Re: Strange display behavior after filling
Thanks for fixing this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
[EMAIL PROTECTED] (Kim F. Storm) writes: > I have installed a further change which seems to fix this. It does, thanks. -- Romain Francoise <[EMAIL PROTECTED]> | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
Romain Francoise <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Kim F. Storm) writes: > >> I changed the code to just recenter which seems to DTRT. > > Hmm. Now the calendar window isn't correctly displayed. I have installed a further change which seems to fix this. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
[EMAIL PROTECTED] (Kim F. Storm) writes: > I changed the code to just recenter which seems to DTRT. Hmm. Now the calendar window isn't correctly displayed. Try: - emacs -Q - M-x calendar RET The top line which shows month names isn't shown, and there is a blank line at the bottom of the window. Without your changes, the calendar fits perfectly in the window. -- Romain Francoise <[EMAIL PROTECTED]> | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> On Thu, 20 Apr 2006 09:36:07 +0900, YAMAMOTO Mitsuharu <[EMAIL >> PROTECTED]> said: > >> On Thu, 20 Apr 2006 01:21:04 +0200, [EMAIL PROTECTED] (Kim F. Storm) >> said: >>> Ok, so my first patch only fixed one instance of this problem. I >>> have committed a different, more generic fix for this, which also >>> attempts to select a more reasonable window start rather than just >>> recentering. > >> Thanks. It works for the cases I've shown. > > Sorry, maybe I should have tested it more carefully. Sometimes it > seems to recenter too much: > > 1. emacs -q > The splash screen is shown. > 2. C-p > The message in *scratch* is not shown. > 3. C-p > Now we can see it. I'm sorry too. The problem is that I set centering_position = 0 which works fine when PT is on the top line, but fails miserably otherwise. I changed the code to just recenter which seems to DTRT. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
> On Thu, 20 Apr 2006 09:36:07 +0900, YAMAMOTO Mitsuharu <[EMAIL > PROTECTED]> said: > On Thu, 20 Apr 2006 01:21:04 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: >> Ok, so my first patch only fixed one instance of this problem. I >> have committed a different, more generic fix for this, which also >> attempts to select a more reasonable window start rather than just >> recentering. > Thanks. It works for the cases I've shown. Sorry, maybe I should have tested it more carefully. Sometimes it seems to recenter too much: 1. emacs -q The splash screen is shown. 2. C-p The message in *scratch* is not shown. 3. C-p Now we can see it. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
> On Thu, 20 Apr 2006 01:21:04 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: > Ok, so my first patch only fixed one instance of this problem. I > have committed a different, more generic fix for this, which also > attempts to select a more reasonable window start rather than just > recentering. Thanks. It works for the cases I've shown. >> The examples I've shown may look artificial, but I sometimes >> experience some redisplay glitches such as violation of the >> assertion "IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it))" in >> set_iterator_to_next, or partial octal representation of a >> multibyte character after fill operations. (The buffer contents >> seems to be correct because C-l fixes redisplay in these cases.) >> So I was trying to find reliably reproducible cases. > Maybe the change will fix those cases -- I don't know. I'll see if the above problems that are not easily reproducible will happen in my daily use. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> On Tue, 18 Apr 2006 13:57:46 +0200, [EMAIL PROTECTED] (Kim F. Storm) >> said: > >> Please test if this gives good results, or if it has some bad >> effects on existing features > > I tried the patch, and I found another case that shows a similar > problem: Ok, so my first patch only fixed one instance of this problem. I have committed a different, more generic fix for this, which also attempts to select a more reasonable window start rather than just recentering. > The examples I've shown may look artificial, but I sometimes > experience some redisplay glitches such as violation of the assertion > "IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it))" in > set_iterator_to_next, or partial octal representation of a multibyte > character after fill operations. (The buffer contents seems to be > correct because C-l fixes redisplay in these cases.) So I was trying > to find reliably reproducible cases. Maybe the change will fix those cases -- I don't know. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
> On Tue, 18 Apr 2006 13:57:46 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: > Please test if this gives good results, or if it has some bad > effects on existing features I tried the patch, and I found another case that shows a similar problem: 1. emacs -D -q (not -Q to show the message in *scratch*) 2. M-q 3. M-< C-e C-d C-e C-d Then the message ";; This buffer ... own buffer." is shown in one line. 4. M-< C-u 1 C-v 5. M-q 6. C-p C-n C-n The examples I've shown may look artificial, but I sometimes experience some redisplay glitches such as violation of the assertion "IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it))" in set_iterator_to_next, or partial octal representation of a multibyte character after fill operations. (The buffer contents seems to be correct because C-l fixes redisplay in these cases.) So I was trying to find reliably reproducible cases. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
Thanks for fixing this. I think your fix is sufficient. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes:
> I found some strange display behavior after filling. In the
> following, "row" means a displayed horizontal segment, and "line"
> means a sequence of characters delimited by newlines.
>
> 1. emacs -D -Q
> 2. M-q (I'm not sure why this is needed.)
> 3. Insert "123456789 " (without quotations or newlines) 18 times.
> Say, C-x ( 1 2 3 4 5 6 7 8 9 SPC C-x ) C-u 1 7 C-x e.
> It is displayed in three rows.
> 4. M-<
> 5. C-u 1 C-v
>
> Now the first row becomes continued to both directions.
>
> 6. M-q
>
> Then the first row is displayed shorter than the second one, whereas
> they have the same number of characters.
>
> 7. C-p C-n C-n
>
> The line number in the mode line says the cursor is at the third line.
> But it is displayed at the second row that corresponds to the second
> line.
The problem starts when the C-u 1 C-v scrolling command moves window
start to a position which happens to be in the middle of a
continuation line.
Now, when the filling command has reformatted the buffer text, the
redisplay code still starts window display at the old window start --
which still is in the middle of a line, but not at the same relative
position in the line as before ... so it gets confused.
This is just one way in which a buffer change can mess things up when
window start is not at the start of a line, so I think it is generally
a bit difficult to find a method which will always select the
intuitively best window start after such a change.
On the other hand, I guess this is not something which happens very
often, so a simpler method is probably ok. Below is a change which
simply will just recenter the display in this case.
Please test if this gives good results, or if it has some bad effects
on existing features
2006-04-18 Kim F. Storm <[EMAIL PROTECTED]>
* xdisp.c (try_window_id): If first window line is a continuation line,
and the first change is before window start, return -1 to select a new
window start.
*** xdisp.c 16 Apr 2006 23:05:20 +0200 1.1086
--- xdisp.c 18 Apr 2006 13:53:04 +0200
***
*** 14263,14269
but why that was tested escapes me at the moment. */
if (CHARPOS (start) >= first_changed_charpos
&& CHARPOS (start) <= last_changed_charpos)
! GIVE_UP (15);
/* Check that window start agrees with the start of the first glyph
row in its current matrix. Check this after we know the window
--- 14263,14278
but why that was tested escapes me at the moment. */
if (CHARPOS (start) >= first_changed_charpos
&& CHARPOS (start) <= last_changed_charpos)
! {
! /* If first window line is a continuation line, and the first
!change is before window start, return -1 to select a new
!window start.*/
! if (NILP (w->start_at_line_beg)
! && CHARPOS (start) > first_changed_charpos)
! return -1;
!
! GIVE_UP (15);
! }
/* Check that window start agrees with the start of the first glyph
row in its current matrix. Check this after we know the window
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange display behavior after filling
> Date: Tue, 11 Apr 2006 11:48:06 +0900 (JST) > From: YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> > > I found some strange display behavior after filling. In the > following, "row" means a displayed horizontal segment, and "line" > means a sequence of characters delimited by newlines. > > 1. emacs -D -Q > 2. M-q (I'm not sure why this is needed.) I don't know either, but it loads newcomment. > 3. Insert "123456789 " (without quotations or newlines) 18 times. > Say, C-x ( 1 2 3 4 5 6 7 8 9 SPC C-x ) C-u 1 7 C-x e. > It is displayed in three rows. > 4. M-< > 5. C-u 1 C-v > > Now the first row becomes continued to both directions. > > 6. M-q > > Then the first row is displayed shorter than the second one, whereas > they have the same number of characters. > > 7. C-p C-n C-n > > The line number in the mode line says the cursor is at the third line. > But it is displayed at the second row that corresponds to the second > line. The problem is with redisplay of the cursor: it is displayed in the wrong place. Try typing C-a and arrow keys, and eventually you will see a second cursor in the correct place. C-l fixes the messed up display. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Strange display behavior after filling
I found some strange display behavior after filling. In the following, "row" means a displayed horizontal segment, and "line" means a sequence of characters delimited by newlines. 1. emacs -D -Q 2. M-q (I'm not sure why this is needed.) 3. Insert "123456789 " (without quotations or newlines) 18 times. Say, C-x ( 1 2 3 4 5 6 7 8 9 SPC C-x ) C-u 1 7 C-x e. It is displayed in three rows. 4. M-< 5. C-u 1 C-v Now the first row becomes continued to both directions. 6. M-q Then the first row is displayed shorter than the second one, whereas they have the same number of characters. 7. C-p C-n C-n The line number in the mode line says the cursor is at the third line. But it is displayed at the second row that corresponds to the second line. YAMAMOTO Mitsuharu [EMAIL PROTECTED] In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars) of 2006-04-11 on church X server distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--x-libraries=/usr/local/lib' 'CFLAGS=-g -O2 -mv8 -DSYNC_INPUT'' 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: ja locale-coding-system: japanese-iso-8bit default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t auto-compression-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
