Emacs Book Vs Emacs Manuals

[Vaidheeswaran C]

What would be the best way to learn Emacs. Is it

a) Through the different Manuals (there are many and they are big)

b) Through a Book that puts all of the different pieces together in a
concise mannner.

----------------------------------------------------------------

What do you think are the "must haves" in an Emacs book? How often
should it catch up with new developments in Emacs releases?

----------------------------------------------------------------

For those who own a book on Emacs:

1. What is the book you own?

2. What is "good" about that book?

3. What is "bad" about that book?

----------------------------------------------------------------

How about resources like Emacswiki, Stackexchange or Stackoverflow.

----------------------------------------------------------------

TIA for all those who check-in to this thread.

[Shakthi Kannan]

Hi,

--- On Fri, May 8, 2015 at 3:36 PM, Vaidheeswaran C

<vaidheeswara...@gmail.com> wrote:
| What would be the best way to learn Emacs.

\--

Start with the GNU Emacs tutorial. If you prefer a book, I'd recommend
"Learning GNU Emacs":

http://shop.oreilly.com/product/9780596006488.do

You need to start using GNU Emacs for your day-to-day work/study. See
how people are using it for their needs, and then customize your
.emacs and configurations as you learn.

SK

--
Shakthi Kannan
http://www.shakthimaan.com

[Vaidheeswaran C]

On Friday 08 May 2015 04:06 PM, Shakthi Kannan wrote:
> Hi,
>
> --- On Fri, May 8, 2015 at 3:36 PM, Vaidheeswaran C
> <vaidheeswara...@gmail.com> wrote:
> | What would be the best way to learn Emacs.
> \--
>
> Start with the GNU Emacs tutorial. If you prefer a book, I'd recommend
> "Learning GNU Emacs":
>
> http://shop.oreilly.com/product/9780596006488.do

Have you read that book? The book is old. Do you still think that I
can use it. For example, does it talk about Org-mode etc.

> You need to start using GNU Emacs for your day-to-day work/study. See
> how people are using it for their needs, and then customize your
> .emacs and configurations as you learn.

Thanks for suggesting this.

[Tassilo Horn]

Vaidheeswaran C <vaidheeswara...@gmail.com> writes:

> What would be the best way to learn Emacs. Is it
>
> a) Through the different Manuals (there are many and they are big)
>
> b) Through a Book that puts all of the different pieces together in a
> concise mannner.

The best way to learn emacs is the tutorial (C-h t). And once you
master that, read the manuals on the topics that are most relevant to
you.

The good thing with the manuals is that they are exactly about the
version of emacs you are using. A book might pretty soon be outdated,
although it depends on the topics it focuses. I think from the point of
view of a normal user, emacs doesn't change (at least fundamentally) too
often. One such fundamental change in the last years has probably been
the activation of transient-mark-mode by default.

On the other hand, a book could probably be a bit more exciting read
focussing on the things that attract new users most, e.g., org-mode,
magit, etc. But there are actually even manuals that are a fun read,
one of them being the Gnus manual.

> How often should it catch up with new developments in Emacs releases?

Ideally it was free (not necessarily gratis!) so that it could be
updated by a community effort similar to the Git book.

> How about resources like Emacswiki, Stackexchange or Stackoverflow.

The problem with those external sites is that they frequently contain
outdated answers. Both Emacswiki and SX allow for updating answers but
that doesn't always happen. And IMHO, SX fosters a copy & past culture
where people just blindly copy snippets from SX answers to their
~/.emacs without even trying to understand what they are doing until all
breaks.

Also, it seems to me that many users nowadays aren't even aware that
there are official support channels (mailinglists, newsgroups, issue
trackers, IRC) for most things emacs. They just go and ask on SX. That
way, the maintainers won't even notice that there might be something
wrong with their package unless they follow SX, too.

I myself as one of the GNU AUCTeX maintainers sometimes check SX for
AUCTeX questions. But honestly, I very very much prefer if bugs get
reported to debbugs (M-x TeX-submit-bug-report) and questions get asked
on our mailinglist. Then I can answer from Gnus, and have quick access
to the docs, the code, the version control history, etc.

Just my 2 cents,
Tassilo

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, May 08, 2015 at 04:13:34PM +0530, Vaidheeswaran C wrote:
> On Friday 08 May 2015 04:06 PM, Shakthi Kannan wrote:

[...]

> > You need to start using GNU Emacs for your day-to-day work/study. See
> > how people are using it for their needs, and then customize your
> > .emacs and configurations as you learn.

