[HN Gopher] The Anvil Text Editor
___________________________________________________________________
The Anvil Text Editor
Author : bwidlar
Score : 74 points
Date : 2024-10-23 08:29 UTC (1 days ago)
(HTM) web link (anvil-editor.net)
(TXT) w3m dump (anvil-editor.net)
| euroderf wrote:
| If this can be compiled into WASM and embedded in a web page...
| andrewshadura wrote:
| 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.
| major505 wrote:
| Snarf always remembers me of the Thundercats pet.
| gcanyon wrote:
| Wow, something I didn't know was in my brain, and you found
| it. Snarf!
| fatboy wrote:
| Such a great theme tune. That scream from mumm-ra is the
| icing on the cake.
|
| https://www.youtube.com/watch?v=ooVDv8kuzXY
| tempfile wrote:
| 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.
| lynx23 wrote:
| One (kill) ring to find them...
| andrewshadura wrote:
| 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.
| nanna wrote:
| Yeah definitely should be something modern and respectable like
| Hugging Face
| aquariusDue wrote:
| 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.
| ksynwa wrote:
| Source code archives are available on the download page:
| https://anvil-editor.net/download/
|
| But as you said I couldn't find a repo.
| Arch-TK wrote:
| > 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.
| wodenokoto wrote:
| 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.
| globular-toast wrote:
| 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.
| vulcan01 wrote:
| 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.
| msravi wrote:
| In vim, to replace in the next 5 lines (not instances)
| :.,.+5s/findtext/replacetext/g
|
| In neovim, you'll see a preview of the changes as you type
| the regexp. Neovim is really good.
| buster wrote:
| 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/".
| cxr wrote:
| V * n n n gets you a selection around 5 consecutive
| occurrences. In Visual (selection) Mode, Vim will
| automatically scope the substitution to the selection.
|
| I agree that the .,.+5 recommendation is silly--
| technically doable, but unergonomic and, realistically
| speaking, unlikely to get used.
| kstrauser wrote:
| 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.
| specialist wrote:
| 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.
| globular-toast wrote:
| 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.
| subjectsigma wrote:
| 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?
| kqr wrote:
| For the record, there are plugins (for e.g. Emacs) that
| provide visual feedback on regex operations.
| frou_dh wrote:
| Why don't you use regex for all editing in the single-cursor
| case as well then?
| msravi wrote:
| 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.
| frou_dh wrote:
| 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.
| nextcaller wrote:
| 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.
| aragonite wrote:
| > 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!
| sevensor wrote:
| 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.
| freetonik wrote:
| 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.
| t-3 wrote:
| 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).
| gpderetta wrote:
| 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.
| rk06 wrote:
| Two rules of success:
|
| 1. Be attractive
|
| 2. Don't be unattractive
|
| Lack of multi cursor supprot is unattractive in current era.
| sexyman48 wrote:
| Tom Brady agrees.
| quadsteel wrote:
| 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
| Vegenoid wrote:
| 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.
| robenkleene wrote:
| 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.
| mkovach wrote:
| 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.
| xpe wrote:
| For those who have used Anvil, what are the key differentiators
| for you?
| msravi wrote:
| 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
| archargelod wrote:
| 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)
| disintegrator wrote:
| 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.
| stronglikedan wrote:
| I may not _need_ it, but every operation they demonstrated is
| significantly slower than using multiple cursors, so I
| definitely _want_ it.
| deagle50 wrote:
| 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.
| submeta wrote:
| 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.
| OmarAssadi wrote:
| 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
| hdb2 wrote:
| I know this is a minor gripe, but something isn't right with the
| https version of this site.
| lexoj wrote:
| 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.
| OmarAssadi wrote:
| 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.
| imiric wrote:
| 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?
| jxy wrote:
| 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
___________________________________________________________________
(page generated 2024-10-24 23:00 UTC)