Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kakoune Code Editor

kakoune.org

Post reply on HN
Print view View original

111–120 of 176 posts

Re: Kakoune Code Editor

#111

Post by sidkshatriya »

HKH2 wrote: post #110
sidkshatriya wrote: post #63

Earlier quoted context omitted.

I use Kakoune very extensively. I've tried out Helix a bit though. While I'm adequately informed to make an assessment about Kakoune, my opinion about Helix is more impressionistic. My overall assessment is that Helix has the potential to run away with the Kakoune interested crowd! For a new editor Helix looks shockingly polished! Here is what I like: - Tree sitter is integrated into Helix. Kakoune use a lot of regex…

How did you get Kakoune to segfault?

Kakoune is built in C++. So bugs will sometimes manifest as segfaults. You could be doing some normal editing, press a sequence of editing commands that might trigger some code that may subtly wrong. Sometime later, when C++ code tries to write to memory that it shouldn't have, you will segfault.

In that respect this is true for any C/C++ application. Kakoune keeps fixing these issues as they come up.

Re: Kakoune Code Editor

#112

Post by christophilus »

yitchelle wrote: post #108
raiguard wrote: post #22

Earlier quoted context omitted.

I've been using Kakoune as my daily driver for almost a year. The thing that made me fall in love was the simplicity, both in daily usage and in extensibility. The biggest "oh wow" moment for me was how easy it was to create a color scheme. In Vim, creating your own color scheme is potentially a huge ordeal, with many edge cases. For example, vim-one's color scheme file is over 800 lines long. By contrast, I created…

I would have thought that creating/adapting a colour scheme is a onetime activity when you start using the editor for your language. Do you update the colour scheme regularly?

I think he gave that as an illustrative point about the simplicity of Kakoune, rather than saying this specific example is why he uses it.

Re: Kakoune Code Editor

#113

Post by hyperupcall »

sidkshatriya wrote: post #39
hyperupcall wrote: post #31

When I tried Kakoune, it seemed like a really cool idea and implementation, but it didn't seem like their configuration language had basic functions for string manipulation, path testing, etc. So a common pattern with plugins etc. was to shell out to sed, awk, etc, which was a _huge_ turnoff. I now use Neovim, but if they have recently implemented that functionality, I'd be willing to give Kakoune another shot

Shelling out was a turnoff for me also initially but I've learn to embrace it. Kakoune tries not to re-invent the wheel. If sh/sed/awk/perl/other unix tools do the job well, might as well use them. That is the philosophy I think. I like the fact that using Kakoune has improved my shell script skills like crazy. (Posix) shell scripting is just everywhere and is an important skill to have. Kakoune uses shell integratio…

Sure POSIX shell scripting is a good skill to have, but I would hardly consider it good for a text editor to have that skillset be commonplace within their configuration language. Shelling out incurs a non-zero execution cost. For example with Bash, it is significantly slower execing out when using a builtin or parameter expansion will work just fine, especially with these types of quick text manipulation operations. And that's not even mentioning that you are literally starting up a new Bash process every time you want to do something semi-complicated in a Kakouine config. This doesn't just leave a bad taste in my mouth - it is also a giant waste of resources and causes initialization to be substantially slower compared to the alternative

It is also too easy to write poor shell scripts. It is too easy, even for experienced developers to sneak in GNUisms, and forget simple facts, like how Bash and especially Perl aren't guaranteed to be installed on all systems. Sometimes I also wonder: does Kakoune set `-o pipefail` or `-o errexit`? If somebody sets `ENV` and does something fishy, will that make my text editor unlaunchable? Behavior rooted in common semantics rather than heavy syntax (Bash, Perl) or micro-languages (Awk, Sed) make the overall experience much more pleasant. Especially if you do something like Neovim (Awesome, etc.) and use Lua for Config so you don't have to reinvent anything

Re: Kakoune Code Editor

#114

Post by jimmyvalmer »

dima55 wrote: post #90
raverbashing wrote: post #78

Earlier quoted context omitted.

