[HN Gopher] Ad: An Adaptable Text Editor
___________________________________________________________________
Ad: An Adaptable Text Editor
Author : xelxebar
Score : 125 points
Date : 2024-12-18 00:37 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| AdieuToLogic wrote:
| To paraphrase The Princess Bride[0]: You fell
| victim to one of the classic blunders - the most famous of
| which is "never get involved in a land war in Asia" - but
| only slightly less well-known is this:
|
| Sooner or later, wanting to write a program editor has ensnared
| many a skilled developer, only to find it to be a time vampire
| when considered anything more than an intellectual exercise.
|
| Good luck on your journey. :-)
|
| 0 - https://www.imdb.com/title/tt0093779/quotes/?ref_=tt_dyk_qu
| girvo wrote:
| Indeed, I was chuckling along as I read the README, as this is
| remarkably similar to my attempt at the same problem about 14
| years ago. Though sminez seems much more skilled and motivated
| than I am: https://github.com/sminez/penrose
| chefandy wrote:
| I respect the ambition. I thought I was combining chocolate
| and peanut butter a few times, but after sinking a few days
| into it, realized I was building a Homer car. All of those
| projects were driven by my desire for some way of interacting
| with some common data or whatever rather than solving a
| unique technical problem, so I now force myself to define a
| very granular UI spec and start with the front end code, and
| the profile of the homer car reveals itself way earlier in
| the process. Popping open the code editor and banging out the
| scaffolding for a back-end always feels so productive, but if
| it's a fundamentally flawed idea, it's very much the
| opposite, in reality.
| marssaxman wrote:
| I appreciate your joke, but also - it doesn't have to be so bad
| as that! Of all the everyday tools a developer might choose to
| reinvent in their own personal style, an editor is likely the
| easiest to complete.
|
| I have written three different code editors over the course of
| my career, and the last of them I have been using every day for
| a long time. It is a good feeling, building tools which suit
| oneself perfectly!
| Gualdrapo wrote:
| Is it just me, or in the latest few (10?) years there have surged
| more vi-like alternatives like never before?
|
| - Kakoune
|
| - Helix
|
| - Vis
|
| - Ki
|
| - Ad
|
| - ...
| JadeNB wrote:
| I'd never heard of Ki, and it's hard to google. Do you have a
| reference?
| yjftsjthsd-h wrote:
| Sounds like a Google problem;
| https://duckduckgo.com/?t=ffab&q=ki+text+editor&ia=web gives
| https://ki-editor.github.io/ki-editor/ in the first screen.
| dcre wrote:
| It's the first result for "ki editor" on Google as well. I
| suspect they just typed in "ki".
| JadeNB wrote:
| > It's the first result for "ki editor" on Google as
| well. I suspect they just typed in "ki".
|
| I tried "ki vimlike." In retrospect, "ki editor" would
| have made more sense.
| barnabee wrote:
| https://ki-editor.github.io/ki-editor/
|
| It's quite a young editor but is conceptually pretty neat! It
| works on syntax trees as defined by tree sitter, and the
| tutorial on their site shows off how powerful that is pretty
| nicely.
|
| I also like how it gets by with pretty much just buffers and
| readline for everything. I'm a bit more wary of all config
| happening by changing code and recompiling, though.
|
| Definitely one I'm watching, though it's far from being able
| to tempt me away from Helix at this stage.
| porridgeraisin wrote:
| This is nice. I like this editor, will try it out. The
| beginnings of a "mode" exist in vim, with plugins like
| tinykeymap that let you get into "tab manipulation mode" or
| "window manipulation mode", you can really do that with
| anything though, but maybe not as extensively as in Ki.
| It's quite a neat trick, example that lets you c-w +++++
| instead of c-w + c-w +: nmap <C-W>+
| <C-W>+<SID>ws nnoremap <script> <SID>ws+
| 10<C-W>+<SID>ws nmap <SID>ws <nop>
| nine_k wrote:
| If "ki editor" is hard to google, I suppose "ad editor" must
| be basically impossible to google. A clever way to keep the
| project low-profile before it's ready for world domination :)
| AdieuToLogic wrote:
| There is a reason why interactive command shells such as bash,
| korn, and zsh only support two editing modes; emacs and vi.
|
| Emacs reifies its LISP underpinnings by modelling edit commands
| as an AST[0]. "Top down" as it were. This optimizes for command
| categorization.
|
| Vi/vim/derivatives model editing by "flattening" the editing
| command tree such that the vast majority are no more than two
| or three keystrokes (excluding repeat count prefixes). This
| optimizes for uniform command distribution.
|
| Both eschew requiring a mouse and/or a GUI, which vastly
| increase their applicability.
|
| As to which is superior, that is the subject of thousands of
| "editor wars" threads in one form or another.
|
| My stance is to pick whichever best suits how you like to think
| when solving problems.
|
| 0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree
| lproven wrote:
| > Both eschew requiring a mouse and/or a GUI, which vastly
| increase their applicability.
|
| This is a prime example of what is, it seems to me, one of
| the absolutely core misunderstandings of the wider Unix
| world.
|
| GUI does not mean, imply, or require a mouse. The original
| Mac and Lisa were mouse-centric, yes, but folks, _that was 40
| years ago now_ and the world has moved on.
|
| You can use a modern Mac entirely without a pointing device,
| via Voiceover, which is built in to all Macs, iPhones, iPads,
| etc.
|
| Windows has been amenable to being 100% keyboard driven since
| Windows 1.0 in _1985_ and I have been using Windows primarily
| by keyboard controls since 1988.
|
| This is the standard method of computer interaction for
| millions of blind computer users around the world _since the
| 1980s._
|
| What's more, the Windows keyboard UI strongly influenced IBM
| CUA, which in turn was informed by the mid-1980s Apple Human
| Interface Guidelines, and that influenced OS/2, DOS from 1990
| or so onwards (so MS/PC DOS 4 and later), and that influenced
| Xfce, KDE, GNOME 1/2, and most other xNix GUIs.
|
| It is _only_ the shell oriented xNix world that has refused
| to adapt.
|
| Console-mode shell-only Linux text editors such as eFTE,
| SETedit, and Tilde all have the _third-of-a-century-old_
| standard UI and can be used 100% with the keyboard _but also
| have menus and dialog boxes_.
|
| The standard design of basically all 21st century GUIs
| (except for the handful that are intentionally different -
| GNOME, Pantheon, Unity) _does not need graphics_. It does not
| need a mouse. It can be, and still today is, sometimes
| implemented entirely in text mode, it works on dumb text
| terminals, and it was universal in 1990s DOS, OS /2 and other
| native x86 OSes.
|
| The result of the refusal of the xNix world to even notice
| this is happening has absolutely _crippled_ the field of
| editor design on xNix.
|
| In all other fields of software, text editors moved on from
| the awful and terribly dated design of Vi and Emacs by the
| late 1970s. See this interview with Larry Tesler, who
| invented cut/copy/paste as a computer UI.
|
| https://worrydream.com/refs/Tesler_2012_-_A_Personal_History.
| ..
|
| This means that there are something like a million times more
| users out there happily editing text every day with editors
| with better UI than the absolute top-rated shell editors on
| any xNix.
| InfamousRece wrote:
| Which editor do these million times more users use?
| homarp wrote:
| vscode!
| lproven wrote:
| Essentially and any all Windows apps that edit text.
|
| MS Word and all of Office, and all of its rivals. IE,
| Edge, Chrome, Firefox, and all other browsers, GUI email
| clients including on Linux and all the BSDs, etc.
|
| I have written about this, in case you're unfamiliar with
| CUA:
|
| https://www.theregister.com/2024/01/24/rise_and_fall_of_c
| ua/
| uludag wrote:
| From what I've noticed, despite the label "outdated", I
| can't reliably notice any difference in utility between
| these categories. neo/vim users (which I certainly don't
| use) are at least as effective using these tools as so-
| called "modern" text editors. I don't think anyone can
| categorically say that modern text editor users (e.g.
| vscode) are more productive/better/extract more
| utility/etc. than their terminal based counterpart like you
| can say for other truly outdated technologies. And these
| tools make up a huge portion of the (coding) market. I
| don't think it should matter that they don't target the
| masses.
|
| I think there are a lot bigger problems to solve in the
| xNix environment than getting people to stop pressing
| escape to enter normal mode.
|
| (the argument for Emacs makes less sense since it has
| customizations available to be as "modern" as you want. You
| may criticize it's byzantine configuration process, but
| that's a different topic. It's also funny how Apple, the
| poster child for elegance in UIs has Emacs keybindings by
| default everywhere in macOS, even the concepts of "yanking"
| and "killing". In hindsight though, it makes perfect sense)
| lproven wrote:
| I think you misunderstand what I am saying.
|
| I am absolutely not saying that there is any difference
| in utility whatsoever. I have watched skilled exponents
| of Vim and Emacs perform wizardry, and I've also seen an
| adept of Jedit do things with plain English text that I
| don't know how to do in any editor.
|
| This is absolutely _not about utility or capabilities._
|
| It's about UI.
|
| I am aware of efforts to bring a standard modern (as in,
| 1990s) UI to both editors.
|
| For Emacs there is ErgoEmacs --
| https://ergoemacs.github.io/ -- which is amazing and
| makes it slightly usable even for me, steeped in CUA for
| over a third of a century.
|
| For Vim I know of Cream -- https://cream.sourceforge.net/
| -- but it seems unmaintained for a long time and when I
| tried it I couldn't get it working.
|
| What I am saying is two other, quite different things:
|
| 1. Using the Linux shell is needlessly hard and
| complicated, because of its adamant refusal to adopt the
| modernised UIs of other text-mode OSes from 30+ years
| ago. These could be bringing the shell into harmony with
| the GUI, making the experience better, and it would be
| trivially easy to set things up so that experienced users
| with their own ways of doing things were not
| inconvenienced at all.
|
| 2. As a result of this refusal, or even of this blank
| ignorance and lack of curiosity in how other OSes and
| other platforms modernised text-mode apps, the dominant
| tools in Linux and other FOSS xNixes have no
| standadisation. Even when there are TUIs driven by
| ncurses or whatever, they're all different and all
| inconsistent. There's no need for it. It's wasting
| everyone's time.
|
| In other words, the tools don't need to be different from
| one another _and_ they don 't need to look and work so
| differently from in GUI desktops.
| uludag wrote:
| ok, I think I understand what you meant better. I guess
| my mental model of UI has some sort of utility baked in
| but I see how this isn't necessarily the case. I would
| agree with this take actually. It is deffinitely is a
| jarring experience with with terminal stuff as every TUI
| is a world unto itself.
| TeMPOraL wrote:
| It's not just me. There's also some Zigs or Zags or something;
| pretty sure your list is missing several entries.
|
| My pet theory, we can thank LSP for that, as it removed the
| major hurdle for any new editor project: the complexity of
| supporting modern programming languages and practices. Being
| able to offload most of that complexity to a language server
| (and most of the rest to tree-sitter) just about makes a new
| editor a viable side project.
|
| As for motivation... I wonder how many of the new editors are a
| "let's rewrite it in Rust" thing?
| smasher164 wrote:
| This is very exciting! I've been longing for an acme-like editor
| that adapts better to mainstream OSes. Being vim-like is a major
| plus. I'm gonna try this out!
| ilyagr wrote:
| People should be aware of two related editors:
|
| https://anvil-editor.net/ is more directly inspired by and
| similar to Acme (but makes no attempt to borrow from Vim).
|
| https://github.com/martanne/vis is a minimalist editor that stays
| close to Vim but adds Sam-style regular extensions and multi-
| cursor editing (but not Acme-style "execute anything on screen").
| For example, you can select all instances of a regex and edit
| them all at once afterwards interactively.
| ilyagr wrote:
| Which brings me to a question: I'm not entirely clear on the
| relationship between and capabilities of Sam and Acme.
|
| Is the ability of Vis to select all instances of a regex and
| edit them all at once afterwards interactively (see e.g.
| https://asciinema.org/a/41361) Vis's own idea, or was it part
| of Acme? Is it part of Ad?
| rob74 wrote:
| > _https://anvil-editor.net/ is more directly inspired by and
| similar to Acme (but makes no attempt to borrow from Vim)._
|
| Wow, I didn't think there is still open source software around
| that isn't hosted on GitHub or another code hosting platform.
| And the page also makes it very hard to tell if the project is
| still active, the only date I could find was in the license
| (2019). I actually had to download the latest version and look
| inside the archive to see that it's from November 2024...
| ilrwbwrkhv wrote:
| It is active and it works remarkable well as an editor.
| wasted_intel wrote:
| Your comment about writing a text editor library is precisely
| what got me started with amp ~10 years ago, where much of its
| core functionality was extracted here:
|
| https://crates.io/crates/scribe
|
| Good luck with the project! Building a text editor to scratch
| your own itch is fun.
| teo_zero wrote:
| I wonder why every attempt at copying vi's concept, which is
| reasonable, also ends up copying its keybinding from the 70s.
|
| I'm not talking about hjkl, but rather y for yank, p for put, d
| for delete, u for undo... where today every other software adopts
| a different vocabulary, namely x for cut, c for copy, v for
| paste, z for undo, etc.
| mathstuf wrote:
| IMO, it's because mnemonics make more sense than QWERTY
| keyboard placement. Of course, there are exceptions even in Vim
| (e.g., ^E and ^Y for viewport scrolling), but bindings to value
| rather than pointer for things make it easier for those with
| alternate layouts (very few apps use scancode rather than
| keycodes for bindings, but they are possible such as GNOME's
| Alt+<key above Tab> for same-app window switching).
| atiedebee wrote:
| I think those bindings are fine, what is more problematic to me
| is the inconsistencies or straight up arbitrary mappings (gg
| and G come to mind). I feel like kakoune did a great job at
| improving vims bindings to make more sense.
| tliltocatl wrote:
| Speaking of 70s, my personal showstopper for vi isn't mode
| switching (actually, quite convenient). It's the cursor being
| on top of a symbol, rather then between symbols, so you need to
| mind when to 'i' and when to 'a'. And no, virtual spaces
| doesn't change much, the whole editing model is built around
| it.
| cess11 wrote:
| It's the terminal that controls the cursor. You can tell vim
| to change it and have a vertical bar in insert mode and a
| block otherwise if you want.
|
| By default you just get what your terminal does.
| tliltocatl wrote:
| Terminal is just the display, I'm talking about editor
| model. Even if the cursor is displayed as vertical bar, vi
| would still models it on-symbol and switching between modes
| will move it sometimes inconsistently. Well explained here:
| https://www.reddit.com/r/vim/comments/99h4le/comment/e4nsx0
| m...
| cess11 wrote:
| Reddit doesn't like my network and I won't dig up some
| proxy they prefer. You can describe an incantation that
| will "move it sometimes inconsistently" instead.
| tliltocatl wrote:
| My personal take is just you have to remember what you
| did last to choose between "a" and "i". If you do
| i123<Esc>iabc, you get "12abc3" rather then "123abc".
|
| And then as the link says:
|
| - <Esc> moves to the left [...] but if you do i_Ctrl-O or
| i_Ctrl-\\_Ctrl-O [...] it moves to the right!!
|
| - An empty line still allows normal mode to have a
| cursor, but since there are zero characters this cursor
| is kind of "fake".
| cess11 wrote:
| None of those are inconsistent. If a is confusing for
| you, use i, A and o, that'll be enough for most things
| you want. Most of the time you'll drop into insert mode
| through cw, cib and the like anyway.
|
| What do you mean by empty lines? Does your vim somehow
| have lines in the buffer that aren't in the file?
| tliltocatl wrote:
| \n\n
| usrbinbash wrote:
| I don't see how that is a problem, given how trivially easy
| most of these editors make it to rebind keys.
| opan wrote:
| CUA bindings are very QWERTY-centric, which feels even more
| dated to me. The mnemonic style binds remain more equal across
| layouts. In the case of p, there's also P, so you'd likely lose
| half the functionality trying to force it into the CUA style. I
| guess you could use ctrl-shift-v, but that tends to be "paste
| without formatting".
|
| I grew up mostly with Windows and CUA, and I still became a big
| fan of vim.
| marssaxman wrote:
| vim bindings are even more QWERTY-centric, no? That's why I
| skipped it after a brief look, many years ago: having to
| memorize a lot of unfamiliar key commands was bad enough, but
| coming at it as a lifelong Dvorak user, the keys also seemed
| to be scattered incoherently all over the keyboard.
| maccard wrote:
| I'm an IDE-with-vim-bindings user, and I don't get the desire for
| another vim. The value proposition in vim (or vscode or idea) is
| in the extra functionality on top of the core editing experience.
| If you give me a different text editing experience, but don't
| support the ecosystem of plugins, the value proposition is almost
| zero. There are basically no methods of text input that will make
| me more productive than a good debugger, test and project/file
| explorer integration.
|
| One thing that I would love to see is vim like bindings for
| navigating a semantic representation - navigating a tree sitter
| representation instead of words and symbols.
| dlisboa wrote:
| Many editors pop up with zero ecosystem and become successful
| anyway. All you need to do is provide a better editor
| experience in some fashion for there to be a value proposition.
| Atom, VS Code, helix, zed, etc. none of these had mountains of
| plugins and integrations initially.
|
| Plus building vi-like editors is just a fun exercise a lot of
| programmers undertake, hence why there are so many. People have
| to try things to know what is better.
| 0points wrote:
| Screenshots, please.
| splitbrain wrote:
| I saw the headline and thought HackerNews is now showing ads. But
| it's an editor called "ad".
| amelius wrote:
| There are ads disguised as articles, but they are usually about
| Apple products. Often the article is a direct link to the
| corresponding product web page.
___________________________________________________________________
(page generated 2024-12-18 23:02 UTC)