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

[Geek4AllSeasons <Geek4AllSeasons@hotmail.com>]

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
emacs-from-cvs-091015.zip 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.

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.
http://old.nabble.com/Emacs-cvs-purecopy%28%29-td26245381.html#a26245381
Emacs CVS purecopy() 
http://old.nabble.com/Use-of-purecopy%28%29-td26177841.html#a26177841 Use of
purecopy 
http://old.nabble.com/bug-4429%3A-purecopy-calls-needed-for-%3Ahelp-and-in-menu-bar.el-td25441688.html#a26175618
bug#4429: purecopy calls needed for :help and in menu-bar.el 
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?

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.

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

david
-- 
View this message in context: http://old.nabble.com/menu-bar-menu-problems-and-label-help-text-purecopy-guidelines-tp26634810p26780209.html
Sent from the Emacs - Help mailing list archive at Nabble.com.