zsh-workers
 help / color / mirror / Atom feed
* [BUG] insert-last-word gets stuck at comments
@ 2021-07-26  7:06 Frederick Eaton
  2021-07-26 22:50 ` Bart Schaefer
  0 siblings, 1 reply; 8+ messages in thread
From: Frederick Eaton @ 2021-07-26  7:06 UTC (permalink / raw)
  To: zsh-workers

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


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

* Re: [BUG] insert-last-word gets stuck at comments
  2021-07-26  7:06 [BUG] insert-last-word gets stuck at comments Frederick Eaton
@ 2021-07-26 22:50 ` Bart Schaefer
  2021-07-27  5:52   ` Frederick Eaton
  0 siblings, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2021-07-26 22:50 UTC (permalink / raw)
  To: Frederick Eaton; +Cc: Zsh hackers list

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.


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

* Re: [BUG] insert-last-word gets stuck at comments
  2021-07-26 22:50 ` Bart Schaefer
@ 2021-07-27  5:52   ` Frederick Eaton
  2021-07-27 20:19     ` Bart Schaefer
  0 siblings, 1 reply; 8+ messages in thread
From: Frederick Eaton @ 2021-07-27  5:52 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

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?


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

* Re: [BUG] insert-last-word gets stuck at comments
  2021-07-27  5:52   ` Frederick Eaton
@ 2021-07-27 20:19     ` Bart Schaefer
  2021-07-28  1:36       ` Bart Schaefer
  0 siblings, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2021-07-27 20:19 UTC (permalink / raw)
  To: Frederick Eaton; +Cc: Zsh hackers list

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.


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

* Re: [BUG] insert-last-word gets stuck at comments
  2021-07-27 20:19     ` Bart Schaefer
@ 2021-07-28  1:36       ` Bart Schaefer
  2021-07-28  9:06         ` Peter Stephenson
  0 siblings, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2021-07-28  1:36 UTC (permalink / raw)
  To: Frederick Eaton; +Cc: Zsh hackers list

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.


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

* Re: [BUG] insert-last-word gets stuck at comments
  2021-07-28  1:36       ` Bart Schaefer
@ 2021-07-28  9:06         ` Peter Stephenson
  2021-07-28 15:40           ` Bart Schaefer
  0 siblings, 1 reply; 8+ messages in thread
From: Peter Stephenson @ 2021-07-28  9:06 UTC (permalink / raw)
  To: Zsh hackers list; +Cc: Frederick Eaton

> 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


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

* Re: [BUG] insert-last-word gets stuck at comments
  2021-07-28  9:06         ` Peter Stephenson
@ 2021-07-28 15:40           ` Bart Schaefer
  2021-07-29  8:14             ` Peter Stephenson
  0 siblings, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2021-07-28 15:40 UTC (permalink / raw)
  To: Zsh hackers list

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.


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

* Re: [BUG] insert-last-word gets stuck at comments
  2021-07-28 15:40           ` Bart Schaefer
@ 2021-07-29  8:14             ` Peter Stephenson
  0 siblings, 0 replies; 8+ messages in thread
From: Peter Stephenson @ 2021-07-29  8:14 UTC (permalink / raw)
  To: Zsh hackers list

> 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


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

end of thread, other threads:[~2021-07-29  8:15 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-26  7:06 [BUG] insert-last-word gets stuck at comments Frederick Eaton
2021-07-26 22:50 ` Bart Schaefer
2021-07-27  5:52   ` Frederick Eaton
2021-07-27 20:19     ` Bart Schaefer
2021-07-28  1:36       ` Bart Schaefer
2021-07-28  9:06         ` Peter Stephenson
2021-07-28 15:40           ` Bart Schaefer
2021-07-29  8:14             ` Peter Stephenson

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/zsh-workers

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

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


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