[Bash-completion-devel] Improve make target completion

Tue Sep 11 20:21:42 UTC 2012

On Sat, 8 Sep 2012 00:24:06 +0100
Tristan Wibberley <tristan.wibberley at gmail.com> wrote:

> Igor,
> 
> I rewrote some of the incremental completion for make that I sent
> previously. Hopefully this is clearer.
> 
>   commit-4a1e30f-incremental-completion

Looks like this one works much slower than the previous.

> It offers make targets for completion only as far as the next slash in
> each target that matches the current word. This causes incremental
> completion behaviour like regular file and directory completion.
> 
> When displaying possible completions, it also avoids displaying all
> the parent directories of the target being completed, ie:
> 
>  foo/all-x86<tab><tab>
> 
> will display:
> 
>  all-x86-bins
>  all-x86-libs
>  all-x86-sub-components/
> 
> instead of:
> 
>  foo/all-x86-bins
>  foo/all-x86-libs
>  foo/all-x86-sub-components/bins
>  foo/all-x86-sub-components/libs
> 
> This makes a big difference to usability for many non-autotools
> makefiles where there can be large numbers of long paths matching any
> prefix.

Yeah. This way it looks much better.

And i also have some remarks regarding coding style:

 * Please use:

    if list; then
        list
    fi

  not 

    if list
    then
        list
    fi

 * if you want to use _make_sed_escape() only once, then
   why you need it at all?

> I am also considering an improvement to display for autotools
> makefiles offering common prefix suggestions when displaying
> alternatives up to a dash character in order to keep the number of
> lines to display useful information to a practical level. eg:
> 
> all-<many>-bins
> clean-<many>
> 
> which can later become:
> 
> all-foo-bins
> all-bar-bins
> 
> or
> 
> clean-foo
> clean-bar
> 
> After the user has added more of a word.
> 
> That's just a pipe-dream at the moment. Opinions wanted.
> 
> Regards,
> Tristan Wibberley
> 
> On 5 September 2012 22:50, Igor Murzov <e-mail at date.by> wrote:
> > On Wed, 5 Sep 2012 19:59:06 +0100
> > Tristan Wibberley <tristan.wibberley at gmail.com> wrote:
> >
> >> commit-a1843b3: Rolled up previous changes. Also made the displayed
> >> suggestions only show the next step of the completion, like file and
> >> folder completion. Fixed whitespace.
> >
> > Sorry, I don't understand how $mode works in this patch.
> > So I pushed the first version of the patch with some formatting
> > fixes:
> >
> > http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commit;h=b28d7108d3677c61bd01c51ccee8bb1cf9e3bfba
> >
> >
> > -- Igor
> >
> >> On 5 September 2012 14:32, Igor Murzov <e-mail at date.by> wrote:
> >> > On Sat, 1 Sep 2012 09:14:41 +0100
> >> > Tristan Wibberley <tristan.wibberley at gmail.com> wrote:
> >> >
> >> >> Hello bash completion team.
> >> >>
> >> >> Forwarding my changes to the team now that I discovered there is a
> >> >> mailling list for this.
> >> >>
> >> >> Please consider applying the attached git commits for bash-completion for make.
> >> >>
> >> >> attachments:
> >> >>   commit-aef2ee - converts make completion to use more metadata for
> >> >> better results
> >> >>   commit-6d1b6d9 - simplifies regex, adds more exclusions
> >> >>   commit-d05dbbc - scalability and speed + incremental completions.
> >> >>
> >> >> The commits against
> >> >> http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git
> >> >> improve bash completion for make by replacing the processing command
> >> >> for the output of make -np
> >> >>
> >> >> This lists all explicit targets, no intermediates, and no source files.
> >> >>
> >> >> For an automake project like gcc there is almost no difference in
> >> >> output completions. For gcc's generated makefile a couple of
> >> >> completions are not proposed in this version which are proposed by the
> >> >> existing version and these are not buildable targets in that project's
> >> >> make system.
> >> >>
> >> >> Performance even for small makefiles like gcc's is improved.
> >> >>
> >> >> For makefiles with .INTERMEDIATE targets properly marked up then
> >> >> generated deps rules, targets of those deps and intermediate files do
> >> >> not get listed thus the patch avoids suggesting most of the targets a
> >> >> user doesn't want.
> >> >>
> >> >> For the linux kernel makefiles, completion time is reduced to one
> >> >> quarter of the time to process the makefiles, nearly halving the
> >> >> latency while returning most useful targets (taking the list from 88
> >> >> to four digits) and keeping the number of suggestions small (taking
> >> >> the first round of suggestions up to the first slash from 88 to 100 or
> >> >> so because it supports incremental completion where targets are in
> >> >> subdirectories.).
> >> >>
> >> >> For a makefile such as the example at
> >> >> http://codeshot.blogspot.co.uk/2012/08/this-is-program-that-lists-targets-in.html
> >> >> the improvement is dramatic. When I create 4 empty files named
> >> >> test/a.cc test/b.cc test/c.cc test/d.cc in a subfolder "test" below
> >> >> that Makefile this version of make target completion generates 14
> >> >> useful user targets and no source files vs 2 useful targets and 5
> >> >> source files for the existing bash completion awk expression.
> >> >
> >> > Hi, Tristan.
> >> >
> >> > I like your patches. Completion for make was always somewhat
> >> > incomplete and with your patches it definitely works!
> >> >
> >> > Some small remarks about the patches:
> >> >
> >> > * Your way to parse the output of `make -npq` does not work
> >> >   for me unless LC_ALL=C is set. So please use `LC_ALL=C make -npq`
> >> >   to get correct results on other locales.
> >> >
> >> > * We don't use tabs for formatting. And commit-d05dbbc has
> >> >   one tab in it. And there is also one whitespace issue in
> >> >   this patch:
> >> >
> >> >   $ git apply commit-aef2eee commit-6d1b6d9 commit-d05dbbc
> >> >   commit-d05dbbc:279: trailing whitespace.
> >> >           COMPREPLY=( $( compgen -W "$(
> >> >   warning: 1 line adds whitespace errors.
> >> >
> >> > Also, it's may be better to squash these 3 patches into one
> >> > single patch, because it seems better for me to review the
> >> > changes as a whole. Anyway, the patches are great!
> >> >
> >> >
> >> > -- Igor