Changes for emacs 28

Changes for emacs 28

[Ergus]

Hi Emacs:

As 27 has just been released I think it is time to start considering
changes for the release 28. I will add some points I think we could
discuss (specially implying defaults) in order to hear opinions and have
enough time to discuss/implement them.

PLEASE: this are just proposals and every time we talk about defaults we
never get a conclusion or agreement. So I would appreciate if at the end,
one of the main developers (Eli, Stefan, etc) give a final opinion in
favor/opposing/reforming the change and that will close the discussion
(please).

Of course anyone can add extra points these are just the ones I remember
so far.

This are mainly "visible" changes that will benefit new users and first
impression because I don't understand why we hide the best
functionalities until the user learns how to configure them (and some
lisp).

1) Improve the default theme: Maybe set a default dark theme to make
emacs feel more modern. Experienced users usually already have a custom
theme, so they won't be affected. There is actually some statistics
about downloades themes here:

https://emacsthemes.com/popular/index.html

So we can use that to choose or design the theme.

2) Improve the completion buffer behavior: Actually I have a proposal
feature branch for this to make the experience more like zsh; but of
course that is just one option. Most experienced users use IDO, ivy or
helm, icompletes so they won't be affected.

3) Substitute list-buffers with ibuffer: This is actually in the TODO
but for interactive users ibuffer offers a bit more modern
experience. So the proposition is just to set ibuffer to the default
bindings as so far it already offers all the list-buffers'
functionalities.

4) Enable display-line-numbers-mode by default. Almost all editors
around have line numbers by default why we hide them?

5) Enable winmove and mouse-wheel-mode by default.

I think all these are very conservative changes (specially considering
that we have 2-3 years before enabling them)

WDYT??

Re: Changes for emacs 28

[Alfred M. Szmidt]

   1) Improve the default theme: Maybe set a default dark theme to make
   emacs feel more modern. Experienced users usually already have a custom
   theme, so they won't be affected. There is actually some statistics
   about downloades themes here:

This would be an utterly disastrous change.  As an experienced user, I
do not have a custom theme, and prefer to use the defaults of Emacs.

   4) Enable display-line-numbers-mode by default. Almost all editors
   around have line numbers by default why we hide them?

Just no.  Just because everyone does it, doesn't mean that it is a
good default.  In the majority of cases, there is no need to see the
line number -- for example, like when writting an email.

   5) Enable winmove and mouse-wheel-mode by default.

What is winmove?  

   I think all these are very conservative changes (specially considering
   that we have 2-3 years before enabling them)

They are absolutley not conservative changes. 

Re: Changes for emacs 28

[Elias Mårtenson]

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

On Sun, 6 Sep 2020 at 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:

>    1) Improve the default theme: Maybe set a default dark theme to make
>    emacs feel more modern. Experienced users usually already have a custom
>    theme, so they won't be affected. There is actually some statistics
>    about downloades themes here:
>
> This would be an utterly disastrous change.  As an experienced user, I
> do not have a custom theme, and prefer to use the defaults of Emacs.
>

Same for me, and I'm pretty sure we're not alone.

Also, while dark background is popular right now, it's not necessarily
better. Apart from the fact that there is actual science showing that dark
backgrounds are worse for one's eyes, I believe the current trend is merely
the pendulum is swinging back.

Recall that backgrounds used to be dark back in the terminal era. Then
monitors became better and white background was finally usable. Now, people
who only ever have experienced white backgrounds wants to change things for
the sake of change, so that is now popular, even though it's actually
quantifiably worse.

This Wired article on the topic contains links to actual research on this:
https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1773 bytes --]

Re: Changes for emacs 28

[Óscar Fuentes]

Elias Mårtenson <lokedhs@gmail.com> writes:

> This Wired article on the topic contains links to actual research on this:
> https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science

Actually, the article links just one study about the specific topic of
dark/light modes. And it is behind a paywall.

The rest of the article is fluff, starting with assuming that "dark
mode" means "white text on black background", following with the
mentions of eye dryness, blink frequency and other issues unrelated to
dark mode and, the cake, hinting that dark modes might be bad because
people are more confortable with them and thus spend more time on front
of the screen.

Re: Changes for emacs 28

[Ergus]

Hi Elias:

Your link is basically a set of personal opinions with not concise
arguments at all against the "popular" keys that support dark mode use.

They refer to only 1 study; for the eye stress; they suggest to work
less in light screen mode while they present the comfortableness of dark
mode as an addiction problem.

So when you say "quantifiably worse" I hope you refer to something
else. OTOH there are also other "studies" blaming emacs for carpal
tunnel syndrome and even some posts of special keyboards only for
emacs... so not all "studies" are serious.

There actually are serious market studies, company studies, application
studies, ergonomic studies supporting dark mode. But also in the link I
shared there are the statistics of downloaded emacs themes; the
popularity experience of spacemacs or doom-emacs and also other editors
(atom, sublime, VSCode, Android Studio, the new Arduino IDE). Is
everybody wrong? 

I won't insist on this because in my experience this doesn't go
anywhere. But when I talked about theme I made in the general way
(font-lock, terminal, bars); because even vim has "better" default
colors. Dark thing was just one part of this.
  

On Sun, Sep 06, 2020 at 11:00:39PM +0800, Elias M?rtenson wrote:
>On Sun, 6 Sep 2020 at 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:
>
>>    1) Improve the default theme: Maybe set a default dark theme to make
>>    emacs feel more modern. Experienced users usually already have a custom
>>    theme, so they won't be affected. There is actually some statistics
>>    about downloades themes here:
>>
>> This would be an utterly disastrous change.  As an experienced user, I
>> do not have a custom theme, and prefer to use the defaults of Emacs.
>>
>
>Same for me, and I'm pretty sure we're not alone.
>
>Also, while dark background is popular right now, it's not necessarily
>better. Apart from the fact that there is actual science showing that dark
>backgrounds are worse for one's eyes, I believe the current trend is merely
>the pendulum is swinging back.
>
>Recall that backgrounds used to be dark back in the terminal era. Then
>monitors became better and white background was finally usable. Now, people
>who only ever have experienced white backgrounds wants to change things for
>the sake of change, so that is now popular, even though it's actually
>quantifiably worse.
>
>This Wired article on the topic contains links to actual research on this:
>https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science
>
>Regards,
>Elias

Re: Changes for emacs 28

[Alfred M. Szmidt]

   There actually are serious market studies, company studies, application
   studies, ergonomic studies supporting dark mode. But also in the link I
   shared there are the statistics of downloaded emacs themes; 

Those are statistics for how many times something was downloaded --
not the preference over one or the other...

   the popularity experience of spacemacs or doom-emacs and also other
   editors (atom, sublime, VSCode, Android Studio, the new Arduino
   IDE). Is everybody wrong?

Both sides can have a good reason to pick one default over the other.
There are plenty of editors that have a preference of a black-on-white
background too. 

Re: Changes for emacs 28

[Dmitry Gutov]

On 06.09.2020 20:07, Ergus wrote:
> Your link is basically a set of personal opinions with not concise
> arguments at all against the "popular" keys that support dark mode use.

Here's a more serious overview of related research: 
https://ux.stackexchange.com/a/53268/136203

Spoiler alert: light mode wins.

Re: Changes for emacs 28

[chad]

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

On Sun, Sep 6, 2020 at 11:33 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 06.09.2020 20:07, Ergus wrote:
> > Your link is basically a set of personal opinions with not concise
> > arguments at all against the "popular" keys that support dark mode use.
>
> Here's a more serious overview of related research:
> https://ux.stackexchange.com/a/53268/136203
>
> Spoiler alert: light mode wins.
>


It's been a while since I dove into the research around this, but from this
thread it seems to still be the case that context makes a large, in many
cases overriding difference. From that link:

For applications which provide long-form reading (books, articles, even
> news sites), dark mode options are recommended.


Many of those studies are concerned about visual acuity in very short-term
tasks -- correctly reading text that appears and disappears quickly, such
as alerts or notifications. It also notes that matching the background to
the environment (light in bright rooms, etc.) is key for sustained reading.

There's more research these days on glancing at small, very-hi-res screens,
which is nice (and unsurprising), but probably isn't all that helpful for
typical Emacs use (if there is such a thing as "typical" Emacs use). This
doesn't seem to be the sort of issue that's going to be resolved with a
clear "objectively better in most cases" argument, and Emacs has very
clearly declared (for decades) its conservatism towards UI changes, so
we're probably better off not painting this particular bikeshed.

That's my opinion, at least. I do think Emacs' new user experience could be
improved by adding some options/actions on display-splash-screen, though,
and I'd be happy to help with that.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 2658 bytes --]

Re: Changes for emacs 28

[Dmitry Gutov]

On 07.09.2020 05:17, chad wrote:

> It's been a while since I dove into the research around this, but from 
> this thread it seems to still be the case that context makes a large, in 
> many cases overriding difference. From that link:
> 
>     For applications which provide long-form reading (books, articles,
>     even news sites), dark mode options are recommended. 

Maybe. But it's a quote from just one of the references articles.

> It also notes that matching 
> the background to the environment (light in bright rooms, etc.) is key 
> for sustained reading.

This is key. And you won't find many offices which match dark-background 
color themes, would you?

I'm not exactly against dark themes, and I use them on the phone for 
certain apps, but it's so much better when on my laptop the editor 
matches the rest of the programs, and the room around it as well.

> That's my opinion, at least. I do think Emacs' new user experience could 
> be improved by adding some options/actions on display-splash-screen, 
> though, and I'd be happy to help with that.

Sure. I'm all for that.

And it's not too long ago that we've had a similar, much longer thread 
on the same topic where a lot of us expressed the same sentiment.

Re: Changes for emacs 28

[Tim Van den Langenbergh]

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

Personal preference for a theme should have little if any impact on
Emacs defaults, as (at least on my OpenSUSE KDE desktop) Emacs
is a proper citizen and follows my global theme.
The only thing that doesn't follow and which I like to use a custom
theme for is the modeline.

On Sunday, 6 September 2020 17:00:39 CEST Elias Mårtenson wrote:
> On Sun, 6 Sep 2020 at 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:
> 
> >    1) Improve the default theme: Maybe set a default dark theme to make
> >    emacs feel more modern. Experienced users usually already have a custom
> >    theme, so they won't be affected. There is actually some statistics
> >    about downloades themes here:
> >
> > This would be an utterly disastrous change.  As an experienced user, I
> > do not have a custom theme, and prefer to use the defaults of Emacs.
> >
> 
> Same for me, and I'm pretty sure we're not alone.
> 
> Also, while dark background is popular right now, it's not necessarily
> better. Apart from the fact that there is actual science showing that dark
> backgrounds are worse for one's eyes, I believe the current trend is merely
> the pendulum is swinging back.
> 
> Recall that backgrounds used to be dark back in the terminal era. Then
> monitors became better and white background was finally usable. Now, people
> who only ever have experienced white backgrounds wants to change things for
> the sake of change, so that is now popular, even though it's actually
> quantifiably worse.
> 
> This Wired article on the topic contains links to actual research on this:
> https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science
> 
> Regards,
> Elias
> 


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Changes for emacs 28

[Ergus]

On September 9, 2020 8:35:18 PM GMT+02:00, Tim Van den Langenbergh <tmt_vdl@gmx.com> wrote:
>Personal preference for a theme should have little if any impact on
>Emacs defaults, as (at least on my OpenSUSE KDE desktop) Emacs
>is a proper citizen and follows my global theme.
>The only thing that doesn't follow and which I like to use a custom
>theme for is the modeline.
>
Yes, I actually didn't mention the mode line before because with the profile solution that could be also solved... And we can create several alternatives.

>On Sunday, 6 September 2020 17:00:39 CEST Elias Mårtenson wrote:
>> On Sun, 6 Sep 2020 at 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:
>> 
>> >    1) Improve the default theme: Maybe set a default dark theme to
>make
>> >    emacs feel more modern. Experienced users usually already have a
>custom
>> >    theme, so they won't be affected. There is actually some
>statistics
>> >    about downloades themes here:
>> >
>> > This would be an utterly disastrous change.  As an experienced
>user, I
>> > do not have a custom theme, and prefer to use the defaults of
>Emacs.
>> >
>> 
>> Same for me, and I'm pretty sure we're not alone.
>> 
>> Also, while dark background is popular right now, it's not
>necessarily
>> better. Apart from the fact that there is actual science showing that
>dark
>> backgrounds are worse for one's eyes, I believe the current trend is
>merely
>> the pendulum is swinging back.
>> 
>> Recall that backgrounds used to be dark back in the terminal era.
>Then
>> monitors became better and white background was finally usable. Now,
>people
>> who only ever have experienced white backgrounds wants to change
>things for
>> the sake of change, so that is now popular, even though it's actually
>> quantifiably worse.
>> 
>> This Wired article on the topic contains links to actual research on
>this:
>> https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science
>> 
>> Regards,
>> Elias
>> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Changes for emacs 28

[Andrea Corallo via Emacs development discussions.]

IMO our ultimate goal should be bringing more people into Emacs, GNU, and
Free Software.  As many as we can I'd say.

I fear pleasing ourselves with a nostalgic toy may not be most effective
strategy there.

Thanks Ergus, FWIW I support your points.

  Andrea

Re: Changes for emacs 28

[Ergus]

There will be never an agreement about changing defaults with long
standing users. (I can't understand the strong feeling about that
because some/most of the choices we have today were actually determined
by historic/technological conditions more than user preferences)

So what if:

Could we provide a simple command line option like "emacs -m" (or any
letter not in use) which automatically loads a set of extra
"experimental" defaults not suitable for older users?? (the same as
emacs -l modern.el but shorter) Like a different theme, line numbers,
show-paren mode, and any other "modern" feature a newbie expects in a
2020 editor?

We can also provide a .desktop only for it and equivalents to make it
easier to find for new users. And recommend the users to add an alias if
they like to set it as default? and add a note in the welcome screen.

Is this also too crazy?

Probably this features will be trivial for us, but not for anyone
opening emacs for the first time. I am just talking about enabling some
features we already have in vanilla, but they are "hidden"; this is not
doing a complex configs or so.

Alternatively the user will have a copy of this file ready to copy in
his home and personalize as he prefers. So he will have something
"official" to start with; instead of coping random potentially
outdated/problematic configs from internet.

Does this makes sense?

On Sun, Sep 06, 2020 at 08:49:25PM +0000, Andrea Corallo via Emacs development discussions. wrote:
>IMO our ultimate goal should be bringing more people into Emacs, GNU, and
>Free Software.  As many as we can I'd say.
>
>I fear pleasing ourselves with a nostalgic toy may not be most effective
>strategy there.
>
>Thanks Ergus, FWIW I support your points.
>
>  Andrea
>

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Mon, 7 Sep 2020 00:20:08 +0200
> From: Ergus <spacibba@aol.com>
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, emacs-devel@gnu.org
> 
> So what if:
> 
> Could we provide a simple command line option like "emacs -m" (or any
> letter not in use) which automatically loads a set of extra
> "experimental" defaults not suitable for older users?? (the same as
> emacs -l modern.el but shorter) Like a different theme, line numbers,
> show-paren mode, and any other "modern" feature a newbie expects in a
> 2020 editor?
> 
> We can also provide a .desktop only for it and equivalents to make it
> easier to find for new users. And recommend the users to add an alias if
> they like to set it as default? and add a note in the welcome screen.
> 
> Is this also too crazy?
> 
> Probably this features will be trivial for us, but not for anyone
> opening emacs for the first time. I am just talking about enabling some
> features we already have in vanilla, but they are "hidden"; this is not
> doing a complex configs or so.
> 
> Alternatively the user will have a copy of this file ready to copy in
> his home and personalize as he prefers. So he will have something
> "official" to start with; instead of coping random potentially
> outdated/problematic configs from internet.
> 
> Does this makes sense?

Yes.

This was proposed in the past.   Someone will have to figure out what
features should this turn on.  AFAIR, no one has come with a coherent
suggestion yet.

Re: Changes for emacs 28

[Alfred M. Szmidt]

   There will be never an agreement about changing defaults with long
   standing users. (I can't understand the strong feeling about that
   because some/most of the choices we have today were actually determined
   by historic/technological conditions more than user preferences)

You are mixing up several different changes, which makes it difficult
to explain why sometimes.  Please take it one default at a time.

   Could we provide a simple command line option like "emacs -m" (or any
   letter not in use) which automatically loads a set of extra
   "experimental" defaults not suitable for older users??

If that mode is significantly different (e.g, CUA mode) from
"standard" emacs then it will be difficult to point users to the
documentation, or that the documentation will have to have many
caveats.

   (the same as emacs -l modern.el but shorter) Like a different
   theme, line numbers, show-paren mode, and any other "modern"
   feature a newbie expects in a 2020 editor?

Why are the things you suggest not suitable for experienced users, but
suitable for new users?  You do not explain why, and you come up with
more suggestions in each new message.  Before enabling, or disabling a
feature one should have a reason to do so.

I do not think that new users expect any of those things you have
listed (show-paren-mode, display-line-numbers-mode or a different
theme); from my experience when teaching new users they want just get
stuff done.  The first thing they tend to miss in my experience is
getting navigation setup, or auto-completion since many editors come
with that out of the box.

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Would people please split this discussion into a separate
thread for each proposal?  That would make it easier for each
person to focus on the issues that interest per.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Andrea Corallo via Emacs development discussions.]

Ergus <spacibba@aol.com> writes:

[...]
> So what if:
>
> Could we provide a simple command line option like "emacs -m" (or any
> letter not in use) which automatically loads a set of extra
> "experimental" defaults not suitable for older users?? (the same as
> emacs -l modern.el but shorter) Like a different theme, line numbers,
> show-paren mode, and any other "modern" feature a newbie expects in a
> 2020 editor?
>
> We can also provide a .desktop only for it and equivalents to make it
> easier to find for new users. And recommend the users to add an alias if
> they like to set it as default? and add a note in the welcome screen.
>
> Is this also too crazy?

It is probably the only viable option, even if sub-optimal will be
certainly better than nothing.

Unfortunately many people evaluate this default changes in terms of how
many lines their .emacs is going to be afterwards.  This is a totally
broken metric as the only goal should be easing new users to get
onboard.

  Andrea

Re: Changes for emacs 28

[tomas]

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

On Mon, Sep 07, 2020 at 12:20:08AM +0200, Ergus wrote:
> There will be never an agreement about changing defaults with long
> standing users.

So we use your preferences?

>(I can't understand the strong feeling about that
> because some/most of the choices we have today were actually determined
> by historic/technological conditions more than user preferences)

And yours are better than other's ;-P

Sorry for being a bit sarcastic. It's not with the intention to hurt:
I know you're well-intentioned, but if you think about it, discussions
about defaults are bound to end like this, at least in a community as
diverse as Emacs's is (show me another piece of software which is (a)
user-oriented and (b) alive for over 30 years).

There are several reactions to this (recurring) "Hey, let's change the
world, because, you know, Emacs is Old (TM)". You now have seen a couple
of them. Most old folks who are happy with how things work now just
sigh and say "well, as long as I can disable it -- go ahead". This,
of course, ignores that there's a price to pay: fragmented experience.
Of course, with a highly customizable thing as Emacs is, there'll
always be some of that, but it costs something (like asking for help
on copy-paste and getting blank stares, or being told to do C-v (is
this on Apple/Microsoft-themed Ergus-Emacs, where it means "paste",
or in "Classic", where it means "scroll down"?.

It's clear that one has to pay part of that price. But how much? That
can only be found by trying to find a consensus, since it is a collective
price to pay.

So please: as important as those ideas are, consider those points:

1. there are people perfectly happy with the current defaults.
  And they are happy for a reason -- sometimes for a *good*
  reason. Just assumeng that they are "resistant to change"
  can feel insulting.

2. "anyone can coustomize its own Platonic cave" is a solution
  just up to a certain point. Finding this equilibrium (which
  tends to shift over time) is something a long-lived project
  has to do (and is doing) anyway all of the time.

So your best way forward is, as someone else (I think it was Eli)
proposed in this thread is to discuss each potential default change
separately.

Alternatively, you could offer your new "world vision" as an ELPA
package for people to try out: no need to wait for the next version.

Then, as a more radical approach, you might try to fork Emacs.
This sounds harsh, but a friendly fork can be enriching, too.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Elias Mårtenson]

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

On Mon, 7 Sep 2020, 15:38 , <tomas@tuxteam.de> wrote:

>
> I know you're well-intentioned, but if you think about it, discussions
> about defaults are bound to end like this, at least in a community as
> diverse as Emacs's is (show me another piece of software which is (a)
> user-oriented and (b) alive for over 30 years).
>

Maxima. Over 50 years at this point, and counting.

And yes, it has the same concerns as Emacs in many areas. Remarkably
similar in fact.

Regards,
Elias

>

