SpartanJ

Shameless plug: For anyone interested in new code editors, I'm working on a multi-platform one called ecode [1]. It's similar in spirit to Notepad++ and Textadept, and some of the newer ones like Zed. It tries to be a fresh take using modern tools like LSP and DAP. I started it after using Geany for many years but finding it lacking some essential features for my needs. Speed is a big focus and it has very fast startup time.

[1] https://github.com/SpartanJ/ecode/

It's in the main project repo, since ecode it's part of a much bigger project: https://github.com/SpartanJ/eepp/

Here's the explanation: https://github.com/SpartanJ/ecode/?tab=readme-ov-file#source...

Why? Genuine curiosity, what's the angle for a market for sublime/zed alternatives? What are they lacking?

In my opinion, Sublime’s biggest gap is that it’s not open-source, and there aren’t many (if any) open-source alternatives that match its feature set, performance, and unique user experience, Sublime just feels especially nice. Zed comes closest, and I think it’s fantastic, but it’s VC-backed, so their focus on profitability will likely shape the user experience over time (as some users are already noticing). Every editor has its pros and cons, and preferences vary, but there’s always room for innovation. Even subtle differences can add up to a significantly better user experience. With ecode, I’m aiming to deliver a polished, enjoyable experience while subtly innovating on common editor features. That said, ecode is opinionated in some ways, so it won’t suit everyone, though it’s highly customizable and configurable.

And congrats on your project, looks interesting.

Thanks! =)

I think there's still space in the editor market for an open-source Sublime/Zed alternative. I've been working solo on a code editor with similar characteristics for a few years. It's still a work in progress, but it's already feature-rich (all the basics and some advanced features, like LSP, DAP, multi-cursor, etc.): https://github.com/SpartanJ/ecode/

ecode can handle big files, though it's not specifically designed for that. I just tested it with the largest text file I could find (760MB), and it worked just fine (searches included). The editor is designed with performance in mind, taking a similar approach to Zed (custom GPU-accelerated renderer, fully native C++ code, heavily multi-threaded, etc.). The biggest challenge is forming a community of collaborators, solo developing such a project in my free time is a huge task. So if anyone is interested, please contact me =)

I'm working on a multi-platform code editor similar to notepad++ and some new editors like Zed, called ecode, that tries to be a fresh take on code editors using some modern tools and technologies like LSPs. I started working on it after using Geany (which was the closest alternative to notepad++ in Linux) for many years but finding Geany lacking some essential features for my needs. ecode is developed with speed in mind and has a very fast startup time. It might be a good fit for your search.

[1] https://github.com/SpartanJ/ecode/

Thanks! Currently it does not but it's not something particularly complex to implement so I can add it if there's interest! I haven't used NP++ in some time so I don't remember exactly how it behaves but I'll take a look.

Shameless plug: I'm working on a multi-platform code editor similar to NP++ and some new editors like Zed called ecode, that tries to be a fresh take on code editors using some modern tools and technologies like LSPs. I started working on it after using Geany for many years but finding Geany lacking some essential features for my needs. ecode is developed with speed in mind and has a very fast startup time.

[1] https://github.com/SpartanJ/ecode/

It's also important to mention that given that the projected inflation for 2024 is above 200% and historically this taxes are not properly annually updated, the most probable scenario is that in a year or a few months most people that were benefited are going to pay income taxes again. So this are just populist measures to get some votes for the incoming elections (also mostly forced by the liberal party that is leading the polls), but won't last much.

I'm working on an code editor with a similar philosophy (or at least I'm trying to achieve similar goals) but it's completely open-source (MIT licence). It's called ecode and can be found here: https://github.com/SpartanJ/ecode . It's also GPU accelerated, native code (no electron), has LSP integration and has many similar feature set.

I'm looking for collaborators, if someone is interested please message me.

This is an ongoing trend that will continue until some of the new GUI-backed UIs gain some popularity. What we need right now is a real alternative to Electron based applications, and probably carrying new technologies. I know that we already have alternatives, like Qt, which is an amazing framework, but it doesn't fit all developer's needs and sometimes looks also "too big". I think that many devs are saturated of the HTML+CSS+JS ecosystem and want something new, maybe something less bloated in the sense of the tech specs. I celebrate the numerous projects that are appearing these days, to name a few: egui, iced, imgui, GuiLite, RmlUI, elements. They need more exposure, more collaborators, and more development, they need to grow.

Having said that, I'm working on an alternative GPU accelerated and retained-mode GUI called eepp (https://github.com/SpartanJ/eepp/) while I work on a new code editor similar to Zed called ecode (https://github.com/SpartanJ/ecode). The framework still needs a lot of work but presents some ideas that might be interesting to some. Retained-mode GUIs are a complex beast and it's hard to achieve simplicity (I think immediate-mode GUIs can't be beaten in that regard, but they have their own downsides). So I invite anyone interested in GPU accelerated GUIs to take a look at my projects (online demos are available), I'm looking for collaborators! (sadly C++ isn't very appealing these days, but my code-base is huge and I can't write everything from scratch in a new fancy and cool language).

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.

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

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.

Thank you for the support! I really appreciate it!

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.

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.

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

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

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

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

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.

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.

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.

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.

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

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

I'll consider it, thanks for sharing.

I didn't know that Hg already works with Python 3, that's great! The problem is that most distributions still will distribute the Python 2.7 version, I guess it makes sense until TortoiseHG catches up with Mercurial. I hope this happens soon, but I think that I'm going to switch to Git for the convenience of using GitHub over the other solutions (for open source projects the visibility is a good plus, for private projects I think GitLab is on par on features).

I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks.

3 weeks for me is a lot of time, that's at least 3 weeks I can't use TortoiseHg, something I use on a daily basis. Anyway, since this happened several times now I manually update hg and thg to avoid this problem (but it's a PITA). I know this is a problem with the distributor and not from the Hg or Thg devs, but still it's a common problem that could be coordinated between the two projects. I actually started using Mercurial because Thg was way better than the Git GUI tools at the moment, and I think this still applies.

In conclusion, a hope the best for the Mercurial project but I'm afraid this will have a negative impact in the long term.

I've been using Bitbucket with Mercurial repositories since 2011, both for private and public repos. I can count more than 50 mercurial repos that I'll need to manually move somewhere else. I'm really disappointed right now. I can understand their motives but they need to provide a single click method to at least convert a repo to git (this is a MUST IMHO).

I love mercurial but also can see that the community is shrinking, mercurial still relies on Python 2.7, and we are approaching to the EOL of Python 2.7. TortoiseHG also suffers from this, and the release cycle is always out of sync with the hg releases, and this breaks thg. These little things shows the sad state of mercurial, and in the end, this will drive most of the developers away from using it.

I guess it was great while it lasted... now, Bitbucket, please provide the developers the right tools to move away from mercurial with celerity.

Well... that's great! :)

May be it was PC-BSD, i don't have it installed right now, so i can't say it with certainty. But that number looks just enough.