Hello Zsh Workers, This may be a somewhat minor bug, but I think that when interactive_comments is set, the 'insert-last-word' widget gets stuck on lines that are fully commented: $ zsh -f -i % setopt interactive_comments % echo hi #comment hi % # blah blah % echo bye #comment bye % echo foo foo % echo <Esc>.<Esc>.<Esc>. I would have expected to see "echo hi" after the command line prompt at this point, but I see "echo bye". zsh 5.8 (x86_64-pc-linux-gnu) Thanks! Frederick
On Mon, Jul 26, 2021 at 12:07 AM Frederick Eaton <frederik@ofb.net> wrote: > > This may be a somewhat minor bug, but I think that when > interactive_comments is set, the 'insert-last-word' widget gets stuck > on lines that are fully commented: I'm able to reproduce this. A fully-commented line has an event number but contains no words; e.g., it's also an "error" to attempt to refer to event number 3 e.g. with !3 in the example: > $ zsh -f -i > % setopt interactive_comments > % echo hi #comment > hi > % # blah blah > % echo bye #comment > bye > % echo foo > foo > % echo <Esc>.<Esc>.<Esc>. At this point: % !3 zsh: no such word in event Even though !2 and !4 work as expected. So insert-last-word gets as far as event 3 and then gets the no-such-word error, which interrupts it. A workaround is to enable smart-insert-last-word.
On Mon, Jul 26, 2021 at 03:50:17PM -0700, Bart Schaefer wrote:
>On Mon, Jul 26, 2021 at 12:07 AM Frederick Eaton <frederik@ofb.net> wrote:
>>
>> This may be a somewhat minor bug, but I think that when
>> interactive_comments is set, the 'insert-last-word' widget gets stuck
>> on lines that are fully commented:
>
>I'm able to reproduce this. A fully-commented line has an event
>number but contains no words; e.g., it's also an "error" to attempt to
>refer to event number 3 e.g. with !3 in the example:
>
>> $ zsh -f -i
>> % setopt interactive_comments
>> % echo hi #comment
>> hi
>> % # blah blah
>> % echo bye #comment
>> bye
>> % echo foo
>> foo
>> % echo <Esc>.<Esc>.<Esc>.
>
>At this point:
>
>% !3
>zsh: no such word in event
>
>Even though !2 and !4 work as expected. So insert-last-word gets as
>far as event 3 and then gets the no-such-word error, which interrupts
>it.
>
>A workaround is to enable smart-insert-last-word.
I've read the documentation for insert-last-word and
smart-insert-last-word and I can't figure out how they are different.
In the manual page, under 'smart-insert-last-word', it says:
With a numeric argument, or when passed command line arguments
in a call from another widget, it behaves like insert-last-word,
except that words in comments are ignored when INTERACTIVE_COM-
MENTS is set.
So they are the same when interactive_comments is not set? However,
according to my experiments it seems that insert-last-word also
ignores comments when interactive_comments is set, so I am not able to
understand the difference.
Maybe someday someone will send a patch to fix insert-last-word to
work as described in the documentation?
On Mon, Jul 26, 2021 at 10:52 PM Frederick Eaton <frederik@ofb.net> wrote:
>
> I've read the documentation for insert-last-word and
> smart-insert-last-word and I can't figure out how they are different.
>
> So they are the same when interactive_comments is not set? However,
> according to my experiments it seems that insert-last-word also
> ignores comments when interactive_comments is set, so I am not able to
> understand the difference.
I think what's happened is that a (now very old) change to the way the
history mechanism stores/fetches words, had an unexpected side-effect
on insert-last-word.
Where we've ended up is that insert-last-word can never "see"
comments, but smart-insert-last-word is able to see them if the
setting of interactive_comments changes from on to off between the
time the comment got entered into the history and the time
smart-insert-last-word is run. Which of course almost never occurs.
There's code in the insertlastword function that's (according to the
comment) supposed to stop us getting stuck, but apparently in the case
where the line is entirely empty that isn't working. It may be
possible to fix it.
On Tue, Jul 27, 2021 at 1:19 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> There's code in the insertlastword function that's (according to the
> comment) supposed to stop us getting stuck, but apparently in the case
> where the line is entirely empty that isn't working. It may be
> possible to fix it.
Hm. It's not difficult to fix in that continuing to hit <ESC .> picks
up where it left off, but it still beeps and inserts nothing.
I wonder if it would be preferable if it just skipped on to the next
(that is, usually, the preceding) last word?
It's possible the current misdocumented behavior dates all the way
back to 849f4068de (workers/16767) in 2002 and nobody noticed. I
can't find anything else obvious.
> On 28 July 2021 at 02:36 Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Tue, Jul 27, 2021 at 1:19 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > There's code in the insertlastword function that's (according to the
> > comment) supposed to stop us getting stuck, but apparently in the case
> > where the line is entirely empty that isn't working. It may be
> > possible to fix it.
>
> Hm. It's not difficult to fix in that continuing to hit <ESC .> picks
> up where it left off, but it still beeps and inserts nothing.
>
> I wonder if it would be preferable if it just skipped on to the next
> (that is, usually, the preceding) last word?
That seems reasonable --- I can't think of circumstances where you'd want
no result, unless you've actually reached the last possibility.
pws
On Wed, Jul 28, 2021 at 2:07 AM Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> > I wonder if it would be preferable if it just skipped on to the next
> > (that is, usually, the preceding) last word?
>
> That seems reasonable --- I can't think of circumstances where you'd want
> no result, unless you've actually reached the last possibility.
Should that happen only in the default case, or even when one or more
arguments are provided?
My inclination is to say that if a specific history event or word was
requested, but isn't found, the op should just fail as it does now.
> On 28 July 2021 at 16:40 Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Wed, Jul 28, 2021 at 2:07 AM Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
> >
> > > I wonder if it would be preferable if it just skipped on to the next
> > > (that is, usually, the preceding) last word?
> >
> > That seems reasonable --- I can't think of circumstances where you'd want
> > no result, unless you've actually reached the last possibility.
>
> Should that happen only in the default case, or even when one or more
> arguments are provided?
>
> My inclination is to say that if a specific history event or word was
> requested, but isn't found, the op should just fail as it does now.
Seems OK --- as long as it doesn't get stuck when it shouldn't I don't
think the exact behaviour is that big a deal if there's some kind of
rationale.
pws