Re: Navigating completions from minibuffer

[T.V Raman]

Adding emacs-devel after verifying slowness:

1. completion-at-point appears to have gotten very slow -- from memory
   in the last week (emacs built against Git @HEAD)
   The slowness is not present in a build from October 4.

   

T.V Raman writes:
 > Juri Linkov <juri@linkov.net> writes:
 > 
 > 
 > Agreed. And somewhat related and something that has been causing me
 > trouble:
 > 
 > Q: Why is completion-at-point *soo much* slower than
 > hippie-expand?
 > 
 > I tried to understand why by looking at the code for completion-at-point
 > but failed miserably.
 > 
 > Hope you could look at this since you're working on completion related
 > bits.
 > 
 > 
 > Also, how and when completions are displayed can now be controlled by
 > multiple custom knobs, but it's hard to map the combinatorial explosion
 > of the available possibilities to different user experiences without
 > trying all possible settings; a higher level overview with a couple of
 > recipes that describe common combinations would help.
 > 
 > 
 > >> everything works, now that I actually applied the complete patch:-)
 > >
 > > Thanks for confirming and for suggesting this change, now pushed.
 > >
 > > Probably we have to make RET more smart, so that when more editing
 > > was performed in the minibuffer after the completions were displayed,
 > > then to use the minibuffer contents with exit-minibuffer,
 > > not an obsolete completion candidate that remains selected.
 > >
 > 
 > -- 

-- 

--