A weird bug of grep completion

A weird bug of grep completion

[Joseph Lee]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Dear all,
I'm using macOS 10.13.6, zsh 5.5.1 (x86_64-apple-darwin16.7.0) and grep (GNU grep) 3.1 packaged by Homebrew.
A weird behavior happened when completing `grep --no-*` arguments.
While typing `--no-group-separator`, which is a GNU only argument, after another `--no-*`, the cursor stoped in a wrong place and unable to finish completion. But it works right when `--no-group-separator` goes ahead.

Words might not be clear, so here's a demo video:
https://streamable.com/bxbdv

I would appreciate any ideas, thank you.

Best,
Joseph

Re: A weird bug of grep completion

[Joey Pabalinas]

On July 27, 2018 4:28:27 PM Joseph Lee <cgjosephlee@gmail.com> wrote:

> Dear all,
> I'm using macOS 10.13.6, zsh 5.5.1 (x86_64-apple-darwin16.7.0) and grep (GNU grep) 3.1 packaged by Homebrew.
> A weird behavior happened when completing `grep --no-*` arguments.
> While typing `--no-group-separator`, which is a GNU only argument, after another `--no-*`, the cursor stoped in a wrong place and unable to finish completion. But it works right when `--no-group-separator` goes ahead.
>
> Words might not be clear, so here's a demo video:
> https://streamable.com/bxbdv
>
> I would appreciate any ideas, thank you.

You ended up with your cursor one to the left of a - (you can see it within the block cursor) and that would cause completion to behave a bit oddly depending on setopts.

-- 
Cheers,
Joey Pabalinas

Re: A weird bug of grep completion

[Daniel Shahaf]

Joey Pabalinas wrote on Fri, 27 Jul 2018 16:34 -1000:
> On July 27, 2018 4:28:27 PM Joseph Lee <cgjosephlee@gmail.com> wrote:
> 
> > Dear all,
> > I'm using macOS 10.13.6, zsh 5.5.1 (x86_64-apple-darwin16.7.0) and grep (GNU grep) 3.1 packaged by Homebrew.
> > A weird behavior happened when completing `grep --no-*` arguments.
> > While typing `--no-group-separator`, which is a GNU only argument, after another `--no-*`, the cursor stoped in a wrong place and unable to finish completion. But it works right when `--no-group-separator` goes ahead.
> >
> > Words might not be clear, so here's a demo video:
> > https://streamable.com/bxbdv
> >
> > I would appreciate any ideas, thank you.
> 
> You ended up with your cursor one to the left of a - (you can see it 
> within the block cursor) and that would cause completion to behave a bit 
> oddly depending on setopts.

To clarify: the bug report is that «grep --no-filename --no<TAB>» appends
a hyphen to $BUFFER but leaves $CURSOR as it was, after the second "--no"
rather than after the newly-added hyphen.

There's no option whose name is of the form /^--no[^-].*/, so this does seem to
be a bug.

Re: A weird bug of grep completion

[Joseph Lee]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

Suplemnt previous report: the bug happens only when `--no-group-separator` after `--no-messages` or `--no-filename` arguments, even the short form `-s` and `-h`do the same behavior.

Best,
Joseph
On Jul 28, 2018, 3:54 PM +0800, Daniel Shahaf <d.s@daniel.shahaf.name>, wrote:
> Joey Pabalinas wrote on Fri, 27 Jul 2018 16:34 -1000:
> > On July 27, 2018 4:28:27 PM Joseph Lee <cgjosephlee@gmail.com> wrote:
> >
> > > Dear all,
> > > I'm using macOS 10.13.6, zsh 5.5.1 (x86_64-apple-darwin16.7.0) and grep (GNU grep) 3.1 packaged by Homebrew.
> > > A weird behavior happened when completing `grep --no-*` arguments.
> > > While typing `--no-group-separator`, which is a GNU only argument, after another `--no-*`, the cursor stoped in a wrong place and unable to finish completion. But it works right when `--no-group-separator` goes ahead.
> > >
> > > Words might not be clear, so here's a demo video:
> > > https://streamable.com/bxbdv
> > >
> > > I would appreciate any ideas, thank you.
> >
> > You ended up with your cursor one to the left of a - (you can see it
> > within the block cursor) and that would cause completion to behave a bit
> > oddly depending on setopts.
>
> To clarify: the bug report is that «grep --no-filename --no<TAB>» appends
> a hyphen to $BUFFER but leaves $CURSOR as it was, after the second "--no"
> rather than after the newly-added hyphen.
>
> There's no option whose name is of the form /^--no[^-].*/, so this does seem to
> be a bug.
>

Re: A weird bug of grep completion

[Jun T.]

> 2018/07/28 11:28, Joseph Lee <cgjosephlee@gmail.com> wrote:
> 
> A weird behavior happened when completing `grep --no-*` arguments.
> While typing `--no-group-separator`, which is a GNU only argument, after another `--no-*`, the cursor stoped in a wrong place and unable to finish completion. But it works right when `--no-group-separator` goes ahead.

The problem can be reproduced by simple examples shown below,
but I don't know how to fix it.

% compdef '_arguments : -a-a -a-b -a-c -a-d-e' cmd

Then the following work as expected
('<TAB>' can be replaced by '-<TAB>' or '-a-<TAB>' etc.)
% cmd <TAB>
% cmd -a-a <TAB>
% cmd -a-a -a-b -a-c <TAB>
% cmd -a-a -a-d-e <TAB>

But this does not work
% cmd -a-a -a-b <TAB>

So the problem occurs when
  exactly two possibilities are remaining for completion
    and
  one of the possibilities contains two (or more) hyphens
  (as in a-d-e) except for the leading '-'.

# If -a-d-e is replaced by -a-d-c then behavior changes
# (becomes worse, I think).

The problem is related with the match-spec "r:|[_-]=*" used
by _arguments (hard-coded in parse_cadef(), computil.c).
For example, the following does not work either:

% compdef 'compadd -M "r:|[_-]=*" a-a a-b-a' cmd
% cmd <TAB>

But I couldn't get exactly why this happens or how to
fix this.

Re: A weird bug of grep completion

[Jun T]

Is there anyone looking into this problem?

A minimal example to reproduce the problem is:
    % _cmd() { compadd -M 'r:|[_-]=*' a-b a-c-d }       # [1]
    % compdef _cmd cmd
    % cmd <TAB>
The cursor is misplaced after the first TAB.

If a-c-d is replaced by a-c-b, the problem becomes worse:
    % _cmd() { compadd -M 'r:|[_-]=*' a-b a-c-b }       # [2]
    % cmd <TAB>
Only a-b is completed in this case.
The following behaves similarly (only a-b is completed):
    % _cmd() { compadd -M 'r:|[_-]=*' a-b a-c-b a-d-b } # [3]

But the followings are OK:
    % _cmd() { compadd -M 'r:|[_-]=*' a-c-b a-b }       # [4]
or
    % _cmd() { compadd -M 'r:|[_-]=*' a-b a-e a-c-b }   # [5]

[2] and [4] differ only in the order 'a-b' and 'a-c-b' are passed
to compadd. I guess the function join_clines() (compmatch.c) is
most suspicious but not sure.
Anyway the code is too complicated for me to debug.

Re: A weird bug of grep completion

[Peter Stephenson]

On Thu, 16 Aug 2018 17:20:55 +0900
Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
> Is there anyone looking into this problem?
>
> Anyway the code is too complicated for me to debug.

This is basically unmaintained for just that reason.

pws