GNU bug report logs - #46316
27.1; wrong horizontal scroll with truncate-lines value t

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46316 in the body.
You can then email your comments to 46316 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; wrong horizontal scroll with truncate-lines value t
Date: Fri, 05 Feb 2021 14:08:06 +0900

(1) When isearch fails after last match
Evaluate the form below and type 'C-s a C-s', then emacs messages
'Failing I-search: a' and the buffer scrolls back left and the current
point is out of the window.
Type C-s again, and overwrapped search succeeds at the same point,
but the matched point is still out of the window.

  (let ((buf (generate-new-buffer "tmp")))
    (switch-to-buffer buf)
    (setq truncate-lines t)
    (dotimes (i 100) (insert (format "%d\n" i)))
    (insert-char ?x 200)
    (insert ?a)
    (goto-char (point-min)))

(2) When image-toggle-display
Evaluate the form below, then the SVG image is displayed.
Type 'C-c C-c' to view the source text and type 'C-c C-c' again to view
the image, then the buffer keeps scrolled right and the image is hidden
out of the window.
Type C-a and the image is shown, type 'C-c C-c' to view the source text
again, then the buffer keeps scrolled left and the current point is out
of the window.

  (let ((buf (generate-new-buffer "tmp"))
        (svg "<svg width=\"80\" height=\"80\" version=\"1.1\"\
   xmlns=\"http://www.w3.org/2000/svg\"\
   xmlns:xlink=\"http://www.w3.org/1999/xlink\">\
   <rect width=\"80\" height=\"80\" x=\"0\" y=\"0\" fill=\"blue\"></rect>\
  </svg>"))
    (switch-to-buffer buf)
    (setq truncate-lines t)
    (insert svg)
    (image-mode))



In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-22 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Pro (v10.0.1909.18363.1316)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading c:/home/yagi/.emacs.d/minimal-init.el (source)...
Loading term/bobcat...done
Loading c:/home/yagi/.emacs.d/minimal-init.el (source)...done

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
term/bobcat japan-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 49564 9493)
 (symbols 48 6091 1)
 (strings 32 16912 1998)
 (string-bytes 1 523773)
 (vectors 16 10730)
 (vector-slots 8 208731 12936)
 (floats 8 21 314)
 (intervals 56 225 0)
 (buffers 1000 11))

Message #8 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1;
 wrong horizontal scroll with truncate-lines value t
Date: Sat, 06 Feb 2021 15:01:39 +0200

tags 46316 notabug
thanks

> From: ynyaaa <at> gmail.com
> Date: Fri, 05 Feb 2021 14:08:06 +0900
> 
> 
> (1) When isearch fails after last match
> Evaluate the form below and type 'C-s a C-s', then emacs messages
> 'Failing I-search: a' and the buffer scrolls back left and the current
> point is out of the window.
> Type C-s again, and overwrapped search succeeds at the same point,
> but the matched point is still out of the window.
> 
>   (let ((buf (generate-new-buffer "tmp")))
>     (switch-to-buffer buf)
>     (setq truncate-lines t)
>     (dotimes (i 100) (insert (format "%d\n" i)))
>     (insert-char ?x 200)
>     (insert ?a)
>     (goto-char (point-min)))
> 
> (2) When image-toggle-display
> Evaluate the form below, then the SVG image is displayed.
> Type 'C-c C-c' to view the source text and type 'C-c C-c' again to view
> the image, then the buffer keeps scrolled right and the image is hidden
> out of the window.
> Type C-a and the image is shown, type 'C-c C-c' to view the source text
> again, then the buffer keeps scrolled left and the current point is out
> of the window.
> 
>   (let ((buf (generate-new-buffer "tmp"))
>         (svg "<svg width=\"80\" height=\"80\" version=\"1.1\"\
>    xmlns=\"http://www.w3.org/2000/svg\"\
>    xmlns:xlink=\"http://www.w3.org/1999/xlink\">\
>    <rect width=\"80\" height=\"80\" x=\"0\" y=\"0\" fill=\"blue\"></rect>\
>   </svg>"))
>     (switch-to-buffer buf)
>     (setq truncate-lines t)
>     (insert svg)
>     (image-mode))

I don't think this behavior is a bug.  We only change the hscroll of a
window when point moves, and in these two scenarios it doesn't move.
I see no reason to assume that the user will necessarily want to have
the window scroll, instead of keeping it at its current horizontal
scroll.

