RE: A modern-mode?

RE: A modern-mode?

[Drew Adams]

>    following recent discussions I've started toying with what I've pushed on
>    scratch/modern-mode.
> 
> What some find modern, some will find old.  What some find old, some
> will find modern.  What was once modern will become old again, and
> what was old again will become modern.

The term "modern" should definitely never be used
to name something in Emacs.  That just invites
mocking as anachronism.

Everything someone thinks is old-fashioned today
could have been, and some things were, labeled
"modern" at some point.

And in the world of marketing, that has often been
done in a way that associates the thing with, well,
just phony advertising.

"Modern" has a connotation of fad, hot, or fashion.
If you really want someone to think your thing is
new, hot, or fashionable, don't call it "modern".

> A different name would be more appropriate.

Yes, and a name that _actually_ describes the thing.

If you can't describe it in a way that gets your
point across, it might well be that you don't have
much of a point to get across.

If the most/best you can say about something is
that it is blue, then just say that.  Don't try to
embellish or sell it by calling it "modern".  That
just invites ridicule, and it doesn't help anyone.

A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Hi all,

following recent discussions I've started toying with what I've pushed on
scratch/modern-mode.

The (not so new) idea is to have a global minor mode to enable other
code we already have in Emacs core to make Emacs a little more
friendly/modern to new comers.  IOW this is to enable some non
excessively invasive features to help people getting into the Emacs
universe.

ATM this modern-mode enables: column-number-mode, delete-selection-mode,
fido-mode, global-auto-revert-mode, show-paren-mode, winner-mode and
windmove, plus is binding ibuffer to C-x C-b.

Hopefully in the future we could enable something like fido vertical and
which-key.

I had a look but for now I gave-up on the idea of picking up a dark mode
to enable as is not so easy.

I've also made that this mode can be enabled at invocation time using
'-m' '-modern' or '--modern' as I think it may be more accessible for new
starters.

I think would be good to have something like this in core and not in
ELPA to ease people getting started without having to install anything.

Feedback is welcome

Thanks

  Andrea

Re: A modern-mode?

[Ergus]

On Tue, Sep 15, 2020 at 02:41:07PM +0000, Andrea Corallo via Emacs development discussions. wrote:
>Hi all,
>
>following recent discussions I've started toying with what I've pushed on
>scratch/modern-mode.
>
>The (not so new) idea is to have a global minor mode to enable other
>code we already have in Emacs core to make Emacs a little more
>friendly/modern to new comers.  IOW this is to enable some non
>excessively invasive features to help people getting into the Emacs
>universe.
>
>ATM this modern-mode enables: column-number-mode, delete-selection-mode,
>fido-mode, global-auto-revert-mode, show-paren-mode, winner-mode and
>windmove, plus is binding ibuffer to C-x C-b.
>
>Hopefully in the future we could enable something like fido vertical and
>which-key.
>
>I had a look but for now I gave-up on the idea of picking up a dark mode
>to enable as is not so easy.
>
>I've also made that this mode can be enabled at invocation time using
>'-m' '-modern' or '--modern' as I think it may be more accessible for new
>starters.
>
>I think would be good to have something like this in core and not in
>ELPA to ease people getting started without having to install anything.
>
>Feedback is welcome
>
>Thanks
>
>  Andrea
>
Hi Andrea:

This is a very good thing!. BTW I have something similar (for my
preferences of course)

https://github.com/Ergus/mini_dotemacs

Please feel free to take ideas from there as there are some
configuration options I have discovered with the time. There are not
any external package.

Best,
Ergus

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Ergus <spacibba@aol.com> writes:

> Hi Andrea:
>
> This is a very good thing!. BTW I have something similar (for my
> preferences of course)
>
> https://github.com/Ergus/mini_dotemacs
>
> Please feel free to take ideas from there as there are some
> configuration options I have discovered with the time. There are not
> any external package.

Hi Ergus,

thanks I'll certanly have a look.

Thanks
  Andrea

Re: A modern-mode?

[Stefan Monnier]

Hi Andrea,

Any chance you could turn it into a custom-theme?

AFAIK most of your minor-mode could be turned into a theme fairly
easily, so what I'm asking is for you try and do the extra work to cover
the remaining non-trivial part (e.g. the key-bindings).

Part of the difference between a minor mode and a custom theme is that
a custom theme is more declarative, with consequences such as the fact
that a user can enable your hypothetical "modern theme" but with
`fido-mode` disabled, and it won't have the effect of "enabling and then
disabling" `fido-mode` (e.g. running `fido-mode-hook` twice along the
way).

I'm mostly interested in pushing the limits of what can be done with
custom themes, so try to keep an eye on what generic/infrastructure
changes would make a "modern theme" easier to write cleanly.

> I had a look but for now I gave-up on the idea of picking up a dark mode
> to enable as is not so easy.

I thought setting the foreground and the background of the `default`
face  is all it takes (it should change the frame-background-mode and
thus cause all other faces to choose their dark-background alternative).
What problem did you encounter?


        Stefan

RE: A modern-mode?

[Drew Adams]

> Any chance you could turn it into a custom-theme?

> Part of the difference between a minor mode and a custom theme is that
> a custom theme is more declarative, with consequences such as the fact
> that a user can enable your hypothetical "modern theme" but with
> `fido-mode` disabled, and it won't have the effect of "enabling and then
> disabling" `fido-mode` (e.g. running `fido-mode-hook` twice along the
> way).

I'm not sure a theme is better than a global minor
mode.  I agree that there should be easy ways for
a user to choose what to turn on/off, including
easy ways to add things to turn on/off that aren't
included in whatever is provided by default.

I'm no expert on themes or minor modes, but I think
there's room for improvement of how to make such
enablement easier and more discoverable.  The minor
mode approach sounds like a good one to me, as far
as it goes.

> I'm mostly interested in pushing the limits of what can be done with
> custom themes

The aim here should, I think, be to provide users
with easy ways to:

1. Turn on(/off) a set of default settings that we
   generally think new users might appreciate.

2. Turn on(/off) individual settings in that set,
   i.e., to "customize/personalize" that set.

3. Add new settings to the default set, from
   wherever.

An aim of "pushing the limits of custom themes",
to see what can be done with them is something
else.

No doubt such an exploration could help with the
aim of helping new users get into Emacs.  But
those two aims are not the same.

Re: A modern-mode?

[Teemu Likonen]

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

* 2020-09-15 11:08:53-04, Stefan Monnier wrote:

> Any chance you could turn it into a custom-theme?

Yes, themes please!

> Part of the difference between a minor mode and a custom theme is that
> a custom theme is more declarative,

Minor modes are good for relatively narrow purpose but "modern" is a
broad term which can have effect on various other minor modes, variables
and faces. Themes are good for that because theme's individual minor
modes, variables and faces can be overridden easily and themes work
nicely with other themes.

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

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

> Hi Andrea,
>
> Any chance you could turn it into a custom-theme?
>
> AFAIK most of your minor-mode could be turned into a theme fairly
> easily, so what I'm asking is for you try and do the extra work to cover
> the remaining non-trivial part (e.g. the key-bindings).
>
> Part of the difference between a minor mode and a custom theme is that
> a custom theme is more declarative, with consequences such as the fact
> that a user can enable your hypothetical "modern theme" but with
> `fido-mode` disabled, and it won't have the effect of "enabling and then
> disabling" `fido-mode` (e.g. running `fido-mode-hook` twice along the
> way).

Sounds like is what we want.  Happy to have a look into this direction.

> I'm mostly interested in pushing the limits of what can be done with
> custom themes, so try to keep an eye on what generic/infrastructure
> changes would make a "modern theme" easier to write cleanly.
>
>> I had a look but for now I gave-up on the idea of picking up a dark mode
>> to enable as is not so easy.
>
> I thought setting the foreground and the background of the `default`
> face  is all it takes (it should change the frame-background-mode and
> thus cause all other faces to choose their dark-background alternative).
> What problem did you encounter?

Sorry I wasn't clear, I was not referring to a technical difficulty.

All I did was just having a look to the dark themes we have in Emacs
core and could not find one that fully convinced me.  Wombat and
tango-dark are not bad but modus-vivendi has maybe the best set of
colors, OTOH I think this last IMO has a little too much contrast
(probably because focus on accessibility).

One thing I noticed is that tool and scroll bar don't change color (I'm
testing with GTK).  If this an Emacs limitation is not very good as the
aesthetic outcome with a dark theme IMO is not optimal (say pretty bad).

That said I think this should enable some dark setting so I'll look into
how to proceed (suggestions very welcome on this too :).

  Andrea

Re: A modern-mode?

[Antoine Kalmbach]

Andrea Corallo <akrl@sdf.org> writes:

> That said I think this should enable some dark setting so I'll look into
> how to proceed (suggestions very welcome on this too :).

I suspect that whether a "modern" theme should enable a dark/light theme by
default is a point of contention. I think it would be better to either (a) split
the theme into modern-light-theme / modern-dark-theme or even better (b) make
the whole thing interactive on first use which would prompt/guide the user to
select by their preference, not unlike a guided tour. 

-- 
Antoine Kalmbach

Re: A modern-mode?

[Teemu Likonen]

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

* 2020-09-15 18:36:53Z, Andrea Corallo via wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Part of the difference between a minor mode and a custom theme is
>> that a custom theme is more declarative, with consequences such as
>> the fact that a user can enable your hypothetical "modern theme" but
>> with `fido-mode` disabled, and it won't have the effect of "enabling
>> and then disabling" `fido-mode` (e.g. running `fido-mode-hook` twice
>> along the way).
>
> Sounds like is what we want. Happy to have a look into this direction.

Also note that the whole "modernism" concept could be split into
different themes. Then user could toggle them individually. Something
like:

    modern-settings
    modern-keybindings
    modern-decorations
    modern-color-light
    modern-color-dark

Or whatever.

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Teemu Likonen <tlikonen@iki.fi> writes:

> Also note that the whole "modernism" concept could be split into
> different themes. Then user could toggle them individually. Something
> like:
>
>     modern-settings
>     modern-keybindings
>     modern-decorations
>     modern-color-light
>     modern-color-dark
>
> Or whatever.

Agree, I think once is rewritten in the suggested theme declarative way
to have it splitted should come easy.  That said I think key is that we
provide a way to enable it as first with the less necessary tweaking as
we can offer.

  Andrea

RE: A modern-mode?

[Drew Adams]

> have a global minor mode to enable other
> code we already have in Emacs core to make Emacs a little more
> friendly/modern to new comers.

