Re: ee (easy editor) bugged on 9.0?
Stefan Bethke
> Dear list,
>
> Has anyone noticed the easy editor is quite bugged on 9.0? On console
> direct access, opening the easy editor has several bugs:
>
> 1) the cursor starts on line 2 instead of line 1
> 2) the line numbering is printed on line 1 instead of the boundary (line 0)
> 3) the keys page up and page down bring the escape menu
>
> Strange enough, if I SSH into the box the ee editor works normally. So
> I'm wondering if this is something other people have noticed? Just
> want to exclude the possibility of me doing something wrong.
>
> I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2,
> amd64. GENERIC kernel and tested inside Virtualbox.
Working fine here on 9.0-RC1.
Is this a fresh install, or did you upgrade? Have you updated your ttys to set the terminal type to xterm instead of cons25?
Stefan
--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Lyndon Nerenberg
Adrian Chadd
adrian
Alexander Best
> On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd <adr...@freebsd.org> wrote:
> > .. how many users is this going to trip up?
>
> went through several iterations with ed@ over the fact that various
> curses based apps were broken with the libteken work, but then just
> gave in and set 'xterm'.
>
> That being said, I can't reproduce the issue Jason mentioned in the first post.
running a very recent HEAD doing 'export TERM=cons25' in zsh and then running
'ee', i can exactly reproduce this issue.
cheers.
alex
>
> 1. Have you rebuilt your termcap database?
> 2. What is your $TERM in the ssh case and the console case?
> Etc.
>
> Thanks,
> -Garrett
Alexander Best
> > On Sat Nov 19 11, Garrett Cooper wrote:
> >> On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd <adr...@freebsd.org> wrote:
> >> > .. how many users is this going to trip up?
> >>
> >> cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I
> >> went through several iterations with ed@ over the fact that various
> >> curses based apps were broken with the libteken work, but then just
> >> gave in and set 'xterm'.
> >>
> >> That being said, I can't reproduce the issue Jason mentioned in the first post.
> >
> > running a very recent HEAD doing 'export TERM=cons25' in zsh and then running
> > 'ee', i can exactly reproduce this issue.
>
> email thread: http://comments.gmane.org/gmane.os.freebsd.current/136528
what do you mean? i fire up xterm (actually sakura in my case) and simply type
'export TERM=cons25'. this is on my local machine. however i tried the same
over ssh, connecting to hub.freebsd.org (which is running7.4-STABLE, and got
the same result.
cheers.
alex
> .
> Cheers,
Jan Beich
> Has anyone noticed the easy editor is quite bugged on 9.0? On console
> direct access, opening the easy editor has several bugs:
>
> 1) the cursor starts on line 2 instead of line 1
> 2) the line numbering is printed on line 1 instead of the boundary (line 0)
> 3) the keys page up and page down bring the escape menu
Try to use cons25 emulation beforehand
$ vidcontrol -T cons25 # aka TEKEN_CONS25 in kernel config
unless you've updated etc/ttys to use `xterm'.
Alexander Best
> On Sat, Nov 19, 2011 at 6:07 PM, Stefan Bethke <s...@lassitu.de> wrote:
> > Am 19.11.2011 um 17:29 schrieb Jason Edwards:
> >
> >> Dear list,
> >>
> >> Has anyone noticed the easy editor is quite bugged on 9.0? On console
> >> direct access, opening the easy editor has several bugs:
> >>
> >> 1) the cursor starts on line 2 instead of line 1
> >> 2) the line numbering is printed on line 1 instead of the boundary (line 0)
> >> 3) the keys page up and page down bring the escape menu
> >>
> >> Strange enough, if I SSH into the box the ee editor works normally. So
> >> I'm wondering if this is something other people have noticed? Just
> >> want to exclude the possibility of me doing something wrong.
> >>
> >> I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2,
> >> amd64. GENERIC kernel and tested inside Virtualbox.
> >
> > Working fine here on 9.0-RC1.
> >
> > Is this a fresh install, or did you upgrade? Have you updated your ttys to set the terminal type to xterm instead of cons25?
>
>
> it pretty much is a vanilla FreeBSD install with just some packages
> preinstalled (webserver, php, etc). The only relevant changes I think
> are a change to /etc/ttys. But when I revert the file back to the
> defaults, the problem stays. I thought that perhaps Virtualbox had
> something to do with it, but it seems to happen on a real system as
> well.
>
> Some of you asked for the environmental settings. Using 'env' the
> output begins with:
>
> -- on console --
> TERM=cons25
> SHELL=/usr/local/bin/bash
>
> -- via SSH --
> TERM=xterm
> SHELL=/usr/local/bin/bash
>
> Via SSH the ee editor works as it should. On the console it is bugged.
i just grabbed a copy of
"FreeBSD-9.0-RC2-amd64-dvd1.iso"
and ran it in qemu. i noticed nothing irregular running ee. also TERM is set to
"xterm" on the console. so this is either an issue with bash (have you tried
running sh?) or something in your /etc is broken.
cheers.
alex
>
> Regards,
> Jason
Stefan Bethke
> Some of you asked for the environmental settings. Using 'env' the
> output begins with:
>
> -- on console --
> TERM=cons25
> SHELL=/usr/local/bin/bash
>
> -- via SSH --
> TERM=xterm
> SHELL=/usr/local/bin/bash
>
> Via SSH the ee editor works as it should. On the console it is bugged.
As I suspected. On my fresh 90-RC1 install, I get xterm for all the console terminals. You'll have to check where your /etc/ttys picks up the old entries. Both stable and releng have the updated version, as far as I can tell.
If your /etc/ttys has
ttyv0 "/usr/libexec/getty Pc" xterm on secure
and so on, you'll need to check whether a login script resets the TERM environment variable.
Stefan Bethke
> I wonder: is cons25 bugged or simply obsolete? Not that I want to keep
> cons25; just being curious.
cons25 is no more, syscons speaks xterm now, thanks to Ed Schouten and his libteken.
Ed Schouten
* Jason Edwards <sub....@gmail.com>, 20111122 21:56:
> I wonder: is cons25 bugged or simply obsolete? Not that I want to keep
> cons25; just being curious.
There are two reasons why I changed the default terminal emulator to be
xterm-like, instead of conforming to cons25:
- It is more compatible. Not all operating systems have proper cons25
entries in their termcap/terminfo, meaning it is practically
impossible to SSH to one of those systems and do your work properly.
Also, there are many devices (e.g. Cisco/HP switches) that don't offer
a lot of flexibility with respect to terminal handling. By using an
xterm-style emulator, this is all solved, because xterm is pretty much
compatible with VT100 and friends.
- It is more bandwidth efficient. cons25-like terminals do not (have to)
support more advanced features like scrolling regions. This means for
example that if you use applications where only a portion of the
screen scrolls (e.g. irssi, mutt), it has to redraw that entire
portion of the screen, instead of being able to simply scroll that
independent region, without affecting the rest of the display
contents. This is of course no problem when running applications
locally, but it does have its advantages when SSHing to another
system.
- It is more future proof. There are many implementations of xterm-like
terminals that demonstrate that it's not hard to get (a sane subset
of) UTF-8 and 256 colors working. Things like that are simply not
available for cons25.
As people pointed out, if you still want to keep on using TERM=cons25
(not advised, though), you _MUST_ either compile your kernel with
TEKEN_CONS25 or run vidcontrol -T cons25. This is due to the fact that
cons25-like terminals are incompatible with xterm-like terminals. For
example:
- With xterm, ^N and ^O are used to switch character maps, while with
cons25, they render a music note and star symbol.
- With xterm, processing backspace while the cursor is at the first
column of the screen does nothing, while cons25 performs reverse line
wrapping.
- With xterm, ^L is interpreted as a newline, while with cons25, it
clears the entire screen.
- With xterm, line wrapping of the cursor on a display of n columns wide
is only performed when printing the n+1'th character, while cons25
already does this after the n'th character. Effectively, this makes it
very hard to print a character in the lower righthand corner of the
screen.
One of these incompatibilities is likely what caused the problems you
experienced when you ran ee(1) without updating /etc/ttys accordingly.
--
Ed Schouten <e...@80386.nl>
WWW: http://80386.nl/
Ed Schouten
> There are two reasons why I changed the default terminal emulator to be
> xterm-like, instead of conforming to cons25:
Errr... for large values of two.
Ed Schouten
* Jason Edwards <sub....@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,