On 14/07/2019, ropers <rop...@gmail.com> wrote:
> On 13/07/2019, Ingo Schwarze <schwa...@usta.de> wrote:
>> Hi Ian,
>>
>> ropers wrote on Sat, Jul 13, 2019 at 02:53:28AM +0200:
>>
>>> altnumd with e.g. CP437 support
>>
>> Over my dead body. We won't add support for legacy character encodings.
>
> I understand the sentiment. The way I'm thinking about it though
> wouldn't necessarily force CP437 on anybody; that was just my example.
> If there gets to be a default .altnumrc, it could also be one that
> supports ISO-8859-1 or Windows CP1252 (the latter making more sense,
> because nobody has ISO-8859-1 Alt codes in muscle memory). And it
> wouldn't really even be legacy encoding "support" beyond merely
> offering the plumbing for people to type the key combos they still
> remember or still find on the web. The plan is to actually make those
> produce nice, proper UTF-8, at least once things get beyond scan
> codes, etc.
>
>>> the more fundamental idea is to have this be completely configurable,
>>
>> The OpenBSD philosophy is to limit configurability to the utter minimum
>> needed.
>
> I'm not sure I would entirely agree. Does pf.conf offer the utter
> minimum configurability needed? It depends on your point of view I
> suppose. Don't get me wrong, I can see the merit of your sentiment
> too, and it's a suckless kind of thought, perhaps.
> Either way, I don't think I'd dare dream of getting to the level where
> anything substantially by me would actually make its way into OpenBSD;
> just a port would be plenty of an achievement for me. I appreciate
> that altnumd might require deep hooks, and in that sense perhaps even
> some helping hand from the the system at some stage -- but I'd worry
> about crossing that bridge when I get to it. If I get to it.
>
>> Take mandoc as an example. It supports as input: ASCII, UTF-8, latin-1,
>
> When you say Latin-1, are you referring to ISO-8859-1, which is what
> OpenBSD uses in many places, including on console? (My thoughts on all
> of that, and I have learnt a lot about it all, are for another email,
> Real Soon Now.)
>
>> and the latter only because legacy manual pages encoded that way are
>> still somewhat common in the wild. It's all fully transparent and
>> just works. Yes, the -K option exists, but only for compatibility,
>> you almost never need it. No configuration or customization is ever
>> required, and no helper programs like preconv(1) with groff.
>> It supports as output: ASCII and UTF-8. Again, almost nothing to
>> configure, just LC_CTYPE is enough, or -Tascii / -Tutf8 to override
>> that. Though the final code achieving all that is relatively simple,
>> getting there took years of thought on how to simplify.
>>
>> Take any other base userland program; likewise optimized for KISS.
>> Examples of some that i contributed to for that purpose include
>> ksh(1), xterm(1), ls(1), ssh(1), sftp(1), though these are by now
>> means perfect yet; there is still much that could be taken away.
>>
>> The part that is still really complicated, difficult to use, and
>> fragile is keyboard encoding and low-level input handling.
>
> And that's the part, well, that and injecting things back into some
> buffer there, those are the parts I really would like some advice,
> from absolutely anyone, on where to even start, i.e. where to look,
> and what to read and find out more about.
>
> Thanks for your time,
> Ian
>
