GNU bug report logs -
#14567
Scrolling of large images
Previous Next
To reply to this bug, email your comments to 14567 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Thu, 06 Jun 2013 16:33:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Thomas Wiecki <thomas.wiecki <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 06 Jun 2013 16:33:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
The scrolling behavior of emacs when there are large images (larger than
the window height) in the buffer seems to broken. Specifically, down-ward
scrolling makes a huge jump over the image as the image is about to move
outside of the current view (it seems the image is treated as a single
line).
image-mode is not applicable as there is text intermixed with images.
This behavior and its implications are also discussed here:
https://github.com/tkf/emacs-ipython-notebook/issues/94
and here:
http://www.randomsample.de/dru5/node/25
"slice-images" is a work-around solution but far from ideal.
Any chance this could get fixed?
Thomas
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Thu, 06 Jun 2013 16:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> Date: Thu, 6 Jun 2013 08:17:02 -0400
>
> The scrolling behavior of emacs when there are large images (larger than
> the window height) in the buffer seems to broken. Specifically, down-ward
> scrolling makes a huge jump over the image as the image is about to move
> outside of the current view (it seems the image is treated as a single
> line).
>
> image-mode is not applicable as there is text intermixed with images.
>
> This behavior and its implications are also discussed here:
> https://github.com/tkf/emacs-ipython-notebook/issues/94
> and here:
> http://www.randomsample.de/dru5/node/25
>
> "slice-images" is a work-around solution but far from ideal.
>
> Any chance this could get fixed?
Any chance to get a simple reproducible recipe, complete with images,
which I could use to look into the problem locally?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Thu, 06 Jun 2013 17:20:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 14567 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
1. Download a large image (e.g.
http://cdn.urbanislandz.com/wp-content/uploads/2011/10/MMSposter-large.jpg)
and save it as /tmp/test.jpg
2. In an emacs buffer type "(insert-image (create-image "/tmp/test.jpg"))"
3. Type some arbitrary lines of text below this line.
4. In first line (containing insert-image), type C-x C-e at end of line to
load the image.
5. Image should appear in buffer.
6. Scroll down repeatedly until past the image.
Expected behavior: Scrolls down smoothly even once scrolled past image.
Observed behavior: Scrolls down smoothly until end of image is reached. At
end of image, the next scroll causes a huge jump in the window so that and
only the text is shown but not any of the residual image.
7. scroll back up
Expected behavior: Scrolls upwards over image.
Observed behavior: Jumps over complete image and shows beginning of buffer.
Please let me know if there is anything else you need.
Thanks,
Thomas
On Thu, Jun 6, 2013 at 12:42 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> > Date: Thu, 6 Jun 2013 08:17:02 -0400
> >
> > The scrolling behavior of emacs when there are large images (larger than
> > the window height) in the buffer seems to broken. Specifically, down-ward
> > scrolling makes a huge jump over the image as the image is about to move
> > outside of the current view (it seems the image is treated as a single
> > line).
> >
> > image-mode is not applicable as there is text intermixed with images.
> >
> > This behavior and its implications are also discussed here:
> > https://github.com/tkf/emacs-ipython-notebook/issues/94
> > and here:
> > http://www.randomsample.de/dru5/node/25
> >
> > "slice-images" is a work-around solution but far from ideal.
> >
> > Any chance this could get fixed?
>
> Any chance to get a simple reproducible recipe, complete with images,
> which I could use to look into the problem locally?
>
> Thanks.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Thu, 06 Jun 2013 17:35:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> Date: Thu, 6 Jun 2013 13:16:43 -0400
> Cc: 14567 <at> debbugs.gnu.org
>
> 1. Download a large image (e.g.
> http://cdn.urbanislandz.com/wp-content/uploads/2011/10/MMSposter-large.jpg)
> and save it as /tmp/test.jpg
> 2. In an emacs buffer type "(insert-image (create-image "/tmp/test.jpg"))"
> 3. Type some arbitrary lines of text below this line.
> 4. In first line (containing insert-image), type C-x C-e at end of line to
> load the image.
> 5. Image should appear in buffer.
> 6. Scroll down repeatedly until past the image.
>
> Expected behavior: Scrolls down smoothly even once scrolled past image.
> Observed behavior: Scrolls down smoothly until end of image is reached. At
> end of image, the next scroll causes a huge jump in the window so that and
> only the text is shown but not any of the residual image.
>
> 7. scroll back up
>
> Expected behavior: Scrolls upwards over image.
> Observed behavior: Jumps over complete image and shows beginning of buffer.
Perfect, thanks. I will take a look.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 08 Jun 2013 14:21:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 06 Jun 2013 20:32:15 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 14567 <at> debbugs.gnu.org
>
> > From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> > Date: Thu, 6 Jun 2013 13:16:43 -0400
> > Cc: 14567 <at> debbugs.gnu.org
> >
> > 1. Download a large image (e.g.
> > http://cdn.urbanislandz.com/wp-content/uploads/2011/10/MMSposter-large.jpg)
> > and save it as /tmp/test.jpg
> > 2. In an emacs buffer type "(insert-image (create-image "/tmp/test.jpg"))"
> > 3. Type some arbitrary lines of text below this line.
> > 4. In first line (containing insert-image), type C-x C-e at end of line to
> > load the image.
> > 5. Image should appear in buffer.
> > 6. Scroll down repeatedly until past the image.
> >
> > Expected behavior: Scrolls down smoothly even once scrolled past image.
> > Observed behavior: Scrolls down smoothly until end of image is reached. At
> > end of image, the next scroll causes a huge jump in the window so that and
> > only the text is shown but not any of the residual image.
> >
> > 7. scroll back up
> >
> > Expected behavior: Scrolls upwards over image.
> > Observed behavior: Jumps over complete image and shows beginning of buffer.
>
> Perfect, thanks. I will take a look.
Can you try the changes below and see if they give good results,
including in the real-life use cases where you bumped into this? Note
that you will have to rebuild Emacs to try this.
Thanks.
=== modified file 'lisp/simple.el'
--- lisp/simple.el 2013-06-05 18:10:27 +0000
+++ lisp/simple.el 2013-06-08 14:14:39 +0000
@@ -4738,20 +4738,35 @@ lines."
(vpos (nth 1 lh))
(ypos (nth 2 lh))
(rbot (nth 3 lh))
+ (this-lh (window-line-height))
+ (this-height (nth 0 this-lh))
+ (this-ypos (nth 2 this-lh))
+ (fch (frame-char-height))
py vs)
(when (or (null lh)
- (>= rbot (frame-char-height))
- (<= ypos (- (frame-char-height))))
+ (>= rbot fch)
+ (<= ypos (- fch))
+ (null this-lh)
+ (<= this-ypos (- fch)))
(unless lh
(let ((wend (pos-visible-in-window-p t nil t)))
(setq rbot (nth 3 wend)
vpos (nth 5 wend))))
+ (unless this-lh
+ (let ((wstart (pos-visible-in-window-p nil nil t)))
+ (setq this-ypos (nth 2 wstart)
+ this-height (nth 4 wstart))))
(cond
- ;; If last line of window is fully visible, move forward.
- ((or (null rbot) (= rbot 0))
+ ;; If last line of window is fully visible, and vscrolling
+ ;; more would make this line invisible, move forward.
+ ((and (or (< (setq vs (window-vscroll nil t)) fch)
+ (<= this-height fch))
+ (or (null rbot) (= rbot 0)))
nil)
- ;; If cursor is not in the bottom scroll margin, move forward.
- ((and (> vpos 0)
+ ;; If cursor is not in the bottom scroll margin, and the
+ ;; current line is is not too tall, move forward.
+ ((and (<= this-height fch)
+ (> vpos 0)
(< (setq py
(or (nth 1 (window-line-height))
(let ((ppos (posn-at-point)))
@@ -4761,9 +4776,10 @@ lines."
nil)
;; When already vscrolled, we vscroll some more if we can,
;; or clear vscroll and move forward at end of tall image.
- ((> (setq vs (window-vscroll nil t)) 0)
- (when (> rbot 0)
- (set-window-vscroll nil (+ vs (min rbot (frame-char-height))) t)))
+ ((> vs 0)
+ (when (or (> rbot 0)
+ (> this-height fch))
+ (set-window-vscroll nil (+ vs fch) t)))
;; If cursor just entered the bottom scroll margin, move forward,
;; but also vscroll one line so redisplay won't recenter.
((and (> vpos 0)
@@ -4808,7 +4824,14 @@ lines."
;; display-based motion doesn't make sense (because each
;; logical line occupies exactly one screen line).
(not (> (window-hscroll) 0)))
- (line-move-visual arg noerror)
+ (prog1 (line-move-visual arg noerror)
+ ;; If we moved into a tall line, set vscroll to make
+ ;; scrolling through tall images more smooth.
+ (let ((lh (line-pixel-height)))
+ (if (and (< arg 0)
+ (< (point) (window-start))
+ (> lh (frame-char-height)))
+ (set-window-vscroll nil (- lh (frame-char-height)) t))))
(line-move-1 arg noerror to-end)))))
;; Display-based alternative to line-move-1.
=== modified file 'src/xdisp.c'
--- src/xdisp.c 2013-06-06 16:35:31 +0000
+++ src/xdisp.c 2013-06-08 14:02:28 +0000
@@ -1217,6 +1217,24 @@ line_bottom_y (struct it *it)
return line_top_y + line_height;
}
+DEFUN ("line-pixel-height", Fline_pixel_height,
+ Sline_pixel_height, 0, 0, 0,
+ doc: /* Return height in pixels of text line in the selected window.
+
+Value is the height in pixels of the line at point. */)
+ (void)
+{
+ struct it it;
+ struct text_pos pt;
+ struct window *w = XWINDOW (selected_window);
+
+ SET_TEXT_POS (pt, PT, PT_BYTE);
+ start_display (&it, w, pt);
+ it.vpos = it.current_y = 0;
+ last_height = 0;
+ return make_number (line_bottom_y (&it));
+}
+
/* Subroutine of pos_visible_p below. Extracts a display string, if
any, from the display spec given as its argument. */
static Lisp_Object
@@ -28665,6 +28683,7 @@ syms_of_xdisp (void)
defsubr (&Stool_bar_lines_needed);
defsubr (&Slookup_image_map);
#endif
+ defsubr (&Sline_pixel_height);
defsubr (&Sformat_mode_line);
defsubr (&Sinvisible_p);
defsubr (&Scurrent_bidi_paragraph_direction);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 08 Jun 2013 15:54:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 14567 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks! Which branch is this based off of? I tried it on bzr trunk (bzr://
bzr.savannah.gnu.org/emacs/trunk) but got:
patching file lisp/simple.el
Hunk #1 FAILED at 4738.
Hunk #2 FAILED at 4761.
Hunk #3 FAILED at 4808.
3 out of 3 hunks FAILED -- saving rejects to file lisp/simple.el.rej
patching file src/xdisp.
On Sat, Jun 8, 2013 at 10:19 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Date: Thu, 06 Jun 2013 20:32:15 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 14567 <at> debbugs.gnu.org
> >
> > > From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> > > Date: Thu, 6 Jun 2013 13:16:43 -0400
> > > Cc: 14567 <at> debbugs.gnu.org
> > >
> > > 1. Download a large image (e.g.
> > >
> http://cdn.urbanislandz.com/wp-content/uploads/2011/10/MMSposter-large.jpg
> )
> > > and save it as /tmp/test.jpg
> > > 2. In an emacs buffer type "(insert-image (create-image
> "/tmp/test.jpg"))"
> > > 3. Type some arbitrary lines of text below this line.
> > > 4. In first line (containing insert-image), type C-x C-e at end of
> line to
> > > load the image.
> > > 5. Image should appear in buffer.
> > > 6. Scroll down repeatedly until past the image.
> > >
> > > Expected behavior: Scrolls down smoothly even once scrolled past image.
> > > Observed behavior: Scrolls down smoothly until end of image is
> reached. At
> > > end of image, the next scroll causes a huge jump in the window so that
> and
> > > only the text is shown but not any of the residual image.
> > >
> > > 7. scroll back up
> > >
> > > Expected behavior: Scrolls upwards over image.
> > > Observed behavior: Jumps over complete image and shows beginning of
> buffer.
> >
> > Perfect, thanks. I will take a look.
>
> Can you try the changes below and see if they give good results,
> including in the real-life use cases where you bumped into this? Note
> that you will have to rebuild Emacs to try this.
>
> Thanks.
>
> === modified file 'lisp/simple.el'
> --- lisp/simple.el 2013-06-05 18:10:27 +0000
> +++ lisp/simple.el 2013-06-08 14:14:39 +0000
> @@ -4738,20 +4738,35 @@ lines."
> (vpos (nth 1 lh))
> (ypos (nth 2 lh))
> (rbot (nth 3 lh))
> + (this-lh (window-line-height))
> + (this-height (nth 0 this-lh))
> + (this-ypos (nth 2 this-lh))
> + (fch (frame-char-height))
> py vs)
> (when (or (null lh)
> - (>= rbot (frame-char-height))
> - (<= ypos (- (frame-char-height))))
> + (>= rbot fch)
> + (<= ypos (- fch))
> + (null this-lh)
> + (<= this-ypos (- fch)))
> (unless lh
> (let ((wend (pos-visible-in-window-p t nil t)))
> (setq rbot (nth 3 wend)
> vpos (nth 5 wend))))
> + (unless this-lh
> + (let ((wstart (pos-visible-in-window-p nil nil t)))
> + (setq this-ypos (nth 2 wstart)
> + this-height (nth 4 wstart))))
> (cond
> - ;; If last line of window is fully visible, move forward.
> - ((or (null rbot) (= rbot 0))
> + ;; If last line of window is fully visible, and vscrolling
> + ;; more would make this line invisible, move forward.
> + ((and (or (< (setq vs (window-vscroll nil t)) fch)
> + (<= this-height fch))
> + (or (null rbot) (= rbot 0)))
> nil)
> - ;; If cursor is not in the bottom scroll margin, move forward.
> - ((and (> vpos 0)
> + ;; If cursor is not in the bottom scroll margin, and the
> + ;; current line is is not too tall, move forward.
> + ((and (<= this-height fch)
> + (> vpos 0)
> (< (setq py
> (or (nth 1 (window-line-height))
> (let ((ppos (posn-at-point)))
> @@ -4761,9 +4776,10 @@ lines."
> nil)
> ;; When already vscrolled, we vscroll some more if we can,
> ;; or clear vscroll and move forward at end of tall image.
> - ((> (setq vs (window-vscroll nil t)) 0)
> - (when (> rbot 0)
> - (set-window-vscroll nil (+ vs (min rbot (frame-char-height)))
> t)))
> + ((> vs 0)
> + (when (or (> rbot 0)
> + (> this-height fch))
> + (set-window-vscroll nil (+ vs fch) t)))
> ;; If cursor just entered the bottom scroll margin, move forward,
> ;; but also vscroll one line so redisplay won't recenter.
> ((and (> vpos 0)
> @@ -4808,7 +4824,14 @@ lines."
> ;; display-based motion doesn't make sense (because each
> ;; logical line occupies exactly one screen line).
> (not (> (window-hscroll) 0)))
> - (line-move-visual arg noerror)
> + (prog1 (line-move-visual arg noerror)
> + ;; If we moved into a tall line, set vscroll to make
> + ;; scrolling through tall images more smooth.
> + (let ((lh (line-pixel-height)))
> + (if (and (< arg 0)
> + (< (point) (window-start))
> + (> lh (frame-char-height)))
> + (set-window-vscroll nil (- lh (frame-char-height)) t))))
> (line-move-1 arg noerror to-end)))))
>
> ;; Display-based alternative to line-move-1.
>
> === modified file 'src/xdisp.c'
> --- src/xdisp.c 2013-06-06 16:35:31 +0000
> +++ src/xdisp.c 2013-06-08 14:02:28 +0000
> @@ -1217,6 +1217,24 @@ line_bottom_y (struct it *it)
> return line_top_y + line_height;
> }
>
> +DEFUN ("line-pixel-height", Fline_pixel_height,
> + Sline_pixel_height, 0, 0, 0,
> + doc: /* Return height in pixels of text line in the selected
> window.
> +
> +Value is the height in pixels of the line at point. */)
> + (void)
> +{
> + struct it it;
> + struct text_pos pt;
> + struct window *w = XWINDOW (selected_window);
> +
> + SET_TEXT_POS (pt, PT, PT_BYTE);
> + start_display (&it, w, pt);
> + it.vpos = it.current_y = 0;
> + last_height = 0;
> + return make_number (line_bottom_y (&it));
> +}
> +
> /* Subroutine of pos_visible_p below. Extracts a display string, if
> any, from the display spec given as its argument. */
> static Lisp_Object
> @@ -28665,6 +28683,7 @@ syms_of_xdisp (void)
> defsubr (&Stool_bar_lines_needed);
> defsubr (&Slookup_image_map);
> #endif
> + defsubr (&Sline_pixel_height);
> defsubr (&Sformat_mode_line);
> defsubr (&Sinvisible_p);
> defsubr (&Scurrent_bidi_paragraph_direction);
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 08 Jun 2013 16:50:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> Date: Sat, 8 Jun 2013 11:52:39 -0400
> Cc: 14567 <at> debbugs.gnu.org
>
> Thanks! Which branch is this based off of?
The trunk, of course.
> I tried it on bzr trunk (bzr://
> bzr.savannah.gnu.org/emacs/trunk) but got:
> patching file lisp/simple.el
> Hunk #1 FAILED at 4738.
> Hunk #2 FAILED at 4761.
> Hunk #3 FAILED at 4808.
> 3 out of 3 hunks FAILED -- saving rejects to file lisp/simple.el.rej
I don't know why, perhaps your mailer did something wicked to the
patch. I just tried to apply the patch I sent, and it applied
cleanly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 08 Jun 2013 17:53:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 14567 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
OK, I got the patch to apply, compiled and installed.
Unfortunately, I still get the scrolling behavior on the test case I
provided. In addition I now often see
"line-move: Wrong type argument: number-or-marker-p, nil" when wanting to
scroll around from certain positions.
Any ideas on what I might be doing wrong?
On Sat, Jun 8, 2013 at 12:49 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> > Date: Sat, 8 Jun 2013 11:52:39 -0400
> > Cc: 14567 <at> debbugs.gnu.org
> >
> > Thanks! Which branch is this based off of?
>
> The trunk, of course.
>
> > I tried it on bzr trunk (bzr://
> > bzr.savannah.gnu.org/emacs/trunk) but got:
> > patching file lisp/simple.el
> > Hunk #1 FAILED at 4738.
> > Hunk #2 FAILED at 4761.
> > Hunk #3 FAILED at 4808.
> > 3 out of 3 hunks FAILED -- saving rejects to file lisp/simple.el.rej
>
> I don't know why, perhaps your mailer did something wicked to the
> patch. I just tried to apply the patch I sent, and it applied
> cleanly.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 08 Jun 2013 18:46:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> Date: Sat, 8 Jun 2013 13:51:33 -0400
> Cc: 14567 <at> debbugs.gnu.org
>
> OK, I got the patch to apply, compiled and installed.
>
> Unfortunately, I still get the scrolling behavior on the test case I
> provided. In addition I now often see
> "line-move: Wrong type argument: number-or-marker-p, nil" when wanting to
> scroll around from certain positions.
>
> Any ideas on what I might be doing wrong?
Did you make sure simple.el is byte-compiled and Emacs is re-dumped
afterwards?
If you made a full build, then please give a precise recipe for
reproducing these error messages, and I will look into it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 08 Jun 2013 21:41:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 14567 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
OK, it must have been something in my config file. If I launch emacs -Q I
can't reproduce the behavior and scrolling seems to work just fine (any
idea? Could be any package I suppose..). I can't really reproduce the
line-move error either in this mode. It does show up occasionally but I
haven't figured out how to explicitly trigger it thus far.
What I have figured out however, is that scrolling using page up/down still
produces funky behavior. To reproduce set cursor at end of buffer, press
page-up, buffer jumps to beginning rather than scrolling over image. Press
page-down several times, cursor gets stuck after first page-down scroll.
On Sat, Jun 8, 2013 at 2:44 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> > Date: Sat, 8 Jun 2013 13:51:33 -0400
> > Cc: 14567 <at> debbugs.gnu.org
> >
> > OK, I got the patch to apply, compiled and installed.
> >
> > Unfortunately, I still get the scrolling behavior on the test case I
> > provided. In addition I now often see
> > "line-move: Wrong type argument: number-or-marker-p, nil" when wanting to
> > scroll around from certain positions.
> >
> > Any ideas on what I might be doing wrong?
>
> Did you make sure simple.el is byte-compiled and Emacs is re-dumped
> afterwards?
>
> If you made a full build, then please give a precise recipe for
> reproducing these error messages, and I will look into it.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 09 Jun 2013 02:45:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
> Date: Sat, 8 Jun 2013 17:39:27 -0400
> Cc: 14567 <at> debbugs.gnu.org
>
> OK, it must have been something in my config file. If I launch emacs -Q I
> can't reproduce the behavior and scrolling seems to work just fine (any
> idea? Could be any package I suppose..).
Try bisecting your .emacs.
> I can't really reproduce the line-move error either in this mode. It
> does show up occasionally but I haven't figured out how to
> explicitly trigger it thus far.
I'll try reproducing it here.
> What I have figured out however, is that scrolling using page up/down still
> produces funky behavior. To reproduce set cursor at end of buffer, press
> page-up, buffer jumps to beginning rather than scrolling over image. Press
> page-down several times, cursor gets stuck after first page-down scroll.
I will look into cursor being stuck, but other than that, moving by
screen-fulls was not supposed to be affected by the change, because
it's not clear what exactly is a "page" in that case. Only scrolling
with C-n/C-p or up/down arrow key was supposed to be affected.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 09 Jun 2013 09:29:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Somehow related to this issue. Is there a way to resize the image in
place to fit into window?
I always struggle with big images in gnus and the only way I can deal
with it is to open in external application.
Thanks,
Vitalie
>> Eli Zaretskii <eliz <at> gnu.org>
>> on Sun, 09 Jun 2013 05:42:15 +0300 wrote:
>> From: Thomas Wiecki <thomas.wiecki <at> gmail.com>
>> Date: Sat, 8 Jun 2013 17:39:27 -0400
>> Cc: 14567 <at> debbugs.gnu.org
>>
>> OK, it must have been something in my config file. If I launch emacs -Q I
>> can't reproduce the behavior and scrolling seems to work just fine (any
>> idea? Could be any package I suppose..).
> Try bisecting your .emacs.
>> I can't really reproduce the line-move error either in this mode. It
>> does show up occasionally but I haven't figured out how to
>> explicitly trigger it thus far.
> I'll try reproducing it here.
>> What I have figured out however, is that scrolling using page up/down still
>> produces funky behavior. To reproduce set cursor at end of buffer, press
>> page-up, buffer jumps to beginning rather than scrolling over image. Press
>> page-down several times, cursor gets stuck after first page-down scroll.
> I will look into cursor being stuck, but other than that, moving by
> screen-fulls was not supposed to be affected by the change, because
> it's not clear what exactly is a "page" in that case. Only scrolling
> with C-n/C-p or up/down arrow key was supposed to be affected.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Tue, 11 Jun 2013 20:16:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii writes:
>> I can't really reproduce the line-move error either in this mode. It
>> does show up occasionally but I haven't figured out how to
>> explicitly trigger it thus far.
>
> I'll try reproducing it here.
I also tried the patch on current trunk. I use the following snippet to
generate a buffer containing large and small images as well as text:
(with-current-buffer (get-buffer-create "test")
(erase-buffer)
(let ((imagelarge (create-image "~/someimage.jpg" 'imagemagick nil :height 2000 :width 1000))
(imagesmall (create-image "~/someimage.jpg" 'imagemagick nil :height 200 :width 100)))
(dotimes (i 20)
(insert "\n*** " (number-to-string i)" ***\nThis is a line of text.\nAnd here's a large image:\n")
(insert-image imagelarge)
(insert "\nAnd a small image:\n")
(insert-image imagesmall))
(goto-char (point-min))))
Obviously, replace "~/someimage.jpg" with something else. Also, Emacs
must be compiled with imagemagick support.
Scrolling using your patch looks already pretty good, but I also get the
'wrong-type-argument' error while scrolling down. I use a maximized
'emacs -Q' on a display with 1366x768 resolution, and here's the backtrace:
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
line-move-partial(1 nil nil)
line-move(1 nil nil 1)
#[0 "\302\300@\303\211\301$\207" [(1) 1 line-move nil] 5 "\n\n(fn)"]()
funcall(#[0 "\302\300@\303\211\301$\207" [(1) 1 line-move nil] 5 "\n\n(fn)"])
next-line(1 1)
call-interactively(next-line nil nil)
command-execute(next-line)
This happens during scrolling when point should switch from the first
small image to the following text line containing "*** 1 ***". The
second large image is already visible at the bottom. I can do
screenshots or even a screencast if necessary.
-David
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 15 Jun 2013 08:25:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: David Engster <deng <at> randomsample.de>
> Cc: Thomas Wiecki <thomas.wiecki <at> gmail.com>, 14567 <at> debbugs.gnu.org
> Date: Tue, 11 Jun 2013 22:14:47 +0200
>
> Eli Zaretskii writes:
> >> I can't really reproduce the line-move error either in this mode. It
> >> does show up occasionally but I haven't figured out how to
> >> explicitly trigger it thus far.
> >
> > I'll try reproducing it here.
>
> I also tried the patch on current trunk. I use the following snippet to
> generate a buffer containing large and small images as well as text:
Thanks. Unfortunately, using Emacs with Imagemagick support is a
no-starter for me. However, I tried to cover every possibility of
using non-numeric values in numeric context. Please try the patch
below (it's relative to the current trunk, not to the previous patch),
and see if it gives good results. If you still get errors, please
manually load simple.el (not simple.elc) into your Emacs, run your
test snippet, and see if the backtrace can pinpoint the place where I
missed something.
Thanks.
=== modified file 'lisp/simple.el'
--- lisp/simple.el 2013-06-13 22:24:52 +0000
+++ lisp/simple.el 2013-06-15 07:57:08 +0000
@@ -4738,22 +4738,39 @@ lines."
(vpos (nth 1 lh))
(ypos (nth 2 lh))
(rbot (nth 3 lh))
+ (this-lh (window-line-height))
+ (this-height (nth 0 this-lh))
+ (this-ypos (nth 2 this-lh))
+ (fch (frame-char-height))
py vs)
(when (or (null lh)
- (>= rbot (frame-char-height))
- (<= ypos (- (frame-char-height))))
+ (>= rbot fch)
+ (<= ypos (- fch))
+ (null this-lh)
+ (<= this-ypos (- fch)))
(unless lh
(let ((wend (pos-visible-in-window-p t nil t)))
(setq rbot (nth 3 wend)
vpos (nth 5 wend))))
+ (unless this-lh
+ (let ((wstart (pos-visible-in-window-p nil nil t)))
+ (setq this-ypos (nth 2 wstart)
+ this-height (nth 4 wstart))))
(cond
- ;; If last line of window is fully visible, move forward.
- ((or (null rbot) (= rbot 0))
+ ;; If last line of window is fully visible, and vscrolling
+ ;; more would make this line invisible, move forward.
+ ((and (or (< (setq vs (window-vscroll nil t)) fch)
+ (null this-height)
+ (<= this-height fch))
+ (or (null rbot) (= rbot 0)))
nil)
- ;; If cursor is not in the bottom scroll margin, move forward.
- ((and (> vpos 0)
+ ;; If cursor is not in the bottom scroll margin, and the
+ ;; current line is is not too tall, move forward.
+ ((and (or (null this-height) (<= this-height fch))
+ vpos
+ (> vpos 0)
(< (setq py
- (or (nth 1 (window-line-height))
+ (or (nth 1 this-lh)
(let ((ppos (posn-at-point)))
(cdr (or (posn-actual-col-row ppos)
(posn-col-row ppos))))))
@@ -4761,19 +4778,21 @@ lines."
nil)
;; When already vscrolled, we vscroll some more if we can,
;; or clear vscroll and move forward at end of tall image.
- ((> (setq vs (window-vscroll nil t)) 0)
- (when (> rbot 0)
- (set-window-vscroll nil (+ vs (min rbot (frame-char-height))) t)))
+ ((> vs 0)
+ (when (or (and rbot (> rbot 0))
+ (and this-height (> this-height fch)))
+ (set-window-vscroll nil (+ vs fch) t)))
;; If cursor just entered the bottom scroll margin, move forward,
;; but also vscroll one line so redisplay won't recenter.
- ((and (> vpos 0)
+ ((and vpos
+ (> vpos 0)
(= py (min (- (window-text-height) scroll-margin 1)
(1- vpos))))
(set-window-vscroll nil (frame-char-height) t)
(line-move-1 arg noerror to-end)
t)
;; If there are lines above the last line, scroll-up one line.
- ((> vpos 0)
+ ((and vpos (> vpos 0))
(scroll-up 1)
t)
;; Finally, start vscroll.
@@ -4808,7 +4827,14 @@ lines."
;; display-based motion doesn't make sense (because each
;; logical line occupies exactly one screen line).
(not (> (window-hscroll) 0)))
- (line-move-visual arg noerror)
+ (prog1 (line-move-visual arg noerror)
+ ;; If we moved into a tall line, set vscroll to make
+ ;; scrolling through tall images more smooth.
+ (let ((lh (line-pixel-height)))
+ (if (and (< arg 0)
+ (< (point) (window-start))
+ (> lh (frame-char-height)))
+ (set-window-vscroll nil (- lh (frame-char-height)) t))))
(line-move-1 arg noerror to-end)))))
;; Display-based alternative to line-move-1.
=== modified file 'src/xdisp.c'
--- src/xdisp.c 2013-06-10 04:36:06 +0000
+++ src/xdisp.c 2013-06-15 07:24:37 +0000
@@ -1217,6 +1217,24 @@ line_bottom_y (struct it *it)
return line_top_y + line_height;
}
+DEFUN ("line-pixel-height", Fline_pixel_height,
+ Sline_pixel_height, 0, 0, 0,
+ doc: /* Return height in pixels of text line in the selected window.
+
+Value is the height in pixels of the line at point. */)
+ (void)
+{
+ struct it it;
+ struct text_pos pt;
+ struct window *w = XWINDOW (selected_window);
+
+ SET_TEXT_POS (pt, PT, PT_BYTE);
+ start_display (&it, w, pt);
+ it.vpos = it.current_y = 0;
+ last_height = 0;
+ return make_number (line_bottom_y (&it));
+}
+
/* Subroutine of pos_visible_p below. Extracts a display string, if
any, from the display spec given as its argument. */
static Lisp_Object
@@ -28691,6 +28709,7 @@ syms_of_xdisp (void)
defsubr (&Stool_bar_lines_needed);
defsubr (&Slookup_image_map);
#endif
+ defsubr (&Sline_pixel_height);
defsubr (&Sformat_mode_line);
defsubr (&Sinvisible_p);
defsubr (&Scurrent_bidi_paragraph_direction);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 15 Jun 2013 09:03:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 14567 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii writes:
>> >> I can't really reproduce the line-move error either in this mode. It
>> >> does show up occasionally but I haven't figured out how to
>> >> explicitly trigger it thus far.
>> >
>> > I'll try reproducing it here.
>>
>> I also tried the patch on current trunk. I use the following snippet to
>> generate a buffer containing large and small images as well as text:
>
> Thanks. Unfortunately, using Emacs with Imagemagick support is a
> no-starter for me.
It's only needed for scaling, though. If you have at least libjpeg, then
just download those two images
http://randomsample.de/bigimage.jpg
http://randomsample.de/smallimage.jpg
and use
(with-current-buffer (get-buffer-create "test")
(erase-buffer)
(let ((imagelarge (create-image "~/bigimage.jpg"))
(imagesmall (create-image "~/smallimage.jpg")))
(dotimes (i 20)
(insert "\n*** " (number-to-string i)" ***\nThis is a line of text.\nAnd here's a large image:\n")
(insert-image imagelarge)
(insert "\nAnd a small image:\n")
(insert-image imagesmall))
(goto-char (point-min))))
>However, I tried to cover every possibility of using non-numeric values
>in numeric context. Please try the patch below (it's relative to the
>current trunk, not to the previous patch), and see if it gives good
>results. If you still get errors, please manually load simple.el (not
>simple.elc) into your Emacs, run your test snippet, and see if the
>backtrace can pinpoint the place where I missed something.
It fails in line 4789 because 'py' is nil. I attached the backtrace.
-David
[backtrace.txt (text/plain, inline)]
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
=(nil 4)
(and vpos (> vpos 0) (= py (min (- (window-text-height) scroll-margin 1) (1- vpos))))
(cond ((and (or (< (setq vs (window-vscroll nil t)) fch) (null this-height) (<= this-height fch)) (or (null rbot) (= rbot 0))) nil) ((and (or (null this-height) (<= this-height fch)) vpos (> vpos 0) (< (setq py (or (nth 1 this-lh) (let (...) (cdr ...)))) (min (- (window-text-height) scroll-margin 1) (1- vpos)))) nil) ((> vs 0) (if (or (and rbot (> rbot 0)) (and this-height (> this-height fch))) (progn (set-window-vscroll nil (+ vs fch) t)))) ((and vpos (> vpos 0) (= py (min (- (window-text-height) scroll-margin 1) (1- vpos)))) (set-window-vscroll nil (frame-char-height) t) (line-move-1 arg noerror to-end) t) ((and vpos (> vpos 0)) (scroll-up 1) t) (t (set-window-vscroll nil (frame-char-height) t)))
(progn (if lh nil (let ((wend (pos-visible-in-window-p t nil t))) (setq rbot (nth 3 wend) vpos (nth 5 wend)))) (if this-lh nil (let ((wstart (pos-visible-in-window-p nil nil t))) (setq this-ypos (nth 2 wstart) this-height (nth 4 wstart)))) (cond ((and (or (< (setq vs (window-vscroll nil t)) fch) (null this-height) (<= this-height fch)) (or (null rbot) (= rbot 0))) nil) ((and (or (null this-height) (<= this-height fch)) vpos (> vpos 0) (< (setq py (or (nth 1 this-lh) (let ... ...))) (min (- (window-text-height) scroll-margin 1) (1- vpos)))) nil) ((> vs 0) (if (or (and rbot (> rbot 0)) (and this-height (> this-height fch))) (progn (set-window-vscroll nil (+ vs fch) t)))) ((and vpos (> vpos 0) (= py (min (- (window-text-height) scroll-margin 1) (1- vpos)))) (set-window-vscroll nil (frame-char-height) t) (line-move-1 arg noerror to-end) t) ((and vpos (> vpos 0)) (scroll-up 1) t) (t (set-window-vscroll nil (frame-char-height) t))))
(if (or (null lh) (>= rbot fch) (<= ypos (- fch)) (null this-lh) (<= this-ypos (- fch))) (progn (if lh nil (let ((wend (pos-visible-in-window-p t nil t))) (setq rbot (nth 3 wend) vpos (nth 5 wend)))) (if this-lh nil (let ((wstart (pos-visible-in-window-p nil nil t))) (setq this-ypos (nth 2 wstart) this-height (nth 4 wstart)))) (cond ((and (or (< (setq vs ...) fch) (null this-height) (<= this-height fch)) (or (null rbot) (= rbot 0))) nil) ((and (or (null this-height) (<= this-height fch)) vpos (> vpos 0) (< (setq py (or ... ...)) (min (- ... scroll-margin 1) (1- vpos)))) nil) ((> vs 0) (if (or (and rbot (> rbot 0)) (and this-height (> this-height fch))) (progn (set-window-vscroll nil (+ vs fch) t)))) ((and vpos (> vpos 0) (= py (min (- ... scroll-margin 1) (1- vpos)))) (set-window-vscroll nil (frame-char-height) t) (line-move-1 arg noerror to-end) t) ((and vpos (> vpos 0)) (scroll-up 1) t) (t (set-window-vscroll nil (frame-char-height) t)))))
(let* ((lh (window-line-height -1)) (vpos (nth 1 lh)) (ypos (nth 2 lh)) (rbot (nth 3 lh)) (this-lh (window-line-height)) (this-height (nth 0 this-lh)) (this-ypos (nth 2 this-lh)) (fch (frame-char-height)) py vs) (if (or (null lh) (>= rbot fch) (<= ypos (- fch)) (null this-lh) (<= this-ypos (- fch))) (progn (if lh nil (let ((wend (pos-visible-in-window-p t nil t))) (setq rbot (nth 3 wend) vpos (nth 5 wend)))) (if this-lh nil (let ((wstart (pos-visible-in-window-p nil nil t))) (setq this-ypos (nth 2 wstart) this-height (nth 4 wstart)))) (cond ((and (or (< ... fch) (null this-height) (<= this-height fch)) (or (null rbot) (= rbot 0))) nil) ((and (or (null this-height) (<= this-height fch)) vpos (> vpos 0) (< (setq py ...) (min ... ...))) nil) ((> vs 0) (if (or (and rbot ...) (and this-height ...)) (progn (set-window-vscroll nil ... t)))) ((and vpos (> vpos 0) (= py (min ... ...))) (set-window-vscroll nil (frame-char-height) t) (line-move-1 arg noerror to-end) t) ((and vpos (> vpos 0)) (scroll-up 1) t) (t (set-window-vscroll nil (frame-char-height) t))))))
(if (< arg 0) (let ((vs (window-vscroll nil t))) (if (> vs (frame-char-height)) (progn (set-window-vscroll nil (- vs (frame-char-height)) t)))) (let* ((lh (window-line-height -1)) (vpos (nth 1 lh)) (ypos (nth 2 lh)) (rbot (nth 3 lh)) (this-lh (window-line-height)) (this-height (nth 0 this-lh)) (this-ypos (nth 2 this-lh)) (fch (frame-char-height)) py vs) (if (or (null lh) (>= rbot fch) (<= ypos (- fch)) (null this-lh) (<= this-ypos (- fch))) (progn (if lh nil (let ((wend ...)) (setq rbot (nth 3 wend) vpos (nth 5 wend)))) (if this-lh nil (let ((wstart ...)) (setq this-ypos (nth 2 wstart) this-height (nth 4 wstart)))) (cond ((and (or ... ... ...) (or ... ...)) nil) ((and (or ... ...) vpos (> vpos 0) (< ... ...)) nil) ((> vs 0) (if (or ... ...) (progn ...))) ((and vpos (> vpos 0) (= py ...)) (set-window-vscroll nil (frame-char-height) t) (line-move-1 arg noerror to-end) t) ((and vpos (> vpos 0)) (scroll-up 1) t) (t (set-window-vscroll nil (frame-char-height) t)))))))
line-move-partial(1 nil nil)
(and auto-window-vscroll try-vscroll (= (abs arg) 1) (zerop scroll-conservatively) (not defining-kbd-macro) (not executing-kbd-macro) (line-move-partial arg noerror to-end))
(if (and auto-window-vscroll try-vscroll (= (abs arg) 1) (zerop scroll-conservatively) (not defining-kbd-macro) (not executing-kbd-macro) (line-move-partial arg noerror to-end)) nil (set-window-vscroll nil 0 t) (if (and line-move-visual (not goal-column) (not (> (window-hscroll) 0))) (prog1 (line-move-visual arg noerror) (let ((lh (line-pixel-height))) (if (and (< arg 0) (< (point) (window-start)) (> lh (frame-char-height))) (set-window-vscroll nil (- lh (frame-char-height)) t)))) (line-move-1 arg noerror to-end)))
(if noninteractive (forward-line arg) (if (and auto-window-vscroll try-vscroll (= (abs arg) 1) (zerop scroll-conservatively) (not defining-kbd-macro) (not executing-kbd-macro) (line-move-partial arg noerror to-end)) nil (set-window-vscroll nil 0 t) (if (and line-move-visual (not goal-column) (not (> (window-hscroll) 0))) (prog1 (line-move-visual arg noerror) (let ((lh (line-pixel-height))) (if (and (< arg 0) (< ... ...) (> lh ...)) (set-window-vscroll nil (- lh ...) t)))) (line-move-1 arg noerror to-end))))
line-move(1 nil nil 1)
(condition-case err (line-move arg nil nil try-vscroll) ((beginning-of-buffer end-of-buffer) (signal (car err) (cdr err))))
(if (called-interactively-p (quote interactive)) (condition-case err (line-move arg nil nil try-vscroll) ((beginning-of-buffer end-of-buffer) (signal (car err) (cdr err)))) (line-move arg nil nil try-vscroll))
(if (and next-line-add-newlines (= arg 1)) (if (save-excursion (end-of-line) (eobp)) (let ((abbrev-mode nil)) (end-of-line) (insert (if use-hard-newlines hard-newline "\n"))) (line-move arg nil nil try-vscroll)) (if (called-interactively-p (quote interactive)) (condition-case err (line-move arg nil nil try-vscroll) ((beginning-of-buffer end-of-buffer) (signal (car err) (cdr err)))) (line-move arg nil nil try-vscroll)))
next-line(1 1)
call-interactively(next-line nil nil)
(prog1 (call-interactively cmd record-flag keys) (if (and (symbolp cmd) (get cmd (quote byte-obsolete-info)) (not (get cmd (quote command-execute-obsolete-warned)))) (progn (put cmd (quote command-execute-obsolete-warned) t) (message "%s" (macroexp--obsolete-warning cmd (get cmd (quote byte-obsolete-info)) "command")))))
(cond ((arrayp final) (if record-flag (progn (setq command-history (cons (list (quote execute-kbd-macro) final prefixarg) command-history)) (if (and (numberp history-length) (> history-length 0)) (progn (let (...) (if ... ...)))))) (execute-kbd-macro final prefixarg)) (t (prog1 (call-interactively cmd record-flag keys) (if (and (symbolp cmd) (get cmd (quote byte-obsolete-info)) (not (get cmd (quote command-execute-obsolete-warned)))) (progn (put cmd (quote command-execute-obsolete-warned) t) (message "%s" (macroexp--obsolete-warning cmd (get cmd ...) "command")))))))
(let ((final cmd)) (while (progn (setq final (indirect-function final)) (if (autoloadp final) (setq final (autoload-do-load final cmd))))) (cond ((arrayp final) (if record-flag (progn (setq command-history (cons (list ... final prefixarg) command-history)) (if (and (numberp history-length) (> history-length 0)) (progn (let ... ...))))) (execute-kbd-macro final prefixarg)) (t (prog1 (call-interactively cmd record-flag keys) (if (and (symbolp cmd) (get cmd (quote byte-obsolete-info)) (not (get cmd ...))) (progn (put cmd (quote command-execute-obsolete-warned) t) (message "%s" (macroexp--obsolete-warning cmd ... "command"))))))))
(let ((prefixarg (if special nil (prog1 prefix-arg (setq current-prefix-arg prefix-arg) (setq prefix-arg nil))))) (and (symbolp cmd) (get cmd (quote disabled)) (run-hooks (quote disabled-command-function))) (let ((final cmd)) (while (progn (setq final (indirect-function final)) (if (autoloadp final) (setq final (autoload-do-load final cmd))))) (cond ((arrayp final) (if record-flag (progn (setq command-history (cons ... command-history)) (if (and ... ...) (progn ...)))) (execute-kbd-macro final prefixarg)) (t (prog1 (call-interactively cmd record-flag keys) (if (and (symbolp cmd) (get cmd ...) (not ...)) (progn (put cmd ... t) (message "%s" ...))))))))
command-execute(next-line)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 15 Jun 2013 09:40:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: David Engster <deng <at> randomsample.de>
> Cc: thomas.wiecki <at> gmail.com, 14567 <at> debbugs.gnu.org
> Date: Sat, 15 Jun 2013 11:02:46 +0200
>
> > Thanks. Unfortunately, using Emacs with Imagemagick support is a
> > no-starter for me.
>
> It's only needed for scaling, though. If you have at least libjpeg, then
> just download those two images
>
> http://randomsample.de/bigimage.jpg
> http://randomsample.de/smallimage.jpg
>
> and use
>
> (with-current-buffer (get-buffer-create "test")
> (erase-buffer)
> (let ((imagelarge (create-image "~/bigimage.jpg"))
> (imagesmall (create-image "~/smallimage.jpg")))
> (dotimes (i 20)
> (insert "\n*** " (number-to-string i)" ***\nThis is a line of text.\nAnd here's a large image:\n")
> (insert-image imagelarge)
> (insert "\nAnd a small image:\n")
> (insert-image imagesmall))
> (goto-char (point-min))))
>
> >However, I tried to cover every possibility of using non-numeric values
> >in numeric context. Please try the patch below (it's relative to the
> >current trunk, not to the previous patch), and see if it gives good
> >results. If you still get errors, please manually load simple.el (not
> >simple.elc) into your Emacs, run your test snippet, and see if the
> >backtrace can pinpoint the place where I missed something.
>
> It fails in line 4789 because 'py' is nil. I attached the backtrace.
Thanks. I fixed that and committed the result as trunk revision
112998. I am not closing the bug yet because it still jumps
sometimes, although the context of point is now preserved, unlike
before the changes. I will see if I can prevent those jumps.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 15 Jun 2013 10:09:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii writes:
> Thanks. I fixed that and committed the result as trunk revision
> 112998. I am not closing the bug yet because it still jumps
> sometimes, although the context of point is now preserved, unlike
> before the changes. I will see if I can prevent those jumps.
Thank you, Eli! This is a great improvement.
-David
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 15 Jun 2013 11:14:01 GMT)
Full text and
rfc822 format available.
Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):
David Engster <deng <at> randomsample.de> writes:
> Eli Zaretskii writes:
>> Thanks. I fixed that and committed the result as trunk revision
>> 112998. I am not closing the bug yet because it still jumps
>> sometimes, although the context of point is now preserved, unlike
>> before the changes. I will see if I can prevent those jumps.
>
> Thank you, Eli! This is a great improvement.
Thanks for this, working fine here, however it would be great to be able
to scroll horizontally too.
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 15 Jun 2013 11:27:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Date: Sat, 15 Jun 2013 13:13:05 +0200
>
> however it would be great to be able to scroll horizontally too.
That's a much larger project, since we lack infrastructure to scroll
horizontally by pixels.
Feel free to file a separate feature request bug report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 15 Jun 2013 12:42:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 15 Jun 2013 14:26:13 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 14567 <at> debbugs.gnu.org
>
> > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> > Date: Sat, 15 Jun 2013 13:13:05 +0200
> >
> > however it would be great to be able to scroll horizontally too.
>
> That's a much larger project, since we lack infrastructure to scroll
> horizontally by pixels.
Actually, I see that I was wrong: set-window-hscroll can do the job.
The only problem is to get C-f/C-b and <left>/<right> keys invoke that
function when appropriate. Patches are welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 16 Jun 2013 05:35:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sat, 15 Jun 2013 14:26:13 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 14567 <at> debbugs.gnu.org
>>
>> > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> > Date: Sat, 15 Jun 2013 13:13:05 +0200
>> >
>> > however it would be great to be able to scroll horizontally too.
>>
>> That's a much larger project, since we lack infrastructure to scroll
>> horizontally by pixels.
>
> Actually, I see that I was wrong: set-window-hscroll can do the job.
> The only problem is to get C-f/C-b and <left>/<right> keys invoke that
> function when appropriate. Patches are welcome.
I don't understand how to use this, it is actually setting the number of
column where to start scrolling, and it seems an image have only one
column?
Though only setting `auto-hscroll-mode' to nil let move with C-f/b and
left/right as expected, may be this value should be let-bounded when
image-mode is detected?
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 16 Jun 2013 06:20:02 GMT)
Full text and
rfc822 format available.
Message #68 received at submit <at> debbugs.gnu.org (full text, mbox):
Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Sat, 15 Jun 2013 14:26:13 +0300
>>> From: Eli Zaretskii <eliz <at> gnu.org>
>>> Cc: 14567 <at> debbugs.gnu.org
>>>
>>> > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>>> > Date: Sat, 15 Jun 2013 13:13:05 +0200
>>> >
>>> > however it would be great to be able to scroll horizontally too.
>>>
>>> That's a much larger project, since we lack infrastructure to scroll
>>> horizontally by pixels.
>>
>> Actually, I see that I was wrong: set-window-hscroll can do the job.
>> The only problem is to get C-f/C-b and <left>/<right> keys invoke that
>> function when appropriate. Patches are welcome.
>
> I don't understand how to use this, it is actually setting the number of
> column where to start scrolling, and it seems an image have only one
> column?
>
> Though only setting `auto-hscroll-mode' to nil let move with C-f/b and
> left/right as expected, may be this value should be let-bounded when
> image-mode is detected?
I saw auto-hscroll-mode was already used, but have no effect, when
moving it to image-mode and make it buffer-local, it is working.
However, navigation in image looks a little slower than scrolling
vertically, but maybe I am wrong.
diff --git a/lisp/image-mode.el b/lisp/image-mode.el
index 30dfd04..fdede81 100644
--- a/lisp/image-mode.el
+++ b/lisp/image-mode.el
@@ -446,7 +446,8 @@ to toggle between display as an image and display as text."
(kill-all-local-variables)
(setq major-mode 'image-mode)
-
+ ;; Allow navigation of large images.
+ (set (make-variable-buffer-local 'auto-hscroll-mode) nil)
(if (not (image-get-display-property))
(progn
(image-toggle-display-image)
@@ -643,8 +644,6 @@ was inserted."
(if (coding-system-equal (coding-system-base buffer-file-coding-system)
'no-conversion)
(setq-local find-file-literally t))
- ;; Allow navigation of large images.
- (setq-local auto-hscroll-mode nil)
(setq image-type type)
(if (eq major-mode 'image-mode)
(setq mode-name (format "Image[%s]" type)))
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 16 Jun 2013 16:25:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Date: Sun, 16 Jun 2013 08:18:57 +0200
>
> Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:
>
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> Date: Sat, 15 Jun 2013 14:26:13 +0300
> >>> From: Eli Zaretskii <eliz <at> gnu.org>
> >>> Cc: 14567 <at> debbugs.gnu.org
> >>>
> >>> > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> >>> > Date: Sat, 15 Jun 2013 13:13:05 +0200
> >>> >
> >>> > however it would be great to be able to scroll horizontally too.
> >>>
> >>> That's a much larger project, since we lack infrastructure to scroll
> >>> horizontally by pixels.
> >>
> >> Actually, I see that I was wrong: set-window-hscroll can do the job.
> >> The only problem is to get C-f/C-b and <left>/<right> keys invoke that
> >> function when appropriate. Patches are welcome.
> >
> > I don't understand how to use this, it is actually setting the number of
> > column where to start scrolling, and it seems an image have only one
> > column?
> >
> > Though only setting `auto-hscroll-mode' to nil let move with C-f/b and
> > left/right as expected, may be this value should be let-bounded when
> > image-mode is detected?
>
> I saw auto-hscroll-mode was already used, but have no effect, when
> moving it to image-mode and make it buffer-local, it is working.
> However, navigation in image looks a little slower than scrolling
> vertically, but maybe I am wrong.
>
>
> diff --git a/lisp/image-mode.el b/lisp/image-mode.el
> index 30dfd04..fdede81 100644
> --- a/lisp/image-mode.el
> +++ b/lisp/image-mode.el
I'm confused: didn't you want C-f/C-b and the arrows to scroll images
in modes other than image-mode? I mentioned image-mode only as
example of usage of set-window-hscroll, since image-mode already binds
the movement keys to a command that scrolls the image horizontally.
The idea was to use something similar in other modes, when an image is
present in the window.
Wasn't that what you wanted? If so, why are you suggesting changes to
image-mode?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Mon, 17 Jun 2013 05:02:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Date: Sun, 16 Jun 2013 08:18:57 +0200
>>
>> Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:
>>
>> > Eli Zaretskii <eliz <at> gnu.org> writes:
>> >
>> >>> Date: Sat, 15 Jun 2013 14:26:13 +0300
>> >>> From: Eli Zaretskii <eliz <at> gnu.org>
>> >>> Cc: 14567 <at> debbugs.gnu.org
>> >>>
>> >>> > From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> >>> > Date: Sat, 15 Jun 2013 13:13:05 +0200
>> >>> >
>> >>> > however it would be great to be able to scroll horizontally too.
>> >>>
>> >>> That's a much larger project, since we lack infrastructure to scroll
>> >>> horizontally by pixels.
>> >>
>> >> Actually, I see that I was wrong: set-window-hscroll can do the job.
>> >> The only problem is to get C-f/C-b and <left>/<right> keys invoke that
>> >> function when appropriate. Patches are welcome.
>> >
>> > I don't understand how to use this, it is actually setting the number of
>> > column where to start scrolling, and it seems an image have only one
>> > column?
>> >
>> > Though only setting `auto-hscroll-mode' to nil let move with C-f/b and
>> > left/right as expected, may be this value should be let-bounded when
>> > image-mode is detected?
>>
>> I saw auto-hscroll-mode was already used, but have no effect, when
>> moving it to image-mode and make it buffer-local, it is working.
>> However, navigation in image looks a little slower than scrolling
>> vertically, but maybe I am wrong.
>>
>>
>> diff --git a/lisp/image-mode.el b/lisp/image-mode.el
>> index 30dfd04..fdede81 100644
>> --- a/lisp/image-mode.el
>> +++ b/lisp/image-mode.el
>
> I'm confused: didn't you want C-f/C-b and the arrows to scroll images
> in modes other than image-mode? I mentioned image-mode only as
> example of usage of set-window-hscroll, since image-mode already binds
> the movement keys to a command that scrolls the image horizontally.
Which command?
I see that forward-char is remapped to image-forward-hscroll and same
for backward-char, but it is not working because auto-hscroll-mode is
not set correctly.
But may be I missed something?
> The idea was to use something similar in other modes, when an image is
> present in the window.
>
> Wasn't that what you wanted?
Yes also.
> If so, why are you suggesting changes to image-mode?
To allow navigation with C-f/b and left/right which is not working actually.
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Mon, 17 Jun 2013 15:15:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: 14567 <at> debbugs.gnu.org
> Date: Mon, 17 Jun 2013 06:57:21 +0200
>
> > I'm confused: didn't you want C-f/C-b and the arrows to scroll images
> > in modes other than image-mode? I mentioned image-mode only as
> > example of usage of set-window-hscroll, since image-mode already binds
> > the movement keys to a command that scrolls the image horizontally.
> Which command?
This one:
> I see that forward-char is remapped to image-forward-hscroll and same
> for backward-char
> but it is not working because auto-hscroll-mode is
> not set correctly.
Horizontal scrolling works just fine for me without any changes, when
I visit an image file (which automatically puts the buffer into
image-mode). If this is the use case you were talking about, then our
observations don't match.
> > If so, why are you suggesting changes to image-mode?
> To allow navigation with C-f/b and left/right which is not working actually.
They do for me, in image-mode. The challenge is to support that in
other modes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Tue, 18 Jun 2013 11:36:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: 14567 <at> debbugs.gnu.org
>> Date: Mon, 17 Jun 2013 06:57:21 +0200
>>
>> > I'm confused: didn't you want C-f/C-b and the arrows to scroll images
>> > in modes other than image-mode? I mentioned image-mode only as
>> > example of usage of set-window-hscroll, since image-mode already binds
>> > the movement keys to a command that scrolls the image horizontally.
>> Which command?
>
> This one:
>
>> I see that forward-char is remapped to image-forward-hscroll and same
>> for backward-char
>
>
>> but it is not working because auto-hscroll-mode is
>> not set correctly.
>
> Horizontal scrolling works just fine for me without any changes, when
> I visit an image file (which automatically puts the buffer into
> image-mode). If this is the use case you were talking about, then our
> observations don't match.
They don't match, it is not working for me.
>> > If so, why are you suggesting changes to image-mode?
>> To allow navigation with C-f/b and left/right which is not working actually.
>
> They do for me, in image-mode.
It is not working for me without the changes I sent:
C-f is going straight to the right edge of the image, and C-b is doing nothing.
> The challenge is to support that in other modes.
I understood this, but it should be fixed first in image-mode (which is trivial).
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Tue, 18 Jun 2013 16:14:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: 14567 <at> debbugs.gnu.org
> Date: Tue, 18 Jun 2013 13:35:03 +0200
>
> > Horizontal scrolling works just fine for me without any changes, when
> > I visit an image file (which automatically puts the buffer into
> > image-mode). If this is the use case you were talking about, then our
> > observations don't match.
>
> They don't match, it is not working for me.
Fascinating. Do you perhaps turn on image-mode manually? What I did
was visit an image file with "C-x C-f".
> > The challenge is to support that in other modes.
>
> I understood this, but it should be fixed first in image-mode (which is trivial).
I don't see how image-mode is related to the issue at hand. We want
horizontal scrolling in any mode that displays an embedded image.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Wed, 19 Jun 2013 06:45:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Fascinating. Do you perhaps turn on image-mode manually?
No.
> What I did was visit an image file with "C-x C-f".
Me too.
I will keep in my .emacs:
(add-hook 'image-mode-hook #'(lambda () (set (make-variable-buffer-local
'auto-hscroll-mode) nil)))
until it is fixed.
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 06 Jul 2013 09:03:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Hi. I'm seeing the patches meant to address this bug break plain-text
scrolling. I'm reporting this new issue here, since it seems on-topic.
I'm running a close-to-HEAD emacs on a Debian box. The most recent
change to simple.el is this:
http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/simple.el?id=a7484019a30de380087389ccc8e5b0d0b8dae290
I'm observing that under some specific conditions (ones that my .emacs
just happens to hit) C-f can get stuck scrolling text instead of going
to the next line. To make the bug happen, I do this:
1. Load a text file. This is plain ASCII. No images or unicode or
anything interesting. A nice test case is the output of 'seq 1000'
2. Press C-f repeatedly until the point reaches the bottom of the
screen; this works fine
3. When at the bottom of the screen C-f scrolls the text one line up,
while keeping the point where it was in the buffer. Now the point
gets stuck, and subsequent C-f/C-b just scroll the screen; the point
is stuck.
The bug requires particular .emacs settings. I wittled it down to this:
(custom-set-variables
'(default-frame-alist
'((font . "-adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1")))
'(inhibit-startup-screen t))
(global-hl-line-mode)
The inhibit-startup-screen is there to be nicer; may not be required for
the bug. The (global-hl-line-mode) is significant. The bug doesn't
happen without it. That font is significant also. Other fonts seem to
work without the bug. I suspect the window sizes are significant as
well. I can see the bug if I launch 'emacs -geometry 30x30'. The
width/height of the emacs window as reported by xwininfo is then
308x455.
This is 100% reproducible for me. I suspect it may not be so for others.
Let me know if I should run any specific tests to get to the bottom of
this.
Thanks
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 06 Jul 2013 11:04:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Sat, 06 Jul 2013 02:02:16 -0700
>
> 2. Press C-f repeatedly until the point reaches the bottom of the
> screen; this works fine
>
> 3. When at the bottom of the screen C-f scrolls the text one line up,
> while keeping the point where it was in the buffer. Now the point
> gets stuck, and subsequent C-f/C-b just scroll the screen; the point
> is stuck.
You mean, "C-x =" reports the same value no matter how many times you
press C-f or C-b?
> The bug requires particular .emacs settings. I wittled it down to this:
>
> (custom-set-variables
> '(default-frame-alist
> '((font . "-adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1")))
> '(inhibit-startup-screen t))
>
> (global-hl-line-mode)
Thanks, but I cannot follow this recipe, since I don't have that font.
And with a few other fonts I tried, I cannot reproduce the problem.
Moreover, the changes in this bug report are not supposed to affect
C-f/C-b in any way. If you revert the changes in simple.el introduced
in revision 112998, does this problem go away?
Does any file reproduces the problem, or only some? E.g., does
xdisp.c from the Emacs sources reproduce it? If not, what is special
about the files you use to reproduce the problem? Is the last line
only partially visible, per chance? If you set auto-window-vscroll to
nil, does the problem still happen?
> This is 100% reproducible for me. I suspect it may not be so for others.
> Let me know if I should run any specific tests to get to the bottom of
> this.
Well, not being dependent on a particular font would be a start. An
easier reproducing recipe would be even better.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 06 Jul 2013 16:15:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Dima Kogan <dima <at> secretsauce.net>
>> Date: Sat, 06 Jul 2013 02:02:16 -0700
>>
>> 2. Press C-f repeatedly until the point reaches the bottom of the
>> screen; this works fine
>>
>> 3. When at the bottom of the screen C-f scrolls the text one line up,
>> while keeping the point where it was in the buffer. Now the point
>> gets stuck, and subsequent C-f/C-b just scroll the screen; the point
>> is stuck.
>
> You mean, "C-x =" reports the same value no matter how many times you
> press C-f or C-b?
First off, there was a very important brain fart in what I just said. I
meant C-n/C-p instead of C-f/C-b everywhere in this bug report. Oops.
This was probably the worst way to mess up this bug report. Hopefully it
makes a bit more sense now. Sorry.
C-x = does report the same value with C-n/C-p pressed as long as there
is room to scroll; if we're already looking at the start of the
document, then C-p does the normal unbugged thing, since it can't scroll
back any further.
> Moreover, the changes in this bug report are not supposed to affect
> C-f/C-b in any way. If you revert the changes in simple.el introduced
> in revision 112998, does this problem go away?
Like I said above, I badly flubbed the report; it's actually about
C-n/C-p. And yes; reverting that revision makes things work again.
> Does any file reproduces the problem, or only some? E.g., does
> xdisp.c from the Emacs sources reproduce it?
Any file does it. I use the output of `seq 1000`, which is not very
special.
> Is the last line only partially visible, per chance?
No. The edge of the buffer looks like it aligns with the bottom edge of
the last line of text, at least to my eye. If I mess with the displayed
text more by pressing C-x C-+ several times then the last line IS only
partially visible. Then I get the same point-getting-stuck behavior, but
it recovers after a handful of scroll-only C-n presses. The exact number
depends on window size, font size, how many times C-x C-+ was pressed,
etc.
> If you set auto-window-vscroll to nil, does the problem still happen?
No. That fixes it.
>> This is 100% reproducible for me. I suspect it may not be so for others.
>> Let me know if I should run any specific tests to get to the bottom of
>> this.
>
> Well, not being dependent on a particular font would be a start. An
> easier reproducing recipe would be even better.
I suspect this is font-dependent because it has something to do with the
pixel height of the font text. Can you reproduce by keeping whaever font
you're using and pressing C-x C-+ a few times? As I described earlier
this usually sticks the point for only a few C-n presses, but it's
probably the same issue.
I just did some minor debugging by adding a trace to
(window-line-height) with (trace-function-background). If I turn off
global-hl-line-mode, then the bug goes away, and (window-line-height)
appears to return reasonable values. With global-hl-line-mode,
(window-line-height) and (window-line-height -1) both return nil
supposedly. Not sure how line-move-partial could keep working without
error in that case, but that's what it says.
> Thanks.
Thank YOU!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 06 Jul 2013 17:42:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Sat, 06 Jul 2013 09:14:44 -0700
>
> First off, there was a very important brain fart in what I just said. I
> meant C-n/C-p instead of C-f/C-b everywhere in this bug report. Oops.
Ah! That changes everything.
> I suspect this is font-dependent because it has something to do with the
> pixel height of the font text. Can you reproduce by keeping whaever font
> you're using and pressing C-x C-+ a few times? As I described earlier
> this usually sticks the point for only a few C-n presses, but it's
> probably the same issue.
I see something, but I'm not sure it's the same problem as what you
see. Please try the latest trunk and see if the problem with that
font and global-hl-line-mode is solved.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sat, 06 Jul 2013 21:52:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Please try the latest trunk and see if the problem with that font and
> global-hl-line-mode is solved.
I applied this patch:
http://git.savannah.gnu.org/cgit/emacs.git/diff/?id=daec5594cd21e30469f2a489875a89c8e931bee9
and tried again. It's better, but not 100% fixed yet. The previous
behavior of sticking until scrolling was no longer possible is now
replaced with sticking for a few presses of C-n. As before, turning off
global-hl-line-mode fixes it. Let me know what I can do to help debug.
Thanks
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 07 Jul 2013 02:49:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Sat, 06 Jul 2013 14:51:07 -0700
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Please try the latest trunk and see if the problem with that font and
> > global-hl-line-mode is solved.
>
> I applied this patch:
>
> http://git.savannah.gnu.org/cgit/emacs.git/diff/?id=daec5594cd21e30469f2a489875a89c8e931bee9
>
> and tried again. It's better, but not 100% fixed yet. The previous
> behavior of sticking until scrolling was no longer possible is now
> replaced with sticking for a few presses of C-n. As before, turning off
> global-hl-line-mode fixes it. Let me know what I can do to help debug.
Don't you see the same in Emacs 24.3? If so, the changes that were
done to allow smoother scrolling of tall images are no longer
responsible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 07 Jul 2013 04:47:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Dima Kogan <dima <at> secretsauce.net>
>> Date: Sat, 06 Jul 2013 14:51:07 -0700
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Please try the latest trunk and see if the problem with that font and
>> > global-hl-line-mode is solved.
>>
>> I applied this patch:
>>
>> http://git.savannah.gnu.org/cgit/emacs.git/diff/?id=daec5594cd21e30469f2a489875a89c8e931bee9
>>
>> and tried again. It's better, but not 100% fixed yet. The previous
>> behavior of sticking until scrolling was no longer possible is now
>> replaced with sticking for a few presses of C-n. As before, turning off
>> global-hl-line-mode fixes it. Let me know what I can do to help debug.
>
> Don't you see the same in Emacs 24.3? If so, the changes that were
> done to allow smoother scrolling of tall images are no longer
> responsible.
Aha. It does seem like the behavior before the changes introduced by
this bug and the behavior after your new patch are very similar. Thanks!
It does seem like a bug to me that the sticking happens at all,
especially given that it depends on global-hl-line-mode. Should I file a
separate bug for that?
Thanks again.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 07 Jul 2013 15:53:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Sat, 06 Jul 2013 21:46:36 -0700
>
> > Don't you see the same in Emacs 24.3? If so, the changes that were
> > done to allow smoother scrolling of tall images are no longer
> > responsible.
>
> Aha. It does seem like the behavior before the changes introduced by
> this bug and the behavior after your new patch are very similar. Thanks!
>
> It does seem like a bug to me that the sticking happens at all,
> especially given that it depends on global-hl-line-mode. Should I file a
> separate bug for that?
Yes, definitely, as this is a very old problem. But before you do,
please try the latest trunk, where revision 113314 attempts to make
scrolling in this case even more smooth. If you think the result is
acceptable, there's no need for a bug report.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Sun, 07 Jul 2013 18:58:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Dima Kogan <dima <at> secretsauce.net>
>> Date: Sat, 06 Jul 2013 21:46:36 -0700
>>
>> It does seem like a bug to me that the sticking happens at all,
>> especially given that it depends on global-hl-line-mode. Should I file a
>> separate bug for that?
>
> Yes, definitely, as this is a very old problem. But before you do,
> please try the latest trunk, where revision 113314 attempts to make
> scrolling in this case even more smooth. If you think the result is
> acceptable, there's no need for a bug report.
Hi Eli. With the latest trunk there's still a bit of sticking with
global-hl-line-move. I'm going to file a separate bug.
Thanks again.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Mon, 08 Jul 2013 17:37:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Sun, 07 Jul 2013 11:57:15 -0700
>
> Hi Eli. With the latest trunk there's still a bit of sticking with
> global-hl-line-move. I'm going to file a separate bug.
Didn't see any new bug, but in the meantime I fixed a few more
problems (trunk revision 113327). Now I no longer see any "sticking"
with the recipes I used. If you still see them, please describe
exactly what you see, and tell which scroll-related options, if any,
did you customize from their default values.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Mon, 08 Jul 2013 23:43:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 14567 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Dima Kogan <dima <at> secretsauce.net>
>> Date: Sun, 07 Jul 2013 11:57:15 -0700
>>
>> Hi Eli. With the latest trunk there's still a bit of sticking with
>> global-hl-line-move. I'm going to file a separate bug.
>
> Didn't see any new bug
I did a search for similar-sounding existing bugs, and apparently this
issue has already been filed, so I didn't add to the pile:
http://debbugs.gnu.org/6103
http://debbugs.gnu.org/6272
http://debbugs.gnu.org/14598
>, but in the meantime I fixed a few more problems (trunk revision
>113327). Now I no longer see any "sticking" with the recipes I used. If
>you still see them, please describe exactly what you see, and tell
>which scroll-related options, if any, did you customize from their
>default values.
Thank you very much, Eli. My main test case now works perfectly. I can
still make problems happen if I adjust the text size with C-x C-+.
Loading emacs with the .emacs I mentioned in the original post about
this and then pressing 'C-x C-+' 4 times, pressing C-n never results in
a 50% screen scroll. At the bottom, C-n presses alternate between
- scrolling down one line while keeping the point stationary
- moving the point down one line normally.
This sounds like http://debbugs.gnu.org/14598 so maybe it's not
something to worry about here.
Thanks again
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Tue, 09 Jul 2013 17:02:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Mon, 08 Jul 2013 16:42:49 -0700
>
> I did a search for similar-sounding existing bugs, and apparently this
> issue has already been filed, so I didn't add to the pile:
>
> http://debbugs.gnu.org/6103
> http://debbugs.gnu.org/6272
> http://debbugs.gnu.org/14598
None of these are reproducible with the current trunk, so I guess my
latest changes fixed them all indirectly. I'm closing them.
> My main test case now works perfectly. I can still make problems
> happen if I adjust the text size with C-x C-+.
I can't. So please file a new bug report ;-)
> Loading emacs with the .emacs I mentioned in the original post about
> this and then pressing 'C-x C-+' 4 times, pressing C-n never results in
> a 50% screen scroll. At the bottom, C-n presses alternate between
>
> - scrolling down one line while keeping the point stationary
Stationary on screen, or stationary at the same buffer position?
> - moving the point down one line normally.
What do the following report in each one of the 2 above-mentioned
situations, i.e. before C-n would scroll, and before it would move?
M-: (pos-visible-in-window-p t nil t) RET
M-: (posn-at-point) RET
M-: (default-font-height) RET
> This sounds like http://debbugs.gnu.org/14598
No, it isn't, as that bug is already solved. I guess it was easier
than I thought at the time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Wed, 10 Jul 2013 09:32:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 14567 <at> debbugs.gnu.org (full text, mbox):
The changes in revision 113314 cause problems with repeated C-n:
0. emacs -Q (any revision post 113313)
1. C-h n to visit NEWS
2. Type C-n and hold it.
=> Scrolling starts out fine, but around line 270 (sometimes earlier) it
starts getting jerky and soon it appears to stop altogether, and only
after releasing the keys is the display updated. From this point on,
holding down C-n shows this misbehavior. Reverting simple.el to
revision 113313 and rebuilding Emacs makes holding down C-n work fine
again.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Wed, 10 Jul 2013 16:28:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 14567 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Dima Kogan <dima <at> secretsauce.net>, 14567 <at> debbugs.gnu.org
> Date: Wed, 10 Jul 2013 11:30:48 +0200
>
> The changes in revision 113314 cause problems with repeated C-n:
>
> 0. emacs -Q (any revision post 113313)
> 1. C-h n to visit NEWS
> 2. Type C-n and hold it.
> => Scrolling starts out fine, but around line 270 (sometimes earlier) it
> starts getting jerky and soon it appears to stop altogether, and only
> after releasing the keys is the display updated. From this point on,
> holding down C-n shows this misbehavior.
I cannot reproduce this, sorry, not with the above recipe. I tried
different fonts and different sizes of them, and never saw anything
like this. If in your case Emacs cannot keep up due to some high
computational load (what does the CPU load say?), then I see no sign
of that on my system when I scroll through NEWS. If you do see a
significant CPU load, please tell (in a new bug report, see below)
what kind of CPU do you have and whether the problem disappears if you
reduce the keyboard auto-repeat rate.
If you still see this after revision 113360 (where I made changes in
the same function as in 113314, although I think they are unrelated),
please report a new bug for this, as the problem you describe has
nothing to do whatsoever with this bug. I will then try to give you
instructions how to instrument line-move-partial and report the
results.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14567; Package
emacs.
(Wed, 10 Jul 2013 21:34:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 14567 <at> debbugs.gnu.org (full text, mbox):
On Wed, 10 Jul 2013 19:27:19 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Dima Kogan <dima <at> secretsauce.net>, 14567 <at> debbugs.gnu.org
>> Date: Wed, 10 Jul 2013 11:30:48 +0200
>>
>> The changes in revision 113314 cause problems with repeated C-n:
>>
>> 0. emacs -Q (any revision post 113313)
>> 1. C-h n to visit NEWS
>> 2. Type C-n and hold it.
>> => Scrolling starts out fine, but around line 270 (sometimes earlier) it
>> starts getting jerky and soon it appears to stop altogether, and only
>> after releasing the keys is the display updated. From this point on,
>> holding down C-n shows this misbehavior.
>
> I cannot reproduce this, sorry, not with the above recipe. I tried
> different fonts and different sizes of them, and never saw anything
> like this. If in your case Emacs cannot keep up due to some high
> computational load (what does the CPU load say?), then I see no sign
> of that on my system when I scroll through NEWS. If you do see a
> significant CPU load, please tell (in a new bug report, see below)
> what kind of CPU do you have and whether the problem disappears if you
> reduce the keyboard auto-repeat rate.
>
> If you still see this after revision 113360 (where I made changes in
> the same function as in 113314, although I think they are unrelated),
> please report a new bug for this, as the problem you describe has
> nothing to do whatsoever with this bug. I will then try to give you
> instructions how to instrument line-move-partial and report the
> results.
I updated to revision 113360 and the behavior is worse: now holding down
C-n almost immediately fails to scroll until releasing the keys. CPU
load goes quickly up to 95% (it also does so on my prior builds starting
with 113314, but not as quickly and only after ~270 lines of C-n'ing).
I've opened a new bug (#14838) with further details.
Steve Berman
Forcibly Merged 14567 16840.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 26 Sep 2019 17:13:01 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 214 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.