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

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.

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

[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

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

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

[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

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

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

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.