[arch-dev-public] Vi package
Hi, I was looking at FS#20778 and was wondering what we should do with it. While it is true that the "traditional vi" is buggy and not user friendly. It does not seems that BusyBox is a good alternative. There are options here: 1) Statu quo Pro : * Support for multi-byte character encodings like UTF-8 * Small size Cons : * Did I said that it is buggy ? * Use of this old software in the installer may give a strange impression to new users as they are faced with an editor from the '70 on a distro where everything is up to date. * Appears to be no longer be updated upstream. 2) nvi Pro : * Small size * More advanced features : multiple undo, command history, filename completions, multiple edit buffers, etc. * Version of vi that is shipped with {Free,Open,Net,DragonFly}BSD Cons : * No support for muti-byte character encoding * Appears to be no longer be updated 3) elvis Pro : * Small size * Advanced features * Shipped with Slackware and Debian Cons : * the editor has been abandoned upstream since about March 2004. * the Debian package has only an incomplete implementation of support for multi-byte characters 4) A compact version of vim http://packages.ubuntu.com/en/maverick/vim-tiny https://github.com/BlackIkeEagle/herecura/tree/master/herecura-stable/vim Pro : * Most popular vi implementation * Advanced features * UTF-8 support * Avoid dependency on vim-runtime. Cons : * Size : not as bloated as the full vim, but larger than ex/vi. On Ubuntu x86_64, installation size is 836 kB which is reasonable. * May need a duplicate PKGBUILD as vim is in [extra] while vi is in [core] Opinions? Stéphane
[2011-02-09 11:23:53 -0500] Stéphane Gaudreault:
4) A compact version of vim
Since it is both maintained upstream and featureful, it seems like the most reasonable choice to me. And I personally think that the few additional 100KB compared to other vi's is worth it.
* May need a duplicate PKGBUILD as vim is in [extra] while vi is in [core]
Would you still name that package "vi" and prevent it from conflicting with the vim of [extra]? Or something like "vim-tiny" that would conflict and provide vim? -- Gaetan
Le 10 février 2011 02:51:26, Gaetan Bisson a écrit :
[2011-02-09 11:23:53 -0500] Stéphane Gaudreault:
4) A compact version of vim
Since it is both maintained upstream and featureful, it seems like the most reasonable choice to me. And I personally think that the few additional 100KB compared to other vi's is worth it.
I received a couple of emails from users that wanted to express their preference for a vim-based vi.
* May need a duplicate PKGBUILD as vim is in [extra] while vi is in [core]
Would you still name that package "vi" and prevent it from conflicting with the vim of [extra]? Or something like "vim-tiny" that would conflict and provide vim?
I do not have a strong opinion on this, but the first choice (name that package "vi" and prevent it from conflicting with the vim of [extra]) is probably simpler as the new vim-based vi will be a drop-in replacement of the old vi pkg. Stéphane
On 02/10/2011 04:22 PM, Stéphane Gaudreault wrote:
Le 10 février 2011 02:51:26, Gaetan Bisson a écrit :
[2011-02-09 11:23:53 -0500] Stéphane Gaudreault:
4) A compact version of vim
Since it is both maintained upstream and featureful, it seems like the most reasonable choice to me. And I personally think that the few additional 100KB compared to other vi's is worth it.
I received a couple of emails from users that wanted to express their preference for a vim-based vi.
* May need a duplicate PKGBUILD as vim is in [extra] while vi is in [core]
Would you still name that package "vi" and prevent it from conflicting with the vim of [extra]? Or something like "vim-tiny" that would conflict and provide vim?
I do not have a strong opinion on this, but the first choice (name that package "vi" and prevent it from conflicting with the vim of [extra]) is probably simpler as the new vim-based vi will be a drop-in replacement of the old vi pkg.
Stéphane
we did had vi being a stripped vim package in the past. We got rid of it because upstream vim started to not helping arch users because "it was broken". That impression was given by our users who didn't understand that python and other crap that vim support is in vim package and not in vi. now the same situation is now. Some users don't understand that vi is nvi and what they want is in vim. -- Ionuț
Le 10 février 2011 10:24:18, Ionuț Bîru a écrit :
On 02/10/2011 04:22 PM, Stéphane Gaudreault wrote:
Le 10 février 2011 02:51:26, Gaetan Bisson a écrit :
[2011-02-09 11:23:53 -0500] Stéphane Gaudreault:
4) A compact version of vim
Since it is both maintained upstream and featureful, it seems like the most reasonable choice to me. And I personally think that the few additional 100KB compared to other vi's is worth it.
I received a couple of emails from users that wanted to express their preference for a vim-based vi.
* May need a duplicate PKGBUILD as vim is in [extra] while vi is in [core]
Would you still name that package "vi" and prevent it from conflicting with the vim of [extra]? Or something like "vim-tiny" that would conflict and provide vim?
I do not have a strong opinion on this, but the first choice (name that package "vi" and prevent it from conflicting with the vim of [extra]) is probably simpler as the new vim-based vi will be a drop-in replacement of the old vi pkg.
Stéphane
we did had vi being a stripped vim package in the past. We got rid of it because upstream vim started to not helping arch users because "it was broken". That impression was given by our users who didn't understand that python and other crap that vim support is in vim package and not in vi.
This is a good point. Maybe that confusion came from the name of the package/executable (vi). In Ubuntu for example there is no package called "vi" afaik. In the vim-tiny package, the main executable is /usr/bin/vim.tiny and it has it's own configuration file in /etc/vim/vimrc.tiny. I assume that way there is no confusion between the full vim and the compact one.
now the same situation is now. Some users don't understand that vi is nvi and what they want is in vim.
vi is not nvi, it is the Traditional Vi :) Stéphane
[2011-02-10 11:13:58 -0500] Stéphane Gaudreault:
In the vim-tiny package, the main executable is /usr/bin/vim.tiny and it has it's own configuration file in /etc/vim/vimrc.tiny. I assume that way there is no confusion between the full vim and the compact one.
I find the name "vim-tiny" makes it quite explicit what the package is; however, I wouldn't bother avoiding conflicts with "vim" since I do not see why somebody would want to have this stripped-down version installed alongside the full-featured vim. But that's only my opinion; since you do the work, you decide. :) -- Gaetan
On Thu, 2011-02-10 at 17:24 +0200, Ionuț Bîru wrote:
we did had vi being a stripped vim package in the past. We got rid of it because upstream vim started to not helping arch users because "it was broken". That impression was given by our users who didn't understand that python and other crap that vim support is in vim package and not in vi.
now the same situation is now. Some users don't understand that vi is nvi and what they want is in vim.
I don't think we should go back to a fucked vim package with /etc/virc like we had it in the past. We switched from that to nvi, which fucked up files if they contained unicode stuff (it would just segfault in the middle of a save operation, leaving you with a broken file). After that, we decided to go for busybox, which works fairly well as vi, is maintained, but doesn't do anything that looks like vim. IMHO vi is totally useless on most systems. I prefer to uninstall it and do ln -s vim /usr/bin/vi instead. Users who complain about vi being too limited should do that too.
On Thu, 10 Feb 2011 17:52:16 +0100, Jan de Groot wrote:
On Thu, 2011-02-10 at 17:24 +0200, Ionuț Bîru wrote:
we did had vi being a stripped vim package in the past. We got rid of it because upstream vim started to not helping arch users because "it was broken". That impression was given by our users who didn't understand that python and other crap that vim support is in vim package and not in vi.
now the same situation is now. Some users don't understand that vi is nvi and what they want is in vim.
I don't think we should go back to a fucked vim package with /etc/virc like we had it in the past. We switched from that to nvi, which fucked up files if they contained unicode stuff (it would just segfault in the middle of a save operation, leaving you with a broken file). After that, we decided to go for busybox, which works fairly well as vi, is maintained, but doesn't do anything that looks like vim.
IMHO vi is totally useless on most systems. I prefer to uninstall it and do ln -s vim /usr/bin/vi instead. Users who complain about vi being too limited should do that too.
I wonder the same. I cannot imagine why anybody would want to use vi. Personally I would not mind if nano was the only interactive editor in [core]. But keeping the current busybox vi is also fine. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 11 February 2011 00:59, Pierre Schmitz <pierre@archlinux.de> wrote:
I wonder the same. I cannot imagine why anybody would want to use vi. Personally I would not mind if nano was the only interactive editor in [core].
I am in full agreement.
Le 10 février 2011 15:28:12, Ray Rashif a écrit :
On 11 February 2011 00:59, Pierre Schmitz <pierre@archlinux.de> wrote:
I wonder the same. I cannot imagine why anybody would want to use vi. Personally I would not mind if nano was the only interactive editor in [core].
I am in full agreement.
+1 Yesterday, I hesitated a lot to write this in my list of possible options. I think that POSIX (and maybe other standards) compliance require the presence of a VI editor ... but since we do not follow the POSIX standard in a lot of way this might not be a very important issue after all. Nano is just fine (although I use it only during installation) and the place of the traditional ex-vi is in a museum ... so I must admit that this would be my favorite option too :) Stéphane
On 11/02/11 06:28, Ray Rashif wrote:
On 11 February 2011 00:59, Pierre Schmitz<pierre@archlinux.de> wrote:
I wonder the same. I cannot imagine why anybody would want to use vi. Personally I would not mind if nano was the only interactive editor in [core].
I am in full agreement.
My last Arch install was the first and only time I have ever used nano. And that was only because I could not use the piece of crap that is our current vi package (I'm not vim guru but I usually manage in vim just fine). Is the current vi package actually usable for an install by someone more familiar with it? Allan
Am 10.02.2011 17:52, schrieb Jan de Groot:
After that, we decided to go for busybox, which works fairly well as vi, is maintained, but doesn't do anything that looks like vim.
Wrong. We have ex-vi. On my system, I have a busybox-based vi, but I never use it.
Hi, this comes up every once in a while, and while the current situation is not exactly satisfying, it's IMHO the best compromise we have. Here is why: In my and many others opinion, vi sole purpose ist to maintain standard compliance plus to serve as simple editor on install time. For everything else, let me repeat that: EVERYTHING ELSE, please install vim. Thank you! So, why not have vim, a mini vim, vim-tiny, a stripped version of vim instead? Because it's a lot of work and more importantly a damn error prone thing to do for very little benefit. Vim, no matter how stripped down, comes with a significant runtime. This runtime needs to be stripped down manually but still will be bigger than ex-vi and friends. Moreover, any vim/gvim package must be designed complementary to a) provide everything the stripped vi doesn't have b) don't conflict with with the stripped vi That is a lot of work and very error prone. We had that partially in the past and let's just say it didn't go so well. Did anyone notice the release speed of vim? It needs to be rechecked and veryfied for every release. On top of that, because vi will be in core, every vim/gvim release will have to be delayed by the testing period for vi. That too we did have in the past and it doesn't ring so well with both users and developers. So in conclusion, I see very little benefit in having a more functional vi package, when most can be achieved by installing vim for what you wanna do in the editor. The difference in typing "vi" or "vim" is a rather semantic one and if you really can't stand it, Jan's symlink idea works just fine. The cost for splitting it in a vi and a vim packag is simply way to high. - T On Wed, 09 Feb 2011, Stéphane Gaudreault wrote:
Hi,
I was looking at FS#20778 and was wondering what we should do with it.
While it is true that the "traditional vi" is buggy and not user friendly. It does not seems that BusyBox is a good alternative.
There are options here:
1) Statu quo Pro : * Support for multi-byte character encodings like UTF-8 * Small size Cons : * Did I said that it is buggy ? * Use of this old software in the installer may give a strange impression to new users as they are faced with an editor from the '70 on a distro where everything is up to date. * Appears to be no longer be updated upstream.
2) nvi Pro : * Small size * More advanced features : multiple undo, command history, filename completions, multiple edit buffers, etc. * Version of vi that is shipped with {Free,Open,Net,DragonFly}BSD Cons : * No support for muti-byte character encoding * Appears to be no longer be updated
3) elvis Pro : * Small size * Advanced features * Shipped with Slackware and Debian Cons : * the editor has been abandoned upstream since about March 2004. * the Debian package has only an incomplete implementation of support for multi-byte characters
4) A compact version of vim http://packages.ubuntu.com/en/maverick/vim-tiny https://github.com/BlackIkeEagle/herecura/tree/master/herecura-stable/vim Pro : * Most popular vi implementation * Advanced features * UTF-8 support * Avoid dependency on vim-runtime. Cons : * Size : not as bloated as the full vim, but larger than ex/vi. On Ubuntu x86_64, installation size is 836 kB which is reasonable. * May need a duplicate PKGBUILD as vim is in [extra] while vi is in [core]
Opinions?
Stéphane
Le 9 février 2011 11:23:53, Stéphane Gaudreault a écrit :
I was looking at FS#20778 and was wondering what we should do with it.
As a wrap up : No consensus has been reached, so I am going to suggest to close FS#20778 as "won't fix" and continue with the statu quo. Someone suggested to simply remove the vi pkg from [core]. Although I agree with this proposition, this is not a top priority for me. If other devs want to organize a vote on this then it could be another way to close the discussion. Stéphane
participants (9)
-
Allan McRae
-
Gaetan Bisson
-
Ionuț Bîru
-
Jan de Groot
-
Pierre Schmitz
-
Ray Rashif
-
Stéphane Gaudreault
-
Thomas Bächler
-
Tobias Kieslich