emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Display problems with 'before-string in overlay


From: Lennart Borgman (gmail)
Subject: Re: Display problems with 'before-string in overlay
Date: Thu, 12 Apr 2007 15:03:39 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666

Kim F. Storm wrote:
"Lennart Borgman (gmail)" <address@hidden> writes:

Looking at the logic it seems like it perhaps should be like below instead? This at least works in my case. The current test just seems useless. Or perhaps I am just very bad at reading C code?

The "useless" code you refer to was installed to fix a bug, and it
did fix _that_ bug.

The code before my change looked like this:

  if (PT == MATRIX_ROW_END_CHARPOS (row))
    {
      if (CHARPOS (row->end.string_pos) >= 0)
        cursor_row_p = (row->continued_p
                        || PT >= MATRIX_ROW_START_CHARPOS (row));

I thought it was useless because it the first test with PT seems to imply that the second test with PT must be true. I did not look into the structures and how they are used, only the names of the macros and the definition of them.

Do you say that the second test actually could fail? I believed it was perhaps a mis-paste or something.


Now you have found a different bug in the same code, and you propose
a different way to fix _your_ bug.
Indeed your code does look like it could fix the problem - but it
definitely changes the semantics of the test, so there may very well
be other corner casee which are broken by _your_ code.

Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old bug(s).
I must be close to the date in the ChangeLog.

If you think that the test actually does something I can try.


Besides, the ++row seems dangrous to me.  Would row+1 do the same?

Sorry, yes, that is better and my first test now implies it works.

This is the bug I want to have fixed (since it is very visible), but there are other bugs there too. The first one is for the record, perhaps you care about the second:

1) In some situations the cursor can still stop at the end of the first row in the 'before-string. But I have only seen it once and I am not sure how to reproduce it. (It does not happen when the overlay is at 1-1 or at least I have not seen it then.) Does this imply that some other test in cursor_row_p may be wrong?

2) If you shrink the window so that the 'before-string fills from top to bottom the first char after it disappears from the screen. Not extremely serious in itself, but perhaps easy to fix (and it might also point to other troubles, of course). To reproduce this eval the code below (same as before):

(defvar temp-ovl nil)
(defun temp-toggle-ovl()
  (interactive)
  (if temp-ovl
      (progn
        (delete-overlay temp-ovl)
        (setq temp-ovl nil))
    (setq temp-ovl (make-overlay 1 1))
    (let ((s "A string\nwith several rows\nthat should be at top\n"))
      (put-text-property 0 (length s)
                         'face (list (cons 'background-color
                                           "yellow"))
                         s)
      (overlay-put temp-ovl 'before-string s))))

The create a new buffer with two rows:
<<<<<<<<<<
First char may disappear.
But second line is ok.
>>>>>>>>>>

Do

   M-x temp-toggle-ovl

go to char 1 and then shrink the window vertically. When the number of lines gets down to the height of the 'before-string the char "F" disappears. Or the cursor may move to the first line of the 'before-string.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]