Kakoune as complete ide

Off Topic
1

I have been using vscode for development work. However, I am being frustrated with it over time (just look at their unaddressed issues and backlog). Then I found Why Kakoune. And I have been hooked to it even since.

Being said that, I have been trying to use kakoune for last few days. After using some latest cli tools, I have some recommendations.

Let me explain so that you understand where I am coming from.

Alacritty has a config file with all default configs and the config file in itself is well documented. We just uncomment and customize the configs we want. So we do not have to go through the documentation to configure it. Almost everything is configurable here. No hard coded keybindings (yes some people like to use ctrl-c, ctrl-x, ctrl-x… for their selfish needs).

I think prompts make code editors complex. Most of us use bash / zsh / fish with our own customization. Having a second prompt make things inconsistent, or at least customizing the second prompt make things difficult. In modal editors we use only handful of commands. We can configure them in the config file.

I also think there should be only two modes. Normal and insert mode. For example, object Selection is one of the selling feature of kakoune. Why do we need to put it in a different mode given most of them can be bound to one key. For example, map global normal [ ': execute-keys <lt>a-i<gt> %val{selection} <ret>'

I also think kakoune should be well integrated to tmux (if we choose to use it within tmux). In tmux, normally a session is considered a project. Each windows as a workspace. Each project has a root directory. We have to somehow declare the root directory in kakoune. Then we should be able to browse or search it with something like broot. However, broot do not search each of the file contents in project directory. We have to figure out a way to do that.

To be a complete ide we need to be able to toggle breakpoints via keybinding. We need a option like Ctrl+F5 (obviously customizable) to run. F5 (obviously customizable) to debug (We might have to give the config to how to debug or run. We can take some inspiration from vscode here). As far the output of the given commands, we just have to say that forward the output to a terminal or tmux pane.

xi-editor is a editor core. As far I know it also has syntax highlighting and other cool stuff. It has even vim frontend. It says:

Plug-ins over scripting . Most text editors have an associated scripting language for extending functionality. However, these languages are usually both more arcane and less powerful than “real” languages. The xi editor will communicate with plugins through pipes, letting them be written in any language, and making it easier to integrate with other systems such as version control, deeper static analyzers of code, etc.

I can not agree more with that statement. Who likes stuff like:

printf "value: %s\\n" "${var}"

expr "${var}" : '[a-z]*' >/dev/null

expr "${var}" : '\([a-z]*\)'

:nop %sh{ {
    sleep 10
    echo "eval -client '$kak_client' 'echo sleep ended'" |
        kak -p ${kak_session}
} > /dev/null 2>&1 < /dev/null & }

please think of it from an end user perspective.

imitating or being inspired by vim in the most unintelligent thing a text editor can do in 2020. Coke own after they decided to compete against water insted of pepsi.

Being said all of that, I am proposing a xi-editor’s kakoune fronted with the recommended features. Please let me know what you guys think about my idea. Being a system analyst, I like listening to feedback.

thank you very much for your time.

PS: Being a new user I can put only two links so I had to remove most of my references.

2

@blueray453 welcome to the community! Everything below intended in a warm and welcoming tone. :slight_smile:

Kakoune as complete ide

Unix is the IDE – Kakoune is the text editor component of that IDE. I think trying to turn Kakoune into an IDE should be an anti-goal of the project.

No hard coded keybindings

This is actually a fundamental decision made about Kakoune (for better or worse). Some editors make the binding the “truth”, some editors making the bindings just a map to a function with is the “truth”. Vim is in the former category, Emacs is in the latter. Kakoune is in the former camp.

I think prompts make code editors complex.

I think trying to live without them is more complex. When you go to open a file – it would open a custom file browser? The prompt serves a ton of functions – and lets you compose so very powerful, not often used commands that you don’t want to be bound to keypresses.

Why do we need to put it in a different mode

Can you clarify this? Honestly, what is your example bound to [ trying to accomplish?

In tmux, normally a session is considered a project. Each windows as a workspace. Each project has a root directory

I don’t agree with your assertions here – nor is that how I use tmux. Additionally, I don’t believe tmux has the concept you reference of “root directory”, it is per shell. That said, there are “root setting” plugins that look for like .git or similar that can handle getting this set for you – then everything else just works.

broot do not search each of the file contents

… I do search with broot and my own find command over my entire working directory regularly. This is actually probably my single most used feature. This is all about starting (or moving) kakoune to the project root directory.

To be a complete ide we need to be able to toggle breakpoints via keybinding.

This is astonishingly language dependant. There are some integrations that do stuff down this line – but obviously only for specific languages, and the same applies to VSCode. Your favorite language might be well supported, but many are not.

xi-editor is a editor core.

xi-editor is dead: xi-editor retrospective | Raph Levien’s blog – and the core idea of developing code over pipes and custom UI can be done in Kakoune (kakoune/doc/json_ui.asciidoc at master · mawww/kakoune · GitHub) – but Kakoune is deeply committed to using unix shell as its universally available top tier glue.

imitating or being inspired by vim in the most unintelligent thing a text editor can do in 2020

Vim is top 5 text editors consistently for 20+ years – I think being inspired by a project with that sort of longevity is wise. I think possibly Kakoune was TOO devoted to Vim’s old keybindings at the cost of internal consistency – but the inspiration is wise.

Being said all of that, I am proposing a xi-editor’s kakoune fronted with the recommended features.

You are more than welcome to write one! :slight_smile: I would download it and play with it – however as a community it isn’t something I would put our time into – we have more pressing issues.

2 Likes
3

I actually looked upon Raph Levien. He was doing a great job. Its sad that he gave up. However, I think the community is still continuing with the project. I have to contact them to know whether it is production ready or not.

I am currently looking for a developer who can implement the requirements I have mentioned (in rust). It is In-Shah-Allah going to happen. However, I am not sure how much it might cost, or who will be fit for this job? I wanted to email mawww, Screwtapello or someone. Who knows about this project. But I could not find the email address of any of them. If you can fix me a meeting with someone who knows about kakoune and can write modal editor in rust then you are welcome to play with it.

Being said that, after receiving your feedback, I found some mistakes in my requirement.

I think the prompt we are currently using in kakoune makes it complex. We can take some inspiration from vscode here and make a prompt which will be triggered by ctrl+p (obviously customizable) to search files and ctrl+shift+p (obviously customizable) to search commands associated with our keybindings or commands (which do not have associated keys). Just to be clear, each keybinding will be a “command + Key”.

We should have a way to take our current selection, pipe it to an external command, and replace our selection with the stdout of that command. These functions should be is the config-file.

Plugins (what we will put in ~.config/kak/autoload) should be for language support, intellisence etc.

Sorry I could not give more than two links in my last post. The answer to your question is in How to change default keybindings · Issue #3020 · mawww/kakoune · GitHub

I am not talking about searching files. I am talking about searching content of all the files in a directory.

Yes, I know. That is why I said:

Maybe we have to put a project specific config file in each project directory. Who knows. I have to talk with the developer about that.

Being said that, please help me get the ball rolling.

4

To see how it should work, please check:

5

And also, please check (bot thing, only two links per post for me)

6

OK, I’m fairly new to the Kakoune community, but hopefully I can help out on some of these pain points.

You said that we need a way to take a selection, pipe it into a command, and replace the current selection with the output of that command. I haven’t used it much, but I believe Kakoune can already do this with the pipe (|) operator.

Also, as far as debug configuration like VSCode - the way VSCode’s debugging works is by using a protocol known as the Debug Adapter Protocol (DAP) to communicate with “debug servers” known as debug adapters. This allows VSCode to be a generic client hooking to these debug adapters to provide debugging functionality. A good Vim plugin to look at that implements this is Vimspector. I’m currently working on a plugin for Kakoune that leverages this protocol called Kak-Inspector, but given my relative inexperience with Kakoune and full-time job, it’s slow going :wink:.

As far as the prompt goes, it serves a similar purpose in Kakoune as it does in Vim - it allows for more complex commands to be executed than can be handled by Kakoune’s keybindings. You can certainly get by without it with the right Kakoune config, but the extra power is there if necessary.

I hope this helps, and good luck with finding an editor that suits your needs.

3 Likes
7

I think there is also Language Server Protocol (LSP). If we can take these stuff from vscode then hopefully things will be easier. I am hoping the base will be from alacritty. By base I mean the foundation or starting boilerplate or the architecture. Hopefully, developing later will be easier if we minic alacritty architecture. Everything should revolve around the config file.

For taking selection and processing with a command and sending back the stdout, I am looking for something like:

#- { command: search-remove-duplicated,  description:"This will sort and remove duplicates" action-mode:from-cli, action: "sort | uniq" }
#- { key: L,  mods: Control, editor-mode: Normal, action: search-remove-duplicated }

We can discuss further on how the config file should look like.

8

Yes. That is something we do not want. we should not be able to write something like

:nop %sh{ {
    sleep 10
    echo "eval -client '$kak_client' 'echo sleep ended'" |
        kak -p ${kak_session}
} > /dev/null 2>&1 < /dev/null & }

Our prompt will be like vscode’s ctrl+p (it is completely different from vim or kak’s prompt). It will only suggest our commands defined in the config-file.

If we need to run multiline command we can do something like:

#- { command: search-remove-duplicated,  description:"This will sort and remove duplicates" action-mode:from-scripts, action: "script.zsh" }

Where script.zsh will sit on a particular directory, or

#- { command: search-remove-duplicated,  description:"This will sort and remove duplicates" action-mode:from-scripts, action: "path/script.zsh" }

where the script sits on a particular directories sub-directory.

we should support script’s in rust / golang / bash / python / zsh / fish.

we should not be writing text manipulation code on what the normal mode can do. Let people contribute their owe scripts and configs to manipulate code. We are only providing the foundation so that they can do it.

9

Hello @blueray453.

Actually yes, we could have that for a lot of options.

Yes, and you can easily drop to the terminal with <c-z>. I don’t think having a less capable prompt is a solution to this, as you can already use it just for that. The only solution would be to be able to use your prompt keybindings to execute kakoune commands, which actually sounds nice. Maybe you’d like to try connect.kak and add even more commands.

I think many people would think differently. But anyway, programming a plugin that does this is fairly easy.

In regards to searching files, I think you have missed Kakoune’s integration with grep-like tools. Check grep.kak. Just set your preferred grepcmd.

This is a matter of implementing the protocol.

I don’t see why I would want this. What happens with modal editing?

Many of us already have that functionality, which serves for many things. I don’t know whom I copied it from.

try %{ source .kakrc.local }

This way you can customize your commands for a local project.

Check kak-lsp.

What is the benefit of mapping things that way instead of with the command map? Because, honestly, I find it much simpler to type map window <key> <command> on the way, which I do when I’ll be doing something repetitive.

You are removing most of the interactivity from kakoune doing this. I love to write things in my local config file, evaluate them, keep them for the following session in this project and lastly moving them to my global config if they were really useful. I like to be able to write something like that! :smiley:

It is great that the configuration language is the prompt language. Because I can write configuration and evaluate it, or I can quickly map new things in the prompt (or whatever really).

3 Likes
10

we should support script’s in rust / golang / python / zsh / fish / bash

To define a command we put our script on a particular directory’s normal or insert subdirectory. normal directory is for normal mode commands. insert directory is for insertion mode commands.

If we need to run command we can do something like:

#- { script-name: "script.go" description:"This will sort and remove duplicates" command-to-execute-script:"go run" }
#- { key: L,  mods: Control, editor-mode: Normal, action: search-remove-duplicated }

Where script.go will sit on a particular directory’s normal or insert subdirectory. And script-name will be also the command-name. So, if we name the script search-remove-duplicated.go the command name will be search-remove-duplicated.go (maybe this .go will show only if there are same name with multiple extensions). We can enforce some naming conventions to eliminate confusions.

I am suggestion that this would be optional, one can if he wants. But the infrastructure should be there so that they can do it easily.

I think we should read “The Paradox of Choice: Why More Is Less”. People will try to implement functionality in different places and it will confuse the new users. Moreover, please look at ctrl+p in vscode. It is not a prompt. It is used to invoke internal stuff only. It is not build to run shell scripts or shell commands.

I am looking for a foundation where we can take code from vscode (specially LSP, DAP etc) and alacritty and just use it. So that we can leverage their large community and wisdom. Their community is larger, so if we structure our program such that we can just copy paste their stuff then development and maintenance will be lot easier in the long run.

So, essentially what we have to keep from kakoune is its grammar, which is object followed by verb. Which will hopefully lay the foundation for multiple selections, which is the central way of interacting with your text in kakoune.

12

The thing is, for most of us (at least I believe so), Kakoune is way more than that. Kakoune has a lot of great ideas, and that one is a particular one. It is great that you like it a lot and want basically something more similar to vscode with that, but some are going to like the rest of the features too. Also, Kakoune’s not trying very hard to be a supreme IDE, but most likely a text editor, only that we prefer to use a text editor as an ide sometimes.

Have you checked dance? It’s a plugin for vscode with kakoune key bindings, and maybe that suits your needs perfectly. If not, what else would you need?

I also suggest you try to use Kakoune for some time. I think you don’t know all of the features yet. Your idea may be great, but you will be able to take the best from kakoune only if you have used kakoune to its full extent. Maybe there are other things apart from object->verb that you want to keep but you don’t know just yet.

3 Likes
13

In addition to what @useredsa has said, I would like to add the following:

This is the beauty of Kakoune’s particular configuration language - it’s merely the glue that exposes Kakoune’s state. The ability to call out to a shell with %sh effectively allows us to script Kakoune with whatever language we wish. Plugins have been created in the community leveraging a wide range of languages - kak-lsp’s backend is written in rust; kakoune-easymotion is largely written in python; kakoune-gdb leverages perl - I could go on and on.

While I agree that having a simpler prompt would be easier for new users, I don’t see how simplifying the existing prompt will improve the editor for existing users used to Kakoune’s philosphy. The prompt is already capable of what you say, running internal commands and commands defined in Kakoune’s config files, and those that simply need VSCode’s Ctrl-P functionality can just stick to that, so why not keep that extra functionality for those that need it, since it’s already developed and tested?

Again, I’m not sure I agree that this would make Kakoune’s development easier. Compatibility with VSCode’s extensions is by no means an easy task. Even if it was easy to do this, Kakoune’s philosophy and editing paradigms are so different from VSCode’s that many of VSCode’s plugins (especially the themes) would likely need significant changes to work with Kakoune. While gaining access to VSCode’s repertoire of extensions would undoubtedly be great, this is probably outside the scope of a text editor like Kakoune.

Based on what you’ve been saying, you seem to be looking for an editor that has a different philosophy than Kakoune. That’s totally fine - everyone has different tastes, after all :wink:. I would second @useredsa’s suggestion to try the dance extension for VSCode to try Kakoune’s keybindings and modal editing nature in VSCode’s environment.

2 Likes
14

Yes, true. I am actually willing to hire a developer. But, I have to try kakoune for sometimes to actually understand what more features I want.

No, we are not talking about theme or plugin. We do not need those. The normal mode commands will do 95% of the stuff that plugins do in vscode. I was talking about compatibility with vscode’s LSP, DAP etc.

15

One quick question. i think vscode uses Language Server Protocol (LSP) & Debug Adapter Protocol (DAP). Which other protocols does a modern code editor use?

16

Trying to enter a community you don’t know much about and hire people is generally extremely expensive and unsuccessful.

1 Like
17

Ah, I misunderstood. My apologies.

Kakoune already has LSP support in the form of the kak-lsp plugin. It requires you to install the necessary language servers yourself, and even gives you instructions on how to do so for many different languages. It supports code completion, code actions, snippets, go-to-definition, semantic highlighting - the works. This functionality isn’t built in to Kakoune, but that’s why we have plugins :smiley:.

As for DAP support - as mentioned before, I’m working on it, with the end goal of achieving similar functionality to the Vimspector plugin for Vim, but that’s a fair ways off. At the moment, my plugin simply allows you to set/unset breakpoints, and start/stop a Java program that will eventually serve as the bridge between Kakoune and the debug adapters. The main pain point with implementing DAP support in an editor other than VSCode is, unlike language servers, most debug adapters are written specifically for VSCode and are a pain to use outside of it as a result.

Many editors use protocols based on JSON-RPC. This is a message format that allows for passing messages/events to/from a client and a server. Incidentally, this is how LSP and DAP work. Xi editor uses JSON-RPC to communicate with external frontends, as does Kakoune.

2 Likes
18

@blueray453 respectfully, I think you need to understand how Kakoune works a bit better before you can consider a fork or overhaul of it. I think if you give it a few months, you will understand how it works much better and your feedback will be more focused.

Kakoune has plenty to improve on — but I do not think a radical restart, port to xi-editor or anything similar is (1) needed or (2) wanted.

Understanding how | works and alt-| and various other features – not just in theory but in practice will make your feedback have far more weight. Understanding the most commonly used plugins (plug.kak, kak-lsp, etc) will also give you context.

EDIT: But I love the passion and I am not trying to dissuade it in any way.

7 Likes
19

Nice question. Honestly, I don’t know about others. Some programs are programmed independently from the editor and then a plugin is created for some editor (much like Kakoune has grep.kak, make.kak, but also things like this one batch(.kak)). Therefore, it is sometimes a matter of writing something small to adapt those tools.

What is the problem? That many programs are not developed in an editor agnostic way. Either because they are not notoriously used such as language servers or because they depend on something from the editor. When it’s the first option, it’s a pity but some developers will only develop for their tools and not try to abstract what can be used for other editors. When it’s the second, usually an adaptation means to reimagine the concept for your editor with the features it has.

Either way, I see you really like the project so maybe you could try to help in those areas.

2 Likes
20

Yes, this is exactly what I am thinking. Today I called a very good hiring manager in India. He is so good that if there is one developer who can get it done, he will In-Shah-Allah find him for me. However, I took your suggestion and will continue using kakoune to understand it more until I come-up with a requirement which both me and the community will like.

21

@blueray453 you might want to check out amp, which is written in rust and has a lot of the features your looking for out of the box. Only thing is it’s focused on basic vim bindings, rather than kakoune’s.

2 Likes