RE: [External] : Re: Gitlab Migration

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> Maybe Emacs project should be better at informing users 
> about Emacs bug tracker: ... and this one: ... and
> debbugs package for browsing bugs directly from Emacs?

(Apologies for not really following this thread.)

1. It might not help with the general process of tracking
or searching bugs, but we do have a `Help' menu item for
submitting a bug report: `Send Bug Report'.  That should
be an easy entry, in principle.

Of course that just invokes `report-emacs-bug'.  Maybe
the `report-emacs-bug' interaction scares some users and
could be made less scary (dunno).

3. Something else that might help a bit is to include,
in each mail sent to a bug thread, a debbugs.gnu.org 
link to that post.

4. And yes, a web interface (at debbugs.gnu.org or not)
that lets you not only view, but also reply to, posts
would be good.

5. And debbugs.gnu.org search sucks.  Or at least I suck
at trying to find anything using it.

Re: [External] : Re: Gitlab Migration

[Arthur Miller]

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

>> Maybe Emacs project should be better at informing users 
>> about Emacs bug tracker: ... and this one: ... and
>> debbugs package for browsing bugs directly from Emacs?
>
> (Apologies for not really following this thread.)
>
> 1. It might not help with the general process of tracking
> or searching bugs, but we do have a `Help' menu item for
> submitting a bug report: `Send Bug Report'.  That should
> be an easy entry, in principle.
It is an easy entry, but it is not so much about reporting bugs, but
contributing to emacs. Some people think it is easier to search through web
bases "issues" interface to discover if their issue is already reported, covered
etc.

> Of course that just invokes `report-emacs-bug'.  Maybe
> the `report-emacs-bug' interaction scares some users and
> could be made less scary (dunno).
>
> 3. Something else that might help a bit is to include,
> in each mail sent to a bug thread, a debbugs.gnu.org 
> link to that post.

That sounds like a good idea in my eyes.

> 4. And yes, a web interface (at debbugs.gnu.org or not)
> that lets you not only view, but also reply to, posts
> would be good.
>
> 5. And debbugs.gnu.org search sucks.  Or at least I suck
> at trying to find anything using it.

Re: [External] : Re: Gitlab Migration

[tomas]

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

On Thu, Aug 26, 2021 at 09:41:06PM +0000, Drew Adams wrote:
> > Maybe Emacs project should be better at informing users 
> > about Emacs bug tracker: ... and this one: ... and
> > debbugs package for browsing bugs directly from Emacs?
> 
> (Apologies for not really following this thread.)

[...]

> 5. And debbugs.gnu.org search sucks.  Or at least I suck
> at trying to find anything using it.

My starting point would be something like [1].

(And yes, I think we old jeezers have the responsibility to show
folks ways to use the Internet instead of being used by it ;-)

There is some obvious low hanging fruit there, the first which comes
to mind would be to add a subdomain for each package: this would
leverage the search engine's `site' filter.

Of course there's that higher hanging fruit: add a useful search
facility to debbugs. I hear that there are project funding resources
with Debian in search of a project [2]. Perhaps Gnu and Debian could
band together for that? Some GSOC?

Cheers

[1] https://html.duckduckgo.com/html?q=redisplay+idle+site:debbugs.gnu.org
[2] https://salsa.debian.org/freexian-team/project-funding

 - t

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

Re: [External] : Re: Gitlab Migration

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Thu, 26 Aug 2021 21:41:06 +0000
> Cc: "larsi@gnus.org" <larsi@gnus.org>,
>  "philipk@posteo.net" <philipk@posteo.net>,
>  "danflscr@gmail.com" <danflscr@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> 5. And debbugs.gnu.org search sucks.  Or at least I suck
> at trying to find anything using it.

I actually find the debbugs search engine superior to at least what we
have on the mailing lists.

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> > 5. And debbugs.gnu.org search sucks.  Or at least I suck
> > at trying to find anything using it.
> 
> I actually find the debbugs search engine superior to at least what we
> have on the mailing lists.