> Somebody found this useful. Would you have preferred that this person didn't do any of this at all? The usual conversation starters about emacs go "oh you have Spacemacs, you have EVil, you have plugin X, Y, Z, etc, etc" Whereas with other editors the focus is on improving the core experience Plugins are great, sure, but there seems to be an excessive focus on it and most plugins just don't give you the same experi…

You're clearly not involved in the development of emacs, and your perception of the "focus" is based on talking to newbies. Respectfully, go read emacs-devel to find out where the focus is.

go read emacs-devel to find out where the focus is.

If by focus you mean distilled yak shaving, then emacs-devel is the place to be. Emacs is going nowhere because elisp makes it too easy to work on the plugins relative to the C core which was showing its age 15 years ago.

Re: Kakoune Code Editor

#115

Post by Someone »

stjohnswarts wrote: post #55
thayne wrote: post #26

Earlier quoted context omitted.

I tried to use it enough to see if I could switch to it from (neo)vim. I liked a lot of the ideas in it, and in some ways I liked it more than vim, but it was missing some functionality that I just couldn't live without. Some things could be solved by plugins that just didn't exist yet, but others, I couldn't even see a way a plugin could be implemented. In particular, there isn't any way to get a diff mode comparabl…

I don't understand the new line thing at the end. I haven't used a utility or app in -decades- that cared about whether you have a blank final line.

Do you ever do wc? It cares:

  > echo hello > hello
  > echo -n hello > hellon
  > wc hello hellon
         1       1       6 hello
         0       1       5 hellon
         1       2      11 total

Re: Kakoune Code Editor

#117

Post by konart »

ziml77 wrote: post #79
konart wrote: post #67

Earlier quoted context omitted.

> which matches well with the visual feedback Kakoune gives you. Do you really need this feedback though? I can understand this when yanking, but if I'm going to delete the word... The whole action take much less that a second and then I proceed with my task. Well, to each their own I guess

You're taking the example too literally. The point is that using the motion first gives opens the possibility of visually confirming what the action will be taken on. The usefulness of that improves when the motion is complex. But nothing forces you to confirm, so if you're confident it's right you can immediately follow the motion with the action. That loses you no time compared to Vim.

>when the motion is complex

>multiple cursors (from a different comment)

I agree that in this kind of case motion first may be a way to go. Basically it should look like `search && replace`. Without actually doing search && replace.

Re: Kakoune Code Editor

#118

Post by doppioandante »

jzm2k wrote: post #94
usrbinbash wrote: post #87

Earlier quoted context omitted.

imo, Multiline cursors are one of these features that look and feel cool, but are rarely, if ever, really useful.

That's also what I thought as a Vim user before I had access to Kakoune's multiline editing. It changed my mind and might change yours too if you give it a chance

Ditto. I rarely use multiple cursors in other editors, but I use them _constantly_ in Kakoune. I have been using it for multiple years. The composability of the command language is what makes it shine.

Re: Kakoune Code Editor

#119

Post by lvass »

raverbashing wrote: post #42
NateEag wrote: post #15

Note the existence of kakoune.el, an emacs emulation of Kakoune's core: https://github.com/jmorag/kakoune.el I have no idea how well it reproduces the experience - I'll probably be using vim on servers and emacs evil-mode locally until the day I die, so I haven't bothered to get into Kakoune, awesome though it seems.

Why would you even bother making Emacs look like Kakoune? Funny how it seems a lot of Emacs developer time is spent a) making it look like / act like something else and b) making it do things unrelated to editing text. There is no focus. It's good that it can do a lot but it doesn't do any of those things well (unless you want to learn some cryptic key combinations that make less sense than vim). Meanwhile the rest o…

Just look around this thread for the issues people list with kakoune. I.e. hard to configure, window management, lack of IDE features, lightspeed/avy, localization, etc. All of them are trivially solved by using a kakoune layer on emacs instead.

Re: Kakoune Code Editor

#120

Post by jb1991 »

skavi wrote: post #12

Check out helix [0] for a kakoune inspired editor with some nice modern features included by default. [0]: https://helix-editor.com/

wow, I pulled up a C++ file in Helix just now -- never used it before -- and the LSP just worked out of the box. Amazing. Setting up LSP is usually quite a pain in editors like this.
Post reply on HN