[External] : Re: Gitlab Migration

[External] : Re: Gitlab Migration

[Drew Adams]

> If we started Emacs from a clean slate today,
> we would obviously have put kill-region on C-x.

Would we?  Maybe, maybe not.

Pro: Killing text is similar to cutting text.

Con: It's not the same thing.  The `kill-ring'
     is not what non-emacsers are used to.

This is similar to the pros & cons for words
in different languages that look the same or
similar, and may (or may not) have similar
meanings and uses, but can nevertheless be
quite different in some respects.

In French they're called "faux amis" - fake
friends.

 They can help you by giving you an idea
 what they mean (immediate recognition).

 They can hurt you if you just use them with
 the same expectation/understanding you have
 for them in your original language.

> We would in my opinion do well to take
> opportunities to make Emacs behave more in
> line with modern user expectations.

Again, yes & no.  We should look for what is
good - an improvement - not just for what is
currently popular.

Think Lisp versus the many "modern" languages
that were most popular at one time (Basic,
Pascal,...).  Lisp is as old-hat as they get.
(Fortran is only slightly older.)  It's still
a great language, and a lot better than the
Best-Of-Show languages that have won Blue
Ribbons over the decades.

We should consider adopting (and improving!)
something that provides real improvement, not
just something that's the flavor of the month
(or the decade).

Re: [External] : Re: Gitlab Migration

[Stefan Kangas]

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

> We should consider adopting (and improving!)
> something that provides real improvement, not
> just something that's the flavor of the month
> (or the decade).

Fully agreed.

Re: [External] : Re: Gitlab Migration

[Stefan Monnier]

> Con: It's not the same thing.  The `kill-ring'
>      is not what non-emacsers are used to.

[ This is all very hypothetical, so it clearly doesn't matter, but IMO
  the difference is small enough not to matter when it comes to choosing
  this key binding, IMO.  ]

> This is similar to the pros & cons for words
> in different languages that look the same or
> similar, and may (or may not) have similar
> meanings and uses, but can nevertheless be
> quite different in some respects.
>
> In French they're called "faux amis" - fake
> friends.

Nope.  "Faux amis" are words whose core meanings are just plain
different, whereas "Cut" and `kill-region` fundamentally mean pretty
much the same thing (with some minor differences).

> We should consider adopting (and improving!)  something that provides
> real improvement, not just something that's the flavor of the month
> (or the decade).

`C-x` for "Cut" has been standard for a lot more than a decade.


        Stefan

Re: [External] : Re: Gitlab Migration

[Tim Cross]

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

>> Con: It's not the same thing.  The `kill-ring'
>>      is not what non-emacsers are used to.
>
> [ This is all very hypothetical, so it clearly doesn't matter, but IMO
>   the difference is small enough not to matter when it comes to choosing
>   this key binding, IMO.  ]
>
>> This is similar to the pros & cons for words
>> in different languages that look the same or
>> similar, and may (or may not) have similar
>> meanings and uses, but can nevertheless be
>> quite different in some respects.
>>
>> In French they're called "faux amis" - fake
>> friends.
>
> Nope.  "Faux amis" are words whose core meanings are just plain
> different, whereas "Cut" and `kill-region` fundamentally mean pretty
> much the same thing (with some minor differences).
>
>> We should consider adopting (and improving!)  something that provides
>> real improvement, not just something that's the flavor of the month
>> (or the decade).
>
> `C-x` for "Cut" has been standard for a lot more than a decade.
>
Yes, I think this may be a 'flavour' which has won and can no longer be
considered a passing fad. The uncommon bindings used by Emacs for cut,
copy and paste is probably the number one complaint I hear from new
users. The kill-ring really just provides an enhancement rather than
a fundamental difference.

This would probably be a good candidate for the profiles idea. Change
the default, but have the old behaviour in a 'traditional' profile and
have the default be the more common CUA bindings. Personally, I would
probably load the traditional profile because that is what my finger
memory is and because I've spent way too many hours tweaking everything
else to use the Emacs bindings for these operations. However, part of me
wishes I'd not become accustomed to those key bindings as it is a
constant frustration when I'm forced to use a different program which
I've not been able to tweak - none of which would be necessary if I
hadn't grown accustomed to Emacs bindings. These are such common and
frequently used bindings, consistency across applications is probably
more important than maintaining inconsistent bindings simply to
highlight fairly subtle differences. 

Keybinding styles (was: [External] : Re: Gitlab Migration)

[Stefan Monnier]

> This would probably be a good candidate for the profiles idea.

FWIW, binding `kill-region` to `C-x` (and `copy-region-as-kill` to
`C-c`) is a hard problem in Emacs.  `cua-mode` tackles it in a pragmatic
way, and it's pretty good at it, but it comes with enough caveats that
I don't think it's a satisfactory solution.

