[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51575: 28.0.60; Many issues with icomplete-in-buffer
From: |
Juri Linkov |
Subject: |
bug#51575: 28.0.60; Many issues with icomplete-in-buffer |
Date: |
Mon, 27 Feb 2023 20:44:23 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) |
close 51575 30.0.50
thanks
> I would like to use fido-mode in completion in-region / at-point
> contexts. I realized there is a icomplete-in-buffer flag that is
> intended to do that, at least for icomplete. So I started emacs with:
>
> (setq icomplete-in-buffer t)
> (icomplete-mode 1)
>
> But the behavior is erratic to say the best. Say I'm in *scratch* and
> want to autocomplete some symbol:
>
> 1. Doing M-<tab> once shows the icomplete menu, doing it again replaces
> the *entire* buffer contents with just the selection.
>
> 2. Sometimes only the icomplete menu is shown, sometimes the traditional
> *Completions* buffer is shown at the same time.
>
> 3. Pressing Enter doesn't select the candidate but inserts Enter.
>
> 4. If I enable fido-mode it disables and re-enables icomplete-mode but
> leaves the icomplete completion-in-region-mode-hook uninstalled,
> disregarding icomplete-in-buffer.
>
> Maybe this is a legacy option that should be made obsolete, but it's a
> pity that vanilla emacs provides so many alternatives for
> completing-read but none for completion-at-point. The current
> implementation wants to show the menu at point, this probably makes it
> more complex, but simply showing the standard minibuffer icomplete
> interface at the bottom would be a lot (like for example selectrum
> does).
Thanks for the bug report. This is fixed now in Emacs 30
for icomplete-mode and fido-mode.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#51575: 28.0.60; Many issues with icomplete-in-buffer,
Juri Linkov <=