* bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default
2014-09-01 18:42 ` Eli Zaretskii
@ 2014-09-01 22:21 ` Stefan Monnier
2014-09-01 22:47 ` Josh Triplett
` (2 subsequent siblings)
3 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2014-09-01 22:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 755351-forwarded, rlb, 18372, 755351, Josh Triplett
> Why should we only take blink-cursor-mode from there, and ignore all
> the rest?
Nobody asked to ignore the rest ;-)
> E.g., cursor-blink-time and cursor-blink-timeout. And then
> there are other settings, like cursor-size, clock-format, etc. It
> makes very little sense to take only one setting.
Currently we only take a few things such as foreground and
background color. I agree that we should take "anything that's
applicable".
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default
2014-09-01 18:42 ` Eli Zaretskii
2014-09-01 22:21 ` Stefan Monnier
@ 2014-09-01 22:47 ` Josh Triplett
2014-09-02 4:57 ` Jan Djärv
2014-09-02 5:05 ` Jan Djärv
3 siblings, 0 replies; 13+ messages in thread
From: Josh Triplett @ 2014-09-01 22:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 755351-forwarded, rlb, 18372, 755351
On Mon, Sep 01, 2014 at 09:42:15PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 1 Sep 2014 11:24:31 -0700
> > From: Josh Triplett <josh@joshtriplett.org>
> > Cc: 755351@bugs.debian.org, Rob Browning <rlb@defaultvalue.org>,
> > 18372@debbugs.gnu.org, 755351-forwarded@bugs.debian.org
> >
> > For the simplest possible implementation, determine the desktop setting
> > for whether the cursor should blink, and set blink-cursor-mode to that
> > at startup; any explicit setting would then override that.
>
> Why should we only take blink-cursor-mode from there, and ignore all
> the rest? E.g., cursor-blink-time and cursor-blink-timeout. And then
> there are other settings, like cursor-size, clock-format, etc. It
> makes very little sense to take only one setting.
>
> (I know nothing about GTK, so apologies if these are silly questions.)
By all means, please do so. blink-cursor-mode was just the particular
one that motivated my report.
- Josh Triplett
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default
2014-09-01 18:42 ` Eli Zaretskii
2014-09-01 22:21 ` Stefan Monnier
2014-09-01 22:47 ` Josh Triplett
@ 2014-09-02 4:57 ` Jan Djärv
2014-09-02 5:05 ` Jan Djärv
3 siblings, 0 replies; 13+ messages in thread
From: Jan Djärv @ 2014-09-02 4:57 UTC (permalink / raw)
To: Eli Zaretskii
Cc: 755351@bugs.debian.org, rlb@defaultvalue.org, Josh Triplett,
18372@debbugs.gnu.org, 755351-forwarded@bugs.debian.org
Hi.
1 sep 2014 kl. 20:42 skrev Eli Zaretskii <eliz@gnu.org>:
>> Date: Mon, 1 Sep 2014 11:24:31 -0700
>> From: Josh Triplett <josh@joshtriplett.org>
>> Cc: 755351@bugs.debian.org, Rob Browning <rlb@defaultvalue.org>,
>> 18372@debbugs.gnu.org, 755351-forwarded@bugs.debian.org
>>
>> For the simplest possible implementation, determine the desktop setting
>> for whether the cursor should blink, and set blink-cursor-mode to that
>> at startup; any explicit setting would then override that.
>
> Why should we only take blink-cursor-mode from there, and ignore all
> the rest? E.g., cursor-blink-time and cursor-blink-timeout. And then
> there are other settings, like cursor-size, clock-format, etc. It
> makes very little sense to take only one setting.
>
> (I know nothing about GTK, so apologies if these are silly questions.)
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default
2014-09-01 18:42 ` Eli Zaretskii
` (2 preceding siblings ...)
2014-09-02 4:57 ` Jan Djärv
@ 2014-09-02 5:05 ` Jan Djärv
2022-06-29 14:55 ` Stefan Kangas
3 siblings, 1 reply; 13+ messages in thread
From: Jan Djärv @ 2014-09-02 5:05 UTC (permalink / raw)
To: Eli Zaretskii
Cc: 755351@bugs.debian.org, rlb@defaultvalue.org, Josh Triplett,
18372@debbugs.gnu.org, 755351-forwarded@bugs.debian.org
Hi.
1 sep 2014 kl. 20:42 skrev Eli Zaretskii <eliz@gnu.org>:
>> Date: Mon, 1 Sep 2014 11:24:31 -0700
>> From: Josh Triplett <josh@joshtriplett.org>
>> Cc: 755351@bugs.debian.org, Rob Browning <rlb@defaultvalue.org>,
>> 18372@debbugs.gnu.org, 755351-forwarded@bugs.debian.org
>>
>> For the simplest possible implementation, determine the desktop setting
>> for whether the cursor should blink, and set blink-cursor-mode to that
>> at startup; any explicit setting would then override that.
>
> Why should we only take blink-cursor-mode from there, and ignore all
> the rest? E.g., cursor-blink-time and cursor-blink-timeout. And then
> there are other settings, like cursor-size, clock-format, etc. It
> makes very little sense to take only one setting.
Those that we look at had a GUI in Gnome at one point to change them. Also the set of settings has not been very stable. There is no GUI in current Gnome to change them, so they aren't really the place where a user can easily tweak settings.
So in 99% (figure from air) of the cases these settings are never changed. It is not worth it to track a setting that with high probability will be removed or change name/place within two years.
Jan D.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default
2014-09-02 5:05 ` Jan Djärv
@ 2022-06-29 14:55 ` Stefan Kangas
2022-06-30 1:09 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Kangas @ 2022-06-29 14:55 UTC (permalink / raw)
To: Jan Djärv
Cc: 18372@debbugs.gnu.org, Josh Triplett, Po Lu, rlb@defaultvalue.org,
Eli Zaretskii, 755351@bugs.debian.org,
755351-forwarded@bugs.debian.org
Jan Djärv <jan.h.d@swipnet.se> writes:
> Hi.
>
> 1 sep 2014 kl. 20:42 skrev Eli Zaretskii <eliz@gnu.org>:
>
>>> Date: Mon, 1 Sep 2014 11:24:31 -0700
>>> From: Josh Triplett <josh@joshtriplett.org>
>>> Cc: 755351@bugs.debian.org, Rob Browning <rlb@defaultvalue.org>,
>>> 18372@debbugs.gnu.org, 755351-forwarded@bugs.debian.org
>>>
>>> For the simplest possible implementation, determine the desktop setting
>>> for whether the cursor should blink, and set blink-cursor-mode to that
>>> at startup; any explicit setting would then override that.
>>
>> Why should we only take blink-cursor-mode from there, and ignore all
>> the rest? E.g., cursor-blink-time and cursor-blink-timeout. And then
>> there are other settings, like cursor-size, clock-format, etc. It
>> makes very little sense to take only one setting.
>
> Those that we look at had a GUI in Gnome at one point to change them. Also the
> set of settings has not been very stable. There is no GUI in current Gnome to
> change them, so they aren't really the place where a user can easily tweak
> settings.
>
> So in 99% (figure from air) of the cases these settings are never
> changed. It is not worth it to track a setting that with high
> probability will be removed or change name/place within two years.
So if we don't want to chase these settings, does it make sense to keep
this bug open? Maybe Po Lu has any comments?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#18372: Bug#755351: blink-cursor-mode should respect GTK+ setting by default
2022-06-29 14:55 ` Stefan Kangas
@ 2022-06-30 1:09 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-05 11:51 ` Stefan Kangas
0 siblings, 1 reply; 13+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-30 1:09 UTC (permalink / raw)
To: Stefan Kangas
Cc: Josh Triplett, 18372@debbugs.gnu.org, rlb@defaultvalue.org,
Eli Zaretskii, Jan Djärv, 755351@bugs.debian.org,
755351-forwarded@bugs.debian.org
Stefan Kangas <stefan@marxist.se> writes:
>> Those that we look at had a GUI in Gnome at one point to change them. Also the
>> set of settings has not been very stable. There is no GUI in current Gnome to
>> change them, so they aren't really the place where a user can easily tweak
>> settings.
>>
>> So in 99% (figure from air) of the cases these settings are never
>> changed. It is not worth it to track a setting that with high
>> probability will be removed or change name/place within two years.
>
> So if we don't want to chase these settings, does it make sense to keep
> this bug open? Maybe Po Lu has any comments?
No, I think it should be closed.
^ permalink raw reply [flat|nested] 13+ messages in thread