* RE: A modern-mode? [not found] ` <<E1kIPmO-0001u5-0m@fencepost.gnu.org> @ 2020-09-16 14:37 ` Drew Adams 0 siblings, 0 replies; 96+ messages in thread From: Drew Adams @ 2020-09-16 14:37 UTC (permalink / raw To: Alfred M. Szmidt, Andrea Corallo; +Cc: emacs-devel > following recent discussions I've started toying with what I've pushed on > scratch/modern-mode. > > What some find modern, some will find old. What some find old, some > will find modern. What was once modern will become old again, and > what was old again will become modern. The term "modern" should definitely never be used to name something in Emacs. That just invites mocking as anachronism. Everything someone thinks is old-fashioned today could have been, and some things were, labeled "modern" at some point. And in the world of marketing, that has often been done in a way that associates the thing with, well, just phony advertising. "Modern" has a connotation of fad, hot, or fashion. If you really want someone to think your thing is new, hot, or fashionable, don't call it "modern". > A different name would be more appropriate. Yes, and a name that _actually_ describes the thing. If you can't describe it in a way that gets your point across, it might well be that you don't have much of a point to get across. If the most/best you can say about something is that it is blue, then just say that. Don't try to embellish or sell it by calling it "modern". That just invites ridicule, and it doesn't help anyone. ^ permalink raw reply [flat|nested] 96+ messages in thread
* A modern-mode? @ 2020-09-15 14:41 Andrea Corallo via Emacs development discussions. 2020-09-15 14:51 ` Ergus ` (5 more replies) 0 siblings, 6 replies; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-15 14:41 UTC (permalink / raw To: emacs-devel Hi all, following recent discussions I've started toying with what I've pushed on scratch/modern-mode. The (not so new) idea is to have a global minor mode to enable other code we already have in Emacs core to make Emacs a little more friendly/modern to new comers. IOW this is to enable some non excessively invasive features to help people getting into the Emacs universe. ATM this modern-mode enables: column-number-mode, delete-selection-mode, fido-mode, global-auto-revert-mode, show-paren-mode, winner-mode and windmove, plus is binding ibuffer to C-x C-b. Hopefully in the future we could enable something like fido vertical and which-key. I had a look but for now I gave-up on the idea of picking up a dark mode to enable as is not so easy. I've also made that this mode can be enabled at invocation time using '-m' '-modern' or '--modern' as I think it may be more accessible for new starters. I think would be good to have something like this in core and not in ELPA to ease people getting started without having to install anything. Feedback is welcome Thanks Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 14:41 Andrea Corallo via Emacs development discussions. @ 2020-09-15 14:51 ` Ergus 2020-09-16 0:16 ` Andrea Corallo via Emacs development discussions. 2020-09-15 15:08 ` Stefan Monnier ` (4 subsequent siblings) 5 siblings, 1 reply; 96+ messages in thread From: Ergus @ 2020-09-15 14:51 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel On Tue, Sep 15, 2020 at 02:41:07PM +0000, Andrea Corallo via Emacs development discussions. wrote: >Hi all, > >following recent discussions I've started toying with what I've pushed on >scratch/modern-mode. > >The (not so new) idea is to have a global minor mode to enable other >code we already have in Emacs core to make Emacs a little more >friendly/modern to new comers. IOW this is to enable some non >excessively invasive features to help people getting into the Emacs >universe. > >ATM this modern-mode enables: column-number-mode, delete-selection-mode, >fido-mode, global-auto-revert-mode, show-paren-mode, winner-mode and >windmove, plus is binding ibuffer to C-x C-b. > >Hopefully in the future we could enable something like fido vertical and >which-key. > >I had a look but for now I gave-up on the idea of picking up a dark mode >to enable as is not so easy. > >I've also made that this mode can be enabled at invocation time using >'-m' '-modern' or '--modern' as I think it may be more accessible for new >starters. > >I think would be good to have something like this in core and not in >ELPA to ease people getting started without having to install anything. > >Feedback is welcome > >Thanks > > Andrea > Hi Andrea: This is a very good thing!. BTW I have something similar (for my preferences of course) https://github.com/Ergus/mini_dotemacs Please feel free to take ideas from there as there are some configuration options I have discovered with the time. There are not any external package. Best, Ergus ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 14:51 ` Ergus @ 2020-09-16 0:16 ` Andrea Corallo via Emacs development discussions. 0 siblings, 0 replies; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 0:16 UTC (permalink / raw To: Ergus; +Cc: emacs-devel Ergus <spacibba@aol.com> writes: > Hi Andrea: > > This is a very good thing!. BTW I have something similar (for my > preferences of course) > > https://github.com/Ergus/mini_dotemacs > > Please feel free to take ideas from there as there are some > configuration options I have discovered with the time. There are not > any external package. Hi Ergus, thanks I'll certanly have a look. Thanks Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 14:41 Andrea Corallo via Emacs development discussions. 2020-09-15 14:51 ` Ergus @ 2020-09-15 15:08 ` Stefan Monnier 2020-09-15 15:26 ` Drew Adams ` (2 more replies) 2020-09-15 15:13 ` Drew Adams ` (3 subsequent siblings) 5 siblings, 3 replies; 96+ messages in thread From: Stefan Monnier @ 2020-09-15 15:08 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel Hi Andrea, Any chance you could turn it into a custom-theme? AFAIK most of your minor-mode could be turned into a theme fairly easily, so what I'm asking is for you try and do the extra work to cover the remaining non-trivial part (e.g. the key-bindings). Part of the difference between a minor mode and a custom theme is that a custom theme is more declarative, with consequences such as the fact that a user can enable your hypothetical "modern theme" but with `fido-mode` disabled, and it won't have the effect of "enabling and then disabling" `fido-mode` (e.g. running `fido-mode-hook` twice along the way). I'm mostly interested in pushing the limits of what can be done with custom themes, so try to keep an eye on what generic/infrastructure changes would make a "modern theme" easier to write cleanly. > I had a look but for now I gave-up on the idea of picking up a dark mode > to enable as is not so easy. I thought setting the foreground and the background of the `default` face is all it takes (it should change the frame-background-mode and thus cause all other faces to choose their dark-background alternative). What problem did you encounter? Stefan ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-15 15:08 ` Stefan Monnier @ 2020-09-15 15:26 ` Drew Adams 2020-09-15 16:34 ` Teemu Likonen 2020-09-15 18:36 ` Andrea Corallo via Emacs development discussions. 2 siblings, 0 replies; 96+ messages in thread From: Drew Adams @ 2020-09-15 15:26 UTC (permalink / raw To: Stefan Monnier, Andrea Corallo; +Cc: emacs-devel > Any chance you could turn it into a custom-theme? > Part of the difference between a minor mode and a custom theme is that > a custom theme is more declarative, with consequences such as the fact > that a user can enable your hypothetical "modern theme" but with > `fido-mode` disabled, and it won't have the effect of "enabling and then > disabling" `fido-mode` (e.g. running `fido-mode-hook` twice along the > way). I'm not sure a theme is better than a global minor mode. I agree that there should be easy ways for a user to choose what to turn on/off, including easy ways to add things to turn on/off that aren't included in whatever is provided by default. I'm no expert on themes or minor modes, but I think there's room for improvement of how to make such enablement easier and more discoverable. The minor mode approach sounds like a good one to me, as far as it goes. > I'm mostly interested in pushing the limits of what can be done with > custom themes The aim here should, I think, be to provide users with easy ways to: 1. Turn on(/off) a set of default settings that we generally think new users might appreciate. 2. Turn on(/off) individual settings in that set, i.e., to "customize/personalize" that set. 3. Add new settings to the default set, from wherever. An aim of "pushing the limits of custom themes", to see what can be done with them is something else. No doubt such an exploration could help with the aim of helping new users get into Emacs. But those two aims are not the same. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 15:08 ` Stefan Monnier 2020-09-15 15:26 ` Drew Adams @ 2020-09-15 16:34 ` Teemu Likonen 2020-09-15 18:36 ` Andrea Corallo via Emacs development discussions. 2 siblings, 0 replies; 96+ messages in thread From: Teemu Likonen @ 2020-09-15 16:34 UTC (permalink / raw To: Stefan Monnier, Andrea Corallo; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 669 bytes --] * 2020-09-15 11:08:53-04, Stefan Monnier wrote: > Any chance you could turn it into a custom-theme? Yes, themes please! > Part of the difference between a minor mode and a custom theme is that > a custom theme is more declarative, Minor modes are good for relatively narrow purpose but "modern" is a broad term which can have effect on various other minor modes, variables and faces. Themes are good for that because theme's individual minor modes, variables and faces can be overridden easily and themes work nicely with other themes. -- /// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 251 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 15:08 ` Stefan Monnier 2020-09-15 15:26 ` Drew Adams 2020-09-15 16:34 ` Teemu Likonen @ 2020-09-15 18:36 ` Andrea Corallo via Emacs development discussions. 2020-09-15 21:08 ` Antoine Kalmbach 2020-09-16 4:15 ` Teemu Likonen 2 siblings, 2 replies; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-15 18:36 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > Hi Andrea, > > Any chance you could turn it into a custom-theme? > > AFAIK most of your minor-mode could be turned into a theme fairly > easily, so what I'm asking is for you try and do the extra work to cover > the remaining non-trivial part (e.g. the key-bindings). > > Part of the difference between a minor mode and a custom theme is that > a custom theme is more declarative, with consequences such as the fact > that a user can enable your hypothetical "modern theme" but with > `fido-mode` disabled, and it won't have the effect of "enabling and then > disabling" `fido-mode` (e.g. running `fido-mode-hook` twice along the > way). Sounds like is what we want. Happy to have a look into this direction. > I'm mostly interested in pushing the limits of what can be done with > custom themes, so try to keep an eye on what generic/infrastructure > changes would make a "modern theme" easier to write cleanly. > >> I had a look but for now I gave-up on the idea of picking up a dark mode >> to enable as is not so easy. > > I thought setting the foreground and the background of the `default` > face is all it takes (it should change the frame-background-mode and > thus cause all other faces to choose their dark-background alternative). > What problem did you encounter? Sorry I wasn't clear, I was not referring to a technical difficulty. All I did was just having a look to the dark themes we have in Emacs core and could not find one that fully convinced me. Wombat and tango-dark are not bad but modus-vivendi has maybe the best set of colors, OTOH I think this last IMO has a little too much contrast (probably because focus on accessibility). One thing I noticed is that tool and scroll bar don't change color (I'm testing with GTK). If this an Emacs limitation is not very good as the aesthetic outcome with a dark theme IMO is not optimal (say pretty bad). That said I think this should enable some dark setting so I'll look into how to proceed (suggestions very welcome on this too :). Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 18:36 ` Andrea Corallo via Emacs development discussions. @ 2020-09-15 21:08 ` Antoine Kalmbach 2020-09-16 4:15 ` Teemu Likonen 1 sibling, 0 replies; 96+ messages in thread From: Antoine Kalmbach @ 2020-09-15 21:08 UTC (permalink / raw To: Andrea Corallo; +Cc: Stefan Monnier, emacs-devel Andrea Corallo <akrl@sdf.org> writes: > That said I think this should enable some dark setting so I'll look into > how to proceed (suggestions very welcome on this too :). I suspect that whether a "modern" theme should enable a dark/light theme by default is a point of contention. I think it would be better to either (a) split the theme into modern-light-theme / modern-dark-theme or even better (b) make the whole thing interactive on first use which would prompt/guide the user to select by their preference, not unlike a guided tour. -- Antoine Kalmbach ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 18:36 ` Andrea Corallo via Emacs development discussions. 2020-09-15 21:08 ` Antoine Kalmbach @ 2020-09-16 4:15 ` Teemu Likonen 2020-09-16 7:52 ` Andrea Corallo via Emacs development discussions. 1 sibling, 1 reply; 96+ messages in thread From: Teemu Likonen @ 2020-09-16 4:15 UTC (permalink / raw To: Andrea Corallo, Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 958 bytes --] * 2020-09-15 18:36:53Z, Andrea Corallo via wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Part of the difference between a minor mode and a custom theme is >> that a custom theme is more declarative, with consequences such as >> the fact that a user can enable your hypothetical "modern theme" but >> with `fido-mode` disabled, and it won't have the effect of "enabling >> and then disabling" `fido-mode` (e.g. running `fido-mode-hook` twice >> along the way). > > Sounds like is what we want. Happy to have a look into this direction. Also note that the whole "modernism" concept could be split into different themes. Then user could toggle them individually. Something like: modern-settings modern-keybindings modern-decorations modern-color-light modern-color-dark Or whatever. -- /// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 251 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 4:15 ` Teemu Likonen @ 2020-09-16 7:52 ` Andrea Corallo via Emacs development discussions. 0 siblings, 0 replies; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 7:52 UTC (permalink / raw To: Teemu Likonen; +Cc: Stefan Monnier, emacs-devel Teemu Likonen <tlikonen@iki.fi> writes: > Also note that the whole "modernism" concept could be split into > different themes. Then user could toggle them individually. Something > like: > > modern-settings > modern-keybindings > modern-decorations > modern-color-light > modern-color-dark > > Or whatever. Agree, I think once is rewritten in the suggested theme declarative way to have it splitted should come easy. That said I think key is that we provide a way to enable it as first with the less necessary tweaking as we can offer. Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-15 14:41 Andrea Corallo via Emacs development discussions. 2020-09-15 14:51 ` Ergus 2020-09-15 15:08 ` Stefan Monnier @ 2020-09-15 15:13 ` Drew Adams 2020-09-15 16:31 ` Theodor Thornhill 2020-09-15 15:56 ` Göktuğ Kayaalp ` (2 subsequent siblings) 5 siblings, 1 reply; 96+ messages in thread From: Drew Adams @ 2020-09-15 15:13 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel > have a global minor mode to enable other > code we already have in Emacs core to make Emacs a little more > friendly/modern to new comers. Such an approach is a good start - a good approach, I think. Then we can provide a tool-bar button or splash-screen link or some such prominent, early-and-obvious way(s) to turn it on/off. There may be some difficulty getting agreement on what should be there by default. It could be good for the mode to have an easy way for users to check off (opt in/out) things that they want included when the mode is enabled. `C-h m' for the mode (or other help for it) could present such a check list. The list could be like what the Options menu presents, but it could have more description and, where appropriate, links to Customize for relevant options etc. ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-15 15:13 ` Drew Adams @ 2020-09-15 16:31 ` Theodor Thornhill 0 siblings, 0 replies; 96+ messages in thread From: Theodor Thornhill @ 2020-09-15 16:31 UTC (permalink / raw To: Drew Adams, Andrea Corallo; +Cc: emacs-devel Drew Adams <drew.adams@oracle.com> writes: >> have a global minor mode to enable other >> code we already have in Emacs core to make Emacs a little more >> friendly/modern to new comers. [...] > > It could be good for the mode to have an easy way for > users to check off (opt in/out) things that they want > included when the mode is enabled. > Yeah, this is important. IMO the biggest problem with DOOM/Spacemacs is that it isn't really easy to declare .emacs bankrupcy and start over, since so much is convoluted inside the distribution. I'm afraid a mode such as this would only serve as some sort of "vendor lock-in", and make people rely too much on this, rather than creating their own, reading the docs and code etc. I think that when you are confused about something, emacs should guide you to the variable or function in question, and not hidden away in some mode. However, I still think this is a good idea. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 14:41 Andrea Corallo via Emacs development discussions. ` (2 preceding siblings ...) 2020-09-15 15:13 ` Drew Adams @ 2020-09-15 15:56 ` Göktuğ Kayaalp 2020-09-15 16:47 ` Gregory Heytings via Emacs development discussions. 2020-09-16 5:14 ` Alfred M. Szmidt 5 siblings, 0 replies; 96+ messages in thread From: Göktuğ Kayaalp @ 2020-09-15 15:56 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel On 2020-09-15 17:41 +03, Andrea Corallo via Emacs development discussions. <emacs-devel@gnu.org> wrote: > Hi all, > following recent discussions I've started toying with what I've pushed on > scratch/modern-mode. > > The (not so new) idea is to have a global minor mode to enable other > code we already have in Emacs core to make Emacs a little more > friendly/modern to new comers. IOW this is to enable some non > excessively invasive features to help people getting into the Emacs > universe. IMHO this is the best way to go forward. What’s inside it could be fine tuned until 28 release, and then a checkbox or a link can introduce it in the splash screen. IMHO we could look at Emacs distributions for inspirations regarding what to have in this mode. P.S. maybe we’re missing the chance to include a terrible pun not calling this ‘a-la-mode’? (that’s not serious at all, of course) -- İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/> pgp: 024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 14:41 Andrea Corallo via Emacs development discussions. ` (3 preceding siblings ...) 2020-09-15 15:56 ` Göktuğ Kayaalp @ 2020-09-15 16:47 ` Gregory Heytings via Emacs development discussions. [not found] ` <a4bc94ca-3130-463a-bd79-3dbffbbce492@default> 2020-09-15 18:47 ` Andrea Corallo via Emacs development discussions. 2020-09-16 5:14 ` Alfred M. Szmidt 5 siblings, 2 replies; 96+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-09-15 16:47 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel Hi Andrea, > > following recent discussions I've started toying with what I've pushed > on scratch/modern-mode. > > The (not so new) idea is to have a global minor mode to enable other > code we already have in Emacs core to make Emacs a little more > friendly/modern to new comers. IOW this is to enable some non > excessively invasive features to help people getting into the Emacs > universe. > > ATM this modern-mode enables: column-number-mode, delete-selection-mode, > fido-mode, global-auto-revert-mode, show-paren-mode, winner-mode and > windmove, plus is binding ibuffer to C-x C-b. > [...] > > Feedback is welcome > I'm biased, but I do not think this is better than the guided tour / interactive guide proposal that Yuan Fu and me sent a few days ago. The problem of "modern-mode" is that, as the traffic on this list during the last days has shown, different people have different ideas of what "modern" is, and might want to turn each feature on or off. Some might want a dark theme and others not, some might want tabs and others not, and so forth. So it is better to give something more refined than a binary modern/non-modern choice. Moreover the guided tour proposal introduces the most important concepts of Emacs, and explains how to find help, which I believe is very important if the point is the help people getting (and staying!) into the Emacs universe. ^ permalink raw reply [flat|nested] 96+ messages in thread
[parent not found: <a4bc94ca-3130-463a-bd79-3dbffbbce492@default>]
* RE: A modern-mode? [not found] ` <a4bc94ca-3130-463a-bd79-3dbffbbce492@default> @ 2020-09-15 17:11 ` Gregory Heytings via Emacs development discussions. 2020-09-15 17:32 ` Drew Adams 2020-09-15 17:35 ` Drew Adams 0 siblings, 2 replies; 96+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-09-15 17:11 UTC (permalink / raw To: Drew Adams; +Cc: Andrea Corallo, emacs-devel >> I'm biased, but I do not think this is better than the guided tour / >> interactive guide proposal that Yuan Fu and me sent a few days ago. > >> Moreover the guided tour proposal introduces the most important >> concepts of Emacs, and explains how to find help, which I believe is >> very important if the point is the help people getting (and staying!) >> into the Emacs universe. > > A tour is different from a button to get a set of features. > Did you have a look at the proposal? I realize that there has been so much traffic here that you may have missed it. It combines the two aspects: buttons to set a number of features that newcomers might want to turn on, and explanations to guide their first steps. Your feedback would be most welcome. ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-15 17:11 ` Gregory Heytings via Emacs development discussions. @ 2020-09-15 17:32 ` Drew Adams 2020-09-15 17:35 ` Drew Adams 1 sibling, 0 replies; 96+ messages in thread From: Drew Adams @ 2020-09-15 17:32 UTC (permalink / raw To: Gregory Heytings; +Cc: emacs-devel, Andrea Corallo > >> I'm biased, but I do not think this is better than the guided tour / > >> interactive guide proposal that Yuan Fu and me sent a few days ago. > > > >> Moreover the guided tour proposal introduces the most important > >> concepts of Emacs, and explains how to find help, which I believe is > >> very important if the point is the help people getting (and staying!) > >> into the Emacs universe. > > > > A tour is different from a button to get a set of features. > > Did you have a look at the proposal? I realize that there has been so > much traffic here that you may have missed it. It combines the two > aspects: buttons to set a number of features that newcomers might want to > turn on, and explanations to guide their first steps. Your feedback would > be most welcome. A tour with ability to choose stuff on the fly is still different from a mode for a set of settings and an interface to "customize" or add to those settings. IMO. The latter lets you turn the mode on/off anytime. And it lets you "customize" it anytime. Those things are not mixed in with following a tour. Letting a tour give you one way to "customize" such a mode would be fine. But you shouldn't need to go through a tour to do that. IOW, they're related, but not the same, I think. ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-15 17:11 ` Gregory Heytings via Emacs development discussions. 2020-09-15 17:32 ` Drew Adams @ 2020-09-15 17:35 ` Drew Adams 1 sibling, 0 replies; 96+ messages in thread From: Drew Adams @ 2020-09-15 17:35 UTC (permalink / raw To: Gregory Heytings; +Cc: emacs-devel, Andrea Corallo > > > A tour is different from a button to get a set of features. > > > > Did you have a look at the proposal? You yourself agreed they are not the same thing: > I do not think this is better than the guided > tour / interactive guide proposal Your point in saying that was presumably not to claim that they are the same but that one is better than the other. My point was that they have different purposes, with some overlap. They are not the same thing. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 16:47 ` Gregory Heytings via Emacs development discussions. [not found] ` <a4bc94ca-3130-463a-bd79-3dbffbbce492@default> @ 2020-09-15 18:47 ` Andrea Corallo via Emacs development discussions. 2020-09-15 20:48 ` Gregory Heytings via Emacs development discussions. 1 sibling, 1 reply; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-15 18:47 UTC (permalink / raw To: Gregory Heytings; +Cc: emacs-devel Gregory Heytings <ghe@sdf.org> writes: > I'm biased, but I do not think this is better than the guided tour / > interactive guide proposal that Yuan Fu and me sent a few days ago. > > The problem of "modern-mode" is that, as the traffic on this list > during the last days has shown, different people have different ideas > of what "modern" is, and might want to turn each feature on or off. > Some might want a dark theme and others not, some might want tabs and > others not, and so forth. So it is better to give something more > refined than a binary modern/non-modern choice. > > Moreover the guided tour proposal introduces the most important > concepts of Emacs, and explains how to find help, which I believe is > very important if the point is the help people getting (and staying!) > into the Emacs universe. Hi Gregory, I agree with Drew that these are two different (IMO interesting) features. If (as suggested) the modern-mode becomes a modern-theme this is effectively like a new set of defaults that can be easily toggled, and if the user wants later on refined and re-configured. I hope to see both features coming to fruition as they are not exclusive. Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 18:47 ` Andrea Corallo via Emacs development discussions. @ 2020-09-15 20:48 ` Gregory Heytings via Emacs development discussions. 2020-09-16 0:07 ` Andrea Corallo via Emacs development discussions. 0 siblings, 1 reply; 96+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-09-15 20:48 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel > > If (as suggested) the modern-mode becomes a modern-theme this is > effectively like a new set of defaults that can be easily toggled, and > if the user wants later on refined and re-configured. > I see what you mean, but I do not see how this would help newcomers. It would be one set of defaults, and many will come with another set of defaults that they would also like to call "modern-mode" (or "postmodern-mode" or "futuristic-mode" or "postfuturistic-mode" or ...). This would result in the long term in a large set of "profiles", each with a number of unrelated defaults modified, in which a new user would be lost. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 20:48 ` Gregory Heytings via Emacs development discussions. @ 2020-09-16 0:07 ` Andrea Corallo via Emacs development discussions. 2020-09-16 8:58 ` Gregory Heytings via Emacs development discussions. 0 siblings, 1 reply; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 0:07 UTC (permalink / raw To: Gregory Heytings; +Cc: emacs-devel Gregory Heytings <ghe@sdf.org> writes: > I see what you mean, but I do not see how this would help newcomers. I think one easily accessible ready to go set of more modern/friendly defaults can help new users getting started. I'm convinced new comers should ideally do *nothing* to have a more friendly system to begin with, if this is not possible hopefully something easy as typing '-m' is the closest. If you think a guided tour to go through is more effective, well you are very much entitled to. I don't think this is sufficiently immediate for many cases but I think can be useful for others. Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 0:07 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 8:58 ` Gregory Heytings via Emacs development discussions. 2020-09-16 9:03 ` Dmitry Gutov ` (2 more replies) 0 siblings, 3 replies; 96+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-09-16 8:58 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel >> I see what you mean, but I do not see how this would help newcomers. > > I think one easily accessible ready to go set of more modern/friendly > defaults can help new users getting started. > The problem is that Emacs developers would have to agree on what that set of "more modern / friendly defaults" is, which is unlikely to happen. Again, different people have (very!) different ideas of what "modern / friendly" is. A few examples, in the defaults you suggested: - fido-mode: in another thread Eli explained that in his opinion icomplete's behavior is not intuitive enough for newcomers, and I (and probably others) agree with what he said - global-auto-revert-mode: I would strongly object to this, having your editor doing something without asking you for a confirmation is not something many newcomers would find intuitive - winner-mode: I don't understand why you would turn this on, IMO having C-c <left> and C-c <right> to undo window changes is useless for a newcomer, and C-c <left> / <right> is not a keybinding they can guess by themselves. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 8:58 ` Gregory Heytings via Emacs development discussions. @ 2020-09-16 9:03 ` Dmitry Gutov 2020-09-16 10:39 ` Göktuğ Kayaalp 2020-09-16 12:20 ` Arthur Miller 2 siblings, 0 replies; 96+ messages in thread From: Dmitry Gutov @ 2020-09-16 9:03 UTC (permalink / raw To: Gregory Heytings, Andrea Corallo; +Cc: emacs-devel On 16.09.2020 11:58, Gregory Heytings via Emacs development discussions. wrote: > The problem is that Emacs developers would have to agree on what that > set of "more modern / friendly defaults" is, which is unlikely to > happen. Again, different people have (very!) different ideas of what > "modern / friendly" is. Cue several more weeks of discussions. > A few examples, in the defaults you suggested: > > - fido-mode: in another thread Eli explained that in his opinion > icomplete's behavior is not intuitive enough for newcomers, and I (and > probably others) agree with what he said It's more intuitive than the absence of any completion hints, which is the current default. We can swap it for a different system when one is available. > - global-auto-revert-mode: I would strongly object to this, having your > editor doing something without asking you for a confirmation is not > something many newcomers would find intuitive It's a feature of many other "modern" editors. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 8:58 ` Gregory Heytings via Emacs development discussions. 2020-09-16 9:03 ` Dmitry Gutov @ 2020-09-16 10:39 ` Göktuğ Kayaalp 2020-09-16 10:47 ` João Távora 2020-09-16 12:20 ` Arthur Miller 2 siblings, 1 reply; 96+ messages in thread From: Göktuğ Kayaalp @ 2020-09-16 10:39 UTC (permalink / raw To: Gregory Heytings; +Cc: emacs-devel, Andrea Corallo On 2020-09-16 11:58 +03, Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> wrote: > The problem is that Emacs developers would have to agree on what that > set of "more modern / friendly defaults" is, which is unlikely to > happen. Again, different people have (very!) different ideas of what > "modern / friendly" is. If we’re trying to make Emacs friendlier for newcomers, I doubt it’s Emacs developers who need to agree, but the software that they use as a proxy to their preferences. And given such agreement exists when you compare the feature set of these programs, there’s not much room for debate here actually. > - fido-mode: in another thread Eli explained that in his opinion > icomplete's behavior is not intuitive enough for newcomers, and I > (and probably others) agree with what he said Could be made more intuitive via customisation within the mode. > - global-auto-revert-mode: I would strongly object to this, having > your editor doing something without asking you for a confirmation is > not something many newcomers would find intuitive This is what _all_ these editors do so while maybe you (and I, too) don’t find it intuitive, that other people do find it intuitive is kinda obvious. > - winner-mode: I don't understand why you would turn this on, IMO > having C-c <left> and C-c <right> to undo window changes is useless > for a newcomer, and C-c <left> / <right> is not a keybinding they > can guess by themselves. And in that case they just use the mouse until they feel like they can do better. We could also incorporate a cheat sheet that organises things a bit more better than C-h m. But ultimately the beauty of Andrea’s approach is that we can just put random things in there, write EXPERIMENTAL in all caps in the docstring, and refine until 28. What we initially put in there is not all that important. to be honest. -- İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/> pgp: 024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 10:39 ` Göktuğ Kayaalp @ 2020-09-16 10:47 ` João Távora 0 siblings, 0 replies; 96+ messages in thread From: João Távora @ 2020-09-16 10:47 UTC (permalink / raw To: Göktuğ Kayaalp; +Cc: Gregory Heytings, Andrea Corallo, emacs-devel [-- Attachment #1: Type: text/plain, Size: 879 bytes --] On Wed, Sep 16, 2020 at 11:39 AM Göktuğ Kayaalp <self@gkayaalp.com> wrote: But ultimately the beauty of Andrea’s approach is that we can just put > random things in there, write EXPERIMENTAL in all caps in the docstring, > and refine until 28. What we initially put in there is not all that > important. to be honest. > I don't agree with this. We should not throw "random things" in there because that will affect the possibility that Andrea's customization can be composed with Joe Doe's, whose contribution I would also welcome. If we follow your plan, it seems very likely that a sub-battle for defaults emerges within it. So, no to "random". Only things that our "custom-theme" infrastructure knows how to handle. If it doesn't handle some of those, then either that infrastructure or a package's custom.el conformance should be augmented. João [-- Attachment #2: Type: text/html, Size: 1438 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 8:58 ` Gregory Heytings via Emacs development discussions. 2020-09-16 9:03 ` Dmitry Gutov 2020-09-16 10:39 ` Göktuğ Kayaalp @ 2020-09-16 12:20 ` Arthur Miller 2 siblings, 0 replies; 96+ messages in thread From: Arthur Miller @ 2020-09-16 12:20 UTC (permalink / raw To: Gregory Heytings via Emacs development discussions. Cc: Gregory Heytings, Andrea Corallo Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> writes: > - winner-mode: I don't understand why you would turn this on, IMO having C-c > <left> and C-c <right> to undo window changes is useless for a newcomer, and > C-c <left> / <right> is not a keybinding they can guess by themselves. C-c <...> is not something anyone could guess; and for newcomers to Emacs probably any kyeboard shortcut would be hard or impossible to guess. Reason being probably because not much other software have undo stack for guit layut. But that shouldn't be reason not to enable winner mode. Winner mode is usefull and there is probably no reason not to enable it in main Emacs. I would probably also include ace-window and enable it by default. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-15 14:41 Andrea Corallo via Emacs development discussions. ` (4 preceding siblings ...) 2020-09-15 16:47 ` Gregory Heytings via Emacs development discussions. @ 2020-09-16 5:14 ` Alfred M. Szmidt 2020-09-16 7:27 ` Andrea Corallo via Emacs development discussions. ` (2 more replies) 5 siblings, 3 replies; 96+ messages in thread From: Alfred M. Szmidt @ 2020-09-16 5:14 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel following recent discussions I've started toying with what I've pushed on scratch/modern-mode. What some find modern, some will find old. What some find old, some will find modern. What was once modern will become old again, and what was old again will become modern. A different name would be more appropriate. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 5:14 ` Alfred M. Szmidt @ 2020-09-16 7:27 ` Andrea Corallo via Emacs development discussions. 2020-09-16 7:36 ` Alfred M. Szmidt 2020-09-16 8:15 ` Ergus 2020-09-16 7:33 ` Robert Pluim 2020-09-16 9:36 ` João Távora 2 siblings, 2 replies; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 7:27 UTC (permalink / raw To: Alfred M. Szmidt; +Cc: emacs-devel ams@gnu.org (Alfred M. Szmidt) writes: > What was once modern will become old again, and what was old again > will become modern. One important aspect of this collection of settings is that we should be less committed to (eternal :) immutability as we are for normal defaults. As this is meant to be an help for new starters we should feel free to improve these from release to release without a negative impact on old new starters, as by definition they are not anymore new starters :) IOW If they stayed around for more than a release cycle quite certainly they have learned how to personalize Emacs themselves. Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 7:27 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 7:36 ` Alfred M. Szmidt 2020-09-16 8:36 ` Alan Third ` (2 more replies) 2020-09-16 8:15 ` Ergus 1 sibling, 3 replies; 96+ messages in thread From: Alfred M. Szmidt @ 2020-09-16 7:36 UTC (permalink / raw To: Andrea Corallo; +Cc: emacs-devel The word modern has a negative meaning in that it implies that the rest of Emacs isn't modern -- why would users ever want to switch of "modern-mode" and use the un-modern Emacs? As this is meant to be an help for new starters we should feel free to improve these from release to release without a negative impact on old new starters, as by definition they are not anymore new starters :) ever-changing-mode? :) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 7:36 ` Alfred M. Szmidt @ 2020-09-16 8:36 ` Alan Third 2020-09-16 14:37 ` Drew Adams 2020-09-17 3:54 ` Richard Stallman 2020-09-16 10:30 ` Göktuğ Kayaalp 2020-09-17 3:53 ` Richard Stallman 2 siblings, 2 replies; 96+ messages in thread From: Alan Third @ 2020-09-16 8:36 UTC (permalink / raw To: Alfred M. Szmidt; +Cc: emacs-devel, Andrea Corallo On Wed, Sep 16, 2020 at 03:36:12AM -0400, Alfred M. Szmidt wrote: > The word modern has a negative meaning in that it implies that the > rest of Emacs isn't modern -- why would users ever want to switch of > "modern-mode" and use the un-modern Emacs? Easy-mode as opposed to expert, obviously. ;) Starter-mode Familiar-mode Familiar-defaults-easy-start-mode? ;) -- Alan Third ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-16 8:36 ` Alan Third @ 2020-09-16 14:37 ` Drew Adams 2020-09-16 15:00 ` Arthur Miller 2020-09-17 3:54 ` Richard Stallman 1 sibling, 1 reply; 96+ messages in thread From: Drew Adams @ 2020-09-16 14:37 UTC (permalink / raw To: Alan Third, Alfred M. Szmidt; +Cc: Andrea Corallo, emacs-devel > Easy-mode as opposed to expert, obviously. ;) > Starter-mode > Familiar-mode > Familiar-defaults-easy-start-mode? ;) newbie-mode ___________ Someone who's a newbie and sees "Newbie" can think (at least) two things: 1. It's easy, intended for newbies, so maybe it's for me, at least for now. 2. Maybe it's something I might want to grow out of. It's maybe not the "real" or "full" thing. There's more to Emacs than this mode. #1 can encourage a newbie, especially if timid, to try it. #2 can encourage someone to move beyond it, and discover and use more of Emacs. The Emacs Wiki has long had pages that aimed especially at newbies, and referred to as such. They've helped a lot of people, and I've never seen a negative reaction to use of the term "newbie". This is like "training wheels" for someone learning to ride a bike. You trust them, use them to help you get going, but you want to get to a point where you can really ride without them. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 14:37 ` Drew Adams @ 2020-09-16 15:00 ` Arthur Miller 2020-09-16 15:22 ` Thibaut Verron 0 siblings, 1 reply; 96+ messages in thread From: Arthur Miller @ 2020-09-16 15:00 UTC (permalink / raw To: Drew Adams; +Cc: Alan Third, emacs-devel, Alfred M. Szmidt, Andrea Corallo Drew Adams <drew.adams@oracle.com> writes: >> Easy-mode as opposed to expert, obviously. ;) >> Starter-mode >> Familiar-mode >> Familiar-defaults-easy-start-mode? ;) > > > newbie-mode > ___________ > > Someone who's a newbie and sees "Newbie" > can think (at least) two things: > > 1. It's easy, intended for newbies, so maybe > it's for me, at least for now. > > 2. Maybe it's something I might want to grow > out of. It's maybe not the "real" or "full" > thing. There's more to Emacs than this mode. > > #1 can encourage a newbie, especially if timid, > to try it. > > #2 can encourage someone to move beyond it, and > discover and use more of Emacs. > > The Emacs Wiki has long had pages that aimed > especially at newbies, and referred to as such. > They've helped a lot of people, and I've never > seen a negative reaction to use of the term > "newbie". > > This is like "training wheels" for someone > learning to ride a bike. You trust them, use > them to help you get going, but you want to > get to a point where you can really ride > without them. And then you will see threads on Reddit & elswhere asking when it is appropriate to switch to "true Emacs mode"; should I learn this and then switch to Emacs original etc; just as there already are such threads considerinv Evil & Emacs interaction models. Newbie-mode and numacs are bad names, in my opinion. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:00 ` Arthur Miller @ 2020-09-16 15:22 ` Thibaut Verron 0 siblings, 0 replies; 96+ messages in thread From: Thibaut Verron @ 2020-09-16 15:22 UTC (permalink / raw To: Arthur Miller Cc: Alan Third, Andrea Corallo, Alfred M. Szmidt, Drew Adams, emacs-devel > And then you will see threads on Reddit & elswhere asking when it is > appropriate to switch to "true Emacs mode"; should I learn this and then > switch to Emacs original etc; just as there already are such threads > considerinv Evil & Emacs interaction models. > > Newbie-mode and numacs are bad names, in my opinion. I tend to agree. Some (most?) of the suggested options do not need to be grown out of. Some are even already activated by default. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 8:36 ` Alan Third 2020-09-16 14:37 ` Drew Adams @ 2020-09-17 3:54 ` Richard Stallman 1 sibling, 0 replies; 96+ messages in thread From: Richard Stallman @ 2020-09-17 3:54 UTC (permalink / raw To: Alan Third; +Cc: alan, emacs-devel, ams, akrl [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Easy-mode as opposed to expert, obviously. ;) > Starter-mode > Familiar-mode > Familiar-defaults-easy-start-mode? ;) Like Other Editors mode? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 7:36 ` Alfred M. Szmidt 2020-09-16 8:36 ` Alan Third @ 2020-09-16 10:30 ` Göktuğ Kayaalp 2020-09-16 11:17 ` Alfred M. Szmidt 2020-09-16 18:19 ` Daniel Martín 2020-09-17 3:53 ` Richard Stallman 2 siblings, 2 replies; 96+ messages in thread From: Göktuğ Kayaalp @ 2020-09-16 10:30 UTC (permalink / raw To: emacs-devel; +Cc: Andrea Corallo On 2020-09-16 10:36 +03, Alfred M. Szmidt <ams@gnu.org> wrote: > The word modern has a negative meaning in that it implies that the > rest of Emacs isn't modern -- why would users ever want to switch of > "modern-mode" and use the un-modern Emacs? IMHO reading too much into names is not productive. ‘Modern’ is a term that’s used fairly often in this context, and what to expect would be obvious to those who would want to use such a mode: features common to contemporary text editors. What features to put in there could slowly brew until 28 is released. There’s no harm in starting out with Andrea’s opinions and slowly refining it with feedback from within and from without. But if we keep yak shaving over names and particularities we won’t have anything to refine. And we’ve already doubled the traffic of Sep 2019... -- İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/> pgp: 024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 10:30 ` Göktuğ Kayaalp @ 2020-09-16 11:17 ` Alfred M. Szmidt 2020-09-16 14:32 ` Eli Zaretskii 2020-09-16 18:19 ` Daniel Martín 1 sibling, 1 reply; 96+ messages in thread From: Alfred M. Szmidt @ 2020-09-16 11:17 UTC (permalink / raw Cc: akrl, emacs-devel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 970 bytes --] On 2020-09-16 10:36 +03, Alfred M. Szmidt <ams@gnu.org> wrote: > The word modern has a negative meaning in that it implies that the > rest of Emacs isn't modern -- why would users ever want to switch of > "modern-mode" and use the un-modern Emacs? IMHO reading too much into names is not productive. ‘Modern’ is a term that’s used fairly often in this context, and what to expect would be obvious to those who would want to use such a mode: features common to contemporary text editors. Names mean things and in this discussion it was because Emacs was seen as old (i.e., un-modern), a new user would be curious why modern-mode isn't the default. And as the discussion has showed, there is no agreement what people think is modern. So it would be simply better to avoid the term "modern" completely. What features to put in there could slowly brew until 28 is released. Why not slowly brew those and make them default instead? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 11:17 ` Alfred M. Szmidt @ 2020-09-16 14:32 ` Eli Zaretskii 2020-09-16 14:46 ` Andrea Corallo via Emacs development discussions. ` (3 more replies) 0 siblings, 4 replies; 96+ messages in thread From: Eli Zaretskii @ 2020-09-16 14:32 UTC (permalink / raw To: Alfred M. Szmidt; +Cc: self, emacs-devel, akrl > From: ams@gnu.org (Alfred M. Szmidt) > Date: Wed, 16 Sep 2020 07:17:08 -0400 > Cc: akrl@sdf.org, emacs-devel@gnu.org > > > On 2020-09-16 10:36 +03, Alfred M. Szmidt <ams@gnu.org> wrote: > > The word modern has a negative meaning in that it implies that the > > rest of Emacs isn't modern -- why would users ever want to switch of > > "modern-mode" and use the un-modern Emacs? > > IMHO reading too much into names is not productive. ‘Modern’ is a term > that’s used fairly often in this context, and what to expect would be > obvious to those who would want to use such a mode: features common to > contemporary text editors. > > Names mean things and in this discussion it was because Emacs was seen > as old (i.e., un-modern), a new user would be curious why modern-mode > isn't the default. And as the discussion has showed, there is no > agreement what people think is modern. So it would be simply better > to avoid the term "modern" completely. Yes, let's find a different name for this. I'd object to calling it "modern", because I disagree that vanilla Emacs isn't. newcomer-friendly-mode? new-to-emacs-mode? numacs-mode? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 14:32 ` Eli Zaretskii @ 2020-09-16 14:46 ` Andrea Corallo via Emacs development discussions. 2020-09-16 21:53 ` Dmitry Gutov 2020-09-16 15:18 ` Lars Ingebrigtsen ` (2 subsequent siblings) 3 siblings, 1 reply; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 14:46 UTC (permalink / raw To: Eli Zaretskii; +Cc: Alfred M. Szmidt, self, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > newcomer-friendly-mode? new-to-emacs-mode? numacs-mode? I like numacs-mode! ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 14:46 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 21:53 ` Dmitry Gutov 0 siblings, 0 replies; 96+ messages in thread From: Dmitry Gutov @ 2020-09-16 21:53 UTC (permalink / raw To: Andrea Corallo, Eli Zaretskii; +Cc: self, Alfred M. Szmidt, emacs-devel On 16.09.2020 17:46, Andrea Corallo via Emacs development discussions. wrote: > I like numacs-mode! I do too. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 14:32 ` Eli Zaretskii 2020-09-16 14:46 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 15:18 ` Lars Ingebrigtsen 2020-09-16 15:33 ` Andrea Corallo via Emacs development discussions. ` (2 more replies) 2020-09-16 15:18 ` Alfred M. Szmidt 2020-09-16 16:45 ` tomas 3 siblings, 3 replies; 96+ messages in thread From: Lars Ingebrigtsen @ 2020-09-16 15:18 UTC (permalink / raw To: Eli Zaretskii; +Cc: self, Alfred M. Szmidt, akrl, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Yes, let's find a different name for this. I'd object to calling it > "modern", because I disagree that vanilla Emacs isn't. I think "modern" implies that one day it won't be modern any more, so it's a fine name by me. But perhaps it should be more specific: `modern-2020-mode'. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:18 ` Lars Ingebrigtsen @ 2020-09-16 15:33 ` Andrea Corallo via Emacs development discussions. 2020-09-16 15:46 ` Eli Zaretskii 2020-09-16 21:54 ` Dmitry Gutov 2 siblings, 0 replies; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 15:33 UTC (permalink / raw To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, self, Alfred M. Szmidt, emacs-devel Lars Ingebrigtsen <larsi@gnus.org> writes: > I think "modern" implies that one day it won't be modern any more, so > it's a fine name by me. But perhaps it should be more specific: > `modern-2020-mode'. Hi Lars, your idea for the name is nice :) The other option I suggested is that we do not commit to retrocompatibility from release to release on this collection of settings. Hopefully users learn how to configure Emacs after sticking around for a while. Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:18 ` Lars Ingebrigtsen 2020-09-16 15:33 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 15:46 ` Eli Zaretskii 2020-09-16 15:54 ` Andrea Corallo via Emacs development discussions. 2020-09-16 21:54 ` Dmitry Gutov 2 siblings, 1 reply; 96+ messages in thread From: Eli Zaretskii @ 2020-09-16 15:46 UTC (permalink / raw To: Lars Ingebrigtsen; +Cc: self, ams, emacs-devel, akrl > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Wed, 16 Sep 2020 17:18:01 +0200 > Cc: self@gkayaalp.com, "Alfred M. Szmidt" <ams@gnu.org>, akrl@sdf.org, > emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > > Yes, let's find a different name for this. I'd object to calling it > > "modern", because I disagree that vanilla Emacs isn't. > > I think "modern" implies that one day it won't be modern any more, so > it's a fine name by me. But perhaps it should be more specific: > `modern-2020-mode'. I'm okay with that if we drop the "modern" part. How about emacs-2021-mode? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:46 ` Eli Zaretskii @ 2020-09-16 15:54 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:08 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 15:54 UTC (permalink / raw To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, self, ams, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Lars Ingebrigtsen <larsi@gnus.org> >> Date: Wed, 16 Sep 2020 17:18:01 +0200 >> Cc: self@gkayaalp.com, "Alfred M. Szmidt" <ams@gnu.org>, akrl@sdf.org, >> emacs-devel@gnu.org >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > Yes, let's find a different name for this. I'd object to calling it >> > "modern", because I disagree that vanilla Emacs isn't. >> >> I think "modern" implies that one day it won't be modern any more, so >> it's a fine name by me. But perhaps it should be more specific: >> `modern-2020-mode'. > > I'm okay with that if we drop the "modern" part. How about > emacs-2021-mode? I like this one too :) But would still be possible to have it enabled with a command line option? I mean if every new release we have a new version of this mode (theme?) either we loose this ability or we have the command line option binded to the most recent one. Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:54 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 16:08 ` Eli Zaretskii 2020-09-16 16:17 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:30 ` Alan Third 2020-09-16 16:45 ` Alfred M. Szmidt 2 siblings, 1 reply; 96+ messages in thread From: Eli Zaretskii @ 2020-09-16 16:08 UTC (permalink / raw To: Andrea Corallo; +Cc: self, larsi, ams, emacs-devel > From: Andrea Corallo <akrl@sdf.org> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, self@gkayaalp.com, ams@gnu.org, > emacs-devel@gnu.org > Date: Wed, 16 Sep 2020 15:54:28 +0000 > > > I'm okay with that if we drop the "modern" part. How about > > emacs-2021-mode? > > I like this one too :) But would still be possible to have it enabled > with a command line option? I mean if every new release we have a new > version of this mode (theme?) either we loose this ability or we have > the command line option binded to the most recent one. The usual way of solving this is to turn it on in your .emacs. Why does it have to be a command-line option (that isn't --eval)? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 16:08 ` Eli Zaretskii @ 2020-09-16 16:17 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:28 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 16:17 UTC (permalink / raw To: Eli Zaretskii; +Cc: larsi, self, ams, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > The usual way of solving this is to turn it on in your .emacs. > > Why does it have to be a command-line option (that isn't --eval)? I imagine myself in the condition of giving a suggestion to a colleague for trying out Emacs. It's very easy to suggest like '-m'. IMO it is already considerably more complex to start explaining --eval... or the .emacs equivalent. And I'm thinking to a colleague, if I think to someone less computer skilled it's even worst. Yes I know may sounds strange I believe this is a first barrier. Andrea ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 16:17 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 16:28 ` Eli Zaretskii 2020-09-16 16:32 ` Noam Postavsky 2020-09-16 16:45 ` Alfred M. Szmidt 2 siblings, 0 replies; 96+ messages in thread From: Eli Zaretskii @ 2020-09-16 16:28 UTC (permalink / raw To: Andrea Corallo; +Cc: self, larsi, ams, emacs-devel > From: Andrea Corallo <akrl@sdf.org> > Cc: larsi@gnus.org, self@gkayaalp.com, ams@gnu.org, emacs-devel@gnu.org > Date: Wed, 16 Sep 2020 16:17:03 +0000 > > > Why does it have to be a command-line option (that isn't --eval)? > > I imagine myself in the condition of giving a suggestion to a colleague > for trying out Emacs. It's very easy to suggest like '-m'. IMO it is > already considerably more complex to start explaining --eval... or the > .emacs equivalent. And I'm thinking to a colleague, if I think to > someone less computer skilled it's even worst. You don't need to explain anything, just create a .emacs file for them with that one line. This is what I do in such cases. The advantage is that the users don't need to remember any switches, and can invoke Emacs from their desktop icons. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 16:17 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:28 ` Eli Zaretskii @ 2020-09-16 16:32 ` Noam Postavsky 2020-09-16 16:45 ` Alfred M. Szmidt 2 siblings, 0 replies; 96+ messages in thread From: Noam Postavsky @ 2020-09-16 16:32 UTC (permalink / raw To: Andrea Corallo Cc: Göktuğ Kayaalp, Eli Zaretskii, Emacs developers, Lars Magne Ingebrigtsen, ams On Wed, 16 Sep 2020 at 12:17, Andrea Corallo via Emacs development discussions. <emacs-devel@gnu.org> wrote: > I imagine myself in the condition of giving a suggestion to a colleague > for trying out Emacs. It's very easy to suggest like '-m'. IMO it is > already considerably more complex to start explaining --eval... or the You could use --funcall (or the short from -f), as in: '-f emacs-2021-mode'. This gets around the potential difficulties of escaping parens that --eval has. I don't think much explanation should be needed. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 16:17 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:28 ` Eli Zaretskii 2020-09-16 16:32 ` Noam Postavsky @ 2020-09-16 16:45 ` Alfred M. Szmidt 2 siblings, 0 replies; 96+ messages in thread From: Alfred M. Szmidt @ 2020-09-16 16:45 UTC (permalink / raw To: Andrea Corallo; +Cc: self, eliz, larsi, emacs-devel > The usual way of solving this is to turn it on in your .emacs. > > Why does it have to be a command-line option (that isn't --eval)? I imagine myself in the condition of giving a suggestion to a colleague for trying out Emacs. It's very easy to suggest like '-m'. IMO it is already considerably more complex to start explaining --eval... or the .emacs equivalent. And I'm thinking to a colleague, if I think to someone less computer skilled it's even worst. Yes I know may sounds strange I believe this is a first barrier. Most users would just click on an icon to start emacs, I doubt that they would fire up a terminal and then do emacs --help and find a -m option. It would be either that, or guidance from someone to suggest to use -m -- then one might as well teach them plain Emacs which isn't hard. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:54 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:08 ` Eli Zaretskii @ 2020-09-16 16:30 ` Alan Third 2020-09-16 16:45 ` Alfred M. Szmidt 2 siblings, 0 replies; 96+ messages in thread From: Alan Third @ 2020-09-16 16:30 UTC (permalink / raw To: Andrea Corallo; +Cc: self, Eli Zaretskii, emacs-devel, Lars Ingebrigtsen, ams On Wed, Sep 16, 2020 at 03:54:28PM +0000, Andrea Corallo via Emacs development discussions. wrote: > Eli Zaretskii <eliz@gnu.org> writes: > > > I'm okay with that if we drop the "modern" part. How about > > emacs-2021-mode? > > I like this one too :) But would still be possible to have it enabled > with a command line option? I mean if every new release we have a new > version of this mode (theme?) either we loose this ability or we have > the command line option binded to the most recent one. Easy, make it "emacs -2021", then in a few years when we decide that's no longer modern looking we can add "emacs -2023", and so on forever. ;) Personally I dislike the idea of turning it on with a command line option, I'd rather we just give them a customize option linked from the splash screen or whatever, merging two competing proposals. -- Alan Third ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:54 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:08 ` Eli Zaretskii 2020-09-16 16:30 ` Alan Third @ 2020-09-16 16:45 ` Alfred M. Szmidt 2020-09-16 22:11 ` arthur miller 2 siblings, 1 reply; 96+ messages in thread From: Alfred M. Szmidt @ 2020-09-16 16:45 UTC (permalink / raw To: Andrea Corallo; +Cc: self, eliz, larsi, emacs-devel >> > Yes, let's find a different name for this. I'd object to calling it >> > "modern", because I disagree that vanilla Emacs isn't. >> >> I think "modern" implies that one day it won't be modern any more, so >> it's a fine name by me. But perhaps it should be more specific: >> `modern-2020-mode'. > > I'm okay with that if we drop the "modern" part. How about > emacs-2021-mode? I like this one too :) But would still be possible to have it enabled with a command line option? I mean if every new release we have a new version of this mode (theme?) either we loose this ability or we have the command line option binded to the most recent one. Why not some clickable link on the splash screen, or a toggle from the menu-bar? The only option that might make sense is an option to select a theme from the command line. ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-16 16:45 ` Alfred M. Szmidt @ 2020-09-16 22:11 ` arthur miller 0 siblings, 0 replies; 96+ messages in thread From: arthur miller @ 2020-09-16 22:11 UTC (permalink / raw To: Alfred M. Szmidt, Andrea Corallo Cc: self@gkayaalp.com, eliz@gnu.org, larsi@gnus.org, emacs-devel@gnu.org [-- Attachment #1: Type: text/plain, Size: 2678 bytes --] You didn't created Emacs 20-mode when you switched from Emacs 19 to Emacs 20. Why should you have new mode for new version? I don't think this entire discussion is about being modern, but about being more like other software. As I have followed original Andrea's proposal, here is what I think: Make a list of external packages that are legally and technically acceptable for inclusion in Emacs (for example which-key) Include those and enable them as default, not as a mode. Old users are experienced enough to setq a variable or two, or change it via customize, new users are not. Rarionale: you already have such features (me nus, tool ars, scrollbars etc) that experienced users usually turn off. Same is with which-key and other new packages you choose to include. Keyboard interaction is another subject in this "modern" discussion. 3d modellers/animation packages usually come with key-bindings that resemble competitions package. That to make eventual transition easy. I have no idea if it is fully possible in Emacs, but Emacs already have Vi emulation. Maybe there could be VisualStudio too (or whatever is interesting)? Remapping C-x & co is probably not directly trivial. Looks: Emacs has themes, and there are quality themes out there. A not so trivial part is 3rd party packages which has to be skinned "manually", something seems to be missing, so complete theming framework so 3rd party packages can also get blended into looks automatically (a thread about color scheming is about that). -------- Originalmeddelande -------- Från: "Alfred M. Szmidt" <ams@gnu.org> Datum: 2020-09-16 18:49 (GMT+01:00) Till: Andrea Corallo <akrl@sdf.org> Kopia: self@gkayaalp.com, eliz@gnu.org, larsi@gnus.org, emacs-devel@gnu.org Ämne: Re: A modern-mode? >> > Yes, let's find a different name for this. I'd object to calling it >> > "modern", because I disagree that vanilla Emacs isn't. >> >> I think "modern" implies that one day it won't be modern any more, so >> it's a fine name by me. But perhaps it should be more specific: >> `modern-2020-mode'. > > I'm okay with that if we drop the "modern" part. How about > emacs-2021-mode? I like this one too :) But would still be possible to have it enabled with a command line option? I mean if every new release we have a new version of this mode (theme?) either we loose this ability or we have the command line option binded to the most recent one. Why not some clickable link on the splash screen, or a toggle from the menu-bar? The only option that might make sense is an option to select a theme from the command line. [-- Attachment #2: Type: text/html, Size: 3991 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:18 ` Lars Ingebrigtsen 2020-09-16 15:33 ` Andrea Corallo via Emacs development discussions. 2020-09-16 15:46 ` Eli Zaretskii @ 2020-09-16 21:54 ` Dmitry Gutov 2 siblings, 0 replies; 96+ messages in thread From: Dmitry Gutov @ 2020-09-16 21:54 UTC (permalink / raw To: Lars Ingebrigtsen, Eli Zaretskii Cc: self, Alfred M. Szmidt, emacs-devel, akrl On 16.09.2020 18:18, Lars Ingebrigtsen wrote: > I think "modern" implies that one day it won't be modern any more, so > it's a fine name by me. But perhaps it should be more specific: > `modern-2020-mode'. You can call it 21st-century-mode, and it will still fit. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 14:32 ` Eli Zaretskii 2020-09-16 14:46 ` Andrea Corallo via Emacs development discussions. 2020-09-16 15:18 ` Lars Ingebrigtsen @ 2020-09-16 15:18 ` Alfred M. Szmidt 2020-09-16 15:27 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:45 ` tomas 3 siblings, 1 reply; 96+ messages in thread From: Alfred M. Szmidt @ 2020-09-16 15:18 UTC (permalink / raw To: Eli Zaretskii; +Cc: self, emacs-devel, akrl > Names mean things and in this discussion it was because Emacs was seen > as old (i.e., un-modern), a new user would be curious why modern-mode > isn't the default. And as the discussion has showed, there is no > agreement what people think is modern. So it would be simply better > to avoid the term "modern" completely. Yes, let's find a different name for this. I'd object to calling it "modern", because I disagree that vanilla Emacs isn't. A more specific name also means that not everything has to be added to such a theme/mode -- as it has a specific goal to solve. E.g., making it easier for new users to use Emacs -- which is slightly different from "modernizing" Emacs (similar sentiment to Eli there) which Andrea(?) seemed want to address. newcomer-friendly-mode? new-to-emacs-mode? numacs-mode? ersatz-mode? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:18 ` Alfred M. Szmidt @ 2020-09-16 15:27 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:45 ` Alfred M. Szmidt 0 siblings, 1 reply; 96+ messages in thread From: Andrea Corallo via Emacs development discussions. @ 2020-09-16 15:27 UTC (permalink / raw To: Alfred M. Szmidt; +Cc: Eli Zaretskii, self, emacs-devel ams@gnu.org (Alfred M. Szmidt) writes: > A more specific name also means that not everything has to be added to > such a theme/mode -- as it has a specific goal to solve. E.g., making > it easier for new users to use Emacs -- which is slightly different > from "modernizing" Emacs (similar sentiment to Eli there) which > Andrea(?) seemed want to address. "modern" popular editors are made to be accessible and confortable to be used for new comers. This is the same problem. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:27 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 16:45 ` Alfred M. Szmidt 2020-09-17 3:58 ` Richard Stallman 0 siblings, 1 reply; 96+ messages in thread From: Alfred M. Szmidt @ 2020-09-16 16:45 UTC (permalink / raw To: Andrea Corallo; +Cc: self, eliz, emacs-devel > A more specific name also means that not everything has to be added to > such a theme/mode -- as it has a specific goal to solve. E.g., making > it easier for new users to use Emacs -- which is slightly different > from "modernizing" Emacs (similar sentiment to Eli there) which > Andrea(?) seemed want to address. "modern" popular editors are made to be accessible and confortable to be used for new comers. This is the same problem. And the same is true for vanila Emacs. Maybe call this Bolios; in homage to Emack and Bolios from which the name Emacs comes from. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 16:45 ` Alfred M. Szmidt @ 2020-09-17 3:58 ` Richard Stallman 2020-09-17 4:45 ` Alfred M. Szmidt 0 siblings, 1 reply; 96+ messages in thread From: Richard Stallman @ 2020-09-17 3:58 UTC (permalink / raw To: Alfred M. Szmidt; +Cc: self, eliz, emacs-devel, akrl [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Maybe call this Bolios; in homage to Emack and Bolios from which the > name Emacs comes from. The name "Emacs" has nothing to do with that store. I did not know about the store until after starting Emacs; when I tried it, I did not particularly like it, and never went back. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-17 3:58 ` Richard Stallman @ 2020-09-17 4:45 ` Alfred M. Szmidt 2020-09-17 9:54 ` Lars Brinkhoff 0 siblings, 1 reply; 96+ messages in thread From: Alfred M. Szmidt @ 2020-09-17 4:45 UTC (permalink / raw To: rms; +Cc: self, eliz, emacs-devel, akrl > Maybe call this Bolios; in homage to Emack and Bolios from which the > name Emacs comes from. The name "Emacs" has nothing to do with that store. Sorry, the joke/pun/whatever to call it was far to subtle -- modern has nothing to do with modern, and Emacks and Bolio had nothing to do with Emacs. So a name that has nothing to do with either... ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-17 4:45 ` Alfred M. Szmidt @ 2020-09-17 9:54 ` Lars Brinkhoff 2020-09-18 4:09 ` Richard Stallman 0 siblings, 1 reply; 96+ messages in thread From: Lars Brinkhoff @ 2020-09-17 9:54 UTC (permalink / raw To: emacs-devel Alfred M. Szmidt wrote: > > Maybe call this Bolios; in homage to Emack and Bolios from > > which the name Emacs comes from. > > The name "Emacs" has nothing to do with that store. > > Sorry, the joke/pun/whatever to call it was far to subtle -- modern > has nothing to do with modern, and Emacks and Bolio had nothing to do > with Emacs. This exchange is almost like the original AI koan: | A cocky novice once said to Stallman: "I can guess why the editor is | called Emacs, but why is the justifier called Bolio?" | | Stallman replied forcefully: "Names are but names, 'Emack & Bolio's' | is the name of a popular ice cream shop in Boston-town. Neither of | these men had anything to do with the software." | | His question answered, yet unanswered, the novice turned to go, but | Stallman called to him: "Neither Emack nor Bolio had anything to do | with the ice cream shop, either." ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-17 9:54 ` Lars Brinkhoff @ 2020-09-18 4:09 ` Richard Stallman 0 siblings, 0 replies; 96+ messages in thread From: Richard Stallman @ 2020-09-18 4:09 UTC (permalink / raw To: Lars Brinkhoff; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > | A cocky novice once said to Stallman: "I can guess why the editor is > | called Emacs, but why is the justifier called Bolio?" > | > | Stallman replied forcefully: "Names are but names, 'Emack & Bolio's' > | is the name of a popular ice cream shop in Boston-town. Neither of > | these men had anything to do with the software." > | > | His question answered, yet unanswered, the novice turned to go, but > | Stallman called to him: "Neither Emack nor Bolio had anything to do > | with the ice cream shop, either." That joke is misleading, since I did not know any of that When Bolio was written -- around 1980 I think -- I did not know about the store. I was puzzled by thek text formatter's name, and asked what it meant. Then I was told about the store. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 14:32 ` Eli Zaretskii ` (2 preceding siblings ...) 2020-09-16 15:18 ` Alfred M. Szmidt @ 2020-09-16 16:45 ` tomas 2020-09-16 21:47 ` arthur miller 3 siblings, 1 reply; 96+ messages in thread From: tomas @ 2020-09-16 16:45 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 307 bytes --] On Wed, Sep 16, 2020 at 05:32:03PM +0300, Eli Zaretskii wrote: [...] > Yes, let's find a different name for this. I'd object to calling it > "modern", because I disagree that vanilla Emacs isn't. > > newcomer-friendly-mode? new-to-emacs-mode? numacs-mode? Millenial-mode? ;-P Cheers - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-16 16:45 ` tomas @ 2020-09-16 21:47 ` arthur miller 0 siblings, 0 replies; 96+ messages in thread From: arthur miller @ 2020-09-16 21:47 UTC (permalink / raw To: tomas@tuxteam.de, emacs-devel@gnu.org [-- Attachment #1: Type: text/plain, Size: 529 bytes --] +1 😁 Skickat från min Samsung Galaxy-smartphone. -------- Originalmeddelande -------- Från: tomas@tuxteam.de Datum: 2020-09-16 18:47 (GMT+01:00) Till: emacs-devel@gnu.org Ämne: Re: A modern-mode? On Wed, Sep 16, 2020 at 05:32:03PM +0300, Eli Zaretskii wrote: [...] > Yes, let's find a different name for this. I'd object to calling it > "modern", because I disagree that vanilla Emacs isn't. > > newcomer-friendly-mode? new-to-emacs-mode? numacs-mode? Millenial-mode? ;-P Cheers - t [-- Attachment #2: Type: text/html, Size: 1408 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 10:30 ` Göktuğ Kayaalp 2020-09-16 11:17 ` Alfred M. Szmidt @ 2020-09-16 18:19 ` Daniel Martín 2020-09-16 18:45 ` Thibaut Verron 1 sibling, 1 reply; 96+ messages in thread From: Daniel Martín @ 2020-09-16 18:19 UTC (permalink / raw To: Göktuğ Kayaalp; +Cc: emacs-devel, Andrea Corallo > > IMHO reading too much into names is not productive. ‘Modern’ is a term > that’s used fairly often in this context, and what to expect would be > obvious to those who would want to use such a mode: features common to > contemporary text editors. "Modern" may give the impression that the rest of Emacs is old. Maybe emacs-beginner-mode, or some name that uses the word "familiar", or a synonym? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 18:19 ` Daniel Martín @ 2020-09-16 18:45 ` Thibaut Verron 2020-09-16 18:53 ` Eli Zaretskii 0 siblings, 1 reply; 96+ messages in thread From: Thibaut Verron @ 2020-09-16 18:45 UTC (permalink / raw To: Daniel Martín; +Cc: Göktuğ Kayaalp, Andrea Corallo, emacs-devel > "Modern" may give the impression that the rest of Emacs is old. I don't see a problem there. > Maybe emacs-beginner-mode, or some name that uses the word "familiar", > or a synonym? Such a name would convey the impression that those settings are for beginners and that experts prefer not to use them. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 18:45 ` Thibaut Verron @ 2020-09-16 18:53 ` Eli Zaretskii 2020-09-16 20:02 ` Thibaut Verron 0 siblings, 1 reply; 96+ messages in thread From: Eli Zaretskii @ 2020-09-16 18:53 UTC (permalink / raw To: thibaut.verron; +Cc: self, akrl, emacs-devel, mardani29 > From: Thibaut Verron <thibaut.verron@gmail.com> > Date: Wed, 16 Sep 2020 20:45:48 +0200 > Cc: Göktuğ Kayaalp <self@gkayaalp.com>, > Andrea Corallo <akrl@sdf.org>, emacs-devel <emacs-devel@gnu.org> > > > Maybe emacs-beginner-mode, or some name that uses the word "familiar", > > or a synonym? > > Such a name would convey the impression that those settings are for > beginners Which they are. > and that experts prefer not to use them. How do you get this impression? The name is not emacs-beginner-but-not-expert-mode or anything to that effect. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 18:53 ` Eli Zaretskii @ 2020-09-16 20:02 ` Thibaut Verron 2020-09-16 21:36 ` Alan Third 2020-09-16 21:48 ` Lars Ingebrigtsen 0 siblings, 2 replies; 96+ messages in thread From: Thibaut Verron @ 2020-09-16 20:02 UTC (permalink / raw To: Eli Zaretskii; +Cc: self, akrl, emacs-devel, mardani29 > > Such a name would convey the impression that those settings are for > > beginners > > Which they are. I disagree. We are not talking about cua-mode or undo-only/redo-only here. We are talking about full Emacs features which users usually expect but need to discover. Those settings are for everybody, except those who know that they don't want them. > > and that experts prefer not to use them. > > How do you get this impression? The name is not > emacs-beginner-but-not-expert-mode or anything to that effect. And modern-mode is not modern-and-not-completely-archaic-mode. But in both cases, by choosing this name, we would state that it is the best qualificative we could find for all those settings, and to me it seems to imply that those settings are not for experts (resp. not-completely-archaic). I don't think that I'm the only one with this understanding, see for example the earlier post suggesting the name newbie-mode (synonymous to beginner-mode for me) with the idea that users would eventually grow out of this mode, like training wheels. I don't consider any of the suggested settings to be training wheels. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 20:02 ` Thibaut Verron @ 2020-09-16 21:36 ` Alan Third 2020-09-17 0:11 ` arthur miller 2020-09-17 3:18 ` Thibaut Verron 2020-09-16 21:48 ` Lars Ingebrigtsen 1 sibling, 2 replies; 96+ messages in thread From: Alan Third @ 2020-09-16 21:36 UTC (permalink / raw To: Thibaut Verron; +Cc: self, Eli Zaretskii, emacs-devel, mardani29, akrl On Wed, Sep 16, 2020 at 10:02:20PM +0200, Thibaut Verron wrote: > I don't think that I'm the only one with this understanding, see for > example the earlier post suggesting the name newbie-mode (synonymous > to beginner-mode for me) with the idea that users would eventually > grow out of this mode, like training wheels. I don't consider any of > the suggested settings to be training wheels. It's the use of the theme (or mode) that's expected to be "grown out of". As the user progresses they'll discover they like this, but they don't like that, and now they have to make the choice of whether to disable the theme and just enable the features they want in their init.el, or enable the theme and try to disable the features they don't want in their init.el. I think the latter option is less desirable and probably harder to achieve. Perhaps the theme should come with documentation explaining what you need to add to your init.el to achieve the same effects. -- Alan Third ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-16 21:36 ` Alan Third @ 2020-09-17 0:11 ` arthur miller 2020-09-17 19:17 ` Alan Third 2020-09-17 3:18 ` Thibaut Verron 1 sibling, 1 reply; 96+ messages in thread From: arthur miller @ 2020-09-17 0:11 UTC (permalink / raw To: Alan Third, Thibaut Verron Cc: self@gkayaalp.com, akrl@sdf.org, Eli Zaretskii, mardani29@yahoo.es, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1628 bytes --] Isn't what you describe just ordinary Emacs usage? I mean we use Emacs, we grow out of default features and turn off/on stuff after hand as our knowledge and skills ? By the way, why would anyone turn off features and then recreate them in their init file? It seems like very convoluted use case to me. -------- Originalmeddelande -------- Från: Alan Third <alan@idiocy.org> Datum: 2020-09-16 23:37 (GMT+01:00) Till: Thibaut Verron <thibaut.verron@gmail.com> Kopia: self@gkayaalp.com, Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org>, mardani29@yahoo.es, akrl@sdf.org Ämne: Re: A modern-mode? On Wed, Sep 16, 2020 at 10:02:20PM +0200, Thibaut Verron wrote: > I don't think that I'm the only one with this understanding, see for > example the earlier post suggesting the name newbie-mode (synonymous > to beginner-mode for me) with the idea that users would eventually > grow out of this mode, like training wheels. I don't consider any of > the suggested settings to be training wheels. It's the use of the theme (or mode) that's expected to be "grown out of". As the user progresses they'll discover they like this, but they don't like that, and now they have to make the choice of whether to disable the theme and just enable the features they want in their init.el, or enable the theme and try to disable the features they don't want in their init.el. I think the latter option is less desirable and probably harder to achieve. Perhaps the theme should come with documentation explaining what you need to add to your init.el to achieve the same effects. -- Alan Third [-- Attachment #2: Type: text/html, Size: 2430 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-17 0:11 ` arthur miller @ 2020-09-17 19:17 ` Alan Third 2020-09-17 19:43 ` Stefan Monnier 0 siblings, 1 reply; 96+ messages in thread From: Alan Third @ 2020-09-17 19:17 UTC (permalink / raw To: arthur miller Cc: Thibaut Verron, mardani29@yahoo.es, self@gkayaalp.com, Eli Zaretskii, emacs-devel, akrl@sdf.org On Thu, Sep 17, 2020 at 12:11:04AM +0000, arthur miller wrote: > Isn't what you describe just ordinary Emacs usage? I mean we use > Emacs, we grow out of default features and turn off/on stuff after > hand as our knowledge and skills ? > > By the way, why would anyone turn off features and then recreate > them in their init file? It seems like very convoluted use case to > me. As opposed to turning on features with a theme then turning them off again in their init file? I've seen enough people ask how to implement spacemacs/doom features in vanilla Emacs to know that this happens. -- Alan Third ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-17 19:17 ` Alan Third @ 2020-09-17 19:43 ` Stefan Monnier 2020-09-17 19:54 ` arthur miller 0 siblings, 1 reply; 96+ messages in thread From: Stefan Monnier @ 2020-09-17 19:43 UTC (permalink / raw To: Alan Third Cc: Thibaut Verron, mardani29@yahoo.es, arthur miller, self@gkayaalp.com, Eli Zaretskii, emacs-devel, akrl@sdf.org >> By the way, why would anyone turn off features and then recreate >> them in their init file? It seems like very convoluted use case to >> me. > As opposed to turning on features with a theme then turning them off > again in their init file? > I've seen enough people ask how to implement spacemacs/doom features > in vanilla Emacs to know that this happens. BTW one of the advantages of themes is also that we could provide a UI that displays the various elements of that theme (without having to show ELisp code). Stefan ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-17 19:43 ` Stefan Monnier @ 2020-09-17 19:54 ` arthur miller 2020-09-18 4:50 ` Arthur Miller 0 siblings, 1 reply; 96+ messages in thread From: arthur miller @ 2020-09-17 19:54 UTC (permalink / raw To: Stefan Monnier, Alan Third Cc: Thibaut Verron, mardani29@yahoo.es, self@gkayaalp.com, Eli Zaretskii, emacs-devel, akrl@sdf.org [-- Attachment #1: Type: text/plain, Size: 1263 bytes --] Can't customize already show ui to turn on/off features without showing elisp? Can't there be just a customize group or page where people can turn on/off features and similar? What makes theme more suitable? I am sorry if I am a tad bit obnoxious, my goal is not to be negative, just "thinking loud". -------- Originalmeddelande -------- Från: Stefan Monnier <monnier@iro.umontreal.ca> Datum: 2020-09-17 21:43 (GMT+01:00) Till: Alan Third <alan@idiocy.org> Kopia: arthur miller <arthur.miller@live.com>, Thibaut Verron <thibaut.verron@gmail.com>, self@gkayaalp.com, akrl@sdf.org, Eli Zaretskii <eliz@gnu.org>, mardani29@yahoo.es, emacs-devel <emacs-devel@gnu.org> Ämne: Re: A modern-mode? >> By the way, why would anyone turn off features and then recreate >> them in their init file? It seems like very convoluted use case to >> me. > As opposed to turning on features with a theme then turning them off > again in their init file? > I've seen enough people ask how to implement spacemacs/doom features > in vanilla Emacs to know that this happens. BTW one of the advantages of themes is also that we could provide a UI that displays the various elements of that theme (without having to show ELisp code). Stefan [-- Attachment #2: Type: text/html, Size: 2162 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-17 19:54 ` arthur miller @ 2020-09-18 4:50 ` Arthur Miller 0 siblings, 0 replies; 96+ messages in thread From: Arthur Miller @ 2020-09-18 4:50 UTC (permalink / raw To: Stefan Monnier Cc: Alan Third, Thibaut Verron, emacs-devel, self@gkayaalp.com, Eli Zaretskii, mardani29@yahoo.es, akrl@sdf.org arthur miller <arthur.miller@live.com> writes: > Can't customize already show ui to turn on/off features without showing elisp? > > Can't there be just a customize group or page where people can turn on/off features and similar? What makes theme more > suitable? > > I am sorry if I am a tad bit obnoxious, my goal is not to be negative, just "thinking loud". > > -------- Originalmeddelande -------- > Från: Stefan Monnier <monnier@iro.umontreal.ca> > Datum: 2020-09-17 21:43 (GMT+01:00) > Till: Alan Third <alan@idiocy.org> > Kopia: arthur miller <arthur.miller@live.com>, Thibaut Verron <thibaut.verron@gmail.com>, self@gkayaalp.com, akrl@sdf.org, Eli > Zaretskii <eliz@gnu.org>, mardani29@yahoo.es, emacs-devel <emacs-devel@gnu.org> > Ämne: Re: A modern-mode? > >>> By the way, why would anyone turn off features and then recreate >>> them in their init file? It seems like very convoluted use case to >>> me. >> As opposed to turning on features with a theme then turning them off >> again in their init file? >> I've seen enough people ask how to implement spacemacs/doom features >> in vanilla Emacs to know that this happens. > > BTW one of the advantages of themes is also that we could provide a UI > that displays the various elements of that theme (without having to show > ELisp code). > > Stefan Sorry, I have been looking into manual about themes and custom.el; sure theme can do anything so I understand it now :-). "Custom themes are collections of settings that can be enabled or disabled as a unit. You can use Custom themes to switch easily between various collections of settings, and to transfer such collections from one computer to another. " ".... loading a Custom theme can execute arbitrary Lisp code ..." "To apply the choice of theme(s) to future Emacs sessions, type C-x C-s (custom-theme-save) or use the ‘[Save Theme Settings]’ button." So indeed it can be used for anything. Though I would rather call such theme for a "mode" but that would be really a confusion since Emacs modes are different things. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 21:36 ` Alan Third 2020-09-17 0:11 ` arthur miller @ 2020-09-17 3:18 ` Thibaut Verron 1 sibling, 0 replies; 96+ messages in thread From: Thibaut Verron @ 2020-09-17 3:18 UTC (permalink / raw To: Alan Third, Thibaut Verron, Eli Zaretskii, self, akrl, emacs-devel, mardani29 [-- Attachment #1: Type: text/plain, Size: 2145 bytes --] Le mer. 16 sept. 2020 à 23:36, Alan Third <alan@idiocy.org> a écrit : > On Wed, Sep 16, 2020 at 10:02:20PM +0200, Thibaut Verron wrote: > > I don't think that I'm the only one with this understanding, see for > > example the earlier post suggesting the name newbie-mode (synonymous > > to beginner-mode for me) with the idea that users would eventually > > grow out of this mode, like training wheels. I don't consider any of > > the suggested settings to be training wheels. > > It's the use of the theme (or mode) that's expected to be "grown out > of". As the user progresses they'll discover they like this, but they > don't like that, and now they have to make the choice of whether to > disable the theme and just enable the features they want in their > init.el, or enable the theme and try to disable the features they > don't want in their init.el. I think the latter option is less > desirable and probably harder to achieve. > > Perhaps the theme should come with documentation explaining what you > need to add to your init.el to achieve the same effects. > But why is that a good thing? The point as I understand it is that all those features were suggested to be activated by default (some of them are). Because we cannot so easily change the defaults, this mode gives an easy entry point to users wanting those defaults (even if they don't know it yet). If they were defaults we wouldn't expect the users to explicitly re-add them to their init.el (actually, if we did, there wouldn't be a problem with changing the defaults in the first place). So why treat this mode any differently? If this mode is implemented, I'd probably go the other route and remove the corresponding settings in my init.el and invoke the mode instead. Just as I would do with anything else I would be doing by hand but now comes built-in, to avoid duplicating the work of maintaining the code. As for disabling individual features, it's been suggested that the mode offers customization for its individual options, so there shouldn't be any need for elisp to activate or deactivate individual options. > [-- Attachment #2: Type: text/html, Size: 2861 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 20:02 ` Thibaut Verron 2020-09-16 21:36 ` Alan Third @ 2020-09-16 21:48 ` Lars Ingebrigtsen 1 sibling, 0 replies; 96+ messages in thread From: Lars Ingebrigtsen @ 2020-09-16 21:48 UTC (permalink / raw To: Thibaut Verron; +Cc: self, Eli Zaretskii, emacs-devel, mardani29, akrl Thibaut Verron <thibaut.verron@gmail.com> writes: > I don't think that I'm the only one with this understanding, see for > example the earlier post suggesting the name newbie-mode (synonymous > to beginner-mode for me) with the idea that users would eventually > grow out of this mode, like training wheels. I don't consider any of > the suggested settings to be training wheels. Yeah, `newbie-mode' or anything similar to that would just be an insult. This should be an opinionated and curated selection of good modes and themes, and there's nothing "newbie" or "beginner" about that. And there should, of course, be more than one of these. Just give them fun names, like, say, "Doom" or "Quake". -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 7:36 ` Alfred M. Szmidt 2020-09-16 8:36 ` Alan Third 2020-09-16 10:30 ` Göktuğ Kayaalp @ 2020-09-17 3:53 ` Richard Stallman 2 siblings, 0 replies; 96+ messages in thread From: Richard Stallman @ 2020-09-17 3:53 UTC (permalink / raw To: Alfred M. Szmidt; +Cc: emacs-devel, akrl [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The word modern has a negative meaning in that it implies that the > rest of Emacs isn't modern -- why would users ever want to switch of > "modern-mode" and use the un-modern Emacs? How about Faddish mode? Fashionable mode? Mode mode? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 7:27 ` Andrea Corallo via Emacs development discussions. 2020-09-16 7:36 ` Alfred M. Szmidt @ 2020-09-16 8:15 ` Ergus 1 sibling, 0 replies; 96+ messages in thread From: Ergus @ 2020-09-16 8:15 UTC (permalink / raw To: Andrea Corallo; +Cc: Alfred M. Szmidt, emacs-devel On Wed, Sep 16, 2020 at 07:27:10AM +0000, Andrea Corallo via Emacs development discussions. wrote: >ams@gnu.org (Alfred M. Szmidt) writes: > >> What was once modern will become old again, and what was old again >> will become modern. > >One important aspect of this collection of settings is that we should be >less committed to (eternal :) immutability as we are for normal >defaults. > >As this is meant to be an help for new starters we should feel free to >improve these from release to release without a negative impact on old >new starters, as by definition they are not anymore new starters :) > >IOW If they stayed around for more than a release cycle quite certainly >they have learned how to personalize Emacs themselves. > > Andrea > Maybe instead of modern we should call it experimental/develop... (: looking the discussion here we should call it warrior or rebel ;) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 5:14 ` Alfred M. Szmidt 2020-09-16 7:27 ` Andrea Corallo via Emacs development discussions. @ 2020-09-16 7:33 ` Robert Pluim 2020-09-16 8:55 ` tomas 2020-09-16 9:36 ` João Távora 2 siblings, 1 reply; 96+ messages in thread From: Robert Pluim @ 2020-09-16 7:33 UTC (permalink / raw To: Alfred M. Szmidt; +Cc: emacs-devel, Andrea Corallo >>>>> On Wed, 16 Sep 2020 01:14:52 -0400, ams@gnu.org (Alfred M. Szmidt) said: Alfred> following recent discussions I've started toying with what I've pushed on Alfred> scratch/modern-mode. Alfred> What some find modern, some will find old. What some find old, some Alfred> will find modern. What was once modern will become old again, and Alfred> what was old again will become modern. Alfred> A different name would be more appropriate. cadt-mode? (with apologies to jwz) Robert ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 7:33 ` Robert Pluim @ 2020-09-16 8:55 ` tomas 0 siblings, 0 replies; 96+ messages in thread From: tomas @ 2020-09-16 8:55 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 418 bytes --] On Wed, Sep 16, 2020 at 09:33:50AM +0200, Robert Pluim wrote: [...] > cadt-mode? (with apologies to jwz) But then, it would have to change every two weeks. Since that might become tedious for devels, which also have to squash bugs here and there, I propose a genetic annealing driven mode generator fed by a machine learning program which scans the Internets for new trends. Perhaps agent-based. ;-P Cheers - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 5:14 ` Alfred M. Szmidt 2020-09-16 7:27 ` Andrea Corallo via Emacs development discussions. 2020-09-16 7:33 ` Robert Pluim @ 2020-09-16 9:36 ` João Távora 2020-09-16 9:48 ` tomas 2 siblings, 1 reply; 96+ messages in thread From: João Távora @ 2020-09-16 9:36 UTC (permalink / raw To: Alfred M. Szmidt; +Cc: emacs-devel, Andrea Corallo [-- Attachment #1: Type: text/plain, Size: 1233 bytes --] On Wed, Sep 16, 2020 at 6:15 AM Alfred M. Szmidt <ams@gnu.org> wrote: > following recent discussions I've started toying with what I've pushed > on > scratch/modern-mode. > > What some find modern, some will find old. What some find old, some > will find modern. What was once modern will become old again, and > what was old again will become modern. > > A different name would be more appropriate Yup, this is really obvious to me, too (*) I seem to remember that other packages don't have a lot of problems naming some features "fancy". Does "fancy" have a negative connotation? Maybe it does, as does e.g. "baroque". Both terms indicate an "elaboration" or an "amplification" beyond some essential state, which would be Emacs -Q, I guess. fancy-mode? rich-mode? amplified-mode? ornate-mode? Why not just andrea-mode? João * though "modernism" is itself considered a style, reasonably well defined within the 20th century, but that doesn't matter, unless we are purposely trying to emulate that style in Emacs, which I don't think we are. On a tangent, Emacs defaults themselves could even be seen as modernist already, form mostly follows function, rejects most ornament, etc etc [-- Attachment #2: Type: text/html, Size: 2029 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 9:36 ` João Távora @ 2020-09-16 9:48 ` tomas 2020-09-16 9:54 ` João Távora 2020-09-16 12:32 ` Arthur Miller 0 siblings, 2 replies; 96+ messages in thread From: tomas @ 2020-09-16 9:48 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1208 bytes --] On Wed, Sep 16, 2020 at 10:36:23AM +0100, João Távora wrote: > On Wed, Sep 16, 2020 at 6:15 AM Alfred M. Szmidt <ams@gnu.org> wrote: > > > following recent discussions I've started toying with what I've pushed > > on > > scratch/modern-mode. > > > > What some find modern, some will find old. What some find old, some > > will find modern. What was once modern will become old again, and > > what was old again will become modern. > > > > A different name would be more appropriate > > > Yup, this is really obvious to me, too (*) I seem to remember that > other packages don't have a lot of problems naming some > features "fancy". Does "fancy" have a negative connotation? De Luxe? But more seriously: what I have learnt from all this discussion is that we'll need more than one of those. Those modes are often opinionated (they have to). So it's better if the mode's opinions align with those of the user. It'll be Emacs's job to provide the bridges and the common base for all of that (someone in this monster thread quoted X11's motto of providing "mechanism, not policy": I think this is - mutatis mutandis - a good guiding principle). Cheers - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 9:48 ` tomas @ 2020-09-16 9:54 ` João Távora 2020-09-16 10:20 ` tomas 2020-09-16 12:32 ` Arthur Miller 1 sibling, 1 reply; 96+ messages in thread From: João Távora @ 2020-09-16 9:54 UTC (permalink / raw To: tomas; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1434 bytes --] On Wed, Sep 16, 2020 at 10:50 AM <tomas@tuxteam.de> wrote: > On Wed, Sep 16, 2020 at 10:36:23AM +0100, João Távora wrote: > > On Wed, Sep 16, 2020 at 6:15 AM Alfred M. Szmidt <ams@gnu.org> wrote: > > > > > following recent discussions I've started toying with what I've > pushed > > > on > > > scratch/modern-mode. > > > > > > What some find modern, some will find old. What some find old, some > > > will find modern. What was once modern will become old again, and > > > what was old again will become modern. > > > > > > A different name would be more appropriate > > > > > > Yup, this is really obvious to me, too (*) I seem to remember that > > other packages don't have a lot of problems naming some > > features "fancy". Does "fancy" have a negative connotation? > > De Luxe? > > But more seriously: what I have learnt from all this discussion > is that we'll need more than one of those. > > Those modes are often opinionated (they have to). So it's better > if the mode's opinions align with those of the user.\ > Good point: these are opinionated things by nature, so they should be named as themes are, somewhat freely according to the vision of their authors. This also reveals that the thing shouldn't be called a "mode" at all. It should be done with custom-themes and if that proves a limitation, then custom-themes have to be improved, maybe even reinvented. João [-- Attachment #2: Type: text/html, Size: 2073 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 9:54 ` João Távora @ 2020-09-16 10:20 ` tomas 2020-09-16 10:30 ` João Távora 0 siblings, 1 reply; 96+ messages in thread From: tomas @ 2020-09-16 10:20 UTC (permalink / raw To: João Távora; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 516 bytes --] On Wed, Sep 16, 2020 at 10:54:43AM +0100, João Távora wrote: [...] > Good point: these are opinionated things by nature, so they > should be named as themes are, somewhat freely according > to the vision of their authors. This also reveals that the > thing shouldn't be called a "mode" at all. It should be done > with custom-themes and if that proves a limitation, then > custom-themes have to be improved, maybe even reinvented. We can set up our own giant feedback loops, too :-) Cheers - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 10:20 ` tomas @ 2020-09-16 10:30 ` João Távora 2020-09-16 10:53 ` tomas 2020-09-16 12:40 ` Arthur Miller 0 siblings, 2 replies; 96+ messages in thread From: João Távora @ 2020-09-16 10:30 UTC (permalink / raw To: tomas; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1215 bytes --] On Wed, Sep 16, 2020 at 11:20 AM <tomas@tuxteam.de> wrote: > On Wed, Sep 16, 2020 at 10:54:43AM +0100, João Távora wrote: > > [...] > > > Good point: these are opinionated things by nature, so they > > should be named as themes are, somewhat freely according > > to the vision of their authors. This also reveals that the > > thing shouldn't be called a "mode" at all. It should be done > > with custom-themes and if that proves a limitation, then > > custom-themes have to be improved, maybe even reinvented. > > We can set up our own giant feedback loops, too :-) > Not sure what you mean, I just meant the "custom-themes" infrastructure should be enough to accommodate enough of the proposed "modern-mode". Not sure if it is (as I don't use it). I think reasonably solutions with a lot of value and relatively little code are often in front of our eyes. Such was the case with icomplete being a good basis for fido-mode, which seems good enough that people are even recommending it. I'm almost always wary of giants or grand reinventions of things. For the "base" Emacs experience that is, in their setups people can use all the ivys, dooms, helms and magits they want. João [-- Attachment #2: Type: text/html, Size: 1747 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 10:30 ` João Távora @ 2020-09-16 10:53 ` tomas 2020-09-16 11:09 ` João Távora 2020-09-16 12:40 ` Arthur Miller 1 sibling, 1 reply; 96+ messages in thread From: tomas @ 2020-09-16 10:53 UTC (permalink / raw To: João Távora; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1952 bytes --] On Wed, Sep 16, 2020 at 11:30:18AM +0100, João Távora wrote: > On Wed, Sep 16, 2020 at 11:20 AM <tomas@tuxteam.de> wrote: > > > On Wed, Sep 16, 2020 at 10:54:43AM +0100, João Távora wrote: > > > > [...] > > > > > Good point: these are opinionated things by nature, so they > > > should be named as themes are, somewhat freely according > > > to the vision of their authors. This also reveals that the > > > thing shouldn't be called a "mode" at all. It should be done > > > with custom-themes and if that proves a limitation, then > > > custom-themes have to be improved, maybe even reinvented. > > > > We can set up our own giant feedback loops, too :-) > > > > Not sure what you mean, I just meant the "custom-themes" > infrastructure should be enough to accommodate enough of > the proposed "modern-mode". Not sure if it is (as I don't use it). Sorry -- was a lame self-reference. I characterised at some point that whatever is currently considered "ergonomic" is but part of a giant feedback loop involving (among many other things, like genuine UI research) big corp's marketing departments. What you wrote offered itself as another kind of feedback loop: opinionated "custom-themes" (or whatever we end up naming that) informing the Emacs core about whatever tech or concepts are necessary to keep the whole ship together. > I think reasonably solutions with a lot of value and relatively > little code are often in front of our eyes. Such was the case > with icomplete being a good basis for fido-mode, which seems > good enough that people are even recommending it. I'm > almost always wary of giants or grand reinventions of things. > For the "base" Emacs experience that is, in their setups people > can use all the ivys, dooms, helms and magits they want. So Emacs has been doing that all along, it seems... And still, this kind of discussions seem necessary and fruitful. Cheers - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 10:53 ` tomas @ 2020-09-16 11:09 ` João Távora 0 siblings, 0 replies; 96+ messages in thread From: João Távora @ 2020-09-16 11:09 UTC (permalink / raw To: tomas; +Cc: emacs-devel tomas@tuxteam.de writes: > loop: opinionated "custom-themes" (or whatever we end up > naming that) informing the Emacs core about whatever tech > or concepts are necessary to keep the whole ship together. > Right. New features often come with a component of infrastruture and component of user code that relies on it. >> I think reasonably solutions with a lot of value and relatively >> little code are often in front of our eyes. Such was the case >> with icomplete being a good basis for fido-mode, which seems >> good enough that people are even recommending it. I'm >> almost always wary of giants or grand reinventions of things. >> For the "base" Emacs experience that is, in their setups people >> can use all the ivys, dooms, helms and magits they want. > this kind of discussions seem necessary and fruitful. > Emacs has always had this "problem" which is brought about by the huge flexibility that Elisp affords. But those kitchen-sink developments don't always integrate cleanly into Emacs for various reasons (from legal to technical). Custom themes can be used to tweak aspects _already_ in Emacs, and doing the latter would make long strides towards newcomer-friendliness, I think (and I also think we've all kind of agreed on that, bringing us to the "defaults" argument"). Anyway, my impression is that, custom themes don't seem to be used effectively, except to customize colors. Maybe they're not powerful enough? They do seem to have features that are extremely desirable here, such as ease of distribution, ease of composition and human-readability (for non-programmers). João ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 10:30 ` João Távora 2020-09-16 10:53 ` tomas @ 2020-09-16 12:40 ` Arthur Miller 2020-09-16 13:04 ` João Távora 2020-09-16 16:42 ` tomas 1 sibling, 2 replies; 96+ messages in thread From: Arthur Miller @ 2020-09-16 12:40 UTC (permalink / raw To: João Távora; +Cc: tomas, emacs-devel João Távora <joaotavora@gmail.com> writes: > I just meant the "custom-themes" > infrastructure should be enough to accommodate enough of > the proposed "modern-mode". Not sure if it is (as I don't use it). No, it is not. It lacks unified framework to use as logicla names for color use; someting similar to what you have in <h1>, <h2>, ... <h8> in html, just as example. Instead people use rgb values directly in their packages, and when user changes a theme, packages does not follow. So theme engine in Emacs needs a little additional work. > I'm > almost always wary of giants or grand reinventions of things. > For the "base" Emacs experience that is, in their setups people > can use all the ivys, dooms, helms and magits they want. I understand your sentiment, but then, you could say this for any feature, inclusive fido-mode or icomplete or even find-file. Just as an illustration one could argue that "simpler" open-file as found in other software packages is what "casual" users would expext. Personally I would like to see ffap being enabled as default ... ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 12:40 ` Arthur Miller @ 2020-09-16 13:04 ` João Távora 2020-09-16 14:10 ` Arthur Miller 2020-09-16 14:20 ` Arthur Miller 2020-09-16 16:42 ` tomas 1 sibling, 2 replies; 96+ messages in thread From: João Távora @ 2020-09-16 13:04 UTC (permalink / raw To: Arthur Miller; +Cc: tomas, emacs-devel [-- Attachment #1: Type: text/plain, Size: 3101 bytes --] On Wed, Sep 16, 2020 at 1:40 PM Arthur Miller <arthur.miller@live.com> wrote: > João Távora <joaotavora@gmail.com> writes: > > > I just meant the "custom-themes" > > infrastructure should be enough to accommodate enough of > > the proposed "modern-mode". Not sure if it is (as I don't use it). > No, it is not. It lacks unified framework to use as logicla names for > color use; someting similar to what you have in <h1>, <h2>, ... <h8> in > html, just as example. Instead people use rgb values directly in their > packages, and when user changes a theme, packages does not follow. So > theme engine in Emacs needs a little additional work. > In theming, Emacs works with faces, not with colors. Those would seem to be sufficient logical placeholders for various types of colors. But indeed my message suffered from this confusion, too. > > I'm > > almost always wary of giants or grand reinventions of things. > > For the "base" Emacs experience that is, in their setups people > > can use all the ivys, dooms, helms and magits they want. > I understand your sentiment, but then, you could say this for any > feature, inclusive fido-mode or icomplete or even find-file. > I don't think you can. It's because of their simplicity that they are much better integrated into Emacs's infrastructure. Compare the number of lines and the number of configuration options in fido-mode/icomplete-mode to the same number in those other packages. These are leaner packages, they follow the existing infrastructure as much as possible, rather than reinvent it. But if the complexity comparison isn't satisfying to you, it's easy to note that changes to the infrastructure, i.e. completion styles, are "naturally" absorbed by icomplete-mode and fido-mode, whereas a package such as Helm had to go through great efforts to support them (reasonably recently). And Ivy still doesn't support them, as far as I know. In another example, multiple reinventions of the "imenu" display frontend, which read the menu item information directly have failed to account for recent augmentation of that format. Fido-mode provides a different visualization of M-x imenu without suffering from those problems, playing along with M-x imenu, rather than re-implemeting it. Reinventing a parallel infrastructure, easy as it is to do in Lisp/Emacs, has those very real drawbacks. Just as an illustration one could argue that "simpler" open-file as > found in other software packages is what "casual" users would expext. > Yes, you can argue that. I would maybe agree, though I wouldn't agree we should give those users exactly what they "expect", because they "expect" VSCode, I guess. But making a custom theme allow such modifications is what is needed, in my opinion. Then, if I'm mistaken, enabling that idea is just a few clicks away. Personally I would like to see ffap being enabled as default ... > Don't understand this bit. I use ffap a lot and don't need to "enable" anything, just M-x ffap. Is it a mode? João [-- Attachment #2: Type: text/html, Size: 4977 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 13:04 ` João Távora @ 2020-09-16 14:10 ` Arthur Miller 2020-09-16 15:26 ` João Távora 2020-09-16 14:20 ` Arthur Miller 1 sibling, 1 reply; 96+ messages in thread From: Arthur Miller @ 2020-09-16 14:10 UTC (permalink / raw To: João Távora; +Cc: tomas, emacs-devel João Távora <joaotavora@gmail.com> writes: > On Wed, Sep 16, 2020 at 1:40 PM Arthur Miller <arthur.miller@live.com> wrote: > > João Távora <joaotavora@gmail.com> writes: > > > I just meant the "custom-themes" > > infrastructure should be enough to accommodate enough of > > the proposed "modern-mode". Not sure if it is (as I don't use it). > No, it is not. It lacks unified framework to use as logicla names for > color use; someting similar to what you have in <h1>, <h2>, ... <h8> in > html, just as example. Instead people use rgb values directly in their > packages, and when user changes a theme, packages does not follow. So > theme engine in Emacs needs a little additional work. > > In theming, Emacs works with faces, not with colors. Those > would seem to be sufficient logical placeholders for > various types of colors. But indeed my message suffered > from this confusion, too. You are probably correct about this one. I myself are not very well acustomed to theming engine, faces, defface etc so I might not be aware that this mechanism already is there. Question is why 3rd party packages don't use those placeholders? Is it lack of documentation? Or something else. > > I'm > > almost always wary of giants or grand reinventions of things. > > For the "base" Emacs experience that is, in their setups people > > can use all the ivys, dooms, helms and magits they want. > I understand your sentiment, but then, you could say this for any > feature, inclusive fido-mode or icomplete or even find-file. > > I don't think you can. It's because of their simplicity that they > are much better integrated into Emacs's infrastructure. Compare > the number of lines and the number of configuration options > in fido-mode/icomplete-mode to the same number in those other > packages. These are leaner packages, they follow the existing > infrastructure as much as possible, rather than reinvent it. It is a little bit oranges to apples comparison. Helm offered quite different interaction model for completions then what was originally in Emacs. I don't know if fido/icomplete were in place then, so it is natural that complexity is there. Also offered set of feature is not the same. Just being simpler in terms of complexity is not good enough measure of quality, although it might be a reason good enough to use something. Observer also that when Ivy & Co get to level of Helm functionality it will probably be as complex as Helm. Same for other completions etc. > But if the complexity comparison isn't satisfying to you, it's easy > to note that changes to the infrastructure, i.e. completion styles, > are "naturally" absorbed by icomplete-mode and fido-mode, > whereas a package such as Helm had to go through great > efforts to support them (reasonably recently). Indeed, but it is in the nature of the thing, since it historically had to invent what was later added to Emacs core? If I understnd the history correct (correct me if I am wrong). > Don't understand this bit. I use ffap a lot and don't need to "enable" > anything, just M-x ffap. Is it a mode? Ok, I wasn't precise, it isn't a mode, but one can enable ffap bindings automatically so they replace ordinary ones by default. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 14:10 ` Arthur Miller @ 2020-09-16 15:26 ` João Távora 2020-09-16 15:43 ` Thibaut Verron 0 siblings, 1 reply; 96+ messages in thread From: João Távora @ 2020-09-16 15:26 UTC (permalink / raw To: Arthur Miller; +Cc: tomas, emacs-devel Arthur Miller <arthur.miller@live.com> writes: > João Távora <joaotavora@gmail.com> writes: > that this mechanism already is there. Question is why 3rd party packages > don't use those placeholders? Is it lack of documentation? Or > something else. I think they do use them. When I load theme A it uses something for say, the diff-added face. When I laod theme B it uses something else. >>> I understand your sentiment, but then, you could say this for any >>> feature, inclusive fido-mode or icomplete or even find-file. >> I don't think you can. It's because of their simplicity that they >> are much better integrated into Emacs's infrastructure. Compare >> the number of lines and the number of configuration options >> in fido-mode/icomplete-mode to the same number in those other >> packages. These are leaner packages, they follow the existing >> infrastructure as much as possible, rather than reinvent it. > It is a little bit oranges to apples comparison. Well you brought up fido-mode, not I. > Helm offered quite > different interaction model for completions then what was originally > in Emacs. I don't know if fido/icomplete were in place then, Pretty sure icomplete was. > so it is natural that complexity is there. Also offered set of feature > is not the same. Just being simpler in terms of complexity is not good > enough measure of quality, although it might be a reason good enough > to use something. Observer also that when Ivy & Co get to level of > Helm functionality it will probably be as complex as Helm. Same for > other completions etc. I'm not convinced about that, simply because helm duplicates a lot of stuff that is already in Emacs. I'm not saying fido-mode offers the same features, just that you can add features to it, say "acting on completions", in a way that integrates cleanly with existing infrastructure, without having to make new infrastructure. Helm took the route of making its own parallel infrastructure. So when a user uses some option to customize the former it doesn't affect the latter automatically, it has to be replicated. This is a simple matter of modular architecture. Helm's base is used by little more than Helm itself, in contrast to Emacs's own infrastructure. >> But if the complexity comparison isn't satisfying to you, it's easy >> to note that changes to the infrastructure, i.e. completion styles, >> are "naturally" absorbed by icomplete-mode and fido-mode, >> whereas a package such as Helm had to go through great >> efforts to support them (reasonably recently). > Indeed, but it is in the nature of the thing, since it historically had > to invent what was later added to Emacs core? If I understnd the history > correct (correct me if I am wrong). You are mostly wrong. Icomplete already existed and so did Imenu. But that's not the same as saying that infrastructure at the time was sufficient for Helm's vision, or even that it is now. I'm just saying that adding capabilities to existing infrastructure is a good thing, and by contrast making a parallel infrastructure is less of a good thing. Doing the former is hard because design decisions are carefully considered since they have to serve multiple clients. Doing the latter is easier and a good way to churn out features quickly. But alas, it creates the problems I explained. Sometimes things will get integrated into Emacs core, depending on how generic they were. For example xref.el came as a rewrite of SLIME's cross-referencing functionality. But it's a bit too ambitious to integrate say, Helm's completion gathering code with Emacs's. Some of Helm's interesting features can be copied, but that, again, takes work. >> Don't understand this bit. I use ffap a lot and don't need to >> "enable" anything, just M-x ffap. Is it a mode? > Ok, I wasn't precise, it isn't a mode, but one can enable ffap bindings > automatically so they replace ordinary ones by default. Still confused. Ffap is "find file at point" right? What do you want to replace with it? João ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:26 ` João Távora @ 2020-09-16 15:43 ` Thibaut Verron 2020-09-16 15:45 ` João Távora 0 siblings, 1 reply; 96+ messages in thread From: Thibaut Verron @ 2020-09-16 15:43 UTC (permalink / raw To: João Távora; +Cc: tomas, Arthur Miller, emacs-devel > >> Don't understand this bit. I use ffap a lot and don't need to > >> "enable" anything, just M-x ffap. Is it a mode? > > Ok, I wasn't precise, it isn't a mode, but one can enable ffap bindings > > automatically so they replace ordinary ones by default. > > Still confused. Ffap is "find file at point" right? What do you want to > replace with it? Maybe he means binding C-x C-f to ffap when point is on a file path (not a great idea in my experience) or to have the file name at point pre-entered in the completion prompt (I personally have that behavior enabled)? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 15:43 ` Thibaut Verron @ 2020-09-16 15:45 ` João Távora 0 siblings, 0 replies; 96+ messages in thread From: João Távora @ 2020-09-16 15:45 UTC (permalink / raw To: thibaut.verron; +Cc: tomas, Arthur Miller, emacs-devel [-- Attachment #1: Type: text/plain, Size: 802 bytes --] On Wed, Sep 16, 2020 at 4:43 PM Thibaut Verron <thibaut.verron@gmail.com> wrote: > > >> Don't understand this bit. I use ffap a lot and don't need to > > >> "enable" anything, just M-x ffap. Is it a mode? > > > Ok, I wasn't precise, it isn't a mode, but one can enable ffap bindings > > > automatically so they replace ordinary ones by default. > > > > Still confused. Ffap is "find file at point" right? What do you want to > > replace with it? > > Maybe he means binding C-x C-f to ffap when point is on a file path > (not a great idea in my experience) or to have the file name at point > pre-entered in the completion prompt (I personally have that behavior > enabled)? > Thanks. The latter makes more sense, indeed. But will be surprising for some users, I guess. João [-- Attachment #2: Type: text/html, Size: 1241 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 13:04 ` João Távora 2020-09-16 14:10 ` Arthur Miller @ 2020-09-16 14:20 ` Arthur Miller 1 sibling, 0 replies; 96+ messages in thread From: Arthur Miller @ 2020-09-16 14:20 UTC (permalink / raw To: João Távora; +Cc: tomas, emacs-devel João Távora <joaotavora@gmail.com> writes: > > I'm > > almost always wary of giants or grand reinventions of things. > > For the "base" Emacs experience that is, in their setups people > > can use all the ivys, dooms, helms and magits they want. > I understand your sentiment, but then, you could say this for any > feature, inclusive fido-mode or icomplete or even find-file. > > I don't think you can. It's because of their simplicity that they > are much better integrated into Emacs's infrastructure. Just add few more thoughts: I don't think it is bc of simplicity, but because they incorporate functionality that wasn's present when Helm/Ivy were written. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 12:40 ` Arthur Miller 2020-09-16 13:04 ` João Távora @ 2020-09-16 16:42 ` tomas 2020-09-16 21:46 ` arthur miller 1 sibling, 1 reply; 96+ messages in thread From: tomas @ 2020-09-16 16:42 UTC (permalink / raw To: Arthur Miller; +Cc: João Távora, emacs-devel [-- Attachment #1: Type: text/plain, Size: 762 bytes --] On Wed, Sep 16, 2020 at 02:40:53PM +0200, Arthur Miller wrote: > João Távora <joaotavora@gmail.com> writes: > > > I just meant the "custom-themes" > > infrastructure should be enough to accommodate enough of > > the proposed "modern-mode". Not sure if it is (as I don't use it). > No, it is not. It lacks unified framework to use as logicla names for > color use; Isn't "face" the better abstraction, anyway? Think blind people. Think color-blind people (up to 8% of the male and 0.5% of the female population of Norther European descent [1]). Conveying semantics via color has to have some fallback, and this meshes well with faces, I think. Cheers [1] https://en.wikipedia.org/wiki/Color_blindness - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-16 16:42 ` tomas @ 2020-09-16 21:46 ` arthur miller 2020-09-17 19:28 ` Alan Third 0 siblings, 1 reply; 96+ messages in thread From: arthur miller @ 2020-09-16 21:46 UTC (permalink / raw To: tomas@tuxteam.de; +Cc: João Távora, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1357 bytes --] Any logical explanation why females have got that much better deal with colors than guys from the evolution? Sure, I completely agree that faces are better to work with then plain colors. Imaginary framework could have co exist of base-faces and accent-faces instead of base-colors and accent-colors (if this separation is even acceptable). -------- Originalmeddelande -------- Från: tomas@tuxteam.de Datum: 2020-09-16 18:43 (GMT+01:00) Till: Arthur Miller <arthur.miller@live.com> Kopia: João Távora <joaotavora@gmail.com>, emacs-devel <emacs-devel@gnu.org> Ämne: Re: A modern-mode? On Wed, Sep 16, 2020 at 02:40:53PM +0200, Arthur Miller wrote: > João Távora <joaotavora@gmail.com> writes: > > > I just meant the "custom-themes" > > infrastructure should be enough to accommodate enough of > > the proposed "modern-mode". Not sure if it is (as I don't use it). > No, it is not. It lacks unified framework to use as logicla names for > color use; Isn't "face" the better abstraction, anyway? Think blind people. Think color-blind people (up to 8% of the male and 0.5% of the female population of Norther European descent [1]). Conveying semantics via color has to have some fallback, and this meshes well with faces, I think. Cheers [1] https://en.wikipedia.org/wiki/Color_blindness - t [-- Attachment #2: Type: text/html, Size: 2338 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 21:46 ` arthur miller @ 2020-09-17 19:28 ` Alan Third 2020-09-17 19:47 ` arthur miller 0 siblings, 1 reply; 96+ messages in thread From: Alan Third @ 2020-09-17 19:28 UTC (permalink / raw To: arthur miller; +Cc: emacs-devel On Wed, Sep 16, 2020 at 09:46:58PM +0000, arthur miller wrote: > Any logical explanation why females have got that much better deal > with colors than guys from the evolution? The gene for colour blindness is carried on the X chromosome, males only have one copy but females have two, therefore females have two chances to get a "correct" gene. There are some other related effects, like tetrachromacy, and apparently cats with more than two colours of fur are all female for similar reasons. -- Alan Third ^ permalink raw reply [flat|nested] 96+ messages in thread
* RE: A modern-mode? 2020-09-17 19:28 ` Alan Third @ 2020-09-17 19:47 ` arthur miller 0 siblings, 0 replies; 96+ messages in thread From: arthur miller @ 2020-09-17 19:47 UTC (permalink / raw To: Alan Third; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 792 bytes --] That was cool to learn. Thank you! -------- Originalmeddelande -------- Från: Alan Third <alan@idiocy.org> Datum: 2020-09-17 21:28 (GMT+01:00) Till: arthur miller <arthur.miller@live.com> Kopia: emacs-devel <emacs-devel@gnu.org> Ämne: Re: A modern-mode? On Wed, Sep 16, 2020 at 09:46:58PM +0000, arthur miller wrote: > Any logical explanation why females have got that much better deal > with colors than guys from the evolution? The gene for colour blindness is carried on the X chromosome, males only have one copy but females have two, therefore females have two chances to get a "correct" gene. There are some other related effects, like tetrachromacy, and apparently cats with more than two colours of fur are all female for similar reasons. -- Alan Third [-- Attachment #2: Type: text/html, Size: 1493 bytes --] ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: A modern-mode? 2020-09-16 9:48 ` tomas 2020-09-16 9:54 ` João Távora @ 2020-09-16 12:32 ` Arthur Miller 1 sibling, 0 replies; 96+ messages in thread From: Arthur Miller @ 2020-09-16 12:32 UTC (permalink / raw To: tomas; +Cc: emacs-devel <tomas@tuxteam.de> writes: > Those modes are often opinionated (they have to). So it's better > if the mode's opinions align with those of the user. What I have learned by following emacs-dev mail list is that any, feature here is opinionated. > It'll be Emacs's job to provide the bridges and the common base > for all of that (someone in this monster thread quoted X11's > motto of providing "mechanism, not policy": I think this is > - mutatis mutandis - a good guiding principle). Indeed, "mechanism not policy" is one of the the best feature of X11 (along with being a network protocol too). ^ permalink raw reply [flat|nested] 96+ messages in thread
end of thread, other threads:[~2020-09-18 4:50 UTC | newest] Thread overview: 96+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<xjfmu1rrtks.fsf@sdf.org> [not found] ` <<E1kIPmO-0001u5-0m@fencepost.gnu.org> 2020-09-16 14:37 ` A modern-mode? Drew Adams 2020-09-15 14:41 Andrea Corallo via Emacs development discussions. 2020-09-15 14:51 ` Ergus 2020-09-16 0:16 ` Andrea Corallo via Emacs development discussions. 2020-09-15 15:08 ` Stefan Monnier 2020-09-15 15:26 ` Drew Adams 2020-09-15 16:34 ` Teemu Likonen 2020-09-15 18:36 ` Andrea Corallo via Emacs development discussions. 2020-09-15 21:08 ` Antoine Kalmbach 2020-09-16 4:15 ` Teemu Likonen 2020-09-16 7:52 ` Andrea Corallo via Emacs development discussions. 2020-09-15 15:13 ` Drew Adams 2020-09-15 16:31 ` Theodor Thornhill 2020-09-15 15:56 ` Göktuğ Kayaalp 2020-09-15 16:47 ` Gregory Heytings via Emacs development discussions. [not found] ` <a4bc94ca-3130-463a-bd79-3dbffbbce492@default> 2020-09-15 17:11 ` Gregory Heytings via Emacs development discussions. 2020-09-15 17:32 ` Drew Adams 2020-09-15 17:35 ` Drew Adams 2020-09-15 18:47 ` Andrea Corallo via Emacs development discussions. 2020-09-15 20:48 ` Gregory Heytings via Emacs development discussions. 2020-09-16 0:07 ` Andrea Corallo via Emacs development discussions. 2020-09-16 8:58 ` Gregory Heytings via Emacs development discussions. 2020-09-16 9:03 ` Dmitry Gutov 2020-09-16 10:39 ` Göktuğ Kayaalp 2020-09-16 10:47 ` João Távora 2020-09-16 12:20 ` Arthur Miller 2020-09-16 5:14 ` Alfred M. Szmidt 2020-09-16 7:27 ` Andrea Corallo via Emacs development discussions. 2020-09-16 7:36 ` Alfred M. Szmidt 2020-09-16 8:36 ` Alan Third 2020-09-16 14:37 ` Drew Adams 2020-09-16 15:00 ` Arthur Miller 2020-09-16 15:22 ` Thibaut Verron 2020-09-17 3:54 ` Richard Stallman 2020-09-16 10:30 ` Göktuğ Kayaalp 2020-09-16 11:17 ` Alfred M. Szmidt 2020-09-16 14:32 ` Eli Zaretskii 2020-09-16 14:46 ` Andrea Corallo via Emacs development discussions. 2020-09-16 21:53 ` Dmitry Gutov 2020-09-16 15:18 ` Lars Ingebrigtsen 2020-09-16 15:33 ` Andrea Corallo via Emacs development discussions. 2020-09-16 15:46 ` Eli Zaretskii 2020-09-16 15:54 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:08 ` Eli Zaretskii 2020-09-16 16:17 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:28 ` Eli Zaretskii 2020-09-16 16:32 ` Noam Postavsky 2020-09-16 16:45 ` Alfred M. Szmidt 2020-09-16 16:30 ` Alan Third 2020-09-16 16:45 ` Alfred M. Szmidt 2020-09-16 22:11 ` arthur miller 2020-09-16 21:54 ` Dmitry Gutov 2020-09-16 15:18 ` Alfred M. Szmidt 2020-09-16 15:27 ` Andrea Corallo via Emacs development discussions. 2020-09-16 16:45 ` Alfred M. Szmidt 2020-09-17 3:58 ` Richard Stallman 2020-09-17 4:45 ` Alfred M. Szmidt 2020-09-17 9:54 ` Lars Brinkhoff 2020-09-18 4:09 ` Richard Stallman 2020-09-16 16:45 ` tomas 2020-09-16 21:47 ` arthur miller 2020-09-16 18:19 ` Daniel Martín 2020-09-16 18:45 ` Thibaut Verron 2020-09-16 18:53 ` Eli Zaretskii 2020-09-16 20:02 ` Thibaut Verron 2020-09-16 21:36 ` Alan Third 2020-09-17 0:11 ` arthur miller 2020-09-17 19:17 ` Alan Third 2020-09-17 19:43 ` Stefan Monnier 2020-09-17 19:54 ` arthur miller 2020-09-18 4:50 ` Arthur Miller 2020-09-17 3:18 ` Thibaut Verron 2020-09-16 21:48 ` Lars Ingebrigtsen 2020-09-17 3:53 ` Richard Stallman 2020-09-16 8:15 ` Ergus 2020-09-16 7:33 ` Robert Pluim 2020-09-16 8:55 ` tomas 2020-09-16 9:36 ` João Távora 2020-09-16 9:48 ` tomas 2020-09-16 9:54 ` João Távora 2020-09-16 10:20 ` tomas 2020-09-16 10:30 ` João Távora 2020-09-16 10:53 ` tomas 2020-09-16 11:09 ` João Távora 2020-09-16 12:40 ` Arthur Miller 2020-09-16 13:04 ` João Távora 2020-09-16 14:10 ` Arthur Miller 2020-09-16 15:26 ` João Távora 2020-09-16 15:43 ` Thibaut Verron 2020-09-16 15:45 ` João Távora 2020-09-16 14:20 ` Arthur Miller 2020-09-16 16:42 ` tomas 2020-09-16 21:46 ` arthur miller 2020-09-17 19:28 ` Alan Third 2020-09-17 19:47 ` arthur miller 2020-09-16 12:32 ` Arthur Miller
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.