Live data from Hacker News

Neovim

github.com

211–220 of 372 posts

Re: Neovim

#211
post #47

Earlier quoted context omitted.

No, it doesn't work fine. LateX is slow, inconsistent and needs to be ran multiple times to give a correct result, it has no API, is not extendable in a sane way, it's source code is so arcane there's books written about it, and if you've read the books the only thing you've learned is that trying to reimplement LateX is a fool's errand. And it's syntax is ugly. Markdown is better. Microsoft Word is better. They just…

"A shell that instead of working on character streams worked on structured and annotated data streams, so it could intelligently interpret what is going on?" I'm not convinced that's worse, but I'm not convinced it's better for the task of being a shell . It's totally, unequivocally, way the hell better when you're trying to build anything large out of it, but taking everything back to byte streams at the interfaces…

This sounds like PowerShell

Re: Neovim

#212
If you can make Vim seamlessly work with a REPL then this would be worth me upgrading (if all my current vim plugins still work).

It's the only reason I use Emacs + Evil + trying to get it to be as close to a Vim clone as possible. You know how cool it is to type ":" instead of M-x?

Re: Neovim

#213

As someone who uses Vim to write articles and documentation in addition to code, I'd really love to see a richer UI with proper support for features like variable-width fonts. It looks like the developer behind this refactoring effort has some really good ideas for decoupling the Vim engine from the user interface layer. It'd be great if somebody could build a really good cross-platform Qt-based UI on top.

"I'd really love to see a richer UI with proper support for features like variable-width fonts." Would the variable-width fonts be simply for display with plain text being edited and buffered, or do you wish to be able to have rich text formatting within the editor (e.g. italic, bold, smart quote marks &c)? Just interested: rich text formatting has been suggested for emacs I recollect.

By none other than rms himself.[0]

[0]: https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00...

Re: Neovim

#214

Earlier quoted context omitted.

That's a fair argument. Neither Golang nor D give you the control that C gives you. If that's your yardstick, then the only viable candidate at this point is Rust. But Rust doesn't feel or look anything like C, but more like C++ or maybe Scala.

Its not just the lack of control, the bigger problem is features that have been added in. There major use cases for C that go by its nature can not fill. It can not do bare metal programming or real time applications without major changes to the language standard. Go aims to be a superior system programming language than C but not a successor to C. No one will be doing audio codecs or device drivers in go, but I woul…

> It can not do bare metal programming or real time applications without major changes to the language standard.

TIL that these are required for text editors and related tools.

Re: Neovim

#215

Earlier quoted context omitted.

If you are comparing Word and Markdown to LaTeX I think it's clear you haven't really used LaTeX.

Oh get over yourself. Every one of the criticisms he levelled against latex is spot on, and you pick up on the fact that he mentions Word is easier to use (which, by a long, long way, it it).

I hardly think so. Let's address them:

> "LateX is slow, inconsistent and needs to be ran multiple times to give a correct result"

It is not slow, it runs in under a second on most documents I have authored.

> "Inconsistent"

I'm not sure what tinco meant by this, but it does in fact return the same results for the same file across multiple runs.

> "Needs to be run multiple times to give the correct result"

This is true for things like references, etc. However, this proves to be a non-issue in practice as you are recompiling so often to view changes that references are always up to date.

> "It's syntax is ugly."

I don't see how learning LaTeX is different from learning any other programming language. I don't think that many C++ gurus would call C++ "ugly". Calling a progamming language "ugly" is often the last argument you see when someone couldn't come up with a decent argument against it.

Re: Neovim

#216
post #99

Earlier quoted context omitted.

I think you miss a major thing here: if you put vim with just it's top 100 plugins up against Sublime Text, I think it will easily lose. Why would I even use that? It's because of the long tail of thousands of plugins (your 1% usage) that I choose vim/emacs (more specifically, each power user chooses it because of the set of many of those top 100 hundred plugins + a handful of weird, obscure plugins that fit their ne…

Maybe I'm wrong. I don't think I have any non-top100 vim plugins installed. I could be underestimating the problem by a large margin. I sort of think that if just the top 100 plugins would be compatible, the authors of the non-top100 plugins would be motivated to migrate, as a sort of herd mentality thing.

This is the same kind of short-sighted programmer selfishness that leads to idiotic ideas like "let's abolish time zones and just everyone use UTC". Do you realize how many man-years of other people's time and effort you're proposing to spend adding zero value to that software?

Re: Neovim

#217

Earlier quoted context omitted.

Oh get over yourself. Every one of the criticisms he levelled against latex is spot on, and you pick up on the fact that he mentions Word is easier to use (which, by a long, long way, it it).

I hardly think so. Let's address them: > "LateX is slow, inconsistent and needs to be ran multiple times to give a correct result" It is not slow, it runs in under a second on most documents I have authored. > "Inconsistent" I'm not sure what tinco meant by this, but it does in fact return the same results for the same file across multiple runs. > "Needs to be run multiple times to give the correct result" This is tr…

Inconsistent probably refers to the fact that there are subtleties that can mess you up, once it works you are fine, but you may have a blocking issue on the way.

Syntax is important, remember he is comparing it to Markdown, not C++. C++ is certainly ugly and should not be used as the basis for any comparison, certainly not for a word processor.

I think he is just pointing out that general theme amongst these tools. They work for the people using them well enough, so they stay that way forever. It isn't that features aren't added or that they stagnate, it is just that thinking outside of the box is impossible.

Re: Neovim

#218

Earlier quoted context omitted.

>You're confounding usability with "do not need a manual". They're not the same thing at all. Moreover, I reject entirely your assertion that vim is not usable. If by usable we mean "one can be productive in it" then yes that's correct, vim is immensely usable and I've been using it in that sense for six years. That however is a facile definition of what most people typically mean when we speak of 'usability'. A tool…

> If by usable we mean "one can be productive in it" then yes that's correct, vim is immensely usable and I've been using it in that sense for six years. Usable means an interface which is (i) consistent and (ii) well suited to the task at hand. It does not mean you should not require any training nor that you should be able to intuit the functionality without looking at the manual. vim is an example of software that…

You have to admit, compared to most any tool out there, vim has one of the worst newbie experiences, given its popularity.

Even a terminal window allows you to type help to get something to work with. VIM replies with "Left, end of word, Right, paste after" which in most cases is nearly a NOP.

I believe what he is trying to say is that it would make sense to figure out how to make the initial experience less daunting without giving up the power it provides.

Re: Neovim

#219
post #201

Earlier quoted context omitted.

i so wish any of the terminal emulators in osx had the scriptability that urxvt has. i miss it all the time :/

I've been frustrated by the lack of iterm2 features in Linux terminal emulators: local autocomplete, tmux integration, etc

I've been frustrated with the lack of Konsole in any other term emulator.

Re: Neovim

#220

Earlier quoted context omitted.

I used to use zsh (including a giant, customized zshlovers .zhsrc) but I switched back to bash when I started administrating a few different servers. There's just something to be said for feeling totally comfortable and productive with a default environment. I'm also quite comfortable using plain old vi -- something a lot of other vim users can't stand.

Bash has also come a long way recently. I suspect a lot of the excitement over zsh comes from mac users who are stuck with what is now an ancient version of bash.

as long as bash doesn't get the terminal sizing 100% right all the time (and thus display proper entry line/prompt all the time), I'm not going to use it. It always happens eventually, if you spend along time in the shell. There used to be a myriad of little bugs causing this. Not sure how many are left now.
Post reply on HN