GNU bug report logs - #39379
27.0.60; Fix for #38457 broke ido-vertical-mode

Previous Next

Full log

Message #50 received at 39379 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39379 <at> debbugs.gnu.org, wyuenho <at> gmail.com
Subject: Re: bug#39379: 27.0.60; Fix for #38457 broke ido-vertical-mode
Date: Wed, 5 Feb 2020 02:55:00 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.