[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: menu-bar/menu problems and label/help text purecopy guidelines

From: Lennart Borgman
Subject: Re: menu-bar/menu problems and label/help text purecopy guidelines
Date: Tue, 15 Dec 2009 00:49:24 +0100

On Mon, Dec 14, 2009 at 11:10 PM, Geek4AllSeasons
<address@hidden> wrote:
> Lennart Borgman (gmail) wrote:
>> Could you please test with an unpatched Emacs? I suspect the problem
>> may be difficult to reproduce there because the menus are harder to
>> reach from the keyboard. Or are you using the mouse?
>> According to the elisp manual purecopy does not do anything except
>> when building and dumping Emacs so it should not be the problem here,
>> see
>> In any case please try to reproduce it with an unpatched Emacs and
>> send a bug report.
> An unpatched test produced the same behavior. Binaries from
> downloaded from OurComments (unpatched) directory
> were used. That is the EmacsW32/OurComments version preceding the current
> (patched) installation. Separate unpatched binaries corresponding to the
> installed version were not present.

Ok, fine. Then we know a bit more.

> The apparent cause of the menu-bar not working differs from the prior
> description. A menu-bar mode menu includes an imenu sub-menu:
> imenu-create-index-function =semantic-create-imenu-index
> The parse directory option is on. The menu-bar problem occurs for
> buffer/files in directories containing large numbers of files, e.g.
> emacs/lisp. A message has been observed reporting that a semantic table
> entry for a file was empty. Opening each file appearing in those messages
> corrected the problem and the menu-bar was fully functional.
> It was not intended to suggest purecopy semantics are at issue. There seems
> to be a correlation between what menu label/tooltip text is and is not in
> pure storage.
> Emacs CVS purecopy()
> Use of
> purecopy
> bug#4429: purecopy calls needed for :help and in menu-bar.el

I know very little about this, but I know the elisp manual says that
purecopy only makes difference for the dumped Emacs, ie not for
libraries loaded later when you as a user runs Emacs.

> I'm using many of Drew Adams' libraries. Some make extensive changes to the
> menu-bar. Some possibly many of them don't use purecopy without problem. The
> imenu/semantic issue above produces similar/the same behavior. It is likely
> not related to purecopy since there is no problem if the directory index is
> completely loaded.
> IMO there are new implicit dependencies/requirements which library
> configurations. individually and/or in combination violate. There may not be
> a "bug" in code. What happens if a menu-map is preloaded into pure storage
> then "overlayed" with a new key-map in GC storage? In the imenu/semantic
> case are menu-map transactions atomic, kinda? Are maps always left in a
> consistent state. i.e. usable by the display front end?

No. There are some bugs there, but they are hard to nail down.

> The most significant issue is lack of error reporting. The search space is
> far too large for indirect debugging methods. I fumbled around attempting
> unsuccessfully to use Edebug and/or gdb to identify specific point(s) of
> failure. It appears the c code primitives are silently choking on related
> elisp data structures. It seems like it's time for the training wheels to
> come off and start rolling my own binaries. The lack of any visibility into
> c code is frustrating and unproductive.

The unpatched binaries are compiled with debug information so you
should be able to debug it using them.

Or perhaps you should that since there might be unforseen problems due
to that the menu code is not running in the elisp thread.
Unfortunately I know little about how to debug this, but hopefully
someone else can guide you (if you need assistance).

> I'll repeat the test with unpatched binaries and submit a bug report.

Thanks. That is very good.

> david
> --
> View this message in context: 
> Sent from the Emacs - Help mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]