[-- Attachment #2: Type: text/html, Size: 1105 bytes --]

Re: Changes for emacs 28

[tomas]

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

On Tue, Sep 08, 2020 at 08:50:25AM +0800, Elias Mårtenson wrote:
> On Mon, 7 Sep 2020, 15:38 , <tomas@tuxteam.de> wrote:
> 
> >
> > I know you're well-intentioned, but if you think about it, discussions
> > about defaults are bound to end like this, at least in a community as
> > diverse as Emacs's is (show me another piece of software which is (a)
> > user-oriented and (b) alive for over 30 years).
> >
> 
> Maxima. Over 50 years at this point, and counting.

Yes. Thanks for that :-)

> And yes, it has the same concerns as Emacs in many areas. Remarkably
> similar in fact.

I see. I'd like there to be a way to have such discussions in a
fashion that is constructive: on the one side, the enthusiasm of
people arriving and saying "hey, let's change the world!" is very
valuable, and it's always sad to see it chilled, on the other side
the experience lurking in the old and seasoned corpus (an more
than that: the community) is as valuable.

I'd like to see such exchanges with no hurt feelings. On the contrary,
they should be enjoyable for all parties alike.

Is that the philosopher's stone? Or am I becoming senile?

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Bastien]

Hi Andrea,

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> IMO our ultimate goal should be bringing more people into Emacs, GNU, and
> Free Software.  As many as we can I'd say.

You also need to keep a good balance between maintainers, contributors
and users--one that allows users to exert their famous freedom through
software that is both free and well maintained.

> I fear pleasing ourselves with a nostalgic toy may not be most effective
> strategy there.

As Eli said, nobody here is paid for working on Emacs, so if there is
a good idea out there (and Stefan's concept of profiles looks good to
me) then you need to work on it or to convince someone else to do so.

2 cents,

-- 
 Bastien

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sun, 6 Sep 2020 15:37:19 +0200
> From: Ergus <spacibba@aol.com>
> 
> As 27 has just been released I think it is time to start considering
> changes for the release 28.

We don't normally "consider changes for the next release", we just
wait until there're enough new features and/or enough time since the
previous major release, and go with what we have at that point.  Since
we are not a company with hierarchy and management, we have no real
way of telling someone what to do and when.

So I suggest a separate discussion for each feature/change you'd like
to see happening.  Then whatever decision we will make about each one,
will be in Emacs 28.

Thanks.

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 05:44:40PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 6 Sep 2020 15:37:19 +0200
>> From: Ergus <spacibba@aol.com>
>>
>> As 27 has just been released I think it is time to start considering
>> changes for the release 28.
>
>We don't normally "consider changes for the next release", we just
>wait until there're enough new features and/or enough time since the
>previous major release, and go with what we have at that point.  Since
>we are not a company with hierarchy and management, we have no real
>way of telling someone what to do and when.
>
>So I suggest a separate discussion for each feature/change you'd like
>to see happening.  Then whatever decision we will make about each one,
>will be in Emacs 28.
>
>Thanks.

Hi Eli:

I just mentioned some default changes that will not require almost any
extra implementation and functionalities that have already been there
for many years. I am just thinking in the first impression for new
users...

The reaction has been as expected but I needed to mention them just to
see which ones could or couldn't be at least considered. So I don't
waste time with the others.

Sorry but I can't understand why "old" users, that can write lisp lines
easily to their configs, can't understand that for new users (and
younger ones) those lines sometimes takes hours or days (mainly because
they don't know what/where/how to look for, and lisp is not so
popular or familiar these days). And that the first impression when they
open emacs is like going back to 1998. 

I know that ideally the users should read the documentation, learn lisp,
pass the tutorial and so on... but in real live if the first impression
is not good we just scare away them before they discover the power of
emacs. Mainly because there are many alternatives easier to start with.

It is just my opinion.
I won't insist on this anymore.

Best,
Ergus.

Re: Changes for emacs 28

[Yuan Fu]

> 
> I just mentioned some default changes that will not require almost any
> extra implementation and functionalities that have already been there
> for many years. I am just thinking in the first impression for new
> users...
> 
> The reaction has been as expected but I needed to mention them just to
> see which ones could or couldn't be at least considered. So I don't
> waste time with the others.
> 
> Sorry but I can't understand why "old" users, that can write lisp lines
> easily to their configs, can't understand that for new users (and
> younger ones) those lines sometimes takes hours or days (mainly because
> they don't know what/where/how to look for, and lisp is not so
> popular or familiar these days). And that the first impression when they
> open emacs is like going back to 1998. 
> I know that ideally the users should read the documentation, learn lisp,
> pass the tutorial and so on... but in real live if the first impression
> is not good we just scare away them before they discover the power of
> emacs. Mainly because there are many alternatives easier to start with.
> 
> It is just my opinion.
> I won't insist on this anymore.
> 
> Best,
> Ergus.
> 

AFAICT, those changes wouldn’t have enough support (if any) here. Instead, what about compiling a separate Emacs that has all these “good modern features/options” enabled? We can even go further and compile a shiny and truly out-of-the-box Emacs. The problem is, of course, people with the skill don’t care about this, and people need/want this don’t have the skill.

Yuan

Re: Changes for emacs 28

[Alfred M. Szmidt]

   Sorry but I can't understand why "old" users, that can write lisp lines
   easily to their configs, can't understand that for new users (and
   younger ones) those lines sometimes takes hours or days (mainly because
   they don't know what/where/how to look for, and lisp is not so
   popular or familiar these days). And that the first impression when they
   open emacs is like going back to 1998. 

I think you need to make a stronger case as to why a user would spend,
from day one, several hours or days to configure Emacs to be able to
use it -- such an story would be very interesting to read to learn and
understand what could be improved.  The list you suggested would
barley have any impact on the experience of new users, but would have
a large impact on people who have been using emacs for a long time.

We can turn the argument around as well, as users become more
experienced they will add more of the "experienced" defaults to their
configuration files -- making it a general waste of time trying to
find those good defaults for experienced users, having to possibly
reinvent the wheel over and over again.

What new users will want is more or less from my experience the same
as what experienced users expect to see, to open and edit files, have
navigation or auto-popup-completion -- both which I think would be
nice to see as standard for common modes (not just programming, and
working as well as emacs-lisp-mode and eldoc-mode).  They will
probobly want to have some sort of WYSIWYG feature for writting notes.

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 03:32:02PM -0400, Alfred M. Szmidt wrote:
>   Sorry but I can't understand why "old" users, that can write lisp lines
>   easily to their configs, can't understand that for new users (and
>   younger ones) those lines sometimes takes hours or days (mainly because
>   they don't know what/where/how to look for, and lisp is not so
>   popular or familiar these days). And that the first impression when they
>   open emacs is like going back to 1998.
>
>I think you need to make a stronger case as to why a user would spend,
>from day one, several hours or days to configure Emacs to be able to
>use it -- such an story would be very interesting to read to learn and
>understand what could be improved.  The list you suggested would
>barley have any impact on the experience of new users, but would have
>a large impact on people who have been using emacs for a long time.
>
Suppose that you come from a world more or less standard where you copy
with C-c paste with C-v cut with C-x undo with C-z and redo with C-S-z
or C-r; you also save with C-s and search with C-f.

In this same world you get that tabs insert tabs, complete with C-RET,
you search for all the documentation in internet not in the same
application and if you don't like the colors, the indentation, the
bindings or want to add line numbers or use a different font you go to
Preferences and it is done with 2 clicks.

In this same world there is an application's store you find in the bar
"install extension" or even a panel comes suggesting you what to
install. If you don't know how to do common operations you right click
on text and you get a panel with plenty of common options like copy
paste highlight all like this, replace, compile and so on.

I am NOT telling we should do all this, but this is what a young user
expects because all these is more or less standard everywhere else. To
anyone coming from that world it takes learning time to understand or
get used to ALL the changes, the Lisp parenthesis, the M-x, the new
names, get a smarter completion for it's use case, learn the common
bindings, debugging his config usually a copy-paste from somewhere
random on internet..

>We can turn the argument around as well, as users become more
>experienced they will add more of the "experienced" defaults to their
>configuration files -- making it a general waste of time trying to
>find those good defaults for experienced users, having to possibly
>reinvent the wheel over and over again.
>
They don't become experienced if they don't enter long enough and go for
any other alternative because is simpler, prettier, or just works out of
the box. 

>What new users will want is more or less from my experience the same
>as what experienced users expect to see, to open and edit files, have
>navigation or auto-popup-completion -- both which I think would be
>nice to see as standard for common modes (not just programming, and
>working as well as emacs-lisp-mode and eldoc-mode).  They will
>probobly want to have some sort of WYSIWYG feature for writting notes.
>
Go for Atom, VSCode, Sublime Text and see what the users wants
there. There are very active forums and plenty of packages because these
editors has 10 times more users than emacs with just 2 or 3 years of
existence.

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

Ergus:
>
> There actually are serious market studies, company studies, application 
> studies, ergonomic studies supporting dark mode.
>

I'd like to see some of these studies.  "Dark mode" goes against what so 
many people have been doing for centuries (think of books for example) 
that I'm really curious to see why they were wrong.

>
> They don't become experienced if they don't enter long enough and go for 
> any other alternative because is simpler, prettier, or just works out of 
> the box.
>

Each software has its audience.  Some are targeted at advanced users, 
others at a more general audience.  Word processors work out of the box 
with all the nice features you describe, yet LaTeX is still there (and was 
already there before all of them existed).  Visual Basic and <name your 
favorite next-generation programming language here> each have some of the 
features you describe, yet C is still there (and was there before they 
existed).  And so forth.

>
> Go for Atom, VSCode, Sublime Text and see what the users wants there. 
> There are very active forums and plenty of packages because these 
> editors has 10 times more users than emacs with just 2 or 3 years of 
> existence.
>

Yet Emacs is one of the oldest computer programs still in use.  And not 
all its users are 60-year old people.

Re: Changes for emacs 28

[Ricardo Wurmus]

Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> writes:

> Ergus:
>>
>> There actually are serious market studies, company studies,
>> application studies, ergonomic studies supporting dark mode.
>>
>
> I'd like to see some of these studies.  "Dark mode" goes against what
> so many people have been doing for centuries (think of books for
> example) that I'm really curious to see why they were wrong.

https://www.nature.com/articles/s41598-018-28904-x

  “We found that reading dark text on bright background reduces
choroidal thickness in one hour, while reading bright text on dark
background increases the thickness of the choroid. Since choroidal
thickness changes are precursors for future changes in eye growth, we
expect that there will be selective effects on subsequent myopia
development.”

-- 
Ricardo

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
>> I'd like to see some of these studies.  "Dark mode" goes against what 
>> so many people have been doing for centuries (think of books for 
>> example) that I'm really curious to see why they were wrong.
>
> https://www.nature.com/articles/s41598-018-28904-x
>
>  “We found that reading dark text on bright background reduces choroidal 
> thickness in one hour, while reading bright text on dark background 
> increases the thickness of the choroid. Since choroidal thickness 
> changes are precursors for future changes in eye growth, we expect that 
> there will be selective effects on subsequent myopia development.”
>

Okay, so according to these authors, in essence "light mode" might perhaps 
in the long term lead to more myopia.  There is no causal relation, they 
only "expect" something, and their expectation might very well be what is 
known as a "cum hoc ergo propter hoc" fallacy.  In short, that's already 
an interesting indication, but I'll wait to see (much) more studies like 
this before being convinced.

Re: Changes for emacs 28

[Ricardo Wurmus]

Gregory Heytings <ghe@sdf.org> writes:

>>> I'd like to see some of these studies.  "Dark mode" goes against
>>> what so many people have been doing for centuries (think of books
>>> for example) that I'm really curious to see why they were wrong.
>>
>> https://www.nature.com/articles/s41598-018-28904-x
>>
>>  “We found that reading dark text on bright background reduces
>> choroidal thickness in one hour, while reading bright text on dark
>> background increases the thickness of the choroid. Since choroidal
>> thickness changes are precursors for future changes in eye growth,
>> we expect that there will be selective effects on subsequent myopia
>> development.”
>>
>
> Okay, so according to these authors, in essence "light mode" might
> perhaps in the long term lead to more myopia.

No, the choroid became significantly thicker after *one* hour of reading
white text on black, and significantly thinner after *one* hour of
reading black text on white.  Choroid thickness is known to be a
significant factor in myopia.

The open questions include a description of the exact mechanism leading
to this observable effect and identification of whether it is (lack or
presence of) ON or OFF stimulation that has the effect.  The effect
itself is not in question.

> In short, that's already an interesting indication, but I'll wait to
> see (much) more studies like this before being convinced.

That’s fine.  I don’t think the topic is black and white (hah) anyway,
so I don’t aim to convince or be convinced myself.  There are simply
different metrics on which light and dark mode score differently well or
poorly, so I don’t expect there to be a clear winner either way.  It’s a
value judgement and finding a personal compromise, weighing eye strain,
readability, short-term and long-term changes to the eyes, etc.

We shouldn’t pretend that there’s one best way for everyone.  The most
eye-saving way forward is clearly not to read at all, but we don’t
recommend using emacspeak instead of displaying text — though in all
seriousness, perhaps there should be a simple accessibility menu to
enable or disable emacspeak, to select dark or light mode, to set the
text contrast (similar to how the solarized theme grades colours on an
adjustable contrast curve), etc.

-- 
Ricardo

Re: Changes for emacs 28

[Joost Kremers]

On Mon, Sep 07 2020, Ricardo Wurmus wrote:
> No, the choroid became significantly thicker after *one* hour of 
> reading
> white text on black, and significantly thinner after *one* hour 
> of
> reading black text on white.

Yes, but...

>  Choroid thickness is known to be a
> significant factor in myopia.

in the sense that a thicker choroid is correlated to worse cases 
of myopia? Or is it the other way around? (Perhaps it's me, but 
the formulation "choroid thickness is a factor in myopia" doesn't 
seem to answer that question.)

-- 
Joost Kremers
Life has its moments

Re: Changes for emacs 28

[Dmitry Gutov]

On 07.09.2020 11:38, Ricardo Wurmus wrote:
> https://www.nature.com/articles/s41598-018-28904-x
> 
>    “We found that reading dark text on bright background reduces
> choroidal thickness in one hour, while reading bright text on dark
> background increases the thickness of the choroid. Since choroidal
> thickness changes are precursors for future changes in eye growth, we
> expect that there will be selective effects on subsequent myopia
> development.”

I wouldn't take this at face value. First, the big "conclusion" in there 
is based on conjecture, we don't know the underlying choroid <-> myopia 
mechanism, and whether it's causation or correlation.

Second, the example dark-on-light color choice in the article (Figure 1) 
is obviously terrible and low-contrast. I wouldn't recommend anyone to 
use it.

Third, and this is of course anecdotal, I had an episode in my 
mid-twenties where I started having problems with vision (blurriness, 
low perception in the dark, etc), and it only got better when I made 
sure to use good, strong lighting everywhere, good contrast screens, 
etc, which is the predominant ergonomic advice these days. 10 years 
later, my vision is 20/20.

Another advice from the same category is that the brightness and 
contrast levels of your screen should match the rest of the room, and 
more specifically, the room (or wall) behind the screen. So dark themes 
have their uses, of course (for reading in the dark: on the phone in the 
evening outside; on the airplane; etc). But I'm quite sure defaulting to 
a light theme for general work is still better for most people.

Re: Changes for emacs 28

[Juri Linkov]

> Another advice from the same category is that the brightness and contrast
> levels of your screen should match the rest of the room, and more
> specifically, the room (or wall) behind the screen. So dark themes have
> their uses, of course (for reading in the dark: on the phone in the evening
> outside; on the airplane; etc). But I'm quite sure defaulting to a light
> theme for general work is still better for most people.

+1  Also it's recommended to use a blue light filter to avoid suppression of
Melatonin production.  For example, http://jonls.dk/redshift/ pre-installed
on Mint adjusts the color temperature depending on the time of the day.

Re: Changes for emacs 28

[Alfred M. Szmidt]

There is a fine line to walk between people who use emacs, and people
who might come to use emacs.  To change the defaults of Emacs to
something that would be entirely alien to the majority of Emacs users
would do more harm than good.  

Many settings can be set using Cutomize which is available via the
menu bar, maybe another page or some type of reorganisation with
commonly wanted settings could be done.  Emacs already has packages
that you can install using the Manage Emacs Packages option in the menu
bar as well.  Context dependant mouse menus based on the mode are
already provided in Emacs since a long time, Control and right click.

The missing features you are raising seem to be already provided by
emacs.  Even if learning Lisp should be considered something to
encourage all users, a new users can happily use Emacs without seeing
any lisp code, or never invoking M-x since Emacs works very well out
of the box.  This is not to say that each of the above couldn't use
improvements, but one can do so without breaking things for existing
users.

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Instead of discussing new, radical defaults (which I don't think are
going to go anywhere, because annoying older users isn't nice), we could
just put a button on the opening splash page saying

     Current theme: Classic.  Click HERE to get the super-cool rad one.

And then the HERE could enable whatever the kids these days want, and it
could be ALL the mod cons.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[Caio Henrique]

I wouldn't mind radical new defaults if I could easily disable them with
some compilation flag like --with-old-defaults, or just adding a line like 
(setq use-new-radical-defaults nil) to my early-init.el.

Cordially,
Caio Henrique

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Sun, Sep 06 2020, Caio Henrique wrote:

> I wouldn't mind radical new defaults if I could easily disable them with
> some compilation flag like --with-old-defaults, or just adding a line like
> (setq use-new-radical-defaults nil) to my early-init.el.

FWIW, as someone who has been using emacs for more than 20 years and
spends 90% of his computer time in emacs, i wouldn't mind either.

IMHO, the odds that an experienced user of emacs would ditch it just
because of a (for her, easily overriden) default change are virtually
nil; with a new user, the situation is almost the opposite.

Just my old-timer 2 cents,
jao
-- 
More people would learn from their mistakes if they weren't so busy
denying them - Harlod J. Smith

Re: Changes for emacs 28

[Lars Ingebrigtsen]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> IMHO, the odds that an experienced user of emacs would ditch it just
> because of a (for her, easily overriden) default change are virtually
> nil; with a new user, the situation is almost the opposite.

I don't think we should underestimate how annoying user interface
changes can be.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Mon, Sep 07 2020, Lars Ingebrigtsen wrote:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> IMHO, the odds that an experienced user of emacs would ditch it just
>> because of a (for her, easily overriden) default change are virtually
>> nil; with a new user, the situation is almost the opposite.
>
> I don't think we should underestimate how annoying user interface
> changes can be.

Well, yes, but that cuts both ways: for new users with experience with
other editors or current environments, opening Emacs for the first time
amounts to a huge user interface change.

Cheers,
jao
-- 
Once you hear the details of victory, it is hard to distinguish it
from a defeat. -Jean-Paul Sartre, writer and philosopher (1905-1980)

Re: Changes for emacs 28

[Eric S Fraga]

On Monday,  7 Sep 2020 at 13:44, Jose A. Ortega Ruiz wrote:
> Well, yes, but that cuts both ways: for new users with experience with
> other editors or current environments, opening Emacs for the first time
> amounts to a huge user interface change.

Yes, but a decision consciously made by choosing to try a new tool
whereas a change to the interface made to an existing user is without
her conscious choice.

But I'm one of those crusty/fusty Emacs users whose .emacs file (none of
this new fangled .emacs.d or .config business ;-)) dates to the 1980s so
I won't mind what happens as I'm sure I will be able to fix things to my
satisfaction...

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Changes for emacs 28

[Daniel Martín]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Instead of discussing new, radical defaults (which I don't think are
> going to go anywhere, because annoying older users isn't nice), we could
> just put a button on the opening splash page saying
>
>      Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it
> could be ALL the mod cons.

I very much agree with this point. For these discussions to be
productive, we should try to reach a compromise, if possible, and work
in small steps. The idea of offering a light/dark alternative theme
prominently from the splash screen is worth considering.

Recently, modus-operandi-theme[1] and modus-vivendi-theme[2] have been
included in core Emacs. They are two light/dark themes that offer good
accessibility and broad face coverage for internal and external
packages. I'm not suggesting we should offer those exact themes, that
was just an example; maybe we can poll users/developers about what's
their favorite FSF-copyrighted theme.

[1]: https://elpa.gnu.org/packages/modus-operandi-theme.html
[2]: https://elpa.gnu.org/packages/modus-vivendi-theme.html

--
Daniel Martín

Re: Changes for emacs 28

[Eduardo Ochs]

So we all want this modern-ish "layer" for Emacs. If I haven't missed
anything, the main ideas on how to activate it are:

  1) it will be the new default, or

  2) it will be toggled by a command-line option like "-m" (btw, is
     this viable on M$ Windows?), or

  3) there will be a button in the splash screen that toggles it,

  4) it can be toggled via Customize,

  5) it can be turned on by a built-in command like M-x
     use-the-new-super-cool-rad-layer.

