GNU bug report logs - #36193
26.2; 'set-window-scroll-bars' setting doesn't take effect in emacsclient session

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 36193 in the body.
You can then email your comments to 36193 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: Andrea Greselin <greselin.andrea <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.2; 'set-window-scroll-bars' setting doesn't take effect in
 emacsclient session
Date: Thu, 13 Jun 2019 16:57:36 +0200

[Message part 1 (text/plain, inline)]

Hello,

I use
  (set-window-scroll-bars (minibuffer-window) 0 nil)
to disable the minibuffer scroll bar. This works if Emacs is launched with
  $ emacs
but it doesn't in emacsclient sessions, though it takes effect if evaluated
in the running session (e.g. with 'eval-expression'). I tried delaying the
evaluation with  'window-setup-hook', to no avail.

$ cat ~/.emacs.d/init.el
(set-window-scroll-bars (minibuffer-window) 0 nil)

In GNU Emacs 26.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.8)
 of 2019-04-30 built on buildvm-06.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.12004000
System Description: Fedora release 30 (Thirty)

Recent messages:
Loading /usr/share/emacs/site-lisp/site-start.d/desktop-entry-mode-init.el
(source)...done
Starting Emacs daemon.
When done with this frame, type C-x 5 0
Making completion list...

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules
 build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu
 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
 -fstack-protector-strong -grecord-gcc-switches
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS GLIB NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LCMS2

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

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
  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 mml-sec epa derived epg gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils pp server time-date elec-pair finder-inf
tex-site info ess-generics package easymenu epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame 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 minibuffer
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 dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
xwidget-internal move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 116700 6479)
 (symbols 48 22592 1)
 (miscs 40 55 101)
 (strings 32 36127 1817)
 (string-bytes 1 1005252)
 (vectors 16 17258)
 (vector-slots 8 542430 8396)
 (floats 8 59 58)
 (intervals 56 294 0)
 (buffers 992 13))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Greselin <greselin.andrea <at> gmail.com>
Cc: 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2;
 'set-window-scroll-bars' setting doesn't take effect in emacsclient
 session
Date: Thu, 13 Jun 2019 19:11:56 +0300

> From: Andrea Greselin <greselin.andrea <at> gmail.com>
> Date: Thu, 13 Jun 2019 16:57:36 +0200
> 
> I use
>   (set-window-scroll-bars (minibuffer-window) 0 nil)
> to disable the minibuffer scroll bar. This works if Emacs is launched with
>   $ emacs
> but it doesn't in emacsclient sessions, though it takes effect if evaluated in the running session (e.g. with
> 'eval-expression'). I tried delaying the evaluation with  'window-setup-hook', to no avail.
> 
> $ cat ~/.emacs.d/init.el 
> (set-window-scroll-bars (minibuffer-window) 0 nil)

Are you starting Emacs as daemon?  If so, disable the scroll bars in
after-make-frame-functions instead of directly in your init file.

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

From: Andrea Greselin <greselin.andrea <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Thu, 13 Jun 2019 20:48:42 +0200

[Message part 1 (text/plain, inline)]

> Are you starting Emacs as daemon?
Yep.

Trying to follow your suggestion I've written

  (defun hide-minibuffer-scrollbar (frame)
    (with-selected-frame frame
      (set-window-scroll-bars (minibuffer-window) 0 nil)))
  (if (daemonp)
      (add-hook 'after-make-frame-functions #'hide-minibuffer-scrollbar) ;
Only for client sessions
    (set-window-scroll-bars (minibuffer-window) 0 nil))

Now client sessions start without the minibuffer scrollbar, but as soon as
I use the minibuffer it comes back and it isn't removed afterwards.

On Thu, 13 Jun 2019 at 18:12, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Andrea Greselin <greselin.andrea <at> gmail.com>
> > Date: Thu, 13 Jun 2019 16:57:36 +0200
> >
> > I use
> >   (set-window-scroll-bars (minibuffer-window) 0 nil)
> > to disable the minibuffer scroll bar. This works if Emacs is launched
> with
> >   $ emacs
> > but it doesn't in emacsclient sessions, though it takes effect if
> evaluated in the running session (e.g. with
> > 'eval-expression'). I tried delaying the evaluation with
> 'window-setup-hook', to no avail.
> >
> > $ cat ~/.emacs.d/init.el
> > (set-window-scroll-bars (minibuffer-window) 0 nil)
>
> Are you starting Emacs as daemon?  If so, disable the scroll bars in
> after-make-frame-functions instead of directly in your init file.
>

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Andrea Greselin <greselin.andrea <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Sun, 16 Jun 2019 10:17:37 +0200

