Feature request: readline's completion-prefix-display-length option

Feature request: readline's completion-prefix-display-length option

[Hong Xu]

[-- Attachment #1.1: Type: text/plain, Size: 427 bytes --]

Hi,

I believe that readline's completion-prefix-display-length is a great
option to have for zle. This option enables the common part of long
completions to be represented by ellipsis, so the options in the
completion list would not be too long in many cases.

An demo is shown here
<http://rebrn.com/re/you-can-make-readline-and-bash-much-more-user-friendly-by-adding-1571082/>

Please CC me when reply.

Hong


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Feature request: readline's completion-prefix-display-length option

[Bart Schaefer]

On Sat, May 14, 2016 at 11:08 PM, Hong Xu <hong@topbug.net> wrote:
>
> I believe that readline's completion-prefix-display-length is a great
> option to have for zle. This option enables the common part of long
> completions to be represented by ellipsis, so the options in the
> completion list would not be too long in many cases.

There might be a deviously clever way to do this with the list-colors
style, similar to the way that show-ambiguity is implemented.

Re: Feature request: readline's completion-prefix-display-length option

[Daniel Shahaf]

Bart Schaefer wrote on Sun, May 15, 2016 at 04:50:50 -0700:
> On Sat, May 14, 2016 at 11:08 PM, Hong Xu <hong@topbug.net> wrote:
> >
> > I believe that readline's completion-prefix-display-length is a great
> > option to have for zle. This option enables the common part of long
> > completions to be represented by ellipsis, so the options in the
> > completion list would not be too long in many cases.
> 
> There might be a deviously clever way to do this with the list-colors
> style, similar to the way that show-ambiguity is implemented.

Like this?

[[[
$ zsh -f
% autoload compinit && compinit
% zstyle -e ':completion:*' list-colors $'reply=( "=(#b)(${(b)PREFIX})(?)([^ ]#)*=0=33=${#PREFIX}D…\e[34=33" )'
% rsync --no-<TAB>
…D                        -- turn off --devices and --specials                                                                                                        
…blocking-io              -- turn off --blocking-io                                                                                                                   
…detach                   -- do not detach from the parent                                                                                                            
…devices                  -- turn off --devices                                                                                                                       
…dirs           …d    -- turn off --dirs                                                                                                                          
…group          …g    -- turn off --group                                                                                                                         
…hard-links     …H    -- turn off --hard-links                                                                                                                    
]]]

This is simply a bobby tables solution:

- The xterm control sequence for coloring is «\e[42m».
- The xterm control sequence for "move left" is «\e[42D».
- Setting the part between the two '=' signs to «42Dfoobar\e[43» causes
  the cursor to move left 42 spaces (over the common prefix already
  output), insert "foobar", and switch to color number 43.

(reference: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html)

This solution breaks alignment¹ since zle doesn't account for the
cursor movement; a workaround for that is to add padding:

[[[
% zstyle -e ':completion:*' list-colors $'reply=( "=(#b)(${(b)PREFIX})(?)([^ ]#)*=0=33=${#PREFIX}D${(r:$#PREFIX-1:: :):-}…\e[34=33" )'
% rsync --delete<TAB>
--delete                               -- delete files that do not exist on the sending side                                                                              
       …-before                        -- receiver deletes before transfer                                                                                                
       …-delay                …-after  -- receiver deletes after transfer                                                                                                 
       …-during                        -- receiver deletes during transfer                                                                                                
       …-excluded                      -- also delete excluded files on the receiving side                                                                                
       …-missing-args                  -- delete missing source args from destination                                                                                     
]]]

However, this workaround doesn't make the listing occupy less columns,
which was the original request.

Cheers,

Daniel

¹ Alignment is broken in two cases: (a) when both ${PREFIX} and
${PREFIX}foo are possible completions; (b) when some completions have the
same description as each other and are shown together.  If ${PREFIX} is
a proper prefix of all possible completions and all descriptions are
unique, the listing will be aligned, but descriptions will not use the
full terminal width.

Re: Feature request: readline's completion-prefix-display-length option

[Daniel Shahaf]

Daniel Shahaf wrote on Thu, May 19, 2016 at 21:14:27 +0000:
> Bart Schaefer wrote on Sun, May 15, 2016 at 04:50:50 -0700:
> > On Sat, May 14, 2016 at 11:08 PM, Hong Xu <hong@topbug.net> wrote:
> > >
> > > I believe that readline's completion-prefix-display-length is a great
> > > option to have for zle. This option enables the common part of long
> > > completions to be represented by ellipsis, so the options in the
> > > completion list would not be too long in many cases.
> > 
> > There might be a deviously clever way to do this with the list-colors
> > style, similar to the way that show-ambiguity is implemented.
> 
> Like this?

I've added a guard and made minor tweaks:

if [[ $'\e\x5b3D' == "$(echoti cub 3)" ]] &&
   [[ $'\e\x5b33m' == "$(echoti setaf 3)" ]]; then
  zstyle -e ':completion:*' list-colors $'reply=( "=(#b)(${(b)PREFIX})(?)([^ ]#)*=0=0=${PREFIX:+${#PREFIX}D${(l:$#PREFIX:: :):-…}\e\x5b}34=33" )'
fi
zstyle ':completion:*:*(directories|files)*' list-colors ''

Re: Feature request: readline's completion-prefix-display-length option

[Daniel Shahaf]

Bart Schaefer wrote on Sun, May 15, 2016 at 04:50:50 -0700:
> On Sat, May 14, 2016 at 11:08 PM, Hong Xu <hong@topbug.net> wrote:
> >
> > I believe that readline's completion-prefix-display-length is a great
> > option to have for zle. This option enables the common part of long
> > completions to be represented by ellipsis, so the options in the
> > completion list would not be too long in many cases.
> 
> There might be a deviously clever way to do this with the list-colors
> style, similar to the way that show-ambiguity is implemented.

Deviously clever solutions aside, isn't this exactly what the -d option
to compadd is for?  I imagine prior to calling compadd, the following
preprocessing could be invoked:

    if -d not passed:
      argument_to_-d = argument_to_-a
      for each element of argument_to_-d:
        if this element starts with ${PREFIX}
	  replace the first ${#PREFIX} characters of this element with an ellipsis

However, I'm not sure where this preprocessing should be invoked from.

CHeers,

Daniel

Re: Feature request: readline's completion-prefix-display-length option

[Bart Schaefer]

On May 19,  9:14pm, Daniel Shahaf wrote:
} Subject: Re: Feature request: readline's completion-prefix-display-length 
}
} Deviously clever solutions aside, isn't this exactly what the -d option
} to compadd is for?  I imagine prior to calling compadd, the following
} preprocessing could be invoked:
} 
}     if -d not passed:
}       argument_to_-d = argument_to_-a
}       for each element of argument_to_-d:
}         if this element starts with ${PREFIX}
} 	  replace the first ${#PREFIX} characters with an ellipsis
} 
} However, I'm not sure where this preprocessing should be invoked from.

It'd have to be internal to complete.c:bin_compadd in order to be
foolproof; there are too many variations on how to pass in the list
matches to make it feasible to do in shell code: literal lists of
words, names passed to -a, subscripts on names passed to -a, etc.