Discussion:
emacs construction + customisation / extension
(too old to reply)
Richard Smith
2024-03-06 09:39:25 UTC
Permalink
Not much traffic on here, so if okay, a fairly dumb question...

Given been using emacs for more than 25 years, writing files - text
documents, markup docs to go through a typesetter, computer programs,
and running small computer programs written in elisp for engineering
calculations, etc.

These 25 years onwards...

How would I learn how emacs is constructed => how should you really
customise it, use it, etc.?

As in - can you point me to a good info. source / article / book /
info-repository or whatever?

Regards,
Rich Smith
Aidan Kehoe
2024-03-06 14:34:11 UTC
Permalink
Post by Richard Smith
Not much traffic on here, so if okay, a fairly dumb question...
Given been using emacs for more than 25 years, writing files - text
documents, markup docs to go through a typesetter, computer programs,
and running small computer programs written in elisp for engineering
calculations, etc.
These 25 years onwards...
How would I learn how emacs is constructed => how should you really
customise it, use it, etc.?
As in - can you point me to a good info. source / article / book /
info-repository or whatever?
GNU Emacs is a mess. The usual rhythm of things is that those interested in
best practice are driven away from contributing to the program. If it had good
management Perl would never have gained traction; Emacs was around first and
had a larger user base that manipulated text all day every day.

It has a lot of cross-over with Common Lisp, and Common Lisp is not a mess. I
would encourage using best practice from Common Lisp as far as is possible in
Emacs Lisp.

https://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part1/faq-doc-4.html

https://web.archive.org/web/20051231134345/http://www.aiai.ed.ac.uk/~jeff/lisp/cl-pitfalls

Now, as an active XEmacs developer, I am throwing stones from a glass house,
GNU has had more developer momentum and a larger user base for years and
correspondingly has more features (lexical scope being the big one).

But, generally, GNU Emacs is not the Sistine Chapel, doing things right in
interacting with it is like painting a fresco on a hovel. You might give
yourself a feeling of a job well done but the structure is still made of twine,
packing crates, and corrugated iron.
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)
Richard Smith
2024-03-06 21:31:43 UTC
Permalink
Post by Aidan Kehoe
Post by Richard Smith
Not much traffic on here, so if okay, a fairly dumb question...
Given been using emacs for more than 25 years, writing files - text
documents, markup docs to go through a typesetter, computer programs,
and running small computer programs written in elisp for engineering
calculations, etc.
These 25 years onwards...
How would I learn how emacs is constructed => how should you really
customise it, use it, etc.?
As in - can you point me to a good info. source / article / book /
info-repository or whatever?
GNU Emacs is a mess. The usual rhythm of things is that those interested in
best practice are driven away from contributing to the program. If it had good
management Perl would never have gained traction; Emacs was around first and
had a larger user base that manipulated text all day every day.
It has a lot of cross-over with Common Lisp, and Common Lisp is not a mess. I
would encourage using best practice from Common Lisp as far as is possible in
Emacs Lisp.
https://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part1/faq-doc-4.html
https://web.archive.org/web/20051231134345/http://www.aiai.ed.ac.uk/~jeff/lisp/cl-pitfalls
Now, as an active XEmacs developer, I am throwing stones from a glass house,
GNU has had more developer momentum and a larger user base for years and
correspondingly has more features (lexical scope being the big one).
But, generally, GNU Emacs is not the Sistine Chapel, doing things right in
interacting with it is like painting a fresco on a hovel. You might give
yourself a feeling of a job well done but the structure is still made of twine,
packing crates, and corrugated iron.
Thanks for the categorisation.
That could be why I do what I know of and haven't formed a fundamental
view. Because it doesn't exist?
There is no Donald Knuth | TeX, "Programming in C" by Kernighan and
Ritchie, How to use GnuPlot manual by Dartmouth College - but no "here's
the structure and design principle of emacs" from anywhere?
Lawrence D'Oliveiro
2024-03-06 21:54:34 UTC
Permalink
... but no "here's
the structure and design principle of emacs" from anywhere?
Note sure if this <https://www.emacswiki.org/> helps ...
Aidan Kehoe
2024-03-07 08:59:41 UTC
Permalink
[...] Thanks for the categorisation. That could be why I do what I know of
and haven't formed a fundamental view. Because it doesn't exist?
Not to my knowledge. I like the XEmacs lispref and XEmacs internals manual; I
haven’t recently looked at the corresponding GNU document, elisp.info , but bad
documentation is always better than no documentation. Some guidance as to best
practice in XEmacs, that will also apply to GNU:

https://www.xemacs.org/Documentation/21.5/html/lispref_65.html#Tips
There is no Donald Knuth | TeX, "Programming in C" by Kernighan and
Ritchie, How to use GnuPlot manual by Dartmouth College - but no "here's
the structure and design principle of emacs" from anywhere?
Nothing beyond elisp.info .
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)
Richard Smith
2024-03-08 07:13:03 UTC
Permalink
Post by Aidan Kehoe
[...] Thanks for the categorisation. That could be why I do what I know of
and haven't formed a fundamental view. Because it doesn't exist?
Not to my knowledge. I like the XEmacs lispref and XEmacs internals manual; I
haven’t recently looked at the corresponding GNU document, elisp.info , but bad
documentation is always better than no documentation. Some guidance as to best
https://www.xemacs.org/Documentation/21.5/html/lispref_65.html#Tips
...
I already do the one about start my own functions [without long
incredibly abstruse names indicating some obscure topic] with a standard
prefix indicating it's a "my" function.

Thanks for that.

I suppose what I am getting at is that most programs which stay around
for a long time have an underlying rational which works and unifies
effort around a good goal.
That is what I was looking for - does emacs have some underlying
philosophy I could find an entry to and develop to a new level my
interaction with emacs?

The thing is though - emacs as a working environment works well for me.
I am in emacs now, using gnus.
I will write email messages.
Likely do a bit of maths inline into some notes working out projects and
planning thought tasks.

I come from a positive place.

Best wishes all,
Rich Smith
Aidan Kehoe
2024-03-08 09:39:38 UTC
Permalink
[...] The thing is though - emacs as a working environment works well for
me. I am in emacs now, using gnus. I will write email messages. Likely do a
bit of maths inline into some notes working out projects and planning
thought tasks.
I come from a positive place.
Same here, I expect to continue to use XEmacs as long as I need to write email
and TeX, which, as a 42-year-old non-smoker in good health, will likely be
another 40 years or so. The point of a tool is to meet one’s needs, and it is
unusual to need perfection.
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)
Richard Smith
2024-03-08 14:02:13 UTC
Permalink
Post by Aidan Kehoe
[...] The thing is though - emacs as a working environment works well for
me. I am in emacs now, using gnus. I will write email messages. Likely do a
bit of maths inline into some notes working out projects and planning
thought tasks.
I come from a positive place.
Same here, I expect to continue to use XEmacs as long as I need to write email
and TeX, which, as a 42-year-old non-smoker in good health, will likely be
another 40 years or so. The point of a tool is to meet one’s needs, and it is
unusual to need perfection.
{thumbs-up}

Loading...