IMO Emacs Info node head
== Indexes (nodes containing large menus) ==
might be misleading, as the user may understand that
the index entries pertain to nodes containing
large menus only.
AFAIU that's not the focus. Probably its intended as a
hint, describing the contents of these indexes.
I forgot to raise this earlier, but reconfiguring reminds me.
$ ./configure
checking build system type... sparc-sun-solaris2.8
checking host system type... sparc-sun-solaris2.8
checking for gcc... no
checking for cc... cc
...
checking for alsa = 1.0.0... sh: gnome-config: not found
no
sh:
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
$ /usr/local/emacs/bin/emacs -Q
M-x server-start
Go to a new xterm window and do this:
$ ssh -X localhost
$ emacsclient --display=$DISPLAY some-file
The buffer for some-file is opened, but not in a new frame and is not
displayed in any existing window.
*Messages* now has this:
Loading
Lennart Borgman wrote:
As far as I can see the exit hooks for Emacs are not run when a user
logs out from Windows 2000 or reboots the pc. I do not know however if
this problem is specific to w32. It is in my opinion a serious problem
that ought to be fixed before the release.
I'm not sure
Jason Rumney wrote:
Lennart Borgman wrote:
As far as I can see the exit hooks for Emacs are not run when a user
logs out from Windows 2000 or reboots the pc. I do not know however
if this problem is specific to w32. It is in my opinion a serious
problem that ought to be fixed before the
Jason Rumney wrote:
Lennart Borgman wrote:
As far as I can see the exit hooks for Emacs are not run when a user
logs out from Windows 2000 or reboots the pc. I do not know however
if this problem is specific to w32. It is in my opinion a serious
problem that ought to be fixed before the
Lennart Borgman [EMAIL PROTECTED] writes:
Where is the code that discovers that WM_CLOSE has been sent to the
last frame and that Emacs should be killed?
WM_CLOSE is received in w32fns.c and passed on to lisp in w32term.c,
the same as most other windows messages. But I think you will find
that
I have a minor mode I want enabled in most buffers. I use this code to
fix that:
(define-global-minor-mode html-site-global-mode html-site-mode
(lambda()
(when buffer-file-name
(unless (memq major-mode html-site-mode-off-list)
(html-site-mode 1)
This works as expected
On Fri, 23 Jun 2006 16:43:33 +0200, [EMAIL PROTECTED] (Kim F. Storm) said:
Redisplay state was not restored properly after a composition. I've
fixed this by using the iterator stack for compositions.
I don't find any display problems so far. Thanks. But an assertion
violation occurs when
On Sun, 25 Jun 2006 17:46:39 +0100, David Reitter [EMAIL PROTECTED]
said:
Emacs hangs (no C-g possible) when create new listener from the
Allegro Common Lisp package is selected - I can't verify /
investigate further as I don't have Allegro Common Lisp. The package
seems non-standard, but
11 matches
Mail list logo
