On Wed, Mar 04, 2009 at 01:27:29AM -0500, James Vega wrote: > On Tue, Mar 03, 2009 at 01:12:36PM +0100, Dennis Benzinger wrote: > > I meant systems which have or can use only a small amount of memory. For > > example (16bit) MS-DOS where you can only use 640KB. These systems may > > be rare nowadays but if you'll encounter one you'd probably be happy to > > be able to minimize the size of the binary. > > Indeed, but there are currently checks that prevent Vim from building > with multibyte support on such systems (ints that are smaller than 32 > bit). I guess supporting such OSes would be a reason not to disallow > building without multibyte entirely. > > That does raise the question of where the trade-off between keeping > legacy, mostly unused code versus dropping support occurs.
Actually, according to <http://www.vim.org/download.php>, the 16-bit DOS executable stopped being provided as of Vim 7.2 because 7.2 was too large for DOS' memory model. > > But I didn't try it out how > > much the size differs between a multibyte and a non-multibyte build. > > Therefore I wrote "_probably_ makes the resulting binary smaller" ;-) > > > > So if ripping out non-multibyte support does not make the code much > > simpler or smaller I'd simply keep it. Do you have any idea much simpler > > or smaller the code would be? > > Well, since supporting 16bit systems is still desirable, there'd be no > change in code size. Since 16-bit DOS is out of the picture, are there any other supported OSes which *don't* have 32-bit integers? If so, that changes the weight behind supporting the ability to build Vim without multibyte support. Of course, this whole tangent is just about speculative advantages to only supporting multibyte-capable Vim builds. The primary point of my original post is still to determine whether there are any impediments preventing Vim from using UTF-8 for the default 'encoding' and determining 'termencoding' from the user's locale. Anything else that would happen because of that is just icing on the cake. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <james...@jamessan.com>
signature.asc
Description: Digital signature
