Arch Linux

frankly, we can do that but ex-vi from core is meant to be used just on the console, and when in X or bigger environments I will always use vim. It probably won't hurt though to set the value higher.

and besides,
[tobias@buran scripts]$ echo $COLUMNS
224
[tobias@buran scripts]$ vi import.lua

runs just fine

On top of working for me, config.h comments suggest that it's a bad idea to touch the TUBECOL number.

No idea why it works for you. But the only comment mentioning TUBECOLS I can find in config.h is:

TUBECOLS should stay at 160 at least since this defines
the maximum length of opening on hardcopies and allows two lines
of open on terminals like adm3's (glass tty's) where it switches
to pseudo hardcopy mode when a line gets longer than 80 characters.

Which says, unless I am totally mistaken, that it should not be set to a value less than 160.

I think it's important to realize that as KMS becomes more common, even consoles will tend to be wider than 160. Even with vesafb it's not too hard to do exceed that. Once KMS becomes the default, it will require a more-than-averagely-experienced user to be able to make vi work in the case where one wants to use it for system recovery, and that's a fairly lousy position to be in - just imagine the volume of forum threads this will generate.

The comment warning about changing TUBECOLS appears to be talking about ancient hardware terminals rather than about breaking the code, so I'd say it's safe to change.

Frankly, I have to strongly disagree with Tobias here. vi is used by default by visudo, git, subversion and many more applications. It is an editor that should be safe to run in any environment.

Moreover, it doesn't work whenever I log in to our servers, which is very very bad. This must be fixed.

Also, the switch from nvi to ex-vi was made without any comment in subversion, it would have been nice for the reason to be archived there. Changing the severity to critical and assigning Aaron as well, as this strongly affects the core package set and our ISO.

I disagree with Tobias as well. I think the argument that "Well, you're in X, just use vim" is a silly one. This package itself has an issue with wide terminals, and it can be fixed. Saying "well don't use the package" is dumb.

Bumping TUBECOLS seems fine to me.

Also... when did we switch from nvi to ex-vi? Why?

I also agree that bumping TUBECOLS would be best. I've also encounted the problem when I've enabled KMS and have tried to edit things on a tty console.

I thought ex-vi replaced Vim? I put together an AUR package for ex-vi as I found the Vim package defaults to be frustrating (e.g. syntax highlighting, mouse enabled), and also felt it was too bloated for the basic text editing that I use "vi" like editors for.

fair enough, 250 sounds good, or shall we just double the 160, so it becomes 320?

My console has 160, my X terminal already had 202 on the small laptop screen, so 320 sounds reasonable.

From very rough memory, I think the cost per charater in the buffer was two bytes. With RAM being as cheap and as large as it is, I'd suggest making the screen buffer so large at this time that it'd never ever have to be changed again. I
d think something like 512 x 512 (1MB) or even 1024 x 1024 (2MB) would ensure it would never have to be revisited.

I get this error in vi on the console, not in X

in the console `echo $COLUMNS` reports 175

I have a thinkpad T60,

@markzzzsmith
Never say never :) I think we should look for a solution that will handle all cases, not just ones that will handle up to some large boundary. 640KiB was after all supposed to be enough for everyone :P

Now that kms comes by default, it is imperative that we fix this; vi is broken out of the box for nearly every even remotely modern machine. I think that a width of 320 would *probably* cover 30" monitors (the largest that is likely to be encountered), but don't quote me on that. My 24" is 240 cols wide, for reference.

I don't think you get the point here. vi is today meant to be run on small boxes, like old server. At least that are the places I use vi instead of vim. Increasing the buffer means increasing the memory-footprint and yes there are still machines which have very little memory but rely on vi!! Don't break them with increasing the footprint and "memory is cheap" is no argument in this decision.

If your machine has more power and can run vim instead of vi, just do it! Symlink vim to vi and you are happy and still all the people who really need the small vi are happy too.

I vote for keeping it as it is.

Launch with:
$ COLUMNS=80 vi
and vi does't fallback to ex mode in a large terminal.

About TUBECOLS just note that 8 px is the typical font width; a 1920 px monitor gives space for 240 columns. And I don't want to think of someone with a 4 HD monitors xinerama setup.

Seriously, does any of those machines where the big footprint matters run Arch? I pretty much doubt it.

@brain0: you are correct, that I personally run arch just on my server, netbook and laptop and none of them will have a problem with vi having more memory need. But this still doesn't hit the point: vi is for old hardware and vim for new one. Thus what is the sense in increasing the memory need of vi? If you have enough memry run vim (and if it really matters to you, run it in vi compatible mode and you won't notice any difference!!), but let the other people with older hardware use vi.

I still don't understand the reason why this is a bug report? It is a feature request and one that should in my opinion be denied because it has no benefits but just disadvantages.

"vi" is the default editor for many programs. Having those respond with "terminal too wide" in any completely normal situation is a bug.

vi is part of core, vim isn't. If vi in it's current form can't be used on any possible default console size (i.e. the default size for a kms enabled system), then I think it is a bug, and need to be fixed.

Aside from the default editor issues, I don't like using the vim package because it's defaults are not the same as vi's - I don't like syntax highlighing, and I don't like that it interprets mouse movements - I prefer the standard xterm character based application behaviour where my mouse buttons are cut-and-paste. In other words, VIM might be "vi improved", but I don't want or need any of the improvements.

@Rorschach: can you list the disadvantages? Thanks

@Rorschach: We're not changing vi at all. We're changing the vi that is *built* for *Arch Linux* and only *Arch Linux*

Other people that have old crippled machines are (a) NOT running Arch and (b) Welcome to use another distribution that has a smaller vi if the memory footprint of vi is a deciding factor for what distro you use.

Additionally, people are ALWAYS welcome to recompile vi to suit their own needs. It is 100% impossible to cover all cases and make all people happy. The best we can do is cover the _common_ case as it does not break anything.

I absolutely confounded that people think that it is "okay" to ship a vi that doesn't work out of the box. I have ended up symlinking vi to vim on all of my boxes, however I would imagine that booting up and finding a broken vi gives many users a bad impression of arch. IMHO it's bad enough that vim doesn't have normal default configs right now. All these arguments about "old hardware" are insane; the oldest cpu that will run arch is a pentium pro, so I very much doubt that ancient hardware terminals are an issue. When arch came out, targeting builds at i686 meant that only "new" hardware worked... Currently we support relatively old hardware as well, but there's no reason to optimize things for dinosaurs. Anyone running something that old has presumably learned a thing or two and can modify the config files themselves.

It's impressive how people make claims about "normal defaults". We used to have the example file shipping with vim as default -> not good enough. Now we are stripped to almost nothing -> still, not good enough "normal default". It's just claimed that it's not normal without giving any reason why. In any serious discourse people would rip you apart.

On a more constructive note. Yes, vi is targeted as the console editor, mainly to suffice the needs for the installer in core. For anymore serious editing vim is recommended. And contrary to other claims, vi does work out of the box, since most terminals open at sane sizes. BUT, Thomas is right, if $EDITOR is not set, most programs fall back to vi and not to vim. The environment variables are not really in our control, they shouldn't be. So whatever we open in an X-terminal might blow up, which is ugly. Fixing it with settings to 320 shall work not corrupting vi in any way. I'll get on that when I have time again.

@Tobias: Not with KMS. KMS will automatically change your terminal size by default on an ATI card. I know for a fact it happens because it does so on my thinkpad. So on first boot with the newer kernels, vi does NOT work. It is 100% broken

Once we release 2.6.32, the same will happen on Intel cards too. On ATI, there was no way to support KMS without enabling it by default, so we took the hard route and just switched it on by default (in 2.6.32 it will be more stable though). On Intel, we could support it without enabling it by default. However, future Intel drivers will require KMS - that is why I decided that starting with 2.6.32-ARCH, KMS should be on by default on Intel as well. This especially means that our installer will be broken if we don't fix vi, because it uses vi by default.

On my over two year old i915, 1280x800 display, I get a 160 column text console by default, and it's a rather small display by today's standards.

On my over 2 year old G33, 1920x1200 display, the size is even bigger. I don't think bigger displays than that are very common, but you'll never know. I think it's safe to assume 1920x1200 for now, though bigger displays aren't rare. 1920x1200 is the highest supported resolution for single-link DVI though. I don't know if recent Intel chipsets support dual-link, but the G33 sure isn't one of them.

@Aaron: sweet, my box at work has an ATI and it actually runs 2 * 1680x1050 on one screen. KMS requires which drivers to work, radeonhd? (that's what I use)

No, it happens before X. I have no idea what modules it actually uses, I can check when I get home. All I know is that udev loads some module at boot time, and the init output jumps and changes sizes

Maybe it's just me, but isn't this an upstream bug?

If the current console is too big, then why doesn't the editor just use as much as it can handle and ignore the rest?

@Tobias: As with Aaron KMS automatically changes my terminal size unless I specify nokms in my kernel options. It is not driver specific but it is card specific. I have an R500 card, and I think as of 2.6.31 R300-R500 cards will have KMS enabled. In 2.6.32 R600 cards will be supported so you might notice it then.

Tobias, the maintainer, decides on expanding TUBECOLS to 320 on 11/18/09. I agree it's probably the cleanest and most Arch solution to the problem; while we could use nvi or elvis instead and symlink them to vi, it's actually predictable/vanilla/nice knowing that vi is really as close to real vi as we can get.

Attached is a patch and PKGBUILD diff to implement this. I increased TUBESIZE to 32000 to accommodate the new TUBEWIDTH of 320, and left TUBELINES at 100. If in the future we need to go bigger, we can always increase to keep up with screen sizes. The impact of this should be 16k vs 32k allocated when entering visual mode, and so should not affect most people.

Tobias, let me know if you would like me to apply this. I'll check back on Feb bug day if I haven't heard anything by then.

I will do that as soon as I'm back home in CA. Atm, I'm still visiting family in Europe and all I have is a netbook. It should happen soon, since vi in the console on Intel and ATI machines is unusable.

Paul's patch works fine here, tested under x86_64.

this is fixed in testing(s), awaiting signoffs