Such an approach is a good start - a good approach, I
think.  Then we can provide a tool-bar button or
splash-screen link or some such prominent,
early-and-obvious way(s) to turn it on/off.

There may be some difficulty getting agreement on what
should be there by default.

It could be good for the mode to have an easy way for
users to check off (opt in/out) things that they want
included when the mode is enabled.

`C-h m' for the mode (or other help for it) could
present such a check list.  The list could be like
what the Options menu presents, but it could have
more description and, where appropriate, links to
Customize for relevant options etc.

RE: A modern-mode?

[Theodor Thornhill]

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

>> have a global minor mode to enable other
>> code we already have in Emacs core to make Emacs a little more
>> friendly/modern to new comers.
[...]
>
> It could be good for the mode to have an easy way for
> users to check off (opt in/out) things that they want
> included when the mode is enabled.
>

Yeah, this is important.  IMO the biggest problem with DOOM/Spacemacs is
that it isn't really easy to declare .emacs bankrupcy and start over,
since so much is convoluted inside the distribution.  I'm afraid a mode
such as this would only serve as some sort of "vendor lock-in", and make
people rely too much on this, rather than creating their own, reading
the docs and code etc.  I think that when you are confused about
something, emacs should guide you to the variable or function in
question, and not hidden away in some mode.  However, I still think this
is a good idea.

Re: A modern-mode?

[Göktuğ Kayaalp]

On 2020-09-15 17:41 +03, Andrea Corallo via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> Hi all,
> following recent discussions I've started toying with what I've pushed on
> scratch/modern-mode.
>
> The (not so new) idea is to have a global minor mode to enable other
> code we already have in Emacs core to make Emacs a little more
> friendly/modern to new comers.  IOW this is to enable some non
> excessively invasive features to help people getting into the Emacs
> universe.

IMHO this is the best way to go forward.  What’s inside it could be fine
tuned until 28 release, and then a checkbox or a link can introduce it
in the splash screen.

IMHO we could look at Emacs distributions for inspirations regarding
what to have in this mode.
















P.S. maybe we’re missing the chance to include a terrible pun not
calling this ‘a-la-mode’?


(that’s not serious at all, of course)


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

Re: A modern-mode?

[Gregory Heytings via Emacs development discussions.]

Hi Andrea,

>
> following recent discussions I've started toying with what I've pushed 
> on scratch/modern-mode.
>
> The (not so new) idea is to have a global minor mode to enable other 
> code we already have in Emacs core to make Emacs a little more 
> friendly/modern to new comers.  IOW this is to enable some non 
> excessively invasive features to help people getting into the Emacs 
> universe.
>
> ATM this modern-mode enables: column-number-mode, delete-selection-mode, 
> fido-mode, global-auto-revert-mode, show-paren-mode, winner-mode and 
> windmove, plus is binding ibuffer to C-x C-b.
>
[...]
>
> Feedback is welcome
>

I'm biased, but I do not think this is better than the guided tour / 
interactive guide proposal that Yuan Fu and me sent a few days ago.

The problem of "modern-mode" is that, as the traffic on this list during 
the last days has shown, different people have different ideas of what 
"modern" is, and might want to turn each feature on or off.  Some might 
want a dark theme and others not, some might want tabs and others not, and 
so forth.  So it is better to give something more refined than a binary 
modern/non-modern choice.

Moreover the guided tour proposal introduces the most important concepts 
of Emacs, and explains how to find help, which I believe is very important 
if the point is the help people getting (and staying!) into the Emacs 
universe.

RE: A modern-mode?

[Gregory Heytings via Emacs development discussions.]

>> I'm biased, but I do not think this is better than the guided tour / 
>> interactive guide proposal that Yuan Fu and me sent a few days ago.
>
>> Moreover the guided tour proposal introduces the most important 
>> concepts of Emacs, and explains how to find help, which I believe is 
>> very important if the point is the help people getting (and staying!) 
>> into the Emacs universe.
>
> A tour is different from a button to get a set of features.
>

Did you have a look at the proposal?  I realize that there has been so 
much traffic here that you may have missed it.  It combines the two 
aspects: buttons to set a number of features that newcomers might want to 
turn on, and explanations to guide their first steps.  Your feedback would 
be most welcome.

RE: A modern-mode?

[Drew Adams]

> >> I'm biased, but I do not think this is better than the guided tour /
> >> interactive guide proposal that Yuan Fu and me sent a few days ago.
> >
> >> Moreover the guided tour proposal introduces the most important
> >> concepts of Emacs, and explains how to find help, which I believe is
> >> very important if the point is the help people getting (and staying!)
> >> into the Emacs universe.
> >
> > A tour is different from a button to get a set of features.
> 
> Did you have a look at the proposal?  I realize that there has been so
> much traffic here that you may have missed it.  It combines the two
> aspects: buttons to set a number of features that newcomers might want to
> turn on, and explanations to guide their first steps.  Your feedback would
> be most welcome.

A tour with ability to choose stuff on the fly is
still different from a mode for a set of settings
and an interface to "customize" or add to those
settings.  IMO.

The latter lets you turn the mode on/off anytime.
And it lets you "customize" it anytime.  Those
things are not mixed in with following a tour.

Letting a tour give you one way to "customize"
such a mode would be fine.  But you shouldn't
need to go through a tour to do that.

IOW, they're related, but not the same, I think.

RE: A modern-mode?

[Drew Adams]

> > > A tour is different from a button to get a set of features.
> >
> > Did you have a look at the proposal?

You yourself agreed they are not the same thing:

> I do not think this is better than the guided
> tour / interactive guide proposal

Your point in saying that was presumably not to
claim that they are the same but that one is
better than the other.

My point was that they have different purposes,
with some overlap.  They are not the same thing.

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Gregory Heytings <ghe@sdf.org> writes:

> I'm biased, but I do not think this is better than the guided tour /
> interactive guide proposal that Yuan Fu and me sent a few days ago.
>
> The problem of "modern-mode" is that, as the traffic on this list
> during the last days has shown, different people have different ideas
> of what "modern" is, and might want to turn each feature on or off.
> Some might want a dark theme and others not, some might want tabs and
> others not, and so forth.  So it is better to give something more
> refined than a binary modern/non-modern choice.
>
> Moreover the guided tour proposal introduces the most important
> concepts of Emacs, and explains how to find help, which I believe is
> very important if the point is the help people getting (and staying!)
> into the Emacs universe.

Hi Gregory,

I agree with Drew that these are two different (IMO interesting)
features.

If (as suggested) the modern-mode becomes a modern-theme this is
effectively like a new set of defaults that can be easily toggled, and
if the user wants later on refined and re-configured.

I hope to see both features coming to fruition as they are not
exclusive.

  Andrea

Re: A modern-mode?

[Gregory Heytings via Emacs development discussions.]

>
> If (as suggested) the modern-mode becomes a modern-theme this is 
> effectively like a new set of defaults that can be easily toggled, and 
> if the user wants later on refined and re-configured.
>

I see what you mean, but I do not see how this would help newcomers.  It 
would be one set of defaults, and many will come with another set of 
defaults that they would also like to call "modern-mode" (or 
"postmodern-mode" or "futuristic-mode" or "postfuturistic-mode" or ...). 
This would result in the long term in a large set of "profiles", each with 
a number of unrelated defaults modified, in which a new user would be 
lost.

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Gregory Heytings <ghe@sdf.org> writes:

> I see what you mean, but I do not see how this would help newcomers.

I think one easily accessible ready to go set of more modern/friendly
defaults can help new users getting started.

I'm convinced new comers should ideally do *nothing* to have a more
friendly system to begin with, if this is not possible hopefully
something easy as typing '-m' is the closest.

If you think a guided tour to go through is more effective, well you are
very much entitled to.  I don't think this is sufficiently immediate for
many cases but I think can be useful for others.

  Andrea

Re: A modern-mode?

[Gregory Heytings via Emacs development discussions.]

>> I see what you mean, but I do not see how this would help newcomers.
>
> I think one easily accessible ready to go set of more modern/friendly 
> defaults can help new users getting started.
>

The problem is that Emacs developers would have to agree on what that set 
of "more modern / friendly defaults" is, which is unlikely to happen. 
Again, different people have (very!) different ideas of what "modern / 
friendly" is.

A few examples, in the defaults you suggested:

- fido-mode: in another thread Eli explained that in his opinion 
icomplete's behavior is not intuitive enough for newcomers, and I (and 
probably others) agree with what he said

- global-auto-revert-mode: I would strongly object to this, having your 
editor doing something without asking you for a confirmation is not 
something many newcomers would find intuitive

- winner-mode: I don't understand why you would turn this on, IMO having 
C-c <left> and C-c <right> to undo window changes is useless for a 
newcomer, and C-c <left> / <right> is not a keybinding they can guess by 
themselves.

Re: A modern-mode?

[Dmitry Gutov]

On 16.09.2020 11:58, Gregory Heytings via Emacs development discussions. 
wrote:

> The problem is that Emacs developers would have to agree on what that 
> set of "more modern / friendly defaults" is, which is unlikely to 
> happen. Again, different people have (very!) different ideas of what 
> "modern / friendly" is.

Cue several more weeks of discussions.

> A few examples, in the defaults you suggested:
> 
> - fido-mode: in another thread Eli explained that in his opinion 
> icomplete's behavior is not intuitive enough for newcomers, and I (and 
> probably others) agree with what he said

It's more intuitive than the absence of any completion hints, which is 
the current default.

We can swap it for a different system when one is available.

> - global-auto-revert-mode: I would strongly object to this, having your 
> editor doing something without asking you for a confirmation is not 
> something many newcomers would find intuitive

It's a feature of many other "modern" editors.

Re: A modern-mode?

[Göktuğ Kayaalp]

On 2020-09-16 11:58 +03, Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> wrote:
> The problem is that Emacs developers would have to agree on what that
> set of "more modern / friendly defaults" is, which is unlikely to
> happen. Again, different people have (very!) different ideas of what
> "modern / friendly" is.

If we’re trying to make Emacs friendlier for newcomers, I doubt it’s
Emacs developers who need to agree, but the software that they use as a
proxy to their preferences.  And given such agreement exists when you
compare the feature set of these programs, there’s not much room for
debate here actually.

> - fido-mode: in another thread Eli explained that in his opinion
>   icomplete's behavior is not intuitive enough for newcomers, and I
>   (and probably others) agree with what he said

Could be made more intuitive via customisation within the mode.

> - global-auto-revert-mode: I would strongly object to this, having
>   your editor doing something without asking you for a confirmation is
>   not something many newcomers would find intuitive

This is what _all_ these editors do so while maybe you (and I, too)
don’t find it intuitive, that other people do find it intuitive is kinda
obvious.

> - winner-mode: I don't understand why you would turn this on, IMO
>   having C-c <left> and C-c <right> to undo window changes is useless
>   for a newcomer, and C-c <left> / <right> is not a keybinding they
>   can guess by themselves.

And in that case they just use the mouse until they feel like they can
do better.

We could also incorporate a cheat sheet that organises things a bit more
better than C-h m.

But ultimately the beauty of Andrea’s approach is that we can just put
random things in there, write EXPERIMENTAL in all caps in the docstring,
and refine until 28.  What we initially put in there is not all that
important. to be honest.


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

Re: A modern-mode?

[João Távora]

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

On Wed, Sep 16, 2020 at 11:39 AM Göktuğ Kayaalp <self@gkayaalp.com> wrote:

But ultimately the beauty of Andrea’s approach is that we can just put
> random things in there, write EXPERIMENTAL in all caps in the docstring,
> and refine until 28.  What we initially put in there is not all that
> important. to be honest.
>

I don't agree with this.  We should not throw "random things" in there
because that will affect the possibility that Andrea's customization
can be composed with Joe Doe's, whose contribution I would also
welcome. If we follow your plan, it seems very likely  that a sub-battle
for defaults emerges within it. So, no to "random". Only things that
our "custom-theme" infrastructure knows how to handle. If it doesn't
handle some of those, then either that infrastructure or a package's
custom.el conformance should be augmented.

João

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

Re: A modern-mode?

[Arthur Miller]

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

> - winner-mode: I don't understand why you would turn this on, IMO having C-c
>   <left> and C-c <right> to undo window changes is useless for a newcomer, and
>   C-c <left> / <right> is not a keybinding they can guess by themselves.
C-c <...> is not something anyone could guess; and for newcomers to
Emacs probably any kyeboard shortcut would be hard or impossible to
guess. Reason being probably because not much other software have undo
stack for guit layut.

But that shouldn't be reason not to enable winner mode. Winner mode is
usefull and there is probably no reason not to enable it in main Emacs.
I would probably also include ace-window and enable it by default.

Re: A modern-mode?

[Alfred M. Szmidt]

   following recent discussions I've started toying with what I've pushed on
   scratch/modern-mode.

What some find modern, some will find old.  What some find old, some
will find modern.  What was once modern will become old again, and
what was old again will become modern.

A different name would be more appropriate.

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

ams@gnu.org (Alfred M. Szmidt) writes:

> What was once modern will become old again, and what was old again
> will become modern.

One important aspect of this collection of settings is that we should be
less committed to (eternal :) immutability as we are for normal
defaults.

As this is meant to be an help for new starters we should feel free to
improve these from release to release without a negative impact on old
new starters, as by definition they are not anymore new starters :)

IOW If they stayed around for more than a release cycle quite certainly
they have learned how to personalize Emacs themselves.

  Andrea

Re: A modern-mode?

[Alfred M. Szmidt]

The word modern has a negative meaning in that it implies that the
rest of Emacs isn't modern -- why would users ever want to switch of
"modern-mode" and use the un-modern Emacs?

   As this is meant to be an help for new starters we should feel free to
   improve these from release to release without a negative impact on old
   new starters, as by definition they are not anymore new starters :)

ever-changing-mode? :)

Re: A modern-mode?

[Alan Third]

On Wed, Sep 16, 2020 at 03:36:12AM -0400, Alfred M. Szmidt wrote:
> The word modern has a negative meaning in that it implies that the
> rest of Emacs isn't modern -- why would users ever want to switch of
> "modern-mode" and use the un-modern Emacs?

Easy-mode as opposed to expert, obviously. ;)

Starter-mode

Familiar-mode

Familiar-defaults-easy-start-mode? ;)

-- 
Alan Third

RE: A modern-mode?

[Drew Adams]

> Easy-mode as opposed to expert, obviously. ;)
> Starter-mode
> Familiar-mode
> Familiar-defaults-easy-start-mode? ;)


newbie-mode
___________

Someone who's a newbie and sees "Newbie"
can think (at least) two things:

1. It's easy, intended for newbies, so maybe
   it's for me, at least for now.

2. Maybe it's something I might want to grow
   out of.  It's maybe not the "real" or "full"
   thing.  There's more to Emacs than this mode.

#1 can encourage a newbie, especially if timid,
to try it.

#2 can encourage someone to move beyond it, and
discover and use more of Emacs.

The Emacs Wiki has long had pages that aimed
especially at newbies, and referred to as such.
They've helped a lot of people, and I've never
seen a negative reaction to use of the term
"newbie".

This is like "training wheels" for someone
learning to ride a bike.  You trust them, use
them to help you get going, but you want to
get to a point where you can really ride
without them.

Re: A modern-mode?

[Arthur Miller]

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

>> Easy-mode as opposed to expert, obviously. ;)
>> Starter-mode
>> Familiar-mode
>> Familiar-defaults-easy-start-mode? ;)
>
>
> newbie-mode
> ___________
>
> Someone who's a newbie and sees "Newbie"
> can think (at least) two things:
>
> 1. It's easy, intended for newbies, so maybe
>    it's for me, at least for now.
>
> 2. Maybe it's something I might want to grow
>    out of.  It's maybe not the "real" or "full"
>    thing.  There's more to Emacs than this mode.
>
> #1 can encourage a newbie, especially if timid,
> to try it.
>
> #2 can encourage someone to move beyond it, and
> discover and use more of Emacs.
>
> The Emacs Wiki has long had pages that aimed
> especially at newbies, and referred to as such.
> They've helped a lot of people, and I've never
> seen a negative reaction to use of the term
> "newbie".
>
> This is like "training wheels" for someone
> learning to ride a bike.  You trust them, use
> them to help you get going, but you want to
> get to a point where you can really ride
> without them.
And then you will see threads on Reddit & elswhere asking when it is
appropriate to switch to "true Emacs mode"; should I learn this and then
switch to Emacs original etc; just as there already are such threads
considerinv Evil & Emacs interaction models.

Newbie-mode and numacs are bad names, in my opinion.

Re: A modern-mode?

[Thibaut Verron]

> And then you will see threads on Reddit & elswhere asking when it is
> appropriate to switch to "true Emacs mode"; should I learn this and then
> switch to Emacs original etc; just as there already are such threads
> considerinv Evil & Emacs interaction models.
>
> Newbie-mode and numacs are bad names, in my opinion.

I tend to agree. Some (most?) of the suggested options do not need to
be grown out of. Some are even already activated by default.

Re: A modern-mode?

[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. ]]]

  > Easy-mode as opposed to expert, obviously. ;)

  > Starter-mode

  > Familiar-mode

  > Familiar-defaults-easy-start-mode? ;)

Like Other Editors mode?


-- 
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: A modern-mode?

[Göktuğ Kayaalp]

On 2020-09-16 10:36 +03, Alfred M. Szmidt <ams@gnu.org> wrote:
> The word modern has a negative meaning in that it implies that the
> rest of Emacs isn't modern -- why would users ever want to switch of
> "modern-mode" and use the un-modern Emacs?

IMHO reading too much into names is not productive.  ‘Modern’ is a term
that’s used fairly often in this context, and what to expect would be
obvious to those who would want to use such a mode: features common to
contemporary text editors.

What features to put in there could slowly brew until 28 is released.
There’s no harm in starting out with Andrea’s opinions and slowly
refining it with feedback from within and from without.  But if we keep
yak shaving over names and particularities we won’t have anything to
refine.  And we’ve already doubled the traffic of Sep 2019...


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

Re: A modern-mode?

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]


   On 2020-09-16 10:36 +03, Alfred M. Szmidt <ams@gnu.org> wrote:
   > The word modern has a negative meaning in that it implies that the
   > rest of Emacs isn't modern -- why would users ever want to switch of
   > "modern-mode" and use the un-modern Emacs?

   IMHO reading too much into names is not productive.  ‘Modern’ is a term
   that’s used fairly often in this context, and what to expect would be
   obvious to those who would want to use such a mode: features common to
   contemporary text editors.

Names mean things and in this discussion it was because Emacs was seen
as old (i.e., un-modern), a new user would be curious why modern-mode
isn't the default.  And as the discussion has showed, there is no
agreement what people think is modern.  So it would be simply better
to avoid the term "modern" completely.

   What features to put in there could slowly brew until 28 is released.

Why not slowly brew those and make them default instead?

Re: A modern-mode?

[Eli Zaretskii]

> From: ams@gnu.org (Alfred M. Szmidt)
> Date: Wed, 16 Sep 2020 07:17:08 -0400
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> 
> 
>    On 2020-09-16 10:36 +03, Alfred M. Szmidt <ams@gnu.org> wrote:
>    > The word modern has a negative meaning in that it implies that the
>    > rest of Emacs isn't modern -- why would users ever want to switch of
>    > "modern-mode" and use the un-modern Emacs?
> 
>    IMHO reading too much into names is not productive.  ‘Modern’ is a term
>    that’s used fairly often in this context, and what to expect would be
>    obvious to those who would want to use such a mode: features common to
>    contemporary text editors.
> 
> Names mean things and in this discussion it was because Emacs was seen
> as old (i.e., un-modern), a new user would be curious why modern-mode
> isn't the default.  And as the discussion has showed, there is no
> agreement what people think is modern.  So it would be simply better
> to avoid the term "modern" completely.

Yes, let's find a different name for this.  I'd object to calling it
"modern", because I disagree that vanilla Emacs isn't.

newcomer-friendly-mode? new-to-emacs-mode? numacs-mode?

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

> newcomer-friendly-mode? new-to-emacs-mode? numacs-mode?

I like numacs-mode!

Re: A modern-mode?

[Dmitry Gutov]

On 16.09.2020 17:46, Andrea Corallo via Emacs development discussions. 
wrote:
> I like numacs-mode!

I do too.

Re: A modern-mode?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, let's find a different name for this.  I'd object to calling it
> "modern", because I disagree that vanilla Emacs isn't.

I think "modern" implies that one day it won't be modern any more, so
it's a fine name by me.  But perhaps it should be more specific:
`modern-2020-mode'.

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

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think "modern" implies that one day it won't be modern any more, so
> it's a fine name by me.  But perhaps it should be more specific:
> `modern-2020-mode'.

Hi Lars,

your idea for the name is nice :) The other option I suggested is that
we do not commit to retrocompatibility from release to release on this
collection of settings.  Hopefully users learn how to configure Emacs
after sticking around for a while.

  Andrea

Re: A modern-mode?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 16 Sep 2020 17:18:01 +0200
> Cc: self@gkayaalp.com, "Alfred M. Szmidt" <ams@gnu.org>, akrl@sdf.org,
>  emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes, let's find a different name for this.  I'd object to calling it
> > "modern", because I disagree that vanilla Emacs isn't.
> 
> I think "modern" implies that one day it won't be modern any more, so
> it's a fine name by me.  But perhaps it should be more specific:
> `modern-2020-mode'.

