Emacs Book Vs Emacs Manuals

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.

Re: Emacs Book Vs Emacs Manuals

[Shakthi Kannan]

Hi,

--- On Fri, May 8, 2015 at 3:36 PM, Vaidheeswaran C
<vaidheeswaran.chinnaraju@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

Re: Emacs Book Vs Emacs Manuals

[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
> <vaidheeswaran.chinnaraju@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.

Re: Emacs Book Vs Emacs Manuals

[Tassilo Horn]

Vaidheeswaran C <vaidheeswaran.chinnaraju@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

Re: Emacs Book Vs Emacs Manuals

[tomas]

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

Re: Emacs Book Vs Emacs Manuals

[Shakthi Kannan]

Hi,

--- On Fri, May 8, 2015 at 4:13 PM, Vaidheeswaran C
<vaidheeswaran.chinnaraju@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/.

SK

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

Re: Emacs Book Vs Emacs Manuals

[notbob]

On 2015-05-08, Shakthi Kannan <shakthimaan@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

Re: Emacs Book Vs Emacs Manuals

[Phillip Lord]

Tassilo Horn <tsdh@gnu.org> writes:

> Vaidheeswaran C <vaidheeswaran.chinnaraju@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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: phillip.lord@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.

Re: Emacs Book Vs Emacs Manuals

[Tassilo Horn]

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>> Vaidheeswaran C <vaidheeswaran.chinnaraju@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

Re: Emacs Book Vs Emacs Manuals

[Barry Margolin]

In article <mailman.2604.1431095644.904.help-gnu-emacs@gnu.org>,
 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: phillip.lord@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.

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, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Barry Margolin <barmar@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?

Re: Emacs Book Vs Emacs Manuals

[Phillip Lord]

Tassilo Horn <tsdh@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

Re: Emacs Book Vs Emacs Manuals

[Tassilo Horn]

phillip.lord@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

RE: Emacs Book Vs Emacs Manuals

[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!

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-05-08, at 12:06, Vaidheeswaran C <vaidheeswaran.chinnaraju@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

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-05-08, at 21:10, Bob Proulx <bob@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

Best,

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

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@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.

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-05-09, at 09:47, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@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.

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

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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@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.

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Stefan Monnier <monnier@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.

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[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)

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@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.

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

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

>> From: Marcin Borkowski <mbork@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.

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,

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Vaidheeswaran C <vaidheeswaran.chinnaraju@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

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Bob Proulx <bob@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.

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

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[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 :-) ]

Re: Emacs Book Vs Emacs Manuals

[Pascal J. Bourguignon]

Rusi <rustompmody@gmail.com> writes:

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

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

Re: Emacs Book Vs Emacs Manuals

[Steinar Bang]

>>>>> phillip.lord@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/

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> Date: Sun, 10 May 2015 12:17:25 +0530
> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@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.

RE: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[Vaidheeswaran C]

On Sunday 10 May 2015 08:31 PM, Eli Zaretskii wrote:
>> Date: Sun, 10 May 2015 12:17:25 +0530
>> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@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.
> 
> 

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.

Re: Emacs Book Vs Emacs Manuals

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Barry Margolin <barmar@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

Re: Emacs Book Vs Emacs Manuals

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Marcin Borkowski <mbork@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

Re: Emacs Book Vs Emacs Manuals

[Phillip Lord]

Rusi <rustompmody@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

Re: Emacs Book Vs Emacs Manuals

[Phillip Lord]

"Pascal J. Bourguignon" <pjb@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

Re: Emacs Book Vs Emacs Manuals

[Pascal J. Bourguignon]

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

> "Pascal J. Bourguignon" <pjb@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.


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.


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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Cc: <help-gnu-emacs@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.

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Cc: <help-gnu-emacs@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.

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@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.

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 11 May 2015 12:12:43 -0400
> 
> > 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.

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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> Date: Mon, 11 May 2015 19:23:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Mon, 11 May 2015 12:12:43 -0400
> > 
> > > 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.
> 
> Which is why I said (and you elided) that I won't mind if such a
> section would be added.

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.

RE: Emacs Book Vs Emacs Manuals

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

RE: Emacs Book Vs Emacs Manuals

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

RE: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
>> Cc: <help-gnu-emacs@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

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Cc: <help-gnu-emacs@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.

Re: Emacs Book Vs Emacs Manuals

[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

RE: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-05-11, at 18:30, Eli Zaretskii <eliz@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

Re: Emacs Book Vs Emacs Manuals

[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]

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[Rasmus]

Rusi <rustompmody@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!

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> Date: Mon, 11 May 2015 21:07:36 -0700 (PDT)
> From: Rusi <rustompmody@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.

Re: Emacs Book Vs Emacs Manuals

[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?

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> Date: Tue, 12 May 2015 09:55:47 -0700 (PDT)
> From: Rusi <rustompmody@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.

Re: Emacs Book Vs Emacs Manuals

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

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

RE: Emacs Book Vs Emacs Manuals

[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)

Re: Emacs Book Vs Emacs Manuals

[tomas]

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

Re: Emacs Book Vs Emacs Manuals

[Filipp Gunbin]

On 13/05/2015 09:47 +0200, tomas@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

Re: Emacs Book Vs Emacs Manuals

[tomas]

-----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, tomas@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-----

Re: Emacs Book Vs Emacs Manuals

[Filipp Gunbin]

On 13/05/2015 14:32 +0200, tomas@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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> Date: Wed, 13 May 2015 09:47:35 +0200
> Cc: help-gnu-emacs@gnu.org
> From:  <tomas@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.

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> Date: Thu, 14 May 2015 19:56:12 -0700 (PDT)
> From: Rusi <rustompmody@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?

Re: Emacs Book Vs Emacs Manuals

[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
]

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> Date: Fri, 15 May 2015 04:12:28 -0700 (PDT)
> From: Rusi <rustompmody@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.

Re: Emacs Book Vs Emacs Manuals

[Phillip Lord]

Eli Zaretskii <eliz@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

Re: Emacs Book Vs Emacs Manuals

[Rusi]

On Friday, May 15, 2015 at 7:14:52 PM UTC+5:30, Phil Lord wrote:
> Eli Zaretskii  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.

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"

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> Date: Fri, 15 May 2015 07:01:55 -0700 (PDT)
> From: Rusi <rustompmody@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

Re: Emacs Book Vs Emacs Manuals

[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 :-) ]
>

RE: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

MBR <mbr@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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Doug Lewan <dougl@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.

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

Re: Emacs Book Vs Emacs Manuals

[Yuri Khan]

On Sat, May 16, 2015 at 2:18 AM, Emanuel Berg <embe8573@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.

Re: Emacs Book Vs Emacs Manuals

[Vaidheeswaran C]

On Monday 11 May 2015 09:36 PM, Eli Zaretskii wrote:
>> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@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 ...

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@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.

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@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.

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
> Date: Mon, 18 May 2015 08:19:14 +0530
> 
> 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.

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.

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

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

Re: Emacs Book Vs Emacs Manuals

[Eli Zaretskii]

> From: Vaidheeswaran C <vaidheeswaran.chinnaraju@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?

Re: Emacs Book Vs Emacs Manuals

[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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Vaidheeswaran C <vaidheeswaran.chinnaraju@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?

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

Re: Emacs Book Vs Emacs Manuals

[Robert Thorpe]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

There could be a link to the Emacs Tour somewhere near the start of the
tutorial, that would help.

http://www.gnu.org/software/emacs/tour/

BR,
Robert Thorpe

Re: Emacs Book Vs Emacs Manuals

[Ken Goldman]

+1.  The first time I used a keyboard macro, I was sold on emacs.

(I use them so often that start, end, and run are assigned to Fn keys.)

On 5/15/2015 12:15 PM, MBR wrote:
> 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.

Re: Emacs Book Vs Emacs Manuals

[Ken Goldman]

As someone who uses keyboard macros constantly ...

I think they're certainly faster to write than lisp, since there's no 
debug time.

For some specialized task I'll probably never use again, I can probably 
write the macro with less keystrokes than calling up .emacs and typing 
in the elisp.

For the rare times I think I'll need the command again, I assign it to a 
key chord or save it.

On 5/15/2015 4:18 PM, Emanuel Berg wrote:
> Doug Lewan <dougl@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.
>

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Ken Goldman <kgoldman@us.ibm.com> writes:

> As someone who uses keyboard macros constantly ...
>
> I think they're certainly faster to write than lisp,
> since there's no debug time.
>
> For some specialized task I'll probably never use
> again, I can probably write the macro with less
> keystrokes than calling up .emacs and typing in
> the elisp.
>
> For the rare times I think I'll need the command
> again, I assign it to a key chord or save it.

What do you typically produce with your macros? If you
give me a good example where the macro is the life
saver, I can think how I would do the same thing.

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

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-06-26, at 17:03, Emanuel Berg <embe8573@student.uu.se> wrote:

> Ken Goldman <kgoldman@us.ibm.com> writes:
>
>> As someone who uses keyboard macros constantly ...
>>
>> I think they're certainly faster to write than lisp,
>> since there's no debug time.
>>
>> For some specialized task I'll probably never use
>> again, I can probably write the macro with less
>> keystrokes than calling up .emacs and typing in
>> the elisp.
>>
>> For the rare times I think I'll need the command
>> again, I assign it to a key chord or save it.
>
> What do you typically produce with your macros? If you
> give me a good example where the macro is the life
> saver, I can think how I would do the same thing.

What about this: you have a LaTeX table with 4 columns, and you want to
delete the second one.  While you /can/ do it with LaTeX hackery
(essentially making one of the columns invisible), you want to deal with
it at the level of the source file.  You put the point at the beginning
of the first row and do something along these lines:

F3
C-s & RET C-SPC C-s C-s RET C-w C-a C-n
F4

and then press F4 once for each row (or even C-8 F4 if you know you have
8 more rows to go).

I cannot see how Elisp could be faster for this, even if you /think/ in
Elisp /and/ can touch-type.

Best,

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

>> What do you typically produce with your macros?
>> If you give me a good example where the macro is
>> the life saver, I can think how I would do the
>> same thing.
>
> What about this: you have a LaTeX table with 4
> columns, and you want to delete the second one.
> While you /can/ do it with LaTeX hackery
> (essentially making one of the columns invisible),
> you want to deal with it at the level of the source
> file. You put the point at the beginning of the
> first row and do something along these lines:
>
> F3 C-s & RET C-SPC C-s C-s RET C-w C-a C-n F4
>
> and then press F4 once for each row (or even C-8 F4
> if you know you have 8 more rows to go).
>
> I cannot see how Elisp could be faster for this,
> even if you /think/ in Elisp /and/ can touch-type.

Oh, yeah?

\begin{longtable}
  1 & 2 & 3 & 4 \\\\
  a & b & c & d \\\\
  A & B & C & D
\end{longtable}

%% (replace-regexp "^\\(.*&.*&\\).*&\\(.*\\)" "\\1\\2")

\begin{longtable}
  1 & 2 & 4 \\\\
  a & b & d \\\\
  A & B & D
\end{longtable}

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

Re: Emacs Book Vs Emacs Manuals

[Rusi]

On Saturday, June 27, 2015 at 4:14:04 AM UTC+5:30, Emanuel Berg wrote:
> %% (replace-regexp "^\\(.*&.*&\\).*&\\(.*\\)" "\\1\\2")

51 chars (ignoring that things like ^& are shift chords)

F3
C-s & RET C-SPC C-s C-s RET C-w C-a C-n
F4

16 keystrokes counting each chord as 1 1/2 keys

Re: Emacs Book Vs Emacs Manuals

[Bob Proulx]

Rusi wrote:
> Emanuel Berg wrote:
> > %% (replace-regexp "^\\(.*&.*&\\).*&\\(.*\\)" "\\1\\2")
>
> 51 chars (ignoring that things like ^& are shift chords)
> 
> F3
> C-s & RET C-SPC C-s C-s RET C-w C-a C-n
> F4
> 
> 16 keystrokes counting each chord as 1 1/2 keys

I don't think keyboard golf is the best justification for something.
It helps.  But for me keyboard macros are simply more interactive.
They are a way to quickly multiply one keystroke into many.

But the above does make me realize that I often use keyboard macros
when the "shape" of the text is a factor in the editing of it.  Such
as when I need to make edits around something both above and below
it.  I might need to move a chunk of text up or down or otherwise
mutate it in unusual ways while editing.  During the keyboard macro I
can search for something, then search for something different, perhaps
several times to land on the right starting point.  Then I can move up
or down spatially to be where I want to be.  That is much harder to do
with regular expression.  I grew up with regular expressions and use
them all of the time.  But I use different tools at different times.

Here is a contrived example.  Split the buffer into two windows.

C-x 4 C-f /tmp/outfile RET
C-x o

Then set up this quick keyboard macro.

  C-s			;; isearch-forward-regexp
  \			;; self-insert-command
  ^			;; self-insert-command
  C-p			;; previous-line
  C-SPC			;; set-mark-command
  C-b			;; backward-char
  M-w			;; kill-ring-save
  C-n			;; next-line
  C-e			;; move-end-of-line
  C-x o			;; other-window
  C-y			;; yank
  C-x o			;; other-window

Run that on this following, C-x e, e, e, e, e, repeatedly executing
the macro and decode the (not so) secret message.

  the quick brown fox jumps over a lazy dog
                        ^
  the quick brown fox jumps over a lazy dog
                                 ^
  the quick brown fox jumps over a lazy dog
         ^
  the quick brown fox jumps over a lazy dog
             ^
  the quick brown fox jumps over a lazy dog
              ^
  the quick brown fox jumps over a lazy dog
                          ^
  the quick brown fox jumps over a lazy dog
     ^
  the quick brown fox jumps over a lazy dog
             ^
  the quick brown fox jumps over a lazy dog
              ^
  the quick brown fox jumps over a lazy dog
         ^
  the quick brown fox jumps over a lazy dog
          ^

Regular expressions are awesome.  But keyboard macros are awesome too.

Bob

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-06-27, at 07:02, Bob Proulx <bob@proulx.com> wrote:

> Rusi wrote:
>> Emanuel Berg wrote:
>> > %% (replace-regexp "^\\(.*&.*&\\).*&\\(.*\\)" "\\1\\2")
>>
>> 51 chars (ignoring that things like ^& are shift chords)
>> 
>> F3
>> C-s & RET C-SPC C-s C-s RET C-w C-a C-n
>> F4
>> 
>> 16 keystrokes counting each chord as 1 1/2 keys
>
> I don't think keyboard golf is the best justification for something.
> It helps.  But for me keyboard macros are simply more interactive.
> They are a way to quickly multiply one keystroke into many.
>
> But the above does make me realize that I often use keyboard macros
> when the "shape" of the text is a factor in the editing of it.  Such
> as when I need to make edits around something both above and below
> it.  I might need to move a chunk of text up or down or otherwise
> mutate it in unusual ways while editing.  During the keyboard macro I
> can search for something, then search for something different, perhaps
> several times to land on the right starting point.  Then I can move up
> or down spatially to be where I want to be.  That is much harder to do
> with regular expression.  I grew up with regular expressions and use
> them all of the time.  But I use different tools at different times.

Exactly.

Macros are especially nice in that they mimic the way you edit text.
You can do that in Elisp, too, or sometimes regexen, but Elisp requires
a lot of typing and regexen require a lot of thinking; both are energy-
and time-consuming.  OTOH, there are cases when macros won't do
(conditional expressions, loops – they are doable in macros – see Calc
manual – but much less intuitive, at least for me).

> Here is a contrived example.  Split the buffer into two windows.

Nice!


> Regular expressions are awesome.  But keyboard macros are awesome too.

Yes.

> Bob

Best,

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

Re: Emacs Book Vs Emacs Manuals

[Robert Thorpe]

Marcin Borkowski <mbork@mbork.pl> writes:
> Macros are especially nice in that they mimic the way you edit text.

I agree.  I find macros much easier to compose than regular expressions.

BR,
Robert Thorpe

Re: Emacs Book Vs Emacs Manuals

[Rusi]

On Saturday, June 27, 2015 at 5:27:03 PM UTC+5:30, Robert Thorpe wrote:
> Marcin Borkowski  writes:
> > Macros are especially nice in that they mimic the way you edit text.
> 
> I agree.  I find macros much easier to compose than regular expressions.

Yes REs are much harder to get right than we imagine.
Also emacs res are more painful than many others:
Try
$ find /usr/share/emacs/24.4/lisp/ -iname '*.el.gz'|xargs zgrep '\\\\\\\\\\\\\\\\'
should give an idea why.
[You may need to tailor the emacs-lisp path]

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

>> %% (replace-regexp "^\\(.*&.*&\\).*&\\(.*\\)"
>> "\\1\\2")
>
> 51 chars (ignoring that things like ^& are shift
> chords)
>
> F3 C-s & RET C-SPC C-s C-s RET C-w C-a C-n F4
>
> 16 keystrokes counting each chord as 1 1/2 keys

Elisp is by definition better because everything you
can do with keyboard macros, you can do with Elisp -
but not even remotely so the other way around.

When you have done something with Elisp, you can save
that for future use. What it is is clearly defined and
easy to read and edit. Not only that, if it is
modular, as it should, you can use it for other,
unexpected things in the future.

In the past, people wrote extremely long programs that
were macro-ish with a lot of repetition and patterns
in the code, and if you did that all day I suppose
a macro to do the same thing over and over would come
in handy.

I don't know why people wrote code like that then,
probably it was their programming languages that
weren't as powerful as Lisp. With all with have with
Lisp there isn't any reason to do that. Instead of
having page up, page down with

    SOME_VARIABLE_1 = 1
    SOME_VARIABLE_2 = 2
    ...
    SOME_FUNCTION_1 = f1
    SOME_FUNCTION_2 = f2

and then use macros to keep track of it all should you
want to change it you put all that in data structures
and have a function do the mapping. Whenever you want
to change something, you'd change the function, not
use macros to change the code.

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> Macros are especially nice in that they mimic the
> way you edit text.

Almost: keyboard macros mimic how *some* people edit
text, for example when they program in FORTRAN...

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

Re: Emacs Book Vs Emacs Manuals

[Rusi]

On Saturday, June 27, 2015 at 11:14:38 PM UTC+5:30, Emanuel Berg wrote:
> Rusi  writes:
> 
> >> %% (replace-regexp "^\\(.*&.*&\\).*&\\(.*\\)"
> >> "\\1\\2")
> >
> > 51 chars (ignoring that things like ^& are shift
> > chords)
> >
> > F3 C-s & RET C-SPC C-s C-s RET C-w C-a C-n F4
> >
> > 16 keystrokes counting each chord as 1 1/2 keys
> 
> Elisp is by definition better because everything you
> can do with keyboard macros, you can do with Elisp -
> but not even remotely so the other way around.

Except that sometimes more is less
http://www.w3.org/2001/tag/doc/leastPower.html

> 
> When you have done something with Elisp, you can save
> that for future use. 


So also macros
(info "(emacs)save keyboard macro")

> What it is is clearly defined and easy to read and edit.

Readability is like beauty -- in the eye of the beholder.
[As my earlier example showed, emacs regexps can be ghastly]

> Not only that, if it is modular, as it should, you can use it for other,
> unexpected things in the future.

Sure...
(E)lisp is neat; doesn't mean its always relevant or appropriate

Re: Emacs Book Vs Emacs Manuals

[MBR]

There are often multiple ways of accomplishing the same thing. Sometimes 
one approach is faster or easier to compose than others. Sometimes one 
approach is more errorprone.  For this particular data, a macro vs. a 
regular expression is about the same effort.

But what if the table had 200 lines so you might not have noticed that 
somewhere off the bottom of the screen was a line with 5 columns instead 
of 4?  For any such line, the first ".*" in your regular expression 
would do a greedy match which would include the first "&".

Another approach when dealing with things that line up visually in 
columns, is Emacs' rectangle commands.  Using the same LaTeX table:

\begin{longtable}
   1 & 2 & 3 & 4 \\\\
   a & b & c & d \\\\
   A & B & C & D
\end{longtable}

Position mark on the "3" in line 2 and point on the "D" in line 4.
Now type:

    C-x r k

Done!

    Mark (not Point) Rosenthal


On 6/26/15 6:42 PM, Emanuel Berg wrote:
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>>> What do you typically produce with your macros?
>>> If you give me a good example where the macro is
>>> the life saver, I can think how I would do the
>>> same thing.
>> What about this: you have a LaTeX table with 4
>> columns, and you want to delete the second one.
>> While you /can/ do it with LaTeX hackery
>> (essentially making one of the columns invisible),
>> you want to deal with it at the level of the source
>> file. You put the point at the beginning of the
>> first row and do something along these lines:
>>
>> F3 C-s & RET C-SPC C-s C-s RET C-w C-a C-n F4
>>
>> and then press F4 once for each row (or even C-8 F4
>> if you know you have 8 more rows to go).
>>
>> I cannot see how Elisp could be faster for this,
>> even if you /think/ in Elisp /and/ can touch-type.
> Oh, yeah?
>
> \begin{longtable}
>    1 & 2 & 3 & 4 \\\\
>    a & b & c & d \\\\
>    A & B & C & D
> \end{longtable}
>
> %% (replace-regexp "^\\(.*&.*&\\).*&\\(.*\\)" "\\1\\2")
>
> \begin{longtable}
>    1 & 2 & 4 \\\\
>    a & b & d \\\\
>    A & B & D
> \end{longtable}
>

Re: Emacs Book Vs Emacs Manuals

[Stefan Monnier]

>> When you have done something with Elisp, you can save
>> that for future use.
> So also macros (info "(emacs)save keyboard macro")

FWIW, I'd love to see a new keyboard-macro facility which doesn't record
keys but commands.  It should be able to display those commands, with
their args in a separate buffer and let you edit them.


        Stefan

Re: Emacs Book Vs Emacs Manuals

[Pascal J. Bourguignon]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> When you have done something with Elisp, you can save
>>> that for future use.
>> So also macros (info "(emacs)save keyboard macro")
>
> FWIW, I'd love to see a new keyboard-macro facility which doesn't record
> keys but commands.  It should be able to display those commands, with
> their args in a separate buffer and let you edit them.

Try
https://gitlab.com/com-informatimago/emacs/blob/master/pjb-echo-keys.el

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, I'd love to see a new keyboard-macro facility
> which doesn't record keys but commands. It should be
> able to display those commands, with their args in
> a separate buffer and let you edit them.

All-interactive Elisp which you don't type but hammer
by hitting keys that are bound to commands. I like
it :)

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> Readability is like beauty -- in the eye of the
> beholder. [As my earlier example showed, emacs
> regexps can be ghastly]

I actually think both keyboard macros and regexps as
a method of editing code are bad (both almost as bad,
but regexps are still a bit better because they can be
read, and the skills you get are usable elsewhere).

But both are bad in the sense they solve problems by
rearranging code according to patterns which almost
turn the code into something graphical! Or to be
precise, the methods are not bad but good but my code
never looks like that. If there are patterns to the
code those should be expressed by other means - not as
ASCII art!

So I ask again, next time you use this with real
technology like Lisp, C, C++, zsh, SQL, even groff,
LaTeX, just about anything that I know that would be
interesting to see.

I have only seen one example so far and there
I disagree: I think the Elisp one-liner is the best
solution by far.

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

MBR <mbr@arlsoft.com> writes:

> But what if the table had 200 lines so you might not
> have noticed that somewhere off the bottom of the
> screen was a line with 5 columns instead of 4?
> For any such line, the first ".*" in your regular
> expression would do a greedy match which would
> include the first "&".

Now you are changing the rules after the solution is
offered. Besides this is exactly the kind of code
I ridicule ("200 lines"). For LaTeX I make a small
exception but in general I don't think computer code
should look like that.

> Another approach when dealing with things that line
> up visually in columns, is Emacs' rectangle
> commands. Using the same LaTeX table:
>
> \begin{longtable}
>    1 & 2 & 3 & 4 \\\\
>    a & b & c & d \\\\
>    A & B & C & D
> \end{longtable}
>
> Position mark on the "3" in line 2 and point on the
> "D" in line 4. Now type:
>
>     C-x r k

:)

Yeah, that's good. That's the best so far.

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

Re: Emacs Book Vs Emacs Manuals

[Rusi]

On Sunday, June 28, 2015 at 4:19:41 AM UTC+5:30, Emanuel Berg wrote:
> MBR  writes:
>
> > Another approach when dealing with things that line
> > up visually in columns, is Emacs' rectangle
> > commands. Using the same LaTeX table:
> >
> > \begin{longtable}
> >    1 & 2 & 3 & 4 \\\\
> >    a & b & c & d \\\\
> >    A & B & C & D
> > \end{longtable}
> >
> > Position mark on the "3" in line 2 and point on the
> > "D" in line 4. Now type:
> >
> >     C-x r k
> 
> :)
> 
> Yeah, that's good. That's the best so far.

