emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Emacs raison d'etre


From: Philip K.
Subject: Re: GNU Emacs raison d'etre
Date: Sun, 24 May 2020 20:31:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Arthur Miller <address@hidden> writes:

> Yes, indeed,  you are onto something here. It would be nice if there
> were different smaller tutorials, for example one for text, one for file
> managing, one for email etc. I guess everybody could agree with that,
> and probably only reason why it didn't happened yet is because somebody
> actually have to produce those, which is not as trivial as it might
> sound, I guess. There are some floating resources, tutorial-like blog
> posts, some YT content etc. I don't know if Emacs could link to those
> as extra resources etc.

I find this very interesting, the built in tutorial is often seen as
boring, and I remember trying multiple times to get through it, most
after 10%-20%.

What might be interesting is to use child frames to only show what's
necessary, like many other programms do (highlighting what's
interesting, waiting for user interaction, etc.).

But that would require a kind of DSL or pseudo-DSL to "programm" these
interactive tutorials, unless one would want to manually write them out
for every topic. Might look something like this:

        (deftutorial window-managment "Window Managment"
          "A basic tutorial on window managment"
          :estemated-time "3m"
          :difficulty 'easy
          (show "This tutorial introduces the user to window managment")
          (wait)
          (show "Press \\[split-window-below] to split the current window.")
          (expect 'split-window-below)
          (show "Good! Now you can switch to that buffer with
 C-x o runs the \\[other-window].")
          ...)

where the user might later invoke a command like M-x introduce RET, and
choose "Window Managment" from a list of options. On the other hand, a
list-buffers like approach would be better, because the default
completion system can be unintuitive.

Ideally it might even be used by external packages to introduce user to
whatever it has to offer.

-- 
        Philip K.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]