18 ms·

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'

by tinco 13y ago

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, chances are it's shit and a lot of it should be thrown out. Look at SublimeText, it's got 1% of the features of Vim, yet it's converting Vim users left and right, by its sheer usability. We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. (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.)

fournm 13y ago
I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim! The thing about compatibility is that it doesn't matter how great your new and shiny is if it can't talk to old things at all. Imagine the best new text editor in the world, but it's completely incompatible with every file format that's ever been written previously, even .txt! No one would use it, because the cost of switching is too high. In some cases, it's definitely worthwhile to have some development pain to keep that around. Stuff like keeping vimscript (and therefore the entire ecosystem around vim) functioning means that neovim could be a drop-in for some people, and HAS to be preserved at least partially. Stuff like keeping ancient Amiga support or integration with Sun workshop? Definitely not worth it anymore.
- tinco 13y ago
  I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim! This is the part where people are surprised, but I am an extremist. I definitely think backwards compatibility should be among the lowest priorities when making decisions on improving software, especially and perhaps just, in Open Source. Just think about it. What happens when we decide a certain core feature of Vim is archaeic, and could be implemented in a more modern, more flexible, more loosely coupled way. First, every vim plugin would break. But if you look at how many Vim plugins are actually used, I would be surprised if the top 100 Vim plugins covered less than 99.99% of all Vim users. That means we only have to upgrade 100 Vim plugins, and probably just a couple of lines if they're written well. How much technical debt have we accrued now, that in reality could be paid off just by biting the bullet and going through a hundred pieces of software and changing a couple of lines? This is open source, we could just do it. (tm)
  - riffraff 13y ago
    The problem is you broke compatibility now. Will you do it again next year, and fix 100 plugins once more? I am also not a big fun of extreme forms of compatibility, but plenty of projects try to break it only to have people which stick around with old versions for years.
    - tinco 13y ago
      Big projects like Python only break compatibility once every few years, and a lot of thought goes into it. I think it's a lack of respect to the authors of Python and perhaps a lack of authority of Guido that packages are not being upgraded to Python 3. I wonder what would happen, if just a few companies that actively use Python, like Google, would hire a few devs that for a year would only fork and fix Python 2 projects. Wouldn't it just solve the problem? I bet they'd be done within a couple of months too, and they wouldn't even have to be super senior types.
      - jnbiche 13y ago
        Almost all major Python packages have now been upgraded to Python 3. For example, only 3 or 4 of the Top 50 have not been upgraded, and all but 1 of those are in the process of updating. It's now mostly just the thousands of smaller packages that still are on Python 2 only. But Python couldn't get away with that more than once every 10 years.
      - GFK_of_xmaspast 13y ago
        Maybe I would have upgraded to python 3 by now if I saw any compelling reason to do so (like, say, getting rid of the GIL).
  - roel_v 13y ago
    As a user of software - fuck you, and may you never touch anything I use. It's juvenile oo-look-shiny nonsense like this that makes us people who just want to get shit done waste yet another afternoon on patching working stuff after a (forced) update because some wet behind the ears dude decided that everybody before him was a utter moron. There is a reason people pay for software that just works, and will work for the next few years. It's because they're fed up with being the guinea pigs for architecture astronauts and code purity fetishists. Also, "that means we only have to upgrade..." Who is "we" here? You? Of course not, you're too busy chasing the next fad, while the rest of us have to repare shit just to make it do again what it aready did before.
grannyg00se 13y ago
So Sublime text provides a 99% feature loss but a great usability gain? Can you explain that a bit?
- jamesgeck0 13y ago
  I don't think anyone would argue that Sublime Text has a much nicer GUI than anything Vim has. It's just lots of little things, like how scrolling is smooth and quick, not entire lines popping into/out of view. The zoomed out source map is also nice. It's also ever so slightly snappier. Vim seems to be ever so slightly less responsive when I have several panes open.
- tinco 13y ago
  Well, I can explain how I use it. I have my Sublime in legacy mode, which enables some vim like controls. And I benefit from Sublimes super fast text rendering, it's nice fonts and colors, the way it integrates with my desktop environment, how fast it interacts with plugins that spawn popups and analyze my code. And then every once in a while I need to do some cool text transformation, and it doesn't work, so I launch a terminal, edit the file in Vim and work my magic. Then I exit Vim and continue in Sublime. Ideal? No.. but it's the usability of Sublime with the features of Vim.. every once in a while..
  - NAFV_P 13y ago
    > And I benefit from Sublimes super fast text rendering, it's nice fonts and colors, the way it integrates with my desktop environment, how fast it interacts with plugins that spawn popups and analyze my code. The sentence quoted above sounds a lot like something out of a product promotion.
    - oblio 13y ago
      Well, when users are doing that, you can be sure that the competition will be in a world of pain!