If people are serious about trying to make Emacs easier for newcomers
accustomed to other tools, I think it might be worth developing
a package which starts with those C-<zxcv>` bindings and works its way
to create a complete new set of keybindings.

It's a work comparable to what is done for god-mode, Evil, etc... where
you'll need to have ad-hoc tweaks for many (most?all?) modes.
So it's a long-term maintenance challenge.

I keep wishing someone came up with a clever way for modes to specify
their key-bindings in such a way that Emacs can automatically derive from
it the keys to use "normally" as well as the keys to use in Evil or the
keys to use in god-mode, or the keys to use in this hypothetical new
`really-cua-mode`, ...
So as to finally address this long-term maintenance challenge.


        Stefan

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Dmitry Gutov]

On 04.09.2021 16:26, Stefan Monnier wrote:
> I keep wishing someone came up with a clever way for modes to specify
> their key-bindings in such a way that Emacs can automatically derive from
> it the keys to use "normally" as well as the keys to use in Evil or the
> keys to use in god-mode, or the keys to use in this hypothetical new
> `really-cua-mode`, ...

Choosing prefix keys as handy as C-x and C-c is hard enough.

C-d and C-e, I guess? Everything else close enough to Ctrl is occupied 
in CUA.

Re: Keybinding styles

[Stefan Monnier]

Dmitry Gutov [2021-09-04 16:39:34] wrote:
> On 04.09.2021 16:26, Stefan Monnier wrote:
>> I keep wishing someone came up with a clever way for modes to specify
>> their key-bindings in such a way that Emacs can automatically derive from
>> it the keys to use "normally" as well as the keys to use in Evil or the
>> keys to use in god-mode, or the keys to use in this hypothetical new
>> `really-cua-mode`, ...
> Choosing prefix keys as handy as C-x and C-c is hard enough.
> C-d and C-e, I guess? Everything else close enough to Ctrl is occupied
> in CUA.

IIRC the meta key is largely unused.  And of course it could go the Vi
route of using a key like ESC to access further bindings.


        Stefan

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Yuan Fu]

> On Sep 4, 2021, at 6:26 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> This would probably be a good candidate for the profiles idea.
> 
> FWIW, binding `kill-region` to `C-x` (and `copy-region-as-kill` to
> `C-c`) is a hard problem in Emacs.  `cua-mode` tackles it in a pragmatic
> way, and it's pretty good at it, but it comes with enough caveats that
> I don't think it's a satisfactory solution.
> 
> If people are serious about trying to make Emacs easier for newcomers
> accustomed to other tools, I think it might be worth developing
> a package which starts with those C-<zxcv>` bindings and works its way
> to create a complete new set of keybindings.
> 
> It's a work comparable to what is done for god-mode, Evil, etc... where
> you'll need to have ad-hoc tweaks for many (most?all?) modes.
> So it's a long-term maintenance challenge.
> 
> I keep wishing someone came up with a clever way for modes to specify
> their key-bindings in such a way that Emacs can automatically derive from
> it the keys to use "normally" as well as the keys to use in Evil or the
> keys to use in god-mode, or the keys to use in this hypothetical new
> `really-cua-mode`, ...
> So as to finally address this long-term maintenance challenge.
> 

On Mac I never had the problem because C-x/c/v and other system shortcuts are bound to the Command key, not Control. So I can use Emacs bindings with Control and system shortcuts with Command. Can we do the same in Windows and Linux? We can use the win key as Control for Emacs—seems that was where the Control key back in the day anyway.

Yuan

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 4 Sep 2021 08:44:02 -0700
> Cc: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.org
> 
> On Mac I never had the problem because C-x/c/v and other system shortcuts are bound to the Command key, not Control. So I can use Emacs bindings with Control and system shortcuts with Command. Can we do the same in Windows and Linux? We can use the win key as Control for Emacs—seems that was where the Control key back in the day anyway.

Win+C, Win+X, etc. are hardly natural for MS-Windows users.

But let's first think about users of GNU/Linux, okay?

RE: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Drew Adams]

> > On Mac I never had the problem because C-x/c/v and other system
> shortcuts are bound to the Command key, not Control. So I can use Emacs
> bindings with Control and system shortcuts with Command. Can we do the
> same in Windows and Linux? We can use the win key as Control for Emacs—
> seems that was where the Control key back in the day anyway.
> 
> Win+C, Win+X, etc. are hardly natural for MS-Windows users.

Yes.  If the point is to not have users need to
change the keys they use for this, between Emacs
and outside-Emacs, then using some other modifier
key than Control doesn't really help with that,
I think.

Same for substituting some other modifier key
for `M-' (typically defaulted to the Alt key).

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Yuan Fu]

> On Sep 4, 2021, at 8:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 4 Sep 2021 08:44:02 -0700
>> Cc: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.org
>> 
>> On Mac I never had the problem because C-x/c/v and other system shortcuts are bound to the Command key, not Control. So I can use Emacs bindings with Control and system shortcuts with Command. Can we do the same in Windows and Linux? We can use the win key as Control for Emacs—seems that was where the Control key back in the day anyway.
> 
> Win+C, Win+X, etc. are hardly natural for MS-Windows users.
> 
> But let's first think about users of GNU/Linux, okay?

I meant the other way around. Emacs use win+C for C-c, and Control-bindings are left to Windows. I.e., Win-c for C-c, Control-c for copy. 

Linux users generally use windows keyboards, and they have a win key as well.

Yuan

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 4 Sep 2021 09:07:36 -0700
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  Tim Cross <theophilusx@gmail.com>,
>  emacs-devel@gnu.org
> 
> > Win+C, Win+X, etc. are hardly natural for MS-Windows users.
> > 
> > But let's first think about users of GNU/Linux, okay?
> 
> I meant the other way around. Emacs use win+C for C-c, and Control-bindings are left to Windows. I.e., Win-c for C-c, Control-c for copy. 

Then I don't see how this is better than simple rebind the commands to
C-c/C-x/C-z/C-v.  You are in for a massive rebinding all over the
place, and people will have to relearn or bind them back to their
originals.

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[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 meant the other way around. Emacs use win+C for C-c, and Control-bindings are left to Windows. I.e., Win-c for C-c, Control-c for copy. 

  > [GNU/]Linux users generally use windows keyboards, and they have a win key as well.

If the goal is finger compatibility, then it would make sense to use
the Command modifier on MacOS, and the Ctrl modified on other systems.
The Lose key would only be a good choice in Emacs if it other programs
use it too.

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

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Dmitry Gutov]

On 06.09.2021 06:07, Richard Stallman wrote:
> The Lose key would only be a good choice in Emacs if it other programs
> use it too.

To avoid having to invent euphemisms, you can call it the "Super key".

Re: Keybinding styles

[Daniel Fleischer]

Eli Zaretskii [2021-09-04 Sat 18:50] wrote:

> Win+C, Win+X, etc. are hardly natural for MS-Windows users.
>
> But let's first think about users of GNU/Linux, okay?

I would cautiously say that the profiles we're discussing are meant for
users who skew toward OSes that are NOT Linux.  I might be wrong
though.

-- 

Daniel Fleischer

Re: Keybinding styles

[Stefan Kangas]

Daniel Fleischer <danflscr@gmail.com> writes:

> > Win+C, Win+X, etc. are hardly natural for MS-Windows users.

Or anyone else, for that matter.

> > But let's first think about users of GNU/Linux, okay?
>
> I would cautiously say that the profiles we're discussing are meant for
> users who skew toward OSes that are NOT Linux.  I might be wrong
> though.

They are principally meant for users of GNU/Linux, as that is the
primary OS that Emacs is developed for.  Keep in mind that not
everyone who uses GNU/Linux is automatically a power user -- you have
a very large variation in that group, just as you have with any other
OS.

Re: Keybinding styles

[tomas]

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

On Sat, Sep 04, 2021 at 10:52:12PM +0200, Stefan Kangas wrote:

[...]

> They are principally meant for users of GNU/Linux, as that is the
> primary OS that Emacs is developed for.  Keep in mind that not
> everyone who uses GNU/Linux is automatically a power user [...]

Is that just a "gut feeling" or do you have anecdote/data to back
that up?

I don't have data, but at least anecdote to offer: as someone pretty
well immersed in GNU/Linux circles, I see semi-power users mostly
using Geany or (second) KEdit; non-power users even tend to use
LibreOffice (remember, on the Dark Side folks also insist on using
Word as a text editor, because a text is a text is a text [1], right?

Power users in GNU/Linux split (unevenly) between Vi(m) and Emacs.
Some sprinklings of nano who upgraded form the more advanced
group above.

My hunch (but remember: I've got anecdote, not data) is: A GNU/Linux
Emacs user is, in the overwhelming majority of the cases, perfectly
well-equipped to beat her Emacs config into whichever submission she
needs. Actually, she'll enjoy doing that.

Exceptions to the above (and IMHO /these/ would be the interesting
ones) might be "special" cases: those for whom Emacs solves a very
specific problem no other editor does well: think speech integration,
cross-language literate programming, humanities, things like that.

All of that my hunches, of course.

Cheers

[1] cue in seasoned sysadmins trying to rescue a situation where
   /etc/passwd has been edited with Word: yes, I've had that!

 - t

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

Re: Keybinding styles

[Bird]

Yuan Fu <casouri@gmail.com> writes:

>> On Sep 4, 2021, at 6:26 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>>[clip]
>> I keep wishing someone came up with a clever way for modes to specify
>> their key-bindings in such a way that Emacs can automatically derive from
>> it the keys to use "normally" as well as the keys to use in Evil or the
>> keys to use in god-mode, or the keys to use in this hypothetical new
>> `really-cua-mode`, ...
>> So as to finally address this long-term maintenance challenge.
>> 
>
> On Mac I never had the problem because C-x/c/v and other system
> shortcuts are bound to the Command key, not Control. So I can use
> Emacs bindings with Control and system shortcuts with Command. Can we
> do the same in Windows and Linux? We can use the win key as Control
> for Emacs—seems that was where the Control key back in the day anyway.
>
> Yuan

A lot of people use the mod4/win/super key for managing their
Desktop Environment/Window Manager especially people using
tiling window managers. Already a lot of Desktop Environments
have used Alt(meta) key for their own use which is very
annoying. So using the super key in place of control will
probably not be a great use to many folks.

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Tim Cross]

Yuan Fu <casouri@gmail.com> writes:

>> On Sep 4, 2021, at 6:26 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>>> This would probably be a good candidate for the profiles idea.
>> 
>> FWIW, binding `kill-region` to `C-x` (and `copy-region-as-kill` to
>> `C-c`) is a hard problem in Emacs.  `cua-mode` tackles it in a pragmatic
>> way, and it's pretty good at it, but it comes with enough caveats that
>> I don't think it's a satisfactory solution.
>> 
>> If people are serious about trying to make Emacs easier for newcomers
>> accustomed to other tools, I think it might be worth developing
>> a package which starts with those C-<zxcv>` bindings and works its way
>> to create a complete new set of keybindings.
>> 
>> It's a work comparable to what is done for god-mode, Evil, etc... where
>> you'll need to have ad-hoc tweaks for many (most?all?) modes.
>> So it's a long-term maintenance challenge.
>> 
>> I keep wishing someone came up with a clever way for modes to specify
>> their key-bindings in such a way that Emacs can automatically derive from
>> it the keys to use "normally" as well as the keys to use in Evil or the
>> keys to use in god-mode, or the keys to use in this hypothetical new
>> `really-cua-mode`, ...
>> So as to finally address this long-term maintenance challenge.
>> 
>
> On Mac I never had the problem because C-x/c/v and other system shortcuts are
> bound to the Command key, not Control. So I can use Emacs bindings with Control
> and system shortcuts with Command. Can we do the same in Windows and Linux? We
> can use the win key as Control for Emacs—seems that was where the Control key
> back in the day anyway.
>

The problem I see with this approach is that many desktop environments
have already adopted using the 'wind' key for window manager shortcuts.
I've seen many 'problems' for new users where the documented key binding
does not appear to work when what is actually happening is that the
window manager is steeling the key presses, so emacs never sees them.
Therefore, I think adopting use of the win key could just increase
confusion.  

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[John Yates]

