How to make Emacs popular again.

How to make Emacs popular again.

[James Lu]

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

I am a new (2020 started) Emacs user.

Sell customer support packages, so 1) You can focus on gaining users =
giving more users computer user freedom and user empowerment. 2) You can
better understand the problems with Emacs' documentation and user interface
because people will email you support questions on them, incentivizing you
to reduce how many support queries are needed.
User experience testing. a la Don't Make Me Think by Steve Krug.
Path dependence-- sequence points matter.
https://kwokchain.com/2020/06/19/why-figma-wins/

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

Re: How to make Emacs popular again.

[Pankaj Jangid]

On Sat, Sep 26 2020, James Lu wrote:

> I am a new (2020 started) Emacs user.

This is evident from your email. Perhaps you should read about "the GNU
project"

> Sell customer support packages, so 1) You can focus on gaining users =
> giving more users computer user freedom and user empowerment. 2) You can
> better understand the problems with Emacs' documentation and user interface
> because people will email you support questions on them, incentivizing you
> to reduce how many support queries are needed.
> User experience testing. a la Don't Make Me Think by Steve Krug.
> Path dependence-- sequence points matter.
> https://kwokchain.com/2020/06/19/why-figma-wins/

Emacs Inc. ;-)

Re: How to make Emacs popular again.

[James Lu]

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

I have read several gnu.org articles.

On Sat, Sep 26, 2020 at 9:47 AM Pankaj Jangid <pankaj@codeisgreat.org>
wrote:

> On Sat, Sep 26 2020, James Lu wrote:
>
> > I am a new (2020 started) Emacs user.
>
> This is evident from your email. Perhaps you should read about "the GNU
> project"
>
> > Sell customer support packages, so 1) You can focus on gaining users =
> > giving more users computer user freedom and user empowerment. 2) You can
> > better understand the problems with Emacs' documentation and user
> interface
> > because people will email you support questions on them, incentivizing
> you
> > to reduce how many support queries are needed.
> > User experience testing. a la Don't Make Me Think by Steve Krug.
> > Path dependence-- sequence points matter.
> > https://kwokchain.com/2020/06/19/why-figma-wins/
>
> Emacs Inc. ;-)
>
>

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

Re: How to make Emacs popular again.

[Philip K.]

James Lu <jamtlu@gmail.com> writes:

> a la Don't Make Me Think by Steve Krug.

I'm not familiar with the book, but from from [0]

> The book's premise is that a good software program or web site should
> let users accomplish their intended tasks as easily and directly as
> possible.

I guess I agree, but it seems to be a truism. Nobody wants to make
software intentionally unusable, it's hard to imagine that people would
still be using Emacs after all this time if that were the case.

The question I see is should it be "Don't make me think" or "Don't make
me learn". I get the first one, but you limit yourself to what you
already know, if you want everything to already be familiar.

[0] https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think


-- 
	Philip K.

Re: How to make Emacs popular again.

[Ergus]

On Sat, Sep 26, 2020 at 03:59:53PM +0200, Philip K. wrote:
>
>James Lu <jamtlu@gmail.com> writes:
>
>> a la Don't Make Me Think by Steve Krug.
>
>I'm not familiar with the book, but from from [0]
>
>> The book's premise is that a good software program or web site should
>> let users accomplish their intended tasks as easily and directly as
>> possible.
>
>I guess I agree, but it seems to be a truism. Nobody wants to make
>software intentionally unusable, it's hard to imagine that people would
>still be using Emacs after all this time if that were the case.
>
>The question I see is should it be "Don't make me think" or "Don't make
>me learn". I get the first one, but you limit yourself to what you
>already know, if you want everything to already be familiar.
>
IMO it is indeed a mixture. A point in the middle that in emacs never
(or very rarely) reaches and agreement in favor of new users. At the end
someone always has to learn something either the old or new users...

On one side Emacs is extremely powerful and complex so it should be
expected some differences with other software, at the end every program
is at some point different to the others specially for the complex
tasks. In that case it makes sense that the new user have to learn how
to proceed.

BUT, on the other hand, it is true that Emacs makes some simple things
more complex/weird and keep them like that just because "it is the emacs
way" or "not to bother old users" or "we shouldn't do that just because
others do" or "our way is better just 90% more complex because it covers
this very weird and infrequent use case".

It is like a language evolution; with 1 or 2 differences it is fine; but
after many years with that policy the rest of the world evolves and only
the ancient people in the city will know your language while the younger
only learn it if they are forced to or have not choice.

Many things in emacs are indeed different because they were before; even
before the computer boom in the 90s; but then after the years everyone
adopted a different "standard" (due to Windows, Office, or even gnome
and KDE) and somehow we decided not to follow them. Again with one or
two details it is fine; but after some years... the differences pilled
up.

IMO it makes sense that a user reads a manual to know how to record a
macro, or replace all occurrences of a regex, or configure completions,
autopair, send email... But it is crazy (and pointless to discuss in
this mailing list) that a user has to learn how to copy and paste from
the keyboard or try to understand why there is not a right click panel
with the basic-common options, or why shift+click doesn't behave as it
does everywhere else...



>[0] https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think
>
>	Philip K.
>

Re: How to make Emacs popular again.

[Jean Louis]

* James Lu <jamtlu@gmail.com> [2020-09-26 16:40]:
> I am a new (2020 started) Emacs user.
> 
> Sell customer support packages, so

> 1) You can focus on gaining users giving more users computer user
> freedom and user empowerment.

I understand what you mean. That is right and valid for any
software. And I am sure you mean it for interaction with the software.

> 2) You can better understand the problems with Emacs' documentation
> and user interface

Major problem there are abbreviations, words, terms, that are easily
misunderstood by users which may cause rejections.

If I am faced with a Chinese menu and I do not speak Chinese,
obviously this will cause rejection and I will soonest possible stop
using such editor. For a Chinese person, that editor or piece of
software may become best thing they found and they may love it.

By introducing a lot of Chinese-like terminology, let us call it
simply potential misunderstoods, users are rejecting whatever they
have in front of them.

The remedy is already there, is it just not good enough. Good example
of remedy are tooltips. Example is what I have here on the mode line:

 -:**-

So that is where the misunderstoods start, with -:**- so that looks
like Chinese to me, even though I know what it means as experienced
Emacs user. But from a view point of empowering a user, I have no clue
how is that empowering me.

If I move the mouse point there to the first - I can see following
words inside of a tooltip:

Buffer coding system (multi-byte): undecided-unix
Mouse-1: describe coding system
Mouse-3: set coding system

So it is a tip, it should tell me some indications, but words are too
hard for new users, one could ask himself what really applies to that
definition of "buffer":

* Overview of noun buffer

The noun buffer has 7 senses (first 1 from tagged texts)
1. (8) buffer -- ((chemistry) an ionic compound that resists changes in its pH)
2. buffer zone, buffer -- (a neutral zone between two rival powers that is created in order to diminish the danger of conflict)
3. fender, buffer, cowcatcher, pilot -- (an inclined metal frame at the front of a locomotive to clear the track)
4. buffer, buffer storage, buffer store -- ((computer science) a part of RAM used for temporary storage of data that is waiting to be sent to a device; used to compensate for differences in the rate of flow of data between components of a computer system)
5. buffer, polisher -- (a power tool used to buff surfaces)
6. buffer, fender -- (a cushion-like device that reduces shock due to an impact)
7. buff, buffer -- (an implement consisting of soft material mounted on a block; used for polishing (as in manicuring))

So there are plenty of ways how new user can get misunderstoods. Do
not assume that such has a ready Wordnet dictionary to do
{M-x wordnut-search} like I do. They most probably don't have it.

A tooltip in Emacs user interface should have the option to be
"caught" or examined, that it does not disappear, so that now user can
click on words such as "buffer" and find out the definition of it,
that user can understand what means "coding" in the context of buffer
coding system, that user can understand what means "multi-byte", and
what does it mean UNIX and what does it mean "undecided-unix", as if
user does not know that, there is no reason or point to use the
Mouse-1 to describe the coding system, as it really does not describe
nothing to the user:

> - -- undecided-unix (alias: unix)

Why is it undecided?! It is unclear. Why is alias "unix"?! It is
unclear, why not call it unix?! Why is it alias? What is alias?
Consider my questions with !?  hypothetical questions that user could
be asking.

> No conversion on encoding, automatic conversion on decoding.

This sentence says nothing. It is clear to developer what it means,
but is unclear to average user.

Conversion of what?! It is not specified.

Encoding of what?! It is no specified.

What would mean "automatic conversion"?!

Decoding of what?!

> Type: undecided (do automatic conversion)

Who is undecided?! User or computer? If it is undecided why is it
automatic?!

> EOL type: LF

No definition for this if I do: "!define EOL" inside of
duckduckgo.com, I get this: https://www.thefreedictionary.com/EOL

For LF I am asking myself, is it left field or low frequency:
https://www.thefreedictionary.com/LF

Of course I do know what Line Feed means, but average beginner will
not know it.

And there is no recourse within Emacs to find out about it.

Thus to conclude my example here:

- Making Emacs friendlier will be easier with a built-in dictionary
  that will describe any terminology in easy English

- all tooltips, all words, should be describable and definable by
  clicking the mouse or choosing {M-x define-word} or similar
  function. Just all. I am talking about easy English description of
  Menus, it is analogous to {C-h k} to describe the menu, but in easy
  way, without confusing the user more and more.

Another practical example of nonsense within Emacs, but don't take me
for a negative critic, I like Emacs now so much more because of
nonsense descriptions, but look at this:

- I press {C-h k} and then choose Tools -> Search Files (Grep)...

Side comment: if it runs "grep" command, I don't know why it is
capitalized, but alright.

I wanted to find out about "Search Files..." so the menu option is
pretty clear, it helps me search files, but then description about
"Search files" does not even mention the word "search".

It mentions other things, like <menu-bar> I would not know why is it
so written, tools, grep, it does not help me understand what "grep"
means, I cannot find it in my Wordnet dictionary as definition, and
the the Duck is redirecting "!define grep" to Unix word, so I have no
option to understand what "grep" would mean, it is confusing me and I
am prone to reject it.

Look what I read as description of a "Search Files (Grep...)" option
menu:


> <menu-bar> <tools> <grep> runs the command grep (found in global-map),
> which is an autoloaded interactive compiled Lisp function in
> ‘grep.el’.

> It is bound to <menu-bar> <tools> <grep>.

> (grep COMMAND-ARGS)

>   Probably introduced at or before Emacs version 1.4.

> Run Grep with user-specified COMMAND-ARGS.
> The output from the command goes to the "*grep*" buffer.

> While Grep runs asynchronously, you can use C-x ` (M-x next-error),
> or RET in the *grep* buffer, to go to the lines where Grep found
> matches.  To kill the Grep job before it finishes, type C-c C-k.

> Noninteractively, COMMAND-ARGS should specify the Grep command-line
> arguments.

> For doing a recursive ‘grep’, see the ‘rgrep’ command.  For running
> Grep in a specific directory, see ‘lgrep’.

> This command uses a special history list for its COMMAND-ARGS, so you
> can easily repeat a grep command.

> A prefix argument says to default the COMMAND-ARGS based on the current
> tag the cursor is over, substituting it into the last Grep command
> in the Grep command history (or into ‘grep-command’ if that history
> list is empty).

> [back]

For a new user, only two things make sense there:

- The term "Search files", that is what makes sense

- within the description of menu option "Search files" the only thing
  that makes sense is [back] link

> because people will email you support questions on them,

Emacs should have a built in support question system, so that every
user can straight send a support question, and which would be answered
by using referenced or hyperlinked easy English, and such question
would be then automatically placed on some website, or integrated
into Emacs, so next users could then inquire answers in easier and
easier manner.

Jean

Re: How to make Emacs popular again.

[James Lu]

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

> Emacs should have a built in support question system, so that every
> user can straight send a support question, and which would be answered
> by using referenced or hyperlinked easy English, and such question
> would be then automatically placed on some website, or integrated
> into Emacs, so next users could then inquire answers in easier and
> easier manner.

When you're paid to answer boring and repetitive questions, and
you're expected to answer all of them, you have an economic
incentive to create good documentation people want to read
and is easy to find through.

On Sat, Sep 26, 2020 at 12:30 PM Jean Louis <bugs@rcdrun.com> wrote:

> * James Lu <jamtlu@gmail.com> [2020-09-26 16:40]:
> > I am a new (2020 started) Emacs user.
> >
> > Sell customer support packages, so
>
> > 1) You can focus on gaining users giving more users computer user
> > freedom and user empowerment.
>
> I understand what you mean. That is right and valid for any
> software. And I am sure you mean it for interaction with the software.
>
> > 2) You can better understand the problems with Emacs' documentation
> > and user interface
>
> Major problem there are abbreviations, words, terms, that are easily
> misunderstood by users which may cause rejections.
>
> If I am faced with a Chinese menu and I do not speak Chinese,
> obviously this will cause rejection and I will soonest possible stop
> using such editor. For a Chinese person, that editor or piece of
> software may become best thing they found and they may love it.
>
> By introducing a lot of Chinese-like terminology, let us call it
> simply potential misunderstoods, users are rejecting whatever they
> have in front of them.
>
> The remedy is already there, is it just not good enough. Good example
> of remedy are tooltips. Example is what I have here on the mode line:
>
>  -:**-
>
> So that is where the misunderstoods start, with -:**- so that looks
> like Chinese to me, even though I know what it means as experienced
> Emacs user. But from a view point of empowering a user, I have no clue
> how is that empowering me.
>
> If I move the mouse point there to the first - I can see following
> words inside of a tooltip:
>
> Buffer coding system (multi-byte): undecided-unix
> Mouse-1: describe coding system
> Mouse-3: set coding system
>
> So it is a tip, it should tell me some indications, but words are too
> hard for new users, one could ask himself what really applies to that
> definition of "buffer":
>
> * Overview of noun buffer
>
> The noun buffer has 7 senses (first 1 from tagged texts)
> 1. (8) buffer -- ((chemistry) an ionic compound that resists changes in
> its pH)
> 2. buffer zone, buffer -- (a neutral zone between two rival powers that is
> created in order to diminish the danger of conflict)
> 3. fender, buffer, cowcatcher, pilot -- (an inclined metal frame at the
> front of a locomotive to clear the track)
> 4. buffer, buffer storage, buffer store -- ((computer science) a part of
> RAM used for temporary storage of data that is waiting to be sent to a
> device; used to compensate for differences in the rate of flow of data
> between components of a computer system)
> 5. buffer, polisher -- (a power tool used to buff surfaces)
> 6. buffer, fender -- (a cushion-like device that reduces shock due to an
> impact)
> 7. buff, buffer -- (an implement consisting of soft material mounted on a
> block; used for polishing (as in manicuring))
>
> So there are plenty of ways how new user can get misunderstoods. Do
> not assume that such has a ready Wordnet dictionary to do
> {M-x wordnut-search} like I do. They most probably don't have it.
>
> A tooltip in Emacs user interface should have the option to be
> "caught" or examined, that it does not disappear, so that now user can
> click on words such as "buffer" and find out the definition of it,
> that user can understand what means "coding" in the context of buffer
> coding system, that user can understand what means "multi-byte", and
> what does it mean UNIX and what does it mean "undecided-unix", as if
> user does not know that, there is no reason or point to use the
> Mouse-1 to describe the coding system, as it really does not describe
> nothing to the user:
>
> > - -- undecided-unix (alias: unix)
>
> Why is it undecided?! It is unclear. Why is alias "unix"?! It is
> unclear, why not call it unix?! Why is it alias? What is alias?
> Consider my questions with !?  hypothetical questions that user could
> be asking.
>
> > No conversion on encoding, automatic conversion on decoding.
>
> This sentence says nothing. It is clear to developer what it means,
> but is unclear to average user.
>
> Conversion of what?! It is not specified.
>
> Encoding of what?! It is no specified.
>
> What would mean "automatic conversion"?!
>
> Decoding of what?!
>
> > Type: undecided (do automatic conversion)
>
> Who is undecided?! User or computer? If it is undecided why is it
> automatic?!
>
> > EOL type: LF
>
> No definition for this if I do: "!define EOL" inside of
> duckduckgo.com, I get this: https://www.thefreedictionary.com/EOL
>
> For LF I am asking myself, is it left field or low frequency:
> https://www.thefreedictionary.com/LF
>
> Of course I do know what Line Feed means, but average beginner will
> not know it.
>
> And there is no recourse within Emacs to find out about it.
>
> Thus to conclude my example here:
>
> - Making Emacs friendlier will be easier with a built-in dictionary
>   that will describe any terminology in easy English
>
> - all tooltips, all words, should be describable and definable by
>   clicking the mouse or choosing {M-x define-word} or similar
>   function. Just all. I am talking about easy English description of
>   Menus, it is analogous to {C-h k} to describe the menu, but in easy
>   way, without confusing the user more and more.
>
> Another practical example of nonsense within Emacs, but don't take me
> for a negative critic, I like Emacs now so much more because of
> nonsense descriptions, but look at this:
>
> - I press {C-h k} and then choose Tools -> Search Files (Grep)...
>
> Side comment: if it runs "grep" command, I don't know why it is
> capitalized, but alright.
>
> I wanted to find out about "Search Files..." so the menu option is
> pretty clear, it helps me search files, but then description about
> "Search files" does not even mention the word "search".
>
> It mentions other things, like <menu-bar> I would not know why is it
> so written, tools, grep, it does not help me understand what "grep"
> means, I cannot find it in my Wordnet dictionary as definition, and
> the the Duck is redirecting "!define grep" to Unix word, so I have no
> option to understand what "grep" would mean, it is confusing me and I
> am prone to reject it.
>
> Look what I read as description of a "Search Files (Grep...)" option
> menu:
>
>
> > <menu-bar> <tools> <grep> runs the command grep (found in global-map),
> > which is an autoloaded interactive compiled Lisp function in
> > ‘grep.el’.
>
> > It is bound to <menu-bar> <tools> <grep>.
>
> > (grep COMMAND-ARGS)
>
> >   Probably introduced at or before Emacs version 1.4.
>
> > Run Grep with user-specified COMMAND-ARGS.
> > The output from the command goes to the "*grep*" buffer.
>
> > While Grep runs asynchronously, you can use C-x ` (M-x next-error),
> > or RET in the *grep* buffer, to go to the lines where Grep found
> > matches.  To kill the Grep job before it finishes, type C-c C-k.
>
> > Noninteractively, COMMAND-ARGS should specify the Grep command-line
> > arguments.
>
> > For doing a recursive ‘grep’, see the ‘rgrep’ command.  For running
> > Grep in a specific directory, see ‘lgrep’.
>
> > This command uses a special history list for its COMMAND-ARGS, so you
> > can easily repeat a grep command.
>
> > A prefix argument says to default the COMMAND-ARGS based on the current
> > tag the cursor is over, substituting it into the last Grep command
> > in the Grep command history (or into ‘grep-command’ if that history
> > list is empty).
>
> > [back]
>
> For a new user, only two things make sense there:
>
> - The term "Search files", that is what makes sense
>
> - within the description of menu option "Search files" the only thing
>   that makes sense is [back] link
>
> > because people will email you support questions on them,
>
> Emacs should have a built in support question system, so that every
> user can straight send a support question, and which would be answered
> by using referenced or hyperlinked easy English, and such question
> would be then automatically placed on some website, or integrated
> into Emacs, so next users could then inquire answers in easier and
> easier manner.
>
> Jean
>

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

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Sat, 26 Sep 2020 19:30:08 +0300
> From: Jean Louis <bugs@rcdrun.com>
> Cc: emacs-devel@gnu.org
> 
> > - -- undecided-unix (alias: unix)
> 
> Why is it undecided?! It is unclear. Why is alias "unix"?! It is
> unclear, why not call it unix?! Why is it alias? What is alias?
> Consider my questions with !?  hypothetical questions that user could
> be asking.
> 
> > No conversion on encoding, automatic conversion on decoding.
> 
> This sentence says nothing. It is clear to developer what it means,
> but is unclear to average user.
> 
> Conversion of what?! It is not specified.
> 
> Encoding of what?! It is no specified.
> 
> What would mean "automatic conversion"?!
> 
> Decoding of what?!

You cannot learn this stuff by walking around the UI and reading the
tooltips.  It's unrealistic.  Those tooltips assume some minimal
knowledge of the terminology and the UI elements, which are described
in the tutorial and in the first chapter of the manual.  Making each
term a hyperlink that leads to its description, then each term in that
description a hyperlink, and so on and so forth, will in effect take
the user down a huge rabbit hole.  Users who need to actually do
something useful with their time, not just follow hyperlinks, will
very quickly lose patience and stop following.

> - Making Emacs friendlier will be easier with a built-in dictionary
>   that will describe any terminology in easy English

We already have that: the Glossary section of the manual.  But I don't
think taking the user there for each non-trivial word in our
documentation is a practical idea, or even a good one.

> - I press {C-h k} and then choose Tools -> Search Files (Grep)...
> 
> Side comment: if it runs "grep" command, I don't know why it is
> capitalized, but alright.
> 
> I wanted to find out about "Search Files..." so the menu option is
> pretty clear, it helps me search files, but then description about
> "Search files" does not even mention the word "search".

Unsurprisingly, the doc string assumes the user already knows what
Grep is.  So it doesn't say "search", because that's what Grep stands
for.

Doc strings are in generally terse; if you want more details,
including background etc, you need to read the description of the
commands in the user manual.  There's a 95-line section there about
M-x grep and related commands.

> Emacs should have a built in support question system, so that every
> user can straight send a support question, and which would be answered
> by using referenced or hyperlinked easy English, and such question
> would be then automatically placed on some website, or integrated
> into Emacs, so next users could then inquire answers in easier and
> easier manner.

I'm sure patches to provide such a system will be greatly appreciated,
when and if submitted.

Re: How to make Emacs popular again.

[Jean Louis]

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

* Ergus <spacibba@aol.com> [2020-09-26 17:54]:
> On one side Emacs is extremely powerful and complex so it should be
> expected some differences with other software

That is right. It is written in the Lisp programming language also
popular for applications of artificial intelligence. Under Help menu
there is psychoterapist, so I guess the joke with it can become
reality, as new users may feel so frustrated that the only thing is to
speak to artificial psychoterapist.

I am expecting Emacs to interact with user, to ask questions and give
answers and offer choice of answers and options as that is what
psychoterapis is also doing.

> BUT, on the other hand, it is true that Emacs makes some simple things
> more complex/weird and keep them like that just because "it is the emacs
> way" or "not to bother old users" or "we shouldn't do that just because
> others do" or "our way is better just 90% more complex because it covers
> this very weird and infrequent use case".

None of those reasons are valid.

Emacs developers are friendly and willing to improve Emacs, it is
process, takes time, and everybody is welcome.

In any subject of life, we want users to easier understand
instructions so that whatever is to be used, can be easier learned to
be used.

Emacs does great job there:

- Help menu is there

- Tutorials, FAQ, News and problems, sending bug reports, and if 
  nothing works, then psychoterapist, manuals, packages, jokes, all
  kinds of things

It is all there, it is self-describing editor.

While great work of description and instructions have been already
implemented, what is missing is a built-in dictionary of computing
and editing terminology used within Emacs and maybe even a Wordnet
dictionary.

> It is like a language evolution; with 1 or 2 differences it is fine; but
> after many years with that policy the rest of the world evolves and only
> the ancient people in the city will know your language while the younger
> only learn it if they are forced to or have not choice.

Myself I do not feel that attitude, quite contrary, I feel that users
and beginners are welcome and that many compromises are made and new
features are being implemented to help the new users.

It would be good to make a competition of Emacs Lisp authors to make
packages for beginners, so that a new "category" of packages, strike
the "category", that a new tag is made something like "beginner" so
that new packages are created to teach beginners various functions of
the editor.

Finally, you could also describe workflows how beginners could learn
more and propose it here.

> Many things in emacs are indeed different because they were before; even
> before the computer boom in the 90s; but then after the years everyone
> adopted a different "standard" (due to Windows, Office, or even gnome
> and KDE) and somehow we decided not to follow them. Again with one or
> two details it is fine; but after some years... the differences pilled
> up.

I do not see a problem with that, and it is too much of a general
statement.

Quite contrary, I can also see that Emacs bindings are included in
many other software:

https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx
https://support.rstudio.com/hc/en-us/articles/210928128-Emacs-Editor-Keybindings
https://github.com/p-baleine/jq.el
https://askubuntu.com/questions/124815/how-do-i-enable-emacs-keybindings-in-apps-such-as-google-chrome

So obviously many other software packages are following Emacs
keybindings, and Emacs is following and allowing any kind of key
bindings of other software.

It is not about key bindings only, Emacs is extensible, it was made
for the reason you want it, to be customized, extensible, so when
something is missing, please do: {M-x report-emacs-bug} and tell
developers about it, request a new feature.

> IMO it makes sense that a user reads a manual to know how to record a
> macro, or replace all occurrences of a regex, or configure completions,
> autopair, send email...

That is great really.

> But it is crazy (and pointless to discuss in this mailing list) that
> a user has to learn how to copy and paste from the keyboard or try

I thint it is point-full, and exactly those features you mentioned, I
would put in the spoken by espeak or other speech engine instruction
or within {M-x tell-me-more-I-am-beginner-mode}

> to understand why there is not a right click panel with the
> basic-common options, or why shift+click doesn't behave as it does
> everywhere else...

Those things are maybe becomming common, not that I know it is some
kind of standard, it is not I would say. In my opinion your
expectation is subjective based on what was familiar to you. 

I did use right click in many applications like on Desktop, Window
Managers, KDE, etc. But I never used it in Emacs, neither I expected
right click in Emacs to behave like you are expecting it. Due to my
experience with right click, I can understand easily what you
mean. Yet me subjective impression is that I never even used right
click in Emacs.

For some general function of Emacs to be implemented or changed, I
would always suggest to make a real user survey, as that way we avoid
subjective impressions.

You may easily put on right click what you wish. You expect that it
does something for new users, I don't and never did since 1999. Today
I learn that I can use left click to place a cursor at one side of a
text and right click to mark or highlight the region with the right
click. And if I do double click I am deleting the text by using
mouse. Good feature, but personally I never needed it. And I would not
need anything else on right click.

Jean

[-- Attachment #2: emacs-for-beginners.wav --]
[-- Type: audio/x-wav, Size: 71144 bytes --]

[-- Attachment #3: let-me-guide-you.wav --]
[-- Type: audio/x-wav, Size: 125230 bytes --]

[-- Attachment #4: would-you-like-to-learn-how-to-copy-text.wav --]
[-- Type: audio/x-wav, Size: 121516 bytes --]

Re: How to make Emacs popular again.

[Stefan Monnier]

> I am a new (2020 started) Emacs user.
> Sell customer support packages,

Might be a good idea, indeed.

I'm personally not interested in selling such support (I'm too happy
contributing to Emacs only when I feel like it), but if other people
want to, they're very welcome to do so.

I do expect that they'd suffer from the same problems as configs like
Spacemacs and friends in that it would be difficult for them to get
their changes into Emacs because they would inevitably work within
a very different context (e.g. their clients wouldn't be Emacs
old-timers).


        Stefan

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-26 19:55]:
> You cannot learn this stuff by walking around the UI and reading the
> tooltips.  It's unrealistic.  Those tooltips assume some minimal
> knowledge of the terminology and the UI elements, which are described
> in the tutorial and in the first chapter of the manual.

It is your opinion.

I tried finding what should undecided-unix mean, and I cannot find, I
just found that "unix" is alias for "undecided-unix".

Does the tooltip assume that only experienced user, in this case,
experienced developer is to know what it means?!

You say that it is described in the tutorial and in the first chapter
of the manual, and I gave you example with one term "undecided-unix"
and it is not described or defined. It could be defined in the source
code, but tooltip should not be written with such assumptions, tooltip
should help the user understand what is it.

In general tooltips are good. I just say there is space for improvement.

> Making each term a hyperlink that leads to its description, then
> each term in that description a hyperlink, and so on and so forth,
> will in effect take the user down a huge rabbit hole.

Is not that complex, maybe you should try wordnut package, I am using
it all the time. I can find definition of the word "time" and I am
facing new split buffer and if there is other word I do not
understand, I can enter into its definition, and come back with "l" or
quit, so it is very easy to provide a system of defining terms, they
need not be underlined or highlighted as words. I think every term
should be reachable from Emacs, as defining and helping users define
and clear the meanings of words is what is making users understand the
Emacs. 

> Users who need to actually do something useful with their time, not
> just follow hyperlinks, will very quickly lose patience and stop
> following.

I just have a feeling you got that opinion too subjectively. In my
opinion, every word should be reachable, so that user can understand
everything, that was already principle of Emacs, that is why there is
{C-h k} or other describe functions. It just needs better
interactivity with users and improvements.

> > - Making Emacs friendlier will be easier with a built-in dictionary
> >   that will describe any terminology in easy English
> 
> We already have that: the Glossary section of the manual.  But I don't
> think taking the user there for each non-trivial word in our
> documentation is a practical idea, or even a good one.

If user cannot understand the word, then cannot understand the
sentence, so how it can be good to bring users to misunderstandings? I
don't get the logic.

What is good is to bring users to understanding.

> > - I press {C-h k} and then choose Tools -> Search Files (Grep)...
> > 
> > Side comment: if it runs "grep" command, I don't know why it is
> > capitalized, but alright.
> > 
> > I wanted to find out about "Search Files..." so the menu option is
> > pretty clear, it helps me search files, but then description about
> > "Search files" does not even mention the word "search".
> 
> Unsurprisingly, the doc string assumes the user already knows what
> Grep is.  So it doesn't say "search", because that's what Grep stands
> for.

From the new user viewpoint I cannot possibly agree with that
explanation. Descriptions of menus should be accessible and
understandable for users especially from a new user viewpoint.

> Doc strings are in generally terse; if you want more details,
> including background etc, you need to read the description of the
> commands in the user manual.  There's a 95-line section there about
> M-x grep and related commands.

I am not speaking of myself Eli. I am speaking of new user viewpoint.

Even "Search files..." is not well described. You cannot possibly
design any interface for new user with experienced user viewpoint.

The "Search files" with grep would actually mean to search the files
containing certain term.

But for new user, "Search files" would probably mean to find those
files named "Alice-Homework.txt" or something like that.

It is good for developers to think more from a new user viewpoint.

Within Gnome, if you wish to find files, you open some find file
dialogue and you type file names and if it is using grep or not, why
it does matter? It does not matter for new user, as person wants to
use "Search files".

We speak here more of principles of design of the interface and
descriptions. Practical implementations may come later.

Jean

Re: How to make Emacs popular again.

[Dmitry Gutov]

On 26.09.2020 19:51, James Lu wrote:
>  > Emacs should have a built in support question system, so that every
>> user can straight send a support question, and which would be answered
>> by using referenced or hyperlinked easy English, and such question
>> would be then automatically placed on some website, or integrated
>> into Emacs, so next users could then inquire answers in easier and
>> easier manner.
> 
> When you're paid to answer boring and repetitive questions, and
> you're expected to answer all of them, you have an economic
> incentive to create good documentation people want to read
> and is easy to find through.

And even a personal incentive: nobody likes to answer the same questions 
again and again.

But it would have to be an official GNU initiative. Probably done by the 
one of the current Emacs maintainers, or some other people who still 
have the authority to make significant changes in Emacs.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Sat, 26 Sep 2020 20:36:51 +0300
> From: Jean Louis <bugs@rcdrun.com>
> Cc: jamtlu@gmail.com, emacs-devel@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2020-09-26 19:55]:
> > You cannot learn this stuff by walking around the UI and reading the
> > tooltips.  It's unrealistic.  Those tooltips assume some minimal
> > knowledge of the terminology and the UI elements, which are described
> > in the tutorial and in the first chapter of the manual.
> 
> It is your opinion.

Each one of us expresses his or her own opinions.  It's a trivium.

> I tried finding what should undecided-unix mean, and I cannot find, I
> just found that "unix" is alias for "undecided-unix".

Type "C-h i m emacs RET i undecided RET", and read there.

> Does the tooltip assume that only experienced user, in this case,
> experienced developer is to know what it means?!

Not "experienced", but one who have read some minimal introductory
material about the Emacs UI, and/or have learned how to use the manual
to search for (as yet) unknown concepts.

> You say that it is described in the tutorial and in the first chapter
> of the manual, and I gave you example with one term "undecided-unix"
> and it is not described or defined.

The tutorial describes the main parts of the mode-line display.  The
section "Mode Line", which is the 3rd section of the 1st chapter of
the manual, describes the mode line in more detail, including the
"coding-system" parts.

> It could be defined in the source code, but tooltip should not be
> written with such assumptions

It isn't.

> tooltip should help the user understand what is it.

It does.  It just doesn't (and cannot) explain everything, because a
tooltip is a small widget which cannot display a very long text, and
because clicking on the text in a tooltip is impossible, at least in
some/most toolkits we use.

> In general tooltips are good. I just say there is space for improvement.

There's always space for improvement, and practical suggestions for
improvements are welcome.  Such practical suggestions need to
recognize and observe the limitations of a tooltip, as well as the
limitations of the attention span of a typical user -- especially a
newcomer, because newcomers frequently come to Emacs to do some
relatively small job, and cannot invest long hours in following
hyperlinks.

> > Making each term a hyperlink that leads to its description, then
> > each term in that description a hyperlink, and so on and so forth,
> > will in effect take the user down a huge rabbit hole.
> 
> Is not that complex, maybe you should try wordnut package

I never said it was complex.  You are missing my point.

> > Users who need to actually do something useful with their time, not
> > just follow hyperlinks, will very quickly lose patience and stop
> > following.
> 
> I just have a feeling you got that opinion too subjectively. In my
> opinion, every word should be reachable

So we disagree.  That's fine.  Others can read your opinion and mine,
and make up their own minds.  Let's see how they respond to these
ideas.

> > We already have that: the Glossary section of the manual.  But I don't
> > think taking the user there for each non-trivial word in our
> > documentation is a practical idea, or even a good one.
> 
> If user cannot understand the word, then cannot understand the
> sentence, so how it can be good to bring users to misunderstandings? I
> don't get the logic.

The logic is that when they find some term that is not clear, and the
text there doesn't have a hyperlink to where that term is described in
more detail (there usually is), then the user should go to the
Glossary and search the term there.

> > > I wanted to find out about "Search Files..." so the menu option is
> > > pretty clear, it helps me search files, but then description about
> > > "Search files" does not even mention the word "search".
> > 
> > Unsurprisingly, the doc string assumes the user already knows what
> > Grep is.  So it doesn't say "search", because that's what Grep stands
> > for.
> 
> >From the new user viewpoint I cannot possibly agree with that
> explanation. Descriptions of menus should be accessible and
> understandable for users especially from a new user viewpoint.

Once again, there are limitations of what can be usefully said in a
short menu entry and its tooltip.  If you have practical suggestions
for how to use up the available screen estate better in that case,
please propose how to improve the wording we have there.

> > Doc strings are in generally terse; if you want more details,
> > including background etc, you need to read the description of the
> > commands in the user manual.  There's a 95-line section there about
> > M-x grep and related commands.
> 
> I am not speaking of myself Eli. I am speaking of new user viewpoint.

So am I.

> Even "Search files..." is not well described. You cannot possibly
> design any interface for new user with experienced user viewpoint.

Once again, the menus assume a certain level of understanding and
expectations.  You are claiming that those assumptions are incorrect,
but the solutions you propose are simply not practical, as they ignore
the basic limitations of the screen estate we have for this, and would
make the doc strings impractically verbose and full of loosely-related
background information.  Our policy is to leave the extra information
for the manual.

> The "Search files" with grep would actually mean to search the files
> containing certain term.

The tooltip for that menu item says:

  Search files for strings or regexps (with Grep)

which is basically what you say above.

> But for new user, "Search files" would probably mean to find those
> files named "Alice-Homework.txt" or something like that.

See above.

> It is good for developers to think more from a new user viewpoint.

Agreed.  We do.

> We speak here more of principles of design of the interface and
> descriptions. Practical implementations may come later.

Emacs already does have the practical implementations.  They are
well-thought and are being constantly improved.  There's no need to
start from scratch, as what we have already is a reasonably good and
newbie-friendly UI.  It is newbie-friendly because the Emacs
developers of past and present invest a lot of efforts into making it
so.

Re: How to make Emacs popular again.

[Dmitry Gutov]

On 26.09.2020 17:53, Ergus wrote:

> BUT, on the other hand, it is true that Emacs makes some simple things
> more complex/weird and keep them like that just because "it is the emacs
> way" or "not to bother old users" or "we shouldn't do that just because
> others do" or "our way is better just 90% more complex because it covers
> this very weird and infrequent use case".

Very much yes.

It's very discouraging to see the constant push-back against even the 
small and reasonable changes.

It feels like everybody who is not content with Emacs remaining a fringe 
quirky editor simply has to leave (*), sooner or later. And thus the 
development team self-selects in favor of individuals who don't care 
much about the programs around Emacs (and being at least somewhat 
compatible with them in the UI), or general usability concerns.

(*) The core development, at least. Or they go and create their own 
sub-community (like "starter packs", or the lsp-mode project), 
contributing very little outside of it because of the much higher 
friction that entails.

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-26 21:12]:
> > Date: Sat, 26 Sep 2020 20:36:51 +0300
> > From: Jean Louis <bugs@rcdrun.com>
> > Cc: jamtlu@gmail.com, emacs-devel@gnu.org
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2020-09-26 19:55]:
> > > You cannot learn this stuff by walking around the UI and reading the
> > > tooltips.  It's unrealistic.  Those tooltips assume some minimal
> > > knowledge of the terminology and the UI elements, which are described
> > > in the tutorial and in the first chapter of the manual.
> > 
> > It is your opinion.
> 
> Each one of us expresses his or her own opinions.  It's a trivium.

Sure, but we talk about users, so to say that one cannot learn the
stuff in general, should be supported by some kind of a survey. The
fact is right now is that not every tooltip is usable, so fact is now
in present time, that in my particular example, I cannot learn several
words.

So it will happen to new user to get confused. Users expect tooltips
to describe the function, and description shall be made better
understandable. 

> > I tried finding what should undecided-unix mean, and I cannot find, I
> > just found that "unix" is alias for "undecided-unix".
> 
> Type "C-h i m emacs RET i undecided RET", and read there.

I did not find the definition for undecided-unix by following your
example. That it is alias, does not define it.

> > Does the tooltip assume that only experienced user, in this case,
> > experienced developer is to know what it means?!
> 
> Not "experienced", but one who have read some minimal introductory
> material about the Emacs UI, and/or have learned how to use the manual
> to search for (as yet) unknown concepts.

For that group of people I disagree they need any tooltip
then. Tooltip is for users to understand it, it is not for Emacs UI
skilled people. It is for unskilled.

> > tooltip should help the user understand what is it.
> 
> It does.  It just doesn't (and cannot) explain everything, because a
> tooltip is a small widget which cannot display a very long text, and
> because clicking on the text in a tooltip is impossible, at least in
> some/most toolkits we use.

The point is not one tooltip, there are many examples, yet it is hard
for you to see what I see, and what could be obvious to many, that is
why few threads have been spawned here.

In marketing, I always learn to look from client's viewpoint. 

> > If user cannot understand the word, then cannot understand the
> > sentence, so how it can be good to bring users to misunderstandings? I
> > don't get the logic.
> 
> The logic is that when they find some term that is not clear, and the
> text there doesn't have a hyperlink to where that term is described in
> more detail (there usually is), then the user should go to the
> Glossary and search the term there.

Sure, you know it. But does it say anywhere? Does it guide the user?

Emacs as Lisp have all the capacities to guide the user. It has the
capacity to provide a humorous psychoterapist, so it can also guide a
user in better way.

> > > > I wanted to find out about "Search Files..." so the menu option is
> > > > pretty clear, it helps me search files, but then description about
> > > > "Search files" does not even mention the word "search".
> > > 
> > > Unsurprisingly, the doc string assumes the user already knows what
> > > Grep is.  So it doesn't say "search", because that's what Grep stands
> > > for.
> > 
> > >From the new user viewpoint I cannot possibly agree with that
> > explanation. Descriptions of menus should be accessible and
> > understandable for users especially from a new user viewpoint.
> 
> Once again, there are limitations of what can be usefully said in a
> short menu entry and its tooltip.  If you have practical suggestions
> for how to use up the available screen estate better in that case,
> please propose how to improve the wording we have there.

I think that general principles shall be set first, as to improve
wording, there are so many that could be improved, the descriptions
should not be written in first place that do not describe it
meaningfully. So I do not speak of a specific bug, I speak of general
flaws hindering understanding for users.

> > > Doc strings are in generally terse; if you want more details,
> > > including background etc, you need to read the description of the
> > > commands in the user manual.  There's a 95-line section there about
> > > M-x grep and related commands.
> > 
> > I am not speaking of myself Eli. I am speaking of new user viewpoint.
> 
> So am I.

Alright, then your viewpoint for new users is way advanced. You are
targeting various groups, not only Unix hackers or experienced users
or UI skilled users.

> > Even "Search files..." is not well described. You cannot possibly
> > design any interface for new user with experienced user viewpoint.
> 
> Once again, the menus assume a certain level of understanding and
> expectations.  You are claiming that those assumptions are incorrect,
> but the solutions you propose are simply not practical, as they ignore
> the basic limitations of the screen estate we have for this, and would
> make the doc strings impractically verbose and full of loosely-related
> background information.  Our policy is to leave the extra information
> for the manual.

The doc string, if it is taken out of it, that relates to Search
files, should be more descriptive.

From grep manual:

       grep searches the named input FILEs for lines containing a match to the
       given PATTERN.  If no files are specified, or if the file “-” is given,
       grep  searches  standard  input.   By default, grep prints the matching
       lines.

So something like:

Search files (Grep...) is using the external shell command "grep" that
searches the named input files for lines containing a match to the
given pattern.

That would be in this particular example much better described then:

> <menu-bar> <tools> <grep> runs the command grep (found in global-map),
> which is an autoloaded interactive compiled Lisp function in
> ‘grep.el’.

> It is bound to <menu-bar> <tools> <grep>.

> (grep COMMAND-ARGS)

>   Probably introduced at or before Emacs version 1.4.

> Run Grep with user-specified COMMAND-ARGS.
> The output from the command goes to the "*grep*" buffer.

> While Grep runs asynchronously, you can use C-x ` (M-x next-error),
> or RET in the *grep* buffer, to go to the lines where Grep found
> matches.  To kill the Grep job before it finishes, type C-c C-k.

> > We speak here more of principles of design of the interface and
> > descriptions. Practical implementations may come later.
> 
> Emacs already does have the practical implementations.  They are
> well-thought and are being constantly improved.  There's no need to
> start from scratch, as what we have already is a reasonably good and
> newbie-friendly UI.  It is newbie-friendly because the Emacs
> developers of past and present invest a lot of efforts into making it
> so.

I don't say from scratch, many things are already there, descriptions,
Info, docstring, I just speak of better connectivity to instructions
and to information and improvement of those sentences that appear not
understandable to average computer users, with the purpose to bring it
to more users in the world.

Myself personally, I like it how it is, but to draw new users, it has
to become fancier, easier, moderner, use any attribute here, the point
is that it does need that group of improvements that will attract
larger users' base, and not have them reject it.

It is good to read what some people are writing here:
https://news.ycombinator.com/item?id=24593616&p=2 so read those
comments and see.

Jean

RE: How to make Emacs popular again.

[Drew Adams]

> In marketing, I always learn to look from client's viewpoint.

Client/customer != user.

Marketing is about, well, marketing: selling.  Marketing is interested in customers, including helping them.

Customers are not the same as users, even when they might be the same people.  An athlete is not the same thing as an astronaut, even when the same person might be both.

A user point of view is about the use of something.  A marketing point of view is about the sale of something (a commodity), or keeping existing customers (selling again).

There's overlap, and some users also buy some of the products they use.  But use value and exchange value are not the same thing, and customer and user are not the same thing.

RE: How to make Emacs popular again.

[Drew Adams]

> Good example of remedy are tooltips. Example is what
> I have here on the mode line:
> 
>  -:**-
> 
> So that is where the misunderstoods start, with -:**- so that looks
> like Chinese to me, even though I know what it means as experienced
> Emacs user. But from a view point of empowering a user, I have no clue
> how is that empowering me.
> 
> If I move the mouse point there to the first - I can see following
> words inside of a tooltip:
> 
> Buffer coding system (multi-byte): undecided-unix
> Mouse-1: describe coding system
> Mouse-3: set coding system

+1 for finding the tool-tip.  And +1 to Emacs for
providing it.

> So it is a tip, it should tell me some indications, but words are too
> hard for new users, one could ask himself what really applies to that
> definition of "buffer":
> 
> * Overview of noun buffer

Then you list 7 meanings of the English word "buffer",
from some dictionary.  Nope; not the best way to go.

Menu bar `Help' > `Search Documentation' > `Emacs
Terminology' tells you:

 Buffer
  The buffer is the basic editing unit; one buffer
  corresponds to one text being edited.  You normally
  have several buffers, but at any time you are editing
  only one, the current buffer, though several can be
  visible when you are using multiple windows or frames
  (q.v.).  Most buffers are visiting (q.v.) some file.
  *Note Buffers::.

(It ends with a link to node `Buffers' in the manual.)

But yes, Emacs should do more, to make its glossary
more readily available.  (And it maybe shouldn't use
"q.v.".)  `M-x report-emacs-bug' to suggest glossary
changes.  And thanks for taking an interest in Emacs
help/doc.

> So there are plenty of ways how new user can get misunderstoods. Do
> not assume that such has a ready Wordnet dictionary to do
> {M-x wordnut-search} like I do. They most probably don't have it.

You shouldn't need any access to a dictionary here.

What Emacs needs to do a better job of is advising
you to "Ask Emacs", and telling you _how_ to "Ask
Emacs".

Looking up "buffer" in a dictionary is nowhere near
as helpful as asking Emacs what _Emacs_ means by
"buffer".  At least it shouldn't be.  Emacs should
be the go-to place to ask about Emacs.  At your
fingertips, with a good help system.

But a new user isn't very likely to know this.
And a new user isn't very likely to know _how_
to ask Emacs what "buffer" means.  And yet Emacs
is ready, willing, and able to answer the question.

> A tooltip in Emacs user interface should have the option to be
> "caught" or examined, that it does not disappear, so that now user can
> click on words such as "buffer" and find out the definition of it,
> that user can understand what means "coding" in the context of buffer
> coding system, that user can understand what means "multi-byte", and
> what does it mean UNIX and what does it mean "undecided-unix", as if
> user does not know that, 

Agreed, direct bridges from short help/feedback
to more complete help would be welcome additions.

Emacs has good user help.  But yes, there's room
for improvement.

> - Making Emacs friendlier will be easier with a built-in dictionary
>   that will describe any terminology in easy English

Emacs has a glossary - see above.  It could no
doubt be improved.  Suggestions welcome (`M-x
report-emacs-bug').

> - all tooltips, all words, should be describable and definable by
>   clicking the mouse or choosing {M-x define-word} or similar
>   function. Just all. I am talking about easy English description of
>   Menus, it is analogous to {C-h k} to describe the menu, but in easy
>   way, without confusing the user more and more.

Agreed, though some of that might be easier said
than done.  You can't click a mouseover tooltip,
for example.  But you can click a link in a *Help*
window.

In `help+.el' I define command `help-on-click/key',
bound to `C-h RET' and `C-h mouse-1'.  And library
`menu-bar+.el' adds it to menu `Help' > `Describe'
as item `This'.

This command doesn't work for everything, but it's
usable many places.  It prompts you to click something,
hit a key, or choose a menu item, and it tells you
about the thing you click or the key/menu you choose.

,----
| help-on-click/key is an interactive Lisp function in ‘help+.el’.
| 
| It is bound to C-h RET, f1 RET, help RET, menu-bar help-menu describe
| help-on-click/key.
| 
| (help-on-click/key KEY)
| 
| Give help on a key/menu sequence or object clicked with the mouse.
| The object can be any part of an Emacs window or a name appearing in a
| buffer.  You can do any of the following:
| 
|     type a key sequence (e.g. `C-M-s')
|     choose a menu item (e.g. [menu-bar files open-file])
|     click on a scroll bar
|     click on the mode line
|     click in the minibuffer
|     click on an Emacs-related name in a buffer: apropos is called
|     click anywhere else in a buffer: its modes are described
| 
| Help is generally provided using `describe-key' and the Emacs online
| manual (via `Info-goto-emacs-key-command-node').  If no entry is found
| in the index of the Emacs manual, then the manual is searched from the
| beginning for literal occurrences of KEY.
| 
| If you click on a name in a buffer, then `apropos-documentation' and
| `apropos' are used to find information on the name.  These functions
| are not used when you do something besides click on a name.
| 
| If you click elsewhere in a buffer other than the minibuffer, then
| `describe-mode' is used to describe the buffer's current mode(s).
`----

It's a start, but Emacs could offer more such help.
`help+.el' has been around since 2007.

______

`help+.el':
https://www.emacswiki.org/emacs/download/help%2b.el

About Help+ libraries:
https://www.emacswiki.org/emacs/HelpPlus

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Sat, 26 Sep 2020 21:58:24 +0300
> From: Jean Louis <bugs@rcdrun.com>
> Cc: jamtlu@gmail.com, emacs-devel@gnu.org
> 
> > > It is your opinion.
> > 
> > Each one of us expresses his or her own opinions.  It's a trivium.
> 
> Sure, but we talk about users, so to say that one cannot learn the
> stuff in general, should be supported by some kind of a survey.

Same is true for your opinions.

> The fact is right now is that not every tooltip is usable

"Not usable" in your opinion.  I disagree.

> So it will happen to new user to get confused. Users expect tooltips
> to describe the function, and description shall be made better
> understandable. 

You (and anyone else) are welcome to suggest improvements.  But the
fact that there's place for improvement doesn't yet mean that what we
have is unusable or confusing.

> > > I tried finding what should undecided-unix mean, and I cannot find, I
> > > just found that "unix" is alias for "undecided-unix".
> > 
> > Type "C-h i m emacs RET i undecided RET", and read there.
> 
> I did not find the definition for undecided-unix by following your
> example. That it is alias, does not define it.

I don't think I understand why.  Quote:

     The coding systems ‘unix’, ‘dos’, and ‘mac’ are aliases for
  ‘undecided-unix’, ‘undecided-dos’, and ‘undecided-mac’, respectively.
  These coding systems specify only the end-of-line conversion, and leave
  the character code conversion to be deduced from the text itself.

(The previous text explains what is "end-of-line conversion".)

> > Not "experienced", but one who have read some minimal introductory
> > material about the Emacs UI, and/or have learned how to use the manual
> > to search for (as yet) unknown concepts.
> 
> For that group of people I disagree they need any tooltip
> then. Tooltip is for users to understand it, it is not for Emacs UI
> skilled people. It is for unskilled.

I didn't say "skilled".  Users aren't divided into those who know
nothing and those who are "skilled".  There are many degrees of gray
in between.

> > The logic is that when they find some term that is not clear, and the
> > text there doesn't have a hyperlink to where that term is described in
> > more detail (there usually is), then the user should go to the
> > Glossary and search the term there.
> 
> Sure, you know it. But does it say anywhere? Does it guide the user?

Having a glossary is one of the basic traits of any serious
publication.  Not unlike having a TOC.  I expect readers to know about
that and actively search for it.

> > Once again, there are limitations of what can be usefully said in a
> > short menu entry and its tooltip.  If you have practical suggestions
> > for how to use up the available screen estate better in that case,
> > please propose how to improve the wording we have there.
> 
> I think that general principles shall be set first, as to improve
> wording, there are so many that could be improved, the descriptions
> should not be written in first place that do not describe it
> meaningfully. So I do not speak of a specific bug, I speak of general
> flaws hindering understanding for users.

There are no "general flaws" in this context.  These aspects of Emacs
documentation and UI were worked on for many years by many talented
people.  So any flaws are likely specific and not general.

In any case, speaking about "general flaws" without any concrete
details and concrete proposals for specific menu items or tooltips is
not a very useful investment of our time.  So if this is what you
intend to talk about, I'm afraid I won't be able to continue
participating in this thread.

> > > I am not speaking of myself Eli. I am speaking of new user viewpoint.
> > 
> > So am I.
> 
> Alright, then your viewpoint for new users is way advanced.

Your words.  I disagree.

> So something like:
> 
> Search files (Grep...) is using the external shell command "grep" that
> searches the named input files for lines containing a match to the
> given pattern.

That is basically what the tooltip already says.

Re: How to make Emacs popular again.

[James Lu]

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

Go to a conference. Find some random person. You want a representative
sample.
Pay them to try Emacs.
Then watch them use Emacs.


https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

On Sat, Sep 26, 2020 at 3:28 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 26 Sep 2020 21:58:24 +0300
> > From: Jean Louis <bugs@rcdrun.com>
> > Cc: jamtlu@gmail.com, emacs-devel@gnu.org
> >
> > > > It is your opinion.
> > >
> > > Each one of us expresses his or her own opinions.  It's a trivium.
> >
> > Sure, but we talk about users, so to say that one cannot learn the
> > stuff in general, should be supported by some kind of a survey.
>
> Same is true for your opinions.
>
> > The fact is right now is that not every tooltip is usable
>
> "Not usable" in your opinion.  I disagree.
>
> > So it will happen to new user to get confused. Users expect tooltips
> > to describe the function, and description shall be made better
> > understandable.
>
> You (and anyone else) are welcome to suggest improvements.  But the
> fact that there's place for improvement doesn't yet mean that what we
> have is unusable or confusing.
>
> > > > I tried finding what should undecided-unix mean, and I cannot find, I
> > > > just found that "unix" is alias for "undecided-unix".
> > >
> > > Type "C-h i m emacs RET i undecided RET", and read there.
> >
> > I did not find the definition for undecided-unix by following your
> > example. That it is alias, does not define it.
>
> I don't think I understand why.  Quote:
>
>      The coding systems ‘unix’, ‘dos’, and ‘mac’ are aliases for
>   ‘undecided-unix’, ‘undecided-dos’, and ‘undecided-mac’, respectively.
>   These coding systems specify only the end-of-line conversion, and leave
>   the character code conversion to be deduced from the text itself.
>
> (The previous text explains what is "end-of-line conversion".)
>
> > > Not "experienced", but one who have read some minimal introductory
> > > material about the Emacs UI, and/or have learned how to use the manual
> > > to search for (as yet) unknown concepts.
> >
> > For that group of people I disagree they need any tooltip
> > then. Tooltip is for users to understand it, it is not for Emacs UI
> > skilled people. It is for unskilled.
>
> I didn't say "skilled".  Users aren't divided into those who know
> nothing and those who are "skilled".  There are many degrees of gray
> in between.
>
> > > The logic is that when they find some term that is not clear, and the
> > > text there doesn't have a hyperlink to where that term is described in
> > > more detail (there usually is), then the user should go to the
> > > Glossary and search the term there.
> >
> > Sure, you know it. But does it say anywhere? Does it guide the user?
>
> Having a glossary is one of the basic traits of any serious
> publication.  Not unlike having a TOC.  I expect readers to know about
> that and actively search for it.
>
> > > Once again, there are limitations of what can be usefully said in a
> > > short menu entry and its tooltip.  If you have practical suggestions
> > > for how to use up the available screen estate better in that case,
> > > please propose how to improve the wording we have there.
> >
> > I think that general principles shall be set first, as to improve
> > wording, there are so many that could be improved, the descriptions
> > should not be written in first place that do not describe it
> > meaningfully. So I do not speak of a specific bug, I speak of general
> > flaws hindering understanding for users.
>
> There are no "general flaws" in this context.  These aspects of Emacs
> documentation and UI were worked on for many years by many talented
> people.  So any flaws are likely specific and not general.
>
> In any case, speaking about "general flaws" without any concrete
> details and concrete proposals for specific menu items or tooltips is
> not a very useful investment of our time.  So if this is what you
> intend to talk about, I'm afraid I won't be able to continue
> participating in this thread.
>
> > > > I am not speaking of myself Eli. I am speaking of new user viewpoint.
> > >
> > > So am I.
> >
> > Alright, then your viewpoint for new users is way advanced.
>
> Your words.  I disagree.
>
> > So something like:
> >
> > Search files (Grep...) is using the external shell command "grep" that
> > searches the named input files for lines containing a match to the
> > given pattern.
>
> That is basically what the tooltip already says.
>

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

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Major problem there are abbreviations, words, terms, that are easily
  > misunderstood by users which may cause rejections.

We can't do anything about this as a general issue.
We can change specific terms, at least in principle -- though
it can be a big hassle and doing it gently can take years.

So how about proposing, one at a time, a few changes.

  >  Example is what I have here on the mode line:

  >  -:**-

  > So that is where the misunderstoods start, with -:**- so that looks
  > like Chinese to me, even though I know what it means as experienced
  > Emacs user. But from a view point of empowering a user, I have no clue
  > how is that empowering me.

The information encoded there is very useful, so providing it
clearly does "empower the user".

Of course, there are many possible ways to present that info.

Is there a specific change you would suggest, in how to present it?
And why would it be better?

  > If I move the mouse point there to the first - I can see following
  > words inside of a tooltip:

  > Buffer coding system (multi-byte): undecided-unix
  > Mouse-1: describe coding system
  > Mouse-3: set coding system

We can easily change this.  However, a tooltip can't be very long.
Would you like to make a concrete proposal?



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

tooltip feature

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > A tooltip in Emacs user interface should have the option to be
  > "caught" or examined, that it does not disappear,

That is a good idea.  Is there a natural interface for commanding
this?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's very discouraging to see the constant push-back against even the 
  > small and reasonable changes.

We do adopt some such changes.

Arguing about people's general nature is useless.
You can't convince anyone about a general characeristic
and arguing trnds to offend.

Please focus on a specific proposal you want to try to advance.
We can work on it until we reach a form that is ok to adopt.
That is how progress is made.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Does the tooltip assume that only experienced user, in this case,
  > experienced developer is to know what it means?!

That particular tooltip is detailed data for an experienced user.
It explains the meaning of the specific character that the mouse is on.
It does not give general info for a beginnin user
about the purpose of displaying that character.

There is a good reason to present that detailed data.
Experienced users will sometimes find it useful.

Can we find a good way to present both the general explanation
and the specific data?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Users who need to actually do something useful with their time, not
  > > just follow hyperlinks, will very quickly lose patience and stop
  > > following.

  > I just have a feeling you got that opinion too subjectively. In my
  > opinion, every word should be reachable, so that user can understand
  > everything,

When you say "reachable", could you explain concretely?
Reachable "where"?  Where would the code find the text to
refer to?  That question is crucial for both practical
and ethica; questions.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > And even a personal incentive: nobody likes to answer the same questions 
  > again and again.

  > But it would have to be an official GNU initiative. Probably done by the 
  > one of the current Emacs maintainers, or some other people who still 
  > have the authority to make significant changes in Emacs.

It is not useful to propose this in the abstract.  An argument about
whether this is a desirable feature is not useful.  If you propose a
concrete design, people can refine it through discussion,  Then maybe
we can decide we would like it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 26 Sep 2020 22:42:23 -0400
> Cc: eliz@gnu.org, jamtlu@gmail.com, emacs-devel@gnu.org
> 
> That particular tooltip is detailed data for an experienced user.

"Relatively experienced", I would say.  Those who are _really_
experienced, like myself, don't need to tooltip to understand what the
mnemonics say.

Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-09-27 05:43]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > > Users who need to actually do something useful with their time, not
>   > > just follow hyperlinks, will very quickly lose patience and stop
>   > > following.
> 
>   > I just have a feeling you got that opinion too subjectively. In my
>   > opinion, every word should be reachable, so that user can understand
>   > everything,
> 
> When you say "reachable", could you explain concretely?
> Reachable "where"?  Where would the code find the text to
> refer to?  That question is crucial for both practical
> and ethica; questions.

You are right, I have not expressed myself well.

Consider two extremes: reading some alien language which one does not
know, certainly belongs to extreme misunderstanding area. Reading
simple English belongs to extreme understanding area.

In any computing, people are asking questions. If they are alone, they
may go through larval stage until they understand all the terms. This
is because of tedious work to find proper definitions for words.

Thus when I said that every word should be reachable, in my opinion
every special term should be defined in the glossary. This is for the
sake of bringing understanding to users. This is something that should
be internal to Emacs. Modifier plus mouse or some key could bring jump
to definition of the word in glossary. This feature is not so
complex. It should include looking up words from within Info files as
well, and if such definition does not exit, there should be fallback
to some external dictionaries.

And for just any word, including those words in the menu, anywhere,
there should be possibility to define or search for such words,
including in any other languages. That is my general opinion, I am
using wordnut package and I can quickly define any word at point, if I
click enter on any word within the definition of Wordnet dictionary, I
am going to the other definition, this way I can clarify any
misunderstood words. This feature could be external to Emacs, as it is
much more complex. There are many packages using various dictionaries,
such could be put in a group.

Emacs should in general have an option under Tools -> Look up word, as
we deal with words, and dictionary feature should be internal to
Emacs, and not just external package.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Sun, 27 Sep 2020 10:32:21 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: eliz@gnu.org, jamtlu@gmail.com, emacs-devel@gnu.org
> 
> Emacs should in general have an option under Tools -> Look up word

We have that under Help->Search Documentation.

P.S. Email responses to you bounce.  Could you please fix your return
address to prevent that from happening?

Re: How to make Emacs popular again.

[Dmitry Gutov]

On 27.09.2020 05:42, Richard Stallman wrote:
>    > And even a personal incentive: nobody likes to answer the same questions
>    > again and again.
> 
>    > But it would have to be an official GNU initiative. Probably done by the
>    > one of the current Emacs maintainers, or some other people who still
>    > have the authority to make significant changes in Emacs.
> 
> It is not useful to propose this in the abstract.  An argument about
> whether this is a desirable feature is not useful.  If you propose a
> concrete design, people can refine it through discussion,  Then maybe
> we can decide we would like it.

This subthread is not about a particular feature, but about a service 
where you have to solve users' problems (for money; one-time or a 
subscription fee), and in the course of that become more familiar with 
the usual difficulties that they encounter.

I'm not really sure it will take off given Emacs' waning popularity, but 
it sounds like something worth trying.

Here's one potential client's message.

https://www.reddit.com/r/emacs/comments/j04xxw/i_am_in_awe_of_emacs/g6pleve/?utm_source=reddit&utm_medium=web2x&context=3

Quoting from there:

 >>>

I would gladly make a monthly contribution to an "emacs accessibility" 
project

I would also gladly pay for emacs setup consultation. Magit broke when I 
changed jobs and setup emacs anew. (I had my old .emacs but I wasn't 
meticulous about noting the version of emacs I was using at the old job 
and what versions of packages I had). I love magit and contribute 
monthly to their patreon (despite the fact that I currently can't use it).

I've used emacs for over 20 years and love it. OTOH, every hour spent 
tinkering with emacs is an hour I'm not working on what I'm paid to work 
on. With my most recent job change I probably spent 1/2 a day (or more) 
getting emacs setup again. After spending that much time I probably 
won't re-attempt to fix magit (and other broken things) for another 6 
months or more.

What I want to use (and have "just work") is

     C/C++ language LSP // I currently use cscope and for C that is good 
enough. Meh on the ease of setup and having to periodically rerun cscope 
to update the symbols

     Go language LSP // I currently use go guru which is good enough

     programming lang auto-complete and highlight current symbol

     Org-mode // works great for me out of the box.

     magit!! // currently broken for me. I really miss being able to 
view annotated files with a keystroke

     gud // this works pretty darn well out of the box, even with 
golang's delve

It would be great if, I could

     get my emacs environment set up just right

     create a docker image from said environment

     move that perfectly working emacs environment with me from job to job

     easily update the docker image with changes now and then

My assessment is that this would requires too much up front work and the 
friction involved in updating the container with new changes is too high.

It is great that emacs continues to be developed with new features 
added. I want that to continue, but what I really want that is missing 
is the ability to not waste time on emacs tinkering if I'm satisfied 
with my current setup and change employers.

<<<

Re: tooltip feature

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > A tooltip in Emacs user interface should have the option to be
>   > "caught" or examined, that it does not disappear,
>
> That is a good idea.  Is there a natural interface for commanding
> this?
Considering a tool-tip is just a small pop-up frame you could have it
with a character in a tooltip corner which could act as a "sticky
button" to press with mouse, and there could be a keyboard shortcut user
can press when a tooltip have a focus.

Such a "button" could be also added to context menus to make them
"sticky" and persistent on the screen. Another version is to have a tiny
separator say in tooltip bottom/top that can be pressed with mouse to
"tear of" the tooltip and make it persistent on the screen. 

Some software have this feature for menus usually (never saw it for a
tooltip), and if I remember well, it is common in tcl/tk scripts.

Re: tooltip feature

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Sun, 27 Sep 2020 11:42:04 +0200
> Cc: emacs-devel@gnu.org, jamtlu@gmail.com, Jean Louis <bugs@rcdrun.com>
> 
> Considering a tool-tip is just a small pop-up frame you could have it
> with a character in a tooltip corner which could act as a "sticky
> button" to press with mouse, and there could be a keyboard shortcut user
> can press when a tooltip have a focus.

Sounds complicated (and I'm not sure it will be possible when we use
GTK tooltips, which is the default in the GTK builds).

Emacs is already capable of redirecting the tooltip text to the echo
area (to see that, disable tooltip-mode), so it should be easy to
provide some command or variable, which, when activated, would copy
the tooltip text to some specialized buffer, where it could be later
read by the user.

Would you like to propose a patch along these lines?

> Such a "button" could be also added to context menus to make them
> "sticky" and persistent on the screen.

For menus, most Emacs configurations use the toolkit.  Do the toolkits
we use offer capabilities to make the menus "sticky"?

> Another version is to have a tiny separator say in tooltip
> bottom/top that can be pressed with mouse to "tear of" the tooltip
> and make it persistent on the screen.

AFAIK, you generally cannot click on tooltips, because they disappear
when you do so.

Re: tooltip feature

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Sun, 27 Sep 2020 11:42:04 +0200
>> Cc: emacs-devel@gnu.org, jamtlu@gmail.com, Jean Louis <bugs@rcdrun.com>
>> 
>> Considering a tool-tip is just a small pop-up frame you could have it
>> with a character in a tooltip corner which could act as a "sticky
>> button" to press with mouse, and there could be a keyboard shortcut user
>> can press when a tooltip have a focus.
>
> Sounds complicated (and I'm not sure it will be possible when we use
> GTK tooltips, which is the default in the GTK builds).
>
> Emacs is already capable of redirecting the tooltip text to the echo
> area (to see that, disable tooltip-mode), so it should be easy to
> provide some command or variable, which, when activated, would copy
> the tooltip text to some specialized buffer, where it could be later
> read by the user.
>
> Would you like to propose a patch along these lines?
>
>> Such a "button" could be also added to context menus to make them
>> "sticky" and persistent on the screen.
>
> For menus, most Emacs configurations use the toolkit.  Do the toolkits
> we use offer capabilities to make the menus "sticky"?
>
>> Another version is to have a tiny separator say in tooltip
>> bottom/top that can be pressed with mouse to "tear of" the tooltip
>> and make it persistent on the screen.
>
> AFAIK, you generally cannot click on tooltips, because they disappear
> when you do so.
I understand.

I don't know what Gtk offers, I am sorry; I always avoided
to get into that toolkit, so I really don't know :-).

According to docs there is a GtkTearoffMenuItem:

https://developer.gnome.org/gtk3/stable/GtkTearoffMenuItem.html

but then I don't know how useful is that to Emacs since I am not into
internals on the Gtk front ...

Sorry for the confusion.

Re: How to make Emacs popular again.

[Dmitry Gutov]

On 27.09.2020 05:41, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > It's very discouraging to see the constant push-back against even the
>    > small and reasonable changes.
> 
> We do adopt some such changes.

If it's an actual change, and not just an addition, the amount of effort 
required to enact it is very often vastly disproportionate.

> Arguing about people's general nature is useless.
> You can't convince anyone about a general characeristic
> and arguing trnds to offend.

I'm not talking about people's nature. This is feedback on the general 
process, which you can take under advisement, or not.

I've been here for a number of years, so I'm not just talking out of my 
posterior.

> Please focus on a specific proposal you want to try to advance.
> We can work on it until we reach a form that is ok to adopt.
> That is how progress is made.

There has been a number of those in this year alone.

Here's a simple example:

https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00842.html

BTW, my last personal email to you has seen no response. Were you too 
busy, or is there some delivery problem, maybe?

Re: tooltip feature

[Stefan Monnier]

> Considering a tool-tip is just a small pop-up frame you could have it
> with a character in a tooltip corner which could act as a "sticky
> button" to press with mouse, and there could be a keyboard shortcut user
> can press when a tooltip have a focus.

In case this is not a option, an alternative would be to provide
a command which will catch the content of the next tooltip (and
e.g. put it into the kill-ring).


        Stefan

Re: How to make Emacs popular again.

[Bob Newell]

In your long posting with many ideas about making Emacs
beginner friendly, there is much to consider, and I must say
right at the start that easing the Emacs learning experience
is a worthy goal.

It does raise the question: how did the current Emacs users
learn Emacs? I can't speak for anyone else but I don't know
that my own experiences are in any way unique. I learned first
from the tutorial, then from some of the manuals, then by doing
and experimenting and reading more of the manuals, and trial
and error.

Could this have been more efficient? Yes, of course. But I did
I learn a lot in the process--- a very serious "lot"--- and it
cemented my knowledge and appreciation of what Emacs could,
and was already, doing for me.

Do I advocate pure bumbling in the dark as a means of
learning?  No. But perhaps guided bumbling is more of the
thing.

We can never forget something critically important: Emacs is a
very sophisticated, very powerful tool, and like all such
tools, it takes effort and dedication to learn. (Even lesser
tools, like office suites, take effort to learn, if perhaps in
lesser amounts.)

While we can and should do all we can to make the road
smoother--- short of turning Emacs into something completely
different and so overwhelmed with tooltips, popups, and other
"help" that it becomes unpleasant or even unusable--- let's
face it, Emacs is never going to be "easy."

Emacs will continue to attract a certain audience. I'm not
sure that this is an issue per se. Nor (as I've said in the
past) do I mean this to be an elitist thing. Emacs has a
certain appeal to certain people. So does opera, baseball, or
liver and onions.

Things are, in fact, very much easier now than when I started
with Emacs decades ago. Today, there is a wealth of on-line
information, with tutorials, how-tos, discussions, code
samples, and help readily available to anyone who asks
politely. 

But in the end: do you become a chess master after reading a
"Chess Made Easy" book? Do you become a concert guitarist
after working through "Guitar Playing Made Easy For
Beginners"?

Effort and reward go together, whether it's Emacs or anything
else that is deep and sophisticated. If someone wants instant
gratification, maybe Twitter is a better choice.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: How to make Emacs popular again.

[James Lu]

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

Some things don't need to sacrifice existing users for new users:
* Having the documentation organized nicely
* Interactive things

For example, when I first wrote "DEADLINE:" under a todo in
org-mode, why couldn't there be a pop-up poining me to a tutorial on
how to sort by deadline?

That's easier than learning the DEADLINE: syntax then
specifically searching out a tutorial for it.

And re the Cua mode argument:
Why not ask the user what they're used to in a wizard, that
activates with something like M-x setup. We can learn from
IntelliJ Community Edition here.*

*IntelliJ CE is free software.

On Sun, Sep 27, 2020 at 1:32 PM Bob Newell <bobnewell@bobnewell.net> wrote:

>
> In your long posting with many ideas about making Emacs
> beginner friendly, there is much to consider, and I must say
> right at the start that easing the Emacs learning experience
> is a worthy goal.
>
> It does raise the question: how did the current Emacs users
> learn Emacs? I can't speak for anyone else but I don't know
> that my own experiences are in any way unique. I learned first
> from the tutorial, then from some of the manuals, then by doing
> and experimenting and reading more of the manuals, and trial
> and error.
>
> Could this have been more efficient? Yes, of course. But I did
> I learn a lot in the process--- a very serious "lot"--- and it
> cemented my knowledge and appreciation of what Emacs could,
> and was already, doing for me.
>
> Do I advocate pure bumbling in the dark as a means of
> learning?  No. But perhaps guided bumbling is more of the
> thing.
>
> We can never forget something critically important: Emacs is a
> very sophisticated, very powerful tool, and like all such
> tools, it takes effort and dedication to learn. (Even lesser
> tools, like office suites, take effort to learn, if perhaps in
> lesser amounts.)
>
> While we can and should do all we can to make the road
> smoother--- short of turning Emacs into something completely
> different and so overwhelmed with tooltips, popups, and other
> "help" that it becomes unpleasant or even unusable--- let's
> face it, Emacs is never going to be "easy."
>
> Emacs will continue to attract a certain audience. I'm not
> sure that this is an issue per se. Nor (as I've said in the
> past) do I mean this to be an elitist thing. Emacs has a
> certain appeal to certain people. So does opera, baseball, or
> liver and onions.
>
> Things are, in fact, very much easier now than when I started
> with Emacs decades ago. Today, there is a wealth of on-line
> information, with tutorials, how-tos, discussions, code
> samples, and help readily available to anyone who asks
> politely.
>
> But in the end: do you become a chess master after reading a
> "Chess Made Easy" book? Do you become a concert guitarist
> after working through "Guitar Playing Made Easy For
> Beginners"?
>
> Effort and reward go together, whether it's Emacs or anything
> else that is deep and sophisticated. If someone wants instant
> gratification, maybe Twitter is a better choice.
>
> --
> Bob Newell
> Honolulu, Hawai`i
>
> - Via GNU/Linux/Emacs/Gnus/BBDB
>
>

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

Re: How to make Emacs popular again.

[James Lu]

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

Can your response be summarized like this?

"Let's keep doing the same thing we're doing now
and get the same result we've been getting for decades."


> Today, there is a wealth of on-line
> information, with tutorials, how-tos, discussions, code
> samples, and help readily available to anyone who asks
> politely.

Sure, but when I search "emacs org-mode deadline agenda"
on Google, I get an helpful page from org-mode manual
as the first result. I want to sort by deadline, not see what's
due today. "I want to do X" guides don't appear.

"emacs org-mode sort by deadline agenda" gets
me this that just tells me to follow another link and read
several more paragraphs:
https://orgmode.org/manual/Sorting-of-agenda-items.html

Compare that to most task managers that simply show you
where on the GUI to do it. I want a guide and a lecture, not
a lecture and a puzzle. Even if it's a little puzzle, I shouldn't
have to think about it to do a task other people have done
before.

Say what you will about it "taking time to learn." I think
the documentation is poorly organized.

On Sun, Sep 27, 2020 at 1:32 PM Bob Newell <bobnewell@bobnewell.net> wrote:

>
> In your long posting with many ideas about making Emacs
> beginner friendly, there is much to consider, and I must say
> right at the start that easing the Emacs learning experience
> is a worthy goal.
>
> It does raise the question: how did the current Emacs users
> learn Emacs? I can't speak for anyone else but I don't know
> that my own experiences are in any way unique. I learned first
> from the tutorial, then from some of the manuals, then by doing
> and experimenting and reading more of the manuals, and trial
> and error.
>
> Could this have been more efficient? Yes, of course. But I did
> I learn a lot in the process--- a very serious "lot"--- and it
> cemented my knowledge and appreciation of what Emacs could,
> and was already, doing for me.
>
> Do I advocate pure bumbling in the dark as a means of
> learning?  No. But perhaps guided bumbling is more of the
> thing.
>
> We can never forget something critically important: Emacs is a
> very sophisticated, very powerful tool, and like all such
> tools, it takes effort and dedication to learn. (Even lesser
> tools, like office suites, take effort to learn, if perhaps in
> lesser amounts.)
>
> While we can and should do all we can to make the road
> smoother--- short of turning Emacs into something completely
> different and so overwhelmed with tooltips, popups, and other
> "help" that it becomes unpleasant or even unusable--- let's
> face it, Emacs is never going to be "easy."
>
> Emacs will continue to attract a certain audience. I'm not
> sure that this is an issue per se. Nor (as I've said in the
> past) do I mean this to be an elitist thing. Emacs has a
> certain appeal to certain people. So does opera, baseball, or
> liver and onions.
>
> Things are, in fact, very much easier now than when I started
> with Emacs decades ago. Today, there is a wealth of on-line
> information, with tutorials, how-tos, discussions, code
> samples, and help readily available to anyone who asks
> politely.
>
> But in the end: do you become a chess master after reading a
> "Chess Made Easy" book? Do you become a concert guitarist
> after working through "Guitar Playing Made Easy For
> Beginners"?
>
> Effort and reward go together, whether it's Emacs or anything
> else that is deep and sophisticated. If someone wants instant
> gratification, maybe Twitter is a better choice.
>
> --
> Bob Newell
> Honolulu, Hawai`i
>
> - Via GNU/Linux/Emacs/Gnus/BBDB
>
>

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

Re: How to make Emacs popular again.

[James Lu]

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

> on Google, I get an helpful page from org-mode manual
*an unhelpful

On Sun, Sep 27, 2020 at 4:38 PM James Lu <jamtlu@gmail.com> wrote:

> Can your response be summarized like this?
>
> "Let's keep doing the same thing we're doing now
> and get the same result we've been getting for decades."
>
>
> > Today, there is a wealth of on-line
> > information, with tutorials, how-tos, discussions, code
> > samples, and help readily available to anyone who asks
> > politely.
>
> Sure, but when I search "emacs org-mode deadline agenda"
> on Google, I get an helpful page from org-mode manual
> as the first result. I want to sort by deadline, not see what's
> due today. "I want to do X" guides don't appear.
>
> "emacs org-mode sort by deadline agenda" gets
> me this that just tells me to follow another link and read
> several more paragraphs:
> https://orgmode.org/manual/Sorting-of-agenda-items.html
>
> Compare that to most task managers that simply show you
> where on the GUI to do it. I want a guide and a lecture, not
> a lecture and a puzzle. Even if it's a little puzzle, I shouldn't
> have to think about it to do a task other people have done
> before.
>
> Say what you will about it "taking time to learn." I think
> the documentation is poorly organized.
>
> On Sun, Sep 27, 2020 at 1:32 PM Bob Newell <bobnewell@bobnewell.net>
> wrote:
>
>>
>> In your long posting with many ideas about making Emacs
>> beginner friendly, there is much to consider, and I must say
>> right at the start that easing the Emacs learning experience
>> is a worthy goal.
>>
>> It does raise the question: how did the current Emacs users
>> learn Emacs? I can't speak for anyone else but I don't know
>> that my own experiences are in any way unique. I learned first
>> from the tutorial, then from some of the manuals, then by doing
>> and experimenting and reading more of the manuals, and trial
>> and error.
>>
>> Could this have been more efficient? Yes, of course. But I did
>> I learn a lot in the process--- a very serious "lot"--- and it
>> cemented my knowledge and appreciation of what Emacs could,
>> and was already, doing for me.
>>
>> Do I advocate pure bumbling in the dark as a means of
>> learning?  No. But perhaps guided bumbling is more of the
>> thing.
>>
>> We can never forget something critically important: Emacs is a
>> very sophisticated, very powerful tool, and like all such
>> tools, it takes effort and dedication to learn. (Even lesser
>> tools, like office suites, take effort to learn, if perhaps in
>> lesser amounts.)
>>
>> While we can and should do all we can to make the road
>> smoother--- short of turning Emacs into something completely
>> different and so overwhelmed with tooltips, popups, and other
>> "help" that it becomes unpleasant or even unusable--- let's
>> face it, Emacs is never going to be "easy."
>>
>> Emacs will continue to attract a certain audience. I'm not
>> sure that this is an issue per se. Nor (as I've said in the
>> past) do I mean this to be an elitist thing. Emacs has a
>> certain appeal to certain people. So does opera, baseball, or
>> liver and onions.
>>
>> Things are, in fact, very much easier now than when I started
>> with Emacs decades ago. Today, there is a wealth of on-line
>> information, with tutorials, how-tos, discussions, code
>> samples, and help readily available to anyone who asks
>> politely.
>>
>> But in the end: do you become a chess master after reading a
>> "Chess Made Easy" book? Do you become a concert guitarist
>> after working through "Guitar Playing Made Easy For
>> Beginners"?
>>
>> Effort and reward go together, whether it's Emacs or anything
>> else that is deep and sophisticated. If someone wants instant
>> gratification, maybe Twitter is a better choice.
>>
>> --
>> Bob Newell
>> Honolulu, Hawai`i
>>
>> - Via GNU/Linux/Emacs/Gnus/BBDB
>>
>>

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

Re: How to make Emacs popular again.

[Bob Newell]

James Lu <jamtlu@gmail.com> writes:

> Can your response be summarized like this?
>
> "Let's keep doing the same thing we're doing now
> and get the same result we've been getting for decades."

No, that's a complete misreading! And in any case, Emacs has
grown and developed over the years, and become ever more
powerful. That's positive change with positive results.

I perhaps wasn't clear enough about saying that of course more
high-quality documentation would be a good thing, that more
clarity would be a good thing, and that easing the learning
curve would be a good thing. (That's not to say that there
isn't already a lot of good documentation available, although
perhaps scattered about.)

The other side of that, though, is that I wouldn't like to see
Emacs turned into some bloated monster. It's large enough as
it is, but at least the size relates to the power. Emacs was
never big on frills and cosmetics.

Perhaps we have different concepts of what Emacs is or should
be, and that's fine. The Emacs community is broad and a
variety of opinions exist, as they should.

I don't want Emacs to be Visual Studio. I certainly don't want
it to be like an office suite with toolbars and ribbons filled
with incomprehensible icons. I'm comfortable with the idea of
putting in effort to get a lot more back in return. In turn, I
recognize the need to keep the community active by bringing in
new people. It's a balancing act but if we don't stay true to
the core concepts of Emacs, which to me are unrivaled power
and flexibility with a minimalist, unobtrusive interface,
I think we will have gone in an unfortunate direction.

I don't really know the statistics: is the Emacs audience
truly in decline? By what measure? This is not a challenge but
a genuine question; I really don't know the answer.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: How to make Emacs popular again.

[황병희]

Bob Newell <bobnewell@bobnewell.net> writes:

> James Lu <jamtlu@gmail.com> writes:
>
>> Can your response be summarized like this?
>>
>> "Let's keep doing the same thing we're doing now
>> and get the same result we've been getting for decades."
>
> No, that's a complete misreading! And in any case, Emacs has
> grown and developed over the years, and become ever more
> powerful. That's positive change with positive results.
>
> I perhaps wasn't clear enough about saying that of course more
> high-quality documentation would be a good thing, that more
> clarity would be a good thing, and that easing the learning
> curve would be a good thing. (That's not to say that there
> isn't already a lot of good documentation available, although
> perhaps scattered about.)
>
> The other side of that, though, is that I wouldn't like to see
> Emacs turned into some bloated monster. It's large enough as
> it is, but at least the size relates to the power. Emacs was
> never big on frills and cosmetics.
>
> Perhaps we have different concepts of what Emacs is or should
> be, and that's fine. The Emacs community is broad and a
> variety of opinions exist, as they should.
>
> I don't want Emacs to be Visual Studio. I certainly don't want
> it to be like an office suite with toolbars and ribbons filled
> with incomprehensible icons. I'm comfortable with the idea of
> putting in effort to get a lot more back in return. In turn, I
> recognize the need to keep the community active by bringing in
> new people. It's a balancing act but if we don't stay true to
> the core concepts of Emacs, which to me are unrivaled power
> and flexibility with a minimalist, unobtrusive interface,
> I think we will have gone in an unfortunate direction.

Wow, really i like Bob's thought^^^

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Thus when I said that every word should be reachable, in my opinion
  > every special term should be defined in the glossary. This is for the
  > sake of bringing understanding to users. This is something that should
  > be internal to Emacs. Modifier plus mouse or some key could bring jump
  > to definition of the word in glossary.

Now I understand what you are asking for:

* To add more items to the glossary.  (Want to suggest some?)

and

* To make a more convenient command to search the glossary for
the word at point.

Each of these may be possible.  The two are independent and could
be worked on separately.

  > And for just any word, including those words in the menu, anywhere,
  > there should be possibility to define or search for such words,

Sorry, I don't understand that text.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Here's a simple example:

  > https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00842.html

Referring to messages that way is inconvenient for me.  The message is
in my saved mail, but I cannot find it with that info.  Would you
please send message IDs instead?  I can search for that.

  > BTW, my last personal email to you has seen no response. Were you too 
  > busy, or is there some delivery problem, maybe?

Sorry, I don't remember.  I don't remember things like that for very
long nowadays.  If it was important, ask me again.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This subthread is not about a particular feature, but about a service 
  > where you have to solve users' problems (for money; one-time or a 
  > subscription fee), and in the course of that become more familiar with 
  > the usual difficulties that they encounter.

It might be a good idea,   It would take a lot of work to organize,
and the organizer would need business experience.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For example, when I first wrote "DEADLINE:" under a todo in
  > org-mode, why couldn't there be a pop-up poining me to a tutorial on
  > how to sort by deadline?

How about trying to implement that?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Jean Louis]

Emacs is today more popular than ever. There is no decline in
popularity, there is increase in popularity.

If one is developing or let's say simply loving Emacs as software,
then one should look into how many new users are coming to Emacs and
how spread and disseminated is Emacs and what impact it does, and if
that impact is greater and greater or lesser and lesser.

There is no point in measuring various other editors and looking into
the proportional statistics of editor usage, to say that Emacs is not
popular, as that is incorrect, inadequate, let me also say false
statistics, that spreads doubts, it's negative energy.

Let me give you example:

Time period 1:

- emacs users 20
- other editor A 20
- other editor B 35

Time period 2:

- emacs users 25
- other editor A 23
- other editor B 38

Time period 3:

- emacs users 30
- other editor A 30
- other editor B 42

In this blunt example, if you look into how many other editors are
used and compare that to Emacs, you could be saying that Emacs is not
popular.

But that is wrong way of looking into things, what one has to look is
if Emacs is being used more and more.

If I sell bread from my own bakery, I do not mind and it becomes
really not relevant, if so many other bakeries are out there, also
seling all kinds of bread.

What really makes impact to me, as from my viewpoint, is if my bread
is selling more and more. As that is the one true statistics of
improvement and impact.

Statistics of improvement and impact and popularity of Emacs should be
watched from Emacs distribution statistics.

I have no access to YouTube, as I did not pay tax for Internte here in
Uganda and don't use VPN to access it, but I think that YouTube offers
searches by time, so one could search for Emacs in specific year
maybe, as what I know is that today there are more and more Emacs
presentations and videos, and more and more people speak about Emacs,
as I am observing it last 21 years, I can say today is Emacs more
popular than ever.

Jean

Re: How to make Emacs popular again.

[Jean Louis]

* James Lu <jamtlu@gmail.com> [2020-09-27 23:40]:
> Sure, but when I search "emacs org-mode deadline agenda"
> on Google, I get an helpful page from org-mode manual
> as the first result. I want to sort by deadline, not see what's
> due today. "I want to do X" guides don't appear.

> "emacs org-mode sort by deadline agenda" gets
> me this that just tells me to follow another link and read
> several more paragraphs:
> https://orgmode.org/manual/Sorting-of-agenda-items.html

When faced with those issues, I am using the built-in info system, so
something like {C-h i} then I find "Org Mode" then inside there, I am
using {C-s deadline}, so I need not have any Internet access at all
and need not consult same information online.

Emacs and Org Mode and many other features are well documented in the
GNU systems, so use info, manuals, and /usr/share/doc/ information.

> Compare that to most task managers that simply show you
> where on the GUI to do it. I want a guide and a lecture, not
> a lecture and a puzzle. Even if it's a little puzzle, I shouldn't
> have to think about it to do a task other people have done
> before.

Look into the information above, it is most probably already on your
computer.

The information on how to use the info system is in Help -> Tutorial

Jean

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: James Lu <jamtlu@gmail.com>
> Date: Sun, 27 Sep 2020 16:31:49 -0400
> 
> Some things don't need to sacrifice existing users for new users:
> * Having the documentation organized nicely 
> * Interactive things

Yes.  But someone has to do the work of making these happen.

> For example, when I first wrote "DEADLINE:" under a todo in
> org-mode, why couldn't there be a pop-up poining me to a tutorial on
> how to sort by deadline?
> 
> That's easier than learning the DEADLINE: syntax then
> specifically searching out a tutorial for it.
> 
> And re the Cua mode argument:
> Why not ask the user what they're used to in a wizard, that
> activates with something like M-x setup. We can learn from
> IntelliJ Community Edition here.*

Nothing in Emacs gets done because someone asks a "why not do this and
that?" question.  We don't have a means to tell some employee to do
this and that job.  For a job to get done, someone motivated enough
should sit down and do it.  The best candidate for that is whoever
raises the issue in the first place, but of course not everyone who
proposes something can actually implement it.

Re: How to make Emacs popular again [or less square].

[Po Lu]

James Lu <jamtlu@gmail.com> writes:

> I am a new (2020 started) Emacs user. 

Welcome to the club.

> Sell customer support packages, so
> 1) You can focus on gaining users = giving more users computer user
> freedom and user empowerment.

There are a few GNU projects that actually do this, usually by
outsourcing the support to a separate organization or having the
maintainer provide support himself (notably Octave and GNAT), but for a
pretty complicated set of reasons I don't really think this can apply to
Emacs, which AFAIK is not employed in any large commercial context, or
used by the sort of people who are actually interested in expensive
support packages.

> 2) You can better understand the problems with Emacs' documentation
> and user interface because people will email you support questions on
> them, incentivizing you to reduce how many support queries are needed.
> User experience testing. a la Don't Make Me Think by Steve Krug.  Path
> dependence-- sequence points
> matter. https://kwokchain.com/2020/06/19/why-figma-wins/

There was another thread talking about this from a while back (feel free
to search 'Why is Emacs so square?' in the mailing list archives), which
did actually talk about some user experience improvements.  Some of the
ideas were fairly good (such as improving the appalling icons in gud.el,
suggesting packages when opening various files), while others were not
really practical (for instance drastically changing the defaults, and
moving the existing defaults to a "vanilla-mode").  It would be a
terrible waste of time if that particular discussion was repeated here.

Re: How to make Emacs popular again [or less square].

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 28 Sep 2020 17:00:40 +0800
> 
> It would be a terrible waste of time if that particular discussion
> was repeated here.

If you wait enough time, it will be, whether we want it or not.

Re: How to make Emacs popular again.

[Ergus]

Sorry Jean Louis but I totally disagree with all your opinions.

1) Yes, emacs popularity is NOT growing even without proportions, not
relative or absolute numbers grow. You look at younger projects like
sublime, atom, VSCode, notepad++, even vim is MUCH more popular than
us. Just search editor ranking and you will see. Numbers are not
opinions... that's the good about numbers.

2) There were some emails some weeks ago with some statistics and data
but you can check many of them online. 

3) Not only numbers but also community interaction and references to
emacs are negligible if we compare with much newer projects around. 

4) Also the number of developers is a measurement... specially the
number of young and new developers... Most people prefer to just develop
small packages and project and never even try to join to the core
development. We should be worried about that and ask us why.

5) Denying the importance of the statistics here is like trusting the
health of the project to feelings and hopes... Actually there are many
ways to measure the health-maintainability-popularity of a project from
different points of view (downloads, google hits, references, scientific
articles related, number of threads in reddit, editor rankings, views
and likes in youtube channel of related videos...) If you don't trust
statistics then just look at the starts and ask them.

I don't consider this as a competition; but as developers this is
important:

Popularity is proportional to users, users to potential developers and
potential developers to new functionalities, updates, code reviews, new
ideas. The less professional and newer users usually find issues more
often than the advanced programmers.



On Mon, Sep 28, 2020 at 08:16:06AM +0300, Jean Louis wrote:
>Emacs is today more popular than ever. There is no decline in
>popularity, there is increase in popularity.
>
>If one is developing or let's say simply loving Emacs as software,
>then one should look into how many new users are coming to Emacs and
>how spread and disseminated is Emacs and what impact it does, and if
>that impact is greater and greater or lesser and lesser.
>
>There is no point in measuring various other editors and looking into
>the proportional statistics of editor usage, to say that Emacs is not
>popular, as that is incorrect, inadequate, let me also say false
>statistics, that spreads doubts, it's negative energy.
>
>Let me give you example:
>
>Time period 1:
>
>- emacs users 20
>- other editor A 20
>- other editor B 35
>
>Time period 2:
>
>- emacs users 25
>- other editor A 23
>- other editor B 38
>
>Time period 3:
>
>- emacs users 30
>- other editor A 30
>- other editor B 42
>
>In this blunt example, if you look into how many other editors are
>used and compare that to Emacs, you could be saying that Emacs is not
>popular.
>
>But that is wrong way of looking into things, what one has to look is
>if Emacs is being used more and more.
>
>If I sell bread from my own bakery, I do not mind and it becomes
>really not relevant, if so many other bakeries are out there, also
>seling all kinds of bread.
>
>What really makes impact to me, as from my viewpoint, is if my bread
>is selling more and more. As that is the one true statistics of
>improvement and impact.
>
>Statistics of improvement and impact and popularity of Emacs should be
>watched from Emacs distribution statistics.
>
>I have no access to YouTube, as I did not pay tax for Internte here in
>Uganda and don't use VPN to access it, but I think that YouTube offers
>searches by time, so one could search for Emacs in specific year
>maybe, as what I know is that today there are more and more Emacs
>presentations and videos, and more and more people speak about Emacs,
>as I am observing it last 21 years, I can say today is Emacs more
>popular than ever.
>
>Jean
>

Re: How to make Emacs popular again.

[James Lu]

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

On Sun, Sep 27, 2020 at 8:52 PM Bob Newell <bobnewell@bobnewell.net> wrote:

> > I don't want Emacs to be Visual Studio. I certainly don't want
> it to be like an office suite with toolbars and ribbons filled
> with incomprehensible icons. I'm comfortable with the idea of
> putting in effort to get a lot more back in return. In turn, I
> recognize the need to keep the community active by bringing in
> new people. It's a balancing act but if we don't stay true to
> the core concepts of Emacs, which to me are unrivaled power
> and flexibility with a minimalist, unobtrusive interface,
> I think we will have gone in an unfortunate direction.

I agree wholeheartedly.

If I look at other todo apps...they have either too many features
or too few, and most importantly, almost every user complains
something doesn't work the way they want... org-mode has
none of those problems: it's flexible and adaptable to the core.

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

Re: How to make Emacs popular again.

[James Lu]

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

I agree greatly with what Jean Louis said here.

On Sat, Sep 26, 2020 at 12:30 PM Jean Louis <bugs@rcdrun.com> wrote:

> * James Lu <jamtlu@gmail.com> [2020-09-26 16:40]:
> > I am a new (2020 started) Emacs user.
> >
> > Sell customer support packages, so
>
> > 1) You can focus on gaining users giving more users computer user
> > freedom and user empowerment.
>
> I understand what you mean. That is right and valid for any
> software. And I am sure you mean it for interaction with the software.
>
> > 2) You can better understand the problems with Emacs' documentation
> > and user interface
>
> Major problem there are abbreviations, words, terms, that are easily
> misunderstood by users which may cause rejections.
>
> If I am faced with a Chinese menu and I do not speak Chinese,
> obviously this will cause rejection and I will soonest possible stop
> using such editor. For a Chinese person, that editor or piece of
> software may become best thing they found and they may love it.
>
> By introducing a lot of Chinese-like terminology, let us call it
> simply potential misunderstoods, users are rejecting whatever they
> have in front of them.
>
> The remedy is already there, is it just not good enough. Good example
> of remedy are tooltips. Example is what I have here on the mode line:
>
>  -:**-
>
> So that is where the misunderstoods start, with -:**- so that looks
> like Chinese to me, even though I know what it means as experienced
> Emacs user. But from a view point of empowering a user, I have no clue
> how is that empowering me.
>
> If I move the mouse point there to the first - I can see following
> words inside of a tooltip:
>
> Buffer coding system (multi-byte): undecided-unix
> Mouse-1: describe coding system
> Mouse-3: set coding system
>
> So it is a tip, it should tell me some indications, but words are too
> hard for new users, one could ask himself what really applies to that
> definition of "buffer":
>
> * Overview of noun buffer
>
> The noun buffer has 7 senses (first 1 from tagged texts)
> 1. (8) buffer -- ((chemistry) an ionic compound that resists changes in
> its pH)
> 2. buffer zone, buffer -- (a neutral zone between two rival powers that is
> created in order to diminish the danger of conflict)
> 3. fender, buffer, cowcatcher, pilot -- (an inclined metal frame at the
> front of a locomotive to clear the track)
> 4. buffer, buffer storage, buffer store -- ((computer science) a part of
> RAM used for temporary storage of data that is waiting to be sent to a
> device; used to compensate for differences in the rate of flow of data
> between components of a computer system)
> 5. buffer, polisher -- (a power tool used to buff surfaces)
> 6. buffer, fender -- (a cushion-like device that reduces shock due to an
> impact)
> 7. buff, buffer -- (an implement consisting of soft material mounted on a
> block; used for polishing (as in manicuring))
>
> So there are plenty of ways how new user can get misunderstoods. Do
> not assume that such has a ready Wordnet dictionary to do
> {M-x wordnut-search} like I do. They most probably don't have it.
>
> A tooltip in Emacs user interface should have the option to be
> "caught" or examined, that it does not disappear, so that now user can
> click on words such as "buffer" and find out the definition of it,
> that user can understand what means "coding" in the context of buffer
> coding system, that user can understand what means "multi-byte", and
> what does it mean UNIX and what does it mean "undecided-unix", as if
> user does not know that, there is no reason or point to use the
> Mouse-1 to describe the coding system, as it really does not describe
> nothing to the user:
>
> > - -- undecided-unix (alias: unix)
>
> Why is it undecided?! It is unclear. Why is alias "unix"?! It is
> unclear, why not call it unix?! Why is it alias? What is alias?
> Consider my questions with !?  hypothetical questions that user could
> be asking.
>
> > No conversion on encoding, automatic conversion on decoding.
>
> This sentence says nothing. It is clear to developer what it means,
> but is unclear to average user.
>
> Conversion of what?! It is not specified.
>
> Encoding of what?! It is no specified.
>
> What would mean "automatic conversion"?!
>
> Decoding of what?!
>
> > Type: undecided (do automatic conversion)
>
> Who is undecided?! User or computer? If it is undecided why is it
> automatic?!
>
> > EOL type: LF
>
> No definition for this if I do: "!define EOL" inside of
> duckduckgo.com, I get this: https://www.thefreedictionary.com/EOL
>
> For LF I am asking myself, is it left field or low frequency:
> https://www.thefreedictionary.com/LF
>
> Of course I do know what Line Feed means, but average beginner will
> not know it.
>
> And there is no recourse within Emacs to find out about it.
>
> Thus to conclude my example here:
>
> - Making Emacs friendlier will be easier with a built-in dictionary
>   that will describe any terminology in easy English
>
> - all tooltips, all words, should be describable and definable by
>   clicking the mouse or choosing {M-x define-word} or similar
>   function. Just all. I am talking about easy English description of
>   Menus, it is analogous to {C-h k} to describe the menu, but in easy
>   way, without confusing the user more and more.
>
> Another practical example of nonsense within Emacs, but don't take me
> for a negative critic, I like Emacs now so much more because of
> nonsense descriptions, but look at this:
>
> - I press {C-h k} and then choose Tools -> Search Files (Grep)...
>
> Side comment: if it runs "grep" command, I don't know why it is
> capitalized, but alright.
>
> I wanted to find out about "Search Files..." so the menu option is
> pretty clear, it helps me search files, but then description about
> "Search files" does not even mention the word "search".
>
> It mentions other things, like <menu-bar> I would not know why is it
> so written, tools, grep, it does not help me understand what "grep"
> means, I cannot find it in my Wordnet dictionary as definition, and
> the the Duck is redirecting "!define grep" to Unix word, so I have no
> option to understand what "grep" would mean, it is confusing me and I
> am prone to reject it.
>
> Look what I read as description of a "Search Files (Grep...)" option
> menu:
>
>
> > <menu-bar> <tools> <grep> runs the command grep (found in global-map),
> > which is an autoloaded interactive compiled Lisp function in
> > ‘grep.el’.
>
> > It is bound to <menu-bar> <tools> <grep>.
>
> > (grep COMMAND-ARGS)
>
> >   Probably introduced at or before Emacs version 1.4.
>
> > Run Grep with user-specified COMMAND-ARGS.
> > The output from the command goes to the "*grep*" buffer.
>
> > While Grep runs asynchronously, you can use C-x ` (M-x next-error),
> > or RET in the *grep* buffer, to go to the lines where Grep found
> > matches.  To kill the Grep job before it finishes, type C-c C-k.
>
> > Noninteractively, COMMAND-ARGS should specify the Grep command-line
> > arguments.
>
> > For doing a recursive ‘grep’, see the ‘rgrep’ command.  For running
> > Grep in a specific directory, see ‘lgrep’.
>
> > This command uses a special history list for its COMMAND-ARGS, so you
> > can easily repeat a grep command.
>
> > A prefix argument says to default the COMMAND-ARGS based on the current
> > tag the cursor is over, substituting it into the last Grep command
> > in the Grep command history (or into ‘grep-command’ if that history
> > list is empty).
>
> > [back]
>
> For a new user, only two things make sense there:
>
> - The term "Search files", that is what makes sense
>
> - within the description of menu option "Search files" the only thing
>   that makes sense is [back] link
>
> > because people will email you support questions on them,
>
> Emacs should have a built in support question system, so that every
> user can straight send a support question, and which would be answered
> by using referenced or hyperlinked easy English, and such question
> would be then automatically placed on some website, or integrated
> into Emacs, so next users could then inquire answers in easier and
> easier manner.
>
> Jean
>

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

Re: How to make Emacs popular again.

[Jean Louis]

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

* Ergus <spacibba@aol.com> [2020-09-28 14:11]:
> Sorry Jean Louis but I totally disagree with all your opinions.
> 
> 1) Yes, emacs popularity is NOT growing even without proportions, not
> relative or absolute numbers grow. You look at younger projects like
> sublime, atom, VSCode, notepad++, even vim is MUCH more popular than
> us. Just search editor ranking and you will see. Numbers are not
> opinions... that's the good about numbers.

* Overview of noun popularity

The noun popularity has 1 sense (first 1 from tagged texts)

1. (6) popularity -- (the quality of being widely admired or accepted
or sought after; "his charm soon won him affection and popularity";
"the universal popularity of American movies")

Measuring popularity of Johnny Depp by looking how much popularity got
Arnold Schwarzenegger and Jim Carrey and Emma Watson is simply fake
and misleading.

Popularity of Johnny Depp is thing for itself, popularity for Arnold
Schwarzenegger is popularity for itself.

This quick research is telling how many results for term "emacs" are
there per year on YouTube. It is not necessarily showing Emcas editor,
there is variety of stuff, so statistics cannot be accurate, but it
gives a good feeling that Emacs popularity grows and grows from year
to year, and that it is in 2020 more than ever before.

before:2002-12-21 after:2002-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2002-12-21+after%3A2002-01-01+emacs
0 results

before:2003-12-21 after:2003-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2003-12-21+after%3A2003-01-01+emacs
0 results

before:2004-12-21 after:2004-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2004-12-21+after%3A2004-01-01+emacs
0 results

before:2005-12-21 after:2005-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2005-12-21+after%3A2005-01-01+emacs
1 result

before:2006-12-21 after:2006-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2006-12-21+after%3A2006-01-01+emacs&sp=CAM%253D
54 results, about 54 videos in 2006

before:2007-12-21 after:2007-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2007-12-21+after%3A2007-01-01+emacs
124 pages each about 3 videos per page, approximately 372 videos in 207

before:2008-12-21 after:2008-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2008-12-21+after%3A2008-01-01+emacs
134 pages, each about 3 videos per page, approximately 402 videos in 2008

before:2009-12-21 after:2009-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2009-12-21+after%3A2009-01-01+emacs
75 pages, each about 3 videos, approximately 225 videos in 2009

before:2010-12-21 after:2010-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2010-12-21+after%3A2010-01-01+emacs&sp=CAM%253D
16 pages x 3 approximately 48 videos in 2010

before:2011-12-21 after:2011-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2011-12-21+after%3A2011-01-01+emacs
65 pages x 3 approximately 195 videos in 2011

before:2012-12-21 after:2012-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2012-12-21+after%3A2012-01-01+emacs
59 pages x approximately 3 videos per page, result is approximately 177 videos in 2012

before:2013-12-21 after:2013-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2013-12-21+after%3A2013-01-01+emacs
93 pages, approximately 3 videos per page, result is approximately 279 videos in 2013

before:2014-12-21 after:2014-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2014-12-21+after%3A2014-01-01+emacs
73 pages x 3 videos gives approximate result of 219 videos in 2014

before:2015-12-21 after:2015-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2015-12-21+after%3A2015-01-01+emacs
86 pages x 3 videos, approximately 258 videos in 2015

before:2016-12-21 after:2016-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2016-12-21+after%3A2016-01-01+emacs
169 pages x 3 videos, approximately 507 videos in 2016

before:2017-12-21 after:2017-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2017-12-21+after%3A2017-01-01+emacs
179 pages x 3 videos, approximately 537 videos in 2017

before:2018-12-21 after:2018-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2018-12-21+after%3A2018-01-01+emacs
162 pages x 3 videos, approximately 486 videos in 2018

before:2019-12-21 after:2019-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2019-12-21+after%3A2019-01-01+emacs
199 pages x 3 videos, approximately 597 videos in 2019

before:2020-12-21 after:2020-01-01 emacs
https://www.youtube.com/results?search_query=before%3A2020-12-21+after%3A2020-01-01+emacs
208 page x 3 videos, approximately 624 videos in 2020, year is not yet over

Evaluate following to see the chart of Emacs's growing popularity on YouTube:

(require 'chart)
(chart-bar-quickie 'vertical "Popularity for term \"Emacs\" on Youtube"
		   '("2002" "2003" "2004" "2005" "2006" "2007" "2008" "2009" "2010"
		     "2011" "2012" "2013" "2014" "2015" "2016" "2017" "2018" "2019" "2020")
		   "Year"
		   '(0 0 0 1 54 124 135 75 16 65 59 93 73 86 169 179 162 199 208)
		   "Videos per year")

We say in and from Yugoslavia, if the "If the horn lies, the goat does not lie"

Jean


[-- Attachment #2: 2020-09-20-00:45:13.jpg --]
[-- Type: image/jpeg, Size: 78961 bytes --]

Re: How to make Emacs popular again.

[Jean Louis]

* James Lu <jamtlu@gmail.com> [2020-09-27 23:33]:
> Some things don't need to sacrifice existing users for new users:
> * Having the documentation organized nicely
> * Interactive things
> 
> For example, when I first wrote "DEADLINE:" under a todo in
> org-mode, why couldn't there be a pop-up poining me to a tutorial on
> how to sort by deadline?

If I may suggest Orgzly application for mobile phones:
https://f-droid.org/en/packages/com.orgzly/

It creates Org files and is excellent for note taking and creating Org
files on the go, later may be used by Emacs on desktop, even though
Emacs works on mobile phones as well.

Jean

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-27 10:54]:
> > Date: Sun, 27 Sep 2020 10:32:21 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: eliz@gnu.org, jamtlu@gmail.com, emacs-devel@gnu.org
> > 
> > Emacs should in general have an option under Tools -> Look up word
> 
> We have that under Help->Search Documentation.

Search documentation is separate feature from looking up any technical
or special word in glossary, and third feature would be looking up any
word in dictionaries.

Tools -> Look up word, it could provide looking up definitions in
dictionaries. At least one dictionary like GCIDE could be supported or
Wordnet, or both of them.

That way users will not get confused, they could quickly lookup any
word under cursor or mouse in dictionaries and would get empowered.

I am personall using dictionary servers straight from Emacs, {s-d} on
any word gives me helm completion, list of dictionaries I can choose
from, to find a definition, it runs these functions below, and {s-w}
runs (wordnut-search) from wordnut package, so definitions are
quickly there accessible. If we speak of text editing, we edit words,
words are defined and Emacs should have reference to dictionary for
each word, and fall back to online searches.

Jean


(setq dict/dictionaries
      '(
	("The Collaborative International Dictionary of English v.0.48" "gcide")
	("WordNet (r) 3.0 (2006)" "wn")
	("Moby Thesaurus II by Grady Ward, 1.0" "moby-thesaurus")
	("The Elements (07Nov00)" "elements")
	("vera" "V.E.R.A. -- Virtual Entity of Relevant Acronyms (September 2014)")
	("The Jargon File (version 4.4.7, 29 Dec 2003)" "jargon")
	("The Free On-line Dictionary of Computing (18 March 2015)" "foldoc")
	("Easton's 1897 Bible Dictionary" "easton")
	("Hitchcock's Bible Names Dictionary (late 1800's)" "hitchcock")
	("Bouvier's Law Dictionary, Revised 6th Ed (1856)" "bouvier")
	("The Devil's Dictionary (1881-1906)" "devil")
	("CIA World Factbook 2002" "world02")
	("U.S. Gazetteer Counties (2000)" "gaz2k-counties")
	("U.S. Gazetteer Places (2000)" "gaz2k-places")
	("U.S. Gazetteer Zip Code Tabulation Areas (2000)" "gaz2k-zips")
	("Turkish-English FreeDict Dictionary ver. 0.2.1" "fd-tur-eng")
	("Portuguese-German FreeDict Dictionary ver. 0.1.1" "fd-por-deu")
	("Dutch-English Freedict Dictionary ver. 0.1.3" "fd-nld-eng")
	("English-Arabic FreeDict Dictionary ver. 0.6.2" "fd-eng-ara")
	("Spanish-English FreeDict Dictionary ver. 0.1.1" "fd-spa-eng")
	("English-Hungarian FreeDict Dictionary ver. 0.1" "fd-eng-hun")
	("Italian-English FreeDict Dictionary ver. 0.1.1" "fd-ita-eng")
	("Welsh-English Freedict dictionary" "fd-wel-eng")
	("English-Dutch FreeDict Dictionary ver. 0.1.1" "fd-eng-nld")
	("French-English FreeDict Dictionary ver. 0.3.4" "fd-fra-eng")
	("Turkish-German FreeDict Dictionary ver. 0.1.1" "fd-tur-deu")
	("Swedish-English FreeDict Dictionary ver. 0.1.1" "fd-swe-eng")
	("Nederlands-French FreeDict Dictionary ver. 0.1.1" "fd-nld-fra")
	("English-Swahili xFried/FreeDict Dictionary" "fd-eng-swa")
	("German-Dutch FreeDict Dictionary ver. 0.1.1" "fd-deu-nld")
	("French-German FreeDict Dictionary ver. 0.1.1" "fd-fra-deu")
	("English-Croatian Freedict Dictionary" "fd-eng-cro")
	("English-Italian FreeDict Dictionary ver. 0.1.1" "fd-eng-ita")
	("English-Latin FreeDict Dictionary ver. 0.1.1" "fd-eng-lat")
	("Latin-English FreeDict Dictionary ver. 0.1.1" "fd-lat-eng")
	("French-Dutch FreeDict Dictionary ver. 0.1.2" "fd-fra-nld")
	("Italian-German FreeDict Dictionary ver. 0.1.1" "fd-ita-deu")
	("English-Hindi FreeDict Dictionary ver. 1.5.1" "fd-eng-hin")
	("German-English FreeDict Dictionary ver. 0.3.4" "fd-deu-eng")
	("Portuguese-English FreeDict Dictionary ver. 0.1.1" "fd-por-eng")
	("Latin - German FreeDict dictionary ver. 0.4" "fd-lat-deu")
	("Japanese-German FreeDict Dictionary ver. 0.1.1" "fd-jpn-deu")
	("English-German FreeDict Dictionary ver. 0.3.6" "fd-eng-deu")
	("English-Serbo-Croat Freedict dictionary" "fd-eng-scr")
	("English-Romanian FreeDict Dictionary ver. 0.6.1" "fd-eng-rom")
	("Irish-English Freedict dictionary" "fd-iri-eng")
	("Czech-English Freedict dictionary" "fd-cze-eng")
	("Serbo-Croat-English Freedict dictionary" "fd-scr-eng")
	("English-Czech fdicts/FreeDict Dictionary" "fd-eng-cze")
	("English-Russian FreeDict Dictionary ver. 0.3" "fd-eng-rus")
	("Afrikaans-German FreeDict Dictionary ver. 0.3" "fd-afr-deu")
	("English-Portuguese FreeDict Dictionary ver. 0.2.2" "fd-eng-por")
	("Hungarian-English FreeDict Dictionary ver. 0.3.1" "fd-hun-eng")
	("English-Swedish FreeDict Dictionary ver. 0.1.1" "fd-eng-swe")
	("German-Italian FreeDict Dictionary ver. 0.1.1" "fd-deu-ita")
	("Croatian-English Freedict Dictionary" "fd-cro-eng")
	("Danish-English FreeDict Dictionary ver. 0.2.1" "fd-dan-eng")
	("English-Turkish FreeDict Dictionary ver. 0.2.1" "fd-eng-tur")
	("English-Spanish FreeDict Dictionary ver. 0.2.1" "fd-eng-spa")
	("Dutch-German FreeDict Dictionary ver. 0.1.1" "fd-nld-deu")
	("German-Portuguese FreeDict Dictionary ver. 0.2.1" "fd-deu-por")
	("Swahili-English xFried/FreeDict Dictionary" "fd-swa-eng")
	("English-Hindi Freedict Dictionary [reverse index]" "fd-hin-eng")
	("German-French FreeDict Dictionary ver. 0.3.1" "fd-deu-fra")
	("English-French FreeDict Dictionary ver. 0.1.4" "fd-eng-fra")
	("Slovak-English Freedict dictionary" "fd-slo-eng")
	("Scottish Gaelic-German FreeDict Dictionary ver. 0.1.1" "fd-gla-deu")
	("English-Welsh Freedict dictionary" "fd-eng-wel")
	("English-Irish Freedict dictionary" "fd-eng-iri")
	("English Monolingual Dictionaries" "english")
	("Translating Dictionaries" "trans")
	("All Dictionaries (English-Only and Translating)" "all")))

(setq dict/buffer "*Dict*")

(defun tmpbuf (buf)
  (switch-to-buffer
   (get-buffer-create (concat "*" buf "*"))))

(defun dict/kill-dict ()
  (interactive)
  (kill-buffer dict/buffer))

(defun dictd-dictionaries (&optional host)
  "Returns the list of dictionaries and their names"
  (let* ((command (if host (format "dict -D -h %s" host) "dict -D"))
	 (dictionaries (shell-command-to-string command))
	 (dictionaries (split-string dictionaries "\n")))
    (pop dictionaries)
    (mapcar 'string-trim dictionaries)))

(defun dict/query ()
  (interactive)
  (let* ((word (current-word 1))
	 (dictionary (helm-comp-read  "Dictionary: " (dictd-dictionaries)))
	 (dictionary (first (split-string dictionary)))
	 (dict (format "dict -d %s \"%s\"" dictionary word))
	 (statement (shell-command-to-string dict)))
    (get-buffer-create dict/buffer)
    (switch-to-buffer dict/buffer)
    (local-set-key (kbd "q") 'dict/kill-dict)
    (local-set-key (kbd "<return>") 'dict/query)
    (insert statement)
    (goto-char 1)))

(global-set-key (kbd "s-d") 'dict/query)

Re: How to make Emacs popular again.

[Dmitry Gutov]

On 28.09.2020 06:45, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > Here's a simple example:
> 
>    > https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00842.html
> 
> Referring to messages that way is inconvenient for me.  The message is
> in my saved mail, but I cannot find it with that info.  Would you
> please send message IDs instead?  I can search for that.

Too bad. Perhaps the generated HTML should include something unique in 
the urls to help refer to. Not sure what, though. You can't easily read 
a website. My email client can't search by message ID.

Anyway, here it is: <d9c671f2-dfa1-ffdd-f501-83c143d350e7@yandex.ru>

See this and the preceding thread.

>    > BTW, my last personal email to you has seen no response. Were you too
>    > busy, or is there some delivery problem, maybe?
> 
> Sorry, I don't remember.  I don't remember things like that for very
> long nowadays.  If it was important, ask me again.

OK, will do.

Re: How to make Emacs popular again.

[Eduardo Ochs]

Here's how to check the dict entries for a word if you have eev
installed. Type

  dict buffer

in a line by itself, and then type `M-S' (meta-shift-s). The `M-S'
wraps the contents of the current line in a:

  # (find-sh "...")

so the line becomes:

  # (find-sh "dict buffer")

which is an elisp hyperlink to the output of running "dict buffer" on
a shell. In this case the FOLDOC entry is the most relevant one, so I
will usually duplicate and refine that hyperlink, to obtain this:

  # (find-sh "dict buffer")
  # (find-sh "dict buffer" "[foldoc]")

For more info:

  http://angg.twu.net/emacsconf2019.html
  http://angg.twu.net/eev-intros/find-eev-quick-intro.html#3
  http://angg.twu.net/eev-intros/find-refining-intro.html
  https://www.youtube.com/watch?v=86yiRG8YJD0&t=841

Cheers,
  Eduardo Ochs

On Mon, 28 Sep 2020 at 20:31, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 28.09.2020 06:45, Richard Stallman wrote:
> > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> > [[[ whether defending the US Constitution against all enemies,     ]]]
> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> >
> >    > Here's a simple example:
> >
> >    > https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00842.html
> >
> > Referring to messages that way is inconvenient for me.  The message is
> > in my saved mail, but I cannot find it with that info.  Would you
> > please send message IDs instead?  I can search for that.
>
> Too bad. Perhaps the generated HTML should include something unique in
> the urls to help refer to. Not sure what, though. You can't easily read
> a website. My email client can't search by message ID.
>
> Anyway, here it is: <d9c671f2-dfa1-ffdd-f501-83c143d350e7@yandex.ru>
>
> See this and the preceding thread.
>
> >    > BTW, my last personal email to you has seen no response. Were you too
> >    > busy, or is there some delivery problem, maybe?
> >
> > Sorry, I don't remember.  I don't remember things like that for very
> > long nowadays.  If it was important, ask me again.
>
> OK, will do.
>

Re: tooltip feature

[chad]

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

On Sun, Sep 27, 2020 at 9:08 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> [...] an alternative would be to provide
> a command which will catch the content of the next tooltip (and
> e.g. put it into the kill-ring).
>

Peeking at tooltip.el, it looks quite easy to have tooltip text sent to
*Messages* or similar (*Tooltips*?), perhaps based on a global minor mode.
I don't personally use tooltips enough to know if that might cause
troubles or high overhead. Can someone suggest a reasonable test case where
I would get a lot of tooltips?

Thanks,
~Chad

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

Re: How to make Emacs popular again.

[Kévin Le Gouguec]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 28.09.2020 06:45, Richard Stallman wrote:
>>    > Here's a simple example:
>>    >
>> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00842.html
>> Referring to messages that way is inconvenient for me.  The message
>> is
>> in my saved mail, but I cannot find it with that info.  Would you
>> please send message IDs instead?  I can search for that.
>
> Too bad. Perhaps the generated HTML should include something unique in
> the urls to help refer to. Not sure what, though. You can't easily
> read a website. My email client can't search by message ID.

FWIW, public-inbox includes message IDs both in URLs and among the
headers displayed on the page[1].  See for example:

https://orgmode.org/list/E1kIPh1-0001Lu-Rg@fencepost.gnu.org/


For lists.gnu.org archives, in case that helps anyone, here is what I
use to automate the "MHonArc URL → message ID" translation:

#+begin_src elisp
(defun mhonarc-to-messageid (url)
  "Retrieve the Message-ID from an article archived on MHonArc."
  (interactive
   (list
    (let* ((default (or (thing-at-point-url-at-point)
                        (and (derived-mode-p 'eww-mode)
                             (shr-url-at-point nil))))
           (prompt (if default
                       (format "URL? (%s) " default)
                     "URL? ")))
      (read-string prompt nil nil default))))
  (with-current-buffer (url-retrieve-synchronously url)
    (search-forward-regexp "^<!--X-Message-Id: \\(.+\\) -->$")
    (message (xml-substitute-numeric-entities (match-string 1)))))
#+end_src

(Requires being online, of course.)


[1] Among other nice qualities (comes with an NNTP server, can display
    all messages in a thread on a single HTML page, licensed under the
    AGPL).  Sales pitch over at:
    https://public-inbox.org/public-inbox.git/about/

Re: How to make Emacs popular again.

[Robert Pluim]

>>>>> On Tue, 29 Sep 2020 10:08:45 +0200, Kévin Le Gouguec <kevin.legouguec@gmail.com> said:
    Kévin> [1] Among other nice qualities (comes with an NNTP server, can display
    Kévin>     all messages in a thread on a single HTML page, licensed under the
    Kévin>     AGPL).  Sales pitch over at:
    Kévin>     https://public-inbox.org/public-inbox.git/about/

And can be updated via git, rather than some dodgy wget alias Iʼve got
lying around somewhere :-)

Robert
-- 

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Tue, 29 Sep 2020 01:25:17 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, jamtlu@gmail.com, emacs-devel@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2020-09-27 10:54]:
> > > Date: Sun, 27 Sep 2020 10:32:21 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: eliz@gnu.org, jamtlu@gmail.com, emacs-devel@gnu.org
> > > 
> > > Emacs should in general have an option under Tools -> Look up word
> > 
> > We have that under Help->Search Documentation.
> 
> Search documentation is separate feature from looking up any technical
> or special word in glossary

No, I think it's quite related, especially since the Glossary is part
of the manual.

> and third feature would be looking up any word in dictionaries.

That's an almost unrelated feature.  Useful, but unrelated to the
current discussion.  Let's not mix them.

> I am personall using dictionary servers straight from Emacs, {s-d} on
> any word gives me helm completion, list of dictionaries I can choose
> from, to find a definition, it runs these functions below, and {s-w}
> runs (wordnut-search) from wordnut package, so definitions are
> quickly there accessible. If we speak of text editing, we edit words,
> words are defined and Emacs should have reference to dictionary for
> each word, and fall back to online searches.

I'd rather have Emacs implement the client side of the DICT protocol,
it shouldn't be too hard.  Especially people already tried (there are
packages floating out there).  Depending on an external tool makes the
solution less portable.

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-29 17:12]:
> > Search documentation is separate feature from looking up any technical
> > or special word in glossary
> 
> No, I think it's quite related, especially since the Glossary is part
> of the manual.

It is related. Let me express myself better, I am proposing a
function, something like a long click or key press that is then
searching in the glossary. Maybe underlying Lisp functions can be used
for that feature.

> > I am personall using dictionary servers straight from Emacs, {s-d} on
> > any word gives me helm completion, list of dictionaries I can choose
> > from, to find a definition, it runs these functions below, and {s-w}
> > runs (wordnut-search) from wordnut package, so definitions are
> > quickly there accessible. If we speak of text editing, we edit words,
> > words are defined and Emacs should have reference to dictionary for
> > each word, and fall back to online searches.
> 
> I'd rather have Emacs implement the client side of the DICT protocol,
> it shouldn't be too hard.  Especially people already tried (there are
> packages floating out there).  Depending on an external tool makes the
> solution less portable.

That would be great tool in Emacs, it would make it powerful teaching tool.

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Hold your horses!  I am concerned that promoting 'dict' is going in
the wrong direction.  I don't know all the facts, so I won't assert
that it is a problem; but we need to check.

The program 'dict' seems to be intended to access dictionaries on
internet servers.  Probably on servers that don't belong to the user.

Does it have the ability to use a locally stored dictionary?  That's
what we should encourage -- not dependence on servers by default.

'dict -D' gave me a list of dictionaries that the program knows about.
I presume these are found on various servers.  It does not say what their
licenses are.  Which of those dictionaries is downloadable with
a free license?

There IS a free English dictionary that people can download.  It is
Wiktionary, packaged by kiwix.  It uses a special format, .zim, that
is compact and suitable for searching.  That project packages
Wiktionary for various languages.

Does the dict program have the ability to access a dictionary
in that format?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Too bad. Perhaps the generated HTML should include something unique in 
  > the urls to help refer to. Not sure what, though. You can't easily read 
  > a website. My email client can't search by message ID.

  > Anyway, here it is: <d9c671f2-dfa1-ffdd-f501-83c143d350e7@yandex.ru>

Thanks.

ANY text from the message itself will enable me to find it.  The date
field, the subject, the message IS, the first line of body, if it is
text in the message and within one line, I can grep for it.
The web interface URLs are the only way I can't use.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Eduardo Ochs]

Hi Richard,

try:

  sudo apt-get install dict dictd
  sudo apt-get install dict-gcide dict-jargon dict-wn dict-foldoc
  dict smop

in the setting that I get in my machines after doing that the "dict"
client only accesses the locally installed dictionaries, and AFAICT
the licenses of all these programs and data files are public domain,
(L)GPL, BSD, or WordNet3.0.

  [[]], E.

On Wed, 30 Sep 2020 at 01:37, Richard Stallman <rms@gnu.org> wrote:
>
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Hold your horses!  I am concerned that promoting 'dict' is going in
> the wrong direction.  I don't know all the facts, so I won't assert
> that it is a problem; but we need to check.
>
> The program 'dict' seems to be intended to access dictionaries on
> internet servers.  Probably on servers that don't belong to the user.
>
> Does it have the ability to use a locally stored dictionary?  That's
> what we should encourage -- not dependence on servers by default.
>
> 'dict -D' gave me a list of dictionaries that the program knows about.
> I presume these are found on various servers.  It does not say what their
> licenses are.  Which of those dictionaries is downloadable with
> a free license?
>
> There IS a free English dictionary that people can download.  It is
> Wiktionary, packaged by kiwix.  It uses a special format, .zim, that
> is compact and suitable for searching.  That project packages
> Wiktionary for various languages.
>
> Does the dict program have the ability to access a dictionary
> in that format?
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>

Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-09-30 07:51]:
> Hold your horses!  I am concerned that promoting 'dict' is going in
> the wrong direction.  I don't know all the facts, so I won't assert
> that it is a problem; but we need to check.
> 
> The program 'dict' seems to be intended to access dictionaries on
> internet servers.  Probably on servers that don't belong to the user.
> 
> Does it have the ability to use a locally stored dictionary?  That's
> what we should encourage -- not dependence on servers by default.

Yes, it has ability to access local servers, at my Hyperbola
GNU/Linux-libre the package dictd was (probably) so configured to try
localhost first. On many other GNU/Linux systems, dictionaries can be
easier downloaded and installed on local system.

> 'dict -D' gave me a list of dictionaries that the program knows about.
> I presume these are found on various servers.  It does not say what their
> licenses are.  Which of those dictionaries is downloadable with
> a free license?

Yes, they have all free licenses.

dict-bouvier - John Bouvier's Law Dictionary for the USA
dict-devil - "The Devil's Dictionary" by Ambrose Bierce
dict-elements - Data regarding the Elements
dict-foldoc - FOLDOC dictionary database
dict-gcide - Comprehensive English Dictionary
dict-jargon - dict package for The Jargon Lexicon
dict-moby-thesaurus - Largest and most comprehensive thesaurus
dict-de-en - German-English translation dictionary for dictd
dict-freedict-afr-deu - Afrikaans-German dictionary for the dict server/client
dict-freedict-afr-eng - Afrikaans-English dictionary for the dict server/client
dict-freedict-ara-eng - Arabic-English dictionary for the dict server/client
dict-freedict-bre-fra - Breton-French dictionary for the dict server/client
dict-freedict-ces-eng - Czech-English dictionary for the dict server/client
dict-freedict-ckb-kmr - Central Kurdish-Northern Kurdish dictionary for the dict server/client
dict-freedict-cym-eng - Welsh-English dictionary for the dict server/client
dict-freedict-dan-eng - Danish-English dictionary for the dict server/client
dict-freedict-deu-eng - German-English dictionary for the dict server/client
dict-freedict-deu-ita - German-Italian dictionary for the dict server/client
dict-freedict-deu-kur - German-Kurdish dictionary for the dict server/client
dict-freedict-deu-nld - German-Dutch dictionary for the dict server/client
dict-freedict-deu-por - German-Portuguese dictionary for the dict server/client
dict-freedict-deu-tur - German-Turkish dictionary for the dict server/client
dict-freedict-eng-afr - English-Afrikaans dictionary for the dict server/client
dict-freedict-eng-ara - English-Arabic dictionary for the dict server/client
dict-freedict-eng-ces - English-Czech dictionary for the dict server/client
dict-freedict-eng-cym - English-Welsh dictionary for the dict server/client
dict-freedict-eng-deu - English-German dictionary for the dict server/client
dict-freedict-eng-ell - English-Modern Greek (1453-) dictionary for the dict server/client
dict-freedict-eng-fra - English-French dictionary for the dict server/client
dict-freedict-eng-gle - English-Irish dictionary for the dict server/client
dict-freedict-eng-hin - English-Hindi dictionary for the dict server/client
dict-freedict-eng-hrv - English-Croatian dictionary for the dict server/client
dict-freedict-eng-hun - English-Hungarian dictionary for the dict server/client
dict-freedict-eng-ita - English-Italian dictionary for the dict server/client
dict-freedict-eng-lat - English-Latin dictionary for the dict server/client
dict-freedict-eng-lit - English-Lithuanian dictionary for the dict server/client
dict-freedict-eng-nld - English-Dutch dictionary for the dict server/client
dict-freedict-eng-pol - English-Polish dictionary for the dict server/client
dict-freedict-eng-por - English-Portuguese dictionary for the dict server/client
dict-freedict-eng-rom - English-Romany dictionary for the dict server/client
dict-freedict-eng-rus - English-Russian dictionary for the dict server/client
dict-freedict-eng-spa - English-Spanish dictionary for the dict server/client
dict-freedict-eng-srp - English-Serbian dictionary for the dict server/client
dict-freedict-eng-swe - English-Swedish dictionary for the dict server/client
dict-freedict-eng-swh - English-Swahili (individual language) dictionary for the dict server/client
dict-freedict-eng-tur - English-Turkish dictionary for the dict server/client
dict-freedict-epo-eng - Esperanto-English dictionary for the dict server/client
dict-freedict-fra-bre - French-Breton dictionary for the dict server/client
dict-freedict-fra-eng - French-English dictionary for the dict server/client
dict-freedict-fra-nld - French-Dutch dictionary for the dict server/client
dict-freedict-gla-deu - Scottish Gaelic-German dictionary for the dict server/client
dict-freedict-gle-eng - Irish-English dictionary for the dict server/client
dict-freedict-gle-pol - Irish-Polish dictionary for the dict server/client
dict-freedict-hrv-eng - Croatian-English dictionary for the dict server/client
dict-freedict-hun-eng - Hungarian-English dictionary for the dict server/client
dict-freedict-isl-eng - Icelandic-English dictionary for the dict server/client
dict-freedict-ita-deu - Italian-German dictionary for the dict server/client
dict-freedict-ita-eng - Italian-English dictionary for the dict server/client
dict-freedict-jpn-deu - Japanese-German dictionary for the dict server/client
dict-freedict-jpn-eng - Japanese-English dictionary for the dict server/client
dict-freedict-jpn-fra - Japanese-French dictionary for the dict server/client
dict-freedict-jpn-rus - Japanese-Russian dictionary for the dict server/client
dict-freedict-kha-deu - Khasi-German dictionary for the dict server/client
dict-freedict-kha-eng - Khasi-English dictionary for the dict server/client
dict-freedict-kur-deu - Kurdish-German dictionary for the dict server/client
dict-freedict-kur-eng - Kurdish-English dictionary for the dict server/client
dict-freedict-kur-tur - Kurdish-Turkish dictionary for the dict server/client
dict-freedict-lat-deu - Latin-German dictionary for the dict server/client
dict-freedict-lat-eng - Latin-English dictionary for the dict server/client
dict-freedict-lit-eng - Lithuanian-English dictionary for the dict server/client
dict-freedict-mkd-bul - Macedonian-Bulgarian dictionary for the dict server/client
dict-freedict-nld-deu - Dutch-German dictionary for the dict server/client
dict-freedict-nld-eng - Dutch-English dictionary for the dict server/client
dict-freedict-nld-fra - Dutch-French dictionary for the dict server/client
dict-freedict-nno-nob - Norwegian Nynorsk-Norwegian Bokmål dictionary for the dict server/client
dict-freedict-oci-cat - Occitan (post 1500)-Catalan dictionary for the dict server/client
dict-freedict-pol-gle - Polish-Irish dictionary for the dict server/client
dict-freedict-por-deu - Portuguese-German dictionary for the dict server/client
dict-freedict-por-eng - Portuguese-English dictionary for the dict server/client
dict-freedict-san-deu - Sanskrit-German dictionary for the dict server/client
dict-freedict-slk-eng - Slovak-English dictionary for the dict server/client
dict-freedict-spa-ast - Spanish-Asturian dictionary for the dict server/client
dict-freedict-spa-deu - Spanish-German dictionary for the dict server/client
dict-freedict-spa-eng - Spanish-English dictionary for the dict server/client
dict-freedict-spa-por - Spanish-Portuguese dictionary for the dict server/client
dict-freedict-srp-eng - Serbian-English dictionary for the dict server/client
dict-freedict-swe-eng - Swedish-English dictionary for the dict server/client
dict-freedict-swh-eng - Swahili (individual language)-English dictionary for the dict server/client
dict-freedict-swh-pol - Swahili (individual language)-Polish dictionary for the dict server/client
dict-freedict-tur-deu - Turkish-German dictionary for the dict server/client
dict-freedict-tur-eng - Turkish-English dictionary for the dict server/client
dict-freedict-wol-fra - Wolof-French dictionary for the dict server/client
dict-freedict-deu-bul - German-Bulgarian dictionary for the dict server/client
dict-freedict-deu-fra - German-French dictionary for the dict server/client
dict-freedict-deu-pol - German-Polish dictionary for the dict server/client
dict-freedict-deu-rus - German-Russian dictionary for the dict server/client
dict-freedict-deu-spa - German-Spanish dictionary for the dict server/client
dict-freedict-deu-swe - German-Swedish dictionary for the dict server/client
dict-freedict-eng-bul - English-Bulgarian dictionary for the dict server/client
dict-freedict-eng-fin - English-Finnish dictionary for the dict server/client
dict-freedict-eng-jpn - English-Japanese dictionary for the dict server/client
dict-freedict-fin-bul - Finnish-Bulgarian dictionary for the dict server/client
dict-freedict-fin-ell - Finnish-Modern Greek (1453-) dictionary for the dict server/client
dict-freedict-fin-eng - Finnish-English dictionary for the dict server/client
dict-freedict-fin-ita - Finnish-Italian dictionary for the dict server/client
dict-freedict-fin-jpn - Finnish-Japanese dictionary for the dict server/client
dict-freedict-fin-nor - Finnish-Norwegian dictionary for the dict server/client
dict-freedict-fin-por - Finnish-Portuguese dictionary for the dict server/client
dict-freedict-fin-swe - Finnish-Swedish dictionary for the dict server/client
dict-freedict-fra-bul - French-Bulgarian dictionary for the dict server/client
dict-freedict-fra-deu - French-German dictionary for the dict server/client
dict-freedict-fra-ell - French-Modern Greek (1453-) dictionary for the dict server/client
dict-freedict-fra-fin - French-Finnish dictionary for the dict server/client
dict-freedict-fra-ita - French-Italian dictionary for the dict server/client
dict-freedict-fra-jpn - French-Japanese dictionary for the dict server/client
dict-freedict-fra-pol - French-Polish dictionary for the dict server/client
dict-freedict-fra-por - French-Portuguese dictionary for the dict server/client
dict-freedict-fra-rus - French-Russian dictionary for the dict server/client
dict-freedict-fra-spa - French-Spanish dictionary for the dict server/client
dict-freedict-fra-swe - French-Swedish dictionary for the dict server/client
dict-freedict-fra-tur - French-Turkish dictionary for the dict server/client
dict-freedict-ita-ell - Italian-Modern Greek (1453-) dictionary for the dict server/client
dict-freedict-ita-fin - Italian-Finnish dictionary for the dict server/client
dict-freedict-ita-jpn - Italian-Japanese dictionary for the dict server/client
dict-freedict-ita-pol - Italian-Polish dictionary for the dict server/client
dict-freedict-ita-por - Italian-Portuguese dictionary for the dict server/client
dict-freedict-ita-rus - Italian-Russian dictionary for the dict server/client
dict-freedict-ita-swe - Italian-Swedish dictionary for the dict server/client
dict-freedict-nld-ita - Dutch-Italian dictionary for the dict server/client
dict-freedict-nld-spa - Dutch-Spanish dictionary for the dict server/client
dict-freedict-nld-swe - Dutch-Swedish dictionary for the dict server/client
dict-freedict-pol-deu - Polish-German dictionary for the dict server/client
dict-freedict-pol-ell - Polish-Modern Greek (1453-) dictionary for the dict server/client
dict-freedict-pol-eng - Polish-English dictionary for the dict server/client
dict-freedict-pol-fin - Polish-Finnish dictionary for the dict server/client
dict-freedict-pol-fra - Polish-French dictionary for the dict server/client
dict-freedict-pol-ita - Polish-Italian dictionary for the dict server/client
dict-freedict-pol-nld - Polish-Dutch dictionary for the dict server/client
dict-freedict-pol-nor - Polish-Norwegian dictionary for the dict server/client
dict-freedict-pol-por - Polish-Portuguese dictionary for the dict server/client
dict-freedict-pol-rus - Polish-Russian dictionary for the dict server/client
dict-freedict-pol-spa - Polish-Spanish dictionary for the dict server/client
dict-freedict-pol-swe - Polish-Swedish dictionary for the dict server/client
dict-freedict-por-spa - Portuguese-Spanish dictionary for the dict server/client
dict-freedict-swe-bul - Swedish-Bulgarian dictionary for the dict server/client
dict-freedict-swe-deu - Swedish-German dictionary for the dict server/client
dict-freedict-swe-ell - Swedish-Modern Greek (1453-) dictionary for the dict server/client
dict-freedict-swe-fin - Swedish-Finnish dictionary for the dict server/client
dict-freedict-swe-fra - Swedish-French dictionary for the dict server/client
dict-freedict-swe-ita - Swedish-Italian dictionary for the dict server/client
dict-freedict-swe-lat - Swedish-Latin dictionary for the dict server/client
dict-freedict-swe-pol - Swedish-Polish dictionary for the dict server/client
dict-freedict-swe-por - Swedish-Portuguese dictionary for the dict server/client
dict-freedict-swe-rus - Swedish-Russian dictionary for the dict server/client
dict-freedict-swe-spa - Swedish-Spanish dictionary for the dict server/client
dict-freedict-swe-tur - Swedish-Turkish dictionary for the dict server/client
mueller7-dict - Mueller English/Russian dictionary in dict format
mueller7accent-dict - Mueller English/Russian dictionary with accents in dict format
dict-vera - Dictionary of computer related acronyms -- dict format
dict-wn - electronic lexical database of English language for dict

So all those can be downloaded on local server, it could be simple
task of one minute or more depending of the bandwidth.

> There IS a free English dictionary that people can download.  It is
> Wiktionary, packaged by kiwix.  It uses a special format, .zim, that
> is compact and suitable for searching.  That project packages
> Wiktionary for various languages.

I do not think it is standardized for dictd protocol, but I am not
sure.

I cannot easily find anythin:
https://dumps.wikimedia.org/enwiktionary/latest/ and if there is no
implementation for RFC 2229 protocol, its function remains more or
less browser based.

> Does the dict program have the ability to access a dictionary
> in that format?

Better said, does the Wiktionary provide the dict format.

I prefer using GNU dico first, before dict:

Package: dico
Version: 2.9-5
Description-en: RFC 2229 compliant dictionary client
 GNU Dico is an implementation of the DICT protocol as defined in RFC 2229.
 It is fully modular: the daemon itself (dicod) provides only the server
 functionality, and knows nothing about database formats. Actual searches
 are performed by functions supplied in loadable modules. A single module
 can serve one or more databases.
 .
 This package contains the dico console client.

Homepage: https://puszcza.gnu.org.ua/software/dico/

Reference: https://tools.ietf.org/html/rfc2229

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

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 30 Sep 2020 00:37:33 -0400
> Cc: philipk@posteo.net, emacs-devel@gnu.org, spacibba@aol.com, jamtlu@gmail.com,
>  dgutov@yandex.ru
> 
> There IS a free English dictionary that people can download.  It is
> Wiktionary, packaged by kiwix.  It uses a special format, .zim, that
> is compact and suitable for searching.  That project packages
> Wiktionary for various languages.
> 
> Does the dict program have the ability to access a dictionary
> in that format?

This site seems to offer a gateway between Wiktionary and DICT
clients:

   https://hewgill.com/dict/

Re: How to make Emacs popular again.

[Juri Linkov]

> - I press {C-h k} and then choose Tools -> Search Files (Grep)...
>
> Side comment: if it runs "grep" command, I don't know why it is
> capitalized, but alright.

Initially GREP was an abbreviation, short for "Get REPresentation".
I learned about the meaning of GREP abbreviation from this implementation:
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/decus/rsx88b/373230/

As a command "grep" should be in lower case indeed.  But OTOH,
on the menu all words are in title case (except for minor words):
https://en.wikipedia.org/wiki/Title_case

Re: How to make Emacs popular again.

[Mathias Dahl]

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

>
>
> Initially GREP was an abbreviation, short for "Get REPresentation".
> I learned about the meaning of GREP abbreviation from this implementation:
>
> http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/decus/rsx88b/373230/


Wikipedia says its name comes from the ed command g/re/p (globally search
for a regular expression and print matching lines).

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

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This site seems to offer a gateway between Wiktionary and DICT
  > clients:

  >    https://hewgill.com/dict/

Unfortunately, it is a "site", meaning a server you have to contact
over the internet.

The tendency to involve other people's computers in doing jobs that
you could do on your own computer is a fundamental wrong turning in
computing practice.  'dict' is an example of this problem.

We need to lead people away from that paradigm, not adapt our
activities to fit into it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Does it have the ability to use a locally stored dictionary?  That's
  > > what we should encourage -- not dependence on servers by default.

  > Yes, it has ability to access local servers, at my Hyperbola
  > GNU/Linux-libre the package dictd was (probably) so configured to try
  > localhost first.

This design partly assuages the problem but does not eliminate it.
With this design, referrihg to someone else's server is the natural
and easy way, and referring to data on your own machine is the hard way.

  > On many other GNU/Linux systems, dictionaries can be
  > easier downloaded and installed on local system.

When you do that, can 'dict' refer directly to the local copies?


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Better said, does the Wiktionary provide the dict format.

I have no idea, but if it doesn't, 'dict' doesn't do the job.

  > I prefer using GNU dico first, before dict:

What is the significant difference?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>> Yes, it has ability to access local servers, at my Hyperbola 
>> GNU/Linux-libre the package dictd was (probably) so configured to try 
>> localhost first.
>
> This design partly assuages the problem but does not eliminate it. With 
> this design, referrihg to someone else's server is the natural and easy 
> way, and referring to data on your own machine is the hard way.
>

On Debian at least, the default configuration is to try localhost first, 
and to try remote hosts (dict.org) if that fails.  The configuration file 
(/etc/dictd/dict.conf) indicates that it was last revised on 22 Nov 1998, 
so apparently it's a common default behavior.

>> On many other GNU/Linux systems, dictionaries can be easier downloaded 
>> and installed on local system.
>
> When you do that, can 'dict' refer directly to the local copies?
>

On Debian at least, yes:

# apt-get install dict dictd dict-wn
$ dict -v conflate
Configuration file:
    server localhost
    server dict.org
    server dict0.us.dict.org
    server alt0.dict.org
1 definition found

From WordNet (r) 3.0 (2006) [wn]:

   conflate
       v 1: mix together different elements; "The colors blend well"
            [syn: {blend}, {flux}, {mix}, {conflate}, {commingle},
            {immix}, {fuse}, {coalesce}, {meld}, {combine}, {merge}]

Re: How to make Emacs popular again.

[Philip K.]

Richard Stallman <rms@gnu.org> writes:

>   > On many other GNU/Linux systems, dictionaries can be
>   > easier downloaded and installed on local system.
>
> When you do that, can 'dict' refer directly to the local copies?

yes, you just have to start the dictd deamon locally and point the
client to localhost.

-- 
	Philip K.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, eduardoochs@gmail.com, spacibba@aol.com,
> 	emacs-devel@gnu.org, dgutov@yandex.ru, jamtlu@gmail.com
> Date: Thu, 01 Oct 2020 00:13:20 -0400
> 
>   >    https://hewgill.com/dict/
> 
> Unfortunately, it is a "site", meaning a server you have to contact
> over the internet.
> 
> The tendency to involve other people's computers in doing jobs that
> you could do on your own computer is a fundamental wrong turning in
> computing practice.  'dict' is an example of this problem.
> 
> We need to lead people away from that paradigm, not adapt our
> activities to fit into it.

I understand the general issue with using services, but in this case
the server just sends the description of a word taken from a
dictionary.  Aren't we a tad too radical, perhaps even extreme, in
this case?  It's not like the server calculates something that could
be subverted by a server we don't control.  What harm could be done by
looking up a word?  And how is it different from the command we have
that queries an Internet search engine (M-s M-w)?  Or from asking an
SMTP server to send an email message?

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-09-30 17:03]:
> > From: Richard Stallman <rms@gnu.org>
> > Date: Wed, 30 Sep 2020 00:37:33 -0400
> > Cc: philipk@posteo.net, emacs-devel@gnu.org, spacibba@aol.com, jamtlu@gmail.com,
> >  dgutov@yandex.ru
> > 
> > There IS a free English dictionary that people can download.  It is
> > Wiktionary, packaged by kiwix.  It uses a special format, .zim, that
> > is compact and suitable for searching.  That project packages
> > Wiktionary for various languages.
> > 
> > Does the dict program have the ability to access a dictionary
> > in that format?
> 
> This site seems to offer a gateway between Wiktionary and DICT
> clients:
> 
>    https://hewgill.com/dict/

That is great, but... the database for Wiktionary shall be made
available, I have asked Greg, webmaster, to tell me where is such.

Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-01 07:15]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > > Does it have the ability to use a locally stored dictionary?  That's
>   > > what we should encourage -- not dependence on servers by default.
> 
>   > Yes, it has ability to access local servers, at my Hyperbola
>   > GNU/Linux-libre the package dictd was (probably) so configured to try
>   > localhost first.
> 
> This design partly assuages the problem but does not eliminate it.
> With this design, referrihg to someone else's server is the natural
> and easy way, and referring to data on your own machine is the hard way.
> 
>   > On many other GNU/Linux systems, dictionaries can be
>   > easier downloaded and installed on local system.
> 
> When you do that, can 'dict' refer directly to the local copies?

Yes, it can. 

Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-01 07:15]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Better said, does the Wiktionary provide the dict format.
> 
> I have no idea, but if it doesn't, 'dict' doesn't do the job.
> 
>   > I prefer using GNU dico first, before dict:
> 
> What is the significant difference?

dico is GNU dico, that is why.

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-01 16:08]:
> > From: Richard Stallman <rms@gnu.org>
> > Cc: philipk@posteo.net, eduardoochs@gmail.com, spacibba@aol.com,
> > 	emacs-devel@gnu.org, dgutov@yandex.ru, jamtlu@gmail.com
> > Date: Thu, 01 Oct 2020 00:13:20 -0400
> > 
> >   >    https://hewgill.com/dict/
> > 
> > Unfortunately, it is a "site", meaning a server you have to contact
> > over the internet.
> > 
> > The tendency to involve other people's computers in doing jobs that
> > you could do on your own computer is a fundamental wrong turning in
> > computing practice.  'dict' is an example of this problem.
> > 
> > We need to lead people away from that paradigm, not adapt our
> > activities to fit into it.
> 
> I understand the general issue with using services, but in this case
> the server just sends the description of a word taken from a
> dictionary.  Aren't we a tad too radical, perhaps even extreme, in
> this case?  It's not like the server calculates something that could
> be subverted by a server we don't control.  What harm could be done by
> looking up a word?  And how is it different from the command we have
> that queries an Internet search engine (M-s M-w)?  Or from asking an
> SMTP server to send an email message?

As long as dict database of Wiktionary exists, as I think, by the
license, it should exist, so I have asked the webmaster to tell me
about that.

If the database does not exist, server can go down any time, and users
will be left in rain.

Relying on a server is not good, it is always better that local
dictionaries can be installed, it is cost efficient for a university,
school or any network to rely on their own computers, and not remote
computers.

Dictionary must be made accessible offline, just as paper dictionaries
are. 

Re: How to make Emacs popular again.

[Alfred M. Szmidt]

   >   >    https://hewgill.com/dict/
   > 
   > Unfortunately, it is a "site", meaning a server you have to contact
   > over the internet.
   > 
   > The tendency to involve other people's computers in doing jobs that
   > you could do on your own computer is a fundamental wrong turning in
   > computing practice.  'dict' is an example of this problem.
   > 
   > We need to lead people away from that paradigm, not adapt our
   > activities to fit into it.

   I understand the general issue with using services, but in this case
   the server just sends the description of a word taken from a
   dictionary.  

I think the specific problem in this case is that this specific site
is doing some type of conversion between the Wikitionary format to
something dict clients understand.  To quote part of the initial
message:

  > This site seems to offer a gateway between Wiktionary and DICT
  > clients:

But to put the blame on dict as the problem seems strange; it isn't
causing this and it is no different than finger, bug trackers, or even
just a plain wget.

Re: How to make Emacs popular again.

[Stefan Monnier]

> I understand the general issue with using services, but in this case
> the server just sends the description of a word taken from a
> dictionary.  Aren't we a tad too radical, perhaps even extreme, in
> this case?

FWIW, I tend to agree: the main reason for using a server is to avoid
having to *store* a local copy of all the dictionaries you might want
to use.  So I see it more like a remote storage than a remote service.

I do value highly having offline access to such info, which is why
I have local copies of some dictionaries, but I think this is more
a practical matter than an ethical one.

This said, it is a slippery slope and given the general current context
where we move every time more in the direction of relying on external
servers that are not under the control of the user, I do think we should
be careful not to encourage the use of such remote servers.

> It's not like the server calculates something that could
> be subverted by a server we don't control.

OTOH, there can be definite value in collecting the set of queries
a particular user performs.

> And how is it different from the command we have that queries an
> Internet search engine (M-s M-w)?

Indeed, the difference is fairly small (tho there's a clear practical
difference in that it's unrealistic to run your own search engine).

> Or from asking an SMTP server to send an email message?

That is quite different, since the whole purpose is to send a message
elsewhere, so there's just no way you could do it locally.


        Stefan

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Thu, 1 Oct 2020 17:39:29 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, philipk@posteo.net, eduardoochs@gmail.com,
>   spacibba@aol.com, emacs-devel@gnu.org, dgutov@yandex.ru,
>   jamtlu@gmail.com
> 
> As long as dict database of Wiktionary exists, as I think, by the
> license, it should exist, so I have asked the webmaster to tell me
> about that.
> 
> If the database does not exist, server can go down any time, and users
> will be left in rain.
> 
> Relying on a server is not good, it is always better that local
> dictionaries can be installed, it is cost efficient for a university,
> school or any network to rely on their own computers, and not remote
> computers.

I don't think this is the issue that bothers Richard.

Re: How to make Emacs popular again.

[James Lu]

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

Has anyone checked if Wiktionary's quality is good?

In my experience, Oxford dictionary are better than Meriam-Webster's
dictionary.

On Thu, Oct 1, 2020 at 10:08 AM Jean Louis <bugs@gnu.support> wrote:

> * Eli Zaretskii <eliz@gnu.org> [2020-09-30 17:03]:
> > > From: Richard Stallman <rms@gnu.org>
> > > Date: Wed, 30 Sep 2020 00:37:33 -0400
> > > Cc: philipk@posteo.net, emacs-devel@gnu.org, spacibba@aol.com,
> jamtlu@gmail.com,
> > >  dgutov@yandex.ru
> > >
> > > There IS a free English dictionary that people can download.  It is
> > > Wiktionary, packaged by kiwix.  It uses a special format, .zim, that
> > > is compact and suitable for searching.  That project packages
> > > Wiktionary for various languages.
> > >
> > > Does the dict program have the ability to access a dictionary
> > > in that format?
> >
> > This site seems to offer a gateway between Wiktionary and DICT
> > clients:
> >
> >    https://hewgill.com/dict/
>
> That is great, but... the database for Wiktionary shall be made
> available, I have asked Greg, webmaster, to tell me where is such.
>

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

Re: How to make Emacs popular again.

[James Lu]

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

macOS comes with a system dictionary.

Maybe the dictionary should be part of the GNU system, usable by any
userspace program, such as the other GNU operating system, Emacs.

On Thu, Oct 1, 2020 at 11:01 AM James Lu <jamtlu@gmail.com> wrote:

> Has anyone checked if Wiktionary's quality is good?
>
> In my experience, Oxford dictionary are better than Meriam-Webster's
> dictionary.
>
> On Thu, Oct 1, 2020 at 10:08 AM Jean Louis <bugs@gnu.support> wrote:
>
>> * Eli Zaretskii <eliz@gnu.org> [2020-09-30 17:03]:
>> > > From: Richard Stallman <rms@gnu.org>
>> > > Date: Wed, 30 Sep 2020 00:37:33 -0400
>> > > Cc: philipk@posteo.net, emacs-devel@gnu.org, spacibba@aol.com,
>> jamtlu@gmail.com,
>> > >  dgutov@yandex.ru
>> > >
>> > > There IS a free English dictionary that people can download.  It is
>> > > Wiktionary, packaged by kiwix.  It uses a special format, .zim, that
>> > > is compact and suitable for searching.  That project packages
>> > > Wiktionary for various languages.
>> > >
>> > > Does the dict program have the ability to access a dictionary
>> > > in that format?
>> >
>> > This site seems to offer a gateway between Wiktionary and DICT
>> > clients:
>> >
>> >    https://hewgill.com/dict/
>>
>> That is great, but... the database for Wiktionary shall be made
>> available, I have asked Greg, webmaster, to tell me where is such.
>>
>

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

Re: How to make Emacs popular again.

[tomas]

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

On Thu, Oct 01, 2020 at 05:39:29PM +0300, Jean Louis wrote:

[...]

> As long as dict database of Wiktionary exists, as I think, by the
> license, it should exist, so I have asked the webmaster to tell me
> about that.

I think all those questions are answered in their web pages. The
license(s) are here [1]. The download question is in the FAQ [2]:

"Q: Is it possible to download Wiktionary?

 A: Yes. https://dumps.wikimedia.org/enwiktionary/ should have
    the latest copy of the main namespace. The cleanest navigation
    page is https://dumps.wikimedia.org/. Just download a
    *-articles.xml.bz2 file and some software to read it (for
    *nix, for Windows).

(The "for *nix..." are actually links to software).

Cheers

[1] https://en.wiktionary.org/wiki/Wiktionary:About
[2] https://en.wiktionary.org/wiki/Help:FAQ#Downloading_Wiktionary

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: How to make Emacs popular again.

[tomas]

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

On Thu, Oct 01, 2020 at 11:01:14AM -0400, James Lu wrote:
> Has anyone checked if Wiktionary's quality is good?

It is. You, too, can make it even better :-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: How to make Emacs popular again.

[Stefan Monnier]

> Has anyone checked if Wiktionary's quality is good?

I use it fairly frequently.  I find it too terse, but otherwise it's not bad.


        Stefan

Re: How to make Emacs popular again.

[Jean Louis]

* James Lu <jamtlu@gmail.com> [2020-10-01 18:14]:
> Has anyone checked if Wiktionary's quality is good?
> 
> In my experience, Oxford dictionary are better than Meriam-Webster's
> dictionary.

Maybe linguists could answer. 

What would be important is to have Wiktionary in the RFC 2229 format,
just as mentioned on that site, but I could not find the database
file.

We have plethora of free dictionaries, and Wiktionary and others
outside of the scope of that format. Important is that we have it
free, it cannot be perfect, we can work on it through time.

GNU Dico - Re: How to make Emacs popular again.

[Jean Louis]

* James Lu <jamtlu@gmail.com> [2020-10-01 18:20]:
> macOS comes with a system dictionary.
> 
> Maybe the dictionary should be part of the GNU system, usable by any
> userspace program, such as the other GNU operating system, Emacs.

It is already part of GNU, there is GNU Dico:
https://puszcza.gnu.org.ua/software/dico/

It is official GNU project. GNU Dico is a flexible modular
implementation of DICT server (RFC 2229). In contrast to another
implementations, it does not depend on particular database format. GNU
Dico handles database accesses using loadable modules.

The package is shipped with quite a few modules thnat provide support
for the most often used database formats and strategies. New modules
can easily be written in C, Guile or Python. The module API is mature
and well documented.

The package also includes a console client program, that can be used
to query remote dictionary servers.

Thus GNU Dico is extensible for any type of dictionary access, for
this reason it is better than other dict/dictd software.

I prefer that Emacs dictionary function become adapted to use dico.

Jean

Re: How to make Emacs popular again.

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2020-10-01 18:20]:
> On Thu, Oct 01, 2020 at 05:39:29PM +0300, Jean Louis wrote:
> 
> [...]
> 
> > As long as dict database of Wiktionary exists, as I think, by the
> > license, it should exist, so I have asked the webmaster to tell me
> > about that.
> 
> I think all those questions are answered in their web pages. The
> license(s) are here [1]. The download question is in the FAQ [2]:
> 
> "Q: Is it possible to download Wiktionary?
> 
>  A: Yes. https://dumps.wikimedia.org/enwiktionary/ should have
>     the latest copy of the main namespace. The cleanest navigation
>     page is https://dumps.wikimedia.org/. Just download a
>     *-articles.xml.bz2 file and some software to read it (for
>     *nix, for Windows).
> 
> (The "for *nix..." are actually links to software).

I have tried that, I did not find RFC 2229 format there. When I
mentioned "dict database" I was referring to RFC 2229 standard. Do you
know the link to such database?

Re: How to make Emacs popular again.

[Jean Louis]

* Alfred M. Szmidt <ams@gnu.org> [2020-10-01 17:53]:
>    >   >    https://hewgill.com/dict/
>    > 
>    > Unfortunately, it is a "site", meaning a server you have to contact
>    > over the internet.
>    > 
>    > The tendency to involve other people's computers in doing jobs that
>    > you could do on your own computer is a fundamental wrong turning in
>    > computing practice.  'dict' is an example of this problem.
>    > 
>    > We need to lead people away from that paradigm, not adapt our
>    > activities to fit into it.
> 
>    I understand the general issue with using services, but in this case
>    the server just sends the description of a word taken from a
>    dictionary.  
> 
> I think the specific problem in this case is that this specific site
> is doing some type of conversion between the Wikitionary format to
> something dict clients understand.

That is alright for users, and I think, that type of output is then to
comply to free software license, so the source should be free.

Re: GNU Dico - Re: How to make Emacs popular again.

[Thibaut Verron]

Le jeu. 1 oct. 2020 à 18:25, Jean Louis <bugs@gnu.support> a écrit :
>
> * James Lu <jamtlu@gmail.com> [2020-10-01 18:20]:
> > macOS comes with a system dictionary.
> >
> > Maybe the dictionary should be part of the GNU system, usable by any
> > userspace program, such as the other GNU operating system, Emacs.
>
> It is already part of GNU, there is GNU Dico:
> https://puszcza.gnu.org.ua/software/dico/
>
> (...)
>
> I prefer that Emacs dictionary function become adapted to use dico.

Does it run on non GNU OS'es?

Re: How to make Emacs popular again.

[tomas]

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

On Thu, Oct 01, 2020 at 07:15:15PM +0300, Jean Louis wrote:
> * tomas@tuxteam.de <tomas@tuxteam.de> [2020-10-01 18:20]:
> > On Thu, Oct 01, 2020 at 05:39:29PM +0300, Jean Louis wrote:
> > 
> > [...]
> > 
> > > As long as dict database of Wiktionary exists, as I think, by the
> > > license, it should exist, so I have asked the webmaster to tell me
> > > about that.
> > 
> > I think all those questions are answered in their web pages. The
> > license(s) are here [1]. The download question is in the FAQ [2]:
> > 
> > "Q: Is it possible to download Wiktionary?
> > 
> >  A: Yes. https://dumps.wikimedia.org/enwiktionary/ should have
> >     the latest copy of the main namespace. The cleanest navigation
> >     page is https://dumps.wikimedia.org/. Just download a
> >     *-articles.xml.bz2 file and some software to read it (for
> >     *nix, for Windows).
> > 
> > (The "for *nix..." are actually links to software).
> 
> I have tried that, I did not find RFC 2229 format there. When I
> mentioned "dict database" I was referring to RFC 2229 standard. Do you
> know the link to such database?

Wait, RFC 2229 is a protocol description, not a storage format
description? So the wikimedia dump format would be irrelevant
here, I guess.

Related, but not quite on-topic, there seems to be an effort
towards providing a dict interface to the wiktionary itself,
so if you want to help there [1], I'm sure they'll appreciate.

Cheers

[1] https://strategy.wikimedia.org/wiki/Proposal:Dictionary_extensions

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Dico - Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Thu, 1 Oct 2020 19:13:07 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> I prefer that Emacs dictionary function become adapted to use dico.

Once again, I don't see any reason to use an external program for
these capabilities.  Emacs is perfectly capable of talking to servers
using built-in features.  Where did the server come from, whether it's
called dictd or dicod, doesn't matter.

Re: GNU Dico - Re: How to make Emacs popular again.

[Jean Louis]

* Thibaut Verron <thibaut.verron@gmail.com> [2020-10-01 19:30]:
> Le jeu. 1 oct. 2020 à 18:25, Jean Louis <bugs@gnu.support> a écrit :
> >
> > * James Lu <jamtlu@gmail.com> [2020-10-01 18:20]:
> > > macOS comes with a system dictionary.
> > >
> > > Maybe the dictionary should be part of the GNU system, usable by any
> > > userspace program, such as the other GNU operating system, Emacs.
> >
> > It is already part of GNU, there is GNU Dico:
> > https://puszcza.gnu.org.ua/software/dico/
> >
> > (...)
> >
> > I prefer that Emacs dictionary function become adapted to use dico.
> 
> Does it run on non GNU OS'es?

It runs, why not. It is GPL software.

Re: GNU Dico - Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-01 19:33]:
> > Date: Thu, 1 Oct 2020 19:13:07 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: rms@gnu.org, emacs-devel@gnu.org
> > 
> > I prefer that Emacs dictionary function become adapted to use dico.
> 
> Once again, I don't see any reason to use an external program for
> these capabilities.  Emacs is perfectly capable of talking to servers
> using built-in features.  Where did the server come from, whether it's
> called dictd or dicod, doesn't matter.

Oh, sorry, I get it.

Sure, dictionary.el is doing that, I looked inside, it is not using
any client command.

Yes, you are right.

Re: GNU Dico - Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-01 19:42]:
> > Date: Thu, 1 Oct 2020 19:13:07 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: rms@gnu.org, emacs-devel@gnu.org
> > 
> > I prefer that Emacs dictionary function become adapted to use dico.
> 
> Once again, I don't see any reason to use an external program for
> these capabilities.  Emacs is perfectly capable of talking to servers
> using built-in features.  Where did the server come from, whether it's
> called dictd or dicod, doesn't matter.

GNU Dico as server already offers wikimedia module that can use
Wiktionary as source, and thus offer to users. So everything is
solved from server side software, and it is already GNU project. We
have been discussing what already exists:

See:
https://puszcza.gnu.org.ua/software/dico/modules.html

From page:
==========

The package comes with the following database modules:

dictorg
This module provides full support for the format designed by the DICT development group. This is a de facto standard for DICT databases. A number of dictionary databases in this format are provided by the the FreeDict project.
wordnet
Provides search capabilities for WordNet -- a lexical database for the English language, created and maintained at the Cognitive Science Laboratory of Princeton University.
gcide
Interface to GNU Collaborative International Dictionary of English.
outline
Support for databases in Emacs outline format. This module is designed mostly as an example and for testing purposes.
guile
It is an abstract layer for interfacing with database modules written in Guile. Such databases are, for example, operational on Runasimi.org and Ellinika.gnu.org.ua.
python
It is an abstract layer for interfacing with database modules written in Python.
mediawiki
This module allows to use Wiktionary or Wikipedia as a dictionary database. The Dicoweb page offers several databases defined this way.
The following modules provide additional lookup strategies:

stratall
A pseudo-strategy which returns all headwords, no matter what the search key was.
substr
This strategy matches arbitrary substrings anywhere in the headword.
word
Provides search strategies for matching separate words within headwords: word, first, and last. The word strategy matches a word anywhere in a headword. The first and last strategies match a word at the beginning or at the end of a keyword, correspondingly.
nprefix
Provides a variant of the prefix strategy which returns the specified range of matching headwords.
metaphone2
Implements strategy based on Double Metaphone phonetic encoding algorithm.
pcre
Use Perl-compatible regular expressions for headword lookup.
The following modules provide storage for user authentication databases:

ldap
An engine for using LDAP schemas to keep user authentication information.
pam
Implements user authentication via Pluggable Authentication Modules (PAM).

Re: GNU Dico - Re: How to make Emacs popular again.

[Thibaut Verron]

Le jeu. 1 oct. 2020 à 18:51, Jean Louis <bugs@gnu.support> a écrit :
>
> * Eli Zaretskii <eliz@gnu.org> [2020-10-01 19:33]:
> > > Date: Thu, 1 Oct 2020 19:13:07 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: rms@gnu.org, emacs-devel@gnu.org
> > >
> > > I prefer that Emacs dictionary function become adapted to use dico.
> >
> > Once again, I don't see any reason to use an external program for
> > these capabilities.  Emacs is perfectly capable of talking to servers
> > using built-in features.  Where did the server come from, whether it's
> > called dictd or dicod, doesn't matter.
>
> Oh, sorry, I get it.
>
> Sure, dictionary.el is doing that, I looked inside, it is not using
> any client command.
>
> Yes, you are right.

And as a bonus, it should work out of the box on all systems that
Emacs supports (including Win32 and MacOS), without any dependency.
That was the point of my question above, which was definitely not
clear enough.

Re: How to make Emacs popular again.

[Juri Linkov]

>     Initially GREP was an abbreviation, short for "Get REPresentation".
>     I learned about the meaning of GREP abbreviation from this
>     implementation:
>     http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/decus/rsx88b/373230/
>
> Wikipedia says its name comes from the ed command g/re/p (globally search
> for a regular expression and print matching lines).

Ok, on Wikipedia is probably the original acronym.  All the rest are backronyms.

Re: How to make Emacs popular again.

[chad]

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

On Thu, Oct 1, 2020 at 8:14 AM James Lu <jamtlu@gmail.com> wrote:

> Has anyone checked if Wiktionary's quality is good?
>
> In my experience, Oxford dictionary are better than Meriam-Webster's
> dictionary.
>

My favorite professional editor tells me that in general, for English
definitions and usage, MW is preferred to the OED. OED is generally better
if you care specifically about etymology, but otherwise, MW has the edge
for usage, especially modern usage, as the OED is (deliberately) slower to
add words and update usages.

This is, of course, a very broad comparison, and both are good enough for
most people.

Hope that helps,
~Chad

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

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > sudo apt-get install dict dictd
    > sudo apt-get install dict-gcide dict-jargon dict-wn dict-foldoc
    > dict smop

Before I try this, would you please tell me what each of those
packages does?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > When you do that, can 'dict' refer directly to the local copies?

  > yes, you just have to start the dictd deamon locally and point the
  > client to localhost.

If any special configuration is needed to tell dict to look
at a local dictionary, that is bad design.  It should look for
a local dictionary by default.  Looking elsewhere should be
the special case.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   It's not like the server calculates something that could
  > be subverted by a server we don't control.  What harm could be done by
  > looking up a word?

The server could report that you did so.

                        And how is it different from the command we have
  > that queries an Internet search engine (M-s M-w)?

One difference is that you can, and should, have a local dictionary
and you can't have a local search engine.

Another difference is that you are likely to want to check definitions
very often, and searching less often.

                                                       Or from asking an
  > SMTP server to send an email message?

There are so many differences I don't have time to write them.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   > This site seems to offer a gateway between Wiktionary and DICT
  >   > clients:

  > But to put the blame on dict as the problem seems strange; it isn't
  > causing this and it is no different than finger, bug trackers, or even
  > just a plain wget.

I don't want to argue about whose fault it is.  The point is that
the lookup software should handle a format that we can download
Wikipedia in.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This said, it is a slippery slope and given the general current context
  > where we move every time more in the direction of relying on external
  > servers that are not under the control of the user, I do think we should
  > be careful not to encourage the use of such remote servers.

That's exactly the cconcern I have.

I am not opposed to supporting free software that can look up words in
remote dictionaries.  When you want to do that, we should offer you
free software for that -- and we do.

But we need to be careful about which direction we lead most users to
go.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > A: Yes. https://dumps.wikimedia.org/enwiktionary/ should have
   >    the latest copy of the main namespace. The cleanest navigation
   >    page is https://dumps.wikimedia.org/. Just download a
   >    *-articles.xml.bz2 file and some software to read it (for
   >    *nix, for Windows).

The version of WIkipedia I use is from kiwix.org, which uses the .zim
format.  I use that because there is a FRirefox add-on to do lookups
in it.

I don't know how these formats compare.  Maybe one is better than the other.
Maybe it is a toss-up.

it does not matter in principle which of these formats or software
can do local lookup in,  That is just a practical issue.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Eduardo Ochs]

In brief:

  dict        - dictionary client
  dictd       - dictionary server
  dict-gcide  - Comprehensive English Dictionary
  dict-jargon - dict package for The Jargon Lexicon
  dict-wn     - electronic lexical database of English language for dict
                ("WordNet(C) is an on-line lexical reference system...")
  dict-foldoc - FOLDOC dictionary database

I obtained that by running

  apt-cache show dict dictd dict-gcide dict-jargon dict-wn dict-foldoc
  apt-cache show dict dictd dict-gcide dict-jargon dict-wn dict-foldoc
| grep Description

and tinkering with the output a bit.

  Cheers,
    E.


On Fri, 2 Oct 2020 at 00:45, Richard Stallman <rms@gnu.org> wrote:
>
>     > sudo apt-get install dict dictd
>     > sudo apt-get install dict-gcide dict-jargon dict-wn dict-foldoc
>     > dict smop
>
> Before I try this, would you please tell me what each of those
> packages does?

Re: How to make Emacs popular again.

[Jean Louis]

None of them have free license, we need free information.

Am October 1, 2020 7:15:08 PM UTC schrieb chad <yandros@gmail.com>:
>On Thu, Oct 1, 2020 at 8:14 AM James Lu <jamtlu@gmail.com> wrote:
>
>> Has anyone checked if Wiktionary's quality is good?
>>
>> In my experience, Oxford dictionary are better than Meriam-Webster's
>> dictionary.
>>
>
>My favorite professional editor tells me that in general, for English
>definitions and usage, MW is preferred to the OED. OED is generally
>better
>if you care specifically about etymology, but otherwise, MW has the
>edge
>for usage, especially modern usage, as the OED is (deliberately) slower
>to
>add words and update usages.
>
>This is, of course, a very broad comparison, and both are good enough
>for
>most people.
>
>Hope that helps,
>~Chad

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, eduardoochs@gmail.com, spacibba@aol.com,
> 	emacs-devel@gnu.org, dgutov@yandex.ru, jamtlu@gmail.com
> Date: Thu, 01 Oct 2020 23:52:45 -0400
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   >   It's not like the server calculates something that could
>   > be subverted by a server we don't control.  What harm could be done by
>   > looking up a word?
> 
> The server could report that you did so.

That is something that should be known about a server, isn't it?  The
default dict.org server runs dictd, the server built from the
dict-1.12 package.  dict is a GPLed package and its source can be
scrutinized to see if anything like that is there.  The information
about the server is reachable from the dict.org home page,
www.dict.org.

>                         And how is it different from the command we have
>   > that queries an Internet search engine (M-s M-w)?
> 
> One difference is that you can, and should, have a local dictionary
> and you can't have a local search engine.

DICT servers usually use more than one dictionary.  The dict.org one
uses 12 of them (all free or PD, AFAIU), and that's even before you
count the dictionaries that translate between 2 languages.  It would
be unusual for a seasoned Emacs user to have all of them installed
locally.

> Another difference is that you are likely to want to check definitions
> very often, and searching less often.

I think it's the other way around.  I very rarely need to search for a
single word, and when I do, I can use "M-s M-w" to do that, because
search engines consult these dictionaries as well.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, philipk@posteo.net, eduardoochs@gmail.com,
> 	spacibba@aol.com, emacs-devel@gnu.org, dgutov@yandex.ru,
> 	jamtlu@gmail.com
> Date: Thu, 01 Oct 2020 23:52:46 -0400
> 
> I don't want to argue about whose fault it is.  The point is that
> the lookup software should handle a format that we can download
> Wikipedia in.

What's so special about wiktionary that we should prefer it?  The
other free and PD dictionaries used by dict.org aren't of lower
quality, and sometimes much better.

Sv: How to make Emacs popular again.

[arthur miller]

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

Whichever implementations you choose; I would just like to
say that having dictionaries in Emacs "by default" would be very
valuable and appreciated. If there could be some functionality to
find synonyms, antonynms, rhems and other stuff, that would be
really great. Pair that with Org andEmacs might be indispensable
for writers, bloggers etc.

I don't have much technical to add to the discussions, so I keep
myself off, I just wish to say that I dig the idea; and hope 28 gets
first class dictionary support. 🙂
________________________________
Från: Emacs-devel <emacs-devel-bounces+arthur.miller=live.com@gnu.org> för Eli Zaretskii <eliz@gnu.org>
Skickat: den 2 oktober 2020 09:08
Till: rms@gnu.org <rms@gnu.org>
Kopia: spacibba@aol.com <spacibba@aol.com>; eduardoochs@gmail.com <eduardoochs@gmail.com>; philipk@posteo.net <philipk@posteo.net>; emacs-devel@gnu.org <emacs-devel@gnu.org>; ams@gnu.org <ams@gnu.org>; dgutov@yandex.ru <dgutov@yandex.ru>; jamtlu@gmail.com <jamtlu@gmail.com>
Ämne: Re: How to make Emacs popular again.

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, philipk@posteo.net, eduardoochs@gmail.com,
>        spacibba@aol.com, emacs-devel@gnu.org, dgutov@yandex.ru,
>        jamtlu@gmail.com
> Date: Thu, 01 Oct 2020 23:52:46 -0400
>
> I don't want to argue about whose fault it is.  The point is that
> the lookup software should handle a format that we can download
> Wikipedia in.

What's so special about wiktionary that we should prefer it?  The
other free and PD dictionaries used by dict.org aren't of lower
quality, and sometimes much better.


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

dict - Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-02 06:53]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > > When you do that, can 'dict' refer directly to the local copies?
> 
>   > yes, you just have to start the dictd deamon locally and point the
>   > client to localhost.
> 
> If any special configuration is needed to tell dict to look
> at a local dictionary, that is bad design.  It should look for
> a local dictionary by default.  Looking elsewhere should be
> the special case.

Exactly.

The client in Emacs, such as dictionary.el should first look for
localhost, and if that is not available, few servers could be set as
fallback.

This could be done in customization.

dictd - is server started on machine, should be installed, then
dictionaries should be installed

Emacs could have dictionary.el looking up to the list of servers
pre-configured, starting with localhost






























> 
> 
> -- 
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
> 
> 
> 

Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-02 06:57]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   >   > This site seems to offer a gateway between Wiktionary and DICT
>   >   > clients:
> 
>   > But to put the blame on dict as the problem seems strange; it isn't
>   > causing this and it is no different than finger, bug trackers, or even
>   > just a plain wget.
> 
> I don't want to argue about whose fault it is.  The point is that
> the lookup software should handle a format that we can download
> Wikipedia in.

Let me repeat that GNU Dico is also dictd RFC 2229 server, and it is
already GNU software, so GNU already has its own dictd - RFC 2229
server, which already has various modules to include various types of
dictionaries, not only being in RFC 2229 format.

There is module wikimedia that then can use the Wiktionary as database
and serve such through localhost server.

So the solution is already there.

Server and client is here:
https://puszcza.gnu.org.ua/software/dico/

dictionary.el can request from server the definitions.

modules are explained here:
https://puszcza.gnu.org.ua/software/dico/modules.html

One of them is mediawiki module which can retrieve from Wiktionary and
From Wikipedia too. Imagine.

Thus Emacs can soon have access to all kinds of dictionaries and
results can be displayed inside of Emacs, including results from
Wiktionary and from Wikipedia.

Jean

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-02 10:09]:
> What's so special about wiktionary that we should prefer it?  The
> other free and PD dictionaries used by dict.org aren't of lower
> quality, and sometimes much better.

The official GNU Dico project can show you mass of dictionaries being
served from official GNU Dico server, including over web, see here:

https://dicoweb.gnu.org.ua/

and here http://www.gnu.org/software/dico/

So everything is there, including Wikipedia and Wiktionary and
plethora of other dictionaries.

Jean

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Fri, 2 Oct 2020 19:13:07 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, spacibba@aol.com, eduardoochs@gmail.com,
>   philipk@posteo.net, emacs-devel@gnu.org, ams@gnu.org,
>   dgutov@yandex.ru, jamtlu@gmail.com
> 
> * Eli Zaretskii <eliz@gnu.org> [2020-10-02 10:09]:
> > What's so special about wiktionary that we should prefer it?  The
> > other free and PD dictionaries used by dict.org aren't of lower
> > quality, and sometimes much better.
> 
> The official GNU Dico project can show you mass of dictionaries being
> served from official GNU Dico server, including over web, see here:
> 
> https://dicoweb.gnu.org.ua/
> 
> and here http://www.gnu.org/software/dico/
> 
> So everything is there, including Wikipedia and Wiktionary and
> plethora of other dictionaries.

That doesn't answer my question, does it?

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-02 19:19]:
> > Date: Fri, 2 Oct 2020 19:13:07 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: rms@gnu.org, spacibba@aol.com, eduardoochs@gmail.com,
> >   philipk@posteo.net, emacs-devel@gnu.org, ams@gnu.org,
> >   dgutov@yandex.ru, jamtlu@gmail.com
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2020-10-02 10:09]:
> > > What's so special about wiktionary that we should prefer it?  The
> > > other free and PD dictionaries used by dict.org aren't of lower
> > > quality, and sometimes much better.
> > 
> > The official GNU Dico project can show you mass of dictionaries being
> > served from official GNU Dico server, including over web, see here:
> > 
> > https://dicoweb.gnu.org.ua/
> > 
> > and here http://www.gnu.org/software/dico/
> > 
> > So everything is there, including Wikipedia and Wiktionary and
> > plethora of other dictionaries.
> 
> That doesn't answer my question, does it?

Sorry.

For me, when defining the word, etymology is important for full
understanding. That is main reason for Wiktionary for me.

Good reason is that Wiktionary is localized in many languages, for
example Indonesian with so many people.

Quote from Wiktionary website:

Wiktionary has grown beyond a standard dictionary and now includes a
thesaurus, a rhyme guide, phrase books, language statistics and
extensive appendices. We aim to include not only the definition of a
word, but also enough information to really understand it. Thus
etymologies, pronunciations, sample quotations, synonyms, antonyms and
translations are included.

Wiktionary has web interface that can hardly be replicated by dictd
protocol, as web interface gives so many references that are helpful
in the study. Thus in my opinion, when dictionary.el looks up word in
Wiktionary, there shall be the 2 extra options:

- the link to the hyperlinked display of Wiktionary entries

- customization for the host that serves Wiktionary entries, as this
  could be also localhost or local network server

Re: dict - Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The client in Emacs, such as dictionary.el should first look for
  > localhost, and if that is not available, few servers could be set as
  > fallback.

That would do the right job, but in a kludgy way.  It ought to
be able to read local files without the kludge of talking
to the same machine over the net.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There is module wikimedia that then can use the Wiktionary as database
  > and serve such through localhost server.

What format does that use for the copy it downloads?

  > So the solution is already there.

WHen it comes to downloading a copy of Wiktionary,
it makes a big difference what format you use.
The smallest format that can be searched quickly enough
is the best format.

The .zim file for Wiktionary from June 2018 (the newest version
available a year ago) is 4408344149.
In download.kiwix.org I see that the most complete version is 5.5 G.

How does the format dico uses compare with that?
It would be best to compare the two formats using
roughly the same date, as it surely grows with time.

If they are fairly similar then they are equally good.
But we should compare.  Can you compare them?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Fri, 2 Oct 2020 19:33:08 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, spacibba@aol.com, eduardoochs@gmail.com,
>   philipk@posteo.net, emacs-devel@gnu.org, ams@gnu.org,
>   dgutov@yandex.ru, jamtlu@gmail.com, torsten@myrkr.in-berlin.de
> 
> Wiktionary has web interface that can hardly be replicated by dictd
> protocol, as web interface gives so many references that are helpful
> in the study.

We have "M-x eww" to go to Wiktionary directly.

And I very much doubt that Richard brought up Wiktionary due to those
reasons.  I think that was from the POV of free software.

Re: dict - Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-03 05:56]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > The client in Emacs, such as dictionary.el should first look for
>   > localhost, and if that is not available, few servers could be set as
>   > fallback.
> 
> That would do the right job, but in a kludgy way.  It ought to
> be able to read local files without the kludge of talking
> to the same machine over the net.

Yes and no.

Emacs can be and will be installed on various systems, various
devices, not every device has the capacity to hold dictionaries, and
not every operating system will even have such dictionaries
included. Many dictionaries like Wiktionary and Wikipedia that can be
served through same system are of large size, not everybody has the
ability to hold large files on their systems.

Debian GNU/Linux and probably PureOS as fully free operating
system have large list of various dictionaries.

Imagine a classroom of pupils with 5 computers, not on each computer
to be dictionary, they can have one server serving dictionary to
others.

Imagine library with 20 private notebook users, they can connect to
library server and access dictionary definitions.

Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-03 05:57]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > There is module wikimedia that then can use the Wiktionary as database
>   > and serve such through localhost server.
> 
> What format does that use for the copy it downloads?

I have asked Sergey, developer of wikimedia module to provide more information.

>   > So the solution is already there.
> 
> WHen it comes to downloading a copy of Wiktionary,
> it makes a big difference what format you use.
> The smallest format that can be searched quickly enough
> is the best format.
> 
> The .zim file for Wiktionary from June 2018 (the newest version
> available a year ago) is 4408344149.
> In download.kiwix.org I see that the most complete version is 5.5 G.
> 
> How does the format dico uses compare with that?

We will know when Sergey, developer of wikimedia module for GNU Dico
answers to me.

dictd or RFC 2229 format is not as nice as ZIM files, it gives textual
definition, like this one below, without hyperlinks:

 Found one definition

From en.wiktionary.org:

[Computer]


** English




*** Etymology

From [en].


*** Pronunciation


- [UK] [en]
- [en]
- [US] [en]
- [en]
- [en]
- [en]

*** Noun

[en-noun]


1. [en] A person employ ed to perform computation s; one who compute s. [from 17th c.]
2. * [en]
3. * 1927 , J. B. S. Haldane, _Possible Worlds and Other Essays_ , page 173
4. *: Only a few years ago Mr. Powers, an American COMPUTER , disproved a hypothesis about prime numbers which had held the field for more than 250 years.
5. * 2003 , [Bill Bryson] , _A Short History of Nearly Everything_ , BCA, page 116:
6. *: One Harvard COMPUTER , Annie Jump Cannon, used her repetitive acquaintance with the stars to devise a system of stellar classifications so practical that it is still in use today.
7. [en] A male computer, where the female computer is called a computress .
8. A programmable electronic device that performs mathematical calculation s and logical operation s, especially one that can process , store and retrieve large amounts of data very quickly; now especially, a small one for personal or home use employed for manipulating text or graphics, accessing the Internet, or playing games or media. [from 20th c.]

Re: dict - Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 02 Oct 2020 22:56:14 -0400
> Cc: philipk@posteo.net, eduardoochs@gmail.com, bugs@gnu.support,
>  spacibba@aol.com, emacs-devel@gnu.org, torsten@myrkr.in-berlin.de,
>  dgutov@yandex.ru, jamtlu@gmail.com
> 
>   > The client in Emacs, such as dictionary.el should first look for
>   > localhost, and if that is not available, few servers could be set as
>   > fallback.
> 
> That would do the right job, but in a kludgy way.  It ought to
> be able to read local files without the kludge of talking
> to the same machine over the net.

Doing so would require reinventing the wheel of reading the dictionary
files, something that dict servers already implement.  Why not let the
server do its job?

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I don't want to argue about whose fault it is.  The point is that
  > > the lookup software should handle a format that we can download
  > > Wikipedia in.

  > What's so special about wiktionary that we should prefer it?

Prefer it?  I did not say to prefer it.  I am saying we should
not presume a preference for some other dictionary  and use that
to support Wiktionary less than fully.a

Use of Wiktionary should not be deprioritized by accidents of past
development choices.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The server could report that you did so.

  > That is something that should be known about a server, isn't it?

How could it ever be known?

                                                                      The
  > default dict.org server runs dictd, the server built from the
  > dict-1.12 package.

You can never verify independently what code a server actually runs,

                        dict is a GPLed package and its source can be
  > scrutinized to see if anything like that is there.

(I am sure it runs many other programs in addition to that.
But let's suppose all of them are libre.)

The people who run any particular server can alter the copy running there, or
add other programs and scripts.

The only way you can have confidence that a particular server does not
try to identify you is if you personally trust the people who run it.
I don't know anything about the people who run that dict server or
any other, so I have no opinion.

There is a defense against this: to go through Tor and make your browser
look like lots of other browsers.

Meanwhile, there are other reasons why it is bad to adopt "talk to a
server" as your default way to do something, and for bad the community
to adopt "talk to a server" as its default recommendation and practice.

  > I think it's the other way around.  I very rarely need to search for a
  > single word, and when I do, I can use "M-s M-w" to do that, because
  > search engines consult these dictionaries as well.

Even if my local dictionary took more work to search, which it
doesn't, I would I always prefer my local dictionary over anything
that requires network communication.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

There are other reasons why it is bad to adopt "talk to a server" as
your default way to do something, and for bad the community to adopt
"talk to a server" as its default recommendation and practice.

Getting an answer over the network can take time.

It can cost you money, in some circumstances.

It can fail, if the network is having a problem.

It can result in tracking your movements, if it requires you to
activate a network connection that identifies and tracks you.

It can be impossible, if you don't have a connection
at that time or place.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We have "M-x eww" to go to Wiktionary directly.

Does using eww imply visiting a web site over the net?
My point is that this should work even if you don't have
a network connection, provided you have a local copy
of Wiktionary.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, eduardoochs@gmail.com, spacibba@aol.com,
> 	emacs-devel@gnu.org, dgutov@yandex.ru, jamtlu@gmail.com
> Date: Sat, 03 Oct 2020 23:38:49 -0400
> 
>   > > The server could report that you did so.
> 
>   > That is something that should be known about a server, isn't it?
> 
> How could it ever be known?

The same way we know that various proprietary operating systems and
programs spy on their users: from people who investigate these issues
and publish their findings.

>   > I think it's the other way around.  I very rarely need to search for a
>   > single word, and when I do, I can use "M-s M-w" to do that, because
>   > search engines consult these dictionaries as well.
> 
> Even if my local dictionary took more work to search, which it
> doesn't, I would I always prefer my local dictionary over anything
> that requires network communication.

I think you are very unusual in this regard.  I have a lot to do on my
typical day, so every second of my time counts.  I will use the most
efficient means of getting the information I need as fast as possible.
Today's Internet search engines make that possible, so I use them a
lot.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, eduardoochs@gmail.com, spacibba@aol.com,
> 	emacs-devel@gnu.org, dgutov@yandex.ru, jamtlu@gmail.com
> Date: Sat, 03 Oct 2020 23:38:51 -0400
> 
> There are other reasons why it is bad to adopt "talk to a server" as
> your default way to do something, and for bad the community to adopt
> "talk to a server" as its default recommendation and practice.
> 
> Getting an answer over the network can take time.
> 
> It can cost you money, in some circumstances.
> 
> It can fail, if the network is having a problem.
> 
> It can result in tracking your movements, if it requires you to
> activate a network connection that identifies and tracks you.
> 
> It can be impossible, if you don't have a connection
> at that time or place.

I think we should let the user decide whether such risks are relevant
in each and every case, and whether these risks, if they exist, are
worth taking.  We explain these issues on the FSF site, so the
considerations and the risks are well known.  We can explain this
again in our documentation where relevant.  This way, we can consider
users informed and capable of making their own decisions.

That said, I agree that testing for the availability of a local server
first is a good idea that dictionary.el should implement, so I'm not
really sure what are we still arguing about.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: bugs@gnu.support, philipk@posteo.net, spacibba@aol.com,
> 	emacs-devel@gnu.org, torsten@myrkr.in-berlin.de, ams@gnu.org,
> 	dgutov@yandex.ru, jamtlu@gmail.com, eduardoochs@gmail.com
> Date: Sat, 03 Oct 2020 23:45:20 -0400
> 
>   > We have "M-x eww" to go to Wiktionary directly.
> 
> Does using eww imply visiting a web site over the net?

Yes, if the URL is HTTP/HTTPS/FTP.

> My point is that this should work even if you don't have
> a network connection, provided you have a local copy
> of Wiktionary.

EWW is not the solution for that use case.

Dictionaries better be offline - Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-04 06:39]:
> Even if my local dictionary took more work to search, which it
> doesn't, I would I always prefer my local dictionary over anything
> that requires network communication.

Definitely good, safe and practical approach.

Dictionaries are traditionally books and handy, used when learning.

Let me give you example, phones and outside networks are forbidden in
many universities in Tanzania and Uganda (about 90 million
people). That means a student of 20 years, even adult, is disallowed
mobile phone while in university.

Yet they are allowed to use computers and notebooks. We speak of
millions of people, I guess there are millions of students in those
countries.

When in the library or at home, I am often reading books and need
quick lookup in the dictionary, normally I am using Wordnet, and I
prefer having everything offline. These days I hope to establish to
have Wiktionary and Wikipedia offline, for youth in this
house.

Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-04 06:42]:
> It can result in tracking your movements, if it requires you to
> activate a network connection that identifies and tracks you.

There are millions of people in Internet censored countries, thinking
about Iran as example, there is youth there, if they would be just
searching for certain definitions of words in a dictionary, over
insecure connection, they could be visited by police even tortured or
persecuted.

For me, GNU project became planetary.

Re: How to make Emacs popular again.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-04 06:46]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > We have "M-x eww" to go to Wiktionary directly.
> 
> Does using eww imply visiting a web site over the net?
> My point is that this should work even if you don't have
> a network connection, provided you have a local copy
> of Wiktionary.

It would be great if it would work through Emacs. Large problem is
that data files are huge.

For libraries, for universities, academies, best is to have local
network kiwix-serve command that serves Wiktionary locally over
network, I guess it works as web server with search engine.

Jean

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-04 09:59]:
> > Even if my local dictionary took more work to search, which it
> > doesn't, I would I always prefer my local dictionary over anything
> > that requires network communication.
> 
> I think you are very unusual in this regard.  I have a lot to do on my
> typical day, so every second of my time counts.  I will use the most
> efficient means of getting the information I need as fast as possible.
> Today's Internet search engines make that possible, so I use them a
> lot.

I was for months outside of good Internet network area in Uganda, and
locally installed dictionary was really help. I have translation
dictionaries installed locally and English dictionaries.

Let me say that majority of computer users on the planet do not have
reliable or any Internet connections.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Sun, 4 Oct 2020 12:02:27 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: emacs-devel@gnu.org
> 
> Let me say that majority of computer users on the planet do not have
> reliable or any Internet connections.

We should have a good support both for those that have good
connections and those that don't.

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-04 10:04]:
> > From: Richard Stallman <rms@gnu.org>
> > Cc: philipk@posteo.net, eduardoochs@gmail.com, spacibba@aol.com,
> > 	emacs-devel@gnu.org, dgutov@yandex.ru, jamtlu@gmail.com
> > Date: Sat, 03 Oct 2020 23:38:51 -0400
> > 
> > There are other reasons why it is bad to adopt "talk to a server" as
> > your default way to do something, and for bad the community to adopt
> > "talk to a server" as its default recommendation and practice.
> > 
> > Getting an answer over the network can take time.
> > 
> > It can cost you money, in some circumstances.
> > 
> > It can fail, if the network is having a problem.
> > 
> > It can result in tracking your movements, if it requires you to
> > activate a network connection that identifies and tracks you.
> > 
> > It can be impossible, if you don't have a connection
> > at that time or place.
> 
> I think we should let the user decide whether such risks are relevant
> in each and every case, and whether these risks, if they exist, are
> worth taking.

Universities are often off-line, something impossible for you to
imagine in the US, is very realistic in East Africa. Students may be
prevented having mobile phones, but not prevented having
computers.

In too many countries Internet is not easily available or accessible,
and is too often too expensive for even normal people to access it how
they want it.

> We explain these issues on the FSF site, so the considerations and
> the risks are well known.

They may be well published by FSF, but they cannot possibly be known
to general public as referencing and finding articles is not easy. It
is well known to smaller group of people who are fans of FSF and the
website. 

> We can explain this again in our documentation where relevant.  This
> way, we can consider users informed and capable of making their own
> decisions.

I have totally different impression. So many times I am explaining
friends and associates about this subject, I am talking face to face
to people I know, majority of people are not aware of any risks in
networking. That is greatest problem in our society right now. In my
opinion with technology development, society will become dumber 100%
within only next 5 years, so avoiding unsecure networking and making
people aware is necessity of today.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Sun, 4 Oct 2020 13:07:19 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: philipk@posteo.net, rms@gnu.org, spacibba@aol.com, emacs-devel@gnu.org,
>  dgutov@yandex.ru, jamtlu@gmail.com, eduardoochs@gmail.com
> 
> > I think we should let the user decide whether such risks are relevant
> > in each and every case, and whether these risks, if they exist, are
> > worth taking.
> 
> Universities are often off-line, something impossible for you to
> imagine in the US, is very realistic in East Africa. Students may be
> prevented having mobile phones, but not prevented having
> computers.
> 
> In too many countries Internet is not easily available or accessible,
> and is too often too expensive for even normal people to access it how
> they want it.
> 
> > We explain these issues on the FSF site, so the considerations and
> > the risks are well known.
> 
> They may be well published by FSF, but they cannot possibly be known
> to general public as referencing and finding articles is not easy. It
> is well known to smaller group of people who are fans of FSF and the
> website. 
> 
> > We can explain this again in our documentation where relevant.  This
> > way, we can consider users informed and capable of making their own
> > decisions.
> 
> I have totally different impression. So many times I am explaining
> friends and associates about this subject, I am talking face to face
> to people I know, majority of people are not aware of any risks in
> networking. That is greatest problem in our society right now. In my
> opinion with technology development, society will become dumber 100%
> within only next 5 years, so avoiding unsecure networking and making
> people aware is necessity of today.

What exactly are you arguing for?  That we forcibly prevent users from
using on-line access where it is available and reasonably fast, just
because in some parts of the world Internet access is nonexistent, or
because there are risks associated with using Internet?  Such
enforcement makes no sense to me.  We should treat our users as
responsible adults.

We've already agreed to look for local resources first, and only fall
back to remote servers if the local resources don't exist.  So I see
no reason to continue arguing here if you are saying we should prefer
local resources.  And if you are really saying that we should forcibly
prevent remote access because our users don't know what they are
doing, then it's so far away of everything I believe in that any
argument will be futile.

Re: How to make Emacs popular again.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-04 13:53]:
> > Date: Sun, 4 Oct 2020 13:07:19 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: philipk@posteo.net, rms@gnu.org, spacibba@aol.com, emacs-devel@gnu.org,
> >  dgutov@yandex.ru, jamtlu@gmail.com, eduardoochs@gmail.com
> > 
> > > I think we should let the user decide whether such risks are relevant
> > > in each and every case, and whether these risks, if they exist, are
> > > worth taking.
> > 
> > Universities are often off-line, something impossible for you to
> > imagine in the US, is very realistic in East Africa. Students may be
> > prevented having mobile phones, but not prevented having
> > computers.
> > 
> > In too many countries Internet is not easily available or accessible,
> > and is too often too expensive for even normal people to access it how
> > they want it.
> > 
> > > We explain these issues on the FSF site, so the considerations and
> > > the risks are well known.
> > 
> > They may be well published by FSF, but they cannot possibly be known
> > to general public as referencing and finding articles is not easy. It
> > is well known to smaller group of people who are fans of FSF and the
> > website. 
> > 
> > > We can explain this again in our documentation where relevant.  This
> > > way, we can consider users informed and capable of making their own
> > > decisions.
> > 
> > I have totally different impression. So many times I am explaining
> > friends and associates about this subject, I am talking face to face
> > to people I know, majority of people are not aware of any risks in
> > networking. That is greatest problem in our society right now. In my
> > opinion with technology development, society will become dumber 100%
> > within only next 5 years, so avoiding unsecure networking and making
> > people aware is necessity of today.
> 
> What exactly are you arguing for?  That we forcibly prevent users from
> using on-line access where it is available and reasonably fast, just
> because in some parts of the world Internet access is nonexistent, or
> because there are risks associated with using Internet?  Such
> enforcement makes no sense to me.  We should treat our users as
> responsible adults.

Noo.

I am suggesting to assume the planetary view point, not only western
developed view point.

No, I did not say to prevent users. I am suggesting to help users
download resources and use them offline.

We cannot say that in some parts of the world Internet access is not
as good, rather we shall say in the majority of the world.

I am saying that it is not optimum for Emacs and accessibility of
users to assume that users will be able to have those network
connections.

Please compare the Kiwix project: https://www.kiwix.org/en/ that
brings various Wikipedia, Wiktionary, Gutenberg and other resources to
those areas which are cut from Internet. There is reason for their
project, and it is of strong humanitarian character.

Also observe this statistics of Internet users:
https://en.wikipedia.org/wiki/List_of_countries_by_number_of_Internet_users

Compare the number of Internet users to population on that table. In
Germany 86% of Internet users, while in Ethiopia 18.62% Internet
users, and country has population of 104 millions which greater than
Germany of 82 millions.

> We've already agreed to look for local resources first, and only fall
> back to remote servers if the local resources don't exist.  So I see
> no reason to continue arguing here if you are saying we should prefer
> local resources.  And if you are really saying that we should forcibly
> prevent remote access because our users don't know what they are
> doing, then it's so far away of everything I believe in that any
> argument will be futile.

No, I did not say, why force people not to use Internet? I am not that
crazy.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Sun, 4 Oct 2020 16:54:40 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: philipk@posteo.net, rms@gnu.org, spacibba@aol.com,
>   emacs-devel@gnu.org, dgutov@yandex.ru, jamtlu@gmail.com,
>   eduardoochs@gmail.com
> 
> > We've already agreed to look for local resources first, and only fall
> > back to remote servers if the local resources don't exist.  So I see
> > no reason to continue arguing here if you are saying we should prefer
> > local resources.  And if you are really saying that we should forcibly
> > prevent remote access because our users don't know what they are
> > doing, then it's so far away of everything I believe in that any
> > argument will be futile.
> 
> No, I did not say, why force people not to use Internet? I am not that
> crazy.

Good.  Then I guess we are in a violent agreement about what commands
that access dictionaries should do, and we can stop arguing about
things we agree upon.

Re: How to make Emacs popular again.

[Dmitry Gutov]

On 27.09.2020 20:31, Bob Newell wrote:
> 
> In your long posting with many ideas about making Emacs
> beginner friendly, there is much to consider, and I must say
> right at the start that easing the Emacs learning experience
> is a worthy goal.
> 
> It does raise the question: how did the current Emacs users
> learn Emacs? I can't speak for anyone else but I don't know
> that my own experiences are in any way unique. I learned first
> from the tutorial, then from some of the manuals, then by doing
> and experimenting and reading more of the manuals, and trial
> and error.

I don't remember too much, but:

- I went through the manual a few times. Was also puzzled why the 
trivial functionality (exotic bindings for regular editing commands) 
needs several pages of instruction, and why the tutorial tells very 
little about things that would make Emacs more useful than 
Nano/Notepad/etc. After that, I avoided the "Emacs" bindings anyway for 
a couple of years by using cua-mode, arrow keys, etc (not sure in which 
exact order), then eventually migrated to the default bindings except 
for 'undo'.

- I started not with the default configuration but with the "starter 
kit" by Phil Hagelberg. Its latest iteration lives at 
https://git.sr.ht/~technomancy/better-defaults. Check out the rationale 
in the description, too (it's pretty accurate).

> We can never forget something critically important: Emacs is a
> very sophisticated, very powerful tool, and like all such
> tools, it takes effort and dedication to learn. (Even lesser
> tools, like office suites, take effort to learn, if perhaps in
> lesser amounts.)
> 
> While we can and should do all we can to make the road
> smoother--- short of turning Emacs into something completely
> different and so overwhelmed with tooltips, popups, and other
> "help" that it becomes unpleasant or even unusable--- let's
> face it, Emacs is never going to be "easy."

I don't think it become too similar to VS Code (and friends) by default 
anytime soon.

But at least it could start giving off a more "polished" impression, 
both in the UI and the introduction documentation. So that, even to an 
uninitiated person (but someone with a compatible mindset, perhaps) it 
would look like a worthy investment of their time.

> Things are, in fact, very much easier now than when I started
> with Emacs decades ago. Today, there is a wealth of on-line
> information, with tutorials, how-tos, discussions, code
> samples, and help readily available to anyone who asks
> politely.

That is true.

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I am saying that it is not optimum for Emacs and accessibility of
  > users to assume that users will be able to have those network
  > connections.

I agree with this point.

However, I have another point, in the same area but different:
accessing local resources should not go through running a local
internet server by default.  Here are reasons:

* It is a kludge.

* Accessing a local resource through a generic interface will often
limit what can be done with it.

* Having an internet server running will make people have to worry,
"Can anyone else get at this server?"  Even if the answer is "No,
that is blocked by some of the settings," it is still a worry.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The same way we know that various proprietary operating systems and
  > programs spy on their users: from people who investigate these issues
  > and publish their findings.

That is not reliable.  Occasionally we learn that a server is doing
something bad.  We hear about that as news if it is a very important
server that lots of people use.  Otherwise, people hardly bother.

  > I think you are very unusual in this regard.  I have a lot to do on my
  > typical day, so every second of my time counts.

Me, too.  But looking up in the local copy of Wiktionary is faster than
getting a response from a web site.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, eduardoochs@gmail.com, spacibba@aol.com,
> 	emacs-devel@gnu.org, dgutov@yandex.ru, jamtlu@gmail.com
> Date: Sun, 04 Oct 2020 23:14:56 -0400
> 
>   > I think you are very unusual in this regard.  I have a lot to do on my
>   > typical day, so every second of my time counts.
> 
> Me, too.  But looking up in the local copy of Wiktionary is faster than
> getting a response from a web site.

You said you'd do that even if it were longer, and my response was to
that part only.

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > I think you are very unusual in this regard.  I have a lot to do on my
  > >   > typical day, so every second of my time counts.
  > > 
  > > Me, too.  But looking up in the local copy of Wiktionary is faster than
  > > getting a response from a web site.

  > You said you'd do that even if it were longer, and my response was to
  > that part only.

Sorry for confusion.

Yes, I would prefer a local dictionary to one reached across the network,
even if it were slower.  There are more important things at stake.
I think I explained that before.

However, in fact, accessing my local copy is faster than accessing pages
across the network.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>
> It does raise the question: how did the current Emacs users learn Emacs? 
> I can't speak for anyone else but I don't know that my own experiences 
> are in any way unique.
>

Thank you for this interesting question.

I can't speak for anyone else either, but FWIW here is what happend for 
me.  I just digged in my digital archives to find the first traces of my 
use of Emacs.  Apparently the oldest version of Emacs I used was 19.34.

In the oldest copies of the .emacs file I used at that time, I see mainly 
two things:

1. settings to customize Emacs' visual appearance:

default-frame-alist: font, cursor-color, background-color, 
vertical-scroll-bars nil

icon-title-format and frame-title-format: I was using (list " Emacs - " 
'(-1 . "%s")), apparently to have a visual indication that gnuserv was 
running

mode-line-format: in particular, I removed the "L" before the line number 
and added columns with %c, I replaced the default "%14b" with "%b", and I 
displayed time with (setq display-time-24hr-format t) or (setq 
display-time-format ...) and (display-time)

font-lock-mode: (global-font-lock-mode t), (setq 
font-lock-maximum-decoration t), (setq font-lock-maximum-size nil), and a 
number of customized font-lock faces

menu-bar: apparently I sometimes (i.e., not always) disabled the menu bar 
with (menu-bar-mode nil)

2. settings to customize Emacs' keyboard bindings:

(pc-selection-mode)
(CUA-mode t)
(global-set-key [home] 'beginning-of-line)
(global-set-key [end] 'end-of-line)
(global-set-key [C-home] 'beginning-of-buffer)
(global-set-key [C-end] 'end-of-buffer)

I vaguely remember that I stopped using CUA-mode after a year or two.

So it seems that, for me at that time as for newcomers today, the visual 
appearance and keyboard settings were the main/only thing I was interested 
in.

(I believe there is, however, an important difference between twenty years 
ago and now: at that time it would have been as difficult to do such 
customizations with other text editors as it was for Emacs (and with a 
number of these other editors it would simply not have been possible to do 
such customizations), so it was okay to spend some time on this. 
Nowadays with other text editors these customizations are the first thing 
you are asked to do, and you can do them with a few mouse clicks.  Which 
explains, I think, that the average user expectation is very different now 
than it was twenty years ago.)

>
> I learned first from the tutorial, then from some of the manuals, then 
> by doing and experimenting and reading more of the manuals, and trial 
> and error.
>

I remember that I tried to follow the tutorial, and that I never had the 
patience to do so, because (IIRC) it spends too much time on things that 
are (or at least appear) easy (moving around, which you can do with arrow 
keys, Home, End, Page Up, Page Down, ...).

Most of what I learned later was with C-h: C-h k, C-h l, C-h m, C-h f, C-h 
v, C-h w.  I also read parts of the manual (with Info) but found it less 
useful than the built-in documentation.  And, of course, I learned a lot 
by trial and error.

>
> Things are, in fact, very much easier now than when I started with Emacs 
> decades ago. Today, there is a wealth of on-line information, with 
> tutorials, how-tos, discussions, code samples, and help readily 
> available to anyone who asks politely.
>

Again I can't speak for you or anyone else, but I also remember (and my 
digital archives confirm) that twenty years ago there was a "dotemacs" 
website, which is I believe now at https://dotemacs.de , in which I found 
many example configuration files, with many simple defuns.

Re: How to make Emacs popular again.

[João Távora]

My experience was very close to Gregory's.  I also didn't have
patience to follow the tutorial at first, but when I did I ended up
ditching cua-mode and a lot of half-baked stuff I had.  I also
didn't read the manual very often, because I didn't find it easily.
I didn't even distinguish correctly between Emacs and Emacs Lisp
manuals, and was confused by Info vs Man.  But C-h f and C-h k
and following those hyperlinks were life savers from the start.
Didn't care about the remaining C-h stuff though, which would have
helped, in retrospect.

I still do keep a C-a binding that switches back and forth between
beginning of line and beginning of indentation and a shadowing
binding to kill current buffer with C-x C-k (the default one, C-x k, is
too easy to mistype for such a common operation).  Those are my
only two surviving things from 2005, and I can perfectly use
an Emacs without them.

João

Re: How to make Emacs popular again.

[Jean Louis]

* João Távora <joaotavora@gmail.com> [2020-10-07 14:23]:
> My experience was very close to Gregory's.  I also didn't have
> patience to follow the tutorial at first, but when I did I ended up
> ditching cua-mode and a lot of half-baked stuff I had.  I also
> didn't read the manual very often, because I didn't find it easily.
> I didn't even distinguish correctly between Emacs and Emacs Lisp
> manuals, and was confused by Info vs Man.  But C-h f and C-h k
> and following those hyperlinks were life savers from the start.
> Didn't care about the remaining C-h stuff though, which would have
> helped, in retrospect.

I started using Emacs in 1999, in fact I went to find GNU operating
system as I knew it is "type of Unix" that is what I knew, and I
wanted good multi-tasking, as I was pissed off with Windows lack of
performance in database population for search engine creation.

Instead of buying GNU on CD, that was available in Stuttgart's library
Witwer at that time, I have purchased some copy of "Red Hat Linux",
because I found they have "GNU" inside.

Among many software I tried, there was Emacs, that is where I could
read about the GNU project, and understand it.

I was using various Emacs versions, at that time there was XEmacs I
think and Emacs, I did not know what is what, I used both of them, all
Emacs were installed and I remember I had pleasure in learning, no
hard time, and there was a lot of jokes and stuff to read in the
directory of Emacs, I guess those are still there, like those in
share/emacs/28.0.50/etc -- and I remember I have not used any special
customizations, until I found gnus for news and email, those were only
customizations so far I used since 1999, until about some time
2016. Today I don't use customizations on many remote machines and in
various user accounts, why should I, I am using it mainly for editing.

I have used vi and vim, and from time to time I forget its key
bindings, while those from Emacs stay in my fingers.

Last person reading tutorial was Ugandan before few days, without
previous knowledge of computers, she could easily remember the key
bindings she learned, how to move the cursor, save file and similar, I
can just say that tutorial is helpful.

Jean

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   I also
  > didn't read the manual very often, because I didn't find it easily.

Can you suggest a way to make that easier for others in the future?

  > I didn't even distinguish correctly between Emacs and Emacs Lisp
  > manuals, 

Can you suggest a way to clarify that?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[João Távora]

On Thu, Oct 8, 2020 at 5:42 AM Richard Stallman <rms@gnu.org> wrote:

>   > I didn't even distinguish correctly between Emacs and Emacs Lisp
>   > manuals,
>
> Can you suggest a way to clarify that?

Not really.  Tip-the-day in the welcome screen?  A clippy, type thing?
So many ideas sophisticated ideas here, but I guess at a certain point
we just want the following sentence to be presented in front of the eyes
of impatient, not particularly methodical, programmers like I was back
then:

"Hey, did you know Emacs has manuals?  They're really good!
There's THIS manual that teaches how to use Emacs, its
keys and stuff, and there THIS manual which teaches how
to program for Emacs, so you can make your own extensions."

People starting off with Emacs are not married to it like we
mostly are.  They want it to stay out of their way so they can
go about their task.  There should be a way to slowly call
attention to the superior qualities of the editor, even if the
strategy is to textually say: "take our word for it, spend 10
minutes doing this fun tutorial".  And then deliver, of course,
if the tutorial is utterly boring or useless that user is probably
lost forever.

João

Re: How to make Emacs popular again.

[Georges Ko]

Richard Stallman <rms@gnu.org> writes:

> Can you suggest a way to make that easier for others in the future?
>
>   > I didn't even distinguish correctly between Emacs and Emacs Lisp
>   > manuals, 
>
> Can you suggest a way to clarify that?

Regarding the Emacs Lisp manual, something that would be helpful is to
list the functions, user options, commands, etc. of each chapter at the
top or in its own section, so that one doesn't need to go to that
specific chapter just to get the forgotten name of a function or one can
quickly see all the symbols in one page for a topic.

In the Common Lisp HyperSpec, each chapter has a dictionary chapter at
the end, listing all the functions, variables, etc. For example, if we
look at Strings in http://www.lispworks.com/documentation/HyperSpec/Body/16_.htm,
we can see:

  16. Strings
  16.1 String Concepts
  16.2 The Strings Dictionary

with the page "The Strings Dictionary" listing related elements:

     System Class STRING
     Type BASE-STRING
     Type SIMPLE-STRING
     Type SIMPLE-BASE-STRING
     Function SIMPLE-STRING-P
     Accessor CHAR, SCHAR
     Function STRING
     Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
     Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM
     Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
     Function STRINGP
     Function MAKE-STRING

In the Emacs Lisp manual, instead of:

   4 Strings and Characters
   ************************
   
   A string in Emacs Lisp is an array that contains an ordered sequence of
   characters.  Strings are used as names of symbols, buffers, and files;
   to send messages to users; to hold text being copied between buffers;
   and for many other purposes.  Because strings are so important, Emacs
   Lisp has many functions expressly for manipulating them.  Emacs Lisp
   programs use strings more often than individual characters.
   
      *Note Strings of Events::, for special considerations for strings of
      keyboard character events.
      
      * Menu:
      
      * Basics: String Basics.      Basic properties of strings and characters.
      * Predicates for Strings::    Testing whether an object is a string or char.
      ...

it could be:

        4 Strings and Characters
        ************************
        
        A string in Emacs Lisp is an array that contains an ordered sequence of
        ...
        programs use strings more often than individual characters.
     
   -->  [List of symbols]
     
           *Note Strings of Events::, for special considerations for strings of
           keyboard character events.
           
        * Menu:
           
        * Basics: String Basics.      Basic properties of strings and characters.
        * Predicates for Strings::    Testing whether an object is a string or char.
        ...

or

        4 Strings and Characters
        ************************
        
        A string in Emacs Lisp is an array that contains an ordered sequence of
        ...
        programs use strings more often than individual characters.
     
           *Note Strings of Events::, for special considerations for strings of
           keyboard character events.
           
        * Menu:
      
   -->  * Strings and Characters Symbols.   Symbols of strings and charactgers
        * Basics: String Basics.      Basic properties of strings and characters.
        * Predicates for Strings::    Testing whether an object is a string or char.
        ...

Georges
-- 
 Georges Ko                     gko@gko.net                      2020-10-08

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Georges Ko <gko@gko.net>
> Date: Thu, 08 Oct 2020 22:05:07 +0800
> 
> Regarding the Emacs Lisp manual, something that would be helpful is to
> list the functions, user options, commands, etc. of each chapter at the
> top or in its own section, so that one doesn't need to go to that
> specific chapter just to get the forgotten name of a function or one can
> quickly see all the symbols in one page for a topic.
> 
> In the Common Lisp HyperSpec, each chapter has a dictionary chapter at
> the end, listing all the functions, variables, etc. For example, if we
> look at Strings in http://www.lispworks.com/documentation/HyperSpec/Body/16_.htm,
> we can see:
> 
>   16. Strings
>   16.1 String Concepts
>   16.2 The Strings Dictionary
> 
> with the page "The Strings Dictionary" listing related elements:
> 
>      System Class STRING
>      Type BASE-STRING
>      Type SIMPLE-STRING
>      Type SIMPLE-BASE-STRING
>      Function SIMPLE-STRING-P
>      Accessor CHAR, SCHAR
>      Function STRING
>      Function STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE, NSTRING-DOWNCASE, NSTRING-CAPITALIZE
>      Function STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM
>      Function STRING=, STRING/=, STRING<, STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL, STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
>      Function STRINGP
>      Function MAKE-STRING

We support that via indexing: each symbol is indexed, and the command
Info-index, bound to 'i', lands you exactly where the symbol is
described.  You don't even need to go through the section where it is
described.  Just type 'i SYMBOL RET" anywhere in the manual, and you
should see the place where that SYMBOL is described.

This is IMO more efficient that lists such as the one above,
especially because these lists can be very long and time-consuming to
search.

Re: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>> I also didn't read the manual very often, because I didn't find it 
>> easily.
>
> Can you suggest a way to make that easier for others in the future?
>

My suggestion would be to add links in the docstrings to the relevant 
chapter in the Emacs and Emacs Lisp manuals.  Three examples:

kill-line would have a link to (info "(emacs)Killing")
kill-buffer would have two links, one to (info "(emacs)Buffers") and another to (info "(elisp)Buffers")
call-process would have a link to (info "(elisp)Processes")

I think a link to the relevant chapter, as in the examples above, is 
better than a link to the relevant section or subsection.  With this, 
users who follow that link would find more information about the general 
context of the command or function, and not just a similar documentation.

Re: How to make Emacs popular again.

[Robert Pluim]

>>>>> On Thu, 08 Oct 2020 14:22:01 +0000, Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> said:

    >>> I also didn't read the manual very often, because I didn't find it
    >>> easily.
    >> 
    >> Can you suggest a way to make that easier for others in the future?
    >> 

    Emacs> My suggestion would be to add links in the docstrings to the relevant
    Emacs> chapter in the Emacs and Emacs Lisp manuals.  Three examples:

    Emacs> kill-line would have a link to (info "(emacs)Killing")
    Emacs> kill-buffer would have two links, one to (info "(emacs)Buffers") and another to (info "(elisp)Buffers")
    Emacs> call-process would have a link to (info "(elisp)Processes")

    Emacs> I think a link to the relevant chapter, as in the examples above, is
    Emacs> better than a link to the relevant section or subsection.  With this,
    Emacs> users who follow that link would find more information about the
    Emacs> general context of the command or function, and not just a similar
    Emacs> documentation.

Try

C-h f kill-line
put point somewhere on 'kill-line' in the docstring
C-h S

Now making that more widely known would help, I think.

Robert
-- 

Re: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>>>> I also didn't read the manual very often, because I didn't find it 
>>>> easily.
>>>
>>> Can you suggest a way to make that easier for others in the future?
>>>
>>
>> My suggestion would be to add links in the docstrings to the relevant 
>> chapter in the Emacs and Emacs Lisp manuals.  Three examples:
>>
>> kill-line would have a link to (info "(emacs)Killing")
>>
>> kill-buffer would have two links, one to (info "(emacs)Buffers") and 
>> another to (info "(elisp)Buffers")
>>
>> call-process would have a link to (info "(elisp)Processes")
>>
>> I think a link to the relevant chapter, as in the examples above, is 
>> better than a link to the relevant section or subsection.  With this, 
>> users who follow that link would find more information about the 
>> general context of the command or function, and not just a similar 
>> documentation.
>
> Try
>
> C-h f kill-line
> put point somewhere on 'kill-line' in the docstring
> C-h S
>
> Now making that more widely known would help, I think.
>

Well, that doesn't quite do what I suggest.  It only finds the symbol in 
the Emacs manual (AFAICS it does not search in the Elisp manual), and what 
you find when you do this on a command is something that much resembles 
what you find in the docstring, so it doesn't look like useful 
information, it looks redundant.  As I said, I think entering the chapter 
would be much more useful, as it would give the user the feeling that 
there is more information there.

Re: How to make Emacs popular again.

[Robert Pluim]

>>>>> On Thu, 08 Oct 2020 14:54:09 +0000, Gregory Heytings <ghe@sdf.org> said:

    Gregory> Well, that doesn't quite do what I suggest.  It only finds the symbol
    Gregory> in the Emacs manual (AFAICS it does not search in the Elisp manual),
    Gregory> and what you find when you do this on a command is something that much
    Gregory> resembles what you find in the docstring, so it doesn't look like
    Gregory> useful information, it looks redundant.  As I said, I think entering
    Gregory> the chapter would be much more useful, as it would give the user the
    Gregory> feeling that there is more information there.

It puts you in info, where it is obvious there is more information: at
the top of the buffer it says:

Up: Deletion and Killing

so finding out more is easy.

Robert
-- 

Re: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>> Well, that doesn't quite do what I suggest.  It only finds the symbol 
>> in the Emacs manual (AFAICS it does not search in the Elisp manual), 
>> and what you find when you do this on a command is something that much 
>> resembles what you find in the docstring, so it doesn't look like 
>> useful information, it looks redundant.  As I said, I think entering 
>> the chapter would be much more useful, as it would give the user the 
>> feeling that there is more information there.
>
> It puts you in info, where it is obvious there is more information: at 
> the top of the buffer it says:
>
> Up: Deletion and Killing
>
> so finding out more is easy.
>

I do not agree with your "obvious".  It is true that there is a "Up" link 
at the top of the buffer, but it's not what you immediately see. 
Moreover, when you click on it you do not see the chapter title, you find 
a "Menu" with section titles.

Remember that I was answering Richard's question: "Can you suggest a way 
to make [finding the manuals] easier for others in the future?"

Two visible links in the docstring of, say, kill-buffer, to the relevant 
chapters of both the Emacs and Elisp manual, are easier to use than typing 
C-h S u M-<, followed by d m Elisp RET i kill-buffer RET u M-<.  Even IMO 
for an experienced user.

Re: How to make Emacs popular again.

[Daniel Martín]

Robert Pluim <rpluim@gmail.com> writes:

> Try
>
> C-h f kill-line
> put point somewhere on 'kill-line' in the docstring
> C-h S
>
> Now making that more widely known would help, I think.

We could add a "View in Manual" button in Help buffers if info-lookup
says that the symbol is in the Emacs Lisp Info index.

It could be a symbol lookup added to the one we already have to say
"Probably introduced at of before Emacs version XX.X".

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: Gregory Heytings via "Emacs development discussions."
>  <emacs-devel@gnu.org>,  Gregory Heytings <ghe@sdf.org>,
>  bobnewell@bobnewell.net,  Richard Stallman <rms@gnu.org>,
>  João Távora <joaotavora@gmail.com>
> Date: Thu, 08 Oct 2020 20:08:23 +0200
> 
> > C-h f kill-line
> > put point somewhere on 'kill-line' in the docstring
> > C-h S
> >
> > Now making that more widely known would help, I think.
> 
> We could add a "View in Manual" button in Help buffers if info-lookup
> says that the symbol is in the Emacs Lisp Info index.

For interactive functions (a.k.a. "commands"), there's an ambiguity
here: should the link lead to the Emacs user manual or to the Emacs
Lisp Reference manual?  We could show both, but that could confuse
users (as opposed to Lisp programmers).

RE: How to make Emacs popular again.

[Drew Adams]

> We could add a "View in Manual" button in Help buffers if info-lookup
> says that the symbol is in the Emacs Lisp Info index.
> 
> It could be a symbol lookup added to the one we already have to say
> "Probably introduced at of before Emacs version XX.X".

I do that in `help-fns+.el'.  A user option lets you
choose which manuals to use.

RE: How to make Emacs popular again.

[Drew Adams]

> C-h f kill-line
> put point somewhere on 'kill-line' in the docstring
> C-h S
> 
> Now making that more widely known would help, I think.

Yes.  A start is to what I do in `help-mode+.el':
change the help-echo on  a linked symbol, so it
includes mention of `C-h S'.  This trivial change
could be made to `help-mode.el'.

IOW, instead of just

 "mouse-2, RET: describe this symbol"

say:

 "mouse-2, RET: describe, C-h S RET: check manual"

That just requires this in `help-mode.el':

(define-button-type 'help-symbol
  :supertype 'help-xref
  'help-function #'describe-symbol
  'help-echo
  (purecopy "mouse-2, RET: describe this symbol, \
C-h S RET: check manual"))
___

As mentioned in another mail, we could enhance
`C-h S' to use more than the Emacs manual, in
which case that `help-echo' would say "manuals",
not "manual".

Re: How to make Emacs popular again.

[Daniel Martín]

Eli Zaretskii <eliz@gnu.org> writes:

>
> For interactive functions (a.k.a. "commands"), there's an ambiguity
> here: should the link lead to the Emacs user manual or to the Emacs
> Lisp Reference manual?  We could show both, but that could confuse
> users (as opposed to Lisp programmers).

IIRC, info-lookup already has some heuristics to decide between the
Emacs manual or the Emacs Lisp manual. For example, C-h S on find-file
opens the Emacs manual (even though the command is indexed on both
manuals), but C-h S on region-end opens the Emacs Lisp manual.

Maybe those heuristics are already good enough to make users and ELisp
programmers happy.

RE: How to make Emacs popular again.

[Drew Adams]

[Really getting tired of having to add emacs-devel@gnu.org manually...]

> C-h f kill-line
> put point somewhere on 'kill-line' in the docstring
> C-h S
> 
> Now making that more widely known would help, I think.

Yes.  A start is to what I do in `help-mode+.el':
change the help-echo on  a linked symbol, so it
includes mention of `C-h S'.  This trivial change
could be made to `help-mode.el'.

IOW, instead of just

 "mouse-2, RET: describe this symbol"

say:

 "mouse-2, RET: describe, C-h S RET: check manual"

That just requires this in `help-mode.el':

(define-button-type 'help-symbol
  :supertype 'help-xref
  'help-function #'describe-symbol
  'help-echo
  (purecopy "mouse-2, RET: describe this symbol, \
C-h S RET: check manual"))
___

As mentioned in another mail, we could enhance
`C-h S' to use more than the Emacs manual, in
which case that `help-echo' would say "manuals",
not "manual".

RE: How to make Emacs popular again.

[Drew Adams]

> IIRC, info-lookup already has some heuristics to decide between the
> Emacs manual or the Emacs Lisp manual. For example, C-h S on find-file
> opens the Emacs manual (even though the command is indexed on both
> manuals), but C-h S on region-end opens the Emacs Lisp manual.
> 
> Maybe those heuristics are already good enough to make users and ELisp
> programmers happy.

Yes, such heuristics can help.

But it's also good to let users specify which manuals
to use (with, say, emacs and elisp as the defaults).

Re: How to make Emacs popular again.

[Stefan Monnier]

>> We could add a "View in Manual" button in Help buffers if info-lookup
>> says that the symbol is in the Emacs Lisp Info index.

Yes, it should be fairly easy to do using the
`help-fns-describe-*-functions` hooks.

> For interactive functions (a.k.a. "commands"), there's an ambiguity
> here: should the link lead to the Emacs user manual or to the Emacs
> Lisp Reference manual?  We could show both, but that could confuse
> users (as opposed to Lisp programmers).

I think something like:

    Also documented in the >Emacs user's manual<.
    Also documented in the >ELisp programmer's reference<.

should be clear enough (where >...< is meant to delimit the hyperlink).


        Stefan

RE: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>> C-h f kill-line
>> put point somewhere on 'kill-line' in the docstring
>> C-h S
>>
>> Now making that more widely known would help, I think.
>
> Yes.  A start is to what I do in `help-mode+.el': change the help-echo 
> on a linked symbol, so it includes mention of `C-h S'.  This trivial 
> change could be made to `help-mode.el'.
>
> IOW, instead of just
>
> "mouse-2, RET: describe this symbol"
>
> say:
>
> "mouse-2, RET: describe, C-h S RET: check manual"
>

This help-echo is not present in all help buffers, I see it only in C-h m 
(describe-mode) buffers.  And it is necessary to put point on the symbol 
before pressing C-h S RET.

Wouldn't a "See also chapter N ZZZZ in the Emacs manual." and/or "For 
programmers, see also chapter N ZZZZ in the Emacs Lisp manual." (with 
hyperlinks) at the end of ordinary help buffers be much more useful?  I 
can only speak for myself, but this is what I would have found useful when 
I started using Emacs.

RE: How to make Emacs popular again.

[Drew Adams]

> >> We could add a "View in Manual" button in Help buffers if info-lookup
> >> says that the symbol is in the Emacs Lisp Info index.
> 
> Yes, it should be fairly easy to do using the
> `help-fns-describe-*-functions` hooks.

That won't help with variable, face, etc. help.

> > For interactive functions (a.k.a. "commands"), there's an ambiguity
> > here: should the link lead to the Emacs user manual or to the Emacs
> > Lisp Reference manual?  We could show both, but that could confuse
> > users (as opposed to Lisp programmers).
> 
> I think something like:
> 
>     Also documented in the >Emacs user's manual<.
>     Also documented in the >ELisp programmer's reference<.
> 
> should be clear enough (where >...< is meant to delimit the hyperlink).

That won't help with functions (vars, faces, etc.)
covered in other manuals: CL, Tramp, Org, Dired-X,
Calc, Ediff, etc.

Re: How to make Emacs popular again.

[Stefan Monnier]

>> I think something like:
>> 
>>     Also documented in the >Emacs user's manual<.
>>     Also documented in the >ELisp programmer's reference<.
>> 
>> should be clear enough (where >...< is meant to delimit the hyperlink).
>
> That won't help with functions (vars, faces, etc.)
> covered in other manuals: CL, Tramp, Org, Dired-X,
> Calc, Ediff, etc.

Why not?  I'd expect them to appear as things like:

     Also documented in >Calc's manual<.


-- Stefan

RE: How to make Emacs popular again.

[Drew Adams]

> >> C-h f kill-line
> >> put point somewhere on 'kill-line' in the docstring
> >> C-h S
> >>
> >> Now making that more widely known would help, I think.
> >
> > Yes.  A start is to what I do in `help-mode+.el': change the help-echo
> > on a linked symbol, so it includes mention of `C-h S'.  This trivial
> > change could be made to `help-mode.el'.
> >
> > IOW, instead of just
> >   "mouse-2, RET: describe this symbol"
> > say:
> >   "mouse-2, RET: describe, C-h S RET: check manual"
> 
> This help-echo is not present in all help buffers, I see it only in C-h m
> (describe-mode) buffers.

I see it generally.  What do you see when you
use `C-h f defcustom' or `C-h v print-circle?
Don't you see links for each of the quoted
(`...') functions and vars?

> And it is necessary to put point on the symbol
> before pressing C-h S RET.

If that's considered a big hurdle then we can
add a mouse binding for it on such links.

> Wouldn't a "See also chapter N ZZZZ in the Emacs manual." and/or "For
> programmers, see also chapter N ZZZZ in the Emacs Lisp manual." (with
> hyperlinks) at the end of ordinary help buffers be much more useful?

For which symbols?  Are you going to add such a
see-also for each quoted name in a `*Help*' buffer?

In general, that's what `C-h S' works on: each such
name.  That is, we generally put links on the names
that `C-h S' will work for.

> I can only speak for myself, but this is what I
> would have found useful when I started using Emacs.

I've long said that we need that for the thing that
is the subject of the `*Help*' buffer.  And we do
have it for some `*Help*' buffers - e.g., `C-h f
defcustom'.

But I don't think it makes sense to add that for
each quoted name that has a help link.

Inline (i.e., in-context) links are better, in
general, than a pile of see-also's at the end of
the buffer.

And we already have such links for recognized
quoted names.  What's missing is providing more
info, or additional navigation possibilities, for
such names.

RE: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>
> I see it generally.  What do you see when you use `C-h f defcustom' or 
> `C-h v print-circle? Don't you see links for each of the quoted (`...') 
> functions and vars?
>

Yes, but not for the most important one: the function/variable/face... 
being described, defcustom or print-circle in your examples.

>> Wouldn't a "See also chapter N ZZZZ in the Emacs manual." and/or "For 
>> programmers, see also chapter N ZZZZ in the Emacs Lisp manual." (with 
>> hyperlinks) at the end of ordinary help buffers be much more useful?
>
> For which symbols?  Are you going to add such a see-also for each quoted 
> name in a `*Help*' buffer?
>

No, only for the main symbol, the symbol whose docstring is being 
displayed in the help buffer.  At least that was the meaning of the 
proposal I sent a few hours ago: to add one (or more) link(s) at the end 
of the docstring pointing to the chapter(s) of the manual(s) in which they 
are documented.

>
> I've long said that we need that for the thing that is the subject of 
> the `*Help*' buffer.
>

Then I agree with you :-)

>
> And we do have it for some `*Help*' buffers - e.g., `C-h f defcustom'.
>

Thank you, this is an excellent example, it is exactly what I meant: a 
link to the chapter of the manual.

>
> Inline (i.e., in-context) links are better, in general, than a pile of 
> see-also's at the end of the buffer.
>

Not a pile, one or two.  The point is to make manuals more accessible.

RE: How to make Emacs popular again.

[Drew Adams]

> >> I think something like:
> >>
> >>     Also documented in the >Emacs user's manual<.
> >>     Also documented in the >ELisp programmer's reference<.
> >>
> >> should be clear enough (where >...< is meant to delimit the hyperlink).
> >
> > That won't help with functions (vars, faces, etc.)
> > covered in other manuals: CL, Tramp, Org, Dired-X,
> > Calc, Ediff, etc.
> 
> Why not?  I'd expect them to appear as things like:
>      Also documented in >Calc's manual<.

I meant that it won't help now (as is, with `Info-lookup').

Yes, links to such manuals would help.

But if we are going to do this for more, or all, names
referred to in *Help*, and not just for the name that's
the subject of the *Help*, then "Also documented in..."
would become a real drag.

Instead, we should let you get to the info in a manual
from the occurrence of the name itself in the buffer,
just as we now do with a link to its own *Help*.  That
is, do it only for quoted (`...'), linked names.

The same link can't go to two different places when you
use the same key (e.g. `mouse-1' or `RET').  But it can
go to a different place (or places) if we provide more
bindings at that location.

E.g., bind `C-h mouse-1' to do it.  (And `C-h S RET'
with point on the link already does it.)  Change the
`help-echo' to indicate this go-to-manual behavior.

Do that and there's no need for umpteen "Also documented
in..." additions to the buffer.  The links are already
there, in context, for each recognized name.

(If we can easily/quickly tell whether a given linked
name `...' is documented in a manual then we can also
omit any `help-echo' about checking the manual for it
when there's no manual that covers it.)

RE: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>>>> I think something like:
>>>>
>>>>     Also documented in the >Emacs user's manual<.
>>>>     Also documented in the >ELisp programmer's reference<.
>>>>
>>>> should be clear enough (where >...< is meant to delimit the hyperlink).
>>>
>>> That won't help with functions (vars, faces, etc.) covered in other 
>>> manuals: CL, Tramp, Org, Dired-X, Calc, Ediff, etc.
>>
>> Why not?  I'd expect them to appear as things like:
>>
>>      Also documented in >Calc's manual<.
>
> I meant that it won't help now (as is, with `Info-lookup').
>
> Yes, links to such manuals would help.
>
> But if we are going to do this for more, or all, names referred to in 
> *Help*, and not just for the name that's the subject of the *Help*, then 
> "Also documented in..." would become a real drag.
>

I don't think anyone here is proposing to do this.

RE: How to make Emacs popular again.

[Drew Adams]

> > I see it generally.  What do you see when you use `C-h f defcustom' or
> > `C-h v print-circle? Don't you see links for each of the quoted (`...')
> > functions and vars?
> 
> Yes, but not for the most important one: the function/variable/face...
> being described, defcustom or print-circle in your examples.

That one should be covered by an explicit sentence with
a link to the manual.  I already mentioned that (and
said I do that in help-fns+.el).

But even that one could be handled instead, or also,
the same way.  It's not quoted (`...'), but it's easy
to find where it is and give it go-to-manual behavior.

> >> Wouldn't a "See also chapter N ZZZZ in the Emacs manual." and/or "For
> >> programmers, see also chapter N ZZZZ in the Emacs Lisp manual." (with
> >> hyperlinks) at the end of ordinary help buffers be much more useful?
> >
> > For which symbols?  Are you going to add such a see-also for each quoted
> > name in a `*Help*' buffer?
> 
> No, only for the main symbol, the symbol whose docstring is being
> displayed in the help buffer.  At least that was the meaning of the
> proposal I sent a few hours ago: to add one (or more) link(s) at the end
> of the docstring pointing to the chapter(s) of the manual(s) in which they
> are documented.

I already addressed that.

> > I've long said that we need that for the thing that is the subject of
> > the `*Help*' buffer.
> 
> Then I agree with you :-)
> 
> > And we do have it for some `*Help*' buffers - e.g., `C-h f defcustom'.
> 
> Thank you, this is an excellent example, it is exactly what I meant: a
> link to the chapter of the manual.
> 
> > Inline (i.e., in-context) links are better, in general, than a pile of
> > see-also's at the end of the buffer.
> 
> Not a pile, one or two.  The point is to make manuals more accessible.

Both would be useful:

1. Link(s) to manual(s) for the name that is the
   subject of the help.  This can be in an explicit
   sentence that makes clear what it does - as
   mentioned earlier.

2. Links to manuals for each quoted, linked name in
   the buffer (or each known to be doc'd in a manual,
   if that's known when the buffer is created).

For #2, such names already have inline links where they
occur.  It suffices to (1) give users an easy way to
get to the manual(s) from that location, preferably by
both mouse and key, and (2) let users know about this
possibility.

The usual way to let users know about possible actions
at the mouse-pointer location is `help-echo': a tooltip
or message in the echo area (depending on
`tooltip-use-echo-area').

RE: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>
> That one should be covered by an explicit sentence with a link to the 
> manual.  I already mentioned that (and said I do that in help-fns+.el).
>

Sorry, I did not know you already do that in help-fns+.el when I answered 
RMS' email a few hours ago.

As I mentioned earlier, there are however two important difference between 
what you do in help-fns+ (which I just tried) and what I proposed:

1. I do not think this can be done programmatically, the meaning of the 
proposal was to do this by adding information in docstrings manually.

2. I do think that a link to the place where the function/variable/... is 
being defined in the manual is the best solution, a link to the chapter 
would be better.  I just tried it with "kill-buffer", the additional 
information (additional wrt to the docstring) I get by entering the two 
manual sections is nil.

>
> But even that one could be handled instead, or also, the same way. 
> It's not quoted (`...'), but it's easy to find where it is and give it 
> go-to-manual behavior.
>

IMO this would not be optimal.  I think an explicit link (like the one at 
the end of the docstring of defcustom) makes it clear that if you follow 
it you leave the "built-in" documentation and open a "manual" (in another 
window).

>> Not a pile, one or two.  The point is to make manuals more accessible.
>
> Both would be useful:
>
> 1. Link(s) to manual(s) for the name that is the subject of the help. 
> This can be in an explicit sentence that makes clear what it does - as 
> mentioned earlier.
>

Yes.

>
> 2. Links to manuals for each quoted, linked name in the buffer (or each 
> known to be doc'd in a manual, if that's known when the buffer is 
> created).
>
> For #2, such names already have inline links where they occur.  It 
> suffices to (1) give users an easy way to get to the manual(s) from that 
> location, preferably by both mouse and key, and (2) let users know about 
> this possibility.
>

Perhaps I don't understand what you mean, but I don't see why this would 
be useful.  The current system (docstrings with links to other docstrings) 
works well.  If links to manual chapters are added at the end of each 
docstring, why would it be necessary to duplicate that information after 
the docstrings that refer to a given docstring?

For example, why would it be useful to add a link (info 
"(elisp)Processes") in kill-buffer because it mentions 'process-buffer', 
when following the link on 'process-buffer' already opens (or rather, 
would open) a help buffer with a link to (info "(elisp)Processes")?

Lists of symbols in the Lisp Manual

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Regarding the Emacs Lisp manual, something that would be helpful is to
  > list the functions, user options, commands, etc. of each chapter at the
  > top or in its own section, so that one doesn't need to go to that
  > specific chapter just to get the forgotten name of a function or one can
  > quickly see all the symbols in one page for a topic.

I have trouble understanding that concretely.  It says to add a list
to each chapter, so that people don't have to go to that chapter.
That seems self-contradictory.

I suppose that you have a coherent idea in mind, and that it involves
adding lots of lists to the manual.

This could make the manual substantially longer and thus substantially
raise the price of the printed manual.  That would be a substantial
drawback.

Is this something that you would only want on line?
If it is only on line, it would not have that drawback.

Scripts could generate those lists by scanning the source of the Lisp
Manual.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > "Hey, did you know Emacs has manuals?  They're really good!
  > There's THIS manual that teaches how to use Emacs, its
  > keys and stuff, and there THIS manual which teaches how
  > to program for Emacs, so you can make your own extensions."

The way we do this now is with the splash screen.

Some people seem to think that that drives users away.  I can't
understand why anyone would be driven away by this, but that doesn't
prove they are wrong.  But is there a better way to do this?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


  > kill-line would have a link to (info "(emacs)Killing")
  > kill-buffer would have two links, one to (info "(emacs)Buffers") and another to (info "(elisp)Buffers")
  > call-process would have a link to (info "(elisp)Processes")

  > I think a link to the relevant chapter, as in the examples above, is 
  > better than a link to the relevant section or subsection.  With this, 
  > users who follow that link would find more information about the general 
  > context of the command or function, and not just a similar documentation.

They are ideas worthy of consideration.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: bobnewell@bobnewell.net,  rms@gnu.org,  rpluim@gmail.com,
>   emacs-devel@gnu.org,  joaotavora@gmail.com,  ghe@sdf.org
> Date: Thu, 08 Oct 2020 22:45:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >
> > For interactive functions (a.k.a. "commands"), there's an ambiguity
> > here: should the link lead to the Emacs user manual or to the Emacs
> > Lisp Reference manual?  We could show both, but that could confuse
> > users (as opposed to Lisp programmers).
> 
> IIRC, info-lookup already has some heuristics to decide between the
> Emacs manual or the Emacs Lisp manual. For example, C-h S on find-file
> opens the Emacs manual (even though the command is indexed on both
> manuals), but C-h S on region-end opens the Emacs Lisp manual.
> 
> Maybe those heuristics are already good enough to make users and ELisp
> programmers happy.

That heuristics is exactly the issue here: it shows the user manual
for a function that is a command.  The suggestion in this thread was
to show the ELisp manual instead, or at least the current heuristics
was deemed to be insufficient based on the fact that the ELisp manual
was not shown.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 08 Oct 2020 17:57:12 -0400
> Cc: bobnewell@bobnewell.net, rms@gnu.org, rpluim@gmail.com, emacs-devel@gnu.org,
>  joaotavora@gmail.com, ghe@sdf.org,
>  Daniel Martín <mardani29@yahoo.es>
> 
> > For interactive functions (a.k.a. "commands"), there's an ambiguity
> > here: should the link lead to the Emacs user manual or to the Emacs
> > Lisp Reference manual?  We could show both, but that could confuse
> > users (as opposed to Lisp programmers).
> 
> I think something like:
> 
>     Also documented in the >Emacs user's manual<.
>     Also documented in the >ELisp programmer's reference<.

And now newcomers might be confused: which of these should they click?

To resolve the confusion, the "Also documented" part should be
replaced by something more specific.  But even then I'm not sure the
confusion will go away completely.  Sometimes it is better to have
only one watch, even if that watch is slightly askew, than having
several ones, each one showing a different time.

Re: How to make Emacs popular again.

[Gregory Heytings via Emacs development discussions.]

>>> We could add a "View in Manual" button in Help buffers if info-lookup 
>>> says that the symbol is in the Emacs Lisp Info index.
>
> Yes, it should be fairly easy to do using the 
> `help-fns-describe-*-functions` hooks.
>
>> For interactive functions (a.k.a. "commands"), there's an ambiguity 
>> here: should the link lead to the Emacs user manual or to the Emacs 
>> Lisp Reference manual?  We could show both, but that could confuse 
>> users (as opposed to Lisp programmers).
>
> I think something like:
>
>    Also documented in the >Emacs user's manual<.
>    Also documented in the >ELisp programmer's reference<.
>
> should be clear enough (where >...< is meant to delimit the hyperlink).
>

Perhaps it would be even clearer as follows (again with the example of 
kill-buffer):

See also `(emacs) Buffers'.  For programmers, see also `(elisp) Buffers'.

Re: How to make Emacs popular again.

[Eli Zaretskii]

> Date: Fri, 09 Oct 2020 07:38:00 +0000
> cc: Eli Zaretskii <eliz@gnu.org>,
>  Daniel Martín <mardani29@yahoo.es>,
>  bobnewell@bobnewell.net, rms@gnu.org, rpluim@gmail.com,
>  emacs-devel@gnu.org, joaotavora@gmail.com
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > I think something like:
> >
> >    Also documented in the >Emacs user's manual<.
> >    Also documented in the >ELisp programmer's reference<.
> >
> > should be clear enough (where >...< is meant to delimit the hyperlink).
> >
> 
> Perhaps it would be even clearer as follows (again with the example of 
> kill-buffer):
> 
> See also `(emacs) Buffers'.  For programmers, see also `(elisp) Buffers'.

"For programmers" is ambiguous (programmers are users as well).  Maybe
something like "For calling from a Lisp program".  And we should have
some adequate qualification for the user-manual link as well, perhaps
"For interactive use".

RE: How to make Emacs popular again.

[Drew Adams]

> > With vanilla Emacs you can use `C-h S' on the subject
> > symbol, but there's no explicit link.  And it works
> > only for the Emacs and Elisp manuals.
> 
> The last sentence is not true, at least not in my testing.

Good to hear; I'm glad to be mistaken about that.

How do you get it to look in other manuals?  E.g.
`C-h S dired-jump' should take you to its coverage
in manual Dired-X.

RE: How to make Emacs popular again.

[Drew Adams]

> > That one should be covered by an explicit sentence with a link to the
> > manual.  I already mentioned that (and said I do that in help-fns+.el).
> 
> Sorry, I did not know you already do that in help-fns+.el when I answered
> RMS' email a few hours ago.
> 
> As I mentioned earlier, there are however two important difference between
> what you do in help-fns+ (which I just tried) and what I proposed:
> 
> 1. I do not think this can be done programmatically, the meaning of the
> proposal was to do this by adding information in docstrings manually.

I don't know what "this" is.  Programmatically adding
a link to the manuals for the symbol that's the subject
of the *Help* is already done (with `help-fns+.el').
Just what do you think can't be done programmatically?

> 2. I do think that a link to the place where the function/variable/... is
> being defined in the manual is the best solution, a link to the chapter
> would be better.  I just tried it with "kill-buffer", the additional
> information (additional wrt to the docstring) I get by entering the two
> manual sections is nil.

I don't understand.  If I click the `manuals' link
in the *Help* output (from `help-fns+.el') for
`C-h f kill-buffer' I go to the manual for that command.

By default you go to the manual per `info-lookup-symbol'.
But you can optionally instead have the link search the
indexes of any set of manuals and show you an Info Index
buffer with links to a hit in each relevant manual.

> > But even that one could be handled instead, or also, the same way.
> > It's not quoted (`...'), but it's easy to find where it is and give it
> > go-to-manual behavior.
> 
> IMO this would not be optimal.  I think an explicit link (like the one at
> the end of the docstring of defcustom) makes it clear that if you follow
> it you leave the "built-in" documentation and open a "manual" (in another
> window).

It need not be only an either/or.  Links at `...'
naturally go to `*Help*' for their symbols.  But it
doesn't hurt to have `help-echo' tell you that, in
addition, `C-h S' takes you to the relevant part of
the Emacs or Elisp manual.

> > Both would be useful:
> >
> > 1. Link(s) to manual(s) for the name that is the subject of the help.
> > This can be in an explicit sentence that makes clear what it does - as
> > mentioned earlier.
> 
> Yes.
> 
> > 2. Links to manuals for each quoted, linked name in the buffer (or each
> > known to be doc'd in a manual, if that's known when the buffer is
> > created).
> >
> > For #2, such names already have inline links where they occur.  It
> > suffices to (1) give users an easy way to get to the manual(s) from that
> > location, preferably by both mouse and key, and (2) let users know about
> > this possibility.
> 
> Perhaps I don't understand what you mean, but I don't see why this would
> be useful.

It would be useful for the same reason that `C-h S'
is useful anywhere.  All this is, is reminding users
(and telling those who would be unaware) that `C-h S'
takes you to the coverage of a symbol in the manual.
As someone else said earlier in this thread, that's
maybe not known widely enough.

It's like the question of why we quote and highlight
defined symbols: `...'.  We do so to let you recognize
that they're defined symbols.  This is so, independent
of the fact that we might also put a link on the symbol
(and we don't always succeed in putting a link on every
relevant occurrence, unfortunately).

> The current system (docstrings with links to other docstrings)
> works well.  If links to manual chapters are added at the end of each
> docstring, why would it be necessary to duplicate that information after
> the docstrings that refer to a given docstring?

See above.

> For example, why would it be useful to add a link (info
> "(elisp)Processes") in kill-buffer because it mentions 'process-buffer',
> when following the link on 'process-buffer' already opens (or rather,
> would open) a help buffer with a link to (info "(elisp)Processes")?

It's useful for the reason given above.

The fact that you can instead, or in addition, visit the
*Help* for that symbol, and then click its "...manual"
link to get to its doc in the manual, doesn't preclude
the usefulness of getting there directly while keeping
the same *Help* open.  The two are orthogonal, even if
they both give you a way to get to the manual.
___

What's still missing, AFAIK:

1. Ability for `info-lookup-symbol' to use an arbitrary
   set of manuals.  Eli has said this is possible, but
   it's not clear to me how.  (I haven't looked for it,
   though.)

2. Ability to get access to matches in multiple manuals.
   `help-fns+.el' lets you do that: you can be shown an
   Info Index buffer with a link for each manual with a
   match.  However:

   a. Only one match is used per manual.
   b. It's not performant: the indexes of a manual are
      searched when you click the link.  Still useful,
      but not very handy.

If `info-lookup-symbol' (or some other function) could
do both of those things in a performant way, that would
be great.

Re: How to make Emacs popular again.

[Daniel Martín]

Drew Adams <drew.adams@oracle.com> writes:
>
> 1. Ability for `info-lookup-symbol' to use an arbitrary
>    set of manuals.  Eli has said this is possible, but
>    it's not clear to me how.  (I haven't looked for it,
>    though.)
>

One way to register new manuals is by calling
`info-lookup-maybe-add-help' to register a new help
specification. Here's how info-lookup recognizes Tramp symbols from
Emacs Lisp buffers, for example:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=99ad65eda44e3b6edcc51cf0fb70ea499c3ccb07

If you are not in an Emacs Lisp buffer, you can always do C-u C-h S and
select `tramp-info-lookup-mode' manually.

RE: How to make Emacs popular again.

[Drew Adams]

> > 1. Ability for `info-lookup-symbol' to use an arbitrary
> >    set of manuals.  Eli has said this is possible, but
> >    it's not clear to me how.  (I haven't looked for it,
> >    though.)
> 
> One way to register new manuals is by calling
> `info-lookup-maybe-add-help' to register a new help
> specification. Here's how info-lookup recognizes Tramp symbols from
> Emacs Lisp buffers, for example:...
> 
> If you are not in an Emacs Lisp buffer, you can always do C-u C-h S and
> select `tramp-info-lookup-mode' manually.

OK, good to know.  It would be good to incorporate
such an ability in an easy-to-specify/use manner.

E.g., in `help-fns+.el' you can just specify a list
of manuals to use, in a user-option.

It sounds like what you describe would need some
encapsulation, massaging, or interfacing, to let
users just do that to make use of specific manuals.

Re: dict - Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Emacs can be and will be installed on various systems, various
  > devices, not every device has the capacity to hold dictionaries, and
  > not every operating system will even have such dictionaries
  > included.

I am sure that is possible, but we are talking about slightly
different questions.  There is no real conflict between what you say
here and what I said.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: dict - Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Doing so would require reinventing the wheel of reading the dictionary
  > files, something that dict servers already implement.  Why not let the
  > server do its job?

The point is, whoever decided to say this was "the server's job"
was following a dangerous design philosophy.  When some job can
be done locally, we should not say that that job belongs to servers.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think we should let the user decide whether such risks are relevant
  > in each and every case, and whether these risks, if they exist, are
  > worth taking.

I agree.  I am not saying users should not be able to talk with servers
for dictionary lookup.  I am discussing a different question;
whether we should designate "use an internet server" as the default
way to do a job for which there is a natural local method.
I say we must never do that, because using the internet should
always be something one makes a special decision to do.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > My point is that this should work even if you don't have
  > > a network connection, provided you have a local copy
  > > of Wiktionary.

  > EWW is not the solution for that use case.

Therefore, we should not say recommend EWW as the primary way
to look up a dictionary definition.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again.

[Tomas Hlavaty]

On Sun 04 Oct 2020 at 10:31, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Stallman <rms@gnu.org>
>> Date: Sat, 03 Oct 2020 23:45:20 -0400
>> 
>>   > We have "M-x eww" to go to Wiktionary directly.
>> 
>> Does using eww imply visiting a web site over the net?
>
> Yes, if the URL is HTTP/HTTPS/FTP.

No, if the URL is file.

Example:
cat "hi there" > /tmp/a.html
eww file:///tmp/a.html

>> My point is that this should work even if you don't have
>> a network connection, provided you have a local copy
>> of Wiktionary.
>
> EWW is not the solution for that use case.

It is not obvious to me why.

For example, I've been using eww with off-line Common Lisp HyperSpec and
it works well.  A key bound to hyperspec-lookup function will simply
open relevant local html file.

A dictionary could work like that too.  Could you please describe the
problems, why eww is not the solution for that use case?

Re: How to make Emacs popular again.

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Sat, 10 Oct 2020 09:24:36 +0200
> 
> >> My point is that this should work even if you don't have
> >> a network connection, provided you have a local copy
> >> of Wiktionary.
> >
> > EWW is not the solution for that use case.
> 
> It is not obvious to me why.

Because for that EWW will need to be taught the relevant protocol,
wouldn't it?  Try this:

  M-x eww RET dict://dict.org RET

What do you get?

> For example, I've been using eww with off-line Common Lisp HyperSpec and
> it works well.  A key bound to hyperspec-lookup function will simply
> open relevant local html file.

EWW does support file:// URLs, that's why showing human-readable files
works.  But that doesn't mean it knows about any URL scheme out there,
it only knows about the ones we taught it.

A dictionary file is not just a human-readable text file, so inserting
its contents in a buffer is not enough to find a word in a dictionary
and show its definition.  You need to write the code which
uncompresses the dictionary, looks up the definition, and displays it.
And once you wrote that code, why use EWW at all for showing word
definitions, instead of having a command that just visits the
dictionary file and does that processing?

IOW, EWW is a handy tool for retrieving content using known URL
schemes.  It makes no sense to me to teach it about a "scheme" that
accesses a local file which needs special processing, because EWW will
not help us do the job, and it is much simpler to just read that file
into a buffer directly.

Re: How to make Emacs popular again.

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

>> One way to register new manuals is by calling
>> `info-lookup-maybe-add-help' to register a new help
>> specification. Here's how info-lookup recognizes Tramp symbols from
>> Emacs Lisp buffers, for example:...
>>
>> If you are not in an Emacs Lisp buffer, you can always do C-u C-h S and
>> select `tramp-info-lookup-mode' manually.
>
> OK, good to know.  It would be good to incorporate
> such an ability in an easy-to-specify/use manner.
>
> E.g., in `help-fns+.el' you can just specify a list
> of manuals to use, in a user-option.
>
> It sounds like what you describe would need some
> encapsulation, massaging, or interfacing, to let
> users just do that to make use of specific manuals.

In Tramp, I've implemented a package-self hook. That is, if Tramp is
loodad, it hooks its manual into info-lookup.

A similar approach could be recommended for other packages.

Best regards, Michael.

Re: How to make Emacs popular again.

[Tomas Hlavaty]

Thanks for clarification.  I see now that there is no html available to
be displayed in eww in the first place.

RE: How to make Emacs popular again.

[Drew Adams]

> >> One way to register new manuals is by calling
> >> `info-lookup-maybe-add-help' to register a new help
> >> specification. Here's how info-lookup recognizes Tramp symbols from
> >> Emacs Lisp buffers, for example:...
> >>
> >> If you are not in an Emacs Lisp buffer, you can always do C-u C-h S and
> >> select `tramp-info-lookup-mode' manually.
> >
> > OK, good to know.  It would be good to incorporate
> > such an ability in an easy-to-specify/use manner.
> >
> > E.g., in `help-fns+.el' you can just specify a list
> > of manuals to use, in a user-option.
> >
> > It sounds like what you describe would need some
> > encapsulation, massaging, or interfacing, to let
> > users just do that to make use of specific manuals.
> 
> In Tramp, I've implemented a package-self hook. That is, if Tramp is
> loodad, it hooks its manual into info-lookup.
> 
> A similar approach could be recommended for other packages.

Sounds good.  However, my thinking (so far) is this:

1. Users, not packages, should decide which manuals
   to search, for this.

2. This should be as easy as possible for users:
   just set an option value to the list of manuals
   they want to use.

On the other hand, if packages need to jump through
some hoops to make their manual even available for
use by `info-lookup-symbol', then yes, that should
be done.  It would preferably be done in some general,
perhaps even automatic, way.

E.g., `info-lookup-symbol' itself should be made open
to an arbitrary list of manuals, and any new manual
should be able to add itself to those known by
`info-lookup' (or that should happen automatically).
But users should be able to easily control which
manuals are actually used.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

One of the reasons Emacs looks kinda old-fashioned is that we use
monospaced fonts all over the place.  Now, when programming and stuff, a
monospaced font is preferred, but in other contexts, it looks pretty
old-fashioned.

So here's my most controversial suggestion ever:

diff --git a/lisp/faces.el b/lisp/faces.el
index 5b7e0a5aee..e6f65a5901 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2553,6 +2553,7 @@ mode-line-faces
 (defface mode-line
   '((((class color) (min-colors 88))
      :box (:line-width -1 :style released-button)
+     :inherit variable-pitch
      :background "grey75" :foreground "black")
     (t
      :inverse-video t))

In addition to looking nicer, it means we can fit more data into the
mode line.

Other obvious candidates for variable-pitching are basically any mode
that displays data in tabular form.  And, of course, the manuals, but
that'll happen by itself once we move from .info to .html.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

On October 11, 2020 8:37:45 AM GMT+03:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> One of the reasons Emacs looks kinda old-fashioned is that we use
> monospaced fonts all over the place.  Now, when programming and stuff,
> a
> monospaced font is preferred, but in other contexts, it looks pretty
> old-fashioned.
> 
> So here's my most controversial suggestion ever:
> 
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
> 
> In addition to looking nicer, it means we can fit more data into the
> mode line.
> 
> Other obvious candidates for variable-pitching are basically any mode
> that displays data in tabular form.  And, of course, the manuals, but
> that'll happen by itself once we move from .info to .html.

We cannot just switch to variable-pitch font and leave the rest unchanged.  Using a variable-pitch font will cause an annoying horizontal movement of the mode-line stuff when some parts change.  For example, moving in the buffer will change the column and line numbers, and everything to the right of that will as result shift slightly in the horizontal direction.

So to use variable pitch fonts here (and in any other tabjlar display), we'd need to use 'align-to' display properties to keep the other parts from moving.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> We cannot just switch to variable-pitch font and leave the rest
> unchanged.  Using a variable-pitch font will cause an annoying
> horizontal movement of the mode-line stuff when some parts change.
> For example, moving in the buffer will change the column and line
> numbers, and everything to the right of that will as result shift
> slightly in the horizontal direction.

The line numbers aren't that big a problem -- the number of digits
rarely change, and all the numbers are the same size in most variable
pitch fonts that are in use for this stuff.

I don't use column number mode, but I switched it on now, and that seems
fine to me, too.

> So to use variable pitch fonts here (and in any other tabjlar
> display), we'd need to use 'align-to' display properties to keep the
> other parts from moving.

After playing with this stuff for half an hour, the only thing that
seemed vaguely disturbing was the U:** stuff at the start.  Adding an
align-to after that would get us most of the way there, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

On October 11, 2020 9:35:39 AM GMT+03:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We cannot just switch to variable-pitch font and leave the rest
> > unchanged.  Using a variable-pitch font will cause an annoying
> > horizontal movement of the mode-line stuff when some parts change.
> > For example, moving in the buffer will change the column and line
> > numbers, and everything to the right of that will as result shift
> > slightly in the horizontal direction.
> 
> The line numbers aren't that big a problem -- the number of digits
> rarely change, and all the numbers are the same size in most variable
> pitch fonts that are in use for this stuff.
> 
> I don't use column number mode, but I switched it on now, and that
> seems
> fine to me, too.

The number of digits in the line number can change a lot if you jump to another place with M-g g or C-x C-x or some other similar command.

And what about the "All/Top/Bot/NN%" part?

And then there are optional displays, like display-time-mode etc.

In any case, I wouldn't rely on what you see with some subset of fonts, this is a general feature we are talking about.

> > So to use variable pitch fonts here (and in any other tabjlar
> > display), we'd need to use 'align-to' display properties to keep the
> > other parts from moving.
> 
> After playing with this stuff for half an hour, the only thing that
> seemed vaguely disturbing was the U:** stuff at the start.  Adding an
> align-to after that would get us most of the way there, I think.

I rather think we should use align-to for all the fields.  Half-measures will come back to bite us down the road.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The number of digits in the line number can change a lot if you jump
> to another place with M-g g or C-x C-x or some other similar command.

That's true, but is also the case today (in huge files).  I think the
only way to see whether it's annoying or not is to try it out on people
and see what they say.

> And what about the "All/Top/Bot/NN%" part?

Ditto.

> And then there are optional displays, like display-time-mode etc.

All the ones that display numbers (and don't change between numbers and
non-numerical data) aren't affected in any reasonable font.

> I rather think we should use align-to for all the fields.
> Half-measures will come back to bite us down the road.

I think we should just gather some feedback first and see what's
annoying and what isn't.  I've now used this for hours :-), and the only
thing I've noticed being even remotely odd is the U:** switching to
U:--, which takes much less space and draws the eye.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

This reminds me, by the way...  I forget if this has been discussed
before or not, but in these cases it'd be handy to have a text property
like, say, (propertize "foo" :min-width 5) (or :min-width (50)), and
have the display engine compute how much space to add to the end.

Would that be much work to add?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>>  (defface mode-line
>>    '((((class color) (min-colors 88))
>>       :box (:line-width -1 :style released-button)
>> +     :inherit variable-pitch
>>       :background "grey75" :foreground "black")

FWIW, I've been using pretty much exactly that for quite a few years now.
I did it mostly to save space, and the main downside for me was that the
`*`s "don't look right" (they're shifted up compared to my monospace
fonts), but I overcame this trauma without too much trouble.

> We cannot just switch to variable-pitch font and leave the rest unchanged.
> Using a variable-pitch font will cause an annoying horizontal movement of
> the mode-line stuff when some parts change.

Never bothered me even a tiny bit.  It's the kind of thing that annoys
me when it happens right where I'm editing, but apparently the modeline
is far enough.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 11 Oct 2020 12:54:06 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The number of digits in the line number can change a lot if you jump
> > to another place with M-g g or C-x C-x or some other similar command.
> 
> That's true, but is also the case today (in huge files).

Yes, but with variable-pitch fonts, it will happen more frequently,
because the width of a space is typically different in these fonts
from the width of digit characters.

> I think the only way to see whether it's annoying or not is to try
> it out on people and see what they say.

I've seen complaints about similar behavior in other contexts, that's
why I raised the issue.

> > And what about the "All/Top/Bot/NN%" part?
> 
> Ditto.

No: these are all 3-character wide, so they take a fixed-width space
with fixed-pitch fonts.  Now it won't.

> > And then there are optional displays, like display-time-mode etc.
> 
> All the ones that display numbers (and don't change between numbers and
> non-numerical data) aren't affected in any reasonable font.

display-time-mode shows AM and PM, though.

> I think we should just gather some feedback first and see what's
> annoying and what isn't.

We _are_ getting feedback: you've got mine ;-)

And others are encouraged to express their views as well.

> I've now used this for hours :-), and the only thing I've noticed
> being even remotely odd is the U:** switching to U:--, which takes
> much less space and draws the eye.

Using :align-to is simple, and could even simplify the mode-line
construction: instead of carefully counting spaces, you will need just
one space with a suitable :align-to.  So I'm not really sure why this
needs an argument.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 11 Oct 2020 13:28:06 +0200
> 
> This reminds me, by the way...  I forget if this has been discussed
> before or not, but in these cases it'd be handy to have a text property
> like, say, (propertize "foo" :min-width 5) (or :min-width (50)), and
> have the display engine compute how much space to add to the end.
> 
> Would that be much work to add?

Let's put it this way: if there's a simple way of adding this, I
cannot think of it.

Btw, if there were such a property, how would you calculate the value
to put there?

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 11 Oct 2020 09:21:46 -0400
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> > We cannot just switch to variable-pitch font and leave the rest unchanged.
> > Using a variable-pitch font will cause an annoying horizontal movement of
> > the mode-line stuff when some parts change.
> 
> Never bothered me even a tiny bit.

So I guess you won't be sending bug reports about it.  But someone
else would, and the measures to avoid that up front are so easy I
don't see why we are arguing.

Re: How to make Emacs popular again: Use monospaced fonts less

[Teemu Likonen]

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

* 2020-10-11 07:37:45+02, Lars Ingebrigtsen wrote:

> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))

Thanks. I think this is a good idea. I included it to my own Emacs
theme.

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: How to make Emacs popular again: Use monospaced fonts less

[Andreas Schwab]

On Okt 11 2020, Lars Ingebrigtsen wrote:

> So here's my most controversial suggestion ever:
>
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
>
> In addition to looking nicer, it means we can fit more data into the
> mode line.

Make sure that the header-line face does *not* inherit the
variable-pitch face.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> Make sure that the header-line face does *not* inherit the
> variable-pitch face.

My header-line face uses the same variable pitch face as my mode line,
so I'm not sure why you say the above.

There are indeed several uses of the header-line that need/want to be
aligned with the buffer's content (typically for tabular formats), which
I bumped into back when I started using a variable pitch face for the
mode/header-lines, but these should be fixed in any case (for those
people like me who use a variable pitch face), and I have indeed fixed
those cases that I saw (e.g. `list-buffers`, `list-packages`,
`csv-mode`, `ses-mode`, ...).


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Andreas Schwab]

On Okt 11 2020, Stefan Monnier wrote:

>> Make sure that the header-line face does *not* inherit the
>> variable-pitch face.
>
> My header-line face uses the same variable pitch face as my mode line,
> so I'm not sure why you say the above.

Try hexl-mode.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>>> Make sure that the header-line face does *not* inherit the
>>> variable-pitch face.
>> My header-line face uses the same variable pitch face as my mode line,
>> so I'm not sure why you say the above.
> Try hexl-mode.

I use `nhexl-mode` ;-)

It should be pretty easy to fix `hexl-mode` to do something like what
`nhexl-mode` does (based on my experience with the various other
packages I fixed over the years).

But at least in `nhexl-mode` I still get a slightly incorrect result in
the "right hand side ASCII area" because the digits of my variable-pitch
font take up a bit more horizontal space than the chars of my monospaced
font, so the "0123456789abcdef" string in the header-line ends up wider
(by ~2 chars) than the 16 monospaced chars below.  Luckily, it's the
last field of the line, so it's not too bothersome, but admittedly
it's unsatisfactory.

I actually played with another approach which was to impose the same
font in `nhexl-mode`s header-line as in the buffer's text, but after
playing with it I decided that I preferred the variable pitch font,
despite its downsides.


        Stefan

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> There are indeed several uses of the header-line that need/want to be
> aligned with the buffer's content (typically for tabular formats), 

Ah, good point.  In this respect a header-line isn't
similar to a mode-line.

(Well, I suppose a mode-line could also have column
"footers" that repeat the column headers or provide
some alternative identification.)

> but these should be fixed in any case

Agreed.  And the fix is (should always be, AFAICT)
pretty simple.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stephen Berman]

On Sun, 11 Oct 2020 14:29:14 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Make sure that the header-line face does *not* inherit the
>> variable-pitch face.
>
> My header-line face uses the same variable pitch face as my mode line,
> so I'm not sure why you say the above.
>
> There are indeed several uses of the header-line that need/want to be
> aligned with the buffer's content (typically for tabular formats), which
> I bumped into back when I started using a variable pitch face for the
> mode/header-lines, but these should be fixed in any case (for those
> people like me who use a variable pitch face), and I have indeed fixed
> those cases that I saw (e.g. `list-buffers`, `list-packages`,
> `csv-mode`, `ses-mode`, ...).

Could you try to make proced work with a variable pitch header-line?  I
tried and failed (bug#1779).

Steve Berman

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> Could you try to make proced work with a variable pitch header-line?
> I tried and failed (bug#1779).

Haven't looked at it yet, but I just pushed an attempt to fix it for
`hexl-mode` (which already had some of the work done).


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> display-time-mode shows AM and PM, though.

I don't think the shift in pixels twice a day will annoy anyone.  :-)

>> I've now used this for hours :-), and the only thing I've noticed
>> being even remotely odd is the U:** switching to U:--, which takes
>> much less space and draws the eye.
>
> Using :align-to is simple, and could even simplify the mode-line
> construction: instead of carefully counting spaces, you will need just
> one space with a suitable :align-to.  So I'm not really sure why this
> needs an argument.

I just didn't want to add any premature complexity here if none is
needed.

But...  Now that you mention it, I don't quite see how to use :align-to
in the mode line (in general).  It takes as a parameter the target
column number (or pixels), so if we want to say "this element should be
at least 80 pixels wide", then we need to know what column/pixel we're
on already, don't we?  Or am I missing something obvious here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> This reminds me, by the way...  I forget if this has been discussed
>> before or not, but in these cases it'd be handy to have a text property
>> like, say, (propertize "foo" :min-width 5) (or :min-width (50)), and
>> have the display engine compute how much space to add to the end.
>> 
>> Would that be much work to add?
>
> Let's put it this way: if there's a simple way of adding this, I
> cannot think of it.

Yeah, the semantics of text properties aren't very well-defined,
either.  I mean, if you have "foo" in the buffer with a :min-width (50)
text property, and then you insert a space in the middle (without any
properties), then both "fo" and "o" would have a separate :min-width
(50) stretch, so presumably would both be that wide.

So that's kinda a mess.

> Btw, if there were such a property, how would you calculate the value
> to put there?

It depends -- for instance, when calculating tabular layouts, I'd know
the number of pixels already.  In the mode line, I'd take 5x
typical-character-width if I wanted to display something that should
typically not take more than 5 characters.

Which is what we do in the mode line already for some of the things that
change lengths, like the line numbers.

OK, here's another random idea for padding variable-pitch elements in
the mode lines in particular:

        (setq mode-line-thing
              `(:propertize
                "some-string"
                :min-width 15))

which could have well-defined semantics, like "this element should have
the width of at least 15 typical characters", and be pretty easy to use?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> Could you try to make proced work with a variable pitch header-line?  I
> tried and failed (bug#1779).

Done.  The right-alignment is still fairly ugly, of course.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Stephen Berman]

On Sun, 11 Oct 2020 18:23:36 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Could you try to make proced work with a variable pitch header-line?  I
>> tried and failed (bug#1779).
>
> Done.  The right-alignment is still fairly ugly, of course.

Thanks!

Steve Berman

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> > display-time-mode shows AM and PM, though.
> 
> I don't think the shift in pixels twice a day will annoy anyone.  :-)

Emacs is already too popular.  Surely it will annoy someone. ;-)

Re: How to make Emacs popular again: Use monospaced fonts less

[Andreas Schwab]

On Okt 11 2020, Stefan Monnier wrote:

>> Make sure that the header-line face does *not* inherit the
>> variable-pitch face.
>
> My header-line face uses the same variable pitch face as my mode line,
> so I'm not sure why you say the above.

header-line overrides all attributes of mode-line anyway.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: How to make Emacs popular again: Use monospaced fonts less

[Ricardo Wurmus]

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

>> Make sure that the header-line face does *not* inherit the
>> variable-pitch face.
>
> My header-line face uses the same variable pitch face as my mode line,
> so I'm not sure why you say the above.
>
> There are indeed several uses of the header-line that need/want to be
> aligned with the buffer's content (typically for tabular formats), which
> I bumped into back when I started using a variable pitch face for the
> mode/header-lines, but these should be fixed in any case (for those
> people like me who use a variable pitch face), and I have indeed fixed
> those cases that I saw (e.g. `list-buffers`, `list-packages`,
> `csv-mode`, `ses-mode`, ...).

mu4e’s *mu4e-headers* buffer has a header line (“Date”, “Flgs”, “List”,
“From”, “Subject”), which no longer lines up with the contents of the
buffer when the mode-line face inherits from variable-pitch.

I suspect that other packages would suffer from the same problem (and we
can’t fix this for them all), so perhaps it would be a good idea to
override the inheritance of header-line by default.

-- 
Ricardo

Re: How to make Emacs popular again: Use monospaced fonts less

[Ricardo Wurmus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> One of the reasons Emacs looks kinda old-fashioned is that we use
> monospaced fonts all over the place.  Now, when programming and stuff, a
> monospaced font is preferred, but in other contexts, it looks pretty
> old-fashioned.
>
> So here's my most controversial suggestion ever:
>
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
>
> In addition to looking nicer, it means we can fit more data into the
> mode line.

I use variable-pitch for EWW, Info, and Org buffers, so I’m generally
happy to see more uses of variable-pitch where monospace isn’t
necessary.  That said, I think it looks a bit out of place to me,
perhaps because I use a serif font for the variable-pitch face.
Variable pitch looks fine in text buffers to me, but on a single line
surrounded by monospaced text it looks a bit odd.

The modeline would benefit from prettification, of course, such as using
icons instead of the more cryptic “U:-*” indicators etc.  But perhaps
variable pitch isn’t the best way to accomplish prettification here.

Another thing I noticed is that only the active modeline has variable
pitch; perhaps all mode line faces (including mode-line-inactive) need
adjustment?

> Other obvious candidates for variable-pitching are basically any mode
> that displays data in tabular form.  And, of course, the manuals, but
> that'll happen by itself once we move from .info to .html.

Will this move only affect Emacs?  Emacs is still the best Info reader
out there and most GNU packages have manuals in Info format.  Reading
other GNU packages’ Info documentation in Emacs would still look odd,
even if the Emacs manual(s) were to be converted to HTML.

Perhaps it would make sense to augment the Info format with extra
information, so that all Info documentation would look better in all
Info readers.

-- 
Ricardo

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> Another thing I noticed is that only the active modeline has variable
> pitch; perhaps all mode line faces (including mode-line-inactive) need
> adjustment?

I think you must be doing something special.
Face `mode-line-inactive' inherits from face
`mode-line'.  After I changed `mode-line' to
use variable-pitch, `mode-line-inactive' had
it also.

> > Other obvious candidates for variable-pitching are basically any mode
> > that displays data in tabular form.

Perhaps NON-variable was meant there?

> > And, of course, the manuals, but
> > that'll happen by itself once we move from .info to .html.

Variable pitch for header-line and mode-line
work fine for me in Info (FWIW).

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 12 Oct 2020 00:14:18 +0200
> 
> But...  Now that you mention it, I don't quite see how to use :align-to
> in the mode line (in general).  It takes as a parameter the target
> column number (or pixels), so if we want to say "this element should be
> at least 80 pixels wide", then we need to know what column/pixel we're
> on already, don't we?

Yes.  But that's how you design tabulated display, don't you?  You
select the coordinate where each column will end, and set tab stops
there, right?

If you are saying that you are used to start with column widths
instead, then just adding them up will give you the goal coordinates
for :align-to.  Am I missing something?

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 12 Oct 2020 00:21:10 +0200
> 
> > Btw, if there were such a property, how would you calculate the value
> > to put there?
> 
> It depends -- for instance, when calculating tabular layouts, I'd know
> the number of pixels already.  In the mode line, I'd take 5x
> typical-character-width if I wanted to display something that should
> typically not take more than 5 characters.

If this is what you already know, then calculating the goal
coordinates for :align-to should be a simple matter of adding up the
column widths.  Right?

> OK, here's another random idea for padding variable-pitch elements in
> the mode lines in particular:
> 
>         (setq mode-line-thing
>               `(:propertize
>                 "some-string"
>                 :min-width 15))
> 
> which could have well-defined semantics, like "this element should have
> the width of at least 15 typical characters", and be pretty easy to use?

This stuff is basically unworkable without having a window in whose
context the string will be shown.  That's because we need metrics of
each character glyph, and that presumes fonts, and that presumes faces
and other stuff.

This is why we use 'display' property: when the text is displayed, we
have this data by definition.  But not when we just have a string.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> mu4e’s *mu4e-headers* buffer has a header line (“Date”, “Flgs”, “List”,
> “From”, “Subject”), which no longer lines up with the contents of the
> buffer when the mode-line face inherits from variable-pitch.
>
> I suspect that other packages would suffer from the same problem (and we

No need to use the conditional: this already affects all users who have
changed their `header-line` (such as yours truly).

The best course of action is to file bug reports for every such case.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Tim Cross]

Just as another data point ....

I'm using spacemacs with the default spacemacs mode-line theme. I added
the following to my .spacemacs config file (I'm using the 'gotham'
theme).

(setq theming-modifications '((gotham (mode-line :inherit variable-pitch))))

This appears to be working well despite the fact spacemacs has a heavily
customised mode-line definition. The spacemacs environment supports a
number of different mode-line themes. I have only tried variable pitch
with the default theme. It looks good. 

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Ricardo Wurmus <rekado@elephly.net> writes:

> Another thing I noticed is that only the active modeline has variable
> pitch; perhaps all mode line faces (including mode-line-inactive) need
> adjustment?

I don't see this -- perhaps you've altered that face yourself?

>> Other obvious candidates for variable-pitching are basically any mode
>> that displays data in tabular form.  And, of course, the manuals, but
>> that'll happen by itself once we move from .info to .html.
>
> Will this move only affect Emacs?

Yes.

> Perhaps it would make sense to augment the Info format with extra
> information, so that all Info documentation would look better in all
> Info readers.

That would require changing all those other Info readers, which isn't
feasible.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> But...  Now that you mention it, I don't quite see how to use :align-to
>> in the mode line (in general).  It takes as a parameter the target
>> column number (or pixels), so if we want to say "this element should be
>> at least 80 pixels wide", then we need to know what column/pixel we're
>> on already, don't we?
>
> Yes.  But that's how you design tabulated display, don't you?  You
> select the coordinate where each column will end, and set tab stops
> there, right?

More or less.  But how would this work for mode lines?  There's nothing
tabular about those, and they move around a lot.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> OK, here's another random idea for padding variable-pitch elements in
>> the mode lines in particular:
>> 
>>         (setq mode-line-thing
>>               `(:propertize
>>                 "some-string"
>>                 :min-width 15))
>> 
>> which could have well-defined semantics, like "this element should have
>> the width of at least 15 typical characters", and be pretty easy to use?
>
> This stuff is basically unworkable without having a window in whose
> context the string will be shown.  That's because we need metrics of
> each character glyph, and that presumes fonts, and that presumes faces
> and other stuff.
>
> This is why we use 'display' property: when the text is displayed, we
> have this data by definition.  But not when we just have a string.

I'm not sure I understand you.  The mode line elements are only used
when we display them, so we know all that stuff, and can apply some
padding after the element if we have a :min-width thing here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Ricardo Wurmus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Another thing I noticed is that only the active modeline has variable
>> pitch; perhaps all mode line faces (including mode-line-inactive) need
>> adjustment?
>
> I don't see this -- perhaps you've altered that face yourself?

Perhaps smart-mode-line did it.  Sorry for the noise.

>>> Other obvious candidates for variable-pitching are basically any mode
>>> that displays data in tabular form.  And, of course, the manuals, but
>>> that'll happen by itself once we move from .info to .html.
>>
>> Will this move only affect Emacs?
>
> Yes.
>
>> Perhaps it would make sense to augment the Info format with extra
>> information, so that all Info documentation would look better in all
>> Info readers.
>
> That would require changing all those other Info readers, which isn't
> feasible.

There aren’t many Info readers, but there are countless .info documents
across GNU and beyond.  Changing the Info format (and Info readers with
it) seems the better choice.

-- 
Ricardo

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 13 Oct 2020 02:35:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But...  Now that you mention it, I don't quite see how to use :align-to
> >> in the mode line (in general).  It takes as a parameter the target
> >> column number (or pixels), so if we want to say "this element should be
> >> at least 80 pixels wide", then we need to know what column/pixel we're
> >> on already, don't we?
> >
> > Yes.  But that's how you design tabulated display, don't you?  You
> > select the coordinate where each column will end, and set tab stops
> > there, right?
> 
> More or less.  But how would this work for mode lines?  There's nothing
> tabular about those, and they move around a lot.

I think if we want to keep the fields in their places, we should
consider the mode line to be tabular.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 13 Oct 2020 02:38:03 +0200
> 
> >>         (setq mode-line-thing
> >>               `(:propertize
> >>                 "some-string"
> >>                 :min-width 15))
> >> 
> >> which could have well-defined semantics, like "this element should have
> >> the width of at least 15 typical characters", and be pretty easy to use?
> >
> > This stuff is basically unworkable without having a window in whose
> > context the string will be shown.  That's because we need metrics of
> > each character glyph, and that presumes fonts, and that presumes faces
> > and other stuff.
> >
> > This is why we use 'display' property: when the text is displayed, we
> > have this data by definition.  But not when we just have a string.
> 
> I'm not sure I understand you.  The mode line elements are only used
> when we display them, so we know all that stuff, and can apply some
> padding after the element if we have a :min-width thing here.

Then perhaps I didn't understand your suggestion: how would the above
be different from what you originally had in mind about :min-width?

Re: How to make Emacs popular again: Use monospaced fonts less

[Juri Linkov]

> So here's my most controversial suggestion ever:
>
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
>
> In addition to looking nicer, it means we can fit more data into the
> mode line.

I tried this, and the mode-line looks much nicer indeed,
but this improvement is unusable because the mode-line jumps
left and right when the buffer is saved, the cursor is moved, etc.

Is it possible to leave monospaced fonts on parts of the mode-line
that change often (mode-line-modified, mode-line-position),
and put variable-pitch only on parts of the mode-line that don't
change often (mode-line-buffer-identification, mode-line-modes…)

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> I tried this, and the mode-line looks much nicer indeed,
> but this improvement is unusable because the mode-line jumps
> left and right when the buffer is saved, the cursor is moved, etc.

FWIW, I don't find it unusable.  (Just one user.)

(So far, my vote would be for face `mode-line' to
inherit from face `variable-pitch'.)

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think if we want to keep the fields in their places, we should
> consider the mode line to be tabular.

I don't think a tabular mode line is something that would be practical.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> >>         (setq mode-line-thing
>> >>               `(:propertize
>> >>                 "some-string"
>> >>                 :min-width 15))

[...]

> Then perhaps I didn't understand your suggestion: how would the above
> be different from what you originally had in mind about :min-width?

When rendering the mode line, Emacs knows what pixel it started the
first glyph of each mode line element on, and it knows where it ends, so
it sounds conceptually sound to add a :min-width spec here (since it can
just insert some space of the required length at the end).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I tried this, and the mode-line looks much nicer indeed,
> but this improvement is unusable because the mode-line jumps
> left and right when the buffer is saved, the cursor is moved, etc.

Do you use a variable-pitch font that has different widths for the
digits?  I didn't think that would be an issue in practice.  What font
do you use?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Protesilaos Stavrou]

On 2020-10-14, 06:05 +0200, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Juri Linkov <juri@linkov.net> writes:
>
>> I tried this, and the mode-line looks much nicer indeed,
>> but this improvement is unusable because the mode-line jumps
>> left and right when the buffer is saved, the cursor is moved, etc.
>
> Do you use a variable-pitch font that has different widths for the
> digits?  I didn't think that would be an issue in practice.  What font
> do you use?

To add to Juri's comment, many typefaces I tested exhibit this
jumpiness: Roboto, FiraGO, Inter, Noto Sans, Open Sans, DejaVu Sans…

I have column-number-mode enabled.  Typing this makes the modeline's
text shift slightly to the left and right, as if it were pulsing.  It is
due to the column count changing.  The effect may be fairly minor, but
is noticeable enough for me not to be able to tolerate it in its current
state.

The effect would be more pronounced (to my eyes, anyway), whenever I
would work towards the bottom of the window, where the text I type is
closer to the modeline.

Perhaps some modeline fields that change often can have a fixed length?

-- 
Protesilaos Stavrou
protesilaos.com

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Protesilaos Stavrou <info@protesilaos.com> writes:

> To add to Juri's comment, many typefaces I tested exhibit this
> jumpiness: Roboto, FiraGO, Inter, Noto Sans, Open Sans, DejaVu Sans…

I'm using DejaVu Sans, and all the digits are the same width here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Protesilaos Stavrou]

On 2020-10-14, 09:09 +0200, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Protesilaos Stavrou <info@protesilaos.com> writes:
>
>> To add to Juri's comment, many typefaces I tested exhibit this
>> jumpiness: Roboto, FiraGO, Inter, Noto Sans, Open Sans, DejaVu Sans…
>
> I'm using DejaVu Sans, and all the digits are the same width here.

True for DejaVu Sans.  Though it is the difference between the width of
a space and a character/digit that causes the issue for me.  Again, this
is minor and subjective.

Note that some typefaces default to proportional spacing for digits.
Some fonts have a "tabular figures" configuration to enable fixed-space
digits.[1] It can be controlled by fontconfig, but that is outside
Emacs' control, as far as I can tell.[2]

[1]: https://en.wikipedia.org/wiki/OpenType_feature_tag_list
[2]: https://www.freedesktop.org/software/fontconfig/fontconfig-user.html

-- 
Protesilaos Stavrou
protesilaos.com

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Protesilaos Stavrou <info@protesilaos.com> writes:

>> I'm using DejaVu Sans, and all the digits are the same width here.
>
> True for DejaVu Sans.  Though it is the difference between the width of
> a space and a character/digit that causes the issue for me.  Again, this
> is minor and subjective.

Yes, with variable width fonts, different characters take up various
amount of space -- that's the point, and will have to be dealt with.

There seemed to be some claims that even totally numerical elements
(that doesn't change the number of digits) also leads to shifts that'll
have to be handled (like display-time-mode), and that just isn't lining
up with my experiences.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Juri Linkov]

>> I tried this, and the mode-line looks much nicer indeed,
>> but this improvement is unusable because the mode-line jumps
>> left and right when the buffer is saved, the cursor is moved, etc.
>
> Do you use a variable-pitch font that has different widths for the
> digits?  I didn't think that would be an issue in practice.  What font
> do you use?

I'm using DejaVu Sans, where all the digits have the same width,
but still with column-number-mode enabled, the mode-line exhibits
jumpiness when the length of the column number changes.

But maybe using monospaced fonts only on these parts of the mode-line
will fix the problem when the rest of the mode-line will use variable-pitch?

Re: How to make Emacs popular again: Use monospaced fonts less

[James Cloos]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

LI> There seemed to be some claims that even totally numerical elements
LI> (that doesn't change the number of digits) also leads to shifts that'll
LI> have to be handled (like display-time-mode), and that just isn't lining
LI> up with my experiences.

Opentype offers both fixed width and proportional digits (not to mention
oldstyle).

Some fonts default to proportinal.  Most to fixed.

DOCCIS is down now so I cannot remind myself how to ensure fixed width digits...

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: How to make Emacs popular again: Use monospaced fonts less

[tomas]

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

On Wed, Oct 14, 2020 at 04:30:48AM -0400, James Cloos wrote:
> >>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> LI> There seemed to be some claims that even totally numerical elements
> LI> (that doesn't change the number of digits) also leads to shifts that'll
> LI> have to be handled (like display-time-mode), and that just isn't lining
> LI> up with my experiences.
> 
> Opentype offers both fixed width and proportional digits (not to mention
> oldstyle).

Fixed width digits do make sense: often you want more than just aligning
a numerical "field" -- you'd like the individual digits to align. This
is an issue at least as old as Metafont (at least whithin our digital
bubble, I'm sure the lead-and-ink typesetters were well aware of that!).

Let's call those fonts the "normal" fonts (with a tip off the hat to
Russel's paradox ;-)

The question here is whether there is a space the width of a digit (for
"normal fonts", that is).

It seems Unicode has a place for that:  U+2007 aka FIGURE SPACE. Whether
those fonts implement that is left as an exercise...

Me? I use fixed fonts on-screen. Actually my eyes very much prefer them.
This might be the result of acclimatisation.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>> I tried this, and the mode-line looks much nicer indeed,
>> but this improvement is unusable because the mode-line jumps
>> left and right when the buffer is saved, the cursor is moved, etc.
> Do you use a variable-pitch font that has different widths for the digits?

The jumps come from the difference of width between the numbers and the
SPC char.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 06:01:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think if we want to keep the fields in their places, we should
> > consider the mode line to be tabular.
> 
> I don't think a tabular mode line is something that would be practical.

All the "other" apps that provide such a "status bar" do treat its
display as tabular: the positions of its parts never move.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 06:03:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >>         (setq mode-line-thing
> >> >>               `(:propertize
> >> >>                 "some-string"
> >> >>                 :min-width 15))
> 
> [...]
> 
> > Then perhaps I didn't understand your suggestion: how would the above
> > be different from what you originally had in mind about :min-width?
> 
> When rendering the mode line, Emacs knows what pixel it started the
> first glyph of each mode line element on, and it knows where it ends, so
> it sounds conceptually sound to add a :min-width spec here (since it can
> just insert some space of the required length at the end).

Yes, this can be done.  But we'd need fort to decide what is the
semantics of this:

  (setq mode-line-thing `(:propertize "%12b" :min-width 10))

IOW, when the format and :min-width contradict, who "wins"?

Or maybe we should re-purpose the WIDTH parameter of such formats to
mean "min-width"?

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 14 Oct 2020 09:53:12 +0200
> Cc: emacs-devel@gnu.org, Juri Linkov <juri@linkov.net>
> 
> Protesilaos Stavrou <info@protesilaos.com> writes:
> 
> >> I'm using DejaVu Sans, and all the digits are the same width here.
> >
> > True for DejaVu Sans.  Though it is the difference between the width of
> > a space and a character/digit that causes the issue for me.  Again, this
> > is minor and subjective.
> 
> Yes, with variable width fonts, different characters take up various
> amount of space -- that's the point, and will have to be dealt with.

I think Protesilaos means SPC the character, not "space" the screen
estate.

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> But maybe using monospaced fonts only on these parts of the mode-line
> will fix the problem when the rest of the mode-line will use variable-
> pitch?

I'd suggest that rather than trying to do something like
that automatically (especially if done in a hard-to-disable
way), we should just try to make it easier for users to apply
a given face to specific parts of the mode-line.

Finding a good way to make that easier would also let users
do other things more easily to parts of the mode-line.

We have mode-line variables, but maybe we need another level,
that takes the string results they provide and lets you
easily apply a function to them.  We have `eval', and you
can pretty much do anything you need to do with the mode-line,
but it's not simple to do things, for most users.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> Yes, this can be done.  But we'd need fort to decide what is the
> semantics of this:
>
>   (setq mode-line-thing `(:propertize "%12b" :min-width 10))

One solution is to not use text-properties, e.g.

    (setq mode-line-format
          '(...
            (:control-width mode-line-buffer-identification
                            :min-width 10 :max-width 30)
            ...
            (:control-width mode-line-position
                            :min-width 10
                            :align 'center)
            ...))

The downside is that this will only work for <foo>-line-format, whereas
this kind of functionality would also be handy within buffer text for
tabular modes like `proced`.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 13:07:42 -0400
> 
> > Yes, this can be done.  But we'd need fort to decide what is the
> > semantics of this:
> >
> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
> 
> One solution is to not use text-properties, e.g.

That's what I suggested: to use the "12" part for that.

> The downside is that this will only work for <foo>-line-format, whereas
> this kind of functionality would also be handy within buffer text for
> tabular modes like `proced`.

Outside of the mode line, I don't know how to implement that easily,
because that would need some kind of looking-back to find where the
text property started.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>> > Yes, this can be done.  But we'd need fort to decide what is the
>> > semantics of this:
>> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>> One solution is to not use text-properties, e.g.
> That's what I suggested: to use the "12" part for that.

That would limit its applicability to to the few % escape sequences
(and would make it more difficult to provide things like centering,
min-width, max-width, ...).

>> The downside is that this will only work for <foo>-line-format, whereas
>> this kind of functionality would also be handy within buffer text for
>> tabular modes like `proced`.
> Outside of the mode line, I don't know how to implement that easily,
> because that would need some kind of looking-back to find where the
> text property started.

Indeed.  Maybe the text-property's value should include the information
of what is the "starting position".


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>> I tried this, and the mode-line looks much nicer indeed,
>>> but this improvement is unusable because the mode-line jumps
>>> left and right when the buffer is saved, the cursor is moved, etc.
>>
>> Do you use a variable-pitch font that has different widths for the
>> digits?  I didn't think that would be an issue in practice.  What font
>> do you use?
>
> I'm using DejaVu Sans, where all the digits have the same width,
> but still with column-number-mode enabled, the mode-line exhibits
> jumpiness when the length of the column number changes.

OK, so you exaggerated a bit.  :-)  Then we're on the same page. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, this can be done.  But we'd need fort to decide what is the
> semantics of this:
>
>   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>
> IOW, when the format and :min-width contradict, who "wins"?

I'd say %12b should win -- :min-width should be used only to add extra
padding if needed.  I think that would be pretty clear semantics...

> Or maybe we should re-purpose the WIDTH parameter of such formats to
> mean "min-width"?

Hm...  *ponder*  I think that perhaps sounds like a complicating
factor.  I mean, semantics-wise.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

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

>> Yes, this can be done.  But we'd need fort to decide what is the
>> semantics of this:
>>
>>   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>
> One solution is to not use text-properties, e.g.

I wasn't really thinking that the :min-width would be translated into
text properties at all here -- it's just an instruction to the mode line
rendering machinery.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>>> Yes, this can be done.  But we'd need fort to decide what is the
>>> semantics of this:
>>>
>>>   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>>
>> One solution is to not use text-properties, e.g.
>
> I wasn't really thinking that the :min-width would be translated into
> text properties at all here -- it's just an instruction to the mode line
> rendering machinery.

I sorry, I guess I read the `:propertize` too literally.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 18:53:31 -0400
> 
> >> > Yes, this can be done.  But we'd need fort to decide what is the
> >> > semantics of this:
> >> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
> >> One solution is to not use text-properties, e.g.
> > That's what I suggested: to use the "12" part for that.
> 
> That would limit its applicability to to the few % escape sequences
> (and would make it more difficult to provide things like centering,
> min-width, max-width, ...).

We'll need to change the mode-line spec anyway, if we decide to go
this way, no matter if it's by a property or by some change in the
format specs.

The advantage of %12b and its ilk is that it solves 2 problems at the
same time: removes the potential contradiction between the width
specification in mode-line-format and this new property; and allows to
get rid of the text property, which is a certain complication.

> >> The downside is that this will only work for <foo>-line-format, whereas
> >> this kind of functionality would also be handy within buffer text for
> >> tabular modes like `proced`.
> > Outside of the mode line, I don't know how to implement that easily,
> > because that would need some kind of looking-back to find where the
> > text property started.
> 
> Indeed.  Maybe the text-property's value should include the information
> of what is the "starting position".

??? How can Lisp know that?  The starting position is needed at pixel
accuracy to be useful.  Mode-line display knows that because it keeps
the string iterator object as it goes from one mode-line element to
the next one, and the iterator object needs to keep track of the
current X coordinate.  So we can record the X coordinate we started
from when we begin to lay out each mode-line element.  But that
doesn't happen in normal text layout.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 08:48:55 +0200
> 
> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
> >
> > IOW, when the format and :min-width contradict, who "wins"?
> 
> I'd say %12b should win -- :min-width should be used only to add extra
> padding if needed.

But so is %12b, no?

> > Or maybe we should re-purpose the WIDTH parameter of such formats to
> > mean "min-width"?
> 
> Hm...  *ponder*  I think that perhaps sounds like a complicating
> factor.  I mean, semantics-wise.

I don't think I see the complications.  Can you elaborate?

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>> >
>> > IOW, when the format and :min-width contradict, who "wins"?
>> 
>> I'd say %12b should win -- :min-width should be used only to add extra
>> padding if needed.
>
> But so is %12b, no?
>
>> > Or maybe we should re-purpose the WIDTH parameter of such formats to
>> > mean "min-width"?
>> 
>> Hm...  *ponder*  I think that perhaps sounds like a complicating
>> factor.  I mean, semantics-wise.
>
> I don't think I see the complications.  Can you elaborate?

I mean, it would be complicated if we did both.  If we just extend
"%12b" to effectively be :min-width, then that'd be fine, I think.
Unless we want to do pixel-based :min-widths, but that's perhaps not so
useful...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> The advantage of %12b and its ilk is that it solves 2 problems at the
> same time: removes the potential contradiction between the width
> specification in mode-line-format and this new property; and allows to
> get rid of the text property, which is a certain complication.

But the %12b approach doesn't let you specify a max/min width for other
elements such as `mode-line-process`, `major-mode, `minor-mode-alist`, ...

>> > Outside of the mode line, I don't know how to implement that easily,
>> > because that would need some kind of looking-back to find where the
>> > text property started.
>> Indeed.  Maybe the text-property's value should include the information
>> of what is the "starting position".
> ??? How can Lisp know that?

Oh, I see we were not talking about the same thing.
Yes, we'd need somehow to walk back the glyph structure to find the
pixel position of the start position of the element.

What I was trying to address is the issue of text properties being
potentially split, so you can't really rely on

    (put-text-property START END 'width 50)

so I was thinking of instead doing something like

    (put-text-property (1- END) END 'relative-end-position (list START 50))

so when the redisplay sees this position, it would walk back the glyphs
to find the nearest one corresponding to START, and then either truncate
the last few glyphs to fit in a width of 50, or add some space to reach
a width of 50.

Of course, on the next day someone would come along and want to use it
with START on another line with the intention to do relative
indentation ;-)

At which point we may prefer to use something like:

    (put-text-property START (1+ START) 'glyph-mark 'my-glyph-mark)
    (put-text-property (1- END) END 'relative-end-position (list 'my-glyph-mark 50))

with the redisplay keeping track somehow(!) of a set of "glyph-marks" seen
in the current window.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 16:07:36 +0200
> 
> >> > Or maybe we should re-purpose the WIDTH parameter of such formats to
> >> > mean "min-width"?
> >> 
> >> Hm...  *ponder*  I think that perhaps sounds like a complicating
> >> factor.  I mean, semantics-wise.
> >
> > I don't think I see the complications.  Can you elaborate?
> 
> I mean, it would be complicated if we did both.  If we just extend
> "%12b" to effectively be :min-width, then that'd be fine, I think.

That is what I intended to propose.

> Unless we want to do pixel-based :min-widths, but that's perhaps not so
> useful...

The idea is to interpret "12" in units of the canonical frame's
character width, and do the calculations in pixels.  I think this is
good enough, as I don't envision a need for Lisp programs to fine-tune
the position at pixel granularity.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 10:21:39 -0400
> 
> Yes, we'd need somehow to walk back the glyph structure to find the
> pixel position of the start position of the element.
> 
> What I was trying to address is the issue of text properties being
> potentially split, so you can't really rely on
> 
>     (put-text-property START END 'width 50)
> 
> so I was thinking of instead doing something like
> 
>     (put-text-property (1- END) END 'relative-end-position (list START 50))
> 
> so when the redisplay sees this position, it would walk back the glyphs
> to find the nearest one corresponding to START, and then either truncate
> the last few glyphs to fit in a width of 50, or add some space to reach
> a width of 50.

I don't think this will be much simpler than just the first method
above: the way to find where the property started is just one
previous-single-property-change call away, right?

Or we could add some new field to the iterator to keep track of the
beginning, and be done with that.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> I don't think this will be much simpler than just the first method
> above: the way to find where the property started is just one
> previous-single-property-change call away, right?

Not necessarily if the property ends up split into two (or
more) sections.

Or rather, yes that's what it would boil down to in the redisplay, but
in terms of resulting behavior we'd have bugs whenever the property span
gets split into several spans.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

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

> Or rather, yes that's what it would boil down to in the redisplay, but
> in terms of resulting behavior we'd have bugs whenever the property span
> gets split into several spans.

Yeah, :min-width as a text property thing is fraught with all kinds of
issues.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 10:48:32 -0400
> 
> > I don't think this will be much simpler than just the first method
> > above: the way to find where the property started is just one
> > previous-single-property-change call away, right?
> 
> Not necessarily if the property ends up split into two (or
> more) sections.

The function has the LIMIT argument.

> Or rather, yes that's what it would boil down to in the redisplay, but
> in terms of resulting behavior we'd have bugs whenever the property span
> gets split into several spans.

If this is a danger, then this feature is not workable at all for
buffer text.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>> Or rather, yes that's what it would boil down to in the redisplay, but
>> in terms of resulting behavior we'd have bugs whenever the property span
>> gets split into several spans.
>
> If this is a danger, then this feature is not workable at all for
> buffer text.

That's why I was suggesting a representation where you don't put
a property on the whole span but only at the beginning and at the end.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 12:25:15 -0400
> 
> >> Or rather, yes that's what it would boil down to in the redisplay, but
> >> in terms of resulting behavior we'd have bugs whenever the property span
> >> gets split into several spans.
> >
> > If this is a danger, then this feature is not workable at all for
> > buffer text.
> 
> That's why I was suggesting a representation where you don't put
> a property on the whole span but only at the beginning and at the end.

That's not the difficulty I had in mind, so your suggestion doesn't
clear the path towards a solution.

The problem is that if the run of text which needs to be "padded" this
way can be split between lines, the problem becomes undefined.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> The problem is that if the run of text which needs to be "padded" this
> way can be split between lines, the problem becomes undefined.

I think we could give it a well-defined meaning.  E.g.

    (put-text-property (1- END) END 'relative-end-position (list START 50))

could mean something like "make sure that END ends up exactly 50 pixels
more to the right than the horizontal pixel position of START".

This way, it could be used for indentation relative to some position
START in some previous line.

Sadly, this email format does not include any notion of margin, so
I can't include the simple&elegant implementation of that feature here.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 14:31:43 -0400
> 
>     (put-text-property (1- END) END 'relative-end-position (list START 50))
> 
> could mean something like "make sure that END ends up exactly 50 pixels
> more to the right than the horizontal pixel position of START".
> 
> This way, it could be used for indentation relative to some position
> START in some previous line.

So you now expect the display engine to look back at previous lines,
not just previous glyphs on the same screen line?  That's against the
heart of the design of the display code: it is required to be able to
start at any point in the buffer text, and go from there forward one
buffer position at a time.  The need to go back sometimes is one
reason why displaying long lines brings Emacs to its knees.

> Sadly, this email format does not include any notion of margin, so
> I can't include the simple&elegant implementation of that feature here.

Looking forward to seeing that implementation soon in a Git repository
near me.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The idea is to interpret "12" in units of the canonical frame's
> character width, and do the calculations in pixels.  I think this is
> good enough, as I don't envision a need for Lisp programs to fine-tune
> the position at pixel granularity.

Yeah, that probably wouldn't be very useful.  So the %12b thing sound
good to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again.

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Eli Zaretskii <eliz@gnu.org> [2020-09-29 17:12]:
>> > Search documentation is separate feature from looking up any technical
>> > or special word in glossary
>> 
>> No, I think it's quite related, especially since the Glossary is part
>> of the manual.
>
> It is related. Let me express myself better, I am proposing a
> function, something like a long click or key press that is then
> searching in the glossary. Maybe underlying Lisp functions can be used
> for that feature.

Would it be possible to make something like Helm occur where I can type
a term as pattern in minibuffer and then helm will show different hits
in a buffer; say something like those ambigious names I don't remember
like dired-file-name-at-point and dired-filename-at-point; or if there
is a function and local varaible with same name; so that docs for
all hits are shown in an helm occur buffer, which I can easiry navigate
when I wish just to skim over what function does? I would prefer that to
C-h f or C-h v.

It is already really awesome to be able to see parameters shown on
modeline when I call a function in minibuffer; and jumping into doch
with C-h ... when I wish to test how something works or see the
implementation in another window is indespensible. I just miss something
to look up docs when I need to clear up what something was when I know
how use it but have maybe forgotten some details (like did I want
string-replace or replace-string? ). Maybe there is already something
like that, I am just not aware of it?

Would be cool for docs, but it would be also very cool for a dictionary
in general; say for pulling a description of a word from different
dictionaries.

Re: How to make Emacs popular again.

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-10-20 16:23]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Eli Zaretskii <eliz@gnu.org> [2020-09-29 17:12]:
> >> > Search documentation is separate feature from looking up any technical
> >> > or special word in glossary
> >> 
> >> No, I think it's quite related, especially since the Glossary is part
> >> of the manual.
> >
> > It is related. Let me express myself better, I am proposing a
> > function, something like a long click or key press that is then
> > searching in the glossary. Maybe underlying Lisp functions can be used
> > for that feature.
> 
> Would it be possible to make something like Helm occur where I can type
> a term as pattern in minibuffer and then helm will show different hits
> in a buffer; say something like those ambigious names I don't remember
> like dired-file-name-at-point and dired-filename-at-point; or if there
> is a function and local varaible with same name; so that docs for
> all hits are shown in an helm occur buffer, which I can easiry navigate
> when I wish just to skim over what function does? I would prefer that to
> C-h f or C-h v.

You just enable helm-mode and do C-h f

Then install Hyperbole package from GNU ELPA and use Action key to
jump to function definitions, very handy! It has also other look up
functions.

> It is already really awesome to be able to see parameters shown on
> modeline when I call a function in minibuffer; and jumping into doch
> with C-h ... when I wish to test how something works or see the
> implementation in another window is indespensible. I just miss something
> to look up docs when I need to clear up what something was when I know
> how use it but have maybe forgotten some details (like did I want
> string-replace or replace-string? ). Maybe there is already something
> like that, I am just not aware of it?
> 
> Would be cool for docs, but it would be also very cool for a dictionary
> in general; say for pulling a description of a word from different
> dictionaries.

It would be.

Re: How to make Emacs popular again.

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-10-20 16:23]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Eli Zaretskii <eliz@gnu.org> [2020-09-29 17:12]:
> >> > Search documentation is separate feature from looking up any technical
> >> > or special word in glossary
> >> 
> >> No, I think it's quite related, especially since the Glossary is part
> >> of the manual.
> >
> > It is related. Let me express myself better, I am proposing a
> > function, something like a long click or key press that is then
> > searching in the glossary. Maybe underlying Lisp functions can be used
> > for that feature.
> 
> Would it be possible to make something like Helm occur where I can type
> a term as pattern in minibuffer and then helm will show different hits
> in a buffer; say something like those ambigious names I don't remember
> like dired-file-name-at-point and dired-filename-at-point; or if there
> is a function and local varaible with same name; so that docs for
> all hits are shown in an helm occur buffer, which I can easiry navigate
> when I wish just to skim over what function does? I would prefer that to
> C-h f or C-h v.

My request to help users define words everywhere in Emacs cannot be
practical. A teaching class or course provider can do that when
necessary. I was thinking that set of definitions could be all updated
in Glossary of the info file, as example, and then various special
words anywhere in Emacs could be quickly defined.

There is no need for that, and Emacs is in true sense already so much
self-documenting.

Now what you mentioned with Helm, it already exists when
{M-x helm-mode RET} is activated.

Then if you try {C-h f} you may see all the functions and narrow
them. There is recommendd helm config, and it includes function
helm-M-x on my right menu key between Alt and Ctrl for anything like M-x

> Would be cool for docs, but it would be also very cool for a dictionary
> in general; say for pulling a description of a word from different
> dictionaries.

I have made 2 step into dictionaries. The package Wordnut that uses
Wordnet dictionary works well with Helm automatically. It shows
possible list of words and user can narrow it or even find those
others interesting.

For dictd versions I think there is no such completion yet, it could
be possible.

-- 
Jean Louis

Re: How to make Emacs popular again.

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-10-20 16:23]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> > * Eli Zaretskii <eliz@gnu.org> [2020-09-29 17:12]:
>> >> > Search documentation is separate feature from looking up any technical
>> >> > or special word in glossary
>> >> 
>> >> No, I think it's quite related, especially since the Glossary is part
>> >> of the manual.
>> >
>> > It is related. Let me express myself better, I am proposing a
>> > function, something like a long click or key press that is then
>> > searching in the glossary. Maybe underlying Lisp functions can be used
>> > for that feature.
>> 
>> Would it be possible to make something like Helm occur where I can type
>> a term as pattern in minibuffer and then helm will show different hits
>> in a buffer; say something like those ambigious names I don't remember
>> like dired-file-name-at-point and dired-filename-at-point; or if there
>> is a function and local varaible with same name; so that docs for
>> all hits are shown in an helm occur buffer, which I can easiry navigate
>> when I wish just to skim over what function does? I would prefer that to
>> C-h f or C-h v.
>
> My request to help users define words everywhere in Emacs cannot be
> practical. A teaching class or course provider can do that when
> necessary. I was thinking that set of definitions could be all updated
> in Glossary of the info file, as example, and then various special
> words anywhere in Emacs could be quickly defined.
>
> There is no need for that, and Emacs is in true sense already so much
> self-documenting.
>
> Now what you mentioned with Helm, it already exists when
> {M-x helm-mode RET} is activated.
>
> Then if you try {C-h f} you may see all the functions and narrow
> them. There is recommendd helm config, and it includes function
> helm-M-x on my right menu key between Alt and Ctrl for anything like M-x
>
>> Would be cool for docs, but it would be also very cool for a dictionary
>> in general; say for pulling a description of a word from different
>> dictionaries.
>
> I have made 2 step into dictionaries. The package Wordnut that uses
> Wordnet dictionary works well with Helm automatically. It shows
> possible list of words and user can narrow it or even find those
> others interesting.
>
> For dictd versions I think there is no such completion yet, it could
> be possible.
Cool, thanks for the answer; I'll investigate more. I am really bad to
look up what is already there sometimes ...

Re: How to make Emacs popular again.

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-10-20 16:23]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> > * Eli Zaretskii <eliz@gnu.org> [2020-09-29 17:12]:
>> >> > Search documentation is separate feature from looking up any technical
>> >> > or special word in glossary
>> >> 
>> >> No, I think it's quite related, especially since the Glossary is part
>> >> of the manual.
>> >
>> > It is related. Let me express myself better, I am proposing a
>> > function, something like a long click or key press that is then
>> > searching in the glossary. Maybe underlying Lisp functions can be used
>> > for that feature.
>> 
>> Would it be possible to make something like Helm occur where I can type
>> a term as pattern in minibuffer and then helm will show different hits
>> in a buffer; say something like those ambigious names I don't remember
>> like dired-file-name-at-point and dired-filename-at-point; or if there
>> is a function and local varaible with same name; so that docs for
>> all hits are shown in an helm occur buffer, which I can easiry navigate
>> when I wish just to skim over what function does? I would prefer that to
>> C-h f or C-h v.
>
> You just enable helm-mode and do C-h f
Not sure what you mean there. I have Helm always enabled :-). C-h f will
jump to function definition if I have it under cursor already. I ment
more like helm-occur, to show a list of functions that have simmilar
names and permutation on words in names (fuzzy search), and then when
moving cursor in helm buffer it would show doc for the function in
another window. C-h f asks you for a precise name; but sure helm completes
the name in help. 

> Then install Hyperbole package from GNU ELPA and use Action key to
> jump to function definitions, very handy! It has also other look up
> functions.
Never used Hyperbole; seems to me like very big package so I am lazy to
install it and get into it. Also feels like a lot of things is already
provided by Org mode so I never really cared to install and learn it.
But that is just my impression by reading their webpage; are there some
unique and really useful features not found elsewhere? 

Re: How to make Emacs popular again.

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-10-27 07:14]:
> > You just enable helm-mode and do C-h f
> Not sure what you mean there. I have Helm always enabled :-). C-h f will
> jump to function definition if I have it under cursor already. I ment
> more like helm-occur, to show a list of functions that have simmilar
> names and permutation on words in names (fuzzy search), and then when
> moving cursor in helm buffer it would show doc for the function in
> another window. C-h f asks you for a precise name; but sure helm completes
> the name in help.

Helm is great package.

Let us say you would have Hyperbole, you would then simply click
action key on following line:
{M-x customize-apropos RET helm SPC fuzzy RET}

and get the helm fuzzy options. without writing the above. 

> > Then install Hyperbole package from GNU ELPA and use Action key to
> > jump to function definitions, very handy! It has also other look up
> > functions.
> Never used Hyperbole; seems to me like very big package so I am lazy to
> install it and get into it. Also feels like a lot of things is already
> provided by Org mode so I never really cared to install and learn it.
> But that is just my impression by reading their webpage; are there some
> unique and really useful features not found elsewhere?

It is not equivalent to Org. There is file to read Why Use {C-h h d w}
and you come back with {C-h h h}. GNU Hyperbole is replacing so many
other new packages that reinvent its features, manages frames,
windows, remembers frame positions, jumps to various links, has per
directory link or button files for quick jumping from file to file,
jumps quickly from emacs-lisp function to its definition or various
other resources and it is not dependent of specific mode such as Org
mode

-- 
Jean Louis

Re: How to make Emacs popular again: Use monospaced fonts less

[Juri Linkov]

>> Could you try to make proced work with a variable pitch header-line?  I
>> tried and failed (bug#1779).
>
> Done.  The right-alignment is still fairly ugly, of course.

Trying to click on the proced header line sometimes sorts a wrong column.

Comparing 'proced-sort-header' with 'tabulated-list-col-sort' shows
that the latter uses '(cdr posn-object)' to get the clicked column,
whereas 'proced' uses more complex logic with 'posn-actual-col-row'
that fails to get the correct aligned column.

This begs the question why proced doesn't use 'tabulated-list-mode'?
Maybe there are some features in proced that are not yet supported
by tabulated-list?

Re: How to make Emacs popular again: Use monospaced fonts less

[Stephen Berman]

On Wed, 02 Dec 2020 23:06:37 +0200 Juri Linkov <juri@linkov.net> wrote:

>>> Could you try to make proced work with a variable pitch header-line?  I
>>> tried and failed (bug#1779).
>>
>> Done.  The right-alignment is still fairly ugly, of course.
>
> Trying to click on the proced header line sometimes sorts a wrong column.
>
> Comparing 'proced-sort-header' with 'tabulated-list-col-sort' shows
> that the latter uses '(cdr posn-object)' to get the clicked column,
> whereas 'proced' uses more complex logic with 'posn-actual-col-row'
> that fails to get the correct aligned column.
>
> This begs the question why proced doesn't use 'tabulated-list-mode'?
> Maybe there are some features in proced that are not yet supported
> by tabulated-list?

This question came up in bug#1779
<20008.59545.186131.208473@gargle.gargle.HOWL>:

From: "Roland Winkler" <winkler@gnu.org>
Subject: Re: bug#1779: 23.0.60; proced with variable-pitch header line
  To: Chong Yidong <cyd@stupidchicken.com>
  Cc: Stephen Berman <stephen.berman@gmx.net>, 1779@debbugs.gnu.org
  Date: Thu, 21 Jul 2011 22:03:53 -0500

  On Thu Jul 21 2011 Chong Yidong wrote:
  > AFAICT, the alignment issue does not occur in Tabulated List mode, which
  > uses :align-to.  In the short run, you might be able to get a clue about
  > the correct fix from there.  In the long run, I think proced.el should
  > be reworked to use Tabulated List mode.

  Thanks, I'll have to find out what Tabulated List mode is doing.
  I am just wondering: In general, proced was much inspired by dired.
  Would you suggest that dired should likewise use Tabulated List mode?

Maybe Roland (added to CC) can weigh in again.

Steve Berman

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 02 Dec 2020 23:06:37 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Stephen Berman <stephen.berman@gmx.net>,
>  Andreas Schwab <schwab@linux-m68k.org>, emacs-devel@gnu.org
> 
> >> Could you try to make proced work with a variable pitch header-line?  I
> >> tried and failed (bug#1779).
> >
> > Done.  The right-alignment is still fairly ugly, of course.
> 
> Trying to click on the proced header line sometimes sorts a wrong column.
> 
> Comparing 'proced-sort-header' with 'tabulated-list-col-sort' shows
> that the latter uses '(cdr posn-object)' to get the clicked column,
> whereas 'proced' uses more complex logic with 'posn-actual-col-row'
> that fails to get the correct aligned column.

Then it's a bug that needs to be fixed, IMO.

Re: How to make Emacs popular again: Use monospaced fonts less

[Juri Linkov]

>> This begs the question why proced doesn't use 'tabulated-list-mode'?
>> Maybe there are some features in proced that are not yet supported
>> by tabulated-list?
>
> This question came up in bug#1779
> <20008.59545.186131.208473@gargle.gargle.HOWL>:
>
> From: "Roland Winkler" <winkler@gnu.org>
> Subject: Re: bug#1779: 23.0.60; proced with variable-pitch header line
>   To: Chong Yidong <cyd@stupidchicken.com>
>   Cc: Stephen Berman <stephen.berman@gmx.net>, 1779@debbugs.gnu.org
>   Date: Thu, 21 Jul 2011 22:03:53 -0500
>
>   On Thu Jul 21 2011 Chong Yidong wrote:
>   > AFAICT, the alignment issue does not occur in Tabulated List mode, which
>   > uses :align-to.  In the short run, you might be able to get a clue about
>   > the correct fix from there.  In the long run, I think proced.el should
>   > be reworked to use Tabulated List mode.
>
>   Thanks, I'll have to find out what Tabulated List mode is doing.
>   I am just wondering: In general, proced was much inspired by dired.
>   Would you suggest that dired should likewise use Tabulated List mode?

IMHO, the difference is that dired is based on the output from external
programs inserted to the buffer as is, whereas proced has an internal
list data that can be provided to tabulated-list.

Re: How to make Emacs popular again: Use monospaced fonts less

[Roland Winkler]

On Wed Dec 2 2020 Stephen Berman wrote:
>   On Thu Jul 21 2011 Chong Yidong wrote:
>   > AFAICT, the alignment issue does not occur in Tabulated List mode, which
>   > uses :align-to.  In the short run, you might be able to get a clue about
>   > the correct fix from there.  In the long run, I think proced.el should
>   > be reworked to use Tabulated List mode.
> 
>   Thanks, I'll have to find out what Tabulated List mode is doing.
>   I am just wondering: In general, proced was much inspired by dired.
>   Would you suggest that dired should likewise use Tabulated List mode?
> 
> Maybe Roland (added to CC) can weigh in again.

I am sorry, there is not much I can contribute to this discussion.
I developed proced in 2008 when, I believe, tabulated list mode did
not yet exist.  In general, I am much in favor of not re-inventing
the wheel.  So even if tabulated list mode cannot yet provide all
the functionality that is useful for proced, it is probably better
if this is provided only once in tabulated list mode, and packages
like proced use it.  I will not miss the handcrafted solutions in
proced.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> One of the reasons Emacs looks kinda old-fashioned is that we use
> monospaced fonts all over the place.  Now, when programming and stuff, a
> monospaced font is preferred, but in other contexts, it looks pretty
> old-fashioned.
>
> So here's my most controversial suggestion ever:
>
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
>
> In addition to looking nicer, it means we can fit more data into the
> mode line.

What happened to this?

I have noticed that the modus themes has the option
`modus-themes-variable-pitch-ui':

    Use proportional fonts (variable-pitch) in UI elements.
    This includes the mode line, header line, tab bar, and tab line.

It is useful if one wants to experiment with how this works in
practice.  Just set it to t and `M-x load-theme RET modus-operandi RET'.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> What happened to this?

I think we wanted to introduce mode line constructs to ensure a minimum
width to elements (like "L13") for those that want that, and somehow
have variable pitch fonts that have numbers of unequal width (uncommon
as those fonts are).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think we wanted to introduce mode line constructs to ensure a minimum
> width to elements (like "L13") for those that want that, and somehow
> have variable pitch fonts that have numbers of unequal width (uncommon
> as those fonts are).

How about installing the attached for the `header-line' face while we
work on sorting out all that?

AFAICT, tabulation already works there (e.g. `tabulated-list-mode'), and
it would allow us to give this some testing before Emacs 28.

[-- Attachment #2: 0001-lisp-faces.el-header-line-Inherit-variable-pitch.patch --]
[-- Type: text/x-diff, Size: 864 bytes --]

From b0a6eb47a30843d66012ee99a2449b935a732ba7 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Mon, 12 Apr 2021 15:08:45 +0200
Subject: [PATCH] * lisp/faces.el (header-line): Inherit variable-pitch.

---
 lisp/faces.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/faces.el b/lisp/faces.el
index 42f4cddfb1..d120852418 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2613,7 +2613,9 @@ mode-line-buffer-id
 
 (defface header-line
   '((default
-     :inherit mode-line)
+      ;; FIXME: This can be changed to inherit only `mode-line' once
+      ;;        that face inherits variable-pitch.
+      :inherit (variable-pitch mode-line))
     (((type tty))
      ;; This used to be `:inverse-video t', but that doesn't look very
      ;; good when combined with inverse-video mode-lines and multiple
-- 
2.30.2

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 12 Apr 2021 08:23:19 -0500
> Cc: emacs-devel@gnu.org
> 
> How about installing the attached for the `header-line' face while we
> work on sorting out all that?

That's an incompatible change, in that it will cause header-line not
necessarily follow mode-line.  Right?

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> That's an incompatible change, in that it will cause header-line not
> necessarily follow mode-line.  Right?

We could do this instead; the effect is the same in emacs -Q:

diff --git a/lisp/faces.el b/lisp/faces.el
index d120852418..c7d9b48d2d 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2615,7 +2615,7 @@ header-line
   '((default
       ;; FIXME: This can be changed to inherit only `mode-line' once
       ;;        that face inherits variable-pitch.
-      :inherit (variable-pitch mode-line))
+      :inherit (mode-line variable-pitch))
     (((type tty))
      ;; This used to be `:inverse-video t', but that doesn't look very
      ;; good when combined with inverse-video mode-lines and multiple

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 12 Apr 2021 10:27:23 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's an incompatible change, in that it will cause header-line not
> > necessarily follow mode-line.  Right?
> 
> We could do this instead; the effect is the same in emacs -Q:
> 
> diff --git a/lisp/faces.el b/lisp/faces.el
> index d120852418..c7d9b48d2d 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2615,7 +2615,7 @@ header-line
>    '((default
>        ;; FIXME: This can be changed to inherit only `mode-line' once
>        ;;        that face inherits variable-pitch.
> -      :inherit (variable-pitch mode-line))
> +      :inherit (mode-line variable-pitch))

I don't see how that is different.

My problem is that this change makes header-line different from
mode-line, which I think is undesirable.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> diff --git a/lisp/faces.el b/lisp/faces.el
>> index d120852418..c7d9b48d2d 100644
>> --- a/lisp/faces.el
>> +++ b/lisp/faces.el
>> @@ -2615,7 +2615,7 @@ header-line
>>    '((default
>>        ;; FIXME: This can be changed to inherit only `mode-line' once
>>        ;;        that face inherits variable-pitch.
>> -      :inherit (variable-pitch mode-line))
>> +      :inherit (mode-line variable-pitch))
>
> I don't see how that is different.

If a list of faces is used, attributes from faces earlier in the list
override those from later faces.

> My problem is that this change makes header-line different from
> mode-line, which I think is undesirable.

Oh, okay.  Yes, that would be the drawback.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 12 Apr 2021 12:29:40 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> > My problem is that this change makes header-line different from
> > mode-line, which I think is undesirable.
> 
> Oh, okay.  Yes, that would be the drawback.

Which is why I prefer that we change the mode-line face (if we thing
using variable-pitch there is a good move), and leave header-line
inheriting from mode-line as before.  Then (a) mode line and header
line will look the same by default, and (b) if someone wants a
different face for both, they just need to change a single face, not 2
of them.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Which is why I prefer that we change the mode-line face (if we thing
> using variable-pitch there is a good move), and leave header-line
> inheriting from mode-line as before.  Then (a) mode line and header
> line will look the same by default, and (b) if someone wants a
> different face for both, they just need to change a single face, not 2
> of them.

Yup; I agree.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Robert Weiner]

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

On Sun, Oct 11, 2020 at 1:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Other obvious candidates for variable-pitching are basically any mode
> that displays data in tabular form.  And, of course, the manuals, but
> that'll happen by itself once we move from .info to .html.
>

Is this a serious statement?  Please don't do that.  I can browse an entire
Info manual easily inside Emacs nicely by pressing the spacebar and delete
only.  I can search entire manuals quickly and move across manuals easily.

Of course, it would be fine to additionally output html format for web
viewing since the Texinfo/Makeinfo package already supports that.

Old fashioned sometimes is better.  If only Scribe had survived, millions
of hours would not have been lost in Word and LaTeX formatting and now the
minimalist Markdown to get worse results.

-- Bob

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

Re: How to make Emacs popular again: Use monospaced fonts less

[tomas]

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

On Sun, Apr 18, 2021 at 11:13:49PM -0400, Robert Weiner wrote:
> On Sun, Oct 11, 2020 at 1:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> > Other obvious candidates for variable-pitching are basically any mode
> > that displays data in tabular form.  And, of course, the manuals, but
> > that'll happen by itself once we move from .info to .html.
> >
> 
> Is this a serious statement?  Please don't do that.  I can browse an entire
> Info manual easily inside Emacs nicely by pressing the spacebar and delete
> only.  I can search entire manuals quickly and move across manuals easily.
> 
> Of course, it would be fine to additionally output html format for web
> viewing since the Texinfo/Makeinfo package already supports that.

Seconded. HTML is (more of) a rendering format. Info is more of a
document structure format. Rendering info to HTML would make sense
for display (for those who enjoy viewing things in the browser).
The other way around... not so much.

I know that this taxonomy is fluid (what is "more" rendering: PS or
PDF? What about SVG?), but I think that most would agree that HTML
is more on the "rendering" side than info.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: How to make Emacs popular again: Use monospaced fonts less

[Kévin Le Gouguec]

Robert Weiner <rsw@gnu.org> writes:

> On Sun, Oct 11, 2020 at 1:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>  Other obvious candidates for variable-pitching are basically any mode
>  that displays data in tabular form.  And, of course, the manuals, but
>  that'll happen by itself once we move from .info to .html.
>
> Is this a serious statement?  Please don't do that.  I can browse an entire Info manual easily inside Emacs nicely by pressing the spacebar and delete only.  I can
> search entire manuals quickly and move across manuals easily.

(Jumping in without having read the whole thread; my apologies if my
reply misses the mark)

FWIW, Emacs's web browser (M-x eww), just like most read-only modes,
supports SPC and DEL for forward and backward page navigation.

Whatever this hypothetical move from .info to .html entails (I don't
think we have seen patches for that yet), I expect the maintainers'
vision is to keep feature parity with the current Info browser, with all
its indexing and searching convenience; I don't think there should be
cause for alarm.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Whatever this hypothetical move from .info to .html entails (I don't
> think we have seen patches for that yet), I expect the maintainers'
> vision is to keep feature parity with the current Info browser, with all
> its indexing and searching convenience; I don't think there should be
> cause for alarm.

Indeed.  I don't think casual users will notice the change from .info to
.html much at all (except getting better rendering).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Mon, 19 Apr 2021 09:55:29 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, rswgnu@gmail.com,
>  emacs-devel <emacs-devel@gnu.org>
> 
> Robert Weiner <rsw@gnu.org> writes:
> 
> > On Sun, Oct 11, 2020 at 1:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> >
> >  Other obvious candidates for variable-pitching are basically any mode
> >  that displays data in tabular form.  And, of course, the manuals, but
> >  that'll happen by itself once we move from .info to .html.
> >
> > Is this a serious statement?  Please don't do that.  I can browse an entire Info manual easily inside Emacs nicely by pressing the spacebar and delete only.  I can
> > search entire manuals quickly and move across manuals easily.
> 
> (Jumping in without having read the whole thread; my apologies if my
> reply misses the mark)
> 
> FWIW, Emacs's web browser (M-x eww), just like most read-only modes,
> supports SPC and DEL for forward and backward page navigation.
> 
> Whatever this hypothetical move from .info to .html entails (I don't
> think we have seen patches for that yet), I expect the maintainers'
> vision is to keep feature parity with the current Info browser, with all
> its indexing and searching convenience; I don't think there should be
> cause for alarm.

I think this sub-thread is based on a misunderstanding.  I think Lars
alluded to the on-going development in the Texinfo quarters, whereby
the goal is to have HTML-based format "on steroids", which will allow
to browse GNU manuals with capable browsers without losing any
functionality we have now in the text-based Info readers.  No one
intends to lose any useful Info features; when the Texinfo developers
are done designing and implementing this, Emacs should examine the
results and see how best to support that.

People who are interested in details should go and read the archives
of bug-texinfo@gnu.org for the past year or so.