I didn't test it even more but think on it from time to time. If my slightly negative comment was OK or too fast judged. And yes it may.

It's almost untested, will try to use it on daily basis.
After think a little about it, I came to this variant. Code lines are unlikely to "join", so why test for comments?

• Don't rely on comments or highlighting

His original post with some more text/hints/questions
https://mail.kde.org/pipermail/kwrite-devel/2018-April/000345.html
He got the advice from @brauch to post here.

As said above, I think some "smart wrap" option and that can be used for it.

Better late than never: I also figured out how to make the plugin's toolview display correctly in KDevelop: https://commits.kde.org/kate/3cd03f408eed2d66ae008fb8349f8b5af24260e9

I think we could do that in two steps:

> ok to have that go in now, thanks!

Abandoned in favor of https://phabricator.kde.org/D9175

:( Sorry that this never got attention.

Thanks for your input Dominik.
In the meanwhile I noticed (again) these "Smart-Return" function (I noticed, and used that a couple of years for a short time period, but forgot that somehow) A reverse version of that should be nice. And somehow the possibility to use that automatically without to todo some special key-stroke when join lines by simple remove the newline character by Del-Key.

@cullmann I think you could give a short hint

As background: inserting the '*' automatically is done by the indenter in cstyle.js. Theorwtically, we could even add a joinLines function to the indenters as well and call it if it exists, and if not use the default implementation. Just an idea... Usually, the motivation for moving something into an indenter boils down to whether a specific behavior is related only to a specific programming language, i.e. when a general purpose solution cannot be done.

Updated as requested.

undesirable qWarning() removed

Hmm, could you remove or comment out:

An extra action looks to me at first sight a little overdone, but an option how join behaves may appropriate.

An option in the settings would work for me, too.
I just don't want to destroy the work-flow of people that rely on the current behavior.

Allowing negative prios makes sense.

I am not sure if the normal join lines should try to be that clever.

I think we merge the change here now.
The tooltip is no real issue, we can try to consolidate what-this-tooltip-inline help an other time if somebody has interest.
Allowing negative prios makes sense.

Hi, I like the improvements, just want some feedback on my questions above.
Still alive?

Whereas I think such an extension is good, I am not sure if the normal join lines should try to be that clever.
ATM it is very "deterministic" what happens and I think people like that.
It would make more sense to have an extra action for such a "smart" variant in my eyes.
What do others think?

I think neither the dialog/spellcheck bar nor the context menu things got any love in the close past.
If you have time to improve this, any patch is welcome!

This works so far in most cases I have tried.

It would be nice someone could explain, or point me where to read, why there is no (more) direct use of Sonnet stuff in KTextEditor/Kate.

I've made a few more usability changes, and renamed the new menu action to "Configure..." because it corresponds to what the action does.

You are right. Please add some comment why one disconnects all things and push it.

Btw., the 2 nullptr in the disconnect can be left out, or?

Btw., the 2 nullptr in the disconnect can be left out, or?
+ a comment for the future would be nice in the code

Sounds reasonable.

This adds a safety against a race-like condition I've seen happen once in KDevelop.
It may not be required to make m_mWin a QPointer but it seemed sensible to do.

updated as requested.

I'm a bit confused... I thought KDevelop had much more advanced plugins/features for this? What does KDevelop need this old plugin for? Non-C/C++ languages or what?

I'm a bit confused... I thought KDevelop had much more advanced plugins/features for this? What does KDevelop need this old plugin for? Non-C/C++ languages or what?

Merged in changes from an older attempt I forgot about (apologies!).

FWIW, inline "what's this" help is something we're considering removing altogether for a variety of reasons (T9986), so I would prefer to ensure user-friendliness via an intuitive UI, tooltips, and non-inline documentation. Often a little inline note can work. Here's an example from Gwenview's settings dialog, which makes use of this paradigm:

I would prefer to set this in the ui file: The maximum is already set to 99.

For the tooltip stuff: I am not sure if that is not inconsistent with the remaining stuff on these pages.

+1 for the negative priority idea, might help some people.

Thanks for the advice! :)

Note: Probably not worth the hassle for this simple patch though :)

Thanks for the patch! Please submit it using Phabricator's Differential/Code Review tools. See https://community.kde.org/Infrastructure/Phabricator for documentation. Since you already have a .patch file, it'll be as easy as pasting the contents into https://phabricator.kde.org/differential/diff/create/. Later on, you can set up arc to make the process even easier.

Not sure how to use Phabricator properly right now, so I'm just throwing stuff at the wall to see what sticks.

Thanks, I can. I'm getting an error in Arcanist, so let me diagnose that and I'll land it.

Looks good to me. Can you commit yourself?

In D15337#322043, @dhaumann wrote:

Solarized dark still only has 28 colors, right? Can you add the missing ones?

• Added three missing definitions

Solarized dark still only has 28 colors, right? Can you add the missing ones?

@dhaumann, I've added these colors to KSyntaxHighlighting over here: D15340

You were right again. For some reason that Others= disappeared from my ~/.config/katesyntaxhighlightingrc so I didn't notice it. Even though it was defined and displaying fine in the GUI. Weird.

• Fixed Others definition

• Some Marker color tweaks to ensure Solarized interaction rule adherence

• Fixed Light scheme Error color

• Solarized Light Region Marker fix and small Dark tweak.

I've fixed the section. I'm actually working on the KSyntaxHighlighting themes now, you'll see those in another patch.

• Fixed section code

Thanks for working on this. Looks good to me - just a minor question about the section for Solarized light.

Going to land this now

Ok with this.

I don't think such a behavior change is wanted.

As said, I agree a fix for the unsaved documents vs. no swap files problem is wanted, but a single use case is not enough to bring back the dbus overhead per document.