headers
David Reitter | 1 Apr 2006 01:41
Picon
Gravatar

crash in xdisp.c: show_mouse_face

A user reported a crash under the circumstances described below.
This is the Carbon port of GNU Emacs from March 28, with some patches  
(none to xdisp.c).
Please see the stack trace below, and ask Phil directly in case there  
are questions - I don't have more information.

Begin forwarded message:

> From: Phil <pbpublist <at> comcast.net>
> Date: 31 March 2006 20:54:56 BDT
> To: David Reitter <david.reitter <at> gmail.com>
> Subject: Re: [Aquamacs-bugs] Aquamacs crash report
>
> I'm running Slime under Aquamacs and it had just popped up it's  
> debugger reporting a REPL error.   About one to two seconds later,  
> Aquamacs crashed.  This is a periodic problem but not easily  
> reproducible as I can relaunch Aquamacs and immediately generate  
> the error in my REPL session without crashing Aquamacs again.  It's  
> entirely possible that Slime is directly related to the problem but  
> since Aquamacs crashes, I'm not sure how to determine this.
>
> Whether or not Aquamacs crashes does not appear to be related to a  
> specific duration (Aquamacs can be running for minutes or days) or  
> usage (what was happening at the time of the crash can be repeated  
> after a restart without causing another crash).  I've tried killing  
> running Lisp processes to see if this would result in Slime causing  
> Aquamacs to crash but it correctly determines that the process is  
> gone and life goes on in Aquamacs.  Any suggestions on how I might  
> go about capturing additional data that would be helpful in  
> narrowing this down?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Luc Teirlinck | 1 Apr 2006 02:52
Picon

Re: emacs-unicode-2: bootstrap failed due to recent mh-e changes

