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".
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
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.
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.
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.
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.
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.
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.
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 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?
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.
> 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.
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 :)
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.
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"
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):
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)
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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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 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 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.
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.)
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.
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 :)
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..
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.
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.
> 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.
> 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...
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!)
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.
> 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 ?
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.
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.
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.
As the boss of a company: micro managing your employees to the point where you dictate exactly how they work including their preferences for editing text is an excellent way to lose your best talents, who will likely be quirky and in some cases - possibly this case - know more about this than you do. And no, it is not 'like an electrician refusing to wear protective clothing', it is much more like an electrical engineer that knows when to use auto-routing and when to route things themselves.
Besides, I'd love to see you make your case to HR: "I want to fire this person because they don't edit their text like I do".
While I wouldn't want to fire someone for using bad/incomplete/incapable tooling, the Nth time someone doesn't follow the style guide (which is automated for everyone else, but not for this guy because his 1337 editor doesn't support it) or leaves bugs in that are caught automatically for everyone else because of editor support it's time to consider if his constant breaking of convention is an issue and he either needs to use more capable tooling or leave.
Less extreme than the previous poster, I'd actually like to provide JetBrains licenses for my teams and strongly suggest using them. The amount of help WebStorm, PyCharm, etc. give is honestly way too much to pass up and the kind of uniformity you can get from everyone using them is great, all out of the box.
I used to only use Vim and Emacs but there's no question they're much more incomplete tools for development. I don't see why one would pass up JetBrains IDEs considering they have a passable Vim mode and for the languages they have plugins and/or product lines for they're just better.
Yes, but that's different. You are judging people by their output, not by their tools, and that's just fine.
I've seen people produce absolute miracles using fairly archaic tools showing a very deep level of understanding of both the problem and the domain. Forcing them into some kind of straightjacket to use 'modern tools' would be the same as taking Itzhak Perlman's Soil Stradivarius away to force him to play on an electric violin just to get with the times.
For things like formatting/finding bugs, shouldn't those be command line tools anyway, so they can be built into your CI?
Even if not, there's no reason not to allow someone to edit text however they like, and then just load their changes into Intellij or whatever to double-check formatting and use its static analysis tools before raising a pull request.
> I don't see why one would pass up JetBrains IDEs considering they have a passable Vim mode and for the languages they have plugins and/or product lines for they're just better.
I use Intellij at work for Java stuff, and I could easily see why someone would want to use something less resource intensive (especially for less IDE-dependent languages than Java). I regularly run into issue where I get pauses while I type.
This may only apply to junior people. Take James Gosling's super dense style of coding and disregard for style guides. These ultimate geeks would just leave.
I completely understand the position of the person you replied to. One video outlining it is here: https://www.youtube.com/watch?v=Q3XuFr7rw84 . Many people disagree with it but I think thats because they don't imagine being productive without auto-completion.
> If I were a boss of a company and saw one of my employees do this, I would seriously reconsider their employment. Purposely limiting yourself has no place in development.
If I was a boss of a company I would try to judge people based on some objective measure, rather than subjective opinions about how one should be doing things.
I write in languages with and without IDE. With autocompletion, I'm more productive than without. Even in shell I prefer to use autocompletion or two panel file commander, because it lowers burden on my brain. I don't need to spend brain cycles on correctness of typed code. I know names, I type fast, but with Tab it even faster to type, and less error prone.
For example, when I started to use Rust, IDE was not available, so I used plain text editor for about 2 years. When I switched to halfbaked IDE, my productivity is raised because of autocompletion and error checking on the fly.
Right, not quantity in that sense, but as a fraction of the working product expected of you.
I have known a couple of people who fussed and fussed with little chunks of code until they were little gems, but always missed the big picture and missed deadlines. I have also known a few whose instinct was to write a framework first, and that takes a life of its own; the most egregious one was a CLOS (common lisp) style system using C macros. Debugging was a nightmare.
- Are they comfortable and productive in their own coding environment?
- Do they understand the code they are writing?
There are more things I look for, but those two touch upon this... if someone interviewed and were fluently moving around their coding environment and the quality was high and they understood what they were doing (complexity, allocs, maintainability, readability, approach to the problem, etc)... then they'd be hired.
Further, their future perf reviews would never care about this stuff. Or if it did, it's only to say that this is part of the health and wellbeing of the individual who has chosen a work environment in which they are happy and productive - which is a net positive to the company.
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.)
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/ )
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.
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.
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
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.
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.)
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
> 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
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.
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.
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.
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...
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.)
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.
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.
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!”
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.
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.
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.
> 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?
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.
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.
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.
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 !
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.
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.
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.
> [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.
> 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.
"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."
> 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.
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.
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.
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.
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.
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.
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.
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?
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'
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:
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."
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():
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.
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.
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?”
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.
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.
> 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?!?
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.
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.
