Anvil piqued my interest especially because it provides a REST API to interact with it opening the door to writing extensions in practically anything, similar to Kakoune in that regard. But what I find odd is that there's no mention of a repo (though it has a link to a Discord server) anywhere on the site as far as I've seen.
Sadly there's no mention of LSP either which is kinda a deal-breaker these days nor anything about tree-sitter. But at the same time this might mean that Anvil is free to experiment with its own solutions without being tied to a standard. Every cloud a silver lining or how it goes.
Gio also seems like a solid choice for the UI.
I hope Anvil becomes more popular, it would be fun to see a new generation of niche text editors duke it out between Lem, Helix and Anvil.
But seriously though, why does everything these days need multiple cursors? It's a confusing visual gimmick in every scenario I've seen it implemented in. I'll take fully fleshed out structural regular expressions or even perl-re over multiple cursors any day. Combined with as vim's [c]onfirm flag you get all the benefits of multiple cursors without all the clunky downsides and weirdness.
When I need to edit the code around next five instance of "foo", but not every instance in the open file, then I don't know how to do that with structural regular expression, but pressing ctr+d five times and then edit what I want is really straight forward.
And I need to edit around a limited version of foo way more often than I need to edit all instances.
I'd watch this twitch stream. Contemporary editors are like 5-axis CNC mills and I'm still banging the rocks together. My occasional use multiple cursors is very basic. Your strategy wouldn't even occur to me.
Ages ago, Suresh Bhavanani (sp?) studied (suboptimum) usage of office and CADD applications. He was hired by the Army Corps of Engineers to help determine why adoption of CADD hadn't resulted in either higher productivity or improved quality.
His theory, which I believe, is various people have various "strategies" of varying merit. But for some reason users didn't (couldn't) readily learn better techniques from each other. IIRC, His two proposals were 1) re-organize user interfaces around tasks, instead of a features and 2) update training materials emphasize strategies.
IIRC, he compared manual and digital drafting. He identified a bunch of implicit and explicit "strategies" for manual work. eg Using ink and mylar, skilled drafters would work right-to-left, to avoid smudging prior work. Many early adopters carried those manual strategies over to CADD. Suboptimal, right? So then Suresh identified a bunch of digital appropriate strategies, leveraging the new tool.
Suresh did the same for spreadsheets.
Any way, this is a too long ramble now ending with the point: It'd be nice to see how others organize their work. I'm sure there's a lot of low hanging fruit "strategies". All the day to day tricks that experts use that don't get captured and explained in our training materials.
It's mostly a matter of taste.
I do use multiple cursors quite often in Sublime Text when needing to edit some CSV or JSON file. It's probably the feature of Sublime Text, why i'm still having the editor around.
It work's extremely well.
I could type ":.,.+5s/findtext/replacetext/g" in vim (and remember the syntax!) or i just could do "ctrl-d, ctrl-d, ctrl-d, ctrl-d, ctrl-d, replacetext" and have a visual, immediate confirmation on what i am doing.
But i bet you, that i'll press ctrl-d 5 times faster than you entering ":.,.+5s/".
You do not have to remember the syntax; you can use Vimscript and you can create a custom keybinding that prompts you for the "findtext" and "replacetext" strings, then apply the search-and-replace operation over the next 5 lines (number of lines is easily adjustable and can be prompted for it, too; it does not have to be hard-coded either).
Vim users don't have to choose between precision and ease of use as you can build macros or mappings that match ANY workflow, creating powerful, customized processes that minimize the need to remember exact syntax or type it all out, for example achieving results similar to multiple cursors but with Vim's inherent efficiency and scalability. So, while Sublime Text's multiple cursors are handy, Vim can match - and even exceed - this functionality with very little setup (emphasis: one time setup!).
(I use VSCodium (which I really enjoy) for Go, PHP, and Elixir; IntelliJ IDEA for Java and Kotlin, and I use both Emacs and Vim for everything else).
What about holding down the shift arrow, pressing the down arrow five times, then ctrl-r? In most IDEs replace with an active selection will default to replacing only in the selection.
I speak vim, but vastly prefer multiple cursors when the editing is less trivial. Say you want to turn
"foo bar" # For the 1st line
"baz qux" # For the 2nd line
into
"bar" # For the foo key
"qux" # For the baz key
With multi cursors, you could select foo and baz and then interactively edit the rest of the line. I'm capable of doing that with vim, but by the time I'd even settled on an approach for it, I'd already be done in the other editor.
I could use Emacs macros to do the same kind of thing, and I've probably used `C-x (` a zillion times to build procedures I could then run 30 more times on the following lines. For quick interaction, I still prefer multi cursors.
Vim, and I'm sure neovim, allow visually selecting an area by lines. If you then type ":" to initiate a search and replace, it will apply only to those lines.
Say I want to change "foo" to "bar" in a single function in my file. I hit "V" to enter by-line visual mode at the top of the function, go to the end of the function and type ":s/foo/bar/g". If there are other words in the function that contain foo as a substring, then ":s/\<foo\>/bar/g".
> If there are other words in the function that contain foo
How would you know that???
So that's the first roundabout eliminated:
- set word selection by default not to have to worry about substrings
But otherwise you're describing a different workflow: while there is no semantic meaning in the "next 5 lines", you actually don't know whether that would be 5 of 7, that's the whole point/benefit of incrementalism, there is in "this function", so block operations are a valid contender and I could also select the function and search&replace within the selection instead of doing word-by-word.
But then the original also works in a more direct way (maybe you actually don't want to replace all "foo" in a function, but skip some of them):
So you would skip your two roundabouts:
- go to the beginning of a function
- go+select to the end of a function
Then proceed with the "direct" way:
- go to your desired word anywhere within the function
- invoke select forward/backward commands until visually reaching the beginning/end of said function (the candidates will all be highlighted)
Thank you for your detailed reply. So let me address the points.
> How would you know that???
Typically I'm working on code that I wrote, or I've been studying it enough that I've gotten to the point that I'm refactoring and editing it. It isn't like a gameshow where I have a blinder on and then the blinder is removed and I'm given a task to perform.
> - set word selection by default not to have to worry about substrings
So you have to do another step? I can pick word selection or not dynamically on a case by case basis without having to go somewhere else and turn word mode on or off. Or maybe I'm misunderstanding how your editor works. At any rate, I don't see how my approach is roundabout -- I directly express if I want complete word matching or not, and I can even mix both types in a single search/replace operation.
I don't understand your next point -- I can select the body of a function without knowing how many lines it has. It isn't clear to me what your approach is, "incrementalism". Are you doing a word search and replace one at a time? I thought we were discussing multi-cursor editing.
> Then proceed with the "direct" way:
> - go to your desired word anywhere within the function
> - invoke select forward/backward commands until visually reaching the beginning/end of said function (the candidates will all be highlighted)
What you've described is just another way of doing it, not fewer steps.
> Typically I'm working on code that I wrote, or I've been studying it enough that I've gotten to the point that I'm refactoring and editing it
That doesn't explain it. You can't know for any "foo" whether all the content, including comments, has "foo" as a subword for any non-trivial amount of text because you're not a computer.
> so you have to do another step?
No, you reduce many steps having to specify word-based selection every time with a cognitive overhead ("If there are other words") with a single default.
> I can pick word selection or not dynamically
So can I, and I don't need to do precision jumping in the middle of a combined text field to do that, but that's a different benefit
> It isn't clear to me what your approach is, "incrementalism"
when instead of counting 5 lines and selecting them you press a selection key the amount of times is needed to select what you need
> I can select the body of a function
and as I've pointed out, that's a different workflow. You've added a "in this semantic block" requirement and mistakenly compare it to the original incremental one
> just another way of doing it, not fewer steps.
it is fewer steps, I've pointed out which steps are not needed, and then there is another condition complicating your simple explanation when it's not a certainty that you actually want to replace everything within a block.
But again, within semantic blocks there are different tradeoffs
You would restrict your regexp to a region. In Emacs you just select a region somehow (like your press ctrl+d five times), then just do the regexp replace.
Notice that you also don't need to write a regex with multiple cursors - instead, you can visually see your selections and changes as you go, using the same editing motions that you would typically use.
I feel exactly the opposite, macros and regexps always felt like I was trying to shoot something blindfolded, it was always awkward and usually didn’t work the first time. Multiple cursors provide immediate visual feedback. Once I started using them they replaced macros and find-and-replace immediately. I don’t use an editor unless it supports multiple cursors. What “clunky downsides and weirdness” are you experiencing?
Multiple cursors are just live visual feedback for editing macros. Generally live visual feedback is a universal good, e.g., I'd argue most innovations in desktop user interfaces for creative apps are using Moore's Law to take modal interfaces and make them live (and correspondingly, non-destructive). E.g., find-as-you-type search and fuzzy finders being a couple examples, as well as most changes to Photoshop, GPU-based rendering IPR views, the entire existence of Lightroom and Ableton Live as apps.
With that said, the reason live visual feedback haven't systemically replaced all previous modal interfaces, the way they have for media editing apps, is because it's easier to picture the result of a text editor (i.e., relative to a HSR change to a photo), so it's not quite as revolutionary for text editing as it is applied elsewhere, I'd still argue it's a universal good though, more visual feedback is always better.
I cannot imagine a workflow without multiple cursors. I use this feature dozens of times every single day. It became a subconscious part of how I edit text.
Some people can craft the perfect command ahead of time to execute an series of editing operations on the first try. Some other people (/raises hand) prefer to visual incremental feedback on an in-progress operation and be able to partially undo mistakes as they go.
With Vim it’s all local decision unless writing a macro or regex substitution would take less time (the structure is very repetitive). Often it’s just n.n.n.n. (Next search occurence and repeat last edit)
Vim is a great editor, and when I see people laboriously clicking to create multiple cursors to do something that a simple s/foo/bar/g would accomplish, I feel sorry for them. However, multiple cursors can be pretty great; I love the implementation in kakoune, where I can make multiple selections and then replace them with the output of piping them through an arbitrary shell command. I like to do this with basic math I write out as inputs to dc and then transform to the computed results using select and pipe.
Would s/foo/bar/g change every foo into bar without also changing every food into bard?
Also in most use cases, clicking for each multicursor is the wrong way to do it.
With multicursor you can:
- Press a shortcut to auto select every instance of the characters that you already have highlighted (which is just s/foo/bar/g with visual feedback before confirming)
- Press your "select next occurrence" shortcut a few times so you're only changing the first few occurrences that you care about.
- Press your "select next occurrence" shortcut to select the instances you want and press your "skip next occurrence" shortcut to skip the instances you want to keep. That way you can change a bunch of "foo"s to "bar"s while keeping all "food"s as "food"s but also keeping those few instances of "foo" that you want to stay as "foo" (such as in comments, imports, tests, etc...)
- Press your "select next occurrence" shortcut (usually ctrl/cmd + d) each time if you literally want to see each instance before moving on to the next. Usually this is when you really want to make sure of something next to one of the occurrences.
- And finally clicking each cursor if there really is no simple pre-existing pattern for where you're trying to make changes
> Would s/foo/bar/g change every foo into bar without also changing every food into bard?
Sure, and if that’s the case you write a better pattern. The replacement s/foo/bar/g applies only to the current line as written. It’s easy to see if it will work or not. But if you also have food on the same line, you can write s/foo\ze\W/bar/g to match foo followed by a non-letter and replace only foo.
> Also in most use cases, clicking for each multicursor is the wrong way to do it.
Maybe, but I’ve sure spent a lot of time pair programming with people who do it, which is why I bring it up. For what it’s worth, I prefer multicursors, and my find-and-replace workflow is much as you describe, albeit entirely keyboard and regex driven. Your average junior programmer who just learned vscode three or four years ago only knows multiclicking though, and I don’t want to kill the momentum by interrupting to point out how they could use their tools better.
I use Vim every day, but sometimes it's simply more convenient to visually confirm how something should be aligned etc., which is where Visual Block mode comes in handy. And Visual Block mode is just multiple cursors limited to a single column, so I can definitely see how multi-cursor support can be a more modern evolution.
I use multiple cursors all the time and rarely use the mouse to create them. Either it's "Add cursor to line ends" (VSCode)/"Split into lines"(Sublime) or just Ctrl+D.
Suppose I'm editing a text file, and I'm working through a tradeoff
between data volume and accuracy, where more accuracy requires
more data. I have an array of 14 sensors, and I can configure them
to take either 100-byte samples or 500-byte samples, and I can take
samples at intervals between 1 and 60 seconds.
Now, I want to know bytes per day, and this is where the math comes in.
I start adding columns. First I duplicate the three existing columns,
since I want to see them next to the result. I can do this by putting
a cursor at the beginning of each row, highlighting the whole thing,
and pasting. I also hit & to line up the pasted selections.
Now, because I don't want to have to think about the stack too hard,
I put 1440 (minutes per day) and 60 (seconds per minute) in before
the interval column.
Now each line has a little dc program on it, like 14 500 * 1440 *
60 * 60 / p.
I then highlight the back half of each row (again, still working
with the same set of cursors the whole time, it takes way longer to
explain this than it does to actually do it.) I type
| dc
and each of my selections gets run through dc. The result is:
Thanks! This is pretty cool. I do often run shell commands on entire lines/ranges of lines in vim, but haven't tried it with just parts of lines. I just tried with vim's rectangular selection, and while it does correctly give the 'dc' output, it replaces entire lines with the output instead of just the selection. I'll have to look into this further.
Enjoy! Kakoune’s selection-verb editing model really clicked for me; I had been a heavy user of visual mode in vim before I switched. The great Unix integration composes really well with the selection model too.
I find multiple cursors very useful, a must-have. However I think there needs to be more "safety" around them. It's very easy to accidentally have multiple cursors active without you knowing, and the next thing you type changed something you didn't intend to. I would appreciate if there was some sort of lock I can apply to multiple cursors, to only use them when I need them and when I'm aware that I'm using them.
> However I think there needs to be more "safety" around them. It's very easy to accidentally have multiple cursors active without you knowing ...
Relatedly, if you've created cursors across many lines (or more lines than fit in your viewport), and for whatever reason you want to move all the cursors to the start or end of lines, you want to press Home/End not once, but twice, due to to possible word wrapping on lines outside your view. I've lost nontrivial work by making this mistake!
Way less mental overhead than macros and much faster for most cases. You might wanna look at them beyond surface level, they\'re actually awesome.
Having both is even better. While I'm not a fan of Helix's selection→action model it's a great example of how macros&multicursors go very well together.
Soon to be on neovim native too, so there's that
Multiple cursors aren't really any different from regex for editing, but are much easier for the layman to pick up and often much quicker for edits where the regex would be complicated and verbose. If my edit-scope is within a single screen or so, I will almost never use regex before multiple cursors. They are incredibly useful for writing new content though (just think about all the times text or code is structurally repetitive with lots of identical boilerplate).
I see multiple cursors as an alternative to macros rather than regexp. There's stuff that is really awkward with regexp, like anything involving multiple lines, for example. But more importantly, macros and multiple cursors have the opportunity to operate at a higher-level, ie. taking into account language syntax and editor modes etc. Regexp is just about text. Having said that when I see people using it they are just doing a glorified regexp replace more often than not.
I use multiple cursors all the time in Kakoune. Say I want to make a change that is very similar on 10 adjacent lines. I could write a regex or macro that does what I want, which will require me doing that with no visual feedback as I build it. Instead, I can put a cursor on each line and see if I’m getting it right as I’m making the changes. To me, it is an easier, more interactive way of doing the things you’d usually do with a macro in Vim.
I use multiple cursors multiple times per hour when programming. I do not like vim and I don't use regex. And I am convinced I am faster this way than I could ever be using vim or regex for common editing operations. They are ubiquitous but imho still underrated.
The point is that single-cursor editing is a special case of multiple-cursor editing. If there's value in any single-cursor editing operations that don't use regex (or other indirectness) then they have value when used with multiple cursors, too.
The mouse doesn't necessarily come into the discussion at all.
While looking into Acme several months back, I actually bumped into this; there just don't seem to be many editors that draw inspiration from Acme's workflow rather than borrowing from things like Vim, Emacs, or more traditional mouse-based GUI editors -- e.g., Notepad++, Sublime, Kate, VS Code, etc -- so Anvil popped up pretty much instantly while searching around for similar concepts.
However, as someone who hadn't, and unfortunately, still hasn't, spent a load of time using Acme, it wasn't super clear to me how they differentiate from each other. I wasn't totally sure whether it was more of a clone made for fun of it, or whether Anvil was trying to solve a genuine issue that Acme wasn't, or was trying to solve in its own distinct way, or perhaps trying to address a gripe with Acme itself, etc.
If anyone working on the project could highlight some of the differences in features and goals, or if anyone who has used one or the other long enough to notice some stuff at a glance, it'd be super helpful as an outsider to both. Superficially, I do see syntax highlighting, but I figure there's probably more going on than that.
Also, is there any sort of publicly accessible version control? I see the source archives, but I couldn't find any sort of mention of git or any other vcs.
FWIW, by the way, I hope asking about a comparison doesn't come across as some sort of dismissive, "what's the point", comment; it was just cool and interesting enough that this isn't the first time I've wanted to ask.
A few of the main differences between Acme and Anvil are:
1. Anvil supports syntax highlighting, as you noted.
2. Anvil allows remote editing over ssh. If you open a file with a name of the form '[username@]host:/path/to/file', then Anvil will establish an SSH connection to the host (if one doesn't already exist) and allow the user to edit the file and execute commands remotely in the context of the window
3. Anvil allows the use of multiple cursors and selections. What's interesting about this is that text manipulation language called "Range Statements" in Anvil uses the current selections in the window as input (the initial ranges on which to operate), and those statements that produce a set of ranges when executed replace the set of selections in the window. Range Statements are mostly equivalent to the Sam language in Acme, which most people refer to as Structural Regular Expressions (but of which Structural Regular Expressions are only a subset of the language). So the practice of selecting text with the mouse or the keyboard, adjusting ranges with expressions, and switching between the two is slightly more tactile than in Acme.
4. Anvil is a bit more convenient to use with the keyboard than Acme. For example, moving up and down with the arrow keys is standard, text can be selected using shift and movement keys, a word can be executed using CTRL-T, and a line by CTRL-Enter, and a number of other common keyboard shortcuts are supported.
5. Anvil has better support for files with spaces in the name
6. Anvil has a special syntax that makes it a bit easier to execute commands or perform searches that contain spaces. If you surround the command or search with lozenges (i.e. ◊|wc -l◊ or ◊search term◊) then executing or searching using the mouse by clicking anywhere within the lozenges executes or searches for the entire delimited string. This is nice for things you do often.
7. Anvil allows searching backwards via clicking, as well as searching for a regexp
8. Anvil borrows from Wily the ability to hit Escape to highlight the recently typed text for easy execution or searching
>whether Anvil was trying to solve a genuine issue that Acme wasn't
The last time I checked Acme used its own text-rendering algorithms and its own fonts (this is the Acme that is part of plan9port) which wouldn't be a problem except that the visual details (I am pretty sure Acme was using bitmapped fonts) clashed pretty strongly with the rest of the system (I was using a Mac at the time).
The browsers do their own text rendering, too, but the rendering is tuned to match the OS the browser is running on.
Point is, although I could've gotten used to the tiny details of how Acme renders text, I despaired of ever getting used to frequently switching my gaze back and forth between Acme's window and the other windows on the Mac.
In contrast, the text in the Anvil window does not clash with all the other windows on my system (which is no longer a Mac, but rather Gnome / Linux). So that is why I rejected Acme quickly after installing it, but am still interested in Anvil (the existence of which I learned about about an hour ago).
How's the feature parity with Acme + plumber + other Plan9 stuff?
This feels like a modernization of Acme and it sounds like a very good idea to me. If it's not immediately a better alternative to VSCode and other IDEs, it can be seen as a platform for integrating external tools and have a cohesive experience (similar to what Emacs offers). I dig it!
I really love working in neovim but this is a frustrating position that much of the community has taken. Editing multiple sites _simultaneously_ is nowhere as intuitive as with VS Code and IntelliJ/Sublime before it.
- Repeat - `.` - is ok for some bulk manipulations but in my opinion it's not as nice because it's after the fact. I like that in VSC I select all the occurrences I want to edit first and then if the selections match my expectations I go ahead.
- Visual mode only lets you work vertically in a contiguous block of text. That's not the same or as convenient as multi-cursor in VSCode where I can select the word "const" for example and ⌘-D to select more occurrences of it anywhere in the buffer, not just above/below, and bulk edit them to "let".
- Macros are often what I lean and they can do far more than multi-cursor editing could but they are far more tedious to string along and repeat when all I want is to change some text in multiple locations.
- Text replacement (sed) is also fine but not as convenient in my opinion.
Either way, neovim will be getting native multi-cursor support and I'm very excited about that because I'm not particularly fond of VS Code (in terms of perf/resource usage) but I recognise (neo)vim doesn't have a monopoly on good ideas.
It seems good but as others have mentioned, LSP/tree sitter pretty much must-have these days.
And I'd like to see inspiration taken from OniVim's "sneak" feature, which is basically link hints (or ace jump) for all the buttons in the UI, which makes mouse actions doable with just the keyboard, in an intuitive way.
This is very interesting, and it's great to see new editors.
But honestly I never got the fascination for the Acme editor. It seems powerful, but relying on mouse input is limiting, slow and imprecise. I'd much rather control my editor using the infinite key combinations of the keyboard I'm already typing on, which is much more comfortable, accurate and faster. It also builds muscle memory that can never be built with an analog input method like the mouse.
Multi-pane editing is also not very useful beyond a single vertical or horizontal split. For anything more complex, a tiling window manager is a more versatile tool that works for any app.
To enable these two functionalities UI elements need to be rendered, which clutters up the UI and takes up considerable screen real-estate. When working in a buffer and keyboard-oriented editor like Vim or Emacs, the screen only needs to show the content itself, which is a much more pleasant environment to work in.
But maybe I'm misunderstanding the benefits of the Acme workflow, and I honestly haven't given it a thorough try, so I'd be happy to read counterpoints.
BTW, I love the font Anvil uses! Is it available somewhere to download?
> It seems powerful, but relying on mouse input is limiting, slow and imprecise.
Anyone who says this, has never played StarCraft.
In practice, some things a much faster with the mouse. You see something, and immediately you can move your cursor there. Text selection is also faster, given the text to be selected fits on the screen.
I have seen this claim online for decades, and it totally contradicts my experience. Some people learned computing before GUIs existed, and that shaped their opinions, but at this point that claim is just a meme repeated over and over on the internet forums.
However, my principal criticism to your point is: any text editor that allows you to use the mouse, also has keyboard shortcuts. It's never one vs the other.
> Anyone who says this, has never played StarCraft.
Ha, I actually loved StarCraft back in the day, and RTS (or what's left of it) is still one of my favorite genres today.
> In practice, some things a much faster with the mouse. You see something, and immediately you can move your cursor there.
I get that, and while it may apply for gaming, that's not always the case for editing text or programming. For one, the keyboard is the primary input device you rely on while editing text. Switching away from it to use the mouse (or touchpad, Trackpoint, etc.) requires conscious effort. Whereas in gaming, particularly with RTS games, your hand is on the mouse most of the time, so there's no context switching.
Yet even RTS games rely heavily on keyboard shortcuts. In competitive gaming, skill is measured by APM (Actions Per Minute), and using both keyboard and mouse efficiently is a critical part of that. I would say that the keyboard is even more important than the mouse, though.
Take a look at this video[1]. Notice that the mouse is only used to select units, issue commands on specific targets, and ocasionally scroll the map. The keyboard instead is used constantly, and even exclusively for short periods of time.
Obviously, text editing and programming proficiency is not measured in APM. We spend much more time thinking about the content than how we input and manipulate it. But if we can remove any friction between using our tools and our output, then this is worth pursuing since this friction adds up over long periods of time.
> Text selection is also faster, given the text to be selected fits on the screen.
I'm not so sure. I can select a word, line, sentence, paragraph, or text between braces in a fraction of the time and effort it would take me to do the same with the mouse. It would also be much more precise.
> Some people learned computing before GUIs existed, and that shaped their opinions, but at this point that claim is just a meme repeated over and over on the internet forums.
That could well be the case, but the history of GUIs and mouse input dates as far back as the 1960s and 70s. Vi, Emacs and Vim were created in the 70s, 80s and 90s, after GUIs were popularized or during that process. Maybe there are legitimate reasons for people to prefer keyboard input beyond it being just a meme?
> However, my principal criticism to your point is: any text editor that allows you to use the mouse, also has keyboard shortcuts. It's never one vs the other.
That's true, and viceversa as well: any editor heavily focused on keyboard shortcuts also allows mouse input. My preference for keyboard input has nothing to do with my editor choice, I just never feel the need to rely on the mouse. This is why I wanted to better understand why someone would prefer mouse input, and why text editors like Acme would be specifically built for this kind of workflow.
mouse or keyboard is really just a preference. you could do mouse 1 sweep-select 2-3 in one window, and move to another mouse 1-3, and move to another do mouse 1-3, ... Or you could do, in case of vi, y$ (or other movements), ^w w (or other way to select other window), (move your cursor) p, ^w w, (move your cursor) p, ... Though I'm biased, because I feel it's much easier to move my mouse than do one of wWbBeE^$fFtThjkl to move my cursor, even though it is a lot faster and efficient to only move a few of my fingers than my whole arm.
Aha, right, cursor movement across large distances is indeed more comfortable with the mouse. This is usually awkward with the keyboard, and requires plugins like EasyMotion, or just holding keys or repeating key combos. I think these movements are rarer than small cursor movements, like jumping to the next character, word, line, etc., or jumping to the matching brace, etc. In these cases using the keyboard is still faster and more precise.
But I was more thinking about controlling the editor itself. Creating new buffers/panes and switching between them is all much faster with a keyboard. For example, I bind `=` and `-` to switch to the previous/next buffer, and Tab to switch to the next pane. I do these actions hundreds of times a day, and they're just a keystroke away. I couldn't imagine having to use the mouse for this. It would be unbearably slow and tedious.
The best part of key bindings is that they can be easily modified to suit any workflow. Whereas with mouse movements you really can't customize them beyond which of the few buttons to click. The movements themselves can't be optimized, unless you go into gesture territory, which has a lot of drawbacks as well.
> Aha, right, cursor movement across large distances is indeed more comfortable with the mouse. This is usually awkward with the keyboard, and requires plugins like EasyMotion, or just holding keys or repeating key combos
Embrace search based navigation. And if you’re using Vim or Emacs, do whatever that can popup a new window with the result of your search and links to their location in the main buffer. And extend that to search in all files of the $PROJECT.
I do use search often as well, but it's not great. You may mistype and land somewhere unintended. Or have to iterate over the results if they're not a unique match, etc. Whereas if the location is visible on screen, it's much easier to go to it with a point and click.
I've been a vim (then neovim) user since 1999 (plus or minus 1 year - basically so long that I don't precisely remember).
I've written so much custom vimscript for things like an irc client, tiling window manager within vim, literate programming, my own slime'ish plug-in, etc, etc, that I even have a prelude.vim, with my own "standard lib" of useful vim functions.
The only point behind this is to say that, you could say, I appreciate and "get" vim.
So after 20+ years of nothing but vim, I felt the urge to try acme because of all the cool videos I kept seeing. And, 20 years of anything is enough to cause burnout.
And you know what - I really, really liked acme. The best way I can describe it is that you may well be slowly for strictly text editing tasks, but more if your attention is left for what you're actually doing, and less is spent playing vimgolf (or even remembering YOUR OWN mappings for YOUR OWN plug-ins- because you accumulate oh so many of them).
It's a simple system, with a few basic primitives, which when approached with a clean mindset - are really very powerful.
The best way to approach acme is NOT to think of it as a text editor, but rather think if it as a replacement for your terminal.
(btw, I use an acme fork called acme2k, with some additional nicities - some of which anvil also has).
In the end, I didn't completely abandon neovim, but now I use neovim in a more acmelike fashion. All my terms are inside neovim, and I frequently pipe from shell to empty buffers, etc.
Basically, try it. It's so different, it's hard to get across in just words. It's like smalltalk - you have to try it to really get it.
Thank you for engaging in the conversation. This is the kind of response I was hoping for. :)
I'm not nearly as experienced with Vim as you are, even though I've been using it for a similar amount of time, along with Emacs. I've never written my own plugins, though have deeply configured them to my preference along the years.
The thing is that I never feel that I'm playing "vimgolf", or that I need to make an effort to remember key bindings. Maybe once I change some things or introduce new behavior it requires a period of adjustment, but for the vast majority of time the actions I need to take to produce an effect are ingrained in my muscle memory. E.g. I don't actively think "how do I select the text between parenthesis", and typing `vi)` just happens automatically with little mental effort. I'm sure it's the same for you and anyone who's used Vim for a while.
In contrast, it's not possible to achieve this with mouse input. You will always have to consciously think about the action you want to take and manipulate the mouse to achieve it. More importantly, this action will always be imprecise given the analog nature of the input, so you might misclick and cause unintended behavior. Additionally, it takes your hands away from the keyboard which you're already using for making content changes. I'm a big fan of the ThinkPad Trackpoint for this reason, but even that is not a perfect solution. All of this combined means that it requires much more effort from the user, to the point where it's personally unbearable every time I've tried it. Both Vim and Emacs support mouse input as well, but I never rely on it for this reason.
> The best way to approach acme is NOT to think of it as a text editor, but rather think if it as a replacement for your terminal.
That's interesting. I kind of don't want that, though. Just like with my editors, I've invested a lot of time and effort to customize my terminal as well. It also has custom key bindings and configuration, and is deeply integrated into my workflow. Emacs, for example, supports embedding terminals and many different shells. I can see the benefit of having better integration with the editor, but all these solutions have some shortcomings that make them inferior to using a standalone terminal IME.
I also prefer the Unix philosophy of using smaller tools that do one thing well, and combining them to fit my workflow. Repurposing my editor for all my tasks doesn't gel nicely with that, otherwise I would be using an IDE. :)
> Basically, try it. It's so different, it's hard to get across in just words. It's like smalltalk - you have to try it to really get it.
Thanks. I've tried Acme a few times over the years, but not extensively, precisely because I get frustrated fairly quickly... I'll give Anvil or acme2k a more serious attempt. But then again, this is all based on personal preferences anyway, so I'm fine with accepting these editors are just not for me.
I’ve spent a fair amount of time with Acme because it’s fun, but you’re not misunderstanding anything. Anyone who unironically tries assert the superiority of their niche editor is delusional and/or full of shit. It’s just personal preference.
I'm not trying to have an argument about the superiority of any specific editor, but to try to better understand those preferences for one workflow over another. I could be missing something that would make my own workflow better.
For example, you could elaborate on what makes Acme fun.
I opened my project with Anvil on a mac (without mouse) and I cant figure out how to open a local file. Skimming through docs and I didnt find it. A video would have been very useful here.
Interesting. I don't know if it will distract me from Acme, but I will try. I'm unsure if I am ready for a rest API interface when the 9p interface to Acme works so well.
I know it has. That's why I said "still". To be honest, yank is also not great. Both terms were invented back in the day the industry hasn't settled yet on copy and paste. For new software, choosing such names is counter-productive.
I read it more as a comment on the library itself, not the UIs that you can create with it.
But, in any case, I find this beautiful because not a single line is wasted on anything that isn't text, yet I can easily see what is what without it hurting my eyes.
We have Emacs/vim at one end of the spectrum and VS Code at the other. What else do we need? At this point I feel like these poor souls waste a lot of their energy to develop something that has perfect solutions already out there. Or you need to come up with something that totally transcends the way we write (ascii) text.
Maybe one of these will grow into emacs+vim+vs code and make them obsolete ? We didn't just spawn in with computers having vs code emacs or vim already installed you know.
I did already write my own comment trying to ask about the goals and state of Anvil when compared to Acme. That said, RE: "Emacs/Vim on one end and VS Code on the other" and "... you need to come up with something totally transcends the way we write" -- the latter is actually the reason why I was genuinely curious.
I haven't had the time to give Acme a proper try myself, so who knows whether I'd hate it or love it or what, but it only took a few minutes of Russ Cox's little introduction video [1] on Acme for me to go, "Whoa, that is unique"; half the concepts gave me a near-instant visceral feeling of simultaneously being disturbed yet also somehow delighted.
I am really unhappy with the direction of modern UI design, and much of software in general, but sometimes I wonder how much of my feelings are truly objective, how much is my own bias, and how I would feel if I grew up in a totally different environment with different stuff. I've kind of always been curious in that sense, if you took a group of people who somehow had been totally isolated from not only computers and software, but our various cultural biases, what would they find to be the most intuitive, and what sort of things would they come up with?
In a similar sense, for better or for worse, that is almost how I felt seeing Russ use Acme; it looked like an editor built by aliens for other gremlin-like aliens.
I can't confirm or deny whether the aliens are right about their editing paradigm, but it is at least something much closer to "transcending the way we write (ascii) text" than most, and so it's cool to see Anvil is at least drawing inspiration from that rather than, say, yet another VS Code.
Anvil piqued my interest especially because it provides a REST API to interact with it opening the door to writing extensions in practically anything, similar to Kakoune in that regard. But what I find odd is that there's no mention of a repo (though it has a link to a Discord server) anywhere on the site as far as I've seen.
Sadly there's no mention of LSP either which is kinda a deal-breaker these days nor anything about tree-sitter. But at the same time this might mean that Anvil is free to experiment with its own solutions without being tied to a standard. Every cloud a silver lining or how it goes.
Gio also seems like a solid choice for the UI.
I hope Anvil becomes more popular, it would be fun to see a new generation of niche text editors duke it out between Lem, Helix and Anvil.
Source code archives are available on the download page: https://anvil-editor.net/download/
But as you said I couldn't find a repo.
It is however open-source (MIT license).
> multiple cursors
But seriously though, why does everything these days need multiple cursors? It's a confusing visual gimmick in every scenario I've seen it implemented in. I'll take fully fleshed out structural regular expressions or even perl-re over multiple cursors any day. Combined with as vim's [c]onfirm flag you get all the benefits of multiple cursors without all the clunky downsides and weirdness.
When I need to edit the code around next five instance of "foo", but not every instance in the open file, then I don't know how to do that with structural regular expression, but pressing ctr+d five times and then edit what I want is really straight forward.
And I need to edit around a limited version of foo way more often than I need to edit all instances.
I'd watch this twitch stream. Contemporary editors are like 5-axis CNC mills and I'm still banging the rocks together. My occasional use multiple cursors is very basic. Your strategy wouldn't even occur to me.
Ages ago, Suresh Bhavanani (sp?) studied (suboptimum) usage of office and CADD applications. He was hired by the Army Corps of Engineers to help determine why adoption of CADD hadn't resulted in either higher productivity or improved quality.
His theory, which I believe, is various people have various "strategies" of varying merit. But for some reason users didn't (couldn't) readily learn better techniques from each other. IIRC, His two proposals were 1) re-organize user interfaces around tasks, instead of a features and 2) update training materials emphasize strategies.
IIRC, he compared manual and digital drafting. He identified a bunch of implicit and explicit "strategies" for manual work. eg Using ink and mylar, skilled drafters would work right-to-left, to avoid smudging prior work. Many early adopters carried those manual strategies over to CADD. Suboptimal, right? So then Suresh identified a bunch of digital appropriate strategies, leveraging the new tool.
Suresh did the same for spreadsheets.
Any way, this is a too long ramble now ending with the point: It'd be nice to see how others organize their work. I'm sure there's a lot of low hanging fruit "strategies". All the day to day tricks that experts use that don't get captured and explained in our training materials.
In vim, to replace in the next 5 lines (not instances)
In neovim, you'll see a preview of the changes as you type the regexp. Neovim is really good.It's mostly a matter of taste. I do use multiple cursors quite often in Sublime Text when needing to edit some CSV or JSON file. It's probably the feature of Sublime Text, why i'm still having the editor around. It work's extremely well.
I could type ":.,.+5s/findtext/replacetext/g" in vim (and remember the syntax!) or i just could do "ctrl-d, ctrl-d, ctrl-d, ctrl-d, ctrl-d, replacetext" and have a visual, immediate confirmation on what i am doing. But i bet you, that i'll press ctrl-d 5 times faster than you entering ":.,.+5s/".
You do not have to remember the syntax; you can use Vimscript and you can create a custom keybinding that prompts you for the "findtext" and "replacetext" strings, then apply the search-and-replace operation over the next 5 lines (number of lines is easily adjustable and can be prompted for it, too; it does not have to be hard-coded either).
Vim users don't have to choose between precision and ease of use as you can build macros or mappings that match ANY workflow, creating powerful, customized processes that minimize the need to remember exact syntax or type it all out, for example achieving results similar to multiple cursors but with Vim's inherent efficiency and scalability. So, while Sublime Text's multiple cursors are handy, Vim can match - and even exceed - this functionality with very little setup (emphasis: one time setup!).
(I use VSCodium (which I really enjoy) for Go, PHP, and Elixir; IntelliJ IDEA for Java and Kotlin, and I use both Emacs and Vim for everything else).
I more commonly solve a problem like this one with /findtext<CR>creplacetext<Esc>n.n.n.n.
Remembering the syntax is not a problem here. Learning it in the first place, on the other hand...
I do like multiple cursors though. I end up switching to VSCode a couple times a week to do things where it's the right tool for the job.
What about holding down the shift arrow, pressing the down arrow five times, then ctrl-r? In most IDEs replace with an active selection will default to replacing only in the selection.
I speak vim, but vastly prefer multiple cursors when the editing is less trivial. Say you want to turn
into With multi cursors, you could select foo and baz and then interactively edit the rest of the line. I'm capable of doing that with vim, but by the time I'd even settled on an approach for it, I'd already be done in the other editor.I could use Emacs macros to do the same kind of thing, and I've probably used `C-x (` a zillion times to build procedures I could then run 30 more times on the following lines. For quick interaction, I still prefer multi cursors.
Vim can do multiple cursors as long as they start on the same column: ff<ctrl-v>jdw
For longer distance, I use search navigation, faster than scanning where to put the cursors.
But then you'd have to count beforehand and have no good way to correct instead of just going off that sweet immediate visual feedback
Vim, and I'm sure neovim, allow visually selecting an area by lines. If you then type ":" to initiate a search and replace, it will apply only to those lines.
Why would I want to go via this roundabout way? What happens if I decide to add/remove one more line to the mix later?
Say I want to change "foo" to "bar" in a single function in my file. I hit "V" to enter by-line visual mode at the top of the function, go to the end of the function and type ":s/foo/bar/g". If there are other words in the function that contain foo as a substring, then ":s/\<foo\>/bar/g".
Please describe your non-roundabout way then.
> If there are other words in the function that contain foo
How would you know that???
So that's the first roundabout eliminated:
- set word selection by default not to have to worry about substrings
But otherwise you're describing a different workflow: while there is no semantic meaning in the "next 5 lines", you actually don't know whether that would be 5 of 7, that's the whole point/benefit of incrementalism, there is in "this function", so block operations are a valid contender and I could also select the function and search&replace within the selection instead of doing word-by-word.
But then the original also works in a more direct way (maybe you actually don't want to replace all "foo" in a function, but skip some of them):
So you would skip your two roundabouts:
- go to the beginning of a function
- go+select to the end of a function
Then proceed with the "direct" way:
- go to your desired word anywhere within the function
- invoke select forward/backward commands until visually reaching the beginning/end of said function (the candidates will all be highlighted)
Thank you for your detailed reply. So let me address the points.
> How would you know that???
Typically I'm working on code that I wrote, or I've been studying it enough that I've gotten to the point that I'm refactoring and editing it. It isn't like a gameshow where I have a blinder on and then the blinder is removed and I'm given a task to perform.
> - set word selection by default not to have to worry about substrings
So you have to do another step? I can pick word selection or not dynamically on a case by case basis without having to go somewhere else and turn word mode on or off. Or maybe I'm misunderstanding how your editor works. At any rate, I don't see how my approach is roundabout -- I directly express if I want complete word matching or not, and I can even mix both types in a single search/replace operation.
I don't understand your next point -- I can select the body of a function without knowing how many lines it has. It isn't clear to me what your approach is, "incrementalism". Are you doing a word search and replace one at a time? I thought we were discussing multi-cursor editing.
> Then proceed with the "direct" way: > - go to your desired word anywhere within the function > - invoke select forward/backward commands until visually reaching the beginning/end of said function (the candidates will all be highlighted)
What you've described is just another way of doing it, not fewer steps.
> Typically I'm working on code that I wrote, or I've been studying it enough that I've gotten to the point that I'm refactoring and editing it
That doesn't explain it. You can't know for any "foo" whether all the content, including comments, has "foo" as a subword for any non-trivial amount of text because you're not a computer.
> so you have to do another step?
No, you reduce many steps having to specify word-based selection every time with a cognitive overhead ("If there are other words") with a single default.
> I can pick word selection or not dynamically
So can I, and I don't need to do precision jumping in the middle of a combined text field to do that, but that's a different benefit
> It isn't clear to me what your approach is, "incrementalism"
when instead of counting 5 lines and selecting them you press a selection key the amount of times is needed to select what you need
> I can select the body of a function
and as I've pointed out, that's a different workflow. You've added a "in this semantic block" requirement and mistakenly compare it to the original incremental one
> just another way of doing it, not fewer steps.
it is fewer steps, I've pointed out which steps are not needed, and then there is another condition complicating your simple explanation when it's not a certainty that you actually want to replace everything within a block. But again, within semantic blocks there are different tradeoffs
I think even the people advocating these stupid keyboard combinations don't really use them... they just think that it makes them sound smart.
There is a way to express your opinion without insulting people about something you have no way of knowing.
As a simple matter of fact, I have been using vim since the mid-ish 90s every day and do exactly what you claimed don't really do.
You would restrict your regexp to a region. In Emacs you just select a region somehow (like your press ctrl+d five times), then just do the regexp replace.
Notice that you also don't need to write a regex with multiple cursors - instead, you can visually see your selections and changes as you go, using the same editing motions that you would typically use.
I feel exactly the opposite, macros and regexps always felt like I was trying to shoot something blindfolded, it was always awkward and usually didn’t work the first time. Multiple cursors provide immediate visual feedback. Once I started using them they replaced macros and find-and-replace immediately. I don’t use an editor unless it supports multiple cursors. What “clunky downsides and weirdness” are you experiencing?
For the record, there are plugins (for e.g. Emacs) that provide visual feedback on regex operations.
Using :%s instead of :s lets you preview in real-time what a regex substitution will do while you are typing it.
Multiple cursors are just live visual feedback for editing macros. Generally live visual feedback is a universal good, e.g., I'd argue most innovations in desktop user interfaces for creative apps are using Moore's Law to take modal interfaces and make them live (and correspondingly, non-destructive). E.g., find-as-you-type search and fuzzy finders being a couple examples, as well as most changes to Photoshop, GPU-based rendering IPR views, the entire existence of Lightroom and Ableton Live as apps.
With that said, the reason live visual feedback haven't systemically replaced all previous modal interfaces, the way they have for media editing apps, is because it's easier to picture the result of a text editor (i.e., relative to a HSR change to a photo), so it's not quite as revolutionary for text editing as it is applied elsewhere, I'd still argue it's a universal good though, more visual feedback is always better.
I cannot imagine a workflow without multiple cursors. I use this feature dozens of times every single day. It became a subconscious part of how I edit text.
Some people can craft the perfect command ahead of time to execute an series of editing operations on the first try. Some other people (/raises hand) prefer to visual incremental feedback on an in-progress operation and be able to partially undo mistakes as they go.
With Vim it’s all local decision unless writing a macro or regex substitution would take less time (the structure is very repetitive). Often it’s just n.n.n.n. (Next search occurence and repeat last edit)
People coming from word or notepad have no idea what 'n.n.n.n.' is supposed to be - they know how a cursor works though.
Vim is a great editor, and when I see people laboriously clicking to create multiple cursors to do something that a simple s/foo/bar/g would accomplish, I feel sorry for them. However, multiple cursors can be pretty great; I love the implementation in kakoune, where I can make multiple selections and then replace them with the output of piping them through an arbitrary shell command. I like to do this with basic math I write out as inputs to dc and then transform to the computed results using select and pipe.
Would s/foo/bar/g change every foo into bar without also changing every food into bard?
Also in most use cases, clicking for each multicursor is the wrong way to do it.
With multicursor you can:
- Press a shortcut to auto select every instance of the characters that you already have highlighted (which is just s/foo/bar/g with visual feedback before confirming)
- Press your "select next occurrence" shortcut a few times so you're only changing the first few occurrences that you care about.
- Press your "select next occurrence" shortcut to select the instances you want and press your "skip next occurrence" shortcut to skip the instances you want to keep. That way you can change a bunch of "foo"s to "bar"s while keeping all "food"s as "food"s but also keeping those few instances of "foo" that you want to stay as "foo" (such as in comments, imports, tests, etc...)
- Press your "select next occurrence" shortcut (usually ctrl/cmd + d) each time if you literally want to see each instance before moving on to the next. Usually this is when you really want to make sure of something next to one of the occurrences.
- And finally clicking each cursor if there really is no simple pre-existing pattern for where you're trying to make changes
> Would s/foo/bar/g change every foo into bar without also changing every food into bard?
Sure, and if that’s the case you write a better pattern. The replacement s/foo/bar/g applies only to the current line as written. It’s easy to see if it will work or not. But if you also have food on the same line, you can write s/foo\ze\W/bar/g to match foo followed by a non-letter and replace only foo.
> Also in most use cases, clicking for each multicursor is the wrong way to do it.
Maybe, but I’ve sure spent a lot of time pair programming with people who do it, which is why I bring it up. For what it’s worth, I prefer multicursors, and my find-and-replace workflow is much as you describe, albeit entirely keyboard and regex driven. Your average junior programmer who just learned vscode three or four years ago only knows multiclicking though, and I don’t want to kill the momentum by interrupting to point out how they could use their tools better.
In vim, you can do s/foo/bar/gc to iteratively confirm or skip each replacement.
I use Vim every day, but sometimes it's simply more convenient to visually confirm how something should be aligned etc., which is where Visual Block mode comes in handy. And Visual Block mode is just multiple cursors limited to a single column, so I can definitely see how multi-cursor support can be a more modern evolution.
I use multiple cursors all the time and rarely use the mouse to create them. Either it's "Add cursor to line ends" (VSCode)/"Split into lines"(Sublime) or just Ctrl+D.
Can you give an example of using dc like this? Seems like something I would find really useful!
Absolutely!
Suppose I'm editing a text file, and I'm working through a tradeoff between data volume and accuracy, where more accuracy requires more data. I have an array of 14 sensors, and I can configure them to take either 100-byte samples or 500-byte samples, and I can take samples at intervals between 1 and 60 seconds.
So I make myself a little table:
Then I duplicate it: I'm using kakoune, so I can put my cursor on the 100 in the first duplicate row, press C twice, then press r5, and now I have this table: Now, I want to know bytes per day, and this is where the math comes in. I start adding columns. First I duplicate the three existing columns, since I want to see them next to the result. I can do this by putting a cursor at the beginning of each row, highlighting the whole thing, and pasting. I also hit & to line up the pasted selections. Now, because I don't want to have to think about the stack too hard, I put 1440 (minutes per day) and 60 (seconds per minute) in before the interval column. Then I add my operations. And keep in mind I'm still using multiple cursors, so all this stuff is just getting typed one time. Now each line has a little dc program on it, like 14 500 * 1440 * 60 * 60 / p.I then highlight the back half of each row (again, still working with the same set of cursors the whole time, it takes way longer to explain this than it does to actually do it.) I type
and each of my selections gets run through dc. The result is: That's not super readable, so I cursor over three times (multiselection is still active!) and insert commas, and then I do it again: The result is I've done a quick back-of-the-envelope calculation on how much data I need to handle in each scenario.Thanks! This is pretty cool. I do often run shell commands on entire lines/ranges of lines in vim, but haven't tried it with just parts of lines. I just tried with vim's rectangular selection, and while it does correctly give the 'dc' output, it replaces entire lines with the output instead of just the selection. I'll have to look into this further.
Enjoy! Kakoune’s selection-verb editing model really clicked for me; I had been a heavy user of visual mode in vim before I switched. The great Unix integration composes really well with the selection model too.
Replying to my own post for a couple of follow on comments:
1. I wrote this comment using kakoune as the editor under w3m
2. I don’t know emacs as well as I’d like to. Anyone want to chime in on how you’d do this in emacs?
I find multiple cursors very useful, a must-have. However I think there needs to be more "safety" around them. It's very easy to accidentally have multiple cursors active without you knowing, and the next thing you type changed something you didn't intend to. I would appreciate if there was some sort of lock I can apply to multiple cursors, to only use them when I need them and when I'm aware that I'm using them.
> However I think there needs to be more "safety" around them. It's very easy to accidentally have multiple cursors active without you knowing ...
Relatedly, if you've created cursors across many lines (or more lines than fit in your viewport), and for whatever reason you want to move all the cursors to the start or end of lines, you want to press Home/End not once, but twice, due to to possible word wrapping on lines outside your view. I've lost nontrivial work by making this mistake!
Way less mental overhead than macros and much faster for most cases. You might wanna look at them beyond surface level, they\'re actually awesome.
Having both is even better. While I'm not a fan of Helix's selection→action model it's a great example of how macros&multicursors go very well together. Soon to be on neovim native too, so there's that
Multiple cursors aren't really any different from regex for editing, but are much easier for the layman to pick up and often much quicker for edits where the regex would be complicated and verbose. If my edit-scope is within a single screen or so, I will almost never use regex before multiple cursors. They are incredibly useful for writing new content though (just think about all the times text or code is structurally repetitive with lots of identical boilerplate).
I see multiple cursors as an alternative to macros rather than regexp. There's stuff that is really awkward with regexp, like anything involving multiple lines, for example. But more importantly, macros and multiple cursors have the opportunity to operate at a higher-level, ie. taking into account language syntax and editor modes etc. Regexp is just about text. Having said that when I see people using it they are just doing a glorified regexp replace more often than not.
I use multiple cursors all the time in Kakoune. Say I want to make a change that is very similar on 10 adjacent lines. I could write a regex or macro that does what I want, which will require me doing that with no visual feedback as I build it. Instead, I can put a cursor on each line and see if I’m getting it right as I’m making the changes. To me, it is an easier, more interactive way of doing the things you’d usually do with a macro in Vim.
I use multiple cursors multiple times per hour when programming. I do not like vim and I don't use regex. And I am convinced I am faster this way than I could ever be using vim or regex for common editing operations. They are ubiquitous but imho still underrated.
Why don't you use regex for all editing in the single-cursor case as well then?
If I want to change a word on one line, I find it faster to do <esc>cw replacetext rather than use the mouse to select the text and then replace text.
If I want to do that on 2-3 lines, I just use /findtext n and . to redo the prev command.
Anything more than that becomes a full search/replace.
Ymmv. It's just what I find efficient, given my muscle memory.
The point is that single-cursor editing is a special case of multiple-cursor editing. If there's value in any single-cursor editing operations that don't use regex (or other indirectness) then they have value when used with multiple cursors, too.
The mouse doesn't necessarily come into the discussion at all.
Two rules of success:
1. Be attractive
2. Don't be unattractive
Lack of multi cursor supprot is unattractive in current era.
Tom Brady agrees.
While looking into Acme several months back, I actually bumped into this; there just don't seem to be many editors that draw inspiration from Acme's workflow rather than borrowing from things like Vim, Emacs, or more traditional mouse-based GUI editors -- e.g., Notepad++, Sublime, Kate, VS Code, etc -- so Anvil popped up pretty much instantly while searching around for similar concepts.
However, as someone who hadn't, and unfortunately, still hasn't, spent a load of time using Acme, it wasn't super clear to me how they differentiate from each other. I wasn't totally sure whether it was more of a clone made for fun of it, or whether Anvil was trying to solve a genuine issue that Acme wasn't, or was trying to solve in its own distinct way, or perhaps trying to address a gripe with Acme itself, etc.
If anyone working on the project could highlight some of the differences in features and goals, or if anyone who has used one or the other long enough to notice some stuff at a glance, it'd be super helpful as an outsider to both. Superficially, I do see syntax highlighting, but I figure there's probably more going on than that.
Also, is there any sort of publicly accessible version control? I see the source archives, but I couldn't find any sort of mention of git or any other vcs.
FWIW, by the way, I hope asking about a comparison doesn't come across as some sort of dismissive, "what's the point", comment; it was just cool and interesting enough that this isn't the first time I've wanted to ask.
A few of the main differences between Acme and Anvil are:
1. Anvil supports syntax highlighting, as you noted.
2. Anvil allows remote editing over ssh. If you open a file with a name of the form '[username@]host:/path/to/file', then Anvil will establish an SSH connection to the host (if one doesn't already exist) and allow the user to edit the file and execute commands remotely in the context of the window
3. Anvil allows the use of multiple cursors and selections. What's interesting about this is that text manipulation language called "Range Statements" in Anvil uses the current selections in the window as input (the initial ranges on which to operate), and those statements that produce a set of ranges when executed replace the set of selections in the window. Range Statements are mostly equivalent to the Sam language in Acme, which most people refer to as Structural Regular Expressions (but of which Structural Regular Expressions are only a subset of the language). So the practice of selecting text with the mouse or the keyboard, adjusting ranges with expressions, and switching between the two is slightly more tactile than in Acme.
4. Anvil is a bit more convenient to use with the keyboard than Acme. For example, moving up and down with the arrow keys is standard, text can be selected using shift and movement keys, a word can be executed using CTRL-T, and a line by CTRL-Enter, and a number of other common keyboard shortcuts are supported.
5. Anvil has better support for files with spaces in the name
6. Anvil has a special syntax that makes it a bit easier to execute commands or perform searches that contain spaces. If you surround the command or search with lozenges (i.e. ◊|wc -l◊ or ◊search term◊) then executing or searching using the mouse by clicking anywhere within the lozenges executes or searches for the entire delimited string. This is nice for things you do often.
7. Anvil allows searching backwards via clicking, as well as searching for a regexp
8. Anvil borrows from Wily the ability to hit Escape to highlight the recently typed text for easy execution or searching
>whether Anvil was trying to solve a genuine issue that Acme wasn't
The last time I checked Acme used its own text-rendering algorithms and its own fonts (this is the Acme that is part of plan9port) which wouldn't be a problem except that the visual details (I am pretty sure Acme was using bitmapped fonts) clashed pretty strongly with the rest of the system (I was using a Mac at the time).
The browsers do their own text rendering, too, but the rendering is tuned to match the OS the browser is running on.
Point is, although I could've gotten used to the tiny details of how Acme renders text, I despaired of ever getting used to frequently switching my gaze back and forth between Acme's window and the other windows on the Mac.
In contrast, the text in the Anvil window does not clash with all the other windows on my system (which is no longer a Mac, but rather Gnome / Linux). So that is why I rejected Acme quickly after installing it, but am still interested in Anvil (the existence of which I learned about about an hour ago).
How's the feature parity with Acme + plumber + other Plan9 stuff?
This feels like a modernization of Acme and it sounds like a very good idea to me. If it's not immediately a better alternative to VSCode and other IDEs, it can be seen as a platform for integrating external tools and have a cohesive experience (similar to what Emacs offers). I dig it!
You don't need more than one cursor in vim:
https://medium.com/@schtoeffel/you-don-t-need-more-than-one-...
But if you really want it:
https://github.com/mg979/vim-visual-multi
I really love working in neovim but this is a frustrating position that much of the community has taken. Editing multiple sites _simultaneously_ is nowhere as intuitive as with VS Code and IntelliJ/Sublime before it.
- Repeat - `.` - is ok for some bulk manipulations but in my opinion it's not as nice because it's after the fact. I like that in VSC I select all the occurrences I want to edit first and then if the selections match my expectations I go ahead.
- Visual mode only lets you work vertically in a contiguous block of text. That's not the same or as convenient as multi-cursor in VSCode where I can select the word "const" for example and ⌘-D to select more occurrences of it anywhere in the buffer, not just above/below, and bulk edit them to "let".
- Macros are often what I lean and they can do far more than multi-cursor editing could but they are far more tedious to string along and repeat when all I want is to change some text in multiple locations.
- Text replacement (sed) is also fine but not as convenient in my opinion.
Either way, neovim will be getting native multi-cursor support and I'm very excited about that because I'm not particularly fond of VS Code (in terms of perf/resource usage) but I recognise (neo)vim doesn't have a monopoly on good ideas.
There's also vis[0]
It is an editor that combines best parts from vim and plan9 sam[1] (multiple cursors, structural regular expressions).
0 - https://github.com/martanne/vis
1 - https://en.wikipedia.org/wiki/Sam_(text_editor)
I may not need it, but every operation they demonstrated is significantly slower than using multiple cursors, so I definitely want it.
I'm on M2 Mac (Sonoma 14.5). How to run this?
./anvil
[1] 25270 killed ./anvil
chmod +x, xattr -dr com.apple.quarantine etc don't work.
It seems good but as others have mentioned, LSP/tree sitter pretty much must-have these days.
And I'd like to see inspiration taken from OniVim's "sneak" feature, which is basically link hints (or ace jump) for all the buttons in the UI, which makes mouse actions doable with just the keyboard, in an intuitive way.
If this can be compiled into WASM and embedded in a web page...
ad is another text editor inspired by Acme:
https://github.com/sminez/ad
https://www.youtube.com/watch?v=jb2pAi5hLUg
This is very interesting, and it's great to see new editors.
But honestly I never got the fascination for the Acme editor. It seems powerful, but relying on mouse input is limiting, slow and imprecise. I'd much rather control my editor using the infinite key combinations of the keyboard I'm already typing on, which is much more comfortable, accurate and faster. It also builds muscle memory that can never be built with an analog input method like the mouse.
Multi-pane editing is also not very useful beyond a single vertical or horizontal split. For anything more complex, a tiling window manager is a more versatile tool that works for any app.
To enable these two functionalities UI elements need to be rendered, which clutters up the UI and takes up considerable screen real-estate. When working in a buffer and keyboard-oriented editor like Vim or Emacs, the screen only needs to show the content itself, which is a much more pleasant environment to work in.
But maybe I'm misunderstanding the benefits of the Acme workflow, and I honestly haven't given it a thorough try, so I'd be happy to read counterpoints.
BTW, I love the font Anvil uses! Is it available somewhere to download?
> It seems powerful, but relying on mouse input is limiting, slow and imprecise.
Anyone who says this, has never played StarCraft.
In practice, some things a much faster with the mouse. You see something, and immediately you can move your cursor there. Text selection is also faster, given the text to be selected fits on the screen.
I have seen this claim online for decades, and it totally contradicts my experience. Some people learned computing before GUIs existed, and that shaped their opinions, but at this point that claim is just a meme repeated over and over on the internet forums.
However, my principal criticism to your point is: any text editor that allows you to use the mouse, also has keyboard shortcuts. It's never one vs the other.
> Anyone who says this, has never played StarCraft.
Ha, I actually loved StarCraft back in the day, and RTS (or what's left of it) is still one of my favorite genres today.
> In practice, some things a much faster with the mouse. You see something, and immediately you can move your cursor there.
I get that, and while it may apply for gaming, that's not always the case for editing text or programming. For one, the keyboard is the primary input device you rely on while editing text. Switching away from it to use the mouse (or touchpad, Trackpoint, etc.) requires conscious effort. Whereas in gaming, particularly with RTS games, your hand is on the mouse most of the time, so there's no context switching.
Yet even RTS games rely heavily on keyboard shortcuts. In competitive gaming, skill is measured by APM (Actions Per Minute), and using both keyboard and mouse efficiently is a critical part of that. I would say that the keyboard is even more important than the mouse, though.
Take a look at this video[1]. Notice that the mouse is only used to select units, issue commands on specific targets, and ocasionally scroll the map. The keyboard instead is used constantly, and even exclusively for short periods of time.
Obviously, text editing and programming proficiency is not measured in APM. We spend much more time thinking about the content than how we input and manipulate it. But if we can remove any friction between using our tools and our output, then this is worth pursuing since this friction adds up over long periods of time.
> Text selection is also faster, given the text to be selected fits on the screen.
I'm not so sure. I can select a word, line, sentence, paragraph, or text between braces in a fraction of the time and effort it would take me to do the same with the mouse. It would also be much more precise.
> Some people learned computing before GUIs existed, and that shaped their opinions, but at this point that claim is just a meme repeated over and over on the internet forums.
That could well be the case, but the history of GUIs and mouse input dates as far back as the 1960s and 70s. Vi, Emacs and Vim were created in the 70s, 80s and 90s, after GUIs were popularized or during that process. Maybe there are legitimate reasons for people to prefer keyboard input beyond it being just a meme?
> However, my principal criticism to your point is: any text editor that allows you to use the mouse, also has keyboard shortcuts. It's never one vs the other.
That's true, and viceversa as well: any editor heavily focused on keyboard shortcuts also allows mouse input. My preference for keyboard input has nothing to do with my editor choice, I just never feel the need to rely on the mouse. This is why I wanted to better understand why someone would prefer mouse input, and why text editors like Acme would be specifically built for this kind of workflow.
[1]: https://www.youtube.com/watch?v=bexWuHmV32A
mouse or keyboard is really just a preference. you could do mouse 1 sweep-select 2-3 in one window, and move to another mouse 1-3, and move to another do mouse 1-3, ... Or you could do, in case of vi, y$ (or other movements), ^w w (or other way to select other window), (move your cursor) p, ^w w, (move your cursor) p, ... Though I'm biased, because I feel it's much easier to move my mouse than do one of wWbBeE^$fFtThjkl to move my cursor, even though it is a lot faster and efficient to only move a few of my fingers than my whole arm.
the font is likely Go Font, the proportional one
Aha, right, cursor movement across large distances is indeed more comfortable with the mouse. This is usually awkward with the keyboard, and requires plugins like EasyMotion, or just holding keys or repeating key combos. I think these movements are rarer than small cursor movements, like jumping to the next character, word, line, etc., or jumping to the matching brace, etc. In these cases using the keyboard is still faster and more precise.
But I was more thinking about controlling the editor itself. Creating new buffers/panes and switching between them is all much faster with a keyboard. For example, I bind `=` and `-` to switch to the previous/next buffer, and Tab to switch to the next pane. I do these actions hundreds of times a day, and they're just a keystroke away. I couldn't imagine having to use the mouse for this. It would be unbearably slow and tedious.
The best part of key bindings is that they can be easily modified to suit any workflow. Whereas with mouse movements you really can't customize them beyond which of the few buttons to click. The movements themselves can't be optimized, unless you go into gesture territory, which has a lot of drawbacks as well.
No, it doesn't look like the Go font, but thanks.
> Aha, right, cursor movement across large distances is indeed more comfortable with the mouse. This is usually awkward with the keyboard, and requires plugins like EasyMotion, or just holding keys or repeating key combos
Embrace search based navigation. And if you’re using Vim or Emacs, do whatever that can popup a new window with the result of your search and links to their location in the main buffer. And extend that to search in all files of the $PROJECT.
I do use search often as well, but it's not great. You may mistype and land somewhere unintended. Or have to iterate over the results if they're not a unique match, etc. Whereas if the location is visible on screen, it's much easier to go to it with a point and click.
Anvil uses a licensed version of the Input font, by David Jonathan Ross.
I've been a vim (then neovim) user since 1999 (plus or minus 1 year - basically so long that I don't precisely remember).
I've written so much custom vimscript for things like an irc client, tiling window manager within vim, literate programming, my own slime'ish plug-in, etc, etc, that I even have a prelude.vim, with my own "standard lib" of useful vim functions.
The only point behind this is to say that, you could say, I appreciate and "get" vim.
So after 20+ years of nothing but vim, I felt the urge to try acme because of all the cool videos I kept seeing. And, 20 years of anything is enough to cause burnout.
And you know what - I really, really liked acme. The best way I can describe it is that you may well be slowly for strictly text editing tasks, but more if your attention is left for what you're actually doing, and less is spent playing vimgolf (or even remembering YOUR OWN mappings for YOUR OWN plug-ins- because you accumulate oh so many of them).
It's a simple system, with a few basic primitives, which when approached with a clean mindset - are really very powerful.
The best way to approach acme is NOT to think of it as a text editor, but rather think if it as a replacement for your terminal.
(btw, I use an acme fork called acme2k, with some additional nicities - some of which anvil also has).
In the end, I didn't completely abandon neovim, but now I use neovim in a more acmelike fashion. All my terms are inside neovim, and I frequently pipe from shell to empty buffers, etc.
Basically, try it. It's so different, it's hard to get across in just words. It's like smalltalk - you have to try it to really get it.
Thank you for engaging in the conversation. This is the kind of response I was hoping for. :)
I'm not nearly as experienced with Vim as you are, even though I've been using it for a similar amount of time, along with Emacs. I've never written my own plugins, though have deeply configured them to my preference along the years.
The thing is that I never feel that I'm playing "vimgolf", or that I need to make an effort to remember key bindings. Maybe once I change some things or introduce new behavior it requires a period of adjustment, but for the vast majority of time the actions I need to take to produce an effect are ingrained in my muscle memory. E.g. I don't actively think "how do I select the text between parenthesis", and typing `vi)` just happens automatically with little mental effort. I'm sure it's the same for you and anyone who's used Vim for a while.
In contrast, it's not possible to achieve this with mouse input. You will always have to consciously think about the action you want to take and manipulate the mouse to achieve it. More importantly, this action will always be imprecise given the analog nature of the input, so you might misclick and cause unintended behavior. Additionally, it takes your hands away from the keyboard which you're already using for making content changes. I'm a big fan of the ThinkPad Trackpoint for this reason, but even that is not a perfect solution. All of this combined means that it requires much more effort from the user, to the point where it's personally unbearable every time I've tried it. Both Vim and Emacs support mouse input as well, but I never rely on it for this reason.
> The best way to approach acme is NOT to think of it as a text editor, but rather think if it as a replacement for your terminal.
That's interesting. I kind of don't want that, though. Just like with my editors, I've invested a lot of time and effort to customize my terminal as well. It also has custom key bindings and configuration, and is deeply integrated into my workflow. Emacs, for example, supports embedding terminals and many different shells. I can see the benefit of having better integration with the editor, but all these solutions have some shortcomings that make them inferior to using a standalone terminal IME.
I also prefer the Unix philosophy of using smaller tools that do one thing well, and combining them to fit my workflow. Repurposing my editor for all my tasks doesn't gel nicely with that, otherwise I would be using an IDE. :)
> Basically, try it. It's so different, it's hard to get across in just words. It's like smalltalk - you have to try it to really get it.
Thanks. I've tried Acme a few times over the years, but not extensively, precisely because I get frustrated fairly quickly... I'll give Anvil or acme2k a more serious attempt. But then again, this is all based on personal preferences anyway, so I'm fine with accepting these editors are just not for me.
Cheers for the chat!
I’ve spent a fair amount of time with Acme because it’s fun, but you’re not misunderstanding anything. Anyone who unironically tries assert the superiority of their niche editor is delusional and/or full of shit. It’s just personal preference.
I'm not trying to have an argument about the superiority of any specific editor, but to try to better understand those preferences for one workflow over another. I could be missing something that would make my own workflow better.
For example, you could elaborate on what makes Acme fun.
For those who have used Anvil, what are the key differentiators for you?
I opened my project with Anvil on a mac (without mouse) and I cant figure out how to open a local file. Skimming through docs and I didnt find it. A video would have been very useful here.
Interesting. I don't know if it will distract me from Acme, but I will try. I'm unsure if I am ready for a rest API interface when the 9p interface to Acme works so well.
I know this is a minor gripe, but something isn't right with the https version of this site.
Yeah, the site flagged as malware for me.
The window management looks great but going back to mouse-driven input is a non starter for me. Anvil with vim motions would be interesting.
I’m not convinced Snarf is still a good name for any function in any piece of software these days. Or ever was, to be honest.
It got that name from Acme. I don't think it's any worse than "yank", which most of us continue to put up with.
I know it has. That's why I said "still". To be honest, yank is also not great. Both terms were invented back in the day the industry hasn't settled yet on copy and paste. For new software, choosing such names is counter-productive.
One (kill) ring to find them...
Snarf always remembers me of the Thundercats pet.
Such a great theme tune. That scream from mumm-ra is the icing on the cake.
https://www.youtube.com/watch?v=ooVDv8kuzXY
Wow, something I didn't know was in my brain, and you found it. Snarf!
Yeah definitely should be something modern and respectable like Hugging Face
[flagged]
I read it more as a comment on the library itself, not the UIs that you can create with it.
But, in any case, I find this beautiful because not a single line is wasted on anything that isn't text, yet I can easily see what is what without it hurting my eyes.
Isn't that what's meant by "functional"?
We have Emacs/vim at one end of the spectrum and VS Code at the other. What else do we need? At this point I feel like these poor souls waste a lot of their energy to develop something that has perfect solutions already out there. Or you need to come up with something that totally transcends the way we write (ascii) text.
Maybe one of these will grow into emacs+vim+vs code and make them obsolete ? We didn't just spawn in with computers having vs code emacs or vim already installed you know.
I did already write my own comment trying to ask about the goals and state of Anvil when compared to Acme. That said, RE: "Emacs/Vim on one end and VS Code on the other" and "... you need to come up with something totally transcends the way we write" -- the latter is actually the reason why I was genuinely curious.
I haven't had the time to give Acme a proper try myself, so who knows whether I'd hate it or love it or what, but it only took a few minutes of Russ Cox's little introduction video [1] on Acme for me to go, "Whoa, that is unique"; half the concepts gave me a near-instant visceral feeling of simultaneously being disturbed yet also somehow delighted.
I am really unhappy with the direction of modern UI design, and much of software in general, but sometimes I wonder how much of my feelings are truly objective, how much is my own bias, and how I would feel if I grew up in a totally different environment with different stuff. I've kind of always been curious in that sense, if you took a group of people who somehow had been totally isolated from not only computers and software, but our various cultural biases, what would they find to be the most intuitive, and what sort of things would they come up with?
In a similar sense, for better or for worse, that is almost how I felt seeing Russ use Acme; it looked like an editor built by aliens for other gremlin-like aliens.
I can't confirm or deny whether the aliens are right about their editing paradigm, but it is at least something much closer to "transcending the way we write (ascii) text" than most, and so it's cool to see Anvil is at least drawing inspiration from that rather than, say, yet another VS Code.
[1]: https://www.youtube.com/watch?v=dP1xVpMPn8M