Hacker News Reader

Comment by bcrescimanno | Hacker News Reader

It's definitely a problem All Vi/Vim users know well; and, it's precisely why I don't install these "vim mode" plugins / extensions / whatever for other software. Simply put: no matter what they do, it's still not actually Vim. And honestly, I'd rather be forced to do a complete mental shift into a "plain editor" mode rather than have to wrestle with "will this particular combination of Vim commands work in this pseudo-Vim world?"

I've found that if I completely break the expectation that I'll get anything even remotely "Vim-like" outside of Vim, I'm better able to deal.

...though I still wish I could make every editor I have to interact with a Vim window. :)

View on HN

I started using VIM 3 months ago. And now I can't fucking use anything else. The ergo gains of vim are so rediculously awesome, and NOBODY else does VI right, other than VI. Even Sublime 2, it has vintage mode but its not VI, it's missing most of the magic. This is why we need a new VI. One that has better syntax highlighting, one that can use something other than VIMScript AND STILL support all of vimscript. Something with better graphics like what Sublime 2 has, but still lose nothing of VIM's power.

Tough project, but needs to be done.

This [1] is an attempt to do just that. I haven't really looked at the source, but from what I gather it is a way to combine keymaps, actions, parsers, and syntax grammars however you like. There's also a vi mode (don't know how complete) and I think the modular approach they've taken is the way to go.

Also, it is written in Haskell.

[1] http://www.haskell.org/haskellwiki/Yi

urgh; I feel that the last thing we need is to couple our editors even more strongly to the flavors of the month (and 500mb+ of dependencies). I wish these things were more ecumenical...

How is Haskell a flavor of the month?

For the record, the first commit to the Yi project was 8 years ago. This isn't some flash in the pan project.

We are speaking in a context set by vi/vim (remember, that was the jumping off point for promoting yi here).

If you cannot think of at least one language which is older and a better common denominator than Haskell (both at the binary level and at the interface presented to programmers)... I don't know what to say.

What actual reason do I have for switching from vim to yi? Just because it's written in Haskell and that obviously makes it better, or what?

I... have absolutely no idea what you're trying to say. It's not worth ever using a language if there's an older one around? Are you saying you don't want to switch editors unless the new one is written in FORTRAN?

Yes, we should write our editors in assembler.

it's not that haskell is bloated...

Better syntax highlighting? For what language? In all honesty, it's not super-tough to write your own syntax for any language. If you do it, release it on github and others will probably be willing to contribute.

Vim has support for scripting against Python and Ruby in addition to VimScript.

Better graphics? For what purpose? For displaying text?

> it's not super-tough to write your own syntax for any language

Spoken like somebody who's never tried to parse C++.

Parsing C++ isn't required if all you are doing is syntax coloring.

vim has a fully configurable syntax highlighting system; its behavior is not hard-coded. So if you have a problem with how C++ is highlighted then you don't need to petition for the developers to patch or rewrite vim for you.

You can tweak the related configuration. And it's true that it's really not that hard to make your own new configuration to do this. Because you aren't compiling the code, you are only highlighting it according to your own tastes.

Any syntax highlighting scheme which does not leverage a language parser is woefully limited. If you're satisfied with a scattering of heuristics, great; you'll find satisfaction in a much wider set of tools. Myself, I want syntax highlighting that doesn't break as soon as I do something unusual, and which is capable of more than identifying keywords.

Given that vim is open source, I'm not sure why you think hard-coded syntax highlighting would be impossible for me to modify.

Mind the context: the guy said there needed to be a "new VI" to have "better" syntax highlighting (whatever specifically he meant by that). You broke in to emphasize how tough it is to parse C++, which is true, but not entirely relevant; the person you replied to was simply pointing out that it's easy to reconfigure vim's syntax highlighting to almost any requirement. Which is true, by the way.

It appears that you are preoccupied with hard-coded construction of ASTs for some dialect of C++ inside your editor. I never suggested it could not be done. But, this is a different issue.

However, I really don't think many people need that when the facilities for configuring syntax highlighting are so good. The existing system has allowed vim to support a crazy number of languages and have fresh support for languages quite quickly after they start to be used.

If you like vim, and you want something SPECIFIC to be fixed about its C++ highlighting (not just a general complaint that you feel it is 'woefully limited' because it isn't based on hardcoded static analysis for C++) ... then don't waste time on doubt. Just try it. Make your own highlighting script and see if it works to a usable level. If it does not, then you know, and not just because of some a priori principle that syntax highlighting is useless unless it is based on an AST generated by your compiler toolchain or something.

If you really did have any practical reason to believe that the existing syntax highlighting facility was totally unsuitable for more than a handful of people... maybe it would be interesting to have some way of plugging in external modules of some kind to provide ASTs for specific languages. (Because I think the idea of making my text editor totally coupled to a specific hard-coded implementation of a parser for a particular language sucks really bad; but if you don't think that, then maybe you just want to buy a C++ IDE and be done with it)

What makes you think I want anything hard-coded?

Ruby is quite a beast too, in that parsing Ruby is easy, except for a bunch of wicked corner cases which makes parsing exactly like ruby(1) tricky.

Ha! Fair enough!

Well, vim cannot syntax highlight markdown. Period.

There are multiple markdown syntax highlighting plugins, but none of them work most non-trivial markdown features (a paragraph indented by four spaces after a list item is a regular paragraph not a code block; extend the same analogy to multiple nested lists...).

>Vim has support for scripting against Python and Ruby in addition to VimScript.

and Lua, Perl Tcl and Racket.

replying to every person to point out, that syntax highlighting _is_ pretty complete in vim. yes, it is.

... but, what about microformats (not the w3c-flavor) in other files. say: any in-place templating language (php), code blocks in markdown, etc.

that would be really great. it does not stop at syntax highlighting though. i'd really like my erlang mode in markdown code blocks :D.

Vim has support for scripting in Scheme and Lua as well I think.

vim already supports things other than vimscript (e.g. perl, ruby, python). Depends on what your OS packages provide, or compile it yourself (really not too hard).

I don't know how the syntax highlighting could be better since it is already fully scriptable and allows 256 colors, etc.

So what is it that needs to be done? All I get from this is that you think vim should have "better graphics like what Sublime 2 has". So I ask sincerely: what is the actual essential functionality required and why would it demand a 'new VI' rather than a patch or plugin?

If you can formulate what is needed more specifically then it's more likely that you can fix it yourself or at least have a chance of enlisting someone else to do it.

> The ergo gains of vim are so rediculously awesome

For instance?

  * select all: ctrl-a
  * copy: ctrl-c
  * spawn vim: ctrl-f ! vim enter (varies by desktop environment)
  * paste contents into vim: :.!xsel -o
  * edit text in vim
  * copy contents from vim: :%!xsel -ib
  * close vim: :q!
  * paste contents into original window: ctrl-a ctrl-v

There is no reason to use xsel. try "+p or "* p to pull into the clipboard, try "+y or "* y (edit: the spaces are just me trying to escape the asterisks for HN)

You can also easily configure vim so that simple 'y' and 'p' will operate using the system clipboard, which I do.

You don't have to spawn and close vim around each task either.

Of course vim has no way at all to reduce the amount of ctrl-a, ctrl-c, ctrl-f, ctrl-a, ctrl-v boilerplate you are doing in this example because that all occurs in some other program.

The easiest thing to do here would likely be to make an alias that runs vim -c s/^/\\=@\* which opens vim with the text from "* on the first line. You could even add a mapping like gg"* yG:qa!<Cr> to yank the new text and close vim(the space after the asterisk is to escape it, of course).

I definitely agree that having a faster way to use the system clipboard is great, but I don't like cloberring the clipboard when I do deletions and whatnot in vim, so I have <Leader><Leader> (I use ; for leader, seems like most people use ,) mapped to "* which I find much easier(;;y is so much faster than "+y for me).

This is a great idea, for optimizing this pathway. With a sufficiently programmable desktop environment, you can probably wrap it all up into one hotkey (including the select-all, cut, and paste in the original window). I'm not sure if it's quite worth doing, on first principles, but I may take a swing at it for the practice in customizing my setup.

although I've used vim for a while now, I still feel like chuckling when I see something like 'gg"* yG:qa!<Cr>' written out, because of how ridiculous it looks to anyone who doesn't use vim.

I know just what you mean, it looks absolutely ridiculous. I occasionally send coworkers very long vim macros just for the enjoyment of explaining how useful some 100-character line of gibberish is.

> try "+p or "* p to pull into the clipboard, try "+y or "* y

Very nice. I like xsel because it gives me more flexibility and uniformity (I can pipe it to/from whatever, and use it the same in the shell as in vim), but I'll probably wind up using the above for simple cases (especially if the xsel command I want isn't in my history for some reason).

I made a more detailed post below, but I would think an alias to something like vim -c s/^/\\=@\* (or @\+ I'm not sure which register you'd need to use) would be your best bet for fast editing: it should let you open vim with text from your clipboard already inserted on the first line.

You are right, piping with xsel is very cool.

you will need a vim with xclipboard though. (not on every server)

8 steps is hardly efficient. That's not a nice flow to edit every text field where you want a more powerful editor.

Eh, most of the time what I write in a text field is short enough I'm not really going to be editing it. When I find myself writing paragraphs, I do something like the above. I agree that it's not ideal, but it suffices.

The biggest pain point I have with the constant copying back and forth is when I'm editing something that live previews in the text field or that needs to be executed. There are times when I just want to embed vim when editing code in a browser.

I use the pentadactyl extension for firefox, and I've added the emacs hotkeys <C-a>, <C-e>, <C-n>, <C-p>, <C-f>, <C-b>, <M-f>, and <M-b> to insert mode so that I can at least move between lines and words without much problem. It's not vim, but it makes things like writing this comment a lot easier for me.

Also having <C-p> and <C-n> as up and down means that moving between search suggestions on sites is really easy, which is nice.

   f 24 ^M      - choose reply
   f 6  ^M      - enter text buffer
   ^i           - open vim
   *** write this message ***
   :wq          - message gets transplanted into text buffer
   esc, esc     - exit text buffer, exit insert mode
   f 7 ^M       - choose reply again

   ??? 

   profit       - vimperator

pentadactyl user here.

I'd replace your second step with 'gi'. Saves a char, and avoids scanning for numbers..

Reply on news.ycombinator.com