UIs and actual functionality are completely separate implementations. Loading and displaying text are entirely decoupled, so the display doesn't have to care if the actual file is 10kb or 2gb in size.
Also I think that the marshalling you need for IPC is not so different than the boxing and conversion that you have under the hood if you write in an interpreted language, e.g. Python or JavaScript.
I changed my mind over two electron editors/IDE. I use RStudio and it is really been getting so fast on my old computer that I can't tell anymore. VS Code by Microsoft is so fast and nimble that I have been using it 75% of the time with no felt overhead. It really is an amazing piece of software in terms of speed, now the ram usage is still much higher but for my uses I don't notice it at all on my 8 year old Dell corporate computer.
It's not an either/or problem though.
You actually see this in many IDEs that more features make editing feel more sluggish. This shouldn't happen with this structure.
Both can (and have) been achieved without a client server architecture.
You can also do it async style and have neither of the drawbacks - if the user types too quickly, the autocomp just doesn't show up.
Or are you talking out of your ass?
From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths.
Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here:
https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
If the performance hit is not noticeable, nobody really cares about the waste of CPU cycles. Especially since a text editor uses something like 1/10 the resources a large, complex program uses anyway.
Some IDEs go as far as to offer low power modes where they throttle external plugins.
I'm hoping to find the time to get more comfortable with Rust and try to contribute at some point
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/
It is written in D, a fast (close to C++) language, easy to write code in, runs in a terminal, runs graphically, runs on many systems (I don't know every possible system but I doubt in runs in a Commodore 64), it is open source and I have no idea about it being extensible or not.
It's however the closest thing I have seen to your list of requirements.
https://github.com/vim/vim/blob/master/runtime/doc/version8....
If you don't mind the lack of extensions, and are willing to write your own, you may wish to try some of the other emacsen associated with the lisps. Hemlock is CL-based, so likely faster than Emacs, and Edwin and Guile-Emacs are both based on Schemes (edwin is MIT Scheme, Guile Emacs is... Guile). They still suck at some stuff, though, and they don't have the massive plugin ecosystem.
+ runs graphically
+ runs linux, macos, windows (nothing else?)
+ open source
+ ridiculously, easily extensible
+ not riddled with bugs (slowness is not a bug)
+ for small files, comparably quick to Sublime on my machine
+ major dev community; already much better than 6 months ago
- slow in some instances, esp. large files
- doesn't run in terminal
- doesn't run in less-popular OSes
+/- moderate RAM usage, decreasing
I came to Atom from Sublime because the plugin ecosystem was growing much faster and the community felt more active. I haven't looked back since.
And no, Atom not designed to open 30Mb files. Complaining about this is akin to stomping on a land mine and complaining that your Timberland boots didn't save your foot. Just use Atom for its intended purpose: editing source files written by reasonably reasonable people.
head -10 myfile.json
And that's exactly one of it's problems. It's not designed to be a damn text editor. Instead - it's just another "hipster editor". You can find a growing number of useless plugins, but can't open log file sent to you, or connect via proxy without a trouble.
Not to mention the speed and ram usage. My IDEA instance with a large project opened up use less memory than Atom without any files opened (but with a bunch of plugins loaded).
Sorry for the emotional replay, but I just do not understand how people can go from Sublime, which is, in my opinion, almost ideal text editor, to something like this js crap.
since when do you need to edit log files? you don't need an editor for that, you need a log explorer. there are other tools for hat.
what exactly do you mean with proxy problems? i'm behind a proxy at work and didn't have any problems?
> Not to mention the speed and ram usage
that thats its only real problem. especially if you're on a laptop without a power outlet nearby. i tend to just use vim in that situation notice a significant increase in battery life.
> I just do not understand how people can go from Sublime [...] to something like this js crap.
at least its fully extensible. i love the linting, auto-beautification, Markdown Preview, extensible autocompletion, useful autosave, Git-WIP support, extensive git integration and so much more.
its just not meant to be used as anything beside editing small code files. and most people don't have to code monolithic code files beyond a few MB in size.
Any time I want to re-hydrate escaped control sequences like newlines, or explore the log using a host of tools available in a text editor.
> at least its fully extensible
As are most text editors and IDEs. Atom's only difference here is that the extensions must be written in Javascript. Not everyone sees this as a good thing.
> its just not meant to be used as anything beside editing small code files
And that's the problem. Why should a user be forced ahead of time to consider their usecase for editing a file just to choose which gimped file editor they want to use?
No, it's more like having a car that doesn't get to 70mph.
It's useless on the Interstate, and it's also not that good on regular city traffic, because the same limitations that make it unable to reach 70mph also make it clunky at 10mph.
As to why I'm opening such large files: It's not like I chose to do so, but sometimes I have to. It's great to be able to (in Sublime) `<Ctrl+P> log <Ctrl+F> blah` and see immediately what I'm looking for without switching to another tool. I even have a simple syntax highlighting definition for my log file that makes it really nice.
I'd really like to like Atom, but the fundamental problem is that it tries to emulate a text editor widget in a web browser. That works, but creates a certain amount of latency that I can't work with. It's really irritating.
Let me know when they start advertising atom as a source code editor instead of a text editor.
It takes all of 200ms and a wee bit of inference to figure out that their usage of "text editor" is different from yours.
From the tone of some of these posts, you'd think downloading Atom and subsequently realizing it doesn't suit one's needs caused lasting psychological harm.
Semantics aside, Atom is good at what it does. For 99% of projects it's an excellent, flexible tool.
Well, this is simply a bullshit, sorry. This is might be a point of view of someone who never worked on an enterprise project or something of a similar scale.
Atom is good at one thing - opening small js\ruby\python scripts and showing you them in a modern UI. That's it. Anything more than that - he just can't do it.
No lasting harm, but I did invest quite a bit of time to discover that it doesn't suite my needs.
> It takes all of 200ms and a wee bit of inference to figure out that their usage of "text editor" is different from yours.
No it doesn't, it takes experience with the editor. 200ms of googling shows there are some log and tail plugins, which would lead me ot believe it was good at handling large files.
i mean we're talking about opening a file that is 1% of typical system memory.
tail -f *Going through log files and developing software are related, but distinct enterprises. It's no wonder the tools for one are sometimes suboptimal for the other.
Atom is about nice aesthetics, github integration and a plugin ecosystem. It's not trying to solve the problem of reading through massive log files.
Same goes for Sublime. And arguably - Sublime has much better plugin ecosystem. With easier discovery and installation.
Woah. woah. woah. Back the truck up.
Slowness is most definitely a bug.
In that case I'll assume it's a feature :)
Do you mean major as in "large", or as in "possessing some positive quality"? While I'm not commenting on Atom's dev community in particular, the two don't have a causative relationship.
A particular downside I see with Atom is it's performance - the perception of which is in some cases arguably approaching that of its competitors - and hence its energy impact, which affects my battery life.
I mean, I love Emacs and use it daily. But it certainly has plenty of bugs; but what reasonably complicated piece of software doesn't?
Having said that, the very core text editing engine, i.e., the part that's written in C and the basic Elisp editing functions around that are still rock solid as always, and for me this is still the ultimate model of what a text processing engine should be. It handles large files beautifully (and errors gracefully when it cannot), does file locking well, goes to great lengths to ensure the integrity of your file, all of that basic core stuff is just superb and well thought out, by a lot of brilliant people over a long time, and that's all very well optimized. I think the problem is that too many third-party extensions are included with the core release.
Before that there were years during which there was no way to configure Emacs that I was able to find to refrain from asking the user what coding system he wants to use every time a buffer containing a non-ascii character is saved. Not strictly a bug since maybe there are users who do not mind regularly getting into the same dialog with their text editor, but certainly, so many occurrences of the same monotonous dialog is unusual behavior in a user-facing application in this decade and very tedious at least to this particular user.
One reason Emacs is difficult to debug is because of the widespread use of global variables.
That said, I haven't found anything worth leaving Emacs for. (If I were a web dev, maybe I would've left it for vscode by now, but I don't like how text looks in vscode: I prefer the native OS X text rendering used by almost all text editors except the Electron-based ones.)
Exactly. Every so often I try to make a half-hearted effort to move to a more moderen editor, or even an IDE, but for all its flaws even nothing comes close to Emacs. Vim is pretty good, but tries to do too many things it's not supposed to; for vi-style editors I prefer Nvi.
Hey, I can dream.
On the other hand, I can't really think about a system that fulfills those conditions. But I wouldn't call anything "ultimate" if it doesn't :)
Compare it with emacs in which I have far more plugins and it still starts fast as a clean install.
Anyway not a big problem eh. For me vimscript is the shitty part of vim.
Price of admission: run in a terminal, run graphically, run on every possible system, be open source, be ridiculously, easily extensible.
What a successor might add:
Not be riddled with bugs.
Not be ridiculously, terribly bad at actually displaying text (quickly, smoothly, large amounts).
Not be extended in a language that's so slow that most "intelligent" modes end up being piles of half-correct regex hacks.
Not not care about correctness, in general.
Hop to it, dear idealistic genius whiz-kid reader!
Or fund me, overly-$-laden startup lottery winner. I'll take a crack at it.