Ox is a fast text editor, written in Rust, that runs in your terminal | Hacker News Reader

Ox is a fast text editor, written in Rust, that runs in your terminal

github.com

416 pointsguessmyname336 comments

Editor looks pretty cool, but I really admire how optimized the headline is for reaching the top of the front page. I mean, it's practically an HN bingo card in a single line: Text editor! Rust! Terminal! Fast! All that's missing is "minimalist" and "respects your privacy".

Good catch!

I feel like no project should be allowed to advertise itself as "fast" unless it presents at least one (1) measurement demonstrating it.

I'm slowly putting together a library and series of blog posts for really showing this, so stay tuned (one measurement often isn't enough).

I've always wanted to be able to try and verify performance bounds at the CI stage, and I'm hesitantly optimistic it can be done cleanly (although amortized analysis is extremely important, you can actually play "guess the C++ std container from the graph" if you plot the data right)

Python compared to raw assembly development is slow as hell in computationally heavy scenarios.

Development speed of applications in Python compared to raw assembly is nearly infinitely faster, both because it’s easier to write and because the talent pool for ASM is near zero in most cities.

But the same can be said for basically all metrics people use to sell products.

Running subjective benchmark now. Generated 1G text file. Vim and nano after some delay are showing things on screen, ox is still thinking. 5 minutes and counting...

  base64 /dev/urandom | head -c 1000000000 > file.txt

Yeah but that's not a realistic usecase for most users/developers. I haven't measured if Ox is faster or slower, but for me startup time and ability to quickly open files under 10MB are more important.

I open massive files in a text editor all the time.

I also am regularly limited in opening large text files working with genetic data.

Probably, but then we don’t use our normal editors when we want to open huge files, we use the fast ones.

But for 10MB range do you even feel the delay for any of text editors? For me it feels instant whatever (terminal based) editor i'm using. And what does it even mean "fast" in this case. They all are definitely faster than me typing.

It is very realistic when I copy a json dump into an editor and then do a key stroke to format it.

My beloved vim doesn't fair so we'll. VScode does very well on this.

I noticed some years ago that vim can be much slower due to highlighting of particular syntax of huge files. For example it was fine with a 10MiB C file, but super slow with a 10MiB XML file, but fast again with ":syntax off"

Are you doing the formatting via a Vim plugin?

I often find it's much faster to pipe out to a command line program to do formatting on huge files.

e.g.

   :%! jq

   :%! xmllint --format -

Huh, thanks, I didn't know you could put the contents on stdin like that (%!) - just in case you (or anyone) was similarly unaware in reverse, you can also put `%` wherever you want to use the filename in the command.

i.e. I would have done:

    :! jq %

and have probably been guilty of (not knowing `%!` per above):

    :! cat % | ...

I frequently open minified CSS/JS by accident. IntelliJ's project search window includes a small preview of each result when you hover it, so when you navigate through the results your might pass through a minified file and get your IDE to hang for a couple of minutes :)

I open massive text files semi-regularly. If a text editor can't deal with that it's a big con for me.

> Yeah but that's not a realistic usecase for most users/developers.

It also looks like vim and emacs don't decide what a realistic use case is, or if you're "most" users/developers. They just open text files for editing.

Is something like Emacs, Vim, or Nano genuinely slow for you?

Even for large files, I've never noticed anything beyond microsecond-type delays with those. Definitely does not feel laggy to me, usually.

One thing about this particular benchmark is that the file it produces is a little bit unusual even for large text files, because it is only contains one (massive) line. Most huge text files you open in text editors are things like multi-gigabyte logs and database dumps, which are composed of many relatively short lines. Text editors often bake that assumption into their data structures. A more representative test would probably be to use hexdump instead of base64 there.

Though I take the point: if a text editor advertises itself as being "fast", this is the kind of stuff you expect it to handle.