> Trying to follow your suggestion I've written
>
>    (defun hide-minibuffer-scrollbar (frame)
>      (with-selected-frame frame
>        (set-window-scroll-bars (minibuffer-window) 0 nil)))
>    (if (daemonp)
>        (add-hook 'after-make-frame-functions #'hide-minibuffer-scrollbar) ; Only for client sessions
>      (set-window-scroll-bars (minibuffer-window) 0 nil))
>
> Now client sessions start without the minibuffer scrollbar, but as soon as
> I use the minibuffer it comes back and it isn't removed afterwards.

Scrollbar management in the minibuffer window might be unpredictable.
Also, GTK builds usually hide the scroll bar in a one line minibuffer
window automatically, so even the 'min-slider-length' might come into
play here.

To make sure we don't miss anything before proceeding further:

(1) Is this behavior special for the minibuffer window?  That is, if
in 'after-make-frame-functions' you removed the scroll bar from any
other window, does it stay removed when you switch to that window
repeatedly?

(2) Does showing a message in the echo area suffice to make the scroll
bar reappear?  With other words, what does "use" the minibuffer stand
for?

(3) I suppose "it isn't removed afterwards" means you can still remove
the scroll bar explicitly via 'set-window-scroll-bars' afterwards.
Right?  And if you do that, does it come back after yet another "use"
of the minibuffer?

(4) Can you influence the behavior by customizing the variable
`resize-mini-windows'?

Thanks, martin

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

From: Andrea Greselin <greselin.andrea <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Tue, 18 Jun 2019 14:46:15 +0200

[Message part 1 (text/plain, inline)]

> (1) Is this behavior special for the minibuffer window?  That is, if
> in 'after-make-frame-functions' you removed the scroll bar from any
> other window, does it stay removed when you switch to that window
> repeatedly?
Yes. If in 'hide-minibuffer-scrollbar' I replace '(minibuffer-window)' with
'nil', the scratch buffer has no scroll bars and they don't reappear even
if the buffer become longer than the window height. They are only
re-enabled if I open another buffer in that window, and then they persist.

> (2) Does showing a message in the echo area suffice to make the scroll
> bar reappear?  With other words, what does "use" the minibuffer stand
> for?
No, messages are shown at startup without the scroll bars being shown. if I
do M-x or M-: or anything that moves the point to the minibuffer, then they
are re-enabled.

> (3) I suppose "it isn't removed afterwards" means you can still remove
> the scroll bar explicitly via 'set-window-scroll-bars' afterwards.
> Right?  And if you do that, does it come back after yet another "use"
> of the minibuffer?
Yes I can still remove them by evaluating '(set-window-scroll-bars
(minibuffer-window) 0 nil)'. Then they are only shown while the minibuffer
is active (which is the same behaviour I get right from the start in normal
(non-client) Emacs sessions).

> (4) Can you influence the behavior by customizing the variable
> `resize-mini-windows'?
Nope, it doesn't appear to have any effect, neither when set in the init
file nor in a running emacsclient session.

Best, andrea

On Sun, 16 Jun 2019 at 10:17, martin rudalics <rudalics <at> gmx.at> wrote:

