Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Mon, 13 May 2019 04:43:00 +0300
> 
> On 10.05.2019 23:43, Eli Zaretskii wrote:
> 
> >>> Yes, my point was that having to work via a Web browser will need to
> >>> switch frequently between it and Emacs.  Which is an annoyance, to say
> >>> the least.
> >>
> >> I can believe that, even if I don't really understand it.
> > 
> > Let me try to explain.
> 
> Before I reply to the rest, I'd like to clarify: my surprise was at the 
> declared difficulty of switching between the web browser and Emacs. 

Not "difficulty", "annoyance".  Quite a different thing, I'd say.  You
want me to copy/paste the text to Emacs, edit there, then copy/paste
back?  The switch itself is the least of the problems.

> Out of these, I still use Emacs for more or less everything but abbrevs 
> and word completion. IOW, for everything except writing prose, and I 
> still might copy-paste some snippets of code or text between it and the 
> web browser or the email client.
> 
> Writing text in something other than Emacs is not particularly 
> enjoyable, but turns out, certain kinds of text are 
> fetched/rendered/displayed better in other tools. And you generally have 
> to edit the said kinds of text in the same tools that you're reading 
> them in. In particular, after a few years of trying Gnus for email, I 
> went back to Thunderbird, losing with that all the benefits of 
> everything-inside-Emacs email workflow. So the use of web browser 
> doesn't make it worse (and makes certain other things better).

That's you, not me.  (And I don't use Gnus, either; Emacs has more
than a single email client to offer.)

> > Instead, GitLab wants me to use the Web browser for most of these.
> 
> As per above, I disagree.

So for you the Emacs solution will not be needed.  But there are
enough of those who'd want it.

> > This means the Web browser now becomes a very important program for
> > me, I need to start learning it much more than I bothered until now, I
> > need to keep it updated at all times, I need to customize it (more
> > things to learn and try), etc.
> 
> That is true, of course. Alas, the contemporary Internet makes browsers 
> quite indispensable.

Not in my workflows.  I use it quite rarely, and generally not for
working on code (except when I need to consult documentation, or find
a solution to some problem I bump into).

> >> Here's also the same information on the API level:
> >> https://docs.gitlab.com/ee/api/notification_settings.html
> > 
> > Where is each value described?  The names are not descriptive enough,
> > and I couldn't find any details about them.  Did I miss something?
> 
> You can search the documentation

Granted, I already did.  And came up empty-handed.

> or ask. I think (as a person familiar with GitLab) that all names
> are quite descriptive.

Well, perhaps then you could explain these to me:

 . the "mention" level
 . the "global" level
 . from the "custom" level:
   - issue_due
   - push_to_merge_request and merge_merge_request

> > I never needed to set up any filters.  Never.  It sounds very wrong to
> > me that I need to set up a filter to defend myself against my own
> > project.
> 
> Well, I routinely get duplicate emails because I'm both subscribed to 
> emacs-devel and the bug tracker, and also get Cc'd. I ignore that, but 
> some people suggested technical solutions.

This is standard in almost all mailing lists, and easy to ignore.