Re: Some developement questions

Re: Some developement questions

[Ergus]

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

On Thu, Aug 16, 2018 at 05:15:49PM +0300, Eli Zaretskii wrote:
>
>It does, since Emacs 26.1.  See the emacs-modules feature.

This is an incredibly good new. The documentation maybe does not follow the common format, but it is perfectly fine for me. The sooner you include this in the tutorial the projects/collaborators will use it. Because I was looking around and I couldn't find anything. 

>
>> - What's the actual status for the emacs-guile integration and why is it abandoned since 2015?
>
>AFAIK, no one is actively working on Guile Emacs.  (And Guile itself
>is developed much slower than Emacs is.)
>

Opposite to the previous one this is a terribly sad new. But at least the C API could work for what I wanted. 


>
>We just got a JIT branch a few days ago, please take a look and help
>work towards eventually landing it.
>

I will try it specially for benchmarking. I'm so tired of listening Vim users talking about how fast it is. Hope this could help to reduce the gap.

I would prefer that packages could compile to native code with gcc or so, (not only because of the expected speedup, but also for debugging facilities already available); maybe giving to the user the option to choose between bytecode/JIT/gcc and they will give live to the most successful one, but I understand that this requires a manpower unavailable now.

>
>I'm not sure I understand what you suggest in practical terms here.
>

I just suggest a cleanup/deletion/ deprecation advice in Elpa/Melpa. It is not a programming suggestion, but almost a logistical one. Because for new users it is confusing which package to install and the suggestions in the Wiki are usually the older options. So basically I have the feeling we have a volume of packages unmaintainable for the number of active developers I see. For example most of the documentation suggests to use smex while it is abandoned and the "successor" is amx fully functional and maintained. New users will install smex facing the already solved bugs. But also some new packages will use the old one for new purposes. Younger people need to know emacs from scratch as they grow with other completely different tools. 

>
>Emacs is much more flexible, and different people have different
>needs.
>
Yes, but someone who opens emacs for the first time will open it to edit text and very probably to program, he should have color preferences and for sure he doesn't know how to add packages and the elpa repository (maybe don't even know about about something called elpa), so, the most basic customization options. If comes from vim/nano/gedit he will need some assistance that emacs can bring (not only the tutorial, but evile, bindkeys), but he don't know how get there. Maybe he prefers to use always the terminal version instead of the graphical one, or he will read the manual and something keybinds doesn't work, and blame emacs when tmux was the guilty. 
>
>But that doesn't mean people cannot come up with such proposals.
>Please do propose practical changes, and they will be reviewed.

I really want to, sadly I am totally inexpert using elisp out of my personal configuration. I just started reading the elisp documentation like 2 months ago, and after this I will need to start with the coding styles and so on. So it will take a while before I could contribute in the adult league :( . BTW: Whats the best documentation (from scratch) to learn elisp and the emacs developement environment? Do you have anything like for example: "The Linux Programming Interface" from "Michael Kerrisk" but for Emacs? 

Very thanks for your previous reply.
Ergus

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

Re: Some developement questions

[Eli Zaretskii]

> Date: Fri, 17 Aug 2018 20:49:48 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> I just suggest a cleanup/deletion/ deprecation advice in Elpa/Melpa. It is not a programming suggestion, but
> almost a logistical one. Because for new users it is confusing which package to install and the suggestions in
> the Wiki are usually the older options. So basically I have the feeling we have a volume of packages
> unmaintainable for the number of active developers I see. For example most of the documentation suggests
> to use smex while it is abandoned and the "successor" is amx fully functional and maintained. New users will
> install smex facing the already solved bugs. But also some new packages will use the old one for new
> purposes. Younger people need to know emacs from scratch as they grow with other completely different
> tools. 

This is a volunteer project.  Someone with motivation and time on
their hands should (and is welcome to) start a project of better and
more up-to-date documentation of available packages.  One possible
place to let users access this is when they use package.el to browse
the list of available packages and decide what they want to install.

> >Emacs is much more flexible, and different people have different
> >needs.
> >
> Yes, but someone who opens emacs for the first time will open it to edit text and very probably to program, he
> should have color preferences and for sure he doesn't know how to add packages and the elpa repository
> (maybe don't even know about about something called elpa), so, the most basic customization options. If
> comes from vim/nano/gedit he will need some assistance that emacs can bring (not only the tutorial, but
> evile, bindkeys), but he don't know how get there. Maybe he prefers to use always the terminal version instead
> of the graphical one, or he will read the manual and something keybinds doesn't work, and blame emacs
> when tmux was the guilty. 

Exactly my point: you have just enumerated at least 3 different
classes of users, and the solution is different for every one of them.
Finding a way of being friendly to each class is the problem to solve.
One possible solution could be groups of Custom options that are
likely to be relevant to each class of users, and writing
customization commands that target each class.  Patches are welcome.

> BTW: Whats the best documentation (from
> scratch) to learn elisp and the emacs developement environment? Do you have anything like for example:
> "The Linux Programming Interface" from "Michael Kerrisk" but for Emacs? 

Take a look at Introduction to Programming in Emacs Lisp, it comes
with Emacs.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

> [...]
>> >Emacs is much more flexible, and different people have different
>> >needs.
>> >
>> Yes, but someone who opens emacs for the first time will open it to edit text and very probably to program, he
>> should have color preferences and for sure he doesn't know how to add packages and the elpa repository
>> (maybe don't even know about about something called elpa), so, the most basic customization options. If
>> comes from vim/nano/gedit he will need some assistance that emacs can bring (not only the tutorial, but
>> evile, bindkeys), but he don't know how get there. Maybe he prefers to use always the terminal version instead
>> of the graphical one, or he will read the manual and something keybinds doesn't work, and blame emacs
>> when tmux was the guilty. 
>
> Exactly my point: you have just enumerated at least 3 different
> classes of users, and the solution is different for every one of them.
> Finding a way of being friendly to each class is the problem to solve.
> One possible solution could be groups of Custom options that are
> likely to be relevant to each class of users, and writing
> customization commands that target each class.  Patches are welcome.

How about including a number of ~/.emacs files, containing options
supposed to make things easier for a class of users --- or include
groups of ~/.emacs files so that for any given class, there can be many
configurations to pick from within a group?

Maybe that can (needs to) be done with existing package management,
including the things users have written themselves and use with their
configurations.

It would also make a great resource for learning.

>> BTW: Whats the best documentation (from
>> scratch) to learn elisp and the emacs developement environment? Do you have anything like for example:
>> "The Linux Programming Interface" from "Michael Kerrisk" but for Emacs? 
>
> Take a look at Introduction to Programming in Emacs Lisp, it comes
> with Emacs.

That would be my recommendation, too, plus elisp written by others.

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: Ergus <spacibba@aol.com>,  emacs-devel@gnu.org
> Date: Wed, 22 Aug 2018 14:34:26 +0200
> 
> > Exactly my point: you have just enumerated at least 3 different
> > classes of users, and the solution is different for every one of them.
> > Finding a way of being friendly to each class is the problem to solve.
> > One possible solution could be groups of Custom options that are
> > likely to be relevant to each class of users, and writing
> > customization commands that target each class.  Patches are welcome.
> 
> How about including a number of ~/.emacs files, containing options
> supposed to make things easier for a class of users --- or include
> groups of ~/.emacs files so that for any given class, there can be many
> configurations to pick from within a group?

IMO, that would be too radical, because in an init file each option
already has a value.  So we will have to decide for the users whether
or not they want certain options to have certain values.  That might
work for boolean options, but many options in Emacs are non-boolean.
As just one example, consider display-line-numbers-mode -- it has
between 3 and 4 different styles, so which one would you put in the
.emacs?

By contrast, by creating a group of options, we don't need to decide
for the users what values of which options they like; we just make the
options we think are relevant for them more easily discoverable.

I also think that browsing through a Custom buffer is more
user-friendly than telling the users to find their way through several
files.

Thanks.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: Ergus <spacibba@aol.com>,  emacs-devel@gnu.org
>> Date: Wed, 22 Aug 2018 14:34:26 +0200
>> 
>> > Exactly my point: you have just enumerated at least 3 different
>> > classes of users, and the solution is different for every one of them.
>> > Finding a way of being friendly to each class is the problem to solve.
>> > One possible solution could be groups of Custom options that are
>> > likely to be relevant to each class of users, and writing
>> > customization commands that target each class.  Patches are welcome.
>> 
>> How about including a number of ~/.emacs files, containing options
>> supposed to make things easier for a class of users --- or include
>> groups of ~/.emacs files so that for any given class, there can be many
>> configurations to pick from within a group?
>
> IMO, that would be too radical, because in an init file each option
> already has a value.  So we will have to decide for the users whether
> or not they want certain options to have certain values.  That might
> work for boolean options, but many options in Emacs are non-boolean.
> As just one example, consider display-line-numbers-mode -- it has
> between 3 and 4 different styles, so which one would you put in the
> .emacs?

Use the values you would you put for the particular use case the file is
designed for.

I didn´t know that there´s a mode displaying line numbers that has
styles; I´ve only used linum-mode so far.  It would be interesting to
learn about this from a file.

> By contrast, by creating a group of options, we don't need to decide
> for the users what values of which options they like; we just make the
> options we think are relevant for them more easily discoverable.

But then, the users can be overwhelmed by a multitude of options and
may have trouble figuring out which ones to change and which values to
set.


When customize was introduced, I tried it out and got totally lost in
it.  I got taken from one buffer to another and figured this isn´t
useful at all unless you already exactly know what you´re looking for.
Even then, it´s difficult to find.

The only thing I sometimes use customize for is setting the default
font, and that is /very/ difficult to find because I never think of
"face" when trying to pick a font.  (Only yesterday I found out that
setting the default font is now easy because there´s an entry in the
menu which works great.  A long time ago, I disabled the menu bar, and
I usually don´t run 'emacs -q' ...)

How do you customize key bindings and add your own elisp?


> I also think that browsing through a Custom buffer is more
> user-friendly than telling the users to find their way through several
> files.

They don´t need to do that.  You offer them to use one of the
configurations in the LaTeX group for working with LaTeX and to use one
of the configurations in the C++ group when writing C++ source code, and
so on.

Users may be happy when they can try some different configurations, pick
one they like and go from there --- rather than having to figure it out
all at once all by themselves.


Configuring Emacs is kinda like configuring fvwm, and it was
fvwm-crystal that brought me back to fvwm after using enlightenment for
a long time.  Fvwm-crystal is like a pre-defined configuration for fvwm,
with a few customization options to choose from.  It didn´t take long
before I wanted to create my own configuration, so I did, learning from
the docs and other configurations.  I ended up with a window manager
that *finally* manages the windows for me rather than forcing me to
manage the windows --- and any time I want to change something, I can
just do that.  Why would I put up with anything less?

So what I suggest is more like giving users a choice between fvwms
default configuration, fvwm-nightshade, fvwm-crystal and others for
Emacs, rather than forcing users to try to find their way through
configuration files or options.  They may discover Emacs over time,
starting from something useful they like, and it probably won´t take
long before they aren´t willing to put up with anything less than Emacs
(unless they like vi maybe).

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Wed, 22 Aug 2018 18:37:54 +0200
> 
> > IMO, that would be too radical, because in an init file each option
> > already has a value.  So we will have to decide for the users whether
> > or not they want certain options to have certain values.  That might
> > work for boolean options, but many options in Emacs are non-boolean.
> > As just one example, consider display-line-numbers-mode -- it has
> > between 3 and 4 different styles, so which one would you put in the
> > .emacs?
> 
> Use the values you would you put for the particular use case the file is
> designed for.

They all are.  The selection depends on user preferences and habits.

> I didn´t know that there´s a mode displaying line numbers that has
> styles; I´ve only used linum-mode so far.  It would be interesting to
> learn about this from a file.

You can learn about it from the Emacs manual, of course.

> > By contrast, by creating a group of options, we don't need to decide
> > for the users what values of which options they like; we just make the
> > options we think are relevant for them more easily discoverable.
> 
> But then, the users can be overwhelmed by a multitude of options and
> may have trouble figuring out which ones to change and which values to
> set.

They don't need to consider all of them.  They can take them one at a
time.  The documentation should tell them enough to make the decision,
perhaps after some experimenting.  Then they can go to the next
option.

IOW, the collection is just a device to enhance discoverability, in
presenting the options some class of users are likely to benefit from.

> When customize was introduced, I tried it out and got totally lost in
> it.  I got taken from one buffer to another and figured this isn´t
> useful at all unless you already exactly know what you´re looking for.
> Even then, it´s difficult to find.

That's the purpose of presenting a relatively small group of options,
out of many hundreds we have.

> How do you customize key bindings and add your own elisp?

I write Lisp.  But I'm not a user of the kind we are talking about, so
what I do have little relevance here.

> They don´t need to do that.  You offer them to use one of the
> configurations in the LaTeX group for working with LaTeX and to use one
> of the configurations in the C++ group when writing C++ source code, and
> so on.

We already have that: each mode file includes options for that mode.
What will we gain by having another file with those same options?

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Wed, 22 Aug 2018 18:37:54 +0200
>> 
>> > IMO, that would be too radical, because in an init file each option
>> > already has a value.  So we will have to decide for the users whether
>> > or not they want certain options to have certain values.  That might
>> > work for boolean options, but many options in Emacs are non-boolean.
>> > As just one example, consider display-line-numbers-mode -- it has
>> > between 3 and 4 different styles, so which one would you put in the
>> > .emacs?
>> 
>> Use the values you would you put for the particular use case the file is
>> designed for.
>
> They all are.  The selection depends on user preferences and habits.
>
> [...]
>
>> They don´t need to do that.  You offer them to use one of the
>> configurations in the LaTeX group for working with LaTeX and to use one
>> of the configurations in the C++ group when writing C++ source code, and
>> so on.
>
> We already have that: each mode file includes options for that mode.
> What will we gain by having another file with those same options?

The gain would be that the user can pick between *sets* of settings,
guided by a description of what each set does.  He doesn't need to
concern himself with any particular setting to figure out if changing it
brings him closer to what he wants, and then experiment with the next
and the next and the next until he tried all the ones he could find.
That kind of learning can come later.

I think I see your point to assume that the defaults are good and to
present the user with the individual settings and to let him learn and
make his own decisions because everyone is too different to do anything
else.  That's great when the new user uses Emacs because he wants to
learn how to use it, and it might not be so good when he wants to use
Emacs to get some work done while the defaults happen not to be good for
him: Even better when he can simply switch to a set of settings that
helps him with his work without having to go through all the trial and
error otherwise needed to get there.

Does that make sense?

Re: Some developement questions

[Ergus]

Hi:

When I asked about this I had in mind more or less what hd is proposing.

A simple config helper specially for newer users. I see for example what
Spacemacs does the first time I started it; and I thing it is a very
good approach for the new user. But I don't like the excess of
layers they added to the configurations after that; because it
that the configuration experience feels too different and
complicated.

On the other hand, if emacs starts without a config .emacs or init.el it
is a hint that probably is a new user or a new machine or a frequent
user in a hurry, time to configure everything. In this situations emacs
could ask if he wants some help to create a simple BUT personalized
configuration. **if yes** just start a dialog or interactive functions
calls that makes him some simple questions with comments about the
different choices. And then generate a basic init.el. Nothing more
complicated than that.

This could be useful not only because it can attract new emacs users
giving a better initial experience less intimidating (elisp seemed like
Sanskrit the first time I saw it), but also because the first time a new
user opens emacs he could get an idea about the potential without
needing to read a full manual to have line numbers, tutorial, google,
emacs wiki... Consider that many people come from limited editors, so
they don't even know that they can make much more with emacs.

Something like this could be useful because:

1) We could have some feedback about which options are most used and which packages are more suitable.

2) The default options and changes are not always properly documented or google gives older documentation for them.

3) Almost everybody changes some default options like C indentation, add packages, change colors or require some lisp lines which is
just too much for a user that wants probably to make his first hello world.

4) Many configurations available online like the availables on github are very complicated with many dependencies, with too many irrelevant details in some aspects; and the risk to become or being already abandoned. If its creator is a C programmer maybe he don't need to improve the python mode. 

5) Newer users will start looking for ways to improve they modes in google and they will end coping random code from random places to their config, ending with a broken/useless/inefficient or deprecated configuration; which means a bad user experience and a potential migration to vim or something worst.

6) There are multiple packages that do exactly the same thing and it is sometimes very confusing to pick one (or even to know if we need it) because the documentation is obsolete or incomplete. Imagine newer users installing flycheck+flymake+company+autocomplete because they just read all the recommendations and they copy from here and there. But without irony or gtags o ctags they don't really get the experience they are really looking for. Or maybe the user needs a python mode and he will install jedi, and copy the config from someone with company... Or installing ivy+helm and not using any of them because he didn't configure. Or downloading some packages and installing them manually because the don't know we have a package manager and the wiki says "download from bla bla bla". 

I thing we could even make like a survey or ask in the mailing list to the clients about what they include in their config usually. So we can know what to ask because is important, and what is not relevant in most of the cases. It is a good idea to ask what the actual users want to see in the next releases.

This is just my opinion. Sorry for the extension and not knowing how to write code for doing such a thing myself.



On Thu, Aug 23, 2018 at 12:17:11AM +0200, hw wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: hw <hw@adminart.net>
>>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>>> Date: Wed, 22 Aug 2018 18:37:54 +0200
>>>
>>> > IMO, that would be too radical, because in an init file each option
>>> > already has a value.  So we will have to decide for the users whether
>>> > or not they want certain options to have certain values.  That might
>>> > work for boolean options, but many options in Emacs are non-boolean.
>>> > As just one example, consider display-line-numbers-mode -- it has
>>> > between 3 and 4 different styles, so which one would you put in the
>>> > .emacs?
>>>
>>> Use the values you would you put for the particular use case the file is
>>> designed for.
>>
>> They all are.  The selection depends on user preferences and habits.
>>
>> [...]
>>
>>> They don�t need to do that.  You offer them to use one of the
>>> configurations in the LaTeX group for working with LaTeX and to use one
>>> of the configurations in the C++ group when writing C++ source code, and
>>> so on.
>>
>> We already have that: each mode file includes options for that mode.
>> What will we gain by having another file with those same options?
>
>The gain would be that the user can pick between *sets* of settings,
>guided by a description of what each set does.  He doesn't need to
>concern himself with any particular setting to figure out if changing it
>brings him closer to what he wants, and then experiment with the next
>and the next and the next until he tried all the ones he could find.
>That kind of learning can come later.
>
>I think I see your point to assume that the defaults are good and to
>present the user with the individual settings and to let him learn and
>make his own decisions because everyone is too different to do anything
>else.  That's great when the new user uses Emacs because he wants to
>learn how to use it, and it might not be so good when he wants to use
>Emacs to get some work done while the defaults happen not to be good for
>him: Even better when he can simply switch to a set of settings that
>helps him with his work without having to go through all the trial and
>error otherwise needed to get there.
>
>Does that make sense?
>

Re: Some developement questions

[hw]

Ergus <spacibba@aol.com> writes:

> 4) Many configurations available online like the availables on github
> are very complicated with many dependencies, with too many irrelevant
> details in some aspects; and the risk to become or being already
> abandoned. If its creator is a C programmer maybe he don't need to
> improve the python mode. 

Doesn't the package installer handle dependencies?

Re: Some developement questions

[Ergus]

On Thu, Aug 23, 2018 at 12:50:54PM +0200, hw wrote:
>Ergus <spacibba@aol.com> writes:
>
>> 4) Many configurations available online like the availables on github
>> are very complicated with many dependencies, with too many irrelevant
>> details in some aspects; and the risk to become or being already
>> abandoned. If its creator is a C programmer maybe he don't need to
>> improve the python mode.
>
>Doesn't the package installer handle dependencies?
>
>
It depends of who created the configuration and how he did it. With ""require" we get an error not an automatic install, use-package fixes this.

But before that, the problem is to configure the package manager; add elpa and melpa, initialize... A new user doesn't know how to do that. Also consider the disadvantage that emacs is not default in any Linux distribution which represent a starting complexity level for new users and the wikipage is outdated specially about simpler basic aspects. That's the real reason why vim is winning young users and sadly emacs is not. The first impression.

For some packages the package manager solves some dependencies but not always because they could use multiple alternatives or may be used as a backend for others (for example smex). So the default is not to provide anyone.

Example: Jedi is a plugin for autocomplete, but company uses company-jedi and NOT jedi itself, company doesn't depend of it, but most company and python users may like to have jedi or anaconda, so the default alternative is not to provide anyone not elpy either; so a new python user will have the same experience like for example a notepad user until he learns elisp; in the packages manager jedi is not documented and it doesn't contain a link, in spite of it requires some not trivial configuration to set it up. So even if the new user had time, patience and abilities to configure and open the package manager, add melpa, install jedi, but not configure it or use autocomplete, nothing will work for him. This is very error prone.

Assuming that the defaults are always right is an unrealistic assumption. Many default options and packages are rarely what most of long time emacs' users like or prefer, so, how to explain this to newbies: vile vs evil-mode, the default C indentation is the gnu while 99% of the users prefer K&R, linux kernel or google's.

The excess of alternatives is also a source of confusion (gtags-ctags-rtags, company-autocomplete, flymake-flycheck, irony-rtags-ycmd, anaconda-jedi, Helm-ivy+counsel-ido_mode. smex-amx, package-paradox). Sometimes we need to think as new users not as developers or experiences users for the future of emacs.

Re: Some developement questions

[Eli Zaretskii]

> Date: Thu, 23 Aug 2018 02:20:59 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> A simple config helper specially for newer users. I see for example what
> Spacemacs does the first time I started it; and I thing it is a very
> good approach for the new user. But I don't like the excess of
> layers they added to the configurations after that; because it
> that the configuration experience feels too different and
> complicated.

The fact that distributions like Spacemacs don't quite succeed to
achieve the goals you have in mind might mean that achieving them is
hard or even impossible in practice.  Something to think about, I
guess.

> This could be useful not only because it can attract new emacs users
> giving a better initial experience less intimidating (elisp seemed like
> Sanskrit the first time I saw it), but also because the first time a new
> user opens emacs he could get an idea about the potential without
> needing to read a full manual to have line numbers, tutorial, google,
> emacs wiki... Consider that many people come from limited editors, so
> they don't even know that they can make much more with emacs.

The motivation is clear and agreed to; it's the practical
implementation of these ideas that isn't quite clear, to say the
least.  As written earlier in this thread, I envision practical
difficulties on the way towards this goal.  Whether it can be achieved
can only be decided by trying to do it.

> 1) We could have some feedback about which options are most used and which packages are more suitable.

We encourage users to report this stuff to the Emacs issue tracker.

> 2) The default options and changes are not always properly documented or google gives older documentation for them.

They should be generally well documented in the manuals that come with
Emacs and in the built-in doc string (barring bugs that should be
reported as such).  Searching for the documentation on the net will
generally bring less accurate and sometimes misleading results.

> 3) Almost everybody changes some default options like C indentation, add packages, change colors or require some lisp lines which is
> just too much for a user that wants probably to make his first hello world.

FWIW, I don't customize indentation, in any of the languages I edit in
Emacs.  YMMV.

As for colors and fonts: sure, everybody customizes them to some
extent.  But how can you propose non-default customizations for these,
when it's a matter of personal taste, the type and quality of your
monitor, and the fonts installed on your system?  The defaults in this
area try to cater to the majority of users, and I really cannot see
how it would be possible to do better with matters of appearance.  And
if it is possible, we should simply change the defaults.

> This is just my opinion. Sorry for the extension and not knowing how to write code for doing such a thing myself.

Thank you for speaking up, it's IMO important to maintain dialog on
these topics.

Re: Some developement questions

[Pierre Neidhardt]

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

May be related to this thread:

	http://emacs-bootstrap.com/

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Thu, 23 Aug 2018 00:17:11 +0200
> 
> I think I see your point to assume that the defaults are good and to
> present the user with the individual settings and to let him learn and
> make his own decisions because everyone is too different to do anything
> else.  That's great when the new user uses Emacs because he wants to
> learn how to use it, and it might not be so good when he wants to use
> Emacs to get some work done while the defaults happen not to be good for
> him: Even better when he can simply switch to a set of settings that
> helps him with his work without having to go through all the trial and
> error otherwise needed to get there.
> 
> Does that make sense?

It might.  However, the proverbial proof of the pudding is in eating
it: I look forward to seeing concrete proposals of sets of non-default
settings that cater to certain users.  Then we could perhaps discuss
this further based on practical proposals, and see whether and how to
incorporate that into Emacs.

Thanks.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Thu, 23 Aug 2018 00:17:11 +0200
>> 
>> [...]
>> him: Even better when he can simply switch to a set of settings that
>> helps him with his work without having to go through all the trial and
>> error otherwise needed to get there.
>> 
>> Does that make sense?
>
> It might.  However, the proverbial proof of the pudding is in eating
> it: I look forward to seeing concrete proposals of sets of non-default
> settings that cater to certain users.  Then we could perhaps discuss
> this further based on practical proposals, and see whether and how to
> incorporate that into Emacs.

Thank you for listening!

How do we make such proposals?  Should we post some or all of our
settings here, including self-written functions we call with non-default
key bindings?  What are the users we should have in mind?

Here are a few of the settings I use:


(setq inhibit-startup-message t
      default-major-mode 'text-mode
      mouse-yank-at-point t)
(add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
(add-hook 'mail-mode-hook 'turn-on-orgstruct++)
(blink-cursor-mode 0)
(setq scroll-margin 0)
(set-cursor-color "#F00000")
(setq Man-width 75)
(setq Man-notify-method 'aggressive)
(load "~/emacs/my-mark-line")
(global-set-key "\C-xl" 'my-mark-this-line)
(global-set-key "\C-xc" 'my-copy-this-line)
(global-set-key "\C-xw" 'my-cut-this-line)

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Fri, 24 Aug 2018 03:00:32 +0200
> 
> How do we make such proposals?  Should we post some or all of our
> settings here, including self-written functions we call with non-default
> key bindings?  What are the users we should have in mind?

My idea is to start with identifying particular classes of users, in
terms of stuff they mostly do in Emacs, perhaps with a second
gradation into 2 or 3 proficiency levels.  Then making a list of
settings each class/level generally wants to change from the built-in
defaults.  When we have that, we could step back and see what to do
with the data we collected.  For some, we might decide we want to
change the defaults, end of story.  For others, we should discuss in
what form(s) to expose the relevant options to each such group of
users.

That is just one idea, of course; other ideas for making progress are
welcome.

> (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))

This is already in the defaults.

> (setq scroll-margin 0)

This is the default.

> (setq Man-width 75)

Emacs nowadays calculates the width dynamically, depending on the
dimensions of the window.

> (load "~/emacs/my-mark-line")

This is not really a setting ;-)

Re: Some developement questions

[Ergus]

On Fri, Aug 24, 2018 at 12:04:44PM +0300, Eli Zaretskii wrote:
>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Fri, 24 Aug 2018 03:00:32 +0200
>>
>> How do we make such proposals?  Should we post some or all of our
>> settings here, including self-written functions we call with non-default
>> key bindings?  What are the users we should have in mind?
>

For me this sounds perfect. What platform could we use for this? Does
fsf or savannah have something like feathub? or your plan to start a
survey? Because a mailing list I thing is not dynamic enough. 

In case of a survey it could be very useful with the right questions.

>My idea is to start with identifying particular classes of users, in
>terms of stuff they mostly do in Emacs, perhaps with a second
>gradation into 2 or 3 proficiency levels.

If we ask to the user the time he has been using emacs, the most
frequent uses he does (including languages, extra packages). We can
determine the levels. Statistics do the rest.

To share the survey we can add it to it'sfoss and related publications.

>Then making a list of
>settings each class/level generally wants to change from the built-in
>defaults.  When we have that, we could step back and see what to do
>with the data we collected.  For some, we might decide we want to
>change the defaults, end of story.  For others, we should discuss in
>what form(s) to expose the relevant options to each such group of
>users.
>

100% agree!

>That is just one idea, of course; other ideas for making progress are
>welcome.
>

I propose a simple online survey, but I don't know what platform will you approve for this:

Some of my proposed questions are: (more or less)

======================================

Objective questions:
-------------------

1) Time of experience and using emacs.

1.1) Age range (10-20; 20-30 ...)

2) Main working/use field (programming, writing, etc)

2.1) Do you use the preferences dialog or manual init.el editing in elisp?

3) if programming: ( Most used language(s) / packages / tools) (probably give some lists here)

4) Operative system / platform?

5) Do you use terminal or gui emacs?

6) Do you use emacs server?

7) What documentation do you use the most? (self documented in emacs, emacs wiki, what ever gives the web search)

8) Have you contributed to the emacs development in the past?

9) Have you contributed or created any emacs package?


Specific questions
------------------

1) What keybindings do you use? (default emacs, vim like modes (evile, evil-mode..), ergoemacs, god-emacs, other?)

2) Do you access or read the emacs mailing list? (frequently, rarely, never, is there a mailing list?)

?) Maybe add some questions depending of the languages he added in previous section.

Subjective questions
--------------------

1) Self qualification user level.

2) Self qualification e-lisp knowledge.

3) Why did you started using emacs (maybe give some possible options)

4) What you don't like of emacs.

5) What do you thing could be improved in emacs?

6) What new features should be included in emacs?

===================================

Of course all this is just a pre-pre-alpha proposal that I put here for your
consideration. I can help doing the survey once you tell me the platform you
approve to use. Once we all agree in a list of questions we can start
sharing it with a fix deadline.

Does it looks right for you?



>> (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
>
>This is already in the defaults.
>
>> (setq scroll-margin 0)
>
>This is the default.
>
>> (setq Man-width 75)
>
>Emacs nowadays calculates the width dynamically, depending on the
>dimensions of the window.
>
>> (load "~/emacs/my-mark-line")
>
>This is not really a setting ;-)

Re: Some developement questions

[hw]

Ergus <spacibba@aol.com> writes:

> [...]
> I propose a simple online survey, but I don't know what platform will you approve for this:
>
> Some of my proposed questions are: (more or less)
> [...]

The assumption that there are qualified classes of users may be false or
true.  How could the answers to these questions show which is the case,
and how do the answers allow to derive qualified classes of users from
them?


This survey could be extremely difficult to do because you need to make
a very detailed anticipation of what you're asking about to ensure that
you are asking the right questions without influencing the result
through the way the questions are formed, and all that before you could
verify whether what you are trying to find something out about does
indeed exist or not.

What is the usual way scientists have to research a recursive problem
like this?  Find out if there are qualified classes of users first, then
what they might be and then what settings they are using?

PS: I just noticed that the bug tracker must have a collection of
settings because some are being reported when making a bug report.  Is
there a way to find out what most bug reporters use for some of the
settings, using this information?

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Fri, 24 Aug 2018 03:00:32 +0200
>> 
>> How do we make such proposals?  Should we post some or all of our
>> settings here, including self-written functions we call with non-default
>> key bindings?  What are the users we should have in mind?
>
> My idea is to start with identifying particular classes of users, in
> terms of stuff they mostly do in Emacs, perhaps with a second
> gradation into 2 or 3 proficiency levels.  Then making a list of
> settings each class/level generally wants to change from the built-in
> defaults.  When we have that, we could step back and see what to do
> with the data we collected.  For some, we might decide we want to
> change the defaults, end of story.  For others, we should discuss in
> what form(s) to expose the relevant options to each such group of
> users.
>
> That is just one idea, of course; other ideas for making progress are
> welcome.

It´s a good idea, though I think it shouldn't be limited to settings.

>> (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
>
> This is already in the defaults.

I probably read it on the emacs wiki, 15 years ago maybe.

Maybe Emacs should give us warnings when it discovers outdated,
deprecated or useless settings in ~/.emacs.

>> (setq scroll-margin 0)
>
> This is the default.

I´ve had it at 2 for many years and only tried 0 the other day.  If I
remove it, I won't remember how it's called, so I'd have to comment it
out.

>> (setq Man-width 75)
>
> Emacs nowadays calculates the width dynamically, depending on the
> dimensions of the window.

Why not make Emacs dynamically size it's windows to the width of the
display first? ;~O

<Rant>

Yes, Emacs can do that since a while, and has made it an extremely
annoying default.  Who wants to read manual pages or other text when it
has been formatted to be about 140--300 characters per line wide (and
way more than that if my eyes were what they used to be)?

Lines that wide are great for programming and suck for manuals.  Even
the about 140 characters per line I have with defaulting to two windows
side by side are a bit much for programming, and fortunately most lines
are a lot shorter.  If they are too long, I reformat them to a
reasonable length.  About 140 is a good compromise, yet still too wide
for manuals. (For more than two windows side by side, I'd need a larger
display (or glasses maybe).)

And who wants to need to somehow re-format manual pages to a reasonable
width when they make the window smaller?  Re-formatting them isn't even
possible --- at least it wasn't when I made this setting.  If it now is,
are the manual pages reformatted automatically when you change the size
of the window?  If they are, who would want to change the size of a
window to be able to read a manual page?

This is a good example for a default that really should be changed.
Text is easiest to read at about 70--80 characters per line.  Not having
this setting at a reasonable default allows Emacs to show off with being
able to reformat manual pages to ridiculous line lengths, thus making
them unreadable, which is not useful for the users.

How about changing the effect of Man-width, or an additional setting:
Emacs could usefully format manual pages to fit the window when the
window is narrower than the default width of manual pages (unless the
window is ridiculously narrow, in which case it could fall back to the
default width for manual pages) and format them no wider than the
default width of manual pages for windows that are wider.  It could
also, depending on a(nother) setting(s), dynamically re-format the
manual pages to

min(
    (width_of_window <= ridiculously_narrow) ?
    max_width_of_manual_pages : width_of_window,
    max_width_of_manual_pages
   )

when the window is resized and had been less wide than the maximal width
for manual pages before.

I'd consider that as much more useful than ending up with ridiculously
wide manual pages that are unreadable when they are as wide as the
window and even more unreadable when you make the window less wide in an
attempt to get the pages more readable: awww, too late ....

This would be the solution for this particular setting: a good default.

</Rant>

>
>> (load "~/emacs/my-mark-line")
>
> This is not really a setting ;-)

That's why I think packaging configurations targeted at qualified
classes of users shouldn't be limited to settings like Man-width.

Think of what Ergus pointed out in his last post[1] about the
difficulties users and Emacs are experiencing:


+ find out about Emacs
+ install Emacs
+ find out about package manager of Emacs
+ configure package manager, add repos
+ somehow get an idea of what packages to install
+ get into dependency hell and alternatives hell
+ get into documentation hell because it's hard to tell which
  documentation is up to date
+ get nothing to work


<Ergus>
> So even if the new user had time, patience and abilities to configure
> and open the package manager, add melpa, install jedi, but not
> configure it or use autocomplete, nothing will work for him. This is
> very error prone.
</Ergus>

