Accent keys in ee editor

Brutanas

Brutanas

Hello !

I am using FreeBSD 14 as a desktop on a laptop. The window manager is Mate. Everything that I need is working fine...
The accent keys are working generally ok inside Mate. But sometimes I need to use the ee editor on a terminal and these keys don't work. I am even able do use the accent keys in the terminal when I am sending some commands to the system (but I don't). Also after reboot before startx in the console I also can use the accent keys (but still not inside ee editor).
But inside and outside the window manager I am not able to use them on the ee editor.
The output of the locale command is:
Code: 
LANG=pt_PT.UTF-8
LC_CTYPE="pt_PT.UTF-8"
LC_COLLATE="pt_PT.UTF-8"
LC_TIME="pt_PT.UTF-8"
LC_NUMERIC="pt_PT.UTF-8"
LC_MONETARY="pt_PT.UTF-8"
LC_MESSAGES="pt_PT.UTF-8"
LC_ALL=
What to I have to do to be able to write the accent keys insde ee editor as well ?

Thank you in advance!
 
Last edited by a moderator:
If you are already possible to use accent key on the command line of the same terminal, ee would be (usually) OK.
What's annoying is that, at least for CJK characters, UTF-8 multibyte characters "LOOKS BROKEN" on input.
If you scroll out the part outside displayed area of ee, and go back to see what actually is currently, it could be OK.
Maybe ee needs to repaint by itself to properly show UTF-8 multibyte characters.
 
Huau!!!! You are right! When I press the key combination to get an accented character, it writes a "M". Then I scroll out and back in and "voila" its there!
Funny and strange behavior... but it works!

Thank you to share :-)
 
Esc + d.

1704659679160.png

forums.freebsd.org

What is your favorite text editor?

One benefit of vi is that the navigational commands under less are based on them: Commands are based on both more and vi. Commands may be preceded by a decimal number, called N in the descriptions below. less is also used as the default pager for man, which means man commands are based...
forums.freebsd.org forums.freebsd.org
 
CuatroTorres said:
Esc + d.

View attachment 17886
forums.freebsd.org

What is your favorite text editor?

One benefit of vi is that the navigational commands under less are based on them: Commands are based on both more and vi. Commands may be preceded by a decimal number, called N in the descriptions below. less is also used as the default pager for man, which means man commands are based...
forums.freebsd.org forums.freebsd.org
Click to expand...
Ah, I've missed the menu item.
It's nice especially very short texts which fits in single sreen.
 
ee doesn't understand UTF-8 (and can't safely work with it — you'll mangle your text eventually). Do yourself a favor and use another editor.
 
shkhln said:
ee doesn't understand UTF-8 (and can't safely work with it — you'll mangle your text eventually). Do yourself a favor and use another editor.
Click to expand...
If I understand correctly, Yes. ee doesn't care about character codes, simply toss them to underlying terminals/conoles. So Editing multibyte codes are pain. But it can input, if the user is aware of byte sequences of the character codes, possible to edit or delete them. And most importantly, it IS installed BY DEFAULT as a component of base.

[Edit]
My current understanding why inserted multibyte texts are not properly displayed would be because ee attempts to redraw remainders of the line from the BYTE LOCATION after NUMBER-OF-CHARACTERS BYTES from the beginning of the inserted text. For example, if I insert 3 Japanese texts at the top of a line, which consumes 3*3=9 bytes in UFT-8, ee attempts to redraw remainder of the line from 4th byte. When whole redraw is done, characters are drawn from the top of line PER BYTE from buffer, thus displayed correctly. This is almost always seen behaviour on DOS era when we Japanese attempt to use overseas editors/IDEs which is not completely ported to, for example, MS-DOS on PC-9801. At the moment, Japanees characters are in 2 bytes Shift-JIS, though.
 
T-Aoki said:
So Editing multibyte codes are pain. But it can input, if the user is aware of byte sequences of the character codes, possible to edit or delete them.
Click to expand...
You'll see a space character at the end of the line for each "excess" byte. Those are very unsafe to mess with. Typing in-between multibyte characters is practically impossible as well. That is before we get to the actual fun stuff like Unicode's combining characters.

T-Aoki said:
And most importantly, it IS installed BY DEFAULT as a component of base.
Click to expand...
Yeah, whatever.
 
shkhln said:
You'll see a space character at the end of the line for each "excess" byte. Those are very unsafe to mess with. Typing in-between multibyte characters is practically impossible as well. That is before we get to the actual fun stuff like Unicode's combining characters.
Click to expand...
100% agreed, but it's better than nothing, on emergency.

shkhln said:
Yeah, whatever.
Click to expand...
Whatever that...
  • BSD-compatiblly licensed,
  • can display/handle at least UTF-8 correctly.
  • newbies friendly, especially having NOT-AT-ALL knowledges about vi and/or emacs and strongly needs menus and guides like in ee for notepad-incompatible key sequences.
I consider vi users knows risks which you mentioned deeeeeeply and almost perfectly understand how they should handle them, so not considering about vi (regardless current nvi in base or vim in ports). They all should be very well skilled professionals. To whom we should focus on with this area are clearly newbies.
 
Screenshot of editors/turbo on x11/wezterm, displaying en dash.
Maybe anyone who used TurboPascal and/or TurboC on DOS era would love it (not an IDE, though). Just done some casual tests and looks handling UTF-8 OK.
Mouse works here (not tested on vty yet), and as shown at the bottom, hitting F12 leads to menus at the top (selected entry is green-highlited) and drop down menus are shown by cursor down key.
What's good with this is that it states MIT license and very few dependencies.
The problem is that the dependencies are devel/cmake-core and devel/ninja, which would not fit for base as they pull in python in their build dependency chains.

turbo_screenshot.png
 
Sorry, it was U+FE32 PRESENTATION FORM FOR VERTICAL EN DASH.
UTF-8: 0xEF 0xB8 0xB2

U+2013 EN DASH (UTF-8: 0xE2 0x80 0x93) is shown as attached.
turbo-01.png
 
You must log in or register to reply here.
Back
Top