5 ms·

concerning vimdiff: one of the goal is to get vis to also work in server mode and be embeddable. it should then be possible to create a diff tool that uses vis

by aoloe 11y ago

concerning vimdiff: one of the goal is to get vis to also work in server mode and be embeddable. it should then be possible to create a diff tool that uses vis for the editing.

rauljara 11y ago
That sounds fantastic. Very often I find myself editing outside of vim and wishing vim style editing were there. Recreating optional vim key bindings for every app that has text is clearly not realistic. Getting as many things inside of vim as possible is just tantalizing enough that a lot of people (myself included) try it. It's better than nothing, but results in some very hacked together tools. Embedding vim (or in this case, vis) inside of other things would be a much better solution.
geoelectric 11y ago
So instead of the vim philosophy of embedding every functionality within vim, this potentially embeds vis in every functionality? I actually like that--much more composable.
- qu4z-2 11y ago
  I believe (and I may be wrong) that the vim philosophy is actually to embed vim in things rather than embed things in vim. They've just lost track of that a little over time. See also :help design-not: 'Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"'
  - geoelectric 11y ago
    You're right, and I sold vim a little short there, compared to something like emacs. More accurately, I meant that when someone wants to combine vim with a functionality they tend to implement it as a plugin with vim as the host and interface. I won't speak for anyone else, but my vimrc tends to accumulate a lot of behavior such that it's still a kitchen sink--it just wasn't included with the initial distro.

by aoloe 11y ago

concerning vimdiff: one of the goal is to get vis to also work in server mode and be embeddable. it should then be possible to create a diff tool that uses vis for the editing.

rauljara 11y ago

That sounds fantastic. Very often I find myself editing outside of vim and wishing vim style editing were there. Recreating optional vim key bindings for every app that has text is clearly not realistic. Getting as many things inside of vim as possible is just tantalizing enough that a lot of people (myself included) try it. It's better than nothing, but results in some very hacked together tools. Embedding vim (or in this case, vis) inside of other things would be a much better solution.

geoelectric 11y ago

So instead of the vim philosophy of embedding every functionality within vim, this potentially embeds vis in every functionality? I actually like that--much more composable.

qu4z-2 11y ago
I believe (and I may be wrong) that the vim philosophy is actually to embed vim in things rather than embed things in vim. They've just lost track of that a little over time. See also :help design-not: 'Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"'
- geoelectric 11y ago
  You're right, and I sold vim a little short there, compared to something like emacs. More accurately, I meant that when someone wants to combine vim with a functionality they tend to implement it as a plugin with vim as the host and interface. I won't speak for anyone else, but my vimrc tends to accumulate a lot of behavior such that it's still a kitchen sink--it just wasn't included with the initial distro.