Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Unicode in strings
Date: Mon, 3 Jun 2024 05:24:22 -0500
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <v3k5kv$3rpcv$1@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me>
 <2024May11.173149@mips.complang.tuwien.ac.at> <v1preb$2jn47$1@dont-email.me>
 <2024May12.110053@mips.complang.tuwien.ac.at>
 <jwvjzjwid50.fsf-monnier+comp.arch@gnu.org>
 <2024May18.072920@mips.complang.tuwien.ac.at>
 <jwved9t656u.fsf-monnier+comp.arch@gnu.org>
 <2024May25.174807@mips.complang.tuwien.ac.at>
 <jwvy17ty8v7.fsf-monnier+comp.arch@gnu.org>
 <2024May29.085955@mips.complang.tuwien.ac.at>
 <jwv5xuwwuqe.fsf-monnier+comp.arch@gnu.org>
 <2024May30.182546@mips.complang.tuwien.ac.at> <v3d0hj$2amga$1@dont-email.me>
 <v3jth8$3qduu$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 03 Jun 2024 12:24:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="56679ce97caa389ea52fdd0a12ac3b0c";
	logging-data="4056479"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1++ljAmTSY6PedENiaVdZ4/3oZ2ki0cws0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:utvPgmYVkFfgJxwUA5yZwr7uOCE=
In-Reply-To: <v3jth8$3qduu$4@dont-email.me>
Content-Language: en-US
Bytes: 3017

On 6/3/2024 3:06 AM, Lawrence D'Oliveiro wrote:
> On Fri, 31 May 2024 12:14:19 -0500, BGB wrote:
> 
>> Though, one thing that makes sense for text editors is if only the
>> "currently being edited" lines are fully unpacked, whereas the others
>> can remain in a more compact form (such as UTF-8), and are then unpacked
>> as they come into view (say, treating the editor window as a 32-entry
>> modulo cache or similar).
> 
> That may make sense if you are implementing a *text* editor, like the vi/
> vim family. Remember that Emacs is usable for editing things other than
> text.

I was mostly imagining a Notepad style editor, but either way.

But, yeah, otherwise I was thinking one doesn't want to use a fully 
unpacked representation because this would waste excessive memory for 
larger text files. But, even then, there are practical limits as one 
still needs to be able to read the whole text file into memory, meaning 
one can't realistically deal with files too big to be loaded into RAM.

Though, in most contexts, one isn't going to be opening large files in a 
text-editor (though, this may still happen sometimes).

In general, I consider things with hypertext features / etc to be in a 
different category.

But, one may still deal with fonts or style/color for things like syntax 
highlighting (but, these are not generally stored in the text itself, 
but inferred at run-time from various rules).

....