Kill all proportional fonts!

Kill all proportional fonts!

[Colin Baxter 😺]

Hello,

I am beginning to hate with a vengeance the new proportional fonts used
in emacs-29.0.50. They seem to crop up everywhere. I have got rid of them
from the mode-line and gnus headers but now they appear in eww and gnus 
html articles. The latter I can wash with toggle html fonts. But I want
a permanent global solution. Is there any emacs-init setting I can use
to banish proportional fonts totally from emacs - preferably forever.

If it's relevant, I have

(set-frame-font
 "-unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1")

Thank you.

Colin Baxter.

Re: Kill all proportional fonts!

[Eli Zaretskii]

> From: Colin Baxter 😺 <m43cap@yandex.com>
> Date: Mon, 27 Dec 2021 18:19:24 +0000
> 
> I am beginning to hate with a vengeance the new proportional fonts used
> in emacs-29.0.50. They seem to crop up everywhere. I have got rid of them
> from the mode-line and gnus headers but now they appear in eww and gnus 
> html articles. The latter I can wash with toggle html fonts. But I want
> a permanent global solution. Is there any emacs-init setting I can use
> to banish proportional fonts totally from emacs - preferably forever.

Try customizing the variable-pitch face to use a fixed-pitch font.

Re: Kill all proportional fonts!

[Kévin Le Gouguec]

Colin Baxter 😺 <m43cap@yandex.com> writes:

>                                                              But I want
> a permanent global solution. Is there any emacs-init setting I can use
> to banish proportional fonts totally from emacs - preferably forever.

The Modus themes provide a straightforward boolean user option
(modus-themes-variable-pitch-ui) to opt in to proportional fonts; FWIW,
I think it would make sense for Emacs to provide similar user options
(e.g. ui-use-variable-pitch, shr-use-variable-pitch,
outline-use-variable-pitch).

IMO it would be more user-friendly and robust than advising users to
tweak face attributes themselves.  Consider the snippet we put in NEWS
during last month's mode-line experiment:

> (set-face-attribute 'mode-line nil :inherit 'default)

This puts the onus on the user to check future releases to make sure the
mode-line face is not supposed to inherit from other elements beside
variable-pitch.  Conversely, Modus-style booleans mean the user can rest
easy assuming Emacs will DTRT.

Disclaimer: I like those proportional fonts and don't mind them
"creeping in".  I'm also fine in principle with them being opt-in
(instead of opt-out like they were during the mode-line experiment);
however I'd rather not stick calls to set-face-attribute in my config,
for the reason given above.

Re: Kill all proportional fonts!

[Colin Baxter 😺]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

    >> From: Colin Baxter 😺️ <m43cap@yandex.com> Date: Mon, 27 Dec 2021
    >> 18:19:24 +0000
    >> 
    >> I am beginning to hate with a vengeance the new proportional
    >> fonts used in emacs-29.0.50. They seem to crop up everywhere. I
    >> have got rid of them from the mode-line and gnus headers but now
    >> they appear in eww and gnus html articles. The latter I can wash
    >> with toggle html fonts. But I want a permanent global
    >> solution. Is there any emacs-init setting I can use to banish
    >> proportional fonts totally from emacs - preferably forever.

    > Try customizing the variable-pitch face to use a fixed-pitch font.

Thanks.

