The nonselectable items, are still selectable from the completions
buffer with mouse-1 or RET. They just do nothing and return to
the original buffer. I guess this is consistent with clicking on a
nonselectable menu-item but in this case its clearer that you
haven't selected
Nick Roberts writes:
I have written some code that removes the mouse-face property for
inactive entries, and adds a face inherited from
font-lock-comment-face; see attached. I think this does what you
want regarding selection.
I prefer this behaviour for selection but I don't
Steven T. Hatton [EMAIL PROTECTED] writes:
The attached file contains the top and bottom of a Lisp backtrace I got from
C-g, after enabling enter debugger on quit.
Indeed it looks like a loop/recursion bug in EDE.
So can we conclude that emacs does not _crash_ ?
--
Kim F. Storm [EMAIL
If there is no reason for Info to use TABS, then why use them?
TAB characters are a pretty standard part of Emacs culture; a
restriction on their use would require enforcement to be effective. A
program that doesn't deal with tabs is likely to experience them
anyway.
The
The attached file contains the top and bottom of a Lisp backtrace I got from
C-g, after enabling enter debugger on quit.
Indeed it looks like a loop/recursion bug in EDE.
So can we conclude that emacs does not _crash_ ?
And since C-g works as well, it's not frozen.
I.e. it's not an Emacs
The same argument could be made for *Help*, or Dired, or *Apropos*, or
*Buffer List*, or Those buffers don't use TABs, but there is no
restriction on their use or any explicit enforcement to not use TABs,
AFAIK.
AFAICT these are different situations: the TABs in info buffers don't come
I don't have a problem serious enough to warrent the change. I just don't
see why Info should have TABs. I don't suggest this as an urgent or
important problem, but as something that might be changed over time. If
there is no reason for Info to use TABS, then why use them?
They
KFS == Kim F Storm [EMAIL PROTECTED] writes:
KFS The problem turned out to be nested calls to format-mode-line,
KFS which caused internal data pointers to be altered in unexpected
KFS ways.
KFS I have just installed a patch to fix this. Pls. try it.
It works well now, thanks!
Saving a modified file i am allowed to access (owner) in a directory i
am not allowed to write in (no new files allowed). Emacs seems to hang,
but quitting works, and with debug-on-quit t:
Debugger entered--Lisp error: (quit)
copy-file(/etc/apt/sources.list /etc/apt/sources.list~ t t excl)
From: Stefan Monnier [EMAIL PROTECTED]
Date: Wed, 01 Jun 2005 11:28:48 -0400
Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
the TABs in info buffers don't come from Emacs but from actual info
files (generated by makeinfo, or install-info, or by hand).
install-info doesn't change the Info
When a modified buffer is killed through some mouse action, I get a
``yes-or-no-p'' question in form of a single submenu drawn on the
screen, in the middle of the frame.
When I then click somewhere else in the frame (outside the menu), the
adopted semantics are no rather than quit.
Place the following in the middle of a buffer (with text following):
`[(,test ,)]
Set the point right after the (malformed) expression and hit C-x C-e.
You will find that an error is correctly reported (invalid-read-
syntax )), but that the complete rest of the buffer (after the
point) IS
Hi,
I'm troubled with Emacs crashing since yesterday when executing
some emacs-w3m command. I haven't succeeded in identifying of
the Lisp code of the cause yet, though. Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0809704f in lisp_string_width (string=149514347,
13 matches
Mail list logo
