Re: "Why is emacs so square?"

Re: "Why is emacs so square?"

[ndame]

> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.

If the cursor keys work out of the box then the tutorial should
begin with features which can be used without learning new cursor keys,
demonstrating something which emacs does well or better than other
tools. Is there such a thing? Or does learning emacs mostly pay off
for the advanced user? I can't think of a feature right know where
emacs shines for the casual user.

C-v and stuff are advanced topics IMO which pay off mostly in the long
run, not at the beginning, they could be shown in an advanced section
of the tutorial later.

And for keybindings there is no real need to switch to emacs, because,
for example, vscode can also have emacs keys:

https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx


So some feature should be found which can be shown for the casual user at the beginning
of the tutorial which may convince the user that emacs is worth the effort.

IMO  starting with C-v, etc. keys just puts off must users who casually try emacs.

Re: "Why is emacs so square?"

[조성빈]

2020. 4. 25. 오전 1:39, ndame <ndame@protonmail.com> 작성:

>> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.
> 
> If the cursor keys work out of the box then the tutorial should
> begin with features which can be used without learning new cursor keys,
> demonstrating something which emacs does well or better than other
> tools.

Yeah, Emacs should not position it as an obscure editor that only gurus use. 

> Is there such a thing? Or does learning emacs mostly pay off
> for the advanced user? I can't think of a feature right know where
> emacs shines for the casual user.

Org mode, magit, helm comes to my mind.
Programmability should also be mentioned — one should show a step-by-step tutorial that adds a new interactive function invokable by a keybinding.

> C-v and stuff are advanced topics IMO which pay off mostly in the long
> run, not at the beginning, they could be shown in an advanced section
> of the tutorial later.
> 
> And for keybindings there is no real need to switch to emacs, because,
> for example, vscode can also have emacs keys:
> 
> https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx
> 
> 
> So some feature should be found which can be shown for the casual user at the beginning
> of the tutorial which may convince the user that emacs is worth the effort.
> 
> IMO  starting with C-v, etc. keys just puts off must users who casually try emacs.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 20:57, 조성빈 wrote:
> Programmability should also be mentioned

As well as, specifically, that you can easily change Emacs's looks and 
behavior at runtime by evaluating code in *scratch*. Which allows for 
quick iterative development.

I know of no other mainstream editors that support this.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Sat, 25 Apr 2020 02:57:17 +0900
> 
> 2020. 4. 25. 오전 1:39, ndame <ndame@protonmail.com> 작성:
> 
> >> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.
> > 
> > If the cursor keys work out of the box then the tutorial should
> > begin with features which can be used without learning new cursor keys,
> > demonstrating something which emacs does well or better than other
> > tools.
> 
> Yeah, Emacs should not position it as an obscure editor that only gurus use. 
> 
> > Is there such a thing? Or does learning emacs mostly pay off
> > for the advanced user? I can't think of a feature right know where
> > emacs shines for the casual user.
> 
> Org mode, magit, helm comes to my mind.
> Programmability should also be mentioned — one should show a step-by-step tutorial that adds a new interactive function invokable by a keybinding.

A tutorial is not for "selling" Emacs.  It's a good idea to write such
a "sales" document, but it would be a separate document.

A tutorial is supposed to teach the users how to use Emacs, so it
should indeed start from the basics.  Whether those basics should or
shouldn't begin with cursor motion is a matter of opinion, but it
would be strange to see an Emacs tutorial that would begin by showing
how to enter and use Org, Magit, Helm, and other similar packages.  I
challenge you to even write about these features without mentioning
"buffer", "window", "mode line", and other basics of the Emacs UI.
How can you talk about these without first saying something about what
they are, what they show, how they can be used, etc.?

RE: "Why is emacs so square?"

[Drew Adams]

> A tutorial is not for "selling" Emacs.  It's a good
> idea to write such a "sales" document, but it would
> be a separate document.

+1

