Re: Emacs Mini Manual (PART 3) - CUSTOMIZING AND EXTENDING EMACS

[Emanuel Berg <embe8573@student.uu.se>]

solidius4747@gmail.com writes:

> As I stated in Part 1 in "Why I wrote this guide"
> section, it is because I feel the Emacs manual is
> designed to be more like a reference material than a
> beginner material.

I only have a very old version of the manual - Emacs
18, I think - but I read that twice. It wasn't
difficult to understand but I noticed there were gaps
in it when I compared how I used Emacs. There was no
mention of Gnus and I don't remember if RMAIL was
mentioned, for example, but there were material on the
message-mode, perhaps to be used between Unix boxes on
an intranet (?) - of course, if those things weren't
around then, they couldn't have been included - but as
for being a reference, I don't remember it being too
difficult to digest, on the contrary I remember it
being pleasant to read (big sheets, wide margins, clear
and normal language, and so on).

> It also does not mention about popular 3rd party
> packages, and popular package archives like MELPA.

It is not only the manual who is quiet about MELPA. I
didn't know of it until recently, when I learned about
it - ironically - on gnu.emacs.sources.

In this book

@Book{cameron,
author = {Cameron and Elliot and Loy and Raymond and Rosenblatt},
title = {Learning GNU Emacs},
publisher = {O'Reilly},
year = 2004,
ISBN = {0-596-00648-9},
edition = {3rd edition}}

there is a very short chapter on packages and online,
unofficial repositories, but it doesn't say how to use
it and it doesn't mention MELPA or even ELPA.

So, all the more reason (in my mind) for you to mention
it in more detail, or at least to provide a reference
to "how to broadcast" as that is as vital a part as is
downloading/installing. It just seems clear to me.

> Where should new users to Emacs find this
> information? They will have to waste time to
> rediscover packages that people used long ago.

Right, that's always the case. However, just knowing
about MELPA won't have people discovering what they
want instantly. Of course, first they must know what
they want, which always takes time, and is natural and
nothing that we should (could) influence (to any extent
anyway). But the second part is: finding what they
want. So how do you search MELPA? And how do you know
what to search for, if you terminology is different
from the person who wrote the package? Great things to
discuss here, as well as to include...

> I want to get productive with Emacs as fast as
> possible.

Everything in time...

> Telling people to read the whole Emacs Lisp manual
> before able to customizing/extending Emacs is likely
> to push them away from Emacs.

We should of course never tell anyone to read the
manual, and especially not the whole Elisp manual :) We
can post URLs. Best way is for course to do that, but
also explain how it relates to the particular problem,
and even support example Elisp. But sometimes there
isn't the energy, time or will to do that, and then a
HTTP manual in small chapters is great so you at least
can give the URL.

> As for submitting code to MELPA, I don't think it's
> necessary to include in the guide, because clearly
> the targeted audience is beginners who just start
> their journey with customizing/extending Emacs. It's
> unlikely they will roll a package on their own after
> finishing the guide anyway.

Well, I disagree here. First, the beginners will use
your tutorial, yes, but that's not it. They will also
write Elisp and configure Emacs and use Emacs and the
online help. They are likely to also come across the
Emacs manual, the Elisp manual, perhaps even the Gnus
manual, and of course the EmacsWiki if they happen to
Google problems (very likely). You yourself said MELPA
didn't get enough attention (and I agree), so if the
readers come across it in your book, at some point they
will ask - "how do I use MELPA in a more advanced way:
searching, filtering, submitting?" - at that point, if
the readers first came across it in your book, they
will instinctively reach for that book. If they read
about it somewhere else, they'll go for that source, of
course. But we (you) cannot influence that, can be?
Better make your own source as complete as possible.

-- 
underground experts united