New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regarding xxd, vimdiff, and evim #1646

Closed
ghost opened this Issue Dec 12, 2014 · 41 comments

Comments

Projects
None yet
5 participants
@ghost

ghost commented Dec 12, 2014

I see that runtime/doc/manpages contains man pages for vimdiff, evim, and xxd, but none of these binaries seem to be built. I'm wondering if these man pages are going to be removed, or if their respective binaries will eventually be built by default. I ask because I'm unsure about the inclusion about a few of these.

  • xxd seems like the byproduct of feature creep for it to be included with a text editor at all. Even if it is useful, I'm still unsure about its inclusion (probably because I've never used it). It'd be great if someone could chime in on its value over something like xd.
  • Is there any particular need for evim anyways? It really confuses me why it was even included in vim in the first place. Why not just use nano?
  • I don't see much reason for vimdiff to exist, let alone have its own man page. I say this because it's the same thing as vim -d, at least according to :h vimdiff:
1. Starting diff mode

The easiest way to start editing in diff mode is with the "vimdiff" command.
This starts Vim as usual, and additionally sets up for viewing the differences
between the arguments. >

    vimdiff file1 file2 [file3 [file4]]

This is equivalent to: >

    vim -d file1 file2 [file3 [file4]]

I'm not a fan of having all these symlinks (viewdiff, gviewdiff, evim, vimdiff, rview, etc.), especially since:

  • Their one letter arguments are usually shorter, although not by much
  • It introduces the possibility that people would falsely think that something like vimdiff is a separate binary, especially since it has a separate man page. I can understand having separate man pages for something like git, but vim doesn't have any subcommands with unique arguments, only arguments for vim (I think).
@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 12, 2014

Contributor
  • xxd is pretty useful when editing hex files with vim. Its output by default is much better than xds, and vim has some niceties to handle it (syntax highlighting). See :help using-xxd. I think xxd could be better integrated with vim, though - vim+xxd is not a very good hex editor. It is also a problem if nvim tries to install it over vim's provided binary.
  • In systems that support it, you can type vimd<TAB>, which is shorter than vim -d. I think the *diff invocations are nice to have.
Contributor

fmoralesc commented Dec 12, 2014

  • xxd is pretty useful when editing hex files with vim. Its output by default is much better than xds, and vim has some niceties to handle it (syntax highlighting). See :help using-xxd. I think xxd could be better integrated with vim, though - vim+xxd is not a very good hex editor. It is also a problem if nvim tries to install it over vim's provided binary.
  • In systems that support it, you can type vimd<TAB>, which is shorter than vim -d. I think the *diff invocations are nice to have.
@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 12, 2014

Member

xxd is very useful and would be quite a shock to remove it. Though on linux, perhaps we should depend on the package manager to provide it.

Eventually I even hope that on Windows we will consider shipping curl and perhaps other tools.

I see that runtime/doc/manpages contains man pages for vimdiff, evim, and xxd,

I'd be in favor of merging those manpages to the nvim manpage.

I'm not a fan of having all these symlinks (viewdiff, gviewdiff, evim, vimdiff, rview,

Neither am I, it only increases the cognitive burden for the user, and adds confusion. One argument in favor of at least keeping the handling of the "magic symlink invocations" is that it may be expected by tools like git. I'm not completely sure though. I think the usability/consistency gain is worth this small cost. If anyone knows of another reason to keep these around, please do say so.

In systems that support it, you can type vimd<TAB>, which is shorter than vim -d. I think the *diff invocations are nice to have.

Distributions or users can add bash aliases for that (e.g. alias vimdiff='nvim -d'), right?

Member

justinmk commented Dec 12, 2014

xxd is very useful and would be quite a shock to remove it. Though on linux, perhaps we should depend on the package manager to provide it.

Eventually I even hope that on Windows we will consider shipping curl and perhaps other tools.

I see that runtime/doc/manpages contains man pages for vimdiff, evim, and xxd,

I'd be in favor of merging those manpages to the nvim manpage.

I'm not a fan of having all these symlinks (viewdiff, gviewdiff, evim, vimdiff, rview,

Neither am I, it only increases the cognitive burden for the user, and adds confusion. One argument in favor of at least keeping the handling of the "magic symlink invocations" is that it may be expected by tools like git. I'm not completely sure though. I think the usability/consistency gain is worth this small cost. If anyone knows of another reason to keep these around, please do say so.

