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

311–320 of 329 posts

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

#311

Post by cwp »

eridius wrote: post #294
egypturnash wrote: post #238

Earlier quoted context omitted.

I'm not the person who mentioned QS but I'm still using it too. For me it's mostly inertia: Alfred can probably do everything I use QS for, but QS still works just fine, so why bother? When something breaks the 10% or so of QS's capabilities that I actually use beyond fixing, then I'll switch. ("Probably": last I tried using Alfred a few years ago, I think there was something I relied on QS to do that Alfred couldn't…

QS was seriously broken for a long time. I understand someone else finally picked it up and started fixing the bugs, but I don't know why anyone actually kept with QS during the long broken period. Even back when QS was under active development by the original author, it was still pretty buggy. I actually had a separate keyboard shortcuts app running in the background with a single shortcut which would relaunch QS fo…

The great thing about Quicksilver is the grammar - it's actually object, verb, indirect object. That lets you do things like , , .

Alfred didn't have that basic structure when I tried it. I'm sure it's quite powerful, probably more so than QS given the latter's long stagnation. But I never bothered to figure out how to use Alfred effectively because QS is so easy and works great. There were a couple of bugs that were annoying for a while, but they've been fixed.

Kakoune doesn't mention the "indirect object" part of the grammar, but apparently it'll prompt for more information when needed, so it's pretty close.

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

#312

Post by etruong42 »

I see many valuable feature, such as the highlighting and the tooltips.

I wonder if these could have been expediently implemented as VIM plugins - perhaps each feature could have been a VIM plugin so that people can pick and choose which feature set they wanted.

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

#313

Post by iplog »

Really interesting project and looking forward to having time to play a bit more with it. After trying it for the first time and reading the documentation I have the impression that the `alt` key is used a lot as a modifier key for basic things such as selecting inner objects. One thing I love about Vi and Vim is that most it tries to reduce the usage of modifier keys which is awesome when you are touch typing. I would love to know why the author chose the `alt` key and what the other options were. That's a great project and I'm sure it could help a lot of developers to understand modal mode. Great work!

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

#314

Post by eridius »

cwp wrote: post #311
eridius wrote: post #294

Earlier quoted context omitted.

QS was seriously broken for a long time. I understand someone else finally picked it up and started fixing the bugs, but I don't know why anyone actually kept with QS during the long broken period. Even back when QS was under active development by the original author, it was still pretty buggy. I actually had a separate keyboard shortcuts app running in the background with a single shortcut which would relaunch QS fo…

The great thing about Quicksilver is the grammar - it's actually object, verb, indirect object. That lets you do things like , , . Alfred didn't have that basic structure when I tried it. I'm sure it's quite powerful, probably more so than QS given the latter's long stagnation. But I never bothered to figure out how to use Alfred effectively because QS is so easy and works great. There were a couple of bugs that were…

Alfred does use that structure, and as far as I remember, it always has. I can indeed do , , in Alfred (though my most common object, verb, indirect object sequence is , , ).

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

#315

Post by mncharity »

wangchow wrote: post #245
greenspot wrote: post #18

If you are wondering why Kakoune and not Vim, the OP claims... (you find following passages later in his post and they don't reflect my opinion) > A design goal of Kakoune is to beat vim at its own game, while providing a cleaner editing model. > Kakoune manages to beat Vim at the keystroke count game in most cases, using much more idiomatic commands. > Kakoune provides an efficient code editing environment, both ver…

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. Yay. But think 1980's green CRT (on pentile, green is higher res). In retrospect, it was a sunk-cost project-management garden path.

There's been a lot of that. One theme of the last few years, has been people putting a lot of effort and creativity into solutions to VR tech constraints, only to have the constraints disappear on a time scale that has them wishing they had just waited, and used the time to work on something else. It's fine for patent trolls (do something useless to plunder future value), and somewhat ok for academics (create interesting toy), but otherwise a cause for caution.

So on the one hand, I suggest that if the center tenth of VR displays had twice their current resolution, everything else being current tech, we would already be starting on a "I can have so many screens! And they're 3D! And..." disruption in software development tooling. But that's still a year or two out. Pessimistically, perhaps even more, if VR market growth is slow.

In the mean time, what? Anything where the UI isn't the only bottleneck (work on the others). Or which can work in 2D, or in 3D-on-2D screen (prototype on multiple screens). Or is VR, but is resolution insensitive, and doesn't require a lot of "if I had waited 6 months, I wouldn't have had to roll my own" infrastructure. Or which sets you up interestingly for the transition (picture kite.com, not as a 2D sidebar, but generating part of your 3D environment). Or which can be interestingly demo spiked (for fun mostly?).

For example, I would love to be working on VR visual programming on top of a category theoretic type system. But there seems no part of that which isn't best left at least another year to ripen. Though maybe 2D interactive string diagrams might be a fun spike.

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

#317

Post by mncharity »

wangchow wrote: post #304
rimantas wrote: post #250

Earlier quoted context omitted.

> We have all the technology. > It's time to get to the next level. Just because you can does not mean you should. Dictating code may be useful is you cannot use your hands, but that's about it. In all other cases there is no benefits of doing that.

Well consider if you use both dictation and typing simultaneously. Vi and kakoune are ergonomic because it requires minimum changes to hand positions. But if you added voice dictation like "toggle tab 2" or "toggle terminal" or "go next brace" etc, all while STILL typing my guess is efficiency would go up physical fatigue would go down.

Folks have created Dragon-based voiced-sound vocabulary for editor control. Voice strain is an issue, but you can load share with typing.

You can do Google voice recognition in browser/WebVR, but it's better at sentences than brief commands.

Another component, largely unexplored, is hand controller motion. The Vive's are highly sensitive in position and angle. Millimeterish. So imagine swype text (phone keyboard continuous sliding) with 6 DOF. Plus the touchpad (the buttons aren't something you'd want to use all the time). Keyboard+pad is mature tech. But wands-with-pads look potentially competitive, and (not yet available) hand-mounted finger tracking added to keyboard+pad might make for a smooth transition. Plus voice. The space of steep-learning-curve input UIs for professionals looks intriguing.

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

#319

Post by notheguyouthink »

blakeyrat wrote: post #165
hans wrote: post #60

Pontificating but for ide + editor replacement: someday we'll see ai/ml features that aide in opening files and keeping the right blobs of code nearby, maybe pre fetch good goog links that can drop down on a whim panel. Even some kind of auto model visualizer that helps every so often like a replacement for the ignoble package mmanager side panel view. We're still so stuck on text editing.

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 code into rich text, imo.

Post reply on HN