Seconded. Emacs is huge. Coming from vi (long time ago) I took the pain
of switching (because I was convinced that Emacs Is Right (TM). The first
stretch, until you get your day-to-day stuff covered takes a bit. After
that, my strategy was identifying pain points, one by one, and tackling
each one. If I like the solution, I try to memorize it.

The (built in) manual and function/variable documentation are pure gold,
get early into the habit of doing "C-h i emacs" for the manual (or just
C-h r to jump directly into the Emacs manual) (and searching in the
manual, f.ex. the topic search, `i').

Be sure to do C-h ? to get an overview of all help topics. Just ignore
the ones you don't understand at the beginning

I'm not the tutorial type, my eyes glaze over after lesson 1, but you
might give it a try.

Emacswiki is a good resource. Another one I appreciate highly, especially
when I'm in "exploration mode" is the emacs category of Sacha Chua's blog:
<http://sachachua.com/blog/category/emacs/>. Very recommended. There are
quite a few other high-quality blogs out there.

This list. Well, you've found it.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlVMmSQACgkQBcgs9XrR2kaXAACfZ9PoUte2glVf3hDDKfmBqJ07
dM4An05l8RAsK2uYj+jJm0/wuW6HeVt6
=uHq5
-----END PGP SIGNATURE-----

[Shakthi Kannan]

Hi,

--- On Fri, May 8, 2015 at 4:13 PM, Vaidheeswaran C

<vaidheeswara...@gmail.com> wrote:
| Have you read that book? The book is old.

\--

Yes, I have read the book and I still refer to it. The concepts do not
change. History teaches you many lessons. If you find something that
doesn't work, please feel free to ask.

For org-mode, I'd encourage you to refer http://orgmode.org/worg/.

[notbob]

On 2015-05-08, Shakthi Kannan <shakt...@gmail.com> wrote:

> If you prefer a book, I'd recommend
> "Learning GNU Emacs":

> http://shop.oreilly.com/product/9780596006488.do
>
> You need to start using GNU Emacs for your day-to-day work/study.

As a lifelong emacs user (vi is the heart of evil --nb), I also
recommend this book. The latest edition (3rd ed) is 10 yrs outta
date, but it's still better than any alternatvives I've seen.
Primariliy due to the fact the author presents his howto info in every
day lay language. Buy a used copy. After the book introduces you to
the basics, look up specifics online.

I use emacs primarily as my file manager (dired), also as my
primary text editor. All the other stuff emacs is capable of, like
erc (IRC client), gnus (mail/nntp), etc, are stricly bonuses and can
be quite complicated for the neophyte.

This is a good source of info:

http://www.emacswiki.org/

The Gnu Emacs official manual is a document best experienced in small
doses. Do a browser search and find small specifics from the manusl,
as the entire manual is almost overwhelming. At the very least, a
total snooze. ;)

nb

[Phillip Lord]

Tassilo Horn <ts...@gnu.org> writes:

> Vaidheeswaran C <vaidheeswara...@gmail.com> writes:
>
>> What would be the best way to learn Emacs. Is it
>>
>> a) Through the different Manuals (there are many and they are big)
>>
>> b) Through a Book that puts all of the different pieces together in a
>> concise mannner.
>
> The best way to learn emacs is the tutorial (C-h t).

I wish this were true. Actually, the tutorial is not a good
introduction to emacs. It's over 200 lines before you get off "how to
move the cursor around". Most people these days assume that you do this
with the mouse or a finger and that doesn't take 200 lines to explain.
Works with Emacs too.

There are other introductions out there, and one of the needs to be
integrated into Emacs.

Phil

[Eli Zaretskii]

> From: philli...@newcastle.ac.uk (Phillip Lord)
> Date: Fri, 08 May 2015 14:39:31 +0100

>
> > The best way to learn emacs is the tutorial (C-h t).
>
> I wish this were true. Actually, the tutorial is not a good
> introduction to emacs. It's over 200 lines before you get off "how to
> move the cursor around".

No, it isn't, not in my Emacs. It mentions PageUp/PageDown on line 65
and arrow keys on line 76. Subtract 15 lines of typographic
conventions and 13 more lines "left blank for didactic purposes", and
you get 37 and 48 lines to read until one sees these truisms -- a far
cry from 200.

[Tassilo Horn]

philli...@newcastle.ac.uk (Phillip Lord) writes:

> Tassilo Horn <ts...@gnu.org> writes:
>
>> Vaidheeswaran C <vaidheeswara...@gmail.com> writes:
>>
>>> What would be the best way to learn Emacs. Is it
>>>
>>> a) Through the different Manuals (there are many and they are big)
>>>
>>> b) Through a Book that puts all of the different pieces together in a
>>> concise mannner.
>>

>> The best way to learn emacs is the tutorial (C-h t).
>
> I wish this were true. Actually, the tutorial is not a good
> introduction to emacs. It's over 200 lines before you get off "how to
> move the cursor around".

Mine starts with the key binding notation, then come some empty lines,
and then on line 53ff immediately C-v/M-v are explained. The section at
line 93 then starts the section about C-f/C-b/C-n/C-p, then word-wise
motion, then bol/eol motion. Around line 200, the basic motion commands
are done with the exception of M-</M-> and the use of an numeric
argument.

> Most people these days assume that you do this with the mouse or a
> finger and that doesn't take 200 lines to explain. Works with Emacs
> too.

Yes, and the tutorial also states that you can use the arrow keys or the
mouse for scrolling/moving point. Ok, not at prominent positions. But
if the tutorial started with "you can use emacs like notepad" then users
would immediately pick up the habit of using emacs like notepad.

> There are other introductions out there, and one of the needs to be
> integrated into Emacs.

Out of interest, which ones?

Bye,
Tassilo

[Barry Margolin]

In article <mailman.2604.14310956...@gnu.org>,

Aren't those part of moving the cursor around? Maybe you misunderstood
him, he said that you have to read more than 200 lines until you learn
something OTHER THAN how to move the cursor around. Line 263 (on my
admittedly old version 22.3) is where it finally says "WHEN EMACS IS
HUNG", the first non-movement section.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Eli Zaretskii]

> From: Barry Margolin <bar...@alum.mit.edu>
> Date: Fri, 08 May 2015 10:50:20 -0400

>
> > No, it isn't, not in my Emacs. It mentions PageUp/PageDown on line 65
> > and arrow keys on line 76. Subtract 15 lines of typographic
> > conventions and 13 more lines "left blank for didactic purposes", and
> > you get 37 and 48 lines to read until one sees these truisms -- a far
> > cry from 200.
>
> Aren't those part of moving the cursor around? Maybe you misunderstood
> him, he said that you have to read more than 200 lines until you learn
> something OTHER THAN how to move the cursor around. Line 263 (on my
> admittedly old version 22.3) is where it finally says "WHEN EMACS IS
> HUNG", the first non-movement section.

Yes, I gave him the benefit of the doubt about that. If he really
meant what he said, then I don't understand the whole quip. What's a
tutorial about an editor supposed to start with, if not basic cursor
motion? Which other editor has its tutorial start with something
else?

[Phillip Lord]

Tassilo Horn <ts...@gnu.org> writes:
>>>>
>>>> a) Through the different Manuals (there are many and they are big)
>>>>
>>>> b) Through a Book that puts all of the different pieces together in a
>>>> concise mannner.
>>>

>>> The best way to learn emacs is the tutorial (C-h t).
>>
>> I wish this were true. Actually, the tutorial is not a good

>> introduction to emacs. It's over 200 lines before you get off "how to
>> move the cursor around".
>
> Mine starts with the key binding notation, then come some empty lines,
> and then on line 53ff immediately C-v/M-v are explained. The section at
> line 93 then starts the section about C-f/C-b/C-n/C-p, then word-wise
> motion, then bol/eol motion. Around line 200, the basic motion commands
> are done with the exception of M-</M-> and the use of an numeric
> argument.

Yep, that's quite a lot. And then it goes into "What to do when Emacs in
Hung". After that, it starts talking about Windows which, of course, are
not windows.

It's very off-putting. I didn't realise this till, of course, till I
watched on of my students fight with it.

>> Most people these days assume that you do this with the mouse or a
>> finger and that doesn't take 200 lines to explain. Works with Emacs
>> too.
>
> Yes, and the tutorial also states that you can use the arrow keys or the
> mouse for scrolling/moving point. Ok, not at prominent positions. But
> if the tutorial started with "you can use emacs like notepad" then users
> would immediately pick up the habit of using emacs like notepad.

If users move the cursor in Emacs the same way at they do in notepad,
that's fine by me.

>> There are other introductions out there, and one of the needs to be
>> integrated into Emacs.
>
> Out of interest, which ones?

This one has some funky pictures of the basic GUI elements.


http://www.jesshamrick.com/2012/09/10/absolute-beginners-guide-to-emacs/


This one is quite nice.

https://www.youtube.com/watch?v=B6jfrrwR10k

Xah Lee's stuff is erratic but useful.

Basically, anything that doesn't start off with keybindings would be
good for me. They can come later.

Phil

[Tassilo Horn]

philli...@newcastle.ac.uk (Phillip Lord) writes:

> After that, it starts talking about Windows which, of course, are not
> windows.

Maybe with Emacs 30, we'll replace frame by window, and window by
pane. :-)

> It's very off-putting. I didn't realise this till, of course, till I
> watched on of my students fight with it.

When I started using emacs about a decade ago (as a student as well), I
didn't have problems accepting that emacs is different to what I've been
used to (KDE's Kate at that time). I was just prepared to do whatever
it takes to get that Gnus running!

>> Yes, and the tutorial also states that you can use the arrow keys or
>> the mouse for scrolling/moving point. Ok, not at prominent
>> positions. But if the tutorial started with "you can use emacs like
>> notepad" then users would immediately pick up the habit of using
>> emacs like notepad.
>
> If users move the cursor in Emacs the same way at they do in notepad,
> that's fine by me.

It's not completely wrong of course but once you've got used to the
"normal" movement bindings, it's easy to go from character-based motion
to word- or sexp-based motion.

>>> There are other introductions out there, and one of the needs to be
>>> integrated into Emacs.
>>
>> Out of interest, which ones?
>
> This one has some funky pictures of the basic GUI elements.
>
> http://www.jesshamrick.com/2012/09/10/absolute-beginners-guide-to-emacs/

Indeed, that's pretty nice. The only thing I didn't like skimming over
it is that it calls the mode-line status-bar. Using the emacs term is
better because if you know it, you can use the help more effectively.

And the kill/yanking section is a bit weird. It says `M-y' would
replace the current yank with the next from the kill-ring but that's
actually the previous. And it advertises a keybinding `M-Y' which would
reverse the yank direction wrt. the kill-ring. I suspect the author's
using some extension (maybe undo-tree?) without being aware of that. So
there's a very high chance the novice won't be able to reproduce what
she's reading.

> This one is quite nice.
>
> https://www.youtube.com/watch?v=B6jfrrwR10k

The problem with that (except that it's a video) is that it shows a
highly customized emacs, not the one the newbie's currently sitting in
front of.

> Basically, anything that doesn't start off with keybindings would be
> good for me. They can come later.

"To move the cursor to the next character, simply do M-x forward-char
RET. Yes, it's really that easy!" ;-)
Ok, ok, M-x is a keybinding, too.

But the tutorial you've cited first also starts with key bindings.

Bye,
Tassilo

[Drew Adams]

> What would be the best way to learn Emacs. Is it

> a) Through the different Manuals (there are many and they are big)
> b) Through a Book that puts all of the different pieces together in
> a concise mannner.

...

> How about resources like Emacswiki, Stackexchange or Stackoverflow.

You will get lots of answers here, no doubt. As you can guess,
this is not the first time people have considered this question.

The question is especially apropos for Emacs, because Emacs has
as a major goal to help you learn about it - it is touted as "the
self-documenting editor". The best lesson to learn: Ask Emacs.

Some of what you get here as responses might be interesting & new.
But you can also benefit from previous pondering of the question.

I would recommend starting with the info that has been distilled
on Emacs Wiki about this. And you can update it with your own
thoughts/experience/advice about the question.

On the main EmacsWiki page you see prominently this section heading:
Learning About Emacs.
(http://www.emacswiki.org/emacs/SiteMap#LearningEmacs)

The first entry under that heading is EmacsNewbie.
(http://www.emacswiki.org/emacs/EmacsNewbie)

And at EmacsNewbie you see links to a glossary, guided tour, etc.
The main link is "LearningEmacs – Different ways to learn Emacs."
(http://www.emacswiki.org/emacs/LearningEmacs)

The "different ways" is important, because people learn, and
want to learn, differently.

Enjoy, and welcome to Emacs!

[Sivaram Neelakantan]

On Fri, May 08 2015,Phillip Lord wrote:


[snipped 11 lines]

>> The best way to learn emacs is the tutorial (C-h t).
>
> I wish this were true. Actually, the tutorial is not a good
> introduction to emacs. It's over 200 lines before you get off "how to

> move the cursor around". Most people these days assume that you do this

> with the mouse or a finger and that doesn't take 200 lines to explain.
> Works with Emacs too.
>

> There are other introductions out there, and one of the needs to be
> integrated into Emacs.
>

As a counterexample I did find the tutorial helpful and just about
enough to get started back in the 90s. Then again, I simply accepted
that's how you learn Emacs and went ahead. and it was a good thing
that I did because it simply forced me to abandon vi mode of thinking.

Though I distinctly remember my opinion was initially "dafuq is this
ctrl and meta key mumbo jumbo" and I was off to a grumpy start in
learning it.

sivaram
--

[Bob Proulx]

Vaidheeswaran C wrote:
> Shakthi Kannan wrote:

> > Vaidheeswaran C wrote:
> > | What would be the best way to learn Emacs.
> >

> > Start with the GNU Emacs tutorial. If you prefer a book, I'd recommend

> > "Learning GNU Emacs":
> >
> > http://shop.oreilly.com/product/9780596006488.do
>

> Have you read that book? The book is old. Do you still think that I
> can use it. For example, does it talk about Org-mode etc.

A student says that they really want to learn Calculus. They know
that Calculus is very powerful and can be used to solve many problems.
I suggest that they learn Arithmetic first. They respond,
"Arithmetic! Have you learned Arithmetic? Arithmetic is old. Should
I learn Arithmetic? For example, will Arithmetic talk about
Calculus?"

I didn't learn Emacs from the book Learning GNU Emacs but I have it
and it is a good introduction. It is easier to learn the fundamentals
and then build upon them with more advanced concepts afterward.

Bob

[Marcin Borkowski]

On 2015-05-08, at 12:06, Vaidheeswaran C <vaidheeswara...@gmail.com> wrote:

> What do you think are the "must haves" in an Emacs book? How often

> should it catch up with new developments in Emacs releases?

I'm really astonished that nobody mentioned Mickey Petersen's "Mastering
Emacs": https://www.masteringemacs.org/ . It's an excellent blog, and
the author announced also a book (which is not just a bunch of blog
posts put together, but mostly newly written material). I'm not sure
how much I'm allowed to say about the book itself, but let me put it
this way: *if* I were to learn Emacs soon, I'd check the website for the
book *every day* to see when it's out. (For intermediate to advanced
users it's not a must-read, but nice anyway.)

I agree that the built-in tutorial needs rewriting, but it's not that
bad. The official manual, OTOH, is very good. Also, I second Drew's
suggestion about learning to ask Emacs.

Also, subscribing to Planet Emacsen RSS, while not a must-do, may be
a good idea.

And after a while, reading Robert J. Chassell's "An Introduction to
Programming in Emacs Lisp" becomes a necessity. ;-)

As for the updates: Emacs changes *a lot* from one release to the next
one, but most of these changes are not visible for users. Plus, you can
always read the CHANGES file.

Best,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

[Marcin Borkowski]

On 2015-05-08, at 21:10, Bob Proulx <b...@proulx.com> wrote:

> Vaidheeswaran C wrote:
>> Shakthi Kannan wrote:
>> > Vaidheeswaran C wrote:
>> > | What would be the best way to learn Emacs.
>> >
>> > Start with the GNU Emacs tutorial. If you prefer a book, I'd recommend
>> > "Learning GNU Emacs":
>> >
>> > http://shop.oreilly.com/product/9780596006488.do
>>
>> Have you read that book? The book is old. Do you still think that I
>> can use it. For example, does it talk about Org-mode etc.
>
> A student says that they really want to learn Calculus. They know
> that Calculus is very powerful and can be used to solve many problems.
> I suggest that they learn Arithmetic first. They respond,
> "Arithmetic! Have you learned Arithmetic? Arithmetic is old. Should
> I learn Arithmetic? For example, will Arithmetic talk about
> Calculus?"

Nice try;-). But this analogy is flawed: software, unlike mathematical
theories, is subject to change.

> I didn't learn Emacs from the book Learning GNU Emacs but I have it
> and it is a good introduction. It is easier to learn the fundamentals
> and then build upon them with more advanced concepts afterward.

Well, I don't have the book, but I agree with the above. The tutorial
and the first few chapters of the official manual are good for learning
fundamentals.

> Bob

[Stefan Monnier]

>> After that, it starts talking about Windows which, of course, are not
>> windows.
> Maybe with Emacs 30, we'll replace frame by window, and window by
> pane. :-)

Sounds about right. If all goes according to plan, that will be right
around the time when more than half of our users have never seen
a desktop/laptop GUI and hence have no idea what is a "window".


Stefan

[Stefan Monnier]

> What's a tutorial about an editor supposed to start with, if not basic
> cursor motion?

I think most users will already have used some kind of text editor
(e.g. text box in a browser, notepad, textedit, you name it, ...), so
they probably "know" how to navigate the text and aren't interested in
that, as a start.

I think it's good and important to talk about the different ways to
navigate (e.g. I'm particularly fond of sexp-navigation), but when
I present Emacs to my students, I never bother with the cursor-motion
part. E.g. I talk instead about windows and buffers (e.g. the fact that
you can display a buffer in more that one window at the same time),
especially about C-x 1 to get rid of the pesky windows which may popup
along the way.

I also talk about indentation (since either they can't imagine that the
editor might do it for them, or on the contrary they're disappointed
that it doesn't happen 100% automatically, or because they're confusing
the TAB key, the insertion of TAB characters, and the notion of
indenting text to a "tabulation point", which they seem to sometimes
take from WYSIWYG word processors).


Stefan

[Eli Zaretskii]

> From: Marcin Borkowski <mb...@mbork.pl>
> Date: Fri, 08 May 2015 21:10:30 +0200

>
> I agree that the built-in tutorial needs rewriting

Feel free to suggest such a rewrite. If it's really good, I'm sure it
will be a welcome contribution.

Thanks.

[Marcin Borkowski]

If/when I sign the FSF papers, I'll surely do. I'm not sure whether
I could do better - after all, it's easier to criticize (even if the
criticism is valid)...

> Thanks.

Best

[Eli Zaretskii]

> From: Marcin Borkowski <mb...@mbork.pl>
> Date: Sat, 09 May 2015 10:07:51 +0200

>
> > Feel free to suggest such a rewrite. If it's really good, I'm sure it
> > will be a welcome contribution.
>
> If/when I sign the FSF papers, I'll surely do. I'm not sure whether
> I could do better - after all, it's easier to criticize (even if the
> criticism is valid)...

Right. But that shouldn't keep you from trying.

[Eli Zaretskii]

> From: Stefan Monnier <mon...@iro.umontreal.ca>
> Date: Fri, 08 May 2015 18:06:22 -0400

>
> > What's a tutorial about an editor supposed to start with, if not basic
> > cursor motion?
>
> I think most users will already have used some kind of text editor
> (e.g. text box in a browser, notepad, textedit, you name it, ...), so
> they probably "know" how to navigate the text and aren't interested in
> that, as a start.

We could tell them to skip these sections if they want to (and don't
know how to skip without being told).

But anyhow, that's how an editor's tutorial usually starts. E.g.,
look at the one for Vim.

> I think it's good and important to talk about the different ways to
> navigate (e.g. I'm particularly fond of sexp-navigation), but when
> I present Emacs to my students, I never bother with the cursor-motion
> part.

Note that while describing cursor motion, we also introduce the
important topic of a numeric argument to a command.

> E.g. I talk instead about windows and buffers (e.g. the fact that
> you can display a buffer in more that one window at the same time),
> especially about C-x 1 to get rid of the pesky windows which may popup
> along the way.

Which is the topic of the very next part of the tutorial, after
skimming over a couple of small but important issues.

> I also talk about indentation (since either they can't imagine that the
> editor might do it for them, or on the contrary they're disappointed
> that it doesn't happen 100% automatically, or because they're confusing
> the TAB key, the insertion of TAB characters, and the notion of
> indenting text to a "tabulation point", which they seem to sometimes
> take from WYSIWYG word processors).

That's hardly in the first several topics, not before buffers, files,
undo, insertion and deletion, search, etc. If it's important enough
to be in the tutorial, we could add that, though.

[Vaidheeswaran C]

On Saturday 09 May 2015 03:36 AM, Stefan Monnier wrote:
> I think it's good and important to talk about the different ways to
> navigate (e.g. I'm particularly fond of sexp-navigation), but when
> I present Emacs to my students, I never bother with the cursor-motion

> part. E.g. I talk instead about windows and buffers (e.g. the fact that

> you can display a buffer in more that one window at the same time),
> especially about C-x 1 to get rid of the pesky windows which may popup
> along the way.
>

> I also talk about indentation (since either they can't imagine that the
> editor might do it for them, or on the contrary they're disappointed
> that it doesn't happen 100% automatically, or because they're confusing
> the TAB key, the insertion of TAB characters, and the notion of
> indenting text to a "tabulation point", which they seem to sometimes
> take from WYSIWYG word processors).

Thanks for this note. This is EXACTLY the kind of input that I hoped
this thread would generate.

If the tutorial is just a handout and the manual is a Handbook, the
"Emacs Book" will be a handy-book, full of tips and tricks and lot
less intimadting.

There is a Quick Tour (http://www.gnu.org/software/emacs/tour/) but in
my assessment it is a bit advanced.

[Vaidheeswaran C]

On Friday 08 May 2015 09:20 PM, Drew Adams wrote:

> The question is especially apropos for Emacs, because Emacs has
> as a major goal to help you learn about it - it is touted as "the
> self-documenting editor". The best lesson to learn: Ask Emacs.

Easy to overlook this. Thanks for the reminder.

An ideal book will take the Trainee to a pond, rent them a fishing-rod
and show some slick moves to catch fish for the day's supper and leave
them there.

The Book will not sell fishes. Dead fishes stink.

----------------------------------------------------------------

Drew, will you be interested in working with me (along with others) on
this book. The book, (as I see it):

1. Will be published by FSF.

2. (To begin with it) Will stick to just the packages that come with
Stock Emacs or GNU ELPA. (Specifically, it will not cover Icicles
for example).

Stefan's note on devel list indicate that contributors assign the
copyright to FSF. Will you be interested in being a contributor to
this this book? I will try to rope in more contributors.

At this point in time, I appoint myself as a co-ordinator and editor
for this new initiative. I am willing to re-work the incoming drafts
in to a readable book.

I may write a few chapters myself.

[Vaidheeswaran C]

Tassilo

On Friday 08 May 2015 09:11 PM, Tassilo Horn wrote:

> I was just prepared to do whatever it takes to get that Gnus
> running!

Will you be interested in contributing a chapter on Gnus?

Folks who have an assignment with FSF, if they could contribute some
of their notes or config tips with me, I can mash them together in to
a readable book.

I am really shooting for an FSF-approved Emacs Book.

(See my other replies on emacs-devel and on this list)

[Vaidheeswaran C]

On Friday 08 May 2015 07:09 PM, Phillip Lord wrote:

> I wish this were true. Actually, the tutorial is not a good
> introduction to emacs.

I have been using Emacs for almost a decade now. My initial struggles
are just vague memories.

If you were to write this tutorial, how will you structure it. (Just
some quick notes would do)

If you (Hello There!), are a user who has started using Emacs
recently...If could share yours WTFs or suggestions, I will make a
note of it and fold it in to "The Emacs Book" I am working on.

NB: "The Emacs Book" is just a vapourware right now. I am looking for
inputs from the user community. If all goes well and if there is some
good initial meat, I may even propose to Emacs maintainers to host a
repository for this book.

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswara...@gmail.com>
> Date: Sat, 09 May 2015 14:48:55 +0530

>
> If the tutorial is just a handout and the manual is a Handbook, the
> "Emacs Book" will be a handy-book, full of tips and tricks and lot
> less intimadting.

I think you will find out that building a book based on tips and tricks
for a package as large and complex as Emacs is a sure way to a book
that won't be read. There's no reasonable way of describing the
multitude of tricks and tips in any organized way. So in effect you
will have a hodgepodge of unrelated stuff, impossible to read _as_ a
book, and useful only for finding the particular trick one wants --
for which Google is much better method.

A book must have some methodology and some didactic principles
behind its organization and structure. It must describe its subject
in some methodical way. Building on tips and tricks is therefore an
antithesis of a book.

[Jude DaShiell]

I think it would be useful to mention the emacs wiki in the tutorial and
show how it can be accessed with emacs.
If an emacs irc channel exists that along with showing how to access it on
emacs would be useful too. Should probably only put the new users emacs
irc channel in the tutorial though.



-- Twitter: JudeDaShiell

[Marcin Borkowski]

On 2015-05-09, at 10:27, Eli Zaretskii <el...@gnu.org> wrote:

>> From: Marcin Borkowski <mb...@mbork.pl>

I will, of course. Not sure when; I'm going for vacation in two weeks
and that might be a good moment, but we'll see.

Best,

[Emanuel Berg]

Vaidheeswaran C <vaidheeswara...@gmail.com>
writes:

> What would be the best way to learn Emacs. Is it
>
> a) Through the different Manuals (there are many and
> they are big)
>
> b) Through a Book that puts all of the different
> pieces together in a concise mannner.

c) None of the alternatives. The best way to learn
Emacs is to use it for everything, everyday (or every
night). Activity is the key to everything and activity
leads to more activity. It is like installing a new
sound system. You get the gear. But it won't work.
You learn that you need a jumper - a cable or wire,
one might say (it doesn't matter here), and it works.
Now, when you got about the new sound system you
didn't think "Man, it will be so cool to learn what
a jumper is!" But that is exactly what happened.
So activity will bring activity and you will learn in
the processes. You only have to worry about
being active.

But don't use Emacs every hour awake because there are
other things in life that have nothing to do with
Emacs but will make you a better computer and Emacs
user nonetheless. So it is more important to use Emacs
or whatever you want to master every day than to use
it 18 hours straight and then not touch it for a week.

Manuals you use when you get stuck to find out how to
solve a particular problem.

Books you read for example when you travel by train.

--
underground experts united
http://user.it.uu.se/~embe8573

[Bob Proulx]

Stefan Monnier wrote:
> I also talk about indentation (since either they can't imagine that the
> editor might do it for them, or on the contrary they're disappointed
> that it doesn't happen 100% automatically, or because they're confusing
> the TAB key, the insertion of TAB characters, and the notion of
> indenting text to a "tabulation point", which they seem to sometimes
> take from WYSIWYG word processors).

+1. This is one of those very important topics because it is one that
most rookies get wrong. It would be great if there were a way to
better educate more people about it.

Bob

[Bob Proulx]

Marcin Borkowski wrote:

> Bob Proulx wrote:
> > A student says that they really want to learn Calculus. They know
> > that Calculus is very powerful and can be used to solve many problems.
> > I suggest that they learn Arithmetic first. They respond,
> > "Arithmetic! Have you learned Arithmetic? Arithmetic is old. Should
> > I learn Arithmetic? For example, will Arithmetic talk about
> > Calculus?"
>
> Nice try;-). But this analogy is flawed: software, unlike mathematical
> theories, is subject to change.

Has emacs changed that much? I don't think it has. It is still very
much the same. It is still an extensible editor that uses emacs lisp
for the extension language. Some of the small details have changed.
But the concepts and most of the day to day details are the same.

Bob

[Emanuel Berg]

Bob Proulx <b...@proulx.com> writes:

> Has emacs changed that much? I don't think it has.
> It is still very much the same. It is still an
> extensible editor that uses emacs lisp for the
> extension language. Some of the small details have
> changed. But the concepts and most of the day to day
> details are the same.

It is an illusion that things are changing and that
they should change. I don't see much in humankind
changing since ancient Babylonia. With technology the
exact same is observable: for example I write this
with Emacs (Lisp - 50s; Emacs, C - 70s) on Linux
(again C, UNIX - 70s). One thing beginners should stop
caring about is what things are old, new, "modern",
etc. Just as in human life, where young morons make
old morons, that doesn't matter, what matters is how
good something is and what you can do with it with
time and effort.

[Vaidheeswaran C]

On Saturday 09 May 2015 04:08 PM, Eli Zaretskii wrote:
> A book must have some methodology and some didactic principles
> behind its organization and structure. It must describe its subject
> in some methodical way.

Someone suggested http://everypageispageone.com/the-book/.

What I call as "A Book", may not in actuality be a book as it is
conventionally understood and consumed.

I am looking for inputs that would address your specific question.

[Rusi]

On Sunday, May 10, 2015 at 8:18:20 AM UTC+5:30, Bob Proulx wrote:
> Marcin Borkowski wrote:
> > Bob Proulx wrote:
> > > A student says that they really want to learn Calculus. They know
> > > that Calculus is very powerful and can be used to solve many problems.
> > > I suggest that they learn Arithmetic first. They respond,
> > > "Arithmetic! Have you learned Arithmetic? Arithmetic is old. Should
> > > I learn Arithmetic? For example, will Arithmetic talk about
> > > Calculus?"
> >
> > Nice try;-). But this analogy is flawed: software, unlike mathematical
> > theories, is subject to change.
>
> Has emacs changed that much? I don't think it has. It is still very
> much the same.

Sad but true

After 20 years of using, teaching with, and making my students use emacs,
for the first time this year I taught python using Idle rather than emacs.
Some nuisances... C-a now means Select-all whereas my nerve-pathways know it as
Beginning-of-line etc etc
Also some sadness... however one needs to get real and selling emacs to students
has led to lot of funny looks and some significant hostility.

The tutorial with C-f C-b... for cursor movements was I guess the last straw

What I describe may sound like exaggeration but that's only because I am trying to
reconstruct what happens between noob and emacs when I am not around.

Student starts reading tutorial and sees the C-f C-b stuff:

- Some follow it wonder about the weirdness but then get on with it
- Some just use cursor keys like the rest of the planet ignore the C-f C-b
stuff and get on with it
- But a few notice that cursor keys work as they should but is not documented
and are a bit confused/bewildered
- And of those few, a few get real HOSTILE

Now if the cursor-keys didn't work it would not be so bad
And ideal would be for them to work AND be documented
But works and NOT documented/demoed in tutorial... and there are serious
allegations of ATTITUDE!

[And I am implicated with the emacs-devs :-) ]

[Pascal J. Bourguignon]

I can't believe it. Do you teach retards?

--
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

[Steinar Bang]

>>>>> philli...@newcastle.ac.uk (Phillip Lord):

> This one has some funky pictures of the basic GUI elements.

> http://www.jesshamrick.com/2012/09/10/absolute-beginners-guide-to-emacs/

Here's my take on the beginners guide (interestingly from the same year
as the article above):
http://steinar.bang.priv.no/2012/05/01/very-basic-emacs-usage-2/

[Eli Zaretskii]

> Date: Sun, 10 May 2015 12:17:25 +0530
> From: Vaidheeswaran C <vaidheeswara...@gmail.com>

>
> Someone suggested http://everypageispageone.com/the-book/.
>
> What I call as "A Book", may not in actuality be a book as it is
> conventionally understood and consumed.

Then what is it? And why would people want to use it, instead of
googling?

Without some "glue", there's no added value to a book that just brings
together unsorted tops that are already available on the Web.

[Drew Adams]

> selling emacs to students has led to lot of funny looks

Funny looks are good. Encourage funny looks about Emacs.
Emacs needs more funny looks.

> and some significant hostility.

Stop selling, in that case.

> The tutorial with C-f C-b... for cursor movements was I guess the
> last straw

Really. Stop selling, if something like that is "the last straw".
Don't bother. Do yourself and your customers a favor.

Sounds like trying to get kiddies to eat their veggies. Try it
when they're tiny, but if you can't make headway, give up and
wait till they come 'round later, sometime after adolescence -
some of 'em will; some of 'em won't. Not your problem, then.

> what happens between noob and emacs when I am not around.

It doesn't sound like it gets much better when you are around. ;-)

> Student starts reading tutorial and sees the C-f C-b stuff:...

> - But a few notice that cursor keys work as they should but is
> not documented and are a bit confused/bewildered

Teach 'em how to file a doc bug. Show that Emacs is undergoing
development (still!) and that they are the developers. How would
they improve this part of the tutorial? (How would you?)

But of course the "doc" bug here concerns only the tutorial,
not the doc: "is not documented" is simply not true.

`C-h r i cursor TAB motion RET'. Teach them how to *Ask Emacs*.

Should the tutorial mention this? Ask your students. That's
likely to engage them in a productive and interesting
discussion about Emacs design and use. Why does Emacs bind
`C-f' etc.? What were those old farts thinking? Is this just
vestigial baggage? Just hysterical raisins?

> - And of those few, a few get real HOSTILE

Move to a less privileged environment to teach, where the kids
have more important things to "get real HOSTILE" about.

> Now if the cursor-keys didn't work it would not be so bad

So unbind them in the Emacs version that you expose to your
congregation.

Erect a sign, like in Disneyland, with a bar 1.5m high, and
tell them that only those taller than the bar can go on the
Real Emacs ride. Too risky for toddlers - they're limited
to the shallow end of the Emacs pool. But someday...

Then maybe show some of them how to add cursor-key bindings
to the kiddie pool. Look, Ma! I made <right> work, all by
myself! Tu m'as vu !?

Extra credit: Ask Emacs, instead of Rusi, how to add the key
bindings.

> And ideal would be for them to work AND be documented

Again: teach about doc bugs. But again: they *are* documented.

> But works and NOT documented/demoed in tutorial... and there
> are serious allegations of ATTITUDE!

Take a nap. This too will pass.

[Vaidheeswaran C]

You can help me define the "glue".

First, I need to understand what the Thesis of the Book (I was
recommended) is. I don't want to talk based on a __mere supposition__
of what the Book is advocating.

[Phillip Lord]

Eli Zaretskii <el...@gnu.org> writes:

>> From: Barry Margolin <bar...@alum.mit.edu>
>> Date: Fri, 08 May 2015 10:50:20 -0400
>>
>> > No, it isn't, not in my Emacs. It mentions PageUp/PageDown on line 65
>> > and arrow keys on line 76. Subtract 15 lines of typographic
>> > conventions and 13 more lines "left blank for didactic purposes", and
>> > you get 37 and 48 lines to read until one sees these truisms -- a far
>> > cry from 200.
>>
>> Aren't those part of moving the cursor around? Maybe you misunderstood
>> him, he said that you have to read more than 200 lines until you learn
>> something OTHER THAN how to move the cursor around. Line 263 (on my
>> admittedly old version 22.3) is where it finally says "WHEN EMACS IS
>> HUNG", the first non-movement section.
>
> Yes, I gave him the benefit of the doubt about that. If he really
> meant what he said, then I don't understand the whole quip. What's a

> tutorial about an editor supposed to start with, if not basic cursor

> motion? Which other editor has its tutorial start with something
> else?


https://atom.io/docs/v0.198.0/


Starts with "why atom is cool". Then explains basic concepts (including
"buffers" which mean exactly the same thing as in Emacs). The packages.

It does have a section on moving around, including keybindings, but it
starts by saying "using a mouse or the arrow keys works well". Their
basic introduction also includes snippets, version control, autocomplete
and folding.

Phil

[Phillip Lord]

Rusi <rusto...@gmail.com> writes:
>> Has emacs changed that much? I don't think it has. It is still very
>> much the same.
>
> Sad but true
>
> After 20 years of using, teaching with, and making my students use
> emacs, for the first time this year I taught python using Idle rather
> than emacs. Some nuisances... C-a now means Select-all whereas my
> nerve-pathways know it as Beginning-of-line etc etc Also some
> sadness... however one needs to get real and selling emacs to students
> has led to lot of funny looks and some significant hostility.
>
> The tutorial with C-f C-b... for cursor movements was I guess the last straw

I have exactly the same experience, and use idle for the same reason. I
have sat behind some students and looked at them staring at the front
page of the tutorial in despair. I mean, they are leaning Python
already?

This is despite the fact that idle is not that great.

I give them cart blanche to choose as they will, although I do plug
Emacs (while admitting that I am biased). Very few of them use it,
and the initial hurdle is getting it to work at all.

Phil

[Phillip Lord]

"Pascal J. Bourguignon" <p...@informatimago.com> writes:
>> Now if the cursor-keys didn't work it would not be so bad
>> And ideal would be for them to work AND be documented
>> But works and NOT documented/demoed in tutorial... and there are serious
>> allegations of ATTITUDE!
>

> I can't believe it. Do you teach retards?

I teach intelligent, interested and engaged students, whom it is my
pleasure and privilege to introduce to programming, and show them how to
take charge of their own computers, and have the computers work for
them, rather than the other way around. I am sure that Rusi is in the
same position.

Over time, the experiences of people change, and the knowledge that they
bring with them changes. This makes some things harder to understand,
some things easier. For instance, I have the majority of my students got
to grips with git in a day or two (which I was not expecting),
something which has caused grief here. But running "hello world" in
python in Emacs not easy. "Eval buffer" -- what's that then? And even
once you've done that, where has it gone, because the shell isn't
visible.

Phil

[Pascal J. Bourguignon]

Be careful, soon they'll complain when you make them use a keyboard
instead of an iPad to write code…


These days, I'm starting to think that there's a deficit of CS history
teaching.

When I started programming, modern computing was only 25 years old, so
CS history was short, and even if not widely accessible outside of
academia, it was rather easy to cover it all.

While arguably nothing much has been invented since the end of the
sixties, it appears that google doesn't give easy access to the history,
giving some preference to new web sites and recent entries. And one
must also consider that older papers and books are either not accessible
or only accessible in the deep web or behind paywalls.

Therefore it seems to me that teaching CS history would help students
widden their horizons, given the diversity of languages and OSes
already invented.

[Phillip Lord]

Eli Zaretskii <el...@gnu.org> writes:

>> From: Marcin Borkowski <mb...@mbork.pl>
>> Date: Fri, 08 May 2015 21:10:30 +0200
>>
>> I agree that the built-in tutorial needs rewriting
>

> Feel free to suggest such a rewrite. If it's really good, I'm sure it
> will be a welcome contribution.

I did start work on this a while back, actually. I was going to wait
till I got to the a point of completion, but as the argument has come up
again, I've stuck my working version up.

https://github.com/phillord/emacs-tutorial.git

Phil

[Eli Zaretskii]

> From: philli...@newcastle.ac.uk (Phillip Lord)
> Cc: <help-gn...@gnu.org>
> Date: Mon, 11 May 2015 11:53:32 +0100

>
> >What's a tutorial about an editor supposed to start with, if not
> > basic cursor motion? Which other editor has its tutorial start
> > with something else?
>
> https://atom.io/docs/v0.198.0/
>
> Starts with "why atom is cool".

Waste of the student's time, if you ask me.

But if someone wants to add a similar section to the Emacs tutorial
(with a "skip" button ;-), why not?

> Then explains basic concepts (including
> "buffers" which mean exactly the same thing as in Emacs). The packages.

And then, tada! "Moving in Atom".

So it's not so different, except that it risks losing its audience
while explaining the basics, which the Emacs tutorial does seamlessly
as part of describing the commands.

> It does have a section on moving around, including keybindings, but it
> starts by saying "using a mouse or the arrow keys works well".

So do we:

You can also use the PageUp and PageDn keys to move by screenfuls, if
your terminal has them, but you can edit more efficiently if you use
C-v and M-v.
[...]
You can use the arrow keys, but it's more efficient to keep your hands
in the standard position and use the commands C-p, C-b, C-f, and C-n.

> Their basic introduction also includes snippets, version control,
> autocomplete and folding.

Making the tutorial much longer. But we could add some of that as
well.

And here's another example:

http://linuxconfig.org/vim-tutorial

It also starts with cursor movement.

[Eli Zaretskii]

> From: philli...@newcastle.ac.uk (Phillip Lord)
> Cc: <help-gn...@gnu.org>

> Date: Mon, 11 May 2015 12:02:07 +0100

>
> I did start work on this a while back, actually. I was going to wait
> till I got to the a point of completion, but as the argument has come up
> again, I've stuck my working version up.
>
> https://github.com/phillord/emacs-tutorial.git

Thanks, but it includes little more than description of the UI basics:
windows, frames, the mode line, etc. Even if we agree that this is
the right methodology (and I personally don't like tutorials that
require me to read too much before I can do something with the
package), "the meat" is not there yet. So it's hard to say what will
this look like when it's closer to completion.

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswara...@gmail.com>
> Date: Mon, 11 May 2015 11:00:09 +0530

>
> >> What I call as "A Book", may not in actuality be a book as it is
> >> conventionally understood and consumed.
> >
> > Then what is it? And why would people want to use it, instead of
> > googling?
> >
> > Without some "glue", there's no added value to a book that just brings
> > together unsorted tops that are already available on the Web.
>
> You can help me define the "glue".

It's that stuff that guides the reader from one feature to another,
and generally allows the reader to make sense out of a huge pile of
loosely related features.

E.g., when you describe commands that act on buffers, they should be
described in some methodical manner, and the order should make some
sense, and facilitate understanding and memorizing them.

[Stefan Monnier]

> Waste of the student's time, if you ask me.

You (and the current tutorial) assume that the reader of the tutorial
has decided he's going to use Emacs and wants to figure out how to use
it efficiently.

That's good for that use case. But there are other use cases, such as
someone who's intrigued and wants to "check it out". In that case, the
tutorial should mostly try and showcase what you can do with Emacs.


Stefan

[Eli Zaretskii]

> From: Stefan Monnier <mon...@iro.umontreal.ca>
> Date: Mon, 11 May 2015 12:12:43 -0400

Which is why I said (and you elided) that I won't mind if such a
section would be added.

[Eli Zaretskii]

> Date: Mon, 11 May 2015 19:23:35 +0300
> From: Eli Zaretskii <el...@gnu.org>

Btw, it could just be that the "someone intrigued" use case could be
better served by a separate document, also reachable from Help. It
is, after all, quite a different goal -- to "sell" Emacs to newcomers,
rather than teach them to use it.

[Drew Adams]

> I personally don't like tutorials that require me to read too much
> before I can do something with the package)

Yes, a tutorial should be learning by *doing*.

(A user guide is something else.)

[Drew Adams]

> > Waste of the student's time, if you ask me.
>
> You (and the current tutorial) assume that the reader of the
> tutorial has decided he's going to use Emacs and wants to figure
> out how to use it efficiently.

Of course. (Though not necessarily efficiently - just want to learn
to use it.)

> That's good for that use case. But there are other use cases, such
> as someone who's intrigued and wants to "check it out". In that case,
> the tutorial should mostly try and showcase what you can do with Emacs.

No, those are not use cases for a *tutorial*. Those are use cases for
a demo or a user guide or an introduction/overview.

A tutorial is about learning by *doing*. In a way, it is an
introductory lab exercise.

[Drew Adams]

> Btw, it could just be that the "someone intrigued" use case could be
> better served by a separate document, also reachable from Help. It
> is, after all, quite a different goal -- to "sell" Emacs to
> newcomers, rather than teach them to use it.

Precisely. That is not the aim of a tutorial. But that doesn't
mean that it is not helpful for potential new users.

[Phillip Lord]

Eli Zaretskii <el...@gnu.org> writes:

>> From: philli...@newcastle.ac.uk (Phillip Lord)
>> Cc: <help-gn...@gnu.org>
>> Date: Mon, 11 May 2015 12:02:07 +0100
>>
>> I did start work on this a while back, actually. I was going to wait
>> till I got to the a point of completion, but as the argument has come up
>> again, I've stuck my working version up.
>>
>> https://github.com/phillord/emacs-tutorial.git
>
> Thanks, but it includes little more than description of the UI basics:
> windows, frames, the mode line, etc. Even if we agree that this is

> the right methodology (and I personally don't like tutorials that

> require me to read too much before I can do something with the

> package), "the meat" is not there yet. So it's hard to say what will
> this look like when it's closer to completion.

Sure, I agree. I did say it was a work in progress.

I talk about the UI basics because you have to know what "buffer" means
or the menu makes little sense ("Buffers" or "Eval Buffer" from python).
And it does assume from the start that you are using a graphical display
system. The current tutorial gets onto those in line 974 (give or take a
bit).

Phil

[Rusi]

On Monday, May 11, 2015 at 10:41:58 PM UTC+5:30, Drew Adams wrote:

>
> > That's good for that use case. But there are other use cases, such
> > as someone who's intrigued and wants to "check it out". In that case,
> > the tutorial should mostly try and showcase what you can do with Emacs.
>
> No, those are not use cases for a *tutorial*. Those are use cases for
> a demo or a user guide or an introduction/overview.

From http://en.wikipedia.org/wiki/Tutorial#Internet

-------------------------

utorials usually have the following characteristics:

A presentation of the view usually explaining and showing the user the user interface

A demonstration of a process, using examples to show how a workflow or process is completed; often broken up into discrete modules or sections.

Some method of review that reinforces or tests understanding of the content in the related module or section.

A transition to additional modules or sections that builds on the instructions already provided. Tutorials can be linear or branching.

While many writers refer to a mere list of instructions or tips as a tutorial, this usage can be misleading.

[Stefan Monnier]

> Btw, it could just be that the "someone intrigued" use case could be
> better served by a separate document, also reachable from Help.

That was my assumption. A tutorial should be reasonably short, so
I don't think we can have a single tutorial that covers both cases
without either of the two use-cases suffering.


Stefan

[Eli Zaretskii]

> From: philli...@newcastle.ac.uk (Phillip Lord)
> Cc: <help-gn...@gnu.org>

> Date: Mon, 11 May 2015 18:20:38 +0100

>
> I talk about the UI basics because you have to know what "buffer" means
> or the menu makes little sense ("Buffers" or "Eval Buffer" from python).
> And it does assume from the start that you are using a graphical display
> system. The current tutorial gets onto those in line 974 (give or take a
> bit).

That's because the current tutorial doesn't describe a term until it
is actually used. As long as you type in a single buffer, you don't
need to know that buffers exist.

[Stefan Monnier]

> No, those are not use cases for a *tutorial*. Those are use cases for
> a demo or a user guide or an introduction/overview.

I disagree. Someone who's interested in trying out Emacs might like to
write some Python code (say), and might be better served by a tutorial
that showcases what Emacs can do in that specific context, focusing on
how to use various features like completion, eldoc, interaction with an
inferior process, installing new ELPA packages, looking up help,
tweaking the indentation rules, ...

> A tutorial is about learning by *doing*.

That's a property of its form, not its function.


Stefan

[Drew Adams]

> > No, those are not use cases for a *tutorial*. Those are use cases
> > for a demo or a user guide or an introduction/overview.
>
> I disagree. Someone who's interested in trying out Emacs might like
> to write some Python code (say), and might be better served by a
> tutorial that showcases what Emacs can do in that specific context,
> focusing on how to use various features like completion, eldoc,
> interaction with an inferior process, installing new ELPA packages,
> looking up help, tweaking the indentation rules, ...

So? You're just saying that such a person could benefit from a
*tutorial* that is oriented toward using Emacs with Python.

Nothing wrong with that. You can learn to bake cookies using a
cookie-baking tutorial, and you can learn to feed turtles using a
turtle-feeding tutorial. Why not?

> > A tutorial is about learning by *doing*.
>
> That's a property of its form, not its function.

Tutorial vs demo vs user guide overview vs cheat sheet... *is*
about form difference. The function of any or all such forms of
help can be to serve as an introduction to learning a subject.
They do it differently.

And of course it is possible to combine different forms.

You can call anything a tutorial if you like. I don't care.

For me, a tutorial is something that involves the user *doing
stuff*, not just viewing or reading. Think of the difference
between reading a Shakespeare play and acting it out.

A tutorial is inherently *interactive*. There is some (clear)
way to "act it out"). There may even be several such ways.
This is the case even if the way the recipe to follow is
communicated by watching a video or playing a game or reading
or telepathy or...

Typically, a tutorial walks users through the recipe in some
way, or helps them walk themselves through it.

So yes, the difference that makes something a tutorial is a
difference of form, but a tutorial can take multiple forms.

If it is not easy to "follow along" by doing something
yourself (at least doing something in imagination, but
preferably physically too), then the learning tool is not
much of a tutorial, IMO. It may still be a good learning
tool, even if it is not a very good tutorial.

A good tutorial has clear instructions, whether or not there
might be multiple possibilities (different ways to follow,
different routes to take).

[Marcin Borkowski]

On 2015-05-11, at 18:30, Eli Zaretskii <el...@gnu.org> wrote:

> Btw, it could just be that the "someone intrigued" use case could be

> better served by a separate document, also reachable from Help. It
> is, after all, quite a different goal -- to "sell" Emacs to newcomers,
> rather than teach them to use it.

No. /This/ should be reachable by C-x C-c.

"So you want to quit. Before you go, let me show you what I can do for
you. You will change your mind then."

;-)

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

[Rusi]

On Tuesday, May 12, 2015 at 2:09:00 AM UTC+5:30, Marcin Borkowski wrote:

> On 2015-05-11, at 18:30, Eli Zaretskii wrote:
>
> > Btw, it could just be that the "someone intrigued" use case could be
> > better served by a separate document, also reachable from Help. It
> > is, after all, quite a different goal -- to "sell" Emacs to newcomers,
> > rather than teach them to use it.
>
> No. /This/ should be reachable by C-x C-c.
>
> "So you want to quit. Before you go, let me show you what I can do for
> you. You will change your mind then."
>
> ;-)

Many of those tearing their hair and screaming "I want to quit!!"
have no idea that C-x C-c will soothe the soul :-)

Still less the locution "C-x C-c"
[In all fairness Menu → File → Quit helps]

[Rusi]

On Monday, May 11, 2015 at 11:40:12 PM UTC+5:30, Stefan Monnier wrote:
> > No, those are not use cases for a *tutorial*. Those are use cases for
> > a demo or a user guide or an introduction/overview.
>
> I disagree. Someone who's interested in trying out Emacs might like to
> write some Python code (say), and might be better served by a tutorial
> that showcases what Emacs can do in that specific context, focusing on
> how to use various features like completion, eldoc, interaction with an
> inferior process, installing new ELPA packages, looking up help,
> tweaking the indentation rules, ...

Around the time org mode manual crossed the 200(?) page mark there was some
talk of having a mini-manual or something like that

At that time I suggested that since org is a world in itself
a bunch of intros targeted at specific audiences may be a good idea:

https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00660.html
https://lists.gnu.org/archive/html/emacs-orgmode/2009-02/msg00197.html

Since emacs is a superset of org half dozen emacs-intros from different slants
could certainly help

[Rasmus]

Rusi <rusto...@gmail.com> writes:

> Around the time org mode manual crossed the 200(?) page mark there was some
> talk of having a mini-manual or something like that

Such a thing exists, but I don't think it ships with Emacs. See:
http://orgmode.org/cgit.cgi/org-mode.git/tree/doc/orgguide.texi
--
9000!

[Eli Zaretskii]

> Date: Mon, 11 May 2015 21:07:36 -0700 (PDT)
> From: Rusi <rusto...@gmail.com>

>
> Since emacs is a superset of org half dozen emacs-intros from different slants
> could certainly help

Each chapter in the Emacs manual is a short intro to the subject of
that chapter.

[Rusi]

On Tuesday, May 12, 2015 at 9:42:10 PM UTC+5:30, Eli Zaretskii wrote:
> > Date: Mon, 11 May 2015 21:07:36 -0700 (PDT)
> > From: Rusi
> >

> > Since emacs is a superset of org half dozen emacs-intros from different slants
> > could certainly help
>
> Each chapter in the Emacs manual is a short intro to the subject of
> that chapter.

There is a fundamental difference between logical and pedagogical order.

If I may quote Minsky's Turing lecture

|There is a real conflict between the logician's goal and the educator's. The
| logician wants to minimize the variety of ideas, and doesn't mind a long, thin
| path. The educator (rightly) wants to make the paths short and doesn't mind-in
| fact, prefers-connections to many other ideas. And he cares almost not at all
| about the directions of the links.

The emacs manual may be logically structured.
It is not structured to be inviting to a noob -- whether of Drew's or of
Stefan's variety.

Joe Noob has a need that is completely covered in chaps i,(more likely i,j,k)
of the manual. How does he go from his need to chaps i,j,k?

Lets say that dired and even better wdired is exactly what he needs. How is he
going to find that out?

[Eli Zaretskii]

> Date: Tue, 12 May 2015 09:55:47 -0700 (PDT)
> From: Rusi <rusto...@gmail.com>
>

> > Each chapter in the Emacs manual is a short intro to the subject of
> > that chapter.
>
> There is a fundamental difference between logical and pedagogical order.

Indeed, it is. But I don't see the relevance of that to the issue at
hand.

> The emacs manual may be logically structured.

No, it is intended to be pedagogically structured. If you find
evidence to the contrary, i.e. style that is typical of academic
papers, please report that as a bug.

> Joe Noob has a need that is completely covered in chaps i,(more likely i,j,k)
> of the manual. How does he go from his need to chaps i,j,k?

Via cross-references and menus, of course. And via index search.

> Lets say that dired and even better wdired is exactly what he needs. How is he
> going to find that out?

I would start by typing "i directory TAB", then see "directory
listing" there, and select it. And there, lo and behold, I'd see
this:

The file system groups files into "directories". A "directory listing"
is a list of all the files in a directory. Emacs provides commands to
create and delete directories, and to make directory listings in brief
format (file names only) and verbose format (sizes, dates, and authors
included). Emacs also includes a directory browser feature called
Dired; see *note Dired::. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^

Then I'd follow that Dired hyperlink, and in the menu, due to some
sheer luck (or maybe something else) I'd see this, inter alia:

* Wdired:: Operating on files by editing the Dired buffer.

and also

* Image-Dired:: Viewing image thumbnails in Dired.

and lots of other interesting and relevant topics.

[Rusi]

On Tuesday, May 12, 2015 at 11:16:00 PM UTC+5:30, Eli Zaretskii wrote:
> > Date: Tue, 12 May 2015 09:55:47 -0700 (PDT)
> > From: Rusi
> >

I just picked the dired/wdired eg at random
And now I look (emacs 24.3.1)

Where-is: wdired-change-to-wdired-mode <Menubar> <Immediate> <Wdired-mode>
But I dont see any Wdired in menu → immediate

[Drew Adams]

> Where-is: wdired-change-to-wdired-mode <Menubar> <Immediate>
> <Wdired-mode> But I dont see any Wdired in menu → immediate

Immediate > Edit File Names (C-x C-q)

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 12, 2015 at 08:45:39PM +0300, Eli Zaretskii wrote:

[...]

> I would start by typing "i directory TAB", then see "directory
> listing" there, and select it. And there, lo and behold, I'd see
> this:

Really good example you got there, which nicely stresses the strengths
and weaknesses of the whole thing. Two notes:

1. I've been using Emacs for quite a while. I'm perhaps atypical
in that I learn in leaps and bounds and not very systematically.
It took me several years (three? four?) to learn about "i".
Before, I used "s". I shouldn't have been allowed to *touch*
Emacs without knowing about Info's "i" (see below for some
thoughts on that)

2. I enter "i folder TAB" and get no entries. Hmmm.

Ad 1: I think an intro should blaze a wide track collecting the
indispensable tools to get up and running (and only hinting at
alternatives).

Which are the "indispensable tools" is very much a matter of taste
and of "current fashion": it will vary over users and time.

Most user nowadays will be happy to use the (these days) conventional
cursor keys for movement (and discover to their delight that C-Left
jumps by words, wow!), click on menus and so on. Thus (one variant of)
tutorial would *only hint* (with links) at the existence of C-f etc.
which are so close to the hearts of the old garde. Heck, I'm an
old fart and *even on vi* (which I spell vim) I don't "HJKL" but use
the cursor keys (which are more within reach these days as nearly
everyone who has still a keyboard is on some kind of netbook).

Ad 2: As Emacs is used by a more diverse population, it has to talk
a broader language set. Besides, language(s) evolve over time.

I know that there's an effort to add synonyms to the index (see?
I tried to look up "synonym" in the info manual. No hits ;-) --
but I don't believe that it scales as it is, done by hand by
a handful of heroes (no, really, I have a ton of appreciation for
this work: Emacs has given me more joy that I'm able to express
in a few words) -- one bug report at a time.

I think we need new ideas here, therefore I'm really excited that
Vaidheeswaran C is taking a try at it. Thanks!

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlVTAZcACgkQBcgs9XrR2kYrmwCeIN51fAqqSoJ/7FyQ4YYd0P/X
3GIAn1lB5a/AnxuxXKSqcFIqU078V42V
=2p7g
-----END PGP SIGNATURE-----

[Filipp Gunbin]

On 13/05/2015 09:47 +0200, to...@tuxteam.de wrote:

> Most user nowadays will be happy to use the (these days) conventional
> cursor keys for movement (and discover to their delight that C-Left
> jumps by words, wow!), click on menus and so on. Thus (one variant of)
> tutorial would *only hint* (with links) at the existence of C-f etc.
> which are so close to the hearts of the old garde. Heck, I'm an
> old fart and *even on vi* (which I spell vim) I don't "HJKL" but use
> the cursor keys (which are more within reach these days as nearly
> everyone who has still a keyboard is on some kind of netbook).

When using arrow keys for movement there's a danger that Emacs will turn
into one big inconvenience.

Rather, large amount of different keys to remember could lead to
thinking of a suitable typing scheme and that's imho is an enjoyable
thing.

When I realized that right-hand modifiers can be used as well as
left-hand, it made my experience much more pleasant.

Filipp

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 13, 2015 at 03:10:02PM +0300, Filipp Gunbin wrote:
> On 13/05/2015 09:47 +0200, to...@tuxteam.de wrote:
>
> > Most user nowadays will be happy to use the (these days) conventional

> > cursor keys for movement [...]

> When using arrow keys for movement there's a danger that Emacs will turn
> into one big inconvenience.

This is obviously in the eye (rather the finger) of the beholder. I wasn't
advocating to remove the traditional movement keys in Emacs. I was rather
questioning that they deserve such a prominent place in a beginner's
tutorial (although a link, with a short explanation of their advantages
seems to make a lot of sense in any case).

> Rather, large amount of different keys to remember could lead to
> thinking of a suitable typing scheme and that's imho is an enjoyable
> thing.

Different finger memories, different models. The key bindings of the
arrow keys (with and without modifiers) might make more sense to some --
especially when you have an "exotic" keyboard layout: cf. the other
current thread in this list. At least, the arrow keys stay invariant.

> When I realized that right-hand modifiers can be used as well as
> left-hand, it made my experience much more pleasant.

Yep, and with some binding magic one can re-use those funny (nowadays
nearly ubiquitous) "Windows" keys. But this is all advanced material,
where our topic here is "Tutorial(s) for beginners".

I'm not for hiding that information -- but thinking about a short,
wide path to start with, showing hints to all sorts of (narrower)
side paths, to let people "grow" at their own pace.

regards

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlVTRE8ACgkQBcgs9XrR2kZQ1gCdFgzQU00xdnNduHdgAo3qSLih
MqYAn3qJCFnP/d95VYT56QeBpTT8CERr
=s+oB
-----END PGP SIGNATURE-----

[Filipp Gunbin]

On 13/05/2015 14:32 +0200, to...@tuxteam.de wrote:

> I wasn't advocating to remove the traditional movement keys in
> Emacs. I was rather questioning that they deserve such a prominent
> place in a beginner's tutorial (although a link, with a short
> explanation of their advantages seems to make a lot of sense in any
> case).

To speak for myself - the best tutorial for me was the key bindings
cheatsheet. Of course, I barely understood the description of some of
them (`C-x c-x', for example), but it was interesting to experiment.

>> Rather, large amount of different keys to remember could lead to
>> thinking of a suitable typing scheme and that's imho is an enjoyable
>> thing.
>
> Different finger memories, different models. The key bindings of the
> arrow keys (with and without modifiers) might make more sense to some --
> especially when you have an "exotic" keyboard layout: cf. the other
> current thread in this list. At least, the arrow keys stay invariant.

The arrow keys aren't conveniently located, even the touch pad (on
laptops which have it) is easier to access.

>> When I realized that right-hand modifiers can be used as well as
>> left-hand, it made my experience much more pleasant.
>
> Yep, and with some binding magic one can re-use those funny (nowadays
> nearly ubiquitous) "Windows" keys. But this is all advanced material,
> where our topic here is "Tutorial(s) for beginners".

For me, the main point is whether the modifier key is doubled on both
sides of Space. "ctrl" key on the Mac keyboard, for example, is not.
As I can see on my colleagues' keyboards, "Win" key is.

For a beginner, some bindings (like `C-t') may seem too hard to press
unless they are pressed with two hands, which is not the obvious way.

Filipp

[Eli Zaretskii]

> Date: Wed, 13 May 2015 09:47:35 +0200
> Cc: help-gn...@gnu.org
> From: <to...@tuxteam.de>

>
> > I would start by typing "i directory TAB", then see "directory
> > listing" there, and select it. And there, lo and behold, I'd see
> > this:
>
> Really good example you got there

It's not me, I just worked the example suggested by Rusi.

> 1. I've been using Emacs for quite a while. I'm perhaps atypical
> in that I learn in leaps and bounds and not very systematically.
> It took me several years (three? four?) to learn about "i".
> Before, I used "s". I shouldn't have been allowed to *touch*
> Emacs without knowing about Info's "i" (see below for some
> thoughts on that)

Should probably be added to the end of the tutorial.

> 2. I enter "i folder TAB" and get no entries. Hmmm.

Please make a bug report in any such case.

> Ad 1: I think an intro should blaze a wide track collecting the
> indispensable tools to get up and running (and only hinting at
> alternatives).

I don't think this is practical, for at least 2 reasons:

. the number of indispensable tools is very large
. the set of such tools is highly dependent on what you want to do
in Emacs

> Which are the "indispensable tools" is very much a matter of taste
> and of "current fashion": it will vary over users and time.

Exactly, so it is impractical to have them in an introductory text.

> Heck, I'm an old fart and *even on vi* (which I spell vim) I don't
> "HJKL" but use the cursor keys

And yet the Vim tutorial starts with description of cursor motion.

[Rusi]

On Wednesday, May 13, 2015 at 10:07:58 PM UTC+5:30, Eli Zaretskii wrote:

> > From: tomas
> > Ad 1: I think an intro should blaze a wide track collecting the
> > indispensable tools to get up and running (and only hinting at
> > alternatives).
>
> I don't think this is practical, for at least 2 reasons:
>
> . the number of indispensable tools is very large
> . the set of such tools is highly dependent on what you want to do
> in Emacs
>
> > Which are the "indispensable tools" is very much a matter of taste
> > and of "current fashion": it will vary over users and time.
>
> Exactly, so it is impractical to have them in an introductory text.

This underscores the difference in profile of the user who needs a
Drew tutorial and one who needs a Stefan tutorial
The first being more educational the second more adverise-ial

>
> > Heck, I'm an old fart and *even on vi* (which I spell vim) I don't
> > "HJKL" but use the cursor keys
>
> And yet the Vim tutorial starts with description of cursor motion.

vim and emacs are the only apps (I know and in current wide use) that
dont follow the cua- specification.

Speaking of cua, before someone unwinds the usual spiel about "If you want Word
use Word etc etc" it would be good to read the following from Doug Adams


1) everything that's already in the world when you're born is just
normal;

2) anything that gets invented between then and before you turn
thirty is incredibly exciting and creative and with any luck you can
make a career out of it;

3) anything that gets invented after you're thirty is against the
natural order of things and the beginning of the end of civilisation
as we know it until it's been around for about ten years when it
gradually turns out to be alright really.

[Eli Zaretskii]

> Date: Thu, 14 May 2015 19:56:12 -0700 (PDT)
> From: Rusi <rusto...@gmail.com>
>

> > And yet the Vim tutorial starts with description of cursor motion.
>
> vim and emacs are the only apps (I know and in current wide use) that
> dont follow the cua- specification.

How CUA is relevant in the context of discussing cursor motion?

[Rusi]

On Friday, May 15, 2015 at 1:01:36 PM UTC+5:30, Eli Zaretskii wrote:
> > From: Rusi

> >
> > > And yet the Vim tutorial starts with description of cursor motion.
> >
> > vim and emacs are the only apps (I know and in current wide use) that
> > dont follow the cua- specification.
>
> How CUA is relevant in the context of discussing cursor motion?

Its 2015.
You dont need to explain things like cursor-movement [do people read/need
notepad or gedit tutorials?] unless its rather non-standard.

Of course in 1975 it was different... But history is unlikely to be of interest
to someone who needs an emacs-tutorial.

[Disclaimer: Whether cursor-movement is technically part of the cua-specification...
If so which version of cua??
etc
I dont know
]

[Eli Zaretskii]

> Date: Fri, 15 May 2015 04:12:28 -0700 (PDT)
> From: Rusi <rusto...@gmail.com>
>

> On Friday, May 15, 2015 at 1:01:36 PM UTC+5:30, Eli Zaretskii wrote:
> > > From: Rusi
> > >
> > > > And yet the Vim tutorial starts with description of cursor motion.
> > >
> > > vim and emacs are the only apps (I know and in current wide use) that
> > > dont follow the cua- specification.
> >
> > How CUA is relevant in the context of discussing cursor motion?
>
> Its 2015.
> You dont need to explain things like cursor-movement [do people read/need
> notepad or gedit tutorials?] unless its rather non-standard.

Emacs is neither notepad nor gedit, and we describe cursor motion
because the ergonomic commands for that are "rather non-standard", or
at least could be for people whose only experience is gedit or
notepad.

> Of course in 1975 it was different...

It's different today as it was different in 1985. And we do mention
the arrow keys and PageUp/PageDown before we describe the
Emacs-specific bindings. So I really see no reason to complain,
except if you have an agenda.

[Phillip Lord]

Eli Zaretskii <el...@gnu.org> writes:
>> Its 2015.
>> You dont need to explain things like cursor-movement [do people read/need
>> notepad or gedit tutorials?] unless its rather non-standard.
>

> Emacs is neither notepad nor gedit, and we describe cursor motion
> because the ergonomic commands for that are "rather non-standard", or
> at least could be for people whose only experience is gedit or
> notepad.
>

>> Of course in 1975 it was different...
>

> It's different today as it was different in 1985. And we do mention
> the arrow keys and PageUp/PageDown before we describe the
> Emacs-specific bindings. So I really see no reason to complain,
> except if you have an agenda.

I suspect that Rusi's agenda is to make the Emacs tutorial as easy to
understand as possible.

I've rarely managed to get one of my students to read the tutorial. I
would like to be able to change that situation. It's good to think of
how.

Phil

[Rusi]

On Friday, May 15, 2015 at 7:14:52 PM UTC+5:30, Phil Lord wrote:

Thanks Phil

Only change I'd make to your representation of my 'agenda' is that
I'd change 'easy' to 'useful'
This in line with Stefan's understanding that different audiences would
likely require different starting points.

eg For git there was a "Git for Computer Scientists"
Presumably a CSist is one who would understand (and feel pleased with
understanding) graphs, dags etc
Putting aside the naivete of that view the point is that some people may like to
start looking at git 'as CSists' and others may not

Likewise emacs

"Emacs for typing tamil"
(to pick up an adjacent thread) is likely to read differently from
"Emacs for C programmers"
from
"Master GTD with emacs and org mode"
from
"Live online inside emacs! -- gnus, erc, sx"

[Eli Zaretskii]

> Date: Fri, 15 May 2015 07:01:55 -0700 (PDT)
> From: Rusi <rusto...@gmail.com>
>

> > I suspect that Rusi's agenda is to make the Emacs tutorial as easy to
> > understand as possible.
> >
> > I've rarely managed to get one of my students to read the tutorial. I
> > would like to be able to change that situation. It's good to think of
> > how.
>
> Thanks Phil
>
> Only change I'd make to your representation of my 'agenda' is that
> I'd change 'easy' to 'useful'

Then why are you talking about cursor motion and its place in the
tutorial? What does that tiny detail have to do with making the
tutorial easier/more useful?

Like I said: changes and even complete rewrites of the tutorial are
welcome. But it has to be a more or less complete job, not just the
first few paragraphs.

(Minor changes to the tutorial are also welcome, but then we aren't
really talking about revolutionary new ideas, do we?)

> This in line with Stefan's understanding that different audiences would
> likely require different starting points.
>
> eg For git there was a "Git for Computer Scientists"
> Presumably a CSist is one who would understand (and feel pleased with
> understanding) graphs, dags etc
> Putting aside the naivete of that view the point is that some people may like to
> start looking at git 'as CSists' and others may not
>
> Likewise emacs
>
> "Emacs for typing tamil"
> (to pick up an adjacent thread) is likely to read differently from
> "Emacs for C programmers"
> from
> "Master GTD with emacs and org mode"
> from
> "Live online inside emacs! -- gnus, erc, sx"

These are tutorials for users who already mastered the basics. IMO,
they belong to the respective manuals, the one for Org, Gnus, etc.,
but we could also maintain them as separate documents.

In any case, that is a far cry from the tutorial we were talking
about, which could only touch these advanced topics after covering a
lot of turf, without which you cannot even start to describe them.

But feel free to contradict me -- by actually writing such a tutorial.

TIA

[MBR]

What about trying a different approach? Telling them, "Learn Emacs.
You'll find it useful in the long run," is guaranteed to make them hate
it. It's like being told, "Eat your vegetables. They're good for you."

Instead, why not challenge them to do some task whose end result they'll
consider useful, but that you know will be a royal pain in the ass to do
with a simple-minded text editor. Make sure it's not something
contrived. Tell them to use whatever editor they're most comfortable
with. After 15 min. or more of tedious editing in their underpowered,
brain-dead editor, show them that you can do the same thing in 15
seconds using some general-purpose Emacs feature.

I say "general-purpose Emacs feature" because it's important that they
see that they could use this functionality for lots of tasks they run
into all the time. So I wouldn't choose C-M-q, (i.e. c-indent-exp)
because that's too specific to a single task. Instead, how about
something like C-x (, (i.e. kmacro-start-macro) followed by C-x e (i.e.
kmacro-end-and-call-macro) with a large repeat count. You can reformat
from any format to damned near any other format just by showing Emacs
how to do it once and then repeating it. And telling Emacs to remember
and replay what you just typed is much easier for a newbie to comprehend
than doing it with a regular expression.

Even better than you showing off would be to plant a shill in the
crowd. All you need is one student who already knows some Emacs. Then
when he's finished in under a minute and they're still tediously slaving
away 15 or 20 minutes later, they're going to be asking him how the hell
he did it so fast. He'll sell Emacs for you.

If you start off by showing (not telling) them Emacs' value, I bet there
will be a lot less grumbling about having to learn a few unfamiliar
keystrokes for navigating.

Mark Rosenthal

On 5/10/15 10:01 AM, Rusi wrote:
> On Sunday, May 10, 2015 at 8:18:20 AM UTC+5:30, Bob Proulx wrote:
>> Marcin Borkowski wrote:
>>> Bob Proulx wrote:
>>>> A student says that they really want to learn Calculus. They know
>>>> that Calculus is very powerful and can be used to solve many problems.
>>>> I suggest that they learn Arithmetic first. They respond,
>>>> "Arithmetic! Have you learned Arithmetic? Arithmetic is old. Should
>>>> I learn Arithmetic? For example, will Arithmetic talk about
>>>> Calculus?"
>>> Nice try;-). But this analogy is flawed: software, unlike mathematical
>>> theories, is subject to change.
>> Has emacs changed that much? I don't think it has. It is still very
>> much the same.
> Sad but true
>
> After 20 years of using, teaching with, and making my students use emacs,
> for the first time this year I taught python using Idle rather than emacs.
> Some nuisances... C-a now means Select-all whereas my nerve-pathways know it as
> Beginning-of-line etc etc
> Also some sadness... however one needs to get real and selling emacs to students
> has led to lot of funny looks and some significant hostility.
>
> The tutorial with C-f C-b... for cursor movements was I guess the last straw
>
> What I describe may sound like exaggeration but that's only because I am trying to
> reconstruct what happens between noob and emacs when I am not around.
>
> Student starts reading tutorial and sees the C-f C-b stuff:
>
> - Some follow it wonder about the weirdness but then get on with it
> - Some just use cursor keys like the rest of the planet ignore the C-f C-b
> stuff and get on with it
> - But a few notice that cursor keys work as they should but is not documented
> and are a bit confused/bewildered
> - And of those few, a few get real HOSTILE
>
> Now if the cursor-keys didn't work it would not be so bad
> And ideal would be for them to work AND be documented
> But works and NOT documented/demoed in tutorial... and there are serious
> allegations of ATTITUDE!
>
> [And I am implicated with the emacs-devs :-) ]
>

[Doug Lewan]

> -----Original Message-----
> On
> Behalf Of MBR
> Subject: Re: Emacs Book Vs Emacs Manuals

>
> Instead, why not challenge them to do some task whose end result
> they'll
> consider useful, but that you know will be a royal pain in the ass to
> do
> with a simple-minded text editor. Make sure it's not something
> contrived. Tell them to use whatever editor they're most comfortable
> with. After 15 min. or more of tedious editing in their underpowered,
> brain-dead editor, show them that you can do the same thing in 15
> seconds using some general-purpose Emacs feature.

I agree. Letting them do a complex repetitive task would be a good demonstration.

Here's my proposed task; I do this all the time during development.

Given a long structure of some sort, write a print function for it.
The wrapper is easy, something like the following:
void
print_long_structure (FILE *fp, long_struct_t *ls)
{
fprintf(fp,"long structure name:\n");

return;
}
Each element should be printed on a line of its own, indented a little with name and value separated by TAB:
structure_element_name: element_value

If you know emacs, then it's an obvious keyboard macro.
If not, then there's some education to be had,
including rehearsing keyboard macros,
thinking about initial conditions,
preparing for the next iteration (forward-line), etc.

Once you get through all that, writing the code for the next, e.g. 30 lines is easy and very satisfying.

I hope this is worthwhile to someone.

--
,Doug
Douglas Lewan
Shubert Ticketing
(201) 489-8600 ext 224 or ext 4335

The human brain is the most complex thing known to man, according to the human brain.

[Emanuel Berg]

MBR <m...@arlsoft.com> writes:

> What about trying a different approach?
> Telling them, "Learn Emacs. You'll find it useful in
> the long run," is guaranteed to make them hate it.
> It's like being told, "Eat your vegetables.
> They're good for you."
>
> Instead, why not challenge them to do some task
> whose end result they'll consider useful, but that
> you know will be a royal pain in the ass to do with
> a simple-minded text editor. Make sure it's not
> something contrived. Tell them to use whatever
> editor they're most comfortable with. After 15 min.
> or more of tedious editing in their underpowered,
> brain-dead editor, show them that you can do the
> same thing in 15 seconds using some general-purpose
> Emacs feature.

I agree telling people stuff in general and trying to
convince them is pointless, perhaps even counter
productive. It is like all the criminals and
disfunctional crazy people in jails and institutions.
Why did they end up there? I guess they didn't read
the law book! Perhaps the authorities should compile
a simplified version and hand it out so the convicts
can read it after dropping the soap in the shower
room...

A better approach is to just have the software we like
*exposed* to as many people as possible, and in as
many ways as possible. A minority - small, but still -
will be curious, and a minority of the minority will
instantly see this is something they will like, a lot.
This is what happened to me. I don't remember
switching from nano to Emacs but I also do not
remember ever wanting to go back.

Use the software, and do cool things with it. If that
doesn't work on people, is there anything we can say,
or do, or write that will make for better PR, that
will work? And: do we even *want* it to work on the
people which were unaffected by the cool things that
were all natural at that?

But then, how do we expose it to people?
Answer: activity.

Here are some examples:

When I wrote my Bachelor degree paper, I included
a screenshot of Emacs and some comments (it was
a subsection of the paper comparing interfaces).
When I wrote my Master, I used (and included in the
report) a short Elisp program to do some computation.
I also made an experiment when a compilation process
was timed in different settings - what I compiled was
actually my Emacs, Gnus, w3m (etc.) init files! As you
correctly suspect, this was only some 50% convenience
(and even less practical necessity), the rest 50% was
propaganda and "coolness", and the most important 50%
was enjoyment being active with my favorite tools
(yes, you get an extra 50% if you do all those).
Later I gave a talk to describe some project, and
instead of the pathetic "Power"Point I used Emacs -
figures were ASCII and Unicode, and I had setup
ultra-fast shortcuts to jump between and across the
material (from anywhere to everywhere). This worked as
the confidence of using what I use every day didn't
disappear with the rest of the home-field advantage,
and besides I could show code and respond to questions
by showing stuff the same way I access it every day,
and then when done carry on with the presentation by
going to the next figure - like this:

http://user.it.uu.se/~embe8573/dumps/scheduler.png

Another example is, I use BibLaTeX to keep track of
what I read, so every time I discuss books with my
friend the next day I send them a mail - again
ultra-fast and convenient - just a yank from the .bib
source to the message-buffer - "this was the book you
asked me about" -

@book{aku-aku,
author = {Thor Heyerdahl},
publisher = {Bonniers},
title = {Aku-aku. Påsköns hemlighet},
year = 1957
}

I use Elisp to keep track of birds so I can add new
ones without updating the sum digit each time:

http://user.it.uu.se/~embe8573/BIRDS

And so on. I always find new, unexpected things to do
with it. And that is the best I can do! I personally
would not mind meeting cool people who do amazing
stuff. While I unsure I can be that cool person to
anyone, I am 100% convinced if I were to take the
"convince approach", I could speak to every girl in
the entire public library Tuesday afternoon and
I wouldn't turn a single one of them into Emacs, Gnus,
Usenet, or zsh users (if anything, I'd be banned from
the building, and I even know all the staff!).
And even if I could convince people - which
I absolutely can't - I wouldn't enjoy doing it, tho it
would be beneficial to them to stop do the iPhone
idiocy (and interesting to me, as it is so alone at
the top ;)) - but it plain *doesn't work*, so why be
frustrated about it?

--
underground experts united
http://user.it.uu.se/~embe8573

[Emanuel Berg]

Doug Lewan <do...@shubertticketing.com> writes:

> If you know emacs, then it's an obvious keyboard
> macro.

Keyboard macros is poor-man's programming and while
they can be useful in many situations it is in many
more situations better to write proper Lisp. When one
gets some fluency with it it is not only infinitely
more powerful (obviously) but also faster, safer, and
less frustrating than keyboard macros.

[Yuri Khan]

On Sat, May 16, 2015 at 2:18 AM, Emanuel Berg <embe...@student.uu.se> wrote:

> Keyboard macros is poor-man's programming and while
> they can be useful in many situations it is in many
> more situations better to write proper Lisp. When one
> gets some fluency with it it is not only infinitely
> more powerful (obviously) but also faster, safer, and
> less frustrating than keyboard macros.

For recurring tasks, yes. But for a one-off highly repetitive task, a
macro is cheaper to set up.

Also, macros can be viewed as a gateway drug to programming.

[Vaidheeswaran C]

On Monday 11 May 2015 09:36 PM, Eli Zaretskii wrote:
>> From: Vaidheeswaran C <vaidheeswara...@gmail.com>
>> Date: Mon, 11 May 2015 11:00:09 +0530
>>
>>>> What I call as "A Book", may not in actuality be a book as it is
>>>> conventionally understood and consumed.
>>>
>>> Then what is it? And why would people want to use it, instead of
>>> googling?
>>>
>>> Without some "glue", there's no added value to a book that just brings
>>> together unsorted tops that are already available on the Web.
>>
>> You can help me define the "glue".
>
> It's that stuff that guides the reader from one feature to another,
> and generally allows the reader to make sense out of a huge pile of
> loosely related features.
>
> E.g., when you describe commands that act on buffers, they should be
> described in some methodical manner, and the order should make some
> sense, and facilitate understanding and memorizing them.

DITA and Robert E Horn's work on Structured Writing could __inform__
our efforts. See below for more details.

Here is a quick summary of DITA (from Wikipedia page).

| DITA content is created as topics. Typically, each topic covers a
| specific subject with a singular intent, for example, a conceptual
| topic that provides an overview, or a procedural topic that explains
| how to accomplish a task.


For the sake of discussion, let us pretend that my proposed "Book"
will be task-oriented and include guidelines (platform-specific or
locale-specific). Each task-oriented node will cross-reference some
or more of standard Info nodes. (The cross-reference can be to a link
to a concept or a node in the glossary).

----------------------------------------------------------------

On the topic of "glues",

| See
http://www.scriptorium.com/2009/12/assessing-dita-as-a-foundation-for-xml-implementation/

| The topic-oriented architecture requires that authors create
| modular, self-contained information. For content creators who are
| accustomed to working on cohesive books, this can be rather a
| difficult transition.

| One topic (sorry!) of heated discussion is the issue of “glue text,”
| the content that provides coherent transitions from one topic to
| another. Some argue that glue text is unnecessary and that
| transitions are overrated; at the other extreme is the opinion that
| modules without transitions are unusable. If you belong to the
| latter group, keep in mind that implementing transitional text in
| DITA is quite difficult. Transition text that makes sense in one
| context might not be relevant in another.

----------------------------------------------------------------

| From http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
|
| Information typing
|
| DITA includes three specialized topic types: Task, Concept, and
| Reference. Each of these three topic types is a specialization of a
| generic Topic type, which contains a title element, a prolog element
| for metadata, and a body element. The body element contains
| paragraph, table, and list elements, similar to HTML.
|
| - A (General) Task topic is intended for a procedure that describes
| how to accomplish a task. A Task topic lists a series of steps
| that users follow to produce an intended outcome. The steps are
| contained in a taskbody element, which is a specialization of the
| generic body element. The steps element is a specialization of an
| ordered list element.
|
| - Concept information is more objective, containing definitions,
| rules, and guidelines.
|
| - A Reference topic is for topics that describe command syntax,
| programming instructions, and other reference material, and usually
| contains detailed, factual material.

----------------------------------------------------------------

Works of Robert E. Horn may be of some interest to current
discussion. (See http://www.amazon.com/Robert-E.-Horn/e/B000APJGAU).
If any of you is familiar with the works, please check-in ...

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswara...@gmail.com>
> Date: Sat, 16 May 2015 11:20:09 +0530

>
> >> You can help me define the "glue".
> >
> > It's that stuff that guides the reader from one feature to another,
> > and generally allows the reader to make sense out of a huge pile of
> > loosely related features.
> >
> > E.g., when you describe commands that act on buffers, they should be
> > described in some methodical manner, and the order should make some
> > sense, and facilitate understanding and memorizing them.
>
> DITA and Robert E Horn's work on Structured Writing could __inform__
> our efforts. See below for more details.
>
> Here is a quick summary of DITA (from Wikipedia page).
>
> | DITA content is created as topics. Typically, each topic covers a
> | specific subject with a singular intent, for example, a conceptual
> | topic that provides an overview, or a procedural topic that explains
> | how to accomplish a task.

I think the Emacs manuals already conform to this.

> On the topic of "glues",
>
> | See
> http://www.scriptorium.com/2009/12/assessing-dita-as-a-foundation-for-xml-implementation/
>
> | The topic-oriented architecture requires that authors create
> | modular, self-contained information. For content creators who are
> | accustomed to working on cohesive books, this can be rather a
> | difficult transition.
>
> | One topic (sorry!) of heated discussion is the issue of “glue text,”
> | the content that provides coherent transitions from one topic to
> | another. Some argue that glue text is unnecessary and that
> | transitions are overrated; at the other extreme is the opinion that
> | modules without transitions are unusable. If you belong to the
> | latter group, keep in mind that implementing transitional text in
> | DITA is quite difficult. Transition text that makes sense in one
> | context might not be relevant in another.

That's not the "glue" I alluded to.

> | From http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
> |
> | Information typing
> |
> | DITA includes three specialized topic types: Task, Concept, and
> | Reference. Each of these three topic types is a specialization of a
> | generic Topic type, which contains a title element, a prolog element
> | for metadata, and a body element. The body element contains
> | paragraph, table, and list elements, similar to HTML.
> |
> | - A (General) Task topic is intended for a procedure that describes
> | how to accomplish a task. A Task topic lists a series of steps
> | that users follow to produce an intended outcome. The steps are
> | contained in a taskbody element, which is a specialization of the
> | generic body element. The steps element is a specialization of an
> | ordered list element.
> |
> | - Concept information is more objective, containing definitions,
> | rules, and guidelines.
> |
> | - A Reference topic is for topics that describe command syntax,
> | programming instructions, and other reference material, and usually
> | contains detailed, factual material.

Again, I think we already do all that in the Emacs manuals, where
appropriate.

But please note the catch in this approach, if used indiscriminately:
the number of potential "Tasks" that an Emacs user can face is
virtually infinite. These tasks break into certain "building blocks",
which are combined in many different ways. If you always describe the
"tasks", then you will need to repeat the description of these
building blocks time and time again, which is a disadvantage.

IOW, the above methodology is suitable only to relatively simple tools
that support a small number of well-defined tasks. Emacs is not like
that, especially if you take ELisp into consideration, because that's
a reasonably general-purpose programming language, where the
task-based approach is unsuitable, IMO.

[Vaidheeswaran C]

On Saturday 16 May 2015 01:02 PM, Eli Zaretskii wrote:

> Again, I think we already do all that in the Emacs manuals, where
> appropriate.

- Emacs Manual :: I am arguing for FSF-blessed, Task-oriented "Emacs
Primer".

- 'Appropriate' :: The word "Approrpriate" is situational. Who
decides what is appropriate? The maintainers, the
users or the author of the manual.

In so far as "Emacs Primer" is concerned, the Noobs become
authorities. If they say something is "inappropriate" (from where
they stand), then it will be deemed as such, without further
disputation.

> But please note the catch in this approach, if used indiscriminately:
> the number of potential "Tasks" that an Emacs user can face is
> virtually infinite. These tasks break into certain "building blocks",
> which are combined in many different ways. If you always describe the
> "tasks", then you will need to repeat the description of these
> building blocks time and time again, which is a disadvantage.

The question is: Whose "disadvantage" are you talking about?

> IOW, the above methodology is suitable only to relatively simple tools
> that support a small number of well-defined tasks. Emacs is not like
> that, especially if you take ELisp into consideration, because that's
> a reasonably general-purpose programming language, where the
> task-based approach is unsuitable, IMO.

In so far as "Emacs Primer" is concerned, Elisp will be out-of-scope.

If "Appropriate" => ""Completeness", then what you say cannot be
disputed. (See my earlier question on "Appropriateness"). "Emacs
Manual" MAY be considered as a Curriculum but "Emacs Primer" WILL NOT
BE A curriculum.

The cookbooks and recipes are particularly popular and useful
http://www.emacswiki.org/emacs/ElispCookbook. (This is true in spite
of whether Emacs developers approve of such material or not.)

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswara...@gmail.com>
> Date: Sun, 17 May 2015 21:05:26 +0530

>
> On Saturday 16 May 2015 01:02 PM, Eli Zaretskii wrote:
>
> > Again, I think we already do all that in the Emacs manuals, where
> > appropriate.
>
> - Emacs Manual :: I am arguing for FSF-blessed, Task-oriented "Emacs
> Primer".

And I am trying to tell you that a task-oriented Emacs Book might not
be the best idea.

> - 'Appropriate' :: The word "Approrpriate" is situational. Who
> decides what is appropriate? The maintainers, the
> users or the author of the manual.

The maintainers, who are also the authors of the manual. It is always
the author who decides, and users then submit bug reports if they
don't like the result.

> In so far as "Emacs Primer" is concerned, the Noobs become
> authorities. If they say something is "inappropriate" (from where
> they stand), then it will be deemed as such, without further
> disputation.

The issue at hand is not what is "inappropriate", but what is
"appropriate". Saying that some material is described in a way that
hampers understanding and usability is not enough for fixing the
inadequacy: whoever fixes that has to come up with a more
"appropriate" alternative.

IOW, the users complain about the "inappropriate", and no one casts
doubt in their right to do so. But the complaint alone is not enough
to come up with a better alternative. And that is what I was talking
about.

> > But please note the catch in this approach, if used indiscriminately:
> > the number of potential "Tasks" that an Emacs user can face is
> > virtually infinite. These tasks break into certain "building blocks",
> > which are combined in many different ways. If you always describe the
> > "tasks", then you will need to repeat the description of these
> > building blocks time and time again, which is a disadvantage.
>
> The question is: Whose "disadvantage" are you talking about?

Everyone's.

> > IOW, the above methodology is suitable only to relatively simple tools
> > that support a small number of well-defined tasks. Emacs is not like
> > that, especially if you take ELisp into consideration, because that's
> > a reasonably general-purpose programming language, where the
> > task-based approach is unsuitable, IMO.
>
> In so far as "Emacs Primer" is concerned, Elisp will be out-of-scope.

If so, you are limiting the usability of your book too much. Most of
customizations, for example, need to use Lisp, or at least understand
it. If you leave it out of scope, your book will be abandoned by many
users, because most of the tips they will find in the net do use Lisp.

> The cookbooks and recipes are particularly popular and useful
> http://www.emacswiki.org/emacs/ElispCookbook.

I'm saying that a cookbook approach is not advisable, to say the
least, for a tool as complex and versatile/flexible as Emacs.

[Vaidheeswaran C]

On Sunday 17 May 2015 08:17 PM, Eli Zaretskii wrote:

> I am trying to tell you that a task-oriented Emacs Book might not be
> the best idea.

I am trying to get some help and co-operation. I am exploring if there
is a common ground on which we can work together.

I have noted your informed judgement. I have also noted your
reluctance to help me fine tune my proposal.

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswara...@gmail.com>
> Date: Mon, 18 May 2015 08:19:14 +0530

I don't understand where you see reluctance to help. From where I
stand, I just took quite some time to save you from several pitfalls.

You are welcome.

[Bob Proulx]

Yuri Khan wrote:

> Emanuel Berg wrote:
> > Keyboard macros is poor-man's programming and while
> > they can be useful in many situations it is in many
> > more situations better to write proper Lisp. When one
> > gets some fluency with it it is not only infinitely
> > more powerful (obviously) but also faster, safer, and
> > less frustrating than keyboard macros.
>

> For recurring tasks, yes. But for a one-off highly repetitive task, a
> macro is cheaper to set up.
>
> Also, macros can be viewed as a gateway drug to programming.

I have been writing programs for quite a long time. I also use emacs
macros quite a lot too. Both have their proper place. In my mind
macros are mostly interactive while programs are mostly
non-interactive. With a macro it is like using a carving tool on a
piece of wood to create a sculpture. With a program it is like
building a jig to create as many sculptures as desired. It takes more
effort to create a program but having done so it pays more return.
But if just doing something one-off then a macro is less effort.

Bob

[Vaidheeswaran C]

On Monday 18 May 2015 07:45 PM, Eli Zaretskii wrote:

> I don't understand where you see reluctance to help. From where I
> stand, I just took quite some time to save you from several
> pitfalls.

I understand that.

I also understand that you are a old (and stable) hand when it comes
to preparing (instructional) manuals. I will neither question your
intention or expertise.

----------------------------------------------------------------

What I would have ALSO liked to hear from you is your inputs on what
would make "The Emacs Primer" a success. For example, I am thinking
of multiple Emacs primers:

1. An Emacs Primer for Common Text Editing Tasks.
2. An Emacs Primer for Programmers.
3. An Emacs Primer for Thesis Writers.
4 An Emacs Primer for The Network Savvy.

----------------------------------------------------------------

In summary, I really don't want to talk about Emacs Manual. I only
want to hear about it Emacs Primer (which is my current interest).

----------------------------------------------------------------

I would very much appreciate your notings on my (future) drafts.

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswara...@gmail.com>
> Date: Tue, 19 May 2015 11:20:43 +0530

>
> What I would have ALSO liked to hear from you is your inputs on what
> would make "The Emacs Primer" a success. For example, I am thinking
> of multiple Emacs primers:
>
> 1. An Emacs Primer for Common Text Editing Tasks.
> 2. An Emacs Primer for Programmers.
> 3. An Emacs Primer for Thesis Writers.
> 4 An Emacs Primer for The Network Savvy.

I cannot (yet) answer these questions, mainly because it's not clear
to me what would be the scope of such primers. Perhaps you could
clarify that. For example, the Emacs manual has a chapter named
"Commands for Human Languages", which seems to cover the same turf as
your "Common Text Editing Tasks". So what part of that would be in
scope for the "Text Primer"? Same question regarding "Primer for
Programmers" vs. "Editing Programs", "Compiling and Testing Programs",
and maybe also "Maintaining Large Programs".

By "scope" I mean where does each primer start and where does it end?

IOW, I guess it goes back to the questions asked by RMS, which you
didn't (yet) answer.

> I would very much appreciate your notings on my (future) drafts.

When there are drafts, why not?

[Filipp Gunbin]

On 19/05/2015 11:20 +0530, Vaidheeswaran C wrote:

> In summary, I really don't want to talk about Emacs Manual. I only
> want to hear about it Emacs Primer (which is my current interest).

I hope your primer will not be written in such a language.

Filipp

[Emanuel Berg]

Vaidheeswaran C <vaidheeswara...@gmail.com>
writes:

> 1. An Emacs Primer for Common Text Editing Tasks.
> 2. An Emacs Primer for Programmers.
> 3. An Emacs Primer for Thesis Writers.

> 4. An Emacs Primer for The Network Savvy.

Aha, it is the old "suite" idea (as in a card deck)!

Here is how I would organize that material:

(1) should be in the manual - contribute there if you
think it is insufficient. It is the foundation of
Emacs (a text editor) and by extension all
of computing.

(2) should be in the manual, save for some creative
methods and habits that perhaps aren't there - which
is rather strategies how to organize and carry through
a project - e.g., Makefiles; shortcuts to move between
the project files, fast; how to name and organize the
files and access them (with dired or otherwise); how
to use Gnus so you can get on Usenet/litbots/gmane and
ask/reply-to questions and thus improve your skills
but also solve specific problems (ditto IRC with ERC
but to a lesser degree as it isn't as powerful by
far); also, how to document it all with groff and
integrate that into the man pages of your system; and
so on. All of this should be (and is) documented
separately and with the ambition of being complete,
but yes, it would be cool to attempt to glue it all
together in one neat volume. As in, without
documenting the entirety of those systems, instead
show how parts of them all can be components (tools
and/or methods) in a particular style of programming
which we would think of as "Emacsy"...

(3) is something like

(1)
some of (2)
LaTeX and BibLaTeX
gnuplot (or equivalent(s))

so there wouldn't be a lot to write in terms of Emacs
relating specifically to thesis writing.

(4) I don't have any experience using Emacs like that
so I can't say. Is it common?