I'm okay with that if we drop the "modern" part.  How about
emacs-2021-mode?

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Wed, 16 Sep 2020 17:18:01 +0200
>> Cc: self@gkayaalp.com, "Alfred M. Szmidt" <ams@gnu.org>, akrl@sdf.org,
>>  emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Yes, let's find a different name for this.  I'd object to calling it
>> > "modern", because I disagree that vanilla Emacs isn't.
>> 
>> I think "modern" implies that one day it won't be modern any more, so
>> it's a fine name by me.  But perhaps it should be more specific:
>> `modern-2020-mode'.
>
> I'm okay with that if we drop the "modern" part.  How about
> emacs-2021-mode?

I like this one too :) But would still be possible to have it enabled
with a command line option?  I mean if every new release we have a new
version of this mode (theme?) either we loose this ability or we have
the command line option binded to the most recent one.

  Andrea

Re: A modern-mode?

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, self@gkayaalp.com, ams@gnu.org,
>         emacs-devel@gnu.org
> Date: Wed, 16 Sep 2020 15:54:28 +0000
> 
> > I'm okay with that if we drop the "modern" part.  How about
> > emacs-2021-mode?
> 
> I like this one too :) But would still be possible to have it enabled
> with a command line option?  I mean if every new release we have a new
> version of this mode (theme?) either we loose this ability or we have
> the command line option binded to the most recent one.

The usual way of solving this is to turn it on in your .emacs.

Why does it have to be a command-line option (that isn't --eval)?

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

> The usual way of solving this is to turn it on in your .emacs.
>
> Why does it have to be a command-line option (that isn't --eval)?

I imagine myself in the condition of giving a suggestion to a colleague
for trying out Emacs.  It's very easy to suggest like '-m'.  IMO it is
already considerably more complex to start explaining --eval... or the
.emacs equivalent.  And I'm thinking to a colleague,  if I think to
someone less computer skilled it's even worst.

Yes I know may sounds strange I believe this is a first barrier.

  Andrea

Re: A modern-mode?

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: larsi@gnus.org, self@gkayaalp.com, ams@gnu.org, emacs-devel@gnu.org
> Date: Wed, 16 Sep 2020 16:17:03 +0000
> 
> > Why does it have to be a command-line option (that isn't --eval)?
> 
> I imagine myself in the condition of giving a suggestion to a colleague
> for trying out Emacs.  It's very easy to suggest like '-m'.  IMO it is
> already considerably more complex to start explaining --eval... or the
> .emacs equivalent.  And I'm thinking to a colleague,  if I think to
> someone less computer skilled it's even worst.

You don't need to explain anything, just create a .emacs file for them
with that one line.  This is what I do in such cases.  The advantage
is that the users don't need to remember any switches, and can invoke
Emacs from their desktop icons.

Re: A modern-mode?

[Noam Postavsky]

On Wed, 16 Sep 2020 at 12:17, Andrea Corallo via Emacs development
discussions. <emacs-devel@gnu.org> wrote:

> I imagine myself in the condition of giving a suggestion to a colleague
> for trying out Emacs.  It's very easy to suggest like '-m'.  IMO it is
> already considerably more complex to start explaining --eval... or the

You could use --funcall (or the short from -f), as in: '-f
emacs-2021-mode'. This gets around the potential difficulties of
escaping parens that --eval has. I don't think much explanation should
be needed.

Re: A modern-mode?

[Alfred M. Szmidt]

   > The usual way of solving this is to turn it on in your .emacs.
   >
   > Why does it have to be a command-line option (that isn't --eval)?

   I imagine myself in the condition of giving a suggestion to a colleague
   for trying out Emacs.  It's very easy to suggest like '-m'.  IMO it is
   already considerably more complex to start explaining --eval... or the
   .emacs equivalent.  And I'm thinking to a colleague,  if I think to
   someone less computer skilled it's even worst.

   Yes I know may sounds strange I believe this is a first barrier.

Most users would just click on an icon to start emacs, I doubt that
they would fire up a terminal and then do emacs --help and find a -m
option.

It would be either that, or guidance from someone to suggest to use -m
-- then one might as well teach them plain Emacs which isn't hard.

Re: A modern-mode?

[Alan Third]

On Wed, Sep 16, 2020 at 03:54:28PM +0000, Andrea Corallo via Emacs development discussions. wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm okay with that if we drop the "modern" part.  How about
> > emacs-2021-mode?
> 
> I like this one too :) But would still be possible to have it enabled
> with a command line option?  I mean if every new release we have a new
> version of this mode (theme?) either we loose this ability or we have
> the command line option binded to the most recent one.

Easy, make it "emacs -2021", then in a few years when we decide that's
no longer modern looking we can add "emacs -2023", and so on forever.
;)

Personally I dislike the idea of turning it on with a command line
option, I'd rather we just give them a customize option linked from
the splash screen or whatever, merging two competing proposals.
-- 
Alan Third

Re: A modern-mode?

[Alfred M. Szmidt]

   >> > Yes, let's find a different name for this.  I'd object to calling it
   >> > "modern", because I disagree that vanilla Emacs isn't.
   >> 
   >> I think "modern" implies that one day it won't be modern any more, so
   >> it's a fine name by me.  But perhaps it should be more specific:
   >> `modern-2020-mode'.
   >
   > I'm okay with that if we drop the "modern" part.  How about
   > emacs-2021-mode?

   I like this one too :) But would still be possible to have it enabled
   with a command line option?  I mean if every new release we have a new
   version of this mode (theme?) either we loose this ability or we have
   the command line option binded to the most recent one.

