[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
`completion-table-subvert`.
[ 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. ]
Stefan
- [pcomplete.el (pcomplete-completions-at-point)] Why max?, Tadeus Prastowo, 2019/03/16
- Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?, Tadeus Prastowo, 2019/03/19
- Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?,
Stefan Monnier <=
- Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?, Tadeus Prastowo, 2019/03/20
- Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?, Stefan Monnier, 2019/03/20
- Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?, Tadeus Prastowo, 2019/03/20
- Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?, Stefan Monnier, 2019/03/20
- Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?, Tadeus Prastowo, 2019/03/20
- Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?, John Wiegley, 2019/03/20