zsh-workers
 help / color / mirror / code / Atom feed
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


  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).