Message #13 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Mon, 08 Feb 2021 00:28:57 +0900

Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 46316 notabug
> thanks
>
>> From: ynyaaa <at> gmail.com
>> Date: Fri, 05 Feb 2021 14:08:06 +0900
>> 
>> 
>> (1) When isearch fails after last match
>> Evaluate the form below and type 'C-s a C-s', then emacs messages
>> 'Failing I-search: a' and the buffer scrolls back left and the current
>> point is out of the window.
>> Type C-s again, and overwrapped search succeeds at the same point,
>> but the matched point is still out of the window.
>> 
>>   (let ((buf (generate-new-buffer "tmp")))
>>     (switch-to-buffer buf)
>>     (setq truncate-lines t)
>>     (dotimes (i 100) (insert (format "%d\n" i)))
>>     (insert-char ?x 200)
>>     (insert ?a)
>>     (goto-char (point-min)))
>> 
>> (2) When image-toggle-display
>> Evaluate the form below, then the SVG image is displayed.
>> Type 'C-c C-c' to view the source text and type 'C-c C-c' again to view
>> the image, then the buffer keeps scrolled right and the image is hidden
>> out of the window.
>> Type C-a and the image is shown, type 'C-c C-c' to view the source text
>> again, then the buffer keeps scrolled left and the current point is out
>> of the window.
>> 
>>   (let ((buf (generate-new-buffer "tmp"))
>>         (svg "<svg width=\"80\" height=\"80\" version=\"1.1\"\
>>    xmlns=\"http://www.w3.org/2000/svg\"\
>>    xmlns:xlink=\"http://www.w3.org/1999/xlink\">\
>>    <rect width=\"80\" height=\"80\" x=\"0\" y=\"0\" fill=\"blue\"></rect>\
>>   </svg>"))
>>     (switch-to-buffer buf)
>>     (setq truncate-lines t)
>>     (insert svg)
>>     (image-mode))
>
> I don't think this behavior is a bug.  We only change the hscroll of a
> window when point moves, and in these two scenarios it doesn't move.
> I see no reason to assume that the user will necessarily want to have
> the window scroll, instead of keeping it at its current horizontal
> scroll.

In the case of isearch, the hscroll is changed without point motion
when isearch fails.

In the case of image-toggle-display, the hscroll is changed without
point motion when typing 'C-c C-c' for the first time.

Message #16 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Sun, 07 Feb 2021 17:34:58 +0200

> Cc: 46316 <at> debbugs.gnu.org
> From: ynyaaa <at> gmail.com
> Date: Mon, 08 Feb 2021 00:28:57 +0900
> 
> > I don't think this behavior is a bug.  We only change the hscroll of a
> > window when point moves, and in these two scenarios it doesn't move.
> > I see no reason to assume that the user will necessarily want to have
> > the window scroll, instead of keeping it at its current horizontal
> > scroll.
> 
> In the case of isearch, the hscroll is changed without point motion
> when isearch fails.

Yes, because the focus changes into the minibuffer, where we show the
failure message.

> In the case of image-toggle-display, the hscroll is changed without
> point motion when typing 'C-c C-c' for the first time.

Yes, and for a similar good reason.

I don't really understand the insistence: you can easily cause the
window to auto-scroll if you move point by one character.  Emacs
cannot possibly guess which part of the display is more important for
the user in situations like this.

Message #19 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Mon, 08 Feb 2021 03:54:32 +0900

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 46316 <at> debbugs.gnu.org
>> From: ynyaaa <at> gmail.com
>> Date: Mon, 08 Feb 2021 00:28:57 +0900
>> 
>> > I don't think this behavior is a bug.  We only change the hscroll of a
>> > window when point moves, and in these two scenarios it doesn't move.
>> > I see no reason to assume that the user will necessarily want to have
>> > the window scroll, instead of keeping it at its current horizontal
>> > scroll.
>> 
>> In the case of isearch, the hscroll is changed without point motion
>> when isearch fails.
>
> Yes, because the focus changes into the minibuffer, where we show the
> failure message.
>
>> In the case of image-toggle-display, the hscroll is changed without
>> point motion when typing 'C-c C-c' for the first time.
>
> Yes, and for a similar good reason.

When emacs misses the appropriate hscroll, typing 'M-: t RET' changes
the forcus into the minibuffer temporally, but does not change the
hscroll of the original buffer.

> I don't really understand the insistence: you can easily cause the
> window to auto-scroll if you move point by one character.  Emacs
> cannot possibly guess which part of the display is more important for
> the user in situations like this.

I only want auto-hscroll-mode to scroll buffer automatically.
Otherwise I will be very confused.
If a searched string is not displayed in the window, I might think the
searched string does not exist in the buffer.
If an image is hidden, I might think the image is a solid color same as
the emacs background color.

Message #22 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Sun, 07 Feb 2021 21:10:15 +0200

> Cc: 46316 <at> debbugs.gnu.org
> From: ynyaaa <at> gmail.com
> Date: Mon, 08 Feb 2021 03:54:32 +0900
> 
> I only want auto-hscroll-mode to scroll buffer automatically.

It does, when you give it enough information that it should.  When
your input focus is in another window (the mini-window in the case of
C-s), I think it would be strange for Emacs to auto-scroll some other
window.