In systems that support it, you can type vimd<TAB>, which is shorter than vim -d. I think the *diff invocations are nice to have.

Distributions or users can add bash aliases for that (e.g. alias vimdiff='nvim -d'), right?

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 12, 2014

Contributor

Distributions or users can add bash aliases for that (e.g. alias vimdiff='nvim -d'), right?

Completely right. It is just more convenient if it comes from upstream itself ;)

Anyway, I was just thinking all of these might be eventually replaced by special purpose UIs, in particular evim and gvimdiff.

Contributor

fmoralesc commented Dec 12, 2014

Distributions or users can add bash aliases for that (e.g. alias vimdiff='nvim -d'), right?

Completely right. It is just more convenient if it comes from upstream itself ;)

Anyway, I was just thinking all of these might be eventually replaced by special purpose UIs, in particular evim and gvimdiff.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 12, 2014

Member

If people actually like these aliases then I won't insist on removing them, but I strongly prefer to improve the default interface, so that "special purpose" UIs are not needed. evim in particular is a misfeature. Does anyone use evim?

Member

justinmk commented Dec 12, 2014

If people actually like these aliases then I won't insist on removing them, but I strongly prefer to improve the default interface, so that "special purpose" UIs are not needed. evim in particular is a misfeature. Does anyone use evim?

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 12, 2014

Contributor

Does anyone use evim?

I don't think so. Anyway, would neovim remove runtime/evim.vim too, or keep it for backwards compatibility?

Also, you are right, in that it is not terribly important to keep these aliases. As you say, people who use them can set them up themselves or rely on the distributors to provide them.

I mentioned "special purpose UIs" because I was thinking of eventually having interfaces like
this
for diff mode. I don't think the widgets and layouts required for this are necessarily useful in the default interfaces (or non-default general purpose interfaces even).

Contributor

fmoralesc commented Dec 12, 2014

Does anyone use evim?

I don't think so. Anyway, would neovim remove runtime/evim.vim too, or keep it for backwards compatibility?

Also, you are right, in that it is not terribly important to keep these aliases. As you say, people who use them can set them up themselves or rely on the distributors to provide them.

I mentioned "special purpose UIs" because I was thinking of eventually having interfaces like
this
for diff mode. I don't think the widgets and layouts required for this are necessarily useful in the default interfaces (or non-default general purpose interfaces even).

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 12, 2014

In systems that support it, you can type vimd, which is shorter than vim -d. I think the *diff invocations are nice to have.

I suppose, but IMO this is something that should be done by the user, as it lacks consistency given only a select few commands have their symlink handling provided for. I can understand keeping just that symlink as IIRC git has hardcoded references to vimdiff, but I'm not sure about keeping all the other ones. For example, Vim on Arch Linux only has three of the 11 aliases mentioned in the man pages (10 at the top of vim.1 + vimdiff.1).

I don't think so. Anyway, would neovim remove runtime/evim.vim too, or keep it for backwards compatibility?

I can understand providing backwards compatibility for popular commands, but I don't think this is one of them. After looking at :h evim-keys, I'm even more convinced this is an out of place feature worth totally removing:

EVim runs Vim as click-and-type editor.  This is very unlike the original Vi
idea.  But it helps for people that don't use Vim often enough to learn the
commands.  Hopefully they will find out that learning to use Normal mode
commands will make their editing much more effective.

I've personally never seen anyone even mention it, as if vim is too strange then nano or pico are usually recommended.

ghost commented Dec 12, 2014

In systems that support it, you can type vimd, which is shorter than vim -d. I think the *diff invocations are nice to have.

I suppose, but IMO this is something that should be done by the user, as it lacks consistency given only a select few commands have their symlink handling provided for. I can understand keeping just that symlink as IIRC git has hardcoded references to vimdiff, but I'm not sure about keeping all the other ones. For example, Vim on Arch Linux only has three of the 11 aliases mentioned in the man pages (10 at the top of vim.1 + vimdiff.1).

I don't think so. Anyway, would neovim remove runtime/evim.vim too, or keep it for backwards compatibility?

I can understand providing backwards compatibility for popular commands, but I don't think this is one of them. After looking at :h evim-keys, I'm even more convinced this is an out of place feature worth totally removing:

