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

Re: [Mlterm-dev-en] "key" file settings ignored

[Andi C. S. <ski...@ya...>]

Hello,

> X server seems to report that Button6 (tilt left?) is always pressed. I think the attached patch will fix this problem. Please test it.

Thanks for the patch. I've tested it and it did fix the problem. It actually was the mouse wheel (mine is broken). From time to time it behaves erratically, randomly sending signals to the effect that it has been turned (although it hasn't), which triggered the buggy behaviour in mlterm. Most of the time it apparently didn't do anything (not even work) so I didn't suspect it. Time to buy a new mouse then :)

Regards,
Andi Șerbănescu

Re: [Mlterm-dev-en] Broken behaviour with some key combinations!

[Mohammad_Alsaleh <ms...@to...>]

On Fri, May 17, 2013 at 08:29:39PM +0900, Araki Ken wrote:
>  Hi,
> 
> From: Mohammad_Alsaleh <ms...@to...>
> Subject: Re: [Mlterm-dev-en] Broken behaviour with some key combinations!
> Date: Thu, 16 May 2013 14:20:27 +0300
> Message-ID: <1Uc...@in...>
> 
> msal> 1] tmux # start tmux session
> msal> 2] C-b+" # split pane
> msal> 3] C-b+Up # select top pane
> msal> 4] C-b+C-Up # should resize pane
> msal> 
> msal> Step 4 fails with mlterm here.
> 
>  Thanks.
> 
>  It seems that terminfo kUP5 etc entries don't match the sequences mlterm outputs.
>  Will you show me the output of "infocmp -x" command on mlterm ?

Attached.

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

Re: [Mlterm-dev-en] Broken behaviour with some key combinations!

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

 Hi,

From: Mohammad_Alsaleh <ms...@to...>
Subject: Re: [Mlterm-dev-en] Broken behaviour with some key combinations!
Date: Thu, 16 May 2013 14:20:27 +0300
Message-ID: <1Uc...@in...>

msal> 1] tmux # start tmux session
msal> 2] C-b+" # split pane
msal> 3] C-b+Up # select top pane
msal> 4] C-b+C-Up # should resize pane
msal> 
msal> Step 4 fails with mlterm here.

 Thanks.

 It seems that terminfo kUP5 etc entries don't match the sequences mlterm outputs.
 Will you show me the output of "infocmp -x" command on mlterm ?
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] "key" file settings ignored

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

 Hi,

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: Re: [Mlterm-dev-en] "key" file settings ignored
Date: Thu, 16 May 2013 11:44:20 -0700 (PDT)
Message-ID: <136...@we...>

> I've applied the new patch and ran mlterm and here's what I got. Key 
> definitions just seem not to work most of the time (sometimes they do, 
> but I can't figure out exactly when).

 Thanks.

 X server seems to report that Button6 (tilt left?) is always pressed.
 I think the attached patch will fix this problem.
 Please test it.

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

Re: [Mlterm-dev-en] "key" file settings ignored

[Andi C. S. <ski...@ya...>]

Hello,


> Please apply the attached patch to hg head source codes and send me
> ~/.mlterm/msg.log again.
> This patch logs to ~/.mlterm/msg.log in more detail.

I've applied the new patch and ran mlterm and here's what I got. Key 
definitions just seem not to work most of the time (sometimes they do, 
but I can't figure out exactly when).

> BTW, let me check to be sure, but did you execute 'make clean' and './configure'
> before building mlterm ?

Not exactly, but I built it from a gentoo ebuild, which normally compiles from a clean tree (and I did double-check just to make sure).

Regards,
Andi Șerbănescu

Re: [Mlterm-dev-en] Broken behaviour with some key combinations!

[Mohammad_Alsaleh <ms...@to...>]

On Thu, May 16, 2013 at 06:57:29AM +0900, Araki Ken wrote:
>  Hi,
> 
> From: Mohammad_Alsaleh <ms...@to...>
> Subject: Re: [Mlterm-dev-en] Broken behaviour with some key combinations!
> Date: Wed, 15 May 2013 23:52:30 +0300
> Message-ID: <1Uc...@in...>
> 
> msal> Yes. I discovered the bug while using tmux. But then I carried my tests
> msal> outside tmux to make sure it's not at fault.
> msal> 
> msal> Only mlterm prints those symbols. Other terminal emulators don't print
> msal> anything. So, I'm assuming they're parsing the escape sequences
> msal> correctly. Only with Shift+Arrow_Key something is printed. But only a letter
> msal> (no ;2).
> 
>  It is normal behavior for terminal emulators to print such escape
> seqneuce by the key combinations.
>  (http://mlterm.sf.net/alt-arrowkey.png shows what xterm 278, rxvt 2.6.4,
> gnome-terminal 3.6.0 and mlterm 3.1.9 post/2013-05-15 output by Alt-Arrow keys)
> 
>  But if you can't assign the key combinations to tmux functions, I suspect
> there is a bug.
>  So please tell me how you assign these keys in ~/.tmuxrc to reproduce
> this problem.
>  When I tested tmux 1.8 with "bind-key -n M-up next" on mlterm / Ubuntu 12.10,
> it worked fine.
> 
>  Regards,

Here is a simple sequence without needing ~/.tmux.conf

1] tmux # start tmux session
2] C-b+" # split pane
3] C-b+Up # select top pane
4] C-b+C-Up # should resize pane

