The Anvil Text Editor
anvil-editor.net
anvil-editor.net
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 as you said I couldn't find a repo.
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.
And I need to edit around a limited version of foo way more often than I need to edit all instances.
:.,.+5s/findtext/replacetext/g
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/".
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.
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).
"foo bar" # For the 1st line
"baz qux" # For the 2nd line
"bar" # For the foo key
"qux" # For the baz key
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.
This is two lines, if everything was a different length, I think by the time I got multiple cursors to do this, I would have long managed by just doing the same editing task twice (cut overwrite-paste then cut overwrite-paste).
If I had to do this for many more lines I would have just used a substitution:
:s/\(.*\)"\(\w\+\) \(\w\+\)" # \(.*\)\(\d\+\w\+\).\*/\1"\3" # \4\2 key/
Although in this case I think a macro would probably be what I would settle on. This macro would look like:
^wdw/the<ret>wvawpwciwkey<esc>j (<ret> and <esc> are ^M and ^[ but I replaced them to avoid confusion)
Multiple cursors are effectively (in my experience) just macro recording with automatic playback simultaneously at all the positions you care about. Whereas if you just record a macro and apply it wherever you would otherwise place your cursors, you get the same result without having the visual mess of dealing with multiple cursors. And it's just as error prone as macros.
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.
I am proficient in emacs and don't need the mouse to do anything, but I am conscious I still reach for the mouse when more complex movements are required because it would be extremely dogmatic and unproductive to do otherwise, as it's just so much easier, and there's absolutely no shame in using the right tool for the job.
Please describe your non-roundabout way then.
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)
> 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.
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 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
Yes, I picked that scenario because doing search & replace on all vars of a given name across the whole file doesn't require selection. Yes, I would normally want to replace that var name when it appears in comments too. Yes, I typically have a very good if not perfect knowledge of whether foobar is a variable name only or might appear as a substring of something else. If my variable name was "n" then I'd have to take more care.
The original scenario explicitly states "not every instance in the open file ", so not sure why you bring that up
> in comments
same, where is this coming from? That adds no difference to these 2 workflows
> very good ... knowledge
This is just self-deception, you don't have the full text with auto-matching built into your brain, and since 'n' is an rethorical alternative, in reality you wouldn't even have a great way of knowing when to take more care
But also: how is your very serious "I know all the text" limitation relevant to this general comparison of 2 approaches?
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.
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 mouse doesn't necessarily come into the discussion at all.
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!
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
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.
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:
sensors size interval
14 100 1
14 100 30
14 100 60
sensors size interval
14 100 1
14 100 30
14 100 60
14 100 1
14 100 30
14 100 60
sensors size interval
14 100 1
14 100 30
14 100 60
14 500 1
14 500 30
14 500 60
sensors size interval
14 100 1 14 100 1
14 100 30 14 100 30
14 100 60 14 100 60
14 500 1 14 500 1
14 500 30 14 500 30
14 500 60 14 500 60
sensors size interval
14 100 1 14 100 1440 60 1
14 100 30 14 100 1440 60 30
14 100 60 14 100 1440 60 60
14 500 1 14 500 1440 60 1
14 500 30 14 500 1440 60 30
14 500 60 14 500 1440 60 60
sensors size interval
14 100 1 14 100 * 1440 * 60 * 1 / p
14 100 30 14 100 * 1440 * 60 * 30 / p
14 100 60 14 100 * 1440 * 60 * 60 / p
14 500 1 14 500 * 1440 * 60 * 1 / p
14 500 30 14 500 * 1440 * 60 * 30 / p
14 500 60 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
sensors size interval
14 100 1 120960000
14 100 30 4032000
14 100 60 2016000
14 500 1 604800000
14 500 30 20160000
14 500 60 10080000
sensors size interval
14 100 1 120,960,000
14 100 30 4,032,000
14 100 60 2,016,000
14 500 1 604,800,000
14 500 30 20,160,000
14 500 60 10,080,000
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?
1. Be attractive
2. Don't be unattractive
Lack of multi cursor supprot is unattractive in current era.
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
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.
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.
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).
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
https://medium.com/@schtoeffel/you-don-t-need-more-than-one-...
But if you really want it:
It is an editor that combines best parts from vim and plan9 sam[1] (multiple cursors, structural regular expressions).
- 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.
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!
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.
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?
the font is likely Go Font, the proportional one
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.
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.
For example, you could elaborate on what makes Acme fun.
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.
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.
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.
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!
./anvil
[1] 25270 killed ./anvil
chmod +x, xattr -dr com.apple.quarantine etc don't work.
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.