Re: Comment on Emacs Lisp Introduction

Re: Comment on Emacs Lisp Introduction

[Robert J. Chassell]

    Goto node "(eintr) Buffer Names", and look at the paragraphs that start at
    lines 37 and 49. Both are saying basically the same. Aren't they redundant?

Please tell me the words of the lines you mean; I tried using `M-g
M-g' (`goto-line') and the command went to the beginning of the node;
probably it counted from the beginning of whole buffer as the
documentation says.  In any case, I wrote in "(eintr) Who You Are":

       Firstly, I try to say everything at least three times: first, to
    introduce it; second, to show it in context; and third, to show it in a
    different context, or to review it.

and I am pretty sure I covered most things at least twice.  You may be a
programmer for whom the book is *not* written.

    PS: I don't know if this is the suitable channel for comments/suggestions.
    If it isn't, please let me know.

I don't know.  Others can comment.

-- 
    Robert J. Chassell                          
    bob@gnu.org                                 bob@rattlesnake.com
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Comment on Emacs Lisp Introduction

[Robert J. Chassell]

    But anyway, this question isn't very relevant at all, so, ignore it if you
    don't see the issue.

I don't see the issue; I agree it is redundant, but the intro is supposed
to be redundant.  Maybe if I were rewriting it, I would remove some of
the redundancy; but I am not.

-- 
    Robert J. Chassell                          
    bob@gnu.org                                 bob@rattlesnake.com
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Comment on Emacs Lisp Introduction

[Fren Zeee]

Robert, does your intro book explain things like how to get the full
definition of a function like for example

next-line which is a down arrow

