Re: ee (easy editor) bugged on 9.0?

Hello Jason,

* Jason Edwards <sub.mesa_at_gmail.com>, 20111127 22:15:
> Thanks for the impressive list of advantages! There's just one
> non-critical issue I'd like to address regarding the use of xterm
> terminal type.
> 
> When using cons25 terminal, the dialog menus (drawn using
> devel/cdialog and `make config` in portstree as well) are using smooth
> lines to draw boxes and stuff.
> 
> But when using xterm terminal, those lines are replaced by 'dashed'
> lines like - - - - - instead of a smooth line without whitespace in
> between. When doing the same via SSH login, the lines are smooth with
> xterm type. So this issue appear to be limited to the console in
> combination with xterm terminal type.
> 
> Is there a way to use xterm but still allow cdialog to draw smooth
> lines on the console?

Unfortunately, this is actually a workaround for a problem that existed
all along, even before we switched to TERM=xterm. It's not beautiful,
but needed.

When using TERM=cons25, ncurses applications simply print certain bytes
to do the box drawing, namely these ones:

	http://en.wikipedia.org/wiki/Code_page_437#Standard_code_page

This means that if you load a different font file into the console
driver that uses a different character set (e.g. ISO-8859-1), you get
all sorts of math characters and diacritics instead of the box drawing
characters.

With TERM=xterm, this is essentially solved, because box drawing can be
performed using character set independent escape sequences (using ^N and
^O), but the problem is that syscons does not know which glyphs in the
font file correspond with the box drawing characters.

There are two ways to solve this:

- Extend the font file format to include a mapping table of box drawing
  characters to glyph indices,
- Patch syscons to just print +-| instead of the box drawing characters.

The first option would fix it properly, but in my opinion it's not worth
the effort, because time should be spent to just get Unicode working.
The terminal emulator already supports Unicode internally and even
remaps box drawing characters to Unicode. Get Unicode working and you
fix the box drawing issue for free. This is why I have chosen the second
option.

If you really miss the box drawing characters, you can revert SVN
revision 203659. Do keep in mind that it effectively breaks support for
custom fonts/character sets. I think box drawing does work when you
compile your kernel with TEKEN_UTF8 (poor mans UTF-8 support), but
please don't attempt to load any fonts then.

Best regards,
-- 
 Ed Schouten <ed_at_80386.nl>
 WWW: http://80386.nl/