On Sat, Mar 19, 2016 at 08:33:34PM +0900, YASUOKA Masahiko wrote: > > On Thu, 17 Mar 2016 10:42:21 -0600 > "Anthony J. Bentley" <anth...@anjbe.name> wrote: > > Marc Espie writes: > >> On Thu, Mar 17, 2016 at 12:00:47AM -0600, Anthony J. Bentley wrote: > >> > I'm concerned about this port, though. It's an unmaintained ISO-2022 > >> > patchset on top of less-332, which was released in *1997*. The patches > >> > no longer exist except on our mirrors. Have there been any > >> > vulnerabilities in less in the past 19 years? Do the patches introduce > >> > any? > >> > > >> > It seems like it might be worthwhile for jless users to alias it to > >> > "iconv -f iso-2022-jp -t utf-8 | less", and see if it acts as a > >> > reasonable approximation. > >> > > >> > I'm very concerned about keeping such an old, unmaintained fork in > >> > our tree, when the original software has since grown its own support > >> > for Japanese. I have similar concerns about kterm (1996 xterm), > >> > jvim (1996 vim), ja-groff (1995 groff), hanterm-xf (2003 xterm)... > >> > >> I don't know. Japanese is slightly peculiar, and they sometimes have needs > >> that haven't gotten to the 21st century... > >> > >> keeping a toolchain that works with JIS/SJIS encoding probably makes some > >> sense. > >> > >> Analogy with western countries: we just switched to utf8 by default less > >> than a release ago. before that, a lot of people, me included were still > >> mostly working with iso-8859-* > > > > I do understand. But I'm very leery of promoting such old, old software. > > I'm not convinced that we're doing anybody a favor by keeping these ports > > around. If 20-year-old packages exist under japanese/, that's an implicit > > endorsement that "to set up a Japanese environment, you need to use this > > special terminal with a special encoding that nothing else on the system > > uses." I saw this happen even last year on misc@. That is a bad thing to > > promote, because there is no future for ISO-2022 or Shift-JIS on OpenBSD. > > > > By analogy, we used to have nvi-m17n in ports. But it turns out the nvi > > port supported the same encodings and more; and has a somewhat maintained > > upstream. It was worth removing nvi-m17n and encouraging people to use > > nvi instead. > > > > I understand that people sometimes, even frequently, need to work with > > non-UTF encodings. But you can get that effect on OpenBSD with a UTF-8 > > locale and using iconv on incoming and outgoing data. I've been doing > > so for Japanese and European content for over six years. > > > > Base xterm works natively with Japanese text out of the box; you don't > > even need to install any fonts. And if you have to, you can even run > > Shift-JIS/ISO-2022 software directly in xterm using luit(1). Promoting > > use of a parallel xterm with a parallel less and a parallel vim, all > > unmaintained for decade after decade after decade, is *harmful*. > > I totally agree your opinion. I'd like to help removing old Japanese > ports and guide people to use newer tools. > > But I myself don't use any japanese/* already. So I need to learn the > reasons why some people are still using japanese/* for this moment. > > --yasuoka >
I use jserver/kinput2 because it works with cwm and I can run it on a legacy i386 system and connect over ssh from an amd64 machine (I was hoping the new vmd development work would help there, but i386 support seems a way off). The new UTF-8 desktop settings in -current work OK for me to display UTF-8 fonts, it is just the occasional inputting of kanji that I need something for. If someone can show how to use uim/anthy with cwm in a non-root manner I would be grateful. uim does have appeal because it supports a wide range of languages and I would like something for Chinese, too. Peter