I had auto-complete working (until I disabled it because it got into my
way by trying to automatically complete everything when I used Emacs for
something I didn't install auto-complete for), installed from a git repo
somewhere on github.  I don't know about melpa and jedi, and I remember
that there was something that required something that had to do with
either auto-complete or snippets (I had yasnippets also working but then
couldn't be bothered to create all the snippets I would have needed for
it to make sense, but it's cool), and that there were several things
that would either provide automatic completion or snippets, and it was
not too clear which one I should use. My clone of the auto-complete repo
is from 2014, so I don´t remember everything exactly.  It wasn't too
difficult, though, but I didn't do it for python.

So I agree with Ergus here.  This is why I was asking about the package
manager handling dependencies (and alternatives).  Users kinda need to
be able to create a package from their running and working (and perhaps
even non-working) configuration, including /everything/ that is needed
for this configuration.  Other users need to be able to back up their
configuration --- hence be able to create configuration packages --- and
to conveniently install packages created by other users, or by
themselves.  They do not need to have to try to figure out dependencies
or alternatives when installing packages.  Otherwise they would have
some sort of Gentoo experience which can get so horrible it could make
them switch to Windows, or even to a Mac.[2]

Now when Ergus gets everything which is great for programming in python
to work, he would create a configuration package, send it to me, and I
could install it and start learning python.  Emacs kinda needs to be
able to be boring for users to become excited about it and wanting to
learn.  And that includes displaying manual pages by default in a
boringly wonderful readable way.  Often times, the greatest power arises
from simplicity --- perhaps all the more so, the more complicated
everything becomes.


[1]: Message-ID: <20180823163325.cebnxjwu37efy45k@Ergus>

[2]: For those who haven't tried: Gentoo is virtually great, i. e. great
     until the at-least-weekly update fails and forces you yet again to
     make wild guesses about how you could fix the dependencies because
     the package management doesn't do that because you're the one who
     is supposed to do it.  If you can't fix them in time, or if you try
     to avoid the dreadful updates, or if you don't have several hours
     per machine each week for updates, the machine may quickly become
     impossible to update at all.  Not only that, the machine may be
     useless because it can not provide the services it is supposed to
     provide before you fixed the dependencies, which may not be
     possible until some packages have been updated by the package
     managers.  I can understand how I unexpectedly become the one to
     fix the dependencies, and I can not afford to depend on package
     managers who mess things up so badly that updates become
     impossible.  This is one of the many paths leading to the
     appreciation of Centos and the realisation that sometimes there is
     nothing better than boring.

Re: Some developement questions

[Alexis]

hw <hw@adminart.net> writes:

> Maybe Emacs should give us warnings when it discovers outdated, 
> deprecated or useless settings in ~/.emacs.

i imagine many people might want this; but many people might /not/ 
want this if it has a noticeable impact on startup times. Startup 
times don't usually have an impact on me personally, since i run 
an Emacs server at machine startup and connect clients to 
that. From what i've read, however, a number of people find even 
an extra 0.5s-1.0s in startup to be significant when jumping in 
and out of a non-client Emacs instance. So if this feature did 
have an impact on startup times, people would want to be able to 
enable and disable it at will.

> get into documentation hell because it's hard to tell which 
> documentation is up to date

One of the pleasures i find in using Emacs is its extensive 
accompanying documentation, documentation which (in my experience) 
is typically far better maintained than that of many other 
projects[1]. As someone who has been using Emacs for around 20 
years, i very much appreciate the comprehensive NEWS file with 
each release, which allows me to quite quickly ascertain what 
changes have been made that might affect my configuration and 
workflow (e.g. changed default values).

i say this because i'm wondering which area(s) of documentation 
you're having these difficulties with? If you're talking about the 
Emacs Wiki at emacswiki.org, well, as far as i'm aware, that's not 
an official wiki, is it[2]? Nor is wikemacs.org. i personally much 
prefer the latter to the former. But i strongly feel that people's 
first destinations when searching for documentation should be the 
Emacs Manual and the Emacs Lisp Reference Manual - only after not 
being able to locate the information in those manuals, making sure 
to make use their excellent indexes, should one consider trying to 
find information on the two wikis. i regularly find myself 
responding to "How do I do X in Emacs?" questions with "Here's the 
relevant section of the relevant manual." At any rate, one should 
certainly consider submitting a bug report about inadequate or 
inaccurate documentation for functionality shipped with 
Emacs. Even if no volunteer can immediately address it, at least 
it's recorded as something for potential volunteers to work on.

> I had auto-complete working (until I disabled it because it got 
> into my way by trying to automatically complete everything when 
> I used Emacs for something I didn't install auto-complete for), 
> installed from a git repo somewhere on github.

Do you literally mean the `auto-complete.el' package and its 
associated `ac-*' packages? Is that still maintained? i'm using 
`company` as my autocompletion framework, myself. But neither is 
shipped with Emacs, and there's no index entry for `auto-complete' 
or `autocomplete' in the Emacs Manual, which probably comes as a 
surprise to the many people who have come to expect autocompletion 
as basic functionality in a programming environment .... i think 
this is indeed a problem, but unfortunately, i don't have any 
suggestions as to how it might be addressed. :-(


Alexis.

--

[1] OpenBSD is probably the other project i think of when thinking 
of excellence in documentation. Comparing `man 4 intro' for the 
Linux kernel vs. `man 4 intro' for the OpenBSD kernel is 
eye-opening.

[2] i have the impression that many people assume it /is/ an 
official Emacs wiki, so if its not, this fact might need to be 
somehow emphasised or made more clear.

Re: Some developement questions

[Ergus]

On Sat, Aug 25, 2018 at 05:35:33PM +1000, Alexis wrote:
>
>hw <hw@adminart.net> writes:
>
>>Maybe Emacs should give us warnings when it discovers outdated, 
>>deprecated or useless settings in ~/.emacs.
>
>i imagine many people might want this; but many people might /not/ 
>want this if it has a noticeable impact on startup times. Startup 
>times don't usually have an impact on me personally, since i run an 
>Emacs server at machine startup and connect clients to that. From what 
>i've read, however, a number of people find even an extra 0.5s-1.0s in 
>startup to be significant when jumping in and out of a non-client 
>Emacs instance. So if this feature did have an impact on startup 
>times, people would want to be able to enable and disable it at will.
>
If the messages are just printed in the message buffer it shouldn't impact too much the startup time I think. 

>>get into documentation hell because it's hard to tell which 
>>documentation is up to date
>
>One of the pleasures i find in using Emacs is its extensive 
>accompanying documentation, documentation which (in my experience) is 
>typically far better maintained than that of many other projects[1]. 
>As someone who has been using Emacs for around 20 years, i very much 
>appreciate the comprehensive NEWS file with each release, which allows 
>me to quite quickly ascertain what changes have been made that might 
>affect my configuration and workflow (e.g. changed default values).
>
>i say this because i'm wondering which area(s) of documentation you're 
>having these difficulties with? If you're talking about the Emacs Wiki 
>at emacswiki.org, well, as far as i'm aware, that's not an official 
>wiki, is it[2]? Nor is wikemacs.org. i personally much prefer the 
>latter to the former. But i strongly feel that people's first 
>destinations when searching for documentation should be the Emacs 
>Manual and the Emacs Lisp Reference Manual - only after not being able 
>to locate the information in those manuals, making sure to make use 
>their excellent indexes, should one consider trying to find 
>information on the two wikis. i regularly find myself responding to 
>"How do I do X in Emacs?" questions with "Here's the relevant section 
>of the relevant manual." At any rate, one should certainly consider 
>submitting a bug report about inadequate or inaccurate documentation 
>for functionality shipped with Emacs. Even if no volunteer can 
>immediately address it, at least it's recorded as something for 
>potential volunteers to work on.
>
You are right, emacs documentation is awesome... once you understand how
to get there and how it is organized, the name of the package or the
functionality you want to configure and how to use the indices.

Newer users will go straight to google/duckduckgo to make the
questions. Not only because they don't know exactly the name of what
they are looking for, but also because that's the stackoverflow's
culture. In the beginning they just want some code to copy and paste
in the config.

There are not emacs foros either, the closes we had were some reddit
posts from more than 2 years ago. And the mailing list really feels so
1995. So when a user configures or find a solution, there is not a
central place to share his tweaks/work/corrections/worksaround, and
where the developers could get opinions about what to improve, or what
"defaults" are changing most of the users.

So basically the information is not flowing as it should in all the
directions (developer/mainteiner - experiences user - new user - potential user).

Another consequence of this is that newer users will report miss configured
features or solved problems as bugs that are never solved, or they feel
intimidated/disapointed to do it. Maybe it is already corrected,
fixed or a work around exists, or another user knows how to fix quickly
but the issues list grows infinitely and all the work goes to the developers.

>>I had auto-complete working (until I disabled it because it got into 
>>my way by trying to automatically complete everything when I used 
>>Emacs for something I didn't install auto-complete for), installed 
>>from a git repo somewhere on github.
>
>Do you literally mean the `auto-complete.el' package and its 
>associated `ac-*' packages? Is that still maintained? i'm using 
>`company` as my autocompletion framework, myself. But neither is 
>shipped with Emacs, and there's no index entry for `auto-complete' or 
>`autocomplete' in the Emacs Manual, which probably comes as a surprise 
>to the many people who have come to expect autocompletion as basic 
>functionality in a programming environment .... i think this is indeed 
>a problem, but unfortunately, i don't have any suggestions as to how 
>it might be addressed. :-(
>
This is one of the reasons I made my first questions. Because I don't
know what package to use in the list of options when multiple packages
offer the same functionality. I just mention some of them in a previous
message. But from the project point of view, sadly there are not as many
developers as they used to be, so maintaining two or three similar
packages for exactly the same is a waste of man power and a source of
incompatibilities and conflicts with other packages (and so on
recursively because fixing it requires then more man power).

Example: When I started using emacs most of the recommendation were to
use flycheck instead of flymake because it was supposed to be a
replacement for the last one. 5 years later, in the latest release they
have touched flymake and now I don't know if I should migrate back or
not, or why there are people putting effort in flymake instead of
flycheck. But the worst is that some plugins are available only in one
of them (same in auto-complete vs company) since ever.

This is the kind of problems that stagnates big projects and disappoint developers and users.

>
>Alexis.
>
>--
>
>[1] OpenBSD is probably the other project i think of when thinking of 
>excellence in documentation. Comparing `man 4 intro' for the Linux 
>kernel vs. `man 4 intro' for the OpenBSD kernel is eye-opening.
>
>[2] i have the impression that many people assume it /is/ an official 
>Emacs wiki, so if its not, this fact might need to be somehow 
>emphasised or made more clear.

Re: Some developement questions

[Radon Rosborough]

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

> If the messages are just printed in the message buffer it shouldn't
> impact too much the startup time I think.

To do the kind of analysis you are talking about, one would have to
hook into really basic subroutines like `setq`. I don't have any
numbers to back this up, but that sounds like it would be a massive
slowdown for all Elisp code. Alternatively, you'd have to do a lot of
heavy static analysis because what defines a "outdated, deprecated, or
useless" setting is actually quite nebulous and complicated.

I do actually think this is an interesting idea, but it would
definitely best be implemented as either a third-party package or some
optional user library in core that either does static analysis or
allows one to load the init-file with profiling enabled like ESUP [1]
(or both).

> a number of people find even an extra 0.5s-1.0s in startup to be
> significant

I am one of those people, and actually I find even an extra 50ms of
startup time to be unacceptable unless there's a good reason for it.
My ~5,000 line configuration [2] which pulls in ~130 packages takes
only ~250ms to load, according to a startup profiler -- meaning 0.6s
to go from nothing to a full graphical frame.

Why bother with the Emacs server when you can just make Emacs start up
as fast as Vim? ;)

[1]: https://github.com/jschaf/esup
[2]: https://github.com/raxod502/radian

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

Re: Some developement questions

[Eli Zaretskii]

> From: Radon Rosborough <radon.neon@gmail.com>
> Date: Sat, 25 Aug 2018 10:11:38 -0600
> Cc: flexibeast@gmail.com, hw@adminart.net, Eli Zaretskii <eliz@gnu.org>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Why bother with the Emacs server when you can just make Emacs start up
> as fast as Vim? ;)

Not sure if this is a serious question.  But if it is, then the answer
is clear: because keeping Emacs running at all times means you keep
all the stuff that isn't saved to files, like buffers that don't visit
files (*scratch* being the most important one of them), various
history variables, etc.

Re: Some developement questions

[Ergus]

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

Hi Eli.

This is one of the reasons the proposed feedback is a good idea. To identify different kinds of users and their needs.

One of my proposed questions is about the server. Some people just dont like to have the server. So they care about startup.

⁣Sent from BlueMail ​

On 25 Aug 2018, 18:21, at 18:21, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Radon Rosborough <radon.neon@gmail.com>
>> Date: Sat, 25 Aug 2018 10:11:38 -0600
>> Cc: flexibeast@gmail.com, hw@adminart.net, Eli Zaretskii
><eliz@gnu.org>,
>> 	emacs-devel <emacs-devel@gnu.org>
>> 
>> Why bother with the Emacs server when you can just make Emacs start
>up
>> as fast as Vim? ;)
>
>Not sure if this is a serious question.  But if it is, then the answer
>is clear: because keeping Emacs running at all times means you keep
>all the stuff that isn't saved to files, like buffers that don't visit
>files (*scratch* being the most important one of them), various
>history variables, etc.

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

Re: Some developement questions

[Eli Zaretskii]

> From: Ergus <spacibba@aol.com>
> Date: Sat, 25 Aug 2018 22:34:21 +0200
> CC: Radon Rosborough <radon.neon@gmail.com>,hw@adminart.net,
> 		flexibeast@gmail.com,emacs-devel@gnu.org
> 
> One of my proposed questions is about the server. Some people just dont like to have the server. So they
> care about startup.

You can still have a long running session, even without the server.
Just visit files from the running Emacs instead of starting a new
session each time you need to edit a file.

Re: Some developement questions

[Radon Rosborough]

>> Why bother with the Emacs server when you can just make Emacs start
>> up as fast as Vim? ;)
>
> Not sure if this is a serious question.  But if it is, then the answer
> is clear: because keeping Emacs running at all times means you keep
> all the stuff that isn't saved to files, like buffers that don't visit
> files (*scratch* being the most important one of them), various
> history variables, etc.

It was intended rhetorically, because in my experience the Emacs
server is most frequently discussed when people are talking about how
to avoid a slow startup. Of course you are right that there are other
reasons one might want to use it.

Re: Some developement questions

[Ergus]

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



⁣Sent from BlueMail ​

On 25 Aug 2018, 18:14, at 18:14, Radon Rosborough <radon.neon@gmail.com> wrote:
>> If the messages are just printed in the message buffer it shouldn't
>> impact too much the startup time I think.
>
>To do the kind of analysis you are talking about, one would have to
>hook into really basic subroutines like `setq`. I don't have any
>numbers to back this up, but that sounds like it would be a massive
>slowdown for all Elisp code. Alternatively, you'd have to do a lot of
>heavy static analysis because what defines a "outdated, deprecated, or
>useless" setting is actually quite nebulous and complicated.
>
>I do actually think this is an interesting idea, but it would
>definitely best be implemented as either a third-party package or some
>optional user library in core that either does static analysis or
>allows one to load the init-file with profiling enabled like ESUP [1]
>(or both).
>
>> a number of people find even an extra 0.5s-1.0s in startup to be
>> significant
>
>I am one of those people, and actually I find even an extra 50ms of
>startup time to be unacceptable unless there's a good reason for it.
>My ~5,000 line configuration [2] which pulls in ~130 packages takes
>only ~250ms to load, according to a startup profiler -- meaning 0.6s
>to go from nothing to a full graphical frame.
>
>Why bother with the Emacs server when you can just make Emacs start up
>as fast as Vim? ;)
>
>[1]: https://github.com/jschaf/esup
>[2]: https://github.com/raxod502/radian

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

Re: Some developement questions

[hw]

Radon Rosborough <radon.neon@gmail.com> writes:

>> If the messages are just printed in the message buffer it shouldn't
>> impact too much the startup time I think.
>
> To do the kind of analysis you are talking about, one would have to
> hook into really basic subroutines like `setq`. I don't have any
> numbers to back this up, but that sounds like it would be a massive
> slowdown for all Elisp code. Alternatively, you'd have to do a lot of
> heavy static analysis because what defines a "outdated, deprecated, or
> useless" setting is actually quite nebulous and complicated.

In theory, Emacs could find out which variables are being defined in
~/.emacs and whether they are already known or not, like by checking if
they can successfully be described.  The unknown variables could then be
brought to the attention of the user.  Perhaps a few other things could
be done, too.

> I do actually think this is an interesting idea, but it would
> definitely best be implemented as either a third-party package or some
> optional user library in core that either does static analysis or
> allows one to load the init-file with profiling enabled like ESUP [1]
> (or both).

How difficult would it be to do the above?

>> a number of people find even an extra 0.5s-1.0s in startup to be
>> significant
>
> I am one of those people, and actually I find even an extra 50ms of
> startup time to be unacceptable unless there's a good reason for it.
> My ~5,000 line configuration [2] which pulls in ~130 packages takes
> only ~250ms to load, according to a startup profiler -- meaning 0.6s
> to go from nothing to a full graphical frame.
>
> Why bother with the Emacs server when you can just make Emacs start up
> as fast as Vim? ;)

How is it relevant whether it takes 50ms more or less to start Emacs?
Is that even within the error margin of the measurements, like changes
in temperature might cause larger differences than that.

I just keep Emacs running on my server in a tmux session.  With a
terminal that has good colours, it's quite ok.  I could even use it
without booting my workstation by just switching the monitor input: 50ms
more or less are nothing compared to that, you can't keep up with me
anyway ;P

Unfortunately, the Emacs server can still not be used from remote
machines --- or can it finally?

Other than that, the Emacs server is useful to push a file into Emacs
from the terminal and things like that.  Why not just use it, it's
probably faster than 0.6s before you can edit a file.


> [1]: https://github.com/jschaf/esup
> [2]: https://github.com/raxod502/radian

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  Eli Zaretskii <eliz@gnu.org>,  flexibeast@gmail.com,  emacs-devel <emacs-devel@gnu.org>
> Date: Sun, 26 Aug 2018 03:33:08 +0200
> 
> In theory, Emacs could find out which variables are being defined in
> ~/.emacs and whether they are already known or not, like by checking if
> they can successfully be described.  The unknown variables could then be
> brought to the attention of the user.

That would definitely annoy me, for example: I have a lot of settings
of "unknown" variables, in preparation for when they will become known
(when the corresponding package is loaded on demand).

> Unfortunately, the Emacs server can still not be used from remote
> machines --- or can it finally?

Yes, it can.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  Eli Zaretskii <eliz@gnu.org>,  flexibeast@gmail.com,  emacs-devel <emacs-devel@gnu.org>
>> Date: Sun, 26 Aug 2018 03:33:08 +0200
>> 
>> In theory, Emacs could find out which variables are being defined in
>> ~/.emacs and whether they are already known or not, like by checking if
>> they can successfully be described.  The unknown variables could then be
>> brought to the attention of the user.
>
> That would definitely annoy me, for example: I have a lot of settings
> of "unknown" variables, in preparation for when they will become known
> (when the corresponding package is loaded on demand).

Hmm, yes, there would have to be a way to tell the check which unknown
variables it must not consider.  Would it bother you when there was
merely a function you needed to run to perform the check?  I wouldn't
consider it useful that the check would be done on every startup.

>> Unfortunately, the Emacs server can still not be used from remote
>> machines --- or can it finally?
>
> Yes, it can.

Wow!  Finally!  Awesome!  I have to see if I can get that to work right
now!  That would be incredibly helpful ...

Hm, no, it doesn't work:  It says it connects, but then it either says
"*ERROR*: Display :0 can't be opened" or "*ERROR*: Could not open file:
/dev/pts/35".

I can understand that it might not be able to open the display on the
client because I started the X session without it listening to the
network.  But if I do that and allow the server to access my X session,
everything goes unencrypted over the network.

I don't exactly understand how emacsclient fails because it can not open
the terminal.  'emacsclient -f ~/.emacs.d/server/server -nw' would never
work on a remote client.

I can 'ssh -Y server' and then start an xterm which shows up on the
client.  With the current Emacs server setup, starting emacsclient fails
because it insists on using display :0, ignoring that I'm telling it
otherwise.

I do not really want to use 'ssh -Y server', run Emacs on the server and
then use frames that appear on the client unless the Emacs session on
the server would survive the sudden disappearance of the frames.  Last
time I checked, Emacs did not survive this, even not Emacs-lucid.

So how do I get this to work?

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 27 Aug 2018 00:51:38 +0200
> 
> >> In theory, Emacs could find out which variables are being defined in
> >> ~/.emacs and whether they are already known or not, like by checking if
> >> they can successfully be described.  The unknown variables could then be
> >> brought to the attention of the user.
> >
> > That would definitely annoy me, for example: I have a lot of settings
> > of "unknown" variables, in preparation for when they will become known
> > (when the corresponding package is loaded on demand).
> 
> Hmm, yes, there would have to be a way to tell the check which unknown
> variables it must not consider.  Would it bother you when there was
> merely a function you needed to run to perform the check?  I wouldn't
> consider it useful that the check would be done on every startup.

If there were a setting to disable the check, that'd be fine by me.
Of course, then we'd have an argument about the default of that
setting ;-)

> >> Unfortunately, the Emacs server can still not be used from remote
> >> machines --- or can it finally?
> >
> > Yes, it can.
> 
> Wow!  Finally!  Awesome!  I have to see if I can get that to work right
> now!  That would be incredibly helpful ...
> 
> Hm, no, it doesn't work:  It says it connects, but then it either says
> "*ERROR*: Display :0 can't be opened" or "*ERROR*: Could not open file:
> /dev/pts/35".
> [...]
> So how do I get this to work?

Read about that in the manual, nodes "TCP Emacs server" and the
description of the --tramp-prefix= option under "emacsclient Options".

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 27 Aug 2018 00:51:38 +0200
>> 
>> >> In theory, Emacs could find out which variables are being defined in
>> >> ~/.emacs and whether they are already known or not, like by checking if
>> >> they can successfully be described.  The unknown variables could then be
>> >> brought to the attention of the user.
>> >
>> > That would definitely annoy me, for example: I have a lot of settings
>> > of "unknown" variables, in preparation for when they will become known
>> > (when the corresponding package is loaded on demand).
>> 
>> Hmm, yes, there would have to be a way to tell the check which unknown
>> variables it must not consider.  Would it bother you when there was
>> merely a function you needed to run to perform the check?  I wouldn't
>> consider it useful that the check would be done on every startup.
>
> If there were a setting to disable the check, that'd be fine by me.
> Of course, then we'd have an argument about the default of that
> setting ;-)

Why, you want a check on every startup? ;)

>> >> Unfortunately, the Emacs server can still not be used from remote
>> >> machines --- or can it finally?
>> >
>> > Yes, it can.
>> 
>> Wow!  Finally!  Awesome!  I have to see if I can get that to work right
>> now!  That would be incredibly helpful ...
>> 
>> Hm, no, it doesn't work:  It says it connects, but then it either says
>> "*ERROR*: Display :0 can't be opened" or "*ERROR*: Could not open file:
>> /dev/pts/35".
>> [...]
>> So how do I get this to work?
>
> Read about that in the manual, nodes "TCP Emacs server" and the
> description of the --tramp-prefix= option under "emacsclient Options".

I don't understand this documentation.  It's a good example for why
people turn to a search engine.  And I don't remember how to get back
when following links in info documentation --- if I ever knew that and
if there even is a way (I seem to vaguely remember that there is ...).
This documentation is really difficult to read.

Anyway, why would I need to forward the port via ssh?  Emacs can use it
just fine without, and it would be already in use.  I would expect using
a secure connection to be the default anyway.

I'm guessing the documentation wants me to allow the emacs daemon to
access /dev/pts/35 via tramp.  To be able to do that, emacs would have
to ask me for my password, which it can not do because it can not open
the terminal.  Tramp can be extremely finicky, and what are the
difficulties SELinux might put into my way when doing this?

And what file is there to access when I want an X frame?

The example in the documentation is the wrong way round: The server is
running on the remote machine.  If I wanted to run emacs locally on my
workstation, I could just do that, but I want it to run on the server
because I don't shut the server down but my workstation.


I'm running it now with Emacs as daemon on the server and 'ssh -Y
server'.  That allows me to get either X frames or to use the terminal.
I needed to restart the tmux session because this does not work with a
tmux session that was started without the -Y option of ssh.

But I'd like to use the Emacs server without such detours.  Can remote
Emacs not simply be simple?  Why doesn't the locally running emacsclient
allow the remote Emacs server to access the terminal transparently?

Re: Some developement questions

[Michael Albinus]

hw <hw@adminart.net> writes:

Hi,

> Tramp can be extremely finicky,

Whenever you have this feeling, pls report in detail. Sometimes, it
might be a bug, sometimes, the doc needs an improvement.

Best regards, Michael.

Re: Some developement questions

[hw]

Michael Albinus <michael.albinus@gmx.de> writes:

> hw <hw@adminart.net> writes:
>
> Hi,
>
>> Tramp can be extremely finicky,
>
> Whenever you have this feeling, pls report in detail. Sometimes, it
> might be a bug, sometimes, the doc needs an improvement.

Well, I don't really know the datails; only sometimes I need to run
(tramp-cleanup-all-connections) when it somehow gets screwed up.

Last time, it blocked me entirely when it tried to create a backup file
and couldn't do that because file permissions did not allow it.  I was
forced to either kill Emacs or change permissions so it could create the
file.  After that, I changed the backup directory for tramp and found
out that cleaning up all the connections is not enough to have this
change applied; I had to kill the buffer and visit the file again for it
to work.

So at least for one case, here are the details, but I won't call it a
bug, only something that could be improved upon, like check permissions
before creating backups and prompt what to do when permissions do not
allow to create one, and applying a change of the backup directory right
away to all connections, or prompt the user if the change should be
applied to all of them now.

That was Emacs 24.x, on Centos, so perhaps this has already been
changed.

Re: Some developement questions

[Michael Albinus]

hw <hw@adminart.net> writes:

Hi,

> Well, I don't really know the datails; only sometimes I need to run
> (tramp-cleanup-all-connections) when it somehow gets screwed up.
>
> Last time, it blocked me entirely when it tried to create a backup file
> and couldn't do that because file permissions did not allow it.  I was
> forced to either kill Emacs or change permissions so it could create the
> file.  After that, I changed the backup directory for tramp and found
> out that cleaning up all the connections is not enough to have this
> change applied; I had to kill the buffer and visit the file again for it
> to work.

If this happens again, you could call "M-x
tramp-cleanup-all-buffers". It clears all connections *and* kills all
buffers related to a remote file.

For further analysis, I would need the Tramp debug buffer. If you set
permanently tramp-verbose to 6, relevant information are traced. Well,
at least as long Tramp is mulish ...

> So at least for one case, here are the details, but I won't call it a
> bug, only something that could be improved upon, like check permissions
> before creating backups and prompt what to do when permissions do not
> allow to create one, and applying a change of the backup directory right
> away to all connections, or prompt the user if the change should be
> applied to all of them now.

Again, it is not clear what caused the problem. In order to get Tramp
improved, I count on users sending the traces.

> That was Emacs 24.x, on Centos, so perhaps this has already been
> changed.

Well, Emacs 26 is out, and the integrated Tramp shall behave
better. Yes, this is my hope all the years ...

Best regards, Michael.

Re: Some developement questions

[hw]

Michael Albinus <michael.albinus@gmx.de> writes:

> hw <hw@adminart.net> writes:
>
> Hi,
>
>> Well, I don't really know the datails; only sometimes I need to run
>> (tramp-cleanup-all-connections) when it somehow gets screwed up.
>>
>> Last time, it blocked me entirely when it tried to create a backup file
>> and couldn't do that because file permissions did not allow it.  I was
>> forced to either kill Emacs or change permissions so it could create the
>> file.  After that, I changed the backup directory for tramp and found
>> out that cleaning up all the connections is not enough to have this
>> change applied; I had to kill the buffer and visit the file again for it
>> to work.
>
> If this happens again, you could call "M-x
> tramp-cleanup-all-buffers". It clears all connections *and* kills all
> buffers related to a remote file.

Wouldn't that have killed a lot of buffers that do not require the
change of the autosave directory?

> For further analysis, I would need the Tramp debug buffer. If you set
> permanently tramp-verbose to 6, relevant information are traced. Well,
> at least as long Tramp is mulish ...

You could reproduce it maybe:  Edit a remote file in /usr/local/bin
which belongs to micheal:root.  Once Emacs tries to create an autosave,
tramp freaks out because it does not have permission to create the
autosave file in that place.

>> So at least for one case, here are the details, but I won't call it a
>> bug, only something that could be improved upon, like check permissions
>> before creating backups and prompt what to do when permissions do not
>> allow to create one, and applying a change of the backup directory right
>> away to all connections, or prompt the user if the change should be
>> applied to all of them now.
>
> Again, it is not clear what caused the problem. In order to get Tramp
> improved, I count on users sending the traces.

file permissions

I had to change the ownership of the directory so Emacs was allowed to
create the autosave file there to get around the problem.  After
changing the autosave location, I could give the directory back to root.

>> That was Emacs 24.x, on Centos, so perhaps this has already been
>> changed.
>
> Well, Emacs 26 is out, and the integrated Tramp shall behave
> better. Yes, this is my hope all the years ...

There's a way to find out :)

Re: Some developement questions

[Michael Albinus]

hw <hw@adminart.net> writes:

Hi,

> Wouldn't that have killed a lot of buffers that do not require the
> change of the autosave directory?

Maybe. It is the last resort; prior calling this you might call
`tramp-cleanup-this-connection' and kill the buffer in question.

>> For further analysis, I would need the Tramp debug buffer. If you set
>> permanently tramp-verbose to 6, relevant information are traced. Well,
>> at least as long Tramp is mulish ...
>
> You could reproduce it maybe:  Edit a remote file in /usr/local/bin
> which belongs to micheal:root.  Once Emacs tries to create an autosave,
> tramp freaks out because it does not have permission to create the
> autosave file in that place.

I've tried this, with Emacs 27.0.50, and starting Emacs with the "-Q"
option. The file was autosaved in the "/tmp/" directory as it should
(due to the default value of auto-save-file-name-transforms).

Do you have some other settings? Does the problem happen for you, when
you start "emacs -Q"?

>>> So at least for one case, here are the details, but I won't call it a
>>> bug, only something that could be improved upon, like check permissions
>>> before creating backups and prompt what to do when permissions do not
>>> allow to create one, and applying a change of the backup directory right
>>> away to all connections, or prompt the user if the change should be
>>> applied to all of them now.
>>
>> Again, it is not clear what caused the problem. In order to get Tramp
>> improved, I count on users sending the traces.
>
> file permissions
>
> I had to change the ownership of the directory so Emacs was allowed to
> create the autosave file there to get around the problem.  After
> changing the autosave location, I could give the directory back to root.

Again, the default directory for remote auto-save files ist "/tmp". If
it is different for you, you might have set your own values.

>>> That was Emacs 24.x, on Centos, so perhaps this has already been
>>> changed.
>>
>> Well, Emacs 26 is out, and the integrated Tramp shall behave
>> better. Yes, this is my hope all the years ...
>
> There's a way to find out :)

Yep.

Best regards, Michael.

Re: Some developement questions

[hw]

Michael Albinus <michael.albinus@gmx.de> writes:

> hw <hw@adminart.net> writes:

> [...]
>> You could reproduce it maybe:  Edit a remote file in /usr/local/bin
>> which belongs to micheal:root.  Once Emacs tries to create an autosave,
>> tramp freaks out because it does not have permission to create the
>> autosave file in that place.
>
> I've tried this, with Emacs 27.0.50, and starting Emacs with the "-Q"
> option. The file was autosaved in the "/tmp/" directory as it should
> (due to the default value of auto-save-file-name-transforms).
>
> Do you have some other settings? Does the problem happen for you, when
> you start "emacs -Q"?

I tried it with see footer, and it is automatically using the /tmp
directory.  So I would consider this fixed since 24.x :)

It's time to update emacs at work ...


Thank you for looking into this!


-- 
GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.22.30)
 of 2018-06-26

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 28 Aug 2018 22:42:25 +0200
> 
> > Read about that in the manual, nodes "TCP Emacs server" and the
> > description of the --tramp-prefix= option under "emacsclient Options".
> 
> I don't understand this documentation.  It's a good example for why
> people turn to a search engine.

Feel free to submit bug reports about any unclear documentation,
explaining what part(s) confused you.

> And I don't remember how to get back when following links in info
> documentation

You can type 'l' (for "last"), or use the left arrow button on the
tool bar, or click on "Info" in the menu bar and select "Back in
History", or click on Info->History and select any node you visited at
random.

> This documentation is really difficult to read.

You mean in general, or this specific feature description?

> Anyway, why would I need to forward the port via ssh?

I don't really know what you are after, exactly: you never described
that in enough detail.  The features I pointed to allow one to use
emacsclient to access remote machines in several different use cases,
and I hoped one of them is yours.

> And what file is there to access when I want an X frame?

When you invoke emacsclient, you usually ask it to visit a file,
right?

> The example in the documentation is the wrong way round: The server is
> running on the remote machine.  If I wanted to run emacs locally on my
> workstation, I could just do that, but I want it to run on the server
> because I don't shut the server down but my workstation.

It depends on the direction from which you look at the connection.
Files local to the remote host are remote files for you when you sit
at the other end.

> But I'd like to use the Emacs server without such detours.  Can remote
> Emacs not simply be simple?  Why doesn't the locally running emacsclient
> allow the remote Emacs server to access the terminal transparently?

Now I'm confused: which terminal would you like the remote Emacs to
access, and how is that relevant to your original question?

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 28 Aug 2018 22:42:25 +0200
>> 
>> > Read about that in the manual, nodes "TCP Emacs server" and the
>> > description of the --tramp-prefix= option under "emacsclient Options".
>> 
>> I don't understand this documentation.  It's a good example for why
>> people turn to a search engine.
>
> Feel free to submit bug reports about any unclear documentation,
> explaining what part(s) confused you.

The whole section about the --tramp-prefix= option confused me.

>> And I don't remember how to get back when following links in info
>> documentation
>
> You can type 'l' (for "last"), or use the left arrow button on the
> tool bar, or click on "Info" in the menu bar and select "Back in
> History", or click on Info->History and select any node you visited at
> random.

Ah!  I remembered something about arrows and tried to use the cursor
keys --- how about making it so that you can go back and forth in info
with Alt+<Cursor> like you can do in web browsers?

I have menu and toolbar disabled ...

>> This documentation is really difficult to read.
>
> You mean in general, or this specific feature description?

It's the combination of both, i. e. the description didn't make sense to
me and fighting with how to use the info browser because the description
made me follow the reference about tramps prefixes, and I couldn't get
back.  I ended up getting stuck in the help documentation of info and
actually had to kill the buffer to be able to start over because I
couldn't get anywhere else from there.

>> Anyway, why would I need to forward the port via ssh?
>
> I don't really know what you are after, exactly: you never described
> that in enough detail.  The features I pointed to allow one to use
> emacsclient to access remote machines in several different use cases,
> and I hoped one of them is yours.

Well, that's what I'd like to do, and you've probably pointed me the
right way.

>> And what file is there to access when I want an X frame?
>
> When you invoke emacsclient, you usually ask it to visit a file,
> right?

Wrong; the files are usually already loaded, either because Emacs keeps
running on the server, or because desktop-mode has already restored
them.

>> The example in the documentation is the wrong way round: The server is
>> running on the remote machine.  If I wanted to run emacs locally on my
>> workstation, I could just do that, but I want it to run on the server
>> because I don't shut the server down but my workstation.
>
> It depends on the direction from which you look at the connection.
> Files local to the remote host are remote files for you when you sit
> at the other end.

That depends.  Files local to the server are not really remote to the
client because the client has them mounted via NFS.  But the virtual
terminal would be a file remote to the server.  Hence I'm guessing that
the Emacs server would somehow need to use tramp to access them, but in
order to do so, the Emacs server would need to ask me for my password,
and it can not do that because it can not open a terminal without that
password.  Even if it had the password, SELinux might prevent it from
accessing a device file like that.

>> But I'd like to use the Emacs server without such detours.  Can remote
>> Emacs not simply be simple?  Why doesn't the locally running emacsclient
>> allow the remote Emacs server to access the terminal transparently?
>
> Now I'm confused: which terminal would you like the remote Emacs to
> access, and how is that relevant to your original question?

So you see how this is confusing :)

I'd like to use the Emacs server that runs remotely on the server from
my workstation with an emacsclient running locally on the workstation
directly without X11 forwarding via ssh for the frames, and I'd like to
be able to also use 'emacsclient -nw' on the workstation, using the
emacs server on the server.  I am wondering if I need the X server
running on the workstation to listen on a TCP port for that to work for
the frames; I guess not because the emacsclient would run locally.

Basically, I want to use the Emacs server the usual way how you use any
server, like a web server or an ssh server or an XMPP server.

I understand that the Emacs server can not open the virtual terminal
when using 'emacsclient -nw' because from its perspective, that is a
remote file.  Apparently, it might able to use tramp to open it if I
supply an appropriate --tramp-prefix= option, provided I could enter the
password for the log in, and provided that SELinux doesn't get in the
way.  However, emacsclient is running locally, so it should be able to
use the console.

I am wondering what remote file the Emacs server would need to open to
create a frame in the X session running on the workstation.  And I am
finding the idea of remotely opening files representing virtual consoles
within a tmux session somewhat strange and not looking like a good idea.

So, yes, I kinda understand the documentation, but it's confusing, and I
couldn't get it to work yet and am not sure that I can.  Even if I
could, I can not enter the password.

I've downloaded the 26.1 release sources and am using that version
because the server runs Centos, which comes with Emacs 24.x which seems
a bit old.  So I have most of the cool new features now, and this should
be a really easy thing to do :)  I need to give it more time and
experimentation, maybe this weekend.

Re: Some developement questions

[Filipp Gunbin]

On 29/08/2018 22:52 +0200, hw wrote:

> I ended up getting stuck in the help documentation of info and
> actually had to kill the buffer to be able to start over because I
> couldn't get anywhere else from there.

You could use `C-h m' to find about Info-history-back which is bound to
`l'.  Or Info-history (`L') for the history.

Re: Some developement questions

[hw]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 29/08/2018 22:52 +0200, hw wrote:
>
>> I ended up getting stuck in the help documentation of info and
>> actually had to kill the buffer to be able to start over because I
>> couldn't get anywhere else from there.
>
> You could use `C-h m' to find about Info-history-back which is bound to
> `l'.  Or Info-history (`L') for the history.

And how would I know this?

Re: Some developement questions

[Filipp Gunbin]

On 31/08/2018 01:49 +0200, hw wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 29/08/2018 22:52 +0200, hw wrote:
>>
>>> I ended up getting stuck in the help documentation of info and
>>> actually had to kill the buffer to be able to start over because I
>>> couldn't get anywhere else from there.
>>
>> You could use `C-h m' to find about Info-history-back which is bound to
>> `l'.  Or Info-history (`L') for the history.
>
> And how would I know this?