It may be superior; I have no idea, as I'm inferior to it.

I can easily search the emails I hold onto.  Easily and
flexibly.  Not that searching emails with an email client
is ideal, but at least a mortal can find things that way.

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> > Yep, that mirrors what I'm seeing as well. Many younger users really use
> > it primarily to provide a unique identifier (login) and for when they
> > have to deal with institutions that don't provide other alternatives.
> 
> I think part of the rush is nudge pressure applied by the Big Ones.
> It's not possible to monetise mail in the same way as it is possible
> to do with whatsapp, tiktok, twitter and the uncountable more or less
> "secure" messengers popping up here and there.

+1.

Email is less of an Only-Mine-All-Mine!!! mine for
surveillance capitalism to mine.

And being still relatively new, the "instant
notification" of Slack etc. seems handy.  Wait till
there's as much incoming traffic for you there, as
there is your email inbox.

Yeah, you can turn off notifications, but they seem
to be touted as one of the killer-app features of
"always-on" Slacking (much appreciated by mgrs, in
particular).

> The nice thing about those communications platforms (nice from the
> perspective of the venture capitalist) is that there's no separation
> of platform and UI, so they get direct control of the user's perception.
> 
> I opt out of that. Count me in whenever there is a platform which
> separates transport and clients the way mail does and has at least
> some choice of client applications with a perspective of diversity.

+1.

> > The other interesting trend I'm seeing is with many companies now
> > working to minimise email as part of their internal/external workflows.
> > Many companies are finding it a huge resource sink, cause of unnecessary
> > stress/pressure on staff, source of significant security concerns and a
> > real problem for records management.
> 
> I have watched this process around the 2010s in one company. The
> decision was made at top level (they were convinced by some Microsoft
> salesperson [1] to switch to Office 365 instead of mail, because...
> mail is old). Today, they still use mail, but have outsourced their
> whole communications infrastructure to Microsoft, GDPR be dammed.
> 
> The resource sink, stress and pressure stemmed rather from that
> change, for those who had to use that "new" platform (not to
> talk about staff layoffs for the old sysadmins, but I disgress).
> 
> Those having taken the decisions didn't have to use O365, they
> have secretaries. For them, it was success.
> 
> This may sound like an off-topic rant, but I'm serious. Not all
> of this "mail is old" meme is for real. Some of it is propaganda
> (I emphasise: /some/ of it). So we should take each critique
> and address it one by one.
> 
> To put it in other words: I won't pay a wholesale-ish "mail is
> old" argument. I want to have more solid stuff.

Agree.

RE: [External] : Re: Gitlab Migration

[Drew Adams]

Shiny new toy syndrome.  Even if not really
so new.

(Not at all saying you're infected, Tim.
Just saying it's out there, endemic here &
there, if not yet pandemic.)

> The problem with that argument is that it doesn't explain the behaviour
> of young adults and teenagers. Nobody has 'nudged' them to move away
> from email - they were never into it. It simply isn't a communication
> medium they are interested in. For them, it is about IM, instagram,
> tiktok etc. Some of it is because of marketing, a lot of it is because
> of peer influences. Regardless, email is of no interest to them.

They're already pwned, lock, stock, and barrel.

Even seemingly self-determined "peer influence"
is influenced - by the same pwners.  That's what
they do.

And the pwnees _are_ (actively) "nudged" - to
stay pwned.  They're even led to proudly show
off their guilded, fools-gold ankle bracelets.

> ... this largely pre-dates the drive to move away from email.
> Email, regardless how it is provided, is a problem for companies. It is
> a major source of security problem, it is a nightmare for records
> management, policy and regulation compliance and a major impediment in
> business workflow automation. While I doubt any company will stop using
> email completely, they are definitely moving way from having it as a key
> technology in their business processes.