Why not some clickable link on the splash screen, or a toggle from the
menu-bar?

The only option that might make sense is an option to select a theme
from the command line.

RE: A modern-mode?

[arthur miller]

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

You didn't created Emacs 20-mode when you switched from Emacs 19 to Emacs 20. Why should you have new mode for new version?

I don't think this entire discussion is about being modern, but about being more like other software.

As I have followed original Andrea's proposal, here is what I think:

Make a list of external packages that are legally and technically acceptable for inclusion in Emacs (for example which-key)

Include those and enable them as default, not as a mode. Old users are experienced enough to setq a variable or two, or change it  via customize, new users are not.

Rarionale: you already have such features (me nus, tool ars, scrollbars etc) that experienced users usually turn off. Same is with which-key and other  new packages you choose to include.

Keyboard interaction is another subject in this "modern" discussion. 3d modellers/animation packages usually come with key-bindings that resemble competitions package. That to make eventual transition easy. I have no idea if it is fully possible in Emacs, but Emacs already have Vi emulation. Maybe there could be VisualStudio too (or whatever is interesting)? Remapping C-x & co is probably not directly trivial.

Looks: Emacs has themes, and there are quality themes out there. A not so trivial part is 3rd party packages which has to be skinned "manually",  something seems to be missing, so complete theming framework so 3rd party packages can also get blended into looks automatically (a thread about color scheming is about that).


-------- Originalmeddelande --------
Från: "Alfred M. Szmidt" <ams@gnu.org>
Datum: 2020-09-16 18:49 (GMT+01:00)
Till: Andrea Corallo <akrl@sdf.org>
Kopia: self@gkayaalp.com, eliz@gnu.org, larsi@gnus.org, emacs-devel@gnu.org
Ämne: Re: A modern-mode?

   >> > Yes, let's find a different name for this.  I'd object to calling it
   >> > "modern", because I disagree that vanilla Emacs isn't.
   >>
   >> I think "modern" implies that one day it won't be modern any more, so
   >> it's a fine name by me.  But perhaps it should be more specific:
   >> `modern-2020-mode'.
   >
   > I'm okay with that if we drop the "modern" part.  How about
   > emacs-2021-mode?

   I like this one too :) But would still be possible to have it enabled
   with a command line option?  I mean if every new release we have a new
   version of this mode (theme?) either we loose this ability or we have
   the command line option binded to the most recent one.

Why not some clickable link on the splash screen, or a toggle from the
menu-bar?

The only option that might make sense is an option to select a theme
from the command line.


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

Re: A modern-mode?

[Dmitry Gutov]

On 16.09.2020 18:18, Lars Ingebrigtsen wrote:
> I think "modern" implies that one day it won't be modern any more, so
> it's a fine name by me.  But perhaps it should be more specific:
> `modern-2020-mode'.

You can call it 21st-century-mode, and it will still fit.

Re: A modern-mode?

[Alfred M. Szmidt]

   > Names mean things and in this discussion it was because Emacs was seen
   > as old (i.e., un-modern), a new user would be curious why modern-mode
   > isn't the default.  And as the discussion has showed, there is no
   > agreement what people think is modern.  So it would be simply better
   > to avoid the term "modern" completely.

   Yes, let's find a different name for this.  I'd object to calling it
   "modern", because I disagree that vanilla Emacs isn't.

A more specific name also means that not everything has to be added to
such a theme/mode -- as it has a specific goal to solve.  E.g., making
it easier for new users to use Emacs -- which is slightly different
from "modernizing" Emacs (similar sentiment to Eli there) which
Andrea(?) seemed want to address.

   newcomer-friendly-mode? new-to-emacs-mode? numacs-mode?

ersatz-mode?

Re: A modern-mode?

[Andrea Corallo via Emacs development discussions.]

ams@gnu.org (Alfred M. Szmidt) writes:

> A more specific name also means that not everything has to be added to
> such a theme/mode -- as it has a specific goal to solve.  E.g., making
> it easier for new users to use Emacs -- which is slightly different
> from "modernizing" Emacs (similar sentiment to Eli there) which
> Andrea(?) seemed want to address.

"modern" popular editors are made to be accessible and confortable to be
used for new comers.  This is the same problem.

Re: A modern-mode?