Setting (set-face-font 'variable-pitch "DejaVu Sans Mono-11")
worked. I've also got a less drastic solution in defining a
fixed-pitch-mode as a buffer-face-mode and then hooking a mode
(e.g. eww-mode) to it.

Best wishes.
 

Re: Kill all proportional fonts!

[Colin Baxter 😺]

>>>>> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
 
    > Disclaimer: I like those proportional fonts

I'm afraid I don't like them one little bit.

Re: Kill all proportional fonts!

[Colin Baxter 😺]

>>>>> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

    > Colin Baxter 😺 <m43cap@yandex.com> writes:
    >> But I want a permanent global solution. Is there any emacs-init
    >> setting I can use to banish proportional fonts totally from emacs
    >> - preferably forever.

    > The Modus themes provide a straightforward boolean user option
    > (modus-themes-variable-pitch-ui) to opt in to proportional fonts;
    > FWIW, I think it would make sense for Emacs to provide similar
    > user options (e.g. ui-use-variable-pitch, shr-use-variable-pitch,
    > outline-use-variable-pitch).

    > IMO it would be more user-friendly and robust than advising users
    > to tweak face attributes themselves.  Consider the snippet we put
    > in NEWS during last month's mode-line experiment:

    >> (set-face-attribute 'mode-line nil :inherit 'default)

    > This puts the onus on the user to check future releases to make
    > sure the mode-line face is not supposed to inherit from other
    > elements beside variable-pitch.  Conversely, Modus-style booleans
    > mean the user can rest easy assuming Emacs will DTRT.

I agree. I personally don't like having to alter my ~/.emacs just to stay the
same. I think it should be the other way round - but what do I know?

Best wishes,

Colin Baxter.

Re: Kill all proportional fonts!

[tomas]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Tue, Dec 28, 2021 at 07:32:14AM +0000, Colin Baxter 😺 wrote:
> >>>>> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

[...]

>     > This puts the onus on the user [...]

> I agree. I personally don't like having to alter my ~/.emacs just to stay the
> same. I think it should be the other way round - but what do I know?

Who does. Usually, I'm the one complaining when things move too fast.

OTOH, I think "unchanging defaults" would put the bar too high for such
a long-lived thing as Emacs is. There may be defaults which made sense
in VT220 times and are too limiting nowadays, to put a somewhat extreme
example.

All in all I'm very happy the way Emacs handles things. Usually, changes
in defaults are discussed extensively and done carefully.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Kill all proportional fonts!

[Po Lu]

<tomas@tuxteam.de> writes:

> Who does.

I don't mind the changes to Gnus, but I mind the changes to the
modeline.  IMO, it should always stay optional.

Re: Kill all proportional fonts!

[tomas]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On Tue, Dec 28, 2021 at 04:00:39PM +0800, Po Lu wrote:
> <tomas@tuxteam.de> writes:
> 
> > Who does.
> 
> I don't mind the changes to Gnus, but I mind the changes to the
> modeline.  IMO, it should always stay optional.

We are in violent agreement there. That makes it so complicated: Someone
is going to object to every change. No change at all is not an option,
long term. Somehow this has to be navigated, in the best case without
yelling at each other :-)

That's why I am really impressed by the way Emacs manages things.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Kill all proportional fonts!

[Po Lu]

tomas@tuxteam.de writes:

> We are in violent agreement there.  That makes it so complicated:
> Someone is going to object to every change.

Not true: for example, I don't see anyone objecting to the fix for
bug#52809 that was checked in this morning, even though it changes some
previously established behaviour of the Lucid toolkit.

Re: Kill all proportional fonts!

[tomas]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Tue, Dec 28, 2021 at 05:38:07PM +0800, Po Lu wrote:
> tomas@tuxteam.de writes:
> 
> > We are in violent agreement there.  That makes it so complicated:
> > Someone is going to object to every change.
> 
> Not true:

:-)

>           for example, I don't see anyone objecting to the fix for
> bug#52809 that was checked in this morning, even though it changes some
> previously established behaviour of the Lucid toolkit.

OK, OK, let's agree on "most changes". Or at least "a sizeable
proportion of them".

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Kill all proportional fonts!

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Not true: for example, I don't see anyone objecting to the fix for
> bug#52809 that was checked in this morning, even though it changes some
> previously established behaviour of the Lucid toolkit.

https://xkcd.com/1172/


        Stefan

Someone start maintaining luddites.el

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

* 2021-12-28 07:32:14+0000, Colin Baxter wrote:

> I agree. I personally don't like having to alter my ~/.emacs just to
> stay the same. I think it should be the other way round - but what do
> I know?

Maybe don't ask other people (Emacs developers) to do things for you.
Create and maintain an Emacs package which keeps current and future
Emacses just like "in the old days." The package wouldn't do much, just
gradually add configuration options which disable everything new. I
wouldn't use it myself but I think some/many people would be grateful.
Name it luddites.el, or something.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 434 bytes --]

Re: Someone start maintaining luddites.el

[Colin Baxter 😺]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

