From: Corwin Brust <corwin@bru.st>
To: summeremacs@summerstar.me
Cc: emacs-devel@gnu.org
Subject: Re: Emacs Newbie Info Pages
Date: Thu, 12 Sep 2024 13:29:40 -0500 [thread overview]
Message-ID: <CAJf-WoSgKhQ73M6-Bn+YyGvSbhJrutCiTTn5M0sc6320FBkF6A@mail.gmail.com> (raw)
In-Reply-To: <EE7D2B70-4778-42B5-B265-8C87995411E6@summerstar.me>
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 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).
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.
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).
The goal of this project would be the following:
>
Thanks for your note.
next prev parent reply other threads:[~2024-09-12 18:29 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 17:30 Emacs Newbie Info Pages Summer Emacs
2024-09-12 18:26 ` Philip Kaludercic
2024-09-12 18:45 ` Summer Emacs
2024-09-12 19:17 ` Philip Kaludercic
2024-09-13 6:40 ` Eli Zaretskii
2024-09-13 7:36 ` Philip Kaludercic
2024-09-13 7:39 ` Summer Emacs
2024-09-13 14:46 ` Juergen Fenn
2024-09-13 12:28 ` Thanos Apollo
2024-09-12 18:29 ` Corwin Brust [this message]
2024-09-12 19:00 ` Summer Emacs
2024-09-13 2:24 ` Suhail Singh
2024-09-17 3:47 ` Richard Stallman
2024-09-17 10:58 ` Summer Emacs
2024-09-17 13:31 ` Eli Zaretskii
2024-09-17 14:12 ` Summer Emacs
2024-09-17 14:48 ` Emanuel Berg
2024-09-17 16:45 ` Summer Emacs
2024-09-18 1:09 ` Emanuel Berg
2024-09-17 15:44 ` Eli Zaretskii
2024-09-17 16:49 ` Summer Emacs
2024-09-17 17:53 ` Eli Zaretskii
2024-09-19 3:51 ` Richard Stallman
2024-09-19 9:45 ` Summer Emacs
2024-09-13 6:38 ` Eli Zaretskii
2024-09-13 7:45 ` Summer Emacs
2024-09-13 10:46 ` Eli Zaretskii
2024-09-13 11:20 ` Summer Emacs
2024-09-13 11:57 ` Eli Zaretskii
2024-09-13 12:09 ` Summer Emacs
2024-09-13 13:31 ` Eli Zaretskii
2024-09-18 8:13 ` Emanuel Berg
2024-09-18 20:02 ` Juergen Fenn
2024-09-20 2:39 ` Emanuel Berg
2024-09-22 12:37 ` Peter Oliver
2024-09-22 14:31 ` Eli Zaretskii
2024-09-13 6:35 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJf-WoSgKhQ73M6-Bn+YyGvSbhJrutCiTTn5M0sc6320FBkF6A@mail.gmail.com \
--to=corwin@bru.st \
--cc=emacs-devel@gnu.org \
--cc=summeremacs@summerstar.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.