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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 39379@debbugs.gnu.org, wyuenho@gmail.com
> From: Dmitry Gutov <dgutov@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.