Live data from Hacker News

Neovim

github.com

221–230 of 372 posts

Re: Neovim

#221

Earlier quoted context omitted.

> 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…

The first thing that shows up in a VIM session is a small introductory text that includes

    type   :help  or     for on-line help
And of course the GUI also has the familiar Help menu as most common GUI apps.

Re: Neovim

#222
post #220

Earlier quoted context omitted.

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.

I spend pretty much all day every day in the shell and haven't had problems like that in a long time. I think maybe because at some point the checkwinsize option got turned on by default, at least on ubuntu.

Re: Neovim

#223

I applaud your effort but I worry that this step is not far enough to make a better version of vim. However I really think that we can do better and the famous, great editors (vim, emacs, acme, etc.) all have different features that make them great and unique. I prefer vim because of its modal nature which might be the reason why I find it also ergonomically superior (after remapping ESC to jf) - e.g. I don't like it…

Lime text fits this description I think.

Re: Neovim

#224
post #66
post #59

Earlier quoted context omitted.

I do what I want. Also, LaTeX is a system for creating documents, and Word is a system for creating documents. There's only four important differences: Word has a more modern architecture, Words compiler is integrated into its GUI, Word is closed source, Words source format is not human readable. Apples to Oranges? I can compare these Braeburns to those Fujis just fine thank you.

If that is all you need and expect from a replacement for LaTeX, why aren't you just using LibreOffice?

If we're talking about LaTeX, Word, Markdown and LibreOffice - well, then LibreOffice is a contender for the worst usability, it's superficially similar to a mature product but it's a case of "the remaining 10% of goodness will take more work than the first 90%".

Re: Neovim

#225

Thiago if you read this, please do your fundraiser a favor and mention all the work and review that went into your thread safe message queue already. There is a lot of skepticism about your capability of delivering, but i think it's clear that you already have the experience needed.

To make sure that your message does reach him, try to reach out directly.

His contact information is here:

http://tarruda.github.io/

Re: Neovim

#226
post #29

Thanks for trying to do what many of us secretly wished we could do but can't because of time/skill constraints. I will definitely move to NeoVim the second it's packaged (is it yet?), regardless if you've changed anything yet. I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. There is nothing holy about Unix era software, chance…

> (Yes, it gives me shivers just thinking about how much each of those technologies sucks when you think about how good it all could be.)

I can tacitly agree that using vim running in a terminal to write LaTeX is not the easiest way in the world to write LaTeX.

However, terminals do not suck. Bash sucks a bit, vim sucks in ways this project aims to fix, but terminals are absolutely awesome.

A terminal is a dead-simple API for interacting with the user. Want to display text? Write to fd 1. Want to read some input? Read from fd 0. Want to control the cursor or change the colour? Write a special sequence of characters to fd 1, that's supported by every regular terminal emulator. There is even support for getting mouse events. Yes, it's text-only but that is enough in a lot of cases. And it's very simple. And you get it for free the moment your program starts. There is no opening connections to X, no initialising GUI libraries, no callbacks, no need to design a GUI. It's just there. It's always there.

Try coming up with a GUI system that has an API as simple as that. The only thing I can imagine is something that consumes HTML written to fd 1 and renders it nicely. But note that HTML can and will be malformed, and malformed HTML can and will be parsed differently by different "HTML terminal emulators". Plus, if you want to do that, just write javascript and stick it in a .html file.

Re: Neovim

#227

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…

>>> "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.

Slow? I don't know about that, but compared to what? Even in word it does need some time to reach the "Save as PDF" menu, right?

>> "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.

Well, there is some truth about this. There is an odd naming scheme if you look at stuff like "enumerate", "itemize" and "description" - beginners get confused by this as they assume it would be called "describe". The same goes for most of the packages. This is somehow historical, but I think it also makes it unnecessary hard to figure out LaTex for beginners, right?

Also the reason why LaTex needs several runs to finally create the full document. Nowadays you would do this differently I guess as there is simply no need to start the program twice if the application would be smart enough to call sub-programs (like biblatex) by itself on the fly. It would still run the same routine several times, but users wouldn't see it and it would be one command for them to build the document. That's another point beginners tend to go crazy about :)

Having said that, I should add that I'm using LaTex (and XeLaTex, etc.) daily and there isn't a single program matching the power and beauty of it - I even design covers for my publications with it. But I'm able to use vim and emacs, right? 90% of the people are bloody beginners and it would be a shame to hide the beauty of a LaTex document from them.

>> "It's syntax is ugly."

Yeah, well...ugly is a bad term to discuss about. I like it and I think the syntax is way cleaner than reStructured text :D

Re: Neovim

#228
post #123

Earlier quoted context omitted.

Those are just the surface differences. The modes in which you use all of these are very different. Word: explicit WYSIWYG control over typesetting. LaTeX: semantic level control over typesetting. Additionally provides explicit low level typesetting commands. Markdown: given how basic (trivial even) Markdown is ( http://daringfireball.net/projects/markdown/syntax ) I'm not sure why it's even in this list.

It's in the list because it's what I would use for my thesis, if I'd do one now :) It's basic, but it has the semantics for most stuff, and can easily be extended for more. I'd do all formula's/drawings in external tools. Word nowadays has semantic typesetting controls too, I think since they started that ribbon thing that it has become useable. If you stick to using their semantic things I think you can do a pretty…

Check out pandoc [1], it will let you write documents in Markdown + LaTeX for equations and then convert it to LaTeX, a PDF, or several other document formats.

Also, even though Markdown tends to be fairly easy to write, there are many edge cases where you can't really be sure what the result is unless you try it.

[1]: http://johnmacfarlane.net/pandoc/

Re: Neovim

#229

Earlier quoted context omitted.

Writing a thesis using only markdown sounds extremely painful. Are you going to create all your figures elsewhere and then include them as images? How are you going to create your list of figures? And your table of contents? How are you going to create, maintain, and organize your list of references? I could go on.

> Are you going to create all your figures elsewhere and then include them as images? This is what most people do in physics and astronomy. You make the plot in some kind of plotting package and export it to a vector format. In astronomy, the journals only recently started accepting PDF figures in addition to EPS. In my experience doing all of my figures in LaTeX is significantly more painful than using a real plotti…

I don't know your exact use cases but I am reallyfond of pgfplots which, being based on TikZ, integrates much better than matplotlib. But I also happen to hate matplotlib for sticking with "that" API ...

Re: Neovim

#230
Good to hear that vim development takes on some speed again. Please keep compatibility with existing vim plugins.
Post reply on HN