IMHO Bob Proulx's 'interactivity' + 'shape' is key.

Shape: REs are strong
Interactivity : Vanilla emacs rules
Combo : Macros are good

Earlier I only glanced that this example; did not try it.
Now that I see it is a clear case of rect commands, column editing mode beats
the pants off classic rect commands -- because of interactivity
https://vimeo.com/1168225

[Hope that's the right video -- my flashplayer not working right now]

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-06-28, at 05:45, Rusi <rustompmody@gmail.com> wrote:

> Earlier I only glanced that this example; did not try it.
> Now that I see it is a clear case of rect commands, column editing mode beats
> the pants off classic rect commands -- because of interactivity
> https://vimeo.com/1168225

Didn't see the video (yet), but be reminded that LaTeX tables need not
be so neatly arranged in the source code.

So: another win for keyboard macros.

Best,

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

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-06-28, at 00:40, Emanuel Berg <embe8573@student.uu.se> wrote:

> Rusi <rustompmody@gmail.com> writes:
>
> I actually think both keyboard macros and regexps as
> a method of editing code are bad (both almost as bad,
> but regexps are still a bit better because they can be
> read, and the skills you get are usable elsewhere).

Emanuel, are you aware of C-x C-k RET?

> But both are bad in the sense they solve problems by
> rearranging code according to patterns which almost
> turn the code into something graphical! Or to be
> precise, the methods are not bad but good but my code
> never looks like that. If there are patterns to the
> code those should be expressed by other means - not as
> ASCII art!

If you edit text, which is somehow “graphical”, why shouldn’t the code
reflect the problem?  Not that it has to, but IMHO there’s nothing wrong
if it does.

Note that my Emacs usage is somewhat atypical: while I do edit code
often, I edit texts in natural languages (usually marked up in LaTeX or
Org-mode) even more often.

> So I ask again, next time you use this with real
> technology like Lisp, C, C++, zsh, SQL, even groff,
> LaTeX, just about anything that I know that would be
> interesting to see.

Admittedly, I don’t think I’ve ever used macros when editing Elisp, for
instance.  OTOH, I have Oleh Krehel’s Lispy for that (have you seen
that?  Some commands, e.g., the xc/xi pair, look almost like magic.).

> I have only seen one example so far and there
> I disagree: I think the Elisp one-liner is the best
> solution by far.

I disagree (not surprising), and when I next use a kbd macro, I'll try
to remember to show it here.

(One other case I like keyboard macros is rearranging things, e.g.,
paragraphs, in a buffer; I open two windows with the same buffer, but
with the point in different places, and record a macro which kills
something in one window and yanks in the other one.  Very handy.)

Best,

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> but be reminded that LaTeX tables need not be so
> neatly arranged in the source code.
>
> So: another win for keyboard macros.

?! - on the contrary: keyboard macros relies on the
code being arranged.

Now, regexps and Elisp (for this purpose) would also
rely on that but would still come up on top because of
more expressive power.

However, I don't consider this a big loss for keyboard
macros - rather it is a loss for the programmer who
wrote such code to begin with.

And again, I don't consider using regexps or Elisp
everyday stuff for editing code. For that purpose
I have a 61 keys and nine fingers.

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

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-06-28, at 17:31, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> but be reminded that LaTeX tables need not be so
>> neatly arranged in the source code.
>>
>> So: another win for keyboard macros.
>
> ?! - on the contrary: keyboard macros relies on the
> code being arranged.

No, rectangle editing relies on that.

Best,

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> (One other case I like keyboard macros is
> rearranging things, e.g., paragraphs, in a buffer;
> I open two windows with the same buffer, but with
> the point in different places, and record a macro
> which kills something in one window and yanks in the
> other one. Very handy.)

(defun kill-and-yank-other-window (beg end)
  (interactive "r")
  (kill-region beg end)
  (save-window-excursion
    (other-window 1)
    (yank) ))

> If you edit text, which is somehow “graphical”, why
> shouldn’t the code reflect the problem? Not that it
> has to, but IMHO there’s nothing wrong if it does.

It is good that the code is "graphical" (perhaps
"visual" is a better word) in terms of simple but
life-important features like font lock (syntax
highlighting) and indentation, as well as the
programmer's expert touch and personality to arrange
code his way. This makes it easier to *see* the code,
rather than having to *read* it all the time.
For example, when I look at Lisp, I don't read the
code, I only see blondes and brunettes and...

No, those are nice little things (I mean, the font
locks etc.) to make it pleasant and productive, and
because of that, they are very important despite
their littleness.

However, it is not good if structure and purpose is
expressed and controlled like that in a deeper sense.
The code - the functions and keywords - should
do that.

When you want to change something, you shouldn't
"rearrange" the code into some new pattern in the
fourth dimension of Nirvana, you should change
typically but a few function invocations or
variable settings.

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

>>> but be reminded that LaTeX tables need not be so
>>> neatly arranged in the source code. So: another
>>> win for keyboard macros.
>>
>> ?! - on the contrary: keyboard macros relies on the
>> code being arranged.
>
> No, rectangle editing relies on that.

All of this relies on that: keyboard macros and
regexps as well. If there is no pattern,
parsing/applying another pattern won't work.

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

Re: Emacs Book Vs Emacs Manuals

[Filipp Gunbin]

On 27/06/2015 19:42 +0200, Emanuel Berg wrote:

> Rusi <rustompmody@gmail.com> writes:
>
>>> %% (replace-regexp "^\\(.*&.*&\\).*&\\(.*\\)"
>>> "\\1\\2")
>>
>> 51 chars (ignoring that things like ^& are shift
>> chords)
>>
>> F3 C-s & RET C-SPC C-s C-s RET C-w C-a C-n F4
>>
>> 16 keystrokes counting each chord as 1 1/2 keys
>
> Elisp is by definition better because everything you
> can do with keyboard macros, you can do with Elisp -
> but not even remotely so the other way around.

Macros can be viewed as an Emacs-specific way of writing programs - by
using the benefits of an interactive editor.  Resulting code is not that
editable, but in my practice I didn't usually have to edit that code,
when it's easier just to re-record a similar macros, if needed.

> When you have done something with Elisp, you can save
> that for future use. What it is is clearly defined and
> easy to read and edit. Not only that, if it is
> modular, as it should, you can use it for other,
> unexpected things in the future.

Why then use awk when you always can write equivalent program in C?

Filipp

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> Macros can be viewed as an Emacs-specific way of
> writing programs - by using the benefits of an
> interactive editor.

Macros are even in the *name* of Emacs so they would
seem essential. That christening was a long time ago,
of course.

There are macros in many other tools. Perhaps they are
not editable. Probably the whole thing is not as
refined as in Emacs.

> Resulting code is not that editable, but in my
> practice I didn't usually have to edit that code,
> when it's easier just to re-record a similar macros,
> if needed.

So you don't write code - you write macros to write
the code for you. Now we have ventured far beyond my
horizon. It would be interesting to see you in action.

>> When you have done something with Elisp, you can
>> save that for future use. What it is is clearly
>> defined and easy to read and edit. Not only that,
>> if it is modular, as it should, you can use it for
>> other, unexpected things in the future.
>
> Why then use awk when you always can write
> equivalent program in C?

Answer: because awk is a shell tool which comes with
features and interfaces to fit that particular
habitate, while C is a general-purpose programming
langauge with which you can create any tool,
including awk.

This is awk:

    get-group () { awk '{print $5}' < /proc/$1/stat }

and this is C:

    $ apt-get source gawk

:)

