Kate is an advanced, programmer-and-source-code-centric text editor. It should have line numbers on by default, since these are useful 99+% of the time for those use cases.
BUG: 390870
dhaumann | |
mludwig |
Kate | |
KTextEditor |
Kate is an advanced, programmer-and-source-code-centric text editor. It should have line numbers on by default, since these are useful 99+% of the time for those use cases.
BUG: 390870
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
Not yet good enough, let's have another revision.
BTW, I am fine with this change, since nowadays screens are typically wider, so horizontal space is usually there.
src/utils/kateconfig.cpp | ||
---|---|---|
1240 ↗ | (On Diff #31047) | This is wrong: the set flag indicates that the setting was changed by a user. So you want to keep false here. |
1287 ↗ | (On Diff #31047) | Same here: false is correct. |
1373 ↗ | (On Diff #31047) | This is correct, and the only place that needs change. |
I don't think that this is ok for Kile.
KatePart is an editor component that needs to fit many different contexts. For Kile, I don't see a need to have line numbers switched on by default.
However, it the *default* setting for showing line numbers is made configurable, then this change is fine by me.
So what's our path forward here? Is there a way to only turn on line numbers for Kate itself, and not for the katepart?
That said, I'm still struggling to understand what the problems is with line numbers in Kile. Most of the editors listed at https://beebom.com/best-latex-editors/ have line numbers on by default, including TeXmaker, which is what all of my scientist friends use. Screens are wider than ever before, and average users are going to just maximize the window anyway, making the small amount of horizontal space taken up by the line numbers a non-issue.
On that website four screenshots out of eight show line numbers. And especially in TeXmaker's case, I wouldn't call the amount of space needed for line numbers small.
The point is that line numbers do not bring much added value when editing LaTeX documents. To reduce clutter on Kile's user interface, line numbers should not be shown by default. It's not just a question of horizontal screen space, but also of usefulness/usability.
One suggestion would be to extend the method for creating new views in KTextEditor::Document by adding a parameter for specifying default config values.
For instance, you could create a new interface for KTextEditor::Document that contains the method
virtual View* createView(QWidget *parent, const QLinkedList<QPair<QString, QVariant>>& defaultConfigList, KTextEditor::MainWindow *mainWindow = nullptr) = 0
The method would set the values given in 'defaultConfigList' as default config values when creating a view.
Kile could then create its views as follows:
QLinkedList defaultConfigList; defaultConfigList << qMakePair("ShowLineNumbers", false); KTextEditor::View *view = document->createView(parent, defaultConfigList);
(also see KTextEditor::ConfigInterface for an example of how to create interfaces)
I wouldn't mind seeing it on in KDevelop. From using it though, I really don't need them much in it. Especially since when debugging I can just click on an error and it will take me to the line.
Kate would be nice to have it on. KWrite, probably not, since it's supposed to be "lighter" like Notepad.
As background: in KF5 world, the KTextEditor settings are shared among applications: enabling line numbers in Kate will enable line numbers in KDevelop, Kile, KWrite, ...
Currently, there is no way to show line numbers except in Kile.
I can understand that line numbers may indeed not be to useful. We have two paths forward here:
Given we do not have evidence that line numbers on by default reflect any increase in usability, I would go for 1. for now.
Except if there are better solutions.
Personally, I dislike the idea of passing options in createView for a very simple reason: we have document variables, .kateconfig files, settings on the UI, the command line, the ConfigInterface. Adding yet another way to configure KTextEditor sounds like a bad idea.
If at all, the only clear way is to let an application decide to not share settings with other KTextEditor applications. E.g. KTextEditor::Editor::setUseSharedConfig(bool share).
Since the controversy over this patch reveals that KTextEditor clients may have different needs, perhaps we should move towards allowing clients to have independent settings.
I think that actually makes sense, as a user i am not sure why changing some settings in kile should affect kwrite?
All these mechanisms allow to change "current" config settings, but not their default values, as far as I can see. Passing options to createView would also allow it, e.g., to control which actions should be created. Kile has to delete some actions after creating a view at the moment, which could be avoided. But that's another discussion.
If at all, the only clear way is to let an application decide to not share settings with other KTextEditor applications. E.g. KTextEditor::Editor::setUseSharedConfig(bool share).
I support this idea, but one should maybe also think about whether some settings could be better read/saved using read/writeSessionConfig. "showLineNumbers" could fall into that category.
I think allowing a own configuration per hosting application makes sense.
But I would propose to do this "opt-in".
We could add some application wide flag in the config that triggers "application local" storage, that is default off.
The KTextEditor config pages could allow to change it, if e.g. Kile wants to have this on per default, it just needs to adjust the default by shipping a default kilerc.
Thanks so much, guys! So much improvement in so little time. It's very impressive.
Probably this particular patch is now obsolete. I guess now we need a way for individual KTextEditor-using apps to pre-populate entries in their local rc files or something.
Just to make everyone aware of what this implies:
Especially 2. is something that was @mludwig definitely wanted to avoid...
@mludwig @cullmann Can you both please discuss a solution that works for Kile? If this is not fixed this week during Akademy, it will likely not be fixed until the next KDE Frameworks releases.