In my not-so-humble-at-all opinion the recommended way to install this
new layer should START as a progn. The developers' page should say
something like: at this moment the modern-ish layer is still
experimental; to try it copy the 5-line "(progn ...)" below to an
Emacs buffer, put the cursor after the close-parenthesis in the last
line, and type C-x C-e - this will execute the whole (progn ...), and
this will install the super-cool-rad-layer and make it the default:

  (progn (Lorem ipsum dolor sit amet consectetuer adipiscing elit)
     (Ut purus elit vestibulum ut placerat ac adipiscing vitae felis)
     (Curabitur dictum gravida mauris)
     (Nam arcu libero nonummy eget consectetuer id vulputate a magna)
     )

This reminds me of a discussion that happened in February in the Lua
mailing list, about "we need a super-user-friendly distribution of Lua
that comes with all batteries included". In one of my messages to that
discussion - at http://lua-users.org/lists/lua-l/2020-02/msg00036.html
- I said:

  "In my way of seeing things, making a package manager that makes
  developers super-happy [1] is a pre-requisite for [2] having a
  distribution for all OSs including Windows that beginners find easy
  to use. And [1] can be done in 100 or 200 programmer-hours with
  expertise that we already have, while [2] needs 10000000000 hours at
  least, plus black-belt social skills, lots of money to hire external
  people, and luck."

I am very passionate about the idea that in environments like Emacs
"developer-friendly" should come before "user-friendly". If there are
people who insist that even in the development stage we should NEVER
offer the progn-ish way of installing the super-cool-rad-layer I would
be overjoyed to hit them several times with my ten-feet pole.

  Just my 2c, sorry for not being more active here, cheers, etc =),
    Eduardo Ochs
    http://angg.twu.net/emacsconf2019.html

On Sun, 6 Sep 2020 at 19:01, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Instead of discussing new, radical defaults (which I don't think are
> going to go anywhere, because annoying older users isn't nice), we could
> just put a button on the opening splash page saying
>
>      Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it
> could be ALL the mod cons.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

Re: Changes for emacs 28

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Instead of discussing new, radical defaults (which I don't think are
> going to go anywhere, because annoying older users isn't nice), we could
> just put a button on the opening splash page saying
>
>      Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it
> could be ALL the mod cons.

I agree.  I've proposed before to introduce a concept called "profiles"
much like the existing theme support:

    https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg02032.html
    https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01168.html

I haven't yet had the time/energy to work on this, but I think it could
be useful here.

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I agree.  I've proposed before to introduce a concept called "profiles"
> much like the existing theme support:
>
>     https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg02032.html
>     https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01168.html
>
> I haven't yet had the time/energy to work on this, but I think it could
> be useful here.

Yes, I think it's exactly what we need, and it seems like almost
everybody is pretty much in agreement?  But somebody has to, like,
implement it.  :-)

A splash page with a selection for different
profiles/distribution/flavour/curated version or whatever we're calling
it would be cool: A vi-flavoured one, and a Doom-flavoured one, etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Ergus <spacibba@aol.com>,  eliz@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 07 Sep 2020 00:01:05 +0200
> 
> Instead of discussing new, radical defaults (which I don't think are
> going to go anywhere, because annoying older users isn't nice), we could
> just put a button on the opening splash page saying
> 
>      Current theme: Classic.  Click HERE to get the super-cool rad one.
> 
> And then the HERE could enable whatever the kids these days want, and it
> could be ALL the mod cons.

This was suggested long ago, but no one seems to be willing to pick up
the gauntlet and make this happen.

Re: Changes for emacs 28

[Lars Ingebrigtsen]

This just showed up in my feed:

   https://phaazon.net/blog/editors-in-2020

It's kinda interesting -- they go through a bunch of editors and list
what works/doesn't work for them.  Key quote:

* The defaults of emacs are really, really bad. And making the whole thing like
 what you get with DOOM Emacs is going to cost you lots of hours reading
 documentation and experimenting with your configuration. I enjoyed doing it but
 in the end… why simply not ship emacs with those defaults? Is it due to
 historical reasons that no one cares about anymore nowadays? /stares at vim

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[tomas]

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

On Mon, Sep 07, 2020 at 02:31:36PM +0200, Lars Ingebrigtsen wrote:
> This just showed up in my feed:
> 
>    https://phaazon.net/blog/editors-in-2020
> 
> It's kinda interesting -- they go through a bunch of editors and list
> what works/doesn't work for them.  Key quote:
> 
> * The defaults of emacs are really, really bad. And making the whole thing like
>  what you get with DOOM Emacs is going to cost you lots of hours reading
>  documentation and experimenting with your configuration. I enjoyed doing it but
>  in the end… why simply not ship emacs with those defaults? Is it due to
>  historical reasons that no one cares about anymore nowadays? /stares at vim

This is, of course, Dimitri Sabadie's take on it. It's an interesting
read, and one can learn a lot about it.

Still I spot this horrible anti-pattern ("my opinion matters, others
don't exist", cf the above: "Is it due to historical reasons that no
one cares about anymore nowadays?" -- has Dimitri ever talked to someone
who might "care nowadays" or does he postulate his POV to be the only one?).

Same goes for those terms subtly transporting a judgment like "modern".
They don't go well with those people implicitly being relegated to 
"not existent" or "old".

I'd like to see some integrative efforts on part of those proposing
changes -- more akin to "what can be done to cater to all?" instead
of "let's change the defaults to look more like VSCode!".

Discussing the defaults one by one (as proposed by Eli) might be one
good step in that direction.

After all, we don't gain anything by attracting two VSCoders and
kicking out five old-timers here.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> The defaults of emacs are really, really bad. And making the whole thing 
> like what you get with DOOM Emacs is going to cost you lots of hours 
> reading documentation and experimenting with your configuration.
>

That's just wrong.  If you want Doom Emacs, you just have to type two 
commands:

git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d

~/.emacs.d/bin/doom install

The first commands takes two seconds to complete, the second one about 
five minutes (it downloads and compiles about 200 MB of code, fonts, 
icons, ...).  Then you start Emacs, and you're done.  That's clearly not 
"lots of hours".

Re: Changes for emacs 28

[Ergus]

On Mon, Sep 07, 2020 at 01:05:20PM +0000, Gregory Heytings via Emacs development discussions. wrote:
>
>>
>>The defaults of emacs are really, really bad. And making the whole 
>>thing like what you get with DOOM Emacs is going to cost you lots of 
>>hours reading documentation and experimenting with your 
>>configuration.
>>
>
>That's just wrong.  If you want Doom Emacs, you just have to type two 
>commands:
>
>git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
>
>~/.emacs.d/bin/doom install
>
>The first commands takes two seconds to complete, the second one about 
>five minutes (it downloads and compiles about 200 MB of code, fonts, 
>icons, ...).  Then you start Emacs, and you're done.  That's clearly 
>not "lots of hours".
>

I think it refers to convert vanilla emacs in a "doomed like"
experience.

Any way the doom experience is (in my opinion) like the spacemacs
experience. A signal that

1) There are enough people interested enough in emacs (the community)
and we (as developers) are not interacting enough with them or hearing
their concerns and needs.

2) Part of that community are also so annoyed with the defaults (and
have the needed skills) that they tried to create their own "emacs
distro" like a "GNU/Linux distro".

3) They are reinventing the wheel again and again because we don't
attract some of them on board to contribute part of their code into
vanilla.

The existence of larger sub-communities like spacemacs or doom or forks
like remacs is a bad symptom and a waste of manpower we really need.

My last 2 cents on this.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Mon, 7 Sep 2020 16:03:32 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> The existence of larger sub-communities like spacemacs or doom or forks
> like remacs is a bad symptom and a waste of manpower we really need.

I don't think I agree that those communities are a waste of effort:
someone needed to invest those efforts anyway.

The waste of effort is that those who invested them don't come back to
us and don't suggest to integrate those features upstream.  Granted,
such integration would need some additional shims and infrastructure,
to adapt the extra features to less monolith audience.  But those
adaptations should not be very hard to come up with, so the lack of
communications is unfortunate.

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The waste of effort is that those who invested them don't come back to
  > us and don't suggest to integrate those features upstream.  Granted,
  > such integration would need some additional shims and infrastructure,
  > to adapt the extra features to less monolith audience.  But those
  > adaptations should not be very hard to come up with, so the lack of
  > communications is unfortunate.

You may be right.  I think it depends on what sort of changes they make,
and I have no idea what sort they are.

It might be that some of their changes are features we'd like to
merge in as optional features, or new options, while others are not.
Maybe they would be willing to contribute certain code that we would like
since it could reduce the continuing maintenance work they do.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>>> The defaults of emacs are really, really bad. And making the whole 
>>> thing like what you get with DOOM Emacs is going to cost you lots of 
>>> hours reading documentation and experimenting with your configuration.
>> 
>> That's just wrong.  If you want Doom Emacs, you just have to type two 
>> commands:
>> 
>> git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
>> 
>> ~/.emacs.d/bin/doom install
>> 
>> The first commands takes two seconds to complete, the second one about 
>> five minutes (it downloads and compiles about 200 MB of code, fonts, 
>> icons, ...).  Then you start Emacs, and you're done.  That's clearly 
>> not "lots of hours".
>
> I think it refers to convert vanilla emacs in a "doomed like" 
> experience.
>

I don't understand.  The two commands above do exactly that.

Or does "convert vanilla emacs in a "doomed like" experience" means 
"without using Doom Emacs, by doing everything by oneself"?  In that case 
it's not wrong, it is ridiculous.  Almost as ridiculous as if he had 
written "it would have taken me more time to develop Emacs by myself than 
to develop Visual Studio by myself".

BTW, I find that many of the defaults of Visual Studio are really bad, and 
I'm pretty sure that making the whole thing like what you get with vanilla 
Emacs would cost me lots of hours.  Can I conclude something from this? 
Clearly not.

Re: Changes for emacs 28

[Ergus]

On Mon, Sep 07, 2020 at 03:37:58PM +0000, Gregory Heytings wrote:
>
>>>>The defaults of emacs are really, really bad. And making the 
>>>>whole thing like what you get with DOOM Emacs is going to cost 
>>>>you lots of hours reading documentation and experimenting with 
>>>>your configuration.
>>>
>>>That's just wrong.  If you want Doom Emacs, you just have to type 
>>>two commands:
>>>
>>>git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
>>>
>>>~/.emacs.d/bin/doom install
>>>
>>>The first commands takes two seconds to complete, the second one 
>>>about five minutes (it downloads and compiles about 200 MB of 
>>>code, fonts, icons, ...).  Then you start Emacs, and you're done.  
>>>That's clearly not "lots of hours".
>>
>>I think it refers to convert vanilla emacs in a "doomed like" 
>>experience.
>>

Sorry, you don't get the point and I don't waste more time on this.

>
>I don't understand.  The two commands above do exactly that.
>
>Or does "convert vanilla emacs in a "doomed like" experience" means 
>"without using Doom Emacs, by doing everything by oneself"?  In that 
>case it's not wrong, it is ridiculous.  Almost as ridiculous as if he 
>had written "it would have taken me more time to develop Emacs by 
>myself than to develop Visual Studio by myself".
>
If a software we develop require a complex layer like doom (which could
be seen as a big set of patches) to be "attractive" for many users. But
also if there are many layer many of them doing the similar changes
again and again. Yes our software is missing something.

>BTW, I find that many of the defaults of Visual Studio are really bad, 
>and I'm pretty sure that making the whole thing like what you get with 
>vanilla Emacs would cost me lots of hours.  Can I conclude something 
>from this? Clearly not.

There is not such a thing like the "perfect" default. But we can learn
some things from similar newer software around. Sometimes the feeling is
that we don't change things not because they are fine, but because we
are used to how they are and we reject anything that other editors are
doing just because they are not us (the opposite is also an error;
trying to do everything the others are doing).

Any way there is a sort of consensus about the profiles No more
discussion is needed.

Re: Changes for emacs 28

[Alfred M. Szmidt]

   >Or does "convert vanilla emacs in a "doomed like" experience" means 
   >"without using Doom Emacs, by doing everything by oneself"?  In that 
   >case it's not wrong, it is ridiculous.  Almost as ridiculous as if he 
   >had written "it would have taken me more time to develop Emacs by 
   >myself than to develop Visual Studio by myself".

   If a software we develop require a complex layer like doom (which could
   be seen as a big set of patches) to be "attractive" for many users. 

Emacs definitely doesn't require a complex layer like doom /
spaceemacs.

Re: Changes for emacs 28

[Eduardo Ochs]

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

Is there a way to have both standard Emacs and Doom Emacs available at the
same time? Is there a way to run the standard Emacs and then make it load
the Doom code? Where can we find instructions for that? Is Doom Emacs
user-friendly to long-time Emacs users that would want to turn the Doom
layer on for only a few minutes each week?

  Cheers & thanks in advance,
    Eduardo Ochs

On Mon, 7 Sep 2020, 10:06 Gregory Heytings via Emacs development
discussions., <emacs-devel@gnu.org> wrote:

>
> >
> > The defaults of emacs are really, really bad. And making the whole thing
> > like what you get with DOOM Emacs is going to cost you lots of hours
> > reading documentation and experimenting with your configuration.
> >
>
> That's just wrong.  If you want Doom Emacs, you just have to type two
> commands:
>
> git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
>
> ~/.emacs.d/bin/doom install
>
> The first commands takes two seconds to complete, the second one about
> five minutes (it downloads and compiles about 200 MB of code, fonts,
> icons, ...).  Then you start Emacs, and you're done.  That's clearly not
> "lots of hours".
>
>

[-- Attachment #2: Type: text/html, Size: 1723 bytes --]

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
> Is there a way to have both standard Emacs and Doom Emacs available at 
> the same time? Is there a way to run the standard Emacs and then make it 
> load the Doom code? Where can we find instructions for that?
>

"Doom Emacs" is, in essence, a set of Emacs Lisp files bundled together, 
configured so that they interact nicely and coherently.  For example, 
smartparens, which-key and magit are part of Doom Emacs, but can be used 
(and were developed) independently of Doom Emacs.  The same holds for all 
Emacs "distributions", for example Spacemacs or Emacs Prelude.

The Emacs Lisp files contained in these distributions are loaded by Emacs 
when it starts and change its look and feel.  What you run is "standard 
Emacs", but with a number of non-standard (that is, not distributed with 
Emacs) Emacs Lisp files.

>
> Is Doom Emacs user-friendly to long-time Emacs users that would want to 
> turn the Doom layer on for only a few minutes each week?
>

That's of course possible.  It suffices to replace one's ~/.emacs.d 
directory with the ~/.emacs.d directory of an Emacs distribution (and to 
move the ~/.emacs file, if it exists, to another place).  Switching 
between several Emacs distributions can probably be achieved with symbolic 
links.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 07 Sep 2020 22:07:39 +0000, Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> said:

    >> Is Doom Emacs user-friendly to long-time Emacs users that would want
    >> to turn the Doom layer on for only a few minutes each week?
    >> 

    Gregory> That's of course possible.  It suffices to replace one's ~/.emacs.d
    Gregory> directory with the ~/.emacs.d directory of an Emacs distribution (and
    Gregory> to move the ~/.emacs file, if it exists, to another place).  Switching
    Gregory> between several Emacs distributions can probably be achieved with
    Gregory> symbolic links.

Anything is possible with symbolic links, but with emacs >= 27.1 itʼs
probably easier to use XDG_CONFIG_HOME

Robert

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's kinda interesting -- they go through a bunch of editors and list
  > what works/doesn't work for them.  Key quote:

  > * The defaults of emacs are really, really bad.

Alas, that feedback is too vague to be of any use.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> Instead of discussing new, radical defaults (which I don't think are 
> going to go anywhere, because annoying older users isn't nice), we could 
> just put a button on the opening splash page saying
>
>     Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it 
> could be ALL the mod cons.
>

I could perhaps agree with this (except perhaps that I would rephrase "to 
get the super-cool..." as "to activate the super-cool...").  But as Eli 
noted nobody has done this so far.  And in fact I'm not sure it would 
really improve the "adoption rate".  There are plenty of example 
configurations available (for example Spacemacs), and someone who would 
not want to make the effort of trying to find a configuration that suits 
their needs would quickly switch to another trendy editor anyway.

FWIW, my own experience with this kind of tools is that those who do not 
have initially a good non-technical reason to use it (for example "I want 
to be a guru", "Someone I admire uses that tool", "It is one of the freest 
free software", "It is based on Lisp and I love Lisp", "I want to have the 
freedom to change everything to make it work exactly as I want", "I like 
minimal user interfaces", "I want to do as much as possible without using 
a mouse", ...) will not use it in the long term.  This external motivation 
is necessary to "climb the learning curve", so to speak, and "better" 
defaults will have no influence on it.

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> Instead of discussing new, radical defaults (which I don't think are 
> going to go anywhere, because annoying older users isn't nice), we could 
> just put a button on the opening splash page saying
>
>     Current theme: Classic.  Click HERE to get the super-cool rad one.
>
> And then the HERE could enable whatever the kids these days want, and it 
> could be ALL the mod cons.
>

Would it not be better to have a "guided tour" (something like C-h t, but 
shorter and more "modern") for first-time users (those without a .emacs / 
.emacs.d)?  This is quite common in "modern" software, so it would not 
surprise anyone.

During that "guided tour" the user could select a number of options, e.g. 
cua-mode, evil-mode, which-key, hl-line, show-paren-mode, a theme 
(customize-themes is there since Emacs 24, with a number builtin themes, 
currently sixteen), and these options would be written in their .emacs 
file.

(In fact, it would perhaps make sense to create a few guided tours, with 
an initial question "Are you a programmer? a scientist? a teacher? a 
writer?" with which the set of options could be narrowed.)

With this it would be unnecessary to change any of the defaults, yet 
newcomers would quickly be able to tailor some aspects of Emacs to their 
needs.

A side-effect is that the discussions here would perhaps be less 
passionated.  "Should feature X be offered as an option to first-time 
users?" may lead to more serene discussions than "Should feature X become 
a default in future Emacs versions?"

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> Would it not be better to have a "guided tour" (something like C-h t,
> but shorter and more "modern") for first-time users (those without a
> .emacs / .emacs.d)?  This is quite common in "modern" software, so it
> would not surprise anyone.
[...]
> (In fact, it would perhaps make sense to create a few guided tours,
> with an initial question "Are you a programmer? a scientist? a
> teacher? a writer?" with which the set of options could be narrowed.)

Why not instead just have nicer introductory material? E.g. videos that
walk through initial customisation for different setups, that discuss
and explain things, talk about tangents.

This actually is produced by the community, but it’s scattered around
YouTube.  We could ask prolific producers to prepare 20-30min videos for
some particular setup, showing how to get going with Emacs in that
particular niche.

The wizard idea from another thread is nice, but I’m not a fan of a
whole guided tour.  Most probably people would want to skip it.  A
blocker just as your first boot a program is not nice.


--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
>> Would it not be better to have a "guided tour" (something like C-h t, 
>> but shorter and more "modern") for first-time users (those without a 
>> .emacs / .emacs.d)?  This is quite common in "modern" software, so it 
>> would not surprise anyone.
> [...]
>> (In fact, it would perhaps make sense to create a few guided tours, 
>> with an initial question "Are you a programmer? a scientist? a teacher? 
>> a writer?" with which the set of options could be narrowed.)
>
> Why not instead just have nicer introductory material? E.g. videos that 
> walk through initial customisation for different setups, that discuss 
> and explain things, talk about tangents.
>

That's too complex IMO.  I at least would never have the patience to watch 
N videos to discover such things.  If the target is users who just give 
Emacs a try, as we all do from time to time for programs we don't know, 
expecting that they would first watch videos (or to read introductory 
material) sets the bar way too high.

>
> The wizard idea from another thread is nice, but I’m not a fan of a 
> whole guided tour.  Most probably people would want to skip it.  A 
> blocker just as your first boot a program is not nice.
>

I was thinking of something very simple, with say five screens.  There are 
at least two examples I have in mind and which I find rather pleasing to 
go through: the Debian installer and the macOS installer.

A rough draft:

Screen 1: Welcome! Please tell us something about you: are you (a) a 
programmer, (b) a teacher, (c) ...

Screen 2: Choose a theme (font + colors).

Screen 3: A few (at most twenty) common options to turn on or off, with a 
short explanation for each option.  "cua-mode" is a good candidate for 
this screen.  A button "Other options" could open another similar screen 
with a few other less common options to turn on or off.

Screen 4: Some basic explanations: what "C-" and "M-" mean, what is the 
minibuffer, ...

Screen 5: Thank you and welcome on board!  You'll find a list of 
extensions that you may find useful in the menu "Extensions".

The menu "Extensions" would be populated depending on the user kind 
selected in screen 1.

Re: Changes for emacs 28

[Stefan Monnier]

> Emacs a try, as we all do from time to time for programs we don't know,
> expecting that they would first watch videos (or to read introductory
> material) sets the bar way too high.

Yes and no: many (young) people seem to spend most of their time
watching videos (as in, watching videos is their equivalent to my being
idle).  But admittedly, those videos usually last 10s or so (and if not,
they switch to the next video anyway), so we'd have to use *very* short
videos, ideally funny and sexy, maybe with a cat?


        Stefan

Re: Changes for emacs 28

[Ergus]

On Wed, Sep 09, 2020 at 12:19:10PM -0400, Stefan Monnier wrote:
>> Emacs a try, as we all do from time to time for programs we don't know,
>> expecting that they would first watch videos (or to read introductory
>> material) sets the bar way too high.
>
>Yes and no: many (young) people seem to spend most of their time
>watching videos (as in, watching videos is their equivalent to my being
>idle).  But admittedly, those videos usually last 10s or so (and if not,
>they switch to the next video anyway), so we'd have to use *very* short
>videos, ideally funny and sexy, maybe with a cat?
>
>
>        Stefan

To start lets see what video series are around and it seems to be some
material already (and the most important, people willing to do emacs
videos):

https://www.youtube.com/watch?v=rBcw42ZGJDo&list=PLstWlvURJNxQknxEfkIktiPDfUrAUC8s6
https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpFxIcNQa9js7dQQIHc81b0-Xg
https://www.youtube.com/watch?v=V27zOhfN8Ys&list=PLGP2UnPoZ7HzLGU2cyK1MXSZwXy5niFkk

So far (as I have seen most of those) they have just 3 issues:

1) Put most of the attention in the external packages and not in the
vanilla functionalities.

2) They are not connected or referenced in the emacs web site. But also
they make little or no reference to the manual at all.

3) I saw a series of vim tutorials and the videos were sealing vim much
better. Even the vim terrible modes they found a way to sale them as
features..

4*) There are very few videos about elisp language and programming or
the emacs infrastructure.

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > https://www.youtube.com/watch?v=rBcw42ZGJDo&list=PLstWlvURJNxQknxEfkIktiPDfUrAUC8s6
  > https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpFxIcNQa9js7dQQIHc81b0-Xg
  > https://www.youtube.com/watch?v=V27zOhfN8Ys&list=PLGP2UnPoZ7HzLGU2cyK1MXSZwXy5niFkk

If these videos carry free licenses, and they are worth referring to,
we can do so.  Not on youtube, though: it sends nonfree JS code to the
browser.

If we could count on the "invidious" sites to function stably, we could
refer to the videos via them.  But we can't assume Google will allow
them to continue functioning.

So we would have to copy the videos to a place we can count on to
function without demanding you run nonfree software.

  > 3) I saw a series of vim tutorials and the videos were sealing vim much
  > better. Even the vim terrible modes they found a way to sale them as
  > features..

To address that, we need people who can MAKE good videos.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 07:13, Richard Stallman wrote:
> If we could count on the "invidious" sites to function stably, we could
> refer to the videos via them.  But we can't assume Google will allow
> them to continue functioning.
> 
> So we would have to copy the videos to a place we can count on to
> function without demanding you run nonfree software.
> 
>    > 3) I saw a series of vim tutorials and the videos were sealing vim much
>    > better. Even the vim terrible modes they found a way to sale them as
>    > features..
> 
> To address that, we need people who can MAKE good videos.

I'd like to remind everybody that we do have a few videos on 
https://www.gnu.org/software/emacs/ already.

Alas, Magnar has not been making any new videos for a few years now, so 
we probably can't ask him to make a specific video.

Re: Changes for emacs 28

[Pankaj Jangid]

Gregory Heytings via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> That's too complex IMO.  I at least would never have the patience to
> watch N videos to discover such things.  If the target is users who
> just give Emacs a try, as we all do from time to time for programs we
> don't know, expecting that they would first watch videos (or to read
> introductory material) sets the bar way too high.

