Re: (emacs) Intro [was: Making Emacs popular again with a video]

[excalamus--- via "Emacs development discussions." <emacs-devel@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4495 bytes --]


May 14, 2020, 20:46 by dgutov@yandex.ru:

> On your proposed text:
>
>  built from the idea that each key calls a tiny program (or macro)
> Keys don't call macros anymore (all commands must be functions, not macros). Seems like the meaning of the word "macro" has changed over the years.
>
My intent with this paragraph is to explain what "Emacs" is and what defines an "Emacs", at a high level.  Emacs stands for  "Editor MACroS" and the idea of explicitly associating a function with each key, as I see it, is the defining aspect of an Emacs.  I think the etymology is an appropriate starting place for explaining what "Emacs" is, especially since it is an unusual word, potentially confused with something like "email" or Apple's "mac" computer.  However, starting with the etymology restricts the author to using the term "macro" somewhere.  I agree that "function" is a better word.  But to Andreas Röhler's point, I'm trying to strike a balance between programmer and non-programmer.  I used "tiny program" instead of "function" for this reason.  I think a programmer is likely to get the gist of "tiny program" whereas a non-programmer would be confused by jargon like "function"  (Based on my convos with non-programmers, aka., my girlfriend). "macro" is bad, maybe worse, but etymologically unavoidable. I think the manual should cater to the non-programmer; let the Emacs Lisp reference cater to programmers.
So much for what Emacs is.  

What *defines* an Emacs? Is it "the Emacs idea", as I've called it, that each key press is transparently associated with a function?  Word or Gmail probably call a function on a keypress, but that's not exposed to the user like it is with Emacs.  (This is partly what I was asking about when I asked for Emacs' raison d'etre.)  Thoughts?

>  GNU Emacs is the GNU project's
>  incarnation of the Emacs idea.
>
> ...I'm not 100% sure what the idea is. Keys having bindings? I'll admit I might have missed that in the original text.
>
You're right that it's confusing; it's not well expressed and not a complete thought.  Here's what I'm trying to get at: there is *an* Emacs, a piece of software characterized by *something*, and there is *the* GNU Emacs.  Is Word an Emacs? No. Is Epoch an Emacs? Yes. Why is that? Further, there is Lucid Emacs, DrRacket, Multics Emacs, Gosling Emacs, etc.  GNU Emacs is only one *instance* of an Emacs.  What sets GNU Emacs apart, specifically? Is it just that it's currently the most active in development? Or, is there something more underpinning GNU Emacs' existence? Why is it we're talking about GNU Emacs and not any of the others? 

>  The documentation even reaches down to the source code
>  itself!
>
> What does this mean? Functions having docstrings? Which they do everywhere.
>
I mean the source code itself is documentation and that the user has easy acess to it.  Word has documentation, but no access to source code. Notepad++ is free sotware, but the source code is not easily accessed (relative to Emacs).  The immediate access to the source is, I feel, a key compenent of the self-documentation of Emacs and what puts it in that unique space between user and developer.
>  We love GNU Emacs because we
>  feel that no other editing environment rewards sustained user
>  investment quite like it.
>
> Personally, I don't love this sentiment. It implies that one must invest a lot of time to get something good out of it. I'd rather emphasize power, flexibility and interactivity rather than paint a picture of the user polishing his Emacs for decades. Which we do, but, well, a lot of professionals in different industries do this too with their industry-specific tools.
>
This is a good point. I think Karl Fogel nailed it when he said, "Emacs's best prospects are with the sorts of people who *do* see -- or who can be persuaded to see -- text editing as worthy of investment."  I think the only people who will make it far enough to read the manual are the sort of people who are willing to invest in their time *and* have decided to investigate.  It's important to let them know they will be rewarded for that and how.  The manual intro, I feel, is an appropriate place to do that.  I agree we should emphasize power, flexibility, and interactivity as a selling point, but that will/should have happened well before a user gets to the manual.  

Thank you for sharing your thoughts! I am interesting in hearing more of them!

[-- Attachment #2: Type: text/html, Size: 6405 bytes --]