Really awesome project, is there any plan?

[brupelo]

Hi,

Nice to meet you, this project looks really awesome and I'll tell you why, usually I code 3d tools using pyqt for the frontend (on python) and for the backend/plugins I use c++.

For years I've been using QScintilla (which it's a Scintilla qt widget) python bindings and while this component isn't bad I can't tell is great neither, Scintilla supports multicursor but unfortunately it doesn't implement undo/redo properly to work with multiple selections. Overall Scintilla isn't a bad component but I think it isn't great in comparison to other existing "cleaner" solutions such as codemirror/ace for the web... or SublimeText native.

I'd like to hear what's the scope/goal of this project... Do you intend to use it on some specific real 3d tools? Make it generic for any kind of desktop tool?

Could you eventually upload some screenshots/videos or demo executables to play with it? I've wanted to replace Scintilla with some native widget for very long time but I haven't found any solution out there to consider worth the replacement.

Also, I can see the project is still in early stages of development... from my experience I'd suggest you take a look to this library http://tree-sitter.github.io/tree-sitter/ , I've tried many different highlighters over the years (pygments, syntect, qsyntaxhighlighter, ...) and tree-sitter is just great ;)

Anyway, I'd really like to hear a bit more about this project, features, milestones... If I like it I wouldn't mind creating python bindings for it eventually.

Thanks for your time!
Regards

[lukedan]

Hi @brupelo,

Nice to meet you, and glad to see that you're interested in this project.

The goal of this project is to create a standalone text editor like Sublime Text or VSCode. The motivation behind this project is that ST is neither free nor open source, while VSCode is based on electron and during my experience with it I've encountered numerous small performance issues. I started this project intending to create a native text editor that's fast, open source, and customizable.

With that said, it's still possible to use this project as a component in your own project. As you can see, all components are built upon a 'platform abstraction layer'. In order to integrate them into your own project, besides needing to compile the code of this project, you'll also need to implement your own abstraction layer or modify the existing ones so that these components can render and update properly. One possible issue that I can think of is that this project manages its own message loop (in codepad/ui/scheduler.h), so you'll probably need to hack around that part.

Existing implementations of the platform abstraction layer can be found in codepad/os. Note that while the Windows implementation is working, the Linux implementation is not since I've changed the rendering backend from raw graphics API like OpenGL to vector graphics libraries. Even before this change the Linux implementation was very buggy and crashed often. Since I have very little experience with UI programming on Linux, I'd greatly appreciate it if someone experienced can help.

You can follow the instructions here to build it and try for yourself if you're on Windows and have VS2017 or later installed (the FreeType and OpenGL dependencies aren't really needed anymore, so you can simply remove them from the link parameters). I don't commit very often because there's currently only me working on this project. Most commits contain a lot of changes and should work right away. Just contact me if you need help building it or if you prefer me sending you the binaries directly.

As you have said, this project is still in very early stages of development, thus I won't recommend using it right now in production code. I intend to provide the minimum amount of features in the base application and expose as much of the internal interface as possible to plugins for maximum customization ability, so although the tree-sitter project you recommended looks really great, it'll have to wait until a proper plugin system is implemented before it can be integrated into the editor as a plugin. (I had been working on https://github.com/lukedan/apigen for a while before I decided that I don't have enough time for both projects and suspended its development.)

Recently I've been working on a settings system and refactoring the tab management system. There's a lot to be done and I could really use some help. The code is well documented except for some files in codepad/os, and some (partially outdated) TODO items can be found in TODO.md, if you're interested. I've never had any experience with managing open source projects, and there's currently no written plans for this project. I'll keep this issue open until this is resolved.

Regards

[brupelo]

@lukedan Hi!

Cool, thanks for the explanation! that gives me enough background about the project, usually I'm very busy but when I allocate some time I'll start by trying to build&run codepad, I've got already few vs compilers available 2008,2010,2013,2015,2017 as well as vcpkg on my box... so hopefully I'll be able to build it without much hazzle.

Existing implementations of the platform abstraction layer can be found in codepad/os. Note that while the Windows implementation is working, the Linux implementation is not since I've changed the rendering backend from raw graphics API like OpenGL to vector graphics libraries. Even before this change the Linux implementation was very buggy and crashed often. Since I have very little experience with UI programming on Linux, I'd greatly appreciate it if someone experienced can help.

I usually code on windows and just use linux for very specific projects so this is definitely good news to me :) . I wonder though, a lot of text editors I've seen out there don't use OpenGL as a rendering backend, why is that? Wouldn't that choice simplify development for all major platforms? Few weeks ago I'd made a little experiment using python+opengl and this is what I'd got https://dl.dropboxusercontent.com/s/ek5gsen03fo2b5k/2019-07-24_11-15-10.gif, that's the result of a simple doodling session, with that experiment I just wanted to check whether an opengl renderer would be feasible instead using any specific OS APIs for text rendering and the result was promising but there must be a good reason why everybody use native text APIs instead, I wonder why though :)

