Re: Display problems with 'before-string in overlay
Kim F. Storm wrote:
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:
Just another note if someone else is trying this. Having coming back
to this several times today I am starting to believe that the way to
fix this is to change cursor_row_p. This was the original way that Kim
tried to solve it. Maybe Kim's solution with an added test of if the
"string" has the 'display property will solve the problem for now.
I am unable to test this now, since I do not understand how to check
for the 'display property in cursor_row_p. If someone can tell that I
will test.
That is _not_ easy.
You have to record that during redisplay (by display_line in the glyph
row) if you need that information later.
I tested this way, but everything just gets very weird after some of the
"Lisp_Object q_display" lines have been executed. I guess I am breaking
something very fundamental. Could someone of you explain what?
static int
cursor_row_p (w, row)
struct window *w;
struct glyph_row *row;
{
int cursor_row_p = 1;
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row->end.string_pos) >= 0)
{
int start = row->start.pos.charpos;
int end = row->end.pos.charpos;
//Lisp_Object q_display = get_char_property_and_overlay (end,
Qdisplay, Qnil, 0);
Lisp_Object q_display = Fget_char_property (end, Qdisplay, Qnil);
//fprintf (stderr, "> cursor_row_p.start=%d, end=%d,
nil(q_display)=%d\n", start, end, NILP(q_display));
cursor_row_p = row->continued_p;
}
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BibTeX-mode: bibtex-user-optional-fields: INIT without {}
"Roland Winkler" wrote:
> The following patch appears much clearer to me.
[...]
> Should I check it in?
Entirely up to you. I installed mine, but feel free to revert it.
> + (unless (string-match "\\`\\({.*}\\|\".*\"\\)\\'" init)
> +(setq init (concat (bibtex-field-left-delimiter) init
> + (bibtex-field-right-delimiter)
What about the (unlikely?) cases like:
author = {Smith}, J. and Jones, {P.}
It matches the above regexp, but still needs enclosing.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: Just another note if someone else is trying this. Having coming back to this several times today I am starting to believe that the way to fix this is to change cursor_row_p. This was the original way that Kim tried to solve it. Maybe Kim's solution with an added test of if the "string" has the 'display property will solve the problem for now. I am unable to test this now, since I do not understand how to check for the 'display property in cursor_row_p. If someone can tell that I will test. That is _not_ easy. You have to record that during redisplay (by display_line in the glyph row) if you need that information later. But does not the code in set_cursor_from_row test for 'display in "strings"? Or is that another situation? But I see now set_cursor_from_row just calls pos = XINT (Fnext_single_char_property_change (make_number (pos), Qdisplay, Qnil, limit)); Can't that approach be used? glyph_row has a "pointer" to the position in the buffer through the field display_pos start, where display_pos has a text_pos field. And text_pos has a charpos field, which I assume is the position in the buffer. I am thinking about this solution since it seems rather safe to me. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
> > I managed to reproduce the bug. > > > > emacs -nw > > M-: (set-window-margins (selected-window) 1) RET > > C-x 2 > > C-x ^ > > > > Pressing left and right button and inserting text now makes it clear > > that redisplay is broken. > > > > The call to enlarge-window and set-window-margins appears to be > > essential to producing this bug. A related error that may/may not help: when I do this I can only drag the mode-line in one direction. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
[EMAIL PROTECTED] (Kim F. Storm) writes: > Chong Yidong <[EMAIL PROTECTED]> writes: > >> Eli Zaretskii <[EMAIL PROTECTED]> writes: >> It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. >>> >>> Are you sure redisplay is ``so fast''? what about remote connections >>> via a slow link? >> >> I don't have a way to test this, but I believe the cost should be >> negligible even for that case. In the very worst case scenario it, >> will only lead to one extra screen redraw every time you do C-x ^. > > Could you test if the current window has non-empty left margin, > and only set the garbaged flag in that case? No, the problem seems to come up as long as there is a window with a marginal area in use. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes:
> (progn
> (switch-to-buffer (get-buffer-create "*test*"))
> (erase-buffer)
> (insert ".\n<\n.\n>\n")
> (goto-char (point-min))
> (let ((ov (make-overlay 4 7)))
> (overlay-put ov 'display "Ax\nyB"))
> (goto-char (point-max)))
>
> With my change, moving the cursor places it on the 'A'.
> Without my change, moving the cursor places it on the 'y'.
> So my change may be incorrect - but it _does_ solve a real problem.
I think the following approach may work.
It reverts your cursor_row_p change, and deals with overlays
containing display properties by modifying adjust_point_for_property
so that one is never at the start of such an overlay (the behavior for
display text properties is left unchanged). It doesn't deal with the
other issue I raised (i.e., the apparently false assumption in the way
set_cursor_from_row uses string_buffer_position). However, dealing
with the opens up another can of worms, and the current patch seems
sufficient to provide good behavior for all cases I've tried.
Of course, redisplay can lead to some pretty subtle bugs. It's still
debatable whether we want to make such a change at this stage.
*** emacs/src/xdisp.c.~1.1146.~ 2007-04-14 16:57:50.0 -0400
--- emacs/src/xdisp.c 2007-04-14 19:03:17.0 -0400
***
*** 15854,15865
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
!the cursor there, but we still want it at the start of the
!string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row->end.string_pos) >= 0)
! cursor_row_p = (row->continued_p
! || PT >= MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15854,15863
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
!the cursor there.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row->end.string_pos) >= 0)
! cursor_row_p = row->continued_p;
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
*** emacs/src/keyboard.c.~1.899.~ 2007-04-14 16:26:52.0 -0400
--- emacs/src/keyboard.c2007-04-14 19:22:33.0 -0400
***
*** 2006,2027
}
check_composition = 0;
if (check_display
! && PT > BEGV && PT < ZV
&& !NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, &overlay))
! && display_prop_intangible_p (val)
! && (!OVERLAYP (overlay)
! ? get_property_and_range (PT, Qdisplay, &val, &beg, &end, Qnil)
! : (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay
! && (beg < PT /* && end > PT <- It's always the case. */
! || (beg <= PT && STRINGP (val) && SCHARS (val) == 0)))
! {
! xassert (end > PT);
! SET_PT (PT < last_pt
! ? (STRINGP (val) && SCHARS (val) == 0 ? beg - 1 : beg)
! : end);
! check_composition = check_invisible = 1;
}
check_display = 0;
if (check_invisible && PT > BEGV && PT < ZV)
--- 2006,2041
}
check_composition = 0;
if (check_display
! && PT >= BEGV && PT < ZV
&& !NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, &overlay))
! && display_prop_intangible_p (val))
! {
! if (OVERLAYP (overlay))
! {
! beg = OVERLAY_POSITION (OVERLAY_START (overlay));
! end = OVERLAY_POSITION (OVERLAY_END (overlay));
! if (beg <= PT)
! {
! SET_PT (PT < last_pt
! ? (beg > BEGV) ? beg - 1 : end
! : end);
! check_composition = check_invisible = 1;
! }
! }
! else if (PT > BEGV)
! {
! get_property_and_range (PT, Qdisplay, &val, &beg, &end, Qnil);
! xassert (end > PT);
! if ((beg < PT)
! || (beg == PT && STRINGP (val) && SCHARS (val) == 0))
! {
! SET_PT (PT < last_pt
! ? (STRINGP (val) && SCHARS (val) == 0 ? beg - 1 : beg)
! : end);
! check_composition = check_invisible = 1;
! }
! }
}
check_display = 0;
if (check_invisible && PT > BEGV && PT < ZV)
___
emacs-pretest-bug mailing lis
Re: Display problems with 'before-string in overlay
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: > Just another note if someone else is trying this. Having coming back > to this several times today I am starting to believe that the way to > fix this is to change cursor_row_p. This was the original way that Kim > tried to solve it. Maybe Kim's solution with an added test of if the > "string" has the 'display property will solve the problem for now. > > I am unable to test this now, since I do not understand how to check > for the 'display property in cursor_row_p. If someone can tell that I > will test. That is _not_ easy. You have to record that during redisplay (by display_line in the glyph row) if you need that information later. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Chong Yidong <[EMAIL PROTECTED]> writes: > Eli Zaretskii <[EMAIL PROTECTED]> writes: > >>> It forces a glyph matrix reallocation after each call to >>> enlarge_window. The slowdown will be undetectable since redisplay is >>> so fast on text terminals anyway. >> >> Are you sure redisplay is ``so fast''? what about remote connections >> via a slow link? > > I don't have a way to test this, but I believe the cost should be > negligible even for that case. In the very worst case scenario it, > will only lead to one extra screen redraw every time you do C-x ^. Could you test if the current window has non-empty left margin, and only set the garbaged flag in that case? -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BibTeX-mode: bibtex-user-optional-fields: INIT without {}
Glenn Morris wrote
> Christian Schlauer wrote:
> > So the curly braces are missing.
> I think this patch fixes it.
The following patch appears much clearer to me. Also, it handles
properly the case that INIT can be a lambda expression. Finally, the
first part fixes an old bug in the handling of bibtex-include-OPTkey.
Should I check it in?
--- bibtex.el~ 2007-01-21 07:37:51.0 -0600
+++ bibtex.el 2007-04-14 15:35:57.0 -0500
@@ -2831,7 +2831,7 @@
(push (list "key"
"Used for reference key creation if author and editor
fields are missing"
(if (or (stringp bibtex-include-OPTkey)
-(fboundp bibtex-include-OPTkey))
+(functionp bibtex-include-OPTkey))
bibtex-include-OPTkey))
optional))
(if (member-ignore-case entry-type bibtex-include-OPTcrossref)
@@ -3058,10 +3058,14 @@
(indent-to-column (+ bibtex-entry-offset
bibtex-text-indentation)))
(let ((init (nth 2 field)))
-(insert (cond ((stringp init) init)
- ((fboundp init) (funcall init))
- (t (concat (bibtex-field-left-delimiter)
- (bibtex-field-right-delimiter))
+(if (not init) (setq init (concat (bibtex-field-left-delimiter)
+ (bibtex-field-right-delimiter)))
+ (if (functionp init) (setq init (funcall init)))
+ (unless (stringp init) (error "%s is not a string" init))
+ (unless (string-match "\\`\\({.*}\\|\".*\"\\)\\'" init)
+(setq init (concat (bibtex-field-left-delimiter) init
+ (bibtex-field-right-delimiter)
+(insert init))
(when interactive
;; (bibtex-find-text nil nil bibtex-help-message)
(if (memq (preceding-char) '(?} ?\")) (forward-char -1))
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> It forces a glyph matrix reallocation after each call to >> enlarge_window. The slowdown will be undetectable since redisplay is >> so fast on text terminals anyway. > > Are you sure redisplay is ``so fast''? what about remote connections > via a slow link? I don't have a way to test this, but I believe the cost should be negligible even for that case. In the very worst case scenario it, will only lead to one extra screen redraw every time you do C-x ^. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Just another note if someone else is trying this. Having coming back to this several times today I am starting to believe that the way to fix this is to change cursor_row_p. This was the original way that Kim tried to solve it. Maybe Kim's solution with an added test of if the "string" has the 'display property will solve the problem for now. I am unable to test this now, since I do not understand how to check for the 'display property in cursor_row_p. If someone can tell that I will test. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
> From: Chong Yidong <[EMAIL PROTECTED]> > Date: Sat, 14 Apr 2007 11:58:53 -0400 > > It forces a glyph matrix reallocation after each call to > enlarge_window. The slowdown will be undetectable since redisplay is > so fast on text terminals anyway. Are you sure redisplay is ``so fast''? what about remote connections via a slow link? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: A) It looks like set_cursor_from_row gets called over and over again in some circumstances. I might have done something stupid that triggers this, I am not sure at the moment, but if I move to the end of the file with right error this happens. If stops when I press down arrow. Whatever size the buffer have when point is at the end of buffer and I press left arrow then set_cursor_from_row has PT=14 and when I press down arrow PT=1. In other circusomstances PT seems to be what I expect (ie ==(point)). Could not this be a problem for the cursor position routines? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: B) Moving with right arrow across the 'display part on the screen moves point across the part of the buffer that has the 'display property. In contrast moving with left arrow make point stop at the first of the characters that has the overlay with the 'display property (which is the correct behavior I believe). This seems to be a bug in another part than the ones Chong tried to cover with his patch sketch. Can others reproduce the bug in B? If so I believe this is the most serious one. I reverted the changes to keyboard.c in Chongs patch sketch. That cured this problem. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Richard Stallman <[EMAIL PROTECTED]> writes: > You could add code inside a conditional which tests for that case. > Then you know it won't affect any other cases. I don't have a clue to how to write the "conditional which tests for that case". Have you tried to figure out how? To figure out what this conditional is, one must first get to the bottom of the failure. If you explain the failure mode to me, I will try to figure out a safe fix. I already explained twice what the problem is, and why it's better to postphone the fix. I took the sketchial patch Chong sent, inserted a lot of dump messages and played with it to try to understand what is happening. The patch looks bigger than it actually is. I mean much of it just adds another parameter to string_buffer_pos and that is rather harmless from a stability point of view. I think I see several small bugs, most related to the 'display property, but not all: A) It looks like set_cursor_from_row gets called over and over again in some circumstances. I might have done something stupid that triggers this, I am not sure at the moment, but if I move to the end of the file with right error this happens. If stops when I press down arrow. B) Moving with right arrow across the 'display part on the screen moves point across the part of the buffer that has the 'display property. In contrast moving with left arrow make point stop at the first of the characters that has the overlay with the 'display property (which is the correct behavior I believe). This seems to be a bug in another part than the ones Chong tried to cover with his patch sketch. C) Even when moving with left arrow the cursor stops at the wrong position. It stops after the 'display part. (This behavior is correct for 'before-string and 'after-string, but not for 'display strings.) D) When the cursor is at the second 'display area of Kim's example set_cursor_from_row gets called over and over again. It does not matter how that row was entered AFAICS. Can others reproduce the bug in B? If so I believe this is the most serious one. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Chong Yidong <[EMAIL PROTECTED]> writes: > I managed to reproduce the bug. > > emacs -nw > M-: (set-window-margins (selected-window) 1) RET > C-x 2 > C-x ^ > > Pressing left and right button and inserting text now makes it clear > that redisplay is broken. > > The call to enlarge-window and set-window-margins appears to be > essential to producing this bug. I can't seem to track down this bug. There seems to be some subtle bug in the optimizations for reusing glyph matrices on text terminals, which only shows up when display margins are present. For the release, I propose the following hack. It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. I'll try to track this down completely after the release. Any objections? (I'll also insert the appropriate comments explaining the situation, of course.) *** emacs/src/window.c.~1.575.~ 2007-03-31 10:10:14.0 -0400 --- emacs/src/window.c 2007-04-14 11:43:03.0 -0400 *** *** 4415,4422 XSETFASTINT (p->last_modified, 0); XSETFASTINT (p->last_overlay_modified, 0); /* Adjust glyph matrices. */ ! adjust_glyphs (XFRAME (WINDOW_FRAME (XWINDOW (window; } --- 4415,4425 XSETFASTINT (p->last_modified, 0); XSETFASTINT (p->last_overlay_modified, 0); + if (!FRAME_WINDOW_P (WINDOW_XFRAME (XWINDOW (window + SET_FRAME_GARBAGED (WINDOW_XFRAME (XWINDOW (window))); + /* Adjust glyph matrices. */ ! adjust_glyphs (WINDOW_XFRAME (XWINDOW (window))); } ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Richard Stallman <[EMAIL PROTECTED]> writes: > > You could add code inside a conditional which tests for that case. > > Then you know it won't affect any other cases. > > I don't have a clue to how to write the "conditional which tests for that > case". > > Have you tried to figure out how? > > To figure out what this conditional is, one must first get to the bottom > of the failure. If you explain the failure mode to me, I will try to figure > out a safe fix. I already explained twice what the problem is, and why it's better to postphone the fix. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
> You could add code inside a conditional which tests for that case. > Then you know it won't affect any other cases. I don't have a clue to how to write the "conditional which tests for that case". Have you tried to figure out how? Show what that conditional is ... then we can continue this talk. To figure out what this conditional is, one must first get to the bottom of the failure. If you explain the failure mode to me, I will try to figure out a safe fix. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
> >> I see no function assq-remove-all. Is this in Emacs 23? > > My guess is, it's (another) one of Stefan's local changes... :) > > No. I don't have such a thing here either. But the name should make the > intended behavior clear enough. It's hard enough remembering what actual functions should do without having to work out what hypothetical ones would do! -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Glenn Morris writes: > Nick Roberts wrote: > > > But isn't globalbind already a copy of the global map? > > > > (setq globalbind (cdr (global-key-binding keyseq))) > > By experiment, no, eg: > > (define-key lisp-interaction-mode-map [menu-bar edit] 'undefined) > M-x tmm-menubar > > will delete the Edit menu from _all_ buffers. I don't see that. I only see a problem if I toggle a minor mode, e.g: M-x view-mode (define-key view-mode-map [menu-bar edit] 'undefined) M-x view-mode The edit menu-item has disappeared from the global-map. > Adding a copy-sequence > prevents that. Yes, so I have committed this change. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
- Me (2007-04-14) wrote:- > I will try a font that cause flickering and see if I can catch a bug. I mean a font that causes *NO* flickering. -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
Dear Kenichi, - Kenichi Handa (2007-04-14) wrote:- >> It happens usually when there are many links in a buffer such as in ERC >> or W3M. I can move around mouse in a w3m buffer with tons of links (such >> as www.6park.com) to catch a crash, which usually happens within a few >> minutes. I just catch one with 'emacs -Q'. Unfortunately I don't know >> the exact recipe to trigger a crash. > > I've just installed w3m and emacs-w3m, visited > www.6park.com, moved mouse-cursor and normal cursor onto > various links, but couldn't trigger a crash. Since that website is using Chinese font and the flickering problem depends on font and size, I wonder if that is why you can not reproduce the crash. But I can confirm even with a font that *does not* cause flickering, crashes still happen. So seems there is something wrong. BTW, I am using CVS emacs-w3m. >> The following can help you see the bug although it won't crash Emacs: > >> o emacs -Q --enable-font-backend -fn SOMEFONT >> o C-u 3 2 M-x hanoi > >> You should see the frame flickering like TV disturbed by static. > > I can confirm the flickering with some fonts of some size. > For instance, this cause flickering: > > emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=16' > > but these don't cause flickering: > > emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=24' > emacs-unicode --enable-font-backend -fn 'lucidatypewriter:pixelsize=16' > > I think the reason is that font-height of "dejavu sans > mono:pixelsize=16" is somehow shorter than the glyph '|' in > that font. So, every time Emacs redraw '|', the upper and > lower lines are also redrawn which leads to the whole buffer > redrawing. For instance, when I replace all occurence of > "?\|" in lisp/play/hanoi.el with "?i", even this: > > emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=16' > > stops flickering. Indeed, using another font can stop flickering in hanoi. But flickering can still be seen by doing the following in emacs-w3m: 1. go to http://dir.gmane.org/gmane.education.brazil.infoestacio 2. In Line 10, there is "All messages from the list, with excerpted texts.", now move mouse cursor back and forth on that link and you will see the same phenomena as in hanoi. The font I am using is: , | dejavu lgc sans mono:pixelsize=17:foundry=unknown:weight=bold:slant=r:width=normal (#x24) ` HTH -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
Dear Kenichi, - Kenichi Handa (2007-04-14) wrote:- >> It happens usually when there are many links in a buffer such as in ERC >> or W3M. I can move around mouse in a w3m buffer with tons of links (such >> as www.6park.com) to catch a crash, which usually happens within a few >> minutes. I just catch one with 'emacs -Q'. Unfortunately I don't know >> the exact recipe to trigger a crash. > > I've just installed w3m and emacs-w3m, visited > www.6park.com, moved mouse-cursor and normal cursor onto > various links, but couldn't trigger a crash. I will try a font that cause flickering and see if I can catch a bug. > >> The following can help you see the bug although it won't crash Emacs: > >> o emacs -Q --enable-font-backend -fn SOMEFONT >> o C-u 3 2 M-x hanoi > >> You should see the frame flickering like TV disturbed by static. > > I can confirm the flickering with some fonts of some size. > For instance, this cause flickering: > > emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=16' > > but these don't cause flickering: > > emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=24' > emacs-unicode --enable-font-backend -fn 'lucidatypewriter:pixelsize=16' > > I think the reason is that font-height of "dejavu sans > mono:pixelsize=16" is somehow shorter than the glyph '|' in > that font. So, every time Emacs redraw '|', the upper and > lower lines are also redrawn which leads to the whole buffer > redrawing. For instance, when I replace all occurence of > "?\|" in lisp/play/hanoi.el with "?i", even this: > > emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=16' > > stops flickering. I can confirm this. Do you think that's a bug in dejavu sans mono? > > Perhaps we must do something like this: > > o When we open a font for a frame, check the ascents and > descents of ASCII characters (perhaps checking only "\|/" > is ok), and set font's ascent and descent to the maximum > of them if the font's data is shorter than glyphs' data. regards, -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