Sure.  Compliance is a headache.  History and
its footprints are a bother.  Being able to go
back and see who did and said what is, well,
something that some would rather evade/avoid.

> The problems with email for business are real. While lots of companies
> are pushing their alternative solutions for various reasons, it doesn't
> remove the reality that it fails for business on many levels.

That just means that email isn't the answer
to every problem.  The Message is not The
Messiah.

> the key point to note is that I don't think anyone is saying we need to
> get rid of the email based stuff we currently have - what people are
> asking for is to have an alternative interface..., not instead of.

Additional interfaces/UXes, yes.

> Arguments about one being better than the other are pointless

Pointing out relevant, relative advantages
isn't pointless.  Not if there's a chance of
that "instead of".

And even if there's no such chance, it's not
pointless because it can affect design of
alternatives to fit together with an email
interface.

> What people are asking for is support for a
> broader set of preferences.

I think so, and I hope for that to happen.

Re: [External] : Re: Gitlab Migration

[tomas]

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

On Fri, Aug 27, 2021 at 04:59:32PM +0000, Drew Adams wrote:
> > > Yep, that mirrors what I'm seeing as well. Many younger users really use
> > > it primarily to provide a unique identifier (login) and for when they
> > > have to deal with institutions that don't provide other alternatives.
> > 
> > I think part of the rush is nudge pressure applied by the Big Ones.
> > It's not possible to monetise mail [...]

[...]

> Email is less of an Only-Mine-All-Mine!!! mine for
> surveillance capitalism to mine.
> 
> And being still relatively new, the "instant
> notification" of Slack etc. seems handy.  Wait till
> there's as much incoming traffic for you there, as
> there is your email inbox.

Heh. You also a Slack victim? When they introduced it at
$COMPANY (before O365 took all), I decided that it violates
the Convention of Geneva.

Having a browser open all the time, OK. But having the
browser bouncing up'n down while I try to concentrate
on a database schema... that's cruel ;-)