> If a searched string is not displayed in the window, I might think the
> searched string does not exist in the buffer.

The searched string _is_ displayed, when you first find it.

> If an image is hidden, I might think the image is a solid color same as
> the emacs background color.

Just move the cursor and you will see it.

Sorry, I see no problem here, certainly not something that would
justify complicated triggers for redisplaying a window.

Message #25 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Sat, 13 Feb 2021 00:41:18 +0900

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 46316 <at> debbugs.gnu.org
>> From: ynyaaa <at> gmail.com
>> Date: Mon, 08 Feb 2021 03:54:32 +0900
>> 
>> I only want auto-hscroll-mode to scroll buffer automatically.
>
> It does, when you give it enough information that it should.  When
> your input focus is in another window (the mini-window in the case of
> C-s), I think it would be strange for Emacs to auto-scroll some other
> window.
>
>> If a searched string is not displayed in the window, I might think the
>> searched string does not exist in the buffer.
>
> The searched string _is_ displayed, when you first find it.
>
>> If an image is hidden, I might think the image is a solid color same as
>> the emacs background color.
>
> Just move the cursor and you will see it.
>
> Sorry, I see no problem here, certainly not something that would
> justify complicated triggers for redisplaying a window.

I investigated some more.

#'isearch-update tries to control the hsrcoll using
#'pos-visible-in-window-group-p.
Under the folloing conditions, it returns coordinates as if the point is
at the beginning of a virtual next line.
  (1) the point is the end of the buffer.
  (2) the buffer does not end with a newline.
  (3) the last line is displayed in the window.
  (4) the last line is truncated.
So the calculation is wrong and the hscroll becomes inappropriate.

With a different reason, if isearch started with a large hscroll and the
last match is near the beginning of a line, the hscroll becomes
inapropriate.
For example, evaluate the form below, and type 'C-s a C-s', then the
current point is hidden to the left of the window.
This is because #'isearch-update only checks whether the point is to the
right of the window and does not check whether the point is to the left
of the window.

(let ((buf (generate-new-buffer "tmp")))
  (switch-to-buffer buf)
  (setq truncate-lines t)
  (insert-char ?x 100)
  (save-excursion
    (insert-char ?\n 100)
    (insert ?a)))

Regarding image-mode, a simpler example of the bug is written as below.
The hscroll does not change when the buffer is changed.
Image display, window focus or message is not related.

(let ((buf (generate-new-buffer "tmp")))
  (switch-to-buffer buf)
  (setq truncate-lines t)
  (dotimes (i 200)
    (insert (format ":%03d" i))
    (when (= 0 (% (1+ i) 100)) (insert ?\n)))
  (forward-char -1)
  (sit-for 1)
  (set-window-hscroll nil (window-hscroll))
  (save-excursion
    (forward-char -100)
    (insert-char ?\n 10)
    ))

Message #28 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Sat, 13 Feb 2021 17:30:38 +0200

> Cc: 46316 <at> debbugs.gnu.org
> From: ynyaaa <at> gmail.com
> Date: Sat, 13 Feb 2021 00:41:18 +0900
> 
> #'isearch-update tries to control the hsrcoll using
> #'pos-visible-in-window-group-p.
> Under the folloing conditions, it returns coordinates as if the point is
> at the beginning of a virtual next line.
>   (1) the point is the end of the buffer.
>   (2) the buffer does not end with a newline.
>   (3) the last line is displayed in the window.
>   (4) the last line is truncated.
> So the calculation is wrong and the hscroll becomes inappropriate.

Thanks, I wasn't aware isearch called pos-visible-in-window-p.

I fixed pos-visible-in-window-p on the master branch in this case, so
this part of the report now works correctly.

> With a different reason, if isearch started with a large hscroll and the
> last match is near the beginning of a line, the hscroll becomes
> inapropriate.
> For example, evaluate the form below, and type 'C-s a C-s', then the
> current point is hidden to the left of the window.
> This is because #'isearch-update only checks whether the point is to the
> right of the window and does not check whether the point is to the left
> of the window.
> 
> (let ((buf (generate-new-buffer "tmp")))
>   (switch-to-buffer buf)
>   (setq truncate-lines t)
>   (insert-char ?x 100)
>   (save-excursion
>     (insert-char ?\n 100)
>     (insert ?a)))

This now also works correctly.

> Regarding image-mode, a simpler example of the bug is written as below.
> The hscroll does not change when the buffer is changed.
> Image display, window focus or message is not related.
> 
> (let ((buf (generate-new-buffer "tmp")))
>   (switch-to-buffer buf)
>   (setq truncate-lines t)
>   (dotimes (i 200)
>     (insert (format ":%03d" i))
>     (when (= 0 (% (1+ i) 100)) (insert ?\n)))
>   (forward-char -1)
>   (sit-for 1)
>   (set-window-hscroll nil (window-hscroll))
>   (save-excursion
>     (forward-char -100)
>     (insert-char ?\n 10)
>     ))

