[External] : Re: Gitlab Migration

[External] : Re: Gitlab Migration

[Drew Adams]

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

Would we?  Maybe, maybe not.

Pro: Killing text is similar to cutting text.

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

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

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

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

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

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

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

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

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

Re: [External] : Re: Gitlab Migration

[Stefan Kangas]

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

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

Fully agreed.

Re: [External] : Re: Gitlab Migration

[Stefan Monnier]

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

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

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

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

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

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


        Stefan

Re: [External] : Re: Gitlab Migration

[Tim Cross]

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

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

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

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

[Stefan Monnier]

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

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

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

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

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


        Stefan

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

[Dmitry Gutov]

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

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

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

Re: Keybinding styles

[Stefan Monnier]

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

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


        Stefan

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

[Yuan Fu]

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

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

Yuan

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

[Eli Zaretskii]

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

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

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

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

[Drew Adams]

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

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

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

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

[Yuan Fu]

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

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

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

Yuan

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

[Eli Zaretskii]

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

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

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

[Richard Stallman]

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

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

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

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

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

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

[Dmitry Gutov]

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

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

Re: Keybinding styles

[Daniel Fleischer]

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

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

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

-- 

Daniel Fleischer

Re: Keybinding styles

[Stefan Kangas]

Daniel Fleischer <danflscr@gmail.com> writes:

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

Or anyone else, for that matter.

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

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

Re: Keybinding styles

[tomas]

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

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

[...]

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

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

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

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

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

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

All of that my hunches, of course.

Cheers

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

 - t

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

Re: Keybinding styles

[Bird]

Yuan Fu <casouri@gmail.com> writes:

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

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

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

[Tim Cross]

Yuan Fu <casouri@gmail.com> writes:

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

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

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

[John Yates]

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

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

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

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

/john

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

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

[Eli Zaretskii]

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

What would such a move mean in practical terms?

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

[Richard Stallman]

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

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

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

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

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

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

[John Yates]

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

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

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

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

/john

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

[Richard Stallman]

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

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

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

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

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

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

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

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

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

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

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

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

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



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

Re: Keybinding styles

[André A. Gomes]

Richard Stallman <rms@gnu.org> writes:

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

Why is it outside the scope of the GNU Project?

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

1. Convert the Emacs manual from texi to org.

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

3. Export the org manual to texi.


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

Re: Keybinding styles

[Eli Zaretskii]

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

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

Re: Keybinding styles

[John Yates]

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

I imagined something more along these lines:

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

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

/john

Re: Keybinding styles

[Eli Zaretskii]

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

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

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

Re: Keybinding styles

[André A. Gomes]

Eli Zaretskii <eliz@gnu.org> writes:

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

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

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

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


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

Re: Keybinding styles

[Stefan Kangas]

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

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

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

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

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

Re: Keybinding styles

[Eli Zaretskii]

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

Isn't that what I said above?

Re: Keybinding styles

[Richard Stallman]

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

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

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

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

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

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

Re: Keybinding styles

[Alexandre Garreau]

Le mercredi 15 septembre 2021, 22:15:00 CEST Richard Stallman a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > But I brought the subject from another perspective.  When a user
>   > runs
>   > (info-emacs-manual), shouldn't it reflect Emacs' state?  Concretely,
>   > if
>   > I rebind C-x C-f to something else, the manual should tell me.  It
>   > seems to me like a missed opportunity.
> 
> That would fit into the spirit of Emacs documentation, but calling it
> a "missed opportunity" supposes that we have an opportunity to do it.
> 
> Do we have an opportunity?  Maybe, but I tend to doubt it.  I tend to
> think that doing this correctly is a big job; a simple search and
> replace will get confused and make mistakes.
> 
> I could be mistaken.  If it turns out to be easy, why not?  But I don't
> think this is important enough to be worth a lot of work.

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

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

Re: Keybinding styles

[Eli Zaretskii]

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

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

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

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

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

We cannot make unilateral changes in this area.

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

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

Re: Keybinding styles

[Eli Zaretskii]

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

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

Re: Keybinding styles

[Richard Stallman]

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

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

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

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

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

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

  > 3. Export the org manual to texi.

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

Eli wrote:

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

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

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

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

Re: [External] : Re: Gitlab Migration

[Stefan Kangas]

Tim Cross <theophilusx@gmail.com> writes:

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

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

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

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

This would be my ideal future, as well.

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

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

RE: [External] : Re: Gitlab Migration

[Drew Adams]

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

It's a matter of opinion, yes.

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

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

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

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

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

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

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

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

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

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

Re: [External] : Re: Gitlab Migration

[Stefan Monnier]

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

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

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

And yet you did.


        Stefan

RE: [External] : Re: Gitlab Migration

[Drew Adams]

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

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

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

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

(Do you, really?)

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

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

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

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

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

Re: [External] : Re: Gitlab Migration

[Stefan Monnier]

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

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

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


-- Stefan

RE: [External] : Re: Gitlab Migration

[Drew Adams]

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

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

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

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

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

Re: [External] : Re: Gitlab Migration

[John Yates]

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

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

/john

Re: [External] : Re: Gitlab Migration

[Richard Stallman]

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

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

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

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



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

Re: [External] : Re: Gitlab Migration

[Barry Fishman]

On 2021-09-06 23:16:19 -04, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > `C-x` for "Cut" has been standard for a lot more than a decade.
>
>   > CUA was first published in 1987, so nearly three and a half decaces :-)
>
> Emacs (the PDP-10 version) was first released in 1976.
> CUA came second.

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

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

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

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

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

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

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

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

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

-- 
Barry Fishman

Re: [External] : Re: Gitlab Migration

[Richard Stallman]

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

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

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

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

Re: [External] : Re: Gitlab Migration

[André A. Gomes]

Richard Stallman <rms@gnu.org> writes:

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

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

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

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

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


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

Gitlab Migration

[Daniel Fleischer]

