The demo is impressive for something running on a browser.

    > Planned Features
    >
    >    ...
    >    Multi-cursor support
    >    ...

I can't live without that though. SublimeText spoiled me, my editing flow is heavily based on multiple cursors.

Author here: I guess this is gonna be one of the most requested features. It will come sooner than later, but it's not a feature I use very often, that's probably the only reason it's not implemented yet.

I'll keep it on my watch list!

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.

More than just multi-cursor the workflows VSCode offers with them (selecting all occurrences, selecting the next occurrence) are vital for my work.

Aren't those workflows operated by LSP Rename action rather than multi cursor ? Since Ecode supports LSP, if you only need to rename things, you should be good without multi cursor.

LSP only applies to programming languages and specific configuration files, it's useless when you edit files such as JSON/YAML/etc.

indeed. LSP are for high latency, high impact, careful changes. multicursor edits (with sublime for me) are for those "replace all the str_something with string_something in the next 3 lines, quick"

Could you expand on your use case? Are you writing the same thing across multiple lines? I've only gotten tripped up on multiple cursors when I somehow activate them.

My main use cases:

- 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".

Author here: This is interesting to me. I usually solve all the multi-cursor usage with a range based search and replace (that it's supported in ecode by selecting the range and Ctr/Cmd + F to search and replace over that range). I would like to see how it's used by other users to have a better idea on how it should behave a multi-cursor feature. If you know how to record a video of you editing in the way you explained it would be awesome to see it. Thanks

I use for things that I could do with find and replace (often requiring regex) but I find it faster/easier to just use multiple cursors. With multiple cursors I can convert a PHP array to JSON or JS very easily or take a list of params and turn it in to an object. I do this often when creating client-side TypeScript interfaces for the data the server is going to spit back at me. Example:

* 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.

Awesome, it really helps me to visualize the usefulness of the feature. Thanks for taking the time to explain it.

Oh, I completely forgot about copying and pasting multiple cursors. I'm a hardcore user of that as well.

Sure can do!

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.

Thank you very much! Indeed it looks really useful. I hope I can implement it soon.

This is also how I go about it in Doom Emacs. I guess either way solves the same problem, just differently.

I cant speak for the commenter you replied to, but I find it great to transform data without any tooling.

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.

Also not author of original comment, but I use it for “stupid data transforms” all the time. Like formatting some stuff for a spreadsheet. I find it faster than writing a script most of the time

This looks great. It's nearly impossible for me to leave Neovim at this point, but I do miss a good git-aware minimap, and I miss the VS Code git diff / integration.

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.

Though not a minimap, I use gitsigns plugin for neovim that shows changed lines in the gutter. I wouldn't be surprised if there's even minimap plugin somewhere.

Here it is (haven’t used it but looks that part):

https://github.com/wfxr/minimap.vim

Author here: Git integration plugins will come later, but it's planned. I hope the project gets enough visibility to get some collaborators :)

For anyone confused why there’s no source:

> 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

I am happy to see one more open source GUI text editor that aims to be fast, minimalist, yet has some essential features (at least for me) like LSP support, minimap, and terminal support. I hope this editor will have a good plugin manager in the future.

I'm using Sublime and as Druid fan I'm following Lapce but this one looks good too.

> as Druid fan I'm following Lapce

Doesn't Lapce use a custom wgpu renderer, and not Druid? Or did that change at some point?

From the Lapce's README [1]:

> Lapce is written in pure Rust with a UI in Druid

[1] https://github.com/lapce/lapce

We use fork of Druid that uses OpenGL. It was wgpu before instead of OpenGL but there were issues and limitations with it.

I think it has own fork of Druid but there may be plan to use Xilem.

yes, we plan to switch to Xilem when it's ready for us

Same. Lapce is the hottest new editor and might be the only one to get me to switch away from sublime.

This is a little off topic but related because I keep looking at these source code editor posts. I have always been looking for a little "sidekick" editor that is always in the background that you can invoke with a ctrl-<char> and it at least maintains just a single local data store. (It's not a general purpose text editor like Sublime.) Sort of like the old Notational Velocity but able to be invoked very quickly anytime. The file could just be synced across computers using Dropbox or similar but it would be nice if it also allowed simultaneous editing of the file.

As a primary sublime user for the last decade, this is the only alternative I've tried so far with promise.

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!!

The editor looks fabulous, great job! although I am actually very excited and impressed with the eepp GUI framework.. it's pretty sick! I wish we had more like this in rust..

Would love to see one of these that used Miller Columns for navigation, and supported VSCode task and launch files.

What code editor does support Miller columns?

The environment I grew up in (NeXTstep with Miller Column FileBrowser + Edit + InterfaceBuilder) effectively did, but I'd love to see them tightly integrated.

Thanks for sharing. I'm going to give it a try.

was ed not light enough? it is the standard editor.

> designed for modern hardware with a focus on responsiveness and performance

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.

Performance in text editors used for programming is important. If there's a delay between pressing a key and something happening, it's a worthwhile goal optimizing for that. Consider how many things can happen in modern editors with a single key stroke: changing large blocks of text, executing a macro, rendering syntax highlighting, communicating with an LSP server, rendering code completion, executing plugins, etc. All those things should happen in as few milliseconds as possible for the experience to be considered "responsive".

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.

Most people use neither Emacs, nor Vim [citation needed, but I’d bet some money on it]. And for me, performance is most certainly a selling point.

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/

I've seen voting results on one of niche Linux sites, and was surprised that majority of users use vim/neovim or vim bindings in other editors/IDEs.

But I'm pretty sure that most Windows users wouldn't use any editor resembling vim.

Visiting niche Linux sites often enough to take part in such a poll is probably introducing a very strong selection bias here.

> Point being, performance is a weak selling point to switch text editors

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.

Text rendering is very expensive. That's why you need hardware acceleration.

It's amazing then how much writing of both code and prose I and many others did on machines that were much less capable than today's. I wrote considerable amounts of code on the Z80 Apple II add on in the early '80s and never felt that the editor was too slow. My wife wrote a novel on our Osborne 1 (CP/M, Z80, 5 1.4 inch floppies) in Wordstar. Speed was never a problem for editing.

> It's amazing then how much writing of both code and prose I and many others did on machines that were much less capable than today's.

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.

Are you really trying to say that 100 times the pixels (and a lot less in a window that isn't full screen) cancels out 10,000-20,000 times the CPU power (per core)?

CPU speed isn't the limit, memory speed is. Apple II's 1MHz to DDR4's 1600MHz is 1600x increase, so more modest than CPU gains.

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/

You are conflating a lot of different things here and some of your math is off.

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.

Bitmap rendering is incredibly fast. Old computers were so slow it was the only viable method.

So new computers are slow because it is no longer the only method? Do they spend a lot of time on each frame dithering over how to do it?

If it's so expensive, why were computers a 10,000 times less powerful able to do it well?

They only supported the ASCII characters and a few sizes/colors that was pre-rendered.

My 486 was able to do arbitrary text rendering without any problem. Text rendering is not expensive by any standard today. The only reason any text editor is slow is exceptionally poor programming or bad multi-threading (which is a little more forgivable).

Yeah -- while not mainstream compared to VSCode -- it'll take something very big and impactful to move me away from neovim + alacritty. It works amazingly well.

What is neovim + alacritty

neovim is a fork of vim. https://neovim.io/

alacritty is a terminal application. https://github.com/alacritty/alacritty

What blooper said.

I use alacritty as a gpu-accelerated terminal and neovim plus the LSP stuff from VSCode

I'm on Kitty + Lunarvim. Nice and fast / responsive.

I have apparently completely lost touch with what people mean by 'minimalist' these days. Can someone help me understand why that word is applied here?

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...

I think in 2023 "minimalist" just means "not written in something like Electron"!

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.

And thank goodness for that. Electron is the scourge of modern software and causes global warming.

I think it has some fierce competition there - in fact I might even argue that modern software itself is the scourge!

presumably they meant visually minimal (not that i would agree...). It is indeed minimal compared to say, intellij IDEA, or even VSCode.

Author here: Yes, that's what I meant. I agree it's not the most appropriate adjetive to describe the editor. But one of my intentions is to keep the UI as clean as possible (I'm not a fan of cluttered editors with several panels on screen all the time).

Considering IntelliJ has different setups, you'd have to compare the zen or distraction mode of IntelliJ with the minimalist setup here, which seems to be more cluttered than what JetBrains is offering.

Author here: You can hide everything in the editor (minimap, line number info, side panel, etc). I guess could add a Zen mode that hides everything at once for simplicity. The editor will remember your view settings, so it's very doable to have a zen mode by default.

In modern days it's kinda shocking when you see a new UI app that was built without using the HTML+JS+Electron bullshit. Big respect for that!

Always happy to see new source code editors.

> 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.

Author here: Thanks for the suggestion! I forgot to change it in the repository description! It's already fixed.

> 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).

So the extendable functionality is enabled with C++? If it were emacs lisp I would be right there already. :)

Author here: That's correct. It's partially intentional, since I want to keep some control over the plugins ecosystem. I think it's explained somewhere in the README file: Extendable functionality but in a controlled environment. New features and new plugins are accepted, but the author will supervise any new content that might affect the product quality and performance.

So there's currently no mechanism by which I can extend Ecode without your involvement?

That depends on what you want to extend. You can expand the capabilities of the LSP, linter, and formatter by adding new configurations. You can also create new color themes for the editor and the terminal. You can also customize the UI (it won't be that easy, but you can). But, if you want to create a new plugin... since it's native code you'll need to at least fork the repository and create the plugin on your own repository. I don't plan to be a dictator, just a supervisor. And of course, I'm more than open to getting new collaborators (this is the main reason I'm publishing it), that would be great. I just want to ensure that my application branch is "safe" (no malicious code, no horrendous implementations, etc).

Author here: No, you're incorrect. It's a general purpose code editor. What you are describing is the underlying technology used to create the editor. eepp (the library) currently is more like a Qt alternative (not at the same level, much work needs to be done yet), it's not used as a game engine (but it can be used), I simply changed my focus over time.

What about the graphics module? It seems there are features that aren't needed for other than game development? Btw, it's still a pretty nice editor :)

Thanks for the compliment! The graphics module is the core of the application (the UI consumes the Graphics module for all the rendering). There are two modules that aren't currently being used in ecode: physics and audio. I'll keep the audio module for the moment (it's very tiny and doesn't add new dependencies, and I'll probably use it for optional notifications). The physics module it will be probably moved apart as a complementary module as I did already with the "Maps" module for this release.

I understand. Love it.

The most important point is expandability. Did it has an API or is it planned to add an API to extend the editor?

Author here: The editor can be expanded via plugins and several features are presented as plugins (LSP, linter, formatter and auto-complete). But the plugins API it's not as friendly as other editors since I want to keep some control over the plugins. I think we already have many editors very expandable but also with very little to no control over the plugins/extensions environment, and that ends up creating a big mess for the final product (inconsistent UI, bad implementations, etc). Currently the plugins can only be implemented with C++ native code and new plugins will need to be merged into the project. I would like to keep control over the new features and supervise that the implementations are correctly done (mainly I care about plugins not locking the UI thread). I understand this can be bad for some but I want to keep a certain vision that needs some kind of control over the end product.

A third of the linked github readme is about how to do plugins.

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 have to strain to read the text because it's so small and I have no recourse against that problem. Stop "skinning" software, it is literally easier to do nothing and then the software will automatically do the correct thing and follow the rules.

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.

Author here: Besides the fact that you were very rude with your comment I'll give you my point of view.

> 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.

Just jumping in to say that you sound like an amazing maintainer and a really great person, for responding so constructively to something so toxic. Building one's own UI engine is not for the faint of heart, and the amount of features and cross-platform compatibility you've built is quite a feat! I'll be following the project, and don't let comments like this one get you down.

Thank you for the support! I really appreciate it!

You made a very nice editor, dismiss that clown. You are clearly also a great person. Do you have a channel for us to provide feedback or interact with the community? like a Matrix server, or should we just open issues in your repo?.

Thank you for your kind words! Almost no one knew the project until some hours ago so there was no community to communicate with, there's nothing available for the moment. I would love to have a place to chat if people is interested in the project. As for now, just open new issues, we can use that for feature requests, ideas, and of course bug reports.

There's no need to be that dismissive and rude.