Re: Changes for emacs 28

Re: Changes for emacs 28

[TEC]

Hello everyone,

This is my first time jumping onto the emacs-devel ML so don't be too
harsh :P (also, I'm not subscribed, so if there are anyone wants to
mention me, please CC me).

Yesterday, Gregory Heytings wrote
> FWIW, my own experience with this kind of tools is that those who do
> not have initially a good non-technical reason to use it ...
> This external motivation is necessary to "climb the learning curve",
> so to speak, and "better" defaults will have no influence on it.

If I may interject - I am exactly that user. I started using Emacs via.
Doom early this year, and I honestly doubt that I would still be using
it now otherwise.

The motivating factor was annoyance with JupyterLab. Doom allowed me to
'get started' easily. Looking back on it now, had I had to "climb the
mountain", I don't think I'd be here today. I think I can thank Doom for
turning "climb the mountain" into "slide down the rabbit-hole".

IMO the most significant factor is that Doom allowed me to "just get
started" with the tasks which caused my lingering interest to manifest
into installing. While now I couldn't imagine going without Emacs, that
initial ease was crucial.

If there is further interest in exactly how I think Doom worked for me
when vanilla Emacs wouldn't, I'm more than happy to elaborate :)

All the best,

Timothy.

Re: Changes for emacs 28

[Yuan Fu]

> 
> If there is further interest in exactly how I think Doom worked for me
> when vanilla Emacs wouldn't, I'm more than happy to elaborate :)
> 
> All the best,
> 
> Timothy.
> 

That’ll be very helpful, since many people on this ML are trying to imagine what a new user needs and can’t figure out. Even myself, just started using Emacs 3 years ago, can’t remember what problem I faced as a beginner anymore.

Yuan

Re: Changes for emacs 28

[TEC]

Yuan Fu <casouri@gmail.com> writes:

> That’ll be very helpful, since many people on this ML are trying to
> imagine what a new user needs and can’t figure out. Even myself, just
> started using Emacs 3 years ago, can’t remember what problem I faced
> as a beginner anymore.

All right then, I'll try to give a dot point version of my journey into
Emacs, and background/context. I hope this ends up being useful :)

* Prior editor experience (~2y in each) : total ~8 years
- I started off several years ago in IDLE (yes, that Tk python thing)
- I then used Komodo edit for a bit, started doing web stuff
- I shifted to Brackets for web stuff
- I shifted to VS Code, for everything

* VS Code
- VS Code is a great editor
- Everything just worked™, and the experience was generally smooth
- Used VS Code for: Python, Web(HTML,CSS,JS,TS), Rust, LaTeX
- I started writing /lots/ of LaTeX, so much that I became (for a
  period) the #3 contributor to the 'main' LaTeX extension (~500k users)
  and then went off and developed an extension to that extension :P
  (https://marketplace.visualstudio.com/items?itemName=tecosaur.latex-utilities)
- Why does this matter? At this point I'm *heavily* invested into VS
  Code. I'll need to be quite confident of a better experience in order
  to switch.
* VS Code pain points
- I like windows. VS Code's windows are independent electron instances.
  Not good (for UX, or RAM).
- Extension API felt a bit limiting a few times, I'd gaze at open
  issues/PRs in desperation that they'd actually be resolved

* Emacs, the warmup
- I'd heard a few things that sounded interesting about Emacs
  (read: faint inclination to see what the fuss was about)
- I like living in my editor (as long as it's comfortable), I didn't
  like it when I had to type into a barren textbox on the web (e.g.
  writing a GitHub issue).
- I became aware of the client/server archetecture, and EmacsAnywhere
- Installed EmacsAnywhere, and grabbed Spacemacs because it looked
  trendy (I'm serious, I /care/ about visuals, and the Spacemacs web page
  and screenshots were most attractive)
- Used a little bit, on and off, was pretty underwhelmed.
- Tried setting a few things in Spacemacs, found to be a pain --- recall
  I'm coming from a settings.json, and the layers seemed complicated
- Experience didn't end up meeting the Hype for me. Massive start up
  time also impeded further experimenting.
- Fell out of use

The good:
- Prompts on install asking how I wanted to have the main aspects set up
- Prompts on opening a new file type for the first time saying "We have
  a layer for this, would you like to install it?"

The bad:
- Felt clunky to use
- Felt quite opaque, like I didn't understand what I was doing and how
  it was working
- Sloooow to start

TLDR; gave Spacemacs a brief go, felt overwhelmed and underwhelmed at
the same time. Didn't end up going beyond a novelty.

* The drive to try Org-mode
- A few months later I started a Stats project using Jupyter Lab
- I missed my proper editor experience
- Version control was a pain
- I didn't like having to choose between opening a local server +
  browser, or trying to parse json >:(
- Did I mention I missed the 'full' editor experience? Just simple stuff
  like select word, replace matches. Trying to make any global (all
  cells) edits was a pain
- State was constantly a pain

* Org-mode, my ramp into Emacs pt.1 - vanilla
- I'd heard about Org-mode as a thing markdown + execution
- Maybe this could be better than Jupyter?
- However... I didn't like Spacemacs
- Removed Spacemacs
- Typed 'emacs' into a terminal
- Oh, this looks old.
- Successfully opened a file
  + Where are the line numbers?
  + Why aren't I given much information on the file
  + Where's the completion, the linting, etc.
  + I thought this was supposed to provide a richer experience than
    colourised nano?
- Tried to execute a command interactively (forget which command)
  + Typed M-x
  + Wait, this is just a text box
  + I don't know commands off by heart!
  + I want to be able to type key terms and see options!
- This isn't going to well
- I'm just slightly dissatisfied with notebooks, I don't want to "build
  my editor from scratch!" *before* I can get going with it!

Conclusion: vanilla emacs is:
 - faster starting
 - uglier, way uglier
 - Not sure how this is much better than Nano TBH (remember: new user, not
   intimately familiar with the benefits)
 - so lean that I don't get "basic" editor functionality (remember:
   coming from VS Code where on install I can open a common file and get
   completion, linting, and more! with common file types suggesting
   extensions which can be installed with a single click).
 - Difficult to use
 - Not something I can try in an afternoon
 - Likely not worth the time

* Org-mode, my ramp into Emacs pt.2 - Doom
- I wonder if there's some other option, closer to Spacemacs where I
  feel it actually helps me get stuff done, but isn't Spacemacs
- [Googles] finds out about Doom, screenshot looks way better
- Skim the readme, looks promising
- I run the one-line install
- Ok, so what do we have hear.
- Oh, look for

Re: Changes for emacs 28

[TEC]

NOTE: I accidentally sent a draft before this. Please disregard it.

Yuan Fu <casouri@gmail.com> writes:

> That’ll be very helpful, since many people on this ML are trying to
> imagine what a new user needs and can’t figure out. Even myself, just
> started using Emacs 3 years ago, can’t remember what problem I faced
> as a beginner anymore.

All right then, I'll try to give a dot point version of my journey into
Emacs, and background/context. I hope this ends up being useful :)

* Prior editor experience (~2y in each) : total ~8 years
- I started off several years ago in IDLE (yes, that Tk python thing)
- I then used Komodo edit for a bit, started doing web stuff
- I shifted to Brackets for web stuff
- I shifted to VS Code, for everything

* VS Code
- VS Code is a great editor
- Everything just worked™, and the experience was generally smooth
- Used VS Code for: Python, Web(HTML,CSS,JS,TS), Rust, LaTeX
- I started writing /lots/ of LaTeX, so much that I became (for a
  period) the #3 contributor to the 'main' LaTeX extension (~500k users)
  and then went off and developed an extension to that extension :P
  (https://marketplace.visualstudio.com/items?itemName=tecosaur.latex-utilities)
- Why does this matter? At this point I'm *heavily* invested into VS
  Code. I'll need to be quite confident of a better experience in order
  to switch.
* VS Code pain points
- I like windows. VS Code's windows are independent electron instances.
  Not good (for UX, or RAM).
- Extension API felt a bit limiting a few times, I'd gaze at open
  issues/PRs in desperation that they'd actually be resolved

* Emacs, the warmup
- I'd heard a few things that sounded interesting about Emacs
  (read: faint inclination to see what the fuss was about)
- I like living in my editor (as long as it's comfortable), I didn't
  like it when I had to type into a barren textbox on the web (e.g.
  writing a GitHub issue).
- I became aware of the client/server archetecture, and EmacsAnywhere
- Installed EmacsAnywhere, and grabbed Spacemacs because it looked
  trendy (I'm serious, I /care/ about visuals, and the Spacemacs web page
  and screenshots were most attractive)
- Used a little bit, on and off, was pretty underwhelmed.
- Tried setting a few things in Spacemacs, found to be a pain --- recall
  I'm coming from a settings.json, and the layers seemed complicated
- Experience didn't end up meeting the Hype for me. Massive start up
  time also impeded further experimenting.
- Fell out of use

The good:
- Prompts on install asking how I wanted to have the main aspects set up
- Prompts on opening a new file type for the first time saying "We have
  a layer for this, would you like to install it?"

The bad:
- Felt clunky to use
- Felt quite opaque, like I didn't understand what I was doing and how
  it was working
- Sloooow to start

TLDR; gave Spacemacs a brief go, felt overwhelmed and underwhelmed at
the same time. Didn't end up going beyond a novelty.

* The drive to try Org-mode
- A few months later I started a Stats project using Jupyter Lab
- I missed my proper editor experience
- Version control was a pain
- I didn't like having to choose between opening a local server +
  browser, or trying to parse json >:(
- Did I mention I missed the 'full' editor experience? Just simple stuff
  like select word, replace matches. Trying to make any global (all
  cells) edits was a pain
- State was constantly a pain

* Org-mode, my ramp into Emacs pt.1 - vanilla
- I'd heard about Org-mode as a thing markdown + execution
- Maybe this could be better than Jupyter?
- However... I didn't like Spacemacs
- Removed Spacemacs
- Typed 'emacs' into a terminal
- Oh, this looks old.
- Successfully opened a file
  + Where are the line numbers?
  + Why aren't I given much information on the file
  + Where's the completion, the linting, etc.
  + I thought this was supposed to provide a richer experience than
    colourised nano?
- Tried to execute a command interactively (forget which command)
  + Typed M-x
  + Wait, this is just a text box
  + I don't know commands off by heart!
  + I want to be able to type key terms and see options!
- This isn't going to well
- I'm just slightly dissatisfied with notebooks, I don't want to "build
  my editor from scratch!" *before* I can get going with it!

Conclusion: vanilla emacs is:
 - faster starting
 - uglier, way uglier
 - Not sure how this is much better than Nano TBH (remember: new user, not
   intimately familiar with the benefits)
 - so lean that I don't get "basic" editor functionality (remember:
   coming from VS Code where on install I can open a common file and get
   completion, linting, and more! with common file types suggesting
   extensions which can be installed with a single click).
 - Difficult to use
 - Not something I can try in an afternoon
 - Likely not worth the time

* Org-mode, my ramp into Emacs pt.2 - Doom
- I wonder if there's some other option, closer to Spacemacs where I
  feel it actually helps me get stuff done, but isn't Spacemacs
- [Googles] finds out about Doom, screenshot looks way better
- Skim the readme, looks promising
- I run the one-line install
- Ok, so what do we have hear.
- Oh, look for the file ~/.doom.d/init.el ? I can do that
- Finds commits describing how the file works
  + Doom has 'modules' - bundles of functionality
  + Uncomment the modules you like the sound of, then run 'doom <something>'
  + I can do that!
- It works, I open up a file and it behaves as expected (and in a
  somewhat snappy manner - compared to Spacemacs)
- I try an Org file, it works!
- I gradually get drawn into Emacs, the rest is history
  (for an idea of how I currently am, see:
   https://tecosaur.github.io/emacs-config/config.html)

Ok, so what are the key aspects that allowed Doom to draw me in where
Spacemacs and Vanilla Emacs failed?
- Having an initialisation† file, well commented such that *without knowing
  anything about Emacs* I could have Emacs be set up such that I could
  actually try it with familiar tasks and not be underwhelmed, or have
  to deal with sudden troubleshooting

  †The important bit about this file is that it let me declare which
  bundles of functionality I want easily, and without having to parse
  much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
  but in different ways).
- Having good 'discoverability enhancements' used by default
  - counsel for M-x
  - which-key
- Looking 'modern' helped me think of Emacs as something which /could/
  be modern, which helped give me confidence in giving Doom a shot (and
  put me off vanilla Emacs)
- Felt a lot smoother/faster than Spacemacs
- Used Discord for it's community, a recent chat-app which I recognised
  (I'm still warming up to mailing lists).
- I don't think I can stress the init.el/module system enough. I wanted
  to use Org-mode with R. I just needed to uncomment ESS, run doom
  refresh and it worked; and *this was all made obvious to me shortly
  after installing*. When I had combinations which used packages which
  interacted and required work-arounds or modifications to integrate
  with other modules - Doom would just take care of this in the
  background. The modules let me 'hit the ground running' in a way I
  didn't in vanilla.


This has been quite a ramble, but should give an idea of how I
approached Emacs, and why the difference in first impressions Doom
provided ended up being so important to me.

All the best,

Timothy.

Re: Changes for emacs 28

[tomas]

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

On Wed, Sep 09, 2020 at 02:15:24AM +0800, TEC wrote:

[...]

> All right then, I'll try to give a dot point version of my journey into
> Emacs, and background/context. I hope this ends up being useful :)

Thanks for this. Very valuable.

Cheers
 - t

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

Re: Changes for emacs 28

[Ergus]

Continuing somehow with the profiles approach. (Which seems to be the
only productive conclusion of the thread that everyone more or less
agree)

As a first step:

May we consider to insert use-package, leaf or something similar in
vanilla?

Either of them are developed by people with copyright and reduces the
configuration complexity while more or less standardizes the packages
configuration; they doesn't affect at all the old user's configs.

Maybe we don't need them fully but at least a part of their
functionalities could be inserted in packages.el?



On Tue, Sep 08, 2020 at 09:28:55PM +0200, tomas@tuxteam.de wrote:
>On Wed, Sep 09, 2020 at 02:15:24AM +0800, TEC wrote:
>
>[...]
>
>> All right then, I'll try to give a dot point version of my journey into
>> Emacs, and background/context. I hope this ends up being useful :)
>
>Thanks for this. Very valuable.
>
>Cheers
> - t

Re: Changes for emacs 28

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> May we consider to insert use-package, leaf or something similar in
> vanilla?

Work on use-package is ongoing, see its GitHub issues page where they
are sorting out the assignment.  I believe I linked the relevant issue
on this list a couple of days ago.

It is my understanding that the idea is to include it in Emacs itself
(rather than only as an ELPA package).

> Maybe we don't need them fully but at least a part of their
> functionalities could be inserted in packages.el?

What do you have in mind?

Re: Changes for emacs 28

[Ergus]

On Tue, Sep 08, 2020 at 09:01:51PM +0000, Stefan Kangas wrote:

>> Maybe we don't need them fully but at least a part of their
>> functionalities could be inserted in packages.el?
>
>What do you have in mind?
>
Actually nothing specific. I just prevented in case it was not ongoing.

OTOH: While I use use-packages I have seen leaf and it seems to have
some interesting things and it is "syntax coherent" in some aspects
while developed by a single user with all the paperwork done.

We must take the best of both. Could we request Naoya Yamashita and John
Wiegley to create together a sort of super use-package-leaf for vanilla?

Re: Changes for emacs 28

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> OTOH: While I use use-packages I have seen leaf and it seems to have
> some interesting things and it is "syntax coherent" in some aspects
> while developed by a single user with all the paperwork done.

Which useful features does leaf provide over use-package?

Re: Changes for emacs 28

[Ergus]

On September 9, 2020 12:14:15 AM GMT+02:00, Stefan Kangas <stefankangas@gmail.com> wrote:
>Ergus <spacibba@aol.com> writes:
>
>> OTOH: While I use use-packages I have seen leaf and it seems to have
>> some interesting things and it is "syntax coherent" in some aspects
>> while developed by a single user with all the paperwork done.
>
>Which useful features does leaf provide over use-package?

Just some details. Some coherent syntax, easier extensibility and extra keywords.

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

Re: Changes for emacs 28

[Daniel Martín]

Ergus <spacibba@aol.com> writes:

>
> Maybe we don't need them fully but at least a part of their
> functionalities could be inserted in packages.el?

Despite the name, use-package is not very related to what package.el
does, so it may be accepted into Emacs, but as its own package.

As a first step, someone should write a proposal that describes in
detail the concept of "profile", what it'll entail, and how it'll help
existing Emacs users and developers. With the help of the experienced
Emacs developers in this ML, I'm sure we could come up with a technical
design for the feature, that works on top of the existing Emacs
architecture.

--
Daniel Martín

Re: Changes for emacs 28

[Stefan Monnier]

Thanks, TEC, I found it quite useful.  Further comments and questions below.

> * Org-mode, my ramp into Emacs pt.1 - vanilla
> - I'd heard about Org-mode as a thing markdown + execution
> - Maybe this could be better than Jupyter?
> - However... I didn't like Spacemacs
> - Removed Spacemacs
> - Typed 'emacs' into a terminal

So far so good.

> - Oh, this looks old.

Fair enough.  I don't think we (Emacs community) are in a position to
make it look "modern" and sexy.  I know I'm not because my notion of
"modern and sexy" is quite outmoded ;-)

But "looks old" is usually not a deal breaker, just a negative
first impression.

> - Successfully opened a file
>   + Where are the line numbers?

Interesting.  It would never occur to me to expect line numbers in
a text editor.  When and why did line numbers become fashionable?
[ My guess is something like "ever since shortscreens became the only
  option, creating a void in the horizontal space that needed
  filling" ;-) ]

I don't oppose enabling line numbers by default, but I do find line
numbers to be an awful waste of valuable screen real estate.

>   + Why aren't I given much information on the file

Could you be more specific in terms of the particular information that
you felt Emacs failed to give (and maybe how you expected it to be given)?

>   + Where's the completion, the linting, etc.

Do I understand you right that you expected company+eglot+flymake to be
enabled (and configured) by default?

I personally find this to be the most glaring concrete problem in
Emacs nowadays.

> - Tried to execute a command interactively (forget which command)
>   + Typed M-x
>   + Wait, this is just a text box
>   + I don't know commands off by heart!
>   + I want to be able to type key terms and see options!

How much of this would be satisfied by icomplete-mode together with the
`substring` completion-style (which would be a smaller change to
the UI than something like helm-M-x or counsel-M-x).

> - Having an initialisation† file, well commented such that *without knowing
>   anything about Emacs* I could have Emacs be set up such that I could
>   actually try it with familiar tasks and not be underwhelmed, or have
>   to deal with sudden troubleshooting

Maybe we could have a "default init file" (consisting of nothing but
commented out code snippets, accompanied by actual comments explaining
them)?

>   †The important bit about this file is that it let me declare which
>   bundles of functionality I want easily, and without having to parse
>   much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
>   but in different ways).

Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afraid.

> - Having good 'discoverability enhancements' used by default
>   - counsel for M-x

IIUC this is similar to enabling icomplete-vertical and
icomplete-show-matches-on-no-input, and maybe using a regexp
completion style?

> - Used Discord for it's community, a recent chat-app which I recognised
>   (I'm still warming up to mailing lists).

Definitely a non-starter since it's proprietary.
There are obviously acceptable alternatives.

I think an important aspect is to find a communication medium that can
be used from Emacs.  IRC and Email do satisfy this criteria.
Whenever I have to write text outside Emacs I feel hampered.


        Stefan

Re: Changes for emacs 28

[T.V Raman]

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

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


and with taller screens, may be old typewriter  motivated displays with
column numbers running along the top:-)> Thanks, TEC, I found it quite useful.  Further comments and questions below.
>
>> * Org-mode, my ramp into Emacs pt.1 - vanilla
>> - I'd heard about Org-mode as a thing markdown + execution
>> - Maybe this could be better than Jupyter?
>> - However... I didn't like Spacemacs
>> - Removed Spacemacs
>> - Typed 'emacs' into a terminal
>
> So far so good.
>
>> - Oh, this looks old.
>
> Fair enough.  I don't think we (Emacs community) are in a position to
> make it look "modern" and sexy.  I know I'm not because my notion of
> "modern and sexy" is quite outmoded ;-)
>
> But "looks old" is usually not a deal breaker, just a negative
> first impression.
>
>> - Successfully opened a file
>>   + Where are the line numbers?
>
> Interesting.  It would never occur to me to expect line numbers in
> a text editor.  When and why did line numbers become fashionable?
> [ My guess is something like "ever since shortscreens became the only
>   option, creating a void in the horizontal space that needed
>   filling" ;-) ]
>
> I don't oppose enabling line numbers by default, but I do find line
> numbers to be an awful waste of valuable screen real estate.
>
>>   + Why aren't I given much information on the file
>
> Could you be more specific in terms of the particular information that
> you felt Emacs failed to give (and maybe how you expected it to be given)?
>
>>   + Where's the completion, the linting, etc.
>
> Do I understand you right that you expected company+eglot+flymake to be
> enabled (and configured) by default?
>
> I personally find this to be the most glaring concrete problem in
> Emacs nowadays.
>
>> - Tried to execute a command interactively (forget which command)
>>   + Typed M-x
>>   + Wait, this is just a text box
>>   + I don't know commands off by heart!
>>   + I want to be able to type key terms and see options!
>
> How much of this would be satisfied by icomplete-mode together with the
> `substring` completion-style (which would be a smaller change to
> the UI than something like helm-M-x or counsel-M-x).
>
>> - Having an initialisation6¥8 file, well commented such that *without knowing
>>   anything about Emacs* I could have Emacs be set up such that I could
>>   actually try it with familiar tasks and not be underwhelmed, or have
>>   to deal with sudden troubleshooting
>
> Maybe we could have a "default init file" (consisting of nothing but
> commented out code snippets, accompanied by actual comments explaining
> them)?
>
>>   6¥8The important bit about this file is that it let me declare which
>>   bundles of functionality I want easily, and without having to parse
>>   much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
>>   but in different ways).
>
> Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afraid.
>
>> - Having good 'discoverability enhancements' used by default
>>   - counsel for M-x
>
> IIUC this is similar to enabling icomplete-vertical and
> icomplete-show-matches-on-no-input, and maybe using a regexp
> completion style?
>
>> - Used Discord for it's community, a recent chat-app which I recognised
>>   (I'm still warming up to mailing lists).
>
> Definitely a non-starter since it's proprietary.
> There are obviously acceptable alternatives.
>
> I think an important aspect is to find a communication medium that can
> be used from Emacs.  IRC and Email do satisfy this criteria.
> Whenever I have to write text outside Emacs I feel hampered.
>
>
>         Stefan
>
>

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

Re: Changes for emacs 28

[TEC]

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

> Thanks, TEC, I found it quite useful.  Further comments and questions below.

Happy to (try) to help. I'll see if I can elaborate on your
points/queries :)

>> - Oh, this looks old.
>
> Fair enough.  I don't think we (Emacs community) are in a position to
> make it look "modern" and sexy.  I know I'm not because my notion of
> "modern and sexy" is quite outmoded ;-)
>
> But "looks old" is usually not a deal breaker, just a negative
> first impression.

This is a tricky thing. You see, I don't think it's inherently bad.
However, for me at least, most of the editors I've used have had a good
degree of 'visual polish' and 'modern snazziness' that Vanilla Emacs
currently lacks. The editors I've used which haven't are
 - IDLE
 - Nano
 - BlueJ (for all of 30 seconts)
All of which I ended up finding quite lacking.

So the 'issue' here isn't a direct "this doesn't look good so I won't
use this" but a case of association. When I see the vanilla Emacs splash
screen I'm reminded of the *worst* editors I have experienced, which is
(as we both know) completely inaccurate, but first impressions are
coloured by a myriad of factors.

Vim of course also lacks a splash screen, but it's also known as a
terminal-exclusive editor. I know I tend to set different expectations
TUIs and GUIs, so I'd imagine I'd find this less of a subconscious
red-flag.

>> - Successfully opened a file
>>   + Where are the line numbers?
>
> Interesting.  It would never occur to me to expect line numbers in
> a text editor.  When and why did line numbers become fashionable?
> [ My guess is something like "ever since shortscreens became the only
>   option, creating a void in the horizontal space that needed
>   filling" ;-) ]
>
> I don't oppose enabling line numbers by default, but I do find line
> numbers to be an awful waste of valuable screen real estate.

This really is quite minor, and not something to get hung up about in my
opinion. This was more a surprise than anything else, having just been
made used to line numbers by my previous editors.

>>   + Why aren't I given much information on the file
>
> Could you be more specific in terms of the particular information that
> you felt Emacs failed to give (and maybe how you expected it to be given)?

It's almost got all the main attributes, just an issue of clarity and
expected functionality not coming with vanilla Emacs.

- Unsaved changes, I see this is now present but the you have to know
  what you're looking for somewhat
- linter checks/status (of course, I now know this is because there is
  no linter by default)

>>   + Where's the completion, the linting, etc.
>
> Do I understand you right that you expected company+eglot+flymake to be
> enabled (and configured) by default?
>
> I personally find this to be the most glaring concrete problem in
> Emacs nowadays.

Yep. This is the main item, no doubt in my mind. Not having /any/
completion or linting was a bit of a shock.

>> - Tried to execute a command interactively (forget which command)
>>   + Typed M-x
>>   + Wait, this is just a text box
>>   + I don't know commands off by heart!
>>   + I want to be able to type key terms and see options!
>
> How much of this would be satisfied by icomplete-mode together with the
> `substring` completion-style (which would be a smaller change to
> the UI than something like helm-M-x or counsel-M-x).

I'm frankly not sure. Just trying icomplete now for the first time the
horizontal display of options seems a bit odd to my sensibilities.

>> - Having an initialisation† file, well commented such that *without knowing
>>   anything about Emacs* I could have Emacs be set up such that I could
>>   actually try it with familiar tasks and not be underwhelmed, or have
>>   to deal with sudden troubleshooting
>
> Maybe we could have a "default init file" (consisting of nothing but
> commented out code snippets, accompanied by actual comments explaining
> them)?

I feel like this could be a good thing, with the most common/immediate
settings described and commented out. For example, doom has this:

-----

;; Some functionality uses this to identify you, e.g. GPG configuration, email
;; clients, file templates and snippets.
(setq user-full-name "John Doe"
      user-mail-address "john@doe.com")

...

;; This determines the style of line numbers in effect. If set to `nil', line
;; numbers are disabled. For relative line numbers, set this to `relative'.
(setq display-line-numbers-type t)

-----

>>   †The important bit about this file is that it let me declare which
>>   bundles of functionality I want easily, and without having to parse
>>   much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
>>   but in different ways).
>
> Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afraid.

This was mostly a comparison to spacemacs. Doom's init.el is mostly
lines like this:

-----
       :lang
       ;;agda              ; types of types of types of types...
       ;;cc                ; C/C++/Obj-C madness
       ;;clojure           ; java with a lisp
       ;;common-lisp       ; if you've seen one lisp, you've seen them all
-----

Which as a lisp-noob I didn't find intimidating.

>> - Having good 'discoverability enhancements' used by default
>>   - counsel for M-x
>
> IIUC this is similar to enabling icomplete-vertical and
> icomplete-show-matches-on-no-input, and maybe using a regexp
> completion style?

This sounds like a change I would have appreciated.

>> - Used Discord for it's community, a recent chat-app which I recognised
>>   (I'm still warming up to mailing lists).
>
> Definitely a non-starter since it's proprietary.
> There are obviously acceptable alternatives.

Oh, I don't expect Emacs' community at large (particularly individuals
like the cheif GNUsance) to switch to discord or anything like that, but
a non-IRC IM platform could make asking quick newbie questions seem more
appreciable.

Unfortunately, I feel that a lot of youngsters (myself included) tend to
/expect/ projects to:
 - be on github
 - have public forums
 - use popluar IM services

I'm not saying Email+IRC isn't fit for purpose, it's simply not
something I was used to using like this (until months after I got into
Emacs).

I think we can somewhat see this effect in the benefits that being on
GitHub seems to have had for NeoVim, in terms of visibility and
engagement.

I'm not saying that Emacs should follow suit, simply that IMO this seems
like a matter worthy of some consideration.

> I think an important aspect is to find a communication medium that can
> be used from Emacs.  IRC and Email do satisfy this criteria.

Indeed. Though I think that when trying to make Emacs inviting, having
services that a curious user feels comfortable just jumping onto
(Discord, Gitter, Slack, Discorse,...) may also have value.

Feel free to follow up with more questions, I'll do my best to answer
them :)

Timothy.

Re: Changes for emacs 28

[Stefan Monnier]

>> But "looks old" is usually not a deal breaker, just a negative
>> first impression.
> This is a tricky thing.

I fully agree with you that it can be important.
All I meant is that I'll let others figure out what to do with this part
of the problem.

>>> - Successfully opened a file
>>>   + Where are the line numbers?
>>
>> Interesting.  It would never occur to me to expect line numbers in
>> a text editor.  When and why did line numbers become fashionable?
>> [ My guess is something like "ever since shortscreens became the only
>>   option, creating a void in the horizontal space that needed
>>   filling" ;-) ]
>>
>> I don't oppose enabling line numbers by default, but I do find line
>> numbers to be an awful waste of valuable screen real estate.
>
> This really is quite minor, and not something to get hung up about in my
> opinion.

I'm not getting "hung up on" but I'm curious to know if it's really
something that's expected nowadays (just like a tool-bar was expected
at some point and maybe a tab-bar is expected nowadays, tho I find
both of them completely useless in Emacs for my usage pattern).

And it does make it clear that regardless if we change the default, it
should be very easy and obvious how to enable (or disable) it.

>> Could you be more specific in terms of the particular information that
>> you felt Emacs failed to give (and maybe how you expected it to be given)?
> It's almost got all the main attributes, just an issue of clarity and
> expected functionality not coming with vanilla Emacs.
> - Unsaved changes, I see this is now present but the you have to know
>   what you're looking for somewhat

Any hint how (else) you expected it to be shown at that point?

> - linter checks/status (of course, I now know this is because there is
>   no linter by default)

Ah, yes, that ;-)

>>>   + Where's the completion, the linting, etc.
>> Do I understand you right that you expected company+eglot+flymake to be
>> enabled (and configured) by default?
>> I personally find this to be the most glaring concrete problem in
>> Emacs nowadays.
> Yep. This is the main item, no doubt in my mind. Not having /any/
> completion or linting was a bit of a shock.

I'm glad we agree.

>> Maybe we could have a "default init file" (consisting of nothing but
>> commented out code snippets, accompanied by actual comments explaining
>> them)?
> I feel like this could be a good thing, with the most common/immediate
> settings described and commented out. For example, doom has this:

Right, that was the idea.  Of course, in my world, Emacs is installed by
the admin so the init file of the users initially just doesn't exist at all.
So we'd need some magic to fill it with this initial template upon first visit.

> -----
>        :lang
>        ;;agda              ; types of types of types of types...
>        ;;cc                ; C/C++/Obj-C madness
>        ;;clojure           ; java with a lisp
>        ;;common-lisp       ; if you've seen one lisp, you've seen them all
> -----

Oh, cool, I didn't expect "agda" to be there!

> Which as a lisp-noob I didn't find intimidating.

I see.  Not sure if I'd want to go in this direction for configuration.
But for selection of packages to install, it looks fine, indeed.

> Unfortunately, I feel that a lot of youngsters (myself included) tend to
> /expect/ projects to:
>  - be on github

This is one we won't satisfy because it doesn't just mean "a github-like
model" but "on github itself", so it's incompatible with our philosophy.

But we hopefully will (sooner rather than later) move our development to
something that offers a nicer web UI for merge requests and bug reports.
This is not going very fast, tho.
[ Currently I'm personally hoping we'll move to SourceHut.  ]

>  - have public forums

Hmm... emacs-devel is definitely public.  Do you not consider it a forum?
Do you mean "web forum"?

>  - use popluar IM services

I oppose all the most popular IM services because they make money using
(y)our data, so using them would be unethical (even if we decided we were
OK with implicitly selling our data, by using such forums we'd be
forcing other people to make this choice as well).

> I'm not saying Email+IRC isn't fit for purpose, it's simply not
> something I was used to using like this (until months after I got into
> Emacs).

Yup.  So the only possible meeting point is one that is ethically
acceptable (Free Software, open protocol, non-centralized control), and
can be accessed from within Emacs as well as via more popular UIs.

Any suggestion what this could be?

> I'm not saying that Emacs should follow suit, simply that IMO this seems
> like a matter worthy of some consideration.

Indeed, but there are strong commercial forces that strive to keep the
acceptable solutions unpopular ;-(

>> I think an important aspect is to find a communication medium that can
>> be used from Emacs.  IRC and Email do satisfy this criteria.
> Indeed. Though I think that when trying to make Emacs inviting, having
> services that a curious user feels comfortable just jumping onto
> (Discord, Gitter, Slack, Discorse,...) may also have value.

Value or not, Discord and Slack are not part of the Free Software world,
so they're definitely not an option.  Gitter and Discourse are
possible, OTOH.  I haven't had an opportunity to use them from with
Emacs yet, so I don't know if the regulars of emacs-devel would find it
sufficiently palatable, but I'd be happy to try it out if someone sets
up such a service for us.


        Stefan

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-09 21:35 +03, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> I'm not getting "hung up on" but I'm curious to know if it's really
> something that's expected nowadays (just like a tool-bar was expected
> at some point and maybe a tab-bar is expected nowadays, tho I find
> both of them completely useless in Emacs for my usage pattern).

Most of the popular graphical text editor applications have it on by
default.  I’ve observed Sublime Text, VS Code, Notepad++ (not sure tho),
and a few others in distant past whose names escape me now.

Notably, tho, IDEs in general don’t seem to have line numbers on by
default.

Enabling line numbers by default is, IDK.  In most special-mode type of
buffers they don’t make any sense.  In text-mode, not really needed
either.  Maybe in prog-mode, but then usually you have flymake,
flycheck, lsp or similar and they just highlight the relevant line, and
compilation errors are usually clickable (tho possibly not everybody are
using M-x compile).  Maybe when navigating via prefix args (e.g. C-5
C-n)?

Maybe, if we ever have something like a initial config wizard, we could:

  Do you want to enable line number display on the left side of the
  window in any of the following contexts?

      ( ) Programming modes only
      ( ) Text editing modes only
      ( ) Both programming and text editing modes
      ( ) Everywhere

> And it does make it clear that regardless if we change the default, it
> should be very easy and obvious how to enable (or disable) it.

Maybe a toggle inserted into the very left hand side of the mode line?
E.g., try:

(setq
 mode-line-format
 (cons
  '(:eval
    (propertize
     "# "
     'help-echo  "mouse-1: Toggle line number display"
     'mouse-face 'mode-line-highlight

     'local-map
     (make-mode-line-mouse-map
      'mouse-1 #'display-line-numbers-mode)))
  mode-line-format))

>> I'm not saying Email+IRC isn't fit for purpose, it's simply not
>> something I was used to using like this (until months after I got into
>> Emacs).
> Yup.  So the only possible meeting point is one that is ethically
> acceptable (Free Software, open protocol, non-centralized control), and
> can be accessed from within Emacs as well as via more popular UIs.
>
> Any suggestion what this could be?

A Mastodon (or equivalent) instance for Emacs?  A lot of Emacs users
there already.

There’s an Emacs client, mastodon.el, which is nice but has some
polishing to be done.  Haven’t used it much tho.


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

RE: Changes for emacs 28

[Drew Adams]

> Enabling line numbers by default ...
> Maybe a toggle inserted into the very left hand side of the mode line?

Isn't what we have now sufficient for discovery
and setting line-number display on, if that's
what someone wants?  (Not a snarky or rhetorical
question - I'm curious.)

How hard is it to find this submenu?

`Options' >
    `Show/Hide' >
      `Line Numbers for All Lines'

Perhaps that submenu should be moved up, before
submenu `Scroll Bars', i.e., as the first submenu
of `Show/Hide'.  And perhaps submenu `Show/Hide'
should be moved higher in the `Options' menu.

(I've also argued in the past to rename `Options'
to `Preferences', as that's more common, and
as it covers faces also.  That wasn't done.)

Re: Changes for emacs 28

[Yuri Khan]

On Fri, 11 Sep 2020 at 00:43, Drew Adams <drew.adams@oracle.com> wrote:

> How hard is it to find this submenu?
>
> `Options' >
>     `Show/Hide' >
>       `Line Numbers for All Lines'

By CUA, Show/Hide should be a top-level menu named View. Someone who
is (subconsciously) familiar with that convention will not think to
look in Options.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 11 Sep 2020 00:56:41 +0700
> Cc: Göktuğ Kayaalp <self@gkayaalp.com>,
>  Gregory Heytings <ghe@sdf.org>, Yuan Fu <casouri@gmail.com>,
>  TEC <tecosaur@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> > `Options' >
> >     `Show/Hide' >
> >       `Line Numbers for All Lines'
> 
> By CUA, Show/Hide should be a top-level menu named View.

Emacs doesn't have a View menu.  And frankly, in an editor, too many
things are about "viewing" for View to be of any use.

Also, Options in many apps is not easily discovered, its place is not
fixed: sometimes in Tools, sometimes somewhere else.  Emacs, being a
highly-customizable application, cannot avoid having Options at top
level.

Re: Changes for emacs 28

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Date: Fri, 11 Sep 2020 00:56:41 +0700
>> Cc: Göktuğ Kayaalp <self@gkayaalp.com>,
>>  Gregory Heytings <ghe@sdf.org>, Yuan Fu <casouri@gmail.com>,
>>  TEC <tecosaur@gmail.com>, Emacs developers <emacs-devel@gnu.org>
>> 
>> > `Options' >
>> >     `Show/Hide' >
>> >       `Line Numbers for All Lines'
>> 
>> By CUA, Show/Hide should be a top-level menu named View.
>
> Emacs doesn't have a View menu.  And frankly, in an editor, too many
> things are about "viewing" for View to be of any use.
>
> Also, Options in many apps is not easily discovered, its place is not
> fixed: sometimes in Tools, sometimes somewhere else.  Emacs, being a
> highly-customizable application, cannot avoid having Options at top
> level.

I wonder if it makes sense to link directly to the customize “feature”
(for the lack of a better word), i.e. to remove options from the menu
and replace them with an item that essentially does “M-x customize”.
Customize provides an intuitive interface for many options and is not
constrained by the limitations of a single menu.

As a bonus it would lead users to learn more about Emacs and how to
customize it.

If the customize buffers are too intimidating or too “full”, perhaps
this means that we should find more groups and better organize them.

-- 
Ricardo

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> Cc: Yuri Khan <yuri.v.khan@gmail.com>, casouri@gmail.com, ghe@sdf.org,
>  self@gkayaalp.com, drew.adams@oracle.com, tecosaur@gmail.com,
>  emacs-devel@gnu.org
> Date: Thu, 10 Sep 2020 21:48:01 +0200
> 
> I wonder if it makes sense to link directly to the customize “feature”
> (for the lack of a better word), i.e. to remove options from the menu
> and replace them with an item that essentially does “M-x customize”.
> Customize provides an intuitive interface for many options and is not
> constrained by the limitations of a single menu.

Customize is in the Options menu.

For simple on/off options, especially the popular ones, it makes sense
to offer them as simple menu toggles, so that we don't force the user
to use the more complex UI of Customize for such simple tasks.

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-10 21:21 +03, Eli Zaretskii <eliz@gnu.org> wrote:
> Emacs doesn't have a View menu.  And frankly, in an editor, too many
> things are about "viewing" for View to be of any use.
>
> Also, Options in many apps is not easily discovered, its place is not
> fixed: sometimes in Tools, sometimes somewhere else.  Emacs, being a
> highly-customizable application, cannot avoid having Options at top
> level.

It appears that in Emacs we have the extra trouble of menu-bar-mode
being one of the first things people disable, and some major ‘distros’
like Spacemacs seem to disable them by default, so many people never
even see it.  Also, FWIW, I just noticed the Options menu for the first
time in my life, after reading Drew’s message, even though the menu bar
has been sitting there before my eyes for years...

There was an idea in another thread that we could ask major distros to
not disable menu bar, and I said I could create the issues, but I though
I’d wait for some of the maintainers (dis)agree first. What do you
think, would such a thing be useful?

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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


Göktuğ Kayaalp:
>
> There was an idea in another thread that we could ask major distros to 
> not disable menu bar, and I said I could create the issues, but I though 
> I’d wait for some of the maintainers (dis)agree first. What do you 
> think, would such a thing be useful?
>

I'm not a maintainer, but FWIW my opinion is that what will most likely 
happen is that they will never agree to do this.  Menus are not "modern".

Re: Changes for emacs 28

[Ricardo Wurmus]

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

> Göktuğ Kayaalp:
>>
>> There was an idea in another thread that we could ask major distros
>> to not disable menu bar, and I said I could create the issues, but I
>> though I’d wait for some of the maintainers (dis)agree first. What
>> do you think, would such a thing be useful?
>>
>
> I'm not a maintainer, but FWIW my opinion is that what will most
> likely happen is that they will never agree to do this.  Menus are not
> "modern".

FWIW, we don’t disable the menu bar in Guix.

It seems super weird to me to disable a feature like that for all users
of the package.  We disable anti-features (like an application phoning
home), but why would any distribution maintainer decide for the users on
something like that?

I personally don’t use the menus, but it would never occur to me to
disable them for new users or to suggest they disable them.

If you use a distribution that disables the menu bar, I would suggest
talking to them.  Perhaps this was done by an over-zealous person and
has long been forgotten by whoever maintains the package today.

-- 
Ricardo

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>> There was an idea in another thread that we could ask major distros to 
>> not disable menu bar, and I said I could create the issues, but I 
>> though I’d wait for some of the maintainers (dis)agree first. What do 
>> you think, would such a thing be useful?
>
> FWIW, we don’t disable the menu bar in Guix.
>

The words "major distros" here are not clear without the context.  They 
mean "Spacemacs", "Doom Emacs" and the like.  Not Guix, Debian and the 
like.

RE: Changes for emacs 28

[Drew Adams]

> It seems super weird to me to disable a feature like that for all users
> of the package.  We disable anti-features (like an application phoning
> home), but why would any distribution maintainer decide for the users on
> something like that?

<scratchy-voice>E.T. menu-phone HOME!</ scratchy -voice>

Re: Changes for emacs 28

[Stefan Kangas]

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

> I'm not a maintainer, but FWIW my opinion is that what will most likely
> happen is that they will never agree to do this.  Menus are not "modern".

Maybe not.  But we don't know until we have given them the opportunity
to think about this problem.  Even if just a small number of popular
distributions choose to listen it would be an improvement.

The same explanatory text could be used to file several bug reports.
That makes it worth spending the extra couple of minutes to make sure
that it's a convincing text.

Re: Changes for emacs 28

[Richard Stallman]

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

  > I'm not a maintainer, but FWIW my opinion is that what will most likely 
  > happen is that they will never agree to do this.  Menus are not "modern".

What in the world?  This strikes me as incomprehensible.

Who thinks "Menus are not modern"?  Why?
What do they use instead of menus?

(Perhaps they use a different kind of menu
but do not think of it as a manu.)

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

Re: Changes for emacs 28

[Philip K.]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I'm not a maintainer, but FWIW my opinion is that what will most likely 
>   > happen is that they will never agree to do this.  Menus are not "modern".
>
> What in the world?  This strikes me as incomprehensible.
>
> Who thinks "Menus are not modern"?  Why?
> What do they use instead of menus?
>
> (Perhaps they use a different kind of menu
> but do not think of it as a manu.)

I think that this is the case, most programmes seem to use the
"Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
what the reason for this change was, but I have a hunch one of the
motivating reasons was the attempt to merge applications and the window
frames (as GNOME does in the free software world, but Chrome, MS Office,
etc. do in the non-free world). When no space is left between the
application and it's frame, the menu must be moved somewhere
else. Another reason is probably the influence of mobile applications,
that use these kinds of menus due to lack of space.

[0] https://en.wikipedia.org/wiki/Hamburger_button

-- 
	Philip K.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Date: Fri, 11 Sep 2020 09:04:59 +0200
> Cc: Gregory Heytings <ghe@sdf.org>, emacs-devel@gnu.org
> 
> I think that this is the case, most programmes seem to use the
> "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
> what the reason for this change was, but I have a hunch one of the
> motivating reasons was the attempt to merge applications and the window
> frames

I think the reason is likely to be compatibility with mobile platforms,
where screen space is at premium.

Re: Changes for emacs 28

[tomas]

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

On Fri, Sep 11, 2020 at 10:12:01AM +0300, Eli Zaretskii wrote:
> > From: "Philip K." <philipk@posteo.net>
> > Date: Fri, 11 Sep 2020 09:04:59 +0200
> > Cc: Gregory Heytings <ghe@sdf.org>, emacs-devel@gnu.org
> > 
> > I think that this is the case, most programmes seem to use the
> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
> > what the reason for this change was, but I have a hunch one of the
> > motivating reasons was the attempt to merge applications and the window
> > frames
> 
> I think the reason is likely to be compatibility with mobile platforms,
> where screen space is at premium.

This is a friendly interpretation. You're such a friendly person [1].

Me? I'd say the Hamburger menu is the latest fad, to be taken over
next year by the Sushi menu, or the Falafel-Halloumi-Magali menu,
depending on the alignment of the stars.

Never forget that the current trendsetters care for user's well-being
as much as the cattle-herders care for their cattle's well-being.

They are the wares. Their customers are elsewhere.

Cheers

[1] Someone might be tempted to read irony in this. That'd be wrong.

 - t

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

Re: Changes for emacs 28

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Fri, Sep 11, 2020 at 10:12:01AM +0300, Eli Zaretskii wrote:
>> > From: "Philip K." <philipk@posteo.net>
>> > Date: Fri, 11 Sep 2020 09:04:59 +0200
>> > Cc: Gregory Heytings <ghe@sdf.org>, emacs-devel@gnu.org
>> > 
>> > I think that this is the case, most programmes seem to use the
>> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
>> > what the reason for this change was, but I have a hunch one of the
>> > motivating reasons was the attempt to merge applications and the window
>> > frames
>> 
>> I think the reason is likely to be compatibility with mobile platforms,
>> where screen space is at premium.
>
> This is a friendly interpretation. You're such a friendly person [1].
>
> Me? I'd say the Hamburger menu is the latest fad, to be taken over
> next year by the Sushi menu, or the Falafel-Halloumi-Magali menu,
> depending on the alignment of the stars.
:-) Haha, what is Magali? Never tried that. Wikipedia says it is a river
in Guinea and Google shows me pictures of different dishes.

"Hamburger icon" has become a standard icon for a menu; I don't think
there was an established "menu icon" before the "responsive design"
kicked in. People used '+' sign och '...' or something else. Responsive
design is all the rage nowadays; I think it started already with Java
introducing layout managers, but it didn't become a thing until mobile
platforms made it popular due to necessity.

Re: Changes for emacs 28

[tomas]

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

On Fri, Sep 11, 2020 at 12:27:13PM +0200, Arthur Miller wrote:

[...]

> :-) Haha, what is Magali? Never tried that. Wikipedia says it is a river
> in Guinea and Google shows me pictures of different dishes.

In the Sudanese take-outs around here, they serve you diced, fried 
vegetables [1]. Yummy.

Cheers
[1] https://saharaimbiss.de/en/
 - t

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

Re: Changes for emacs 28

[Arthur Miller]

tomas@tuxteam.de writes:

> On Fri, Sep 11, 2020 at 12:27:13PM +0200, Arthur Miller wrote:
>
> [...]
>
>> :-) Haha, what is Magali? Never tried that. Wikipedia says it is a river
>> in Guinea and Google shows me pictures of different dishes.
>
> In the Sudanese take-outs around here, they serve you diced, fried 
> vegetables [1]. Yummy.
No, we don't have those, but I believe you that fried veggies are
delicious. Anything fried ususally is :).

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-11 10:44 +03, tomas@tuxteam.de wrote:
>> I think the reason is likely to be compatibility with mobile platforms,
>> where screen space is at premium.
>
> This is a friendly interpretation. You're such a friendly person [1].
>
> Me? I'd say the Hamburger menu is the latest fad, to be taken over
> next year by the Sushi menu, or the Falafel-Halloumi-Magali menu,
> depending on the alignment of the stars.

This is so true...

Tho it’s a fact that there are two main sources of UI ‘innovation’ in
desktop these days: copy web and copy mobile.

Another fact is we already have hamburger menus in Emacs: the onese
bound to C-mouse.

> Never forget that the current trendsetters care for user's well-being
> as much as the cattle-herders care for their cattle's well-being.
>
> They are the wares. Their customers are elsewhere.
>
> Cheers
>
> [1] Someone might be tempted to read irony in this. That'd be wrong.
>
>  - t


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

Re: Changes for emacs 28

[Juri Linkov]

>> > I think that this is the case, most programmes seem to use the
>> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
>> > what the reason for this change was, but I have a hunch one of the
>> > motivating reasons was the attempt to merge applications and the window
>> > frames

If the menu-bar isn't displayed then we could display the Hamburger icon
in the tool-bar, and clicking on it will pop-up the menu with items from
the menu-bar, so users won't need to display both menu-bar and tool-bar.

> Me? I'd say the Hamburger menu is the latest fad, to be taken over
> next year by the Sushi menu

Unlike the Hamburger menu that has three sticks,
the Sushi menu icon should have two chopsticks.

Re: Changes for emacs 28

[tomas]

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

On Sun, Sep 13, 2020 at 11:41:45AM +0300, Juri Linkov wrote:
> >> > I think that this is the case, most programmes seem to use the
> >> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
> >> > what the reason for this change was, but I have a hunch one of the
> >> > motivating reasons was the attempt to merge applications and the window
> >> > frames
> 
> If the menu-bar isn't displayed then we could display the Hamburger icon
> in the tool-bar, and clicking on it will pop-up the menu with items from
> the menu-bar, so users won't need to display both menu-bar and tool-bar.
> 
> > Me? I'd say the Hamburger menu is the latest fad, to be taken over
> > next year by the Sushi menu
> 
> Unlike the Hamburger menu that has three sticks,
> the Sushi menu icon should have two chopsticks.

Perhaps with something mushy and fishy in-between, to differentiate
it from the spring-roll menu.

On a more serious note, what I wanted to point out is that there
are many forces shaping what is currently perceived as "usage
friendly". Some of them stem from ergonomy research (which, of
course, focuses on some population already exposed to software
"out there", so it's part of a feedback loop), some of it stems
from some manufacturer's attempt to differentiate itself, to
grow sales, some of it, even, from a strategy of appealing to
potential decision takers (who are /not/ those who have to use
the sofware later).

As we focus on user freedom here, not all those forces are our
friends. Some are, some are not.

The table TEC posted (Message-ID: <87o8maj1kh.fsf@gmail.com>)
is very interesting. Do you think the popularity of vscode
and vs (both at the  list's top) stems from the colours? Or
rather from the fact that there is an incredibly rich behemoth
behind both of them and that many developers are working,
directly or indirectly for it? Or from some mixture of both?

Microsoft has a long record of trying to suck in users into
their dependency from them. It's their business model.

The fact that Microsoft put 7 billions on the table to
acquire Github should be telling, in itself. A platform
which transforms Git's inherently decentralised model into
a centralised service (when I worked for some big company,
developers there saw Github as a synonym for git, and that
was before the acquisition).

Exchange Microsoft for any other company whose revenue comes
from dependent users, there are many.

The latter runs counter our core principles, I think.

I'm not arguing that Emacs shoud make it hard for people coming
from vscode, on the contrary. But the argument "it's more popular,
so it must be better" is too naive, I think.

Cheers
 - t

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

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-13 13:30 +03, tomas@tuxteam.de wrote:
> On a more serious note, what I wanted to point out is that there
> are many forces shaping what is currently perceived as "usage
> friendly". Some of them stem from ergonomy research (which, of
> course, focuses on some population already exposed to software
> "out there", so it's part of a feedback loop), some of it stems
> from some manufacturer's attempt to differentiate itself, to
> grow sales, some of it, even, from a strategy of appealing to
> potential decision takers (who are /not/ those who have to use
> the sofware later).

A lot of that research is pseudo scientific.  E.g. some famous
‘principles’ of UX design are based on academesified opition or
misappropriation of unrelated research.  E.g. see this one [1].  If you
read the ‘scientific’ background to the ‘laws’, what you’ll see is that
some of those are shaky, and some of those are lesser than that.

We should focus on what makes users *stay* with Emacs, and what makes
such a stay comfortable.  While I see no harm in making the first steps
easier---so long as it’s reasonably backwards compatible---, I firmly
believe that Emacs is a piece of software users should come to with a
knowledge of what to expect.  That’s not to mean it should be difficult,
as some are tending to interpret, but that Emacs constitutes a certain
paradigm of computing, and that that’s the main thing it has to offer.

As an example---tho it’s inevitably a single data point---I’ve never
been a user who is unable to figure out how to change the theme or
modify something in Emacs.  But I’ve only came to stick with it when I
uncovered what _actually_ it has to offer, over some keybindings and
random customisation.  It should also be considered how so many users
stick to Emacs despite it’s apparent that they are pretty much aware
that many other editors are way easier than Emacs, for some measure of
easy, and yet they stick to Emacs, despite the unfamiliarity, despite
the supposed difficulty.

We’re asking "why people aren’t coming to Emacs in hordes" too much,
when "why are people using Emacs in the first place" is the more
important one.

[1] https://lawsofux.com/

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

Re: Changes for emacs 28

[tomas]

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

On Sun, Sep 13, 2020 at 01:59:02PM +0300, Göktuğ Kayaalp wrote:

[...]

> A lot of that research is pseudo scientific.  E.g. some famous
> ‘principles’ of UX design are based on academesified opition or
> misappropriation of unrelated research.  E.g. see this one [1].  If you
> read the ‘scientific’ background to the ‘laws’, what you’ll see is that
> some of those are shaky, and some of those are lesser than that.

Thanks for the link, and thanks for your appreciation. Yes, I
see it similarly; this research may be, at the bottom, genuine,
but it is strongly modulated by marketing departments (at several
points: for one, of course, the software vendor's, but also the
UX research company's).

> We should focus on what makes users *stay* with Emacs [...]

This is an important point, I think.

> We’re asking "why people aren’t coming to Emacs in hordes" too much,
> when "why are people using Emacs in the first place" is the more
> important one.

Yes. It's always a balancing act, where the equilibrium point shifts
over time.

Diverging too far from what is "customary" isn't user friendly
(most of us use other software besides Emacs, and it raises the
barrier to entry), following the "customary" too closely creates
a lot of churn along the random walk, at the cost of Emacs users.

Cheers
 - t

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

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 13, 2020 at 01:59:02PM +0300, Göktuğ Kayaalp wrote:
>On 2020-09-13 13:30 +03, tomas@tuxteam.de wrote:
>> On a more serious note, what I wanted to point out is that there
>> are many forces shaping what is currently perceived as "usage
>> friendly". Some of them stem from ergonomy research (which, of
>> course, focuses on some population already exposed to software
>> "out there", so it's part of a feedback loop), some of it stems
>> from some manufacturer's attempt to differentiate itself, to
>> grow sales, some of it, even, from a strategy of appealing to
>> potential decision takers (who are /not/ those who have to use
>> the sofware later).
>
>A lot of that research is pseudo scientific.  E.g. some famous
>‘principles’ of UX design are based on academesified opition or
>misappropriation of unrelated research.  E.g. see this one [1].  If you
>read the ‘scientific’ background to the ‘laws’, what you’ll see is that
>some of those are shaky, and some of those are lesser than that.
>
>We should focus on what makes users *stay* with Emacs, and what makes
>such a stay comfortable.  While I see no harm in making the first steps
>easier---so long as it’s reasonably backwards compatible---, I firmly
>believe that Emacs is a piece of software users should come to with a
>knowledge of what to expect.  That’s not to mean it should be difficult,
>as some are tending to interpret, but that Emacs constitutes a certain
>paradigm of computing, and that that’s the main thing it has to offer.
>
>As an example---tho it’s inevitably a single data point---I’ve never
>been a user who is unable to figure out how to change the theme or
>modify something in Emacs.  But I’ve only came to stick with it when I
>uncovered what _actually_ it has to offer, over some keybindings and
>random customisation.  It should also be considered how so many users
>stick to Emacs despite it’s apparent that they are pretty much aware
>that many other editors are way easier than Emacs, for some measure of
>easy, and yet they stick to Emacs, despite the unfamiliarity, despite
>the supposed difficulty.
>
>We’re asking "why people aren’t coming to Emacs in hordes" too much,
>when "why are people using Emacs in the first place" is the more
>important one.
>
I would make also these questions:

Why the vanilla emacs users almost hasn't increased or has decreases if
the number of programmers has exponentially grow in the world?  And
being emacs so powerful and old; how is it possible that it is
frequently not even listed in the GNU/Linux popular editors articles or
it is back in the list?  The emacs popularity is so low these days (even
in GNU/Linux users) that some distros still comes with emacs 24. And if
we split spacemacs and doom apart it is almost negligible... we are even
after vim.

How the emacs modifications (specially spacemacs) have found a set of
frequent developers, and a big younger community? (which is not bigger
because it is a bit overloaded of external packages IMO)

How is it possible that all those dummy and young editors have multiple
times more users and community than Emacs when they don't really bring
anything much better than us?

Are we sure we don't need that "fresh air", "new ideas" and "lot of
work" to be happening in vanilla directly? Even if we (former users)
disagree with some of them and have to add 3, 4 or 10 extra lines to our
config to disable them?

I think that when emacs was created it was a revolutionary thing; it
brought an "easier" way to do "complex" things in that time's standard
and broke many paradigms. Why now we constantly insist in "paradigm of
computing" and "historic reasons" or "because in the 90's ..."? I am a
big supporter of backward compatibility, but sometimes the problem
becomes "evolve or die".

Every software has a complex social part; and part of that is to satisfy
general user's needs (because not all the users must be programmers and
even not all programmers have to be lisp programmers or understand the
emacs internals).

Just a recent example:

It's worth nothing to have a better technical feature if most of the
users prefer something else or don't really care the benefits if they
sacrifice simplicity (like for example undo) or don't know about them or
are used to, and like something else. OTOH the strong positions about
having a normal undo-redo in vanilla ()even not by default for years and
trying to enforce the user to follow our "technically better paradigm"
just made that alternative buggy undo-redo implementations grow like
mushrooms; some of them with bad implementations and giving a bad
experience to final users.

One of the things we must understand is that even not all developers
need to be programmers, know lisp or understand the benefits of undo
over undo-redo. We need help with the documentation, the web sites,
sysadmins, designers, web designers, javascript, CSS and the other
beasts, even youtubers, publishers and journalists etc. And is more
probable that all those help here if they can do part of their work in
emacs; even if they have no idea about lisp, packages, and prefer a
black screen and CUA mode.

It's my opinion.

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

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-13 15:53 +03, Ergus <spacibba@aol.com> wrote:
> Why the vanilla emacs users almost hasn't increased or has decreases if
> the number of programmers has exponentially grow in the world?  And
> being emacs so powerful and old; how is it possible that it is
> frequently not even listed in the GNU/Linux popular editors articles or
> it is back in the list?  The emacs popularity is so low these days (even
> in GNU/Linux users) that some distros still comes with emacs 24. And if
> we split spacemacs and doom apart it is almost negligible... we are even
> after vim.

Those distros are part of the Emacs community.  And IMHO a very good
part.  With them, a very diverse set of users find ways to make use of
Emacs.

As to why Emacs is not more popular, well, why should it be popular in
the first place?  I’d say Emacs has thrived in the last decade and
personally I’d fancy a stable but content community over a large one.

> How the emacs modifications (specially spacemacs) have found a set of
> frequent developers, and a big younger community? (which is not bigger
> because it is a bit overloaded of external packages IMO)

Because they are producing great software that helps people in ways
Emacs core may not.

> How is it possible that all those dummy and young editors have multiple
> times more users and community than Emacs when they don't really bring
> anything much better than us?

That’s insulting to the users and developers of those editors, which
are, again, great software.

> Are we sure we don't need that "fresh air", "new ideas" and "lot of
> work" to be happening in vanilla directly? Even if we (former users)
> disagree with some of them and have to add 3, 4 or 10 extra lines to our
> config to disable them?

Nobody’s against that so long as breakage is not _disastrous_.  And
certain changes proposed, like those regarding default colours, have the
potential to be so.

It’s not our configs.  It’s many packages that are built upon those
values.  Ultimately software evolves and APIs get outdated, but big
changes should be done with as much discussion and criticism as
possible, so please don’t think that the more conservative members of
the community are trying to hamper the development of Emacs or are
gatekeeping.  Everyone’s views are important and necessary.

> I think that when emacs was created it was a revolutionary thing; it
> brought an "easier" way to do "complex" things in that time's standard
> and broke many paradigms. Why now we constantly insist in "paradigm of
> computing" and "historic reasons" or "because in the 90's ..."? I am a
> big supporter of backward compatibility, but sometimes the problem
> becomes "evolve or die".

You’re over-dramatising it.  Emacs was a nice idea that built upon the
paradigm of software it was created in.  Lisp machines, screen editors
becoming a thing after the introduction of cursor adressable screens.

And there’s definitely ways to evolve compatibly.  Linux doesn’t die
because not everyone uses Yggdrasil anymore.

> Every software has a complex social part; and part of that is to satisfy
> general user's needs (because not all the users must be programmers and
> even not all programmers have to be lisp programmers or understand the
> emacs internals).

That’s a false tautology.  Not every piece of software needs to satisfy
every type of users’ needs.  In fact, software that tries to do that,
dies.



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

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 13, 2020 at 06:05:33PM +0300, Göktuğ Kayaalp wrote:
>On 2020-09-13 15:53 +03, Ergus <spacibba@aol.com> wrote:
>> Why the vanilla emacs users almost hasn't increased or has decreases if
>> the number of programmers has exponentially grow in the world?  And
>> being emacs so powerful and old; how is it possible that it is
>> frequently not even listed in the GNU/Linux popular editors articles or
>> it is back in the list?  The emacs popularity is so low these days (even
>> in GNU/Linux users) that some distros still comes with emacs 24. And if
>> we split spacemacs and doom apart it is almost negligible... we are even
>> after vim.
>
>Those distros are part of the Emacs community.  And IMHO a very good
>part.  With them, a very diverse set of users find ways to make use of
>Emacs.
>
Agree. But many times they need to reinvent the wheel and duplicate
efforts to add things unavailable and claimed in vanilla (there are many
examples of unneeded duplication in melpa with almost no differences
between them.)


>> How the emacs modifications (specially spacemacs) have found a set of
>> frequent developers, and a big younger community? (which is not bigger
>> because it is a bit overloaded of external packages IMO)
>
>Because they are producing great software that helps people in ways
>Emacs core may not.
>
Sometimes maybe, but in general... Why emacs may not?

>> How is it possible that all those dummy and young editors have multiple
>> times more users and community than Emacs when they don't really bring
>> anything much better than us?
>
>That’s insulting to the users and developers of those editors, which
>are, again, great software.
>
Sorry, I should have added: compared to emacs ;p

>> I think that when emacs was created it was a revolutionary thing; it
>> brought an "easier" way to do "complex" things in that time's standard
>> and broke many paradigms. Why now we constantly insist in "paradigm of
>> computing" and "historic reasons" or "because in the 90's ..."? I am a
>> big supporter of backward compatibility, but sometimes the problem
>> becomes "evolve or die".
>
>You’re over-dramatising it.  Emacs was a nice idea that built upon the
>paradigm of software it was created in.  Lisp machines, screen editors
>becoming a thing after the introduction of cursor adressable screens.
>
>And there’s definitely ways to evolve compatibly.  Linux doesn’t die
>because not everyone uses Yggdrasil anymore.
>
The difference is that vanilla is not a kernel not a "distro" but both.

The number of kernel developers is relatively big and the number of
GNU/Linux distros is huge, so they come and go without affecting the
kernel at all. There are also some companies implied to support the
kernel in different ways and of course the sort of "monopoly" the kernel
has in some fields like HPC and IOT.

While in our case emacs vanilla IS the distro, with many alternatives
around and a small set of developers doing their best.

So in case of a comparison, maybe openBSD is a more realistic
parallelism... and to compare with a distro you should look at spacemacs
or equivalents. If a distro disappears there are others coming, but if
the kernel disappears (or die) then also the distros will.

>> Every software has a complex social part; and part of that is to satisfy
>> general user's needs (because not all the users must be programmers and
>> even not all programmers have to be lisp programmers or understand the
>> emacs internals).
>
>That’s a false tautology.  Not every piece of software needs to satisfy
>every type of users’ needs.  In fact, software that tries to do that,
>dies.
>
>
I agree there, but not every piece of code is emacs. Otherwise we won't
have a music player, eww, mail client, terminal and gui interface,
dired and so on.

We can't expect to do the same than a specialized program (unless we
try). But text editing es something that almost everyone does so almost
everyone needs a text editor.

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

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-13 19:17 +03, Ergus <spacibba@aol.com> wrote:
> Agree. But many times they need to reinvent the wheel and duplicate
> efforts to add things unavailable and claimed in vanilla (there are many
> examples of unneeded duplication in melpa with almost no differences
> between them.)

That’s not a net negative.  Similar packages cater to similar but
different needs.

By that logic why have different text editors one ed(1) can handle all
text editing?

If you don’t think about it in competitive and/or corporate terms,
coexistence of similar but different projects is a net positive for any
use case because people’s needs are similar but different.

> Sometimes maybe, but in general... Why emacs may not?

B a c k w a r d s   c o m p a t i b i l i t y .

> Sorry, I should have added: compared to emacs ;p

Doesn’t change much.  Many of the editors we’re talking about are as
good and as capable as Emacs.

> The difference is that vanilla is not a kernel not a "distro" but both.
>
> The number of kernel developers is relatively big and the number of
> GNU/Linux distros is huge, so they come and go without affecting the
> kernel at all. There are also some companies implied to support the
> kernel in different ways and of course the sort of "monopoly" the kernel
> has in some fields like HPC and IOT.
>
> While in our case emacs vanilla IS the distro, with many alternatives
> around and a small set of developers doing their best.
>
> So in case of a comparison, maybe openBSD is a more realistic
> parallelism... and to compare with a distro you should look at spacemacs
> or equivalents. If a distro disappears there are others coming, but if
> the kernel disappears (or die) then also the distros will.

I don’t get what this is supposed to mean.  Emacs has lived on with way
smaller popularity and a smaller number of core developers for decades.

And the main roadblock there is the C core, not anything else.  There
are efforts like Remacs and Guile-Emacs, which are relevant in that
space.

> I agree there, but not every piece of code is emacs. Otherwise we won't
> have a music player, eww, mail client, terminal and gui interface,
> dired and so on.
>
> We can't expect to do the same than a specialized program (unless we
> try). But text editing es something that almost everyone does so almost
> everyone needs a text editor.

You’d be surprised.  The majority of computer users mainly use phones
and the majority of users don’t even know what plain text is, let alone
editing is.  You’d be surprised how hard it is to explain the concept of
plain text to people.

We’re a niche within a niche within a niche.

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

Re: Changes for emacs 28

[Arthur Miller]

tomas@tuxteam.de writes:

> On Sun, Sep 13, 2020 at 11:41:45AM +0300, Juri Linkov wrote:
>> >> > I think that this is the case, most programmes seem to use the
>> >> > "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
>> >> > what the reason for this change was, but I have a hunch one of the
>> >> > motivating reasons was the attempt to merge applications and the window
>> >> > frames
>> 
>> If the menu-bar isn't displayed then we could display the Hamburger icon
>> in the tool-bar, and clicking on it will pop-up the menu with items from
>> the menu-bar, so users won't need to display both menu-bar and tool-bar.
>> 
>> > Me? I'd say the Hamburger menu is the latest fad, to be taken over
>> > next year by the Sushi menu
>> 
>> Unlike the Hamburger menu that has three sticks,
>> the Sushi menu icon should have two chopsticks.
>
> Perhaps with something mushy and fishy in-between
Please keep it vegan!

> The table TEC posted (Message-ID: <87o8maj1kh.fsf@gmail.com>)
> is very interesting. Do you think the popularity of vscode
> and vs (both at the  list's top) stems from the colours? Or
> rather from the fact that there is an incredibly rich behemoth
> behind both of them and that many developers are working,
> directly or indirectly for it? Or from some mixture of both?
Money certainly plays role when it comes to making software; paid devs =
more development; but I wouldn't say VS (Studion or Code) are that
popular just because MS is behind.

> Microsoft has a long record of trying to suck in users into
> their dependency from them. It's their business model.
Yes, and now they are realeasing their "security services" to GNU/Linux
too to such in some of those users who are not using their OS:

https://techcommunity.microsoft.com/t5/microsoft-defender-atp/microsoft-defender-atp-for-linux-is-coming-and-a-sneak-peek-into/ba-p/1192251

I guess they will need to send some "feedback" data back to MS servers
for "security" analysis? :-)

> The fact that Microsoft put 7 billions on the table to
> acquire Github should be telling, in itself. A platform
> which transforms Git's inherently decentralised model into
> a centralised service (when I worked for some big company,
> developers there saw Github as a synonym for git, and that
> was before the acquisition).
They are out for user data; information is everything, big data and how
people use computers, exchange information etc is where money seems to
be. Probably same reason why they penetrate GNU/Linux too. I am sure one
day, operating system will go same destiny as text editors, web browsers
and compiler - be free of charge. It is probably a matter of time when
Windows will become free to user for "priate" and/or some business users.

> I'm not arguing that Emacs shoud make it hard for people coming
> from vscode, on the contrary. But the argument "it's more popular,
> so it must be better" is too naive, I think.
Indeed, popularity is not always a measure of quality. Best technology
does not always win, unfortunately, political, financial or other
reasons can unfortunately stand in the way of quality.

Re: Changes for emacs 28

[tomas]

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

On Sun, Sep 13, 2020 at 02:15:55PM +0200, Arthur Miller wrote:
> tomas@tuxteam.de writes:

[...]

> > Perhaps with something mushy and fishy in-between
> Please keep it vegan!

But then, non-vegan users will protest!

> > The table TEC posted [...]

> Money certainly plays role when it comes to making software; paid devs =
> more development;

...and thus mindshare

> but I wouldn't say VS (Studion or Code) are that
> popular just because MS is behind.

It's the mindshare effect I'm hinting at: if you are using
X at work (because you must: someone else has made that
choice for you), you'll tend to use X privately, since you
already invested in learning it. Perhaps you even don't notice
how much you invested (a kind of Stockholm syndrome), because
you did that "on pay".

Comparing "that ease of learning" to any other has to result
in a slanted playing field.

> They are out for user data [...]

I think that's only part of it. Dependency is key.

I've watched people trying to change their search engine.

Cheers
 - t

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

Re: Changes for emacs 28

[chad]

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

On Sun, Sep 13, 2020 at 3:31 AM <tomas@tuxteam.de> wrote:

> But the argument "it's more popular, so it must be better" is too naive, I
> think.
>

As conversations progress, details get dropped because context builds up.
That said, I think it's important to realize that "it's more popular, so it
must be better" isn't the argument that brought up this (current wave of
this periodically-recurring) discussion; rather, the argument is "people
try emacs but go (back) to VSCode, because ...". Usually, that sentence
ends in some form of "it's much easier/more intuitive to get started" or
"it's quick/easy/obvious how to get it to 'it just-works'".

In other words, the popularity is a symptom, not a cause. It's worthwhile
to remind ourselves of this now and then, but it's not the central thrust
of the original argument (even if it is sometimes used as evidence for
subsequent points).

Similarly, this point:

On Sun, Sep 13, 2020 at 3:59 AM Göktuğ Kayaalp <self@gkayaalp.com> wrote:

> We’re asking "why people aren’t coming to Emacs in hordes" too much,
> when "why are people using Emacs in the first place" is the more
> important one.


The argument that started (this wave) is more about how and why people
`bounce off of Emacs' so often. While there are always new people with
unique viewpoints, I have personally seen many, _many_ potential emacs
users (including programmers, scientists, and other professionals who very
much understand the concept of investing time in mastering tools) try
emacs, and give up, often very quickly. This has been happening for decades
-- For example, way back when I was an undergrad, I used to work user
support for students, faculty, and staff. Emacs was the default text
editor, and still we saw lots of people try emacs and give it up for other
choices, even when those options were known to be less powerful, buggier,
and not officially supported.

My point here is not to call anyone out in the discussion, but to remind
(reassert?) that Emacs' "approachability" has always been a concern, and
that issue has gotten more intense as the baseline of computer familiarity
and competence has increased dramatically. This issue doesn't concern
"market share" or "general popularity", although that has some obvious
upsides -- it's about the large numbers of people who understand that Emacs
should be especially interesting to them, and invest some effort into
trying it, and don't get very far. In addition to the fringe benefits of
network effects, there are a bunch of potential hackers, maintainers,
porters, documentation writers, editors, and the like that bounce off of
emacs. I think it's clear that it would be very helpful to the project to
have more of those people bounce off less quickly, at least.

Hope that helps,
~Chad

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

Re: Changes for emacs 28

[tomas]

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

On Mon, Sep 14, 2020 at 11:45:27AM -0700, chad wrote:
> On Sun, Sep 13, 2020 at 3:31 AM <tomas@tuxteam.de> wrote:
> 
> > But the argument "it's more popular, so it must be better" is too naive, I
> > think.

[...]

> try emacs but go (back) to VSCode, because ...". Usually, that sentence
> ends in some form of "it's much easier/more intuitive to get started" or
> "it's quick/easy/obvious how to get it to 'it just-works'".
> 
> In other words, the popularity is a symptom, not a cause.

This is exactly the point I was putting in question: My
take is that popularity is part of a giant feedback loop,
so it's *both*, a symptom and a cause. And a (non-negligible)
set of forces driving that feedback loop are the marketing
departments of big corps [1]. They wouldn't be doing their
jobs if it weren't so.

Failing to see this leads to this over-eager "how can we
change Emacs to make it more popular" thing, instead of
to a more balanced view, where potential changes are
judged against a more complete set of principles and
goals (newcomer friendliness surely being one of them!).

[...]

Cheers

[1] Whose goals and values don't always align with ours,
   to put it politely.

 - t

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

Re: Changes for emacs 28

[Dmitry Gutov]

On 15.09.2020 11:12, tomas@tuxteam.de wrote:
> On Mon, Sep 14, 2020 at 11:45:27AM -0700, chad wrote:
>> On Sun, Sep 13, 2020 at 3:31 AM <tomas@tuxteam.de> wrote:
>>
>>> But the argument "it's more popular, so it must be better" is too naive, I
>>> think.
> 
> [...]
> 
>> try emacs but go (back) to VSCode, because ...". Usually, that sentence
>> ends in some form of "it's much easier/more intuitive to get started" or
>> "it's quick/easy/obvious how to get it to 'it just-works'".
>>
>> In other words, the popularity is a symptom, not a cause.
> 
> This is exactly the point I was putting in question: My
> take is that popularity is part of a giant feedback loop,
> so it's *both*, a symptom and a cause. And a (non-negligible)
> set of forces driving that feedback loop are the marketing
> departments of big corps [1]. They wouldn't be doing their
> jobs if it weren't so.

A feedback loop is of course there.

But since we're not in marketing department, and we're not outlining a 
promotional campaign, it's also irrelevant.

We're not living in a vacuum, and we try to help real people. If a 
feature, or a UI design, or etc, has reached a significant level of 
popularity, adopting it in our program is likely to be beneficial. When 
someone comes in with just basic familiarity of other programs such as 
VS Code, and manages to become productive enough in Emacs faster because 
of that, it _is_ good.

It's far from the only consideration we should make, but scoffing at 
"popular" misses the point.

> Failing to see this leads to this over-eager "how can we
> change Emacs to make it more popular" thing, instead of
> to a more balanced view, where potential changes are
> judged against a more complete set of principles and
> goals (newcomer friendliness surely being one of them!).

As long as we don't discount familiarity when talking about newcomer 
friendliness, I agree.

Re: Changes for emacs 28

[tomas]

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

On Tue, Sep 15, 2020 at 09:27:42PM +0300, Dmitry Gutov wrote:

[...]

> >This is exactly the point I was putting in question: My
> >take is that popularity is part of a giant feedback loop,

[...]

> A feedback loop is of course there.
> 
> But since we're not in marketing department, and we're not outlining
> a promotional campaign, it's also irrelevant.

I think it's relevant, inasmuch as we should try to understand
where things come from, and especially how they impact user
freedom whenever we consider emulating them.

> We're not living in a vacuum, and we try to help real people. If a
> feature, or a UI design, or etc, has reached a significant level of
> popularity, adopting it in our program is likely to be beneficial.
> When someone comes in with just basic familiarity of other programs
> such as VS Code, and manages to become productive enough in Emacs
> faster because of that, it _is_ good.
> 
> It's far from the only consideration we should make,

Exactly.

>       but scoffing at "popular" misses the point.

I'm not for scoffing. But most definitely for a critical valuation
and for an understanding where things come from.

Some "features" coming from our "commercial competitors" may be
good ideas. Some are just attempts at differentiation, to gather
attention or market share. Copy the first, not necessarily the
second.

> >Failing to see this leads to this over-eager "how can we
> >change Emacs to make it more popular" [...]

> As long as we don't discount familiarity when talking about newcomer
> friendliness, I agree.

Alternatively, we can just offer bridges. Emacs is flexible
enough to play vi, after all :-)

Cheers
 - t

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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> This is exactly the point I was putting in question: My take is that 
> popularity is part of a giant feedback loop, so it's *both*, a symptom 
> and a cause. And a (non-negligible) set of forces driving that feedback 
> loop are the marketing departments of big corps [1]. They wouldn't be 
> doing their jobs if it weren't so.
>

This is not clear at all IMO.  When users choose to use VS Code or Atom or 
Emacs or ..., they choose between a number of free (as in beer) products. 
In such cases I tend to think that marketing plays little if any role, and 
that it's the quality of the product that matters.  More precisely, not 
the absolute quality, but the quality for newcomers.  As Chad wrote: "it's 
much easier/more intuitive to get started" or "it's quick/easy/obvious how 
to get it to 'it just-works'".

>
> Failing to see this leads to this over-eager "how can we change Emacs to 
> make it more popular" thing, instead of to a more balanced view, where 
> potential changes are judged against a more complete set of principles 
> and goals (newcomer friendliness surely being one of them!).
>

IMO, it's pointless to discuss whether Emacs should be changed, or how 
potential changes should be judged.  In fact I don't understand why such 
discussions/debates take place: Emacs is likely the most flexible of all 
available editors, and can be adapted to all imaginable needs.

So the only thing that should change in Emacs is that it should be made 
easier (even more: as easy as possible) to customize and understand for 
newcomers.

Re: Changes for emacs 28

[tomas]

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

On Tue, Sep 15, 2020 at 08:45:56PM +0000, Gregory Heytings wrote:
> 
> >
> >This is exactly the point I was putting in question: My take is
> >that popularity is part of a giant feedback loop [...]

> This is not clear at all IMO.  When users choose to use VS Code or
> Atom or Emacs or ..., they choose between a number of free (as in
> beer) products. In such cases [1] I tend to think that marketing plays
> little if any role, and that it's the quality of the product that
> matters.  More precisely, not the absolute quality, but the quality
> for newcomers.  As Chad wrote: "it's much easier/more intuitive to
> get started" or "it's quick/easy/obvious how to get it to 'it
> just-works'".

[1] But "such cases" are the exception. When I worked at a bigger
company, I /had/ to use (to me) horrible software. After a while,
most people got used to it and enjoyed their Stockholm syndrome.
I seem to be somewhat stubborn (which didn't make my life easier,
mind you).

[...]

> IMO, it's pointless to discuss whether Emacs should be changed, or
> how potential changes should be judged.  In fact I don't understand
> why such discussions/debates take place [...]

No, no. I think such debates are important, to help shape Emacs's
evolution.

> flexible of all available editors, and can be adapted to all
> imaginable needs.
> 
> So the only thing that should change in Emacs is that it should be
> made easier (even more: as easy as possible) to customize and
> understand for newcomers.

In this we agree.

Cheers
 - t

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

Re: Changes for emacs 28

[Alan Third]

On Tue, Sep 15, 2020 at 08:45:56PM +0000, Gregory Heytings via Emacs development discussions. wrote:
> This is not clear at all IMO.  When users choose to use VS Code or Atom or
> Emacs or ..., they choose between a number of free (as in beer) products. In
> such cases I tend to think that marketing plays little if any role, and that
> it's the quality of the product that matters.

One thing I see come up time and again is how so many people believe
that all Emacs users have crippled, arthritic hands because of the use
of modifiers. I'm sure it genuinely puts people off Emacs.

That is "marketing".
-- 
Alan Third

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 13 Sep 2020 11:41:45 +0300
> Cc: emacs-devel@gnu.org
> 
> If the menu-bar isn't displayed then we could display the Hamburger icon
> in the tool-bar, and clicking on it will pop-up the menu with items from
> the menu-bar, so users won't need to display both menu-bar and tool-bar.

If the menu bar isn't displayed, C-mouse-3 already displays a menu
that shows all the top-level menu-bar items.  So we don't really need
the Hamburger icon (but it wouldn't hurt to have it, of course --
provided they don't disable the tool bar as well...)

Re: Changes for emacs 28

[Juri Linkov]

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

>> If the menu-bar isn't displayed then we could display the Hamburger icon
>> in the tool-bar, and clicking on it will pop-up the menu with items from
>> the menu-bar, so users won't need to display both menu-bar and tool-bar.
>
> If the menu bar isn't displayed, C-mouse-3 already displays a menu
> that shows all the top-level menu-bar items.  So we don't really need
> the Hamburger icon (but it wouldn't hurt to have it, of course --
> provided they don't disable the tool bar as well...)

Yes, this is useful when they don't disable the tool bar,
then the Hamburger menu will look like this:


[-- Attachment #2: tool-bar-menu.png --]
[-- Type: image/png, Size: 21830 bytes --]

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


with this patch:

diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
index 7df1e28e06..3bb8f70ca1 100644
--- a/lisp/tool-bar.el
+++ b/lisp/tool-bar.el
@@ -249,6 +249,16 @@ tool-bar-local-item-from-menu
 (defun tool-bar-setup ()
   (setq tool-bar-separator-image-expression
 	(tool-bar--image-expression "separator"))
+
+  (let ((tool-bar-map (default-value 'tool-bar-map)))
+    (tool-bar-add-item "newsticker/narrow"
+                       (lambda ()
+			 (interactive)
+			 (popup-menu (mouse-menu-bar-map)))
+		       'menu-bar
+		       :visible '(zerop (or (frame-parameter nil 'menu-bar-lines) 0))
+		       :vert-only t
+		       :help "Pop up the global menu bar"))
   (tool-bar-add-item-from-menu 'find-file "new" nil :label "New File"
 			       :vert-only t)
   (tool-bar-add-item-from-menu 'menu-find-file-existing "open" nil

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: tomas@tuxteam.de,  emacs-devel@gnu.org
> Date: Sun, 13 Sep 2020 21:05:28 +0300
> 
> +    (tool-bar-add-item "newsticker/narrow"

This doesn't exactly look like a Hamburger menu icon...

Also, we'd like to have this at the right edge of the tool bar, where
users will expect it, I think.

Thanks.

Re: Changes for emacs 28

[Juri Linkov]

>> +    (tool-bar-add-item "newsticker/narrow"
>
> This doesn't exactly look like a Hamburger menu icon...

Really?  Maybe someone could help to draw a real hamburger.

> Also, we'd like to have this at the right edge of the tool bar, where
> users will expect it, I think.

IDK, some programs display it on the left, some on the right.

Anyway, there is a bug in tool-bar code that doesn't allow to use
align-to, whereas align-to works perfectly when used on the tab-bar.

Here is the test case to reproduce the bug on the tool-bar:

emacs -Q and eval:

  (define-key-after (default-value 'tool-bar-map) [global-menu-bar]
    `(menu-item (propertize " " 'display '(space :align-to (- right 5)))
                (lambda ()
                  (interactive)
                  (popup-menu (mouse-menu-bar-map)))
                :image ,(tool-bar--image-expression "newsticker/narrow")
                :help "Pop up the global menu bar"))
  (force-mode-line-update)

It doesn't align the icon to the right edge of the tool-bar
whereas the same code aligns it on the tab-bar.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: tomas@tuxteam.de,  emacs-devel@gnu.org
> Date: Sun, 13 Sep 2020 22:17:19 +0300
> 
> >> +    (tool-bar-add-item "newsticker/narrow"
> >
> > This doesn't exactly look like a Hamburger menu icon...
> 
> Really?  Maybe someone could help to draw a real hamburger.

You need 3 lines, not 4, for starters.

> > Also, we'd like to have this at the right edge of the tool bar, where
> > users will expect it, I think.
> 
> IDK, some programs display it on the left, some on the right.

But not in the middle, I presume?

> Anyway, there is a bug in tool-bar code that doesn't allow to use
> align-to, whereas align-to works perfectly when used on the tab-bar.
> 
> Here is the test case to reproduce the bug on the tool-bar:
> 
> emacs -Q and eval:
> 
>   (define-key-after (default-value 'tool-bar-map) [global-menu-bar]
>     `(menu-item (propertize " " 'display '(space :align-to (- right 5)))
>                 (lambda ()
>                   (interactive)
>                   (popup-menu (mouse-menu-bar-map)))
>                 :image ,(tool-bar--image-expression "newsticker/narrow")
>                 :help "Pop up the global menu bar"))
>   (force-mode-line-update)
> 
> It doesn't align the icon to the right edge of the tool-bar
> whereas the same code aligns it on the tab-bar.

Here, the above displays nothing at all on the tool bar.

bug#43405: Tool bar item doesn't align to the right edge

[Juri Linkov]

This bug report is from emacs-devel thread:

>> Anyway, there is a bug in tool-bar code that doesn't allow to use
>> align-to, whereas align-to works perfectly when used on the tab-bar.
>> 
>> Here is the test case to reproduce the bug on the tool-bar:
>> 
>> emacs -Q and eval:
>> 
>>   (define-key-after (default-value 'tool-bar-map) [global-menu-bar]
>>     `(menu-item (propertize " " 'display '(space :align-to (- right 5)))
>>                 (lambda ()
>>                   (interactive)
>>                   (popup-menu (mouse-menu-bar-map)))
>>                 :image ,(tool-bar--image-expression "newsticker/narrow")
>>                 :help "Pop up the global menu bar"))
>>   (force-mode-line-update)
>> 
>> It doesn't align the icon to the right edge of the tool-bar
>> whereas the same code aligns it on the tab-bar.
>
> Here, the above displays nothing at all on the tool bar.

The icon is displayed only after more changes in window-configuration like
switching buffers, i.e. force-mode-line-update (copied from tool-bar-local-item)
has no effect.

Another bug?  Or should this code use both (redraw-display) and
(force-mode-line-update) like in bug#43397?

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 14 Sep 2020 22:18:33 +0300
> 
> >> emacs -Q and eval:
> >> 
> >>   (define-key-after (default-value 'tool-bar-map) [global-menu-bar]
> >>     `(menu-item (propertize " " 'display '(space :align-to (- right 5)))
> >>                 (lambda ()
> >>                   (interactive)
> >>                   (popup-menu (mouse-menu-bar-map)))
> >>                 :image ,(tool-bar--image-expression "newsticker/narrow")
> >>                 :help "Pop up the global menu bar"))
> >>   (force-mode-line-update)
> >> 
> >> It doesn't align the icon to the right edge of the tool-bar
> >> whereas the same code aligns it on the tab-bar.
> >
> > Here, the above displays nothing at all on the tool bar.
> 
> The icon is displayed only after more changes in window-configuration like
> switching buffers, i.e. force-mode-line-update (copied from tool-bar-local-item)
> has no effect.
> 
> Another bug?  Or should this code use both (redraw-display) and
> (force-mode-line-update) like in bug#43397?

I didn't yet look into that bug report, so I cannot say.

Btw, are you trying this in a GTK build or with some other toolkit?

bug#43405: Tool bar item doesn't align to the right edge

[Juri Linkov]

> Btw, are you trying this in a GTK build or with some other toolkit?

I tried both GTK and no-toolkit, and it can't align the icon to the right
on the tool-bar.

Whereas the same code nicely alights the icon on the tab-bar:

(progn
  (tab-bar-mode)
  (advice-add
   'tab-bar-make-keymap-1 :around
   (lambda (orig-fun)
     (append (funcall orig-fun)
	     `((menu-bar
		menu-item
		,(concat
		  (propertize " " 'display '(space :align-to (- right 5)))
		  (propertize " " 'display
			      '(image :type xpm
				      :file "newsticker/narrow.xpm")))
		(lambda ()
		  (interactive)
		  (popup-menu (mouse-menu-bar-map)))))))
   '((name . tab-bar-menu-bar))))

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 43405@debbugs.gnu.org
> Date: Tue, 15 Sep 2020 21:14:45 +0300
> 
> > Btw, are you trying this in a GTK build or with some other toolkit?
> 
> I tried both GTK and no-toolkit, and it can't align the icon to the right
> on the tool-bar.
> 
> Whereas the same code nicely alights the icon on the tab-bar:
> 
> (progn
>   (tab-bar-mode)
>   (advice-add
>    'tab-bar-make-keymap-1 :around
>    (lambda (orig-fun)
>      (append (funcall orig-fun)
> 	     `((menu-bar
> 		menu-item
> 		,(concat
> 		  (propertize " " 'display '(space :align-to (- right 5)))
> 		  (propertize " " 'display
> 			      '(image :type xpm
> 				      :file "newsticker/narrow.xpm")))
> 		(lambda ()
> 		  (interactive)
> 		  (popup-menu (mouse-menu-bar-map)))))))
>    '((name . tab-bar-menu-bar))))

I think you forget how the tool bar is displayed.  In the versions of
Emacs that produce our native tool bar, the tool bar is displayed by
displaying a Lisp string made of spaces, where each space has a
display property which specifies the icon to display.  Your code puts
the :align-to properties on menu item's name, but that name is not
used at all for the display of tool bar, so it has no effect.  What
you need is to put the :align-to property on the respective space of
the Lisp string used to display the tool bar.  I don't think this can
be done in Lisp, we need support on the C level.

In the versions of Emacs that use the so-called "external tool bar",
like the GTK build, I don't see how :align-to can have any effect at
all; we need instead to use GTK facilities to arrange the buttons
(assuming that such facilities exist and are available to Emacs).

bug#43405: Tool bar item doesn't align to the right edge

[Juri Linkov]

> I think you forget how the tool bar is displayed.  In the versions of
> Emacs that produce our native tool bar, the tool bar is displayed by
> displaying a Lisp string made of spaces, where each space has a
> display property which specifies the icon to display.  Your code puts
> the :align-to properties on menu item's name, but that name is not
> used at all for the display of tool bar, so it has no effect.  What
> you need is to put the :align-to property on the respective space of
> the Lisp string used to display the tool bar.  I don't think this can
> be done in Lisp, we need support on the C level.

Actually, I didn't forget how the tool bar is displayed, but hoped
that maybe somehow this is still possible.

> In the versions of Emacs that use the so-called "external tool bar",
> like the GTK build, I don't see how :align-to can have any effect at
> all; we need instead to use GTK facilities to arrange the buttons
> (assuming that such facilities exist and are available to Emacs).

AFAIK, the GTK build supports 4 positions of the tool-bar:
'top', 'bottom' 'left', 'right'.  I can't imagine how the
Hamburger menu icon should be aligned for a tool-bar position
different from the default 'top'.

bug#43405: Tool bar item doesn't align to the right edge

[Robert Pluim]

>>>>> On Tue, 15 Sep 2020 21:39:22 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Eli> In the versions of Emacs that use the so-called "external tool bar",
    Eli> like the GTK build, I don't see how :align-to can have any effect at
    Eli> all; we need instead to use GTK facilities to arrange the buttons
    Eli> (assuming that such facilities exist and are available to Emacs).

The GTK code just adds items to the toolbar in order. Itʼs possible in
GTK to specify negative positions for toolbar items, but that just
means 'append', not 'align to right border' as far as I can see.

Hmm, if we were to use a 'header bar' rather than a 'tool bar', we
could use css to specify whether individual items are right or left
aligned. Iʼll leave that exercise up to someone else.

Robert

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Juri Linkov <juri@linkov.net>,  43405@debbugs.gnu.org
> Date: Thu, 17 Sep 2020 11:03:46 +0200
> 
> >>>>> On Tue, 15 Sep 2020 21:39:22 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> In the versions of Emacs that use the so-called "external tool bar",
>     Eli> like the GTK build, I don't see how :align-to can have any effect at
>     Eli> all; we need instead to use GTK facilities to arrange the buttons
>     Eli> (assuming that such facilities exist and are available to Emacs).
> 
> The GTK code just adds items to the toolbar in order. Itʼs possible in
> GTK to specify negative positions for toolbar items, but that just
> means 'append', not 'align to right border' as far as I can see.

Thanks.

If we cannot control the placement of icons on GTK, then I guess it
makes little sense to add features to do this in our native tool bar,
since most users will be unable to take advantage of it.

bug#43405: Tool bar item doesn't align to the right edge

[Robert Pluim]

>>>>> On Thu, 17 Sep 2020 16:45:16 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> The GTK code just adds items to the toolbar in order. Itʼs possible in
    >> GTK to specify negative positions for toolbar items, but that just
    >> means 'append', not 'align to right border' as far as I can see.

    Eli> Thanks.

    Eli> If we cannot control the placement of icons on GTK, then I guess it
    Eli> makes little sense to add features to do this in our native tool bar,
    Eli> since most users will be unable to take advantage of it.

Actually we *can* control the placement of the icons on the GTK
toolbar, as it turns out. Buried in the fine print is this sentence:

    If the GtkToolbar child property "expand" is TRUE and the property
    "draw" is set to FALSE, the effect is to force all following items to
    the end of the toolbar.

So if you do the following, all toolbar items added after this
separator end up on the right:

      ti = gtk_separator_tool_item_new ();
      gtk_tool_item_set_expand (ti, true);
      gtk_separator_tool_item_set_draw (GTK_SEPARATOR_TOOL_ITEM (ti), true);
      gtk_toolbar_insert (GTK_TOOLBAR (wtoolbar), ti, j);

It does produce an ugly empty patch in the middle of the toolbar
thatʼs a different colour though.

The other way to do this would be to add toolbar items at specific
positions in the toolbar, but I couldn't find an api that answered the
question "how many items of size x can I add before I reach the right
border of the window" (and then weʼd have to recalculate the positions
if the frame changes size).

Robert

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 43405@debbugs.gnu.org,  juri@linkov.net
> Date: Thu, 17 Sep 2020 16:43:37 +0200
> 
>     If the GtkToolbar child property "expand" is TRUE and the property
>     "draw" is set to FALSE, the effect is to force all following items to
>     the end of the toolbar.
> 
> So if you do the following, all toolbar items added after this
> separator end up on the right:
> 
>       ti = gtk_separator_tool_item_new ();
>       gtk_tool_item_set_expand (ti, true);
>       gtk_separator_tool_item_set_draw (GTK_SEPARATOR_TOOL_ITEM (ti), true);
>       gtk_toolbar_insert (GTK_TOOLBAR (wtoolbar), ti, j);
> 
> It does produce an ugly empty patch in the middle of the toolbar
> thatʼs a different colour though.

So you are saying that, while possible, doing this is not really
workable, since it produces ugly display?

bug#43405: Tool bar item doesn't align to the right edge

[Robert Pluim]

>>>>> On Thu, 17 Sep 2020 17:54:15 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: 43405@debbugs.gnu.org,  juri@linkov.net
    >> Date: Thu, 17 Sep 2020 16:43:37 +0200
    >> 
    >> If the GtkToolbar child property "expand" is TRUE and the property
    >> "draw" is set to FALSE, the effect is to force all following items to
    >> the end of the toolbar.
    >> 
    >> So if you do the following, all toolbar items added after this
    >> separator end up on the right:
    >> 
    >> ti = gtk_separator_tool_item_new ();
    >> gtk_tool_item_set_expand (ti, true);
    >> gtk_separator_tool_item_set_draw (GTK_SEPARATOR_TOOL_ITEM (ti), true);
    >> gtk_toolbar_insert (GTK_TOOLBAR (wtoolbar), ti, j);
    >> 
    >> It does produce an ugly empty patch in the middle of the toolbar
    >> thatʼs a different colour though.

    Eli> So you are saying that, while possible, doing this is not really
    Eli> workable, since it produces ugly display?

You know this is 2020, so truth == lies, and lies == truth, right?
So, once I actually follow the documentation and pass 'false' in the right
place, the toolbar looks correct :-)

Now the question is: do we want to expose this to lisp, and if so,
how? I mean, I have no idea if the macOS or MS-Windows tool bar have
a similar feature.

Robert

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 43405@debbugs.gnu.org,  juri@linkov.net
> Date: Thu, 17 Sep 2020 17:24:55 +0200
> 
> You know this is 2020, so truth == lies, and lies == truth, right?

Yes, I tend to forget this from time to time...

> So, once I actually follow the documentation and pass 'false' in the right
> place, the toolbar looks correct :-)

Great, thanks.

> Now the question is: do we want to expose this to lisp

I think so, yes.

> and if so, how?

Some attribute of the binding, similar to :image and :vert-only, I
guess?

> I mean, I have no idea if the macOS or MS-Windows tool bar have a
> similar feature.

I don't know about macOS, but MS-Windows uses the native tool bar
produced by our own code, i.e. it displays a Lisp string in a special
window.

bug#43405: Tool bar item doesn't align to the right edge

[Robert Pluim]

>>>>> On Thu, 17 Sep 2020 18:33:17 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> Now the question is: do we want to expose this to lisp

    Eli> I think so, yes.

    >> and if so, how?

    Eli> Some attribute of the binding, similar to :image and :vert-only, I
    Eli> guess?

    >> I mean, I have no idea if the macOS or MS-Windows tool bar have a
    >> similar feature.

    Eli> I don't know about macOS, but MS-Windows uses the native tool bar
    Eli> produced by our own code, i.e. it displays a Lisp string in a special
    Eli> window.

OK, so I took a look, and Iʼm not sure itʼs possible with the native
tool bar. We have '(space :align-to right)', but that just inserts
space up to a specified location, everything subsequent is
appended. In order to calculate the correct location, Iʼd need to know
the width of everything that came after the space, which only
redisplay can tell us, unless thereʼs a function Iʼve missed?
'string-width' doesnʼt take 'display properties into account.

macOS has something called a flexibleSpace toolbar item that might
serve, but Iʼm utterly ignorant of how the macOS code works.

Robert

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 43405@debbugs.gnu.org,  juri@linkov.net
> Date: Fri, 18 Sep 2020 10:38:18 +0200
> 
>     Eli> Some attribute of the binding, similar to :image and :vert-only, I
>     Eli> guess?
> 
>     >> I mean, I have no idea if the macOS or MS-Windows tool bar have a
>     >> similar feature.
> 
>     Eli> I don't know about macOS, but MS-Windows uses the native tool bar
>     Eli> produced by our own code, i.e. it displays a Lisp string in a special
>     Eli> window.
> 
> OK, so I took a look, and Iʼm not sure itʼs possible with the native
> tool bar. We have '(space :align-to right)', but that just inserts
> space up to a specified location, everything subsequent is
> appended. In order to calculate the correct location, Iʼd need to know
> the width of everything that came after the space, which only
> redisplay can tell us, unless thereʼs a function Iʼve missed?

The support for doing this with the native tool bar must be in C, and
should indeed be part of the display engine.  So everything redisplay
knows should be at your fingertips.

bug#43405: Tool bar item doesn't align to the right edge

[Robert Pluim]

>>>>> On Fri, 18 Sep 2020 11:58:21 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> OK, so I took a look, and Iʼm not sure itʼs possible with the native
    >> tool bar. We have '(space :align-to right)', but that just inserts
    >> space up to a specified location, everything subsequent is
    >> appended. In order to calculate the correct location, Iʼd need to know
    >> the width of everything that came after the space, which only
    >> redisplay can tell us, unless thereʼs a function Iʼve missed?

    Eli> The support for doing this with the native tool bar must be in C, and
    Eli> should indeed be part of the display engine.  So everything redisplay
    Eli> knows should be at your fingertips.

Your fingertips maybe, not mine :-)

So let's assume we do this by exending the display spec to allow

'(:right-justify t)

which would mean to move everything on this line as far to the right
in the window as possible.

At some point weʼd end up in 'gui_produce_glyphs' with a 'struct
iter' pointing at the char with that property set. Then:

remember it->current_x
loop over the iters until we hit eol or max_x, calling PRODUCE_GLPYHS
The final it->current_x minus the remembered one is the width of the remaining
glyphs on the line.
Now set it->current_x to the window right edge minus the width.

Does that sound like it would work? Is there a more direct way of
calculating that width? (I got lost in all the various move_to
functions).

Robert

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 43405@debbugs.gnu.org,  juri@linkov.net
> Date: Mon, 21 Sep 2020 20:30:53 +0200
> 
> So let's assume we do this by exending the display spec to allow
> 
> '(:right-justify t)
> 
> which would mean to move everything on this line as far to the right
> in the window as possible.
> 
> At some point weʼd end up in 'gui_produce_glyphs' with a 'struct
> iter' pointing at the char with that property set. Then:
> 
> remember it->current_x
> loop over the iters until we hit eol or max_x, calling PRODUCE_GLPYHS
> The final it->current_x minus the remembered one is the width of the remaining
> glyphs on the line.
> Now set it->current_x to the window right edge minus the width.
> 
> Does that sound like it would work? Is there a more direct way of
> calculating that width? (I got lost in all the various move_to
> functions).

I'd first try to repeat what we do for :align-to support: insert a
stretch glyph of a suitable width, computed using it->last_visible_x
and the width of the image for the button that has to be
right-justified.  See produce_stretch_glyph (except that most of it is
not relevant, since :align-to supports a lot of functionalities).

bug#43405: Tool bar item doesn't align to the right edge

[Robert Pluim]

>>>>> On Mon, 21 Sep 2020 22:04:36 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> Does that sound like it would work? Is there a more direct way of
    >> calculating that width? (I got lost in all the various move_to
    >> functions).

    Eli> I'd first try to repeat what we do for :align-to support: insert a
    Eli> stretch glyph of a suitable width, computed using it->last_visible_x
    Eli> and the width of the image for the button that has to be
    Eli> right-justified.  See produce_stretch_glyph (except that most of it is
    Eli> not relevant, since :align-to supports a lot of functionalities).

OK, that would work, but then you could only right justify a single
item, which would be different from what you can do with the GTK tool
bar (and I see no reason to restrict this to tool bar buttons, I see
at least org-mode wants to right-justify headline tags)

Robert

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 43405@debbugs.gnu.org,  juri@linkov.net
> Date: Mon, 21 Sep 2020 22:07:51 +0200
> 
>     Eli> I'd first try to repeat what we do for :align-to support: insert a
>     Eli> stretch glyph of a suitable width, computed using it->last_visible_x
>     Eli> and the width of the image for the button that has to be
>     Eli> right-justified.  See produce_stretch_glyph (except that most of it is
>     Eli> not relevant, since :align-to supports a lot of functionalities).
> 
> OK, that would work, but then you could only right justify a single
> item, which would be different from what you can do with the GTK tool
> bar

No, it will work with more than one as well, you just need to loop
twice over all the buttons and keep track of all those which should be
right-justified.

> (and I see no reason to restrict this to tool bar buttons, I see
> at least org-mode wants to right-justify headline tags)

What are "headline tags" in Org, and how are they related?

Your original description said:

> So let's assume we do this by exending the display spec to allow
> 
> '(:right-justify t)
> 
> which would mean to move everything on this line as far to the right
> in the window as possible.

"Everything on this line" on which line?

Do you mean you want to display an entire screen line justified to the
right?  Then we already do something like that with R2L lines
(although there we also reorder display elements, something you don't
need here).

bug#43405: Tool bar item doesn't align to the right edge

[Robert Pluim]

>>>>> On Tue, 22 Sep 2020 17:39:23 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: 43405@debbugs.gnu.org,  juri@linkov.net
    >> Date: Mon, 21 Sep 2020 22:07:51 +0200
    >> 
    Eli> I'd first try to repeat what we do for :align-to support: insert a
    Eli> stretch glyph of a suitable width, computed using it->last_visible_x
    Eli> and the width of the image for the button that has to be
    Eli> right-justified.  See produce_stretch_glyph (except that most of it is
    Eli> not relevant, since :align-to supports a lot of functionalities).
    >> 
    >> OK, that would work, but then you could only right justify a single
    >> item, which would be different from what you can do with the GTK tool
    >> bar

    Eli> No, it will work with more than one as well, you just need to loop
    Eli> twice over all the buttons and keep track of all those which should be
    Eli> right-justified.

OK, weʼre saying the same thing with different words: everything to
the right of this stretch glyph needs its width calculated (and its
x-coordinate adjusted)

    >> (and I see no reason to restrict this to tool bar buttons, I see
    >> at least org-mode wants to right-justify headline tags)

    Eli> What are "headline tags" in Org, and how are they related?

Org headlines look like this:

* This is a headline                       :tag1:tag2:tag3

The tags are right justified by default, but this is done by inserting
spaces, which fails with non-monospace fonts. Thereʼs a patch to
org-mode to do this by instead inserting a space with an :align-to
property, but that code has to calculate the value to specify in lisp,
which I strongly suspect will turn out to be slow, hence doing it in
redisplay would be better (and perhaps more likely to be accurate).

    Eli> Your original description said:

    >> So let's assume we do this by exending the display spec to allow
    >> 
    >> '(:right-justify t)
    >> 
    >> which would mean to move everything on this line as far to the right
    >> in the window as possible.

    Eli> "Everything on this line" on which line?

Sorry, everything on this line after whatever element has that display
spec. Everything before stays where it is (and only the first
:right-justify property found in the line is acted upon).

    Eli> Do you mean you want to display an entire screen line justified to the
    Eli> right?  Then we already do something like that with R2L lines
    Eli> (although there we also reorder display elements, something you don't
    Eli> need here).

No, I just want to be able to produce:

This is text                          This is right justified

And have the "This is right justified" stay right justified as the
window size and line content changes (unless the user deletes that
stretch glyph in the middle).

If the line became longer than could be displayed in the available
window width, then I think the stretch glyph in the middle would just
be treated as a single space (and hence line continuation/truncation
would work as normal).

Robert

bug#43405: Tool bar item doesn't align to the right edge

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 43405@debbugs.gnu.org,  juri@linkov.net
> Date: Tue, 22 Sep 2020 17:14:18 +0200
> 
> No, I just want to be able to produce:
> 
> This is text                          This is right justified
> 
> And have the "This is right justified" stay right justified as the
> window size and line content changes (unless the user deletes that
> stretch glyph in the middle).
> 
> If the line became longer than could be displayed in the available
> window width, then I think the stretch glyph in the middle would just
> be treated as a single space (and hence line continuation/truncation
> would work as normal).

Then the way to do this is to set some flag on the first glyph after
the stretch, lay out the glyphs on the screen line as usual, then go
back to that marked glyph and recompute the width of the stretch.  It
will complicate the likes of display_line a bit, and will need to
disable some redisplay optimizations (so there should be some easy way
of knowing that such lines are in the buffer).

bug#43405: Tool bar item doesn't align to the right edge

[spvk]

Juri Linkov <juri@linkov.net> writes:

> The icon is displayed only after more changes in window-configuration like
> switching buffers, i.e. force-mode-line-update (copied from tool-bar-local-item)
> has no effect.
>
> Another bug?  Or should this code use both (redraw-display) and
> (force-mode-line-update) like in bug#43397?

I tried all related functions that I could think of
(force-mode-line-update, redraw-display, force-mode-line-update) just to 
try to understand what is happening. I.e. I don't know what the code
should use and I don't know if this is a bug.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 09:04:59AM +0200, Philip K. wrote:
>Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > I'm not a maintainer, but FWIW my opinion is that what will most likely
>>   > happen is that they will never agree to do this.  Menus are not "modern".
>>
>> What in the world?  This strikes me as incomprehensible.
>>
>> Who thinks "Menus are not modern"?  Why?
>> What do they use instead of menus?
>>
>> (Perhaps they use a different kind of menu
>> but do not think of it as a manu.)
>
>I think that this is the case, most programmes seem to use the
>"Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
>what the reason for this change was, but I have a hunch one of the
>motivating reasons was the attempt to merge applications and the window
>frames (as GNOME does in the free software world, but Chrome, MS Office,
>etc. do in the non-free world). When no space is left between the
>application and it's frame, the menu must be moved somewhere
>else. Another reason is probably the influence of mobile applications,
>that use these kinds of menus due to lack of space.
>
>[0] https://en.wikipedia.org/wiki/Hamburger_button
>
>-- 
>	Philip K.
>
I agree that people are using such "Hamburger Menu" (not telling we
should do the same or not) Because in the same way some users are
concerned about space saving and line-numbers; others are concerned
about vertical space and menu-bar + toolbar space saving. Usually
screens are wider than taller.

The other thing is the addiction to right click and find everything
there (undo, redo, copy, paste, goto, select all, goto). 

Re: Changes for emacs 28

[Richard Stallman]

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

  > The other thing is the addiction to right click and find everything
  > there (undo, redo, copy, paste, goto, select all, goto). 

If we think about this, maybe we could make Emacs handle right-click
in a way they would like.  But it needs to be studied concretely
to make a concrete proposal.

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

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 11:21:41PM -0400, Richard Stallman wrote:
>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>[[[ whether defending the US Constitution against all enemies,     ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>  > The other thing is the addiction to right click and find everything
>  > there (undo, redo, copy, paste, goto, select all, goto).
>
>If we think about this, maybe we could make Emacs handle right-click
>in a way they would like.  But it needs to be studied concretely
>to make a concrete proposal.
>
Actually there are already some context menus for right click.

https://github.com/zonuexe/right-click-context
or
https://www.emacswiki.org/emacs/mouse3.el

In the simplest case we only need to put in the right-click menu what is
already in the tool-bar.

The real problem is that now the right click is bind to
mouse-save-then-kill which I have never ever used, but probably others
have.



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

Re: Changes for emacs 28

[Juri Linkov]

> In the simplest case we only need to put in the right-click menu what is
> already in the tool-bar.

The right-click menu needs to be a combination of submenus with:

1. tool-bar items;
2. major-mode menu (currently on <C-down-mouse-3>);
3. buffer menu (currently on <C-down-mouse-1>);
4. face menu (currently on <C-down-mouse-2>);
5. appearance menu (currently on <S-down-mouse-1>);
...

> The real problem is that now the right click is bind to
> mouse-save-then-kill which I have never ever used, but probably others
> have.

Not a problem, just add a new customization option to disable
mouse-save-then-kill on mouse-3, and use the context menu instead.

RE: Changes for emacs 28

[Drew Adams]

> > > I'm not a maintainer, but FWIW my opinion is that what will most likely
> > > happen is that they will never agree to do this.  Menus are not "modern".
> >
> > What in the world?  This strikes me as incomprehensible.
> > Who thinks "Menus are not modern"?  Why?
> > What do they use instead of menus?
> > (Perhaps they use a different kind of menu
> > but do not think of it as a manu.)
> 
> I think that this is the case, most programmes seem to use the
> "Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
> what the reason for this change was, but I have a hunch one of the
> motivating reasons was the attempt to merge applications and the window
> frames (as GNOME does in the free software world, but Chrome, MS Office,
> etc. do in the non-free world). When no space is left between the
> application and it's frame, the menu must be moved somewhere
> else. Another reason is probably the influence of mobile applications,
> that use these kinds of menus due to lack of space.

1. `C-mouse-3' does that - essentially a hamburger menu.

2. Library `tool-bar+.el' offers something similar for
the tool-bar: `tool-bar-pop-up-mode'.  It adds a pseudo
menu to the menu-bar, which, if clicked, shows the
tool-bar for the use of a single action.  This saves the
tool-bar real estate most of the time.

If the menu-bar isn't displayed then you can just use
`C-mouse-3' to show it, and choose the pseudo menu that
pops up the tool-bar temporarily.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus

Re: Changes for emacs 28

[Richard Stallman]

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

  > I think that this is the case, most programmes seem to use the
  > "Hamburger Menu"[0] instead of a transitional top-menu.

The people who say "menus are not modern" are failing to clearly
analyze what are complaining about -- or else their message has
been garbled in transmission to us.

They do not dislike menus.  They dislike one particular way of
displaying menus.

I have seen programs with hamburger buttons.  If you don't want to use
the menus very often, that interface is ok.

Now that we understand what they meant, maybe we can give them what
they want.  Can we implement Emacs menus through the hamburger systems
of various toolkits?  Run them through the meatgrinder, shall we say?
;-}

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

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. 
wrote:
> 
> I'm not a maintainer, but FWIW my opinion is that what will most likely 
> happen is that they will never agree to do this.  Menus are not "modern".

That's certainly the current trend in Emacs customizations, but it's not 
a universal rule.

VS Code has a traditional menu. Atom has a menu. Visual Studio and 
IntelliJ IDEA of course have them too.

Re: Changes for emacs 28

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>> I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>> is that they will never agree to do this.  Menus are not "modern".
>
> That's certainly the current trend in Emacs customizations, but it's not a
> universal rule.
>
> VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
> of course have them too.
When I used to make money by programming VBA with MS Office and C++ with
VStudio I used to turn off all toolbars and menus I could. Back then
computer screens where much smaller then today, and even today I still
fight for vertical screen estate on my computer.

For that reason, on my home computer I run a WM without decorations, Emacs
without any gui elements more then main gui window, Firefox & Gimp with
menus and gui hidden etc. I have never used IntellliJ software, but I
guess they will give you option to maximize the working area by
disabling the gui items too.

Anyway, I don't think GUI should be disabled by default; that should be left to
the user. I am really curious which distro you run :-)?

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 14:00, Arthur Miller wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>>> I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>>> is that they will never agree to do this.  Menus are not "modern".
>>
>> That's certainly the current trend in Emacs customizations, but it's not a
>> universal rule.
>>
>> VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
>> of course have them too.
> When I used to make money by programming VBA with MS Office and C++ with
> VStudio I used to turn off all toolbars and menus I could. Back then
> computer screens where much smaller then today, and even today I still
> fight for vertical screen estate on my computer.

I do too. But menus should be helpful for newcomers (and when they are 
not, we should improve them). So having "starter kits" disable the menus 
right away seems counter-productive.

BTW, the Unity DE and Sublime Text editor included an alternative UI for 
menus, where you hit a key (Alt, in the case of Unity) and then fuzzy 
match on command description.

> For that reason, on my home computer I run a WM without decorations, Emacs
> without any gui elements more then main gui window, Firefox & Gimp with
> menus and gui hidden etc. I have never used IntellliJ software, but I
> guess they will give you option to maximize the working area by
> disabling the gui items too.
> 
> Anyway, I don't think GUI should be disabled by default; that should be left to
> the user. I am really curious which distro you run :-)?

I use Ubuntu with GNOME and the Unite extension which emulates Unity to 
the best extent possible. That means removing application title bars 
when the app is maximized, moving their contents (such as menus) to the 
top panel when possible.

So it's the kind of changes as you did, but to a smaller extent.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 03:50:24PM +0300, Dmitry Gutov wrote:
>On 11.09.2020 14:00, Arthur Miller wrote:
>>Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>>On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>>>>I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>>>>is that they will never agree to do this.� Menus are not "modern".
>>>
>>>That's certainly the current trend in Emacs customizations, but it's not a
>>>universal rule.
>>>
>>>VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
>>>of course have them too.
>>When I used to make money by programming VBA with MS Office and C++ with
>>VStudio I used to turn off all toolbars and menus I could. Back then
>>computer screens where much smaller then today, and even today I still
>>fight for vertical screen estate on my computer.
>
>I do too. But menus should be helpful for newcomers (and when they are 
>not, we should improve them). So having "starter kits" disable the 
>menus right away seems counter-productive.
>
>BTW, the Unity DE and Sublime Text editor included an alternative UI 
>for menus, where you hit a key (Alt, in the case of Unity) and then 
>fuzzy match on command description.
>
Just a question as I don't use sublime anymore. Do you mean something
like "autohiding" the toolbar or part of it?

>>For that reason, on my home computer I run a WM without decorations, Emacs
>>without any gui elements more then main gui window, Firefox & Gimp with
>>menus and gui hidden etc. I have never used IntellliJ software, but I
>>guess they will give you option to maximize the working area by
>>disabling the gui items too.
>>
>>Anyway, I don't think GUI should be disabled by default; that should be left to
>>the user. I am really curious which distro you run :-)?
>
>I use Ubuntu with GNOME and the Unite extension which emulates Unity 
>to the best extent possible. That means removing application title 
>bars when the app is maximized, moving their contents (such as menus) 
>to the top panel when possible.
>
>So it's the kind of changes as you did, but to a smaller extent.
>
The toolbar is less useful if the right click offers the expected
options in a panel (copy, paste, cut, select all, upcase, highlight all
like this, show error at point).

That's why many applications have removed or hided the toolbar; because
a right click is usually faster than moving the mouse to the top of the
screen. (they also use the <menu> key to show the right click panel from
keyboard but we use it for execute-extended-command)

Sadly we have <mouse-3> bind to mouse-save-then-kill which I don't find
useful at all, but maybe somebody will complain if we change it to
C-<mouse-3> and move the panel to <mouse-3>. Also our right click panel
does not offer those options so it is not as useful now.

Actually there is an external package for that:

https://github.com/zonuexe/right-click-context

So the implementation seems to be pretty simple if we agree in this. WDYT?

RE: Changes for emacs 28

[Drew Adams]

> Sadly we have <mouse-3> bind to mouse-save-then-kill which I don't find
> useful at all, but maybe somebody will complain if we change it to
> C-<mouse-3> and move the panel to <mouse-3>.

1. `mouse-save-then-kill' is very useful, IMO.

2. Library `mouse3.el' gives you any behavior you want
   for mouse-3 - in particular, popup context menus of
   any sort.

   AND it gives you the usual `mouse-save-then-kill'
   behavior.

   IOW, you don't have to choose one or the other, you
   can have both: choose what you want on the fly.

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

https://www.emacswiki.org/emacs/download/mouse3.el


This option lets you do whatever you want with a second
mouse-3 click.  And option `mouse3-double-click-command'
does the same thing for a double-click.

,----
| mouse3-second-click-default-command is a variable defined in `mouse3.el'.
| Its value is mouse3-popup-menu
| 
| Command used for a second `mouse-3' click at the same location.
| The command must accept 2 args: mouse click event and prefix arg.
| 
| This is a default value, which can be programmatically overridden in
| various contexts.  This option is used only if variable
| `mouse3-save-then-kill-command' is nil.
| 
| Two particular values:
|  `mouse3-popup-menu': Pop up a menu of actions on the region.
|  `mouse3-kill/delete-region': Kill or delete the region, according to
|                               `mouse-drag-copy-region'.
| 
| See also `mouse3-double-click-command'.  You will probably want to
| customize these two options together.  To make either a no-op, set the
| value to command `ignore'.
| 
| Note that setting `mouse3-double-click-command' to `mouse3-popup-menu'
| and `mouse3-second-click-default-command' to
| `mouse3-kill/delete-region' is not recommended, because in Emacs a
| double-click event is always preceded automatically by the associated
| single-click event.  See `(elisp) Repeat Events'.
| 
| You can customize this variable.
`----

Re: Changes for emacs 28

[Ergus]

Hi Drew:

This looks interesting. I will give it a look in a while.

Why you don't add your packages to elpa :( otherwise I/us will never
discover them?

Also, if integration with use-packages finally arrives many elpa
packages could be installed on the fly for the new users. And some of
your improvements seems to be good candidates.

And if you update them, the users will get the improvements immediately.

Is it too much work?

On Fri, Sep 11, 2020 at 11:29:41AM -0700, Drew Adams wrote:
>> Sadly we have <mouse-3> bind to mouse-save-then-kill which I don't find
>> useful at all, but maybe somebody will complain if we change it to
>> C-<mouse-3> and move the panel to <mouse-3>.
>
>1. `mouse-save-then-kill' is very useful, IMO.
>
>2. Library `mouse3.el' gives you any behavior you want
>   for mouse-3 - in particular, popup context menus of
>   any sort.
>
>   AND it gives you the usual `mouse-save-then-kill'
>   behavior.
>
>   IOW, you don't have to choose one or the other, you
>   can have both: choose what you want on the fly.
>
>https://www.emacswiki.org/emacs/Mouse3
>
>https://www.emacswiki.org/emacs/download/mouse3.el
>
>
>This option lets you do whatever you want with a second
>mouse-3 click.  And option `mouse3-double-click-command'
>does the same thing for a double-click.
>
>,----
>| mouse3-second-click-default-command is a variable defined in `mouse3.el'.
>| Its value is mouse3-popup-menu
>|
>| Command used for a second `mouse-3' click at the same location.
>| The command must accept 2 args: mouse click event and prefix arg.
>|
>| This is a default value, which can be programmatically overridden in
>| various contexts.  This option is used only if variable
>| `mouse3-save-then-kill-command' is nil.
>|
>| Two particular values:
>|  `mouse3-popup-menu': Pop up a menu of actions on the region.
>|  `mouse3-kill/delete-region': Kill or delete the region, according to
>|                               `mouse-drag-copy-region'.
>|
>| See also `mouse3-double-click-command'.  You will probably want to
>| customize these two options together.  To make either a no-op, set the
>| value to command `ignore'.
>|
>| Note that setting `mouse3-double-click-command' to `mouse3-popup-menu'
>| and `mouse3-second-click-default-command' to
>| `mouse3-kill/delete-region' is not recommended, because in Emacs a
>| double-click event is always preceded automatically by the associated
>| single-click event.  See `(elisp) Repeat Events'.
>|
>| You can customize this variable.
>`----

RE: Changes for emacs 28

[Drew Adams]

> Hi Drew:
> 
> This looks interesting. I will give it a look in a while.
> 
> Why you don't add your packages to elpa :( otherwise I/us will never
> discover them?
> 
> Also, if integration with use-packages finally arrives many elpa
> packages could be installed on the fly for the new users. And some of
> your improvements seems to be good candidates.
> 
> And if you update them, the users will get the improvements immediately.
> 
> Is it too much work?

Sorry.  I prefer to upload to Emacs Wiki (locked pages).

https://www.reddit.com/r/emacs/comments/7vocqa/update_on_melpa_removing_emacswiki_packages_they/dtuhzmt/

It's not hard to discover my Lisp libraries.
It's not hard to use them.  YMMV.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 12:23:34PM -0700, Drew Adams wrote:
>> Hi Drew:
>>
>> This looks interesting. I will give it a look in a while.
>>
>> Why you don't add your packages to elpa :( otherwise I/us will never
>> discover them?
>>
>> Also, if integration with use-packages finally arrives many elpa
>> packages could be installed on the fly for the new users. And some of
>> your improvements seems to be good candidates.
>>
>> And if you update them, the users will get the improvements immediately.
>>
>> Is it too much work?
>
>Sorry.  I prefer to upload to Emacs Wiki (locked pages).
>
>https://www.reddit.com/r/emacs/comments/7vocqa/update_on_melpa_removing_emacswiki_packages_they/dtuhzmt/
>
>It's not hard to discover my Lisp libraries.

I haven't find any reference to mouse-3 anywhere and I have been looking
for alternatives like that for months. Actually I tried many of
them...

>It's not hard to use them.  YMMV.
>
It depends of what we understand by hard... but ok.

RE: Changes for emacs 28

[Drew Adams]

> >It's not hard to discover my Lisp libraries.
> 
> I haven't find any reference to mouse-3 anywhere and I have been looking
> for alternatives like that for months. Actually I tried many of
> them...

Googling for the file name finds some, for me.
Of course, if looking for some `mouse-3' context
menu library you won't know the file name.

But even searching just for "emacs mouse-3" finds
the wiki page for it - for me.  But maybe that's
because my use of the search engine knows me. ;-)

---

All of my libraries (though I sometimes forget to
update this page) are listed and described here:

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

But yes, going there assumes you're looking for
one of my libraries, not that you're looking for
a library that shows a `mouse-3' context menu.

> >It's not hard to use them.  YMMV.
>
> It depends of what we understand by hard... but ok.

Yes.

You need to (1) download a library, (2) put it in a
dir that's in your `load-path', then (3) `require' it
in your init file.

Re: Changes for emacs 28

[Richard Stallman]

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

  > I haven't find any reference to mouse-3 anywhere and I have been looking
  > for alternatives like that for months. Actually I tried many of
  > them...

I confused Mouse-3 with C-Mouse-3 in my previous responses.
Please pardon my memory.

I am getting the impression that Emacs differs from "modern" editors
in that they put the menu on Mouse-3 (no Ctrl).  In Emacs,
Mouse-3 is an editing command.

I think we patterned the Emacs bindings of the mouse keys Mouse-1,
Mouse-2 and Mouse-3 after what was the standard in X Windows around
1990.  We could create a global minor mode in which they do
what "modern" editors do -- if that is a well-defined thing.
This would include putting the local menu on Mouse-3 (as well as on C-Mouse-3).

Is that something that new users would make new users much happier?


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

Re: Changes for emacs 28

[Dmitry Gutov]

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

On 11.09.2020 16:23, Ergus wrote:

>> BTW, the Unity DE and Sublime Text editor included an alternative UI 
>> for menus, where you hit a key (Alt, in the case of Unity) and then 
>> fuzzy match on command description.
>>
> Just a question as I don't use sublime anymore. Do you mean something
> like "autohiding" the toolbar or part of it?

I don't have Sublime installed either. Not sure if it was used in 
conjunction with auto-hiding, but the user could probably pref the menu off.

The feature I meant is also present in Atom and VS Code. You can trigger 
it with Ctrl-Shift-P.

Here's a screenshot.

[-- Attachment #2: Screenshot from 2020-09-12 00-06-06.png --]
[-- Type: image/png, Size: 248625 bytes --]

Re: Changes for emacs 28

[Arthur Miller]

Ergus <spacibba@aol.com> writes:

> On Fri, Sep 11, 2020 at 03:50:24PM +0300, Dmitry Gutov wrote:
>>On 11.09.2020 14:00, Arthur Miller wrote:
>>>Dmitry Gutov <dgutov@yandex.ru> writes:
>>>
>>>>On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>>>>>I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>>>>>is that they will never agree to do this.� Menus are not "modern".
>>>>
>>>>That's certainly the current trend in Emacs customizations, but it's not a
>>>>universal rule.
>>>>
>>>>VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
>>>>of course have them too.
>>>When I used to make money by programming VBA with MS Office and C++ with
>>>VStudio I used to turn off all toolbars and menus I could. Back then
>>>computer screens where much smaller then today, and even today I still
>>>fight for vertical screen estate on my computer.
>>
>> I do too. But menus should be helpful for newcomers (and when they are not, we
>> should improve them). So having "starter kits" disable the menus right away
>> seems counter-productive.
>>
>> BTW, the Unity DE and Sublime Text editor included an alternative UI for
>> menus, where you hit a key (Alt, in the case of Unity) and then fuzzy match on
>> command description.
>>
> Just a question as I don't use sublime anymore. Do you mean something
> like "autohiding" the toolbar or part of it?
>
>>>For that reason, on my home computer I run a WM without decorations, Emacs
>>>without any gui elements more then main gui window, Firefox & Gimp with
>>>menus and gui hidden etc. I have never used IntellliJ software, but I
>>>guess they will give you option to maximize the working area by
>>>disabling the gui items too.
>>>
>>>Anyway, I don't think GUI should be disabled by default; that should be left to
>>>the user. I am really curious which distro you run :-)?
>>
>> I use Ubuntu with GNOME and the Unite extension which emulates Unity to the
>> best extent possible. That means removing application title bars when the app
>> is maximized, moving their contents (such as menus) to the top panel when
>> possible.
>>
>>So it's the kind of changes as you did, but to a smaller extent.
>>
> The toolbar is less useful if the right click offers the expected
> options in a panel (copy, paste, cut, select all, upcase, highlight all
> like this, show error at point).
>
> That's why many applications have removed or hided the toolbar; because
> a right click is usually faster than moving the mouse to the top of the
> screen. (they also use the <menu> key to show the right click panel from
> keyboard but we use it for execute-extended-command)
I also agree, some few years ago before I switched to Helm on "full-time
basis" I used context menus a lot. I had menu-bar and tool-bar turned
off and used mouse to switch buffers and so on. Nowadays it is all Helm
for me since it is even faster to fuzzy complete with a shortcut key
than to move hand to the mouse for the context menu.

There is  a commercial package called Maya. They have a pop-up
window/menu widget they call "hot box". In that pop-up they have all, or
as few as chosen by the user, menus collected in a transparent window
they pop-up under the mouse after the spacebar is hold for a while (I
think it was half a second). As info, the application itself could be
called "emacs for 3d modellers"; it is completely scriptable/extensible
(in-house dialect of TCL), all gui elements can be turned off/on etc.
You can see a demo in action:

https://www.youtube.com/watch?v=o2FB6UIK1rc

(sorry for the YT and non-free JS but it is what it is).

Maybe such or similar widget could be good to have in Emacs? As a
compromise between a minimal GUI, discoverability and avialability of
menus even when gui elements are disabled? A context menu would still be
faster though.

RE: Changes for emacs 28

[Drew Adams]

> There is  a commercial package called Maya. They have a pop-up
> window/menu widget they call "hot box". In that pop-up they have all, or
> as few as chosen by the user, menus collected in a transparent window
> they pop-up under the mouse after the spacebar is hold for a while (I
> think it was half a second). 

`mouse3.el' does this.  But it's initiated by
a right-click, not by holding the space bar.

It could be made to also or instead be initiated
by a keyboard key.  But why?  If the location of
the popup is at the mouse pointer, why make users
involve _both_ the mouse and the keyboard?

> Maybe such or similar widget could be good to have in Emacs? As a
> compromise between a minimal GUI, discoverability and avialability of
> menus even when gui elements are disabled? A context menu would still be
> faster though.

See `mouse3.el'.  I think it provides what I
think you've described.

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

https://www.emacswiki.org/emacs/download/mouse3.el

Re: Changes for emacs 28

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11.09.2020 14:00, Arthur Miller wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> On 11.09.2020 00:21, Gregory Heytings via Emacs development discussions. wrote:
>>>> I'm not a maintainer, but FWIW my opinion is that what will most likely happen
>>>> is that they will never agree to do this.  Menus are not "modern".
>>>
>>> That's certainly the current trend in Emacs customizations, but it's not a
>>> universal rule.
>>>
>>> VS Code has a traditional menu. Atom has a menu. Visual Studio and IntelliJ IDEA
>>> of course have them too.
>> When I used to make money by programming VBA with MS Office and C++ with
>> VStudio I used to turn off all toolbars and menus I could. Back then
>> computer screens where much smaller then today, and even today I still
>> fight for vertical screen estate on my computer.
>
> I do too. But menus should be helpful for newcomers (and when they are not, we
> should improve them). So having "starter kits" disable the menus right away
> seems counter-productive.
Yeah I agree; I got it clarified you ment starter kits when you thought
about "distros".

> BTW, the Unity DE and Sublime Text editor included an alternative UI for menus,
> where you hit a key (Alt, in the case of Unity) and then fuzzy match on command
> description.
Ok; I didn't know. I am using Rofi to achieve this in X11/OS and Helm in
Emacs.

>> For that reason, on my home computer I run a WM without decorations, Emacs
>> without any gui elements more then main gui window, Firefox & Gimp with
>> menus and gui hidden etc. I have never used IntellliJ software, but I
>> guess they will give you option to maximize the working area by
>> disabling the gui items too.
>> Anyway, I don't think GUI should be disabled by default; that should be left
>> to
>> the user. I am really curious which distro you run :-)?
>
> I use Ubuntu with GNOME and the Unite extension which emulates Unity to the best
> extent possible. That means removing application title bars when the app is
> maximized, moving their contents (such as menus) to the top panel when possible.
>
> So it's the kind of changes as you did, but to a smaller extent.
I understand; yes it sounds pretty much what I except the top-level bar.
Last time I logged into a Gnome or KDE session was like 4 years agoI
think. Thanks for the answer.

Re: Changes for emacs 28

[Caio Henrique]

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

> It appears that in Emacs we have the extra trouble of menu-bar-mode
> being one of the first things people disable

Yeah, I started using Emacs ~11 months ago. Disabling the menu-bar was
the first thing that I did. I learned how to use Emacs watching these video
tutorials https://www.youtube.com/watch?v=8Zkte37UOnA and on the first 5
minutes he teaches how to disable the menu-bar to make Emacs look more
modern.

As a beginner I loved these video tutorials. He has short videos
that teaches how to install and configure use-package, which-key, then
he shows how to change themes and fonts, then he gives an introduction
to org-mode and teaches how to create a literate emacs configuration
file, then he continues teaching how to install and configure
ido-vertical, avy, rainbow-mode etc...

Because of these video tutorials I never bothered trying Doom or
Spacemacs, I just started creating my own configuration on
vanilla. Besides not using the menu-bar, I also never looked the Emacs
tutorial or the Emacs Guided Tour.

Re: Changes for emacs 28

[Richard Stallman]

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

  > the first thing that I did. I learned how to use Emacs watching these video
  > tutorials https://www.youtube.com/watch?v=8Zkte37UOnA and on the first 5
  > minutes he teaches how to disable the menu-bar to make Emacs look more
  > modern.

Is it the case that you wanted a hamburger key menu?

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

Re: Changes for emacs 28

[Caio Henrique]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > the first thing that I did. I learned how to use Emacs watching these video
>   > tutorials https://www.youtube.com/watch?v=8Zkte37UOnA and on the first 5
>   > minutes he teaches how to disable the menu-bar to make Emacs look more
>   > modern.
>
> Is it the case that you wanted a hamburger key menu?

No, I wanted to just disable both the menu and the toolbar to have a
more minimalist look and save more screen space. But I do think that
regular menus like the one that Emacs has are better than hamburger
button menus, since IMO it is easier to find specific options and
buttons.

Re: Changes for emacs 28

[Richard Stallman]

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

  > There was an idea in another thread that we could ask major distros to
  > not disable menu bar, and I said I could create the issues, but I though
  > I’d wait for some of the maintainers (dis)agree first. What do you
  > think, would such a thing be useful?

I think that would be a good idea.

Another idea: code that runs for beginning users could tell the user,

  To learn what is available in Emacs, we recommend you type
  C-u M-x menu-bar-mode RET
  and then look at all the entries in each menu.

Maybe C-h t could do that.

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

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-11 07:16 +03, Richard Stallman <rms@gnu.org> wrote:
>   > There was an idea in another thread that we could ask major distros to
>   > not disable menu bar, and I said I could create the issues, but I though
>   > I’d wait for some of the maintainers (dis)agree first. What do you
>   > think, would such a thing be useful?
> I think that would be a good idea.

So I just opened three tickets:

https://github.com/syl20bnr/spacemacs/issues/13939
https://github.com/hlissner/doom-emacs/issues/3926
https://github.com/bbatsov/prelude/issues/1278

and contacted Phil Hagelberg, author of better-defaults.el, in private,
because the Github repo was archived and I couldn’t figure out how to
report a bug on his sr.ht repo (looks like the feature is disabled).

If anybody else knows of other prolific distributions, please reply here
and I can add open tickets on their bug trackers too.

> Another idea: code that runs for beginning users could tell the user,
>
>   To learn what is available in Emacs, we recommend you type
>   C-u M-x menu-bar-mode RET
>   and then look at all the entries in each menu.

You mean if menu-bar-mode is disabled?

There is a variety of ideas like this, and they are nice, but IMHO the
social side of this issue is more relevant---why users don’t find and/or
look for all the help and docs bundled with Emacs?---and a social
solution would be of greater use.  E.g. we could prominently feature the
easy availability of extensive docs in Emacs right up top on
<gnu.org/s/emacs>.

If I was to give an Emacs intro class tomorrow to non-programmers, the
very first thing I’d teach, after a very brief description/demo of
Emacs, would be C-h i/f/v/k and how to navigate Info and Help buffers.
That’s because offline documentation is simply _absent_ from most
software people use daily, and many even lack any online
documentation---you’re expected to look at it and /know/.


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

Re: Changes for emacs 28

[Lars Ingebrigtsen]

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

> On 2020-09-11 07:16 +03, Richard Stallman <rms@gnu.org> wrote:
>>   > There was an idea in another thread that we could ask major distros to
>>   > not disable menu bar, and I said I could create the issues, but I though
>>   > I’d wait for some of the maintainers (dis)agree first. What do you
>>   > think, would such a thing be useful?
>> I think that would be a good idea.
>
> So I just opened three tickets:
>
> https://github.com/syl20bnr/spacemacs/issues/13939
> https://github.com/hlissner/doom-emacs/issues/3926
> https://github.com/bbatsov/prelude/issues/1278

For what it's worth, I do not think this is a good idea.  Emacs
distributors should do whatever they think is best, and for emacs-devel
to chide them (even as gently as in these issues) for their decisions is
counter-productive at best.

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

Re: Changes for emacs 28

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> For what it's worth, I do not think this is a good idea.  Emacs
> distributors should do whatever they think is best, and for emacs-devel
> to chide them (even as gently as in these issues) for their decisions is
> counter-productive at best.

Good point.  I never considered that it could be seen as chiding them.
Maybe it was a mistake for me to insist on this idea.

RE: Changes for emacs 28

[Drew Adams]

> If I was to give an Emacs intro class tomorrow to non-programmers, the
> very first thing I’d teach, after a very brief description/demo of
> Emacs, would be C-h i/f/v/k and how to navigate Info and Help buffers.
> That’s because offline documentation is simply _absent_ from most
> software people use daily, and many even lack any online
> documentation---you’re expected to look at it and /know/.

Yes!  Learning to ask Emacs is learning Emacs...

Re: Changes for emacs 28

[Stefan Kangas]

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

> So I just opened three tickets:

Thanks for doing that.

> If anybody else knows of other prolific distributions, please reply here
> and I can add open tickets on their bug trackers too.

There's a list here, but I don't know how complete it is:
https://www.emacswiki.org/emacs/StarterKits

Best regards,
Stefan Kangas

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-11 22:09 +03, Stefan Kangas <stefankangas@gmail.com> wrote:
> Thanks for doing that.

You’re welcome!

> There's a list here, but I don't know how complete it is:
> https://www.emacswiki.org/emacs/StarterKits

Thanks for the link.  I feel like waiting to see how the projects I
contacted behave before contacting others would be a good idea?  Sounds
sensible?

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

Re: Changes for emacs 28

[Stefan Kangas]

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

> Thanks for the link.

Thanks for the work you have done so far.

> I feel like waiting to see how the projects I contacted behave before
> contacting others would be a good idea?  Sounds sensible?

Sounds reasonable.  But given that Lars had some reservations about
doing this at all, perhaps we could just leave it at that.  See his
separate email about this.

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 00:40 +03, Stefan Kangas <stefankangas@gmail.com> wrote:
> Sounds reasonable.  But given that Lars had some reservations about
> doing this at all, perhaps we could just leave it at that.  See his
> separate email about this.

Saw the message, yes, reasonable indeed.  I’ve tried to make it as clear
as possible that it’s just a suggestion for the greater good of the
community, but it coming from a place of ‘authority’, can definitely be
read that way.

IMO, let’s see how upstreams respond, tho.  If it’s positive, we talk
again and /maybe/ continue, if it’s negative, we stop.



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

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Göktuğ Kayaalp <self@gkayaalp.com>
> Cc: Yuri Khan <yuri.v.khan@gmail.com>, drew.adams@oracle.com,
>  self@gkayaalp.com, ghe@sdf.org, casouri@gmail.com, tecosaur@gmail.com,
>  emacs-devel@gnu.org
> Date: Fri, 11 Sep 2020 00:01:29 +0300
> 
> It appears that in Emacs we have the extra trouble of menu-bar-mode
> being one of the first things people disable, and some major ‘distros’
> like Spacemacs seem to disable them by default, so many people never
> even see it.  Also, FWIW, I just noticed the Options menu for the first
> time in my life, after reading Drew’s message, even though the menu bar
> has been sitting there before my eyes for years...
> 
> There was an idea in another thread that we could ask major distros to
> not disable menu bar, and I said I could create the issues, but I though
> I’d wait for some of the maintainers (dis)agree first. What do you
> think, would such a thing be useful?

Disabling the menu bar and the tool bar, let alone doing that by
default, makes very little sense to me.  I'm running with both of them
enable, although I rarely if ever use them.

So yes, please do urge those distros not to disable these UI features.

Thanks.

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 09:01, Eli Zaretskii wrote:
> Disabling the menu bar and the tool bar, let alone doing that by
> default, makes very little sense to me.  I'm running with both of them
> enable, although I rarely if ever use them.

Toolbar takes up space. We also reportedly have less than high quality 
icons in there, on some platforms more than others.

The distros we're talking about usually pride themselves (among other 
things) on "slick" appearance and keyboard-only interaction.

There's a small chance they will enable the menu by default just because 
you asked, but the toolbar is a lost cause.

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

>
> The distros we're talking about usually pride themselves (among other 
> things) on "slick" appearance and keyboard-only interaction.
>
> There's a small chance they will enable the menu by default just because 
> you asked
>

If, and only if, Emacs adapts the appearance of the menu bar to the chosen 
theme.  A boring gray oldish menu bar above a dark mode buffer goes 
against "slick" appearance.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 09:19:03 +0000, Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> said:

    >> 
    >> The distros we're talking about usually pride themselves (among
    >> other things) on "slick" appearance and keyboard-only interaction.
    >> 
    >> There's a small chance they will enable the menu by default just
    >> because you asked
    >> 

    Emacs> If, and only if, Emacs adapts the appearance of the menu bar to the
    Emacs> chosen theme.  A boring gray oldish menu bar above a dark mode buffer
    Emacs> goes against "slick" appearance.

Which build of emacs are you using? Emacs+GTK on Gnu/Linux here
follows the theme set in the desktop environment for menus (the buffer
itself is still white on black, but thatʼs a different discussion).

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
>> If, and only if, Emacs adapts the appearance of the menu bar to the 
>> chosen theme.  A boring gray oldish menu bar above a dark mode buffer 
>> goes against "slick" appearance.
>
> Which build of emacs are you using? Emacs+GTK on Gnu/Linux here follows 
> the theme set in the desktop environment for menus (the buffer itself is 
> still white on black, but thatʼs a different discussion).
>

I did not mean "to the chosen desktop theme" but "to the chosen Emacs 
theme".  IOW, if it were possible for example for Doom Emacs to force the 
menu bar to have white text on a dark gray background.  That might be 
possible in fact, but I don't know how this could be done.  There is a 
`menu' face and a `tool-bar' face, but changing them does not seem to have 
any effect.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 14:10:22 +0000, Gregory Heytings <ghe@sdf.org> said:

    >> Which build of emacs are you using? Emacs+GTK on Gnu/Linux here
    >> follows the theme set in the desktop environment for menus (the
    >> buffer itself is still white on black, but thatʼs a different
    >> discussion).
    >> 

    Gregory> I did not mean "to the chosen desktop theme" but "to the chosen Emacs
    Gregory> theme".  IOW, if it were possible for example for Doom Emacs to force
    Gregory> the menu bar to have white text on a dark gray background.  That might
    Gregory> be possible in fact, but I don't know how this could be done.  There
    Gregory> is a `menu' face and a `tool-bar' face, but changing them does not
    Gregory> seem to have any effect.

I think the answer is going to be 'it depends on the platform and the
toolkit in use'.

Robert

Re: Changes for emacs 28

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11.09.2020 09:01, Eli Zaretskii wrote:
>> Disabling the menu bar and the tool bar, let alone doing that by
>> default, makes very little sense to me.  I'm running with both of them
>> enable, although I rarely if ever use them.
>
> Toolbar takes up space. We also reportedly have less than high quality icons in
> there, on some platforms more than others.
>
> The distros we're talking about usually pride themselves (among other things) on
> "slick" appearance and keyboard-only interaction.
>
> There's a small chance they will enable the menu by default just because you
> asked, but the toolbar is a lost cause.
Which distro does disable menus and toolbars in a text editor by
default? I don't even know of a distro that offers Emacs as a default
text editor. In some distros Emacs is only the "community effort", not
even packaged by distro developers. Anyway, if users choose such a
distro, which is not some of mainstream distros I guess, then they are
probably aware and experienced enough to sort out things for themselves
and enable Emacs gui if they wish, or they should be left to explore it
by themselves.

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-11 13:36 +03, Arthur Miller <arthur.miller@live.com> wrote:
> Which distro does disable menus and toolbars in a text editor by
> default?

We’re talking about some canned configurations of Emacs, not OS
distributions.  Like Spacemacs, Doom Emacs, etc.  Some of these are
called distr{o,ibution}s, some ‘starter kits’.

These are more like Anaconda Python.  But yeah, the terms are a bit
confusing.

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

Re: Changes for emacs 28

[Arthur Miller]

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

> On 2020-09-11 13:36 +03, Arthur Miller <arthur.miller@live.com> wrote:
>> Which distro does disable menus and toolbars in a text editor by
>> default?
>
> We’re talking about some canned configurations of Emacs, not OS
> distributions.  Like Spacemacs, Doom Emacs, etc.  Some of these are
> called distr{o,ibution}s, some ‘starter kits’.
Aha, ok; sorry, yes, I am aware of started kits, just never used any of
those :-). Anyway, I agree they should not disable gui elements by
default, that is definitely best left to the end user.

Re: Changes for emacs 28

[Richard Stallman]

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

  > We’re talking about some canned configurations of Emacs, not OS
  > distributions.  Like Spacemacs, Doom Emacs, etc.  Some of these are
  > called distr{o,ibution}s, some ‘starter kits’.

Please let's NOT use the term "distros" or "distributions" for these!
It is confusing.  Even if some others do use it, let's firmly not
follow them.

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

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 06:21 +03, Richard Stallman <rms@gnu.org> wrote:
> Please let's NOT use the term "distros" or "distributions" for these!
> It is confusing.  Even if some others do use it, let's firmly not
> follow them.

It looks like the term is fairly settled in the community, and what
studying linguistics has tought me is fighting that is an uphill battle,
optimistically speaking.  Not to mention just coining a new term would
only add to the confusion.

There is even a duality of terms: distribution and starter kit.  The
former seems to apply to larger, all encompassing, framework like
constructs, like Spacemacs and Doom; whereas starter kits are more like
nicer defaults and some popular packages, with less intervention as to
how user interacts with Emacs and configures it.


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

Re: Changes for emacs 28

[Richard Stallman]

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

  > > Please let's NOT use the term "distros" or "distributions" for these!
  > > It is confusing.  Even if some others do use it, let's firmly not
  > > follow them.

  > It looks like the term is fairly settled in the community, and what
  > studying linguistics has tought me is fighting that is an uphill battle,
  > optimistically speaking.

They can say what they like, but _here_ please don't use the term
"distributions" except_ for operating system distributions.

We fight many uphill battles, because it is worth the trouble
to advance even if we don't "win" in a permanent sense.

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

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 13:36, Arthur Miller wrote:
> Which distro does disable menus and toolbars in a text editor by
> default? I don't even know of a distro that offers Emacs as a default
> text editor.

This is about "Emacs distros" like Spacemacs, Doom and Prelude.

> In some distros Emacs is only the "community effort", not
> even packaged by distro developers. Anyway, if users choose such a
> distro, which is not some of mainstream distros I guess, then they are
> probably aware and experienced enough to sort out things for themselves
> and enable Emacs gui if they wish, or they should be left to explore it
> by themselves.

I tend to agree. But all popular "Emacs distros" do that. So there's 
really not much alternative for users who would like something different 
than the "vanilla" experience.

RE: Changes for emacs 28

[Drew Adams]

> > Disabling the menu bar and the tool bar, let alone doing that by
> > default, makes very little sense to me.  I'm running with both of them
> > enable, although I rarely if ever use them.
> 
> Toolbar takes up space. We also reportedly have less than high quality
> icons in there, on some platforms more than others.
> 
> The distros we're talking about usually pride themselves (among other
> things) on "slick" appearance and keyboard-only interaction.
> 
> There's a small chance they will enable the menu by default just because
> you asked, but the toolbar is a lost cause.

See my reply about `tool-bar-pop-up-mode'.
Show the tool-bar only when you want, for
one-off uses.

RE: Changes for emacs 28

[Drew Adams]

> > How hard is it to find this submenu?
> >
> > `Options' >
> >     `Show/Hide' >
> >       `Line Numbers for All Lines'
> 
> By CUA, Show/Hide should be a top-level menu named View. 

Really?  Even for setting persistent preferences?
I can imagine using `View' for changing something
for the time being, but not necessarily for
setting preferences (persistent configuration).

`Options' provides both behaviors.

[Some apps have an `Options' menu that stuff for
non-persistent changes and a `Preferences' submenu
for persisitent changes (configuration).]

> Someone who is (subconsciously) familiar with that
> convention will not think to look in Options.

I, like everyone, use lots of apps.  I have no idea
which (if any) follow the CUA convention (nor do I
care).

Some of them have `View' menus (not always top-level).
And some of them have `Preferences' or `Options' menus,
sometimes as a submenu under `File', `Edit', or `Tools'.

Different apps do things differently.  I really
don't think it's hard to find the ability to turn
line-number display on/off, either temporarily or
persistently, even for someone who might be looking
for it under a nonexistent `View' menu.  Do you?

Not difficult, that is, provide the menu-bar is shown.

Re: Changes for emacs 28

[Yuri Khan]

On Fri, 11 Sep 2020 at 01:44, Drew Adams <drew.adams@oracle.com> wrote:

> > By CUA, Show/Hide should be a top-level menu named View.
>
> Really?  Even for setting persistent preferences?
> I can imagine using `View' for changing something
> for the time being, but not necessarily for
> setting preferences (persistent configuration).

Yes. In many applications, View is the place to go if you want to
toggle any optional UI parts (toolbars, sidebars, sometimes menu bar).
These toggles are usually persisted immediately.

It would be nice if the CUA specification was available somewhere on
the Web. Unfortunately, Wikipedia only links to an incomplete Wayback
Machine mirror that does not have the page on the View menu, so I
can’t quote from there.

Re: Changes for emacs 28

[Richard Stallman]

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

  > It would be nice if the CUA specification was available somewhere on
  > the Web. Unfortunately, Wikipedia only links to an incomplete Wayback
  > Machine mirror that does not have the page on the View menu, so I
  > can’t quote from there.

Do any developers these days try to follow the CUA spec?
If so, they must get it from somewhere.

If developers these days don't try to follow it,
why do any users expect us (or anyone) to follow it?


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

Re: Changes for emacs 28

[Yuri Khan]

On Fri, 11 Sep 2020 at 11:16, Richard Stallman <rms@gnu.org> wrote:

>   > It would be nice if the CUA specification was available somewhere on
>   > the Web. Unfortunately, Wikipedia only links to an incomplete Wayback
>   > Machine mirror that does not have the page on the View menu, so I
>   > can’t quote from there.
>
> Do any developers these days try to follow the CUA spec?
> If so, they must get it from somewhere.
>
> If developers these days don't try to follow it,
> why do any users expect us (or anyone) to follow it?

Developers follow the guidelines of their respective GUI toolkit, OS
or desktop environment. Which are many and somewhat diverse, but, in
the end, most of them ultimately descend from CUA.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 11 Sep 2020 02:34:47 +0700
> Cc: Göktuğ Kayaalp <self@gkayaalp.com>,
>  Gregory Heytings <ghe@sdf.org>, Yuan Fu <casouri@gmail.com>,
>  TEC <tecosaur@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, 11 Sep 2020 at 01:44, Drew Adams <drew.adams@oracle.com> wrote:
> 
> > > By CUA, Show/Hide should be a top-level menu named View.
> >
> > Really?  Even for setting persistent preferences?
> > I can imagine using `View' for changing something
> > for the time being, but not necessarily for
> > setting preferences (persistent configuration).
> 
> Yes. In many applications, View is the place to go if you want to
> toggle any optional UI parts (toolbars, sidebars, sometimes menu bar).
> These toggles are usually persisted immediately.
> 
> It would be nice if the CUA specification was available somewhere on
> the Web.

It doesn't really matter, because whatever any specification says, we
don't blindly follow it, we treat such specifications as
recommendations, and fit them to what we think is best for Emacs and
the GNU Project.

(Needless to say, when the current menu arrangement was discussed, we
took into considerations user expectations and what other applications
do with their menus.)

Re: Changes for emacs 28

[Richard Stallman]

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

  > By CUA, Show/Hide should be a top-level menu named View. Someone who
  > is (subconsciously) familiar with that convention will not think to
  > look in Options.

1. The difficulty is that some moides are running out of space in the
menu bar,  Adding a View menu WOULD screw some users.

2. Someone who won't try each menu to see what is in it
seems to be dispose to lose.

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

Re: Changes for emacs 28

[Juri Linkov]

> A Mastodon (or equivalent) instance for Emacs?  A lot of Emacs users
> there already.

I recommend a Pleroma instance: easier to maintain and requires less resources.

> There’s an Emacs client, mastodon.el, which is nice but has some
> polishing to be done.  Haven’t used it much tho.

mastodon.el can be used for Pleroma because Pleroma supports Mastodon API.

Re: Changes for emacs 28

[tomas]

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

On Thu, Sep 10, 2020 at 12:45:18AM +0800, TEC wrote:

[...]

> Vim of course also lacks a splash screen

You never started vim without a file name argument, did you?

;-)

Cheers
 - t

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

Re: Changes for emacs 28

[Howard Melman]

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

TEC <tecosaur@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> - Tried to execute a command interactively (forget which command)
>>>   + Typed M-x
>>>   + Wait, this is just a text box
>>>   + I don't know commands off by heart!
>>>   + I want to be able to type key terms and see options!
>>
>> How much of this would be satisfied by icomplete-mode together with the
>> `substring` completion-style (which would be a smaller change to
>> the UI than something like helm-M-x or counsel-M-x).
>
> I'm frankly not sure. Just trying icomplete now for the first time the
> horizontal display of options seems a bit odd to my sensibilities.

FWIW and for those that might not know, this is how
counsel-M-x looks for me:


[-- Attachment #2: Screen Shot 2020-09-09 at 5.24.08 PM.png --]
[-- Type: image/png, Size: 175014 bytes --]

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


The short description and the keybindings are quite useful.
Even after 30 years of using emacs, there are so many new
packages and features I'm always learning more, and these
help a lot.

I get similar displays using describe-function,
describe-variable, etc.

-- 

Howard

RE: Changes for emacs 28

[Drew Adams]

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

> FWIW ... this is how counsel-M-x looks for me

FWIW, attached is how it looks with Icicles.

First line of current candidate's doc string is shown in
mode line temporarily.  (Hit a key to see its full doc.)

Otherwise, mode-line shows:

* Number of matching candidates (51, in this case).
* Current completion method (vanilla, in this case).
* Current sort order (alphabetical, in this case).

`Icy' lighter in mode-line indicates:

* Must-match completion, not lax (blue bars).
* Case-sensitive completion (`ICY' for insensitive).
* Multi-command (`+'): can act on multiple candidates.

[-- Attachment #2: throw-M-x-find.png --]
[-- Type: image/png, Size: 84920 bytes --]

Re: Changes for emacs 28

[Ricardo Wurmus]

TEC <tecosaur@gmail.com> writes:

> So the 'issue' here isn't a direct "this doesn't look good so I won't
> use this" but a case of association. When I see the vanilla Emacs splash
> screen I'm reminded of the *worst* editors I have experienced, which is
> (as we both know) completely inaccurate, but first impressions are
> coloured by a myriad of factors.
>
> Vim of course also lacks a splash screen, but it's also known as a
> terminal-exclusive editor. I know I tend to set different expectations
> TUIs and GUIs, so I'd imagine I'd find this less of a subconscious
> red-flag.

This is something I have seen in other people who wanted to learn Emacs
after they saw me use it and heard me evangelize… When they get started
with vanilla Emacs they see something that looks like it’s going to be a
lot of work to make it work well for them.

Many of them do know of Vim, if only for the fact that they don’t know
how to exit it.  (They realize then that they also don’t know how to
exit Emacs.)  They remember that Vim requires a lot of work to make it
do things that it doesn’t do out of the box, and they fear they’ll have
to do the same with Emacs.

At that point their initial enthusiasm has all but disappeared and they
glance over to their colleagues who use Rstudio or Atom (in 2017) or
that proprietary editor Sublime.  Everything seems so easy and
approachable and just as extensible.  They see their colleague use Git
from within Rstudio and wonder if they’d ever get to that point if they
will first have to configure Emacs to do all the basic things first.

When I started to use Emacs (after the third serious attempt switching
from vim) I had lots of time on my hands — literally, because I had just
decided to learn touch typing with Dvorak.  Everything was uncomfortable
and new, so the pain of learning Emacs and making Emacs learn about me
disappeared in an ocean of unrelated discomfort.  This situation doesn’t
seem to be very common in those that are curious about Emacs.

-- 
Ricardo

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-10 14:20 +03, Ricardo Wurmus <rekado@elephly.net> wrote:
> At that point their initial enthusiasm has all but disappeared and they
> glance over to their colleagues who use Rstudio or Atom (in 2017) or
> that proprietary editor Sublime.  Everything seems so easy and
> approachable and just as extensible.  They see their colleague use Git
> from within Rstudio and wonder if they’d ever get to that point if they
> will first have to configure Emacs to do all the basic things first.

IMO we should draw a line between attracting users into a detrimental
experience for them and making Emacs more approachable.  Rstudio is a
_great_ fundamental project, and if the rest of my life wasn’t inside
Emacs, I’d be using it these days as I’m studying R.  Org mode is better
than Rmarkdown in certain respects, but if it’s just ‘do statistics in a
nice environment’, I’d definitely recommend Rstudio over Emacs (or
anything else, for that matter).  There’s no way Emacs will ever be as
good at that particular task set, especially if that’s the only task set
one will need it for.

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

Re: Changes for emacs 28

[Ricardo Wurmus]

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

> On 2020-09-10 14:20 +03, Ricardo Wurmus <rekado@elephly.net> wrote:
>> At that point their initial enthusiasm has all but disappeared and they
>> glance over to their colleagues who use Rstudio or Atom (in 2017) or
>> that proprietary editor Sublime.  Everything seems so easy and
>> approachable and just as extensible.  They see their colleague use Git
>> from within Rstudio and wonder if they’d ever get to that point if they
>> will first have to configure Emacs to do all the basic things first.
>
> IMO we should draw a line between attracting users into a detrimental
> experience for them and making Emacs more approachable.  Rstudio is a
> _great_ fundamental project, and if the rest of my life wasn’t inside
> Emacs, I’d be using it these days as I’m studying R.  Org mode is better
> than Rmarkdown in certain respects, but if it’s just ‘do statistics in a
> nice environment’, I’d definitely recommend Rstudio over Emacs (or
> anything else, for that matter).  There’s no way Emacs will ever be as
> good at that particular task set, especially if that’s the only task set
> one will need it for.

In my work environment R is essential, but it’s not nearly the only
thing people have to use regularly.  A lot of work is done in Python and
with Jupyter, and RStudio is almost useless for those tasks.  There’s
also a lot of command line drudgery that could be done more conveniently
with “M-x shell” (editing the output of a tool directly), etc.

So there is a palpable desire for better tools to avoid the constant
context switching, but for every task people end up on the hill of a
local maximum, unable to reach something better (presumably Emacs),
because it doesn’t seem worth the effort to climb that mountain if you
first need to descend into the valley of inscrutable configuration.

-- 
Ricardo

Re: Changes for emacs 28

[Richard Stallman]

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

  > At that point their initial enthusiasm has all but disappeared and they
  > glance over to their colleagues who use Rstudio or Atom (in 2017) or
  > that proprietary editor Sublime.  Everything seems so easy and
  > approachable and just as extensible.  They see their colleague use Git
  > from within Rstudio and wonder if they’d ever get to that point if they
  > will first have to configure Emacs to do all the basic things first.

The tone of that text seems harsh -- it feels like venting hostility.
Would you like to make some constructive suggestions?

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

Re: Changes for emacs 28

[Ricardo Wurmus]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > At that point their initial enthusiasm has all but disappeared and they
>   > glance over to their colleagues who use Rstudio or Atom (in 2017) or
>   > that proprietary editor Sublime.  Everything seems so easy and
>   > approachable and just as extensible.  They see their colleague use Git
>   > from within Rstudio and wonder if they’d ever get to that point if they
>   > will first have to configure Emacs to do all the basic things first.
>
> The tone of that text seems harsh -- it feels like venting hostility.
> Would you like to make some constructive suggestions?

This is certainly not meant to come across as harsh.  It is a
description of what I have observed dozens of times while watching
people who had initial enthusiasm to try out Emacs, only to realize that
it requires much more time to get started than they imagined.  At that
point they have mentally moved on and are already on the lookout for
something else that gets them close to what they had been looking for
initially — even if that falls short of what they could have reached
with Emacs.

I agree with what others have pointed out earlier, namely that a lack of
pre-configuration of features such as automatic completion as you type
and more helpful matching and suggestion of inputs at dreaded empty
prompts would go a long way to reduce what is seen as an intimidating
amount of configuration that users would have to perform for features
that are readily available in most editors and IDEs (and of course
Emacs, once configured).

This drop in initial enthusiasm and motivation is real and closely
linked to defaults.  It is also why I shifted to recommend Spacemacs
(for people familiar with Vim) or Doom Emacs (for all others), because
people can dive right into the interesting stuff without getting bogged
down at the worst time: while learning something that is completely
foreign to them.

-- 
Ricardo

Re: Changes for emacs 28

[TEC]

Hi Ricardo,

In your reply I found something that I think really sums up my experience well.

Ricardo Wurmus <rekado@elephly.net> writes:
> [Doom and Spacemacs are good] because
> people can dive right into the interesting stuff without getting bogged
> down at the worst time: while learning something that is completely
> foreign to them.

For me, and for others, I feel that this is the crux of the matter.
All my comments about Doom's modules allowing me to 'just get started'
are in this vein, as are completion, linting, etc.

I think Emacs is tremendous (no surprise to anyone reading this 😛,
I'm sure). However, I fear that there are many  people who /would/
discover how brilliant Emacs is ... were it not for this initial hurdle.

I think there are essentially three categories of changes we'd likely
want in trying to make Emacs less off-putting:
 1. Look - theme, splash screen, etc.
 2. Feel - completion, linting, etc.
 3. Defaults - changes to functionality already present, e.g. setting
    utf8 at the default text encoding

I hear those long-time users who have years to decades of configuration
built on Emacs' current behaviour, I appreciate your need for Emacs'
behaviour to stay consistent.

I can't see any simple solution which I imagine makes both long-time
users, and 'just seeing what this is' newcomers happy --- but that
doesn't mean there isn't a way forward.

* Some potential avenues to investigate:

The most promising idea I've heard is to come up with a clean, and
elegant way to allow for users to easily select from/combine different
Emacs experiences.

Profiles are a nice idea I think. They sound good for easily selecting
from a selection of 'presets', but perhaps aren't so good when it comes
when use cases blur (as they often do) and one wants to combine
functionality.

Modules are a nicer approach in this respect, in that you partition
common/related functionality into discrete bundles that can be used (or
not) as one wishes.

Another approach may be to essentially delegate this to 'downstream
distributions' like Doom or Spacemacs, by making them trivially easy for
the user to chose to use --- as opposed to having them be something that
the user has to independently discover/investigate/install.

The reason I suggest this is because:
 - a lot of commonly used packages which help shape Emacs into what I
   consider a more approachable UX are only in MELPA
 - these packages seem to generally be frequently updated, and I fear
   that baking them into Emacs will result in a bifurcation of
   versions/features/development. This also opens up the annoyance
   backporting bug fixes etc.

That said, I for some 'key' aspects of functionality like code
completion, I feel that it would make sense to have something like
Company baked into Emacs.

Hopefully this can provide some food for thought,

Timothy.

Re: Changes for emacs 28

[Richard Stallman]

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

  > I think there are essentially three categories of changes we'd likely
  > want in trying to make Emacs less off-putting:
  >  1. Look - theme, splash screen, etc.

How about if you to discuss with some interested people
which specific changes to propose?

  >  2. Feel - completion, linting, etc.

I think that turning some of these things on by default would not annoy
old users who don't want them.  We would only need to disable them once.
As long as disabling them is easy and straightforward, that is.

  >  3. Defaults - changes to functionality already present, e.g. setting
  >     utf8 at the default text encoding

Some of these might be good for everyone.  For those that aren't, I
think it would be enough to provide a function to call to switch to
the old defaults.

  > * Some potential avenues to investigate:

  > The most promising idea I've heard is to come up with a clean, and
  > elegant way to allow for users to easily select from/combine different
  > Emacs experiences.

  > Profiles are a nice idea I think. They sound good for easily selecting
  > from a selection of 'presets', but perhaps aren't so good when it comes
  > when use cases blur (as they often do) and one wants to combine
  > functionality.

Maybe -- but first how about trying the simpler approach described
above, and seeing how far it can go?


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

Re: Changes for emacs 28

[Richard Stallman]

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

  > This is certainly not meant to come across as harsh.

I believe you.  I am sorry if my message sounded like criticism of
you.

                                                          It is a
  > description of what I have observed dozens of times while watching
  > people who had initial enthusiasm to try out Emacs, only to realize that
  > it requires much more time to get started than they imagined.

Now I understand.  There was hostility in those words, but it was not
your hostility.  You were describing the reactions of various others,
and what they were doing was venting their hostility.  You portrayed
that hostility and it came through and hit me in the face.

What you observed is an important fact, and reporting it was
potentially very useful.  But please, in the future, avoid repeating
the actual words with which they express hostility.  That is not the
part that can be helpful for Emacs development.

  > I agree with what others have pointed out earlier, namely that a lack of
  > pre-configuration of features such as automatic completion as you type
  > and more helpful matching and suggestion of inputs at dreaded empty
  > prompts would go a long way to reduce what is seen as an intimidating
  > amount of configuration that users would have to perform for features
  > that are readily available in most editors and IDEs (and of course
  > Emacs, once configured).

I think we're convinced of this, in general.




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

Re: Changes for emacs 28

[Richard Stallman]

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

  > This is a tricky thing. You see, I don't think it's inherently bad.
  > However, for me at least, most of the editors I've used have had a good
  > degree of 'visual polish' and 'modern snazziness' that Vanilla Emacs
  > currently lacks.

I have no idea what looks "good" or "bad" in a splash screen; it never
occurs to me to judge such a question.  Do you have any idea where
to get objective advice about what users will judge as "good"?

It might be easy to implement such advice if we had it.

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

Re: Changes for emacs 28

[Richard Stallman]

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

  > ;; This determines the style of line numbers in effect. If set to `nil', line
  > ;; numbers are disabled. For relative line numbers, set this to `relative'.
  > (setq display-line-numbers-type t)

The default for this should depend on the screen width!

Maybe most young people make wide Emacs frames, since modern laptop
screens are lengthwise and width foolish. but PLEASE do not propose
defaults that cater to ONLY to one kind of usage.  DTRT for multiple
kinds!

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

Re: Changes for emacs 28

[Ergus]

On Wed, Sep 09, 2020 at 12:05:54PM -0400, Stefan Monnier wrote:
>Thanks, TEC, I found it quite useful.  Further comments and questions below.
>
>> * Org-mode, my ramp into Emacs pt.1 - vanilla
>> - I'd heard about Org-mode as a thing markdown + execution
>> - Maybe this could be better than Jupyter?
>> - However... I didn't like Spacemacs
>> - Removed Spacemacs
>> - Typed 'emacs' into a terminal
>
>So far so good.
>
>> - Oh, this looks old.
>
>Fair enough.  I don't think we (Emacs community) are in a position to
>make it look "modern" and sexy.  I know I'm not because my notion of
>"modern and sexy" is quite outmoded ;-)
>
>But "looks old" is usually not a deal breaker, just a negative
>first impression.
>
Actually spacemacs made it to look a bit more modern by just changing
some colors.

>> - Successfully opened a file
>>   + Where are the line numbers?
>
>Interesting.  It would never occur to me to expect line numbers in
>a text editor.  When and why did line numbers become fashionable?
>[ My guess is something like "ever since shortscreens became the only
>  option, creating a void in the horizontal space that needed
>  filling" ;-) ]
>
>I don't oppose enabling line numbers by default, but I do find line
>numbers to be an awful waste of valuable screen real estate.
>
I use line numbers, but instead of enabling them by default we could
make it very very accessible in the toolbar or initial config dialog.

>>   + Why aren't I given much information on the file
>
>Could you be more specific in terms of the particular information that
>you felt Emacs failed to give (and maybe how you expected it to be given)?
>
>>   + Where's the completion, the linting, etc.
>
>Do I understand you right that you expected company+eglot+flymake to be
>enabled (and configured) by default?
>
>I personally find this to be the most glaring concrete problem in
>Emacs nowadays.
>
Again we just don't need to enable them by default, but just make them
easier to config. I still find myself in the dichotomy between company
or auto-complete modes after 6 years in emacs.

flymake is good enough, but not very easy to find on the beginning, and
it still requires a lot of work. Also most of the documentation around
recommends using flycheck and actually for me it works much better in
most of the situations and languages I use.

>> - Tried to execute a command interactively (forget which command)
>>   + Typed M-x
>>   + Wait, this is just a text box
>>   + I don't know commands off by heart!
>>   + I want to be able to type key terms and see options!
>
>How much of this would be satisfied by icomplete-mode together with the
>`substring` completion-style (which would be a smaller change to
>the UI than something like helm-M-x or counsel-M-x).
>
Yes please.. If you think that icomplete/fido-mode can be improved
somehow, just make specific requests.

>> - Having an initialisation† file, well commented such that *without knowing
>>   anything about Emacs* I could have Emacs be set up such that I could
>>   actually try it with familiar tasks and not be underwhelmed, or have
>>   to deal with sudden troubleshooting
>
>Maybe we could have a "default init file" (consisting of nothing but
>commented out code snippets, accompanied by actual comments explaining
>them)?
>
This is why I have been asking for use-package integration. As a
starting point this is the easier we can provide to starters to
find/know about the different options and modes.

>>   †The important bit about this file is that it let me declare which
>>   bundles of functionality I want easily, and without having to parse
>>   much unfamiliar lisp (both Spacemacs and Vanilla fail in this regard,
>>   but in different ways).
>
>Hmm... a "default init file" would still use "unfamiliar Lisp", I'm afraid.
>
with use-packages the lisp knowledge needed to configure is
minimal. Just to understand (this detail)

>> - Having good 'discoverability enhancements' used by default
>>   - counsel for M-x
>
>IIUC this is similar to enabling icomplete-vertical and
>icomplete-show-matches-on-no-input, and maybe using a regexp
>completion style?
>
There is not icomplete-vertical yet ;).

Any way icomplete is too far to compete with counsel/ivy/swiper in
functionality and termination level.  (at the moment icomplete is Donald
Duck and counsel is James Bond).

I don't ask to add counsel to vanilla because it requires many external
optional dependencies that I would never like to see in vanilla and
retards the startup time.

>> - Used Discord for it's community, a recent chat-app which I recognised
>>   (I'm still warming up to mailing lists).
>
>Definitely a non-starter since it's proprietary.
>There are obviously acceptable alternatives.
>
>I think an important aspect is to find a communication medium that can
>be used from Emacs.  IRC and Email do satisfy this criteria.
>Whenever I have to write text outside Emacs I feel hampered.
>
>
Emacs has even a telegram client, jabber client, and IRC... so of course
any method we use to communicate must have an emacs client, a web or
desktop client and a mobile client.



>        Stefan
>
>

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

Ergus:
>
> There is not icomplete-vertical yet ;).
>

Of course there is: https://github.com/oantolin/icomplete-vertical .

Re: Changes for emacs 28

[Ergus]

On Wed, Sep 09, 2020 at 05:08:05PM +0000, Gregory Heytings via Emacs development discussions. wrote:
>
>Ergus:
>>
>>There is not icomplete-vertical yet ;).
>>
>
>Of course there is: https://github.com/oantolin/icomplete-vertical .
>

That's an external package not even in elpa and it has some issues. We
have been talking to add it to internal icomplete and finally there is a
feature branch with the WIP.

RE: Changes for emacs 28

[Drew Adams]

> I use line numbers, but instead of enabling them by default we could
> make it very very accessible in the toolbar or initial config dialog.

Menu Options >
  Show/Hide >
    Line Numbers for All Lines (submenu)

(And yes, the menu-bar needs to be shown initially,
i.e., by default.)

> with use-packages the lisp knowledge needed to configure
> is minimal. Just to understand (this detail)

Maybe so, but I see _lots_ of questions posted that
come from not understanding the syntax, or rather
the behavior of certain bits of the syntax.

Some of that is not understanding Lisp, I think.
Most of it is not, perhaps.

Re: Changes for emacs 28

[Caio Henrique]

>I use line numbers, but instead of enabling them by default we could
>make it very very accessible in the toolbar or initial config dialog.
On the menu-bar, one can go into [Options] -> [Show/Hide] -> [Line numbers
for all lines].

Related to this: I can't find where is redo (undo-redo) on the
menu-bar, so I suppose that it isn't there. Maybe it should be included?
(I'm not sure how useful it is since I use undo-tree).


Caio Henrique

"modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   >Fair enough.  I don't think we (Emacs community) are in a position to
   >make it look "modern" and sexy.  I know I'm not because my notion of
   >"modern and sexy" is quite outmoded ;-)
   >
   >But "looks old" is usually not a deal breaker, just a negative
   >first impression.

   Actually spacemacs made it to look a bit more modern by just changing
   some colors.

What kind of changes to colors was that?  It would be good to quantify
what "modern" means.

   >Whenever I have to write text outside Emacs I feel hampered.

   Emacs has even a telegram client, jabber client, and IRC... so of course
   any method we use to communicate must have an emacs client, a web or
   desktop client and a mobile client.

Only as long as those protocols/systems do not require or recommend
non-free software.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Thu, Sep 10, 2020 at 05:09:49AM -0400, Alfred M. Szmidt wrote:
>   >Fair enough.  I don't think we (Emacs community) are in a position to
>   >make it look "modern" and sexy.  I know I'm not because my notion of
>   >"modern and sexy" is quite outmoded ;-)
>   >
>   >But "looks old" is usually not a deal breaker, just a negative
>   >first impression.
>
>   Actually spacemacs made it to look a bit more modern by just changing
>   some colors.
>
>What kind of changes to colors was that?  It would be good to quantify
>what "modern" means.
>
In general this is very subjective. But looking at WinXP vs Win10 one
gets more or less where the style feeling is moving to. Specially the
colors and the default fonts in the interfaces make a big difference;
but also the whole integration.

>   >Whenever I have to write text outside Emacs I feel hampered.
>
>   Emacs has even a telegram client, jabber client, and IRC... so of course
>   any method we use to communicate must have an emacs client, a web or
>   desktop client and a mobile client.
>
>Only as long as those protocols/systems do not require or recommend
>non-free software.
>
I just mentioned those as examples of how software communities interact
these days. But of course emacs has special requirements.

In particular I would recommend to give a look to a self-hosted
Mattermost or Matrix.org or Zulip. So far the only missing for the
moment is the emacs client, but apis are available.

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   >   Actually spacemacs made it to look a bit more modern by just changing
   >   some colors.
   >
   >What kind of changes to colors was that?  It would be good to quantify
   >what "modern" means.

   In general this is very subjective. But looking at WinXP vs Win10 one
   gets more or less where the style feeling is moving to. Specially the
   colors and the default fonts in the interfaces make a big difference;
   but also the whole integration.

Could you list those changes?  Changing the font to another default,
or some minor tweaks to the default color theme sounds like very low
hanging fruit that shouldn't be to difficult of a change to get
through.

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: ams@gnu.org (Alfred M. Szmidt)
> Date: Thu, 10 Sep 2020 06:29:18 -0400
> Cc: ghe@sdf.org, casouri@gmail.com, tecosaur@gmail.com,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Could you list those changes?  Changing the font to another default,
> or some minor tweaks to the default color theme sounds like very low
> hanging fruit that shouldn't be to difficult of a change to get
> through.

AFAIK, we generally use the defaults of each toolkit, so most of the
changes being implied here are automatically followed as the
underlying OS and the toolkits evolve.

Or maybe I don't understand well enough what changes are being alluded
to here.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Thu, Sep 10, 2020 at 06:29:18AM -0400, Alfred M. Szmidt wrote:
>   >   Actually spacemacs made it to look a bit more modern by just changing
>   >   some colors.
>   >
>   >What kind of changes to colors was that?  It would be good to quantify
>   >what "modern" means.
>
>   In general this is very subjective. But looking at WinXP vs Win10 one
>   gets more or less where the style feeling is moving to. Specially the
>   colors and the default fonts in the interfaces make a big difference;
>   but also the whole integration.
>
>Could you list those changes?

1) The "included" themes (not only the default one) are a bit more
"attractive" and similar to the ones in VSCode, Sublime or Android
Studio:

https://themegallery.robdor.com/

2) In the windows side they just made the whole colors a bit more
"coherent" with the internal themes,

2.1) the menu-bar is usually more "compact" with a smaller and bold font
(OR hided OR enabled xterm-mouse-mode because otherwise the toolbar is
pretty much useless as F10 is intercepted by most of the terminal
emulators or desktop environments).

2.2) In the case where they keep the tool-bar the icons are smaller and
more "attractive". Lets say sometimes independent of the theme, but in
general smaller.

3) Finally they fully redesigned the mode-line. I don't like all the
changes they did because they require many extra external packages that
increase too much the loading time and I prefer to load my emacs in less
than 1 sec. But form the aestetic point of view it is an important
change.

>Changing the font to another default,
>or some minor tweaks to the default color theme sounds like very low
>hanging fruit that shouldn't be to difficult of a change to get
>through.
>
I know some of these modifications are dependent of time. So they will
be updated because preferences changes on time. But in general giving a
set of full coherent themes with icons/colors/fonts is everything we need.

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Thu, 10 Sep 2020 13:08:32 +0200
> From: Ergus <spacibba@aol.com>
> Cc: ghe@sdf.org, casouri@gmail.com, tecosaur@gmail.com,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> 2.1) the menu-bar is usually more "compact" with a smaller and bold font

In most builds, the font of the menu bar comes from the toolkit,
doesn't it?

> (OR hided OR enabled xterm-mouse-mode because otherwise the toolbar is
> pretty much useless as F10 is intercepted by most of the terminal
> emulators or desktop environments).

If F10 is intercepted, perhaps we should also bind the command to
another key?  That's a simple and backward-compatible change.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Thu, Sep 10, 2020 at 03:32:21PM +0300, Eli Zaretskii wrote:
>> Date: Thu, 10 Sep 2020 13:08:32 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: ghe@sdf.org, casouri@gmail.com, tecosaur@gmail.com,
>>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
>> 2.1) the menu-bar is usually more "compact" with a smaller and bold font
>
>In most builds, the font of the menu bar comes from the toolkit,
>doesn't it?
>
>> (OR hided OR enabled xterm-mouse-mode because otherwise the toolbar is
>> pretty much useless as F10 is intercepted by most of the terminal
>> emulators or desktop environments).
>
>If F10 is intercepted, perhaps we should also bind the command to
>another key?  That's a simple and backward-compatible change.
>
I have discussed this with Stefan already and there are some small
backward compatible changes we can do here because usually F10 is
intercepted by gnome, toggle guake, gnome-terminal menu or tmux before
arriving to emacs.

Some of the (non exclusive) options are: 

1) Bind it also to another key

2) Show the binding somewhere (in the same bar or modeline) when
xterm-mouse-mode is disabled.

3) Underline the letter in the menus that "opens" each menu from the
keyboard (as some Windows applications do)

4) Enable xterm-mouse-mode by default in more situations as most of the
popular terminal emulators are xterm compatible (gnome-term, xterm,
konsole, rxvt, guake, terminator)

Re: "modern" colors Re: Changes for emacs 28

[Yuri Khan]

On Thu, 10 Sep 2020 at 20:22, Ergus <spacibba@aol.com> wrote:

> >> (OR hided OR enabled xterm-mouse-mode because otherwise the toolbar is
> >> pretty much useless as F10 is intercepted by most of the terminal
> >> emulators or desktop environments).
> >
> >If F10 is intercepted, perhaps we should also bind the command to
> >another key?  That's a simple and backward-compatible change.
> >
> I have discussed this with Stefan already and there are some small
> backward compatible changes we can do here because usually F10 is
> intercepted by gnome, toggle guake, gnome-terminal menu or tmux before
> arriving to emacs.

Most GUI terminal emulators have a preference option to refrain from
squatting important key combinations (F1, F10, Alt+F, Alt+E, …) for
their own UI and pass them to the application running within, although
that runs against keyboard accessibility of the terminal emulator.

Some in-terminal applications also have provisions that let them run
on terminals without function keys. For example, Midnight Commander
accepts ESC 1, …, ESC 0 (and thus also M-1, …, M-0) as equivalents of
F1..F10. Emacs could not adopt the same workaround though, because of
universal numeric argument.

(Also for historical reasons Midnight Commander opens its menu bar on
F9, not F10. F10 is Quit. This is because the MC descends in spirit
from Norton Commander whose keybindings were established way before
CUA.)

> 3) Underline the letter in the menus that "opens" each menu from the
> keyboard (as some Windows applications do)

Windows applications (and applications on other GUI toolkits that use
mnemonics) open those menus when those letters are pressed with the
Alt modifier. Emacs mostly cannot do that because Alt+F is M-f is
forward-word. In Emacs-GTK you can choose a different modifier key for
Meta, but in terminal I’m not sure.

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Thu, 10 Sep 2020 15:17:54 +0200
> From: Ergus <spacibba@aol.com>
> Cc: casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org,
> 	monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
> 
> >If F10 is intercepted, perhaps we should also bind the command to
> >another key?  That's a simple and backward-compatible change.
> >
> I have discussed this with Stefan already and there are some small
> backward compatible changes we can do here because usually F10 is
> intercepted by gnome, toggle guake, gnome-terminal menu or tmux before
> arriving to emacs.
> 
> Some of the (non exclusive) options are: 
> 
> 1) Bind it also to another key

This is what I had in mind.

> 2) Show the binding somewhere (in the same bar or modeline) when
> xterm-mouse-mode is disabled.

I don't see how xterm-mouse-mode is relevant: we are not talking about
the mouse, and TTY menus work without a mouse as well.

> 3) Underline the letter in the menus that "opens" each menu from the
> keyboard (as some Windows applications do)

How will that help?

> 4) Enable xterm-mouse-mode by default in more situations as most of the
> popular terminal emulators are xterm compatible (gnome-term, xterm,
> konsole, rxvt, guake, terminator)

Again, xterm-mouse-mode is an orthogonal issue.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Thu, Sep 10, 2020 at 05:41:58PM +0300, Eli Zaretskii wrote:
>> Date: Thu, 10 Sep 2020 15:17:54 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org,
>> 	monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
>>
>> >If F10 is intercepted, perhaps we should also bind the command to
>> >another key?  That's a simple and backward-compatible change.
>> >
>> I have discussed this with Stefan already and there are some small
>> backward compatible changes we can do here because usually F10 is
>> intercepted by gnome, toggle guake, gnome-terminal menu or tmux before
>> arriving to emacs.
>>
>> Some of the (non exclusive) options are:
>>
>> 1) Bind it also to another key
>
>This is what I had in mind.
>
Of course, this is the first to do in any case. Do you have any binding
in mind?

>> 2) Show the binding somewhere (in the same bar or modeline) when
>> xterm-mouse-mode is disabled.
>
>I don't see how xterm-mouse-mode is relevant: we are not talking about
>the mouse, and TTY menus work without a mouse as well.
>
Ex: in gnome-terminal (which captures the F10) and with xterm-mouse-mode
disabled it is almost impossible to access the menu (unless throw
M-x but then the user can type the commands without needing the
menubar).

So it is there basically stilling space because there is no way to
access it.

>> 3) Underline the letter in the menus that "opens" each menu from the
>> keyboard (as some Windows applications do)
>
>How will that help?
>
With a disabled xterm-mouse-mode a first timer user doesn't know how to
open the menu-bar, even its name. It will be specially useful to give
some hints.

Menubar is specially useful for beginners; lets say the fist step to
start doing the basics. Being inaccessible gives the same experience
than a first time user trying to exit vim.

>> 4) Enable xterm-mouse-mode by default in more situations as most of the
>> popular terminal emulators are xterm compatible (gnome-term, xterm,
>> konsole, rxvt, guake, terminator)
>
>Again, xterm-mouse-mode is an orthogonal issue.

I know. This were general points we mentioned about why some people
found useless the menubar and used to remove it.

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Thu, 10 Sep 2020 20:40:11 +0200
> From: Ergus <spacibba@aol.com>
> Cc: casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org,
> 	monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
> 
> >> 1) Bind it also to another key
> >
> >This is what I had in mind.
> >
> Of course, this is the first to do in any case. Do you have any binding
> in mind?

Not in particular.  I think we should see what other keys customary
open menus in applications that don't want to use F10.

> >> 2) Show the binding somewhere (in the same bar or modeline) when
> >> xterm-mouse-mode is disabled.
> >
> >I don't see how xterm-mouse-mode is relevant: we are not talking about
> >the mouse, and TTY menus work without a mouse as well.
> >
> Ex: in gnome-terminal (which captures the F10) and with xterm-mouse-mode
> disabled it is almost impossible to access the menu (unless throw
> M-x but then the user can type the commands without needing the
> menubar).

You can open the menu. and then navigate it.  That the command which
opens the menu is invoked through M-x doesn't yet mean the rest of the
navigation is useless: the user can learn how to open the menu (a
single command), but still find the rest of the commands via the
menus, thus avoiding the need to know which commands they invoke.

> >> 3) Underline the letter in the menus that "opens" each menu from the
> >> keyboard (as some Windows applications do)
> >
> >How will that help?
> >
> With a disabled xterm-mouse-mode a first timer user doesn't know how to
> open the menu-bar, even its name. It will be specially useful to give
> some hints.

I disagree.  Once upon a time F10 was the universally accepted way.
If nowadays it is another key, or a group of other keys, we could
still provide menus that don't need a mouse.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

>
>I disagree.  Once upon a time F10 was the universally accepted way.

But everybody wanted to provide a menu and everybody bind it to
F10 increasing the probability that someone intercepts it before
arriving to emacs.

>If nowadays it is another key, or a group of other keys, we could
>still provide menus that don't need a mouse.

Ok

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   >   >   Actually spacemacs made it to look a bit more modern by just changing
   >   >   some colors.
   >   >
   >   >What kind of changes to colors was that?  It would be good to quantify
   >   >what "modern" means.
   >
   >   In general this is very subjective. But looking at WinXP vs Win10 one
   >   gets more or less where the style feeling is moving to. Specially the
   >   colors and the default fonts in the interfaces make a big difference;
   >   but also the whole integration.
   >
   >Could you list those changes?

   1) The "included" themes (not only the default one) are a bit more
   "attractive" and similar to the ones in VSCode, Sublime or Android
   Studio:

   https://themegallery.robdor.com/

That lists several hundreds of themes.  Can you summarize _what_
changes where done to make Emacs look more modern?  A list of maybe
3-5 things would give a good idea.  For example, one concrete change
is to replace a warning face that is bright yellow with a dark yellow.

   2) In the windows side they just made the whole colors a bit more
   "coherent" with the internal themes,

What does that mean? What changes did they (who is they?) do exactly?

   2.1) the menu-bar is usually more "compact" with a smaller and bold font
   (OR hided OR enabled xterm-mouse-mode because otherwise the toolbar is
   pretty much useless as F10 is intercepted by most of the terminal
   emulators or desktop environments).


   2.2) In the case where they keep the tool-bar the icons are smaller and
   more "attractive". Lets say sometimes independent of the theme, but in
   general smaller.

How are the more attractive?  The list you provided doesn't show a
single tool-bar.

   3) Finally they fully redesigned the mode-line. I don't like all the
   changes they did because they require many extra external packages that
   increase too much the loading time and I prefer to load my emacs in less
   than 1 sec. But form the aestetic point of view it is an important
   change.

In what way have the "fully redesigned the mode-line"? The link you
provided has no mode-lines.  

Please be specific, give examples -- "it is more attractive" without
explicilty saying what "it" is makes for a long discussion.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 09:15:40AM -0400, Alfred M. Szmidt wrote:
>   >   >   Actually spacemacs made it to look a bit more modern by just changing
>   >   >   some colors.
>   >   >
>   >   >What kind of changes to colors was that?  It would be good to quantify
>   >   >what "modern" means.
>   >
>   >   In general this is very subjective. But looking at WinXP vs Win10 one
>   >   gets more or less where the style feeling is moving to. Specially the
>   >   colors and the default fonts in the interfaces make a big difference;
>   >   but also the whole integration.
>   >
>   >Could you list those changes?
>
>   1) The "included" themes (not only the default one) are a bit more
>   "attractive" and similar to the ones in VSCode, Sublime or Android
>   Studio:
>
>   https://themegallery.robdor.com/
>
>That lists several hundreds of themes.  Can you summarize _what_
>changes where done to make Emacs look more modern?  A list of maybe
>3-5 things would give a good idea.  For example, one concrete change
>is to replace a warning face that is bright yellow with a dark yellow.
>
If you change a single face it doesn't improve anything. The whole thing
is the important. The overall result after all the changes. A light
toolbar looks worst with a dark background as well; big icons looks
terrible with small fonts.

>   2) In the windows side they just made the whole colors a bit more
>   "coherent" with the internal themes,
>
>What does that mean? What changes did they (who is they?) do exactly?
>
If you change the background but not the borders, the icons the
font-lock faces, modeline and so on; a single change conflicts with the
others. I am not designer to quantify that with designer words.

>   2.1) the menu-bar is usually more "compact" with a smaller and bold font
>   (OR hided OR enabled xterm-mouse-mode because otherwise the toolbar is
>   pretty much useless as F10 is intercepted by most of the terminal
>   emulators or desktop environments).
>
>
>   2.2) In the case where they keep the tool-bar the icons are smaller and
>   more "attractive". Lets say sometimes independent of the theme, but in
>   general smaller.
>
>How are the more attractive?  The list you provided doesn't show a
>single tool-bar.
>
>   3) Finally they fully redesigned the mode-line. I don't like all the
>   changes they did because they require many extra external packages that
>   increase too much the loading time and I prefer to load my emacs in less
>   than 1 sec. But form the aestetic point of view it is an important
>   change.
>
>In what way have the "fully redesigned the mode-line"? The link you
>provided has no mode-lines.
>
https://github.com/jonathanchu/emacs-powerline
https://github.com/TheBB/spaceline
https://github.com/domtronn/spaceline-all-the-icons.el
https://seagle0128.github.io/doom-modeline
https://www.spacemacs.org/ (there are pictures)

>Please be specific, give examples -- "it is more attractive" without
>explicilty saying what "it" is makes for a long discussion.
>

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   On Fri, Sep 11, 2020 at 09:15:40AM -0400, Alfred M. Szmidt wrote:
   >   >   >   Actually spacemacs made it to look a bit more modern by just changing
   >   >   >   some colors.
   >   >   >
   >   >   >What kind of changes to colors was that?  It would be good to quantify
   >   >   >what "modern" means.
   >   >
   >   >   In general this is very subjective. But looking at WinXP vs Win10 one
   >   >   gets more or less where the style feeling is moving to. Specially the
   >   >   colors and the default fonts in the interfaces make a big difference;
   >   >   but also the whole integration.
   >   >
   >   >Could you list those changes?
   >
   >   1) The "included" themes (not only the default one) are a bit more
   >   "attractive" and similar to the ones in VSCode, Sublime or Android
   >   Studio:
   >
   >   https://themegallery.robdor.com/
   >
   >That lists several hundreds of themes.  Can you summarize _what_
   >changes where done to make Emacs look more modern?  A list of maybe
   >3-5 things would give a good idea.  For example, one concrete change
   >is to replace a warning face that is bright yellow with a dark yellow.
   >
   If you change a single face it doesn't improve anything. The whole thing
   is the important. The overall result after all the changes. A light
   toolbar looks worst with a dark background as well; big icons looks
   terrible with small fonts.

I realise that, but could you give concrete changs that were made?  It
seemed that it was relativley small changes (some color changes that
made emacs modern), so what changes are you talking about exactly?

The default spaceemacs link shows a black background, is that it?  I
don't see anything that is very different with regard to fonts, and
colors.  Can you point those changes out?

   https://github.com/jonathanchu/emacs-powerline
   https://github.com/TheBB/spaceline
   https://github.com/domtronn/spaceline-all-the-icons.el
   https://seagle0128.github.io/doom-modeline
   https://www.spacemacs.org/ (there are pictures)

There are loads of random changes there to the default Emacs, I do not
know which one you are refering to.  What am I supposed to look at?

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

> If you change a single face it doesn't improve anything. The whole thing
> is the important. The overall result after all the changes. A light
> toolbar looks worst with a dark background as well; big icons looks
> terrible with small fonts.

I personally have no idea what "modern" looks like or what makes
something look "modern", so I'd welcome a description.  Showing me
examples doesn't really help me.  By description I don't mean "change
this one face to foo", but rather the underlying ideas behind the
various changes.


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Iñigo Serna]

On 11 September 2020 at 16:23 +02, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I personally have no idea what "modern" looks like or what makes
> something look "modern", so I'd welcome a description.

IMO, Po Lu's work (already presented here [1]) would be a good example
at nice "modern" integration with linux computers using any gtk-based desktop.

Of course, it's no finished and possibly needs some work, but I think
this, plus wayland compatiblity and, maybe, some minor additions like
all-the-icons functionality would offer a quite "modern" aesthetic
experience.


Best regards,
Iñigo

[1] https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01901.html

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 10:23:19AM -0400, Stefan Monnier wrote:
>> If you change a single face it doesn't improve anything. The whole thing
>> is the important. The overall result after all the changes. A light
>> toolbar looks worst with a dark background as well; big icons looks
>> terrible with small fonts.
>
>I personally have no idea what "modern" looks like or what makes
>something look "modern", so I'd welcome a description.  Showing me
>examples doesn't really help me.  By description I don't mean "change
>this one face to foo", but rather the underlying ideas behind the
>various changes.
>
>
>        Stefan
>
I will try my best but my terminology could be totally wrong (worst than
my English). (Note that I only use emacs from the terminal anyway)

1) The toolbar: Some applications don't use them anymore as they have a
full panel on right click and the hamburger icon like the browsers.

1.1) Using system icons generally has not so good effect either; because
gnome themes are not good in general by default (except ubuntu and some
others who changed them). Some applications bring their own icons just
to look better OOTB (not telling we should do the same)

OTOH Plasma (KDE) has better icons; but all the environment is now a bit
darker, so emacs looks like something not really fixing there (too
light).

2) Modeline: Our modeline is a kind of relic from other times. With the
same gray color in the terminal and some cryptic information. It also
shows the line but not the column by default and the file status is
somehow in that cryptic initial part I don't think many users understand
very well.

Just adding an * to the filename in modeline (and or tab when using
them) or changing the color is easier to understand. Than -UUU:----F1

You can see all the popular alternatives around.

3) Colors: People prefer higher contrast in general 4 example: in my
system when the region es enabled the default gray color is so light
that I can't see it. Same applies to icon that when enabled or disabled
the difference sometimes is minimal.

Usually blues and green are more attractive to users (that's why MS
decided to use them for their OS). PANTONE448C (a kind of yellow + grey)
is considered the ugliest color ever and our UI and fonts are mostly
grey and yellow-orange.

There has been a long discussion these days about light vs dark
themes... But as you can see all the applications are implementing a
dark mode and people prefer dark today (maybe tomorrow this changes)

4) Right click: (Probably it is the most lacking functionality and
surprising for any user not using the terminal.) Right click is expected
to bring a panel with the most common operations. It is useful, fast
and somehow standard since 1995 while removing most of the needs of the
toolbar which takes precious vertical space.

Extra ide features (we already have but hidden) and are in some editors
around bu default (again I'm not telling we should do the same):

5) sidebar: most code editors have a button somewhere in the interface
to show/hide the sidebar to explore and open files/access symbols or see
open files. That bottom is usually in what we we call modeline or it is
a tight bar on the lest to toggle it on and off quickly. (You find them
in atom, sublime, geany, clion, VSCode). That's why in emacs it is
becoming more and more popular things like neotree.

6) fill-column-indicator, indent-column-indicator,
highlight-all-like-this on mouse double click and idle,
show-parent-mode, show-trailing-whitespaces.

Hope this can help

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 00:14:35 +0200
> From: Ergus <spacibba@aol.com>
> Cc: ghe@sdf.org, "Alfred M. Szmidt" <ams@gnu.org>, tecosaur@gmail.com,
>  casouri@gmail.com, emacs-devel@gnu.org
> 
> 4) Right click: (Probably it is the most lacking functionality and
> surprising for any user not using the terminal.) Right click is expected
> to bring a panel with the most common operations. It is useful, fast
> and somehow standard since 1995 while removing most of the needs of the
> toolbar which takes precious vertical space.

We have this on C-mouse-2 and C-mouse-3.  Putting those on mouse-2 and
mouse-3 would fly in the face of pasting text from the window-system
selection, which is something a text editor cannot possibly disable by
default.  Unless we are willing to abandon support for selections,
that is (which I guess what the "modern" editors did?).

> 5) sidebar: most code editors have a button somewhere in the interface
> to show/hide the sidebar to explore and open files/access symbols or see
> open files.

We have it in Options->Hide/Show.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

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



On September 12, 2020 8:25:41 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 12 Sep 2020 00:14:35 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: ghe@sdf.org, "Alfred M. Szmidt" <ams@gnu.org>,
>tecosaur@gmail.com,
>>  casouri@gmail.com, emacs-devel@gnu.org
>> 
>> 4) Right click: (Probably it is the most lacking functionality and
>> surprising for any user not using the terminal.) Right click is
>expected
>> to bring a panel with the most common operations. It is useful, fast
>> and somehow standard since 1995 while removing most of the needs of
>the
>> toolbar which takes precious vertical space.
>
>We have this on C-mouse-2 and C-mouse-3.  Putting those on mouse-2 and

The menu we have in C-mouse-3 does not show the most basic options like copy, paste, and so on to access them fast. We have there a set of maybe more advanced options; but not the basics, so that menu is less useful in general and its use is very poor in our days. BTW, xterm intercepts C-mouse-3 but not mouse-3.

Mouse-2 so far is used to paste or not used at all in the other editors... So we shouldn't touch that

>mouse-3 would fly in the face of pasting text from the window-system
>selection, which is something a text editor cannot possibly disable by
>default.  Unless we are willing to abandon support for selections,
>that is (which I guess what the "modern" editors did?).
>
I think that modern editors removed that indeed and only use the clipboard. I am not saying to go or not in that direction and rebind everything; but at least add a more useful set of options to the panel could help. 

>> 5) sidebar: most code editors have a button somewhere in the
>interface
>> to show/hide the sidebar to explore and open files/access symbols or
>see
>> open files.
>
>We have it in Options->Hide/Show.

Yes but the idea behind is to make it very accessible to toggle it on demand more frequently. Maybe we can add a bottom for that [>>] in the beginning of the modeline to give a toggle effect?

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

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

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 11:03:33 +0200
> CC: casouri@gmail.com,ams@gnu.org,monnier@iro.umontreal.ca,ghe@sdf.org,tecosaur@gmail.com
> From: Ergus <spacibba@aol.com>
> 
> >> 4) Right click: (Probably it is the most lacking functionality and
> >> surprising for any user not using the terminal.) Right click is
> >expected
> >> to bring a panel with the most common operations. It is useful, fast
> >> and somehow standard since 1995 while removing most of the needs of
> >the
> >> toolbar which takes precious vertical space.
> >
> >We have this on C-mouse-2 and C-mouse-3. Putting those on mouse-2 and
> 
> The menu we have in C-mouse-3 does not show the most basic options like copy, paste, and so on to
> access them fast.

Why should it?  We show the menu for the current major mode, which is
IMO more useful than basic editing.

It's a pity too many newbies don't see the menu bar and the tool bar,
because all this was arranged to have all the important features be
readily available through the different UI elements.  With the menu
and the tool bar removed, we don't have enough UI elements to satisfy
all the important needs.  Which is one more reason to encourage
newbies to start with the vanilla Emacs, not with the hyper-loaded
"distros".

> >> 5) sidebar: most code editors have a button somewhere in the
> >interface
> >> to show/hide the sidebar to explore and open files/access symbols or
> >see
> >> open files.
> >
> >We have it in Options->Hide/Show.
> 
> Yes but the idea behind is to make it very accessible to toggle it on demand more frequently. Maybe we can
> add a bottom for that [>>] in the beginning of the modeline to give a toggle effect?

If people agree that Speedbar is so important these days, the mode
line is not a good place for the toggle.  But I'm not sure people
agree.  For example, isn't Speedbar important mostly in PL major
modes? what would you do with it in, say, Text mode?  So maybe make it
appear automatically in such modes?

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On September 12, 2020 11:25:22 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 12 Sep 2020 11:03:33 +0200
>> CC:
>casouri@gmail.com,ams@gnu.org,monnier@iro.umontreal.ca,ghe@sdf.org,tecosaur@gmail.com
>> From: Ergus <spacibba@aol.com>
>> 
>> >> 4) Right click: (Probably it is the most lacking functionality and
>> >> surprising for any user not using the terminal.) Right click is
>> >expected
>> >> to bring a panel with the most common operations. It is useful,
>fast
>> >> and somehow standard since 1995 while removing most of the needs
>of
>> >the
>> >> toolbar which takes precious vertical space.
>> >
>> >We have this on C-mouse-2 and C-mouse-3. Putting those on mouse-2
>and
>> 
>> The menu we have in C-mouse-3 does not show the most basic options
>like copy, paste, and so on to
>> access them fast.
>
>Why should it?  We show the menu for the current major mode, which is
>IMO more useful than basic editing.
>
>It's a pity too many newbies don't see the menu bar and the tool bar,
>because all this was arranged to have all the important features be
>readily available through the different UI elements.  With the menu
>and the tool bar removed, we don't have enough UI elements to satisfy
>all the important needs.  

Right click panel is closer and faster to copy paste and so on. As well as expected.

>Which is one more reason to encourage
>newbies to start with the vanilla Emacs, not with the hyper-loaded
>"distros".
>
Not exactly because some of these "distros" already add their own right click panel.

(While I agree that most of them end hyper-loaded, but not because of this specific detail)

>> >> 5) sidebar: most code editors have a button somewhere in the
>> >interface
>> >> to show/hide the sidebar to explore and open files/access symbols
>or
>> >see
>> >> open files.
>> >
>> >We have it in Options->Hide/Show.
>> 
>> Yes but the idea behind is to make it very accessible to toggle it on
>demand more frequently. Maybe we can
>> add a bottom for that [>>] in the beginning of the modeline to give a
>toggle effect?
>
>If people agree that Speedbar is so important these days, the mode
>line is not a good place for the toggle.  But I'm not sure people
>agree.  For example, isn't Speedbar important mostly in PL major
>modes? what would you do with it in, say, Text mode?  So maybe make it
>appear automatically in such modes?

The sidebars around usually are more like neotree (a file browser) + imenu-sidebar (program browser if it is a program) + projectile sidebars (a list of this project's opened files) so there will be at least one of them always useful (neotree).

If you give a look to the simple geany editor you will see the most basic implementation of this "ide like" feature.
 

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

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   > >We have this on C-mouse-2 and C-mouse-3. Putting those on mouse-2 and
   > 
   > The menu we have in C-mouse-3 does not show the most basic
   > options like copy, paste, and so on to access them fast.

   Why should it?  We show the menu for the current major mode, which is
   IMO more useful than basic editing.

FWIW, in fundamental-mode it does show copy/cut/paste... Maybe
text-mode could be added, similar to some other modes where it makes
sense.  In some modes, it definitly doesn't make sense.

Re: "modern" colors Re: Changes for emacs 28

[Thibaut Verron]

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

Le sam. 12 sept. 2020 à 11:25, Eli Zaretskii <eliz@gnu.org> a écrit :

>
> > >> 4) Right click: (Probably it is the most lacking functionality and
> > >> surprising for any user not using the terminal.) Right click is
> > >expected
> > >> to bring a panel with the most common operations. It is useful, fast
> > >> and somehow standard since 1995 while removing most of the needs of
> > >the
> > >> toolbar which takes precious vertical space.
> > >
> > >We have this on C-mouse-2 and C-mouse-3. Putting those on mouse-2 and
> >
> > The menu we have in C-mouse-3 does not show the most basic options like
> copy, paste, and so on to
> > access them fast.
>
> Why should it?  We show the menu for the current major mode, which is
> IMO more useful than basic editing.
>

Is it? What feature of your major mode do you use more often than
copy/paste?

It's a pity too many newbies don't see the menu bar and the tool bar,
> because all this was arranged to have all the important features be
> readily available through the different UI elements.  With the menu
> and the tool bar removed, we don't have enough UI elements to satisfy
> all the important needs.  Which is one more reason to encourage
> newbies to start with the vanilla Emacs, not with the hyper-loaded
> "distros".
>

I believe that mouse users have muscle memory for right-click, 15 px down,
left-click, where we have M-w. Moving the mouse to the top of the screen
for the same operation is a lot slower.

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

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Sun, 13 Sep 2020 07:51:53 +0200
> Cc: Ergus <spacibba@aol.com>, casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org, 
> 	monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
> 
>  > The menu we have in C-mouse-3 does not show the most basic options like copy, paste, and so on
>  to
>  > access them fast.
> 
>  Why should it?  We show the menu for the current major mode, which is
>  IMO more useful than basic editing.
> 
> Is it? What feature of your major mode do you use more often than copy/paste? 

Typing characters, of course.  I hope you will not suggest that we
should have a menu item for inserting a character.

My point is that frequency of operations is not the only criterion for
what to put on the context menu, not even the main one.  The most
important criterion, IMO, is what are the important operations that
would be otherwise much harder to discover and invoke.

We decided that the menu for the current major mode is a very good
approximation to what the user would like to have at his/her
fingertips.  There's probably some space for improving that, but I
think the basic principle that the context menu should depend heavily
on the major mode is valid and should be preserved.

Re: "modern" colors Re: Changes for emacs 28

[Thibaut Verron]

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

Le dim. 13 sept. 2020 à 16:21, Eli Zaretskii <eliz@gnu.org> a écrit :

> > From: Thibaut Verron <thibaut.verron@gmail.com>
> > Date: Sun, 13 Sep 2020 07:51:53 +0200
> > Cc: Ergus <spacibba@aol.com>, casouri@gmail.com, emacs-devel@gnu.org,
> ams@gnu.org,
> >       monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
> >
> >  > The menu we have in C-mouse-3 does not show the most basic options
> like copy, paste, and so on
> >  to
> >  > access them fast.
> >
> >  Why should it?  We show the menu for the current major mode, which is
> >  IMO more useful than basic editing.
> >
> > Is it? What feature of your major mode do you use more often than
> copy/paste?
>
> Typing characters, of course.  I hope you will not suggest that we
> should have a menu item for inserting a character.
>

Of course not, the keyboard shortcut for character insertion is not
surprising. But basic operations which are not insertion? Copy/cut/paste,
undo/redo, maybe search/-and-replace... All those are very common
operations, none depend on the major mode, and all require to either learn
an unusual keyboard shortcut, use the toolbar, or navigate the menu-bar.


My point is that frequency of operations is not the only criterion for
> what to put on the context menu, not even the main one.  The most
> important criterion, IMO, is what are the important operations that
> would be otherwise much harder to discover and invoke.
>

I agree, but I'd say that ease of invokation should take priority over ease
of discoverability. The menu bar offers just as much discoverability, but
the ease of use is greatly decreased there.

I have only one data point at hand, but I happen to have helped a new user
set up an emacs environment recently. They were happy with finding options
in the menu bar, and (a selective list of) major mode commands in the tool
bar.

The major-mode submenus of the menu bar were overwhelming on the other
hand, and finding the same menus on the context menu was not much help.

Not finding common operations such as copy and paste in the context menu
was more disconcerting (and directly led them to discovering and activating
CUA).

Ditto when their spell-check (again, activated without my help via the
menu) flagged some words and they didn't find the corrections in the
context menu.


We decided that the menu for the current major mode is a very good
> approximation to what the user would like to have at his/her
> fingertips.


Was it perhaps at the same time as it was decided that this menu should
require a modifier key in the default bindings? ;)

The context menu in emacs is underused to say the least, and I'd blame that
on both the hidden binding and the redundant contents.

Sadly, by the point users know enough to know how to address/report the
poor condition of the context menu, they simply don't care anymore because
they can get everything done with keyboard shortcuts and menu/tool bar.

There's probably some space for improving that, but I
> think the basic principle that the context menu should depend heavily
> on the major mode is valid and should be preserved.
>

I believe that it should depend on the context in a wide sense. That
includes the major mode, but also the minor modes, the thing at point,
whether the region is active, etc.

Copy-cut-paste and auto-correct suggestions should be no-brainers, for
instance.

>

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

Re: "modern" colors Re: Changes for emacs 28

[Richard Stallman]

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

  > The menu we have in C-mouse-3 does not show the most basic options like copy, paste, and so on to access them fast.

Indeed, it doesn't.  That's because we put these on other mouse buttons.
To put them in a menu _also_ seems like offering a special inconvenient
alternative.

But if that's what some users like, we can certainly offer that 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: "modern" colors Re: Changes for emacs 28

[Yuri Khan]

On Sat, 12 Sep 2020 at 13:28, Eli Zaretskii <eliz@gnu.org> wrote:

> > 4) Right click: (Probably it is the most lacking functionality and
> > surprising for any user not using the terminal.) Right click is expected
> > to bring a panel with the most common operations. It is useful, fast
> > and somehow standard since 1995 while removing most of the needs of the
> > toolbar which takes precious vertical space.
>
> We have this on C-mouse-2 and C-mouse-3.  Putting those on mouse-2 and
> mouse-3 would fly in the face of pasting text from the window-system
> selection, which is something a text editor cannot possibly disable by
> default.

mouse-2 pastes text from selection and a context menu would not change
that. mouse-3, as far as I can tell[1], extends the selection to the
point of the click. In most applications, this is done by Shift+left
click.

[1]: I have read the docstring for mouse-save-then-kill and it turns
out you can kill with a double-right-click. Maybe it’s convenient when
you internalize it. In a conventional UI, that would be
Shift+left-click to select, then right-click for context menu, then
Cut.

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sat, 12 Sep 2020 18:24:26 +0700
> Cc: Ergus <spacibba@aol.com>, Yuan Fu <casouri@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>, "Alfred M. Szmidt" <ams@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Gregory Heytings <ghe@sdf.org>, TEC <tecosaur@gmail.com>
> 
> > We have this on C-mouse-2 and C-mouse-3.  Putting those on mouse-2 and
> > mouse-3 would fly in the face of pasting text from the window-system
> > selection, which is something a text editor cannot possibly disable by
> > default.
> 
> mouse-2 pastes text from selection and a context menu would not change
> that.

It will on two-button mice.

> mouse-3, as far as I can tell[1], extends the selection to the
> point of the click. In most applications, this is done by Shift+left
> click.

Shift+left click is already taken in Emacs.

I'm not sure a complete reshuffle of mouse-related bindings, of the
kind that seems to be implied here, is really a good idea in Emacs.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 02:32:50PM +0300, Eli Zaretskii wrote:
>
>It will on two-button mice.
>
>
>Shift+left click is already taken in Emacs.
>
There is the mouse-appearance-menu, which is actually not that bad for
our purposes.

>I'm not sure a complete reshuffle of mouse-related bindings, of the
>kind that seems to be implied here, is really a good idea in Emacs.

I think that only a menu in mouse-3 will be enough (as a customizable
option to avoid complains) so only mouse-3 will change.

Then we could also find alternatives to "enrich" mouse-appearance-menu
too. Probably we can rename it to contain appearance + other options. As
well.

RE: "modern" colors Re: Changes for emacs 28

[Drew Adams]

> I think that only a menu in mouse-3 will be enough (as a customizable
> option to avoid complains) so only mouse-3 will change.

See `mouse3.el'.

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

>> > We have this on C-mouse-2 and C-mouse-3.  Putting those on mouse-2 and
>> > mouse-3 would fly in the face of pasting text from the window-system
>> > selection, which is something a text editor cannot possibly disable by
>> > default.
>> mouse-2 pastes text from selection and a context menu would not change
>> that.
> It will on two-button mice.

Under GNU/Linux at least, all the two-button mouse I saw gave me
`mouse-1` and `mouse-3` (and to get the effect of `mouse-2` I needed to
use some convention like pressing both buttons at the same time, which
is frustratingly difficult to do reliably).


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 11:36:33AM -0400, Stefan Monnier wrote:
>>> > We have this on C-mouse-2 and C-mouse-3.  Putting those on mouse-2 and
>>> > mouse-3 would fly in the face of pasting text from the window-system
>>> > selection, which is something a text editor cannot possibly disable by
>>> > default.
>>> mouse-2 pastes text from selection and a context menu would not change
>>> that.
>> It will on two-button mice.
>
>Under GNU/Linux at least, all the two-button mouse I saw gave me
>`mouse-1` and `mouse-3` (and to get the effect of `mouse-2` I needed to
>use some convention like pressing both buttons at the same time, which
>is frustratingly difficult to do reliably).
>
>
>        Stefan
>
In my mouse (a pretty standard logitech) mouse-2 is pressing (not
rolling) the wheel down. This does not work for you?

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

> In my mouse (a pretty standard logitech) mouse-2 is pressing (not
> rolling) the wheel down. This does not work for you?

That counts as a "three button mouse" for me (actually three buttons
plus a wheel), not a two-button mouse.


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Richard Stallman]

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

  > I'm not sure a complete reshuffle of mouse-related bindings, of the
  > kind that seems to be implied here, is really a good idea in Emacs.

I think we should consider offering a reshuffled mode
if that will make some new users like Emacs much better.

The reason I think so is that the definitions of mouse clicks
is largely orthogonal to the keyboard commands.  So it would not
be a lot of work to develop this, and even less to maintain it.

How about if someone implements it so people can try it?

I think the hardest part will be to modify the various mode-specific
C-Mouse-3 (Mouse-3 in this mode) menus to conditionally include basic
editing commands.  Here's an idea to make that simpler:

Define augment-mouse-menu to take a menu specification not containung
the basic editing commands, and optionally add those depending on
the interface choice.

Or perhaps define-mouse-menu to do that, and then put it on the proper
mouse click depending on the interface choice.

-- 
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: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-13 07:06 +03, Richard Stallman <rms@gnu.org> wrote:
> I think the hardest part will be to modify the various mode-specific
> C-Mouse-3 (Mouse-3 in this mode) menus to conditionally include basic
> editing commands.

IMHO this is not really necessary.  A simpler approach would be to
simply have a mode which has the plain right click (mouse-3) show a
simple menu.  This is what VS Code has, which looks fit for us too:

Go to definition => xref-find-definitions
----
Cut
Copy
Paste
----
Command palette => execute-extended-command

We could extend this with undo/redo + maybe ‘insert-char’, which are
present in some other applications.  The following is a demonstrative
example that’s IMHO fairly ‘Emacsy’ but I couldn’t get the attached
commands to run (FWIW the relevant docs are pretty sparse for this):

(global-set-key
 (kbd "<mouse-3>")
 (lambda (event)
   (interactive "e")
   (x-popup-menu
    event
    (let ((map (make-sparse-keymap)))
      (define-key map [xref] '("Go to definition" . #'xref-find-definitions))
      (define-key-after
        map [sep1] '("--" . nil) 'xref)
      (define-key-after
        map [cut] '("Cut" . #'kill-region) 'sep1)
      (define-key-after
        map [copy] '("Copy" . #'kill-ring-save) 'cut)
      (define-key-after
        map [paste] '("Paste" . #'yank) 'copy)
      (define-key-after
        map [sep2] '("--" . nil) 'paste)
      (define-key-after
        map [undo] '("Undo" . #'undo) 'sep2)
      (define-key-after
        map [redo] '("Paste" . #'undo-redo) 'undo)
      (define-key-after
        map [sep3] '("--" . nil) 'redo)
      (define-key-after
        map [special] '("Insert special character" . #'insert-char) 'sep3)
      (define-key-after
        map [command] '("Execute command" . #'execute-extended-command) 'special)
      (define-key-after
        map [sexp] '("Execute lisp expression" . #'eval-expression) 'command)
      map))))

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

Re: "modern" colors Re: Changes for emacs 28

[Richard Stallman]

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

  > IMHO this is not really necessary.  A simpler approach would be to
  > simply have a mode which has the plain right click (mouse-3) show a
  > simple menu

Do you mean, this menu is the same regardless of modes, buttons, etc?

The C-Mouse-3 menus offer commands useful for the text you are using.
Why not include that too?

-- 
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: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-14 06:50 +03, Richard Stallman <rms@gnu.org> wrote:
>   > IMHO this is not really necessary.  A simpler approach would be to
>   > simply have a mode which has the plain right click (mouse-3) show a
>   > simple menu
>
> Do you mean, this menu is the same regardless of modes, buttons, etc?
>
> The C-Mouse-3 menus offer commands useful for the text you are using.
> Why not include that too?

I’d expect that this ‘right click menu’ to have a large skeleton that’s
the same everywhere, but possibly with some salient context relevant
items.  Because that’s what I’ve observed in most operating systems and
GUI applications.  The only place I’ve seen something like Emacs’
C-mouse bindings is NextStep and GnuStep.

Another thing is mouse bindings with modifiers are rather uncommon in
other software.  Personally, the only place I used them was TVM menus.

The current binding of C-mouse-3 is basically the global menu and it’s
way to crowded to be useful as a quick access right click menu.  Ideally
the majority of actions in such a menu would be accessible without
opening submenus.  Otherwise I don’t think providing the global menu at
three different places is of any use.

A positive side effect would be that this mostly one-level menu would
list some common keybindings like for kill, save kill, yank, M-x, etc.,
so it’d have some didactic value as well.

An interesting way to set things up could be to somehow have a hook
which major modes could use to add a submenu to this right click context
menu, in whatever fashion they see fit.

IMHO if we fix the menu I wrote and add the functionality I just
mentioned, we’d have something to play with and modify up until we
eventually arrive at the 28 release cycle, and at that point we’d have
developed an implementation that pleases everyone.

In fact we could just throw a bunch of stuff this whole discussion talks
about behind a configure flag like --with/without-breaking-ui-changes,
and folks like me who use up-to-date builds of Emacs master could
periodically try these out and report breakage, workarounds, usage
patterns, etcetera.  So we’d have an iterative, interactive approach,
rather than trying to ossify everything right at the start.  Actually,
given the size of this discussion, having a separate
‘emacs-modernization’ mailing list could be a good idea too.  Because
this discussion will likely have the spotlight for some certain and long
amount of time up until when 28 becomes ready for release candidates.

If it sounds interesting / plausible, I can post this last paragraph,
with a bit more detail, as it’s own toplevel thread.

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

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Mon, Sep 14, 2020 at 11:08:44AM +0300, Göktuğ Kayaalp wrote:
>On 2020-09-14 06:50 +03, Richard Stallman <rms@gnu.org> wrote:
>>   > IMHO this is not really necessary.  A simpler approach would be to
>>   > simply have a mode which has the plain right click (mouse-3) show a
>>   > simple menu
>>
>> Do you mean, this menu is the same regardless of modes, buttons, etc?
>>
>> The C-Mouse-3 menus offer commands useful for the text you are using.
>> Why not include that too?
>
>I’d expect that this ‘right click menu’ to have a large skeleton that’s
>the same everywhere, but possibly with some salient context relevant
>items.  Because that’s what I’ve observed in most operating systems and
>GUI applications.  The only place I’ve seen something like Emacs’
>C-mouse bindings is NextStep and GnuStep.
>
>Another thing is mouse bindings with modifiers are rather uncommon in
>other software.  Personally, the only place I used them was TVM menus.
>
>The current binding of C-mouse-3 is basically the global menu and it’s
>way to crowded to be useful as a quick access right click menu.  Ideally
>the majority of actions in such a menu would be accessible without
>opening submenus.  Otherwise I don’t think providing the global menu at
>three different places is of any use.
>
IMO it is better to improve that same C-mouse-3 and promote it to
mouse-3.

https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01141.html

>A positive side effect would be that this mostly one-level menu would
>list some common keybindings like for kill, save kill, yank, M-x, etc.,
>so it’d have some didactic value as well.
>
Totally agree

>An interesting way to set things up could be to somehow have a hook
>which major modes could use to add a submenu to this right click context
>menu, in whatever fashion they see fit.
>
We do something similar in the menu-bar right? I mean, dynamically add
entries to the menu bar.

The only thing I concern about this is that many modes could try to add
many entries and we end with a bad very long problematic panel. I face
that problem frequently in lxde.

>IMHO if we fix the menu I wrote and add the functionality I just
>mentioned, we’d have something to play with and modify up until we
>eventually arrive at the 28 release cycle, and at that point we’d have
>developed an implementation that pleases everyone.
>
>In fact we could just throw a bunch of stuff this whole discussion talks
>about behind a configure flag like --with/without-breaking-ui-changes,
>and folks like me who use up-to-date builds of Emacs master could
>periodically try these out and report breakage, workarounds, usage
>patterns, etcetera.  So we’d have an iterative, interactive approach,
>rather than trying to ossify everything right at the start.  Actually,
>given the size of this discussion, having a separate
>‘emacs-modernization’ mailing list could be a good idea too.  Because
>this discussion will likely have the spotlight for some certain and long
>amount of time up until when 28 becomes ready for release candidates.
>
>If it sounds interesting / plausible, I can post this last paragraph,
>with a bit more detail, as it’s own toplevel thread.
>

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

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Göktuğ Kayaalp <self@gkayaalp.com>
> Cc: casouri@gmail.com,
>  spacibba@aol.com, emacs-devel@gnu.org, ams@gnu.org,
>  monnier@iro.umontreal.ca, ghe@sdf.org, eliz@gnu.org,
>  yuri.v.khan@gmail.com, tecosaur@gmail.com
> Date: Mon, 14 Sep 2020 11:08:44 +0300
> 
> The current binding of C-mouse-3 is basically the global menu

Only if you turn off menu-bar-mode.  When that mode is on, C-mouse-3
displays a much smaller menu specific to the current buffer's major
mode.

RE: "modern" colors Re: Changes for emacs 28

[Drew Adams]

> > Do you mean, this menu is the same regardless of modes, buttons, etc?
> > The C-Mouse-3 menus offer commands useful for the text you are using.
> > Why not include that too?
> 
> I’d expect that this ‘right click menu’ to have a large skeleton that’s
> the same everywhere, but possibly with some salient context relevant
> items.

mouse3.el allows that.  The skeleton can be large,
small, or nonexistent.  It can be the same everywhere
or the same for contexts X,Y,Z and differently the
same for contexts A,B,C.  And context-relevant items
or submenus can be added, beyond any "skeleton(s)".

> The current binding of C-mouse-3 is basically the global menu and it’s
> way to crowded to be useful as a quick access right click menu.  Ideally
> the majority of actions in such a menu would be accessible without
> opening submenus.  Otherwise I don’t think providing the global menu at
> three different places is of any use.

It's not either-or.  Different things can be useful
for different contexts - different modes, users,
phase of the moon, whatever.  A context menu can be
useful whether it has submenus or not.  No one need
bother with, or be bothered by, submenus if the
top-level items s?he uses most (or exclusively) are
readily available.

Just because one thing is often useful (e.g. quick
access to simple edit actions), it doesn't follow
that other, different kinds of things can't also
be useful.

> An interesting way to set things up could be to somehow have a hook
> which major modes could use to add a submenu to this right click context
> menu, in whatever fashion they see fit.

mouse3.el does that.  It's easy for a mode to add
its own context menu or replace a default one.

https://www.emacswiki.org/emacs/Mouse3#ModeSpecificPopupMenu

> IMHO if we fix the menu I wrote and add the functionality I just
> mentioned, we’d have something to play with and modify up until we
> eventually arrive at the 28 release cycle, and at that point we’d have
> developed an implementation that pleases everyone.

You have mouse3.el to play with.  It doesn't
hard-code stuff.

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

>> 4) Right click: (Probably it is the most lacking functionality and
>> surprising for any user not using the terminal.) Right click is expected
>> to bring a panel with the most common operations. It is useful, fast
>> and somehow standard since 1995 while removing most of the needs of the
>> toolbar which takes precious vertical space.
>
> We have this on C-mouse-2 and C-mouse-3.  Putting those on mouse-2 and
> mouse-3 would fly in the face of pasting text from the window-system
> selection, which is something a text editor cannot possibly disable by
> default.  Unless we are willing to abandon support for selections,
> that is (which I guess what the "modern" editors did?).

`down-mouse-3` is currently basically unused, so we could definitely
make it popup a context menu without interfering with current bindings.

I proposed a patch along those lines some years ago.


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Iñigo Serna]

On 11 September 2020 at 16:23 +02, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I personally have no idea what "modern" looks like or what makes
> something look "modern", so I'd welcome a description.

IMO, Po Lu's work (already presented here [1]) would be a good example
at nice "modern" integration with linux computers using any gtk-based desktop.

Of course, it's no finished and possibly needs some work, but I think
this, plus wayland compatiblity and, maybe, some minor additions like
all-the-icons functionality would offer a quite "modern" aesthetic
experience.


Best regards,
Iñigo

[1] https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01901.html

Re: "modern" colors Re: Changes for emacs 28

[Yuri Khan]

On Sat, 12 Sep 2020 at 05:15, Ergus <spacibba@aol.com> wrote:

> 4) Right click: (Probably it is the most lacking functionality and
> surprising for any user not using the terminal.) Right click is expected
> to bring a panel with the most common operations. It is useful, fast
> and somehow standard since 1995 while removing most of the needs of the
> toolbar which takes precious vertical space.

I want to clarify an important detail here. Right click is expected to
display a *context menu* and the context menu is expected to contain
commands that are related to the object that received the right click.
This does not always correlate with “the most common operations”.

Right-clicking a misspelled word offers a list of possible
corrections. Right-clicking with a highlighted region offers Cut and
Copy. (Actually, Cut/Copy/Paste are always on the context menu for
text editors, and get enabled/disabled depending on availability.) In
a programming mode, right-clicking an identifier could offer
xref-find-definitions and xref-find-references.

Applications made with greater attention to UI design also extend the
context menu functionality to other UI elements. Right-clicking a
toolbar offers to hide or customize it. Right-clicking a tab offers to
save or close the document.

Implementing a context menu in Emacs is not a simple matter of binding
<mouse-3> to any of the menus displayed by <C-mouse-1…3>. Someone™
needs to pick things that are relevant in each context. More likely,
each major mode needs to pick things that are appropriate in its
buffers.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 06:13:38PM +0700, Yuri Khan wrote:
>On Sat, 12 Sep 2020 at 05:15, Ergus <spacibba@aol.com> wrote:
>
>
>I want to clarify an important detail here. Right click is expected to
>display a *context menu* and the context menu is expected to contain
>commands that are related to the object that received the right click.
>This does not always correlate with “the most common operations”.
>
>Right-clicking a misspelled word offers a list of possible
>corrections. Right-clicking with a highlighted region offers Cut and
>Copy. (Actually, Cut/Copy/Paste are always on the context menu for
>text editors, and get enabled/disabled depending on availability.) In
>a programming mode, right-clicking an identifier could offer
>xref-find-definitions and xref-find-references.
>
>Applications made with greater attention to UI design also extend the
>context menu functionality to other UI elements. Right-clicking a
>toolbar offers to hide or customize it. Right-clicking a tab offers to
>save or close the document.
>
>Implementing a context menu in Emacs is not a simple matter of binding
><mouse-3> to any of the menus displayed by <C-mouse-1…3>. Someone™
>needs to pick things that are relevant in each context. More likely,
>each major mode needs to pick things that are appropriate in its
>buffers.

Totally agree (maybe not properly explained in my text).

So far there is some work already done on external packages and the
mode-specific menus have some information about the context.

We only need to set that in a smarter way. It is not that complex so
far, at least for the text part. But this goes beyond my capabilities
and I don't think that the experts are convinced yet (for the moment).

RE: "modern" colors Re: Changes for emacs 28

[Drew Adams]

> I want to clarify an important detail here. Right click is expected to
> display a *context menu* and the context menu is expected to contain
> commands that are related to the object that received the right click.
> This does not always correlate with “the most common operations”.
> 
> Right-clicking a misspelled word offers a list of possible
> corrections. Right-clicking with a highlighted region offers Cut and
> Copy. (Actually, Cut/Copy/Paste are always on the context menu for
> text editors, and get enabled/disabled depending on availability.) In
> a programming mode, right-clicking an identifier could offer
> xref-find-definitions and xref-find-references.
> 
> Applications made with greater attention to UI design also extend the
> context menu functionality to other UI elements. Right-clicking a
> toolbar offers to hide or customize it. Right-clicking a tab offers to
> save or close the document.
> 
> Implementing a context menu in Emacs is not a simple matter of binding
> <mouse-3> to any of the menus displayed by <C-mouse-1…3>. Someone™
> needs to pick things that are relevant in each context. More likely,
> each major mode needs to pick things that are appropriate in its
> buffers.

1. I agree with your characterization of a
   context menu.

2. The `C-mouse-3' is contextual, in the sense
   that it shows the major-mode menu(s), and some
   items in some of those menus may apply to the
   thing clicked on.

   For example, Dired mode's `Immediate' menu
   has items that apply to the file/dir of the
   clicked line.  (`C-mouse-3' shows you all of
   the Dired mode menus.)

   But it's true that most major-mode menu items
   don't apply specifically to the thing clicked.
   They're generally context-specific (major mode),
   but they aren't specific to what you click on.

   [We do also have a mouse-3 (and C-mouse-3)
   context menu for the scroll bar, BTW.]

> Implementing a context menu in Emacs is not a
> simple matter of binding <mouse-3> to any of
> the menus displayed by <C-mouse-1…3>. Someone™
> needs to pick things that are relevant in each
> context. More likely, each major mode needs to
> pick things that are appropriate in its buffers.

3. I agree that Emacs should provide helpful
   right-click context menus, and that picking
   what's helpful/relevant isn't a simple matter.

   And Emacs should provide a way for users and
   libraries to easily define their own such, or
   improve the default right-click context menus.

   I've done this with library `mouse3.el'.

   It provides a menu with context-specific items
   by default.  And it's easy to change what
   items are offered.  And you don't even need to
   give up the ordinary `mouse-3' behavior that
   lets you select text and optionally cut/delete
   the selection.

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

   https://www.emacswiki.org/emacs/download/mouse3.el

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   On Fri, Sep 11, 2020 at 10:23:19AM -0400, Stefan Monnier wrote:
   >> If you change a single face it doesn't improve anything. The whole thing
   >> is the important. The overall result after all the changes. A light
   >> toolbar looks worst with a dark background as well; big icons looks
   >> terrible with small fonts.
   >
   >I personally have no idea what "modern" looks like or what makes
   >something look "modern", so I'd welcome a description.  Showing me
   >examples doesn't really help me.  By description I don't mean "change
   >this one face to foo", but rather the underlying ideas behind the
   >various changes.
   >
   >
   >        Stefan
   >
   I will try my best but my terminology could be totally wrong (worst than
   my English). (Note that I only use emacs from the terminal anyway)

I'd like to get back to the initial premsis that "some color changes"
could make Emacs more modern.  While this list is interesting, and
lists things that Emacs already provides, it is slightly on the left
side of the topic.  I wanted to understand what is the meaning of
"modern", and "some color" changes seemed to be easy enough to
describe.

   2) Modeline: Our modeline is a kind of relic from other times. With the
   same gray color in the terminal and some cryptic information. It also
   shows the line but not the column by default and the file status is
   somehow in that cryptic initial part I don't think many users understand
   very well.

   Just adding an * to the filename in modeline (and or tab when using
   them) or changing the color is easier to understand. Than
   -UUU:----F1

How is that different from today?  ** signifies that the buffer is
modified...

New users don't have to understand it from the start though, it is
something one can come to understand with using Emacs.  If you hover
with the mouse over each item, it will describe what each thing means,
and you can change each thing accordingly.

   3) Colors: People prefer higher contrast in general 4 example: in my
   system when the region es enabled the default gray color is so light
   that I can't see it. Same applies to icon that when enabled or disabled
   the difference sometimes is minimal.

Can you provide research on that people do actually prefer higher
contrast in general?  Your example doesn't really follow from the
first claim -- since that is your specific preference, not everyone
elses preference.

   Usually blues and green are more attractive to users (that's why MS
   decided to use them for their OS). PANTONE448C (a kind of yellow + grey)
   is considered the ugliest color ever and our UI and fonts are mostly
   grey and yellow-orange.

Again, what is the basis for these claims?  You make several of them
that this or that is the case, but you do not say on what basis the
claim is made, it would be very interesting to read about it.

For example, several applications (e.g, even those that you mention)
also implement light colored themes.  Most source forges also default
to white backgrounds, so the claim that there is some preference for
one (or the other!) seems weak.

Only that a general acceptance that people have a preference for
something; and Emacs already has means for switching to dark/light
backgrounds -- maybe this could be made easier to switch, for example
a dark/light-toggle-mode that switches between the default dark and
light coloring scheme.

   4) Right click: (Probably it is the most lacking functionality and
   surprising for any user not using the terminal.) Right click is expected
   to bring a panel with the most common operations. It is useful, fast
   and somehow standard since 1995 while removing most of the needs of the
   toolbar which takes precious vertical space.

The behaviours you describe are not that standard on the systems where
Emacs is mainly used, namely GNU systems with X11 for right clickity
behaviour, where it has been standard for the last 30 odd years (and
probobly longer, since this behaviour dates back at least to the Lisp
Machine).

It is important to remeber that Emacs has to pick some default, as it
happens it is the one where it was developed on.

   6) fill-column-indicator, indent-column-indicator,
   highlight-all-like-this on mouse double click and idle,
   show-parent-mode, show-trailing-whitespaces.

Could you explain how those modes are useful, is it for new users,
programming, what exactly?

Seeing the fill-column-indicator seems slightly useless, since if you
fill the region that will be honoured anyway.  indent-column-indicator
seems to be a programming thing and probobly only useful for some
specific programming languages or narrow use cases, same with
highlight-all-like-this and show-trailing-whitespaces.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 10:52:37AM -0400, Alfred M. Szmidt wrote:
>   I will try my best but my terminology could be totally wrong (worst than
>   my English). (Note that I only use emacs from the terminal anyway)
>
>I'd like to get back to the initial premsis that "some color changes"
>could make Emacs more modern.  While this list is interesting, and
>lists things that Emacs already provides, it is slightly on the left
>side of the topic.  I wanted to understand what is the meaning of
>"modern", and "some color" changes seemed to be easy enough to
>describe.
>
The meaning of modern is by default not old; it means not to look like a
win95 app in 2020. The grays and white backgrounds has been substituted
by blue black and other colors.

There is not science here. Just a matter of preferences and
subjectivity. But looking around popular applications, you will find
that there is a pattern among the years.
>
>   2) Modeline: Our modeline is a kind of relic from other times. With the
>   same gray color in the terminal and some cryptic information. It also
>   shows the line but not the column by default and the file status is
>   somehow in that cryptic initial part I don't think many users understand
>   very well.
>
>   Just adding an * to the filename in modeline (and or tab when using
>   them) or changing the color is easier to understand. Than
>   -UUU:----F1
>
>How is that different from today?  ** signifies that the buffer is
>modified...
>
I maaany ways. Not for pleasure that's the first thing all the distros
change that, powerline became popular and so on.

Just look around; don't believe me

>New users don't have to understand it from the start though, it is
>something one can come to understand with using Emacs.  If you hover
>with the mouse over each item, it will describe what each thing means,
>and you can change each thing accordingly.
>
New users are used to know if the document has changes at least. And in
the applications they use: filename* by default.

>   3) Colors: People prefer higher contrast in general 4 example: in my
>   system when the region es enabled the default gray color is so light
>   that I can't see it. Same applies to icon that when enabled or disabled
>   the difference sometimes is minimal.
>
>Can you provide research on that people do actually prefer higher
>contrast in general?  Your example doesn't really follow from the
>first claim -- since that is your specific preference, not everyone
>elses preference.
>
Lock back in this same thread there was a long discussion about
that. The supporters of light colors brought some articles about
astigmatism and so on, while the others bring different ones.

Again look around and compare what you see.

>   Usually blues and green are more attractive to users (that's why MS
>   decided to use them for their OS). PANTONE448C (a kind of yellow + grey)
>   is considered the ugliest color ever and our UI and fonts are mostly
>   grey and yellow-orange.
>
>Again, what is the basis for these claims?  You make several of them
>that this or that is the case, but you do not say on what basis the
>claim is made, it would be very interesting to read about it.
>
Blue is known to be the most favorite color since 1920. Don't trust me,
just google it. There have been studies, has to do with the sky and the
sea bla bla bla. Yellow on the other hand is associated with illness and
old white things (again this is veeeery subjective).

But when MS decided to create their operative system they did after a
market study.

Again. Don't trust me, and actually these are not all my preferences. I
just asked a couple of students on yesterday and compared with what they
use and said.

>For example, several applications (e.g, even those that you mention)
>also implement light colored themes.  Most source forges also default
>to white backgrounds, so the claim that there is some preference for
>one (or the other!) seems weak.
>
>Only that a general acceptance that people have a preference for
>something; and Emacs already has means for switching to dark/light
>backgrounds -- maybe this could be made easier to switch, for example
>a dark/light-toggle-mode that switches between the default dark and
>light coloring scheme.
>
This is actually what is being discussed. Any way just look at the
popular downloaded emacs themes the so called "distros", and the actual
"top" editors. Sourceforge is also kind of "old" as users prefer github
(which is actually working in a dark mode too). Understand that I never
said we should set dark themes by default; I just replied what young
developers consider "old". 

>   4) Right click: (Probably it is the most lacking functionality and
>   surprising for any user not using the terminal.) Right click is expected
>   to bring a panel with the most common operations. It is useful, fast
>   and somehow standard since 1995 while removing most of the needs of the
>   toolbar which takes precious vertical space.
>
>The behaviours you describe are not that standard on the systems where
>Emacs is mainly used, namely GNU systems with X11 for right clickity
>behaviour, where it has been standard for the last 30 odd years (and
>probobly longer, since this behaviour dates back at least to the Lisp
>Machine).
>
>It is important to remeber that Emacs has to pick some default, as it
>happens it is the one where it was developed on.
>
The right click contextual menu is standard so far in geany, gedit,
kate, jedit, anjuta, android studio, arduino studio, sublime, atom,
kwrite, kdevelop, qtcreator, clion, VSCode, Notepad++, Bluefish, Komodo,
Brakets, Eclipse... + browsers, Office applications, texmaker,
Texstudio, Kile and so on.

It is missing only in gvim and emacs in my experience.

So maybe 30 years ago it wasn't standard but today it is.

>   6) fill-column-indicator, indent-column-indicator,
>   highlight-all-like-this on mouse double click and idle,
>   show-parent-mode, show-trailing-whitespaces.
>
>Could you explain how those modes are useful, is it for new users,
>programming, what exactly?
>
>Seeing the fill-column-indicator seems slightly useless, since if you
>fill the region that will be honoured anyway.  indent-column-indicator
>seems to be a programming thing and probobly only useful for some
>specific programming languages or narrow use cases, same with
>highlight-all-like-this and show-trailing-whitespaces.
>
>
Just look around.

Again I never said that we should follow the fashion in all details. But
when someone tells "emacs looks old" these are the arguments.

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   On Sat, Sep 12, 2020 at 10:52:37AM -0400, Alfred M. Szmidt wrote:
   >   I will try my best but my terminology could be totally wrong (worst than
   >   my English). (Note that I only use emacs from the terminal anyway)
   >
   >I'd like to get back to the initial premsis that "some color changes"
   >could make Emacs more modern.  While this list is interesting, and
   >lists things that Emacs already provides, it is slightly on the left
   >side of the topic.  I wanted to understand what is the meaning of
   >"modern", and "some color" changes seemed to be easy enough to
   >describe.
   >
   The meaning of modern is by default not old; it means not to look like a
   win95 app in 2020. The grays and white backgrounds has been substituted
   by blue black and other colors.

Emacs from default screenshots looks like many of the popular editors
with light background.  I do not know what Windows 95 (calling Windows
a win is a loss), but I'm quite sure that it doesn't look like that.

Have you used Emacs in its default setting in the past years?

   There is not science here. Just a matter of preferences and
   subjectivity. But looking around popular applications, you will find
   that there is a pattern among the years.

You seem to have an experience with several other editors, which is
why I'm asking you specifically about the specific differences.  I
cannot possibly go through all editors to figure which one you think
is modern in our view, and telling me to "just look around" without
even having the slightest clue where isn't very helpful.

I'm simply trying to figure out what some of those subjective
differences are, but you're telling me to figure it out by myself.
Stefan too seemed interested in understanding what "modern" (be it in
your view, or otherwise) meant.

Let me try to reiterate again, could you point out a handful of
differences in colors and/or fonts (to keep it simple) between Emacs
and some other editor (one is fine, several would be interesting too
but I understand that can be taxing) that you find more modern than in
Emacs?

   >   Just adding an * to the filename in modeline (and or tab when using
   >   them) or changing the color is easier to understand. Than
   >   -UUU:----F1
   >
   >How is that different from today?  ** signifies that the buffer is
   >modified...
   >
   I maaany ways. Not for pleasure that's the first thing all the distros
   change that, powerline became popular and so on.

I do not understand what you are saying here.  You said that "adding
an * to the filename" would solve an issue -- that is already done
_today_ (and for decades in Emacs).  

   >New users don't have to understand it from the start though, it is
   >something one can come to understand with using Emacs.  If you hover
   >with the mouse over each item, it will describe what each thing means,
   >and you can change each thing accordingly.

   New users are used to know if the document has changes at least. And in
   the applications they use: filename* by default.

And in Emacs we do it in a similar fashion.  I've seen that some put
"modified" in the title bar, some show it differently -- indeed, I
think every single editor I can think of does it differently.

   Lock back in this same thread there was a long discussion about
   that. The supporters of light colors brought some articles about
   astigmatism and so on, while the others bring different ones.

Yes, and there too it was asked about the background to this research
-- and it too was underwhelming.

   >Only that a general acceptance that people have a preference for
   >something; and Emacs already has means for switching to dark/light
   >backgrounds -- maybe this could be made easier to switch, for example
   >a dark/light-toggle-mode that switches between the default dark and
   >light coloring scheme.

   This is actually what is being discussed. Any way just look at the
   popular downloaded emacs themes the so called "distros", and the
   actual "top" editors. Sourceforge is also kind of "old" as users
   prefer github (which is actually working in a dark mode
   too). Understand that I never said we should set dark themes by
   default; I just replied what young developers consider "old".

I know plenty of developers in their twenties that think that dark
backgrounds are "old terminal backgrounds".  That is why I am asking
for actual research, and not just your or my experience.  Downloads
are not statistics.  

With source forges I meant in general, not Sourceforge specifically.

And by your own accord, since some are only now working on dark-mode
themes, it cannot have been such an important thing for them.  Doesn't
this somewhat contradict the claim that this is the preference by the
majority of people?

   It is missing only in gvim and emacs in my experience.

I don't use that many programs, but don't forget xterm.

   So maybe 30 years ago it wasn't standard but today it is.

Dare say that none of those programs existed 30 years ago, but you are
confusing the behaviour of individual programs with the general
behaviour of the system which I was refering to, and a historical
context where the defaults where chosen.

Re: "modern" colors Re: Changes for emacs 28

[TEC]

Alfred M. Szmidt <ams@gnu.org> writes:

> You seem to have an experience with several other editors, which is
> why I'm asking you specifically about the specific differences.  I
> cannot possibly go through all editors to figure which one you think
> is modern in our view, and telling me to "just look around" without
> even having the slightest clue where isn't very helpful.
>
> I'm simply trying to figure out what some of those subjective
> differences are, but you're telling me to figure it out by myself.
> Stefan too seemed interested in understanding what "modern" (be it in
> your view, or otherwise) meant.
>
> Let me try to reiterate again, could you point out a handful of
> differences in colors and/or fonts (to keep it simple) between Emacs
> and some other editor (one is fine, several would be interesting too
> but I understand that can be taxing) that you find more modern than in
> Emacs?

FWIW, prompted by this I'm working on this point ;)

Timothy.

Re: "modern" colors Re: Changes for emacs 28

[TEC]

Forgot to mention: "Popularity" comes from the 2019 stack overflow survey.

TEC <tecosaur@gmail.com> writes:

> Hopefully this is in line with what you're looking for:
>
>
> I did some basic analysis with R (the language is a pain, but it's well
> suited for quick stuff like this).
>
> * Basic editor theme comparison
>
> #+NAME: editor-themes
> | Editor   | Popularity | Year | DarkDefault | Bluey | Line Numbers | StatusBarMatchBackground |
> |----------+------------+------+-------------+-------+--------------+--------------------------|
> | vscode   |       0.51 | 2015 |           1 |     1 |            1 |                        0 |
> | vs       |       0.32 | 1997 |           1 |     1 |            1 |                        0 |
> | npp      |       0.24 | 2003 |           0 |     0 |            1 |                        1 |
> | intellij |       0.24 | 2001 |           1 |     0 |            1 |                        1 |
> | vim      |       0.24 | 1991 |           1 |     0 |            0 |                        1 |
> | sublime  |       0.23 | 2008 |           1 |     1 |            1 |                        1 |
> | eclipse  |       0.14 | 2001 |           0 |     1 |            1 |                        1 |
> | pycharm  |       0.13 | 2014 |           1 |     1 |            1 |                        1 |
> | atom     |       0.13 | 2015 |           1 |     1 |            1 |                        1 |
> | brackets |          0 | 2014 |           0 |     1 |            1 |                        1 |
>
> #+BEGIN_SRC R :var editors=editor-themes
> library(orgutils)
> editors$Popularity <- editors$Popularity / sum(editors$Popularity)
> editors$Age <- (editors$Year - min(editors$Year)) / diff(range(editors$Year))
> editors$Age <- editors$Age / sum(editors$Age)
> dim(editors)
> #+END_SRC
>
> #+RESULTS:
> | 10 |
> |  8 |
>
> #+BEGIN_SRC R :results output raw
> means <- colMeans(editors[,4:7])
> popularityWeighted <- as.data.frame(round(colSums(editors[,4:7] * editors$Popularity), 2))
> ageWeighted <- as.data.frame(round(colSums(editors[,4:7] * editors$Age), 2))
> weightedValues <- cbind(means, popularityWeighted, ageWeighted)
> colnames(weightedValues) <- c("mean", "popularity weighted", "age weighted")
> toOrg(weightedValues)
> #+END_SRC
>
> #+RESULTS:
> | row.names                | mean | popularity weighted | age weighted |
> |--------------------------+------+---------------------+--------------|
> | DarkDefault              |  0.7 |                0.83 |          0.7 |
> | Bluey                    |  0.7 |                0.67 |         0.85 |
> | Line.Numbers             |  0.9 |                0.89 |            1 |
> | StatusBarMatchBackground |  0.8 |                0.62 |          0.8 |
>
> Hopefully this is of some interest :)
>
> Timothy

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sun, Sep 13, 2020 at 02:24:14AM +0800, TEC wrote:
>
>Alfred M. Szmidt <ams@gnu.org> writes:
>> Let me try to reiterate again, could you point out a handful of
>> differences in colors and/or fonts (to keep it simple) between Emacs
>> and some other editor (one is fine, several would be interesting too
>> but I understand that can be taxing) that you find more modern than in
>> Emacs?
>
>Hopefully this is in line with what you're looking for:
>


>
>I did some basic analysis with R (the language is a pain, but it's well
>suited for quick stuff like this).
>
>* Basic editor theme comparison
>
>#+NAME: editor-themes
>| Editor   | Popularity | Year | DarkDefault | Bluey | Line Numbers | StatusBarMatchBackground |
>|----------+------------+------+-------------+-------+--------------+--------------------------|
>| vscode   |       0.51 | 2015 |           1 |     1 |            1 |                        0 |
>| vs       |       0.32 | 1997 |           1 |     1 |            1 |                        0 |
>| npp      |       0.24 | 2003 |           0 |     0 |            1 |                        1 |
>| intellij |       0.24 | 2001 |           1 |     0 |            1 |                        1 |
>| vim      |       0.24 | 1991 |           1 |     0 |            0 |                        1 |
>| sublime  |       0.23 | 2008 |           1 |     1 |            1 |                        1 |
>| eclipse  |       0.14 | 2001 |           0 |     1 |            1 |                        1 |
>| pycharm  |       0.13 | 2014 |           1 |     1 |            1 |                        1 |
>| atom     |       0.13 | 2015 |           1 |     1 |            1 |                        1 |
>| brackets |          0 | 2014 |           0 |     1 |            1 |                        1 |
>
>#+BEGIN_SRC R :var editors=editor-themes
>library(orgutils)
>editors$Popularity <- editors$Popularity / sum(editors$Popularity)
>editors$Age <- (editors$Year - min(editors$Year)) / diff(range(editors$Year))
>editors$Age <- editors$Age / sum(editors$Age)
>dim(editors)
>#+END_SRC
>
>#+RESULTS:
>| 10 |
>|  8 |
>
>#+BEGIN_SRC R :results output raw
>means <- colMeans(editors[,4:7])
>popularityWeighted <- as.data.frame(round(colSums(editors[,4:7] * editors$Popularity), 2))
>ageWeighted <- as.data.frame(round(colSums(editors[,4:7] * editors$Age), 2))
>weightedValues <- cbind(means, popularityWeighted, ageWeighted)
>colnames(weightedValues) <- c("mean", "popularity weighted", "age weighted")
>toOrg(weightedValues)
>#+END_SRC
>
>#+RESULTS:
>| row.names                | mean | popularity weighted | age weighted |
>|--------------------------+------+---------------------+--------------|
>| DarkDefault              |  0.7 |                0.83 |          0.7 |
>| Bluey                    |  0.7 |                0.67 |         0.85 |
>| Line.Numbers             |  0.9 |                0.89 |            1 |
>| StatusBarMatchBackground |  0.8 |                0.62 |          0.8 |
>
>Hopefully this is of some interest :)
>
>Timothy

Sorry what is Bluey? And what is the data source for popularity?

Re: "modern" colors Re: Changes for emacs 28

[TEC]

Ergus <spacibba@aol.com> writes:
> Sorry what is Bluey? And what is the data source for popularity?

- Bluey :: I picked background tone colours and looked at the HSL value.
  If the Hue lay within the region of Blue, I designated the theme to be
  "Bluey". NB: Sublime and Intellij should have their 'Bluey' values
  swapped in the table I provided
- Popularity :: https://insights.stackoverflow.com/survey/2019#technology-_-most-popular-development-environments

Hope that clears things up!

Timothy.

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   > Let me try to reiterate again, could you point out a handful of
   > differences in colors and/or fonts (to keep it simple) between Emacs
   > and some other editor (one is fine, several would be interesting too
   > but I understand that can be taxing) that you find more modern than in
   > Emacs?

   Hopefully this is in line with what you're looking for:

Thank you, but I am not entierly sure what I am looking at -- the
Emacs you are showing is not from 1985.  What does the percentage
mean?

All of those look similar to me, other than black/light background
when it comes to color selection.  There is I think very little
commonality between the edtiors in general in what they show.

This doesn't seem to be a default Emacs screenshot?  The menu-bar is
different.

   I did some basic analysis with R (the language is a pain, but it's well
   suited for quick stuff like this).

   * Basic editor theme comparison

Emacs doeesn't seem to be listed?  

All the modes you show are programming modes, Emacs is more often than
not used in other context so things like line-number-mode do not make
much sense, like in the splash screen.

Emacs doesn't treat everything as a nail.

Re: "modern" colors Re: Changes for emacs 28

[TEC]

Alfred M. Szmidt <ams@gnu.org> writes:

> Thank you, but I am not entierly sure what I am looking at -- the
> Emacs you are showing is not from 1985.  What does the percentage
> mean?

Ah yes, a bit remiss of me not to state the format for my lablings:

 Editor --- Year of initial release (Stackoverflow 2019 survey, editor popularity)
 Screenshot of editor with default theme (trying for current)

> All of those look similar to me, other than black/light background
> when it comes to color selection.  There is I think very little
> commonality between the edtiors in general in what they show.

There are indeed many commonalities. However there are a few that Emacs
doesn't share --- namely: dark default, bluey tones, line numbers, and a
status bar that matches the background (in terms of background colour).
Hmm, and also iconography on the status bar.

> This doesn't seem to be a default Emacs screenshot?  The menu-bar is
> different.

For that I ran emacs -Q and took a screenshot.

>    I did some basic analysis with R (the language is a pain, but it's well
>    suited for quick stuff like this).
>
>    * Basic editor theme comparison
>
> Emacs doeesn't seem to be listed?

No, as I took your question to be "what are other editors doing?".
Is this correct?

> All the modes you show are programming modes, Emacs is more often than
> not used in other context so things like line-number-mode do not make
> much sense, like in the splash screen.
>
> Emacs doesn't treat everything as a nail.

Indeed! I love how Emacs now serves me as a common interface to a
variety of tasks, but the most frequent of those is as a code editor,
and I imagine it's code editing that brings most people to Emacs.

The only equivalent application to Emacs is ... Emacs (AFAIK), which
isn't terribly helpful for comparing and contrasting visual styles :P

I hope that helps,

Timothy.

p.s. for another weighting, I could also ask some friends (Under-25,
non-Emacsers) to rank these sample screenshots by aesthetic appeal. Just
a thought.

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   Alfred M. Szmidt <ams@gnu.org> writes:

   > Thank you, but I am not entierly sure what I am looking at -- the
   > Emacs you are showing is not from 1985.  What does the percentage
   > mean?

   Ah yes, a bit remiss of me not to state the format for my lablings:

    Editor --- Year of initial release (Stackoverflow 2019 survey, editor popularity)
    Screenshot of editor with default theme (trying for current)

Why is the initial release important?

   > All of those look similar to me, other than black/light background
   > when it comes to color selection.  There is I think very little
   > commonality between the edtiors in general in what they show.

   There are indeed many commonalities. However there are a few that Emacs
   doesn't share --- namely: dark default, bluey tones, line numbers, and a
   status bar that matches the background (in terms of background colour).
   Hmm, and also iconography on the status bar.

You are getting quite concrete -- you say "bluey tones" and how colors
match each other.  What does bluey tones mean?  Do you have a
suggestin how the mode-line could match the background better?

Dark vs. light default is not interesting, since I would assume that
the light theme would also have a "modern" appeal for users.

   >    * Basic editor theme comparison
   >
   > Emacs doeesn't seem to be listed?

   No, as I took your question to be "what are other editors doing?".
   Is this correct?

My question was what color and possibly font (to keep the list of
things small) differences exist between emacs and what some consider
modern coloring.

   I hope that helps,

Thank you, it does.  

   p.s. for another weighting, I could also ask some friends (Under-25,
   non-Emacsers) to rank these sample screenshots by aesthetic appeal. Just
   a thought.

I do not think such a metric would be useful, since it is so
subjective and very generic.  What would be useful is them pointing
out exactly what they think is "ugly" or "outdated" for a lack of
term.

Re: "modern" colors Re: Changes for emacs 28

[TEC]

Alfred M. Szmidt <ams@gnu.org> writes:

> Why is the initial release important?

I included this as the more modern editors (to me at least) seem to have
a different 'look' (subjective, culmination of visual factors).


> You are getting quite concrete -- you say "bluey tones" and how colors
> match each other.  What does bluey tones mean?  Do you have a
> suggestin how the mode-line could match the background better?

- Bluey :: I picked background tone colours and looked at the HSL value.
  If the Hue lay within the region of Blue, I designated the theme to be
  "Bluey". NB: Sublime and Intellij should have their 'Bluey' values
  swapped in the table I provided
- Status bas matching background :: When the colour lightness (HSL) is only
  slightly off the bacground, and the same colour. E.g. Emacs has a
  difference of 25, Atom has a difference of 4, IntelliJ 9, N++ 5.

> Dark vs. light default is not interesting, since I would assume that
> the light theme would also have a "modern" appeal for users.

Well, this seems relevant to the discussion as I assume editors chose
light/dark for a reason. In the case of companies like MS probably
market research.

> My question was what color and possibly font (to keep the list of
> things small) differences exist between emacs and what some consider
> modern coloring.

Font is harder, but one could look a bit more at the colours for sure.

If we start looking at colour palettes though, top themes on extension
marketplaces are probably relevant.

Let me know if there's anything else of interest,

Timothy.

Re: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 21:24 +03, TEC <tecosaur@gmail.com> wrote:
> #+RESULTS:
> | row.names                | mean | popularity weighted | age weighted |
> |--------------------------+------+---------------------+--------------|
> | DarkDefault              |  0.7 |                0.83 |          0.7 |
> | Bluey                    |  0.7 |                0.67 |         0.85 |
> | Line.Numbers             |  0.9 |                0.89 |            1 |
> | StatusBarMatchBackground |  0.8 |                0.62 |          0.8 |

Interesting indeed but comes with two major caveats:

- To what extent should we take popularity as an indication that a
  feature should be included in Emacs?

  Might as well be the case that the unique features of Emacs is what
  makes it stand out (mind that we’re directly communicating with a very
  little, opinionated sample of users here, inevitably).  We wouldn’t
  want to go the Firefox route.

- The sample size is pretty small for making any conclusions.

  And that may be inevitable given how little the population (editors
  people actually use) already is.

On a subjective note I think we’re exaggerating the role of Emacs’ looks
with regards to how it affects newcomers.  And it’s solved as easily as
M-x load-theme RET modus-vivendi RET post Emacs 28 (or some
point-release of 27 maybe?), or today with a simple package install.

What I wonder is how a change of default colours would affect other
themes, because AFAIU as it is we don’t have a clean situation where
each theme is independent of each other, but all of them depend on
default.  In which case fiddling with it means most smaller themes break
in one way or another.  Am I mistaken?

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

Re: "modern" colors Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
> On a subjective note I think we’re exaggerating the role of Emacs’ looks 
> with regards to how it affects newcomers.
>

Given the insane length of this thread (about 1000 emails so far), I think 
not.  Of course it's only "a very little, opinionated sample of users" as 
you write, but one user who takes the time to come here and to explain and 
defend their viewpoint is worth thousands other users who think the same 
but do not want to waste their time, and just switch to another editor.

>
> And it’s solved as easily as M-x load-theme RET modus-vivendi RET post 
> Emacs 28 (or some point-release of 27 maybe?), or today with a simple 
> package install.
>

Do you realize that what you write amounts to "In software A, B, C and D, 
to get what you want, click on this button.  In software E, to get what 
you want, it's very easy, just type "Zk1v31!*".  For them it's almost like 
a secret keystroke for an easter egg in a game.  How is a new user 
supposed to know that they should type M-x load-theme (or M-x 
customize-themes)? There is not even a menu entry for this (AFAICS).

Re: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

Tone down please.  I don’t know if (and don’t think that--, really) you
mean it but your replies come off as rather agressive.

On 2020-09-13 12:04 +03, Gregory Heytings <ghe@sdf.org> wrote:
>> On a subjective note I think we’re exaggerating the role of Emacs’
>> looks with regards to how it affects newcomers.
> Given the insane length of this thread (about 1000 emails so far), I
> think not.  Of course it's only "a very little, opinionated sample of
> users" as you write, but one user who takes the time to come here and
> to explain and defend their viewpoint is worth thousands other users
> who think the same but do not want to waste their time, and just
> switch to another editor.

There is no reason we believe that is the case, and no reason to
believe, even if that _is_ the case, that voices that _disagree_ with
you represent an identical or superior amount of users.

The length of the thread does not mean anything really.  Except that
we’re bikeshedding a bit, possibly.

>> And it’s solved as easily as M-x load-theme RET modus-vivendi RET
>> post Emacs 28 (or some point-release of 27 maybe?), or today with a
>> simple package install.
> Do you realize that what you write amounts to "In software A, B, C and
> D, to get what you want, click on this button.  In software E, to get
> what you want, it's very easy, just type "Zk1v31!*".  For them it's
> almost like a secret keystroke for an easter egg in a game.  How is a
> new user supposed to know that they should type M-x load-theme (or M-x
> customize-themes)? There is not even a menu entry for this (AFAICS).

I don’t realise such thing.  What I realise is, when I open VS Code, I
don’t see an option to change the theme in the menus.  Instead, I have
to find preferences (or learn that C-, opens it), notice that it’s
searchable, search for ‘theme’ (and also: know that it’s theme, not
colourcheme or similar), and select a theme.  I don’t see how that’s
easier, especially when we have in the menu bar "Options > Customize
Emacs > Custom Themes", and M-x customize-themes RET.  It’s the same
thing, rendered differently.  And in this particular instance Emacs is
better at it already.

You’re also engaging in reductio ad absurdum again which serves no-one.
The said commands are English words, not some random alphanumeric
sequence.


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

Re: "modern" colors Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


>
> I don’t know if (and don’t think that--, really) you mean it but your 
> replies come off as rather agressive.
>

That was not my intention.  I've just reread what I wrote, and I don't see 
what you find "rather agressive".  Though I admit that I was irritated by 
your "Someone who can't spare more than three minutes to research a tool 
that they may end up using for a life time for the majority of their 
workday is IMHO not a kind of user we should strive to support."

>>> And it’s solved as easily as M-x load-theme RET modus-vivendi RET post 
>>> Emacs 28 (or some point-release of 27 maybe?), or today with a simple 
>>> package install.
>
>> Do you realize that what you write amounts to "In software A, B, C and 
>> D, to get what you want, click on this button.  In software E, to get 
>> what you want, it's very easy, just type "Zk1v31!*".  For them it's 
>> almost like a secret keystroke for an easter egg in a game.  How is a 
>> new user supposed to know that they should type M-x load-theme (or M-x 
>> customize-themes)? There is not even a menu entry for this (AFAICS).
>
> I don’t realise such thing.  What I realise is, when I open VS Code, I 
> don’t see an option to change the theme in the menus. Instead, I have to 
> find preferences (or learn that C-, opens it), notice that it’s 
> searchable, search for ‘theme’ (and also: know that it’s theme, not 
> colourcheme or similar), and select a theme.  I don’t see how that’s 
> easier, especially when we have in the menu bar "Options > Customize 
> Emacs > Custom Themes", and M-x customize-themes RET.  It’s the same 
> thing, rendered differently.  And in this particular instance Emacs is 
> better at it already.
>

Please look again.  When you open VS Code for the first time, you have a 
big "Welcome" tab opened.  It contains four sections.  One of them is 
"Customize", and has three big buttons.  The third one is "Color theme".

Another section is "Help", with pointers to a cheatsheet, introductory 
videos, and so forth.

This "Welcome" tab will be shown every time you start VS Code, until you 
untick "Show welcome page on startup".

The proposal I sent on this list yesterday is to do something like this 
for Emacs.

Re: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-13 17:26 +03, Gregory Heytings <ghe@sdf.org> wrote:
> Please look again.  When you open VS Code for the first time, you have
> a big "Welcome" tab opened.  It contains four sections.  One of them
> is "Customize", and has three big buttons.  The third one is "Color
> theme".

I think that I haven’t seen it to this day is interesting.  Wonder if
there’s data / research on how effective these screens are.

> Another section is "Help", with pointers to a cheatsheet, introductory
> videos, and so forth.
>
> This "Welcome" tab will be shown every time you start VS Code, until
> you untick "Show welcome page on startup".
>
> The proposal I sent on this list yesterday is to do something like
> this for Emacs.

These are not things that I disagree.  Where we disagree is the effect
size of these, and I think you’re exaggerating the effects of the status
quo a bit.  Guess we’ll agree to disagree there.

Sorry if my tone was irritating / agressive at any time.

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

Re: "modern" colors Re: Changes for emacs 28

[Stefan Kangas]

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

> I think that I haven’t seen it to this day is interesting.  Wonder if
> there’s data / research on how effective these screens are.

We already have a splash/welcome screen.  The only question is if and
how it could be improved, AFAIU.

Re: "modern" colors Re: Changes for emacs 28

[Colin Baxter]

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

-------- 8  snip ---------

    > What I wonder is how a change of default colours would affect
    > other themes, because AFAIU as it is we don’t have a clean
    > situation where each theme is independent of each other, but all
    > of them depend on default.  In which case fiddling with it means
    > most smaller themes break in one way or another.  Am I mistaken?

I do not think you are mistaken. You have brought up an important point
that should not be ignored.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 01:02:54PM -0400, Alfred M. Szmidt wrote:
>
>   On Sat, Sep 12, 2020 at 10:52:37AM -0400, Alfred M. Szmidt wrote:

>Let me try to reiterate again, could you point out a handful of
>differences in colors and/or fonts (to keep it simple) between Emacs
>and some other editor (one is fine, several would be interesting too
>but I understand that can be taxing) that you find more modern than in
>Emacs?
>
You ask what is considered "modern". I just gave you some points. Then
you ask why and question the points.

Sorry I can't tell why people prefer blue or dark background today or
small icons or hamburger menus. I just know they like them and all the
editors more or less successful these days are all black/dark.

Maybe they prefer those because is what they see more frequently and
they get familiar with that or because white light burn their eyes.


>I do not understand what you are saying here.  You said that "adding
>an * to the filename" would solve an issue -- that is already done
>_today_ (and for decades in Emacs).
>
I sent some links in a previous mail with several modeline styles and
reimplementations. And said that all the distros (doom, spacemacs, etc)
start fully reimplementing the modeline (less text more icon and
colors). I use emacs from the terminal only, so the modeline will never
have icon or fancy helps for me. But I am not talking in my name. The *
in the name is just a detail most users are used to these days.

If most editors had a modeline with a -UU-:**--F1 at the beginning and
people prefer that and understand that; then will be perfect. But that's
not the case.

>
>And in Emacs we do it in a similar fashion.  I've seen that some put
>"modified" in the title bar, some show it differently -- indeed, I
>think every single editor I can think of does it differently.
>
If you can't see that out method is much more cryptic and oriented to
text; then ok. But don't ask me then what is modern or familiar for
users because this one is one of the most obvious. I never said it is
more or less functional... juts too old fashioned and unfamiliar.
>
>   Lock back in this same thread there was a long discussion about
>   that. The supporters of light colors brought some articles about
>   astigmatism and so on, while the others bring different ones.
>
>Yes, and there too it was asked about the background to this research
>-- and it too was underwhelming.
>
Whatever

>   This is actually what is being discussed. Any way just look at the
>   popular downloaded emacs themes the so called "distros", and the
>   actual "top" editors. Sourceforge is also kind of "old" as users
>   prefer github (which is actually working in a dark mode
>   too). Understand that I never said we should set dark themes by
>   default; I just replied what young developers consider "old".
>
>I know plenty of developers in their twenties that think that dark
>backgrounds are "old terminal backgrounds".  That is why I am asking
>for actual research, and not just your or my experience.  Downloads
>are not statistics.
>
If you have method to make a market study around will be perfect. I just
see that the application most users like are dark. Sublime, Atom,
VSCode and ClIon all of them bring the dark option and in my work
(around 300 programmers) most of the screens are dark. The proprietary
application that make market studies (like facebook) invested time and
resources creating a new interface with what now is considered "modern"
(clean icons, flat colors, not shadows, and dark theme)

Why people prefer dark today?. I don't know/care. 
>
>With source forges I meant in general, not Sourceforge specifically.
>
>And by your own accord, since some are only now working on dark-mode
>themes, it cannot have been such an important thing for them.  Doesn't
>this somewhat contradict the claim that this is the preference by the
>majority of people?
>
Preferences change with time. WinXP was pretty in it's time then the
menus became transparent and clear and now they are going back to flat
colors and corners. In 10 years maybe orange will be the new black. Or
google plays the color card as apple did with the white earphones.


>
>   It is missing only in gvim and emacs in my experience.
>
>I don't use that many programs, but don't forget xterm.
>
I am the only person I know personally still uses xterm. Most users I
know prefer gnome-terminal or terminator urxvt or xfce-terminal.

It is sat, but true. I actually use xterm only because of emacs
compatibility recommendation in this list some time ago. But xterm has
the similar problems.

In spite of it is probably the most powerful terminal around. The
defaults are terrible, copy text there is complex without a plugin and a
config, the default font is very tiny based in some system defaults, the
default colors are problematic and the right click doesn't work as in
the others. The config in Xdefaults has a weird syntax and some new
features are not available. Also the developer is very kind, but there
is not community or git repo for the developement. So xterm can't be
taken as an example these days.

>
>   So maybe 30 years ago it wasn't standard but today it is.
>
>Dare say that none of those programs existed 30 years ago, but you are
>confusing the behaviour of individual programs with the general
>behaviour of the system which I was refering to, and a historical
>context where the defaults where chosen.
>
I never complain for the reasons in a default; because usually they were
discussed and there are very good arguments for them. But the historical
arguments can't be the reason to keep everything unchanged and reject
new styles, ideas methods and general evolution. The arguments must be
based on user needs, preferences or technical.

RE: "modern" colors Re: Changes for emacs 28

[Drew Adams]

> I can't tell why people prefer blue or dark
> background today or small icons or hamburger
> menus.  I just know they like them and all
> the editors more or less successful these
> days are all black/dark.

Sigh.

> Preferences change with time. 

You said it yourself.

And preferences are individual.

Will _you_ implement new defaults for Emacs
in two years?  And then two years after that?
And so on?  Will you take care of Emacs,
keeping it always in fashion?  No lapses, now...

Each time carefully, scientifically measuring
the pulse of fashion or fad, to see what's
currently hot, and so what will be (currently)
"successful"?  No mistakes, now - be careful.

A generation or two breast-fed from marketing,
Big Data, social-media nipples.  This is where
we are.

Everyone wants to be sure to be seen wearing,
using, and saying only the latest and coolest
things, as defined by...  Look at me, Ma!

"Likes" rule.  Not in Emacs; not yet anyway.

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

   >Let me try to reiterate again, could you point out a handful of
   >differences in colors and/or fonts (to keep it simple) between Emacs
   >and some other editor (one is fine, several would be interesting too
   >but I understand that can be taxing) that you find more modern than in
   >Emacs?

   You ask what is considered "modern". I just gave you some points. Then
   you ask why and question the points.

You told me to "go look it up".  I do not know what to look up, you
gave a multitude of links and it is unrealistic for me to look at each
one and understand what the point you are trying to make is.

You made the claim that there where some minor differences in colors
that could make Emacs more modern -- I'd like to understand what those
minor differences are exactly.  This should be easy enough to document
for some points and not tell someone to go for a goose chase (or is it
beef chase to make hamburgers?).

The question here isn't the preference of blue or dark, it is what you
found more modern specifically.

Re: "modern" colors Re: Changes for emacs 28

[Caio Henrique]

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

I like using a light theme during the day and a dark theme during the
night when I'm in a dark room. I use a function to toggle between those
two different themes. Here is some code based on my personal
configuration:

_____
(defun toggle-light-dark-theme--custom-choices (theme)
  "Function used to create the choice widget options of the
toggle-light-dark-theme custom variables."
  `(const :tag ,(symbol-name theme) ,theme))

(defcustom toggle-light-dark-theme-light-theme 'modus-operandi
  "The light theme that the function toggle-light-dark-theme will use."
  :type `(choice ,@(mapcar #'toggle-light-dark-theme--custom-choices
		    (custom-available-themes))))

(defcustom toggle-light-dark-theme-dark-theme 'tango-dark
  "The dark theme that the function toggle-light-dark-theme will use."
  :type `(choice ,@(mapcar #'toggle-light-dark-theme--custom-choices
		    (custom-available-themes))))

(defvar toggle-light-dark-theme--current-theme 'light)

(defun toggle-light-dark-theme ()
  "Disables all custom enabled themes and then toggles between a
light and a dark theme, which are the values of the variables
toggle-light-dark-theme-light-theme and toggle-light-dark-theme-dark-theme."
  (interactive)
  (mapc #'disable-theme custom-enabled-themes)
  (cond ((eq toggle-light-dark-theme--current-theme 'light)
	 (load-theme toggle-light-dark-theme-dark-theme)
	 (setq toggle-light-dark-theme--current-theme 'dark))
	(t (load-theme toggle-light-dark-theme-light-theme)
	   (setq toggle-light-dark-theme--current-theme 'light))))
_____

Maybe we could use something like this and then add buttons to the menu
and the tool bar? The tool bar could use an icon like the image
attached (the image is just illustrative, it probably has copyright).


[-- Attachment #2: toggle light dark icon --]
[-- Type: image/png, Size: 354785 bytes --]

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



This way, there is no need to change the default theme :).

toggle-light-dark-mode (was: Re: "modern" colors Re: Changes for emacs 28)

[Alfred M. Szmidt]

[Tip, it is a good idea to change the subject!]

   I like using a light theme during the day and a dark theme during the
   night when I'm in a dark room. I use a function to toggle between those
   two different themes. Here is some code based on my personal
   configuration:

   _____
   (defun toggle-light-dark-theme--custom-choices (theme)
     "Function used to create the choice widget options of the
   toggle-light-dark-theme custom variables."
     `(const :tag ,(symbol-name theme) ,theme))

   (defcustom toggle-light-dark-theme-light-theme 'modus-operandi
     "The light theme that the function toggle-light-dark-theme will use."
     :type `(choice ,@(mapcar #'toggle-light-dark-theme--custom-choices
		       (custom-available-themes))))

   (defcustom toggle-light-dark-theme-dark-theme 'tango-dark
     "The dark theme that the function toggle-light-dark-theme will use."
     :type `(choice ,@(mapcar #'toggle-light-dark-theme--custom-choices
		       (custom-available-themes))))

   (defvar toggle-light-dark-theme--current-theme 'light)

   (defun toggle-light-dark-theme ()
     "Disables all custom enabled themes and then toggles between a
   light and a dark theme, which are the values of the variables
   toggle-light-dark-theme-light-theme and toggle-light-dark-theme-dark-theme."
     (interactive)
     (mapc #'disable-theme custom-enabled-themes)
     (cond ((eq toggle-light-dark-theme--current-theme 'light)
	    (load-theme toggle-light-dark-theme-dark-theme)
	    (setq toggle-light-dark-theme--current-theme 'dark))
	   (t (load-theme toggle-light-dark-theme-light-theme)
	      (setq toggle-light-dark-theme--current-theme 'light))))
   _____

   Maybe we could use something like this and then add buttons to the menu
   and the tool bar? The tool bar could use an icon like the image
   attached (the image is just illustrative, it probably has copyright).

This looks like a good idea.

I think something in the tool-bar is a bit much, I don't think it is
the most used option that should that have such a high visibility --
rather I think users would like to toggle it once, so the menu-bar
would be a better place where the user would also be prompt to save
their settings if they quit emacs.

Would you like to purpose a patch for this?

Re: toggle-light-dark-mode

[Caio Henrique]

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

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

> [Tip, it is a good idea to change the subject!]
>
>    I like using a light theme during the day and a dark theme during the
>    night when I'm in a dark room. I use a function to toggle between those
>    two different themes. Here is some code based on my personal
>    configuration:
>
>    _____
>   [ ... ]
>    _____
>
>    Maybe we could use something like this and then add buttons to the menu
>    and the tool bar? The tool bar could use an icon like the image
>    attached (the image is just illustrative, it probably has copyright).
>
> This looks like a good idea.
>
> I think something in the tool-bar is a bit much, I don't think it is
> the most used option that should that have such a high visibility --
> rather I think users would like to toggle it once, so the menu-bar
> would be a better place where the user would also be prompt to save
> their settings if they quit emacs.
>
> Would you like to purpose a patch for this?

Ok, I tried to improve that code, a patch is attached.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Add toggle light dark theme --]
[-- Type: text/x-patch, Size: 3653 bytes --]

diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index ef04689f4c..243f0db151 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -645,6 +645,9 @@ menu-bar-custom-menu
     (bindings--define-key menu [customize]
       '(menu-item "Top-level Customization Group" customize
                   :help "The master group called `Emacs'"))
+    (bindings--define-key menu [toggle-light-dark-theme]
+      '(menu-item "Toggle Light Dark Theme" toggle-light-dark-theme
+                  :help "Toggle light dark theme"))
     (bindings--define-key menu [customize-themes]
       '(menu-item "Custom Themes" customize-themes
                   :help "Choose a pre-defined customization theme"))
diff --git a/lisp/toggle-light-dark-theme.el b/lisp/toggle-light-dark-theme.el
new file mode 100644
index 0000000000..29966c7c9b
--- /dev/null
+++ b/lisp/toggle-light-dark-theme.el
@@ -0,0 +1,73 @@
+;;; toggle-light-dark-theme.el -- Toggle dark and light theme  -*- lexical-binding: t -*-
+;;
+;; Copyright (C) 2020 Free Software Foundation, Inc.
+;;
+;; Author: Caio Henrique <caio.hcs0@gmail.com>
+;; Maintainer: emacs-devel@gnu.org
+;; Keywords: faces
+;; Package: emacs
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; This file provides a function to toggle between a light and a dark
+;; theme, the two themes can be specified with customize-option, the
+;; function is added to the menu bar.
+
+;;; Code:
+
+(defgroup toggle-light-dark-theme nil
+  "Toggle light dark theme"
+  :group 'faces)
+
+(defun toggle-light-dark-theme--custom-choices (theme)
+  "Used to create the choice widget options of the
+toggle-light-dark-theme custom variables."
+  `(const :tag ,(symbol-name theme) ,theme))
+
+(defcustom toggle-light-dark-theme-light-theme 'modus-operandi
+  "The light theme used by the function `toggle-light-dark-theme'."
+  :group 'toggle-light-dark-theme
+  :type `(choice ,@(mapcar #'toggle-light-dark-theme--custom-choices
+			   (custom-available-themes))))
+
+(defcustom toggle-light-dark-theme-dark-theme 'tango-dark
+  "The dark theme used by the function `toggle-light-dark-theme'."
+  :group 'toggle-light-dark-theme
+  :type `(choice ,@(mapcar #'toggle-light-dark-theme--custom-choices
+			   (custom-available-themes))))
+
+(defvar toggle-light-dark-theme--current-theme 'light)
+
+;;;###autoload
+(defun toggle-light-dark-theme ()
+  "Disables all custom enabled themes and then toggles between a
+light and a dark theme, which are the values of the variables
+`toggle-light-dark-theme-light-theme' and
+`toggle-light-dark-theme-dark-theme'."
+  (interactive)
+  (mapc #'disable-theme custom-enabled-themes)
+  (cond ((eq toggle-light-dark-theme--current-theme 'light)
+	 (load-theme toggle-light-dark-theme-dark-theme)
+	 (setq toggle-light-dark-theme--current-theme 'dark))
+	(t
+	 (load-theme toggle-light-dark-theme-light-theme)
+	 (setq toggle-light-dark-theme--current-theme 'light))))
+
+(provide 'toggle-light-dark-theme)
+
+;;; toggle-light-dark-theme.el ends here

Re: toggle-light-dark-mode

[Juri Linkov]

>> [Tip, it is a good idea to change the subject!]
>>
>>    I like using a light theme during the day and a dark theme during the
>>    night when I'm in a dark room. I use a function to toggle between those
>>    two different themes. Here is some code based on my personal
>>    configuration:
>>
>>    _____
>>   [ ... ]
>>    _____
>>
>>    Maybe we could use something like this and then add buttons to the menu
>>    and the tool bar? The tool bar could use an icon like the image
>>    attached (the image is just illustrative, it probably has copyright).
>>
>> This looks like a good idea.
>>
>> I think something in the tool-bar is a bit much, I don't think it is
>> the most used option that should that have such a high visibility --
>> rather I think users would like to toggle it once, so the menu-bar
>> would be a better place where the user would also be prompt to save
>> their settings if they quit emacs.
>>
>> Would you like to purpose a patch for this?
>
> Ok, I tried to improve that code, a patch is attached.

But the theme can be toggled from light to dark using the command
line switch --reverse-video, -r, -rv, or with the frame parameter
'background-mode' that can be either 'dark' or 'light', and the
user selected theme should support both modes.  Then toggling can be
automatic:

(defvar my-sunset-timer nil)
(defvar my-sunrise-timer nil)

(defun toggle-light-dark-mode (&optional frame)
  "Automatically switch to dark background after sunset
and to light background after sunrise.
(Note that `calendar-latitude' and `calendar-longitude'
should be set before calling the `solar-sunrise-sunset')."
  (interactive)
  (require 'solar)
  (if (and (bound-and-true-p calendar-latitude)
           (bound-and-true-p calendar-longitude)
           (bound-and-true-p calendar-time-zone))
      (let* ((l (solar-sunrise-sunset (calendar-current-date)))
             (sunrise-string (apply 'solar-time-string (car l)))
             (sunset-string (apply 'solar-time-string (car (cdr l))))
             (current-time-string (format-time-string "%H:%M")))
        (if (or (string-lessp current-time-string sunrise-string)
                (string-lessp sunset-string current-time-string))
            (toggle-dark-mode frame)
          (toggle-light-mode frame))
        (if (and (boundp 'my-sunset-timer)  (timerp my-sunset-timer))
            (cancel-timer my-sunset-timer))
        (if (and (boundp 'my-sunrise-timer) (timerp my-sunrise-timer))
            (cancel-timer my-sunrise-timer))
        (setq my-sunset-timer  (run-at-time sunset-string  (* 60 60 24)
                                            'toggle-dark-mode))
        (setq my-sunrise-timer (run-at-time sunrise-string (* 60 60 24)
                                            'toggle-light-mode)))))

(add-hook 'after-make-frame-functions 'toggle-light-dark-mode)

(defun my-colors-light (&optional frame)
  "Set colors suitable for working in light environments,
i.e. in daylight or under bright electric lamps."
  (interactive)
  (setq frame-background-mode 'light)
  (modify-frame-parameters nil (list (cons 'background-mode 'light)))
  ;; The color with minimal eye fatigue in light environments
  ;; is "AntiqueWhite3" (RGB: 205 192 176),
  ;; (set-background-color "AntiqueWhite3")
)

(defun my-colors-dark (&optional frame)
  "Set colors suitable for working in the darkness without electricity."
  (interactive)
  (setq frame-background-mode 'dark)
  (modify-frame-parameters nil (list (cons 'background-mode 'dark))))

Re: toggle-light-dark-mode

[Caio Henrique]

Juri Linkov <juri@linkov.net> writes:

>   "Automatically switch to dark background after sunset
> and to light background after sunrise.

Personally I don't find this very useful, since most of the time the
lights in my room are turned on during the night. I only call that
function when I turn my lights off.

I don't know any applications that have that kind of behavior enabled by
default, since it's a bit intrusive.

But I think that it would be a great optional feature (i.e. disabled by
default) for those that are into it.

> But the theme can be toggled from light to dark using the command
> line switch --reverse-video, -r, -rv, or with the frame parameter

Maybe this could also be an optional alternative behavior that you can
enable with a boolean variable? toggle-light-dark-theme-use-reverse-video

I like your suggestions and I can see that they appeal to other users,
but personally I also wouldn't use reverse video (I like using
kaolin-galaxy as my dark theme and modus-operandi for my light theme).

Or we could also do the inverse: use the behavior of your code by
default and make mine optional.  :)

Re: toggle-light-dark-mode

[Juri Linkov]

>>   "Automatically switch to dark background after sunset
>> and to light background after sunrise.
>
> Personally I don't find this very useful, since most of the time the
> lights in my room are turned on during the night. I only call that
> function when I turn my lights off.
>
> I don't know any applications that have that kind of behavior enabled by
> default, since it's a bit intrusive.

For example, GPS navigation apps switch to night mode automatically on sunset.

> But I think that it would be a great optional feature (i.e. disabled by
> default) for those that are into it.

I agree.

>> But the theme can be toggled from light to dark using the command
>> line switch --reverse-video, -r, -rv, or with the frame parameter
>
> Maybe this could also be an optional alternative behavior that you can
> enable with a boolean variable? toggle-light-dark-theme-use-reverse-video
>
> I like your suggestions and I can see that they appeal to other users,
> but personally I also wouldn't use reverse video (I like using
> kaolin-galaxy as my dark theme and modus-operandi for my light theme).
>
> Or we could also do the inverse: use the behavior of your code by
> default and make mine optional.  :)

Actually my point was that the default Emacs faces support both modes:
dark and light, so you can use the same default theme in different modes,
just by toggling frame-background-mode.  This is implemented by using
'(background dark)' and '(background light)' in defface definitions.

I wonder why other themes don't support both modes?  For example, why there
is separate light tango-theme and tango-dark-theme, but not one tango-theme
supporting dark and light modes?  And why separate light modus-operandi-theme
and dark modus-vivendi-theme, but not one modus-theme with both modes?

Re: toggle-light-dark-mode

[Protesilaos Stavrou]

Juri Linkov <juri@linkov.net> [2020-09-16, 22:31 +0300]:

>> Maybe this could also be an optional alternative behavior that you can
>> enable with a boolean variable? toggle-light-dark-theme-use-reverse-video
>>
>> I like your suggestions and I can see that they appeal to other users,
>> but personally I also wouldn't use reverse video (I like using
>> kaolin-galaxy as my dark theme and modus-operandi for my light theme).
>>
>> Or we could also do the inverse: use the behavior of your code by
>> default and make mine optional.  :)
>
> Actually my point was that the default Emacs faces support both modes:
> dark and light, so you can use the same default theme in different modes,
> just by toggling frame-background-mode.  This is implemented by using
> '(background dark)' and '(background light)' in defface definitions.
>
> I wonder why other themes don't support both modes?  For example, why there
> is separate light tango-theme and tango-dark-theme, but not one tango-theme
> supporting dark and light modes?  And why separate light modus-operandi-theme
> and dark modus-vivendi-theme, but not one modus-theme with both modes?

Indeed, defface already provides the means to account for different
display specs.

Concerning the Modus themes' question, I simply did not know any better
~1 year ago when I started the project.  The tango themes where my point
of reference.  Also, and if my memory serves me well, the command
customize-create-theme did not account for light/dark variants.

Going forward, it may be preferable to follow your suggestion.


-- 
Protesilaos Stavrou
protesilaos.com

Re: toggle-light-dark-mode

[Juri Linkov]

>> Actually my point was that the default Emacs faces support both modes:
>> dark and light, so you can use the same default theme in different modes,
>> just by toggling frame-background-mode.  This is implemented by using
>> '(background dark)' and '(background light)' in defface definitions.
>>
>> I wonder why other themes don't support both modes?  For example, why there
>> is separate light tango-theme and tango-dark-theme, but not one tango-theme
>> supporting dark and light modes?  And why separate light modus-operandi-theme
>> and dark modus-vivendi-theme, but not one modus-theme with both modes?
>
> Indeed, defface already provides the means to account for different
> display specs.
>
> Concerning the Modus themes' question, I simply did not know any better
> ~1 year ago when I started the project.  The tango themes where my point
> of reference.  Also, and if my memory serves me well, the command
> customize-create-theme did not account for light/dark variants.

But maybe there is some reason for having separate light and dark themes?
Maybe for users it's not easy to toggle light/dark mode in the same theme?
For example, when a user selects a theme while in the light mode, and wants
to activate its dark mode.  It seems there is no simple command to do that.

Re: toggle-light-dark-mode

[Stefan Monnier]

>> I wonder why other themes don't support both modes?  For example, why there
>> is separate light tango-theme and tango-dark-theme, but not one tango-theme
>> supporting dark and light modes?  And why separate light modus-operandi-theme
>> and dark modus-vivendi-theme, but not one modus-theme with both modes?
> Indeed, defface already provides the means to account for different
> display specs.
[...]
> Going forward, it may be preferable to follow your suggestion.

Yes and no: I'm not sure the end users will really care for a two-step
choice of theme where they first need to choose a theme and then
figure out how on earth to switch from the dark version to the light or
vice-versa.

The background-mode feature of face-specs is very useful for the default
face settings to work well regardless of the choice of
foreground/background for the `default` face and that's important when
that face's default is inherited from external settings (like Gtk or
Xresources).

But in the case of modus-themes, the default face's color is chosen by
the theme, so it doesn't make much sense to say "if the default face
looks like this, do one thing otherwise do another" since we already
know what the default face looks like.


        Stefan

Re: toggle-light-dark-mode

[Arthur Miller]

Juri Linkov <juri@linkov.net> writes:

> I wonder why other themes don't support both modes?  For example, why there
> is separate light tango-theme and tango-dark-theme, but not one tango-theme
> supporting dark and light modes?  And why separate light modus-operandi-theme
> and dark modus-vivendi-theme, but not one modus-theme with both modes?

It is not easy to define a set of colors that go well with each other in
inverted scenario, especially if you would like to obey some other
criteria, like say equal contrast (as in Solarized) or very low-, high
contrast. Personally I don't think every theme need to have both, since
not everyone is switching their themes based on dayoftime.

By the way, the code you posted in another message is interested. Wonder
if one could get some input from a webcam, analyze light intensity and
switch dark/light Emacs or even pick theme shades based on the image
recorded; similar as they do here

https://github.com/makuto/auto-base16-theme

It would be a bit like modern TVs with background LED lightning; no idea
if it would be usable at all; but fun? :-)

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

Ergus <spacibba@aol.com> writes:

>>New users don't have to understand it from the start though, it is
>>something one can come to understand with using Emacs.  If you hover
>>with the mouse over each item, it will describe what each thing means,
>>and you can change each thing accordingly.
>>
> New users are used to know if the document has changes at least. And in
> the applications they use: filename* by default.

We have buffers that end on “*”, such as “*scratch*”, “*shell*” (M-x
shell), “*mu4e-view*”, etc.  Emacs can display graphics and/or Unicode
characters; it doesn’t need to follow a convention here other than to
provide *some* indication of a changed buffer.

The modeline already separately indicates a changed buffer with “*” (and
another “*” to indicate that the buffer is writable).  Modeline themes
such as the excellent smart-mode-line display a coloured Unicode
character instead (a vertically centered cross), which works just as
well.

>>   3) Colors: People prefer higher contrast in general 4 example: in my
>>   system when the region es enabled the default gray color is so light
>>   that I can't see it. Same applies to icon that when enabled or disabled
>>   the difference sometimes is minimal.
>>
>>Can you provide research on that people do actually prefer higher
>>contrast in general?  Your example doesn't really follow from the
>>first claim -- since that is your specific preference, not everyone
>>elses preference.
>>
> Lock back in this same thread there was a long discussion about
> that. The supporters of light colors brought some articles about
> astigmatism and so on, while the others bring different ones.
>
> Again look around and compare what you see.

None of the articles AFAIR talked about *high* contrast; many user
interface guidelines and accessibility recommendations do recommend
sufficient contrast (sometimes quantified as a minimum contrast between
two colours), but this doesn’t mean that higher contrast is always
better than lower contrast.

The Solarized colour palette, for example, aims to provide *equal*
contrast, but is agnostic on exactly how high the contrast threshold
should be (in some implementations of the theme the contrast threshold
can trivially be adjusted).

Back to the original claim: I cannot reproduce the problem in “emacs
-Q”; when I activate the region the background and foreground colours of
the text in the region are swapped, providing the same contrast as when
the region is not active.

-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

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

>Back to the original claim: I cannot reproduce the problem in “emacs
>-Q”; when I activate the region the background and foreground colours of
>the text in the region are swapped, providing the same contrast as when
>the region is not active.
>
Look the attachment.

The second line is selected
>-- 
>Ricardo

[-- Attachment #2: Screenshot_2020-09-12_21-51-25.png --]
[-- Type: image/png, Size: 14968 bytes --]

Re: "modern" colors Re: Changes for emacs 28

[Caio Henrique]

Ergus <spacibba@aol.com> writes:

>>Back to the original claim: I cannot reproduce the problem in “emacs
>>-Q”; when I activate the region the background and foreground colours of
>>the text in the region are swapped, providing the same contrast as when
>>the region is not active.
>>
> Look the attachment.
>
> The second line is selected
>> -- Ricardo

It depends on your monitor. On my LG monitor I can see it fine; but it's
almost impossible to see it on my Lenovo screen.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 04:59:51PM -0300, Caio Henrique wrote:
>Ergus <spacibba@aol.com> writes:
>
>>>Back to the original claim: I cannot reproduce the problem in “emacs
>>>-Q”; when I activate the region the background and foreground colours of
>>>the text in the region are swapped, providing the same contrast as when
>>>the region is not active.
>>>
>> Look the attachment.
>>
>> The second line is selected
>>> -- Ricardo
>
>It depends on your monitor. On my LG monitor I can see it fine; but it's
>almost impossible to see it on my Lenovo screen.
>
This is bad, because I have 3 different monitors right now and I can't
see the region in any of them (hp, samsung and dell) :(

Re: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 22:59 +03, Caio Henrique <caiohcs0@gmail.com> wrote:
> Ergus <spacibba@aol.com> writes:
>> The second line is selected
> It depends on your monitor. On my LG monitor I can see it fine; but it's
> almost impossible to see it on my Lenovo screen.

Depends also on your desktop.  That colour comes from your desktop.  I
just switched my desktops theme to dark and opened ‘emacs -q’, the
highlight’s background is black.

FWIW Emacs’ default theme should have a preference here, given the rest
of the colours do not really depend on the toolkit theme.

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

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

Ergus <spacibba@aol.com> writes:

>>Back to the original claim: I cannot reproduce the problem in “emacs
>>-Q”; when I activate the region the background and foreground colours of
>>the text in the region are swapped, providing the same contrast as when
>>the region is not active.
>>
> Look the attachment.
>
> The second line is selected

Interesting!  In my Emacs the background of the selection is close to
black, so for typed text that’s fine, but it’s indeed sub-optimal when
selecting the red comment text.  Perhaps the difference is because I set
up a dark GTK theme (the toolbar has a dark background, for example).

-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> Date: Sat, 12 Sep 2020 22:13:30 +0200
> Cc: casouri@gmail.com, emacs-devel@gnu.org, "Alfred M. Szmidt" <ams@gnu.org>,
>  monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
> 
> Interesting!  In my Emacs the background of the selection is close to
> black, so for typed text that’s fine, but it’s indeed sub-optimal when
> selecting the red comment text.  Perhaps the difference is because I set
> up a dark GTK theme (the toolbar has a dark background, for example).

The behavior you have on your system isn't the Emacs default: we don't
invert colors to display the region, we only specify a different
background color (see the default definition of the 'region' face).

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ricardo Wurmus <rekado@elephly.net>
>> Date: Sat, 12 Sep 2020 22:13:30 +0200
>> Cc: casouri@gmail.com, emacs-devel@gnu.org, "Alfred M. Szmidt" <ams@gnu.org>,
>>  monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
>> 
>> Interesting!  In my Emacs the background of the selection is close to
>> black, so for typed text that’s fine, but it’s indeed sub-optimal when
>> selecting the red comment text.  Perhaps the difference is because I set
>> up a dark GTK theme (the toolbar has a dark background, for example).
>
> The behavior you have on your system isn't the Emacs default: we don't
> invert colors to display the region, we only specify a different
> background color (see the default definition of the 'region' face).

I’m used “emacs -Q” and I’m on Guix where we don’t patch Emacs to have
different defaults.  I also have nothing in my .Xdefaults or .Xresources
that should affect Emacs.

-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> Cc: spacibba@aol.com, casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org,
>  monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
> Date: Sun, 13 Sep 2020 18:22:11 +0200
> 
> > The behavior you have on your system isn't the Emacs default: we don't
> > invert colors to display the region, we only specify a different
> > background color (see the default definition of the 'region' face).
> 
> I’m used “emacs -Q” and I’m on Guix where we don’t patch Emacs to have
> different defaults.  I also have nothing in my .Xdefaults or .Xresources
> that should affect Emacs.

Then it's a mystery only you can solve.  Look at the definition of the
'region' face in faces.el: the only case where we use :inverse-video
is on monochrome TTYs.  If that is not your case, then I don't know
how to explain the fact that you see the region in reverse video.  I
guess I'm missing something, but what?

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ricardo Wurmus <rekado@elephly.net>
>> Cc: spacibba@aol.com, casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org,
>>  monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
>> Date: Sun, 13 Sep 2020 18:22:11 +0200
>> 
>> > The behavior you have on your system isn't the Emacs default: we don't
>> > invert colors to display the region, we only specify a different
>> > background color (see the default definition of the 'region' face).
>> 
>> I’m used “emacs -Q” and I’m on Guix where we don’t patch Emacs to have
>> different defaults.  I also have nothing in my .Xdefaults or .Xresources
>> that should affect Emacs.
>
> Then it's a mystery only you can solve.  Look at the definition of the
> 'region' face in faces.el: the only case where we use :inverse-video
> is on monochrome TTYs.  If that is not your case, then I don't know
> how to explain the fact that you see the region in reverse video.  I
> guess I'm missing something, but what?

The ’region’ face has these settings:

  DistantForeground: gtk_selection_fg_color
         Background: gtk_selection_bg_color

I switch to a light GTK theme and run Emacs:

  $ dconf write /org/gnome/desktop/interface/gtk-theme "'Adwaita'"
  $ emacs -Q

Now the selected region has a light gray background.

I switch to a dark GTK theme and run Emacs:

  $ dconf write /org/gnome/desktop/interface/gtk-theme "'Adwaita-dark'"
  $ emacs -Q

Now the selected region has a very dark background and the text is
bright.

I suppose that’s exactly what gtk_selection_bg_color and
gtk_selection_fg_color are supposed to do: take the colours from the GTK
theme.

On Guix we build Emacs with the GTK toolkit.

-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

> I suppose that’s exactly what gtk_selection_bg_color and
> gtk_selection_fg_color are supposed to do: take the colours from the GTK
> theme.
>
> On Guix we build Emacs with the GTK toolkit.

So the bug is that we obey the "external" settings for the region but
apparently not for the `default` face.


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

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

>> I suppose that’s exactly what gtk_selection_bg_color and
>> gtk_selection_fg_color are supposed to do: take the colours from the GTK
>> theme.
>>
>> On Guix we build Emacs with the GTK toolkit.
>
> So the bug is that we obey the "external" settings for the region but
> apparently not for the `default` face.

There’s also a colour clash with the font-lock-comment-face and the
region when gtk_selection_bg_color happens to be dark (dark red on
black).

Perhaps it’s a mistake to obey external colour settings at all, when we
can only do it partially anyway.


-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sun, Sep 13, 2020 at 11:43:11PM +0200, Ricardo Wurmus wrote:
>
>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I suppose that’s exactly what gtk_selection_bg_color and
>>> gtk_selection_fg_color are supposed to do: take the colours from the GTK
>>> theme.
>>>
>>> On Guix we build Emacs with the GTK toolkit.
>>
>> So the bug is that we obey the "external" settings for the region but
>> apparently not for the `default` face.
>
>There’s also a colour clash with the font-lock-comment-face and the
>region when gtk_selection_bg_color happens to be dark (dark red on
>black).
>
>Perhaps it’s a mistake to obey external colour settings at all, when we
>can only do it partially anyway.
>
>
>-- 
>Ricardo


A bit offtopic but related with fontlock.

Using vim today (Don't judge me) I noticed that they fortify escape
sequences and numbers (I mentioned this last one before). Could we have
that? please please.

There is a highlight numbers package but it breaks my cmake-fontlock-mode.

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

> Using vim today (Don't judge me) I noticed that they fortify escape
> sequences and numbers (I mentioned this last one before).

You mean they add a strong alcohol to them?


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Lars Ingebrigtsen]

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

>> Using vim today (Don't judge me) I noticed that they fortify escape
>> sequences and numbers (I mentioned this last one before).
>
> You mean they add a strong alcohol to them?

I think it means that vim puts a wall around the escape sequences.

And then serves the port.  Sounds sensible.

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

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sun, Sep 13, 2020 at 11:43:11PM +0200, Ricardo Wurmus wrote:
>
>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I suppose that’s exactly what gtk_selection_bg_color and
>>> gtk_selection_fg_color are supposed to do: take the colours from the GTK
>>> theme.
>>>
>>> On Guix we build Emacs with the GTK toolkit.
>>
>> So the bug is that we obey the "external" settings for the region but
>> apparently not for the `default` face.
>
>There’s also a colour clash with the font-lock-comment-face and the
>region when gtk_selection_bg_color happens to be dark (dark red on
>black).
>
>Perhaps it’s a mistake to obey external colour settings at all, when we
>can only do it partially anyway.
>
>
>-- 
>Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

>>> I suppose that’s exactly what gtk_selection_bg_color and
>>> gtk_selection_fg_color are supposed to do: take the colours from the GTK
>>> theme.
>>> On Guix we build Emacs with the GTK toolkit.
>> So the bug is that we obey the "external" settings for the region but
>> apparently not for the `default` face.
> There’s also a colour clash with the font-lock-comment-face and the
> region when gtk_selection_bg_color happens to be dark (dark red on
> black).

Most faces have two settings depending on whether the default background
id dark or light, so as long as we don't get the right default
background color, your region face (which assumes a dark background)
will likely clash with many other faces (which assume a light background).

> Perhaps it’s a mistake to obey external colour settings at all, when we
> can only do it partially anyway.

It's definitely a mistake to do it for a non-default face like
`region` when we don't do it for `default`, indeed.

Our faces are normally setup to work reasonably well with "any" sane
default foreground/background (by choosing between the dark and the
light "theme" based on the color of the default background), so I don't
think it would be a mistake to obey external color settings for the
default face.


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

> Most faces have two settings depending on whether the default background
> id dark or light, so as long as we don't get the right default
> background color, your region face (which assumes a dark background)
                                            ^^^^^^^
                                            presumes
> will likely clash with many other faces (which assume a light background).
                                                 ^^^^^^
                                                 presume
Damn French!


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com, casouri@gmail.com,
>  emacs-devel@gnu.org, ams@gnu.org, ghe@sdf.org, tecosaur@gmail.com
> Date: Sun, 13 Sep 2020 23:43:11 +0200
> 
> Perhaps it’s a mistake to obey external colour settings at all, when we
> can only do it partially anyway.

But is it certain that we can only do a partial job here?  I don't
think so, and the fact that we succeed in producing good results on
other platforms is evidence to that.

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ricardo Wurmus <rekado@elephly.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com, casouri@gmail.com,
>>  emacs-devel@gnu.org, ams@gnu.org, ghe@sdf.org, tecosaur@gmail.com
>> Date: Sun, 13 Sep 2020 23:43:11 +0200
>> 
>> Perhaps it’s a mistake to obey external colour settings at all, when we
>> can only do it partially anyway.
>
> But is it certain that we can only do a partial job here?  I don't
> think so, and the fact that we succeed in producing good results on
> other platforms is evidence to that.

If we set the region colour according to the GTK colour theme we would
need to make sure that none of the other faces use a colour that would
be hard to distinguish from the region colour.  To do a complete job
would require to set the colours in *all* faces according to the GTK
colour theme.

Just the default colour will do nothing to remove the colour clash
between e.g. font-lock-comment-face and the region colour.

-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

> Just the default colour will do nothing to remove the colour clash
> between e.g. font-lock-comment-face and the region colour.

But this same problem will affect several other applications rather than
only Emacs, so it's basically "the user's problem".


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> Cc: monnier@iro.umontreal.ca, spacibba@aol.com, casouri@gmail.com,
>  emacs-devel@gnu.org, ams@gnu.org, ghe@sdf.org, tecosaur@gmail.com
> Date: Mon, 14 Sep 2020 18:45:19 +0200
> 
> > But is it certain that we can only do a partial job here?  I don't
> > think so, and the fact that we succeed in producing good results on
> > other platforms is evidence to that.
> 
> If we set the region colour according to the GTK colour theme we would
> need to make sure that none of the other faces use a colour that would
> be hard to distinguish from the region colour.  To do a complete job
> would require to set the colours in *all* faces according to the GTK
> colour theme.
> 
> Just the default colour will do nothing to remove the colour clash
> between e.g. font-lock-comment-face and the region colour.

How is this different from other platforms we support?  This stuff
does work there.  It works because, as Stefan points out, Emacs adapts
its face colors to the background color of the default face: we have
separate sets of colors for light and dark backgrounds.

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ricardo Wurmus <rekado@elephly.net>
>> Cc: monnier@iro.umontreal.ca, spacibba@aol.com, casouri@gmail.com,
>>  emacs-devel@gnu.org, ams@gnu.org, ghe@sdf.org, tecosaur@gmail.com
>> Date: Mon, 14 Sep 2020 18:45:19 +0200
>> 
>> > But is it certain that we can only do a partial job here?  I don't
>> > think so, and the fact that we succeed in producing good results on
>> > other platforms is evidence to that.
>> 
>> If we set the region colour according to the GTK colour theme we would
>> need to make sure that none of the other faces use a colour that would
>> be hard to distinguish from the region colour.  To do a complete job
>> would require to set the colours in *all* faces according to the GTK
>> colour theme.
>> 
>> Just the default colour will do nothing to remove the colour clash
>> between e.g. font-lock-comment-face and the region colour.
>
> How is this different from other platforms we support?  This stuff
> does work there.  It works because, as Stefan points out, Emacs adapts
> its face colors to the background color of the default face: we have
> separate sets of colors for light and dark backgrounds.

I don’t understand.  There is a clear problem here in that the
font-lock-comment-face is dark red and the region colour is whatever the
GTK theme says it should be.  So unless font-lock-comment-face is also
set according to the GTK theme’s colours there is no way to avoid this
unfortunate combination of colours (dark red on dark background) without
customization.

FWIW neither the dark red colour nor the region background colour
changes when I change frame-background-mode.

-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Stefan Monnier]

> I don’t understand.  There is a clear problem here in that the
> font-lock-comment-face is dark red and the region colour is whatever the
> GTK theme says it should be.  So unless font-lock-comment-face is also
> set according to the GTK theme’s colours there is no way to avoid this
> unfortunate combination of colours (dark red on dark background) without
> customization.

Does Gtk offer some setting for the color of "comments"?
What do other applications do?

> FWIW neither the dark red colour nor the region background colour
> changes when I change frame-background-mode.

Maybe there's a bug here.  The color of `font-lock-comment-face`
*should* change.  If you can reproduce this, please provide a recipe to
`report-emacs-bug`.  The code says:

    (defface font-lock-comment-face
      '((((class grayscale) (background light))
         :foreground "DimGray" :weight bold :slant italic)
        (((class grayscale) (background dark))
         :foreground "LightGray" :weight bold :slant italic)
        (((class color) (min-colors 88) (background light))
         :foreground "Firebrick")
        (((class color) (min-colors 88) (background dark))
         :foreground "chocolate1")
        (((class color) (min-colors 16) (background light))
         :foreground "red")
        (((class color) (min-colors 16) (background dark))
         :foreground "red1")
        (((class color) (min-colors 8) (background light))
         :foreground "red")
        (((class color) (min-colors 8) (background dark))
         :foreground "yellow")
        (t :weight bold :slant italic))
      "Font Lock mode face used to highlight comments."
      :group 'font-lock-faces)

So when in "dark background" mode, `font-lock-comment-face` should be
using `chocolate1` rather than `Firebrick`.


        Stefan

Re: "modern" colors Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 14 Sep 2020 16:20:19 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> I don’t understand.  There is a clear problem here in that the
    >> font-lock-comment-face is dark red and the region colour is whatever the
    >> GTK theme says it should be.  So unless font-lock-comment-face is also
    >> set according to the GTK theme’s colours there is no way to avoid this
    >> unfortunate combination of colours (dark red on dark background) without
    >> customization.

    Stefan> Does Gtk offer some setting for the color of "comments"?
    Stefan> What do other applications do?

    >> FWIW neither the dark red colour nor the region background colour
    >> changes when I change frame-background-mode.

    Stefan> Maybe there's a bug here.  The color of `font-lock-comment-face`
    Stefan> *should* change.  If you can reproduce this, please provide a recipe to
    Stefan> `report-emacs-bug`.  The code says:

    Stefan>     (defface font-lock-comment-face
    Stefan>       '((((class grayscale) (background light))
    Stefan>          :foreground "DimGray" :weight bold :slant italic)
    Stefan>         (((class grayscale) (background dark))
    Stefan>          :foreground "LightGray" :weight bold :slant italic)
    Stefan>         (((class color) (min-colors 88) (background light))
    Stefan>          :foreground "Firebrick")
    Stefan>         (((class color) (min-colors 88) (background dark))
    Stefan>          :foreground "chocolate1")
    Stefan>         (((class color) (min-colors 16) (background light))
    Stefan>          :foreground "red")
    Stefan>         (((class color) (min-colors 16) (background dark))
    Stefan>          :foreground "red1")
    Stefan>         (((class color) (min-colors 8) (background light))
    Stefan>          :foreground "red")
    Stefan>         (((class color) (min-colors 8) (background dark))
    Stefan>          :foreground "yellow")
    Stefan>         (t :weight bold :slant italic))
    Stefan>       "Font Lock mode face used to highlight comments."
    Stefan>       :group 'font-lock-faces)

    Stefan> So when in "dark background" mode, `font-lock-comment-face` should be
    Stefan> using `chocolate1` rather than `Firebrick`.

The GTK theme may be in 'dark' mode, but (as discussed elsewhere in
this thread), the default face does not respect the GTK theme
background.

Robert

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 15 Sep 2020 09:40:11 +0200
> Cc: casouri@gmail.com, spacibba@aol.com, emacs-devel@gnu.org,
>  Ricardo Wurmus <rekado@elephly.net>, ams@gnu.org, ghe@sdf.org,
>  Eli Zaretskii <eliz@gnu.org>, tecosaur@gmail.com
> 
> The GTK theme may be in 'dark' mode, but (as discussed elsewhere in
> this thread), the default face does not respect the GTK theme
> background.

Is that because we don't know how to query GTK for the themes default
colors?

Re: "modern" colors Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Tue, 15 Sep 2020 17:34:43 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Tue, 15 Sep 2020 09:40:11 +0200
    >> Cc: casouri@gmail.com, spacibba@aol.com, emacs-devel@gnu.org,
    >> Ricardo Wurmus <rekado@elephly.net>, ams@gnu.org, ghe@sdf.org,
    >> Eli Zaretskii <eliz@gnu.org>, tecosaur@gmail.com
    >> 
    >> The GTK theme may be in 'dark' mode, but (as discussed elsewhere in
    >> this thread), the default face does not respect the GTK theme
    >> background.

    Eli> Is that because we don't know how to query GTK for the themes default
    Eli> colors?

If by 'we' you mean Emacs, then yes. (I donʼt know how either, and I
find the GTK docs unhelpful).

Robert

Re: "modern" colors Re: Changes for emacs 28

[Yuri Khan]

On Tue, 15 Sep 2020 at 21:54, Robert Pluim <rpluim@gmail.com> wrote:

>     Eli> Is that because we don't know how to query GTK for the themes default
>     Eli> colors?
>
> If by 'we' you mean Emacs, then yes. (I donʼt know how either, and I
> find the GTK docs unhelpful).

Some time ago someone over at Bugzilla (Firefox’s bug tracker) said
it’s generally not possible to query about that.

Re: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-15 18:51 +03, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> Some time ago someone over at Bugzilla (Firefox’s bug tracker) said
> it’s generally not possible to query about that.

And yet they are able to use that information to set up their UI
colours, and more interestingly they are able to relay that information
via CSS such that the @media(prefers-color-scheme) works.

Maybe it’s just heuristics then?

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

Re: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-15 19:01 +03, Göktuğ Kayaalp <self@gkayaalp.com> wrote:
> On 2020-09-15 18:51 +03, Yuri Khan <yuri.v.khan@gmail.com> wrote:
>> Some time ago someone over at Bugzilla (Firefox’s bug tracker) said
>> it’s generally not possible to query about that.
>
> And yet they are able to use that information to set up their UI
> colours, and more interestingly they are able to relay that information
> via CSS such that the @media(prefers-color-scheme) works.
>
> Maybe it’s just heuristics then?

I think I found something relevant here [1] and indeed it seems they’re
just using heuristics to guess if the GTK theme is dark-ish:

    mSystemUsesDarkTheme =
        (RelativeLuminanceUtils::Compute(GDK_RGBA_TO_NS_RGBA(bg)) <
         RelativeLuminanceUtils::Compute(GDK_RGBA_TO_NS_RGBA(fg)));

[1] https://searchfox.org/mozilla-central/rev/0c97a6410ff018c22e65a0cbe4e5f2ca4581b22e/widget/gtk/nsLookAndFeel.cpp#1021-1023

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

Re: "modern" colors Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Tue, 15 Sep 2020 22:51:24 +0700, Yuri Khan <yuri.v.khan@gmail.com> said:

    Yuri> On Tue, 15 Sep 2020 at 21:54, Robert Pluim <rpluim@gmail.com> wrote:
    Eli> Is that because we don't know how to query GTK for the themes default
    Eli> colors?
    >> 
    >> If by 'we' you mean Emacs, then yes. (I donʼt know how either, and I
    >> find the GTK docs unhelpful).

    Yuri> Some time ago someone over at Bugzilla (Firefox’s bug tracker) said
    Yuri> it’s generally not possible to query about that.

Would you have a bugzilla bug number?

Robert

Re: "modern" colors Re: Changes for emacs 28

[Yuri Khan]

On Tue, 15 Sep 2020 at 23:06, Robert Pluim <rpluim@gmail.com> wrote:

>     Yuri> On Tue, 15 Sep 2020 at 21:54, Robert Pluim <rpluim@gmail.com> wrote:
>     Eli> Is that because we don't know how to query GTK for the themes default
>     Eli> colors?
>     >>
>     >> If by 'we' you mean Emacs, then yes. (I donʼt know how either, and I
>     >> find the GTK docs unhelpful).
>
>     Yuri> Some time ago someone over at Bugzilla (Firefox’s bug tracker) said
>     Yuri> it’s generally not possible to query about that.
>
> Would you have a bugzilla bug number?

Okay, I went to look for a reference and it turns out I misremembered.
What actually happened is I asked on the GTK mailing lists whether an
application can programmatically detect if the user is using a light
or dark variant of a theme.

https://mail.gnome.org/archives/gtk-app-devel-list/2018-November/msg00006.html

In the reply, I was told this:

  The only way to respect the GTK theme is to use GTK to render UI elements
  according to that theme—using the `gtk_render_*` API. Anything else is, by
  and large, impossible unless you literally parse the CSS with your own CSS
  parser, determine the colours of every UI element you care about, and then
  detect whether those colours are "light" or "dark".

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Tue, 15 Sep 2020 22:51:24 +0700
> Cc: Yuan Fu <casouri@gmail.com>, Ergus <spacibba@aol.com>,
>  Emacs developers <emacs-devel@gnu.org>, rekado@elephly.net,
>  "Alfred M. Szmidt" <ams@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
>  Gregory Heytings <ghe@sdf.org>, Eli Zaretskii <eliz@gnu.org>,
>  TEC <tecosaur@gmail.com>
> 
> On Tue, 15 Sep 2020 at 21:54, Robert Pluim <rpluim@gmail.com> wrote:
> 
> >     Eli> Is that because we don't know how to query GTK for the themes default
> >     Eli> colors?
> >
> > If by 'we' you mean Emacs, then yes. (I donʼt know how either, and I
> > find the GTK docs unhelpful).
> 
> Some time ago someone over at Bugzilla (Firefox’s bug tracker) said
> it’s generally not possible to query about that.

Why, doesn't GTK have the default color for text and another for the
window background?

Re: "modern" colors Re: Changes for emacs 28

[Yuri Khan]

On Tue, 15 Sep 2020 at 23:11, Eli Zaretskii <eliz@gnu.org> wrote:

> > >     Eli> Is that because we don't know how to query GTK for the themes default
> > >     Eli> colors?
> > >
> > > If by 'we' you mean Emacs, then yes. (I donʼt know how either, and I
> > > find the GTK docs unhelpful).
> >
> > Some time ago someone over at Bugzilla (Firefox’s bug tracker) said
> > it’s generally not possible to query about that.
>
> Why, doesn't GTK have the default color for text and another for the
> window background?

It does, but it encapsulates them. You don’t say “tell me the colors
so I could draw things”, you say “draw things for me”.

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> Cc: monnier@iro.umontreal.ca, spacibba@aol.com, casouri@gmail.com,
>  emacs-devel@gnu.org, ams@gnu.org, ghe@sdf.org, tecosaur@gmail.com
> Date: Mon, 14 Sep 2020 21:47:13 +0200
> 
> FWIW neither the dark red colour nor the region background colour
> changes when I change frame-background-mode.

It should be the other way around: when Emacs switches its default
colors, the background mode is recalculated, and if it changed, we use
a different set of colors for many faces.

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  spacibba@aol.com,  casouri@gmail.com,
>   emacs-devel@gnu.org,  ams@gnu.org,  ghe@sdf.org,  tecosaur@gmail.com
> Date: Sun, 13 Sep 2020 16:16:17 -0400
> 
> > I suppose that’s exactly what gtk_selection_bg_color and
> > gtk_selection_fg_color are supposed to do: take the colours from the GTK
> > theme.
> >
> > On Guix we build Emacs with the GTK toolkit.
> 
> So the bug is that we obey the "external" settings for the region but
> apparently not for the `default` face.

Are we sure this is the case?  Where's the code which uses the colors
for the region?

Re: "modern" colors Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 14 Sep 2020 17:39:37 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Stefan Monnier <monnier@iro.umontreal.ca>
    >> Cc: Eli Zaretskii <eliz@gnu.org>,  spacibba@aol.com,  casouri@gmail.com,
    >> emacs-devel@gnu.org,  ams@gnu.org,  ghe@sdf.org,  tecosaur@gmail.com
    >> Date: Sun, 13 Sep 2020 16:16:17 -0400
    >> 
    >> > I suppose that’s exactly what gtk_selection_bg_color and
    >> > gtk_selection_fg_color are supposed to do: take the colours from the GTK
    >> > theme.
    >> >
    >> > On Guix we build Emacs with the GTK toolkit.
    >> 
    >> So the bug is that we obey the "external" settings for the region but
    >> apparently not for the `default` face.

    Eli> Are we sure this is the case?  Where's the code which uses the colors
    Eli> for the region?


faces.el:

(defface region
  '((((class color) (min-colors 88) (background dark))
     :background "blue3" :extend t)
    (((class color) (min-colors 88) (background light) (type gtk))
     :distant-foreground "gtk_selection_fg_color"
     :background "gtk_selection_bg_color" :extend t)

'region' is the only face this is done for.

Itʼs then used here:

gtkutil.c:

bool
xg_check_special_colors (struct frame *f,
                         const char *color_name,
                         Emacs_Color *color)
{
  bool success_p = 0;
  bool get_bg = strcmp ("gtk_selection_bg_color", color_name) == 0;
  bool get_fg = !get_bg && strcmp ("gtk_selection_fg_color", color_name) == 0;

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  spacibba@aol.com,
>   casouri@gmail.com,  emacs-devel@gnu.org,  rekado@elephly.net,
>   ams@gnu.org,  ghe@sdf.org,  tecosaur@gmail.com
> Date: Mon, 14 Sep 2020 16:47:13 +0200
> 
>     Eli> Are we sure this is the case?  Where's the code which uses the colors
>     Eli> for the region?
> 
> 
> faces.el:
> 
> (defface region
>   '((((class color) (min-colors 88) (background dark))
>      :background "blue3" :extend t)
>     (((class color) (min-colors 88) (background light) (type gtk))
>      :distant-foreground "gtk_selection_fg_color"
>      :background "gtk_selection_bg_color" :extend t)
> 
> 'region' is the only face this is done for.

And a similar trick with the default face won't work or something?

Re: "modern" colors Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 14 Sep 2020 19:07:24 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  spacibba@aol.com,
    >> casouri@gmail.com,  emacs-devel@gnu.org,  rekado@elephly.net,
    >> ams@gnu.org,  ghe@sdf.org,  tecosaur@gmail.com
    >> Date: Mon, 14 Sep 2020 16:47:13 +0200
    >> 
    Eli> Are we sure this is the case?  Where's the code which uses the colors
    Eli> for the region?
    >> 
    >> 
    >> faces.el:
    >> 
    >> (defface region
    >> '((((class color) (min-colors 88) (background dark))
    >> :background "blue3" :extend t)
    >> (((class color) (min-colors 88) (background light) (type gtk))
    >> :distant-foreground "gtk_selection_fg_color"
    >> :background "gtk_selection_bg_color" :extend t)
    >> 
    >> 'region' is the only face this is done for.

    Eli> And a similar trick with the default face won't work or something?

Sure it will, if someone knowledgeable tells us what Gtk calls those
colours. (I tried to work it out from what's on my system, but got
lost in a twisty maze of includes of non-existent files).

Robert

Re: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Ricardo Wurmus <rekado@elephly.net>
> Cc: spacibba@aol.com, casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org,
>  monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
> Date: Sun, 13 Sep 2020 21:49:24 +0200
> 
> > Then it's a mystery only you can solve.  Look at the definition of the
> > 'region' face in faces.el: the only case where we use :inverse-video
> > is on monochrome TTYs.  If that is not your case, then I don't know
> > how to explain the fact that you see the region in reverse video.  I
> > guess I'm missing something, but what?
> 
> The ’region’ face has these settings:
> 
>   DistantForeground: gtk_selection_fg_color
>          Background: gtk_selection_bg_color
> 
> I switch to a light GTK theme and run Emacs:
> 
>   $ dconf write /org/gnome/desktop/interface/gtk-theme "'Adwaita'"
>   $ emacs -Q
> 
> Now the selected region has a light gray background.
> 
> I switch to a dark GTK theme and run Emacs:
> 
>   $ dconf write /org/gnome/desktop/interface/gtk-theme "'Adwaita-dark'"
>   $ emacs -Q
> 
> Now the selected region has a very dark background and the text is
> bright.
> 
> I suppose that’s exactly what gtk_selection_bg_color and
> gtk_selection_fg_color are supposed to do: take the colours from the GTK
> theme.

Thanks for investigating.  So this explains the colors that you see,
but AFAIU, they are not exactly the default colors inverted, they just
look similar to that.  Your original description said the region was
shown in inverse video, which is what puzzled me.

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ricardo Wurmus <rekado@elephly.net>
>> Cc: spacibba@aol.com, casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org,
>>  monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
>> Date: Sun, 13 Sep 2020 21:49:24 +0200
>> 
>> > Then it's a mystery only you can solve.  Look at the definition of the
>> > 'region' face in faces.el: the only case where we use :inverse-video
>> > is on monochrome TTYs.  If that is not your case, then I don't know
>> > how to explain the fact that you see the region in reverse video.  I
>> > guess I'm missing something, but what?
>> 
>> The ’region’ face has these settings:
>> 
>>   DistantForeground: gtk_selection_fg_color
>>          Background: gtk_selection_bg_color
>> 
>> I switch to a light GTK theme and run Emacs:
>> 
>>   $ dconf write /org/gnome/desktop/interface/gtk-theme "'Adwaita'"
>>   $ emacs -Q
>> 
>> Now the selected region has a light gray background.
>> 
>> I switch to a dark GTK theme and run Emacs:
>> 
>>   $ dconf write /org/gnome/desktop/interface/gtk-theme "'Adwaita-dark'"
>>   $ emacs -Q
>> 
>> Now the selected region has a very dark background and the text is
>> bright.
>> 
>> I suppose that’s exactly what gtk_selection_bg_color and
>> gtk_selection_fg_color are supposed to do: take the colours from the GTK
>> theme.
>
> Thanks for investigating.  So this explains the colors that you see,
> but AFAIU, they are not exactly the default colors inverted, they just
> look similar to that.  Your original description said the region was
> shown in inverse video, which is what puzzled me.

Yes, it is not inverse video, but it looks very much like it with the
Adwaita-dark theme.  I could not know the true cause prior to
investigating the issue :)

-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Richard Stallman]

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

  > 2) Modeline: Our modeline is a kind of relic from other times. With the
  > same gray color in the terminal and some cryptic information. It also
  > shows the line but not the column by default and the file status is
  > somehow in that cryptic initial part I don't think many users understand
  > very well.

Changing this is easy.  The hard part is deciding what to change it
to.

  > Just adding an * to the filename in modeline (and or tab when using
  > them) or changing the color is easier to understand. Than -UUU:----F1

Sorry, I can't parse that.

  > You can see all the popular alternatives around.

Sorry, I am lost.  Who can see what, when?

  > 3) Colors: People prefer higher contrast in general 4 example: in my
  > system when the region es enabled the default gray color is so light
  > that I can't see it. Same applies to icon that when enabled or disabled
  > the difference sometimes is minimal.

It is easy to change these colors.  The hard part is determining
precisely what change to make, and deciding what change to make.

  > 4) Right click: (Probably it is the most lacking functionality and
  > surprising for any user not using the terminal.) Right click is expected
  > to bring a panel with the most common operations. It is useful, fast
  > and somehow standard since 1995 while removing most of the needs of the
  > toolbar which takes precious vertical space.

We can easily add more right-click menus.  What we need is
a set of concrete proposals for what to add, in which modes
or on what text.

-- 
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: "modern" colors Re: Changes for emacs 28

[Richard Stallman]

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

  > 5) sidebar: most code editors have a button somewhere in the interface
  > to show/hide the sidebar to explore and open files/access symbols or see
  > open files.

I don't think we have a sidebar feature in Emacs.  This is the one
thing that would actually be difficult.

-- 
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: "modern" colors Re: Changes for emacs 28

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 12 Sep 2020 23:57:33 -0400
> Cc: casouri@gmail.com, emacs-devel@gnu.org, ams@gnu.org,
>  monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
> 
>   > 5) sidebar: most code editors have a button somewhere in the interface
>   > to show/hide the sidebar to explore and open files/access symbols or see
>   > open files.
> 
> I don't think we have a sidebar feature in Emacs.

We do: it's called Speedbar.  But it is only useful on GUI displays
(although should work on TTYs as well).

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

     > 5) sidebar: most code editors have a button somewhere in the interface
     > to show/hide the sidebar to explore and open files/access symbols or see
     > open files.

   I don't think we have a sidebar feature in Emacs.  This is the one
   thing that would actually be difficult.

We do, but it is called speedbar.

Re: "modern" colors Re: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

>>In what way have the "fully redesigned the mode-line"? The link you
>>provided has no mode-lines.
>>
> https://github.com/jonathanchu/emacs-powerline
> https://github.com/TheBB/spaceline
> https://github.com/domtronn/spaceline-all-the-icons.el
> https://seagle0128.github.io/doom-modeline
> https://www.spacemacs.org/ (there are pictures)

If this is modern, I'd very much argue against modernizing.

First of all, most of these changes are either non-functional or just
changes for the sake of change. They also remind me of the prompts some
people use in their shell, that use those modified fonts to create the
illusion of pentagon-like shape. That's already existed for a few years,
and from my experience, after reaching a critical-mass and it looses it
novelty value, it will look even more outdated (or perhaps even
"cringe") than what we have no. Think of those 3D, hyper-detail desktops
that were cool 10-15 years ago. Or the skeuomorphism found on Apple
operating systems. What use to be cool, fresh and new, was that only
because it managed to make use of new technical capabilities, that
previously limited the design (higher density displays, enough spare
computational power to render excessive animations, etc.). 

These tendencies usually go too far, and eventually this excess is
commonly understood. But until then, the movement is recognized as
modern, and following it's style doesn't make sense for everyone. For a
new programme, without an established user-base, appearances are a lot
more important, because "first look" count. But established applications
can suffer from it, as I often hear from MS Office users, who lament the
frequent changes in the UI. While a change of theme or mode-line isn't
that drastic, I think the analogy can be recognized.

Secondly, design reflects mentality. One can say a lot about a person,
by looking at their living room furniture. Most would consider VS Code
or Atom to have modern UIs and designs, but I don't think that it could
or should be disconnected from the UX. I'd argue: The UX or an "ideal"
work flow in Emacs doesn't match that of VSC or Atom, and by reflecting
that in the design, we don't stand to gain a modern UI, but "break" the
UX. Emacs is different, and to a certain degree this should be reflected
in the way it looks (which doesn't mean everything should stay the
same). 

Maybe it would be better to aim for "Timeless", instead of "Modern".

(I recognize that the argument is a bit flimsy, but I'm writing this
around half past one in the morning, so mistakes are bound to happen.)

-- 
	Philip K.

Re: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-12 02:29 +03, Philip K. <philipk@posteo.net> wrote:
> If this is modern, I'd very much argue against modernizing.
[...]
> Maybe it would be better to aim for "Timeless", instead of "Modern".

A m e n.

Emacs has an aesthetic.  We may improve it, but must preserve it.  The
great beauty of it is that, like Vim or shell prompts, people with
diverging aesthetical preferences may make it look exactly the way they
want.  One guy who publishes often on /r/emacs is making pixel perfect
stuff, very beautiful and minimalist UX-wise.  Calls it "Elegant Emacs"
I guess.  But while it’s cool to look at I’d hate to have to work with
it.  The beauty of Emacs and similar is, everybody can have what they
want, what comes OOTB is but a canvas.

@Ergus: Off topic, but would you mind clipping out irrelevant parts of
the quoted messages when replying?  Not a huge thing but makes it just a
little bit more easier on the reader.


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

Re: "modern" colors Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 02:29, Philip K. wrote:
> Maybe it would be better to aim for "Timeless", instead of "Modern".

Among similar packages, I quite like Artur's package:

https://github.com/Malabarba/smart-mode-line

The light version in particular.

It is both an improvement on the default mode-line, and it doesn't 
change the aesthetics too much.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 02:44:29PM +0300, Dmitry Gutov wrote:
>On 12.09.2020 02:29, Philip K. wrote:
>>Maybe it would be better to aim for "Timeless", instead of "Modern".
>
>Among similar packages, I quite like Artur's package:
>
>https://github.com/Malabarba/smart-mode-line
>
>The light version in particular.
>
>It is both an improvement on the default mode-line, and it doesn't 
>change the aesthetics too much.

I had it some time ago, but it added some external dependencies that
increased my startup time. But the aesthetic is actually perfect;
specially the powerline theme.

RE: "modern" colors Re: Changes for emacs 28

[Drew Adams]

Nostradamus (Philip K) was right when he whispered,
in the wee hours of a morning:

> after reaching a critical-mass ... it loses it[s]
> novelty value, it will look even more outdated (or
> perhaps even "cringe")

> What use[d] to be cool, fresh and new, was that
> only because it managed to make use of new
> technical capabilities, that previously limited
> the design (higher density displays, enough spare
> computational power to render excessive animations, etc.). 
>
> These tendencies usually go too far, and
> eventually this excess is commonly understood.

But by then we'll have 1000s, if not 1000000s, of
new emacs-devel participants who'll be happy to
argue over and (try to) update those newly
old-fashioned novelties.

And of course some of those ex-newbies will argue
to keep the once-novel thingies that they've become
accustomed to or learned to love.  Others will
storm the ramparts...

> The UX or an "ideal" work flow in Emacs doesn't
> match that of VSC or Atom, and by reflecting that
> in the design, we don't stand to gain a modern UI,
> but "break" the UX.  Emacs is different...


> If this is modern, I'd very much argue against
> modernizing.

Oh, Nostra, Baby, you're such a loser boomer, at
heart.  ;-)

+1.

Re: "modern" colors Re: Changes for emacs 28

[Arthur Miller]

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

>    >   >   Actually spacemacs made it to look a bit more modern by just changing
>    >   >   some colors.
>    >   >
>    >   >What kind of changes to colors was that?  It would be good to quantify
>    >   >what "modern" means.
>    >
>    >   In general this is very subjective. But looking at WinXP vs Win10 one
>    >   gets more or less where the style feeling is moving to. Specially the
>    >   colors and the default fonts in the interfaces make a big difference;
>    >   but also the whole integration.
>    >
>    >Could you list those changes?
>
>    1) The "included" themes (not only the default one) are a bit more
>    "attractive" and similar to the ones in VSCode, Sublime or Android
>    Studio:
>
>    https://themegallery.robdor.com/
>
> That lists several hundreds of themes.  Can you summarize _what_
> changes where done to make Emacs look more modern?  A list of maybe
> 3-5 things would give a good idea.  For example, one concrete change
> is to replace a warning face that is bright yellow with a dark yellow.
>
>    2) In the windows side they just made the whole colors a bit more
>    "coherent" with the internal themes,
>
> What does that mean? What changes did they (who is they?) do exactly?
>
>    2.1) the menu-bar is usually more "compact" with a smaller and bold font
>    (OR hided OR enabled xterm-mouse-mode because otherwise the toolbar is
>    pretty much useless as F10 is intercepted by most of the terminal
>    emulators or desktop environments).
>
>
>    2.2) In the case where they keep the tool-bar the icons are smaller and
>    more "attractive". Lets say sometimes independent of the theme, but in
>    general smaller.
>
> How are the more attractive?  The list you provided doesn't show a
> single tool-bar.
>
>    3) Finally they fully redesigned the mode-line. I don't like all the
>    changes they did because they require many extra external packages that
>    increase too much the loading time and I prefer to load my emacs in less
>    than 1 sec. But form the aestetic point of view it is an important
>    change.
>
> In what way have the "fully redesigned the mode-line"? The link you
> provided has no mode-lines.  
>
> Please be specific, give examples -- "it is more attractive" without
> explicilty saying what "it" is makes for a long discussion.

What changes are attractive or modern will depend on the user and
his/her taste mostly. We could also said provide more useful, gentle for
the eyes etc.

I don't liek staring at white backgrounds, it is like looking into a
lamp. As I write this I have half of my screen on white background (a
github page) and white in dary green (Emacs) and I can clearly compare
and see how much harder it is to look at white background of Github.

Anyway, if you gonna include a new theme or color framework in Emacs, I
think you should include Solarized as ported by B. Batsov:

https://github.com/bbatsov/solarized-emacs

Furthermore his theme could be simplified and ported to a framework,
call it "colorized" which could consist of 8 base colors + 8 accented
colors + 8 lighter/darker accented colors. That gives a total of
framework 32 colors, which should be more then enough to theme a
screen/application.

Any design book nowadays will speak of importance of a color palette and
visual coherence of elements on the screen, be it an application GUI,
document or a web page. Too many colors is just not very good for
different reasons be it a pedagogical, aesthetic or something else.

Emacs seems to completely lack guidance for package developers/scripts
how to write visually appealing and color coherent extensions.
Furthermore nature of Elisp and Emacs lets you change anything in
arbitrary way, and everything being text in Emacs usually results in
color output of Emacs on the screen being a rainbow. Maybe there could
be a color guidance and framework for extensions to use and follow to
offer more visual coherence as well as ease of modding and choosing a
color theme. I think Batsov's Solarized makes a good candidate to turn
it into such framework.

Re: "modern" colors Re: Changes for emacs 28

[Ricardo Wurmus]

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

> Anyway, if you gonna include a new theme or color framework in Emacs, I
> think you should include Solarized as ported by B. Batsov:
>
> https://github.com/bbatsov/solarized-emacs
>
> Furthermore his theme could be simplified and ported to a framework,
> call it "colorized" which could consist of 8 base colors + 8 accented
> colors + 8 lighter/darker accented colors. That gives a total of
> framework 32 colors, which should be more then enough to theme a
> screen/application.
>
> […] Maybe there could
> be a color guidance and framework for extensions to use and follow to
> offer more visual coherence as well as ease of modding and choosing a
> color theme. I think Batsov's Solarized makes a good candidate to turn
> it into such framework.

I support this motion.

Solarized is very easy on the eyes, available for many other
applications, and it is the result of a simple set of harmonized colours
that are optimized for equal contrast.

It can easily be customized to use different colours without looking
“strange”.

-- 
Ricardo

Re: "modern" colors Re: Changes for emacs 28

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Anyway, if you gonna include a new theme or color framework in Emacs, I
>> think you should include Solarized as ported by B. Batsov:
>>
>> https://github.com/bbatsov/solarized-emacs
>>
>> Furthermore his theme could be simplified and ported to a framework,
>> call it "colorized" which could consist of 8 base colors + 8 accented
>> colors + 8 lighter/darker accented colors. That gives a total of
>> framework 32 colors, which should be more then enough to theme a
>> screen/application.
>>
>> […] Maybe there could
>> be a color guidance and framework for extensions to use and follow to
>> offer more visual coherence as well as ease of modding and choosing a
>> color theme. I think Batsov's Solarized makes a good candidate to turn
>> it into such framework.
>
> I support this motion.
>
> Solarized is very easy on the eyes, available for many other
> applications, and it is the result of a simple set of harmonized colours
> that are optimized for equal contrast.
>
> It can easily be customized to use different colours without looking
> “strange”.
I guess most of you are familiar with Solarized, but for those that are
not here is the original author's page that explains "the science"
behind it:

https://ethanschoonover.com/solarized/

Re: "modern" colors Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 17:31, Arthur Miller wrote:
> I guess most of you are familiar with Solarized, but for those that are
> not here is the original author's page that explains "the science"
> behind it:
> 
> https://ethanschoonover.com/solarized/

Solarized themes are nice enough color-wise, but they are terribly 
low-contrast. It's a struggle to simply read the text when coming other 
applications which typically use higher contrast colors (e.g. 
Thunderbird and the numerous web sites accessible from Firefox).

Perhaps macOS's font rendering is different enough that this problem is 
less pronounced. Not on my Ubuntu, though.

Re: "modern" colors Re: Changes for emacs 28

[Alfred M. Szmidt]

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

   > […] Maybe there could
   > be a color guidance and framework for extensions to use and follow to
   > offer more visual coherence as well as ease of modding and choosing a
   > color theme. I think Batsov's Solarized makes a good candidate to turn
   > it into such framework.

   I support this motion.

   Solarized is very easy on the eyes, available for many other
   applications, and it is the result of a simple set of harmonized
   colours that are optimized for equal contrast.

Solarized is a good selection and maybe even a good default (other
programs might use it, and having a coherent selection of colors is
always nice).  But what someone finds easy, someone else will find
hard so we shouldn't make such generalised claims that something is
very easy on the eyes e.g., I find the "pink-ish" background hard on
my eyes (despite liking that color palette).

Re: "modern" colors Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 16:16, Arthur Miller wrote:
> I don't liek staring at white backgrounds, it is like looking into a
> lamp. As I write this I have half of my screen on white background (a
> github page) and white in dary green (Emacs) and I can clearly compare
> and see how much harder it is to look at white background of Github.

This looks like a common misconception. Here's how this experiment is 
flawed.

The eyes adapts to the current ambient level of lighting. That why when 
you go outside you don't usually have to cover your eyes. Even though 
daylight's brightness is an order(s) of magnitude higher than the 
lighting inside an average office, indoors.

As soon as your eyes and brain notice that the basic level of 
illumination has increased, the iris muscles in your eyes contract, the 
irises become smaller and let in only the amount of light that is needed 
for you to see things clearly, but not more (leading to too-bright a 
picture). And when you go back into the shade, the iris muscle relaxes 
and the pupils enlarge to, again, capture the appropriate amount of light.

If you ever did some photography (digital or otherwise), you probably 
know that more light is generally a good thing, and most cameras can 
produce a good picture in generous lighting. In twilight, that takes 
more effort.

The bulk of the eye strain comes from those moments when the eye has to 
adapt to the new level of brightness. That's when the iris muscle does 
its work.

So if you have been working in a dark Emacs for some time, and 
especially if the room around you is not well-lit, of course Github and 
similar websites would immediately look like a bright sun.

But if you turn on more lights in the room (or simply lower the screen 
brightness to match the surrounding lighting) and spend some time on 
Github, Wikipedia, Reddit, SX, inside Thunderbird, etc, then switch back 
to your dark Emacs, the immediate stress should be about the same.

Re: Changes for emacs 28

[Richard Stallman]

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

  > IMO the most significant factor is that Doom allowed me to "just get
  > started" with the tasks which caused my lingering interest to manifest
  > into installing. While now I couldn't imagine going without Emacs, that
  > initial ease was crucial.

That describes how it felt, subjectively, to you.
That's a consequence of some concrete things about DOOM,
I am sure -- but I have no idea what those concrete things _are_.

Can you describe even a few of the concrete differences of DOOM that
made it so easy for you?  I suggest not aiming for completeness,
but rather mentioning the ones that are most important.

That would be the information we might perhaps draw concrete lessons
from.

  > IMO the most significant factor is that Doom allowed me to "just get
  > started" with the tasks

Could you describe a few of those tasks, and what would have been
hard about them, which DOOM made easier?

I'm also curious about how why you decided to change from DOOM
to standard Emacs?

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

Re: Changes for emacs 28

[TEC]

Richard Stallman <rms@gnu.org> writes:

> That describes how it felt, subjectively, to you.
> That's a consequence of some concrete things about DOOM,
> I am sure -- but I have no idea what those concrete things _are_.

I appreciate the difficulty.
Unfortunately, as you point out this is a single subjective impression
of qualitative factors that are generally hard to pin down.
I welcome any attempt to corral my jumbled thoughts into something
actually useful, and will try my best to communicate which factors had
the most impact on my experience :)

> Can you describe even a few of the concrete differences of DOOM that
> made it so easy for you?  I suggest not aiming for completeness,
> but rather mentioning the ones that are most important.
>
> That would be the information we might perhaps draw concrete lessons
> from.
>
>   > IMO the most significant factor is that Doom allowed me to "just get
>   > started" with the tasks
>
> Could you describe a few of those tasks, and what would have been
> hard about them, which DOOM made easier?

So, the task that got me started was using R, notebook style
 --- i.e. R + Org.

This is what the process was like with Doom:
 - run the one-line install script
 - opening the config dir is prominently listed (with the associated
   keybinding) on the 'home'/init/welcome buffer
 - I find three files, well commented, describing what they are and what
   to do with them
 - I see ESS listed in init.el as a 'statistics' module under :lang
   C-c c k pulls up the documentation on it (as I am told by comments at
   the start of the file) and I see that it does indeed add support for
   R. I uncomment the line and run 'doom refresh'
 - Excluding install time, I think this took me ~5 minutes

At this point I have:
 - Support for R
 - Completion via Company
 - Linting via Flycheck
 - A fuzzy searcher for commands I don't know with Ivy
 - When I pause on keybindings (what was that next part?)
   which-key pops up.
 - An editor that appeals to my 'flashy modern' sensibles
   + A UI/theme more inline with Atom/VS Code/etc.
   + Git status gutters
   + A modeline that tells me nice stuff like

To get here all I needed to know is that I wanted to use R,
notebook-style with Org, hoping to see the 'editor features' that I
missed in JupyterLab.

In order to get to this same point with Vanilla emacs I'd need to:
 - Identify ESS as the package for R (quick search online)
 - Work out how to install packages
   + come across conflicting answers on the web. use-package? straight?
     package-install?
 - I'd try an R block in org, and get told:
   "No org-babel-execute function for R!"
   + what's this? how do I fix it?
 - Once I get that working - where's the completion I was hoping for?
   + another internet trip...
 - Etc.

Unfortunately I can't imagine this taking a comparable length of time,
or being nearly as easy.

I'm not sure that Emacs can embrace the behaviours that people who have
primarily experienced the likes of VS Code/Atom/JetBrains/Sublime/etc.
will be looking for, without compromising the experience that long-time
users have come to expect. Perhaps the way forward may be to treat
standard Emacs as a core and prominently offer 'distributions' of Emacs?

Possibly the best thing about Emacs IMO is its versatility. I suspect
that trying to be all things to all people could be a futile task,
but maybe Emacs can lean into this and say to a new user:
 - if you're looking to use Emacs like X, here you go
 - looking for Y instead? Then just use/do this
 - actually want Z? Here's that option...

This seems like something where some selection of:
 - modules
 - profiles
 - embracing distributions

could improve the situation.

Anyway, that's just my thoughts. Hopefully they're of some interest.

> I'm also curious about how why you decided to change from DOOM
> to standard Emacs?

Erm. I haven't switched from Doom to standard Emacs. Apologies if I
incorrectly implied that somewhere.
My journey was (excluding pre-emacs):
  Spacemacs (for a brief period) → Vanilla (for mere hours) → Doom

[aside: why I'm still on doom, http://ix.io/2wUw]

I feel that for the purposes of this discussion, it would have been nice
if I'd spent longer trying to get vanilla/standard Emacs working --- but
I didn't. However I'll still offer what I can in the hope that it may be
useful.

All the best,

Timothy.

Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-09 09:26 +03, TEC <tecosaur@gmail.com> wrote:
[...]
> Unfortunately I can't imagine this taking a comparable length of time,
> or being nearly as easy.

I think experiences like this highlight two major clusters among Emacs
users: those who come to Emacs for Emacs, and those whow are attracted
to it because it has Org mode (or sth. else, but it seems to be Org mode
most of the time).

Those who come to Emacs for Emacs are mainly here because they
appreciate how Emacs caters to their need for an extensible,
customisable system which they can use to build up a computing
environment that’s tailor-made for their needs.  I fall within this
category.  I started with a blank init.el some 6 years ago.  When I
found Org mode or ESS or Elfeed or whatnot, it was because I was
actively looking for how to do the relevant thing in Emacs, because I
assumed that doing it in Emacs would allow me to sculpt the experience
to my liking, fine tune everything, and tie things nicely together.

Those who come to Emacs for Org mode, mu4e, or maybe something else
(I’ll just say Org mode from here on; assume a dangling ‘or maybe
something else’ for each instance), are fundamentally different.  You
fall into this category.  I of course can’t know your particular
experience, but what I deduce from reading /r/emacs to this day is this
kind of user generally finds out about Emacs as the thing that hosts Org
mode.  They are mainly interested in Org mode and some related
features.  They won’t find out about what users like me think are the
main virtues of Emacs until later, and they won’t find out about how
Emacs is traditionally used, customised, until even later.

There maybe is a third kind of user who thinks of it just another text
editor with some programming support, but I won’t risk more detailed
assumptions for this hypothetical category.

But, what I’ve described above is IMO something that’ll render itself
pretty obvious e.g. if you go to /r/emacs and read it for a week or two.

> I'm not sure that Emacs can embrace the behaviours that people who have
> primarily experienced the likes of VS Code/Atom/JetBrains/Sublime/etc.
> will be looking for, without compromising the experience that long-time
> users have come to expect. Perhaps the way forward may be to treat
> standard Emacs as a core and prominently offer 'distributions' of Emacs?

If what I said above is indeed relevant and truthy, it might be a nice
basis for introducing people to Emacs (the term ‘marketing’ is really
ugly, IMHO simply means ‘to deceive into thinking, with greedy malice’)
and proves, along with your experience that you document in your OP, how
useful could distributions be to cater to this particular category of
users, without compromising others.

I’d say we should leave distributions to the community, support them and
maybe ‘bless’ the projects that are willing as GNU projects, and make
sure that <gnu.org/s/emacs> and <orgmode.org> are displaying to the
users what’s available, possibly with some video introductions for each
which briefly introduce and overview the thing, and also some for a
variety of common use cases.

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

RE: Changes for emacs 28

[Drew Adams]

> > The mode will substitute undo with undo-only. This small contradiction
> > will start a war here.
> 
> As long as we keep this on the menu and the tool bar, there will be no
> reason for a "war".
> 
> > >> Having undo with an undo-redo in the same "state" could be confusing as
> > >> the normal undo could do also redo IMO.
> > >
> > >If the user uses the menus or the tool bar, the confusion will be
> > >spared, right?
> > >
> > If the user expects undo-only behavior; then having our undo will be
> > confusing because not expecting undo becoming a redo at some point.
> 
> How can it be confusing that 2 different commands produce different
> results?  Why isn't it confusing today, when we already have these 2
> commands?
> 
> > IMO we should have one (undo) or the other (undo-only + undo-edor) but
> > not mix them by default.
> 
> Whether to mix them or not is up to the user.

I'm coming to this late, and I won't go back & forth
about it.  I have only one thing to say about this
as a general topic (not limited to undo/redo etc.).

1. The Emacs menu should, above all, serve to help
discoverability.  Discovering what's possible, and
discovering what the current, "normal" _Emacs_ key
sequences are that correspond to menu items.

Above all, it's about discovering what _Emacs_ has
to offer.

2. The menu can _also_ include actions that help you
do some things for which we don't bind keyboard keys
- e.g., File > Open File.  This can be particularly
helpful for new users, who might expect something
that corresponds to what they're used to.

#2 is an addition.  It's not (should not be) the
main purpose of Emacs menus.  Emacs menus are for
all levels of Emacs users, and their main purpose
is for discovering - including rediscovering (i.e.,
finding) useful Emacs commands.  The main purpose
is #1, not #2.
___

#2 could (and does already, to some extent) apply
to undo/redo behavior.

IMO, we should definitely _not_ bind undo/redo
behavior to keys by default.  We should want to
lead new users to the _Emacs_ undo behavior,
which is superior to what they're used to.

IMO, this means classic Emacs `undo', but it could
mean `undo-tree' or some new variant that keeps
the power of classic Emacs `undo'.  It doesn't
mean the undo/redo that, say, an MS Word user is
used to.

A user who uses undo/redo from the menu bar should
_not_ see associated key bindings, and thus just
stay with what s?he is already used to instead of
discovering the superior behavior Emacs offers.

A new user will soon enough (maybe not immediately
but soon enough) find out how to bind keys to
commands, and can then bind the existing `undo'
keys (or any others) to undo/redo behavior, if
desired.

I think it would be a mistake if we go down the
road of both (a) offering menu items to accommodate
what newbies might be used to and (b) bind those
commands to keys.

That works against discoverability of Emacs's own,
superior commands.

This is a sense in which I agree with Dmitry about
inconsistency, but my reasoning is different.

Yes, we can discuss and disagree about whether
classic Emacs `undo' is actually superior to the
simple undo/redo that newbies might be used to.

But that's really beside the point I'm making,
which is not particularly about undo.

When we _do_ have a superior behavior, which we
agree about (which might not be the case for undo),
and that is bound to a keyboard key sequence, then
if we also decide to provide a menu item for an
inferior command with behavior closer to what a
newbie might expect, we should, as a general rule,
NOT bind the latter to a keyboard key by default.

RE: Changes for emacs 28

[arthur miller]

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


-------- Originalmeddelande --------
Från: Drew Adams <drew.adams@oracle.com>
Datum: 2020-09-12 18:29 (GMT+01:00)
Till: Arthur Miller <arthur.miller@live.com>, Ergus <spacibba@aol.com>
Kopia: Gregory Heytings <ghe@sdf.org>, emacs-devel@gnu.org, Dmitry Gutov <dgutov@yandex.ru>
Ämne: RE: Changes for emacs 28

> There is  a commercial package called Maya. They have a pop-up
> window/menu widget they call "hot box". In that pop-up they have all, or
> as few as chosen by the user, menus collected in a transparent window
> they pop-up under the mouse after the spacebar is hold for a while (I
> think it was half a second).

`mouse3.el' does this.  But it's initiated by
a right-click, not by holding the space bar.

It could be made to also or instead be initiated
by a keyboard key.  But why?  If the location of
the popup is at the mouse pointer, why make users
involve _both_ the mouse and the keyboard?

--------
Why?  Because you could continue activating menus with keyboard so you don't need to switch to mouse.

Why also a key even if mouse is active? Because holding spacebar with the thumb is very easy and can be done while moving mouse around,  but first reason is more interesting in my opinion.

Also observe that I don't say it is better or faster. As you commented on the part below, I mean it mostly as something that makes Emacs more explorable for people that use starter kits with minimalistic guis where menubars are off etc.

Emacs aleady has all menus explorable from context menu, C-mouse2 opens global menu. "Hot  box" widget differs in how it renders menus, and adds some context sensitive zones, so it is some kind of explorable all-in-one options widget, or I don't know how to call it. Like a global context menu on steroids with prettier presentation then ordinary context menu.

> Maybe such or similar widget could be good to have in Emacs? As a
> compromise between a minimal GUI, discoverability and avialability of
> menus even when gui elements are disabled? A context menu would still be
> faster though.

See `mouse3.el'.  I think it provides what I
think you've described.
-------

I have checked it. It is not even remotely close,  not in a slightest :-).

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

Re: Changes for emacs 28

[Ergus]

Hi I have a set of question:

1) Could we add an option to enable choosing between the traditional
undo or undo-only + undo-redo? something like undo-redo-mode?

if (yes):

2) Where in the menubar-toolbar do you expect it should be added to be
enabled/disabled? Maybe with "Use Cua Keys".

3) Is it possible/should we: add a redo icon in the toolbar
conditionally when the mode is enabled?

else

4) I see a redo added in the menu-bar unconditionally... should we do
the same in the toolbar unconditionally?

Re: Changes for emacs 28

[Caio Henrique]

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

Ergus <spacibba@aol.com> writes:

> 4) I see a redo added in the menu-bar unconditionally... should we do
> the same in the toolbar unconditionally?

I tried adding it to the toolbar just to see how it would look like:


[-- Attachment #2: Redo added to toolbar --]
[-- Type: image/png, Size: 31100 bytes --]

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


Maybe it takes too much horizontal space? I don't know.
___________
diff --git a/lisp/term/x-win.el b/lisp/term/x-win.el
index 42a6f4030e..fa87739c23 100644
--- a/lisp/term/x-win.el
+++ b/lisp/term/x-win.el
@@ -1396,6 +1396,7 @@ x-gtk-stock-map
     ("etc/images/save" . ("document-save" "gtk-save"))
     ("etc/images/saveas" . ("document-save-as" "gtk-save-as"))
     ("etc/images/undo" . ("edit-undo" "gtk-undo"))
+    ("etc/images/redo" . ("edit-redo" "gtk-redo"))
     ("etc/images/cut" . ("edit-cut" "gtk-cut"))
     ("etc/images/copy" . ("edit-copy" "gtk-copy"))
     ("etc/images/paste" . ("edit-paste" "gtk-paste"))
diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
index 7df1e28e06..ac8134dce6 100644
--- a/lisp/tool-bar.el
+++ b/lisp/tool-bar.el
@@ -259,6 +259,7 @@ tool-bar-setup
                               :label "Save")
   (define-key-after (default-value 'tool-bar-map) [separator-1] menu-bar-separator)
   (tool-bar-add-item-from-menu 'undo "undo" nil)
+  (tool-bar-add-item-from-menu 'undo-redo "redo" nil)
   (define-key-after (default-value 'tool-bar-map) [separator-2] menu-bar-separator)
   (tool-bar-add-item-from-menu (lookup-key menu-bar-edit-menu [cut])
                               "cut" nil :vert-only t)
___________

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Caio Henrique <caiohcs0@gmail.com>
> Date: Thu, 10 Sep 2020 22:38:18 -0300
> Cc: Ricardo Wurmus <rekado@elephly.net>, Gregory Heytings <ghe@sdf.org>,
>  Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> > 4) I see a redo added in the menu-bar unconditionally... should we do
> > the same in the toolbar unconditionally?
> 
> I tried adding it to the toolbar just to see how it would look like:

Thanks, but please add a help-echo text for that button.  The menu
item perhaps could do without it, but not the tool-bar button.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 09:58:18 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Caio Henrique <caiohcs0@gmail.com>
    >> Date: Thu, 10 Sep 2020 22:38:18 -0300
    >> Cc: Ricardo Wurmus <rekado@elephly.net>, Gregory Heytings <ghe@sdf.org>,
    >> Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
    >> 
    >> > 4) I see a redo added in the menu-bar unconditionally... should we do
    >> > the same in the toolbar unconditionally?
    >> 
    >> I tried adding it to the toolbar just to see how it would look like:

    Eli> Thanks, but please add a help-echo text for that button.  The menu
    Eli> item perhaps could do without it, but not the tool-bar button.

(enabling and looking at the toolbar for the first time in a decade)

Why have we got separate 'open new file' and 'open existing file'
buttons? You can open an existing one from the dialog that 'open new
file' pops up.

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Caio Henrique <caiohcs0@gmail.com>,  rekado@elephly.net,  ghe@sdf.org,
>   spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 11 Sep 2020 15:57:31 +0200
> 
> Why have we got separate 'open new file' and 'open existing file'
> buttons?

Because most other applications have File->New and File->Open as
separate items.

> You can open an existing one from the dialog that 'open new file'
> pops up.

Yes, we Emacs veterans don't need both.  But the tool bar is not for
us.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 17:04:17 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Caio Henrique <caiohcs0@gmail.com>,  rekado@elephly.net,  ghe@sdf.org,
    >> spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
    >> Date: Fri, 11 Sep 2020 15:57:31 +0200
    >> 
    >> Why have we got separate 'open new file' and 'open existing file'
    >> buttons?

    Eli> Because most other applications have File->New and File->Open as
    Eli> separate items.

Hm, OK. Then if the goal is to save space we could remove the 'Save'
and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
has only icons).

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: caiohcs0@gmail.com,  rekado@elephly.net,  ghe@sdf.org,
>   spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 11 Sep 2020 16:24:23 +0200
> 
> if the goal is to save space we could remove the 'Save'
> and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
> has only icons).

Does the text come from Emacs?  I thought it comes from GTK (I see no
text on MS-Windows, either).

Re: Changes for emacs 28

[Caio Henrique]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: caiohcs0@gmail.com,  rekado@elephly.net,  ghe@sdf.org,
>>   spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Fri, 11 Sep 2020 16:24:23 +0200
>> 
>> if the goal is to save space we could remove the 'Save'
>> and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
>> has only icons).
>
> Does the text come from Emacs?  I thought it comes from GTK (I see no
> text on MS-Windows, either).

(setq tool-bar-style 'image)

That should do the trick for GTK. Maybe this should be its default value?

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 13:12:05 -0300, Caio Henrique <caiohcs0@gmail.com> said:

    Caio> Eli Zaretskii <eliz@gnu.org> writes:
    >>> From: Robert Pluim <rpluim@gmail.com>
    >>> Cc: caiohcs0@gmail.com,  rekado@elephly.net,  ghe@sdf.org,
    >>> spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
    >>> Date: Fri, 11 Sep 2020 16:24:23 +0200
    >>> 
    >>> if the goal is to save space we could remove the 'Save'
    >>> and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
    >>> has only icons).
    >> 
    >> Does the text come from Emacs?  I thought it comes from GTK (I see no
    >> text on MS-Windows, either).

    Caio> (setq tool-bar-style 'image)

    Caio> That should do the trick for GTK. Maybe this should be its default value?

I agree (but I donʼt use the toolbar :-) )

Re: Changes for emacs 28

[Caio Henrique]

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

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Fri, 11 Sep 2020 13:12:05 -0300, Caio Henrique <caiohcs0@gmail.com> said:
>
>     Caio> Eli Zaretskii <eliz@gnu.org> writes:
>     >>> From: Robert Pluim <rpluim@gmail.com>
>     >>> Cc: caiohcs0@gmail.com,  rekado@elephly.net,  ghe@sdf.org,
>     >>> spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
>     >>> Date: Fri, 11 Sep 2020 16:24:23 +0200
>     >>> 
>     >>> if the goal is to save space we could remove the 'Save'
>     >>> and 'Undo' text in the toolbar under Gnu/Linux (the toolbar on macOS
>     >>> has only icons).
>     >> 
>     >> Does the text come from Emacs?  I thought it comes from GTK (I see no
>     >> text on MS-Windows, either).
>
>     Caio> (setq tool-bar-style 'image)
>
>     Caio> That should do the trick for GTK. Maybe this should be its default value?
>
> I agree (but I donʼt use the toolbar :-) )


I believe that this is a bug (see the images attached comparing before
and after this patch). 

_____
diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
index 7df1e28e06..bec45c1ea4 100644
--- a/lisp/tool-bar.el
+++ b/lisp/tool-bar.el
@@ -256,9 +256,9 @@ tool-bar-setup
   (tool-bar-add-item-from-menu 'dired "diropen" nil :vert-only t)
   (tool-bar-add-item-from-menu 'kill-this-buffer "close" nil :vert-only t)
   (tool-bar-add-item-from-menu 'save-buffer "save" nil
-			       :label "Save")
+			       :label "Save" :vert-only t)
   (define-key-after (default-value 'tool-bar-map) [separator-1] menu-bar-separator)
-  (tool-bar-add-item-from-menu 'undo "undo" nil)
+  (tool-bar-add-item-from-menu 'undo "undo" nil :vert-only t)
   (define-key-after (default-value 'tool-bar-map) [separator-2] menu-bar-separator)
   (tool-bar-add-item-from-menu (lookup-key menu-bar-edit-menu [cut])
 			       "cut" nil :vert-only t)
_____



[-- Attachment #2: toolbar before 1 --]
[-- Type: image/png, Size: 23688 bytes --]

[-- Attachment #3: toolbar before 2 --]
[-- Type: image/png, Size: 28526 bytes --]

[-- Attachment #4: toolbar after patch 1 --]
[-- Type: image/png, Size: 24166 bytes --]

[-- Attachment #5: toolbar patched 2 --]
[-- Type: image/png, Size: 31321 bytes --]

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 03:29:34PM -0300, Caio Henrique wrote:
>Robert Pluim <rpluim@gmail.com> writes:
>
>
>
>I believe that this is a bug (see the images attached comparing before
>and after this patch).
>
>_____
>diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
>index 7df1e28e06..bec45c1ea4 100644
>--- a/lisp/tool-bar.el
>+++ b/lisp/tool-bar.el
>@@ -256,9 +256,9 @@ tool-bar-setup
>   (tool-bar-add-item-from-menu 'dired "diropen" nil :vert-only t)
>   (tool-bar-add-item-from-menu 'kill-this-buffer "close" nil :vert-only t)
>   (tool-bar-add-item-from-menu 'save-buffer "save" nil
>-			       :label "Save")
>+			       :label "Save" :vert-only t)
>   (define-key-after (default-value 'tool-bar-map) [separator-1] menu-bar-separator)
>-  (tool-bar-add-item-from-menu 'undo "undo" nil)
>+  (tool-bar-add-item-from-menu 'undo "undo" nil :vert-only t)
>   (define-key-after (default-value 'tool-bar-map) [separator-2] menu-bar-separator)
>   (tool-bar-add-item-from-menu (lookup-key menu-bar-edit-menu [cut])
> 			       "cut" nil :vert-only t)
>_____
>
>

Why you think it is a bug? :vert-only means exactly what I see.

Re: Changes for emacs 28

[Caio Henrique]

Ergus <spacibba@aol.com> writes:

> Why you think it is a bug? :vert-only means exactly what I see.

Sorry, "bug" was the wrong word, it is just an inconsistency IMO since
all other buttons are vertical only.

Re: Changes for emacs 28

[Thibaut Verron]

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

Wouldn't File > New in most other applications be more akin to switching to
an empty buffer with no associated file?

Le ven. 11 sept. 2020 à 16:05, Eli Zaretskii <eliz@gnu.org> a écrit :

> > From: Robert Pluim <rpluim@gmail.com>
> > Cc: Caio Henrique <caiohcs0@gmail.com>,  rekado@elephly.net,
> ghe@sdf.org,
> >   spacibba@aol.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> > Date: Fri, 11 Sep 2020 15:57:31 +0200
> >
> > Why have we got separate 'open new file' and 'open existing file'
> > buttons?
>
> Because most other applications have File->New and File->Open as
> separate items.
>
> > You can open an existing one from the dialog that 'open new file'
> > pops up.
>
> Yes, we Emacs veterans don't need both.  But the tool bar is not for
> us.
>
>

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

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Fri, 11 Sep 2020 17:16:33 +0200
> Cc: Robert Pluim <rpluim@gmail.com>, spacibba@aol.com, caiohcs0@gmail.com, 
> 	emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com
> 
> Wouldn't File > New in most other applications be more akin to switching to an empty buffer with no
> associated file? 

"Other applications" mostly don't support buffers with no associated
files, so we had to make a decision which of these two to use.  Since
those other applications force you to decide on exit whether to save
your edits or not, we decided it was more like what Emacs does with
buffers that do visit files.

Re: Changes for emacs 28

[Thibaut Verron]

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

Le ven. 11 sept. 2020 à 17:21, Eli Zaretskii <eliz@gnu.org> a écrit :

> > From: Thibaut Verron <thibaut.verron@gmail.com>
> > Date: Fri, 11 Sep 2020 17:16:33 +0200
> > Cc: Robert Pluim <rpluim@gmail.com>, spacibba@aol.com,
> caiohcs0@gmail.com,
> >       emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org,
> drew.adams@oracle.com
> >
> > Wouldn't File > New in most other applications be more akin to switching
> to an empty buffer with no
> > associated file?
>
> "Other applications" mostly don't support buffers with no associated
> files, so we had to make a decision which of these two to use.  Since
> those other applications force you to decide on exit whether to save
> your edits or not, we decided it was more like what Emacs does with
> buffers that do visit files.
>

Don't they? As far as I can remember, Libreoffice does, MS office does,
Notepad does...

They call it "new document" rather than "new file" for this reason, I
guess.

Maybe this button could be bound to a function creating a new buffer with a
name like *unnamed[-n]*, and also mark these buffers for query for save on
exit?

>

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

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Fri, 11 Sep 2020 17:36:24 +0200
> Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com, 
> 	emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com
> 
>  "Other applications" mostly don't support buffers with no associated
>  files, so we had to make a decision which of these two to use.  Since
>  those other applications force you to decide on exit whether to save
>  your edits or not, we decided it was more like what Emacs does with
>  buffers that do visit files.
> 
> Don't they? As far as I can remember, Libreoffice does, MS office does, Notepad does... 
> 
> They call it "new document" rather than "new file" for this reason, I guess. 

And ask you where to save it when you exit.  That's what Emacs does
with file-visiting buffers.

> Maybe this button could be bound to a function creating a new buffer with a name like *unnamed[-n]*, and
> also mark these buffers for query for save on exit? 

AFAIR, that was considered.  Maybe you want to read those old
discussions.

Re: Changes for emacs 28

[Thibaut Verron]

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

Le ven. 11 sept. 2020 à 17:49, Eli Zaretskii <eliz@gnu.org> a écrit :

> > From: Thibaut Verron <thibaut.verron@gmail.com>
> > Date: Fri, 11 Sep 2020 17:36:24 +0200
> > Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com,
> >       emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org,
> drew.adams@oracle.com
> >
> >  "Other applications" mostly don't support buffers with no associated
> >  files, so we had to make a decision which of these two to use.  Since
> >  those other applications force you to decide on exit whether to save
> >  your edits or not, we decided it was more like what Emacs does with
> >  buffers that do visit files.
> >
> > Don't they? As far as I can remember, Libreoffice does, MS office does,
> Notepad does...
> >
> > They call it "new document" rather than "new file" for this reason, I
> guess.
>
> And ask you where to save it when you exit.  That's what Emacs does
> with file-visiting buffers.
>

Yes but if you don't want to save it, you can just click discard and never
input a path. With the current setting you need to choose a path before you
can write text.


> > Maybe this button could be bound to a function creating a new buffer
> with a name like *unnamed[-n]*, and
> > also mark these buffers for query for save on exit?
>
> AFAIR, that was considered.  Maybe you want to read those old
> discussions.
>

Right, I will. :) No need to run in circles.

>

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

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Fri, 11 Sep 2020 18:20:57 +0200
> Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com, 
> 	emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com
> 
>  > They call it "new document" rather than "new file" for this reason, I guess. 
> 
>  And ask you where to save it when you exit.  That's what Emacs does
>  with file-visiting buffers.
> 
> Yes but if you don't want to save it, you can just click discard and never input a path. With the current setting
> you need to choose a path before you can write text. 

But with a buffer that doesn't visit a file, you don't get any prompt
at all.

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Fri, 11 Sep 2020 21:24:17 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Thibaut Verron <thibaut.verron@gmail.com>
    >> Date: Fri, 11 Sep 2020 18:20:57 +0200
    >> Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com, 
    >> emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com
    >> 
    >> > They call it "new document" rather than "new file" for this reason, I guess. 
    >> 
    >> And ask you where to save it when you exit.  That's what Emacs does
    >> with file-visiting buffers.
    >> 
    >> Yes but if you don't want to save it, you can just click discard and never input a path. With the current setting
    >> you need to choose a path before you can write text. 

    Eli> But with a buffer that doesn't visit a file, you don't get any prompt
    Eli> at all.

We could set 'kill-buffer-hook' to a querying function in buffers
created via the toolbar.

Robert

Re: Changes for emacs 28

[Thibaut Verron]

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

Le lun. 14 sept. 2020 à 09:37, Robert Pluim <rpluim@gmail.com> a écrit :

> >>>>> On Fri, 11 Sep 2020 21:24:17 +0300, Eli Zaretskii <eliz@gnu.org>
> said:
>
>     >> From: Thibaut Verron <thibaut.verron@gmail.com>
>     >> Date: Fri, 11 Sep 2020 18:20:57 +0200
>     >> Cc: rpluim@gmail.com, spacibba@aol.com, caiohcs0@gmail.com,
>     >> emacs-devel@gnu.org, rekado@elephly.net, ghe@sdf.org,
> drew.adams@oracle.com
>     >>
>     >> > They call it "new document" rather than "new file" for this
> reason, I guess.
>     >>
>     >> And ask you where to save it when you exit.  That's what Emacs does
>     >> with file-visiting buffers.
>     >>
>     >> Yes but if you don't want to save it, you can just click discard
> and never input a path. With the current setting
>     >> you need to choose a path before you can write text.
>
>     Eli> But with a buffer that doesn't visit a file, you don't get any
> prompt
>     Eli> at all.
>
> We could set 'kill-buffer-hook' to a querying function in buffers
> created via the toolbar.
>

There is already a (buffer-local) variable buffer-offer-save which, set to
'always, causes save-some-buffers to query for save the corresponding
buffer, if non-empty.

And save-buffers-kill-emacs calls save-some-buffers with the second
argument set to t, aka, "also save some non-file buffers".

It really looks as if this scenario is already planned, but just not for
entry from the tool-bar.

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

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Mon, 14 Sep 2020 09:53:28 +0200, Thibaut Verron <thibaut.verron@gmail.com> said:
    >> 
    >> We could set 'kill-buffer-hook' to a querying function in buffers
    >> created via the toolbar.
    >> 

    Thibaut> There is already a (buffer-local) variable buffer-offer-save which, set to
    Thibaut> 'always, causes save-some-buffers to query for save the corresponding
    Thibaut> buffer, if non-empty.

Right, but toolbar-save doesnʼt run save-some-buffers. That could be
added, but it seems people feel toolbar space is precious (here the
default toolbar uses slightly more than 50% of the available width
when running -Q)

    Thibaut> And save-buffers-kill-emacs calls save-some-buffers with the second
    Thibaut> argument set to t, aka, "also save some non-file buffers".

    Thibaut> It really looks as if this scenario is already planned, but just not for
    Thibaut> entry from the tool-bar.

That covers the 'exiting emacs' scenario, weʼd still need something to
cover the 'clicked the kill-buffer button'. Or if we really want to go
whole hog, we automatically save the state of buffers created via the
toolbar, and restore them on startup.

Robert

Re: Changes for emacs 28

[Thibaut Verron]

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

Le lun. 14 sept. 2020 à 13:54, Robert Pluim <rpluim@gmail.com> a écrit :

> >>>>> On Mon, 14 Sep 2020 09:53:28 +0200, Thibaut Verron <
> thibaut.verron@gmail.com> said:
>     >>
>     >> We could set 'kill-buffer-hook' to a querying function in buffers
>     >> created via the toolbar.
>     >>
>
>     Thibaut> There is already a (buffer-local) variable buffer-offer-save
> which, set to
>     Thibaut> 'always, causes save-some-buffers to query for save the
> corresponding
>     Thibaut> buffer, if non-empty.
>
> Right, but toolbar-save doesnʼt run save-some-buffers. That could be
> added, but it seems people feel toolbar space is precious (here the
> default toolbar uses slightly more than 50% of the available width
> when running -Q)
>

The save button runs save-buffer, so it should DTRT already, no?


> That covers the 'exiting emacs' scenario, weʼd still need something to
> cover the 'clicked the kill-buffer button'.


That's correct, I didn't have this usage in mind. Kill-buffer-hook seems to
be more for cleanup, but kill-buffer-query-functions could do the job as a
first step (as in, "do you really want to kill without saving?"). I believe
that
the most natural would be to add such a test to kill-buffer, since it
already
takes care of modified file buffers.

All those approaches would also affect other commands killing the buffer,
preventing a user from accidentally losing data because of an unfortunate
keypress.


Or if we really want to go
> whole hog, we automatically save the state of buffers created via the
> toolbar, and restore them on startup.
>

Restoring them as-is is what notepad++ does (or did when I last used it
10 years ago). I personally did not like this behavior, and I didn't have
remotely as many open files in notepad++ as I do in a typical emacs session.

On the other hand, auto-saving and offering to restore could be sensible.

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

Re: Changes for emacs 28

[Stefan Monnier]

>     Eli> But with a buffer that doesn't visit a file, you don't get any prompt
>     Eli> at all.
> We could set 'kill-buffer-hook' to a querying function in buffers
> created via the toolbar.

Beside this question of "save" there's also the issue of "autosave".

Why not create a new and "normal" file-buffer whose file name is
something like `~/.emacs.d/newfiles/untitled<N>`?


        Stefan

Re: Changes for emacs 28

[Andreas Schwab]

On Sep 14 2020, Stefan Monnier wrote:

> Why not create a new and "normal" file-buffer whose file name is
> something like `~/.emacs.d/newfiles/untitled<N>`?

The file name also sets the major mode for the buffer.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 01:14:20 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Ricardo Wurmus <rekado@elephly.net>, Gregory Heytings <ghe@sdf.org>,
>  emacs-devel@gnu.org
> 
> 3) Is it possible/should we: add a redo icon in the toolbar
> conditionally when the mode is enabled?
> 
> else
> 
> 4) I see a redo added in the menu-bar unconditionally... should we do
> the same in the toolbar unconditionally?

I indeed think that the Redo icon should be added unconditionally
(enabled only when there's something to redo, like the menu item).

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 09:39, Eli Zaretskii wrote:
>> Date: Fri, 11 Sep 2020 01:14:20 +0200
>> From: Ergus<spacibba@aol.com>
>> Cc: Ricardo Wurmus<rekado@elephly.net>, Gregory Heytings<ghe@sdf.org>,
>>   emacs-devel@gnu.org
>>
>> 3) Is it possible/should we: add a redo icon in the toolbar
>> conditionally when the mode is enabled?
>>
>> else
>>
>> 4) I see a redo added in the menu-bar unconditionally... should we do
>> the same in the toolbar unconditionally?
> I indeed think that the Redo icon should be added unconditionally
> (enabled only when there's something to redo, like the menu item).

Are you not worried about the divergence between the menu items and the 
toolbar, and the actual available bindings?

And also about the fact the menu item next to 'redo' doesn't call 
'undo-only'? Which will be contrary to the expectations of users who 
know the concept of 'redo' from other programs.

I think this created a potential for additional user confusion.

A global mode like undo-redo-mode, like suggested by Ergus, would avoid 
both of these problems. We'd only need to find a key for 'undo-redo'.

Perhaps, 'M-_' and 'C-?'? That's what undo-tree uses by default.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: rekado@elephly.net, ghe@sdf.org, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 11 Sep 2020 13:10:29 +0300
> 
> >> 4) I see a redo added in the menu-bar unconditionally... should we do
> >> the same in the toolbar unconditionally?
> > I indeed think that the Redo icon should be added unconditionally
> > (enabled only when there's something to redo, like the menu item).
> 
> Are you not worried about the divergence between the menu items and the 
> toolbar, and the actual available bindings?

I see no divergence in the proposal.  So no, I'm not worried.

> And also about the fact the menu item next to 'redo' doesn't call 
> 'undo-only'?

What is "the menu item next to 'redo'"?

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 13:33, Eli Zaretskii wrote:
> What is "the menu item next to 'redo'"?

'undo'.

As opposed to 'undo-only'.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 11 Sep 2020 13:36:25 +0300
> Cc: rekado@elephly.net, ghe@sdf.org, spacibba@aol.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> 
> On 11.09.2020 13:33, Eli Zaretskii wrote:
> > What is "the menu item next to 'redo'"?
> 
> 'undo'.
> 
> As opposed to 'undo-only'.

If people prefer that, we could change the binding, I won't object.

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 13:41, Eli Zaretskii wrote:
> If people prefer that, we could change the binding, I won't object.

But then we'll have no binding for `undo-redo`, just a menu item?

Or would you be fine with adding a binding for it too?

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 02:09:17PM +0300, Dmitry Gutov wrote:
>On 11.09.2020 13:41, Eli Zaretskii wrote:
>>If people prefer that, we could change the binding, I won't object.
>
>But then we'll have no binding for `undo-redo`, just a menu item?
>
>Or would you be fine with adding a binding for it too?
>
Do you think we should go with the mode approach?

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 14:19, Ergus wrote:
> On Fri, Sep 11, 2020 at 02:09:17PM +0300, Dmitry Gutov wrote:
>> On 11.09.2020 13:41, Eli Zaretskii wrote:
>>> If people prefer that, we could change the binding, I won't object.
>>
>> But then we'll have no binding for `undo-redo`, just a menu item?
>>
>> Or would you be fine with adding a binding for it too?
>>
> Do you think we should go with the mode approach?

Either that, or switch to undo-only and undo-redo bindings in the 
default set.

But I don't think we'll reach an agreement for the latter anytime soon. 
So the gradual approach seems more in line with the usual Emacs evolution.

Said mode could be an easy switch to the alternative undo behavior. We 
can announce it availability prominently, and sometime after we could 
discuss whether that mode should be on by default. If we do, people who 
prefer the old way could easily disable it then, that's also a plus.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: rekado@elephly.net, ghe@sdf.org, spacibba@aol.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 11 Sep 2020 14:09:17 +0300
> 
> On 11.09.2020 13:41, Eli Zaretskii wrote:
> > If people prefer that, we could change the binding, I won't object.
> 
> But then we'll have no binding for `undo-redo`, just a menu item?
> 
> Or would you be fine with adding a binding for it too?

Why do we need a binding for it in the default configuration?  Not
every command available through the menus has a keybinding by default.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 03:04:50PM +0300, Eli Zaretskii wrote:
>> Cc: rekado@elephly.net, ghe@sdf.org, spacibba@aol.com, drew.adams@oracle.com,
>>  emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Fri, 11 Sep 2020 14:09:17 +0300
>>
>> On 11.09.2020 13:41, Eli Zaretskii wrote:
>> > If people prefer that, we could change the binding, I won't object.
>>
>> But then we'll have no binding for `undo-redo`, just a menu item?
>>
>> Or would you be fine with adding a binding for it too?
>
>Why do we need a binding for it in the default configuration?  Not
>every command available through the menus has a keybinding by default.
>
Hi Eli:

Could you reconsider my proposal of an undo-redo-mode to:

- Add the extra icon in the toolbar.
- Change the undo action in menu-bar and tool-bar by undo-only instead.
- Bind undo-redo to something in the keyboard.
- To enable it in some of the proposed user "profiles"
- Not bother the users that somehow won't like to have all that.

Having undo with an undo-redo in the same "state" could be confusing as
the normal undo could do also redo IMO.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 14:19:19 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, rekado@elephly.net, ghe@sdf.org,
> 	drew.adams@oracle.com, emacs-devel@gnu.org
> 
> Could you reconsider my proposal of an undo-redo-mode to:
> 
> - Add the extra icon in the toolbar.

I believe I already agreed to that.  We even had a patch posted for
it, and I commented on it.

> - Change the undo action in menu-bar and tool-bar by undo-only instead.

We need more opinions for this one.  If many people agree to it, I
won't object.

> - Bind undo-redo to something in the keyboard.

If you can find a good key that is vacant, sure, why not?

> - To enable it in some of the proposed user "profiles"

Since we don't have any profiles yet, this is not something we can do.

> - Not bother the users that somehow won't like to have all that.

Having said all of the above, I'm now asking myself (and you) why do
we have to have a special mode for this?  None of these measures
contradicts the default operation of undo via C-/, so we could simply
have this by default.

> Having undo with an undo-redo in the same "state" could be confusing as
> the normal undo could do also redo IMO.

If the user uses the menus or the tool bar, the confusion will be
spared, right?

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 03:35:40PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 11 Sep 2020 14:19:19 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Dmitry Gutov <dgutov@yandex.ru>, rekado@elephly.net, ghe@sdf.org,
>> 	drew.adams@oracle.com, emacs-devel@gnu.org
>>
>> Could you reconsider my proposal of an undo-redo-mode to:
>>
>> - Add the extra icon in the toolbar.
>
>I believe I already agreed to that.  We even had a patch posted for
>it, and I commented on it.
>
I mean conditionally in the mode ;p

>> - Change the undo action in menu-bar and tool-bar by undo-only instead.
>
>We need more opinions for this one.  If many people agree to it, I
>won't object.
>
That's why we need the mode. Normally there is not agreement about
changes of this kind, so user can set it on demand if they prefer it.

>> - Bind undo-redo to something in the keyboard.
>
>If you can find a good key that is vacant, sure, why not?
>
C-? and M-_ are generally used in the packages around and they make
sense with the current ones.

>> - To enable it in some of the proposed user "profiles"
>
>Since we don't have any profiles yet, this is not something we can do.
>
>> - Not bother the users that somehow won't like to have all that.
>
>Having said all of the above, I'm now asking myself (and you) why do
>we have to have a special mode for this?  None of these measures
>contradicts the default operation of undo via C-/, so we could simply
>have this by default.
>
The mode will substitute undo with undo-only. This small contradiction
will start a war here.

>> Having undo with an undo-redo in the same "state" could be confusing as
>> the normal undo could do also redo IMO.
>
>If the user uses the menus or the tool bar, the confusion will be
>spared, right?
>
If the user expects undo-only behavior; then having our undo will be
confusing because not expecting undo becoming a redo at some point.

IMO we should have one (undo) or the other (undo-only + undo-edor) but
not mix them by default.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 14:57:44 +0200
> From: Ergus <spacibba@aol.com>
> Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
> 	drew.adams@oracle.com, dgutov@yandex.ru
> 
> The mode will substitute undo with undo-only. This small contradiction
> will start a war here.

As long as we keep this on the menu and the tool bar, there will be no
reason for a "war".

> >> Having undo with an undo-redo in the same "state" could be confusing as
> >> the normal undo could do also redo IMO.
> >
> >If the user uses the menus or the tool bar, the confusion will be
> >spared, right?
> >
> If the user expects undo-only behavior; then having our undo will be
> confusing because not expecting undo becoming a redo at some point.

How can it be confusing that 2 different commands produce different
results?  Why isn't it confusing today, when we already have these 2
commands?

> IMO we should have one (undo) or the other (undo-only + undo-edor) but
> not mix them by default.

Whether to mix them or not is up to the user.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 16:04:48 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: rekado@elephly.net, ghe@sdf.org, dgutov@yandex.ru, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> 
> > Date: Fri, 11 Sep 2020 14:57:44 +0200
> > From: Ergus <spacibba@aol.com>
> > Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
> > 	drew.adams@oracle.com, dgutov@yandex.ru
> > 
> > The mode will substitute undo with undo-only. This small contradiction
> > will start a war here.
> 
> As long as we keep this on the menu and the tool bar, there will be no
> reason for a "war".
> 
> > >> Having undo with an undo-redo in the same "state" could be confusing as
> > >> the normal undo could do also redo IMO.
> > >
> > >If the user uses the menus or the tool bar, the confusion will be
> > >spared, right?
> > >
> > If the user expects undo-only behavior; then having our undo will be
> > confusing because not expecting undo becoming a redo at some point.
> 
> How can it be confusing that 2 different commands produce different
> results?  Why isn't it confusing today, when we already have these 2
> commands?
> 
> > IMO we should have one (undo) or the other (undo-only + undo-edor) but
> > not mix them by default.
> 
> Whether to mix them or not is up to the user.

To clarify: I'm not opposed to your proposal of having a special mode,
I just think it's an unnecessary complication, and actually flies in
the face of our desire to make Emacs easier for newbies: a mode that
is not turned on by default needs to be discovered and turned on,
before its benefits can be apparent.  Having these commands available
by default doesn't have this disadvantage.

Re: Changes for emacs 28

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 11 Sep 2020 16:04:48 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: rekado@elephly.net, ghe@sdf.org, dgutov@yandex.ru, drew.adams@oracle.com,
>>  emacs-devel@gnu.org
>> 
>> > Date: Fri, 11 Sep 2020 14:57:44 +0200
>> > From: Ergus <spacibba@aol.com>
>> > Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>> > 	drew.adams@oracle.com, dgutov@yandex.ru
>> > 
>> > The mode will substitute undo with undo-only. This small contradiction
>> > will start a war here.
>> 
>> As long as we keep this on the menu and the tool bar, there will be no
>> reason for a "war".
>> 
>> > >> Having undo with an undo-redo in the same "state" could be confusing as
>> > >> the normal undo could do also redo IMO.
>> > >
>> > >If the user uses the menus or the tool bar, the confusion will be
>> > >spared, right?
>> > >
>> > If the user expects undo-only behavior; then having our undo will be
>> > confusing because not expecting undo becoming a redo at some point.
>> 
>> How can it be confusing that 2 different commands produce different
>> results?  Why isn't it confusing today, when we already have these 2
>> commands?
>> 
>> > IMO we should have one (undo) or the other (undo-only + undo-edor) but
>> > not mix them by default.
>> 
>> Whether to mix them or not is up to the user.
>
> To clarify: I'm not opposed to your proposal of having a special mode,
> I just think it's an unnecessary complication, and actually flies in
> the face of our desire to make Emacs easier for newbies: a mode that
> is not turned on by default needs to be discovered and turned on,
> before its benefits can be apparent.  Having these commands available
> by default doesn't have this disadvantage.

They don't need to know that it is a mode and it can be on by default.
Users just need to know it is a "feature" which they can switch off or
on. Being a mode could be just an so called implemetation detail. I
don't see personally what extra a mode brings in, but when it comes to
discoverability it can still be "just a feature".

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 16:04, Eli Zaretskii wrote:
>> Date: Fri, 11 Sep 2020 14:57:44 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>> 	drew.adams@oracle.com, dgutov@yandex.ru
>>
>> The mode will substitute undo with undo-only. This small contradiction
>> will start a war here.
> 
> As long as we keep this on the menu and the tool bar, there will be no
> reason for a "war".

So there will be contradiction between the menu and the keyboard?

>>>> Having undo with an undo-redo in the same "state" could be confusing as
>>>> the normal undo could do also redo IMO.
>>>
>>> If the user uses the menus or the tool bar, the confusion will be
>>> spared, right?
>>>
>> If the user expects undo-only behavior; then having our undo will be
>> confusing because not expecting undo becoming a redo at some point.
> 
> How can it be confusing that 2 different commands produce different
> results?  Why isn't it confusing today, when we already have these 2
> commands?

The menu item doesn't exactly say which command it is invoking.

>> IMO we should have one (undo) or the other (undo-only + undo-edor) but
>> not mix them by default.
> 
> Whether to mix them or not is up to the user.

This has been true before the menu items were added, and will continue 
to be true if/when we change the default bindings.

So I think that statement is missing the point: we should endeavor for 
predictable and consistent sets of menu items, key bindings, and other 
features.

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 12:00:48AM +0300, Dmitry Gutov wrote:
>On 11.09.2020 16:04, Eli Zaretskii wrote:
>>>Date: Fri, 11 Sep 2020 14:57:44 +0200
>>>From: Ergus <spacibba@aol.com>
>>>Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>>>	drew.adams@oracle.com, dgutov@yandex.ru
>>>
>>>The mode will substitute undo with undo-only. This small contradiction
>>>will start a war here.
>>
>>As long as we keep this on the menu and the tool bar, there will be no
>>reason for a "war".
>
>So there will be contradiction between the menu and the keyboard?
>
Hopefully not: With the undo-redo-mode; undo icon will do undo-only as
well as the keyboard and toolbar-icon.

Otherwise; maybe it is easier to keep everything there as now (undo and
redo in toolbar and menubar and no undo-redo-mode) but add an option
like default-undo-command to set the undo-only as the default undo
either in the keyboard, toolbar and menubar if someone (like me) don't
like at all the default undo.

I don't know if that's possible with a simple remap... is it?

BTW: everybody agrees in set undo-redo to C-? and M-_??

>>>>>Having undo with an undo-redo in the same "state" could be confusing as
>>>>>the normal undo could do also redo IMO.
>>>>
>>>>If the user uses the menus or the tool bar, the confusion will be
>>>>spared, right?
>>>>
>>>If the user expects undo-only behavior; then having our undo will be
>>>confusing because not expecting undo becoming a redo at some point.
>>
>>How can it be confusing that 2 different commands produce different
>>results?  Why isn't it confusing today, when we already have these 2
>>commands?
>
>The menu item doesn't exactly say which command it is invoking.
>
>>>IMO we should have one (undo) or the other (undo-only + undo-edor) but
>>>not mix them by default.
>>
>>Whether to mix them or not is up to the user.
>
>This has been true before the menu items were added, and will continue 
>to be true if/when we change the default bindings.
>
>So I think that statement is missing the point: we should endeavor for 
>predictable and consistent sets of menu items, key bindings, and other 
>features.
>
Personally I still think that a mode is better. But I trust more in Eli's
opinion than mine in this topics.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 00:17, Ergus wrote:
> On Sat, Sep 12, 2020 at 12:00:48AM +0300, Dmitry Gutov wrote:

>> So there will be contradiction between the menu and the keyboard?
>>
> Hopefully not: With the undo-redo-mode; undo icon will do undo-only as
> well as the keyboard and toolbar-icon.

Indeed.

> Otherwise; maybe it is easier to keep everything there as now (undo and
> redo in toolbar and menubar and no undo-redo-mode) but add an option
> like default-undo-command to set the undo-only as the default undo
> either in the keyboard, toolbar and menubar if someone (like me) don't
> like at all the default undo.
> 
> I don't know if that's possible with a simple remap... is it?

It's unlikely to be as seamless as toggling undo-redo-mode.

> BTW: everybody agrees in set undo-redo to C-? and M-_??

No objections so far, and the bindings are free, so...

We can change the exact keys later anyway.

> Personally I still think that a mode is better. But I trust more in Eli's
> opinion than mine in this topics.

Since Eli clarified that his objection is not hard (email from 
11.09.2020, 16:13), perhaps you should go ahead and propose a concrete 
patch for review.

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 01:29:42AM +0300, Dmitry Gutov wrote:
>On 12.09.2020 00:17, Ergus wrote:
>>On Sat, Sep 12, 2020 at 12:00:48AM +0300, Dmitry Gutov wrote:
>
>>>So there will be contradiction between the menu and the keyboard?
>>>
>>Hopefully not: With the undo-redo-mode; undo icon will do undo-only as
>>well as the keyboard and toolbar-icon.
>
>Indeed.
>
>>Otherwise; maybe it is easier to keep everything there as now (undo and
>>redo in toolbar and menubar and no undo-redo-mode) but add an option
>>like default-undo-command to set the undo-only as the default undo
>>either in the keyboard, toolbar and menubar if someone (like me) don't
>>like at all the default undo.
>>
>>I don't know if that's possible with a simple remap... is it?
>
>It's unlikely to be as seamless as toggling undo-redo-mode.
>

>>BTW: everybody agrees in set undo-redo to C-? and M-_??
>
>No objections so far, and the bindings are free, so...
>
>We can change the exact keys later anyway.
>
>>Personally I still think that a mode is better. But I trust more in Eli's
>>opinion than mine in this topics.
>
>Since Eli clarified that his objection is not hard (email from 
>11.09.2020, 16:13), perhaps you should go ahead and propose a concrete 
>patch for review.

Actually the implementation is barely trivial; something like this
should work (including tool-bar and menu-bar) because the redo icon is
already there; so we only add the bindings for it until it will be added
by default:

(defvar undo-redo-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map [remap undo] 'undo-only)
     (define-key map (kbd "C-?") 'undo-redo)
     (define-key map (kbd "M-_") 'undo-redo)
     map))

(define-minor-mode undo-redo-mode
   "Replace undo with undo-only and enables undo-redo."
   :global t
   :keymap undo-redo-mode-map
   :group 'undo
   )

As it seems like the redo will stay by default as well as the bindings,
then the mode is probably not needed and the user could just bind:

(define-key global-map [remap undo] 'undo-only)

if he don't like to use the default undo.

If we remove the redo from the menu and toolbar and or the default
bindings; then some other small changes will be needed and will make
sense to have this mode. But so far nobody complained about the redo
icon and personally I don't really care too much.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 05:01, Ergus wrote:

> Actually the implementation is barely trivial; something like this
> should work (including tool-bar and menu-bar) because the redo icon is
> already there; so we only add the bindings for it until it will be added
> by default:

I agree it is simple, but a concrete patch would be another step toward 
the goal.

> (defvar undo-redo-mode-map
>    (let ((map (make-sparse-keymap)))
>      (define-key map [remap undo] 'undo-only)
>      (define-key map (kbd "C-?") 'undo-redo)
>      (define-key map (kbd "M-_") 'undo-redo)
>      map))
> 
> (define-minor-mode undo-redo-mode
>    "Replace undo with undo-only and enables undo-redo."
>    :global t
>    :keymap undo-redo-mode-map
>    :group 'undo
>    )
> 
> As it seems like the redo will stay by default as well as the bindings,
> then the mode is probably not needed and the user could just bind:

Indeed, so IMO the mode should affect the toolbar and the menu as well.

> (define-key global-map [remap undo] 'undo-only)
> 
> if he don't like to use the default undo.

That's a decent point, but this setup is missing the new bindings for 
undo-redo. It also won't help with the low discoverability that 
undo-only and undo-redo have.

And since the main moment when we would expect someone to want this is 
just when they are becoming familiar with Emacs, making it as easy as 
possible should be the goal.

> If we remove the redo from the menu and toolbar and or the default
> bindings; then some other small changes will be needed and will make
> sense to have this mode. But so far nobody complained about the redo
> icon and personally I don't really care too much.

If we're talking about existing, experienced users such as you and I, we 
might as well leave _everything_ as is, and customize whatever bits in 
the init scripts. But we're probably talking about new user experience.

Re: Changes for emacs 28

[Richard Stallman]

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

There are two problems with C-?:

* It requires two shift keys, so it is inconvenient.
(The bindings for undo ensure it can be typed with just one
shift key on all usual terminals.)

* It does not exist at all on ttys.  (I don't know whether we can
change that on Linux consoles.)

Whether constitutes a problem for the undo-redo feature depends on the
precise meanings of the two commands.  I don't know those details
so I can't judge.

M-_ is likewise inconvenient because of the need for two shift keys.

Defining these keys in addition to the existing binding for 'undo'
can't do direct harm.  But it may disappoint the users you're trying
to help.


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

Re: Changes for emacs 28

[Yuri Khan]

On Sun, 13 Sep 2020 at 10:57, Richard Stallman <rms@gnu.org> wrote:

> There are two problems with C-?:
>
> * It requires two shift keys, so it is inconvenient.
> (The bindings for undo ensure it can be typed with just one
> shift key on all usual terminals.)
>
> M-_ is likewise inconvenient because of the need for two shift keys.
>
> Defining these keys in addition to the existing binding for 'undo'
> can't do direct harm.  But it may disappoint the users you're trying
> to help.

The users we’re trying to help are already used to Redo being bound to
Ctrl+Shift+Z (because Redo is the inverse of Undo which is usually on
Ctrl+Z).

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 13 Sep 2020 16:49:05 +0700
> Cc: Ergus <spacibba@aol.com>, Emacs developers <emacs-devel@gnu.org>, rekado@elephly.net, 
> 	Dmitry Gutov <dgutov@yandex.ru>, Gregory Heytings <ghe@sdf.org>, Eli Zaretskii <eliz@gnu.org>, 
> 	Drew Adams <drew.adams@oracle.com>
> 
> The users we’re trying to help are already used to Redo being bound to
> Ctrl+Shift+Z (because Redo is the inverse of Undo which is usually on
> Ctrl+Z).

I'm used to Redo bound to Ctrl-Y.

Re: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 17:30, Eli Zaretskii wrote:
>> The users we’re trying to help are already used to Redo being bound to
>> Ctrl+Shift+Z (because Redo is the inverse of Undo which is usually on
>> Ctrl+Z).
> I'm used to Redo bound to Ctrl-Y.

Do you use it in Emacs as well?

If you have an idea how to accommodate this kind of existing habit here, 
we're all ears, of course. But I think the best one could hope is to 
make it a part of cua-mode.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: rms@gnu.org, spacibba@aol.com, emacs-devel@gnu.org, rekado@elephly.net,
>  ghe@sdf.org, drew.adams@oracle.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 13 Sep 2020 20:36:04 +0300
> 
> On 13.09.2020 17:30, Eli Zaretskii wrote:
> >> The users we’re trying to help are already used to Redo being bound to
> >> Ctrl+Shift+Z (because Redo is the inverse of Undo which is usually on
> >> Ctrl+Z).
> > I'm used to Redo bound to Ctrl-Y.
> 
> Do you use it in Emacs as well?
> 
> If you have an idea how to accommodate this kind of existing habit here, 
> we're all ears, of course.

There are more ears here than just yours.

Re: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 06:57, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> There are two problems with C-?:
> 
> * It requires two shift keys, so it is inconvenient.

Do you mean two modifier keys?

It's just one shift key. C-? is the same as C-S-/, at least in GUI version.

 > (The bindings for undo ensure it can be typed with just one
 > shift key on all usual terminals.)

C-_, one of the two existing bindings for 'undo', has the exact same 
problem. Which, for undo, is more significant, I'd say.

> * It does not exist at all on ttys.  (I don't know whether we can
> change that on Linux consoles.)

I don't know either.

It _is_ a drawback, especially for users who tend to switch between GUI 
and terminal, but I don't have any better suggestions about that. But as 
far as new users are concerned, GUI Emacs is a lot more popular.

> Whether constitutes a problem for the undo-redo feature depends on the
> precise meanings of the two commands.  I don't know those details
> so I can't judge.

I don't think it is. As Juri said, the target audience of this feature 
expects 'undo' to be on Ctrl-Z and 'redo' on Ctrl-Shift-Z (though many 
editors bind it to Ctrl-Y as well).

> M-_ is likewise inconvenient because of the need for two shift keys.

I guess you do mean "two modifier keys". See above.

Re: Changes for emacs 28

[Richard Stallman]

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

  >  > (The bindings for undo ensure it can be typed with just one
  >  > shift key on all usual terminals.)

  > C-_, one of the two existing bindings for 'undo', has the exact same 
  > problem.

Not on a tty.  On a tty you can type Ctrl-minus and you get that
character.

Undo has two 1-key bindings, C-_ for ttys and C-/ for consoles with
the full space of input characters.  Each requires just one shift key
on the consoles it is meant for.




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

Re: Changes for emacs 28

[Dmitry Gutov]

On 14.09.2020 06:51, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    >  > (The bindings for undo ensure it can be typed with just one
>    >  > shift key on all usual terminals.)
> 
>    > C-_, one of the two existing bindings for 'undo', has the exact same
>    > problem.
> 
> Not on a tty.  On a tty you can type Ctrl-minus and you get that
> character.

Interesting. I never would have guessed.

> Undo has two 1-key bindings, C-_ for ttys and C-/ for consoles with
> the full space of input characters.  Each requires just one shift key
> on the consoles it is meant for.

I see. There is certain elegance in that, but I'd say it's not very 
discoverable. Especially when you get C-_ by typing Ctrl-/ in xterm, but 
you need to press Ctrl-- in a tty. And with a yet another behavior in X.

Going back to the proposed bindings for 'redo', a certain popular 
package we have seen mentioned in this discussion uses them (undo-tree). 
So they have been proven in the field, for many years.

Most new users might prefer to see C-z for undo and C-S-z for redo, of 
course, but I don't think we can do anything about that, other than add 
a C-S-z binding to cua-mode.

Re: Changes for emacs 28

[Stefan Monnier]

> Most new users might prefer to see C-z for undo and C-S-z for redo, of
> course, but I don't think we can do anything about that, other than add
> a C-S-z binding to cua-mode.

C-S-z could be added globally by default.  It's currently unbound.


        Stefan

Re: Changes for emacs 28

[Richard Stallman]

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

  > I see. There is certain elegance in that, but I'd say it's not very 
  > discoverable.

It is very prominent in documentation, and C-h w will tell you.

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

Re: Changes for emacs 28

[Dmitry Gutov]

On 15.09.2020 07:43, Richard Stallman wrote:
>    > I see. There is certain elegance in that, but I'd say it's not very
>    > discoverable.
> 
> It is very prominent in documentation, and C-h w will tell you.

It tells me that C-_ is one of the bindings.

It doesn't tell me that C-- will map to C-_.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Undo.html 
mentions, in a footnote, that C-/ is sometimes mapped to C-_. Which is 
true for gnome-terminal, but for ttys on my machine.

There's no mention of C-- being mapped in the manual.

Re: Changes for emacs 28

[Richard Stallman]

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

  > It tells me that C-_ is one of the bindings.

  > It doesn't tell me that C-- will map to C-_.

I am surprised.  I thought this was documented.
So I sent a patch to mention it in the Emacs manual.

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

Re: Changes for emacs 28

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> There are two problems with C-?:
>
> * It requires two shift keys, so it is inconvenient.
> (The bindings for undo ensure it can be typed with just one
> shift key on all usual terminals.)
Doesn't that depend on the keyboard layout?

Some of bindings that you lucky us-layout people use are inconvenient
for oss others. We have to press shift+alt graphic and do some serious
finger gymnastics sometimes to use some Emacs bindings. I think there is
not much to do there, not everybody will be always happy with all
default bindings. We can just re-bind (what I do at least) what we find
awkward.

Could C-- work? Then undo functions will be on C-_ and C--, kind of
similar?

Re: Changes for emacs 28

[Stefan Kangas]

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

> Could C-- work? Then undo functions will be on C-_ and C--, kind of
> similar?

That would be backwards incompatible: C-- runs the command
negative-argument (found in global-map).

Re: Changes for emacs 28

[T.V Raman]

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

Richard Stallman <rms@gnu.org> writes:

For what it's worth, I have C-x u undo-only C-x C-u undo-redo > [[[ 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. ]]]
>
> There are two problems with C-?:
>
> * It requires two shift keys, so it is inconvenient.
> (The bindings for undo ensure it can be typed with just one
> shift key on all usual terminals.)
>
> * It does not exist at all on ttys.  (I don't know whether we can
> change that on Linux consoles.)
>
> Whether constitutes a problem for the undo-redo feature depends on the
> precise meanings of the two commands.  I don't know those details
> so I can't judge.
>
> M-_ is likewise inconvenient because of the need for two shift keys.
>
> Defining these keys in addition to the existing binding for 'undo'
> can't do direct harm.  But it may disappoint the users you're trying
> to help.

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

RE: Changes for emacs 28

[Drew Adams]

> BTW: everybody agrees in set undo-redo to C-? and M-_??

;-)

Do you think everyone agrees on _any_ default key bindings?
___


Such keys should be used/saved for repeatable commands
(hold down the key to repeat command) or for use as
prefix keys.

(FWIW, I use `M-_' for `forward-whitespace'.)

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>  drew.adams@oracle.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 12 Sep 2020 00:00:48 +0300
> 
> > As long as we keep this on the menu and the tool bar, there will be no
> > reason for a "war".
> 
> So there will be contradiction between the menu and the keyboard?

Yes.  We already have quite a few of them, so one or two more cannot
hurt.

> > How can it be confusing that 2 different commands produce different
> > results?  Why isn't it confusing today, when we already have these 2
> > commands?
> 
> The menu item doesn't exactly say which command it is invoking.

It does, if you invoke "C-h k".

If you don't ask Emacs what the menu item invokes, then the text of
the menu item and the help-echo string are the only description you
get, and that is so for all the other menu items.  So there's nothing
new here.

> So I think that statement is missing the point: we should endeavor for 
> predictable and consistent sets of menu items, key bindings, and other 
> features.

I agree, but the criteria for "predictable and consistent" might be
something other than "make the keybindings and menus invoke identical
commands".  Because if that's the criteria, we are already in
violation of them.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 09:12, Eli Zaretskii wrote:
>> Cc: rekado@elephly.net, ghe@sdf.org, emacs-devel@gnu.org,
>>   drew.adams@oracle.com
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 12 Sep 2020 00:00:48 +0300
>>
>>> As long as we keep this on the menu and the tool bar, there will be no
>>> reason for a "war".
>>
>> So there will be contradiction between the menu and the keyboard?
> 
> Yes.  We already have quite a few of them, so one or two more cannot
> hurt.

I'm looking to improve the current state of affairs.

Also: confusion about certain basic operations are likely to hit new 
users harder than confusions about other things.

>>> How can it be confusing that 2 different commands produce different
>>> results?  Why isn't it confusing today, when we already have these 2
>>> commands?
>>
>> The menu item doesn't exactly say which command it is invoking.
> 
> It does, if you invoke "C-h k".

Irrelevant, as long as we're talking about new user experience.

> If you don't ask Emacs what the menu item invokes, then the text of
> the menu item and the help-echo string are the only description you
> get, and that is so for all the other menu items.  So there's nothing
> new here.

Hence we shouldn't create a confusing menu item like this.

>> So I think that statement is missing the point: we should endeavor for
>> predictable and consistent sets of menu items, key bindings, and other
>> features.
> 
> I agree, but the criteria for "predictable and consistent" might be
> something other than "make the keybindings and menus invoke identical
> commands".  Because if that's the criteria, we are already in
> violation of them.

That doesn't mean we're not allowed to improve things in specific cases.

Re: Changes for emacs 28

[Richard Stallman]

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

  > - Add the extra icon in the toolbar.
  > - Change the undo action in menu-bar and tool-bar by undo-only instead.
  > - Bind undo-redo to something in the keyboard.

Which key?  Finding a good key for this is the hardest part of the
idea.  You need to bite the bullet and make specific proposals.

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

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 06:21, Richard Stallman wrote:
>    > - Add the extra icon in the toolbar.
>    > - Change the undo action in menu-bar and tool-bar by undo-only instead.
>    > - Bind undo-redo to something in the keyboard.
> 
> Which key?  Finding a good key for this is the hardest part of the
> idea.  You need to bite the bullet and make specific proposals.

Proposal has already been made: C-? and M-_

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 02:36:45PM +0300, Dmitry Gutov wrote:
>On 12.09.2020 06:21, Richard Stallman wrote:
>>   > - Add the extra icon in the toolbar.
>>   > - Change the undo action in menu-bar and tool-bar by undo-only instead.
>>   > - Bind undo-redo to something in the keyboard.
>>
>>Which key?  Finding a good key for this is the hardest part of the
>>idea.  You need to bite the bullet and make specific proposals.
>
>Proposal has already been made: C-? and M-_

We can't use C-?; it conflicts with some old terminal interfaces we support.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 15:42, Ergus wrote:
> We can't use C-?; it conflicts with some old terminal interfaces we 
> support.

IIUC it simply won't work in those terminals.

But that's what we'll have the other binding for (M-_).

Re: Changes for emacs 28

[Ergus]

On Sat, Sep 12, 2020 at 07:37:21PM +0300, Dmitry Gutov wrote:
>On 12.09.2020 15:42, Ergus wrote:
>>We can't use C-?; it conflicts with some old terminal interfaces we 
>>support.
>
>IIUC it simply won't work in those terminals.
>
>But that's what we'll have the other binding for (M-_).
>
Binding it as "\C-?" actually doesn't work, ?C-? or \^-? either. Only
with kbd I made it work.

So I prefer to ask before breaking anything.

Re: Changes for emacs 28

[Dmitry Gutov]

On 12.09.2020 19:46, Ergus wrote:
> Binding it as "\C-?" actually doesn't work, ?C-? or \^-? either. Only
> with kbd I made it work.

Using kbd is just fine.

(kbd "C-?") evaluates to [67108927], which seems to show right away that 
it's GUI-only and is unlikely to affect anything in terminal.

> So I prefer to ask before breaking anything.

Or you can post a patch and wait for comments.

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 15:04, Eli Zaretskii wrote:
>> Cc: rekado@elephly.net, ghe@sdf.org, spacibba@aol.com, drew.adams@oracle.com,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Fri, 11 Sep 2020 14:09:17 +0300
>>
>> On 11.09.2020 13:41, Eli Zaretskii wrote:
>>> If people prefer that, we could change the binding, I won't object.
>>
>> But then we'll have no binding for `undo-redo`, just a menu item?
>>
>> Or would you be fine with adding a binding for it too?
> 
> Why do we need a binding for it in the default configuration?  Not
> every command available through the menus has a keybinding by default.

Existing user expectations, regarding undo-redo, coming from just about 
any other editor or software with text inputs (such as Firefox).

I'm pretty confident that any user that will use 'redo' from the menu 
will look for the binding for it.

Also: we do make an effort to create key bindings for commands that we 
anticipate will be used often. If the user uses 'redo' at all, they will 
do it frequently.

Additionally, the difference between 'undo' and 'undo-only' is likely to 
be surprising for such users.

Re: Changes for emacs 28

[Richard Stallman]

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

  > > 'undo'.
  > > 
  > > As opposed to 'undo-only'.

  > If people prefer that, we could change the binding, I won't object.

I might object to this.  People should make a concrete proposal,
then we can all think about it.
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 01:10:29PM +0300, Dmitry Gutov wrote:
>On 11.09.2020 09:39, Eli Zaretskii wrote:
>>>Date: Fri, 11 Sep 2020 01:14:20 +0200
>>>From: Ergus<spacibba@aol.com>
>>>Cc: Ricardo Wurmus<rekado@elephly.net>, Gregory Heytings<ghe@sdf.org>,
>>>  emacs-devel@gnu.org
>>>
>>>3) Is it possible/should we: add a redo icon in the toolbar
>>>conditionally when the mode is enabled?
>>>
>>>else
>>>
>>>4) I see a redo added in the menu-bar unconditionally... should we do
>>>the same in the toolbar unconditionally?
>>I indeed think that the Redo icon should be added unconditionally
>>(enabled only when there's something to redo, like the menu item).
>
>Are you not worried about the divergence between the menu items and 
>the toolbar, and the actual available bindings?
>
>And also about the fact the menu item next to 'redo' doesn't call 
>'undo-only'? Which will be contrary to the expectations of users who 
>know the concept of 'redo' from other programs.
>
>I think this created a potential for additional user confusion.
>
Yes these were/are exactly my concerns. 

>A global mode like undo-redo-mode, like suggested by Ergus, would 
>avoid both of these problems. We'd only need to find a key for 
>'undo-redo'.
>
>Perhaps, 'M-_' and 'C-?'? That's what undo-tree uses by default.

I use C-/ for undo so C-? in my keyboard is C-S-/ so it is perfect. But
for people using C-_ (C-S--) maybe M-_ (M-S--) will make more
sense (BTW: in Spanish keyboard it does).

Re: Changes for emacs 28

[Dmitry Gutov]

On 11.09.2020 13:59, Ergus wrote:
>> A global mode like undo-redo-mode, like suggested by Ergus, would 
>> avoid both of these problems. We'd only need to find a key for 
>> 'undo-redo'.
>>
>> Perhaps, 'M-_' and 'C-?'? That's what undo-tree uses by default.
> 
> I use C-/ for undo so C-? in my keyboard is C-S-/ so it is perfect. But
> for people using C-_ (C-S--) maybe M-_ (M-S--) will make more
> sense (BTW: in Spanish keyboard it does).

Right, and I did mean using both key sequences.

Since default Emacs binds 'undo' to both 'C-_' and 'C-/', it would make 
sense to add a corresponding 'redo' binding to each using nearby keys.

Re: Changes for emacs 28

[Juri Linkov]

>>> A global mode like undo-redo-mode, like suggested by Ergus, would avoid
>>> both of these problems. We'd only need to find a key for 'undo-redo'.
>>>
>>> Perhaps, 'M-_' and 'C-?'? That's what undo-tree uses by default.
>> I use C-/ for undo so C-? in my keyboard is C-S-/ so it is perfect. But
>> for people using C-_ (C-S--) maybe M-_ (M-S--) will make more
>> sense (BTW: in Spanish keyboard it does).
>
> Right, and I did mean using both key sequences.
>
> Since default Emacs binds 'undo' to both 'C-_' and 'C-/', it would make
> sense to add a corresponding 'redo' binding to each using nearby keys.

What about adding a transient mode activated by a key sequence.
When the mode is active, it will enable arrow keys to navigate the
undo history in both directions: <left> to undo, and <right> to redo.
This is similar to 'indent-rigidly' bound to 'C-x TAB':

  If called interactively with no prefix argument, activate a
  transient mode in which the indentation can be adjusted interactively
  by typing <left>, <right>, <S-left>, or <S-right>.
  Typing any other key deactivates the transient mode.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 09:39:30AM +0300, Eli Zaretskii wrote:
>> Date: Fri, 11 Sep 2020 01:14:20 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Ricardo Wurmus <rekado@elephly.net>, Gregory Heytings <ghe@sdf.org>,
>>  emacs-devel@gnu.org
>>
>> 3) Is it possible/should we: add a redo icon in the toolbar
>> conditionally when the mode is enabled?
>>
>> else
>>
>> 4) I see a redo added in the menu-bar unconditionally... should we do
>> the same in the toolbar unconditionally?
>
>I indeed think that the Redo icon should be added unconditionally
>(enabled only when there's something to redo, like the menu item).

Then Caio Henrique can add his patch from a previous mail to master.

I tried it but there is a problem enabling disabling the icon. It
doesn't enable automatically when I do an undo until I click with the
mouse somewhere.

Maybe it is a redisplay problem?

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 12:15:09 +0200
> From: Ergus <spacibba@aol.com>
> Cc: caiohcs0@gmail.com, emacs-devel@gnu.org
> 
> I tried it but there is a problem enabling disabling the icon. It
> doesn't enable automatically when I do an undo until I click with the
> mouse somewhere.
> 
> Maybe it is a redisplay problem?

No, because the Cut and Paste button have no such problems.

Re: Changes for emacs 28

[Caio Henrique]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 11 Sep 2020 12:15:09 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: caiohcs0@gmail.com, emacs-devel@gnu.org
>> 
>> I tried it but there is a problem enabling disabling the icon. It
>> doesn't enable automatically when I do an undo until I click with the
>> mouse somewhere.
>> 
>> Maybe it is a redisplay problem?
>
> No, because the Cut and Paste button have no such problems.

I tried that code again and I experienced the same thing as Ergus, but
only in some cases. If I:
1. launch emacs -Q
2. type only the letter "a"
3. click on the "Undo" button on the toolbar

Then the "Redo" button on the toolbar activates and all works well.

But if I try:
1. launch emacs -Q
2. type the letter "a"
3. press RET to insert newline
4. type the letter "b"
5. click on the "Undo" button on the toolbar

In this case the "Redo" toolbar button doesn't activate (but the "Redo"
button on the menu bar works fine). Then if I click with the mouse
anywhere inside the buffer, then the toolbar menu activates.
I don't know what the problem is, any ideas?

> Thanks, but please add a help-echo text for that button.  The menu
> item perhaps could do without it, but not the tool-bar button.

Isn't the help-echo text the one that appears when I place my mouse over
the toolbar button? Isn't this text the same one used for the menu bar
buttons? When I place my mouse over "Redo" on the toolbar, it says "Undo
last undo".

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Caio Henrique <caiohcs0@gmail.com>
> Cc: Ergus <spacibba@aol.com>,  caiohcs0@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 11 Sep 2020 11:02:54 -0300
> 
> >> Maybe it is a redisplay problem?
> >
> > No, because the Cut and Paste button have no such problems.
> 
> I tried that code again and I experienced the same thing as Ergus, but
> only in some cases. If I:
> 1. launch emacs -Q
> 2. type only the letter "a"
> 3. click on the "Undo" button on the toolbar
> 
> Then the "Redo" button on the toolbar activates and all works well.
> 
> But if I try:
> 1. launch emacs -Q
> 2. type the letter "a"
> 3. press RET to insert newline
> 4. type the letter "b"
> 5. click on the "Undo" button on the toolbar
> 
> In this case the "Redo" toolbar button doesn't activate (but the "Redo"
> button on the menu bar works fine). Then if I click with the mouse
> anywhere inside the buffer, then the toolbar menu activates.
> I don't know what the problem is, any ideas?

Did you look at how Cut/Paste solve the same problem?

> > Thanks, but please add a help-echo text for that button.  The menu
> > item perhaps could do without it, but not the tool-bar button.
> 
> Isn't the help-echo text the one that appears when I place my mouse over
> the toolbar button? Isn't this text the same one used for the menu bar
> buttons? When I place my mouse over "Redo" on the toolbar, it says "Undo
> last undo".

Hmm, when I tried that, I didn't see any help-echo for the Redo menu
item.  I do see it now, so I guess I did something wrong when I tried
that back then.  Sorry about that.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 11:02:54AM -0300, Caio Henrique wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Fri, 11 Sep 2020 12:15:09 +0200
>>> From: Ergus <spacibba@aol.com>
>>> Cc: caiohcs0@gmail.com, emacs-devel@gnu.org
>>>
>>> I tried it but there is a problem enabling disabling the icon. It
>>> doesn't enable automatically when I do an undo until I click with the
>>> mouse somewhere.
>>>
>>> Maybe it is a redisplay problem?
>>
>> No, because the Cut and Paste button have no such problems.
>
>I tried that code again and I experienced the same thing as Ergus, but
>only in some cases. If I:
>1. launch emacs -Q
>2. type only the letter "a"
>3. click on the "Undo" button on the toolbar
>
>Then the "Redo" button on the toolbar activates and all works well.
>
>But if I try:
>1. launch emacs -Q
>2. type the letter "a"
>3. press RET to insert newline
>4. type the letter "b"
>5. click on the "Undo" button on the toolbar
>
>In this case the "Redo" toolbar button doesn't activate (but the "Redo"
>button on the menu bar works fine). Then if I click with the mouse
>anywhere inside the buffer, then the toolbar menu activates.
>I don't know what the problem is, any ideas?
>
>> Thanks, but please add a help-echo text for that button.  The menu
>> item perhaps could do without it, but not the tool-bar button.
>
>Isn't the help-echo text the one that appears when I place my mouse over
>the toolbar button? Isn't this text the same one used for the menu bar
>buttons? When I place my mouse over "Redo" on the toolbar, it says "Undo
>last undo".
For me it happens always if I do:

emacs -Q
Do anything
C-/  (for undo)

Independently of how many times I do "undo" with C-/ it never gets
activated. If I click anywhere then it does.

Re: Changes for emacs 28

[Caio Henrique]

Ergus <spacibba@aol.com> writes:

> For me it happens always if I do:
>
> emacs -Q
> Do anything
> C-/  (for undo)
>
> Independently of how many times I do "undo" with C-/ it never gets
> activated. If I click anywhere then it does.

Sorry, I still don't know what is wrong. Looking the code of other
buttons like copy and paste, I don't know what I'm missing.

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 06:29:02PM -0300, Caio Henrique wrote:
>Ergus <spacibba@aol.com> writes:
>
>> For me it happens always if I do:
>>
>> emacs -Q
>> Do anything
>> C-/  (for undo)
>>
>> Independently of how many times I do "undo" with C-/ it never gets
>> activated. If I click anywhere then it does.
>
>Sorry, I still don't know what is wrong. Looking the code of other
>buttons like copy and paste, I don't know what I'm missing.
>

Actually this seems to be a bug somewhere updating the {tool,menu}-bars.

Try this:

1) emacs -Q
2) Insert this in scratch:
(global-set-key [menu-bar edit] 'undefined)

3) And at the end of the line do:
C-x C-e

The menu-bar won't hide Edit menu until you click it and for me it
blocks emacs after that when I try to reinsert text.

The backtrace shows this:

(gdb) bt
#0  0x00007fa6ed75cc96 in pselect () at /usr/lib/libc.so.6
#1  0x000055def30f481c in really_call_select (arg=0x7ffde562dc70) at ../../src/thread.c:592
#2  0x000055def30f55ff in flush_stack_call_func (arg=0x7ffde562dc70, func=0x55def30f47b0 <really_call_select>) at ../../src/lisp.h:3791
#3  thread_select (func=<optimized out>, max_fds=max_fds@entry=9, rfds=rfds@entry=0x7ffde562dd70, wfds=wfds@entry=0x7ffde562ddf0, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffde562e3a0, sigmask=0x0)
     at ../../src/thread.c:624
#4  0x000055def310faeb in xg_select (fds_lim=9, rfds=rfds@entry=0x7ffde562e4b0, wfds=wfds@entry=0x7ffde562e530, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffde562e3a0, sigmask=sigmask@entry=0x0)
     at ../../src/xgselect.c:131
#5  0x000055def30d2d85 in wait_reading_process_output
     (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0)
     at ../../src/process.c:5601
#6  0x000055def301aa5d in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=0x7ffde562ed1b, kbp=<synthetic pointer>) at ../../src/lisp.h:1007
#7  read_event_from_main_queue (used_mouse_menu=0x7ffde562ed1b, local_getcjmp=0x7ffde562e940, end_time=0x0) at ../../src/keyboard.c:2156
#8  read_decoded_event_from_main_queue (used_mouse_menu=<optimized out>, prev_event=<optimized out>, local_getcjmp=<optimized out>, end_time=<optimized out>) at ../../src/keyboard.c:2220
#9  read_char (commandflag=1, map=0x55def4e4b563, prev_event=0x0, used_mouse_menu=0x7ffde562ed1b, end_time=0x0) at ../../src/keyboard.c:2830
#10 0x000055def301d1d4 in read_key_sequence (keybuf=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>)
     at ../../src/keyboard.c:9547
#11 0x000055def301eb5c in command_loop_1 () at ../../src/lisp.h:1007
#12 0x000055def308c647 in internal_condition_case (bfun=bfun@entry=0x55def301e970 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55def3015080 <cmd_error>) at ../../src/eval.c:1356
#13 0x000055def300f7b4 in command_loop_2 (ignore=ignore@entry=0x0) at ../../src/lisp.h:1007
#14 0x000055def308c5a1 in internal_catch (tag=tag@entry=0xd5f0, func=func@entry=0x55def300f790 <command_loop_2>, arg=arg@entry=0x0) at ../../src/eval.c:1117
#15 0x000055def300f75b in command_loop () at ../../src/lisp.h:1007
#16 0x000055def3014c96 in recursive_edit_1 () at ../../src/keyboard.c:714
#17 0x000055def3014fc2 in Frecursive_edit () at ../../src/keyboard.c:786
#18 0x000055def2f29dac in main (argc=2, argv=<optimized out>) at
../../src/emacs.c:2047

But it is totally frozen.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 05:22:32 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> 1) emacs -Q
> 2) Insert this in scratch:
> (global-set-key [menu-bar edit] 'undefined)
> 
> 3) And at the end of the line do:
> C-x C-e
> 
> The menu-bar won't hide Edit menu until you click it and for me it
> blocks emacs after that when I try to reinsert text.

Then don't do that, okay?

Re: Changes for emacs 28

[Ergus]

On September 12, 2020 8:30:48 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 12 Sep 2020 05:22:32 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> 
>> 1) emacs -Q
>> 2) Insert this in scratch:
>> (global-set-key [menu-bar edit] 'undefined)
>> 
>> 3) And at the end of the line do:
>> C-x C-e
>> 
>> The menu-bar won't hide Edit menu until you click it and for me it
>> blocks emacs after that when I try to reinsert text.
>
>Then don't do that, okay?

Ok. But this is a modified version of the example code in the elisp manual for removing elements from the menu. Is the manual outdated?

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

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 10:27:58 +0200
> CC: caiohcs0@gmail.com
> From: Ergus <spacibba@aol.com>
> 
> >> The menu-bar won't hide Edit menu until you click it and for me it
> >> blocks emacs after that when I try to reinsert text.
> >
> >Then don't do that, okay?
> 
> Ok. But this is a modified version of the example code in the elisp manual for removing elements from the menu. Is the manual outdated?

Does the unmodified version of the code in the manual cause the same
problem?  If so, we'd need to revise it.

Re: Changes for emacs 28

[Ergus]

On September 12, 2020 10:38:26 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 12 Sep 2020 10:27:58 +0200
>> CC: caiohcs0@gmail.com
>> From: Ergus <spacibba@aol.com>
>> 
>> >> The menu-bar won't hide Edit menu until you click it and for me it
>> >> blocks emacs after that when I try to reinsert text.
>> >
>> >Then don't do that, okay?
>> 
>> Ok. But this is a modified version of the example code in the elisp
>manual for removing elements from the menu. Is the manual outdated?
>
>Does the unmodified version of the code in the manual cause the same
>problem?  If so, we'd need to revise it.

In the manual says that the code is used by dired to disable the edit menu. But dired doesn't disable it. I tried the original example and yes, I have the same 2 problems: needs a click and clocks emacs.

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

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Sat, 12 Sep 2020 11:38:40 +0200
> CC: emacs-devel@gnu.org,caiohcs0@gmail.com
> From: Ergus <spacibba@aol.com>
> 
> >Does the unmodified version of the code in the manual cause the same
> >problem?  If so, we'd need to revise it.
> 
> In the manual says that the code is used by dired to disable the edit menu. But dired doesn't disable it.

The code is commented out in dired.el.

> I tried the original example and yes, I have the same 2 problems: needs a click and clocks emacs.

It doesn't do that here, FWIW.

Please submit a full bug report with the recipe to reproduce.

Re: Changes for emacs 28

[Richard Stallman]

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

  > 1) Could we add an option to enable choosing between the traditional
  > undo or undo-only + undo-redo? something like undo-redo-mode?

That is not concrete.  What exactly is the change in key bindings
you propose?

(Choosing key bindings is the hard part.)


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

Re: Changes for emacs 28

[Ergus]

On Fri, Sep 11, 2020 at 11:20:04PM -0400, Richard Stallman wrote:
>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>[[[ whether defending the US Constitution against all enemies,     ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>  > 1) Could we add an option to enable choosing between the traditional
>  > undo or undo-only + undo-redo? something like undo-redo-mode?
>
>That is not concrete.  What exactly is the change in key bindings
>you propose?
>
>(Choosing key bindings is the hard part.)
>
>
I already commented and added some code; but maybe the changes does not
worth creating a mode because undo-redo will be enabled bu default in
the menu-bar.

But the idea was to do:

[remap undo] -> undo-only

+

C-? and M-_ -> undo-redo

But binding C-? could be problematic in some terminals so probably is
better to avoid it.

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

Re: Changes for emacs 28

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

  > But the idea was to do:

  > [remap undo] -> undo-only

  > +

  > C-? and M-_ -> undo-redo

I wonder if it is possible to modify undo-redo
to work in a meaningful way with the ordinary undo command.
More precisely, if you invoke 'undo-redo' that would cause
'undo' to start acting like 'undo-only' for the time being.

'undo' would go back to normal undo the next time you start a new
chain of undos.

In effect, this way we would have both kinds of undo _behavior_
with just one undo _command_.  That might eliminate the confusion.

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

Re: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 07:07, Richard Stallman wrote:

> I wonder if it is possible to modify undo-redo
> to work in a meaningful way with the ordinary undo command.
> More precisely, if you invoke 'undo-redo' that would cause
> 'undo' to start acting like 'undo-only' for the time being.
> 
> 'undo' would go back to normal undo the next time you start a new
> chain of undos.
> 
> In effect, this way we would have both kinds of undo _behavior_
> with just one undo _command_.  That might eliminate the confusion.

I am wary of this kind of hidden state, which makes a command behave in 
two distinctly different ways. It is likely to increase confusion, 
rather than eliminate it.

It maybe could have worked if people called 'redo' before 'undo', thus 
creating a consistent indication of intent.

But the order is exactly the opposite, of course.

Re: Changes for emacs 28

[Richard Stallman]

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

  > I am wary of this kind of hidden state, which makes a command behave in 
  > two distinctly different ways. It is likely to increase confusion, 
  > rather than eliminate it.

I am not convinced.  I urge someone to try implementing my suggestion
so people can see whether they like it.  That will be more useful than
speculating whether people will like it.

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

Re: Changes for emacs 28

[Achilles Yuce]

Hey,


I was reading this thread and lost in the variety of choices, wondering:

How about something superior to anything and sophisticated for every
taste, shipping a learning algorithm inside/with Emacs?


Best regards,

          Achilles

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Achilles Yuce <ayuce@posteo.mx>
> Date: Sat, 12 Sep 2020 17:28:17 +0300
> 
> How about something superior to anything and sophisticated for every
> taste, shipping a learning algorithm inside/with Emacs?

I think we will gratefully accept patches for that, thank you.

RE: Changes for emacs 28

[Drew Adams]

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

+1.  I'm seeing this more lately in the mailing
lists, for some reason.  But I guess only from
specific users.

Re: Changes for emacs 28

[Boruch Baum]

On Tue, 08 Sep 2020 13:50:37 +0100, João Távora wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > On Tue, 08 Sep 2020 12:13:04 +0100, João Távora wrote:
> >> It must be a command-line option because when reproducing and fixing
> >> bugs on Emacs, you very frequently have the need to run "a bare Emacs
> >> -Q" frequently from a shell, devoid of any third-party packages that may
> >> be interfering.
> >
> > That's only ever is true when reporting a bug to the emacs project
> > itself.
>
> No, no and no. When answering bug reports for a package that is _not_
> in Emacs it's imperative that the reporter uses Emacs -Q + <package
> setup when explaining the problem.

You're right. I'm surprised I wrote that part.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[Boruch Baum]

On Tue, 08 Sep 2020 12:13:04 +0100, João Távora wrote:

> Richard Stallman <rms@gnu.org> writes:
> > I like the idea, but this should be something to set in .emacs,
> > not a command-line option.
>
> It must be a command-line option because when reproducing and fixing
> bugs on Emacs, you very frequently have the need to run "a bare Emacs
> -Q" frequently from a shell, devoid of any third-party packages that may
> be interfering.

That's only ever is true when reporting a bug to the emacs project
itself. Should your proposal be adopted as an add-on loaded via .emacs
as Richard Stallman suggests, it can be treated like any of the other
zillion emacs third-party packages that are competently and
professionally debugged by their own authors and maintainers, without
imposing extra burdens on the maintainers of the core emacs project.

I do think it would be great for emacs to include a curated collection
of sample init files descriptively labeled for use-case. I would go
further and suggest that the technique of using an org-mode file with
embedded code blocks as one's emacs init file be adopted as standard,
and be used for those collection of init files. That way each code block
can be explained and annotated to 'new' users.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[João Távora]

Boruch Baum <boruch_baum@gmx.com> writes:

> On Tue, 08 Sep 2020 12:13:04 +0100, João Távora wrote:
>> Richard Stallman <rms@gnu.org> writes:
>> > I like the idea, but this should be something to set in .emacs,
>> > not a command-line option.
>>
>> It must be a command-line option because when reproducing and fixing
>> bugs on Emacs, you very frequently have the need to run "a bare Emacs
>> -Q" frequently from a shell, devoid of any third-party packages that may
>> be interfering.
>
> That's only ever is true when reporting a bug to the emacs project
> itself.

No, no and no.  When answering bug reports for a package that is _not_
in Emacs it's imperative that the reporter uses Emacs -Q + <package
setup> when explaining the problem.

I really feel I must stress this, since I've come across so many bad
frustrating and time-consuming bug reports in this aspect in last 15
years (Yasnippet, SLY, Eglot, many others).  The frustration is not only
mine, it's also the reporter's, who frequently isn't even aware of the
underlying Emacs they they are using inside Doom, or even that there is
variation of it that is not souped up with a million packages.

Unless explicited otherwise, authors develop packages to work with
Emacs, not with other packages they are not aware of.  Personally, I
will go to some effort (but not an infinite amount) to help the user
track down the problem even in tandem with other packages not in Emacs.
But the initial report really must contain the perfectly reproducible
starting conditions.  Emacs -Q is an invaluable tool for that.  Every
user must never be made to forget it, no matter what Doom, Space, or
Cauliflower distribution they use.

João

RE: Changes for emacs 28

[Drew Adams]

> When answering bug reports for a package that is _not_
> in Emacs it's imperative that the reporter uses Emacs -Q + <package
> setup> when explaining the problem.

+1

(Helps, anyway.)

Re: Changes for emacs 28

[Robert Pluim]

>>>>> On Tue, 8 Sep 2020 07:52:02 -0400, Boruch Baum <boruch_baum@gmx.com> said:

    Boruch> I do think it would be great for emacs to include a curated collection
    Boruch> of sample init files descriptively labeled for use-case. I would go
    Boruch> further and suggest that the technique of using an org-mode file with
    Boruch> embedded code blocks as one's emacs init file be adopted as standard,
    Boruch> and be used for those collection of init files. That way each code block
    Boruch> can be explained and annotated to 'new' users.

Now youʼre just trying to get me to start rummaging through the garage
for a pitchfork and some torches. There are experienced emacs users
who manage to shoot themselves in the foot with such a setup, any
sample init files should just be emacs lisp forms, with
comments. Thatʼs the only setup thatʼs almost guaranteed to work out
of the box.

Robert

Re: Changes for emacs 28

[Boruch Baum]

My suggestion does skew to 'people willing to make the extra effort to
perform internet searches or downloads', so it will miss populations
such as 'people who download emacs, try it for a minutes, and reject it
on that basis'.

OTOH emacs has had sufficient time to establish a reputation for itself,
so anyone taking the first step to download vanilla emacs can be
expected to already have an expectation of a 'learning curve' ahead and
a future of constant tinkering.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[Boruch Baum]

On  Mon, 07 Sep 2020 22:57:34 -0400, Richard Stallman wrote:

> > If you don't want these features yourself and nobody else in the project
> > wants them either, the only way I can think of making a compelling
> > argument for people to develop those feature is to ask real people and
> > get real responses. I am fairly confident that if you had a testimony or
> > user-test from actual people stating that a feature is missing, then
> > people here would help develop that feature.
>
> I agree.  Before we put time into developing a feature, we should verify
> that many people would like it.
>
> Speaking of which, it would be useful to sit down with a new user just
> trying Emacs and see what perse actually complains about or requests.
> If several people do this, it could give us useful ideas of what changes
> would actually make Emacs more appealing to new users.

How about using existing download statistics from some source like
MELPA? That would be more empirical / less anecdotal, and would cast a
wider net. Other data sources might be link-click-quantity from github
or google analytics or stackexchange.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[Boruch Baum]

 On Mon, 7 Sep 2020 00:20:08 +0200, Ergus wrote:

> There will be never an agreement about changing defaults with long
> ...
> So what if:
> ...
> Does this makes sense?

Debian (and possibly other downstream projects) liberally change
defaults and add packages to their default version of emacs, so your
idea might meet a more enthusiastic reception somewhere in some
downstream project that caters more specifically to the user-base to
which your proposal is aimed.

In the case of Debian, that project may have already started moving in
the *opposite* direction; they culled many small debian-specific tweaks,
and removed packages from their 'vanilla' default version of emacs. On
the other hand, they've increased and somewhat standardized native
package-manager support for many third-party packages that most users
get MELPA or other third-parties.

Communicating with people at the following links might help advance your
proposal:

  https://github.com/bbatsov/prelude

  http://wikemacs.org/wiki/Starter_Kits


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: Changes for emacs 28

[Ergus]

Hi:

My point actually goes in the opposite direction. I don't want to add an
extra layer of abstraction, a fork, a new distribution (starter kit),
external dependencies to do things that vanilla emacs is totally capable
to do with probably less than 100 lines of configuration... but hidden
in our old syntax/names/bindings, unfamiliar lisp, and long and
sometimes too technical documentation.

The idea is to bring what we already have in vanilla but disabled, no
long starting times, extra hacks/functions or complex things to attract
new users coming from VSCode, Sublime or Atom.  



On Mon, Sep 07, 2020 at 05:31:48AM -0400, Boruch Baum wrote:
> On Mon, 7 Sep 2020 00:20:08 +0200, Ergus wrote:
>
>> There will be never an agreement about changing defaults with long
>> ...
>> So what if:
>> ...
>> Does this makes sense?
>
>Debian (and possibly other downstream projects) liberally change
>defaults and add packages to their default version of emacs, so your
>idea might meet a more enthusiastic reception somewhere in some
>downstream project that caters more specifically to the user-base to
>which your proposal is aimed.
>
I thing that we should a attract a little bit of everything; not only
lisp hacker. In my personal experience the Starter_Kits do too much and
increases the configuration complexity much more than the benefit they
bring. Specially because of the external dependencies and trick to group
them while supporting different emacs versions.

>In the case of Debian, that project may have already started moving in
>the *opposite* direction; they culled many small debian-specific tweaks,
>and removed packages from their 'vanilla' default version of emacs. On
>the other hand, they've increased and somewhat standardized native
>package-manager support for many third-party packages that most users
>get MELPA or other third-parties.
>
I actually never understood why Debian adds melpa-elpa packages to their
repos as their update sycle is veeeery slow... but this is another
discussion.

>Communicating with people at the following links might help advance your
>proposal:
>
>  https://github.com/bbatsov/prelude
>
>  http://wikemacs.org/wiki/Starter_Kits
>
Actually no, because they support (as I said) add too many complexities
layers, external dependencies and custom configuration sets with
personalized packages (like spacemacs layers) while modifying completely
the emacs bindings and sometimes breaking the integration with internal
emacs features like package-list. I want to bring the best we can with
what we have but with the simplest possible configuration and only with
internal features.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.


>
>--
>hkp://keys.gnupg.net
>CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
>

Changes for emacs 28

[Ergus]

Hi Emacs:

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

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

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

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

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

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

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

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

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

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

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

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

WDYT??

Re: Changes for emacs 28

[Alfred M. Szmidt]

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

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

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

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

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

What is winmove?  

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

They are absolutley not conservative changes. 

Re: Changes for emacs 28

[Elias Mårtenson]

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

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

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

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

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

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

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

Regards,
Elias

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

Re: Changes for emacs 28

[Óscar Fuentes]

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

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

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

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

Re: Changes for emacs 28

[Ergus]

Hi Elias:

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

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

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

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

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

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

Re: Changes for emacs 28

[Alfred M. Szmidt]

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

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

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

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

Re: Changes for emacs 28

[Dmitry Gutov]

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

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

Spoiler alert: light mode wins.

Re: Changes for emacs 28

[chad]

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

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

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


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

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


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

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

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

Hope that helps,
~Chad

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

Re: Changes for emacs 28

[Dmitry Gutov]

On 07.09.2020 05:17, chad wrote:

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

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

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

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

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

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

Sure. I'm all for that.

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

Re: Changes for emacs 28

[Tim Van den Langenbergh]

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

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

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


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

Re: Changes for emacs 28

[Ergus]

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

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

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

Re: Changes for emacs 28

[Andrea Corallo via Emacs development discussions.]

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

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

Thanks Ergus, FWIW I support your points.

  Andrea

Re: Changes for emacs 28

[Ergus]

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

So what if:

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

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

Is this also too crazy?

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

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

Does this makes sense?

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

Re: Changes for emacs 28

[Eli Zaretskii]

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

Yes.

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

Re: Changes for emacs 28

[Alfred M. Szmidt]

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

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

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

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

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

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

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

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

Re: Changes for emacs 28

[Andrea Corallo via Emacs development discussions.]

Ergus <spacibba@aol.com> writes:

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

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

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

  Andrea

Re: Changes for emacs 28

[tomas]

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

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

So we use your preferences?

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

And yours are better than other's ;-P

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

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

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

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

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

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

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

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

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

Cheers
-- t

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

Re: Changes for emacs 28

[Elias Mårtenson]

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

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

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

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

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

Regards,
Elias

>

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

Re: Changes for emacs 28

[tomas]

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

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

Yes. Thanks for that :-)

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

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

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

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

Cheers
 - t

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

Re: Changes for emacs 28

[Bastien]

Hi Andrea,

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

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

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

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

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

2 cents,

-- 
 Bastien

Re: Changes for emacs 28

[Eli Zaretskii]

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

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

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

Thanks.

Re: Changes for emacs 28

[Ergus]

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

Hi Eli:

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

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

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

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

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

Best,
Ergus.

Re: Changes for emacs 28

[Yuan Fu]

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

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

Yuan

Re: Changes for emacs 28

[Alfred M. Szmidt]

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

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

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

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

Re: Changes for emacs 28

[Ergus]

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

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

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

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

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

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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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

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

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

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

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

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

Re: Changes for emacs 28

[Ricardo Wurmus]

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

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

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

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

-- 
Ricardo

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


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

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

Re: Changes for emacs 28

[Ricardo Wurmus]

Gregory Heytings <ghe@sdf.org> writes:

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

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

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

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

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

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

-- 
Ricardo

Re: Changes for emacs 28

[Joost Kremers]

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

Yes, but...

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

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

-- 
Joost Kremers
Life has its moments

Re: Changes for emacs 28

[Dmitry Gutov]

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

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

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

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

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

Re: Changes for emacs 28

[Juri Linkov]

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

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

Re: Changes for emacs 28

[Alfred M. Szmidt]

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

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

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

Re: Changes for emacs 28

[Lars Ingebrigtsen]

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

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

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

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

Re: Changes for emacs 28

[Caio Henrique]

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

Cordially,
Caio Henrique

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Sun, Sep 06 2020, Caio Henrique wrote:

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

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

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

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

Re: Changes for emacs 28

[Lars Ingebrigtsen]

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

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

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

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

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Mon, Sep 07 2020, Lars Ingebrigtsen wrote:

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

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

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

Re: Changes for emacs 28

[Eric S Fraga]

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

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

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

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

Re: Changes for emacs 28

[Daniel Martín]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

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

--
Daniel Martín

Re: Changes for emacs 28

[Eduardo Ochs]

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

  1) it will be the new default, or

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

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

  4) it can be toggled via Customize,

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

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

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

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

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

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

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

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

Re: Changes for emacs 28

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

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

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

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

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

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

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

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

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

Re: Changes for emacs 28

[Eli Zaretskii]

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

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

Re: Changes for emacs 28

[Lars Ingebrigtsen]

This just showed up in my feed:

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

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

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

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

Re: Changes for emacs 28

[tomas]

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

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

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

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

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

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

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

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

Cheers
 - t

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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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

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

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

~/.emacs.d/bin/doom install

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

Re: Changes for emacs 28

[Ergus]

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

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

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

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

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

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

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

My last 2 cents on this.

Re: Changes for emacs 28

[Eli Zaretskii]

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

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

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

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

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

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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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

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

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

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

Re: Changes for emacs 28

[Ergus]

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

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

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

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

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

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

Re: Changes for emacs 28

[Alfred M. Szmidt]

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

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

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

Re: Changes for emacs 28

[Eduardo Ochs]

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

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

  Cheers & thanks in advance,
    Eduardo Ochs

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

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

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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


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

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

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

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

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

Re: Changes for emacs 28

[Robert Pluim]

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

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

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

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

Robert

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

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

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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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

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

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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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

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

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

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

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

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

Re: Changes for emacs 28

[Göktuğ Kayaalp]

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

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

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

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


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

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


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

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

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

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

A rough draft:

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

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

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

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

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

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

Re: Changes for emacs 28

[Stefan Monnier]

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

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


        Stefan

Re: Changes for emacs 28

[Ergus]

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

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

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

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

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

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

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

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

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

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

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

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

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

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

Re: Changes for emacs 28

[Dmitry Gutov]

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

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

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

Re: Changes for emacs 28

[Pankaj Jangid]

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

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

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

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

Re: Changes for emacs 28

[Ergus]

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

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

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


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

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

Re: Changes for emacs 28

[Ihor Radchenko]

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

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

Best,
Ihor

Ergus <spacibba@aol.com> writes:

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

Re: Changes for emacs 28

[Philip K.]

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

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

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

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

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

-- 
	Philip K.

Re: Changes for emacs 28

[Richard Stallman]

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

Does anyone want to _make_ videos for Emacs?

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

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

Re: Changes for emacs 28

[Ihor Radchenko]

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

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

Best,
Ihor

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

Richard Stallman <rms@gnu.org> writes:

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

Re: Changes for emacs 28

[Ergus]

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

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

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

Re: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

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

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

-- 
	Philip K.

Re: Changes for emacs 28

[Ergus]

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

Good: I didn't know about it.

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

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

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

Re: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

> Good: I didn't know about it.

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

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

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

and playlists can be created too:

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

-- 
	Philip K.

Re: Changes for emacs 28

[Ergus]

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

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

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

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

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

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

Re: Changes for emacs 28

[Jose A. Ortega Ruiz]

On Fri, Sep 11 2020, Ergus wrote:

[...]

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

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

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

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

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


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

Re: Changes for emacs 28

[Göktuğ Kayaalp]

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

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

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

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

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

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

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

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

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

Re: Changes for emacs 28

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

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

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

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

Re: Changes for emacs 28

[Ricardo Wurmus]

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

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

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

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

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

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

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

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

-- 
Ricardo

Re: Changes for emacs 28

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

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

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

Re: Changes for emacs 28

[Ricardo Wurmus]

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

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

I linked to them above:

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

All of these videos were made with this pipeline.

-- 
Ricardo

Re: Changes for emacs 28

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

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

RE: Changes for emacs 28

[Drew Adams]

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

Just a nit about this part.

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

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

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

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


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

Re: Changes for emacs 28

[Robert Pluim]

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

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

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

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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

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

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

Re: Changes for emacs 28

[Robert Pluim]

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

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

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

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

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

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

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


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

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

Re: Changes for emacs 28

[Robert Pluim]

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

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

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

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

DMARC/DKIM/SPF, what hath ye wrought?

Robert

Re: Changes for emacs 28

[Gregory Heytings via Emacs development discussions.]

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


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

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

Re: Changes for emacs 28

[Robert Pluim]

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

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

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

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

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

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

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

Re: Changes for emacs 28

[Robert Pluim]

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

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

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

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

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

Maybe Drew needs a different MUA? :-)

Robert

Re: Changes for emacs 28

[Eli Zaretskii]

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

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

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

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

Rmail does the same, in general.

> Maybe Drew needs a different MUA? :-)

Definitely, but that's out of our control.

Re: Changes for emacs 28

[Robert Pluim]

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

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

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

Itʼs not (directly) under their control.

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

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

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

Robert

RE: Changes for emacs 28

[Drew Adams]

> Maybe Drew needs a different MUA? :-)

Maybe that ain't gonna happen. ;-)

RE: Changes for emacs 28

[Drew Adams]

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

Thanks for the reply.

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

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

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

Re: Changes for emacs 28

[Lars Ingebrigtsen]

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

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

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

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

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

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

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

RE: Changes for emacs 28

[Drew Adams]

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

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

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

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

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

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

Re: Changes for emacs 28

[Juri Linkov]

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

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

Re: Changes for emacs 28

[Juri Linkov]

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

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

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

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

Re: Changes for emacs 28

[Yoni Rabkin]

Ergus <spacibba@aol.com> writes:

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

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

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

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

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

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

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

Re: Changes for emacs 28

[Ergus]

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

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

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

https://github.com/Ergus/mini_dotemacs

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

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

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

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

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

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

Re: Changes for emacs 28

[Yoni Rabkin]

Ergus <spacibba@aol.com> writes:

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

Re: Changes for emacs 28

[Ergus]

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

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

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

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

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

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

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

Re: Changes for emacs 28

[Mario Lang]

Ergus <spacibba@aol.com> writes:

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

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

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

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

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

Re: Changes for emacs 28

[Ihor Radchenko]

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

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

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

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

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

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

I will also attach the message texts below for convenience:

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

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

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

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

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

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

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

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

Best,
Ihor


Richard Stallman <rms@gnu.org> writes:

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

RE: Changes for emacs 28

[Drew Adams]

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

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

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

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

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

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

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

RE: Changes for emacs 28

[Ihor Radchenko]

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

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

Best,
Ihor


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

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

Re: Changes for emacs 28

[tomas]

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

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

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

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

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

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

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

Sorry for being so fuzzy.

Cheers
 - t

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

RE: Changes for emacs 28

[Drew Adams]

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

Thanks for confirming.

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

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

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

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

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

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

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

RE: Changes for emacs 28

[Ihor Radchenko]

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

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

Best,
Ihor

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

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

RE: Changes for emacs 28

[Stefan Kangas]

Ihor Radchenko <yantar92@gmail.com> writes:

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

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

Re: Changes for emacs 28

[Eli Zaretskii]

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

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

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

> Could you submit that as a new bug report?

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

Re: Changes for emacs 28

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

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

Indeed, thanks for pointing that out!

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

Thanks for explaining the background.

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

Re: Changes for emacs 28

[Ihor Radchenko]

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

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

Best,
Ihor




Stefan Kangas <stefankangas@gmail.com> writes:

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

Re: Changes for emacs 28

[Eric S Fraga]

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

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

Re: Changes for emacs 28

[Ihor Radchenko]

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

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

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

Best,
Ihor

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

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

Re: Changes for emacs 28

[Richard Stallman]

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

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

What Emacs version were you using?

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

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

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

Re: Changes for emacs 28

[Ihor Radchenko]

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

I am on master.

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

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

Probably something like the following:

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

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

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

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

Best,
Ihor

Richard Stallman <rms@gnu.org> writes:

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

Re: Changes for emacs 28

[Richard Stallman]

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

  > Probably something like the following:

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

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

That is a concrete suggestion.

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


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

Thanks for that help.

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

Re: Changes for emacs 28

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

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

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

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

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

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

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

Re: Changes for emacs 28

[Richard Stallman]

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

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

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

I learned useful things from it in the past.

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

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

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

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

Re: Changes for emacs 28

[João Távora]

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

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

> Sorry but I can't understand why "old" users, that can write lisp lines
> easily to their configs, can't understand that for new users (and
> younger ones) those lines sometimes takes hours or days (mainly because
> they don't know what/where/how to look for, and lisp is not so
> popular or familiar these days). And that the first impression when they
> open emacs is like going back to 1998.

I think this is a very compelling argument.

I have to say that even as a "old" (oldish) user who has learned
to cherish the medieval Emacs defaults and would be slightly
annoyed at seeing some new defaults that I would have to configure
away.  But precisely like Ergus argues, that's kind of easy for me,
and not for newcomers.

This point comes up here so often that probably someone has
already suggested this silly idea:  Why not have a -1998
(or -1334 (; ) startup switch for the old timers?

João Távora

[-- Attachment #2: Type: text/html, Size: 1310 bytes --]

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This point comes up here so often that probably someone has
  > already suggested this silly idea:  Why not have a -1998
  > (or -1334 (; ) startup switch for the old timers?

I like the idea, but this should be something to set in .emacs,
not a command-line option.

Does the minus sign stand for BC?  I don't think Emacs existed in the
time of the Third Dynasty of Ur.  I developed the first Emacs
in Babylon in -1765.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Stefan Monnier]

> I developed the first Emacs in Babylon in -1765.

And according to Moore's law, the typical density of chips back then was
a teeny tiny fraction of transistor.


        Stefan

Re: Changes for emacs 28

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > This point comes up here so often that probably someone has
>   > already suggested this silly idea:  Why not have a -1998
>   > (or -1334 (; ) startup switch for the old timers?
>
> I like the idea, but this should be something to set in .emacs,
> not a command-line option.

It must be a command-line option because when reproducing and fixing
bugs on Emacs, you very frequently have the need to run "a bare Emacs
-Q" frequently from a shell, devoid of any third-party packages that may
be interfering.  Maintainers would have to additionally specify the
--medieval switch to feel minimally confortable in that setting. It's
not possible to do this in the .emacs because Emacs -Q jumps that, by
definition.

Come to think of it, this is a bit of a counter argument against my
proposal: if we accept new defaults we must be ready to run Emacs -Q's
that have them.  If the new defaults are to include, say, vim-like
keybindings (ugh!), then maintainers are going to have lots of pain.  

This was a bit of an extreme example, but I guess what I'm saying is
that we should still criteriously choose new defaults.

> Does the minus sign stand for BC?  I don't think Emacs existed in the
> time of the Third Dynasty of Ur.  I developed the first Emacs
> in Babylon in -1765.

1334 was my lame attempt of spelling "leet" in "leetspeak", but I put a
4 instead of 7, i.e. I meant 1337.  Guess I'm not so leet after
all. Both sound suitably medieval, tho.

João

Re: Changes for emacs 28

[Alfred M. Szmidt]

This just reminds me of the -u USER option in Emacs.  It is n some
sense quite similar to the idea of "profiles".

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Come to think of it, this is a bit of a counter argument against my
  > proposal: if we accept new defaults we must be ready to run Emacs -Q's
  > that have them.  If the new defaults are to include, say, vim-like
  > keybindings (ugh!), then maintainers are going to have lots of pain.  

  > This was a bit of an extreme example, but I guess what I'm saying is
  > that we should still criteriously choose new defaults.

I agree, the changes in defaults must not be drastic.
But we might still find it useful to be able to specify
the defaults from version N if we don't like the subsequent changes.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> 5) Enable winmove and mouse-wheel-mode by default.

mouse-wheel-mode is already enabled by default on most graphical
displays.

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 03:06:18PM +0000, Stefan Kangas wrote:
>Ergus <spacibba@aol.com> writes:
>
>> 5) Enable winmove and mouse-wheel-mode by default.
>
>mouse-wheel-mode is already enabled by default on most graphical
>displays.
>
Right!... btw why not in the terminal?

Re: Changes for emacs 28

[Stefan Monnier]

>>> 5) Enable winmove and mouse-wheel-mode by default.
>> mouse-wheel-mode is already enabled by default on most graphical
>> displays.
> Right!... btw why not in the terminal?

I think it *is* enabled in the terminal as well.

But it only works if you ask to capture the terminal's mouse buttons
with `xterm-mouse-mode`.


        Stefan "who doesn't use a mouse any more"

Re: Changes for emacs 28

[Ergus]

On Sun, Sep 06, 2020 at 12:54:08PM -0400, Stefan Monnier wrote:
>>>> 5) Enable winmove and mouse-wheel-mode by default.
>>> mouse-wheel-mode is already enabled by default on most graphical
>>> displays.
>> Right!... btw why not in the terminal?
>
>I think it *is* enabled in the terminal as well.
>
>But it only works if you ask to capture the terminal's mouse buttons
>with `xterm-mouse-mode`.
>
>
>        Stefan "who doesn't use a mouse any more"
>
Hi Stefan:

Is there a reason why the user needs to enable this explicitly? The
wheel and mouse works for me when using man/less/vim, out of the
box. Couldn't we do the same?

Best,
Ergus

Re: Changes for emacs 28

[Alfred M. Szmidt]

   >I think it *is* enabled in the terminal as well.
   >
   >But it only works if you ask to capture the terminal's mouse buttons
   >with `xterm-mouse-mode`.

   Is there a reason why the user needs to enable this explicitly? The
   wheel and mouse works for me when using man/less/vim, out of the
   box. Couldn't we do the same?

Not everyone uses xterm as their terminal of choise.

Re: Changes for emacs 28

[Stefan Monnier]

>    Is there a reason why the user needs to enable this explicitly?

IIRC the issue is that it prevents *other* uses of the mouse in xterm.
But I'm not quite sure what these are nor how important they are.
Maybe it's time to make a formal request to enable it by default?

> Not everyone uses xterm as their terminal of choise.

Not sure how that's related.  `xterm-mouse-mode` should only have an
effect in the terminals in which it works.  Are you saying that it is
known to have undesirable side-effects in some terminals?


        Stefan

Re: Changes for emacs 28

[Alfred M. Szmidt]

   >    Is there a reason why the user needs to enable this explicitly?

   IIRC the issue is that it prevents *other* uses of the mouse in xterm.
   But I'm not quite sure what these are nor how important they are.
   Maybe it's time to make a formal request to enable it by default?

I tried it in xterm, it doesn't conflict with the standard
C-mouse-1/2/3 pop-up menus that are available there.

   > Not everyone uses xterm as their terminal of choise.

   Not sure how that's related.  `xterm-mouse-mode` should only have an
   effect in the terminals in which it works.  Are you saying that it is
   known to have undesirable side-effects in some terminals?

If it is only enabled when one uses a xterm compatible terminal, I
don't see any harm.  But it would be strange to have xterm features
enabled when ones terminal isn't xterm, and still support mousy stuff.

Re: Changes for emacs 28

[Mario Lang]

Ergus <spacibba@aol.com> writes:

> 3) Substitute list-buffers with ibuffer: This is actually in the TODO
> but for interactive users ibuffer offers a bit more modern
> experience. So the proposition is just to set ibuffer to the default
> bindings as so far it already offers all the list-buffers'
> functionalities.

+1

> 4) Enable display-line-numbers-mode by default. Almost all editors
> around have line numbers by default why we hide them?

No, please don't.  Maybe I am already too old, but I don't know what
these other editors you are talking about would be.  I never saw vim or
nano do that by default, and I am grateful for that.

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Mario Lang <mlang@blind.guru>
> Date: Tue, 08 Sep 2020 10:25:15 +0200
> Cc: emacs-devel@gnu.org
> 
> Ergus <spacibba@aol.com> writes:
> 
> > 3) Substitute list-buffers with ibuffer: This is actually in the TODO
> > but for interactive users ibuffer offers a bit more modern
> > experience. So the proposition is just to set ibuffer to the default
> > bindings as so far it already offers all the list-buffers'
> > functionalities.
> 
> +1
> 
> > 4) Enable display-line-numbers-mode by default. Almost all editors
> > around have line numbers by default why we hide them?
> 
> No, please don't.  Maybe I am already too old, but I don't know what
> these other editors you are talking about would be.  I never saw vim or
> nano do that by default, and I am grateful for that.

See, that's exactly the crux of the difficulty in these matters: ask N
people about changing defaults to M options, and you get the number of
different "please do this and this, but not that" opinions almost as
large as the number of permutations.

So either (1) we go for the lowest common denominator of features that
most people agree to (which can easily be an empty set); or (2) we
come up with groups of optional features which are turned on and off
together.  The latter needs someone who'd figure out such groups,
based on some principles, like experience or the kind of jobs that
people want to do, or something else.  It isn't easy, but unless
someone picks up the gauntlet, we will never move in that direction.

Re: Changes for emacs 28

[Stefan Monnier]

> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set);

That's what we've been doing so far.  I think we should keep doing it,
of course, because it's pretty much the only choice for the "default
defaults".

Beside this, we could create a kind of hierarchical configuration
system, where the hierarchy is not (like is the case in Custom) based
only on functionality, but rather on "popularity/importance/frequency".

We already have a bit of that with the few options which are placed
directly in the `Options` menu.  We could offer a menu entry "Settings"
which shows the "most commonly" requested settings (in a buffer rather
than in a submenu).  Not sure if we'd need "advanced settings" as an
intermediate point before getting to the "exhaustive" list of settings
available currently via Customize.

> or (2) we come up with groups of optional features which are turned on
> and off together.

These sound like Custom themes.  Currently we only use them for
aesthetics (faces, basically), but we should probably try to develop
them further to cover similar needs to the ones satisfied by
Doom/Spacemacs/StarterKit/...

> It isn't easy, but unless someone picks up the gauntlet, we will never
> move in that direction.

Agreed.  Maybe we should start small and try to create a few simple
custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...

And ideally someone should try and see what breaks down when we try and
create a theme that mimicks Prelude or Starter Kit, and then work
towards lifting those restrictions.


        Stefan

Re: Changes for emacs 28

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Mario Lang <mlang@blind.guru>,  spacibba@aol.com,  emacs-devel@gnu.org
> Date: Tue, 08 Sep 2020 10:51:14 -0400
> 
> > It isn't easy, but unless someone picks up the gauntlet, we will never
> > move in that direction.
> 
> Agreed.  Maybe we should start small and try to create a few simple
> custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...

That'd be fine, although I'd rather prefer themes that sound like
Python-programming and Ruby-programming, and Atom, Sublime and VSCode
instead of Vim...

Re: Changes for emacs 28

[Stefan Monnier]

> That'd be fine, although I'd rather prefer themes that sound like
> Python-programming and Ruby-programming,

I think these usually aren't "themes".  They're rather integration work
that make things work the way they should, regardless of preference.
We definitely should work on that, but I don't think it's fit for
a custom theme.

> and Atom, Sublime and VSCode instead of Vim...

;-)


        Stefan

Re: Changes for emacs 28

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Beside this, we could create a kind of hierarchical configuration
> system, where the hierarchy is not (like is the case in Custom) based
> only on functionality, but rather on "popularity/importance/frequency".

It would also be good to be able to be able to present options in a
logical and predetermined order in custom instead of the current
alphabetical order.  Could custom be extended to handle that?  Maybe we
could add a :weight property to defcustom?

> We already have a bit of that with the few options which are placed
> directly in the `Options` menu.  We could offer a menu entry "Settings"
> which shows the "most commonly" requested settings (in a buffer rather
> than in a submenu).

Agreed, excellent idea.

> Agreed.  Maybe we should start small and try to create a few simple
> custom-themes like `emacs24`, `emacs19`, `dark-background`, `Vim`, ...
>
> And ideally someone should try and see what breaks down when we try and
> create a theme that mimicks Prelude or Starter Kit, and then work
> towards lifting those restrictions.

Agreed.  (Although I'm looking for the 'emacs29' theme myself.)

RE: Changes for emacs 28

[Drew Adams]

> > Beside this, we could create a kind of hierarchical configuration
> > system, where the hierarchy is not (like is the case in Custom) based
> > only on functionality, but rather on "popularity/importance/frequency".
> 
> It would also be good to be able to be able to present options in a
> logical and predetermined order in custom instead of the current
> alphabetical order.  Could custom be extended to handle that?  Maybe we
> could add a :weight property to defcustom?

Isn't that what :group is about?  An author can assign
any option or face to any number of :groups.

A :group is thus like a Delicious-style tag, in a way.

https://en.wikipedia.org/wiki/Delicious_(website)

Finder keywords, that is, keywords in a `Keywords'
file-header field, are also like tags in this way.

`customize-group' and `finder-by-keyword' are UI
entry points.  They could be improved.

Uses of finder keywords haven't been too systematic
so far.  And :group has been used sparingly so far.

But both seem to have this property that you can
assign multiple such "tags" to a thing (file/library
for finder keywords, option/face for :groups).

An advantage of organization by such tags is that
there can be any number of "logical and predetermined
orders".  Or rather, tags define sets, which are
unordered, but there can be hierarchies of sets.  And
the sets - their hierarchies and their elements - are
easily updated/redefined.

Re: Changes for emacs 28

[Dmitry Gutov]

On 08.09.2020 17:35, Eli Zaretskii wrote:
> See, that's exactly the crux of the difficulty in these matters: ask N
> people about changing defaults to M options, and you get the number of
> different "please do this and this, but not that" opinions almost as
> large as the number of permutations.

Honestly, I don't think that enabling (or not) display-line-numbers-mode 
is going to be a big deal either way: it's easy to enable or disable, 
and it has little far-reaching consequences otherwise.

Certainly fewer consequences that changing the default theme to dark, or 
enabling cua-mode by default, or even incorporating which-key.

Likewise for ibuffer vs list-buffers (though it'll be a bit harder to 
change back).

> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set); or (2) we
> come up with groups of optional features which are turned on and off
> together.

Orthogonally, we could decide on a method for changing defaults which 
doesn't involve the impossible task of making everybody happy but still 
makes some effort to change with the times.

Re: Changes for emacs 28

[Eli Zaretskii]

> Cc: spacibba@aol.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 9 Sep 2020 01:06:31 +0300
> 
> On 08.09.2020 17:35, Eli Zaretskii wrote:
> > See, that's exactly the crux of the difficulty in these matters: ask N
> > people about changing defaults to M options, and you get the number of
> > different "please do this and this, but not that" opinions almost as
> > large as the number of permutations.
> 
> Honestly, I don't think that enabling (or not) display-line-numbers-mode 
> is going to be a big deal either way: it's easy to enable or disable, 
> and it has little far-reaching consequences otherwise.

That was only an example.

And anyway, isn't what you say above true for almost every optional
feature in Emacs?

> > So either (1) we go for the lowest common denominator of features that
> > most people agree to (which can easily be an empty set); or (2) we
> > come up with groups of optional features which are turned on and off
> > together.
> 
> Orthogonally, we could decide on a method for changing defaults which 
> doesn't involve the impossible task of making everybody happy but still 
> makes some effort to change with the times.

If this can be done, why not?  But based on past experience, I'm
skeptical, to tell the truth.

Re: Changes for emacs 28

[Dmitry Gutov]

On 09.09.2020 17:04, Eli Zaretskii wrote:

>> On 08.09.2020 17:35, Eli Zaretskii wrote:
>>> See, that's exactly the crux of the difficulty in these matters: ask N
>>> people about changing defaults to M options, and you get the number of
>>> different "please do this and this, but not that" opinions almost as
>>> large as the number of permutations.
>>
>> Honestly, I don't think that enabling (or not) display-line-numbers-mode
>> is going to be a big deal either way: it's easy to enable or disable,
>> and it has little far-reaching consequences otherwise.
> 
> That was only an example.
> 
> And anyway, isn't what you say above true for almost every optional
> feature in Emacs?

For a lot of them, yes. But of course there are also changes in behavior 
(that people also asked for) that can have farther-reaching consequences.

So I do believe we shouldn't worry too much about making some existing 
users moderately unhappy if we have convincing data that a given change 
will make Emacs more useful or more approachable (without making it less 
useful) for a lot of users, current or future ones. Especially if said 
optional feature is easy to toggle, and we can document how to negate 
the change in NEWS.

Repeat the same decision process M times.

Since this way there is no goal of making every user 100% happy, there 
is no stalemate.

>>> So either (1) we go for the lowest common denominator of features that
>>> most people agree to (which can easily be an empty set); or (2) we
>>> come up with groups of optional features which are turned on and off
>>> together.
>>
>> Orthogonally, we could decide on a method for changing defaults which
>> doesn't involve the impossible task of making everybody happy but still
>> makes some effort to change with the times.
> 
> If this can be done, why not?
> But based on past experience, I'm
> skeptical, to tell the truth.

 From my past experience, what was lacking is direction in leadership. 
Sorry to be blunt.

There were cases where we had evidence that a change will be welcome by 
the majority of users, existing and potential ones, and would be easily 
reverted locally by anybody who didn't like it, and it still wasn't 
made. E.g. the simple case of indent-tabs-mode=>nil.

Of course, not all cases are simple, and whether something is generally 
beneficial/user-friendly/etc is a matter of judgment. But at least we 
shouldn't be stopped by the sole concern that a given change can 
generate complaints because the option in question has held a certain 
value for a number of years. Or even decades.

Re: Changes for emacs 28

[Howard Melman]

Eli Zaretskii <eliz@gnu.org> writes:

> See, that's exactly the crux of the difficulty in these matters: ask N
> people about changing defaults to M options, and you get the number of
> different "please do this and this, but not that" opinions almost as
> large as the number of permutations.
>
> So either (1) we go for the lowest common denominator of features that
> most people agree to (which can easily be an empty set); or (2) we
> come up with groups of optional features which are turned on and off
> together.  The latter needs someone who'd figure out such groups,
> based on some principles, like experience or the kind of jobs that
> people want to do, or something else.  It isn't easy, but unless
> someone picks up the gauntlet, we will never move in that direction.

How about creating a new function that generates a report of
how a user has configured emacs.  Various options,
global-minor-modes, faces, etc, similar to what
report-emacs-bug generates.  Setup a separate email address
to receive reports and automatically tabulate what the
popular settings are.

Ship it with emacs 28.  Let it percolate into Doom,
Spacemacs and other distributions.  Then ask people far and
wide to run it.  This would generate actual data about
what's popular and what defaults people typically change and
could settle these recurring debates.

Like report-emacs-bug, it should display the info to the
user before sending so they can check that nothing personal
is revealed.

-- 

Howard

Re: Changes for emacs 28

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > 4) Enable display-line-numbers-mode by default. Almost all editors
  > > around have line numbers by default why we hide them?

  > No, please don't.  Maybe I am already too old, but I don't know what
  > these other editors you are talking about would be.  I never saw vim or
  > nano do that by default, and I am grateful for that.

Maybe the default for this should depend on the width of the frame.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Changes for emacs 28

[Philip K.]

Ergus <spacibba@aol.com> writes:

> Hi Emacs:
>
> As 27 has just been released I think it is time to start considering
> changes for the release 28. I will add some points I think we could
> discuss (specially implying defaults) in order to hear opinions and have
> enough time to discuss/implement them.

Most of the discussions seems to have revolved around user-facing
changes, but I think it might also be time to clean-up some of the
internal code. There are vast discrepancies in style between newer
modules such as xref or project and older systems such as hippie-expand
and Rmail.

My hope would be that with easier interfaces to work with, that leverage
Elisp improvements, that more people would be interested in using,
supporting and extending OOTB packages/modules. My fear is that
backwards compatibility would be at risk.

---

And regarding modernizing defaults, how about bundling a few "themes"
that enable/disable a few settings. It might be confusing at first, as
most people associate themes with visual customisations, but since Emacs
interprets the term more generally, adding themes such as "Modern" that
enables more bells and whistles (I'm not too enthusiastic about the
name, some might have chosen "Hipster" instead :^)), "Minimal" that
reduces UI, etc. might be a compromise between the fractions that want
to make Emacs appealing to newcomers and those that don't want to break
Emacs' way-of-operating by default.

-- 
	Philip K.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Gcc: nnfolder+archive:sent.2020-09
> Date: Wed, 09 Sep 2020 19:14:29 +0200
> 
> And regarding modernizing defaults, how about bundling a few "themes"
> that enable/disable a few settings. It might be confusing at first, as
> most people associate themes with visual customisations, but since Emacs
> interprets the term more generally, adding themes such as "Modern" that
> enables more bells and whistles (I'm not too enthusiastic about the
> name, some might have chosen "Hipster" instead :^)), "Minimal" that
> reduces UI, etc. might be a compromise between the fractions that want
> to make Emacs appealing to newcomers and those that don't want to break
> Emacs' way-of-operating by default.

We already have a couple of such themes, so the issue of us accepting
such themes doesn't exist.

P.S.  Please review your MUA settings, because they just caused Emacs
to exclude the mailing list from the recipients, something that is
unwanted.

Re: Changes for emacs 28

[Eli Zaretskii]

> Date: Thu, 10 Sep 2020 12:40:37 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> 
> P.S.  Please review your MUA settings, because they just caused Emacs
> to exclude the mailing list from the recipients, something that is
> unwanted.                            ^^^^^^^^^^

I meant the recipients of the response message, i.e. the addresses
automatically added to a response message by Emacs.

Re: Changes for emacs 28

[Philip K.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Philip K." <philipk@posteo.net>
>> Gcc: nnfolder+archive:sent.2020-09
>> Date: Wed, 09 Sep 2020 19:14:29 +0200
>> 
>> And regarding modernizing defaults, how about bundling a few "themes"
>> that enable/disable a few settings. It might be confusing at first, as
>> most people associate themes with visual customisations, but since Emacs
>> interprets the term more generally, adding themes such as "Modern" that
>> enables more bells and whistles (I'm not too enthusiastic about the
>> name, some might have chosen "Hipster" instead :^)), "Minimal" that
>> reduces UI, etc. might be a compromise between the fractions that want
>> to make Emacs appealing to newcomers and those that don't want to break
>> Emacs' way-of-operating by default.
>
> We already have a couple of such themes, so the issue of us accepting
> such themes doesn't exist.

Oh, I didn't know that? Is this being done in a separate feature branch?

> P.S.  Please review your MUA settings, because they just caused Emacs
> to exclude the mailing list from the recipients, something that is
> unwanted.

My apologies, again, I use Gnus to follow the mailing list, but forget
that unlike Rmail, it doesn't reply to every when 'R' is pressed.

-- 
	Philip K.

Re: Changes for emacs 28

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> Date: Thu, 10 Sep 2020 17:08:25 +0200
> 
> >> And regarding modernizing defaults, how about bundling a few "themes"
> >> that enable/disable a few settings. It might be confusing at first, as
> >> most people associate themes with visual customisations, but since Emacs
> >> interprets the term more generally, adding themes such as "Modern" that
> >> enables more bells and whistles (I'm not too enthusiastic about the
> >> name, some might have chosen "Hipster" instead :^)), "Minimal" that
> >> reduces UI, etc. might be a compromise between the fractions that want
> >> to make Emacs appealing to newcomers and those that don't want to break
> >> Emacs' way-of-operating by default.
> >
> > We already have a couple of such themes, so the issue of us accepting
> > such themes doesn't exist.
> 
> Oh, I didn't know that? Is this being done in a separate feature branch?

No, those themes are on master.

Re: Changes for emacs 28

[Tassilo Horn]

Ergus <spacibba@aol.com> writes:

> 1) Improve the default theme: Maybe set a default dark theme to make
> emacs feel more modern.

If you just set your background to some dark color, the stock Emacs
default faces are actually very nice, see:

  https://functional.cafe/web/statuses/104411970368324669

So just a default face light/dark toggle which doesn't use a theme but
the standard faces seems like a good idea.

Bye,
Tassilo

Re: Changes for emacs 28

[Philip K.]

Tassilo Horn <tsdh@gnu.org> writes:

> Ergus <spacibba@aol.com> writes:
>
>> 1) Improve the default theme: Maybe set a default dark theme to make
>> emacs feel more modern.
>
> If you just set your background to some dark color, the stock Emacs
> default faces are actually very nice, see:
>
>   https://functional.cafe/web/statuses/104411970368324669
>
> So just a default face light/dark toggle which doesn't use a theme but
> the standard faces seems like a good idea.
>
> Bye,
> Tassilo

That actually looks fairly similar to my own "dark mode":

        (defun reverse-face (face &optional frame)
          "Set FACE (in FRAME) to RGB inverse."
          (interactive (list (read-face-name "Reverse face" (face-at-point t))))
          (require 'color)
          (ignore-errors
            (let ((fg (face-attribute face :foreground frame))
                  (bg (face-attribute face :background frame)))
              (set-face-attribute
               face frame
               :foreground (color-complement-hex fg)
               :background (color-complement-hex bg)))))

        (defun toggle-dark-mode ()
          "Toggle dark mode."
          (interactive)
          (dolist (face '(mode-line default))
            (reverse-face face)))

-- 
	Philip K.