From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: "Roland Winkler" <winkler@gnu.org>
Cc: 11983@debbugs.gnu.org
Subject: bug#11983: 24.1; Electric-command-loop broken?
Date: Fri, 20 Jul 2012 08:09:41 -0400 [thread overview]
Message-ID: <jwvfw8mocza.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20489.13911.18062.669102@lukas.physics.niu.edu> (Roland Winkler's message of "Fri, 20 Jul 2012 05:43:35 -0500")
>> > (unwind-protect
>> > (catch 'return-tag
>> > (Electric-command-loop 'return-tag))
>> > (cleanup-form))
>> But in which way is this different from `recursive-edit'?
> I do not know much about recursive-edit. How would you use it as a
> replacement for the above to be sure that after leaving
> recursive-edit cleanup-form is always executed?
(unwind-protect
(recursive-edit)
(cleanup-form))
>> It seems that it requires a fair bit of extra surrounding code to
>> use it right. E.g. electric-buffer-list is buggy because it lacks
>> this extra code: after popping up the electric-buffer-list, you
>> can select some other window and work there, but the behavior is
>> then all messed up.
> The amount of protection provided by an Electric-command-loop
> depends on the surrounding code (save-excursion,
> save-window-excursion, etc.)
The issue is not that the buffer is not reset when you return from
electric-buffer-list, but that during electric-buffer-list if you select
some other window you do not exit electric-buffer-list and the keys end
up behaving weird (e.g. typing "c" in a normal buffer will insert "c"
and then move to EOB or something like that). Once you exit from
electric-buffer-list, things are back to normal.
> I believe that the intended usage pattern of Electric-command-loop
> does not include too wild things such as selecting other windows. Or
> phrased differently: of course, you can always do whatever you
> like. But only cleanup-form is definitely evaluated at the end.
What I'm saying is that it's tricky to use Electric-command-loop without
introducing bugs because Electric-command-loop presumes that all
operations will stay within the current buffer, but it does not (help
to) try to enforce it. So it's a poor API.
Stefan
next prev parent reply other threads:[~2012-07-20 12:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-18 20:54 bug#11983: 24.1; Electric-command-loop broken? Roland Winkler
2012-07-19 8:40 ` Stefan Monnier
2012-07-19 21:29 ` Roland Winkler
2012-07-20 9:47 ` Stefan Monnier
2012-07-20 10:43 ` Roland Winkler
2012-07-20 12:09 ` Stefan Monnier [this message]
2012-07-20 12:38 ` Roland Winkler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvfw8mocza.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=11983@debbugs.gnu.org \
--cc=winkler@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.