bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] colored filename completion


From: Raphaël Droz
Subject: Re: [patch] colored filename completion
Date: Sat, 25 Jun 2011 23:56:25 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, May 31, 2011 at 01:32:44AM +0200, Raphaël wrote:
> Hi,
> 
> I finished 6 patches which add color to filename completions in
> readline.


Those who tried the patch may have noticed (at least) two bugs:

* non-filename completion (variable, processes, ...) was broken.
I missed part of a condition in readline.c / print_filename().
It is fixed with the attached "dont-bug-non-filename-comp.patch"

* completion of command names was annoying: every match was considered as
a missing-file
It is (partly) fixed with the attached "dont-bug-command-name-completion.patch"


I'll speak about this patch below.

The fact is that readline is not aware that bash went through $PATH and,
very sadly, the char *full_pathname parameter of print_filename() is not
set. readline is, at most, able to check if <full_pathname> or
<to_print> exists (eg, is_dir()).


I was not able to find a nice way to do this without changing a
lot of char **function_definition() by a struct match_entry**.
(it would have had consequences from gen_completion_matches() to
display_matches()).


So I took my inspiration from "rl_filename_completion_desired" and
declared an new readline variable: "rl_executable_completion_desired".
It is almost always 0 but, when
- the bash "command_word_completion_function()" callback is used
- and it returns one entry which is a binary from $PATH
Then
- the variable is set to 1
- the absolute path is returned (instead of the basename)

The lowest common denominator calculation is skipped.
printable_part(), in display_matches(), will take care of splitting the
path so print_filename() will be fed with a valid absolute path (which
allow a correct color).

In such case the LCD would not be useful because:
- there may be aliases, function names, ... + absolute paths
- the LCD on absolute paths would be a non-sense here.


three main drawbacks stays after this patch:

- duplication is not correct:
$ which ls
/bin/ls
$ type -t ls
alias
$ ls<TAB><TAB>
ls      ls      lsattr  ...
[ one is a green (executable), the other is a red "missing file" ]


- aliases, functions, ... and any too "abstract" command name is still
considered as an "missing file". (The goal of the patch was just to make
the "binary in $PATH"-case not that "abstract").


- in the end (print_filename()) priority is given to the filesystem so:
$ pid<TAB><TAB>
pidof@  pidgin*
$ pidt() { true; }
$ pid<TAB><TAB>
pidof@  pidgin* pidt    # "pidt" is red as a missing file
$ touch pidt
$ pid<TAB><TAB>
pidof@  pidgin* pidt    # "pidt" is blank, that's what stat() decided



I would be happy to be given some advises.


Raph

Attachment: dont-bug-non-filename-comp.patch
Description: Text document

Attachment: dont-bug-command-name-completion.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]