You can follow the instructions here to build it and try for yourself if you're on Windows and have VS2017 or later installed (the FreeType and OpenGL dependencies aren't really needed anymore, so you can simply remove them from the link parameters). I don't commit very often because there's currently only me working on this project. Most commits contain a lot of changes and should work right away. Just contact me if you need help building it or if you prefer me sending you the binaries directly.

Great, as I said before, I'll eventually try to build & run the project myself, if I find some problem I'll just open a different issue/report. Btw, you say in the instructions is required a compiler >=vs2017, would it be difficult to relax that constraint to also support older compilers such as vs2015 or that'd very difficult? Asking as a lot of coders out there still using vs<=2015 and relaxing tools constraints is always a good thing to increase popularity.

Recently I've been working on a settings system and refactoring the tab management system. There's a lot to be done and I could really use some help. The code is well documented except for some files in codepad/os, and some (partially outdated) TODO items can be found in TODO.md, if you're interested. I've never had any experience with managing open source projects, and there's currently no written plans for this project. I'll keep this issue open until this is resolved.

Well, I also don't have a lot of experience with open source projects neither myself, few months ago I'd uploaded to github some attempt to create a SublimeText standalone widget written in python and started promoting it on Sublime forums and IRC, opened a lot of issues, roadmap, etc... Trying to get more people interested but at the end of the day it was just me doing all the job so I lost interest on the project :) . One advice I can give you, screenshots & binary releases help to get traction & stars.

Let me tell you sad news is there isn't really any good options when it comes to open-source standalone text editor widgets with quality like SublimeText/Codemirror/VSCode/Textmate/... And a lot of people relying on Scintilla mainly because there isn't many alternatives out there. And believe me, I've done quite a lot of research about this subject so I know what I'm talking about here:

https://github.com/ajaxorg/ace
https://github.com/andreikop/qutepart
https://github.com/awm/synhtor/wiki/Research
https://github.com/codemirror/CodeMirror
https://github.com/edbee/edbee
https://github.com/edbee/edbee-app
https://github.com/edbee/edbee-data
https://github.com/edbee/edbee-examples
https://github.com/edbee/edbee-lib
https://github.com/githole/Live-Coder
https://github.com/howl-editor
https://github.com/hydrargyrum/eye
https://github.com/JuBan1/notepadqq
https://github.com/JuBan1/OpenTextEdit
https://github.com/kai66673/PythonEditor
https://github.com/luchko/QCodeEditor
https://github.com/lukedan/codepad
https://github.com/martinrotter/textosaurus
https://github.com/matkuki/ExCo
https://github.com/prymatex/prymatex
https://github.com/pybee/seasnake
https://github.com/pyQode/pyqode.core
https://github.com/richrd/suplemon
https://github.com/SergeySatskiy/codimension
https://github.com/smathot/QProgEdit
https://github.com/spyder-ide/spyder
https://github.com/trishume/syntect
https://github.com/tsujan/FeatherPad
https://github.com/waddlesplash/Heidi
https://kate-editor.org/
https://sourceforge.net/projects/synwrite

My point is, this project of yours has:

1. The right license
2. Code looks clean (didn't read it yet) and it seems to be well organized
3. The right goals... unfortunately SublimeText (my favourite text editor ever) is closed source, so if this projects ends up being a real alternative for sure dozens (if not hundreds) of coders will join for sure and the project will get a lot of traction

Anyway, I'll stop here (I tend to write very long mails, hopefully that doesn't bother you). As I said, when I find the time I'll try to test the project.

Btw, I understand you also like SublimeText but you're also concerned about that software being closed source (same here)... in fact, not sure if you follow ST forums but you'll see I've participated in a lot of threads related to this specific subject:

https://forum.sublimetext.com/t/standalone-sublimetext-widget/42065/13
https://forum.sublimetext.com/t/open-source/32583/44
https://forum.sublimetext.com/t/sublimes-future-and-open-source/7424/27

So yeah, an open-source project like SublimeText definitely is a very interesting ;) . Although is a very challenging project as well...

Regards

Ps. Sorry for my English

[lukedan]

Hi @brupelo,

Thanks for your reply.

I wonder though, a lot of text editors I've seen out there don't use OpenGL as a rendering backend, why is that?

Interestingly, codepad used graphics APIs such as OpenGL from the start, until relatively recently I decided to change the rendering backend to vector graphics libraries (not exactly OS APIs, take Skia and Cairo for example). This is the last commit that uses OpenGL and, interestingly, is actually faster than the current commit when browsing large files. There are a couple of reasons that I made this decision:

1. A lot of mature UI libraries like WPF use vector graphics for rendering. As you may have realized, the UI part of this project is heavily inspired by WPF.
2. Using OpenGL for text rendering means that a lot of things need to be done by hand. For example, subpixel positioning and antialiasing of text, and the implementation of font ligatures (although I intend to redo this myself for performance reasons).
3. Using vector graphics makes it much easier to draw smooth geometries in the UI.
4. As far as I know, OpenGL is deprecated on macOS.

would it be difficult to relax that constraint to also support older compilers such as vs2015 or that'd very difficult?

Codepad uses C++17, and will probably quickly adopt C++20 in the near future. I intend for it to use the latest language features as they greatly benefit the development process and make the code much cleaner. However, older compilers tend to have buggy or missing support for new language features. Personally, I'm not too worried since VS2017 is required only for contributors, not end users. Besides, it is not that hard to install VS nowadays.

---

There are a few things that I left out in the last reply. Firstly, I took some influence from vim when designing codepad, and now the application has no menu bars and everything is done through hotkeys. The file codepad/config/keys.json contains some useful commands, and you can customize them as you wish. Secondly, after building the latest commit, you'll notice that most places where text should be are blank, except for code editors. This is because they're rendered using the default empty brush. This behavior will change very soon. Finally, the dragging of tabs is broken in the latest commit and will be fixed (and probably improved) soon.

If you're really interested, I would suggest that you also build the last commit that uses OpenGL to see a version of codepad that functions better. FreeType is required for this commit, and you'll probably need to find and download additional OpenGL headers.

Regards

P.S. I'm also not a native speaker of English. Glad to have this chance to practice with you.

Interesting conversation. I was looking for a sublime text alternative as well, the screenshots caught my attention. While sublime is great as-is, it would be nice to have an open source text editor that is as good or better. Many, and by many i mean thousands of people have useless projects on this site because they are all either

1-doing the same thing, like those CLI editors or the endless vi, emacs, notepad copycats

2-programming in under-performant languages such as java, python, c#, resulting in slow or memory-hungry applications.

3-failing to implement truly great functions like sublime's ability to view the whole text at once. I am practically unable to write or code without that function now, it's just so nice to have.

a text editor shouldn't use more than few megabytes when opened, at most. it should open instantly too. only languages such as C, C++ and other similarly performant ones can do this. that is the harsh reality.

default windows notepad uses 2mb on idle. sublime text, while also opening in an instant, utilizes solid 40 megabytes just to hang there doing nothing. that is quite a lot, but it's still far from some others... specially electron ones. You mentioned you want to ditch the menu: I don't think that's a good idea. sublime, while also having a shortcut for practically everything, has a menu there with all the functions. maybe you're a noob, or you've just started utilizing the application, or you forgot the command, or you just want to use an ui. there are many reasons to have a menu, specially when it comes to options that require a list.