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

Why Kakoune – The quest for a better code editor

kakoune.org

Post reply on HN
Print view View original

321–329 of 329 posts

Re: Why Kakoune – The quest for a better code editor

#321

Post by jxy »

Roboprog wrote: post #130
DennisP wrote: post #98

Earlier quoted context omitted.

That's why I tend to use visual mode. It sounds like Kakoune is basically visual mode by default, which is cool but not that different. This example was a bit silly: "dtf will delete to next f, if you then realize that was one f before the one you targeted, you need to undo, go back to your initial position, and try again with d2tf." There's no need to undo. Just follow up with a dot and you're done. Which pretty muc…

The dot trick is fine, unless you wanted to paste the deleted text somewhere afterward, in which case you need to pick it up in one go. Otherwise, yeah, dot is great. I love using that for repetitive stuff on "tabular" copied entries that I'm not thinking real hard about transforming. (E.g. - 5 lines or so that I'm not cooking up a regex or an perl/awk spell to transmute)

   > The dot trick is fine, unless you wanted to paste the 
   > deleted text somewhere afterward, in which case you 
   > need to pick it up in one go.
No.

   "1p.

Re: Why Kakoune – The quest for a better code editor

#322

Post by nikolay »

steveklabnik wrote: post #320
nikolay wrote: post #316

Why not write it in Rust though like Google's Xi [0]? [0]: https://github.com/google/xi-editor

> I have been working, for the last 5 years, Rust was very, very different five years ago.

Sorry, I've missed that!

Re: Why Kakoune – The quest for a better code editor

#323

Post by buster »

geodel wrote: post #175
buster wrote: post #167

Earlier quoted context omitted.

No multi threading is a plus?

From Design notes: > "No threading: multithreading is a hard problem, and is not well suited to a text editor: Either we want a direct result, and we need to be synchronous with the user, so getting a 4x speed up is meaningless, we need to have an algorithm which appears instantaneous the user. Or we want an asynchronous result, and then the processing is best left to a helper command which can be reused with other U…

One of the big problems of editors like emacs and vim is that they haven't had means for background processing for years. And no, multithreading is not hard if you design for it. It is very hard if you need to add it as an afterthought. Some people would even say threads are easier then async.

Re: Why Kakoune – The quest for a better code editor

#324

Post by blakeyrat »

notheguyouthink wrote: post #319
blakeyrat wrote: post #165

Earlier quoted context omitted.

I think we need to first get over the hurdle of "code == text". I mean, the features you talk about are great-- but right now I can't even embed a little vector graphic explaining a function's flow in my source file. Every time I've suggested using a file format that allows things like fonts, styles, embedded images, to write my code, the reaction is always an insanely irrational knee-jerk against it. (Seriously, try…

To be fair, why does it need to be imbedded in the code? Why can't it just be a plain text link to a binary file (your vector image), which automatically embeds for supported editors? What you're talking about is turning source code into a binary object. That's fine, if you use an editor that supports it, but you shun all other editors when you do that. There is a middleground that doesn't involve making your source…

It doesn't need to be. (Why the italics?) In fact I don't give half a crap about the implementation details of how it works. All I want is to be able to drag a little diagram from a paint program into my code editor and have it there in the code and then when someone else looks at the code they see the little diagram, too. Whether it's implemented by a "binary object", or by adding an additional XML file, or by a magical monkey from heaven reaching down and placing it there, I do not care. I'm talking about a feature I want to use, not about nitty-gritty implementation details.

As for "shunning other editors", well, frankly, why are we as an industry bending over backwards to support people using editors from the 1970s? Do you think Ford still builds cars with imperial measurements just so Old Bob the mechanic can keep using the tools he bought when he went into the field in 1968? No of course not, that's stupid. But that's exactly what our industry is doing.

Re: Why Kakoune – The quest for a better code editor

#325

Post by blakeyrat »

spc476 wrote: post #227
blakeyrat wrote: post #165

Earlier quoted context omitted.

I think we need to first get over the hurdle of "code == text". I mean, the features you talk about are great-- but right now I can't even embed a little vector graphic explaining a function's flow in my source file. Every time I've suggested using a file format that allows things like fonts, styles, embedded images, to write my code, the reaction is always an insanely irrational knee-jerk against it. (Seriously, try…

