emacs-devel
[Top][All Lists]
Advanced

[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!



reply via email to

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