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

[Jude DaShiell]

I wasn't even aware of ses until earlier today and found that as a 
built-in looking through m-x list-packages.   Fortunately emacs has that 
available since oleo won't build on this amd K8 athelon I have.  A 
built-in that's coming in the next version of emacs will be eww and for 
those of us on command line level of linux (no g.u.i.) by preference, 
masquerrade mode from what I've read over on the emacspeak list may get 
us better web content from several sites that restrict content just 
because a text browser is in use.  One real useful tool I found with 
emacs that's also built-in is orgmode.  That has spreadsheet capacity, 
but implementation in terms of content of fmtline's to my mind is 
abstruse.

On Tue, 8 Jul 2014, solidius4747@gmail.com wrote:
The forms built-in will probably be very useful but this is probably at an 
intermediate level.


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

jude <jdashiel@shellworld.net>