[-- Attachment #1: Type: text/html, Size: 4341 bytes --]

Re: Gitlab Migration

[Philip Kaludercic]

Hi,

Daniel Fleischer <danflscr@gmail.com> writes:

> One issue which I think is important is the move to a new VC system,
> e.g. Gitlab. I started reading the relevant threads and I'm not sure
> where the issue stands today. Let me recap the benefits:
>
> 1 The need for new people to join the community and help. Newer
>  (younger) people will be more familiar with the newer VC platforms
>  (github/lab and similar). These are not only developers but regular
>  users who want to report an issue (bug) or suggest a feature.

Shouldn't it be easier to send an email than create an account, navigate
some web UI and fill in some form? The same goes for
patches. Git{Lab,Hub} usually requires leaving the development context,
to prepare a patch online, that requires "forking", more navigation and
more fora. Just today I tried preparing a "pull request" on GitLab and
didn't manage to do so, because it insisted on merging the commit into
my own repository, no matter what I did. Just attaching a git patch
seems much easier.

>  Lowering the bar for participation is the key to growing Emacs and
>  the community.

I think that showing people that they biases against mailing list
development might be illegitimate would be a viable alternative.

> 2 Having the code + issues + discussions in the same place as opposed
>  to now, where the code and discussions (lists) are in 3 different
>  places (Savannah, Gnu mailing lists and Gnu bug tracker). With a
>  modern VC system, one can jump easily between issues, discussions,
>  code commits back and forth easily as opposed to now, where if it's a
>  bug you can use its number to search lists and commits messages but
>  if it's a discussion, it's not "connected" to anything.

Correct me if I am wrong, but all the discussions are at least mirrored
on the mailing lists. Savannah is just for project management and the
GNU bug tracker uses the mailing list too. It is more uniform too, as
everything is just a mail-message, not part of a forcefully linearized
thread. Commenting on a issue, "pull request" or a patch is always just
responding to a message.

That being said, I wouldn't mind prettier web interface for the mailing
list (I think that the Guix project is doing well on that front).

> Possible issue:
>
> 1 Being able to use Emacs for all these needs. One way is being able to
>  interact with the VC system using emails, i.e. issues, features,
>  discussions should have a nice and efficient email interface in
>  addition to using a website. Another approach is using the wonderful
>  Magit and Forge packages. Forge currently is lacking the discussions
>  feature but has a very good git + pull-requests + org-mode
>  integration abilities.

I remember Sourceforge being suggested as an alternative to Gitlab, but
the software is currently still in a beta stage (AFAIR).

> 2 Changing processes, how people operate. Whether it's the technical
>  aspect of a pull-request approval vs. patch submission to the more
>  conceptual change of dealing with "issues" representing bugs, ideas,
>  feature requests or general discussions instead of mailing lists.
>  These changes shouldn't be too disruptive. However I do believe a
>  small price has to be paid in order to go from one local minima of
>  effort in a given practice to another, hopefully better local minima.
>
> Does this describe well the current situation?
> What areas need attention in order to facilitate the change?
>
> Thanks for any feedback.
>
> Daniel Fleischer
>

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form? The same goes for
> patches. Git{Lab,Hub} usually requires leaving the development context,
> to prepare a patch online, that requires "forking", more navigation and
> more fora. Just today I tried preparing a "pull request" on GitLab and
> didn't manage to do so, because it insisted on merging the commit into
> my own repository, no matter what I did. Just attaching a git patch
> seems much easier.

It seems like it should be easier to just send a patch, but feedback
we're getting shows that it's not for a number of developers.  Many
don't use mail at all for development, and all they're used to is the
GitLab/Hub way of doing it.

So it's easier for them -- it feels safe and familiar for them to do
development by clicking around in a web browser.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Gitlab Migration

[Dmitry Gutov]

On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
> Many
> don't use mail at all for development, and all they're used to is the
> GitLab/Hub way of doing it.

Email is used by virtually everyone (for example, to receive 
notifications about others' actions or messages), what's "unusual" for 
many is sending patches over email. Or inlining them in comments/messages.

> So it's easier for them -- it feels safe and familiar for them to do
> development by clicking around in a web browser.

We also have a bunch of formal rules for submissions which tend to seem 
intimidating. A CI with an automated checker running against all PRs can 
alleviate that problem.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 26 Aug 2021 22:31:45 +0300
> Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> 
> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
> > Many
> > don't use mail at all for development, and all they're used to is the
> > GitLab/Hub way of doing it.
> 
> Email is used by virtually everyone (for example, to receive 
> notifications about others' actions or messages), what's "unusual" for 
> many is sending patches over email. Or inlining them in comments/messages.

No, Lars is right: I've heard quite a lot of people saying that they
feel uneasy to write email messages.

> > So it's easier for them -- it feels safe and familiar for them to do
> > development by clicking around in a web browser.
> 
> We also have a bunch of formal rules for submissions which tend to seem 
> intimidating. A CI with an automated checker running against all PRs can 
> alleviate that problem.

Automation can alleviate only some of the violations, a minority IME.
For example, there's no automation known to me that can fix the commit
log entry format.

But anyway, what prevents us from having those same checkers running
on our machines as part of "git am"?

Re: Gitlab Migration

[Dmitry Gutov]

On 26.08.2021 22:41, Eli Zaretskii wrote:
>> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
>>> Many
>>> don't use mail at all for development, and all they're used to is the
>>> GitLab/Hub way of doing it.
>>
>> Email is used by virtually everyone (for example, to receive
>> notifications about others' actions or messages), what's "unusual" for
>> many is sending patches over email. Or inlining them in comments/messages.
> 
> No, Lars is right: I've heard quite a lot of people saying that they
> feel uneasy to write email messages.

While there are as many habits as there are people, perhaps we should 
interpret it more like "write a first email message", to a particular 
mailing list.

There is a whole list of worries a polite and careful person can 
associate with that.

>>> So it's easier for them -- it feels safe and familiar for them to do
>>> development by clicking around in a web browser.
>>
>> We also have a bunch of formal rules for submissions which tend to seem
>> intimidating. A CI with an automated checker running against all PRs can
>> alleviate that problem.
> 
> Automation can alleviate only some of the violations, a minority IME.
> For example, there's no automation known to me that can fix the commit
> log entry format.
> 
> But anyway, what prevents us from having those same checkers running
> on our machines as part of "git am"?

The point is, someone who has never contributed before can more easily 
see all bugs/PRs/discussions from the outside, and when they file a PR, 
see the checks succeed or fail (with specific complaints and 
recommendations) without having to involve a live person.

The ability to avoid bothering anyone directly (and risk a negative 
reception) can help avoid some of the worries.

Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 22:41, Eli Zaretskii wrote:
>>> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
>>>> Many
>>>> don't use mail at all for development, and all they're used to is the
>>>> GitLab/Hub way of doing it.
>>>
>>> Email is used by virtually everyone (for example, to receive
>>> notifications about others' actions or messages), what's "unusual" for
>>> many is sending patches over email. Or inlining them in comments/messages.
>> No, Lars is right: I've heard quite a lot of people saying that they
>> feel uneasy to write email messages.
>
> While there are as many habits as there are people, perhaps we should interpret
> it more like "write a first email message", to a particular mailing list.
>
> There is a whole list of worries a polite and careful person can associate with
> that.
>
>>>> So it's easier for them -- it feels safe and familiar for them to do
>>>> development by clicking around in a web browser.
>>>
>>> We also have a bunch of formal rules for submissions which tend to seem
>>> intimidating. A CI with an automated checker running against all PRs can
>>> alleviate that problem.
>> Automation can alleviate only some of the violations, a minority IME.
>> For example, there's no automation known to me that can fix the commit
>> log entry format.
>> But anyway, what prevents us from having those same checkers running
>> on our machines as part of "git am"?
>
> The point is, someone who has never contributed before can more easily see all
> bugs/PRs/discussions from the outside, and when they file a PR, see the checks
> succeed or fail (with specific complaints and recommendations) without having to
> involve a live person.
Hmm, some projects have thousands of issues, some remove solved issues. I am not
sure it is so easily discoverable. Also I see a lot of comments on gh advising
users to first search for the issue before posting, which makes me thing that
people are not so good to "look first" if issue is already solved.

> The ability to avoid bothering anyone directly (and risk a negative reception)
> can help avoid some of the worries.

Maybe Emacs project should be better at informing users about Emacs bug tracker:

https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs

and this one:

https://debbugs.gnu.org/

and debbugs package for browsing bugs directly from Emacs?

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

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

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

[Tim Cross]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
>> Many
>> don't use mail at all for development, and all they're used to is the
>> GitLab/Hub way of doing it.
>
> Email is used by virtually everyone (for example, to receive notifications about
> others' actions or messages), what's "unusual" for many is sending patches over
> email. Or inlining them in comments/messages.
>

I'm not sure this is true. I think virtually all developers are forced
to suffer email, but a gorwing number don't use it. Often, all the
discussions, notifications, comments etc are actually consumed via a
mobile 'app'. For these users, logging into their inbox is frustrating
and inconvenient because their inbox is full of pointless and old
messages/notifications/alerts they have already seen/received via other
channels. For these users, the primary reason they have an email address
is to have something to put into the 'login' box for web services they
use. Telling these users to use email to submit a patch is very similar
to me being told when I started using email that I had to send in a hard
copy via snail mail.

I love an email interface. Then again, I still miss newsgroups. I hate
web based 'groups' and avoid slack/discord whenever possible. However,
I'm an old white guy in his 60s and not representative of Emacs' future
even though I hope I still have some positive contributions to make.

We do need to look at how to support more modern/current engagement
models, but perhaps not at the expense of old proven ones. We need a
more flexible engagement model rather than replacement of the existing
one. 

Re: Gitlab Migration

[Daniel Fleischer]

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

Tim Cross [2021-08-27 Fri 11:01]  *wrote*:

> I'm not sure this is true. I think virtually all developers are forced
> to suffer email, but a gorwing number don't use it. Often, all the
> discussions, notifications, comments etc are actually consumed via a
> mobile 'app'. For these users, logging into their inbox is frustrating
> and inconvenient because their inbox is full of pointless and old
> messages/notifications/alerts they have already seen/received via other
> channels. For these users, the primary reason they have an email address
> is to have something to put into the 'login' box for web services they
> use. Telling these users to use email to submit a patch is very similar
> to me being told when I started using email that I had to send in a hard
> copy via snail mail.

It's a very intersting point about what email represent to different
people that arising from this discussion. I'm half your age and use
email for 2 reasons:

1. It's an identify for today's web. As such, it's becoming the main
   tool for tracking (especially as cookies phase out), so I use
   multiple boxes and regard them is disposable and spam-infected.

2. Receiving official documents from institutions.

I don't talk to family, friends or coworkers via mail. Personally, I
think it's old, not secure or private by default, very inconsistent
(HTML rendering is arbitrary vs. text, multiple MUA) and just can't
imagine using it as a software engineering tool.

*Daniel Fleischer*

Re: Gitlab Migration

[Tim Cross]

Daniel Fleischer <danflscr@gmail.com> writes:

> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>
>> I'm not sure this is true. I think virtually all developers are forced
>> to suffer email, but a gorwing number don't use it. Often, all the
>> discussions, notifications, comments etc are actually consumed via a
>> mobile 'app'. For these users, logging into their inbox is frustrating
>> and inconvenient because their inbox is full of pointless and old
>> messages/notifications/alerts they have already seen/received via other
>> channels. For these users, the primary reason they have an email address
>> is to have something to put into the 'login' box for web services they
>> use. Telling these users to use email to submit a patch is very similar
>> to me being told when I started using email that I had to send in a hard
>> copy via snail mail.
>
> It's a very intersting point about what email represent to different
> people that arising from this discussion. I'm half your age and use
> email for 2 reasons:
>
> 1. It's an identify for today's web. As such, it's becoming the main
>    tool for tracking (especially as cookies phase out), so I use
>    multiple boxes and regard them is disposable and spam-infected.
>
> 2. Receiving official documents from institutions.
>
> I don't talk to family, friends or coworkers via mail. Personally, I
> think it's old, not secure or private by default, very inconsistent
> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
> imagine using it as a software engineering tool.
>

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.

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.

From the Emacs project perspective, providing alternative web based
workflows similar to what github/gitlab/sourceHut provide would be
beneficial. The challenge seems to be in finding software which meets
FSF requirements. In particular, a solution which is mature enough and
is not based on non-free Javascript libraries. 

Re: Gitlab Migration

[tomas]

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

On Fri, Aug 27, 2021 at 05:34:26PM +1000, Tim Cross 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 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.

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.

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

Cheers

[1] https://en.wikipedia.org/wiki/Gr%C3%ADma

 - t

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

Re: Gitlab Migration

[Tim Cross]

<tomas@tuxteam.de> writes:

> [[PGP Signed Part:Undecided]]
> On Fri, Aug 27, 2021 at 05:34:26PM +1000, Tim Cross 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 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.
>
> 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.
>
>

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. 

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

The move to use o365 or google mail was about moving away from
maintenance of infrastructure in favour of using 'commodity' services.
It is about streamlining management, reducing dependency on in-house
technical skills and more predictable and easy to manage budgets. This
was particularly true for companies who already used exchange and were
paying dearly for the cost (both technical and hardware) to maintain
the platform. It was also about the dream of unified communications with
Calendaring, VoIP, Video Conferencing, etc. Few companies just ran a
simple Postfix or similar mail server - they had calendaring systems,
video conferencing/meeting systems, VoIP systems etc., all of which
could be replaced by services from MS or Google and they could get rid
of those expensive and difficult to recruit skilled technical staff who
kept it all running. It was about easier management and predictable
budgets (even when it was more expensive).

However, 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. 

>
> 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.
>
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.
Personally, it remains my preferred communication medium, except when I
need to communicate with my kids or any of their friends!  

> To put it in other words: I won't pay a wholesale-ish "mail is
> old" argument. I want to have more solid stuff.
>

Time will tell. I certainly wouldn't be investing in any company that
was only an email provider. However, we are getting off topic. I think
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 which is similar to what
is offered by Github/Gitlab/sourceHut in addition, not instead of.
Arguments about one being better than the other are pointless as we all
have our own preferences. What people are asking for is support for a
broader set of preferences. 

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

[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

[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

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

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> Daniel Fleischer <danflscr@gmail.com> writes:
>
>> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>>
>>> I'm not sure this is true. I think virtually all developers are forced
>>> to suffer email, but a gorwing number don't use it. Often, all the
>>> discussions, notifications, comments etc are actually consumed via a
>>> mobile 'app'. For these users, logging into their inbox is frustrating
>>> and inconvenient because their inbox is full of pointless and old
>>> messages/notifications/alerts they have already seen/received via other
>>> channels. For these users, the primary reason they have an email address
>>> is to have something to put into the 'login' box for web services they
>>> use. Telling these users to use email to submit a patch is very similar
>>> to me being told when I started using email that I had to send in a hard
>>> copy via snail mail.
>>
>> It's a very intersting point about what email represent to different
>> people that arising from this discussion. I'm half your age and use
>> email for 2 reasons:
>>
>> 1. It's an identify for today's web. As such, it's becoming the main
>>    tool for tracking (especially as cookies phase out), so I use
>>    multiple boxes and regard them is disposable and spam-infected.
>>
>> 2. Receiving official documents from institutions.
>>
>> I don't talk to family, friends or coworkers via mail. Personally, I
>> think it's old, not secure or private by default, very inconsistent
>> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
>> imagine using it as a software engineering tool.
>>
>
> 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.
>
> 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.
>
> From the Emacs project perspective, providing alternative web based
> workflows similar to what github/gitlab/sourceHut provide would be
> beneficial. The challenge seems to be in finding software which meets
> FSF requirements. In particular, a solution which is mature enough and
> is not based on non-free Javascript libraries. 

I wouldn't agree with you that young people don't know how to use email. That is
something you are deriving yourself. Sure Instagram, Facebook, Dicord, Twitter,
Slack etc might be very popular as a mean of communication, but saying that
young people don't know how to use email is stretching it too far.

Re: Gitlab Migration

[Tim Cross]

Arthur Miller <arthur.miller@live.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Daniel Fleischer <danflscr@gmail.com> writes:
>>
>>> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>>>
>>>> I'm not sure this is true. I think virtually all developers are forced
>>>> to suffer email, but a gorwing number don't use it. Often, all the
>>>> discussions, notifications, comments etc are actually consumed via a
>>>> mobile 'app'. For these users, logging into their inbox is frustrating
>>>> and inconvenient because their inbox is full of pointless and old
>>>> messages/notifications/alerts they have already seen/received via other
>>>> channels. For these users, the primary reason they have an email address
>>>> is to have something to put into the 'login' box for web services they
>>>> use. Telling these users to use email to submit a patch is very similar
>>>> to me being told when I started using email that I had to send in a hard
>>>> copy via snail mail.
>>>
>>> It's a very intersting point about what email represent to different
>>> people that arising from this discussion. I'm half your age and use
>>> email for 2 reasons:
>>>
>>> 1. It's an identify for today's web. As such, it's becoming the main
>>>    tool for tracking (especially as cookies phase out), so I use
>>>    multiple boxes and regard them is disposable and spam-infected.
>>>
>>> 2. Receiving official documents from institutions.
>>>
>>> I don't talk to family, friends or coworkers via mail. Personally, I
>>> think it's old, not secure or private by default, very inconsistent
>>> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
>>> imagine using it as a software engineering tool.
>>>
>>
>> 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.
>>
>> 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.
>>
>> From the Emacs project perspective, providing alternative web based
>> workflows similar to what github/gitlab/sourceHut provide would be
>> beneficial. The challenge seems to be in finding software which meets
>> FSF requirements. In particular, a solution which is mature enough and
>> is not based on non-free Javascript libraries. 
>
> I wouldn't agree with you that young people don't know how to use email. That is
> something you are deriving yourself. Sure Instagram, Facebook, Dicord, Twitter,
> Slack etc might be very popular as a mean of communication, but saying that
> young people don't know how to use email is stretching it too far.

I never said they don't know how to use email - I said they were not
interested in using email. They use it when they are forced to, but it
is not their preferred choice. We even asked students what they wanted
and when you broke that information down by age, nearly 80% of under 25s
indicated they would prefer non-email based communications. This is only
one data point from one institution and only for one year, so there
could be sampling error, cultural variation and possibly question bias
based on wording etc. However, the results were in line with other
feedback and comments. The preference for email also increased with age
- older students showed a higher preference for email, which means the
results could be related to experience and user maturity - we won't know
until more time has passed.

I cannot provide specific details because the information is classified
as sensitive and internal only. It was part of analysis done at a
smaller University (approx 25k students) where the main objective was to
determine if providing students with an email account (actually o365
account), was beneficial or not. The result was that the majority of
students were not interested in the email account (either because they
already had one or because email was not a comms channel they cared
about), but they did want the o365 account because of the access it gave
them to other things, most notably Office suite. 

Re: Gitlab Migration

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> Daniel Fleischer <danflscr@gmail.com> writes:
>>>
>>>> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>>>>
>>>>> I'm not sure this is true. I think virtually all developers are forced
>>>>> to suffer email, but a gorwing number don't use it. Often, all the
>>>>> discussions, notifications, comments etc are actually consumed via a
>>>>> mobile 'app'. For these users, logging into their inbox is frustrating
>>>>> and inconvenient because their inbox is full of pointless and old
>>>>> messages/notifications/alerts they have already seen/received via other
>>>>> channels. For these users, the primary reason they have an email address
>>>>> is to have something to put into the 'login' box for web services they
>>>>> use. Telling these users to use email to submit a patch is very similar
>>>>> to me being told when I started using email that I had to send in a hard
>>>>> copy via snail mail.
>>>>
>>>> It's a very intersting point about what email represent to different
>>>> people that arising from this discussion. I'm half your age and use
>>>> email for 2 reasons:
>>>>
>>>> 1. It's an identify for today's web. As such, it's becoming the main
>>>>    tool for tracking (especially as cookies phase out), so I use
>>>>    multiple boxes and regard them is disposable and spam-infected.
>>>>
>>>> 2. Receiving official documents from institutions.
>>>>
>>>> I don't talk to family, friends or coworkers via mail. Personally, I
>>>> think it's old, not secure or private by default, very inconsistent
>>>> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
>>>> imagine using it as a software engineering tool.
>>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> From the Emacs project perspective, providing alternative web based
>>> workflows similar to what github/gitlab/sourceHut provide would be
>>> beneficial. The challenge seems to be in finding software which meets
>>> FSF requirements. In particular, a solution which is mature enough and
>>> is not based on non-free Javascript libraries. 
>>
>> I wouldn't agree with you that young people don't know how to use email. That is
>> something you are deriving yourself. Sure Instagram, Facebook, Dicord, Twitter,
>> Slack etc might be very popular as a mean of communication, but saying that
>> young people don't know how to use email is stretching it too far.
>
> I never said they don't know how to use email - I said they were not
> interested in using email. They use it when they are forced to, but it
Ok. Fair enough. It was maybe oversimplification there by me.

> is not their preferred choice. We even asked students what they wanted
> and when you broke that information down by age, nearly 80% of under 25s
> indicated they would prefer non-email based communications. This is only
> one data point from one institution and only for one year, so there
> could be sampling error, cultural variation and possibly question bias
> based on wording etc. However, the results were in line with other
> feedback and comments. The preference for email also increased with age
> - older students showed a higher preference for email, which means the
> results could be related to experience and user maturity - we won't know
> until more time has passed.
>
> I cannot provide specific details because the information is classified
> as sensitive and internal only. It was part of analysis done at a
> smaller University (approx 25k students) where the main objective was to
> determine if providing students with an email account (actually o365
> account), was beneficial or not. The result was that the majority of
> students were not interested in the email account (either because they
> already had one or because email was not a comms channel they cared
> about), but they did want the o365 account because of the access it gave
> them to other things, most notably Office suite.

I understand, but that can also be interpretted as if they prefer mail as
they getting more experienced. I also don't really understand what is problem
with emails. Smartphones have almost removed distinction between a so called an
instant message and and email. Email has become just yet another messaging
media.

What I have suggested in several comments by now, is that it is maybe possible
to tuck git workflow on existing mail workflow. Maybe some tasks could be
automated I don't know.

So will your university listen to the students and open a discord channel or
was it snappchat they prefer? Sorry, hope you don't mind a joke.

Re: Gitlab Migration

[Tim Cross]

Arthur Miller <arthur.miller@live.com> writes:

>
> I understand, but that can also be interpretted as if they prefer mail as
> they getting more experienced.

Yes, I already pointed that out and said we won't know until more time
has passed. 

> I also don't really understand what is problem
> with emails. Smartphones have almost removed distinction between a so called an
> instant message and and email. Email has become just yet another messaging
> media.
>

Some of it is about ensuring all necessary information is included. In
many 'business' processes, email is a problem because people neglect to
include crucial information in the message. If on the other hand, they
are required to fill in a form, then mandatory or important information
can be gathered and the content will be in a set format, enabling easier
automation of processing.

Despite what others have claimed, the security problems with email have
NOT been addressed. It is still one of the major vectors for
compromising access via social engineering, major vector for infection
from ransomeware, frequent source of privacy breeches and a common means
used to get sensitive data out of an organisation. Even having encrypted
messages is overly complex for most users and a nightmare to administer
for large organisations. Some of these issues can be partially mitigated
through training/education and various technologies, but these tend to
significantly increase the cost and administration overheads and often
make the service less convenient for users. There is also an element of
it all being 'too hard' (from an administration perspective). 

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

> What I have suggested in several comments by now, is that it is maybe possible
> to tuck git workflow on existing mail workflow. Maybe some tasks could be
> automated I don't know.
>

I'm sure we could use git facilities to enhance the existing workflows,
but that isn't what people are asking for. Those using the existing
email based workflows are not the ones suggesting adoption of more
github/gitlab type functionality. I get the impression that those who
use the existing workflows are quite happy with the current situation.
this is what makes the suggestion of sourceHut as a solution uncertain
as it isn't clear it would provide the web UI facilities being asked for
and may only add a little sugar to the existing workflows, which may
make the effort and change management overhead of adoption harder to
justify. 

> So will your university listen to the students and open a discord channel or
> was it snappchat they prefer? Sorry, hope you don't mind a joke.

Don't know, I retired and no longer work there. They did introduce
'Facebook for Business' for staff and certainly were looking at how to
incorporate various social media platforms. However, social media makes
them (administration) nervous because they cannot control it (which in
itself shows a flaw or outdated thinking within administration's
attitude).

I think some of Eli's comments are quite relevant to this discussion.
There probably needs to be more clarity about exactly what the
requirements or final goal is here. There are lots of opinions about
what would be a good solution, but less clarity regarding what precisely
those requirements are. 

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

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

[Daniel Fleischer]

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

Philip Kaludercic [2021-08-26 Thu 17:24]  *wrote*:

> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form? The same goes for
> patches. Git{Lab,Hub} usually requires leaving the development context,
> to prepare a patch online, that requires "forking", more navigation and
> more fora. Just today I tried preparing a "pull request" on GitLab and
> didn't manage to do so, because it insisted on merging the commit into
> my own repository, no matter what I did. Just attaching a git patch
> seems much easier.

I explicitly don't want to get into questions of what is easier because
we can't answer these objectively. Each person is used to something else
which they consider easier, where the getting used to is a long
mental process depending on personal preference and outside influence.

I can say objectively that one form of workflow is more popular than
another so people would be more familiar with it.

*Daniel Fleischer*

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Fri, 27 Aug 2021 10:00:10 +0300
> Cc: emacs-devel@gnu.org
> 
> Philip Kaludercic [2021-08-26 Thu 17:24]  *wrote*:
> 
> > Shouldn't it be easier to send an email than create an account, navigate
> > some web UI and fill in some form? The same goes for
> > patches. Git{Lab,Hub} usually requires leaving the development context,
> > to prepare a patch online, that requires "forking", more navigation and
> > more fora. Just today I tried preparing a "pull request" on GitLab and
> > didn't manage to do so, because it insisted on merging the commit into
> > my own repository, no matter what I did. Just attaching a git patch
> > seems much easier.
> 
> I explicitly don't want to get into questions of what is easier because
> we can't answer these objectively. Each person is used to something else
> which they consider easier, where the getting used to is a long
> mental process depending on personal preference and outside influence.

Agreed.  We don't need to force everyone to use a single workflow.  We
should have a platform that supports reasonably well the different
popular workflows.

Re: Gitlab Migration

[Stefan Monnier]

> Agreed.  We don't need to force everyone to use a single workflow.
> We should have a platform that supports reasonably well the different
> popular workflows.

AFAIK SourceHut is the only project which explicitly aims to provide
full and convenient support for both web and email control, which makes
it the obvious&natural choice for Emacs, IMO.


        Stefan

Re: Gitlab Migration

[Dmitry Gutov]

On 27.08.2021 17:33, Stefan Monnier wrote:
>> Agreed.  We don't need to force everyone to use a single workflow.
>> We should have a platform that supports reasonably well the different
>> popular workflows.
> 
> AFAIK SourceHut is the only project which explicitly aims to provide
> full and convenient support for both web and email control, which makes
> it the obvious&natural choice for Emacs, IMO.

 From what I have seen of it, it's email-first, and far from "full and 
convenient support for ... web".

For example, those quality-of-life features that Gitlab has in the 
browser which I previously figured would be difficult to translate  to 
email (the code review workflow, with inline comments and updates from 
the branch; automatically updated CI indicators and links to builds; 
editing of messages) are predictably absent.

Of course, it should still be a significant step forward compared to the 
current situation.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: Daniel Fleischer <danflscr@gmail.com>, philipk@posteo.net,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 28 Aug 2021 00:09:41 +0300
> 
>  From what I have seen of it, it's email-first, and far from "full and 
> convenient support for ... web".
> 
> For example, those quality-of-life features that Gitlab has in the 
> browser which I previously figured would be difficult to translate  to 
> email (the code review workflow, with inline comments and updates from 
> the branch; automatically updated CI indicators and links to builds; 
> editing of messages) are predictably absent.

That sounds worrisome.

Can you tell how did you see what SourceHut offers in this department,
so others (myself included) could have a look?  I cannot find any
documentation of the features.

> Of course, it should still be a significant step forward compared to the 
> current situation.

Can you elaborate why you think so, given the lack of the above
features?

Re: Gitlab Migration

[Dmitry Gutov]

On 28.08.2021 09:00, Eli Zaretskii wrote:
>> Cc: Daniel Fleischer <danflscr@gmail.com>, philipk@posteo.net,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 28 Aug 2021 00:09:41 +0300
>>
>>   From what I have seen of it, it's email-first, and far from "full and
>> convenient support for ... web".
>>
>> For example, those quality-of-life features that Gitlab has in the
>> browser which I previously figured would be difficult to translate  to
>> email (the code review workflow, with inline comments and updates from
>> the branch; automatically updated CI indicators and links to builds;
>> editing of messages) are predictably absent.
> 
> That sounds worrisome.
> 
> Can you tell how did you see what SourceHut offers in this department,
> so others (myself included) could have a look?  I cannot find any
> documentation of the features.

I used my web browser, mostly following the links others submitted in 
this discussion (and then followed some links from there), also did some 
educated guessing (and turned out to be wrong on the subject of CI 
indicators and links to builds).

The video Drew posted yesterday (see the response to it I sent just now) 
has also been illuminating.

I haven't looked too deeply or tried to work with it personally, so my 
impressions are of course superficial and biased. Perhaps somebody wants 
to create a test project on sr.ht and invite a bunch of us to 
collaborate? Or set up a private installation like emba.gnu.org, with 
the same end goal.

>> Of course, it should still be a significant step forward compared to the
>> current situation.
> 
> Can you elaborate why you think so, given the lack of the above
> features?

It seems to provide a nicer/better bug tracker and mailing list archive 
viewers than the ones we already have. With unified views, better 
searching, tagging and perhaps even an ability to write messages from 
the browser (which is certain to appeal to some newcomers). Maybe also 
features like subscribe/unsubscribe to a discussion, though that looks 
less certain.

We have generally routed around those problems (by doing extra manual 
work, usually; or asking others to do it), but that haven't made them go 
away. E.g. recall at the beginning of this thread you suggested the 
author would do a search for the previous thread on the subject and then 
find the gitlab issue there. I'm guessing it was, at least in part, due 
to the search on lists.gnu.org being not that great.

Of course, whether this promise will hold up (with good performance and 
few bugs) remain to be seen, but Drew has a good track record.

Overall, if we finally accept that neither UI familiarity (for new 
users) nor workflow familiarity (for new contributors) are a priority 
for the Emacs project, this might a reasonable option to migrate to. I 
just wonder whether we'd have to do another migration in 5-10 years, 
with the natural change in Emacs contributor base.

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

  >  perhaps even an ability to write messages from 
  > the browser (which is certain to appeal to some newcomers).

It is fine to offer this feature, provided the message turns into
email so that we can receive it in our inboxes.  Is that the case?

  > Overall, if we finally accept that neither UI familiarity (for new 
  > users) nor workflow familiarity (for new contributors) are a priority 
  > for the Emacs project, this might a reasonable option to migrate to.

They count for something, but less than many other countervaling values.
This is meaningful at the "all else being equal" level.

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

[Dmitry Gutov]

On 30.08.2021 05:58, 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. ]]]
> 
>    >  perhaps even an ability to write messages from
>    > the browser (which is certain to appeal to some newcomers).
> 
> It is fine to offer this feature, provided the message turns into
> email so that we can receive it in our inboxes.  Is that the case?

That's the idea.

>    > Overall, if we finally accept that neither UI familiarity (for new
>    > users) nor workflow familiarity (for new contributors) are a priority
>    > for the Emacs project, this might a reasonable option to migrate to.
> 
> They count for something, but less than many other countervaling values.
> This is meaningful at the "all else being equal" level.

Yes, as is now apparent from multiple arguments around the subject, 
appealing to newcomers (and/or trying to adopt contemporary usability 
practices) is of much lesser priority than, say, making sure that each 
key binding that has been with us for a number of years, is left 
unchanged for ever. We hate to risk inconveniencing existing users.

Re: Gitlab Migration

[Daniel Fleischer]

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

Dmitry Gutov [2021-08-30 Mon 15:20]  wrote:

> Yes, as is now apparent from multiple arguments around the subject, appealing to newcomers (and/or trying to adopt
> contemporary usability practices) is of much lesser priority than, say, making sure that each key binding that has been
> with us for a number of years, is left unchanged for ever. We hate to risk inconveniencing existing users.

Key bindings are important!


*Daniel Fleischer*

Re: Gitlab Migration

[Dmitry Gutov]

On 30.08.2021 15:48, Daniel Fleischer wrote:
> Dmitry Gutov [2021-08-30 Mon 15:20]  wrote:
> 
>> Yes, as is now apparent from multiple arguments around the subject, appealing to newcomers (and/or trying to adopt
>> contemporary usability practices) is of much lesser priority than, say, making sure that each key binding that has been
>> with us for a number of years, is left unchanged for ever. We hate to risk inconveniencing existing users.
> Key bindings are important!

The question is, important for what.

And whether existing muscle memory can be sacrificed for better 
usability. And/or for reduced suffering in newcomers.

Re: Gitlab Migration

[Elias Mårtenson]

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

Den mån 30 aug. 2021 20:57Dmitry Gutov <dgutov@yandex.ru> skrev:

>
> And whether existing muscle memory can be sacrificed for better
> usability. And/or for reduced suffering in newcomers.
>

If whatever is popular equals better, then Emacs would have been rewritten
in Java already, no wait, Ruby, no actually Python, sorry I meant
Javascript.

A lot of things are familiar to a lot of people, but familiarity is
orthogonal to quality.

>

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

Re: Gitlab Migration

[Ihor Radchenko]

Elias Mårtenson <lokedhs@gmail.com> writes:

> If whatever is popular equals better, then Emacs would have been rewritten
> in Java already, no wait, Ruby, no actually Python, sorry I meant
> Javascript.

> A lot of things are familiar to a lot of people, but familiarity is
> orthogonal to quality.

Reducto ad absurdum? Of course, rewriting Emacs using different language
is not a good idea if the justification is merely the language
popularity. However, much smaller changes can be reverted if they do not
prove themselves useful.

Can Emacs have "experimental" and "stable" dev branches with the former
being more open to "popular" changes? Then, people who wish a more
"popular" approach can use the experimental branch without disturbing
more conservative users. If features in experimental branch prove their
usefulness and quality, they can be moved to the stable branch.

Best,
Ihor

Re: Gitlab Migration

[Philip Kaludercic]

Ihor Radchenko <yantar92@gmail.com> writes:

> Can Emacs have "experimental" and "stable" dev branches with the former
> being more open to "popular" changes? Then, people who wish a more
> "popular" approach can use the experimental branch without disturbing
> more conservative users. If features in experimental branch prove their
> usefulness and quality, they can be moved to the stable branch.

In some sense this exists with prepared configurations (or
"distributions" as some call them). The changes they can make are not
exactly the same as a "experimental" branch could, but they can do a lot
of superficial and organisational changes.

The issue there is that prepared configurations bundle a lot of options
together, so it is harder to evaluate what is popular and what the
maintainers of these projects prefer.

An idea I was playing around with for a while was to build a website to
generate Emacs configurations. You'd select what you like to use, what
you don't want, etc. and it would let you download an init.el
file. Optionally, the user could select to have their preferences
anonymously logged, for statistical purposes (comparable to Debian's
popcon). Of course the data could be manipulated easily, so it is
debatable how reliable it would be.

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 10:26, Philip Kaludercic wrote:
> Ihor Radchenko<yantar92@gmail.com>  writes:
> 
>> Can Emacs have "experimental" and "stable" dev branches with the former
>> being more open to "popular" changes? Then, people who wish a more
>> "popular" approach can use the experimental branch without disturbing
>> more conservative users. If features in experimental branch prove their
>> usefulness and quality, they can be moved to the stable branch.
> In some sense this exists with prepared configurations (or
> "distributions" as some call them). The changes they can make are not
> exactly the same as a "experimental" branch could, but they can do a lot
> of superficial and organisational changes.

And as those distributions have been around for some time, we could look 
at the changes in options they made and strongly consider making the 
changes in defaults where those distributions agree, or largely agree.

Those kind of arguments, however, aren't generally accepted around here 
either.

Re: Gitlab Migration

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 03.09.2021 10:26, Philip Kaludercic wrote:
>> Ihor Radchenko<yantar92@gmail.com>  writes:
>> 
>>> Can Emacs have "experimental" and "stable" dev branches with the former
>>> being more open to "popular" changes? Then, people who wish a more
>>> "popular" approach can use the experimental branch without disturbing
>>> more conservative users. If features in experimental branch prove their
>>> usefulness and quality, they can be moved to the stable branch.
>> In some sense this exists with prepared configurations (or
>> "distributions" as some call them). The changes they can make are not
>> exactly the same as a "experimental" branch could, but they can do a lot
>> of superficial and organisational changes.
>
> And as those distributions have been around for some time, we could
> look at the changes in options they made and strongly consider making
> the changes in defaults where those distributions agree, or largely
> agree.
>
> Those kind of arguments, however, aren't generally accepted around
> here either.

I guess because it is easy to conflate the changes they make. These
distributions and prepared configurations don't have to care about
backwards compatibility, to they are a lot more flexible to change
whatever they want. But there are different things:

* Rebinding existing commands to ...
  - different functionalities (C-x to kill)
  - stronger equivalents (M-/ to hippie-expand)
  - slightly different but more intuitive commands (M-z to zap-up-to-char)
* Binding commands to new keys (C-x p for project.el)
* Providing more or different packages by-default (various major modes
  not available in ELPA, use-package, ...)
* Enabling options by default ...
  - that might have been considered to intensive in the past
    (show-paren-mode, decreasing lazy-highlight-initial-delay, ...)
  - that change the default behaviour by trying to be intuitive (electric
    modes)
* Changing the default UI to ...
  - match modern design trends (adding blank space, adding those
    little triangles to the mode line, ...)
  - improve readability (changing the default theme, using more
    variable-width faces in the UI)

And I am sure there are more, but the point is that there are different
discussions and motivations behind these changes. Emacs is currently in
the weird position where it is already different but doesn't want to
confuse new users even more by disabling some commands by default
(upcase-region, narrow-to-region) or offer more power by default
(searching using regular expressions by default).

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 14:11, Philip Kaludercic wrote:
> * Enabling options by default ...
>    - that might have been considered to intensive in the past
>      (show-paren-mode, decreasing lazy-highlight-initial-delay, ...)
>    - that change the default behaviour by trying to be intuitive (electric
>      modes)

One change I previously suggested is the value of 
uniquify-buffer-name-style to 'forward, which most distributions out 
there use.

It's a small difference, but again -- no go.

Another similar changes:

require-final-newline -> t

indent-tabs-mode -> nil (of course)

show-paren-mode seems universally acclaimed as well (though prelude and 
doom-emacs use smartparens for a similar effect), so why not enable it too.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: Ihor Radchenko <yantar92@gmail.com>, Elias Mårtenson
>  <lokedhs@gmail.com>, Daniel Fleischer <danflscr@gmail.com>,
>  Richard Stallman <rms@gnu.org>, emacs-devel <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 14:31:47 +0300
> 
> One change I previously suggested is the value of 
> uniquify-buffer-name-style to 'forward, which most distributions out 
> there use.
> 
> It's a small difference, but again -- no go.
> 
> Another similar changes:
> 
> require-final-newline -> t
> 
> indent-tabs-mode -> nil (of course)
> 
> show-paren-mode seems universally acclaimed as well (though prelude and 
> doom-emacs use smartparens for a similar effect), so why not enable it too.

There, you have already a list of options to include in a suitably
named "profile".  Why not add that to Emacs right now?

Re: Gitlab Migration

[Daniel Fleischer]

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

Starting simple, with the following four areas:

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

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

;; Session
(desktop-save-mode)

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


Some questions:

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

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?


--
Daniel Fleischer

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

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

  > Yes, as is now apparent from multiple arguments around the subject, 
  > appealing to newcomers (and/or trying to adopt contemporary usability 
  > practices) is of much lesser priority than, say, making sure that each 
  > key binding that has been with us for a number of years, is left 
  > unchanged for ever. We hate to risk inconveniencing existing users.

Please don't bring sarcasm into our discussions.  It tends to make the
discussion more acrimonious and make agreement more difficult.
Any point can be made without sarcasm, and it's likely to arouse
less resistance that way.

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

[Dmitry Gutov]

On 31.08.2021 06:09, Richard Stallman wrote:
>    > Yes, as is now apparent from multiple arguments around the subject,
>    > appealing to newcomers (and/or trying to adopt contemporary usability
>    > practices) is of much lesser priority than, say, making sure that each
>    > key binding that has been with us for a number of years, is left
>    > unchanged for ever. We hate to risk inconveniencing existing users.
> 
> Please don't bring sarcasm into our discussions.  It tends to make the
> discussion more acrimonious and make agreement more difficult.
> Any point can be made without sarcasm, and it's likely to arouse
> less resistance that way.

I wasn't really that sarcastic. The above is literally my observations 
on our decision-making in the area.

Re: Gitlab Migration

[João Távora]

On Tue, Aug 31, 2021 at 12:50 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 31.08.2021 06:09, Richard Stallman wrote:
> >    > Yes, as is now apparent from multiple arguments around the subject,
> >    > appealing to newcomers (and/or trying to adopt contemporary usability
> >    > practices) is of much lesser priority than, say, making sure that each
> >    > key binding that has been with us for a number of years, is left
> >    > unchanged for ever. We hate to risk inconveniencing existing users.
> >
> > Please don't bring sarcasm into our discussions.  It tends to make the
> > discussion more acrimonious and make agreement more difficult.
> > Any point can be made without sarcasm, and it's likely to arouse
> > less resistance that way.
>
> I wasn't really that sarcastic. The above is literally my observations
> on our decision-making in the area.

I want to offer a small amount of anecdotal evidence in favor of the
recent push to Sourcehut and against the GitLab/GitHub alternatives
that are presumably favoured by you (Dmitry) and some others.  In recent
$DAYJOBs I worked with these two GL/GH platforms fully, using them
liberally and without restrictions. In these recent experiences the undeniable
contemporarity and newcomer friendliness of these platforms does NOT
seem to translate into quality of code, quality of discussion or any
kind of benefic developer agility in any way.  Again, just anecdotal
evidence which you may take for what it's worth, but in fact I believe
that the "slow", unfamiliar, peculiar, old-school whatever-you-want-to-call-them
methods used in Emacs development may in fact be "aces up our
sleeve", not just a means to appease those that have been using them
for a number of years.

João

Re: Gitlab Migration

[André A. Gomes]

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

> [...] but in fact I believe that the "slow", unfamiliar, peculiar,
> old-school whatever-you-want-to-call-them methods used in Emacs
> development may in fact be "aces up our sleeve", not just a means to
> appease those that have been using them for a number of years.

I couldn't agree more.  There are historical (and technical) reasons for
the Emacs development being the way it is.  From my point of view, the
point of view of an enthusiast and absolute beginner, I've matured
respect and appreciation for the modus operandi of this community.  I
acknowledge that "easy" options are often illusions.

I don't think Emacs cultivates "elitism".  But it does require
proficiency, which is only sensible.  If getting more people on board
entails lowering the bar, then Emacs would be subscribing to "worse is
better".  Emacs doesn't stand for that, and it's not on a race.


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

Re: Gitlab Migration

[Yuchen Pei]

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


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

> João Távora <joaotavora@gmail.com> writes:
>
>> [...] but in fact I believe that the "slow", unfamiliar, 
>> peculiar,
>> old-school whatever-you-want-to-call-them methods used in Emacs
>> development may in fact be "aces up our sleeve", not just a 
>> means to
>> appease those that have been using them for a number of years.
>
> I couldn't agree more.  There are historical (and technical) 
> reasons for
> the Emacs development being the way it is.  From my point of 
> view, the
> point of view of an enthusiast and absolute beginner, I've 
> matured
> respect and appreciation for the modus operandi of this 
> community.  I
> acknowledge that "easy" options are often illusions.
>
> I don't think Emacs cultivates "elitism".  But it does require
> proficiency, which is only sensible.  If getting more people on 
> board
> entails lowering the bar, then Emacs would be subscribing to 
> "worse is
> better".  Emacs doesn't stand for that, and it's not on a race.

1+

I also want to add some personal thoughts about "old" vs. "young / 
new" in this respect.

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

-- 
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
           <https://ypei.me/assets/ypei-pubkey.txt>

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

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