From: Frank Terbeck <ft@bewatermyfriend.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org
Subject: Re: PATCH: edit-command-line: disable `monitor' option locally
Date: Thu, 17 Mar 2011 11:08:49 +0100 [thread overview]
Message-ID: <87tyf2hxe6.fsf@ft.bewatermyfriend.org> (raw)
In-Reply-To: <110316210401.ZM25580@torch.brasslantern.com> (Bart Schaefer's message of "Wed, 16 Mar 2011 21:04:01 -0700")
Bart Schaefer wrote:
> On Mar 16, 9:16pm, Frank Terbeck wrote:
> } Subject: PATCH: edit-command-line: disable `monitor' option locally
> }
> } I was just told, that suspending an editor while using
> } `edit-command-line' will cause the command line to be lost, yielding
> } this:
> }
> } edit-command-line:zle:17: widgets can only be called when ZLE is active
> }
> } Which makes sense.
>
> Hmm. I don't have this problem.
Hm. I had trouble reproducing this, too. So, I asked the guys for
precise instructions and they came up with something I could reproduce
as well.
> If I suspend from edit-command-line I get brought back to the prompt
> and the previous input is all still there. I can resume the editor
> with "fg" (at which point vim gives me an error about the file no
> longer existing); if I write, exit, and then repeat the
> edit-command-line keystroke, I'm back in the editor looking at the
> stuff I wrote out a minute before, and if I now exit again that stuff
> is loaded onto the command line.
Here is how to get the error:
a) Start a new shell. The error seems to only appear the first time the
`edit-command-line' widget is called.
b) Enter something into the command line buffer.
c) Strike your `edit-command-line' shortcut.
d) "C-z" to suspend.
e) Run another command while being suspended.
f) "fg" to get the editor back.
g) Exit the editor.
This leads to the error I mentioned.
Later attempts don't yield the error, but the command line buffer's
content is *gone* every time. Which to me is quite a grave problem, as
this may lead to rather huge multi-line commands to be gone.
> } So, in order to shield users from accidential dataloss, this patch
> } unsets the `monitor' option temporarily. That does the trick for me and
> } I don't think there is anything this would break.
>
> On the other hand if I put in this patch, then when I try to resume the
> backgrounded editor
Um. How do you end up with a backgrounded editor with this patch?
Shouldn't it be impossible to background the editor if `monitor' is
unset? I can't seem to get that to happen on my linux-based laptop.
> I end up in a *very* strange state where the shell is not responding
> to anything, and I have to go off to another window and kill -CONT the
> editor before I can proceed. In that case vim dies almost immediately
> with "Vim: Error reading input, exiting..."
>
> } If I'm missing something, yell.
>
> I think perhaps this behaves very differently in different contexts.
> Restartable system calls may be the difference, I don't know which
> platform has the trouble that you described.
This happens for me on various linux systems with different kernel
versions. I may be able to try OpenBSD later today, unless someone beats
me to it.
In any case, I think the widget should protect the user from losing the
command line. And disallowing the editor from backgrounding should do
that (and in fact does for me).
Regards, Frank
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925
next prev parent reply other threads:[~2011-03-17 10:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-16 20:16 Frank Terbeck
2011-03-17 4:04 ` Bart Schaefer
2011-03-17 10:08 ` Frank Terbeck [this message]
2011-03-17 15:25 ` Bart Schaefer
2011-03-17 17:56 ` Frank Terbeck
2011-03-18 1:11 ` Bart Schaefer
2011-04-25 14:55 ` Frank Terbeck
2011-04-25 16:21 ` Bart Schaefer
2011-04-25 22:25 ` Frank Terbeck
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=87tyf2hxe6.fsf@ft.bewatermyfriend.org \
--to=ft@bewatermyfriend.org \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.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 public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).