Show HN: Ecode – A minimalist and fast open-source code editor (github.com)
Hi HN! I've been working on a code editor and I think that it's mature enough to catch some interest. It's using a custom GPU accelerated GUI written in C++. Currently implements some interesting features: LSP, terminal, auto-completion, linters, formatters, custom keybindings, plugins and more. It's a hobby project but still intends to be an alternative to other popular code editors like Sublime, Kate, Lapce, Lite XL (and takes inspiration from them).
The project was born as a playground for the GUI I'm developing (eepp GUI) and is advanced enough to currently be my main code editor, but it's a work in progress, and many features are still pending. Some minor hints on how to use it:
Folders are used as project (and .gitignore is used to ignore files)
The wheel icon on the top-right has all the options you need (Ctrl/Cmd + M to show).
Some keybidings to navigate any project (navigation is keyboard driven):
Ctrl/Cmd + K = Locate Files
Ctrl/Cmd + Shift + F = Global Search
Ctrl/Cmd + Number (Go to tab #)
99 comments
[ 5.9 ms ] story [ 173 ms ] thread> Currently, the source code is located at the eepp project repository. […] At some point, it will be migrated to this repository.
-- https://github.com/SpartanJ/ecode#source-code
Not sure why a text editor needs modern hardware to be performant. I’m working on a text editor myself, and aspire to vim on the performance front as it is fast as one would reasonably want. If anything, my physical body is the bottleneck. There are edge cases such as really large files (100+ million lines) or ones having super long lines that makes certain data structures choke, but vim can do random access on 180m line files just fine on my M1.
Point being, performance is a weak selling point to switch text editors, and I question whether it should even be predicated on “modern” hardware ( GPU accelerated rendering ? ). The selling point has to be something else. This is why the editor wars is a dichotomy between Emacs and Vim. Emacs strives for many things, but speed isn’t one of them, and that’s perfectly okay. The main selling point of my editor, built for myself, is native support for Org-like files without the rabbithole of Emacs.
The main reason I use my windows text editor (EmEditor [0]) despite having no formatting and only barebones syntax highlighting, is that it’s faster than any other editor I’ve ever seen (though I think the large file handler tops out at 256 GB). Well, that and its superior CSV handling, though Notepad++ comes close with plugins ;)
[0]: https://www.emeditor.com/
But I'm pretty sure that most Windows users wouldn't use any editor resembling vim.
alacritty is a terminal application. https://github.com/alacritty/alacritty
I use alacritty as a gpu-accelerated terminal and neovim plus the LSP stuff from VSCode
Sure, on machines with low resolution screens with simple fonts and no anti-aliasing. I'm not saying accelerated graphics are necessary for text editors today, just that the context has changed considerably so the comparison isn't obviously fair.
Apple II's display was 280x192 with 6 colours in high res mode, which is ~107kB of raw pixel data (Apple II didn't store this all in RAM). An RGBa display at 1080p is least 105MB of raw pixel data. That accounts for the 1000x difference right there. Add a few extra features like anti-aliasing, more sophisticated layout management, syntax highlighting, etc. and it all seems to track.
Finally, there are other sources of perceptible differences in UI/UX due to the growing depth of the software stack:
https://danluu.com/input-lag/
First, 1920x1080 pixels times 3 bytes for RGB is about 6.2 MB. I'm not sure where you got an alpha channel from. Also an entire screen of pixels isn't being copied from memory to refresh a text buffer.
Second the Z80 couldn't transfer a byte every cycle so that's 500KB/s.
Third, DDR4 doesn't have a bandwidth of 1.6 GB/s, which would be absurd. We can call that about 20 GB/s - https://www.transcend-info.com/Support/FAQ-292
The comparison for memory pixel data is 6.2 million / 107,000, which is 58. The comparison for memory bandwidth is 500KB to 20 GB/s, which would be 40,000.
Add a few extra features like anti-aliasing, more sophisticated layout management, syntax highlighting, etc. and it all seems to track.
These don't have anything to do with memory bandwidth and are back to CPUs.
Finally, there are other sources of perceptible differences in UI/UX due to the growing depth of the software stack:
This doesn't have anything to do with anything in this thread. The original person said text rendering was expensive, that has nothing to do with input latency.
I use Emacs on a daily basis, and even with the recent native compilation change and relatively few packages, some common actions feel noticeably slower than in Vim or other editors. Is this a dealbreaker? No, I made a conscious decision to get the flexibility of Emacs at the expense of performance, but I would jump at the opportunity to use something with the same featureset that _does_ prioritize performance. It's not about how productive it would make me, but how enjoyable the experience of using it would be.
You’ve never worked with IntelliJ I see. If someone builds the exact same thing but any amount faster I’ll switch in a heartbeat.
I’m using Zed more and more, even though it has barely any of the features I use, purely because it’s so fast.
Doesn't Lapce use a custom wgpu renderer, and not Druid? Or did that change at some point?
> Lapce is written in pure Rust with a UI in Druid
[1] https://github.com/lapce/lapce
Looking over the feature list and the ReadMe, this editor seems really attractive and checks most of my boxes for a good main editor, but I hit that word and cannot figure out what I'm missing here...
While this certainly doesn't match my idea of minimalist either, it does look interesting - I'm always enthusiastic about projects that target systems beyond Windows and Linux - and this one can run on Haiku.
I'd love to find an editor that has those features while being as light and snappy as Neovim with the same ability to split, navigate, and do all the things without leaving the keyboard.
https://github.com/wfxr/minimap.vim
It already marks several of my editor checkboxes (LSP support, fast global search/replace, real time tree view, etc). I'll say it again, it looks very impressive.
As an example, if I have some tabular data, I can quickly turn it into JSON. Find-replace can also add a cursor to each result which is very helpful. Many other code/data transformation tasks are also made trivial with multiple cursors.
- Replacing variable and function names: I have Ctrl+D bound to "Mark Next Occurrence", which creates a multiple cursor and replicates the selection I have on my main cursor to the next following similar thing. Instead of changing a name and then search/replace it afterwards, I selectively mark the next occurrences within the scope I'm in and change them all at once.
- Editing multiple similar expressions: If I want to add a new parameter to a function, I can multi-select `existingParam,` (including the comma) and add the new parameter to multiple occurrences within a scope.
- Ctrl-based multi navigation: I use Ctrl + Arrow Keys to skip words a lot. In combination with multiple cursors, it allows each cursor to skip words individually. This is useful for the previous use case (editing parameters) when each parameter might have a different name (and therefore a different length).
- Several alignment and formatting things: This is hard to explain in text. I use it to align the ` = ` sign in repeated variable assignments, to manage indentation, etc.
I can do most of these things using other tools if needed (I did before multiple cursors). The parameter editing is often a vi "showcase" scenario, which I consider to be much more effective using mc than repeating actions or macros.
I don't place cursors with a mouse, I don't add cursors below or above or any other feature. Just "select the next occurrence" or "select all occurrences".
* I just select `public` on my first PHP class property
* Use multiple cursors to select all `public`'s that are before the properties I want (Normally by adding 1 selection at a time since I only want the props, not the public methods)
* Arrow over right 3 times (Now my cursor is right before the property names, after the `$`, this is PHP remember)
* Hold shift + control
* Arrow once more to the right (now the variable names are selected)
* Hit Cmd+c (copy all variable names)
* Open new IMyInterfaceDTO.ts file
* Type `export interface IMyInterfaceDTO { <cursor is here now> }`
* Paste in all my variables between the `{}`
* Select the new-line between each variable (I want a cursor before each variable name)
* Then add in `: string;` after each variable (string is the most common, I then manually change it to number/boolean/etc on the props that need it)
Done, now I have a TypeScript interface that matches my php class that gets turned into JSON.
Here is an example of what I'm talking about: https://cs.joshstrange.com/jlH4BnT3
Yes, I could accomplish the same thing with find and replace using a regex but this lets me see each step of the transformation and react easier. Maybe if I was a regex pro I'd feel differently but this method works really well for me and how my brain works. I know it's a lot of steps but I do it reflexively almost on autopilot verses having to stop and think about a regex.
Here it is: https://streamable.com/vwj0hs
I did three things there:
1. Replace the prefix of several variables from `$mock` to `$stub`
2. Added a prefix to all properties of the object `$r`, which left the camelCasing missing an uppercase letter, I selected that letter on all properties and used "Transform To Uppercase" action on VSCode to camelCase it properly back again.
3. Aligned some keys of two arrays. I selected them, placed some minimal spacing, then hit `Home` to align the cursors to indentation, then used `Ctrl+Delete` to trim the added spaces.
I'll try the range based search, I never used something like that and might like it.
> Lightweight multi-platform C++ code editor designed for modern hardware
Maybe change this description. At first blush, I thought this was a "C++ code editor" rather than an "editor written in C++".
My favourite languages, Java and SQL, are not in the supported languages list but hopefully support can be added with LSP.
> My favourite languages, Java and SQL, are not in the supported languages list but hopefully support can be added with LSP.
For the moment I only implemented syntax highlighting for the languages. Adding linter and LSP support is trivial. May be you can collaborate by adding it (it's just a configuration, take a look at the plugins section).
When I paste in text, it only shows squares, afaict only a few scripts like Latin or Cyrillic work. The input method editor does not work correctly, I can't see what I'm typing.
Unusable, into the rubbish bin it goes.
> I have carefully set up my desktop environment the way I like it, specifically the way menus are displayed, colours, fonts, icons, keyboard shortcuts, notifications. Ecode does not even make a single attempt to adhere which was not acceptable when Winamp came out and certainly not acceptable in 2023.
I understand what you want, but it's not an easy task I it's not something I care anymore. It's technically possible to create a theme that looks almost exactly like anyone's desktop but I don't think it is worth it. eepp, the underlying technology behind ecode is more like HTML+CSS. All the styling is done via CSS and the layouting with XML, and it's more similar to the web technology than native desktop widgets (such thing stopped to be a thing in every OS except macOS).
> Stop "skinning" software, it is literally easier to do nothing and then the software will automatically do the correct thing and follow the rules.
Then you don't understand the problem.
> When I paste in text, it only shows squares, afaict only a few scripts like Latin or Cyrillic work.
The README file clarifies this. For the moment I don't support wide-characters (Chinese, Japanese, Korean, etc) and the editor only supports UTF-8. I'll add support for it at some point. Wide-characters are only supported in the terminal for the moment.
> The input method editor does not work correctly, I can't see what I'm typing.
I guess you're referring to IME support. It's still pending.
> Unusable, into the rubbish bin it goes.
I have no problem with critics, but this is not the way to have a conversation about an open-source application. At least take the time to read the README and understand that this is work in progress. Such comments like yours are a waste of time.
Runs smooth as silk, this is an editor for speed demons like me. A lot of essential features already in there.
Would love to see drag-drop of files/folders in the directory panel- bonus points if you can drag between instances of ecode.
Love the very slim UI. Effective use of screen real estate!!