(symbol-function 'next-line)
#[(arg) "\b\203& [next-line-add-newlines arg abbrev-mode 1 nil "
" line-move (line-move arg) ((... ...))] 3 1337315 "p"]

I could not figure out from online doc and apropos how to do it.

Basically, I want lisp code to see how it maintains to try to got to
the same column below unlike for example

forward-line

Franz

On Fri, Jul 30, 2010 at 7:44 AM, Robert J. Chassell <bob@gnu.org> wrote:
>    But anyway, this question isn't very relevant at all, so, ignore it if you
>    don't see the issue.
>
> I don't see the issue; I agree it is redundant, but the intro is supposed
> to be redundant.  Maybe if I were rewriting it, I would remove some of
> the redundancy; but I am not.
>
> --
>    Robert J. Chassell
>    bob@gnu.org                                 bob@rattlesnake.com
>    http://www.rattlesnake.com                  http://www.teak.cc
>
>

Re: Comment on Emacs Lisp Introduction

[David Kastrup]

Fren Zeee <frenzeee@gmail.com> writes:

> Robert, does your intro book explain things like how to get the full
> definition of a function like for example
>
> next-line which is a down arrow
>
> (symbol-function 'next-line)
> #[(arg) "\b\203& [next-line-add-newlines arg abbrev-mode 1 nil "
> " line-move (line-move arg) ((... ...))] 3 1337315 "p"]
>
> I could not figure out from online doc and apropos how to do it.

Huh?

C-h f next-line RET gives the online doc, and the very first line is

next-line is an interactive compiled Lisp function in `simple.el'.

where the string `simple.el' is a hyperlink leading to the definition of
next-line in simple.el.  So I don't understand what problem you
encountered using the online documentation.  You can also use
M-x find-function RET next-line RET
to get to the source.

What is your problem?

-- 
David Kastrup

Re: Comment on Emacs Lisp Introduction

[Fren Zeee]

On Sat, Jul 31, 2010 at 1:01 AM, David Kastrup <dak@gnu.org> wrote:
> Fren Zeee <frenzeee@gmail.com> writes:
>
>> Robert, does your intro book explain things like how to get the full
>> definition of a function like for example
>>
>> next-line which is a down arrow
>>
>> (symbol-function 'next-line)
>> #[(arg) " \203& [next-line-add-newlines arg abbrev-mode 1 nil "
>> " line-move (line-move arg) ((... ...))] 3 1337315 "p"]
>>
>> I could not figure out from online doc and apropos how to do it.
>
> Huh?
>
> C-h f next-line RET gives the online doc, and the very first line is
>
> next-line is an interactive compiled Lisp function in `simple.el'.
>
> where the string `simple.el' is a hyperlink leading to the definition of
> next-line in simple.el.  So I don't understand what problem you
> encountered using the online documentation.  You can also use
> M-x find-function RET next-line RET
> to get to the source.
>
> What is your problem?

David, My problem is that I want to see the function definition of next-line.

Re: Comment on Emacs Lisp Introduction

[Fren Zeee]

On Sat, Jul 31, 2010 at 12:33 PM, Fren Zeee <frenzeee@gmail.com> wrote:
> On Sat, Jul 31, 2010 at 1:01 AM, David Kastrup <dak@gnu.org> wrote:
>> Fren Zeee <frenzeee@gmail.com> writes:
>>
>>> Robert, does your intro book explain things like how to get the full
>>> definition of a function like for example
>>>
>>> next-line which is a down arrow
>>>
>>> (symbol-function 'next-line)
>>> #[(arg) " \203& [next-line-add-newlines arg abbrev-mode 1 nil "
>>> " line-move (line-move arg) ((... ...))] 3 1337315 "p"]
>>>
>>> I could not figure out from online doc and apropos how to do it.
>>
>> Huh?
>>
>> C-h f next-line RET gives the online doc, and the very first line is
>>
>> next-line is an interactive compiled Lisp function in `simple.el'.
>>
>> where the string `simple.el' is a hyperlink leading to the definition of
>> next-line in simple.el.  So I don't understand what problem you
>> encountered using the online documentation.  You can also use
>> M-x find-function RET next-line RET
>> to get to the source.
>>
>> What is your problem?
>
> David, My problem is that I want to see the function definition of next-line.
>
ie lisp code without having to search, find which file has it and then
open it. On some platforms, I dont have the source and its an
unnecessary interruption in the work to go and make the detour to
search for it.

RE: Comment on Emacs Lisp Introduction

[Drew Adams]

> >> What is your problem?
> >
> > David, My problem is that I want to see the function 
> > definition of next-line.
>
> ie lisp code without having to search, find which file has it and then
> open it. On some platforms, I dont have the source and its an
> unnecessary interruption in the work to go and make the detour to
> search for it.

As you saw, `symbol-function' gives you the current definition of a function.
However, in your example use of it you can see that it is not very useful if the
definition is byte-compiled.  If you do not have access to the source code, and
if the current definition does not come from the source code but from
byte-compiled code, then what do you expect to see?

If you do have access to the source code and if the function is defined in Lisp,
then `symbol-function' will show you that Lisp code (assuming you have evaluated
the source code).

Re: Comment on Emacs Lisp Introduction

[Óscar Fuentes]

Fren Zeee <frenzeee@gmail.com> writes:

>> David, My problem is that I want to see the function definition of
>> next-line.
>>
> ie lisp code without having to search, find which file has it and then
> open it.

Emacs, the self-documenting text editor.

You know that whatever C-h f is, it knows what you want to know, so you
just need to investigate "C-h f". For that you can do "C-h k C-h f" for
seeing help about the function invoked with "C-h f", which is
describe-function. You use the hyperlink from the Help window to jump to
the function definition. Then you read the source code a bit or do a
quick text search to learn that what you probably want is

find-lisp-object-file-name

What's find-lisp-object-file-name? Well,

C-h f find-lisp-object-file-name RET

will tell you... and so on.

> On some platforms, I dont have the source and its an unnecessary
> interruption in the work to go and make the detour to search for it.

Sorry, I don't understand this. How do you expect seeing the function
definition without having the source code?

Re: Comment on Emacs Lisp Introduction

[David Kastrup]

Fren Zeee <frenzeee@gmail.com> writes:

> On Sat, Jul 31, 2010 at 12:33 PM, Fren Zeee <frenzeee@gmail.com> wrote:
>> On Sat, Jul 31, 2010 at 1:01 AM, David Kastrup <dak@gnu.org> wrote:
>>> Fren Zeee <frenzeee@gmail.com> writes:
>>>
>>>> Robert, does your intro book explain things like how to get the full
>>>> definition of a function like for example
>>>>
>>>> next-line which is a down arrow
>>>>
>>>> (symbol-function 'next-line)
>>>> #[(arg) " \203& [next-line-add-newlines arg abbrev-mode 1 nil "
>>>> " line-move (line-move arg) ((... ...))] 3 1337315 "p"]
>>>>
>>>> I could not figure out from online doc and apropos how to do it.
>>>
>>> Huh?
>>>
>>> C-h f next-line RET gives the online doc, and the very first line is
>>>
>>> next-line is an interactive compiled Lisp function in `simple.el'.
>>>
>>> where the string `simple.el' is a hyperlink leading to the definition of
>>> next-line in simple.el.  So I don't understand what problem you
>>> encountered using the online documentation.  You can also use
>>> M-x find-function RET next-line RET
>>> to get to the source.
>>>
>>> What is your problem?
>>
>> David, My problem is that I want to see the function definition of next-line.
>>
> ie lisp code without having to search, find which file has it and then
> open it.

Emacs does all the work for you, so why do you complain?

> On some platforms, I dont have the source and its an unnecessary
> interruption in the work to go and make the detour to search for it.

Distributing Emacs without corresponding source to the byte code is a
violation of its license.

Byte code is byte code.  You can't turn byte code back into Elisp.  If
you want to look at the byte code in a more readable form than that used
by just printing its Lisp forms, you can use M-x disassemble on the
compiled command.

That is most certainly not the corresponding source code, but you
_refuse_ to read the corresponding source code for whatever twisted
reason.

-- 
David Kastrup

Re: Comment on Emacs Lisp Introduction

[Harald Hanche-Olsen]

+ David Kastrup <dak@gnu.org>:

> Distributing Emacs without corresponding source to the byte code is a
> violation of its license.

Is it? I thought you only had to offer access to the source code.
Section 6 of the GPL lists a number of ways to do this. But I would
agree that giving people a runnable emacs without lisp/*.el[.gz] is at
least in bad taste.

- Harald

Re: Comment on Emacs Lisp Introduction

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

[snip]

>> On some platforms, I dont have the source and its an unnecessary
>> interruption in the work to go and make the detour to search for it.
>
> Distributing Emacs without corresponding source to the byte code is a
> violation of its license.

Really? I thought that Emacs' license was the GPL ;-)

Maybe the OP has access to the source code, but for whatever reason
can't install it everywhere he would like to.

[snip]

Re: Comment on Emacs Lisp Introduction

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:
 > + David Kastrup <dak@gnu.org>:
 > 
 > > Distributing Emacs without corresponding source to the byte code is a
 > > violation of its license.
 > 
 > Is it? I thought you only had to offer access to the source code.

Normally you have to offer access to source in the same way as you
offer access to binaries.  You don't need to bundle them in the same
medium, but normally they're available more or less side by side.

Under certain circumstances the object code may be conveyed separately
from the source, but the conditions are pretty onerous (it must be a
physical product, and it must be accompanied with a paper certificate
promising that *anybody* with a copy of the object code can get it
from you); it's unlikely that the OP received his code that way.

I'm less than impressed with the OP's complaints, of course.

Re: Comment on Emacs Lisp Introduction

[Fren Zeee]

On Mon, Aug 2, 2010 at 1:26 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Harald Hanche-Olsen writes:
>  > + David Kastrup <dak@gnu.org>:
>  >
>  > > Distributing Emacs without corresponding source to the byte code is a
>  > > violation of its license.
>  >
>  > Is it? I thought you only had to offer access to the source code.
>
> Normally you have to offer access to source in the same way as you
> offer access to binaries.  You don't need to bundle them in the same
> medium, but normally they're available more or less side by side.
>
> Under certain circumstances the object code may be conveyed separately
> from the source, but the conditions are pretty onerous (it must be a
> physical product, and it must be accompanied with a paper certificate
> promising that *anybody* with a copy of the object code can get it
> from you); it's unlikely that the OP received his code that way.
>
> I'm less than impressed with the OP's complaints, of course.

I am not complaining. Its just that I dont have it, and need to find
source matching this old executable, which means that it will take
some time to search for the particular freeze or tar file if it is
still on the web.

>
>
>

Re: Comment on Emacs Lisp Introduction

[Stephen J. Turnbull]

Fren Zeee writes:

 > I am not complaining. Its just that I dont have it, and need to find
 > source matching this old executable, which means that it will take
 > some time to search for the particular freeze or tar file if it is
 > still on the web.

Huh.  Why are you so focused on "old"?  If you are an historian, you'd
better enjoy such searches because that's what historians do.  If
you're a programmer, though, old versions are of no particular
interest unless you already know them well enough for forward
differences to have meaning to you.

If you're interested in a particular function, M-x disassemble.

Otherwise, why do you refuse to take the advice to use a modern
version?  The basic architecture hasn't changed since the GNU rewrite.
Functions that are more complex now have become that way for a reason;
those reasons are worth studying.  Many functions are *not* more
complex in themselves than they were then, but have become simpler
because they delegate subtasks that have increased in complexity to
other functions.  It's easier to work backward from modern versions which
are well-developed based on better abstractions (cf. Michael Stokes'
comment about Green's Theorem: "It is trivial.  It is trivial because
the concepts have been well-defined.  That definition took decades."
-- or something like that, I don't have _Calculus on Manifolds_ handy).

Re: Comment on Emacs Lisp Introduction

[Fren Zeee]

On Mon, Aug 2, 2010 at 8:26 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Fren Zeee writes:
>
>  > I am not complaining. Its just that I dont have it, and need to find
>  > source matching this old executable, which means that it will take
>  > some time to search for the particular freeze or tar file if it is
>  > still on the web.
>
> Huh.  Why are you so focused on "old"?  If you are an historian, you'd
> better enjoy such searches because that's what historians do.  If
> you're a programmer, though, old versions are of no particular
> interest unless you already know them well enough for forward
> differences to have meaning to you.

It appears that software is developed both outside-in and inside-out
at various times and the oldest most primitive version has the
simplest structure, and least features. IMHO it would be for
educational purposes, not just historical.

For a professor like you, who knows a lot more, perhaps, can start
anywhere in the field, but not for a newbie like myself.

> If you're interested in a particular function, M-x disassemble.

Show me an example where disassemble would help in understanding the
code. I think it gives VM code, not lisp code.

Give a walk-thru concrete example of several functions that illustrate
how disassemble would help understanding the code.

> Otherwise, why do you refuse to take the advice to use a modern
> version?  The basic architecture hasn't changed since the GNU rewrite.

OK, so give me a diagram which shows the scanner of LISP interpreter,
and in addition some comments for writing the primitives.

> Functions that are more complex now have become that way for a reason;
> those reasons are worth studying.  Many functions are *not* more
> complex in themselves than they were then, but have become simpler
> because they delegate subtasks that have increased in complexity to
> other functions.  It's easier to work backward from modern versions which
> are well-developed based on better abstractions (cf. Michael Stokes'
> comment about Green's Theorem: "It is trivial.  It is trivial because
> the concepts have been well-defined.  That definition took decades."
> -- or something like that, I don't have _Calculus on Manifolds_ handy).

I know what you mean but you cant stuff that into the mouth of a
newbie before knowing something of vector calculus.

Franz Xe

It would certainly help if I can get some debug sessions from you and
the other gentleman who gave me the initial advice on playing with
emacs using its own debug and gdb, a typescript file.

Re: Comment on Emacs Lisp Introduction

[Stephen J. Turnbull]

Fren Zeee writes:

 > Give a walk-thru concrete example

 > OK, so give me a diagram which shows the scanner of LISP interpreter,

 > and in addition some comments for writing the primitives.

 > It would certainly help if I can get some debug sessions from you

Good luck finding the kind of help you want, but it would cost me
personally way too much time and effort to provide it (my PhD is in
Economics, and that's what I teach, not computer science -- everything
I know about programming is self-taught).

Re: Comment on Emacs Lisp Introduction

[David Kastrup]

Fren Zeee <frenzeee@gmail.com> writes:

> Show me [...]
>
> Give [...]
>
> OK, so give me [...]

If you want personalized walk-throughs, I suggest that you find somebody
willing to tutor you for appropriate recompensation.

This mailing list is not a programming course.  It may provide help
where your efforts of working with the existing material fall short, but
the person responsible for getting you up to scratch is you, and nobody
else.

-- 
David Kastrup

Re: Comment on Emacs Lisp Introduction

[Fren Zeee]

I dont think it takes very much time to generate the typescript on the
plan that he suggested, any more than the time to do it. All it
appears is the absence of intention. I did not ask personal walk-thru.
I asked him to give a typescript based on the plan he suggested for
knowing the architecture.

On Wed, Aug 4, 2010 at 2:22 AM, David Kastrup <dak@gnu.org> wrote:
> Fren Zeee <frenzeee@gmail.com> writes:
>
>> Show me [...]
>>
>> Give [...]
>>
>> OK, so give me [...]
>
> If you want personalized walk-throughs, I suggest that you find somebody
> willing to tutor you for appropriate recompensation.
>
> This mailing list is not a programming course.  It may provide help
> where your efforts of working with the existing material fall short, but
> the person responsible for getting you up to scratch is you, and nobody
> else.
>
> --
> David Kastrup
>
>
>

Re: Comment on Emacs Lisp Introduction

[Fren Zeee]

It will benefit many people and can be added to the documentation of emacs.

On Thu, Aug 5, 2010 at 1:13 PM, Fren Zeee <frenzeee@gmail.com> wrote:
> I dont think it takes very much time to generate the typescript on the
> plan that he suggested, any more than the time to do it. All it
> appears is the absence of intention. I did not ask personal walk-thru.
> I asked him to give a typescript based on the plan he suggested for
> knowing the architecture.
>
> On Wed, Aug 4, 2010 at 2:22 AM, David Kastrup <dak@gnu.org> wrote:
>> Fren Zeee <frenzeee@gmail.com> writes:
>>
>>> Show me [...]
>>>
>>> Give [...]
>>>
>>> OK, so give me [...]
>>
>> If you want personalized walk-throughs, I suggest that you find somebody
>> willing to tutor you for appropriate recompensation.
>>
>> This mailing list is not a programming course.  It may provide help
>> where your efforts of working with the existing material fall short, but
>> the person responsible for getting you up to scratch is you, and nobody
>> else.
>>
>> --
>> David Kastrup
>>
>>
>>
>