This patch does not work for me.
Because it didn't apply?
I think we should go with the approach suggested by YAMAMOTO
Mitsuharu, which does work. It may not be the most general
approach---as you pointed out, exotic user-set mode lines might cause
failures---but such situations are
Reports from Windows users still wanted.
Works here, thanks.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Reports from Windows users still wanted.
Works here, thanks.
Sorry, no. With a newline after the
html/html
and moving down and back that line I get
sgml-point-entered: Lisp nesting exceeds `max-lisp-eval-depth'
If I define `sgml-point-entered' as
(defun sgml-point-entered (x y)
;;
On Mon, 28 May 2007 10:58:00 +0200, martin rudalics [EMAIL PROTECTED]
said:
Reports from Windows users still wanted.
Works here, thanks.
Sorry, no. With a newline after the
html/html
and moving down and back that line I get
sgml-point-entered: Lisp nesting exceeds
I could reproduce this, but shouldn't the above `let' be `let*'?
My bad, let*'s ignore this.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
martin rudalics [EMAIL PROTECTED] writes:
I couldn't reproduce it on Mac OS X. It only shows an error like
forward-list: Scan error: Containing expression ends prematurely
OK. To prevent this I'd apply something like the attached patch (low
priority).
I think it's cleaner to put the
I think it's cleaner to put the condition-case outside. Does this
work for you?
Good. Eventually, someone could try to avoid theses scans when it's
easy to determine that they fail.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
martin rudalics [EMAIL PROTECTED] writes:
I think it's cleaner to put the condition-case outside. Does this
work for you?
Good. Eventually, someone could try to avoid theses scans when it's
easy to determine that they fail.
I've checked it into the branch.
The most simple patch I can come up with is specbinding it within
`display_mode_line' since that's causing the present problems. Please
test it (no other patches needed). If there are more occurrences
left I'll have move it to `display_mode_element'.
That may be a good
It fixes the bug as seen on GNU/Linux (i.e., with `debug-on-error' on,
I no longer see a `forward-list' error with original bug recipe; I
never observed the other operations are blocked part of the bug
report on this platform.)
Let's get this into the branch.
Yes, that is
On Sun, 27 May 2007 00:45:55 +0200, martin rudalics [EMAIL PROTECTED]
said:
(2) A bug in redisplay. Somewhere Qinhibit_point_motion_hooks
doesn't get bound to Qt but so far I was not able to find out where.
There's evidence that the bug shows up when `column-number-mode' is
enabled
to avoid that SET_PT_BOTH runs point-entered
! hooks when displaying the mode-line. If this forms a regression, restore
! it and find out why these hooks are run during redisplay at all. */
! /*** SET_PT_BOTH (opoint, opoint_byte); ***/
next_boundary = scan;
if (tab_width = 0
On Sun, 27 May 2007 11:12:35 +0200, martin rudalics [EMAIL PROTECTED]
said:
Unless someone who is familiar with this matter gives a better one,
I'd propose the following minimal and conservative change to avoid
regression at this stage.
It's too minimal. The following
SET_PT_BOTH
`Vinhibit_point_motion_hooks ==
Qnil'. I found the following cases:
pos_visible_p - display_mode_line
echo_area_display - redisplay_mode_lines - display_mode_lines -
display_mode_line
Thanks, I'm aware of these. I don't understand why pos_visible_p should
be called by redisplay. For the second
with the condition `Vinhibit_point_motion_hooks ==
Qnil'. I found the following cases:
pos_visible_p - display_mode_line echo_area_display -
redisplay_mode_lines - display_mode_lines - display_mode_line
Thanks, I'm aware of these. I don't understand why pos_visible_p
should be called by redisplay
(2) A bug in redisplay. Somewhere Qinhibit_point_motion_hooks doesn't
get bound to Qt but so far I was not able to find out where. There's
evidence that the bug shows up when `column-number-mode' is enabled,
`current-column' is called and triggers sgml's point-entered hook
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
Maybe you need to use specbind for the `current_column' call in
redisplay_internal instead.
*** src/xdisp.c.~1.1149.2.2.~ Fri May 25 11:00:00 2007
--- src/xdisp.c Sun May 27 22:48:48 2007
*** redisplay_internal
Chong Yidong [EMAIL PROTECTED] writes:
Maybe you need to use specbind for the `current_column' call in
redisplay_internal instead.
*** src/xdisp.c.~1.1149.2.2.~Fri May 25 11:00:00 2007
--- src/xdisp.c Sun May 27 22:48:48 2007
*** redisplay_internal
This patch works on Mac OS X for the original problem (without my
previous patch). Adding specbind and unbind_to around the
`current_column' in redisplay_internal also works.
I'm still uncertain whether this would catch all occurrences.
The most simple patch I can come up with is
BTW, as far as I can tell, this is a satisfactory permanent solution,
not just a temporary hack; so we might as well check it into the trunk
too. However, we may want to overhaul the way column-number-works,
after the release, to avoid problems of this sort.
Suppose someone wants to put the
);
{
Lisp_Object tail, frame;
This binds the variable across nearly all of redisplay.
That is a bit drastic as a solution; it might be right,
but it is hard to be sure.
Where is the actual call to `current_column' for which you
specifically want to bind this? Could you bind
On Sun, 27 May 2007 19:21:28 -0400, Richard Stallman [EMAIL PROTECTED]
said:
Where is the actual call to `current_column' for which you
specifically want to bind this? Could you bind
Qinhibit_point_motion_hooks for just that?
I meant the only direct call to `current_column' from
YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
I meant the only direct call to `current_column' from
redisplay_internal:
/* If %c is in the mode line, update it if needed. */
if (!NILP (w-column_number_displayed)
/* This alternative quickly identifies a common case
where no
On Sun, 27 May 2007 22:32:28 -0400, Chong Yidong [EMAIL PROTECTED] said:
Could someone check if this works on Windows for the original
problem?
It fixes the bug as seen on GNU/Linux (i.e., with `debug-on-error'
on, I no longer see a `forward-list' error with original bug recipe;
I never
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
C-u 8 C-b ;; move back the cursor
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
C-u 8 C-b ;; move back the cursor
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
C-u 8 C-b
On Sat, 26 May 2007 15:41:27 +0200 martin rudalics [EMAIL PROTECTED] wrote:
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode
On Sat, 26 May 2007 16:12:04 +0200 Stephen Berman [EMAIL PROTECTED] wrote:
On Sat, 26 May 2007 15:41:27 +0200 martin rudalics [EMAIL PROTECTED] wrote:
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept
MIYOSHI Masanori [EMAIL PROTECTED] writes:
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
C-u 8 C-b ;; move back the cursor
martin rudalics [EMAIL PROTECTED] writes:
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
With `debug-on-error' t you do get an error from `forward-list'?
Yes, but I don't see the not accepting any operations or continuous
redisplay behaviors. Maybe that part of the bug is specific to
Windows.
I think there are three bugs:
(1) The list scanning bug in `sgml-point-entered
., (redisplay t) fails to wait for
redisplay to finish.
2. Evalling the sexp with C-x C-e in any buffer results in what RMS
reported.
On my Emacs - 22.0.97.1 (i386-mingw-windows98.3000) - I only see the
second behavior. GTK+ related?
___
emacs
On Sat, 21 Apr 2007 20:47:19 -0400 Richard Stallman [EMAIL PROTECTED] wrote:
(progn (new-frame)
(redisplay t)
(x-popup-dialog t '(Foo (Bar . 1
I tried this but it didn't fail -- the new frame was not empty.
In my Emacs (GNU Emacs 22.0.98.2 (i686-pc-linux-gnu, GTK
(progn (new-frame)
(redisplay t)
(x-popup-dialog t '(Foo (Bar . 1
I tried this but it didn't fail -- the new frame was not empty.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman
;;; This ...
(progn (new-frame)
(redisplay t)
(x-popup-dialog t '(Foo (Bar . 1
;;; ... produces a blank frame while the popup dialog is active,
;;; i.e., (redisplay t) fails to wait for redisplay to finish.
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE
emacs -Q
M-: (info (ediff)Session Commands) RET
Click on the i of Ediff in the header line:
Next: Registry of Ediff Sessions
^
Go back with l.
Click the i again.
Some characters in the header line are still highlighted:
Next: Session Groups, Prev: Session
This is with CVS Emacs as of Jan 8.
In GNU Emacs 22.0.92.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
of 2007-01-08 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--prefix=/rvcarma/marshals/software/slash/usr/local'
'--with-x-toolkit=motif'
[EMAIL PROTECTED] (Kim F. Storm) writes:
I can reproduce this on
GNU Emacs 22.0.92.19 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2007-01-08 on kfs-l.imdomain.dk
I can repoduce this on
GNU Emacs 22.0.92.40 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
of 2007-01-09 on trpaslik
too.
I can reproduce similar results with M-x shell on GNU/Linux following
your description (terminating each multi-line with C-j is crusial!!)
It looks like redisplay fails to delete to end of line when lines
have mouse face.
Is it really a bug in Emacs, or is this just a matter
I can reproduce similar results with M-x shell on GNU/Linux following
your description (terminating each multi-line with C-j is crusial!!)
It looks like redisplay fails to delete to end of line when lines
have mouse face.
Is it really a bug in Emacs, or is this just a matter
Michael Mauger [EMAIL PROTECTED] writes:
John Paul Wallington writes:
I've noticed a weird redisplay bug on Emacs built and run with mingw
on Windows XP x64 Edition for development versions of Emacs built on
2006-09-30 through 2006-10-14.
In a Gnus Summary buffer, mouse-wheel scrolling
bytecode called
Fredisplay. The only lisp code I can find that calls redisplay is subr.el's
sit-for. It is worth noting that jit-lock-stealth-fontify calls sit-for.
Putting message forms in it suggests that redisplay is a consequence of its
sit-fors.
Changing its calls of sit-for to pass t for NODISP
Jorgen Schaefer [EMAIL PROTECTED] writes:
I'm sorry for the miserable bug report. I'll try to better myself
:-)
Don't worry. Your report got us going in the right direction!!
It does fix all the reproducible problems I found, too. Thanks a
lot!
Thanks for testing.
--
Kim F. Storm
[EMAIL PROTECTED] (Kim F. Storm) writes:
[EMAIL PROTECTED] (Johan Bockgård) writes:
Try it on a tty.
Thanks -- your recipe worked every time.
I'm sorry for the miserable bug report. I'll try to better myself
:-)
I've installed a patch which fixes it for me.
It does fix all the
Jorgen Schaefer [EMAIL PROTECTED] writes:
I now found out where the problem occurs, too. Both Circe and my
comint mode do perform
(save-excursion
(goto-char (point-max))
(recenter -1)
(sit-for 0))
on scrolling to keep the bottom-most line of the buffer at the
[EMAIL PROTECTED] (Johan Bockgård) writes:
Try it on a tty.
Thanks -- your recipe worked every time.
I've installed a patch which fixes it for me.
--
Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk
___
emacs-pretest-bug mailing list
Jorgen Schaefer [EMAIL PROTECTED] writes:
Hi there!
Since 2006-06-13, my Emacs behaved weirdly using Circe (an IRC
client). Text inserted due to network activity causes other text
to be moved, but the new text is not shown. Hitting any key will
show the text.
Does
M-: (setq redisplay
Hi there!
Since 2006-06-13, my Emacs behaved weirdly using Circe (an IRC
client). Text inserted due to network activity causes other text
to be moved, but the new text is not shown. Hitting any key will
show the text.
This behavior got less frequent with the patch of 2006-06-14, but
it still
:
This is on a tty (urxvt). The problem only shows up when the
problematic window is not selected.
I managed to come up with other weird behavior related to the
redisplay changes:
1) Shell buffer delayed update
In a *shell* buffer, do:
while sleep 1 ; do echo Fnord ; echo Frob ; done
-emption of Emacs redisplay would work better.)
Usually the whole screenful will get buffered anyway.
Does the X protocol buffer requests like that? Last time I looked,
it didn't do much buffering before transmitting on the wire. But
IIRC, there may be some X-aware protocol which does buffering
connections, it feels faster.
That's good news!
I haven't checked, but maybe checking for input during redisplay will
flush output ... so with the new preemption method, output is flushed
less often than before, actually making X output run faster.
--
Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk
I put the documentation for redisplay-preemption-period next to
redisplay-dont-pause in display.texi -- is there a better place?
Sounds good.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo
Perhaps we should undo the recent change in sit-for.
I don't remember the specific case for which we made it.
If it was one specific caller that needed another facility,
let's make (sit-for -1) do this, as someone else suggested.
Here is a way to do that.
It looks correct
Richard Stallman [EMAIL PROTECTED] writes:
Perhaps we should undo the recent change in sit-for.
I don't remember the specific case for which we made it.
If it was one specific caller that needed another facility,
let's make (sit-for -1) do this, as someone else suggested.
This could be done by checking for input every 0.10 seconds during
window redisplay (rather than every N lines).
This means that if redisplay is fast enough to complete within 0.10
seconds, it doesn't pre-empt.
That would work, for a terminal, assuming it waits for the output
.
But then the existing pre-emption check is also meaningless, since
redisplay (due to output buffering) will usually complete before more
input arrives.
It's possible that your suggestion will give good results nonetheless.
At least, I don't think it will be any worse ... and btw, it also
adapts pre-emption
[EMAIL PROTECTED] (Kim F. Storm) writes:
So please install your patch, and document it. Then we can see
how well it works.
I'll do that.
Done.
I put the documentation for redisplay-preemption-period next to
redisplay-dont-pause in display.texi -- is there a better place?
I also wrote
Richard Stallman [EMAIL PROTECTED] writes:
To repeat, (B) says:
(B) Don't _interrupt_ redisplay once it has started.
And this definitely _is_ (part of) what you get by setting
redisplay_dont_pause.
It is part of what you get, but now it is no longer the whole of what
you
to run stty, so that it will affect
all Emacs sessions during one login session.
The Linux console seems to say its speed is 38400 baud. That is
rather misleading, since even a typical modem is faster than that.
Here's an idea: adapt to the redisplay performance on the fly...
This could be done
. What would it do for a tty? Look at the tty name to see
if it is a pty?
And how do you decide how fast a remote connection is, nowadays?
Lots of them go to a machine on the same local net, and that would
be so fast it might as well be the same machine (as far as Emacs redisplay
decisions
To repeat, (B) says:
(B) Don't _interrupt_ redisplay once it has started.
And this definitely _is_ (part of) what you get by setting
redisplay_dont_pause.
It is part of what you get, but now it is no longer the whole of what
you get.
Perhaps we should undo the recent change
A first step would be to provide more realistic settings for baud_rate
in xterm.c, macterm.c, and w32term.c -- for example, 25 (assuming
that the connection is over a somewhat loaded half-duplex 10 MB LAN).
And then only enable pre-emptive redisplay if baud-rate is 20
Richard Stallman skrev:
A first step would be to provide more realistic settings for baud_rate
in xterm.c, macterm.c, and w32term.c -- for example, 25 (assuming
that the connection is over a somewhat loaded half-duplex 10 MB LAN).
And then only enable pre-emptive redisplay
And (B) is what you get by setting `redisplay-dont-pause'.
It WAS, but not any more.
It still IS, since redisplay-dont-pause _also_ controls whether input
interrupts redisplay.
No, what redisplay-dont-pause gives you is NOT (B).
(B) says that redisplay still only
Richard Stallman [EMAIL PROTECTED] writes:
And (B) is what you get by setting `redisplay-dont-pause'.
It WAS, but not any more.
It still IS, since redisplay-dont-pause _also_ controls whether input
interrupts redisplay.
No, what redisplay-dont-pause gives you
Richard Stallman [EMAIL PROTECTED] writes:
Normal redisplay is restarted whenever it is interrupted by user
input. For example, pressing and holding the down-arrow key will be
randomly jumpy -- depending on the speed of the computer vs. the key
repeat rate
The idea is:
(A) Don't _start_ redisplay if there is pending input,
i.e. process all available input before starting redisplay.
(B) Don't _interrupt_ redisplay once it has started.
That is interesting. I never thought about the question that way.
When redisplay is as fast
Richard Stallman [EMAIL PROTECTED] writes:
The idea is:
(A) Don't _start_ redisplay if there is pending input,
i.e. process all available input before starting redisplay.
(B) Don't _interrupt_ redisplay once it has started.
That is interesting. I never thought about
Normal redisplay is restarted whenever it is interrupted by user
input. For example, pressing and holding the down-arrow key will be
randomly jumpy -- depending on the speed of the computer vs. the key
repeat rate of the keyboard.
The only way to get more fluent display
Eli Zaretskii [EMAIL PROTECTED] writes:
Cc: Ralf Angeli [EMAIL PROTECTED], emacs-pretest-bug@gnu.org,
[EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Mon, 05 Jun 2006 23:00:43 +0200
I have [redisplay-dont-pause] enabled for all my Emacs installations
because I
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Tue, 06 Jun 2006 10:26:36 +0200
I agree that redisplay-dont-pause in its current form is not
the best _user_ option for controlling this ... as it has the
other purpose of forcing sit
From: Drew Adams [EMAIL PROTECTED]
Date: Mon, 5 Jun 2006 23:56:44 -0700
I did not understand that redisplay is restarted whenever it is interrupted
by user input. I thought that user input _inhibited_ redisplay (but that a
redisplay would eventually occur).
If user input never stops
I did not understand that redisplay is restarted whenever it
is interrupted by user input. I thought that user input
_inhibited_ redisplay (but that a redisplay would eventually
occur).
If user input never stops, redisplay will never happen (except if
Emacs needs
absolute priority over redisplay. If you
call these functions when input is available, they do nothing
immediately, but a full redisplay does happen eventually--after all the
input has been processed. (node Refresh Screen)
Emacs redisplays only when it pauses. (node Edebug Display Update
Eli Zaretskii [EMAIL PROTECTED] writes:
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Tue, 06 Jun 2006 10:26:36 +0200
I agree that redisplay-dont-pause in its current form is not
the best _user_ option for controlling this ... as it has
I don't see any inaccuracies or unclear statements in these excerpts.
Perhaps I know too much ;-) Feel free to point out in more words
which ones are confusing, and why.
As I said, none are incorrect. Nowhere is the eagerness of redisplay
conveyed, however: the fact that it occurs
IMHO, if a user needs to futz with redisplay-dont-pause to solve her
problems, there's either a bug or a missing feature.
Either it is one of those, or a user who is too fastidious.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Kim Normal redisplay is restarted whenever it is interrupted by user
input. For example, pressing and holding the down-arrow key will be
randomly jumpy -- depending on the speed of the computer
vs. the key repeat rate of the keyboard.
Emacs defers redisplay
From: Drew Adams [EMAIL PROTECTED]
Date: Tue, 6 Jun 2006 14:34:34 -0700
Cc: Kim F. Storm [EMAIL PROTECTED]
BTW, I think Kim was referring to cursor movement (holding down an arrow
key, for instance), not necessarily to insertion of characters in a buffer.
I guess the idea is the same,
As I said, none are incorrect.
I know that, but are they inaccurate or unclear?
I would leave them as is, and clarify instead 1) by adding a general
section, as you suggested, and 2) in the description of
`redisplay-dont-pause', where this understanding seems important. And maybe
remove
* Eli Zaretskii (2006-06-05) writes:
From: Drew Adams [EMAIL PROTECTED]
Date: Sun, 4 Jun 2006 17:34:00 -0700
I'm not certain it should be, as I'm not clear on how this user option
works.
I don't think it should be: it's not for users. It's for Lisp
programs that need special attention
I'm not certain it should be, as I'm not clear on how this
user option works.
I don't think it should be: it's not for users. It's for Lisp
programs that need special attention from the display engine.
Really? I have it enabled for all my Emacs installations because
From: Ralf Angeli [EMAIL PROTECTED]
Cc: Drew Adams [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
Date: Mon, 05 Jun 2006 09:54:52 +0200
I have [redisplay-dont-pause] enabled for all my Emacs installations
because I cannot stand the way buffer contents are updated during
scrolling
Eli Zaretskii [EMAIL PROTECTED] writes:
From: Ralf Angeli [EMAIL PROTECTED]
Cc: Drew Adams [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
Date: Mon, 05 Jun 2006 09:54:52 +0200
I have [redisplay-dont-pause] enabled for all my Emacs installations
because I cannot stand the way buffer contents
* Kim F. Storm (2006-06-05) writes:
Eli Zaretskii [EMAIL PROTECTED] writes:
From: Ralf Angeli [EMAIL PROTECTED]
I have [redisplay-dont-pause] enabled for all my Emacs installations
because I cannot stand the way buffer contents are updated during
scrolling if it is not.
I think that's
Cc: Ralf Angeli [EMAIL PROTECTED], emacs-pretest-bug@gnu.org,
[EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Mon, 05 Jun 2006 23:00:43 +0200
I have [redisplay-dont-pause] enabled for all my Emacs installations
because I cannot stand the way buffer contents
I'm not certain it should be, as I'm not clear on how this user option
works.
I find the Elisp doc on it confusing. I'd like to see some guidelines
for its use - what kinds of things a non-nil value is useful for.
And, again, if it's appropriate for end users too (it is a user
option), then
Try this:
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Kim == Kim F Storm [EMAIL PROTECTED] writes:
Try this:
Huh? I tried it and it didn't do anything.
Stefan ;-)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Eric Hanchrow offby1 at blarg.net writes:
I'm using Debian Sarge, and I've installed the ttf-bitstream-vera package.
I start Emacs with
emacs -Q /usr/share/dict/words -fn '-*-Bitstream Vera Sans
Mono-Medium-r-*-*-18-*-*-*-*-*-*-*'
Then I move point to the bottom of the window
I'm using Debian Sarge, and I've installed the ttf-bitstream-vera package.
I start Emacs with
emacs -Q /usr/share/dict/words -fn '-*-Bitstream Vera Sans
Mono-Medium-r-*-*-18-*-*-*-*-*-*-*'
Then I move point to the bottom of the window with M-- M-r. Now I
roll the mouse wheel away
On Mon, 26 Dec 2005 16:56:59 -0500 Richard M. Stallman [EMAIL PROTECTED]
wrote:
Please forgive my delay in looking at this bug report.
#2 0x08064fad in safe_eval (sexpr=139399637) at xdisp.c:2261
Can you make it get there again, and do
f 2
p sexpr
pr
and show us what that outputs?
Please forgive my delay in looking at this bug report.
#2 0x08064fad in safe_eval (sexpr=139399637) at xdisp.c:2261
Can you make it get there again, and do
f 2
p sexpr
pr
and show us what that outputs?
Also, if you could display the value of mode-line-format,
that would lead us to the cause
nothing to do with the
error.
Breakpoint 3, safe_eval_handler (arg=140906725) at xdisp.c:2236
2236 add_to_log (Error during redisplay: %s, arg, Qnil);
#0 safe_eval_handler (arg=140906725) at xdisp.c:2236
#1 0x081508a8 in internal_condition_case_1 (bfun=0x81519c0 Feval,
arg=139399637
When I start Emacs normally with my init-file, the following appears
in *Messages*:
Error during redisplay: (invalid-function /home/steve/diary-Abendessen.txt)
I don't see this message in the echo area and don't notice anything
wrong with the display and no other display problems appear
redisplay: %s, arg, Qnil);
#0 safe_eval_handler (arg=140906725) at xdisp.c:2236
#1 0x081508a8 in internal_condition_case_1 (bfun=0x81519c0 Feval,
arg=139399637, handlers=137489449, hfun=0x806c440 safe_eval_handler)
at eval.c:1496
#2 0x08064fad in safe_eval (sexpr=139399637) at xdisp.c
Edward O'Connor [EMAIL PROTECTED] writes:
Does it still happen with the test case you sent me?
In any case, can you try this patch to see if it gives better results:
With that patch installed it does still happen, but not in the test
case I sent the list. Looks like I need to come up with
Edward O'Connor [EMAIL PROTECTED] writes:
Kim F. Storm wrote:
I have installed a change that fixes this for me.
Can you pls. try latest CVS to see if it works for you too.
Unfortunately, I still see this behavior in the latest CVS.
Does it still happen with the test case you sent me?
In
1 - 100 of 105 matches
Mail list logo
