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

[solidius4747]

Vào 22:09:49 UTC+7 Thứ ba, ngày 08 tháng bảy năm 2014, Emanuel Berg đã viết:

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

The recent GNU Emacs Manual is more than 600 pages long: 
http://www.gnu.org/software/emacs/manual/pdf/emacs.pdf 

It includes packages like Semantic, EDE, Calc, GUD... (I am using these 
packages myself). That's a lot of features. Certainly, users won't need to 
learn of those to be productive. It's likely that users usually read cover from 
cover, so they will be distracted by unnecessary stuffs not needed at the 
moment. The exported PDF of part 1 is only 43 pages long and part 3 is 83 pages 
long. Certainly mini compared to the actual manual. I also added screencasts to 
demonstrate what Emacs is capable of. I want to ensure the new users that 
learning Emacs worth their time. I also explicitly stated that the official 
Emacs manual is the next place they should look for if they want to get the 
most of Emacs. My manual only provides a starting point.
 
> 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...

MELPA is really useful. It helped me to discover many useful packages and ease 
package management. Before that, I added packages as submodules in my .emacs.d 
git repo. I think once users know MELPA, even if they do not know what they 
want, they will explore the packages, install and play with it - like I did - 
and discover features not available in other editors; for example, Helm, Magit, 
undo-tree...


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

I did provide it in part 3, not to the manual, but encourage new users to 
directly use Emacs for looking up functions and stuffs, as you can see in the 
section "Just enough Emacs Lisp" for each listed function. But probably I will 
provide a link to the function in the official Elisp manual, so they can 
compare and contrast.


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

Yes, I know. That's the route I worked through when I was new to Emacs. But I 
still want new users to be productive with Emacs as possible, with minimal 
Elisp. To be honest, I'm not an expert with Emacs Lisp; I'm still learning (I 
actually want to be proficient with Common Lisp first) and I only have limited 
experience with Racket from some Coursera courses ("Introduction to Systematic 
Design" - which uses the book How to Design Program and "Programming Languages" 
that I wrote a small evaluator for a made up language).

I always encourage users to seek help from the official manual and especially, 
within Emacs itself, in all of my articles. In part 3, I only want to introduce 
enough Emacs Lisp that new users can feel comfortable with using MELPA to add 
package for extending Emacs, rather than taking the hard route, that is 
actually learn and write Elisp. I think, after new users use various Emacs 
packages from the community comfortable, they will see the power of Emacs and 
have an interest in learning Elisp, just like I did. That's why I listed many 
popular and useful packages, one by one in this part, along with how to set up 
the packages properly to start using it. I believe, by repeating adding 
packages and Elisp code configuration, new users will get comfortable with 
Elisp and extending Emacs in general. My goal is to have an interested-in-Emacs 
reader to get what I demonstrated in part 1 in about a month or less.

As for searching and filtering packages using the package manager, I will add 
it.