mlterm-dev-en — mlterm mailing list(English)

[Mlterm-dev-en] mlterm: weird mouse behaviour

[John S. <jd...@ca...>]

Ubuntu 20.04, Gnome shell 3.36.2 running under X11, Ubuntu distribution
version of mlterm — version 3.8.9, Features: otl ssh implugin
imagelib(builtin) utmp.

I have configured mlterm for use with normal Roman and also Devanagari
(Hindi). Both appear to work well.

Once mlterm is displaying some text, if I move the mouse it behaves as if I
were simultaneously pressing the left button: text is highlighted and the
window scrolls up/down. Nothing I do seems to change this behaviour. I have
tried modifying the settings for clipboard and scroll under “Others” in
mlterm’s menu, but these changes seem to have no effect, and anyway they don’t
“stick” — they always revert to the default (clipboard selection checked, the
two scroll options unchecked).

The only item in my msg.log file is

May 27 08:55:16[277993] Font(id 10d1) width(10) is not matched with standard width(8).

repeated whenever I switch into the Devanagari font.

I would be happy to try compiling the current version of mlterm, but would
need specific guidance on what options to use for ./configure.

Thanks for any help,
John Smith

--
John Smith
jd...@ca...
https://bombay.indology.info

[Mlterm-dev-en] mlterm 3.9.0 released

[Araki K. <ara...@us...>]

 Hi,

 This is to announce the release of mlterm version 3.9.0

 http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.9.0/mlterm-3.9.0.tar.gz/download

 SHA1 (mlterm-3.9.0.tar.gz) = be37059caab99219be79b14cfabfb26d34bb8954

Overview of changes from 3.8.9
===============================
ver 3.9.0
* Support CSI>4;1m.
* Support uniscribe for libotl on win32.
* Support SCP by Shift+DnD on HaikuOS.
* Support xdg-shell on wayland.
* Support DEC Technical character set.
* Support input of unicode characters on mlterm-fb.
* Support ormode of Sixel Graphics.
* Update unicode property table (generated from UnicodeData.txt and
  EastAsianWidth.txt) to version 12.1.0.
* Mlconfig configures files in ~/.mlterm directly if it starts without options
  or with --file option.