>  > Trying to follow your suggestion I've written
>  >
>  >    (defun hide-minibuffer-scrollbar (frame)
>  >      (with-selected-frame frame
>  >        (set-window-scroll-bars (minibuffer-window) 0 nil)))
>  >    (if (daemonp)
>  >        (add-hook 'after-make-frame-functions
> #'hide-minibuffer-scrollbar) ; Only for client sessions
>  >      (set-window-scroll-bars (minibuffer-window) 0 nil))
>  >
>  > Now client sessions start without the minibuffer scrollbar, but as soon
> as
>  > I use the minibuffer it comes back and it isn't removed afterwards.
>
> Scrollbar management in the minibuffer window might be unpredictable.
> Also, GTK builds usually hide the scroll bar in a one line minibuffer
> window automatically, so even the 'min-slider-length' might come into
> play here.
>
> To make sure we don't miss anything before proceeding further:
>
> (1) Is this behavior special for the minibuffer window?  That is, if
> in 'after-make-frame-functions' you removed the scroll bar from any
> other window, does it stay removed when you switch to that window
> repeatedly?
>
> (2) Does showing a message in the echo area suffice to make the scroll
> bar reappear?  With other words, what does "use" the minibuffer stand
> for?
>
> (3) I suppose "it isn't removed afterwards" means you can still remove
> the scroll bar explicitly via 'set-window-scroll-bars' afterwards.
> Right?  And if you do that, does it come back after yet another "use"
> of the minibuffer?
>
> (4) Can you influence the behavior by customizing the variable
> `resize-mini-windows'?
>
> Thanks, martin
>

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Andrea Greselin <greselin.andrea <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Tue, 18 Jun 2019 15:42:39 +0200

> Yes. If in 'hide-minibuffer-scrollbar' I replace '(minibuffer-window)' with
> 'nil', the scratch buffer has no scroll bars and they don't reappear even
> if the buffer become longer than the window height. They are only
> re-enabled if I open another buffer in that window, and then they persist.

Ahh...  I should have asked you that so it's good you noticed it.
This shows that the behavior is not minibuffer window specific.

> No, messages are shown at startup without the scroll bars being shown. if I
> do M-x or M-: or anything that moves the point to the minibuffer, then they
> are re-enabled.

So showing another buffer in the minibuffer window reenables the
scroll bars.  This is consistent with the first observation.

The behavior (which I would call a bug) is caused by set_window_buffer
when called with keep_margins_p nil and is completely unrelated to
whether you do it in emacsclient or in a "normal" session.  That is if
I evaluate with emacs -Q

(set-window-scroll-bars (minibuffer-window) 0 nil)

and then type M-x, I get the scroll bars back just as you do.  The
behavior is described in the Elisp manual on 'set-window-scroll-bars'

     The values specified here may be later overridden by invoking
     ‘set-window-buffer’ (*note Buffers and Windows::) on WINDOW with
     its KEEP-MARGINS argument ‘nil’ or omitted.

but I consistently forget about it.

If people agree that this is a bug, we can try to find a more general
fix.  Otherwise, I'll fix the minibuffer window scroll bars with the
help of a separate variable (I have written the code some time ago and
would "only" have to find it now).

As a temporary workaround you can try to set the buffer local values
of 'scroll-bar-width' to zero in all buffers that might eventually
show up in the minibuffer window, for example, thusly

(progn
  (set-window-scroll-bars (minibuffer-window) 0 nil)
  (with-current-buffer (get-buffer-create " *Echo Area 0*")
    (setq scroll-bar-width 0))
  (with-current-buffer (get-buffer-create " *Echo Area 1*")
    (setq scroll-bar-width 0))
  (with-current-buffer (get-buffer-create " *Minibuf-0*")
    (setq scroll-bar-width 0))
  (with-current-buffer (get-buffer-create " *Minibuf-1*")
    (setq scroll-bar-width 0)))

This should work as long as you don't enable recursive minibuffers.

martin

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

From: Andrea Greselin <greselin.andrea <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Tue, 18 Jun 2019 15:59:53 +0200

[Message part 1 (text/plain, inline)]

> That is if I evaluate with emacs -Q
>   (set-window-scroll-bars (minibuffer-window) 0 nil)
> and then type M-x, I get the scroll bars back just as you do.

The behaviour is different in my case: when I use
'after-make-frame-functions' as in the snippet in my second message, the
scroll bar persists after doing M-x. If I evaluate
  (set-window-scroll-bars (minibuffer-window) 0 nil)
in a running session, they are displayed only as long as the minibuffer is
active, and then they are turned off again.

On Tue, 18 Jun 2019 at 15:42, martin rudalics <rudalics <at> gmx.at> wrote:

>  > Yes. If in 'hide-minibuffer-scrollbar' I replace '(minibuffer-window)'
> with
>  > 'nil', the scratch buffer has no scroll bars and they don't reappear
> even
>  > if the buffer become longer than the window height. They are only
>  > re-enabled if I open another buffer in that window, and then they
> persist.
>
> Ahh...  I should have asked you that so it's good you noticed it.
> This shows that the behavior is not minibuffer window specific.
>
>  > No, messages are shown at startup without the scroll bars being shown.
> if I
>  > do M-x or M-: or anything that moves the point to the minibuffer, then
> they
>  > are re-enabled.
>
> So showing another buffer in the minibuffer window reenables the
> scroll bars.  This is consistent with the first observation.
>
> The behavior (which I would call a bug) is caused by set_window_buffer
> when called with keep_margins_p nil and is completely unrelated to
> whether you do it in emacsclient or in a "normal" session.  That is if
> I evaluate with emacs -Q
>
> (set-window-scroll-bars (minibuffer-window) 0 nil)
>
> and then type M-x, I get the scroll bars back just as you do.  The
> behavior is described in the Elisp manual on 'set-window-scroll-bars'
>
>       The values specified here may be later overridden by invoking
>       ‘set-window-buffer’ (*note Buffers and Windows::) on WINDOW with
>       its KEEP-MARGINS argument ‘nil’ or omitted.
>
> but I consistently forget about it.
>
> If people agree that this is a bug, we can try to find a more general
> fix.  Otherwise, I'll fix the minibuffer window scroll bars with the
> help of a separate variable (I have written the code some time ago and
> would "only" have to find it now).
>
> As a temporary workaround you can try to set the buffer local values
> of 'scroll-bar-width' to zero in all buffers that might eventually
> show up in the minibuffer window, for example, thusly
>
> (progn
>    (set-window-scroll-bars (minibuffer-window) 0 nil)
>    (with-current-buffer (get-buffer-create " *Echo Area 0*")
>      (setq scroll-bar-width 0))
>    (with-current-buffer (get-buffer-create " *Echo Area 1*")
>      (setq scroll-bar-width 0))
>    (with-current-buffer (get-buffer-create " *Minibuf-0*")
>      (setq scroll-bar-width 0))
>    (with-current-buffer (get-buffer-create " *Minibuf-1*")
>      (setq scroll-bar-width 0)))
>
> This should work as long as you don't enable recursive minibuffers.
>
> martin
>
>

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Andrea Greselin <greselin.andrea <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Wed, 19 Jun 2019 11:14:04 +0200

>> That is if I evaluate with emacs -Q
>>    (set-window-scroll-bars (minibuffer-window) 0 nil)
>> and then type M-x, I get the scroll bars back just as you do.
>
> The behaviour is different in my case: when I use
> 'after-make-frame-functions' as in the snippet in my second message,

This one, I suppose

(defun hide-minibuffer-scrollbar (frame)
  (with-selected-frame frame
    (set-window-scroll-bars (minibuffer-window) 0 nil)))

(if (daemonp)
    (add-hook 'after-make-frame-functions #'hide-minibuffer-scrollbar) ; Only for client sessions
  (set-window-scroll-bars (minibuffer-window) 0 nil))

> the
> scroll bar persists after doing M-x. If I evaluate
>    (set-window-scroll-bars (minibuffer-window) 0 nil)
> in a running session, they are displayed only as long as the minibuffer is
> active, and then they are turned off again.

Since I never use emacsclient I can't tell and have no idea how this
is supposed to work.  It could be caused by this part in minibuf.c

  if ((noninteractive
       /* In case we are running as a daemon, only do this before
	  detaching from the terminal.  */
       || (IS_DAEMON && DAEMON_RUNNING))
      && NILP (Vexecuting_kbd_macro))
    {
      val = read_minibuf_noninteractive (prompt, expflag, defalt);
      return unbind_to (count, val);
    }

which avoids saving and restoring the window configuration and thus
removing the scroll bar when restoring.

Maybe someone else can clarify how this is supposed to work.

In a normal session the scroll bar gets removed after M-x is done so
apparently restoring the old window configuration also removes the
scroll bar.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Andrea Greselin <greselin.andrea <at> gmail.com>
Cc: 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Wed, 17 Jul 2019 10:38:39 +0200

[Message part 1 (text/plain, inline)]

> As a temporary workaround you can try to set the buffer local values
> of 'scroll-bar-width' to zero in all buffers that might eventually
> show up in the minibuffer window, for example, thusly
>
> (progn
>    (set-window-scroll-bars (minibuffer-window) 0 nil)
>    (with-current-buffer (get-buffer-create " *Echo Area 0*")
>      (setq scroll-bar-width 0))
>    (with-current-buffer (get-buffer-create " *Echo Area 1*")
>      (setq scroll-bar-width 0))
>    (with-current-buffer (get-buffer-create " *Minibuf-0*")
>      (setq scroll-bar-width 0))
>    (with-current-buffer (get-buffer-create " *Minibuf-1*")
>      (setq scroll-bar-width 0)))
>
> This should work as long as you don't enable recursive minibuffers.

Have you ever tried that workaround?

I now attach a patch that should address this problem with the help of
an additional argument PERSISTENT for 'set-window-scroll-bars' and
'set-window-fringes'.  If set, the requested settings should survive
subsequent invocations of 'set-window-buffer' for the window (in
particular the minibuffer window) in question.  If you build Emacs
yourself, please try it.

Thanks, martin

[scrollbar-fringes-persistent.diff (text/plain, attachment)]

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

From: Andrea Greselin <greselin.andrea <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Thu, 18 Jul 2019 10:12:35 +0200

[Message part 1 (text/plain, inline)]

> Have you ever tried that workaround?
Sorry, I missed it. It works!

> If you build Emacs yourself, please try it.
I wouldn't know how to test it, I'm sorry. I don't build my Emacs.

Thank you,
Andrea

On Wed, 17 Jul 2019 at 10:38, martin rudalics <rudalics <at> gmx.at> wrote:

>  > As a temporary workaround you can try to set the buffer local values
>  > of 'scroll-bar-width' to zero in all buffers that might eventually
>  > show up in the minibuffer window, for example, thusly
>  >
>  > (progn
>  >    (set-window-scroll-bars (minibuffer-window) 0 nil)
>  >    (with-current-buffer (get-buffer-create " *Echo Area 0*")
>  >      (setq scroll-bar-width 0))
>  >    (with-current-buffer (get-buffer-create " *Echo Area 1*")
>  >      (setq scroll-bar-width 0))
>  >    (with-current-buffer (get-buffer-create " *Minibuf-0*")
>  >      (setq scroll-bar-width 0))
>  >    (with-current-buffer (get-buffer-create " *Minibuf-1*")
>  >      (setq scroll-bar-width 0)))
>  >
>  > This should work as long as you don't enable recursive minibuffers.
>
> Have you ever tried that workaround?
>
> I now attach a patch that should address this problem with the help of
> an additional argument PERSISTENT for 'set-window-scroll-bars' and
> 'set-window-fringes'.  If set, the requested settings should survive
> subsequent invocations of 'set-window-buffer' for the window (in
> particular the minibuffer window) in question.  If you build Emacs
> yourself, please try it.
>
> Thanks, martin
>

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Andrea Greselin <greselin.andrea <at> gmail.com>
Cc: 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Fri, 19 Jul 2019 10:15:51 +0200

>> Have you ever tried that workaround?
> Sorry, I missed it. It works!
>
>> If you build Emacs yourself, please try it.
> I wouldn't know how to test it, I'm sorry. I don't build my Emacs.

Then you will have to live with the workaround for the moment.

If there are no objections I will commit the patch in a few days.

Thanks, martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: greselin.andrea <at> gmail.com, 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2;
 'set-window-scroll-bars' setting doesn't take effect in emacsclient
 session
Date: Fri, 19 Jul 2019 12:09:18 +0300

> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 19 Jul 2019 10:15:51 +0200
> Cc: 36193 <at> debbugs.gnu.org
> 
> If there are no objections I will commit the patch in a few days.

I think this change needs to be called out in NEWS.

If you haven't already, please make sure you test the window-resizing
stuff on TTY frames, as your changes affect the code which deals with
that, and we know from bitter experience that it's somewhat fragile.

Thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: greselin.andrea <at> gmail.com, 36193 <at> debbugs.gnu.org
Subject: Re: bug#36193: 26.2; 'set-window-scroll-bars' setting doesn't take
 effect in emacsclient session
Date: Mon, 22 Jul 2019 09:41:16 +0200

tags 36193 fixed
close 36193 27.1
quit

> I think this change needs to be called out in NEWS.

Done.

> If you haven't already, please make sure you test the window-resizing
> stuff on TTY frames, as your changes affect the code which deals with
> that, and we know from bitter experience that it's somewhat fragile.

I had given it some limited testing and I've done a few further tests
now.  Inherently, the old behavior was incorrect in a number of ways.
For example, it was impossible to reduce a minibuffer-only frame to
one text line unless horizontal scroll bars were explicitly disabled
for that frame.  It's now possible to enable horizontal scroll bars on
minibuffer windows although it does not make much sense.

In either case, thanks for the reminder.  Unfortunately, as we know,
frame/window resizing routines depend on too many external factors so
any related changes will always tend to be fragile.

martin, trying to close this bug now

Previous Next

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