SciTE [1] is the "official" demo-editor for Scintilla and was last updated on March 9th 2024. The history reaches back to 1999.
SciTE [1] is the "official" demo-editor for Scintilla and was last updated on March 9th 2024. The history reaches back to 1999.
Multicursors are the number one editor innovation of the last ten years that developers should get comfortable with-- once you start to use them you won't want to use an editor without them.
With regex, you need to plan everything you need to do and then surgically do it.
With multiple cursors, you only need to know (roughly) where you need to change, the rest you figure it out on the fly.
As for regexps, the syntax in Emacs is hell, but I do know Emcacs has very powerful edit/replace tools.
Video showing this https://youtu.be/lhFNWTAIzOI?t=28
I also haven’t found a use for multiple cursors.
Writing a regex is quick and easy.
* transform a list of field names into different formats (class properties, sql select list, etc.)
* quick and dirty convert delimited text into insert statements or graphql queries or json objects
* really anything I need to change in column mode but with better tracking of words via mod+arrow keys
M-x lsp-rename in emacs, for example works great, if you're using lsp.
Have two thousand strings which all need the same edits? No need to do a find/replace operation, you can do it directly in the editor.
[
"foo bar/2322",
"foo baz/4223",
"foo blah/2232",
...
]
And you need to reformat that into: [
"bar 2322: foo",
"baz 4223: foo",
"blah 2232: foo",
...
]
You can absolutely use a regular expression find/replace to solve this. But using multicursors, you can just highlight the first "foo ", then hold Ctrl+D to select all instances, then hit right arrow key so that your cursors are at "foo |bar/2322" (and nothing is selected) et al, then use shift+right arrow key to select bar, baz, blah, and all other substrings, then use ctrl+X to cut that list to your clipboard. Hit delete key to get rid of the /s and add a space so you can keep the fields separated. Then, use ctrl+arrow to move your cursors to just before foo ("|foo /2322"), paste, hit space. Now you have "bar foo 2322". Repeat the same action to cut all the "foo" substrings, then move your cursor to the end, now type ": " and then paste.You get the idea. It sounds complex, but these are all just comprised of the same fundamental editing patterns-- all of the cursors act as if you had just that one cursor when you press the keys. You have to play with multicursors to really appreciate their power.
Most of the time, someone who is well versed with multicursors and their editor's cursor shortcuts (arrow keys, page up/down, shift/ctrl arrow keys, etc) will be able to complete these sort of textual manipulations much faster than using find/replace.
The benefit of it is that you're left with a cursor in each location, and you can then do absolutely anything that you'd normally do with a single cursor in every place at once. This includes things like copy/paste, which will maintain a separate buffer in each selection. This also includes things that're actually tough to do with normal find/replace -- I could select the bit after a search result and switch it to title-case, for instance.
You can do most things you'd use it for with find/replace. But sometimes it's easier to watch it happen as you type, rather than construct a fairly complex regex with groups and suchlike.
I might be missing something here, but how is making 2000 individual selections better than `:%s/oldstring/newstring/g`?
I'm guessing that you have a rule for setting up those 2000 selection, or something?
I mean, even for like 5 identical edits, the regex is going to be faster, so you must have a short way of performing the multi-selection.
Also when working with lists it is useful, you spawn cursors on , or < or whatever symbol you've got at a fixed location between lines, and then you can manipulate text in any number of otherwise different lines.
It's more or less a way for standaline plugins/programs to provide language-specific functionality like autocompletions, syntax-highlighting, and diagnostic errors (like type errors) independently of a specific editor.
The idea is that standalone programs are made called language servers which can provide these features. Editors tend to communicate with them using JSON-RPC over stdin. So one can only write a language-specific parser once and integrate it with any editor.
Usually (at least in VS Code), there's a third part which is an editor-specific plugin which contains custom code to connect the editor to the language server, but this part is meant to be a thin layer.
I've been wanting/meaning to make a new text editor using SciTE as a base, just adding in that core functionality that I need, but I haven't got around to it.
If this NPN uses flatpacks I'm not really interested though. I want something super lightweight and fast that can be run as close to standalone as possible.
Might be time to move the text editor project to the top of my list, since it seems other people would probably also appreciate it.
Unfortunately, I don’t really see how you could make a standalone GUI app of meaningful scope on Linux, given the platform that “standalone” is usually defined with respect to doesn’t include a widget toolkit or even a font handling library (it does on Windows). I guess going it alone with an OpenGL viewport would work, but that’s also just setting yourself up for pain the minute accessibility, font shaping, or input methods come into the picture.
I won’t begrudge anyone writing their own toolkit or shaper, it’s just, that’s far too much work to do for the sake of being “standalone”. For the ideal of doing everything yourself, yes, I can definitely sympathize, but just getting rid of DT_NEEDED records isn’t much of an ideal.
Fair point. I meant able to run without needing any special libraries above those that can be assumed to be installed on a standard linux desktop.