Step 4 fails with mlterm here.

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

Re: [Mlterm-dev-en] Broken behaviour with some key combinations!

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

 Hi,

From: Mohammad_Alsaleh <ms...@to...>
Subject: Re: [Mlterm-dev-en] Broken behaviour with some key combinations!
Date: Wed, 15 May 2013 23:52:30 +0300
Message-ID: <1Uc...@in...>

msal> Yes. I discovered the bug while using tmux. But then I carried my tests
msal> outside tmux to make sure it's not at fault.
msal> 
msal> Only mlterm prints those symbols. Other terminal emulators don't print
msal> anything. So, I'm assuming they're parsing the escape sequences
msal> correctly. Only with Shift+Arrow_Key something is printed. But only a letter
msal> (no ;2).

 It is normal behavior for terminal emulators to print such escape
seqneuce by the key combinations.
 (http://mlterm.sf.net/alt-arrowkey.png shows what xterm 278, rxvt 2.6.4,
gnome-terminal 3.6.0 and mlterm 3.1.9 post/2013-05-15 output by Alt-Arrow keys)

 But if you can't assign the key combinations to tmux functions, I suspect
there is a bug.
 So please tell me how you assign these keys in ~/.tmuxrc to reproduce
this problem.
 When I tested tmux 1.8 with "bind-key -n M-up next" on mlterm / Ubuntu 12.10,
it worked fine.

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

Re: [Mlterm-dev-en] Broken behaviour with some key combinations!

[Mohammad_Alsaleh <ms...@to...>]

On Wed, May 15, 2013 at 09:20:30PM +0900, Araki Ken wrote:
>  Hi,
> 
> From: Mohammad_Alsaleh <ms...@to...>
> Subject: [Mlterm-dev-en] Broken behaviour with some key combinations!
> Date: Mon, 13 May 2013 02:03:54 +0300
> Message-ID: <1Ub...@in...>
> 
> > Last month, some key combinations' behaviour broke in my system.
> > Instead of executing assigned functionality (or doing nothing).
> > Weird escape sequences started to be printed instead.
> > 
> > ALT+Arrow_Key ;3A ;3B ;3C ;3D
> > Shift+Arrow_Key ;2A ;2B ;2C ;2D
> > Ctrl+Arrow_key ;5A ;5B ;5C ;5D
> >
> > * (A --> Up, B --> Down, C --> Right, D --> Left)
> >
> > I strongly suspected that an update to my system caused this.
> > 
> > To test my theory, I compiled older mlterm (minor) releases and they
> > all showed the same behaviour. The latest release itself (3.1.9) was
> > working just fine before this bug appeared.
> > 
> > Still, mlterm must be doing something wrong (or different) as it's
> > the only terminal emulator affected.
> 
>  I'm sorry but I still have no idea about the cause of this problem.
> 
>  Mlterm (and xterm) output these escape sequences ("^[[1;3A" etc)
> by default if combination keys doesn't match shortcut keys specified in
> ~/.mlterm/key.
> 

This happens with default configurations.

>  Do you mean that you assign these keys to the functions of some console
> applications like tmux and screen ?