>>>>> Teemu Likonen <tlikonen@iki.fi> writes:

    > * 2021-12-28 07:32:14+0000, Colin Baxter wrote:
    >> I agree. I personally don't like having to alter my ~/.emacs just
    >> to stay the same. I think it should be the other way round - but
    >> what do I know?

    > Maybe don't ask other people (Emacs developers) to do things for
    > you.

??????????

I think you have misunderstood. I was expressing an opinion. Read the thread.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Someone start maintaining luddites.el

[Fu Yuan]

> 在 2021年12月28日，上午11:37，Teemu Likonen <tlikonen@iki.fi> 写道：
> 
> * 2021-12-28 07:32:14+0000, Colin Baxter wrote:
> 
>> I agree. I personally don't like having to alter my ~/.emacs just to
>> stay the same. I think it should be the other way round - but what do
>> I know?
> 
> Maybe don't ask other people (Emacs developers) to do things for you.
> Create and maintain an Emacs package which keeps current and future
> Emacses just like "in the old days." The package wouldn't do much, just
> gradually add configuration options which disable everything new. I
> wouldn't use it myself but I think some/many people would be grateful.
> Name it luddites.el, or something.
> 
I think similar thing has been brought up when we were discussing changing defaults in new Emacs, but I don’t remember the conclusion. Were there any problems with it, is anyoneworking on that?

Yuan

Re: Someone start maintaining luddites.el

[Stefan Monnier via Users list for the GNU Emacs text editor]

> I think similar thing has been brought up when we were discussing changing
> defaults in new Emacs, but I don’t remember the conclusion. Were there any
> problems with it, is anyoneworking on that?

I think the main problem is whether this file should try and mimic the
defaults of Emacs-27, or Emacs-24, or Emacs-21, or Emacs-18, ...


        Stefan

Re: Someone start maintaining luddites.el

[Fu Yuan]

> 在 2021年12月28日，下午3:42，Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> 写道：
> 
> 
>> 
>> I think similar thing has been brought up when we were discussing changing
>> defaults in new Emacs, but I don’t remember the conclusion. Were there any
>> problems with it, is anyoneworking on that?
> 
> I think the main problem is whether this file should try and mimic the
> defaults of Emacs-27, or Emacs-24, or Emacs-21, or Emacs-18, ...

It shouldn’t be hard to allow users to choose a release they want to stick to, no? For a starter we can have Emacs 28 when 29 releases. And with each following release we can add the previous release to possible fallback list.

Providing fall back for releases prior to 28 might not be very useful, as users who want to old behavior must already have the configuration written in their init file.

Yuan

Re: Someone start maintaining luddites.el

[Stefan Monnier via Users list for the GNU Emacs text editor]

> It shouldn’t be hard to allow users to choose a release they want to stick
> to, no? For a starter we can have Emacs 28 when 29 releases. And with each
> following release we can add the previous release to possible fallback list.

Go for it!


        Stefan

Re: Someone start maintaining luddites.el

[Po Lu]

Fu Yuan <casouri@gmail.com> writes:

> It shouldn’t be hard to allow users to choose a release they want to
> stick to, no? For a starter we can have Emacs 28 when 29 releases. And
> with each following release we can add the previous release to
> possible fallback list.
>
> Providing fall back for releases prior to 28 might not be very useful,
> as users who want to old behavior must already have the configuration
> written in their init file.

I expect future versions of Emacs to behave generally the same way as
Emacs 23 or 27, so that I do not get lost trying to use it, but I don't
want to remember how Emacs 28 (or 29, or 30, or 31) behaved so I can
pick a version whose behaviour it should emulate, if that behaviour is
even enumerable.

Such a compatibility layer will probably have to be constantly updated
as well to fit with changes in later versions of Emacs.

The solution is simply to not change the default values of options when
it is not due, and to change them when it is, forgoing any of the
"compatibility layer" nonsense.

Re: Someone start maintaining luddites.el

[Yuan Fu]

