headers
Stefan Monnier | 1 Nov 2010 02:28
Picon

Re: GTK stack-busting loop

> *** src/xterm.c	2010-10-25 16:04:54 +0000
> --- src/xterm.c	2010-10-31 03:51:26 +0000
> ***************
> *** 7056,7062 ****
>       }

>     --handling_signal;
> !   UNBLOCK_INPUT;

>     return count;
>   }
> --- 7056,7062 ----
>       }

>     --handling_signal;
> !   --interrupt_input_blocked;

>     return count;
>   }

> Any thoughts?  (Stefan?)

That doesn't sound very good.
There's nothing wrong (fundamentally) with the UNBLOCK_INPUT causing
another call to XTread_socket: after all, we've basically finished the
first call when we get to UNBLOCK_INPUT, so there's no "nested
interrupt" problem, AFAICT.  After all, we're just coming out of
a "while (gtk_events_pending ())", so the case where we get "called
recursively" should be very rare.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Monnier | 1 Nov 2010 02:20
Picon

Re: package.el should be preloaded

> I looked into this, but it turns out that most of package.el would need
> to be preloaded.

That's really strange.  The code needed at startup shouldn't need to be
that large.  Of course, that was part of the reason why I want(ed) all
the job of finding which packages to load in which order to be done
"offline" rather than at startup.

> Instead, I tweaked the code startup.el to check more aggressively for
> local package directories, so that package.el won't be loaded if no
> packages are installed.

It's better than nothing, but we'll need a better answer as soon as
people get used to installing packages, such that the "no installed
package" case becomes rare.

        Stefan
Permalink | Reply | 1 comment |
headers
Stefan Monnier | 1 Nov 2010 02:31
Picon

Re: Package Menu - Unintuitive Keybinding?

> May be 'g' should do what 'r' is right now doing?

Indeed.

> Btw, what could revert-buffer possibly mean in package menu?

revert-buffer means "refresh".

        Stefan
Permalink | Reply | 0 comments |
headers
Jan Djärv | 1 Nov 2010 12:43
Picon

Re: GTK stack-busting loop

2010-10-31 05:00, Chong Yidong skrev:
> On the trunk, with GTK, the following recipe causes an infloop:
>
> 1. emacs -Q -nw -f server-start
> 2. emacsclient -c
> 3. In another terminal, run `xkill' and click on the GTK toolbar
>
> The backtrace is at the end of this message.  It can be obtained by
> attaching to the looping Emacs process in another gdb session.
> Eventually, the loop overflows the stack.
>
> This bug does not occur on the emacs-23 branch, nor if you click `xkill'
> on other parts of the graphical frame.  In those cases, Emacs aborts as
> it now ought to.
>

I get the same behaviour in Emacs-23 and trunk, i.e.:
Connection lost to X server `:0.0'
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.

(emacs:8582): GLib-WARNING **: g_main_context_prepare() called recursively 
from within a source's check() or prepare() member.

(emacs:8582): GLib-WARNING **: g_main_context_check() called recursively from 
within a source's check() or prepare() member.
Fatal error (6)Avbruten (SIGABRT)

	Jan D.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Brown | 1 Nov 2010 14:48
Picon
Favicon

Incorrect merge

Hi Michael,

It looks like the following change got merged with the trunk inadvertently:

revno: 100136
committer: Michael Albinus <michael.albinus <at> gmx.de>
branch nick: emacs-23
timestamp: Mon 2010-10-25 13:46:21 +0200
message:
   * dbusbind.c (Fdbus_call_method_asynchronously)
   (Fdbus_register_signal, Fdbus_register_method): Check, whether
   `dbus-registered-objects-table' is initialized.

   Must not be synchronized with the trunk.

Ken
Permalink | Reply | 38 comments |
headers
Stefan Monnier | 1 Nov 2010 15:12
Picon

