Extended characters don't display correctly

[thblt]

There seem to be some problems with extended/accentuated characters in terminal-plus (latest version on latest Atom). I'm reporting all of them here as I assume they may all be somehow related.

1. Prompts using Powerline characters don't display correctly. Here's what my prompt (using agnoster theme from oh my zsh looks like in iTerm 2 :

   

   and in terminal-plus:

   

   It seems that terminal-plus can't display the final > character (which is a special symbol, requiring a font patched for Powerline). Weird enough, I can run vim in terminal-plus and the same character displays almost perfectly :

   

2. Some characters can't be entered at the prompt. On a simple Bash prompt (which doesn't show the zsh prompt bug explained above) :
   • é, è, | (pipe character, option-shift-l), can't be entered. They display nothing and the cursor remains at its current position. { and } have the same problem.
   • ê (which on my keyboard is composed with a dead key : ^+e) simply prints e.
   • ~ (option-n) clears the current line and prints : when typed for the first time at the current prompt, then ^[n the next times.

When not at a prompt, those of these characters which are composed with a single key (requiring neither a dead key, nor a combination including a modifier) usually display perfectly : é, and è display correctly when typed in cat called without parameters, or vim, but not in ex).

All of these characters display perfectly when printed (and not typed) by some program:

As this is likely to have to do with input methods (maybe related to #14 ?), here's a short summary of the characters I've been testing with and the key combinations required to enter them.

Character	Key combination	Behavior at prompt	Behavior in vim/cat
é, è, à	é, è, à	Prints nothing	Correctly prints é, è or à
ê	^, e	Incorrectly prints e	Incorrectly prints e
		option-shift-L	clears line and prints ":", then prints ^[n	Prints nothing
~	option-n	Prints nothing	Prints nothing
{, }	option-5, option-°	Prints nothing	Prints nothing

Also notice that with the buggy zsh prompt, é, à and the like (single-key accentuated characters) print hexadecimal combinations: Here I keep typing éèà:

I'm using OS X 10.11 (El Capitan) with a French Apple keyboard mapping.

Really sorry about the very long report, I've been trying to be exhaustive. And thanks a lot for terminal-plus — despite these problems, it's already an excellent package (I was impressed it can run vim!) which provides a really fundamental feature in a modern text editor.

[jeremyramin]

Thank you for your time and the report, I appreciate it. These characters are fundamental to using a terminal and should work. The characters issue is most likely related to the issues I'm trying to solve with #14. Terminal-Plus relies on some dependencies that don't particularly have support for languages other than English. My package sends the characters to the terminal correctly but they just don't display.

In bash nothing shows up and in zsh you get the hexadecimal combinations. I'll add this to my research regarding the other issue because I feel like they are closely related. As far as Powerline characters go, I'll have to look into that separately and see why they do not show up properly.

Thank you for the compliment, it means a lot.

[jeremyramin]

1. You should probably set your font in the settings to a powerline patched font. That arrow character in vim is a unicode character that looks similar but isn't the same character used in powerline. Setting: Font Family
2. After some testing in bash with a US English keyboard, I can insert the pipe character |. However accented characters such as è I can not type. Things like option+n don't work either. I believe this is most likely related to issues with non English characters. I'm still actively working through the dependencies to find the cause and a fix.

[thblt]

Thanks for your feedback !

1. I was already using a Powerline patched font, and I just found out the problem was elsewhere. iTerm2 and Apple Terminal both export LANG (on my computer, set to fr_FR.UTF-8). export LANG=fr_FR.UTF-8 in Terminal Plus solves the problem. I believe any locale with encoding would work. Although it would be an acceptable workaround to manually export LANG in some initialization file, I believe Terminal-Plus should mimic iTerm and Apple Term's behavior by setting this variable itself, using the system's UI Locale and encoding.

   For reference, at the bottom of this message is a summary of the environment differences between terminal emulators.

2. On a Linux VM, I'm perfectly able to type é, à, and è. Extended characters with dead keys are still broken, and (probably most interesting), | works with only certain modifiers. I'm going to try on a laptop with a standard Apple keyboard (I have a Corsair mechanical PC keyboard on a Mac Pro here, which won't make things simpler) and will do some tests on Linux with both keyboards as well. I'll keep you informed of the results.
3. (Appendix) Table: Different environment variables in different terminal emulators. This table should be easy to read : ✅ stands for present, ❌ for absent. Variables are grouped by names and values; that is, the two TERM entries should be read as: both iTerm and Apple export TERM as xterm-256color, and Terminal Plus exports it as xterm. If an emulator has no value for a variable, it means it doesn't set the variable at all. This should be more or less "out of the box" settings.

Name	Value	iTerm2	Apple Terminal	Terminal-Plus
COLORFGBG	7;0	✅	❌	❌
ITERM_PROFILE	Default	✅	❌	❌
ITERM_SESSION_ID	w0t0p0	✅	❌	❌
LANG	fr_FR.UTF-8	✅	✅	❌
LC_CTYPE	``	❌	❌	✅
LC_CTYPE	fr_FR.UTF-8	✅	✅	❌
OLDPWD	/Users/thblt	✅	✅	❌
OLDPWD	/Users/thblt/Desktop	❌	❌	✅
SECURITYSESSIONID	186a8	✅	✅	❌
TERM	xterm	❌	❌	✅
TERM	xterm-256color	✅	✅	❌
TERM_PROGRAM	Apple_Terminal	❌	✅	❌
TERM_PROGRAM	iTerm.app	✅	❌	❌
TERM_PROGRAM_VERSION	361	❌	✅	❌
TERM_SESSION_ID	400C111A-AD55-42BD-9E08-1AB169127562	❌	✅	❌

Thanks again, Th

[thblt]

Quick update: export LANG also solved the problem with accentuated characters which can be typed with a single key. No progress on dead keys, though. (all dead keys, including ^ and `, do absolutely nothing).

[jeremyramin]

Wow, this is great work! I've been looking for the solution to this for a long time. On Unix systems I can modify the env before I make the terminal, which means I can get some of these in there. I think the most important from that table would be:

LANG, LC_CTYPE, TERM, TERM_PROGRAM, and OLDPWD.

I could see about getting the dependency to declare itself as a xterm-256color if it supports it. Support for dead keys would have to be added to the Terminal-Plus dependency that presents the terminal view.

[thblt]

Indeed, support for xterm-256color seems perfect already. Here's vim with TERM=xterm:

And vim with TERM=xterm-256color:

[thblt]

Regarding other environment variables: I believe OLDPWD isn't to be set by the emulator, neither is PWD. In my table above, it is correctly set in Terminal Plus already, and seems to be updated by cd/the shell/whatever.

[jeremyramin]

Upon further review, I believe you are right. I shouldn't mess with OLDPWD or PWD.

[jeremyramin]

It seems that just setting the LANG variable sets LC_TYPE as well. I can't seem to be able to get the system locale in node.js. Setting the locale to en_US.UTF-8 allows me to type in multiple languages since it is all unicode. However, I worry that hardcoding the locale rather than having it read the actual locale could lead to issues.

[jeremyramin]

The latest release of Terminal-Plus (v0.7.0) should fix the language issues. Dead keys will have to be added in a later update, but at the very least international characters should be supported now. Please give it a try and let me know what you think.

[thblt]

I've just been trying on a Macbook Air running Ubuntu Gnome and everything works fine. The only difference is that Linux seems to make a strong distinction between the modifier key used to enter commands, and the one used to enter complex characters. That is, in Gnome, left option and right option are two completely different keys.

I believe this may in fact be a serious hint as to what's happening : I'm seriously wondering if, because OSX's option key is more "ambiguous" than Alt Gr in its function (it can be both a character modifier and a command modifier), somehow Terminal Plus and/or one of its dependencies may send a control sequence instead of a character. I have no idea on how to debug terminal input, but maybe you could look into that.

On a side note, every time I install Terminal Plus (and it happened quite a lot recently :-), I get the same error from Atom (I copied it but lost it) that Terminal Plus "could not be loaded because it contains native modules that were compiled from an earlier version of Atom". I don't know if that's normal, I can file open a new ticket if it isn't.

[jeremyramin]

That error is an Atom thing. It insists on rebuilding Terminal-Plus with every update of the package or update to Atom. This is good when I update the dependency that needs to be built with node-gyp. I do not update the dependency often so most of the time it's pointless.

Edit: I'm familiar with how the dependency interprets key presses. If there is a situation that needs the distinction between left and right option, I can look into getting in there. It should be rather simple, assuming JavaScript key events provide a way to tell the difference.

[thblt]

I will try tomorrow with the exact same keyboard in OSX and Linux (sorry my computer setup is a bit of a mess right now), but I can confirm the bug is related to the way key combinations are handled and not to the characters themselves: I created a modified keyboard layout, remapping h and Shift-G to |, and in both cases | show up perfectly. I can test with { and the like if you feel it may show a difference.

About hardcoding the locale : I don't feel like it's a problem, but on Linux (sorry, I really just noticed that) LANG was correctly set, and the new version replaces it with the hardcoded value. It seems like it's an OSX-only problem. At least, I would check if the variable exists before setting it.

I think of two ways of getting the locale on OSX (locale command and plutil -extract AppleLocale xml1 ~/Library/Preferences/.GlobalPreferences.plist -o /dev/stdout), I'll test them tomorrow after downgrading Terminal Plus and will come back to you.

Thanks again, and sorry I can't be of any more help, but I know nothing of [Java|Coffee]Script... Th

[jeremyramin]

Thank you for all of your support. You have been very informational and helpful with figuring things out on my end.

[thblt]

I haven't done the keyboard test yet, but here's already a way to correctly set the locale on OSX:

if [ -z $LANG ] && [ `uname` == "Darwin" ]; then
    export LANG=`plutil -convert json -o - ~/Library/Preferences/.GlobalPreferences.plist | sed -n "s/^.*\"AppleLocale\":\"\([a-zA-Z_]*\)\".*$/\1/p"`.UTF-8
fi

leaving only the encoding hardcoded. Such a script may be sourced each time a new terminal is created.

I believe it will work reasonably well across OSX versions ($HOME/Library/Preferences/.GlobalPreferences.plist have been available since Jaguar, plutil since Puma. Recent versions of plutil provide an -extract command to get only a specific key, but I'm not sure it was available before Mavericks.

Parsing JSON with regular expressions is probably not the best idea ever, but at least it requires absolutely no dependencies. Another way to do it would be, of course, to execute plutil from Terminal Plus directly and parse the result using JSON, extracting the AppleLocale key.

[jeremyramin]

Parsing JSON with regular expressions is probably not the best idea ever, but at least it requires absolutely no dependencies. Another way to do it would be, of course, to execute plutil from Terminal Plus directly and parse the result using JSON, extracting the AppleLocale key.

Node.js actually makes it quite simple to execute a command and work with it's output. If plutil returns JSON then I can parse it and grab what I need.

Edit: I just looked at the command and saw the conversion to JSON flag. I'll give it a shot and get back to you on this. Thanks for the command!

Edit 2: It works! 0e0cf09

[jeremyramin]

Just to check with you, is your issue fixed now or do you really need the dead key implemented?

[thblt]

I just tested with version 0.9.1, $LANG is correctly set on OSX, and some keys now work (namely, accentuated letters). There are still a few bugs, though:

1. On OSX only, ~, {, [, etc, are still broken. These are the characters that are typed as option-something. It seems
2. I believe dead keys are important. On a French keyboard, and some other non-US keyboards, ^ (regex start-of-string) and the backtick ` (shell replace with command result) are dead keys, and important characters for terminal work. They work neither in OSX nor on Linux.
3. Setting $LANG should only happen if it isn't already set. On my Linux laptop, the code seems to unnecessarily force $LANG to en_US.UTF-8.

Thanks again for your work !

[thblt]

Btw : it seems option-something keys send control codes instead of characters. Typing æ, œ or ~ (option-a, o and n, respectively) in cat displays ^[a^[o^[n.

[jeremyramin]

Oh you're right, it shouldn't overwrite the LANG variable if it exists. I'll make that adjustment and have a release for it soon. As for implementing the dead keys, I have created a way to differentiate between the left alt key and right alt key (AltGr). However, I'm not sure where to go from there from the Javascript standpoint. It could be as simple as insert a certain unicode escape character to bash or much more difficult.

[thblt]

I'm not sure I understand how dead keys may relate to the option-something keys. To me they're two different problems. I also don't believe that any of these problems has to do with differentiating between left and right option key on a OSX keyboard. Since Mac stuff and international keyboards can be quite tricky, I'll try to explain the two problems without assuming any knowledge of weird keyboard stuff.

Option-something

On OSX, the option (=alt) key works similarily to the Shift key in standard PC keyboards: used as the primary modifier, it inputs a character (option-a is æ the same way shift-a is an uppercase A). Used in combination with another modifier (usually cmd), it becomes part of a command shortcut, the same way Cmd-Opt-A or Cmd-Shift-A are different shortcuts than Cmd-A.

Now please bear in mind that Mac's option keys is in fact the "alt" key.

In the non-Apple world (including the BSD subsystem of OSX), alt is a control key, not an input modifier (that is, it behaves more like Ctrl than like Shift). It appears that Terminal Plus, when receiving a option-x keystroke, sends the alt-something control code instead of the character. This is easy to show: in Apple Terminal or iTerm2, option-b types ß. In Terminal-Plus, option-b sends the alt-b control code (^[b) which goes back one word in the prompt (and it works, which proves the control code actually gets sent).

If you use iTerm2, you can enable the same behavior in the Profile settings, at the bottom of the Keys tab. A similar config setting would be the best way to fix this.

Dead keys problem

I don't know if US keyboards have dead keys at all, so in case you've never met one, I'll start by a basic explanation. A dead key is a character (and not a modifier) which combines with another character to form only one resulting character. A common use for them is rare accents. The circumflex (^) is a dead key : it is used to combine a circumflex and a letter to form characters like ê, û, î and the like.

Using a dead key thus means entering a single character with two keystrokes. But unlike option/alt gr/shift combinations, you press and release the first character (the dead key), then press and release the second character to get the result. To type an ê, you'd press ^, release it, the press e. If the second character can't be combined with the dead key, you get two characters, eg ^p. If you repeat the dead key twice, or use a space as the second character, you get the dead key's character itself : ^ or `.

The bug : dead keys in Terminal Plus don't work at all. They simply behave as if the key hasn't been pressed. ^^ does nothing, does ^-space prints a space, ^e prints an e. This may be related to the first problem (understanding the keyboard), but yet is quite different. In the "option-something" problem, TP sends a control code instead of a character; in the dead keys problem, TP seems to send absolutely nothing.

[ Edit (An important point : when I say a dead key "is a character", I don't mean that the character itself makes the key a dead key. You can perfectly have a dead ^ and a non-dead ^ in the same keyboard layout. French people who use the shell a lot sometimes remap their keyboards to have ` behave like a normal character instead of a dead key. The keyboard layout makes a key a dead key, not the character) ]

Sorry about the lenghty explanation --- I just wanted to make sure we perfectly understand each other regarding these bugs

(PS: Regarding your recent change of labels, I disagree with the dead keys part not being a bug. Allowing option key to send characters instead of control codes, on the other hand, may indeed be considered an enhancement request, but a critical one since without it the terminal is almost unusable)

[jeremyramin]

(PS: Regarding your recent change of labels, I disagree with the dead keys part not being a bug...)

At the time I visualized the dead keys and keys like option+a as a enhancement given the way the dependency is written. A little explanation into what's going on:

I use a dependency called Term.js that handles the front end task of presenting a terminal. The dependency presents the output of the shell and sends keypresses to the shell. The person who wrote this decided to use Javascript keypress events to register a key. So basically when that happens you aren't just typing a key but rather you send the event 'keypress' : 'a', Term.js sends it to the shell and then the shell sends output that there is an a there now. Keys such as backspace, tab, ctrl+(some key), and the alt+(some key) have been mapped to escape sequences. This explains why you currently see escape sequences with alt+(key) combinations. The escape sequence is sent and then the shell sends the appropriate output.

(...Allowing option key to send characters instead of control codes, on the other hand, may indeed be considered an enhancement request, but a critical one since without it the terminal is almost unusable)

I visualized adding this as an enhancement because there isn't necessarily a 'bug' that is blocking this. Given the way the dependency is set up, I would in fact have to go to the keypress handler and add the concept of dead keys and the other alt+(key) combinations.

I'm not sure I understand how dead keys may relate to the option-something keys. To me they're two different problems.

I lumped the adding of alt+(accent key) with alt+(regular keys) together because they would go into the same section of the keypress handler since they are both key combinations modified with alt.

I also don't believe that any of these problems has to do with differentiating between left and right option key on a OSX keyboard.

At some point in my research, I was misinformed that the right alt key was used in these operations but I see now that it is both alt keys.

I don't know if US keyboards have dead keys at all, so in case you've never met one, I'll start by a basic explanation.

On the US keyboard on a Mac, we do have dead keys. However they are not used often unless one has to type in another language.

You can perfectly have a dead ^ and a non-dead ^ in the same keyboard layout.

This I did not know.

Thank you for the explanation. I needed this because my understanding of the alt+(key) combinations was not that strong. These are new things to me since I do not type accented characters often. I also offer my apologies. I am sorry if I offended you in any way. I do see this as a crippling issue that needs to be fixed. It's just that the way I would fix this is by adding it myself so I visualized it as an 'enhancement' rather than a 'bug'.

The bug : dead keys in Terminal Plus don't work at all. They simply behave as if the key hasn't been pressed. ^^ does nothing, does ^-space prints a space, ^e prints an e. This may be related to the first problem (understanding the keyboard), but yet is quite different. In the "option-something" problem, TP sends a control code instead of a character; in the dead keys problem, TP seems to send absolutely nothing.

As always, thanks for the report. These are things I need to add so every detail helps.

[jeremyramin]

I just had an idea. I know this might not be ideal but I can set up a command to display a prompt asking for input. That input box would be able to recognize all of the alt+(key) and dead keys since it would just be your system typing into an input box. Then when you press enter the prompt would insert the text into the terminal.

[jeremyramin]

v0.11.0 has the feature I just described. There is now a keyboard icon in the top left that presents an input box for typing special characters that the terminal does not respond to. For now, this could work if you only needed the accented characters and other special characters for quick commands. Please give it a try.

[thblt]

Just a quick response for now --- I need to do some research to be more specific, but won't have time until tonight or tomorrow.

First and foremost, I wasn't offended at all, just trying to make myself clear. Please accept my apologies if I sounded harsh — that really wasn't my intention. These are your bug reports, and you're of course free to label them the way you feel. I was trying to avoid a potential misunderstanding, not to lecture you on anything :-)

Your new feature works great, and is a cool workaround to have. I have two small ideas to suggest, I'll do some more research before doing a full report but here they are:

1. You could look into other international-keyboard-related bugs in Atom. Some other packages have trouble with dead keys as well (eg, in vim-mode, ^ doesn't seem to work in normal mode, vim-surround has problems with some option-something characters…). It may in fact be an Atom/Chromium bug. I'll investigate myself, but if you're interested you may want to have a quick look at this issue and the issues it references, and at this package.
2. If you can intercept the keystrokes before they're delivered to the shell, it may be doable to just allow the user to rebind any key combination.

That would be a great thing to have, because it would fix the problem, and still leave available some of the shell's shortcuts: I'd better have alt-b send [^b] (go back on word at the prompt) rather than the ß character, because the shortcut is really useful, and I would still be able to manually bind alt-5 to {, alt-Shift-5 to [, etc. (technically, I guess that would be alt-( and alt-5, since 5 is an uppercase ()

What I mean is something around the lines of these iTerm2 settings:

(Even greater would be to allow a user to bind to either one or the two option keys, some terminal emulators allow this. But maybe I'm asking too much here, Atom may be too high level for that sort of thing)

Of course, this would mean some work by the user with an international keyboard before the terminal is fully usable, but would make for a really powerful emulator.

Please tell me what you think of this :)

Thanks again for your excellent work, Th

[jeremyramin]

First and foremost, I wasn't offended at all, just trying to make myself clear. Please accept my apologies if I sounded harsh — that really wasn't my intention. These are your bug reports, and you're of course free to label them the way you feel. I was trying to avoid a potential misunderstanding, not to lecture you on anything :-)

I'm glad that this is the case. I wanted to avoid a misunderstanding as well.

As always, thanks for the detailed report. It helps a lot with figuring out exactly what you need. As for the custom key mapping, I think this would make for a great addition to Terminal-Plus. I will have to think about how to implement it and I won't know if it is possible until I attempt it. I went through the links you provided as well as some of the code for that package. I'll wait for your full report to see if that package works because you know what to test as far as compatibility goes.

If anything, I can combine this with the suggestion in issue #34. Basically the suggestion is for configuration files on a global and project basis. This would be a slight modification to the original plan; the addition of a keymaps section in the CSON.

commands:
  buildProject:
    trigger: "terminal-plus:compile-project"
    command: "mcs myproject.csproj"
    button:
      icon: "sync"
      tooltip: "Build C# project"
      order: 0
    languages: ["C#"]
keymaps:
  'alt+5':'{'

The hardest part of this addition would be the keymap parser. Just sharing my idea for now, I won't have time to actually try this until later in the week. This might have to wait till the weekend.

[jeremyramin]

Great news! I found a simple way to implement support for the alt+(key) combinations. In OS X, I tested the keys you mentioned earlier (option+5, etc) and they work. Please give it a try and let me know if you have any issues. This should solve your original issue, but I could still add the key mapping feature if necessary.

[thblt]

Thanks a lot for this update! It seems to work for most keys, with a few quirks:

• Almost all alt-something and alt-shift-something characters work perfectly, including greek letters, symbols or strange apple-specific characters (ß, ¬, ). This also includes alt-[letter] combinations, like alt-l (¬). To be more specific : I tried with ´alt-[a-z]´, ´alt-[0-9]´, ´alt-shift-[a-z]´, ´alt-shift-[0-9]´.
• For some reason, neither alt-n (~) nor alt-m (µ) work, they simply print nothing. These are the only two I noticed. alt-shift-n (ı) and alt-shift-m (Ó) both work perfectly.
• The characters themselves can be pasted in the terminal and work perfectly, or entered using the Insert Text button.
• This doesn't seem to have to do with binding conflicts: I tried with KeyBinding Resolver, which says that alt-n isn't bound, alt-m is partially bound to merge-conflicts:detect. alt-d is fully bound to editor:delete-to-end-of-word, and yet correctly enters the ∂ character.
• To be perfectly exhaustive, alt-shift-1 doesn't work either, but it's bound to a dead backtick, so I assume that's expected behavior until a fix for the dead key problems hasn't been found.

One more remark: I don't know if this is on purpose, but on my keyboard, the right alt key still send control codes instead of characters. It's cool for me, because that's the way I like it :-), but may be disconcerting for new user or people used to a different setup.

Sorry for having disappeared that last few weeks — I've been quite busy these days and haven't yet found the time to do the testing I promised. I haven't forgotten though, and will try to find the few hours I need as soon as possible, but I can't promise when it will be --- hopefully next weekend.

Thanks for your excellent work, as usual.

PS: I wanted to have a look at the commit implementing this functionality, and haven't found it. I assume its not 44764ac which seems to solve a completely different issue, but I can't find any other commit before 13.0.0, which IIUC is the first version providing alt-keys characters. Could you point it to me? I'm feeling a bit dumb :-)

[jeremyramin]

For some reason, neither alt-n (~) nor alt-m (µ) work, they simply print nothing. These are the only two I noticed. alt-shift-n (ı) and alt-shift-m (Ó) both work perfectly.

alt+n and `alt+`` unfortunately still do not work. This is because the terminal dependency still lacks support for the dead keys.

One more remark: I don't know if this is on purpose, but on my keyboard, the right alt key still send control codes instead of characters. It's cool for me, because that's the way I like it :-), but may be disconcerting for new user or people used to a different setup.

That is on purpose. Originally both alt keys sent the escape sequences so I found a way to detect which alt key is being pressed in Javascript and made sure that only the right alt key would send escape sequences. That leaves the left alt key for making these alt+(key) combinations.

Sorry for having disappeared that last few weeks — I've been quite busy these days and haven't yet found the time to do the testing I promised. I haven't forgotten though, and will try to find the few hours I need as soon as possible, but I can't promise when it will be --- hopefully next weekend.

I understand, I have been busy as well. Do not worry about it.

PS: I wanted to have a look at the commit implementing this functionality, and haven't found it. I assume its not 44764ac which seems to solve a completely different issue, but I can't find any other commit before 13.0.0, which IIUC is the first version providing alt-keys characters. Could you point it to me? I'm feeling a bit dumb :-)

You are not dumb, it is just that my work on the package is divided between three repositories: jeremyramin/terminal-plus -> This package jeremyramin/term.js -> The terminal display jeremyramin/pty.js -> The backend that forks the shell You are interested in jeremyramin/term.js as that is the part that listens for key press events.

[Z-Clive]

@jeremyramin @thblt Hi there. Is this problem solved already? Or is there a workaround? I'm having the same problem with patched font for powerline here on my Ubuntu GNOME machine. Changing font in terminal-plus's settings seems not working at all.

[thblt]

Could you please be more specific? The problem with Powerline fonts has been fixed, it was a general problem with extended characters due to Terminal-Plus not setting LANG in the environment.

[jeremyramin]

@zmLGBBM Reasons why this might not be working:

1. The font you are trying to use might not be patched for powerline characters.
2. The font name you are entering does not match the font that resides on your computer. Terminal-Plus will default to the monospace font if the custom font you pick does not exist. The monospace font is not patched for powerline characters.

[Z-Clive]

@thblt @jeremyramin Well, yeah, seems like I got the font's name wrong. It has a comma in the name:

Not Working: DejaVu Sans Mono for Powerline Book, Working: DejaVu Sans Mono for Powerline, Book.

[jeremyramin]

As of v0.14.0, Terminal-Plus now supports dead keys. Please review the latest release and let me know what you think. The exact commit can be found here.

[thblt]

It works perfectly for me, although a small quirk remains, but shouldn't be blocking to any use case I can think of: when pressing a dead key twice, the character it represents appears three times instead of one, without enabling dead key behavior on the second and third instances.

Eg, pressing alt-n alt-n n usually inputs "~ñ", where in Terminal Plus the result is "~~~n"

This being said, I really don't think that it's something that requires fixing, unless someone else finds a use case where this is actually a problem. AFAIC the issue is solved, and can now be closed.

Thanks again for your work and for Terminal-Plus :-)

[YarnSphere]

I agree that this was a great addition! I didn't notice any issues with it. :smile:

Just one question: is there still any reason for the existence of the keyboard button that allows you to write in an input box? Or did you just leave it in case the update didn't work as expected?

[jeremyramin]

@thblt I'll try and see if I can fix that. If not, then it should be fine since it does not interrupt normal usage. @nunocastromartins Yes I left it there incase someone still needed it. Also, some people have grown accustomed to it. Later when custom buttons and custom commands are implemented, I plan on using it as the default custom button as well as an example. At that point, you could remove the example keyboard button via the configuration file.

[willin]

mark.

how to use powerline fonts?

add font-family but not work

[dwadden]

Hi,

First. thanks for a very helpful package.

@jeremyramin, you mention above that right alt sends escape sequences while left alt creates special characters. I was wondering if there's any way to have both alt's just send escapes, as this is the behavior I have working in, say, iTerm2. I took a look at the changelog and it appears you implemented this functionality at v 0.13.0. But, when I looked at the actual commits I couldn't find where the change occurred.

Can you point me to it and I can try to fix it / add an option to toggle the behavior of left alt?

Thanks,

Dave

[willin]

fixed.

[bennypowers]

Using Fira Code or Hack, both of which are fonts that are patched for powerline chars, I was not getting proper rendering of powerline prompts. Reading through the thread got me to check LANG:

a temporary solution was to add set LANG en_US.UTF-8 to my ~/.config/fish/config.fish (since I'm using fish shell)

[Nuruddinjr]

Any update on how to use Powerline on terminal Plus?