> On Dec 28, 2021, at 10:13 PM, Po Lu <luangruo@yahoo.com> wrote:
> 
> Fu Yuan <casouri@gmail.com> writes:
> 
>> It shouldn’t be hard to allow users to choose a release they want to
>> stick to, no? For a starter we can have Emacs 28 when 29 releases. And
>> with each following release we can add the previous release to
>> possible fallback list.
>> 
>> Providing fall back for releases prior to 28 might not be very useful,
>> as users who want to old behavior must already have the configuration
>> written in their init file.
> 
> I expect future versions of Emacs to behave generally the same way as
> Emacs 23 or 27, so that I do not get lost trying to use it, but I don't
> want to remember how Emacs 28 (or 29, or 30, or 31) behaved so I can
> pick a version whose behaviour it should emulate, if that behaviour is
> even enumerable.

Probably only variable and faces are emulated, when possible. And I don’t understand why you need to remember anything to use such a mode: it removes changes. If anything, it should only allow you not need to remember things.

> 
> Such a compatibility layer will probably have to be constantly updated
> as well to fit with changes in later versions of Emacs.

That’s not much work, the changes to default values of variables and faces are not that much in each release. And we only need record the change in each release, reverting to defaults of prior releases only need to concatenate the change in each release together.

> The solution is simply to not change the default values of options when
> it is not due, and to change them when it is, forgoing any of the
> "compatibility layer" nonsense.

First, that solution is not very good: people have different opinions of when default values are due. Second, this “compatibility layer” is just a feature, it doesn’t change any default behavior, I don’t know why that could be bad (I assume that you think it is bad). Third, I don’t think adding this feature will make Emacs change default values when they are not due. If anything, the mode only helps people who don’t want Emacs to change: instead of adding code to .emacs, now you only need to turn this mode on.

Yuan

Re: Someone start maintaining luddites.el

[Po Lu]

Yuan Fu <casouri@gmail.com> writes:

> Probably only variable and faces are emulated, when possible. And I
> don’t understand why you need to remember anything to use such a mode:
> it removes changes. If anything, it should only allow you not need to
> remember things.

No, it means I will have to read not only NEWS but also the Antinews
after each upgrade, and then decide which version of Emacs to have mine
emulate.

>> Such a compatibility layer will probably have to be constantly updated
>> as well to fit with changes in later versions of Emacs.

> That’s not much work, the changes to default values of variables and
> faces are not that much in each release.

If my gut feeling is right, this feature will be used as an excuse to
make more of those changes.

> And we only need record the change in each release, reverting to
> defaults of prior releases only need to concatenate the change in each
> release together.

What if a variable is made obsolete in the meantime?  Or if the list of
understood meanings change?

> First, that solution is not very good: people have different opinions
> of when default values are due.

Then let's see which causes the smallest mob of people who complain.

> Third, I don’t think adding this feature will make Emacs change
> default values when they are not due. If anything, the mode only helps
> people who don’t want Emacs to change: instead of adding code to
> .emacs, now you only need to turn this mode on.

How is changing a switch with custom different in principle from adding
code to init.el?

Re: Someone start maintaining luddites.el

[Yuan Fu]

> On Dec 28, 2021, at 11:05 PM, Po Lu <luangruo@yahoo.com> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>> Probably only variable and faces are emulated, when possible. And I
>> don’t understand why you need to remember anything to use such a mode:
>> it removes changes. If anything, it should only allow you not need to
>> remember things.
> 
> No, it means I will have to read not only NEWS but also the Antinews
> after each upgrade, and then decide which version of Emacs to have mine
> emulate.

Even if you don’t read NEWS, you know what the mode does: it keeps Emacs behave the same as it currently is. So you shouldn’t need to remember or read or understand anything. And again, if you don’t like it, you don’t have to use it. So I don’t think it adds any burden to you.


>>> Such a compatibility layer will probably have to be constantly updated
>>> as well to fit with changes in later versions of Emacs.
> 
>> That’s not much work, the changes to default values of variables and
>> faces are not that much in each release.
> 
> If my gut feeling is right, this feature will be used as an excuse to
> make more of those changes.

I think the effectiveness of this mode, in terms of support of adding changes, would be equivalent to “you can add a line of code to .emacs to revert it”. Ie, not much different from the status quo. It’s just AFTER the change is made, one’s life is easier if he decides that he don’t want any of that.

