From: "Alexander E. Patrakov" <patrakov@ums.usu.ru>
To: "Adam Tla/lka" <atlka@pg.gda.pl>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: [PATCH]console:UTF-8 mode compatibility fixes
Date: Sun, 19 Feb 2006 22:07:09 +0500 [thread overview]
Message-ID: <43F8A5BD.3020108@ums.usu.ru> (raw)
In-Reply-To: <20060219161643.GA15459@sunrise.pg.gda.pl>
Adam Tla/lka wrote:
> On Sun, Feb 19, 2006 at 09:24:26AM +0500, Alexander E. Patrakov wrote:
>
>> Adam Tlałka wrote:
>>
>>
>>> Maybe I should remember all bytes of the UTF-sequence to use their
>>> values as a last resort char in case of malformed sequence and 0xfffd
>>> not defined?
>>>
>> Please don't do that. Display question marks instead in the case when
>> 0xfffd is not defined.
>>
>
> Look at the original code. If conv_uni_to_pc fails and there is no replacement
> char (after a clear_unimap for example) and we using US-ASCII we rather
> should see something then sequences of '?' chars.
> Maybe I could change this to:
>
> if (tc == -4) {
> if (c < 128)
> tc = c;
> else
> tc = '?';
> }
>
> What about that?
>
I'd let someone else judge, but that is clearly a broken case that just
has to be declared broken. <joke>could you please also adapt to a font
that has all glyphs looking as smileys?</joke> But it's only three extra
lines of code, so let's accept that "c<128" check.
> Remembering of original bytes is needed if we could then remember
> them in a way so paste from screen gives us the same sequence as it was
> in input.
This doesn't match the behaviour of X.
> With current console design it is impossible is case
> of correct UTF-8 sequences containing undisplayable glyphs or malformed
> sequences.
I agree that, in some cases, it makes sense to copy and paste
undisplayable glyphs. However, IMHO, this should not be allowed for
malformed sequences.
--
Alexander E. Patrakov
next prev parent reply other threads:[~2006-02-19 17:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 23:33 [PATCH]console:UTF-8 mode compatibility fixes Adam Tla/lka
2006-02-18 10:59 ` Andrew Morton
2006-02-18 16:01 ` Adam Tlałka
2006-02-19 4:24 ` Alexander E. Patrakov
2006-02-19 12:45 ` Adam Tla/lka
2006-02-19 16:16 ` Adam Tla/lka
2006-02-19 17:07 ` Alexander E. Patrakov [this message]
2006-02-18 14:17 ` Alexander E. Patrakov
2006-02-19 1:53 ` Thomas Dickey
2006-02-19 4:33 ` Alexander E. Patrakov
2006-02-19 11:47 ` Adam Tla/lka
2006-02-20 1:20 ` Thomas Dickey
2006-03-07 15:05 ` Adam Tlałka
2006-02-19 5:42 ` Alexander E. Patrakov
2006-02-19 10:15 ` Adam Tla/lka
2006-02-19 23:19 ` [PATCH]console:UTF-8 mode compatibility fixes - new version Adam Tla/lka
2006-02-20 8:14 ` [PATCH]console:UTF-8 mode compatibility fixes - new version #1 Adam Tla/lka
[not found] ` <43F72A1E.1090707@ums.usu.ru>
2006-02-18 14:37 ` [PATCH]console:UTF-8 mode compatibility fixes Adam Tlałka
2006-02-19 1:43 ` Thomas Dickey
2006-02-19 10:45 ` Adam Tla/lka
2006-02-18 22:35 ` Adam Tla/lka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43F8A5BD.3020108@ums.usu.ru \
--to=patrakov@ums.usu.ru \
--cc=atlka@pg.gda.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.