Activity for mlterm(Multi Lingual TERMinal emulator)
-
mlterm(Multi Lingual TERMinal emulator) released /01release/mlterm-3.9.4/mlterm-3.9.4.tar.gz
-
-
-
-
Araki Ken posted a comment on ticket #85
Hi, Now I fixed the issue 1. https://github.com/arakiken/mlterm/archive/master.zip
-
Atemu posted a comment on ticket #85
Hi, I can confirm that the bugs highlighted by my repro script have been fixed. Thank you! While playing around however, I managed to get the lines to scroll up again by printing long lines in a small window and then scaling it up. Repro for the new bug variant: 1 2 3 4 5 6 7 8 9 10 11#!/bin/sh printf "\x1b[8;20;80t" for j in {0..10} ; do echo -n " $j: " for i in {00..50} ; do echo -n $i ; done done echo echo last line at the bottom of the terminal sleep 2 printf "\x1b[8;20;120t" echo last line no...
-
Thanks. I fixed to at least make the script work correctly. I'd like you to test https://github.com/arakiken/mlterm/archive/master.zip But it is quite difficult to solve the problem 1 soon. Mlterm assumes that the data in the backlog doesn't need to be edited, thereby simplifies the implementation (bidi, opentype layout and so on). Major design change is necessary to rewap lines in the backlog. Regards,
-
Hi! Thank you so much for the fix! I can confirm that dynamic resizing is working and output is not being eaten up by horizontal resizing anymore. As you mentioned it isn't quite perfect, there are three minor issues I have noticed: Scrolling up (Shift+PgUp) after scaling down the window doesn't reflow the old output that was off-screen (vertically) before, it stays truncated. Scrolling up after enlarging the window again brings it back though. When scaling down the window, the log is pushed off-screen...
-
Hi, thanks for your report. Mlterm now supports your request. Please try https://github.com/arakiken/mlterm/archive/master.zip (It is not completely compatible to rxvt-unicode, but I think it generally works fine.) If you find strange behavior, I would like you to send me a script to reproduce it. Sample script is http://mlterm.sf.net/mlterm-resize-test.sh Regards,
-
Horizontal resizing and wrapping
-
-
-
Evgenii Burmentev posted a comment on ticket #84
Thank you, now works.
-
Thanks. mlterm-wl used wl_shell or xdg-shell v6 unstable. But sway has removed support for xdg-shell v6 unstable since 1.4, so mlterm-wl failed to start in sway-1.4. Now mlterm-wl supports xdg-wm-base which sway-1.4 supports. Please try http://bitbucket.org/arakiken/mlterm/get/tip.tar.gz
-
I use sway 1.4 Here you are the logs: ==> .mlterm/msg.log <== Feb 11 14:36:12[8259] WARN: [vt_color.c:519] /home/gargantua/.mlterm/color couldn't be opened. Feb 11 14:36:12[8259] WARN: [ui_shortcut.c:77] /home/gargantua/.mlterm/key couldn't be opened. Feb 11 14:36:12[8259] WARN: [vt_termcap.c:179] /home/gargantua/.mlterm/termcap couldn't be opened. Feb 11 14:36:12[8259] DEBUG: Unknown interface: zwp_linux_dmabuf_v1 Feb 11 14:36:12[8259] DEBUG: Unknown interface: wl_drm Feb 11 14:36:12[8259] DEBUG:...
-
Thanks. I suspect that mlterm fails to bind wl_shell. Which window manager do you use? Will you rebuild mlterm-wl as follows and send me ~/.mlterm/msg.log again ? $ ./configure --enable-debug ... (edit uitoolkit/wayland/ui_display.c: #if 0 #define __DEBUG #endif -> #if 1 #define __DEBUG #endif) $ make; make install $ mlterm-wl
-
mlterm-wl segfault on start
-
Also support ‘modifyOtherKeys’ mode Ps==1
-
add EWMH support for _NET_WM_PID to 3.8.8
-
Scrolling behaviour on window resize
-
Mixed text/sixel crashes with segault
-
sixel output corruption with longcat
-
mlterm windows does not close until it receives a keypress
-
Thanks.
-
Thanks. I've merged it.
-
Sorry for my late reply. Thanks for your patch. I've merged it.
-
pathetic-lynx modified a comment on ticket #81
Havent used mlterm in a while, but the bug is no longer present as of 3.8.9. You can close this
-
Havent used mlterm in a while, but the bug is no longer present as of 3.8.9
-
Ahmed El-Mahmoudy created ticket #25
Fix spelling mistakes
-
Petr Gajdos posted a comment on ticket #78
Patch against 3.8.9.
-
Hey, could you please react, somehow ..
-
George L. Yermulnik posted a comment on ticket #13
Oh, my. This was not about mlterm. It's about this https://bugzilla.redhat.com/show_bug.cgi?id=1648170 Apologies for the noise — I recently switched to newer version of the distro I use and at first glance I thought it was mlterm that sort of misbehaved but eventually mlterm is fine =) Thanks for the help finding the culprit =)
-
For example, doesn't --bl=red disable blinking ? What happens if you execute as follows ? $ echo -e "\x1b[5maaaa\x1b[m" aaaa <= blinking $ mlcc bl_color red $ echo -e "\x1b[5maaaa\x1b[m" aaaa <= Not blinking
-
Could you please give an example of value for bl_color — I tried differrent values but it didn't disable blinking =(
-
--bl option (or $ mlcc bl_color xxx) which sets alternate color to blinking characters disables blinking. But it disabled blinking but didn't set alternate color. Following commit fixes it. https://bitbucket.org/arakiken/mlterm/commits/45766b7f1442a4984b22854b75b89af28b18887a
-
Kevin Schoedel posted a comment on ticket #21
Thank you!
-
Disable blinking text
-
Hi, I supported it. https://bitbucket.org/arakiken/mlterm/commits/c18b19b0ae9481e502ba795622a0d15c52d5a900 Regards,
-
Also support ‘modifyOtherKeys’ mode Ps==1
-
-
Maximilian Claus posted a comment on ticket #82
Yes! I can confirm the behaviour is exactly like xterm now. Thank you so much! I can use mlterm as my everyday terminal now! :)
-
Hi, I fixed. Please test it. Diff: https://bitbucket.org/arakiken/mlterm/commits/b0c624ceb27426792f3a121c95e1ecd18ab8a1d0 Archive: http://bitbucket.org/arakiken/mlterm/get/tip.tar.gz
-
Yoichi NAKAYAMA modified a comment on ticket #83
I've confirmed the problem won't be reproduced after applying https://bitbucket.org/arakiken/mlterm/commits/a6e36763fc52cb27886c61facdee2014aca1aa3d on my Ubuntu environment. Thanks!
-
I've confirmed the problem is gone after applying https://bitbucket.org/arakiken/mlterm/commits/a6e36763fc52cb27886c61facdee2014aca1aa3d on my Ubuntu environment. Thanks!
-
sixel output corruption with longcat
-
Scrolling behaviour on window resize
-
Eric Praline posted a comment on discussion Help
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.
-
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.
-
I re-downloaded 3.8.8, didn't pass anything to configure and built mlterm again. This time it starts without any problem. The problem still persists (I applied the patch before building). uname -a: Linux shell 5.3.4-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 5 13:44:11 UTC 2019 x86_64 GNU/Linux Oh I forgot, removing .mlterm does not change anything either
-
I re-downloaded 3.8.8, didn't pass anything to configure and built mlterm again. This time it starts without any problem. The problem still persists (I applied the patch before building). uname -a: Linux shell 5.3.4-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 5 13:44:11 UTC 2019 x86_64 GNU/Linux
-
I re-downloaded 3.8.8, didn't pass anything to configure and built mlterm again. This time it starts without any problem. The problem still persists (I applied the patch before building).
-
Hi, What option do you specified to ./configure script ? Which environment do you build and run ? Does mlterm start or not if you remove files in ~/.mlterm ? Then, please test as follows and send me the result of it. $ gdb /foo/bar/mlterm (the binary produced by the build process) run
-
Unfortunately I cannot test it, because the binary produced by the build process SEGFAULTs on startup. Any idea why? (it was like this before the patch)
-
Thanks. I think that http://mlterm.sf.net/mlterm-3.8.8-fixes.patch fixes this problem.
-
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.
-
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.
-
Nevermind, it's there now. -- Copy&Paste works flawlessly now, thank you!
-
Thank you. I do not see any new commits at hg head. Did you push?
-
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 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
-
Thanks. I found that mlterm-wl specified incorrect mime type to receive selected text. I fixed this problem. Please test hg head.
-
Here is another log, pasting from firefox instead of xterm. These are the complete logs. Pressing keys after mlterm has freezed and killing mlterm is not logged.
-
Here it is. What I did: 1. Open mlterm-wl 2. Press Shift+Insert.
-
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...
-
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...
-
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.
-
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.)
-
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.
-
Does "ISO10646_UCS4_1_BOLD=Inconsolata:style=Regular" in aafont work ?
-
Does letter_space option imrove it? $ mlterm-wl -csp 3
-
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
-
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
-
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.
-
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.
-
Thanks. Does this patch improve it? http://mlterm.sf.net/mlterm-3.8.8-fixfontwidth.patch
-
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...
-
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. Diff: https://bitbucket.org/arakiken/mlterm/commits/c311b122004daaf3b7cdcf7bef3d081706e32faa#chg-uitoolkit/wayland/ui_display.c Archive: https://bitbucket.org/arakiken/mlterm/get/tip.zip
-
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
-
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...
-
Mike Maxwell posted a comment on discussion Help
On 9/28/2019 12:24 PM, Eric Praline wrote: 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 "ä"...
-
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)....
-
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,
-
When setting the daemon_mode to blend or genuine, attempting to close one terminal freezes all mlterm windows and makes opening a new instance impossible until I killall mlterm
-
mlterm windows does not close until it receives a keypress
-
Thanks for your report. I revive WM_CLASS property at hg head. https://bitbucket.org/arakiken/mlterm/get/ba0fb4374d57.zip (mlterm-3.8.6 removed WM_CLASS property for workaround in order to avoid a problem related to lxde.)
-
Thanks. I merged your patch.
-
Omar Shaalan posted a comment on discussion Help
I'm running MLTerm on a system based on Arch-linux, When my Language is set to Arabic in the locale as shown below, and I launch a MLTerm session it doesn't render English letters, although I do write command and they run (which means that the content of the command was understood and not garbage) but all the letters appear as a boxes, but if I open an Arabic text file the Arabic text will be displayed correctly. localectl status System Locale: LANG=ar_EG.UTF-8 LC_COLLATE=C VC Keymap: ar_EG X11 Layout:...
-
Autumn Lamonte posted a comment on ticket #79
I just tried with 3.8.8, and can confirm that it is fixed.
-
Bert created ticket #80
WM_CLASS property is missing
-
add EWMH support for _NET_WM_PID to 3.8.8
-
Kevin Schoedel posted a comment on discussion Help
Thanks for your reply. The problem did turn out to be with the font, which was at a different version between the different systems. (The same font problem is described by someone else using a different terminal at https://github.com/belluzj/fantasque-sans/issues/101 )
-
Thanks for your report. I can't reproduce it on my environment. (arch linux) Which font do you use? Does this problem happen if you use other fonts ? If you show me your configuration files in ~/.mlterm and log messages in ~/.mlterm/msg.log, I might know the reason. Regards,
-
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 mlter...
-
I have this problem on one of my systems, but I can't find the misconfiguration. The mlterm configuration at least is identical. I have encoding=UTF8 and auto_detect_encodings=false, and my locale is LANG=en_CA.UTF-8. But mlterm is somehow treating the Unicode close-quotation marks U+2018 (’) and U+201D (”) as something like combining acute accents, instead of themselves. That is, I see something like $ echo $'These are \u2018single\u2019 and \u201Cdouble\u201D quotes.' These are ‘singlé and “double̋...
-
I have this problem on one of my systems, but I can't find the misconfiguration. The mlterm configuration at least is identical. I have encoding=UTF8 and auto_detect_encodings=false, and my locale is LANG=en_CA.UTF-8. But mlterm is somehow treating the Unicode close-quotation marks U+2018 (’) and U+201D (”) as something like combining acute accents, instead of themselves. That is, I see something like $ echo $'These are \u2018single\u2019 and \u201Cdouble\u201D quotes.' These are ‘singlé and “double̋...
-
-
-
Thanks. This is a bug of mlterm. The attached patch will fix this problem. Regards,
-
Mixed text/sixel crashes with segault
-