EDIT: ok, so i just tried the hexdump version. Vim and Emacs took a couple of seconds each (Emacs being slightly slower and chunkier when you navigate, Vim handles it without issue and is perfectly repsonsive). less opened it instantly (obviously, it's less!). ox has been going for a few minutes now, nothing happening.

It's not the benchmark's fault, ox is just slow for large files.

> the file it produces is a little bit unusual even for large text files, because it is only contains one (massive) line.

XML and JSON without pretty print. Minimized HTML with embedded resources. While not often gigabyte sized those seem to be enough to get most editors to hang and make editing the files a miserable experience.

Yes, true enough, it does happen occasionally, but it's pretty rare (and usually there are other ways to deal with it: using less or similar tools, or just running your massive single-line JSON thing through jq first). And my point was exactly what you're saying: many text editors choke on files like this, so it's not such a huge indictment of ox that it chokes on it as well.

However, ox clearly performs poorly even when your text files aren't massive single lines, so it doesn't really matter: ox basically can't handle files like this regardless of line distribution.

> and usually there are other ways to deal with it: using less or similar tools, or just running your massive single-line JSON thing through jq first

Older Unixen at least (SVR3-based) had a tool called bfs - big file scanner. Used it some, e.g. when, as a system engineer, I helped IT staff of one of our customers, a university processing exam results of tens of thousands of students from dozens of colleges affiliated to that univ. IIRC, its UI was something like a read-only ed (google "unix bfs command"). You used it to scan really large (for the time) files, e.g. data files (input/output) in large data processing environments, for purposes like checking if the input or output files anecdotally looked okay, no major noticeable garbage in them. Haven't checked if it is present in modern Linuxes. Also don't remember if it could handle large files without newlines. Likely not, if based on ed. Didn't have such files to work on then.

Incorrect. The base64 command wraps at 76 columns by default.

Whether there's a wrapping feature depends on the implementation. coreutils base64, yes. Other implementations, maybe not. macOS's /usr/bin/base64 for instance doesn't have the concept of wrapping. FreeBSD base64, judging from the manpage, doesn't do that either. https://www.freebsd.org/cgi/man.cgi?query=base64

Edit: Oops, posted some misinformation. The mistaken part, reproduced below:

> First, wrapping by default only occurs when writing to a tty. When stdout is redirected to a file, wrapping base64 output usually doesn't make sense, so wrapping doesn't happen.

Correction: coreutils base64 wraps regardless of whether stdout is a tty.

> macOS's /usr/bin/base64 for instance doesn't have the concept of wrapping

Yes it does. "-b N" or "--break=N" inserts a line break every N characters.

Yeah. I know -w doesn't work, and missed -b when glancing at the manpage. (I use coreutils day to day.)

I ran it on macOS, and there I got:

    $ base64 /dev/urandom | head -c 1000000000 | wc
       0       1 1000000000

I haven't tried anywhere else, so it might be different on Linux or GNU or whatever.

As an emacs user, one of the things I really wish it had was robust support for arbitrary file sizes and shapes.

(It'd be fine if not all features worked on these files.)

Sure, most files are reasonably sized and shaped, but sometimes you do find yourself needing to e.g. dig into that single-line 1GB json file to try to debug something, and it's inefficient to have to think, before opening any file, "is more normal tool sufficient for this, or should I use something else?"

There's no fundamental reason we can't have one tool that does it all!

emacs -q or -Q is often quite fast. It's things like syntax highlighting, word wrapping, etc. which modes add which usually slow it down. Anything trying to run regexes over the buffer isn't going to scale well.

I think long lines are (were? [1] seems to be a new feature) a well known problem in emacs even without a custom config. There have been ways to work around this for awhile I think, but as far as I know emacs -Q isn't one of them.

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Lo...

oh that's neat, i didn't know about that! could help.

my ideal editor would never block, and use file-sized based approximations to allow scrolling to arbitrary locations w/o having to actually read the contents of the entire. things like syntax highlighting &c would be either strictly time-limited to not drop frames, or done in the background.

Try M-x find-file-literally to avoid any mode-specific hooks, colorization, etc.

Could this be summarized as "algorithm" (or data structure more specifically) beats language implementation performance?

Certainly could!

Most would happily trade an editor that is 100x slower for gigabyte single-line text for one that is 10% faster on gigabyte multi line text.

99% of files I work with are <1000 lines, so I don't mind. For larger files I will fall back to Vim.

The important thing to realize is that text editor performance is less about the technology used and more about the data structures and i/o.

This is not an excuse for an editor being claimed "fast". Textadept is written in C and is also very fast but has the exact same issue -- choking on huge files when Vim and others are able to handle it.

I rarely open gigabyte single-line files, but when I do, I don't want to switch editor.

Most of the time I only realize that everything is on a single line after opening the file.

A good editor doesn't require me to think about these things.

If it's over 1 GB and single line you're almost always going to exit the editor, run some scripts on it, and open it again when it's correctly formatted.

I would rather open it in editor, strike a "reformat all" shortcut, and have the file right there.

I don't want to chase separate tools that can format different text files, that's what editors are for.

It's still annoying if your editor hangs and you have to find some way to kill it before your computer becomes usable again.

Sure. I'd not be able to actually do anything useful with a gigabyte single-line file so what I'd want my editor to do is say "Longest line is over 100k characters, truncating display to the first 100k".

issue is that the editor can't tell if it's a multiline file with a first big line or an editor with one big line if it's cut at the first line. But I'd rather have the editor bail at the first 100k line than not opening it.

Sure, but this one isn't 10% faster on gigabyte multiline text. Others in this thread are testing wrapped text and Ox still chokes.

Emacs opened it in about 4 secs on my 2018 MBP.

I highly doubt you have to manually edit a GiB file by hand. For read-only, less opens it instantly.

I have had to do this in the past. Admittedly, that was only a few times over the course of 15 years.

I tweak 1.5GB files by hand on a weekly basis on servers across the globe. Fortunately vim works for my use case.

In that case, you would be better served by some automation tools.

You'd have to know my specific use case to say that.

Unfortunately it's not automatable.

Vim is amazing. Try searching for patterns in this enormous file ;) Definitely a hard nut to crack.

Personally i see no reason why this is needed (just use vim), but I'm sure a lot of people will use it just because its written in rust^^

Software developers find lazy/partial file loading unnecessary but, it is not and it won't...

Summary of replies: This benchmark doesn't count because No true Scotsman.

I wonder: Couldn't we have some kind of simulated line breaks, which an editor places virtually, so that it can manage very long lines easily and efficiently internally, while writing out the file without these virtual line breaks? Basically only so make the conditions appropriate for the editor's string data structure?

In fact, you basically need to do that anyway to wrap long lines effectively.

It runs in the terminal. I think most people assumes that terminal === fast.

Direct to X can be much faster, as there is no middle man. And can have better keyboard (and mouse) support which in terminals is pretty poor. This is why vi(m) is best for terminals, because it's keyboard shortcuts are adapted for that (except typical 1 second delay on escape key).

But it's close to metal

The input is actually very slow. It's own configuration file (about 300 lines) took over a minute to paste.

and end-to-end encrypted

Hah, look at the author's user profile!

Yeah! I think Rust is mature enough now that this isn't necessary from a novelty perspective. And it's not really an obscure language. "In Haskell" for eg is still warranted because it's obscure and uncommon, but I don't think this fits Rust.

For an even catchier headline, it should be prefaced with: "How I built a..."

I'd seriously like someone to build a HN scraper that aggregates all the articles prefaced by "How I built a..." and then write an article called "How I built a scraper to aggregate 'How I built a...' articles to assess their HN upvotes." I'd upvote that.

I'd add "alternative to popular software" to that list as well. People love to find alternatives that are supposedly better and not from big corporations.

It’s missing “Open Source” and “artisnal”. Obviously its’s crap /a

Am I the only one who feels _less_ inclined to use a program if they use 'written in rust' as a selling point?

I mean, I very rarely see non-rust projects say "Written in X!" as a selling point for the end user (why would an end user care?), and the campaign to re-write everything in rust is similarly irritating. I've never explored or read up on the rust community, but the sheer insistence that I see jutting into everything from the outside turns me off.

https://hn.algolia.com/?q=written+in (this is by top score, you can also see this by date)

Lots of stuff where X != Rust.

> (why would an end user care?)

They probably don't. But, on GitHub, where programmers go, and on a forum like this, with lots of developers, this means something to many folks here.

Non-rust programmer here, written in X does not tell me anything about the app.

I mean, it tells you that if you wanted to contribute, you'd also have to learn Rust before being able to do so.

Also, beyond that, note my "many"; sure, it doesn't mean anything to you. It feels weird to get upset about something that supposedly has no meaning, though. When I see something that's "written in X" and I don't care about X, I just move on with my day. If I post about how much I don't care about X, it really seems like I do actually care about X, otherwise, I wouldn't take the time to complain about it.

(The OP of this thread said that they did care, negatively. And you didn't explicitly say you don't care either. But this attitude is common and is also elsewhere in this thread so, let me just finally jump off this soapbox real quick...)

I agree with the other poster that it doesn't add anything to the title. I'm not "upset" about it, this is simply a side discussion about what goes in a title. I wanted to add my thoughts and now I'm done.

Surely you can think of one thing that it tells you

If I see that something is written in Rust, I'm predisposed positively because I know it'll be a single binary I can easily install, it'll be fast and it'll usually be well-designed (Rust and good cli design correlate, for some reason).

Same. I suspect the correlation is because of the crate ecosystem and cargo making it easy to use a good TUI framework.

I think it's mostly because the people who write Rust now are the same kinds of people who care about the cli.

That's a lot more compelling to me than the safety argument I usually see. Maybe I'll look into it more at some point in the future

Check out ripgrep, bat, exa, fd; or just google top rust cli's etc. They are so, so good.

I’ve recently started syncing these single binaries along with zsh dotfiles using them to all the machines I use with syncthing and have been extremely happy with the result. Just had to set PATH=$HOME/Sync/$(uname)/$(uname -m):$PATH and haven’t been without a tool since.

Similar for Go for me. I personally like Go and will go out of my way to use tools written in it because I understand the tooling and the language well enough that building from source is painless.

Agree wholeheartedly. Just yesterday I saw what looked like a very useful tool whose install instructions were "npm install -g <thing>" and I felt a little pang of "ugh" but went ahead and did it anyway. Never got the thing running but did get a nice error message that said "Electron failed to install correctly, please delete node_modules/electron and try installing again." I actually said out loud, "why the hell does this tool use electron?!" and gave up.

When I’m looking for a new open source application, for various reasons of experience and preferences about what I work with, I often look for and prefer relatively new projects in compiled, statically typed languages that are reasonably active and mature codebases.

That means the solution often ends up being written Go, Rust or C/C++, to the extent that Go and Rust specifically also turn out to be good signalling that the application may meet my other requirements, partly simply because they are relatively new languages. They also seem to signal better thought out and more “serious” solutions, perhaps because of the barrier to entry they present vs interpreted and scripting languages.

So yeah. Rust or other languages certainly aren’t a requirement but they do sometimes present some useful signalling.

Statically checked safety is a big deal.

I mean it can have a crappy UI, and not do what you want it to, but at least you won't have a memory leak.

I think for most applications, written in rust shouldn't be a selling point, but things such a cURL can definitely benefit from it

If it's open source, the audience isn't just end users, it's also programmers. They might be interested in looking at the code, reusing it in some way, or even contributing to the project.

It seems cyclical. There was a time when it was "written in Go" that was on the bingo card. I remember this being an original hype point for docker, for instance.

I do agree that I'd rather see the technology choice not highlighted so much, though. But it really is a proxy for some things that matter to me: if it is in Rust, I expect it to be a single binary I can easily install and which starts up quickly and performs well (as opposed to, say, javascript, python, ruby, or java programs), but is likely to suffer very few security problems (as opposed to, say, a C or C++ program), and has a decent shot at growing an active community, which I may be able to contribute to. A lot of these things apply to other technologies (like the aforementioned Go) as well, but it I do feel like I get some information by knowing the technology.

Maybe the better approach would be to enumerate benefits rather than saying what the technology is, even if the benefits flow from the technology choice.

You are definitely not the only one.

Nothing has put me off of Rust more than "Rust people". The same thing happened to me with Python over 20 years ago and I've successfully (and happily) avoided that language for over 20 years because of just how unbelievably, unstoppably "effervescent" Python people were in the late 1990s. If Python were 10% as good as those people said is was, it would be, by a wide margin, mankind's greatest achievement for the next 10 millennia.

I get the exact same vibe from "Rustaceans."

They are just (a bit too much) excited...

I like Rust and terminal editors but the Readme really put me off, I advise the author to either remove the bit about the other editors or take the time to really study what people like in them, because there's a lot of nonsense in here.

The part about Vim is almost entirely missing the mark, but arguably so does the part about Emacs. The real brilliantness of Emacs is that almost everything is an Emacs buffer. The interface is extremely uniform: text file, configuration menu, completion buffer, compilation log, IRC chat window, it's all the same "widget" with just some customization (keybinds, coloring) on top. You can always copy/paste text the way you're used to, navigate the buffer the way you're used to, everything is uniform and consistent.

Ever felt the frustration of having an application pop-up a modal with an error message and you want to search for it online, only to realize that you can't select the text so you have to copy it by hand? That can't happen in Emacs. Ever been annoyed that your custom bindings and shortcuts didn't work in all the parts of your editor? That the way you interact in the main text editor is different from the input box in the search dialog? In Emacs it's all the same thing.

I switched to Vim a couple of years ago but this uniform interface is still something I miss. Maybe one day I'll bite the bullet and use Spacemacs.

Have you checked out doom emacs? I used to have a manually tailored emacs configuration gradually built over the years, and ditched it quite happily in favour of doom emacs. I tried spacemacs to with much less success.

Doom emacs also has default vi-workflow.

Thank you (and jgilias) for the Doom emacs pointer, I'll be sure to look it up!

I switched from Spacemacs the last time Doom Emacs was discussed here and I'm very happy with it. Took me a while to adjust, and sometimes I'll miss something Spacemacs did, or struggle with muscle-memory, but overall it's been worth it. And the people on the Doom emacs discord helped out a bunch of times too.

I decided to bite the bullet and try Doom Emacs as a Vim user. I highly suggest it. I hadn't used Emacs before, so it was all new, but I really relate to what you're saying about the uniformness of all the 'apps', that was the first thing I noticed. And I get to keep my Vim muscle memory for wrangling text around, so to me it's the best of both worlds.

Agreed about vim.

I'm no emacs guru, but I know this much: even if we suppose for the sake of argument that customizability is the best thing about emacs, it's an absolute pratfall to write

> Ox took the idea for the customization and extensibility of Emacs and made a configuration system where you can change the colours and appearance of the editor.

But what's a marketing spiel without comparing to incumbents.

You could try SpaceVim too: https://spacevim.org/

That would sort of be the worst of both worlds for me: my problem with Vim is that many of the fundamentals are a bit wonky. Elisp is vastly better than vimscript, the macro system of Vim in nice for one-off macros but quickly reaches its limit and becomes hard to manage if you try to use it to implement advanced functions etc... It's improved quite a lot these past few years (notably because of neovim and other forks) but Emacs has been dealing with that stuff since basically forever.

Basically I want Vim with an Emacs backend. I don't need a bajillion plugins, but I want the things that I use to be easily tweakable and customizable, something that Vim struggles with and Emacs excels at in my experience.

Honestly, as someone who transitioned from vim to emacs for Clojure development, I didn't find any great benefit to Doom or Spacemacs vs. reading some init.el files on github and setting up my own config. I find `use-package` to be the best package for managing and configuring the various plugins I have installed and was able to get running in an hour or so. If you're used to vim and have tried managing your own config in the past, it probably seems more daunting than it actually is.

I totally agree with your statements about Emacs.

The readme mentions Emacs and says: "Ox took the idea for the customization and extensibility of Emacs and made a configuration system where you can change the colours and appearance of the editor."

Changing the colours and appearance is a customization option for every text editor.

Now if the readme mentioned that Ox had it's own version of a .emacs file that would run any Rust code you put into it on start up then I would be VERY excited.

I really don't think he understands vim. He writes that the plugin system is its best feature, whereas I (as someone who as almost exclusively used vim for a decade and a half) have never installed a plugin.

For many, many, many vim'ers, I know, the modal system (and hence the musclememory macro/scripting) IS the defining best feature...

Also, see all the "browser with vim binding" and "x with vim bindings" that is the modality, not the plugin system, that is emulated...

I am also a vim user, but I have 15 plugins installed including themes etc.. I am a big fan of coc and use it a lot for Typescript development. I am curious how you do programming without any plugins at all? Don't you miss linters and autocompletion?

I made a decision 20 years ago to avoid auto complete and other "in programming flow breakers". Instead, I have multiple phases, writing, linting and such.

I am sure that it made me a better programmer as I know a lot of stuff by heart, where a lot of "auto" programmers are merely constantly picking of a list, which I think breaks their thinking flow...

Which is basically the same as not using the vim muscle memory for me..

Consider a piano player that needs to look up the right keys before every stoke.. The never get a feel for the music..

I use autocomplete heavily and I can assure you that it breaks up flow much much less than having to go to the documentation all the time to look up minor naming variations (is it "start" or "begin"?).

Programming is not remotely the same as playing the piano. This and the sibling "I don't make mistakes" comment just seem like excuses to me.

FWIW, I didn’t say that I don’t make mistakes. Perhaps you misread my comment.

And why would one need an excuse for setting their development environment up the way that works best for them?

> Perhaps you misread my comment.

Which comment are you referring to you? IshKebab (the user you are replying to) was replying to svennek (not you).

IshKebab said:

> This and the sibling "I don't make mistakes" comment just seem like excuses to me.

At the time of IshKebab’s comment I was the only sibling comment.

You literally said

> I’ve learned not to make the mistakes

Yes. Perhaps you're just skipping over the word "the" when reading that sentence? In the context it has a pretty important meaning, so it pays to read all the words, not just the ones that support your preconception.

I have learned not to make the specific mistakes that the linter used to tell me off for making, so it doesn't tell me off any more. That's a very different thing from "I don't make mistakes", which is what you incorrectly claimed that I said (even with quote marks around it, implying a direct quote!)

> it breaks up flow much much less than having to go to the documentation all the time to look up minor naming variations (is it "start" or "begin"?).

I read OP's position as: If you don't use aurocomplete you'll remember the naming variations better, and won't have to look them up all the time.

I still think aurocomplete might be faster for libraries you haven't used much before, but it doesn't sound at all unbelievable to me that the brain works as stated.

I never used autocomplete until my fourth programming language. By that point, trying to write anything was an exercise in frustration as I constantly mixed keywords, namespaces and functions from the other languages.

Nowadays, I just leave autocomplete on for minimal flow break no matter what language I'm using at the moment. I don't want language-specific names and structures interrupting the flow of models and ideas from my head.

OP's position doesn't work very well the more you generalize. I had OP's philosophy when all I was doing was low level C code. It doesn't work very well when you are switching between yaml, python, c++, c#, typescript all with different libraries, coding standards, and naming conventions. By the time you no longer need the reference to remember, the reference changes.

For me, it works with 5+ languages I write (production) code in at least every month...

I don't know how it is for others.

Also, I really try to minimize complexity and not ending up in the javascript npm dependency spaghetti..

Good code is simple and obvious....

> I still think aurocomplete might be faster for libraries you haven't used much before, but it doesn't sound at all unbelievable to me that the brain works as stated.

Possibly, but I still need to read the librarys documentation carefully, where I plan my code anyways...

I have seen so many "auto coders" write 100+ lines of extra code because they missed reading the manual carefully and doing it correctly/efficiently...

If lines of code is your metric, that is great, if not, not...

I think it depends on whether you type, or your fingers type (without brain involvement).

I didn't say, that I don't make mistakes. It is rare that I make it a quarter of an hour before fucking up... luckily I am good at fixing it :)

