bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39379: 27.0.60; Fix for #38457 broke ido-vertical-mode


From: Dmitry Gutov
Subject: bug#39379: 27.0.60; Fix for #38457 broke ido-vertical-mode
Date: Wed, 5 Feb 2020 02:55:00 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 04.02.2020 18:40, Eli Zaretskii wrote:

But... the change in ido-vertical-mode is simpler still: just add an
extra argument to concat.

That's true, but AFAIU the problem is not limited to
ido-vertical-mode, it will happen whenever the string to display
starts with a newline.  Such a string is entirely legitimate, isn't
it? And the caller cannot possibly know that ido-exhibit will put the
'cursor' property on the first character of that text.  So I think it
isn't entirely reasonable to expect such callers to defend themselves
against internal implementation details of ido-exhibit.

Umm, it's ido-exhibit that calls ido-completions. And ido-completions, as defined in ido.el, never returns such strings.

Anyway, since you insist, I've pushed that change.

If we do that in ido.do, the reason why would be fairly non-obvious from
that code.

If the test for the leading newline is there, the reason is quite
obvious, and we can have a comment for those who don't know enough
about the 'cursor' property and cursor positioning.  I think the
result will more obvious than a mysterious concatenation of a blank in
ido-vertical-mode, which will need a comment explaining it as well.

Yes, ok. Although our general policy, I think, is that external packages that use questionable practices (such as redefining functions, instead of using whatever available public customization points there are) are generally left to their own devices.





reply via email to

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