>> And we only need record the change in each release, reverting to
>> defaults of prior releases only need to concatenate the change in each
>> release together.
> 
> What if a variable is made obsolete in the meantime?  Or if the list of
> understood meanings change?

If a variable is removed, we can’t help it. But if it is removed, there must be very good reason to do so and it must has been obsoleted for many years, ie, it’s due time. If it is just obsolete, resetting it shouldn’t hurt anything.


>> First, that solution is not very good: people have different opinions
>> of when default values are due.
> 
> Then let's see which causes the smallest mob of people who complain.

I don’t quite understand that. What are you referring to as “which”?

> 
>> Third, I don’t think adding this feature will make Emacs change
>> default values when they are not due. If anything, the mode only helps
>> people who don’t want Emacs to change: instead of adding code to
>> .emacs, now you only need to turn this mode on.
> 
> How is changing a switch with custom different in principle from adding
> code to init.el?

They are equivalent, but a switch is more convenient. The whole point (I think) is that it’s equivalent to adding code to init.el, but more convenient: you don’t need to figure out what code to add, you don’t need to maintain the code, you don’t need to remember what that code does and why it is added, etc.

Do you agree with my claim that adding this feature will not make Emacs change default values when they are not due?

Yuan

Re: Someone start maintaining luddites.el

[Po Lu]

Yuan Fu <casouri@gmail.com> writes:

> Even if you don’t read NEWS, you know what the mode does: it keeps
> Emacs behave the same as it currently is. So you shouldn’t need to
> remember or read or understand anything. And again, if you don’t like
> it, you don’t have to use it. So I don’t think it adds any burden to
> you.

No, I'll have to read the antinews in order to come to an intelligent
decision as to whether or not it should be enabled.

> I think the effectiveness of this mode, in terms of support of adding
> changes, would be equivalent to “you can add a line of code to .emacs
> to revert it”. Ie, not much different from the status quo. It’s just
> AFTER the change is made, one’s life is easier if he decides that he
> don’t want any of that.

That's extra trouble for everyone, and you still haven't demonstrated
why someone won't say:

  Let's set indent-tabs-mode to nil by default, people can just revert
  it by turning on luddites-mode.

Or something to that effect.

> If a variable is removed, we can’t help it. But if it is removed,
> there must be very good reason to do so and it must has been obsoleted
> for many years, ie, it’s due time. If it is just obsolete, resetting
> it shouldn’t hurt anything.

But one will have to

>> Then let's see which causes the smallest mob of people who complain.

> I don’t quite understand that. What are you referring to as “which”?

"Which one of the options that people are complaining about"

> They are equivalent, but a switch is more convenient. The whole point
> (I think) is that it’s equivalent to adding code to init.el, but more
> convenient: you don’t need to figure out what code to add, you don’t
> need to maintain the code, you don’t need to remember what that code
> does and why it is added, etc.

As I said, you will have to understand _all_ of what changed in order to
make an intelligent decision to turn it on or off, whereas without such
a feature, people can just individually revert the changes that cause
them inconvenience.

> Do you agree with my claim that adding this feature will not make
> Emacs change default values when they are not due?

I still don't, because you didn't answer my concerns there.

Re: Someone start maintaining luddites.el

[Philip Kaludercic]

Fu Yuan <casouri@gmail.com> writes:

>> 在 2021年12月28日，上午11:37，Teemu Likonen <tlikonen@iki.fi> 写道：
>> 
>> * 2021-12-28 07:32:14+0000, Colin Baxter wrote:
>> 
>>> I agree. I personally don't like having to alter my ~/.emacs just to
>>> stay the same. I think it should be the other way round - but what do
>>> I know?
>> 
>> Maybe don't ask other people (Emacs developers) to do things for you.
>> Create and maintain an Emacs package which keeps current and future
>> Emacses just like "in the old days." The package wouldn't do much, just
>> gradually add configuration options which disable everything new. I
>> wouldn't use it myself but I think some/many people would be grateful.
>> Name it luddites.el, or something.
>> 
> I think similar thing has been brought up when we were discussing
> changing defaults in new Emacs, but I don’t remember the
> conclusion. Were there any problems with it, is anyoneworking on that?

I started working on something like this a few months back, and it
should be possible.  The had part it tracking down all the changes.

> Yuan
>