I assumed the same thing when I was training a new joinee in my
company. Probably we are getting old. :-) This new person tells me after
going through software manuals for 2-3 days, "do we have video
tutorials?"

So my opinion is that we need impressive community videos that talk
about vanilla emacs.

Re: Changes for emacs 28

[Ergus]

On September 9, 2020 5:04:57 PM GMT+02:00, "Göktuğ Kayaalp" <self@gkayaalp.com> wrote:
>On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development
>discussions. <emacs-devel@gnu.org> wrote:
>> Would it not be better to have a "guided tour" (something like C-h t,
>> but shorter and more "modern") for first-time users (those without a
>> .emacs / .emacs.d)?  This is quite common in "modern" software, so it
>> would not surprise anyone.
>[...]
>> (In fact, it would perhaps make sense to create a few guided tours,
>> with an initial question "Are you a programmer? a scientist? a
>> teacher? a writer?" with which the set of options could be narrowed.)
>
>Why not instead just have nicer introductory material? E.g. videos that
>walk through initial customisation for different setups, that discuss
>and explain things, talk about tangents.
>
>This actually is produced by the community, but it’s scattered around
>YouTube.  We could ask prolific producers to prepare 20-30min videos
>for
>some particular setup, showing how to get going with Emacs in that
>particular niche.
>
>The wizard idea from another thread is nice, but I’m not a fan of a
>whole guided tour.  Most probably people would want to skip it.  A
>blocker just as your first boot a program is not nice.
>

Yes I think that more, better and organized set of videos could be much easier to produce. There are actually some emacs video series already. We just need to organize the links and refer them in the site. 

Actually shorter videos maybe 10 mins is enough. Specially if they add links to the manual sections related to the topic and how to access it either from emacs and on the web.


>
>--
>İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
>pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Changes for emacs 28

[Ihor Radchenko]

> Actually shorter videos maybe 10 mins is enough. Specially if they add links to the manual sections related to the topic and how to access it either from emacs and on the web.

Would it also make sense to add links to the videos (or relevant wiki
page) from manual itself?

Best,
Ihor

Ergus <spacibba@aol.com> writes:

> On September 9, 2020 5:04:57 PM GMT+02:00, "Göktuğ Kayaalp" <self@gkayaalp.com> wrote:
>>On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development
>>discussions. <emacs-devel@gnu.org> wrote:
>>> Would it not be better to have a "guided tour" (something like C-h t,
>>> but shorter and more "modern") for first-time users (those without a
>>> .emacs / .emacs.d)?  This is quite common in "modern" software, so it
>>> would not surprise anyone.
>>[...]
>>> (In fact, it would perhaps make sense to create a few guided tours,
>>> with an initial question "Are you a programmer? a scientist? a
>>> teacher? a writer?" with which the set of options could be narrowed.)
>>
>>Why not instead just have nicer introductory material? E.g. videos that
>>walk through initial customisation for different setups, that discuss
>>and explain things, talk about tangents.
>>
>>This actually is produced by the community, but it’s scattered around
>>YouTube.  We could ask prolific producers to prepare 20-30min videos
>>for
>>some particular setup, showing how to get going with Emacs in that
>>particular niche.
>>
>>The wizard idea from another thread is nice, but I’m not a fan of a
>>whole guided tour.  Most probably people would want to skip it.  A
>>blocker just as your first boot a program is not nice.
>>
>
> Yes I think that more, better and organized set of videos could be much easier to produce. There are actually some emacs video series already. We just need to organize the links and refer them in the site. 
>
> Actually shorter videos maybe 10 mins is enough. Specially if they add links to the manual sections related to the topic and how to access it either from emacs and on the web.
>
>
>>
>>--
>>İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
>>pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Changes for emacs 28

[Philip K.]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> wrote:
>> Would it not be better to have a "guided tour" (something like C-h t,
>> but shorter and more "modern") for first-time users (those without a
>> .emacs / .emacs.d)?  This is quite common in "modern" software, so it
>> would not surprise anyone.
> [...]
>> (In fact, it would perhaps make sense to create a few guided tours,
>> with an initial question "Are you a programmer? a scientist? a
>> teacher? a writer?" with which the set of options could be narrowed.)
>
> Why not instead just have nicer introductory material? E.g. videos that
> walk through initial customisation for different setups, that discuss
> and explain things, talk about tangents.
>
> This actually is produced by the community, but it’s scattered around
> YouTube.  We could ask prolific producers to prepare 20-30min videos for
> some particular setup, showing how to get going with Emacs in that
> particular niche.

Why 20-30 minutes? I think limiting it to 2-3 minutes for specific
problems would be more helpful. After all, a video that demonstrates
one thing well (search, buffer or window management, etc.) is better
than mentioning a few topics over the timespan of half an hour. I hope
I'm not the only one who tends to forget most of the points made in a
longer video, and often gives up half-way through if it gets too
boring.

> The wizard idea from another thread is nice, but I’m not a fan of a
> whole guided tour.  Most probably people would want to skip it.  A
> blocker just as your first boot a program is not nice.

I think I've suggested this before, but a manually invoked wizard could
be interesting. Typing "M-x intro" and getting a selection of
"interactive tutorials" -- again short and with a progress indicator --
would probably help a lot of people learn the basics quicker than
reading the manual or C-h t.

-- 
	Philip K.

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Does anyone want to _make_ videos for Emacs?

It is no use discussing what sort of videos we
would like if nobody wants to make them.
Let's stick to ideas we can implement.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Ihor Radchenko]

> Does anyone want to _make_ videos for Emacs?
>
> It is no use discussing what sort of videos we
> would like if nobody wants to make them.
> Let's stick to ideas we can implement.

I can try to contact Mike Zamansky [1] - he already has very good
introductory series about Emacs and might (hopefully) be interested to
help. Also, he is a teacher himself and may be a good person to suggest
on the best format/timing of such videos.

Best,
Ihor

[1] https://www.youtube.com/channel/UCxkMDXQ5qzYOgXPRnOBrp1w

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Does anyone want to _make_ videos for Emacs?
>
> It is no use discussing what sort of videos we
> would like if nobody wants to make them.
> Let's stick to ideas we can implement.
>
> -- 
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 12:16:13AM -0400, Richard Stallman wrote:
>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>[[[ whether defending the US Constitution against all enemies,     ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>Does anyone want to _make_ videos for Emacs?
>
>It is no use discussing what sort of videos we
>would like if nobody wants to make them.
>Let's stick to ideas we can implement.
>
Actually there are series of videos in youtube about emacs. Some of them
very long with more than 40 episodes. So their producers could be
contacted and they could help making things on demand. (not centered in
external packages but in included features or elpa packages only)

The real problem is: If we cannot refer to youtube then: Where these
videos can be offloaded that we could link to?

>-- 
>Dr Richard Stallman
>Chief GNUisance of the GNU Project (https://gnu.org)
>Founder, Free Software Foundation (https://fsf.org)
>Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

Re: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

> On Fri, Sep 11, 2020 at 12:16:13AM -0400, Richard Stallman wrote:
>>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>[[[ whether defending the US Constitution against all enemies,     ]]]
>>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>Does anyone want to _make_ videos for Emacs?
>>
>>It is no use discussing what sort of videos we
>>would like if nobody wants to make them.
>>Let's stick to ideas we can implement.
>
> Actually there are series of videos in youtube about emacs. Some of them
> very long with more than 40 episodes. So their producers could be
> contacted and they could help making things on demand. (not centered in
> external packages but in included features or elpa packages only)
>
> The real problem is: If we cannot refer to youtube then: Where these
> videos can be offloaded that we could link to?

I was thinking about using Peertube for something like that. It works
fairly well, the interface is clean enough, and it even has fediverse
integration.

-- 
	Philip K.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 12:55:41PM +0200, Philip K. wrote:
>Ergus <spacibba@aol.com> writes:
>
>> On Fri, Sep 11, 2020 at 12:16:13AM -0400, Richard Stallman wrote:
>>>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>[[[ whether defending the US Constitution against all enemies,     ]]]
>>>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>>Does anyone want to _make_ videos for Emacs?
>>>
>>>It is no use discussing what sort of videos we
>>>would like if nobody wants to make them.
>>>Let's stick to ideas we can implement.
>>
>> Actually there are series of videos in youtube about emacs. Some of them
>> very long with more than 40 episodes. So their producers could be
>> contacted and they could help making things on demand. (not centered in
>> external packages but in included features or elpa packages only)
>>
>> The real problem is: If we cannot refer to youtube then: Where these
>> videos can be offloaded that we could link to?
>
>I was thinking about using Peertube for something like that. It works
>fairly well, the interface is clean enough, and it even has fediverse
>integration.
>
>-- 
>	Philip K.

Good: I didn't know about it.

In this case we could start trying to contact the authors of the videos
already existent in youtube asking to copy them to peertube so we can
link them.

In principle they can keep a copy in youtube but we won't refer to
them.

Is it possible to create channels in peertube? If so, then maybe we
could create an "official" emacs channel and then some playlists there
for the creators.

Re: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

> Good: I didn't know about it.

In case anyone else is not familiar with the Project, here's the link:
https://joinpeertube.org/

> In this case we could start trying to contact the authors of the videos
> already existent in youtube asking to copy them to peertube so we can
> link them.
>
> In principle they can keep a copy in youtube but we won't refer to
> them.
>
> Is it possible to create channels in peertube? If so, then maybe we
> could create an "official" emacs channel and then some playlists there
> for the creators.

Yes, it's possible to create a channel
     
     https://docs.joinpeertube.org/#/use-create-upload-video

and playlists can be created too:

    https://docs.joinpeertube.org/#/use-library?id=playlist

-- 
	Philip K.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 02:12:24PM +0200, Philip K. wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Good: I didn't know about it.
>
>In case anyone else is not familiar with the Project, here's the link:
>https://joinpeertube.org/
>
>> In this case we could start trying to contact the authors of the videos
>> already existent in youtube asking to copy them to peertube so we can
>> link them.
>>
>> In principle they can keep a copy in youtube but we won't refer to
>> them.
>>
>> Is it possible to create channels in peertube? If so, then maybe we
>> could create an "official" emacs channel and then some playlists there
>> for the creators.
>
>Yes, it's possible to create a channel
>
>     https://docs.joinpeertube.org/#/use-create-upload-video
>
>and playlists can be created too:
>
>    https://docs.joinpeertube.org/#/use-library?id=playlist
>
>-- 
>	Philip K.

I also think that Mike Zamansky is the right guy for this task because
he has a very long set of video. Hopefully he will reply positively to
do an extra set of short videos/screen only about embedded
features. That we could recommend as video-tutorials in peertube.

There is also Sacha Chua, Howard Abrams, Derek Banas. All of them with
good formatted (but usually long) videos about emacs.

I prefer screen only videos because are more useful but also because
after a first version it could be easier to create versions in different
languages with them.

BTW I just contacted a couple of Spanish emacs youtubers. I am waiting
for their reply if they are willing to migrate/port their videos to
peertube to start with something.

Maybe some others here could do the same to contact youtubers in their
languages?

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Fri, Sep 11 2020, Ergus wrote:

[...]

> There is also Sacha Chua, Howard Abrams, Derek Banas. All of them with
> good formatted (but usually long) videos about emacs.
>
> I prefer screen only videos because are more useful but also because
> after a first version it could be easier to create versions in different
> languages with them.

I would suggest taking a look also at Protesilaos Stavrou's screencasts
(https://protesilaos.com/codelog/): they're close to what you are
imagining, and he's already collaborating with Emacs as the author of
the recently added modus-operandi and modus-vivendi themes.

Cheers,
jao
-- 
What sane person could live in this world and not be crazy?
  -Ursula K. Le Guin, author

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I don't know whether we can link to peertube.org.  Please tell me a URL
and I will check it.

  > >Yes, it's possible to create a channel
  > >
  > >     https://docs.joinpeertube.org/#/use-create-upload-video

That URL leads me to worry that its handling depends on JS code!


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 06:21 +03, Richard Stallman <rms@gnu.org> wrote:
> That URL leads me to worry that its handling depends on JS code!

It does, but it’s free software (AGPL 3.0).

They also are based on FOSS tech like ActivityPub and WebTorrent, and
mpv handles video urls just fine (I have version 0.32.0 from Linux Mint
20 repos).

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > That URL leads me to worry that its handling depends on JS code!

  > It does, but it’s free software (AGPL 3.0).

In a moral sense, that changes things.  If you suggest that a person
use Peertube, explaining that its JS code actually is free (supposing
you've verified that every script is indeed licenses that way), you're
not doing anything bad.

But we can't take that approach that when we refer the pubilc to
sites, because that approach does not scale.  It is not practical to
tell people, "The following 156 sites send only free JS code, even
though you can't verify that because the code isn't labeled for
LibreJS."  Advice of that form is too hard for people to follow, since
they can't remember those sites.  Therefore, giving such advice is
self-defeating.

We must refer only to sites that clearly label their JS code with
licenses, so that LibreJS can verify it for the user.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Does anyone want to _make_ videos for Emacs?
>
> It is no use discussing what sort of videos we
> would like if nobody wants to make them.
> Let's stick to ideas we can implement.
I am not the one, but looking at Youtube/Vimeo there are people who like
to make those; some people have series of videos. Maybe if you raised
question/call in "social media platforms" and proposed the content for
"episodes" maybe some people would take a provided "scenario" and turn
it into a video? Another solution is maybe to raise community funding
and pay some pro to make the desired content? But I think the first one
is more realistic :-).

By the way, I don't think the video content has to be done as real video
with a person talking in microfon and all that. It is common in some
graphical and 3d packages to have short "feature videos" where they
highlight some specific, or new, feature which is essentially just
someone clicking in gui and doing something basic just to showe where
the feature is and how it works. I think those are usually just scripted
and recorded as gif/png images and turned into some flv/mpg video or
similar. This kind of video can be done by anyone who knows how to use a
feature and if I am not wrong there is a screencast recorder for Emacs
already (requires external software).

Maybe video is not important at all since Emacs can be scripted; maybe
it is possible to script (macro) a "video" in Elisp; so when a demo is
called it would replay the gui/lisp actions like a macro?

Re: Changes for emacs 28

[Ricardo Wurmus]

Arthur Miller <arthur.miller@live.com> writes:

> Maybe video is not important at all since Emacs can be scripted; maybe
> it is possible to script (macro) a "video" in Elisp; so when a demo is
> called it would replay the gui/lisp actions like a macro?

The Guix videos at https://guix.gnu.org/videos/ were made with a
pipeline that assembles slides and scripted text:

    https://git.savannah.gnu.org/cgit/guix/videos.git

The core is a little Guile thing that interprets a scripted session
(like this: [1]) and produces a bunch of frames that are then assembled
with ffmpeg.

We built this pipeline to allow for easy translation of these videos.
To manage expectations: the intended effect is that of a narrated
slideshow presentation with little shell demos here and there.

Maybe parts of this workflow could be useful to those that would like to
build videos for Emacs.

[1]: https://git.savannah.gnu.org/cgit/guix/videos.git/tree/04-packaging1/en_US/sessions/firstCli

-- 
Ricardo

Re: Changes for emacs 28

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Maybe video is not important at all since Emacs can be scripted; maybe
>> it is possible to script (macro) a "video" in Elisp; so when a demo is
>> called it would replay the gui/lisp actions like a macro?
>
> The Guix videos at https://guix.gnu.org/videos/ were made with a
> pipeline that assembles slides and scripted text:
>
>     https://git.savannah.gnu.org/cgit/guix/videos.git
>
> The core is a little Guile thing that interprets a scripted session
> (like this: [1]) and produces a bunch of frames that are then assembled
> with ffmpeg.
>
> We built this pipeline to allow for easy translation of these videos.
> To manage expectations: the intended effect is that of a narrated
> slideshow presentation with little shell demos here and there.
>
> Maybe parts of this workflow could be useful to those that would like to
> build videos for Emacs.
>
> [1]: https://git.savannah.gnu.org/cgit/guix/videos.git/tree/04-packaging1/en_US/sessions/firstCli

I don't know how they look like, but probably. Can you record one of
those with a screen recorder and upload it somewhere as a demo how it
look like when in "action"?

Re: Changes for emacs 28

[Ricardo Wurmus]

Arthur Miller <arthur.miller@live.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Maybe video is not important at all since Emacs can be scripted; maybe
>>> it is possible to script (macro) a "video" in Elisp; so when a demo is
>>> called it would replay the gui/lisp actions like a macro?
>>
>> The Guix videos at https://guix.gnu.org/videos/ were made with a
>> pipeline that assembles slides and scripted text:
>>
>>     https://git.savannah.gnu.org/cgit/guix/videos.git
>>
>> The core is a little Guile thing that interprets a scripted session
>> (like this: [1]) and produces a bunch of frames that are then assembled
>> with ffmpeg.
>>
>> We built this pipeline to allow for easy translation of these videos.
>> To manage expectations: the intended effect is that of a narrated
>> slideshow presentation with little shell demos here and there.
>>
>> Maybe parts of this workflow could be useful to those that would like to
>> build videos for Emacs.
>>
>> [1]: https://git.savannah.gnu.org/cgit/guix/videos.git/tree/04-packaging1/en_US/sessions/firstCli
>
> I don't know how they look like, but probably. Can you record one of
> those with a screen recorder and upload it somewhere as a demo how it
> look like when in "action"?

I linked to them above:

   https://guix.gnu.org/videos/

All of these videos were made with this pipeline.

-- 
Ricardo

Re: Changes for emacs 28

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Arthur Miller <arthur.miller@live.com> writes:
>>>
>>>> Maybe video is not important at all since Emacs can be scripted; maybe
>>>> it is possible to script (macro) a "video" in Elisp; so when a demo is
>>>> called it would replay the gui/lisp actions like a macro?
>>>
>>> The Guix videos at https://guix.gnu.org/videos/ were made with a
>>> pipeline that assembles slides and scripted text:
>>>
>>>     https://git.savannah.gnu.org/cgit/guix/videos.git
>>>
>>> The core is a little Guile thing that interprets a scripted session
>>> (like this: [1]) and produces a bunch of frames that are then assembled
>>> with ffmpeg.
>>>
>>> We built this pipeline to allow for easy translation of these videos.
>>> To manage expectations: the intended effect is that of a narrated
>>> slideshow presentation with little shell demos here and there.
>>>
>>> Maybe parts of this workflow could be useful to those that would like to
>>> build videos for Emacs.
>>>
>>> [1]: https://git.savannah.gnu.org/cgit/guix/videos.git/tree/04-packaging1/en_US/sessions/firstCli
>>
>> I don't know how they look like, but probably. Can you record one of
>> those with a screen recorder and upload it somewhere as a demo how it
>> look like when in "action"?
>
> I linked to them above:
I am sorry my bed; I actually saw them but didn't realized they were
what you wrote about :-). Yes, it looks good, I think something similar
would be be great for Emacs. 

RE: Changes for emacs 28

[Drew Adams]

> and these options would be written in their .emacs file.

Just a nit about this part.

I really think we should get away from having Emacs
fiddle with users' init files.

For Customize, we should encourage use of `custom-file'.

For other, similar things (such as what you suggest),
we should similarly provide for Emacs to record
<whatever> in a file other than the init file.

An init file should be pretty much reserved for users.
Emacs and its libraries should try to stay away from it.
___


[For some reason, when I do `Reply All' for your
messages emacs-devel is not in the To or CC list.
Had to send this again, adding emacs-devel explicitly.]

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Wed, 9 Sep 2020 09:15:58 -0700 (PDT), Drew Adams <drew.adams@oracle.com> said:

    Drew> [For some reason, when I do `Reply All' for your
    Drew> messages emacs-devel is not in the To or CC list.
    Drew> Had to send this again, adding emacs-devel explicitly.]

Gregory has a 'Reply-To' header which points at ghe@sdf.org. I guess
your Outlook client honours it a bit too much

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> Gregory has a 'Reply-To' header which points at ghe@sdf.org. I guess 
> your Outlook client honours it a bit too much
>

Indeed.  I know this, but I don't know why this is the case (*).  I used 
to explicitly set Reply-To to emacs-devel@gnu.org in my MUA, but Eli asked 
me to stop to do this.

(*) I guess, but I'm not 100% sure, that Mailman honors the strict DMARC 
policy ("quarantine") of the the sdf.org domain.  So mails sent from that 
domain are forwared to the list with a "From: emacs-devel@gnu.org 
Reply-To: <original sender>" while those sent from other domains are 
forwared to the list with a "From: <original sender>".

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 12:26:15 +0000, Gregory Heytings <ghe@sdf.org> said:

    >> 
    >> Gregory has a 'Reply-To' header which points at ghe@sdf.org. I guess
    >> your Outlook client honours it a bit too much
    >> 

    Gregory> Indeed.  I know this, but I don't know why this is the case (*).  I
    Gregory> used to explicitly set Reply-To to emacs-devel@gnu.org in my MUA, but
    Gregory> Eli asked me to stop to do this.

I think in that case rmail replies only to emacs-devel@, which means
Eli has to add back the other recipients. Eli, do we need a "reply to
'From+To+CC+Reply-To'" feature in rmail? ("wide reply" in Gnus parlance).

    Gregory> (*) I guess, but I'm not 100% sure, that Mailman honors the strict
    Gregory> DMARC policy ("quarantine") of the the sdf.org domain.  So mails sent
    Gregory> from that domain are forwared to the list with a "From:
    Gregory> emacs-devel@gnu.org Reply-To: <original sender>" while those sent from
    Gregory> other domains are forwared to the list with a "From: <original
    sender> ".

Yes, that matches the Mailman documentation. Iʼm not sure what a good
solution is; Mailman adding a Reply-To with both the sender and
emacs-devel would no doubt also break either Outlook or rmail or
both. Not adding a Reply-To at all means the sender would get dropped
<sigh>.

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
> Yes, that matches the Mailman documentation. Iʼm not sure what a good 
> solution is; Mailman adding a Reply-To with both the sender and 
> emacs-devel would no doubt also break either Outlook or rmail or both. 
> Not adding a Reply-To at all means the sender would get dropped <sigh>.
>

In fact not adding a Reply-To would be perfect, at least for me. 
Presumably someone who sends a message to a list has subscribed to the 
list, of if they are not, it's common to mention explicitly that they are 
not.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 13:04:47 +0000, Gregory Heytings <ghe@sdf.org> said:

    >> 
    >> Yes, that matches the Mailman documentation. Iʼm not sure what a
    >> good solution is; Mailman adding a Reply-To with both the sender and
    >> emacs-devel would no doubt also break either Outlook or rmail or
    >> both. Not adding a Reply-To at all means the sender would get
    >> dropped <sigh>.
    >> 

    Gregory> In fact not adding a Reply-To would be perfect, at least for
    Gregory> me. Presumably someone who sends a message to a list has subscribed to
    Gregory> the list, of if they are not, it's common to mention explicitly that
    Gregory> they are not.

That works if their email address is mentioned in one of the headers
of the message, but in this case yours wouldnʼt be (unless you CC
yourself explicitly, which is an imposition on the sender)

DMARC/DKIM/SPF, what hath ye wrought?

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
>> In fact not adding a Reply-To would be perfect, at least for me. 
>> Presumably someone who sends a message to a list has subscribed to the 
>> list, of if they are not, it's common to mention explicitly that they 
>> are not.
>
> That works if their email address is mentioned in one of the headers of 
> the message, but in this case yours wouldnʼt be
>

Hmmm... Why should my address be mentioned in one of the headers of the 
message?  A "From emacs-devel@gnu.org To emacs-devel@gnu.org" or a "From 
emacs-devel@gnu.org To <someone> Cc emacs-devel@gnu.org" would be 
perfectly fine.  There is no need (in my case at least) to add a 
"Reply-To".

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 14:16:45 +0000, Gregory Heytings <ghe@sdf.org> said:

    >> 
    >>> In fact not adding a Reply-To would be perfect, at least for
    >>> me. Presumably someone who sends a message to a list has subscribed
    >>> to the list, of if they are not, it's common to mention explicitly
    >>> that they are not.
    >> 
    >> That works if their email address is mentioned in one of the headers
    >> of the message, but in this case yours wouldnʼt be
    >> 

    Gregory> Hmmm... Why should my address be mentioned in one of the headers of
    Gregory> the message?  A "From emacs-devel@gnu.org To emacs-devel@gnu.org" or a
    Gregory> "From emacs-devel@gnu.org To <someone> Cc emacs-devel@gnu.org" would
    Gregory> be perfectly fine.  There is no need (in my case at least) to add a
    Gregory> "Reply-To".

Yes, but you get mail sent to emacs-devel. Not everyone who sends to
emacs-devel is subscribed to it, nor do they all read it via gmane.io
like I do (or some other method of getting it). The polite assumption
is to CC the originator of the message, just in case, which is what
Drew did.

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 10 Sep 2020 14:52:49 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Drew Adams <drew.adams@oracle.com>,
>  Emacs developers <emacs-devel@gnu.org>
> 
>     Gregory> Indeed.  I know this, but I don't know why this is the case (*).  I
>     Gregory> used to explicitly set Reply-To to emacs-devel@gnu.org in my MUA, but
>     Gregory> Eli asked me to stop to do this.
> 
> I think in that case rmail replies only to emacs-devel@, which means
> Eli has to add back the other recipients. Eli, do we need a "reply to
> 'From+To+CC+Reply-To'" feature in rmail? ("wide reply" in Gnus parlance).

I don't think I understand what that means (never used Gnus, sorry),
and don't remember the details of the issue.  But in general, why
would someone need to set Reply-To to the list address when replying
to a message from the list?  It should be automatic in any sensible
MUA, no?

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 17:32:35 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Thu, 10 Sep 2020 14:52:49 +0200
    >> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Drew Adams <drew.adams@oracle.com>,
    >> Emacs developers <emacs-devel@gnu.org>
    >> 
    Gregory> Indeed.  I know this, but I don't know why this is the case (*).  I
    Gregory> used to explicitly set Reply-To to emacs-devel@gnu.org in my MUA, but
    Gregory> Eli asked me to stop to do this.
    >> 
    >> I think in that case rmail replies only to emacs-devel@, which means
    >> Eli has to add back the other recipients. Eli, do we need a "reply to
    >> 'From+To+CC+Reply-To'" feature in rmail? ("wide reply" in Gnus parlance).

    Eli> I don't think I understand what that means (never used Gnus, sorry),
    Eli> and don't remember the details of the issue.  But in general, why
    Eli> would someone need to set Reply-To to the list address when replying
    Eli> to a message from the list?  It should be automatic in any sensible
    Eli> MUA, no?

They wouldnʼt, but apparently Mailman sets 'Reply-To: ghe@sdf.org' on
Gregory's behalf, which then causes Outlook to respond only to him.

In Gnus, when I say 'wide reply', it hoovers up 'From,To,CC,Reply-To',
so that doesnʼt bother me. I donʼt know what rmail does, hence my
question.

Maybe Drew needs a different MUA? :-)

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: ghe@sdf.org,  larsi@gnus.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Thu, 10 Sep 2020 16:56:07 +0200
> 
>     Eli> I don't think I understand what that means (never used Gnus, sorry),
>     Eli> and don't remember the details of the issue.  But in general, why
>     Eli> would someone need to set Reply-To to the list address when replying
>     Eli> to a message from the list?  It should be automatic in any sensible
>     Eli> MUA, no?
> 
> They wouldnʼt, but apparently Mailman sets 'Reply-To: ghe@sdf.org' on
> Gregory's behalf, which then causes Outlook to respond only to him.

Then maybe Gregory should take this up with GNU folks who oversee the
mailing lists?

Or maybe how should do something to stop Mailman from mangling his
From address?

> In Gnus, when I say 'wide reply', it hoovers up 'From,To,CC,Reply-To',
> so that doesnʼt bother me. I donʼt know what rmail does, hence my
> question.

Rmail does the same, in general.

> Maybe Drew needs a different MUA? :-)

Definitely, but that's out of our control.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Thu, 10 Sep 2020 18:03:20 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: ghe@sdf.org,  larsi@gnus.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
    >> Date: Thu, 10 Sep 2020 16:56:07 +0200
    >> 
    Eli> I don't think I understand what that means (never used Gnus, sorry),
    Eli> and don't remember the details of the issue.  But in general, why
    Eli> would someone need to set Reply-To to the list address when replying
    Eli> to a message from the list?  It should be automatic in any sensible
    Eli> MUA, no?
    >> 
    >> They wouldnʼt, but apparently Mailman sets 'Reply-To: ghe@sdf.org' on
    >> Gregory's behalf, which then causes Outlook to respond only to him.

    Eli> Then maybe Gregory should take this up with GNU folks who oversee the
    Eli> mailing lists?

Itʼs not (directly) under their control.

    Eli> Or maybe how should do something to stop Mailman from mangling his
    Eli> From address?

I donʼt think he can: thatʼs under the control of whoever looks after
the sdf.org domain setup.

Anyway, this is not really relevant to Emacs development anymore.

Robert

RE: Changes for emacs 28

[Drew Adams]

> Maybe Drew needs a different MUA? :-)

Maybe that ain't gonna happen. ;-)

RE: Changes for emacs 28

[Drew Adams]

>     Drew> [For some reason, when I do `Reply All' for your
>     Drew> messages emacs-devel is not in the To or CC list.
>     Drew> Had to send this again, adding emacs-devel explicitly.]
> 
> Gregory has a 'Reply-To' header which points at ghe@sdf.org. I guess
> your Outlook client honours it a bit too much

Thanks for the reply.

Maybe so.  I know nothing about such things, and
I don't really want to start fiddling with them.

Outlook "just works" for me, with lots of mailing
lists and lots of interlocutors.  I've seen this
problem only a few times, with a few correspondents.

IOW, "not my problem", at least not enough that
I'd care to try to fix it on my end.

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Maybe so.  I know nothing about such things, and
> I don't really want to start fiddling with them.
>
> Outlook "just works" for me, with lots of mailing
> lists and lots of interlocutors.  I've seen this
> problem only a few times, with a few correspondents.

You're going to see it more and more with mailing lists.  A person with
a strict SPF/DMARC policy (and that's getting more and more common) has
to have their From addresses rewritten by the mailing list software so
that the mail isn't tagged as spam, which is why (for instance)
Gregory's From header looks like:

From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>

The mailing list software puts the original From in the Reply-To header
after doing this rewrite, and if you have software that (on a "wide
reply") just sends the response to the Reply-To header, you end up in
this mess.

We all have to deal with the fallout of this debacle called "modern
email".  Fortunately, all the Emacs mail user agents all do the right
thing here, so it's normally not a problem, but if Outlook does
something insane (and when doesn't it?), you're going to have to adjust.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: Changes for emacs 28

[Drew Adams]

> >> and these options would be written in their .emacs file.
> >
> > Just a nit about this part.
> >
> > I really think we should get away from having Emacs fiddle with users'
> > init files.
> >
> > For Customize, we should encourage use of `custom-file'.
> 
> I agree with you that in general Emacs should better not fiddle with
> users' init files, but not in this particular case.  This would happen
> only for first-time users who, as I said, do not yet have a .emacs file /
> .emacs.d directory.  Populating that file / directory with the result of
> their choices during the initial "guided tour" makes perfect sense.  IOW,
> this would happen only the first time they start Emacs.

Even so.  It doesn't matter how or when or why Emacs
writes to a user's init file.  The effect is the same:
mixing automatic, programmatic edits with user edits
(even if there not yet any user edits).

It's fine, IMO, for Emacs to prompt for where to record
something.

It could even be OK (but not as nice) for Emacs to
automatically put something in a file in ~/.emacs.d, as
the default directory for something.

What I think is not OK is for Emacs to put stuff in a
user's init file, whether that be the default location
and name of an init file or an init file with some other
location and name.

`custom-file' is the right place for Customize to put
and edit stuff.  For what you propose, some other file
can be chosen.  It just shouldn't be a file that is
intended for user editing - in particular, the user's
init file.

Re: Changes for emacs 28

[Juri Linkov]

> During that "guided tour" the user could select a number of options,
> e.g. cua-mode, evil-mode, which-key, hl-line, show-paren-mode, a theme

+1  For each profile (a combination of the most popular features)
show a screenshot, short description and checkbox "Enable".

Re: Changes for emacs 28

[Juri Linkov]

>> During that "guided tour" the user could select a number of options,
>> e.g. cua-mode, evil-mode, which-key, hl-line, show-paren-mode, a theme
>
> +1  For each profile (a combination of the most popular features)
> show a screenshot, short description and checkbox "Enable".

That means that like Custom-save adds the saved variable/value to the
init/custom file, enabling this checkbox should add 'use-package' to the
init file (and evaluate it immediately).

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Would it not be better to have a "guided tour" (something like C-h t, but 
  > shorter and more "modern") for first-time users (those without a .emacs / 
  > .emacs.d)?  This is quite common in "modern" software, so it would not 
  > surprise anyone.

We discussed this a few months ago and it turned out someone had made
such a tour.  I can't recall whether we could, or could not, make use of it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Yoni Rabkin]

Ergus <spacibba@aol.com> writes:

> I am NOT telling we should do all this, but this is what a young user
> expects because all these is more or less standard everywhere else.

I appreciate you enthusiasm for making Emacs popular. Thank you for
that.

However, it is always jarring to me to see free software developers
arguing over features none of them like or want, and instead trying to
"prove" to the other that a hypothetical third person would really like
those features. This supposed "young user" is a pretend person; they
don't exist. People ascribe whatever properties they want to the poor
hypothetical "young user" and then argue that those properties require a
change in Emacs. I disagree with this approach because I think that real
people and their preferences are more complicated and subtle than any
person we can make up as a tool to back an argument.

If you want these features yourself then you should add them (I don't
mean that in a sarcastic way at all). Your enthusiasm for creating and
maintaining these features will appeal to others who want similar
features. We all know and love this way of development in the free
software development world. This way assures that at least one real
person's needs are being met.

If you don't want these features yourself and nobody else in the project
wants them either, the only way I can think of making a compelling
argument for people to develop those feature is to ask real people and
get real responses. I am fairly confident that if you had a testimony or
user-test from actual people stating that a feature is missing, then
people here would help develop that feature.

I develop Emacs extensions (Emms, rt-liberation in GNU ELPA, and others
outside of it). I never try to guess what a hypothetical person wants
from Emms, but I do actively solicit requests and suggestions from
anyone I can, and when someone cares enough to ask for a feature, I do
everything I can to add it. Indeed, Emms has several extensions and
modes that I never use and can't even wrap my head around why people
like. But real people asked for them, so they are there.

-- 
   "Cut your own wood and it will warm you twice"

Re: Changes for emacs 28

[Ergus]

On Mon, Sep 07, 2020 at 09:58:32AM -0400, Yoni Rabkin wrote:
>
>Ergus <spacibba@aol.com> writes:
>
>> I am NOT telling we should do all this, but this is what a young user
>> expects because all these is more or less standard everywhere else.
>
>I appreciate you enthusiasm for making Emacs popular. Thank you for
>that.
>
>However, it is always jarring to me to see free software developers
>arguing over features none of them like or want, and instead trying to
>"prove" to the other that a hypothetical third person would really like
>those features. This supposed "young user" is a pretend person; they
>don't exist. People ascribe whatever properties they want to the poor
>hypothetical "young user" and then argue that those properties require a
>change in Emacs. I disagree with this approach because I think that real
>people and their preferences are more complicated and subtle than any
>person we can make up as a tool to back an argument.
>
The post actually started not for adding new features, but just to
change some of our defaults. Actually one thing I don't like about doom
or spacemacs is the excessive complexity they add and long configuration
sets.

When I recommend Emacs to any of my students; after a week trying it
they finally go for VSCode or sublime and they get the work done in an
hour.

Actually I have this config I share with them with only vanilla features:

https://github.com/Ergus/mini_dotemacs

And so far I could convince at least some of them this year.

>If you want these features yourself then you should add them (I don't
>mean that in a sarcastic way at all). Your enthusiasm for creating and
>maintaining these features will appeal to others who want similar
>features. We all know and love this way of development in the free
>software development world. This way assures that at least one real
>person's needs are being met.
>
Again, are not features the "issue", but some "bad" defaults. If there
come out specific features I will try (as I am doing actually with
vertical-icomplete or highlight-completions).

The question to the developers was about defaults we would be willing to
change and which are whiten in stone.

>If you don't want these features yourself and nobody else in the project
>wants them either, the only way I can think of making a compelling
>argument for people to develop those feature is to ask real people and
>get real responses. I am fairly confident that if you had a testimony or
>user-test from actual people stating that a feature is missing, then
>people here would help develop that feature.
>
Actually as mentioned before, the existence of doom emacs, spacemacs and
all the other configs (some of them more popular than vanilla these
days) is a proof.

>I develop Emacs extensions (Emms, rt-liberation in GNU ELPA, and others
>outside of it). I never try to guess what a hypothetical person wants
>from Emms, but I do actively solicit requests and suggestions from
>anyone I can, and when someone cares enough to ask for a feature, I do
>everything I can to add it. Indeed, Emms has several extensions and
>modes that I never use and can't even wrap my head around why people
>like. But real people asked for them, so they are there.
>
I am adding changes to completions and icomplete while I use ivy.

>-- 
>   "Cut your own wood and it will warm you twice"

Re: Changes for emacs 28

[Yoni Rabkin]

Ergus <spacibba@aol.com> writes:

> On Mon, Sep 07, 2020 at 09:58:32AM -0400, Yoni Rabkin wrote:
>>
>>Ergus <spacibba@aol.com> writes:
>>
>>> I am NOT telling we should do all this, but this is what a young user
>>> expects because all these is more or less standard everywhere else.
>>
>>I appreciate you enthusiasm for making Emacs popular. Thank you for
>>that.
>>
>>However, it is always jarring to me to see free software developers
>>arguing over features none of them like or want, and instead trying to
>>"prove" to the other that a hypothetical third person would really like
>>those features. This supposed "young user" is a pretend person; they
>>don't exist. People ascribe whatever properties they want to the poor
>>hypothetical "young user" and then argue that those properties require a
>>change in Emacs. I disagree with this approach because I think that real
>>people and their preferences are more complicated and subtle than any
>>person we can make up as a tool to back an argument.
>>
> The post actually started not for adding new features, but just to
> change some of our defaults. Actually one thing I don't like about doom
> or spacemacs is the excessive complexity they add and long configuration
> sets.

Configuration defaults, configurability, and features are
interchangeable in this discussion.

> When I recommend Emacs to any of my students; after a week trying it
> they finally go for VSCode or sublime and they get the work done in an
> hour.

That's an interesting initial point, but I don't follow the leap you
made since there are no details. You are trying to make a strong point
in comparing a week of failure to an hour of success. But unfortunately
that doesn't explain what needs to be changed.

> Actually I have this config I share with them with only vanilla features:
>
> https://github.com/Ergus/mini_dotemacs
>
> And so far I could convince at least some of them this year.

Convince to do what? Have they been convinced to move to Emacs as a
development platform going forward? To use Emacs just for the course? To
value software freedom?

Conversely, if they used "sublime" (which I assume is an editor) for
that university course, does that mean that they have rejected software
freedom in some way? Does that mean they are now life-long sublime
users? Do they also read their email, browse the web, listen to music,
watch videos, and interface with task-management systems via sublime?

I hope those questions don't come across as badgering. Instead, I'm
trying to point out that the conclusions you've come to aren't implied
by the information you've provided.

If you've found a way to provide a popular configuration for Emacs for
your university environment, it may make sense to package that and make
it easy to install. After all, the power of Emacs is in what it can
become, as opposed to what it is when you load it.


>>If you want these features yourself then you should add them (I don't
>>mean that in a sarcastic way at all). Your enthusiasm for creating and
>>maintaining these features will appeal to others who want similar
>>features. We all know and love this way of development in the free
>>software development world. This way assures that at least one real
>>person's needs are being met.
>>
> Again, are not features the "issue", but some "bad" defaults. If there
> come out specific features I will try (as I am doing actually with
> vertical-icomplete or highlight-completions).
>
> The question to the developers was about defaults we would be willing
> to change and which are whiten in stone.

The loud introduction screen to Emacs is what made me aware of the
existence of the free software movement about 20 years ago. It would not
be hyperbole to say that particular default changed the course of my
life.

If there is such a thing as an ideal default for Emacs, it would be
being presented with a screen that succinctly explains the free software
movement and the endless possibilities of Emacs as a platform.

I would try to argue for a robust and easy way for you to be able to
provide people with the kind of setup for Emacs that you are obviously
enthusiastic about, regardless of how Emacs loads. If you can't do that,
then to my mind Emacs is indeed missing something.


>>If you don't want these features yourself and nobody else in the project
>>wants them either, the only way I can think of making a compelling
>>argument for people to develop those feature is to ask real people and
>>get real responses. I am fairly confident that if you had a testimony or
>>user-test from actual people stating that a feature is missing, then
>>people here would help develop that feature.
>>
> Actually as mentioned before, the existence of doom emacs, spacemacs and
> all the other configs (some of them more popular than vanilla these
> days) is a proof.

I'm unsure of what you mean by that. If those have features that GNU
Emacs doesn't and that you want, then you should port them
over. Unfortunately, I have a feeling we may be talking past each other
on this point.

-- 
   "Cut your own wood and it will warm you twice"

Re: Changes for emacs 28

[Ergus]

On Mon, Sep 07, 2020 at 11:19:44AM -0400, Yoni Rabkin wrote:
>Ergus <spacibba@aol.com> writes:
>
>
>Configuration defaults, configurability, and features are
>interchangeable in this discussion.
>
No, they aren't. New features need to be implemented new defaults is
actually something that comes out of the box.

>
>That's an interesting initial point, but I don't follow the leap you
>made since there are no details. You are trying to make a strong point
>in comparing a week of failure to an hour of success. But unfortunately
>that doesn't explain what needs to be changed.
>
This was just an example and a personal anecdote to show that some
better defaults are possible without too much effort to "attract" fresh
blood to emacs.

>
>Convince to do what? Have they been convinced to move to Emacs as a
>development platform going forward? To use Emacs just for the course? To
>value software freedom?
>
As of today people start appreciating free software if they see it is
useful. If they go for geany or vim it is also free software, but as
emacs developers we should be concerned why if this becomes frequent
pattern (that people try and not stay enough to discover the rest).

>Conversely, if they used "sublime" (which I assume is an editor) for
>that university course, does that mean that they have rejected software
>freedom in some way? Does that mean they are now life-long sublime
>users? Do they also read their email, browse the web, listen to music,
>watch videos, and interface with task-management systems via sublime?
>
FWIS people come to emacs looking for the basic feature: an editor (with
steroids).

If that is no as satisfying as they expect (or has disadvantages over
gedit, sublime or any other, or require 300 lines of configurations for
the basics) then they don't stay enough to discover the rest.

>I hope those questions don't come across as badgering. Instead, I'm
>trying to point out that the conclusions you've come to aren't implied
>by the information you've provided.
>
>If you've found a way to provide a popular configuration for Emacs for
>your university environment, it may make sense to package that and make
>it easy to install. After all, the power of Emacs is in what it can
>become, as opposed to what it is when you load it.
>
>
Yes, but it doesn't mean that we have to provide the worst possible
defaults.
>
>I would try to argue for a robust and easy way for you to be able to
>provide people with the kind of setup for Emacs that you are obviously
>enthusiastic about, regardless of how Emacs loads. If you can't do that,
>then to my mind Emacs is indeed missing something.
>
That's the point. Emacs can do so (and much more) but users need to stay
enough to discover that, learn the environment and so on. I was just
talking about THAT first impression to keep them more than 10 minute and
think it worth cross the barrier if the new bindings, no right click for
everything and so on.

>
>I'm unsure of what you mean by that. If those have features that GNU
>Emacs doesn't and that you want, then you should port them
>over. Unfortunately, I have a feeling we may be talking past each other
>on this point.
>
>-- 
>   "Cut your own wood and it will warm you twice"

Re: Changes for emacs 28

[Mario Lang]

Ergus <spacibba@aol.com> writes:

> Actually as mentioned before, the existence of doom emacs, spacemacs and
> all the other configs (some of them more popular than vanilla these
> days) is a proof.

Actually, popularity is not the only measure of quality, if at all.
If popularity were all that counts, we would all be listening to Lady
Gaga and there would be no need for any other music.

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If you don't want these features yourself and nobody else in the project
  > wants them either, the only way I can think of making a compelling
  > argument for people to develop those feature is to ask real people and
  > get real responses. I am fairly confident that if you had a testimony or
  > user-test from actual people stating that a feature is missing, then
  > people here would help develop that feature.

I agree.  Before we put time into developing a feature, we should verify
that many people would like it.

Speaking of which, it would be useful to sit down with a new user just
trying Emacs and see what perse actually complains about or requests.
If several people do this, it could give us useful ideas of what changes
would actually make Emacs more appealing to new users.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Ihor Radchenko]

> Speaking of which, it would be useful to sit down with a new user just
> trying Emacs and see what perse actually complains about or requests.
> If several people do this, it could give us useful ideas of what changes
> would actually make Emacs more appealing to new users.

There are three main things I spotted when guiding a new
(non-programmer) user getting started with Emacs (for org-mode):

1. The welcome screen has too much information and new user simply
ignores it

2. CUA mode is not offered by default and it is not easy for a new user
to know about its existence (because of previous point)

3. File opening dialogue is completely throwing the new user off -
people are too used to pop-up file opening dialogue listing all the
files. The message area is even not noticed.

More details and my suggestion on what can be done in my earlier
messages:
https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00335.html
https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00359.html

I will also attach the message texts below for convenience:

Message 1:
----------

While I agree that the existing Emacs defaults are reasonable in
general, I do not think that they are good for users coming from an
arbitrary background.

Emacs is a very versatile tool and can be used for programming, creative
writing, research, note-taking, todo management, and many more different
fields. I do not think that a single set of defaults can satisfy users
aiming for every single use-case. Moreover, changes required to tweak
Emacs towards a specific use-case are often much more than "just takes a
moment". No surprise that we have a whole spectrum of Emacs startup kits,
which offer predefined set of tweaks for different styles of using
Emacs.

I do think that the existing Emacs defaults are a good starting point
for a new user with unknown workflows. They are generic enough to tweak
Emacs in any possible direction. However, I believe that it would be a
good option to have several sets of defaults, which would better fit
some common use-cases, like programming, note-taking, tramp, git, etc.
Then, the existing defaults will represent "Generic" use-case, but a new
user (who may or may not have programming background) might easily
select other set of defaults, which is more suitable for the user's
background and expected use-cases.

Message 2:
------------

> It would be nice if people came up with
> an idea as to how exactly this functionality is to be implemented, 
> and a
> set of better usecases than just 'programming' or 'note-taking' or
> 'TRAMP' or 'git'.

As one possibility, we can try to extend "A guided tour to Emacs" and
make it more interactive.

Some thoughts:
1. The link to the tour in the welcome page is not easy to spot for a
new user. There is too much information. I might be better to show it by
default on first startup after installation.
2. Currently, the tour is one long web-page, which is not very easy to
read. I imagine that a presentation-like style (with prev/next buttons
on each page) showing one concept at a time would be easier to read.
3. The tour may as well include interactive customisation. For example,
'Migrating to Emacs' part of the tour may as well contain a clickable
element to turn on CUA mode by default.
4. The tour might ask user questions if the user is going to work with
source code, email, web-browsing, shell, etc. If the user is not
planning to work with certain things, they may as well be hidden from
menu and customisation pages. By hidden I don't mean completely hidden,
but rather "folded" - the user should be able to show them back.
For a newcomer, Emacs offers very too many different options. I believe
that it makes more sense to restrict the customisation and menus to what
user explicitly plans to do. It should be already more than enough to
start learning.
5. Similar guided tours may be created for most popular Emacs features:
   - working with source code
   - org-mode
   - version-control and collaboration
   - remote file access
   - mail
   Those tours might also offer some initial customisation, so that the
   user may disable/enable some features which are not relevant to
   his/her workflow.
   The guides should be easily accessible from menu.
6. Some new users might be confused by default file open dialogie
involving mode-line. I believe that similarly to CUA-mode, Emacs can
emulate more standard approach by offering dired as a way to open files
(not enabled by default, but offered as a customisation together with
CUA-mode).

Best,
Ihor


Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > If you don't want these features yourself and nobody else in the project
>   > wants them either, the only way I can think of making a compelling
>   > argument for people to develop those feature is to ask real people and
>   > get real responses. I am fairly confident that if you had a testimony or
>   > user-test from actual people stating that a feature is missing, then
>   > people here would help develop that feature.
>
> I agree.  Before we put time into developing a feature, we should verify
> that many people would like it.
>
> Speaking of which, it would be useful to sit down with a new user just
> trying Emacs and see what perse actually complains about or requests.
> If several people do this, it could give us useful ideas of what changes
> would actually make Emacs more appealing to new users.
>
> -- 
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

RE: Changes for emacs 28

[Drew Adams]

> 3. File opening dialogue is completely throwing the new user off -
> people are too used to pop-up file opening dialogue listing all the
> files. The message area is even not noticed.

> 6. Some new users might be confused by default file open dialogie
> involving mode-line. I believe that similarly to CUA-mode, Emacs can
> emulate more standard approach by offering dired as a way to open files
> (not enabled by default, but offered as a customisation together with
> CUA-mode).

Doesn't menu File > Open File do what you request,
by default?  Likewise, other file operations, such
as File > Insert File, File > Save As, and File >
Open Directory.

On MS Windows, for example, this just uses the usual
Windows file selection dialog box.

This depends on the value of option `use-file-dialog',
but that's `t' by default (as is `use-dialog-box').

 "Non-nil means mouse commands use a file dialog to ask for files.
  This applies to commands from menus and tool bar buttons even when
  they are initiated from the keyboard.  If 'use-dialog-box' is nil,
  that disables the use of a file dialog, regardless of the value of
  this variable."

https://www.gnu.org/software/emacs/manual/html_node/emacs/Dialog-Boxes.html

RE: Changes for emacs 28

[Ihor Radchenko]

> Doesn't menu File > Open File do what you request,
> by default?  Likewise, other file operations, such
> as File > Insert File, File > Save As, and File >
> Open Directory.

Hmm. You are right. I thought that the problem was with Emacs defaults,
but it seems to be a problem with helm, which I asked to install at the
very beginning - it appears to override the file dialogue.

Best,
Ihor


Drew Adams <drew.adams@oracle.com> writes:

>> 3. File opening dialogue is completely throwing the new user off -
>> people are too used to pop-up file opening dialogue listing all the
>> files. The message area is even not noticed.
>
>> 6. Some new users might be confused by default file open dialogie
>> involving mode-line. I believe that similarly to CUA-mode, Emacs can
>> emulate more standard approach by offering dired as a way to open files
>> (not enabled by default, but offered as a customisation together with
>> CUA-mode).
>
> Doesn't menu File > Open File do what you request,
> by default?  Likewise, other file operations, such
> as File > Insert File, File > Save As, and File >
> Open Directory.
>
> On MS Windows, for example, this just uses the usual
> Windows file selection dialog box.
>
> This depends on the value of option `use-file-dialog',
> but that's `t' by default (as is `use-dialog-box').
>
>  "Non-nil means mouse commands use a file dialog to ask for files.
>   This applies to commands from menus and tool bar buttons even when
>   they are initiated from the keyboard.  If 'use-dialog-box' is nil,
>   that disables the use of a file dialog, regardless of the value of
>   this variable."
>
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Dialog-Boxes.html

Re: Changes for emacs 28

[tomas]

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

On Tue, Sep 08, 2020 at 01:33:24PM +0800, Ihor Radchenko wrote:
> > Doesn't menu File > Open File do what you request,
> > by default? [...]

> Hmm. You are right. I thought that the problem was with Emacs defaults,
> but it seems to be a problem with <package> [...]

I'm sure there are a couple of things to learn from this, although
I can't quite put my finger on it. A try:

 - versatility vs. user experience fragmentation?
 - ease/difficulty of moving between Emacs "subworlds"?
 - opinionated/authoritarian vs. permissive/loosey-goosey?

Does software have a pedagogical duty? If yes, which one?

I think those questions have some relationship with Gnu's core values,
somehow.

Sorry for being so fuzzy.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: Changes for emacs 28

[Drew Adams]

> > Doesn't menu File > Open File do what you request,
> > by default?  Likewise, other file operations, such
> > as File > Insert File, File > Save As, and File >
> > Open Directory.
> 
> Hmm. You are right. I thought that the problem was with Emacs defaults,
> but it seems to be a problem with helm, which I asked to install at the
> very beginning - it appears to override the file dialogue.

Thanks for confirming.

In several cases, though it may not be systematic,
Emacs default behavior tries to present, by way of
menus, something closer to what new users might be
used to.  Another example is Edit > Cut|Copy|Paste.

CUA-mode is about keyboard-key (not menu) behavior.
And in general Emacs default key bindings are
closer to what most Emacs users use, as opposed to
what new users might be used to.

There's always room for improvement.  And indeed,
the menus have improved in this way over time, to
be more accommodating to new users.

Menus are an important way to discover features
and, yes, key bindings.  They can be a gateway to
more "emacsy" behavior.
____

In terms of discovering with menus, and at the
same time seeing the power/utility of keyboard
key bindings (completion, in particular), there
is library La Carte.

https://www.emacswiki.org/emacs/LaCarte

And vanilla Emacs has `tmm-menubar' (M-`).

RE: Changes for emacs 28

[Ihor Radchenko]

> There's always room for improvement.  And indeed,
> the menus have improved in this way over time, to
> be more accommodating to new users.
>
> Menus are an important way to discover features
> and, yes, key bindings.  They can be a gateway to
> more "emacsy" behavior.

Would it make sense to re-evaluate Xah Lee's suggestions about menu?
http://ergoemacs.org/emacs/modernization_menu.html

Best,
Ihor

Drew Adams <drew.adams@oracle.com> writes:

>> > Doesn't menu File > Open File do what you request,
>> > by default?  Likewise, other file operations, such
>> > as File > Insert File, File > Save As, and File >
>> > Open Directory.
>> 
>> Hmm. You are right. I thought that the problem was with Emacs defaults,
>> but it seems to be a problem with helm, which I asked to install at the
>> very beginning - it appears to override the file dialogue.
>
> Thanks for confirming.
>
> In several cases, though it may not be systematic,
> Emacs default behavior tries to present, by way of
> menus, something closer to what new users might be
> used to.  Another example is Edit > Cut|Copy|Paste.
>
> CUA-mode is about keyboard-key (not menu) behavior.
> And in general Emacs default key bindings are
> closer to what most Emacs users use, as opposed to
> what new users might be used to.
>
> There's always room for improvement.  And indeed,
> the menus have improved in this way over time, to
> be more accommodating to new users.
>
> Menus are an important way to discover features
> and, yes, key bindings.  They can be a gateway to
> more "emacsy" behavior.
> ____
>
> In terms of discovering with menus, and at the
> same time seeing the power/utility of keyboard
> key bindings (completion, in particular), there
> is library La Carte.
>
> https://www.emacswiki.org/emacs/LaCarte
>
> And vanilla Emacs has `tmm-menubar' (M-`).

RE: Changes for emacs 28

[Stefan Kangas]

Ihor Radchenko <yantar92@gmail.com> writes:

> Would it make sense to re-evaluate Xah Lee's suggestions about menu?
> http://ergoemacs.org/emacs/modernization_menu.html

These proposals look relevant to me, I think we should examine them in
more detail.  Could you submit that as a new bug report?

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 9 Sep 2020 07:35:37 -0700
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> 
> Ihor Radchenko <yantar92@gmail.com> writes:
> 
> > Would it make sense to re-evaluate Xah Lee's suggestions about menu?
> > http://ergoemacs.org/emacs/modernization_menu.html
> 
> These proposals look relevant to me, I think we should examine them in
> more detail.

Beware: they are outdated (more than 10 years old, and many items in
our menus were changed since then).  More importantly, Xah is known
to be violently anti-FSF/GNU, and even anti-RMS, let alone full of NIH
tendencies.  His recommendations are rarely provided with any
rationale except "the current situation is silly/stupid", and should
therefore be taken with a grain of salt.

That said, it is of course okay to consider the ideas that make sense,
but not just "because Xah said so".

> Could you submit that as a new bug report?

Separate bug reports for each item or a group of related items,
please.  Let's not have one bug report about dozens of menu items
unrelated to each other.

Re: Changes for emacs 28

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Could you submit that as a new bug report?
>
> Separate bug reports for each item or a group of related items,
> please.  Let's not have one bug report about dozens of menu items
> unrelated to each other.

Indeed, thanks for pointing that out!

> Beware: they are outdated (more than 10 years old, and many items in
> our menus were changed since then).  More importantly, Xah is known
> to be violently anti-FSF/GNU, and even anti-RMS, let alone full of NIH
> tendencies.  His recommendations are rarely provided with any
> rationale except "the current situation is silly/stupid", and should
> therefore be taken with a grain of salt.
>
> That said, it is of course okay to consider the ideas that make sense,
> but not just "because Xah said so".

Thanks for explaining the background.

If someone does look over that list, they should check to see which are
still relevant and provide some rationale for the change.

Re: Changes for emacs 28

[Ihor Radchenko]

>> Beware: they are outdated (more than 10 years old, and many items in
>> our menus were changed since then).  More importantly, Xah is known
>> to be violently anti-FSF/GNU, and even anti-RMS, let alone full of NIH
>> tendencies.  His recommendations are rarely provided with any
>> rationale except "the current situation is silly/stupid", and should
>> therefore be taken with a grain of salt.
>>
>> That said, it is of course okay to consider the ideas that make sense,
>> but not just "because Xah said so".
> Thanks for explaining the background.
>
> If someone does look over that list, they should check to see which are
> still relevant and provide some rationale for the change.

That article is mostly reasonable, except some rants about FSF
"advertisement". I will double check with latest Emacs menu and split
the relevant suggestions from the article into separate bug reports.

Best,
Ihor




Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Could you submit that as a new bug report?
>>
>> Separate bug reports for each item or a group of related items,
>> please.  Let's not have one bug report about dozens of menu items
>> unrelated to each other.
>
> Indeed, thanks for pointing that out!
>
>> Beware: they are outdated (more than 10 years old, and many items in
>> our menus were changed since then).  More importantly, Xah is known
>> to be violently anti-FSF/GNU, and even anti-RMS, let alone full of NIH
>> tendencies.  His recommendations are rarely provided with any
>> rationale except "the current situation is silly/stupid", and should
>> therefore be taken with a grain of salt.
>>
>> That said, it is of course okay to consider the ideas that make sense,
>> but not just "because Xah said so".
>
> Thanks for explaining the background.
>
> If someone does look over that list, they should check to see which are
> still relevant and provide some rationale for the change.

Re: Changes for emacs 28

[Eric S Fraga]

On Wednesday,  9 Sep 2020 at 18:20, Eli Zaretskii wrote:
> His recommendations are rarely provided with any rationale except "the
> current situation is silly/stupid", and should therefore be taken with
> a grain of salt.

My experience entirely and he's rather quick to insult if you disagree.
-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: Changes for emacs 28

[Ihor Radchenko]

>> His recommendations are rarely provided with any rationale except "the
>> current situation is silly/stupid", and should therefore be taken with
>> a grain of salt.
>
> My experience entirely and he's rather quick to insult if you disagree.

FYI, When sharing the link, I did not imply that suggestions should be
accepted "because Xah said so". I did imply that they are worth
reviewing, because I found many of the suggestions in that article
reasonable. Regardless of the author.

Instead of discussing the author of the article, it would be better to
discuss concrete suggestions proposed there (or better wait a little
until I split them into separate bug reports and discuss one-by-one).

Best,
Ihor

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Wednesday,  9 Sep 2020 at 18:20, Eli Zaretskii wrote:
>> His recommendations are rarely provided with any rationale except "the
>> current situation is silly/stupid", and should therefore be taken with
>> a grain of salt.
>
> My experience entirely and he's rather quick to insult if you disagree.
> -- 
> Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Tramp defaults (was: Changes for emacs 28)

[Michael Albinus]

Ihor Radchenko <yantar92@gmail.com> writes:

Hi,

> I do think that the existing Emacs defaults are a good starting point
> for a new user with unknown workflows. They are generic enough to tweak
> Emacs in any possible direction. However, I believe that it would be a
> good option to have several sets of defaults, which would better fit
> some common use-cases, like programming, note-taking, tramp, git, etc.
> Then, the existing defaults will represent "Generic" use-case, but a new
> user (who may or may not have programming background) might easily
> select other set of defaults, which is more suitable for the user's
> background and expected use-cases.

It has been mentioned several times in the past that there shall be
better (or other) Tramp defaults. But I haven't seen proposals.

For sure I'm biased, but I believe the current Tramp defaults are suited
for the majority of users. Could people pls tell me where I'm wrong with
this? What other Tramp defaults are better?

And promised, I'm willing to accept proper changes.

> 5. Similar guided tours may be created for most popular Emacs features:
>    - working with source code
>    - org-mode
>    - version-control and collaboration
>    - remote file access
>    - mail
>    Those tours might also offer some initial customisation, so that the
>    user may disable/enable some features which are not relevant to
>    his/her workflow.
>    The guides should be easily accessible from menu.

Hard to do. Remote file access is different for everybody, because
everybody uses another remote host. I'm lacking on ideas what such a
guided tour for remote access shall show (except the simple
recommendation "write /ssh:user@host:/path/to/file instead of /path/to/file").

Proposals welcome!

> Best,
> Ihor

Best regards, Michael.

Re: Tramp defaults (was: Changes for emacs 28)

[Ihor Radchenko]

>> ... However, I believe that it would be a
>> good option to have several sets of defaults, which would better fit
>> some common use-cases, like programming, note-taking, tramp, git, etc.
>> Then, the existing defaults will represent "Generic" use-case, but a new
>> user (who may or may not have programming background) might easily
>> select other set of defaults, which is more suitable for the user's
>> background and expected use-cases.

> It has been mentioned several times in the past that there shall be
> better (or other) Tramp defaults. But I haven't seen proposals.

Sorry. My writing was probably not clear enough.

I am not proposing to decide on concrete "better defaults" at this
point. Looking at multiple threads discussing the defaults, there will
be no agreement on this. Instead, I propose to create a general
framework allowing people to create such defaults (maybe multiples of
defaults):

1. Change the welcome screen highlighting "User guide" for new users
2. Upgrade "User guide" to be more like "presentation" or "configuration
   wizard". Basically, I propose to make "User guide" interactive and
   splitted into multiple slides/pages:
   a. Introduction page describing how Emacs is different from
   mainstream editors. Something in like the following (not necessary
   literally, I am just describing the idea):

   ---------
   You are about to dive into one of the most powerful and the oldest
   text editing tools - GNU Emacs.

   Many of the commonly used concepts existing in modern (and younger)
   text editors were first introduced here.

   Many Emacs concepts are not used so commonly though. They can be
   powerful in experienced hands but require time (sometimes a lot of
   time) to master.

   In the following slides, we will go through some important concepts
   existing in Emacs, which are different from what you may be used to.
   
   We encourage you to use these Emacs concepts, but will also offer
   more familiar (but less powerful in long term) alternatives

   <prev>                                                       <next>
   --------
   Copy/Paste concepts
   
   Unlike other editors, Emacs does not use C-c/C-v bindings to
   copy/paste text. At the time C-c/C-v became a standard Emacs already
   had conflicting standards for these key-bindings.

   <talk about M-w/C-y>

   If you wish to use the C-c/C-v bindings anyway (and miss on some more
   advanced features), you can turn on "cua-mode" below

   [ ] <Interactive checkbox enabling cua-mode>

   You can always return to superior Emacs bindings from <Options menu>

   <prev>                                                         <next>

   <...>
   <Similar slides describing key differences of Emacs and allowing 
   changing defaults to more common settings>

   b. Customisation page allowing user to select the intended
   functionality. Here, the user can chose "configuration bundles"
   optimised for specific use-cases

   ---------
   Emacs is very powerful piece of software where you can find pretty
   much any feature you may imagine (and many feature you never thought
   of).

   However, the large number of features is also a disadvantage: you
   will most likely be lost in all the possibilities you can choose from.

   As you are just getting started with Emacs, you may choose the types
   of workflows you are interested in. Unrelated features will be hidden
   from the interface to reduce possible confusion. If you wish to, you
   may still access the hidden features in "Other" menu items or "Other"
   sections of customisation interface.

   [ ] <Checkbox to be checked if you want to hide confusing elements
        for now>
   
   In the following slides we will go through specific common workflows,
   you may want to enable/disable. The options relevant to the chosen
   workflows will not be hidden.

   <prev>                                                       <next>

   The next slides should go through the main sections of Emacs manual
   (maybe also including theme selection).
   Each section will be represented by the following (maybe in multiple
   slides):
   - short description of the section
   - this slide should have a button "do not plan to use", skipping all
      other relevant slides and hiding menu and cusomisation options.
      By hiding, I mean grouping the relevant menu options into "Other"
      sub-menu and moving the relevant customisation groups/options into
      "Other" group
   - slides showing common workflows for the section. For example,
     org-mode section may have "Agenda" and "Outlining" slides
     describing different things user may do in org-mode. In "agenda"
     user may be offered to check/uncheck tracking TODO changes (which
     is disabled by default) depending how they prefer to do planning
     (if they care about it): (1) Via journal notes; (2) Via agenda
     views.
     
3. Provide interface for "hiding" less common customisations/menu items
   from the user:
   - unimportant menu items can be moved to "Other" sub-menus
   - unimportant customisations/customisation groups can be moved under
     "Other" sub-group

   The "unimportant" customisation means the following:
   1. Not frequently-used
   2. But also not chosen as important within the "workflow" selected by
      user in the above slides.

   Of course, this feature is only enabled if the user actually went
   through the above slides and chose to hide "confusing options"

The individual "better defaults" are better to be discussed when
creating the relevant slides. This whole thing will go nowhere if we
discuss those details right now. First, it would be better to have the
framework creating the slides and hiding irrelevant options.

Best,
Ihor


Michael Albinus <michael.albinus@gmx.de> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
> Hi,
>
>> I do think that the existing Emacs defaults are a good starting point
>> for a new user with unknown workflows. They are generic enough to tweak
>> Emacs in any possible direction. However, I believe that it would be a
>> good option to have several sets of defaults, which would better fit
>> some common use-cases, like programming, note-taking, tramp, git, etc.
>> Then, the existing defaults will represent "Generic" use-case, but a new
>> user (who may or may not have programming background) might easily
>> select other set of defaults, which is more suitable for the user's
>> background and expected use-cases.
>
> It has been mentioned several times in the past that there shall be
> better (or other) Tramp defaults. But I haven't seen proposals.
>
> For sure I'm biased, but I believe the current Tramp defaults are suited
> for the majority of users. Could people pls tell me where I'm wrong with
> this? What other Tramp defaults are better?
>
> And promised, I'm willing to accept proper changes.
>
>> 5. Similar guided tours may be created for most popular Emacs features:
>>    - working with source code
>>    - org-mode
>>    - version-control and collaboration
>>    - remote file access
>>    - mail
>>    Those tours might also offer some initial customisation, so that the
>>    user may disable/enable some features which are not relevant to
>>    his/her workflow.
>>    The guides should be easily accessible from menu.
>
> Hard to do. Remote file access is different for everybody, because
> everybody uses another remote host. I'm lacking on ideas what such a
> guided tour for remote access shall show (except the simple
> recommendation "write /ssh:user@host:/path/to/file instead of /path/to/file").
>
> Proposals welcome!
>
>> Best,
>> Ihor
>
> Best regards, Michael.

Re: Tramp defaults

[Michael Albinus]

Ihor Radchenko <yantar92@gmail.com> writes:

Hi Ihor,

> I am not proposing to decide on concrete "better defaults" at this
> point. Looking at multiple threads discussing the defaults, there will
> be no agreement on this. Instead, I propose to create a general
> framework allowing people to create such defaults (maybe multiples of
> defaults):

I do not oppose. But this doesn't give me yet an idea what to do wrt
Tramp concretely.

> Best,
> Ihor

Best regards, Michael.

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 1. The welcome screen has too much information and new user simply
  > ignores it

What Emacs version were you using?

  > 3. File opening dialogue is completely throwing the new user off -

Can you say concretely what you mean by "file opening dialogue"?  We
don't use the term "dialogue", and I can't see how it fits anything in
Emacs.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Ihor Radchenko]

>   > 1. The welcome screen has too much information and new user simply
>   > ignores it
>
> What Emacs version were you using?

I am on master.

Strictly speaking, it is not too much information (just single page),
but rather that the information does not look important. The guided tour
is grouped together with warranty and redistribution - things people
largely ignore.

I believe that it is better to put more emphasis on the guided tour (and
change the tour as I suggested in my email and later replying to the
request about tramp defaults with even more details).

Probably something like the following:

Welcome to GNU Emacs, one component of the GNU/Linux operating system.

    First time using Emacs? Check out how it is different from other
                             editors:
           <larger font> Emacs Guided Tour </larger font>
               (if you don't, you may be confused)
        
Emacs Tutorial	Learn basic keystroke commands
Emacs Guided Tour	Overview of Emacs features at gnu.org
<...>

>   > 3. File opening dialogue is completely throwing the new user off -
>
> Can you say concretely what you mean by "file opening dialogue"?  We
> don't use the term "dialogue", and I can't see how it fits anything in
> Emacs.

That point can be disregarded. Emacs uses graphical dialog (see
`use-file-dialog') when user tries to open file from menu or toolbar,
but I did not know it because helm overrides that behaviour. I filed bug
report in helm. The problem should be fixed now.

Best,
Ihor

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > 1. The welcome screen has too much information and new user simply
>   > ignores it
>
> What Emacs version were you using?
>
>   > 3. File opening dialogue is completely throwing the new user off -
>
> Can you say concretely what you mean by "file opening dialogue"?  We
> don't use the term "dialogue", and I can't see how it fits anything in
> Emacs.
>
> -- 
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Probably something like the following:

  > Welcome to GNU Emacs, one component of the GNU/Linux operating system.

  >     First time using Emacs? Check out how it is different from other
  >                              editors:
  >            <larger font> Emacs Guided Tour </larger font>
  >                (if you don't, you may be confused)
        
  > Emacs Tutorial	Learn basic keystroke commands
  > Emacs Guided Tour	Overview of Emacs features at gnu.org
  > <...>

That is a concrete suggestion.

Does anyone remember how the discusstion of that video tour ended?
Can we use it?


  > That point can be disregarded. Emacs uses graphical dialog (see
  > `use-file-dialog') when user tries to open file from menu or toolbar,
  > but I did not know it because helm overrides that behaviour. I filed bug
  > report in helm. The problem should be fixed now.

Thanks for that help.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Speaking of which, it would be useful to sit down with a new user just
> trying Emacs and see what perse actually complains about or requests.
> If several people do this, it could give us useful ideas of what changes
> would actually make Emacs more appealing to new users.

I don't think that's likely to result in anything very interesting,
really.

Looking at the runaway success of DOOM Emacs (or Spacemacs), they're
distributions created by people with a specific point of view, and with
a specific user interface vision in mind.  That can't be achieved by
a committee, and the results will be totally unsuitable for some people.

But I think that's what Emacs should support: Just like emacs-devel
doesn't bikeshed themes -- we just let whoever make them make them the
way they like, and then distribute the result -- we should create a way
to specify "layers", and then invite people to create them, without
micromanaging them.  And then distribute the result in vanilla Emacs,
but with an easy, obvious way for users to switch these "layers" on and
off.

I.e., I want the enthusiasm of these people making these distributions
to infect mainline Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Speaking of which, it would be useful to sit down with a new user just
  > > trying Emacs and see what perse actually complains about or requests.
  > > If several people do this, it could give us useful ideas of what changes
  > > would actually make Emacs more appealing to new users.

  > I don't think that's likely to result in anything very interesting,
  > really.

I learned useful things from it in the past.

  > Looking at the runaway success of DOOM Emacs (or Spacemacs), they're
  > distributions created by people with a specific point of view, and with
  > a specific user interface vision in mind.  That can't be achieved by
  > a committee,

I believe you, but I don't think that is a useful direction for us to go.

I'm thinking about improving specific aspects of the Emacs interface
to make incremental changes.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[João Távora]

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

On Sun, Sep 6, 2020 at 5:34 PM Ergus <spacibba@aol.com> wrote:

> Sorry but I can't understand why "old" users, that can write lisp lines
> easily to their configs, can't understand that for new users (and
> younger ones) those lines sometimes takes hours or days (mainly because
> they don't know what/where/how to look for, and lisp is not so
> popular or familiar these days). And that the first impression when they
> open emacs is like going back to 1998.

I think this is a very compelling argument.

I have to say that even as a "old" (oldish) user who has learned
to cherish the medieval Emacs defaults and would be slightly
annoyed at seeing some new defaults that I would have to configure
away.  But precisely like Ergus argues, that's kind of easy for me,
and not for newcomers.

This point comes up here so often that probably someone has
already suggested this silly idea:  Why not have a -1998
(or -1334 (; ) startup switch for the old timers?

João Távora

[-- Attachment #2: Type: text/html, Size: 1310 bytes --]

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This point comes up here so often that probably someone has
  > already suggested this silly idea:  Why not have a -1998
  > (or -1334 (; ) startup switch for the old timers?

I like the idea, but this should be something to set in .emacs,
not a command-line option.

Does the minus sign stand for BC?  I don't think Emacs existed in the
time of the Third Dynasty of Ur.  I developed the first Emacs
in Babylon in -1765.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Stefan Monnier]

> I developed the first Emacs in Babylon in -1765.

And according to Moore's law, the typical density of chips back then was
a teeny tiny fraction of transistor.


        Stefan

joke (was: Changes for emacs 28)

[andres.ramirez]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

    >> I developed the first Emacs in Babylon in -1765.
    Stefan> And according to Moore's law, the typical density of chips back then was a teeny tiny
    Stefan> fraction of transistor.

RMS: in what machine did you coded it? ;)

BR

Re: joke (was: Changes for emacs 28)

[tomas]

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

On Tue, Sep 08, 2020 at 03:54:03AM +0000, andres.ramirez wrote:
> >>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>     >> I developed the first Emacs in Babylon in -1765.
>     Stefan> And according to Moore's law, the typical density of chips back then was a teeny tiny
>     Stefan> fraction of transistor.
> 
> RMS: in what machine did you coded it? ;)

It must have been a one-bit, one-operation machine. The hardware must
have been a giant slab of sandstone.

OTOH, Babylonians are known for their love of sexagesimal; this leaves
us with a tough conundrum to solve.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: joke

[Ulrich Mueller]

>>>>> On Tue, 08 Sep 2020, <tomas@tuxteam.de> wrote:

> On Tue, Sep 08, 2020 at 03:54:03AM +0000, andres.ramirez wrote:
>> RMS: in what machine did you coded it? ;)

> It must have been a one-bit, one-operation machine. The hardware must
> have been a giant slab of sandstone.

ObXKCD: https://xkcd.com/505/ :)

Re: joke

[tomas]

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

On Tue, Sep 08, 2020 at 10:00:10AM +0200, Ulrich Mueller wrote:
> >>>>> On Tue, 08 Sep 2020, <tomas@tuxteam.de> wrote:
[...]
> > It must have been a one-bit, one-operation machine [...]

> ObXKCD: https://xkcd.com/505/ :)

:-)

thanks
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: joke (was: Changes for emacs 28)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > RMS: in what machine did you coded it? ;)

At first it was hand-simulated by scribes in training.  Then we
developed a clay-based precursor of the AI Lab's TTL (Tinker-Toy
Logic).

It was even slower than writing cuneiform.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > This point comes up here so often that probably someone has
>   > already suggested this silly idea:  Why not have a -1998
>   > (or -1334 (; ) startup switch for the old timers?
>
> I like the idea, but this should be something to set in .emacs,
> not a command-line option.

It must be a command-line option because when reproducing and fixing
bugs on Emacs, you very frequently have the need to run "a bare Emacs
-Q" frequently from a shell, devoid of any third-party packages that may
be interfering.  Maintainers would have to additionally specify the
--medieval switch to feel minimally confortable in that setting. It's
not possible to do this in the .emacs because Emacs -Q jumps that, by
definition.

Come to think of it, this is a bit of a counter argument against my
proposal: if we accept new defaults we must be ready to run Emacs -Q's
that have them.  If the new defaults are to include, say, vim-like
keybindings (ugh!), then maintainers are going to have lots of pain.  

This was a bit of an extreme example, but I guess what I'm saying is
that we should still criteriously choose new defaults.

> Does the minus sign stand for BC?  I don't think Emacs existed in the
> time of the Third Dynasty of Ur.  I developed the first Emacs
> in Babylon in -1765.

1334 was my lame attempt of spelling "leet" in "leetspeak", but I put a
4 instead of 7, i.e. I meant 1337.  Guess I'm not so leet after
all. Both sound suitably medieval, tho.

João

Re: Changes for emacs 28

[Alfred M. Szmidt]

This just reminds me of the -u USER option in Emacs.  It is n some
sense quite similar to the idea of "profiles".

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Come to think of it, this is a bit of a counter argument against my
  > proposal: if we accept new defaults we must be ready to run Emacs -Q's
  > that have them.  If the new defaults are to include, say, vim-like
  > keybindings (ugh!), then maintainers are going to have lots of pain.  

  > This was a bit of an extreme example, but I guess what I'm saying is
  > that we should still criteriously choose new defaults.

I agree, the changes in defaults must not be drastic.
But we might still find it useful to be able to specify
the defaults from version N if we don't like the subsequent changes.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> 5) Enable winmove and mouse-wheel-mode by default.

mouse-wheel-mode is already enabled by default on most graphical
displays.

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 03:06:18PM +0000, Stefan Kangas wrote:
>Ergus <spacibba@aol.com> writes:
>
>> 5) Enable winmove and mouse-wheel-mode by default.
>
>mouse-wheel-mode is already enabled by default on most graphical
>displays.
>
Right!... btw why not in the terminal?

Re: Changes for emacs 28

[Stefan Monnier]

>>> 5) Enable winmove and mouse-wheel-mode by default.
>> mouse-wheel-mode is already enabled by default on most graphical
>> displays.
> Right!... btw why not in the terminal?