Re: "Why is emacs so square?"

[chad]

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

Several years ago, someone put together "A guided tour of Emacs":

  https://www.gnu.org/software/emacs/tour/

I suspect what is being discussed here is a new version of that document,
possibly included directly in the build and/or linked from the default
startup screen.

~Chad

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

Re: "Why is emacs so square?"

[ndame]

> Several years ago, someone put together "A guided tour of Emacs":
>
>   https://www.gnu.org/software/emacs/tour/
>
> I suspect what is being discussed here is a new version of that document, possibly included directly in the build and/or linked from the default startup screen.
>

Pretty nice and well put together. It really should be linked from
the startup screen.

For the record, here's a page with similar purpose for vscode.
It's useful to see what the competition offers. Just scroll
down and read the titles:

https://vscodecandothat.com/

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 24 Apr 2020 18:53:56 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
>  조성빈 <pcr910303@icloud.com>,
>  EMACS development team <emacs-devel@gnu.org>
> 
> Pretty nice and well put together. It really should be linked from
> the startup screen.

It's already there.

Re: "Why is emacs so square?"

[chad]

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

On Fri, Apr 24, 2020 at 12:25 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Fri, 24 Apr 2020 18:53:56 +0000
> > From: ndame <ndame@protonmail.com>
> > Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
> >  조성빈 <pcr910303@icloud.com>,
> >  EMACS development team <emacs-devel@gnu.org>
> >
> > Pretty nice and well put together. It really should be linked from
> > the startup screen.
>
> It's already there.
>

I checked again with emacs -q on a fresh build from this morning. The
default starting text is below, but it doesn't seem to include it. I also
checked the default Help menu, where I thought that it had once been
included, but didn't find it there, either. Maybe I got removed at some
point?

Welcome to GNU Emacs, one component of the GNU/Linux operating system.
> To follow a link, click Mouse-1 on it, or move to it and type RET.
> To quit a partially entered command, type Control-g.
>


Important Help menu items:
> Emacs Tutorial Learn basic Emacs keystroke commands
> Read the Emacs Manual View the Emacs manual using Info
> (Non)Warranty GNU Emacs comes with ABSOLUTELY NO WARRANTY
> Copying Conditions Conditions for redistributing and changing Emacs
> More Manuals / Ordering Manuals  How to order printed manuals from the FSF
>


Useful tasks:
> Visit New File Specify a new file’s name, to edit the file
> Open Home Directory Open your home directory, to operate on its files
> Customize Startup Change initialization settings including this screen
>


GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo
> version 1.16.0)
>  of 2020-04-24
> Copyright (C) 2020 Free Software Foundation, Inc.
>

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Fri, 24 Apr 2020 15:52:04 -0700
> Cc: ndame <ndame@protonmail.com>, Drew Adams <drew.adams@oracle.com>, 
> 	조성빈 <pcr910303@icloud.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
>  > Pretty nice and well put together. It really should be linked from
>  > the startup screen.
> 
>  It's already there.
> 
> I checked again with emacs -q on a fresh build from this morning. The default starting text is below, but it
> doesn't seem to include it. I also checked the default Help menu, where I thought that it had once been
> included, but didn't find it there, either. Maybe I got removed at some point?

No, it was not removed.  It's still there, both in Emacs 27 and on
master.  But we have several different variants of the startup screen,
and what gets actually displayed depends on how you invoke Emacs and
on Emacs's capabilities in the session you started.  So how did you
start Emacs (from the shell prompt, from some icon, from some
service), and what kind of features do you have in that build?

Alternatively, just read the code in startup.el and try to figure out
why you don't have that displayed in your case.  It usually means you
lack some capability, but of course there could be some bug as well.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 21:42, chad wrote:
> Several years ago, someone put together "A guided tour of Emacs":
> 
> https://www.gnu.org/software/emacs/tour/
> 
> I suspect what is being discussed here is a new version of that 
> document, possibly included directly in the build and/or linked from the 
> default startup screen.