No, I'm not saying you should always use this instead
of that, and in particular you seem to have a style
which is completely based on macros so to you I'm not
saying anything.

Some boxers are boxers, some are punchers on the
outside, while some are body punchers on the inside;
some are brawlers, or even southpaw counter-punchers
that moves forward! Because there are world champions
representing every and each of those styles, plus many
that I haven't mentioned, plus a fewsome from
categories I don't even know about, this all tells me
there is not any one style that is better than all
other. The important thing is to have a style.
When you have it, keep refining it, every day.

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

Re: Emacs Book Vs Emacs Manuals

[Vaidheeswaran C]

On Tuesday 30 June 2015 05:21 AM, Emanuel Berg wrote:
> There are macros in many other tools. Perhaps they are
> not editable. Probably the whole thing is not as
> refined as in Emacs.

LibreOffice has macros.  You can save and edit them.  In my opinion,
they are quite handy.

Re: Emacs Book Vs Emacs Manuals

[Marcin Borkowski]

On 2015-06-30, at 01:51, Emanuel Berg <embe8573@student.uu.se> wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> Macros can be viewed as an Emacs-specific way of
>> writing programs - by using the benefits of an
>> interactive editor.
>
> Macros are even in the *name* of Emacs so they would
> seem essential. That christening was a long time ago,
> of course.