Bill Wohler wrote:

   If an update doesn't resolve the problem, please remove
   lisp/mh-e/*.elc and try again.

All of that is apparently not sufficient to solve the problem.  Still
same error message:

Compiling /home/teirllm/emacscvsdir/emacs/lisp/./mh-e/mh-e.el

In toplevel form: mh-e/mh-e.el:997:1:Error: Symbol's function
definition is void: mh-strip-package-version
make[2]: *** [compile] Error 1
make[2]: Leaving directory `/home/teirllm/emacscvsdir/emacs/lisp'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory `/home/teirllm/emacscvsdir/emacs'
make: *** [bootstrap] Error 2
Permalink | Reply | 0 comments |
headers
Bill Wohler | 1 Apr 2006 03:06
Picon
Picon
Gravatar

Re: emacs-unicode-2: bootstrap failed due to recent mh-e changes

Luc Teirlinck <teirllm <at> dms.auburn.edu> wrote:

> Bill Wohler wrote:
> 
>    If an update doesn't resolve the problem, please remove
>    lisp/mh-e/*.elc and try again.
> 
> All of that is apparently not sufficient to solve the problem.  Still
> same error message:
> 
> Compiling /home/teirllm/emacscvsdir/emacs/lisp/./mh-e/mh-e.el
> 
> In toplevel form: mh-e/mh-e.el:997:1:Error: Symbol's function
> definition is void: mh-strip-package-version
> make[2]: *** [compile] Error 1
> make[2]: Leaving directory `/home/teirllm/emacscvsdir/emacs/lisp'
> make[1]: *** [bootstrap-build] Error 2
> make[1]: Leaving directory `/home/teirllm/emacscvsdir/emacs'
> make: *** [bootstrap] Error 2

I do not understand this. If you remove mh-e/*.elc, it compiles. If you
just touch mh-e/mh-e.el and compile it fails.

I found that making mh-strip-package-version a macro fixes the error
(which I just checked in). If someone would like to explain why this is
so, I would listen eagerly. Is this fixing the problem, or merely
masking the symptoms?

Color me baffled by the compiler (again).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Apr 2006 05:31
Picon
Favicon

Speedbar mode line is far too wide

emacs -q
M-x speedbar

The mode line centers "Files ####" (where #### is a number) between 64
black spaces and "<<" and ">>". This is needlessly wide.

If, for example, frame-fitting code is used, the "Files ####" usually
disappears off to the right, because the buffer text (when collapsed)
is much narrower.

Please use just "<< Files #### >>" or similar, with no extra padding.

If emacs crashed, and you have the emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/Emacs-22-2006-03-20/etc/DEBUG for instructions.

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2006-03-20 on W2ONE
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Apr 2006 05:32
Picon
Favicon

Speedbar mode line is far too wide

emacs -q
M-x speedbar

The mode line centers "Files ####" (where #### is a number) between 64
black spaces and "<<" and ">>". This is needlessly wide.

If, for example, frame-fitting code is used, the "Files ####" usually
disappears off to the right, because the buffer text (when collapsed)
is much narrower.

Please use just "<< Files #### >>" or similar, with no extra padding.

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2006-03-20 on W2ONE
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Dired by name
(Continue reading)

Permalink | Reply | 2 comments |
headers
Drew Adams | 1 Apr 2006 05:39
Picon
Favicon

"Funktion" in Elisp manual

In the Emacs Lisp manual, for example node Parameter Access, I see
"Funktion" everywhere. That is not English.

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2006-03-20 on W2ONE
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Info

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
(Continue reading)

Permalink | Reply | 7 comments |
headers
Luc Teirlinck | 1 Apr 2006 05:51
Picon

Re: emacs-unicode-2: bootstrap failed due to recent mh-e changes

Bill Wohler wrote:

   I do not understand this. If you remove mh-e/*.elc, it compiles. If you
   just touch mh-e/mh-e.el and compile it fails.

I did `make maintainer-clean' and I even checked that that really
removed all mh-e/*.elc files.  Bootstrapping nevertheless failed
(before your very latest change).

   I found that making mh-strip-package-version a macro fixes the error
   (which I just checked in)

Now bootstrapping indeed works again.

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Drew Adams | 1 Apr 2006 09:15
Picon
Favicon

compilation-message-face should be an option or shouldn't exist

`compilation-message-face' is a new, internal variable that hard-codes
underlining on complete lines in compilation buffers.  This is
ridiculous - it gives users no control over the appearance of such
lines (except by fiddling with an internal variable).  It should be a
face or a user option, so users can customize it. And the default
value should be the default face - that is, there should be no special
appearance, by default.

As it stands now, the only way I could find to turn off this horrible
underlining is to set this internal variable to nil. This isn't even
documented, AFAIK. This ugliness is intrusive and obstructs
readability.

The only underlining that would make sense in this context would be to
use `underline' as the `mouse-face' (not the `face') property.

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2006-03-20 on W2ONE
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
(Continue reading)

Permalink | Reply | 3 comments |
headers
Drew Adams | 1 Apr 2006 09:25
Picon
Favicon

Send Bug Report is worse

Help > Send Bug Report is worse than before.

1. It's good that it now uses the user's mail client. It's silly that
it pastes a message saying to paste the message you have already
composed into the mail body. If the program can paste this silly
message then it can paste the message that you have composed, and save
you the trouble.

2. The message-composition buffer, *mail*, has this text *following*
the cursor, so it ends up between the user's message and the extra
data that is to be sent:

"If emacs crashed, and you have the emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/Emacs-22-2006-03-20/etc/DEBUG for instructions."

IOW, first there are instructions, then the cursor (so, the user
message), then more instructions, then the session data. The program
cleverly pastes only the user's message plus the data, avoiding this
extra instruction.

All of the instructions should appear at the beginning. The user input
area should be delineated by a horizontal line before and after.

3. There is no need for four colors for the header labels: black,
blue, brown, red. What's the point?

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
(Continue reading)

Permalink | Reply | 9 comments |
headers
Drew Adams | 1 Apr 2006 10:17
Picon
Favicon

Info directory (dir): Emacs heading different from Menu heading

emacs -q
C-h i

In the left column are two headings: "* Menu" and "Emacs". It looks a
bit odd that Menu is preceded by an asterisk. Is this just a vestige
of older versions of Emacs? Is it perhaps still needed for emacs on a
terminal (no window mgr)? In any case, it looks odd in normal Emacs.

The Info manual says that "* Menu" determines a menu, so the Info
manual will need to be updated if the appearance is updated. This is
the same as what happened to "*Note": that text is now hidden, so the
Info manual was updated so it now reads without mention of "*Note".
(Actually, no change to the manual was needed in that case, because
the text simply says "Cross references look like this:". The change in
appearance of the cross reference sufficed to update the manual's
description of that appearance.)

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2006-03-20 on W2ONE
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
(Continue reading)

Permalink | Reply | 2 comments |

Gmane