On Sat, Sep 4, 2021 at 9:26 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> I keep wishing someone came up with a clever way for modes to specify
> their key-bindings in such a way that Emacs can automatically derive from
> it the keys to use "normally" as well as the keys to use in Evil or the
> keys to use in god-mode, or the keys to use in this hypothetical new
> `really-cua-mode`, ...
> So as to finally address this long-term maintenance challenge.

I would like to suggest that key bindings are the most contentious
aspect of Emacs.  We have numerous examples of efforts to offer
alternative binding schemes.  But it is the "default" bindings that
engender all of the "Sturm und Drang".  The keystrokes in these
default bindings are distinguished in tutorials, package development,
documentation, and casual communication over those in other binding
schemes.

Many regard those keystrokes as a fundamental Emacs feature.
Yet, I believe, whatever one's view of vi/vim, none of us would deny
that a user with evil-mode enabled is still truly using Emacs.  What
matters is that such a user is invoking elisp functions to work with
Emacs buffers.  To me, that is the essence of being an Emacs user.

As a first step towards Stefan's wish, might I suggest that we
consider what it would take to move to a world in which other
binding schemes are considered fully equal peers of our current
default bindings?  Once we internalize that model, we can then
work on abstractions to describe the relationships between the
functions exposed by a given package (flat, sub-groups) and
their relationship to overarching concepts like navigation.

/john

PS: For the record, I use the default bindings.

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Sun, 5 Sep 2021 15:03:54 -0400
> Cc: Tim Cross <theophilusx@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> As a first step towards Stefan's wish, might I suggest that we
> consider what it would take to move to a world in which other
> binding schemes are considered fully equal peers of our current
> default bindings?

What would such a move mean in practical terms?

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

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

  > As a first step towards Stefan's wish, might I suggest that we
  > consider what it would take to move to a world in which other
  > binding schemes are considered fully equal peers of our current
  > default bindings?

If "fully equal peers" means that we give them as much support to each
of them as we do to the Emacs key bindings, we shouldn't.  It would be
an enormous amount of work, and not worth it.  We won't urge people to
make a version of the Emacs Manual that uses a different set of key
bindings, nor to update it for each Emacs version.

It's reasonable to support selecting other sets of key bindings,
but the implementing them and supporting them will have to be up
to whoever likes each one.

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

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[John Yates]

On Mon, Sep 6, 2021 at 11:16 PM Richard Stallman <rms@gnu.org> wrote:
>
>   > As a first step towards Stefan's wish, might I suggest that we
>   > consider what it would take to move to a world in which other
>   > binding schemes are considered fully equal peers of our current
>   > default bindings?
>
> If "fully equal peers" means that we give them as much support to each
> of them as we do to the Emacs key bindings, we shouldn't.  It would be
> an enormous amount of work, and not worth it.  We won't urge people to
> make a version of the Emacs Manual that uses a different set of key
> bindings, nor to update it for each Emacs version.
>
> It's reasonable to support selecting other sets of key bindings,
> but the implementing them and supporting them will have to be up
> to whoever likes each one.

I did not suggest that we do any work specifically to support
any specific alternative set of key bindings.  What I attempted
to suggest is trying to understand the experience of someone
adopting Emacs from the outset with evil-mode or some other
alternative set of key bindings enabled.  To what extent can
that user be made to feel other than a second class member
of our community?  Can the user experience when perusing
documentation be either in terms of neutral function names
or, when key bindings must be mentioned, then in terms of
that user's elected bindings?

The implication was, until we accept at a cultural level, that
other sets of bindings should not be disadvantaged, we are
unlikely to make progress toward Stefan's stated wish:

> I keep wishing someone came up with a clever way for modes to specify
> their key-bindings in such a way that Emacs can automatically derive from
> it the keys to use "normally" as well as the keys to use in Evil or the
> keys to use in god-mode, or the keys to use in this hypothetical new
> `really-cua-mode`, ...
> So as to finally address this long-term maintenance challenge.

/john

Re: Keybinding styles (was: [External] : Re: Gitlab Migration)

[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 did not suggest that we do any work specifically to support
  > any specific alternative set of key bindings.  What I attempted
  > to suggest is trying to understand the experience of someone
  > adopting Emacs from the outset with evil-mode or some other
  > alternative set of key bindings enabled.  To what extent can
  > that user be made to feel other than a second class member
  > of our community?

In principle, if we could easily do that, there would be no reason not
to try.  But I expect it would be far too much work, and that we should
therefore reject the goal.

For instance, anyone using an interface different from the one
described in the Emacs Manual will justly feel it is second-class.

  > Can the user experience when perusing
  > documentation be either in terms of neutral function names
  > or, when key bindings must be mentioned, then in terms of
  > that user's elected bindings?

We do that in the documentation strings in Emacs.
But not in the manual, because that is written by hand.

If you wanted to do a research project, you could try developing a
system for writing manuals which handled variation in key bindings.
You might come up with an advance in technology.

If you want to work on that research, I wish you luck, but that is
outside the scope of the GNU Project.

  > > I keep wishing someone came up with a clever way for modes to specify
  > > their key-bindings in such a way that Emacs can automatically derive from
  > > it the keys to use "normally" as well as the keys to use in Evil or the
  > > keys to use in god-mode, or the keys to use in this hypothetical new
  > > `really-cua-mode`, ...
  > > So as to finally address this long-term maintenance challenge.

This is a different project -- it does not involve the Emacs Manual.
It might be much easier than the project I discussed above.

It is still research, though, and outside the scope of the GNU Project.
Not so far outside, but outside nonetheless.

I don't think this project should be a priority.  But work on it if
you like, and if you make it work, we could install it.

I do not believe that this would be enough to avoid making users of
nonstandard key bindings feel their key bindings are second class.



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

Re: Keybinding styles

[André A. Gomes]

Richard Stallman <rms@gnu.org> writes:

> If you wanted to do a research project, you could try developing a
> system for writing manuals which handled variation in key bindings.
> You might come up with an advance in technology.
>
> If you want to work on that research, I wish you luck, but that is
> outside the scope of the GNU Project.

Why is it outside the scope of the GNU Project?

This is probably a silly hack, but here are some ideas to have a
"dynamic" Emacs manual.  Basically, write dynamically, publish
statically.  A rough plan:

1. Convert the Emacs manual from texi to org.

2. Leverage `where-is' and the macro replacement facilities of org---(info
"(org) Macro Replacement").

3. Export the org manual to texi.


--
André A. Gomes
"Free Thought, Free World"

Re: Keybinding styles

[Eli Zaretskii]

> From: André A. Gomes <andremegafone@gmail.com>
> Date: Wed, 08 Sep 2021 15:15:52 +0300
> Cc: theophilusx@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  John Yates <john@yates-sheets.org>
> 
> This is probably a silly hack, but here are some ideas to have a
> "dynamic" Emacs manual.  Basically, write dynamically, publish
> statically.  A rough plan:
> 
> 1. Convert the Emacs manual from texi to org.
> 
> 2. Leverage `where-is' and the macro replacement facilities of org---(info
> "(org) Macro Replacement").
> 
> 3. Export the org manual to texi.