Those were other macros, AFAIK.

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

keyboard-macro facility recording commands (Was: Emacs Book Vs Emacs Manuals)

[Steinar Bang]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca>:

>>> When you have done something with Elisp, you can save
>>> that for future use.

>> So also macros (info "(emacs)save keyboard macro")

> FWIW, I'd love to see a new keyboard-macro facility which doesn't record
> keys but commands.  It should be able to display those commands, with
> their args in a separate buffer and let you edit them.

I would also really like to see this feature.

Re: Emacs Book Vs Emacs Manuals

[Filipp Gunbin]

On 30/06/2015 01:51 +0200, Emanuel Berg wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> Macros can be viewed as an Emacs-specific way of
>> writing programs - by using the benefits of an
>> interactive editor.
>
> Macros are even in the *name* of Emacs so they would
> seem essential. That christening was a long time ago,
> of course.
>
> There are macros in many other tools. Perhaps they are
> not editable. Probably the whole thing is not as
> refined as in Emacs.
>
>> Resulting code is not that editable, but in my
>> practice I didn't usually have to edit that code,
>> when it's easier just to re-record a similar macros,
>> if needed.
>
> So you don't write code - you write macros to write
> the code for you. Now we have ventured far beyond my
> horizon. It would be interesting to see you in action.

