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: "modern" colors Re: Changes for emacs 28

[ej32u]

From: 	Ergus
Subject: 	Re: "modern" colors Re: Changes for emacs 28
Date: 	Thu, 10 Sep 2020 20:58:50 +0200


     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

-----

There is the command `tmm-menu-bar' which is bound to "M-`". Would it make sense 
to remap this to `menu-bar-open' instead?

Re: "modern" colors Re: Changes for emacs 28

[ej32u]

From: 	Ergus
Subject: 	Re: "modern" colors Re: Changes for emacs 28
Date: 	Thu, 10 Sep 2020 20:58:50 +0200


     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

-----

There is the command `tmm-menu-bar' which is bound to "M-`". Would it make sense 
to remap this to `menu-bar-open' instead?

RE: "modern" colors Re: Changes for emacs 28

[Drew Adams]

> There is the command `tmm-menu-bar' which is bound to "M-`". Would it make
> sense to remap this to `menu-bar-open' instead?

The behavior provided by `lacarte.el' is superior
to that provided by `tmm-menu-bar', IMO.

It lets you more easily navigate to different
parts of the menu hierarchy, using completion.

It's especially nice if you use more than just
basic (prefix) completion - even just substring
matching is helpful.

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

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

RE: "modern" colors Re: Changes for emacs 28

[arthur miller]

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


-------- Originalmeddelande --------
Från: Dmitry Gutov <dgutov@yandex.ru>
Datum: 2020-09-13 02:17 (GMT+01:00)
Till: Arthur Miller <arthur.miller@live.com>, Ricardo Wurmus <rekado@elephly.net>
Kopia: casouri@gmail.com, Ergus <spacibba@aol.com>, emacs-devel@gnu.org, "Alfred M. Szmidt" <ams@gnu.org>, monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
Ämne: Re: "modern" colors Re: Changes for emacs 28

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).

------‐--------
There is some addon, Solarized-dark everywhere for Firefox (or something similar) which makes Ffx render all websites in Solarized colors.

But to the topic, I indeed suggested to include Solarized in Emacs, but I also suggested to turn Batsov's implementation of Solarized into more general framework for defining color schemes in Emacs so that people can use it to easily create  and I stall whichever color scheme they like. Thus it does not need to be limited to low contrast at all.

It would make Emacs look more aesthetically pleasing if packages output data in more color consistent and coherent  way instead of everyone sprinkling hardcoded RGB values for their outputs.

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

Re: "modern" colors Re: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 03:36, arthur miller wrote:
> But to the topic, I indeed suggested to include Solarized in Emacs, but 
> I also suggested to turn Batsov's implementation of Solarized into more 
> general framework for defining color schemes in Emacs so that people can 
> use it to easily create  and I stall whichever color scheme they like. 
> Thus it does not need to be limited to low contrast at all.

Yes, it's an interesting idea. I don't have the time to explore it, but 
others are very welcome to.

> It would make Emacs look more aesthetically pleasing if packages output 
> data in more color consistent and coherent  way instead of everyone 
> sprinkling hardcoded RGB values for their outputs.

Yup. It sounds like a big change, though.

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

  > > It would make Emacs look more aesthetically pleasing if packages output 
  > > data in more color consistent and coherent  way instead of everyone 
  > > sprinkling hardcoded RGB values for their outputs.

  > Yup. It sounds like a big change, though.

A small part of Emacs interprets color specifications.
If we want to define a new kind of color specification,
perhaps defined in terms of solarized, it whould not be hard.

The hard question is what we WANT to do.  Does someone want to
study the details and 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: "modern" colors Re: Changes for emacs 28

[TEC]

Richard Stallman <rms@gnu.org> writes:
> The hard question is what we WANT to do.  Does someone want to
> study the details and make a concrete proposal?

I'm seeing a trend here along the lines of:
 - general idea sounds good
 - a fully-formed proposal (with specifics) is needed

Does that sound about right for this discussion?

Timothy.

Re: "modern" colors Re: Changes for emacs 28

[Ergus]

On Mon, Sep 14, 2020 at 01:14:42PM +0800, TEC wrote:
>
>Richard Stallman <rms@gnu.org> writes:
>> The hard question is what we WANT to do.  Does someone want to
>> study the details and make a concrete proposal?
>
>I'm seeing a trend here along the lines of:
> - general idea sounds good
> - a fully-formed proposal (with specifics) is needed
>
>Does that sound about right for this discussion?
>
>Timothy.

Somehow I just mentioned the color as part of the changes in the first
email in this thread and very intense answers came out. So I just passed
the topic.

Someone proposed some days ago to have some sort of profiles... which
for me is good enough and we already have the theme loader. What, I
think we need now is just a better set of included themes as the
embedded ones look outdated (specially in terminal). But there are
plenty of themes around, we just need to make a selection.

IMO the other very important detail are the fonts, we usually use the
ones in the system which are very good in systems like ubuntu but not so
good in others like Debian.

Maybe we should establish our own criteria here over the system if the
system does not provide any default information and there is not config
file yet. But this is something that I think will be solved if we
finally implement the "welcome screen".

I don't know if we should provide our own set of "extra pretty fonts" to
use them in Emacs where they aren't installed.

Re: "modern" colors Re: Changes for emacs 28

[Göktuğ Kayaalp]

On 2020-09-14 09:35 +03, Ergus <spacibba@aol.com> wrote:
> I don't know if we should provide our own set of "extra pretty fonts" to
> use them in Emacs where they aren't installed.

Put them under ~/.fonts.  That might require running fc-cache(1).

--
İ. 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:18:57AM +0300, Göktuğ Kayaalp wrote:
>On 2020-09-14 09:35 +03, Ergus <spacibba@aol.com> wrote:
>> I don't know if we should provide our own set of "extra pretty fonts" to
>> use them in Emacs where they aren't installed.
>
>Put them under ~/.fonts.  That might require running fc-cache(1).
>
I am talking for OOTB experience but also for windows and Mac where the
process may be different.

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

  > I'm seeing a trend here along the lines of:
  >  - general idea sounds good
  >  - a fully-formed proposal (with specifics) is needed

  > Does that sound about right for this discussion?

Discussions of general ideas can only give a start.
Further progress has to center on specific proposals.
The initial proposals will have flaws, and we can see
if it is possible to correct them and make a usable 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: "modern" colors 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. ]]]
>
>   > > It would make Emacs look more aesthetically pleasing if packages output 
>   > > data in more color consistent and coherent  way instead of everyone 
>   > > sprinkling hardcoded RGB values for their outputs.
>
>   > Yup. It sounds like a big change, though.
>
> A small part of Emacs interprets color specifications.
> If we want to define a new kind of color specification,
> perhaps defined in terms of solarized, it whould not be hard.
>

I was thinking about it a bit, and was looking at the code of Bozhidar's
Solarized implementation. I think it is rather a trivial thing to do.

Here is what I think is a specific of Emacs: 

1. Emacs has not parametrized names for colors of standard GUI elements
(as I am aware of); so both Emacs internally, and third party packages
are using color values directly for GUI elements (variables like
forground, background etc). It results in Emacs theme having to go to
great deal of color customizations when it comes to third party packages
in particular. For illustration take at look at

https://github.com/bbatsov/solarized-emacs/blob/master/solarized-faces.el

Or themes don't do this which results in less coherent visual appereance
in the end.

2. Everything in Emacs is text (mostly); that is one of best features of
Emacs but it also means that pretty much any defvar can become a part of
gui which leads to third party packages using color values directly (or
none). It makes it hard for themes to create unified looks in Emacs for all the
diverse packages that are out there.

What is nice with original Solarized by Ethan S. is that there is
"logical framework" to think about colors: he defines base colors
(background, foreground, selection etc) and accented colors for
information that has to stand out. Bozhidar's implementation adds ligher
and darker variant to accented colors. But best part with Bozhidar's
Solarized for Emacs is that he has done a lion share of work on styling
thrid party packages:

https://github.com/bbatsov/solarized-emacs/blob/master/solarized-faces.el

to make them consistent Emacs GUI and Solarized theme.

I think his theme implementation can be simplified, paramtrized and
turned into relatively simple framework to use.

For end users who would like to create a color scheme it could be as
easy as just specifying a two arrays of colors, base and accented ones.
For package creators, elisp scripting etc, it could be relatively simply
to use paramerized names like cs-accent-1, cs-accent-darker-1 etc (cs =
color-scheme), or something similar. It shouldn't be hard to write a
manual/docs on how to use the framework either since it is pretty much
trivial.

I can try to refactor Bozhidar's code if it is interesting (I have been
playing with it for my own purpose soem time ago), if Bozhidar himself is
not reading this list and don't' have opinions on this by himself.

> The hard question is what we WANT to do.  Does someone want to
> study the details and make a concrete proposal?

Concrete proposal would be:

1. remove dark/light variant and some color blending code which is
specific for Solarized theme itself to simplify the framework. 

2. parametrize names, instead of yellow, magenta etc, use something like
cs-accent-1, cs-accent-2, cs-base-1, cs-base-2 etc

3. create setter/getter api to manipulate base/accent color arrays
4. write nice docs/tips/guide how to use it

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

  > Concrete proposal would be:

  > 1. remove dark/light variant and some color blending code which is
  > specific for Solarized theme itself to simplify the framework. 

  > 2. parametrize names, instead of yellow, magenta etc, use something like
  > cs-accent-1, cs-accent-2, cs-base-1, cs-base-2 etc

  > 3. create setter/getter api to manipulate base/accent color arrays
  > 4. write nice docs/tips/guide how to use it

Thanks for making a concrete proposal.  Now I hope others will respond
concretely.

-- 
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

[Stefan Kangas]

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

> I was thinking about it a bit, and was looking at the code of Bozhidar's
> Solarized implementation. I think it is rather a trivial thing to do.
[...]
> I can try to refactor Bozhidar's code if it is interesting (I have been
> playing with it for my own purpose soem time ago), if Bozhidar himself is
> not reading this list and don't' have opinions on this by himself.

The biggest benefit would come from including something like this in
vanilla.

What is the status with regards to copyright assignment for that code?
I personally think the idea makes sense, but we would need to sort that
part out before we can consider it for vanilla.

Re: "modern" colors Re: Changes for emacs 28

[Arthur Miller]

Stefan Kangas <stefankangas@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I was thinking about it a bit, and was looking at the code of Bozhidar's
>> Solarized implementation. I think it is rather a trivial thing to do.
> [...]
>> I can try to refactor Bozhidar's code if it is interesting (I have been
>> playing with it for my own purpose soem time ago), if Bozhidar himself is
>> not reading this list and don't' have opinions on this by himself.
>
> The biggest benefit would come from including something like this in
> vanilla.
>
> What is the status with regards to copyright assignment for that code?
> I personally think the idea makes sense, but we would need to sort that
> part out before we can consider it for vanilla.
GPL 3

"Copyright © 2011-2020 Bozhidar Batsov, Thomas Frössman, and contributors.

Distributed under the GNU General Public License, version 3"

I don't know how many are contributors in the statement above

I have sent him email and ask if he is willing to assign the copyright
to fsf, and ask if he can check the dev-list himself; would be the best
if he has possibility to participate himself.
 

Re: "modern" colors Re: Changes for emacs 28

[Stefan Kangas]

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

>> What is the status with regards to copyright assignment for that code?
>> I personally think the idea makes sense, but we would need to sort that
>> part out before we can consider it for vanilla.
> GPL 3
>
> "Copyright © 2011-2020 Bozhidar Batsov, Thomas Frössman, and contributors.
>
> Distributed under the GNU General Public License, version 3"
>
> I don't know how many are contributors in the statement above
>
> I have sent him email and ask if he is willing to assign the copyright
> to fsf, and ask if he can check the dev-list himself; would be the best
> if he has possibility to participate himself.

Thanks.

I believe you can see a list of all contributors here:

    https://github.com/bbatsov/solarized-emacs/graphs/contributors

AFAIU, we would need copyright assignments for any contributor with more
than 15 lines of changes in total.

Re: "modern" colors Re: Changes for emacs 28

[Arthur Miller]

Stefan Kangas <stefankangas@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>>> What is the status with regards to copyright assignment for that code?
>>> I personally think the idea makes sense, but we would need to sort that
>>> part out before we can consider it for vanilla.
>> GPL 3
>>
>> "Copyright © 2011-2020 Bozhidar Batsov, Thomas Frössman, and contributors.
>>
>> Distributed under the GNU General Public License, version 3"
>>
>> I don't know how many are contributors in the statement above
>>
>> I have sent him email and ask if he is willing to assign the copyright
>> to fsf, and ask if he can check the dev-list himself; would be the best
>> if he has possibility to participate himself.
>
> Thanks.
>
> I believe you can see a list of all contributors here:
>
>     https://github.com/bbatsov/solarized-emacs/graphs/contributors
>
> AFAIU, we would need copyright assignments for any contributor with more
> than 15 lines of changes in total.

Ok, so the legal issues set stop for the proposal?

Some of the people seem familiar from this list :-), but some not; so I
guess getting them all to sign might be tedious if not impossible task?

Maybe it is then easiest just to implement some framework similar to
Solarized and then implement the theme itself afterwords?

Re: "modern" colors Re: Changes for emacs 28

[Stefan Kangas]

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

> Ok, so the legal issues set stop for the proposal?
>
> Some of the people seem familiar from this list :-), but some not; so I
> guess getting them all to sign might be tedious if not impossible task?

I don't think it stops it or makes it impossible.  We have had some
successful examples of collecting assignments in packages with even more
significant contributors than solarized.  One example is use-package,
which seems to be nearing completion:

  https://github.com/jwiegley/use-package/issues/282

So it's just something that someone would need to do.

> Maybe it is then easiest just to implement some framework similar to
> Solarized and then implement the theme itself afterwords?

I guess that depends entirely on the amount of contributors that don't
have assignments already.  Having only taken a cursory glance, my first
impression is that collecting the assignments looks a bit easier.

I'd personally encourage you to give it a go.  :-)

PS. See also:

      https://www.gnu.org/licenses/why-assign.html

Re: "modern" colors Re: Changes for emacs 28

[Arthur Miller]

Stefan Kangas <stefankangas@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Ok, so the legal issues set stop for the proposal?
>>
>> Some of the people seem familiar from this list :-), but some not; so I
>> guess getting them all to sign might be tedious if not impossible task?
>
> I don't think it stops it or makes it impossible.  We have had some
> successful examples of collecting assignments in packages with even more
> significant contributors than solarized.  One example is use-package,
> which seems to be nearing completion:
>
>   https://github.com/jwiegley/use-package/issues/282
>
> So it's just something that someone would need to do.
>
>> Maybe it is then easiest just to implement some framework similar to
>> Solarized and then implement the theme itself afterwords?
>
> I guess that depends entirely on the amount of contributors that don't
> have assignments already.  Having only taken a cursory glance, my first
> impression is that collecting the assignments looks a bit easier.
>
> I'd personally encourage you to give it a go.  :-)
>
> PS. See also:
>
>       https://www.gnu.org/licenses/why-assign.html

I have sent a mail to Bozhidar, and got answer I thought I forwarded to
this list; I don't see it myself though; but let give him some time and
see howit develops. If not much happens I'll file an issue on github
page and see how it goes from there.

Re: "modern" colors Re: Changes for emacs 28

[Marcus Harnisch]

On 13/09/2020 02.51, Dmitry Gutov wrote:
> On 13.09.2020 03:36, arthur miller wrote:
>> But to the topic, I indeed suggested to include Solarized in Emacs, 
>> but I also suggested to turn Batsov's implementation of Solarized into 
>> more general framework for defining color schemes in Emacs so that 
>> people can use it to easily create  and I stall whichever color scheme 
>> they like. Thus it does not need to be limited to low contrast at all.
> 
> Yes, it's an interesting idea. I don't have the time to explore it, but 
> others are very welcome to.
> 
>> It would make Emacs look more aesthetically pleasing if packages 
>> output data in more color consistent and coherent  way instead of 
>> everyone sprinkling hardcoded RGB values for their outputs.
> 
> Yup. It sounds like a big change, though.

You may want to check out base16-emacs 
(https://github.com/belak/base16-emacs) and the base16 meta-theme 
approach in general. I believe it does get pretty close to what is being 
discussed here. Solarized is available as base16 variant.

Re: "modern" colors Re: Changes for emacs 28

[Arthur Miller]

Marcus Harnisch <mh-mercurial@online.de> writes:

> On 13/09/2020 02.51, Dmitry Gutov wrote:
>> On 13.09.2020 03:36, arthur miller wrote:
>>> But to the topic, I indeed suggested to include Solarized in Emacs, but I
>>> also suggested to turn Batsov's implementation of Solarized into more general
>>> framework for defining color schemes in Emacs so that people can use it to
>>> easily create  and I stall whichever color scheme they like. Thus it does not
>>> need to be limited to low contrast at all.
>> Yes, it's an interesting idea. I don't have the time to explore it, but others
>> are very welcome to.
>> 
>>> It would make Emacs look more aesthetically pleasing if packages output data
>>> in more color consistent and coherent  way instead of everyone sprinkling
>>> hardcoded RGB values for their outputs.
>> Yup. It sounds like a big change, though.
>
> You may want to check out base16-emacs (https://github.com/belak/base16-emacs)
> and the base16 meta-theme approach in general.
Ok! I never heard of base16 before; I have just skimmed over the code of
it a bit.

I don't care which framework is used as long as there is some, but what
I can see by just skimming over the code on github, they use names
base0-base15 (in hex:-); I would prefer the Solarized naming scheme,
since it adds more "logical separation" base1-base8 and accent1-accent8.
If a 3rd party package would use such names, then accent1-accent8 would
be names they care about, unless that package is a theme. I would also
like to see more logical names (either a defvaralias or a macro)
describing what base1 is used for, something cs-main-backgroung
cs-main-foreground, cs-highlight-color etc.

> I believe it does get pretty close to what is being discussed here.
> Solarized is available as base16 variant.
Indeed the idea used in base16 seem to be very similar to what I proposed. 

I checked hastily link provided and also like this idea too:

https://github.com/makuto/auto-base16-theme

"This script generates a base16 color theme intended for code syntax
highlighting from a source image."

But I don't understand if they mean they use the auto created theme just
for syntax highlighting or to theme gui elements. Does not matter.

RE: "modern" colors Re: Changes for emacs 28

[arthur miller]

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


-------- Originalmeddelande --------
Från: Dmitry Gutov <dgutov@yandex.ru>
Datum: 2020-09-13 02:45 (GMT+01:00)
Till: Arthur Miller <arthur.miller@live.com>, "Alfred M. Szmidt" <ams@gnu.org>
Kopia: Ergus <spacibba@aol.com>, casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, ghe@sdf.org, tecosaur@gmail.com
Ämne: Re: "modern" colors Re: Changes for emacs 28

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
-----------

It was in the middle of the afternoon when light is at brightest at my place :-).

I don't think it is a misconception. I understand your reasoning but I don't think it really applies. Yeah, sure, there is some adaptation and o on between dark and light, but try to stare at Sun on a shiny day, or to stare  longer time at a light bulb. I don't think your eyes will appreciate, mine certainly won't.

I also think there is a lot of subjectivity here. Muscles and sensitivity is different from person to person. By the way I didn't claim it was a scientific experiment,  just my perception atm.

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

Re: "modern" colors Re: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 04:26, arthur miller wrote:

> It was in the middle of the afternoon when light is at brightest at my 
> place :-).
> 
> I don't think it is a misconception. I understand your reasoning but I 
> don't think it really applies. Yeah, sure, there is some adaptation and 
> o on between dark and light, but try to stare at Sun on a shiny day, or 
> to stare  longer time at a light bulb. I don't think your eyes will 
> appreciate, mine certainly won't.

A sun is much brighter than its background. Same for the light bulb.

So as first step I would really recommend calibrating the screen's 
brightness so that the usual background of many programs and websites 
(shades of near-white) doesn't look like a sun compared to the room's 
lighting. Just look at the wall behind the screen and compare 
accordingly. A 30%-50% brightness can work well. Or even lower.

> I also think there is a lot of subjectivity here. Muscles and 
> sensitivity is different from person to person. By the way I didn't 
> claim it was a scientific experiment,  just my perception atm.

There are, of course, personal factors as well.

BTW, did you change the email client recently? It seems to use a 
different quoting style, and it breaks discussion threads (creates a new 
one with easy reply).

Re: "modern" colors Re: Changes for emacs 28

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.09.2020 04:26, arthur miller wrote:
>
>> It was in the middle of the afternoon when light is at brightest at my place
>> :-).
>> I don't think it is a misconception. I understand your reasoning but I don't
>> think it really applies. Yeah, sure, there is some adaptation and o on between
>> dark and light, but try to stare at Sun on a shiny day, or to stare  longer
>> time at a light bulb. I don't think your eyes will appreciate, mine certainly
>> won't.
>
> A sun is much brighter than its background. Same for the light bulb.
Indeed. But eyes should get used to it if you stared at it. Get a big
wide lamp like they have at construction sites so it completely
overshadows the background. Eyes would still find too much light hard to
look at. It was just a comment on "more light is better" as I understand
your comment I answered; and that is why I think it does not apply in
this case. Observe that I am not an expert in such matters; so you might
as well be correct, I don't really know, I just have some sense it is
not that easy.

> BTW, did you change the email client recently? It seems to use a different
> quoting style, and it breaks discussion threads (creates a new one with easy
> reply).
When I am not at home and have some spare time I answer from my phone.
But (observe!) I have edited bort "The email is changned from my *****
phone." since Thomas find it annoying :-).

Sorry for the inconvenience if it is hard to follow my mails; I tried to
make it easier by underscoring your text.

Re: "modern" colors Re: Changes for emacs 28

[Dmitry Gutov]

On 13.09.2020 14:50, Arthur Miller wrote:

>> A sun is much brighter than its background. Same for the light bulb.
> Indeed. But eyes should get used to it if you stared at it. Get a big
> wide lamp like they have at construction sites so it completely
> overshadows the background. Eyes would still find too much light hard to
> look at. It was just a comment on "more light is better" as I understand
> your comment I answered; and that is why I think it does not apply in
> this case.

Indeed, there is a certain limit, but as the example with daylight 
shows, it's considerably above the brightness of an average screen. 
Screen usually seem too bright because the room around them is darker, 
and the eyes have adapted to that particular level of illumination.

It is especially easy to notice if you take a laptop with you to work 
somewhere in a park in a bright day.

> Observe that I am not an expert in such matters; so you might
> as well be correct, I don't really know, I just have some sense it is
> not that easy.

It might be not too easy to take my advice because the same dark themes 
you liked become that much less legible as soon as you lower the 
monitor's brightness. For example, if I set the brightness to 100%, the 
Solarized theme becomes legible enough (which I complained about 
earlier), and the Github background might indeed look too bright, which 
mirrors you experience.

As soon as I lower the brightness enough for a white background to be 
easy to look at, the same Solarized theme becomes unusable.

>> BTW, did you change the email client recently? It seems to use a different
>> quoting style, and it breaks discussion threads (creates a new one with easy
>> reply).
> When I am not at home and have some spare time I answer from my phone.
> But (observe!) I have edited bort "The email is changned from my *****
> phone." since Thomas find it annoying :-).
> 
> Sorry for the inconvenience if it is hard to follow my mails; I tried to
> make it easier by underscoring your text.

Just wanted to make sure you are aware.

The broken threading hurts the most, but an email is better than no 
email, so please don't worry about it too much.