Ken Takata wrote:
> > > > Two years ago, you announced closing of Vim-multibyte mailing list.
> > > >
> > > > Vim-multibyte mailing list is closed
> > > > https://groups.google.com/d/msg/vim_announce/3Kzdhtsp9dQ/afcHmpksN7QJ
> > > >
> > > > In the announcement, you said:
> > > >
> > > > > Multi-byte text is a core part of Vim these days, mainly
> > > > > because UTF-8 is wide spread now.
> > > >
> > > > I strongly agree with this. Nowadays, support for UTF-8 is mandatory
> > > > for
> > > > text editors.
> > > > Thus how about removing the `FEAT_MBYTE` build option on next minor
> > > > release
> > > > and make it always available? It can make the code simpler (a bit).
> > > >
> > > > I also think it's better to set `enc=utf-8` as the default on all
> > > > platforms
> > > > near the future. (After the next minor release?)
> > > >
> > > > What do you think?
> > >
> > > I still like to be able to build a tiny Vim with the smallest set of
> > > features. Can be used on rescue systems and embedded systems.
> > > It is especially important to have a minimal set of dependencies, e.g.
> > > no iconv library.
> >
> > Personally I think the difference of size between with/without multibyte
> > support is negligible. As per the result by James, it is 838K vs. 978K.
> > Moreover, Ubuntu (and some other distributions) uses vim-tiny for an alias
> > of vi, however, actually it is vim-tiny with multibyte support.
> >
> > But, okay, I agree with you that it is needed for rescue/embedded systems.
> >
> > Then, how about setting `enc=utf-8` as the default?
Note that utf-8 is already the default on most systems, because the
locale is set in the environment. And if it isn't, Vim probably should
not use utf-8 by its own choice.
> And, I have another proposal.
>
> I propose always enabling FEAT_MBYTE on Windows, because Windows version
> can convert encodings without iconv and will rarely used for rescue/embedded
> systems.
> There are so many `#ifdef FEAT_MBYTE`s in os_win32.c, os_mswin.c and
> gui_w32.c. They exist everywhere calling Unicode APIs. Enabling multibyte
> makes them simpler.
That makes sense. Now that we dropped support for Windows 95 we need to
have the code for Unicode support anyway. It also means that without
FEAT_MBYTE codepage support is pretty bad.
Hmm, I see the default MSVC build is without FEAT_MBYTE. Well, after
changing the default HUGE to something else. Hmm, Tiny build doesn't
work... Looks like an MSVC build without FEAT_MBYTE will fail:
# if !(defined(FEAT_MBYTE) && defined(WIN3264))
# define mch_fopen(n, p) fopen((n), (p))
# endif
And then the proto for mch_fopen() in proto/os_win32.pro conflicts with
the system defined one.
Anyway, using a tiny build and enabling FEAT_MBYTE adds about 140 Kbyte.
On top of about 800 Kbyte. That's still quite a lot.
Building a really tiny version: 780 Kbyte. FEAT_MBYTE adds 135 Kbyte to
that.
To compare: A huge build is about 2 Mbyte.
I haven't checked runtime memory use.
--
ARTHUR: Well, I can't just call you `Man'.
DENNIS: Well, you could say `Dennis'.
ARTHUR: Well, I didn't know you were called `Dennis.'
DENNIS: Well, you didn't bother to find out, did you?
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