But again, if you like your IDE, use it.

I have (almost) one decade of using IDE vs. two of not using an IDE and I strongly prefer the freethinking of the latter...

It's a fair point, certainly interesting, however most or all of it is an assumption (you didn't try the other thing in an elaborate way, let alone double-blind-tested it), plus it might not work like that for everyone.

In the past decades I have written (and still do) like 50/50 in IDEs and plain to somewhat less plain text editors, and if there's something which is a flow breaker for me, then it's coming up with the exact name and method in such plain editor when I just know there's one which does what I need but cannot remember the exact name. Fuzzy matching it against a list doesn't break any flow for me on the other hand.

Which matches how my memory works: I cannot remember hard facts and data well (function DoSomethingVeryHardCore). However I'm good at remembering abstract things (function which does something hardcore). I am pretty sure learning many things by heart from the many very different codebases I work on would be a complete waste of time. Instead learning some abstract mental model of the codebases architecture, and how to navigate through it in text, is what makes me fast and efficient.

I coded in IDEs for almost a decade up to that decision.

I could feel my "clarity" fall year for year.. I have never looked back.

I stand by my original statement, that for me, IDEs hinder my thought.

Also, I have seen other coders I really consider high-end having the same considerations (it might just be a bias, where I just notice those, who agree with me)..

Have you ever seen the "competitions" where they give a really really good photographer (or videographer) a 50$ toy and lets them compete against an amateur with a really high end setup..

Only amateurs blame their tools (above a certain minimum threshold)..

I'm gonna go out on a limb here and say that the amateur does worse than the pro is because said amateur doesn't know how to use the (often very complex) tool that they've been given, whereas the pro knows all of the theory and at least mostly how to use this toy.

You've really never used CTRL+X F to look up a file name in vim?

Can you elaborate how 'Ctrl-x f' looks up a file name?

I tried 'Ctrl-x' but it decrements the integer under the cursor by 1. I tried 'f' but it starts a new motion command to search the next occurrence of the character following it to the right. Example: 'fx' will place the cursor on the next occurrence of 'x' to the right.

How can I use 'Ctrl-x f' to look up a file name?

It's an insert-mode binding, built in by default.

In addition to being an insert mode command as jshholland already noted, it is Ctrl-x Ctrl-f, not Ctrl-x f.

Here is a description of it and a few other insert mode commands: https://georgebrock.github.io/talks/vim-completion/

Fascinating. These ctrl-anything is like a dangerous, crippled emacs lurking in a dark corner of my beautiful vim, ready to terrorize with keyboard coords over modes and commands ;)

