[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Support "\n" in icomplete-separator
From: |
Andrii Kolomoiets |
Subject: |
Re: [PATCH] Support "\n" in icomplete-separator |
Date: |
Fri, 13 Nov 2020 22:18:58 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin) |
Eli Zaretskii <eliz@gnu.org> writes:
> We are not talking about the default completion in this thread, we are
> talking about icomplete-mode and its ilk. They work differently, and
> in particular do show completion candidates automatically in the
> minibuffer.
>
>> > Without seeing the possible answers, what are your chances of knowing
>> > what to type?
>>
>> Chances are pretty good: I'll press TAB to see the *Completions* buffer.
>
> Pressing TAB seems to be against the philosophy of icomplete, ivy, and
> similar features, at least AFAIU: they display the candidates without
> any prior request by the user.
Among icomplete, ivy and ido modes only ivy is overriding TAB key. With
icomplete and ido the overlay text is not the _only_ way of knowing what
inputs are acceptable. Seems like they has nothing against using TAB to
complete text.
>> Oh, in this case let's try even simpler approach: show as much text
>> before point as possible.
>
> What is "this case"? If "this case" is limited to echo-area display,
> then it cannot be shared with minibuffer display. If you mean both
> use cases, then "displaying as much as possible before point" will
> yield sub-optimal results for minibuffer input, when some text is
> displayed after point, whether as an aoverlay string or not.
I agree.
>> > The conclusion, IMO, is that the application should tell the display
>> > engine how it wants to display the stuff in the mini-window in the
>> > "unusual" cases, where the default strategy produces sub-optimal
>> > results.
>>
>> I see many applications are trying their best to fit the text into the
>> miniwindow. Can the display strategy be changed to display the
>> beginning of the text by default?
>
> We can do that, but I don't think it would be TRT, because the current
> strategy does work in many use cases. I thin a better way is to let
> applications control this aspect of the behavior, because we will
> never be able to find a solution that always works, what with all the
> different settings and kinds of display in the mini-window.
Got it. Looking forward for usable tool to let applications control the
display behavior.
Thanks!
- Re: [PATCH] Support "\n" in icomplete-separator, (continued)
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Stefan Monnier, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/17
- Re: [PATCH] Support "\n" in icomplete-separator, Stefan Monnier, 2020/11/17
- Re: [PATCH] Support "\n" in icomplete-separator, Andrii Kolomoiets, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/17
- Re: [PATCH] Support "\n" in icomplete-separator,
Andrii Kolomoiets <=
- Re: [PATCH] Support "\n" in icomplete-separator, Ergus, 2020/11/14
- Re: [PATCH] Support "\n" in icomplete-separator, Andrii Kolomoiets, 2020/11/14
- Re: [PATCH] Support "\n" in icomplete-separator, Ergus, 2020/11/14
- Re: [PATCH] Support "\n" in icomplete-separator, Andrii Kolomoiets, 2020/11/15
- Re: [PATCH] Support "\n" in icomplete-separator, Stefan Monnier, 2020/11/10
Re: [PATCH] Support "\n" in icomplete-separator, Jean Louis, 2020/11/06