I've been using http://kakoune.org/ for the past 3-4 months now and the design of it is pretty good and fits me personally however the implementation feels very hack-y and lacking, especially the way plugins are written (even though its users claim they're not plugins) and its syntax highlighting engine.
I'm an intermediate programmer with no real projects and I'd like to dedicate sometime to master the language I assume I'm familiar with. I am unsure whether writing my own text editor is a difficult task for meor not, I feel like the devs behind Kakoune are much experienced in comparison so my piece of software will most likely be inferior in comparison.
I'm starting to get interested in the scheme world and really want to design a text editor that is powered by Guile much like emacs. I'm aware that Zile Guile and Emacs Zile exist but both them seem rather dead and unsure about how usable and maintainable they are.
Kakoune's editing design is very different from Vim/Vis that I'm quite sure that it's impossible to re-implement on top of it and for that reason that if I go on to write my own text editor, I'll make sure that it's more of a Zile inspired one rather than a monolithic static one.
I'd like to implement Kakoune on top of Emacs but how practical is Elisp compared to Guile outside of Emacs? I want it to be expanded a language that the user can adopt as their "general scripting language" instead of just a domain-specific language. Originally this idea came in mind because I was looking at high level languages to learn and that's how I got interested in Guile and still looking to explore more languages that I can use for prototyping something quickly in.
The uncertainty of my own implementation becoming usable or any better than Kakoune's is making me think maybe I should just give up and force myself to settle with a popular modal editing plugin on top of Emacs so I could dive in the Emacs world.
How practical is it to write your own text editor while making sure it'll implement modern features e.g., syntax highlighting and LSP-client and preferably without forcing too many design choices on the user? What design principles should I follow for implementing a text editor? and should one expect implementation to come to existence after a short period of research/general reading?
I suppose it's a general thread about implementing text editors too.
There's a book called ``The Craft of Text Editing'' that you might want to skim to get an idea of the complexity involved in writing an Emacs-like editor.
You'll lithp cowards can't even write a text editor see you in a week after you give up.
Go look at the micro editor which has a small codebase and plugin support.
>>3
Don't bully.
Don't forget edwin. It's a more pleasant experience if you use it with gjs' conf file which you can find in an old thread posted here.
OpenBSD's mg is another a tiny emacs-like editor (~ 160 KB): https://github.com/ibara/mg
Good luck, OP. I've never heard of Kakoune but its source code isn't too huge yet.
$ cloc src/
136 text files.
136 unique files.
1 file ignored.
github.com/AlDanial/cloc v 1.84 T=0.14 s (959.2 files/s, 252170.7 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C++ 56 3158 208 21877
C/C++ Header 78 1981 179 7894
make 1 34 2 157
-------------------------------------------------------------------------------
SUM: 135 5173 389 29928
-------------------------------------------------------------------------------It would probably be more interesting to "port" Kakoune's insights to Emacs.
>>8
https://github.com/clemera/objed is pretty close to this; it wasn't quite consistent, or refined enough for me though.
>>9
If you look a the branches, it's currently being rewritten, so that might improve.
But it lacks multiple selections.
>>10
You know it was actually several months ago that I tried it, even the master branch has seen a number of changes since then. It really does have a lot of potentially, and I really wanted it to be a part of my workflow even if it took a while to adjust to.
Unfortunately, despite the progress in the branches and in master, this was during the start of last month, the last commit was at the start of this month was the following: https://github.com/clemera/objed/commit/70f9fb5e0aa1627b0afc7c6b3d0aea9bac70a210 I wonder if this refers to all branches or just master?
In any case I'd encourage others and probably myself to give it a try, it very well might have had the problems I experienced when I gave it a go resolved, or it might be that they wouldn't be problems for you. It does take some time to adjust to so you should try to be patient if you do try it.
(I'm not sure if others here agree, but I actually really wish this project wasn't modal, and had generic operations text-objects which were just inferred from context.)
(I'm not sure if others here agree, but I actually really wish this project wasn't modal, and had generic operations text-objects which were just inferred from context.)
This sounds interesting, but I'm not exactly sure what you mean. Could you give an example?
>>12
Well an example would be that if you're in a S-expression and not in a comment or quote you could effectively have paredit bindings working on the inferred S-expression. Many of these operations would have analogous uses in plain text for example you could snarf a word into a sentence, or move a sentence within a paragraph without the explicit act of selection. Here movement influences selection, but it is not selection, in that the selection is inferred from context rather than most movement commands leaving behind a mark for example. If you wanted movement to be selection you would have to explicitly enable it with C-SPC, as you do currently.
>>13
Isn't that something like Lispy (https://github.com/abo-abo/lispy)?
>>14
yes, in a way. Lispy is a redesign of paredit, it's modal by default with the option to use paredit cord based keybindings. It would basically just be a generic version of paredit which allows for the user to create arbitrary text-object hierarchies and apply paredit commands.