I've bound some complete-plug-in to tab, but that's pretty much all I do in insert-mode command-wise.

My use of vi-like editors is sufficiently minimalist that I use a locally built http://ex-vi.sf.net/ and still don't really need more than about half the features of that.

I -personally- find it way more comfortable than even a minimal vim install because when I typo a command it beeps at me, whereas in vim I generally accidentally activate a command I don't understand and get broken out of flow while I figure out wtf just happened.

I don't at all judge people who're IDE wizards, I've not seen any correspondence between maximalist versus minimalist taste in tooling and competence, but this approach works way better for me.

> in vim I generally accidentally activate a command I don't understand and get broken out of flow while I figure out wtf just happened

This doesn't happen to me very often anymore but when it does I’m grateful for multiple undo, I’d be scared to use an editor without it.

So interesting.

> where a lot of "auto" programmers are merely constantly picking of a list, which I think breaks their thinking flow...

For me, typing when the computer can type faster than me breaks the flow. Though your auto complete is very bad if it needs you to pick things from a list - 99% of the time it's just "type a couple of first letters, <ctrl-space>, repeat for the next token."

> Consider a piano player that needs to look up the right keys before every stoke..

Most professional classical musicians play with sheet music, no ?

> Most professional classical musicians play with sheet music, no ?

That is WHAT to play, not how to play... also I actually thought more of improv players, but that wasn't stated :)

I don't consciously type...

I think, my fingers type...

I spend 0% brain cycles on typing (it is pure muscle memory), which why picking from a list (or checking that autocomplete choose the correct) is more brain work...

> I spend 0% brain cycles on typing (it is pure muscle memory), which why picking from a list (or checking that autocomplete choose the correct) is more brain work...

but, it's definitely not "more brain work", just like stenography does not take "more brain work" to write - when you're used to it you don't need to look at the autocomplete output either, it's just a very shorthand way to get things from your brain to your computer.

I just need to trust my fingers, you need to trust an algorithm choosing something for you.

For me, checking whether auto-complete choose the correct is more work that typing the correct thing, as my fingers type on their own - almost without supervision...

I have written code for 30ish years (professionally for 25 years) and I have honed (and still hone) my environment for maximally "transparency" so that my though is not hampered by tools..

If that is not true for you, then use your IDE and be happy about it... Nothing wrong with that, at all...

EDIT: also fun, that you highligt stenography that is the definition of learning-curve/musclememory ... :)

> I just need to trust my fingers, you need to trust an algorithm choosing something for you.

but, that's the thing, I don't even remember the last time my autocomplete didn't complete the right thing. So yes, I entirely trust the algorithm, it has already saved me so muchtime.

In my experience simple tools leads to simple designs. With the aid of an IDE the architecture/design of an app can become insanely complicated.

Vim has built-in auto completion, for some languages (Python, C, ...) it can even be kind of smart. There are many videos showcasing the power of vanilla Vim

https://youtube.com/watch?v=XA2WjJbmmoM

https://youtube.com/watch?v=Gs1VDYnS-Ac

Not GP, but I have a linter that runs on commit, and generally it doesn’t catch anything because I’ve learned not to make the mistakes.

I have never liked autocomplete. If I know the type or method I’m looking for (which is most of the time) then typing its name is not a hardship, and takes really no more time than finding it in a list.

If I don’t know the type/method, most of the time I have the documentation up in another window or monitor, and I’m going to want to read that in depth anyway, since I’m not familiar with the type/method, so autocomplete wouldn’t save me any meaningful time.

I agree with you, but this depends on the language. Some languages and libraries take more liberties with the length of identifiers, the amount of abstraction layers, and maybe more. Java is the classic example where using a plain text editor is really a liability; I can use C++ without any editor support and be fast. But I'm not sure what this really depends on. (Disclaimer: my argument is flawed because I know C++ well and not Java.)

There may definitely be something in that. I’m writing Rust or C most of the time.

Despite your disclaimer I think you are onto something.

I am experienced in both Java and C++ and while I can read/write/refactor code in C++ just fine with Vim, doing so in Java without a sophisticated IDE is a painful experience.

Plugins are a bonus for vim, but one doesn't really use vim just because of the plugins. There are far better editors for this. Decidated vimmer usually make heavy usage of external tools, instead of integration which plugins bring. There is the term "Unix IDE" for this, you can read a bit online about this (for example: https://mkaz.blog/code/unix-is-my-ide/ )

I also use no plugins (because I often have to ssh to many network servers). I have found a surprising benefit in my coding to "coming to know" things about library APIs and projects through mental "muscle memory". For instance, by not relying on a file browser or even a fuzzy finder, I eventually come to learn where certain files probably are... and the probability goes up the longer I am in the code base. Similar for lib APIs; although my vim session may be on a remote machine via xterm, that doesn't prevent me from having a local browser window open and reading API docs to find what I need often helps me understand the library better.

Also vim user. I use fairly minimal plugins. Mostly Nerdtree and the tabs plugin for that, formatting plugins for various languages, and CtrlP. I've tried autocomplete a few times, but never found it worth the trouble. Might be because I mostly work in dynamic languages where autocomplete is mostly awful, and it's easier to just remember, yank from elsewhere, or lookup function names and signatures than to get anything useful from autocomplete.

I don't really like realtime linting, autoformatting, or error highlighting either. I find it highly distracting, and usually it's complaining about something I was already going to fix anyways. I'd rather have such things done only when I intentionally trigger them. I'd say please stop whining about syntax errors and test failures in code that I haven't finished writing yet.

I've tried some Git plugins, but never got into those either. I still prefer the gitsh cli application for most of my Git work.

And does ox even have a plugin system? I don't see anything for that.

Yeah.

> Ox is easier to use than Vim because it doesn’t have modes where the keyboard is repurposed, however it takes the idea of being a keyboard-only editor and being able to act just like an IDE after some configuration.

Modes in Vim re-purpose the keyboard. What does Ox do to re-purpose the keyboard? You can't have all functionalities on CTRL+? bindings.

> in Vim re-purpose the keyboard. What does Ox do to re-purpose the keyboard? Y

I don't use plugins just because I don't know what or whose system I'm going to be using vim on. The reason I use vim is because it's everywhere. When I started programming, I used emacs, and actually dropped it years later for that reason.

Are you a consultant?

vi is everywhere, vim less so.

The *BSDs come with vi for example

For me, "downgrading" to vi (vs. vim) is only a slight annoyance..

A fresh install of Debian also comes with vi and not with vim. It's actually ridiculous if you think about the fact that vim was published 1991

That is also the case for me.. I log into 50+ different boxes with different security policies (due to different orgs) every week..

I used to be this way for a decade+, then I learned that vim can open and save scp: urls. (Note: it has a weird scp url syntax you have to look up.) Coupled with a fancy ~/.ssh/config that sets per-host ProxyCommands and such, now I always edit locally.

Correspondingly, I have a lot of cool plugins in my .vimrc now, and my editor works better.

Bonus: no remote echo typing lag! (Yes, I know about mosh.)

I am not always allowed to bring my own laptop to the network...

Do they make you use the console with a paperclip and a DB-9, too?! That’s gotta be a bummer.

No, but no "foreign" computers... We can have tools installed, but even though those are windows machines (I run linux on my laptop) my only "custom" tools are a good ssh-client and firefox :)

Not everyone is ok with you exfiltrating their data to your computer.

If you're running the ssh client on your own computer, even with a remote editor, the file you're editing via ssh is being exfiltrated to your computer regardless, just in a different format.

Yea I mean if you wanna talk PLUGIN CENTRIC, emacs is definitely the 800 lbs gorilla here. Thats said I'm a vimer who now uses vscode for 90% of my work because I like pretty colors and I can setup everything I need to work in a few clicks.

Ha, I actually tried to use VSCode, but went back to vim because it needed 'a few clicks' to set up everything.

I hate things not being configured explicitly in files that I can version control.

VSCode let’s you do that, with the .vscode folder either globally or locally per-folder/project, for what it’s worth. Unless I misunderstood what you meant!

At least at the time, the format was really not conducive to it, especially re plugins that should be installed, and on macOS since it used Electron's config mechanism it all got stuffed in ~/Library/Application\ Support/VSCode.app/Resources/macOS/Content/package/config/vscode.config or something horrific.

I primarily use Linux, but I don't want something as crucial as my editor to unavailable or differently configured (so I can't just clone dotfiles) on macOS which I might sometimes use. Which, again, last I checked, means no Electron for anything that 'crucial'.

(I think it's fair enough for maintainers of these things to defer to Electron on config locatio, but it's unfortunate that Electron decided what 'platform standard locations' are irrespective of what the tool is, whether $XDG_CONFIG_HOME is explicitly set, and what other tools do or user preference is.)

