From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Greselin Newsgroups: gmane.emacs.bugs Subject: 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-ID: References: <83lfy5zcqb.fsf@gnu.org> <095ad324-1ba2-253d-9d5d-bb576f722966@gmx.at> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b6f6f2058b9881ea" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="180315"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36193@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 18 14:52:25 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hdDb6-000knP-TZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Jun 2019 14:52:25 +0200 Original-Received: from localhost ([::1]:57006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdDb5-0005yd-QC for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Jun 2019 08:52:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35795) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdDX3-0000tI-WC for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2019 08:48:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hdDWw-0003E6-QO for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2019 08:48:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58603) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hdDWs-000371-3H for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2019 08:48:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hdDWr-0004z4-Pg for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2019 08:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Greselin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Jun 2019 12:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36193 X-GNU-PR-Package: emacs Original-Received: via spool by 36193-submit@debbugs.gnu.org id=B36193.156086202219007 (code B ref 36193); Tue, 18 Jun 2019 12:48:01 +0000 Original-Received: (at 36193) by debbugs.gnu.org; 18 Jun 2019 12:47:02 +0000 Original-Received: from localhost ([127.0.0.1]:43913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdDVt-0004wM-Nw for submit@debbugs.gnu.org; Tue, 18 Jun 2019 08:47:02 -0400 Original-Received: from mail-pg1-f181.google.com ([209.85.215.181]:39542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdDVp-0004vU-By for 36193@debbugs.gnu.org; Tue, 18 Jun 2019 08:46:58 -0400 Original-Received: by mail-pg1-f181.google.com with SMTP id 196so7650332pgc.6 for <36193@debbugs.gnu.org>; Tue, 18 Jun 2019 05:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WfJcfullGp4NqcYu4OtpPY+fiFZyoF7Zav5CGrIJk+4=; b=Ra5ZspFDoQGcGEE5OrTIHNMrvaAsxiLnzmifsLMW8hLdSANT4hgxU9+Wb6K4gIcdxf lv1HePUl40ofufGo4vTTgRVqUsbwdMMY0wG8uCAQoy0Bz9NK5qs7VbKh+gtYxzWkxgJ+ ssibaPnJ/Lgg5Pl0IDJZuBtlpHjRn67k5l+yiR5t3hrSqiq90uCo0wnis3sioS6NfmU2 gOrfBczZCVwW68uHz2KvjhZ64d1CjQuYRhlFzD8ognl7vzqbc6mzUFN7u8l/G/5Hd0M8 o1uvt2e5R//tQefboOhM/nmO/wlrogEQ8v7NJ0WtNqjpdMrSfWVIvFL9XOU2s0bdtDl3 azzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WfJcfullGp4NqcYu4OtpPY+fiFZyoF7Zav5CGrIJk+4=; b=LVJsXFXiqMoTMNMV5GFiXgXEE3S8ZOYYYFN37PCg9dM0c1EG/wNXKB6gf9Zd/x5COh OXKVgGGTRKHvZ6SS3iiz8z+Ty2OyyOJPnxYK53IIDr82t1vHKhIj4O00MerQXjZqs7zU KxoD2ysiEAzl5zyBySz5KyoVOt9Tl24vnNmGL21wPVdzqdTxUppsWfOrrUEpKCI4NqhH O/BOlO9ht4dccov7YRt5WjSqjW4svC0iWLyOnqUinBpFluWuR3rpi+BVceIrWEZM4GG9 BMZWOTYklneZw2KoA05ZOjaE97Fd8D6MTiDrR1fVlVguHOtv+xCnejaY8NFDJM9uYFwg TiYQ== X-Gm-Message-State: APjAAAVzTpXjwtF2oj3BA9BjmCPKw34Y2PC71Xd0WBfxqIWvDFJKv0WY 2PIpmATgGo+7NFBySJvqycc1LMOSkRb7n0+bMew= X-Google-Smtp-Source: APXvYqzT0pGGDEDeTfZzZKfs826xaBzccxzdMnMVRm1g7ldWmu367qFa3GMU1rtOdGSzx/93Ou6unigx1miI5pWrroA= X-Received: by 2002:a17:90a:cb12:: with SMTP id z18mr4759343pjt.82.1560862011093; Tue, 18 Jun 2019 05:46:51 -0700 (PDT) In-Reply-To: <095ad324-1ba2-253d-9d5d-bb576f722966@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:160765 Archived-At: --000000000000b6f6f2058b9881ea Content-Type: text/plain; charset="UTF-8" > (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 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 > --000000000000b6f6f2058b9881ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> (1) Is this behavior special= for the minibuffer window?=C2=A0 That is, if
> in 'after-make-frame-functions' you removed the scroll bar fro= m any
> other window, does it stay removed when you switch to that wi= ndow
> repeatedly?
Yes. If in 'hide-minibuffer-scrollbar&#= 39; I replace '(min= ibuffer-window)' with 'nil', the scratch buffer has no scroll bars and they don'= ;t=20 reappear even if the buffer become longer than the window height. They=20 are only re-enabled if I open another buffer in that window, and then=20 they persist.

> (2) Do= es showing a message in the echo area suffice to make the scroll
> ba= r reappear?=C2=A0 With other words, what does "use" the minibuffe= r 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=20 they are re-enabled.

>= (3) I suppose "it isn't removed afterwards" means you can st= ill remove
> the scroll bar explicitly via 'set-window-scroll-bar= s' afterwards.
> Right?=C2=A0 And if you do that, does it come ba= ck after yet another "use"
> of the minibuffer?
Yes I can still remove them by evaluating '(set-window-scroll-bars=20 (minibuffer-window) 0 nil)'. Then they are only shown while the=20 minibuffer is active (which is the same behaviour I get right from the=20 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 n= or in a running emacsclient session.

Best, andrea<= /div>

On Sun, 16 Jun 2019 at 10:17, martin rudalics <rudalics@gmx.at> wrote:
=C2=A0> Trying to follow your suggestion I= 've written
=C2=A0>
=C2=A0>=C2=A0 =C2=A0 (defun hide-minibuffer-scrollbar (frame)
=C2=A0>=C2=A0 =C2=A0 =C2=A0 (with-selected-frame frame
=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (set-window-scroll-bars (minibuffer-w= indow) 0 nil)))
=C2=A0>=C2=A0 =C2=A0 (if (daemonp)
=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (add-hook 'after-make-frame-funct= ions #'hide-minibuffer-scrollbar) ; Only for client sessions
=C2=A0>=C2=A0 =C2=A0 =C2=A0 (set-window-scroll-bars (minibuffer-window) = 0 nil))
=C2=A0>
=C2=A0> Now client sessions start without the minibuffer scrollbar, but = as soon as
=C2=A0> I use the minibuffer it comes back and it isn't removed afte= rwards.

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 in= to
play here.

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

(1) Is this behavior special for the minibuffer window?=C2=A0 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?=C2=A0 With other words, what does "use" the minibuf= fer stand
for?

(3) I suppose "it isn't removed afterwards" means you can sti= ll remove
the scroll bar explicitly via 'set-window-scroll-bars' afterwards.<= br> Right?=C2=A0 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
--000000000000b6f6f2058b9881ea--