(I don't work for $COMPANY anymore).

Cheers
 - t

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

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> For younger people, I suspect part of it is just a perception of email
> as being old and outdated and not fitting as well with their 'style' of
> communication, which tends to be about short messages and group chat in
> near 'real time'.

Shiny New Toy syndrome, aka Flavor Of The Month.

(Not at all limited to youth, of course.)
___


Corporate "social media": antisocial

Re: [External] : Re: Gitlab Migration

[Tim Cross]

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

>> For younger people, I suspect part of it is just a perception of email
>> as being old and outdated and not fitting as well with their 'style' of
>> communication, which tends to be about short messages and group chat in
>> near 'real time'.
>
> Shiny New Toy syndrome, aka Flavor Of The Month.
>
> (Not at all limited to youth, of course.)

Sadly, I think comments like this are all too frequent from us oldies.
They feel simplistic, overly dismissive and somewhat arrogant. For youth,
nearly everything is shiny and new - we forget that for us, email was
shiny and new once upon a time. The difference could just as easily be
due to us 'old dogs' failing to learn new tricks and failing to
recognise the evolution in social interaction brought about by new
technologies. If it is just the flavour of the month, it is a very long
month and I see little evidence of that flavour becoming stale. I'm sure
it will continue to evolve, but feel it is very unlikely to go back the
other way. 

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

I publish a page about nasty things about Slack, but I only cover
those which are nasty in moral terms.  Those which are merely
painfully annoying, are out of scope.

However, do you think that if the Slack client were free
it would be possible to correct the painfully annoying behavior?
If so, that relates the problem to the injustice of the nonfree client
and I could include it.

But I would need a reference -- a page that describes the behavior and
why it is annoying.  Can you find one?  Or make 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

[Drew Adams]

> >> For younger people, I suspect part of it is just a perception of email
> >> as being old and outdated and not fitting as well with their 'style' of
> >> communication, which tends to be about short messages and group chat in
> >> near 'real time'.
> >
> > Shiny New Toy syndrome, aka Flavor Of The Month.
> > (Not at all limited to youth, of course.)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Sadly, I think comments like this are all too
> frequent from us oldies.

"Comments like these" is facile dismissal.

> They feel simplistic, overly dismissive and
> somewhat arrogant. 

That's exactly what that comment you just made
feels like.  Your complaint does what it
complains about.

> For youth, nearly everything is shiny and new
> - we forget that for us, email was shiny and
> new once upon a time.

I don't forget it.  It's you who laid this on
"younger people", not I.  Your description.

> The difference could just as easily be due
> to us 'old dogs' failing to learn new tricks
> and failing to recognise the evolution in social
> interaction brought about by new technologies.

I don't see it as old vs new dogs.  There are
plenty of old dogs who new-trick all the time.

Shiny New Toy syndrome doesn't respect age.
The toys might differ on average for different
age groups, but that's about all.

> If it is just the flavour of the month, it is
> a very long month and I see little evidence of
> that flavour becoming stale. I'm sure it will
> continue to evolve, but feel it is very unlikely
> to go back the other way.

Define "back the other way".  What dichotomy
are you hinting at: email versus ____?

What's the flavor you're talking about?
Everything other than email?  Or a particular
thing, such as Slack?  Wait and see how long
any particular remains in the Top 10.

There's not really anything new about "short
messages and group chat" versus long messages
and one-on-one.  What's new (and ever-changing)
are the possible forms.

Or if you mean social media powerhouses such
as Facebook then sure, there's no Facebook of
the month.  Yesterday's shiny new Instagram is
just Facebook.  It'll likely be a while before
Facebook and Google go the way of old IBM.
___

There's a difference between (1) being attracted
to something new and (2) being distracted toward
whatever pops into the field of view and away
from what was noticed a millisecond ago.  #2 is
what Shiny New Toy Syndrome is about.

And no, as I said, the malady is _not at all_
limited to youth.  Its underlying, unseen
foundation is _commercial_.  We (of all ages)
succumb to it in part because what appears on
the shelves changes.
___

Anyway, this is fairly off-topic now.

Your point was about youth's perception of email
as "old".  My point was that a view of things as
"old" can be a sign of Shiny New Toy syndrome -
a relentless, overwhelming appetite for "new".

That's not youth; it's market society.

(And no, not everyone is infected to the same
degree.)

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

  > > They feel simplistic, overly dismissive and
  > > somewhat arrogant. 

  > That's exactly what that comment you just made
  > feels like.  Your complaint does what it
  > complains about.

What this says to me is that it isn't a matter of a substantive
issue on which someone is right or wrong.  It's that we've fallen
into a pattern of not being kind to each other, and retaliating
to each other.

Maybe it would be useful for various people to look at the messages
they have previously written, and look for ways to have said
them more kindly.

See https://gnu.org/philosophy/kind-communication.html.

-- 
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

[João Távora]

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

On Thu, Aug 26, 2021, 22:53 Arthur Miller <arthur.miller@live.com> wrote:

> Drew Adams <drew.adams@oracle.com> writes:
>
> >>
> > 3. Something else that might help a bit is to include,
> > in each mail sent to a bug thread, a debbugs.gnu.org
> > link to that post.
>
> That sounds like a good idea in my eyes.


Apologies for chiming in late, but this is too interesting of an idea
to let go.

I think adding it to one or two lines in a kind of signature like:

   [[ view full bug history in https://debbugs.gnu.org/.../12345 ]]
   [[ repliers consider keeping these lines ]]

... in the same situations that the subject line is mutated.  Could
be a simple to implement and very useful idea.

João

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

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> I think adding it to one or two lines in a kind of signature like:
>
>  [[ view full bug history in https://debbugs.gnu.org/.../12345]]
>  [[ repliers consider keeping these lines ]]
>
> ... in the same situations that the subject line is mutated.
> Could be a simple to implement and very useful idea.

The link would be to the specific post within the
bug thread.  So instead of "view full bug history"
I'd suggest something like "View in bug thread"
or "view in context" (or "full history" instead
of "thread" or "context").

It's about viewing the particular post, but within
the full thread.

Re: [External] : Re: Gitlab Migration

[João Távora]

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

On Mon, Aug 30, 2021, 17:51 Drew Adams <drew.adams@oracle.com> wrote:

> > I think adding it to one or two lines in a kind of signature like:
> >
> >  [[ view full bug history in https://debbugs.gnu.org/.../12345]]
> >  [[ repliers consider keeping these lines ]]
> >
> > ... in the same situations that the subject line is mutated.
> > Could be a simple to implement and very useful idea.
>
> The link would be to the specific post within the
> bug thread.  So instead of "view full bug history"
> I'd suggest something like "View in bug thread"
> or "view in context" (or "full history" instead
> of "thread" or "context").
>
> It's about viewing the particular post, but within
> the full thread.
>

Fine.

Who could make this happen? Lars?

João

>

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

Re: [External] : Re: Gitlab Migration

[André A. Gomes]

João Távora <joaotavora@gmail.com> writes:

> On Thu, Aug 26, 2021, 22:53 Arthur Miller <arthur.miller@live.com>
> wrote:
>
>     Drew Adams <drew.adams@oracle.com> writes:
>
>     >>
>     > 3. Something else that might help a bit is to include,
>     > in each mail sent to a bug thread, a debbugs.gnu.org
>     > link to that post.
>
>     That sounds like a good idea in my eyes.
>
> Apologies for chiming in late, but this is too interesting of an idea
> to let go.

If my understanding of this thread is correct, this is exactly what
happens when you submit a bug report in GNU Guix.

Not only it's doable, but it's already written somewhere :)


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

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

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

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: [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: 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: [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: 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

[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: [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: 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: [External] : Re: Gitlab Migration

[Drew Adams]

> ;; Convenient
> (setq scroll-preserve-screen-position t)
> (setq visual-order-cursor-movement t)
> (setq-default tab-width 4)
> (global-auto-revert-mode)
> (auto-save-visited-mode)
> (indent-tabs-mode -1)

I won't speak to those, apart from agreeing
about `indent-tabs-mode'.  But I have doubts
about `auto-save-visited-mode' (as opposed
to just `auto-save-mode').

> ;; Compatibility with other editors
> (electric-indent-mode)
> (electric-pair-mode)
> (cua-mode)

I'm not in favor of turning on those electric
modes by default.  That behavior might be
compatible with some other editors, but it's
not compatible with the default behavior of
other other-editors.  And it's not compatible
with many other (non-editor) apps that allow
code and other-text editing.

As for `cua-mode': That's more or less what
the whole question of `C-x' etc. is about, I
think.  I'm not in favor of turning it on by
default, but it's not a problem for me if
that happens - easy enough to turn it off
individually.

Even if `cua-mode' remains off by default,
however, I'm in favor of Emacs turning ON
`delete-selection-mode' by default.  And not
only for other-editor compatibility but also
for general convenience.

(I think that should have been done back
when we turned on `transient-mark-mode' by
default.)

> ;; Session
> (desktop-save-mode)

Not in favor of that, but OK; it's easy for
an individual to turn it off.

> ;; Visual
> (tool-bar-mode -1)
> (global-visual-line-mode)
> (show-paren-mode)

+1 for `show-paren-mode'.  But maybe not
globally - does it make a lot of sense, by
default, for non-programming modes?

Not in favor of the others, but OK (easy
to flip).  I don't use a tool bar, but it
might be helpful for newbies - at least
that was the idea.

(I offer `tool-bar+.el', which lets you
hide the tool-bar and open it by clicking
a pseudo-menu in the menu-bar.  And it lets
you have tool-bars for only specific frames.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus)

I turn on visual-line only when I'm in a
buffer with text that someone or something
else wrote, which has  l o n g  lines.
Maybe we should have a line-length option
that does this automatically (?).

> Some questions:
> 
> 1. Do we want to split the audience to writers and programmers because
>    it impacts the implementation and the messaging as well.

I don't think we do, but maybe the devil
is in the details.  Elaborate perhaps?

Remember that the same person can be a
member of multiple audiences, depending
on the context.  That's kinda what major
modes are about (but I understand your
suggestion as being about more global
messaging).

> 2. Do we also install popular and relevant Elpa packages as part of the
>    profile setup or do we cross the line at variable setting? what
>    about keybindings?

A "profile" setting for an individual
could certainly specify installing or
loading whatever.  A stock profile (i.e.
a customizable template) could do that also.

What, today, prevents someone from writing
a package (or a theme or any other code)
that, in effect, provides such a "profile"?

If nothing, then why not just leave it to
those interested to create such packages,
themes, or whatever, and see how well they
get taken up?  People can add such things
to GNU ELPA or other repositories, right?

Wouldn't that be a good way to see whether
(and how) such a feature should (and could)
be added to Emacs?

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

[Daniel Fleischer]

Drew Adams [2021-09-04 Sat 16:32] wrote:

> I won't speak to those, apart from agreeing
> about `indent-tabs-mode'.  But I have doubts
> about `auto-save-visited-mode' (as opposed
> to just `auto-save-mode').

These #file# are not what people expect as well as doing recovery. Auto
save in the actual file is more consistent with others. 

> I'm not in favor of turning on those electric
> modes by default.  That behavior might be
> compatible with some other editors, but it's
> not compatible with the default behavior of
> other other-editors.  And it's not compatible
> with many other (non-editor) apps that allow
> code and other-text editing.

Please expand; we're trying to be concrete here and gauge what's the
most common behavior in the editors landscape w.r.t different features. 

> Not in favor of the others, but OK (easy
> to flip).  I don't use a tool bar, but it
> might be helpful for newbies - at least
> that was the idea.

In my knowledge, there is no other editor - code or not - that has a UI
button for saving, copying or pasting. The design language has changed
so unless it's redesigned, it's a bit confusing. 

> Remember that the same person can be a
> member of multiple audiences, depending
> on the context.  That's kinda what major
> modes are about (but I understand your
> suggestion as being about more global
> messaging).

It's  a great point, because we can set nice defaults that fit either
prose writing or programming; can we do both?

> What, today, prevents someone from writing
> a package (or a theme or any other code)
> that, in effect, provides such a "profile"?
>
> If nothing, then why not just leave it to
> those interested to create such packages,
> themes, or whatever, and see how well they
> get taken up?  People can add such things
> to GNU ELPA or other repositories, right?

I don't understand; of course people can create any package they want
and change Emacs behavior but we're looking for ways to make Emacs
easier to use for new users by redefining defaults, changing keybinding
to be comparable to other tools, and perhaps, adding some additional
functionality from Elpa to round the experience. 

-- 

Daniel Fleischer

RE: [External] : Re: Gitlab Migration

[Drew Adams]

> > I won't speak to those, apart from agreeing
> > about `indent-tabs-mode'.  But I have doubts
> > about `auto-save-visited-mode' (as opposed
> > to just `auto-save-mode').
> 
> These #file# are not what people expect as well as doing recovery. Auto
> save in the actual file is more consistent with others.

That may be true; I don't doubt it (or doubt you).

But Emacs intentionally and forthrightly has
buffers, as a separate thing and user concept
from files.  People don't expect buffers, but
they're important to Emacs and using Emacs,
even for newbies.

In Emacs, does it make sense to automatically
save all changes to a buffer periodically?
Out of the box?  I don't think so, a priori,
but let's see what others think about that.

There's a reason that Emacs auto-saves in a
separate file (and gives you ways to sync).
And that reason is...: BUFFERS are a thing.

> > I'm not in favor of turning on those electric
> > modes by default.  That behavior might be
> > compatible with some other editors, but it's
> > not compatible with the default behavior of
> > other other-editors.  And it's not compatible
> > with many other (non-editor) apps that allow
> > code and other-text editing.
> 
> Please expand; we're trying to be concrete here and gauge what's the
> most common behavior in the editors landscape w.r.t different features.

I was thinking of `electric-pair-mode' (not the
indenting), sorry.  Do most other editors
automatically insert closing delimiters etc.?
Even for non-code text?

I use doc-production tools all day long, for
software doc (code), and none of the tools I
and other writers use do that, even for code
examples.  (And I'm glad they don't.)

I can see Emacs turning on `electric-pair-mode'
automatically for this or that programming mode,
or even for all programming modes, using
`electric-pair-local-mode' on a mode hook.  But
turning it on globally?  Why would that be a
good thing?

(Again, I wouldn't have a problem with such a
change, for my own use - easy enough to turn
it off.)

> > Not in favor of the others, but OK (easy
> > to flip).  I don't use a tool bar, but it
> > might be helpful for newbies - at least
> > that was the idea.
> 
> In my knowledge, there is no other editor - code or not - that has a UI
> button for saving, copying or pasting. The design language has changed
> so unless it's redesigned, it's a bit confusing.

You won't get any argument from me about what
belongs in Emacs tool bars.  I don't use the
tool-bar, and I don't know what's best wrt it
for emacs -Q - either in terms of whether it
should be on or off or what buttons it should
contain.

> > Remember that the same person can be a
> > member of multiple audiences, depending
> > on the context.  That's kinda what major
> > modes are about (but I understand your
> > suggestion as being about more global
> > messaging).
> 
> It's  a great point, because we can set nice defaults that fit either
> prose writing or programming; can we do both?

How about finer-grained than just prose and
code?  We have major modes, and code modes
inherit from a common ancestor.

> > What, today, prevents someone from writing
> > a package (or a theme or any other code)
> > that, in effect, provides such a "profile"?
> >
> > If nothing, then why not just leave it to
> > those interested to create such packages,
> > themes, or whatever, and see how well they
> > get taken up?  People can add such things
> > to GNU ELPA or other repositories, right?
> 
> I don't understand; of course people can create any package they want
> and change Emacs behavior but we're looking for ways to make Emacs
> easier to use for new users by redefining defaults, changing keybinding
> to be comparable to other tools, and perhaps, adding some additional
> functionality from Elpa to round the experience.

And how to know what solution is good for that?
Why not encourage such experiments, and see how
actual users actually take up the results?

As you say, it's about possibly modifying Emacs.
How that's done, including just what's done, is
the question.  Let 100 flowers bloom, and then
see which are most fragrant (as smelled by users
and Emacs developers).  Compare actual Emacs
realizations of what you're aiming at.

Re: [External] : Re: Gitlab Migration

[Daniel Fleischer]

Drew Adams [2021-09-04 Sat 19:14] wrote:

> I was thinking of `electric-pair-mode' (not the
> indenting), sorry.  Do most other editors
> automatically insert closing delimiters etc.?
> Even for non-code text?

Code editors YES, word processors NO.  You're exactly right with that;
we need to split our modifications and put them on either prog-mode or
text-mode.

> You won't get any argument from me about what
> belongs in Emacs tool bars.  I don't use the
> tool-bar, and I don't know what's best wrt it
> for emacs -Q - either in terms of whether it
> should be on or off or what buttons it should
> contain.

We are not talking here about modifying default (-Q) Emacs; we're
talking about creating an OPT-IN experience for new users that will
increase the probability of them liking and using Emacs in the future,
increasing Emacs popularity and community.

So this specific discussion is on whether adding certain defaults will
likely make new users more comfortable or not.  It will have no effect
on users who would not turn this feature ON.

> And how to know what solution is good for that?
> Why not encourage such experiments, and see how
> actual users actually take up the results?

I don't think people who start using Emacs and create their own packages
is the demographics for these profiles.  We can do experiments by
introducing the feature and doing some surveys. 

-- 

Daniel Fleischer

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: [External] : Re: Gitlab Migration

[Tim Cross]

Daniel Fleischer <danflscr@gmail.com> writes:

> Drew Adams [2021-09-04 Sat 19:14] wrote:
>
>> I was thinking of `electric-pair-mode' (not the
>> indenting), sorry.  Do most other editors
>> automatically insert closing delimiters etc.?
>> Even for non-code text?
>
> Code editors YES, word processors NO.  You're exactly right with that;
> we need to split our modifications and put them on either prog-mode or
> text-mode.
>
>> You won't get any argument from me about what
>> belongs in Emacs tool bars.  I don't use the
>> tool-bar, and I don't know what's best wrt it
>> for emacs -Q - either in terms of whether it
>> should be on or off or what buttons it should
>> contain.
>
> We are not talking here about modifying default (-Q) Emacs; we're
> talking about creating an OPT-IN experience for new users that will
> increase the probability of them liking and using Emacs in the future,
> increasing Emacs popularity and community.
>
> So this specific discussion is on whether adding certain defaults will
> likely make new users more comfortable or not.  It will have no effect
> on users who would not turn this feature ON.
>
>> And how to know what solution is good for that?
>> Why not encourage such experiments, and see how
>> actual users actually take up the results?
>
> I don't think people who start using Emacs and create their own packages
> is the demographics for these profiles.  We can do experiments by
> introducing the feature and doing some surveys. 

It might be worthwhile looking at some of the existing configuration
packages and perhaps use what they do for inspiration. For example
https://github.com/technomancy/better-defaults - there are others
mentioned on the emacs wiki. Likewise, extracting some of the more
simple tweaks from prelude or Purcell's .emacs.d may e informative as
both these 'distributions' are quite popular and unlike spacemacs/doom,
are not based around evil mode. Things which are common to both of these
are likely good candidates for inclusion. Also worth noting that both
these setups make a distinction between 'pros' and 'programming', which
I think is preferable to global settings for many options. 

Re: [External] : Re: Gitlab Migration

[Daniel Fleischer]

Tim Cross <theophilusx@gmail.com> writes:

> It might be worthwhile looking at some of the existing configuration
> packages and perhaps use what they do for inspiration. For example
> https://github.com/technomancy/better-defaults - there are others
> mentioned on the emacs wiki. Likewise, extracting some of the more
> simple tweaks from prelude or Purcell's .emacs.d may e informative as
> both these 'distributions' are quite popular and unlike spacemacs/doom,
> are not based around evil mode. Things which are common to both of these
> are likely good candidates for inclusion. Also worth noting that both
> these setups make a distinction between 'pros' and 'programming', which
> I think is preferable to global settings for many options. 

Thanks, that's a good idea. 

-- 

Daniel Fleischer

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

[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: [External] : Re: Gitlab Migration

[Drew Adams]

> I've only used emacs for about one year (had been using vim for
> like 10 years before that), so all the "old" emacs way of doing
> things (both usage and development) have been in fact very new and
> shiny to me, but as it turns out overall I very much prefer these
> "old" ways than the new ways that are older for me :)

C'mon Yuchen.  We know you're just an old fart IRL. ;-)

 "Ah but I was so much older then.
  I'm younger than that now."

   - My Back Pages, B.A. Zimmerman

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 (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: [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: 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)

[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)

[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: [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: 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: [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: 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: [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: 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: 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: [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"

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: 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

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