RE: [External] : Re: [PATCH] Package Installation in Tutorial

[Drew Adams <drew.adams@oracle.com>]

> > How do you propose to know what is most useful
> > to them?
> 
> That's easy: because I was a beginner and I struggled with some of these
> things and because I use other editors as well and try to see what is
> offered elsewhere to try and understand what people tend to expect
> nowadays

Do you see first-time users asking about this often?
If so, where do you see that?

> > Why also package management?  That's my question.
> > Why is that something needed for _starting_ to
> > use Emacs?  By "package management" I guess you
> > mean installing and deleting packages?  Why is
> > that something you need to learn at the outset?
> 
> That's the crux: in my experience, installing a package 
> is the FIRST thing I do.

If that is the crux then I'd expect "How do I install
a package?" to be a FAQ, especially for first-timers.
I don't see that, and I go through user questions daily.

Again, where do you see that "crux" question posed
often by first-timers?

_That's_ the crux: how important is this for first use
of Emacs?  Beyond your saying that it's important, and
that you struggled with this yourself, I don't see
where you've pointed to others struggling with it.

> I used to work with Sublime text, Atom, VS Code. The first thing I
> did was to install a package for the type of file I worked on, whether
> it was JSON, Latex, Python. VSCode even has a popup when you open a file
> asking you to download the appropriate package. I gave JSON as an
> example because there is no built-in "support" but it can be easily
> downloaded.

I think you're saying that for practical use of Emacs
with a given type of file, one needs a 3rd-party pkg.

OK, if true, I can see that a tutorial for how to find
and install relevant packages can be useful.  I still
don't see why it would be the "FIRST" thing someone
trying Emacs would need to learn, but OK.

(Is it really a "struggle" to find this how-to?  Maybe
this belongs in its own tutorial?)

> People expect the editor to be lean and to install packages for the type
> of files they work on - it's part of what they call to setup the
> environment. Emacs is different, it's opposite of lean. But even then,
> there are many things Emacs doesn't have built-in. People will open
> Clojure, Rust, GO files or what have you and stare and ask what do I do
> now. Downloading "clojure-mode" or "rust-mode" or "go-mode" is one
> command away, and that's what I want to people to see in the tutorial.

I understand.  But would it be enough to just say that:
With Emacs, you might want to install a 3rd-party
package for some mode.  And point to the manual for
how-to.  The how-to for "installing" is pretty simple,
no?  It seems pretty clear from (emacs) `Package
Installation'.

The how-to for finding the most relevant package for a
given mode might be more involved, but does that belong
in the tutorial?

> To reiterate, I believe the first thing a user does with a new editor is
> have it ready to work with some file-type of interest which the editor
> might not support built-in, and this is even before configuring anything
> general in the editor. Starting to configure the editor requires some
> commitment, which was not earned yet.

That might be true of some users.  Odd, in that case,
that we don't see much in the way of questions "How
do I install a package?"

> > I'm again asking what _you_ look to, as evidence
> > that installing & deleting packages is something
> > that first-timers really need, as part of our
> > learn-by-doing tutorial.
> 
> I feel like that's not fair. In the short time I've been here I was able
> to see features being implemented which were NOT backed up by any
> external data or polls (discussions here are not included).

Indeed.  IMO there's too often stuff done with little
or no discussion, and often even no proposal.  Don't
take my wish to see proposal, reasons, and discussion
personally.

> Moreover, some updates were motivated by individual bug reports which is a sample
> of one.

+1 again.  Full agreement.  This is too bad.

> Also what's the downside here? having the tutorial too long?

The question should always be, IMO, why make a given
change?  The question isn't "Why not?"  And that's
also the professed policy of the maintainers, AFAIK.

(I can't vouch for whether that rule applies to them
as well.  I'd hope and expect that it does.)

> If you're asking if it's a low hanging fruit, compared to teaching users
> about customization, then it is. I don't see anything wrong with it.

I'm not saying there's anything wrong with it.  My
request was for reasons supporting it.