on ``An Introduction to Programming in Emacs Lisp''

on ``An Introduction to Programming in Emacs Lisp''

[Daniel Bastos]

This is a report on minor typos and imperfections regarding

  An Introduction to Programming in Emacs Lisp
  By Robert J. Chassell, published by GNU Press
  Edition 3.10, 28 October 2009 ISBN 1-882114-43-4

I read it last December.  I had so much fun.  I'd like to take this
opportunity to thank the entire GNU project, not just because it
offers the highest quality, but also because of its social importance
and mainly because of its social importance.  (Incidentally, I regard
documentation as highly as the tools they document.  I think
documentation is the soul of science.  You can read documentation
written B.C. in the 21st century --- for instance, Plato.  Some
particular thanks goes to Robert Chassell for writing such a great
book on the excellent software the GNU EMACS is.)

The sections below name the node and the line in which the quoted
passage that deserves attention begins.  Before the quote, I make my
comment so that when you finally see the passage you already know
what to look for.

Some passages were very enjoyable.  Perhaps I can share some of my
enjoyment together with this report.  For those who don't mix fun with
work, you can begin after the line 

  Lots of great things took place in the 80s! 

Feel free to point me towards fixing these myself and providing a
patch.  I wouldn't mind doing it.  But I probably would need someone
to discuss the changes with.

(*) Great passages

(eintr) Simple Extension, 49

--8<---------------cut here---------------start------------->8---
   For example, recent versions blink their cursors by default.  I hate
such blinking, as well as other features, so I [...].
--8<---------------cut here---------------end--------------->8---

A man after my own heart!

(eintr) Columns of a graph, 155

