New issue
Advanced search Search tips

Issue 735748 link

Starred by 0 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature



Sign in to add a comment

hterm: figure out a UX where people can easily recover from a transition to graphics character maps

Project Member Reported by vapier@chromium.org, Jun 22 2017

Issue description

often times when you dump binary data (by accident or whatever), the terminal switches the character map to the graphics one.  so instead of a prompt like:
vapier@vapier-g 0:0 ~ $
they get:
┴▒⎻␋␊⎼@┴▒⎻␋␊⎼-± 0:0 · $

experienced users know that they just have to blindly run `reset` to recover.  but can we do better ?

obviously if we had issue 213983 (add a context menu), we can add a "reset" command there.  but if we went with material design principles, we could add a butter/snack bar [1].  there we could show a message like "Your character map has been changed.  Would you like to reset it? [yes] [no] [never]".  since it'd disappear automatically after a few seconds, it *hopefully* shouldn't be too intrusive.  and the power users could just select "never".

[1] https://material.io/guidelines/components/snackbars-toasts.html
 
Project Member

Comment 1 by bugdroid1@chromium.org, Jul 21 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/8be02338617c4315af1ad5dcc440189ad59af6e5

commit 8be02338617c4315af1ad5dcc440189ad59af6e5
Author: Mike Frysinger <vapier@chromium.org>
Date: Fri Jul 21 22:31:11 2017

hterm: default all character maps to US/ASCII

Currently we default G1 to the graphics map and G0/G2/G3 to US/ASCII.
This makes it very easy to switch to the graphics map (a single SO or
Ctrl+N), but it also means it's easier to accidentally select it when
you cat a binary file.

Since other terminals default all maps to US/ASCII by default (checked
eterm, iTerm2, konsole, mosh, libvte/gnome-terminal, rxvt/rxvt-unicode,
suckless, terminology, xterm), change hterm to do so as well.  The few
programs that use the graphics map will manually load it anyways since
they have no idea what any of the maps are currently pointing to.

BUG= chromium:735748 

Change-Id: Iface24830f236a9c33bf54f9406ea2635bde2334
Reviewed-on: https://chromium-review.googlesource.com/582077
Reviewed-by: Brandon Gilmore <varz@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/8be02338617c4315af1ad5dcc440189ad59af6e5/hterm/js/hterm_vt.js

Project Member

Comment 2 by bugdroid1@chromium.org, Nov 27 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/c5e4453f1ac628c5f2b924ac6440d4e858c50cec

commit c5e4453f1ac628c5f2b924ac6440d4e858c50cec
Author: Mike Frysinger <vapier@chromium.org>
Date: Mon Nov 27 20:54:55 2017

hterm: default all character maps to US/ASCII when resetting

We made this change for initialization, but missed it when doing a reset.

BUG= chromium:735748 

Change-Id: Ic9d1fa378aa2a91a40cb82eaca475b69595cd182
Reviewed-on: https://chromium-review.googlesource.com/789558
Reviewed-by: Brandon Gilmore <varz@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/c5e4453f1ac628c5f2b924ac6440d4e858c50cec/hterm/js/hterm_vt.js

Owner: vapier@chromium.org
Status: Fixed (was: Available)
i think after  issue 747625  where we default the encoding to utf-8 instead of iso-2022, this issue is much less of a problem.  people can't get graphics maps unless they explicitly switch the encoding back to iso-2022 first.

so lets consider character maps as a legacy feature now.

Sign in to add a comment