C and C++ can be made to generate pretty much the same assembly, sure. I find it much easier to maintain a template function than a macro that expands to a function as you did in the B-Tree code, but reasonable people can disagree on that.
Abstractions can hide bloat for sure, but the lack of abstraction can also push coders towards suboptimal solutions. For example C code tends to use linked lists just because its easy to implement when a dynamic array such as std::vector would have been more performant.
Too much inlining can of course be a problem, the optimizer has loads of heuristics to decide if inlinining is worth it or not, and the programmer can always mark the function as `[[gnu::noinline]]` if necessary. It is not because C++ makes it possible for the sort comparator to be inlined that it will.
In my experience, exceptions have a slightly positive impact on codegen (compared to code that actually checks error return values, not code that ignores them) because there is no error checking on the happy path at all. The sad path is greatly slowed down though.
Having worked in highly performance sensitive code all of my career (video game engines and trading software), I would miss a lot of my toolbox if I limited myself to plain C and would expect to need much more effort to achieve the same result.
C and C++ do have very different memory models, C essentially follows the "types are a way to decode memory" model while C++ has an actual object model where accessing memory using the wrong type is UB and objects have actual lifetimes. Not that this would necessarily lead to performance differences.
When people claim C++ to be faster than C, that is usually understood as C++ provides tools that makes writing fast code easier than C, not that the fastest possible implementation in C++ is faster than the fastest possible implementation in C, which is trivially false as in both cases the fastest possible implementation is the same unmaintainable soup of inline assembly.
The typical example used to claim C++ is faster than C is sorting, where C due to its lack of templates and overloading needs `qsort` to work with void pointers and a pointer to function, making it very hard on the optimiser, when C++'s `std::sort` gets the actual types it works on and can directly inline the comparator, making the optimiser work easier.
My guess is that because in most common x86_64 calling conventions the caller is responsible for destructing the parameters, it has to run the unique_ptr parameter destructor which needs to check if it was moved from in the callee or not. Additionally, because this destructor is not a trivial one (i.e. it does something), unique_ptr cannot be passed directly through a register but must be spilled on the stack.
Kakoune goes the opposite way, there is no such thing as "search and replace" in it, you'd use multiselection for that.
It ends up being much more powerful because the editing language is strictly more expressive than regular expressions: you can select using a regular expression, but you can also use all the rest of the normal mode, such as select/jump to the matching parenthesis or brace (or whatever pair of text your language use to scope things), which is not possible to express in pure regex.
You are far from limited to a single screen, the `(` and `)` commands rotate the main selection, so you can inspect all your selections easily if you want to.
In my experience (as a long time Vim user and as Kakoune's main author) multiple selections end-up being much more attractive for quick edits where there's only a handful instances to replace than devising the correct regex/replacement pair, and their interactive nature makes them quicker to use than the macro alternative (which is also supported in Kakoune).
Coming from a video game industry background, I have been running Kakoune in Windows since its early days, but always in a posix environment (cygwin, then WSL).
It was a concious design decision to rely on posix extensively, one reason being that if you do not care about not having posix available, you are probably not that interested in what Kakoune provides.
To give a bit of context, the idea behind this design is that those scripts should ultimately only be glue scripts that convert from some editor agnostic tools into Kakoune commands.
I do agree that sh is not a nice programing language, and forking programs all the time is not very efficient. I think that there is a tradeoff between the different approaches, and Kakoune's has proven to make quick'n'dirty very easy while being suboptimal for complex tasks.
I am okay with that tradeoff because I still believe most complex tasks do not need to be editor specific, and should be provided by separate tools written in a more maintainable language.
Another reason is that I've been trying to design Kakoune in a minimalistic way, and one thing I tried to unify was the user and scripting interface, which means I needed a command language that was easy to write interactively (`edit filename` vs `edit("filename")`). This is again a tradeoff that helps with simple things (as users already know the scripting language if they know how to use the editor), while making complex things harder.
If you get your selections through a regex, you will have access to capture groups in registers 0..9 (which will store the correct match for each selections), so to do the change you wanted, you'll type (in normal mode, no ':'):
%sfoo\(([^,]+), ([^)]+)\)<ret> # select whole buffer, then select all regex matches
cbaz(<c-r>2).foo(<c-r>1)<esc> # enter insert mode, <c-r> recalls a register
I have been meaning to do a screencast at some point, or maybe I could do a twitch Q/A session.
Its more tricky if you do not use tmux, as due to Kakoune client/server nature, fzf will be launched by the server, which might not even have a terminal. That said I really enjoy fuzzy matching, and most built-in completions do fuzzy matching already.
Thanks again for giving feedback on your experience with Kakoune, always much appreciated !
1. that is missing, but mostly because nobody needed it yet, and I am not very familiar with repl style languages. I expect it to be implementable with current features.
2. The simplest way to do that is to set the makecmd option, options can be set per buffer, so each C++ buffer can have it set to the compile command for it. You'll get output in the make buffer.
3. I use ctags a lot, and it is well supported, it requires the readtags command that is provided by default in universal-ctags, and needs to be installed manually with the older exuberant ctags. There is no cscope support script AFAIK (although should be possible).
Thanks a lot for you reply, I try to be reactive to feature requests, especially easy ones like making something configurable through an option (I expect most of these to be resolved in a day or so).
Some people are using kakoune with fzf, using tmux to open a split, which is very simple to implement with fzf-tmux. Interacting with Kakoune interface ought to be possible but possibly more tricky.
Very interested to know what was missing for you ? We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them).
Glad to hear you liked the interaction model, may I ask you what kind of options were missing for you ?
The extension model is, I agree, unorthodox, but I think it does work reasonably well (the file you linked manage to provide asynchrounous clang completion and syntastic like diagnostics using it), and keeps things simple. Note that we try really hard only to depends on POSIX tools, so the scripts are actually targeting POSIX shell.
Hello, glad you enjoyed your first contacts. I have been using Kakoune not only to write itself, but as my only code editor in my day time job (C++ video game coding) as well for the last 3 years. I consider it stable, definitely not alpha, every major features are implemented (with maybe the exception of folding) and while breaking changes happen from time to time (some key binding change mainly), they are very rare, and usually discussed on IRC beforehand.
While I agree a proper release would be neat, at the moment keeping a stable master branch, and opening topic branches for disruptive work does the trick. Most of the time, I do not push any commit before having spent a day at work with that code, making sure I do not hit any problems in my workflow. Still a long way from proper testing.
So yeah, Kakoune is definitely useable for day to day work, with quite strong support for C++ (clang support for completion and diagnostics) as it is the language I mostly use.
Abstractions can hide bloat for sure, but the lack of abstraction can also push coders towards suboptimal solutions. For example C code tends to use linked lists just because its easy to implement when a dynamic array such as std::vector would have been more performant.
Too much inlining can of course be a problem, the optimizer has loads of heuristics to decide if inlinining is worth it or not, and the programmer can always mark the function as `[[gnu::noinline]]` if necessary. It is not because C++ makes it possible for the sort comparator to be inlined that it will.
In my experience, exceptions have a slightly positive impact on codegen (compared to code that actually checks error return values, not code that ignores them) because there is no error checking on the happy path at all. The sad path is greatly slowed down though.
Having worked in highly performance sensitive code all of my career (video game engines and trading software), I would miss a lot of my toolbox if I limited myself to plain C and would expect to need much more effort to achieve the same result.