On Sep 12, 2024, at 20:29, Corwin Brust <corwin@bru.st> wrote:
On Thu, Sep 12, 2024 at 12:30 PM Summer Emacs <summeremacs@summerstar.me> wrote:
Hi everyone,
I posted a question in Reddit this morning about having an Emacs newbie info pages on the front of the default Emacs page for complete newbies and first-timers. I know that the splash page already has information links, which are very appreciated, but I think that first time users would be overwhelmed with the information and how to use it.
I had a potentially relatable idea the other day, which I will riskhijacking your (fine) thread to mention (but do feel free todisregard, if you feel I'm over wrong in thinking it could make senseto take on what I suggest in context of what you propose).
Well I said I welcome all suggestions and constructive criticism and input so I’m not going to say no. =)
I have for some time been "thumping the theory" (meaning: occasionally
mentioning in email or on IRC, etc) that we might have taken the wrong
direction, from a long term approach standpoint and not any of the
micro-decisions leading us here, to lump "introductory features"
together with every other change we make to Emacs. This leads us in
some cases, I think, to conceal such features from exactly the users
whom they have been added to serve. It's not a trivial problem,
either to understand the nuances of or define a way forward, even if
one were to completely agree with everything I say.
But I might have a suggestion, as of the other day. I can't recall
seeing it discussed but it's quite possible I missed that; sorry if I
happen to be beating a dead horse. In any case: seeing your email has
me thinking now is the time to mention.
To put things as simply as I can:
1. We (quite rightly) hide significant changes from behind guards
such as configuration settings as a general practice. This minimizes
the noise for regular users of Emacs who would like to stay abreast of
recent development but who do not want to make an endless series of
configuration changes to continue their existing workflows except
where they have introduced desired changes in their configuration.
Well and good.
You’re getting into territory I wanted to avoid with this. The reason why is because I want to add something to Emacs without changing Emacs. I know from a few years of conversation now how contentious the idea is of changing anything core to Emacs. All I want to do is at least start simple. A simple info pages with a visible link. It wouldn’t change Emacs in any way other than adding more to a section of info pages and one line at the top of the welcome screen. I think starting small is the way to go, even if there is a lot of info behind that link divided up in different ways.
2. Meanwhile, we have an increasingly complex set of expectations
which are maintained in terms of the guards, default values for
variables intended for user settings/configuration and functions that
evaluate (have expert knowledge of) these. I don't suggest it is
unmanageable, only that it might be slightly suboptimal for everyone
involved.
Would it make sense to have a `emacs-welcome-new-user' mode which
"collects" configuration defaults appropriate for new users and
provides means to enable (and, perhaps, disable) them en masse?
I imagine this could be done without major change to existing defaults
and still be quite useful to new users. For example, a command line
option, easy to reach bindings perhaps under C-h, menu options,
integration with or button on the spash-screen, etc, off the top of my
head, seem like ways to offer this functionality that are unlikely to
represent any meaningful change to long-time Emacs users.
If we did eventually want to change the way we approach defaults, this
might provide a useful experiment in the direction of grouping
features logically. I leave aside the question of enabling this new
minor mode by default and thus any contribution to a discussion of
whether or not existing users would accept all having to make this
change (given we mostly won't be building 'all this functionality for
new users' for ourselves). I think simply defining the enable and
disable progns or whathaveyou invoked from there seems could provide a
technical direction to explore, which could breaking the cycle of
having to individually (using Anti-NEWS, or whatever) disable each
change we don't happen to like, and free maintainers a little bit from
having to "hide the fun new things". That said, I have no specific
"feature groups" to suggest other than the "new user friendly
defaults" suggestion, which could be at hand in this thread.
Meanwhile, generally, I do think a collection of features (in this
case "for newer users") can be a very powerful concept. In chat, we
often need to point to -Q/-q (or explain the difference) to people
getting started who are asking questions on Emacs IRC channels. This
type of advice, much as reminding people about the existence of the
tutorial or helping someone get started using info (or man) along with
getting friendly with Emacs' fine manual, can be an invaluable part of
some given new user's Emacs starter-kit. In passing, I think it worth
mentioning that programs like Doom provide as an (IMO) important
feature, a logical grouping of features. I'm not suggesting creating
something akin to this, expressly, but that would be a direction to
consider that I suspect could give the results I have in mind.
In summary, I think it would be easy enough to point people (who don't
notice in the documentation) how to find a command line option or
keystrokes to start emacs in "new user mode" (perhaps, implemented as
a minor mode?). By "grouping" evaluation of certain parts of user
context when the minor mode is toggled (or conditioned on whether it
is enabled, some setting it pays attention to to autoenable, etc) we
could create a model for grouping such other functions that "leaves
the code in one place", in that it doesn't require implementing any
logical framework for feature grouping (but could likely be
implemented according to such).
As above: I wouldn’t even know where to begin with such a thing. I like the idea! But I think it would cause years of infighting perhaps and some people would be dead set against it. I wanted to do it this way because: 1) I could help write things for it along with others and 2) It’s really easy to do and would require almost no coding at all - 99% of the work would be writing and editing, and selecting things for examples.
This would not change Emacs in any way, behind the hood or in front. I think it’s the best approach I can imagine for now without having a war erupt. =) The goal of this project would be the following:
Thanks for your note.
And thank you for yours! Again: I’m not against it but it’s not what I wanted to start as a discussion as I figure some people would be against adding any sort of special thing to Emacs or pre-set config. My suggestion would include different configs (for non-devs mostly) and different themes/examples as well as hand holding on how to find the commands they need and how to set up their own config eventually. More than that would be pointed to in the existing info pages (which are excellent but a bit daunting for beginners). My plan is to get them up and running enough so that what *is* in the help files isn’t that daunting anymore. =)
Summer Emacs.
|