unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: New easymenu behavior
Date: Wed, 03 Nov 2004 13:13:44 +0100	[thread overview]
Message-ID: <x57jp3jfk7.fsf@lola.goethe.zz> (raw)
In-Reply-To: <4188C2D1.6000607@wanadoo.fr> (David Ponce's message of "Wed, 03 Nov 2004 11:36:49 +0000")

David Ponce <david.ponce@wanadoo.fr> writes:

> It appears that this change:
>
> 2004-11-02  Richard M. Stallman  <rms@gnu.org>
>
> 	* emacs-lisp/easymenu.el (easy-menu-intern):
> 	Don't downcase; rather, case-flip the first letter of each word.
>
> Introduced some incompatibility with the previous version of
> easymenu. For example, now recentf creates a new "files" entry in the
> menu bar instead of adding an entry in the "File" menu.

This change makes menu entries that differ only in case different.
For example, AUCTeX has a "Greek" and a "greek" menu.  More
importantly, it has menu entries
γ \gamma
and
Γ \Gamma
and those now get differentiated again (though their names now get
swapped).

Menus that differed only in case were already given different names in
21.3.  Smudging them together only occured because of Richard
downcasing the menu names (with easy-menu-intern) at some time during
21.4 development.

> I think I can easily fix that by using the "Files" path instead of
> the "files" one to locate the "File" menu.  Unfortunately, that
> change also broke other code I have, and probably other existing
> code that uses easymenu to locate menu items.

What does your code do that did not already break in Emacs 21.3?

> So my question: should I fix recentf or is the new easymenu behavior
> a bug?

The new behavior is certainly no bug: it is entirely easymenu's choice
what symbols to use for some menu, that's some internal decision.  I
can't rule out, however, that maybe easy-menu-intern is used in more
or less places than required, which could cause such mismatches.

Can you go into details about the usage patterns that cause this
problem?  If they do not have similar problems with Emacs-21.3
already, there might be some bug.

> What about compatibility with existing code that uses easymenu?

It should not be tampering with internals.  If your problem is not due
to that, you should provide examples of what happens.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  reply	other threads:[~2004-11-03 12:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-03 11:36 New easymenu behavior David Ponce
2004-11-03 12:13 ` David Kastrup [this message]
2004-11-03 14:04   ` David Ponce
2004-11-03 13:56     ` David Kastrup
2004-11-03 15:28       ` David Ponce
2004-11-03 14:27         ` David Kastrup
2004-11-03 15:37           ` David Ponce
2004-11-04  9:52         ` 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=x57jp3jfk7.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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).