* Change DA1 response.
  \x1b[?63;1;2;3;4;7;29c -> \x1b[?63;1;2;3;4;6;7;15;18;22;29c
* geometry / -g option works on HaikuOS.
* Add vte 0.60 API symbols to libvte compatible library.
* Merge patches:
  https://sourceforge.net/p/mlterm/bugs/78/
  https://sourceforge.net/p/mlterm/patches/25/attachment/typos.diff
* Bug fixes:
  Fix a bug which disabled to change the value of "logsize" option from "0" to "unlimited".
  Fix segfault when "snapshot" command of OSC 5379 is executed.
  Fix mouse tracking position if "use_ot_layout = true".
  Fix segfault when mlterm-sdl2 starts with -im=uim option.
  Fix a bug which makes mlterm-sdl2 on win32 stop starting mlconfig.
  Fix compiling error on HaikuOS + gcc-x86.
  Fix http://twitter.com/hamano/status/1177087752208183296
  Fix a bug which disabled clipping of DECDHL in cairo. (Enbugged at 3.8.6)
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Bug with Vim and Cyrillic Compose Sequences

[<kec...@ke...>]

Hey,

That fixes the bug for me, at least for the compose sequence that I 
included in the repro steps in my original report.

Thank you!

  - Kelvin

On Sun, Mar 15, 2020 at 01:56:55PM +0900, Araki Ken wrote:
> Hi,
>
>kec...@ke... wrote:
>> I've encountered a bug where mlterm crashes with a buffer overflow
>> when I try to type a compose sequence consisting of cyrillic
>> characters, the first of which is lowercase and the second capital,
>> into vim running in mlterm.
>>
>> More precise steps to reproduce are:
>>
>>  - Add the line '<Multi_key> <Cyrillic_zhe> <Cyrillic_ZHE> : "TEST"' to
>>  - your ~/.XCompose file (or any sequence of a lowercase cyrillic letter
>>  - followed by a capital; all of the ones I've tried have worked).
>>    - Open mlterm and run Vim
>>
>>  - Press i to insert text into Vim, and then change keyboard to Russian
>>
>>  - Type the above compose sequence (Cyrillic zhe is usually located on
>>  - the semicolon/colon key when you use the Russian layout with an
>>  - American keyboard; for other keyboards you may need to look up the
>>  - layout and find the key before trying this)
>>
>>  - Expected behavior is that "TEST" should appear in Vim, but actual
>>  - behavior is that mlterm crashes.
>>
>> Per @arakiken's request (via Twitter), I've attached a log file
>> obtained by launching mlterm with --logseq and reproducing this
>> bug. I'm running mlterm version 3.8.9 with features otl, ssh, implugin
>> and utmp, although I've seen this bug on v3.8.1 as well (upgrading
>> didn't change anything).  My OS is Sabayon Linux, with kernel version
>> 5.4.0.
>>
>> Note that this bug *only* occurs in Vim running in mlterm; typing the
>> above compose sequence directly into mlterm works as expected.
>
> Thanks for your detailed report.
> I couln't reproduce the crash, but I found a bug which seems to be related
>to this problem.
>
> Please test https://bitbucket.org/arakiken/mlterm/get/tip.tar.gz
> (Diff: https://bitbucket.org/arakiken/mlterm/commits/fc3566fff20d05163a1b6c154e2a438e150e4e7c)
>
> If it doesn't solve this problem, will you use gdb to investigate where
>mlterm crashes ?
>
>$ gdb /foo/bar/mlterm
>(gdb) run
>... -> crashes mlterm
>(gdb) bt
>... -> Please send me this backtrace.
>
> (My environment)
> OS: Arch Linux (Kernel: 5.0.13)
> mlterm: hg head(changeset 3072), mlterm-3.8.9 or mlterm-3.8.8 (~/.mlterm is empty)
> vim: 8.2 (~/.vimrc is empty)
>
> Regards,
>---
>Araki Ken
>ara...@us...

Re: [Mlterm-dev-en] Bug with Vim and Cyrillic Compose Sequences

[Araki K. <ara...@us...>]

 Hi,

kec...@ke... wrote:
> I've encountered a bug where mlterm crashes with a buffer overflow
> when I try to type a compose sequence consisting of cyrillic
> characters, the first of which is lowercase and the second capital,
> into vim running in mlterm.
> 
> More precise steps to reproduce are:
> 
>  - Add the line '<Multi_key> <Cyrillic_zhe> <Cyrillic_ZHE> : "TEST"' to
>  - your ~/.XCompose file (or any sequence of a lowercase cyrillic letter
>  - followed by a capital; all of the ones I've tried have worked).
>    - Open mlterm and run Vim
> 
>  - Press i to insert text into Vim, and then change keyboard to Russian
> 
>  - Type the above compose sequence (Cyrillic zhe is usually located on
>  - the semicolon/colon key when you use the Russian layout with an
>  - American keyboard; for other keyboards you may need to look up the
>  - layout and find the key before trying this)
> 
>  - Expected behavior is that "TEST" should appear in Vim, but actual
>  - behavior is that mlterm crashes.
> 
> Per @arakiken's request (via Twitter), I've attached a log file
> obtained by launching mlterm with --logseq and reproducing this
> bug. I'm running mlterm version 3.8.9 with features otl, ssh, implugin
> and utmp, although I've seen this bug on v3.8.1 as well (upgrading
> didn't change anything).  My OS is Sabayon Linux, with kernel version
> 5.4.0.
> 
> Note that this bug *only* occurs in Vim running in mlterm; typing the
> above compose sequence directly into mlterm works as expected.

 Thanks for your detailed report.
 I couln't reproduce the crash, but I found a bug which seems to be related
to this problem.

 Please test https://bitbucket.org/arakiken/mlterm/get/tip.tar.gz
 (Diff: https://bitbucket.org/arakiken/mlterm/commits/fc3566fff20d05163a1b6c154e2a438e150e4e7c)

 If it doesn't solve this problem, will you use gdb to investigate where
mlterm crashes ?

$ gdb /foo/bar/mlterm
(gdb) run
... -> crashes mlterm
(gdb) bt
... -> Please send me this backtrace.

 (My environment)
 OS: Arch Linux (Kernel: 5.0.13)
 mlterm: hg head(changeset 3072), mlterm-3.8.9 or mlterm-3.8.8 (~/.mlterm is empty)
 vim: 8.2 (~/.vimrc is empty)

 Regards,
---
Araki Ken
ara...@us...

[Mlterm-dev-en] Bug with Vim and Cyrillic Compose Sequences

[<kec...@ke...>]

Hey,

I've encountered a bug where mlterm crashes with a buffer overflow when 
I try to type a compose sequence consisting of cyrillic characters, the 
first of which is lowercase and the second capital, into vim running in 
mlterm.

More precise steps to reproduce are:

  - Add the line '<Multi_key> <Cyrillic_zhe> <Cyrillic_ZHE> : "TEST"' to 
    your ~/.XCompose file (or any sequence of a lowercase cyrillic letter 
    followed by a capital; all of the ones I've tried have worked).
  
  - Open mlterm and run Vim

  - Press i to insert text into Vim, and then change keyboard to Russian

  - Type the above compose sequence (Cyrillic zhe is usually located on 
    the semicolon/colon key when you use the Russian layout with an 
    American keyboard; for other keyboards you may need to look up the 
    layout and find the key before trying this)

  - Expected behavior is that "TEST" should appear in Vim, but actual 
    behavior is that mlterm crashes.

Per @arakiken's request (via Twitter), I've attached a log file obtained 
by launching mlterm with --logseq and reproducing this bug. I'm running 
mlterm version 3.8.9 with features otl, ssh, implugin and utmp, although 
I've seen this bug on v3.8.1 as well (upgrading didn't change anything).  
My OS is Sabayon Linux, with kernel version 5.4.0.

Note that this bug *only* occurs in Vim running in mlterm; typing the 
above compose sequence directly into mlterm works as expected.

Thanks!

  - Kelvin

[Mlterm-dev-en] mlterm 3.8.9 released

[Araki K. <ara...@us...>]

 Hi,

 This is to announce the release of mlterm version 3.8.9

 http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.8.9/mlterm-3.8.9.tar.gz/download

 SHA1 (mlterm-3.8.9.tar.gz) = 485d1f3215e12db8cd23f39a5c06b21e3e802307

Overview of changes from 3.8.8
===============================
ver 3.8.9
* Support zmodem. (See doc/en/README.tarnsfer)
* Add "send_file" and "zmodem_start" to OSC 5379.
* Add receive_directory / --recvdir option.
* Support xdg-shell-v6 (unstable) on wayland.
* Support copy&paste via X11 primary selection on wayland.
* Hide the mouse cursor in inputting keys by default on xlib and win32.
* ~/.mlterm/font accepts UTF-8 on windows.
* Change the default value of "font_size_range" option from 1-100 to 1-10000.
* Clear a window and scroll out all lines on resizing only if
  the value of --sr / "scroll_on_resizing" option is true.
* Set _NET_WM_PID property.
* Revive -N/"app_name" option which sets WM_CLASS property.
  (WM_CLASS was disabled at 3.8.6)
* Add a percent or number argument without '+' and '-' to "vresize_screen" and
  "hresize_screen" of OSC 5379.
* Add "RESET" (which resets the parser of mlterm) as a shortcut key.
* Add vte 0.58 API symbols to libvte compatible library.
* Merge patches:
  https://bitbucket.org/arakiken/mlterm/pull-requests/5/fix-for-wscons-framebuffer/diff
  https://sourceforge.net/p/mlterm/patches/24/
* Bug fixes:
  Fix memory leaks of libptymosh.so
  Fix https://sourceforge.net/p/mlterm/mailman/message/36633222/ (Enbugged at 3.8.8)
  Fix segfault of mlterm for java by race condition.
  Fix unexpected invalidation of --mdi=false option. (Enbugged at 3.8.8)
  Fix uninitialized memory access of mlimgloader.exe for win32.
  Fix broken images of some sixel graphics. (Enbugged at 3.8.5)
---
Araki Ken
ara...@us...

[Mlterm-dev-en] True true-color support

[Yuri D'E. <wa...@th...>]

vt_color_mode/--vtcolor accepts "true" to set true color mode, however
it's limited to a 512-color palette internally:

https://sourceforge.net/p/mlterm/bugs/74/

console_sixel_colors however does seem to support real true-color mode.

I wonder why this limitation exists?
I guess internally all vt operations operate on a color index?

Re: [Mlterm-dev-en] xdg-shell: app_id and key repeat settings

[Araki K. <ara...@us...>]

 Hi,

Christian Victor Schulz <cv....@ma...> wrote:
> If I look at the output of
> 	swaymsg -t get_tree
> under sway, I can see that mlterm does not set the "app_id", which I
> believe is similar to X11's window class. For example, Sway allows the
> selection of windows by app_id in its for_window rules. I don't need
> this functionality, but it might be a good idea to set the app_id to
> "mlterm" or "mlterm-wl" at some point.

 I set app_id to "mlterm".
 If you want to change it, use --name option.

> Also, there seems to be something wrong with key repeat on wayland. I
> can configure key repeat in sway with
> 	input * repeat_delay <delay [ms]>
> 	input * repeat_rate <rate [ms]>,
> and as can be seen in the debug log I posted with regards to the
> copy&paste issue, sway correctly announces those settings to mlterm. But
> mlterm's behaviour does not match the settings. For example, when I have
> delay = 220, rate = 25, key repeat works but the rate is too fast. If I
> set the rate to 75, key repeat does not work at all anymore.

 Thanks. I fixed.
 But mlterm-wl can't adjust a repeating interval finer than 25msec per key
(the rate of repeating keys per sec is 40) for now.

 Regards,
---
Araki Ken
ara...@us...

[Mlterm-dev-en] xdg-shell: app_id and key repeat settings

[Christian V. S. <cv....@ma...>]

Hi Araki Ken,

again, thank you for fixing the glyph rendering problem. Here are two
other minor things I noticed.


If I look at the output of
	swaymsg -t get_tree
under sway, I can see that mlterm does not set the "app_id", which I
believe is similar to X11's window class. For example, Sway allows the
selection of windows by app_id in its for_window rules. I don't need
this functionality, but it might be a good idea to set the app_id to
"mlterm" or "mlterm-wl" at some point.

Also, there seems to be something wrong with key repeat on wayland. I
can configure key repeat in sway with
	input * repeat_delay <delay [ms]>
	input * repeat_rate <rate [ms]>,
and as can be seen in the debug log I posted with regards to the
copy&paste issue, sway correctly announces those settings to mlterm. But
mlterm's behaviour does not match the settings. For example, when I have
delay = 220, rate = 25, key repeat works but the rate is too fast. If I
set the rate to 75, key repeat does not work at all anymore.

Best regards,
Christian Schulz (aka Eric Praline)

Re: [Mlterm-dev-en] mlterm 3.8.8 clears perhaps too aggressively

[Araki K. <ara...@us...>]

 Hi,

"Yuri D'Elia" <wa...@th...> wrote:
> On Mon, May 06 2019, Yuri D'Elia wrote:
>> I often keep the terminal maximized, and when switching a terminal
>> between two screens (which are not the same size) I often now stare at a
>> completely blank terminal. If you had a command running which does't
>> emit any output, there's no feedback of what is going on.
> 
> This was happening waay too frequently for me.
> 
> I would move the terminal to the external screen (which is smaller),
> come back later and just see blank - having no idea of what was running
> in there.
> 
> I reverted the code in vt_edit.c in the commit
> 3b04c25cf0899b43547eeb61e8dca4c03af4a1ec to bring back the old behavior.
> 
> I'd rather have truncated lines.

 Sorry for my late reply.

 I reverted the behavior by default.

---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] mlterm 3.8.8 clears perhaps too aggressively

[Yuri D'E. <wa...@th...>]

On Mon, May 06 2019, Yuri D'Elia wrote:
> I often keep the terminal maximized, and when switching a terminal
> between two screens (which are not the same size) I often now stare at a
> completely blank terminal. If you had a command running which does't
> emit any output, there's no feedback of what is going on.

This was happening waay too frequently for me.

I would move the terminal to the external screen (which is smaller),
come back later and just see blank - having no idea of what was running
in there.

I reverted the code in vt_edit.c in the commit
3b04c25cf0899b43547eeb61e8dca4c03af4a1ec to bring back the old behavior.

I'd rather have truncated lines.

[Mlterm-dev-en] mlterm 3.8.8 clears perhaps too aggressively

[Yuri D'E. <wa...@th...>]

Compared to previous versions, mlterm 3.8.8 has a different shrinking
behavior.

I often keep the terminal maximized, and when switching a terminal
between two screens (which are not the same size) I often now stare at a
completely blank terminal. If you had a command running which does't
emit any output, there's no feedback of what is going on.

It seems that the window content is put in the backscroll, which is
helpful as it doesn't get trimmed when the window is resized, but then
it's moved away.

Maybe just showing the backscroll until some new output is shown would
improve the behavior. But clearing the window because we lost a visible
column is excessive. I'd rather have the previous behavior where the
column was simply truncated.

Re: [Mlterm-dev-en] Hide mouse pointer while typing

[Araki K. <ara...@us...>]

 Hi,

From: "Yuri D'Elia" <wa...@th...>
Subject: Re: [Mlterm-dev-en] Hide mouse pointer while typing
Date: Fri, 19 Apr 2019 20:26:05 +0200
Message-ID: <873...@wa...>

> >  It works by default on my Arch Linux.
> >
> >  If it doesn't work correctly on your environment, please tell me
> > which distribution or window manager you use.
> 
> This is on debian unstable, using x11.
> 
> This seems to be caused by the fact that I don't have the "nil2" font
> (as used in uitoolkit/xlib/ui_display.c:529).
> 
> If I replace with something else, such as "fixed", it works.
> Since the mask is [space], fixed is probably a better choice.

 Thanks.
 I fixed it.

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Hide mouse pointer while typing

[Yuri D'E. <wa...@th...>]

On Fri, Apr 19 2019, Araki Ken wrote:
>  This feature is enabled by default, and CSI > 0 p sequence disables it.
>  (It is impossible to tweak it via "main" configuration file for now.)
>
>  It works by default on my Arch Linux.
>
>  If it doesn't work correctly on your environment, please tell me
> which distribution or window manager you use.

This is on debian unstable, using x11.

This seems to be caused by the fact that I don't have the "nil2" font
(as used in uitoolkit/xlib/ui_display.c:529).

If I replace with something else, such as "fixed", it works.
Since the mask is [space], fixed is probably a better choice.

Re: [Mlterm-dev-en] Hide mouse pointer while typing

[Araki K. <ara...@us...>]

 Hi,

From: "Yuri D'Elia" <wa...@th...>
Subject: Re: [Mlterm-dev-en] Hide mouse pointer while typing
Date: Thu, 18 Apr 2019 18:25:06 +0200
Message-ID: <87z...@wa...>

> On Thu, Apr 18 2019, Araki Ken wrote:
> >> Would it be possible to hide the mouse pointer as soon as some key is
> >> pressed when it's on top of the terminal, and just show it again when
> >> it's a move event is received?
> >
> >  Thanks. I support it.
> >  Please test hg head.
> 
> Is this set only through control sequences?
> 
> I'd like to have this enabled by default and/or tweak the behavior via
> the "main" configuration file.

 This feature is enabled by default, and CSI > 0 p sequence disables it.
 (It is impossible to tweak it via "main" configuration file for now.)

 It works by default on my Arch Linux.

 If it doesn't work correctly on your environment, please tell me
which distribution or window manager you use.
 I'll test it.

 Regards,
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Hide mouse pointer while typing

[Yuri D'E. <wa...@th...>]

On Thu, Apr 18 2019, Araki Ken wrote:
>> Would it be possible to hide the mouse pointer as soon as some key is
>> pressed when it's on top of the terminal, and just show it again when
>> it's a move event is received?
>
>  Thanks. I support it.
>  Please test hg head.

Is this set only through control sequences?

I'd like to have this enabled by default and/or tweak the behavior via
the "main" configuration file.

Re: [Mlterm-dev-en] Hide mouse pointer while typing

[Araki K. <ara...@us...>]

 Hi,

From: "Yuri D'Elia" <wa...@th...>
Subject: [Mlterm-dev-en] Hide mouse pointer while typing
Date: Sun, 14 Apr 2019 18:46:31 +0200
Message-ID: <87v...@wa...>

> Another feature that I miss from urxvt is pointer hiding.
> 
> Would it be possible to hide the mouse pointer as soon as some key is
> pressed when it's on top of the terminal, and just show it again when
> it's a move event is received?

 Thanks. I support it.
 Please test hg head.

 http://bitbucket.org/arakiken/mlterm/get/tip.tar.gz

---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] Cursor blinking behavior

[Yuri D'E. <wa...@th...>]

On Wed, Apr 17 2019, Araki Ken via Mlterm-dev-en wrote:
>> Would it be possible to tweak this behavior?
>
>  The attached patch adds a small delay.
>  Please try it.

Perfect :)

Re: [Mlterm-dev-en] Cursor blinking behavior

[Araki K. <ara...@us...>]

 Hi,

From: "Yuri D'Elia" <wa...@th...>
Subject: [Mlterm-dev-en] Cursor blinking behavior
Date: Sun, 14 Apr 2019 00:49:05 +0200
Message-ID: <87h...@wa...>

> I'm using the blinking cursor in mlterm. I would love the cursor to not
> blink for a small delay (0.5s) after I stop typing.
> 
> Currently mlterm might make the first blink immediately just after a key
> is depressed. I'm not sure if that's just because of a smaller delay
> being used or if there's no delay at all.
> 
> Would it be possible to tweak this behavior?

 The attached patch adds a small delay.
 Please try it.

---
Araki Ken
ara...@us...

[Mlterm-dev-en] Hide mouse pointer while typing

[Yuri D'E. <wa...@th...>]

Another feature that I miss from urxvt is pointer hiding.

Would it be possible to hide the mouse pointer as soon as some key is
pressed when it's on top of the terminal, and just show it again when
it's a move event is received?

[Mlterm-dev-en] Cursor blinking behavior

[Yuri D'E. <wa...@th...>]

I'm using the blinking cursor in mlterm. I would love the cursor to not
blink for a small delay (0.5s) after I stop typing.

Currently mlterm might make the first blink immediately just after a key
is depressed. I'm not sure if that's just because of a smaller delay
being used or if there's no delay at all.

Would it be possible to tweak this behavior?

Re: [Mlterm-dev-en] mlterm 3.8.8 slow exit

[Yuri D'E. <wa...@th...>]

On Thu, Apr 11 2019, Araki Ken wrote:
>  Please try a following patch.
>
>  http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.8.8/mlterm-3.8.8-fixes.patch/download

Thanks (I just rebuilt from the bitbucket repo, which includes this in
the last commit).

I can confirm that it fixes the issue.

Re: [Mlterm-dev-en] mlterm 3.8.8 slow exit

[Araki K. <ara...@us...>]

 Hi,

From: "Yuri D'Elia" <wa...@th...>
Subject: [Mlterm-dev-en] mlterm 3.8.8 slow exit
Date: Sun, 07 Apr 2019 21:43:40 +0200
Message-ID: <87b...@wa...>

> I'm just trying mlterm 3.8.8 from debian experimental.
> 
> Somehow the terminal doesn't always immediately quit as it should when
> the shell exits.
> 
> It just stays there until some extra event happens, just as the window
> losing/gaining focus, or even just pressing (and keeping pressed) a
> modifier key such as Shift. Even the cursor keeps on blinking.
> 
> This is 100% reproducible when the pointer is not on top of the window
> while quitting. If the pointer is *on* the window mlterm exists, but
> there's noticeable delay before it does that (50+ms)
> 
> My previous mlterm version was 3.8.6, so the bug could have been
> introduced in 3.8.7 as well.

 Thanks for your report.
 I fixed this problem.

 Please try a following patch.

 http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.8.8/mlterm-3.8.8-fixes.patch/download

 Regards,
---
Araki Ken
ara...@us...

[Mlterm-dev-en] mlterm 3.8.8 slow exit

[Yuri D'E. <wa...@th...>]

I'm just trying mlterm 3.8.8 from debian experimental.

Somehow the terminal doesn't always immediately quit as it should when
the shell exits.

It just stays there until some extra event happens, just as the window
losing/gaining focus, or even just pressing (and keeping pressed) a
modifier key such as Shift. Even the cursor keeps on blinking.

This is 100% reproducible when the pointer is not on top of the window
while quitting. If the pointer is *on* the window mlterm exists, but
there's noticeable delay before it does that (50+ms)

My previous mlterm version was 3.8.6, so the bug could have been
introduced in 3.8.7 as well.

[Mlterm-dev-en] mlterm 3.8.8 released

[Araki K. <ara...@us...>]

 Hi,

 This is to announce the release of mlterm version 3.8.8

 http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.8.8/mlterm-3.8.8.tar.gz/download

 SHA1 (mlterm-3.8.8.tar.gz) = 54f40fa50214656ab70f592d5d58805b1dfdc1c6

Overview of changes from 3.8.7
===============================
ver 3.8.8
* Support Haiku OS. (Experimental)
  (Execute ./configure with --with-gui=beos option.) (See doc/en/README.beos)
* Support "[font family]:style=..." format in aafont or font-fb config file.
* Support mosh. (Experimental) (See doc/en/README.mosh)
  (Don't distribute libptymosh in binary format.)
* Clear a window and scroll out all lines if the size of a window decreases
  and some characters in it disappear.
* Support "%s" (replaced by selected strings) in "exesel:..." in ~/.mlterm/key.
* Add local_echo_wait / --lew option.
* Remove libind_tamil.so because it is very buggy.
* Change the default shortcut key of INSERT_SELECTION from Shift+Insert to
  Command+v on MacOSX and iOS.
* Skip \r in configuration files.
* Start scp by Shift+Drag&Drop on not only xlib and win32 but also wayland, sdl2
  and cocoa. (Command+Drag&Drop on cocoa.)
* Change the default value of "font_size_range" option from 6-30 to 1-100.
* Add vte 0.56.0 API symbols to libvte compatible library.
* Bug fixes:
  Fix https://sourceforge.net/p/mlterm/mailman/message/36472061/
  Fix https://sourceforge.net/p/mlterm/mailman/message/36513313/
  Fix https://sourceforge.net/p/mlterm/bugs/79/
  Fix segfault in processing illegal sixel sequence.
  Fix invalidation of DECDWL on cairo. (Enbugged at 3.8.6)
  Fix handling ISCII fonts on cairo and xft. (Improve showing bengali characters.)
  Fix screen corruption (http://twitter.com/Cj_bc_sd/status/1088111309223161857)
  on MacOSX 10.14. (Thanks to @Cj_bc_sd)
  Fix segfault in showing an input method window. (Thanks to @isaki68k)
---
Araki Ken
ara...@us...