-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scrolling #70
Comments
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.
|
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.
Regards, |
So for the time being, scrolling down two lines at a time has solved it for me :) |
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.
|
With the scroll-down-line I get a new line only. |
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.
|
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 At this point i have no clue, the only thing i can do is mentioning this issue in the Thank you again, for your reports, at least we can warn other users about this issue! :) Bye! |
Still works great :) |
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! |
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?The text was updated successfully, but these errors were encountered: