Re: [gedit-list] A come back

[Sébastien Wilmet <foss swilmet be>]

Hello Jordi,

On Fri, Aug 30, 2019 at 09:29:26AM +0200, Jordi Mas wrote:
> My name is Jordi Mas. In the last months I have been doing a dozen fixes to
> the gedit-plugins module. Plugins were broken because the migration from
> Python 2 to Python 3 was not tested extensivily (I'm also the author of the
> Translate plugin). I had also added recently static analysis in the CI on
> the plugins repository to prevent future regressions . Additionally I have
> been approving low handing fruit pull requests and doing some fixes in
> gedit also.

Cool, thanks a lot!

> For  me personally, the first question to answer is which are gedit
> potential users.  For example, if we say that is intended as an simple IDE
> clearly gnome-builder is doing a fantastic job in the last months and also
> we are missing key functionalities like been able to work with projects
> (even if we have now the sessions plugin back).  Once this is clear, for me
> we should align on a roadmap that is a mix between that the user needs and
> what we want to work on.

I personnally prefer a simple text editor, and I do everything else in
the terminal (git, build, etc). By using the terminal I have this
feeling to have more control, and better understand how things work,
what work is executed by the computer. So I don't really like IDEs, also
because I prefer to use small GUI apps instead of having everything
integrated (the small developer tools apps can talk to each other with
IPC like D-Bus, for example between gedit and Devhelp).

But I sorely need good code completion for the C language in order to do
more dog-fooding of gedit, plus a few other missing features. Currently
I use gedit with spell-checking to write in Markdown, HTML or simple
text files, but not for code (I used to use gedit a lot to program in
Vala, because there was a plugin available with Vala code completion).

> For example, looking at different sources
> (including Issues, Ubuntu bug reports, etc) it's clear that the users have
> some clear requests from users:
>    - Gedit cannot deal with large files. The user  experience is really
>    broken. We know that this due to Gtk but this is one of the top user
>    problems.

Yes, it definitely needs a solution to prevent loading such files. I
started to implement it in Tepl (limit the file size, not yet for very
long lines).

In a few weeks, when the next development cycle starts, I intend to port
gedit progressively to Tepl, there are some low-hanging fruits to
improve gedit by doing that (I'm thinking about GtkInfoBars
specifically, the rest is just to remove some code from gedit).

>    - Many users are not happy how we handle encodings. Does not fit all
>    user cases. In particular, since we removed the option to select encoding
>    to open files from the open file dialog box.

Indeed, I've noticed that feature removal. It was done to have a better
sandbox for gedit, but accessing the whole filesystem (or the whole
home) is anyway needed for the integrated file browser plugin.

Tepl doesn't yet solve that problem, it needs more work.

>    - Many users are not happy with the fact that when you open a new file
>    if you do not give it at name is not save it automatically and you can lose
>    data.

Yes, it would be super nice to have something similar to SublimeText. It
can be a little difficult to implement, but if I have the time it's
something that I want to do.

>    - etc

Another thing, instead of a dialog window for the search and replace,
have an horizontal bar below or above the text, to not hide the text.

> If there is an IRC meeting I'm happy to participate then we can further
> align on these topics.

What I had in mind, is, maybe once every two weeks, to have a small list
of GitLab issues (including feature requests) or merge requests that are
either important or for which it would be nice to fix them as soon as
possible (for the next stable release, for example).

I don't know if it requires an IRC meeting.

But it would permit to focus on the important things.

Doing daily bug triaging, first line support and reviews for more than a
handful of Gnome projects at the same time, was too stressfull for me
after several years. So I'm still trying to find solutions to avoid that
this problem reappears. I now have a separate email address for my Gnome
stuff, and I could create another email address specifically for
receiving GitLab notifications. I try to not go too much on the computer
during the week-end or the evening, etc.

On IRC there is a bit of everything: first line support (including angry
users), notifications for incoming bug reports, discussion between
contributors, etc. So I prefer to avoid a part of it (not the latter
part, I reassure you ;-) ).

In the CONTRIBUTING.md file, I have written this paragraph:

        Doing **bug triaging** on the bug tracker is a very useful task
        for gedit, because gedit is used by many people and there are
        therefore lots of bug reports or feature requests. The gedit
        developers often have difficulties to triage all the bugs and do
        first line support. Having a curated list of important bugs to
        fix would tremendously help the gedit developers.

Anyone knowing gedit well can help. I used to do a lot of bug triaging
in gedit in bugzilla, but if other contributors can help, it's really
much appreciated. Then we can better view the most important bugs to fix
or user requests.

Cheers,
Sébastien