* Do we need a "Stevens" book? @ 2010-07-28 16:42 Olwe Melwasul 2010-07-28 17:47 ` Andreas Röhler ` (3 more replies) 0 siblings, 4 replies; 14+ messages in thread From: Olwe Melwasul @ 2010-07-28 16:42 UTC (permalink / raw To: help-gnu-emacs I've not gotten very far with this idea; no one seems interested, but I'll try it here anyway... It seems to me that Emacs needs a W. Richard Stevens-style book. As you may know, Stevens wrote the "Advanced Programming in the UNIX(R) Environment" textbook that many of us used in college. Or maybe Emacs needs something along the lines of the many "Linux gnarly/wooly internals" books. Anyway, I would love to see a book that got into the nitty-gritty of Emacs/elisp -- just like you see discussed here every day on the help-gnu-emacs list. Here's an example: comint. How do you effectively use comint? When should you use comint? Okay, I can Google around and find one-off blog discussions here and there about comint; I can read them all; I can get confused; I can kludge something together ... and then find out later that what I've done (as well as bloggers A, B, and C) is really not "best practice" use of comint, i.e., that how I've used comint is overkill or could have been done much simpler with <some other>.el. Wouldn't it be nice to have one go-to source/book that thrashed out comint usage once and for all? Just skimming through all the elisp material (books, Internet, etc.), it seems like a hodge-podge on a continuum between gems and junk just waiting for a clear-speaking Richard Stevens to whip it all into shape. Sure, the "official" texts will get you pretty far, but no way are you ready to be a "best-practices" guru. The printed books seem more like a "cookbook" than a real Stevens-style book. Maybe I'm all wrong, but I think I like what the Racket/PLT people are doing. They seem to be whipping the Scheme hodge-podge into a decent best-practices, best-tools order. Personally I've been admiring Emacs from afar for quite some time. I'm really an Emacs/elisp newbie, but I've got a writing/technical writing background. If what I'm saying strikes a chord, maybe I could be a receiver/collector of a "best-practices-slash-wooly internals" sorta book project. It would be a free/GNU sorta thing of course ... and please don't say "I don't think there'd be enough interest in it." Olwe ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Do we need a "Stevens" book? 2010-07-28 16:42 Do we need a "Stevens" book? Olwe Melwasul @ 2010-07-28 17:47 ` Andreas Röhler 2010-07-28 17:48 ` Richard Riley ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Andreas Röhler @ 2010-07-28 17:47 UTC (permalink / raw To: help-gnu-emacs Am 28.07.2010 18:42, schrieb Olwe Melwasul: > I've not gotten very far with this idea; no one seems interested, but > I'll try it here anyway... > > It seems to me that Emacs needs a W. Richard Stevens-style book. As > you may know, Stevens wrote the "Advanced Programming in the UNIX(R) > Environment" textbook that many of us used in college. Or maybe Emacs > needs something along the lines of the many "Linux gnarly/wooly > internals" books. Anyway, I would love to see a book that got into the > nitty-gritty of Emacs/elisp -- just like you see discussed here every > day on the help-gnu-emacs list. > > Here's an example: comint. How do you effectively use comint? When > should you use comint? Okay, I can Google around and find one-off blog > discussions here and there about comint; I can read them all; I can > get confused; I can kludge something together ... and then find out > later that what I've done (as well as bloggers A, B, and C) is really > not "best practice" use of comint, i.e., that how I've used comint is > overkill or could have been done much simpler with<some other>.el. > Wouldn't it be nice to have one go-to source/book that thrashed out > comint usage once and for all? > > Just skimming through all the elisp material (books, Internet, etc.), > it seems like a hodge-podge on a continuum between gems and junk just > waiting for a clear-speaking Richard Stevens to whip it all into > shape. Sure, the "official" texts will get you pretty far, but no way > are you ready to be a "best-practices" guru. The printed books seem > more like a "cookbook" than a real Stevens-style book. Maybe I'm all > wrong, but I think I like what the Racket/PLT people are doing. They > seem to be whipping the Scheme hodge-podge into a decent > best-practices, best-tools order. > > Personally I've been admiring Emacs from afar for quite some time. I'm > really an Emacs/elisp newbie, but I've got a writing/technical writing > background. If what I'm saying strikes a chord, maybe I could be a > receiver/collector of a "best-practices-slash-wooly internals" sorta > book project. It would be a free/GNU sorta thing of course ... and > please don't say "I don't think there'd be enough interest in it." > > Olwe > > Hi, would welcome such an effort. However, some obstacles are in the way: a basic of Emacs is it's extensibility also for non-programmers. Everyone is encouraged to read Robert Chassell's Emacs Lisp Intro, to try out something. Thats a great pleasure and source of inovation. Naturally, as many hackers are not professional programmers, a kind of wilderness grows out of these efforts. Nothing wrong so far IMHO. After that I'd welcome a kind of mutually code critic, as far as it's not used to intimidate neebies. BTW started a kind of bill-board collecting examples, best practises here: http://repo.or.cz/w/elbb.git Best regards, Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Do we need a "Stevens" book? 2010-07-28 16:42 Do we need a "Stevens" book? Olwe Melwasul 2010-07-28 17:47 ` Andreas Röhler @ 2010-07-28 17:48 ` Richard Riley 2010-07-29 6:40 ` Thien-Thi Nguyen [not found] ` <mailman.0.1280385826.20966.help-gnu-emacs@gnu.org> 3 siblings, 0 replies; 14+ messages in thread From: Richard Riley @ 2010-07-28 17:48 UTC (permalink / raw To: help-gnu-emacs Olwe Melwasul <hercynianforest@gmail.com> writes: > I've not gotten very far with this idea; no one seems interested, but > I'll try it here anyway... > > It seems to me that Emacs needs a W. Richard Stevens-style book. As > you may know, Stevens wrote the "Advanced Programming in the UNIX(R) > Environment" textbook that many of us used in college. Or maybe Emacs > needs something along the lines of the many "Linux gnarly/wooly > internals" books. Anyway, I would love to see a book that got into the > nitty-gritty of Emacs/elisp -- just like you see discussed here every > day on the help-gnu-emacs list. > > Here's an example: comint. How do you effectively use comint? When > should you use comint? Okay, I can Google around and find one-off blog > discussions here and there about comint; I can read them all; I can > get confused; I can kludge something together ... and then find out > later that what I've done (as well as bloggers A, B, and C) is really > not "best practice" use of comint, i.e., that how I've used comint is > overkill or could have been done much simpler with <some other>.el. > Wouldn't it be nice to have one go-to source/book that thrashed out > comint usage once and for all? > > Just skimming through all the elisp material (books, Internet, etc.), > it seems like a hodge-podge on a continuum between gems and junk just > waiting for a clear-speaking Richard Stevens to whip it all into > shape. Sure, the "official" texts will get you pretty far, but no way > are you ready to be a "best-practices" guru. The printed books seem > more like a "cookbook" than a real Stevens-style book. Maybe I'm all > wrong, but I think I like what the Racket/PLT people are doing. They > seem to be whipping the Scheme hodge-podge into a decent > best-practices, best-tools order. > > Personally I've been admiring Emacs from afar for quite some time. I'm > really an Emacs/elisp newbie, but I've got a writing/technical writing > background. If what I'm saying strikes a chord, maybe I could be a > receiver/collector of a "best-practices-slash-wooly internals" sorta > book project. It would be a free/GNU sorta thing of course ... and > please don't say "I don't think there'd be enough interest in it." > > Olwe I believe Sacha Chua is/was writing something along those lines. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Do we need a "Stevens" book? 2010-07-28 16:42 Do we need a "Stevens" book? Olwe Melwasul 2010-07-28 17:47 ` Andreas Röhler 2010-07-28 17:48 ` Richard Riley @ 2010-07-29 6:40 ` Thien-Thi Nguyen 2010-07-30 12:28 ` Thien-Thi Nguyen [not found] ` <mailman.0.1280385826.20966.help-gnu-emacs@gnu.org> 3 siblings, 1 reply; 14+ messages in thread From: Thien-Thi Nguyen @ 2010-07-29 6:40 UTC (permalink / raw To: Olwe Melwasul; +Cc: help-gnu-emacs () Olwe Melwasul <hercynianforest@gmail.com> () Wed, 28 Jul 2010 11:42:14 -0500 Okay, I can Google [...] Why does the search start with Google (and continue with other downstream, non-terminating, whirlpool-shaped, out of date, referenda)? Why not go to the source? The Emacs Lisp manual, the Emacs Lisp code, the Emacs customization facility, the Emacs *scratch* buffer, the Emacs! Personally I've been admiring Emacs from afar for quite some time. Pirsig sez: Quality is the moment of perception. Afar dilutes this. Stop it. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Do we need a "Stevens" book? 2010-07-29 6:40 ` Thien-Thi Nguyen @ 2010-07-30 12:28 ` Thien-Thi Nguyen 2010-07-31 4:47 ` Ken Hori 0 siblings, 1 reply; 14+ messages in thread From: Thien-Thi Nguyen @ 2010-07-30 12:28 UTC (permalink / raw To: Olwe Melwasul; +Cc: help-gnu-emacs () Thien-Thi Nguyen <ttn@gnuvola.org> () Thu, 29 Jul 2010 08:40:46 +0200 Afar dilutes this. Stop it. This was uncalled for. I apologize for the tone. WRT comint, the main message still stands, however. Why don't you take a look at comint.el and post specific questions about what you find? Consider it a shared exercise in (re-)searching a future "Hacking Emacs" book. The discussion on this mailing list (apart from my chilipepper pining headache induced vapidity) could be the start of something. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Do we need a "Stevens" book? 2010-07-30 12:28 ` Thien-Thi Nguyen @ 2010-07-31 4:47 ` Ken Hori 0 siblings, 0 replies; 14+ messages in thread From: Ken Hori @ 2010-07-31 4:47 UTC (permalink / raw To: Thien-Thi Nguyen; +Cc: help-gnu-emacs I am all for any emacs / elisp visualizer. Emacs, at least its documentations, has been devoid of pictures historically. I would love to see it reverted. On Fri, Jul 30, 2010 at 5:28 AM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote: > () Thien-Thi Nguyen <ttn@gnuvola.org> > () Thu, 29 Jul 2010 08:40:46 +0200 > > Afar dilutes this. Stop it. > > This was uncalled for. I apologize for the tone. > > WRT comint, the main message still stands, however. Why don't you take > a look at comint.el and post specific questions about what you find? > Consider it a shared exercise in (re-)searching a future "Hacking Emacs" > book. The discussion on this mailing list (apart from my chilipepper > pining headache induced vapidity) could be the start of something. > > ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <mailman.0.1280385826.20966.help-gnu-emacs@gnu.org>]
* Re: Do we need a "Stevens" book? [not found] ` <mailman.0.1280385826.20966.help-gnu-emacs@gnu.org> @ 2010-07-29 9:50 ` rustom 2010-07-29 10:02 ` Elena 1 sibling, 0 replies; 14+ messages in thread From: rustom @ 2010-07-29 9:50 UTC (permalink / raw To: help-gnu-emacs On Jul 29, 11:40 am, Thien-Thi Nguyen <t...@gnuvola.org> wrote: > () Olwe Melwasul <hercynianfor...@gmail.com> > () Wed, 28 Jul 2010 11:42:14 -0500 > > Okay, I can Google [...] > > Why does the search start with Google (and continue with other > downstream, non-terminating, whirlpool-shaped, out of date, referenda)? > Why not go to the source? The Emacs Lisp manual, the Emacs Lisp code, > the Emacs customization facility, the Emacs *scratch* buffer, the Emacs! Because google searches the world wide web faster and better (usually) than me searching my info dir Unfortunately 'usually' is not 'always' -- hence Olwe's wish is valid > > Personally I've been admiring Emacs from afar for quite some time. > > Pirsig sez: Quality is the moment of perception. > Afar dilutes this. Stop it. My comint.el reads at 3538 lines. Also a $ find ~/local/share/emacs/23.1/lisp -name '*.el.gz' | xargs zcat | wc -l returns 1076048 Spelt out, thats a million lines of elisp only in the default emacs install Now what exactly were you saying? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Do we need a "Stevens" book? [not found] ` <mailman.0.1280385826.20966.help-gnu-emacs@gnu.org> 2010-07-29 9:50 ` rustom @ 2010-07-29 10:02 ` Elena [not found] ` <35282104-5b51-4ba4-8745-4fae239ce0ee@q21g2000prm.googlegroups.com> 1 sibling, 1 reply; 14+ messages in thread From: Elena @ 2010-07-29 10:02 UTC (permalink / raw To: help-gnu-emacs On Jul 29, 6:40 am, Thien-Thi Nguyen <t...@gnuvola.org> wrote: > Why does the search start with Google (and continue with other > downstream, non-terminating, whirlpool-shaped, out of date, referenda)? > Why not go to the source? The Emacs Lisp manual, the Emacs Lisp code, > the Emacs customization facility, the Emacs *scratch* buffer, the Emacs! Surprisingly enough - or not? - it seems few users do read the manuals... I'm guilty of this too (and Emacs' manuals will be my reading on my next vacations). Emacs is too much a complex (not difficult) and powerful software to be used by intuition alone, unlike many softwares we are used to. RTFM! RTFM! RTFM! ... ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <35282104-5b51-4ba4-8745-4fae239ce0ee@q21g2000prm.googlegroups.com>]
* Re: Do we need a "Stevens" book? [not found] ` <35282104-5b51-4ba4-8745-4fae239ce0ee@q21g2000prm.googlegroups.com> @ 2010-07-30 5:29 ` Fren Zeee 2010-07-31 5:47 ` have you read emacs manual cover to cover?; (was Do we need a "Stevens" book?) Xah Lee [not found] ` <63e9cab8-17da-4f1a-b055-e172a3ffeb47@o7g2000prg.googlegroups.com> 2 siblings, 0 replies; 14+ messages in thread From: Fren Zeee @ 2010-07-30 5:29 UTC (permalink / raw To: help-gnu-emacs; +Cc: Fren Zeee On Jul 29, 2:55 pm, Xah Lee <xah...@gmail.com> wrote: > 2010-07-29 > > On Jul 29, 3:02 am, Elena <egarr...@gmail.com> wrote: > > > On Jul 29, 6:40 am, Thien-Thi Nguyen <t...@gnuvola.org> wrote: > > > > Why does the search start with Google (and continue with other > > > downstream, non-terminating, whirlpool-shaped, out of date, referenda)? > > > Why not go to the source? The Emacs Lisp manual, the Emacs Lisp code, > > > the Emacs customization facility, the Emacs *scratch* buffer, the Emacs! > > > Surprisingly enough - or not? - it seems few users do read the > > manuals... I'm guilty of this too (and Emacs' manuals will be my > > reading on my next vacations). > > i always thought of doing this, but just never did. Not the emacs > manual, nor the elisp manual. Over the past 12 years of using emacs > daily, i probably have read only 1/2 of each, counted in a > accumulative way. > > However, i have read cover to cover, word for word, systematically in > a continued setting, several programing lang or software docs/books. > For examples: > > -------------------- > > • Microsoft Word manual i've basically read cover to cover in about > 1992. (stopped using Microsoft Word completely in about 1999) > > -------------------- > • HP-28S Advanced Scientific Calculator manual. (2 books) I read cover > to cover, i think twice, in about 1991. In fact this is how i learned > programing, my first computer language, and the first i mastered. > > • HP-28S Advanced Scientific Calculator > http://xahlee.org/prog/hp28s/hp28s.html > > • Xah Lee's Computing Experience Bio > http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html > > -------------------- > • Mathematica manual (aka the Mathematica Book) i've read 3 times in > separate years, from cover to cover. Note that Mathematica the > software, the subject it deals with, is inherently a order of > magnitude more complex than emacs. (the Mathematica book is over 1k > pages. > e.g.http://www.amazon.com/Mathematica-Book-Fourth-Stephen-Wolfram/dp/0521... > > since early 2000s, the software don't come with the book anymore, and > am not sure if they still produce printed manual at all now... change > with times... > ) > > -------------------- > • The Perl book/manual/“man pages”. I've read basically cover to cover > in about 1998, 1999. (yes, i own the printed book. The printed book > aka The Camel Book is edited version of the man pages. Actually i read > all major perl books in late 2000s. > See: > • Pathetically Elational Regex Language (PERL) > http://xahlee.org/UnixResource_dir/perlr.html > ) > > > Emacs is too much a complex (not > > difficult) and powerful software to be used by intuition alone, unlike > > many softwares we are used to. > > This is simply not true. > > For example, from personal experience, Blender, Second Life both are > more complex than emacs, both for learning it, as well in terms of > effort or complexity of their implementation, as well as inherent > complexity by the nature of what the software do. > > Second Life i've been using for about 3 years now. see: > > • A Photographic Tour of Life in Second Life > http://xahlee.org/sl/index.html > > Blender i started to learn this year... but really too complex... > > I'd say, Blender or Second Life, each, are a order magnitude more > complex and rich than emacs, either you consider simple use aspect, or > deep use aspect such as extension and programing them. > > Also, depending on what you mean by use... for example, if you go into > the programing aspect, then programing Java, C, C++, all are far more > difficult and complex than programing emacs lisp. If you are thinking > of using emacs lisp to program major/minor emacs modes, manipulate > font, creating clients, etc, than, OS GUI platforms such as Mac or > Windows is a order far more complex as well powerful. > > am writing this because i want to dispel certain cult phenomen about > emacs... on the net we often hear some god-like thing about emacs, but > i think if you look at it seriously, usually much of it doesn't mean > anything. > > since i kept thinking about this issue over the years, and in argument > with many old-time emacs users, i thought about the question: if there > is any way, or comment, about emacs that we can justify in claming, > about its complexity, deepth, god-like quality, superiority etc. > > i think to that question we need to be specific. If some claim is made > specific, then it can be easily judged on its veracity. For examples, > the following i think can be reasonably claimed: > > Emacs is most suitable tool for text manipulation tasks that are > complex and not-well-defined and requires interactive human watch. > (See: • Why Emacs is Still so Useful Today http://xahlee.org/emacs/emacs_power_story.html) > > Emacs is most flexible, customizable, user extensible text editor. > > Emacs is the most well known and widely used editor that has a > embedded programing language for text editing. > > Emacs system (emacs+elisp) for text manipulation is probably the most > versatile computer language for text processing. (• Text Processing: > Elisp vs Perl http://xahlee.org/emacs/elisp_text_processing_lang.html > ) > > the above claims are still not so precise, but are items i think can > be reasonably justified. Or can be made more precise, so that the sum > of them can makes sense to say that emacs is quite powerful and > versatile. > > On the other hand, the following i think are in the category of myths: > > • emacs manual is one of the best manual. > > • emacs's keyboard system is most well designed, or most extensible, > or most consistent. > > • emacs keyboard shortcuts and the way they are mapped to emacs's text > manipulation commands, is a very efficient system. (e.g. ratio of > number of commands to call over arbitary text manipulation tasks) > > ... > > there are a lot such myths going around different communities. In perl > community, it's filled to the brim about how perl is this or that > great. In the Common Lisp community, you hear fantastic things about > lisp being the god of all programing languages, while people in this > community almost never mention emacs lisp as a language, and if they > do, it's all sneer and spits and attacks to no ends. In the Scheme > community, likewise you hear how it is the most beautiful, the most > powerful, of all, period. ( See:http://xahlee.org/UnixResource_dir/writ/scheme_fail.htmlhttp://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html > ) In unix community, usually hated by lispers of all walks of life, > you hear how unix is the most versatile, it's “KISS” et al > philosophy's greatness, etc. (see • The Nature of the Unix Philosophyhttp://xahlee.org/UnixResource_dir/writ/unix_phil.html) Likewise, > there's also commercially generated myths, e.g. Java, about how it > solves all cross-platform problems, and how OOP solves the world's > programing problems, etc. > > all these spur from communities that developed certain cult following. > Ultimately, it's more harmful than good. > > What i like to say, is that, yes i love emacs and you love emacs. > However, when praising, be specific on what you like about it, and > avoid cultivating some sense of greatness that's not based on fact or > can't be very meaningful. > > Xah > ∑http://xahlee.org/ > > ☄ If you say, and I take your word on face value, that emacs is so simple - and that you spent so much effort on softwares that you later abandoned like MS Word etc - explain here then, just the C code of eval.c and eval.h and how to add a primitive. A concrete example has to follow the very generalized claims. Make a small demonstrative translation with a metacircular eval and its translation to C side by side. A small diagram to explain the garbage collector operation (Is he using the mark and sweep or another algorithm?). In addition, if Mathematica is Lisp in disguise with some additional code for computer algebra, its not that much more complicated than emacs. ^ permalink raw reply [flat|nested] 14+ messages in thread
* have you read emacs manual cover to cover?; (was Do we need a "Stevens" book?) [not found] ` <35282104-5b51-4ba4-8745-4fae239ce0ee@q21g2000prm.googlegroups.com> 2010-07-30 5:29 ` Fren Zeee @ 2010-07-31 5:47 ` Xah Lee [not found] ` <63e9cab8-17da-4f1a-b055-e172a3ffeb47@o7g2000prg.googlegroups.com> 2 siblings, 0 replies; 14+ messages in thread From: Xah Lee @ 2010-07-31 5:47 UTC (permalink / raw To: help-gnu-emacs cleaned up and extended my previous post. Sentences and ideas made more precise and detailed. • Emacs Idolization: Have You Read the Emacs Manual From Cover to Cover? http://xahlee.org/emacs/emacs_manual_cover_to_cover.html plain text version follows: -------------------------------------------------- Thien-Thi Nguyen wrote: Why does the search start with Google (and continue with other downstream, non-terminating, whirlpool-shaped, out of date, referenda)? Why not go to the source? The Emacs Lisp manual, the Emacs Lisp code, the Emacs customization facility, the Emacs *scratch* buffer, the Emacs! Elena wrote: Surprisingly enough - or not? - it seems few users do read the manuals... I'm guilty of this too (and Emacs' manuals will be my reading on my next vacations). I always thought of doing this, but it never happened. Not the emacs manual, nor the elisp manual. Over the past 12 years of using emacs daily, i have read perhaps 1/3 of the emacs manual and 1/2 elisp manual, counted in a accumulative way. However, i have read cover to cover, word for word, systematically in a continued setting, several programing lang or software manuals. Some of these software are quite more deeper than emacs. Here they are from my recollection. (Note: emacs manual for emacs 22 is 589 pages in printed form, and elisp manual for emacs 21 is 900 pages.) ------------------------- Microsoft Word Manual Microsoft Word manual i think i've read most of it in about 1992. Though, i can't remember i actually read the manual systematically or just become expert by using and scanning it when needed. (i stopped using Microsoft Word about 1998.) ------------------------- HP-28S Advanced Scientific Calculator HP-28S Advanced Scientific Calculator manual. (2 books) I read cover to cover, twice, in about 1991. In fact this is how i learned programing, my first computer language, and the first i mastered. (See: HP-28S Advanced Scientific Calculator and Xah Lee's Computing Experience Bio. ) ------------------------- The Mathematica Book Mathematica manual (aka the Mathematica Book amazon ). I've read it 3 times in separate years, systematically, from cover to cover. This all happened in 1990s. Note that Mathematica the language, the subject it deals with, is inherently a order of magnitude more complex than emacs. The Mathematica book is 1381 pages, 3 kilograms. Heavy enough to hit someone to cause concussion. This 4th edition published in 1999, is the last printed edition. They no longer print it nor come with the software. Note how commercial orgs have adopted changes with the changing industry. ------------------------- The Perl Book The Perl Book. I've read basically cover to cover in about 1998, 1999. (yes, i own the printed book. The printed book aka The Camel Book is edited version of Perl's man pages. Actually i've read all major perl books from 1997 to ~2000. (See: Pathetically Elational Regex Language (PERL)) ------------------------- PHP manual The PHP manual (online). Roughly read reasonably all of it in about a week, in 2005. (scanned in detail on parts that do not require detailed understanding at first.) ------------------------- MySQL manual MySQL manual, online. Read it at the same time i read PHP manual from cover to cover, in 2005. Took me about week or two. I've been working with SQL or variants daily in a day job during 1998 to 2002, but haven't touched it for 2 years. So this reading is to brush up my SQL, as well as first time comprehensive reading of MySQL documentation in particular. ------------------------- Habit of Reading Manuals Reading manuals systematically is kinda a habit, developed from early 1990s as part of a method to study English, and also somewhat a old- fashioned and stubburn mindset of wanting to learn everything from ground up, throughly, and from the original source. Reading manuals, is also how i learned most of my proprograming. Just about any software, language, OS, i used from about 1991 to about early 2000s, i tried to read their manuals systematically from cover to cover, not missing any word. This mentality and its severity, very gradually declined over the past 20 years. Today, i do not take the pain to systematically read their manuals of any new software i have to learn. (if it exists at all; or isn't some haphazard wiki, or random notes by student joe (such as Python's docs. See: Python Documentation Problems).) (other manuals i've read quite a lot for example: vast unix man pages, Apache 1.x, Sun Microsystem's Solaris (3 volumes) (2000), Scheme R4RS (1998), Java, Microsoft's JScript (~2005), Python (~2005), Mac OS X Server official doc from Apple, ... (See: Examples Of Quality Documentation In The Computing Industry) ) ================================= Is Emacs Godsend? Elena wrote: Emacs is too much a complex (not difficult) and powerful software to be used by intuition alone, unlike many softwares we are used to. This is simply not true. For example, from personal experience, Blender, Second Life both are more complex than emacs, both for learning it, as well in terms of effort or complexity of their implementation, as well as inherent complexity by the nature of what these software's purpose. Second Life i've been using for about 3 years now. (See: A Photographic Tour of Life in Second Life.) Blender i started to learn this year... but quite too complex and difficult to get started. I'd say, Blender or Second Life, each, are a order magnitude more complex and rich than emacs. Either considered from simple use aspect, or in-depth use aspect such as coding in their scripting languages to use them fully. (akin to coding emacs lisp.) Also, depending on what you mean by use... for example, if you take perspective of emacs lisp as a language, then, compared to programing Java, C, C++, all are quite deeper than elisp and takes longer to explore before reaching diminishing returns. If you take the perspective of emacs as programing framework for creating applications such as file manager, ftp client, irc client, mp3 manager, etc, then, compared to proper software frameworks such as Mac OS and Windows, both are a order far more complex, of bottomless learning depth, as well far more powerful. ================================= Emacs Cult and Idolization Am writing this because i want to dispel the cult phenomenon surrounding emacs. On the net we often hear some magical qualities about emacs, but i think if you look at it seriously, usually much of it are not scientifically meaningful. Since this issue kept cropping up in my mind over the past ~5 years, in argument with many old-time emacs users, i thought about the question: whether there is any superiority or god-like quality about emacs that we can actually claim and be justified. I think to that question we need to be concrete and specific. If a claim is made concrete, then its veracity can be more easily judged. For examples, the following i think can be reasonably claimed: * Emacs is the most suitable tool for text manipulation tasks that are complex and not-well-defined and requires interactive human watch. (See: Why Emacs is Still so Useful Today.) * Emacs is most flexible, customizable, user extensible text editor. * Emacs is the most well known and widely used editor that has a embedded programing language for text editing. * The Emacs system with Emacs Lisp is probably the most versatile computer language for text processing. (See: Text Processing: Elisp vs Perl.) The above claims are still not so precise, but are items i think can be reasonably justified. Or can be made more precise, so that the sum of them can make sense, and conclude that emacs is quite powerful and versatile. On the other hand, the following i think are in the category of myths: * ? Emacs manual would rank among the top 100 best in today's software. * ? Emacs's keyboard system is among the better designed, in its efficiency, or extensibility, or consistency, or ergonomics. * ? Emacs keyboard shortcuts and the way they are mapped to emacs's text manipulation commands, is a very efficient system. (e.g. ratio of number of commands to call over arbitrary text manipulation tasks) * ? Emacs is among the top one thousand major software today. * ? Emacs and system is among the top one thousand software with respect to the software's power, or versatility, or usefulness. * ? Emacs's implementation considered as a software project today is among the top one thousand software in terms of complexity, size, or achievement. ... There are a lot such myths going around different communities. In perl community, it's filled to the brim about how perl is everything and great. In the Common Lisp community, you hear fantastic things about lisp being the god of all programing languages, while they almost never mention emacs lisp as a language, and if they do, it's all sneer and spits and attacks to no ends. In the Scheme community, likewise you hear how it is the most beautiful, the most elegant, and the most powerful, of all, with its call-cc and tail recursion and whatnot. ( See: Scheme & Failure and Language, Purity, Cult, and Deception ) In unix community, which is usually hated by lispers of any faction, you hear how unix is the most versatile, the greatness of its “Unix philosophy” and “KISS” principles. (See: The Nature of the Unix Philosophy.) Likewise, there's also commercially generated myths, e.g. Java, about how it solves all cross-platform problems, and how OOP solves the world's programing problems, etc. (See: What are OOP's Jargons and Complexities) All these spur from communities that developed certain cult following. Ultimately, it's more harmful than good. What i'd like to say, is that, yes i love emacs and you love emacs. However, when praising, be concrete and specific on what you like about it, and avoid idolization. Because, idolization cultivates cult- like mindset, and that is ultimately damaging. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <63e9cab8-17da-4f1a-b055-e172a3ffeb47@o7g2000prg.googlegroups.com>]
* Re: have you read emacs manual cover to cover?; (was Do we need a "Stevens" book?) [not found] ` <63e9cab8-17da-4f1a-b055-e172a3ffeb47@o7g2000prg.googlegroups.com> @ 2010-08-08 12:02 ` Xah Lee 0 siblings, 0 replies; 14+ messages in thread From: Xah Lee @ 2010-08-08 12:02 UTC (permalink / raw To: help-gnu-emacs On Jul 30, 10:47 pm, Xah Lee <xah...@gmail.com> wrote: > cleaned up and extended my previous post. Sentences and ideas made > more precise and detailed. > > • Emacs Idolization: Have You Read the Emacs Manual From Cover to > Cover? > http://xahlee.org/emacs/emacs_manual_cover_to_cover.html 2010-08-08 I ran into a Chinese blog article on emacs today. It's written in a “Question & Answer” format. Quite funny and well done. It's at: http://yehnan.blogspot.com/2010/06/gnu-emacs-on-windows.html there's a interesting section about emacs documentation. Here's a excerpt: 「 問:這些文件怎麼看起來怪怪的? 答:我覺得Emacs官方寫的文件都很奇怪很囉嗦,因為: 第一,寫的人把用的人都當做初學者,沒有使用編輯器的經驗、甚至沒有使用電腦的經驗。看看這段話: "Files are named units of text which are stored by the operating system for you to retrieve later by name.",拜託,我還需要你教我“檔案”是什麼東西嗎? 第二,寫文件的人似乎停留在1980年代,裡面很多術語都很老舊了,看看這個: " We use the term frame to mean the entire terminal screen or graphical window used by Emacs."、"The main area of the frame, below the tool bar (if one exists) and above the echo area, is called the window.",哇哩咧,你的frame是我的window,你的window又是什麼鬼? 第三,寫文件的人還在緬懷以前的時光,有些在以前算特殊的功能,已經不再特殊了,例如: "You are reading about GNU Emacs, the GNU incarnation of the advanced, self- documenting, customizable, extensible editor Emacs.",啥?self- documenting?哪個編輯器沒有說明文件啊?extensible, customizable?現在很多編輯器多多少少都可以客製化了。 第四,有些功能太過強大,所以解釋起來很麻煩: "You can yank text from the kill ring into any position in a buffer, including a position in a different buffer; the kill ring is shared by all buffers.",yank&kill在這裡等於cut&paste,而kill ring呢?大概是指你cut好幾次後,不會只剩下最後一次 cut的東西,之前的都還在kill ring裡面。 第五,因為Emacs以鍵盤為主,雖然現在有滑鼠可以用了,可是其中心思想還是要求所有的功能動作都要能用鍵盤達到,以至於像“把一段文字圈選”這種以 滑鼠可以輕易達到的功能,手冊要用好多篇幅講解鍵盤的指令。譬如說: "Setting the mark at a position in the text also activates it. When the mark is active, Emacs indicates the extent of the region by highlighting the text within it, using the region face. After certain non-motion commands, including any command that changes the text in the buffer, Emacs automatically deactivates the mark; this turns off the highlighting. ",什麼鬼啊,滑鼠點一點拉一拉就好了啦。 」 -------------------------------------------------- here's my translation -------------------------------------------------- Q: These docs look odd? A: I think emacs's official doc are all odd and verbose, because: (1) The writer thinks users are all beginners, with no experience in using a editor, even no experience in using a computer. Look at this sentence: “Files are named units of text which are stored by the operating system for you to retrieve later by name.”. O please, do i need to be told what's a file? (2) The author seems to have stopped in the 1980s, lots of terms have gone obsolete. Look at these: «We use the term frame to mean the entire terminal screen or graphical window used by Emacs.», «The main area of the frame, below the tool bar (if one exists) and above the echo area, is called the window.» Wow, your “frame” is my “window”, then what gobling is your “window”? (3) Author is nostalgic of the past era; some advanced features are no longer advanced. Example: «You are reading about GNU Emacs, the GNU incarnation of the advanced, self- documenting, customizable, extensible editor Emacs.» huh? “self-documenting”? What editor doesn't have documentation? “extensible, customizable”? Nowadays many editors all can be customized to some degree. (4) Some features are too powerful, so explanation is difficult: «You can yank text from the kill ring into any position in a buffer, including a position in a different buffer; the kill ring is shared by all buffers.» The “yank&kill” here is like “cut&paste”, then what's “kill ring”? Perhaps that means when you cut many times, it won't leave just the last cut text, previous cuts are all still in “kill ring”. (5) Because Emacs uses keyboard as its primary input, although these days we have mouse, but the core design thinking still requires all functionalities to be operable with a keyboard. For example, “select a text”. This can be easily done with a mouse, thus the manual must use lots words to explain how this is done with keyboard. Example: «Setting the mark at a position in the text also activates it. When the mark is active, Emacs indicates the extent of the region by highlighting the text within it, using the region face. After certain non-motion commands, including any command that changes the text in the buffer, Emacs automatically deactivates the mark; this turns off the highlighting.» what the hell, a click here and a drag there with the mouse and be done with it. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <mailman.1.1280335348.2485.help-gnu-emacs@gnu.org>]
* Re: Do we need a "Stevens" book? [not found] <mailman.1.1280335348.2485.help-gnu-emacs@gnu.org> @ 2010-07-28 17:01 ` Pascal J. Bourguignon 2010-07-28 23:15 ` Stefan Monnier 1 sibling, 0 replies; 14+ messages in thread From: Pascal J. Bourguignon @ 2010-07-28 17:01 UTC (permalink / raw To: help-gnu-emacs Olwe Melwasul <hercynianforest@gmail.com> writes: > I've not gotten very far with this idea; no one seems interested, but > I'll try it here anyway... > > It seems to me that Emacs needs a W. Richard Stevens-style book. As > you may know, Stevens wrote the "Advanced Programming in the UNIX(R) > Environment" textbook that many of us used in college. Or maybe Emacs > needs something along the lines of the many "Linux gnarly/wooly > internals" books. Anyway, I would love to see a book that got into the > nitty-gritty of Emacs/elisp -- just like you see discussed here every > day on the help-gnu-emacs list. > > Here's an example: comint. How do you effectively use comint? When > should you use comint? Okay, I can Google around and find one-off blog > discussions here and there about comint; I can read them all; I can > get confused; I can kludge something together ... and then find out > later that what I've done (as well as bloggers A, B, and C) is really > not "best practice" use of comint, i.e., that how I've used comint is > overkill or could have been done much simpler with <some other>.el. > Wouldn't it be nice to have one go-to source/book that thrashed out > comint usage once and for all? > > Just skimming through all the elisp material (books, Internet, etc.), > it seems like a hodge-podge on a continuum between gems and junk just > waiting for a clear-speaking Richard Stevens to whip it all into > shape. Sure, the "official" texts will get you pretty far, but no way > are you ready to be a "best-practices" guru. The printed books seem > more like a "cookbook" than a real Stevens-style book. Maybe I'm all > wrong, but I think I like what the Racket/PLT people are doing. They > seem to be whipping the Scheme hodge-podge into a decent > best-practices, best-tools order. > > Personally I've been admiring Emacs from afar for quite some time. I'm > really an Emacs/elisp newbie, but I've got a writing/technical writing > background. If what I'm saying strikes a chord, maybe I could be a > receiver/collector of a "best-practices-slash-wooly internals" sorta > book project. It would be a free/GNU sorta thing of course ... and > please don't say "I don't think there'd be enough interest in it." It could be an "Olwe Melwasul" book. It would be interesting if you could indeed make it pedagogical and compelling enough so that more students want to use and learn emacs instead of vi. -- __Pascal Bourguignon__ http://www.informatimago.com/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Do we need a "Stevens" book? [not found] <mailman.1.1280335348.2485.help-gnu-emacs@gnu.org> 2010-07-28 17:01 ` Do we need a "Stevens" book? Pascal J. Bourguignon @ 2010-07-28 23:15 ` Stefan Monnier 2010-08-01 17:07 ` Joseph Brenner 1 sibling, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2010-07-28 23:15 UTC (permalink / raw To: help-gnu-emacs > Personally I've been admiring Emacs from afar for quite some time. I'm > really an Emacs/elisp newbie, but I've got a writing/technical writing > background. If what I'm saying strikes a chord, maybe I could be a > receiver/collector of a "best-practices-slash-wooly internals" sorta > book project. It would be a free/GNU sorta thing of course ... and > please don't say "I don't think there'd be enough interest in it." That would be welcome, yes (he said, after (and probably before as well) years of cleaning up messy code). Maybe a good way to do that is to try and get experienced Emacsers to do the effort of recording all/some of the "cleanup" they perform (as patches). Then later on, someone can go through those patches and try and extract principles from them. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Do we need a "Stevens" book? 2010-07-28 23:15 ` Stefan Monnier @ 2010-08-01 17:07 ` Joseph Brenner 0 siblings, 0 replies; 14+ messages in thread From: Joseph Brenner @ 2010-08-01 17:07 UTC (permalink / raw To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Personally I've been admiring Emacs from afar for quite some time. I'm >> really an Emacs/elisp newbie, but I've got a writing/technical writing >> background. If what I'm saying strikes a chord, maybe I could be a >> receiver/collector of a "best-practices-slash-wooly internals" sorta >> book project. It would be a free/GNU sorta thing of course ... and >> please don't say "I don't think there'd be enough interest in it." > > That would be welcome, yes (he said, after (and probably before as well) > years of cleaning up messy code). > > Maybe a good way to do that is to try and get experienced Emacsers to do > the effort of recording all/some of the "cleanup" they perform (as > patches). Then later on, someone can go through those patches and try > and extract principles from them. Sounds good, of course. A page at the emacswiki? I can think of an even simpler step that would be useful: Make a list of files in the code base that are already cleaned up, that you feel are good examples of the best practice in coding. Possibly this could just be a page up at the emacswiki, too. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-08-08 12:02 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-28 16:42 Do we need a "Stevens" book? Olwe Melwasul 2010-07-28 17:47 ` Andreas Röhler 2010-07-28 17:48 ` Richard Riley 2010-07-29 6:40 ` Thien-Thi Nguyen 2010-07-30 12:28 ` Thien-Thi Nguyen 2010-07-31 4:47 ` Ken Hori [not found] ` <mailman.0.1280385826.20966.help-gnu-emacs@gnu.org> 2010-07-29 9:50 ` rustom 2010-07-29 10:02 ` Elena [not found] ` <35282104-5b51-4ba4-8745-4fae239ce0ee@q21g2000prm.googlegroups.com> 2010-07-30 5:29 ` Fren Zeee 2010-07-31 5:47 ` have you read emacs manual cover to cover?; (was Do we need a "Stevens" book?) Xah Lee [not found] ` <63e9cab8-17da-4f1a-b055-e172a3ffeb47@o7g2000prg.googlegroups.com> 2010-08-08 12:02 ` Xah Lee [not found] <mailman.1.1280335348.2485.help-gnu-emacs@gnu.org> 2010-07-28 17:01 ` Do we need a "Stevens" book? Pascal J. Bourguignon 2010-07-28 23:15 ` Stefan Monnier 2010-08-01 17:07 ` Joseph Brenner
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.