I think it *is* enabled in the terminal as well.

But it only works if you ask to capture the terminal's mouse buttons
with `xterm-mouse-mode`.


        Stefan "who doesn't use a mouse any more"

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 12:54:08PM -0400, Stefan Monnier wrote:
>>>> 5) Enable winmove and mouse-wheel-mode by default.
>>> mouse-wheel-mode is already enabled by default on most graphical
>>> displays.
>> Right!... btw why not in the terminal?
>
>I think it *is* enabled in the terminal as well.
>
>But it only works if you ask to capture the terminal's mouse buttons
>with `xterm-mouse-mode`.
>
>
>        Stefan "who doesn't use a mouse any more"
>
Hi Stefan:

Is there a reason why the user needs to enable this explicitly? The
wheel and mouse works for me when using man/less/vim, out of the
box. Couldn't we do the same?

Best,
Ergus

Re: Changes for emacs 28

[Alfred M. Szmidt]

   >I think it *is* enabled in the terminal as well.
   >
   >But it only works if you ask to capture the terminal's mouse buttons
   >with `xterm-mouse-mode`.

   Is there a reason why the user needs to enable this explicitly? The
   wheel and mouse works for me when using man/less/vim, out of the
   box. Couldn't we do the same?

Not everyone uses xterm as their terminal of choise.