--8<---------------cut here---------------start------------->8---
   (Incidentally, I don't know how you would learn of this function
without a book such as this.  It is possible to discover other
functions, like `search-forward' or `insert-rectangle', by guessing at
a part of their names and then using `apropos'.  Even though its base
in metaphor is clear--`apply' its first argument to the rest--I doubt a
novice would come up with that particular word when using `apropos' or
other aid.  Of course, I could be wrong; after all, the function was
first named by someone who had to invent it.)
--8<---------------cut here---------------end--------------->8---

(eintr) defcustom

--8<---------------cut here---------------start------------->8---
   The `custom-set-variables' function works somewhat differently than
a `setq'.  While I have never learned the differences, I modify the
`custom-set-variables' expressions in my `.emacs' file by hand:  I make
the changes in what appears to me to be a reasonable manner and have
not had any problems.  Others prefer to use the Customization command
and let Emacs do the work for them.
--8<---------------cut here---------------end--------------->8---

It's great to known what an expert thinks, even on personal matters.

(eintr) Beginning a .emacs File

--8<---------------cut here---------------start------------->8---
     ;;;; Bob's .emacs file
     ; Robert J. Chassell
     ; 26 September 1985

Look at that date!  I started this file a long time ago.  I have been
adding to it ever since.
--8<---------------cut here---------------end--------------->8---

Lots of great things took place in the 80s! 

(eintr) Emacs Initialization

--8<---------------cut here---------------start------------->8---
"You don't have to like Emacs to like it"--this seemingly paradoxical
statement is the secret of GNU Emacs.  The plain, `out of the box'
Emacs is a generic tool.  Most people who use it, customize it to suit
themselves.
--8<---------------cut here---------------end--------------->8---

Great passage!  But it turns out the last sentence seems to separate
subject from predicate with a comma, violating the English grammar.
(This passage therefore belongs to this section and the next.)

(*) Imperfections

(eintr) kill-new function, 51

I think that the line 

--8<---------------cut here---------------start------------->8---
  (setq kill-ring (cons string kill-ring)) 
--8<---------------cut here---------------end--------------->8---

appears by accident in the code of kill-new as displayed in the book.
It should not be there.  It's not in the source code of the function
and it doesn't make sense where it is displayed.  It seems a
yank-accident.

--8<---------------cut here---------------start------------->8---
   The critical lines are these:

       (if (and replace kill-ring)
           ;; then
           (setcar kill-ring string)
         ;; else
       (push string kill-ring)
         (setq kill-ring (cons string kill-ring))
         (if (> (length kill-ring) kill-ring-max)
             ;; avoid overly long kill ring
             (setcdr (nthcdr (1- kill-ring-max) kill-ring) nil)))
       (setq kill-ring-yank-pointer kill-ring)
       (if interprogram-cut-function
           (funcall interprogram-cut-function string (not replace))))
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Digression into C, 60

I think ``the Lisp'' was not intended.

--8<---------------cut here---------------start------------->8---
   * The sixth part is nearly like the argument that follows the
     `interactive' declaration in a function written in Lisp: a letter
     followed, perhaps, by a prompt.  The only difference from the Lisp
     is when the macro is called with no arguments.  Then you write a
     `0' (which is a `null string'), as in this macro.
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Digression into C, 87

Perhaps ``del_range'' was not intended.  Perhaps ``del_range_1'' was
the intended function because it is the one it seems to be referred
to.

--8<---------------cut here---------------start------------->8---
   The `del_range_1' function actually deletes the text.  It is a
complex function we will not look into.  It updates the buffer and does
other things.  However, it is worth looking at the two arguments passed
to `del_range'.  These are `XINT (start)' and `XINT (end)'.
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Symbols as Chest, 10

Typo.  From ``vice-verse'' to ``vice-versa''.

(*) (eintr) Every, 20

Typo? ``Here's an example'' was meant?

--8<---------------cut here---------------start------------->8---
   Here is example:
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Complete forward-sentence, 73

Likely a typo.  I think the author meant ``opoint'', not ``point''.
The let in question appears on line 43.  It binds the (point) value to
the symbol ``opoint''.

--8<---------------cut here---------------start------------->8---
   Next is a `let'.  That specifies the values of two local variables,
`point' and `sentence-end'.  The local value of point, from before the
search, is used in the `constrain-to-field' function which handles
forms and equivalents.  The `sentence-end' variable is set by the
`sentence-end' function.
--8<---------------cut here---------------end--------------->8---

(*) (eintr) fwd-para while, 130

Typo.  Replace ``a the'' with ``the''.

--8<---------------cut here---------------start------------->8---
This `while' loop has us searching forward for `sp-parstart', which is
the combination of possible whitespace with a the local value of the
start of a paragraph or of a paragraph separator.  (The latter two are
within an expression starting `\(?:' so that they are not referenced by
the `match-beginning' function.)
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Divide and Conquer, l14

Typo? I'd think the proper English here would be ``the /number/ of
words in each function in a file''.  Or would it not?

--8<---------------cut here---------------start------------->8---
   * Second, write a function to list the numbers of words in each
     function in a file.  This function can use the
     `count-words-in-defun' function.

   * Third, write a function to list the numbers of words in each
     function in each of several files.  This entails automatically
     finding the various files, switching to them, and counting the
     words in the definitions within them.
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Find a File, 18

In this paragraph, the passage "optional wildcards argument" should be
"optional WILDCARDS argument" to conform to the convention that
arguments should be written in uppercase.

--8<---------------cut here---------------start------------->8---
   According to its documentation as shown by `C-h f' (the
`describe-function' command), the `find-file-noselect' function reads
the named file into a buffer and returns the buffer.  (Its most recent
version includes an optional wildcards argument, too, as well as
another to read a file literally and an other you suppress warning
messages.  These optional arguments are irrelevant.)
--8<---------------cut here---------------end--------------->8---

(*) (eintr) lengths-list-many-files, 6

Missing preposition? I think the author meant "[t]he argument passed
/to/ the function is a list of files."

--8<---------------cut here---------------start------------->8---
   The design using a `while' loop is routine.  The argument passed the
function is a list of files.  As we saw earlier (*note Loop Example::),
you can write a `while' loop so that the body of the loop is evaluated
if such a list contains elements, but to exit the loop if the list is
empty.  For this design to work, the body of the loop must contain an
expression that shortens the list each time the body is evaluated, so
that eventually the list is empty.  The usual technique is to set the
value of the list to the value of the CDR of the list each time the
body is evaluated.
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Columns of a graph, 35

Typo.  I think the author meant to write ``once took'' but wrote
``once too takes''.

--8<---------------cut here---------------start------------->8---
   What we want to look for is some command that prints or inserts
columns.  Very likely, the name of the function will contain either the
word `print' or the word `insert' or the word `column'.  Therefore, we
can simply type `M-x apropos RET print\|insert\|column RET' and look at
the result.  On my system, this command once too takes quite some time,
and then produced a list of 79 functions and variables.  Now it does
not take much time at all and produces a list of 211 functions and
variables.  Scanning down the list, the only function that looks as if
it might do the job is `insert-rectangle'.
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Columns of a graph, 102

I'm not sure here.  I'd have written "we will have /to/ position point
/to/ the right number of lines".

--8<---------------cut here---------------start------------->8---
                     If this list consists solely of the requisite
number of asterisks, then we will have position point the right number
of lines above the base for the graph to print correctly.  This could
be difficult.
--8<---------------cut here---------------end--------------->8---

(*) (eintr) Columns of a graph, 223

Typo.  The author meant ``you may want'' instead of ``you many want''.

--8<---------------cut here---------------start------------->8---
   As written, `column-of-graph' contains a major flaw: the symbols
used for the blank and for the marked entries in the column are
`hard-coded' as a space and asterisk.  This is fine for a prototype,
but you, or another user, may wish to use other symbols.  For example,
in testing the graph function, you many want to use a period in place
of the space, to make sure the point is being repositioned properly
each time the `insert-rectangle' function is called; or you might want
to substitute a `+' sign or other symbol for the asterisk.  You might
even want to make a graph-column that is more than one display column
wide.  The program should be more flexible.  The way to do that is to
replace the blank and the asterisk with two variables that we can call
`graph-blank' and `graph-symbol' and define those variables separately.
--8<---------------cut here---------------end--------------->8---

(*) (eintr) recursive-graph-body-print, 14

I believe the symbol ``from-position'' was not intended to be in this
function.  It might have been included by accident, since it is used
in another function, related to this one.  We have perhaps a variable
accidentally left over.

--8<---------------cut here---------------start------------->8---
     (defun recursive-graph-body-print (numbers-list)
       "Print a bar graph of the NUMBERS-LIST.
     The numbers-list consists of the Y-axis values."
       (let ((height (apply 'max numbers-list))
             (symbol-width (length graph-blank))
             from-position)
         (recursive-graph-body-print-internal
          numbers-list
          height
          symbol-width)))
--8<---------------cut here---------------end--------------->8---

(*) (eintr) defcustom

If I understood this correctly, the book mentions something I can't
find in GNU EMACS 24.3.1.  Here's the passage.

--8<---------------cut here---------------start------------->8---
     Using the customization command,  you can type:
  
       M-x customize
  
  and find that the group for editing files of data is called `data'.
  Enter that group.  Text Mode Hook is the first member.
--8<---------------cut here---------------end--------------->8---
  
I can't find it.  Here's what happens in my GNU EMACS.  I execute

  M-x customize 

and I see

  Emacs group: Customization of the One True Editor.

(Something with which I can agree!) Lots of groups are listed.

  Editing, Convenience, Files, Text, Data, ... 

I then click on ``Data''.  ``Text Mode Hook'' is not the first member.
In fact, it's not there at all.  I go back by pushing the button on
the ``parent group''.  Instead of ``Data'', I choose now the group
``Text''.  There I find ``Text Mode Hook'' as first member.

Therefore, I think the groups have been reorganized and the book is
now a tiny bit outdated.  Here's the complete definition of my version.

   GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on MARVIN.

(*) (eintr) debug, 57

I have an English question here.  Consider this passage.

--8<---------------cut here---------------start------------->8---
     However, suppose you are not quite certain what is going on?  You
  can read the complete backtrace.
--8<---------------cut here---------------end--------------->8---

Is it proper to question-mark that sentence? Is it what is called a
rhetoric question? Perhaps the author really meant to put a period
there.

(*) (eintr) recursive-count-words, 116

Another English question.

--8<---------------cut here---------------start------------->8---
   But already, we have an outline of the recursive counting function:
--8<---------------cut here---------------end--------------->8---

Is this comma okay there? I wouldn't have put it there.  I'd have
written

  But already we have an outline of the recursive counting function:

(*) (eintr) Columns of a graph, 276

A question, opinion.  It's not clear to me what the word ``value''
refers to in this paragraph.  The word ``value'' suddenly appears on
line 281.  Which value are we talking about? I can only suppose it's
the height of the graph at that point.  Perhaps that could be made
clearer.

--8<---------------cut here---------------start------------->8---
   If we wished, we could rewrite `column-of-graph' a third time to
provide optionally for a line graph as well as for a bar graph.  This
would not be hard to do.  One way to think of a line graph is that it
is no more than a bar graph in which the part of each bar that is below
the top is blank.  To construct a column for a line graph, the function
first constructs a list of blanks that is one shorter than the value,
then it uses `cons' to attach a graph symbol to the list; then it uses
`cons' again to attach the `top blanks' to the list.
--8<---------------cut here---------------end--------------->8---

(*) Text filling and visible-mode

A technical matter.  This is related to how paragraphs of the book are
displayed in the GNU EMACS.  The text isn't properly filled when there
are cross-references and visible-mode is disabled.  The filling is
made as if visible-mode were enabled.  Enabling it, it displays just fine.

A non-exhaustive list of various nodes where this can be seen:

  (eintr) forward-paragraph in brief, 26
  (eintr) fwd-para let, 39
  (eintr) Whitespace Bug, 165
  (eintr) recursive-count-words, 138
  (eintr) Sorting, 11
  (eintr) Counting function definitions, 51
  (eintr) Beginning a .emacs File, 13
  (eintr) Loading Files, l66
  (eintr) Autoload, l25
  (eintr) Conclusion, 89
  (eintr) the-the, 16
  (eintr) Words in a defun, l6

(*) (eintr) count-words-in-defun, 143

Another technical matter.  In this node, I could not run
count-words-defun successfully.  I'll say what I do, what happens and
what I expected to happen.

The defun that will be counted begins on line 143.  Following the
instructions that begin on line 139, I install count-words-in-defun,
count-words-defun, I set the keybinding and I position my cursor on
the ``7'' that appears inside the definition of multiply-by-seven.
IOW, my point is inside the defun.  I press ``C-c ='', which executes
count-words-defun.  My point is moved all the way up to the beginning
of the *info* buffer and the message displayed is

  The definition has 1 word or symbol.

I expected the message to display the correct number of words in the
defun (10 words or symbols) and point be moved to the end of the
defun.

I've narrowed the problem to beginning-of-defun.  In *info*, the defun
is indented by 5 spaces from the beginning of the line where the defun
begins.  As it turns out, beginning-of-defun is programmed not to find
such defun.  I believe this is the relevant regexp.

  (re-search-backward "^\\s(" ...

I interpret this as begin a line with ``(''.  If the defun does not
appear at the beginning of a line, this regexp will not match it.
Since my *info* buffer begins with ``(eintr)'', this is what is
matched.  Hence my point moves all the way to the beginning of buffer.

(*) (eintr) recursive-count-words, 160

Opinion.  For recursive functions, I find it more obvious when the
base case comes first.  The design of recursive-count-words puts the
base case as an else clause.

     (if DO-AGAIN-TEST-AND-NEXT-STEP-COMBINED
         ;; then
         RECURSIVE-CALL-RETURNING-COUNT
       ;; else
       RETURN-ZERO)

I would have done written it the following way.

     (if DO-AGAIN-TEST-TURNS-OUT-FALSE
         ;; then
         RETURN-ZERO
       ;; else
       RECURSIVE-CALL-RETURNING-COUNT)

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Daniel Bastos <dbastos@toledo.com> writes:

> This is a report [...] regarding
>
> An Introduction to Programming in Emacs Lisp By
> Robert J. Chassell, published by GNU Press Edition
> 3.10, 28 October 2009 ISBN 1-882114-43-4

What fun!

I never heard of this one. Books on Lisp sure don't
grow on trees (not even firewood does ha ha).

The last book I saw on Lisp was this one:

@book{lispcraft,
  title      = {LISPcraft},
  author     = {Robert Wilensky},
  publisher  = {Norton},
  year       = 1984,
  ISBN       = 0393954420
}

It is about a Lisp dialect called Franz Lisp (a pun on
Franz Liszt, a Hungarian hot-shot pianist) - but it
was mostly same old Lisp stuff what I could see.

Anyway, if I find Chassell's book as a PDF I'll sure
print it and give it look.

The title rings a little off-key - shouldn't it be "An
introduction to *Lisp*, with some of the intricacies
of *Emacs Lisp* on top"? 

But it is a title. Grandmother said, never to judge
a book by its title!

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Robert Thorpe]

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

> Daniel Bastos <dbastos@toledo.com> writes:
>
>> This is a report [...] regarding
>>
>> An Introduction to Programming in Emacs Lisp By
>> Robert J. Chassell, published by GNU Press Edition
>> 3.10, 28 October 2009 ISBN 1-882114-43-4
>
> What fun!
>
> I never heard of this one. Books on Lisp sure don't
> grow on trees (not even firewood does ha ha).

It's included with Emacs as an Info file.  It's called "Emacs Lisp
Intro" the file is eintr.info.

You're probably not seeing it because you run a distro that hides the
Emacs docs in some obscure repository of the package manager.

It's very good, well worth reading.

BR,
Robert Thorpe

Re: on ``An Introduction to Programming in Emacs Lisp''

[Filipp Gunbin]

On 29/01/2016 00:58 +0100, Emanuel Berg wrote:

> Anyway, if I find Chassell's book as a PDF I'll sure
> print it and give it look.

It's meant to be an introduction into Emacs Lisp programming for people
who are new to Emacs Lisp and Lisp in general.

Besides, it gives some insight into how Emacs works and some good
advices on how to use it.

It was a joy to read it.

> The title rings a little off-key - shouldn't it be "An
> introduction to *Lisp*, with some of the intricacies
> of *Emacs Lisp* on top"?

According to its purpose - no, it shouldn't :-)

Filipp

Re: on ``An Introduction to Programming in Emacs Lisp''

[Paul Smith]

On 29/01/2016 00:58 +0100, Emanuel Berg wrote:
> 
> > Anyway, if I find Chassell's book as a PDF I'll sure
> > print it and give it look.

Or, online: https://www.gnu.org/software/emacs/manual/html_node/eintr/index.html

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

>> The title rings a little off-key - shouldn't it be
>> "An introduction to *Lisp*, with some of the
>> intricacies of *Emacs Lisp* on top"?
>
> According to its purpose - no, it shouldn't :-)

Well, there is programming in Lisp. If you happen to
do that in the context of Emacs, the particular
dialect of Lisp is Emacs Lisp.

Even that is stretching it because the "dialectic"
differences are negligible. It is rather the
applications that are particular to the context - and
I suppose the Emacs buffer is the best example
of that.

But also everything that comes with Emacs - the
software. Take a look at this piece of code:

    (require 'cl-macs)
    (require 'gnus-msg)
    (require 'message)

    (defun mail-to-many (to subject body)
      (cl-dolist (this-to to)
        (gnus-post-news 'post "")
        (message-goto-to)          (insert this-to)
        (message-goto-subject)     (insert subject)
        (message-goto-body)        (insert body)
        (message-send-and-exit) ))

1. Obviously the code is Lisp.

2. The "Emacs Lisp" factor is zero. (?)

3. The context/application factor is:

    - there are macros to get CL syntax

    - there is Gnus which is used for mail and NNTP
      communication from/to Emacs

    - there is a Gnus interface to composing messages,
      message mode, which by all means can be used
      without Gnus as well, and here it is used to
      automatize mailing

With the "Emacs Lisp" in the title, it sounds like the
focus is 2 - but it should be 1 + 3! (And perhaps it
is, as I haven't read the book.) Some mention of 2.
and in particular where it differs can be useful but
that should amount to a very small part of any such
book.

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Marcin Borkowski]

On 2016-01-29, at 21:46, Emanuel Berg <embe8573@student.uu.se> wrote:

> [...] as I haven't read the book.

This.

Just look at the ToC.  Out of 22 chapters, more than a half are devoted
to Emacs-specific topics.

And let me add that I also like this book a lot.

<shameless-plug>

BTW, now that so many people expressed high opinions on it, I'm even
more intimidated to write a book which is kind of a sequel to it.  But
I'll try anyway.  (And a lot is already written - my Org file with the
book is over 42 kwords now.  Say "hi" to the sunk cost fallacy;-).)

</shameless-plug>

Best,

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> BTW, now that so many people expressed high opinions
> on it, I'm even more intimidated to write a book which
> is kind of a sequel to it.

Do it!

> But I'll try anyway.

"Do or do not. There is no try."

  - master Yoda

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Marcin Borkowski]

On 2016-01-30, at 10:05, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> BTW, now that so many people expressed high opinions
>> on it, I'm even more intimidated to write a book which
>> is kind of a sequel to it.
>
> Do it!

I'm doing it, only slower - I have quite a few projects at work, too.

>
>> But I'll try anyway.
>
> "Do or do not. There is no try."
>
>   - master Yoda

;-)

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Robert Thorpe]

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

> focus is 2 - but it should be 1 + 3! (And perhaps it
> is, as I haven't read the book.)

I think you should install Emacs properly - i.e. with all the Info
manuals.

You use Emacs intensively, you've used it for a long time and you've
learned a lot about it.  I didn't know you did all that without reading
the Emacs Lisp Intro.  That's like doing it with one hand tied behind
your back.  It also explains odd gaps in your knowledge that we've
discussed on this list in the past.

My advice is: ditch Debian Emacs and it's policy against info files.
Download the source, build it and use that.

BR,
Robert Thorpe

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> I think you should install Emacs properly - i.e.
> with all the Info manuals.

What you refer to is:

    emacs24-common-non-dfsg

DFSG = Debian Free Software Guidelines

> You use Emacs intensively, you've used it for a long
> time and you've learned a lot about it.

A compliment from the world's most industrious and
energetic island, last outpost of the long-ears -
first with the industrial revolution, punk, the
conquest of Mount Everest (John Hunt), even the
Raspberry Pi - if I had been a girl, I would have been
glowing like phosphorus by now!

> I didn't know you did all that without reading the
> Emacs Lisp Intro. That's like doing it with one hand
> tied behind your back. It also explains odd gaps in
> your knowledge that we've discussed on this list in
> the past.

Mystery solved - Mulder and Scully can relax :)

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Robert Thorpe]

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

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> I think you should install Emacs properly - i.e.
>> with all the Info manuals.
>
> What you refer to is:
>
>     emacs24-common-non-dfsg
>
> DFSG = Debian Free Software Guidelines

Well, if it's in that package, then that's all you need.  If it isn't
then you have to ask "What else is missing?"  In that case it's worth
building Emacs from source so you get everything.

BR,
Robert Thorpe

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Well, if it's in that package, then that's all you
> need. If it isn't then you have to ask "What else
> is missing?"

I found this after `M-x info RET' and then a search
for "Lisp". It is the second hit (right after "The
Emacs Lisp Reference Manual").


    An Introduction to Programming in Emacs Lisp
    ********************************************

    This is an ‘Introduction to Programming in Emacs
    Lisp’, for people who are not programmers.


Ha - "for people who are not programmers" - that means
programmers should read it.

> In that case it's worth building Emacs from source
> so you get everything.

One of the great benefits with a modern Linux system
is that you don't have to do it. The Debian
repositories which have tens of thousands of software
components are also the reason for the plethora of
distributions that are based on Debian: the Ubuntus,
Knoppix, and many more. Or actually people's itchy
fingers are the reasons for the proliferation itself,
but the repositories are the reason it is all
Debian based.

So while it is a good thing building from source is
a possibility, I say it is only a big step better than
the Windows installers, which were horrible, and there
is no reason that I can see not just to use good old
aptitude to do the job with no web browser or
directories to bounce around in involved.

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Marcin Borkowski]

On 2016-01-31, at 21:45, Emanuel Berg <embe8573@student.uu.se> wrote:

> One of the great benefits with a modern Linux system
> is that you don't have to do it. The Debian

I'd like to point out that one nice benefit of compiling from source
(apart from staying on the bleeding edge) is that you can easily use C-h
f to jump to the source code of functions written in C.

Best,

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> I'd like to point out that one nice benefit of
> compiling from source (apart from staying on the
> bleeding edge) ...

There can be many definitions of "staying on the
bleeding edge". One is: using software to be active,
creative and productive with *your own projects* that
perhaps nobody else knows about, until you release it
for everyone to see and (sometimes) use.

Using the latest releases of everything, including
hardware components, is something some people take
pride in.

But often this is actually something that one
shouldn't do because it is an obstacle to the own
activity which benefits from reliable, familiar tools.

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Marcin Borkowski]

On 2016-02-02, at 01:28, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> I'd like to point out that one nice benefit of
>> compiling from source (apart from staying on the
>> bleeding edge) ...
>
> There can be many definitions of "staying on the
> bleeding edge". One is: using software to be active,
> creative and productive with *your own projects* that
> perhaps nobody else knows about, until you release it
> for everyone to see and (sometimes) use.
>
> Using the latest releases of everything, including
> hardware components, is something some people take
> pride in.
>
> But often this is actually something that one
> shouldn't do because it is an obstacle to the own
> activity which benefits from reliable, familiar tools.

Fair enough.

I have to say, though, that the alleged unreliability of the development
version of Emacs has yet to hit me.

Best,

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> I have to say, though, that the alleged
> unreliability of the development version of Emacs
> has yet to hit me.

Even so, it requires some overhead to deal with it.
For your favorite editor/OS it can be motivated.
Not for too many applications tho.

Actually the point isn't you should or shouldn't do
it. The point is it shouldn't be a goal in itself.

If you ever end up on the computer forums on the
Internet it is significant how the kids talk.
Firefox version x.y.z and just upgraded to one
zillionbytes of RAM!

Of course, I myself would like modern equipment just
as well but it doesn't define me one "bit" as
a computer person. Some of them kids have ten times
the more modern equipment but will they turn out ten
times the more creative as well? We'll see!

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Marcin Borkowski]

On 2016-02-02, at 23:59, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> I have to say, though, that the alleged
>> unreliability of the development version of Emacs
>> has yet to hit me.
>
> Even so, it requires some overhead to deal with it.
> For your favorite editor/OS it can be motivated.
> Not for too many applications tho.
>
> Actually the point isn't you should or shouldn't do
> it. The point is it shouldn't be a goal in itself.
>
> If you ever end up on the computer forums on the
> Internet it is significant how the kids talk.
> Firefox version x.y.z and just upgraded to one
> zillionbytes of RAM!
>
> Of course, I myself would like modern equipment just
> as well but it doesn't define me one "bit" as
> a computer person. Some of them kids have ten times
> the more modern equipment but will they turn out ten
> times the more creative as well? We'll see!

All good points.

Considered that currently I basically use mainly six applications most
of the time, it seems reasonable /for me/ to do so:

1. Emacs.
2. Mail client (mu4e, in Emacs)
3. Pdf viewer (pdf-tools, in Emacs)
4. Music player (vlc through emms, in Emacs)
5. TeX (this I don't compile from source, but I don't install it from my
Linux distro, either)
6. Web browser (FF/eww - FF is basically the only app I use from my
distro)

Of course, I mean /applications/ here, I don't count coreutils, ssh etc.

Also, I /used/ to get excited by "the newest version of this and that,
and that many megz RAM", but I agree that one outgrows that ultimately.
When I was a kid, I was pretty excited by hardware ("look ma,
a one-gigabyte-hdd - whoa!").  Now I consider my computer a shell for my
data, and changing computers is an uncomfortable chore instead of
a period of excitement.

I have yet to outgrow excitement about cool features in newer versions
of Emacs, though. ;-)

Best,

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> Of course, I mean /applications/ here, I don't count
> coreutils, ssh etc.

*iiiiii* - if your were to compile all that manually
setting up even a rudimentary Unix system would be
a challenge.

But there are people who do it. I suppose they get
a very solid under-the-hood understanding if
nothing else.

> Also, I /used/ to get excited by "the newest version
> of this and that, and that many megz RAM", but
> I agree that one outgrows that ultimately.
> When I was a kid, I was pretty excited by hardware
> ("look ma, a one-gigabyte-hdd - whoa!").
> Now I consider my computer a shell for my data, and
> changing computers is an uncomfortable chore instead
> of a period of excitement.

That's exactly right! It was the exact same story only
when I was I kid instead of the one-gigabyte HDD there
was an exciting transition from 800K to
1.4M floppies :)

Some people on this list should be able to tell us of
huge coils of tape if not vacuum tubes :)

> I have yet to outgrow excitement about cool features
> in newer versions of Emacs, though. ;-)

There is no reason to outgrow things that are good!

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Nick Dokos]

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

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Of course, I mean /applications/ here, I don't count
>> coreutils, ssh etc.
>
> *iiiiii* - if your were to compile all that manually
> setting up even a rudimentary Unix system would be
> a challenge.
>
> But there are people who do it. I suppose they get
> a very solid under-the-hood understanding if
> nothing else.
>

See e.g.

https://en.wikipedia.org/wiki/Linux_From_Scratch

--
Nick

Re: on ``An Introduction to Programming in Emacs Lisp''

[Pascal J. Bourguignon]

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

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Of course, I mean /applications/ here, I don't count
>> coreutils, ssh etc.
>
> *iiiiii* - if your were to compile all that manually
> setting up even a rudimentary Unix system would be
> a challenge.
>
> But there are people who do it. I suppose they get
> a very solid under-the-hood understanding if
> nothing else.

Yes, it's called Linux From Scratch LFS.
If you ever have a lazy Sunday afternoon, try it.
http://www.linuxfromscratch.org/

-- 
__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: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> Yes, it's called Linux From Scratch LFS. If you ever
> have a lazy Sunday afternoon, try it.

What I remember it is "Linux From Scratch from Linux"
rather because you use a Linux system to do it.
But perhaps that was only the early stages.
Actually this is a cool project.

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Daniel Bastos]

Marcin Borkowski <mbork@mbork.pl> writes:

[...]

> I have yet to outgrow excitement about cool features in newer versions
> of Emacs, though. ;-)

Lol.  You're very fond of emacs, clearly.  No wonder.

I side with Emmanuel Berg's point of view because I tend to look at
software as things which cannot fail whatever.  If they fail, chances
are I will look into the failure to see why.  I don't want to find out
that I'm spending hours investigating an experiment someone decided to
try out since last week.  IOW, if something failed, I must be dealing
with a true exceptional situation here.

Of course, nothing keeps from having a system that's used merely for
playing.  (Though I particularly don't have one.  In fact, I don't have
a computer at home.  I use one at work.)

Re: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

Daniel Bastos <dbastos@toledo.com> writes:

> I tend to look at software as things which cannot
> fail whatever. If they fail, chances are I will look
> into the failure to see why. I don't want to find
> out that I'm spending hours investigating an
> experiment someone decided to try out since last
> week. IOW, if something failed, I must be dealing
> with a true exceptional situation here.

Indeed.

One of the many beauties to it.

> (Though I particularly don't have one. In fact,
> I don't have a computer at home. I use one at work.)

Indeed.

It is like going to the workshop instead of carrying
around the toolbox everywhere, always thinking about
it but still not being able to have everything
cramped in.

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Rusi]

On Tuesday, February 2, 2016 at 12:52:47 PM UTC+5:30, Marcin Borkowski wrote:
> On 2016-02-02, at 01:28, Emanuel Berg wrote:
> 
> > Marcin Borkowski writes:
> >
> >> I'd like to point out that one nice benefit of
> >> compiling from source (apart from staying on the
> >> bleeding edge) ...
> >
> > There can be many definitions of "staying on the
> > bleeding edge". One is: using software to be active,
> > creative and productive with *your own projects* that
> > perhaps nobody else knows about, until you release it
> > for everyone to see and (sometimes) use.
> >
> > Using the latest releases of everything, including
> > hardware components, is something some people take
> > pride in.
> >
> > But often this is actually something that one
> > shouldn't do because it is an obstacle to the own
> > activity which benefits from reliable, familiar tools.
> 
> Fair enough.
> 
> I have to say, though, that the alleged unreliability of the development
> version of Emacs has yet to hit me.

See my other thread on python mode.
In summary: Builtin python mode is giving various unfriendly messages in 
emacs 25 not 24

on specifying the C source code directory (Was: Re: on ``An Introduction to Programming in Emacs Lisp'')

[Daniel Bastos]

Marcin Borkowski <mbork@mbork.pl> writes:

[...]

> I'd like to point out that one nice benefit of compiling from source
> (apart from staying on the bleeding edge) is that you can easily use C-h
> f to jump to the source code of functions written in C.

You seem a good person to ask then.  I'm able to look up source code in
C source code in a Windows installation.  But I always need to tell it
which is the directory source code.  How could I make sure it knows
which directory that is?

Thank you.

Re: on specifying the C source code directory (Was: Re: on ``An Introduction to Programming in Emacs Lisp'')

[Marcin Borkowski]

On 2016-02-01, at 13:07, Daniel Bastos <dbastos@toledo.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
> [...]
>
>> I'd like to point out that one nice benefit of compiling from source
>> (apart from staying on the bleeding edge) is that you can easily use C-h
>> f to jump to the source code of functions written in C.
>
> You seem a good person to ask then.  I'm able to look up source code in
> C source code in a Windows installation.  But I always need to tell it
> which is the directory source code.  How could I make sure it knows
> which directory that is?

No idea.  It Just Works™ on my (GNU/Linux) machine, after compiling from
source, without specifying the directory even once.

Best,

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

Re: on specifying the C source code directory (Was: Re: on ``An Introduction to Programming in Emacs Lisp'')

[tomas]

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

On Mon, Feb 01, 2016 at 01:38:12PM +0100, Marcin Borkowski wrote:
> 
> On 2016-02-01, at 13:07, Daniel Bastos <dbastos@toledo.com> wrote:
> 
> > Marcin Borkowski <mbork@mbork.pl> writes:
> >
> > [...]
> >
> >> I'd like to point out that one nice benefit of compiling from source
> >> (apart from staying on the bleeding edge) is that you can easily use C-h
> >> f to jump to the source code of functions written in C.
> >
> > You seem a good person to ask then.  I'm able to look up source code in
> > C source code in a Windows installation.  But I always need to tell it
> > which is the directory source code.  How could I make sure it knows
> > which directory that is?
> 
> No idea.  It Just Works™ on my (GNU/Linux) machine, after compiling from
> source, without specifying the directory even once.

There is a (documented) variable called "source-directory" which seems
to do that. Try perhaps setting it to an appropriate value.

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

iEYEARECAAYFAlavUHYACgkQBcgs9XrR2kZpEgCffO99NhMmEiQVCV3QoQHnNXD5
a4QAnjeFyo5tVDYNTMWfVimCYvyq2V0O
=fH+w
-----END PGP SIGNATURE-----

Re: on specifying the C source code directory (Was: Re: on ``An Introduction to Programming in Emacs Lisp'')

[Kaushal Modi]

Also check out the find-function-C-source-directory.
http://emacs.stackexchange.com/a/19597/115

If you build emacs from source, that variable is automatically set to
"${BUILD_DIR}/src". If you haven't built emacs from source, you can
download the src/ directory from source (
http://git.savannah.gnu.org/cgit/emacs.git/tree/src?h=emacs-25 ) and set
this variable to point to the location where you downloaded the src/ dir.
Of course, you should download the src/ dir corresponding to the emacs
version you have installed. The example link I posted points to the latest
version of the emacs-25 git branch.

Re: on specifying the C source code directory

[Daniel Bastos]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Also check out the find-function-C-source-directory.

Thanks so much.

(setq find-function-C-source-directory 
   (file-name-as-directory "path/to/my/emacs/src"))

Re: on specifying the C source code directory

[Emanuel Berg]

Daniel Bastos <dbastos@toledo.com> writes:

> (setq find-function-C-source-directory
> (file-name-as-directory "path/to/my/emacs/src"))

`file-name-as-directory' just adds a trail slash so
that can be added manually.

Also, it doesn't seem to be necessary! I never thought
about it, but I see now that I have it like this - no
slash - and it has always worked just the same:

    (defvar find-function-C-source-directory)
    (setq find-function-C-source-directory "~/.emacs.d/emacs-24.1/src")

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

Re: on specifying the C source code directory

[Marcin Borkowski]

On 2016-02-02, at 01:17, Emanuel Berg <embe8573@student.uu.se> wrote:

> Daniel Bastos <dbastos@toledo.com> writes:
>
>> (setq find-function-C-source-directory
>> (file-name-as-directory "path/to/my/emacs/src"))
>
> `file-name-as-directory' just adds a trail slash so
> that can be added manually.

As the docstring says, in Unix this is so.  I don't know about other
systems.

> Also, it doesn't seem to be necessary! I never thought
> about it, but I see now that I have it like this - no
> slash - and it has always worked just the same:
>
>     (defvar find-function-C-source-directory)
>     (setq find-function-C-source-directory "~/.emacs.d/emacs-24.1/src")

Out of curiosity: why defvar?

Best,

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

defvar and "assignment to free variable" (was: Re: on specifying the C source code directory)

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> As the docstring says, in Unix this is so.
> I don't know about other systems.

Me neither :)

>> (defvar find-function-C-source-directory)
>> (setq find-function-C-source-directory "~/.emacs.d/emacs-24.1/src")
>
> Out of curiosity: why defvar?

Without it, when I compile, it says:

    In toplevel form:
    help-new.el:11:7:Warning: assignment to free variable
        `find-function-C-source-directory'

`defvar' here is just used to communicate that you
will use the variable. Because that's exactly what
happens next, this isn't a hack. Really!

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

Re: on specifying the C source code directory

[Daniel Bastos]

<tomas@tuxteam.de> writes:

[...]

> There is a (documented) variable called "source-directory" which seems
> to do that. Try perhaps setting it to an appropriate value.

This variable is documented as such, but it doesn't seem to take the
desired effect.  Other posts mentioned

  find-function-C-source-directory

which does.

Re: on specifying the C source code directory

[tomas]

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

On Tue, Feb 02, 2016 at 09:57:22AM -0200, Daniel Bastos wrote:
> <tomas@tuxteam.de> writes:
> 
> [...]
> 
> > There is a (documented) variable called "source-directory" which seems
> > to do that. Try perhaps setting it to an appropriate value.
> 
> This variable is documented as such, but it doesn't seem to take the
> desired effect.  Other posts mentioned
> 
>   find-function-C-source-directory

Yes, thanks

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

iEYEARECAAYFAlawmIYACgkQBcgs9XrR2kbAuQCfcgpHOsF67sUUJcktAkTvVgTk
+98AoIE1cAJf+46co3i60ZjWZGL0dkVa
=aHS6
-----END PGP SIGNATURE-----

Re: on ``An Introduction to Programming in Emacs Lisp''

[Rusi]

On Saturday, January 30, 2016 at 5:53:56 AM UTC+5:30, Robert Thorpe wrote:
> My advice is: ditch Debian Emacs and it's policy against info files.
> Download the source, build it and use that.
> 
> BR,
> Robert Thorpe

JFTR:
I keep alternating between debian (ubuntu) emacs and "The Source"

And I find:

$ dpkg -S eintr.info
emacs24-common-non-dfsg: /usr/share/info/emacs-24/eintr.info.gz

[Although I am running 25 from source :-) ]

Re: on ``An Introduction to Programming in Emacs Lisp''

[Javier]

>> An Introduction to Programming in Emacs Lisp By
>> Robert J. Chassell, published by GNU Press Edition
>> 3.10, 28 October 2009 ISBN 1-882114-43-4
> 
> What fun!
> 
> I never heard of this one. Books on Lisp sure don't
> grow on trees (not even firewood does ha ha).

You can order it directly from the FSF.

http://shop.fsf.org/product/Intro_to_Emacs_Lisp_3rd_Ed/

Re: on ``An Introduction to Programming in Emacs Lisp''

[Pascal J. Bourguignon]

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

> Daniel Bastos <dbastos@toledo.com> writes:
>
>> This is a report [...] regarding
>>
>> An Introduction to Programming in Emacs Lisp By
>> Robert J. Chassell, published by GNU Press Edition
>> 3.10, 28 October 2009 ISBN 1-882114-43-4
>
> What fun!
>
> I never heard of this one. Books on Lisp sure don't
> grow on trees (not even firewood does ha ha).coruse,
>
> The last book I saw on Lisp was this one:
>
> @book{lispcraft,
>   title      = {LISPcraft},
>   author     = {Robert Wilensky},
>   publisher  = {Norton},
>   year       = 1984,
>   ISBN       = 0393954420
> }

You should spend a little more time in libraries then.  Of course,
nowadays libraries are not brick-and-mortar anymore, it's Amazon:

http://www.amazon.fr/Common-Lisp-Recipes-Problem-Solution-Approach/dp/1484211774/
http://www.amazon.fr/Practical-Common-Lisp-Peter-Seibel/dp/1430242906/

-- 
__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: on ``An Introduction to Programming in Emacs Lisp''

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> You should spend a little more time in libraries
> then. Of course, nowadays libraries are not
> brick-and-mortar anymore, it's Amazon

Oh, yeah? Click on the add and read yet another
customer review so you don't have to read the actual
book! Instead you can have an opinion and be unaware
what's going on five meters in front of you!

And provide even more customer-behavior information to
those thrice-accursed surveillance algorithms so
they'll be even better at turning you into a moron
that buys stuff!

I've been in libraries from Kazan to New York - by the
way *still* the undisputed publishing capital of
the world!

The best book on Lisp so far which isn't the way I'd
write a book, but anyway - is:

@book{land-of-lisp,
  title      = {Land of Lisp},
  author     = {Conrad Barski},
  publisher  = {No Starch},
  year       = 2010,
  ISBN       = 1593272812,
}

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

Re: on ``An Introduction to Programming in Emacs Lisp''

[Eli Zaretskii]

> From: Daniel Bastos <dbastos@toledo.com>
> Date: Tue, 26 Jan 2016 16:08:34 -0200
> 
> This is a report on minor typos and imperfections regarding
> 
>   An Introduction to Programming in Emacs Lisp
>   By Robert J. Chassell, published by GNU Press
>   Edition 3.10, 28 October 2009 ISBN 1-882114-43-4
> 

Thanks, I've fixed the typos that you pointed out.