The same way as a user would know about `C-h k' or other basic help
commands.  If a user doesn't know them (from manuals or tutorials), then
she probably should not switch off menu/tool bars.  Just to not get
lost.

Re: Some developement questions

[hw]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 31/08/2018 01:49 +0200, hw wrote:
>
>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>
>>> On 29/08/2018 22:52 +0200, hw wrote:
>>>
>>>> I ended up getting stuck in the help documentation of info and
>>>> actually had to kill the buffer to be able to start over because I
>>>> couldn't get anywhere else from there.
>>>
>>> You could use `C-h m' to find about Info-history-back which is bound to
>>> `l'.  Or Info-history (`L') for the history.
>>
>> And how would I know this?
>
> The same way as a user would know about `C-h k' or other basic help
> commands.  If a user doesn't know them (from manuals or tutorials), then
> she probably should not switch off menu/tool bars.  Just to not get
> lost.

Ok, Emacs should be able to automatically switch on or off the menu (and
perhaps the tool bar) depending on the mode of a buffer.

Info mode should understand the contemporary key bindings M-left and
M-right to go back and forth in the history.  (Those are bound to
movement by word, which is probably not extremely useful in info
buffers.)

Should I make a feature request?

Re: Some developement questions

[Filipp Gunbin]

On 04/09/2018 16:16 +0200, hw wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 31/08/2018 01:49 +0200, hw wrote:
>>
>>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>>
>>>> On 29/08/2018 22:52 +0200, hw wrote:
>>>>
>>>>> I ended up getting stuck in the help documentation of info and
>>>>> actually had to kill the buffer to be able to start over because I
>>>>> couldn't get anywhere else from there.
>>>>
>>>> You could use `C-h m' to find about Info-history-back which is bound to
>>>> `l'.  Or Info-history (`L') for the history.
>>>
>>> And how would I know this?
>>
>> The same way as a user would know about `C-h k' or other basic help
>> commands.  If a user doesn't know them (from manuals or tutorials), then
>> she probably should not switch off menu/tool bars.  Just to not get
>> lost.
>
> Ok, Emacs should be able to automatically switch on or off the menu (and
> perhaps the tool bar) depending on the mode of a buffer.

Emacs cannot guess for the user when she needs or does not need a menu
bar or a tool bar.  You have to instruct it to, somehow.

> Info mode should understand the contemporary key bindings M-left and
> M-right to go back and forth in the history.  (Those are bound to
> movement by word, which is probably not extremely useful in info
> buffers.)
>
> Should I make a feature request?

It's very useful.  At least for me - when I read info, I usually move
the cursor by word or by sentence.

Well, this thread looks like you're describing how you fight with Emacs
defaults.  You could make your own set of customizations and see what
comes out of it.  Maybe others will find them useful.

Have you looked at Emacs derivatives, like Spacemacs?  I think they
should be closer to "modern" editors than vanilla Emacs.

Re: Some developement questions

[hw]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 04/09/2018 16:16 +0200, hw wrote:
>
>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>
>>> On 31/08/2018 01:49 +0200, hw wrote:
>>>
>>>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>>>
>>>>> On 29/08/2018 22:52 +0200, hw wrote:
>>>>>
>>>>>> I ended up getting stuck in the help documentation of info and
>>>>>> actually had to kill the buffer to be able to start over because I
>>>>>> couldn't get anywhere else from there.
>>>>>
>>>>> You could use `C-h m' to find about Info-history-back which is bound to
>>>>> `l'.  Or Info-history (`L') for the history.
>>>>
>>>> And how would I know this?
>>>
>>> The same way as a user would know about `C-h k' or other basic help
>>> commands.  If a user doesn't know them (from manuals or tutorials), then
>>> she probably should not switch off menu/tool bars.  Just to not get
>>> lost.
>>
>> Ok, Emacs should be able to automatically switch on or off the menu (and
>> perhaps the tool bar) depending on the mode of a buffer.
>
> Emacs cannot guess for the user when she needs or does not need a menu
> bar or a tool bar.  You have to instruct it to, somehow.

Can I do that per mode?  So I could have them automatically enabled when
in info mode and automatically disabled when not?  Emacs could
automatically remember the last setting for each mode I used, so no
additional instructing would be necessary.

>> Info mode should understand the contemporary key bindings M-left and
>> M-right to go back and forth in the history.  (Those are bound to
>> movement by word, which is probably not extremely useful in info
>> buffers.)
>>
>> Should I make a feature request?
>
> It's very useful.  At least for me - when I read info, I usually move
> the cursor by word or by sentence.

That probably means there would be a lot of resistance to get these
useful key bindings to be the default :(

Please try word-wise movement on a German keyboard with these keys.  Do
not use the Alt key for this because it has been almost 30 years that it
was not possible to use that like ESC at all.  Force yourself to do it
for at least two hours; after that, you may use the Alt key and try for
another two hours.  Then tell me how useful these key bindindings really
are :)

> Well, this thread looks like you're describing how you fight with Emacs
> defaults.  You could make your own set of customizations and see what
> comes out of it.  Maybe others will find them useful.

You could always change the default to your preference after it has
changed to something people are more likely to know.  You could propose
that all web browsers start using 'l' to move backwards in history, too.

> Have you looked at Emacs derivatives, like Spacemacs?  I think they
> should be closer to "modern" editors than vanilla Emacs.

I looked at vim.  Besides, "modern" doesn't mean "good".

Re: Some developement questions

[Michael Heerdegen]

hw <hw@adminart.net> writes:

> > Emacs cannot guess for the user when she needs or does not need a menu
> > bar or a tool bar.  You have to instruct it to, somehow.
>
> Can I do that per mode?  So I could have them automatically enabled when
> in info mode and automatically disabled when not?  Emacs could
> automatically remember the last setting for each mode I used, so no
> additional instructing would be necessary.

Before considering that, note that you don't need to use the menu bar to
access the menu bar menu.  You can make the menu accessible as a pop up
menu like in

#+begin_src emacs-lisp
(defun my-mouse-menu-bar-menu ()
  (interactive)
  (popup-menu `("Do" ("Menu Bar" ,@(mouse-menu-bar-map)))))

(global-set-key [(control down-mouse-3)] #'my-mouse-menu-bar-menu)
#+end_src

or use a text interface to access the menu - there is a builtin one
called `tmm-menubar'.  Some external packages provide different (maybe
more convenient) interfaces, e.g. Helm or Icicles.


Michael.

RE: Some developement questions

[Drew Adams]

> or use a text interface to access the menu - there is a builtin one
> called `tmm-menubar'.  Some external packages provide different (maybe
> more convenient) interfaces, e.g. Helm or Icicles.

Icicles doesn't provide an interface for menus.
But it makes LaCarte's interface handier by providing better completion.

https://www.emacswiki.org/emacs/LaCarte

Re: Some developement questions

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> https://www.emacswiki.org/emacs/LaCarte

Oh, yes, that was it, I forgot.  AFAIR Helm also uses LaCarte for its
access to the menu bar.


Michael.

Re: Some developement questions

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Thu, 06 Sep 2018 03:33:56 +0200
> Cc: Filipp Gunbin <fgunbin@fastmail.fm>, emacs-devel@gnu.org
> 
> Before considering that, note that you don't need to use the menu bar to
> access the menu bar menu.  You can make the menu accessible as a pop up
> menu like in
> 
> #+begin_src emacs-lisp
> (defun my-mouse-menu-bar-menu ()
>   (interactive)
>   (popup-menu `("Do" ("Menu Bar" ,@(mouse-menu-bar-map)))))
> 
> (global-set-key [(control down-mouse-3)] #'my-mouse-menu-bar-menu)
> #+end_src

When the menu-bar is disabled, C-mouse-3 pops up the same menu as a
popup, so no Lisp is necessary to get to the global menus.

> or use a text interface to access the menu - there is a builtin one
> called `tmm-menubar'.

Emacs nowadays supports menus even on TTY frames, so no need to use
tmm-menubar (unless one wants to, of course).

RE: Some developement questions

[Drew Adams]

> When the menu-bar is disabled, C-mouse-3 pops up the same menu as a
> popup, so no Lisp is necessary to get to the global menus.

Good point.

And the major and minor mode menus are typically available from the mode-line (at least for a minor mode that has a mode-line lighter).

Re: Some developement questions

[hw]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> hw <hw@adminart.net> writes:
>
>> > Emacs cannot guess for the user when she needs or does not need a menu
>> > bar or a tool bar.  You have to instruct it to, somehow.
>>
>> Can I do that per mode?  So I could have them automatically enabled when
>> in info mode and automatically disabled when not?  Emacs could
>> automatically remember the last setting for each mode I used, so no
>> additional instructing would be necessary.
>
> Before considering that, note that you don't need to use the menu bar to
> access the menu bar menu.  You can make the menu accessible as a pop up
> menu like in

The disadvantage with this is that I need to remember to enable and to
use the menu.  Enabling it manually isn't the problem.

When it's enabled automatically, it tells me that for some reason I
wanted that, and I'm more likely to use it.

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Date: Wed, 05 Sep 2018 22:36:09 +0200
> Cc: emacs-devel@gnu.org
> 
> > Emacs cannot guess for the user when she needs or does not need a menu
> > bar or a tool bar.  You have to instruct it to, somehow.
> 
> Can I do that per mode?

You can enable/disable menu-bar-mode in a mode hook.

> So I could have them automatically enabled when in info mode and
> automatically disabled when not?  Emacs could automatically remember
> the last setting for each mode I used, so no additional instructing
> would be necessary.

Save your mode hooks in your .emacs, and Bob's your uncle.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Date: Wed, 05 Sep 2018 22:36:09 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> > Emacs cannot guess for the user when she needs or does not need a menu
>> > bar or a tool bar.  You have to instruct it to, somehow.
>> 
>> Can I do that per mode?
>
> You can enable/disable menu-bar-mode in a mode hook.
>
>> So I could have them automatically enabled when in info mode and
>> automatically disabled when not?  Emacs could automatically remember
>> the last setting for each mode I used, so no additional instructing
>> would be necessary.
>
> Save your mode hooks in your .emacs, and Bob's your uncle.

Thanks, I'll look into that :)

Re: Some developement questions

[Filipp Gunbin]

Hi, 

On 05/09/2018 22:36 +0200, hw wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 04/09/2018 16:16 +0200, hw wrote:
>>
[...]
>>> Ok, Emacs should be able to automatically switch on or off the menu (and
>>> perhaps the tool bar) depending on the mode of a buffer.
>>
>> Emacs cannot guess for the user when she needs or does not need a menu
>> bar or a tool bar.  You have to instruct it to, somehow.
>
> Can I do that per mode?  So I could have them automatically enabled when
> in info mode and automatically disabled when not?  Emacs could
> automatically remember the last setting for each mode I used, so no
> additional instructing would be necessary.

Yes, customize change-major-mode-hook or just Info-mode-hook.

>>> Info mode should understand the contemporary key bindings M-left and
>>> M-right to go back and forth in the history.  (Those are bound to
>>> movement by word, which is probably not extremely useful in info
>>> buffers.)
>>>
>>> Should I make a feature request?
>>
>> It's very useful.  At least for me - when I read info, I usually move
>> the cursor by word or by sentence.
>
> That probably means there would be a lot of resistance to get these
> useful key bindings to be the default :(
>
> Please try word-wise movement on a German keyboard with these keys.  Do
> not use the Alt key for this because it has been almost 30 years that it
> was not possible to use that like ESC at all.  Force yourself to do it
> for at least two hours; after that, you may use the Alt key and try for
> another two hours.  Then tell me how useful these key bindindings really
> are :)

I've never worked on a German keyboard (but I've just read
https://en.wikipedia.org/wiki/German_keyboard_layout).  So what's your
exact problem with Alt's?

I do work with Russian keyboard, and I usually use US layout when
working with Emacs, and have (setq default-input-method
'russian-computer) in .emacs, so C-\ switches to it.

You should have 2 Ctrl's and 2 Alt's (one of which could be AltGr) on a
German keyboard, so you should be in same situations as other users.

>> Well, this thread looks like you're describing how you fight with Emacs
>> defaults.  You could make your own set of customizations and see what
>> comes out of it.  Maybe others will find them useful.
>
> You could always change the default to your preference after it has
> changed to something people are more likely to know.  You could propose
> that all web browsers start using 'l' to move backwards in history,
> too.

It's really the first time I heard of Alt+arrow bindings.  Maybe that's
because I don't use keyboard for navigation in a web browser :-)

Filipp

Re: Some developement questions

[hw]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> [...]
>> Please try word-wise movement on a German keyboard with these keys.  Do
>> not use the Alt key for this because it has been almost 30 years that it
>> was not possible to use that like ESC at all.  Force yourself to do it
>> for at least two hours; after that, you may use the Alt key and try for
>> another two hours.  Then tell me how useful these key bindindings really
>> are :)
>
> I've never worked on a German keyboard (but I've just read
> https://en.wikipedia.org/wiki/German_keyboard_layout).  So what's your
> exact problem with Alt's?
>
> I do work with Russian keyboard, and I usually use US layout when
> working with Emacs, and have (setq default-input-method
> 'russian-computer) in .emacs, so C-\ switches to it.

I've never used a Russian one.  That might make a nice collectors item
:)

> You should have 2 Ctrl's and 2 Alt's (one of which could be AltGr) on a
> German keyboard, so you should be in same situations as other users.

AltGr is not an Alt key.  There is only *one* Alt key on German
keyboards, and it's on the left side.

They also have AltGr, and that is an entirely different modifier:


keycode  64 = Alt_L Meta_L Alt_L Meta_L
keycode  92 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift


These two keys do entirely different things.  A German keyboard is not
usable for German when you turn AlGr into Alt.  An US keyboard is not
usable for German because it is missing some important keys.

IIRC, Alt is Mod4 and AltGr is Mod5.  Since they invented the additional
useless keys, these keys have all become so small that the useless ones
get in the way and it's difficult to hit what you want.  That's the only
disadvantage of my current keyboard, otherwise it's even better than a
Model M.  If it wasn't for that, I'd be using one of those.

>>> Well, this thread looks like you're describing how you fight with Emacs
>>> defaults.  You could make your own set of customizations and see what
>>> comes out of it.  Maybe others will find them useful.
>>
>> You could always change the default to your preference after it has
>> changed to something people are more likely to know.  You could propose
>> that all web browsers start using 'l' to move backwards in history,
>> too.
>
> It's really the first time I heard of Alt+arrow bindings.  Maybe that's
> because I don't use keyboard for navigation in a web browser :-)

It's much easier than finding the right icon, especially when they made
the icon so small ...

Re: Some developement questions

[Filipp Gunbin]

On 07/09/2018 09:18 +0200, hw wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
> I've never used a Russian one.  That might make a nice collectors item
> :)

Believe me, there's really nothing special about it.  We usually switch
between English and Cyrillic layout.  All Cyrillic letters are put on
the keyboard directly, with no AltGr or anything like that.  If you
enable "russian-computer" input method in Emacs, you'll get the same as
we have on Russian keyboards.

>> You should have 2 Ctrl's and 2 Alt's (one of which could be AltGr) on a
>> German keyboard, so you should be in same situations as other users.
>
> AltGr is not an Alt key.  There is only *one* Alt key on German
> keyboards, and it's on the left side.
>
> They also have AltGr, and that is an entirely different modifier:
>
>
> keycode  64 = Alt_L Meta_L Alt_L Meta_L
> keycode  92 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift
>
>
> These two keys do entirely different things.  A German keyboard is not
> usable for German when you turn AlGr into Alt.  An US keyboard is not
> usable for German because it is missing some important keys.
>
> IIRC, Alt is Mod4 and AltGr is Mod5.  Since they invented the additional
> useless keys, these keys have all become so small that the useless ones
> get in the way and it's difficult to hit what you want.  That's the only
> disadvantage of my current keyboard, otherwise it's even better than a
> Model M.  If it wasn't for that, I'd be using one of those.

Yes, I see from the article that you have that additional (third) level
of alteration, besides normal keys and shifted keys.

I see three German input methods in Emacs (`C-h I g e r TAB TAB'):
german, german-prefix, german-postfix.  Are they not enought for a
typical usage?  If not, then what do other German users here use?

As for Alt's, at least you have one normal Alt.  I have a similar
problem on Macbook, where we have two Command keys, and only one Ctrl.
I swapped them on OS level.  I also swapped resulting Ctrl with Alt, so
I have this: COMMAND CTRL ALT SPACE ALT CTRL without any fancy Emacs
settings.  Not all users actually use right Alt and Ctrl, but I do, so
it's important for me to have symmetric keys to the right of spacebar.

Filipp

Re: Some developement questions

[hw]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 07/09/2018 09:18 +0200, hw wrote:
>
>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>
>> I've never used a Russian one.  That might make a nice collectors item
>> :)
>
> Believe me, there's really nothing special about it.  We usually switch
> between English and Cyrillic layout.  All Cyrillic letters are put on
> the keyboard directly, with no AltGr or anything like that.  If you
> enable "russian-computer" input method in Emacs, you'll get the same as
> we have on Russian keyboards.

Well, I don't know how to read these letters while you see them all
around all the time, so it's not special for you.

>>> You should have 2 Ctrl's and 2 Alt's (one of which could be AltGr) on a
>>> German keyboard, so you should be in same situations as other users.
>>
>> AltGr is not an Alt key.  There is only *one* Alt key on German
>> keyboards, and it's on the left side.
> [...]
>
> Yes, I see from the article that you have that additional (third) level
> of alteration, besides normal keys and shifted keys.

We have a few characters for which there are no keys available, so
someone invented AltGr to make them available.  The result is that
symbols easy to reach on US keyboards are difficult to reach because the
keys that are easy to reach carry the additional characters, and the
symbols are only reachable with AltGr.

That was really stupid; they should just have added a couple more keys
instead.

> I see three German input methods in Emacs (`C-h I g e r TAB TAB'):
> german, german-prefix, german-postfix.  Are they not enought for a
> typical usage?  If not, then what do other German users here use?

I have no idea, I never picked an input method and never saw a need to
do that, so I don't know about them.

> As for Alt's, at least you have one normal Alt.  I have a similar
> problem on Macbook, where we have two Command keys, and only one Ctrl.
> I swapped them on OS level.  I also swapped resulting Ctrl with Alt, so
> I have this: COMMAND CTRL ALT SPACE ALT CTRL without any fancy Emacs
> settings.  Not all users actually use right Alt and Ctrl, but I do, so
> it's important for me to have symmetric keys to the right of spacebar.

Macs are most awful, they didn't even get the keyboard right ...

I usually make a few changes, like turning CapsLock into Ctrl, replacing
the comma on the keypad with a dot, putting / on the tilde key where, on
most keyboards, the * is, and a second Alt key on the useless key on the
right side wich is usually between AltGr and Ctrl.  So I have a map for
every keyboard I have.

I just wish I had a keyboard with real 122 keys all outemu switches.  It
doesn't get any better than those.

Re: Some developement questions

[Filipp Gunbin]

On 07/09/2018 23:27 +0200, hw wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 07/09/2018 09:18 +0200, hw wrote:
>>
>>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>>
>>> I've never used a Russian one.  That might make a nice collectors item
>>> :)
>>
>> Believe me, there's really nothing special about it.  We usually switch
>> between English and Cyrillic layout.  All Cyrillic letters are put on
>> the keyboard directly, with no AltGr or anything like that.  If you
>> enable "russian-computer" input method in Emacs, you'll get the same as
>> we have on Russian keyboards.
>
> Well, I don't know how to read these letters while you see them all
> around all the time, so it's not special for you.

You may well not be able to read the letters, but the layout is
structured like the US layout - lowercase and uppercase letters, digits
and some punctuation.  In that sense it is "simpler" than levels of
alterations in German layout (at least to me :-)

>>>> You should have 2 Ctrl's and 2 Alt's (one of which could be AltGr)
>>>> on a German keyboard, so you should be in same situations as other
>>>> users.
>>>
>>> AltGr is not an Alt key.  There is only *one* Alt key on German
>>> keyboards, and it's on the left side.
>> [...]
>>
>> Yes, I see from the article that you have that additional (third) level
>> of alteration, besides normal keys and shifted keys.
>
> We have a few characters for which there are no keys available, so
> someone invented AltGr to make them available.  The result is that
> symbols easy to reach on US keyboards are difficult to reach because the
> keys that are easy to reach carry the additional characters, and the
> symbols are only reachable with AltGr.
>
> That was really stupid; they should just have added a couple more keys
> instead.

Have you tried Emacs input methods I wrote about?  My impression is that
for any non-US script it should be convenient to use input methods.  It
might be the case that I'm wrong and people in Germany don't switch
between layouts, and do everything in default German layout.  But, say,
for Russian that is simply not possible, because the whole keyboard is
taken by Cyrillic alphabet.

Of course we have OS-level switch, but I don't use that in Emacs because
other keys break (but they remain functional with input method turned
on).  I use OS-level layout switch only in other apps.

Filipp

Re: Some developement questions

[hw]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 07/09/2018 23:27 +0200, hw wrote:
>
>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>
>>> On 07/09/2018 09:18 +0200, hw wrote:
>>>
>>>> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>>>>
>>>> I've never used a Russian one.  That might make a nice collectors item
>>>> :)
>>>
>>> Believe me, there's really nothing special about it.  We usually switch
>>> between English and Cyrillic layout.  All Cyrillic letters are put on
>>> the keyboard directly, with no AltGr or anything like that.  If you
>>> enable "russian-computer" input method in Emacs, you'll get the same as
>>> we have on Russian keyboards.
>>
>> Well, I don't know how to read these letters while you see them all
>> around all the time, so it's not special for you.
>
> You may well not be able to read the letters, but the layout is
> structured like the US layout - lowercase and uppercase letters, digits
> and some punctuation.  In that sense it is "simpler" than levels of
> alterations in German layout (at least to me :-)

That gives you the advantage of having such a layout :)

>>>>> You should have 2 Ctrl's and 2 Alt's (one of which could be AltGr)
>>>>> on a German keyboard, so you should be in same situations as other
>>>>> users.
>>>>
>>>> AltGr is not an Alt key.  There is only *one* Alt key on German
>>>> keyboards, and it's on the left side.
>>> [...]
> Have you tried Emacs input methods I wrote about?  My impression is that
> for any non-US script it should be convenient to use input methods.  It
> might be the case that I'm wrong and people in Germany don't switch
> between layouts, and do everything in default German layout.  But, say,
> for Russian that is simply not possible, because the whole keyboard is
> taken by Cyrillic alphabet.
>
> Of course we have OS-level switch, but I don't use that in Emacs because
> other keys break (but they remain functional with input method turned
> on).  I use OS-level layout switch only in other apps.

I need to read about input methods first.  All the keys and characters
are there plus a few, so we don't switch between layouts.  Some of the
characters are more difficult to reach than on the US layout.

It might be helpful to switch layouts for programming.  That would
involve to create two xmodmaps for each keyboard and finding a way to
switch.  Since the keys are physically not the same on all boards, that
can get confusing.

Re: Some developement questions

[Filipp Gunbin]

On 10/09/2018 20:18 +0200, hw wrote:

>>>>>> You should have 2 Ctrl's and 2 Alt's (one of which could be AltGr)
>>>>>> on a German keyboard, so you should be in same situations as other
>>>>>> users.
>>>>>
>>>>> AltGr is not an Alt key.  There is only *one* Alt key on German
>>>>> keyboards, and it's on the left side.
>>>> [...]
>> Have you tried Emacs input methods I wrote about?  My impression is that
>> for any non-US script it should be convenient to use input methods.  It
>> might be the case that I'm wrong and people in Germany don't switch
>> between layouts, and do everything in default German layout.  But, say,
>> for Russian that is simply not possible, because the whole keyboard is
>> taken by Cyrillic alphabet.
>>
>> Of course we have OS-level switch, but I don't use that in Emacs because
>> other keys break (but they remain functional with input method turned
>> on).  I use OS-level layout switch only in other apps.
>
> I need to read about input methods first.  All the keys and characters
> are there plus a few, so we don't switch between layouts.  Some of the
> characters are more difficult to reach than on the US layout.
>
> It might be helpful to switch layouts for programming.  That would
> involve to create two xmodmaps for each keyboard and finding a way to
> switch.  Since the keys are physically not the same on all boards, that
> can get confusing.

With input methods you don't have to create OS-level layouts.

Re: Some developement questions

[hw]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> On 10/09/2018 20:18 +0200, hw wrote:
> [...]
>> It might be helpful to switch layouts for programming.  That would
>> involve to create two xmodmaps for each keyboard and finding a way to
>> switch.  Since the keys are physically not the same on all boards, that
>> can get confusing.
>
> With input methods you don't have to create OS-level layouts.

I'd have to define input methods for the different keyboards and end up
with keyboard bindings which would only be active in Emacs.  How would
that be an advantage?

Re: Some developement questions

[Filipp Gunbin]

On 11/09/2018 22:14 +0200, hw wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> On 10/09/2018 20:18 +0200, hw wrote:
>> [...]
>>> It might be helpful to switch layouts for programming.  That would
>>> involve to create two xmodmaps for each keyboard and finding a way to
>>> switch.  Since the keys are physically not the same on all boards, that
>>> can get confusing.
>>
>> With input methods you don't have to create OS-level layouts.
>
> I'd have to define input methods for the different keyboards and end up
> with keyboard bindings which would only be active in Emacs.  How would
> that be an advantage?

I think you should read "(emacs) Input Methods" and "(emacs) Select
Input Method", and see if that fits your needs.  Personally I like the
fact that Emacs enables me to use input methods for many scripts without
depending on OS layout and (almost) on physical keyboard layout.

Re: Some developement questions

[Davis Herring]

>>> And I don't remember how to get back when following links in info
>>> documentation
>>
>> You can type 'l' (for "last"), or use the left arrow button on the
>> tool bar, or click on "Info" in the menu bar and select "Back in
>> History", or click on Info->History and select any node you visited at
>> random.
> 
> Ah!  I remembered something about arrows and tried to use the cursor
> keys --- how about making it so that you can go back and forth in info
> with Alt+<Cursor> like you can do in web browsers?

There is the usual issue of Emacs' traditional keybindings clashing with 
those from other (usually newer) domains: Alt generally meaning Meta, 
M-left/M-right are already used for backward-/forward-word.

Of course, we also have M-b/M-f for those, but the point is that such 
changes do not come without cost.  You are free to argue something along 
the lines of "For the future userbase of Emacs, consistency with the 
rest of the world is important enough to change X.", but that's quite a 
bit different from "how about...?".

> I have menu and toolbar disabled ...

Complaining about navigability and discoverability of an interface while 
having disabled its most discoverable features meant to guide new users 
is a strange combination.

> Basically, I want to use the Emacs server the usual way how you use any
> server, like a web server or an ssh server or an XMPP server.

Or an X server, which is attached to the hardware that faces the user? 
There's more than one way to think of the word.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Some developement questions

[hw]

Davis Herring <herring@lanl.gov> writes:

>>>> And I don't remember how to get back when following links in info
>>>> documentation
>>>
>>> You can type 'l' (for "last"), or use the left arrow button on the
>>> tool bar, or click on "Info" in the menu bar and select "Back in
>>> History", or click on Info->History and select any node you visited at
>>> random.
>>
>> Ah!  I remembered something about arrows and tried to use the cursor
>> keys --- how about making it so that you can go back and forth in info
>> with Alt+<Cursor> like you can do in web browsers?
>
> There is the usual issue of Emacs' traditional keybindings clashing
> with those from other (usually newer) domains: Alt generally meaning
> Meta, M-left/M-right are already used for backward-/forward-word.

Meta seems to be ESC.  Alt doesn't do anything like what ESC does, and I
inevitably have two entirely different Alt keys because I'm using a
German keyboard.

Some key combinations that require some combination of Meta and Control
do not work at all.

Who would ever press ESC-right or ESC-left to move a word?

Hm, ok, I tried Alt, and it now does work, at least in an X frame.  Only
the Alt key is on the wrong side of the keyboard, as is ESC, to be
useful for moving.

Since when does Alt work the same as ESC?

> Of course, we also have M-b/M-f for those, but the point is that such
> changes do not come without cost.  You are free to argue something
> along the lines of "For the future userbase of Emacs, consistency with
> the rest of the world is important enough to change X.", but that's
> quite a bit different from "how about...?".

The issue in this case is not traditional key bindings vs. more recently
invented ones.  The issue is that I very rarely use info and thus do not
remember its key bindings.  Does the help page I got stuck in say
anywhere how to get back?

Why shouldn't Emacs adjust to changes and adopt new key bindings so it
becomes easier to use?

>> I have menu and toolbar disabled ...
>
> Complaining about navigability and discoverability of an interface
> while having disabled its most discoverable features meant to guide
> new users is a strange combination.

I'm pointing out a usability issue and you call it complaining.  That
must be the right attitude.

Fine, I'll give vim a try.


PS: I tried vim in the meantime, and I'll probably switch.

>> Basically, I want to use the Emacs server the usual way how you use any
>> server, like a web server or an ssh server or an XMPP server.
>
> Or an X server, which is attached to the hardware that faces the user?
> There's more than one way to think of the word.

I don't want it to use like an X server, and there are always many ways
to think of all words.

Re: Some developement questions

[Joshua Branson]

hw <hw@adminart.net> writes:

> Davis Herring <herring@lanl.gov> writes:
>
>>>>> And I don't remember how to get back when following links in info
>>>>> documentation
>>>>
>>>> You can type 'l' (for "last"), or use the left arrow button on the
>>>> tool bar, or click on "Info" in the menu bar and select "Back in
>>>> History", or click on Info->History and select any node you visited at
>>>> random.
>>>
>>> Ah!  I remembered something about arrows and tried to use the cursor
>>> keys --- how about making it so that you can go back and forth in info
>>> with Alt+<Cursor> like you can do in web browsers?
>>
>> There is the usual issue of Emacs' traditional keybindings clashing
>> with those from other (usually newer) domains: Alt generally meaning
>> Meta, M-left/M-right are already used for backward-/forward-word.
>
> Meta seems to be ESC.  Alt doesn't do anything like what ESC does, and I
> inevitably have two entirely different Alt keys because I'm using a
> German keyboard.
>
> Some key combinations that require some combination of Meta and Control
> do not work at all.
>
> Who would ever press ESC-right or ESC-left to move a word?

part of this reason is why I started to use evil-mode.  :)

>
> Hm, ok, I tried Alt, and it now does work, at least in an X frame.  Only
> the Alt key is on the wrong side of the keyboard, as is ESC, to be
> useful for moving.
>
> Since when does Alt work the same as ESC?
>
>> Of course, we also have M-b/M-f for those, but the point is that such
>> changes do not come without cost.  You are free to argue something
>> along the lines of "For the future userbase of Emacs, consistency with
>> the rest of the world is important enough to change X.", but that's
>> quite a bit different from "how about...?".
>
> The issue in this case is not traditional key bindings vs. more recently
> invented ones.  The issue is that I very rarely use info and thus do not
> remember its key bindings.  Does the help page I got stuck in say
> anywhere how to get back?
>
> Why shouldn't Emacs adjust to changes and adopt new key bindings so it
> becomes easier to use?
>
>>> I have menu and toolbar disabled ...
>>
>> Complaining about navigability and discoverability of an interface
>> while having disabled its most discoverable features meant to guide
>> new users is a strange combination.
>
> I'm pointing out a usability issue and you call it complaining.  That
> must be the right attitude.
>
> Fine, I'll give vim a try.
>
>
> PS: I tried vim in the meantime, and I'll probably switch.
>
>>> Basically, I want to use the Emacs server the usual way how you use any
>>> server, like a web server or an ssh server or an XMPP server.
>>
>> Or an X server, which is attached to the hardware that faces the user?
>> There's more than one way to think of the word.
>
> I don't want it to use like an X server, and there are always many ways
> to think of all words.

Re: Some developement questions

[hw]

Joshua Branson <jbranso@fastmail.com> writes:

>> Who would ever press ESC-right or ESC-left to move a word?
>
> part of this reason is why I started to use evil-mode.  :)

Right, I thought about doing that since starting to learn vim and
understanding how it can be much more efficient than Emacs.  Is it
exactly the same as using vim?

Why not use vim instead?  Does Emacs have advantages over vim when using
evil-mode?  Vim even does syntax highlighting for fvwm out of the box.

I managed to find an fvwm-mode for emacs (which needs some work) years
ago, but why isn't that shipped with Emacs by default?

(Uh, we probably shouldn't discuss this there --- feel free to send me
an email directly :)

Re: Some developement questions

[Ergus]

On Sun, Sep 02, 2018 at 05:07:00PM +0200, hw wrote:
>Joshua Branson <jbranso@fastmail.com> writes:
>
>>> Who would ever press ESC-right or ESC-left to move a word?
>>
>> part of this reason is why I started to use evil-mode.  :)
>
>Right, I thought about doing that since starting to learn vim and
>understanding how it can be much more efficient than Emacs.

That's relative and very subjective. Modal editing makes not too much
sense for me in 2018. It was a solution in a moment but and according to
the vi creator "it was for a world that doesn't exist anymore".

>Is it
>exactly the same as using vim?
>
It depends of your use cases. But for just editing, yes, it is pretty much
the same. Vim users use to complain that evil mode is slower but it is
more a psychological thing; I have tried to measure what they complain
about and if it is, should be in the order of micro seconds.

>Why not use vim instead?  Does Emacs have advantages over vim when using
>evil-mode?

Again. It depends of your use cases. To edit simple files there is not real difference, no advantage or disadvantage as editing is the basic functionality.

But if you do serious programming in big projects, edit remote files in multiple servers cross coping between them, you want to use irony or rtagsor for C++, gtags for cross referencing, gdb inside the same editor, manage cmake projects in the projectile way or simply handle git with magit; or if you plan to customize details for your specific files or systems... it is very hard in vim some of these are impossible. 

>Vim even does syntax highlighting for fvwm out of the box.
>
have you tried config-mode, is a bit generic, but I use i3wm and it works for me?

>I managed to find an fvwm-mode for emacs (which needs some work) years
>ago, but why isn't that shipped with Emacs by default?
>
I thing because the intersection of the groups of people who use fvwm and emacs is close to zero and the package is kind of unmaintained. But you are very welcome to adopt and collaborate with that :)

>(Uh, we probably shouldn't discuss this there --- feel free to send me
>an email directly :)
>
Why not?

Re: Some developement questions

[hw]

Ergus <spacibba@aol.com> writes:

> On Sun, Sep 02, 2018 at 05:07:00PM +0200, hw wrote:
>>Joshua Branson <jbranso@fastmail.com> writes:
>>
>>>> Who would ever press ESC-right or ESC-left to move a word?
>>>
>>> part of this reason is why I started to use evil-mode.  :)
>>
>>Right, I thought about doing that since starting to learn vim and
>>understanding how it can be much more efficient than Emacs.
>
> That's relative and very subjective. Modal editing makes not too much
> sense for me in 2018.

Last night I tried to do some programming with vim, and it was an
interesting experience.  I'm not so sure anymore if it can be much more
efficient than Emacs, provided that you use either 100% the way they're
supposed to be used.  They're probably bascially the same.

But how else than modal would you edit?  The difference between vim and
Emacs is that Emacs` normal mode is vims insert mode, and Emacs can have
a whole mode hiding behind every key you press rather than only one
"command mode" which limits you to the keys you have available and to
stringing them up.

After all, I'll stick with Emacs.  Vim doesn't seem to have any real
advantages for me, and there are some things I'd be missing.

> It was a solution in a moment but and according to the vi creator "it
> was for a world that doesn't exist anymore".

That something is for a world that doesn't exist anymore can be said for
a lot of things.  That doesn't mean that what replaces it is any better,
and indeed the replacements are usually much worse.

>>Is it
>>exactly the same as using vim?
>>
> It depends of your use cases. But for just editing, yes, it is pretty much
> the same. Vim users use to complain that evil mode is slower but it is
> more a psychological thing; I have tried to measure what they complain
> about and if it is, should be in the order of micro seconds.

Someone must have put a lot of work into it.

>>Why not use vim instead?  Does Emacs have advantages over vim when using
>>evil-mode?
>
> Again. It depends of your use cases. To edit simple files there is not
> real difference, no advantage or disadvantage as editing is the basic
> functionality.

Well, that could be said for all editors.

> But if you do serious programming in big projects, edit remote files
> in multiple servers cross coping between them, you want to use irony
> or rtagsor for C++, gtags for cross referencing, gdb inside the same
> editor, manage cmake projects in the projectile way or simply handle
> git with magit; or if you plan to customize details for your specific
> files or systems... it is very hard in vim some of these are
> impossible. 

That seems to go along with my impression that Emacs has some
fundamental features that have allowed it to become far more
sophisticated than vim.  To begin with, vim is painfully lacking the
concept of buffers Emacs has always had.

>>Vim even does syntax highlighting for fvwm out of the box.
>>
> have you tried config-mode, is a bit generic, but I use i3wm and it works for me?

Maybe that is what vim is using.

>>I managed to find an fvwm-mode for emacs (which needs some work) years
>>ago, but why isn't that shipped with Emacs by default?
>>
> I thing because the intersection of the groups of people who use fvwm
> and emacs is close to zero

Why wouldn't people using Emacs not also use fvwm?  I'd say particularly
those using fvwm would be using Emacs, and the other way round.

Besides, why would anyone use anything else than fvwm?

> and the package is kind of unmaintained. But you are very welcome to
> adopt and collaborate with that :)

Yeah I'm thinking about doing that.  It must be rather old because it
doesn't seem to recognize quite a few of the keywords.

Hm, the version I have is 8 years old, and it says it's under GPL.  Do
you know anything about it?  I only remember I found it somewhere, and
it could be painfully slow sometimes.

,----
| ;; $Id: fvwm-mode.el 232 2010-10-29 16:48:05Z dragon $
| ;; 
| ;; Release 1.6.2
| ;; 
| ;; Copyright (C) 2005-2009 Bert Geens <bert@lair.be>
`----

Well, i could ask him :)  Or perhaps there is an entirely different
mode?

>>(Uh, we probably shouldn't discuss this there --- feel free to send me
>>an email directly :)
>>
> Why not?

This is a development mailing list, and I wouldn't want to start an
editor war.

Re: Some developement questions

[Ergus]

On Tue, Sep 04, 2018 at 05:21:40PM +0200, hw wrote:
>Ergus <spacibba@aol.com> writes:
>
>> On Sun, Sep 02, 2018 at 05:07:00PM +0200, hw wrote:
>>>Joshua Branson <jbranso@fastmail.com> writes:
>>>
>>>>> Who would ever press ESC-right or ESC-left to move a word?
>>>>
>>>> part of this reason is why I started to use evil-mode.  :)
>>>
>>>Right, I thought about doing that since starting to learn vim and
>>>understanding how it can be much more efficient than Emacs.
>>
>> That's relative and very subjective. Modal editing makes not too much
>> sense for me in 2018.
>
>Last night I tried to do some programming with vim, and it was an
>interesting experience.  I'm not so sure anymore if it can be much more
>efficient than Emacs, provided that you use either 100% the way they're
>supposed to be used.  They're probably bascially the same.
>
Yes, more or less I agree.
>
>But how else than modal would you edit?  The difference between vim and
>Emacs is that Emacs` normal mode is vims insert mode, and Emacs can have
>a whole mode hiding behind every key you press rather than only one
>"command mode" which limits you to the keys you have available and to
>stringing them up.
>
I my brain at least a text editor should edit and insert a letter if I
press it, and extra things require extra commands. The real issue for me
is that I can only use the terminal and many keybinds are not available
(C-backspace or S-C-backspace for example). That's the reason I have
considered to use evil mode sometimes.

>After all, I'll stick with Emacs.  Vim doesn't seem to have any real
>advantages for me, and there are some things I'd be missing.
>
>> It was a solution in a moment but and according to the vi creator "it
>> was for a world that doesn't exist anymore".
>
>That something is for a world that doesn't exist anymore can be said for
>a lot of things.  That doesn't mean that what replaces it is any better,
>and indeed the replacements are usually much worse.
>
I agree, that's why we still use emacs :) (or vim). But I find the
justification that vim users should move with hjkl (and so on) because it
is faster and better because the fingers don't move... so senseless. Is just my feeling.

But sometimes I understand them when I have to type C-a C-SPC C-e M-w to
select a line because xterm doesn't send C-backspace to emacs.

>>>Is it
>>>exactly the same as using vim?
>>>
>> It depends of your use cases. But for just editing, yes, it is pretty much
>> the same. Vim users use to complain that evil mode is slower but it is
>> more a psychological thing; I have tried to measure what they complain
>> about and if it is, should be in the order of micro seconds.
>
>Someone must have put a lot of work into it.
>
>>>Why not use vim instead?  Does Emacs have advantages over vim when using
>>>evil-mode?
>>
>> Again. It depends of your use cases. To edit simple files there is not
>> real difference, no advantage or disadvantage as editing is the basic
>> functionality.
>
>Well, that could be said for all editors.

Exactly. Emacs is not just an editor, but as a simple editor even nano
is good enough (except for the undo lacking but our redo is not as good
as it can be without undo-tree, this is one of the default things I
would really like to change, the default undo behavior).
>
>> But if you do serious programming in big projects, edit remote files
>> in multiple servers cross coping between them, you want to use irony
>> or rtagsor for C++, gtags for cross referencing, gdb inside the same
>> editor, manage cmake projects in the projectile way or simply handle
>> git with magit; or if you plan to customize details for your specific
>> files or systems... it is very hard in vim some of these are
>> impossible.
>
>That seems to go along with my impression that Emacs has some
>fundamental features that have allowed it to become far more
>sophisticated than vim.  To begin with, vim is painfully lacking the
>concept of buffers Emacs has always had.
>
>>>Vim even does syntax highlighting for fvwm out of the box.
>>>
>> have you tried config-mode, is a bit generic, but I use i3wm and it works for me?
>
>Maybe that is what vim is using.
>
>>>I managed to find an fvwm-mode for emacs (which needs some work) years
>>>ago, but why isn't that shipped with Emacs by default?
>>>
>> I thing because the intersection of the groups of people who use fvwm
>> and emacs is close to zero
>
>Why wouldn't people using Emacs not also use fvwm?  I'd say particularly
>those using fvwm would be using Emacs, and the other way round.
>
>Besides, why would anyone use anything else than fvwm?
>
JA JA, I didn't even know that fvwm existed, I will give a try :p but I prefer tilling wm.

>> and the package is kind of unmaintained. But you are very welcome to
>> adopt and collaborate with that :)
>
>Yeah I'm thinking about doing that.  It must be rather old because it
>doesn't seem to recognize quite a few of the keywords.
>
>Hm, the version I have is 8 years old, and it says it's under GPL.  Do
>you know anything about it?  I only remember I found it somewhere, and
>it could be painfully slow sometimes.
>
>,----
>| ;; $Id: fvwm-mode.el 232 2010-10-29 16:48:05Z dragon $
>| ;;
>| ;; Release 1.6.2
>| ;;
>| ;; Copyright (C) 2005-2009 Bert Geens <bert@lair.be>
>`----
>
>Well, i could ask him :)  Or perhaps there is an entirely different
>mode?
>
>>>(Uh, we probably shouldn't discuss this there --- feel free to send me
>>>an email directly :)
>>>
>> Why not?
>
>This is a development mailing list, and I wouldn't want to start an
>editor war.
>
The editor war finished a long time ago and in spite nobody won then,
now Emacs is sadly loosing the postwar stage in my opinion. That's a long discussion to have.