[Alfred M. Szmidt]

   > A more specific name also means that not everything has to be added to
   > such a theme/mode -- as it has a specific goal to solve.  E.g., making
   > it easier for new users to use Emacs -- which is slightly different
   > from "modernizing" Emacs (similar sentiment to Eli there) which
   > Andrea(?) seemed want to address.

   "modern" popular editors are made to be accessible and confortable to be
   used for new comers.  This is the same problem.

And the same is true for vanila Emacs.  

Maybe call this Bolios; in homage to Emack and Bolios from which the
name Emacs comes from.

Re: A modern-mode?

[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. ]]]

  > Maybe call this Bolios; in homage to Emack and Bolios from which the
  > name Emacs comes from.

The name "Emacs" has nothing to do with that store.  I did not know
about the store until after starting Emacs; when I tried it, I did not
particularly like it, and never went back.

-- 
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: A modern-mode?

[Alfred M. Szmidt]

     > Maybe call this Bolios; in homage to Emack and Bolios from which the
     > name Emacs comes from.

   The name "Emacs" has nothing to do with that store.  

Sorry, the joke/pun/whatever to call it was far to subtle -- modern
has nothing to do with modern, and Emacks and Bolio had nothing to do
with Emacs.  So a name that has nothing to do with either...

Re: A modern-mode?

[Lars Brinkhoff]

Alfred M. Szmidt wrote:
>      > Maybe call this Bolios; in homage to Emack and Bolios from
>      > which the name Emacs comes from.
>
>    The name "Emacs" has nothing to do with that store.  
>
> Sorry, the joke/pun/whatever to call it was far to subtle -- modern
> has nothing to do with modern, and Emacks and Bolio had nothing to do
> with Emacs.

This exchange is almost like the original AI koan:

| A cocky novice once said to Stallman: "I can guess why the editor is
| called Emacs, but why is the justifier called Bolio?"
| 
| Stallman replied forcefully: "Names are but names, 'Emack & Bolio's'
| is the name of a popular ice cream shop in Boston-town. Neither of
| these men had anything to do with the software."
| 
| His question answered, yet unanswered, the novice turned to go, but
| Stallman called to him: "Neither Emack nor Bolio had anything to do
| with the ice cream shop, either."

Re: A modern-mode?

[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. ]]]

  > | A cocky novice once said to Stallman: "I can guess why the editor is
  > | called Emacs, but why is the justifier called Bolio?"
  > | 
  > | Stallman replied forcefully: "Names are but names, 'Emack & Bolio's'
  > | is the name of a popular ice cream shop in Boston-town. Neither of
  > | these men had anything to do with the software."
  > | 
  > | His question answered, yet unanswered, the novice turned to go, but
  > | Stallman called to him: "Neither Emack nor Bolio had anything to do
  > | with the ice cream shop, either."

That joke is misleading, since I did not know any of that

When Bolio was written -- around 1980 I think -- I did not know
about the store.  I was puzzled by thek text formatter's name, and
asked what it meant.  Then I was told about the store.

-- 
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: A modern-mode?

[tomas]

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

On Wed, Sep 16, 2020 at 05:32:03PM +0300, Eli Zaretskii wrote:

[...]

> Yes, let's find a different name for this.  I'd object to calling it
> "modern", because I disagree that vanilla Emacs isn't.
> 
> newcomer-friendly-mode? new-to-emacs-mode? numacs-mode?

Millenial-mode? ;-P

Cheers
 - t

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

RE: A modern-mode?

[arthur miller]

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

+1 😁



Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: tomas@tuxteam.de
Datum: 2020-09-16 18:47 (GMT+01:00)
Till: emacs-devel@gnu.org
Ämne: Re: A modern-mode?

On Wed, Sep 16, 2020 at 05:32:03PM +0300, Eli Zaretskii wrote:

[...]

> Yes, let's find a different name for this.  I'd object to calling it
> "modern", because I disagree that vanilla Emacs isn't.
>
> newcomer-friendly-mode? new-to-emacs-mode? numacs-mode?

Millenial-mode? ;-P

Cheers
 - t

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

Re: A modern-mode?

[Daniel Martín]

>
> IMHO reading too much into names is not productive.  ‘Modern’ is a term
> that’s used fairly often in this context, and what to expect would be
> obvious to those who would want to use such a mode: features common to
> contemporary text editors.

"Modern" may give the impression that the rest of Emacs is old.  Maybe
emacs-beginner-mode, or some name that uses the word "familiar", or a
synonym?

Re: A modern-mode?

[Thibaut Verron]

> "Modern" may give the impression that the rest of Emacs is old.

I don't see a problem there.

> Maybe emacs-beginner-mode, or some name that uses the word "familiar",
> or a synonym?

Such a name would convey the impression that those settings are for
beginners and that experts prefer not to use them.

Re: A modern-mode?

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Wed, 16 Sep 2020 20:45:48 +0200
> Cc: Göktuğ Kayaalp <self@gkayaalp.com>,
>  Andrea Corallo <akrl@sdf.org>, emacs-devel <emacs-devel@gnu.org>
> 
> > Maybe emacs-beginner-mode, or some name that uses the word "familiar",
> > or a synonym?
> 
> Such a name would convey the impression that those settings are for
> beginners

Which they are.

> and that experts prefer not to use them.

How do you get this impression?  The name is not
emacs-beginner-but-not-expert-mode or anything to that effect.

Re: A modern-mode?

[Thibaut Verron]

> > Such a name would convey the impression that those settings are for
> > beginners
>
> Which they are.

I disagree. We are not talking about cua-mode or undo-only/redo-only
here. We are talking about full Emacs features which users usually
expect but need to discover. Those settings are for everybody, except
those who know that they don't want them.


> > and that experts prefer not to use them.
>
> How do you get this impression?  The name is not
> emacs-beginner-but-not-expert-mode or anything to that effect.

And modern-mode is not modern-and-not-completely-archaic-mode.
But in both cases, by choosing this name, we would state that it is
the best qualificative we could find for all those settings, and to me
it seems to imply that those settings are not for experts (resp.
not-completely-archaic).

I don't think that I'm the only one with this understanding, see for
example the earlier post suggesting the name newbie-mode (synonymous
to beginner-mode for me) with the idea that users would eventually
grow out of this mode, like training wheels. I don't consider any of
the suggested settings to be training wheels.

Re: A modern-mode?

[Alan Third]

On Wed, Sep 16, 2020 at 10:02:20PM +0200, Thibaut Verron wrote:
> I don't think that I'm the only one with this understanding, see for
> example the earlier post suggesting the name newbie-mode (synonymous
> to beginner-mode for me) with the idea that users would eventually
> grow out of this mode, like training wheels. I don't consider any of
> the suggested settings to be training wheels.

It's the use of the theme (or mode) that's expected to be "grown out
of". As the user progresses they'll discover they like this, but they
don't like that, and now they have to make the choice of whether to
disable the theme and just enable the features they want in their
init.el, or enable the theme and try to disable the features they
don't want in their init.el. I think the latter option is less
desirable and probably harder to achieve.

Perhaps the theme should come with documentation explaining what you
need to add to your init.el to achieve the same effects.
-- 
Alan Third

RE: A modern-mode?

[arthur miller]

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

Isn't what you describe just ordinary Emacs usage?  I mean we use Emacs, we grow out of default features and turn off/on stuff after hand as our knowledge and skills ?

By the way, why would anyone turn off features and then recreate them in their init file? It seems like very convoluted use case to me.



-------- Originalmeddelande --------
Från: Alan Third <alan@idiocy.org>
Datum: 2020-09-16 23:37 (GMT+01:00)
Till: Thibaut Verron <thibaut.verron@gmail.com>
Kopia: self@gkayaalp.com, Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org>, mardani29@yahoo.es, akrl@sdf.org
Ämne: Re: A modern-mode?

On Wed, Sep 16, 2020 at 10:02:20PM +0200, Thibaut Verron wrote:
> I don't think that I'm the only one with this understanding, see for
> example the earlier post suggesting the name newbie-mode (synonymous
> to beginner-mode for me) with the idea that users would eventually
> grow out of this mode, like training wheels. I don't consider any of
> the suggested settings to be training wheels.

It's the use of the theme (or mode) that's expected to be "grown out
of". As the user progresses they'll discover they like this, but they
don't like that, and now they have to make the choice of whether to
disable the theme and just enable the features they want in their
init.el, or enable the theme and try to disable the features they
don't want in their init.el. I think the latter option is less
desirable and probably harder to achieve.

Perhaps the theme should come with documentation explaining what you
need to add to your init.el to achieve the same effects.
--
Alan Third


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

Re: A modern-mode?

[Alan Third]

On Thu, Sep 17, 2020 at 12:11:04AM +0000, arthur miller wrote:
> Isn't what you describe just ordinary Emacs usage? I mean we use
> Emacs, we grow out of default features and turn off/on stuff after
> hand as our knowledge and skills ?
> 
> By the way, why would anyone turn off features and then recreate
> them in their init file? It seems like very convoluted use case to
> me.

As opposed to turning on features with a theme then turning them off
again in their init file?

I've seen enough people ask how to implement spacemacs/doom features
in vanilla Emacs to know that this happens.
-- 
Alan Third

Re: A modern-mode?

[Stefan Monnier]

>> By the way, why would anyone turn off features and then recreate
>> them in their init file? It seems like very convoluted use case to
>> me.
> As opposed to turning on features with a theme then turning them off
> again in their init file?
> I've seen enough people ask how to implement spacemacs/doom features
> in vanilla Emacs to know that this happens.

BTW one of the advantages of themes is also that we could provide a UI
that displays the various elements of that theme (without having to show
ELisp code).


        Stefan

RE: A modern-mode?

[arthur miller]

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

Can't customize already show ui to turn on/off features without showing elisp?

Can't there be just a customize group or page where people can turn on/off features and similar?  What makes theme more suitable?

I am sorry if I am a tad bit obnoxious, my goal is not to be negative, just "thinking loud".



-------- Originalmeddelande --------
Från: Stefan Monnier <monnier@iro.umontreal.ca>
Datum: 2020-09-17 21:43 (GMT+01:00)
Till: Alan Third <alan@idiocy.org>
Kopia: arthur miller <arthur.miller@live.com>, Thibaut Verron <thibaut.verron@gmail.com>, self@gkayaalp.com, akrl@sdf.org, Eli Zaretskii <eliz@gnu.org>, mardani29@yahoo.es, emacs-devel <emacs-devel@gnu.org>
Ämne: Re: A modern-mode?

