[Top][All Lists]

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

Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?

From: Stefan Monnier
Subject: Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?
Date: Tue, 19 Mar 2019 22:09:21 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> M-x shell
> cd /tmp
> mkdir AAAA\ BB\ CCCC
> cd AAAA\ BB<tab>

When I try this (with Emacs `master` but AFAIK this hasn't changed for
quite a while), I get the expected completion to

    cd AAAA\ BB\ CCCC

what do you get instead?

> Autocomplete fails because (pcomplete-begin) returns the position of
> the first letter A but (length pcomplete-stub) is the length of "AAAA
> BB", which gives the position of the second letter A.  The function
> `max', therefore, sets `beg' to the start of the second letter A.
> Consequently, file-name-completion will be asked to complete "AAA BB"
> instead of the correct one "AAAA BB".

The `completion-table-subvert` and `completion-table-with-quoting`
layers of the completion table are supposed to convert the "AAA\ BB" to
"AAAA BB" and back, so that file-name-completion should see neither
"AAAA\ BB" nor "AAA BB" but "AAAA BB" (which is indeed the string it
needs to do its job correctly).

> What do you think will break if `min' is used instead of `max' to
> repair the following problem seen using `emacs -Q' at the said commit?

To some extent the value of `beg` is not tremendously important because
of the `completion-table-subvert` layer, but there are cases where it
does make a difference.  I can't offhand remember enough to tell you
which are those cases (IIRC it has to do with cases where completion
wants to change text *before* point, e.g. completing `em-li` to
`emacs-lisp` or /u/s/d to /usr/share/doc) so I can't quite remember when
`min` would be worse than `max` here, but IIRC `beg` is used as a kind
of "modification boundary" (the completion operation cannot modify any
part of the text before `beg`) so I use `max` to minimize the damage in
case the replacement breaks the assumptions made by

[ As alluded to in the comment just before the code you cite, there's
  a fundamental discrepancy between the information that pcomplete
  collects and the information that completion-at-point-function needs,
  so we do our best to workaround and confine the cases where the
  discrepancy bites us.  ]


reply via email to

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