backup-by-copying-when-mismatch (was: bug#7289: Tramp changes ownership of remote file when saving)

[ Moving this to emacs-devel. ]

>> 2 problems with this patch:
>> - (put <var> 'permanent-local t) should *never* be in such a function.
>> It's a top-level operation that has global effects and belongs right
>> next to the var's defvar.

> I want to have `backup-by-copying-when-mismatch' buffer local. If I set
> it in `insert-file-contents' (via `make-local-variable'), it is not kept
> buffer local in that buffer.  How could I achieve this otherwise?

You could place the `put' in files.el at toplevel, right next to the
definition of backup-by-copying-when-mismatch.

>> - This makes it impossible to choose backup-by-copying-when-mismatch=nil
>> when accessing such remote files, whereas for local files accessed by
>> root a (setq backup-by-copying-when-mismatch nil) in the .emacs will
>> do the trick.
> D'accord.  We would need another way for the user to express his
> wish.  Maybe there shall be also other values but only than nil and t.

That would be an option, indeed.

>> A simpler solution would be to change the default value of
>> backup-by-copying-when-mismatch to t for everyone rather than just
>> for root.  I don't know what would the objections to this.

> From my pov it would be acceptable, but I don't know how people see it.

Neither do I.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Chong Yidong | 1 Nov 2010 16:01
Favicon

Re: package.el should be preloaded

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> That's really strange.  The code needed at startup shouldn't need to be
> that large.  Of course, that was part of the reason why I want(ed) all
> the job of finding which packages to load in which order to be done
> "offline" rather than at startup.

The total length of package.el is 1642 lines.  Of these, the code
necessary to load and activate packages at startup comes to around 590
lines, or about 16k of memory in the .elc.  (The rest is the code for
downloading and installing, and for the package menu.)

Splitting package.el is certainly doable, but all it will save us is
around 30k.  I'm not sure it's worth it.
Permalink | Reply | 0 comments |
headers
Chong Yidong | 1 Nov 2010 17:03
Favicon

Re: GTK stack-busting loop

Jan Djärv <jan.h.d <at> swipnet.se> writes:

> I get the same behaviour in Emacs-23 and trunk, i.e.:
> Connection lost to X server `:0.0'
> When compiled with GTK, Emacs cannot recover from X disconnects.
> This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
> For details, see etc/PROBLEMS.

Hmm, now I can't reproduce it either.  Oh well, sorry for the noise.
Permalink | Reply | 0 comments |
headers
Chong Yidong | 1 Nov 2010 17:11
Favicon

Re: Merging Finder into package mechanism

"Drew Adams" <drew.adams <at> oracle.com> writes:

>> I'll add a placeholder NEWS entry as a reminder, but
>> there will likely be more changes before Emacs 24 is released.
>
> Please keep NEWS updated correctly wrt this breakage.  NEWS is for
> users.  If you can update change logs for developers then you can also
> update NEWS for users.  You don't use "placeholders" in change logs,
> do you?

I'm not sure you understand how NEWS is supposed to work, or the fact
that Emacs 24 is not yet released...
Permalink | Reply | 6 comments |
headers
Chong Yidong | 1 Nov 2010 16:22
Favicon

Re: [Patch] Tango color theme extension

Jan Moringen <jan.moringen <at> uni-bielefeld.de> writes:

> Hi,
>
> I noticed that a version of the Tango color theme has been added
> recently. Since I had a custom version of the Tango color theme, I
> merged the two versions.
>
> The introduced changes are:
>
>       * Definition of the tango palette colors in a separate file
>       * Faces for Smerge, Ediff, flyspell, Semantic and outline
>
> Screenshots showing the Semantic and outline faces are attached.
>
> The attached patch does not integrate the new file into the build
> system.

Thanks.

Some of these faces should probably inherit from font-lock faces.  That
would reduce the number of faces users, and theme writers, need to edit.
When I get the time, I'll take a look into this, and merge the rest of
your changes into tango-theme.el.
Permalink | Reply | 0 comments |

Gmane