gedit and around
[[ There is a crowdfunding for the gedit project. If you appreciate this application and want to see it improved, you can financially support it! ]]
(( As a small parenthesis, I've assembled a page with my statistics about my GNOME contributions (number of git commits in the different modules). Numbers can tell a story, and the story is probably useful for the gedit crowdfunding ;-) )).
I write this blog post to talk more about gedit, its philosophy for the user experience (the external aspects) and trends in its code development (the internals). I will also relate on an improvement to a plugin, to allow new use-cases. To finish with a list of possible topics to talk about the next time.
Some principles for the gedit user experience
Firstly, gedit is a text editor, not an IDE (Integrated Development Environment). It means that the application focuses on editing the text or source code. Features that are out of scope: compile/execute the code, run a debugger, create git commits, read the developer documentation (the API), graphically creating a GUI, and so on. The other tasks can be done with other applications or a terminal.
Secondly, gedit tries to be as simple to use as possible, and simple to learn.
More advanced features are available by enabling plugins (note for Linux
users, there is usually a
gedit-plugins package to install to
have more plugins).
So, nothing new in this area for those who have known gedit for a long time. gedit stays attached to its roots.
Some principles for the gedit development
Correctness first. Clear code. As much re-usable code as possible. Have a DAG of components for the internal architecture. Well-documented APIs. Well-tested code.
gedit is currently not perfect in these areas, but it's the trend when doing refactorings or when writing new code. The goal: making gedit a rock-solid text editor! And re-usable code is more powerful, it enables new low-hanging fruits!
New possible use-cases with the Draw Spaces plugin
The Draw Spaces plugin is not new, I've just improved it recently (the way to configure it).
Screenshot before --> screenshot after.
If you count the check-boxes, it's the same number before and after. But with the new preferences, it's more powerful! Before, the configuration was a list (a set of flags). Now, it is a two-dimensional matrix (a table), with the whitespace character type on one dimension and its location in the text on the other dimension. Note that the way this is presented to the user doesn't look like a matrix or table, it has been a little abstracted away.
New use-cases that are now possible: basically, draw only unwanted whitespaces. Examples of unwanted whitespaces: all kinds of trailing spaces on a line (git doesn't like them), plus possibly tabulations if the indentation/alignment needs to be done with spaces. Note that such a configuration still allows the non-breaking spaces to be drawn at all locations, to distinguish them from normal spaces (since everybody will agree that this is a good thing, there is no configuration for it, it is always enabled when the plugin is enabled).
This functionality is easily available to other applications, I've implemented the new preferences widget in the Tepl library. The drawing of the little symbols in the text area is implemented in GtkSourceView, where I've implemented the new API with the matrix several years ago.
So, a small improvement of a small feature :-)
Other possible topics to talk about
I will probably write other blog posts to relate in more details the following news in gedit and around: the use of the ICU library in Tepl and gspell; other recent work in Tepl (overhaul of file metadata handling, new file loading and saving implementation in progress, and the addition of a myriad of smaller features).
And of course, the development continues, so there will be more news as time flies.
Thanks for your support!