master@head: completing-read behavior change?

master@head: completing-read behavior change?

[T.V Raman]

Could anyone tell me what changed in the behavior of completing-read
between
* (HEAD detached at 561ba2633e)
and HEAD on master branch?

From what I observe, something low-level appears to  have changed how
completing-read produces its final minibuffer prompt when ido is active.

Background:

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. 
-- 
Id: kg:/m/0285kf1 

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

[Dmitry Gutov]

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.

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

[T.V Raman]

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 

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

[T.V Raman]

P.S. I also see that ido-exhibit now dropped the line that used to
crete/delete overlays -- so I am a bit confused.

Where is the overlay stored (ie var name)
-- 
Id: kg:/m/0285kf1 

-- 
Id: kg:/m/0285kf1 

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 

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

[T.V Raman]

Fix is here for the curious:-)
https://github.com/tvraman/emacspeak/blob/master/lisp/emacspeak-ido.el#L85
T.V Raman writes:
 > 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 

-- 
Id: kg:/m/0285kf1 

-- 
Id: kg:/m/0285kf1 

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

[Dmitry Gutov]

Hi T.V.,

On 23.01.2020 3:03, T.V Raman wrote:
> Fix is here for the curious:-)
> https://github.com/tvraman/emacspeak/blob/master/lisp/emacspeak-ido.el#L85

You haven't answered my question about support for icomplete-mode. Do 
you only support Ido?

I'm happy you made it work, but I think it would be better to handle the 
general approach. Meaning, instead of hardcoding the names of (private) 
variables, scan the minibuffer, look for the overlays with after-string, 
order by 'priority', and read their contents one after another.

The new set-minibuffer-message feature uses the same approach if 
minibuffer is active. Although, in that case, you could advise this 
function, or set an alternative handler via the set-message-function 
variable (also just added in Emacs 27).

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

[T.V Raman]

Dmitry Gutov <dgutov@yandex.ru> writes:

will check icomplete when I have time, I frankly dont remember any more
whether I handle it. What would be a simple test usage for icomplete? I
have ido, flx-ido and ido-ubiquitous (can never remember its new name)
active, so as you can guess my emacs world is complex.> Hi T.V.,
>
> On 23.01.2020 3:03, T.V Raman wrote:
>> Fix is here for the curious:-)
>> https://github.com/tvraman/emacspeak/blob/master/lisp/emacspeak-ido.el#L85
>
> You haven't answered my question about support for icomplete-mode. Do
> you only support Ido?
>
> I'm happy you made it work, but I think it would be better to handle
> the general approach. Meaning, instead of hardcoding the names of
> (private) variables, scan the minibuffer, look for the overlays with
> after-string, order by 'priority', and read their contents one after
> another.
>
> The new set-minibuffer-message feature uses the same approach if
> minibuffer is active. Although, in that case, you could advise this 
> function, or set an alternative handler via the set-message-function
> variable (also just added in Emacs 27).
>

-- 

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

[Dmitry Gutov]

On 23.01.2020 17:44, T.V Raman wrote:
> What would be a simple test usage for icomplete?

emacs -Q
M-x icomplete-mode (or M-x fido-mode, slightly different behavior)
C-h f (or some other command that triggers completing-read)

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

[T.V Raman]

I just checked, emacspeak doesn't have explicit code for
icomplete. That said, I'll implement the more general approach you
suggest at some point -- likely by creating an Emacspeak-specific
minibuffer-contents equivalent. Is there some generic test I can use
to spot the new pattern vs old?
Dmitry Gutov writes:
 > Hi T.V.,
 > 
 > On 23.01.2020 3:03, T.V Raman wrote:
 > > Fix is here for the curious:-)
 > > https://github.com/tvraman/emacspeak/blob/master/lisp/emacspeak-ido.el#L85
 > 
 > You haven't answered my question about support for icomplete-mode. Do 
 > you only support Ido?
 > 
 > I'm happy you made it work, but I think it would be better to handle the 
 > general approach. Meaning, instead of hardcoding the names of (private) 
 > variables, scan the minibuffer, look for the overlays with after-string, 
 > order by 'priority', and read their contents one after another.
 > 
 > The new set-minibuffer-message feature uses the same approach if 
 > minibuffer is active. Although, in that case, you could advise this 
 > function, or set an alternative handler via the set-message-function 
 > variable (also just added in Emacs 27).

-- 
Id: kg:/m/0285kf1 

-- 
Id: kg:/m/0285kf1 

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

[Dmitry Gutov]

On 23.01.2020 19:45, T.V Raman wrote:
> Is there some generic test I can use
> to spot the new pattern vs old?

Well, set-minibuffer-message is a new function. You can check if with 
fboundp.

Or just compare Emacs version against 27 (that will fail for some old 
snapshot builds, but they should update anyway).