No no, you misunderstood or I wasn't clear enough.  It's simpler.  A
macro is a program, too, and it's editable as you know, but written in a
different language.

When I record a macro I get some code in the end, yet it's not elisp.

That's what I meant by saying that macros help write code _using
interactive editor facilities_ - that is, not directly typing language
syntactic constructs.  It's quicker and simpler to record a macro, but
the cost of it is the lack of general usefulness.

This is obvious, and I'm writing it because you time after time refuse
to admit that sometimes macros are better than elisp.  I suppose you
have reasons to say that, that's why this discussion can be interesting
to me.

>>> When you have done something with Elisp, you can
>>> save that for future use. What it is is clearly
>>> defined and easy to read and edit. Not only that,
>>> if it is modular, as it should, you can use it for
>>> other, unexpected things in the future.
>>
>> Why then use awk when you always can write
>> equivalent program in C?
>
> Answer: because awk is
...

Yes, thanks, that was a rhetorical question :-)

Meant to underline that programs written in a language not general
enough to handle all and everything also can be useful sometimes, and
awk is a good example, I think.

Filipp

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
writes:

> LibreOffice has macros. You can save and edit them.
> In my opinion, they are quite handy.

LibreOffice, a word processor.

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

>> Macros are even in the *name* of Emacs so they
>> would seem essential. That christening was a long
>> time ago, of course.
>
> Those were other macros, AFAIK.

