> (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
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
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
_
Richard Stallman <[EMAIL PROTECTED]> writes:
> I think this is a tempest in a teapot, and I wish people
> would drop this subject and move on to fixing some of the bugs
> that have recently been reported.
Just FYI, Drew took this off-list with a few people copied, and
basically he and I seemed to
I think this is a tempest in a teapot, and I wish people
would drop this subject and move on to fixing some of the bugs
that have recently been reported.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
- Original Message -
From: "David Kastrup" <[EMAIL PROTECTED]>
> We need to marry the current, unchanged Customize with the menus in
> the best manner for Emacs-22.1.
>
> The future Customize is irrelevant.
Agree.
___
Emacs-devel mailing lis
Some get saved if they were set through the menu
bar _or_ through Custom. (There does not seem to be too much we can
do about that right now.
This behavior is not wrong. We should not "do anything" about it.
Without storing more stuff in property
lists, Emacs can not dis
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>> which we can not afford to re-open right now.
>
>Correct, but I don't see how it would be relevant.
>
> Several ways. For instance, in that discussion I believe I remember
> that Kim proposed to remove the possibility o
David Kastrup wrote:
> which we can not afford to re-open right now.
Correct, but I don't see how it would be relevant.
Several ways. For instance, in that discussion I believe I remember
that Kim proposed to remove the possibility of setting without saving
altogether. I guess this will
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Lennart Borgman wrote:
>
>> As I mentioned before, I think the sanest way would be to have
>> "Save Options" prompt "Options have been set by Customize.
>> Save them too?"
>
>Agree. This would be much less surprising than the current
>
Lennart Borgman wrote:
> As I mentioned before, I think the sanest way would be to have "Save
> Options" prompt "Options have been set by Customize. Save them too?"
Agree. This would be much less surprising than the current situation and as
far as I remember our discussions it would
- Original Message -
From: "David Kastrup" <[EMAIL PROTECTED]>
> As I mentioned before, I think the sanest way would be to have "Save
> Options" prompt "Options have been set by Customize. Save them too?"
Agree. This would be much less surprising than the current situation and as
far as
>From my previous message:
Some get saved if they were set through the menu
bar _or_ through Custom. (There does not seem to be too much we can
do about that right now. Without storing more stuff in property
lists, Emacs can not distinguish.)
Even so, we might not _want_ to do an
But the problem here are things like:
If nobody objects in the next day or so, I volunteer to install these
two changes
Yes, exactly. No one should EVER wait less than 2 days for such
responses.
___
Emacs-devel mailing list
Emacs-de
I sometimes wish that we had
appointed or elected "dictators" for specific subsystems of Emacs:
We do, for many parts. For instance, Handa is in charge of Mule
issues and mostly decides them on his own. But there are parts
that nobody wants to take special responsibility for.
David Kastrup wrote:
Well, that assessment of the situation certainly sounds like
qualifying for the "bug fixes" department even before the release, and
I don't think it can be considered adequately addressed in
release-quality merely by having the "Save Options" menu entry appear
a
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Lennart Borgman wrote:
>
>3) Choose menu "Save Options".
>
>What happens on your computer? On my computer debug-on-error is
>saved as far as I can see.
>
> If I understood the code in menu-bar.el correctly (I did not try out
> anything), then
Lennart Borgman wrote:
3) Choose menu "Save Options".
What happens on your computer? On my computer debug-on-error is saved as far
as I can see.
If I understood the code in menu-bar.el correctly (I did not try out
anything), then an oversimplified description of the situation if you
cho
- Original Message -
From: "Jason Rumney" <[EMAIL PROTECTED]>
> I think the reason to put it above "Customize Emacs" is to avoid
> misleading users into thinking that it will save changes made inside
> customize.
I am beginning to feel dizzy. Do you mean something like this:
1) M-x cust
On Sun, 20 Mar 2005 17:26:02 +0100, David Kastrup <[EMAIL PROTECTED]> wrote:
> b) one of the few additions we have is the "Hide/Show" menu. It
> appears that similar functionality is available in other applications
> as a top-level menu "View". There has pretty much consent on the list
> that thi
Jason Rumney <[EMAIL PROTECTED]> writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> Since I have stared now at the current menus for 21.4 and 22.x for
>> longer than probably ever previously, I would like to mention one
>> other thing that has struck me as standing out negatively, and this
>
"Lennart Borgman" <[EMAIL PROTECTED]> writes:
>> "global-font-lock-mode" which we now present as "Syntax
>> Highlighting".
>
> Can this go into "Appearance" too please. A shorter structured menu
> makes it easier for users.
It has been there already in Emacs-21.1, and all the other
"Hide/View/App
David Kastrup <[EMAIL PROTECTED]> writes:
> Since I have stared now at the current menus for 21.4 and 22.x for
> longer than probably ever previously, I would like to mention one
> other thing that has struck me as standing out negatively, and this
> _would_ be a change with regard to 21.4: I'd sw
- Original Message -
From: "David Kastrup" <[EMAIL PROTECTED]>
> It has been proposed to rather name this menu "Appearance" since
Agree.
> c) The option blink-cursor-mode has been put into the top level of the
...
> a) naming the current "Hide/Show" (which has not yet been released
>
Luc Teirlinck <[EMAIL PROTECTED]> writes:
>Of course Richard fills in some of that space,
>
> Of course.
>
>but given his intermittent access and numerous other chores,
>
> But the problem here are things like:
>
>If nobody objects in the next day or so, I volunteer to install these
>
Of course Richard fills in some of that space,
Of course.
but given his intermittent access and numerous other chores,
But the problem here are things like:
If nobody objects in the next day or so, I volunteer to install these
two changes
If you were willing to wait at least two da
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>Since both of these suggestions would be a change with regard
>to 21.4, if there is any contention about them (except maybe for
>better proposals for the "All Options" menu), we should rather drop
>them instead of
David Kastrup wrote:
Since both of these suggestions would be a change with regard
to 21.4, if there is any contention about them (except maybe for
better proposals for the "All Options" menu), we should rather drop
them instead of wasting time discussing them, if the advantages are
Richard Stallman <[EMAIL PROTECTED]> writes:
> I don't want to rethink the Emacs menu bar now.
> It would be a big argument. Let's not have the argument.
>
> People, when someone starts a discussion about a substantial change
> in Emacs, please don't argue about the details. If you disagree
> wi
I don't want to rethink the Emacs menu bar now.
It would be a big argument. Let's not have the argument.
People, when someone starts a discussion about a substantial change in
Emacs, please don't argue about the details. If you disagree with the
idea, please just say that this is the wrong time
- Original Message -
From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> These are all either toggle-type options (we have most of them under
> Options->Show/Hide) or text/font options (we have them under
> Edit->Text Properties). To dedicate a whole top-level item to them
> sounds unwise.
Yes,
> From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Cc:
> Date: Sat, 19 Mar 2005 16:51:55 +0100
>
> I think that "View" here mostly is a synonym for "Appearance". In for
> example Firefox View menu the main items are:
>
> Toolbars, Status Bar, Sidebars;
> Stop, Reload;
> Text Size, Page
"Lennart Borgman" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Eli Zaretskii" <[EMAIL PROTECTED]>
>
>> > Most applications I use on w32 have a "View" top menu.
>>
>> This was considered when the menu bar was restructured in preparation
>> for Emacs 21.1. The conclusion, II
- Original Message -
From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> > Most applications I use on w32 have a "View" top menu.
>
> This was considered when the menu bar was restructured in preparation
> for Emacs 21.1. The conclusion, IIRC, was that View is generally
> inappropriate in a text
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> Cc: "Lennart Borgman" <[EMAIL PROTECTED]>,
>>emacs-devel@gnu.org
>> From: David Kastrup <[EMAIL PROTECTED]>
>> Date: Sat, 19 Mar 2005 12:24:34 +0100
>>
>> > When Emacs 21.1 was released, many users complained about the
>> > changed menu-bar s
> Cc: "Lennart Borgman" <[EMAIL PROTECTED]>,
> emacs-devel@gnu.org
> From: David Kastrup <[EMAIL PROTECTED]>
> Date: Sat, 19 Mar 2005 12:24:34 +0100
>
> > When Emacs 21.1 was released, many users complained about the
> > changed menu-bar structure, even though the new structure was
> > gen
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> From: "Lennart Borgman" <[EMAIL PROTECTED]>
>> Date: Fri, 18 Mar 2005 23:56:02 +0100
>> Cc: emacs-devel@gnu.org
>
>> My gut also tells me it is unlikely that we will have a "View" top
>> menu now. However an "Appearance" sub menu with the same conten
> From: "Drew Adams" <[EMAIL PROTECTED]>
> Cc:
> Date: Fri, 18 Mar 2005 12:53:29 -0800
>
> Please don't make such a change: the simple toggle-type options should
> come first, and the submenus (like Mule) later. Not the other way
> around. Likewise with Customize: it should come aft
> From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Date: Fri, 18 Mar 2005 23:56:02 +0100
> Cc: emacs-devel@gnu.org
>
> Most applications I use on w32 have a "View" top menu.
This was considered when the menu bar was restructured in preparation
for Emacs 21.1. The conclusion, IIRC, was that View is
I suggest to rearrange it slightly to make the structure
more logical and useful, by placing frequently used
items at the top and "one-time" customizations later.
People, please let's NOT have a long discussion of whether to do this.
Kim, could you look at what people have already said
- Original Message -
From: "David Kastrup" <[EMAIL PROTECTED]>
> Looks like a candidate for "Appearance". Appearance could be
> structured into overall appearance (frame stuff, cursor, menubar,
> toolbar, speedbar) and detailed appearance (dirnames in buffers, file
> name shadow, syntax
> From: "Drew Adams" <[EMAIL PROTECTED]>
> Date: Fri, 18 Mar 2005 07:48:49 -0800
>
> OPTIONS
> ==
> 1 Customize Emacs >
> --
> 2 Language Environment (Mule
> From: "Drew Adams" <[EMAIL PROTECTED]>
> Date: Fri, 18 Mar 2005 07:48:49 -0800
>
> OPTIONS
> ==
> 1 Customize Emacs >
> --
> 2 Language Environment (Mule) >
> 3 Set Font/fon
OPTIONS
==1 Customize
Emacs
> --2 Language Environment
(Mule) >3 Set
Font/fontset
--4
Show/Hide
>5
> I don't think putting submenus at the top is a good idea, since the
> usual menu semantics imply that some of those menus tend to open in
> the process of trying to select options below them.
Another annoying aspect is that the submenus will open up while navigating
the menus with the left/right
David Kastrup <[EMAIL PROTECTED]> writes:
>> OPTIONS
>> ==
>>Customize Emacs >
>> --
>>Language Environment (Mule) >
>>Set Font/fontset
>> --
>
> I don't
[EMAIL PROTECTED] (Kim F. Storm) writes:
> With the recent addition of "blinking cursor" to the options
> menu, it has become even more dis-organized than before.
>
>
> I suggest to rearrange it slightly to make the structure
> more logical and useful, by placing frequently used
> items at the top
86 matches
Mail list logo