Thanks for the link! Probably, yes.

A heavily updated and reorganized new version.

Re: "Why is emacs so square?"

[ndame]

> Several years ago, someone put together "A guided tour of Emacs":
>
>   https://www.gnu.org/software/emacs/tour/
>

Also, it's much more pleasant looking than the built-in tutorial
which is plain text. I wonder why the tutorial looks so barebones.
Why doesn't it use colors, fonts, formatting?

There should be some tutorial-presentation-mode which is turned on
in the tutorial buffer by default and spices up it a bit by adding
text properties.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 24 Apr 2020 19:22:39 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>, 조성빈 <pcr910303@icloud.com>, EMACS development team <emacs-devel@gnu.org>
> 
> Also, it's much more pleasant looking than the built-in tutorial
> which is plain text. I wonder why the tutorial looks so barebones.
> Why doesn't it use colors, fonts, formatting?
> 
> There should be some tutorial-presentation-mode which is turned on
> in the tutorial buffer by default and spices up it a bit by adding
> text properties.

We have enriched-mode, if someone wants to add colors to the tutorial.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 21:10, Eli Zaretskii wrote:
> A tutorial is not for "selling" Emacs.

We should probably call it the "movement tutorial", or something like 
that. And make it come later in the introduction.

> how to enter and use Org, Magit, Helm, and other similar packages.  I
> challenge you to even write about these features without mentioning
> "buffer", "window", "mode line", and other basics of the Emacs UI.

All of these can be introduced much quicker than a 12-page document. And 
the user doesn't need to know *how* to do stuff before they can learn 
about the things Emacs can do.

And at least for Magit and Helm, it's perfectly possible to describe 
their selling points without first introducing what "buffers" and "mode 
line" are. Maybe even windows.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, ndame@protonmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 24 Apr 2020 21:40:55 +0300
> 
> > how to enter and use Org, Magit, Helm, and other similar packages.  I
> > challenge you to even write about these features without mentioning
> > "buffer", "window", "mode line", and other basics of the Emacs UI.
> 
> All of these can be introduced much quicker than a 12-page document.

Maybe it can, maybe it can't.  I encourage you (or someone else) to
show such a variant of the introductory text, then we'd have something
to talk about, including comparing it with what we have now.

> And at least for Magit and Helm, it's perfectly possible to describe 
> their selling points without first introducing what "buffers" and "mode 
> line" are. Maybe even windows.

Once again, "selling" is a different document.  Describing how to use
these feature without the basics could work for those who already know
the basics, but not for those who don't.  Maybe you assume that people
who read the tutorial already know the basics.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 22:22, Eli Zaretskii wrote:

>> All of these can be introduced much quicker than a 12-page document.
> 
> Maybe it can, maybe it can't.  I encourage you (or someone else) to
> show such a variant of the introductory text, then we'd have something
> to talk about, including comparing it with what we have now.

Guess it's going on my list. But if anyone starts working on the new 
version, I have a few suggestions, please hit me up.

>> And at least for Magit and Helm, it's perfectly possible to describe
>> their selling points without first introducing what "buffers" and "mode
>> line" are. Maybe even windows.
> 
> Once again, "selling" is a different document.  Describing how to use
> these feature without the basics could work for those who already know
> the basics, but not for those who don't.  Maybe you assume that people
> who read the tutorial already know the basics.

"Selling" happens first. Then the new user has more motivation to 
actually learn stuff in detail.

Re: "Why is emacs so square?"

[ndame]

>
> > Is there such a thing? Or does learning emacs mostly pay off
> > for the advanced user? I can't think of a feature right know where
> > emacs shines for the casual user.
>
> Org mode, magit, helm comes to my mind.


Orgmode is included, but helm and magit are in melpa. Emacs should feature
packages which are accessible for the new user without tinkering. Though,
if the newbie.el which can setup a beginner friendly environment if emacs
is started without config is allowed to add melpa to the package list and
install helm/magit automatically then it's ok, because then it is instantly
available  for the new user.

BTW, helm. Maybe the veterans don't recognize it, but the default emacs completion
is extremely clunky, especially if one comes from other modern tools.

A user accustomed to modern tools expects something like this:

https://resources.jetbrains.com/help/img/idea/2020.1/find_action_dialog.png

A vertical list which is instantly filtered as you type.

Compared to this the default completion is hoplessly old fashioned with its
multicolumn text display and having to press for TAB for the results.

Icomplete is a step in the right direction. The above mentioned newbie.el
should set it up instead of the default completion.

Though, it's a single line displaying completions, a vertical display
could be better, especially if the entries are longer.

And someone did it already:

https://github.com/oantolin/icomplete-vertical

Icomplete-vertical should be adopted into the core as an option and this
is how completion should be set up for newbies.

It's still not as good looking as the one on my first link, but it's
almost there. It's vertical, it gives you instant results, so it's much
closer to completion provided by modern tools (Idea, VsCode, etc.) than
the default one.

Re: "Why is emacs so square?"

[Yuan Fu]

> On Apr 25, 2020, at 12:28 PM, ndame <ndame@protonmail.com> wrote:
> 
>> 
>>> Is there such a thing? Or does learning emacs mostly pay off
>>> for the advanced user? I can't think of a feature right know where
>>> emacs shines for the casual user.
>> 
>> Org mode, magit, helm comes to my mind.
> 
> 
> Orgmode is included, but helm and magit are in melpa. Emacs should feature
> packages which are accessible for the new user without tinkering. Though,
> if the newbie.el which can setup a beginner friendly environment if emacs
> is started without config is allowed to add melpa to the package list and
> install helm/magit automatically then it's ok, because then it is instantly
> available  for the new user.
> 
> BTW, helm. Maybe the veterans don't recognize it, but the default emacs completion
> is extremely clunky, especially if one comes from other modern tools.
> 
> A user accustomed to modern tools expects something like this:
> 
> https://resources.jetbrains.com/help/img/idea/2020.1/find_action_dialog.png
> 
> A vertical list which is instantly filtered as you type.
> 
> Compared to this the default completion is hoplessly old fashioned with its
> multicolumn text display and having to press for TAB for the results.
> 
> Icomplete is a step in the right direction. The above mentioned newbie.el
> should set it up instead of the default completion.
> 
> Though, it's a single line displaying completions, a vertical display
> could be better, especially if the entries are longer.
> 
> And someone did it already:
> 
> https://github.com/oantolin/icomplete-vertical
> 
> Icomplete-vertical should be adopted into the core as an option and this
> is how completion should be set up for newbies.
> 
> It's still not as good looking as the one on my first link, but it's
> almost there. It's vertical, it gives you instant results, so it's much
> closer to completion provided by modern tools (Idea, VsCode, etc.) than
> the default one.
> 


Thanks for sharing! I tried to use icomplete with “\n” separator, but encountered the problem that this package aims to solve. This should definitely be included as bugfix.

Yuan

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 25.04.2020 23:45, Yuan Fu wrote:

>> Though, it's a single line displaying completions, a vertical display
>> could be better, especially if the entries are longer.
>>
>> And someone did it already:
>>
>> https://github.com/oantolin/icomplete-vertical
>>
>> Icomplete-vertical should be adopted into the core as an option and this
>> is how completion should be set up for newbies.
>>
>> It's still not as good looking as the one on my first link, but it's
>> almost there. It's vertical, it gives you instant results, so it's much
>> closer to completion provided by modern tools (Idea, VsCode, etc.) than
>> the default one.
>>
> 
> 
> Thanks for sharing! I tried to use icomplete with “\n” separator, but encountered the problem that this package aims to solve. This should definitely be included as bugfix.

