Re: Assignment of misc packages for emacs

[Stefan Monnier]

> I'm visiting  ~/fsf/emacs/lwlib/xlwmenu.c
> On line 1625, there is a call to the function x_free_dpy_colors.
> I want find out where it is defined & used elsewhere.

Note that apart from M-x grep and M-x match there's also M-x igrep that
tries to solve the same kind of problem(s).

> I find this very easy to use; compare:
>         M-x match RET RET RET M-DEL RET
> to using e.g
>         M-x grep-find RET x_free_dpy_colors RET

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 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.

> >     As a result, it presents a buffer with all the matching lines [like
> >     M-x grep does], but it has a command set which is specifically
> >     tailored to navigating through the matches, e.g.
> > 
> >     SPC, n - shows the next match in the other window (but keeps the match
> >     buffer active).  It temporarily highlights the matching text in the
> >     other window.
> > 
> > This feature seems to be orthogonal to the command argument interface.
> 
> 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 `.

> 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).
Hmm... they don't seem to work here any more.  Maybe I messed something
up with some of my keymap.c changes.  Anyway, you can try it
on Emacs-21.2 where it still works.


        Stefan