- badman_ting 13y ago
cicero 13y ago
I don't see anything shameful about using old software if it works well and suits your needs. Yes, new editors like SublimeText have advantages, and if you prefer them over Vim, use them. However, I've seen many projects undergo a rewrite in order to move to new technology, but they never matched the utility of the old technology they were trying to replace. I'm not saying it can't happen, but that it often doesn't. I don't use Vim much now because I work a lot in Windows, and Vim got me into the habit of hitting escape when I was through entering text, but escape cancels the input in a lot of programs. However, I still use it in the shell or when I need to make certain global edits. I wish Neovim great success, and I might use it someday if it meets my needs, but not just because it's new technology.
- philsnow 13y ago
  > Vim got me into the habit of hitting escape when I was through entering text, but escape cancels the input in a lot of programs. Does ^[ cancel input in any programs ? AFAIK vim understands the ^[, not the "escape key". the key labeled "ESC" creating a ^[ is a convention used in terminal emulators. Not that it's going to help you now, but if you had trained your fingers to hit ^[ rather than the escape key (or even ^C but that has other semantics in windows whereas I don't think ^[ does), I wonder if you would be having the same problem now..
  - Crito 13y ago
    ^[ just generates ASCII character 0x1B, aka Escape. Vim understands "escape" to be 0x1B, pressed by itself (not as part of a longer escape sequence).
  - gpvos 13y ago
    Not practical. ^[ is a two-key combination, so more RSI-inducing. And you need escape a lot, especially in plain vi. And the ESC key has been generating ASCII 27 on keyboards for a long time. It's definitely not just terminal emulators.
- tinco 13y ago
  Sorry, I didn't mean you should be ashamed about using old software. What I meant was that we should be ashamed that other people are using old software. I am helping my girlfriend to learn Javascript, and it hurts inside that every once in a while she gets confused with something I have to explain her it's because the author of the language made rookie mistakes/dumb decisions 20 years ago.
glesica 13y ago
> ...should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. First, why? It works just fine. Second, is there anything better? I don't know of anything I would prefer to use. So until someone comes up with something, I'll stick to using Vim to write LaTeX in a Bash shell (might upgrade to zsh, we'll see).
- tinco 13y ago
  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 both lack certain things we need, and LaTeX has those things. Could you not envision things could be better? A LaTeX that parses to an in-memory tree so it could be transformed before compilation? 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? An editor that does have at its core an expectation that its output is ASCII character commands controlling a 1970s terminal interface? Of course you'll stick to using Vim to write LaTeX in a Bash shell, I do too. Doesn't mean I'm not mad about it..
  - robinhoodexe 13y ago
    "Markdown is better. Microsoft Word is better." Stop comparing oranges to apples. And there's really no "objectively better", it's two different tools with two different uses. Sure, LaTeX could be better, but it's been working on.
    - tinco 13y ago
      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.
justinmk 13y ago
This should not be the top comment, it is a rant that misses the point. Neovim maintains backward compatibility where it makes sense to do so. Neovim is NOT a rewrite, it is a thoughtful refactoring that aims to achieve one of Vim's _original_ goals: first class support for embedding. And better interoperability.
- tinco 13y ago
  I think you miss the point of my rant :P I'm not saying everything should be rewritten (though I do believe everything in C should be rewritten in C's successor which doesn't exist yet), but I'm saying Vim has gone too far in maintaining backwards compatibility, and if it would have improved interoperability, even at the expense of some backwards compatibility.
  - jnbiche 13y ago
    >I do believe everything in C should be rewritten in C's successor which doesn't exist yet Both golang and D have a reasonable claim to being C's successor. People often think of D being a nextgen C++, but to me it has much more the feel of a C with garbage collection and batteries included. And golang definitely feels like a modern C, at least to me. And that's what Rob Pike had in mind, as well. PS: Had to use Word every day for years for my job. I despise it, and love vim. Vim keyboard navigation would have made my life so much easier when working on Word, and saved me several severe episodes of carpal tunnel. Luckily, I no longer have to use Word.
    - nousernamesleft 13y ago
      Go has absolutely no claim to being C's successor. It is useless for all the things it makes sense to use C for. That's why it has attracted virtually no C programmers. Go is python's successor if user influx is anything to judge by.
      - jnbiche 13y ago
        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.
chongli 13y ago
We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. What?! You can take my vim+bash+tmux+urxvt when you pry it from my cold, dead hands!
- rjzzleep 13y ago
  i so wish any of the terminal emulators in osx had the scriptability that urxvt has. i miss it all the time :/
  - lepht 13y ago
    I've been frustrated by the lack of iterm2 features in Linux terminal emulators: local autocomplete, tmux integration, etc
    - zobzu 13y ago
      I've been frustrated with the lack of Konsole in any other term emulator.
- slashnull 13y ago
  > 2014 > not zsh
  - dijit 13y ago
    >implying >not on /g/
  - chongli 13y ago
    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.
    - 13y ago
NAFV_P 13y ago
> Look at SublimeText, it's got 1% of the features of Vim, yet it's converting Vim users left and right, by its sheer usability. I just looked it up, $70 is way out of my pay range. I'll convert when I have a full-time job. > We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. Yes, you should be ashamed.
- nicklovescode 13y ago
  You can use the free version. It's full featured but has intermittent alerts asking you to upgrade[0]. [0] Recent vim convert.
  - bmj 13y ago
    Sublime is only free-as-in-beer. Some use vim because it is also free-as-in-speech.
    - nicklovescode 13y ago
      "I just looked it up, $70 is way out of my pay range. I'll convert when I have a full-time job."
gradstudent 13y ago
> Look at SublimeText, it's got 1% of the features of Vim, yet it's converting Vim users left and right, by its sheer usability. 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. vim is amazingly usable; text manipulation commands for example all follow a common structure: [action][times][position]. That means the rules you learn for using "yank" apply just as well to "delete" or "paste" or whatever. Anytime you encounter a new text command you don't even need to wonder how to use it; it's a sure thing it will follow the same structure that you already know.
- rjzzleep 13y ago
  not too mention that vim became hip only in the last couple of years. saying it's converting vim users left and right is a little far fetched. most of those users never had any real vim muscle memory to begin with. a lot of "vim" users i saw work just fine without motion commands. the only reason they used it was because they could use it anywhere. whether it's modal or not is totally irrelevant to them.
  - jude- 13y ago
    > not too mention that vim became hip only in the last couple of years. Wait, what? Vim has been in use for a lot longer than that (it was released in 1991), and vi even longer (1976).
    - andrewflnr 13y ago
      "Hip" does not mean remotely the same thing as "in use".
      - deleted 13y ago
        [deleted]
    - AliceWonder32 13y ago
      Yes but emacs was for more popular than vim for awhile.
terminus 13y ago
> We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. (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.) Let's deconstruct each of the pieces we are supposed to be ashamed about, shall we. LaTeX the language: a wrapper language built on top of TeX for typesetting documents. The idea being to specify higher level document logic (for instance sections, subsections, paragraphs, tables) and if all else fails, then fallback to explicit placement commands. I fail to see anything to be ashamed of in the idea. And, as for your complaints about extendability in some of the comments below: maybe you should look at the texlive distribution or PGF/tikz here: http://www.texample.net/tikz/ http://www.texample.net/tikz/) LaTeX/TeX compiler: that's a fair point. But, doesn't have much to do with the language. vim: a text editor wrapped around using the keyboard efficiently, similar in idea to LaTeX the language in that it asks you to express yourself on a higher plane. Neovim is essentially a more maintainable repackaging of the same model keeping extendability in mind. bash: wrapper over the early Unix model pipes, ttys, processes (and not threads) etc. The bash scripting language is not all it could be. But, as I said before, the basic model is fairly tied up with Unix itself and is similar in zsh/fish etc.
- jrk 13y ago
  (My post got long, so I've put a standalone version, with better markup rendering, here: http://gist.io/9161898. http://gist.io/9161898.) [TikZ] is a perfect example of TeX's missed potential: it is an outstandingly well designed DSL for diagram creation, embedded in an insane macro language. The moment you try to do anything nontrivial that exploits the programmatic (rather than purely declarative) nature of TikZ you immediately run into wall after wall trying to express basic programming concepts in the host language, TeX. For example, two common patterns I have seen frequently arise as perfect uses for a programmatic diagram description: - using computed coordinates and transforms to construct complex paths and diagram layouts from the composition of basic geometric reasoning; - using abstraction to tersely encapsulate common visual components, both for simple iteration over many similar components, or for higher-order encapsulation of parameterized diagram logic. In both cases, you quickly run face first into fundamental limitations of TeX as a programming language. In particular, it is extremely painful to use for either arithmetic or control flow. This is a big enough deal in practice that core among TikZ's features are custom inline arithmetic syntax for coordinate computation, color blending, etc., and a custom `\foreach` macro, both defined not in the language, but provided as part of a specialized diagraming library, because they are fundamentally at odds with the design of the core TeX language. Even this impressive bit of TeX engineering still breaks down as soon as you try to do much more than iterate over a hard-coded constant range. (How much do you need to bracket, `\relax`, etc. the operands of your `\foreach` if it is used inside of a macro definition? Or if they are the result of computation, even as simple as basic index evaluation like `\x+1`? Now what if you want to iterate over a range which results computed in part using floating point arithmetic using one or another library?) TeX suffers because it is at once both a relatively awkward markup language (relative to something like Markdown) and an extremely awkward programming language. Many tasks which would be trivial in any mainstream programming language are outrageously challenging and arcane in TeX. The LuaTeX effort to embed a sane, modern programming language much more centrally into the core of the TeX runtime is a fruitful direction, but it still does little to better formalize or structure the various levels of document representation for programmatic transformation: we still have a giant stack of TeX macro complexity, ultimately expanding down to very low-level page rendering descriptions, just now with the ability to register Lua callbacks at various points along the way, or use Lua scripts to generate new tokens during the expansion process. As a clever, minimalist hack, the single-pass macro expansion semantics at the core of the language were a great way for one man to bootstrap a complex typesetting system. As an expedient hack to build an incrementally more humane document generation system atop the powerful low-level typesetting engine already available in TeX, LaTeX got a lot of mileage for relatively little cost. As an intermediate representation for modern typesetting systems, TeX could be a reasonable higher-level alternative to something like PostScript (which few bother to write by hand, but is a great low-level page description language, particular as a target for machine generation). But as either a primary programming language or a human-facing markup language, TeX is a terrible fit. Worse, the extreme difficulty of doing anything parametric in TeX makes it a bad fit for a future of many display formats and adaptive (responsive) layout, where baking tools focussed on baking a single paginated output format are less and less relevant. The evidence for how different the world could be is not given by plain Markdown for comment boxes—that is, indeed, an apples to oranges comparison—but by the power that comes from creating an extensible and programmable document transformation system based on a well-defined document grammar (which is, in fact, a recursive data type, not tied to any one front-end syntax). That's the heart of [Pandoc]. It's not just "extended Markdown" or "a markup format converter," it's a powerful framework for document transformation, which naturally supports humane markup, while also allowing extreme extensibility via general-purpose programming languages. See the [scripting] documentation to get a sense for the model of extensibility, then recognize that this same document representation is the core of every translation and transformation Pandoc does, and how this model enables many of the same things as TeX's macros, but in a far more structured yet also programming-friendly way. [TikZ]: http://www.texample.net/tikz/ http://www.texample.net/tikz/ [Pandoc]: http://johnmacfarlane.net/pandoc/ http://johnmacfarlane.net/pandoc/ [scripting]: http://johnmacfarlane.net/pandoc/scripting.html http://johnmacfarlane.net/pandoc/scripting.html
jude- 13y ago
> I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. Please clarify by what is meant by "backwards compatibility," since this is a loaded phrase. On the one hand, it's the idea that software system B can do everything that earlier software system A can, using the semantics of software system A (e.g. "vim can do everything vi can, using the semantics of vi"). On the other hand, it's the idea that software system B is semantically incompatible with software system A (e.g. SublimeText vs vim), but software systems A and B can coexist without breaking each other. While I agree that achieving the former idea of backwards compatibility isn't always important (particularly in the realm of text editors), achieving the latter is an absolute must. If there is one thing I will not tolerate on my systems, it is a piece of software that breaks other working software that I rely on. > There is nothing holy about Unix era software, chances are it's shit and a lot of it should be thrown out. Like it or not, we're still in the Unix era, and likely will be for some time. Unix is more than a specific implementation or even a specific API--it also includes the logical abstractions behind them. You still deal with files, directories, processes, threads, pipes, sockets, dynamically-linked libraries, paging, etc., whether you're on Unix or Windows. This means SublimeText is "Unix era software" too--it's built on top of the same Unix-era abstractions as vim. Perhaps the only Unix abstraction vim makes use of that SublimeText does not is the TTY, but that doesn't stop me from using vim where TTYs don't exist. And you're right, most Unix era software is shit. But don't limit yourself to Unix era software--most software in general is shit. Very few pieces of software become as robust and widely-used as vim, and SublimeText isn't going to make vim disappear anytime soon (especially since it doesn't break working vim installations). > We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. Feel ashamed of me then, since I do exactly this. Why? Because there isn't anything sufficiently better for what I need to do. I have given every single WYSIWYG editor that claims to do a better job a good-faith trial, and I have always gone back because each contender always lacked the ability to do something I needed to do. I'm not saying it's impossible to do better; it certainly is. It's just that I've seen nothing that actually is better. I would address this myself, but I have too many other, more important things to work on (like finishing my PhD thesis). > (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.) Code doesn't write itself :) Software systems don't design themselves either :) What you're asking for is a very, very tall order. Many have tried to replace that which is "good enough," and yet we're still in the Unix era despite their efforts.
Arnor 13y ago
I can't believe I read this whole thread... I need to go take a shower now...
chadillac 13y ago
ring ring ring "yeah, what's up?" "Nagios is paging, something with that code you pushed live a couple hours ago is throwing a fit... looks like half the web cluster is on the verge of going to swap, can you look into it? asap!" "Well, I'm on at the bus stop and won't be near a computer for at least an hour...yeah, I'll sort it out, will text you when we can push fix live." pulls out Note 3, shitty 3G coverage connects to VPN ssh into dev env with connectbot switches to hackerkeyboard for input mode screen -dr dev Ctrl+c, tail join IRC channel that dumps syslogs from production cluster sees error Ctrl+c,vim the/file/causing/the/unexpected/problem fix, :wq git stash, git pull, git stash apply, git commit, git push Ctrl+d, exit sends text message "good to go!" deal with it.
- yen223 13y ago
  Moral of the story: Vim is very good for deploying fixes from bus stops.
  - chadillac 13y ago
    ‰s/bus stops/everywhere/g
  - devcjohnson 13y ago
    Moral of the story: This post has devolved into inane commentary.
- pjmlp 13y ago
  Better, mobile off. Fix issue in the morning when back on office.
- tinco 13y ago
  git commit -m "Always commit your changes first!"; git pull --rebase; git push And I use tmux, it's more modern ;) I like the syslog into irc thing, that's neat. By the way, I recently made a commit in the Github web interface while sitting on the toilet. No posix stack required ;)
anon4 13y ago
> (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.
_cipher_ 13y ago
> We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. I agree. Bash sucks. ;)
pjmlp 13y ago
I fully agree. For me, Vi and Emacs are only when I don't have an option in terms of IDE support, even though I know at least Emacs quite well. What can I say, the world of Amiga GUIs, Smalltalk and Lisp environments spoiled me as an IDE fanboy. It baffles me why in 2014, some developers still prefer to work as if UNIX System V had just been released.
- dmytrish 13y ago
  What features does an IDE give you?
  - pjmlp 13y ago
    - Visual representation of the code structure - Ability to select any symbol and find semantic uses of it - For OO code, being able to visuallize the OO graph usage of certain symbols - Refactoring across the whole project with semantic knowledge (no, search/replace does does not cut it) - Navigation in third-party libraries deployed in binary format - Code completion for static/dynamic languages, while showing tooltip documentation - Graphical visualization of data structures on the debugger - Background compilation with static analysis - unit test debugging infrastructure - integration with modelling tools - integration with SCM tooling and being able to interact with them directly from the editor. For example, generating a blame file, with navigation across the file revisions. - integration with continuous integration servers - integration of developer workflow with task management servers As an example of such developer workflows, have the IDE talk to Jira, edit the code, automatically bundle it in a workflow that binds the code changes to the Jira issue being worked on, get a Jenkins notification after the code is checked in and gone through the CI system. Sure you can get part of it in Emacs, after spending a week configuring plugins, with different levels of maturity, and in the end it is still mostly textual.
- markdennehy 13y ago
  > It baffles me why in 2014, some developers still prefer to work as if UNIX System V had just been released. Because (a) some of us aren't convinced that things like IDEs give a better view of what's going on in the system; (b) some of us think that fundamental tools like terminal emulators, editors and so on should be debugged and stable because we have to earn our mortgage payments using them and chasing the shiny isn't on our job description; (c) any actually useful new idea winds up in Vim anyway. You want to use a new shiny unproven editor, grand, have a ball. But don't ask me to purely on the basis that it's not new and shiny.
keerthiko 13y ago
I am honestly amazed at how feistily every 'hacker' here is defending LaTeX in response to your comment. I agree with you for the most part. This whole "it's apples to oranges" claim is bullshit. Both Word as well as LaTeX can be used for anything from writing a resume, making a technical paper with a few simple equations, to writing an entire Vector or Linear Algebra textbooks. When you have two options for doing the same task it's very much comparing apples to apples. Yes, they each were originally built with different objectives and different target markets, but they have since aspired to be usable for all the same things. Of course, they each have their strengths and weaknesses. But I don't get how do a bunch of folk here feel justified in arguing against someone saying "there's room for improvement" with clear viable suggestions on the details too. I know that hating on MSWord (or MS-anything) is fashionable on HN. But you can't seriously be defending * the steep learning curve: throw your 14-year-old who's doing a math assignment Word vs your favourite LaTeX editor, see what happens; * lack of WYSIWYG-like feedback-loops: you have to wait a full minute on decently sized documents to see the result of adding that equation that took you 10 seconds to add; * syntax holdups: you miss an underscore and your document is broken. All the way through. And can take an hour to fix even if you're skilled. People writing documents that need LaTeX's power aren't always coders, and debugging is not a fun or planned-for activity for anyone. I also don't for the life of me see why someone has to "be an expert, not just written a couple documents casually in undergrad" to be able to comment on the flaws of a product. They're as much a user as a power user, and obviously the power users went through that stage too. Losing sight of your past difficulties (or being gifted in LaTeX) doesn't make them irrelevant for people not in your current position. Loosely relevant: I smell hardcore "hacker entitlement" around people using LaTeX and defending it including all its stupid barriers to easy document-creation tooth and nail. Hardcore programmers do this with way too many things (like Linux, and development environments for almost any language). And it's just really frustrating for a lot of people to deal with =/ PS: NeoVim sounds like someone finally got off their high horse (or from whining) and decided to actually make something better. Thanks!
- anonymouz 13y ago
  > This whole "it's apples to oranges" claim is bullshit. Both Word as well as LaTeX can be used for anything from writing a resume, making a technical paper with a few simple equations, to writing an entire Vector or Linear Algebra textbooks. When you have two options for doing the same task it's very much comparing apples to apples. So can HTML. Would you compare Word to HTML? You can also write your resume in Notepad. Does that make Word comparable to Notepad? If you want to compare anything, compare LyX to Word. At least that makes some sense, even if the output of the latter just sucks in comparison to the former. TeX is at its core a typesetting engine. Word is largely a GUI markup editor. It doesn't even do anything coming close to typesetting. > * the steep learning curve: throw your 14-year-old who's doing a math assignment Word vs your favourite LaTeX editor, see what happens; Are you sure? Customizing LaTeX can be hard, but using it in a straightforward way is no more difficult than HTML. Sure, it may be a bit more work than using a GUI, but once you get the hang of it it's a lot quicker than Word's formula editor. > * lack of WYSIWYG-like feedback-loops: you have to wait a full minute on decently sized documents to see the result of adding that equation that took you 10 seconds to add; In my experience it's a lot faster than that. The reason for this is simply that TeX does actual typesetting. This has a certain computational complexity, and cannot just be done on a line-by-line basis. Word is fast because it doesn't do anything like that. Again, Lyx has WYSIWYM (What you see is what you mean), which gives you an approximation of the output instantly, minus the proper typesetting. > * syntax holdups: you miss an underscore and your document is broken. All the way through. And can take an hour to fix even if you're skilled. People writing documents that need LaTeX's power aren't always coders, and debugging is not a fun or planned-for activity for anyone. It more commonly takes a minute, not an hour. Every had Word corrupt a file and mess up the styles in the middle of your 150 pages document? That's not exactly a quick fix either. To sum up: If you want a WYSIWYM editor for TeX use Lyx. Otherwise, comparing LaTeX and Word makes about as much sense as comparing HTML and Word.
krick 13y ago
Oh, it's a real flamewar and people still seem to be here, so I want to add a little constructiveness to it. Vim, bash, LaTeX. Let's postpone vim, as the whole topic is [supposed to be] about it. And we have enough shells (zsh, fish) instead of bash, many people (me too) tried it and have chosen bash (although I use IPython quite often). And I don't know sane and fully functional alternative to LaTeX. (Markdown and co don't count as they don't have same control on output.) So let's stick with LaTeX. There are 2 categories of people: those who think that LaTeX is fine for its usecases and those who think that something is wrong and could be done better. Fine is fine, so lets concentrate on the second category. I'll recite main complaints: slowness, horrible syntax, arcane source code, impossibility to divide semantics from representation. (Did I miss something?) I guess many of us are able to program. So why somebody, right here, right now, wouldn't create a github/bitbucket repo, post link on it and explain, what exactly in your opinion could be done better? I personally would probably participate if somebody has a plan sane and explicit enough.
AliceWonder32 13y ago
Um, I've never heard of SublimeText. I like vim because it is cake to ssh into a server and quickly / efficiently modify a text file. And there is nothing shameful about developers accomodating my desire to use a command-line text editor to create/edit TeX files in whatever terminal I am using. Normally I create / edit TeX using LaTeXila but it is fanstatic that I can do so with vim and when I don't have access to LaTeXila I use vim for TeX editing, and I am quite glad I can. With software that works in a standard shell environment, I can ssh into a networked computer from my Android tablet (Better Terminal Emulator Pro and Hackers Keyboard) and do actual work. Far more convenient than carrying my laptop everywhere and also faster than checking out source, firing up a GUI, and then committing the source. Terminals ARE good technology and we would be worse off without them.
srik 13y ago
But I want to write on my text editor on a terminal emulator because I have access to all of the built in operating system utilities.
eyko 13y ago
"I hate the ideas many programmers have about backwards compatibility, unless it affects me." – FTFY > "There is nothing holy about Unix era software, chances are it's shit and a lot of it should be thrown out." 1. we're still very much in the "Unix era" 2. There's nothing holy about software at all. Rules shouldn't be broken, but rules can be broken. > Look at SublimeText, it's got 1% of the features of Vim, yet it's converting Vim users left and right, by its sheer usability. If anything I'd say Vim is converting TextMate/SublimeText left and right. Most SublimeText users are former TextMate, and many new Vim users are former SublimeText users. > We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators Speak for yourself. I don't personally write LaTeX but I still very much use the shell, and Vim.

by tinco 13y ago

fournm 13y ago

I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim! The thing about compatibility is that it doesn't matter how great your new and shiny is if it can't talk to old things at all. Imagine the best new text editor in the world, but it's completely incompatible with every file format that's ever been written previously, even .txt! No one would use it, because the cost of switching is too high. In some cases, it's definitely worthwhile to have some development pain to keep that around. Stuff like keeping vimscript (and therefore the entire ecosystem around vim) functioning means that neovim could be a drop-in for some people, and HAS to be preserved at least partially. Stuff like keeping ancient Amiga support or integration with Sun workshop? Definitely not worth it anymore.

tinco 13y ago
I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim! This is the part where people are surprised, but I am an extremist. I definitely think backwards compatibility should be among the lowest priorities when making decisions on improving software, especially and perhaps just, in Open Source. Just think about it. What happens when we decide a certain core feature of Vim is archaeic, and could be implemented in a more modern, more flexible, more loosely coupled way. First, every vim plugin would break. But if you look at how many Vim plugins are actually used, I would be surprised if the top 100 Vim plugins covered less than 99.99% of all Vim users. That means we only have to upgrade 100 Vim plugins, and probably just a couple of lines if they're written well. How much technical debt have we accrued now, that in reality could be paid off just by biting the bullet and going through a hundred pieces of software and changing a couple of lines? This is open source, we could just do it. (tm)
- riffraff 13y ago
  The problem is you broke compatibility now. Will you do it again next year, and fix 100 plugins once more? I am also not a big fun of extreme forms of compatibility, but plenty of projects try to break it only to have people which stick around with old versions for years.
  - tinco 13y ago
    Big projects like Python only break compatibility once every few years, and a lot of thought goes into it. I think it's a lack of respect to the authors of Python and perhaps a lack of authority of Guido that packages are not being upgraded to Python 3. I wonder what would happen, if just a few companies that actively use Python, like Google, would hire a few devs that for a year would only fork and fix Python 2 projects. Wouldn't it just solve the problem? I bet they'd be done within a couple of months too, and they wouldn't even have to be super senior types.
    - jnbiche 13y ago
      Almost all major Python packages have now been upgraded to Python 3. For example, only 3 or 4 of the Top 50 have not been upgraded, and all but 1 of those are in the process of updating. It's now mostly just the thousands of smaller packages that still are on Python 2 only. But Python couldn't get away with that more than once every 10 years.
    - GFK_of_xmaspast 13y ago
      Maybe I would have upgraded to python 3 by now if I saw any compelling reason to do so (like, say, getting rid of the GIL).
- roel_v 13y ago
  As a user of software - fuck you, and may you never touch anything I use. It's juvenile oo-look-shiny nonsense like this that makes us people who just want to get shit done waste yet another afternoon on patching working stuff after a (forced) update because some wet behind the ears dude decided that everybody before him was a utter moron. There is a reason people pay for software that just works, and will work for the next few years. It's because they're fed up with being the guinea pigs for architecture astronauts and code purity fetishists. Also, "that means we only have to upgrade..." Who is "we" here? You? Of course not, you're too busy chasing the next fad, while the rest of us have to repare shit just to make it do again what it aready did before.

grannyg00se 13y ago

So Sublime text provides a 99% feature loss but a great usability gain? Can you explain that a bit?

jamesgeck0 13y ago
I don't think anyone would argue that Sublime Text has a much nicer GUI than anything Vim has. It's just lots of little things, like how scrolling is smooth and quick, not entire lines popping into/out of view. The zoomed out source map is also nice. It's also ever so slightly snappier. Vim seems to be ever so slightly less responsive when I have several panes open.
tinco 13y ago
Well, I can explain how I use it. I have my Sublime in legacy mode, which enables some vim like controls. And I benefit from Sublimes super fast text rendering, it's nice fonts and colors, the way it integrates with my desktop environment, how fast it interacts with plugins that spawn popups and analyze my code. And then every once in a while I need to do some cool text transformation, and it doesn't work, so I launch a terminal, edit the file in Vim and work my magic. Then I exit Vim and continue in Sublime. Ideal? No.. but it's the usability of Sublime with the features of Vim.. every once in a while..
- NAFV_P 13y ago
  > And I benefit from Sublimes super fast text rendering, it's nice fonts and colors, the way it integrates with my desktop environment, how fast it interacts with plugins that spawn popups and analyze my code. The sentence quoted above sounds a lot like something out of a product promotion.
  - oblio 13y ago
    Well, when users are doing that, you can be sure that the competition will be in a world of pain!
badman_ting 13y ago

cicero 13y ago

I don't see anything shameful about using old software if it works well and suits your needs. Yes, new editors like SublimeText have advantages, and if you prefer them over Vim, use them. However, I've seen many projects undergo a rewrite in order to move to new technology, but they never matched the utility of the old technology they were trying to replace. I'm not saying it can't happen, but that it often doesn't. I don't use Vim much now because I work a lot in Windows, and Vim got me into the habit of hitting escape when I was through entering text, but escape cancels the input in a lot of programs. However, I still use it in the shell or when I need to make certain global edits. I wish Neovim great success, and I might use it someday if it meets my needs, but not just because it's new technology.

philsnow 13y ago
> Vim got me into the habit of hitting escape when I was through entering text, but escape cancels the input in a lot of programs. Does ^[ cancel input in any programs ? AFAIK vim understands the ^[, not the "escape key". the key labeled "ESC" creating a ^[ is a convention used in terminal emulators. Not that it's going to help you now, but if you had trained your fingers to hit ^[ rather than the escape key (or even ^C but that has other semantics in windows whereas I don't think ^[ does), I wonder if you would be having the same problem now..
- Crito 13y ago
  ^[ just generates ASCII character 0x1B, aka Escape. Vim understands "escape" to be 0x1B, pressed by itself (not as part of a longer escape sequence).
- gpvos 13y ago
  Not practical. ^[ is a two-key combination, so more RSI-inducing. And you need escape a lot, especially in plain vi. And the ESC key has been generating ASCII 27 on keyboards for a long time. It's definitely not just terminal emulators.
tinco 13y ago
Sorry, I didn't mean you should be ashamed about using old software. What I meant was that we should be ashamed that other people are using old software. I am helping my girlfriend to learn Javascript, and it hurts inside that every once in a while she gets confused with something I have to explain her it's because the author of the language made rookie mistakes/dumb decisions 20 years ago.

glesica 13y ago

> ...should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. First, why? It works just fine. Second, is there anything better? I don't know of anything I would prefer to use. So until someone comes up with something, I'll stick to using Vim to write LaTeX in a Bash shell (might upgrade to zsh, we'll see).

tinco 13y ago
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 both lack certain things we need, and LaTeX has those things. Could you not envision things could be better? A LaTeX that parses to an in-memory tree so it could be transformed before compilation? 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? An editor that does have at its core an expectation that its output is ASCII character commands controlling a 1970s terminal interface? Of course you'll stick to using Vim to write LaTeX in a Bash shell, I do too. Doesn't mean I'm not mad about it..
- robinhoodexe 13y ago
  "Markdown is better. Microsoft Word is better." Stop comparing oranges to apples. And there's really no "objectively better", it's two different tools with two different uses. Sure, LaTeX could be better, but it's been working on.
  - tinco 13y ago
    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.

justinmk 13y ago

This should not be the top comment, it is a rant that misses the point. Neovim maintains backward compatibility where it makes sense to do so. Neovim is NOT a rewrite, it is a thoughtful refactoring that aims to achieve one of Vim's _original_ goals: first class support for embedding. And better interoperability.

tinco 13y ago
I think you miss the point of my rant :P I'm not saying everything should be rewritten (though I do believe everything in C should be rewritten in C's successor which doesn't exist yet), but I'm saying Vim has gone too far in maintaining backwards compatibility, and if it would have improved interoperability, even at the expense of some backwards compatibility.
- jnbiche 13y ago
  >I do believe everything in C should be rewritten in C's successor which doesn't exist yet Both golang and D have a reasonable claim to being C's successor. People often think of D being a nextgen C++, but to me it has much more the feel of a C with garbage collection and batteries included. And golang definitely feels like a modern C, at least to me. And that's what Rob Pike had in mind, as well. PS: Had to use Word every day for years for my job. I despise it, and love vim. Vim keyboard navigation would have made my life so much easier when working on Word, and saved me several severe episodes of carpal tunnel. Luckily, I no longer have to use Word.
  - nousernamesleft 13y ago
    Go has absolutely no claim to being C's successor. It is useless for all the things it makes sense to use C for. That's why it has attracted virtually no C programmers. Go is python's successor if user influx is anything to judge by.
    - jnbiche 13y ago
      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.

chongli 13y ago

We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. What?! You can take my vim+bash+tmux+urxvt when you pry it from my cold, dead hands!

rjzzleep 13y ago
i so wish any of the terminal emulators in osx had the scriptability that urxvt has. i miss it all the time :/
- lepht 13y ago
  I've been frustrated by the lack of iterm2 features in Linux terminal emulators: local autocomplete, tmux integration, etc
  - zobzu 13y ago
    I've been frustrated with the lack of Konsole in any other term emulator.
slashnull 13y ago
> 2014 > not zsh
- dijit 13y ago
  >implying >not on /g/
- chongli 13y ago
  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.
  - 13y ago

NAFV_P 13y ago

> Look at SublimeText, it's got 1% of the features of Vim, yet it's converting Vim users left and right, by its sheer usability. I just looked it up, $70 is way out of my pay range. I'll convert when I have a full-time job. > We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. Yes, you should be ashamed.

nicklovescode 13y ago
You can use the free version. It's full featured but has intermittent alerts asking you to upgrade[0]. [0] Recent vim convert.
- bmj 13y ago
  Sublime is only free-as-in-beer. Some use vim because it is also free-as-in-speech.
  - nicklovescode 13y ago
    "I just looked it up, $70 is way out of my pay range. I'll convert when I have a full-time job."

gradstudent 13y ago

> Look at SublimeText, it's got 1% of the features of Vim, yet it's converting Vim users left and right, by its sheer usability. 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. vim is amazingly usable; text manipulation commands for example all follow a common structure: [action][times][position]. That means the rules you learn for using "yank" apply just as well to "delete" or "paste" or whatever. Anytime you encounter a new text command you don't even need to wonder how to use it; it's a sure thing it will follow the same structure that you already know.

rjzzleep 13y ago
not too mention that vim became hip only in the last couple of years. saying it's converting vim users left and right is a little far fetched. most of those users never had any real vim muscle memory to begin with. a lot of "vim" users i saw work just fine without motion commands. the only reason they used it was because they could use it anywhere. whether it's modal or not is totally irrelevant to them.
- jude- 13y ago
  > not too mention that vim became hip only in the last couple of years. Wait, what? Vim has been in use for a lot longer than that (it was released in 1991), and vi even longer (1976).
  - andrewflnr 13y ago
    "Hip" does not mean remotely the same thing as "in use".
    - deleted 13y ago
      [deleted]
  - AliceWonder32 13y ago
    Yes but emacs was for more popular than vim for awhile.

terminus 13y ago

> We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. (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.) Let's deconstruct each of the pieces we are supposed to be ashamed about, shall we. LaTeX the language: a wrapper language built on top of TeX for typesetting documents. The idea being to specify higher level document logic (for instance sections, subsections, paragraphs, tables) and if all else fails, then fallback to explicit placement commands. I fail to see anything to be ashamed of in the idea. And, as for your complaints about extendability in some of the comments below: maybe you should look at the texlive distribution or PGF/tikz here: http://www.texample.net/tikz/ http://www.texample.net/tikz/) LaTeX/TeX compiler: that's a fair point. But, doesn't have much to do with the language. vim: a text editor wrapped around using the keyboard efficiently, similar in idea to LaTeX the language in that it asks you to express yourself on a higher plane. Neovim is essentially a more maintainable repackaging of the same model keeping extendability in mind. bash: wrapper over the early Unix model pipes, ttys, processes (and not threads) etc. The bash scripting language is not all it could be. But, as I said before, the basic model is fairly tied up with Unix itself and is similar in zsh/fish etc.

jrk 13y ago
(My post got long, so I've put a standalone version, with better markup rendering, here: http://gist.io/9161898. http://gist.io/9161898.) [TikZ] is a perfect example of TeX's missed potential: it is an outstandingly well designed DSL for diagram creation, embedded in an insane macro language. The moment you try to do anything nontrivial that exploits the programmatic (rather than purely declarative) nature of TikZ you immediately run into wall after wall trying to express basic programming concepts in the host language, TeX. For example, two common patterns I have seen frequently arise as perfect uses for a programmatic diagram description: - using computed coordinates and transforms to construct complex paths and diagram layouts from the composition of basic geometric reasoning; - using abstraction to tersely encapsulate common visual components, both for simple iteration over many similar components, or for higher-order encapsulation of parameterized diagram logic. In both cases, you quickly run face first into fundamental limitations of TeX as a programming language. In particular, it is extremely painful to use for either arithmetic or control flow. This is a big enough deal in practice that core among TikZ's features are custom inline arithmetic syntax for coordinate computation, color blending, etc., and a custom `\foreach` macro, both defined not in the language, but provided as part of a specialized diagraming library, because they are fundamentally at odds with the design of the core TeX language. Even this impressive bit of TeX engineering still breaks down as soon as you try to do much more than iterate over a hard-coded constant range. (How much do you need to bracket, `\relax`, etc. the operands of your `\foreach` if it is used inside of a macro definition? Or if they are the result of computation, even as simple as basic index evaluation like `\x+1`? Now what if you want to iterate over a range which results computed in part using floating point arithmetic using one or another library?) TeX suffers because it is at once both a relatively awkward markup language (relative to something like Markdown) and an extremely awkward programming language. Many tasks which would be trivial in any mainstream programming language are outrageously challenging and arcane in TeX. The LuaTeX effort to embed a sane, modern programming language much more centrally into the core of the TeX runtime is a fruitful direction, but it still does little to better formalize or structure the various levels of document representation for programmatic transformation: we still have a giant stack of TeX macro complexity, ultimately expanding down to very low-level page rendering descriptions, just now with the ability to register Lua callbacks at various points along the way, or use Lua scripts to generate new tokens during the expansion process. As a clever, minimalist hack, the single-pass macro expansion semantics at the core of the language were a great way for one man to bootstrap a complex typesetting system. As an expedient hack to build an incrementally more humane document generation system atop the powerful low-level typesetting engine already available in TeX, LaTeX got a lot of mileage for relatively little cost. As an intermediate representation for modern typesetting systems, TeX could be a reasonable higher-level alternative to something like PostScript (which few bother to write by hand, but is a great low-level page description language, particular as a target for machine generation). But as either a primary programming language or a human-facing markup language, TeX is a terrible fit. Worse, the extreme difficulty of doing anything parametric in TeX makes it a bad fit for a future of many display formats and adaptive (responsive) layout, where baking tools focussed on baking a single paginated output format are less and less relevant. The evidence for how different the world could be is not given by plain Markdown for comment boxes—that is, indeed, an apples to oranges comparison—but by the power that comes from creating an extensible and programmable document transformation system based on a well-defined document grammar (which is, in fact, a recursive data type, not tied to any one front-end syntax). That's the heart of [Pandoc]. It's not just "extended Markdown" or "a markup format converter," it's a powerful framework for document transformation, which naturally supports humane markup, while also allowing extreme extensibility via general-purpose programming languages. See the [scripting] documentation to get a sense for the model of extensibility, then recognize that this same document representation is the core of every translation and transformation Pandoc does, and how this model enables many of the same things as TeX's macros, but in a far more structured yet also programming-friendly way. [TikZ]: http://www.texample.net/tikz/ http://www.texample.net/tikz/ [Pandoc]: http://johnmacfarlane.net/pandoc/ http://johnmacfarlane.net/pandoc/ [scripting]: http://johnmacfarlane.net/pandoc/scripting.html http://johnmacfarlane.net/pandoc/scripting.html

jude- 13y ago

> I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. Please clarify by what is meant by "backwards compatibility," since this is a loaded phrase. On the one hand, it's the idea that software system B can do everything that earlier software system A can, using the semantics of software system A (e.g. "vim can do everything vi can, using the semantics of vi"). On the other hand, it's the idea that software system B is semantically incompatible with software system A (e.g. SublimeText vs vim), but software systems A and B can coexist without breaking each other. While I agree that achieving the former idea of backwards compatibility isn't always important (particularly in the realm of text editors), achieving the latter is an absolute must. If there is one thing I will not tolerate on my systems, it is a piece of software that breaks other working software that I rely on. > There is nothing holy about Unix era software, chances are it's shit and a lot of it should be thrown out. Like it or not, we're still in the Unix era, and likely will be for some time. Unix is more than a specific implementation or even a specific API--it also includes the logical abstractions behind them. You still deal with files, directories, processes, threads, pipes, sockets, dynamically-linked libraries, paging, etc., whether you're on Unix or Windows. This means SublimeText is "Unix era software" too--it's built on top of the same Unix-era abstractions as vim. Perhaps the only Unix abstraction vim makes use of that SublimeText does not is the TTY, but that doesn't stop me from using vim where TTYs don't exist. And you're right, most Unix era software is shit. But don't limit yourself to Unix era software--most software in general is shit. Very few pieces of software become as robust and widely-used as vim, and SublimeText isn't going to make vim disappear anytime soon (especially since it doesn't break working vim installations). > We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. Feel ashamed of me then, since I do exactly this. Why? Because there isn't anything sufficiently better for what I need to do. I have given every single WYSIWYG editor that claims to do a better job a good-faith trial, and I have always gone back because each contender always lacked the ability to do something I needed to do. I'm not saying it's impossible to do better; it certainly is. It's just that I've seen nothing that actually is better. I would address this myself, but I have too many other, more important things to work on (like finishing my PhD thesis). > (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.) Code doesn't write itself :) Software systems don't design themselves either :) What you're asking for is a very, very tall order. Many have tried to replace that which is "good enough," and yet we're still in the Unix era despite their efforts.

Arnor 13y ago

I can't believe I read this whole thread... I need to go take a shower now...

chadillac 13y ago

ring ring ring "yeah, what's up?" "Nagios is paging, something with that code you pushed live a couple hours ago is throwing a fit... looks like half the web cluster is on the verge of going to swap, can you look into it? asap!" "Well, I'm on at the bus stop and won't be near a computer for at least an hour...yeah, I'll sort it out, will text you when we can push fix live." pulls out Note 3, shitty 3G coverage connects to VPN ssh into dev env with connectbot switches to hackerkeyboard for input mode screen -dr dev Ctrl+c, tail join IRC channel that dumps syslogs from production cluster sees error Ctrl+c,vim the/file/causing/the/unexpected/problem fix, :wq git stash, git pull, git stash apply, git commit, git push Ctrl+d, exit sends text message "good to go!" deal with it.

yen223 13y ago
Moral of the story: Vim is very good for deploying fixes from bus stops.
- chadillac 13y ago
  ‰s/bus stops/everywhere/g
- devcjohnson 13y ago
  Moral of the story: This post has devolved into inane commentary.
pjmlp 13y ago
Better, mobile off. Fix issue in the morning when back on office.
tinco 13y ago
git commit -m "Always commit your changes first!"; git pull --rebase; git push And I use tmux, it's more modern ;) I like the syslog into irc thing, that's neat. By the way, I recently made a commit in the Github web interface while sitting on the toilet. No posix stack required ;)

anon4 13y ago

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

_cipher_ 13y ago

> We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. I agree. Bash sucks. ;)

pjmlp 13y ago

I fully agree. For me, Vi and Emacs are only when I don't have an option in terms of IDE support, even though I know at least Emacs quite well. What can I say, the world of Amiga GUIs, Smalltalk and Lisp environments spoiled me as an IDE fanboy. It baffles me why in 2014, some developers still prefer to work as if UNIX System V had just been released.

dmytrish 13y ago
What features does an IDE give you?
- pjmlp 13y ago
  - Visual representation of the code structure - Ability to select any symbol and find semantic uses of it - For OO code, being able to visuallize the OO graph usage of certain symbols - Refactoring across the whole project with semantic knowledge (no, search/replace does does not cut it) - Navigation in third-party libraries deployed in binary format - Code completion for static/dynamic languages, while showing tooltip documentation - Graphical visualization of data structures on the debugger - Background compilation with static analysis - unit test debugging infrastructure - integration with modelling tools - integration with SCM tooling and being able to interact with them directly from the editor. For example, generating a blame file, with navigation across the file revisions. - integration with continuous integration servers - integration of developer workflow with task management servers As an example of such developer workflows, have the IDE talk to Jira, edit the code, automatically bundle it in a workflow that binds the code changes to the Jira issue being worked on, get a Jenkins notification after the code is checked in and gone through the CI system. Sure you can get part of it in Emacs, after spending a week configuring plugins, with different levels of maturity, and in the end it is still mostly textual.
markdennehy 13y ago
> It baffles me why in 2014, some developers still prefer to work as if UNIX System V had just been released. Because (a) some of us aren't convinced that things like IDEs give a better view of what's going on in the system; (b) some of us think that fundamental tools like terminal emulators, editors and so on should be debugged and stable because we have to earn our mortgage payments using them and chasing the shiny isn't on our job description; (c) any actually useful new idea winds up in Vim anyway. You want to use a new shiny unproven editor, grand, have a ball. But don't ask me to purely on the basis that it's not new and shiny.

keerthiko 13y ago

I am honestly amazed at how feistily every 'hacker' here is defending LaTeX in response to your comment. I agree with you for the most part. This whole "it's apples to oranges" claim is bullshit. Both Word as well as LaTeX can be used for anything from writing a resume, making a technical paper with a few simple equations, to writing an entire Vector or Linear Algebra textbooks. When you have two options for doing the same task it's very much comparing apples to apples. Yes, they each were originally built with different objectives and different target markets, but they have since aspired to be usable for all the same things. Of course, they each have their strengths and weaknesses. But I don't get how do a bunch of folk here feel justified in arguing against someone saying "there's room for improvement" with clear viable suggestions on the details too. I know that hating on MSWord (or MS-anything) is fashionable on HN. But you can't seriously be defending * the steep learning curve: throw your 14-year-old who's doing a math assignment Word vs your favourite LaTeX editor, see what happens; * lack of WYSIWYG-like feedback-loops: you have to wait a full minute on decently sized documents to see the result of adding that equation that took you 10 seconds to add; * syntax holdups: you miss an underscore and your document is broken. All the way through. And can take an hour to fix even if you're skilled. People writing documents that need LaTeX's power aren't always coders, and debugging is not a fun or planned-for activity for anyone. I also don't for the life of me see why someone has to "be an expert, not just written a couple documents casually in undergrad" to be able to comment on the flaws of a product. They're as much a user as a power user, and obviously the power users went through that stage too. Losing sight of your past difficulties (or being gifted in LaTeX) doesn't make them irrelevant for people not in your current position. Loosely relevant: I smell hardcore "hacker entitlement" around people using LaTeX and defending it including all its stupid barriers to easy document-creation tooth and nail. Hardcore programmers do this with way too many things (like Linux, and development environments for almost any language). And it's just really frustrating for a lot of people to deal with =/ PS: NeoVim sounds like someone finally got off their high horse (or from whining) and decided to actually make something better. Thanks!

anonymouz 13y ago
> This whole "it's apples to oranges" claim is bullshit. Both Word as well as LaTeX can be used for anything from writing a resume, making a technical paper with a few simple equations, to writing an entire Vector or Linear Algebra textbooks. When you have two options for doing the same task it's very much comparing apples to apples. So can HTML. Would you compare Word to HTML? You can also write your resume in Notepad. Does that make Word comparable to Notepad? If you want to compare anything, compare LyX to Word. At least that makes some sense, even if the output of the latter just sucks in comparison to the former. TeX is at its core a typesetting engine. Word is largely a GUI markup editor. It doesn't even do anything coming close to typesetting. > * the steep learning curve: throw your 14-year-old who's doing a math assignment Word vs your favourite LaTeX editor, see what happens; Are you sure? Customizing LaTeX can be hard, but using it in a straightforward way is no more difficult than HTML. Sure, it may be a bit more work than using a GUI, but once you get the hang of it it's a lot quicker than Word's formula editor. > * lack of WYSIWYG-like feedback-loops: you have to wait a full minute on decently sized documents to see the result of adding that equation that took you 10 seconds to add; In my experience it's a lot faster than that. The reason for this is simply that TeX does actual typesetting. This has a certain computational complexity, and cannot just be done on a line-by-line basis. Word is fast because it doesn't do anything like that. Again, Lyx has WYSIWYM (What you see is what you mean), which gives you an approximation of the output instantly, minus the proper typesetting. > * syntax holdups: you miss an underscore and your document is broken. All the way through. And can take an hour to fix even if you're skilled. People writing documents that need LaTeX's power aren't always coders, and debugging is not a fun or planned-for activity for anyone. It more commonly takes a minute, not an hour. Every had Word corrupt a file and mess up the styles in the middle of your 150 pages document? That's not exactly a quick fix either. To sum up: If you want a WYSIWYM editor for TeX use Lyx. Otherwise, comparing LaTeX and Word makes about as much sense as comparing HTML and Word.

krick 13y ago

Oh, it's a real flamewar and people still seem to be here, so I want to add a little constructiveness to it. Vim, bash, LaTeX. Let's postpone vim, as the whole topic is [supposed to be] about it. And we have enough shells (zsh, fish) instead of bash, many people (me too) tried it and have chosen bash (although I use IPython quite often). And I don't know sane and fully functional alternative to LaTeX. (Markdown and co don't count as they don't have same control on output.) So let's stick with LaTeX. There are 2 categories of people: those who think that LaTeX is fine for its usecases and those who think that something is wrong and could be done better. Fine is fine, so lets concentrate on the second category. I'll recite main complaints: slowness, horrible syntax, arcane source code, impossibility to divide semantics from representation. (Did I miss something?) I guess many of us are able to program. So why somebody, right here, right now, wouldn't create a github/bitbucket repo, post link on it and explain, what exactly in your opinion could be done better? I personally would probably participate if somebody has a plan sane and explicit enough.

AliceWonder32 13y ago

Um, I've never heard of SublimeText. I like vim because it is cake to ssh into a server and quickly / efficiently modify a text file. And there is nothing shameful about developers accomodating my desire to use a command-line text editor to create/edit TeX files in whatever terminal I am using. Normally I create / edit TeX using LaTeXila but it is fanstatic that I can do so with vim and when I don't have access to LaTeXila I use vim for TeX editing, and I am quite glad I can. With software that works in a standard shell environment, I can ssh into a networked computer from my Android tablet (Better Terminal Emulator Pro and Hackers Keyboard) and do actual work. Far more convenient than carrying my laptop everywhere and also faster than checking out source, firing up a GUI, and then committing the source. Terminals ARE good technology and we would be worse off without them.

srik 13y ago

But I want to write on my text editor on a terminal emulator because I have access to all of the built in operating system utilities.

eyko 13y ago

"I hate the ideas many programmers have about backwards compatibility, unless it affects me." – FTFY > "There is nothing holy about Unix era software, chances are it's shit and a lot of it should be thrown out." 1. we're still very much in the "Unix era" 2. There's nothing holy about software at all. Rules shouldn't be broken, but rules can be broken. > Look at SublimeText, it's got 1% of the features of Vim, yet it's converting Vim users left and right, by its sheer usability. If anything I'd say Vim is converting TextMate/SublimeText left and right. Most SublimeText users are former TextMate, and many new Vim users are former SublimeText users. > We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators Speak for yourself. I don't personally write LaTeX but I still very much use the shell, and Vim.