Best,
Esgus

Re: Some developement questions

[hw]

Ergus <spacibba@aol.com> writes:

> On Tue, Sep 04, 2018 at 05:21:40PM +0200, hw wrote:
> [...]
>>
>>But how else than modal would you edit?  The difference between vim and
>>Emacs is that Emacs` normal mode is vims insert mode, and Emacs can have
>>a whole mode hiding behind every key you press rather than only one
>>"command mode" which limits you to the keys you have available and to
>>stringing them up.
>>
> I my brain at least a text editor should edit and insert a letter if I
> press it, and extra things require extra commands.

Hm, it doesn't really matter to me if insert or command mode is the
default.

> The real issue for me is that I can only use the terminal and many
> keybinds are not available (C-backspace or S-C-backspace for
> example). That's the reason I have considered to use evil mode
> sometimes.

Yeah, that's annoying.  Maybe I should find some key bindings for things
like this that work in terminals, too.

>>After all, I'll stick with Emacs.  Vim doesn't seem to have any real
>>advantages for me, and there are some things I'd be missing.
>>
>>> It was a solution in a moment but and according to the vi creator "it
>>> was for a world that doesn't exist anymore".
>>
>>That something is for a world that doesn't exist anymore can be said for
>>a lot of things.  That doesn't mean that what replaces it is any better,
>>and indeed the replacements are usually much worse.
>>
> I agree, that's why we still use emacs :) (or vim).

I like using Emacs, and there simply is nothing better than Emacs and
vim.  There don't need to be any replacements for them.

> But I find the justification that vim users should move with hjkl (and
> so on) because it is faster and better because the fingers don't
> move... so senseless. Is just my feeling.

It's true; the problem is that this idea breaks because there are too
many occassions when you have to move with the cursor keys instead.
That makes it difficult because you always need to decide which keys you
can currently use to move, or you don't decide and always use the cursor
keys.

I use the cursor keys and Cltr-a and Ctrl-e and Ctrl-l, and that's how
vim already doesn't have any advantages for me but even disadvantages.

> But sometimes I understand them when I have to type C-a C-SPC C-e M-w to
> select a line because xterm doesn't send C-backspace to emacs.

Right:


;; my-mark-line

(defun my-mark-this-line ()
  (interactive)
  (beginning-of-line)
  (set-mark-command nil)
  (end-of-line))

(defun my-copy-this-line ()
  (interactive)
  (my-mark-this-line)
  (kill-ring-save (mark) (point))
  (message "copied current line"))

(defun my-cut-this-line ()
  (interactive)
  (my-mark-this-line)
  (kill-region (mark) (point))
  (message "cut current line"))


;; ~/.emacs

(load "~/emacs/my-mark-line")
(global-set-key "\C-xl" 'my-mark-this-line)
(global-set-key "\C-xc" 'my-copy-this-line)
(global-set-key "\C-xw" 'my-cut-this-line)


If someone needs license info:  GPL v. 2

Is something like this really not already built in?  If C-k is intended
for this, it doesn't work out quite like that.

>>> Again. It depends of your use cases. To edit simple files there is not
>>> real difference, no advantage or disadvantage as editing is the basic
>>> functionality.
>>
>>Well, that could be said for all editors.
>
> Exactly. Emacs is not just an editor, but as a simple editor even nano
> is good enough (except for the undo lacking but our redo is not as good
> as it can be without undo-tree, this is one of the default things I
> would really like to change, the default undo behavior).

Nano sucks when you want to search for something and when you want to
save something.  I don't like it.

> [...]
>>Why wouldn't people using Emacs not also use fvwm?  I'd say particularly
>>those using fvwm would be using Emacs, and the other way round.
>>
>>Besides, why would anyone use anything else than fvwm?
>>
> JA JA, I didn't even know that fvwm existed, I will give a try :p but I prefer tilling wm.

Fvwm can do that, here are some hints:


DestroyMenu  MenuArrangeWindows
AddToMenu    MenuArrangeWindows
+ "Arrange Windows"                             Title
+ ""                                            Nop
+ "&V-Tile 2"                                   FvwmRearrange -tile -a -mn 2 -noraise 0 0 100 100
+ "V-Tile 3"                                    FvwmRearrange -tile -a -mn 3 -noraise 0 0 100 100
+ "V-Tile 4"                                    FvwmRearrange -tile -a -mn 4 -noraise 0 0 100 100
+ ""                                            Nop
+ "H-Tile 2"                                    FvwmRearrange -tile -h -a -mn 2 -noraise 0 0 100 100
+ "H-Tile 3"                                    FvwmRearrange -tile -h -a -mn 3 -noraise 0 0 100 100
+ "H-Tile 4"                                    FvwmRearrange -tile -h -a -mn 4 -noraise 0 0 100 100
+ ""                                            Nop
+ "This &Half"                                  Function HalfReplace
+ "This &Maximize"                              Function MaxReplace
+ "This &Quarter"                               Function QuarterReplace


DestroyFunc HalfReplace
AddToFunc HalfReplace
+ I Resize frame 50 100
+ I PlaceAgain
+ I WarpToWindow 50 50

DestroyFunc MaxReplace
AddToFunc MaxReplace
+ I Resize frame 100 100
+ I Move 0 0
+ I WarpToWindow 50 50

DestroyFunc QuarterReplace
AddToFunc QuarterReplace
+ I Resize frame 50 50
+ I PlaceAgain
+ I WarpToWindow 50 50

Style *           MinOverlapPercentPlacement
Style *           FixedPPosition
Style *           !UsePPosition
Style *           EWMHIgnoreStackingOrderHints
Style *           EWMHIgnoreStrutHints
Style *           EWMHPlacementIgnoreWorkingArea
Style *           EWMHIgnoreStateHints
Style *           DecorateTransient
Style *           !UseTransientPPosition
Style *           FocusFollowsMouse
Style *           SnapAttraction 16 All ScreenAll
Style *           StickyIcon
Style *           IgnoreRestack


It's not strictly tiling like i3 does, but for all intents and purposes,
the outcome is the same, while I can just do whatever I want.  It gives
you best of both floating and tiling with great elegance, simplicty and
ease.

Now fvwm manages the windows for me rather than that I have to manage
them.  Put the window menu or the functions on key bindings, and it
takes only a key or two to get the windows arranged the way you want.

It takes a while to get the hang of configuring fvwm, and it is
extremely worthwhile to learn it.  You only need to learn it so far as
to be able to configure it the way you want it.

>>>>(Uh, we probably shouldn't discuss this there --- feel free to send me
>>>>an email directly :)
>>>>
>>> Why not?
>>
>>This is a development mailing list, and I wouldn't want to start an
>>editor war.
>>
> The editor war finished a long time ago and in spite nobody won then,
> now Emacs is sadly loosing the postwar stage in my opinion. That's a long discussion to have.

That doesn't mean a new one couldn't begin, or that it couldn't be
continued.  I never took part in it.

If Emacs is really loosing, it's probably because of little things, like
the tutorial Emacs has needing to become much more inviting and user
friendly.  What it does best is probably driving potential users away.

Re: Some developement questions

[Phil Sainty]

On 02/09/18 05:40, hw wrote:
> Since when does Alt work the same as ESC?

I can't see a Meta key on a vt100 keyboard, so I suspect this has
been the situation from the beginning (so 30+ years for GNU Emacs
alone).


> Why shouldn't Emacs adjust to changes and adopt new key bindings so
> it becomes easier to use?

It's important to understand that changes which would make life easier
for you may well be making life harder for existing users.  Changing
established key bindings (which have been in muscle memory of many
users for literal decades) is a big deal.

Emacs provides tremendous flexibility when it comes to customising its
key bindings to meet your personal preferences; but remember that they
are your *personal* preferences, which may not match the preferences
or expectations of other users.


> The issue is that I very rarely use info and thus do not remember
> its key bindings.  Does the help page I got stuck in say anywhere
> how to get back?

Everything you need is in the Info menu.


>>> I have menu and toolbar disabled ...
>>
>> Complaining about navigability and discoverability of an interface
>> while having disabled its most discoverable features meant to guide
>> new users is a strange combination.
>
> I'm pointing out a usability issue and you call it complaining.

The menu bar directly addresses that usability issue.  That's its
purpose.

It's a bit like removing the training wheels from a bicycle and then
wondering why the bike allowed you to fall over when you lost your
balance, no?

I wouldn't recommend disabling the menus in *any* application without
establishing how to access them again if you realised you needed to.
With Emacs, even with the menu bar disabled, you still have access to
them via F10 or M-` and in GUI frames the Info menu is also directly
available via the mode line.


-Phil

Re: Some developement questions

[hw]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 02/09/18 05:40, hw wrote:
>> Since when does Alt work the same as ESC?
>
> I can't see a Meta key on a vt100 keyboard, so I suspect this has
> been the situation from the beginning (so 30+ years for GNU Emacs
> alone).

I tried it the other day, and I can say that is the first time in about
30 years that it worked.  IIRC, the Atari ST didn't have an Alt key,
either, and that is the first computer I used Emacs on.

It doesn't really matter because the Alt key is on the same side of the
keyboard as the ESC key, which is simply the wrong side for this
application.  Changing the key bindings would be difficult, and it tends
to be inconvenient when using Emacs on other computers, so I prefer to
keep them at their defaults.

How many users are using Emacs with VT100 keyboards?

>> Why shouldn't Emacs adjust to changes and adopt new key bindings so
>> it becomes easier to use?
>
> It's important to understand that changes which would make life easier
> for you may well be making life harder for existing users.  Changing
> established key bindings (which have been in muscle memory of many
> users for literal decades) is a big deal.

Yes, I'm not suggesting to remove existing key bindings for this, only
to add Alt+left and Alt+right to go back and forth in info buffers.

Here's another idea I had this morning while making coffee:

Users may prefer reading documentation in a web browser for at least two
reasons: Navigation is easier, and the browser can have Tabs.  This is
kinda only one reason, but can Emacs have Tabs?

If Emacs can have Tabs and show its documentation with all the ease a
web browser can, life would be much easier for many users.

> Emacs provides tremendous flexibility when it comes to customising its
> key bindings to meet your personal preferences; but remember that they
> are your *personal* preferences, which may not match the preferences
> or expectations of other users.

I have different key bindings for Emacs at work than I have at home.  It
has taken years before I finally sent parts of my ~/.emacs over, and I
only did that when I was at it anyway.

Why?  It takes time to do all that.  I will continue to miss 'F8 d'
which puts the current date at point into the current buffer because
that requires more time to get working.

There are reasons why I suggested it would be nice if we could package a
configuration, including all dependencies, easily.

I'm finding it very annoying that some keys, and thus some key bindings,
do not work when using Emacs in a terminal, like Ctrl+Home and Ctrl+End
only work in X frames.

>> The issue is that I very rarely use info and thus do not remember
>> its key bindings.  Does the help page I got stuck in say anywhere
>> how to get back?
>
> Everything you need is in the Info menu.

That doesn't help when the menu is disabled.

>>>> I have menu and toolbar disabled ...
>>>
>>> Complaining about navigability and discoverability of an interface
>>> while having disabled its most discoverable features meant to guide
>>> new users is a strange combination.
>>
>> I'm pointing out a usability issue and you call it complaining.
>
> The menu bar directly addresses that usability issue.  That's its
> purpose.

The menu is disabled by default because it takes up screen space.  I'm
just not using it, so why leave it enabled?

> It's a bit like removing the training wheels from a bicycle and then
> wondering why the bike allowed you to fall over when you lost your
> balance, no?

I learned riding bicycles over 40 years ago and actually never used
training wheels.  The first ride ended in a pile of sand down the road;
after that, it was ok.

IIRC, Emacs didn't have a menu when I started to learn using it.

> I wouldn't recommend disabling the menus in *any* application without
> establishing how to access them again if you realised you needed to.
> With Emacs, even with the menu bar disabled, you still have access to
> them via F10 or M-` and in GUI frames the Info menu is also directly
> available via the mode line.

It didn't come to mind to use the menu.  You do not deploy the training
wheels of your bike every time you need to go around a corner, do you?

Web browsers nowadays also come with the menu disabled.  Strange world,
huh?

Re: Some developement questions

[Juri Linkov]

>> It's important to understand that changes which would make life easier
>> for you may well be making life harder for existing users.  Changing
>> established key bindings (which have been in muscle memory of many
>> users for literal decades) is a big deal.
>
> Yes, I'm not suggesting to remove existing key bindings for this, only
> to add Alt+left and Alt+right to go back and forth in info buffers.

It's so unfortunate that due to historical reasons we can't provide
intuitive and convenient keys for Info navigation <M-left> and <M-right>.
Long time ago I configured to use Mozilla-like navigation where <M-left>
goes back in history, but <M-right> goes forward in history unless
point is on a link in which case it visits the link.  And like in
Lynx-like navigation, <M-down> and <M-up> move point to the next/prev
link, and when there are no visible links on the page, scroll to next/prev
page.  Maybe as some packages like windmove allow customization
of modifiers for their keys, Info navigation keys could be provided
with a different modifier like <S-left> and <S-right>?

> Users may prefer reading documentation in a web browser for at least two
> reasons: Navigation is easier, and the browser can have Tabs.  This is
> kinda only one reason, but can Emacs have Tabs?
>
> If Emacs can have Tabs and show its documentation with all the ease a
> web browser can, life would be much easier for many users.

Do you mean frame-local or window-local tabs?  Frame-local tabs are now
easier to implement since we have side windows, but I'm still not sure how
a side window can be created above an individual window to contain its
window-local tabbar?

Re: Some developement questions

[martin rudalics]

 > Do you mean frame-local or window-local tabs?  Frame-local tabs are now
 > easier to implement since we have side windows, but I'm still not sure how
 > a side window can be created above an individual window to contain its
 > window-local tabbar?

I'm using atomic windows for that purpose.  I intend to upload a
pakage win-tabs.el (as soon as I fixed some problems with it) to ELPA.

martin

Re: Some developement questions

[hw]

Juri Linkov <juri@linkov.net> writes:

>>> It's important to understand that changes which would make life easier
>>> for you may well be making life harder for existing users.  Changing
>>> established key bindings (which have been in muscle memory of many
>>> users for literal decades) is a big deal.
>>
>> Yes, I'm not suggesting to remove existing key bindings for this, only
>> to add Alt+left and Alt+right to go back and forth in info buffers.
>
> It's so unfortunate that due to historical reasons we can't provide
> intuitive and convenient keys for Info navigation <M-left> and <M-right>.

Why can't that be done?  Who would use word-wise movement while reading
info documents?  It's not like users of Emacs do not use web browsers.

> Long time ago I configured to use Mozilla-like navigation where <M-left>
> goes back in history, but <M-right> goes forward in history unless
> point is on a link in which case it visits the link.  And like in
> Lynx-like navigation, <M-down> and <M-up> move point to the next/prev
> link, and when there are no visible links on the page, scroll to next/prev
> page.

sounds good

> Maybe as some packages like windmove allow customization of modifiers
> for their keys, Info navigation keys could be provided with a
> different modifier like <S-left> and <S-right>?

What would be the point of adding another key binding nobody knows
about?  It could be used for word-wise movement perhaps.

>> Users may prefer reading documentation in a web browser for at least two
>> reasons: Navigation is easier, and the browser can have Tabs.  This is
>> kinda only one reason, but can Emacs have Tabs?
>>
>> If Emacs can have Tabs and show its documentation with all the ease a
>> web browser can, life would be much easier for many users.
>
> Do you mean frame-local or window-local tabs?  Frame-local tabs are now
> easier to implement since we have side windows, but I'm still not sure how
> a side window can be created above an individual window to contain its
> window-local tabbar?

I mean tabs like in a web browser :)

Unfortunately, web browers do not have windows.  That doesn't mean that
Emacs could not have web-browser-like frames which do not allow windows
--- and info documentation and manual pages could be displayed in them.

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  radon.neon@gmail.com,  Phil Sainty <psainty@orcon.net.nz>,  Emacs development discussions <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,  flexibeast@gmail.com
> Date: Tue, 04 Sep 2018 17:35:12 +0200
> 
> Who would use word-wise movement while reading info documents?

Everybody.  For starters, suppose you want to copy/paste some text
from the manual to somewhere else.  And there are many more use cases
that need fine-grained cursor motion in Info buffers.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com, radon.neon@gmail.com, Phil Sainty
>> <psainty@orcon.net.nz>, Emacs development discussions
>> <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>,
>> flexibeast@gmail.com
>> Date: Tue, 04 Sep 2018 17:35:12 +0200
>> 
>> Who would use word-wise movement while reading info documents?
>
> Everybody.  For starters, suppose you want to copy/paste some text
> from the manual to somewhere else.  And there are many more use cases
> that need fine-grained cursor motion in Info buffers.

Word-wise motion is anything but fine-grained, and you can still move
word-wise with Ctrl-left and Ctrl-right.

Did you set your key repeat to be utterly slow, or did you turn it off
entirely?


Other software also uses Ctrl-left and Ctrl-right, so why would anyone,
especially new Emacs users, think of using something so unlikely as
Alt-left or Alt-right for cursor movement?

There are other reasons, too, like using Alt requires using two hands,
which is ok for infrequent things like history movement, and silly for
cursor movement.

Re: Some developement questions

[martin rudalics]

 > If Emacs can have Tabs and show its documentation with all the ease a
 > web browser can, life would be much easier for many users.

Tabs are available via ELPA - see frame-tabs.el.

martin

RE: Some developement questions

[Drew Adams]

> The issue in this case is not traditional key bindings vs. more recently
> invented ones.  The issue is that I very rarely use info and thus do not
> remember its key bindings.  Does the help page I got stuck in say
> anywhere how to get back?

The Info menu-bar menu has menu item `Back in history' (which, for
consistency, should follow the convention and be `Back in History').
And next to that item you'll see its key: `l'.

You'll also find item `Forward in history' and its key, `r' (think "left"
and "right", if you like). And you'll find item `History' and its key, `L'.
Try it, to see what it offers.

In general, Emacs menus can be a good way to discover features (possible actions).

> Why shouldn't Emacs adjust to changes and adopt new key bindings so it
> becomes easier to use?

Who says it hasn't changed key bindings and doesn't become easier to use?

There are (often extended) discussions on this list pretty much every year
about possible key binding changes. Good arguments are typically presented
on multiple sides of the discussions.

Keep in mind that people can have different ideas of what "easier to use"
means, and people use different things in Emacs. Emacs is not a simple
editor with only a few possible actions.

> >> I have menu and toolbar disabled ...
> >
> > Complaining about navigability and discoverability of an interface
> > while having disabled its most discoverable features meant to guide
> > new users is a strange combination.
> 
> I'm pointing out a usability issue and you call it complaining.

If he had not used the word "complaining" would you perhaps get his
point? Menus can help discovery. (Toolbar buttons not so much, IMO.)

Re: Some developement questions

[hw]

Drew Adams <drew.adams@oracle.com> writes:


> [...]
>> I'm pointing out a usability issue and you call it complaining.
>
> If he had not used the word "complaining" would you perhaps get his
> point? Menus can help discovery. (Toolbar buttons not so much, IMO.)

You could suggest making it impossible to disable the menu, at least for
info buffers.  Or what about including menu preferences into every mode,
so that I can have the menu automatically enabled when it may be helpful
and disabled when it is not?  After all, it may be a bit unlikely that I
disable the menu for modes I do not use often.

That users can get easily stuck in the help page of the help system of a
software when trying to read the documentation of this very software
might indicate that it is not always a good idea for this software to
stick to ideosyncratic key bindings just because the software is used by
multiple persons and not easy to use for anyone.

Re: Some developement questions

[Ergus]

On Sat, Sep 01, 2018 at 07:40:48PM +0200, hw wrote:
> Davis Herring <herring@lanl.gov> writes:
> 
> > > > > And I don't remember how to get back when following links in
> > > > > info documentation
> > > > 
> > > > You can type 'l' (for "last"), or use the left arrow button on
> > > > the tool bar, or click on "Info" in the menu bar and select
> > > > "Back in History", or click on Info->History and select any node
> > > > you visited at random.
> > > 
> > > Ah!  I remembered something about arrows and tried to use the
> > > cursor keys --- how about making it so that you can go back and
> > > forth in info with Alt+<Cursor> like you can do in web browsers?
> > 
> > There is the usual issue of Emacs' traditional keybindings clashing
> > with those from other (usually newer) domains: Alt generally meaning
> > Meta, M-left/M-right are already used for backward-/forward-word.
> 
> Meta seems to be ESC.  Alt doesn't do anything like what ESC does, and
> I inevitably have two entirely different Alt keys because I'm using a
> German keyboard.
> 
> Some key combinations that require some combination of Meta and
> Control do not work at all.
> 
> Who would ever press ESC-right or ESC-left to move a word?
> 
> Hm, ok, I tried Alt, and it now does work, at least in an X frame.
> Only the Alt key is on the wrong side of the keyboard, as is ESC, to
> be useful for moving.
> 
> Since when does Alt work the same as ESC?
> 
Alt and ESC in fact doesn't work exactly the same way .

Alt is Meta so it acts as a modifiers; so you need to press it
simultaneously with some other (ex: M-x) to send anything. This is not
emacs this is related with vt*** and traditiona ascii codes.

ESC on the other hand is not a modifier; so it is not needed to press
both keys at the time and you can press one after the other as a
sequence (ex: ESC x)


> > Of course, we also have M-b/M-f for those, but the point is that
> > such changes do not come without cost.  You are free to argue
> > something along the lines of "For the future userbase of Emacs,
> > consistency with the rest of the world is important enough to change
> > X.", but that's quite a bit different from "how about...?".
> 
> The issue in this case is not traditional key bindings vs. more
> recently invented ones.  The issue is that I very rarely use info and
> thus do not remember its key bindings.  Does the help page I got stuck
> in say anywhere how to get back?
> 
> Why shouldn't Emacs adjust to changes and adopt new key bindings so it
> becomes easier to use?

There have been many tries for this, so you have many options to test:

- cua-mode: https://www.emacswiki.org/emacs/CuaMode

- ergoemacs: http://ergoemacs.github.io/

- god-mode: https://github.com/chrisdone/god-mode

- evil, vile and the rest of vim emulation packages.

- And in spacemacs there is something new called hybrid
  mode. http://spacemacs.org/doc/DOCUMENTATION

As you can see there are many different criteria about what is "better".

On the other hand, I also agree that sometimes dealing with keybindings
is a problem ( ex: C-i, C-?, C-: ) for that reason many new users use
evil mode more and more (in spite of the modes changes designs are
annoying and non intuitive).

The extension of evil mode was, in fact, one of the reasons why I made
some of the initial questions when started this thread. To ease the
initial experience for new times, new users, new standards. Because it
is possible in emacs... but after a lot of configuration.

A good point in favor is that Emacs keybindings are the one by default
in bash and many gui applications because the alternative is to make
everything modal.

> 
> > > I have menu and toolbar disabled ...

The menu and tool bar are in fact examples of the emacs adaptations to
changes. Hardcore users disable them because they want a clean
screen... or a vim like experience. But it is there for a reason,
specially when it is a new user.

In a gui interaction problems with keybinds are avoided in part because
no terminal filters the commands you sent to emacs and because the
options are available with the mouse and the menus.

I use emacs always in the terminal because of my work and the better or
worse behavior strongly depends if I am using xterm, gnome-terminal or
termite... but that's not an emacs issue. (For example binding C-i was a
harder task to what I expected, and I only could do it with xterm). Make
everything gui and terminal compatible with everything new and backward
compatible is very difficult, specially after 30 years.

> > 
> > Complaining about navigability and discoverability of an interface
> > while having disabled its most discoverable features meant to guide
> > new users is a strange combination.
> 
> I'm pointing out a usability issue and you call it complaining.  That
> must be the right attitude.
> 
> Fine, I'll give vim a try.
> 
OK, if you just want an editor, you don't plan to extend it or
personalize..., just follow the editor's rules, you can deal with the
mode changes constantly... go for it, it is a good editor, but only
that, an editor.

Then try to change any default keybinding in vim design.... propose
that... good look...

I came from there a long time ago. They are still with hjkl as
arrows. And using the real arrows is a kind of capital sin with no
serious arguments...

> 
> PS: I tried vim in the meantime, and I'll probably switch.
> 
You are free :)

> > > Basically, I want to use the Emacs server the usual way how you
> > > use any server, like a web server or an ssh server or an XMPP
> > > server.
> > 
> > Or an X server, which is attached to the hardware that faces the
> > user?  There's more than one way to think of the word.
> 
> I don't want it to use like an X server, and there are always many
> ways to think of all words.
> 

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 29 Aug 2018 22:52:40 +0200
> 
> The whole section about the --tramp-prefix= option confused me.

It has an example, which should have cleared up things.  However, I'm
not yet convinced that option is for your use case, because I don't
yet understand your use case well enough.

> I have menu and toolbar disabled ...

Unless you loathe the mouse, C-mouse-3 will pop up the same menu as
the one that would have been available from the menu bar.

> I ended up getting stuck in the help documentation of info and
> actually had to kill the buffer to be able to start over because I
> couldn't get anywhere else from there.

Typing 'q' (for "quit") would have been a better and easier way out.
But there's nothing wrong with killing the Info buffer, either.

> >> And what file is there to access when I want an X frame?
> >
> > When you invoke emacsclient, you usually ask it to visit a file,
> > right?
> 
> Wrong; the files are usually already loaded, either because Emacs keeps
> running on the server, or because desktop-mode has already restored
> them.

That's irrelevant, because eventually you'd want to access files.
That's what Emacs is for, right?

> I'd like to use the Emacs server that runs remotely on the server from
> my workstation with an emacsclient running locally on the workstation
> directly without X11 forwarding via ssh for the frames, and I'd like to
> be able to also use 'emacsclient -nw' on the workstation, using the
> emacs server on the server.

Is this a single use case or two separate ones?

Assuming they are separate: for the first one, is using the -dDISPLAY
option (without any client) what you want?  And for the second, did
you try using server-use-tcp?

> I understand that the Emacs server can not open the virtual terminal
> when using 'emacsclient -nw' because from its perspective, that is a
> remote file.

I'm afraid I don't understand why you need to run "emacsclient -nw" on
another machine.  Why not remotely login and run emacsclient there?

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
>> Date: Wed, 29 Aug 2018 22:52:40 +0200
>> 
>> The whole section about the --tramp-prefix= option confused me.
>
> It has an example, which should have cleared up things.  However, I'm
> not yet convinced that option is for your use case, because I don't
> yet understand your use case well enough.

I'm not sure, either.

>> I have menu and toolbar disabled ...
>
> Unless you loathe the mouse, C-mouse-3 will pop up the same menu as
> the one that would have been available from the menu bar.

I usually use (toggle-menu-bar-mode-from-frame).  In this case, I simply
didn't think of turning on the menu, or of using it.

>> I ended up getting stuck in the help documentation of info and
>> actually had to kill the buffer to be able to start over because I
>> couldn't get anywhere else from there.
>
> Typing 'q' (for "quit") would have been a better and easier way out.
> But there's nothing wrong with killing the Info buffer, either.

I tried that.  When you run (info) again, you're back at the same help
page.  'q' does not actually quit such buffers.

>> >> And what file is there to access when I want an X frame?
>> >
>> > When you invoke emacsclient, you usually ask it to visit a file,
>> > right?
>> 
>> Wrong; the files are usually already loaded, either because Emacs keeps
>> running on the server, or because desktop-mode has already restored
>> them.
>
> That's irrelevant, because eventually you'd want to access files.
> That's what Emacs is for, right?

Sure, and it may not be irrelevant.  Visiting a file is different from
not visiting one.

>> I'd like to use the Emacs server that runs remotely on the server from
>> my workstation with an emacsclient running locally on the workstation
>> directly without X11 forwarding via ssh for the frames, and I'd like to
>> be able to also use 'emacsclient -nw' on the workstation, using the
>> emacs server on the server.
>
> Is this a single use case or two separate ones?

I guess it is two variants of the same case: using the terminal in one
and an X frame in the other variant.  It would be the same case because
in any case, I'm trying to use emacsclient with a remote Emacs server.

> Assuming they are separate: for the first one, is using the -dDISPLAY
> option (without any client) what you want?  And for the second, did
> you try using server-use-tcp?

I tried both.  Without the -d option, emacs and emacsclient both seem to
ignore the DISPLAY variable, and only with -d, they try to use the
display they should use.

>> I understand that the Emacs server can not open the virtual terminal
>> when using 'emacsclient -nw' because from its perspective, that is a
>> remote file.
>
> I'm afraid I don't understand why you need to run "emacsclient -nw" on
> another machine.  Why not remotely login and run emacsclient there?

That's because I want to use emacsclient with a remote Emacs server and
because I would have to log in to run emacsclient on the server.  I
wouldn't be able to use Emacs in an X frame, either, unless I'd switch
the monitor over to the server and run an X server there.  If I wanted
to do that, I'd need to put a dedicated graphics card into the server to
get a decent picture, and I don't want to do that because then the
server would consume more electricity (about 1.5 times as much).  I also
would have to use a keyboard that is connected to the server and end up
with two keyboards on my desk, which doesn't fit very well.

Why would I want to run the emacsclient on the same machine as the Emacs
server?  I tried that, and the only advantage was that I could use it to
visit files in an already running Emacs session from the command line.
Other than that, there were no advantages but disadvantages.

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 31 Aug 2018 02:40:30 +0200
> 
> > Assuming they are separate: for the first one, is using the -dDISPLAY
> > option (without any client) what you want?  And for the second, did
> > you try using server-use-tcp?
> 
> I tried both.  Without the -d option, emacs and emacsclient both seem to
> ignore the DISPLAY variable, and only with -d, they try to use the
> display they should use.

I think this is expected behavior.  Does it solve your use case?  If
not, why not?

> >> I understand that the Emacs server can not open the virtual terminal
> >> when using 'emacsclient -nw' because from its perspective, that is a
> >> remote file.
> >
> > I'm afraid I don't understand why you need to run "emacsclient -nw" on
> > another machine.  Why not remotely login and run emacsclient there?
> 
> That's because I want to use emacsclient with a remote Emacs server and
> because I would have to log in to run emacsclient on the server.  I
> wouldn't be able to use Emacs in an X frame, either, unless I'd switch
> the monitor over to the server and run an X server there.

You explicitly mentioned -nw, so how is X frame relevant here?

> Why would I want to run the emacsclient on the same machine as the Emacs
> server?

Why do you want to run emacsclient at all?  IOW, I still don't
understand what is it that you are trying to accomplish.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 31 Aug 2018 02:40:30 +0200
>> 
>> > Assuming they are separate: for the first one, is using the -dDISPLAY
>> > option (without any client) what you want?  And for the second, did
>> > you try using server-use-tcp?
>> 
>> I tried both.  Without the -d option, emacs and emacsclient both seem to
>> ignore the DISPLAY variable, and only with -d, they try to use the
>> display they should use.
>
> I think this is expected behavior.  Does it solve your use case?  If
> not, why not?

I would call it an unusual way of specifying the display to use.
Everything else seems to refer to the DISPLAY environment variable.

I can't tell if it would solve the problem because I haven't tried all
the options yet.  I usually don't run the X server listening to the
network, and I usually do not restart it.  I also do not know if the X
server needs to listen to the network to be able to use a remote Emacs
server --- after all, the client runs locally and should be able to use
the X server without it listening to the network.

>> >> I understand that the Emacs server can not open the virtual terminal
>> >> when using 'emacsclient -nw' because from its perspective, that is a
>> >> remote file.
>> >
>> > I'm afraid I don't understand why you need to run "emacsclient -nw" on
>> > another machine.  Why not remotely login and run emacsclient there?
>> 
>> That's because I want to use emacsclient with a remote Emacs server and
>> because I would have to log in to run emacsclient on the server.  I
>> wouldn't be able to use Emacs in an X frame, either, unless I'd switch
>> the monitor over to the server and run an X server there.
>
> You explicitly mentioned -nw, so how is X frame relevant here?

It is relevent for 'emacsclient -nc'.

>> Why would I want to run the emacsclient on the same machine as the Emacs
>> server?
>
> Why do you want to run emacsclient at all?  IOW, I still don't
> understand what is it that you are trying to accomplish.

I want to be able to use the same Emacs session with multiple different
machines --- currently only two.

Why does anyone run an ssh server?

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 02 Sep 2018 18:27:27 +0200
> 
> > Why do you want to run emacsclient at all?  IOW, I still don't
> > understand what is it that you are trying to accomplish.
> 
> I want to be able to use the same Emacs session with multiple different
> machines --- currently only two.

That's what -dDISPLAY option is about, AFAIK.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
>> Date: Sun, 02 Sep 2018 18:27:27 +0200
>> 
>> > Why do you want to run emacsclient at all?  IOW, I still don't
>> > understand what is it that you are trying to accomplish.
>> 
>> I want to be able to use the same Emacs session with multiple different
>> machines --- currently only two.
>
> That's what -dDISPLAY option is about, AFAIK.

But that would be unsave ...

Using 'ssh -Y' didn't work too well, either.  The Emacs daemon crashed
when it wasn't able to draw the contents of the frames correctly and I
had to close them because they were entirely unresponsive.  So I'm back
to running Emacs locally :/

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 04 Sep 2018 17:43:32 +0200
> 
> >> I want to be able to use the same Emacs session with multiple different
> >> machines --- currently only two.
> >
> > That's what -dDISPLAY option is about, AFAIK.
> 
> But that would be unsave ...
> 
> Using 'ssh -Y' didn't work too well, either.  The Emacs daemon crashed
> when it wasn't able to draw the contents of the frames correctly and I
> had to close them because they were entirely unresponsive.

What makes you think emacsclient will do any better in this scenario?
After all, you still want the Emacs X frame be displayed on the same
machine, and the data be moved over the same network.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  radon.neon@gmail.com,  flexibeast@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 04 Sep 2018 17:43:32 +0200
>> 
>> >> I want to be able to use the same Emacs session with multiple different
>> >> machines --- currently only two.
>> >
>> > That's what -dDISPLAY option is about, AFAIK.
>> 
>> But that would be unsave ...
>> 
>> Using 'ssh -Y' didn't work too well, either.  The Emacs daemon crashed
>> when it wasn't able to draw the contents of the frames correctly and I
>> had to close them because they were entirely unresponsive.
>
> What makes you think emacsclient will do any better in this scenario?

That way, it worked a couple days until it crashed, which was better
than using it directly, which didn't work at all and is unsafe.

> After all, you still want the Emacs X frame be displayed on the same
> machine, and the data be moved over the same network.

X frames could be displayed on both machines (I'm usually not running an
X session on the server, but I could) and would usually be displayed on
the remote machine.

That is what 'ssh -Y' provides; you can set DISPLAY to point to the
remote machine, run the program locally and have everything displayed
remotely --- without the remote X server listening to the network and
the data transfer encrypted, all like magic.

That means you log in to the remote machine with 'ssh -Y', set DISPLAY
and start some program on the remote machine, and the program uses the
local X session like programs running locally do.

Re: Some developement questions

[Radon Rosborough]

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

> How is it relevant whether it takes 50ms more or less to start
> Emacs?

Because I can notice a difference of 50ms in a delay that happens very
frequently. And yes, I restart Emacs very frequently. Easily a dozen
times a day if I am doing active development on my Emacs
configuration, which happens often.

> Is that even within the error margin of the measurements?

Sure, there's some variation (although usually less than 150ms). But
the mean value going down by 50ms is equally valuable regardless of
the variance.

> I just keep Emacs running on my server in a tmux session.

I know that works for you (and many others), but it doesn't work for
me. The reason it doesn't work for me is that I develop very actively
on my Emacs configuration. This means that Emacs needs to be restarted
frequently to avoid outdated configuration from causing problems
(which, yes, can be worked around easily by evaluating code in the
current session -- but it's a lot easier to just restart and wait half
a second, with no thought required).

The Emacs server also has some big usability problems for me (not
bugs, but just things that make me personally prefer not to use it).
Firstly, the mode line highlighting is shared between all sessions,
and doesn't behave in the way one might expect if one is used to
launching Emacs sessions directly. Secondly, it's not easy to share an
Emacs server between graphical and terminal sessions -- so I'd need to
run two servers, and the problem of having Emacs servers with outdated
configuration gets twice as bad.

