GNU bug report logs -
#50895
28.0.50; show-paren-mode is distracting in some modes
Previous Next
Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Wed, 29 Sep 2021 17:26:02 UTC
Severity: wishlist
Merged with 50894
Found in version 28.0.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50895 in the body.
You can then email your comments to 50895 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 17:26:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lars Ingebrigtsen <larsi <at> gnus.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 29 Sep 2021 17:26:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I think defaulting show-paren-mode to "on" is a good change in general,
but it's distracting in some modes. For instance, when presenting data
in a buffer, having point flash around when moving around in the buffer
is not what most people will want.
(Think Gnus buffers, *Help* buffers, etc.)
Some people have been using this mode for years, though, and are fine
with the cursor bopping around when trying to read data, so
force-disabling it in (say) `special-mode' isn't quite the answer,
either.
Does anybody see a way to enable it by default in non-special buffers
only, but not explicitly switching it off in special-mode buffers for
those that want it?
In GNU Emacs 28.0.50 (build 23, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
of 2021-09-26 built on elva
Repository revision: 43ae8c828d853382bbc2a27b9e14b9fff6ba18b6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Forcibly Merged 50894 50895.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 29 Sep 2021 17:29:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 17:58:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 50895 <at> debbugs.gnu.org (full text, mbox):
> I think defaulting show-paren-mode to "on" is a good
> change in general, but it's distracting in some modes.
Sounds like a user opinion. Users can turn it
on or off wherever they like.
If you turn it off automatically in some modes
for everyone, then you break the behavior for
users who have customized to turn it on (globally).
Why do that?
If you think now that it should be on globally
by default, then change it to on. That will
break the default behavior for users who've
enjoyed it being off globally by default.
But if you change the default globally to on,
AND you change it to off in some modes where
you happen to think it's distracting, then you
oblige both users who enjoyed it off by default
(globally) AND users who (by customizing)
enjoyed it being on globally to customize Emacs
to adjust to your change.
Remember that `show-paren-mode' is not just
about flashing things. It's also (and mostly)
about just highlighting parens.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 18:00:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 50895 <at> debbugs.gnu.org (full text, mbox):
On 9/29/2021 10:25 AM, Lars Ingebrigtsen wrote:
> I think defaulting show-paren-mode to "on" is a good change in general,
> but it's distracting in some modes. For instance, when presenting data
> in a buffer, having point flash around when moving around in the buffer
> is not what most people will want.
>
> (Think Gnus buffers, *Help* buffers, etc.)
>
> Some people have been using this mode for years, though, and are fine
> with the cursor bopping around when trying to read data, so
> force-disabling it in (say) `special-mode' isn't quite the answer,
> either.
>
> Does anybody see a way to enable it by default in non-special buffers
> only, but not explicitly switching it off in special-mode buffers for
> those that want it?
Perhaps something akin to `font-lock-global-modes'? The help text for
that says:
> If nil, means no modes have Font Lock mode automatically turned on.
> If t, all modes that support Font Lock mode have it automatically turned on.
> If a list, it should be a list of ‘major-mode’ symbol names for which Font Lock
> mode should be automatically turned on. The sense of the list is negated if it
> begins with ‘not’.
Then the default value for `show-paren-global-modes' could be
`(prog-mode)' or `(prog-mode text-mode)', or even `(not special-mode)',
depending on one's opinions about whether `show-paren-mode' makes sense
for prose. That would cover both this bug as well as providing an easy
way for users to customize the major modes where `show-paren-mode' is
enabled (this is already possible with `show-paren-local-mode', but it'd
be a bit simpler with `show-paren-global-modes').
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 18:03:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 50895 <at> debbugs.gnu.org (full text, mbox):
Jim Porter <jporterbugs <at> gmail.com> writes:
> Perhaps something akin to `font-lock-global-modes'? The help text for
> that says:
>
>> If nil, means no modes have Font Lock mode automatically turned on.
>> If t, all modes that support Font Lock mode have it automatically turned on.
>> If a list, it should be a list of ‘major-mode’ symbol names for
>> which Font Lock
>> mode should be automatically turned on. The sense of the list is
>> negated if it
>> begins with ‘not’.
Ah, right -- I thought I remembered that we had some kind of
functionality for minor modes like this, but couldn't remember the
specifics.
> Then the default value for `show-paren-global-modes' could be
> `(prog-mode)' or `(prog-mode text-mode)', or even `(not
> special-mode)', depending on one's opinions about whether
> `show-paren-mode' makes sense for prose. That would cover both this
> bug as well as providing an easy way for users to customize the major
> modes where `show-paren-mode' is enabled (this is already possible
> with `show-paren-local-mode', but it'd be a bit simpler with
> `show-paren-global-modes').
Yes, that makes sense to me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 18:03:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 50895 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 29 Sep 2021 19:25:39 +0200
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>
>
>
> I think defaulting show-paren-mode to "on" is a good change in general,
> but it's distracting in some modes. For instance, when presenting data
> in a buffer, having point flash around when moving around in the buffer
> is not what most people will want.
We don't know what "most people" will want, except what we heard
during the poll. And no one said anything like that there.
FWIW, I'm using show-paren-mode for eons as a global setting in all my
modes and buffers, and have nothing negative to report. So evidently
at least for some this is not as annoying as it could seem.
> Does anybody see a way to enable it by default in non-special buffers
> only, but not explicitly switching it off in special-mode buffers for
> those that want it?
Mode hooks is the usual method. And yes, I'm talking about personal
customizations. Nothing wrong with that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 18:04:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 50895 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> We don't know what "most people" will want, except what we heard
> during the poll. And no one said anything like that there.
I'm not sure anybody even thought about the implications this would have
for buffers that are used for display -- I certainly didn't.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 18:26:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 50895 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 50895 <at> debbugs.gnu.org, dgutov <at> yandex.ru
> Date: Wed, 29 Sep 2021 20:03:43 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > We don't know what "most people" will want, except what we heard
> > during the poll. And no one said anything like that there.
>
> I'm not sure anybody even thought about the implications this would have
> for buffers that are used for display -- I certainly didn't.
But it takes time to collect the implications and to see whether they
are real problems or just personal preferences of the "it annoys me"
kind. Once again, I'm using this as a global setting for eons, and
didn't see any implications that bothered me. So the implications we
hear now are not necessarily clear-cut and objective.
We have deliberately and consciously changed the default. This is
what changing the defaults look like: people who already liked it can
now get rid of their customizations, those who don't like it get to
add customizations, and those who never knew it existed get to try it
and decide whether they like it or not. It is this third category
that is the main audience of such changes. Let's not decide for them
what are the implications, let them try the new default and tell us
about the implications they saw, from their POV.
I think we should only consider clear bugs in this setting, at least
until Emacs 28.1 is released. Disabling it sooner, even partially,
based on "annoys me" reports makes no sense to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 18:33:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 50895 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I'm not sure anybody even thought about the implications this would have
>> for buffers that are used for display -- I certainly didn't.
>
> But it takes time to collect the implications and to see whether they
> are real problems or just personal preferences of the "it annoys me"
> kind. Once again, I'm using this as a global setting for eons, and
> didn't see any implications that bothered me. So the implications we
> hear now are not necessarily clear-cut and objective.
Sure, I'm not arguing for changing anything this second. I opened this
bug report to see if anybody had any input into what options we had if
we wanted to tweak the behaviour, and Jim Porter's suggestion seems
promising to me.
It seems like if we implement something like that, then people who have
(show-paren-mode 1) in their .emacs files already won't be affected at
all, and people who don't have it will have it switched on in
editing-related modes, which is what was discussed on emacs-devel (and
was (I think) the only thing that was discussed there).
> It is this third category that is the main audience of such changes.
> Let's not decide for them what are the implications, let them try the
> new default and tell us about the implications they saw, from their
> POV.
That's what's happening -- both Juri and I saw the changes in a help
buffer and didn't like it, so we piped up.
The system is working as intended. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 18:41:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 50895 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 50895 <at> debbugs.gnu.org, dgutov <at> yandex.ru
> Date: Wed, 29 Sep 2021 20:31:50 +0200
>
> Sure, I'm not arguing for changing anything this second. I opened this
> bug report to see if anybody had any input into what options we had if
> we wanted to tweak the behaviour, and Jim Porter's suggestion seems
> promising to me.
It's okay to discuss this, but I implore us not to make any further
changes just yet, except to fix clear bugs.
> It seems like if we implement something like that, then people who have
> (show-paren-mode 1) in their .emacs files already won't be affected at
> all
Those people are not interesting for this discussion. We changed the
default not for them.
> and people who don't have it will have it switched on in
> editing-related modes, which is what was discussed on emacs-devel (and
> was (I think) the only thing that was discussed there).
I see no reason to turn it on/off partially at this time. The
decision, based on a poll, was to turn it on globally. I don't see
any serious reasons yet to back off, not even partially.
> > It is this third category that is the main audience of such changes.
> > Let's not decide for them what are the implications, let them try the
> > new default and tell us about the implications they saw, from their
> > POV.
>
> That's what's happening -- both Juri and I saw the changes in a help
> buffer and didn't like it, so we piped up.
And your feedback is noted. But we shouldn't act on it, not just yet.
For now, if you don't like it, just turn it off, it's very simple.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 18:52:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 50895 <at> debbugs.gnu.org (full text, mbox):
> > We don't know what "most people" will want, except what we heard
> > during the poll. And no one said anything like that there.
>
> I'm not sure anybody even thought about the implications this would
> have for buffers that are used for display -- I certainly didn't.
Certainly those (such as myself and apparently Eli)
who have long had it customized to ON know those
implications (whatever they might be), and yet those
users chose to turn it on globally.
Maybe what you meant is that users who haven't had
it ON haven't thought about the implications of
turning it on globally, and some (e.g. you) of them
might find it distracting in some modes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Wed, 29 Sep 2021 20:03:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 50895 <at> debbugs.gnu.org (full text, mbox):
On 29.09.2021 21:01, Lars Ingebrigtsen wrote:
> Jim Porter <jporterbugs <at> gmail.com> writes:
>
>> Perhaps something akin to `font-lock-global-modes'? The help text for
>> that says:
>>
>>> If nil, means no modes have Font Lock mode automatically turned on.
>>> If t, all modes that support Font Lock mode have it automatically turned on.
>>> If a list, it should be a list of ‘major-mode’ symbol names for
>>> which Font Lock
>>> mode should be automatically turned on. The sense of the list is
>>> negated if it
>>> begins with ‘not’.
>
> Ah, right -- I thought I remembered that we had some kind of
> functionality for minor modes like this, but couldn't remember the
> specifics.
Unlike font-lock-global-mode, it seems in this case the code will be
checking show-paren-global-modes at runtime (inside show-paren-function,
I guess).
The check should special-case buffer-local values of show-paren-mode, so
it's still possible to enable show-paren-local-mode in buffers where
show-paren-mode is disabled via the new variable.
>> Then the default value for `show-paren-global-modes' could be
>> `(prog-mode)' or `(prog-mode text-mode)', or even `(not
>> special-mode)', depending on one's opinions about whether
>> `show-paren-mode' makes sense for prose. That would cover both this
>> bug as well as providing an easy way for users to customize the major
>> modes where `show-paren-mode' is enabled (this is already possible
>> with `show-paren-local-mode', but it'd be a bit simpler with
>> `show-paren-global-modes').
>
> Yes, that makes sense to me.
The new var, if we add it now, should probably be just t by default.
To avoid changing the behavior for those who customized show-paren-mode
for many years, and yet allow an easy customization point for others who
can by annoyed with the change.
I don't know how to avoid changing the behavior for existing users of
this mode, unless we make the variable itself take different values (can
we?), and have it used instead of adding show-paren-global-modes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Thu, 30 Sep 2021 06:46:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 50895 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Unlike font-lock-global-mode, it seems in this case the code will be
> checking show-paren-global-modes at runtime (inside
> show-paren-function, I guess).
Looking at show-paren-mode again -- I thought we'd agreed to make it a
globalized minor mode instead of a global minor mode? I.e., define it
with `define-globalized-minor-mode'. Did that prove to be difficult to
do (i.e., not backwards-compatible)?
If we do that, then we'd define it exactly like global-font-lock-mode is
defined (with the turn-on-paren-mode-if-desired logic).
> The new var, if we add it now, should probably be just t by default.
>
> To avoid changing the behavior for those who customized
> show-paren-mode for many years, and yet allow an easy customization
> point for others who can by annoyed with the change.
I don't see why the default value of a new `paren-mode-global-modes'
variable would affect people who are saying (show-paren-mode 1) in their
init files? It should only affect those who haven't made any such
customisation already.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Thu, 30 Sep 2021 09:03:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 50895 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 29 Sep 2021 23:02:03 +0300
> Cc: 50895 <at> debbugs.gnu.org
>
> >> Then the default value for `show-paren-global-modes' could be
> >> `(prog-mode)' or `(prog-mode text-mode)', or even `(not
> >> special-mode)', depending on one's opinions about whether
> >> `show-paren-mode' makes sense for prose. That would cover both this
> >> bug as well as providing an easy way for users to customize the major
> >> modes where `show-paren-mode' is enabled (this is already possible
> >> with `show-paren-local-mode', but it'd be a bit simpler with
> >> `show-paren-global-modes').
> >
> > Yes, that makes sense to me.
>
> The new var, if we add it now, should probably be just t by default.
>
> To avoid changing the behavior for those who customized show-paren-mode
> for many years, and yet allow an easy customization point for others who
> can by annoyed with the change.
>
> I don't know how to avoid changing the behavior for existing users of
> this mode, unless we make the variable itself take different values (can
> we?), and have it used instead of adding show-paren-global-modes.
IMNSHO, it would be wrong for us to do that now. show-paren-mode in
its traditional global implementation was tested for many years by
many users, and we have a good understanding of what it does. Turning
it on by default makes that well-understood feature available to
everyone. The problems with that should be minor, mostly related to
personal preferences, as always with defaults.
By contrast, the suggestion here is to turn on by default something we
never tried before. While the chances of it to introduce some serious
regressions are probably not high, they are definitely higher than
simply turning on the mode globally, something we already did. It
makes little sense to me to argue for a long time about a feature,
have a user poll about its turning on, then turn on some different
feature by default. That's not a healthy way of changing defaults in
Emacs, and it runs a higher risk of causing unintended problems.
There's absolutely no justification for that. "Perfect is the enemy
of good."
There's nothing particularly wrong with the current global settings,
except that some people don't like the results. That some don't like
it is expected: that's why this can be customized to turn the feature
off. But I see no real reasons to complicate the mode or invent new
untested aspects of it, just because a few people dislike it or have
their doubts or ideas about how to turn it on/off selectively.
So I don't think we should change anything in this by default. If
someone really wants a way of enabling this more selectively, that's
fine, but then this new behavior should not be the default, because
that's not what we decided and not what we asked the users to provide
the feedback about.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Thu, 30 Sep 2021 09:27:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 50895 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> By contrast, the suggestion here is to turn on by default something we
> never tried before. While the chances of it to introduce some serious
> regressions are probably not high, they are definitely higher than
> simply turning on the mode globally, something we already did.
Sorry, I thought it was understood that the discussions here (about
rewriting how show-paren-mode is implemented) is for Emacs 29. I'm not
proposing doing anything further about the implementation in Emacs 28.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Thu, 30 Sep 2021 10:03:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 50895 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, jporterbugs <at> gmail.com,
> 50895 <at> debbugs.gnu.org
> Date: Thu, 30 Sep 2021 11:26:44 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > By contrast, the suggestion here is to turn on by default something we
> > never tried before. While the chances of it to introduce some serious
> > regressions are probably not high, they are definitely higher than
> > simply turning on the mode globally, something we already did.
>
> Sorry, I thought it was understood that the discussions here (about
> rewriting how show-paren-mode is implemented) is for Emacs 29. I'm not
> proposing doing anything further about the implementation in Emacs 28.
Ah, okay. Sorry for my misunderstanding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Thu, 30 Sep 2021 11:21:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 50895 <at> debbugs.gnu.org (full text, mbox):
On 30.09.2021 09:45, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> Unlike font-lock-global-mode, it seems in this case the code will be
>> checking show-paren-global-modes at runtime (inside
>> show-paren-function, I guess).
>
> Looking at show-paren-mode again -- I thought we'd agreed to make it a
> globalized minor mode instead of a global minor mode? I.e., define it
> with `define-globalized-minor-mode'. Did that prove to be difficult to
> do (i.e., not backwards-compatible)?
The current implementation seems both more efficient (which is good for
an on-by-default mode) and actually easier to do, due to how
show-paren-mode works.
> If we do that, then we'd define it exactly like global-font-lock-mode is
> defined (with the turn-on-paren-mode-if-desired logic).
We don't really have buffer-local timers, AFAIK. So the same nuances
should apply.
>> The new var, if we add it now, should probably be just t by default.
>>
>> To avoid changing the behavior for those who customized
>> show-paren-mode for many years, and yet allow an easy customization
>> point for others who can by annoyed with the change.
>
> I don't see why the default value of a new `paren-mode-global-modes'
> variable would affect people who are saying (show-paren-mode 1) in their
> init files? It should only affect those who haven't made any such
> customisation already.
The value of font-lock-global-modes affects how global-font-lock-mode works.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Thu, 30 Sep 2021 13:41:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 50895 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> The value of font-lock-global-modes affects how global-font-lock-mode works.
Right. But we could make (show-paren-mode 1) set the mooted
show-paren-global-modes to t. Since it's show-paren-mode is on by
default, show-paren-global-modes would basically only be used by those
people who's not explicitly saying (show-paren-mode 1).
And (show-paren-mode -1), for that matter.
So introducing a variable like that (with a default value of `(not
special-mode)') should not affect people who are already explicitly
switching the mode on or off.
Or am I missing something?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Thu, 30 Sep 2021 17:01:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 50895 <at> debbugs.gnu.org (full text, mbox):
On 30.09.2021 16:39, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> The value of font-lock-global-modes affects how global-font-lock-mode works.
>
> Right. But we could make (show-paren-mode 1) set the mooted
> show-paren-global-modes to t. Since it's show-paren-mode is on by
> default, show-paren-global-modes would basically only be used by those
> people who's not explicitly saying (show-paren-mode 1).
>
> And (show-paren-mode -1), for that matter.
>
> So introducing a variable like that (with a default value of `(not
> special-mode)') should not affect people who are already explicitly
> switching the mode on or off.
>
> Or am I missing something?
That should be doable, yes.
I just can't think of another mode that does something similar. So this
kind of special behavior might catch people by surprise.
Anyway, this is not a strong objection, and I might be convinced by a
particular implementation. We could even adopt this practice in more
places, if it really makes sense to people.
At the moment, though, I'm more in favor of adding a *-global-modes
variable, and then, having collected feedback, changing its default in
some future version.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Thu, 30 Sep 2021 17:04:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 50895 <at> debbugs.gnu.org (full text, mbox):
On 30.09.2021 12:02, Eli Zaretskii wrote:
> It
> makes little sense to me to argue for a long time about a feature,
> have a user poll about its turning on, then turn on some different
> feature by default.
I agree. And that's not what I suggested. I just described how "a new
way of enabling this more selectively" could be implemented.
> So I don't think we should change anything in this by default. If
> someone really wants a way of enabling this more selectively, that's
> fine, but then this new behavior should not be the default, because
> that's not what we decided and not what we asked the users to provide
> the feedback about.
Yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Fri, 01 Oct 2021 07:31:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 50895 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Anyway, this is not a strong objection, and I might be convinced by a
> particular implementation. We could even adopt this practice in more
> places, if it really makes sense to people.
>
> At the moment, though, I'm more in favor of adding a *-global-modes
> variable, and then, having collected feedback, changing its default in
> some future version.
Yeah, I think we could do with some experimentation here (on the trunk,
not in Emacs 28), because it's not clear what range of options we have
here (not breaking anybody's setup + introduce a more expressive
selection mechanism). *-global-modes is the mechanism that sounds most
promising now.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Tue, 05 Oct 2021 23:27:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50895; Package
emacs.
(Fri, 02 Sep 2022 12:24:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 50895 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> Sounds good to me, but are there any special-modes where it is useful?
>>>
>>> Perhaps we can just disable it in `special-mode', and if we think of
>>> some modes where it seems really useful, we re-enable it for them?
>>
>> I can't think of any special modes where it's useful, so I think that
>> sounds like a plan.
>
> So here is a new request created from bug#50881.
So I've now done this in Emacs 29.
bug marked as fixed in version 29.1, send any further explanations to
50895 <at> debbugs.gnu.org and Lars Ingebrigtsen <larsi <at> gnus.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 02 Sep 2022 12:24:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 01 Oct 2022 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 207 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.