That'd produce a manual that caters to a single, but different set of
key bindings, which was not the intent.  The intent is to produce a
manual that caters to any set, in the same manual.  That'd mean
changing the text dynamically when it is displayed by the Info reader,
whereas you propose a static change.

Re: Keybinding styles

[John Yates]

On Wed, Sep 8, 2021 at 8:15 AM André A. Gomes <andremegafone@gmail.com> wrote:
>
> 1. Convert the Emacs manual from texi to org.
>
> 2. Leverage `where-is' and the macro replacement facilities of org---(info
> "(org) Macro Replacement").
>
> 3. Export the org manual to texi.

I imagined something more along these lines:

First iteration:
* Add a new Tex markup item whose required first argument
  would be a function name and whose optional second argument
  would be a key sequence.
* Makeinfo would make both data available in the generated info
  file.  A standalone info reader would display the optional second
  argument if present.  The emacs info reader would lookup any
  current bindings for the function name.

Second iteration:
* Modify makeinfo to accept a table of bindings.  In this case any
  optional second argument would be ignored.  Instead bindings
  for a function name would be looked up in that table and included
  in the output.

/john

Re: Keybinding styles

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Wed, 8 Sep 2021 16:37:05 -0400
> Cc: Tim Cross <theophilusx@gmail.com>, Emacs developers <emacs-devel@gnu.org>,
>  Richard Stallman <rms@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> On Wed, Sep 8, 2021 at 8:15 AM André A. Gomes <andremegafone@gmail.com> wrote:
> First iteration:
> * Add a new Tex markup item whose required first argument
>   would be a function name and whose optional second argument
>   would be a key sequence.
> * Makeinfo would make both data available in the generated info
>   file.  A standalone info reader would display the optional second
>   argument if present.  The emacs info reader would lookup any
>   current bindings for the function name.
> 
> Second iteration:
> * Modify makeinfo to accept a table of bindings.  In this case any
>   optional second argument would be ignored.  Instead bindings
>   for a function name would be looked up in that table and included
>   in the output.

I don't see a need to modify anything but info.el.  A table that you
want already exists: it's the Index.  We need a special-purpose index
for this: one that maps commands to keys, but Texinfo already supports
the capability of defining new types of indices.  A markup for keys
also already exists.  So all that's needed is to add a feature to
info.el to display a different set of keys given some state variable.

Of course, the printed manual will still show only the standard key
bindings, and so will the HTML-formatted manual we put on the Web
site.

Re: Keybinding styles

[André A. Gomes]

Eli Zaretskii <eliz@gnu.org> writes:

> [...] So all that's needed is to add a feature to info.el to display a
> different set of keys given some state variable.
>
> Of course, the printed manual will still show only the standard key
> bindings, and so will the HTML-formatted manual we put on the Web
> site.

I agree that the printed and HTML-formatted manual must be "standard".
The suggestion of using a state variable also makes sense.

But I brought the subject from another perspective.  When a user runs
(info-emacs-manual), shouldn't it reflect Emacs' state?  Concretely, if
I rebind C-x C-f to something else, the manual should tell me.  It seems
to me like a missed opportunity.

In fact, there's work done in a similar vein.  When users read the
tutorial, they're warned them about rebounded keys.  To my mind, the
same should happen with the manual.


--
André A. Gomes
"Free Thought, Free World"

Re: Keybinding styles

[Stefan Kangas]

André A. Gomes <andremegafone@gmail.com> writes:

> But I brought the subject from another perspective.  When a user runs
> (info-emacs-manual), shouldn't it reflect Emacs' state?  Concretely, if
> I rebind C-x C-f to something else, the manual should tell me.  It seems
> to me like a missed opportunity.

I don't think anyone disagrees that this would be a good thing (we
already try to do that in help buffers, and the tutorial as you note).

It also seems like Eli agrees, and even gave specific advice on how to do it.

The only detail that's missing here is a working patch.  ;-)

Re: Keybinding styles

[Eli Zaretskii]

> From: André A. Gomes <andremegafone@gmail.com>
> Cc: John Yates <john@yates-sheets.org>,  theophilusx@gmail.com,
>   emacs-devel@gnu.org,  rms@gnu.org,  monnier@iro.umontreal.ca
> Date: Wed, 15 Sep 2021 16:40:59 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [...] So all that's needed is to add a feature to info.el to display a
> > different set of keys given some state variable.
> >
> > Of course, the printed manual will still show only the standard key
> > bindings, and so will the HTML-formatted manual we put on the Web
> > site.
> 
> I agree that the printed and HTML-formatted manual must be "standard".
> The suggestion of using a state variable also makes sense.
> 
> But I brought the subject from another perspective.  When a user runs
> (info-emacs-manual), shouldn't it reflect Emacs' state?  Concretely, if
> I rebind C-x C-f to something else, the manual should tell me.  It seems
> to me like a missed opportunity.
> 
> In fact, there's work done in a similar vein.  When users read the
> tutorial, they're warned them about rebounded keys.  To my mind, the
> same should happen with the manual.

Isn't that what I said above?

Re: Keybinding styles

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

  > But I brought the subject from another perspective.  When a user runs
  > (info-emacs-manual), shouldn't it reflect Emacs' state?  Concretely, if
  > I rebind C-x C-f to something else, the manual should tell me.  It seems
  > to me like a missed opportunity.

That would fit into the spirit of Emacs documentation, but calling it
a "missed opportunity" supposes that we have an opportunity to do it.

Do we have an opportunity?  Maybe, but I tend to doubt it.  I tend to
think that doing this correctly is a big job; a simple search and
replace will get confused and make mistakes.

I could be mistaken.  If it turns out to be easy, why not?  But I don't
think this is important enough to be worth a lot of work.

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

Re: Keybinding styles

[Alexandre Garreau]

Le mercredi 15 septembre 2021, 22:15:00 CEST Richard Stallman a écrit :
> [[[ 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. ]]]
> 
>   > But I brought the subject from another perspective.  When a user
>   > runs
>   > (info-emacs-manual), shouldn't it reflect Emacs' state?  Concretely,
>   > if
>   > I rebind C-x C-f to something else, the manual should tell me.  It
>   > seems to me like a missed opportunity.
> 
> That would fit into the spirit of Emacs documentation, but calling it
> a "missed opportunity" supposes that we have an opportunity to do it.
> 
> Do we have an opportunity?  Maybe, but I tend to doubt it.  I tend to
> think that doing this correctly is a big job; a simple search and
> replace will get confused and make mistakes.
> 
> I could be mistaken.  If it turns out to be easy, why not?  But I don't
> think this is important enough to be worth a lot of work.

Don’t we already have a special markup in texinfo for keybindings? 
otherwise we ought to: we control texinfo (essentially used for emacs and 
some other popular gnu stuff (since it’s used by gnu stuff)), and the main 
implementation already is emacs.

We could add some markup to contextualize the origin of keybindings (for 
instance what mode/software the current section is talking about)

Re: Keybinding styles

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Cc: André A. Gomes <andremegafone@gmail.com>, eliz@gnu.org, theophilusx@gmail.com, monnier@iro.umontreal.ca, john@yates-sheets.org
> Date: Wed, 15 Sep 2021 23:29:24 +0200
> 
> Don’t we already have a special markup in texinfo for keybindings? 

No, we don't.  (And it's not "we" who define the Texinfo markup, it's
the Texinfo language, which is not maintained and developed by the
Emacs project.)

What is needed here is to have the _command_ invoked by a key
sequence, rather than the key sequence itself, be mentioned in Texinfo
and propagated to Info with some markup there, so that info.el could
replace the command name by the actual key binding.  Something like
the \\[..] markup we have for doc strings.

> otherwise we ought to: we control texinfo (essentially used for emacs and 
> some other popular gnu stuff (since it’s used by gnu stuff)), and the main 
> implementation already is emacs.

That's not true.  First, the Texinfo language is not controlled by the
Emacs project, it's developed and maintained by a sibling GNU
project.  And second, there are actively developed Info readers that
are not in Emacs: the trivial example is the stand-alone reader that
is part of the Texinfo project.

We cannot make unilateral changes in this area.

> We could add some markup to contextualize the origin of keybindings (for 
> instance what mode/software the current section is talking about)

I don't think I understand the details of this proposal, but in any
case, many sections in the manual do not talk about a single major
mode.

Re: Keybinding styles

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, theophilusx@gmail.com, emacs-devel@gnu.org,
> 	monnier@iro.umontreal.ca, john@yates-sheets.org
> Date: Wed, 15 Sep 2021 16:15:00 -0400
> 
> Do we have an opportunity?  Maybe, but I tend to doubt it.  I tend to
> think that doing this correctly is a big job; a simple search and
> replace will get confused and make mistakes.

IMO, it is not a simple job.  We need to find a way of reliably
identifying key bindings and the functions they invoke in the manual.
It will likely require changes to the Texinfo sources and most
probably the resulting Info file will look somewhat differently, so we
need to consider how this affects other Info readers (or decide that
we don't care?).

Re: Keybinding styles

[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 you wanted to do a research project, you could try developing a
  > > system for writing manuals which handled variation in key bindings.
  > > You might come up with an advance in technology.
  > >
  > > If you want to work on that research, I wish you luck, but that is
  > > outside the scope of the GNU Project.

  > Why is it outside the scope of the GNU Project?

We have an Emacs Manual that documents Emacs.
That's what we want.  Producing manuals for greatly modified
version of Emacs is not our goal.  If some people want to work on it,
they are welcome to, but I won't urge people to choose that project.

  > 1. Convert the Emacs manual from texi to org.

  > 2. Leverage `where-is' and the macro replacement facilities of org---(info
  > "(org) Macro Replacement").

  > 3. Export the org manual to texi.