A keyboard macro is a sequence of interactive input
actions, and the corresponding commands are executed
just as if the user were hitting that
selfsame sequence.

Yeah, it is called a "keyboard" macro to distinguish
them from programming macros, which are programs that
produce a program which is then executed. But despite
the name, if you are unfortunate enough to use
a mouse, as an interactive input device, I'm sure such
actions can be included in keyboard macros as well.

Anyway, I suspect the development was like this.
People were using TECO, and they found they were
repeating the same keyboard patterns to do the same
things over and over. So they started to record those
into macros. After a while, they became to the user
indistinguishable from functions. When enough such
macros/functions had been assembled and collected,
they put it together into Emacs. Perhaps they then
realized some function was missing, so they wrote the
odd man TECO macro to fill the gap.

Feel free to correct this story, which is based solely
on shamanism.

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

Re: Emacs Book Vs Emacs Manuals

[Emanuel Berg]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> A macro is a program, too, and it's editable as you
> know, but written in a different language.
> When I record a macro I get some code in the end,
> yet it's not elisp.

A macro is a program but is it in another language?
If the inputs are commands, and the commands are
Elisp, isn't the language actually a subset of Elisp?

And this is what I've said since day one, macros is
poor man's programming.

Or do you mean how that language is perceived
and/or displayed?

