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 15:59:53 +0200 Message-ID: References: <83lfy5zcqb.fsf@gnu.org> <095ad324-1ba2-253d-9d5d-bb576f722966@gmx.at> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001b2582058b9989d2" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="227712"; 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 16:02:05 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 1hdEgV-000who-U1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Jun 2019 16:02:04 +0200 Original-Received: from localhost ([::1]:58304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdEgH-0003ga-I1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Jun 2019 10:01:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57349) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdEfn-0003aC-Sr for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2019 10:01:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hdEfg-0001ZZ-Nv for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2019 10:01:17 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60029) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hdEfW-0001DE-7z for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2019 10:01:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hdEfW-0000xQ-3X for bug-gnu-emacs@gnu.org; Tue, 18 Jun 2019 10:01:02 -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 14:01:02 +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.15608664393640 (code B ref 36193); Tue, 18 Jun 2019 14:01:02 +0000 Original-Received: (at 36193) by debbugs.gnu.org; 18 Jun 2019 14:00:39 +0000 Original-Received: from localhost ([127.0.0.1]:45340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdEf8-0000we-Ir for submit@debbugs.gnu.org; Tue, 18 Jun 2019 10:00:39 -0400 Original-Received: from mail-pl1-f182.google.com ([209.85.214.182]:46540) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdEf6-0000wO-52 for 36193@debbugs.gnu.org; Tue, 18 Jun 2019 10:00:37 -0400 Original-Received: by mail-pl1-f182.google.com with SMTP id e5so5740949pls.13 for <36193@debbugs.gnu.org>; Tue, 18 Jun 2019 07:00:36 -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=or13dfw/XqqbOkOqN8gQR+w0/OA9wsQ7BYtEO697Uzg=; b=EFrf68u3CrJuC8v1nTXW30lYyjS+tFadB6MGasyIqwJKj4NoXbgUl+3rh5M13bRTwZ QgNFakcQbA1ow307BKZg8BIwYf8DtaAJhxc9V0xmTZV4hriehVoY5e0OgvfpDYKwymzY z1joOa3yyiOHQEPJrE2ZJ+jAQKbiXhrB5+XPfKaI+GDHqP2AOU8ckX2492W4pqiD/Vi6 aOPrAerBkYDDaCdNME8oHdDpBK5PlReS/bFTeS5IQI0+DrtFlnnS5Ah4Y9vEErdtB1MP /56di8RKpIOV0GQMrUr7om7UP4xOjmhpBhsWohXOurXudshtE7yGtzhY2MmKBYBNAFqQ Cp0g== 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=or13dfw/XqqbOkOqN8gQR+w0/OA9wsQ7BYtEO697Uzg=; b=qbdAAD+1uuk5gzVOkIeH3k3PNik7y5EBcts2QB61HsgFVZ12HebigNTJiRohM93syy xqRqHI+vwm/oyWg5IpjG3vaJps+UYqsUO2uOR/QqcZ3XKgMnToQEdhPfZH5CAPKssSe7 fwTgrOcetvpEkHE6eNHSDtBIwznjdKRPjJ1JNu2lryd2TXbooxC15Yo0VQf/o0S3cQT+ 1ITv6DYGqIydjSzuIpPQDchPW5Qoronizzy9Qc7fprZHQoqKk2Es9K731FFqnHzKh+h0 tB1lXao98CsuwpzGU8lDYuLoZhVX01Jwd+EQDR1H2nzdG/th6ZGalE3iodgg4UM7zXZL GZZQ== X-Gm-Message-State: APjAAAWj57tAdd75RUen3+fH4oqUqH41kmLnmZDZ1KYmIGyTsLAc5M0k HMmQOaTTvDmbF7L1xJY2EPSQLJWzuRoEomTvFAI= X-Google-Smtp-Source: APXvYqyYoxckBd44E9yIdyu7YvBHF9O0b0aacP6L3CEEcuOiOOrq28dS8rGtObJ0HSCyc1q8yIUBnflF+WHUOlJxj40= X-Received: by 2002:a17:902:25ab:: with SMTP id y40mr58204389pla.268.1560866430065; Tue, 18 Jun 2019 07:00:30 -0700 (PDT) In-Reply-To: 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:160769 Archived-At: --0000000000001b2582058b9989d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 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 > =E2=80=98set-window-buffer=E2=80=99 (*note Buffers and Windows::) o= n WINDOW with > its KEEP-MARGINS argument =E2=80=98nil=E2=80=99 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 > > --0000000000001b2582058b9989d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> That is if I evaluate with emacs -Q
>=C2=A0=C2=A0 (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 u= se 'after-make-frame-functions' as in the snippet in my second mess= age, the scroll bar persists after doing M-x. If I evaluate
=C2=A0 (set-window-scroll-bars (minibuffer-window) 0 nil)
in a running session, they are displayed only as long as the mini= buffer is active, and then they are turned off again.

On Tue, 18 J= un 2019 at 15:42, martin rudalics <ru= dalics@gmx.at> wrote:
=C2=A0> Yes. If in 'hide-minibuffer-scrollbar' I re= place '(minibuffer-window)' with
=C2=A0> 'nil', the scratch buffer has no scroll bars and they do= n't reappear even
=C2=A0> if the buffer become longer than the window height. They are onl= y
=C2=A0> re-enabled if I open another buffer in that window, and then the= y persist.

Ahh...=C2=A0 I should have asked you that so it's good you noticed it.<= br> This shows that the behavior is not minibuffer window specific.

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

So showing another buffer in the minibuffer window reenables the
scroll bars.=C2=A0 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.=C2=A0 = 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.=C2=A0 The
behavior is described in the Elisp manual on 'set-window-scroll-bars= 9;

=C2=A0 =C2=A0 =C2=A0 The values specified here may be later overridden by i= nvoking
=C2=A0 =C2=A0 =C2=A0 =E2=80=98set-window-buffer=E2=80=99 (*note Buffers and= Windows::) on WINDOW with
=C2=A0 =C2=A0 =C2=A0 its KEEP-MARGINS argument =E2=80=98nil=E2=80=99 or omi= tted.

but I consistently forget about it.

If people agree that this is a bug, we can try to find a more general
fix.=C2=A0 Otherwise, I'll fix the minibuffer window scroll bars with t= he
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<= br> show up in the minibuffer window, for example, thusly

(progn
=C2=A0 =C2=A0(set-window-scroll-bars (minibuffer-window) 0 nil)
=C2=A0 =C2=A0(with-current-buffer (get-buffer-create " *Echo Area 0*&q= uot;)
=C2=A0 =C2=A0 =C2=A0(setq scroll-bar-width 0))
=C2=A0 =C2=A0(with-current-buffer (get-buffer-create " *Echo Area 1*&q= uot;)
=C2=A0 =C2=A0 =C2=A0(setq scroll-bar-width 0))
=C2=A0 =C2=A0(with-current-buffer (get-buffer-create " *Minibuf-0*&quo= t;)
=C2=A0 =C2=A0 =C2=A0(setq scroll-bar-width 0))
=C2=A0 =C2=A0(with-current-buffer (get-buffer-create " *Minibuf-1*&quo= t;)
=C2=A0 =C2=A0 =C2=A0(setq scroll-bar-width 0)))

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

martin

--0000000000001b2582058b9989d2--