This looks good from my side.

@kfunk is this ok also for KDevelop?

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.

For KDevelop this is fine, I don't think we have any objection.

In D11838#238269, @ngraham wrote:

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.

In D11838#238269, @ngraham wrote:

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?

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:

1. Reject the patch.
2. Accept the patch and Kile should try it out.

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.

In D11838#238742, @ngraham wrote:

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?

In D11838#238728, @dhaumann wrote:

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.

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.

We now have application-local settings. What now? Are we closer to solving this? ...I guess not: Either it's on for all applications or off for all applications. The user still needs to set this up. @cullmann and @ngraham Any comments? ;)

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:

1. Every application now has a separate KTextEditor configuration
2. Every application now has line numbers on by default (that includes Kile)

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.

@mludwig @cullmann Sorry, what I wrote is not correct, since this change is in Kate, not KTextEditor. Sorry for the noise... :)