Re: Emacs Newbie Info Pages

[Summer Emacs <summeremacs@summerstar.me>]

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



> 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 <mailto: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 risk
> hijacking your (fine) thread to mention (but do feel free to
> disregard, if you feel I'm over wrong in thinking it could make sense
> to 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.


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