Hello!
I really like mlterm, in particular because it is so fast -- much faster than all those "new" terminal emulators.
Since mlterm supports wayland, I tried running it under sway, but that doesn't work. Is it possible that mlterm only supports the wl_shell protocol? Sway has dropped support for that since it is supposed to be replaced by the xdg-shell protocol.
I don't know whether switching to the new protocol is a priority for you, but I just wanted to let you know.
Thanks for writing mlterm!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
I'm sorry for my late reply.
mlterm now supports xdg-shell-v6 (unstable) at hg head (revision 8e11edf3e0b5). https://bitbucket.org/arakiken/mlterm/get/tip.zip
If you find some problems, please report them to me.
Regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mlterm now starts up, but I ran into a few issues:
1) When I try do disable the scrollbar (either via use_scrollbar=false in ~/.mlterm/main or on the command line by setting --sbmod=none), mlterm hangs. That is, I type "mlterm-wl" but nothing happens and the command does not exit. msg.log does not contain any errors. (I do not need scrollback anyway, but I did not find a way to disable it completely.)
2) There seems to be a problem with my keyboard layout (German). I have LANG=de_DE.UTF-8 and mlterm prints special characters in files like ö,ä,ü just fine, but if I type "ä", it behaves like a dead key: On the first keypress, nothing happens. On the second keypress, a strange character ("A" with a tilda on top of it) is printed.
3) Is it correct that copy&paste is not working under wayland right now?
Let me know if I can help by supplying more information.
Regards
Eric Praline
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2) There seems to be a problem with my keyboard layout (German). I have
LANG=de_DE.UTF-8 and mlterm /prints/ special characters in files like
ö,ä,ü just fine, but if I /type/ "ä", it behaves like a dead key: On the
first keypress, nothing happens. On the second keypress, a strange
character ("A" with a tilda on top of it) is printed.
I suspect the A-tilde is a representation of the first byte of a-umlaut
in UTF-8. That is, the UTF-8 representation of "ä" consists of the
bytes \xc3\xa4, and \u00C3 is 'LATIN CAPITAL LETTER A WITH TILDE'. (The
byte \xa4 corresponds to the Unicode character 'CURRENCY SIGN', which is
a funny looking character.)
So somehow what you type and what is displayed seem to be in two
different Unicode encodings.
--
Mike Maxwell
"I am, by a flood, borne back to that wondrous
period, ere time itself can be said to have begun;
for time began with man." --Herman Melville,
Moby Dick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
3) Is it correct that copy&paste is not working under wayland right now?
Copy&paste from mlterm to other applications works.
But copy&paste from other applications to mlterm was broken.
I fixed it.
I also notice slight differences in font rendering when comparing mlterm to xterm or termite (which do not seem to differ from each other). For example, when using the Inconsolata font (ttf-inconsolata in arch community), some glyphs are rendered one pixel too far to the right. This is e.g. the case with "w" and "A". They are cut off at the right end and the distance to the preceding character is a little bit too large.
Also, I get the impression that xterm slightly reduces the font size of some glyphs when rendering bold text, while mlterm does not do that.
Both issues can be observed very well in mutt, which renders the line with the currently active email bold. Switching between lines in xterm and mlterm, you can see both phenomena: Characters jumping 1px to the right/left in mlterm, and a changing glyph size in xterm.
Regarding the glyph size, this is probably a question of aesthetics. I like the way xterm does it, but that may be because I have been using it for a long time. The horizontal positioning issue looks like a bug to me.
(I hope that I'm not getting on your nerves.)
Regards,
Eric Praline
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it improves the situation in that the characters do not jump to the left or right anymore when switching between regular and boldface. Still, when switching from regular to boldface, it looks like the text is moving a little bit to the upper right. But that is certainly a very minor thing.
The main issue, namely some characters being cut off at the right side, remains.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At the moment, I am not sure whether what I see is Inconsolata Bold or an algorithmically emboldened version of Inconsolata Regular. My aafont file looks like this:
DEFAULT = Inconsolata
In the main file, I have:
use_aafont = true
use_bold_font = true
I tried to set the bold font manually in the aafont file. I tried
BOLD = Inconsolata:style=Regular
or
DEFAULT_BOLD = ...,
but that did not work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It works, thank you!
By the way, I mentioned that bold glyphs in xterm sometimes look a bit smaller than their regular counterparts. They look the same in mlterm, which means that this is a property of the font. So this issue is resolved as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it does. Using the default font size, -csp 1 suffices. When using larger font sizes, letter spacing must be bigger as well so that glyphs are not cut off.
Please have a look at the attachment. You can see two things:
1. mlterm uses subpixel rendering while xterm does not. Cool!
2. The "w" and "A" glyphs have the correct size, but they are translated 1px to the right. This happens only with some glyphs.
There is an according message in msg.log:
Oct 5 12:31:12[45005] Font(id 4d1) width(9) is not matched with standard width(8).
When using bigger font sizes, similar messages appear with larger values, e.g.:
Oct 5 12:22:34[43753] Font(id 4d1) width(14) is not matched with standard width(13).
Edit: Scroll in (if necessary, use an image viewer) until you see every pixel.
I don't really want to have a variable column width, but it's ok. This is the only problem that's left and it is not a big one. Let me know if you need any more information.
Two more remarks:
1. This problem occurs with other fonts as well.
2. The error messages I pasted above do not seem to occur consistently, and I have not found a way to trigger them yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, that was fast. It works perfectly, thank you very much. I have encountered a few more (very minor) things. But I will switch to the mailing list because I find it more convenient. I hope this is ok.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you.
I can confirm that disabling the scrollbar works now.
Regarding copy&paste, things are more complicated. I opened up xterm, mlterm and termite and tried to copy and paste text between them. Note that xterm runs through xwayland while mlterm and termite do not. My observations are:
Between xterm <-> termite and termite <-> mlterm, everything works fine.
mlterm -> xterm does not work; instead, it erases the current contents of the primary clipboard while copying the text to the normal clipboard (This can be checked with the wl-clipboard utility). As it seems, xterm (and other X11 applications like firefox) paste from the primary clipboard for some reason.
xterm -> mlterm causes mlterm to freeze. Copying something in xterm copies the text into the normal and the primary clipboard. But interestingly, doing this manually with wl-clipboard and then telling mlterm to paste works. There must be a difference between setting the clipboard contents using wl-clipboard and doing so by copying something in xterm.
Regards,
Eric Praline
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
I can now copy from mlterm-wl into xwayland applications (xterm, firefox etc. Of course, I don't need to copy things between xterm and mlterm-wl, xterm is just one example of an xwayland application).
But copying from xwayland apps to mlterm still causes mlterm to freeze. There is no information on this in msg.log. Please let me know if I can help with some logs etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Thanks.
Will you add "#define __DEBUG" to uiwindow/wayland/ui_display.c and rebuild mlterm-wl?
Then, if you start mlterm-wl, it outputs logs to ~/.mlterm/msg.log.
Please send me ~/.mlterm/msg.log.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
I really like mlterm, in particular because it is so fast -- much faster than all those "new" terminal emulators.
Since mlterm supports wayland, I tried running it under sway, but that doesn't work. Is it possible that mlterm only supports the wl_shell protocol? Sway has dropped support for that since it is supposed to be replaced by the xdg-shell protocol.
I don't know whether switching to the new protocol is a priority for you, but I just wanted to let you know.
Thanks for writing mlterm!
Hi.
I'm sorry for my late reply.
mlterm now supports xdg-shell-v6 (unstable) at hg head (revision 8e11edf3e0b5).
https://bitbucket.org/arakiken/mlterm/get/tip.zip
If you find some problems, please report them to me.
Regards,
Thank you for implementing this.
Mlterm now starts up, but I ran into a few issues:
1) When I try do disable the scrollbar (either via use_scrollbar=false in ~/.mlterm/main or on the command line by setting --sbmod=none), mlterm hangs. That is, I type "mlterm-wl" but nothing happens and the command does not exit. msg.log does not contain any errors. (I do not need scrollback anyway, but I did not find a way to disable it completely.)
2) There seems to be a problem with my keyboard layout (German). I have LANG=de_DE.UTF-8 and mlterm prints special characters in files like ö,ä,ü just fine, but if I type "ä", it behaves like a dead key: On the first keypress, nothing happens. On the second keypress, a strange character ("A" with a tilda on top of it) is printed.
3) Is it correct that copy&paste is not working under wayland right now?
Let me know if I can help by supplying more information.
Regards
Eric Praline
On 9/28/2019 12:24 PM, Eric Praline wrote:
I suspect the A-tilde is a representation of the first byte of a-umlaut
in UTF-8. That is, the UTF-8 representation of "ä" consists of the
bytes \xc3\xa4, and \u00C3 is 'LATIN CAPITAL LETTER A WITH TILDE'. (The
byte \xa4 corresponds to the Unicode character 'CURRENCY SIGN', which is
a funny looking character.)
So somehow what you type and what is displayed seem to be in two
different Unicode encodings.
--
Mike Maxwell
"I am, by a flood, borne back to that wondrous
period, ere time itself can be said to have begun;
for time began with man." --Herman Melville,
Moby Dick
Thanks.
I fixed 1) issue.
Diff:
https://bitbucket.org/arakiken/mlterm/commits/0550403a961609b1b2829f226f9a9567e2c191ff#chg-uitoolkit/wayland/ui_display.c
Archive:
https://bitbucket.org/arakiken/mlterm/get/tip.zip
Diff:
https://bitbucket.org/arakiken/mlterm/commits/c311b122004daaf3b7cdcf7bef3d081706e32faa#chg-uitoolkit/wayland/ui_display.c
Archive:
https://bitbucket.org/arakiken/mlterm/get/tip.zip
I fixed 2) issue.
Diff:
https://bitbucket.org/arakiken/mlterm/commits/5c4ded96de03fbb85081626a8ee70065df191b3c
(This diff includes the minor improvement of rendering glyphs similar to http://mlterm.sf.net/mlterm-3.8.8-fixfontwidth.patch)
Archive:
https://bitbucket.org/arakiken/mlterm/get/tip.zip
I also notice slight differences in font rendering when comparing mlterm to xterm or termite (which do not seem to differ from each other). For example, when using the Inconsolata font (ttf-inconsolata in arch community), some glyphs are rendered one pixel too far to the right. This is e.g. the case with "w" and "A". They are cut off at the right end and the distance to the preceding character is a little bit too large.
Also, I get the impression that xterm slightly reduces the font size of some glyphs when rendering bold text, while mlterm does not do that.
Both issues can be observed very well in mutt, which renders the line with the currently active email bold. Switching between lines in xterm and mlterm, you can see both phenomena: Characters jumping 1px to the right/left in mlterm, and a changing glyph size in xterm.
Regarding the glyph size, this is probably a question of aesthetics. I like the way xterm does it, but that may be because I have been using it for a long time. The horizontal positioning issue looks like a bug to me.
(I hope that I'm not getting on your nerves.)
Regards,
Eric Praline
Thanks.
Does this patch improve it?
http://mlterm.sf.net/mlterm-3.8.8-fixfontwidth.patch
Yes, it improves the situation in that the characters do not jump to the left or right anymore when switching between regular and boldface. Still, when switching from regular to boldface, it looks like the text is moving a little bit to the upper right. But that is certainly a very minor thing.
The main issue, namely some characters being cut off at the right side, remains.
At the moment, I am not sure whether what I see is Inconsolata Bold or an algorithmically emboldened version of Inconsolata Regular. My aafont file looks like this:
DEFAULT = Inconsolata
In the main file, I have:
use_aafont = true
use_bold_font = true
I tried to set the bold font manually in the aafont file. I tried
BOLD = Inconsolata:style=Regular
or
DEFAULT_BOLD = ...,
but that did not work.
Does "ISO10646_UCS4_1_BOLD=Inconsolata:style=Regular" in aafont work ?
Yes! But mlterm still uses double drawing on the bold font specified this way. (By the way, is this supposed to work? I'm using utf-8, not ucs4.)
I fixed to unuse FT_Outline_Embolden() for a font whose name contains "bold".
Please try hg head, and set the bold font manually in aafont as follows.
ISO10646_UCS4_1_BOLD=Inconsolata:style=Bold
It works, thank you!
By the way, I mentioned that bold glyphs in xterm sometimes look a bit smaller than their regular counterparts. They look the same in mlterm, which means that this is a property of the font. So this issue is resolved as well.
Does letter_space option imrove it?
$ mlterm-wl -csp 3
Yes, it does. Using the default font size, -csp 1 suffices. When using larger font sizes, letter spacing must be bigger as well so that glyphs are not cut off.
Please have a look at the attachment. You can see two things:
1. mlterm uses subpixel rendering while xterm does not. Cool!
2. The "w" and "A" glyphs have the correct size, but they are translated 1px to the right. This happens only with some glyphs.
There is an according message in msg.log:
Oct 5 12:31:12[45005] Font(id 4d1) width(9) is not matched with standard width(8).
When using bigger font sizes, similar messages appear with larger values, e.g.:
Oct 5 12:22:34[43753] Font(id 4d1) width(14) is not matched with standard width(13).
Edit: Scroll in (if necessary, use an image viewer) until you see every pixel.
Last edit: Eric Praline 2019-10-05
I'm investigating the cause, but It seems to take a long time to improve completely.
How about -V option ? Does it fit to you?
I don't really want to have a variable column width, but it's ok. This is the only problem that's left and it is not a big one. Let me know if you need any more information.
Two more remarks:
1. This problem occurs with other fonts as well.
2. The error messages I pasted above do not seem to occur consistently, and I have not found a way to trigger them yet.
I fixed this problem.
https://bitbucket.org/arakiken/mlterm/commits/7d800c6e9225a95d14477b613e0794f0fd65056b#chg-uitoolkit/fb/ui_font.c
I ’m not sure if this fix always works, so let me know if you find some other problems.
Well, that was fast. It works perfectly, thank you very much. I have encountered a few more (very minor) things. But I will switch to the mailing list because I find it more convenient. I hope this is ok.
Thank you.
I can confirm that disabling the scrollbar works now.
Regarding copy&paste, things are more complicated. I opened up xterm, mlterm and termite and tried to copy and paste text between them. Note that xterm runs through xwayland while mlterm and termite do not. My observations are:
Between xterm <-> termite and termite <-> mlterm, everything works fine.
mlterm -> xterm does not work; instead, it erases the current contents of the primary clipboard while copying the text to the normal clipboard (This can be checked with the wl-clipboard utility). As it seems, xterm (and other X11 applications like firefox) paste from the primary clipboard for some reason.
xterm -> mlterm causes mlterm to freeze. Copying something in xterm copies the text into the normal and the primary clipboard. But interestingly, doing this manually with wl-clipboard and then telling mlterm to paste works. There must be a difference between setting the clipboard contents using wl-clipboard and doing so by copying something in xterm.
Regards,
Eric Praline
Hi,
mlterm-wl didn't support X11 Primary selection.
I fixed to support it and now copy&paste between mlterm and xterm works.
https://bitbucket.org/arakiken/mlterm/get/tip.zip
Hi.
I can now copy from mlterm-wl into xwayland applications (xterm, firefox etc. Of course, I don't need to copy things between xterm and mlterm-wl, xterm is just one example of an xwayland application).
But copying from xwayland apps to mlterm still causes mlterm to freeze. There is no information on this in msg.log. Please let me know if I can help with some logs etc.
Hi, Thanks.
Will you add "#define __DEBUG" to uiwindow/wayland/ui_display.c and rebuild mlterm-wl?
Then, if you start mlterm-wl, it outputs logs to ~/.mlterm/msg.log.
Please send me ~/.mlterm/msg.log.