[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7728: 24.0.50; GDB backtrace from abort

From: Drew Adams
Subject: bug#7728: 24.0.50; GDB backtrace from abort
Date: Thu, 13 Jan 2011 14:06:58 -0800

> I'm just telling you what's the right way to do it.

I appreciate that.  But it's not related to what's needed to fix this bug.
That's all I was trying to say.

> > Sorry, but I have never, ever suffered from "those things".
> Then either you were lucky to only use the code after I fixed 
> it, or you don't know what I'm talking about.  The typical
> misuse looks like:
> (save-window-excursion (let ((b (find-file "foo")))  blabla))
> instead of (let ((b (find-file-noselect "foo")))  blabla)
> I.e. call code that may modify the window-layout whereas what 
> the caller wants is something else, so he uses
> save-window-excursion to "undo" those changes.  But of course,
> with pop-up-frames and friends, in many/most cases the code may
> not only modify the window-layout but also create a new frame,
> which can't really be undone because the creation
> itself is already user-visible, and save-window-excursion 
> won't even try to undo it anyway.

It's good to have that pointed out, of course.  But no, I don't believe I've
used `s-w-e' like that.  I tend to use `find-file-noselect' much more than
`find-file' anyway.  I call `find-file' typically only from `find-file' wrapper
commands and such.  But I get your point.

I expect that both you and I have come across places now and then where we
needed to fix code because of interactions with frames.  I don't think it's
common that such source bugs stay hidden from us long, precisely because we use
frames more than most people do.

Problems such as you point out are, I imagine, more common with developers who
test only in an environment where frames are _not_ used very much.  It makes
sense to draw special attention to such gotchas in that case.
> > And `save-window-excursion' _has_ always been used for this kind of
> > thing in Emacs AFAIK - revisionism notwithstanding.
> I didn't know that.  Can you point at some examples?

Nope, sorry.  But you can imagine, I think, that before `with-selected-frame'
existed `s-w-e' was used for similar use cases. ;-)

However, grepping for `with-selected-frame' in the Emacs sources shows very few
hits, and all of them correspond to code (e.g. function defs) that was
inexistent in older releases (e.g. Emacs 20).  So no, I don't see an example
offhand where code that used `s-w-e' might have been "upgraded" to code that
uses `with-selected-frame'.

> You know I always consider any crash as a bug in the C code, even if
> it's triggered by Elisp code.

Yes, I hope (and assume) so.  The question is whether the C fix will still allow
the same behavior as previously.  I really hope so.

So let's please just assume here that (a) the source code I mentioned is not
doing something ill-advised, verboten, off-the-wall, or silly wrt this bug, and
(b) it doesn't need to be changed for things to work properly, but rather (c)
the C code should be fixed so that such source code and its byte-compilation
continues to work as before.

I will help to diagnose things at my end if I can be of assistance, but let's
please not concentrate on having the user source code be changed to effect a

That `save-window-excursion', like other things in Emacs Lisp, can be misused or
might otherwise not DTRT in some cases is not the question here.

For my use case it DTRT, and has been doing it, for this code, for years.  This
code needs to work not just for my own setup (with a standalone minibuffer etc.
- the case for the reported crash), but more importantly for other setups,
including more common setups.  It works well, I believe, so let's not worry here
and now about improving it.  That's all.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]