-- 
	Philip Kaludercic

Re: Kill all proportional fonts!

[Ken Goldman]

On 12/28/2021 2:32 AM, Colin Baxter 😺 wrote:
> I agree. I personally don't like having to alter my ~/.emacs just to stay the
> same. I think it should be the other way round - but what do I know?

I'm not a power user, but I'll argue both ways.

1. Yes, it's annoying when I have to tweak my .emacs at every release,
and especially when I can't upgrade all my platforms at once.

2. If the default is for everything to stay the same, I might not
ever discover the new features.

Re: Someone start maintaining luddites.el

[Yuan Fu]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]



> On Dec 29, 2021, at 3:41 AM, Philip Kaludercic <philipk@posteo.net> wrote:
> 
> Fu Yuan <casouri@gmail.com> writes:
> 
>>> 在 2021年12月28日，上午11:37，Teemu Likonen <tlikonen@iki.fi> 写道：
>>> 
>>> * 2021-12-28 07:32:14+0000, Colin Baxter wrote:
>>> 
>>>> I agree. I personally don't like having to alter my ~/.emacs just to
>>>> stay the same. I think it should be the other way round - but what do
>>>> I know?
>>> 
>>> Maybe don't ask other people (Emacs developers) to do things for you.
>>> Create and maintain an Emacs package which keeps current and future
>>> Emacses just like "in the old days." The package wouldn't do much, just
>>> gradually add configuration options which disable everything new. I
>>> wouldn't use it myself but I think some/many people would be grateful.
>>> Name it luddites.el, or something.
>>> 
>> I think similar thing has been brought up when we were discussing
>> changing defaults in new Emacs, but I don’t remember the
>> conclusion. Were there any problems with it, is anyoneworking on that?
> 
> I started working on something like this a few months back, and it
> should be possible.  The had part it tracking down all the changes.

I think one only needs to go over the NEWS before each release and add changed defaults. Emacs doesn’t change default values very often, most of the change in NEWS are additions.

It’s good to hear you are working on this! Maybe my version could provide a different angle or some news ideas to you:


[-- Attachment #2: old-defaults.el --]
[-- Type: application/octet-stream, Size: 2864 bytes --]

;;; old-defaults.el --- Get off my lawn!!  -*- lexical-binding: t; -*-

;; Author: Yuan Fu <casouri@gmail.com>

;;; This file is NOT part of GNU Emacs

;;; Commentary:
;;
;; We use custom themes to implement this because 1) this way we don’t
;; reinvent the wheels and 2) we don’t need advanced features like
;; choosing what variables to not revert or only revert variables or
;; faces.

;;; Code:


(defvar old-defaults--changelog
  '((emacs-28
     :variable
     ((kill-ring-max 60 t)
      (gnus-treat-fold-headers nil))
     :face
     ((mode-line-inactive (:inherit mode-line) t "In Emacs 29.1, mode-line defaults to proportion font, this setting sets it back to monospace")
      (mode-line-active (:inherit mode-line) t "In Emacs 29.1, mode-line defaults to proportion font, this setting sets it back to monospace")
      (gnus-header (:inherit 'unspecified) t "In Emacs 29.1, gnus-header-* defaults to proportion font, this setting sets them back to monospace"))))
  "Stores old default values.
An alist of (EMACS-VERSION . SETTINGS) where EMACS-VERSION is a
symbol representing a particular version and SETTINGS is a plist
(:variable VARIABLES :face FACES). VARIABLES is a list of custom
variable forms suitable for ‘custom-theme-set-variables’ and
FACES is a list of face forms suitable for
‘custom-theme-set-faces’.

The alist should be ordered in ascending release time, i.e., the
oldest release at the front.")

(defmacro old-defaults-deftheme (version)
  "Define the theme that restores defaults to VERSION.
VERSION is a version symbol that appears in
‘old-defaults--changelog’."
  (when-let* ((theme-name (intern (format "old-defaults-%s" version)))
              (changes-needed
               (cl-loop for change in old-defaults--changelog
                        for idx = 0 then (1+ idx)
                        if (eq (car change) version)
                        return (cl-subseq old-defaults--changelog
                                          0 (1+ idx))))
              ;; CHANGES-NEEDED looks like ((emacs-28 . SETTINGS)
              ;; (emacs-29 . SETTINGS) ...).
              (var-changes-needed
               (cl-loop for change in changes-needed
                        append (plist-get (cdr change) :variable)))
              (face-changes-needed
               (cl-loop for change in changes-needed
                        append (plist-get (cdr change) :face))))
    `(progn
       (deftheme ,theme-name
         ,(format "Restore variable and face defaults to %s" version))
       (custom-theme-set-variables
        ',theme-name
        ,@var-changes-needed)
       (custom-theme-set-faces
        ',theme-name
        ,@face-changes-needed)
       (provide-theme ',theme-name))))

(provide 'old-defaults)

;;; old-defaults.el ends here

[-- Attachment #3: Type: text/plain, Size: 6 bytes --]



Yuan

Re: Someone start maintaining luddites.el

[Yuan Fu]

I think it will be good if we focus on discussing whether adding such a feature would harm Emacs, in the form of changing default values too soon. And I’ll save some typing and not reply to your concerns that I think doesn’t contribute to that topic.

> 
>> Even if you don’t read NEWS, you know what the mode does: it keeps
>> Emacs behave the same as it currently is. So you shouldn’t need to
>> remember or read or understand anything. And again, if you don’t like
>> it, you don’t have to use it. So I don’t think it adds any burden to
>> you.
> 
> No, I'll have to read the antinews in order to come to an intelligent
> decision as to whether or not it should be enabled.
> 
>> I think the effectiveness of this mode, in terms of support of adding
>> changes, would be equivalent to “you can add a line of code to .emacs
>> to revert it”. Ie, not much different from the status quo. It’s just
>> AFTER the change is made, one’s life is easier if he decides that he
>> don’t want any of that.
> 
> That's extra trouble for everyone, and you still haven't demonstrated
> why someone won't say:
> 
>  Let's set indent-tabs-mode to nil by default, people can just revert
>  it by turning on luddites-mode.
> 
> Or something to that effect.

People now says "Let's set indent-tabs-mode to nil by default, people can just revert it by adding a line in init.el”, don’t they? luddites-mode doesn’t change anything, in particular, it doesn’t make anything worse.

> 
>> If a variable is removed, we can’t help it. But if it is removed,
>> there must be very good reason to do so and it must has been obsoleted
>> for many years, ie, it’s due time. If it is just obsolete, resetting
>> it shouldn’t hurt anything.
> 
> But one will have to

Have to what?

> 
>>> Then let's see which causes the smallest mob of people who complain.
> 
>> I don’t quite understand that. What are you referring to as “which”?
> 
> "Which one of the options that people are complaining about"

I’m pointing out that there is no definitive answer to when a thing is due to change, so “change when its due” is not a good solution. Now you are saying “let people discuss and come to agreement”, that’s not the same as “change when it's due”. But I guess that’s not relavent to the current topic of “whether luddites-mode hurts Emacs”.

> 
>> They are equivalent, but a switch is more convenient. The whole point
>> (I think) is that it’s equivalent to adding code to init.el, but more
>> convenient: you don’t need to figure out what code to add, you don’t
>> need to maintain the code, you don’t need to remember what that code
>> does and why it is added, etc.
> 
> As I said, you will have to understand _all_ of what changed in order to
> make an intelligent decision to turn it on or off, whereas without such
> a feature, people can just individually revert the changes that cause
> them inconvenience.
> 

Yuan

Re: Someone start maintaining luddites.el

[Po Lu]

Yuan Fu <casouri@gmail.com> writes:

> People now says "Let's set indent-tabs-mode to nil by default, people
> can just revert it by adding a line in init.el”, don’t they?

"luddites.el" will just give people another excuse.

> Have to what?

Sorry, I replied to that statement further below.

> I’m pointing out that there is no definitive answer to when a thing is
> due to change, so “change when its due” is not a good solution. Now
> you are saying “let people discuss and come to agreement”, that’s not
> the same as “change when it's due”. But I guess that’s not relavent to
> the current topic of “whether luddites-mode hurts Emacs”.

The consensus of a discussion surrounding a change determines exactly
whether or not "it is due", I think.