Sorry, I don't think I follow: what exactly is the bug here?  What did
you expect to happen ,and what did actually happen?

Message #31 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Mon, 15 Feb 2021 00:43:32 +0900

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Regarding image-mode, a simpler example of the bug is written as below.
>> The hscroll does not change when the buffer is changed.
>> Image display, window focus or message is not related.
>> 
>> (let ((buf (generate-new-buffer "tmp")))
>>   (switch-to-buffer buf)
>>   (setq truncate-lines t)
>>   (dotimes (i 200)
>>     (insert (format ":%03d" i))
>>     (when (= 0 (% (1+ i) 100)) (insert ?\n)))
>>   (forward-char -1)
>>   (sit-for 1)
>>   (set-window-hscroll nil (window-hscroll))
>>   (save-excursion
>>     (forward-char -100)
>>     (insert-char ?\n 10)
>>     ))
>
> Sorry, I don't think I follow: what exactly is the bug here?  What did
> you expect to happen ,and what did actually happen?

The expression '(set-window-hscroll nil (window-hscroll))' should not
have any effect, but if it is deleted from the form, auto-hscroll-mode
works correctly.

Not only point motion but also buffer modification should be checked for
auto-hscroll-mode.

Message #34 received at 46316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 46316 <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Sun, 14 Feb 2021 20:50:08 +0200

> From: ynyaaa <at> gmail.com
> Cc: 46316 <at> debbugs.gnu.org
> Date: Mon, 15 Feb 2021 00:43:32 +0900
> 
> >> (let ((buf (generate-new-buffer "tmp")))
> >>   (switch-to-buffer buf)
> >>   (setq truncate-lines t)
> >>   (dotimes (i 200)
> >>     (insert (format ":%03d" i))
> >>     (when (= 0 (% (1+ i) 100)) (insert ?\n)))
> >>   (forward-char -1)
> >>   (sit-for 1)
> >>   (set-window-hscroll nil (window-hscroll))
> >>   (save-excursion
> >>     (forward-char -100)
> >>     (insert-char ?\n 10)
> >>     ))
> >
> > Sorry, I don't think I follow: what exactly is the bug here?  What did
> > you expect to happen ,and what did actually happen?
> 
> The expression '(set-window-hscroll nil (window-hscroll))' should not
> have any effect

That's not true: calling set-window-hscroll inhibits automatic
hscrolling, until point moves for some reason.

> but if it is deleted from the form, auto-hscroll-mode works
> correctly.

I think this is expected: the text your recipe adds is not around
point, so we don't re-enable auto-hscroll.

> Not only point motion but also buffer modification should be checked for
> auto-hscroll-mode.

If you want this to happen, don't call set-window-hscroll.

Message #39 received at 46316-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ynyaaa <at> gmail.com, 46316-done <at> debbugs.gnu.org
Subject: Re: bug#46316: 27.1; wrong horizontal scroll with truncate-lines
 value t
Date: Fri, 9 Apr 2021 11:59:26 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: ynyaaa <at> gmail.com
>> Cc: 46316 <at> debbugs.gnu.org
>> Date: Mon, 15 Feb 2021 00:43:32 +0900
>>
>> >> (let ((buf (generate-new-buffer "tmp")))
>> >>   (switch-to-buffer buf)
>> >>   (setq truncate-lines t)
>> >>   (dotimes (i 200)
>> >>     (insert (format ":%03d" i))
>> >>     (when (= 0 (% (1+ i) 100)) (insert ?\n)))
>> >>   (forward-char -1)
>> >>   (sit-for 1)
>> >>   (set-window-hscroll nil (window-hscroll))
>> >>   (save-excursion
>> >>     (forward-char -100)
>> >>     (insert-char ?\n 10)
>> >>     ))
>> >
>> > Sorry, I don't think I follow: what exactly is the bug here?  What did
>> > you expect to happen ,and what did actually happen?
>>
>> The expression '(set-window-hscroll nil (window-hscroll))' should not
>> have any effect
>
> That's not true: calling set-window-hscroll inhibits automatic
> hscrolling, until point moves for some reason.
>
>> but if it is deleted from the form, auto-hscroll-mode works
>> correctly.
>
> I think this is expected: the text your recipe adds is not around
> point, so we don't re-enable auto-hscroll.
>
>> Not only point motion but also buffer modification should be checked for
>> auto-hscroll-mode.
>
> If you want this to happen, don't call set-window-hscroll.

This was tagged notabug and Eli explained that the behavior is
expected.  The bug that was here has been fixed.

There also has been no further update within 7 weeks.

I'm therefore closing this bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.