From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Heime Newsgroups: gmane.emacs.help Subject: Re: Improving Scroll Bar Tools Date: Sun, 12 May 2024 16:10:46 +0000 Message-ID: References: <86plts3g26.fsf@gnu.org> <86seyo1fda.fsf@gnu.org> <86cypr1s0c.fsf@gnu.org> <86le4fysyv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4832"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 12 18:11:28 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s6BnL-00016Y-Ti for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 12 May 2024 18:11:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s6Bmt-00033h-74; Sun, 12 May 2024 12:10:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s6Bmr-00033U-MK for help-gnu-emacs@gnu.org; Sun, 12 May 2024 12:10:57 -0400 Original-Received: from mail-40137.protonmail.ch ([185.70.40.137]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s6Bmp-0004Y8-EG for help-gnu-emacs@gnu.org; Sun, 12 May 2024 12:10:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1715530251; x=1715789451; bh=/yIt+qHVFUdxT2mekcYinWw7Fe0RCsvXVBkwih6ytaI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=n77NBoTYSUWfdAnVVpyC9mf146CFEfS0hH0M9n56FVKEYrWgNqnHbiwA8xfVDCyYh 5mDmXGbf9ON071RSOuvSLnMq72KIG4RuqtunMHqkQfcKYqVsI7rONAQ5G+f/Btg/hu eyB05HO+J1ox001okVxj2S1kuJjqkXUwaHBa6B6058f5uZ6bjkTGLIUeHgUHGs99C8 iePPDohqqv+1QSokWOfv1dflijzpzsQVJJrMeitYhwcI5Ft7zBIDc4EEYetYS2zPOg 9DuZ11qTOur4SGGGCv0swtSpdlRd9SmzbFY9ZSyNZdCzXHjK/sAa2W5ZFbTVeN8Mxm jnfF98/0ae3tA== In-Reply-To: <86le4fysyv.fsf@gnu.org> Feedback-ID: 57735886:user:proton X-Pm-Message-ID: a3704b9042366c2a744465048a35e9d3ed859e36 Received-SPF: pass client-ip=185.70.40.137; envelope-from=heimeborgia@protonmail.com; helo=mail-40137.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:146689 Archived-At: On Monday, May 13th, 2024 at 3:01 AM, Eli Zaretskii wrote: > > Date: Sun, 12 May 2024 13:51:47 +0000 > > From: Heime heimeborgia@protonmail.com > > Cc: help-gnu-emacs@gnu.org > >=20 > > On Sunday, May 12th, 2024 at 6:08 PM, Eli Zaretskii eliz@gnu.org wrote: > >=20 > > > No, I don't agree. The commands and features implemented by such a > > > package should be able to take care of that without relying on the > > > user's memory. The infrastructure exists already, for example in the > > > form of scroll-bar-mode-hook and its ilk. > >=20 > > My point was identical - the package should take care of things without > > relying upon the user's memory. I tried using my memory and it was awfu= l. > >=20 > > How can a package know whether a window-specific setting was introduced= by > > set-window-scroll-bars ? >=20 >=20 > By looking at the value returned by window-scroll-bars. >=20 > > Would you be kind enough to show the specific use of scroll-bar-mode-ho= ok and > > its ilk for the purpose you have in mind, so I can develop it ? >=20 >=20 > Sorry, I don't have time (and I don't really know what you'd like to > do when frame's scroll-bars are changed). I can describe the idea: in > the hook function use set-window-scroll-bars to change the > window-specific scroll bars according to what you want. Eli, when set-window-scroll-bars have been applied to a window I want to kn= ow some settings were applied. That what you'd like to know. For the reason that I would know that those windows would be unaffected by user changes to the minor mode settings. Are you suggesting that I hook functions that handle set-window-scroll-bars= =20 commands with the scroll minor modes ? Once a window settings have been changed by set-window-scroll-bars, how can one release the change and make them once again affected by the minor modes= . In a previous comment, you described that the aforementioned situation migh= t not be a good idea because their use is not designed for such sort of thing= . What would be the standard procedure then, to kill or close the window ? =20