Re: Changes for emacs 28

[Stefan Monnier]

>    Is there a reason why the user needs to enable this explicitly?

IIRC the issue is that it prevents *other* uses of the mouse in xterm.
But I'm not quite sure what these are nor how important they are.
Maybe it's time to make a formal request to enable it by default?

> Not everyone uses xterm as their terminal of choise.

Not sure how that's related.  `xterm-mouse-mode` should only have an
effect in the terminals in which it works.  Are you saying that it is
known to have undesirable side-effects in some terminals?


        Stefan

Re: Changes for emacs 28

[Alfred M. Szmidt]

   >    Is there a reason why the user needs to enable this explicitly?

   IIRC the issue is that it prevents *other* uses of the mouse in xterm.
   But I'm not quite sure what these are nor how important they are.
   Maybe it's time to make a formal request to enable it by default?

I tried it in xterm, it doesn't conflict with the standard
C-mouse-1/2/3 pop-up menus that are available there.

   > Not everyone uses xterm as their terminal of choise.

   Not sure how that's related.  `xterm-mouse-mode` should only have an
   effect in the terminals in which it works.  Are you saying that it is
   known to have undesirable side-effects in some terminals?

If it is only enabled when one uses a xterm compatible terminal, I
don't see any harm.  But it would be strange to have xterm features
enabled when ones terminal isn't xterm, and still support mousy stuff.

