[Top][All Lists]

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

Re: Gitlab Migration

From: Philip Kaludercic
Subject: Re: Gitlab Migration
Date: Fri, 03 Sep 2021 11:11:05 +0000

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 03.09.2021 10:26, Philip Kaludercic wrote:
>> Ihor Radchenko<yantar92@gmail.com>  writes:
>>> Can Emacs have "experimental" and "stable" dev branches with the former
>>> being more open to "popular" changes? Then, people who wish a more
>>> "popular" approach can use the experimental branch without disturbing
>>> more conservative users. If features in experimental branch prove their
>>> usefulness and quality, they can be moved to the stable branch.
>> In some sense this exists with prepared configurations (or
>> "distributions" as some call them). The changes they can make are not
>> exactly the same as a "experimental" branch could, but they can do a lot
>> of superficial and organisational changes.
> And as those distributions have been around for some time, we could
> look at the changes in options they made and strongly consider making
> the changes in defaults where those distributions agree, or largely
> agree.
> Those kind of arguments, however, aren't generally accepted around
> here either.

I guess because it is easy to conflate the changes they make. These
distributions and prepared configurations don't have to care about
backwards compatibility, to they are a lot more flexible to change
whatever they want. But there are different things:

* Rebinding existing commands to ...
  - different functionalities (C-x to kill)
  - stronger equivalents (M-/ to hippie-expand)
  - slightly different but more intuitive commands (M-z to zap-up-to-char)
* Binding commands to new keys (C-x p for project.el)
* Providing more or different packages by-default (various major modes
  not available in ELPA, use-package, ...)
* Enabling options by default ...
  - that might have been considered to intensive in the past
    (show-paren-mode, decreasing lazy-highlight-initial-delay, ...)
  - that change the default behaviour by trying to be intuitive (electric
* Changing the default UI to ...
  - match modern design trends (adding blank space, adding those
    little triangles to the mode line, ...)
  - improve readability (changing the default theme, using more
    variable-width faces in the UI)

And I am sure there are more, but the point is that there are different
discussions and motivations behind these changes. Emacs is currently in
the weird position where it is already different but doesn't want to
confuse new users even more by disabling some commands by default
(upcase-region, narrow-to-region) or offer more power by default
(searching using regular expressions by default).

        Philip Kaludercic

reply via email to

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