|
From: | Ergus |
Subject: | Re: [PATCH] Re: Other details about completion. |
Date: | Tue, 5 Apr 2022 13:06:38 +0200 |
On Mon, Apr 04, 2022 at 08:31:24PM +0000, Philip Kaludercic wrote:
Juri Linkov <juri@linkov.net> writes:May I finally add this patch to master??I don't know, maybe Philip has no time to review your patch?Sorry about that (I was struck down with Corona for the last few days, so I forgot to respond). Either way, I don't have any objections (beyond what was discussed in bug#54374 that it might be a good idea torethink that mouse-face approach in general --
I already thought on this; it may be possible t do so using other text properties like intangible or similes so commands like next-completion may even disapear or fully simplified; but it may affect some specific use cases like using isearch in the buffer and I am pretty sure someone will complain about that, so we end up with duplicated code to support a custom to provide the legacy behavior... SO I am not sure it worth to try that (sadly).
but if change 2) solves this then the issue isn't that urgent).
On Fri, Apr 01, 2022 at 10:24:25PM +0200, Ergus wrote:Hi again... Here I attached a small patch that makes 3 small changes: 1) Remove the trailing newline in completions one-column 2) Use another condition in next-completion to jump to minibuffer. Normally next-completion with tabs at the end of the buffer needs an extra tab because it goes to the end of the last completion before jumping to the minibuffer or wrap.. That extra tab is because the condition to jump or wrap was eobp/bobp assuming that there is not text unproppertized after the last candidate. 3) Remove a comment in switch-to-completions. That comment suggested that the next-completion action must be called inside minibuffer-completion-help but IMO that is not totally correct when completion-auto-select has some of the new values. Please, if anyone could review,correct and push I would be very grateful.-- Philip Kaludercic
[Prev in Thread] | Current Thread | [Next in Thread] |