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

[T.V Raman]

Found it -- ido--overlay (apologies)

I was looking at the wrong branch earlier. Now have it working in both
emacs 27 and emacs 28 
T.V Raman writes:
 > 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 

-- 
Id: kg:/m/0285kf1 

-- 
Id: kg:/m/0285kf1