Yes. I discovered the bug while using tmux. But then I carried my tests
outside tmux to make sure it's not at fault.

Only mlterm prints those symbols. Other terminal emulators don't print
anything. So, I'm assuming they're parsing the escape sequences
correctly. Only with Shift+Arrow_Key something is printed. But only a letter
(no ;2).

>  If so, which version do you use and how do you assign these keys ?
> 

I use latest tmux 1.8. This happens with default tmux (no user
configuration). I rolled back to 1.7 while testing and the result was
the same.

As I said, I had the same version of mlterm working before. So, I'm
suspecting some update in my system triggered the bug.

Many major components were updated to their latest version at the time
including glibc 3.17, GCC 4.8, glib2 2.36.x, gtk3 3.8.x among others.

Re: [Mlterm-dev-en] Broken behaviour with some key combinations!

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

 Hi,

From: Mohammad_Alsaleh <ms...@to...>
Subject: [Mlterm-dev-en] Broken behaviour with some key combinations!
Date: Mon, 13 May 2013 02:03:54 +0300
Message-ID: <1Ub...@in...>

> Last month, some key combinations' behaviour broke in my system.
> Instead of executing assigned functionality (or doing nothing).
> Weird escape sequences started to be printed instead.
> 
> ALT+Arrow_Key ;3A ;3B ;3C ;3D
> Shift+Arrow_Key ;2A ;2B ;2C ;2D
> Ctrl+Arrow_key ;5A ;5B ;5C ;5D
>
> * (A --> Up, B --> Down, C --> Right, D --> Left)
>
> I strongly suspected that an update to my system caused this.
> 
> To test my theory, I compiled older mlterm (minor) releases and they
> all showed the same behaviour. The latest release itself (3.1.9) was
> working just fine before this bug appeared.
> 
> Still, mlterm must be doing something wrong (or different) as it's
> the only terminal emulator affected.

 I'm sorry but I still have no idea about the cause of this problem.

 Mlterm (and xterm) output these escape sequences ("^[[1;3A" etc)
by default if combination keys doesn't match shortcut keys specified in
~/.mlterm/key.

 Do you mean that you assign these keys to the functions of some console
applications like tmux and screen ?
 If so, which version do you use and how do you assign these keys ?

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

[Mlterm-dev-en] Broken behaviour with some key combinations!

[Mohammad_Alsaleh <ms...@to...>]

Hello.

Last month, some key combinations' behaviour broke in my system.
Instead of executing assigned functionality (or doing nothing).
Weird escape sequences started to be printed instead.

ALT+Arrow_Key ;3A ;3B ;3C ;3D
Shift+Arrow_Key ;2A ;2B ;2C ;2D
Ctrl+Arrow_key ;5A ;5B ;5C ;5D

* (A --> Up, B --> Down, C --> Right, D --> Left)

I strongly suspected that an update to my system caused this.

To test my theory, I compiled older mlterm (minor) releases and they
all showed the same behaviour. The latest release itself (3.1.9) was
working just fine before this bug appeared.

Still, mlterm must be doing something wrong (or different) as it's
the only terminal emulator affected.

I hope someone familiar with the issue or knows what might be going on
will give us his/her feedback.

Thank you in advance.

GNU/Linux x86_64 (Arch Linux)

Re: [Mlterm-dev-en] Urgency hints on beep

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

 Hi,

From: Raghav Krishnapriyan <ra...@oc...>
Subject: Re: [Mlterm-dev-en] Urgency hints on beep
Date: Sun, 21 Apr 2013 16:29:42 -0700
Message-ID: <20130421232942.GA307@montmorency>

