zsh-users
 help / color / mirror / Atom feed
* edit-command-line breaks out of vared
@ 2018-08-19 12:22 Daniel Shahaf
  2018-08-19 13:18 ` Mikael Magnusson
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Shahaf @ 2018-08-19 12:22 UTC (permalink / raw)
  To: zsh-users

[[[
$ zsh -f
% l=( 1 2 3  )
% bindkey -e
% autoload edit-command-line
% zle -N edit-command-line
% bindkey '^Fc' edit-command-line
% vared l
<press ^F c>
<:w>
<:q>
% 1 2 3<CURSOR>
]]]

I expected quitting the editor to let me resume the vared session, but
instead it left me with the variable's value as a command line.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: edit-command-line breaks out of vared
  2018-08-19 12:22 edit-command-line breaks out of vared Daniel Shahaf
@ 2018-08-19 13:18 ` Mikael Magnusson
  2018-08-19 19:03   ` Bart Schaefer
  0 siblings, 1 reply; 5+ messages in thread
From: Mikael Magnusson @ 2018-08-19 13:18 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh Users

On Sun, Aug 19, 2018 at 2:22 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> [[[
> $ zsh -f
> % l=( 1 2 3  )
> % bindkey -e
> % autoload edit-command-line
> % zle -N edit-command-line
> % bindkey '^Fc' edit-command-line
> % vared l
> <press ^F c>
> <:w>
> <:q>
> % 1 2 3<CURSOR>
> ]]]
>
> I expected quitting the editor to let me resume the vared session, but
> instead it left me with the variable's value as a command line.

This works in my version of edit-command-line,

diff --git c/Functions/Zle/edit-command-line w/Functions/Zle/edit-command-line
index e17893e938..761f8da6d0 100644
--- c/Functions/Zle/edit-command-line
+++ w/Functions/Zle/edit-command-line
@@ -29,7 +29,12 @@
   (( $+zle_bracketed_paste )) && print -r -n - $zle_bracketed_paste[1]

   # Replace the buffer with the editor output.
-  print -Rz - "$(<$1)"
-} =(<<<"$PREBUFFER$BUFFER")
+  # avoid drawing a new prompt when we can
+  [[ -z $PREBUFFER ]] && {
+    BUFFER="$(<$1)"
+  } || {
+    print -Rz - "$(<$1)"
+    zle send-break
+  }

-zle send-break         # Force reload from the buffer stack
+} =(<<<"$PREBUFFER$BUFFER")


-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: edit-command-line breaks out of vared
  2018-08-19 13:18 ` Mikael Magnusson
@ 2018-08-19 19:03   ` Bart Schaefer
  2018-08-20 12:58     ` Daniel Shahaf
  0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2018-08-19 19:03 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Daniel Shahaf, Zsh Users

> On Sun, Aug 19, 2018 at 2:22 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>
>> I expected quitting the editor to let me resume the vared session

My first inclination here is to ask why you expected that ...

>> instead it left me with the variable's value as a command line.

... because the name of the function is edit-command-line, after all.


On Sun, Aug 19, 2018 at 6:18 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> This works in my version of edit-command-line,
>
> +  [[ -z $PREBUFFER ]] && {

Hrm, is PREBUFFER really guaranteed to be empty whenever vared is
running?  I suppose so.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: edit-command-line breaks out of vared
  2018-08-19 19:03   ` Bart Schaefer
@ 2018-08-20 12:58     ` Daniel Shahaf
  2020-08-05 11:12       ` Mikael Magnusson
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Shahaf @ 2018-08-20 12:58 UTC (permalink / raw)
  To: zsh-users

Bart Schaefer wrote on Sun, 19 Aug 2018 12:03 -0700:
> > On Sun, Aug 19, 2018 at 2:22 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >>
> >> I expected quitting the editor to let me resume the vared session
> 
> My first inclination here is to ask why you expected that ...
> 
> >> instead it left me with the variable's value as a command line.
> 
> ... because the name of the function is edit-command-line, after all.
> 

I assumed edit-command-line would work inside vared, despite the
name, and that when $EDITOR finished it would return me to the
previous context.

> On Sun, Aug 19, 2018 at 6:18 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> > This works in my version of edit-command-line,
> >
> > +  [[ -z $PREBUFFER ]] && {
> 
> Hrm, is PREBUFFER really guaranteed to be empty whenever vared is
> running?  I suppose so.

Is there a reason not to commit that?  Before we might've thought it was only
an optimisation but now it seems to enable behaviour that isn't possible with
the code in HEAD.  I don't see anything in my archives about reasons not to
commit that.

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: edit-command-line breaks out of vared
  2018-08-20 12:58     ` Daniel Shahaf
@ 2020-08-05 11:12       ` Mikael Magnusson
  0 siblings, 0 replies; 5+ messages in thread
From: Mikael Magnusson @ 2020-08-05 11:12 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-users, zsugabubus

On 8/20/18, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Bart Schaefer wrote on Sun, 19 Aug 2018 12:03 -0700:
>> > On Sun, Aug 19, 2018 at 2:22 PM, Daniel Shahaf <d.s@daniel.shahaf.name>
>> > wrote:
>> >>
>> >> I expected quitting the editor to let me resume the vared session
>>
>> My first inclination here is to ask why you expected that ...
>>
>> >> instead it left me with the variable's value as a command line.
>>
>> ... because the name of the function is edit-command-line, after all.
>>
>
> I assumed edit-command-line would work inside vared, despite the
> name, and that when $EDITOR finished it would return me to the
> previous context.
>
>> On Sun, Aug 19, 2018 at 6:18 AM, Mikael Magnusson <mikachu@gmail.com>
>> wrote:
>> > This works in my version of edit-command-line,
>> >
>> > +  [[ -z $PREBUFFER ]] && {
>>
>> Hrm, is PREBUFFER really guaranteed to be empty whenever vared is
>> running?  I suppose so.
>
> Is there a reason not to commit that?  Before we might've thought it was only
> an optimisation but now it seems to enable behaviour that isn't possible with
> the code in HEAD.  I don't see anything in my archives about reasons not to
> commit that.

I guess I kinda dropped the ball on this, but at least nobody said not
to commit it in the past two years so I suppose it should be pretty
safe? I've also personally never had any problems (although I pretty
much never go to PS2, but it should act the same as before in that
case).

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-08-05 11:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-19 12:22 edit-command-line breaks out of vared Daniel Shahaf
2018-08-19 13:18 ` Mikael Magnusson
2018-08-19 19:03   ` Bart Schaefer
2018-08-20 12:58     ` Daniel Shahaf
2020-08-05 11:12       ` Mikael Magnusson

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ http://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git