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

101–110 of 329 posts

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

#101

Post by to3m »

throwaway109211 wrote: post #64
reitanqild wrote: post #55

Earlier quoted context omitted.

The ones I have used (IntelliJ, Netbeans and eclipse) were quite effortless to jump between. I doubt Visual Studio will be much harder. Jetbrains covers Ruby, Python, JS, C and more and it would surprise me bigtime if those language specific versions aren't quite similar to the plain Java version as well.

I think Vim is far easier to learn than Visual Studio. The menus are completely unintuitive, bureaucratic and painful to use. I always use cl.exe from the command line with Makefiles.

Why not stop using the menus then? ;)

Visual Studio can be operated pretty much entirely from the keyboard. The default shortcuts are fairly sensible, and you can always add more from the options.

There is one major omission: changing build configuration or build target. (You can give the configuration manager a keyboard shortcut, and do it that way, but it's a bit unwieldy.) So I keep the relevant widget in the toolbar and use the mouse to do it. And there are a few things I haven't bothered to assign keyboard shortcuts to, on account of how rarely I use them.

But in general, I use the keyboard to perform actions, and it doesn't feel like I use the mouse any more than I do with emacs (which I use without scrollbar, toolbar, or menu bar).

I do use the mouse a lot for moving the cursor and selecting text in both cases. (Visual Studio is actually slightly better for this, because you can Ctrl+drag to get word selection.)

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

#102

Post by Nadya »

keepper wrote: post #11

I'm sorry... but "kak"? I love/like vi[m], I love/like emacs... I ... never mind lol The new editing language does look great, and I like the idea of the piped filters... but I can't get over the name :-/

Which is funny, I read it as 書こうね (Let's write). Even fits in line with the growing fad of using Japanese in project names I've noticed the past 8~14 months or so.

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

#103

Post by marktangotango »

notheguyouthink wrote: post #52
reitanqild wrote: post #46

A better vim sounds great. That said I suspect most people would be better off learning a good IDE properly, including but not limited to: * effective navigation and selection using modifier keys and search * built in refactoring * project wide as well as single file search/replace, -and this includes regex search AND replace. This should be quite doable in less than a week compared to a few months to get equally eff…

> That said I suspect most people would be better off learning a good IDE properly, including but not limited to: To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people? Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get la…

The core "IDE" features you don't normally get with an editor are things like project views, intellisense, code completion as you type, real time parsing and error highlight, code navigation. Sure you can get most all of this by wrangling plugins for vim (or which ever editor you choose) but in an IDE like eclipse, netbeans, intellij, visual studio, it's all there, ready to go.

In effect, a modern IDE is "programming ability" multiplier. It helps me code smarter and faster. That plus understanding what's going on behind the scenes is a powerful combination.

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

#105

Post by JadeNB »

I generally pass over mentions of new text editors because they seem to be either orthogonal to what makes Vim great, or else to approach Vim with the approach that it's mostly wrong—think of Cream, for example, which seems more about onboarding newbies than appealing to experienced users (which is fine!). I think of Neovim as an improvement for Vim scripters and coders, while aiming to provide mostly the same end-user experience, so I haven't really bothered with it. I'd discounted previous mentions of Kakoune, assuming that it was more of the same, but this discussion (and in particular greenspot's deservedly top-rated comment https://news.ycombinator.com/item?id=13166784 ) made me take a closer look, and I think I'll give it a try.

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

#106

Post by notheguyouthink »

marktangotango wrote: post #103
notheguyouthink wrote: post #52

Earlier quoted context omitted.

> That said I suspect most people would be better off learning a good IDE properly, including but not limited to: To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people? Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get la…

The core "IDE" features you don't normally get with an editor are things like project views, intellisense, code completion as you type, real time parsing and error highlight, code navigation. Sure you can get most all of this by wrangling plugins for vim (or which ever editor you choose) but in an IDE like eclipse, netbeans, intellij, visual studio, it's all there, ready to go. In effect, a modern IDE is "programming…

Note, it sounds like Kakoune is trying to be a text and code editor first. Not just a text editor, like Vim is out of the box. Completion and code related tools appear to be first class citizens.

With that said, it's purely speculative on my part, i clearly don't know - Kakoune is new to me.

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

#108

Post by notheguyouthink »

JohnDotAwesome wrote: post #81
Cpoll wrote: post #77

Earlier quoted context omitted.

This sounds like macros? Of course, the problem with macros is that you sometimes realize you should have hit "Record" only after you've completed the action.

> the problem with macros is that you sometimes realize you should have hit "Record" only after you've completed the action. Happens to me all the time. But if using a macro was actually worth the effort in the first place, then it's probably still worth the effort to undo and record

Definitely. In fact because of that "blind actions" that Vim has, and Kakoune seems to be trying to fix, i often record macros multiple times. I'll make the macro, but the realize it doesn't fit all cases i wanted it to.

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

#109

Post by doppioandante »

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.

While Kakoune is mainly terminal oriented, it has an experimental json interface that while pretty basic can be used to implement a GUI to it.

I took a stab at it, and while it still needs half of the features to be on par with the terminal UI, it gives an idea of how difficult it would be (it isn't): https://github.com/doppioandante/kakoune-qml

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

#110

Post by kaoD »

omtose wrote: post #83
kaoD wrote: post #67

Earlier quoted context omitted.

Not sure I understand what you mean.

For example the fact that the terminal does not make any difference between and . Or and .

You know what? I was ready for bullshit and you actually gave a compelling answer :P Yeah, that's a bummer, but there aren't that many instances of that drawback (it's bitten me a couple times maybe in many years?) and on the other hand text mode gives a lot of convenience like being able to use it from SSH and other niceties.

Anyways, I don't think such behavior is inherent to "the console", only Linux's particular implementation (i.e. it's tty's fault) which admittedly is pretty outdated and relies a bit too much on control characters.

IMHO the original question still stands:

> What would a GUI bring to this that isn't possible in the console?

In my experience text mode brings a lot that GUIs don't, and not the other way around.

Plus it's easier to make a GUI wrapper for a console program than a console wrapper for a GUI program.

Post reply on HN