Supporting this as part of Emacs is a non-goal, but
if this gives you results you like, you are welcome to do it.

Eli wrote:

  > That'd produce a manual that caters to a single, but different set of
  > key bindings, which was not the intent.  The intent is to produce a
  > manual that caters to any set, in the same manual.  That'd mean
  > changing the text dynamically when it is displayed by the Info reader,
  > whereas you propose a static change.

I think that is a much more challenging goal than the other one.  I
expect it will be difficult to reconcile this with formatting the
manual trough TeX.

Supporting this as part of Emacs is a non-goal, but if you present
a clean and unproblematical implementation, we would not reject it
a priori.

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

Re: [External] : Re: Gitlab Migration

[Stefan Kangas]

Tim Cross <theophilusx@gmail.com> writes:

> Yes, I think this may be a 'flavour' which has won and can no longer be
> considered a passing fad. The uncommon bindings used by Emacs for cut,
> copy and paste is probably the number one complaint I hear from new
> users. The kill-ring really just provides an enhancement rather than
> a fundamental difference.

Yup.  I don't think I could unlearn some keys (e.g. C-w for
kill-region) without massive pain.  So I'm not sure I will personally
ever bother re-learning after using Emacs for going on two decades.

At the same time, I have no idea why it is the case in 2021 that Emacs
appeases my archaic preference for C-w to the extent that it makes it
the default.  If Emacs would want to change here, it wouldn't impact
me at all if I could easily move the keys back to where I feel they
belong.

> This would probably be a good candidate for the profiles idea. Change
> the default, but have the old behaviour in a 'traditional' profile and
> have the default be the more common CUA bindings.

This would be my ideal future, as well.

> However, part of me
> wishes I'd not become accustomed to those key bindings as it is a
> constant frustration when I'm forced to use a different program which
> I've not been able to tweak - none of which would be necessary if I
> hadn't grown accustomed to Emacs bindings. These are such common and
> frequently used bindings, consistency across applications is probably
> more important than maintaining inconsistent bindings simply to
> highlight fairly subtle differences.

Amen.  I've lost work many times by closing tabs in Firefox when I
actually wanted to paste something.  Learning to mentally switch
context between "Emacs" and "not Emacs" is in this case a trial by
fire.

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> > Con: It's not the same thing.  The `kill-ring'
> >      is not what non-emacsers are used to.
> 
> [ This is all very hypothetical, so it clearly doesn't matter, but IMO
>   the difference is small enough not to matter when it comes to
>   choosing this key binding, IMO.  ]

It's a matter of opinion, yes.

It's a bit like undo.  Emacs's undo is similar
at first sight to what people are used to, but
"it's not the same thing".  Possibly confusing,
misleading.  But no, not the end of the world.

> > This is similar to the pros & cons for words
> > in different languages that look the same or
> > similar, and may (or may not) have similar
> > meanings and uses, but can nevertheless be
> > quite different in some respects.
> >
> > In French they're called "faux amis" - fake
> > friends.
> 
> Nope.  "Faux amis" are words whose core meanings
> are just plain different, 

Yes and no.  How dissimilar the meanings are
("core" or not) points to _how_ false the friend
is.  The point is that there's a difference, at
least in some contexts, and that difference is
hidden from the person fooled - a gotcha.

It's the similarity together with the difference,
and not being aware of the difference, that makes
for a faux ami.  It's about that ignorance and
the resultant "gotcha!"  It's not about how close
the core meanings are.  But yes, the stronger the
difference in meaning, the more the friends are
false.

And there are all sorts - some of which are very
false, and some of which are quite similar but
differ in usage or connotation in at least some
contexts, perhaps contexts that can be important.

That context relevance happens especially for
more recent loan words than for words taken up
by English from French in the 12th century.
It's common, for instance, for the borrowing
language to give the borrowed word a meaning
with a narrower scope, when it already has
words for the wider-scope meaning.

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

"As well as producing _completely false_ friends,
the use of loanwords often results in the use of
a word in a restricted context, which may then
develop new meanings not found in the original
language."
 
> `C-x` for "Cut" has been standard for a lot more than a decade.

Yes, and?  `C-w' has been standard in Emacs for
longer than "Cut" has existed.

Anyway, I won't argue about `C-x' (or `C-w').
I don't see Emacs moving `C-x', but hey, I've
been wrong before...

Re: [External] : Re: Gitlab Migration

[Stefan Monnier]

>> `C-x` for "Cut" has been standard for a lot more than a decade.
> Yes, and?

So it's not just a passing fad that may change again any time now.
[ Other than the general disappearance of keyboards, or maybe a move to
  some other modifier, as in macOS ]

> Anyway, I won't argue about `C-x' (or `C-w').

And yet you did.


        Stefan

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> >> `C-x` for "Cut" has been standard for a lot more than a decade.
> > Yes, and?
> 
> So it's not just a passing fad that may change again any time now.
> [ Other than the general disappearance of keyboards, or maybe a move to
>   some other modifier, as in macOS ]
> 
> > Anyway, I won't argue about `C-x' (or `C-w').
> 
> And yet you did.

No, I really didn't.  I spoke to the meaning of
"faux amis".

I'm saying nothing about `C-x', because I don't
see that changing - as I said:

  I don't see Emacs moving `C-x'

(Do you, really?)

If it does, then I likely won't have a problem
with that change, because the change would have
to (somehow) deal with the current uses of
prefix key `C-x', as well as (likely) prefix
key `C-c', and key `C-v'.
___