And it's definitely a very good step.

It would be even better if it could work with any of the packages that 
move minibuffer into a childframe. Unfortunately, the combination seems 
broken one way or another, probably because icomplete-vertical has to 
rely on a hack to get the right behavior.

E.g. with https://github.com/honmaple/emacs-maple-minibuffer I get:

Debugger entered--Lisp error: (error "Cannot resize a minibuffer-only 
frame")
   resize-mini-window-internal(#<window 6 on  *Minibuf-1*>)
   window--resize-mini-window(#<window 6 on  *Minibuf-1*> 36)
   enlarge-window(1)
   icomplete-vertical-minibuffer-setup()
   run-hooks(icomplete-minibuffer-setup-hook)
   icomplete-minibuffer-setup()

icomplete-vertical in child frame (was: "Why is emacs so square?")

[Protesilaos Stavrou]

Dmitry Gutov <dgutov@yandex.ru> [2020-04-27, 02:15 +0300]:

>>> https://github.com/oantolin/icomplete-vertical
>>>
>>> Icomplete-vertical should be adopted into the core as an option and this
>>> is how completion should be set up for newbies.
>>>
>> 
>> Thanks for sharing! I tried to use icomplete with “\n” separator, but
>> encountered the problem that this package aims to solve. This should
>> definitely be included as bugfix.
>
> And it's definitely a very good step.
>
> It would be even better if it could work with any of the packages that
> move minibuffer into a childframe. Unfortunately, the combination seems 
> broken one way or another, probably because icomplete-vertical has to
> rely on a hack to get the right behavior.
>
> E.g. with https://github.com/honmaple/emacs-maple-minibuffer I get:
>
> Debugger entered--Lisp error: (error "Cannot resize a minibuffer-only
> frame")
>   resize-mini-window-internal(#<window 6 on  *Minibuf-1*>)
>   window--resize-mini-window(#<window 6 on  *Minibuf-1*> 36)
>   enlarge-window(1)
>   icomplete-vertical-minibuffer-setup()
>   run-hooks(icomplete-minibuffer-setup-hook)
>   icomplete-minibuffer-setup()

The child frame combination looks promising!  Have you considered
reporting your issue to the icomplete-vertical developer?

I volunteer to do some testing, if necessary.


-- 
Protesilaos Stavrou
protesilaos.com

Re: icomplete-vertical in child frame

[Dmitry Gutov]

On 27.04.2020 22:10, Protesilaos Stavrou wrote:
> The child frame combination looks promising!  Have you considered
> reporting your issue to the icomplete-vertical developer?

I didn't, so far. But the author is psychic apparently, since he fixed 
this very problem today: 
https://github.com/oantolin/icomplete-vertical/commit/f737bc8117326469a15747ed53f43d39eba2a9dc

> I volunteer to do some testing, if necessary.

Testing, reporting bugs, and urging the author of maple-minibuffer to 
publish to ELPA (or at least MELPA) would all help.

I haven't properly switched to icomplete from ido myself yet, so others 
are in better positions to contribute.

Re: icomplete-vertical in child frame

[Protesilaos Stavrou]

Dmitry Gutov <dgutov@yandex.ru> [2020-04-28, 03:51 +0300]:

> On 27.04.2020 22:10, Protesilaos Stavrou wrote:
>> The child frame combination looks promising!  Have you considered
>> reporting your issue to the icomplete-vertical developer?
>
> I didn't, so far. But the author is psychic apparently, since he fixed
> this very problem today:
> https://github.com/oantolin/icomplete-vertical/commit/f737bc8117326469a15747ed53f43d39eba2a9dc

News travel fast!

The dev of icomplete-vertical also maintains another useful package that
offers out-of-order completion:

https://github.com/oantolin/orderless

It works well with icomplete.

>> I volunteer to do some testing, if necessary.
>
> Testing, reporting bugs, and urging the author of maple-minibuffer to
> publish to ELPA (or at least MELPA) would all help.

I will start using maple-minibuffer today and try to contribute as best
I can.


--
Protesilaos Stavrou
protesilaos.com

Re: icomplete-vertical in child frame

[ndame]

>
> The dev of icomplete-vertical also maintains another useful package that
> offers out-of-order completion:
>
> https://github.com/oantolin/orderless

This should be added to core emacs as an optional completion style. Orderless matching
is quite useful and it's been provided for years by Helm, etc.

If popup completions could also be added to elpa then emacs could have a
completion system which is comparable in function and appearance to the ones
modern tools have:

https://github.com/honmaple/emacs-maple-minibuffer

screenshot:

https://raw.githubusercontent.com/honmaple/emacs-maple-minibuffer/master/screenshot/example.gif

Re: icomplete-vertical in child frame

[Dmitry Gutov]

On 28.04.2020 09:23, ndame wrote:
> This should be added to core emacs as an optional completion style. Orderless matching
> is quite useful and it's been provided for years by Helm, etc.

Would you like to be our liaison and request the author contributes the 
package in ELPA? :-)

Re: icomplete-vertical in child frame

[ndame]

>
> Would you like to be our liaison and request the author contributes the
> package in ELPA? :-)

That's no problem, the author wrote somewhere he wanted to add this code
to emacs when he had the time. The problem may be that this algorithm uses
space separated words for matching the candidates and AFAIK standard emacs
completion binds space to some complete function, so this binding clashes
with the algorithm and needs to be removed in order for this completion
style to work.

Re: icomplete-vertical in child frame

[Dmitry Gutov]

On 28.04.2020 17:22, ndame wrote:
> The problem may be that this algorithm uses
> space separated words for matching the candidates and AFAIK standard emacs
> completion binds space to some complete function

See https://github.com/oantolin/orderless#company.

I'm all for removing the standard SPC binding, but there have been some 
voices against. You can file a bug report for that, though.

Re: icomplete-vertical in child frame

[Richard Stallman]

[[[ 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. ]]]

  > Would you like to be our liaison and request the author contributes the 
  > package in ELPA? :-)

Those who wish to do that job, please write to me.
I can explain the work that is needed.

Would someone please tell me what Helm does.

-- 
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)

Re: "Why is emacs so square?"

[Richard Stallman]

[[[ 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. ]]]

  > > If the cursor keys work out of the box then the tutorial should
  > > begin with features which can be used without learning new cursor keys,
  > > demonstrating something which emacs does well or better than other
  > > tools.

I used to think it was important to teach Emacs cursor motion
character because they are needed to edit efficiently.  But if that
is a big discouragement to using the tutorial, let's try it another way.

  > Org mode, magit, helm comes to my mind.

"Org mode", as currently conceptualized (a single thing), is not
suitable to teach to beginners.  If we reconceptualize it as several
task-specific features, some of them may be useful to teach to
beginners.

Magit is not part of Emacs.  I would like to include it in Emacs.  A
year ago, its developer agreed to cooperate with getting the copyright
assignments; but last January, after I found a volunteer to do the
work of arranging this with contributors, the developer did not
respond.

Has anyone been in touch with him since then?  It would be very good
to get this moving.

I don't know what Helm's situation is (or what it does), but whether
describing it in Emacs is an option to consider depends on that
situation.

As a general matter, it is a lot more work to describe something with
a learn-by-doing tutorial than to describe it in a manual.  The number
of topics we can teach in the tutorial is thus limited.  The existing
tutorial does not talk about _any_ special purpose subsystems, not
even Dired, and I think it how it should be.

I think that people who reach the stage of starting using Dired
already know enough that they don't need a learn-by-doing tutorial to
learn it, and they might on the contrary find it annoyingly slow as a
way to learn.  That must go double for Magit.  The best way to tell
people how to use features like that is with ordinary manuals.

-- 
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)