>> By the way, why would anyone turn off features and then recreate
>> them in their init file? It seems like very convoluted use case to
>> me.
> As opposed to turning on features with a theme then turning them off
> again in their init file?
> I've seen enough people ask how to implement spacemacs/doom features
> in vanilla Emacs to know that this happens.

BTW one of the advantages of themes is also that we could provide a UI
that displays the various elements of that theme (without having to show
ELisp code).


        Stefan


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

Re: A modern-mode?

[Arthur Miller]

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

> Can't customize already show ui to turn on/off features without showing elisp? 
>
> Can't there be just a customize group or page where people can turn on/off features and similar?  What makes theme more
> suitable?
>
> I am sorry if I am a tad bit obnoxious, my goal is not to be negative, just "thinking loud".
>
> -------- Originalmeddelande --------
> Från: Stefan Monnier <monnier@iro.umontreal.ca> 
> Datum: 2020-09-17 21:43 (GMT+01:00) 
> Till: Alan Third <alan@idiocy.org> 
> Kopia: arthur miller <arthur.miller@live.com>, Thibaut Verron <thibaut.verron@gmail.com>, self@gkayaalp.com, akrl@sdf.org, Eli
> Zaretskii <eliz@gnu.org>, mardani29@yahoo.es, emacs-devel <emacs-devel@gnu.org> 
> Ämne: Re: A modern-mode? 
>
>>> By the way, why would anyone turn off features and then recreate
>>> them in their init file? It seems like very convoluted use case to
>>> me.
>> As opposed to turning on features with a theme then turning them off
>> again in their init file?
>> I've seen enough people ask how to implement spacemacs/doom features
>> in vanilla Emacs to know that this happens.
>
> BTW one of the advantages of themes is also that we could provide a UI
> that displays the various elements of that theme (without having to show
> ELisp code).
>
>         Stefan

Sorry, I have been looking into manual about themes and custom.el; sure
theme can do anything so I understand it now :-).

"Custom themes are collections of settings that can be enabled or
disabled as a unit. You can use Custom themes to switch easily between
various collections of settings, and to transfer such collections from
one computer to another. "

".... loading a Custom theme can execute arbitrary Lisp code ..."

"To apply the choice of theme(s) to future Emacs sessions, type C-x C-s
(custom-theme-save) or use the ‘[Save Theme Settings]’ button."

So indeed  it can be used for anything. Though I would rather call
such theme for a "mode" but that would be really a confusion since Emacs
modes are different things.

Re: A modern-mode?

[Thibaut Verron]

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

Le mer. 16 sept. 2020 à 23:36, Alan Third <alan@idiocy.org> a écrit :

> On Wed, Sep 16, 2020 at 10:02:20PM +0200, Thibaut Verron wrote:
> > I don't think that I'm the only one with this understanding, see for
> > example the earlier post suggesting the name newbie-mode (synonymous
> > to beginner-mode for me) with the idea that users would eventually
> > grow out of this mode, like training wheels. I don't consider any of
> > the suggested settings to be training wheels.
>
> It's the use of the theme (or mode) that's expected to be "grown out
> of". As the user progresses they'll discover they like this, but they
> don't like that, and now they have to make the choice of whether to
> disable the theme and just enable the features they want in their
> init.el, or enable the theme and try to disable the features they
> don't want in their init.el. I think the latter option is less
> desirable and probably harder to achieve.
>
> Perhaps the theme should come with documentation explaining what you
> need to add to your init.el to achieve the same effects.
>

But why is that a good thing? The point as I understand it is that all
those features were suggested to be activated by default (some of them
are). Because we cannot so easily change the defaults, this mode gives an
easy entry point to users wanting those defaults (even if they don't know
it yet).

If they were defaults we wouldn't expect the users to explicitly re-add
them to their init.el (actually, if we did, there wouldn't be a problem
with changing the defaults in the first place). So why treat this mode any
differently?

If this mode is implemented, I'd probably go the other route and remove the
corresponding settings in my init.el and invoke the mode instead. Just as I
would do with anything else I would be doing by hand but now comes
built-in, to avoid duplicating the work of maintaining the code.

As for disabling individual features, it's been suggested that the mode
offers customization for its individual options, so there shouldn't be any
need for elisp to activate or deactivate individual options.

>

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

Re: A modern-mode?

[Lars Ingebrigtsen]

Thibaut Verron <thibaut.verron@gmail.com> writes:

> I don't think that I'm the only one with this understanding, see for
> example the earlier post suggesting the name newbie-mode (synonymous
> to beginner-mode for me) with the idea that users would eventually
> grow out of this mode, like training wheels. I don't consider any of
> the suggested settings to be training wheels.