As for how the discord between Emacs bindings
for these things and those of the outside world
affects me (I use lots of apps outside Emacs,
including the email client I'm using now):

I'm not bothered by accidentally using `C-x',
`C-c', or `C-v' in Emacs when mechanically
trying to cut, copy, or paste.  Why?  Because
those keys in Emacs are benign.  The first two
are prefix keys, so I notice quickly enough
what I did accidentally.  And the third just
scrolls a page.  All are easy to get past.

(Yes, those could well be more problematic
for a new Emacs user.  I'm speaking for myself
here.)

But where I do get a little bothered is in
the other direction - when I accidentally use
`M-w' (not `C-w') in an app like my email
client - client that tries to forward the
email I'm writing.

Re: [External] : Re: Gitlab Migration

[Stefan Monnier]

>   I don't see Emacs moving `C-x'

That was not under discussion.  Here's what you wrote:

    > If we started Emacs from a clean slate today,
    > we would obviously have put kill-region on C-x.
    
    Would we?  Maybe, maybe not.
    
    Pro: Killing text is similar to cutting text.
    
    Con: It's not the same thing.  The `kill-ring'
         is not what non-emacsers are used to.


-- Stefan

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> >   I don't see Emacs moving `C-x'
> 
> That was not under discussion.

It's not?  I think one of the questions
raised in the discussion is whether (and
how) to let users start with a "profile"
(or just change the default behavior)
that gives them a `C-x' that they're
used to - or at least similar, such as
what `kill-region' does.

> Here's what you wrote:
> 
>     > If we started Emacs from a clean slate today,
>     > we would obviously have put kill-region on C-x.
> 
>     Would we?  Maybe, maybe not.
>     Pro: Killing text is similar to cutting text.
>     Con: It's not the same thing.  The `kill-ring'
>          is not what non-emacsers are used to.

Exactly.  I raised the _question_.  And I
pointed out that, though similar, the two
are not the same.

So again, if we started Emacs from scratch
today, is it really obvious that we would
put `kill-region' on `C-x'?  To me, that's
not so obvious - it's an open question
(but counter-factual, since we're not
starting from a clean slate today).

Re: [External] : Re: Gitlab Migration

[John Yates]

On Fri, Sep 3, 2021 at 6:50 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> `C-x` for "Cut" has been standard for a lot more than a decade.

CUA was first published in 1987, so nearly three and a half decaces :-)

/john

Re: [External] : Re: Gitlab Migration

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

  > > `C-x` for "Cut" has been standard for a lot more than a decade.

  > CUA was first published in 1987, so nearly three and a half decaces :-)

Emacs (the PDP-10 version) was first released in 1976.
CUA came second.



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

Re: [External] : Re: Gitlab Migration

[Barry Fishman]

On 2021-09-06 23:16:19 -04, 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. ]]]
>
>   > > `C-x` for "Cut" has been standard for a lot more than a decade.
>
>   > CUA was first published in 1987, so nearly three and a half decaces :-)
>
> Emacs (the PDP-10 version) was first released in 1976.
> CUA came second.

<TLDR>
Lets just say I find this slow creep of small changes, without any
understandable, cohesive long term plan, and requiring a continual
effort on my part to keep my own environment stable, a large continual
sink of my time.
</TLDR>

Emacs has also evolved over that amount of time.  Commands are fit into
an integrated whole, and changed to make things work better.

Subsets of commands are used in other tools like Readline, and seen in
programs like Rlwrap, Bash, Clisp, and Gnome (prior to GTK-4). It was
available also for a long time in Firefox.

In the applications where it has be removed, there is also a gross
removal of a lot of functionality (Such as Gnome-4).  Why is it
important to have C-p print the current page in Firefox rather than fit
into a set of commands to move the cursor in a text entry buffer?  Text
entry has become hell for me, when my fingers go off and do thinks
automatically.  How often do you want to print the current page, and you
can just select print from a menu.

I'm concerned that no attention seem so be given to Emacs's whole
functionality and ease of use, but just shoe-horning in things like CUA,
which to my mind has a negative effect on usability.

That is even ignoring having to relearn a large set commands that in the
end is less well thought out.

Do you have accepted code for all the programs that use Emacs style
bindings?  How are we supposed to navigate the transition where many of
us use a variety of systems with varying version of Emacs and Readline
being used.  In particular when working on slow moving systems like
Debian servers, where we may not have the ability to rebuild (and
sometimes rethink) all our tools.

I made my major transition to Emacs when I was forced by my employer to
move my development environment from Sun to Windows.  Emacs was a way to
exist on Windows while I transitioned my working environment.  I found
that Emacs often had better tools for me that he Microsoft ones I was
learning.  It certainly had a better C++ class browser.  [I wasn't there
very long.]

I find that making the transition easier for people raised on Microsoft
or Apple to GNU/Linux should include the appreciation of an environment
where you no longer had to sit by and hope that your platform made
things better for you, but you could gain some control yourself.
Otherwise we are just making GNU/Linux (Gnome|Plasma) no better, and
often worse that the heavily financed platform they would be leaving.

-- 
Barry Fishman

Re: [External] : Re: Gitlab Migration

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

  > In the applications where it has be removed, there is also a gross
  > removal of a lot of functionality (Such as Gnome-4).  Why is it
  > important to have C-p print the current page in Firefox rather than fit
  > into a set of commands to move the cursor in a text entry buffer?

I would love to enable an option to use Emacs commands in Firefox.  Is
there one?

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

Re: [External] : Re: Gitlab Migration

[André A. Gomes]

Richard Stallman <rms@gnu.org> writes:

> I would love to enable an option to use Emacs commands in Firefox.  Is
> there one?

I apologise if you're aware of everything that follows.  I've been in
this "quest" for some time too.

1. It's possible to use (a subset of) Emacs readline keybindings on any
GTK program (including Firefox).  You can use C-{a,e,f,b}, M-{f,b} and
the like on text input fields (including the address bar).  It's not
possible to pass numerical prefixes, or to use mark commands such as
C-SPC (a pain indeed).  This is easy to configure, see
https://wiki.archlinux.org/title/GTK#Emacs_key_bindings.

2. For page movements ({M,C}-v), you'd need a browser extension such as
Saka key, https://addons.mozilla.org/en-US/firefox/addon/saka-key/.

3. The ultimate solution would be to surrender to EXWM (Emacs X Window
Manager), and to its simulation keys.


--
André A. Gomes
"Free Thought, Free World"