Hacker News new | comments | show | ask | jobs | submit login

Are you suggesting that it is impossible to embody your explanatory ideas in 'cheat sheet' format? If so, that rather renders your objections to the original article moot!

Do all introduction texts need to be in cheat sheet format? Or is there room for an introduction that is a few pages long, but follows a different format than most other few-page-long introductions?

I'm no expert but I would say there is always room for a different approach. Why not draft up a rough idea and post it here?

Sorry to enter so late but: the reason he will not do it seems to be "that does not fit with my way either of seeing it or of explaining it". I tend to agree with him on that.

I guess learning emacs requires some will to learn the environment and this implies reading text.

As for cheat-sheets there must be hundreds. If all you want is basic editing, jus anyone including save, open, quit and search must be sufficient.

The practical reason is that learning Emacs is currently a long term project, and the serious study won't begin until I get around to buying a hard copy manual. I know my learning style. It's depth first. I'm bookish.

So, I'm developing an outline - a sketch of what Emacs actually is. To me it looks like AutoCad of 1991 with a less powerful graphic interface - AutoCad had screen menus which were a context sensitive text based menu system. The difference between that and the <handfull> of Emacs extensions I have seen is that AutoCad screen menus were persistent and had a dedicated slice of the "window" (right or left side). They paged and predated pull downs in the interface.[1]

Anyway, the picture that is coming into focus is that what tutorials are teaching is not the language of Emacs (commands and eLisp), but the language of Emacs users (shortcuts).

Beyond that, Emacs command language uses a verb-noun structure. This is both a natural product of its Lispy origin and lousy for users.

[The following examples are fictitious]

Lisp thinking tends toward being about processes not objects. A programmer will create a higher order procedure <make f> contracted

  procedure -> procedure. 
Call <make buffer> and get <make-buffer>. Call <next line> get <next-line>, call <previous line> get previous-line. It's all nice and tidy from a programmer perspective.

It sucks for the user. The user needs a buffer. Is it <create-buffer>, <new-buffer>, <add-buffer>, or <make-buffer>?

Auto completion doesn't help. The user cannot easily conjure the proper demon. This is where object oriented conventions rule the field. If the user knows the kind of spirit, they know the first half of the spell, [2] and auto-completion is much easier. <buffer.next> <buffer.new> are more user friendly.

Just because from the perspective of the code <next-buffer> may be more akin to <next-line> than it is to <previous-buffer>, it is not akin semantically. There may be a natural language which uses prefix notation, but even if there is, few computer users speak it natively. When Emacs was a tool for a small community familiar with Lisp, verb-noun probably was not an impediment to learning its intricacies. Now it may be something a full fledged tutorial needs to be cognizant of.

[1] http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%202010%20User%...

[2] Ableson and Sussman rock.

Wow that was a pretty nice answer. Yes, all the points you make are right.

I guess that learning emacs requires a will to spend time at the loo reading about it... Otherwise its pro-oriented syntax gets in the way at all times.

I used to use icomplete-mode (incremental completion for M-x), and now I use helm. Helm allows me to start typing "M-x buffer next" and see next-buffer and switch-to-next-buffer as the options. =)

I'm not the original poster of the idea (although I think it does have merit). I'd like to see this fleshed out a bit more.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact