GNU bug report logs -
#39379
27.0.60; Fix for #38457 broke ido-vertical-mode
Previous Next
Full log
Message #47 received at 39379 <at> debbugs.gnu.org (full text, mbox):
> Cc: 39379 <at> debbugs.gnu.org, wyuenho <at> gmail.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 4 Feb 2020 16:19:05 +0300
>
> On 04.02.2020 6:27, Eli Zaretskii wrote:
>
> > I think this is for ido.el to do: it is ido.el that puts the cursor on
> > the overlay string, so it is up to it to make sure the cursor can be
> > put where it puts the 'cursor' property. It's a simple change: if the
> > text to be displayed starts with a newline, prepend a SPC to it when
> > defining the after-string.
>
> 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.
> 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.
This bug report was last modified 5 years and 104 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.