[gedit-list] gtide - gedit to IDEs (and beyond)

[Sébastien Wilmet]

Hi,

I'm creating a new library called gtide, currently hosted on GitHub:
https://github.com/swilmet/gtide

It's to continue making the gedit source code more re-usable. The goal
of gtide is to create an MDI text editor framework:
https://wiki.gnome.org/Apps/Gedit/ReusableCode
https://wiki.gnome.org/Projects/GtkSourceView/MdiFramework

gtide would be a public API for gedit and gedit plugins. When moving
some code from gedit to gtide, the code in gedit would be removed and
the plugins need to use the gtide API instead.

The other solution is trying to keep the gedit API as-is and writing
proxy methods or an adapter. But it gets in the way:
- the API docs need to be duplicated (well anyway it's almost
non-existent in gedit).
- it's a lot of code to keep in gedit.
- other annoyances, like: for functions taking a variable number of
parameters, the proxy is a bit more complicated to write.

So I think putting the re-usable code in a shared library is the best
thing to do. That way it can be used directly in other text editors as
well.

When an API break is needed in gtide, we can bump the major version so
it's parallel installable with previous major versions. And that, every
6 months if needed. Who cares if we end up with gtide-17?

About the name, gtide, "edit" in "gedit" has been reversed. It can also
be seen as an acronym for "gedit to IDEs", which is the goal, easing the
creation of new text editors and IDEs. And this could create a "tide" in
the text editors field :) I prefer "gtide" than "gcode" (gcode was the
other name coming to my mind). For me, gedit is not about code, quite
the contrary, I use gedit only for non-programming text editing tasks. A
notepad-like. I guess the Microsoft employees who developed notepad
didn't use notepad to develop it. The same for me and gedit. So it makes
sense. Also, pronouncing "gtide" is more beautiful than "gcode", in my
opinion. And another reason is that there will maybe be a GtkCodeView in
the future, replacing GtkTextView/GtkSourceView.

So, creating gtide, porting the plugins to the gtide API etc, is quite a
bold move for gedit. But such a bold move is needed. The new library
needs to have a different namespace. And it needs to be different than
GtkSource, since the GtkSourceView repo is not suitable to develop a
framework where API breaks will probably be needed.

What do you think?

--
Sébastien

[Paolo Borelli]

Hi Sébastien,

honestly I am not so convinced about adding yet another library.

The fact that we have to come up with cool names for the library itself, is
a hint that the library does not have a well defined role.
If we have generic widgets they belong in gtk, if we have code editing
utils they belong in gtksourceview, all the rest should be "glue" code
specific to an application current UI design (gedit in this case) and
having an external library with a stable API and ABI can get in the way of
refactorings and incremental changes.

Even for plugin developers would be confusing: today it is already pretty
bad that a plugin developer should keep asking himself:

"Ok I need this method to operate on the text file, where do I look? I
guess in the GeditDocument documentation... uh, no... uhm, maybe in
GtkSourceBuffer? Nope, nothing... ah, ok, found it, it is in GtkTextBuffer".

Splitting things in yet another small lib with its own namespace etc would
make things worse.

Of course I know reality is not so black and white and I completely agree
with your goal of making code reusable, so I apologize in advance if I
sound too negative. My suggestion is to not focus yet on API stability and
on the library infrastructure and to not spend time porting plugins, but
instead first discover what would go in the library and then we can discuss
together where it belongs and how to share it.


Ciao,

Paolo

