Opened 11 years ago

Closed 9 years ago

#2673 closed bug (fixed)

[Terminal] Missing Support for Graphics Char Set

Reported by: scottmc Owned by: pulkomandy
Priority: normal Milestone: R1
Component: Applications/Terminal Version: R1/Development
Keywords: midnight commander Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

I'm not sure but I think the text encoding menu option does nothing. This was on hrev27178. When I built jed (text editor) the menus have letters in their border instead of the expected lines. It might be that terminal isn't using the same mode as jed expects? The jed maintainer suggested trying "xterm" mode?

Attachments (6)

screen5.png (22.4 KB) - added by scottmc 11 years ago.
screen3.png (144.9 KB) - added by scottmc 11 years ago.
another screenshot of jed on hrev27178, leaving tracing of the pop up menus behind.
mc.png (88.3 KB) - added by jackburton 9 years ago.
jed.png (20.6 KB) - added by jackburton 9 years ago.
Jed
mc_freebsd6.2_ru_RU.KOI8-R_r38137.png (40.9 KB) - added by diver 9 years ago.
mc_fedora8_ru_RU.UTF8_r38137.png (57.2 KB) - added by diver 9 years ago.

Download all attachments as: .zip

Change History (27)

Changed 11 years ago by scottmc

Attachment: screen5.png added

comment:1 Changed 11 years ago by scottmc

Here's what the expected output should look like: http://www.jedsoft.org/jed/images.html I've attached a screenshot of what terminal shows. Changing the text encoding to any of the menu selections has no effect.

comment:2 Changed 11 years ago by anevilyak

I'd assume you already tried export TERM=xterm ?

comment:3 in reply to:  2 Changed 11 years ago by bonefish

Replying to anevilyak:

I'd assume you already tried export TERM=xterm ?

That's set by default.

Anyway, this has nothing to do with text encoding. We simply don't support all xterm escape sequences yet. E.g. we don't support the graphics character set, which is why there are "q", "x", "l", "j" instead of lines. So the open "Windows" menu looks at good as it gets ATM. I don't see what the box to the left is supposed to be, but I guess the remainders of some menu. So maybe some positioning escape sequences are used, that we don't support yet. If you can find out which ones, it's probably not so hard to add them.

Changed 11 years ago by scottmc

Attachment: screen3.png added

another screenshot of jed on hrev27178, leaving tracing of the pop up menus behind.

comment:4 Changed 11 years ago by bonefish

Component: - GeneralApplications/Terminal
Owner: changed from axeld to jackburton

#2852 is a duplicate of this one.

comment:5 Changed 11 years ago by diver

Shouldn't be summary changed to include midnight commander. I tried, but failed to find this ticket.

comment:6 Changed 11 years ago by bonefish

Summary: [Terminal] Text Encoding not working?[Terminal] Missing Support for Graphics Char Set

comment:7 Changed 9 years ago by jackburton

It actually doesn't look that bad. Here's "Midnight Commander" under linux (via ssh).

Changed 9 years ago by jackburton

Attachment: mc.png added

comment:8 Changed 9 years ago by scottmc

Maybe try jed again to see if this one has been fixed: http://ports.haiku-files.org/wiki/Downloads It may also need slang installed. If those don't work we may need to build fresh versions as those are a bit old now.

comment:9 Changed 9 years ago by anevilyak

Those might've been partly fixed by some of joshe's patches a while ago, iirc they did extend handling of some extra terminal control sequences.

Changed 9 years ago by jackburton

Attachment: jed.png added

Jed

comment:10 Changed 9 years ago by scottmc

That looks much better, I'd say it's been fixed now.

comment:11 Changed 9 years ago by jackburton

Resolution: fixed
Status: newclosed

Fixed (probably in hrev33327)

comment:12 in reply to:  10 ; Changed 9 years ago by siarzhuk

Sorry, but this problem is still observed with Haiku port of mc-4.6.1 :-(

Replying to scottmc:

That looks much better, I'd say it's been fixed now.

Mentioned jed.png shows not pseudo-graphical characters but so known "ANSI-emulation" - replacing border characters with the same looking ANSI symbols "|", "-", "+" etc. This cannot be indicator of this issue is fixed, IMO.

Replying to jackburton:

It actually doesn't look that bad. Here's "Midnight Commander" under linux (via ssh).

Which version of MC do you use there? Which terminal encoding have you set?

comment:13 in reply to:  12 Changed 9 years ago by jackburton

Resolution: fixed
Status: closedreopened

Replying to siarzhuk:

Mentioned jed.png shows not pseudo-graphical characters but so known "ANSI-emulation" - replacing border characters with the same looking ANSI symbols "|", "-", "+" etc. This cannot be indicator of this issue is fixed, IMO.

Makes sense. I simply don't know how it should look like, though.

Which version of MC do you use there? Which terminal encoding have you set?

MC 4.6.2. You mean on haiku terminal ? The default (UTF8).

comment:14 Changed 9 years ago by pulkomandy

Owner: changed from jackburton to pulkomandy
Status: reopenedassigned

comment:15 Changed 9 years ago by pulkomandy

Resolution: fixed
Status: assignedclosed

Fixed in hrev38088. I didn't add the whole set of graphical chars, feel free to reopen if you need more than the basic ones.

Changed 9 years ago by diver

Changed 9 years ago by diver

comment:16 Changed 9 years ago by diver

Resolution: fixed
Status: closedreopened

This bug is not fixed for me.

comment:17 Changed 9 years ago by diver

Keywords: midnight commander added

comment:18 Changed 9 years ago by diver

Version: R1/pre-alpha1R1/Development

comment:19 Changed 9 years ago by pulkomandy

I had missed some things in the original change. It should work better as of hrev38139. I'll let you test before I close this ticket.

comment:20 Changed 9 years ago by diver

Ok, mc in Fedora is fixed now. FreeBSD however is not, but I believe this is because of missing KOI8-R encoding in Terminal. Could you please add it?

comment:21 Changed 9 years ago by pulkomandy

Resolution: fixed
Status: reopenedclosed

Yes, this is using the wrong encoding. One possible workaround is using screen -U to perform the conversion (this will start an utf-8 shell if screen is installed).

Anyway, this is another issue, so please open another bug.

Note: See TracTickets for help on using tickets.