Re: Assignment of misc packages for emacs

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

Re: M-x match --

> 
> I personally use
> 
>       C-u M-x grep RET <edit things to look like ../**/*.[ch]> RET
> 
> > The latter doesn't (easily) allow you to start the search in another
> > directory, and it finds (duplicate) matches in backup files (such as
> > xterm.c~), and IMO the prompt is _completely obscure_ unless you are a
> > UNIX shell expert...
> 
> Agreed, that's why I prefer zsh's ** construct.  I think C-u M-x grep RET
> should be more aggressive in its choice of initial command (it only
> chooses the files' extension for you the first time you invoke it).
> The reason why it's so conservative was because I wanted to install
> my code without having to convince anybody that the new behavior was better
> so I kept 100% compatibility with the old behavior.

I've never liked M-x grep for the very reason that I have to edit the command.

> 
> > > I am not sure it is worth reading the directory rather than just using
> > > the current directory.
> > This is VERY useful (I use it very often), and to use the current
> > directory, just hit RET.
> 
> I must say that I generally prefer the C-u M-x grep approach which does
> not force you into a series of questions, but just presents you with
> the "complete default" and lets you edit it to your liking.

One additional trick is that M-x match prompts you for the directory
using ido-read-directory, meaning that it is very easy to navigate to
a completely different base directory.

> > Yes, you could argue that this is a separate issue -- but I think the 
> > menu need to be efficient to get the maximum usability...
> 
> You're probably right that we should improve the compilation-mode's support
> for such browsing.  Maybe only for *grep* buffers, but maybe not.
> But that just means rebinding next-error (and previous-error) to more
> keys than just C-x `.

Right.  I'll look at the new grep code (I wasn't aware that grep had been
rewritten) as well as my own code again to see whether I can enhance the
standard code rather than add a separate package.

BTW, M-x match uses jit-lock to fontify the matches in the *Match*
buffer.  And when you visit a match, it is temporarily highlighted in
the target buffer (using an overlay).


Re: mini-menu --

> 
> > I can see the similarity in functionality, but for the simple use for
> > which it is intended, I like mine better, as it is less intrusive and
> > more similar to a keymap "with intermediate help in echo area".
> 
> I'm still not clear how it compares to HierarKey menus
> (see PCL-CVS's `d' prefix or the M-g prefix in the global map).

I wasn't aware of the HierarKey feature (it's a very well hidden "fact").

It compares almost 1:1 ... except I don't like HierarKey menus
to show the full key bindings, e.g.

  Set face: default  (M-g d), bold  (M-g b), italic  (M-g i), l = bold-italic  
(M-g l), undeline  (M-g u), Other ...  (M-g o) 

With mini-menu, this would be much simpler, e.g.

  Set face: d)efault b)old i)talic bo(l)d-italic u)ndeline o)ther ...

I guess we could hack the HierarKey menus to look like that --
then mini-menu would definitely have no purpose at all!

-- 
Kim F. Storm <address@hidden> http://www.cua.dk