I'd suggest to add the Message-ID (maybe in addition to sender and
date).
That is feasible.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> (Would you want to find the URLs for me?)
Given the date and the Subject, it should be very easy to do that,
using the mail-archive Search command.
For me, this is not merely hard, but impossible. I do my work without
internet access, most of the time.
___
I have no idea if this will work without some non-trivial re-shuffling
of the code in x-popup-menu. Just looking at the source, it seems to
invoke functions that need X (or its emulation). Someone will have to
work on refactoring the code before we can do what you suggest.
The fo
> From: "Richard M. Stallman" <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
> Date: Sun, 11 Sep 2005 02:54:10 -0400
>
> (Would you want to find the URLs for me?)
Given the date and the Subject, it should be very easy to do that,
using the mail-archive Search
> From: "Richard M. Stallman" <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED], emacs-devel@gnu.org
> Date: Sun, 11 Sep 2005 02:54:00 -0400
>
> I see no reason to duplicate this code. If x-popup-menu can operate
> at run time, for this limited purpose, wit
On Sun, Sep 11 2005, Richard M. Stallman wrote:
> > In ChangeLog it can be useful to mention the date and sender of the
> > bug report. That would be brief, but enough to find the discussion
> > straightforwardly.
>
> If the discussion was in a public mailing list, a URL of the me
I don't think it's right to compile and link in xmenu.c on platforms
where menus are not supported on the C level. If we want to show
keyboard equivalents in tmm, we should find another way of gleaning
them, without calling x-popup-menu.
I see no reason to duplicate this code. If
> In ChangeLog it can be useful to mention the date and sender of the
> bug report. That would be brief, but enough to find the discussion
> straightforwardly.
If the discussion was in a public mailing list, a URL of the message
that started the thread would IMHO be a better w
> Date: Sat, 10 Sep 2005 12:28:09 +0300
> From: Eli Zaretskii <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> > However you have missed some references to menu-updating-frame. For example
> > F10->f doesn't work beacuse of:
> >
> > (put 'dired 'menu-enable
> > '(not (wi
> Date: Sat, 10 Sep 2005 09:08:40 +0900
> From: YAMAMOTO Mitsuharu <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
>
> Besides menu-updating-frame, tmm.el uses x-popup-menu (defined in
> xmenu.c) in order to obtain keyboard equivalents.
>
>(conditio
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Sat, 10 Sep 2005 11:07:25 +1200
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> xmenu.c compiles without X libraries (--without-x doesn't link to them)
What you say is not detailed enough, because xmenu.c has 2 different
parts (one with USE_X_TOOL
> From: "Richard M. Stallman" <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
> emacs-devel@gnu.org
> Date: Sat, 10 Sep 2005 04:14:23 -0400
>
> In ChangeLog it can be useful to mention the date and sender of the
> bug report. That would be brief, but enoug
You can replace the deleted code with the comment (of course, only if the
location of the comment makes sense: if you delete a whole function at the
toplevel, replacing it with a toplevel comment won't be much help), or you
can put the info in the ChangeLog.
It's a fundamental p
> On Fri, 09 Sep 2005 16:46:25 +0300, Eli Zaretskii <[EMAIL PROTECTED]>
> said:
> The problem is indeed that this change caused the menus to reference
> menu-updating-frame, which is not defined in the non-X version.
Besides menu-updating-frame, tmm.el uses x-popup-menu (defined in
xmenu
> On Fri, 09 Sep 2005 21:18:45 +0300, Eli Zaretskii <[EMAIL PROTECTED]>
> said:
>> Of course, the better solution would be to merge xmenu.c and
>> macmenu.c.
> Agreed. If that's possible, of course (I see that both w32menu.c
> and macmenu.c hold quite a lot of code).
The current macmen
> HAVE_MENUS means menu support on the C level. tmm doesn't do that, it
> _emulates_ menus on the Lisp level.
OK. I see now.
> > However, xmenu.c _does_ compile without
> > X11 headers and libraries, otherwise you couldn't make a non-X build with
> > it.
>
> If the headers and libraries
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Fri, 09 Sep 2005 14:12:04 -0400
>
> > The result of all this was that xmenu.o was being linked in both in
> > the X and in the non-X branches, and in both cases it was conditioned
>
> The result of all this was that xmenu.o was being linked in both in
> the X and in the non-X branches, and in both cases it was conditioned
> on HAVE_MENUS being defined and HAVE_CARBON not being defined (because
> Carbon uses macmenu.o instead).
Of course, the better solution would be to merge
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
> From: David Kastrup <[EMAIL PROTECTED]>
> Date: Fri, 09 Sep 2005 17:47:35 +0200
>
> > I installed a change that avoids referencing that variable on
> > non-multiframe displays. Ismail, please check that the new version
> > works
Eli Zaretskii <[EMAIL PROTECTED]> writes:
> The problem is indeed that this change caused the menus to reference
> menu-updating-frame, which is not defined in the non-X version.
>
> I installed a change that avoids referencing that variable on
> non-multiframe displays. Ismail, please check that
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Sat, 10 Sep 2005 01:12:41 +1200
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> > I think the non-X build on Unix and GNU systems doesn't define
> > HAVE_MENUS for a reason: without the proper X11 headers and libraries,
> > xmenu.c simply will n
> Date: Fri, 09 Sep 2005 14:50:55 +0300
> From: Eli Zaretskii <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> My interim conclusion is that the changes back in 2004 were not the
> one that caused the current problem. I will dig some more to
> understand what is the real cause
>> Let's take it as a reminder that when we commit a fix, we should make sure
>> we describe the bug it fixes, either in comments in the code (when
>> possible/meaningful) or in the ChangeLog entry.
> Alas, there's no machinery in GNU coding/development standards to
> record such information. In
Eli Zaretskii writes:
> Now, your suggested change simply moves the first instance of xmenu.o
> outside the X branch and also outside the HAVE_MENUS condition (and
> does nothing for the second instance, btw).
I think the second instance could be removed.
> Why is that the right thing?
It
> Date: Thu, 08 Sep 2005 22:33:45 +0300
> From: Eli Zaretskii <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> > > That change was made for a reason as well: some problem on Carbon. We
> > > need to understand that problem, to be sure your change will not
> > > reintroduce
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
> emacs-devel@gnu.org
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Thu, 08 Sep 2005 17:02:05 -0400
>
> Let's take it as a reminder that when we commit a fix, we should make sure
> we describe the bug it fixes, either in
>> Perhaps the best way to find out what the bug was is to revert the
>> change; then someone will see that bug again, and someone can write a
>> new fix for it.
> No, this is IMHO a bad way: the chances of that someone to see that
> bug could be small, depending on what was the configuration in w
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Thu, 8 Sep 2005 16:24:50 +1200
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> > > I think this is the right fix.
> >
> > Please describe the reasons why you think this is the right fix.
>
> menu-updating-buffers is defined in syms_of_xmenu ()
Perşembe 08 Eylül 2005 01:04 tarihinde şunları yazmıştınız:
> > Please don't take out this change without understanding what it was
> > fixing in the first place.
>
> I think this is the right fix. Actually I think the problem was caused by
> Kim's change:
>
Your patch fixes the problem for me.
but xmenu.c is more general than that and compiles without X. Even its
name is misleading (as with xdisp.c which also compiles without X).
When I made the file name xdisp.c, I had not yet heard about X Windows.
I put in that file the code for the guts of display that I had rewritten.
__
> > I think this is the right fix.
>
> Please describe the reasons why you think this is the right fix.
menu-updating-buffers is defined in syms_of_xmenu (). Currently syms_of_xmenu
is only called in emacs.c if HAVE_MENUS is true. menu-updating-buffers is
needed even if Emacs is configured w
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Thu, 8 Sep 2005 10:04:25 +1200
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> > Please don't take out this change without understanding what it was
> > fixing in the first place.
>
> I think this is the right fix.
Please describe the reasons w
> From: "Richard M. Stallman" <[EMAIL PROTECTED]>
> Date: Wed, 07 Sep 2005 22:41:46 -0400
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> Perhaps the best way to find out what the bug was is to revert the
> change; then someone will see that bug again, and someone can write a
> new fix for it.
N
It seems to be due to this change:
2004-03-13 Eli Zaretskii <[EMAIL PROTECTED]>
* emacs.c (main): Call syms_of_xmenu only if HAVE_MENUS is defined.
I guess it hasn't been noticed before because, although people may use tmm,
most use a version of Emacs thats compiled
> Please don't take out this change without understanding what it was
> fixing in the first place.
I think this is the right fix. Actually I think the problem was caused by
Kim's change:
2004-03-11 Kim F. Storm <[EMAIL PROTECTED]>
* Makefile.in:...
(XMENU_OBJ) [HAVE_MENUS]:
> > > Is there a way to fix this for non-X users of emacs ?
If you have the X libraries you can compile with X and use it in terminal
mode (emacs -nw).
> > Sorry, I don't understand: what is that ``this'' which you want to be
> > fixed? If that's the tmm problem, it _will_ be fixed, we just n
> From: =?utf-8?q?=C4=B0smail_D=C3=B6nmez?= <[EMAIL PROTECTED]>
> Date: Wed, 7 Sep 2005 17:58:09 +0300
>
> > I don't remember the details (you will probably find them in
> > emacs-devel or emacs-pretest-bug archives for that period of time),
> > but there was some build failure, I think on MacOS,
Çarşamba 07 Eylül 2005 21:04 tarihinde, Eli Zaretskii şunları yazmıştı:
> > From: =?utf-8?q?=C4=B0smail_D=C3=B6nmez?= <[EMAIL PROTECTED]>
> > Date: Wed, 7 Sep 2005 17:58:09 +0300
> >
> > > I don't remember the details (you will probably find them in
> > > emacs-devel or emacs-pretest-bug archives
Çarşamba 07 Eylül 2005 07:16 tarihinde, Eli Zaretskii şunları yazmıştı:
> > From: Nick Roberts <[EMAIL PROTECTED]>
> > Date: Wed, 7 Sep 2005 11:01:27 +1200
> > Cc: emacs-devel@gnu.org
> >
> > It seems to be due to this change:
> >
> > 2004-03-13 Eli Zaretskii <[EMAIL PROTECTED]>
> >
> > * em
> From: Nick Roberts <[EMAIL PROTECTED]>
> Date: Wed, 7 Sep 2005 11:01:27 +1200
> Cc: emacs-devel@gnu.org
>
> It seems to be due to this change:
>
> 2004-03-13 Eli Zaretskii <[EMAIL PROTECTED]>
>
> * emacs.c (main): Call syms_of_xmenu only if HAVE_MENUS is defined.
>
> I guess it hasn't
Salı 06 Eylül 2005 23:45 tarihinde, Nick Roberts şunları yazmıştı:
> M-x report-emacs-bug
Here it goes :
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translator
> Options menu no longer works with emacs from CVS. To reproduce open emacs
> press F10->O and you get :
>
> Symbol's value as variable is void: menu-updating-frame
>
> Looks like recent changes to lisp/menu-bar.el borked this though I am not
> 100% certain with that. So wondering if anyo
Salı 06 Eylül 2005 20:15 tarihinde şunları yazmıştınız:
> You might try a bootstrap build. I had problems like this when I attempted
> to build otherwise.
A clean CVS checkout compiled with make bootstrap is showing the same problem.
Regards,
ismail
_
Hi all,
Options menu no longer works with emacs from CVS. To reproduce open emacs
press F10->O and you get :
Symbol's value as variable is void: menu-updating-frame
Looks like recent changes to lisp/menu-bar.el borked this though I am not 100%
certain with that. So wondering if anyone can repr
46 matches
Mail list logo