Gitlab Migration

Gitlab Migration

[Daniel Fleischer]

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

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Thu, 26 Aug 2021 19:20:36 +0300
> 
> 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.
> 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?

At the time, someone filed an issue with GitLab with a description of
the problems we discovered.  I'm quite sure the issue ID was posted
here.  I suggest to find that issue and read it (unless you already
did), because AFAIR there were several aspects to it, certainly more
than just 2 you mention.

Thanks.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Daniel Fleischer <danflscr@gmail.com> writes:

> One issue which I think is important is the move to a new VC system,
> e.g. Gitlab.

Yeah, that'd be great.  (But it's not really a VC system -- the version
control system will continue to be git.)

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

Yes, I think that's the biggest hurdle -- I think we really need that or
risk losing a number of our current contributors.  Can you interact with
Gitlab via a mail-only system?

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

Re: Gitlab Migration

[Dmitry Gutov]

On 26.08.2021 19:32, Eli Zaretskii wrote:
>> From: Daniel Fleischer<danflscr@gmail.com>
>> Date: Thu, 26 Aug 2021 19:20:36 +0300
>>
>> 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.
>> 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?
> At the time, someone filed an issue with GitLab with a description of
> the problems we discovered.  I'm quite sure the issue ID was posted
> here.  I suggest to find that issue and read it (unless you already
> did), because AFAIR there were several aspects to it, certainly more
> than just 2 you mention.

https://gitlab.com/gitlab-org/gitlab/-/issues/28152

It's pretty daunting, I'd say.

And requires not only work on our side but also a number of improvements 
in Gitlab upstream (there are some linked discussions there on those 
sub-issues, but I'm assuming, best case, they are all currently waiting 
for volunteers).

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 26 Aug 2021 19:40:35 +0300
> 
> > At the time, someone filed an issue with GitLab with a description of
> > the problems we discovered.  I'm quite sure the issue ID was posted
> > here.  I suggest to find that issue and read it (unless you already
> > did), because AFAIR there were several aspects to it, certainly more
> > than just 2 you mention.
> 
> https://gitlab.com/gitlab-org/gitlab/-/issues/28152
> 
> It's pretty daunting, I'd say.
> 
> And requires not only work on our side but also a number of improvements 
> in Gitlab upstream (there are some linked discussions there on those 
> sub-issues, but I'm assuming, best case, they are all currently waiting 
> for volunteers).

We could prioritize the requirements, perhaps, and consider switching
after some critical mass of them is done.

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

[Theodor Thornhill]

On 26 August 2021 19:24:07 CEST, Philip Kaludercic <philipk@posteo.net> wrote:
>
>
>I remember Sourceforge being suggested as an alternative to Gitlab, but
>the software is currently still in a beta stage (AFAIR).
>

Do you mean SourceHut or Sourceforge? SourceHut does have an explicit goal to support mailbased workflow, and supports an interface to it as well. It is pretty neat IMO. 


https://sr.ht/

--
Theodor Thornhill

>>
>

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

[john muhl]

On Thu, 2021-08-26 at 17:24 +0000, Philip Kaludercic wrote:
> 
> I remember Sourceforge being suggested as an alternative to Gitlab,

I think you mean sourcehut <https://sourcehut.org/> (free software)
not sourceforge <https://sourceforge.net/> (saas).

> but the software is currently still in a beta stage (AFAIR).

Pre-beta/alpha stage as of the latest update:
https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3CCDJYU3UHYS0I.3N2HFRMA6AIUB%40taiga%3E

GNU Ethical Repository Criteria related discussion:
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87a79fifzl.fsf%40fsf.org%3E
https://lists.sr.ht/~sircmpwn/sr.ht-
discuss/%3CC03B4X6WE7XN.9NAXAORGDJ0B%40homura%3E

Re: Gitlab Migration

[Philip Kaludercic]

Theodor Thornhill <theo@thornhill.no> writes:

> On 26 August 2021 19:24:07 CEST, Philip Kaludercic <philipk@posteo.net> wrote:
>>
>>
>>I remember Sourceforge being suggested as an alternative to Gitlab, but
>>the software is currently still in a beta stage (AFAIR).
>>
>
> Do you mean SourceHut or Sourceforge? SourceHut does have an explicit goal to support mailbased workflow, and supports an interface to it as well. It is pretty neat IMO. 

Oops, sourcehut of course.

>
> https://sr.ht/
>
> --
> Theodor Thornhill
>
>>>
>>

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Clément Pit-Claudel]

On 8/26/21 1:24 PM, Philip Kaludercic wrote:
> Shouldn't it be easier to send an email than create an account, navigate
> some web UI and fill in some form?

I don't have strong opinions on mailing lists vs other approaches; but: no, not necessarily.

- Unlike email, a webform allows mistakes to be fixed easily (messages can be edited after being posted).  A mailing list does not allow this, so for newcomers the fear of "doing something wrong" is high.  Many projects have an issue reporting template now, and that can be nice.

  (Yes, emacs has M-x report-emacs-bug, but no, I haven't set up my Emacs to send email yet, despite using Emacs for the last ten years).

- Common actions can be mapped to buttons and dropdowns, making them more easily discoverable. I don't interact with debbugs often enough to remember the commands, so I need to look them up every time I want to close a bug, tag an issue, etc.  In practice, I mostly leave these tasks to other volunteers.  With a web UI, I can apply tags from a list of known tags, close issues, mark duplicates, subscribe to an issue, etc. just by clicking my way around.  I can also trivially CC someone in a discussion (this is not easy with debbugs: you need to set up a custom header in your message, and mistakes can't be fixed by editing the original message).  It may be less efficient (although email isn't exactly fast), but it's very discoverable. 

- State tracking can be easier.  The Gitlab UI has, at all times, the latest version of a patchset.  On the emacs mailing list, maintainers regularly request a user to resent the latest version of a patchset, because changes can become hard to follow otherwise.  

- It requires less expertise with git and the patching workflow.  Committing to "one branch per patch" means that contributors don't need to know how to prepare and send or apply patches.  It also means that maintainers (or bots!) can push fixes directly, instead of requesting them.  For example recently I opened a pull request for a Python project I had never contributed to, and an automated system promptly pushed an additional commit to the branch to reformat my code using the project's preferred style.  With Emacs patches we typically ask the author to fix issues that are spotted by hand by a reviewer. 

- Responding to old bugs is easier.  With a mailing list, it's no necessarily clear what the process is.  Should I send a new message to the bug address? Or does it need the right response headers?  In that case should I download the mbox first and import it into my email client?

I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.

Re: Gitlab Migration

[Jim Porter]

On 8/26/2021 10:59 AM, Lars Ingebrigtsen wrote:
> 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.

I'm pretty new contributing to Emacs, and so I can definitely understand 
the feeling of intimidation about using a mailing list-based workflow 
for contributions. However, once I actually tried it, it turned out to 
be very similar as a contributor (I don't know if I'd want to *maintain* 
a project using a mailing list workflow, but that's not my job, so it's 
not a problem for me).

One issue, however, is that the documentation for sending patches[1], 
while very thorough, doesn't make things easy to understand for someone 
familiar with a pull request workflow. While all the advice in the 
documentation is useful, a lot of it is stuff that anyone who's sent a 
PR before (hopefully) already knows, such as, "Don’t mix together 
changes made for different reasons. Send them individually."

After resolving to read the documentation thoroughly, I realized I only 
really needed a few short bits of advice:

1) The bug tracker is at https://debbugs.gnu.org
2) To submit a patch:
    a) Clone the Emacs git repo
    b) Make a branch and add some commits (as usual for the PR workflow)
    c) Run `git format-patch master`
    d) Compose an email to bug-gnu-emacs@ with the files in (c) attached
3) Commit messages have a special format (but you can just imitate what 
you see in prior commits)

Almost everything else is either common advice for contributing to any 
project, or something maintainers can address after a patch is submitted 
(e.g. copyright assignment). While I don't think the existing 
documentation should be removed, having a "quick-start intro" for people 
already familiar with the PR workflow would probably go a long way 
towards making new contributors feel less intimidated.

If the above sounds reasonable, I can work on a patch to the docs once 
my copyright paperwork is updated (or someone else can update them 
instead; I don't have a preference). It might even be helpful to add a 
"Contributing" section to the main Emacs homepage[2] with a short 
version of what's already in the full documentation.

- Jim

[1] 
https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html
[2] https://www.gnu.org/software/emacs/

Re: Gitlab Migration

[Stefan Monnier]

> Possible issue:

You forgot another one: we want the code to be hosted on machines under
the control of the GNU project.  The last I heard from this is that some
software was considered and there was a web page summarizing the status,
but that was maybe 2 years ago and I can't find that page any more now
have I heard anything again.


        Stefan

Re: Gitlab Migration

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 26 Aug 2021 14:36:17 -0400
> 
> - It requires less expertise with git and the patching workflow.  Committing to "one branch per patch" means that contributors don't need to know how to prepare and send or apply patches.  It also means that maintainers (or bots!) can push fixes directly, instead of requesting them.  For example recently I opened a pull request for a Python project I had never contributed to, and an automated system promptly pushed an additional commit to the branch to reformat my code using the project's preferred style.  With Emacs patches we typically ask the author to fix issues that are spotted by hand by a reviewer. 

It's actually the other way around, at least in some cases.  With
patches that are emailed to me, I can fix some simple issues, such as
commit log messages or simple typos, myself, before applying.  With
merging via Web UI, I need to push another commit, which is a waste,
and also breaks what should have been a single commit into several
ones.  So with Web UI, I expect _more_ requests to contributors to get
their act together, where automated fixups are impossible, because
there's little I can do myself.

> - Responding to old bugs is easier.  With a mailing list, it's no necessarily clear what the process is.  Should I send a new message to the bug address? Or does it need the right response headers?  In that case should I download the mbox first and import it into my email client?

I think you see problems where there are none.  If you have an email
message that belongs to a bug, reply to it; otherwise simply write to
the bug address.  admin/notes/bugtracker explains this within its
first dozen of lines.

And it isn't like GitLab and similar platforms don't have similar
issues: e.g., I don't know to this day how to reply to a specific
comment there (as opposed to the last one), nor how to cite portions
of the comment to which I respond.  And that's _after_ I overcome the
shock of not being able to use sophisticated editing commands and
spell-checking.

> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.

I realize that some people who want to contribute don't like emacs or
are intimidated by it.  That's an important reason to provide the UI
to which they are more accustomed.  But let's not exaggerate the
advantages of these platforms for the Emacs developers: though some
advantages exist, they are not that significant, at least IMO, and
there are disadvantages (described in the GitLab issue).

IOW, the most important reason for this move is to be more welcoming
to casual contributors, not to make the job much easier for the
maintainers.

Re: Gitlab Migration

[Greg Farough]

On Thu, Aug 26 2021, john muhl <email@johnmuhl.mx> wrote:

> On Thu, 2021-08-26 at 17:24 +0000, Philip Kaludercic wrote:
>> 
>> I remember Sourceforge being suggested as an alternative to Gitlab,
>
> I think you mean sourcehut <https://sourcehut.org/> (free software)
> not sourceforge <https://sourceforge.net/> (saas).
>
>> but the software is currently still in a beta stage (AFAIR).
>
> Pre-beta/alpha stage as of the latest update:
> https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3CCDJYU3UHYS0I.3N2HFRMA6AIUB%40taiga%3E
>
> GNU Ethical Repository Criteria related discussion:
> https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87a79fifzl.fsf%40fsf.org%3E
> https://lists.sr.ht/~sircmpwn/sr.ht-
> discuss/%3CC03B4X6WE7XN.9NAXAORGDJ0B%40homura%3E

On that note, I should mention that GNU's ethical repo working group
is about to update GitLab's rating to an F[1]. I would not consider it
an acceptable place to host a GNU program.

Once the changes are made to the ethical repo page, Sourcehut will
have a B[2]. Meaning, as per the criteria[3], that it is acceptable to
host a GNU program.

-g

[1]:
https://lists.defectivebydesign.org/archive/html/repo-criteria-discuss/2021-06/msg00035.html
[2]:
https://lists.defectivebydesign.org/archive/html/repo-criteria-discuss/2021-06/msg00036.html
[3]: https://www.gnu.org/software/repo-criteria.html

-- 
"We carry a new world here, in our hearts. That world is growing in
this minute."

Re: Gitlab Migration

[Eli Zaretskii]

> From: Jim Porter <jporterbugs@gmail.com>
> Date: Thu, 26 Aug 2021 11:42:08 -0700
> Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> 
> After resolving to read the documentation thoroughly, I realized I only 
> really needed a few short bits of advice:
> 
> 1) The bug tracker is at https://debbugs.gnu.org
> 2) To submit a patch:
>     a) Clone the Emacs git repo
>     b) Make a branch and add some commits (as usual for the PR workflow)
>     c) Run `git format-patch master`
>     d) Compose an email to bug-gnu-emacs@ with the files in (c) attached
> 3) Commit messages have a special format (but you can just imitate what 
> you see in prior commits)
> 
> Almost everything else is either common advice for contributing to any 
> project, or something maintainers can address after a patch is submitted 
> (e.g. copyright assignment). While I don't think the existing 
> documentation should be removed, having a "quick-start intro" for people 
> already familiar with the PR workflow would probably go a long way 
> towards making new contributors feel less intimidated.
> 
> If the above sounds reasonable, I can work on a patch to the docs once 
> my copyright paperwork is updated (or someone else can update them 
> instead; I don't have a preference). It might even be helpful to add a 
> "Contributing" section to the main Emacs homepage[2] with a short 
> version of what's already in the full documentation.

Feel free to work on this, and let's talk after you actually have a
patch.

However, please note that people vary in their prior background, and
what is clear to someone who has experience with PRs and/or some
knowledge of Git, may be less known to others.  Thus, making this kind
of docs both concise and detailed enough is a problem without trivial
solutions, because that document is written for everyone, not just for
PR veterans.

But don't let me discourage you from trying ;-)

Re: Gitlab Migration

[john muhl]

On Thu, 2021-08-26 at 14:51 -0400, Stefan Monnier wrote:
> 
> The last I heard from this is that some software was considered and
> there was a web page summarizing the status, but that was maybe 2
> years ago and I can't find that page any more

maybe one on these:
https://libreplanet.org/wiki/FSF_2020_forge_evaluation
https://www.gnu.org/software/repo-criteria-evaluation.html

Re: Gitlab Migration

[Stefan Monnier]

> On that note, I should mention that GNU's ethical repo working group
> is about to update GitLab's rating to an F[1]. I would not consider it
> an acceptable place to host a GNU program.

Side note: this working group is focused on evaluating hosting services,
rather than evaluating software to use for such hosting (which you
could use to self-host).  E.g. it evaluates the gitlab.com service
rather than the Gitlab software.

AFAIK the intention for Emacs is to host it on GNU-managed servers, so
it would be self-hosting in this sense and not using any particular
existing service provider.

The two are related but somewhat different.


        Stefan

Re: Gitlab Migration

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It's actually the other way around, at least in some cases.  With
> patches that are emailed to me, I can fix some simple issues, such as
> commit log messages or simple typos, myself, before applying.

Indeed.  But I expect that whatever we end up with, we (that is, the
Emacs maintainers) won't have to click around, and won't have to
actually merge anything directly.  That is, I expect to have a command
in Emacs that says "get that pull request as a patch, apply it, and
don't commit it".  So that we can fix stuff up before committing -- as
before.

(I know, I can hear gasps of outrage from git fundamentalists already.)

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

Re: Gitlab Migration

[Dmitry Gutov]

On 26.08.2021 19:56, Eli Zaretskii wrote:
> We could prioritize the requirements, perhaps, and consider switching
> after some critical mass of them is done.

Sounds good.

The two "external" items (reCAPTCHA and LibreJS) might be hard 
requirements from RMS, though.

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:27:35 +0300
> Cc: danflscr@gmail.com, emacs-devel@gnu.org
> 
> On 26.08.2021 19:56, Eli Zaretskii wrote:
> > We could prioritize the requirements, perhaps, and consider switching
> > after some critical mass of them is done.
> 
> Sounds good.
> 
> The two "external" items (reCAPTCHA and LibreJS) might be hard 
> requirements from RMS, though.

If we host it on Savannah, that will be resolved regardless.

Re: Gitlab Migration

[Dmitry Gutov]

On 26.08.2021 22:04, Eli Zaretskii wrote:
> If you have an email
> message that belongs to a bug, reply to it; otherwise simply write to
> the bug address.

...and cut off all prior participants from the discussions. Except those 
who are subscribed to the mailing list, of course.

Re: Gitlab Migration

[dick]

* Newcomer suggests PR-based workflow citing youth.  Check.

* Veterans chime in, citing the obvious reasons-for and the
political reasons-against.  Check.

* EZ cites his *sui generis* argument that a web-based workflow is actually
*more* work than mailing patches around.  Check.

* Someone announces his intention to begin the necessary work.  Check.

* Someone remarks how discussion on emacs-devel repeats itself.  Now checked.

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 26 Aug 2021 22:37:32 +0300
> 
> On 26.08.2021 22:04, Eli Zaretskii wrote:
> > If you have an email
> > message that belongs to a bug, reply to it; otherwise simply write to
> > the bug address.
> 
> ...and cut off all prior participants from the discussions. Except those 
> who are subscribed to the mailing list, of course.

Way better than Github and its ilk, where I actually need to point my
browser to the issue to see the comments.

Re: Gitlab Migration

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Date: Thu, 26 Aug 2021 15:38:44 -0400
> Cc: emacs-devel@gnu.org, danflscr@gmail.com, Dmitry Gutov <dgutov@yandex.ru>
> 
> * Newcomer suggests PR-based workflow citing youth.  Check.
> 
> * Veterans chime in, citing the obvious reasons-for and the
> political reasons-against.  Check.
> 
> * EZ cites his *sui generis* argument that a web-based workflow is actually
> *more* work than mailing patches around.  Check.
> 
> * Someone announces his intention to begin the necessary work.  Check.
> 
> * Someone remarks how discussion on emacs-devel repeats itself.  Now checked.

What's the alternative? tell that "newcomer" we've been there and
please go away?  That's unkind and unbecoming.

Besides, there's always hope that this time someone will actually do
the job.  It did happen in the past.

Re: Gitlab Migration

[Dmitry Gutov]

On 26.08.2021 22:44, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Thu, 26 Aug 2021 22:37:32 +0300
>>
>> On 26.08.2021 22:04, Eli Zaretskii wrote:
>>> If you have an email
>>> message that belongs to a bug, reply to it; otherwise simply write to
>>> the bug address.
>>
>> ...and cut off all prior participants from the discussions. Except those
>> who are subscribed to the mailing list, of course.
> 
> Way better than Github and its ilk, where I actually need to point my
> browser to the issue to see the comments.

One is a social/collaborative matter, and another is a matter of 
personal convenience, which varies by person.

Re: Gitlab Migration

[Clément Pit-Claudel]

On 8/26/21 3:04 PM, Eli Zaretskii wrote:
> It's actually the other way around, at least in some cases.  With
> patches that are emailed to me, I can fix some simple issues, such as
> commit log messages or simple typos, myself, before applying.  With
> merging via Web UI, I need to push another commit, which is a waste,
> and also breaks what should have been a single commit into several
> ones.  So with Web UI, I expect _more_ requests to contributors to get
> their act together, where automated fixups are impossible, because
> there's little I can do myself.

Oh, that's not how it typically works in the project that I contribute to (and that I maintain): the maintainer often makes small fixes before merging, amends the relevant commits with those changes, and then merge using "git merge".  Did I misunderstand?

>> - Responding to old bugs is easier.  With a mailing list, it's no necessarily clear what the process is.  Should I send a new message to the bug address? Or does it need the right response headers?  In that case should I download the mbox first and import it into my email client?
> 
> I think you see problems where there are none.  If you have an email
> message that belongs to a bug, reply to it; otherwise simply write to
> the bug address.  admin/notes/bugtracker explains this within its
> first dozen of lines.

This is in line with what I wrote above: there is a process that is specific to Emacs, and it requires reading a document that is specific to Emacs to get it right (and you have to find that document).

It's not that bad, really; just not super discoverable. 

> And it isn't like GitLab and similar platforms don't have similar
> issues

Oh, I agree (see my next sentence ^^).

>> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.
> 
> I realize that some people who want to contribute don't like emacs or
> are intimidated by it. 

I would be surprised if anyone who wants to contribute patches to Emacs doesn't like Emacs.  Maybe I'm misunderstanding what you're saying.

> That's an important reason to provide the UI
> to which they are more accustomed.  But let's not exaggerate the
> advantages of these platforms for the Emacs developers: though some
> advantages exist, they are not that significant, at least IMO, and
> there are disadvantages (described in the GitLab issue).

And yet few of the packages hosted on MELPA — even those that don't get many external contributions — are developed using mailing lists (not sure about GNU ELPA).  That might suggest that even Emacs veterans see value in these online systems (?)

But really, I don't know about this part.  All I was responding to is a comment about emailing patches being easier than web forms for newcomers, and about a need to fix misconceptions about email.

> IOW, the most important reason for this move is to be more welcoming
> to casual contributors, not to make the job much easier for the
> maintainers.

That's fair (but the maintainers are doing an incredible job today, so it would be terrible to make your job harder).  This was also the reason that the Gnome and KDE folks cited when they moved to Gitlab (in 2018 and 2020, respectively; https://about.gitlab.com/blog/2018/05/31/welcome-gnome-to-gitlab/ and https://about.gitlab.com/blog/2020/06/29/welcome-kde/).

FWIW, this was the issue that KDE was using to track requirements for their move https://gitlab.com/gitlab-org/gitlab/-/issues/24900 

There isn't much data on whether Gnome moving to gitlab has helped with contributions, unfortunately.

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

[Dmitry Gutov]

On 26.08.2021 23:51, Arthur Miller wrote:

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

I didn't mean to say it's perfect, just more manageable.

And, like you say, a lot of users are already "trained" to look for 
prior discussions, prior issues, etc. This is harder to do with the 
email-based workflow.

We see people on Emacs Help asking similar questions over and over.

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

They should be informed, yes, but our antiquated bug tracker is the main 
technical weak point of the project. Some of the previous messages which 
referred to difficulties in email-based workflow were actually about 
"email-based Debbugs workflow".

Re: Gitlab Migration

[Arthur Miller]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 8/26/21 1:24 PM, Philip Kaludercic wrote:
>> Shouldn't it be easier to send an email than create an account, navigate
>> some web UI and fill in some form?
>
> I don't have strong opinions on mailing lists vs other approaches; but: no, not necessarily.
>
> - Unlike email, a webform allows mistakes to be fixed easily (messages can be
> edited after being posted).  A mailing list does not allow this, so for
> newcomers the fear of "doing something wrong" is high.  Many projects have an
> issue reporting template now, and that can be nice.
I am an expert in having fingers faster than my brain. I found people here being
quite resonable when I send a second mail to correct my misstake.

You are a point there, it is easier to go back and fix errors, but that is about
the only one. I don't think that is so big deal to be a showstopper.

>   (Yes, emacs has M-x report-emacs-bug, but no, I haven't set up my Emacs to send email yet, despite using Emacs for the last ten years).
>
> - Common actions can be mapped to buttons and dropdowns, making them more easily
> discoverable. I don't interact with debbugs often enough to remember the
> commands, so I need to look them up every time I want to close a bug, tag an
> issue, etc.  In practice, I mostly leave these tasks to other volunteers.  With
> a web UI, I can apply tags from a list of known tags, close issues, mark
> duplicates, subscribe to an issue, etc. just by clicking my way around.  I can
> also trivially CC someone in a discussion (this is not easy with debbugs: you
> need to set up a custom header in your message, and mistakes can't be fixed by
> editing the original message).  It may be less efficient (although email isn't
> exactly fast), but it's very discoverable.
So you ask for a context menu for debbugs, that could be done?

> - State tracking can be easier.  The Gitlab UI has, at all times, the latest
> version of a patchset.  On the emacs mailing list, maintainers regularly request
> a user to resent the latest version of a patchset, because changes can become
> hard to follow otherwise.
>
> - It requires less expertise with git and the patching workflow.  Committing to
> "one branch per patch" means that contributors don't need to know how to
> prepare

That was something I had a thoughts about. Couldn't we have a command that
automate this, somethign like M-x create-patch-request. That could automatically
create a patch between current branch and master, and send it away, maybe prompt
user for an additional message.

>                             It also means that maintainers (or bots!) can push
> fixes directly, instead of requesting them.  For example recently I opened a
> pull request for a Python project I had never contributed to, and an automated
> system promptly pushed an additional commit to the branch to reformat my code
> using the project's preferred style.
Yes, but those things work only with things that are easily automated, such as
wha tyou mention, formatting the code. That can be automated with Emacs as well,
and I don't see reason why the patch author can't use Emacs formatting when
writing Emacs patch. I personally dislike gnu coding style, it is probably the
ugliest and most unreadable coding style I have ever seen, but how much pain
does it cause me to use it occasionally? Not much. I can live with that when I
work with Emacs sources.

> - Responding to old bugs is easier.  With a mailing list, it's no necessarily
> clear what the process is.  Should I send a new message to the bug address? Or
> does it need the right response headers?  In that case should I download the
> mbox first and import it into my email client?
>
> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.

You are correct, but it is not particulary easy to use web interfaces en massé
either. I mean, people will clone repo to local disk anyway and code patch in
Emacs. Git can auto create patch. If one setups email account in Emacs, it is a
few clicks away to send patch to mailing list. It is more work to update your
repo on your gitlab account, than click on some button and fill some form to
send a PR.

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

[Stefan Monnier]

> Indeed.  But I expect that whatever we end up with, we (that is, the
> Emacs maintainers) won't have to click around, and won't have to
> actually merge anything directly.  That is, I expect to have a command
> in Emacs that says "get that pull request as a patch, apply it, and
> don't commit it".  So that we can fix stuff up before committing -- as
> before.

Personally I tend to just use `git am` which *does* commit, and then
I use `--amend` or `rebase` to perform adjustments.  Git supports that
particularly well.


        Stefan

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

[Stefan Monnier]

>> If you have an email message that belongs to a bug, reply to it;
>> otherwise simply write to the bug address.
> ...and cut off all prior participants from the discussions. Except those who
> are subscribed to the mailing list, of course.

Indeed, this a major downside of debbugs.


        Stefan

Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 23:51, Arthur Miller wrote:
>
>>> 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.
>
> I didn't mean to say it's perfect, just more manageable.
>
> And, like you say, a lot of users are already "trained" to look for prior
> discussions, prior issues, etc.

I ment they are not :-). Seems like many people are "asking first" instead of
"searching first". That is how I intepret tips on some github projects, to
search first before they report an issue.

If I find something problematic i usually do a web search, and than if SX,
Reddit and Google return nothing useful, than I consider sending a mail to the
list. That is why there are very few bugs I have reported :).

>
> We see people on Emacs Help asking similar questions over and over.
>
>>> 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?
>
> They should be informed, yes, but our antiquated bug tracker is the main
> technical weak point of the project. Some of the previous messages which
> referred to difficulties in email-based workflow were actually about
> "email-based Debbugs workflow".

I understand. Now I don't want to be a devil's advocate here, but for me
M-x debbugs-gnu is a bit slow to load into Emacs, but once loaded I think it is
not much worse Githubs "issues" list on any project. I think it is preferable
since I can see all bugs back to version 23, instead of having to click through
pages on github. Maybe there is some better interface to github web service, I
haven't tried their cli tool, maybe I should, but I don't know.

When I open a bug repport in debbugs-gnu I see entire mailing list tree and I
also can click on any of messages and S-W to send a reply, regardless of how old
it is.

But yes, the difference is that on the web, any random user who is interested
about a project, can go to project page, and look through the list of
"issues". It is not so straightforward with Emacs indeed. 

Re: Gitlab Migration

[Tim Cross]

Philip Kaludercic <philipk@posteo.net> writes:

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

I certainly agree email is easy. However, I'm old. When I talk to young
people i.e. in their 20s, they simply don't use email. Yes, they have an
email address, but that is only because of places that insist on one.
They communicate/share information via slack, discord, reddit, instagram
etc. Email is what they use when forced to interact with 'old'
institutions (Government, Uni, Grandparents etc).

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

I'm not sure how we achieve that. For many, email just isn't a comms
channel they are interested in. Your unlikely to convince anyone of the
benefits when your referring to a technology which simply doens't factor
into their world.

The answer is more likely a solution which allows multiple workflow
styles with no loss of functionality.

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

I suspect one of the things which made github so popular was that there
is little where you are forced to use only the web interface.
Admittedly, there are some things which take a little more effort or
setup to enable non-web UI access, but it is doable. From memory, Gitlab
was similar, but not quite and there are some functions which are either
restricted to web UI or need to be initiated via the web UI.

The solution is likely something which allows equal access via web UI,
email and command line. For example, an email gateway which creates
'pseudo' PRs, a 'shell' which allows full CLI interaction etc. 

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

There was also another repository which had a libre/free focus at all
levels/interfaces, but it too was more 'alpha' than 'beta' wrt
development status. 

Re: Gitlab Migration

[Po Lu]

Daniel Fleischer <danflscr@gmail.com> writes:

> 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.
>  Lowering the bar for participation is the key to growing Emacs and
>  the community.

People mention youth.  I think recently there was an excellent article
written by someone who would definitely qualify as "youth", and posted
to one of the social media platforms frequented by youth, which
basically summed up the process as "initially intimidating, but actually
easy".

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

And in GitLab, the code, issues and discussions are also in 3 separate
places: The repository, the issue tracker, and I'm not even sure what
the place for discussions is on these platforms.  Twitter perhaps?

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

Magit as a whole is nice, but Magit is not part of Emacs.  Forge may be
nice and all that, but has anyone found a way to use Gnus for
pull-requests?

Anyhow, I don't think any of these clients will solve the real problems
with these platforms.  Case in point: some time ago, I tried reporting
an issue on the Freedesktop.org GitLab instance, and tried to register
an account.  At first my browser froze and would not open the
registration form! After it did load, I had to resign myself to running
Google's reCaptcha, and even after that, the confirmation e-mail never
arrived and I gave up.  That seems to be a very high entry barrier for
new contributions.

Re: Gitlab Migration

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>
> IOW, the most important reason for this move is to be more welcoming
> to casual contributors, not to make the job much easier for the
> maintainers.

I agree. Also worth noting that making it too easy to contribute is not
necessarily a positive. I have worked on and helped maintain projects
where the bar for contributing was too low and you ended up with far too
many low quality or completely misguided patches and contributions.

As an example, a recent new release in one project has resulted in a
number of patches that are completely unnecessary because the
functionality they fix/add was either already available or due to local
configuration problems. While this likely indicates a need for better
documentation, part of the issue is due to it being just too easy to
generate a PR, which is often fired off and then forgotten by the OP - a
sort of 'log and flog' mentality that results in lots more
contributions, but a much higher noise ratio which consumes valuable
maintainer time sorting and analysing.

The right level of resistance to contributing can be a positive provided
that level is set appropriately. Many of the discussions I've read about
barriers to contributing to Emacs seem to be centred around
discoverability rather than honours process. Perhaps addressing that
aspect would be worthwhile rather than trying to re-engineer a whole new
framework?

Re: Gitlab Migration

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

I don't know enough git to tell you exactly what it is, but perhaps
whatever runs each time I check-in something to my local copy of the
repository that checks for indentation and extraneous whitespace could
also work for this?

Re: Gitlab Migration

[Jean-Christophe Helary]

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



> On Aug 27, 2021, at 9:38, Tim Cross <theophilusx@gmail.com> wrote:
> 
> The right level of resistance to contributing can be a positive provided
> that level is set appropriately. Many of the discussions I've read about
> barriers to contributing to Emacs seem to be centred around
> discoverability rather than honours process. Perhaps addressing that
> aspect would be worthwhile rather than trying to re-engineer a whole new
> framework?


I found this blog article very valuable (even though I find the conclusion mistaken)
https://www.fosskers.ca/en/blog/contributing-to-emacs

There is nothing intrinsically difficult in using email for this process, and if email is defined as the "channel" through which contributions to emacs are made, I am sure young people will catch up very quickly.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/


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

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

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> 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.
>
> I don't know enough git to tell you exactly what it is, but perhaps
> whatever runs each time I check-in something to my local copy of the
> repository that checks for indentation and extraneous whitespace could
> also work for this?

Couldn't identation and extraneous space be solved by either running after save
hook in Emacs, or by running emacs in batch mode as a git hook?

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 26 Aug 2021 16:09:32 -0400
> 
> On 8/26/21 3:04 PM, Eli Zaretskii wrote:
> > It's actually the other way around, at least in some cases.  With
> > patches that are emailed to me, I can fix some simple issues, such as
> > commit log messages or simple typos, myself, before applying.  With
> > merging via Web UI, I need to push another commit, which is a waste,
> > and also breaks what should have been a single commit into several
> > ones.  So with Web UI, I expect _more_ requests to contributors to get
> > their act together, where automated fixups are impossible, because
> > there's little I can do myself.
> 
> Oh, that's not how it typically works in the project that I contribute to (and that I maintain): the maintainer often makes small fixes before merging, amends the relevant commits with those changes, and then merge using "git merge".  Did I misunderstand?

AFAIK, merging a PM is usually a UI action.  But if it is done
manually like you describe, then there's no difference, and no
advantage to either method.

> >> - Responding to old bugs is easier.  With a mailing list, it's no necessarily clear what the process is.  Should I send a new message to the bug address? Or does it need the right response headers?  In that case should I download the mbox first and import it into my email client?
> > 
> > I think you see problems where there are none.  If you have an email
> > message that belongs to a bug, reply to it; otherwise simply write to
> > the bug address.  admin/notes/bugtracker explains this within its
> > first dozen of lines.
> 
> This is in line with what I wrote above: there is a process that is specific to Emacs, and it requires reading a document that is specific to Emacs to get it right (and you have to find that document).

I've yet to see a serious project of reasonably large size and age
that didn't have such a document.  Coding conventions and patch
submission conventions vary among projects and change with time, and
keeping them unwritten is not a good idea.

> >> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages.
> > 
> > I realize that some people who want to contribute don't like emacs or
> > are intimidated by it. 
> 
> I would be surprised if anyone who wants to contribute patches to Emacs doesn't like Emacs.  Maybe I'm misunderstanding what you're saying.

I meant email.  Sometimes my fingers think they know better what I
mean.

> > That's an important reason to provide the UI
> > to which they are more accustomed.  But let's not exaggerate the
> > advantages of these platforms for the Emacs developers: though some
> > advantages exist, they are not that significant, at least IMO, and
> > there are disadvantages (described in the GitLab issue).
> 
> And yet few of the packages hosted on MELPA — even those that don't get many external contributions — are developed using mailing lists (not sure about GNU ELPA).  That might suggest that even Emacs veterans see value in these online systems (?)

I didn't say there was no value, I said let's not exaggerate the
advantages.

And there's a difference between maintaining a project with perhaps
several Ks or several dozen Ks of lines, and maintaining Emacs.  With
Emacs we need all the power of the development environment
conveniently integrated in the same place; we need Emacs itself.

Re: Gitlab Migration

[tomas]

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

On Thu, Aug 26, 2021 at 10:37:32PM +0300, Dmitry Gutov wrote:
> On 26.08.2021 22:04, Eli Zaretskii wrote:
> >If you have an email
> >message that belongs to a bug, reply to it; otherwise simply write to
> >the bug address.
> 
> ...and cut off all prior participants from the discussions. Except
> those who are subscribed to the mailing list, of course.

There's no reason to not have a web accessible bug mail archive
indexed by bug number, for the webby folks our there. Perhaps
debbugs could implement that... oh wait [1]!

SCNR

[1] https://debbugs.gnu.org/db/pa/lemacs.html

 - t

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

Re: Gitlab Migration

[Clément Pit-Claudel]

On 8/27/21 1:51 AM, Eli Zaretskii wrote:
>> Oh, that's not how it typically works in the project that I contribute to (and that I maintain): the maintainer often makes small fixes before merging, amends the relevant commits with those changes, and then merge using "git merge".  Did I misunderstand?
> 
> AFAIK, merging a PM is usually a UI action.  But if it is done
> manually like you describe, then there's no difference, and no
> advantage to either method.

The UI action is available, but merging the branch in the git repository is enough.  The difference is (through forks) that every patch has its own branch.

> I've yet to see a serious project of reasonably large size and age
> that didn't have such a document.  Coding conventions and patch
> submission conventions vary among projects and change with time, and
> keeping them unwritten is not a good idea.

Of course.  The nice part about the web UIs is that bug-reporting instructions pop up automatically when you press the "report bug" button.

> And there's a difference between maintaining a project with perhaps
> several Ks or several dozen Ks of lines, and maintaining Emacs.  With
> Emacs we need all the power of the development environment
> conveniently integrated in the same place; we need Emacs itself.

Of course.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Thu, 26 Aug 2021 22:51:41 +0200
> Cc: philipk@posteo.net, Eli Zaretskii <eliz@gnu.org>, danflscr@gmail.com,
>  larsi@gnus.org, emacs-devel@gnu.org
> 
> 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/

It's mentioned on line 45 of CONTRIBUTE, near the beginning of the
"Getting involved with development" section.

> and debbugs package for browsing bugs directly from Emacs?

The debbugs package has several non-trivial dependencies, like email,
and is probably not the first or the second thing newcomers should be
messing with.

Re: Gitlab Migration

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 26 Aug 2021 16:09:32 -0400
>> 
>> On 8/26/21 3:04 PM, Eli Zaretskii wrote:
>> > It's actually the other way around, at least in some cases.  With
>> > patches that are emailed to me, I can fix some simple issues, such as
>> > commit log messages or simple typos, myself, before applying.  With
>> > merging via Web UI, I need to push another commit, which is a waste,
>> > and also breaks what should have been a single commit into several
>> > ones.  So with Web UI, I expect _more_ requests to contributors to get
>> > their act together, where automated fixups are impossible, because
>> > there's little I can do myself.
>> 
>> Oh, that's not how it typically works in the project that I contribute to (and
>> that I maintain): the maintainer often makes small fixes before merging,
>> amends the relevant commits with those changes, and then merge using "git
>> merge". Did I misunderstand?
>
> AFAIK, merging a PM is usually a UI action.  But if it is done
> manually like you describe, then there's no difference, and no
> advantage to either method.
>
It is really up to the individual. Github for exmaple, provides
instructions for merging PRs using either the web UI or the command
line. For the CLI, you are adding the remote PR as a 'remote' to your
local git repository. You can then check it out as a branch, review,
modify and test. If satisfied, you then just merge into your main branch
(or whatever branch is appropriate), push it up and close the PR.

Many people will just use the web UI. Personally, I prefer the CLI
approach as I like the additional control. At this level, it isn't
much different to how I imagine Emacs maintainers currently deal with
email patches i.e. checkout a fresh branch, apply the patch to that
branch, evaluate and if appropriate, merge into main branch.

The PR approach does have advantages, especially for those submitting
the PR. It can provide some useful immediate feedback (especially if
some of the advanced actions are used to perform common checks or policy
validation), provides a single definitive place, potentially including
review/comment history and changes and could be setup to help reduce
demands on core maintainers (for example, might require review by one or
more reviewers, who could be trusted volunteers who are comfortable to
assist with reviewing, but perhaps not with the responsibility of
merging). Core maintainers can then focus on just those PRs which have
been reviewed and avoiding wasting their limited time on things others
can deal with.

However, it seems the main issue isn't whether these so called 'modern'
workflows are a bad idea, but rather whether there is software which
implements these workflows which is FSF compliant. The best course of
action might be for those who would like to see adoption of these
workflows contribute to projects which are FSF compliant - perhaps
projects like sourceHut and help get a solution to a satisfactory
standard that it could be used by Emacs (and other GNU projects). Until
software is identified which meet FSF requirements, little can change
and debating the merits is largely pointless. 

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

[tomas]

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

On Thu, Aug 26, 2021 at 03:38:44PM -0400, dick wrote:
> * Newcomer suggests PR-based workflow citing youth.  Check.

[rest deleted]

And this was useful why exactly?

Look. If you have something constructive to contribute, go ahead.

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

[Daniel Fleischer]

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

john muhl [2021-08-26 Thu 14:13]  *wrote*:

> On Thu, 2021-08-26 at 14:51 -0400, Stefan Monnier wrote:
>> 
>> The last I heard from this is that some software was considered and
>> there was a web page summarizing the status, but that was maybe 2
>> years ago and I can't find that page any more
>
> maybe one on these:
> <https://libreplanet.org/wiki/FSF_2020_forge_evaluation>
> <https://www.gnu.org/software/repo-criteria-evaluation.html>

According to the forge evaluation link it seems Gitlab is not really an
option and the front runner is Fedora's Pagure. Are the people that did
the evaluation participate in this list? Where do things stand with
Pagure?

*Daniel Fleischer*

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

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

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

I also don't think it is an either/or choice. It should be possible to
support both email based workflows as well as web UI based ones. 

Debbugs state (was: [External] : Re: Gitlab Migration)

[Michael Albinus]

<tomas@tuxteam.de> writes:

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

The debbugs project in Debian has moved forward a lot since we have
forked back in 2008 (?). We shall merge.

This was planned already a while ago, but it has stalled
since. Volunteers welcome!

> Cheers

Best regards, Michael.

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]

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. 

Structured debbugs list per project (was: Gitlab Migration)

[Michael Albinus]

<tomas@tuxteam.de> writes:

> There's no reason to not have a web accessible bug mail archive
> indexed by bug number, for the webby folks our there. Perhaps
> debbugs could implement that... oh wait [1]!
>
> SCNR
>
> [1] https://debbugs.gnu.org/db/pa/lemacs.html

Hmm. Something I shall add to debbugs.el as well? Shouldn't be that
hard.

>  - t

Best regards, Michael.

Re: Structured debbugs list per project (was: Gitlab Migration)

[tomas]

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

On Fri, Aug 27, 2021 at 09:36:52AM +0200, Michael Albinus wrote:
> <tomas@tuxteam.de> writes:
> 
> > There's no reason to not have a web accessible bug mail archive
> > indexed by bug number, for the webby folks our there. Perhaps
> > debbugs could implement that... oh wait [1]!
> >
> > SCNR
> >
> > [1] https://debbugs.gnu.org/db/pa/lemacs.html
> 
> Hmm. Something I shall add to debbugs.el as well? Shouldn't be that
> hard.

Michael, you rock :)

Cheers
 - t

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

Re: Debbugs state (was: [External] : Re: Gitlab Migration)

[tomas]

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

On Fri, Aug 27, 2021 at 09:23:56AM +0200, Michael Albinus wrote:
> <tomas@tuxteam.de> writes:
> 
> > 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?
> 
> The debbugs project in Debian has moved forward a lot since we have
> forked back in 2008 (?). We shall merge.
> 
> This was planned already a while ago, but it has stalled
> since. Volunteers welcome!

Is there an entry point?

Thanks& cheers
 - t

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

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

[Andreas Schwab]

On Aug 27 2021, Tim Cross wrote:

> For the CLI, you are adding the remote PR as a 'remote' to your local
> git repository.

You don't even need to add a remote, the contents of the PR is available
as a ref in a non-default namespace.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: 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: Debbugs state

[Michael Albinus]

tomas@tuxteam.de writes:

Hi Tomas,

>> The debbugs project in Debian has moved forward a lot since we have
>> forked back in 2008 (?). We shall merge.
>>
>> This was planned already a while ago, but it has stalled
>> since. Volunteers welcome!
>
> Is there an entry point?

bug#26380, bug#43073

> Thanks& cheers
>  - t

Best regards, Michael.

Re: Gitlab Migration

[tomas]

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

On Fri, Aug 27, 2021 at 07:47:33PM +1000, Tim Cross wrote:

[...] However, we are getting off topic [...]

Agreed. Feel free to contact me off-list if you wish to
continue that discussion. I do have different views wrt
a couple of things in your thoughtful reply, but they
definitely don't belong here :-)

Cheers
 - t

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

Re: Debbugs state

[tomas]

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

On Fri, Aug 27, 2021 at 12:24:14PM +0200, Michael Albinus wrote:
> tomas@tuxteam.de writes:
> 
> Hi Tomas,
> 
> >> [...] Volunteers welcome!
> >
> > Is there an entry point?
> 
> bug#26380, bug#43073

Thanks :)

Cheers
 - t

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

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Fri, 27 Aug 2021 09:50:31 +0300
> Cc: emacs-devel@gnu.org
> 
> According to the forge evaluation link it seems Gitlab is not really an
> option and the front runner is Fedora's Pagure. Are the people that did
> the evaluation participate in this list?

Not to the best of my knowledge.

> Where do things stand with Pagure?

I don't think we seriously evaluated it.

Re: Gitlab Migration

[Dmitry Gutov]

On 27.08.2021 09:00, tomas@tuxteam.de wrote:
> There's no reason to not have a web accessible bug mail archive
> indexed by bug number, for the webby folks our there. Perhaps
> debbugs could implement that... oh wait [1]!

How does it help not to cut off previous participants from the 
discussion when you write a new message?

Re: Gitlab Migration

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Fri, 27 Aug 2021 16:10:03 +1000
> 
> > AFAIK, merging a PM is usually a UI action.  But if it is done
> > manually like you describe, then there's no difference, and no
> > advantage to either method.
> >
> It is really up to the individual. Github for exmaple, provides
> instructions for merging PRs using either the web UI or the command
> line. For the CLI, you are adding the remote PR as a 'remote' to your
> local git repository. You can then check it out as a branch, review,
> modify and test. If satisfied, you then just merge into your main branch
> (or whatever branch is appropriate), push it up and close the PR.

I know that one can do all that in Git commands, but the issue at hand
was the claim that PR workflow has advantages for the person who
merges the PR.  As I say above, if one does that via plain Git
commands, I see no advantages.

> (for example, might require review by one or more reviewers, who
> could be trusted volunteers who are comfortable to assist with
> reviewing, but perhaps not with the responsibility of merging).

These all are moot points for Emacs, because the people and roles you
describe simply don't exist.

> However, it seems the main issue isn't whether these so called 'modern'
> workflows are a bad idea, but rather whether there is software which
> implements these workflows which is FSF compliant.

I don't agree that this is the main issue.  It is an important factor,
yes.  But until we find a platform that fits the needs, it is also a
moot point, IMO.

> Until software is identified which meet FSF requirements, little can
> change and debating the merits is largely pointless.

I think it's the other way around: we need first to identify the
platform that fits our basic needs or can be extended to do that;
until we do that, it's pointless to look at the political issues.

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

[Dmitry Gutov]

On 27.08.2021 04:31, Arthur Miller wrote:
>>> 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.
>> I don't know enough git to tell you exactly what it is, but perhaps
>> whatever runs each time I check-in something to my local copy of the
>> repository that checks for indentation and extraneous whitespace could
>> also work for this?
> Couldn't identation and extraneous space be solved by either running after save
> hook in Emacs, or by running emacs in batch mode as a git hook?

Yes, you're both talking about git hooks. A minor disadvantage is that a 
hook needs to be installed, and then a bug in a hook implementation can 
stop you from being able to make a commit (there are overrides, but 
those require more googling).

CI is good because if its visibility: the list of checks on current PRs 
is visible to every newcomer, instead of being buried somewhere near the 
end of the CONTRIBUTE document.

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Fri, 27 Aug 2021 10:25:08 +0200
> From: <tomas@tuxteam.de>
> 
> > 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.

Office 365 includes Outlook, so I don't think you interpret that move
correctly.  It is most probably meant to avoid maintaining email
infrastructure in the company itself.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Fri, 27 Aug 2021 19:47:33 +1000
> Cc: emacs-devel@gnu.org
> 
> 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. 

There are no good replacements of email for companies that do business
with remote partners/clients.  On-line meetings aren't a good
solution, especially when issues are confidential and/or you need a
record of what was said.  Security issues with email have been solved
long time ago, so shouldn't prevent anyone from using email.  Where I
work during my day time, email is very much alive and kicking, and we
all have email clients on our smartphones, so we could respond very
quickly to any important developments.  I can tell you that with our
email-based workflows, we run circles around those of our partners and
competitors who don't.

Re: Gitlab Migration

[tomas]

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

On Fri, Aug 27, 2021 at 02:49:02PM +0300, Eli Zaretskii wrote:

[...]

> > I have watched this process around the 2010s in one company [...]

> Office 365 includes Outlook,

I know. I lived it :)

>                             so I don't think you interpret that move
> correctly.  It is most probably meant to avoid maintaining email
> infrastructure in the company itself.

This was but part of the equation (I had the chance to talk to some
folks next to the decision makers). Actually, this part of the equation
was the more problematic one, because of GDPR. Salespeople promised
this wouldn't be a problem, because "all servers would be in the EU".
Aha :-)

The other was "mail is old, and here we have something *much* better".
This was also the narrative the whole "change management" machinery
was built around, with "planes", "pilots" and "seats" and whatnot.

(Will stop now, because seriously off-topic)

Cheers
 - t

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

Re: Gitlab Migration

[dick]

> On Thu, Aug 26, 2021 at 03:38:44PM -0400, dick wrote:
>> * Newcomer suggests PR-based workflow citing youth.  Check.

> [rest deleted]

> And this was useful why exactly?

When you've been programming as long as I have, you realize more than ninety
percent of the discussion that takes place before a working draft is
irrelevant.  Robert Burns, who would have made an excellent programmer,
noticed this too.

Re: Gitlab Migration

[tomas]

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

On Fri, Aug 27, 2021 at 08:11:21AM -0400, dick wrote:
> > On Thu, Aug 26, 2021 at 03:38:44PM -0400, dick wrote:
> >> * Newcomer suggests PR-based workflow citing youth.  Check.
> 
> > [rest deleted]
> 
> > And this was useful why exactly?
> 
> When you've been programming as long as I have [...]

That was risky, I guess.

Cheers
 - t

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

Re: Gitlab Migration

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Date: Fri, 27 Aug 2021 08:11:21 -0400
> Cc: danflscr@gmail.com, emacs-devel@gnu.org
> 
> > On Thu, Aug 26, 2021 at 03:38:44PM -0400, dick wrote:
> >> * Newcomer suggests PR-based workflow citing youth.  Check.
> 
> > [rest deleted]
> 
> > And this was useful why exactly?
> 
> When you've been programming as long as I have, you realize more than ninety
> percent of the discussion that takes place before a working draft is
> irrelevant.  Robert Burns, who would have made an excellent programmer,
> noticed this too.

Do you (or someone else) have come up with a way to recover the 10%
that _is_ relevant without having the other 90%?  If so, please
describe that way, and we will see if we can follow it.

Re: Gitlab Migration

[Daniel Martín]

Daniel Fleischer <danflscr@gmail.com> writes:

> What areas need attention in order to facilitate the change?
>

Perhaps the people that contribute regularly to Emacs could describe
their workflow in more detail.  For example, things like how they like
to interact with bug reports (if they use the Debbugs Emacs package, for
example), how they search for bugs (if they use the web interface,
search mail locally, or something else), or if they'd like to do code
review from a web UI or doing it via email is a must for them.

I think it's also important to know about the problems and limitations
they face with the current system.

Re: Gitlab Migration

[Daniel Martín]

john muhl <email@johnmuhl.mx> writes:

> On Thu, 2021-08-26 at 17:24 +0000, Philip Kaludercic wrote:
>> 
>> I remember Sourceforge being suggested as an alternative to Gitlab,
>
> I think you mean sourcehut <https://sourcehut.org/> (free software)
> not sourceforge <https://sourceforge.net/> (saas).
>
>> but the software is currently still in a beta stage (AFAIR).
>

IIRC, Sourcehut's workflow to send and review patches is still based on
sending mail; it differs from the branch + pull request model of
GitHub/GitLab.

I still see benefits in the way Sourcehut manages and tracks patches,
but I'm not sure it'll help attract new Emacs contributors if the
premise is that people are afraid to contribute because they're not
familiar with email and git patches.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: emacs-devel@gnu.org
> Date: Fri, 27 Aug 2021 15:35:34 +0200
> 
> Daniel Fleischer <danflscr@gmail.com> writes:
> 
> > What areas need attention in order to facilitate the change?
> 
> Perhaps the people that contribute regularly to Emacs could describe
> their workflow in more detail.  For example, things like how they like
> to interact with bug reports (if they use the Debbugs Emacs package, for
> example), how they search for bugs (if they use the web interface,
> search mail locally, or something else), or if they'd like to do code
> review from a web UI or doing it via email is a must for them.

Are you asking about contributors or about the core maintainers?
E.g., you mention interaction with bug reports, but AFAIK contributors
have only one kind of interaction here: when they submit a report.  So
I wonder whether I understand your questions.

Re: Gitlab Migration

[Daniel Martín]

Eli Zaretskii <eliz@gnu.org> writes:

>
> Are you asking about contributors or about the core maintainers?
> E.g., you mention interaction with bug reports, but AFAIK contributors
> have only one kind of interaction here: when they submit a report.  So
> I wonder whether I understand your questions.

The core maintainers: The people that usually check for new bug reports
and act on them, classify them by priority and see if they block a
release, review and commit any patches that are sent to fix the bugs,
etc.

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

[Lars Ingebrigtsen]

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

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

There doesn't seem to be much movement on getting GitLab to support the
features we want, so perhaps we should take a closer look at SourceHut
instead.  Has anybody here done an evaluation of SourceHut to see
whether it'd fit our requirements?

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

Re: Gitlab Migration

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> 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.
>
> There doesn't seem to be much movement on getting GitLab to support the
> features we want, so perhaps we should take a closer look at SourceHut
> instead.  Has anybody here done an evaluation of SourceHut to see
> whether it'd fit our requirements?

I have seen this thread:

https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC03B4X6WE7XN.9NAXAORGDJ0B%40homura%3E

It is over a year old, so I am not sure if anything has changed.

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Tassilo Horn]

Daniel Martín <mardani29@yahoo.es> writes:

>> I think you mean sourcehut <https://sourcehut.org/> (free software)
>> not sourceforge <https://sourceforge.net/> (saas).
>
> IIRC, Sourcehut's workflow to send and review patches is still based
> on sending mail; it differs from the branch + pull request model of
> GitHub/GitLab.

That's right.

> I still see benefits in the way Sourcehut manages and tracks patches,

Could you elaborate on that?  I'm using sr.ht for some projects and like
it but haven't seen anything related to tracking and managing patches.
Is there anything beyond "use git send-email to the project mailing
list" from which the maintainer can just "git am"?

Oh, cool, now I've found out that you can filter the list for patches,
mark them as applied or "needs revision" etc.  Thanks for making me
aware!

Bye,
Tassilo

Re: Gitlab Migration

[André A. Gomes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There doesn't seem to be much movement on getting GitLab to support the
> features we want, so perhaps we should take a closer look at SourceHut
> instead.  Has anybody here done an evaluation of SourceHut to see
> whether it'd fit our requirements?

I've used SourceHut a bit, and I think it would be suitable for Emacs.
It's email based but it also provides a web UI to centralise all
relevant information.

In fact, sooner or later GNU will replace Savannah and sourcehut has
been referenced as a strong candidate.


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

Re: Gitlab Migration

[Theodor Thornhill]

On 27 August 2021 16:46:22 CEST, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> 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.
>
>There doesn't seem to be much movement on getting GitLab to support the
>features we want, so perhaps we should take a closer look at SourceHut
>instead.  Has anybody here done an evaluation of SourceHut to see
>whether it'd fit our requirements?
>

We actually discussed it on this list with its creator, Drew DeVault last year: 
https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html

Everything seems to be ready, if I understand him correctly. I think he'd be enthusiastic about this.

Theodor

Re: Gitlab Migration

[Daniel Martín]

Tassilo Horn <tsdh@gnu.org> writes:

>
> Could you elaborate on that?  I'm using sr.ht for some projects and like
> it but haven't seen anything related to tracking and managing patches.
> Is there anything beyond "use git send-email to the project mailing
> list" from which the maintainer can just "git am"?
>
> Oh, cool, now I've found out that you can filter the list for patches,
> mark them as applied or "needs revision" etc.  Thanks for making me
> aware!

Yes, there's some tagging and classification on top of plain mailing
list patches.  Another interesting feature of SourceHut is its
continuous integration support for patches. Core maintainers, before
merging a patch, could easily see if it breaks something in a rare
platform or if it generates new warnings.

RE: [External] : Re: Gitlab Migration

[Drew Adams]

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

+1.

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

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

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

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

+1.

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

Agree.

RE: [External] : Re: Gitlab Migration

[Drew Adams]

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

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

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

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

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

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

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

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

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

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

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

Additional interfaces/UXes, yes.

> Arguments about one being better than the other are pointless

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

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

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

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

Re: [External] : Re: Gitlab Migration

[tomas]

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

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

[...]

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

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

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

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

Cheers
 - t

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

Re: Gitlab Migration

[Augusto Stoffel]

On Thu, 26 Aug 2021 at 17:24, Philip Kaludercic <philipk@posteo.net> 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.

To quote Rich Hickey, a pull request is not a value.

A patch is just a value, so no wonder it's easier to make a patch reach
an Emacs maintainer than to maneuver an online collaboration platform
into some state.

Re: Gitlab Migration

[João Távora]

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

On Fri, Aug 27, 2021, 12:31 Eli Zaretskii <eliz@gnu.org> 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.
>

I wish this point was stressed more often. Git, to which we've switched
reasonably recently after some pain, accommodates many many workflows. We
should embrace that!!

E.g. if browser living people want to make PRs to an intermediate repo on
GitHub, they can today! And then once they're reasonably stable and agreed
upon, some email wizard (really, can be me, even though I'm not really a
wizard) can push them to main repo, and even adjust a commit message or
two. Git provides lots of commands for that,. I'm happy to explain and
document them, though I doubt I'm the only such expert here.

The main question is where the discussion happens: it has to be email,
period. And right now it's debbugs and emacs-devel. And yes I know that
GitHub/gitlab do pretty links automatically between web UI parts, but how
is that so different from sending email where you say you have a public
branch with x commits here or there?

My two cents,
João

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

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Fri, 27 Aug 2021 17:29:46 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: Eli Zaretskii <eliz@gnu.org>, Daniel Fleischer <danflscr@gmail.com>,
>  philipk@posteo.net
> 
> >There doesn't seem to be much movement on getting GitLab to support the
> >features we want, so perhaps we should take a closer look at SourceHut
> >instead.  Has anybody here done an evaluation of SourceHut to see
> >whether it'd fit our requirements?
> >
> 
> We actually discussed it on this list with its creator, Drew DeVault last year: 
> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html

That was almost a year ago, and the discussion is thin on actual
details.  Support for email-based workflow is a good start, and is one
of the main requirements, but what about the GitLab/Github-like
features? if they are missing or incomplete, we will be trading
debbugs for something that is basically the same beast in a different
wrapping.  And what about the other requirements we collected and
documented in the GitLab issue about this?

So, like Lars, I think it would help if someone could post an
evaluation of SourceHut vs what we'd like to see, using the GitLab
issue as the baseline.

TIA

Re: Gitlab Migration

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 27 Aug 2021 17:29:46 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: Eli Zaretskii <eliz@gnu.org>, Daniel Fleischer <danflscr@gmail.com>,
>>  philipk@posteo.net
>> 
>> >There doesn't seem to be much movement on getting GitLab to support the
>> >features we want, so perhaps we should take a closer look at SourceHut
>> >instead.  Has anybody here done an evaluation of SourceHut to see
>> >whether it'd fit our requirements?
>> >
>> 
>> We actually discussed it on this list with its creator, Drew DeVault last year: 
>> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>
> That was almost a year ago, and the discussion is thin on actual
> details.  Support for email-based workflow is a good start, and is one
> of the main requirements, but what about the GitLab/Github-like
> features? if they are missing or incomplete, we will be trading
> debbugs for something that is basically the same beast in a different
> wrapping.  And what about the other requirements we collected and
> documented in the GitLab issue about this?
>

It seems like Sourcehut supports everything requested, but I might be
missing something, of course.  In particular the CI is very nice and
simple, at least for the hosted version at https://sr.ht.  It also
supports running without javascript at all, so the libreJS debate should
be settled right there. Instead of me speaking on sourcehuts behalf,
with which I have no affiliation outside of being a happy customer
myself, I'll ping the creator.

@drew, should I or someone else create an issue over at sourcehut about
this or do you want to chime in here?  (apologies if contacting you this
way is inappropriate)


> So, like Lars, I think it would help if someone could post an
> evaluation of SourceHut vs what we'd like to see, using the GitLab
> issue as the baseline.
>
> TIA


Hope this helps,
Theodor

Re: Gitlab Migration

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
> Date: Fri, 27 Aug 2021 21:38:43 +0200
> 
> >> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
> >
> > That was almost a year ago, and the discussion is thin on actual
> > details.  Support for email-based workflow is a good start, and is one
> > of the main requirements, but what about the GitLab/Github-like
> > features? if they are missing or incomplete, we will be trading
> > debbugs for something that is basically the same beast in a different
> > wrapping.  And what about the other requirements we collected and
> > documented in the GitLab issue about this?
> >
> 
> It seems like Sourcehut supports everything requested, but I might be
> missing something, of course.  In particular the CI is very nice and
> simple, at least for the hosted version at https://sr.ht.  It also
> supports running without javascript at all, so the libreJS debate should
> be settled right there. Instead of me speaking on sourcehuts behalf,
> with which I have no affiliation outside of being a happy customer
> myself, I'll ping the creator.

Would it be possible to have a more detailed review, like short
description of what is available for each of the requirements in the
GitLab issue?  That should give us a good idea of how close we are to
the goal.

I tried to find answers to those questions myself, but there doesn't
seem to be any detailed documentation that describes the setup and
usage from the routine user POV (or maybe I missed it?).  I did find a
heads-up that "from the beta onwards, unpaid accounts will be limited
to read-only access to their own projects", so I wonder what that
means for us.  It also says that "web-based workflow for submitting
and reviewing patches" is still under development.

GitLab feature request compared with SourceHut (was: Re: Gitlab Migration)

[Sean Whitton]

Hello,

On Fri 27 Aug 2021 at 10:08PM +03, Eli Zaretskii wrote:

>> Date: Fri, 27 Aug 2021 17:29:46 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: Eli Zaretskii <eliz@gnu.org>, Daniel Fleischer <danflscr@gmail.com>,
>>  philipk@posteo.net
>>
>> >There doesn't seem to be much movement on getting GitLab to support the
>> >features we want, so perhaps we should take a closer look at SourceHut
>> >instead.  Has anybody here done an evaluation of SourceHut to see
>> >whether it'd fit our requirements?
>> >
>>
>> We actually discussed it on this list with its creator, Drew DeVault last year:
>> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>
> That was almost a year ago, and the discussion is thin on actual
> details.  Support for email-based workflow is a good start, and is one
> of the main requirements, but what about the GitLab/Github-like
> features? if they are missing or incomplete, we will be trading
> debbugs for something that is basically the same beast in a different
> wrapping.  And what about the other requirements we collected and
> documented in the GitLab issue about this?

For reference, the GitLab issue:
<https://gitlab.com/gitlab-org/gitlab/-/issues/28152>

> So, like Lars, I think it would help if someone could post an
> evaluation of SourceHut vs what we'd like to see, using the GitLab
> issue as the baseline.

Using the headers in the GitLab issue:

E-MAIL WORKFLOW

This is a given.  SourceHut is all about this.

Something to emphasise is that because SourceHut is e-mail first, rather
than a web platform with e-mail access tacked on, you don't have to
worry about how web forges can do things like ignoring everything in the
message after the first quoted portion, for example.  You don't find
yourself going on the website after replying by e-mail just to check
your text made it through.

REDUCE E-MAIL NOISE

There isn't much granularity regarding notifications, AFAICT.

SUBMITTING PATCHES BY E-MAIL

There's a web interface to prepare patch sets designed to be familiar
to web forge users.

OFFLINE REVIEW

Yes.

REVIEWING PATCHES BY E-MAIL

Yes.

MERGE REQUEST CREATION

Yes.

CODE SHOULD BE ACCOMPANIED BY DOCUMENTATION

Could be done with CI, like GitLab.

FORMATTING CODE COMMITS

Could be done with CI, like GitLab.

DIFF MAILING LIST

No special features for this, I believe.  You'd need a bot.

TRACEABILITY OF MERGE REQUESTS

The mailing list web interface keeps track of the status of series and
tags them "proposed", "applied" etc. and this is searchable.

CONTINUOUS INTEGRATION

Yes.

CLOSELY INTEGRATED BUGTRACKER

Looks a bit manual atm, but a big step up from debbugs because there is
both e-mail control and clickable buttons.

SPELLING & GRAMMAR CHECKING

Could be done with CI.

COPYRIGHT ASSIGNMENTS

Could be done with CI.

LICENSING

Yes.

INTEGRATION WITH SAVANNAH

SourceHut can currently use PAM users, so a Savannah/LDAP integration
along the same lines ought to be doable.

EMACS FRONTEND FOR BUG TRACKER

Doesn't exist yet :)

BUG REPORTING

Filing bugs and starting mailing list threads are both just a matter of
sending e-mails, so report-emacs-bug could do it.

-- 
Sean Whitton

Re: Gitlab Migration

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
>> Date: Fri, 27 Aug 2021 21:38:43 +0200
>> 
>> >> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>> >
>> > That was almost a year ago, and the discussion is thin on actual
>> > details.  Support for email-based workflow is a good start, and is one
>> > of the main requirements, but what about the GitLab/Github-like
>> > features? if they are missing or incomplete, we will be trading
>> > debbugs for something that is basically the same beast in a different
>> > wrapping.  And what about the other requirements we collected and
>> > documented in the GitLab issue about this?
>> >
>> 
>> It seems like Sourcehut supports everything requested, but I might be
>> missing something, of course.  In particular the CI is very nice and
>> simple, at least for the hosted version at https://sr.ht.  It also
>> supports running without javascript at all, so the libreJS debate should
>> be settled right there. Instead of me speaking on sourcehuts behalf,
>> with which I have no affiliation outside of being a happy customer
>> myself, I'll ping the creator.
>
> Would it be possible to have a more detailed review, like short
> description of what is available for each of the requirements in the
> GitLab issue?  That should give us a good idea of how close we are to
> the goal.

Here is my take:

+ Email workflow

  Is supported as a first-class interaction method

+ Reduce email noise

  The mailing lists are just mailing lists, from
  what I know the only "spam" might be CI responding with the results of
  a test

+ Submitting patches by email

  Is supported as part of the email workflow

+ Offline review

  Same as above

+ Reviewing patches by email

  Ditto, and the comments are rendered properly in the web UI.

* Merge request creation

  Not sure if this is applicable, you'd usually just send a patch and
  not create a format "merge request".

* Code should be accompanied by documentation

  Here too I cannot say for sure, but I can imagine integrating checkdoc
  into a CI that automatically warns a patch-submitter if something
  isn't documented properly.

* Formatting code commits

  Same as above.

* Traceability of Merge Requests

  Again, merge requests are not formal but just a message on the mailing
  list, usually generated by git send-email. (There might be an issue
  here if users just attach patches as they do now.)

+ Continuous integration

  Is given

? Closely integrated bugtracker

  I haven't used "todo" (the issue tracker,
  https://man.sr.ht/todo.sr.ht/) enough to really comment on this. My
  general understanding is that this, integration between the different
  components, is one of the things that remain in need of improvement
  before the project leaves the beta stage

* Spell & grammar checking

  Again, could be done with CIs. Assuming one has a grammar checker.

- Branch rules

  I don't know of any mechanism to limit access to branches.

* Copyright assignments

  CI should be able to handle this.

+ Licensing

  Yes!

- Integration with savannah

  Is not implemented, but the question is if the existing infrastructure
  should be extended or replaced.

- Integration with debbugs

  Same as above.

- Emacs frontend for bug tracker

  There is no package for sourcehut comparable to debbugs, but it
  shouldn't be hard to implement considering that.
  
+ Bug reporting

  The mailing list should be able to handle bugs M-x report-emacs-bug.
  
> I tried to find answers to those questions myself, but there doesn't
> seem to be any detailed documentation that describes the setup and
> usage from the routine user POV (or maybe I missed it?).  I did find a
> heads-up that "from the beta onwards, unpaid accounts will be limited
> to read-only access to their own projects", so I wonder what that
> means for us.  It also says that "web-based workflow for submitting
> and reviewing patches" is still under development.

It shouldn't mean anything, if GNU decides to host their own
instance. Otherwise, every project member would have to play to have an
account, but I assume mailing list contributors could continue accessing
the mailing list without any issue.

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:


[...]

>
> Would it be possible to have a more detailed review, like short
> description of what is available for each of the requirements in the
> GitLab issue?  That should give us a good idea of how close we are to
> the goal.
>

Sure, I can try.  At the minimum, it can serve as a starting point from
which Drew can correct all my mistakes when he chimes in.  Firstly, I'll
say that it in general offers a similar workflow to what emacs
developers already use.  It also has an explicit goal of not being too
GitHub/GitLab-like, where pull requests are the default way to
contribute.  However, there are some key differences. You don't need a
user account to use it, though that gives you some benefits like cloning
repos etc.  It is and always will be (I think) emailbased rather than
forms on the web.  That means using `git am` and friends to push and
pull the code.

About payment - all users should be able to report bugs when it hits
beta.  The paid features is for the cloning and personal repo hosting, I
think.  Also not sure if this applies when sourcehut is self hosted.

As for the specific points in the gitlab issue, let me make an effort:

* Email workflow
This is a given.  Patches and discussions are all first class citizens,
meaning that it is all backed by email. You can open, close, adjust and
respond to issues using email.

** Submitting patches by email.
It is possible to send patches using a web interface.  It works by using
the `prepare a patchset` button on your own clone.  So the process
is usually:
  - clone the repo
  - pull it locally
  - do the work
  - push the work
  - use the `prepare a patchset` button or `git format-patch`

It is then sent to the respective mailing list

** Offline review
An issue (if not already subscribed to all) can be subscribed to your
own email and be sent to you.  The whole thing or parts of it can be
downloaded as an mbox.

** Reviewing by email
You can use inline comments [1]

** Merge request creation
Honestly I don't really understand this one...

* Code should be accompanied by documentation

This seems trivial, and can be done using the CI on patch submission
running a job, if I understand that point correctly?

* Formatting code commits
 Same as above

* Diff mailing list
This I don't know

* Traceability of Merge Requests

There is at least a basic web search available on the web client for
this, but seeing how the only repo I maintain with actual contributors I
maintain is on GitHub I don't have much first hand experience here.

* Continuous integration
This is one of sourcehuts strong points, as I see it. Jobs can be run on
patch submission and on commits, and is also inspectable through ssh
should something break.  Arbitrary stuff can be done here.

* Closely integrated bugtracker
automated tasks for patch application and status updates exist here

...

There seems to be some more points here that could be covered by CI, so
I'll jump a little
...

* Licensing
No js is needed
Captcha is not used
GNU criteria for ethics I cannot say anything about. Though it would
surprise me if it didn't score well.

* Integration with savannah
I can't say anything about this

* Integration with debbugs
Seeing how both use mbox this should be trivial to do

* Bug reporting
`report-emacs-bug` can still be used, as well as clicking in the web
ui. This is where I'm not sure about not using email.  I think you still
need to mail the bug, opened by a mailto:

I hope this helps a little.

--
Theodor

[1]: https://lists.sr.ht/~technomancy/fennel/patches/24386

Re: Gitlab Migration

[Sean Whitton]

Hello,

On Fri 27 Aug 2021 at 08:58PM GMT, Philip Kaludercic wrote:

> It shouldn't mean anything, if GNU decides to host their own
> instance. Otherwise, every project member would have to play to have an
> account, but I assume mailing list contributors could continue accessing
> the mailing list without any issue.

Regarding the hosted offering at sr.ht, contributors don't need to pay,
only the project owners.

-- 
Sean Whitton

Re: Gitlab Migration

[Stefan Monnier]

> Perhaps the people that contribute regularly to Emacs could describe
> their workflow in more detail.  For example, things like how they like
> to interact with bug reports (if they use the Debbugs Emacs package, for
> example),

FWIW, here are my main criticisms of debbugs for my own personal use:

- Can't search the database when I'm offline.
  I really wish the database was stored in Git, so I could easily have
  a clone of it.  This said, compared to other issue tracking systems,
  the fact that it works over email makes it at least partly usable
  offline, which is a big plus.

- No notion of "subscription" to a bug, so replies will sometimes fail
  to reach me.

- The notion of "archived" bugs is a pain in the rear when you send
  a new message and the message just bounces back with "the bug is
  archived".
  Either get rid of it, or automatically unarchive bugs when a new reply
  is received, or something (e.g. ask for a confirmation message to
  unarchive the bug and add the already sent message), but the current
  way this is handled is *really* poor.

- I find it a big difficult to classify bugs.  I'm not sure exactly what
  I'd like, and maybe some of it can be done via tags and other things
  already, but I think I'd like it if bugs could be "assigned" to persons
  and/or to files and/or to "subsystems", and maybe even combine this
  with ways to describe relationships between those things (so the
  search tools can known that a given file belongs to a particular
  subsystem, for example).

The poor web UI is of course another criticism but it mostly doesn't
affect me.


        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

[Theodor Thornhill]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

This isn't really true though.  There definitely are links to builds and
inline comments.  Though I agree on parts of this.  One missing thing as
I see it is the updated patch. You need to find the latest patches, and
it won't update as in GitHub when you add another "oops" commit.

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

Yeah.  One might also think that some contributions could trickle down
to sourcehut itself when emacs workflow settles, so the "github way" of
contributing could get a little love?

Theo

Re: Gitlab Migration

[Dmitry Gutov]

On 28.08.2021 00:17, Theodor Thornhill wrote:

>>   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.
> 
> This isn't really true though.

It seems substantially true.

> There definitely are links to builds and

There's no such examples on the home page (and it does have a link to a 
page supposed to resemble a code review). If you have a better link, 
please share.

> inline comments.

Inline comments like quoting parts of an attached patch inline in an 
email, which we've been doing for decades in emacs-devel? That's not 
even close to a dedicated code review UI.

> Though I agree on parts of this.  One missing thing as
> I see it is the updated patch. You need to find the latest patches, and
> it won't update as in GitHub when you add another "oops" commit.

The review UI would need to be tied to a particular branch, instead of 
some file attachments. And happen not in a email client, but either in a 
browser, or perhaps some re-implementation of the same UI inside Emacs.

>> Of course, it should still be a significant step forward compared to the
>> current situation.
> 
> Yeah.  One might also think that some contributions could trickle down
> to sourcehut itself when emacs workflow settles, so the "github way" of
> contributing could get a little love?

I doubt that: since the system is email-first, it would likely be hard 
to promote/upstream features that don't translate well to email. Even if 
someone writes an Emacs UI for them. Does Drew use Emacs?

Re: Gitlab Migration

[Theodor Thornhill]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 28.08.2021 00:17, Theodor Thornhill wrote:
>
>>>   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.
>> 
>> This isn't really true though.
>
> It seems substantially true.
>
>> There definitely are links to builds and
>
> There's no such examples on the home page (and it does have a link to a 
> page supposed to resemble a code review). If you have a better link, 
> please share.
>

https://lists.sr.ht/~technomancy/fennel/patches/24386

This shows both a build that succeeded and an inline comment.  More
complicated stuff is likely still missing, but this seems to address
part of what you were referring to, doesn't it?  There's also examples
where faling builds sends out notifications etc.  I can try to find some
of those, but that will be shooting in the dark until I find one...

>> inline comments.
>
> Inline comments like quoting parts of an attached patch inline in an 
> email, which we've been doing for decades in emacs-devel? That's not 
> even close to a dedicated code review UI.
>
>> Though I agree on parts of this.  One missing thing as
>> I see it is the updated patch. You need to find the latest patches, and
>> it won't update as in GitHub when you add another "oops" commit.
>
> The review UI would need to be tied to a particular branch, instead of 
> some file attachments. And happen not in a email client, but either in a 
> browser, or perhaps some re-implementation of the same UI inside Emacs.
>

Yeah, I agree this is missing, at least if we're not willing to accept
that this might not be the number one thing to need before migrating.


>>> Of course, it should still be a significant step forward compared to the
>>> current situation.
>> 
>> Yeah.  One might also think that some contributions could trickle down
>> to sourcehut itself when emacs workflow settles, so the "github way" of
>> contributing could get a little love?
>
> I doubt that: since the system is email-first, it would likely be hard 
> to promote/upstream features that don't translate well to email. Even if 
> someone writes an Emacs UI for them. Does Drew use Emacs?

You might be correct about this.  No, he is a vim user, and seems a
little negative towards emacs, as far as I can tell.

Theodor

Re: Gitlab Migration

[Dmitry Gutov]

On 28.08.2021 00:44, Theodor Thornhill wrote:

>> There's no such examples on the home page (and it does have a link to a
>> page supposed to resemble a code review). If you have a better link,
>> please share.
>>
> 
> https://lists.sr.ht/~technomancy/fennel/patches/24386
> 
> This shows both a build that succeeded and an inline comment.  More
> complicated stuff is likely still missing, but this seems to address
> part of what you were referring to, doesn't it?

Finally found it. Yeah, that looks good. Hope others will have an easier 
time noticing it.

> There's also examples
> where faling builds sends out notifications etc.  I can try to find some
> of those, but that will be shooting in the dark until I find one...

I think I'll take you at your word here. And yeah, notifications are 
important.

>> The review UI would need to be tied to a particular branch, instead of
>> some file attachments. And happen not in a email client, but either in a
>> browser, or perhaps some re-implementation of the same UI inside Emacs.
>>
> 
> Yeah, I agree this is missing, at least if we're not willing to accept
> that this might not be the number one thing to need before migrating.

I think a more important blocker is the bug tracker integration 
(sourcehut has something called "todo", right?). I hear it's still 
work-in-progress, though maybe that info is outdated?

If after migration we're still using Debbugs, that's pretty much going 
to nullify any advantages, in my eyes.

Re: Gitlab Migration

[Yuchen Pei]

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


Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 19:56, Eli Zaretskii wrote:
>> We could prioritize the requirements, perhaps, and consider 
>> switching
>> after some critical mass of them is done.
>
> Sounds good.
>
> The two "external" items (reCAPTCHA and LibreJS) might be hard
> requirements from RMS, though.

Well, they are problematic because reCAPTCHA is nonfree, and the 
mandatory javascript programs have no license information that 
comes with them (hence not librejs-compliant).

As others have mentioned there is an ongoing effort in evaluating 
forges mainly based on free software values:

- https://www.gnu.org/software/repo-criteria.en.html
- https://lists.gnu.org/mailman/listinfo/repo-criteria-discuss

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

[Yuchen Pei]

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


Daniel Fleischer <danflscr@gmail.com> writes:

> john muhl [2021-08-26 Thu 14:13]  *wrote*:
>
>> On Thu, 2021-08-26 at 14:51 -0400, Stefan Monnier wrote:
>>> 
>>> The last I heard from this is that some software was 
>>> considered and
>>> there was a web page summarizing the status, but that was 
>>> maybe 2
>>> years ago and I can't find that page any more
>>
>> maybe one on these:
>> <https://libreplanet.org/wiki/FSF_2020_forge_evaluation>
>> <https://www.gnu.org/software/repo-criteria-evaluation.html>
>
> According to the forge evaluation link it seems Gitlab is not 
> really an
> option and the front runner is Fedora's Pagure. Are the people 
> that did
> the evaluation participate in this list? Where do things stand 
> with
> Pagure?

I participate in the repo evaluation from time to time.  AIUI 
pagure.io has not been evaluated yet.

>
> *Daniel Fleischer*


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

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Thu, 26 Aug 2021 22:51:41 +0200
>> Cc: philipk@posteo.net, Eli Zaretskii <eliz@gnu.org>, danflscr@gmail.com,
>>  larsi@gnus.org, emacs-devel@gnu.org
>> 
>> 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/
>
> It's mentioned on line 45 of CONTRIBUTE, near the beginning of the
> "Getting involved with development" section.
>
>> and debbugs package for browsing bugs directly from Emacs?
>
> The debbugs package has several non-trivial dependencies, like email,
> and is probably not the first or the second thing newcomers should be
> messing with.

Maybe, but if somoeone is developer who would like to send in patch to Emacs
than they can probably setup email? Newcomer to Emacs dev, does not mean
newcomer to computing.

What about automating it for them?

Is this too wild: when someone signs FSF copyrights assignement, create
automatic "development mail account", which will work only to send and recieve
emails between certain addresses, the person and those used for Emacs
devs? We could then write a small pacakge to auto-setup persons account in
his/her Emacs that would work for bug repporting, debbugs, sending patches etc.

Limitiation because I guess FSF/GNU does not have resources to host free email
accounts for everyone.

We could then abstract parts of PR based worklfow on top of email.

Re: Structured debbugs list per project

[Arthur Miller]

tomas@tuxteam.de writes:

> On Fri, Aug 27, 2021 at 09:36:52AM +0200, Michael Albinus wrote:
>> <tomas@tuxteam.de> writes:
>> 
>> > There's no reason to not have a web accessible bug mail archive
>> > indexed by bug number, for the webby folks our there. Perhaps
>> > debbugs could implement that... oh wait [1]!
>> >
>> > SCNR
>> >
>> > [1] https://debbugs.gnu.org/db/pa/lemacs.html
>> 
>> Hmm. Something I shall add to debbugs.el as well? Shouldn't be that
>> hard.
>
> Michael, you rock :)
>
> Cheers
>  - t
+1

Yes you do rock Michael!

Re: Gitlab Migration

[Arthur Miller]

<tomas@tuxteam.de> writes:

> 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.
Another aspect of those is one we touched on in some of our previous
conversations a year or so ago.

The personal or company PR (public relations). It is sort of CV, persons or a
companies track of popularity, what useful and how much they have done and so
on. It is all about selection :). That is why Instagram is so popular I guess.

Email based workflow does not promote same degree of self-promotion for people,
so they will prefer public stuff. When they give you a PR it is visible on their
GH/GL, when they send you a patch, there is a record in some mail database, but
it is not as visible. 

> 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.
Yes, everybody still uses mail, and a normal day in office for many, many peopel
is to just sit with Outlook or Lotus Notes and answer/write mails 8 hours a
day. I have seen this for last 15 years, but I do see a shift toward instant
messaging and video messaging/ip calls, amongst younger generation. I mean
"younger" in this context is in later 40's now :). But email is still the prime
way of "recording" stuff, confirming so to say.

> 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
Your rants are always spot on. 

Re: Gitlab Migration

[Arthur Miller]

tomas@tuxteam.de writes:

> On Fri, Aug 27, 2021 at 02:49:02PM +0300, Eli Zaretskii wrote:
>
> [...]
>
>> > I have watched this process around the 2010s in one company [...]
>
>> Office 365 includes Outlook,
>
> I know. I lived it :)
>
>>                             so I don't think you interpret that move
>> correctly.  It is most probably meant to avoid maintaining email
>> infrastructure in the company itself.
>
> This was but part of the equation (I had the chance to talk to some
> folks next to the decision makers). Actually, this part of the equation
> was the more problematic one, because of GDPR. Salespeople promised
> this wouldn't be a problem, because "all servers would be in the EU".
> Aha :-)
>
> The other was "mail is old, and here we have something *much* better".
Yes they are pushing hard on Teams. My company is using it extensively for
meetings, calendar, communication and even some logging. They require some
people to write daily repports in Teams so that manager can go in and read it.

> This was also the narrative the whole "change management" machinery
> was built around, with "planes", "pilots" and "seats" and whatnot.
>
> (Will stop now, because seriously off-topic)
>
> Cheers
>  - t

Re: Gitlab Migration

[Arthur Miller]

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

> On Fri, Aug 27, 2021, 12:31 Eli Zaretskii <eliz@gnu.org> 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.
>
> I wish this point was stressed more often. Git, to which we've switched reasonably recently after some pain, accommodates many
> many workflows. We should embrace that!!
>
> E.g. if browser living people want to make PRs to an intermediate repo on GitHub, they can today! And then once they're
> reasonably stable and agreed upon, some email wizard (really, can be me, even though I'm not really a wizard) can push them to
> main repo, and even adjust a commit message or two. Git provides lots of commands for that,. I'm happy to explain and document
> them, though I doubt I'm the only such expert here.
>
> The main question is where the discussion happens: it has to be email, period. And right now it's debbugs and emacs-devel. And
> yes I know that GitHub/gitlab do pretty links automatically between web UI parts, but how is that so different from sending email
> where you say you have a public branch with x commits here or there?
>
> My two cents,
> João

There is also an interesting parallel: why doesn't peopel complain to Linus to
move Kernel development to more modern workflow? 

Re: Gitlab Migration

[Lars Ingebrigtsen]

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

> There is also an interesting parallel: why doesn't peopel complain to Linus to
> move Kernel development to more modern workflow? 

They do.

This is getting off-topic.  Emacs will change to a new system when we
can find a system that's good enough, and offers both an email work flow
(for those that prefer that) as well as a non-email work flow (for those
that prefer that).

We haven't found such a system yet.  sr.ht is perhaps an option, but my
first impression is that it's too different from GitHub/Lab, really.

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

Re: Gitlab Migration

[Arthur Miller]

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

>> Perhaps the people that contribute regularly to Emacs could describe
>> their workflow in more detail.  For example, things like how they like
>> to interact with bug reports (if they use the Debbugs Emacs package, for
>> example),
>
> FWIW, here are my main criticisms of debbugs for my own personal use:
>
> - Can't search the database when I'm offline.
>   I really wish the database was stored in Git, so I could easily have
>   a clone of it.  This said, compared to other issue tracking systems,
>   the fact that it works over email makes it at least partly usable
>   offline, which is a big plus.

I think storing it in Git itself would be very nice indeed.

I wonder if it would even be possible to tuck git bases workflow on top of it?

Every bug could be a branch, with each email as a commit to that
branch. If we could git clone it locally, people could push/pull bug repports
instead of sending mails if they prefer? 

> - No notion of "subscription" to a bug, so replies will sometimes fail
>   to reach me.
>
> - The notion of "archived" bugs is a pain in the rear when you send
>   a new message and the message just bounces back with "the bug is
>   archived".
>   Either get rid of it, or automatically unarchive bugs when a new reply
>   is received, or something (e.g. ask for a confirmation message to
>   unarchive the bug and add the already sent message), but the current
>   way this is handled is *really* poor.
>
> - I find it a big difficult to classify bugs.  I'm not sure exactly what
>   I'd like, and maybe some of it can be done via tags and other things
>   already, but I think I'd like it if bugs could be "assigned" to persons
>   and/or to files and/or to "subsystems", and maybe even combine this
>   with ways to describe relationships between those things (so the
>   search tools can known that a given file belongs to a particular
>   subsystem, for example).
>
> The poor web UI is of course another criticism but it mostly doesn't
> affect me.
>
>
>         Stefan

Re: Gitlab Migration

[Stefan Monnier]

> 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 think the issue is not use of email as such, but use of mailing-lists.
In my experience the reluctance to use email is that they feel
uncomfortable sending email to a potentially large number of persons.
In contrast posting on a forum doesn't impose anything on anyone (in
their mind) because those who read it have to actively go and look
for it.
[ Of course, it doesn't make much sense, really, but this is about
  people's perceptions, not about anything rational.  ]


        Stefan

Re: Gitlab Migration

[Arthur Miller]

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

>> 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 think the issue is not use of email as such, but use of mailing-lists.
> In my experience the reluctance to use email is that they feel
> uncomfortable sending email to a potentially large number of persons.
> In contrast posting on a forum doesn't impose anything on anyone (in
> their mind) because those who read it have to actively go and look
> for it.
> [ Of course, it doesn't make much sense, really, but this is about
>   people's perceptions, not about anything rational.  ]
>
>
>         Stefan

Mailing lists are different though indeed. Anyone still using News servers?

I don't know, I agree that people are not used mail archives, I don't use them
myself much either. Should we tack a forum interface on mailing archives? Like
SX? I don't think people use forums much either. Google has removed their option
"search in webforums" they used to have some 10+ years ago (I don't remember
what was the real name).

Someone (I think Dmitry) mentioned that it is easier to look in "issues" list on
GH, I don't think it is different at emacs mail archive interface on the web
at all. It is just that "issues" are integrated in the GH interface. Emacs mail
archive is not integrated anywhere but is a solo web page, which lots of peeps
probably don't know about.

But your mention of debbugs in Git, is not bad in that regard. I don't know how
is developing Savannah web service, but I suppose that mail archives and git
intefaces are on same computers, at least, payed by same account. Maybe FSF/GNU
could consider rewamping the interface to projects and make them more
gitlab/github alike.

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

We used to recommend GitLab as better than GitHub (though only
barely acceptable).  However, GitLab has got worse, and we
should stop recommending it at all.

notabug.org and sr.ht are considerably better, by our ethical
evaluation standards.

If it is a matter of running our own copy of one of these,
we have an issue with any Javascript code.  If it is in fact free,
but doesn't properly state its license and source code, we would
need to fix that.

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

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

  > Shouldn't it be easier to send an email than create an account, navigate
  > some web UI and fill in some form?

Yes it is.  However, it's more than just ease of use at stake.
You also need to have an internet connection at the moment that you
try to use the web forum.  Not so for sending email.

But those are merely practical considerations.  There are also
moral considerations.

To make an account on a web forum, you have to use that platform in
the way it is set up to require.  You have to accept its terms and
conditions, which may be morally unacceptable.

When you send email, you use your own choice of tools and platforms --
the same ones you used to send mail to a different forum the day
before.

This is why the GNU Project continues to specify that a GNU package
should have a published bug-reporting email address.

    > A mailing list does not allow this, so for newcomers the fear of
    > "doing something wrong" is high.  

It is ok to offer a web forum as an alternative interface for sending
a bug report, just as Emacs has M-x report-emacs-bug.  As long as the
forum's software and use conditions are ethical.

Another way to encourage users to report bugs is to focus on our
appreciation for bug reports, and show it whenever users give us a bug
report.  It's a GNU Project policy to state thanks for each bug
report.

                                        Many projects have an issue
    > reporting template now, and that can be nice.

That sounds good.

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

[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 communicate/share information via slack, discord, reddit, instagram
  > etc.

Those are online dis-services -- they treat users unjustly.
Each of them requires users to run nonfree software to talk to it,
even when the user is doing so through a web browser.
Several of them have other unjust practices I know of;
see stallman.org/slack.html, discord.html, instagram.html.

To recommend that people use one of them would contradict our goal of
computing that respects the user's freedom.  Thus, we can't recommend
any of them.  Whatever practical "advantages" it might have, they
could not make up for the moral contradiction it would cause.

From the node References in the GNU Coding Standards:

======================================================================
A web page recommends a program in an implicit but particularly strong
way if it requires users to run that program in order to use the page.
Many pages contain Javascript code which they recommend in this way.
This Javascript code may be free or non-free, but non-free is the usual
case.

If the purpose for which you would refer to the page cannot be carried
out without running non-free Javascript code, then you should not refer
to it.  Thus, if the purpose of referring to the page is for people to
view a video, or subscribing to a mailing list, and the viewing or
subscribing fail to work if the user's browser blocks the non-free
Javascript code, then don't refer to that page.
======================================================================

It's fine if users have the _option_ of communicating with the
maintainers and developers via some interface other than email.  (Or
ten different interfaces other than email.)  But when some of them use
it. that must not compel the maintainers and developers to 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: 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. ]]]

  > You forgot another one: we want the code to be hosted on machines under
  > the control of the GNU project.

Yes, indeed.

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

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

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > They communicate/share information via slack, discord, reddit, instagram
>   > etc.
>
> Those are online dis-services -- they treat users unjustly.
> Each of them requires users to run nonfree software to talk to it,
> even when the user is doing so through a web browser.
> Several of them have other unjust practices I know of;
> see stallman.org/slack.html, discord.html, instagram.html.
>
> To recommend that people use one of them would contradict our goal of
> computing that respects the user's freedom.  Thus, we can't recommend
> any of them.  Whatever practical "advantages" it might have, they
> could not make up for the moral contradiction it would cause.

? I didn't recommend to anyone to use those, nor did I spoke in their favor, I
just generally spoke about what some people prefer and I try to speculate why.

But yes, they are all there to exploit users in the very end, because users are
their product.

Re: Gitlab Migration

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> We used to recommend GitLab as better than GitHub (though only
> barely acceptable).  However, GitLab has got worse, and we
> should stop recommending it at all.
>
> notabug.org and sr.ht are considerably better, by our ethical
> evaluation standards.
>
> If it is a matter of running our own copy of one of these,
> we have an issue with any Javascript code.  If it is in fact free,
> but doesn't properly state its license and source code, we would
> need to fix that.

So unify savannah with debbugs and mail archives in some way that resembles what
people consider is "modern workflow"?

Re: Gitlab Migration

[Werner LEMBERG]

>> The two "external" items (reCAPTCHA and LibreJS) might be hard
>> requirements from RMS, though.
> 
> Well, they are problematic because reCAPTCHA is nonfree, and the
> mandatory javascript programs have no license information that comes
> with them (hence not librejs-compliant).  [...]

Just curious: What about using a gitlab instance (which uses the
GPL-compatible Expat License) on either gnu.org or an existing one
like gitlab.freedesktop.org?  Has this already been considered?  I
couldn't find this in the emacs-devel list archive.


    Werner

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

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 27.08.2021 04:31, Arthur Miller wrote:
>>>> 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.
>>> I don't know enough git to tell you exactly what it is, but perhaps
>>> whatever runs each time I check-in something to my local copy of the
>>> repository that checks for indentation and extraneous whitespace could
>>> also work for this?
>> Couldn't identation and extraneous space be solved by either running after save
>> hook in Emacs, or by running emacs in batch mode as a git hook?
>
> Yes, you're both talking about git hooks. A minor disadvantage is that a hook
> needs to be installed, and then a bug in a hook implementation can stop you from
> being able to make a commit (there are overrides, but those require more
> googling).
Yes, hook is a one way to implement it, but that particular case is solved by
just after file save hook. But we could also develop an emacs package that does
some basics checks and stuff against local repo? Maybe Cask, edev, I don't know? 

I just answer on someone asking for these basics checks.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Daniel Fleischer <danflscr@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 27 Aug 2021 17:07:10 -0400
> 
> - The notion of "archived" bugs is a pain in the rear when you send
>   a new message and the message just bounces back with "the bug is
>   archived".

That is true, but I don't think we ever looked at the alternatives in
this respect.  I consider it a minor (though quite annoying)
misfeature, certainly not something serious enough to change the
platform.  If SourceHut or whatever we decide to use doesn't have this
misfeature, it's bonus points, of course.

> - I find it a big difficult to classify bugs.  I'm not sure exactly what
>   I'd like, and maybe some of it can be done via tags and other things
>   already, but I think I'd like it if bugs could be "assigned" to persons
>   and/or to files and/or to "subsystems", and maybe even combine this
>   with ways to describe relationships between those things (so the
>   search tools can known that a given file belongs to a particular
>   subsystem, for example).

We should first come up with a meaningful classification that would
help in handling the bugs.  Only then we can talk about the
implementation.  I don't have any practical suggestion for
classification ATM, and frankly, as long as we have only a handful of
people doing this, it doesn't sound very important.

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

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: philipk@posteo.net, Daniel Fleischer <danflscr@gmail.com>,
>  emacs-devel@gnu.org
> Date: Fri, 27 Aug 2021 23:17:32 +0200
> 
> > 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.
> 
> This isn't really true though.  There definitely are links to builds and
> inline comments.  Though I agree on parts of this.  One missing thing as
> I see it is the updated patch. You need to find the latest patches, and
> it won't update as in GitHub when you add another "oops" commit.

Can you point to a place where one could see this stuff in action, or
described with screenshots, and make up one's mind regarding what's
there and what isn't?

Re: Gitlab Migration

[Theodor Thornhill]

On 28 August 2021 08:01:42 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: philipk@posteo.net, Daniel Fleischer <danflscr@gmail.com>,
>>  emacs-devel@gnu.org
>> Date: Fri, 27 Aug 2021 23:17:32 +0200
>> 
>> > 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.
>> 
>> This isn't really true though.  There definitely are links to builds and
>> inline comments.  Though I agree on parts of this.  One missing thing as
>> I see it is the updated patch. You need to find the latest patches, and
>> it won't update as in GitHub when you add another "oops" commit.
>
>Can you point to a place where one could see this stuff in action, or
>described with screenshots, and make up one's mind regarding what's
>there and what isn't?

Sure!

https://lists.sr.ht/~technomancy/fennel/patches/24386

It shows inline comments and link to a succeeding autotriggered build. As for all conveniences in is hard to tell, since that list is a little subjective. 

I think we'd need a definitive list of conveniences we need as a minimum, so that we can actually see what's missing. SourceHut now offers the same or equivalent workflow to GitHub, yet often it is differs in spirit. Many things are available through the web, but some are likely not, considering the different products age and funding

Theo

Re: Gitlab Migration

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Sat, 28 Aug 2021 03:39:56 +0200
> Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> 
> I wouldn't agree with you that young people don't know how to use email.

s/don't know/don't like/

Re: Gitlab Migration

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: dgutov@yandex.ru,  philipk@posteo.net,  danflscr@gmail.com,
>   larsi@gnus.org,  emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 03:51:40 +0200
> 
> >> and debbugs package for browsing bugs directly from Emacs?
> >
> > The debbugs package has several non-trivial dependencies, like email,
> > and is probably not the first or the second thing newcomers should be
> > messing with.
> 
> Maybe, but if somoeone is developer who would like to send in patch to Emacs
> than they can probably setup email? Newcomer to Emacs dev, does not mean
> newcomer to computing.

The main purpose of the Emacs debbugs package is not to send patches.
Sending patches when you have email set up is trivial and doesn't need
the debbugs package.

> What about automating it for them?
> 
> Is this too wild: when someone signs FSF copyrights assignement, create
> automatic "development mail account", which will work only to send and recieve
> emails between certain addresses, the person and those used for Emacs
> devs? We could then write a small pacakge to auto-setup persons account in
> his/her Emacs that would work for bug repporting, debbugs, sending patches etc.
> 
> Limitiation because I guess FSF/GNU does not have resources to host free email
> accounts for everyone.

You mean, set up email account on GNU servers?  That's problematic in
more than one sense, some of which you mention above.

And what would be the advantages?

> We could then abstract parts of PR based worklfow on top of email.

For people who are familiar with, and used to, the PR workflow using
Web forms, I don't think this would be an advantage.  The main purpose
of moving to a service we are discussing is to provide a familiar UI
to those contributors, with a special emphasis on occasional
contributors who don't have time, or don't want, to learn a new UI
just to contribute to Emacs.

Re: Gitlab Migration

[tomas]

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

On Fri, Aug 27, 2021 at 10:38:18PM -0400, Stefan Monnier wrote:
> > I wouldn't agree with you that young people don't know how to use
> > email [...]

> I think the issue is not use of email as such, but use of mailing-lists.
> In my experience the reluctance to use email is that they feel
> uncomfortable sending email to a potentially large number of persons.

Sometimes it comes down to trivial technique things.

For better or worse, some MUAs [1] and corporate-influenced
workflows have trained a significant part of the population to
top-quote.

While this might work in the context of personal mail, it fails
miserably in mailing lists, yielding a longer thread practically
unreadable.

On top of that, some MUAs (again, the same) don't know what a
Message-ID is and thread based on Subject. Resulting in monster
threads with the incredibly informative Subject "Re:".

The result is: "mail is broken". No, it's not. It's some MUAs,
and then, the whole rest, which, like lemmings on the cliff,
try to clone that disfunctional behaviour.

But yes, mail is broken.

Cheers

[1] I'm looking at you, Microsoft

 - t

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

Re: Gitlab Migration

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 27 Aug 2021 22:59:21 -0400
> Cc: danflscr@gmail.com, emacs-devel@gnu.org
> 
> When you send email, you use your own choice of tools and platforms --
> the same ones you used to send mail to a different forum the day
> before.
> 
> This is why the GNU Project continues to specify that a GNU package
> should have a published bug-reporting email address.

Not to be a whistle-blower, but if that's a rule, then some GNU
packages deviate from it.  Just two examples:

  $ ld --help
  ...
  Report bugs to <https://www.sourceware.org/bugzilla/>

  $ gdb --help
  ...
  Report bugs to <https://www.gnu.org/software/gdb/bugs/>.

> It's a GNU Project policy to state thanks for each bug report.

We do that, at least most of the time.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 27 Aug 2021 22:59:20 -0400
> Cc: emacs-devel@gnu.org
> 
> notabug.org and sr.ht are considerably better, by our ethical
> evaluation standards.

Would someone please evaluate notabug.org wrt our expectations, and
post a summary?  TIA.

Re: GitLab feature request compared with SourceHut (was: Re: Gitlab Migration)

[Tassilo Horn]

> CLOSELY INTEGRATED BUGTRACKER
>
> Looks a bit manual atm, but a big step up from debbugs because there
> is both e-mail control and clickable buttons.
> ...
>
> BUG REPORTING
>
> Filing bugs and starting mailing list threads are both just a matter of
> sending e-mails, so report-emacs-bug could do it.

One thing I have to note here is that todo.sr.ht simply assumes that
formatting is some kind of email and markdown, i.e., it'll handle

    > bla bla

as quotation but non-4-space or ```...``` wrapped code snippets will be
treated as normal text (become wrapped).  That's ok if you know it but
suprising if you don't.

Also, todo.sr.ht doesn't support attachments AFAIK, i.e., reports
accompanied with attached patches or screenshots illustrating the issue
aren't displayed.  So that's a major bummer which would need to be
worked on for making it suitable for emacs.

Bye,
Tassilo

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 08:26:14 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>  danflscr@gmail.com, emacs-devel@gnu.org
> 
> I think we'd need a definitive list of conveniences we need as a minimum, so that we can actually see what's missing. SourceHut now offers the same or equivalent workflow to GitHub, yet often it is differs in spirit. Many things are available through the web, but some are likely not, considering the different products age and funding

The list of issues we filed with GitLab was mostly about email-based
workflow and other relevant features, because the Web-based workflow
was supported by GitLab already.  It sounds like we now need to
augment that list by the requirements from the Web-based workflow,
since SourceHut and other platforms might lack them.

Would someone like to come with a list of such requirements?

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 08:57:08 +0200
> From: <tomas@tuxteam.de>
> 
> For better or worse, some MUAs [1] and corporate-influenced
> workflows have trained a significant part of the population to
> top-quote.

We encourage people not to top-post, but don't require them not to do
so.  Some of them do, as you can clearly see in the archives.

> While this might work in the context of personal mail, it fails
> miserably in mailing lists, yielding a longer thread practically
> unreadable.

We generally suck it up and survive.  When the fraction of these is
not too high, it is not a problem in practice.

> On top of that, some MUAs (again, the same) don't know what a
> Message-ID is and thread based on Subject. Resulting in monster
> threads with the incredibly informative Subject "Re:".

That's what Rmail does, and I have yet to see a significant problem
with it, let alone that it broke my workflows.

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 04:57:08 +0000 (UTC)
> From: Werner LEMBERG <wl@gnu.org>
> 
> 
> >> The two "external" items (reCAPTCHA and LibreJS) might be hard
> >> requirements from RMS, though.
> > 
> > Well, they are problematic because reCAPTCHA is nonfree, and the
> > mandatory javascript programs have no license information that comes
> > with them (hence not librejs-compliant).  [...]
> 
> Just curious: What about using a gitlab instance (which uses the
> GPL-compatible Expat License) on either gnu.org or an existing one
> like gitlab.freedesktop.org?  Has this already been considered?  I
> couldn't find this in the emacs-devel list archive.

You mean, forking it and developing our own version free of those
problems?  That depends on the resources GNU could use for that: if
there's a need for significant changes, we'd need to maintain that
fork forever.

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

[tomas]

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

On Sat, Aug 28, 2021 at 10:41:35AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Aug 2021 08:57:08 +0200
> > From: <tomas@tuxteam.de>
> > 
> > For better or worse, some MUAs [1] and corporate-influenced
> > workflows have trained a significant part of the population to
> > top-quote.
> 
> We encourage people not to top-post, but don't require them not to do
> so.  Some of them do, as you can clearly see in the archives.

I know, and I know. This is generally the stragegy in other mailing
lists, too. I was just pointing out how subtle factors can change
the general perception of a tool.

If everyone starts hammering nails with the hammer's shaft, after
a while folks will start saying "hammers suck".

[top quoting as an example "things which don't work"]

> We generally suck it up and survive.  When the fraction of these is
> not too high, it is not a problem in practice.

Yes. In mailing lists where it's more pronounced, I sometimes try
to remind people in a friendly way, but there you go.

> > On top of that, some MUAs (again, the same) don't know what a
> > Message-ID is and thread based on Subject. Resulting in monster
> > threads with the incredibly informative Subject "Re:".
> 
> That's what Rmail does, and I have yet to see a significant problem
> with it, let alone that it broke my workflows.

You mean it doesn't honour Message-ID/In-Reply-To/and References
when they are there? (Of course, in their absence it /has/ to fall
back to Subject, mail systems out there are sometimes beyond
broken).

Cheers
 - t

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

Re: Gitlab Migration

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
> Date: Fri, 27 Aug 2021 23:04:55 +0200
> 
> ** Submitting patches by email.
> It is possible to send patches using a web interface.  It works by using
> the `prepare a patchset` button on your own clone.  So the process
> is usually:
>   - clone the repo
>   - pull it locally
>   - do the work
>   - push the work
>   - use the `prepare a patchset` button or `git format-patch`

Does it mean simply sending a patch via email is not supported?  E.g.,
I could easily create a patch without a separate clone of the
repository, using just the single clone I have already.  You seem to
describe something much more complicated, which starts with a separate
clone?

> ** Offline review
> An issue (if not already subscribed to all) can be subscribed to your
> own email and be sent to you.  The whole thing or parts of it can be
> downloaded as an mbox.

Who gets automatically subscribed to an issue?

> ** Reviewing by email
> You can use inline comments [1]

Do I just respond to an email with the patch, or do I have to use some
special format for the inline comments?

> ** Merge request creation
> Honestly I don't really understand this one...

It's about being able to submit a PR via email.

> * Code should be accompanied by documentation
> 
> This seems trivial, and can be done using the CI on patch submission
> running a job, if I understand that point correctly?
> 
> * Formatting code commits
>  Same as above

FWIW, I very much doubt these two could be automated, except for very
simple and almost trivial requirements.  How can a bot decide whether
a change requires documentation changes, and if so, which ones?  Even
our formatting of log messages is informal enough to defeat
automation.  This has to be part of patch review by humans.

> * Bug reporting
> `report-emacs-bug` can still be used, as well as clicking in the web
> ui. This is where I'm not sure about not using email.  I think you still
> need to mail the bug, opened by a mailto:

That's be a disadvantage in my book.

> I hope this helps a little.

It does, thanks a lot!

Re: Gitlab Migration

[Theodor Thornhill]

On 28 August 2021 09:30:32 CEST, Eli Zaretskii <
>The list of issues we filed with GitLab was mostly about email-based
>workflow and other relevant features, because the Web-based workflow
>was supported by GitLab already.  It sounds like we now need to
>augment that list by the requirements from the Web-based workflow,
>since SourceHut and other platforms might lack them.
>
>Would someone like to come with a list of such requirements?


Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 

The mailing of patches seems like the hardest issue to overcome from what I see people complaining about. Prettier UI/UX is also on the list. One can be learned, the other is subjective. I think the most important thing SourceHut solves is catering a little better to the one time contributing workflow than what debbugs does.

I'm really not sure what this list should look like

Theo

Re: Gitlab Migration

[tomas]

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

On Sat, Aug 28, 2021 at 10:44:27AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Aug 2021 04:57:08 +0000 (UTC)
> > From: Werner LEMBERG <wl@gnu.org>

[...]

> > Just curious: What about using a gitlab instance (which uses the
> > GPL-compatible Expat License) on either gnu.org or an existing one
> > like gitlab.freedesktop.org?  Has this already been considered?  I
> > couldn't find this in the emacs-devel list archive.
> 
> You mean, forking it and developing our own version free of those
> problems?  That depends on the resources GNU could use for that: if
> there's a need for significant changes, we'd need to maintain that
> fork forever.

In that case, it seems advisable to understand first why this strategy
didn't work out with debbugs ("our" version seems to languish in a
state that even merging back Debian's improvements over years has
become a difficult task).

Cheers
 - t

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

Re: Gitlab Migration

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Theodor Thornhill <theo@thornhill.no>,  emacs-devel@gnu.org,
>   larsi@gnus.org,  monnier@iro.umontreal.ca,  danflscr@gmail.com,
>   sir@cmpwn.com
> Date: Fri, 27 Aug 2021 20:58:01 +0000
> 
> + Reduce email noise
> 
>   The mailing lists are just mailing lists, from
>   what I know the only "spam" might be CI responding with the results of
>   a test

What about automated notifications regarding a PR being merged or
issues being closed or merged or changed status?  These are a source
of constant useless noise when you subscribe to Github-based project.
Can they be filtered out, or limited to the submitter if he/she is not
an Emacs maintainer?  Or some other useful and flexible enough
filtering?

> > I tried to find answers to those questions myself, but there doesn't
> > seem to be any detailed documentation that describes the setup and
> > usage from the routine user POV (or maybe I missed it?).  I did find a
> > heads-up that "from the beta onwards, unpaid accounts will be limited
> > to read-only access to their own projects", so I wonder what that
> > means for us.  It also says that "web-based workflow for submitting
> > and reviewing patches" is still under development.
> 
> It shouldn't mean anything, if GNU decides to host their own
> instance. Otherwise, every project member would have to play to have an
> account, but I assume mailing list contributors could continue accessing
> the mailing list without any issue.

This answers the first part, but not the second.  It looks like the
Web-based workflows are still not supported well enough.

Thanks.

Re: Gitlab Migration

[Theodor Thornhill]

On 28 August 2021 09:55:18 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
>> Date: Fri, 27 Aug 2021 23:04:55 +0200
>> 
>> ** Submitting patches by email.
>> It is possible to send patches using a web interface.  It works by using
>> the `prepare a patchset` button on your own clone.  So the process
>> is usually:
>>   - clone the repo
>>   - pull it locally
>>   - do the work
>>   - push the work
>>   - use the `prepare a patchset` button or `git format-patch`
>
>Does it mean simply sending a patch via email is not supported?  E.g.,
>I could easily create a patch without a separate clone of the
>repository, using just the single clone I have already.  You seem to
>describe something much more complicated, which starts with a separate
>clone?
>

No need for a clone. Mailing a patch is enough. For the web UI thing though I think you need one.

>> ** Offline review
>> An issue (if not already subscribed to all) can be subscribed to your
>> own email and be sent to you.  The whole thing or parts of it can be
>> downloaded as an mbox.
>
>Who gets automatically subscribed to an issue?
>

Collaborators to the repos. Otherwise everyone that manually subscribe. You can follow specific issues as well.


>> ** Reviewing by email
>> You can use inline comments [1]
>
>Do I just respond to an email with the patch, or do I have to use some
>special format for the inline comments?
>

I don't know, sorry. I've just seen them.

>> ** Merge request creation
>> Honestly I don't really understand this one...
>
>It's about being able to submit a PR via email.
>

You provide PRs via mail just by sending to the correct list.


>> * Code should be accompanied by documentation
>> 
>> This seems trivial, and can be done using the CI on patch submission
>> running a job, if I understand that point correctly?
>> 
>> * Formatting code commits
>>  Same as above
>
>FWIW, I very much doubt these two could be automated, except for very
>simple and almost trivial requirements.  How can a bot decide whether
>a change requires documentation changes, and if so, which ones?  Even
>our formatting of log messages is informal enough to defeat
>automation.  This has to be part of patch review by humans.
>

I won't argue with this.

>> * Bug reporting
>> `report-emacs-bug` can still be used, as well as clicking in the web
>> ui. This is where I'm not sure about not using email.  I think you still
>> need to mail the bug, opened by a mailto:
>
>That's be a disadvantage in my book.
>

Yes it might be.

>> I hope this helps a little.
>
>It does, thanks a lot!

No problem!

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: danflscr@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 27 Aug 2021 16:17:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >
> > Are you asking about contributors or about the core maintainers?
> > E.g., you mention interaction with bug reports, but AFAIK contributors
> > have only one kind of interaction here: when they submit a report.  So
> > I wonder whether I understand your questions.
> 
> The core maintainers: The people that usually check for new bug reports
> and act on them, classify them by priority and see if they block a
> release, review and commit any patches that are sent to fix the bugs,
> etc.

I do almost everything inside Emacs.  Once I've got bug report in
Emacs, as part of reading email, I use the Emacs facilities to work on
it: the code inspection features like M-. and "M-x grep", Lisp
evaluation, Help commands, etc.  I do use the debbugs package, albeit
rarely, mainly when I need to work on large numbers of bugs.

For search, I use the Debbugs Web form (but I rarely need that,
either); I also have email search set up, but that's also rarely
needed.

For code review, it is important for me to be able to do the following
basic tasks efficiently while reviewing the patch:

  . find code in Emacs
  . copy code from Emacs's sources to the review text
  . spell-check what I write and fix typos
  . run Git commands, including forensics and patch application
  . read past discussions of the same or related issues

Does this answer your question?

Re: Gitlab Migration

[Yuchen Pei]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Fri, 27 Aug 2021 22:59:20 -0400
>> Cc: emacs-devel@gnu.org
>> 
>> notabug.org and sr.ht are considerably better, by our ethical
>> evaluation standards.
>
> Would someone please evaluate notabug.org wrt our expectations, 
> and
> post a summary?  TIA.

There was already some evaluation:

https://lists.gnu.org/archive/html/repo-criteria-discuss/2021-03/msg00052.html
https://lists.gnu.org/archive/html/repo-criteria-discuss/2021-06/msg00036.html
https://libreplanet.org/wiki/Notabug

Not sure if it was conclusive though.

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

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 09:53:55 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> > > On top of that, some MUAs (again, the same) don't know what a
> > > Message-ID is and thread based on Subject. Resulting in monster
> > > threads with the incredibly informative Subject "Re:".
> > 
> > That's what Rmail does, and I have yet to see a significant problem
> > with it, let alone that it broke my workflows.
> 
> You mean it doesn't honour Message-ID/In-Reply-To/and References
> when they are there?

It does, but not for threading purposes.  Rmail's equivalent of
threading commands are rmail-next-same-subject and
rmail-previous-same-subject; the names of those commands already tell
you what it does.  It doesn't have any other notion of threads, AFAIK,
and doesn't allow display of messages by threads, except grouping them
by Subject.

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 09:56:45 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>  danflscr@gmail.com, emacs-devel@gnu.org
> 
> >Would someone like to come with a list of such requirements?
> 
> 
> Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 

I think these are basically the various important aspects of the PR
Web-based workflow.

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 09:57:34 +0200
> From: <tomas@tuxteam.de>
> 
> > You mean, forking it and developing our own version free of those
> > problems?  That depends on the resources GNU could use for that: if
> > there's a need for significant changes, we'd need to maintain that
> > fork forever.
> 
> In that case, it seems advisable to understand first why this strategy
> didn't work out with debbugs ("our" version seems to languish in a
> state that even merging back Debian's improvements over years has
> become a difficult task).

Is it really hard to understand?  The usual reason is availability of
resources.

Re: Gitlab Migration

[tomas]

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

On Sat, Aug 28, 2021 at 11:39:35AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Aug 2021 09:53:55 +0200
> > From: tomas@tuxteam.de

[...]

> > You mean [Rmail] doesn't honour Message-ID/In-Reply-To/and References
> > when they are there?
> 
> It does, but not for threading purposes.  Rmail's equivalent of
> threading commands are rmail-next-same-subject and
> rmail-previous-same-subject; [...]  It doesn't have any other
> notion of threads, AFAIK [...]

Thanks for the clarification :)

Cheers
 - t

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

Re: Gitlab Migration

[Eli Zaretskii]

> From: Yuchen Pei <hi@ypei.me>
> Cc: rms@gnu.org, danflscr@gmail.com, emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 18:12:36 +1000
> 
> >> notabug.org and sr.ht are considerably better, by our ethical
> >> evaluation standards.
> >
> > Would someone please evaluate notabug.org wrt our expectations, 
> > and
> > post a summary?  TIA.
> 
> There was already some evaluation:
> 
> https://lists.gnu.org/archive/html/repo-criteria-discuss/2021-03/msg00052.html
> https://lists.gnu.org/archive/html/repo-criteria-discuss/2021-06/msg00036.html
> https://libreplanet.org/wiki/Notabug

Thanks, but that's not what I meant.  I meant the evaluation wrt to
the requirements the Emacs project has to such a platform.  The same
requirements we were discussing regarding GitLab and SourceHut.

Re: Gitlab Migration

[tomas]

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

On Sat, Aug 28, 2021 at 11:42:41AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Aug 2021 09:57:34 +0200
> > From: <tomas@tuxteam.de>
> > 
> > > [...] forking [Gitlab] and developing our own version free of those
> > > problems? [...]

> > In that case, it seems advisable to understand first why this strategy
> > didn't work out with debbugs [...]

> Is it really hard to understand?  The usual reason is availability of
> resources.

Yes, perhaps. But then, Gitlab could be potentially more costly (more
code, faster cycles these days, etc.).

Cheers
 - t

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

Re: Gitlab Migration

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Sat, 28 Aug 2021 17:53:34 +1000
> Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> 
> 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.

And other means of communications aren't?  Are there _any_ means that
are immune to these attacks?

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

Email is almost as real-time as the other means nowadays.

Re: Gitlab Migration

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: dgutov@yandex.ru,  philipk@posteo.net,  danflscr@gmail.com,
>>   larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Sat, 28 Aug 2021 03:51:40 +0200
>> 
>> >> and debbugs package for browsing bugs directly from Emacs?
>> >
>> > The debbugs package has several non-trivial dependencies, like email,
>> > and is probably not the first or the second thing newcomers should be
>> > messing with.
>> 
>> Maybe, but if somoeone is developer who would like to send in patch to Emacs
>> than they can probably setup email? Newcomer to Emacs dev, does not mean
>> newcomer to computing.
>
> The main purpose of the Emacs debbugs package is not to send patches.
> Sending patches when you have email set up is trivial and doesn't need
> the debbugs package.

About debbugs, I meant for exploration of bugs. Someone mentioned that web based
interface offers "issues" lists where people easily can see if their issue is
already repported or not. My argument is that debbugs with Emacs interface
offers as easy such interface. Though search is not as easy since Emacs fetches
data only on request. One can use C-s to search between titles in debbugs
buffer, but it does not seem to possible to search in-depth in articles, at
least I don't know how. I guess I would have to download entire database to the
harddrive. I don't understand why would peopel prefer to search issues in web
browser, if they can do it faster in Emacs. We just need better interface.

>> What about automating it for them?
>> 
>> Is this too wild: when someone signs FSF copyrights assignement, create
>> automatic "development mail account", which will work only to send and recieve
>> emails between certain addresses, the person and those used for Emacs
>> devs? We could then write a small pacakge to auto-setup persons account in
>> his/her Emacs that would work for bug repporting, debbugs, sending patches etc.
>> 
>> Limitiation because I guess FSF/GNU does not have resources to host free email
>> accounts for everyone.
>
> You mean, set up email account on GNU servers?  That's problematic in
> more than one sense, some of which you mention above.
>
> And what would be the advantages?

The advantage would be that we could have a package in Emacs that sets
everythign up for making it easy for newcomers to contribute so they don't need
to bother with setuing up mail to work with emacs. We could also possibly create
more github/gitlab similar workflow in emacs directly if people could
participate in email-based workflow out of the box so to say. It is lots of
"could" I am aware of.

>> We could then abstract parts of PR based worklfow on top of email.
>
> For people who are familiar with, and used to, the PR workflow using
> Web forms, I don't think this would be an advantage.  The main purpose
> of moving to a service we are discussing is to provide a familiar UI
> to those contributors, with a special emphasis on occasional
> contributors who don't have time, or don't want, to learn a new UI
> just to contribute to Emacs.

Yes, but sh does not look familiar to people who are using github or gitlab. The
risk is also, that you may invest a lot of time, just to find that people are
still opposing because they are taken outside their common environment, required
to create account on new service, adapt to different workflow etc.

Unique selling point of Emacs is integration. I mean, I don't need to leave
Emacs to contribute to Emacs at all. I use same shortcuts for everything, same
familiar interface etc. That's Emacs strength.

Some people are not familiar with the concept, but it can be simplified. Maybe
we need to work better on emphasizing Emacs strengths and help people to use
emacs more effectively.

Re: Gitlab Migration

[Theodor Thornhill]

On 28 August 2021 10:41:01 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 28 Aug 2021 09:56:45 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>>  danflscr@gmail.com, emacs-devel@gnu.org
>> 
>> >Would someone like to come with a list of such requirements?
>> 
>> 
>> Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 
>
>I think these are basically the various important aspects of the PR
>Web-based workflow.

If that's the case I'd say it is covered. But it is different. And in my experience people have a hard time with different. But if inching a little closer to what GitHub does it our goal, then I'd say SourceHut covers it. If making it more accessible to webfolks is the goal, we will get more than halfway. Is that enough? No idea.

People can contribute without using email.

Re: Gitlab Migration

[tomas]

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

On Sat, Aug 28, 2021 at 11:52:48AM +0300, Eli Zaretskii wrote:
> > From: Tim Cross <theophilusx@gmail.com>
> > Date: Sat, 28 Aug 2021 17:53:34 +1000
> > Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
> > 
> > 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 [...]

> And other means of communications aren't?  Are there _any_ means that
> are immune to these attacks?

Yes, this made me wonder a bit, too, at how diverse perceptions
can be. A code execution platform executing random scripts off
the internet (aka Web browser) beats mail any day, in my view.

Smartphone operating systems with their app "ecosystems" are
fashioned after the same model.

I'd have to see some statistics to support Tim's "major vector"
assertion above.

Cheers
 - t

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

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 11:00:36 +0200
> From: Theodor Thornhill <theo@thornhill.no>
> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>  danflscr@gmail.com, emacs-devel@gnu.org
> 
> >> Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 
> >
> >I think these are basically the various important aspects of the PR
> >Web-based workflow.
> 
> If that's the case I'd say it is covered.

Dmitry seems to think otherwise, and he gave examples of such
features, to which you agreed.

> But it is different. And in my experience people have a hard time with different. But if inching a little closer to what GitHub does it our goal, then I'd say SourceHut covers it. If making it more accessible to webfolks is the goal, we will get more than halfway. Is that enough? No idea.

We need to established whether it's enough, and if it isn't, either
look for a better alternative, or somehow make sure SourceHut gets
closer.

Re: Gitlab Migration

[Alan Third]

On Sat, Aug 28, 2021 at 08:57:39AM +0300, Eli Zaretskii wrote:
> > - I find it a big difficult to classify bugs.  I'm not sure exactly what
> >   I'd like, and maybe some of it can be done via tags and other things
> >   already, but I think I'd like it if bugs could be "assigned" to persons
> >   and/or to files and/or to "subsystems", and maybe even combine this
> >   with ways to describe relationships between those things (so the
> >   search tools can known that a given file belongs to a particular
> >   subsystem, for example).
> 
> We should first come up with a meaningful classification that would
> help in handling the bugs.  Only then we can talk about the
> implementation.  I don't have any practical suggestion for
> classification ATM, and frankly, as long as we have only a handful of
> people doing this, it doesn't sound very important.

I occasionally use the usertags feature to tag bug reports as for NS,
which is very helpful for finding relevant bugs. Someone else was
doing it before me, and not all NS bugs are tagged. I struggle to
remember how to use the email-based admin for debbugs, so I only ever
tag them when I'm using the emacs debbugs UI, which is much less often
than I use my MUA.

Not relevant to this discussion, but it has just occurred to me that
since I write all my emails in Emacs it should be possible to create
some sort of system for semi-automatically inserting debbugs commands
into the current email body.
-- 
Alan Third

Re: Gitlab Migration

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

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

That can be the case. Mail is not so good group conversations, indeed.

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

What I mean, is that we could maybe masquerade mail worfklow as git worfklow so
those that prefer git workflow can feel somewhat at home. While nobody has speak
of it, or I have missed it, it can happen that sourceHut is not what those
hypotetical developers ask for. It might be that they come up wit other
arguments and refute sourceHut as yet another burden they need to overcome. I
feel that many would prefer platform they are already in, i.e. github or gitlab,
becuase everybody else is there, they work is exposed to the public
(self-promotion), they already contribute to other projects there, etc. Does not
have to be so, but I would leave an option that it might be case too.

>> 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
'Facebook for Business' - my company use that too. I work for a large company
that is established over entire country and worldwide, so they have installed
Workplace (as facebook for business is called) and switched everything to
facebook.

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

[Eli Zaretskii]

> Date: Sat, 28 Aug 2021 10:25:31 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org,
> 	danflscr@gmail.com, mardani29@yahoo.es
> 
> Not relevant to this discussion, but it has just occurred to me that
> since I write all my emails in Emacs it should be possible to create
> some sort of system for semi-automatically inserting debbugs commands
> into the current email body.

A debbugs command is very simple text, so it should be almost trivial
to write a command to add it to a message being composed.  Definitely
so for a single command such as usertags.

Re: Gitlab Migration

[Theodor Thornhill]

On 28 August 2021 11:24:12 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 28 Aug 2021 11:00:36 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: dgutov@yandex.ru, monnier@iro.umontreal.ca, philipk@posteo.net,
>>  danflscr@gmail.com, emacs-devel@gnu.org
>> 
>> >> Yeah, not sure what these requirements are, though, apart from the pr workflow being recognizable across many GitHub derivatives. 
>> >
>> >I think these are basically the various important aspects of the PR
>> >Web-based workflow.
>> 
>> If that's the case I'd say it is covered.
>
>Dmitry seems to think otherwise, and he gave examples of such
>features, to which you agreed.
>

I agreed on some of it yes, and demonstrated where he was wrong. The things I noted as missing it mostly different:
- editing a comment require a new email
- subsequent iterations on a patch isn't squashed in the web UI

The last one may be a bummer, but not sure if it is. In my opinion this shouldn't tester contributions, but who knows. 

>> But it is different. And in my experience people have a hard time with different. But if inching a little closer to what GitHub does it our goal, then I'd say SourceHut covers it. If making it more accessible to webfolks is the goal, we will get more than halfway. Is that enough? No idea.
>
>We need to established whether it's enough, and if it isn't, either
>look for a better alternative, or somehow make sure SourceHut gets
>closer.

Drew is very responsive, and I think getting input on what a real, old Foss projects needs would be important. Can't speak on his behalf though

Re: Gitlab Migration

[Tim Cross]

<tomas@tuxteam.de> writes:

> [[PGP Signed Part:Undecided]]
> On Sat, Aug 28, 2021 at 11:52:48AM +0300, Eli Zaretskii wrote:
>> > From: Tim Cross <theophilusx@gmail.com>
>> > Date: Sat, 28 Aug 2021 17:53:34 +1000
>> > Cc: Daniel Fleischer <danflscr@gmail.com>, emacs-devel@gnu.org
>> > 
>> > 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 [...]
>
>> And other means of communications aren't?  Are there _any_ means that
>> are immune to these attacks?
>
> Yes, this made me wonder a bit, too, at how diverse perceptions
> can be. A code execution platform executing random scripts off
> the internet (aka Web browser) beats mail any day, in my view.
>
> Smartphone operating systems with their app "ecosystems" are
> fashioned after the same model.
>
> I'd have to see some statistics to support Tim's "major vector"
> assertion above.
>

There are lots of reports, analysis and case studies released by a
number of reputable security firms. Just do a basic google and you will
find plenty of evidence and statistics. Talk to any reputable security
firm and ask them what their experiences are. Most countries have some
form of government cyber security body - check any of them and you will
likely find statistics which show the percentage of major security
incidents where email was the initial vector used.

For example, NIST has a whole bunch of documents and frameworks dealing
solely with email security. Quoting from the NIST Cybersecurity
Framework and Email compliance document from August 25 2021
https://www.tessian.com/blog/nist-cybersecurity-framework-and-email-security/ 

"Ransomware is becoming the most severe cybersecurity threat in the
current threat landscape. Because many, if not most, ransomware attacks
start via email, improving your organization’s email security and its
ransomware defense posture go hand-in-hand."

Frameworks like the NIST framework can go a long way to improving the
security of email. However, the big problem is the human factor.
Companies are spending huge amounts on training and education of staff
to make them less vulnerable to social engineering, but this has high
costs and is difficult to maintain. Often, the business response is to
reduce or minimise the exposure by adopting alternative solutions. It
isn't an argument about how good the technology is or how it can be more
efficient than web based alternatives or case studies showing how a team
using email was more efficient than one using product X. This is largely
about risk mitigation, streamlining administration, reducing dependency
on in-house technical skills and avoiding negative PR. Like it or not,
email has got a sour taste for management in many corporations and this
is driving the change. Focusing on the technical aspects is misguided as
it fails to recognise the real drivers behind the shift. 

To be honest, I'm a little surprised this seems to be 'news', but then
again, I spent the last 10 years working in the security space and that
has probably skewed my view on what is 'known' more broadly. Attend
enough conferences, seminars and workshops and you soon forget what you
know is not always general knowledge. 

As to the question of other communication channels also having security
vulnerabilities - yes of course. No system is 100% secure. However, many
of the alternatives being proposed in many companies allow strong or
more effective mitigation strategies. In a large part this is due to
greater control over who can inject information into the system, greater
control over what users can do and more control over keeping core
components up-to-date. There is also the 'obscurity' aspect - Things
like ransomeware are a numbers game - the more people you can target,
the higher chance of success. With email, it is easy because you just
craft an appropriate email with the right payload. With other
communications channels, you have to be more specific and target
vulnerabilities within that specific product to get your payload into
the system and then get it delivered to the user's browser (or app or
whatever). Basically, the ROI isn't as good.

Mobile devices and apps are definitely a significant challenge and
increasingly so as time passes. However, I never stated these other
channels are secure or without problems. It is almost certainly the case
that if a majority of companies moved away from email to other
platforms, those platforms will begin to be targeted more because they
will provide a higher ROI. However, they will also likely require a
higher skill set level than the current situation with email. This too
will change as more 'canned' exploits become available in the market,
but that will take time. Look at the macOS platform. There are still
lots of people who believe that platform is not vulnerable to viruses.
In reality, it is probably just as vulnerable as modern MS Windows, but
the ROI for development of macOS viruses is much lower than for Windows.
It is a numbers game. 

On a side note, I was just talking to my daughter - she is 20. I asked
her about her use of email. She showed me the email 'icon' on her phone.
Her current count of unread email messages is 8400! I asked her how many
of her friends email addresses she knew. She said 1. 

I cannot convince anyone really. All I can do is put forward my view and
experience. After leaving my last permanent position, I spent a few
years consulting, mainly in the Identity and Access management area. I
know from speaking to many executives in medium and large organisations,
email is one of their highest concerns and they are actively moving to
reduce dependency and incorporation of email in core business processes.
I know from talking to my children (one 20, the other 25) that email
doesn't even get considered in their communications and I know from the
last project I worked at in the University that younger students are not
at all interested in email.

Personally, I love email. As a blind programmer, it is much more
accessible than any of the alternatives. I've had an email account since
the 80s. I love the power of email based workflows. However, this makes
no difference. If Emacs wants to encourage contributions from younger
users and wants to appear relevant, we probably need to seriously
consider providing alternatives to a community centred around email.
This doesn't mean we have to replace existing channels, but instead
add/augment them with additional interfaces.

Re: Gitlab Migration

[Drew DeVault]

Hi! This thread is on my radar but I am at an event so I am a bit scarce
on time. I will answer any questions in thorough detail tomorrow or
Monday. In the meantime, a small summary based on what I've acertained
from reading this thread:

First, we would be very pleased to host emacs on our service, or with
our software on your own infrastructure. It should more-or-less work
with everyone's existing workflows, given that emacs is an
email-oriented project, and over time we are developing an improved
web-based experience which should allow more and more users access to
emacs development over time without necessarily requiring the
maintainers or those who prefer their email-oriented workflow to have to
change their workflow to accomodate a platform like GitLab. We should
also rate quite highly in terms of free-as-in-freedom, since the entire
service is free software, mostly AGPL.

Regarding payment, payment is expected of those who *own* resources on
SourceHut, for the hosted version only. If you host it yourself, you can
configure these settings per your needs. So, for instance, the person
who has control over the emacs mailing lists would be expected to have a
paid account. However, contributors, i.e. someone who sends a patch to
that list, are not expected to pay. In fact, you don't need an account
to participate at all, much like GNU Mailman (which I think you're using
now?)

The bug tracker is indeed a bit different, but we are planning
improvements which will make it more email-oriented, by basically making
it a frontend for the mailing lists similarly to how debbugs works.

If you have any other questions, drop them in my inbox and I'll answer
as soon as I'm able. Cheers!

Re: Gitlab Migration

[Daniel Fleischer]

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

Eli Zaretskii [2021-08-28 Sat 10:30]  wrote:

> The list of issues we filed with GitLab was mostly about email-based
> workflow and other relevant features, because the Web-based workflow
> was supported by GitLab already.  It sounds like we now need to
> augment that list by the requirements from the Web-based workflow,
> since SourceHut and other platforms might lack them.
>
> Would someone like to come with a list of such requirements?

Here are some points:

1. Issues page; collection of bug report, feature suggestions and
general discussions, with or without code commits associated with them.
Ability to tag and search, including closed issues. Ability to define
"projects" which are short term goals and associate issues and PR with
them. Ability to assign issues to specific users. Ability to pin issues
at the top for easy discoverability.

1. PR page; since anyone can clone the project locally and make
modifications, PR page is a list of suggested changes, merges between
some branch in contributors' "local" projects and the original (usually
master) branch. Technically it's a patch. Ability to view the diff.
Ability to have discussions around the PR. Ability to continue modifying
the suggested code by all parties and the diff is kept up to date.
Indications of CI tests pass/fail. ADVANCED: ability to do quick code
edits and commits on the web.

1. Code exploration; view code with syntax highlighting for most file
types. Being able to jump to function definitions and usages (at least
in github). Many people explore code in the web before possibly cloning
it locally so it's an important QOL feature.

*Daniel Fleischer*

Re: Gitlab Migration

[Alan Third]

On Sat, Aug 28, 2021 at 10:05:50AM +0200, Theodor Thornhill wrote:
> 
> 
> On 28 August 2021 09:55:18 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Theodor Thornhill <theo@thornhill.no>
> >> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
> >>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
> >> Date: Fri, 27 Aug 2021 23:04:55 +0200
> >> 
> >> ** Submitting patches by email.
> >> It is possible to send patches using a web interface.  It works by using
> >> the `prepare a patchset` button on your own clone.  So the process
> >> is usually:
> >>   - clone the repo
> >>   - pull it locally
> >>   - do the work
> >>   - push the work
> >>   - use the `prepare a patchset` button or `git format-patch`
> >
> >Does it mean simply sending a patch via email is not supported?  E.g.,
> >I could easily create a patch without a separate clone of the
> >repository, using just the single clone I have already.  You seem to
> >describe something much more complicated, which starts with a separate
> >clone?
> >
> 
> No need for a clone. Mailing a patch is enough. For the web UI thing though I think you need one.

Out of interest, we currently work by attaching patches to emails but
I understand the usual "git" way of doing it is by sending the patch
directly AS an email. Is that something we'd have to do differently?

-- 
Alan Third

Re: Gitlab Migration

[Theodor Thornhill]

Alan Third <alan@idiocy.org> writes:

[...]

> Out of interest, we currently work by attaching patches to emails but
> I understand the usual "git" way of doing it is by sending the patch
> directly AS an email. Is that something we'd have to do differently?
>


Good point.  I tried this right now, and it seems like the patch as an
attachment doesn't work as well... You have to manually view the raw
patch by expanding the details section then `download raw message`


You can see what it looks like here:
https://lists.sr.ht/~theo/public-inbox

Two patches are sent here. The newest is with `git send-email <file>`,
the other is as an attachment.  I think this is a shortcoming in
sourcehut, absolutely.  It must be solvable still, though.

--
Theo

Re: Gitlab Migration

[Philip Kaludercic]

Daniel Fleischer <danflscr@gmail.com> writes:

> 1. Code exploration; view code with syntax highlighting for most file
> types. Being able to jump to function definitions and usages (at least
> in github). Many people explore code in the web before possibly cloning
> it locally so it's an important QOL feature.

I think this is supported in principle, one would have to see what is
necessary for this to work with Elisp too.

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Theodor Thornhill]

Philip Kaludercic <philipk@posteo.net> writes:

> Daniel Fleischer <danflscr@gmail.com> writes:
>
>> 1. Code exploration; view code with syntax highlighting for most file
>> types. Being able to jump to function definitions and usages (at least
>> in github). Many people explore code in the web before possibly cloning
>> it locally so it's an important QOL feature.
>
> I think this is supported in principle, one would have to see what is
> necessary for this to work with Elisp too.
>


You can absolutely read the repo, but the newish feature of github where
some languages are backed by lsp is most likely not on the roadmap

--
Theo

Re: Gitlab Migration

[Jean-Christophe Helary]

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

> On Aug 28, 2021, at 20:42, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> Alan Third <alan@idiocy.org> writes:
> 
>> Out of interest, we currently work by attaching patches to emails but
>> I understand the usual "git" way of doing it is by sending the patch
>> directly AS an email. Is that something we'd have to do differently?
> 
> Good point.  I tried this right now, and it seems like the patch as an
> attachment doesn't work as well... You have to manually view the raw
> patch by expanding the details section then `download raw message`

Nice to see another sr-ht user here :-)

https://drewdevault.com/2018/07/02/Email-driven-git.html

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/


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

Re: Gitlab Migration

[Theodor Thornhill]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

>> On Aug 28, 2021, at 20:42, Theodor Thornhill <theo@thornhill.no> wrote:
>> 
>> Alan Third <alan@idiocy.org> writes:
>> 
>>> Out of interest, we currently work by attaching patches to emails but
>>> I understand the usual "git" way of doing it is by sending the patch
>>> directly AS an email. Is that something we'd have to do differently?
>> 
>> Good point.  I tried this right now, and it seems like the patch as an
>> attachment doesn't work as well... You have to manually view the raw
>> patch by expanding the details section then `download raw message`
>
> Nice to see another sr-ht user here :-)
>
likewise :)

> https://drewdevault.com/2018/07/02/Email-driven-git.html
>

Though I agree in general with what that blog post states, it isn't
really pragmatic enough, imo.  If you want to optimize for contributions
you have to allow several workflows.  Sending a patch as an attachment
is, imo a little less daunting than setting up smtp and friends to allow
for a typo correction contribution (which is how many people first start
contributing).  I asked Phil Hagelberg how he handles things in fennel,
which is one of sourcehuts flagships if I'm not mistaken:

https://icosahedron.website/@technomancy/106830388735139937

--
Theo

Re: Gitlab Migration

[Daniel Fleischer]

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

Hi Drew,

If you're here, a quick question about UX; starting from a project's
main page, e.g. <https://sr.ht/~lattis/muon/>, I notice going to either
the "source", "mailing-list" or "tickets" pages takes you to other
subdomains where there's no way to go back using the UI. I think there
should be a way to go back to a project's main page without using
"back". 

Thanks, 

*Daniel Fleischer*

Re: Gitlab Migration

[Drew DeVault]

We do expect git send-email, but as a good practice, and I don't think
it's reasonable to support it as an attachment instead. However, we have
sent many usability improvements to git upstream and I have written an
interactive git send-email tutorial, which is recommended by the git
book and by the Linux kernel documentation:

https://git-send-email.io

Re: Gitlab Migration

[Stefan Monnier]

> I think storing it in Git itself would be very nice indeed.
>
> I wonder if it would even be possible to tuck git bases workflow on top of it?
>
> Every bug could be a branch, with each email as a commit to that
> branch. If we could git clone it locally, people could push/pull bug repports
> instead of sending mails if they prefer? 

Such issue trackers exist.  But they tend to stay at the stage of
proof-of-concept.
Relevant links include
https://tychoish.com/post/supporting-distributed-bug-tracking/ and of
course https://gitlab.com/monnier/bugit.


        Stefan

Re: Gitlab Migration

[Philip Kaludercic]

Theodor Thornhill <theo@thornhill.no> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Daniel Fleischer <danflscr@gmail.com> writes:
>>
>>> 1. Code exploration; view code with syntax highlighting for most file
>>> types. Being able to jump to function definitions and usages (at least
>>> in github). Many people explore code in the web before possibly cloning
>>> it locally so it's an important QOL feature.
>>
>> I think this is supported in principle, one would have to see what is
>> necessary for this to work with Elisp too.
>>
>
>
> You can absolutely read the repo, but the newish feature of github where
> some languages are backed by lsp is most likely not on the roadmap

I had to look it up, what I was referring to was this:

https://drewdevault.com/2019/07/08/Announcing-annotations-for-sourcehut.html

Yet when trying out the examples given at the end of this article, it
seems the feature isn't working/has been removed? 

> --
> Theo

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Drew DeVault]

On Sat Aug 28, 2021 at 2:09 PM CEST, Daniel Fleischer wrote:
> If you're here, a quick question about UX; starting from a project's
> main page, e.g. <https://sr.ht/~lattis/muon/>, I notice going to either
> the "source", "mailing-list" or "tickets" pages takes you to other
> subdomains where there's no way to go back using the UI. I think there
> should be a way to go back to a project's main page without using
> "back".

Aye, there should be a way. This is prioritized for the beta.

These are (most) of the tickets which are prioritized:

https://todo.sr.ht/~sircmpwn/sr.ht?search=status%3Aopen%20label%3A%22beta%22

SourceHut for Emacs (was: Gitlab Migration)

[Stefan Monnier]

Reading this discussion made me realize why I'm rooting for SourceHut:
it's the only such tool I've seen whose goals align exactly with ours.
Both philosophically (most other tools just happen to be Free Software
and but are more philosophically aligned with Open Source) and
technically (it aims for first class email support while providing as
much as possible of the shiny web features of other systems).

So at this stage, I personally don't see much point looking for other
tools.  Instead I'm just wondering how to get us to use SourceHut
(i.e. how to resolve the problems that might stand in the way, such as
getting an instance up and running on GNU machines, starting to use it
"on the side" to see in practice what issues we'll need
fixed/improved/added before we can really switch, etc...).

An obvious first issue is the one seen in Theodor's example:
https://lists.sr.ht/~theo/public-inbox/%3Cm1r1edold3.fsf%40Frende-MacBook.lan%3E
where the rendering of this email in the web interface completely hides
the actual patch being sent.


        Stefan

Re: Gitlab Migration

[Jean-Christophe Helary]

> On Aug 28, 2021, at 21:09, Daniel Fleischer <danflscr@gmail.com> wrote:
> 
> Hi Drew,
> 
> If you're here, a quick question about UX; starting from a project's
> main page, e.g. <https://sr.ht/~lattis/muon/>, I notice going to either
> the "source", "mailing-list" or "tickets" pages takes you to other
> subdomains where there's no way to go back using the UI. I think there
> should be a way to go back to a project's main page without using
> "back". 

There are ways to include links into the page descriptions to move around a given project's parts.
Those things are discussed on the sr.ht general list too.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Gitlab Migration

[Dmitry Gutov]

On 28.08.2021 14:45, Theodor Thornhill wrote:
> Philip Kaludercic<philipk@posteo.net>  writes:
> 
>> Daniel Fleischer<danflscr@gmail.com>  writes:
>>
>>> 1. Code exploration; view code with syntax highlighting for most file
>>> types. Being able to jump to function definitions and usages (at least
>>> in github). Many people explore code in the web before possibly cloning
>>> it locally so it's an important QOL feature.
>> I think this is supported in principle, one would have to see what is
>> necessary for this to work with Elisp too.
>>
> 
> You can absolutely read the repo, but the newish feature of github where
> some languages are backed by lsp is most likely not on the roadmap

It's not like Github ever supported code navigation for Emacs Lisp anyway.

This feature isn't even enabled in 
https://github.com/emacs-mirror/emacs/blob/master/src/callproc.c

Though I support navigation for C code could be made to work in a local 
installation of Gitlab.

Re: Gitlab Migration

[Daniel Martín]

Eli Zaretskii <eliz@gnu.org> writes:

>
> I do almost everything inside Emacs.  Once I've got bug report in
> Emacs, as part of reading email, I use the Emacs facilities to work on
> it: the code inspection features like M-. and "M-x grep", Lisp
> evaluation, Help commands, etc.  I do use the debbugs package, albeit
> rarely, mainly when I need to work on large numbers of bugs.
>
> For search, I use the Debbugs Web form (but I rarely need that,
> either); I also have email search set up, but that's also rarely
> needed.
>
> For code review, it is important for me to be able to do the following
> basic tasks efficiently while reviewing the patch:
>
>   . find code in Emacs
>   . copy code from Emacs's sources to the review text
>   . spell-check what I write and fix typos
>   . run Git commands, including forensics and patch application
>   . read past discussions of the same or related issues
>
> Does this answer your question?

Thanks, yes, that is very informative.

Re: Gitlab Migration

[Dmitry Gutov]

Sorry,

On 28.08.2021 16:49, Dmitry Gutov wrote:
> Though I support navigation for C code could be made to work in a local 
            ^ suppose

Re: GitLab feature request compared with SourceHut

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> Also, todo.sr.ht doesn't support attachments AFAIK, i.e., reports
> accompanied with attached patches or screenshots illustrating the issue
> aren't displayed.  So that's a major bummer which would need to be
> worked on for making it suitable for emacs.

Yes, that sounds like something that needs to work before we can make
the switch.

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> It shouldn't mean anything, if GNU decides to host their own
>> instance. Otherwise, every project member would have to play to have an
>> account, but I assume mailing list contributors could continue accessing
>> the mailing list without any issue.
>
> This answers the first part, but not the second.  It looks like the
> Web-based workflows are still not supported well enough.

That's also my impression.  That is, SourceHut supports our current work
flow very well, but it doesn't really give us the popular Github/Lab
work flow: fork the repo, work on something, push it, and then do a
"pull request" towards the original repo by clicking a button, without
sending any emails to any person?

Because that's really what we want to add as an option.

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

Theodor Thornhill <theo@thornhill.no> writes:

> ** Submitting patches by email.
> It is possible to send patches using a web interface.  It works by using
> the `prepare a patchset` button on your own clone.  So the process
> is usually:
>   - clone the repo
>   - pull it locally
>   - do the work
>   - push the work
>   - use the `prepare a patchset` button or `git format-patch`

Oh, the "prepare a patchset" button sounds very much like Github/Lab's
"pull request" button?  Is that accurate?

> * Code should be accompanied by documentation
> * Formatting code commits

I don't quite understand why we have these in the Gitlab requirements
list -- they seem pretty orthogonal to everything.

> * Closely integrated bugtracker
> automated tasks for patch application and status updates exist here

Is an issue automatically closed if we push a change containing a
magical string like "closes issue #foo" in the commit message?

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

Re: GitLab feature request compared with SourceHut

[Ben Mezger]

> Yes, that sounds like something that needs to work before we can make
> the switch.

One point though: sr.ht payment is currently optional, but they do
have plans to start requiring payments when they reach a certain
quality -- but perhaps this is negoatible given the the nature of the
project.

https://sourcehut.org/pricing/

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>> Also, todo.sr.ht doesn't support attachments AFAIK, i.e., reports
>> accompanied with attached patches or screenshots illustrating the issue
>> aren't displayed.  So that's a major bummer which would need to be
>> worked on for making it suitable for emacs.
>
> Yes, that sounds like something that needs to work before we can make
> the switch.


--
Kind regards,
Met een vriendelijke groet,
Atenciosamente,

Ben Mezger

https://seds.nl
https://github.com/benmezger

Re: Gitlab Migration

[Theodor Thornhill]

On 28 August 2021 17:24:12 CEST, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> ** Submitting patches by email.
>> It is possible to send patches using a web interface.  It works by using
>> the `prepare a patchset` button on your own clone.  So the process
>> is usually:
>>   - clone the repo
>>   - pull it locally
>>   - do the work
>>   - push the work
>>   - use the `prepare a patchset` button or `git format-patch`
>
>Oh, the "prepare a patchset" button sounds very much like Github/Lab's
>"pull request" button?  Is that accurate?
>

100%. That is what it's for. 
If you look at https://lists.sr.ht/~theo/public-inbox you'll see three posts. One is with a patch as attachment(this fails), other is git send-email and the last one is a patch of a personal fork of Emacs sent using the web UI.


>> * Code should be accompanied by documentation
>> * Formatting code commits
>
>I don't quite understand why we have these in the Gitlab requirements
>list -- they seem pretty orthogonal to everything.
>
>> * Closely integrated bugtracker
>> automated tasks for patch application and status updates exist here
>
>Is an issue automatically closed if we push a change containing a
>magical string like "closes issue #foo" in the commit message?
>
Yes

Re: Structured debbugs list per project

[Michael Albinus]

tomas@tuxteam.de writes:

Hi Tomas,

>> > There's no reason to not have a web accessible bug mail archive
>> > indexed by bug number, for the webby folks our there. Perhaps
>> > debbugs could implement that... oh wait [1]!
>> >
>> > SCNR
>> >
>> > [1] https://debbugs.gnu.org/db/pa/lemacs.html
>>
>> Hmm. Something I shall add to debbugs.el as well? Shouldn't be that
>> hard.
>
> Michael, you rock :)

I gave it a first shot, pushed to ELPA. The commentary has been
extended:

--8<---------------cut here---------------start------------->8---
;; If you want all bugs for a given package, sorted by severity and
;; whether already resolved, call
;;
;;   M-x debbugs-gnu-package

;; Per default it shows the bugs for package "emacs", but with a
;; prefix given to the command, different package names can be
;; specified (comma-separated).
--8<---------------cut here---------------end--------------->8---

It is not perfect, and the doc in the manual is still missing, but you
might give it a try. Pull the recent debbugs version from the GNU ELPA
repo, or wait a few hours until it appears as package in the elpa-devel
archive "https://elpa.gnu.org/devel/>.

> Cheers
>  - t

Best regards, Michael.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Theodor Thornhill <theo@thornhill.no> writes:

>>Oh, the "prepare a patchset" button sounds very much like Github/Lab's
>>"pull request" button?  Is that accurate?
>
> 100%. That is what it's for. 
> If you look at https://lists.sr.ht/~theo/public-inbox you'll see three
> posts. One is with a patch as attachment(this fails), other is git
> send-email and the last one is a patch of a personal fork of Emacs
> sent using the web UI.

Cool.  Then SourceHut is a lot closer to satisfying our major
requirements than I initially thought.  

>>Is an issue automatically closed if we push a change containing a
>>magical string like "closes issue #foo" in the commit message?
>>
> Yes

Very nice.

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

Re: GitLab feature request compared with SourceHut

[Lars Ingebrigtsen]

Ben Mezger <me@benmezger.nl> writes:

> One point though: sr.ht payment is currently optional, but they do
> have plans to start requiring payments when they reach a certain
> quality -- but perhaps this is negoatible given the the nature of the
> project.
>
> https://sourcehut.org/pricing/

The GNU project would presumably host a SourceHut instance, and the GNU
project would not require payment for anything.

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

Re: Gitlab Migration

[Drew DeVault]

On Sat Aug 28, 2021 at 5:20 PM CEST, Lars Ingebrigtsen wrote:
> That's also my impression. That is, SourceHut supports our current work
> flow very well, but it doesn't really give us the popular Github/Lab
> work flow: fork the repo, work on something, push it, and then do a
> "pull request" towards the original repo by clicking a button, without
> sending any emails to any person?
>
> Because that's really what we want to add as an option.

Here is a video of the sourcehut equivalent of the github/lab
pull/merge-request flow:

https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83fc-2bacf578de3a

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

[Daniel Martín]

"Drew DeVault" <sir@cmpwn.com> writes:

>
> Here is a video of the sourcehut equivalent of the github/lab
> pull/merge-request flow:
>
> https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83fc-2bacf578de3a

Thanks for the video.  I think the Web workflow is more or less what
people used to GitHub or Gitlab would expect.

For people that don't want to use the Web interface, the usage of git
send-mail may pose some problems.  In CONTRIBUTE there is a note that
says that patch attachments are preferred to git send-mail for some
reasons:

- It delivers patches in the correct and easily-recognizable format, and
  in a more reliable way. (I'm not sure what this means.)

- Makes the job of applying the patches easier and less error-prone.
  (Perhaps this just requires learning a new way to work?).

- Allows sending patches whose author is someone other than the email
  sender. (I think this is already supported: git config --global
  user.email would set the author's email, and git config --global
  sendemail.from, or passing the --from=<address> option to git
  send-mail, would set the sender's email address.)

But even if patch attachments are not supported by sourcehut, I think
support for image attachments is at least required for some issues.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: "Lars Ingebrigtsen" <larsi@gnus.org>,  "Eli Zaretskii" <eliz@gnu.org>,
>   danflscr@gmail.com,  Philip Kaludercic <philipk@posteo.net>,
>   theo@thornhill.no,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sat, 28 Aug 2021 20:08:37 +0200
> 
> - It delivers patches in the correct and easily-recognizable format, and
>   in a more reliable way. (I'm not sure what this means.)

Think MUAs that wrap long lines and otherwise do tricks with
whitespace.

> - Allows sending patches whose author is someone other than the email
>   sender. (I think this is already supported: git config --global
>   user.email would set the author's email, and git config --global
>   sendemail.from, or passing the --from=<address> option to git
>   send-mail, would set the sender's email address.)

That won't help with "git format-patch" whose results are sent.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Daniel Martín <mardani29@yahoo.es> writes:

> For people that don't want to use the Web interface, the usage of git
> send-mail may pose some problems.  In CONTRIBUTE there is a note that
> says that patch attachments are preferred to git send-mail for some
> reasons:

Well, we really don't care as long as the patches reach us unscathed.

In my experience, it's more likely that a patch won't be mangled if it's
in an attachment (which is why CONTRIBUTE says that), but if you have a
setup that allows you to send patches safely otherwise (i.e., you're not
using Gmail :-)), then we don't care.

> But even if patch attachments are not supported by sourcehut, I think
> support for image attachments is at least required for some issues.

Yeah, it has to support attachments.

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

Re: Gitlab Migration

[Drew DeVault]

On Sat Aug 28, 2021 at 8:08 PM CEST, Daniel Martín wrote:
> - It delivers patches in the correct and easily-recognizable format, and
> in a more reliable way. (I'm not sure what this means.)

Reliability is the main reason for suggesting git send-email :) It does
it for you, and does it correctly.

> - Makes the job of applying the patches easier and less error-prone.
> (Perhaps this just requires learning a new way to work?).

Depends, I suppose.

> - Allows sending patches whose author is someone other than the email
> sender. (I think this is already supported: git config --global
> user.email would set the author's email, and git config --global
> sendemail.from, or passing the --from=<address> option to git
> send-mail, would set the sender's email address.)

This just werks by default with git send-email, it automatically adds
the author.

> But even if patch attachments are not supported by sourcehut, I think
> support for image attachments is at least required for some issues.

Yeah, we can expand the attachments support for sure.

Generally I understand the desire for some projects to have patch
attachments as their workflow, but I find that every user who is
instructed on git send-email (perhaps by [0]) finds it much better.

[0] https://git-send-email.io

Re: GitLab feature request compared with SourceHut

[Tassilo Horn]

Ben Mezger <me@benmezger.nl> writes:

>> Yes, that sounds like something that needs to work before we can make
>> the switch.
>
> One point though: sr.ht payment is currently optional, but they do
> have plans to start requiring payments when they reach a certain
> quality

I think you already must be a paying user to use the CI service as a
result of abuse of the infrastructure for cryptocurrency mining.

> -- but perhaps this is negoatible given the the nature of the project.

As Lars already said, that's irrelevant for us because we'd host
sourcehut the software on GNU infrastructure anyway.

However, I want to point out that I'm very happily paying those 20 bucks
a year to help making sr.ht a sustainable service.  It's so much better
to pay with your money rather than your data.

Bye,
Tassilo

Re: GitLab feature request compared with SourceHut

[Ben Mezger]

> As Lars already said, that's irrelevant for us because we'd host
> sourcehut the software on GNU infrastructure anyway.

I was not aware about the possibility of hosting sourcehut at all -- but
this does seem like a plausible solution indeed.

> However, I want to point out that I'm very happily paying those 20 bucks
> a year to help making sr.ht a sustainable service.  It's so much better
> to pay with your money rather than your data.

Definitely, folks at sourcehut have been doing a great job at tacking
this sort of issue -- in fact, afaik, they are the only ones actually
trying to solve this mailing list problem. I am unaware of any other
solution that tackles code contribution the way they do it.

Maybe if Emacs makes the first move, perhaps other projects may follow
the same path.

Tassilo Horn <tsdh@gnu.org> writes:

> Ben Mezger <me@benmezger.nl> writes:
>
>>> Yes, that sounds like something that needs to work before we can make
>>> the switch.
>>
>> One point though: sr.ht payment is currently optional, but they do
>> have plans to start requiring payments when they reach a certain
>> quality
>
> I think you already must be a paying user to use the CI service as a
> result of abuse of the infrastructure for cryptocurrency mining.
>
>> -- but perhaps this is negoatible given the the nature of the project.
>
> As Lars already said, that's irrelevant for us because we'd host
> sourcehut the software on GNU infrastructure anyway.
>
> However, I want to point out that I'm very happily paying those 20 bucks
> a year to help making sr.ht a sustainable service.  It's so much better
> to pay with your money rather than your data.
>
> Bye,
> Tassilo


--
Kind regards,
Met een vriendelijke groet,
Atenciosamente,

Ben Mezger

https://seds.nl
https://github.com/benmezger

Re: Gitlab Migration

[Basil L. Contovounesios]

Alan Third [2021-08-28 10:25 +0100] wrote:

> I occasionally use the usertags feature to tag bug reports as for NS,
> which is very helpful for finding relevant bugs. Someone else was
> doing it before me, and not all NS bugs are tagged. I struggle to
> remember how to use the email-based admin for debbugs, so I only ever
> tag them when I'm using the emacs debbugs UI, which is much less often
> than I use my MUA.
>
> Not relevant to this discussion, but it has just occurred to me that
> since I write all my emails in Emacs it should be possible to create
> some sort of system for semi-automatically inserting debbugs commands
> into the current email body.

You mean like 'M-x debbugs-gnu-make-control-message', or something more
powerful than that?

-- 
Basil

Re: Gitlab Migration

[Alan Third]

On Sat, Aug 28, 2021 at 10:42:10PM +0100, Basil L. Contovounesios wrote:
> Alan Third [2021-08-28 10:25 +0100] wrote:
> 
> > I occasionally use the usertags feature to tag bug reports as for NS,
> > which is very helpful for finding relevant bugs. Someone else was
> > doing it before me, and not all NS bugs are tagged. I struggle to
> > remember how to use the email-based admin for debbugs, so I only ever
> > tag them when I'm using the emacs debbugs UI, which is much less often
> > than I use my MUA.
> >
> > Not relevant to this discussion, but it has just occurred to me that
> > since I write all my emails in Emacs it should be possible to create
> > some sort of system for semi-automatically inserting debbugs commands
> > into the current email body.
> 
> You mean like 'M-x debbugs-gnu-make-control-message', or something more
> powerful than that?

I only just learnt you can use that in an existing email, but I use
post-mode with mutt, so I don't think it will work for me. At the very
least it'll put me in message mode, which isn't really what I want.
-- 
Alan Third

Re: GitLab feature request compared with SourceHut

[Jean-Christophe Helary]

> On Aug 29, 2021, at 5:15, Ben Mezger <me@benmezger.nl> wrote:
> 
> 
>> As Lars already said, that's irrelevant for us because we'd host
>> sourcehut the software on GNU infrastructure anyway.
> 
> I was not aware about the possibility of hosting sourcehut at all -- but
> this does seem like a plausible solution indeed.

sourcehut is free software.

https://man.sr.ht/installation.md

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

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

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Yes, you're both talking about git hooks. A minor disadvantage is that
> a hook needs to be installed, and then a bug in a hook implementation
> can stop you from being able to make a commit (there are overrides,
> but those require more googling).

It is certainly a very minor disadvantage, as it's always been accurate
for me.

> CI is good because if its visibility: the list of checks on current
> PRs is visible to every newcomer, instead of being buried somewhere
> near the end of the CONTRIBUTE document.

But shouldn't contributors be expected to read CONTRIBUTE anyhow?  If
someone does not read the CONTRIBUTE file, he will not know to add
entries to NEWS, to write correctly formatted commit messages, and so
on.  A list of checks done on formatting does not seem as important as
some of the other topics covered "somewhere near the end of the
CONTRIBUTE document."

Re: Gitlab Migration

[Dmitry Gutov]

On 28.08.2021 19:04, Drew DeVault wrote:
> On Sat Aug 28, 2021 at 5:20 PM CEST, Lars Ingebrigtsen wrote:
>> That's also my impression. That is, SourceHut supports our current work
>> flow very well, but it doesn't really give us the popular Github/Lab
>> work flow: fork the repo, work on something, push it, and then do a
>> "pull request" towards the original repo by clicking a button, without
>> sending any emails to any person?
>>
>> Because that's really what we want to add as an option.
> Here is a video of the sourcehut equivalent of the github/lab
> pull/merge-request flow:
> 
> https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83fc-2bacf578de3a

Thanks for the video. AFAICT it shows a workflow that follows what the 
Linux kernel and associated projects do, so it's clearly workable.

But compared to "the Git**b workflow", here are a few 
frictions/downsides that came to mind:

- You need to input a correct email to send a patchset to. First, it's a 
step where the contributor would have to stop and look stuff up (which 
email indeed to use?), and then they might end up sending the whole 
thing to one of the contributors directly. Whereas, with rare 
exceptions, we probably want to have a section on our "sourcehut project 
page" which lists all current and past submissions.

This seems not too hard to fix, at least conceptually.

- Every version of a patchset is re-submitted as a whole. I suppose 
there is some purity in that, but if for example the original submission 
is big, and I only asked the author to change a few relatively minor 
things, I prefer they do that in a separate commit. Then, in a git**b 
workflow, I see that the branch was updated with that one commit, and I 
don't have to scan the other commit(s) for any unrelated/breaking 
changes. This kind of back-and-forth can go for several rounds (minor 
change here, minor change there). If the user has to rebase and resend 
their whole branch every time, and if the branch has multiple commits, 
that's a lot of extra traffic. Of course, some users want to rebase 
anyway (and I rarely bother asking them to stop), so it only really 
applies to some submissions. But I'd generally prefer to see some fixup 
commits (during the review rounds), and then a rebase at the end of the 
review. Or just merge the whole branch, with fixes and all (this too can 
make sense, depending on the nature of the requested changes). This 
seems to require less work from everybody involved.

- Rebasing. Some of our valued contributors are not 100% comfortable 
with the more advanced features of Git, rebasing included. Our general 
recommendation until now has been to prefer merge commits. If the 
general workflow is going to require people to 'git rebase -i' on a 
regular basis, it could be a problem.

Bonus questions:

- Can we have discussion subthreads "attached" to particular pieces of 
the submitted patches? Like, a line, or a hunk. Being able to view those 
in a compact fashion, right in the middle of the context, is pretty handy.

- Can I jump in in the middle of a patch discussion with a question or 
an advice and have all subsequent messages in that discussion sent to me 
too, if I'm not subscribed to the target mailing list? Does that depend 
on all participants putting me in Cc?

- Can I do that "jumping in" from the web interface?

- Can I "unsubscribe" from replies to a topic/thread/patchset I'm not 
longer interested in?

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

  > We haven't found such a system yet.  sr.ht is perhaps an option, but my
  > first impression is that it's too different from GitHub/Lab, really.

Why should such a difference disqualify it?  We have no commitment to
GitHub/Lab; on the contrary, we disapprove of them.

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

[Richard Stallman]

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

  > The main question is where the discussion happens: it has to be email,
  > period.

It has to be email, because email can be read and written off-line.

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

[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

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

  > > To recommend that people use one of them would contradict our goal of
  > > computing that respects the user's freedom.  Thus, we can't recommend
  > > any of them.  Whatever practical "advantages" it might have, they
  > > could not make up for the moral contradiction it would cause.

  > ? I didn't recommend to anyone to use those, nor did I spoke in their favor, I
  > just generally spoke about what some people prefer and I try to speculate why.

I am glad to know you're not arguing for them, and that I
misunderstood before.

That misunderstanding was not just random.  In a discussion about what
methods we should adopt, to say that a large group of people (whom we
would like to recruit) are accustomed to methods A, B and C is not a
big step away from advocating their use.

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

[Richard Stallman]

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

  > > This is why the GNU Project continues to specify that a GNU package
  > > should have a published bug-reporting email address.

  > Not to be a whistle-blower, but if that's a rule, then some GNU
  > packages deviate from it.

Its unfortunate.  I wonder if I would be able to report a bug
in those ways.

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

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

  > On top of that, some MUAs (again, the same) don't know what a
  > Message-ID is and thread based on Subject. Resulting in monster
  > threads with the incredibly informative Subject "Re:".

Would someone like to implement Message-ID threading in Rmail?
I would definitely appreciate it.

-- 
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 feature request compared with SourceHut

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

  > Definitely, folks at sourcehut have been doing a great job at tacking
  > this sort of issue -- in fact, afaik, they are the only ones actually
  > trying to solve this mailing list problem. I am unaware of any other
  > solution that tackles code contribution the way they do it.

  > Maybe if Emacs makes the first move, perhaps other projects may follow
  > the same path.

Sorry -- what is "first move" that is being proposed?

We want to host Emacs on a GNU server, not someone else's.

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

RE: [External] : Re: Gitlab Migration

[Drew Adams]

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

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

"Comments like these" is facile dismissal.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Anyway, this is fairly off-topic now.

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

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

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

Re: Gitlab Migration

[Drew DeVault]

On Sun Aug 29, 2021 at 3:56 AM CEST, Dmitry Gutov wrote:
> - You need to input a correct email to send a patchset to.
> This seems not too hard to fix, at least conceptually.

Aye. A future enhancement will pre-fill this with the appropriate email
address for the project's mailing list.

> - Every version of a patchset is re-submitted as a whole. I suppose
> there is some purity in that, but if for example the original submission
> is big, and I only asked the author to change a few relatively minor
> things, I prefer they do that in a separate commit. Then, in a git**b
> workflow, I see that the branch was updated with that one commit, and I
> don't have to scan the other commit(s) for any unrelated/breaking
> changes.

This is a bad practice for git, because it makes the history worse. This
has consequences, for example, with tools like git bisect. Instead, git
range-diff is helpful for comparing the previous and new version of a
patch, and future improvements to the web UI will incorporate it to
allow you to easily diff between patchset revisions. The idea is
something similar to Gerrit's approach, you may be familiar with that.

> - Rebasing. Some of our valued contributors are not 100% comfortable
> with the more advanced features of Git, rebasing included. Our general
> recommendation until now has been to prefer merge commits. If the
> general workflow is going to require people to 'git rebase -i' on a
> regular basis, it could be a problem.

We wrote another tutorial about git rebase which has been very helpful:

https://git-rebase.io

In general we are a hard "no" on shying away from powerful tools because
they are intimidating to new users. We prefer to cultivate a culture of
mentorship instead.

> - Can we have discussion subthreads "attached" to particular pieces of
> the submitted patches? Like, a line, or a hunk. Being able to view those
> in a compact fashion, right in the middle of the context, is pretty
> handy.

Yes, though it's based on heuristics and we're still working on it.
Here's a simple example:

https://lists.sr.ht/~mpu/qbe/patches/24383

> - Can I jump in in the middle of a patch discussion with a question or
> an advice and have all subsequent messages in that discussion sent to me
> too, if I'm not subscribed to the target mailing list? Does that depend
> on all participants putting me in Cc?

It depends on all of the participants Cc'ing you. It is common practice
to "reply all" on mailing lists for this reason.

> - Can I do that "jumping in" from the web interface?

No, but this is a prioritized issue.

> - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not
> longer interested in?

In a sense. Because you don't have to subscribe to the mailing list to
participate in a thread, you won't get emails unless the sender has Cc'd
you. But you cannot stop them from Cc'ing you, and neither can we,
unless you ask nicely - which is not a software solution. Such emails
are not relayed by our mail servers, so it's out of our control.

Subscribing to individual threads is also prioritized.

Re: GitLab feature request compared with SourceHut

[Drew DeVault]

On Sun Aug 29, 2021 at 5:03 AM CEST, Richard Stallman wrote:
> > Maybe if Emacs makes the first move, perhaps other projects may follow
> > the same path.
>
> Sorry -- what is "first move" that is being proposed?
>
> We want to host Emacs on a GNU server, not someone else's.

You can run the sourcehut software on GNU servers, it is 100% free
software, mostly AGPL. I would encourage you to do so.

However, I think that this is a rare case where you could also use our
servers if you so desired. The software on our servers is not patched,
it's the same free software you would run on yours. If you did some
reading on sourcehut, I think you would find our philosophy quite
compatible with GNU's ideals. It would be nice to have the emacs vote of
confidence in our services, in the strategic sense of mutual support
between organizations which believe in free software.

SourceHut is a straight upgrade from the existing mailing lists, and
supports the existing workflow almost 1:1, perhaps pending some minor
enhancements around attachments. The web tools to accomodate the
pull-request generation are at a prototype stage, but will be improved.
The free software ethic is here to stay.

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sun, 29 Aug 2021 08:55:41 +0200
> Cc: <danflscr@gmail.com>, "Philip Kaludercic" <philipk@posteo.net>,
>  <theo@thornhill.no>, <monnier@iro.umontreal.ca>, <emacs-devel@gnu.org>
> From: "Drew DeVault" <sir@cmpwn.com>
> 
> > - Rebasing. Some of our valued contributors are not 100% comfortable
> > with the more advanced features of Git, rebasing included. Our general
> > recommendation until now has been to prefer merge commits. If the
> > general workflow is going to require people to 'git rebase -i' on a
> > regular basis, it could be a problem.
> 
> We wrote another tutorial about git rebase which has been very helpful:
> 
> https://git-rebase.io
> 
> In general we are a hard "no" on shying away from powerful tools because
> they are intimidating to new users. We prefer to cultivate a culture of
> mentorship instead.

Rebasing is not just intimidating, it has real problems as well.  One
problem that particularly bothers us is that it could, in some
circumstances, cause the same commit to be present more than once.

I find a hard requirement to use rebase to be user-unfriendly, because
some of us simply don't want to rebase, for reasons of preserving the
original history of the development.  Is rebasing really a requirement
in SourceHut?

> > - Can I jump in in the middle of a patch discussion with a question or
> > an advice and have all subsequent messages in that discussion sent to me
> > too, if I'm not subscribed to the target mailing list? Does that depend
> > on all participants putting me in Cc?
> 
> It depends on all of the participants Cc'ing you. It is common practice
> to "reply all" on mailing lists for this reason.

Too many people forget to "Reply All", we have this all the time on
our current bug tracker.  Is there a way to arrange for automatic
subscription to a discussion once you post to that discussion?

> > - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not
> > longer interested in?
> 
> In a sense. Because you don't have to subscribe to the mailing list to
> participate in a thread, you won't get emails unless the sender has Cc'd
> you. But you cannot stop them from Cc'ing you, and neither can we,
> unless you ask nicely - which is not a software solution. Such emails
> are not relayed by our mail servers, so it's out of our control.
> 
> Subscribing to individual threads is also prioritized.

Does this mean that currently starting a discussion doesn't
automatically subscribe me to that discussion?

Thanks.

Re: Gitlab Migration

[Drew DeVault]

On Sun Aug 29, 2021 at 9:38 AM CEST, Eli Zaretskii wrote:
> Rebasing is not just intimidating, it has real problems as well. One
> problem that particularly bothers us is that it could, in some
> circumstances, cause the same commit to be present more than once.
>
> I find a hard requirement to use rebase to be user-unfriendly, because
> some of us simply don't want to rebase, for reasons of preserving the
> original history of the development. Is rebasing really a requirement
> in SourceHut?

No, it's not a requirement. It's just something I think is a good idea.

How do you end up with the same commit twice?

> > It depends on all of the participants Cc'ing you. It is common practice
> > to "reply all" on mailing lists for this reason.
>
> Too many people forget to "Reply All", we have this all the time on
> our current bug tracker. Is there a way to arrange for automatic
> subscription to a discussion once you post to that discussion?

This is probably something which can be done. Can you file a ticket?
Send an email to ~sircmpwn/lists.sr.ht@todo.sr.ht with the title in the
subject line and the body as markdown.

> > In a sense. Because you don't have to subscribe to the mailing list to
> > participate in a thread, you won't get emails unless the sender has Cc'd
> > you. But you cannot stop them from Cc'ing you, and neither can we,
> > unless you ask nicely - which is not a software solution. Such emails
> > are not relayed by our mail servers, so it's out of our control.
> > 
> > Subscribing to individual threads is also prioritized.
>
> Does this mean that currently starting a discussion doesn't
> automatically subscribe me to that discussion?

Yep. See previous answer.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> - Rebasing. Some of our valued contributors are not 100% comfortable
>   with the more advanced features of Git, rebasing included. Our
>   general recommendation until now has been to prefer merge
>   commits.

Well, one of the co-maintainers is sceptical towards rebasing, and the
other one uses it exclusively, so I don't think we currently have any
recommendation on the matter.

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

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sun, 29 Aug 2021 09:42:14 +0200
> From: "Drew DeVault" <sir@cmpwn.com>
> Cc: <dgutov@yandex.ru>, <larsi@gnus.org>, <danflscr@gmail.com>,
>  <philipk@posteo.net>, <theo@thornhill.no>, <monnier@iro.umontreal.ca>,
>  <emacs-devel@gnu.org>
> 
> On Sun Aug 29, 2021 at 9:38 AM CEST, Eli Zaretskii wrote:
> > Rebasing is not just intimidating, it has real problems as well. One
> > problem that particularly bothers us is that it could, in some
> > circumstances, cause the same commit to be present more than once.
> >
> > I find a hard requirement to use rebase to be user-unfriendly, because
> > some of us simply don't want to rebase, for reasons of preserving the
> > original history of the development. Is rebasing really a requirement
> > in SourceHut?
> 
> No, it's not a requirement. It's just something I think is a good idea.

OK, thanks.  Then I don't think we have a problem here.

> How do you end up with the same commit twice?

I no longer remember the exact details, it was something we bumped
into during discussions when Emacs switched to Git.  AFAIR, it had to
do with working on a feature branch and frequently rebasing it onto
the latest master (so that the feature branch doesn't diverge too
much), then later merging from the feature branch to master.

> > > It depends on all of the participants Cc'ing you. It is common practice
> > > to "reply all" on mailing lists for this reason.
> >
> > Too many people forget to "Reply All", we have this all the time on
> > our current bug tracker. Is there a way to arrange for automatic
> > subscription to a discussion once you post to that discussion?
> 
> This is probably something which can be done. Can you file a ticket?
> Send an email to ~sircmpwn/lists.sr.ht@todo.sr.ht with the title in the
> subject line and the body as markdown.

Will do.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 29 Aug 2021 09:42:18 +0200
> Cc: Philip Kaludercic <philipk@posteo.net>, danflscr@gmail.com,
>  theo@thornhill.no, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  Eli Zaretskii <eliz@gnu.org>, Drew DeVault <sir@cmpwn.com>
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > - Rebasing. Some of our valued contributors are not 100% comfortable
> >   with the more advanced features of Git, rebasing included. Our
> >   general recommendation until now has been to prefer merge
> >   commits.
> 
> Well, one of the co-maintainers is sceptical towards rebasing, and the
> other one uses it exclusively, so I don't think we currently have any
> recommendation on the matter.

Indeed, we leave this to the individual committers.

Re: Gitlab Migration

[Drew DeVault]

On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
> I no longer remember the exact details, it was something we bumped
> into during discussions when Emacs switched to Git. AFAIR, it had to
> do with working on a feature branch and frequently rebasing it onto
> the latest master (so that the feature branch doesn't diverge too
> much), then later merging from the feature branch to master.

Hm, weird. I would like to see some reproducible evidence of this so
that a deeper investigation can be done. I've used rebase thoroughly for
many years on hundreds of projects without any such incident.

> > This is probably something which can be done. Can you file a ticket?
> > Send an email to ~sircmpwn/lists.sr.ht@todo.sr.ht with the title in the
> > subject line and the body as markdown.
>
> Will do.

Thanks!

Re: Gitlab Migration

[Theodor Thornhill]

On 29 August 2021 10:23:17 CEST, Drew DeVault <sir@cmpwn.com> wrote:
>On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
>> I no longer remember the exact details, it was something we bumped
>> into during discussions when Emacs switched to Git. AFAIR, it had to
>> do with working on a feature branch and frequently rebasing it onto
>> the latest master (so that the feature branch doesn't diverge too
>> much), then later merging from the feature branch to master.
>
>Hm, weird. I would like to see some reproducible evidence of this so
>that a deeper investigation can be done. I've used rebase thoroughly for
>many years on hundreds of projects without any such incident.
>

I know one way to do this, after having to untangle a coworkers mess a couple of years ago:

1. Create your branch
2. Make some commits
3. Push them because work day over
4. Next day realize you should change something
5. Edit history
6. Get message from git that remote is diverged, pull to fix
7. Get a million conflicts with old commits
8. Resolve conflicts
9. Force push
10. Since this took all day leave work
11. Go back to 4

You won't believe how crazy this case become. I've seen same commit at least 6 times in the same pr.

Re: Gitlab Migration

[Drew DeVault]

On Sun Aug 29, 2021 at 10:30 AM CEST, Theodor Thornhill wrote:
> I know one way to do this, after having to untangle a coworkers mess a
> couple of years ago:
>
> 1. Create your branch
> 2. Make some commits
> 3. Push them because work day over
> 4. Next day realize you should change something
> 5. Edit history
> 6. Get message from git that remote is diverged, pull to fix
> 7. Get a million conflicts with old commits
> 8. Resolve conflicts
> 9. Force push
> 10. Since this took all day leave work
> 11. Go back to 4
>
> You won't believe how crazy this case become. I've seen same commit at
> least 6 times in the same pr.

Are you sure you're rebasing in this scenario and not making merge
commits? If you can come up with a series of git commands which
reproduces this scenario, I would like to investigate further. Let's
follow up off-list.

Re: Gitlab Migration

[David Engster]

>> How do you end up with the same commit twice?
>
> I no longer remember the exact details, it was something we bumped
> into during discussions when Emacs switched to Git.  AFAIR, it had to
> do with working on a feature branch and frequently rebasing it onto
> the latest master (so that the feature branch doesn't diverge too
> much), then later merging from the feature branch to master.

Frequently rebasing onto latest master is fine. What happened was that
people first did a 'merge-based workflow' by merging master into their
feature branch, but then later *also* decided to rebase. You mustn't mix
these two different workflow: you either regularly merge 'master' into
your feature branch, or you regularly rebase. Never do both.

-David

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sun, 29 Aug 2021 11:21:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org
> 
> > > > It depends on all of the participants Cc'ing you. It is common practice
> > > > to "reply all" on mailing lists for this reason.
> > >
> > > Too many people forget to "Reply All", we have this all the time on
> > > our current bug tracker. Is there a way to arrange for automatic
> > > subscription to a discussion once you post to that discussion?
> > 
> > This is probably something which can be done. Can you file a ticket?
> > Send an email to ~sircmpwn/lists.sr.ht@todo.sr.ht with the title in the
> > subject line and the body as markdown.
> 
> Will do.

Done.

Re: Gitlab Migration

[Theodor Thornhill]

On 29 August 2021 10:33:01 CEST, Drew DeVault <sir@cmpwn.com> wrote:
>On Sun Aug 29, 2021 at 10:30 AM CEST, Theodor Thornhill wrote:
>> I know one way to do this, after having to untangle a coworkers mess a
>> couple of years ago:
>>
>> 1. Create your branch
>> 2. Make some commits
>> 3. Push them because work day over
>> 4. Next day realize you should change something
>> 5. Edit history
>> 6. Get message from git that remote is diverged, pull to fix
>> 7. Get a million conflicts with old commits
>> 8. Resolve conflicts
>> 9. Force push
>> 10. Since this took all day leave work
>> 11. Go back to 4
>>
>> You won't believe how crazy this case become. I've seen same commit at
>> least 6 times in the same pr.
>
>Are you sure you're rebasing in this scenario and not making merge
>commits? If you can come up with a series of git commands which
>reproduces this scenario, I would like to investigate further. Let's
>follow up off-list.

Sure. I'll try to make a repro later today if time permits and notify you with the results.

Re: Gitlab Migration

[Eli Zaretskii]

> Date: Sun, 29 Aug 2021 10:23:17 +0200
> Cc: <dgutov@yandex.ru>, <larsi@gnus.org>, <danflscr@gmail.com>,
>  <philipk@posteo.net>, <theo@thornhill.no>, <monnier@iro.umontreal.ca>,
>  <emacs-devel@gnu.org>
> From: "Drew DeVault" <sir@cmpwn.com>
> 
> On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
> > I no longer remember the exact details, it was something we bumped
> > into during discussions when Emacs switched to Git. AFAIR, it had to
> > do with working on a feature branch and frequently rebasing it onto
> > the latest master (so that the feature branch doesn't diverge too
> > much), then later merging from the feature branch to master.
> 
> Hm, weird. I would like to see some reproducible evidence of this so
> that a deeper investigation can be done. I've used rebase thoroughly for
> many years on hundreds of projects without any such incident.

It is buried in this long discussion:

  https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01436.html

AFAIR, it had to do with "pull --rebase" as well, and the fact that
when doing the rebases in this case, Git "invents" anonymous
branches.  Or something.

Re: Gitlab Migration

[João Távora]

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

On Sun, Aug 29, 2021, 09:23 Drew DeVault <sir@cmpwn.com> wrote:

> On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
> > I no longer remember the exact details, it was something we bumped
> > into during discussions when Emacs switched to Git. AFAIR, it had to
> > do with working on a feature branch and frequently rebasing it onto
> > the latest master (so that the feature branch doesn't diverge too
> > much), then later merging from the feature branch to master.
>
> Hm, weird. I would like to see some reproducible evidence of this so
> that a deeper investigation can be done. I've used rebase thoroughly for
> many years on hundreds of projects without any such incident.
>

If the branch you're integrating via rebase happens to have merge commits
of its own, and you don't pass and/or fully understand what
--preserve-merges does, it's possible I think. If you always always merge,
it doesn't happen. Neither does it if you always always rebase, I guess. So
I guess the argument can be spun around into a counter-merge argument, I
guess. Anyway, I'm a rebase lover myself.

João

>

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

Re: Gitlab Migration

[João Távora]

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

> On Sun, Aug 29, 2021, 09:23 Drew DeVault <sir@cmpwn.com> wrote:
>
>  On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
>  > I no longer remember the exact details, it was something we bumped
>  > into during discussions when Emacs switched to Git. AFAIR, it had to
>  > do with working on a feature branch and frequently rebasing it onto
>  > the latest master (so that the feature branch doesn't diverge too
>  > much), then later merging from the feature branch to master.
>
>  Hm, weird. I would like to see some reproducible evidence of this so
>  that a deeper investigation can be done. I've used rebase thoroughly for
>  many years on hundreds of projects without any such incident.
>
> If the branch you're integrating via rebase happens to have merge
> commits of its own, and you don't pass and/or fully understand what
> --preserve-merges does, it's possible I think. If you always always
> merge, it doesn't happen. Neither does it if you always always rebase,
> I guess. So I guess the argument can be spun around into a
> counter-merge argument, I guess. Anyway, I'm a rebase lover myself.

I just realize I "guessed" about 50 thousand times there and was
basically handwaving.  I've tried a simple example of my own speculation
just now and couldn't reproduce.  Either my toy example was too
simplistic (it involved two branches, a single file and no conflicts
ever) or it's been somehow fixed in recent Git versions.

I still think it may happen if you mix rebase & merge.  Especially if
you merge from "unreliable branches", i.e. branches whose collaborators
are not entirely aware/proficient with the commit-duplicating
consequences of rebasing and/or cherry-picking.

This is a tangent, but we also have some practice here in Emacs which I
don't fully understand, which is to "merge back from release branches"
to integrate fixes from those branches into 'main'.  That in itself
already opens the doors to "duplicated commits" if special care isn't
taken.  That's because these merges are special: they somehow don't
contain all of the stuff that was present in the release branches.  See,
for example, this commit:

    commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
    Merge: 979f14e641 5b03849102
    Author: Glenn Morris <rgm@gnu.org>
    Date:   Wed Aug 25 07:51:41 2021 -0700
     
        ; Merge from origin/emacs-27
     
        The following commit was skipped:
     
        5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...

I don't know if this practice is what constitutes an "evil merge", but
it's the way Emacs release management has worked (successfully, to the
best of my knowledge) for a good while.

João

Re: Merges from release branch (was: Gitlab Migration)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  "Philip K." <philipk@posteo.net>,  Daniel
>  Fleischer <danflscr@gmail.com>,  Theodor Thornhill <theo@thornhill.no>,
>   emacs-devel <emacs-devel@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  Dmitry Gutov <dgutov@yandex.ru>,  Lars
>  Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 29 Aug 2021 10:53:53 +0100
> 
> This is a tangent, but we also have some practice here in Emacs which I
> don't fully understand, which is to "merge back from release branches"
> to integrate fixes from those branches into 'main'.  That in itself
> already opens the doors to "duplicated commits" if special care isn't
> taken.  That's because these merges are special: they somehow don't
> contain all of the stuff that was present in the release branches.  See,
> for example, this commit:
> 
>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>     Merge: 979f14e641 5b03849102
>     Author: Glenn Morris <rgm@gnu.org>
>     Date:   Wed Aug 25 07:51:41 2021 -0700
>      
>         ; Merge from origin/emacs-27
>      
>         The following commit was skipped:
>      
>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...

What problems do you see with these merges?  I don't think I follow.

The commits are skipped either because they are marked "not to merge"
(meaning they are inappropriate for master) or because master already
has the same or a different fix.

Re: Merges from release branch

[David Engster]

>> This is a tangent, but we also have some practice here in Emacs which I
>> don't fully understand, which is to "merge back from release branches"
>> to integrate fixes from those branches into 'main'.  That in itself
>> already opens the doors to "duplicated commits" if special care isn't
>> taken.  That's because these merges are special: they somehow don't
>> contain all of the stuff that was present in the release branches.  See,
>> for example, this commit:
>> 
>>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>>     Merge: 979f14e641 5b03849102
>>     Author: Glenn Morris <rgm@gnu.org>
>>     Date:   Wed Aug 25 07:51:41 2021 -0700
>>      
>>         ; Merge from origin/emacs-27
>>      
>>         The following commit was skipped:
>>      
>>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...
>
> What problems do you see with these merges?  I don't think I follow.
>
> The commits are skipped either because they are marked "not to merge"
> (meaning they are inappropriate for master) or because master already
> has the same or a different fix.

I think João is confused how you would "skip" a commit in a merge,
because you actually can't. The more proper way would be to say "this
commit was separately merged with the strategy 'ours'", but this is
quite a mouthful. The merge stategy 'ours' simply means that the content
of the merged commits is discarded, but it's a perfectly valid way to
merge, so nothing "evil" about it.

-David

Re: Gitlab Migration

[theo]

August 29, 2021 10:33 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> Are you sure you're rebasing in this scenario and not making merge
> commits? If you can come up with a series of git commands which
> reproduces this scenario, I would like to investigate further. Let's
> follow up off-list.


I'll add it as a tangent here because others seemed to chime in. You have to see this from the point of view of someone not used to git at all.

Repo with double edits: 
https://git.sr.ht/~theo/rebase/log

Ok, so what happens?

1. Make some commits, push them
2. Rebase your stuff locally, get this warning after:
```
On branch master
Your branch and 'rebase/master' have diverged,
and have 1 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean
```
(A newcomer would read this as advice)
3. git pull
4. fix conflicts if there are any
5. git add . && git commit, then save the file with commit msg
6. git push


Then you end up with the state in that repo. Timestamps are all over the place and things get hilarious real quick.

I'd consider this a bug in git, though. That message is super confusing.

This can happen in all sorts of workflows. And the fix isn't "do it correctly", since it is so simple to get wrong. When other people add things to master branch while you work on your feature it gets even worse.

Hope this helps

--
Theo

Re: Merges from release branch

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  "Philip K." <philipk@posteo.net>,  Daniel
>>  Fleischer <danflscr@gmail.com>,  Theodor Thornhill <theo@thornhill.no>,
>>   emacs-devel <emacs-devel@gnu.org>,  Stefan Monnier
>>  <monnier@iro.umontreal.ca>,  Dmitry Gutov <dgutov@yandex.ru>,  Lars
>>  Ingebrigtsen <larsi@gnus.org>
>> Date: Sun, 29 Aug 2021 10:53:53 +0100
>> 
>> This is a tangent, but we also have some practice here in Emacs which I
>> don't fully understand, which is to "merge back from release branches"
>> to integrate fixes from those branches into 'main'.  That in itself
>> already opens the doors to "duplicated commits" if special care isn't
>> taken.  That's because these merges are special: they somehow don't
>> contain all of the stuff that was present in the release branches.  See,
>> for example, this commit:
>> 
>>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>>     Merge: 979f14e641 5b03849102
>>     Author: Glenn Morris <rgm@gnu.org>
>>     Date:   Wed Aug 25 07:51:41 2021 -0700
>>      
>>         ; Merge from origin/emacs-27
>>      
>>         The following commit was skipped:
>>      
>>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...
>
> What problems do you see with these merges?  I don't think I follow.
>
> The commits are skipped either because they are marked "not to merge"
> (meaning they are inappropriate for master) or because master already
> has the same or a different fix.

I think I understand fully the reasons _why_ they are skipped.

Here's the source of my comment/confusion: normally, in a merge, I have
the expectation that the ancestors of the each branch being merged
become ancestors of the new commit, the "merge commit".  That is the way
that the vast majority of merges function.  However, for Emacs's
"skipped commits" it is sometimes only half-true, at best.

For instance, 5b038491 is, according to Git, an ancestor of 8ba6a38b3
and all 8ba6a's descendents.  However, its contents -- i.e. its diff --
are not.  At least, not exactly in the diff form as they were created,
because, as you say, they may take on a different form.  I'll add that
in the case of a bugfix commit, that bugfix may be entirely not
applicable to 'main' become the root cause of the bug being fixed has
been eliminated in the meantime.  Then the skipped commit contents would
simply not be in 'main'.

Nevertheless, a naive Git archeologist will assume 5b038491 to be in
8ba6a38b3 or its descendents, but will _not_ find its contents as easily
as he would some other non-skipped commit from some other regular merge.
If the user is lucky, she'll reach hopefully 8ba6a38b3 and read the
commit message which hopefully explains the situation: "you'd think
5b038 would be here, but it's not because reasons".

In summary, the Emacs way of doing this confuses me (and perhaps other
Git users), as I expect a merge commit to integrate fully the
developments of two or more branches.  That is, when I see it in the
DAG, I expect it to contain the contents of the two or more ancestor
branches.  Modulo conflict resolutions, where "conflict" is defined by
Git's inability to merge automatically (using whichever merge driver).
Of course a project may have sophisticated drivers and/or sophisticated
"semantic" definitions of "conflict" so that even Emacs's way of doing
this could in a way conform perfectly to my expectation if I'm
sufficently aware of those definitions.

Anyway, what could be an alternative?  Well, in other projects I work
with, these re-integrations of "release-and-dev-worthy" fixes into the
main development branch take the form of 'git cherry-pick's.  In Emacs,
this would mean cherry-picking only the "unskipped" commits.  The
cherry-picks' commit messages can be specially marked via a `-x` flag.
Arguably -- though, mind you, I'm not necessarily arguing in this
direction, just presenting an idea-- this is a means to:

* reach the same end goal: to have the release-and-dev-worthy fixes
  integrated into the main branch;

* provide more clarity to Git users who may not be familiar with the
  particular sophisticated definition of a conflict or non-default merge
  drivers.

I've seen multiple project work in this cherry-pick fashion, but I've
not done any kind of survery.  I'm unaware of what the linux kernel
does, for example.  Emacs is the only project I know that uses merges
this way, and afaik, they work fine: I've never personally had a problem
with archeology.

Hope this helps,
João

Re: Gitlab Migration

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 28 Aug 2021 23:03:22 -0400
> Cc: emacs-devel@gnu.org
> 
> Would someone like to implement Message-ID threading in Rmail?
> I would definitely appreciate it.

Is the below good enough?  If it is, I can easily code a similar
"previous-by-thread" command.

Note that this actually goes by sub-thread, i.e. it follows the
"In-Reply-To" headers, so if a thread breaks into several separate
lines of parallel discussions, this will follow only one of them.  I
think it's reasonable, given that we have rmail-next-same-subject,
which can be used to find the other sub-threads, but I'm no email
expert, so I might be missing something.

(defun rmail-next-by-thread ()
  (interactive)
  (let* ((i rmail-current-message)
         (id (rmail-get-header "message-id" i))
	 done)
    (while (and (not done) (< i rmail-total-messages))
      (setq i (1+ i)
            done (string-equal id (rmail-get-header "in-reply-to" i))))
    (if done (rmail-show-message i)
      ;; If not found forward, try backward: messages could have
      ;; arrived out of order.
      (while (and (not done) (> i 1))
	(setq i (1- i)
	      done (string-equal id (rmail-get-header "in-reply-to" i))))
      (if done (rmail-show-message i)
	(error "No further messages in this thread")))))

Re: Merges from release branch

[João Távora]

David Engster <deng@randomsample.de> writes:

>>> This is a tangent, but we also have some practice here in Emacs which I
>>> don't fully understand, which is to "merge back from release branches"
>>> to integrate fixes from those branches into 'main'.  That in itself
>>> already opens the doors to "duplicated commits" if special care isn't
>>> taken.  That's because these merges are special: they somehow don't
>>> contain all of the stuff that was present in the release branches.  See,
>>> for example, this commit:
>>> 
>>>     commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
>>>     Merge: 979f14e641 5b03849102
>>>     Author: Glenn Morris <rgm@gnu.org>
>>>     Date:   Wed Aug 25 07:51:41 2021 -0700
>>>      
>>>         ; Merge from origin/emacs-27
>>>      
>>>         The following commit was skipped:
>>>      
>>>         5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...
>>
>> What problems do you see with these merges?  I don't think I follow.
>>
>> The commits are skipped either because they are marked "not to merge"
>> (meaning they are inappropriate for master) or because master already
>> has the same or a different fix.
>
> I think João is confused how you would "skip" a commit in a merge,
> because you actually can't.

Precisely, though I'm reasonably aware of why and how its done.  I've
explained what I find "confusing" or "peculiar" about it in a longer
email to Esli.

>The more proper way would be to say "this
> commit was separately merged with the strategy 'ours'", but this is
> quite a mouthful. The merge stategy 'ours' simply means that the content
> of the merged commits is discarded, but it's a perfectly valid way to
> merge, so nothing "evil" about it.

I think "evil" as an adjective is suitably exaggerated to characterize
merges where some semantic knowledge of the source (vs Git's purely
formal knowledge) of it, was applied to solve a particular definition of
a "conflict".  Those definitions and semantic insights differ from the
Git defaults, which is concerned with line ranges and hunks.  Newcomer
Git archeologists thus don't have good way to know what kind of merge
they're looking at, short of reading commit messages carefully and or
perusing project documentation.  Moreover the non-defualt merge
techniques may be inconsistently applied across commiters or across time
spans.  In short, this Fear-Uncertainty-Doubt is what could be called
"evil" in a sense.

Of course, if everybody has a full understanding of practices, and
definitions and behaves and follows rules, no FUD exists and nothing
"evil" ever takes place.  But that is a big "if".

João

PS: the 'man gitglossary' definition of an "evil merge" is "a merge that
introduces changes that do not appear in any parent."  I do think this
comprises "removing code that appears in some parent", because that
removal is the introduction of a change that was absent before the merge
commit and present after it.  Linus Torvalds definition is more
sophisticated and better, IMO.  According to [1], he says:

  an "evil merge" is something that makes changes that came from neither
  side and aren't actually resolving a conflict.

In this definition, the concept of "conflict" appears.  Depending on how
you massage that concept, nothing is evil and everything is.

Re: Merges from release branch

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 29 Aug 2021 13:29:27 +0100
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org, sir@cmpwn.com
> 
> Here's the source of my comment/confusion: normally, in a merge, I have
> the expectation that the ancestors of the each branch being merged
> become ancestors of the new commit, the "merge commit".  That is the way
> that the vast majority of merges function.  However, for Emacs's
> "skipped commits" it is sometimes only half-true, at best.

No, it's always true, AFAIU.

> For instance, 5b038491 is, according to Git, an ancestor of 8ba6a38b3
> and all 8ba6a's descendents.  However, its contents -- i.e. its diff --
> are not.

I think you are confusing between the ancestry in the DAG sense of the
word, on the one hand, and the contents of the merged commits, OTOH.

> In summary, the Emacs way of doing this confuses me (and perhaps other
> Git users), as I expect a merge commit to integrate fully the
> developments of two or more branches.

Welcome to Git: IME, Git without confusion doesn't exist.

We use the merge workflow because it's the easiest and the less
dangerous one.  We know for a long time that it sometimes produces
confusing and/or suboptimal DAG, but we decided long ago that this is
the price we are prepared to pay in order to make routine usage less
error-prone for those users who are not Git experts and basically use
Git commands as a cookbook they don't always understand 100%.

> Anyway, what could be an alternative?

We examined the alternatives when we switched to Git, and decided they
all are either more complicated, or more dangerous, or both.

Re: Merges from release branch

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

> I think you are confusing between the ancestry in the DAG sense of the
> word, on the one hand, and the contents of the merged commits, OTOH.

What I'm trying to tell you is that -- by default -- in Git, merging
_means_ composition of contents of the ancestors, modulo trivial
patch-application conflicts.  So there's a clear relation between the
two things: DAG ancestry and code contents.  Git allows you to invent
arbitrary meanings for merging, but deviating from the default is
confusing to... those who expect the default.

> We examined the alternatives when we switched to Git, and decided they
> all are either more complicated, or more dangerous, or both.

Of course, there are cons to everything: integrating back by
cherry-picking involves creating different commits with the same
headline&contents, so that if you have many 'emacs-2x' commits to
integrate back they all appear again in 'main' (but never twice in
'main').  That could be tiresome to some.  Also, with cherry-picks
alone, there's no clear way to tell from the DAG when Glenn decided to
"integrate back" like there is now.  However someone could argue that
those cons are outweighed by the fact that no merge commits exists and
that ancestry at a given point of the DAG now tells any Git user which
code changes are operating at a given point.

As to a specific "danger", I'm intrigued.  Like Drew, would have to see
a particular "dangerous" scenario before I can comment on it.  The
enormous Git threads of 5-6 years ago I remember are too daunting to
re-read.

João

Re: Merges from release branch

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 29 Aug 2021 15:48:22 +0100
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org, sir@cmpwn.com
> 
> As to a specific "danger", I'm intrigued.  Like Drew, would have to see
> a particular "dangerous" scenario before I can comment on it.  The
> enormous Git threads of 5-6 years ago I remember are too daunting to
> re-read.

Then you'll have to trust me on that one.

Re: Merges from release branch

[João Távora]

On Sun, Aug 29, 2021 at 3:59 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sun, 29 Aug 2021 15:48:22 +0100
> > Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
> >  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
> >  larsi@gnus.org, sir@cmpwn.com
> >
> > As to a specific "danger", I'm intrigued.  Like Drew, would have to see
> > a particular "dangerous" scenario before I can comment on it.  The
> > enormous Git threads of 5-6 years ago I remember are too daunting to
> > re-read.
>
> Then you'll have to trust me on that one.

For Emacs, sure. Even if our integration scheme is somewhat peculiar,
it is at least very well done, well documented, and I've never had
problems. I'm really quite happy with Git in Emacs and excited about
this recent inclination to SourceHut.

Of course I wonder if there's something special in Emacs it that makes it
somehow vulnerable to more commonly found integration strategies, or,
alternatively, if the danger you're imagining is something to worry about
for any other projects that utilizes them.

João

Re: Merges from release branch

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 29 Aug 2021 16:21:30 +0100
> Cc: "Philip K." <philipk@posteo.net>, Daniel Fleischer <danflscr@gmail.com>,
>  Theodor Thornhill <theo@thornhill.no>, emacs-devel <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, Dmitry Gutov <dgutov@yandex.ru>,
>  Lars Ingebrigtsen <larsi@gnus.org>, sir@cmpwn.com
> 
> Of course I wonder if there's something special in Emacs it that makes it
> somehow vulnerable to more commonly found integration strategies, or,
> alternatively, if the danger you're imagining is something to worry about
> for any other projects that utilizes them.

The discussions at the time were long, detailed, and raised several
loosely-related issues, all of them in the context of what to say in
the document we were composing that described the recommended
procedures.  I don't remember the details, sorry.  Once we understood
the issues and made the decision, there was no need for me to keep
those details in memory.  Maybe David or someone else remembers; if
not, there's no way around the need to read those discussions.

Re: Merges from release branch

[Eli Zaretskii]

> Date: Sun, 29 Aug 2021 18:55:32 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: philipk@posteo.net, danflscr@gmail.com, theo@thornhill.no,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>  larsi@gnus.org, sir@cmpwn.com
> 
> > Of course I wonder if there's something special in Emacs it that makes it
> > somehow vulnerable to more commonly found integration strategies, or,
> > alternatively, if the danger you're imagining is something to worry about
> > for any other projects that utilizes them.
> 
> The discussions at the time were long, detailed, and raised several
> loosely-related issues, all of them in the context of what to say in
> the document we were composing that described the recommended
> procedures.  I don't remember the details, sorry.  Once we understood
> the issues and made the decision, there was no need for me to keep
> those details in memory.  Maybe David or someone else remembers; if
> not, there's no way around the need to read those discussions.

Oh, and the only aspect in those discussions that was specific to
Emacs, AFAIR, was that we have 2 branches that diverge very quickly.

Re: GitLab feature request compared with SourceHut

[Ben Mezger]

> It would be nice to have the emacs vote of confidence in our services,
> in the strategic sense of mutual support between organizations which
> believe in free software.

Drew summarized what I've meant with "first move". Emacs migration
towards a service like sourcehut may contribute to the confidence
and motivation of other projects to follow a similar approach.

"Drew DeVault" <sir@cmpwn.com> writes:

> On Sun Aug 29, 2021 at 5:03 AM CEST, Richard Stallman wrote:
>> > Maybe if Emacs makes the first move, perhaps other projects may follow
>> > the same path.
>>
>> Sorry -- what is "first move" that is being proposed?
>>
>> We want to host Emacs on a GNU server, not someone else's.
>
> You can run the sourcehut software on GNU servers, it is 100% free
> software, mostly AGPL. I would encourage you to do so.
>
> However, I think that this is a rare case where you could also use our
> servers if you so desired. The software on our servers is not patched,
> it's the same free software you would run on yours. If you did some
> reading on sourcehut, I think you would find our philosophy quite
> compatible with GNU's ideals. It would be nice to have the emacs vote of
> confidence in our services, in the strategic sense of mutual support
> between organizations which believe in free software.
>
> SourceHut is a straight upgrade from the existing mailing lists, and
> supports the existing workflow almost 1:1, perhaps pending some minor
> enhancements around attachments. The web tools to accomodate the
> pull-request generation are at a prototype stage, but will be improved.
> The free software ethic is here to stay.


--
Kind regards,
Met een vriendelijke groet,
Atenciosamente,

Ben Mezger

https://seds.nl
https://github.com/benmezger

Re: Gitlab Migration

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>   > We haven't found such a system yet.  sr.ht is perhaps an option, but my
>   > first impression is that it's too different from GitHub/Lab, really.
>
> Why should such a difference disqualify it?  We have no commitment to
> GitHub/Lab; on the contrary, we disapprove of them.

The main point of this exercise is to provide new Emacs workflows that
people used to, and comfortable with using.

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

Re: Gitlab Migration

[Tassilo Horn]

theo@thornhill.no writes:

Hi Theo,

> Repo with double edits: 
> https://git.sr.ht/~theo/rebase/log
>
> Ok, so what happens?
>
> 1. Make some commits, push them
> 2. Rebase your stuff locally, get this warning after:

Well, looking at "git log --graph" of your repo, I'm pretty sure you
ended there because in step 2 you rebased commits which you had already
pushed and later merged the upstream branch with the locally rebased
one.  Rebasing commits which are already pushed is a no-go unless you
are working in your private branch.

Bye,
Tassilo

Re: Gitlab Migration

[Theodor Thornhill]

On 29 August 2021 21:03:45 CEST, Tassilo Horn <tsdh@gnu.org> wrote:
>theo@thornhill.no writes:
>
>Hi Theo,
>
>> Repo with double edits: 
>> https://git.sr.ht/~theo/rebase/log
>>
>> Ok, so what happens?
>>
>> 1. Make some commits, push them
>> 2. Rebase your stuff locally, get this warning after:
>
>Well, looking at "git log --graph" of your repo, I'm pretty sure you
>ended there because in step 2 you rebased commits which you had already
>pushed and later merged the upstream branch with the locally rebased
>one.  Rebasing commits which are already pushed is a no-go unless you
>are working in your private branch.
>

Yeah, absolutely. Thing is these things happen to people and are possibly why people find git hard. At least when your gui hides the fact that git pull is fetch and merge behind a +button, or something like that.

And this is also a way to get duplicated commits without doing very complicated footgun things. Git itself hands you the gun in this case.

Theo

Re: Gitlab Migration

[Dmitry Gutov]

On 29.08.2021 10:42, Lars Ingebrigtsen wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> - Rebasing. Some of our valued contributors are not 100% comfortable
>>    with the more advanced features of Git, rebasing included. Our
>>    general recommendation until now has been to prefer merge
>>    commits.
> Well, one of the co-maintainers is sceptical towards rebasing, and the
> other one uses it exclusively, so I don't think we currently have any
> recommendation on the matter.

Whenever a question arose about a recommended workflow from someone who 
claims not to understand Git well, the recommendation always came in the 
form "use merges, not rebase". Which is a good suggestion, I think.

A well-done rebase is indistinguishable from a "normal" branch, so of 
course there is no point in prohibiting their use.

Re: Gitlab Migration

[Dmitry Gutov]

On 29.08.2021 10:42, Drew DeVault wrote:
> On Sun Aug 29, 2021 at 9:38 AM CEST, Eli Zaretskii wrote:
>> Rebasing is not just intimidating, it has real problems as well. One
>> problem that particularly bothers us is that it could, in some
>> circumstances, cause the same commit to be present more than once.
>>
>> I find a hard requirement to use rebase to be user-unfriendly, because
>> some of us simply don't want to rebase, for reasons of preserving the
>> original history of the development. Is rebasing really a requirement
>> in SourceHut?
> No, it's not a requirement. It's just something I think is a good idea.

When you say it's not a requirement, how does the alternative work?

Suppose I have a feature branch scratch/exciting-new-feature.

And it has a number of existing commits A, B, C, where I did some work 
on said feature.

Then I do a merge from master, creating a merge commit M which resolves 
a conflict. It also pulls commits M1 and M2 from master into the branch, 
both of which have a later creation date than A.

Then I add commits D and E with some subsequent work.

What do I do next, to submit the new version of the code?

If I try to submit that branch's contents from the web UI, and I need to 
select all the commits which include the work:

- Does the Prepare Patchset UI show commits M1 and M2? What happens if 
they get selected (residing chronologically between A and E)?

- Does the Prepare Patchset UI show the merge commit M? If yes, what 
happens with it later if the patchset gets approved? Does it turn into a 
"real" merge commit?

Re: Gitlab Migration

[Dmitry Gutov]

On 29.08.2021 09:55, Drew DeVault wrote:

>> - Every version of a patchset is re-submitted as a whole. I suppose
>> there is some purity in that, but if for example the original submission
>> is big, and I only asked the author to change a few relatively minor
>> things, I prefer they do that in a separate commit. Then, in a git**b
>> workflow, I see that the branch was updated with that one commit, and I
>> don't have to scan the other commit(s) for any unrelated/breaking
>> changes.
> 
> This is a bad practice for git, because it makes the history worse. This
> has consequences, for example, with tools like git bisect.

Depends on how the changes are organized, whether there will be breaking 
builds, and whether commits include back-and-forth changes in the same 
place.

In the end, a branch-driven workflow can ask for a single rebase before 
the changes are merged to master (with fixups, squashes, etc). Which 
should fix the later problems with bisecting and give cleaner history, 
without having all the patches resent for every round of review.

> Instead, git
> range-diff is helpful for comparing the previous and new version of a
> patch, and future improvements to the web UI will incorporate it to
> allow you to easily diff between patchset revisions. The idea is
> something similar to Gerrit's approach, you may be familiar with that.

Haven't used Gerrit (or Phabricator, which I understand includes a 
similar feature). Good to know there is a plan for it, though.

>> - Rebasing. Some of our valued contributors are not 100% comfortable
>> with the more advanced features of Git, rebasing included. Our general
>> recommendation until now has been to prefer merge commits. If the
>> general workflow is going to require people to 'git rebase -i' on a
>> regular basis, it could be a problem.
> 
> We wrote another tutorial about git rebase which has been very helpful:
> 
> https://git-rebase.io
> 
> In general we are a hard "no" on shying away from powerful tools because
> they are intimidating to new users. We prefer to cultivate a culture of
> mentorship instead.

All right. I can live with that. Just want to make sure everybody's on 
the same page about the tradeoffs.

>> - Can we have discussion subthreads "attached" to particular pieces of
>> the submitted patches? Like, a line, or a hunk. Being able to view those
>> in a compact fashion, right in the middle of the context, is pretty
>> handy.
> 
> Yes, though it's based on heuristics and we're still working on it.
> Here's a simple example:
> 
> https://lists.sr.ht/~mpu/qbe/patches/24383

Thanks. I'm curious to see how it turns out.

>> - Can I jump in in the middle of a patch discussion with a question or
>> an advice and have all subsequent messages in that discussion sent to me
>> too, if I'm not subscribed to the target mailing list? Does that depend
>> on all participants putting me in Cc?
> 
> It depends on all of the participants Cc'ing you. It is common practice
> to "reply all" on mailing lists for this reason.

Sure, I'm familiar with it. Hence the questions.

>> - Can I do that "jumping in" from the web interface?
> 
> No, but this is a prioritized issue.
> 
>> - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not
>> longer interested in?
> 
> In a sense. Because you don't have to subscribe to the mailing list to
> participate in a thread, you won't get emails unless the sender has Cc'd
> you. But you cannot stop them from Cc'ing you, and neither can we,
> unless you ask nicely - which is not a software solution. Such emails
> are not relayed by our mail servers, so it's out of our control.

Consider adopting a "common practice" from the Web UI world: every 
discussion (issue/PR/etc) has a unique email address. Every participant 
receives messages "From:" a common address (like notifications@sr.ht) 
but the Reply-To header includes the unique address which will let the 
mail processor on the server associate the reply with the corresponding 
thread and resend it to all participants.

Then anybody will be able to subscribe or unsubscribe from a thread 
without others' cooperation (with different levels, even, where e.g. 
they still get a notification when "mentioned" personally).

As a bonus, it solves the problem of some mail servers/hostings not 
talking to some other mail servers: if you can send an email to sr.ht, 
all others will see it. If you can receive emails from sr.ht, you will 
get all messages.

But it might feel a tad impersonal, I guess. And user error (including 
misbehaving MUAs) can break this approach too.

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: [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 feature request compared with SourceHut

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

  > Drew summarized what I've meant with "first move".

Thanks for showing me that.

                                                       Emacs migration
  > towards a service like sourcehut may contribute to the confidence
  > and motivation of other projects to follow a similar approach.

We could switch to using the sourcehut software on a GNU server.

I think Drew DeVault is right in saying that his philosophy is close
to ours.  If we had to use some outside hosting service, I might well
say there is no better choice than his.  (I don't want to criticize
the other options without knowing what they are; they may be equally
good.)  But we'd rather have this on a GNU machine with GNU Project
people managing it.

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

rmail threading

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

  > Is the below good enough?  If it is, I can easily code a similar
  > "previous-by-thread" command.

It is a start, but what is really needed is a summary command
to generate a summary containing the messages of a thread established
by message-IDs.

In fact, I never use rmail-next-same-subject; I don't even remember
it is there.  I always use rmail-summary-by-topic, after which
I can see all the messages of the thread-by-subject.

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

[Drew DeVault]

On Mon Aug 30, 2021 at 1:17 AM CEST, Dmitry Gutov wrote:
> Consider adopting a "common practice" from the Web UI world: every
> discussion (issue/PR/etc) has a unique email address. Every participant
> receives messages "From:" a common address (like notifications@sr.ht)
> but the Reply-To header includes the unique address which will let the
> mail processor on the server associate the reply with the corresponding
> thread and resend it to all participants.

We cannot add a similar "common practice", as it were, where each
message comes From notifications@sr.ht, without breaking DKIM or PGP
signatures, which we refuse to do. But, we can track participation in
each thread and subscribe users to threads even without a specific email
address, by linking up the In-Reply-To chain. This is how I envision
your ticket being addressed.

Re: Gitlab Migration

[Drew DeVault]

On Mon Aug 30, 2021 at 12:27 AM CEST, Dmitry Gutov wrote:
> When you say it's not a requirement, how does the alternative work?
>
> Suppose I have a feature branch scratch/exciting-new-feature.
>
> And it has a number of existing commits A, B, C, where I did some work
> on said feature.
>
> Then I do a merge from master, creating a merge commit M which resolves
> a conflict. It also pulls commits M1 and M2 from master into the branch,
> both of which have a later creation date than A.
>
> Then I add commits D and E with some subsequent work.

Honestly, by doing this you have created a poor git history which I, as
a maintainer, would not care to review, be it via email or any other
means including the GitHub workflow. I would teach you how to rebase it
properly instead of accepting this work, and I think that emacs would be
wise to do the same.

However, you can still work with this on sourcehut by using git
request-pull(1):

https://www.git-scm.com/docs/git-request-pull

There is no UI for this, but it is planned.

gebbugs.gnu.org search (was Re: Gitlab Migration)

[Maxim Nikulin]

On 27/08/2021 13:21, tomas tuxteam.de wrote:
> On Thu, Aug 26, 2021 at 09:41:06PM +0000, Drew Adams wrote:
> 
>> 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].
...
> [1] https://html.duckduckgo.com/html?q=redisplay+idle+site:debbugs.gnu.org

Does it work for you? I get titles like
- "GNU bug reports: Normal bugs - outstanding"
- "GNU bug report logs - #17678"
and links to raw mail messages, e.g. debbugs.gnu.org/db/17/17678.html

I have no idea what should be find by your request, so let's consider 
another one:

https://html.duckduckgo.com/html?q=site%3Adebbugs.gnu.org+emacs+locale+number

For this particular query I expect to get

     *#29645 Feature Request: Locale aware formatting*
     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29645

among top results. Actually I would not mind to get it without narrowing 
search to debbugs.gnu.org.

It seems, google has no chance to provide relevant human friendly 
results due to

https://debbugs.gnu.org/robots.txt
 > Disallow: /cgi/

Configuration of Debian bug tracker is better:
https://bugs.debian.org/robots.txt
 > Allow: /cgi-bin/bugreport.cgi?bug=

Re: rmail threading

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Sun, 29 Aug 2021 23:01:51 -0400
> 
>   > Is the below good enough?  If it is, I can easily code a similar
>   > "previous-by-thread" command.
> 
> It is a start, but what is really needed is a summary command
> to generate a summary containing the messages of a thread established
> by message-IDs.

Ah, you want an Rmail summary command for this...  OK, will do.

In any case, my original naïve attempt was wrong, because even
sub-threads have the tree structure, they aren't linear lists.  So
we'd need a tree-traversing code, not unlike what SPC and DEL do in
Info.

> In fact, I never use rmail-next-same-subject; I don't even remember
> it is there.  I always use rmail-summary-by-topic, after which
> I can see all the messages of the thread-by-subject.

I prefer not to review a thread via a summary, because a specialized
summary prevents me from easily seeing messages that don't satisfy the
summary criteria.  This is important with criteria based on fuzzy
stuff like the Subject, because people or their MUA many times change
or mangle the Subject, and then those messages appear not to be there.
But that's me.

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

[Dmitry Gutov]

On 30.08.2021 09:31, Drew DeVault wrote:
> On Mon Aug 30, 2021 at 12:27 AM CEST, Dmitry Gutov wrote:
>> When you say it's not a requirement, how does the alternative work?
>>
>> Suppose I have a feature branch scratch/exciting-new-feature.
>>
>> And it has a number of existing commits A, B, C, where I did some work
>> on said feature.
>>
>> Then I do a merge from master, creating a merge commit M which resolves
>> a conflict. It also pulls commits M1 and M2 from master into the branch,
>> both of which have a later creation date than A.
>>
>> Then I add commits D and E with some subsequent work.
> 
> Honestly, by doing this you have created a poor git history which I, as
> a maintainer, would not care to review, be it via email or any other
> means including the GitHub workflow. I would teach you how to rebase it
> properly instead of accepting this work, and I think that emacs would be
> wise to do the same.

So far it has been common practice around these parts, but OK.

> However, you can still work with this on sourcehut by using git
> request-pull(1):
> 
> https://www.git-scm.com/docs/git-request-pull
> 
> There is no UI for this, but it is planned.

Thanks.

Re: Gitlab Migration

[Dmitry Gutov]

On 30.08.2021 09:29, Drew DeVault wrote:
> On Mon Aug 30, 2021 at 1:17 AM CEST, Dmitry Gutov wrote:
>> Consider adopting a "common practice" from the Web UI world: every
>> discussion (issue/PR/etc) has a unique email address. Every participant
>> receives messages "From:" a common address (like notifications@sr.ht)
>> but the Reply-To header includes the unique address which will let the
>> mail processor on the server associate the reply with the corresponding
>> thread and resend it to all participants.
> 
> We cannot add a similar "common practice", as it were, where each
> message comes From notifications@sr.ht, without breaking DKIM or PGP
> signatures, which we refuse to do.

This is about sender identity verification, right? No chance to delegate 
that responsibility to the SourceHut instance?

If the web interface allows users to create patchset email on behalf of 
the user, or even send messages to the mailing list from the web UI (not 
sure if such feature is present, but there will be a demand for it), you 
are already creating emails on their behalf anyway.

> But, we can track participation in
> each thread and subscribe users to threads even without a specific email
> address, by linking up the In-Reply-To chain. This is how I envision
> your ticket being addressed.

Will that affect only replies to later emails?

Either way, that means no reliable way to "unsubscribe from a thread". 
Unfortunate, but of course less important that being able to subscribe.

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

[Drew DeVault]

On Mon Aug 30, 2021 at 2:47 PM CEST, Dmitry Gutov wrote:
> This is about sender identity verification, right? No chance to delegate
> that responsibility to the SourceHut instance?
>
> If the web interface allows users to create patchset email on behalf of
> the user, or even send messages to the mailing list from the web UI (not
> sure if such feature is present, but there will be a demand for it), you
> are already creating emails on their behalf anyway.

We find it important to preserve the original integrity of the email.
This is important for a robust and reliable mail system.

> Will that affect only replies to later emails?

Yes.

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

[Dmitry Gutov]

On 30.08.2021 15:49, Drew DeVault wrote:
>> Will that affect only replies to later emails?
> Yes.

I think that can be fixed in the mailing list software layer: if an 
email is addressed to a thread, and there are some ostensibly 
"subscribed" users that are missing from the list of recipients, send it 
to them too.

Re: Gitlab Migration

[Drew DeVault]

On Mon Aug 30, 2021 at 3:00 PM CEST, Dmitry Gutov wrote:
> On 30.08.2021 15:49, Drew DeVault wrote:
> >> Will that affect only replies to later emails?
> > Yes.
>
> I think that can be fixed in the mailing list software layer: if an
> email is addressed to a thread, and there are some ostensibly
> "subscribed" users that are missing from the list of recipients, send it
> to them too.

Yes, this would work, but only for later emails. I certainly would not
want to try and apply it retroactively by emailing someone 100 messages
after they chime in at the end of a large thread.

Re: Gitlab Migration

[Dmitry Gutov]

On 30.08.2021 16:03, Drew DeVault wrote:
> On Mon Aug 30, 2021 at 3:00 PM CEST, Dmitry Gutov wrote:
>> On 30.08.2021 15:49, Drew DeVault wrote:
>>>> Will that affect only replies to later emails?
>>> Yes.
>> I think that can be fixed in the mailing list software layer: if an
>> email is addressed to a thread, and there are some ostensibly
>> "subscribed" users that are missing from the list of recipients, send it
>> to them too.
> Yes, this would work, but only for later emails. I certainly would not
> want to try and apply it retroactively by emailing someone 100 messages
> after they chime in at the end of a large thread.

Sure. That's how "subscribe to a thread" usually works anyway.

debbugs [was Re: Gitlab Migration]

[Glenn Morris]

Obviously no-one's working on d.g.o (for some time), but for the record:

Stefan Monnier wrote:

> - Can't search the database when I'm offline.
>   I really wish the database was stored in Git, so I could easily have
>   a clone of it. 

I can't see how this could have worked in practice, given the size of
the database.

> - No notion of "subscription" to a bug, so replies will sometimes fail
>   to reach me.

A clear shortcoming. I imagine this wouldn't have been too difficult to
implement - just have a flat text file of subscribed addresses for a
report that gets appended to the maintainer list. Ref:
https://debbugs.gnu.org/5439

> - The notion of "archived" bugs is a pain in the rear when you send a
> new message and the message just bounces back with "the bug is
> archived". Either get rid of it, or automatically unarchive bugs when

I think archiving is important for performance reasons.
I imagine automatic unarchiving would have been easy to do, and I agree
it would be useful. Back in the day, I wasn't so sure, eg I thought that
mostly what would happen is that it would mean people could respond to
very old bugs by mistake without noticing.

> - I find it a big difficult to classify bugs.  I'm not sure exactly what
>   I'd like, and maybe some of it can be done via tags and other things
>   already, but I think I'd like it if bugs could be "assigned" to persons
>   and/or to files and/or to "subsystems"

There are the "owner" and "usertag" commands.

> The poor web UI is of course another criticism but it mostly doesn't
> affect me.

The guix people made a wrapper - https://issues.guix.gnu.org/.


Positive feedback back in the day would probably have gotten features 2
and 3 implemented, but the time is long past.

Re: debbugs.gnu.org search [was gebbugs.gnu.org search]

[Glenn Morris]

Maxim Nikulin wrote:

> and links to raw mail messages, e.g. debbugs.gnu.org/db/17/17678.html

At the top of the page, and the bottom, in bold red text, is a link

"Click here to see this page with the latest information and nicer formatting."

For a suggestion for further improvement, see
https://lists.gnu.org/r/help-debbugs/2020-12/msg00026.html


> For this particular query I expect to get
>
>     *#29645 Feature Request: Locale aware formatting*
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29645

It's the second result?!

> https://debbugs.gnu.org/robots.txt
>> Disallow: /cgi/

Disallowed due to performance reasons.

The "static" pages are indexed, and contain prominent (though clearly not
prominent enough) links to the "dynamic" pages.


There is also a simple search on https://debbugs.gnu.org/
and a complex one (I agree the interface is weird) on
https://debbugs.gnu.org/cgi/search.cgi

Re: debbugs [was Re: Gitlab Migration]

[Stefan Monnier]

> Obviously no-one's working on d.g.o (for some time), but for the record:

My comments weren't really "requests for improvement" w.r.t
d.g.o, indeed.

>> - Can't search the database when I'm offline.
>>   I really wish the database was stored in Git, so I could easily have
>>   a clone of it. 
> I can't see how this could have worked in practice, given the size of
> the database.

When experimenting with BuGit I created a Git database holding all of
debbugs.gnu.org and that worked fine.  It was a few GBs large,
admittedly, so the concept would require more work to make it
possible/easy to download only a part of the database (the
representation I used does/did make it fairly easy since each issue gets
its own Git branch, the problem is more about the design of a UI and/or
heuristics to decide which issue to download and or to flush).

>> - The notion of "archived" bugs is a pain in the rear when you send a
>> new message and the message just bounces back with "the bug is
>> archived". Either get rid of it, or automatically unarchive bugs when
> I think archiving is important for performance reasons.

I definitely agree that the implementation would want to have a notion
of "active" vs "inactive" issues for performance reasons (e.g. the above
multi-GB Git clone would have shrunk a fair bit if it only included the
non-archived bugs).

> I imagine automatic unarchiving would have been easy to do, and I agree
> it would be useful. Back in the day, I wasn't so sure, eg I thought that
> mostly what would happen is that it would mean people could respond to
> very old bugs by mistake without noticing.

An automatic message in return to the author pointing out that this is
an old bug would do the job for that.  No need to divert the message to
/dev/null.  After all, all the other recipients will have received the
message anyway.

>> - I find it a big difficult to classify bugs.  I'm not sure exactly what
>>   I'd like, and maybe some of it can be done via tags and other things
>>   already, but I think I'd like it if bugs could be "assigned" to persons
>>   and/or to files and/or to "subsystems"
> There are the "owner" and "usertag" commands.

Indeed, the basic functionality is there, but I somehow never got to
using it.  In web UIs these categorization tools tend to be shown in
such a way that I'm encouraged to use them, whereas in debbugs's email
interface I really have to go out of my way to use them.
Not sure how to do better within the scope of an email interface.


        Stefan

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: SourceHut for Emacs (was: Gitlab Migration)

[Sean Whitton]

Hello,

On Sat 28 Aug 2021 at 09:04AM -04, Stefan Monnier wrote:

> Reading this discussion made me realize why I'm rooting for SourceHut:
> it's the only such tool I've seen whose goals align exactly with ours.
> Both philosophically (most other tools just happen to be Free Software
> and but are more philosophically aligned with Open Source) and
> technically (it aims for first class email support while providing as
> much as possible of the shiny web features of other systems).
>
> So at this stage, I personally don't see much point looking for other
> tools.  Instead I'm just wondering how to get us to use SourceHut
> (i.e. how to resolve the problems that might stand in the way, such as
> getting an instance up and running on GNU machines, starting to use it
> "on the side" to see in practice what issues we'll need
> fixed/improved/added before we can really switch, etc...).

Perhaps we could get a GNU-hosted instance stood up to play with?

-- 
Sean Whitton

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: SourceHut for Emacs (was: Gitlab Migration)

[Yuan Fu]

> On Aug 28, 2021, at 6:04 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> Reading this discussion made me realize why I'm rooting for SourceHut:
> it's the only such tool I've seen whose goals align exactly with ours.
> Both philosophically (most other tools just happen to be Free Software
> and but are more philosophically aligned with Open Source) and
> technically (it aims for first class email support while providing as
> much as possible of the shiny web features of other systems).

Completely agree.

> 
> So at this stage, I personally don't see much point looking for other
> tools.  Instead I'm just wondering how to get us to use SourceHut
> (i.e. how to resolve the problems that might stand in the way, such as
> getting an instance up and running on GNU machines, starting to use it
> "on the side" to see in practice what issues we'll need
> fixed/improved/added before we can really switch, etc...).
> 
> An obvious first issue is the one seen in Theodor's example:
> https://lists.sr.ht/~theo/public-inbox/%3Cm1r1edold3.fsf%40Frende-MacBook.lan%3E
> where the rendering of this email in the web interface completely hides
> the actual patch being sent.
> 

Maybe we could contact them and discuss the potential to move. They probably would be very happy to assist us, since Emacs can be an advertisement and testimony for their product.

Yuan

Re: rmail threading

[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 prefer not to review a thread via a summary, because a specialized
  > summary prevents me from easily seeing messages that don't satisfy the
  > summary criteria.

I am not sure what this means.  A summary based on filtering will show
some messages and not others, but how is that harmful?
It sounds like you want two conflicting things -- what two things are they?

Could you say concretely what "prevents..,from easily seeing" means?
A summary in Rmail doesn't stop you from looking at messages not
included in it.  I do that frequently.

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

[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: debbugs.gnu.org search

[Maxim Nikulin]

On 30/08/2021 22:30, Glenn Morris wrote:
> Maxim Nikulin wrote:
>> and links to raw mail messages, e.g. debbugs.gnu.org/db/17/17678.html
> 
> At the top of the page, and the bottom, in bold red text, is a link
> "Click here to see this page with the latest information and nicer formatting."

Thank you, I have not noticed this link. I believed that link to raw 
messages were indexed by mistake instead of regular pages. My 
expectations were based on what I saw in bug reports on bugs.debian.org. 
My point is that it is still inconvenient to both humans (intermediate 
page) and search engines (heuristics is not powerful enough to recognize 
valuable parts).

> For a suggestion for further improvement, see
> https://lists.gnu.org/r/help-debbugs/2020-12/msg00026.html

Though this branch of "mail vs. web UI" discussion of communication with 
users and contributors is rather off-topic, it seems, the link you 
provided, might explain why some part of users prefer web UI for 
interaction. Technical details of communication are not available to 
crawlers (e.g. forensic ones, unfortunately been still fully available 
to site owners though). Alternative variant of your link:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43073
"#43073 Trim/hide full email headers on debbugs"

>> For this particular query I expect to get
>>
>>      *#29645 Feature Request: Locale aware formatting*
>>      https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29645
> 
> It's the second result?!

Glad to see that the recipe works for someone. I am not so lucky. See 
below for details.

>> https://debbugs.gnu.org/robots.txt
>>> Disallow: /cgi/
> 
> Disallowed due to performance reasons.
> 
> The "static" pages are indexed, and contain prominent (though clearly not
> prominent enough) links to the "dynamic" pages.

I suspected that indexing was broken intentionally. However static pages 
may still be better formatted in my opinion (and with a footer with 
prominent last update time to avoid confusion related to recent updates).

I have not noticed any special HTTP header sent by bugs.debian.org that 
my alleviate server load during scan by search engines. Unsure that 
"cache-control: public, max-age=600" plays a significant role.

> There is also a simple search on https://debbugs.gnu.org/
> and a complex one (I agree the interface is weird) on
> https://debbugs.gnu.org/cgi/search.cgi

I intentionally preserved the following in my previous message.

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

My impression is that "general purpose" search engines are usually able 
to provide more relevant results due to handling of common typos, 
synonyms, etc. At least while there are no precise criteria for a filter...

So the problem is not really reproducible, thus harder to debug. Namely 
duckduckgo does not show #29645 for me on the first page at all. Maybe 
it depends on region from which a request is originated.

There is another issue with "static" debbugs pages for indexing by 
search engines: poor metadata. HTML TITLE element contains just "GNU bug 
report logs - #29645". Debbugs does not support '<meta 
name="description" content="">' and similar info.

+ duckduckgo (unsure concerning particular underlying engine in my case,
   maybe bing):
   - no #29645 in results
   - title is not informative: "GNU bug report logs - #27544"
   - summary is either enumeration of headers or a part of message
     body. In the former case it is impossible to estimate relevance
     of particular result.
 
https://html.duckduckgo.com/html?q=site%3Adebbugs.gnu.org+emacs+locale+number
+ google
   - title often (but not always) is taken from H1 element,
     so it is usually much better
     "GNU bug report logs - #29645 Feature Request: Locale aware ..."
     Unfortunately it is trimmed.
   - summary: often useless raw headers
     "... X-Spam-Status: No, score=0.8 required=5.0 
tests=BAYES_50,FREEMAIL_FROM, ... Request: Locale aware formatting To: 
bug-gnu-emacs@HIDDEN Content-Type: ..."
 
https://www.google.com/search?q=site%3Adebbugs.gnu.org+emacs+locale+number
+ yandex
   - #29645 sometimes is present, sometimes it is not
   - title is useless: "GNU bug report logs - #29645"
   - summary: a snippet from report is hardly noticeable since
     bug status is placed earlier
     "Package: emacs; Severity: wishlist; Reported by: Gustaf
     Waldemarson ... A while ago I started looking for some simple way
     of writing numbers correctly formatted to the locale. Specifically,
     I wanted the output to use the locale's..."
     It may be completely useless though:
     "Package: emacs; Reported by: Jan Synacek <jsynacek@HIDDEN>;
     merged with #3219 ... Information forwarded to bug-gnu-emacs@HIDDEN:
     bug#40007; Package emacs. Full text available. Merged 3219 4123 9589
     13675 15555..."
   https://yandex.ru/search/?text=site%3Adebbugs.gnu.org+emacs+locale+number
+ bing
   - no #29645
   - titles are useless: "GNU bug report logs - #5618"
   - summary varies from message body snippets to just
     "information forwarded to bug-gnu-emacs@HIDDEN: bug#3229; Package 
emacs. Full text available"
   https://www.bing.com/search?q=site%3Adebbugs.gnu.org+emacs+locale+number

My conclusion is that debbugs.gnu.org is not friendly to search engines, 
so relevant results are not guaranteed, it is hard to estimate if 
particular item may be useful looking at its title and summary. It does 
not matter whether DebBugs, GitLab, or SourceHut is used as a bug 
tracker if robots.txt file does not allow to index descriptions friendly 
to users and to search engines.

Re: SourceHut for Emacs (was: Gitlab Migration)

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Mon, 30 Aug 2021 13:17:42 -0700
> Cc: emacs-devel@gnu.org
> 
> > So at this stage, I personally don't see much point looking for other
> > tools.  Instead I'm just wondering how to get us to use SourceHut
> > (i.e. how to resolve the problems that might stand in the way, such as
> > getting an instance up and running on GNU machines, starting to use it
> > "on the side" to see in practice what issues we'll need
> > fixed/improved/added before we can really switch, etc...).
> > 
> > An obvious first issue is the one seen in Theodor's example:
> > https://lists.sr.ht/~theo/public-inbox/%3Cm1r1edold3.fsf%40Frende-MacBook.lan%3E
> > where the rendering of this email in the web interface completely hides
> > the actual patch being sent.
> > 
> 
> Maybe we could contact them and discuss the potential to move. They probably would be very happy to assist us, since Emacs can be an advertisement and testimony for their product.

They are already participating in these discussions here.

Re: rmail threading

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Mon, 30 Aug 2021 23:09:24 -0400
> 
>   > I prefer not to review a thread via a summary, because a specialized
>   > summary prevents me from easily seeing messages that don't satisfy the
>   > summary criteria.
> 
> I am not sure what this means.  A summary based on filtering will show
> some messages and not others, but how is that harmful?
> It sounds like you want two conflicting things -- what two things are they?
> 
> Could you say concretely what "prevents..,from easily seeing" means?

Once you request a summary based on filtering, the unfiltered summary
is gone.  So I can no longer quickly and conveniently look for
messages that were filtered out by scrolling the summary buffer or by
searching in it.

Suppose a message in a thread changed the subject, enough so that
neither summary by subject nor rmail-next-same-subject find it.  With
the unfiltered summary buffer, I can still look for it, e.g. by
searching for the sender or some fragment of the Subject in the
summary buffer.  With summary-by-topic, I can't do that.

> A summary in Rmail doesn't stop you from looking at messages not
> included in it.  I do that frequently.

Can you tell how do you do that?

And I have one additional question about your request to have a
summary-by-thread: is it okay to request that the user first sorts the
messages by date (C-c C-s C-d), before summarizing the thread?  If
not, then the implementation should be much more complicated, and the
resulting order of the messages in the summary could be confusing,
because messages could have arrived out of order, which happens when,
for example, the email server was temporarily off-line.  If the
messages are sorted by date/time, the order will be reasonable
(barring clock mismatches).

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

[Clément Pit-Claudel]

On 8/31/21 12:03 PM, João Távora wrote:
> gain, 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.

I had a different experience: a large project I contribute to occasionally (Coq) moved to Github a few years ago, and that was followed with a significant increase in first-time contributions.

On a smaller scale, we have had many more (good) bug reports and pull requests for Proof General since we moved it to Github.

What this doesn't say is whether any "modern" workflow would have helped, or whether it was specifically Github, because of network effects (the barrier for contribution is lower if you already have an account and you are already familiar with the UI).

In fact, it doesn't even say whether it was the move itself that helped, or whether the move was an irrelevant manifestation of a more welcoming approach and a general effort to attract contributions.

Re: Gitlab Migration

[John Yates]

On Tue, Aug 31, 2021 at 7:50 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> 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.

I agree with Dmitry.  I would love to see the community be
more open to change, be it key bindings or new workflows.

I have been using Emacs since Lucid-Emacs at Apollo
Computer in the mid-1980s.  I have a massive .init file.
Still, I welcome change and evolution.  Other technologies
that I use on a daily basis evolve, even those for which I
develop muscle memory (e.g. my smart phone).  I accept
such change and can even acknowledge that some of it
represents progress over time.  Other changes I put up
with just to track the herd and not be left behind.

I wish that we were not so determined to proudly go it alone.
Our stances often remind me of this ditty:

    Here lies the body of William Jay,
    who died maintaining his right of way.
    He was right as he sped along—
    but he's just as dead as if he'd been wrong.

Any changes that can attract new blood have my vote.

Re: Gitlab Migration

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Tue, 31 Aug 2021 12:21:40 -0400
> Cc: Richard Stallman <rms@gnu.org>, Eli Zaretskii <eliz@gnu.org>, danflscr@gmail.com, 
> 	Philip Kaludercic <philipk@posteo.net>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> I have been using Emacs since Lucid-Emacs at Apollo
> Computer in the mid-1980s.  I have a massive .init file.
> Still, I welcome change and evolution.  Other technologies
> that I use on a daily basis evolve, even those for which I
> develop muscle memory (e.g. my smart phone).  I accept
> such change and can even acknowledge that some of it
> represents progress over time.  Other changes I put up
> with just to track the herd and not be left behind.
> 
> I wish that we were not so determined to proudly go it alone.

Please don't exaggerate.  Representing Emacs development as something
that didn't change since the 1980s is factually incorrect and
practically not helpful.

> Any changes that can attract new blood have my vote.

Everyone agrees with general principles, the disagreements begin when
we consider the details.  E.g., "any changes" is definitely a
generalization that is not very useful in practice.

Re: Gitlab Migration

[João Távora]

On Tue, Aug 31, 2021 at 5:15 PM Clément Pit-Claudel
<cpitclaudel@gmail.com> wrote:
>
> On 8/31/21 12:03 PM, João Távora wrote:
> > gain, 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.
>
> I had a different experience: a large project I contribute to occasionally (Coq) moved to Github a few years ago, and that was followed with a significant increase in first-time contributions.
>
> On a smaller scale, we have had many more (good) bug reports and pull requests for Proof General since we moved it to Github.
>
> What this doesn't say is whether any "modern" workflow would have helped, or whether it was specifically Github, because of network effects (the barrier for contribution is lower if you already have an account and you are already familiar with the UI).
>
> In fact, it doesn't even say whether it was the move itself that helped, or whether the move was an irrelevant manifestation of a more welcoming approach and a general effort to attract contributions.

Yes, something very similar happened when I and a colleague moved
SLIME to GitHub
around 2014, when it was almost moribund. It revitalized the project
in a way, i.e.
it increased the number of bug reports that were effectively reported,
but it didn't really
bring momentous changes or advances to the software  (I ended up doing
those in a
fork of it, which is now SLY).  It's certainly better there than in
the those moribund
Common Lisp venues and CVS.

I think you make good points, anyway.

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

[Dmitry Gutov]

On 31.08.2021 19:37, Eli Zaretskii wrote:

>> Any changes that can attract new blood have my vote.
> 
> Everyone agrees with general principles,

With "any changes that can attract new blood", really?

> the disagreements begin when
> we consider the details.  E.g., "any changes" is definitely a
> generalization that is not very useful in practice.

FWIW, I mentioned particular categories of changes.

Or as I've been saying, we love additions but hate changes. This is a 
distinction that's easy to conceptualize, and we could start a 
discussion into changing this, or at least instituting some procedures 
for making important non-backward-compatible changes. Nobody with power 
to make decisions has shown any interest, however.

Re: Gitlab Migration

[Dmitry Gutov]

On 31.08.2021 19:03, João Távora wrote:
> 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.

FWIW, I'm really more interested in UI changes than workflow changes (my 
email mentioned both). A move that will at least bring us a functioning 
bug tracker is a plus in my book.

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

That's an odd statement. First of all, why would quality of code change? 
Whatever linters you institute to run on a CI, can run locally as well. 
Quality of discussions is also on you.

gitlab/github/gogs/etc give you tools to make code reviews easier, and 
an opportunity to attract many new contributors, but then it's on you to 
make them feel welcome, so that they stay around.

Better "quality of code" can result from attracting strong new 
contributors, and looking at how, for example, bug#47711 ended up (a 
smart, prolific developer who has authored a number of popular 
third-party packages in the same area has now sworn off contributing to 
Emacs), or the atmosphere around Eglot, I find it hard to trust your 
experience here.

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

Sure, let's keep the barriers to contribution, both formal and informal 
ones. That will serve us well.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: rms@gnu.org, danflscr@gmail.com, philipk@posteo.net,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 31 Aug 2021 22:17:10 +0300
> 
> Or as I've been saying, we love additions but hate changes.

Emacs is an old and _stable_ package.  "Stable" means just that:
features burned into users' muscle memory don't just change every
weekend.  So we do it slowly, cautiously, and preferably via opt-in
features, because we respect our users and their habits.  It is
maddening to have to re-learn your editor just because you've
upgraded.

> we could start a discussion into changing this, or at least
> instituting some procedures for making important
> non-backward-compatible changes.

We _have_ procedures for making backward-incompatible changes, and we
use those procedures all the time.

> Nobody with power to make decisions has shown any interest, however.

Please forgive me the lecture that you don't need: talking never moves
anything in Emacs, never did, never will.  Change in Emacs comes when
motivated individuals sit down and do the work.  If someone presents
the code to make some backward-incompatible change in a way that
leaves it opt-in, the resistance is likely to be much lower than it
may seem when such changes are just "discussed".  For the same reason,
it is hard to show interest in an Nth theoretical discussion that
never results in any code; by contrast, having a code presented to us
_requires_ "The Powers That Be" to make decisions, whether they want
it or not.

Backward-incompatible changes in the _defaults_ take much longer and
might be met with more resistance, that's true.  But this is a feature
in Emacs; see above.  My advice is not to insist on having each
incompatible change to become the default the moment it is coded: it
will in the long run make such changes much easier to introduce, and
everyone wins.

Re: Gitlab Migration

[John Yates]

On Tue, Aug 31, 2021 at 3:17 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> With "any changes that can attract new blood", really?

Sure.  Mine is not the only vote and carries much less
weight than some.  But, as a first approximation, any
serious proposal that would "attract new blood" almost
surely, has my support.

Re: Gitlab Migration

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> A move that will at least bring us a functioning bug tracker is a plus
> in my book.

We are in agreement. 

> That's an odd statement. First of all, why would quality of code
> change? Whatever linters you institute to run on a CI, can run locally
> as well. Quality of discussions is also on you.
>
> gitlab/github/gogs/etc give you tools to make code reviews easier, and
> an opportunity to attract many new contributors, but then it's on you
> to make them feel welcome, so that they stay around.

I'm telling you that code reviews and the ensuing code quality didn't
become specially easier when comparing GH/GL to non-GH/GL.  There were
code reviews with and without these platforms and there were newcomers
with and without them.  There was no perceptual (from my POV) difference
in discussion or proficiency.  This was presented as anecdoctal evidence
and my subjective judgement, of course.  If it sounds "odd" to you, it's
totally understandable.

> Better "quality of code" can result from attracting strong new
> contributors, and looking at how, for example, bug#47711 ended up (a
> smart, prolific developer who has authored a number of popular
> third-party packages in the same area has now sworn off contributing
> to Emacs),

Shooting from the hip, heh :-) Well, if you are so troubled by bug#47711
I encourage you to reply there.  Not only am I waiting your promised
feedback but also it's got absolutely nothing do to with this
thread. (IIUC the participants in that bug are familiar and proficient
with Emacs's workflows and practices).

Bugs don't have to "end up" anywhere without discussion, opposition or
study of alternatives: Daniel wants to deprecate a part of Emacs and
substitute it with a new one.  To my eyes, that's a good idea.  I merely
had time and means to demonstrate that his patch made Icomplete run
about 10% slower.  He later thanked me for spotting this regression.  I
also asked to split up the patch, which is very long and seemed to do
many things at once, so that I could more easily review it.  After
providing an alternative patch, I'm waiting from you and Daniel a
translucid demonstration of the somewhat callous claims leveled at it.
It's short and speeds up icomplete-mode and flex by about 30%, as
requested by none other than you.  Indeed, I have been waiting for these
things and other things for about 2 weeks, and haven't heard a peep.

> or the atmosphere around Eglot, I find it hard to trust your
> experience here.

Intrigued about the amospheric conditions around Eglot.  Should I bring
umbrella or sunscreen?

>> 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.
> Sure, let's keep the barriers to contribution, both formal and
> informal ones. That will serve us well.

I'll just make one last effort to explain my position here.  You may
legitimately think they e-mail, debbugs, non-modern websites etc are
barriers, that they are "bad" to newcomers.  That is true, and I agree
in part, but it is not the whole story.  Some of us are trying to tell
you that that manichaeism is an oversimplification: these things are
_also_ "good", they are points of interest and value to veterans and at
least a certain class of newcomers, perhaps the newcomers that Emacs is
interested in attracting.

It goes both ways, too: I was once a newcomer and the development
practices that I've learned (and still learn) here specifically over the
years have been very valuable in my programming career.  Just some
examples: the deft use of boring old email to structure programming
ideas is very very good here.  The much-ridiculed GNU-style ChangeLog
commit messages are a superb way to review one's own work before
presenting it.  And I don't miss emojis, thumbsup likes and animated
gifs a bit, have to say.

João

Re: Gitlab Migration

[John Yates]

On Tue, Aug 31, 2021 at 3:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Emacs is an old and _stable_ package.  "Stable" means just that:
> features burned into users' muscle memory don't just change every
> weekend.

At 70, I still count myself as an "early adopter".  I am unlikely to
accept having my world and habits disrupted every weekend.  But
with somewhat longer time scales (e.g. Ubuntu's six month and
Android yearly cadences) I am quite comfortable.

> So we do it slowly, cautiously, and preferably via opt-in
> features, because we respect our users and their habits.

Ah, but the model is opt-in to change, not opt-out.  Thus
opponents of change start off with an advantage and set
the terms of debate.

Other models are possible:
* Long term releases with sunset dates
* Previews of features that will become defaults with opt-out
* ?

Anyway, thank you, Eli, for your long, thoughtful reply and
for your project leadership.

/john

Re: Gitlab Migration

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Wed, 1 Sep 2021 07:35:10 -0400
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Richard Stallman <rms@gnu.org>, danflscr@gmail.com, 
> 	Philip Kaludercic <philipk@posteo.net>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > Emacs is an old and _stable_ package.  "Stable" means just that:
> > features burned into users' muscle memory don't just change every
> > weekend.
> 
> At 70, I still count myself as an "early adopter".  I am unlikely to
> accept having my world and habits disrupted every weekend.  But
> with somewhat longer time scales (e.g. Ubuntu's six month and
> Android yearly cadences) I am quite comfortable.

How long is "somewhat longer" is obviously very personal and differs
between people.  I've met people for whom 6 months is a blink of an
eye.

> > So we do it slowly, cautiously, and preferably via opt-in
> > features, because we respect our users and their habits.
> 
> Ah, but the model is opt-in to change, not opt-out.  Thus
> opponents of change start off with an advantage and set
> the terms of debate.

I said "preferably opt-in".  We do make opt-out changes as well, just
less so, for the reasons I tried to explain.

> Other models are possible:
> * Long term releases with sunset dates
> * Previews of features that will become defaults with opt-out
> * ?

Someone™ should step forward and volunteer to manage such models.  If
and when they do, I don't see why not, at least not in principle.

> Anyway, thank you, Eli, for your long, thoughtful reply and
> for your project leadership.

You are welcome.

Re: Gitlab Migration

[Maxim Nikulin]

On 27/08/2021 08:01, Tim Cross wrote:
> Dmitry Gutov writes:
> 
>> 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.

Duplication of notifications to a messenger + mail is definitly a source 
of annoyance and ability to configure notifications in its source is a 
handy feature.

Narrowing to email, it may be used by virtually everyone but much less 
people are able to setup mail filters accordingly to personal priorities 
of notifications. Ideally such tuning should be minimized, actually 
there is no common denominator for this kind of preferences, so some 
settings are unavoidable duty of users.

What is really sour is that notifications are often quite inconvenient 
for filtering.

I had positive experience with gerrit + redmine + sieve filters. Due to 
reach set of extended headers in mail messages it was possible to choose 
mail box based on committer, issue assignee or status change, result of 
build+tests. Failure of build of a my commit is rather important event. 
On the other hand I rarely visited mailbox with notification that build 
is started for someone else or even for me. A few iterations of filter 
tuning was stored in git.

For notifications from bitbucket and jira it was much harder or even 
impossible to determine the precise reason and configuring filters in 
outlook was a pain. There was no convenient set of X-... headers. I did 
not mange to approach to configuration that I considered as convenient 
from my previous experience.

Messengers are horror in the sense of customization and filtering of 
notifications. Channels are hard coded, instruments to suppress some 
messages are rather rude.

To avoid suffer due to email, development tools should be created with 
care and their users should be aware of features like filtering.

P.S. I have not checked whether notifications from SourceHut have reach 
enough metadata.

Re: SourceHut for Emacs (was: Gitlab Migration)

[Yuan Fu]

> On Aug 31, 2021, at 5:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Mon, 30 Aug 2021 13:17:42 -0700
>> Cc: emacs-devel@gnu.org
>> 
>>> So at this stage, I personally don't see much point looking for other
>>> tools.  Instead I'm just wondering how to get us to use SourceHut
>>> (i.e. how to resolve the problems that might stand in the way, such as
>>> getting an instance up and running on GNU machines, starting to use it
>>> "on the side" to see in practice what issues we'll need
>>> fixed/improved/added before we can really switch, etc...).
>>> 
>>> An obvious first issue is the one seen in Theodor's example:
>>> https://lists.sr.ht/~theo/public-inbox/%3Cm1r1edold3.fsf%40Frende-MacBook.lan%3E
>>> where the rendering of this email in the web interface completely hides
>>> the actual patch being sent.
>>> 
>> 
>> Maybe we could contact them and discuss the potential to move. They probably would be very happy to assist us, since Emacs can be an advertisement and testimony for their product.
> 
> They are already participating in these discussions here.

Please forgive my ignorance, then ;-)

Yuan

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

  > The above is literally my observations 
  > on our decision-making in the area.

The substance of your statement may be based on observations.  It may
be a valid position -- I don't know.  But the way you said it is
sarcastic:

  > making sure that each
  > key binding that has been with us for a number of years, is left
  > unchanged for ever.

You have not had time to observe anything last "for ever".
None of us ever does.  That is an exaggeration, and it is sarcasm.

  >           We hate to risk inconveniencing existing users.

That is also a sarcastic way of making the point.

  > appealing to newcomers (and/or trying to adopt contemporary usability
  > practices) is of much lesser priority than,

Perhaps we do give it lower priority.  Perhaps it correct to do so.
It isn't bad to argue for the other position, but doing so with sarcasm
makes it more of a fight.

Sarcasm increases antagonism regardless of whether the point is valid.

If you don't try to avoid sarcasm, you will continue bringing acrimony.
Instead of convincing people, you're likely to entrench their positions.
Please agree to help keep discussion friendly.

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

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

  > Once you request a summary based on filtering, the unfiltered summary
  > is gone.  So I can no longer quickly and conveniently look for
  > messages that were filtered out by scrolling the summary buffer or by
  > searching in it.

I see your point (though M-s will search through all messages, regardless of
the summary).  I don't notice this because I never make an unfiltered summary.

This suggests we should have a convenient way to make multiple
summaries of a single Rmail buffer, and keep them in parallel.
What do you think of that?

  > > A summary in Rmail doesn't stop you from looking at messages not
  > > included in it.  I do that frequently.

  > Can you tell how do you do that?

If you have the Rmail buffer selected, the summary does not affect the
ordinary Rmail commands.  They move through the whole file unaffected
by the summary.

  > And I have one additional question about your request to have a
  > summary-by-thread: is it okay to request that the user first sorts the
  > messages by date (C-c C-s C-d), before summarizing the thread?

That would be a pain in the neck for me.  I don't want to reorder
RMAIL file.

If you go through all the messages making a Lispy data structure that
records the most important header fields of each, and its message
number, it would be pretty easy to sort that data structure and then
find the threads in it.  Then you could display the thread summary
either by send order or by order in the Rmail file.

Hmm, it would be interesting to make the Rmail sort commands operate
on a summary buffer by sorting the summary instead of the Rmail file.

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

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

  > Ah, but the model is opt-in to change, not opt-out.  Thus
  > opponents of change start off with an advantage 

That's ok.  We don't have any obligation to be "fair" to 
wishes for changes that other users don't like.

  > * Previews of features that will become defaults with opt-out

It is useful to offer previews of changed interfaces, but whether
to make the other interface the default some day is a question we
should decide after seeing users' reaction -- not in advance.


-- 
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: SourceHut for Emacs (was: Gitlab Migration)

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Wed, 1 Sep 2021 15:40:07 -0700
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  Emacs Devel <emacs-devel@gnu.org>
> 
> >> Maybe we could contact them and discuss the potential to move. They probably would be very happy to assist us, since Emacs can be an advertisement and testimony for their product.
> > 
> > They are already participating in these discussions here.
> 
> Please forgive my ignorance, then ;-)

No need to apologize, and nothing to forgive.

Re: rmail threading

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Sep 2021 23:37:51 -0400
> 
> This suggests we should have a convenient way to make multiple
> summaries of a single Rmail buffer, and keep them in parallel.
> What do you think of that?

That'd help, yes.  Still, the need to switch between different summary
buffers is less convenient, IMO.

>   > > A summary in Rmail doesn't stop you from looking at messages not
>   > > included in it.  I do that frequently.
> 
>   > Can you tell how do you do that?
> 
> If you have the Rmail buffer selected, the summary does not affect the
> ordinary Rmail commands.  They move through the whole file unaffected
> by the summary.

Yes, of course.  But that means you move by single message, which is
very inconvenient when you search for something.  M-s could help, but
M-s still leaves you looking at the inbox through a single-message
loophole.

>   > And I have one additional question about your request to have a
>   > summary-by-thread: is it okay to request that the user first sorts the
>   > messages by date (C-c C-s C-d), before summarizing the thread?
> 
> That would be a pain in the neck for me.  I don't want to reorder
> RMAIL file.

Too bad.

> If you go through all the messages making a Lispy data structure that
> records the most important header fields of each, and its message
> number, it would be pretty easy to sort that data structure and then
> find the threads in it.  Then you could display the thread summary
> either by send order or by order in the Rmail file.

Yes, that's more or less what Gnus does.  So I think the best way of
doing that would be to borrow the code from Gnus.  I hoped to avoid
that complexity, including the need to process all the threads before
one can walk a single thread.  I usually leave in INBOX old messages
that I need to consult frequently, so my INBOX file is very large, and
processing all of it for threads could take a while.

Re: Gitlab Migration

[Alexander Adolf]

dick <dick.r.chiang@gmail.com> writes:

> * Newcomer suggests PR-based workflow citing youth.  Check.
>
> * Veterans chime in, citing the obvious reasons-for and the
> political reasons-against.  Check.
>
> * EZ cites his *sui generis* argument that a web-based workflow is actually
> *more* work than mailing patches around.  Check.
>
> * Someone announces his intention to begin the necessary work.  Check.
>
> * Someone remarks how discussion on emacs-devel repeats itself.  Now checked.

Nice. Thanks for the laugh!

But back to serious business. This is a long thread (297 on m y machine
at the time of this writing), and - in all honesty - that's not entirely
unexpected.

There is merit in both, keeping long-timers happy, and in lowering the
perceived entry barriers for potential new contributors. I would assume
that the smallest common denominator, which we all can agree to, would
be: "must not alienate/deter neither long-timers, nor newbies".

Thus, the magic words would seem to be "backwards compatibility", and
"migration path".

"backwards compatibility" := Everything that works via email now, must
equally work via email with the new system.

"migration path" := It must be possible to try out one function on the
new system, whilst still using all other functions via email.

If the new system has more functions, or makes some things easier, then
there could even be an incentive for the long-timers to look into the
new system.

Finally, a remark on issue/bug tracking. I have used a great many
trackers, and debbugs and Bugzilla stand out from the crowd. By a huge
margin. The differentiating feature is blocks/depends-on. Many issue
trackers (including those in the various git hosting platforms) lack
this feature altogether. Those trackers who have it, often provide a
limited flavour, e.g. limiting it to one level (i.e. a bug that blocks
another bug, can itself not be blocked by other bugs), or make it
awkward to use (e.g. you have to create a new bug as a subtask of
an existing one, and existing bugs cannot be made into subtasks any more
once created).

Hence my plea: debbugs ought to remain part of whatever any new system
might be.

Just my two cents anyway.


Many thanks and looking forward to your thoughts,

  --alex

Re: Gitlab Migration

[Alexander Adolf]

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> [...]
> Finally, a remark on issue/bug tracking. I have used a great many
> trackers, and debbugs and Bugzilla stand out from the crowd. By a huge
> margin. The differentiating feature is blocks/depends-on. Many issue
> trackers (including those in the various git hosting platforms) lack
> this feature altogether. Those trackers who have it, often provide a
> limited flavour, e.g. limiting it to one level (i.e. a bug that blocks
> another bug, can itself not be blocked by other bugs), or make it
> awkward to use (e.g. you have to create a new bug as a subtask of
> an existing one, and existing bugs cannot be made into subtasks any more
> once created).
>
> Hence my plea: debbugs ought to remain part of whatever any new system
> might be.
> [...]

This discussion might be of interest in this context:

https://www.reddit.com/r/linux/comments/6qoqqi/gnome_wants_to_move_away_from_bugzilla_for_their/

Re: Gitlab Migration

[Eli Zaretskii]

> From: Alexander Adolf <alexander.adolf@condition-alpha.com>
> Cc: emacs-devel@gnu.org, danflscr@gmail.com, Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 02 Sep 2021 13:06:32 +0200
> 
> Thus, the magic words would seem to be "backwards compatibility", and
> "migration path".
> 
> "backwards compatibility" := Everything that works via email now, must
> equally work via email with the new system.

"Everything" is not a requirement, IMO.  It's nice to have, but we do
so much with email that requiring nothing to change is too much.
There should be a way to get notifications via email about the
important stuff, and there should be a way to participate in
discussing issues via email, including sending patches.

> "migration path" := It must be possible to try out one function on the
> new system, whilst still using all other functions via email.

Also not necessarily a requirement: it's okay if several functions
must be tried together.  Nice to have, certainly.

> Finally, a remark on issue/bug tracking. I have used a great many
> trackers, and debbugs and Bugzilla stand out from the crowd. By a huge
> margin. The differentiating feature is blocks/depends-on. Many issue
> trackers (including those in the various git hosting platforms) lack
> this feature altogether. Those trackers who have it, often provide a
> limited flavour, e.g. limiting it to one level (i.e. a bug that blocks
> another bug, can itself not be blocked by other bugs), or make it
> awkward to use (e.g. you have to create a new bug as a subtask of
> an existing one, and existing bugs cannot be made into subtasks any more
> once created).

Well, I agree that this is a good feature, but we don't use it too
much here.  So it is not high on my list of important features that
I'd consider as blocking the migration.

> Hence my plea: debbugs ought to remain part of whatever any new system
> might be.

Not if the new platform learns to support blocking, right?

Thanks.

Re: Gitlab Migration

[Daniel Brooks]

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

>> Indeed.  But I expect that whatever we end up with, we (that is, the
>> Emacs maintainers) won't have to click around, and won't have to
>> actually merge anything directly.  That is, I expect to have a command
>> in Emacs that says "get that pull request as a patch, apply it, and
>> don't commit it".  So that we can fix stuff up before committing -- as
>> before.
>
> Personally I tend to just use `git am` which *does* commit, and then
> I use `--amend` or `rebase` to perform adjustments.  Git supports that
> particularly well.

Yes, we can already do all of this without “click[ing] around” on a web
page. It’s quite easy to fetch the commits that the merge request is
referring to and then use Git locally to add more commits, amend the
existing commits, etc.

I recommend using Magit to do this without even leaving Emacs.

Incidentally, GitHub makes it even easier to do this because they add a
ref for every merge request.

db48x

Re: Gitlab Migration

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

> Way better than Github and its ilk, where I actually need to point my
> browser to the issue to see the comments.

I use the Magit and Forge packages to create, view, and reply to merge
requests from Github and Gitlab inside of Emacs. No web browser needed.

The only downside is that it doesn’t have an inbox–style view of new
comments that I might want to respond to. I’ve occasionally considered
using Forge as a Gnus backend, but haven’t yet gotten around to it.

db48x

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Brooks <db48x@db48x.net>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  cpitclaudel@gmail.com,
>   emacs-devel@gnu.org
> Date: Thu, 02 Sep 2021 08:30:55 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Way better than Github and its ilk, where I actually need to point my
> > browser to the issue to see the comments.
> 
> I use the Magit and Forge packages to create, view, and reply to merge
> requests from Github and Gitlab inside of Emacs. No web browser needed.

How do you know there was a merge request?

Re: Gitlab Migration

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I use the Magit and Forge packages to create, view, and reply to merge
>> requests from Github and Gitlab inside of Emacs. No web browser needed.
>
> How do you know there was a merge request?

You receive an e-mail notification with a link to the request.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 02 Sep 2021 18:19:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I use the Magit and Forge packages to create, view, and reply to merge
> >> requests from Github and Gitlab inside of Emacs. No web browser needed.
> >
> > How do you know there was a merge request?
> 
> You receive an e-mail notification with a link to the request.

Right, so email is still very much part of the workflow being
described, which is not the "pure" Github-based workflow.  That was
exactly my point.

Re: Gitlab Migration

[Yuri Khan]

On Thu, 2 Sept 2021 at 23:49, Eli Zaretskii <eliz@gnu.org> wrote:

> > > How do you know there was a merge request?
> >
> > You receive an e-mail notification with a link to the request.
>
> Right, so email is still very much part of the workflow being
> described, which is not the "pure" Github-based workflow.  That was
> exactly my point.

“Pure” GitHub-based workflow does not mean “no email whatsoever”.
GitHub users do not poll the website all day to see if they have any
pull requests or incoming comments — they react to mail notifications,
too.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 3 Sep 2021 00:01:03 +0700
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> > Right, so email is still very much part of the workflow being
> > described, which is not the "pure" Github-based workflow.  That was
> > exactly my point.
> 
> “Pure” GitHub-based workflow does not mean “no email whatsoever”.
> GitHub users do not poll the website all day to see if they have any
> pull requests or incoming comments — they react to mail notifications,
> too.

How could they react to email notifications, if, as we are being told,
they don't open their mailboxes?

Re: Gitlab Migration

[Yuri Khan]

On Fri, 3 Sept 2021 at 00:09, Eli Zaretskii <eliz@gnu.org> wrote:
> > “Pure” GitHub-based workflow does not mean “no email whatsoever”.
> > GitHub users do not poll the website all day to see if they have any
> > pull requests or incoming comments — they react to mail notifications,
> > too.
>
> How could they react to email notifications, if, as we are being told,
> they don't open their mailboxes?

Are we being told that?

People became unaccustomed to interacting with other people via email,
is all. Email has become (1) an authentication mechanism (“please
enter your email address”, “we’ve sent you a temporary login code or
link”), and (2) the vessel for incoming notifications leading you back
to a website (“you were mentioned in a thread on Slack and did not
react to it in five minutes, click here to read it”).

Re: Gitlab Migration

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Fri, 3 Sep 2021 00:24:31 +0700
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > How could they react to email notifications, if, as we are being told,
> > they don't open their mailboxes?
> 
> Are we being told that?

Yes, read all about it up-thread.

> People became unaccustomed to interacting with other people via email,
> is all. Email has become (1) an authentication mechanism (“please
> enter your email address”, “we’ve sent you a temporary login code or
> link”), and (2) the vessel for incoming notifications leading you back
> to a website (“you were mentioned in a thread on Slack and did not
> react to it in five minutes, click here to read it”).

So you are saying that, while picking up a verification code, they
also read the Github notifications they've got?  I'd be surprised.

Re: Gitlab Migration

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Right, so email is still very much part of the workflow being
>> > described, which is not the "pure" Github-based workflow.  That was
>> > exactly my point.
>> 
>> “Pure” GitHub-based workflow does not mean “no email whatsoever”.
>> GitHub users do not poll the website all day to see if they have any
>> pull requests or incoming comments — they react to mail notifications,
>> too.
>
> How could they react to email notifications, if, as we are being told,
> they don't open their mailboxes?

Sorry, I was not following this thread and just answered your question
based on what (I assume) fits your personal preferences.

On Github, e-mail is one method among others for receiving
notifications. You also can receive push notifications on your browser
and on your phone.

Re: Gitlab Migration

[Dmitry Gutov]

On 02.09.2021 20:09, Eli Zaretskii wrote:
>> From: Yuri Khan<yuri.v.khan@gmail.com>
>> Date: Fri, 3 Sep 2021 00:01:03 +0700
>> Cc: Óscar Fuentes<ofv@wanadoo.es>,
>>   Emacs developers<emacs-devel@gnu.org>
>>
>>> Right, so email is still very much part of the workflow being
>>> described, which is not the "pure" Github-based workflow.  That was
>>> exactly my point.
>> “Pure” GitHub-based workflow does not mean “no email whatsoever”.
>> GitHub users do not poll the website all day to see if they have any
>> pull requests or incoming comments — they react to mail notifications,
>> too.
> How could they react to email notifications, if, as we are being told,
> they don't open their mailboxes?
> 

I have told just the opposite in this very thread: they can and do use 
email, and routinely do that to view notifications about PRs, comments, 
and so on.

Not to mention general business emails, etc.

Re: Gitlab Migration

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Brooks <db48x@db48x.net>
>> Cc: Dmitry Gutov <dgutov@yandex.ru>,  cpitclaudel@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Thu, 02 Sep 2021 08:30:55 -0700
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Way better than Github and its ilk, where I actually need to point my
>> > browser to the issue to see the comments.
>> 
>> I use the Magit and Forge packages to create, view, and reply to merge
>> requests from Github and Gitlab inside of Emacs. No web browser needed.
>
> How do you know there was a merge request?

For the small projects I work on, it is sufficient to open the list of
merge requests from Magit. This is no different than opening my email
inbox to see if there are new emails. Unlike a real email inbox,
however, nothing is keeping track of which “messages” I have read; I
have to do that myself. For a large project I would want some other way
to keep track of that information.

Since there is no Gnus integration yet, I assume that most people read
their email notifications to find out what has changed, then use Forge
or some other means to act on that information. Now that I think about
it, I think that forges should provid all the merge requests via IMAP,
rather than inventing yet another rest api.

db48x

Re: Gitlab Migration

[Dmitry Gutov]

On 02.09.2021 06:38, 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. ]]]
> 
>    > Ah, but the model is opt-in to change, not opt-out.  Thus
>    > opponents of change start off with an advantage
> 
> That's ok.  We don't have any obligation to be "fair" to
> wishes for changes that other users don't like.

We're literally under no "obligation" to anything. But is it a good outcome?

Under the current system a sufficiently loud single user can effectively 
veto any change. Or at least 3-4 such users.

But even 5 or 10 users are in no way representative of our entire user base.

Representation of the Emacs userbase on emacs-devel

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Under the current system a sufficiently loud single user can
> effectively veto any change. Or at least 3-4 such users.
>
> But even 5 or 10 users are in no way representative of our entire user base.

But don't they represent other users? The fundamental issue underlying
all of this is that different people have different ideas of who is
using Emacs. We cannot say if emacs-devel is representative of the
entire user base or not. One can certainly sense differences when
comparing it to different communities (HN, /r/emacs, /emg/, popular
bloggers, various developer groups, ...), but these all tend to skew
towards Emacs enthusiasts, so they cannot be seen as reliable metric
either.

I agree that the ability for a handful of users to veto changes can be
annoying, but how harmful it is should be decided on a case-to-case
basis. Do you (or anyone else) have any examples of where one or just a
few people prevented a change from being made that you think would have
been good in your eyes?

-- 
	Philip Kaludercic

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 02.09.2021 23:35, Philip Kaludercic wrote:
> But don't they represent other users?

Of course they do. But what proportion of users? By the virtue of simply 
being on this mailing list, we are already skewed toward an older, more 
conservative crowd. And then we make it a veto power if *some* 5 people 
from said crowd disapprove.

> The fundamental issue underlying
> all of this is that different people have different ideas of who is
> using Emacs. We cannot say if emacs-devel is representative of the
> entire user base or not. One can certainly sense differences when
> comparing it to different communities (HN,/r/emacs, /emg/, popular
> bloggers, various developer groups, ...), but these all tend to skew
> towards Emacs enthusiasts, so they cannot be seen as reliable metric
> either.

I'm not saying it's easy, but we don't even try. We don't try to make 
whole-userbase polls (we talked about it a few times over last years, 
and never went through), we don't make decisions based on polls made by 
other people (only one exception that comes to mind is Lars' initiative 
regarding ring-bell-function), and we never make decisions based on what 
"others" do. Even when it is clear that when all other editors have made 
a certain technical decision in a different way than we did, decades 
ago, we stick with it. And I'm not even talking about major disruptive 
changes like a switch to CUA would be.

> I agree that the ability for a handful of users to veto changes can be
> annoying, but how harmful it is should be decided on a case-to-case
> basis. Do you (or anyone else) have any examples of where one or just a
> few people prevented a change from being made that you think would have
> been good in your eyes?

Every recent discussion about a UI change has been like that. A 
suggestion is made, arguments added, some people disagree saying it 
won't jive with their workflow (never mind that Emacs is, in fact, 
customizable), and that's it. For example, the thread about bindings for 
undo-only+undo-redo, which would make Emacs friendlier to any user with 
experience in about any other text editing program out there.

Or take indent-tabs-mode, an old pet peeve of mine: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322 I can talk about 
contemporary practice, whole-industry polls, threads with personal 
opinions anywhere, threads with people expressing confusion about the 
current default behavior... but a few people say a change will be 
inconvenient -- and it moves nowhere.

Re: Representation of the Emacs userbase on emacs-devel

[Qiantan Hong]

> Under the current system a sufficiently loud single user can
> effectively veto any change. Or at least 3-4 such users.
> 
> But even 5 or 10 users are in no way representative of our entire user base.

Let reason speak, not individual.

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

  > Any changes that can attract new blood have my vote.

You can argue for that, and your arguments can in general have
influence.  But it isn't a matter of voting.  That's not how
we make the decisions about Emacs.

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

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

  > Sure, let's keep the barriers to contribution, both formal and informal 
  > ones. That will serve us well.

One way to encourage people to stick around is to be kind in the
discussion list.  For instance, not to use sarcasm.  Whatever point
you wish to make, you can make it in a kind way.

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

[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

[Eli Zaretskii]

> Cc: eliz@gnu.org, danflscr@gmail.com, philipk@posteo.net,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 2 Sep 2021 22:02:25 +0300
> 
> >    > Ah, but the model is opt-in to change, not opt-out.  Thus
> >    > opponents of change start off with an advantage
> > 
> > That's ok.  We don't have any obligation to be "fair" to
> > wishes for changes that other users don't like.
> 
> We're literally under no "obligation" to anything. But is it a good outcome?
> 
> Under the current system a sufficiently loud single user can effectively 
> veto any change. Or at least 3-4 such users.
> 
> But even 5 or 10 users are in no way representative of our entire user base.

Opt-in changes are an effective way of dealing with such resistance.
They cannot be easily vetoed.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Opt-in changes are an effective way of dealing with such resistance.
> They cannot be easily vetoed.

We have previously discussed extending the concept of a "theme", which
is currently basically just visual.  I think the way forward here is to
allow people to create opinionated views on how Emacs should work (from
keystrokes on up to basically...  anything), and include these in Emacs.

New users, when starting Emacs, would then be able to choose between,
say, five of these mega-themes on the start-up screen by just clicking
them.

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

Re: Representation of the Emacs userbase on emacs-devel

[Eli Zaretskii]

> Cc: rms@gnu.org, John Yates <john@yates-sheets.org>, eliz@gnu.org,
>  danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 01:39:05 +0300
> 
> > I agree that the ability for a handful of users to veto changes can be
> > annoying, but how harmful it is should be decided on a case-to-case
> > basis. Do you (or anyone else) have any examples of where one or just a
> > few people prevented a change from being made that you think would have
> > been good in your eyes?
> 
> Every recent discussion about a UI change has been like that. A 
> suggestion is made, arguments added, some people disagree saying it 
> won't jive with their workflow (never mind that Emacs is, in fact, 
> customizable), and that's it. For example, the thread about bindings for 
> undo-only+undo-redo, which would make Emacs friendlier to any user with 
> experience in about any other text editing program out there.

That's only true for changes of the default behavior, and key bindings
are examples of such a change, at least the way they are proposed.
There was talk about introducing a minor mode which would then be free
to make controversial changes, including key bindings, but no one
stepped forward to write such a mode.  Which I think is a pity, given
how easy it should be to do that, and how many problems and
frustrations it could potentially solve.

Once again: significant changes in behavior should generally be
introduced as opt-in features, then the friction will be much lower
and in the long run we could perhaps introduce changes at a faster
pace.  Thus, people who insist on making changes in the default
behavior are shooting themselves (and Emacs, if their opinions are
right) in the foot, IME.

> Or take indent-tabs-mode, an old pet peeve of mine: 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322 I can talk about 
> contemporary practice, whole-industry polls, threads with personal 
> opinions anywhere, threads with people expressing confusion about the 
> current default behavior... but a few people say a change will be 
> inconvenient -- and it moves nowhere.

indent-tabs-mode is an existing option, so your insistence on turning
it on by default in the face of resistance is ... peculiar.  We did
turn it on in some of our sources.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  philipk@posteo.net,  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>
> Date: Fri, 03 Sep 2021 13:26:13 +0800
> 
> Can Emacs have "experimental" and "stable" dev branches with the former
> being more open to "popular" changes?

It certainly can, if Someone™ steps forward to take care of them:
review patches, decide which features fit and which don't, perhaps
produce snapshots, etc.  We'd also need to discuss procedures how
stuff is merged from those branches to master.  Volunteers are welcome
to work on this.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  philipk@posteo.net,
>   danflscr@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  john@yates-sheets.org
> Date: Fri, 03 Sep 2021 08:12:04 +0200
> 
> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual.  I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically...  anything), and include these in Emacs.
> 
> New users, when starting Emacs, would then be able to choose between,
> say, five of these mega-themes on the start-up screen by just clicking
> them.

Sure, SGTM.  I hope such themes will be developed and added to Emacs.
That's one way of having several opt-in changes in behavior that can
be turned on and off with a single command.

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

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Opt-in changes are an effective way of dealing with such resistance.
>> They cannot be easily vetoed.
>
> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual.  I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically...  anything), and include these in Emacs.

Conversely, themes could also be used to reset changes. You could have
an Emacs-21, Emacs-27, XEmacs theme bundled by default, allowing people
to reset the defaults to whatever they are used to.

> New users, when starting Emacs, would then be able to choose between,
> say, five of these mega-themes on the start-up screen by just clicking
> them.

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Dmitry Gutov <dgutov@yandex.ru>,
>   danflscr@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  john@yates-sheets.org
> Date: Fri, 03 Sep 2021 07:28:29 +0000
> 
> Conversely, themes could also be used to reset changes. You could have
> an Emacs-21, Emacs-27, XEmacs theme bundled by default, allowing people
> to reset the defaults to whatever they are used to.

Yes.  This was all discussed in the past, I just hope it will happen
some time soon.

Re: Gitlab Migration

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Dmitry Gutov <dgutov@yandex.ru>,
>>   danflscr@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org,
>>   monnier@iro.umontreal.ca,  john@yates-sheets.org
>> Date: Fri, 03 Sep 2021 07:28:29 +0000
>> 
>> Conversely, themes could also be used to reset changes. You could have
>> an Emacs-21, Emacs-27, XEmacs theme bundled by default, allowing people
>> to reset the defaults to whatever they are used to.
>
> Yes.  This was all discussed in the past, I just hope it will happen
> some time soon.

Ah, that is good to hear. The last time I was following one of the
discussions that proposed something like this, it seemed as though the
list was against it. I'll look into how successfully this could be done.

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> > We have previously discussed extending the concept of a "theme", which
> > is currently basically just visual.  I think the way forward here is to
> > allow people to create opinionated views on how Emacs should work (from
> > keystrokes on up to basically...  anything), and include these in Emacs.
> >
> > New users, when starting Emacs, would then be able to choose between,
> > say, five of these mega-themes on the start-up screen by just clicking
> > them.
>
> Sure, SGTM.  I hope such themes will be developed and added to Emacs.
> That's one way of having several opt-in changes in behavior that can
> be turned on and off with a single command.

I agree.  I have proposed to name such themes "profiles" in the past, see e.g.:

    https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg02032.html

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 07:57, Elias Mårtenson wrote:
> 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.

And there is a lot of good stuff we would take from any of the examples 
above, if we could: a module system, concurrency options, a faster 
regexp engine.

Looking at the popular options doesn't mean adopting their changes 
wholesale. But we don't even do the little stuff that we can.

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: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 03.09.2021 09:28, Eli Zaretskii wrote:
> That's only true for changes of the default behavior, and key bindings
> are examples of such a change, at least the way they are proposed.
> There was talk about introducing a minor mode which would then be free
> to make controversial changes, including key bindings, but no one
> stepped forward to write such a mode.  Which I think is a pity, given
> how easy it should be to do that, and how many problems and
> frustrations it could potentially solve.

Again you try to change any discussion of a change into an "addition". 
Something that wouldn't change anything in the default behavior.

> Once again: significant changes in behavior should generally be
> introduced as opt-in features, then the friction will be much lower
> and in the long run we could perhaps introduce changes at a faster
> pace.  Thus, people who insist on making changes in the default
> behavior are shooting themselves (and Emacs, if their opinions are
> right) in the foot, IME.

A lot of the time I'm talking about features that are already available. 
There's nothing to "introduce". But simply by having a wrong default we 
make Emacs harder to adopt with little benefit.

>> Or take indent-tabs-mode, an old pet peeve of mine:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322 I can talk about
>> contemporary practice, whole-industry polls, threads with personal
>> opinions anywhere, threads with people expressing confusion about the
>> current default behavior... but a few people say a change will be
>> inconvenient -- and it moves nowhere.
> 
> indent-tabs-mode is an existing option, so your insistence on turning
> it on by default in the face of resistance is ... peculiar.  We did
> turn it on in some of our sources.

Turning it off by default.

What's so peculiar about changing the behavior that flies in the face of 
existing practice in all programming languages out there? And which 
causes confusion in new users?

The way it is implemented made sense decades ago, but these days even 
users who want tabs for indentation are surprised by Emacs behavior in 
this area (because most of those users want 1 tab to mean 1 indentation 
level).

Re: Gitlab Migration

[Stefan Kangas]

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.

Many of the things some of us would like to see changed are not mainly
characterized by being particularly good. They are just different.

To give a concrete example, the kill ring is objectively better/more
powerful than the undo/redo you find in other text editors. It is also
harder to use, of course, but that's the territory Emacs thrives in.

But why is kill-region bound to C-w instead of C-x? I'm not really
advocating to change that key binding, but it is also clearly not
better. In fact, it is worse, precisely because one might as well use
the more familiar key binding. If we started Emacs from a clean slate
today, we would obviously have put kill-region on C-x.

We would in my opinion do well to take opportunities to make Emacs
behave more in line with modern user expectations. As the above
example shows, that is not always going to be easy. But there is no
reason to expect that careful work here would not lead to a better, if
slightly different, Emacs. (And if you hate the results, Emacs is
always going to be customizable. So you can have your cake, and eat it
too.)

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 09:12, Lars Ingebrigtsen wrote:
> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual.  I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically...  anything), and include these in Emacs.

A key bindings theme is a nice enough concept (for example, to create a 
native set of key bindings that follows the CUA convention). For that, 
indeed what's left is for someone to do the work.

Which is significant -- moving all current default bindings around to 
free up C-x, C-c, C-v, C-a and C-z is a big task, especially if one 
wants to interoperate with bindings made by third-party modes as well.

But I don't really want to migrate to CUA, personally. Do we not want 
our other users to enjoy undo-redo? Having a separate theme for every 
little proposed change seems silly.

And having a theme to just make indent-tabs-mode behavior sane, that 
would just be ridiculous.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But I don't really want to migrate to CUA, personally. Do we not want
> our other users to enjoy undo-redo? Having a separate theme for every
> little proposed change seems silly.

Yes, that's not what I think we should add (and as Stefan reminded us,
the previous time over we called the concept "profiles").  These would
be big things that change Emacs in sweeping, opinionated ways a la
Spacemacs, and there would only be half a dozen of them.

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

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:06, Lars Ingebrigtsen wrote:
> Yes, that's not what I think we should add (and as Stefan reminded us,
> the previous time over we called the concept "profiles").  These would
> be big things that change Emacs in sweeping, opinionated ways a la
> Spacemacs, and there would only be half a dozen of them.

We should not forget that, by maintaining those profiles, we would 
probably obligate any addition or change to the default key binding set 
to be adapted to all (or some) of these half a dozen profiles.

So the more we have of them, the more work we add to our contributors. 
Or potential bugs when we forget to do that.

That would basically extend to any method of bundling and maintaining 
sets of alternative configurations in the core.

Re: Representation of the Emacs userbase on emacs-devel

[Eli Zaretskii]

> Cc: philipk@posteo.net, rms@gnu.org, john@yates-sheets.org,
>  danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 13:34:38 +0300
> 
> On 03.09.2021 09:28, Eli Zaretskii wrote:
> > That's only true for changes of the default behavior, and key bindings
> > are examples of such a change, at least the way they are proposed.
> > There was talk about introducing a minor mode which would then be free
> > to make controversial changes, including key bindings, but no one
> > stepped forward to write such a mode.  Which I think is a pity, given
> > how easy it should be to do that, and how many problems and
> > frustrations it could potentially solve.
> 
> Again you try to change any discussion of a change into an "addition". 
> Something that wouldn't change anything in the default behavior.

Because I think that's a much better way forward, in the long run.
But if you want to insist on changing the defaults without the opt-in
changes first, I guess we will be having this discussion many times in
the future.

> > indent-tabs-mode is an existing option, so your insistence on turning
> > it on by default in the face of resistance is ... peculiar.  We did
> > turn it on in some of our sources.
> 
> Turning it off by default.
> 
> What's so peculiar about changing the behavior that flies in the face of 
> existing practice in all programming languages out there? And which 
> causes confusion in new users?
> 
> The way it is implemented made sense decades ago, but these days even 
> users who want tabs for indentation are surprised by Emacs behavior in 
> this area (because most of those users want 1 tab to mean 1 indentation 
> level).

You tried convincing in this before, and you failed.  IME, at least on
my daytime job, source code produced by people these days with popular
IDEs (not Emacs) includes TABs.  So at least my experience disagrees
with yours.  Which might explain why this change didn't happen.

Someone suggested to have "themes" in Emacs which could change the
defaults of many settings in one simple command.  Why not invest the
energy we waste in these endless discussions in making that happen?
It at least would make the changes easier for newbies, if nothing
else.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: philipk@posteo.net, danflscr@gmail.com, rms@gnu.org, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca, john@yates-sheets.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 13:59:37 +0300
> 
> A key bindings theme is a nice enough concept (for example, to create a 
> native set of key bindings that follows the CUA convention). For that, 
> indeed what's left is for someone to do the work.
> 
> Which is significant -- moving all current default bindings around to 
> free up C-x, C-c, C-v, C-a and C-z is a big task, especially if one 
> wants to interoperate with bindings made by third-party modes as well.
> 
> But I don't really want to migrate to CUA, personally. Do we not want 
> our other users to enjoy undo-redo? Having a separate theme for every 
> little proposed change seems silly.
> 
> And having a theme to just make indent-tabs-mode behavior sane, that 
> would just be ridiculous.

Figuring out these (and other) issues is indeed not trivial.  I still
hope someone will pick up the gauntlet, though.

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

[Dmitry Gutov]

On 03.09.2021 14:26, Eli Zaretskii wrote:
> Figuring out these (and other) issues is indeed not trivial.  I still
> hope someone will pick up the gauntlet, though.

Some of them can be figured by "someone" (e.g. the full resulting CUA 
layout), but please don't dodge the fundamental questions.

You reject the obvious and easy solution, after all.

Re: Gitlab Migration

[João Távora]

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

On Fri, Sep 3, 2021, 12:45 Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 03.09.2021 14:06, Lars Ingebrigtsen wrote:
> > Yes, that's not what I think we should add (and as Stefan reminded us,
> > the previous time over we called the concept "profiles").  These would
> > be big things that change Emacs in sweeping, opinionated ways a la
> > Spacemacs, and there would only be half a dozen of them.
>
> We should not forget that, by maintaining those profiles, we would
> probably obligate any addition or change to the default key binding set
> to be adapted to all (or some) of these half a dozen profiles.
>
> So the more we have of them, the more work we add to our contributors.
> Or potential bugs when we forget to do that.
>

Additionally, I would like to point out that we need reproducible bug
recipes from bug reporters, and the best way to get them is something like
Emacs -Q and its defaults. It is unavoidable that offering profiles as
suggested is going to have a negative impact in that department. But
perhaps it can be controlled if we have a small number of profiles and said
profiles are easily chosen from the command line and  the bug reporting
instructions should updated accordingly.

I support this profiles idea. I suggest these to start:

- default, the default
- space-hippie, or space-pinhead, a reference to spacemacs and to Emacs'
hidden 70s origins
- doctor-doom, likewise for doom emacs, couldn't find anything particularly
clever here, sorry.

The idea are that the latter two are reasonably familiar to people
migrating from those distributions. Not sure about vi kebinds though, ugh...

João

>

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

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 03.09.2021 14:19, Eli Zaretskii wrote:

>> Again you try to change any discussion of a change into an "addition".
>> Something that wouldn't change anything in the default behavior.
> 
> Because I think that's a much better way forward, in the long run.
> But if you want to insist on changing the defaults without the opt-in
> changes first, I guess we will be having this discussion many times in
> the future.

That is just side-stepping the question. There was never any 
disagreement about opt-in changes, and when it is feasible, we of course 
have taken that route.

>> What's so peculiar about changing the behavior that flies in the face of
>> existing practice in all programming languages out there? And which
>> causes confusion in new users?
>>
>> The way it is implemented made sense decades ago, but these days even
>> users who want tabs for indentation are surprised by Emacs behavior in
>> this area (because most of those users want 1 tab to mean 1 indentation
>> level).
> 
> You tried convincing in this before, and you failed.

That discussion is a great example of the problems I wrote about in this 
thread: we don't pay any attention to polls, hard statistics, articles 
and user posts (of which I produced plenty).

A few folks say "I don't like", and that's the end of it.

> IME, at least on
> my daytime job, source code produced by people these days with popular
> IDEs (not Emacs) includes TABs.

Does it include tabs in the same fashion as what is produced by Emacs? 
Which actually mixes tabs and spaces.

> So at least my experience disagrees
> with yours.  Which might explain why this change didn't happen.

I wasn't just listing my experience.

> Someone suggested to have "themes" in Emacs which could change the
> defaults of many settings in one simple command.  Why not invest the
> energy we waste in these endless discussions in making that happen?
> It at least would make the changes easier for newbies, if nothing
> else.

A few reasons. I don't really want to make Emacs more complex than it 
is. I usually strive to make the existing workflows simpler. There are 
only so many hours in a day.

Further: what kind of theme would include indent-tabs-mode set to nil? A 
theme called 'Sane Defaults'?

The users would need to find out about it somehow and then enable 
anyway, so what would make it different from having a custom option 
called indent-tabs-mode, which we have already?

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 14:41, Eli Zaretskii wrote:
> There, you have already a list of options to include in a suitably
> named "profile".  Why not add that to Emacs right now?

What would it be called?

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 15:11, João Távora wrote:
> - default, the default
> - space-hippie, or space-pinhead, a reference to spacemacs and to Emacs' 
> hidden 70s origins
> - doctor-doom, likewise for doom emacs, couldn't find anything 
> particularly clever here, sorry.
> 
> The idea are that the latter two are reasonably familiar to people 
> migrating from those distributions. Not sure about vi kebinds though, ugh...

That's a little silly: people don't usually migrate off those 
distributions to vanilla. Or those that do, can already choose the 
settings they want to carry over.

Spacemacs and Doom don't differ that much between themselves either, not 
in basic behaviors.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: larsi@gnus.org, philipk@posteo.net, danflscr@gmail.com, rms@gnu.org,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, john@yates-sheets.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:08:03 +0300
> 
> On 03.09.2021 14:26, Eli Zaretskii wrote:
> > Figuring out these (and other) issues is indeed not trivial.  I still
> > hope someone will pick up the gauntlet, though.
> 
> Some of them can be figured by "someone" (e.g. the full resulting CUA 
> layout), but please don't dodge the fundamental questions.

Which are?...

> You reject the obvious and easy solution, after all.

I don't think it's easy at all, perhaps not even obvious.

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 15:11, João Távora wrote:
>     We should not forget that, by maintaining those profiles, we would
>     probably obligate any addition or change to the default key binding set
>     to be adapted to all (or some) of these half a dozen profiles.
> 
>     So the more we have of them, the more work we add to our contributors.
>     Or potential bugs when we forget to do that.
> 
> 
> Additionally, I would like to point out that we need reproducible bug 
> recipes from bug reporters, and the best way to get them is something 
> like Emacs -Q and its defaults. It is unavoidable that offering profiles 
> as suggested is going to have a negative impact in that department. But 
> perhaps it can be controlled if we have a small number of profiles and 
> said profiles are easily chosen from the command line and  the bug 
> reporting instructions should updated accordingly.

I honestly think that having a "CUA profile" alone (which seems to be 
the most requested one), would take up enough of our collective effort, 
that we wouldn't want to have many of them.

Re: Representation of the Emacs userbase on emacs-devel

[Eli Zaretskii]

> Cc: philipk@posteo.net, rms@gnu.org, john@yates-sheets.org,
>  danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:11:44 +0300
> 
> On 03.09.2021 14:19, Eli Zaretskii wrote:
> 
> >> Again you try to change any discussion of a change into an "addition".
> >> Something that wouldn't change anything in the default behavior.
> > 
> > Because I think that's a much better way forward, in the long run.
> > But if you want to insist on changing the defaults without the opt-in
> > changes first, I guess we will be having this discussion many times in
> > the future.
> 
> That is just side-stepping the question.

Which question?

We are, I hope, interested mainly in making Emacs evolve and adapt to
the changing times and preferences.  I consider the way of introducing
changes as optional first to be a better way towards that goal,
including the goal to change the defaults.  And I explained in so many
words why and how.  How is that side-stepping the issue at hand?

> > You tried convincing in this before, and you failed.
> 
> That discussion is a great example of the problems I wrote about in this 
> thread: we don't pay any attention to polls, hard statistics, articles 
> and user posts (of which I produced plenty).
> 
> A few folks say "I don't like", and that's the end of it.

Show me a project where things are different, where the lead
developers cannot say "I don't like" (with arguments, which you forget
to mention, or prefer to dismiss or disregard, but they are still
there), and that's it.  This is how Free Software projects are being
developed, at least IME.  Emacs is not an outlier, it's right there in
the mainstream.

> > IME, at least on
> > my daytime job, source code produced by people these days with popular
> > IDEs (not Emacs) includes TABs.
> 
> Does it include tabs in the same fashion as what is produced by Emacs? 
> Which actually mixes tabs and spaces.

Why does it matter?  If we'd make the default use only TABs, would you
agree then?

> > So at least my experience disagrees
> > with yours.  Which might explain why this change didn't happen.
> 
> I wasn't just listing my experience.

Neither was I.  Anyone who'd look at the output of those IDEs will see
it, you don't need my "experience" to do that.  It's a fact.

> > Someone suggested to have "themes" in Emacs which could change the
> > defaults of many settings in one simple command.  Why not invest the
> > energy we waste in these endless discussions in making that happen?
> > It at least would make the changes easier for newbies, if nothing
> > else.
> 
> A few reasons. I don't really want to make Emacs more complex than it 
> is. I usually strive to make the existing workflows simpler. There are 
> only so many hours in a day.
> 
> Further: what kind of theme would include indent-tabs-mode set to nil? A 
> theme called 'Sane Defaults'?

Then I guess you won't be working on this any time soon.  Which is
perfectly okay; I hope someone else will.

> The users would need to find out about it somehow and then enable 
> anyway, so what would make it different from having a custom option 
> called indent-tabs-mode, which we have already?

The difference is that you need to choose among a small number of
themes, instead of among many dozens of individual options.  It makes
the customization simpler.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: philipk@posteo.net, yantar92@gmail.com, lokedhs@gmail.com,
>  danflscr@gmail.com, rms@gnu.org, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:12:08 +0300
> 
> On 03.09.2021 14:41, Eli Zaretskii wrote:
> > There, you have already a list of options to include in a suitably
> > named "profile".  Why not add that to Emacs right now?
> 
> What would it be called?

I don't know, but I don't think the name is the main issue.  The main
issue is to identify the settings many people would like to change,
then try to group them in some reasonable way.

Re: Gitlab Migration

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 3 Sep 2021 13:11:41 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, "Philip K." <philipk@posteo.net>, 
> 	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>, 
> 	John Yates <john@yates-sheets.org>
> 
> Additionally, I would like to point out that we need reproducible bug recipes from bug reporters, and the best
> way to get them is something like Emacs -Q and its defaults. It is unavoidable that offering profiles as
> suggested is going to have a negative impact in that department. But perhaps it can be controlled if we have
> a small number of profiles and said profiles are easily chosen from the command line and  the bug reporting
> instructions should updated accordingly.

I don't think this is a significant problem.  We could add the active
"profile(s)" to the report by report-emacs-bug, and that would take
care of reproducing the issues that don't happen in "emacs -Q".

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 15:27, Eli Zaretskii wrote:
>>> There, you have already a list of options to include in a suitably
>>> named "profile".  Why not add that to Emacs right now?
>> What would it be called?
> I don't know, but I don't think the name is the main issue.  The main
> issue is to identify the settings many people would like to change,
> then try to group them in some reasonable way.

It *is* an issue.

The problem with variables with indent-tabs-mode and 
require-final-newline is they affect Emacs's behavior in ways that 
aren't apparent to a new user, or to a beginner programmer. And then 
they can cause problems for the teammates who aren't even using Emacs.

Having a profile unassumingly called "Dmitry Gutov's Preferences" (who 
would want to enable THAT, right?), which would need to be enabled to 
avoid these issues, is a usability problem.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: Lars Ingebrigtsen <larsi@gnus.org>, "Philip K." <philipk@posteo.net>,
>  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>,
>  John Yates <john@yates-sheets.org>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:14:20 +0300
> 
> On 03.09.2021 15:11, João Távora wrote:
> > - default, the default
> > - space-hippie, or space-pinhead, a reference to spacemacs and to Emacs' 
> > hidden 70s origins
> > - doctor-doom, likewise for doom emacs, couldn't find anything 
> > particularly clever here, sorry.
> > 
> > The idea are that the latter two are reasonably familiar to people 
> > migrating from those distributions. Not sure about vi kebinds though, ugh...
> 
> That's a little silly: people don't usually migrate off those 
> distributions to vanilla. Or those that do, can already choose the 
> settings they want to carry over.

I'm not sure this is a silly idea: I see on Reddit people saying
they'd like switch from some distro to vanilla Emacs.  When they do
so, they could appreciate starting from something that's close to what
they are familiar with.

In any case, only offering such profiles could tell whether they are
useful or not.

> Spacemacs and Doom don't differ that much between themselves either, not 
> in basic behaviors.

Then maybe we need just one profile, not 2.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 15:32:10 +0300
> Cc: philipk@posteo.net, danflscr@gmail.com, rms@gnu.org, lokedhs@gmail.com,
>  yantar92@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca
> 
> On 03.09.2021 15:27, Eli Zaretskii wrote:
> >>> There, you have already a list of options to include in a suitably
> >>> named "profile".  Why not add that to Emacs right now?
> >> What would it be called?
> > I don't know, but I don't think the name is the main issue.  The main
> > issue is to identify the settings many people would like to change,
> > then try to group them in some reasonable way.
> 
> It *is* an issue.

It's an issue, but not the most important or urgent one.

> The problem with variables with indent-tabs-mode and 
> require-final-newline is they affect Emacs's behavior in ways that 
> aren't apparent to a new user, or to a beginner programmer. And then 
> they can cause problems for the teammates who aren't even using Emacs.
> 
> Having a profile unassumingly called "Dmitry Gutov's Preferences" (who 
> would want to enable THAT, right?), which would need to be enabled to 
> avoid these issues, is a usability problem.

I'd start by collecting the relevant settings.  E.g., if those 4 are
the only ones, or close to that, then perhaps a single profile named
"convenience" or somesuch would be enough.  But I suspect there are
many more, so we'd need to divide them into groups, and then name each
group accordingly.

Re: Gitlab Migration

[João Távora]

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

On Fri, Sep 3, 2021, 13:14 Dmitry Gutov <dgutov@yandex.ru> wrote:

> On
> > migrating from those distributions. Not sure about vi kebinds though,
> ugh...
>
> That's a little silly:


I merely meant to take those popular selection of preferences as a starting
point, and not necessarily your pet peeves. Seems perfectly reasonable to
me.

Also, I don't have to keep up with your constant and combatant rudeness.
Goodbye.

João

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

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 15:33, Eli Zaretskii wrote:
>> That's a little silly: people don't usually migrate off those
>> distributions to vanilla. Or those that do, can already choose the
>> settings they want to carry over.
> I'm not sure this is a silly idea: I see on Reddit people saying
> they'd like switch from some distro to vanilla Emacs.  When they do
> so, they could appreciate starting from something that's close to what
> they are familiar with.

"Migration to vanilla" usually means hand-crafting the config from 
scratch, knowing what they want, and what they do not, from e.g. Doom 
Emacs. And they usually continue using Evil as well, as well as many 
other third-party packages.

So a vanilla profile is not so important for them as it is for new 
users. But we could add some variation, of course, if someone wants to 
maintain it.

> In any case, only offering such profiles could tell whether they are
> useful or not.

Fair point.

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 15:45, Eli Zaretskii wrote:
>> The problem with variables with indent-tabs-mode and
>> require-final-newline is they affect Emacs's behavior in ways that
>> aren't apparent to a new user, or to a beginner programmer. And then
>> they can cause problems for the teammates who aren't even using Emacs.
>>
>> Having a profile unassumingly called "Dmitry Gutov's Preferences" (who
>> would want to enable THAT, right?), which would need to be enabled to
>> avoid these issues, is a usability problem.
> I'd start by collecting the relevant settings.  E.g., if those 4 are
> the only ones, or close to that, then perhaps a single profile named
> "convenience" or somesuch would be enough.  But I suspect there are
> many more, so we'd need to divide them into groups, and then name each
> group accordingly.

A private email reminded me of a certain suggestion that has been made 
in this area. And here is a possible twist on the proposal:

What if we do introduce the "profiles" feature, *and* we change our 
practice to alter the defaults more easily as well? Including radical, 
mutinous ones, like indent-tabs-mode -> nil. Not all of them, of course, 
but with more of an eye toward being useful for new users (violent 
discussions about the default values will continue, but will sometimes 
results in changes, too).

And to avoid the problems with Emacs's default moving forward, we 
introduce a profile called "Good Old Days" which the folks who prefer 
things to generally stay the same, would enable, just once. Going 
forward, every time we change some default, we would consider adding the 
previous value to that profile. Or even do that automatically.

Re: Gitlab Migration

[Eli Zaretskii]

> Cc: philipk@posteo.net, danflscr@gmail.com, rms@gnu.org, lokedhs@gmail.com,
>  yantar92@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 3 Sep 2021 16:26:41 +0300
> 
> What if we do introduce the "profiles" feature, *and* we change our 
> practice to alter the defaults more easily as well? Including radical, 
> mutinous ones, like indent-tabs-mode -> nil. Not all of them, of course, 
> but with more of an eye toward being useful for new users (violent 
> discussions about the default values will continue, but will sometimes 
> results in changes, too).
> 
> And to avoid the problems with Emacs's default moving forward, we 
> introduce a profile called "Good Old Days" which the folks who prefer 
> things to generally stay the same, would enable, just once. Going 
> forward, every time we change some default, we would consider adding the 
> previous value to that profile. Or even do that automatically.

This was discussed, but I don't think it flied.  maybe it will one
day, who knows?

Of course, given a profile that becomes the default, the "good old
days" counterpart of it is almost trivial to come up with.

Re: Gitlab Migration

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> What if we do introduce the "profiles" feature, *and* we change our
> practice to alter the defaults more easily as well? Including radical,
> mutinous ones, like indent-tabs-mode -> nil. Not all of them, of
> course, but with more of an eye toward being useful for new users
> (violent discussions about the default values will continue, but will
> sometimes results in changes, too).

1+

It seems to me that the current practice ends up disappointing both
those who want to change the default (everything is stale) and
traditional users (minor annoyances are introduced all the time).

If it were possible for the former to fix how they want the defaults to
be by adding something like

   (load-theme 'emacs-27)

to their init, they wouldn't have to fight against every minor change,
while at the same time making it easier to argue for incremental changes
for the other users.

-- 
	Philip Kaludercic

Re: Gitlab Migration

[Daniel Fleischer]

Eli Zaretskii [2021-09-03 Fri 14:41] wrote:

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

I can start compiling a list of variables and customizations, by groups,
with some documentation hints. Probably a discussion about the variables
and default values will indicate if a single profile is enough or not.

-- 

Daniel Fleischer

Re: Gitlab Migration

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> If it were possible for the former to fix how they want the defaults to
> be by adding something like
>
>    (load-theme 'emacs-27)
>
> to their init, they wouldn't have to fight against every minor change,
> while at the same time making it easier to argue for incremental changes
> for the other users.

Yes, I can certainly see that as a possible good feature.

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

Re: Gitlab Migration

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>    (load-theme 'emacs-27)
>>
>> to their init, they wouldn't have to fight against every minor change,
>> while at the same time making it easier to argue for incremental changes
>> for the other users.
>
> Yes, I can certainly see that as a possible good feature.

(But I don't think that'll get rid of any complaints, really -- there'll
be people going "you changed the defaults on this, and that was good,
but you changed this other thing, too, and THAT"S THE WORST CRIME
AGAINST HUMANITY EVER, and I want the first thing, but not the second
thing, so I can't use (load-theme 'emacs-27), so you suck, and I'm now
switching to vim forever (after posting on Hacker News about how much
you suck)".  That's just people being people.)

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

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 18:11, Lars Ingebrigtsen wrote:
> (But I don't think that'll get rid of any complaints, really -- there'll
> be people going "you changed the defaults on this, and that was good,
> but you changed this other thing, too, and THAT"S THE WORST CRIME
> AGAINST HUMANITY EVER, and I want the first thing, but not the second
> thing, so I can't use (load-theme 'emacs-27), so you suck, and I'm now
> switching to vim forever (after posting on Hacker News about how much
> you suck)".  That's just people being people.)

That's why "nobody is unhappy" is a bad criterion for making changes.

Re: Gitlab Migration

[João Távora]

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

On Fri, Sep 3, 2021, 13:34 Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, "Philip K." <philipk@posteo.net
> >,
> >  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>,
> >  John Yates <john@yates-sheets.org>
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Fri, 3 Sep 2021 15:14:20 +0300
> >
> > On 03.09.2021 15:11, João Távora wrote:
> > > - default, the default
> > > - space-hippie, or space-pinhead, a reference to spacemacs and to
> Emacs'
> > > hidden 70s origins
> > > - doctor-doom, likewise for doom emacs, couldn't find anything
> > > particularly clever here, sorry.
> > Spacemacs and Doom don't differ that much between themselves either, not
> > in basic behaviors.
>
> Then maybe we need just one profile, not 2.
>

Fine with me. I've never really used either of those, just know that they
are demonstrably popular sets of settings (unlike many others which are
fallaciously presented here as self-evidently popular). But if those two
are similar enough in the set of options that we are willing or capable to
make configurable via profiles, then one single profile for them it should
be.

The profile's name (or description) should however reflect the proximity to
these popular distributions. I believe this familiarity hint goes some way
into convincing users.

João

>

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

Re: Gitlab Migration

[João Távora]

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

On Fri, Sep 3, 2021, 13:30 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Fri, 3 Sep 2021 13:11:41 +0100
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, "Philip K." <philipk@posteo.net>,
>
> >       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>,
> >       John Yates <john@yates-sheets.org>
> >
> > Additionally, I would like to point out that we need reproducible bug
> recipes from bug reporters, and the best
> > way to get them is something like Emacs -Q and its defaults. It is
> unavoidable that offering profiles as
> > suggested is going to have a negative impact in that department. But
> perhaps it can be controlled if we have
> > a small number of profiles and said profiles are easily chosen from the
> command line and  the bug reporting
> > instructions should updated accordingly.
>
> I don't think this is a significant problem.  We could add the active
> "profile(s)" to the report by report-emacs-bug, and that would take
> care of reproducing the issues that don't happen in "emacs -Q".
>

Bear in mind that other packages are affected where bugs are not reported
via report-emacs-bugs. But I agree that there is still a way -- there
always is -- to determine the configuration that a user is using. My point
is that it should be very easy to do that, i.e to report and control that
big set of preferences, almost as easy as it is when one uses Emacs -Q,
which is, for me, also a way to control to a very large number of
preferences.

Even with the convenience of Emacs -Q, I already have a lot of trouble
explaining and attaining reproducibility from some users. So, as a package
developer, I'd appreciate Emacs -Qprofile-name (or equivalent). This is
essential to interact with users who will, over time, become completely
helpless when presented with a good-old-days Emacs  -Q (with non-vi
bindings, of all things...)

João

>

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

Re: Gitlab Migration

[Juri Linkov]

> If it were possible for the former to fix how they want the defaults to
> be by adding something like
>
>    (load-theme 'emacs-27)

Its contents could look like the node "Antinews" in the Info manual,
but with code that reverts all release changes.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  philipk@posteo.net,  rms@gnu.org,
>   lokedhs@gmail.com,  yantar92@gmail.com,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca
> Date: Fri, 03 Sep 2021 17:25:12 +0300
> 
> I can start compiling a list of variables and customizations, by groups,
> with some documentation hints.

Please do, and thanks.

> Probably a discussion about the variables and default values will
> indicate if a single profile is enough or not.

Yes, it will all be easier and more practical when we have a list to
work with.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  danflscr@gmail.com,  rms@gnu.org,
>   lokedhs@gmail.com,  yantar92@gmail.com,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 03 Sep 2021 19:08:35 +0300
> 
> > If it were possible for the former to fix how they want the defaults to
> > be by adding something like
> >
> >    (load-theme 'emacs-27)
> 
> Its contents could look like the node "Antinews" in the Info manual,
> but with code that reverts all release changes.

Assuming you are serious, no: "Antinews" mentions only a small
fraction of changes called out in NEWS.

Re: Gitlab Migration

[Dmitry Gutov]

On 03.09.2021 22:13, Eli Zaretskii wrote:
>> From: Juri Linkov<juri@linkov.net>
>> Cc: Dmitry Gutov<dgutov@yandex.ru>,danflscr@gmail.com,rms@gnu.org,
>>    lokedhs@gmail.com,yantar92@gmail.com,emacs-devel@gnu.org,
>>    monnier@iro.umontreal.ca,  Eli Zaretskii<eliz@gnu.org>
>> Date: Fri, 03 Sep 2021 19:08:35 +0300
>>
>>> If it were possible for the former to fix how they want the defaults to
>>> be by adding something like
>>>
>>>     (load-theme 'emacs-27)
>> Its contents could look like the node "Antinews" in the Info manual,
>> but with code that reverts all release changes.
> Assuming you are serious, no: "Antinews" mentions only a small
> fraction of changes called out in NEWS.

And vice versa: I would expect at least some changes in defaults to go 
uncontested, then they don't need to go into the good-old-days profile.

Though whenever somebody objects -- in they go.

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 03.09.2021 15:26, Eli Zaretskii wrote:

> We are, I hope, interested mainly in making Emacs evolve and adapt to
> the changing times and preferences.  I consider the way of introducing
> changes as optional first to be a better way towards that goal,
> including the goal to change the defaults.  And I explained in so many
> words why and how.  How is that side-stepping the issue at hand?

The goals of having Emacs "evolve and adapt" and having it stay the same 
are inherently at odds.

> Show me a project where things are different, where the lead
> developers cannot say "I don't like" (with arguments, which you forget
> to mention, or prefer to dismiss or disregard, but they are still
> there), and that's it.  This is how Free Software projects are being
> developed, at least IME.  Emacs is not an outlier, it's right there in
> the mainstream.

You might as well have said "show me a project where the leaders don't 
make decisions".

So what? We can still question the logic in said decisions.

>>> IME, at least on
>>> my daytime job, source code produced by people these days with popular
>>> IDEs (not Emacs) includes TABs.
>>
>> Does it include tabs in the same fashion as what is produced by Emacs?
>> Which actually mixes tabs and spaces.
> 
> Why does it matter?  If we'd make the default use only TABs, would you
> agree then?

You would not be able to -- it would be just as breaking, and it would 
require even more changes, including various major modes. Like 
synchronizing tab-width and the *-indent-level variables.

But it would make more sense, at least.

It does matter if you are at all interested in the current popular 
practices around tabs vs spaces (meaning being interested in what people 
ultimately want: Emacs users generally don't get to choose the current 
project style at the workplace).

When we look at the polls about indentation style preference (where 
"tabs" can be as high as ~30% for certain languages), they don't prefer 
the kind of tab-based indentation that Emacs does. Which really means we 
only satisfy some tiny fraction of the users OOTB in any language.

Re: rmail threading

[Richard Stallman]

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

  > > This suggests we should have a convenient way to make multiple
  > > summaries of a single Rmail buffer, and keep them in parallel.
  > > What do you think of that?

  > That'd help, yes.  Still, the need to switch between different summary
  > buffers is less convenient, IMO.

If you find thread movement commands convenient, by all means add
them.  We are not forced to choose between summary generation and
movement commands for handling of threads.

What I said was, I'd like to use these threads via a summary.

  > > That would be a pain in the neck for me.  I don't want to reorder
  > > RMAIL file.

  > Too bad.

I have 7000 messages in the RMAIL file -- to reorder them would take a
long time.  And how would I restore the original order?

How about creating a virtual reordering without actually
moving the messages around in the buffer?

-- 
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: Representation of the Emacs userbase on emacs-devel

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> When we look at the polls about indentation style preference (where
> "tabs" can be as high as ~30% for certain languages), they don't prefer
> the kind of tab-based indentation that Emacs does. Which really means we
> only satisfy some tiny fraction of the users OOTB in any language.

I do appreciate the work Dmitry put into Bug#20322, which as far as I
can tell shows that spaces-over-tabs is much more widely used than
tabs-over-spaces.  The reason we didn't flip the default was that John
Wiegely was worried that it would lead to problems for someone out
there, and that the benefit of the change is too low.  I can see much
sense in that.

At the same time, since the data we have suggests that
spaces-over-tabs is more common/popular, indent-tabs-mode to t is an
unnecessary frustration for most users that we might want to remove.
One way we could move forward with this, or other changes, is to make
an experimental change on master.  That is, we would tentatively flip
the default on master after the emacs-28 branch is cut, and wait to
see what kind of feedback it results in.  If we don't get any reports
of breakage before Emacs 29.1, even after our pretests, the new
default wins.  Or some variation on that formula (we take the decision
after having had it for N days, etc.).

I think we have made such experiments only once (or twice?) so far.
I'm not saying we need to do this for indent-tabs-mode specifically,
but the process is there and could be used in more cases.  It could
even be used for changes we feel more confident about (i.e. the ones
that we today would just make, and then it stays because the decision
was already taken).

Re: Representation of the Emacs userbase on emacs-devel

[Yuan Fu]

> On Sep 2, 2021, at 11:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> That's only true for changes of the default behavior, and key bindings
> are examples of such a change, at least the way they are proposed.
> There was talk about introducing a minor mode which would then be free
> to make controversial changes, including key bindings, but no one
> stepped forward to write such a mode.  Which I think is a pity, given
> how easy it should be to do that, and how many problems and
> frustrations it could potentially solve.

There can even be a new mode for each new version of Emacs. And I imagine a tutorial would just say “M-x emacs-28-defaults-mode RET to enable the sane defaults”. How do we decide what is turned on in that mode? If we know what to turn on, writing it is trivial, no?

Yuan

Re: Representation of the Emacs userbase on emacs-devel

[tomas]

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

On Sat, Sep 04, 2021 at 04:32:50AM +0300, Dmitry Gutov wrote:
> On 03.09.2021 15:26, Eli Zaretskii wrote:
> 
> >We are, I hope, interested mainly in making Emacs evolve and adapt to
> >the changing times and preferences.  I consider the way of introducing
> >changes as optional first to be a better way towards that goal,
> >including the goal to change the defaults.  And I explained in so many
> >words why and how.  How is that side-stepping the issue at hand?
> 
> The goals of having Emacs "evolve and adapt" and having it stay the
> same are inherently at odds.

After having followed this discussion for a while I must realise
that I'm so put off by your subliminally aggressive style that I
have but two choices: answer in kind, with sarcasm, or just shut
up.

I choose the second. Just to make clear that my silence isn't
tacit assentment.

Cheers
 - t

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

Re: Representation of the Emacs userbase on emacs-devel

[Eli Zaretskii]

> Cc: philipk@posteo.net, rms@gnu.org, john@yates-sheets.org,
>  danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 4 Sep 2021 04:32:50 +0300
> 
> On 03.09.2021 15:26, Eli Zaretskii wrote:
> 
> > We are, I hope, interested mainly in making Emacs evolve and adapt to
> > the changing times and preferences.  I consider the way of introducing
> > changes as optional first to be a better way towards that goal,
> > including the goal to change the defaults.  And I explained in so many
> > words why and how.  How is that side-stepping the issue at hand?
> 
> The goals of having Emacs "evolve and adapt" and having it stay the same 
> are inherently at odds.

Of course.  But Emacs doesn't "stay the same", at least not in the
literal meaning of the word.  So I still don't understand what are you
trying to say here.

> > Show me a project where things are different, where the lead
> > developers cannot say "I don't like" (with arguments, which you forget
> > to mention, or prefer to dismiss or disregard, but they are still
> > there), and that's it.  This is how Free Software projects are being
> > developed, at least IME.  Emacs is not an outlier, it's right there in
> > the mainstream.
> 
> You might as well have said "show me a project where the leaders don't 
> make decisions".

Exactly.

> So what? We can still question the logic in said decisions.

The decisions can be questioned and scrutinized, of course.  But you
questioned the method of making those decisions, and that was what I
responded to.

> >>> IME, at least on
> >>> my daytime job, source code produced by people these days with popular
> >>> IDEs (not Emacs) includes TABs.
> >>
> >> Does it include tabs in the same fashion as what is produced by Emacs?
> >> Which actually mixes tabs and spaces.
> > 
> > Why does it matter?  If we'd make the default use only TABs, would you
> > agree then?
> 
> You would not be able to -- it would be just as breaking, and it would 
> require even more changes, including various major modes. Like 
> synchronizing tab-width and the *-indent-level variables.
> 
> But it would make more sense, at least.

So who dodges the questions now?

> It does matter if you are at all interested in the current popular 
> practices around tabs vs spaces (meaning being interested in what people 
> ultimately want: Emacs users generally don't get to choose the current 
> project style at the workplace).

We have enough customization variables to fit any style out there, I
think.  Changing the defaults according to the current average fashion
out there makes very little sense in a program as stable as Emacs is
supposed to be.

> When we look at the polls about indentation style preference (where 
> "tabs" can be as high as ~30% for certain languages), they don't prefer 
> the kind of tab-based indentation that Emacs does. Which really means we 
> only satisfy some tiny fraction of the users OOTB in any language.

Says you.

Re: Gitlab Migration

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> That's why "nobody is unhappy" is a bad criterion for making changes.

Indeed.  For instance, there are still people livid about making
line-move-visual the default, over a decade afterwards, but that was the
right decision, anyway.

On the other hand, it is pretty annoying to have things change under
your feet, so it's a balancing act.

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

Re: rmail threading

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 03 Sep 2021 23:39:05 -0400
> 
> If you find thread movement commands convenient, by all means add
> them.  We are not forced to choose between summary generation and
> movement commands for handling of threads.
> 
> What I said was, I'd like to use these threads via a summary.

To clarify: you want a summary of a single thread, or you want a
summary of the entire RMAIL file by its threads?

> I have 7000 messages in the RMAIL file -- to reorder them would take a
> long time.  And how would I restore the original order?

You don't.  Why would you want to? messages normally arrive in the
order of their time stamps, the only deviations are due to problems
with communications delays and servers being off-line.

> How about creating a virtual reordering without actually
> moving the messages around in the buffer?

I'm not sure it will help, but I will think about it.

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: Variables for easy customization (was: Gitlab Migration)

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, philipk@posteo.net, yantar92@gmail.com,
>  lokedhs@gmail.com, rms@gnu.org, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca
> Date: Sat, 04 Sep 2021 11:02:20 +0300
> 
> Starting simple, with the following four areas:

Thanks.  I've changed the Subject, as this is not really related to
Gitlab.

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

If the group's name makes it clear it's for programming, the audience
is clear.  I think in other cases, the target major mode(s) are a
better discriminator.  For example, "Editing Text" is better than "For
Writers".  But I didn't think too long about this.  Maybe we should
wait with this until we have a longer list.

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

I don't think we need to make this decision now.  If we decide to
include ELPA, that's additive, right?

Re: Variables for easy customization (was: Gitlab Migration)

[Alan Third]

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

On Sat, Sep 04, 2021 at 11:02:20AM +0300, Daniel Fleischer wrote:
> 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)

Example (badly named) theme attached.

I left off CUA, desktop-save and tool-bar mode customisations because
I'm not sure they really go along with the others.

I have the feeling that we might want to make a separate CUA theme
that makes customisations that are common to people who turn on CUA
(or perhaps that's what this is supposed to be and I've missed the
point).

Also I'm not sure whether the way I'm turning on these global modes is
appropriate for use in a theme. If I disable the theme they stay on,
which is clearly not right.

Perhaps all we need to do once we have these themes written is put a
link on the splash screen to customize-themes?
-- 
Alan Third

[-- Attachment #2: four-space-tabs-theme.el --]
[-- Type: text/plain, Size: 437 bytes --]

(deftheme four-space-tabs
  "Programming settings that more closely reflect other editors defaults")

(custom-theme-set-variables
 'four-space-tabs
 '(indent-tabs-mode nil)
 '(tab-width 4)
 '(visual-order-cursor-movement t)
 '(scroll-preserve-screen-position t))

(global-auto-revert-mode)
(auto-save-visited-mode)
(electric-indent-mode)
(electric-pair-mode)
(global-visual-line-mode)
(show-paren-mode)

(provide-theme 'four-space-tabs)

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 11:02, Daniel Fleischer wrote:
> (setq-default tab-width 4)

Just a heads-up: this one is kinda dangerous because if you view and 
edit files made with default value of tab-width, and they have tabs in 
them (like a lot of files in the Emacs repo), they will end up looking 
wrong. And if you then edit them and perhaps reindent, the patches can 
look wrong to others.

I could be wrong, but last I checked there was either no consensus on 
this value among editors, or 8 was still popular enough.

global-visual-line-mode seems questionable as well -- I don't remember 
seeing this kind of behavior in other coding editors, which seems to be 
the aim of this profile. At least not by default.

The rest of the list looks good (I'd put the cua-mode setting into a 
different profile, but that can be a part of a larger effort).

Thanks!

Re: Gitlab Migration

[Daniel Fleischer]

Dmitry Gutov [2021-09-04 Sat 13:59] wrote:

> global-visual-line-mode seems questionable as well -- I don't remember seeing this kind of behavior in other coding
> editors, which seems to be the aim of this profile. At least not by default.

Now it really depends on who we compare with; if we go with the
"programmers" profile then one can compare with Vim, VScode and Sublime
Text.  The first two do not wrap and the last one does.  Any other
editor we should examine for deaults?


-- 

Daniel Fleischer

Re: Gitlab Migration

[João Távora]

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

On Sat, Sep 4, 2021, 09:03 Daniel Fleischer <danflscr@gmail.com> wrote:

> Starting simple, with the following four...


Thank you for this indexing effort.

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

Yes.  I think we want the list to be more ambitious. For now, it'd be nice
to see, at a glance, what we would ideally like to configure via profile.
Then we can narrow down to what we are realistically and practically
capable of doing. And, in any case, no one profile is obliged to set all
the things that it can set.

I think the separation into categories is very good. E.g. If there is an
"external package" category, it is easier to tell if a particular profile
installs packages, i.e potentially needs internet.

A "global kebinds" category is probably also warranted.  cua-mode should
fall into that, I think. Viper-mode would also. Curiously, evil-mode would
fall into both "external package" and "keybindings". Maybe we need tags...

João

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

Re: Variables for easy customization

[Stefan Monnier]

[ I'm mostly not following this long thread, yet, here I am.  ]

> better discriminator.  For example, "Editing Text" is better than "For

I'd suggest "Prose" rather than "Text".


        Stefan "who has been known to consider replacing `text` with
                `prose` in `text-mode` and `lisp/textmodes`"

Re: Gitlab Migration

[Stefan Monnier]

>> (setq-default tab-width 4)
[...]
> I could be wrong, but last I checked there was either no consensus on this
> value among editors, or 8 was still popular enough.

My religion tells me that $DEITY has clearly specified TABs to have
a width of 8.  But of late, I've found heretics using 4 to be arguably
more frequent than the true believers.

In Python they survive by using an indentation style that makes the TAB
width non-significant (i.e. every line is indented exclusively with
TABs).


        Stefan

Re: Variables for easy customization

[Lars Ingebrigtsen]

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

> I'd suggest "Prose" rather than "Text".
>
>         Stefan "who has been known to consider replacing `text` with
>                 `prose` in `text-mode` and `lisp/textmodes`"

What about all the people using Emacs to write poetry?  Won't anybody
think of the poets?

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

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 14:37, Daniel Fleischer wrote:
> Dmitry Gutov [2021-09-04 Sat 13:59] wrote:
> 
>> global-visual-line-mode seems questionable as well -- I don't remember seeing this kind of behavior in other coding
>> editors, which seems to be the aim of this profile. At least not by default.
> Now it really depends on who we compare with; if we go with the
> "programmers" profile then one can compare with Vim, VScode and Sublime
> Text.  The first two do not wrap and the last one does.  Any other
> editor we should examine for deaults?

Now that I looked, Sublime does have the option to Word Wrap, but it 
seems to be unchecked by default?

Another popular option is Intellij IDEA (no word-wrap by default either, 
as far as I can see). Neither does Atom.

There are also Eclipse and Netbeans, and some others, but AFAIK VS Code 
and IDEA hold the popularity crown these days.

visual-line-mode also has a side-effect of having "simple editing 
commands to act on visual lines" instead of logical ones, so that 
kill-line only kills a part of the line. I couldn't find whether Sublime 
has any similar commands where we could compare the effect.

Re: Gitlab Migration

[Daniel Fleischer]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Now that I looked, Sublime does have the option to Word Wrap, but it seems to be unchecked by default?

Actually it's "auto": wrap for text, non-wrap for programming. 

> Another popular option is Intellij IDEA (no word-wrap by default either, as far as I can see). Neither does Atom.

So it looks like for programming the default is no word-wrap. 


-- 

Daniel Fleischer

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Sat, 04 Sep 2021 17:10:17 +0300
> 
> So it looks like for programming the default is no word-wrap. 

What do they do instead? truncate?

Re: Gitlab Migration

[Daniel Fleischer]

Eli Zaretskii <eliz@gnu.org> writes:

> What do they do instead? truncate?

Either start to horizontal scroll or soft-wrap in the middle of words.

-- 

Daniel Fleischer

Re: Variables for easy customization

[Daniel Fleischer]

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

> I'd suggest "Prose" rather than "Text".
>
>
>         Stefan "who has been known to consider replacing `text` with
>                 `prose` in `text-mode` and `lisp/textmodes`"

I think it's inevitable to separate the use-cases, much like there are
the text-mode and prog-mode from which all file-buffers inherit. 

-- 

Daniel Fleischer

Re: Gitlab Migration

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 04.09.2021 14:37, Daniel Fleischer wrote:
>> Dmitry Gutov [2021-09-04 Sat 13:59] wrote:
>> 
>>> global-visual-line-mode seems questionable as well -- I don't remember seeing this kind of behavior in other coding
>>> editors, which seems to be the aim of this profile. At least not by default.
>> Now it really depends on who we compare with; if we go with the
>> "programmers" profile then one can compare with Vim, VScode and Sublime
>> Text.  The first two do not wrap and the last one does.  Any other
>> editor we should examine for deaults?
>
> Now that I looked, Sublime does have the option to Word Wrap, but it
> seems to be unchecked by default?
>
> Another popular option is Intellij IDEA (no word-wrap by default
> either, as far as I can see). Neither does Atom.
>
> There are also Eclipse and Netbeans, and some others, but AFAIK VS
> Code and IDEA hold the popularity crown these days.
>
> visual-line-mode also has a side-effect of having "simple editing
> commands to act on visual lines" instead of logical ones, so that
> kill-line only kills a part of the line. I couldn't find whether
> Sublime has any similar commands where we could compare the effect.

If this is about replicating what other popular text editors do, why not
simply create emulation modes? sublime-mode, vs-code-mode, etc. Emacs
has a long tradition doing that (see the successive Vi(m) emulation
modes.)

I'll mention that the proposed configuration theming has an important
side-effect: in practice, the user no longer is using Emacs, but a
customization that makes difficult to provide support and benefiting
from existing published resources. An example: if someone posts a
question on help-emacs, the first thing I need to know if he is using
one of those config themes; if the answer is "yes", most likely I will
unable to assist him because I must know the theme and adapt my
instructions in accordance.

IMAO all those arguments about newcomers being turned off by weird
defaults is overblown. I agree that several defaults could be better,
but Emacs should not bend over to compete with the low-effort,
install-and-run editors. IMHO Emacs target audience should de the
high-effort, high-productivity individuals. Things like C-x are not so
important on that context.

Re: Gitlab Migration

[Eli Zaretskii]

> From: Daniel Fleischer <danflscr@gmail.com>
> Date: Sat, 04 Sep 2021 17:22:29 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What do they do instead? truncate?
> 
> Either start to horizontal scroll or soft-wrap in the middle of words.

Horizontal scroll == truncate+horizontal-scroll-bar-mode, right?
And soft-wrap == continuation lines, right?
Which one is more popular?

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 17:10, Daniel Fleischer wrote:
> Actually it's "auto": wrap for text, non-wrap for programming.

Sounds sensible.

Re: Gitlab Migration

[Stefan Kangas]

Daniel Fleischer <danflscr@gmail.com> writes:

> > Another popular option is Intellij IDEA (no word-wrap by default either, as far as I can see). Neither does Atom.
>
> So it looks like for programming the default is no word-wrap.

So there should be a hook turning wrapping off in `prog-mode', right?

Re: Gitlab Migration

[Christian Vanderwall]

On Fri, Sep 03 2021, Lars Ingebrigtsen wrote:

> We have previously discussed extending the concept of a "theme", which
> is currently basically just visual.  I think the way forward here is to
> allow people to create opinionated views on how Emacs should work (from
> keystrokes on up to basically...  anything), and include these in Emacs.
>
> New users, when starting Emacs, would then be able to choose between,
> say, five of these mega-themes on the start-up screen by just clicking
> them.

UX themes are a neat idea, but does it makes sense to include them in Emacs when external configs like Emacs Prelude exist? I think most new Emacs users these days get started by following a blog post or online tutorial. Those resources usually include an opinionated set of defaults that they suggest the user change right away.

Instead of selecting a profile/theme, what if new users could walk through an interactive configuration tutorial? The config tutorial would walk them through the commonly changed defaults, letting them decide which to change, and teaching them to persist changes in their init.el or via Customize in the process.

-- 
Christian Vanderwall

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

[Stefan Kangas]

Christian Vanderwall <christian@cvdub.net> writes:

> UX themes are a neat idea, but does it makes sense to include them in Emacs when external configs like Emacs Prelude exist?

I think so, yes.  We are discussing how to improve the OOTB experience.

> Instead of selecting a profile/theme, what if new users could walk through an interactive configuration tutorial? The config tutorial would walk them through the commonly changed defaults, letting them decide which to change, and teaching them to persist changes in their init.el or via Customize in the process.

There is currently a separate discussion taking place on this list
about this.  I suggest you take a look at it.

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 17:33, Óscar Fuentes wrote:

> If this is about replicating what other popular text editors do, why not
> simply create emulation modes? sublime-mode, vs-code-mode, etc. Emacs
> has a long tradition doing that (see the successive Vi(m) emulation
> modes.)

I think it's more about being a little less alien right away (which is 
where a lot of first users will bounce off), and about showing off some 
of the little niceties that others have but we have disabled (to make 
first good impression), like show-paren and the electric modes.

And having some better defaults, where we for some reasons cannot 
incorporate them in the stock configuration.

> I'll mention that the proposed configuration theming has an important
> side-effect: in practice, the user no longer is using Emacs, but a
> customization that makes difficult to provide support and benefiting
> from existing published resources. An example: if someone posts a
> question on help-emacs, the first thing I need to know if he is using
> one of those config themes; if the answer is "yes", most likely I will
> unable to assist him because I must know the theme and adapt my
> instructions in accordance.

One idea was that report-emacs-bug would mention the enabled profiles. 
Some assistance for help ports, and for other means of bug reporting 
(other bug trackers, e.g. for third-party packages) could be added too.

> IMAO all those arguments about newcomers being turned off by weird
> defaults is overblown. I agree that several defaults could be better,
> but Emacs should not bend over to compete with the low-effort,
> install-and-run editors. IMHO Emacs target audience should de the
> high-effort, high-productivity individuals.

I disagree with that: Emacs can fit lots of different users.

> Things like C-x are not so
> important on that context.

...but I would prefer to move the cua-mode setting to a separate profile 
too. Or have it like a separate checkbox in the wizard, or similar.

Re: Gitlab Migration

[Dmitry Gutov]

On 04.09.2021 16:46, Stefan Monnier wrote:
> My religion tells me that $DEITY has clearly specified TABs to have
> a width of 8.  But of late, I've found heretics using 4 to be arguably
> more frequent than the true believers.
> 
> In Python they survive by using an indentation style that makes the TAB
> width non-significant (i.e. every line is indented exclusively with
> TABs).

I've seen (and had participated in) this trend as well, but AFAICT there 
is still no consensus on the subject among editors' default settings.

Some can correct me if I'm wrong.

And I guess one thing to worry about is as long as this setting is only 
changed in a profile but not in stock Emacs (which seems infeasible), we 
are fragmenting the user base and risk worse interoperability for 
contributors on Emacs-related projects.

Which, I don't know, in the end might only matter for patches sent for 
Emacs itself (the rest of Elisp projects use spaces).

Re: Gitlab Migration

[Augusto Stoffel]

On Sat,  4 Sep 2021 at 09:46, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>> (setq-default tab-width 4)
> [...]
>> I could be wrong, but last I checked there was either no consensus on this
>> value among editors, or 8 was still popular enough.
>
> My religion tells me that $DEITY has clearly specified TABs to have
> a width of 8.  But of late, I've found heretics using 4 to be arguably
> more frequent than the true believers.
>
> In Python they survive by using an indentation style that makes the TAB
> width non-significant (i.e. every line is indented exclusively with
> TABs).
>
>
>         Stefan

That's true, but the Python scriptures basically instruct you to set
`indent-tabs-mode' to nil:

https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

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

[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

Re: Representation of the Emacs userbase on emacs-devel

[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 we want to find out what aspects of a change Emacs users would like
or dislike, we should ask more of them.  We had a discussion last year
about how to do such an investigation, based on how we used to do it,
with improvements.

Would someone like to write draft inquiry questions for the question
at hand?


======================================================================
Here's the method I propose for inquiries (we used to call them "polls")
about users' views about possible changes in well-known behaviors.

* Make a file for the replies to go into.

* Make a mailing address which drops all mail into the file.

* Write a inquiry statement which describes the proposed change in
sufficient detail that people can judge it, what kind of information
we seek, and where to email the response.  Include a deadline for
replies at least 6 weeks in the future.

If possible, we should tell users how to select various behaviors, so
that they can state their opinions based on comparing actual
experiences.

End the inquiry statement with the following text.

    We do not seek "votes", but rather understanding.  If you are for
    the change, please explain why.  Would it help you directly?  If
    so, in what scenarios?  How often, and how strongly, would it
    benefit you?  What would the benefit be?

    Or is it that you think it will improve Emacs, or speed Emacs
    development, by helping other users?  How so?

    Please distinguish between what you know and what you predict.

    Likewise, if you are against the change, please explain why.
    Would it inconvenience you directly?  If so, in what scenarios?
    How often, and how strongly, would it inconvenience you?  What
    would the inconvenience be?

    Or is it that you think it will harm Emacs or Emacs development by
    inconveniencing others?  How so?

    We invite you also to propose alterations in the proposed change that
    you think would improve it -- saying in what scenario that would be an
    improvement, and how so, etc.

    Please post the URL of this page in forums where it is appropriate,
    and resend it to Emacs users and mailing lists where you know people
    will be glad to receive it.

It is crucial to urge people repeatedly to explain their positions
because people tend to skip that crucial part.

* Put the inquiry statement in a web page under gnu.org/software/emacs.

* Mail the inquiry statement info-gnu-emacs, help-gnu-emacs and
emacs-tangents, with the URL of the web page _and_ the full text
of the inquiry statement.

Also post a note referring to the web page on reddit.com/r/emacs, and
any other suitable places.  Mail the URL to Sacha Chua
<sacha@sachachua.com>.

* Wait until at least two weeks after the deadline, then study and
record the responses.  Note down all interesting comments, since they
are the most important information in the responses.

* Do count how many people support each position that people support,
but it would be a mistake to make the actual decision based simply on
counting.  A given change can affect one user very often, and affect
another user only rarely, but they could both state a "strong
preference".

* We are not compelled to choose between "make that change" and "no
change".  The best outcome of the inquiry is that the responses show
us how to design a way to please almost all users, almost all the
time, and not displease any user very much.

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

[Richard Stallman]

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

  > We're literally under no "obligation" to anything. But is it a
  > good outcome?

The reason we are reluctant to change default behaviors is that
we believe that upward compatibiluty for such things is usually
a good outcome.


-- 
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: Representation of the Emacs userbase on emacs-devel

[Richard Stallman]

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

  > The goals of having Emacs "evolve and adapt" and having it stay the same 
  > are inherently at odds.

That's true.  It is commonplace for an activity to have multiple goals
that are partly in conflict.  So we need to look for approaches that
allow us to get some of one and some of the other.

Adding new features that are disabled by default is one of our ways
of doing that.

Sometimes we can find specific clever ways to get a little more of both
by reconciling the desiderata.


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

[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 why is kill-region bound to C-w instead of C-x? I'm not really
  > advocating to change that key binding, but it is also clearly not
  > better.

When Guy Steele worked out the Emacs command set, he chose C-x
for "extended".  That is natural and easy to remember.  It is true
that C-w for kill-region is not particularly natural, but at least
one of the two bindings makes sense.

Swap them, and neither of them would make sense.

As for why we didn't anticipate that someone else would use C-x to
mean kill-region, that's because we had no relationship with SRI.
If we had had one, we could have asked them to send a precognitive
to help us.

I wouldn't mind offering easy options to replace groups of basic
key bindings, such as the CUA bindings and C-x.  This could be
a feature in a set-up wizard.

It is important for these options to work together, when they
don't conflict.  So if you enable the undo-redo bindings
and the CUA bindings at once, you'd get both changes.

I don't see any point in supporting the sort of profile that replaces
many bindings en masse.  That is less flexible.

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

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

  > To give a concrete example, the kill ring is objectively better/more
  > powerful than the undo/redo you find in other text editors.

I see how it makes sense to compare undo/redo with Emacs undo, but how
does it make sense to compare undo/redo with the kill ring?  They do
different jobs.

I think undo/redo instead of undo-only might be an improvement in
Emacs, and might not be hard to get used to as a change -- if only we
can find a key binding for redo.  I know we had a discussion of
this before.

-- 
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: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Yuan Fu <casouri@gmail.com> writes:

>> On Sep 2, 2021, at 11:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> That's only true for changes of the default behavior, and key bindings
>> are examples of such a change, at least the way they are proposed.
>> There was talk about introducing a minor mode which would then be free
>> to make controversial changes, including key bindings, but no one
>> stepped forward to write such a mode.  Which I think is a pity, given
>> how easy it should be to do that, and how many problems and
>> frustrations it could potentially solve.
>
> There can even be a new mode for each new version of Emacs. And I imagine a
> tutorial would just say “M-x emacs-28-defaults-mode RET to enable the sane
> defaults”. How do we decide what is turned on in that mode? If we know what to
> turn on, writing it is trivial, no?
Exactly, the problem is: how you decide what is sane? :-). I don't think emacs
devs has chosen to ship with "insane defaults" on purpose. Or are you emacs
devs? :-)

With other words, emacs devs already think that default options are sane. So I
don't think that wording here should be "enable sane defaults", but "enable
different defaults". For example enable "VSCode like defaults" or enable
"Eclipse like defaults" or something else.

Re: Representation of the Emacs userbase on emacs-devel

[Stefan Kangas]

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

> With other words, emacs devs already think that default options are sane. So I
> don't think that wording here should be "enable sane defaults", but "enable
> different defaults". For example enable "VSCode like defaults" or enable
> "Eclipse like defaults" or something else.

The wording "sane" might indeed come off as overly harsh on our own
history, and by association the people that chose those defaults.  I
have no doubt in my mind that they were more or less the best choices
at the time.  It's just that the world looks different now.

We don't need to bikeshed about a name before we have something more
concrete, but FWIW:

I don't like dragging other editors names into it very much, because I
don't think that captures what this is or should be about.  It makes
it sound like they have something very desirable that we don't, or
that we simply try to imitate them.  In reality, if they do better on
this or that, it is only because they had the advantage of starting
from a clean slate.  Emacs has no reason to make apologies for itself.
We can support a UI more in line with current user expectations
without reference to anyone but ourselves.

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> I don't like dragging other editors names into it very much, because I
> don't think that captures what this is or should be about.  It makes
> it sound like they have something very desirable that we don't, or
> that we simply try to imitate them.

I understand how you feel, but I think it is more on your side, in the eye of
beholder as they say. I don't mean it in a bad way. It is quite common practice
in other applications to acknowledge that peopel are comming to one's
application from other sites, and to give them possibility to easy
adaptation. If you remember the example with Blender and article from Linux mag
I posted some time ago here, it is a good example of this. Some commercial
applications will offer you to use interaction model of concurring applications.

> that we simply try to imitate them.  In reality, if they do better on
> this or that, it is only because they had the advantage of starting
> from a clean slate.

Same as above, it is not about them doing better. It is about Emacs being
flexible and make it easy for people to switch to Emacs with as least hassle as
possible.

>                      Emacs has no reason to make apologies for itself.
> We can support a UI more in line with current user expectations
> without reference to anyone but ourselves.

Again, it is not about apologies or anything like that. It is about being aware
that we are not a lone rock in the space. There are other rocks and people
sometimes do a jump. Lets give them a hand and help them do that step as easy as
possible. It is not an apology, it is strength.

Personally, I don't think that it is possible to immitate other applications
interaction models easily, because Emacs has expectations of more advanced
interaction model deeply ingrained in it's code. But if some modifications can
be done to help bring it into line of other, I don't see reason why not.

Re: Representation of the Emacs userbase on emacs-devel

[Stefan Kangas]

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

> It is quite common practice
> in other applications to acknowledge that peopel are comming to one's
> application from other sites, and to give them possibility to easy
> adaptation. If you remember the example with Blender and article from Linux mag
> I posted some time ago here, it is a good example of this. Some commercial
> applications will offer you to use interaction model of concurring applications.

That's fine of course, but let me be more concrete: I don't see what
CUA keys has to with e.g. vscode, and I don't see what else from them
we would specifically want to imitate that aren't just general
features found elsewhere.

Perhaps you are talking about something much more extensive, to make
Emacs behave a lot like vscode in many respects. In that case it would
make sense to name such a profile after the editor it imitates.

Re: Representation of the Emacs userbase on emacs-devel

[Daniel Fleischer]

Stefan Kangas [2021-09-05 Sun 09:13] wrote:

> That's fine of course, but let me be more concrete: I don't see what
> CUA keys has to with e.g. vscode, and I don't see what else from them
> we would specifically want to imitate that aren't just general
> features found elsewhere.
>
> Perhaps you are talking about something much more extensive, to make
> Emacs behave a lot like vscode in many respects. In that case it would
> make sense to name such a profile after the editor it imitates.

I think no one wants to introduce specific features from VSCode or any
other editor.  But in order to know which are the "general features
found elsewhere" we need to download several of these editors, try them
out and try to recover the common features they offer.

I don't see Emacs having a "VSCode" profile as a good thing.

-- 

Daniel Fleischer

Re: Gitlab Migration

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

It's also make Emacs users wealthier:

https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

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

Re: Gitlab Migration

[Daniel Fleischer]

Lars Ingebrigtsen [2021-09-05 Sun 09:47] wrote:

> It's also make Emacs users wealthier:
>
> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

Obviously causation.

-- 

Daniel Fleischer

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> It is quite common practice
>> in other applications to acknowledge that peopel are comming to one's
>> application from other sites, and to give them possibility to easy
>> adaptation. If you remember the example with Blender and article from Linux mag
>> I posted some time ago here, it is a good example of this. Some commercial
>> applications will offer you to use interaction model of concurring applications.
>
> That's fine of course, but let me be more concrete: I don't see what
> CUA keys has to with e.g. vscode, and I don't see what else from them
> we would specifically want to imitate that aren't just general
> features found elsewhere.
Of course, but it is no just about CUA? VSCode I guess uses CUA-style, but there
were othter things discussed, like tabs vs spaces. I don't say things *has* to
be named after one or other editor either, but I do see reddit threads about
vscode/vim-like themes, configs etc, so I guess people would like to have
smothig like that.

> Perhaps you are talking about something much more extensive, to make
> Emacs behave a lot like vscode in many respects. In that case it would
> make sense to name such a profile after the editor it imitates.

Probably. I was talking more in generic terms reflecting over entire thread, I
wasn't targeting something truly concrete.

I just don't think discussion should be in terms of "sane", "better" or other
value-loaded terms. "Different" is probably the most helpful term we can use
here.

Re: Representation of the Emacs userbase on emacs-devel

[Tim Cross]

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

> I just don't think discussion should be in terms of "sane", "better" or other
> value-loaded terms. "Different" is probably the most helpful term we can use
> here.

I wold agree with this sentiment. Another term could be 'alternative'.
Using terms like 'sane' or 'better' is likely to add more 'noise' rather
than useful discussion as it can tend to make people feel like they need
to defend their particular preferences as being 'sane' or 'better'. 

Re: Gitlab Migration

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> indent-tabs-mode -> nil (of course)
>
> It's also make Emacs users wealthier:
>
> https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

Well, it also says that there are as many programmers using tabs as
using spaces, which goes against some asseverations made on this thread.
That's based on a survey made by Stackoverflow, so we can assume that
old farts writing COBOL nine to five at $BIGBANK are not skewing the
results.

Re: Gitlab Migration

[Dmitry Gutov]

On 05.09.2021 21:38, Óscar Fuentes wrote:
> Well, it also says that there are as many programmers using tabs as
> using spaces, which goes against some asseverations made on this thread.

I don't think it says exactly that, though the difference is much less 
pronounced there that in my previous analysis. Though some previous 
survey result did say that, see my response here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322#137

And the whole thread, if you like.

> That's based on a survey made by Stackoverflow, so we can assume that
> old farts writing COBOL nine to five at $BIGBANK are not skewing the
> results.

To try to reconcile this with the main analysis I used 
(http://sideeffect.kr/popularconvention/#javascript, based on Github 
code), I can either hypothesize that there is a silent crowd that uses 
spaces but doesn't participate in surveys, or that people working on 
closed-source projects use tabs more than the others (?).

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 05.09.2021 11:08, Arthur Miller wrote:
> I just don't think discussion should be in terms of "sane", "better" or other
> value-loaded terms. "Different" is probably the most helpful term we can use
> here.

Contemporary vs Classic?

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 05.09.2021 11:08, Arthur Miller wrote:
>> I just don't think discussion should be in terms of "sane", "better" or other
>> value-loaded terms. "Different" is probably the most helpful term we can use
>> here.
>
> Contemporary vs Classic?

It can be hard to get that jazz swinging; it is still categorizing. You will
have to get people to agree on categories, i.e. what is "contemporary".

Different or alternative as Tim proposed goes for anything :).

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 05.09.2021 22:45, Arthur Miller wrote:
> It can be hard to get that jazz swinging; it is still categorizing. You will
> have to get people to agree on categories, i.e. what is "contemporary".

Might be.

> Different or alternative as Tim proposed goes for anything:).

But it's not "Different", it's rather "Familiar", as far as new users 
are concerned.

Emacs default bindings

[Richard Stallman]

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

  > And to avoid the problems with Emacs's default moving forward, we 
  > introduce a profile called "Good Old Days" which the folks who prefer 
  > things to generally stay the same, would enable, just once. Going 
  > forward, every time we change some default, we would consider adding the 
  > previous value to that profile. Or even do that automatically.

If each profile can cover many unrelated changes, I think that we
can't expect it to work, in general, to enable two different profiles
simultaneously.  In general, they will conflict.  Therefore, I think
we should instead define ways to enable specific interface options
which are independent.

However, for the special case of selecting the defaults of a previous
Emacs version, the issue of conflicts will not arise, because they are
mutually exclusive.  So the idea of broad profiles could make sense,
for this.

The command to select the Emacs 20 defaults can start by calling the
command to select the Emacs 21 defaults, then make the changes to go
from Emacs 21 to Emacs 20.  We could release Emacs 28 with a no-op
command to select the Emacs 28 defaults.  In Emacs 29, that command
would cease to be a no-op.

It can't be just that, because we will also want commands to switch to
more recent defaults.  But they do not need to be written in detail.
The commands to switch to an older default could build up a sort of
settings undo list, recording changes they make, and switching to a
more recent default could work by undoing entries off that list.

Specifying a particular version of defaults could look at the current
version setting to decide whether to go forward or backward.

Would someone like to give this a try?


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

Emacs default bindings

[Richard Stallman]

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

  > I'm not sure this is a silly idea: I see on Reddit people saying
  > they'd like switch from some distro to vanilla Emacs.  When they do
  > so, they could appreciate starting from something that's close to what
  > they are familiar with.

If they want to try GNU Emacs, they don't need any new code to do
that.  So I think what they want to try is not that.  It is something
else.

If you'd like to do work to develop something else they would actually
like to try, the first step is to figure out what that should do.

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

like a module system

[Richard Stallman]

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

  > And there is a lot of good stuff we would take from any of the examples 
  > above, if we could: a module system, concurrency options, a faster 
  > regexp engine.

I think we are on the way to having something comparable to a module
system, using Joao Tavera's symbol-renaming echanism.  I hope it will
be installed soon.

I was always in favor of having a facility like this, but opposed
to trying to imitate Common Lisp's way of doing it.


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

Emacs default bindings

[Richard Stallman]

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

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

Certainly we could.  You believe we should do so, based on premises
that are not stated in your last message, but that we've argued
against already in this list.

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

Emacs default bindings

[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 don't really want to migrate to CUA, personally. Do we not want 
  > our other users to enjoy undo-redo? Having a separate theme for every 
  > little proposed change seems silly.

Adding this facility would not imply that we must install every such
rebinding feature that anyone writes.  We could install the few that
interest enough users as to be worth supporting.

I would guess that CUA bindings would be one,
and undo-redo bindings would be another.
But we'll see, later, what they are.

Packages in GNU ELPA could support some additional rebinding features
that aren't worth supporting inside core Emacs, and that someone wants
to maintain.


-- 
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: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Richard Stallman]

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

  > And having a theme to just make indent-tabs-mode behavior sane, that 
  > would just be ridiculous.

I've been using indent-tabs-mode = nil for enough time to conclude
I personally would not object to making that the default.

Would someone like to look up who objected to it before, and
ask them to try setting it to nil for a month and see what cases
actually cause them trouble?

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

Emacs default bindings

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

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

Let's announce on info-gnu that we tentatively plan to make this the
default in Emacs 28, and ask users to try it now and tell us now if
they see a reason to change that plan.


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

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

  > > What I said was, I'd like to use these threads via a summary.

  > To clarify: you want a summary of a single thread,

What I would find useful is a command to make a summary of a single
thread, in terms of message-IDs, just as I now use the command to
makea summary of a single thread in terms of Subjects.

  >   And how would I restore the original order?

  > You don't.  Why would you want to?

Changing the order would confuse various hacks.
I would rather not mess with the order.



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

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

  > > How about creating a virtual reordering without actually
  > > moving the messages around in the buffer?

  > I'm not sure it will help, but I will think about it.

If implemented, it would give all the interface features of changing
the order, but without actually changing the file.  I think it would
be considerably faster.

-- 
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: Variables for easy customization

[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'd suggest "Prose" rather than "Text".
  > >
  > >         Stefan "who has been known to consider replacing `text` with
  > >                 `prose` in `text-mode` and `lisp/textmodes`"

  > What about all the people using Emacs to write poetry?  Won't anybody
  > think of the poets?

I had the same reaction, but you beat me to it.

Seriously, shouldn't poetry and prose be treated alike,
in regard to editing with Emacs?

-- 
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: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 05.09.2021 22:45, Arthur Miller wrote:
>> It can be hard to get that jazz swinging; it is still categorizing. You will
>> have to get people to agree on categories, i.e. what is "contemporary".
>
> Might be.
>
>> Different or alternative as Tim proposed goes for anything:).
>
> But it's not "Different", it's rather "Familiar", as far as new users are
> concerned.

That is a different meaning to "different" indeed :). You are interpretting
"different" as not-familiar or unkown, why I was thinking of "different" as of
just somethin else.

Maybe it is best just to smash together something and present it rather than
trying people to agree to what is to be done? Like vim-people did with evil?

A diffent profile could be just a bunch of settings in a file. Why not just take
a so called contermporary setup and put it in a init file, and add a customize
variable to let people choose it? Could that work?

Re: Variables for easy customization

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > I'd suggest "Prose" rather than "Text".
>   > >
>   > >         Stefan "who has been known to consider replacing `text` with
>   > >                 `prose` in `text-mode` and `lisp/textmodes`"
>
>   > What about all the people using Emacs to write poetry?  Won't anybody
>   > think of the poets?
>
> I had the same reaction, but you beat me to it.
>
> Seriously, shouldn't poetry and prose be treated alike,
> in regard to editing with Emacs?

Shouldn't on the contrary, prose differ from poetry as prose doesn't
have as strict of a "structure" while poetry e.g. has to preserve line
breaks (fill-paragraph shouldn't break the visual representation of a
poem)?

-- 
	Philip Kaludercic

Re: Representation of the Emacs userbase on emacs-devel

[Hugo Thunnissen]

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

> With other words, emacs devs already think that default options are sane. So I
> don't think that wording here should be "enable sane defaults", but "enable
> different defaults". For example enable "VSCode like defaults" or enable
> "Eclipse like defaults" or something else.

Is it really different defaults that are required for users who come
from other editors to feel accommodated? Being a younger generation
emacs user and coming from other editors myself, the different keybinds
themselves weren't a problem for me. Finding out what they were though,
was more of a challenge. Of course there is C-h m to find about keybinds
in the current mode and C-h k to find out what a keybind does, but those
are not things someone knows about right off the bat. Especially when
people are my age, reading a manual about an editor before using it is
not a common thing to do. Because of the way UI/UX is these days, we
often expect to be guided into information. In that vain, what about
creating a keybind sheet in similar fashion to, but less comprehensive
than the one found here
https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf and making
that the startup screen for new users?

On another note, people coming from other editors often have some
default settings that they want to have replicated in emacs. Things like
tab or space indentation, tab size, dark or light theme, word wrapping
etc. VScode and Atom store general settings like that in a config.json
(vscode) or config.bson (atom) file that users are also allowed to
hand-edit. Maybe emacs can provide some conversion functionality that
lets a user paste in their config.json and tells them the equivalent
emacs configuration values for general default settings like that. I'm
not suggesting providing a completely similar experience to vscode, but
just the basic configuration that most users will want to carry over
between editors.


- Hugo

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Hugo Thunnissen <devel@hugot.nl> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> With other words, emacs devs already think that default options are sane. So I
>> don't think that wording here should be "enable sane defaults", but "enable
>> different defaults". For example enable "VSCode like defaults" or enable
>> "Eclipse like defaults" or something else.
>
> Is it really different defaults that are required for users who come
> from other editors to feel accommodated? Being a younger generatio

I think that is quite personal. Evil is a big thing, and that is vim
layer. Obviously some people prefer different interaction models. I personally
have been using emacs keys for like 20 years now, so I am happy with that and
get annoyed when I press C-w to cut text in FFX and kill the tab. But we are all
different people, and different people prefer different things. That should be
OK, people should be allowed to be different. As Eli wrote in some earlier
message, Emacs can accomodate for different options quite well, so I don't see
why they wouldn't be avaiable. Viper (vi) and CUA ("contemporary"?) keybinding
are already included in Emacs. If someone else made some other emulation layer,
I don't see why would someone object to include it, provided that it meets some
quality criteria and fsf princples.


> from other editors to feel accommodated? Being a younger generation
> emacs user and coming from other editors myself, the different keybinds
> themselves weren't a problem for me.

For you maybe not, wasn't for me neither, but there are people who complain on
keybdings, terminology used etc. I myself think that terminology could be
updated to more "contemporary" as Dmitri calls it (cut/paste instead of
kill/yank).

> themselves weren't a problem for me. Finding out what they were though,
> was more of a challenge. Of course there is C-h m to find about keybinds
> in the current mode and C-h k to find out what a keybind does, but those
> are not things someone knows about right off the bat. Especially when

Indeed. Some applications have animated (scripted) gui tutorials and "newbie"
modes where things are highlighted extra to make it easier to learn the
application. Emacs does not have such things unfortunately. Also the situation
where people are shown to disable gui from the start does not make it better.

> people are my age, reading a manual about an editor before using it is
> not a common thing to do. Because of the way UI/UX is these days, we
> often expect to be guided into information. In that vain, what about
> creating a keybind sheet in similar fashion to, but less comprehensive
> than the one found here
> https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf and making
> that the startup screen for new users?

Yes, that is good idea. There are such attempts. Rougier has nice one:

https://github.com/rougier/elegant-emacs

if  you haven't seen it. I have seen other attempts but don't remember
those. Which key helps a lot. I think it should be included in Emacs. Or at
least the idea. I think that has already been suggested about year or so ago.

> On another note, people coming from other editors often have some
> default settings that they want to have replicated in emacs. Things like
> tab or space indentation, tab size, dark or light theme, word wrapping
> etc. VScode and Atom store general settings like that in a config.json
> (vscode) or config.bson (atom) file that users are also allowed to
> hand-edit. Maybe emacs can provide some conversion functionality that
> lets a user paste in their config.json and tells them the equivalent
> emacs configuration values for general default settings like that. I'm
> not suggesting providing a completely similar experience to vscode, but
> just the basic configuration that most users will want to carry over
> between editors.

Emacs is good at text processing, it is just to write a converter ;-).

I think the problem here is that people who need such converter does not know
enough of elisp to write one, and by the time they learned enough elisp to write
such, they don't need it any more and don't care :).

Jokes aside, yes that could be a thing for some people.

Re: Emacs default bindings

[Dmitry Gutov]

On 06.09.2021 06:06, Richard Stallman wrote:
>    > > 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.
> 
> Let's announce on info-gnu that we tentatively plan to make this the
> default in Emacs 28, and ask users to try it now and tell us now if
> they see a reason to change that plan.

info-gnu or info-gnu-emacs?

Either way, I'm not subscribed to either of these mailing lists, so if 
someone else could do that, that would be great.

Re: Emacs default bindings

[Dmitry Gutov]

On 06.09.2021 06:05, Richard Stallman wrote:
>    > 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.
> 
> Certainly we could.  You believe we should do so, based on premises
> that are not stated in your last message, but that we've argued
> against already in this list.

I'm not sure I understand your disagreement here. I said "strongly 
consider", not "blindly follow withou question".

And you have just approved (right?) my suggestion to do so WRT 
show-paren-mode.

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 06.09.2021 08:04, Arthur Miller wrote:

>>> Different or alternative as Tim proposed goes for anything:).
>>
>> But it's not "Different", it's rather "Familiar", as far as new users are
>> concerned.
> 
> That is a different meaning to "different" indeed :). You are interpretting
> "different" as not-familiar or unkown, why I was thinking of "different" as of
> just somethin else.

I'm just looking at the profiles as something for the new users. So if 
we're picking names, tailoring them to the news user seems advantageous.

> Maybe it is best just to smash together something and present it rather than
> trying people to agree to what is to be done? Like vim-people did with evil?

Sure. Please don't let me stop anyone from experimenting and creating 
whatever number of different profiles.

It's better we start this process, rather than get bogged down here 
arguing about particulars.

> A diffent profile could be just a bunch of settings in a file. Why not just take
> a so called contermporary setup and put it in a init file, and add a customize
> variable to let people choose it? Could that work?

I was thinking themes can be a good vehicle because someone can both 
enable and disable a theme (if they find it doesn't suit their 
preference) without restarting Emacs.

But, again, let us not have this preconception stop anyone from 
experimenting.

Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Dmitry Gutov]

On 06.09.2021 06:06, Richard Stallman wrote:
>    > And having a theme to just make indent-tabs-mode behavior sane, that
>    > would just be ridiculous.
> 
> I've been using indent-tabs-mode = nil for enough time to conclude
> I personally would not object to making that the default.
> 
> Would someone like to look up who objected to it before, and
> ask them to try setting it to nil for a month and see what cases
> actually cause them trouble?

I'm afraid it's not a good question.

If you look at bug#20322 or the latest discussion, people usually talk 
about inconveniencing *others* (all users that are not present in the 
discussion). Because every one who objected can personally easily 
customize indent-tabs-mode to t locally, and that will endure for a long 
time, without being affected by any changes in the default value in any 
future Emacs version.

But as far as customizing it to nil goes, that's not generally a good 
suggestion because people who use tabs for indentation often do that due 
to coding style required at their current place of employment (and they 
often do not get a say in that).

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 06.09.2021 08:04, Arthur Miller wrote:
>
>>>> Different or alternative as Tim proposed goes for anything:).
>>>
>>> But it's not "Different", it's rather "Familiar", as far as new users are
>>> concerned.
>> That is a different meaning to "different" indeed :). You are interpretting
>> "different" as not-familiar or unkown, why I was thinking of "different" as of
>> just somethin else.
>
> I'm just looking at the profiles as something for the new users. So if we're
> picking names, tailoring them to the news user seems advantageous.
>
>> Maybe it is best just to smash together something and present it rather than
>> trying people to agree to what is to be done? Like vim-people did with evil?
>
> Sure. Please don't let me stop anyone from experimenting and creating whatever
> number of different profiles.
>
> It's better we start this process, rather than get bogged down here arguing
> about particulars.
>
>> A diffent profile could be just a bunch of settings in a file. Why not just take
>> a so called contermporary setup and put it in a init file, and add a customize
>> variable to let people choose it? Could that work?
>
> I was thinking themes can be a good vehicle because someone can both enable and
> disable a theme (if they find it doesn't suit their preference) without
> restarting Emacs.

That is true, but same can be done with a toggle button in customize?
I remember when Stefan M. proposed to use themes. Themes are just lisp,
so they can contain any lisp code, but how will it work with visual themes? There
can be only one theme loaded at time, right? I know people are nowdays using
buffer-local themes with face redirecting, but to have a profile-theme and
visual theme it would need some hacking of them mechanism. Having just a file
called profile or something is just to write something? I don't know just
thinking loud.

> But, again, let us not have this preconception stop anyone from experimenting.

Indeed.

By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
M-space respectively. That way someone could rebind keys to resemble more of
"modern" key usage (C-o, C-x, C-v etc ). C-z would need rework in terminal. But
generally, if a prefix can be remaped automatically, it would be an easy thing to
start with?

Re: Representation of the Emacs userbase on emacs-devel

[Óscar Fuentes]

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

> I remember when Stefan M. proposed to use themes. Themes are just lisp,
> so they can contain any lisp code, but how will it work with visual themes? There
> can be only one theme loaded at time, right?

Wrong :-)

You can load & enable as many themes as you wish. There is a system for
deciding which one has precedence when two or more themes set the same
variable or face.

Re: Representation of the Emacs userbase on emacs-devel

[Philip Kaludercic]

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

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 06.09.2021 08:04, Arthur Miller wrote:
>>
>>>>> Different or alternative as Tim proposed goes for anything:).
>>>>
>>>> But it's not "Different", it's rather "Familiar", as far as new users are
>>>> concerned.
>>> That is a different meaning to "different" indeed :). You are interpretting
>>> "different" as not-familiar or unkown, why I was thinking of "different" as of
>>> just somethin else.
>>
>> I'm just looking at the profiles as something for the new users. So if we're
>> picking names, tailoring them to the news user seems advantageous.
>>
>>> Maybe it is best just to smash together something and present it rather than
>>> trying people to agree to what is to be done? Like vim-people did with evil?
>>
>> Sure. Please don't let me stop anyone from experimenting and creating whatever
>> number of different profiles.
>>
>> It's better we start this process, rather than get bogged down here arguing
>> about particulars.
>>
>>> A diffent profile could be just a bunch of settings in a file. Why not just take
>>> a so called contermporary setup and put it in a init file, and add a customize
>>> variable to let people choose it? Could that work?
>>
>> I was thinking themes can be a good vehicle because someone can both enable and
>> disable a theme (if they find it doesn't suit their preference) without
>> restarting Emacs.
>
> That is true, but same can be done with a toggle button in customize?
> I remember when Stefan M. proposed to use themes. Themes are just lisp,
> so they can contain any lisp code, but how will it work with visual themes? There
> can be only one theme loaded at time, right? 

No, you can load more than one "theme" at a time, it just usually
doesn't make any sense for visual themes. But I agree, it might be
confusing. There was some talk about "profiles", but I am not sure if
the idea is to reuse the theme system or create something new. From what
I have been experimenting with antinews themes (ie. revert all changes
since Emacs XY), it requires a minor mode to be activated anyway, so it
might also make sense to just provide a minor mode instead of a theme.

>> But, again, let us not have this preconception stop anyone from experimenting.
>
> Indeed.
>
> By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
> M-space respectively. That way someone could rebind keys to resemble more of
> "modern" key usage (C-o, C-x, C-v etc ). C-z would need rework in terminal. But
> generally, if a prefix can be remaped automatically, it would be an easy thing to
> start with?

I think directly switching might be difficult, because a lot of people
hard-code C-x into keymaps, even without using kbd.

-- 
	Philip Kaludercic

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 06.09.2021 17:11, Philip Kaludercic wrote:
>  From what
> I have been experimenting with antinews themes (ie. revert all changes
> since Emacs XY),

I think it's a doomed approach (too much of a good thing), since a lot 
of changes go uncontested, so we don't _really_ have to provide a 
profile with all the changes reversed. Just the important ones.

Again, just my 2c.

> it requires a minor mode to be activated anyway, so it
> might also make sense to just provide a minor mode instead of a theme.

Perhaps we could extend the themes mechanism so that when a theme is 
enabled, and when it is disabled, a particular hook is run.

E.g. for a theme called good-old-days-profile, enable-theme would look 
up and call the function good-old-days-profile-before-enable (if it's 
defined), and disable-theme would try to call 
good-old-days-profile-before-disable.

Would that remove the minor mode requirement?

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 06.09.2021 16:52, Arthur Miller wrote:
> By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
> M-space respectively. That way someone could rebind keys to resemble more of
> "modern" key usage (C-o, C-x, C-v etc ). C-z would need rework in terminal. But
> generally, if a prefix can be remaped automatically, it would be an easy thing to
> start with?

These particular prefixes seem too much effort IMHO (but AFAIK Evil 
users like SPC as prefix, so what do I know).

The overall approach, however, is something we have discussed, and yes, 
we'd need some way for third-party code and the users to specify both 
prefixes indirectly (so that they in the end can depend on the current 
profile). Whether it's through a couple of global variables, or through 
some special (kbd) syntax, or through some other novel method, remains 
to be worked out.

Re: Representation of the Emacs userbase on emacs-devel

[Stefan Monnier]

> Perhaps we could extend the themes mechanism so that when a theme is
> enabled, and when it is disabled, a particular hook is run.

No need: a theme can already run the code it likes.
In the worst case, it can provide its own global minor modes and then set those
modes's Custom vars to the values it likes.

The advantage of a theme over a minor mode is that it's more
declarative, making visible to Custom the different settings that make
up the theme so that Custom can better handle collections of themes with
overlapping settings.


        Stefan

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> On 06.09.2021 08:04, Arthur Miller wrote:
>>>
>>>>>> Different or alternative as Tim proposed goes for anything:).
>>>>>
>>>>> But it's not "Different", it's rather "Familiar", as far as new users are
>>>>> concerned.
>>>> That is a different meaning to "different" indeed :). You are interpretting
>>>> "different" as not-familiar or unkown, why I was thinking of "different" as of
>>>> just somethin else.
>>>
>>> I'm just looking at the profiles as something for the new users. So if we're
>>> picking names, tailoring them to the news user seems advantageous.
>>>
>>>> Maybe it is best just to smash together something and present it rather than
>>>> trying people to agree to what is to be done? Like vim-people did with evil?
>>>
>>> Sure. Please don't let me stop anyone from experimenting and creating whatever
>>> number of different profiles.
>>>
>>> It's better we start this process, rather than get bogged down here arguing
>>> about particulars.
>>>
>>>> A diffent profile could be just a bunch of settings in a file. Why not just take
>>>> a so called contermporary setup and put it in a init file, and add a customize
>>>> variable to let people choose it? Could that work?
>>>
>>> I was thinking themes can be a good vehicle because someone can both enable and
>>> disable a theme (if they find it doesn't suit their preference) without
>>> restarting Emacs.
>>
>> That is true, but same can be done with a toggle button in customize?
>> I remember when Stefan M. proposed to use themes. Themes are just lisp,
>> so they can contain any lisp code, but how will it work with visual themes? There
>> can be only one theme loaded at time, right? 
>
> No, you can load more than one "theme" at a time, it just usually
> doesn't make any sense for visual themes. But I agree, it might be
> confusing. There was some talk about "profiles", but I am not sure if
> the idea is to reuse the theme system or create something new. From what
> I have been experimenting with antinews themes (ie. revert all changes
> since Emacs XY), it requires a minor mode to be activated anyway, so it
> might also make sense to just provide a minor mode instead of a theme.

Ah ok. I have never tried to use several themes at once :). So as I understand,
themes are proposed because they revert stuff automatically to the state as before?

If you ask me, I don't care, a minor mode, a theme, or just a file with a bunch of
setq:s. I can write a macro to stash away an old value and setq new value, so
it is easy to revert everything back. Whatever works.

>>> But, again, let us not have this preconception stop anyone from experimenting.
>>
>> Indeed.
>>
>> By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
>> M-space respectively. That way someone could rebind keys to resemble more of
>> "modern" key usage (C-o, C-x, C-v etc ). C-z would need rework in terminal. But
>> generally, if a prefix can be remaped automatically, it would be an easy thing to
>> start with?
>
> I think directly switching might be difficult, because a lot of people
> hard-code C-x into keymaps, even without using kbd.

But it's a prefix. Can input methods provide for that? I don't know myself if
suggested C-space M-space is good, but something. I mean nobody want's to
manually rework entire Emacs shortcuts, right? :).

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 06.09.2021 17:46, Stefan Monnier wrote:
>> Perhaps we could extend the themes mechanism so that when a theme is
>> enabled, and when it is disabled, a particular hook is run.
> No need: a theme can already run the code it likes.

I was thinking more about the time when it's disabled.

> In the worst case, it can provide its own global minor modes and then set those
> modes's Custom vars to the values it likes.

That should work, thanks.

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I remember when Stefan M. proposed to use themes. Themes are just lisp,
>> so they can contain any lisp code, but how will it work with visual themes? There
>> can be only one theme loaded at time, right?
>
> Wrong :-)
>
> You can load & enable as many themes as you wish. There is a system for
> deciding which one has precedence when two or more themes set the same
> variable or face.

Yes, they already told me :). I never tried to be honest.

Re: Representation of the Emacs userbase on emacs-devel

[Stefan Monnier]

>> No, you can load more than one "theme" at a time,

Actually, if you "used a theme" then you have used more than one theme
at a time (because there's always an additional/internal theme
representing your own customizations).


        Stefan

Re: Representation of the Emacs userbase on emacs-devel

[Óscar Fuentes]

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

>> Perhaps we could extend the themes mechanism so that when a theme is
>> enabled, and when it is disabled, a particular hook is run.
>
> No need: a theme can already run the code it likes.
> In the worst case, it can provide its own global minor modes and then set those
> modes's Custom vars to the values it likes.

There are legit uses for such a hook. For instance: I have some advices
set for enable/disable-theme. They adapt certain custom faces to changes
on the default face's background.

It's really surprising that the hook was not implemented on day one. It
almost goes against Emacs' good practices.

RE: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Drew Adams]

> But as far as customizing it to nil goes, that's not generally a good
> suggestion because people who use tabs for indentation often do that
> due to coding style required at their current place of employment
> (and they often do not get a say in that).

I don't understand.  Can't they customize it to t?
That will only affect their own use, but any Emacs
users in their org can do that.  What am I missing?

(FWIW, I'm in favor of changing the default to nil,
which is why I started this thread, breaking it off
from your wishlist of default changes.)

Re: [External] : Re: indent-tabs-mode default [was: Representation of the Emacs userbase on emacs-devel]

[Dmitry Gutov]

On 07.09.2021 02:32, Drew Adams wrote:
> I don't understand.  Can't they customize it to t?

Yes. That was in the paragraph before the one you quoted.

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

Hi Richard,

On 05.09.2021 06:39, Richard Stallman wrote:
> If we want to find out what aspects of a change Emacs users would like
> or dislike, we should ask more of them.  We had a discussion last year
> about how to do such an investigation, based on how we used to do it,
> with improvements.
> 
> Would someone like to write draft inquiry questions for the question
> at hand?

Are we talking about the indent-tabs-mode issue? I proposed a version in 
an email from 19.05.2020, you responded with a rewritten draft, and then 
nothing happened.

Here's an updated proposal (added a paragraph before the last one):


We Emacs developers are currently considering a change in the
default value of indent-tabs-mode.  The change would be to
make it nil, rather than t as it has been.

To respond, please send an email to emacs-tabs-inquiry@gnu.org with
your thoughts on the matter.

We do not seek mere "votes", but rather understanding.  If you are for
the change, please explain why.  Would it help you directly?  If so,
in what scenarios?  How often, and how strongly, would it benefit you?
What would the benefit be?

Or is it that you think it will improve Emacs, or speed Emacs
development, by helping other users?  How so?

Please distinguish between what you know and what you predict.

Likewise, if you are against the change, please explain why.
Would it inconvenience you directly?  If so, in what scenarios?
How often, and how strongly, would it inconvenience you?  What
would the inconvenience be?

Or is it that you think it will harm Emacs or Emacs development by
inconveniencing others?  How so?

We invite you also to propose other alternatives to consider, likewise
saying in what scenario that would be an improvement, and how so, etc.

If you have set the variable indent-tabs-mode in your .emacs file,
please say what value you set it to, and how many years ago (roughly).

If you didn't change this variable's value, but had to customize the 
variable tab-width, tell us as well.

Please post the URL of this page in forums where it is appropriate,
and resend it to Emacs users and mailing lists where you know people
will be glad to receive it.

Re: Gitlab Migration

[Dmitry Gutov]

On 05.09.2021 06:44, Richard Stallman wrote:
> I think undo/redo instead of undo-only might be an improvement in
> Emacs, and might not be hard to get used to as a change -- if only we
> can find a key binding for redo.  I know we had a discussion of
> this before.

Let me do a recap. We proposed the keys that a reasonably popular 11 
year old package called undo-tree uses: 'C-?' and 'M-_'.

You replied that those seem inconvenient because C-? is not available on 
ttys, and both C-? and M-_ require two shift keys.

Others replied later that users generally expect 'redo' to require one 
more modifier than 'undo'. In graphical Emacs, it can work out to having 
'C-/' call 'undo', then one can additionally hold down the Shift key to 
the right of '/', calling 'redo' with the resulting 'C-?'.

Alas, there would be no such easy transition in terminal Emacs, but 
other than that, requiring an extra modifier key is not inherently a 
problem. The user should be able to switch between C-- and M-S-- and 
back without too much trouble.

In the same discussion T.V. Raman mentioned that he has bound 
'undo-redo' to 'C-x C-u', to stay close to 'C-x u', another default 
binding for 'undo'.

'C-x C-u' is unfortunately occupied, but it's a disabled command, so 
maaaybe we could take over the binding? Or use 'C-x U'.

Re: Representation of the Emacs userbase on emacs-devel

[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 just don't think discussion should be in terms of "sane", "better" or other
  > > value-loaded terms. "Different" is probably the most helpful term we can use
  > > here.

  > I wold agree with this sentiment. Another term could be 'alternative'.
  > Using terms like 'sane' or 'better' is likely to add more 'noise' rather
  > than useful discussion as it can tend to make people feel like they need
  > to defend their particular preferences as being 'sane' or 'better'. 

I agree.  We can be kinder in this discussion if we avoid implying
that a preference for some different key bindings or interface
is a sign of a personal failing.

-- 
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: Representation of the Emacs userbase on emacs-devel

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

  > By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
  > M-space respectively.

We will not change C-x and M-x in the Emacs defaults,
nor C-SPC and M-SPC.  Those are important commands.

It is ok for a CUA theme to change them.

-- 
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: Variables for easy customization

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

  > Shouldn't on the contrary, prose differ from poetry as prose doesn't
  > have as strict of a "structure" while poetry e.g. has to preserve line
  > breaks (fill-paragraph shouldn't break the visual representation of a
  > poem)?

I hope you're not taking our humorous ripostes seriously.

-- 
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: Representation of the Emacs userbase on emacs-devel

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
>   > M-space respectively.
>
> We will not change C-x and M-x in the Emacs defaults,
> nor C-SPC and M-SPC.  Those are important commands.
>
> It is ok for a CUA theme to change them.

This is completely backwards.  It is precisely because it is important
that C-x should be changed.

Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 05.09.2021 06:44, Richard Stallman wrote:
>> I think undo/redo instead of undo-only might be an improvement in
>> Emacs, and might not be hard to get used to as a change -- if only we
>> can find a key binding for redo.  I know we had a discussion of
>> this before.
>
> Let me do a recap. We proposed the keys that a reasonably popular 11 year old
> package called undo-tree uses: 'C-?' and 'M-_'.
>
> You replied that those seem inconvenient because C-? is not available on ttys,
> and both C-? and M-_ require two shift keys.
>
> Others replied later that users generally expect 'redo' to require one more
> modifier than 'undo'. In graphical Emacs, it can work out to having 'C-/' call
> 'undo', then one can additionally hold down the Shift key to the right of '/',
> calling 'redo' with the resulting 'C-?'.
>
> Alas, there would be no such easy transition in terminal Emacs, but other than
> that, requiring an extra modifier key is not inherently a problem. The user
> should be able to switch between C-- and M-S-- and back without too much
> trouble.
>
> In the same discussion T.V. Raman mentioned that he has bound 'undo-redo' to
> 'C-x C-u', to stay close to 'C-x u', another default binding for 'undo'.
>
> 'C-x C-u' is unfortunately occupied, but it's a disabled command, so maaaybe we
> could take over the binding? Or use 'C-x U'.

Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)

V is next to c, so all prefixes follow next to each other x,c and v.

Re: Gitlab Migration

[Stefan Kangas]

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

> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)

C-v is bound to scroll-up-command.

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
>   > M-space respectively.
>
> We will not change C-x and M-x in the Emacs defaults,
> nor C-SPC and M-SPC.  Those are important commands.

I didn't meant for Emacs defaults.

I meant for some hypotethical config so that users used to C-o, C-x etc can get
those bindings.

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>   > By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
>>   > M-space respectively.
>>
>> We will not change C-x and M-x in the Emacs defaults,
>> nor C-SPC and M-SPC.  Those are important commands.
>>
>> It is ok for a CUA theme to change them.
>
> This is completely backwards.  It is precisely because it is important
> that C-x should be changed.

Not for defaults, but for some other setup .... Like Vim people made Evil. Maybe
Nedit users would prefer Emacs to feel like Nedit? :) Just joking, but it may
help if it is easy to switch those two prefixes to something else, so people can
experiment easier? I think the biggest obstacle to those comming from Notepad is
the use of those few different keys.

I personally believe they should learn how Emacs does, not because of the
shortcuts itself, but because of concepts behind. Emacs builds on more complex
shortcuts than what is "normal" in Windows/Mac worlds, and to use Emacs
effectively it is important to learn how Emacs deals with keys.

Re: Gitlab Migration

[Arthur Miller]

Stefan Kangas <stefan@marxist.se> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>
> C-v is bound to scroll-up-command.
I know, but scroll-up can be rebound .... I use M-v for scroll

Re: Representation of the Emacs userbase on emacs-devel

[tomas]

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

On Tue, Sep 07, 2021 at 06:44:07AM +0200, Stefan Kangas wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> >   > By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
> >   > M-space respectively.
> >
> > We will not change C-x and M-x in the Emacs defaults,
> > nor C-SPC and M-SPC.  Those are important commands.
> >
> > It is ok for a CUA theme to change them.
> 
> This is completely backwards.  It is precisely because it is important
> that C-x should be changed.

Or forwards.

What would the C committee say if I proposed to exchange ',' and ';' in the
syntax?

After all, my keyboard (a DE layout) needs a shift to access the semicolon,
which I use much more in C code than the comma [1].

I am a bit confused by this default thing, especially by this new incarnation
of a "defaults war". Each time it feels like a turf war.

OTOH, it is clear that defaults aren't carved in stone. On the other, it
should be clear that defaults change slowly wherever there is an established
community of users, and each one takes its process and its timing. It may
take years, and a couple of proofs of concept.

Tab-indent mode looks like low hanging fruit by now (but there have been
voices against changing it which have to be taken seriously). I don't really
see the point for C-x now, but hey, that's me.

A set of defaults is, whenever there is an established community, pretty
much like a language. A language evolves, but it takes its time. And might
not always evolve to your liking.

Cheers

[1] Strictly speaking that's a lie, since the comma separates args and thus
   is probably more frequent than the semicolon, but I hope you get the
   idea.

 - t

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

Re: Gitlab Migration

[Yuri Khan]

On Tue, 7 Sept 2021 at 11:57, Arthur Miller <arthur.miller@live.com> wrote:

> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)

So you want all three CUA editing keys, C-x, C-c, C-v, to be Emacs
prefix keys, so as to annoy CUA users even more?

Re: Gitlab Migration

[Philip Kaludercic]

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

> Stefan Kangas <stefan@marxist.se> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>>
>> C-v is bound to scroll-up-command.
> I know, but scroll-up can be rebound .... I use M-v for scroll

So where would you rebind scroll-down-command?

-- 
	Philip Kaludercic

Re: Gitlab Migration

[tomas]

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

On Tue, Sep 07, 2021 at 02:26:06PM +0700, Yuri Khan wrote:
> On Tue, 7 Sept 2021 at 11:57, Arthur Miller <arthur.miller@live.com> wrote:
> 
> > Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
> 
> So you want all three CUA editing keys, C-x, C-c, C-v, to be Emacs
> prefix keys, so as to annoy CUA users even more?

CUA (or Microsoftized-copied-from-Apple-CUA: CUA is SHIFT-DEL, CTRL-INS
and SHIFT-INS, remember [1]?) people can just use CUA mode.

Cheers

[1] This only to illustrate how ephemeral those things are: CUA came and
   went, Emacs offered a mode and folks still complain ;-)

 - t

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

Re: Gitlab Migration

[Dmitry Gutov]

On 07.09.2021 07:56, Arthur Miller wrote:
> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U?:)
> 
> V is next to c, so all prefixes follow next to each other x,c and v.

I think the current subthread is about adding 'redo' to the default 
bindings set. That would mean not touching the existing bindings, much 
less the important ones.

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 07.09.2021 07:44, Stefan Kangas wrote:
> Richard Stallman<rms@gnu.org>  writes:
> 
>>    > By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
>>    > M-space respectively.
>>
>> We will not change C-x and M-x in the Emacs defaults,
>> nor C-SPC and M-SPC.  Those are important commands.
>>
>> It is ok for a CUA theme to change them.
> This is completely backwards.  It is precisely because it is important
> that C-x should be changed.

It seems very improbable at this point to be able to get CUA bindings in 
the default config. And given that there are unsolved questions WRT 
prefixes, etc, I suggest we focus on the profile approach.

We can argue about making it the default later, when the profile has 
seen some use and had kinks ironed out.

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Tue, Sep 07, 2021 at 06:44:07AM +0200, Stefan Kangas wrote:
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> >   > By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
>> >   > M-space respectively.
>> >
>> > We will not change C-x and M-x in the Emacs defaults,
>> > nor C-SPC and M-SPC.  Those are important commands.
>> >
>> > It is ok for a CUA theme to change them.
>> 
>> This is completely backwards.  It is precisely because it is important
>> that C-x should be changed.
>
> Or forwards.
>
> What would the C committee say if I proposed to exchange ',' and ';' in the
> syntax?
>
> After all, my keyboard (a DE layout) needs a shift to access the semicolon,
> which I use much more in C code than the comma [1].
>
> I am a bit confused by this default thing, especially by this new incarnation
> of a "defaults war". Each time it feels like a turf war.
>
> OTOH, it is clear that defaults aren't carved in stone. On the other, it
> should be clear that defaults change slowly wherever there is an established
> community of users, and each one takes its process and its timing. It may
> take years, and a couple of proofs of concept.
>
> Tab-indent mode looks like low hanging fruit by now (but there have been
> voices against changing it which have to be taken seriously). I don't really
> see the point for C-x now, but hey, that's me.
I didn't propose to change C-x from the defaults. :D

I asked how difficult it would be to change prefixes C-x and M-x to something,
in hope that someone will tell me that there is a function that can switch
prefix so that all other keybindings are following. Not because I want a new
default in Emacs, but because it could be easy as a starting point for a so
called alternative setup :).

Re: Gitlab Migration

[Arthur Miller]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Tue, 7 Sept 2021 at 11:57, Arthur Miller <arthur.miller@live.com> wrote:
>
>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>
> So you want all three CUA editing keys, C-x, C-c, C-v, to be Emacs
> prefix keys, so as to annoy CUA users even more?

:-)

That had nothing to do with CUA. If they can manage two, then they can manager
three as well! :-)

No I actually suggested to swtich C-x and M-x to C-space and M-space, IN AN
ALTERNATIVE setup :), to please CUA users and leave them C-x and M-x prefixes to
use to their contents. But discussion here is getting a soup of rests, people
are picking appart and puttin together statements from different contexts so I
don't think I will care any more :).

Re: Gitlab Migration

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Stefan Kangas <stefan@marxist.se> writes:
>>
>>> Arthur Miller <arthur.miller@live.com> writes:
>>>
>>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U? :)
>>>
>>> C-v is bound to scroll-up-command.
>> I know, but scroll-up can be rebound .... I use M-v for scroll
>
> So where would you rebind scroll-down-command?

I have M-v scroll/M-p scroll up/down by line, M-S-v/M-S-p by page. I am using C-v
and C-z as prefixes already, for like two years or so.

Hitting alt is slightly less comfortable than hitting ctrl, especially on
europian keyboards since we don't have right alt (it is alt-gr), but it is not
so bad. I am quite ok with it.

Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07.09.2021 07:56, Arthur Miller wrote:
>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U?:)
>> V is next to c, so all prefixes follow next to each other x,c and v.
>
> I think the current subthread is about adding 'redo' to the default bindings
> set. That would mean not touching the existing bindings, much less the important
> ones.

Are there any kyes left to add anything new? Adding new prefix to defaults opens
for entire new setup. Maybe some hard to hit key combos could be also rebound to
something easier on new prefix. Yes scroll would have to be rebound, but is it
whole world. You give something to win much more. 

Re: Gitlab Migration

[Dmitry Gutov]

On 07.09.2021 15:49, Arthur Miller wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> On 07.09.2021 07:56, Arthur Miller wrote:
>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U?:)
>>> V is next to c, so all prefixes follow next to each other x,c and v.
>> I think the current subthread is about adding 'redo' to the default bindings
>> set. That would mean not touching the existing bindings, much less the important
>> ones.
> Are there any kyes left to add anything new? Adding new prefix to defaults opens
> for entire new setup. Maybe some hard to hit key combos could be also rebound to
> something easier on new prefix. Yes scroll would have to be rebound, but is it
> whole world. You give something to win much more.

I would be totally fine with 'undo-redo' being bound to 'C-?', 'M-_' and 
possibly 'C-x U'. At least as the first step.

If we try to increase the scope of the changes, the odds of anything 
happening at all will get much slimmer.

Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07.09.2021 15:49, Arthur Miller wrote:
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>> 
>>> On 07.09.2021 07:56, Arthur Miller wrote:
>>>> Introduce an extra prefix: C-v? And put undo on C-v u, and windmove undo on C-v U?:)
>>>> V is next to c, so all prefixes follow next to each other x,c and v.
>>> I think the current subthread is about adding 'redo' to the default bindings
>>> set. That would mean not touching the existing bindings, much less the important
>>> ones.
>> Are there any kyes left to add anything new? Adding new prefix to defaults opens
>> for entire new setup. Maybe some hard to hit key combos could be also rebound to
>> something easier on new prefix. Yes scroll would have to be rebound, but is it
>> whole world. You give something to win much more.
>
> I would be totally fine with 'undo-redo' being bound to 'C-?', 'M-_' and
> possibly 'C-x U'. At least as the first step.
>
> If we try to increase the scope of the changes, the odds of anything happening
> at all will get much slimmer.

true, for the scope of changes

By the way, I am using M - _ as undo since years back and works fine for me. I
always thought it was the default :). 

Re: Representation of the Emacs userbase on emacs-devel

[Yuri Khan]

On Tue, 7 Sept 2021 at 13:22, <tomas@tuxteam.de> wrote:

> > >   > By the way, how much work would it be to switch C-x and M-x prefixes to C-space and
> > >   > M-space respectively.

> I am a bit confused by this default thing, especially by this new incarnation
> of a "defaults war". Each time it feels like a turf war.

We are not asking for C-x to be rebound to Cut and C-c to Copy in
Emacs defaults. We are asking for it to become possible for us to make
that rebinding possible locally. And for that, we need people to stop
assuming C-x and C-c are and will always be prefix keys.

Re: Representation of the Emacs userbase on emacs-devel

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> It seems very improbable at this point to be able to get CUA bindings in
> the default config. And given that there are unsolved questions WRT
> prefixes, etc, I suggest we focus on the profile approach.

Agreed.

FWIW, I don't find it helpful with any pre-emptive "decision" at this
stage, when no serious proposal is even on the table.  Only experience
with actual working code would allow us to evaluate of the relative
pros and cons of both approaches.

> We can argue about making it the default later, when the profile has
> seen some use and had kinks ironed out.

I like a good holy war as much as the next guy, but this one we could
indeed postpone.  ;-)

Re: Emacs default bindings

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

  > > Let's announce on info-gnu that we tentatively plan to make this the
  > > default in Emacs 28, and ask users to try it now and tell us now if
  > > they see a reason to change that plan.

  > info-gnu or info-gnu-emacs?

I think I had in mind info-gnu so lots of people would see it.
But it could be info-gnu-emacs.

I was trying to suggest this, not insist.
If Eli decides to do this, I am sure he can.

-- 
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: Representation of the Emacs userbase on emacs-devel

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

  > Are we talking about the indent-tabs-mode issue? I proposed a version in 
  > an email from 19.05.2020, you responded with a rewritten draft, and then 
  > nothing happened.

I probably had no further time.  I am not pressing to do an inquiry,
and I don't want to be the one to run it.  But if we want to know what
the users would prefer about that and why, this is the best way I know
of to find out.

-- 
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: Representation of the Emacs userbase on emacs-devel

[Richard Stallman]

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

  > > We will not change C-x and M-x in the Emacs defaults,
  > > nor C-SPC and M-SPC.  Those are important commands.

  > I didn't meant for Emacs defaults.

  > I meant for some hypotethical config so that users used to C-o, C-x etc can get
  > those bindings.

I think it is fine to make and use such a theme, if you want to.

-- 
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: Emacs default bindings

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, philipk@posteo.net, danflscr@gmail.com,
> 	lokedhs@gmail.com, yantar92@gmail.com, emacs-devel@gnu.org,
> 	monnier@iro.umontreal.ca
> Date: Tue, 07 Sep 2021 23:22:22 -0400
> 
>   > > Let's announce on info-gnu that we tentatively plan to make this the
>   > > default in Emacs 28, and ask users to try it now and tell us now if
>   > > they see a reason to change that plan.

Btw, it's becoming too late for Emacs 28, as we intend to cut the
release branch this month, barring some grave problems.

>   > info-gnu or info-gnu-emacs?
> 
> I think I had in mind info-gnu so lots of people would see it.
> But it could be info-gnu-emacs.

I think info-gnu-emacs is more appropriate.  We could also cross-post
to help-gnu-emacs, for wider audience.

> I was trying to suggest this, not insist.
> If Eli decides to do this, I am sure he can.

Everyone can post to info-gnu-emacs.  Messages there are held for
moderation, but guess who is the moderator.

So, Dmitry, if you think it's a good idea, please go ahead and post.

Re: Representation of the Emacs userbase on emacs-devel

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > We will not change C-x and M-x in the Emacs defaults,
>   > > nor C-SPC and M-SPC.  Those are important commands.
>
>   > I didn't meant for Emacs defaults.
>
>   > I meant for some hypotethical config so that users used to C-o, C-x etc can get
>   > those bindings.
>
> I think it is fine to make and use such a theme, if you want to.

Of course it is fine, it is a free editor :).

> I think it is fine to make and use such a theme, if you want to.

No, I don't want to, but some other users seems to want to :).

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 08.09.2021 06:27, Richard Stallman wrote:
>    > Are we talking about the indent-tabs-mode issue? I proposed a version in
>    > an email from 19.05.2020, you responded with a rewritten draft, and then
>    > nothing happened.
> 
> I probably had no further time.  I am not pressing to do an inquiry,
> and I don't want to be the one to run it.  But if we want to know what
> the users would prefer about that and why, this is the best way I know
> of to find out.

Who can do it?

I can't even create the mailbox, which is the first necessary step that 
you outlined.

Re: Emacs default bindings

[Dmitry Gutov]

On 08.09.2021 09:39, Eli Zaretskii wrote:
>> From: Richard Stallman <rms@gnu.org>
>> Cc: eliz@gnu.org, philipk@posteo.net, danflscr@gmail.com,
>> 	lokedhs@gmail.com, yantar92@gmail.com, emacs-devel@gnu.org,
>> 	monnier@iro.umontreal.ca
>> Date: Tue, 07 Sep 2021 23:22:22 -0400
>>
>>    > > Let's announce on info-gnu that we tentatively plan to make this the
>>    > > default in Emacs 28, and ask users to try it now and tell us now if
>>    > > they see a reason to change that plan.
> 
> Btw, it's becoming too late for Emacs 28, as we intend to cut the
> release branch this month, barring some grave problems.

Not sure how long we are supposed to wait for objections, but if nothing 
substantial comes in the next few days, we'll still have some time.

>>    > info-gnu or info-gnu-emacs?
>>
>> I think I had in mind info-gnu so lots of people would see it.
>> But it could be info-gnu-emacs.
> 
> I think info-gnu-emacs is more appropriate.  We could also cross-post
> to help-gnu-emacs, for wider audience.
> 
>> I was trying to suggest this, not insist.
>> If Eli decides to do this, I am sure he can.
> 
> Everyone can post to info-gnu-emacs.  Messages there are held for
> moderation, but guess who is the moderator.
> 
> So, Dmitry, if you think it's a good idea, please go ahead and post.

Now sent.

Re: Emacs default bindings

[Eli Zaretskii]

> Cc: philipk@posteo.net, danflscr@gmail.com, lokedhs@gmail.com,
>  yantar92@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 8 Sep 2021 15:26:26 +0300
> 
> >>    > > Let's announce on info-gnu that we tentatively plan to make this the
> >>    > > default in Emacs 28, and ask users to try it now and tell us now if
> >>    > > they see a reason to change that plan.
> > 
> > Btw, it's becoming too late for Emacs 28, as we intend to cut the
> > release branch this month, barring some grave problems.
> 
> Not sure how long we are supposed to wait for objections, but if nothing 
> substantial comes in the next few days, we'll still have some time.

We cannot expect to have responses in few days, it usually takes at
least two weeks for people to react.

> > Everyone can post to info-gnu-emacs.  Messages there are held for
> > moderation, but guess who is the moderator.
> > 
> > So, Dmitry, if you think it's a good idea, please go ahead and post.
> 
> Now sent.

Thanks.

Re: Emacs default bindings

[Lars Ingebrigtsen]

I haven't really been following this thread, but it's about making
`show-paren-mode' default in Emacs 28?  I'm not sure that's quite the
right thing to do at this point -- as bug#29381 points out, it probably
shouldn't be a global minor mode, but should instead be a globalized
minor mode (since that'll make it easier to switch on/off on a
per-major-mode basis).

So it should be rewritten as a show-paren-mode/show-paren-local-mode and
then enabled, but that's too late for Emacs 28.

(And there's also some other open bugs for the mode in interactions with
other stuff, but I haven't looked closely at that.)

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

Re: Emacs default bindings

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  philipk@posteo.net,
>   danflscr@gmail.com,  lokedhs@gmail.com,  yantar92@gmail.com,
>   emacs-devel@gnu.org,  monnier@iro.umontreal.ca
> Date: Wed, 08 Sep 2021 15:37:58 +0200
> 
> I haven't really been following this thread, but it's about making
> `show-paren-mode' default in Emacs 28?  I'm not sure that's quite the
> right thing to do at this point -- as bug#29381 points out, it probably
> shouldn't be a global minor mode, but should instead be a globalized
> minor mode (since that'll make it easier to switch on/off on a
> per-major-mode basis).
> 
> So it should be rewritten as a show-paren-mode/show-paren-local-mode and
> then enabled, but that's too late for Emacs 28.

FWIW, I don't think that minor issue should prevent us from turning it
on.  Many people do that, so the problems in bug#29381 cannot be too
grave.  We could fix them later.

Re: Emacs default bindings

[Dmitry Gutov]

On 08.09.2021 16:37, Lars Ingebrigtsen wrote:
> So it should be rewritten as a show-paren-mode/show-paren-local-mode and
> then enabled, but that's too late for Emacs 28.

This should be a fairly small change, implementation-wise. If we wanted 
to do that before the release branch is cut, I don't see a problem.

> (And there's also some other open bugs for the mode in interactions with
> other stuff, but I haven't looked closely at that.)

If you find something notable, please tag me in the discussion. 
show-paren-mode has been pretty solid for me over the years, but of 
course there might be very different workflows out there. It can also be 
semi-broken in some specific major modes, which change 
show-paren-function (e.g. SMIE based ones with buggy grammars). But 
those should "simply" be fixed.

Re: Emacs default bindings

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So it should be rewritten as a show-paren-mode/show-paren-local-mode and
> then enabled

I've always found the effect of show-paren-mode pointless (and rather
annoying) when writing prose, e.g. in org-mode.  I therefore think it
should be enabled by default only in prog-mode.

By the way, VSCode seems to have a feature to enable highlighting the
enclosing brackets when inside expressions.  Perhaps we should add
that feature as well (unless we already have it)?

https://stackoverflow.com/questions/45182543/highlight-enclosing-bracket-in-visual-studio-code

Re: Emacs default bindings

[Alan Mackenzie]

Hello, Stefan.

On Wed, Sep 08, 2021 at 16:53:57 +0200, Stefan Kangas wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:

> > So it should be rewritten as a show-paren-mode/show-paren-local-mode and
> > then enabled

> I've always found the effect of show-paren-mode pointless (and rather
> annoying) when writing prose, e.g. in org-mode.  I therefore think it
> should be enabled by default only in prog-mode.

> By the way, VSCode seems to have a feature to enable highlighting the
> enclosing brackets when inside expressions.  Perhaps we should add
> that feature as well (unless we already have it)?

(defcustom show-paren-when-point-inside-paren nil .....)

> https://stackoverflow.com/questions/45182543/highlight-enclosing-bracket-in-visual-studio-code

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs default bindings

[Philip Kaludercic]

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> So it should be rewritten as a show-paren-mode/show-paren-local-mode and
>> then enabled
>
> I've always found the effect of show-paren-mode pointless (and rather
> annoying) when writing prose, e.g. in org-mode.  I therefore think it
> should be enabled by default only in prog-mode.

There are also some tricky situations where from what I understand
unusual syntax tables break the highlighting. I remember a forth-mode
wanting to pair the ":" and ";" in word definitions, but show-paren-mode
didn't work as expected.

> By the way, VSCode seems to have a feature to enable highlighting the
> enclosing brackets when inside expressions.  Perhaps we should add
> that feature as well (unless we already have it)?

There is highlight-parentheses (in NonGNU ELPA):
https://sr.ht/~tsdh/highlight-parentheses.el/

> https://stackoverflow.com/questions/45182543/highlight-enclosing-bracket-in-visual-studio-code

-- 
	Philip Kaludercic

Re: Emacs default bindings

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 8 Sep 2021 16:53:57 +0200
> Cc: "Philip K." <philipk@posteo.net>, Daniel Fleischer <danflscr@gmail.com>,
>  Richard Stallman <rms@gnu.org>,
>  Elias Mårtenson <lokedhs@gmail.com>,
>  Ihor Radchenko <yantar92@gmail.com>, Emacs developers <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, Dmitry Gutov <dgutov@yandex.ru>,
>  Eli Zaretskii <eliz@gnu.org>
> 
> I've always found the effect of show-paren-mode pointless (and rather
> annoying) when writing prose, e.g. in org-mode.

I have a contrary anecdote to convey: when I type text (for example,
an email message), I sometimes fail to press Shift in time, so instead
of '(' I get '9'.  Then when I type the closing parenthesis,
show-paren alerts me to the problem.

Re: Emacs default bindings

[João Távora]

On Wed, Sep 8, 2021 at 5:10 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Wed, 8 Sep 2021 16:53:57 +0200
> > Cc: "Philip K." <philipk@posteo.net>, Daniel Fleischer <danflscr@gmail.com>,
> >  Richard Stallman <rms@gnu.org>,
> >  Elias Mårtenson <lokedhs@gmail.com>,
> >  Ihor Radchenko <yantar92@gmail.com>, Emacs developers <emacs-devel@gnu.org>,
> >  Stefan Monnier <monnier@iro.umontreal.ca>, Dmitry Gutov <dgutov@yandex.ru>,
> >  Eli Zaretskii <eliz@gnu.org>
> >
> > I've always found the effect of show-paren-mode pointless (and rather
> > annoying) when writing prose, e.g. in org-mode.
>
> I have a contrary anecdote to convey: when I type text (for example,
> an email message), I sometimes fail to press Shift in time, so instead
> of '(' I get '9'.  Then when I type the closing parenthesis,
> show-paren alerts me to the problem.

If we're in anecdote land, I find show-paren-mode (and any
mode that uses the parenthesis-matching information of the syntax
tables), useful in many situations.  It's very often that I want my
parenthesis balanced in prose much as I do in programming languages.

Emace supports this: for example, in message-mode, you might notice
that parenthesis outside quoted sections are not matched to parenthesis
inside them, and vice versa.  Common smiley faces are also "escaped" :-)

João

Re: Emacs default bindings

[Dmitry Gutov]

On 08.09.2021 17:53, Stefan Kangas wrote:
> Lars Ingebrigtsen<larsi@gnus.org>  writes:
> 
>> So it should be rewritten as a show-paren-mode/show-paren-local-mode and
>> then enabled
> I've always found the effect of show-paren-mode pointless (and rather
> annoying) when writing prose, e.g. in org-mode.  I therefore think it
> should be enabled by default only in prog-mode.

It's an option, but if you are in the minority, maybe we'll just suggest 
you turn it off locally.

I've never had problems with having it enabled with prose, but then 
again I don't use Org.

> By the way, VSCode seems to have a feature to enable highlighting the
> enclosing brackets when inside expressions.  Perhaps we should add
> that feature as well (unless we already have it)?
> 
> https://stackoverflow.com/questions/45182543/highlight-enclosing-bracket-in-visual-studio-code

We don't, but it seems like a minor variation in show-paren-mode's 
behavior. Might be easy enough to find a place to plug it in, for 
someone interested in the feature.

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

  > Others replied later that users generally expect 'redo' to require one 
  > more modifier than 'undo'. In graphical Emacs, it can work out to having 
  > 'C-/' call 'undo', then one can additionally hold down the Shift key to 
  > the right of '/', calling 'redo' with the resulting 'C-?'.

If users are happy with that, I won't argue against it.  It doesn't have
any other problem.

We still have the problem of ttys.  We can't use C-/ or C-? on a tty
because each of them is the same character as DEL.  So we use C-_ instead
for undo.

Because there is no difference on a tty between C-_ and C--.
there is no way to disguinuish between Sh-C-- and C--.

However, C-M-- could be used for redo on ttys.

Does that make everyone happy?  If so, maybe we're ready to
introduce that binding.

Initially we should continue the current behavior of undo
to avoid an incompatible change, and have an option to enablke
the undo-redo behavior.  Once Emacs 28 is out, we could find out
what the users think and whether we old fogeys can adjust to undo-redo.
Then we could decide whether to make that the default.



-- 
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: Representation of the Emacs userbase on emacs-devel

[Richard Stallman]

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

  > We are not asking for C-x to be rebound to Cut and C-c to Copy in
  > Emacs defaults. We are asking for it to become possible for us to make
  > that rebinding possible locally. And for that, we need people to stop
  > assuming C-x and C-c are and will always be prefix keys.

I'm sorry, I did not understand this.

It should not be hard.  Whatever internal changes are needed to make it
easy to rebind an x-prefix key or a mode-prefix-key without knowing
which prefix keys lead to that map, they won't cause any trouble.

-- 
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: Representation of the Emacs userbase on emacs-devel

[Richard Stallman]

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

  > We are not asking for C-x to be rebound to Cut and C-c to Copy in
  > Emacs defaults. We are asking for it to become possible for us to make
  > that rebinding possible locally. And for that, we need people to stop
  > assuming C-x and C-c are and will always be prefix keys.

I'm sorry, I did not understand this.

This should be pretty easy.  Whatever internal changes are needed to
make it easy to rebind an x-prefix key or a mode-prefix-key without
knowing which prefix keys lead to that map, they won't cause any
trouble.  Just a little 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: Representation of the Emacs userbase on emacs-devel

[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 again urge that we look at options to change a few of the default
bindings, so that you could select more than one,
rather that large "profiles" that are mutually exclusive.

I don't mind having "profiles" for totally different editing interfaces,
but as a way to handle CUA, that would be too rigid.

-- 
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: Representation of the Emacs userbase on emacs-devel

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

  > Who can do it?

In general, I don't know anyone to suggest.

  > I can't even create the mailbox, which is the first necessary step that 
  > you outlined.

I'll do that part, whenever people are ready to use it.

-- 
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: Emacs default bindings

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> This should be a fairly small change, implementation-wise. If we
> wanted to do that before the release branch is cut, I don't see a
> problem.

It should be done anyway, so the sooner fixed the better (and if we do
change the default, we definitely shouldn't wait).

>> (And there's also some other open bugs for the mode in interactions with
>> other stuff, but I haven't looked closely at that.)
>
> If you find something notable, please tag me in the
> discussion.

Will do.

> show-paren-mode has been pretty solid for me over the
> years, but of course there might be very different workflows out
> there. It can also be semi-broken in some specific major modes, which
> change show-paren-function (e.g. SMIE based ones with buggy
> grammars). But those should "simply" be fixed.

Yeah, most features in Emacs work well by themselves -- most of the
problems come from unintended interactions with other features, and we
don't know what those failure modes are until people has tested it in
real life situations (since nobody has the same setup).

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

Re: Structured debbugs list per project

[Michael Albinus]

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

Hi Tomas,

> I gave it a first shot, pushed to ELPA. The commentary has been
> extended:
>
> ;; If you want all bugs for a given package, sorted by severity and
> ;; whether already resolved, call
> ;;
> ;;   M-x debbugs-gnu-package
>
> ;; Per default it shows the bugs for package "emacs", but with a
> ;; prefix given to the command, different package names can be
> ;; specified (comma-separated).
>
> It is not perfect, and the doc in the manual is still missing, but you
> might give it a try. Pull the recent debbugs version from the GNU ELPA
> repo, or wait a few hours until it appears as package in the elpa-devel
> archive "https://elpa.gnu.org/devel/>.

Released as debbugs 0.29.

>> Cheers
>>  - t

Best regards, Michael.

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 09.09.2021 06:10, 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. ]]]
> 
>    > Who can do it?
> 
> In general, I don't know anyone to suggest.
> 
>    > I can't even create the mailbox, which is the first necessary step that
>    > you outlined.
> 
> I'll do that part, whenever people are ready to use it.

OK, if you can take care about that part, how about I indeed do it myself?

Do I have your approval for this?

Does anybody object?

Re: Emacs default bindings

[Dmitry Gutov]

On 09.09.2021 16:52, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> This should be a fairly small change, implementation-wise. If we
>> wanted to do that before the release branch is cut, I don't see a
>> problem.
> 
> It should be done anyway, so the sooner fixed the better (and if we do
> change the default, we definitely shouldn't wait).

OK, I've posted a patch to bug#29381.

>> show-paren-mode has been pretty solid for me over the
>> years, but of course there might be very different workflows out
>> there. It can also be semi-broken in some specific major modes, which
>> change show-paren-function (e.g. SMIE based ones with buggy
>> grammars). But those should "simply" be fixed.
> 
> Yeah, most features in Emacs work well by themselves -- most of the
> problems come from unintended interactions with other features, and we
> don't know what those failure modes are until people has tested it in
> real life situations (since nobody has the same setup).

Luckily, show-paren-mode is rather old. :-)

So people had time to test it.

Re: Gitlab Migration

[Dmitry Gutov]

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

On 09.09.2021 06:07, 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. ]]]
> 
>    > Others replied later that users generally expect 'redo' to require one
>    > more modifier than 'undo'. In graphical Emacs, it can work out to having
>    > 'C-/' call 'undo', then one can additionally hold down the Shift key to
>    > the right of '/', calling 'redo' with the resulting 'C-?'.
> 
> If users are happy with that, I won't argue against it.  It doesn't have
> any other problem.
> 
> We still have the problem of ttys.  We can't use C-/ or C-? on a tty
> because each of them is the same character as DEL.  So we use C-_ instead
> for undo.
> 
> Because there is no difference on a tty between C-_ and C--.
> there is no way to disguinuish between Sh-C-- and C--.

I previously suggested M-_ (working fine on my tty), but it does make 
the transition more awkward.

> However, C-M-- could be used for redo on ttys.
> 
> Does that make everyone happy?  If so, maybe we're ready to
> introduce that binding.

That's pretty elegant. On tty, the user would press C-- to undo and 
C-M-- to redo. One-modifier difference.

Though in my testing I had to bind C-M-_ instead. That's what my tty 
Emacs translated the combination to. And that also resolved the conflict 
with the existing 'C-M--' binding for 'negative-argument'.

> Initially we should continue the current behavior of undo
> to avoid an incompatible change, and have an option to enablke
> the undo-redo behavior.  Once Emacs 28 is out, we could find out
> what the users think and whether we old fogeys can adjust to undo-redo.
> Then we could decide whether to make that the default.

Sounds good.

I wonder if we should add some mechanism to detect that the user had 
called undo-redo in the current session, and then one of his/her undo-s 
is going to perform a "redoing" undo (and suggest to disable the 
behavior, by changing some user option that will turn their 'undo' into 
'undo-only').

Or maybe the attached patch is enough: long-time users will use 'undo' 
like they always did, and the undo-redo users aren't generally going to 
notice that 'undo' sometimes goes too far.

We should also modify cua-mode to use undo-redo, but that can go in after.

[-- Attachment #2: undo-redo-bindings.diff --]
[-- Type: text/x-patch, Size: 1188 bytes --]

diff --git a/etc/NEWS b/etc/NEWS
index 8f20db7a76..4e12d431a1 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -865,7 +865,13 @@ for CJK text mixed with Latin text.
 +++
 ** New command 'undo-redo'.
 It undoes previous undo commands, but doesn't record itself as an
-undoable command.
+undoable command. It is bound to 'C-?' and 'C-M-_', the first binding
+works well in graphical mode, and the second one is easy to hit on tty.
+
+For full conventional undo/redo behavior, you can also bind undo-only:
+
+    (define-key global-map [?\C-/] 'undo-only)
+    (define-key global-map "\C-_" 'undo-only)
 
 +++
 ** New commands 'copy-matching-lines' and 'kill-matching-lines'.
diff --git a/lisp/bindings.el b/lisp/bindings.el
index b8bf0c1a6f..97a7b01d43 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -993,6 +993,9 @@ undo-repeat-map
   "Keymap to repeat undo key sequences `C-x u u'.  Used in `repeat-mode'.")
 (put 'undo 'repeat-map 'undo-repeat-map)
 
+(define-key global-map (kbd "C-?") 'undo-redo)
+(define-key global-map [?\C-\M-_] 'undo-redo)
+
 (define-key esc-map "!" 'shell-command)
 (define-key esc-map "|" 'shell-command-on-region)
 (define-key esc-map "&" 'async-shell-command)

Re: Structured debbugs list per project

[Stephen Leake]

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

>> ;;   M-x debbugs-gnu-package
>>
>> ;; Per default it shows the bugs for package "emacs", but with a
>> ;; prefix given to the command, different package names can be
>> ;; specified (comma-separated).

I prefer the default to prompt for a package; I mostly want to look at
ada-mode bugs, not emacs. Or

For ada-mode, debbugs-gnu-package only shows the one Normal outstanding
bug; it does not show the Minor outstanding bug (see
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=ada-mode)

How do I tell debbugs to include Minor bugs? I didn't see anything
related in the debbugs menu, keybindings, or manual; I did not try
reading the code. The manual has stuff about severities, but not how to
change what severities are used in this command.

-- 
-- Stephe

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-M-- to redo. One-modifier difference.

  > Though in my testing I had to bind C-M-_ instead.

That's right.  You can type C-M--, but it really turns into C-M-_.
Same for C--; it really turns into C-_.

  > I wonder if we should add some mechanism to detect that the user had 
  > called undo-redo in the current session, and then one of his/her undo-s 
  > is going to perform a "redoing" undo 

You're trying to solve a problem, but I'm not sure precisely what.  I
think we've made different assumptions and thus are miscommunicating.

My idea was to have two options, undo-only and undo-redo, with a way
for the user to select one.  Initially the default would continue to
be undo-only.  We would ask users try undo-redo; if they generally
like it, we could change the default later to undo-redo.

It looks like you're presuming something different (though I am not
sure what it is) and proposing a DWIM feature for it, but I can't tell.
Would you please spell out both what behavior you're presuming, and
what behavior you propose instead?


-- 
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: Representation of the Emacs userbase on emacs-devel

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


  > OK, if you can take care about that part, how about I indeed do it myself?

Please work on drafting the statement.  Then please show it to me
for revision.

-- 
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: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 12.09.2021 04:47, 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. ]]]
> 
> 
>    > OK, if you can take care about that part, how about I indeed do it myself?
> 
> Please work on drafting the statement.  Then please show it to me
> for revision.

I just sent it to you on 07.09.2021, 05:07. Should I resend it?

Re: Gitlab Migration

[Dmitry Gutov]

On 12.09.2021 04:47, 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-M-- to redo. One-modifier difference.
> 
>    > Though in my testing I had to bind C-M-_ instead.
> 
> That's right.  You can type C-M--, but it really turns into C-M-_.
> Same for C--; it really turns into C-_.

Yep.

>    > I wonder if we should add some mechanism to detect that the user had
>    > called undo-redo in the current session, and then one of his/her undo-s
>    > is going to perform a "redoing" undo
> 
> You're trying to solve a problem, but I'm not sure precisely what.  I
> think we've made different assumptions and thus are miscommunicating.

The plan, as I understood it, was to introduce bindings for the new 
command: undo-redo. But to keep the old binding for 'undo'. Which the 
previous sent patch does.

That can create a problem for users new to Emacs (but with experience 
with some other editors) that, since 'undo' is still not the kind of 
'undo' they are used to, so invoking, for example, 'undo undo right left 
undo', might have a certain unexpected effect. So we could use a 
mechanism to correct it automatically, or suggest to the user how to 
correct it, without them having to read the docs.

That said, the problem of unfamiliar undo isn't new, and certain 
conditions would now need to be met for the user to encounter it (as 
opposed to all previous releases of Emacs, where the lack of 'redo' 
command made the said problem much bigger).

> My idea was to have two options, undo-only and undo-redo, with a way
> for the user to select one.  Initially the default would continue to
> be undo-only.  We would ask users try undo-redo; if they generally
> like it, we could change the default later to undo-redo.

The phrasing of this proposal reads a bit off since the command 
'undo-only' exists, and it does the opposite of what you imagined 
'undo-only' would mean: it it a version of 'undo' which won't redo any 
of the previous 'undo' actions. So it's basically meant to be used 
together with 'undo-redo'.

To restate your proposal how I understood it: we will add a binding for 
'undo-redo', and we will have a user option which will change how 'undo' 
works: either it works as it always did (the default), or it will not 
undo redos. The latter is meant to be used together with 'undo-redo'.

Such variable already exists: undo-no-redo. We can simply turn it into a 
defcustom and document more prominently.

> It looks like you're presuming something different (though I am not
> sure what it is) and proposing a DWIM feature for it, but I can't tell.
> Would you please spell out both what behavior you're presuming, and
> what behavior you propose instead?
I was thinking we would detect that the user had called undo-redo in the 
current session. If they had, and if one of their 'undo' invocations is 
about to "undo a redo", we would suggest to the user, just once, that 
they customize 'undo-no-redo' to t, to prevent this kind of thing from 
happening.

That's the best I could come up with; other suggestions are welcome, of 
course. Or, again, we can choose not to try to solve this now.

Re: Structured debbugs list per project

[Michael Albinus]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

Hi Stephen,

>>> ;;   M-x debbugs-gnu-package
>>>
>>> ;; Per default it shows the bugs for package "emacs", but with a
>>> ;; prefix given to the command, different package names can be
>>> ;; specified (comma-separated).
>
> I prefer the default to prompt for a package; I mostly want to look at
> ada-mode bugs, not emacs. Or

See (info "(debbugs-ug) Retrieving Bugs"):

--8<---------------cut here---------------start------------->8---
 -- Command: debbugs-gnu-package &optional packages

     This command shows all bugs for a given list of PACKAGES, sorted
     by severity and whether already resolved.  It is
     'debbugs-gnu-default-packages' per default.
--8<---------------cut here---------------end--------------->8---

> For ada-mode, debbugs-gnu-package only shows the one Normal outstanding
> bug; it does not show the Minor outstanding bug (see
> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=ada-mode)

For me, it shows both bugs:

(debbugs-gnu-package '("ada-mode"))

--8<---------------cut here---------------start------------->8---
GNU bug reports: package(s) ada-mode

Normal bugs - outstanding:

43742 normal,ada Colton Lewis	    Unable to compile ada-mode

Minor bugs - outstanding:

33744 minor,ada- Ludovic Brenta	    26.1; ada-mode 6.0.0 indentation of operators starting a line in a multi-line expression
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

Re: Representation of the Emacs userbase on emacs-devel

[Dmitry Gutov]

On 12.09.2021 04:52, Dmitry Gutov wrote:
> On 12.09.2021 04:47, 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. ]]]
>>
>>
>>    > OK, if you can take care about that part, how about I indeed do 
>> it myself?
>>
>> Please work on drafting the statement.  Then please show it to me
>> for revision.
> 
> I just sent it to you on 07.09.2021, 05:07. Should I resend it?

I'll take this as a "yes".

Here's the updated proposal (added a paragraph before the last one):


We Emacs developers are currently considering a change in the
default value of indent-tabs-mode.  The change would be to
make it nil, rather than t as it has been.

To respond, please send an email to emacs-tabs-inquiry@gnu.org with
your thoughts on the matter.

We do not seek mere "votes", but rather understanding.  If you are for
the change, please explain why.  Would it help you directly?  If so,
in what scenarios?  How often, and how strongly, would it benefit you?
What would the benefit be?

Or is it that you think it will improve Emacs, or speed Emacs
development, by helping other users?  How so?

Please distinguish between what you know and what you predict.

Likewise, if you are against the change, please explain why.
Would it inconvenience you directly?  If so, in what scenarios?
How often, and how strongly, would it inconvenience you?  What
would the inconvenience be?

Or is it that you think it will harm Emacs or Emacs development by
inconveniencing others?  How so?

We invite you also to propose other alternatives to consider, likewise
saying in what scenario that would be an improvement, and how so, etc.

If you have set the variable indent-tabs-mode in your .emacs file,
please say what value you set it to, and how many years ago (roughly).

If you didn't change this variable's value, but had to customize the 
variable tab-width, tell us as well.

Please post the URL of this page in forums where it is appropriate,
and resend it to Emacs users and mailing lists where you know people
will be glad to receive it.

Re: Emacs default bindings

[Dmitry Gutov]

On 06.09.2021 06:06, 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. ]]]
> 
>    > > 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.
> 
> Let's announce on info-gnu that we tentatively plan to make this the
> default in Emacs 28, and ask users to try it now and tell us now if
> they see a reason to change that plan.

So: the feedback we received has been universally positive.

Two email replies to my personal inbox, and a handful of responses on 
Emacs Help.

Unless anybody has strong objections, I'll flip the default tomorrow.

Re: Emacs default bindings

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Unless anybody has strong objections, I'll flip the default tomorrow.

I still think the default should only be flipped for prog-mode.

When writing prose, it does not help to highlight the parens, in fact it
is distracting.

Re: Emacs default bindings

[Dmitry Gutov]

On 28.09.2021 02:40, Stefan Kangas wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Unless anybody has strong objections, I'll flip the default tomorrow.
> 
> I still think the default should only be flipped for prog-mode.
> 
> When writing prose, it does not help to highlight the parens, in fact it
> is distracting.

We've had a couple of responses like that.

But one asked for being able to disable it locally (which we now can), 
and another later changed their mind.

Perhaps you are in the minority?

We could flip it on universally, and then later change the behavior in 
text modes if we get some more negative feedback.

As for how to do it -- maybe with a variable show-paren-global-modes. 
Semantics similar to font-lock-global-modes, but using 'derived-mode-p', 
I guess.

Re: Emacs default bindings

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Perhaps you are in the minority?

Perhaps, but I doubt it.  For example, LibreOffice does not highlight
parenthesis.

This is very much a case of programmers imposing programmer defaults.
But Emacs is not only used by programmers, it is a general purpose text
editor.

> We could flip it on universally, and then later change the behavior in
> text modes if we get some more negative feedback.

Why not do it the other way around: flip it on for `prog-mode' and later
turn it on elsewhere if we get feedback that it would be better.

Re: Emacs default bindings

[Dmitry Gutov]

On 28.09.2021 03:11, Stefan Kangas wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Perhaps you are in the minority?
> 
> Perhaps, but I doubt it.  For example, LibreOffice does not highlight
> parenthesis.
> 
> This is very much a case of programmers imposing programmer defaults.
> But Emacs is not only used by programmers, it is a general purpose text
> editor.

But where does "code" begins and ends?

E.g. LibreOffice Calc does paren matching when one edits in the cell: 
https://ask.libreoffice.org/t/calc-parenthesis-highlighting/31988

And here's a person who apparently had a good reason to want paren 
matching in MS Word: 
https://word.tips.net/T001308_Checking_for_Matching_Parentheses.html

Good enough reason to end up writing a bunch of Basic code ;-(

>> We could flip it on universally, and then later change the behavior in
>> text modes if we get some more negative feedback.
> 
> Why not do it the other way around: flip it on for `prog-mode' and later
> turn it on elsewhere if we get feedback that it would be better.

Do you have an implementation strategy in mind, BTW?

The one I suggested (putting 'prog-mode' into show-paren-global-modes) 
has a drawback of actually bothering _every_ existing user: those who 
have not enabled show-paren-mode will see it enabled; but those who have 
enabled it already, will see it disabled in all modes but prog-mode 
descendants, and will then have to hunt down the way to change this.

Re: Emacs default bindings

[Dmitry Gutov]

On 28.09.2021 03:23, Dmitry Gutov wrote:
> On 28.09.2021 03:11, Stefan Kangas wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> Perhaps you are in the minority?
>>
>> Perhaps, but I doubt it.  For example, LibreOffice does not highlight
>> parenthesis.
>>
>> This is very much a case of programmers imposing programmer defaults.
>> But Emacs is not only used by programmers, it is a general purpose text
>> editor.
> 
> But where does "code" begins and ends?
> 
> E.g. LibreOffice Calc does paren matching when one edits in the cell: 
> https://ask.libreoffice.org/t/calc-parenthesis-highlighting/31988
> 
> And here's a person who apparently had a good reason to want paren 
> matching in MS Word: 
> https://word.tips.net/T001308_Checking_for_Matching_Parentheses.html
> 
> Good enough reason to end up writing a bunch of Basic code ;-(

Also note that we have had paren-matching behavior in text modes for a 
long time.

It's just using something other than show-paren-mode: 
blink-matching-paren has defaulted to t since 1997.

Re: Emacs default bindings

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But where does "code" begins and ends?
>
> E.g. LibreOffice Calc does paren matching when one edits in the cell:
> https://ask.libreoffice.org/t/calc-parenthesis-highlighting/31988

It is indeed hard to know where it ends.  Related to your example, in
Org mode formulas paren highlighting would be obviously useful.  But
it's another thing when writing prose.  Maybe `show-paren-mode' should
grow the capability to only highlight parens in parts of a buffer?

One thing we do know is that code probably starts with `prog-mode'.  ;-)

> Do you have an implementation strategy in mind, BTW?

I didn't really think about it, no.  Sorry.

But I guess we can't just throw it in the body of `prog-mode' and call
it a day...

Re: Emacs default bindings

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Also note that we have had paren-matching behavior in text modes for a
> long time.
>
> It's just using something other than show-paren-mode:
> blink-matching-paren has defaulted to t since 1997.

That's true.  Not a great default IMO, they should have enabled it only
in `prog-mode'.  ;-)

`blink-matching-paren' is less distracting though, as the paren is only
highlighted when it's first written.

Re: Emacs default bindings

[Jim Porter]

On 9/27/2021 4:49 PM, Dmitry Gutov wrote:
> On 28.09.2021 02:40, Stefan Kangas wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> Unless anybody has strong objections, I'll flip the default tomorrow.
>>
>> I still think the default should only be flipped for prog-mode.
>>
>> When writing prose, it does not help to highlight the parens, in fact it
>> is distracting.
> 
> We've had a couple of responses like that.
> 
> But one asked for being able to disable it locally (which we now can), 
> and another later changed their mind.
> 
> Perhaps you are in the minority?

I missed this post originally, so didn't comment back then. I only 
really want this on for prog-mode (and really, I only find it helpful 
when writing Lisp; I'm neutral about it in other languages). It's not 
that big a deal to me either way though; whatever the default is, I'll 
just customize things to my liking.

That said, I also use electric-pair-mode under prog-mode, but customize 
it to be inactive inside strings and comments. My ideal would be for 
show-paren-mode to be active only in the parts of buffers where I have 
electric-pair-mode active, but that would take quite a bit more work. 
(This is just for context about how I use things, not to suggest that 
this should be added to show-paren-mode anytime soon.)

- Jim

Re: Emacs default bindings

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> Unless anybody has strong objections, I'll flip the default tomorrow.
>
> I still think the default should only be flipped for prog-mode.
>
> When writing prose, it does not help to highlight the parens, in fact it
> is distracting.

How come? The only case where I can think of this being distracting is
when using emoticons that may contain parentheses.

-- 
	Philip Kaludercic

Enabling show-paren-mode by default (Was Re: Emacs default bindings)

[Bodertz]

I think the subject line should be updated.  It doesn't seem to be about
default bindings, and you may not be getting feedback from people who
are interested.

Re: Emacs default bindings

[Yuri Khan]

On Tue, 28 Sept 2021 at 13:59, Philip Kaludercic <philipk@posteo.net> wrote:

> > When writing prose, it does not help to highlight the parens, in fact it
> > is distracting.
>
> How come? The only case where I can think of this being distracting is
> when using emoticons that may contain parentheses.

Prose can also contain numbered lists like this:

    a) foo;
    b) bar;
    c) baz.

Re: Emacs default bindings

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Tue, 28 Sep 2021 14:10:24 +0700
> Cc: danflscr@gmail.com, Richard Stallman <rms@gnu.org>,
>  Elias Mårtenson <lokedhs@gmail.com>, yantar92@gmail.com,
>  Emacs developers <emacs-devel@gnu.org>, Stefan Kangas <stefankangas@gmail.com>,
>  Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>
> 
> Prose can also contain numbered lists like this:
> 
>     a) foo;
>     b) bar;
>     c) baz.

This could happen in prog-mode's as well.  For example in shell
scripts, with the 'case' construct.  Does it mean this mode makes no
sense in prog-mode either?

There will always be corner use cases like that, but they don't make
the feature generally useless.

Re: Emacs default bindings

[Dmitry Gutov]

On 28.09.2021 03:54, Stefan Kangas wrote:
>> Do you have an implementation strategy in mind, BTW?
> I didn't really think about it, no.  Sorry.
> 
> But I guess we can't just throw it in the body of `prog-mode' and call
> it a day...

I suppose it could look like

diff --git a/lisp/progmodes/prog-mode.el b/lisp/progmodes/prog-mode.el
index 6c09dcf881..0060de44cf 100644
--- a/lisp/progmodes/prog-mode.el
+++ b/lisp/progmodes/prog-mode.el
@@ -36,7 +36,7 @@ prog-mode
    "Generic programming mode, from which others derive."
    :group 'languages)

-(defcustom prog-mode-hook nil
+(defcustom prog-mode-hook '(show-paren-local-mode)
    "Normal hook run when entering programming modes."
    :type 'hook
    :options '(flyspell-prog-mode abbrev-mode flymake-mode


This might make it more difficult to disable it, though, for less 
experienced users.

But we do use this approach with a number of other hooks.

Re: Emacs default bindings

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> How come? The only case where I can think of this being distracting is
> when using emoticons that may contain parentheses.

Basically, prog-modes have font-locking and therefore this doesn't stand
out that much.  In text-modes, it stands out more.

Having slept on this, and thought about it some more, I realize that:

a) It is not clear to me how visually distracting this is, given that
   this is only visible when you move point to a parenthesis.  I've
   lived with and accepted it for years; I'm sure it'll be fine in the
   future as well.

b) It is easy to think of exceptions, when highlighting parenthesis will
   be very useful even in text-modes.

So, on balance, I don't think the drawbacks I see are strong enough
reason to object to this change.  So I wish to withdraw my objection.

I'm not sure this changes much with regards to what will actually
happen, but I wanted to put it out there for the record.

Re: Emacs default bindings

[Stefan Monnier]

>>     a) foo;
>>     b) bar;
>>     c) baz.
>
> This could happen in prog-mode's as well.  For example in shell
> scripts, with the 'case' construct.  Does it mean this mode makes no
> sense in prog-mode either?

FWIW, there's an important difference in that sh-script knows about sh's
`case` syntax and neuters those parentheses, so they (usually) don't
break paren matching.

In contrast in prose, the use of parens as above is just a loose
convention that's hard to properly detect and handle correctly.

I personally avoid that convention because it breaks
blink-matching-paren ;-)

> There will always be corner use cases like that, but they don't make
> the feature generally useless.

And the problem already exists with blink-matching-paren.


        Stefan "who's planning on disabling `show-paren-mode` in his .emacs"

Re: Emacs default bindings

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Yuri Khan <yuri.v.khan@gmail.com>,  philipk@posteo.net,
>   danflscr@gmail.com,  rms@gnu.org,  lokedhs@gmail.com,
>   yantar92@gmail.com,  emacs-devel@gnu.org,  stefan@marxist.se,
>   dgutov@yandex.ru
> Date: Tue, 28 Sep 2021 08:56:14 -0400
> 
> >>     a) foo;
> >>     b) bar;
> >>     c) baz.
> >
> > This could happen in prog-mode's as well.  For example in shell
> > scripts, with the 'case' construct.  Does it mean this mode makes no
> > sense in prog-mode either?
> 
> FWIW, there's an important difference in that sh-script knows about sh's
> `case` syntax and neuters those parentheses, so they (usually) don't
> break paren matching.

Usually, but not always.

> In contrast in prose, the use of parens as above is just a loose
> convention that's hard to properly detect and handle correctly.

It is also used quite rarely IME.  And anyone who sees that will
immediately understand it's a false positive, and disregard it.

Finally, if someone doesn't like this, they can easily disable it in
their text-mode hooks.  So this is just another incarnation of
"arguing about defaults of user options is waste of time and energy"
principle.

Re: Emacs default bindings

[Dmitry Gutov]

On 28.09.2021 14:37, Stefan Kangas wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
> 
>> How come? The only case where I can think of this being distracting is
>> when using emoticons that may contain parentheses.
> 
> Basically, prog-modes have font-locking and therefore this doesn't stand
> out that much.  In text-modes, it stands out more.
> 
> Having slept on this, and thought about it some more, I realize that:
> 
> a) It is not clear to me how visually distracting this is, given that
>     this is only visible when you move point to a parenthesis.  I've
>     lived with and accepted it for years; I'm sure it'll be fine in the
>     future as well.

So you have lived with it enabled, just disliked how it works in certain 
contexts? With the local mode, it should be easier to choose now, at least.

> b) It is easy to think of exceptions, when highlighting parenthesis will
>     be very useful even in text-modes.
> 
> So, on balance, I don't think the drawbacks I see are strong enough
> reason to object to this change.  So I wish to withdraw my objection.
> 
> I'm not sure this changes much with regards to what will actually
> happen, but I wanted to put it out there for the record.

Thank you for writing this. It basically removed the last strong 
objection, which is really encouraging.

I've pushed the change. Hopefully the NEWS entries (this one and the 
next) will prove instructive enough.

Re: Emacs default bindings

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 06.09.2021 06:06, 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. ]]]
>>    > > 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.
>> Let's announce on info-gnu that we tentatively plan to make this the
>> default in Emacs 28, and ask users to try it now and tell us now if
>> they see a reason to change that plan.
>
> So: the feedback we received has been universally positive.
>
> Two email replies to my personal inbox, and a handful of responses on
> Emacs Help.
>
> Unless anybody has strong objections, I'll flip the default tomorrow.

I'd had (show-paren-mode 1) in my init to begin with, and now that gives
me a recursive load error at startup. If I comment it out I can start
normally, but just running M-x show-paren-mode gives me the same
recursive load error. 

Re: Emacs default bindings

[Dmitry Gutov]

On 29.09.2021 20:07, Eric Abrahamsen wrote:

Hi Eric,

> I'd had (show-paren-mode 1) in my init to begin with,

Me too.

> and now that gives
> me a recursive load error at startup. If I comment it out I can start
> normally, but just running M-x show-paren-mode gives me the same
> recursive load error.

Could you try 'make bootstrap'?

What I had to do to make the global setting work is add

   :initialize 'custom-initialize-delay

to the mode definition. But it seems to work fine over here.

I did get a recursive loading problem when I tried adding 
'show-paren-local-mode' to the initial value of 'prog-mode-hook'. But 
that change didn't make it to the eventual patch.

Re: Emacs default bindings

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 29.09.2021 20:07, Eric Abrahamsen wrote:
>
> Hi Eric,
>
>> I'd had (show-paren-mode 1) in my init to begin with,
>
> Me too.
>
>> and now that gives
>> me a recursive load error at startup. If I comment it out I can start
>> normally, but just running M-x show-paren-mode gives me the same
>> recursive load error.
>
> Could you try 'make bootstrap'?

That did it -- I should have tried that out first.

Thanks,
Eric

Re: Emacs default bindings

[Richard Stallman]

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

  > > This is very much a case of programmers imposing programmer defaults.
  > > But Emacs is not only used by programmers, it is a general purpose text
  > > editor.

  > But where does "code" begins and ends?

It's not a crucial question.  It's ok for a default to be rough and
approximate, given that users can easily adjust it or override it.

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