EVim runs Vim as click-and-type editor.  This is very unlike the original Vi
idea.  But it helps for people that don't use Vim often enough to learn the
commands.  Hopefully they will find out that learning to use Normal mode
commands will make their editing much more effective.

I've personally never seen anyone even mention it, as if vim is too strange then nano or pico are usually recommended.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 12, 2014

Contributor

I just ran a little query on /r/vim and it seems like vimdiff is the more popular alias, so I think it would be safe to keep that (and only that).

I agree evim is just silly to have.

Vim on Arch Linux only has three of the 11 aliases mentioned in the man pages

In Arch, the vi and gvim packages provide together all the aliases. vim only provides rvim, rview, vim and `vimdiff.

Contributor

fmoralesc commented Dec 12, 2014

I just ran a little query on /r/vim and it seems like vimdiff is the more popular alias, so I think it would be safe to keep that (and only that).

I agree evim is just silly to have.

Vim on Arch Linux only has three of the 11 aliases mentioned in the man pages

In Arch, the vi and gvim packages provide together all the aliases. vim only provides rvim, rview, vim and `vimdiff.

@fmoralesc fmoralesc referenced this issue Dec 12, 2014

Merged

[RFC] Remove "easy" mode. #1656

5 of 5 tasks complete
@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 13, 2014

Contributor

A little update on the /r/vim thread: it seems like removing vimdiff would incite a worse revolt than removing ex mode could ever cause.

Contributor

fmoralesc commented Dec 13, 2014

A little update on the /r/vim thread: it seems like removing vimdiff would incite a worse revolt than removing ex mode could ever cause.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

it seems like removing vimdiff would incite a worse revolt than removing ex mode could ever cause.

We cannot install symlinks or manpages for any of these aliases, because it would conflict with Vim. Only question of this thread, then, is whether to keep the magic handling in parse_command_name(). We definitely must remove the manpages and symlinks (if our make install even creates those symlinks at all).

Member

justinmk commented Dec 13, 2014

it seems like removing vimdiff would incite a worse revolt than removing ex mode could ever cause.

We cannot install symlinks or manpages for any of these aliases, because it would conflict with Vim. Only question of this thread, then, is whether to keep the magic handling in parse_command_name(). We definitely must remove the manpages and symlinks (if our make install even creates those symlinks at all).

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 13, 2014

Contributor

@justinmk Couldn't we provide nvimdiff (and rnvimdiffperhaps)? I would favor nvdiff and `rnvdiff though, which are shorter.

Contributor

fmoralesc commented Dec 13, 2014

@justinmk Couldn't we provide nvimdiff (and rnvimdiffperhaps)? I would favor nvdiff and `rnvdiff though, which are shorter.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

No one is going to revolt if we don't provide nvimdiff :) They can use nvim -d.

Member

justinmk commented Dec 13, 2014

No one is going to revolt if we don't provide nvimdiff :) They can use nvim -d.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 13, 2014

Contributor

I feel entitled to nvimdiff already! lol /jk

Contributor

fmoralesc commented Dec 13, 2014

I feel entitled to nvimdiff already! lol /jk

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

If we keep the handling in parse_command_name(), then alias vimdiff=nvim should work. Other than that, let's not perpetuate the same misfeature with a new set of names.

Member

justinmk commented Dec 13, 2014

If we keep the handling in parse_command_name(), then alias vimdiff=nvim should work. Other than that, let's not perpetuate the same misfeature with a new set of names.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 13, 2014

Contributor

Of course (I forgot for a second how this worked, and you are right). However, somehow I feel that if nvim is going to delegate the aliases to the shell, parse_command_name is simply redundant. Aliasing vimdiff to nvim -d is just as easy.

Anyway, to wrap the discussion up:

  • The decision around the question posed by this issue in regards to aliases, then, is that nvim aliases will be removed by default (as they are de facto already)? If so, will parse_command_name() be kept?
  • Removing evim is clearly a "yes" (and my PR should cover that), and
  • Removing xxd is a "no" (although not as clearly), because it provides something useful, but some integration mode must be developed (we can't depend on vim being installed for it being available, even though nothing should break if xxd is not available).
Contributor

fmoralesc commented Dec 13, 2014

Of course (I forgot for a second how this worked, and you are right). However, somehow I feel that if nvim is going to delegate the aliases to the shell, parse_command_name is simply redundant. Aliasing vimdiff to nvim -d is just as easy.

Anyway, to wrap the discussion up:

  • The decision around the question posed by this issue in regards to aliases, then, is that nvim aliases will be removed by default (as they are de facto already)? If so, will parse_command_name() be kept?
  • Removing evim is clearly a "yes" (and my PR should cover that), and
  • Removing xxd is a "no" (although not as clearly), because it provides something useful, but some integration mode must be developed (we can't depend on vim being installed for it being available, even though nothing should break if xxd is not available).
@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

Aliasing vimdiff to nvim -d is just as easy.

True. I don't feel too strongly about it, I'm ok with removing parse_command_name() or keeping it. Since it's a small, self-contained bit of code, I tend to lean towards keeping it until someone can test the possible side effects of removing it and verify that there is no problem.

we can't depend on vim being installed for [xxd] being available,

I never looked into this, but it's weird that xxd is bundled with Vim even on systems that have package managers. E.g., I can't sudo apt-get install xxd. WTF. This is annoying. We will have to deal with this somehow, we can't remove xxd support, period.

Member

justinmk commented Dec 13, 2014

Aliasing vimdiff to nvim -d is just as easy.

True. I don't feel too strongly about it, I'm ok with removing parse_command_name() or keeping it. Since it's a small, self-contained bit of code, I tend to lean towards keeping it until someone can test the possible side effects of removing it and verify that there is no problem.

we can't depend on vim being installed for [xxd] being available,

I never looked into this, but it's weird that xxd is bundled with Vim even on systems that have package managers. E.g., I can't sudo apt-get install xxd. WTF. This is annoying. We will have to deal with this somehow, we can't remove xxd support, period.

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Dec 13, 2014

Member

Aliasing vimdiff to nvim -d is just as easy.

This might prohibit Neovim from being a complete replacement for Vim in Ubuntu, which uses an "alternatives" system. The way it works is that e.g. /usr/bin/vim is a symlink to /etc/alternatives/vim, which in turn links to /usr/bin/vim.tiny (Ubuntu has multiple builds of Vim with different feature sets). So under Ubuntu, Neovim could provide an alternative to e.g. vimdiff by symlinking it to /usr/bin/nvim. That won't work out-of-the-box if parse_command_name is removed, if I understood all of this correctly.

Member

fwalch commented Dec 13, 2014

Aliasing vimdiff to nvim -d is just as easy.

This might prohibit Neovim from being a complete replacement for Vim in Ubuntu, which uses an "alternatives" system. The way it works is that e.g. /usr/bin/vim is a symlink to /etc/alternatives/vim, which in turn links to /usr/bin/vim.tiny (Ubuntu has multiple builds of Vim with different feature sets). So under Ubuntu, Neovim could provide an alternative to e.g. vimdiff by symlinking it to /usr/bin/nvim. That won't work out-of-the-box if parse_command_name is removed, if I understood all of this correctly.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

@fwalch Thank you, that's a great point. Let's leave that function then.

I guess that means removing evim precludes Neovim from being a "complete replacement" also, but it doesn't really matter because the removal of Vi-compatiblity already made that choice for us.

Ultimately what matters is that users never have to think about this crap again. sudo apt-get install nvim, that's it. Not nvim.tiny, not nvimnox, etc.

Member

justinmk commented Dec 13, 2014

@fwalch Thank you, that's a great point. Let's leave that function then.

I guess that means removing evim precludes Neovim from being a "complete replacement" also, but it doesn't really matter because the removal of Vi-compatiblity already made that choice for us.

Ultimately what matters is that users never have to think about this crap again. sudo apt-get install nvim, that's it. Not nvim.tiny, not nvimnox, etc.

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Dec 13, 2014

Member

E.g., I can't sudo apt-get install xxd.

I think we can rely on packagers to solve this. E.g. for the Ubuntu PPA, we can create a stand-alone package for xxd. It just needs to conflict with the distribution's vim package, since that provides xxd as well. "Non-vim" nvim users can install neovim and xxd from separate packages, others can use xxd from the "vim" package.

I guess that means removing evim precludes Neovim from being a "complete replacement" also, but it doesn't really matter because the removal of Vi-compatiblity already made that choice for us.

As long as nvim can provide the most-used "aliases" like vimdiff, that should be alright. Although technically the Ubuntu package could just ship with "alias" shell scripts and we could get rid of parse_command_name().

#!/bin/sh
exec nvim -d "$@"
Member

fwalch commented Dec 13, 2014

E.g., I can't sudo apt-get install xxd.

I think we can rely on packagers to solve this. E.g. for the Ubuntu PPA, we can create a stand-alone package for xxd. It just needs to conflict with the distribution's vim package, since that provides xxd as well. "Non-vim" nvim users can install neovim and xxd from separate packages, others can use xxd from the "vim" package.

I guess that means removing evim precludes Neovim from being a "complete replacement" also, but it doesn't really matter because the removal of Vi-compatiblity already made that choice for us.

As long as nvim can provide the most-used "aliases" like vimdiff, that should be alright. Although technically the Ubuntu package could just ship with "alias" shell scripts and we could get rid of parse_command_name().

#!/bin/sh
exec nvim -d "$@"
@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

E.g. for the Ubuntu PPA, we can create a stand-alone package for xxd.

I thought about that, but we may have quite an uphill battle there. It may be easier to:

  • ship with xxd,
  • install it to something like /usr/bin/nvimxxd
  • special-case :!xxd to first search $PATH for xxd, and if not found, use nvimxxd

Or, something like that. Hopefully something more elegant than that.

Member

justinmk commented Dec 13, 2014

E.g. for the Ubuntu PPA, we can create a stand-alone package for xxd.

I thought about that, but we may have quite an uphill battle there. It may be easier to:

  • ship with xxd,
  • install it to something like /usr/bin/nvimxxd
  • special-case :!xxd to first search $PATH for xxd, and if not found, use nvimxxd

Or, something like that. Hopefully something more elegant than that.

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Dec 13, 2014

Member

I thought about that, but we may have quite an uphill battle there.

The only thing is that if vim is not installed, Neovim users have to be aware that they have to install an additional package. They could be notified about that by adding xxd to the recommended dependencies. That would break "sudo apt-get install nvim, that's it", though.

Member

fwalch commented Dec 13, 2014

I thought about that, but we may have quite an uphill battle there.

The only thing is that if vim is not installed, Neovim users have to be aware that they have to install an additional package. They could be notified about that by adding xxd to the recommended dependencies. That would break "sudo apt-get install nvim, that's it", though.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 13, 2014

Member

Neovim users have to be aware that they have to install an additional package.

Not sure which case you are referring to, but in my last comment I am suggesting that we bundle fooxxd with nvim. So no extra install step required.

Member

justinmk commented Dec 13, 2014

Neovim users have to be aware that they have to install an additional package.

Not sure which case you are referring to, but in my last comment I am suggesting that we bundle fooxxd with nvim. So no extra install step required.

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Dec 13, 2014

Member

Yes, I was just considering how we could avoid that (because we'd need to rewrite :!xxd, and that sounds slightly hacky).

Member

fwalch commented Dec 13, 2014

Yes, I was just considering how we could avoid that (because we'd need to rewrite :!xxd, and that sounds slightly hacky).

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Dec 13, 2014

Contributor

So under Ubuntu, Neovim could provide an alternative to e.g. vimdiff by symlinking it to /usr/bin/nvim.

However, should neovim provide this? Regardless,

Although technically the Ubuntu package could just ship with "alias" shell scripts and we could get rid of parse_command_name().

👍 This moves this all to the distribution level, which I thought was the idea. As I said earlier in the thread, I believe this might be more convenient to have at upstream level, but if not, then this seems reasonable.

Contributor

fmoralesc commented Dec 13, 2014

So under Ubuntu, Neovim could provide an alternative to e.g. vimdiff by symlinking it to /usr/bin/nvim.

However, should neovim provide this? Regardless,

Although technically the Ubuntu package could just ship with "alias" shell scripts and we could get rid of parse_command_name().

👍 This moves this all to the distribution level, which I thought was the idea. As I said earlier in the thread, I believe this might be more convenient to have at upstream level, but if not, then this seems reasonable.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 9, 2015

After re-reading this thread, it seems like general consensus is that extra interfaces should be removed. Here's the interfaces (from starting.txt) which I'm referring to:

ex     vim -e      Start in Ex mode (see |Ex-mode|).               *ex*
exim   vim -E      Start in improved Ex mode (see |Ex-mode|).      *exim*
                       (normally not installed)
view   vim -R      Start in read-only mode (see |-R|).             *view*
gvim   vim -g      Start the GUI (see |gui|).                      *gvim*
gex    vim -eg     Start the GUI in Ex mode.                     *gex*
gview  vim -Rg     Start the GUI in read-only mode.              *gview*
rvim   vim -Z      Like "vim", but in restricted mode (see |-Z|)   *rvim*
rview  vim -RZ     Like "view", but in restricted mode.          *rview*
rgvim  vim -gZ     Like "gvim", but in restricted mode.          *rgvim*
rgview vim -RgZ    Like "gview", but in restricted mode.         *rgview*

The only one I'm not completely sure about removing is gvim. I think there's no need for it as you would just call the name of your UI frontend directly, like neovim-qt, but this is just conjecture.

ghost commented Feb 9, 2015

After re-reading this thread, it seems like general consensus is that extra interfaces should be removed. Here's the interfaces (from starting.txt) which I'm referring to:

ex     vim -e      Start in Ex mode (see |Ex-mode|).               *ex*
exim   vim -E      Start in improved Ex mode (see |Ex-mode|).      *exim*
                       (normally not installed)
view   vim -R      Start in read-only mode (see |-R|).             *view*
gvim   vim -g      Start the GUI (see |gui|).                      *gvim*
gex    vim -eg     Start the GUI in Ex mode.                     *gex*
gview  vim -Rg     Start the GUI in read-only mode.              *gview*
rvim   vim -Z      Like "vim", but in restricted mode (see |-Z|)   *rvim*
rview  vim -RZ     Like "view", but in restricted mode.          *rview*
rgvim  vim -gZ     Like "gvim", but in restricted mode.          *rgvim*
rgview vim -RgZ    Like "gview", but in restricted mode.         *rgview*

The only one I'm not completely sure about removing is gvim. I think there's no need for it as you would just call the name of your UI frontend directly, like neovim-qt, but this is just conjecture.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 9, 2015

I forgot to mention the whole reason for that: would anyone object to a PR removing the above interfaces in favor of their command line arguments?

ghost commented Feb 9, 2015

I forgot to mention the whole reason for that: would anyone object to a PR removing the above interfaces in favor of their command line arguments?

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Feb 9, 2015

Contributor

I think the -g variants might go, but I'm not so sure about the others.
When discussing the removal of ex mode, it was settled that the command
line ex mode would be preserved.

Or do you mean to merely remove the aliases?
On Feb 9, 2015 5:38 PM, "Michael Reed" notifications@github.com wrote:

I forgot to mention the whole reason for that: would anyone object to a PR
removing the interfaces above?


Reply to this email directly or view it on GitHub
#1646 (comment).

Contributor

fmoralesc commented Feb 9, 2015

I think the -g variants might go, but I'm not so sure about the others.
When discussing the removal of ex mode, it was settled that the command
line ex mode would be preserved.

Or do you mean to merely remove the aliases?
On Feb 9, 2015 5:38 PM, "Michael Reed" notifications@github.com wrote:

I forgot to mention the whole reason for that: would anyone object to a PR
removing the interfaces above?


Reply to this email directly or view it on GitHub
#1646 (comment).

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 9, 2015

Yes, only the aliases.

ghost commented Feb 9, 2015

Yes, only the aliases.

@fmoralesc

This comment has been minimized.

Show comment
Hide comment
@fmoralesc

fmoralesc Feb 9, 2015

Contributor

Ah, I guess the consensus on that is as you thought. 👍
On Feb 9, 2015 5:49 PM, "Michael Reed" notifications@github.com wrote:

Yes, only the aliases.


Reply to this email directly or view it on GitHub
#1646 (comment).

Contributor

fmoralesc commented Feb 9, 2015

Ah, I guess the consensus on that is as you thought. 👍
On Feb 9, 2015 5:49 PM, "Michael Reed" notifications@github.com wrote:

Yes, only the aliases.


Reply to this email directly or view it on GitHub
#1646 (comment).

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Feb 9, 2015

Contributor

About xxd: you can consider removing it entirely for linux and using hexdump instead. You need to use format file with the following contents to have the output exactly matching xxd output:

"%07.7_ax:" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x"
"  " 16/1 "%_p"
"\n"

(note: I do not quite like lots of repeats on the first line, but failed to figure out alternative solution). I have hexdump in sys-apps/util-linux package alongside with such interesting (and basic) things like mkfs, fsck, ionice, cal.

Contributor

ZyX-I commented Feb 9, 2015

About xxd: you can consider removing it entirely for linux and using hexdump instead. You need to use format file with the following contents to have the output exactly matching xxd output:

"%07.7_ax:" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x" " " 1/1 "%02x" 1/1 "%02x"
"  " 16/1 "%_p"
"\n"

(note: I do not quite like lots of repeats on the first line, but failed to figure out alternative solution). I have hexdump in sys-apps/util-linux package alongside with such interesting (and basic) things like mkfs, fsck, ionice, cal.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 9, 2015

It looks like OS X has hexdump too, but it's from "BSD" (FreeBSD?) so I'm not sure the output will be the same, and I lack a machine with OS X to test.

ghost commented Feb 9, 2015

It looks like OS X has hexdump too, but it's from "BSD" (FreeBSD?) so I'm not sure the output will be the same, and I lack a machine with OS X to test.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Feb 9, 2015

Contributor

This means that you can make xxd binary either a shell script (*nix) or an external windows-specific dependency bundled into an installer by a release script and remove from this repository entirely.

@Pyrohh It is said to support format files as well. I do not think there are going to be any differences.

Contributor

ZyX-I commented Feb 9, 2015

This means that you can make xxd binary either a shell script (*nix) or an external windows-specific dependency bundled into an installer by a release script and remove from this repository entirely.

@Pyrohh It is said to support format files as well. I do not think there are going to be any differences.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Apr 3, 2015

Member

I think we can close this. There is still a bit of a question regarding xxd, but we can always dig up this issue when we get around to addressing that.

Member

justinmk commented Apr 3, 2015

I think we can close this. There is still a bit of a question regarding xxd, but we can always dig up this issue when we get around to addressing that.

@justinmk justinmk closed this Apr 3, 2015

@jdavis jdavis referenced this issue Apr 4, 2015

Merged

Upcoming Newsletter #82

22 of 22 tasks complete
@Earnestly

This comment has been minimized.

Show comment
Hide comment
@Earnestly

Earnestly Dec 9, 2015

If only hexdump was even remotely comparable to xxd. Sadly it seems hexdump is not capable of outputing a format like xxd -b and the format needed to emulate xxd itself is gross, even as a wrapper.

This is not to mention the other functions it had which I have used quite often such as generating character arrays in C.

This decision was probably made too hastily by people who have admitted no personal requirements/understanding.

However it would probably make more sense to package xxd as a separate tool given how useful it is compared to hexdump.

Earnestly commented Dec 9, 2015

If only hexdump was even remotely comparable to xxd. Sadly it seems hexdump is not capable of outputing a format like xxd -b and the format needed to emulate xxd itself is gross, even as a wrapper.

This is not to mention the other functions it had which I have used quite often such as generating character arrays in C.

This decision was probably made too hastily by people who have admitted no personal requirements/understanding.

However it would probably make more sense to package xxd as a separate tool given how useful it is compared to hexdump.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 9, 2015

Member

This decision was probably made too hastily by people who have admitted no personal requirements/understanding.

What decision? Only thing that was decided in this issue was to not install aliases that would conflict with Vim, and are redundant with nvim command-line flags. Nothing was decided about xxd, except that we cannot remove it: we must ship with it or depend on it in some fashion, though it is not yet clear how.

Member

justinmk commented Dec 9, 2015

This decision was probably made too hastily by people who have admitted no personal requirements/understanding.

What decision? Only thing that was decided in this issue was to not install aliases that would conflict with Vim, and are redundant with nvim command-line flags. Nothing was decided about xxd, except that we cannot remove it: we must ship with it or depend on it in some fashion, though it is not yet clear how.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Dec 9, 2015

Contributor

@justinmk There is another option which was not discussed: emulate xxd using VimL code. This is rather easy, though much slower then xxd. Other options: convert xxd into a C function available through xxdump(lines[, format_args]) (e.g. call setline(1, xxdump(readfile('/bin/sh', 'b'), {'values': 'hex', 'cols': 16, 'autoskip': 0, 'format': 'ascii', 'groupsize': 2, 'offset': 0}) ('format' is for a number of mutually exclusive switches like -EBCDIC, -e, -include, -postscript; 'values' may be hex, upperhex and bin; -seek was removed as one can truncate lines instead)) and xxparse(lines).

There is also an option to finally start using lua and port xxd to lua: parts of the #243 which execute lua code without parts that translate VimL may be ported for this purpose.

Contributor

ZyX-I commented Dec 9, 2015

@justinmk There is another option which was not discussed: emulate xxd using VimL code. This is rather easy, though much slower then xxd. Other options: convert xxd into a C function available through xxdump(lines[, format_args]) (e.g. call setline(1, xxdump(readfile('/bin/sh', 'b'), {'values': 'hex', 'cols': 16, 'autoskip': 0, 'format': 'ascii', 'groupsize': 2, 'offset': 0}) ('format' is for a number of mutually exclusive switches like -EBCDIC, -e, -include, -postscript; 'values' may be hex, upperhex and bin; -seek was removed as one can truncate lines instead)) and xxparse(lines).

There is also an option to finally start using lua and port xxd to lua: parts of the #243 which execute lua code without parts that translate VimL may be ported for this purpose.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Dec 9, 2015

Member

parts of the #243 which execute lua code without parts that translate VimL may be ported for this purpose.

That's a splendid idea.

Member

justinmk commented Dec 9, 2015

parts of the #243 which execute lua code without parts that translate VimL may be ported for this purpose.

That's a splendid idea.

@Earnestly

This comment has been minimized.

Show comment
Hide comment
@Earnestly

Earnestly Dec 9, 2015

How will your version of xxd create binaries from a dump?

Earnestly commented Dec 9, 2015

How will your version of xxd create binaries from a dump?

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Dec 9, 2015

Contributor

@Earnestly What is the problem? writefile() works in case VimL or C variant is used (basically they are the same, just in case of viml variant xxdump/xxparse will be something like xxd#dump/xxd#parse). Lua has no problems with writing binary data to file.

If you ask how they detect the format, then this is simple: we do not have to be 100% compatible, so can simply add necessary information to the first, last or each line of the dump. Since there are not much variants to detect (basically we need only to tell it what byte order was used and whether format is binary; formats like include or postscript can be easily detected without additional information, other data regarding binary and hex formats does not need additional characters anywhere to be detected), this is just one character somewhere in the line, in the first line or in the last line. Though, of course, one may prefer having second argument to xxparse.

Contributor

ZyX-I commented Dec 9, 2015

@Earnestly What is the problem? writefile() works in case VimL or C variant is used (basically they are the same, just in case of viml variant xxdump/xxparse will be something like xxd#dump/xxd#parse). Lua has no problems with writing binary data to file.

If you ask how they detect the format, then this is simple: we do not have to be 100% compatible, so can simply add necessary information to the first, last or each line of the dump. Since there are not much variants to detect (basically we need only to tell it what byte order was used and whether format is binary; formats like include or postscript can be easily detected without additional information, other data regarding binary and hex formats does not need additional characters anywhere to be detected), this is just one character somewhere in the line, in the first line or in the last line. Though, of course, one may prefer having second argument to xxparse.

@Earnestly

This comment has been minimized.

Show comment
Hide comment
@Earnestly

Earnestly Dec 9, 2015

I'm talking about xxd -r, also I'm not particularly interested in detecting character encodings or byte order, I can select the latter explicitly.

Earnestly commented Dec 9, 2015

I'm talking about xxd -r, also I'm not particularly interested in detecting character encodings or byte order, I can select the latter explicitly.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Dec 9, 2015

Contributor

@Earnestly Where have you seen detecting character encodings? In my variant you are supposed to select byte order when dumping, and dumping is supposed to result in something which makes detection possible when parsing back.

Contributor

ZyX-I commented Dec 9, 2015

@Earnestly Where have you seen detecting character encodings? In my variant you are supposed to select byte order when dumping, and dumping is supposed to result in something which makes detection possible when parsing back.

@Earnestly

This comment has been minimized.

Show comment
Hide comment
@Earnestly

Earnestly Dec 9, 2015

I've not seen detecting character encodings and I've never looked for it. (Not sure why you're asking me this question, btw, sorry if I'm misinterpreting.)

As for xxd I'm just simply going to package it as standalone instead as it is a useful tool even outside the context of an editor. It's only ~700 lines of C.

Earnestly commented Dec 9, 2015

I've not seen detecting character encodings and I've never looked for it. (Not sure why you're asking me this question, btw, sorry if I'm misinterpreting.)

As for xxd I'm just simply going to package it as standalone instead as it is a useful tool even outside the context of an editor. It's only ~700 lines of C.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment