unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: Emacs-Devel <emacs-devel@gnu.org>
Subject: RE: patch to imenu.el and lisp-mode.el for better menu in Lisp modes
Date: Sat, 14 Jul 2007 15:54:21 -0700	[thread overview]
Message-ID: <BNELLINCGFJLDJIKDGACEEIMCAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwv7ip2n4wm.fsf-monnier+emacs@gnu.org>

> > Below are patches to imenu.el and lisp-mode.el. They divide
> > Lisp definitions in the Index imenu into submenus.
>
> Please be careful: only the lisp-mode.el patch does what you say.
> The imenu.el one does something different.
> When you post such suggestions, please don't mix things up that way.

I thought when I posted them that both patches were necessary to provide the
submenus for Lisp. You're right that the imenu.el changes are not needed for
that.

> And clearly distinguish between bug-fixes (which are usually
> non-controversial and might even be installed without any prior
> discussion),

I didn't intend or mention any bug fixes.

Do you mean sorting the submenus prior to splitting instead of afterward? To
be honest, I don't remember why I made that change (I made it in 1999 in my
own code). I tried it both ways just now, and the only difference I can see
is that *Rescan* is placed (correctly, IMO) at the end of the menu with my
version, instead of at the beginning. I don't think that in itself was why I
made that change, but I don't remember the reason, and I can't see any other
difference now. I even compared the change to the vanilla Emacs 20 behavior
just now, but that seems no different from the Emacs 22 behavior in this
respect. Maybe I'm low on caffeine...

Unless someone has an idea why sorting prior to splitting would be
preferable, you can ignore the imenu.el patch.

> new features, and changes to existing defaults (this latter one is usually
> more sensitive so you will probably want to be more careful and make it
> clear that the rest of the suggested changes do not depend on it).

I called attention to the change in default value of `imenu-sort-function'.

Yes, the rest of the changes do not strictly depend on the default value of
`imenu-sort-function'. However, if definitions are classified by type
(submenu), then I think it makes more sense to sort the names.

The change in default value affects more than just Lisp buffers, but I think
it still makes sense for the default behavior to sort index entries. That
might also encourage implementors of `imenu-generic-expression' for other
languages to classify definitions into submenus.

Let me withdraw the imenu.el patch, unless someone sees a good reason to
sort before splitting, and instead propose only that we change the default
value of `imenu-sort-function' from nil (no sorting) to
`imenu--sort-by-name'.

I also think it would be a good idea to add a command to toggle sorting (and
add it to the menu, like *Rescan*), but you can ignore that too.

Another change we might like to make is to the default value of
`emacs-lisp-mode-hook'. Instead of nil, I'd propose
(imenu-add-menubar-index). I'm not sure how many users will look to
customizing the mode hook to find that they can easily have an index menu
that helps them access definitions.

Thanks for making me look at the patches a little closer.

  reply	other threads:[~2007-07-14 22:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-14 15:28 patch to imenu.el and lisp-mode.el for better menu in Lisp modes Drew Adams
2007-07-14 19:51 ` Stefan Monnier
2007-07-14 22:54   ` Drew Adams [this message]
2007-07-14 22:33 ` Richard Stallman
2007-07-14 22:33 ` Richard Stallman
2007-07-14 23:02   ` Drew Adams
2007-07-15 22:54     ` Richard Stallman
2007-07-16  0:39       ` Drew Adams
2007-07-17  3:35         ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BNELLINCGFJLDJIKDGACEEIMCAAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).