[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Handle case where `beg` and `end` are strings instead of mar
From: |
James N . V . Cash |
Subject: |
Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers |
Date: |
Fri, 29 Apr 2022 13:20:07 -0400 |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> James N. V. Cash [2022-04-29 10:07:33] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> + (let ((beg (if (number-or-marker-p beg)
>>>> + beg
>>>> + (save-excursion
>>>> + (goto-char (minibuffer-prompt-end))
>>>> + (search-forward beg))))
>>>> + (end (if (number-or-marker-p end)
>>>> + end
>>>> + (save-excursion
>>>> + (goto-char (point-max))
>>>> + (search-backward end)))))
>>>
>>> What if there are several matches for `beg` and/or for `end` in
>>> the buffer? How do we know we got the intended one?
>>
>> A good question; as far as I can tell though, `beg` and `end` are only
>> strings when called via `choose-completion` in `simple.el`, when it
>> passes in `base-affixes`. `base-affixes` is in turn set to
>> `completion-base-affixes`, which gets set in
>> `minibuffer-completion-help`. There, the value that becomes `beg` is
>> `(buffer-substring (minibuffer--completion-prompt-end) (+ start base-size))`
>> and `end` is `(buffer-substring (point) (point-max))`, so I think that
>> changing
>> `minibuffer-prompt-end` in my patch to
>> `minibuffer--completion-prompt-end` would suffice to ensure that it is
>> always matching from the correct point to match the intended positions.
>
> I think rather than (minibuffer--completion-prompt-end) and (point-max),
> we should be using "the beginning of the completion area" and "the end
> of the completion area". In a typical minibuffer completion, that's
> exactly the same, but in `completing-read-multiple` or
> `complete-in-region` the difference can be significant.
In the `completing-read-multiple` case, the `beg` is going to be the
previous completions, so I think this is exactly finding the completion
area (it also seems that `minibuffer--completion-prompt-end` is the same
value as `minibuffer-prompt-end,` it just also raises an error).
In my brief experimentation, it appears `complete-in-region` receives
`beg` and `end` as numbers, so it doesn't go through this searching
stuff at all.
James
- [PATCH] Handle case where `beg` and `end` are strings instead of markers, James N. V. Cash, 2022/04/28
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, James N . V . Cash, 2022/04/28
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, Juri Linkov, 2022/04/29
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, James N . V . Cash, 2022/04/29
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, Stefan Monnier, 2022/04/29
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, James N . V . Cash, 2022/04/29
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, Stefan Monnier, 2022/04/29
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers,
James N . V . Cash <=
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, Juri Linkov, 2022/04/29
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, Stefan Monnier, 2022/04/29
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, James N . V . Cash, 2022/04/30
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, Stefan Monnier, 2022/04/30
- Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers, James N . V . Cash, 2022/04/30