Re: Changes for emacs 28 - ibuffer the default buffer-listing thing

[João Távora]

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

On Sun, Sep 6, 2020 at 2:37 PM Ergus <spacibba@aol.com> wrote:

> 3) Substitute list-buffers with ibuffer: This is actually in the TODO
> but for interactive users ibuffer offers a bit more modern
> experience. So the proposition is just to set ibuffer to the default
> bindings as so far it already offers all the list-buffers'
> functionalities.

I support this change.  But we should make sure that the advanced
functionality that Ibuffer offers isn't confusing. When I first saw Ibuffer
some many years ago, I was very confused about "filters" and
"filter groups".  I think the top level menus "Tools", "Operate" and
"Buffers", should all be grouped under some kind of "Buffer management"
or "Buffer list" top level entry.

Also, we should have pre-configured "filter groups", like
group-per-project, which we can probably do with project.el
(maybe this is already a thing, but I still have custom code for it).

Idiot-proof, example-rich documentation in the Emacs manual
is probably also a very good thing to have.

João

[-- Attachment #2: Type: text/html, Size: 1443 bytes --]

Re: Changes for emacs 28

[Mario Lang]

Ergus <spacibba@aol.com> writes:

> 3) Substitute list-buffers with ibuffer: This is actually in the TODO
> but for interactive users ibuffer offers a bit more modern
> experience. So the proposition is just to set ibuffer to the default
> bindings as so far it already offers all the list-buffers'
> functionalities.

