From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: solidius4747@gmail.com Newsgroups: gmane.emacs.help Subject: Re: Emacs Mini Manual (PART 3) - CUSTOMIZING AND EXTENDING EMACS Date: Tue, 8 Jul 2014 09:45:24 -0700 (PDT) Message-ID: References: <5eaf0440-3124-4d89-bd20-ddada9a3db12@googlegroups.com> <87r425qi4t.fsf@debian.uxu> <619ae998-2ce5-428d-bec7-a654427b81d0@googlegroups.com> <87k37nzy2q.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1404838227 24096 80.91.229.3 (8 Jul 2014 16:50:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Jul 2014 16:50:27 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jul 08 18:50:21 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X4Yax-0004Ay-P1 for geh-help-gnu-emacs@m.gmane.org; Tue, 08 Jul 2014 18:50:19 +0200 Original-Received: from localhost ([::1]:56741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4Yax-00029N-FP for geh-help-gnu-emacs@m.gmane.org; Tue, 08 Jul 2014 12:50:19 -0400 X-Received: by 10.66.216.130 with SMTP id oq2mr18044507pac.44.1404837925259; Tue, 08 Jul 2014 09:45:25 -0700 (PDT) X-Received: by 10.50.118.38 with SMTP id kj6mr111452igb.11.1404837925003; Tue, 08 Jul 2014 09:45:25 -0700 (PDT) Original-Path: usenet.stanford.edu!uq10no196935igb.0!news-out.google.com!gf2ni0igb.0!nntp.google.com!uq10no196924igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: <87k37nzy2q.fsf@debian.uxu> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=14.161.13.65; posting-account=c2AWuQoAAACA36o69JJJEmXY5MOg4YNp Original-NNTP-Posting-Host: 14.161.13.65 User-Agent: G2/1.0 Injection-Date: Tue, 08 Jul 2014 16:45:25 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:206318 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:98587 Archived-At: V=C3=A0o 22:09:49 UTC+7 Th=E1=BB=A9 ba, ng=C3=A0y 08 th=C3=A1ng b=E1=BA=A3y= n=C4=83m 2014, Emanuel Berg =C4=91=C3=A3 vi=E1=BA=BFt: > I only have a very old version of the manual - Emacs >=20 > 18, I think - but I read that twice. It wasn't >=20 > difficult to understand but I noticed there were gaps >=20 > in it when I compared how I used Emacs. There was no >=20 > mention of Gnus and I don't remember if RMAIL was >=20 > mentioned, for example, but there were material on the >=20 > message-mode, perhaps to be used between Unix boxes on >=20 > an intranet (?) - of course, if those things weren't >=20 > around then, they couldn't have been included - but as >=20 > for being a reference, I don't remember it being too >=20 > difficult to digest, on the contrary I remember it >=20 > being pleasant to read (big sheets, wide margins, clear >=20 > and normal language, and so on). >=20 >=20 >=20 > > It also does not mention about popular 3rd party >=20 > > packages, and popular package archives like MELPA. >=20 >=20 >=20 > It is not only the manual who is quiet about MELPA. I >=20 > didn't know of it until recently, when I learned about >=20 > it - ironically - on gnu.emacs.sources. >=20 >=20 >=20 > In this book >=20 >=20 >=20 > @Book{cameron, >=20 > author =3D {Cameron and Elliot and Loy and Raymond and Rosenblatt}, >=20 > title =3D {Learning GNU Emacs}, >=20 > publisher =3D {O'Reilly}, >=20 > year =3D 2004, >=20 > ISBN =3D {0-596-00648-9}, >=20 > edition =3D {3rd edition}} >=20 >=20 >=20 > there is a very short chapter on packages and online, >=20 > unofficial repositories, but it doesn't say how to use >=20 > it and it doesn't mention MELPA or even ELPA. >=20 >=20 >=20 > So, all the more reason (in my mind) for you to mention >=20 > it in more detail, or at least to provide a reference >=20 > to "how to broadcast" as that is as vital a part as is >=20 > 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=20 It includes packages like Semantic, EDE, Calc, GUD... (I am using these pac= kages myself). That's a lot of features. Certainly, users won't need to lea= rn of those to be productive. It's likely that users usually read cover fro= m 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 scre= encasts to demonstrate what Emacs is capable of. I want to ensure the new u= sers that learning Emacs worth their time. I also explicitly stated that th= e 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. =20 > Right, that's always the case. However, just knowing >=20 > about MELPA won't have people discovering what they >=20 > want instantly. Of course, first they must know what >=20 > they want, which always takes time, and is natural and >=20 > nothing that we should (could) influence (to any extent >=20 > anyway). But the second part is: finding what they >=20 > want. So how do you search MELPA? And how do you know >=20 > what to search for, if you terminology is different >=20 > from the person who wrote the package? Great things to >=20 > discuss here, as well as to include... MELPA is really useful. It helped me to discover many useful packages and e= ase 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 w= hat they want, they will explore the packages, install and play with it - l= ike I did - and discover features not available in other editors; for examp= le, Helm, Magit, undo-tree... > We should of course never tell anyone to read the >=20 > manual, and especially not the whole Elisp manual :) We >=20 > can post URLs. Best way is for course to do that, but >=20 > also explain how it relates to the particular problem, >=20 > and even support example Elisp. But sometimes there >=20 > isn't the energy, time or will to do that, and then a >=20 > HTTP manual in small chapters is great so you at least >=20 > can give the URL. I did provide it in part 3, not to the manual, but encourage new users to d= irectly use Emacs for looking up functions and stuffs, as you can see in th= e 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 >=20 > your tutorial, yes, but that's not it. They will also >=20 > write Elisp and configure Emacs and use Emacs and the >=20 > online help. They are likely to also come across the >=20 > Emacs manual, the Elisp manual, perhaps even the Gnus >=20 > manual, and of course the EmacsWiki if they happen to >=20 > Google problems (very likely). You yourself said MELPA >=20 > didn't get enough attention (and I agree), so if the >=20 > readers come across it in your book, at some point they >=20 > will ask - "how do I use MELPA in a more advanced way: >=20 > searching, filtering, submitting?" - at that point, if >=20 > the readers first came across it in your book, they >=20 > will instinctively reach for that book. If they read >=20 > about it somewhere else, they'll go for that source, of >=20 > course. But we (you) cannot influence that, can be? >=20 > 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 minim= al Elisp. To be honest, I'm not an expert with Emacs Lisp; I'm still learni= ng (I actually want to be proficient with Common Lisp first) and I only hav= e limited experience with Racket from some Coursera courses ("Introduction = to Systematic Design" - which uses the book How to Design Program and "Prog= ramming Languages" that I wrote a small evaluator for a made up language). I always encourage users to seek help from the official manual and especial= ly, within Emacs itself, in all of my articles. In part 3, I only want to i= ntroduce enough Emacs Lisp that new users can feel comfortable with using M= ELPA 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 vario= us Emacs packages from the community comfortable, they will see the power o= f 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 r= epeating adding packages and Elisp code configuration, new users will get c= omfortable 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 a= dd it.