On 12 Jul 2001, Christoph Rohland wrote:
> Yes, we will do that after the discussion if the _feature_ is welcome.
To decide whether a feature is welcome, documentation is needed - and code
isn't. In the first instance, patches to the manual (only) should be
created before the code; then the feature can be discussed on that basis.
After this, testcases can be created; then code (and the coding may feed
back into more testcases and documentation). Even if you don't really
follow this order, the finished product should not be distinguishable from
following it. Software should be aesthetic in implementation as well as
functional.
> Hey, could we please first discuss the content and later the form?
The gcc lists have over 60 Mbyte of mail a month; GCC developers are
mostly sufficiently busy that if you don't arrange for the form of the
patch to be easy to read and understand the intent - by following the
instructions for contributing for GCC - then they probably won't try to.
The same applies when we see patches on other lists as to the 300 people
on gcc-patches directly. Even with clean patches a large proportion may
not end up getting reviewed. But if patches are submitted that don't
follow the instructions for contributing, those just give the impression
that the contributor considers their patch so important that all the
readers should spend their time trying to understand it rather than the
contributor spending their time making it easier to read - even though
that may well not be the actual intent of the contributor.
> Actually we simply provided our internal version for a basis for
> discussion. I would be more interested in the discussion if this an
> accepted feature than getting bashed for some formal requirements.
The impression given by the post first mentioning this patch on linux-utf8
was otherwise - though I would still urge anyone maintaining a patch to
GCC to make it clean from the beginning, whether or not you ever intend to
contribute it to FSF GCC.
In this case, contributing the feature now to FSF GCC would be premature,
but an implementation could be useful *if* this eventually reaches at
least draft technical report stage in the C or C++ committees.
> A question here about standard string literals and UTF8 (I am really
> no specialist about Unicode et al): What hinders anybody to do UCN in
> standard C string literals and UTF8 encoding?
It should already work. But there are probably bugs in this area.
--
Joseph S. Myers
[EMAIL PROTECTED]
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