+1

> 4) Enable display-line-numbers-mode by default. Almost all editors
> around have line numbers by default why we hide them?

No, please don't.  Maybe I am already too old, but I don't know what
these other editors you are talking about would be.  I never saw vim or
nano do that by default, and I am grateful for that.

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Mario Lang <mlang@blind.guru>
> Date: Tue, 08 Sep 2020 10:25:15 +0200
> Cc: emacs-devel@gnu.org
> 
> Ergus <spacibba@aol.com> writes:
> 
> > 3) Substitute list-buffers with ibuffer: This is actually in the TODO
> > but for interactive users ibuffer offers a bit more modern
> > experience. So the proposition is just to set ibuffer to the default
> > bindings as so far it already offers all the list-buffers'
> > functionalities.
> 
> +1
> 
> > 4) Enable display-line-numbers-mode by default. Almost all editors
> > around have line numbers by default why we hide them?
> 
> No, please don't.  Maybe I am already too old, but I don't know what
> these other editors you are talking about would be.  I never saw vim or
> nano do that by default, and I am grateful for that.

See, that's exactly the crux of the difficulty in these matters: ask N
people about changing defaults to M options, and you get the number of
different "please do this and this, but not that" opinions almost as
large as the number of permutations.

So either (1) we go for the lowest common denominator of features that
most people agree to (which can easily be an empty set); or (2) we
come up with groups of optional features which are turned on and off
together.  The latter needs someone who'd figure out such groups,
based on some principles, like experience or the kind of jobs that
people want to do, or something else.  It isn't easy, but unless
someone picks up the gauntlet, we will never move in that direction.

Re: Changes for emacs 28

[Stefan Monnier]

> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set);

That's what we've been doing so far.  I think we should keep doing it,
of course, because it's pretty much the only choice for the "default
defaults".

Beside this, we could create a kind of hierarchical configuration
system, where the hierarchy is not (like is the case in Custom) based
only on functionality, but rather on "popularity/importance/frequency".

We already have a bit of that with the few options which are placed
directly in the `Options` menu.  We could offer a menu entry "Settings"
which shows the "most commonly" requested settings (in a buffer rather
than in a submenu).  Not sure if we'd need "advanced settings" as an
intermediate point before getting to the "exhaustive" list of settings
available currently via Customize.

> or (2) we come up with groups of optional features which are turned on
> and off together.

These sound like Custom themes.  Currently we only use them for
aesthetics (faces, basically), but we should probably try to develop
them further to cover similar needs to the ones satisfied by
Doom/Spacemacs/StarterKit/...

> It isn't easy, but unless someone picks up the gauntlet, we will never
> move in that direction.

Agreed.  Maybe we should start small and try to create a few simple
custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...

And ideally someone should try and see what breaks down when we try and
create a theme that mimicks Prelude or Starter Kit, and then work
towards lifting those restrictions.


        Stefan

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Mario Lang <mlang@blind.guru>,  spacibba@aol.com,  emacs-devel@gnu.org
> Date: Tue, 08 Sep 2020 10:51:14 -0400
> 
> > It isn't easy, but unless someone picks up the gauntlet, we will never
> > move in that direction.
> 
> Agreed.  Maybe we should start small and try to create a few simple
> custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...

That'd be fine, although I'd rather prefer themes that sound like
Python-programming and Ruby-programming, and Atom, Sublime and VSCode
instead of Vim...

Re: Changes for emacs 28

[Stefan Monnier]

> That'd be fine, although I'd rather prefer themes that sound like
> Python-programming and Ruby-programming,

I think these usually aren't "themes".  They're rather integration work
that make things work the way they should, regardless of preference.
We definitely should work on that, but I don't think it's fit for
a custom theme.

> and Atom, Sublime and VSCode instead of Vim...

;-)


        Stefan

Re: Changes for emacs 28

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Beside this, we could create a kind of hierarchical configuration
> system, where the hierarchy is not (like is the case in Custom) based
> only on functionality, but rather on "popularity/importance/frequency".

It would also be good to be able to be able to present options in a
logical and predetermined order in custom instead of the current
alphabetical order.  Could custom be extended to handle that?  Maybe we
could add a :weight property to defcustom?

> We already have a bit of that with the few options which are placed
> directly in the `Options` menu.  We could offer a menu entry "Settings"
> which shows the "most commonly" requested settings (in a buffer rather
> than in a submenu).

Agreed, excellent idea.

> Agreed.  Maybe we should start small and try to create a few simple
> custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...
>
> And ideally someone should try and see what breaks down when we try and
> create a theme that mimicks Prelude or Starter Kit, and then work
> towards lifting those restrictions.

Agreed.  (Although I'm looking for the 'emacs29' theme myself.)

RE: Changes for emacs 28

[Drew Adams]

> > Beside this, we could create a kind of hierarchical configuration
> > system, where the hierarchy is not (like is the case in Custom) based
> > only on functionality, but rather on "popularity/importance/frequency".
> 
> It would also be good to be able to be able to present options in a
> logical and predetermined order in custom instead of the current
> alphabetical order.  Could custom be extended to handle that?  Maybe we
> could add a :weight property to defcustom?

Isn't that what :group is about?  An author can assign
any option or face to any number of :groups.

A :group is thus like a Delicious-style tag, in a way.

https://en.wikipedia.org/wiki/Delicious_(website)

Finder keywords, that is, keywords in a `Keywords'
file-header field, are also like tags in this way.

`customize-group' and `finder-by-keyword' are UI
entry points.  They could be improved.

Uses of finder keywords haven't been too systematic
so far.  And :group has been used sparingly so far.

But both seem to have this property that you can
assign multiple such "tags" to a thing (file/library
for finder keywords, option/face for :groups).

An advantage of organization by such tags is that
there can be any number of "logical and predetermined
orders".  Or rather, tags define sets, which are
unordered, but there can be hierarchies of sets.  And
the sets - their hierarchies and their elements - are
easily updated/redefined.

Re: Changes for emacs 28

[Dmitry Gutov]

On 08.09.2020 17:35, Eli Zaretskii wrote:
> See, that's exactly the crux of the difficulty in these matters: ask N
> people about changing defaults to M options, and you get the number of
> different "please do this and this, but not that" opinions almost as
> large as the number of permutations.

Honestly, I don't think that enabling (or not) display-line-numbers-mode 
is going to be a big deal either way: it's easy to enable or disable, 
and it has little far-reaching consequences otherwise.

Certainly fewer consequences that changing the default theme to dark, or 
enabling cua-mode by default, or even incorporating which-key.

Likewise for ibuffer vs list-buffers (though it'll be a bit harder to 
change back).

> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set); or (2) we
> come up with groups of optional features which are turned on and off
> together.

Orthogonally, we could decide on a method for changing defaults which 
doesn't involve the impossible task of making everybody happy but still 
makes some effort to change with the times.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: spacibba@aol.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 9 Sep 2020 01:06:31 +0300
> 
> On 08.09.2020 17:35, Eli Zaretskii wrote:
> > See, that's exactly the crux of the difficulty in these matters: ask N
> > people about changing defaults to M options, and you get the number of
> > different "please do this and this, but not that" opinions almost as
> > large as the number of permutations.
> 
> Honestly, I don't think that enabling (or not) display-line-numbers-mode 
> is going to be a big deal either way: it's easy to enable or disable, 
> and it has little far-reaching consequences otherwise.

That was only an example.

And anyway, isn't what you say above true for almost every optional
feature in Emacs?

> > So either (1) we go for the lowest common denominator of features that
> > most people agree to (which can easily be an empty set); or (2) we
> > come up with groups of optional features which are turned on and off
> > together.
> 
> Orthogonally, we could decide on a method for changing defaults which 
> doesn't involve the impossible task of making everybody happy but still 
> makes some effort to change with the times.

If this can be done, why not?  But based on past experience, I'm
skeptical, to tell the truth.

Re: Changes for emacs 28

[Dmitry Gutov]

On 09.09.2020 17:04, Eli Zaretskii wrote:

>> On 08.09.2020 17:35, Eli Zaretskii wrote:
>>> See, that's exactly the crux of the difficulty in these matters: ask N
>>> people about changing defaults to M options, and you get the number of
>>> different "please do this and this, but not that" opinions almost as
>>> large as the number of permutations.
>>
>> Honestly, I don't think that enabling (or not) display-line-numbers-mode
>> is going to be a big deal either way: it's easy to enable or disable,
>> and it has little far-reaching consequences otherwise.
> 
> That was only an example.
> 
> And anyway, isn't what you say above true for almost every optional
> feature in Emacs?

For a lot of them, yes. But of course there are also changes in behavior 
(that people also asked for) that can have farther-reaching consequences.

So I do believe we shouldn't worry too much about making some existing 
users moderately unhappy if we have convincing data that a given change 
will make Emacs more useful or more approachable (without making it less 
useful) for a lot of users, current or future ones. Especially if said 
optional feature is easy to toggle, and we can document how to negate 
the change in NEWS.

Repeat the same decision process M times.

Since this way there is no goal of making every user 100% happy, there 
is no stalemate.

>>> So either (1) we go for the lowest common denominator of features that
>>> most people agree to (which can easily be an empty set); or (2) we
>>> come up with groups of optional features which are turned on and off
>>> together.
>>
>> Orthogonally, we could decide on a method for changing defaults which
>> doesn't involve the impossible task of making everybody happy but still
>> makes some effort to change with the times.
> 
> If this can be done, why not?
> But based on past experience, I'm
> skeptical, to tell the truth.

 From my past experience, what was lacking is direction in leadership. 
Sorry to be blunt.

There were cases where we had evidence that a change will be welcome by 
the majority of users, existing and potential ones, and would be easily 
reverted locally by anybody who didn't like it, and it still wasn't 
made. E.g. the simple case of indent-tabs-mode=>nil.

Of course, not all cases are simple, and whether something is generally 
beneficial/user-friendly/etc is a matter of judgment. But at least we 
shouldn't be stopped by the sole concern that a given change can 
generate complaints because the option in question has held a certain 
value for a number of years. Or even decades.

Re: Changes for emacs 28

[Howard Melman]

Eli Zaretskii <eliz@gnu.org> writes:

> See, that's exactly the crux of the difficulty in these matters: ask N
> people about changing defaults to M options, and you get the number of
> different "please do this and this, but not that" opinions almost as
> large as the number of permutations.
>
> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set); or (2) we
> come up with groups of optional features which are turned on and off
> together.  The latter needs someone who'd figure out such groups,
> based on some principles, like experience or the kind of jobs that
> people want to do, or something else.  It isn't easy, but unless
> someone picks up the gauntlet, we will never move in that direction.

How about creating a new function that generates a report of
how a user has configured emacs.  Various options,
global-minor-modes, faces, etc, similar to what
report-emacs-bug generates.  Setup a separate email address
to receive reports and automatically tabulate what the
popular settings are.

Ship it with emacs 28.  Let it percolate into Doom,
Spacemacs and other distributions.  Then ask people far and
wide to run it.  This would generate actual data about
what's popular and what defaults people typically change and
could settle these recurring debates.

Like report-emacs-bug, it should display the info to the
user before sending so they can check that nothing personal
is revealed.

-- 

Howard

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > 4) Enable display-line-numbers-mode by default. Almost all editors
  > > around have line numbers by default why we hide them?

  > No, please don't.  Maybe I am already too old, but I don't know what
  > these other editors you are talking about would be.  I never saw vim or
  > nano do that by default, and I am grateful for that.

Maybe the default for this should depend on the width of the frame.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

> Hi Emacs:
>
> As 27 has just been released I think it is time to start considering
> changes for the release 28. I will add some points I think we could
> discuss (specially implying defaults) in order to hear opinions and have
> enough time to discuss/implement them.

Most of the discussions seems to have revolved around user-facing
changes, but I think it might also be time to clean-up some of the
internal code. There are vast discrepancies in style between newer
modules such as xref or project and older systems such as hippie-expand
and Rmail.

My hope would be that with easier interfaces to work with, that leverage
Elisp improvements, that more people would be interested in using,
supporting and extending OOTB packages/modules. My fear is that
backwards compatibility would be at risk.

---

And regarding modernizing defaults, how about bundling a few "themes"
that enable/disable a few settings. It might be confusing at first, as
most people associate themes with visual customisations, but since Emacs
interprets the term more generally, adding themes such as "Modern" that
enables more bells and whistles (I'm not too enthusiastic about the
name, some might have chosen "Hipster" instead :^)), "Minimal" that
reduces UI, etc. might be a compromise between the fractions that want
to make Emacs appealing to newcomers and those that don't want to break
Emacs' way-of-operating by default.

-- 
	Philip K.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Gcc: nnfolder+archive:sent.2020-09
> Date: Wed, 09 Sep 2020 19:14:29 +0200
> 
> And regarding modernizing defaults, how about bundling a few "themes"
> that enable/disable a few settings. It might be confusing at first, as
> most people associate themes with visual customisations, but since Emacs
> interprets the term more generally, adding themes such as "Modern" that
> enables more bells and whistles (I'm not too enthusiastic about the
> name, some might have chosen "Hipster" instead :^)), "Minimal" that
> reduces UI, etc. might be a compromise between the fractions that want
> to make Emacs appealing to newcomers and those that don't want to break
> Emacs' way-of-operating by default.

We already have a couple of such themes, so the issue of us accepting
such themes doesn't exist.

P.S.  Please review your MUA settings, because they just caused Emacs
to exclude the mailing list from the recipients, something that is
unwanted.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Thu, 10 Sep 2020 12:40:37 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> 
> P.S.  Please review your MUA settings, because they just caused Emacs
> to exclude the mailing list from the recipients, something that is
> unwanted.                            ^^^^^^^^^^

I meant the recipients of the response message, i.e. the addresses
automatically added to a response message by Emacs.

Re: Changes for emacs 28

[Philip K.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Philip K." <philipk@posteo.net>
>> Gcc: nnfolder+archive:sent.2020-09
>> Date: Wed, 09 Sep 2020 19:14:29 +0200
>> 
>> And regarding modernizing defaults, how about bundling a few "themes"
>> that enable/disable a few settings. It might be confusing at first, as
>> most people associate themes with visual customisations, but since Emacs
>> interprets the term more generally, adding themes such as "Modern" that
>> enables more bells and whistles (I'm not too enthusiastic about the
>> name, some might have chosen "Hipster" instead :^)), "Minimal" that
>> reduces UI, etc. might be a compromise between the fractions that want
>> to make Emacs appealing to newcomers and those that don't want to break
>> Emacs' way-of-operating by default.
>
> We already have a couple of such themes, so the issue of us accepting
> such themes doesn't exist.

Oh, I didn't know that? Is this being done in a separate feature branch?

> P.S.  Please review your MUA settings, because they just caused Emacs
> to exclude the mailing list from the recipients, something that is
> unwanted.

My apologies, again, I use Gnus to follow the mailing list, but forget
that unlike Rmail, it doesn't reply to every when 'R' is pressed.

-- 
	Philip K.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> Date: Thu, 10 Sep 2020 17:08:25 +0200
> 
> >> And regarding modernizing defaults, how about bundling a few "themes"
> >> that enable/disable a few settings. It might be confusing at first, as
> >> most people associate themes with visual customisations, but since Emacs
> >> interprets the term more generally, adding themes such as "Modern" that
> >> enables more bells and whistles (I'm not too enthusiastic about the
> >> name, some might have chosen "Hipster" instead :^)), "Minimal" that
> >> reduces UI, etc. might be a compromise between the fractions that want
> >> to make Emacs appealing to newcomers and those that don't want to break
> >> Emacs' way-of-operating by default.
> >
> > We already have a couple of such themes, so the issue of us accepting
> > such themes doesn't exist.
> 
> Oh, I didn't know that? Is this being done in a separate feature branch?

No, those themes are on master.

Re: Changes for emacs 28

[Tassilo Horn]

Ergus <spacibba@aol.com> writes:

> 1) Improve the default theme: Maybe set a default dark theme to make
> emacs feel more modern.

If you just set your background to some dark color, the stock Emacs
default faces are actually very nice, see:

  https://functional.cafe/web/statuses/104411970368324669

So just a default face light/dark toggle which doesn't use a theme but
the standard faces seems like a good idea.

Bye,
Tassilo

Re: Changes for emacs 28

[Philip K.]

Tassilo Horn <tsdh@gnu.org> writes:

> Ergus <spacibba@aol.com> writes:
>
>> 1) Improve the default theme: Maybe set a default dark theme to make
>> emacs feel more modern.
>
> If you just set your background to some dark color, the stock Emacs
> default faces are actually very nice, see:
>
>   https://functional.cafe/web/statuses/104411970368324669
>
> So just a default face light/dark toggle which doesn't use a theme but
> the standard faces seems like a good idea.
>
> Bye,
> Tassilo

That actually looks fairly similar to my own "dark mode":

        (defun reverse-face (face &optional frame)
          "Set FACE (in FRAME) to RGB inverse."
          (interactive (list (read-face-name "Reverse face" (face-at-point t))))
          (require 'color)
          (ignore-errors
            (let ((fg (face-attribute face :foreground frame))
                  (bg (face-attribute face :background frame)))
              (set-face-attribute
               face frame
               :foreground (color-complement-hex fg)
               :background (color-complement-hex bg)))))

        (defun toggle-dark-mode ()
          "Toggle dark mode."
          (interactive)
          (dolist (face '(mode-line default))
            (reverse-face face)))

-- 
	Philip K.