> you can't keep up with me anyway ;P

Fair enough. My configuration loads and quits a tty frame in 500ms,
whereas emacsclient does the same in only 100ms. For me, the usability
problems of the server are worth 400ms to avoid, since I don't pop in
and out of Emacs to edit different files, only to reload my
configuration.

There's not really any point in arguing about which way is "better".
If you want your Emacs state to be clean in the face of a rapidly
changing configuration, it's better to not use the server. If you
don't care about that, nor are you bothered by any of the problems I
mentioned above, then it's better to use the server. It just depends
on your preferences -- but I want to make it clear that there *are*
reasons that some people don't use the server, and actually do care
about init time.

Best,
Radon

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

Re: Some developement questions

[hw]

Radon Rosborough <radon.neon@gmail.com> writes:

>> How is it relevant whether it takes 50ms more or less to start
>> Emacs?
>
> Because I can notice a difference of 50ms in a delay that happens very
> frequently. And yes, I restart Emacs very frequently. Easily a dozen
> times a day if I am doing active development on my Emacs
> configuration, which happens often.

Are you sure you notice a difference of 0.05 seconds?

Even if, this difference adds up to 0.6 seconds over a day, i. e. over
16 hours, when you start Emacs a dozen times.  That means within a
period of 57600 seconds, you notice a difference of 0.6 seconds, which
is 0.001%.  Seriously?

>> Is that even within the error margin of the measurements?
>
> Sure, there's some variation (although usually less than 150ms). But
> the mean value going down by 50ms is equally valuable regardless of
> the variance.

Are you sure you notice a difference of 0.05 seconds when the variance
is around 0.15 seconds anyway?

>> I just keep Emacs running on my server in a tmux session.
>
> I know that works for you (and many others), but it doesn't work for
> me. The reason it doesn't work for me is that I develop very actively
> on my Emacs configuration. This means that Emacs needs to be restarted
> frequently to avoid outdated configuration from causing problems
> (which, yes, can be worked around easily by evaluating code in the
> current session -- but it's a lot easier to just restart and wait half
> a second, with no thought required).

Ok, keeping it running won't work for you.

> The Emacs server also has some big usability problems for me (not
> bugs, but just things that make me personally prefer not to use it).
> Firstly, the mode line highlighting is shared between all sessions,
> and doesn't behave in the way one might expect if one is used to
> launching Emacs sessions directly.

Oh, I didn't mean the Emacs server; I can just use Emacs in a tmux
session and a terminal, connecting with ssh to the server.

> Secondly, it's not easy to share an Emacs server between graphical and
> terminal sessions -- so I'd need to run two servers, and the problem
> of having Emacs servers with outdated configuration gets twice as bad.

ssh -Y server
emacsclient -nc
emacsclient -nw

How is this difficult?

>> you can't keep up with me anyway ;P
>
> Fair enough. My configuration loads and quits a tty frame in 500ms,
> whereas emacsclient does the same in only 100ms. For me, the usability
> problems of the server are worth 400ms to avoid, since I don't pop in
> and out of Emacs to edit different files, only to reload my
> configuration.

no fair comparison when you can't let it run

How do you even measure such tiny amounts of time?

Re: Some developement questions

[Radon Rosborough]

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

> Are you sure you notice a difference of 0.05 seconds?

Yes, actually. I wouldn't notice a difference of 0.05 seconds in
something that takes 2 seconds to run, but I certainly will in
something that takes 0.5 seconds to run. That's 10%, after all.

There's also the fact that 0.5 seconds is such a short amount of time
that I really can't go and do anything else with my brain while I'm
waiting. So all of my attention remains focused on the task at hand,
namely waiting for Emacs to start. This is another likely explanation
for why I notice such a short time difference.

> Are you sure you notice a difference of 0.05 seconds when the
> variance is around 0.15 seconds anyway?

Yes, in fact, I am.

> I can just use Emacs in a tmux session and a terminal, connecting
> with ssh to the server.

If you are using emacsclient, then I am pretty sure you are using the
Emacs server. The server does not have to be headless -- you can start
it from an otherwise normal Emacs instance.

The Emacs server does not work for my workflow even when I run it on
the same machine that I'm connecting from. Introducing network latency
into the mix would just make things even worse.

> ssh -Y server
> emacsclient -nc
> emacsclient -nw
>
> How is this difficult?

In my experience, my color theme is totally broken when I connect to a
graphical Emacs server with a tty client, although it works fine in
both graphical and tty Emacs instances individually. That is what I
was referring to.

I know of at least one other person who has extensive Emacs experience
who does not know how to work around this problem, so it does not
appear to be trivial.

> no fair comparison when you can't let it run

I am sorry but I do not understand this sentence.

> How do you even measure such tiny amounts of time?

With the time utility supported by most shells.

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

Re: Some developement questions

[Basil L. Contovounesios]

Radon Rosborough <radon.neon@gmail.com> writes:

>> How do you even measure such tiny amounts of time?
>
> With the time utility supported by most shells.

FWIW, there is the command emacs-init-time in lisp/time.el which reports
to 1 d.p. the number of seconds it took load one's init files.

For a different precision, you can perform time arithmetic on
before-init-time and after-init-time yourself.

-- 
Basil

Re: Some developement questions

[Radon Rosborough]

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

> FWIW, there is the command emacs-init-time in lisp/time.el which
> reports to 1 d.p. the number of seconds it took load one's init
> files.

Of course. That is what I use to measure my init-file loading time,
but it's also useful to know how long it really takes when you account
for loading Emacs itself, and all that. For this, I use:

$ time emacs -nw --eval "(kill-emacs)"

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

Re: Some developement questions

[hw]

Radon Rosborough <radon.neon@gmail.com> writes:

>> Are you sure you notice a difference of 0.05 seconds?
>
> Yes, actually. I wouldn't notice a difference of 0.05 seconds in
> something that takes 2 seconds to run, but I certainly will in
> something that takes 0.5 seconds to run. That's 10%, after all.

Still the 10% are a really short time.

> There's also the fact that 0.5 seconds is such a short amount of time
> that I really can't go and do anything else with my brain while I'm
> waiting.

Just think about something else while starting Emacs :)

> [...]
>> I can just use Emacs in a tmux session and a terminal, connecting
>> with ssh to the server.
>
> If you are using emacsclient, then I am pretty sure you are using the
> Emacs server.

yes

> The server does not have to be headless -- you can start it from an
> otherwise normal Emacs instance.

I know, yet I would like to use it remotely.

> [...]
>> ssh -Y server
>> emacsclient -nc
>> emacsclient -nw
>>
>> How is this difficult?
>
> In my experience, my color theme is totally broken when I connect to a
> graphical Emacs server with a tty client, although it works fine in
> both graphical and tty Emacs instances individually. That is what I
> was referring to.

Interesting, I was having the problem that the frames didn't get updated
correctly when creating them, using a remote Emacs server.  Yesterday,
the frame remained unresponsive, so I created another one, but it was
also unresponsive and I destroyed the windows.  When I tried to create
another frame, the Emacs daemon crashed.

> I know of at least one other person who has extensive Emacs experience
> who does not know how to work around this problem, so it does not
> appear to be trivial.

awww

>> no fair comparison when you can't let it run
>
> I am sorry but I do not understand this sentence.

If I could use an Emacs server remotely, the Emacs server would run on
my server which runs all the time.  You can't let Emacs run all the time
because you change the configuration all the time.  There is no fair
comparison of startup times in such a case.

>> How do you even measure such tiny amounts of time?
>
> With the time utility supported by most shells.

Then you still need to exit Emacs to do that, which screws off the
measurements.

Re: Some developement questions

[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. ]]]

  > > If the messages are just printed in the message buffer it shouldn't
  > > impact too much the startup time I think.

  > To do the kind of analysis you are talking about, one would have to
  > hook into really basic subroutines like `setq`.

If the goal is to give warnings when certain variables are set in
.emacs, It might be possible to do an almost complete job of that by
advising setq and a few friends around the loading of .emacs.  People
who want the highest startup speed could turn this off, and completely
avoid the slowdown.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: spacibba@aol.com, hw@adminart.net, eliz@gnu.org,
> 	flexibeast@gmail.com, emacs-devel@gnu.org
> Date: Sun, 26 Aug 2018 16:41:56 -0400
> 
> If the goal is to give warnings when certain variables are set in
> .emacs, It might be possible to do an almost complete job of that by
> advising setq and a few friends around the loading of .emacs.

We have now Lisp watchpoints, which will do that much better and
cleaner.

Re: Some developement questions

[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. ]]]

  > > If the goal is to give warnings when certain variables are set in
  > > .emacs, It might be possible to do an almost complete job of that by
  > > advising setq and a few friends around the loading of .emacs.

  > We have now Lisp watchpoints, which will do that much better and
  > cleaner.

If that works well, it is fine with me.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[Filipp Gunbin]

On 25/08/2018 12:34 +0200, Ergus wrote:

> Newer users will go straight to google/duckduckgo to make the
> questions. Not only because they don't know exactly the name of what
> they are looking for, but also because that's the stackoverflow's
> culture. In the beginning they just want some code to copy and paste
> in the config.

What I read in this thread makes me think that all this applies more to
Spacemacs and other derivatives.  I doubt it makes sense to support in
default Emacs some configuration(s) for ever-changing landscape of
packages/plugins.  Sounds like a job for a derivative's developers.

Re: Some developement questions

[Ergus]

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

Emacs has survived because it has adapted to the times before. Sadly it is not getting enough new/younger users if we compare with vim.

Why promote tje creation of more derivatives if we could have a bigger community and avoid effort duplication, keep control, some order and reduce entropy, keeping standar format for documentation and closer communication and interaction and developement? As well as more potential contributions/contributors/developers?

Spacemacs is pretty good but it has changed the configuration experience too much removing flexibility and some control to the user; thats the only thing to complain about it. It automatizes many things and reqires too many packages and dependencies in the basic state and adding a new package requires to create a pluging with 3 files... That's not the idea and it is not a right way to introduce emacs to newer users(in my oppinion), in spite of the interaction experience is good enough.

Why not just improve the emacs defaults and the first impression? It is basically some ergonomy and marketing. Emacs is and should stay being a software for final users, and not developed as a base for derivatives like a kernel or so. In spite of many derivatives have existed among the years.
Adaptation is the key for surviving.

⁣Sent from BlueMail ​

On 27 Aug 2018, 19:11, at 19:11, Filipp Gunbin <fgunbin@fastmail.fm> wrote:
>On 25/08/2018 12:34 +0200, Ergus wrote:
>
>> Newer users will go straight to google/duckduckgo to make the
>> questions. Not only because they don't know exactly the name of what
>> they are looking for, but also because that's the stackoverflow's
>> culture. In the beginning they just want some code to copy and paste
>> in the config.
>
>What I read in this thread makes me think that all this applies more to
>Spacemacs and other derivatives.  I doubt it makes sense to support in
>default Emacs some configuration(s) for ever-changing landscape of
>packages/plugins.  Sounds like a job for a derivative's developers.

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

Re: Some developement questions

[hw]

Alexis <flexibeast@gmail.com> writes:

> hw <hw@adminart.net> writes:
>
>> Maybe Emacs should give us warnings when it discovers outdated,
>> deprecated or useless settings in ~/.emacs.
>
> i imagine many people might want this; but many people might /not/
> want this if it has a noticeable impact on startup times. Startup
> times don't usually have an impact on me personally, since i run an
> Emacs server at machine startup and connect clients to that. From what
> i've read, however, a number of people find even an extra 0.5s-1.0s in
> startup to be significant when jumping in and out of a non-client
> Emacs instance. So if this feature did have an impact on startup
> times, people would want to be able to enable and disable it at will.

Right, the check is more something that to enabled every know and then
rather something that would need to be done on each start.

How does 0.5--1 second more or less time needed for booting make a
difference?

>> get into documentation hell because it's hard to tell which
>> documentation is up to date
>
> One of the pleasures i find in using Emacs is its extensive
> accompanying documentation, documentation which (in my experience) is
> typically far better maintained than that of many other
> projects[1].

Yes :)  And I learned from this thread that I need to pay more attention
to the documentation.  There is lots I haven't looked at yet, and it
continues to evolve.  I guess it just doesn't come to mind because I'm
so much used to search the internet to find something.

> As someone who has been using Emacs for around 20 years,
> i very much appreciate the comprehensive NEWS file with each release,

There is a NEWS file?

> which allows me to quite quickly ascertain what changes have been made
> that might affect my configuration and workflow (e.g. changed default
> values).
>
> i say this because i'm wondering which area(s) of documentation you're
> having these difficulties with?

It was Ergus who finds this difficult.

> If you're talking about the Emacs Wiki at emacswiki.org, well, as far
> as i'm aware, that's not an official wiki, is it[2]? Nor is
> wikemacs.org. i personally much prefer the latter to the former.

Well, yes, it is what I find when I search, and it doesn't matter if
something is official or not when I need to solve a particular problem
because when the solution is good, what difference does it make?

Documentation that can be found can always be old when the software it
refers to is old.  You always have to wonder if there is something more
recent that makes the old documentation outdated or irrelevant.

Emacs stands out in this because it has not only been around for a long
time but continues to evolve at a relatively fast pace compared to other
software that has also been around for ages.  While old documentation
for other software may still be relevant, old documentation for Emacs
might not be because Emacs has moved on while the other software has
not.

> But i strongly feel that people's first destinations when searching
> for documentation should be the Emacs Manual and the Emacs Lisp
> Reference Manual - only after not being able to locate the information
> in those manuals, making sure to make use their excellent indexes,
> should one consider trying to find information on the two wikis. i
> regularly find myself responding to "How do I do X in Emacs?"
> questions with "Here's the relevant section of the relevant manual."

Perhaps that's because it is so much easier and so much more a habit to
enter some search term into a search engine and to browse the findings
than it is to go through the documentation that comes with Emacs.

> At any rate, one should certainly consider submitting a bug report
> about inadequate or inaccurate documentation for functionality shipped
> with Emacs. Even if no volunteer can immediately address it, at least
> it's recorded as something for potential volunteers to work on.

I continue to be amazed and delighted with how exceptionally responsive
and interested the developers of Emacs are and how much help you can get
when you only ask.  This is just wonderful :)

Making bug reports is worthwhile with Emacs because the developers take
care of them and bugs do get fixed.  All this is something other
projects could learn a lot from.

>> I had auto-complete working (until I disabled it because it got into
>> my way by trying to automatically complete everything when I used
>> Emacs for something I didn't install auto-complete for), installed
>> from a git repo somewhere on github.
>
> Do you literally mean the `auto-complete.el' package and its
> associated `ac-*' packages? Is that still maintained?


cat ~/emacs/auto-complete/.git/config 
[...]
[remote "origin"]
        url = https://github.com/auto-complete/auto-complete.git
[...]


It looks like the last commit was two years ago.  I guess it was still
maintained when I tried it four years ago :)

> i'm using company` as my autocompletion framework, myself. But neither
> is shipped with Emacs, and there's no index entry for `auto-complete'
> or autocomplete' in the Emacs Manual, which probably comes as a
> surprise to the many people who have come to expect autocompletion as
> basic functionality in a programming environment ....

Auto completion is worse than a phone ringing, a notification popping up
on the screen, someone asking you a question and/or wanting you to do
something or people talking in front of your office while you are trying
to program.  Auto completion is worse because these things are temporary
and cause you to loose only anything between 10 minutes and 2 hours
while auto completion interrupts you constantly and thus prevents you
from getting anything programmed at all.

So why would anyone want to torture themselves with auto completion?


Gnus is shipped with Emacs.  Have you ever tried to get it to work?

> i think this is indeed a problem, but unfortunately, i don't have any
> suggestions as to how it might be addressed. :-(

I think if we could make configuration packages that handle all the
dependencies and perhaps deal with alternatives, such packages could be
made for particular use cases.

>
> [1] OpenBSD is probably the other project i think of when thinking of
> excellence in documentation. Comparing `man 4 intro' for the Linux
> kernel vs. `man 4 intro' for the OpenBSD kernel is eye-opening.

I never looked at either ...

"Section 4 of the manual describes special files (devices)."

You must have different manpages.

> [2] i have the impression that many people assume it /is/ an official
> Emacs wiki, so if its not, this fact might need to be somehow
> emphasised or made more clear.

Is there another one?  Maybe it also needs to point to the documentation
that comes with Emacs and tell people to always lock there to verify the
information in the wiki.  But then, do I need to learn elisp before I
could have a function like (goto-matching-fence) because I'm supposed to
verify that it is not out of date?

Perhaps nowadays, a wiki is the way to go because it suits the way how
people find information.  Long ago, we were reading the documentation
that came packaged with the software because we didn't have the kind of
internet access we now have.  Nowadays, we wish that documentation came
with the software like it used to.

Would it be possible to convert the documentation that comes with Emacs
into a wiki?

Re: Some developement questions

[Ergus]

On Sun, Aug 26, 2018 at 03:06:35PM +0200, hw wrote:
>Alexis <flexibeast@gmail.com> writes:
>
>> hw <hw@adminart.net> writes:
>>
>>> Maybe Emacs should give us warnings when it discovers outdated,
>>> deprecated or useless settings in ~/.emacs.
>>
>> i imagine many people might want this; but many people might /not/
>> want this if it has a noticeable impact on startup times. Startup
>> times don't usually have an impact on me personally, since i run an
>> Emacs server at machine startup and connect clients to that. From what
>> i've read, however, a number of people find even an extra 0.5s-1.0s in
>> startup to be significant when jumping in and out of a non-client
>> Emacs instance. So if this feature did have an impact on startup
>> times, people would want to be able to enable and disable it at will.
>
>Right, the check is more something that to enabled every know and then
>rather something that would need to be done on each start.
>
>How does 0.5--1 second more or less time needed for booting make a
>difference?
>
>>> get into documentation hell because it's hard to tell which
>>> documentation is up to date
>>
>> One of the pleasures i find in using Emacs is its extensive
>> accompanying documentation, documentation which (in my experience) is
>> typically far better maintained than that of many other
>> projects[1].
>
>Yes :)  And I learned from this thread that I need to pay more attention
>to the documentation.  There is lots I haven't looked at yet, and it
>continues to evolve.  I guess it just doesn't come to mind because I'm
>so much used to search the internet to find something.
>
>> As someone who has been using Emacs for around 20 years,
>> i very much appreciate the comprehensive NEWS file with each release,
>
>There is a NEWS file?

Yes, I usually look for it, but online :p  
>
>> which allows me to quite quickly ascertain what changes have been made
>> that might affect my configuration and workflow (e.g. changed default
>> values).
>>
>> i say this because i'm wondering which area(s) of documentation you're
>> having these difficulties with?
>
>It was Ergus who finds this difficult.

When I started yes, it was difficult. Mainly because the names, the
terms and all the environment were all new and very different of
everything else I used before. Some keybindings in the documentations
didn't work because they were conflicting with the gnome-terminal ones
(as I was using ssh connections with no tramp). There was not redo in
the usual way (still very confusing for me). And many configurations and
help I found in the web was in Lisp which is also very different from
python, C, Ruby, Fortran...


>
>> If you're talking about the Emacs Wiki at emacswiki.org, well, as far
>> as i'm aware, that's not an official wiki, is it[2]? Nor is
>> wikemacs.org. i personally much prefer the latter to the former.
>
>Well, yes, it is what I find when I search, and it doesn't matter if
>something is official or not when I need to solve a particular problem
>because when the solution is good, what difference does it make?
>
>Documentation that can be found can always be old when the software it
>refers to is old.  You always have to wonder if there is something more
>recent that makes the old documentation outdated or irrelevant.
>
>Emacs stands out in this because it has not only been around for a long
>time but continues to evolve at a relatively fast pace compared to other
>software that has also been around for ages.  While old documentation
>for other software may still be relevant, old documentation for Emacs
>might not be because Emacs has moved on while the other software has
>not.
>
>> But i strongly feel that people's first destinations when searching
>> for documentation should be the Emacs Manual and the Emacs Lisp
>> Reference Manual - only after not being able to locate the information
>> in those manuals, making sure to make use their excellent indexes,
>> should one consider trying to find information on the two wikis. i
>> regularly find myself responding to "How do I do X in Emacs?"
>> questions with "Here's the relevant section of the relevant manual."
>
>Perhaps that's because it is so much easier and so much more a habit to
>enter some search term into a search engine and to browse the findings
>than it is to go through the documentation that comes with Emacs.
>
>> At any rate, one should certainly consider submitting a bug report
>> about inadequate or inaccurate documentation for functionality shipped
>> with Emacs. Even if no volunteer can immediately address it, at least
>> it's recorded as something for potential volunteers to work on.
>
>I continue to be amazed and delighted with how exceptionally responsive
>and interested the developers of Emacs are and how much help you can get
>when you only ask.  This is just wonderful :)
>
>Making bug reports is worthwhile with Emacs because the developers take
>care of them and bugs do get fixed.  All this is something other
>projects could learn a lot from.
>
>>> I had auto-complete working (until I disabled it because it got into
>>> my way by trying to automatically complete everything when I used
>>> Emacs for something I didn't install auto-complete for), installed
>>> from a git repo somewhere on github.
>>
>> Do you literally mean the `auto-complete.el' package and its
>> associated `ac-*' packages? Is that still maintained?
>
>
>cat ~/emacs/auto-complete/.git/config
>[...]
>[remote "origin"]
>        url = https://github.com/auto-complete/auto-complete.git
>[...]
>
>
>It looks like the last commit was two years ago.  I guess it was still
>maintained when I tried it four years ago :)
>
>> i'm using company` as my autocompletion framework, myself. But neither
>> is shipped with Emacs, and there's no index entry for `auto-complete'
>> or autocomplete' in the Emacs Manual, which probably comes as a
>> surprise to the many people who have come to expect autocompletion as
>> basic functionality in a programming environment ....
>
>Auto completion is worse than a phone ringing, a notification popping up
>on the screen, someone asking you a question and/or wanting you to do
>something or people talking in front of your office while you are trying
>to program.  Auto completion is worse because these things are temporary
>and cause you to loose only anything between 10 minutes and 2 hours
>while auto completion interrupts you constantly and thus prevents you
>from getting anything programmed at all.
>
>So why would anyone want to torture themselves with auto completion?
>

Because they look for: "auto completion emacs" and that's the result
they get. So the experience is bad and they move to sublime because
emacs completion was bad.


>
>Gnus is shipped with Emacs.  Have you ever tried to get it to work?
>
I tried but it didn't work for me, and in spite there are alternatives like mu4e the documentation directs you to gnus.

>> i think this is indeed a problem, but unfortunately, i don't have any
>> suggestions as to how it might be addressed. :-(
>
>I think if we could make configuration packages that handle all the
>dependencies and perhaps deal with alternatives, such packages could be
>made for particular use cases.
>
>>
>> [1] OpenBSD is probably the other project i think of when thinking of
>> excellence in documentation. Comparing `man 4 intro' for the Linux
>> kernel vs. `man 4 intro' for the OpenBSD kernel is eye-opening.
>
>I never looked at either ...
>
>"Section 4 of the manual describes special files (devices)."
>
>You must have different manpages.
>
>> [2] i have the impression that many people assume it /is/ an official
>> Emacs wiki, so if its not, this fact might need to be somehow
>> emphasised or made more clear.
>
>Is there another one?  Maybe it also needs to point to the documentation
>that comes with Emacs and tell people to always lock there to verify the
>information in the wiki.  But then, do I need to learn elisp before I
>could have a function like (goto-matching-fence) because I'm supposed to
>verify that it is not out of date?
>
>Perhaps nowadays, a wiki is the way to go because it suits the way how
>people find information.  Long ago, we were reading the documentation
>that came packaged with the software because we didn't have the kind of
>internet access we now have.  Nowadays, we wish that documentation came
>with the software like it used to.
>
>Would it be possible to convert the documentation that comes with Emacs
>into a wiki?
>
>
+1 to this.

And a foro where the users can interact dynamically, and give answers
each other, so all the support does not fall on the emacs developers,
but the users can help each other. I told before: a mailing list is so
1998.

We need some feedback from the users if we want more/newer users.

Vim made like a features claim page where the users report what they
want to see in the next releases, and they vote for them. So the
developers with a simple look knows what is coming next

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Sat, 25 Aug 2018 03:31:18 +0200
> 
> >> (setq Man-width 75)
> >
> > Emacs nowadays calculates the width dynamically, depending on the
> > dimensions of the window.
> 
> Why not make Emacs dynamically size it's windows to the width of the
> display first? ;~O
> 
> <Rant>
> 
> Yes, Emacs can do that since a while, and has made it an extremely
> annoying default.  Who wants to read manual pages or other text when it
> has been formatted to be about 140--300 characters per line wide (and
> way more than that if my eyes were what they used to be)?
> [...]
> This is a good example for a default that really should be changed.

Feel free to file a bug report about it.

> Think of what Ergus pointed out in his last post[1] about the
> difficulties users and Emacs are experiencing:
> 
> 
> + find out about Emacs
> + install Emacs
> + find out about package manager of Emacs
> + configure package manager, add repos
> + somehow get an idea of what packages to install
> + get into dependency hell and alternatives hell
> + get into documentation hell because it's hard to tell which
>   documentation is up to date
> + get nothing to work

I agree that practical steps towards helping new users is something
that are very welcome.

Re: Some developement questions

[Noam Postavsky]

On 25 August 2018 at 04:19, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Sat, 25 Aug 2018 03:31:18 +0200
>>
>> >> (setq Man-width 75)
>> >
>> > Emacs nowadays calculates the width dynamically, depending on the
>> > dimensions of the window.
>>
>> Why not make Emacs dynamically size it's windows to the width of the
>> display first? ;~O
>>
>> <Rant>
>>
>> Yes, Emacs can do that since a while, and has made it an extremely
>> annoying default.  Who wants to read manual pages or other text when it
>> has been formatted to be about 140--300 characters per line wide (and
>> way more than that if my eyes were what they used to be)?
>> [...]
>> This is a good example for a default that really should be changed.
>
> Feel free to file a bug report about it.

See also Bug#9385.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9385

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Sat, 25 Aug 2018 03:31:18 +0200
>> 
>> >> (setq Man-width 75)
>> >
>> > Emacs nowadays calculates the width dynamically, depending on the
>> > dimensions of the window.
>> 
>> Why not make Emacs dynamically size it's windows to the width of the
>> display first? ;~O
>> 
>> <Rant>
>> 
>> Yes, Emacs can do that since a while, and has made it an extremely
>> annoying default.  Who wants to read manual pages or other text when it
>> has been formatted to be about 140--300 characters per line wide (and
>> way more than that if my eyes were what they used to be)?
>> [...]
>> This is a good example for a default that really should be changed.
>
> Feel free to file a bug report about it.

Hm, ok, I did that (no response yet).  Let's see what happens.

>> Think of what Ergus pointed out in his last post[1] about the
>> difficulties users and Emacs are experiencing:
> [...]
>> + get nothing to work
>
> I agree that practical steps towards helping new users is something
> that are very welcome.

How about getting new users in the first place?  Ergus is right that
Emacs is not the default editor --- I always have to explicitly install
it and it always annoys me that it isn't installed by default for any of
Centos, Debian, Gentoo, Fedora.  Ubuntu and arch probably don't have a
good default, either.  Instead, you always need to guess which editor
might be installed unless you installed one, and that is usually at
least vi, which I don't get along with.

I wouldn't know how to sway who ever decides what is being installed by
default in any of these distributions to make Emacs a default.  One
reason for it not to be the default may be that it makes for somewhat
large packages maybe.  It is questionable if that should still be a
concern nowadays.

Imagine that, it may even be the only reason.  And it remains that way
only because nobody thought about it yet.

Re: Some developement questions

[Stefan Monnier]

> How about getting new users in the first place?  Ergus is right that
> Emacs is not the default editor --- I always have to explicitly install
> it and it always annoys me that it isn't installed by default for any of
> Centos, Debian, Gentoo, Fedora.  Ubuntu and arch probably don't have a
> good default, either.  Instead, you always need to guess which editor
> might be installed unless you installed one, and that is usually at
> least vi, which I don't get along with.

AFAIK even `vi` is not installed by default.
IOW, by default, there is basically no text editor installed.  And while
I also find it annoying I think it makes a lot of sense: the majority of
computer users don't even know what is a text editor, nor would they
know what to do with one.


        Stefan

Re: Some developement questions

[hw]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> How about getting new users in the first place?  Ergus is right that
>> Emacs is not the default editor --- I always have to explicitly install
>> it and it always annoys me that it isn't installed by default for any of
>> Centos, Debian, Gentoo, Fedora.  Ubuntu and arch probably don't have a
>> good default, either.  Instead, you always need to guess which editor
>> might be installed unless you installed one, and that is usually at
>> least vi, which I don't get along with.
>
> AFAIK even `vi` is not installed by default.

It seems to be in Fedora.  Debian uses nano; I don't know if vi is still
installed along with it.

> IOW, by default, there is basically no text editor installed.  And while
> I also find it annoying I think it makes a lot of sense: the majority of
> computer users don't even know what is a text editor, nor would they
> know what to do with one.

There isn't really much to do with a computer without an editor.  That
is how the majority of people doesn't know what they can do with a
computer, and how they can not be called "users".

So it doesn't make sense not to install an editor by default.  Someone
might find it and learn and eventually evolve into a user.

Re: Some developement questions

[Ergus]

On Sun, Aug 26, 2018 at 05:52:14PM +0200, hw wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: hw <hw@adminart.net>
>>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>>> Date: Sat, 25 Aug 2018 03:31:18 +0200
>>>
>>> >> (setq Man-width 75)
>>> >
>>> > Emacs nowadays calculates the width dynamically, depending on the
>>> > dimensions of the window.
>>>
>>> Why not make Emacs dynamically size it's windows to the width of the
>>> display first? ;~O
>>>
>>> <Rant>
>>>
>>> Yes, Emacs can do that since a while, and has made it an extremely
>>> annoying default.  Who wants to read manual pages or other text when it
>>> has been formatted to be about 140--300 characters per line wide (and
>>> way more than that if my eyes were what they used to be)?
>>> [...]
>>> This is a good example for a default that really should be changed.
>>
>> Feel free to file a bug report about it.
>
>Hm, ok, I did that (no response yet).  Let's see what happens.
>
>>> Think of what Ergus pointed out in his last post[1] about the
>>> difficulties users and Emacs are experiencing:
>> [...]
>>> + get nothing to work
>>
>> I agree that practical steps towards helping new users is something
>> that are very welcome.
>
use-packages can make the life much more easier handling dependencies in
a way that it is not so esoteric to understand the configuration. I
can't understand why melpa/elpa configuration is not default in
emacs. Same for use-package. So new users can find no so cumbersome
adding a new package in the documentation, as well as migration between
machines.

I thing there should be also an emacs tutorial centered only in text
editing, because the basic tutorial is too simple in that field. The
vim's tutorial is all about editing (obviously), but it gives a lot of
hints and keybinds to move/edit faster or associate keys with
actions. There are some keybinds in emacs that I discovered almost by
accident, same with some commands which names are a bit tricky.

>How about getting new users in the first place?  Ergus is right that
>Emacs is not the default editor --- I always have to explicitly install
>it and it always annoys me that it isn't installed by default for any of
>Centos, Debian, Gentoo, Fedora.  Ubuntu and arch probably don't have a
>good default, either.

Ubuntu has vim, nano, ed and all the others, but nor emacs. Arch on the
other hand has nothing by default, but manjaro also has vim in all it's
flavors.

>Instead, you always need to guess which editor
>might be installed unless you installed one, and that is usually at
>least vi, which I don't get along with.
>

>I wouldn't know how to sway who ever decides what is being installed by
>default in any of these distributions to make Emacs a default.  One
>reason for it not to be the default may be that it makes for somewhat
>large packages maybe.  It is questionable if that should still be a
>concern nowadays.
>

I am relatively new in this, but in general if we ask to the people who
maintains those distributions it will be not a big issue to include
emacs in the defaults packages in the future, the restrictions came from
the times when they where restricted to 700Mb for the distros. But I
think that we must make some changes for the first impression
first. Talking to gnome, kde or the other is something doable too.

Vim for example provides a vimrc personalized per distributions to
integrate itself better in the environment.

>Imagine that, it may even be the only reason.  And it remains that way
>only because nobody thought about it yet.
>

Probably that's it. But we could change that with a couple of arguments and emails.

This is also an indication that most of the maintainers in these projects are
using vim (or something else) and not emacs.

Re: Some developement questions

[Eli Zaretskii]

> Date: Mon, 27 Aug 2018 03:54:22 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> I thing there should be also an emacs tutorial centered only in text
> editing, because the basic tutorial is too simple in that field.

If someone would like to write such a tutorial, and does a good job,
I'm sure it will be welcome.

Re: Some developement questions

[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 thing there should be also an emacs tutorial centered only in text
  > > editing, because the basic tutorial is too simple in that field.

  > If someone would like to write such a tutorial, and does a good job,
  > I'm sure it will be welcome.

My idea was that after you get through the tutorial, you can read the
manual.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 27 Aug 2018 03:54:22 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> 
>> I thing there should be also an emacs tutorial centered only in text
>> editing, because the basic tutorial is too simple in that field.
>
> If someone would like to write such a tutorial, and does a good job,
> I'm sure it will be welcome.

I did write a new tutorial which was designed for to come from the
perspective of a new user of today.

My hope was to do something a bit more intelligent with it -- with some
screen shots and rich text, as well as highlighting for menu items, so I
wrote it in org-mode. Alas I haven't had the time to actually integrate
it into Emacs.

https://raw.githubusercontent.com/phillord/emacs-tutorial/master/tutorial.org

If someone has the time to do the integration it's nearly ready to
go. To my mind, updating the tutorial would be a good thing just because
it would give the impression that it is updateable, rather than a thing
set in stone.

Phil

Re: Some developement questions

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Ergus <spacibba@aol.com>,  hw@adminart.net,  emacs-devel@gnu.org
> Date: Wed, 29 Aug 2018 16:39:49 +0100
> 
> >> I thing there should be also an emacs tutorial centered only in text
> >> editing, because the basic tutorial is too simple in that field.
> >
> > If someone would like to write such a tutorial, and does a good job,
> > I'm sure it will be welcome.
> 
> I did write a new tutorial which was designed for to come from the
> perspective of a new user of today.
> 
> My hope was to do something a bit more intelligent with it -- with some
> screen shots and rich text, as well as highlighting for menu items, so I
> wrote it in org-mode. Alas I haven't had the time to actually integrate
> it into Emacs.
> 
> https://raw.githubusercontent.com/phillord/emacs-tutorial/master/tutorial.org
> 
> If someone has the time to do the integration it's nearly ready to
> go. To my mind, updating the tutorial would be a good thing just because
> it would give the impression that it is updateable, rather than a thing
> set in stone.

Thanks.  That tutorial looks like a somewhat expanded version of our
TUTORIAL; e.g., it has almost the same scope in terms of Emacs
features.  I thought, perhaps mistakenly, that we were talking about a
tutorial for the next step -- for those who have read the original
TUTORIAL and want to learn about more advanced issues related to text
editing.

Re: Some developement questions

[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 existing TUTORIAL file is designed so that you try out the commands
while editing TUTORIAL itself.

I get the impression that the proposed new tutorial doesn't do that.

What are the intended advantages of the new one?
-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[Ergus]

I find the new one a little bit more simple, very basic, but some
details are updated in a less technical language. It assumes that for
new users coming from windows, vim, sublime, Visual Studio...; Emacs
will be a more different (hard maybe) experience than what they expect
and are used to. (For example coping with C-c, C-v, and having an undo
and a redo option is an absolute standard thing today and it is still
different in emacs; also nobody uses the words yank, kill, reinsert
anymore, the people looks for how to cut, copy and paste)

The actual tutorial is fine, but in my modest opinion I would like to
suggest some pedagogical changes like divide it by numbered lessons, put
numbers to the tasks, add summaries per lesson, some aesthetic
horizontal lines... Please, give a look for example to the vimtutor. It
has a very good approach in this aspects.

Respecting to content maybe some details about using overwrite-mode
(using the Insert key of course), moving/copping/switching
lines/words/letters, interactive replace (M-%) shell commands (M-| and
M-! and in-place insertion), insert-buffer/file and equivalent
commands. Practical examples about killing N words or N lines and paste
them somewhere else. Goto line is also important on the beginning.

In i think that the emacs tutorial should explain at least the same
points than vimtutor respecting to text edition because that's the first
thing the user expects to do in emacs. If some edition actions in the
vimtutor are not possible or very complex to do in emacs maybe we need
to consider how to add them in a simpler way because they are very basic
(for example copy the current line requires C-a C-SPC C-e M-w). These
details are more important and basic for a new user than recursive
editing modes or talking about multiple frames/windows in the first day.

We should also mention there helpful things like which-key, ido-mode, linum which makes our lives easier.

Does it makes sense?

On Sat, Sep 01, 2018 at 11:11:48PM -0400, 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. ]]]
>
>The existing TUTORIAL file is designed so that you try out the commands
>while editing TUTORIAL itself.
>
>I get the impression that the proposed new tutorial doesn't do that.
>
>What are the intended advantages of the new one?
>-- 
>Dr Richard Stallman
>President, Free Software Foundation (https://gnu.org, https://fsf.org)
>Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>

Re: Some developement questions

[Phillip Lord]

Ergus <spacibba@aol.com> writes:

> I find the new one a little bit more simple, very basic, but some
> details are updated in a less technical language. It assumes that for
> new users coming from windows, vim, sublime, Visual Studio...; Emacs
> will be a more different (hard maybe) experience than what they expect
> and are used to.

Yep, I started off my assuming modern terminology, then associated the
Emacs terminology with it. I think that this is important.

> The actual tutorial is fine, but in my modest opinion I would like to
> suggest some pedagogical changes like divide it by numbered lessons, put
> numbers to the tasks, add summaries per lesson, some aesthetic
> horizontal lines... Please, give a look for example to the vimtutor. It
> has a very good approach in this aspects.

All of this would make sense. In the end, my thought was to write the
tutorial in org, then generate it either to info or to HTML, maybe
pimping up EWW a bit to handle things better. Numbering would become
automatic then.

> Respecting to content maybe some details about using overwrite-mode
> (using the Insert key of course),

This is the kind of thing that I would rather not do. Overwrite-mode is
just the implementation detail of how Emacs achieves overwriting is a
standard function of most applications.


> moving/copping/switching lines/words/letters, interactive replace
> (M-%) shell commands (M-| and M-! and in-place insertion),
> insert-buffer/file and equivalent commands. Practical examples about
> killing N words or N lines and paste them somewhere else. Goto line is
> also important on the beginning.
>
> In i think that the emacs tutorial should explain at least the same
> points than vimtutor respecting to text edition because that's the first
> thing the user expects to do in emacs. If some edition actions in the
> vimtutor are not possible or very complex to do in emacs maybe we need
> to consider how to add them in a simpler way because they are very basic
> (for example copy the current line requires C-a C-SPC C-e M-w). These
> details are more important and basic for a new user than recursive
> editing modes or talking about multiple frames/windows in the first day.
>
> We should also mention there helpful things like which-key, ido-mode,
> linum which makes our lives easier.

Yeah. The reason that I finish off with installing packages is that I
think as branching tutorial would be the right thing to do, extending
from ELPA.

Phil

Re: Some developement questions

[Phillip Lord]

Richard Stallman <rms@gnu.org> writes:

> The existing TUTORIAL file is designed so that you try out the commands
> while editing TUTORIAL itself.
>
> I get the impression that the proposed new tutorial doesn't do that.
>
> What are the intended advantages of the new one?

Yeah. Most of that stuff is "move cursor back and forward". It's too
slow for most new users and freaks them out. While it was well intended
at the time, I think, it is now a negative feature of the tutorial.

I would like to add automation which would work better. So where it says
"create a new frame", it would be nice to have a click button which
actually does this for you.

The advantage of dumping the "you can edit this file" stuff is that a)
the code gets much simpler, because you don't have to store the users
copy and b) we should be able to use some rich text visualisation to put
images, screenshots as well as the clickable buttons described in the
last paragraph.

At the moment, I have done none of this more intelligent stuff however.

Phil

Re: Some developement questions

[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. ]]]

  > Yeah. Most of that stuff is "move cursor back and forward". It's too
  > slow for most new users and freaks them out. While it was well intended
  > at the time, I think, it is now a negative feature of the tutorial.

Users need to learn these commands in order to edit _efficiently_ with
Emacs.  But maybe most beginners will not aim to edit _efficiently_
and it is ok not to teach them this.

  > I would like to add automation which would work better. So where it says
  > "create a new frame", it would be nice to have a click button which
  > actually does this for you.

I don't follow.  Concretely, what do you propose, and what is good about it?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[hw]

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. ]]]
>
>   > Yeah. Most of that stuff is "move cursor back and forward". It's too
>   > slow for most new users and freaks them out. While it was well intended
>   > at the time, I think, it is now a negative feature of the tutorial.
>
> Users need to learn these commands in order to edit _efficiently_ with
> Emacs.

Why can they not edit efficiently with Emacs without learning the
movement keys described in the tutorial?

Keyboards have changed over the years, and using some of these movement
keys would make editing very inefficient because they are rather
difficult to press on nowadays` keyboards.  The effect of having to
re-learn, which may diminish the efficiency of editing, is also
something to consider.

There is much more to learn about Emacs than key bindings for cursor
movement, and the movement keys in the tutorial may be amongst the least
relevant things that help efficient editing.  An email and a C source
require different things to make their editing more efficient, hence
Emacs has a C-mode and a Message-mode one might need to learn about,
each with their own key bindings.

> But maybe most beginners will not aim to edit _efficiently_
> and it is ok not to teach them this.

With very few exceptions, people always do what they want without
worrying about efficiency.

A beginner learning about Emacs striving for the best efficiency of
editing could easily be the most unlikely case --- and/or figure that
using the cursor keys is more efficient than using key combinations that
are difficult to press and hard to remember.

>   > I would like to add automation which would work better. So where it says
>   > "create a new frame", it would be nice to have a click button which
>   > actually does this for you.
>
> I don't follow.  Concretely, what do you propose, and what is good about it?

I haven't read it all yet.  It starts with telling the reader what Emacs
is and gives some history, and that seems to be a good starting point.

It might make sense to have many tutorials for different topics, like
"what are key bindings", "important key bindings", "movement keys
specific to Emacs", "what are modes", "how to edit XXX efficiently" ...

Re: Some developement questions

[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. ]]]

  > Why can they not edit efficiently with Emacs without learning the
  > movement keys described in the tutorial?

What alternative would be better?  Arrow keys require moving your hands
away from the center.  Moving the graphical pointer, even more so.

  > There is much more to learn about Emacs than key bindings for cursor
  > movement, and the movement keys in the tutorial may be amongst the least
  > relevant things that help efficient editing.

Please give more detail.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[hw]

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. ]]]
>
>   > Why can they not edit efficiently with Emacs without learning the
>   > movement keys described in the tutorial?
>
> What alternative would be better?  Arrow keys require moving your hands
> away from the center.  Moving the graphical pointer, even more so.

The arrow keys (that includes PgUp and PgDown and Home and End) in
combination with C-a and C-e are better.  That's all I use for moving
around.

For example, to press C-u, I have to move my left hand over to the left
to press the left Ctrl key, and then my right hand moves one key over to
the left to press U because I'm not on the rows anymore anyway.  You
might say it's not efficient.  It is how nowadays keyboards are.  C-u is
difficult to press, and the chance of hitting an unwanted key when
trying that is very high.  It is like the most inefficient way to scroll
up.

Add to that that Emacs is the only program with such key bindings, and
it is not efficient when I need to think differently with every program
about how to move the cursor.

When I move the cursor around, I'm thinking about what I've been
writing.  I do not need my fingers to be on the home rows then.

>   > There is much more to learn about Emacs than key bindings for cursor
>   > movement, and the movement keys in the tutorial may be amongst the least
>   > relevant things that help efficient editing.
>
> Please give more detail.

Think of all the modes.  They all come with their own key bidings.

I'm using org for only two things: editing tables and hiding stuff with
'*'.  The only specific key binding I know is C-c SPc because it the
only one I need, and it makes editing tables much more efficient.  I've
been using org-mode for years and found out about this key binding only
a few weeks ago because I happened to frequently delete a cells content
and thought there should be an easier way to do that.

Emacs can work with CVS systems like git.  I haven't found yet out how
to make use of this feature, yet I'm sure there are lots of key bindings
that make editing source code much more efficient when you are using CVS
systems.

Gnus comes with a lot of key bindings without which you can't edit your
emails (unless you use the menu perhaps).

Think of many functions you may more or less frequently use, like
query-replace, indent-region, sort-lines ....  Some of them may have key
bindings, but I use ESC-x and call them name.  There are only so many
key bindings one can remember.

Think of bookmarks and registers.  They are essential for moving around.

So I would consider key bindings to move the cursor around as a
non-issue and put those into their own tutorial about "special key
bindings".  In an "important key bindings" tutorial, I would mention C-a
and C-e and ESC-< and ESC-> because they are extremely useful not only
for Emacs, and because when in a terminal, Cltr-End and Ctrl-Home don't
work.  And I would point to registers and bookmarks, and make a tutorial
about them if tutorials were categorized like "move around", "do this",
"do that".

Re: Some developement questions

[Phil Sainty]

On 2018-09-07 20:01, hw wrote:
> Think of all the modes.  They all come with their own key bidings.

> I'm using org for only two things: editing tables and hiding stuff with
> '*'.  The only specific key binding I know is C-c SPc

> Emacs can work with CVS systems like git.  I haven't found yet out how
> to make use of this feature, yet I'm sure there are lots of key 
> bindings
> that make editing source code much more efficient when you are using 
> CVS
> systems.

> Gnus comes with a lot of key bindings without which you can't edit your
> emails (unless you use the menu perhaps).

> There are only so many key bindings one can remember.


I really *urge* you to turn `menu-bar-mode' back on, permanently.

Whatever you feel you're gaining from hiding the menus surely can't be
of greater benefit to you than all the knowledge and functionality that
you're missing as a consequence?

So many of the things that you don't know could be answered by perusing
the menus -- which both provide direct access to commands, and also show
the equivalent key bindings (no doubt including many of the ones you
can't remember).

I believe that re-enabling the menus would be a huge net win for you
-- like any other user, you could learn and gain so much from keeping
them available.  You can almost guarantee that the most important
features of a given mode will be accessible through its menus; so
using the menus not only saves you from having to remember all of the
key bindings, but it also provides an overview of some of the most
useful abilities of the library in question.

Tangentially, also make sure you've taken then time to learn how to
use the Info manuals, which are absolutely invaluable.  Use M-x
Info-help (or type "h" inside any existing info buffer) to learn how
to read and search the manuals, and to use the indexes.  Once you've
done that, you will know how to find the answers to so many questions.

I feel that so many of your questions would be answered by Emacs, if
you only asked it.


-Phil

Re: Some developement questions

[Stefan Monnier]

> I really *urge* you to turn `menu-bar-mode' back on, permanently.

I live pretty happily with a disabled menu-bar.
Disabling it doesn't prevent me from using it (in those rare cases
where I find it more convenient), since I can access it with C-mouse-3.

[ I started disabling the menu-bar many many years ago when the few extra
  lines of screen real-estate it gave me seemed more worthwhile.
  This benefit has diminished over the years as my screens's vertical size
  has grown, but the day my 4:3 laptop dies the benefit will
  increase again.  ]

> I feel that so many of your questions would be answered by Emacs, if
> you only asked it.

Indeed, I think Emacs tries pretty hard to make it easy to find those
answers, so while I don't urge anyone to enable the menu-bar, I strongly
encourage people to *use* it for discovery purposes (including the
discover the various additional items in the Help menu).


        Stefan

Re: Some developement questions

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 07 Sep 2018 10:00:58 -0400
> 
> > I really *urge* you to turn `menu-bar-mode' back on, permanently.
> 
> I live pretty happily with a disabled menu-bar.

And I never disable it.  Not even on a laptop.

RE: Some developement questions

[Drew Adams]

> > I really *urge* you to turn `menu-bar-mode' back on, permanently.
> 
> I live pretty happily with a disabled menu-bar.
> Disabling it doesn't prevent me from using it (in those rare cases
> where I find it more convenient), since I can access it with C-mouse-3.
> 
> [ I started disabling the menu-bar many many years ago when the few extra
>   lines of screen real-estate it gave me seemed more worthwhile.
>   This benefit has diminished over the years as my screens's vertical size
>   has grown, but the day my 4:3 laptop dies the benefit will
>   increase again.  ]
> 
> > I feel that so many of your questions would be answered by Emacs, if
> > you only asked it.
> 
> Indeed, I think Emacs tries pretty hard to make it easy to find those
> answers, so while I don't urge anyone to enable the menu-bar, I strongly
> encourage people to *use* it for discovery purposes (including the
> discover the various additional items in the Help menu).

Yes. But if it is disabled you won't know when/whether a new mode
has added a menu-bar menu (unless you happen to use C-mouse-3
in that mode sometime). That probably doesn't matter to you, but
it might make a difference for a new user.

I agree with Phil S that it makes sense for a new user, especially,
to leave the menu-bar enabled. For someone a bit more experienced
your suggestion can make sense. Choosing to discover things by
exploring menus is in either case an active choice, but the visibility
of a new main menu on the menu-bar can invite investigation.

RE: Some developement questions

[Drew Adams]

> > > I really *urge* you to turn `menu-bar-mode' back on, permanently.
> >
> > I live pretty happily with a disabled menu-bar.
> 
> And I never disable it.  Not even on a laptop.

I disable it on thumbnail frames (it does not resize along with the
frame - I know of no easy way to resize its text).

And I sometimes toggle it off for other reasons. But I too generally
leave it on.

Re: Some developement questions

[hw]

Phil Sainty <psainty@orcon.net.nz> writes:

>> There are only so many key bindings one can remember.
>
>
> I really *urge* you to turn `menu-bar-mode' back on, permanently.

I'd rather have it turned on or off automatically depending on which
mode is active.

> Whatever you feel you're gaining from hiding the menus surely can't be
> of greater benefit to you than all the knowledge and functionality that
> you're missing as a consequence?

Well, I'm not missing anything.  What would I be searching for in the
menues, and why would I bother to look?

Do you have an example?  I never looked at the menu of cperl-mode, so
what am I missing there?

Re: Some developement questions

[Phil Sainty]

On 08/09/18 02:15, hw wrote:
> Phil Sainty <psainty@orcon.net.nz> writes:
>> Whatever you feel you're gaining from hiding the menus surely
>> can't be of greater benefit to you than all the knowledge and
>> functionality that you're missing as a consequence?
>
> Well, I'm not missing anything.  What would I be searching for in
> the menues, and why would I bother to look?

In the snippets I quoted before, as well as in other earlier emails,
you have explained how there are numerous Emacs features and modes
that you don't really know how to use because you don't know what the
key bindings are; and also that you have hidden the feature which
would most trivially let you find out what they did and how to use
them.  With the menus visible I am *imagining* that it would occur to
you to look at them the next time you were wondering what sorts of
commands a particular mode provided, and that in the process you may
even discover some useful key bindings as well.


> Do you have an example?

Sure.  You said just before:

> Emacs can work with CVS systems like git.  I haven't found yet out
> how to make use of this feature, yet I'm sure there are lots of key
> bindings that make editing source code much more efficient when you
> are using CVS systems.

Sitting there waiting in the Tools -> Version Control menu we find
all of the following:

VC Dir                         C-x v d
Ignore File...                 C-x v G
Register                       C-x v i
Check In/Out                   C-x v v
Update to Latest Version       C-x v +
Push Changes                   C-x v P
Revert to Base Version         C-x v u
Insert Header
Show Top of the Tree History   C-x v L
Show History                   C-x v l
Show Incoming Log              C-x v I
Show Outgoing Log              C-x v O
Update ChangeLog               C-x v a
Compare Tree with Base Version C-x v D
Compare with Base Version      C-x v =
Show Other Version             C-x v ~
Rename File
Annotate                       C-x v g
Create Tag                     C-x v s
Retrieve Tag                   C-x v r

Which tells you a whole bunch of useful commands for working with
a VCS system, and means you never need to worry about forgetting
any of the bindings (but it still tells you what they are, so that
you could use them instead if you chose to).

And of course checking the manual (maybe via the Help menu) would
quickly take you to the Info node "(emacs)Version Control" where
you could learn all about this feature in detail.


I have to admit that I'm genuinely perplexed.  On the one hand you
profess to having some difficulty finding out how to do things -- or
even what things there might be available to do -- all of which sounds
to me a lot like "I'm missing things"; and on the other hand you say
"I'm not missing anything" and that you see no reasons to look in the
menus, despite those menus existing for the purposes of showing people
the things they can do, and making it easy to do them even when they
don't know the key bindings.

If the menus are not one of the *best* answers to your issue, then
I've completely and utterly misunderstood.

In any case, I shall stop harping on about it.


-Phil

Re: Some developement questions

[hw]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 08/09/18 02:15, hw wrote:
>> Phil Sainty <psainty@orcon.net.nz> writes:
>>> Whatever you feel you're gaining from hiding the menus surely
>>> can't be of greater benefit to you than all the knowledge and
>>> functionality that you're missing as a consequence?
>>
>> Well, I'm not missing anything.  What would I be searching for in
>> the menues, and why would I bother to look?
>
> In the snippets I quoted before, as well as in other earlier emails,
> you have explained how there are numerous Emacs features and modes
> that you don't really know how to use because you don't know what the
> key bindings are;

That must have been a misunderstanding.

Of course there are many features and key bindings I don't how to use or
I don't know about at all.  I will probably never know all there is to
know.

And that's fine because I do not need all the available features and key
bindings.  I only need to know those I use, and there is a difference
between things I use frequently and things I rarely use.  Info is one of
the things I rarely use.

The last time I used info was probably 4 or 5 years ago.  I simply
didn't need to use it in between because I was using Emacs just fine all
the time.

That is why I'm saying that it would be nice if the menu was
automatically enabled with modes I rarely use and disabled with those I
frequently use.  It might have occured to me to look into the menu to
find out how to go back if the menu had been enabled --- that the menu
would have enabled itself automatically for the info buffer would have
told me that I'll probably need it.

Is that so difficult to understand?

> and also that you have hidden the feature which would most trivially
> let you find out what they did and how to use them.  With the menus
> visible I am *imagining* that it would occur to you to look at them
> the next time you were wondering what sorts of commands a particular
> mode provided, and that in the process you may even discover some
> useful key bindings as well.

I would try to ignore it if it was permanently enabled.  It wastes
screen space, it is inefficient and I rather learn the key bindings than
having to use a menu.  I wouldn't use it *because* it's permanently
enabled and thus permanently annoys me.

>> Do you have an example?
>
> Sure.  You said just before:
>
>> Emacs can work with CVS systems like git.  I haven't found yet out
>> how to make use of this feature, yet I'm sure there are lots of key
>> bindings that make editing source code much more efficient when you
>> are using CVS systems.
>
> Sitting there waiting in the Tools -> Version Control menu we find
> all of the following:

I wouldn't enable the menu if I wanted to use this mode.  I would read
the documentation and learn how to use it.


> [...]
>
> I have to admit that I'm genuinely perplexed.  On the one hand you
> profess to having some difficulty finding out how to do things -- or
> even what things there might be available to do -- all of which sounds
> to me a lot like "I'm missing things"; and on the other hand you say
> "I'm not missing anything" and that you see no reasons to look in the
> menus, despite those menus existing for the purposes of showing people
> the things they can do, and making it easy to do them even when they
> don't know the key bindings.

I think that's probably because you misunderstood.

When I was stuck in the info help, I wanted to read documentation about
tramp, not about anything else.  I followed a reference and didn't know
how to get back, so I looked into the help.  Then I just wanted to get
out of the stupid help page because even that page didn't tell me how I
could get back.  Quitting the info buffer doesn't help for some reason
because when you call info again, you get to the same place where you
left --- that is a very annoying feature not only with info buffers.  So
finally I killed the buffer and started over.

It didn't occur to me to turn on the menu.  Why would it?  It had
nothing to do with I wanted.


So guess what keys especially a new user might try to go back.  Chances
are pretty good he would try Alt-left rather than an ideosyncratic key
only Emacs knows about.  But that doesn't work, and the user remains
stuck.  The user quits the info buffer and calls info again to start
over --- just to find out that he is still stuck at the same place.  The
new user may not be familiar with this weird behaviour and not know that
he needs to kill the buffer.

Seriously?  Do you call that good design?  Do you call that helpfull?

I'm merely saying this is something to improve upon.  You're pushing it
back by saying I should have the menu enabled.  The new user might still
have it enabled, but he might also have found out that it can be
disabled.  He might have disabled it because he wants to learn the key
bindings, and disabling the menu supports that because when something is
harder to look up, there is more incentive to remember it.  It might not
occur to him to enable it when he's stuck in the help of info, or
somewhere else, while trying to read documentation about something.

That someone has trouble finding out something can happen to everyone.
So why not make it easier for everyone?

> If the menus are not one of the *best* answers to your issue, then
> I've completely and utterly misunderstood.

Apparently it happens to me all the time that people don't understand
what I'm saying :/

I think I've found a better answer to the problem with the idea of the
menues enabling and disabling themselves automatically.  The answer to
that was that I can have that by using mode hooks.  That probably means
it will never be considered to perhaps become a default behaviour.

I think it would be an improvement, especially for new users who do not
know about mode hooks.  I don't know how to do it, either, but I'm sure
I can find out when I want to.

RE: Some developement questions

[Drew Adams]

> > There are only so many key bindings one can remember.
> 
> I really *urge* you to turn `menu-bar-mode' back on, permanently.
> 
> Whatever you feel you're gaining from hiding the menus surely can't be
> of greater benefit to you than all the knowledge and functionality that
> you're missing as a consequence?
> 
> So many of the things that you don't know could be answered by perusing
> the menus -- which both provide direct access to commands, and also show
> the equivalent key bindings (no doubt including many of the ones you
> can't remember).
> 
> I believe that re-enabling the menus would be a huge net win for you
> -- like any other user, you could learn and gain so much from keeping
> them available.  You can almost guarantee that the most important
> features of a given mode will be accessible through its menus; so
> using the menus not only saves you from having to remember all of the
> key bindings, but it also provides an overview of some of the most
> useful abilities of the library in question.
> 
> Tangentially, also make sure you've taken then time to learn how to
> use the Info manuals, which are absolutely invaluable.  Use M-x
> Info-help (or type "h" inside any existing info buffer) to learn how
> to read and search the manuals, and to use the indexes.  Once you've
> done that, you will know how to find the answers to so many questions.
> 
> I feel that so many of your questions would be answered by Emacs, if
> you only asked it.

What Phil said.

Re: Some developement questions

[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 arrow keys (that includes PgUp and PgDown and Home and End) in
  > combination with C-a and C-e are better.  That's all I use for moving
  > around.

I use sequences of cursor motion commands all the time.  I don't really
move my hand away when I hold the left control key.  Often I hold it down
for several characters in a row.

I never type PgUp and PgDown and Home and End, because they are
so far away they would never occur to me.

This is the normal way to do cursor motion in Emacs.  You can do it
any way you like, but we should encourage people to learn this way.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[hw]

Richard Stallman <rms@gnu.org> writes:

> [...]
>   > The arrow keys (that includes PgUp and PgDown and Home and End) in
>   > combination with C-a and C-e are better.  That's all I use for moving
>   > around.
>
> I use sequences of cursor motion commands all the time.
> [...]
> This is the normal way to do cursor motion in Emacs.  You can do it
> any way you like, but we should encourage people to learn this way.

I'm fine with encouraging people to learn these movement keys, but how
do the available movement keys give beginners good reasons to use Emacs,
and how do they make using it better for them?

Beginners will probably consider "the normal way to do cursor motion in
Emacs" as the most complicated and awkward way to do cursor motion
anywhere.  Since motion is important when using an editor, building such
a wall against it seems particularly well suited to scare them off to
other editors which appear to be easier to use.

Tutorials which take this into account more strongly might be more
encouraging to use Emacs in the first place, and then beginners might
want to learn the special movement keys.

The current tutorial is doing it the other way round, and aside from
external sources, it is quite likely the first thing beginners will read
about Emacs: The first thing they read is the thing that will scare them
off the most.  How are they going to understand that Emacs is not
difficult to use at all?


BTW, I still don't see how anyone could move around efficiently when it
requires to press ESC.  Does it require a special keyboard?

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: eliz@gnu.org,  phillip.lord@russet.org.uk,  spacibba@aol.com,  emacs-devel@gnu.org
> Date: Sat, 08 Sep 2018 15:02:51 +0200
> 
> > This is the normal way to do cursor motion in Emacs.  You can do it
> > any way you like, but we should encourage people to learn this way.
> 
> I'm fine with encouraging people to learn these movement keys, but how
> do the available movement keys give beginners good reasons to use Emacs,
> and how do they make using it better for them?
> 
> Beginners will probably consider "the normal way to do cursor motion in
> Emacs" as the most complicated and awkward way to do cursor motion
> anywhere.  Since motion is important when using an editor, building such
> a wall against it seems particularly well suited to scare them off to
> other editors which appear to be easier to use.
> 
> Tutorials which take this into account more strongly might be more
> encouraging to use Emacs in the first place, and then beginners might
> want to learn the special movement keys.

The Emacs tutorial already mentions the arrow keys, before it teaches
the more ergonomic cursor motion keys.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: eliz@gnu.org,  phillip.lord@russet.org.uk,  spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Sat, 08 Sep 2018 15:02:51 +0200
> [...]
>> 
>> Beginners will probably consider "the normal way to do cursor motion in
>> Emacs" as the most complicated and awkward way to do cursor motion
>> anywhere.
> [...]
>> Tutorials which take this into account more strongly might be more
>> encouraging to use Emacs in the first place, and then beginners might
>> want to learn the special movement keys.
>
> The Emacs tutorial already mentions the arrow keys, before it teaches
> the more ergonomic cursor motion keys.

My point is not which particular keys to use but that the tutorial
doesn't fly because it makes false assumptions ---

in this case about the efficiency with which certain keys can be pressed
which largely depends on

+ the users and their skill-level in 10-finger typing,

+ the equipment in use and

+ the difficulty of un-learning the usage of arrow keys which might have
  already been practised to a rather high and extremely efficient
  skill-level over decades and is still needed everywhere else

--- which lead the tutorial to lengthly go into explanations about
irrelevant key bindings rather than about relevant ones which prevents
it from picking up beginners where they think they are so that
confidence can be instilled in them that they can learn Emacs, and trust
that Emacs isn't difficult to use at all.

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org,  rms@gnu.org,  phillip.lord@russet.org.uk
> Date: Sun, 09 Sep 2018 01:23:53 +0200
> 
> > The Emacs tutorial already mentions the arrow keys, before it teaches
> > the more ergonomic cursor motion keys.
> 
> My point is not which particular keys to use but that the tutorial
> doesn't fly because it makes false assumptions ---
> 
> in this case about the efficiency with which certain keys can be pressed
> which largely depends on
> 
> + the users and their skill-level in 10-finger typing,
> 
> + the equipment in use and
> 
> + the difficulty of un-learning the usage of arrow keys which might have
>   already been practised to a rather high and extremely efficient
>   skill-level over decades and is still needed everywhere else

Yes, the tutorial makes a point of catering also for people who want
or can overcome these obstacles.  I see nothing wrong with that: if
you are one of those who can't, just ignore the part about ergonomic
cursor motion keys.

> --- which lead the tutorial to lengthly go into explanations about
> irrelevant key bindings rather than about relevant ones which prevents
> it from picking up beginners where they think they are so that
> confidence can be instilled in them that they can learn Emacs, and trust
> that Emacs isn't difficult to use at all.

Are we talking about the same tutorial?  Here's the actual text:

  * BASIC CURSOR CONTROL
  ----------------------

  Moving from screenful to screenful is useful, but how do you
  move to a specific place within the text on the screen?

  There are several ways you can do this.  You can use the arrow keys,
  but it's more efficient to keep your hands in the standard position
  and use the commands C-p, C-b, C-f, and C-n. [...]

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org,  rms@gnu.org,  phillip.lord@russet.org.uk
>> Date: Sun, 09 Sep 2018 01:23:53 +0200
>> 
>> > The Emacs tutorial already mentions the arrow keys, before it teaches
>> > the more ergonomic cursor motion keys.
>> 
>> My point is not which particular keys to use but that the tutorial
>> doesn't fly because it makes false assumptions ---
>> 
>> in this case about the efficiency with which certain keys can be pressed
>> which largely depends on
>> 
>> + the users and their skill-level in 10-finger typing,
>> 
>> + the equipment in use and
>> 
>> + the difficulty of un-learning the usage of arrow keys which might have
>>   already been practised to a rather high and extremely efficient
>>   skill-level over decades and is still needed everywhere else
>
> Yes, the tutorial makes a point of catering also for people who want
> or can overcome these obstacles.

I'm not sure what you're referring to.  I'm seeing the tutorial
repeating that you can use the cursor keys but should learn others
because they are supposedly more efficient.

> I see nothing wrong with that: if you are one of those who can't, just
> ignore the part about ergonomic cursor motion keys.

Does the tutorial say that when you use cursor keys, you can skip
forward to line 322 and start reading there?

>> --- which lead the tutorial to lengthly go into explanations about
>> irrelevant key bindings rather than about relevant ones which prevents
>> it from picking up beginners where they think they are so that
>> confidence can be instilled in them that they can learn Emacs, and trust
>> that Emacs isn't difficult to use at all.
>
> Are we talking about the same tutorial?  Here's the actual text:
>
>   * BASIC CURSOR CONTROL
>   ----------------------
>
>   Moving from screenful to screenful is useful, but how do you
>   move to a specific place within the text on the screen?
>
>   There are several ways you can do this.  You can use the arrow keys,
>   but it's more efficient to keep your hands in the standard position
>   and use the commands C-p, C-b, C-f, and C-n. [...]

Yes, we are talking about the same tutorial.

The tutorial uses the first 322 lines (26%) to go on and on about these
movement keys.  It is supposed to be *the* Emacs tutorial, not a
keyboard tutorial.

Do you really think that *the* Emacs tutorial should use its first 300+
lines to cover a non-issue?  Isn't there anything much more interesting
and far more important to learn about Emacs?

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  phillip.lord@russet.org.uk,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 10 Sep 2018 11:35:58 +0200
> 
> > I see nothing wrong with that: if you are one of those who can't, just
> > ignore the part about ergonomic cursor motion keys.
> 
> Does the tutorial say that when you use cursor keys, you can skip
> forward to line 322 and start reading there?

It says "you can use the arrow keys".  Skipping is not a problem, as
the tutorial has small and clearly marked sections.

But I'm not opposed to adding an explicit sentence like that.

> The tutorial uses the first 322 lines (26%) to go on and on about these
> movement keys.  It is supposed to be *the* Emacs tutorial, not a
> keyboard tutorial.

They are not general keyboard features, they are _Emacs_ keyboard
input features.

> Do you really think that *the* Emacs tutorial should use its first 300+
> lines to cover a non-issue?  Isn't there anything much more interesting
> and far more important to learn about Emacs?

We don't think this is a non-issue.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  phillip.lord@russet.org.uk,  rms@gnu.org,  emacs-devel@gnu.org
>> Date: Mon, 10 Sep 2018 11:35:58 +0200
>> 
>> > I see nothing wrong with that: if you are one of those who can't, just
>> > ignore the part about ergonomic cursor motion keys.
>> 
>> Does the tutorial say that when you use cursor keys, you can skip
>> forward to line 322 and start reading there?
>
> It says "you can use the arrow keys".  Skipping is not a problem, as
> the tutorial has small and clearly marked sections.

I'd break it down into multiple smaller tutorials, even if it is only so
that users can say "Yay, I already finished three of the tutorials!"
rather than "Yeah, I got only to line 234 and it's gona take ages to
learn this.".

Readers should not need to skip.  Imagine you were watching a movie that
said at the beginning "please skip the first 26% percent".  Wouldn't you
ask yourself why the makers of the movie have put these 26% at its
beginning so that everyone needs to skip it?  What's the point of doing
that?

It's like everyone on TV and the on the radio saying "you can look it up
on the internet": Why do they bother to make a TV or radio show when I'm
not supposed to watch or listen but to look it up on the internet?  If I
wanted that, I'd be doing it.

> But I'm not opposed to adding an explicit sentence like that.

That would allow them to feel save about skipping.  Instead of making
everyone skip, there could be information at the beginning people don't
want to skip.

>> The tutorial uses the first 322 lines (26%) to go on and on about these
>> movement keys.  It is supposed to be *the* Emacs tutorial, not a
>> keyboard tutorial.
>
> They are not general keyboard features, they are _Emacs_ keyboard
> input features.

Moving (the cursor) around is a general feature of every software that
involves cursor movement or even just scrolling.

People can use Emacs just fine without ever knowing that it provides
them with a whole set of key bindings for cursor movement.  How are
these special key bindings so important that they must take up the first
26% of the Emacs tutorial?

If the most important feature of Emacs were its key bindings for cursor
movement, then I might still be using joe.  Joe doesn't work at all
without key bindings, but you can easily move around without any special
ones, and it's a pretty good editor.

>> Do you really think that *the* Emacs tutorial should use its first 300+
>> lines to cover a non-issue?  Isn't there anything much more interesting
>> and far more important to learn about Emacs?
>
> We don't think this is a non-issue.

It probably is for beginners.  They can already move around, and they
are eager to do that so they can learn about Emacs by doing something
with it, like editing their files.

Please disable your Alt key(s) and try the Emacs way of cursor movement,
key bindings starting with M-C and everything you usually do with Emacs
like that.  Half a day might be enough to show you how efficiently the
movement keys work :)

Even with Alt working, I suggest that there are far more relevant things
beginners need to learn than something they can already do.  For those
who really do not know how to move around at all, there could be a
tutorial about just that which also explains cursor keys.  I would think
that those users are the most likely ones to pick up the Emacs way of
movement; everyone else will probably continue with cursor keys.

Re: Some developement questions

[Phillip Lord]

hw <hw@adminart.net> writes:

>> Are we talking about the same tutorial?  Here's the actual text:
>>
>>   * BASIC CURSOR CONTROL
>>   ----------------------
>>
>>   Moving from screenful to screenful is useful, but how do you
>>   move to a specific place within the text on the screen?
>>
>>   There are several ways you can do this.  You can use the arrow keys,
>>   but it's more efficient to keep your hands in the standard position
>>   and use the commands C-p, C-b, C-f, and C-n. [...]
>
> Yes, we are talking about the same tutorial.
>
> The tutorial uses the first 322 lines (26%) to go on and on about these
> movement keys.  It is supposed to be *the* Emacs tutorial, not a
> keyboard tutorial.
>
> Do you really think that *the* Emacs tutorial should use its first 300+
> lines to cover a non-issue?  Isn't there anything much more interesting
> and far more important to learn about Emacs?

I have watched people new to Emacs reading the tutorial. "Do I really
need to learn all these keypresses to use Emacs" is what they say. The
answer is no, they don't. It has no place in the tutorial, no.

Phil

Re: Some developement questions

[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'm fine with encouraging people to learn these movement keys, but how
  > do the available movement keys give beginners good reasons to use Emacs,
  > and how do they make using it better for them?

For the second question, they make cursor motion faster.
The fact that it can be faster is a reason to use Emacs,
but I won't claim that reason is visible to people thinking
about using Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[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'm fine with encouraging people to learn these movement keys, but how
  > do the available movement keys give beginners good reasons to use Emacs,
  > and how do they make using it better for them?

For the second question, they make cursor motion faster.
The fact that it can be faster is a reason to use Emacs
but I won't claim that reason is visible to people thinking
about using Emacs.

  > Tutorials which take this into account more strongly might be more
  > encouraging to use Emacs in the first place, and then beginners might
  > want to learn the special movement keys.

That approach might be good, but what can we do to encourage them to
learn the cursor-motion commands later on?

  > BTW, I still don't see how anyone could move around efficiently when it
  > requires to press ESC.  Does it require a special keyboard?

Nowadays, essentially all keyboards have an Alt key, so one never needs
to use ESC for cursor motion.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org, spacibba@aol.com,
> 	phillip.lord@russet.org.uk
> Date: Sun, 09 Sep 2018 02:07:02 -0400
> 
>   > BTW, I still don't see how anyone could move around efficiently when it
>   > requires to press ESC.  Does it require a special keyboard?
> 
> Nowadays, essentially all keyboards have an Alt key, so one never needs
> to use ESC for cursor motion.

For cursor motion, yes.  There are still other keys where using ESC
might prove necessary, e.g. if your window manager "eats up" some
Alt-character sequences, and you cannot or won't disable that.

Re: Some developement questions

[Ergus]

On Sun, Sep 09, 2018 at 02:07:02AM -0400, 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. ]]]
>
>  > I'm fine with encouraging people to learn these movement keys, but how
>  > do the available movement keys give beginners good reasons to use Emacs,
>  > and how do they make using it better for them?
>
>For the second question, they make cursor motion faster.
>The fact that it can be faster is a reason to use Emacs
>but I won't claim that reason is visible to people thinking
>about using Emacs.
>
>  > Tutorials which take this into account more strongly might be more
>  > encouraging to use Emacs in the first place, and then beginners might
>  > want to learn the special movement keys.
>
>That approach might be good, but what can we do to encourage them to
>learn the cursor-motion commands later on?
>
I just started using the traditional keybindings like 3 months ago and I
have been with emacs like 4 years now; so I agree that traditional
keybindings are not transcendental to enjoy emacs (or edit efficiently
because I made 2 thesis without that).

On the other hand I only see some advantage in few of them (C-a, C-e,
C-d), but not all. The C-n/p/b/f are closer, that's true, but requires 2
hands constantly in action and p-n-b-f are not close each other (b and f
are supposed to be typed with different hands in fact). The arrows, in
my keyboard for example, are not far enough from the rest of the keys
so using them is just easier (see the hp elitebook keyboards).
But also C-b/C-f are not very comfortable to be using them
constantly with one hand.

I understand that the keys are designed to be easier to remember, but
not to type in a qwerty keyboard without extensive training. But the
related M-{ M-} are harder remember and to type than C-up C-down because they require
3 (Alt-Shift+) fingers vs 2 (Control+) and are not related with C-p C-n,
so also are difficult to remember.

So the efficiency advantage of C-* displacement is very subjective in this cases.

Comparing for example with vim; the commands are easier to type because
with the modes it doesn't need modifiers with the other hand, but also
hjkl are close each other. But even with all that, new vim's users prefer the
arrows just because "up" is over "down".

So I feel like the real issue here is the "backward compatibility" with
experienced users. But if that's the only priority, it will be very
difficult to attract new users with new ideas and new points of view to
emacs. That's why the spacemacs community is growing, because it
offers a more familiar behavior (even without evil mode).



>  > BTW, I still don't see how anyone could move around efficiently when it
>  > requires to press ESC.  Does it require a special keyboard?
>
>Nowadays, essentially all keyboards have an Alt key, so one never needs
>to use ESC for cursor motion.
>
>
>-- 
>Dr Richard Stallman
>President, Free Software Foundation (https://gnu.org, https://fsf.org)
>Internet Hall-of-Famer (https://internethalloffame.org)
>
>

Re: Some developement questions

[hw]

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. ]]]
>
>   > I'm fine with encouraging people to learn these movement keys, but how
>   > do the available movement keys give beginners good reasons to use Emacs,
>   > and how do they make using it better for them?
>
> For the second question, they make cursor motion faster.

They don't do that.

Besides, it has finally occurred to me that I /like/ moving my hands.
My thinking and my typing would freeze up as well if I had to have them
like frozen to the home row all the time.

> The fact that it can be faster is a reason to use Emacs
> but I won't claim that reason is visible to people thinking
> about using Emacs.

Using Emacs can be faster and more efficient than using other editors
for many reasons.  It's movement keys can help some users and get into
the way of others, and they are by far not the most important feature
and not the only one giving reason to use Emacs.

Making visible to potential users how using Emacs can be advantageous to
them should not be blocked by over 300 lines of tutorial that go on
about the movement keys in the wrong place.  These 300 lines might be
better used to point out what Emacs can do, and to lead users to
specific documentation about the particular features.  Not every user is
interested in the same things.

>   > Tutorials which take this into account more strongly might be more
>   > encouraging to use Emacs in the first place, and then beginners might
>   > want to learn the special movement keys.
>
> That approach might be good, but what can we do to encourage them to
> learn the cursor-motion commands later on?

Let users experience that Emacs is the best editor ever, and they aren't
going to need much encouragement to learn more about it all the time
because they will want to do that anyway.  For those who still would not
want to learn the key bindings for cursor motion, encouragement would
need to be turned into enforcement, and that's not exactly feasible.

So if you can dedicate a whole tutorial to learning the movement keys
and offer users to do it when ever they feel ready, you have vastly
better chances of success and of another happy user than you have when
you push and shove all these movement keys right into the face of a user
who is already struggling hands up with navigating a way through an
entirely new, heavy piece of software which can be very difficult to
learn when you take the wrong way.

>   > BTW, I still don't see how anyone could move around efficiently when it
>   > requires to press ESC.  Does it require a special keyboard?
>
> Nowadays, essentially all keyboards have an Alt key, so one never needs
> to use ESC for cursor motion.

Well, yes, only the Alt key never worked.  It didn't work on the Atari
ST (where Emacs crashed an awful lot), didn't work later with Linux, not
with different keyboards, not for the last 25 years or so.  I can't tell
exactly when it started working because some time I gave up trying.  It
works for me since less than a week.

Key bindings with M-C?  Emacs always says 'C-<escape> is undefined'.

So how are Emacs` key bindings for cursor movement more efficient than
the cursor keys, given that the Alt key does not work?  I've read the
tutorial on my Atari ST and decided against using these key bindings
back then.  I thought they might be for computers that have severe
limitations and/or keyboards without cursor keys, as a workaround to get
the cursor moving at all.


Eli pointed out that window managers like to use the Alt key for
themselves so that it never arrives at Emacs.  That is something I would
definitely put into the (keyboard) tutorial where it explains the Meta
key.

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: eliz@gnu.org,  phillip.lord@russet.org.uk,  spacibba@aol.com,  emacs-devel@gnu.org
> Date: Mon, 10 Sep 2018 13:59:48 +0200
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> So how are Emacs` key bindings for cursor movement more efficient than
> the cursor keys, given that the Alt key does not work?

The Alt key does work, you probably have your keyboard misconfigured.

> Eli pointed out that window managers like to use the Alt key for
> themselves so that it never arrives at Emacs.

Not Alt itself, some combinations that begin with Alt.  Like Alt-TAB,
for example.  There are very few such combinations, and Emacs avoids
binding important functions to them.  So I think explaining that in
the tutorial would not be TRT, as the issue is quite obscure.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: eliz@gnu.org,  phillip.lord@russet.org.uk,  spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Mon, 10 Sep 2018 13:59:48 +0200
>> 
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> So how are Emacs` key bindings for cursor movement more efficient than
>> the cursor keys, given that the Alt key does not work?
>
> The Alt key does work, you probably have your keyboard misconfigured.

I found out less than a week ago that it now finally works.  It did not
work for the first 25 years or so, beginning on an Atari ST.

Technically, it may have started working earlier and I didn't know
because hadn't tried it for a long time because it hasn't been working
for decades.

I don't know why it works now; chances to find out are low.

My keyboard is probably not misconfigured.  Everything works as
intended.  I've had keyboards misconfigured, it usually shows when you
can not switch from X to a console, and I fixed that when it happend.  I
have a couple keyboards here, and each requires its own specific
configuration.

I think someone fixed a bug some time, somewhere, and it works since
then.

>> Eli pointed out that window managers like to use the Alt key for
>> themselves so that it never arrives at Emacs.
>
> Not Alt itself, some combinations that begin with Alt.  Like Alt-TAB,
> for example.  There are very few such combinations, and Emacs avoids
> binding important functions to them.  So I think explaining that in
> the tutorial would not be TRT, as the issue is quite obscure.

I don't know, isn't that hard to say?  If a WM (or something else) were
to use Alt+v for something, it might not work, or work intermittently,
in Emacs.  If this possibility was mentioned in the tutorial, users
could at least check.  A small paragraph about it in the tutorial hurts
less than having the Alt key not working for 25 years.

In the case I've had a problem with it, it would still sometimes work
and sometimes not, apparently depending on whether the WM or the
program came first in reading input.

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org,  rms@gnu.org,  phillip.lord@russet.org.uk
> Date: Mon, 10 Sep 2018 21:48:06 +0200
> 
> > The Alt key does work, you probably have your keyboard misconfigured.
> 
> I found out less than a week ago that it now finally works.  It did not
> work for the first 25 years or so, beginning on an Atari ST.
> 
> Technically, it may have started working earlier and I didn't know
> because hadn't tried it for a long time because it hasn't been working
> for decades.

It worked for me for the last 30 years.

> >> Eli pointed out that window managers like to use the Alt key for
> >> themselves so that it never arrives at Emacs.
> >
> > Not Alt itself, some combinations that begin with Alt.  Like Alt-TAB,
> > for example.  There are very few such combinations, and Emacs avoids
> > binding important functions to them.  So I think explaining that in
> > the tutorial would not be TRT, as the issue is quite obscure.
> 
> I don't know, isn't that hard to say?  If a WM (or something else) were
> to use Alt+v for something, it might not work, or work intermittently,
> in Emacs.

We don't need to solve hypothetical problems, only those that happen
in practice.  In practice, only a small number of ALT combinations are
usurped by window managers, and they tend to be the same combinations
in all WMs, for good practical reasons.  We shouldn't expect that set
to grow or to usurp frequently used combinations, because that would
cause user outcry.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org,  rms@gnu.org,  phillip.lord@russet.org.uk
>> Date: Mon, 10 Sep 2018 21:48:06 +0200
>> 
>> > The Alt key does work, you probably have your keyboard misconfigured.
>> 
>> I found out less than a week ago that it now finally works.  It did not
>> work for the first 25 years or so, beginning on an Atari ST.
>> 
>> Technically, it may have started working earlier and I didn't know
>> because hadn't tried it for a long time because it hasn't been working
>> for decades.
>
> It worked for me for the last 30 years.

It didn't do that for me.

> [...]
>> > Not Alt itself, some combinations that begin with Alt.  Like Alt-TAB,
>> > for example.  There are very few such combinations, and Emacs avoids
>> > binding important functions to them.  So I think explaining that in
>> > the tutorial would not be TRT, as the issue is quite obscure.
>> 
>> I don't know, isn't that hard to say?  If a WM (or something else) were
>> to use Alt+v for something, it might not work, or work intermittently,
>> in Emacs.
>
> We don't need to solve hypothetical problems, only those that happen
> in practice.  In practice, only a small number of ALT combinations are
> usurped by window managers, and they tend to be the same combinations
> in all WMs, for good practical reasons.  We shouldn't expect that set
> to grow or to usurp frequently used combinations, because that would
> cause user outcry.

You have no way of knowing what key combinations a user may have defined
with the WM or with other software that uses or provides binding things
to keys.  You do know that there can be race conditions between Emacs
and other software in the usage of key bindings.

What is the advantage of waiting until a user has problem, like the Alt
key not working in Emacs, and reports it --- or assumes that's just the
way it is and that the ESC key should be used instead --- compared to
put a small paragraph into the tutorial so users can be aware of
possible race conditions right away and may be able to fix them without
asking for help?

Emacs is exceptional in how much the developers care about what the
users say.  With other projects, even if there might still be user
outcries, nobody cares.

Re: Some developement questions

[Phillip Lord]

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. ]]]
>
>   > I would like to add automation which would work better. So where it says
>   > "create a new frame", it would be nice to have a click button which
>   > actually does this for you.
>
> I don't follow.  Concretely, what do you propose, and what is good about it?


The tutorial might look like this:


Now you can create a new frame. Try

File->New Frame
[Show Me]


Clicking on show me would just do this. Given Emacs' architecture, this
should be straightforward to implement. In the idea world, you'd see the
menus opening and things being selected. This might be a little harder,
but still plausible.

I lack the time to implement this but it becomes possible, once we get
away from the idea of a tutorial as a text file you can edit.

Phil

Re: Some developement questions

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> My hope was to do something a bit more intelligent with it -- with some
>> screen shots and rich text, as well as highlighting for menu items, so I
>> wrote it in org-mode. Alas I haven't had the time to actually integrate
>> it into Emacs.
>> 
>> https://raw.githubusercontent.com/phillord/emacs-tutorial/master/tutorial.org
>> 
>> If someone has the time to do the integration it's nearly ready to
>> go. To my mind, updating the tutorial would be a good thing just because
>> it would give the impression that it is updateable, rather than a thing
>> set in stone.
>
> Thanks.  That tutorial looks like a somewhat expanded version of our
> TUTORIAL; e.g., it has almost the same scope in terms of Emacs
> features.  I thought, perhaps mistakenly, that we were talking about a
> tutorial for the next step -- for those who have read the original
> TUTORIAL and want to learn about more advanced issues related to text
> editing.

It covers some never stuff, but yes, it is fairly similar. Personally, I
would like to ditch all the "how to move around" with keys stuff -- this
scares most people to hell, because they think that they need to learn
this to do something that they already know how to do these things.

In terms of advanced issues, my thought was to enable tutorial
extensions to go into ELPA and then have a navigational structure. The
current tutorial for the even trivial reason that it's flat.

Phil

Re: Some developement questions

[hw]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Personally, I would like to ditch all the "how to move around" with
> keys stuff -- this scares most people to hell, because they think that
> they need to learn this to do something that they already know how to
> do these things.

right

The current tutorial is more suited to drive people away than anything
else.

Who knows what a META or an EDIT key is?  And who cares?  Even after
almost 30 years of getting used to them, I'm finding notations like 'C-x
ret f' or 'M-w' very confusing.  How does that belong into a tutorial?

People might use C-v to copy something rather than to scroll.  They will
use the cursor keys and PgUp and PgDown to move around.

What are the didactic purposes of having added so many blank lines?

Then when you do go ahead and hold down C-v as instructed, you suddenly
find yourself somewhere close to the end of the tutorial.  It only takes
a second for that with 'emacs -q' (and my default of 'xset r rate 250
60').

What is the user supposed to do then?

It's good to explain key bindings, but not like that at the beginning of
a tutorial when 99.9999% of the users do not still use keyboards that
don't have cursor keys.  The ones who do probably have found their ways
of dealing with it.


Your tutorial even explains what Emacs is and gives some history.  That
is a much more welcoming start.

> In terms of advanced issues, my thought was to enable tutorial
> extensions to go into ELPA and then have a navigational structure.

Maybe several tutorials would be better, like one covering what Emacs is
(nowadays that may be a good idea), one covering the first steps and
others covering the installation of packages after users have aquired
some understanding of what packages are.

My first step with 'emacs -q' would be to make the menu fonts larger.
As much as I like monospace fonts, the typewriter font used for the text
was *really ugly* even 30 years ago.  One look at Emacs with this font
might turn most people away before they start reading anything.

Re: Some developement questions

[Paul Eggert]

hw wrote:
> My first step with 'emacs -q' would be to make the menu fonts larger.
> As much as I like monospace fonts, the typewriter font used for the text
> was *really ugly* even 30 years ago.  One look at Emacs with this font
> might turn most people away before they start reading anything.

This matches my perception too, when I show Emacs to students. Emacs starts up 
in monospace font and that looks sooooo 1980s.  It's like showing them a 
medieval manuscript: cool in some sense, but they won't want to spend much of 
their working lives using it.

A little bit of marketing would help here. The initial contents of *scratch*, 
the mode line, and the minibuffer need not be monospaced, and would all benefit 
from a better font.

RE: Some developement questions

[Drew Adams]

> A little bit of marketing would help here. The initial contents of *scratch*,
> the mode line, and the minibuffer need not be monospaced, and would all
> benefit from a better font.

Just one opinion: No thanks to such marketing.

99.999% of my use of *scratch* and the minibuffer is code or data
that should be (i.e., that I want to be) monospace. And probably
90% of my mode-line too. (And I could change other parts of the
mode-line to use a different font, if I wanted to.)

IMHO, you could hardly have picked worse examples.

Info would have been a somewhat reasonable example. But even
there I'd rather have the code parts shown using monospace, and
code is a non-negligible part of many Info nodes. There's a reason
that technical doc typically uses variable-width for ordinary text
and fixed-width for code.

But it's true that you said only "the initial contents of..." (why?).
It's hard to argue that the initial contents of *scratch* call for a
monospace font. But are you proposing that Emacs automatically
change *scratch* to a monospace font when most of its contents
become code or such? Do you perhaps propose that Emacs
monitor such buffers to detect text that should reasonably be
monospace, and  automatically use a monospace font for those
parts (only)?

What's so hard about using a variable-width font for your Emacs 
classes/demos, at least for those buffers where you think it
makes sense? You could even show them how easy it is for them
to leave the dark-age 80s behind and become super cool on their
own.

(FWIW, on MS Windows it looks like menus use a variable-width
font.)

Re: Some developement questions

[Paul Eggert]

Drew Adams wrote:
>> A little bit of marketing would help here. The initial contents of *scratch*,
>> the mode line, and the minibuffer need not be monospaced, and would all
>> benefit from a better font.
> 
> 99.999% of my use of*scratch*  and the minibuffer is code or data
> that should be (i.e., that I want to be) monospace.

That's fine, and I wasn't suggesting changing that.

> are you proposing that Emacs automatically
> change *scratch* to a monospace font when most of its contents
> become code

No, just that the initial contents shouldn't be monospace.

> What's so hard about using a variable-width font for your Emacs 
> classes/demos

I generally don't do demos. My students use Emacs directly, and it's better for 
them (as for any other new user) if the defaults work nicely for them.
> (FWIW, on MS Windows it looks like menus use a variable-width
> font.)

Same is true for GNU/Linux, by default.

Re: Some developement questions

[Phillip Lord]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Drew Adams wrote:
>> are you proposing that Emacs automatically
>> change *scratch* to a monospace font when most of its contents
>> become code
>
> No, just that the initial contents shouldn't be monospace.

The simple solution here is to switch *scratch* out of lisp-interaction
mode. Emacs should include a lisp development environment, but it isn't
one.

Mostly I use *scratch* for dumping any old stuff that I want to use
later. Often just text.

Phil

RE: Some developement questions

[Drew Adams]

> The simple solution here is to switch *scratch* out of lisp-interaction
> mode. Emacs should include a lisp development environment, but it isn't
> one.

Agreed. I use `emacs-lisp-mode' for *scratch*, personally.

> Mostly I use *scratch* for dumping any old stuff that I want to use
> later. Often just text.

Re: Some developement questions

[Ergus]

On Tue, Sep 04, 2018 at 12:13:36PM -0700, Paul Eggert wrote:
>hw wrote:
>>My first step with 'emacs -q' would be to make the menu fonts larger.
>>As much as I like monospace fonts, the typewriter font used for the text
>>was *really ugly* even 30 years ago.  One look at Emacs with this font
>>might turn most people away before they start reading anything.
>
>This matches my perception too, when I show Emacs to students. Emacs 
>starts up in monospace font and that looks sooooo 1980s.  It's like 
>showing them a medieval manuscript: cool in some sense, but they won't 
>want to spend much of their working lives using it.
>
>A little bit of marketing would help here. The initial contents of 
>*scratch*, the mode line, and the minibuffer need not be monospaced, 
>and would all benefit from a better font.
>
Yes that was somehow my intention in the beginning. Give to the initial
user a better first impression. That includes a better interaction in
the beginning, access to customization, but also a better look counts
(the default color theme could be very improved). Most new users coming
from vim will like to use emacs in the terminal only, but it looks like
the latest efforts are now in the gui.

I think that new gui or windows users prefer sublime or other editors
that behave as they expect (C-c, C-v, click here and there and most
things working with no configuration needed) Emacs could provide that
experience if that's what the user likes.

But developing all this requires many developers, but you only get new
developers if you have more users (young students), but to have new
users you need a better initial experience... is a vicious circle.

Re: Some developement questions

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 4 Sep 2018 12:13:36 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com, emacs-devel@gnu.org
> 
> A little bit of marketing would help here. The initial contents of *scratch*, 
> the mode line, and the minibuffer need not be monospaced, and would all benefit 
> from a better font.

What newbies see when they start Emacs is not *scratch*, it's the
splash image and the welcome buffer.  And that one doesn't use
monospaced font.

Re: Some developement questions

[Paul Eggert]

Eli Zaretskii wrote:
> What newbies see when they start Emacs is not*scratch*, it's the
> splash image and the welcome buffer.

True; I'd forgotten. But we could still spruce up those bottom two lines, no? 
They're still using monospaced fonts and look like refugees from the 1980s.

Re: Some developement questions

[Joost Kremers]

On Wed, Sep 05 2018, Paul Eggert wrote:
> Eli Zaretskii wrote:
>> What newbies see when they start Emacs is not*scratch*, it's 
>> the
>> splash image and the welcome buffer.
>
> True; I'd forgotten. But we could still spruce up those bottom 
> two lines, no?
> They're still using monospaced fonts and look like refugees from 
> the 1980s.

IMHO the monospace font is not the problem. The font I get when I 
do `emacs -Q` looks quite good (it's DejaVu Sans Mono, BTW). But 
some way to visualise different types of information (similar to 
what most mode-line packages do), perhaps a few unicode symbols 
and a default way to put things at the right side of the mode line 
would, I think, go a long way to make the mode line look more 
modern.

-- 
Joost Kremers
Life has its moments

Re: Some developement questions

[Eli Zaretskii]

> From: Joost Kremers <joost.kremers@phil.uni-goettingen.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, hw@adminart.net, spacibba@aol.com, phillip.lord@russet.org.uk, emacs-devel@gnu.org
> Date: Wed, 05 Sep 2018 09:59:51 +0200
> 
> IMHO the monospace font is not the problem. The font I get when I 
> do `emacs -Q` looks quite good (it's DejaVu Sans Mono, BTW). But 
> some way to visualise different types of information (similar to 
> what most mode-line packages do), perhaps a few unicode symbols 
> and a default way to put things at the right side of the mode line 
> would, I think, go a long way to make the mode line look more 
> modern.

Wrt "a few Unicode symbols", do you have concrete proposals?

Thanks.

Re: Some developement questions

[Joost Kremers]

On Wed, Sep 05 2018, Eli Zaretskii wrote:
>> From: Joost Kremers <joost.kremers@phil.uni-goettingen.de>
>> IMHO the monospace font is not the problem. The font I get when 
>> I 
>> do `emacs -Q` looks quite good (it's DejaVu Sans Mono, BTW). 
>> But 
>> some way to visualise different types of information (similar 
>> to 
>> what most mode-line packages do), perhaps a few unicode symbols 
>> and a default way to put things at the right side of the mode 
>> line 
>> would, I think, go a long way to make the mode line look more 
>> modern.
>
> Wrt "a few Unicode symbols", do you have concrete proposals?

Not really, to be honest. What would be nice I think would be to 
have less 1980's-looking characters for the initial "U:---" 
appearing in the mode line. Two things that immediately come to 
mind (but that I personally don't like and wouldn't endorse) are 
of course a pad lock for read-only files and a floppy disk for an 
unmodified buffer. A floppy disk with the `error` face could then 
be used to indicate a modified buffer.

Personally, what I'd prefer are symbols that are abstract but 
don't really convey this 1980's feeling. For example, I kinda like 
the modified/unmodified indicators used in the screen shots at 
<https://github.com/dustinlacewell/eyeliner> (specifically, a 
neutral-coloured circle 🞅 for an unmodified buffer and a red 
circle with dot 🞊 for a modified buffer). I Haven't given any 
thought to any of the other indicators, though.

BTW, as a side note: I wouldn't mind if all the other indicators 
of the "U:---" part of the mode line would be zero for their 
default values; i.e,. don't display ":" unless the line endings 
are not unix-style LF, don't display the first "-", just display 
something for read-only buffers, etc.

Anyway, it was just a quick remark, I didn't give it much thought. 
If there's some interest, I wouldn't mind putting some ideas 
together, though.

-- 
Joost Kremers, PhD
Wuppertal University
Germanic Linguistics
Gaußstraße 20
42119 Wuppertal, Germany
+49 (0)202-439 3036

Re: Some developement questions

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: emacs-devel@gnu.org
> Date: Sun, 09 Sep 2018 22:07:08 +0200
> 
> Anyway, it was just a quick remark, I didn't give it much thought. 
> If there's some interest, I wouldn't mind putting some ideas 
> together, though.

I think we should consider such a feature, at least as an option if
not the default.  So if you have time to come up with some ideas,
please do, and thanks.

Re: Some developement questions

[Yuri Khan]

On Mon, Sep 10, 2018 at 3:15 AM Joost Kremers <joostkremers@fastmail.fm> wrote:

> > Wrt "a few Unicode symbols", do you have concrete proposals?
>
> Not really, to be honest. What would be nice I think would be to
> have less 1980's-looking characters for the initial "U:---"
> appearing in the mode line.
>
> BTW, as a side note: I wouldn't mind if all the other indicators
> of the "U:---" part of the mode line would be zero for their
> default values; i.e,. don't display ":" unless the line endings
> are not unix-style LF, don't display the first "-", just display
> something for read-only buffers, etc.

This is pretty much what I did to my mode line. I use:

* a U+2022 BULLET • if the buffer is visiting a file and modified, and
nothing otherwise;
* a U+1F512 LOCK 🔒 if it is visiting a file and read-only, and
nothing otherwise;
* a U+1F5AC SOFT SHELL FLOPPY DISK 🖬 if using DOS end-of-lines, or
U+2318 PLACE OF INTEREST SIGN ⌘ if using Mac end-of-lines, nothing if
using Unix end-of-lines, and a question mark ? otherwise.

I customize Ibuffer to show these same icons for modified and
read-only buffers, too.

I do not see value in seeing that e.g. a Dired, Help or Info buffer is
read-only; that is its natural state and so uninteresting. (Rather, I
should make them display a U+1F589 LOWER LEFT PENCIL 🖉 when *not*
read-only, e.g. in wdired-mode.)

Re: Some developement questions

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Mon, 10 Sep 2018 12:16:34 +0700
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> On Mon, Sep 10, 2018 at 3:15 AM Joost Kremers <joostkremers@fastmail.fm> wrote:
> 
> * a U+2022 BULLET • if the buffer is visiting a file and modified, and
> nothing otherwise;
> * a U+1F512 LOCK 🔒 if it is visiting a file and read-only, and
> nothing otherwise;
> * a U+1F5AC SOFT SHELL FLOPPY DISK 🖬 if using DOS end-of-lines, or
> U+2318 PLACE OF INTEREST SIGN ⌘ if using Mac end-of-lines, nothing if
> using Unix end-of-lines, and a question mark ? otherwise.

An image of a floppy disk is generally used for saving something to
disk, so I think it would be better to use it for the "modified"
marker, perhaps even with mouse click on it invoking save-buffer.

As for using these images for EOL format, I guess their mnemonic
significance is something to your personal experience, because I would
not have guessed why a floppy means DOS/Windows, what with GNU/Linux
nowadays being ubiquitous on small devices and PCs.  I don't see any
emoticons that strike me as appropriate, but perhaps we could design
small icons of our own instead.

Re: Some developement questions

[Yuri Khan]

On Mon, Sep 10, 2018 at 2:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > * a U+2022 BULLET • if the buffer is visiting a file and modified, and
> > nothing otherwise;
> > * a U+1F512 LOCK if it is visiting a file and read-only, and
> > nothing otherwise;
> > * a U+1F5AC SOFT SHELL FLOPPY DISK 🖬 if using DOS end-of-lines, or
> > U+2318 PLACE OF INTEREST SIGN ⌘ if using Mac end-of-lines, nothing if
> > using Unix end-of-lines, and a question mark ? otherwise.
>
> An image of a floppy disk is generally used for saving something to
> disk

I thought about it when choosing the character. The save icon uses the
3.5″ floppy disk (when it depicts a floppy disk at all), so I took the
5.25″ one to avoid ambiguity.

> so I think it would be better to use it for the "modified"
> marker, perhaps even with mouse click on it invoking save-buffer.

Well, most other editors use either an asterisk or a bullet. I didn’t
feel like inventing a new symbol usage for its own sake.

What does clicking the * do now? Just drop the “buffer modified” flag?
That feels dangerous.

> As for using these images for EOL format, I guess their mnemonic
> significance is something to your personal experience, because I would
> not have guessed why a floppy means DOS/Windows, what with GNU/Linux
> nowadays being ubiquitous on small devices and PCs.  I don't see any
> emoticons that strike me as appropriate, but perhaps we could design
> small icons of our own instead.

Well, DOS stands for Disk Operating System, so the DOS line end
convention gets a disk icon. Windows does not enter the picture
because it just inherited the DOS convention.

Nowadays, I think, floppy disks are not used, like, at all (except
possibly to file tax reports to the tax office, and even they now
provide a tax form web application), so the image of a floppy evokes
the thought of something ancient.


Point is, U:--- is a cryptic indicator that basically says “everything
is as you expect”, and 1\%*@ is a cryptic indicator that says “there
are so many things wrong, unusual or unsafe about this buffer”. These
are all important status items that could be made more informative
when in their abnormal, unsafe or attention-required state; or,
conversely, quieted down to silence when in the usual, safe and
expected state.

Re: Some developement questions

[hw]

Yuri Khan <yurivkhan@gmail.com> writes:

> On Mon, Sep 10, 2018 at 2:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
> [...]
>> An image of a floppy disk is generally used for saving something to
>> disk
>
> I thought about it when choosing the character. The save icon uses the
> 3.5″ floppy disk (when it depicts a floppy disk at all), so I took the
> 5.25″ one to avoid ambiguity.

Beginners may never have seen a floppy and only remote files.  A 3.5
vs. a 5.25" disk might mean nothing to them even when the disks are
clearly depicted.

What do you use for remote files?

Re: Some developement questions

[Michael Albinus]

hw <hw@adminart.net> writes:

> Beginners may never have seen a floppy and only remote files.  A 3.5
> vs. a 5.25" disk might mean nothing to them even when the disks are
> clearly depicted.
>
> What do you use for remote files?

A tramp?

SCNR, Michael.

Re: Some developement questions

[Yuri Khan]

On Mon, Sep 10, 2018 at 7:08 PM hw <hw@adminart.net> wrote:

> Beginners may never have seen a floppy and only remote files.  A 3.5
> vs. a 5.25" disk might mean nothing to them even when the disks are
> clearly depicted.

Yes. This is why some GTK icon themes no longer use the floppy disk
for the Save icon.

I don’t have a generic solution for character encodings and
end-of-line conventions. Might just keep displaying them as text, but
possibly spelled out in full (cp437, windows-1252, utf-8, instead of
D, *, U) and moved to a less prominent position.

> What do you use for remote files?

Nothing yet, as remote editing is not a thing I do in Emacs often.
U+1F5A7 THREE NETWORKED COMPUTERS 🖧 seems fitting, though.

Re: Some developement questions

[hw]

Yuri Khan <yurivkhan@gmail.com> writes:

> On Mon, Sep 10, 2018 at 7:08 PM hw <hw@adminart.net> wrote:
>
>> Beginners may never have seen a floppy and only remote files.  A 3.5
>> vs. a 5.25" disk might mean nothing to them even when the disks are
>> clearly depicted.
>
> Yes. This is why some GTK icon themes no longer use the floppy disk
> for the Save icon.

Maybe some icons from those could be used for the toolbar to make it
look more modern?

> I don’t have a generic solution for character encodings and
> end-of-line conventions. Might just keep displaying them as text, but
> possibly spelled out in full (cp437, windows-1252, utf-8, instead of
> D, *, U) and moved to a less prominent position.
>
>> What do you use for remote files?
>
> Nothing yet, as remote editing is not a thing I do in Emacs often.
> U+1F5A7 THREE NETWORKED COMPUTERS 🖧 seems fitting, though.

I'd like that.

Re: Some developement questions

[Yuri Khan]

On Tue, Sep 11, 2018 at 3:54 AM hw <hw@adminart.net> wrote:

> > Yes. This is why some GTK icon themes no longer use the floppy disk
> > for the Save icon.
>
> Maybe some icons from those could be used for the toolbar to make it
> look more modern?

They already are. If I turn tool-bar-mode on, the fifth button on the
toolbar displays a sheet of paper with a thick blue downward arrow.
(Of course, the point is not what exactly is depicted but the fact
that it uses the same icons as all the other GTK applications on the
same desktop.)

Re: Some developement questions

[hw]

Yuri Khan <yurivkhan@gmail.com> writes:

> On Tue, Sep 11, 2018 at 3:54 AM hw <hw@adminart.net> wrote:
>
>> > Yes. This is why some GTK icon themes no longer use the floppy disk
>> > for the Save icon.
>>
>> Maybe some icons from those could be used for the toolbar to make it
>> look more modern?
>
> They already are. If I turn tool-bar-mode on, the fifth button on the
> toolbar displays a sheet of paper with a thick blue downward arrow.

On my screen, Emacs 27.0.50 displays what resembles a 3.5" floppy which
is grayed out when I use 'emacs -q'.

> (Of course, the point is not what exactly is depicted but the fact
> that it uses the same icons as all the other GTK applications on the
> same desktop.)

I tried to verify this in gimp, but gimp doesn't show such a toolbar.

Hm, maybe it's because I compiled Emacs with Xaw rather than gtk?

Re: Some developement questions

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Mon, 10 Sep 2018 15:26:25 +0700
> Cc: Joost Kremers <joostkremers@fastmail.fm>, Emacs developers <emacs-devel@gnu.org>
> 
> > An image of a floppy disk is generally used for saving something to
> > disk
> 
> I thought about it when choosing the character. The save icon uses the
> 3.5″ floppy disk (when it depicts a floppy disk at all), so I took the
> 5.25″ one to avoid ambiguity.

I doubt if this subtlety will help, but that's me.

> > so I think it would be better to use it for the "modified"
> > marker, perhaps even with mouse click on it invoking save-buffer.
> 
> Well, most other editors use either an asterisk or a bullet. I didn’t
> feel like inventing a new symbol usage for its own sake.

So what is wrong with the asterisk we already have?

> What does clicking the * do now? Just drop the “buffer modified” flag?

Yes.

> > As for using these images for EOL format, I guess their mnemonic
> > significance is something to your personal experience, because I would
> > not have guessed why a floppy means DOS/Windows, what with GNU/Linux
> > nowadays being ubiquitous on small devices and PCs.  I don't see any
> > emoticons that strike me as appropriate, but perhaps we could design
> > small icons of our own instead.
> 
> Well, DOS stands for Disk Operating System, so the DOS line end
> convention gets a disk icon.

IME, rationalizations don't usually help with mnemonics.  If you need
to explain the mnemonic, you already lost.  The only non-trivial
mnemonics that are OK are those which are widely used by other apps.

> Point is, U:--- is a cryptic indicator that basically says “everything
> is as you expect”, and 1\%*@ is a cryptic indicator that says “there
> are so many things wrong, unusual or unsafe about this buffer”. These
> are all important status items that could be made more informative
> when in their abnormal, unsafe or attention-required state; or,
> conversely, quieted down to silence when in the usual, safe and
> expected state.

Personally, I disagree that they are "important".  I think they are of
secondary importance, as long as Emacs does what the users expect with
the respective features.  It is only when Emacs misbehaves that these
become more important, but I think problems with these particular ones
are well in the past.

So I think we shouldn't over-engineer this.  Using icons or emoji for
some of them is OK if it makes the indicators speak for themselves,
but we shouldn't IMO get out of our way to provide icons at any cost.

Re: Some developement questions

[hw]

Paul Eggert <eggert@cs.ucla.edu> writes:

> hw wrote:
>> My first step with 'emacs -q' would be to make the menu fonts larger.
>> As much as I like monospace fonts, the typewriter font used for the text
>> was *really ugly* even 30 years ago.  One look at Emacs with this font
>> might turn most people away before they start reading anything.
>
> This matches my perception too, when I show Emacs to students. Emacs
> starts up in monospace font and that looks sooooo 1980s.

not really

I don't mean to say that there's something wrong with monospace fonts.
I prefer them for most things because they're monospace.

We should ask a designer for some ideas about how to make Emacs look
better.

Re: Some developement questions

[Ergus]

On 6 September 2018 03:11:08 CEST, hw <hw@adminart.net> wrote:
>Paul Eggert <eggert@cs.ucla.edu> writes:
>
>> hw wrote:
>>> My first step with 'emacs -q' would be to make the menu fonts
>larger.
>>> As much as I like monospace fonts, the typewriter font used for the
>text
>>> was *really ugly* even 30 years ago.  One look at Emacs with this
>font
>>> might turn most people away before they start reading anything.
>>
>> This matches my perception too, when I show Emacs to students. Emacs
>> starts up in monospace font and that looks sooooo 1980s.
>
>not really
>
>I don't mean to say that there's something wrong with monospace fonts.
>I prefer them for most things because they're monospace.
>
>We should ask a designer for some ideas about how to make Emacs look
>better.

We can also see what have succeded before, for example packages like powerline or fonts like Hacks or Cantarell. They have succeded independently of operative systems, editors or tools. The default color scheme, graphical or tui. These are the kind of initial things I wanted to ask to the new user if there is not config file. If he dont want any help can get the defaults, else he could choose and the first impresion could be much much better.

Re: Some developement questions

[hw]

Ergus <spacibba@aol.com> writes:

> On 6 September 2018 03:11:08 CEST, hw <hw@adminart.net> wrote:
>>Paul Eggert <eggert@cs.ucla.edu> writes:
>>
>>> hw wrote:
>>>> My first step with 'emacs -q' would be to make the menu fonts
>>larger.
>>>> As much as I like monospace fonts, the typewriter font used for the
>>text
>>>> was *really ugly* even 30 years ago.  One look at Emacs with this
>>font
>>>> might turn most people away before they start reading anything.
>>>
>>> This matches my perception too, when I show Emacs to students. Emacs
>>> starts up in monospace font and that looks sooooo 1980s.
>>
>>not really
>>
>>I don't mean to say that there's something wrong with monospace fonts.
>>I prefer them for most things because they're monospace.
>>
>>We should ask a designer for some ideas about how to make Emacs look
>>better.
>
> We can also see what have succeded before, for example packages like
> powerline or fonts like Hacks or Cantarell.

I never used these fonts, and what is powerline?

> They have succeded independently of operative systems, editors or
> tools. The default color scheme, graphical or tui. These are the kind
> of initial things I wanted to ask to the new user if there is not
> config file. If he dont want any help can get the defaults, else he
> could choose and the first impresion could be much much better.

That's one of the things I've been thinking about when trying to figure
out why 'emacs -q', creating an X frame, is so ugly.  I thought it might
look much better with different colours, but that's just me as I don't
like black on white much on monitors.

What also makes it look ugly is the toolbar and the menu.  Turning those
off by default might not be the best idea, though.

Having the user pick colors initially is probably difficult:  I need to
see how it looks when I pick colors, so I try them out.  Asking someone
what colours they would like and then using them probably won't work.

Preparing preset colour themes (skins) might work.  You can show a
preview image and let the user pick one.  That could include font
selections.

Re: Some developement questions

[Phillip Lord]

hw <hw@adminart.net> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>> Personally, I would like to ditch all the "how to move around" with
>> keys stuff -- this scares most people to hell, because they think that
>> they need to learn this to do something that they already know how to
>> do these things.
>
> right
>
> The current tutorial is more suited to drive people away than anything
> else.
>
> Who knows what a META or an EDIT key is?  And who cares?  Even after
> almost 30 years of getting used to them, I'm finding notations like 'C-x
> ret f' or 'M-w' very confusing.  How does that belong into a tutorial?


I think we need to introduce this notation, because people will see it
everywhere; but we should not depend on it.


> People might use C-v to copy something rather than to scroll.  They will
> use the cursor keys and PgUp and PgDown to move around.

There is a separate question here about making Emacs better
out-of-the-box. One of the things that might improve things is to turn
CUA mode on by default for instance.



> Your tutorial even explains what Emacs is and gives some history.  That
> is a much more welcoming start.

Thank you!

>> In terms of advanced issues, my thought was to enable tutorial
>> extensions to go into ELPA and then have a navigational structure.
>
> Maybe several tutorials would be better, like one covering what Emacs is
> (nowadays that may be a good idea), one covering the first steps and
> others covering the installation of packages after users have aquired
> some understanding of what packages are.


There is also the practical reality that the Emacs update cycle is
relatively slow. A tutorial on ELPA could be updated out of that cycle.

Phil

RE: Some developement questions

[Drew Adams]

> One of the things that might improve things is to turn
> CUA mode on by default for instance.

Please, no. But we should turn on `delete-selection-mode' by default.

(Any yes, each of these has been discussed multiple times over the years. It took decades to finally get `transient-mark-mode' turned on by default. I'm still hoping for `delete-selection-mode' before the Rapture arrives. ;-)

Re: Some developement questions

[Eli Zaretskii]

> Date: Thu, 6 Sep 2018 07:24:27 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com, emacs-devel@gnu.org
> 
> we should turn on `delete-selection-mode' by default.

I don't think we can, because it gets in the way when editing code.
We could turn it on in text modes, perhaps.

But anyway, we already have non-annoying portions of
delete-selection-mode turned on by default (shift-selection etc.).

Re: Some developement questions

[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. ]]]

Please don't turn on delete-selection-mode.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 6 Sep 2018 07:24:27 -0700 (PDT)
>> From: Drew Adams <drew.adams@oracle.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com, emacs-devel@gnu.org
>> 
>> we should turn on `delete-selection-mode' by default.
>
> I don't think we can, because it gets in the way when editing code.
> We could turn it on in text modes, perhaps.
>
> But anyway, we already have non-annoying portions of
> delete-selection-mode turned on by default (shift-selection etc.).

I'm finding that weird and annoying, can it be turned off?  It sometimes
happens by accident.

If it was on by default, I'd probably disable `delete-selection-mode'.
I rather have something typed than a selection replaced by accident, and
accident would be the only case in which the selection would be
replaced.

How does it get in the way when editing code?  Just don't replace the
selection, or disable the mode?

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: Drew Adams <drew.adams@oracle.com>,  spacibba@aol.com,  emacs-devel@gnu.org,  phillip.lord@russet.org.uk
> Date: Fri, 07 Sep 2018 10:25:36 +0200
> 
> > But anyway, we already have non-annoying portions of
> > delete-selection-mode turned on by default (shift-selection etc.).
> 
> I'm finding that weird and annoying, can it be turned off?  It sometimes
> happens by accident.

I think we can, but if you don't tell what exactly is annoying, I
don't see how can we advise you about turning that off.

> How does it get in the way when editing code?  Just don't replace the
> selection, or disable the mode?

I explained that in followup messages.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: Drew Adams <drew.adams@oracle.com>,  spacibba@aol.com,  emacs-devel@gnu.org,  phillip.lord@russet.org.uk
>> Date: Fri, 07 Sep 2018 10:25:36 +0200
>> 
>> > But anyway, we already have non-annoying portions of
>> > delete-selection-mode turned on by default (shift-selection etc.).
>> 
>> I'm finding that weird and annoying, can it be turned off?  It sometimes
>> happens by accident.
>
> I think we can, but if you don't tell what exactly is annoying, I
> don't see how can we advise you about turning that off.

I was referring to making a selection with shift.  I'm not sure what the
etc. is.

>> How does it get in the way when editing code?  Just don't replace the
>> selection, or disable the mode?
>
> I explained that in followup messages.

Yes, I saw that only later, sorry.

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  phillip.lord@russet.org.uk,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 07 Sep 2018 15:22:06 +0200
> 
> >> I'm finding that weird and annoying, can it be turned off?  It sometimes
> >> happens by accident.
> >
> > I think we can, but if you don't tell what exactly is annoying, I
> > don't see how can we advise you about turning that off.
> 
> I was referring to making a selection with shift.  I'm not sure what the
> etc. is.

From the Emacs manual:

     To turn off shift-selection, set ‘shift-select-mode’ to ‘nil’.  Doing
  so does not disable setting the mark via mouse commands.

RE: Some developement questions

[Drew Adams]

> > I was referring to making a selection with shift. 
> 
> From the Emacs manual:
>      To turn off shift-selection, set ‘shift-select-mode’ to ‘nil’.  Doing
>      so does not disable setting the mark via mouse commands.

And besides the manual (recommended) you can discover this
(if you know that it is called "shift selection") using the menu:

1. Options > Customize Emacs > Specific Option...
2. Type `shift TAB' (or `shi TAB') to complete to `shift-selection-mode'.
3. Hit `RET'.

Or more directly, `M-x customize-option shi TAB RET'.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  phillip.lord@russet.org.uk,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Fri, 07 Sep 2018 15:22:06 +0200
>> 
>> >> I'm finding that weird and annoying, can it be turned off?  It sometimes
>> >> happens by accident.
>> >
>> > I think we can, but if you don't tell what exactly is annoying, I
>> > don't see how can we advise you about turning that off.
>> 
>> I was referring to making a selection with shift.  I'm not sure what the
>> etc. is.
>
>>From the Emacs manual:
>
>      To turn off shift-selection, set ‘shift-select-mode’ to ‘nil’.  Doing
>   so does not disable setting the mark via mouse commands.

Thanks!  I really need to read the manual again ...

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
> Date: Fri, 07 Sep 2018 23:29:19 +0200
> 
> >>From the Emacs manual:
> >
> >      To turn off shift-selection, set ‘shift-select-mode’ to ‘nil’.  Doing
> >   so does not disable setting the mark via mouse commands.
> 
> Thanks!  I really need to read the manual again ...

While re-reading the manual from time to time is a good idea (and we
present an opportunity to do that whenever a new Emacs version is
about to be released, at which point we ask volunteers to proof-read
the manual), you don't really need to read it to find stuff relevant
to some subject.  Instead, use the 'i' command (with completion) to
quickly find the places discussing that subject.  In this case, I
typed "i shift-sel TAB" and was presented with a single completion;
typing RET then landed me in a short section which had the above text
in it.

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
>> Date: Fri, 07 Sep 2018 23:29:19 +0200
>> 
>> >>From the Emacs manual:
>> >
>> >      To turn off shift-selection, set ‘shift-select-mode’ to ‘nil’.  Doing
>> >   so does not disable setting the mark via mouse commands.
>> 
>> Thanks!  I really need to read the manual again ...
>
> While re-reading the manual from time to time is a good idea (and we
> present an opportunity to do that whenever a new Emacs version is
> about to be released, at which point we ask volunteers to proof-read
> the manual),

Hm.  I've started reading it again and was thinking about the changes
between versions.  I could as well proof read it, but wich version
should I read?

> you don't really need to read it to find stuff relevant
> to some subject.  Instead, use the 'i' command (with completion) to
> quickly find the places discussing that subject.  In this case, I
> typed "i shift-sel TAB" and was presented with a single completion;
> typing RET then landed me in a short section which had the above text
> in it.

That's cool.  It's been so long that I read it that I want to read it
again.

BTW, when I was reading it, I was wishing I could open links in other
buffers or windows like I would open another tab in a web brower.  Is
there some way to do something like that?  It can make it easier to keep
track of the history as you can break up a history tree into something
far more navigable by using tabs as anchors of branches (that have
branches, etc.).

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  phillip.lord@russet.org.uk,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Sat, 08 Sep 2018 15:12:05 +0200
> 
> Hm.  I've started reading it again and was thinking about the changes
> between versions.  I could as well proof read it, but wich version
> should I read?

The latest one, which you get if you build the master branch of the
Emacs repository.

> BTW, when I was reading it, I was wishing I could open links in other
> buffers or windows like I would open another tab in a web brower.  Is
> there some way to do something like that?

Not that I know of.  Perhaps you'd like to write a patch to that
effect?

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  phillip.lord@russet.org.uk,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Sat, 08 Sep 2018 15:12:05 +0200
>> 
>> Hm.  I've started reading it again and was thinking about the changes
>> between versions.  I could as well proof read it, but wich version
>> should I read?
>
> The latest one, which you get if you build the master branch of the
> Emacs repository.

Thanks, I cloned it tonight and have it running.  Can I use that version
pretty much normally, including gnus, or are there currently known bugs
which make that a bad idea?

>> BTW, when I was reading it, I was wishing I could open links in other
>> buffers or windows like I would open another tab in a web brower.  Is
>> there some way to do something like that?
>
> Not that I know of.  Perhaps you'd like to write a patch to that
> effect?

Let me start small by reading the manual again and working my way up
from there ...

Re: Some developement questions

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
> Date: Mon, 10 Sep 2018 13:52:58 +0200
> 
> > The latest one, which you get if you build the master branch of the
> > Emacs repository.
> 
> Thanks, I cloned it tonight and have it running.  Can I use that version
> pretty much normally, including gnus, or are there currently known bugs
> which make that a bad idea?

There are no known serious bugs, but if your usage patterns are
unusual, you may bump into problems no one reported yet.

The master branch might become broken by some commit, but that is
usually gets fixed within several hours.  So if you incidentally
update your repository before a bug is fixed, just back up to a
previous commit and wait for the problem to be fixed.

> >> BTW, when I was reading it, I was wishing I could open links in other
> >> buffers or windows like I would open another tab in a web brower.  Is
> >> there some way to do something like that?
> >
> > Not that I know of.  Perhaps you'd like to write a patch to that
> > effect?
> 
> Let me start small by reading the manual again and working my way up
> from there ...

In the meantime, it turned out I was mistaken, and we already have
such a feature ;-)

Re: Some developement questions

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
>> Date: Mon, 10 Sep 2018 13:52:58 +0200
>> 
>> > The latest one, which you get if you build the master branch of the
>> > Emacs repository.
>> 
>> Thanks, I cloned it tonight and have it running.  Can I use that version
>> pretty much normally, including gnus, or are there currently known bugs
>> which make that a bad idea?
>
> There are no known serious bugs, but if your usage patterns are
> unusual, you may bump into problems no one reported yet.

Cool, I'll try it out for regular usage.  I don't think I'm doing
anything particularly unusual.

> The master branch might become broken by some commit, but that is
> usually gets fixed within several hours.  So if you incidentally
> update your repository before a bug is fixed, just back up to a
> previous commit and wait for the problem to be fixed.

I could just leave it as it is now unless there were many changes to the
documentation being made.

>> >> BTW, when I was reading it, I was wishing I could open links in other
>> >> buffers or windows like I would open another tab in a web brower.  Is
>> >> there some way to do something like that?
>> >
>> > Not that I know of.  Perhaps you'd like to write a patch to that
>> > effect?
>> 
>> Let me start small by reading the manual again and working my way up
>> from there ...
>
> In the meantime, it turned out I was mistaken, and we already have
> such a feature ;-)

Info-follow-nearest-node?  It comes pretty close :)

Re: Some developement questions

[Charles A. Roelli]

> BTW, when I was reading it, I was wishing I could open links in other
> buffers or windows like I would open another tab in a web brower.  Is
> there some way to do something like that?  It can make it easier to keep
> track of the history as you can break up a history tree into something
> far more navigable by using tabs as anchors of branches (that have
> branches, etc.).

With point over a link, try "M-n RET".  That will clone the info
buffer, then follow the link in the clone.

Re: Some developement questions

[Juri Linkov]

> BTW, when I was reading it, I was wishing I could open links in other
> buffers or windows like I would open another tab in a web brower.  Is
> there some way to do something like that?  It can make it easier to keep
> track of the history as you can break up a history tree into something
> far more navigable by using tabs as anchors of branches (that have
> branches, etc.).

Here is what could help you to emulate web browser tabs:

(define-key Info-mode-map [C-down-mouse-1]
  (lambda (click)
    (interactive "e")
    (mouse-set-point click)
    (Info-follow-nearest-node 'fork)))

Re: Some developement questions

[hw]

Juri Linkov <juri@linkov.net> writes:

>> BTW, when I was reading it, I was wishing I could open links in other
>> buffers or windows like I would open another tab in a web brower.  Is
>> there some way to do something like that?  It can make it easier to keep
>> track of the history as you can break up a history tree into something
>> far more navigable by using tabs as anchors of branches (that have
>> branches, etc.).
>
> Here is what could help you to emulate web browser tabs:
>
> (define-key Info-mode-map [C-down-mouse-1]
>   (lambda (click)
>     (interactive "e")
>     (mouse-set-point click)
>     (Info-follow-nearest-node 'fork)))

Thanks to everyone for their suggestions!


I've written a function to use X frames when I follow another branch:


(defun my-new-info-tab ()
  (interactive)
  (with-current-buffer (clone-buffer)
    (Info-follow-nearest-node)
    (display-buffer-pop-up-frame (current-buffer) nil)))


Is there a way to make it so that the frame used to display a branch
deletes itself when the cloned buffer it has been created for is killed?

RE: Some developement questions

[Drew Adams]

> Is there a way to make it so that the frame used to display a branch
> deletes itself when the cloned buffer it has been created for is killed?

(This thread is all over the place now...)

I use ` kill-buffer-and-its-windows', defined in `misc-cmds.el':

https://www.emacswiki.org/emacs/download/misc-cmds.el

I do this:
(remap-command 'kill-buffer 'kill-buffer-and-its-windows global-map)

And I use this, from `frame-cmds.el':

;; If WINDOW is the only one in its frame, `delete-frame'.
(defadvice delete-window (around delete-frame-if-one-win activate)
  "If WINDOW is the only one in its frame, then `delete-frame' too."
  (if (fboundp 'with-selected-window)   ; Emacs 22+
      (with-selected-window
          (or (ad-get-arg 0)  (selected-window))
        (if (one-window-p t) (delete-frame) ad-do-it))
    (save-current-buffer
      (select-window (or (ad-get-arg 0)  (selected-window)))
      (if (one-window-p t) (delete-frame) ad-do-it))))

https://www.emacswiki.org/emacs/download/frame-cmds.el

(Be aware too that `q' in Info does not kill the buffer. Use `C-x k'
or similar if you really want to kill the buffer.)

RE: Some developement questions

[Drew Adams]

> > BTW, when I was reading it, I was wishing I could open links in other
> > buffers or windows like I would open another tab in a web brower.  Is
> > there some way to do something like that?  It can make it easier to keep
> > track of the history as you can break up a history tree into something
> > far more navigable by using tabs as anchors of branches (that have
> > branches, etc.).
> 
> With point over a link, try "M-n RET".  That will clone the info
> buffer, then follow the link in the clone.

Yes, good one. `M-n' clones the buffer, showing the same node,
with point in the same position (so still on top of the link). Then
`RET' follows the link in that cloned buffer.

You can also (instead) use `C-u RET'. `RET' is bound to 
`Info-follow-nearest-node', and with a prefix arg it follows the
link in a new (cloned) Info buffer named for that node.

The difference is that with `M-n RET' the cloned buffer will have
the same name as the original, but with `<N>' appended (e.g.
`*info*<2>'), whereas with `C-u RET' the cloned buffer will have
the name of the link you followed, prefixed by `info-' (e.g.
`*info-Screen*' if the node you followed is `Screen').

The prefix-arg thing works with some other Info navigation
commands too. E.g. `C-u g Screen' goes to node `Screen' in a
new, cloned buffer, `C-u f Emacs Lisp' follows an xref to the
Emacs Lisp manual in a cloned buffer. (It doesn't work with
`l', `r', `n', `p', `u', however. (Maybe it should.)

RE: Some developement questions

[Drew Adams]

> The prefix-arg thing works with some other Info navigation
> commands too. E.g. `C-u g Screen' goes to node `Screen' in a
> new, cloned buffer, `C-u f Emacs Lisp' follows an xref to the
> Emacs Lisp manual in a cloned buffer. (It doesn't work with
> `l', `r', `n', `p', `u', however. (Maybe it should.)

FWIW, in my own code I've added this to `n', `p', `u', `l', `r', `d', `]',
and `['. So it's now available with those keys, plus `g', `f', and `m'.

https://www.emacswiki.org/emacs/download/info%2b.el

This could be added to Emacs, if someone is interested. The
change is trivial.

One thing I changed, which is peripherally related:

Vanilla Emacs wraps the body of this and similar functions with
`save-window-excursion'. I think that's wrong. It's problematic,
for example, if you use a dedicated window for the new, cloned
buffer or when it is otherwise shown in a separate frame.

(defun Info-next (&optional fork)
  "Go to the next node of this node.
If FORK is non-nil (interactively with a prefix arg), show the node in
a new Info buffer.
If FORK is a string, it is the name to use for the new buffer."
  (interactive "P")
  (unless (derived-mode-p 'Info-mode) (switch-to-buffer "*info*"))
  (Info-goto-node (Info-extract-pointer "next") fork))

But maybe someone can set me straight about this: let me know
why the `save-window-excursion' was there and what a better fix
would be than just removing it. I haven't yet noticed any problem
from removing it.

I see that in Emacs 23 the code used `pop-to-buffer' here, and
that was changed to `switch-to-buffer'. It's also not clear to me
why that change was made. (I left `switch-to-buffer' in my version,
but it's not clear that "the selected window" would always be
used to display the new buffer.)

RE: Some developement questions

[Drew Adams]

> accident would be the only case in which the selection would be
> replaced.

C-y to yank a replacement, possibly followed by M-y to get different
replacements.

And if, like me, you have a key that yanks the secondary selection,
yank it to replace the region.

It's no different from what you do now, except that you precede
such operations by explicit C-w to first delete the region.

Re: Some developement questions

[hw]

Drew Adams <drew.adams@oracle.com> writes:

>> accident would be the only case in which the selection would be
>> replaced.
>
> C-y to yank a replacement, possibly followed by M-y to get different
> replacements.

That doesn't replace the selection but disables it and yanks --- and it
would only happen by accident because I don't do such weird things.
You're probably using a different setting.

> And if, like me, you have a key that yanks the secondary selection,
> yank it to replace the region.
>
> It's no different from what you do now, except that you precede
> such operations by explicit C-w to first delete the region.

It is different because the way you do something makes a difference.

The result may be identical until you hit the wrong key and something
gets replaced or de-selected by mistake.  It's ok if you want that; I'd
rather have strict-mode.

I don't want anything to happen to a selection just because I pressed
the wrong key.  I also place brackets where they aren't strictly needed
when programming and do other stuff like that because it explicitly says
what I wanted and prevents misunderstandings.  Having selections
randomly replaced or disabled is like omitting the brackets and stuff:
it makes things difficult, confusing and errorenous.

RE: Some developement questions

[Drew Adams]

>>>> accident would be the only case in which the selection would be replaced.
>> >
>> > C-y to yank a replacement, possibly followed by M-y to get different
> > replacements.
> 
> That doesn't replace the selection but disables it and yanks --- and it
> would only happen by accident because I don't do such weird things.
> You're probably using a different setting.

Works for me, including from `emacs -Q'. Perhaps you are using a different setting.

1. emacs -Q

2. M-x delete-selection-mode ; Turn it on

3. Select a word in the first line of buffer *scratch*, say `The', and then `M-w' to copy it to the kill-ring. Do that a few times, with different words, say `buffer', `is', and `for'. So the kill-ring is populated with a few kills.

4. Select some text in the second line.

5. `C-y' replaces that selected text with `for'. `M-y' replaces `for' with `is'. `M-y' replaces `is' with `buffer'.

> > And if, like me, you have a key that yanks the secondary selection,
> > yank it to replace the region.

FWIW, that's is a frequent use case for me. Select some text, then `C-M-y' to replace it with the secondary selection. Do that wherever, whenever. Replace anything with the same bit of text. (Or you can do the same kind of thing using a register instead of the secondary selection.)

> > It's no different from what you do now, except that you precede
> > such operations by explicit C-w to first delete the region.
> 
> It is different because the way you do something makes a difference.

The result is the same; that was the point: With `delete-selection-mode' you can easily replace selected text with other text. The way you do that without `d-s-mode' is the same, except you explicitly use `C-w' to kill the text before yanking.

That's the only difference, except that `d-s-mode' doesn't always kill (`C-w'). What it does depends on the command used when the region is active, and that behavior is configurable.

> The result may be identical until you hit the wrong key and something
> gets replaced or de-selected by mistake.  It's ok if you want that; I'd
> rather have strict-mode.
> 
> I don't want anything to happen to a selection just because I pressed
> the wrong key. 

Nor do I. Who does?

Have you never hit `C-w' by mistake, i.e., as "the wrong key"? Did you get excited about that, or did you just undo the mistake?

> Having selections randomly replaced or disabled ... makes things difficult, confusing and errorenous.

Hyperbole. `delete-selection-mode' does not randomly replace or disable selections.

You're not used to it perhaps. And you don't like it. Leave it at that. People are different. It's no harder for you to turn `d-s-mode' off in your init file than it is for me to turn it on. This discussion is about what the default behavior should be.

RE: Some developement questions

[Drew Adams]

> > we should turn on `delete-selection-mode' by default.
> 
> I don't think we can, because it gets in the way when editing code.

How so? It doesn't get in my way. Quite the contrary - I appreciate
it for editing code.

Please give a recipe, if you're really interested in discussing this
again. And in that case, please start a new thread for it.

> We could turn it on in text modes, perhaps.
> 
> But anyway, we already have non-annoying portions of
> delete-selection-mode turned on by default (shift-selection etc.).

Not the same thing at all. In the wider world, behaviors of/like
both `delete-selection-mode' and shift-selection are on by
default (and they are typically all that is available).

Re: Some developement questions

[Eli Zaretskii]

> Date: Thu, 6 Sep 2018 07:56:13 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: hw@adminart.net, spacibba@aol.com, emacs-devel@gnu.org,
>         phillip.lord@russet.org.uk
> 
> > > we should turn on `delete-selection-mode' by default.
> > 
> > I don't think we can, because it gets in the way when editing code.
> 
> How so? It doesn't get in my way. Quite the contrary - I appreciate
> it for editing code.
> 
> Please give a recipe

Type "C-x C-x", then some letter: puff! the whole region is gone.
This could be okay in text modes, but in code buffers users generally
don't replace regions with single letters.

Re: Some developement questions

[Clément Pit-Claudel]

On 2018-09-06 14:38, Eli Zaretskii wrote:
>> Date: Thu, 6 Sep 2018 07:56:13 -0700 (PDT)
>> From: Drew Adams <drew.adams@oracle.com>
>> Cc: hw@adminart.net, spacibba@aol.com, emacs-devel@gnu.org,
>>         phillip.lord@russet.org.uk
>>
>>>> we should turn on `delete-selection-mode' by default.
>>>
>>> I don't think we can, because it gets in the way when editing code.
>>
>> How so? It doesn't get in my way. Quite the contrary - I appreciate
>> it for editing code.
>>
>> Please give a recipe
> 
> Type "C-x C-x", then some letter: puff! the whole region is gone.
> This could be okay in text modes, but in code buffers users generally
> don't replace regions with single letters.

Funny, I have code in my config for exactly this case.  I use delete-selection-mode, and I invert the meaning of C-u for C-x C-x (a plain C-x C-x doesn't make the region active, and pressing C-u C-x C-x does.

Clément.

Re: Some developement questions

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 6 Sep 2018 15:27:30 -0400
> 
> > Type "C-x C-x", then some letter: puff! the whole region is gone.
> > This could be okay in text modes, but in code buffers users generally
> > don't replace regions with single letters.
> 
> Funny, I have code in my config for exactly this case.  I use delete-selection-mode, and I invert the meaning of C-u for C-x C-x (a plain C-x C-x doesn't make the region active, and pressing C-u C-x C-x does.

That's fine, but I don't think we can make this the default behavior.

RE: Some developement questions

[Drew Adams]

> > > > we should turn on `delete-selection-mode' by default.
> > >
> > > I don't think we can, because it gets in the way when editing code.
> >
> > How so? It doesn't get in my way. Quite the contrary - I appreciate
> > it for editing code. Please give a recipe
> 
> Type "C-x C-x", then some letter: puff! the whole region is gone.
> This could be okay in text modes, but in code buffers users generally
> don't replace regions with single letters.

Just don't do that.

Not a problem at all. Never been a problem for me.
And if I somehow did that by mistake I'd just undo it.

It's equivalent to your doing this without `delete-selection-mode':
C-x C-x M-w, then some letter

I see zero difference between editing code and editing plain prose,
in this regard. In both cases the selection can be replaced by typing,
and that's a plus, not a minus. Nothing obliges you to replace the
region. If you want just to swap point and mark, without acting on
the region, then just C-g.

That C-x C-x activates the region is what's behind this. If you don't
want the region to be active then C-g after C-x C-x. Typing a letter
is no different from using M-w: you're acting on the active region.

C-x C-x is no longer just swapping point and mark. That ship sailed
long ago, when we turned on `transient-mark-mode' by default.
Now it also activates the region, and anyone who doesn't want it
activated can just use C-g to deactivate it.

Re: Some developement questions

[Eli Zaretskii]

> Date: Thu, 6 Sep 2018 16:47:07 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: hw@adminart.net, spacibba@aol.com, phillip.lord@russet.org.uk,
>         drew.adams@oracle.com, emacs-devel@gnu.org
> 
> > Type "C-x C-x", then some letter: puff! the whole region is gone.
> > This could be okay in text modes, but in code buffers users generally
> > don't replace regions with single letters.
> 
> Just don't do that.

It's a way too important a paradigm not to use it.

> Not a problem at all. Never been a problem for me.
> And if I somehow did that by mistake I'd just undo it.

I didn't say it's a catastrophe, I said it gets in the way.  IOW, it's
a nuisance (IME).

> It's equivalent to your doing this without `delete-selection-mode':
> C-x C-x M-w, then some letter

No, that doesn't delete the region.  Perhaps you meant C-w.  And in
any case, the fact that I typed C-w already says that I didn't just
want to return to the marked place.  So I don't think this analogy is
valid.

> C-x C-x is no longer just swapping point and mark. That ship sailed
> long ago, when we turned on `transient-mark-mode' by default.
> Now it also activates the region, and anyone who doesn't want it
> activated can just use C-g to deactivate it.

Like I said: it gets in the way.  You disagree, which is fine, so you
can enable delete-selection-mode in your configuration.  I tried that
once, and quickly disabled it back, due to the above (and similar
issues).

Re: Some developement questions

[hw]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> hw <hw@adminart.net> writes:
>
>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>>
>>> Personally, I would like to ditch all the "how to move around" with
>>> keys stuff -- this scares most people to hell, because they think that
>>> they need to learn this to do something that they already know how to
>>> do these things.
>>
>> right
>>
>> The current tutorial is more suited to drive people away than anything
>> else.
>>
>> Who knows what a META or an EDIT key is?  And who cares?  Even after
>> almost 30 years of getting used to them, I'm finding notations like 'C-x
>> ret f' or 'M-w' very confusing.  How does that belong into a tutorial?
>
>
> I think we need to introduce this notation, because people will see it
> everywhere; but we should not depend on it.

How would you not depend on it?

What confuses me is that C is so easy to confuse with c or C, etc.  I'd
find 'Control-x ret f' or 'ESC-w' much easier to read.

>> People might use C-v to copy something rather than to scroll.  They will
>> use the cursor keys and PgUp and PgDown to move around.
>
> There is a separate question here about making Emacs better
> out-of-the-box. One of the things that might improve things is to turn
> CUA mode on by default for instance.

What does that do?

>> Your tutorial even explains what Emacs is and gives some history.  That
>> is a much more welcoming start.
>
> Thank you!
>
>>> In terms of advanced issues, my thought was to enable tutorial
>>> extensions to go into ELPA and then have a navigational structure.
>>
>> Maybe several tutorials would be better, like one covering what Emacs is
>> (nowadays that may be a good idea), one covering the first steps and
>> others covering the installation of packages after users have aquired
>> some understanding of what packages are.
>
>
> There is also the practical reality that the Emacs update cycle is
> relatively slow. A tutorial on ELPA could be updated out of that cycle.

Such tutorials should be shipped with Emacs when they are available.

Re: Some developement questions

[Ergus]

On Tue, Sep 04, 2018 at 02:58:53PM +0200, Phillip Lord wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> My hope was to do something a bit more intelligent with it -- with some
>>> screen shots and rich text, as well as highlighting for menu items, so I
>>> wrote it in org-mode. Alas I haven't had the time to actually integrate
>>> it into Emacs.
>>>
>>> https://raw.githubusercontent.com/phillord/emacs-tutorial/master/tutorial.org
>>>
>>> If someone has the time to do the integration it's nearly ready to
>>> go. To my mind, updating the tutorial would be a good thing just because
>>> it would give the impression that it is updateable, rather than a thing
>>> set in stone.
>>
>> Thanks.  That tutorial looks like a somewhat expanded version of our
>> TUTORIAL; e.g., it has almost the same scope in terms of Emacs
>> features.  I thought, perhaps mistakenly, that we were talking about a
>> tutorial for the next step -- for those who have read the original
>> TUTORIAL and want to learn about more advanced issues related to text
>> editing.
>
>It covers some never stuff, but yes, it is fairly similar. Personally, I
>would like to ditch all the "how to move around" with keys stuff -- this
>scares most people to hell, because they think that they need to learn
>this to do something that they already know how to do these things.
>
I thing mentioning that move with arrows + keybindings is possible and
would be a more elegant approach. Because some users know how to move in
bash or will find it interesting/useful to know that C-a, C-e, C-d, C-j,
C-i and so on are useful also in bash. (Also to tribute the history a
little bit). For example, vim has its terrible bindings, they mention in
the tutorial and some people like them because they feel more geek using
them.

Some of them are easier to access in some keyboards (C-d in my case for
example). So maybe a table could have two columns with the
traditional and the "modern" alternative. And let the user choose (or mix).

>In terms of advanced issues, my thought was to enable tutorial
>extensions to go into ELPA and then have a navigational structure. The
>current tutorial for the even trivial reason that it's flat.
>
The tutorial should mention how to add packages or at least introduce
the concepts (package, repository, extension, elpa, melpa), and a bit
less of history. But just at the very end in order to create some
expectations in the new user.

Even if it is only to mention as an approximation, and let the
practical things in the manual.

Personally I don't like the navigational structure because the simpler
structure is better for the tutorial until the user can do the basics. A
tutorial should feel like being inside emacs already as everyday.

>Phil
>

Re: Some developement questions

[Phillip Lord]

Ergus <spacibba@aol.com> writes:

> On Tue, Sep 04, 2018 at 02:58:53PM +0200, Phillip Lord wrote:

>>> Thanks.  That tutorial looks like a somewhat expanded version of our
>>> TUTORIAL; e.g., it has almost the same scope in terms of Emacs
>>> features.  I thought, perhaps mistakenly, that we were talking about a
>>> tutorial for the next step -- for those who have read the original
>>> TUTORIAL and want to learn about more advanced issues related to text
>>> editing.
>>
>>It covers some never stuff, but yes, it is fairly similar. Personally, I
>>would like to ditch all the "how to move around" with keys stuff -- this
>>scares most people to hell, because they think that they need to learn
>>this to do something that they already know how to do these things.
>>
> I thing mentioning that move with arrows + keybindings is possible and
> would be a more elegant approach. Because some users know how to move in
> bash or will find it interesting/useful to know that C-a, C-e, C-d, C-j,
> C-i and so on are useful also in bash.

This is backwards, I think. It's an Emacs tutorial not a bash one.


> Some of them are easier to access in some keyboards (C-d in my case for
> example). So maybe a table could have two columns with the
> traditional and the "modern" alternative. And let the user choose (or mix).

No. By definition, a tutorial is about teaching people things. People
who need a tutorial are not in a place to make a sensible decision; we
need to offer one solution, not a choice. People can choose later.


Phil

Re: Some developement questions

[hw]

Ergus <spacibba@aol.com> writes:

> The tutorial should mention how to add packages or at least introduce
> the concepts (package, repository, extension, elpa, melpa), and a bit
> less of history. But just at the very end in order to create some
> expectations in the new user.

"A tutorial is a method of transferring knowledge and may be used as a
part of a learning process. More interactive and specific than a book or
a lecture, a tutorial seeks to teach by example and supply the
information to complete a certain task."[1]

Introducing concepts (and their history) seems more suited for a
manual.  Tutorials would accompany the manual and explain in detail how
to do something introdcued in the manual.


[1]: https://en.wikipedia.org/wiki/Tutorial

> Even if it is only to mention as an approximation, and let the
> practical things in the manual.

Wouldn't the practical things belong into the tutorial?

> Personally I don't like the navigational structure because the simpler
> structure is better for the tutorial until the user can do the basics. A
> tutorial should feel like being inside emacs already as everyday.

I might go ahead and write a story, "Inside Emacs".  It would have a
little boy called Richard who falls alseep on a couch while his mother
is working on a LaTeX document in Emacs.  With his head resting on a big
heavy book about Emacs, in his dream he ends up in the pale light under
the key caps on the ground between the buffers, inside Emacs, where all
kinds of key bindings are scattered all over the place.  Grown-up
Richard comes along, searching for a key binding he's working on, so
they start talking, and Richard explains key bindings to Richard.  Each
time Richard hits a key binding, Richard is being moved around or jumps
up or down.  They're having a lot of fun with it, until Richard finally
finds the key binding he's looking for, and Richard wonders what it
would be like to be inside a buffer when his mother wakes him up to eat
potatoe pancakes for dinner ...

That may help people to remember all the difficult key bindings by
having a cute story to relate to.

debounce (was: Some developement questions)

[Juri Linkov]

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

>>> (setq Man-width 75)
>>
>> Emacs nowadays calculates the width dynamically, depending on the
>> dimensions of the window.
>
> Why not make Emacs dynamically size it's windows to the width of the
> display first? ;~O

Implementing this in bug#32536 revealed that mouse drag events become
too laggy when calling Man-update-manpage after every drag event on the
window separator.  JavaScript libraries provide a good solution that makes
web UI more responsible, see https://duckduckgo.com/?q=javascript+debounce

It could be good to have analogous in Emacs to e.g. make window resizing
more responsible.  So instead of

(add-hook 'window-size-change-functions 'Man-window-size-change)

in Man-mode this patch will allow

(add-hook 'window-size-change-functions (debounce 'Man-window-size-change 2))

where the last arg means 2 seconds sliding window to wait, and make the
final call once there are no more resizing events during that time period.

Since its args are similar to the args of run-with-timer, it makes sense
to add it to timer.el:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: debounce.1.patch --]
[-- Type: text/x-diff, Size: 920 bytes --]

diff --git a/lisp/emacs-lisp/timer.el b/lisp/emacs-lisp/timer.el
index 795554fec5..26c8426d3e 100644
--- a/lisp/emacs-lisp/timer.el
+++ b/lisp/emacs-lisp/timer.el
@@ -545,6 +545,22 @@ internal-timer-start-idle
   (dolist (timer timer-idle-list)
     (if (timerp timer) ;; FIXME: Why test?
         (setf (timer--triggered timer) nil))))
+
+\f
+(defmacro debounce (function secs)
+  "Postpone FUNCTION call until after SECS seconds have elapsed.
+Return a debounced function that will postpone FUNCTION call
+until after SECS seconds have elapsed since the last time
+it was invoked."
+  (declare (indent 0) (debug t))
+  (let ((timer-sym (make-symbol "timer")))
+    `(let (,timer-sym)
+       (lambda (&rest args)
+         (when (timerp ,timer-sym)
+           (cancel-timer ,timer-sym))
+         (setq ,timer-sym
+           (run-with-timer ,secs nil (lambda () (apply ,function args))))))))
+
 \f
 (provide 'timer)
 

Some developement questions

[Ergus]

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

Hi:
This is my first mail in this list and maybe this is not the right place to ask, but I don't know where to (I don't use twitter or any other social network)

 I have been using emacs for around 4 years now, and after all this time me and the the other 3 emacs user in my work have accumulated many question that will be very nice if any experimented user/developer could reply (even if you delete this mail from the list). 

- Why does emacs doesn't have a C api to create extensions as almost everything else in the Linux environment? I know Elisp is very powerful, but many functionalities actually requires to start external processes or call shell commands  intensively to work (magit, irony) and then parse the oulput when they could use the libraries and the APIs directly with dlopen or maybe with a more simplified/efficient approach. C is also the connection with everything (Python, Ruby, or FORTRAN) and nowadays there are more C/Python developers than Lisp developers, so many extensions could be created or ported. As is happening with vim actually.

- What's the actual status for the emacs-guile integration and why is it abandoned since 2015? This has to do with the previous and the next question because Guile already has a powerful C API, multithreading and many other functionalities that are been duplicated now in emacs. Maybe the future for guile is inside emacs.

- Native compiler? We have seen in the list some people talking about JIT compilation. Isn't it easier and more efficient to create a native code compiler like the one in Guile or maybe something that takes advantage of GCC, or a source to source compiler. Most of the extensions are just functions calls and loops and in this way Emacs could take advantage of the other's project progress and the emacs developers could put their effort in the most emacs's specific tasks? 95% of Emacs users are programmers, so a C compiler dependency shouldn't be an issue ans for sure there will be some performance improvement.

- As there are less developers now, why not to consider to make a cleanup and melt/join/merge projects/modes, for example (vile, evil and equivalent all do the same). This could be very helpful not only for the projects but also for the documentation that is becoming obsolete in emacswiki we suppose because of manpower. The same could apply to melpa projects that are unmaintained for a very long time. Some of them just don't work and have not received any commit in 6 or 8 years, so they probably break newest emacs Releases and nobody knows. You could also get tracks of the downloads.
- I have asked in my work and we are 4 emacs users only (in spite of we are more than 400 programmers) while most of the 3/4 of them are using vim. The main justifications are: "it is there" and "it doesn't require to configure anything". I have seen projects like spacemacs that solves somehow the configuration with a first start menu. Why don't you add a first time startup menu for the basic initial configuration in the default emacs, just to create a readable basic init.el? With use-packages it will be not that hard!!. Times have changed and young users need some hep to discover emacs, they will want to learn configuration details, elisp and the rest with the time. And nobody used the actual default emacs configuration. Spacemacs solves it partially but it makes absurdly complex to add manual configuration latter. And we don't need more abstractions layers. Simple questions like: add melpa? use vi like binds, or ergoemacs or ...? or use emacsserver? and some variable details that can be set very easily to have a functional user-friendly, minimal personalized environment like the the theme, linum, terminal or graphical interface by default). The idea is not only to make it easier, but also to show the power of emacs. 
Sorry for the extension, but we prefer one long mail instead of 4 shorter mails.Very thanks in advance
Ergus


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

Re: Some developement questions

[Eli Zaretskii]

> Date: Thu, 16 Aug 2018 13:34:06 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> 
> - Why does emacs doesn't have a C api to create extensions as almost everything else in the Linux
> environment?

It does, since Emacs 26.1.  See the emacs-modules feature.

> - What's the actual status for the emacs-guile integration and why is it abandoned since 2015?

AFAIK, no one is actively working on Guile Emacs.  (And Guile itself
is developed much slower than Emacs is.)

> - Native compiler? We have seen in the list some people talking about JIT compilation.

We just got a JIT branch a few days ago, please take a look and help
work towards eventually landing it.

> - As there are less developers now, why not to consider to make a cleanup and melt/join/merge
> projects/modes, for example (vile, evil and equivalent all do the same). This could be very helpful not only for
> the projects but also for the documentation that is becoming obsolete in emacswiki we suppose because of
> manpower. The same could apply to melpa projects that are unmaintained for a very long time. Some of them
> just don't work and have not received any commit in 6 or 8 years, so they probably break newest emacs
> Releases and nobody knows. You could also get tracks of the downloads.

I'm not sure I understand what you suggest in practical terms here.

> - I have asked in my work and we are 4 emacs users only (in spite of we are more than 400 programmers)
> while most of the 3/4 of them are using vim. The main justifications are: "it is there" and "it doesn't require to
> configure anything". I have seen projects like spacemacs that solves somehow the configuration with a first
> start menu. Why don't you add a first time startup menu for the basic initial configuration in the default emacs,
> just to create a readable basic init.el? With use-packages it will be not that hard!!.

Emacs is much more flexible, and different people have different
needs.

But that doesn't mean people cannot come up with such proposals.
Please do propose practical changes, and they will be reviewed.

Re: Some developement questions

[Aurélien Aptel]

On Thu, Aug 16, 2018 at 4:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
> It does, since Emacs 26.1.  See the emacs-modules feature.

And here is the documentation
https://phst.github.io/emacs-modules

Re: Some developement questions

[Andy Moreton]

On Thu 16 Aug 2018, Aurélien Aptel wrote:

> On Thu, Aug 16, 2018 at 4:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
>> It does, since Emacs 26.1.  See the emacs-modules feature.
>
> And here is the documentation
> https://phst.github.io/emacs-modules

Why has this not been added to the emacs manuals ?

    AndyM

Re: Some developement questions

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Thu, 16 Aug 2018 16:28:20 +0100
> 
> > https://phst.github.io/emacs-modules
> 
> Why has this not been added to the emacs manuals ?

Because it needs to be reworked to be in line with how we document
things in our manuals.  See

  http://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00969.html

Unfortunately, I didn't have time to work on that, and no one else
have beaten me to it.