Greetings to the community! I use Kate as one of my main editors, but I missed some features there, one of them was the multicursor support, which was recently added, the other was virtual whitespace. With this feature on, the cursor would move like with block selection mode activated, but the selection would behave normally. As far as I know, none of the most used code editors (VS Code, Atom, Emacs, Kate…) has this feature (although there is an old request regarding VS Code on GitHub: https://github.com/microsoft/vscode/issues/13960). I currently use Komodo IDE with virtual space enabled via Scintilla scripting, the the experience is far from ideal and I often switch to Kate for e. g. Dart highlighter or better Find & Replace. It would be great had Kate (and related KDE projects) this feature. I’ve thought about trying it by myself (I’ve already made some PRs regarding KDE), but I don’t have much experience with C++ and I don’t want to mess up your code.
You are free to try, I doubt the code will get any messier ;) But anyways, about your feature request. Rather than giving a high level overview /name, can you tell what you actually want to do that is not possible? Maybe a video or some way to demonstrate clearly what this is about. I do not have the time to go reading internet to discover what this feature is. If you explain clearly, that will make it easier to implement. Moreover, it would really help if you can test it before release, so if you can test alongside feel free to create an issue in the Ktexteditor repo and we can discuss / test / implement it.
I found a KTextEditor::ViewPrivate::wrapCursor() method, which just returns false only if block selection is on. I created another property that allows turning cursor wrapping off (that’s the “virtual whitespace” feature) even if block selection is off. I don’t know how to add the option to Kate menu, but I hope you now get it. Here’s my PR: https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/333 I would also like to use multicursor while having this feature turned on, but it crashes just like it used to crash with block selection mode.
Yes, the issue is that at the moment too many places assume that the cursor does wrap. I agree that it is a useful feature, but this needs some more work, as it will need to work with stuff like dynamic word wrap and co.
So basically, you want to put cursor past the end of the line? Assuming the following text Foo| \n \n with the first cursor at the end of "Foo", you want to create more cursors in the same column in lines below even though the next lines are empty? Something as simple as that is very easy i.e., just add spaces and you are done. But not sure if this is what you want.
However, moving the cursors (after creation) beyond the line end will require some work.
Do you have a use case or an example of what you want to do? Maybe there is a better way to do it.
Exactly, I want to put cursor past the end of the line, I see this is possible to implement in Kate as it’s already a thing in the block selection mode (but if I type a letter in such place ant hit up arrow, it moves one character backwards in addition to moving one line up, I hope this is easy to resolve). For me, I’m just used to cursor behaving like that when programming, but it can have some real use cases, such as typing in particular level of indentation after clicking in that spot; I don’t know how all people use this, but as ye can see in the VS Code issue (https://github.com/microsoft/vscode/issues/13960), many people request that.
This is a comment regarding wrapCursor() method: should cursor be wrapped ? take config + blockselection state in account It seems, whoever wrote this, he planned the creation of such config option.
There are some use cases illustrated in this comment: https://github.com/microsoft/vscode/issues/13960#issuecomment-318700740
More examples described: https://github.com/microsoft/vscode/issues/13960#issuecomment-916160471 I agree with the last point.
Some of the usecases in those comments can be handled with my simple proposal. See the example that I gave above. The only extra work that would need to be done is that you will need to manually move the primary cursor to the desired column for e.g by adding spaces I can put up a patch, and maybe you can try it out to see how well it works in practice?
Can you try the branch https://invent.kde.org/frameworks/ktexteditor/-/commits/work/virtualspace and see if something like that can work?
After playing with your branch a bit, and trying out a couple of things on my own, maybe we can just add a config option for this for people who want to enable it and mark it as experimental? Close to all of the multicursor implementation takes this property into account so it will work there as well. There will be bugs for sure, but if the feature is behind a config I don't see any issues.
> I would also like to use multicursor while having this feature turned on, but it crashes just like it used to crash with block selection mode. Can you expand on that? When does it crash
It crashes when creating a secondary cursor (with alt‐click) beyond the line’s end. I tried your branch, it worked for creating secondary cursor above / below the primary cursor, but I want to move the primary cursor past the end of the line as well (with regular mouse click or arrow keys press), like with the block selection mode; it feels more natural to me than cursor moving back and forth in response to the length of the current line.
A screen recording of my desired behavior (Komodo IDE 12 Scintilla configured with a userscript): https://qu.ax/rWwV.mp4 I’d like Kate to have such option in its menu / settings.
Created an MR for the crash. Tried this out a bit more, I think it needs some work before we think about mainlininng this. Basic stuff is broken, for example text insertion is broken if there are two cursors in the same line. All these issues need to be tracked and fixed first so that we have at least something that is usable
I think before we start to allow some general unwrapped cursor handling, we should release the current multi cursor stuff a few months and fix it to some state we are confident with. The non-wrapping behavior just introduces one more level of complexity I would not begin with before we are sure the multi cursor implementation works reasonably well as is.