> especially re plugins that should be installed

Again for what it's worth, that's also been added, and I certainly haven't had that issue on macOS myself? It loads it from the project I have open, or my home directory base settings.json

It’s modal plus the text objects/motion system -

http://vimdoc.sourceforge.net/htmldoc/motion.html

Eh... what turns me off is that list of features and other editors that just names off other editors as inspiration. Don't even mention other editors unless you are fully copying their features.

Imagine a car being advertised in a similar style called Imacar.

Ferrari, know for its Italian design and sleek lines, Imacar takes those famous design cues by including wheels and tires.

Toyota, known for it's rugged truck's like the Hilux. Inspired by that ruggedness and repairability the Imacar includes easy change windshield wipers.

Tesla, know for their famous electric motors and batteries, inspired us to add a battery to Imacar's petrofuled engine.

I think comparison list with other editors gives good introduction about what to expect from ox, For any terminal text editor comparison with vim, emacs is inevitable. It is good to know authors opinions.

If you're expecting vim or emacs, you're in for a bad time.

It's entirely unclear what niche this editor is aiming for. If it's a replacement for the editors it claims as inspiration it's not going to succeed.

For sure. Also the author is probably going to get bombarded by people referencing their favorite editors. This may help them get out in front of that scene...

> good introduction about what to expect from ox

Yes, after reading how the author described vim and emacs, I knew this project was not for me.

"vim only provides basic text editing functionality by default"

It looks like someone has never read the vim manual.

Yes, and at the same time the author claims: "Ox is easier to use than Vim because it doesn’t have modes where the keyboard is repurposed"

So vim both only provides basic text editing functionality and is harder to use than Ox?

Vim has a special "insert mode" in which the keyboard is repurposed for entering text. I don't think that's a very hard concept to grasp.

Comparison is fair. What's presented there isn't exactly a comparison, though. It claims to "take features from some of the most popular editors out there, gaining the best of all worlds", then proceed to list features that are decidedly not the best, nor even differentiating:

- Vim: they took away "being a keyboard-only editor" (every CLI/TUI text editor?) and "being able to act just like an IDE after some configuration" (most programmer text editors?). Also, "being a keyboard-only editor" isn't even accurate for vim, it totally supports mouse input even in a terminal: https://vim.fandom.com/wiki/Using_the_mouse_for_Vim_in_an_xt...

- Emacs: they took away "a configuration system where you can change the colours and appearance of the editor"... This is adequately discussed elsewhere in the thread.

Therefore, gp's analogy of taking away wheels and tires from Ferrari is apt.

And if this is the first car you are building, that may even sound pretty impressive.

I’m not really sure what to think of everyone being so negative here.

Who argued whether it’s impressive or not? People are not impressed with the rather pointless “we take the best features out of popular editors” section of README that neither adds to nor detracts from the editor itself, and only unnecessarily antagonizes people by mischaracterizing other editors.

You can build an impressive car without pointlessly referencing Ferrari.

> Don't even mention other editors

Why not? Your car dealer will happily compare and contrast the different models too.

It is perfectly fine and valid to explain how the "new" thing fits into the crowded landscape of similar offerings. Especially when the reader is likely to be familiar with many of the "landmarks". Using other products as a point(s) of reference is very useful.

Comparing Emacs Lisp to any other configuration system is like comparing the Sydney Opera House to your log cabin. (This is coming from a vim user)

My suggestion: scrap the entire section which compares Ox to other editors. Replace it with something which pitches Ox to people who use text editors and might want to use yours.

I came away from the compare-and-contrast part confused and nonplussed.

It's also perfectly alright to say "I wanted to write a text editor in Rust, so here it is! I like it and use it, you might too".

Yeah. The section that compares it to Vim seems to misunderstand that people actually _like_ the modal nature of Vim, and that it's one of its main advantages.

Also, when I think of minimal I think of nano or ed (I have not used ed but it still comes to mind). Vim is pretty complex out of the box if you think about it, and that’s what enables the tons of plugins that you get.

He correctly surmised that it’s hard to learn though. I’m 10 years in and it’s still a pain.

I can guess why this is. You're probably fighting it instead of embracing it, or perhaps have unrealistic expectations for yourself. Embrace it, and understand it's OK to not know every single thing. I doubt that's even possible for an average user.

:help user-manual is not hard and it won't take 10 years of your life.

But there are also a lot of people who _don't_ like the modal nature of Vim too. Ox not being modal is then one of its main advantages over Vim in that case.

Those people aren't users of Vim. Users of Vim use it _because_ it's modal, not in spite of the fact. There's scarcely any other reason to use it.

There are a lot more than just Vim fans who are reading that section of the readme.

Either way, it is fair to clearly state where the project stands regarding the modal style interaction vis-à-vis Vim.

> Ox took the idea for the customization and extensibility of Emacs and made a configuration system where you can change the colours and appearance of the editor.

Thanks but no thanks. Almost all editors let you customize the color and appearance. Few allow you to customize to such a deep extent as Emacs.

I thought something similar... they referenced emacs, and they took away... customized coloring? And appearance?

Really?

That and not taking away modality from vim makes this project seem like a parody.

They also ignored the modes and composability of Vi.

Chalk up another mark on the board of unserious things the Rust community does with its time.

Edit: I'm sure this will be an unpopular, downvoted comment. I just want to say that I think that Rust is a fantastic language with an enthusiastic community. It's just a community that repeatedly demonstrates that it doesn't know what "good" looks like and has the world's worst case of NIH. Something about the community attracts the like minded.

Damn, what a shitty, negative comment.

Well, if these weren't the results that the community produces over and over and over and over again. Look up any of the long list of "X in Rust" Show HN posts that there have been.

It's kind of a meme at this point.[0,1,2]

It's going to start effecting interviews. I'm saying this as a hiring manager who has to evaluate what projects candidates spend their time on and what they are going to be like to work with. People who oversell their work or don't know how to evaluate value go into the hard pass pile.

And no, I'm not shitting on them for having a hobby project. I'm shitting on them for clearly demonstrating that they don't understand what the very mainstream software they're actively trying to compete with does.

[0]:https://transitiontech.ca/random/RIIR [1]:http://adventures.michaelfbryan.com/posts/how-not-to-riir/ [2]:https://news.ycombinator.com/item?id=21334510 (which is just the comments here from [1], but also interesting.

It's someone's hobby project, they are probably having a great time designing and building it. I bet they've learned a lot doing so.

It's no longer a hobby project when you have the most prominent section of your README comparing your project to a bunch of other mainstream software and you're arguing for why people should use your project over those.

It's not a hobby project when you've shipped your Brew into Core and reserved a name.

At that point, we get to make the apples to apples comparisons.

Props to the Arch community for having the good sense to keep this in the AUR.

Are you implying that if you make an effort to share and promote your work to others, it becomes a free-for-all where criticism with any tone whatsoever is alright? If not, what is your point in arguing whether it's a hobby project?

There are people who take an effort to produce something and then take the extra step to show it to others so they might learn or collaborate. And those people often get comments where their project is being picked apart with a fine-toothed comb, packaged in an abrasive tone.

This happens over and over again in IT. There's plenty of people with insecurities who - for reasons that psychiatrists understand better than me - rejoice in taking others down.

Lots of people would say it's because we are hidden to each other behind the screen and would never say this stuff to a colleague. I guess that's part of the reason why it's so prevalent in HN. Though, I've seen the same style of rhetoric in the industry, face-to-face.

"You should go to back to school before talking about CSS" and plenty of laughing was something directed at me when I suggested that the ´class´ attribute for HTML tags has semantic meaning beyond just hooking up CSS rules to it. I had trouble explaining it, but my colleague with longer industry experience took it as "lol this noob junior programmer doesn't even understand what ´class´ means". He didn't even stop to consider how class attributes can be used through Javascript and beyond, he immediately went for taking me down as fast as possible.

And that f'ing hurt. And after that I have probably been toxic to other people too. I wish I could go back and undo all the times I have hurt someone like that. Totally unnecessarily and without reason. But I can't. That's why the least I can do when someone suggests that "hey, tone it down a bit" is to shut up with the explanations why I am right to say what I'm saying and think whether there's a more constructive way to go forward.

Rust deserves negativity, though, just for balance’s sake.

Nevertheless, this project is somebody learning Rust on an intermediate/advanced level. Nothing wrong with that, and people deriding it because it cannot compete with real text editors with millions of man-hours behind them are behaving bit silly. Who knows, one of these exercises might become a great editor some day.

I never expected it to compete with real editors. I'm just disappointed by the flippant and very dismissive "comparison" section, which manages to perfectly miss what makes each editor so popular. asciimov's comment sums it up.

https://news.ycombinator.com/item?id=24976470

HN gonna HN.

As a counterpoint, ripgrep is good and serious and the only grep I ever use if I can help it.

https://github.com/BurntSushi/ripgrep

Does one project reflect on the whole community? Does your one comment reflect the attitudes of the hacker news community? :)

I've also seen (elsewhere) "inspired by emacs ... it has emacs keybindings".

One of the advantages of emacs is that an insane level of customisation is possible. Or, more practically, the high level of customisation allows for a lot of low-hanging fruit for people to create editor macros that suit their usage.

> "inspired by emacs ... it has emacs keybindings"

Lol, incidentally macOS native text fields / text views support a bunch of Emacs keybindings out of box (C-f, C-b, C-n, C-p, C-a, C-e, C-k, C-d off the top of my mind), so any native Mac application with any text input can claim “inspired by Emacs” for free.

that's likely a side-effect of emacs bindings being the readline default in Bash more than anything. (set -o emacs)

What will be interesting to see is if this changes now that zsh (which does not use readline) has become the standard...but alas, if you don't have EDITOR or VISUAL set, emacs is the default there too...

As for those curious, emacs is the readline default because readline is part of the GNU project.

What are you talking about? I’m talking about Cocoa NSTextField, NSTextView etc., got nothing to with libreadline or bash, unless there’s a history lesson here you’d like to share.

Edit: Your comment was expanded as I was replying / after I replied. From which it’s quite clear you didn’t get my point.

Oh I get it, I think you're just underestimating how much effort Apple's developers put into system-wide consistent behaviors in macOS. And also how picky developers are about keyboard first and changing keybindings.

They decided to use emacs bindings because emacs bindings are the system default for macOS programmers.

Apple's developers were also macOS's first users and they started with a terminal long before they had a working UI.

Reread your comment. I misunderstood the first time round. You presented a theory that Apple implemented Emacs keybindings for Cocoa text input widgets not because of Emacs per se, but rather, mainly for consistency with bash. It's an interesting theory, but without a history lesson backed up by sources it's still a theory.

For the record I don't underestimate how much effort Apple puts into system-wide consistent behaviors in macOS. <s>Also, zsh's default keybinding mode is Emacs mode.</s> (Of course, you did mention that.)

Indeed, it is just a theory, which is completely reasonable of you to point out.

Technically, that was systemwide inconsistent behavior.

Readline compatible keystrokes came from nextstep (sorry, I don’t dare to guess how to capitalize that). Traditional Mac OS used completely different key combinations (command left arrow instead of control-a, for example). Because of that, Carbon apps didn’t support readline-like key combinations (but system input fields did)

The two could happily coexist only because the Mac originally didn’t have control keys (it only got them for supporting terminal programs, as part of trying to make Macs sell better in business), so none of its navigation keystrokes used the control key.

Really nice, did not know that. Thanks for the tip!

I recently showed an OSX based colleague some bash key bindings. He was amazed that I knew these, even more when I replied emacs has the very same key bindings.

GNU readline shows up everywhere.

Exactly. You can even add some more on your own. Just add the file ~/Library/KeyBindings/DefaultKeyBinding.dict and fill in. I added M-f and M-b but you can add more to make the experience even more Emacs-like.

basically this is what stood out to me. that and mentioning Vim modes and saying, "but not this!"

still, I don't like to be harsh. there is a difference between treating this as a serious alternative to a Vim or Emacs (or whatever) and a programmer resume piece. I could see it being quite fun to develop my own editor as a toy project.

Yeah, they missed what makes Emacs so customizable: its architecture.

What makes Emacs great is that the low-level text editor features are implemented in a compiled language and then exposed to an interpreted language to be composed into the actual editor. If they're not splitting the architecture into a compiled part and an interpreted part, they aren't taking anything from Emacs.

The compiled/interpreted architecture is only important because Emacs is written in C and Elisp isn't incrementally compiled to native code.

If Emacs was written in Lisp (like Zmacs), then it would have the same flexibility it currently has without having to contain an interpreter of any kind, and the user-written customizations would have the benefit of being compiled to optimized native code. Some things that you can't do in Elisp for performance reasons would be perfectly doable in a Common Lisp version of Emacs.

To me it sounds like it’s been written in a humorous spirit. That, and things like “You can use the keys Backspace and Return / Enter as well as all the characters on your keyboard to edit files!”

> Nano is an editor that is very simple to grasp due to its intuitive key bindings such as “Ctrl+S” to save and “Ctrl+?” for the help menu etc.

I don't think that's describing nano or pico, at least, no version I've ever used had those keys doing useful stuff. Maybe this is supposed to reference some other editor?

Yeah uh what, I don't know any other cli editor than Nano and I'm pretty sure CTRL+O is write and CTRL+W is write and exit.

Ctrl+X is write and exit while Ctrl+W is "where" IIRC

⌃X is just close.

Recent nano has changed to allow Ctrl-S to save in addition to the previous default (Ctrl-O)

https://www.nano-editor.org/dist/latest/cheatsheet.html

Oh thank goodness!

I'm constantly reflexively reaching for ctrl+s and then correcting myself just at the last second.

It's only intuitive to people who grew up with PC-style keybindings as well—the editor does not appear to bind super-s despite this being the other obvious keybinding.

How do you save and exit from Ox? I tried :wq!, but it doesn't work!

Took me by surprise as well

Weird amount of negativity in this thread, of course it's not going to compare to editors with decades of development.

Pretty impressive what you've put together! I'm sure it's really cool being able an editor to work exactly the way you want it to work.

Agreed, I thought it was amusing that there's a comment saying, "wow this headline is perfect for HN" and yet so much negative talk in the other comments.

I guess this happens as you approach a really specialized set of features and aesthetic--it activates some kind of nitpick psychology, where people who are proud of their specialization are able to demonstrate their unique ability to perceive just what makes a thing in this domain really special. Well, they spend a lot of time working with these interfaces and thinking about it, so it makes some sense--the thought-energy needs to be expressed.

Anyway IDK if one can easily demonstrate that kind of deep specialist insight and also pay attention to how it makes them sound in relation to the author and the author's gift to the world. It's easy to get caught up in what your own perception is offering the world, and kind of steal the stage with what is likely to be perceived as a weirdly negative energy.

> Agreed, I thought it was amusing that there's a comment saying, "wow this headline is perfect for HN" and yet so much negative talk in the other comments.

Well, the headline is perfect for grabbing HN's attention, and the comparison section is perfect for making HN angry, so that's only to be expected.

Editors are practically a religion. No surprise OP is called a heretic.

Because the readme says this: "What features does Ox have and why should I use it?".

Instead it should say: "This is a toy project of me. Learning about text editors. It got pretty far and is really usable. Give it a try."

Also there are zillion articles about "rewrite software x in rust because it's written in evil unsafe C". The author doesn't say this but i instantly think about it if someone tries to write a better vim.

I think much of the hate is because the thread title wasn't prefixed with a "Show HN" to indicate a pet project. Instead it's read as a possible contender in the editor space. Combine that with the somewhat naive, selly text in the readme and you got a nice negativity storm brewing.

It's a really impressive feat to accomplish something like this, and it's sad that it gets framed unfairly. I just hope it doesn't deter the creator. Maybe in the future it could indeed be a serious option for people that want something between nano and vsc.

As far as I can tell, this is basically a toy project to show off the programmer's skills and practice doing something in Rust. It's also probably something that was fun to do and the programmer would probably like to show it off.

Treating it as some kind of alternative to Emacs or Vim is probably missing the point.

Agreed. This should probably be under ShowHN. I was expecting to see an semi-finished product here. And even the first sentence of the "About The Project" section states:

> Ox is a text editor with IDE-like features.

And then we had the actual feature list, current version seems to be 0.2.5.

> Auto indentation (0.3.0) > Auto brackets (0.3.1) > Auto complete (0.3.2)

Which are quite essential for calling something "IDE like".

Other than that. It looks nice. I've seen people calling it an Nano replacement in the comments here, which seems to be missing the big point of nano - it's easily available in a lot of *nix systems by default.

The editor feature list sound definitely promising and certainely has appeal.

I've tried micro, psi but they're not in a state I can use them daily.

What i'd love is basically sublime text in a terminal. I tried ox, but it's currently a bit buggy and non intuitive (no help that I could find, no backspace, cursor on the wrong line..)

Nothing wrong with this, it's a work in progress and early in its development. It shows great promise and I'll definitely check back in the future !

Strongly agreed. Every time anyone makes anything people will always say "why are you making this, since there're better options like x, y and z".

This editor seems lovely, it has very interesting features and it looks nice.

Yet, I hate the punchline "A Rust powered editor". Why should anybody care? Other text editors are never presented according to the language they are written in! For one, I'm getting a bit tired of this obsession with Rust, as if being written in a particular language was somehow an interesting feature.

Binaries written in Rust or Go tend not to require external libraries and tend to be a little more cross-platform than average, it seems. I tend to like things written in Rust or Go.

You know, -static is a thing.

> Why should anybody care?

Potential contributors to the project may care.

A lot of unnecessary hate here. I think many are missing the use case. You use your own favorite and highly customizable text editor? Cool! This might not be for you.

I think this would be a fantastic text editor for anyone new to the terminal. Provides some syntax highlighting, a nice background, line numbers, tabs, and mostly familiar controls without a ton of setup.

I think there are still quite a few improvements I’d love for it to have, but this might be the thing I recommend to anyone first starting out in the terminal who wants a bit of a nicer editor than nano.

How many people out there are willing to commit to a terminal text editor that isn't either emacs or vim? I feel like, if you're committing to a steep learning curve, you may as well commit to a steep learning curve that has a real payoff at the end.

An editor without a steep leaning curve? Like what we use nano for now?

Micro has little learning curve, if you know GUI key bindings.

This is a pretty looking editor! PageUp and PageDown going to the start and the end of the document is questionable! Typically we use ctrl+home and ctrl+end for that. PageUp and PageDown should go a page up or down respectively.

I really like that inspirational editors are mentioned. For one, there were some on there I didn't even know existed. Second, you might want to try out some different ones before you settle on the one you like. Personally I rather liked Micro, for instance, but now I'm definitively going to give Ox a go too.

I think the negative remarks come from people who are probably both very knowledgeable and experienced, but also entrenched in "their" editor, and perhaps they didn't feel the blurb gave "their" editor the justice it deserves, while this isn't an editor that purports to be the "best" out there, or even the most advanced.

Personally I've never been a fan of using the terminal for anything else than reviewing code, so Micro is enough for me. It has text highlighting and commonly known Windows-esque shortcuts. To compare this to Emacs, which I've given my best shot, it just turned out way too complicated for my needs, and there's a ton of extra stuff to learn that I just wasn't motivated for on top of learning to code.

Once I saw the high treshold for getting into Emacs, I just opted out. Perhaps it is better in many ways, but I was instead lured in by Sublime Text, and I've stayed there ever since. Is it "better"? IDK. It's what works for me.

I mistook the screenshots in the README for screenshots of [Doom Emacs][0]. The default theme looks similar.

[0]: https://github.com/hlissner/doom-emacs

> [Vim] has a steep learning curve due to being a “modal” text editor, having special modes for editing text. Ox is easier to use than Vim because it doesn’t have modes where the keyboard is repurposed, however it takes the idea of being a keyboard-only editor

I, and I think most heavy vim users will agree, think that Vim's modal editing is one of it's great strengths. Sure, it has a steeper learning curve, but once you learn it, it is amazing.

The main thing I want from a terminal text editor is to have the same keyboard short cuts as any other program I use, which is why I use micro. In the screenshot I see Ctrl+W to save as. Why not use Ctrl+Shift+S like any other program? Why not use Ctrl+W to close tabs, again, like any other program? I can already see myself closing tabs in other programs trying to save as, if I start using this.

There are limitations to which keyboard shortcuts are available to an application running in a terminal. And those limitations often vary per terminal.

In other word: It ain't that easy.

“… any other program?” ^W has been erase-word in Unix terminals since the ‘new’ tty driver 40 years ago.

> Vim provides a plugin system for adding features to it as it is very minimal and only provides basic text editing functionality by default.

Clearly the author does not understand Vim. Seeing this gross misunderstanding, I can confidently assumee that Ox does not even have a quarter of the features and editing capabilities that an editor like Vim or Emacs providee.

The readme is confusing: it says it wants to take the best of all text editors, calling out Vim first (note that the editors are not listed alphabetically), and specifically mentioning modal editing. But the rest of the readme looks like vanilla `PageUp` and `Ctrl+C` instead of `GG` and `yy` to me. So...is it modal or not?

"Ox is easier to use than Vim because it doesn’t have modes where the keyboard is repurposed, however it takes the idea of being a keyboard-only editor and being able to act just like an IDE after some configuration."

Modal refers to Vim's insert and normal [and visual, etc] modes, where [almost] anything typed in insert mode is entered into the buffer, and you can [sorta] only navigate and manipulate the text from normal mode. The command examples you quote don't really have any bearing on modality.

> The command examples you quote don't really have any bearing on modality.

They do, actually. What happens if you type `yy` in a non-modal editor? You get "yy" in your text. It only works in Vim because you're in normal mode.

> Ox aims to be an editor that takes features from some of the most popular editors out there, gaining the best of all worlds.

> Vim http://vim.org: Vim provides a plugin system for adding features to it as it is very minimal and only provides basic text editing functionality by default. [...] a “modal” text editor, having special modes for editing text. Ox is easier to use than Vim because it doesn’t have modes [...] however it takes the idea of being a keyboard-only editor and being able to act just like an IDE after some configuration.

Interesting, mentions vim first in list of taking features from popular editors, and explicitly doesn't take the one feature that everyone takes (when they take any)!

Looks cool from a distance, and looks more user friendly than most! However any modern editor which doesn't support multiple cursors (be it terminal or gui) is missing the start line of the race these days.

Can you even display multiple cursors in terminal?

Sure you can, but you have to use a trick. You can fake it by modifying the background color of the cell where the cursor is located. Many terminal editors have support for multiple cursors.

I assume this doesn’t work if your terminal uses a vertical line to show the cursor?

Yeah that's a drawback -- multi-cursors will be displayed as blocks regardless. As far as I know there is no way to solve that, but using block cursors for multi-cursor operations isn't that bad.

You can emulate it visually with white-background text.

PageUp/PageDown key binding is strange. I'd go to a natural one instead (the keys are named for a reason) and bind top / bottom of the document to Ctrl + PageUp / Ctrl + PageDown.

> bind top / bottom of the document to Ctrl + PageUp / Ctrl + PageDown.

I think most editors on mainstream Linux distros and also Windows use Ctrl + Home/End for to go to the top/bottom of a document.

This is sort of off-topic, but something I've been looking for is a good editor for writing prose. I want my vim keybindings because even with prose, editing is a big part of writing, but I want sane formatting -- margins, soft line breaks at reasonable text width, that sort of thing. I have not been able to get my vim configuration to a satisfying place for this use case; it seems hopelessly tailored to the code editing use case. Does anybody have something that works really well for this for them?

One of the selling points for Vim and Emacs is that they are pretty impressive at raw text editing, having "simple, intuitive" keybindings like nano seems to go against this goal?

I'm still installing mc on every linux machine I own just o be able to use mcedit. It's still the best text editor for me and it's sad it stopped being included by default.

I'm used to the shortcuts, the syntax highlighting works, and you can run shell scripts on selected text which is the best "plugin system" if you ask me.

I've tried to switch to vim and emacs a few times but they are too big an ecosystem and I don't want to change EVERYTHING at once.

> Ox is so lightweight that it can be used on older computers.

The vagueness of this statement is great.

It only requires 1TB of RAM and 8 Xeon cores.

If people are interested in alternative text editors, two quite interesting ones' I've come across recently were:

http://kakoune.org/ (very interesting concept about "turning the modal editing of vim around)

and https://github.com/fox0430/moe (written in nim)

Perhaps a tangent: I wonder about the true utility and longevity of a project that advertises itself foremost based on the language it is written in, when that should never matter to the consumer. It comes across as a hobby project or a portfolio entry or a tech demonstrator. If it was intended as such: kudos! That is quite an achievement.

> ... heavily bloated and resource hungry editors such as VS Code and JetBrains ...

Normally they are fine, but add the indexers and code parsers then everyone is bloated. On my emacs + lsp, lsp is the one using a lot of cpu/memory resources.

> Emacs is still actively used today ... I would change much of the Readme.

There is a popular Rob Pike's quote on writing terminal based text editor, "Everybody writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful". Then as any self-respecting hackers will do, he wrote Sam text editor few years after making the remarks [1].

Writing text editor seems to be the second favorite hackers past time activities after perhaps writing a compiler for APL and Rob did it too :-)

Anyway, congrats to the Ox editor authors for having a go, and personally I like and commended the fact that on the project Github page they provide the comparison to the other popular text editors.

Since Ox is both front-end and back-end implementation based on Rust based libraries, it does shows that Rust based eco-system has been growing steadily.

I have two features suggestions that perhaps can take Ox editor to the next level and be more useful.

Firstly, as mentioned by the sibling comment's buried towards the end of comment section, on the very large file (VLF) feature for opening big file. This can be implemented by the help of RRB-Tree data structure and the Rust library is already available [2].

Secondly, is the CRDT feature that can be implemented with the automerge library. It seems Rust based automerge library is still in its infancy but perhaps by more project adoption, it can further accelerate the development [3].This second feature is very useful for local-first text editing capability enabling both offline and online collaboration feature that can propel Ox to stand out from the crowd.

[1]https://news.ycombinator.com/item?id=20607261

[2]https://github.com/ArazAbishov/pvec-rs

[3]https://github.com/automerge/automerge-rs

I'll be cheeky and post this top level. Sorry if it's out of place. On the discussions of opening large files, I grant emacs does tend to choke on long lines but when each line is moderate it can open pretty large files.

What I can't see here is any mention of VLF mode (get via elpa/melpa) in emacs which allows you to open very large files (per acronym) which are mem mapped.

I just opened a 3.3GB .mpg and it opened immediately. Seems to be editable but it gets verrrry slow (has to page huge amounts and create temp files if you edit) and I've not verified that, but in the rare case I need to browse a multi-GB file, it has worked for me.

Anyone used vlf mode in emacs more extensively, please chime in.

FYI, HTH

There is a statistical package with the same name https://www.doornik.com/products.html#Ox

These days I'm working on log files sized around 300mb. Vim is slow and some times stop responding. Geany edior works most of the time. Do you guys have any recommendations?

sed

This will likely be the most correct and most underrated answer.

I wish to give you enough money for a coffee and a fancy cookie.

If you're not editing them, then lnav is what you need: http://lnav.org/

For reference, a 435MB web access log with about 3 million lines takes:

* lnav about 4 seconds to index[1] and display

* vim about a second to display

* emacs about 3 seconds to display

This is on a late 2013 27-inch iMac with a 3.5Ghz i7 and the file cached.

[1] - Indexing in lnav involves parsing all log lines to extract their timestamp and log level (status codes in this case)

Years ago a friend had a problem like that, I suggested janky old programmers notepad 2. Which worked for him.

I haven't used this but watched a talk from the author about how it can load huge files really quickly and can even edit while saving. Sounds pretty god tier in terms of performance:

https://github.com/arximboldi/ewig

Check out the talks from Juan Pedro Bolivar Puente. They are truly next level imo.

Do you have a lot of plugins? I updated my config to disabled plugins when the file is above a certain size and mostly have no problems.

I've edited 1GB sql dump files in Vim with no problem. I had to turn off my vimrc for it to work, but 300MB should be no problem as long as you are using barebones vim.

For performant buffer-wide operations (:g, :%s), I had success with using vim like an improved sed by passing in commands directly via the command line. That was noticeably faster than opening vim up and running the commands before exiting e.g.

    # join together lines delimited by LF into one line, then convert all CRLF into LF
    vim -Es \
        -c 'g/[^^M]$/.,/^M$/join' \
        -c ':%s/^M$//g' \
        -c 'wq'

Looks cool, but the author should test this with different terminals and different settings. I have gnome-terminal with white background and black font, and ox uses its own dark-grey-blueish background with the black font from (I presume) my settings, making the title and the text of the file itself completely unreadable. I'm glad that there exists a system to customize the settings, but I'm too lazy to bother, and it should work by default anyway

I personally started to use Amp, more what I am looking for :

"Heavily inspired by Vi/Vim. Amp aims to take the core interaction model of Vim, simplify it, and bundle in the essential features required for a modern text editor. Written in Rust."

It's also a terminal editor btw

https://github.com/jmacdonald/amp

A disadvantage to terminal based text editors is that you are limited to the performance, unicode support, etc, of the terminal emulator.

Writing a text editor is a great way to grow as a programmer. There are some really interesting problems you have to solve, and you can see it in the comments: handling long lines, big and small files, making it load fast, dealing with Unicode... and that's before you get to the fun parts like search and replace, and extension apis.

maybe I'm missing fonts, but rather than the icons at the bottom (a new document icon, a rust icon, 5 horizontal lines icon ...) I see Japanese characters. As a test I also opened a sh file and it was unable to color the syntax. Hopefully this continues development, but right now it doesn't look ready

I can only express myself in English, but I laugh every time a developer explains how easy their tool is to use because one types “ctrl-f” for find and “ctrl-s” for save, etc. The day these developers learn that the latest Cool Tool uses non-English command mnemonics is going to be a rude awakening.

Any plans to add a folding feature? Vim has a plugin which lets you hide the code under the definition unless you want to unfold it to see/edit it. e.g. folded:

  class ClassName(object):
    def some_method():
    def other_method():

  class Class2(ClassName):
    def more_methods():

New fad: build existing tools in Rust

Building existing tools in a language you are learning has been a thing forever. I would argue it's one of the best ways to learn a language in fact. The README also compares it to existing tools and explains why it's different from them.

That trend is usually limited to a TodoMVC level of effort. It's not usually about reinventing wheels (or worse). Except in the Rust case, where it almost always is.

That’s a lot of negativity just for someone experimenting with a unique programming language to see what it’s good and bad at. People see a new tool and try to figure out what it excels at and what it falls short at. Rust tends to be an “everything” language and people try to uncover new patterns and techniques.

“How much faster/leaner/more user friendly can I make X when I don’t have to care about safety, performance, or package management?”

They shipped their hobby project into Homebrew's core tap. 'brew install ox' belongs to them. They've put it out in the world for others to use and have also stated their case for why people should.

This is far above the level of scrutiny of just someone's experiments.

I have a hobby project that is a feature-complete scratch rewrite of Ruby's ActiveRecord, but I'd be kind of an arsehole if I named that something and uploaded it to rubygems.

I think that the author had the audacity to imply that his project is grater or equal to many people's favorite tools. Add this to the rewrite it in rust meme and people feel entitled to pummel the author to the ground. I call it the righteousness fallacy where the fact that the other side is wrong give oneself permission to be as ugly as it feels good because if the other is wrong, then one can't be anything but right.

I really only had issue with the fact that they decided their hobby project was ready to be shipped using mainstream package managers.

Most of the pummeling is me just defending this viewpoint after getting pummeled for my negativity.

Nothing should be immune from criticism, and something really can't be a "hobby project" and distributed with mainstream package management tools at the same time. You have to pick one. Names are finite.

If this was a "clone my github" only distribution, I'd have kept my mouth completely shut.

I actually didn't have anybody in mind when commenting but the general direction of the discussion. As far as I get your main issue is the name squatting which is okay. Good names are hard to get and this is something that all packet managers should take into account. However, please, don't be too harsh on someone who wants a nice name for their project.

I agree with you. It's so much engaging way to explore a language and try implementing those features we really wanted. Just saying building in Rust is the new fad. I only hope in these projects people take take a little more risk in trying out ideas.

I'd love for it to be true. Tools written in a programming language with modern tooling make customizing it a lot more accessible.

> Ox took the idea for the customization and extensibility of Emacs and made a configuration system where you can change the colours and appearance of the editor

Change the colours and appearance of the editor? Took the extensibility and customization of Emacs? Really?!?

> “There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Bjarne Stroustrup

I guess if we were to assume this is also true of text editors, Ox is well on its way to great success!

Installed from brew and tried to open an html file. 1. no syntax highlighting 2. formatting is off (tried with nano - formatting is great) 3. the cursor moving is not rendered, eventually got lost (bug)

I would like to have an editor like this but with native vim, emacs, nano, ... modes, so that the user can decide on how to use his blazingly fast terminal editor in an all-in one ecosystem.

So VSCode?

Found the Vim emulation of Vscode lacking in some areas, plus I'm pretty sure GP is taking about a text editor in the terminal

It is a bit lacking here and there indeed – my comment was tongue-in-cheek, really. I do find using VSCode with neovim to work better than vanilla vim

Let me introduce you to Onivim 2[1][2] I think it's a really promising project

1: onivim.io

2: youtube.com/watch?v=Pi8qRg_gseQ

Thank you. That looks really interesting indeed. In general, I'm strongly opposed to pre-ordering stuff, but I'll sleep on it and may give it a try.

> I do find using VSCode with neovim to work better than vanilla vim

Do neovim and VSCode integrate in some way? I've never used neovim so I'm curious how you're using these two together

Not OP but he is probably talking about this extension https://github.com/asvetliakov/vscode-neovim

This is probably a nice starting point for devs wanting to use Rust as a programming language for creating "classic" client applications (non-web).

I hate the "ctrl+S" to save IMO. On Mac ctrl+S is not used to save, cmd+S is. Don't assume what OS it's being run on.

I use Sublime Text, why should i use Ox?

Only for terminal fetish? Or because it is written in Rust?

That colorscheme looks cool though. Is it available for other text editors?

I wondering the same thing! I would like to know if a similar theme is available for VSCode.

I find it hard to move from vim because of its ubiquity. Same with bash.

Which languages are supported for syntax highlighting?

Can you create a deb package? I'll use it.

I love the focus on Arch Linux in the README

what is the advantage over micro?

why

I feel like in 2020, readme with screenshots don't cut it for me anymore . I need a youtube video of someone going through in couple minutes to get me interested.

I feel like you would miss on a lot of good things with an attitude like that. And will get persuaded by projects that spend time on PR.

Reply on news.ycombinator.com