From: Romain Francoise [EMAIL PROTECTED]
Cc: emacs-devel@gnu.org
Date: Wed, 19 Oct 2005 22:16:01 +0200
Eli Zaretskii [EMAIL PROTECTED] writes:
First, there are some .el files that don't have a corresponding .elc
file; I think such .el file should not be compressed, since then Emacs
Cc: Eli Zaretskii [EMAIL PROTECTED], emacs-devel@gnu.org
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Wed, 19 Oct 2005 23:37:06 +0200
How can you uncompress the tarball without gunzip ?
With DJTARNT (which can only handle .tar.gz files, not compressed .gz
files in general
Cc: Romain Francoise [EMAIL PROTECTED], emacs-devel@gnu.org
From: David Kastrup [EMAIL PROTECTED]
Date: Wed, 19 Oct 2005 22:13:19 +0200
Maybe add an
make install-gzip
target?
That'd be fine, I think.
___
Emacs-devel mailing list
From: Michael Cadilhac [EMAIL PROTECTED]
Date: Thu, 20 Oct 2005 00:44:42 +0200
Cc: Stefan Monnier [EMAIL PROTECTED], emacs-devel@gnu.org
I don't know any way to change the modes of a file, or even of the
current file, within emacs.
C-h f set-file-modes RET
From: Chong Yidong [EMAIL PROTECTED]
Date: Wed, 19 Oct 2005 18:49:03 -0400
This patch fixes the bug. However, it's pure hackery since I'm not
familiar with the code at all. Can someone tell me if it makes sense
to do this?
I don't have the answer to your question, but the snippet you
From: Romain Francoise [EMAIL PROTECTED]
Date: Thu, 20 Oct 2005 09:20:06 +0200
Cc: emacs-devel@gnu.org
The long term plan is to get rid of the gzip dependency for good and use
zlib to provide decompression primitives directly in Emacs.
Then let's postpone compression of .el files until
From: Nick Roberts [EMAIL PROTECTED]
Date: Thu, 20 Oct 2005 09:38:27 +1300
pxref seems to put in a full stop in the generated info page, when the
reference includes the manual name:
(@pxref{Registers,,, gdb, The GNU debugger}) gives: (see Registers(gdb).)
which seems wrong since
From: Jason Rumney [EMAIL PROTECTED]
Date: Mon, 17 Oct 2005 22:23:04 +0100
Cc: emacs-devel@gnu.org
Bill Wohler [EMAIL PROTECTED] writes:
The lisp/Makefile.in has been changed to regenerate
mh-e/mh-loaddefs.el, but the corresponding lisp/makefile.w32-in remain
unchanged. Is that ok?
With today's CVS, GCC 3.4.2 issues the following warning:
minibuf.c: In function `Fminibuffer_completion_help':
minibuf.c:2578: warning: passing arg 2 of
`internal_with_output_to_temp_buffer' from incompatible pointer type
This happens because internal_with_output_to_temp_buffer is declared
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Thu, 20 Oct 2005 11:23:33 +0200
Cc: Lennart Borgman [EMAIL PROTECTED], emacs-devel@gnu.org
I DEFINITELY think this is a non-issue which can EASILY wait until
AFTER the release
Seconded. There's no reason to risk unneeded breakage due to this
From: Juri Linkov [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], bug-texinfo@gnu.org, emacs-devel@gnu.org
Date: Thu, 20 Oct 2005 14:16:22 +0300
makeinfo _always_ produces either a :: or a . at the end of the
@pxref cross-reference, before the closing paren, because those are
the rules of the
Cc: emacs-devel@gnu.org
From: Michael Cadilhac [EMAIL PROTECTED]
Date: Thu, 20 Oct 2005 12:41:21 +0200
If we want dired-do-chmod to work on systems without an external chmod
command, we can easily modify dired-do-chmod to use set-file-modes.
Yep, please do, but please do it with
Date: Sat, 01 Oct 2005 20:28:45 +0900
From: YAMAMOTO Mitsuharu [EMAIL PROTECTED]
At the request of the maintainer, I installed ATSUI support on Carbon
Emacs to the trunk. It does not change anything unless -DUSE_ATSUI is
specified at compile time.
Thank you for your work, but I think this
From: Andreas Schwab [EMAIL PROTECTED]
Cc: emacs-devel@gnu.org
Date: Thu, 20 Oct 2005 15:07:47 +0200
I think this is a bogus warning,
I don't agree. Fdisplay_completion_list will be called with only a single
parameter and will receive garbage in the second one. A sure way to make
From: Chong Yidong [EMAIL PROTECTED]
Date: Mon, 17 Oct 2005 17:56:39 -0400
Cc: emacs-devel@gnu.org
But I don't think this limit should be absolute. I think it should be
specified as a multiple of the frame height and width, and it should
be given as a floating point number. I'd
From: Romain Francoise [EMAIL PROTECTED]
Date: Tue, 18 Oct 2005 08:00:35 +0200
The Emacs CVS packages in Debian use compressed .el files since
September 8th and apart from the aforementioned autoload bugs, no
problem has arisen.
IMHO, Sep 8 till today is a ridiculously short period, to
From: Romain Francoise [EMAIL PROTECTED]
Date: Wed, 19 Oct 2005 09:16:25 +0200
Cc: emacs-devel@gnu.org
Richard M. Stallman [EMAIL PROTECTED] writes:
Would you like to change `make install' to compress the
.el files?
Ok, I'll do that in a few days' time in case someone objects to the
From: David Reitter [EMAIL PROTECTED]
Date: Sun, 16 Oct 2005 15:52:57 +0100
Cc: emacs-devel@gnu.org
someone might want to change the Makefile to gzip the appropriate
files on non-Windows machines.
FWIW, I find no compelling reason to do that. TUTORIAL.* files are
relatively small (circa
Date: Fri, 14 Oct 2005 13:25:57 +0200
From: LENNART BORGMAN [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
Does not compression create some difficulties for w32 users?
They need gzip to be installed. So yes, it does add a difficulty,
since stock Windows
From: Richard M. Stallman [EMAIL PROTECTED]
Date: Sun, 09 Oct 2005 14:16:40 -0400
Cc: emacs-devel@gnu.org
BTW, there is CVS/ in completion-ignored-extensions by default,
but no RCS/ and ,v. Should these extensions be added too?
I am not sure why we wanted to ignore the CVS
From: Richard M. Stallman [EMAIL PROTECTED]
Date: Wed, 28 Sep 2005 13:10:46 -0400
Cc: emacs-devel@gnu.org
if (defined_color (f, color_name, color, 0))
! gray_p = (/* Any color sufficiently close to black counts as grey. */
! (color.red 5000 color.green 5000
From: Thien-Thi Nguyen [EMAIL PROTECTED]
Date: 25 Sep 2005 17:36:45 -0400
Cc: emacs-devel@gnu.org
the top-level ChangeLog gives a hint about the practice: modify
configure.in, regenerate configure, and check in both files.
Not only configure needs to be regenerated; src/config.in is
Date: Tue, 20 Sep 2005 22:13:40 +0300
From: Eli Zaretskii [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
From: Juri Linkov [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
Date: Tue, 20 Sep 2005 08:07:09 +0300
So how about the following patch, which fixes
From: Cheng Gao [EMAIL PROTECTED]
Date: Fri, 23 Sep 2005 15:41:50 +0800
Line 209 of mac/INSTALL says:
,
| Emacs should build and run on a PowerMac running Mac OS 8.6 - 10.3.
`
With Tiger out of cage, it should be changed to
,
| Emacs should build and run on a PowerMac
From: Cheng Gao [EMAIL PROTECTED]
Date: Fri, 23 Sep 2005 15:19:54 +0800
In mac/README, line 39-41:
Binary distributions will be available in
ftp://ftp.gnu.org/gnu/mac/emacs/
But the link is wrong, and I trust there is no official Macos(x) build
in gnu.org ftp.
So maybe these
From: Juri Linkov [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
Date: Tue, 20 Sep 2005 08:07:09 +0300
So how about the following patch, which fixes the case-fold issue,
improves the doc string, and extends the valid syntax for version
numbers?
Your patch works for
Date: Tue, 20 Sep 2005 09:32:11 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
Juri Linkov wrote:
But what to do for aspell version formats not supported even with your
patch?
In particular, after applying Eli's
Date: Tue, 20 Sep 2005 15:56:46 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
Eli Zaretskii wrote:
What version is that (what is the precise version string it reports),
and of which speller?
[bash3.00.0 ~ 3 2
Date: Sat, 17 Sep 2005 09:43:59 +0900
From: YAMAMOTO Mitsuharu [EMAIL PROTECTED]
Cc: emacs-devel@gnu.org, Randal L. Schwartz merlyn@stonehenge.com
On Fri, 16 Sep 2005 23:47:23 +0300, Eli Zaretskii [EMAIL PROTECTED]
said:
Yes, please do try that. I'd like to know whether the non
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 16 Sep 2005 14:12:27 -0700
Cc: emacs-devel@gnu.org
Eli == Eli Zaretskii [EMAIL PROTECTED] writes:
Eli Thanks. Please see if the patch below causes bootstrap to work again
Eli for you.
After make clean; ./configure --prefix=/opt
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 16 Sep 2005 14:58:11 -0700
Cc: emacs-devel@gnu.org
Eli == Eli Zaretskii [EMAIL PROTECTED] writes:
And keep in mind that I could also want to build the non-carbon X11
version on OSX as well. I haven't tried that recently. Maybe I
From: Juri Linkov [EMAIL PROTECTED]
Date: Fri, 16 Sep 2005 01:01:48 +0300
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
That approach seems good to me. It will work with aspell 0.50 as
well as it would have worked with ispell.
Does anyone see a problem with that patch?
This patch
From: Juri Linkov [EMAIL PROTECTED]
Date: Fri, 16 Sep 2005 01:01:48 +0300
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
That approach seems good to me. It will work with aspell 0.50 as
well as it would have worked with ispell.
Does anyone see a problem with that patch?
This patch
From: Magnus Henoch [EMAIL PROTECTED]
Date: Tue, 13 Sep 2005 00:29:04 +0200
Eli Zaretskii [EMAIL PROTECTED] writes:
I don't know why older Aspell's are no good for us. Magnus, can you
please comment on that?
The main cause is that aspell = 0.60 consistently supports UTF-8,
which
Cc: emacs-devel@gnu.org
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 17 Sep 2005 05:34:30 -0700
Eli == Eli Zaretskii [EMAIL PROTECTED] writes:
Eli Please also make sure that tmm-menu works in both --without-x
Eli and --with-x builds, and shows the keyboard bindings for
Eli
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 15 Sep 2005 12:39:11 -0700
Is someone working on this? Here's the tail of make clean bootstrap:
Thanks.
However, this information is insufficient to fix the bug without
breaking other systems, and I don't have access to OSX to
Cc: Eli Zaretskii [EMAIL PROTECTED], emacs-devel@gnu.org,
Randal L. Schwartz merlyn@stonehenge.com
From: Steven Tamm [EMAIL PROTECTED]
Date: Fri, 16 Sep 2005 08:40:43 -0700
Reverting this change fixes the build. Just remove xmenu.o from the
Makefile and keep going.
Why
Cc: emacs-devel@gnu.org
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 16 Sep 2005 07:31:58 -0700
$ ./configure --prefix=/opt/emacs --without-x
[after much probing and printing... ]
Configured for `powerpc-apple-darwin8.2.0'.
Where should the build process find the source
Date: Fri, 16 Sep 2005 13:21:22 +0100
From: Jason Rumney [EMAIL PROTECTED]
CC: Randal L. Schwartz merlyn@stonehenge.com, emacs-devel@gnu.org
Perhaps this change has caused xmenu.c to be compiled when it shouldn't be.
2005-09-15 Richard M. Stallman [EMAIL PROTECTED]
*
Cc: Steven Tamm [EMAIL PROTECTED], Jason Rumney [EMAIL PROTECTED],
Eli Zaretskii [EMAIL PROTECTED], emacs-devel@gnu.org
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 16 Sep 2005 09:10:26 -0700
Stefan == Stefan Monnier [EMAIL PROTECTED] writes:
Stefan Otherwise calling
Cc: emacs-devel@gnu.org
From: merlyn@stonehenge.com (Randal L. Schwartz)
Date: 16 Sep 2005 09:28:00 -0700
Eli == Eli Zaretskii [EMAIL PROTECTED] writes:
Eli One more question: is HAVE_CARBON defined (probably in src/config.h)
Eli in that build?
Yes, it is. From src/config.h
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Tue, 13 Sep 2005 11:23:21 +0200
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
Shortening the file names makes it easier to be 8.3 compliant, and is
essential in the images above.
Does emacs support images on any of the 8.3 limited systems?
It
From: Stefan Monnier [EMAIL PROTECTED]
Date: Mon, 12 Sep 2005 12:22:54 -0400
Now whenever I try to run flyspell-mode (which I use pretty much
everywhere), I get the following backtrace:
Indeed, my aspell is older than 0.60, but it worked just fine until now.
It's not like Fedora Core 2
From: Stefan Monnier [EMAIL PROTECTED]
Date: Mon, 12 Sep 2005 17:37:13 -0400
Cc: emacs-devel@gnu.org
1) When is the best estimate of when 22.1 will come out?
Not before 2006.
I hope it can be done faster than that!
I hope so as well, but my best estimate is still not before 2006.
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, without a
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 command.
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 enough to find
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_TOOLKIT,
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.
(condition-case
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 (window-minibuffer
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
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 it. I hope
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
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 not compile.
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 for you.
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
on
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 (). Currently
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, which
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.
No, this is
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 why you
From: Richard M. Stallman [EMAIL PROTECTED]
Date: Tue, 06 Sep 2005 07:22:59 -0400
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
I don't think it is worth spending the time to have a long discussion
about whether to use a macro to define these commands, whether they
should be lambdas or have
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 been noticed
Cc: emacs-devel@gnu.org
From: Chong Yidong [EMAIL PROTECTED]
Date: Mon, 05 Sep 2005 18:18:18 -0400
(defun Buffer-menu-make-sort-button (column ...)
...
(propertize ...
'keymap (let ((map (make-sparse-keymap))
(fun `(lambda ()
From: Richard M. Stallman [EMAIL PROTECTED]
Date: Wed, 31 Aug 2005 10:36:53 -0400
Cc: emacs-devel@gnu.org
Right now the manual effectively takes for granted that users
know what a paragraph is. Is this a problem?
IMHO, we only need to define what's a paragraph if its Emacs
definitions
From: David Abrahams [EMAIL PROTECTED]
Date: Sun, 28 Aug 2005 04:18:57 -0400
Trying to rebuild NTEmacs today using MinGW I found that I needed to replace:
$(EMACS) $(EMACSOPT) -l autoload --eval '(setq generated-autoload-file
$(lisp)/loaddefs.el)' -f batch-update-autoloads $$wins
From: Richard M. Stallman [EMAIL PROTECTED]
Date: Fri, 26 Aug 2005 23:41:35 -0400
Cc: emacs-devel@gnu.org
(defcustom blink-matching-paren-distance (* 25 1024)
*If non-nil, is maximum distance to search for matching open-paren.
If nil, search stops at the begin of the
From: David Reitter [EMAIL PROTECTED]
Date: Sat, 27 Aug 2005 11:25:47 +0100
On 27 Aug 2005, at 04:41, Richard M. Stallman wrote:
I wrote a cleaner patch to do a job like this, but I have not had time
to test it, so I have not installed it. Can you test it?
OK, it works so far, but
Cc: Luc Teirlinck [EMAIL PROTECTED], [EMAIL PROTECTED],
emacs-devel@gnu.org
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Thu, 25 Aug 2005 10:54:00 +0200
Suppose you have a pop-up in a Windoze application similar to
the M-x customize-face interface in Emacs.
Now, if a Windoze
Date: Mon, 22 Aug 2005 23:23:35 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-devel@gnu.org
Eli Zaretskii wrote:
Cynicism aside, what you say is a general complaint about our doc
strings, not specific to the menu item we are discussing.
What I am
From: Drew Adams [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 07:08:59 -0700
If someone is looking for help on a key or a menu item, he will have
no problem recognizing Describe Key or Menu Item
What about someone who is looking for help on a click on the toolbar
or on mode line or on the
Date: Mon, 22 Aug 2005 23:56:06 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
If you click mouse-1 on the minibuffer or fringe, the KDE user (and
Lennart claimed the Microsoft user too) would expect a tooltip
telling what the minibuffer/echo
Date: Mon, 22 Aug 2005 23:40:20 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
I can only try out the KDE version and that one feels definitely
completely different from describe-key.
Can you give a couple of examples, please?
While I can not
From: Jason Rumney [EMAIL PROTECTED]
Date: Tue, 23 Aug 2005 21:56:01 +0100
Cc: [EMAIL PROTECTED], Luc Teirlinck [EMAIL PROTECTED],
emacs-devel@gnu.org
What IE example? I missed it. If by IE you mean Internet Explorer,
then the version I have does not have a What's This? menu item.
Date: Tue, 23 Aug 2005 17:02:25 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-devel@gnu.org
Click this to delete all cookies from your machine.
If the only useful thing that button does is delete all cookies from
your machine, then your example does
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Mon, 22 Aug 2005 09:58:45 +0200
Cc: martin rudalics [EMAIL PROTECTED], emacs-devel@gnu.org
In its current form, it does IN NO WAY resemble what a Windoze user
would expect from the What's this function.
I disagree. I think it comes reasonably
Date: Mon, 22 Aug 2005 19:08:01 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
First of all, as already pointed out by me and by Stefan, if a user
familiar with What's this clicks on the minibuffer, he expects an
explanation
Cc: [EMAIL PROTECTED] (Kim F. Storm), [EMAIL PROTECTED], emacs-devel@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 16:15:00 -0400
So, to me it sounds like we do something very similar to what you
described, with 2 notable exceptions: the change in mouse pointer
Date: Sun, 21 Aug 2005 12:59:33 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
From my previous reply:
My first choice would be to just delete What's this. But,
alternately one could have one menu item called:
What's This?
Date: Sun, 21 Aug 2005 16:38:21 -0500 (CDT)
From: Luc Teirlinck [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
They do the same thing, that is exactly what is confusing.
I don't see why, really.
What is this this that is referred to in What's this??
See the
From: Richard M. Stallman [EMAIL PROTECTED]
Date: Wed, 17 Aug 2005 02:25:39 -0400
Cc: emacs-devel@gnu.org
Thanks for posting the URL, though it seems that the web interface at
lists.gnu.org eats multiple spaces. Here is the Gmane URL for the
original post from Kevin Rodgers
From: emacs user [EMAIL PROTECTED]
Date: Thu, 18 Aug 2005 02:45:21 -0400
Cc: cygwin@cygwin.com, emacs-devel@gnu.org
some more diagnostics of the GC problem, with the help of some advice from
eliz. does this help?
It's a beginning. Thanks.
Breakpoint 1, abort () at emacs.c:461
461
From: emacs user [EMAIL PROTECTED]
Bcc:
Date: Tue, 16 Aug 2005 04:47:39 -0400
Cc: cygwin@cygwin.com, [EMAIL PROTECTED], [EMAIL PROTECTED],
emacs-devel@gnu.org
here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
absence of a detailed gdb GC debugging which I dont
From: Richard M. Stallman [EMAIL PROTECTED]
Date: Mon, 15 Aug 2005 14:44:26 -0400
Cc: emacs-devel@gnu.org
On Windows (and, as far as I know, on Mac OS), Emacs already places the
scroll bar consistently with the user environment it's running in (i.e.,
on the right).
That
Cc: Stefan Monnier [EMAIL PROTECTED], emacs-devel@gnu.org
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Mon, 15 Aug 2005 09:58:36 +0200
(define-key minibuffer-completion-map 'minibuffer-complete-word)
in their .emacs.
You must be kidding! Since when people who are accustomed
Date: Sat, 13 Aug 2005 11:26:48 + (GMT)
From: Alan Mackenzie [EMAIL PROTECTED]
Hi, Emacs!
Would somebody please install the following change:
2005-08-13 Alan Mackenzie [EMAIL PROTECTED]
* search.texi: Correct a typo.
Done, thanks.
From: Richard M. Stallman [EMAIL PROTECTED]
Date: Fri, 12 Aug 2005 10:59:21 -0400
His test case is very clear, but it does not fail when I try it.
FWIW, it doesn't fail for me, either, with today's CVS on w32.
Since he says he saw this on several different platforms, while you
don't see
From: Richard M. Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-devel@gnu.org, [EMAIL PROTECTED],
cygwin@cygwin.com
Date: Fri, 12 Aug 2005 10:59:49 -0400
As it was, without any
message, my initial suspicion was a SEGV or similar, which would be
much more
Date: Wed, 10 Aug 2005 07:37:43 -0400
From: Joe Buehler [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], cygwin@cygwin.com, emacs-devel@gnu.org
I would think that emacs would say why it is aborting.
When GC encounters a fatal inconsistency in the Emacs data structures,
it is generally unsafe to say
Date: Sat, 6 Aug 2005 02:02:40 +0200
From: Juanma Barranquero [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
Would someone *please* try and comment the changes? Or is there no
interest on an emacs client/server accessible across the network and
Windows-compatible too?
I'd
Cc: Juanma Barranquero [EMAIL PROTECTED], emacs-devel@gnu.org
From: Jason Rumney [EMAIL PROTECTED]
Date: Sat, 06 Aug 2005 08:12:50 +0100
MUCH easier. In fact, it doesn't need any setup at all just to read
messages and reply to them. You will only need to customize if you
want to use
Date: Sat, 06 Aug 2005 11:30:02 +0200
From: Lennart Borgman [EMAIL PROTECTED]
CC: Jason Rumney [EMAIL PROTECTED], [EMAIL PROTECTED],
emacs-devel@gnu.org
Could those of you that are using some mail client in Emacs on w32
perhaps post to the list and tell how this setup is done?
I don't
Date: Fri, 5 Aug 2005 11:09:45 +0200
From: Juanma Barranquero [EMAIL PROTECTED]
Cc: emacs-devel@gnu.org
That said, what would you recommend as e-mail interface for a
mostly-Windows Emacs user? Gnus?
I use RMAIL, but Gnus should also work.
___
From: Reiner Steib [EMAIL PROTECTED]
Date: Thu, 04 Aug 2005 19:57:43 +0200
On GNU/Linux, Emacs autoloads window-12xx.
Yes, I know that. But this has nothing to do with the text in the
MS-DOS appendix of the manual: that text describes codepage.el which
is only used in the MS-DOS port.
Date: Wed, 03 Aug 2005 23:41:04 +0200
From: Lennart Borgman [EMAIL PROTECTED]
Cc: emacs-devel@gnu.org
Stuart D. Herring wrote:
Is not the variable `x-select-enable-clipboard' for this?
No, that enables the use of the X clipboard selection in addition to the
X primary
Date: Tue, 2 Aug 2005 12:28:21 +0200
From: Juanma Barranquero [EMAIL PROTECTED]
Cc: emacs-devel@gnu.org
On 7/30/05, Eli Zaretskii [EMAIL PROTECTED] wrote:
Done (including similar changes in lispref/ and lispintro/). Please
remove your info/dir file, fetch one from the CVS, and report
From: Giuseppe Scrivano [EMAIL PROTECTED]
Date: Sat, 30 Jul 2005 03:31:48 +0200
Cc: emacs-devel@gnu.org
+ if(getcwd (buf, MAXPATHLEN + 1) == 0)
+fatal (`getwd' failed: %s\n, buf);
The error message mentions the wrong function here.
I also wonder whether we should keep the
Date: Fri, 29 Jul 2005 12:30:19 +0200
From: Juanma Barranquero [EMAIL PROTECTED]
Cc: emacs-devel@gnu.org
On 7/16/05, Eli Zaretskii [EMAIL PROTECTED] wrote:
Does anyone know why make info on MS-Windows runs install-info
for every manual, instead of relying on info/dir?
Seems like
From: Andreas Schwab [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
emacs-devel@gnu.org
Date: Sat, 30 Jul 2005 19:35:19 +0200
You can easily create a deeply nested directory whose absolute file name
is longer than MAXPATHLEN. The MAXPATHLEN (a.k.a
From: Giuseppe Scrivano [EMAIL PROTECTED]
Date: Fri, 29 Jul 2005 02:22:37 +0200
Cc: emacs-devel@gnu.org
This little patch should fix it.
Thanks, but please see my comments below.
@@ -5146,14 +5146,47 @@
stat (., dotstat) == 0
dotstat.st_ino == pwdstat.st_ino
Date: Thu, 28 Jul 2005 10:42:12 +0200
From: Juanma Barranquero [EMAIL PROTECTED]
This line of nt/configure.bat puzzles me. What purpose does it serve?
if not exist ..\lisp\Makefile.unix rename ..\lisp\Makefile.in Makefile.unix
On in-place installs, the next cvs update will bring back
1 - 100 of 384 matches
Mail list logo
