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

161–170 of 329 posts

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

#161

Post by brightball »

ncd wrote: post #10

This looks awesome (although I think the name could use a little work). It also brings up a question I have for HN: Every few years, I make an attempt to learn to use one of the classic editors like vim or emacs, and inevitably give up after the enormous productivity drop I suffer when writing code. I just can't seem to pick up the muscle memory required to become fast with these tools, and the overwhelming array of…

If you do any amount of work via command line or SSH, you need to be competent with one of them. I've been using vim for 18 years now and I'd consider myself a barely competent vim user at this point.

I know enough to use it, but not enough to like it.

For virtually all work where I don't have to use a terminal editor, I use Sublime/Textmate or one of the language specific Jetbrains IntelliJ derivatives. The "jump-to-declaration" functionality of Jetbrains is so smooth and so good that I actually have a hard time not having it available now.

Truly useful things get committed to muscle memory almost immediately.

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

#162

Post by mponw »

I started a similar project in 2013, sadly never delivered a working prototype. Its name was going to be "Kuji Editor", basically an editor in visual mode by default and with context-verb grammar instead of vi's verb-object grammar. I knew this would represent a big improvement over other editors because of a more intuitive and modern approach leading to a better workflow.

I started with building the UI in PyGame but never got further than that...

(I am really disappointed I didn't spend more time on this now I see the attention Kakoune gets. I would have loved the feeling of contributing something truly innovative... well...). Congrats to Maxime!

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

#163

Post by brandonmenc »

ncd wrote: post #10

This looks awesome (although I think the name could use a little work). It also brings up a question I have for HN: Every few years, I make an attempt to learn to use one of the classic editors like vim or emacs, and inevitably give up after the enormous productivity drop I suffer when writing code. I just can't seem to pick up the muscle memory required to become fast with these tools, and the overwhelming array of…

It is not worth it.

I used vi for a few years then switched to emacs, which I used for around 15 years. I "lived" in emacs - terminal, web browser, email. Everything.

Now I only use JetBrains IDEs, and have no desire to go back.

At some point, you realize that software development involves way more thinking than it does typing.

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

#164

Post by hxegon »

codebeaker wrote: post #62
IshKebab wrote: post #38

Modal text editors are definitely not my thing, but anyway this looks like a huge improvement on vim. Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.

Interesting, if he's architected it for that purpose, it doesn't have to solely be console based. Neovim separated the client and server parts, and there are a host of clients (QT, HTML/Atom, etc) including the canonical one, from the docs: When compiled with the |+clientserver| option, Vim can act as a command server. It accepts messages from a client and executes them. At the same time, Vim can function as a client…

(it does)

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

#165

Post by blakeyrat »

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 it out with your programmer colleagues.)

(And to prod the bear a bit, a large part of the problem is the developers who insist in working in tools like the ones we're discussing here, designed in the '70s and using absolutely no technology that was invented after 1985 or so. Ludicrous. Imagine if any other industry worked that way!)

Then a couple days later, you found out they spent like an hour making ASCII art of some diagram because they couldn't just paste the actual diagram into the code. Sigh. Reason #3136269 I don't get along with other programmers.

I mean you're talking about advanced AI code that looks up Google links to explain code constructs, meanwhile 95% of the industry is using a code editor that doesn't even allow you to embed a link in a code file. (If you're lucky, it'll make an obvious URL clickable, that's about the best you get.)

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

#166

Post by blakeyrat »

falcolas wrote: post #45
IshKebab wrote: post #38

Modal text editors are definitely not my thing, but anyway this looks like a huge improvement on vim. Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.

What would a GUI bring to this that isn't possible in the console? You can use a mouse to issue commands to console programs, after all: if you want to use your mouse to scroll through or select regions of text, you can.

You could use a nicer font, for one.

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

#168

Post by hxegon »

gr3yh47 wrote: post #78
IshKebab wrote: post #38

Modal text editors are definitely not my thing, but anyway this looks like a huge improvement on vim. Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.

yeah... fta: >The first thing to realize is that non-modal text editors are extremely biased towards insertion. They make insertion easy (by making the default behaviour of most keys to insert a character into the buffer) at the expense of making most other operations suboptimal, by requiring hard to reach keys or modifiers (or, even worse, moving your hand all the way to your mouse). i disagree whole heartedly that…

> 1) occasionally entering several commands by accident when in the wrong mode and having to correct it

Maybe for beginners, but this almost never happens after a while, and hitting undo takes 0 time.

> 2) lack of ease of use both for initial learning and for other coders who might have to type something on your comp when pairing and they dont use your exact modal editor

You have a point for learners, but I'm not going to pick my tools based on what other people need, I'm going to pick them based what I need.

> 3) lack of transitionable skills to other editors, difficult discoverability, and many other side effects of modal systems

Don't see this at all. Vim-like editors have a pretty standard set of objects/verbs, many programs use vim style keys (less for example). How are you going to transition say, IDEA, or RubyMine, or Emacs specific key shortcuts or plugins?

Update: 2 more

> I disagree that reaching for modifiers is some great expense

It is when you are using "commands" at the rate an experienced vim user is. Excluding single char/line navigation spam, I use about 20-70 a minute if I have a good conception of the change I want to make.

> i can do things in sublime at probably 90% of the speed of someone in vim and perform many or all of the same operations including some you cant do in vim etc thanks to plugins.

A) I doubt that. I've seen people rip through stuff in ways that cannot be done without modal editing. For more concrete examples, look at some vimgolf problems and see how sublime solutions compare. keystrokes are a good measurement IMO because it's independent of user typing speed. Not that the average vim user edits like that, but just as an example of what's possible.

B) Saying "with plugins" is a pretty arbitrary measurement, unless you're trying to claim there are plugins in sublime which you can't implement in vim. Do you have a specific example?

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

#169

Post by JupiterMoon »

tdb7893 wrote: post #141
midgetjones wrote: post #13

Earlier quoted context omitted.

It's totally worth it. For me, I learned vim & touch typing at the same time. Generally I learned while doing side projects, supplemented with general vim sessions (such as the built-in tutor, and http://vim-adventures.com/ ). Many find it easier to start off with GUI vim as your favourite keyboard shortcuts are still there, but I found that too much of a crutch. Once you commit a few standard sets of motions to musc…

Can you add code completion or basic static analysis to vim? I've found it fine for editing but it lacks the information of the IDEs that I generally use

https://github.com/Valloric/YouCompleteMe
Post reply on HN