To prod back, you have three source code files---one is in Word Perfect format from 1987. The second is from Microsoft Word from 1998. The third is an ASCII text file from 1972. Which one can you open and reuse today ?

I can open all of those formats in Microsoft Word right now this instant. So.

Good argument?

Re: Why Kakoune – The quest for a better code editor

#326

Post by spc476 »

blakeyrat wrote: post #325
spc476 wrote: post #227

Earlier quoted context omitted.

To prod back, you have three source code files---one is in Word Perfect format from 1987. The second is from Microsoft Word from 1998. The third is an ASCII text file from 1972. Which one can you open and reuse today ?

I can open all of those formats in Microsoft Word right now this instant. So. Good argument?

No. How about Easy Writer II? Or even Type-Rite?

Re: Why Kakoune – The quest for a better code editor

#327

Post by Roboprog »

jxy wrote: post #321
Roboprog wrote: post #130

Earlier quoted context omitted.

The dot trick is fine, unless you wanted to paste the deleted text somewhere afterward, in which case you need to pick it up in one go. Otherwise, yeah, dot is great. I love using that for repetitive stuff on "tabular" copied entries that I'm not thinking real hard about transforming. (E.g. - 5 lines or so that I'm not cooking up a regex or an perl/awk spell to transmute)

> The dot trick is fine, unless you wanted to paste the > deleted text somewhere afterward, in which case you > need to pick it up in one go. No. "1p.

You got me. I don't know how to parse that ("1p.).

My ignorance is showing. Is there a stack of yank buffers??? Does this p-for-put pop the top buffer, back up before the inserted text, then .-do-it-again and put the delete/yank beneath the last one on the stack? I have no idea what the quotation mark actually does.

Thanks in advance if you can explain how that works to me.

Re: Why Kakoune – The quest for a better code editor

#328

Post by wangchow »

mncharity wrote: post #315
wangchow wrote: post #245

Earlier quoted context omitted.

In this age we need to think about things like voice control and 3D manipulation of data-structures and a dynamic view of the code. We can truthfully keep designing 2D editors (and we will always most likely use them to some extent) but I believe it is more important to consider different UI paradigms altogether. For instance, what about editing a living code environment? Game development is very immersive: you can m…

Yes, but. Keep ripeness in mind. It's very easy to spend effort in this area "too soon". So shape projects with care. I run a Vive on linux. Which required my own stack. Which took excessive time, and is limiting, but has some road-less-traveled benefit of altered constraints. So I've gone to talks, and done dev, wearing Vive with video passthrough-AR, with emacs and RDP, driven by an old laptop's integrated graphics…

Very well put. I have to agree that these technologies are still blooming and there are uncertainties--especially in my mind with cost associated with buying devices. Hololense for example with a $3000.00 USD developer edition isn't exactly accessible to the general community! The next 10 years however will probably be pretty exciting in the AR/VR space.

What about voice-controlled programming though? I always thought it would be nice to voice-control my OS. Not specifically for a text-editor, but as a general interface to the OS. It would be nice to move these features out of the cloud and directly onto systems. But then again, a lot of companies (amazon, microsoft, apple) probably don't want to encourage reverse-engineering of their intellectual property. We definitely need open-source variants.

Better AI chips with lower power-consumption and optimization for these types of operations will hopefully usher in a new set of productivity-enhancing applications!

Re: Why Kakoune – The quest for a better code editor

#329

Post by sevensor »

sevensor wrote: post #39
laurent123456 wrote: post #20

Earlier quoted context omitted.

This is also quite an important difference: > Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.

I often use visual selection mode in vim so that I can see what I'm about to operate on. For instance, if I want to change text between the cursor and the next match of a regex, I want to see the selection before I change it. So instead of c/re[enter], I type v/re[enter]c. It's one extra character, but it saves me a lot of headaches. This is the first I've heard of Kakoune, but I'm definitely intrigued.

Probably too late for anybody to see this comment, but I'd just like to drop back in and say I've tried it and it's amazing. I really did not expect that another text editor would be able to improve on Vim on basically all fronts, but kak has done it.
Post reply on HN