bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21734: 25.0.50; cursor-in-non-selected-windows set to nil in gnus-ar


From: Eli Zaretskii
Subject: bug#21734: 25.0.50; cursor-in-non-selected-windows set to nil in gnus-article-mode for no apparent reason
Date: Sun, 01 Nov 2015 18:31:44 +0200

> From: Reiner Steib <reiner.steib@gmx.de>
> Date: Sun, 01 Nov 2015 08:33:34 +0100
> Cc: 21734@debbugs.gnu.org
> 
> On Thu, Oct 22 2015, Oleh Krehel wrote:
> 
> > See commit e4a89ccf738861d7b9c4f611185aa0f204c9c208 from 2006 with:
> >
> > +  (setq cursor-in-non-selected-windows nil)
> >
> > And the following Changelog entry:
> >
> > 2006-04-12  Reiner Steib  <Reiner.Steib@gmx.de>
> >
> >     * gnus-art.el (gnus-article-mode):
> >     Set cursor-in-non-selected-windows to nil.
> >
> > and no further explanation. If there are no objections, I'd like to
> > revert this change, since it's useful to see a hollow cursor in case the
> > buffer with the article isn't selected, and the hollow cursor is the
> > default in all modes except this one.
> 
> Miles Bader suggested this change, I found it useful and Lars approved
> it: See http://thread.gmane.org/gmane.emacs.gnus.general/62017 ...
> 
> | From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> | Subject: Re: cursor-in-non-selected-windows
> | Newsgroups: gmane.emacs.gnus.general
> | Date: 2006-04-12 06:04:52 GMT
> | 
> | Reiner Steib <reinersteib+gmane <at> imap.cc> writes:
> | 
> | > (add-hook 'gnus-article-mode-hook
> | >     (lambda ()
> | >       (setq cursor-in-non-selected-windows nil)))
> | 
> | I think this should be the default.  Any objections?
> 
> Maybe this choice wasn't too bad since no one complained during the
> last 9 years?
> 
> > If a particular user wants the current setting, it can be set in
> > `gnus-article-mode-hook'. It's better than having a non-standard value
> > in one particular mode for all users.
> 
> I had it in my init file before this change.

FWIW, I consider it a bad idea for a package to usurp a user option
like that, unless it has a VERY good reason to do that.  (The thread
you point to is unreadable for some reason -- I see the headers, but
not the body of the messages -- so I couldn't assess how good the
reason was.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]