Post by Sébastien Wilmet
Hi,
https://github.com/swilmet/gtide
It's to continue making the gedit source code more re-usable. The goal
https://wiki.gnome.org/Apps/Gedit/ReusableCode
https://wiki.gnome.org/Projects/GtkSourceView/MdiFramework
gtide would be a public API for gedit and gedit plugins. When moving
some code from gedit to gtide, the code in gedit would be removed and
the plugins need to use the gtide API instead.
The other solution is trying to keep the gedit API as-is and writing
- the API docs need to be duplicated (well anyway it's almost
non-existent in gedit).
- it's a lot of code to keep in gedit.
- other annoyances, like: for functions taking a variable number of
parameters, the proxy is a bit more complicated to write.
So I think putting the re-usable code in a shared library is the best
thing to do. That way it can be used directly in other text editors as
well.
When an API break is needed in gtide, we can bump the major version so
it's parallel installable with previous major versions. And that, every
6 months if needed. Who cares if we end up with gtide-17?
About the name, gtide, "edit" in "gedit" has been reversed. It can also
be seen as an acronym for "gedit to IDEs", which is the goal, easing the
creation of new text editors and IDEs. And this could create a "tide" in
the text editors field :) I prefer "gtide" than "gcode" (gcode was the
other name coming to my mind). For me, gedit is not about code, quite
the contrary, I use gedit only for non-programming text editing tasks. A
notepad-like. I guess the Microsoft employees who developed notepad
didn't use notepad to develop it. The same for me and gedit. So it makes
sense. Also, pronouncing "gtide" is more beautiful than "gcode", in my
opinion. And another reason is that there will maybe be a GtkCodeView in
the future, replacing GtkTextView/GtkSourceView.
So, creating gtide, porting the plugins to the gtide API etc, is quite a
bold move for gedit. But such a bold move is needed. The new library
needs to have a different namespace. And it needs to be different than
GtkSource, since the GtkSourceView repo is not suitable to develop a
framework where API breaks will probably be needed.
What do you think?
--
Sébastien
_______________________________________________
gedit-list mailing list
https://mail.gnome.org/mailman/listinfo/gedit-list

[Sébastien Wilmet]

Post by Paolo Borelli
honestly I am not so convinced about adding yet another library.
The fact that we have to come up with cool names for the library itself, is
a hint that the library does not have a well defined role.

It has a well defined role. Creating a text editor framework.
GtkSourceView is aware of only one view, one file. The framework would
handle multiple views, i.e. it would be an MDI framework (for text
editors). So there is a clear boundary.

Post by Paolo Borelli
If we have generic widgets they belong in gtk, if we have code editing
utils they belong in gtksourceview, all the rest should be "glue" code
specific to an application current UI design (gedit in this case)

40k lines of code is a lot for just "glue" code in gedit… I agree some
widgets in gedit are generic and could move to the libgd for example
(the print preview for example).

Post by Paolo Borelli
and
having an external library with a stable API and ABI can get in the way of
refactorings and incremental changes.

That's why I explained that we can bump the major version of gtide and
break the API every 6 months if we want. Other text editors can still
use older versions of gtide that way, and can do the port at a different
time than the GNOME schedule.

Post by Paolo Borelli
Even for plugin developers would be confusing: today it is already pretty
"Ok I need this method to operate on the text file, where do I look? I
guess in the GeditDocument documentation... uh, no... uhm, maybe in
GtkSourceBuffer? Nope, nothing... ah, ok, found it, it is in GtkTextBuffer".
Splitting things in yet another small lib with its own namespace etc would
make things worse.

When the framework is finished, it would be gtide plugins, not gedit
plugins. All the API would be in gtide and below.

Post by Paolo Borelli
Of course I know reality is not so black and white and I completely agree
with your goal of making code reusable, so I apologize in advance if I
sound too negative. My suggestion is to not focus yet on API stability and
on the library infrastructure and to not spend time porting plugins, but
instead first discover what would go in the library and then we can discuss
together where it belongs and how to share it.

Sorry if it was not clear. I have a clear idea of how the framework
would be designed (not in the details, but the general architecture).
It's not a new idea, I thought about it already five years ago, so I
will not repeat myself:
https://mail.gnome.org/archives/gedit-list/2011-January/msg00055.html

In short, what would you do if you wanted to create a new text editor,
with a Multiple Document Interface (MDI) and based on GtkSourceView? You
would need to rewrite almost all of the gedit core codebase if you want
to have a decent text editor. A fork is not a good solution, because you
would need to maintain two times 40k lines of code…

So, in those situations, a better idea is to write a library. And, even
better, a framework. A framework is more than a library, like explained
in the above link. And a framework doesn't need to provide necessarily
an implementation for everything. For example the UI of GeditWindow is
of course not re-usable. But there would be a GtideWindow class that
provides at least a useful interface, but I'm sure lots of things could
be implemented in GtideWindow, like some GActions. An application would
just need to fill the gaps: implement some vfuncs, assemble the UI, bind
some GSettings to some properties, add a preferences dialog, and other
*small* glue code.

--
Sébastien

Post by Paolo Borelli

Post by Sébastien Wilmet
Hi,
https://github.com/swilmet/gtide
It's to continue making the gedit source code more re-usable. The goal
https://wiki.gnome.org/Apps/Gedit/ReusableCode
https://wiki.gnome.org/Projects/GtkSourceView/MdiFramework
gtide would be a public API for gedit and gedit plugins. When moving
some code from gedit to gtide, the code in gedit would be removed and
the plugins need to use the gtide API instead.
The other solution is trying to keep the gedit API as-is and writing
- the API docs need to be duplicated (well anyway it's almost
non-existent in gedit).
- it's a lot of code to keep in gedit.
- other annoyances, like: for functions taking a variable number of
parameters, the proxy is a bit more complicated to write.
So I think putting the re-usable code in a shared library is the best
thing to do. That way it can be used directly in other text editors as
well.
When an API break is needed in gtide, we can bump the major version so
it's parallel installable with previous major versions. And that, every
6 months if needed. Who cares if we end up with gtide-17?
About the name, gtide, "edit" in "gedit" has been reversed. It can also
be seen as an acronym for "gedit to IDEs", which is the goal, easing the
creation of new text editors and IDEs. And this could create a "tide" in
the text editors field :) I prefer "gtide" than "gcode" (gcode was the
other name coming to my mind). For me, gedit is not about code, quite
the contrary, I use gedit only for non-programming text editing tasks. A
notepad-like. I guess the Microsoft employees who developed notepad
didn't use notepad to develop it. The same for me and gedit. So it makes
sense. Also, pronouncing "gtide" is more beautiful than "gcode", in my
opinion. And another reason is that there will maybe be a GtkCodeView in
the future, replacing GtkTextView/GtkSourceView.
So, creating gtide, porting the plugins to the gtide API etc, is quite a
bold move for gedit. But such a bold move is needed. The new library
needs to have a different namespace. And it needs to be different than
GtkSource, since the GtkSourceView repo is not suitable to develop a
framework where API breaks will probably be needed.
What do you think?
--
Sébastien
_______________________________________________
gedit-list mailing list
https://mail.gnome.org/mailman/listinfo/gedit-list

_______________________________________________
gedit-list mailing list
https://mail.gnome.org/mailman/listinfo/gedit-list

[Sébastien Wilmet]

Some more reflections.

Post by Sébastien Wilmet

Post by Paolo Borelli
The fact that we have to come up with cool names for the library itself, is
a hint that the library does not have a well defined role.

It has a well defined role. Creating a text editor framework.
GtkSourceView is aware of only one view, one file. The framework would
handle multiple views, i.e. it would be an MDI framework (for text
editors). So there is a clear boundary.

A better name for the library would be "GNOME Text Editor Framework", or
Gtef. But Gtef is a really ugly name in my opinion.

Not all library names have a serious name. It doesn't mean that they
don't have a well defined role. For example Enchant, GNU, projects named
in relation to its creator (Linux, Git), etc.

I must note that you didn't like the name "gspell" either…

Anyway, let's not bikeshed on the name.

Post by Sébastien Wilmet
Sorry if it was not clear. I have a clear idea of how the framework
would be designed (not in the details, but the general architecture).
It's not a new idea, I thought about it already five years ago, so I
https://mail.gnome.org/archives/gedit-list/2011-January/msg00055.html
In short, what would you do if you wanted to create a new text editor,
with a Multiple Document Interface (MDI) and based on GtkSourceView? You
would need to rewrite almost all of the gedit core codebase if you want
to have a decent text editor. A fork is not a good solution, because you
would need to maintain two times 40k lines of code…
So, in those situations, a better idea is to write a library. And, even
better, a framework. A framework is more than a library, like explained
in the above link. And a framework doesn't need to provide necessarily
an implementation for everything. For example the UI of GeditWindow is
of course not re-usable. But there would be a GtideWindow class that
provides at least a useful interface, but I'm sure lots of things could
be implemented in GtideWindow, like some GActions. An application would
just need to fill the gaps: implement some vfuncs, assemble the UI, bind
some GSettings to some properties, add a preferences dialog, and other
*small* glue code.

To describe in more details the plans for the MDI text editor framework
based on GtkSourceView, the idea is to:
- Take the general architecture of the gedit core, i.e. the classes
present in the following diagram:
Loading Image...
(for the sake of the argument, let's imagine that the diagram is
up-to-date)
- Make that OOP design re-usable, by creating a framework on which other
text editors can base their code architecture upon.
- To be more useful, the framework can also provide an implementation
for some features, not just interfaces.

That's the general goal.

Now, how to go from the current gedit codebase to that framework, there
are several solutions. But the plugin system of gedit complicates
dramatically the problem. If there was no gedit plugins, no API, the
gedit codebase could be refactored at will, creating the framework
incrementally, class after class.

So, the perfect solution would be:
1) Keep the gedit API as-is, so the plugins don't need to be ported.
2) Refactor the code incrementally to move the re-usable code to a
shared library, so it can be used by other text editors.
3) Be able to change the API of the framework freely, because creating a
framework is a difficult task, it's difficult to get the API right the
first time (and gedit is currently not perfect).
4) A solution that doesn't take ages to accomplish.
5) Not by forking gedit, because maintenance would be duplicated, at
least temporarily.

For 2) and 3), there is a simple solution: when an API break is needed,
bump the major library version so it's parallel installable with
previous major versions. With a build system where the API version is
not hardcoded everywhere, this is simple to do. See for example the
build system of gspell:
https://git.gnome.org/browse/gspell/tree/configure.ac?id=78c3d417f5a0fb827213f0353386209090658ea5#n43

For achieving 4) and 5), 1) is required, because if plugins need to be
ported to new APIs, it would take way more time.

The tricky part is of course 1), not breaking plugins. Although creating
a framework is itself not an easy task either. So the two together…

Does a perfect solution exist? Or are there conflicting goals? How would
you approach the problem?

To be honest I'm tempted to fork gedit, remove the plugin system, to
have more degrees of freedom to create the framework. The fork of gedit
would be called for example gnotepad, since it would be a streamlined
version of gedit. And for gnotepad I could create the UI that I want
(since I disagree on several points about the current gedit UI).

Or, there is maybe a better practical solution than forking gedit. The
gedit API for plugins could be changed as a set of interfaces. The Gedit
namespace would be used only for those public interfaces. The rest of
the code would need to have another namespace. As long as the interfaces
are still implemented correctly, the plugins would work fine. Then the
codebase with the new namespace can be refactored to create the
framework. The framework would have yet another namespace, of course.

Or the framework could actually have the Gedit namespace, providing the
set of interfaces for plugins. But in this case the initial set of
interfaces must be kept backward compatible, otherwise plugins will
break. So it conflicts with point 3).

Do you see other solutions? (apart from abandoning the idea of the
framework altogether).

And I think keeping the gedit plugin API backward compatible is an
illusionary goal, since for gedit 3 the API has been broken three times
already. So it conflicts with 4). And the solution might be forking
gedit.

And this is almost pure theoretical. And like someone said "The
difference between theory and practice tends to be very small in theory,
but in practice it is very large indeed."

So if I want to do something about it, I need to try a solution and see
how it goes.

--
Sébastien

[Sébastien Wilmet]

Post by Sébastien Wilmet
A better name for the library would be "GNOME Text Editor Framework", or
Gtef. But Gtef is a really ugly name in my opinion.

Oh, or why not GTF?

[Ignacio Casal Quinteiro]

Haven't read all the backlog here, but wouldn't we invest our time in a
better way if we
try to i.e share in a better way some parts of gedit by putting them in
GtkSourceView,
instead of making once again another library with all the overhead that it
means.

Some things that I can think about is snippets which is implemented in
gedit and in builder.
We could take builder's implementation as a starting point and add any
missing feature
from gedit's one.

Another interesting thing is the indentation stuff which currently is also
implemented in
gedit-code-assistance and in builder.

And I am pretty sure there are other things out there that we could move
down the stack.

Regards.

Post by Sébastien Wilmet

Post by Sébastien Wilmet
A better name for the library would be "GNOME Text Editor Framework", or
Gtef. But Gtef is a really ugly name in my opinion.

Oh, or why not GTF?
_______________________________________________
gedit-list mailing list
https://mail.gnome.org/mailman/listinfo/gedit-list

[Sébastien Wilmet]

Post by Ignacio Casal Quinteiro
Haven't read all the backlog here, but wouldn't we invest our time in a
better way if we
try to i.e share in a better way some parts of gedit by putting them in
GtkSourceView,
instead of making once again another library with all the overhead that it
means.
Some things that I can think about is snippets which is implemented in
gedit and in builder.
We could take builder's implementation as a starting point and add any
missing feature
from gedit's one.
Another interesting thing is the indentation stuff which currently is also
implemented in
gedit-code-assistance and in builder.
And I am pretty sure there are other things out there that we could move
down the stack.

Yes, there are still several features that could be moved down to
GtkSourceView. But I'm more interested to make the MDI of gedit
re-usable.

For gCSVedit for example, I'm not interested by the snippets system and
smart indentation. I'm interested to be able to open several files in
different tabs, have a search and replace UI, have the equivalent of
GeditTab to show an infobar when there is a file loading or saving
error, etc.

--
Sébastien

[Paolo Borelli]

Hi Sébastien,

I have some specific answers to other parts of your mail, but I think those
are secondary and can be addressed later

Post by Sébastien Wilmet
So if I want to do something about it, I need to try a solution and see
how it goes.

Absolutely. I 100% agree and this was my main point in my previous mail.
What I am trying to say is to not worry right now if this is going to be a
library that is going to be called gtide or gtef, do not worry on whether
we should use ABI bumps and make it parallel installable, do not worry
about porting gedit plugins, do not worry about porting gedit at all and do
not worry about forking gedit under the name gnotepad.

Just try to factor out the code you want to factor out and once we have a
better idea of what it contains we can discuss about the next steps. Once
you have a prototype, my suggestion would be: 1) try to make a proof of
concept gnotepad (not a gedit fork, just a proof of concept mininal editor
that uses the lib) 2) try to port the gedit core (no plugins) 3) try to
port some other app (latexila, csvedit etc).

Once that is done we will have more clear ideas on how to move forward.

Ciao,

Paolo

Post by Sébastien Wilmet
--
Sébastien
_______________________________________________
gedit-list mailing list
https://mail.gnome.org/mailman/listinfo/gedit-list

[Sébastien Wilmet]

Post by Paolo Borelli

Post by Sébastien Wilmet
So if I want to do something about it, I need to try a solution and see
how it goes.

Absolutely. I 100% agree and this was my main point in my previous mail.
What I am trying to say is to not worry right now if this is going to be a
library that is going to be called gtide or gtef, do not worry on whether
we should use ABI bumps and make it parallel installable, do not worry
about porting gedit plugins, do not worry about porting gedit at all and do
not worry about forking gedit under the name gnotepad.

But all that list of things that I should not worry about is exactly
some practical stuff that will need to be handled at some point.

From time to time, I like to head out of the water and look around me,
see in which direction I'm actually heading to, look at the horizon and
take the time for some reflections to see if navigating with a snorkel
is actually the best way to reach that nearest island.

Post by Paolo Borelli
Just try to factor out the code you want to factor out and once we have a
better idea of what it contains we can discuss about the next steps. Once
you have a prototype, my suggestion would be: 1) try to make a proof of
concept gnotepad (not a gedit fork, just a proof of concept mininal editor
that uses the lib) 2) try to port the gedit core (no plugins) 3) try to
port some other app (latexila, csvedit etc).
Once that is done we will have more clear ideas on how to move forward.

In gedit, the top level class is GeditApp, and at the bottom of the
containment hierarchy there is GeditDocument. I think we agree that the
best way is to take one feature at the bottom of the containment
hierarchy, and make it reusable.

The next big chunk that I want to make reusable is having a container
that contains a GtkSourceView plus one or several info bars at the top.
With a higher-level API to load and save files, that shows an info bar
in case of error, with options to choose e.g. another encoding etc.

But when I proposed to include a GtkSourceTab container to
GtkSourceView, you said it was not a good idea to include that in
GtkSourceView. It could be called GtkSourceViewContainer instead, so it
is more general and can be used in a different context than with a
GtkNotebook.

So, I can dive in the GeditTab code again and factor out some reusable
code. Then we can figure out where to put it so I can use it in
gCSVedit.

--
Sébastien

[Sébastien Wilmet]

Post by Sébastien Wilmet
The next big chunk that I want to make reusable is having a container
that contains a GtkSourceView plus one or several info bars at the top.
With a higher-level API to load and save files, that shows an info bar
in case of error, with options to choose e.g. another encoding etc.
But when I proposed to include a GtkSourceTab container to
GtkSourceView, you said it was not a good idea to include that in
GtkSourceView. It could be called GtkSourceViewContainer instead, so it
is more general and can be used in a different context than with a
GtkNotebook.

Actually, there is a smaller thing that I want to make re-usable first:
get/set file metadata, with the gedit-metadata-manager on Windows and
GVFS metadata on Linux.

At first I wanted to add the relevant API to GtkSourceFile:
https://bugzilla.gnome.org/show_bug.cgi?id=761138

But I came to the conclusion that gedit-metadata-manager is not good
enough for GtkSourceView:
https://bugzilla.gnome.org/show_bug.cgi?id=761515

GtkSourceView has a stable API. GtkSourceView 3.0 was released five
years ago. Not all of the API is perfect, we discovered some API flaws
too late, and we need to wait GSV 4 to fix the problems. See the bugs
filed with the 4.0 target milestone:
https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=113854&product=gtksourceview&target_milestone=4.0

So, where to put the gedit-metadata-manager and the higher-level API to
get/set metadata? Not in GtkSourceView. If the files are still mixed
with all the other gedit files, the risk is that after some time a
contributor modifies the re-usable files to add a gedit-specific thing
to it (like using GSettings). So a better idea is to move the files to
another directory. But to re-use the code in another text editor, the
code would need to be copied manually and adjust the build system
manually (e.g. to add new dependencies, configure options etc). But it's
not just the code that needs to be copied, it's also the *.po files. A
git submodule doesn't solve the problem of sharing *.po files. So, the
easiest solution, from a text editor developer's point of view, is to
use a shared library.

When using a shared library, it solves all the problems: the code
doesn't need to be copied, the *.po files doesn't need to be copied, the
build system of the text editor needs only a small adjustment, and we
can have a nice API documentation of the library available in Devhelp.

That's why I came to the conclusion that a new shared library *is*
needed. And for that new shared library, we can have a different policy
than GSV and break the API more often (with a major version bump each
time an API break is needed).

So, is it clearer like that?

The new library could be named GTF, not gtide, and I can try to keep the
gedit API for plugins as-is, by using GTF under the hood. But I think
it'll not be possible to do that each time, for example when gedit was
ported to GtkSourceFile, the API of gedit has been broken. And when that
happens, my worry is to port all plugins, especially those in Python.

--
Sébastien

[Matěj Cepl]

Post by Sébastien Wilmet
To be honest I'm tempted to fork gedit, remove the plugin
system, to have more degrees of freedom to create the
framework. The fork of gedit would be called for example
gnotepad, since it would be a streamlined version of gedit.
And for gnotepad I could create the UI that I want (since
I disagree on several points about the current gedit UI).

Well, the problem is that gedit without plugins is mostly
useless. Really, does anybody care about functional equivalent
of Notepad?

Matěj

[Sébastien Wilmet]

Post by Matěj Cepl

Post by Sébastien Wilmet
To be honest I'm tempted to fork gedit, remove the plugin
system, to have more degrees of freedom to create the
framework. The fork of gedit would be called for example
gnotepad, since it would be a streamlined version of gedit.
And for gnotepad I could create the UI that I want (since
I disagree on several points about the current gedit UI).

Well, the problem is that gedit without plugins is mostly
useless. Really, does anybody care about functional equivalent
of Notepad?

gnotepad would just be the tip of the iceberg. The interesting part is
the framework. Ideally gnotepad would be, say, < 1000 lines of code. But
it would contain all gedit core functionality.

--
Sébastien

[Matěj Cepl]

Post by Sébastien Wilmet
gnotepad would just be the tip of the iceberg. The interesting
part is the framework. Ideally gnotepad would be, say, < 1000
lines of code. But it would contain all gedit core
functionality.

I think Yet Another Rewrite and creating Yet Another New Text
Editor (compering with Atom, SublimeText, VS Code, and many many
others) is DOA, but what do I know?

Matěj

[Sébastien Wilmet]

Post by Matěj Cepl

Post by Sébastien Wilmet
gnotepad would just be the tip of the iceberg. The interesting
part is the framework. Ideally gnotepad would be, say, < 1000
lines of code. But it would contain all gedit core
functionality.

I think Yet Another Rewrite and creating Yet Another New Text
Editor (compering with Atom, SublimeText, VS Code, and many many
others) is DOA, but what do I know?

I have a very different vision for text editors. Instead of developing
one text editor to rule them all, with a plugin system, I prefer
developing small, specialized text editors. For more background on this,
see the "Why?" section on:
https://wiki.gnome.org/Apps/Gedit/ReusableCode

--
Sébastien