Re: master@head: completing-read behavior change?

["T.V Raman" <raman@google.com>]

Yes, you nailed the problem. I need to update how I handle ido-exhibit
in my after advice. Thanks for the prompt help and pointer.
Dmitry Gutov writes:
 > Hi T.V.,
 > 
 > On 23.01.2020 0:42, T.V Raman wrote:
 > > Could anyone tell me what changed in the behavior of completing-read
 > > between
 > > * (HEAD detached at 561ba2633e)
 > > and HEAD on master branch?
 > 
 > I can't find the revision 561ba2633e, but it could be commit 
 > 3b0938c0420de2b845e7e8f8fbbb57ddc61718f2.
 > 
 > >  From what I observe, something low-level appears to  have changed how
 > > completing-read produces its final minibuffer prompt when ido is active.
 > 
 > The aforementioned commit changed the way Ido's suggestions are 
 > displayed: instead of being plainly 'insert'-ed, they are now an 
 > 'after-string' property on an overlay placed at the end of the prompt 
 > and input.
 > 
 >  > From emacspeak, I used to be able to speak the ido choices
 >  > intelligently, now I just get  the number of available choices spoken
 >  > -- and the code on the emacspeak end hasn't changed.
 > 
 > Does emacspeak work okay with icomplete-mode? The above is how the 
 > latter has been displaying its suggestions for some time.
 > 
 > This change has been made for better compatibility with the new way 
 > messages are displayed while minibuffer is active (they are displayed 
 > using the same mechanism). So I think emacspeak should learn to 
 > understand this kind of rendering either way.
 > 
 > Sorry for the inconvenience, though.

-- 
Id: kg:/m/0285kf1 

-- 
Id: kg:/m/0285kf1