> That's what I meant by saying that macros help write
> code _using interactive editor facilities_ - that
> is, not directly typing language syntactic
> constructs. It's quicker and simpler to record
> a macro, but the cost of it is the lack of
> general usefulness.

It may be quicker if you do not make any mistakes and
if you can envision what to do from start to finish.
In Elisp you don't have to worry about the interactive
distinction and instead you are able to use the full
power of the tool Emacs. But yes, I'm sure some people
who did lots of it compared to the amount of Elisp
they did, it makes sense it is quicker for them.

> This is obvious, and I'm writing it because you time
> after time refuse to admit that sometimes macros are
> better than elisp. I suppose you have reasons to say
> that, that's why this discussion can be interesting
> to me.

The reason I have for saying that is that it is
logical: you can do everything with Elisp that you can
do with macros, but not remotely so the other
way around.

I also say that because I haven't seen any good
examples where a macro saves the day.

I also say that because of a more bigger view.
Nother else works like that. Say that ten guys are
digging a hole with shovels. That sounds pretty fun,
ey? Unfortunately, some guy thought that to be
inefficient so he constructed the excavator. Now, that
machinery does the job as well as the ten guys but it
doesn't look or work like the ten guys at all. This is
the Elisp approach. The macro approach would be to
construct ten robots that look exactly like the guys
and have them to the exact same thing to produce the
exact same result.

If A solves problem B, and I want to solve B in
another way, I don't think "how can I replicate A?",
instead I examine B to think how I can solve it in
terms of the problem itself. If I can't find
a solution, I might examine A to learn how to do it,
but not in order to exactly replicate it!

> Yes, thanks, that was a rhetorical question :-)

*nod* (note then smiley)

> Meant to underline that programs written in
> a language not general enough to handle all and
> everything also can be useful sometimes, and awk is
> a good example, I think.

Yeah, but are macros more specific than Elisp just
because they are less general?

No, I think this is rather something on the human side
of the equation. I want to type the actual commands
and see them appear in front of me. You, perhaps do
not care about that and have it all in your fingertips
and muscle memory. And that is interesting because I'm
all into fingertips and muscle memory (finger habits)
as well...

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

Re: Emacs Book Vs Emacs Manuals

[Dan Espen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com>
> writes:
>
>> LibreOffice has macros. You can save and edit them.
>> In my opinion, they are quite handy.
>
> LibreOffice, a word processor.

Web pages have macros too.
Even Emacs has macros.

You just can't get away from them.

-- 
Dan Espen