Yeah, `newbie-mode' or anything similar to that would just be an insult.

This should be an opinionated and curated selection of good modes and
themes, and there's nothing "newbie" or "beginner" about that.

And there should, of course, be more than one of these.  Just give them
fun names, like, say, "Doom" or "Quake".

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

Re: A modern-mode?

[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 word modern has a negative meaning in that it implies that the
  > rest of Emacs isn't modern -- why would users ever want to switch of
  > "modern-mode" and use the un-modern Emacs?

How about Faddish mode?
Fashionable mode?

Mode mode?

-- 
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: A modern-mode?

[Ergus]

On Wed, Sep 16, 2020 at 07:27:10AM +0000, Andrea Corallo via Emacs development discussions. wrote:
>ams@gnu.org (Alfred M. Szmidt) writes:
>
>> What was once modern will become old again, and what was old again
>> will become modern.
>
>One important aspect of this collection of settings is that we should be
>less committed to (eternal :) immutability as we are for normal
>defaults.
>
>As this is meant to be an help for new starters we should feel free to
>improve these from release to release without a negative impact on old
>new starters, as by definition they are not anymore new starters :)
>
>IOW If they stayed around for more than a release cycle quite certainly
>they have learned how to personalize Emacs themselves.
>
>  Andrea
>
Maybe instead of modern we should call it experimental/develop... (:
looking the discussion here we should call it warrior or rebel ;)

Re: A modern-mode?

[Robert Pluim]

>>>>> On Wed, 16 Sep 2020 01:14:52 -0400, ams@gnu.org (Alfred M. Szmidt) said:

    Alfred>    following recent discussions I've started toying with what I've pushed on
    Alfred>    scratch/modern-mode.

    Alfred> What some find modern, some will find old.  What some find old, some
    Alfred> will find modern.  What was once modern will become old again, and
    Alfred> what was old again will become modern.

    Alfred> A different name would be more appropriate.

cadt-mode? (with apologies to jwz)

Robert

Re: A modern-mode?

[tomas]

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

On Wed, Sep 16, 2020 at 09:33:50AM +0200, Robert Pluim wrote:

[...]

> cadt-mode? (with apologies to jwz)

But then, it would have to change every two weeks. Since that might
become tedious for devels, which also have to squash bugs here and
there, I propose a genetic annealing driven mode generator fed by
a machine learning program which scans the Internets for new trends.

Perhaps agent-based.

;-P

Cheers
 - t

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

Re: A modern-mode?

[João Távora]

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

On Wed, Sep 16, 2020 at 6:15 AM Alfred M. Szmidt <ams@gnu.org> wrote:

>    following recent discussions I've started toying with what I've pushed
> on
>    scratch/modern-mode.
>
> What some find modern, some will find old.  What some find old, some
> will find modern.  What was once modern will become old again, and
> what was old again will become modern.
>
> A different name would be more appropriate


Yup, this is really obvious to me, too (*)  I seem to remember that
other packages don't have a lot of problems naming some
features "fancy".  Does "fancy" have a negative connotation?
Maybe it does, as does e.g. "baroque".  Both terms indicate
an "elaboration" or an "amplification" beyond some essential
state, which would be Emacs -Q, I guess.

fancy-mode? rich-mode? amplified-mode? ornate-mode? Why not
just andrea-mode?

João

* though "modernism" is itself considered a style, reasonably
well defined within the 20th century, but that doesn't matter,
unless we are purposely trying to emulate that style in Emacs,
which I don't think we are. On a tangent, Emacs defaults
themselves could even be seen as modernist already, form
mostly follows function, rejects most ornament, etc etc

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

Re: A modern-mode?

[tomas]

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

On Wed, Sep 16, 2020 at 10:36:23AM +0100, João Távora wrote:
> On Wed, Sep 16, 2020 at 6:15 AM Alfred M. Szmidt <ams@gnu.org> wrote:
> 
> >    following recent discussions I've started toying with what I've pushed
> > on
> >    scratch/modern-mode.
> >
> > What some find modern, some will find old.  What some find old, some
> > will find modern.  What was once modern will become old again, and
> > what was old again will become modern.
> >
> > A different name would be more appropriate
> 
> 
> Yup, this is really obvious to me, too (*)  I seem to remember that
> other packages don't have a lot of problems naming some
> features "fancy".  Does "fancy" have a negative connotation?

De Luxe?

But more seriously: what I have learnt from all this discussion
is that we'll need more than one of those.

Those modes are often opinionated (they have to). So it's better
if the mode's opinions align with those of the user.

It'll be Emacs's job to provide the bridges and the common base
for all of that (someone in this monster thread quoted X11's
motto of providing "mechanism, not policy": I think this is
 - mutatis mutandis - a good guiding principle).

Cheers
 - t

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

Re: A modern-mode?

[João Távora]

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

On Wed, Sep 16, 2020 at 10:50 AM <tomas@tuxteam.de> wrote:

> On Wed, Sep 16, 2020 at 10:36:23AM +0100, João Távora wrote:
> > On Wed, Sep 16, 2020 at 6:15 AM Alfred M. Szmidt <ams@gnu.org> wrote:
> >
> > >    following recent discussions I've started toying with what I've
> pushed
> > > on
> > >    scratch/modern-mode.
> > >
> > > What some find modern, some will find old.  What some find old, some
> > > will find modern.  What was once modern will become old again, and
> > > what was old again will become modern.
> > >
> > > A different name would be more appropriate
> >
> >
> > Yup, this is really obvious to me, too (*)  I seem to remember that
> > other packages don't have a lot of problems naming some
> > features "fancy".  Does "fancy" have a negative connotation?
>
> De Luxe?
>
> But more seriously: what I have learnt from all this discussion
> is that we'll need more than one of those.
>
> Those modes are often opinionated (they have to). So it's better
> if the mode's opinions align with those of the user.\
>

Good point: these are opinionated things by nature, so they
should be named as themes are, somewhat freely according
to the vision of their authors. This also reveals that the
thing shouldn't be called a "mode" at all. It should be done
with custom-themes and if that proves a limitation, then
custom-themes have to be improved, maybe even reinvented.

João

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

Re: A modern-mode?

[tomas]

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

On Wed, Sep 16, 2020 at 10:54:43AM +0100, João Távora wrote:

[...]

> Good point: these are opinionated things by nature, so they
> should be named as themes are, somewhat freely according
> to the vision of their authors. This also reveals that the
> thing shouldn't be called a "mode" at all. It should be done
> with custom-themes and if that proves a limitation, then
> custom-themes have to be improved, maybe even reinvented.

We can set up our own giant feedback loops, too :-)

Cheers
 - t

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

Re: A modern-mode?

[João Távora]

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

On Wed, Sep 16, 2020 at 11:20 AM <tomas@tuxteam.de> wrote:

> On Wed, Sep 16, 2020 at 10:54:43AM +0100, João Távora wrote:
>
> [...]
>
> > Good point: these are opinionated things by nature, so they
> > should be named as themes are, somewhat freely according
> > to the vision of their authors. This also reveals that the
> > thing shouldn't be called a "mode" at all. It should be done
> > with custom-themes and if that proves a limitation, then
> > custom-themes have to be improved, maybe even reinvented.
>
> We can set up our own giant feedback loops, too :-)
>

Not sure what you mean, I just meant the "custom-themes"
infrastructure should be enough to accommodate enough of
the proposed "modern-mode".  Not sure if it is (as I don't use it).

I think reasonably solutions with a lot of value and relatively
little code are often in front of our eyes. Such was the case
with icomplete being a good basis for fido-mode, which seems
good enough that people are even recommending it. I'm
almost always wary of giants or grand reinventions of things.
For the "base" Emacs experience that is, in their setups people
can use all the ivys, dooms, helms and magits they want.

João

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

Re: A modern-mode?

[tomas]

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

On Wed, Sep 16, 2020 at 11:30:18AM +0100, João Távora wrote:
> On Wed, Sep 16, 2020 at 11:20 AM <tomas@tuxteam.de> wrote:
> 
> > On Wed, Sep 16, 2020 at 10:54:43AM +0100, João Távora wrote:
> >
> > [...]
> >
> > > Good point: these are opinionated things by nature, so they
> > > should be named as themes are, somewhat freely according
> > > to the vision of their authors. This also reveals that the
> > > thing shouldn't be called a "mode" at all. It should be done
> > > with custom-themes and if that proves a limitation, then
> > > custom-themes have to be improved, maybe even reinvented.
> >
> > We can set up our own giant feedback loops, too :-)
> >
> 
> Not sure what you mean, I just meant the "custom-themes"
> infrastructure should be enough to accommodate enough of
> the proposed "modern-mode".  Not sure if it is (as I don't use it).

Sorry -- was a lame self-reference. I characterised at some
point that whatever is currently considered "ergonomic" is
but part of a giant feedback loop involving (among many other
things, like genuine UI research) big corp's marketing departments.

What you wrote offered itself as another kind of feedback
loop: opinionated "custom-themes" (or whatever we end up
naming that) informing the Emacs core about whatever tech
or concepts are necessary to keep the whole ship together.

> I think reasonably solutions with a lot of value and relatively
> little code are often in front of our eyes. Such was the case
> with icomplete being a good basis for fido-mode, which seems
> good enough that people are even recommending it. I'm
> almost always wary of giants or grand reinventions of things.
> For the "base" Emacs experience that is, in their setups people
> can use all the ivys, dooms, helms and magits they want.

So Emacs has been doing that all along, it seems... And still,
this kind of discussions seem necessary and fruitful.

Cheers
 - t

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

Re: A modern-mode?

[João Távora]

tomas@tuxteam.de writes:

> loop: opinionated "custom-themes" (or whatever we end up
> naming that) informing the Emacs core about whatever tech
> or concepts are necessary to keep the whole ship together.
>

Right.  New features often come with a component of infrastruture and
component of user code that relies on it.

>> I think reasonably solutions with a lot of value and relatively
>> little code are often in front of our eyes. Such was the case
>> with icomplete being a good basis for fido-mode, which seems
>> good enough that people are even recommending it. I'm
>> almost always wary of giants or grand reinventions of things.
>> For the "base" Emacs experience that is, in their setups people
>> can use all the ivys, dooms, helms and magits they want.
> this kind of discussions seem necessary and fruitful.
>

Emacs has always had this "problem" which is brought about by the huge
flexibility that Elisp affords.  But those kitchen-sink developments
don't always integrate cleanly into Emacs for various reasons (from
legal to technical).

Custom themes can be used to tweak aspects _already_ in Emacs, and doing
the latter would make long strides towards newcomer-friendliness, I
think (and I also think we've all kind of agreed on that, bringing us to
the "defaults" argument").

Anyway, my impression is that, custom themes don't seem to be used
effectively, except to customize colors.  Maybe they're not powerful
enough?  They do seem to have features that are extremely desirable
here, such as ease of distribution, ease of composition and
human-readability (for non-programmers).

João

Re: A modern-mode?

[Arthur Miller]

João Távora <joaotavora@gmail.com> writes:

>                          I just meant the "custom-themes" 
> infrastructure should be enough to accommodate enough of 
> the proposed "modern-mode".  Not sure if it is (as I don't use it).
No, it is not. It lacks unified framework to use as logicla names for
color use; someting similar to what you have in <h1>, <h2>, ... <h8> in
html, just as example. Instead people use rgb values directly in their
packages, and when user changes a theme, packages does not follow. So
theme engine in Emacs needs a little additional work.

>  I'm 
> almost always wary of giants or grand reinventions of things.
> For the "base" Emacs experience that is, in their setups people 
> can use all the ivys, dooms, helms and magits they want.
I understand your sentiment, but then, you could say this for any
feature, inclusive fido-mode or icomplete or even find-file.

Just as an illustration one could argue that "simpler" open-file as
found in other software packages is what "casual" users would expext.
Personally I would like to see ffap being enabled as default ... 

Re: A modern-mode?

[João Távora]

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

On Wed, Sep 16, 2020 at 1:40 PM Arthur Miller <arthur.miller@live.com>
wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> >                          I just meant the "custom-themes"
> > infrastructure should be enough to accommodate enough of
> > the proposed "modern-mode".  Not sure if it is (as I don't use it).
> No, it is not. It lacks unified framework to use as logicla names for
> color use; someting similar to what you have in <h1>, <h2>, ... <h8> in
> html, just as example. Instead people use rgb values directly in their
> packages, and when user changes a theme, packages does not follow. So
> theme engine in Emacs needs a little additional work.
>

In theming, Emacs works with faces, not with colors. Those
would seem to be sufficient logical placeholders for
various types of colors.  But indeed my message suffered
from this confusion, too.


> >  I'm
> > almost always wary of giants or grand reinventions of things.
> > For the "base" Emacs experience that is, in their setups people
> > can use all the ivys, dooms, helms and magits they want.
> I understand your sentiment, but then, you could say this for any
> feature, inclusive fido-mode or icomplete or even find-file.
>

I don't think you can. It's because of their simplicity that they
are much better integrated into Emacs's infrastructure. Compare
the number of lines and the number of configuration options
in fido-mode/icomplete-mode to the same number in those other
packages. These are leaner packages, they follow the existing
infrastructure as much as possible, rather than reinvent it.

But if the complexity comparison isn't satisfying to you, it's easy
to note that changes to the infrastructure, i.e. completion styles,
are "naturally" absorbed by icomplete-mode and fido-mode,
whereas a package such as Helm had to go through great
efforts to support them (reasonably recently).  And Ivy still
doesn't support them, as far as I know. In another example,
multiple reinventions of the "imenu" display frontend, which read
the menu item information directly have failed to account for
recent augmentation of that format.  Fido-mode provides a
different visualization of M-x imenu without suffering from
those problems, playing along with M-x imenu, rather than
re-implemeting it.  Reinventing a parallel infrastructure, easy as
it is to do in Lisp/Emacs, has those very real drawbacks.

Just as an illustration one could argue that "simpler" open-file as
> found in other software packages is what "casual" users would expext.
>

Yes, you can argue that.  I would maybe agree, though I wouldn't agree
we should give those users exactly what they "expect", because they
"expect" VSCode, I guess. But making a custom theme allow such
modifications is what is needed, in my opinion. Then, if I'm mistaken,
enabling that idea is just a few clicks away.

Personally I would like to see ffap being enabled as default ...
>

Don't understand this bit.  I use ffap a lot and don't need to "enable"
anything, just M-x ffap. Is it a mode?

João

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

Re: A modern-mode?

[Arthur Miller]

João Távora <joaotavora@gmail.com> writes:

> On Wed, Sep 16, 2020 at 1:40 PM Arthur Miller <arthur.miller@live.com> wrote:
>
>  João Távora <joaotavora@gmail.com> writes:
>
>  >                          I just meant the "custom-themes" 
>  > infrastructure should be enough to accommodate enough of 
>  > the proposed "modern-mode".  Not sure if it is (as I don't use it).
>  No, it is not. It lacks unified framework to use as logicla names for
>  color use; someting similar to what you have in <h1>, <h2>, ... <h8> in
>  html, just as example. Instead people use rgb values directly in their
>  packages, and when user changes a theme, packages does not follow. So
>  theme engine in Emacs needs a little additional work.
>
> In theming, Emacs works with faces, not with colors. Those 
> would seem to be sufficient logical placeholders for 
> various types of colors.  But indeed my message suffered
> from this confusion, too.
You are probably correct about this one. I myself are not very well
acustomed to theming engine, faces, defface etc so I might not be aware
that this mechanism already is there. Question is why 3rd party packages
don't use those placeholders? Is it lack of documentation? Or something else.

>  >  I'm 
>  > almost always wary of giants or grand reinventions of things.
>  > For the "base" Emacs experience that is, in their setups people 
>  > can use all the ivys, dooms, helms and magits they want.
>  I understand your sentiment, but then, you could say this for any
>  feature, inclusive fido-mode or icomplete or even find-file.
>
> I don't think you can. It's because of their simplicity that they 
> are much better integrated into Emacs's infrastructure. Compare
> the number of lines and the number of configuration options
> in fido-mode/icomplete-mode to the same number in those other 
> packages. These are leaner packages, they follow the existing
> infrastructure as much as possible, rather than reinvent it.
It is a little bit oranges to apples comparison. Helm offered quite
different interaction model for completions then what was originally
in Emacs. I don't know if fido/icomplete were in place then, so it
is natural that complexity is there. Also offered set of feature is not
the same. Just being simpler in terms of complexity is not good enough
measure of quality, although it might be a reason good enough to use
something. Observer also that when Ivy & Co get to level of Helm
functionality it will probably be as complex as Helm. Same for other
completions etc.

> But if the complexity comparison isn't satisfying to you, it's easy
> to note that changes to the infrastructure, i.e. completion styles,
> are "naturally" absorbed by icomplete-mode and fido-mode, 
> whereas a package such as Helm had to go through great
> efforts to support them (reasonably recently).
Indeed, but it is in the nature of the thing, since it historically had
to invent what was later added to Emacs core? If I understnd the history
correct (correct me if I am wrong).

> Don't understand this bit.  I use ffap a lot and don't need to "enable"
> anything, just M-x ffap. Is it a mode?
Ok, I wasn't precise, it isn't a mode, but one can enable ffap bindings
automatically so they replace ordinary ones by default.

Re: A modern-mode?

[João Távora]

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

> João Távora <joaotavora@gmail.com> writes:

> that this mechanism already is there. Question is why 3rd party packages
> don't use those placeholders? Is it lack of documentation? Or
> something else.

I think they do use them.  When I load theme A it uses something for
say, the diff-added face.  When I laod theme B it uses something else.

>>>  I understand your sentiment, but then, you could say this for any
>>> feature, inclusive fido-mode or icomplete or even find-file.
>> I don't think you can. It's because of their simplicity that they 
>> are much better integrated into Emacs's infrastructure. Compare
>> the number of lines and the number of configuration options
>> in fido-mode/icomplete-mode to the same number in those other 
>> packages. These are leaner packages, they follow the existing
>> infrastructure as much as possible, rather than reinvent it.
> It is a little bit oranges to apples comparison.

Well you brought up fido-mode, not I.

> Helm offered quite
> different interaction model for completions then what was originally
> in Emacs. I don't know if fido/icomplete were in place then,

Pretty sure icomplete was.

> so it is natural that complexity is there. Also offered set of feature
> is not the same. Just being simpler in terms of complexity is not good
> enough measure of quality, although it might be a reason good enough
> to use something. Observer also that when Ivy & Co get to level of
> Helm functionality it will probably be as complex as Helm. Same for
> other completions etc.

I'm not convinced about that, simply because helm duplicates a lot of
stuff that is already in Emacs.  

I'm not saying fido-mode offers the same features, just that you can add
features to it, say "acting on completions", in a way that integrates
cleanly with existing infrastructure, without having to make new
infrastructure.  Helm took the route of making its own parallel
infrastructure.  So when a user uses some option to customize the former
it doesn't affect the latter automatically, it has to be replicated.

This is a simple matter of modular architecture.  Helm's base is used by
little more than Helm itself, in contrast to Emacs's own infrastructure.

>> But if the complexity comparison isn't satisfying to you, it's easy
>> to note that changes to the infrastructure, i.e. completion styles,
>> are "naturally" absorbed by icomplete-mode and fido-mode, 
>> whereas a package such as Helm had to go through great
>> efforts to support them (reasonably recently).
> Indeed, but it is in the nature of the thing, since it historically had
> to invent what was later added to Emacs core? If I understnd the history
> correct (correct me if I am wrong).

You are mostly wrong.  Icomplete already existed and so did Imenu.  But
that's not the same as saying that infrastructure at the time was
sufficient for Helm's vision, or even that it is now.  I'm just saying
that adding capabilities to existing infrastructure is a good thing, and
by contrast making a parallel infrastructure is less of a good thing.
Doing the former is hard because design decisions are carefully
considered since they have to serve multiple clients.  Doing the latter
is easier and a good way to churn out features quickly.  But alas, it
creates the problems I explained.

Sometimes things will get integrated into Emacs core, depending on how
generic they were.  For example xref.el came as a rewrite of SLIME's
cross-referencing functionality.  But it's a bit too ambitious to
integrate say, Helm's completion gathering code with Emacs's.  Some of
Helm's interesting features can be copied, but that, again, takes work.

>> Don't understand this bit.  I use ffap a lot and don't need to
>> "enable" anything, just M-x ffap. Is it a mode?
> Ok, I wasn't precise, it isn't a mode, but one can enable ffap bindings
> automatically so they replace ordinary ones by default.

Still confused. Ffap is "find file at point" right?  What do you want to
replace with it?

João

Re: A modern-mode?

[Thibaut Verron]

> >> Don't understand this bit.  I use ffap a lot and don't need to
> >> "enable" anything, just M-x ffap. Is it a mode?
> > Ok, I wasn't precise, it isn't a mode, but one can enable ffap bindings
> > automatically so they replace ordinary ones by default.
>
> Still confused. Ffap is "find file at point" right?  What do you want to
> replace with it?

Maybe he means binding C-x C-f to ffap when point is on a file path
(not a great idea in my experience) or to have the file name at point
pre-entered in the completion prompt (I personally have that behavior
enabled)?

Re: A modern-mode?

[João Távora]

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

On Wed, Sep 16, 2020 at 4:43 PM Thibaut Verron <thibaut.verron@gmail.com>
wrote:

> > >> Don't understand this bit.  I use ffap a lot and don't need to
> > >> "enable" anything, just M-x ffap. Is it a mode?
> > > Ok, I wasn't precise, it isn't a mode, but one can enable ffap bindings
> > > automatically so they replace ordinary ones by default.
> >
> > Still confused. Ffap is "find file at point" right?  What do you want to
> > replace with it?
>
> Maybe he means binding C-x C-f to ffap when point is on a file path
> (not a great idea in my experience) or to have the file name at point
> pre-entered in the completion prompt (I personally have that behavior
> enabled)?
>

Thanks.  The latter makes more sense, indeed. But will be surprising
for some users, I guess.

João

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

Re: A modern-mode?

[Arthur Miller]

João Távora <joaotavora@gmail.com> writes:

>  >  I'm 
>  > almost always wary of giants or grand reinventions of things.
>  > For the "base" Emacs experience that is, in their setups people 
>  > can use all the ivys, dooms, helms and magits they want.
>  I understand your sentiment, but then, you could say this for any
>  feature, inclusive fido-mode or icomplete or even find-file.
>
> I don't think you can. It's because of their simplicity that they 
> are much better integrated into Emacs's infrastructure.
Just add few more thoughts: I don't think it is bc of simplicity, but
because they incorporate functionality that wasn's present when Helm/Ivy
were written.

Re: A modern-mode?

[tomas]

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

On Wed, Sep 16, 2020 at 02:40:53PM +0200, Arthur Miller wrote:
> João Távora <joaotavora@gmail.com> writes:
> 
> >                          I just meant the "custom-themes" 
> > infrastructure should be enough to accommodate enough of 
> > the proposed "modern-mode".  Not sure if it is (as I don't use it).
> No, it is not. It lacks unified framework to use as logicla names for
> color use;

Isn't "face" the better abstraction, anyway? Think blind people.
Think color-blind people (up to 8% of the male and 0.5% of the
female population of Norther European descent [1]).

Conveying semantics via color has to have some fallback, and
this meshes well with faces, I think.

Cheers

[1] https://en.wikipedia.org/wiki/Color_blindness

 - t

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

RE: A modern-mode?

[arthur miller]

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

Any logical explanation why females have got that much better deal with colors than guys from the evolution?

Sure, I completely agree that faces are better to work with then plain colors. Imaginary framework could have co exist of base-faces and accent-faces instead of base-colors and accent-colors (if this separation is even acceptable).


-------- Originalmeddelande --------
Från: tomas@tuxteam.de
Datum: 2020-09-16 18:43 (GMT+01:00)
Till: Arthur Miller <arthur.miller@live.com>
Kopia: João Távora <joaotavora@gmail.com>, emacs-devel <emacs-devel@gnu.org>
Ämne: Re: A modern-mode?

On Wed, Sep 16, 2020 at 02:40:53PM +0200, Arthur Miller wrote:
> João Távora <joaotavora@gmail.com> writes:
>
> >                          I just meant the "custom-themes"
> > infrastructure should be enough to accommodate enough of
> > the proposed "modern-mode".  Not sure if it is (as I don't use it).
> No, it is not. It lacks unified framework to use as logicla names for
> color use;

Isn't "face" the better abstraction, anyway? Think blind people.
Think color-blind people (up to 8% of the male and 0.5% of the
female population of Norther European descent [1]).

Conveying semantics via color has to have some fallback, and
this meshes well with faces, I think.

Cheers

[1] https://en.wikipedia.org/wiki/Color_blindness

 - t

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

Re: A modern-mode?

[Alan Third]

On Wed, Sep 16, 2020 at 09:46:58PM +0000, arthur miller wrote:
> Any logical explanation why females have got that much better deal
> with colors than guys from the evolution?

The gene for colour blindness is carried on the X chromosome, males
only have one copy but females have two, therefore females have two
chances to get a "correct" gene.

There are some other related effects, like tetrachromacy, and
apparently cats with more than two colours of fur are all female for
similar reasons.
-- 
Alan Third

RE: A modern-mode?

[arthur miller]

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

That was cool to learn.

Thank you!


-------- Originalmeddelande --------
Från: Alan Third <alan@idiocy.org>
Datum: 2020-09-17 21:28 (GMT+01:00)
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel <emacs-devel@gnu.org>
Ämne: Re: A modern-mode?

On Wed, Sep 16, 2020 at 09:46:58PM +0000, arthur miller wrote:
> Any logical explanation why females have got that much better deal
> with colors than guys from the evolution?

The gene for colour blindness is carried on the X chromosome, males
only have one copy but females have two, therefore females have two
chances to get a "correct" gene.

There are some other related effects, like tetrachromacy, and
apparently cats with more than two colours of fur are all female for
similar reasons.
--
Alan Third

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

Re: A modern-mode?

[Arthur Miller]

<tomas@tuxteam.de> writes:

> Those modes are often opinionated (they have to). So it's better
> if the mode's opinions align with those of the user.
What I have learned by following emacs-dev mail list is that any,
feature here is opinionated.

> It'll be Emacs's job to provide the bridges and the common base
> for all of that (someone in this monster thread quoted X11's
> motto of providing "mechanism, not policy": I think this is
>  - mutatis mutandis - a good guiding principle).
Indeed, "mechanism not policy" is one of the the best feature of X11
(along with being a network protocol too).