Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

["T.V Raman" <raman@google.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 3331 bytes --]

The discussion around how to bring in new users etc is healthy as long
as it moves the ball forward.

Experience tells us that there are multiple directions in which we can
move,  some that will bear fruit, some that will wither and go away.

But independent of which of those branches/offshoots survive, making the
underlying platform, AKA Emacs' extension/configuration layer more
robust and flexible  is work that will stand us in good stead over the
long term.

From that perspective, I hope we can put some energy into making the
underlying M-x custom more robust --- see below for what I mean:

20+ years ago, M-x custom came to Emacs, initially disliked by all those
of us who prefered writing elisp in our init files. Over time though it
has definitely landed well and made Emacs easier to configure --- to the
extent that even  folks who are happy to write elisp by hand in their
setup use it to varying degrees.

that's the good half of Custom.

Custom however is also showing its age, here are some personal opinions
about its shortcomings:

A. It has the disadvantage of dumping all settings into a single file,
   feels like the Windows Registry and can be fragile.

   B. Tends to accumulate cruft, eg customizations for packages that
      dont exist linger in the customization file

      C. Custom scares you  away from touching its setup --- especially
         "the only one of these forms  can appear" bit that forces all
         settings into a single file.

         D. I think custom themes are a great idea but it feels like it
            was "started but never finished".

            E. A dual to custom is use-package that has the virtue of
               isolating package-specific setup to a package-specific
               form in your setup, so you stop using the package and
               there is no cruft left behind (except ... that custom can
               still grab some of those  settings  and dump it into your
               custom file).

               So while we debate the pros/cons of various features, it
               might be a good investment of  time to  rethink and
               evolve custom to become more robust along various axies,
               since any user-friendly layers of
               preferences/customizations we would add could all use the
               underlying infrastructure to advantage.
Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07.09.2020 21:08, Ergus wrote:
>
>>> - undo-tree-mode
>> Undo tree had some problems in the past. But if you want the basic
>> undo/redo behavior there is something already in vanilla (as usual a bit
>> hidden):
>> (global-set-key [remap undo] 'undo-only)
>> (global-set-key (kbd "C-M-_") 'undo-redo)
>> which I discovered after asking here and fighting with undo tree for
>> almost a year.
>
> Good point.
>
> undo-tree has been stable for me lately, but it might be overkill for
> a lot of users, and the default undo behavior is... exotic.
>
> So I think ideally we'd switch to the above key mappings by
> default. But since this is going to be a hard sell, at least this
> option should be better documented/advertised, maybe even on the new
> splash screen people have imagined/mentioned.
>

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8