Scrolling

[gmoutso]

Great package! I think I have this bug. When the annotation appears at the very top of the window (or just hidden above) and scroll-down-line, it doesn't move. Scrolling with the mouse makes my cursor go to the top of the buffer. For the mouse wheel I have customized (setq mouse-wheel-scroll-amount '(1 ((shift) . 1))) but the scroll-down-line also appears with emacs -q. Can it be reproduced?

[cage2]

On Mon, Jun 15, 2020 at 11:12:15AM -0700, George Moutsopoulos wrote:

Hi!

Great package!

Thank you! :)

I think I have this bug. When the annotation appears at the very top of the window (or just hidden above) and scroll-down-line, it doesn't move.

I was able to reproduce this issue, funny thing is that, on my system, if I use a numeric prefix n to scroll-down-line with n at least equals to the number of lines the annotation occupies the command works as expected (scroll to the top of the window). Moreover i found that scroll-up-line works.

So seems to me that, for some reason, the two commands consider the text plus the annotation as a single line, but not always. ;)

In my opinion these two commands do not deal well with overlays

https://www.gnu.org/software/emacs/manual/html_node/elisp/Overlays.html

(an annotation is just an overlay)

but this is just, as i said, my opinion and maybe this behaviour is the one expected by design.

Can you confirm that scroll-down-line with a numeric prefix works as you expect?

If this is confirmed i could write to the Emacs mailing list asking for more information.

Scrolling with the mouse makes my cursor go to the top of the buffer. For the mouse wheel I have customized (setq mouse-wheel-scroll-amount '(1 ((shift) . 1)))

[...]

I am sorry but this one I can not reproduce, can you, please, give me some more help how to recreate the problem?

Bye! C.

[gmoutso]

Hi cage2! This is what I have.

The annotation "annotation" appears on a new line below the annotated text "word". The word+annotation occupy two visual lines. Below the annotation is line3.

scroll-up-line treats the word+annotation as one line. Incremental scroll-up-line just passes the screen through the word+annotation combo.

M-2 scroll-up-line treats the word+annotation as two lines. That is, when the word+annotation appear at the top of the screen and M-2 scroll-up-line, line3 is now at the top of the screen, as would happen without any numeric prefix. Same with higher prefix numbers.

Incremental scroll-down-line does not move pass the word+annotation. In fact, incremental scroll-down-line stops with the annotation and not the word at the top of the screen. In this case, a further scroll-down-line does nothing, but a further M-2 scroll-down-line brings the word at the top of the line (rather than one or two lines above word...).

M-2 scroll-down-line treats the word+annotation as two lines. That is, if the third visual line line3 is at the top of the screen, M-2 scroll-down-line brings the word+annotation at the top of the screen. Same with higher prefix numbers.

So in summary, M-2 scroll-up-line and M-2 scroll-down-line have same behavour (word+annotation is scrolled through only once). M-1 scroll-up-line and M-2 scroll-up-line does the same thing (word+annotation is scrolled through only once). And M-1 scroll-down-line stops at annotation.

(setq mouse-wheel-scroll-amount '(1 ((shift) . 1))) was not enough to reproduce it on a clean emacs -q. If I also do (setq mouse-wheel-progressive-speed nil) then scrolling down incrementally, the following happen: 1) line3 at top 2) annotation at top (similar to scroll-down-line) 3) beginning of buffer!

Regards, George

[gmoutso]

So for the time being, scrolling down two lines at a time has solved it for me :)

[cage2]

On Tue, Jun 16, 2020 at 04:14:24AM -0700, George Moutsopoulos wrote:

Hi George!

I can see you spent some time writing this report as it is quite exhaustive, thank you!

Now that the context is more clear i think i was able to reduce the code to get this bug to the one below:

--------8<---------8<--------8<---------8<--------8<---------8<---

(defun scroll-note-property () (let ((prefix-first " \n") (stopper "\n")) (list 'face 'default 'display (concat prefix-first (propertize "foo" 'face '(:background "red" :foreground "yellow")) stopper))))

(defun scroll-note () (add-text-properties 31 32 (scroll-note-property)))

(scroll-note)

--------8<---------8<--------8<---------8<--------8<---------8<---

If you paste this code in a buffer and eval it (M-x eval-buffer) this should add a "note" (with text "foo") just one row below below the first 'defun'. Than if you try scroll-up-line' and then scroll-down-line' you should get the reported bug.

May i ask just to check if this reproduce the bug on your system?

The fact is that annotate.el add the annotated text as a `display' property of the newline character of the text line where the annotated text belong.

So when Emacs process the newline it see the property and print the annotation text instead, this text contains at least a new line (because we want to break the line with the annotated text). For, inexplicable (to me, because of my ignorance), reasons the newline "aliasing" seems to breaks the scrolling.

So said, as i read somewhere, i admire the problem but i have no solution (yet!)! :)

I think i need to ask for help to Emacs devs because this seems to me something related to the core of Emacs itself.

Sorry but i did not yet check the problem with wheel mouse scrolling. :(

Bye! C.

[gmoutso]

With the scroll-down-line I get a new line only.

[cage2]

On Fri, Jun 19, 2020 at 12:34:47PM -0700, George Moutsopoulos wrote:

Hi George!

With the scroll-down-line I get a new line only.

So the bug is confirmed, right?

OK, if so i am going to forward the code above to the Emacs mailing list, likely they have some information about this behaviour.

Let's see what is going to happens! :)

Bye! C.

[cage2]

Hi George!

I forwarded the code above to the Emacs bug tracker, folks was kind and reply to my issue very quickly. Unfortunately this behaviour was not recognized as a bug but as a limitation of the Emacs display routines. The only workaround is to do like you did: prepend an argument to the function scroll-down-line.

At this point i have no clue, the only thing i can do is mentioning this issue in the known bug section of the README file, probably.

Thank you again, for your reports, at least we can warn other users about this issue! :)

Bye! C.

[gmoutso]

Still works great :)

[cage2]

Hi gmoutso!

I am happy that this package is still useful to you! I am investigating the issue related to the mouse wheel and i have to admit that i cannot reproduce the bug, all i get after evaluating the forms you provided is a smooth scrolling (nice!) and a glitch when displaying the first line of the buffer (the one annotated), when i expected the top line to be shown i got an empty line. I need to increment the rotation of the mouse wheel by another "tick", to made the line appears.

I suspect this is related to the display problem but actually this is just a guess.

Thank you for your report! :)

Bye! C.