> > I'm sorry but mlterm-3.1.9 or before doesn't support it.
> >
> > I pushed the changes for supporting XUrgencyHint to hg head.
> > (http://bitbucket.org/arakiken/mlterm)
> 
> Thanks so much for adding this! It's really useful for 
> implementing notifications. If I could push my luck, would it be 
> possible to set the urgency hint even when the bell mode is set 
> to "none" rather than visual or sound? With IRC clients and 
> other applications it seems useful to simply use the bell as a 
> way of providing notifications while turning off the beep or 
> visual bell.

 Thanks for your suggestion. I fixed.
 Please test hg head.

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

Re: [Mlterm-dev-en] Urgency hints on beep

[Raghav K. <ra...@oc...>]

Hello,

On Fri, Apr 19, 2013, at 10:00:49 pm +0900, Araki Ken wrote:
>> Is it possible in mlterm to set the WM_URGENT hint on beep, 
>> as
>> xterm and urxvt allow you to do? This allows console-based
>> applications to trigger notifications in X, which is useful for
>> mail and chat programs.
>
> I'm sorry but mlterm-3.1.9 or before doesn't support it.
>
> I pushed the changes for supporting XUrgencyHint to hg head.
> (http://bitbucket.org/arakiken/mlterm)

Thanks so much for adding this! It's really useful for 
implementing notifications. If I could push my luck, would it be 
possible to set the urgency hint even when the bell mode is set 
to "none" rather than visual or sound? With IRC clients and 
other applications it seems useful to simply use the bell as a 
way of providing notifications while turning off the beep or 
visual bell.

Thanks again,

Raghav

Re: [Mlterm-dev-en] Urgency hints on beep

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

 Hi,

From: Raghav Krishnapriyan <ra...@oc...>
Subject: [Mlterm-dev-en] Urgency hints on beep
Date: Tue, 16 Apr 2013 19:05:37 -0700
Message-ID: <20130417020537.GC5509@montmorency>

> Is it possible in mlterm to set the WM_URGENT hint on beep, as 
> xterm and urxvt allow you to do? This allows console-based 
> applications to trigger notifications in X, which is useful for 
> mail and chat programs.

 I'm sorry but mlterm-3.1.9 or before doesn't support it.

 I pushed the changes for supporting XUrgencyHint to hg head.
 (http://bitbucket.org/arakiken/mlterm)

 Add "use_urgent_bell = true" to ~/.mlterm/main to enable XUrgencyHint
on beep.

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

Re: [Mlterm-dev-en] Compose key

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

 Hi,

From: Raghav Krishnapriyan <ra...@oc...>
Subject: [Mlterm-dev-en] Compose key
Date: Tue, 16 Apr 2013 18:59:39 -0700
Message-ID: <20130417015825.GA5509@montmorency>

> Is there support in mlterm for inputting characters using the 
> Compose Key?  I see some references to the Compose in some older 
> SuSE changelogs (e.g.  
> http://osdir.com/ml/linux.suse.m17n/2003-01/msg00015.html) but 
> (at least with the default settings) the Compose key seems to 
> have no effect.

 The simplest way to input characters using the compose key on mlterm
is to enable xim.

 Will you try to start mlterm with "-i -M xim" options after setting
locale variables correctly.

 In my environment, I can input them by following steps.

$ unset XMODIFIERS
$ export LANG=en_US.UTF8 LC_CTYPE=en_US.UTF8
$ mlterm -i -M xim

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

[Mlterm-dev-en] Compose key

[Raghav K. <ra...@oc...>]

Hello,

Is there support in mlterm for inputting characters using the 
Compose Key?  I see some references to the Compose in some older 
SuSE changelogs (e.g.  
http://osdir.com/ml/linux.suse.m17n/2003-01/msg00015.html) but 
(at least with the default settings) the Compose key seems to 
have no effect.

Thanks,

Raghav

[Mlterm-dev-en] Urgency hints on beep

[Raghav K. <ra...@oc...>]

Hello,

Is it possible in mlterm to set the WM_URGENT hint on beep, as 
xterm and urxvt allow you to do? This allows console-based 
applications to trigger notifications in X, which is useful for 
mail and chat programs.

Thanks,

Raghav

Re: [Mlterm-dev-en] "key" file settings ignored

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

 Hi,

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: Re: [Mlterm-dev-en] "key" file settings ignored
Date: Tue, 9 Apr 2013 07:12:33 -0700 (PDT)
Message-ID: <136...@we...>

> I have applied the patch. Sometimes mlterm followed the key assignments (at least partially; those with Control or Alt seemed not to work) and sometimes it didn't. I don't know what triggered those behaviours, though.
> 
> Right now it seems to be working partially (with the exception of Alt) and I have attached one log.

 The state of XKeyEvent seems to be correct according to the log file.
 I have no idea about the cause of this problem.

 Please apply the attached patch to hg head source codes and send me
~/.mlterm/msg.log again.
 This patch logs to ~/.mlterm/msg.log in more detail.

 BTW, let me check to be sure, but did you execute 'make clean' and './configure'
before building mlterm ?

> I have also noticed that compiling with --disable-kbd fails:
> 
> x_im.c:353:1: error: conflicting types for ‘x_im_new’
> x_im.h:125:11: note: previous declaration of ‘x_im_new’ was here

 Thanks. I fixed.
---
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] "key" file settings ignored

[Andi C. S. <ski...@ya...>]

Hello,

I have applied the patch. Sometimes mlterm followed the key assignments (at least partially; those with Control or Alt seemed not to work) and sometimes it didn't. I don't know what triggered those behaviours, though.

Right now it seems to be working partially (with the exception of Alt) and I have attached one log. I have also noticed that compiling with --disable-kbd fails:

x_im.c:353:1: error: conflicting types for ‘x_im_new’
x_im.h:125:11: note: previous declaration of ‘x_im_new’ was here

By the way, thank you for the box-drawing option.

Regards,
Andi Șerbănescu

Re: [Mlterm-dev-en] "key" file settings ignored

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

 Hi,

From: Araki Ken <ara...@us...>
Subject: Re: [Mlterm-dev-en] "key" file settings ignored
Date: Sun, 07 Apr 2013 21:16:28 +0900 (JST)
Message-ID: <201...@us...>

> > P.S. Is there any way to force mlterm to use the box-drawing characters provided by the font (including xft fonts)? Currently, it seems one can only force it to use the built-in ones.
> 
>  There is no way now.
>  Is it necessary ?

 I added a new option to force mlterm to use the box-drawing characters of the unicode font.

(~/.mlterm/main)
box_drawing_font = unicode # force the unicode font.
box_drawing_font = decsp   # force the DEC special font.

 You can specify this option by "--boxdraw unicode" or "--boxdraw decsp"
from the command line.

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

Re: [Mlterm-dev-en] what features do m17-lib provide to mlterm?

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

 Hi,

From: Rophy YL Tsai <ts...@tw...>
Subject: [Mlterm-dev-en] what features do m17-lib provide to mlterm?
Date: Sat, 6 Apr 2013 20:41:34 +0800
Message-ID: <OF3...@tw...>

> Is there any info on what features I will get if I add m17-lib to mlterm?
> I was able to find some discussions about fribidi - mlterm, but couldn't 
> find anything about m17n-lib.

 If you configure (and build) mlterm with --enable-m17nlib option and
start it with --im m17nlib option, you can input characters by the input
method provided by m17nlib.

 On the other hand, mlterm didn't depends on m17nlib to display m17n text.

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

Re: [Mlterm-dev-en] "key" file settings ignored

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

 Hi,

From: Andi Cristian Serbanescu <ski...@ya...>
Subject: [Mlterm-dev-en] "key" file settings ignored
Date: Sun, 31 Mar 2013 08:56:29 -0700 (PDT)
Message-ID: <136...@we...>

> A recent change appears to have affected the key file: right now (latest development version) mlterm seems to ignore it completely, whether it's the one in /etc/mlterm/ or the one in ~/.mlterm/, and regardless of the options specified within (mainly string-redefinitions in my case). Could you please look into this? (I didn't modify anything; the same configuration used to work until recently.)

 Will you try the attached patch ?
 Then please send me ~/.mlterm/msg.log.

> Also, according to the README file, --disable-image disables pseudo-transparency, but testing reveals the contrary. Is it meant to be this way? If not (i.e. pseudo-transparency disabled), then the options for brightness, contrast, gamma etc. could also be removed (just as SSH options are not recognized if mlterm is built without), since they won't be required by anything in that case.

 Thanks.
 I removed --contrast,--gamma,--bright and --pic options if configure is
executed with --disable-image option.

> P.S. Is there any way to force mlterm to use the box-drawing characters provided by the font (including xft fonts)? Currently, it seems one can only force it to use the built-in ones.

 There is no way now.
 Is it necessary ?

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

[Mlterm-dev-en] what features do m17-lib provide to mlterm?

[Rophy YL T. <ts...@tw...>]

Hi all,

Is there any info on what features I will get if I add m17-lib to mlterm?
I was able to find some discussions about fribidi - mlterm, but couldn't 
find anything about m17n-lib.

Rophy Tsai

[Mlterm-dev-en] "key" file settings ignored

[Andi C. S. <ski...@ya...>]

Hello,

A recent change appears to have affected the key file: right now (latest development version) mlterm seems to ignore it completely, whether it's the one in /etc/mlterm/ or the one in ~/.mlterm/, and regardless of the options specified within (mainly string-redefinitions in my case). Could you please look into this? (I didn't modify anything; the same configuration used to work until recently.)

Also, according to the README file, --disable-image disables pseudo-transparency, but testing reveals the contrary. Is it meant to be this way? If not (i.e. pseudo-transparency disabled), then the options for brightness, contrast, gamma etc. could also be removed (just as SSH options are not recognized if mlterm is built without), since they won't be required by anything in that case.

Regards,
Andi Șerbănescu

P.S. Is there any way to force mlterm to use the box-drawing characters provided by the font (including xft fonts)? Currently, it seems one can only force it to use the built-in ones.

[Mlterm-dev-en] mlterm 3.1.9 released

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

 This is to announce the release of mlterm version 3.1.9
  
http://sourceforge.net/projects/mlterm/files/01release/mlterm-3.1.9/mlterm-3.1.9.tar.gz/download

MD5 (mlterm-3.1.9.tar.gz) = 0130117ff329b10d3d7db82fb07845b1
SHA1 (mlterm-3.1.9.tar.gz) = 96762a10735b61fb5787f2df808b97b6341d3486

Overview of changes from 3.1.8
===============================
ver 3.1.9
* Remove --enable-sixel option from configure, and add --disable-image option.
  That is, support sixel graphics by default unless configure with
  --disable-image option. (w3m-remoteimg (https://bitbucket.org/arakiken/w3m/downloads)
  which doesn't depend on sixel graphics but on OSC 5379 show_picture also works
  on mlterm by default.)
* Separate SSH client functions to a dynamically loaded module (libptyssh)
  in platforms except win32.
* Treat key strings of "main" configuration file case-insensitively.
  (Both encoding=utf8 and ENCODING=utf8 are available.)
* Assign -M and -P options as the short options of --im and --clip.
* Add "allow_change_shortcut" (--shortcut) option which enables "set_shortcut"
  command of configuration protocol.
* Bug fixes:
  Fix the conflict of DCS(0x90) and the first byte of SJIS, GBK and so on.
  Fix the bug which disabled input and output of pty when configuration program
  such as mlconfig is started.
  Encode input character masked with 0x80 to the character encoding of pty
  if the value of mod_meta_mode option is 8bit. (Thanks to Vladimir Elisseev)
  Fix the bug which disabled Alt+symbol and Control+@ in win32.
  Fix the bug which disabled some shortcut key settings.
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-en] How to get "Alt+." key combination working

[Vlad <vo...@vo...>]

Thanks for a quick replay! In the mean time I've found that the
"mod_meta_mode = esc" indeed solves the problem (before I had
"mod_meta_mode = utf8"). As I understood, this issue is more generic and
if you're enable something like "eightBitInput" "Alt" key will not work
in xterm as well. From another side, I really don"t know what is the
right settings of the "mod_meta_mode" option for me (I'm using Western
European and Cyrillic languages only).


Regards,
Vlad.

On 12/03/13 22:11, Araki Ken wrote:
>  Hi,
>
> From: Vladimir <vo...@vo...>
> Subject: [Mlterm-dev-en] How to get "Alt+." key combination working
> Date: Tue, 12 Mar 2013 11:10:24 +0100
> Message-ID: <513...@vo...>
>
>> I'd appreciate if anybody would give any tips on how to get Alt+. key
>> sequence working (at the moment mlterm doesn't output anything).
>> mlterm version: 3.1.8
>> distro: Gentoo
>  Thanks for your report.
>  Alt+. outputs 0xae (REGISTERED SIGN) by defaults, but it didn't
> work in UTF-8 encoding.
>  The attached patch fixes this problem.
>
>  On the other hand, if you want Alt+. to output "\x1b\x2e" (ESC + .),
> please specify "mod_meta_mode" option in ~/.mlterm/main as follows.
>
> ~/.mlterm/main
> mod_meta_mode = esc
>
>  Regards,
> ---
> Araki Ken
> ara...@us...