emacs-devel
[Top][All Lists]
Advanced

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

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


From: Tadeus Prastowo
Subject: Re: [pcomplete.el (pcomplete-completions-at-point)] Why max?
Date: Wed, 20 Mar 2019 12:00:13 +0100

On Wed, Mar 20, 2019 at 3:13 AM Stefan Monnier <address@hidden> wrote:
>
> > 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?

Okay, that magic word does not work.  Please try the following magic
word (I try it at commit 047c1b19353ff58d8cd45935c7b44c911b70e312):

$ emacs -Q
M-x shell
cd /tmp
mkdir ABCD\ EF\ GHIJKL
cd ABCD\ EF<tab>

The echo area shows "No match".  With my proposed fix (not yet
adjusted to the said commit, I just did C-M-x on my proposed patch),
the completion works.

The correct magic word seems to depend on the correct combinations of
the number of characters and their cases.  The occurrence of the magic
work in the wild is not rare, though, since I had hit this problem
several times till I was compelled last weekend to debug it.

What do you think the real problem is?

> > 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).

Okay, I will keep it in mind.

> > 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.  ]

Thank you very much for your information.  I will keep it in mind.

>         Stefan

--
Best regards,
Tadeus



reply via email to

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