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% certa
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 an
What about the following changes to make the capitalization in the
Options menu consistent? I can install if desired.
===File ~/menu-bar-diff=
*** menu-bar.el 10 Aug 2005 13:30:45 -0500 1.267
--- menu-bar.el 10 Aug 2005 21:40:44 -0500
the
Buffers menu when there is more than one frame. It would nicely
correlate to the "Windows" menu existing in standard GUIs, but
because so many people work with a single frame and switch between
buffers, it makes sense to stick to the menu title "buffers" and have
This change is good; please install it.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Richard Stallman wrote:
- Shouldn't this option be described in the Emacs manual?
It is.
But in a not very clear way. It says: "The variable
@code{mouse-1-click-follows-link} controls whether @kbd{Mouse-1} has
this behavior." after talking about all kinds of details, short clicks
vs
Drew Adams wrote:
> I fired up GNU Emacs 21.3.50.1 (i386-mingw-nt5.1.2600) of 2005-01-30 on
> NONIQPC and discovered that mouse-1 was now following links. Not
remembering
> the email thread about this, I looked in Emacs itself for how to turn
this
> new behavior off.
>
> I didn't find anything ab
t is.
- Should this option perhaps be added to the Options menu?
I don't think so.
- Does it perhaps make sense to add _all_ options to the Options menu that
change commonly used behavior from the previous Emacs version?
No, it is far too much. We decide these one b
on be described in the Emacs manual?
- Should this option perhaps be added to the Options menu? Maybe not, since
this that menu is best for things that you are likely to change more than
once.
- Does it perhaps make sense to add _all_ options to the Options menu that
change commonly used behavior
The case where image-mode isn't equivalent is where you use
`insert-file' to insert an image -- auto-image-file will cause the
inserted text to be covered with the image, but image-mode won't do
anything (unless the user invokes it afterwards, and then it will only
work if the i
On MS-Windows, auto-image-mode helps me view image files for which no
standard viewer comes with the OS. PPM images are a case in point.
Is the new image-mode feature a satisfactory replacement?
I think it ought to be.
If not, why not?
___
Em
What was the outcome? Can we turn `auto-compression-mode' on by default?
I don't know yet. I am trying it nowadays.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> Date: Tue, 29 Mar 2005 05:44:04 +0900
> From: Miles Bader <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org, [EMAIL PROTECTED],
> [EMAIL PROTECTED]
>
> On Mon, 28 Mar 2005 11:25:29 -0500, Richard Stallman <[EMAIL PROTECTED]>
> wrote:
> > BTW, shouldn't "image-file.el" (
On Mon, 28 Mar 2005 11:25:29 -0500, Richard Stallman <[EMAIL PROTECTED]> wrote:
> BTW, shouldn't "image-file.el" (the source file for `auto-image-mode')
> be moved to lisp/obsolete, now that image-mode is preferred?
>
> I don't know if it is totally obsolete. Does anyone think it isn't?
BTW, shouldn't "image-file.el" (the source file for `auto-image-mode')
be moved to lisp/obsolete, now that image-mode is preferred?
I don't know if it is totally obsolete. Does anyone think it isn't?
___
Emacs-devel mailing list
Emacs-devel@gn
> Can't this program just set the find-file-literally variable to t?
> That will prevent auto-compression-mode from trying to compress the
> contents
> when you save.
>
> I will see if that works.
What was the outcome? Can we turn `auto-compression-mode' on by default?
--
Juri Link
BTW, shouldn't "image-file.el" (the source file for `auto-image-mode')
be moved to lisp/obsolete, now that image-mode is preferred?
[I can move it if you like; doing that would help me test some changes
in the file addition/deletion code in my arch-CVS sync scripts... :-]
Thanks,
-Miles
--
Do n
I don't like this solution because it is too ad-hoc.
It is also local, so it won't break anything else. Please do it that
way.
But why can't `auto-mode-alist' allow to do the same?
Thanks, but this is not the time to consider changing the definition
of auto-mode-alist.
___
> So I think you should leave the function `image-mode' unchanged
> and define a new function `image-mode-maybe' which does the new job.
> Then the entries in auto-mode-alist can call `image-mode-maybe'
> and `image-mode-maybe' can conditionally call `image-mode'.
>
> Want to try it that way?
I do
Your code looks good to me, except for one point: every major mode's
symbol name should be a function that *unconditionally* switches to
that mode. You've set it up so that `image-mode' is a function that
usually switches to Image mode, but not always. That's not right.
So I think you should lea
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
Richard Stallman <[EMAIL PROTECTED]> writes:
> 2. Perhaps image-mode should be minor mode for extensions like
>.xbm and .xpm which already have associated major mode c-mode
>in auto-mode-alist.
>
> Someone else can do that.
I can't find a solution better than below.
With this
- 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
Kim proposed to remove the possibility of setting without
> saving altogether. I guess this will meet with disagreement from
> some people, but if it does get adopted, it would make this entire
> discussion completely moot. All options set through Custom or the
> Options menu would be s
his will meet with disagreement from some
people, but if it does get adopted, it would make this entire
discussion completely moot. All options set through Custom or the
Options menu would be saved, because we would have set == saved.
Sincere
ion,
I don't see that at all. Customize is involved only as far as it is a
menu entry in the "Options" menu and can be used to set options in a
different way.
This will not change at all.
> which we can not afford to re-open right now.
Correct, but
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
> That is true. However, copying the image to another buffer would only
> get you text.
Which is what would be appropriate when copying an XPM icon into a C
source file.
I see no problem here. If you prefer to copy it as text, type C-c C-c
so that you see the text, then copy it
> 3. By default this mode should be enabled for non-ascii based
>image format files like .png, .jpg. This could be achieved
>by enabling auto-image-file-mode by default and turning
>image-mode off by default for ascii based formats.
Sorry, I disagree.
- 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
do anything about it. A value which
the user saved through Custom still shows up in the Options Menu. So
"Save Options" saves exactly all options that the user can see (if he
looks at all submenus), that are not buffer local.
Sincerely,
Luc.
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 Option
is concerned, the entire current value
> of text-mode hook gets saved, not just the part mentioned in the
> Options Menu. This could easily be inappropriate. All one can do
> is hope for the better.
>
> 2. The following options get saved to the custom-set-variables form,
&g
ors case-fold-search display-time-mode
auto-compression-mode current-language-environment default-input-method
text-mode-hook.
In as far as text-mode-hook is concerned, the entire current value of
text-mode hook gets saved, not just the part mentioned in the Options
Menu. This could easily be inappro
- 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
Richard Stallman <[EMAIL PROTECTED]> writes:
> 3. By default this mode should be enabled for non-ascii based
>image format files like .png, .jpg. This could be achieved
>by enabling auto-compression-mode by default and turning
>image-mode off by default for ascii based
k
>> for it.
>
> 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 also not happy about the "Customize Emacs" menu name: it
>> implies that
has been there already in Emacs-21.1, and all the other
"Hide/View/Appearance/whatever" options concern the frame/window
layout as opposed to the windows content themselves. We already have
transient-mark-mode and show-paren-mode (which also operate _in_) the
buffer in the Options menu
to avoid
misleading users into thinking that it will save changes made inside
customize.
> I am also not happy about the "Customize Emacs" menu name: it implies
> that selecting options in the Options menu would be different from
> customizing Emacs. I'd prefer to have this
that's where people look for
> it.
That would be good.
> I am also not happy about the "Customize Emacs" menu name: it implies
> that selecting options in the Options menu would be different from
> customizing Emacs. I'd prefer to have this menu called "All
Richard Stallman <[EMAIL PROTECTED]> writes:
> If you used an overlay instead of text properties, there would be no
> necessity to modify the buffer.
>
> That is true. However, copying the image to another buffer would only
> get you text.
Which is what would be appropriate when copying
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
>
If you used an overlay instead of text properties, there would be no
necessity to modify the buffer.
That is true. However, copying the image to another buffer would only
get you text. That's why I decided to make it a text property.
___
Emac
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 r
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 adva
ght. Basically, we have the following:
a) The layout of menu bar and Options menu has _not_ significantly
changed since 21.1, so any restructuring that is not a significant
improvement will tend to make people notice/complain/whatever.
b) one of the few additions we have is the "Hide/S
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
Richard Stallman <[EMAIL PROTECTED]> writes:
> 3. By default this mode should be enabled for non-ascii based
>image format files like .png, .jpg. This could be achieved
>by enabling auto-compression-mode by default and turning
>image-mode off by default for ascii based
3. By default this mode should be enabled for non-ascii based
image format files like .png, .jpg. This could be achieved
by enabling auto-compression-mode by default and turning
image-mode off by default for ascii based formats.
I am completely lost here. What does auto-
- 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,
1 - 100 of 191 matches
Mail list logo
