Re: Mouse stopped working in MC

[Thomas Dickey]

- Original Message -
| From: "Frank McCormick" 
| To: "Thomas Dickey" 
| Cc: mc@gnome.org
| Sent: Sunday, February 2, 2020 4:09:26 PM
| Subject: Re: Mouse stopped working in MC

| On 2/2/20 1:24 PM, Thomas Dickey wrote:
|> On Sun, Feb 02, 2020 at 09:08:33AM -0500, Frank McCormick wrote:
|>>
|>>
|>> On 2/2/20 6:04 AM, Yury V. Zaytsev wrote:
|>>> I would be careful about assigning blame with xterm maintainer also
|>>> reading this list ;-) Maybe we are doing something that gets xterm
|>>> confused... do you have a way of consistenly reproducing the problem?
|>>>
|>>> On Sun, 2 Feb 2020, Adam Pribyl wrote:
|>>>
|>>>> Is it reproducible? This happens from time to time, but is not mc
|>>>> fault but xterm. It shoul help to reset the term with "reset"
|>>>> command.
|>>>>
|>>>> On Sat, 1 Feb 2020, Frank McCormick wrote:
|>>>>
|>>>>>   I am running Debian Sid fully updated. My mouse has stopped
|>>>>>   working in MC. Instead I get key codes on the MC command line.
|>>>>>   I normally run MC in an xterm.
|>>>>>
|>>>>>   How do I go about resolving this.
|>>>
|>>
|>> On my machine, if I go into /usr/bin and run xterm directly, THEN run mc (or
|>> mc -x) the mouse works properly. However
|>> if I pass any parameters to xterm, such as -g 150x40 -e mc
|>> then the mouse stops working and I get keycodes on the
|>> mc command line.
|>>
|>> I should note that I get into /usr/bin by running this small
|>> script.
|>>
|>> cd ~
|>> xterm -g 153x40+150+20 -fn 10x20
|> 
|> That could be this bug:
|> 
|> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495435
|> 
|> e.g., if xterm is confused about the screensize due to this
|> race (which is hard to fix due to the interaction between
|> X11, Xt libraries and the window manager -- there's _always_
|> a delay).
|> 
|> As a workaround, just typing "resize" should fix that.
|> 
|> If you happen to see the problem again, it's worth a moment to verify.
|> 
|> fwiw, I do this:
|> 
|>  resize -s 40 80
|> 
|> to get a 40x80 screen (works _all_ the time :-)
|> 
| 
|   After further experimentation I discovered the problem only arises
| when I use the -e parameter to xterm to run MC directly.
| When I do that i.e. xterm -e mc , the mouse doesn't work. Right now I am
| working around that by using urxvt and avoiding xterm
| entirely when I need to use the -e parameter. I have also tried
| the wrappers uxterm and lxterm and both render the mouse inoperable when
| I use the -e parameter.
| I still am not sure what the problem  is...why would urxvt not
| suffer from it ?

with "-e", you just get the command you asked for, no login-shell.

rxvt and others may imitate xterm, but sometimes get the details a little off.

You might be able to see the difference using strace

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: Mouse stopped working in MC

[Thomas Dickey]

On Sun, Feb 02, 2020 at 09:08:33AM -0500, Frank McCormick wrote:
> 
> 
> On 2/2/20 6:04 AM, Yury V. Zaytsev wrote:
> > I would be careful about assigning blame with xterm maintainer also
> > reading this list ;-) Maybe we are doing something that gets xterm
> > confused... do you have a way of consistenly reproducing the problem?
> > 
> > On Sun, 2 Feb 2020, Adam Pribyl wrote:
> > 
> > > Is it reproducible? This happens from time to time, but is not mc
> > > fault but xterm. It shoul help to reset the term with "reset"
> > > command.
> > > 
> > > On Sat, 1 Feb 2020, Frank McCormick wrote:
> > > 
> > > >  I am running Debian Sid fully updated. My mouse has stopped
> > > >  working in MC. Instead I get key codes on the MC command line.
> > > >  I normally run MC in an xterm.
> > > > 
> > > >  How do I go about resolving this.
> > 
> 
> On my machine, if I go into /usr/bin and run xterm directly, THEN run mc (or
> mc -x) the mouse works properly. However
> if I pass any parameters to xterm, such as -g 150x40 -e mc
> then the mouse stops working and I get keycodes on the
> mc command line.
> 
> I should note that I get into /usr/bin by running this small
> script.
> 
> cd ~
> xterm -g 153x40+150+20 -fn 10x20

That could be this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495435

e.g., if xterm is confused about the screensize due to this
race (which is hard to fix due to the interaction between
X11, Xt libraries and the window manager -- there's _always_
a delay).

As a workaround, just typing "resize" should fix that.

If you happen to see the problem again, it's worth a moment to verify.

fwiw, I do this:

resize -s 40 80

to get a 40x80 screen (works _all_ the time :-)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: use of graphics characters recently disabled in xterm

[Thomas Dickey]

On Mon, Sep 11, 2017 at 11:03:23AM -0500, Theodore Kilgore wrote:
> 
> Thomas,
> 
> The output of locale (invoked without arguments) is as follows,
> between the two lines.
> 
> 
> kilgota@khayyam:/etc/X11/app-defaults$ locale |less
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE=C
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=
> ---

Those settings should work (the important ones are LC_ALL and LC_CTYPE, LANG).
 
> There is a line called "line-drawing characters" which is *not*
> turned on. It is unclear to me what this does (see the xterm man
> page for an explanation, which is not totally clear). What it might
> be doing is turning on the line-drawing characters from X itself, to
> replace the ones which are provided by the font, or alternatively
> what it might be doing is enabling the line-drawing characters which
> are already provided by the font. As I said, the explanation in the
> man page is not very clear and these two meanings are obviously
> opposite to each other. In any event, to toggle this setting on and
> off all by itself, when other settings are not changed, seems to
> have no effect.
> 
> There are also lines in that menu for UTF-8 Encoding, UTF-8 Fonts,
> and UTF-8 Titles. These are also apparently not turned on (no check
> marks in front).
> 
> Setting UTF-Encoding *and* UTF-8 Fonts *and* Line-Drawing Characters
> all to be on seems to solve the problem. But by default all three of
> them are turned off.
> 
> Why are all three of these settings turned off by default? I have no

Line-Drawing is normally turned off because a well-designed font will
look better than xterm's built-in equivalent (since it may use thick
lines for large characters).

UTF-8 Fonts would be turned on if you used the "uxterm" shell script
to setup xterm, which gives better coverage of Unicode.

UTF-8 Encoding isn't on either because there's some problem with the locale
_tables_ or due to a resource setting.  If you have "appres" installed,
you may see the problem in the output of "appres XTerm".

> idea. In particular, this is even more amazing because it seems to
> be in conflict with the locale settings displayed above. So, in
> order to get back to the bottom of this problem it seems to me that
> what needs to be done is to set up a way to turn all three of these
> settings on. However, I do not know what I am supposed to do in
> order to carry that out. Change some configuration file, I suppose,
> or else do a local override. But I suspect that the settings are
> already set correctly in some file somewhere and that somehow the
> settings in that file are being ignored.

I'd try using the "uxterm" script (it's supposed to do most of the
fixes you need).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: use of graphics characters recently disabled in xterm

[Thomas Dickey]

On Sun, Sep 10, 2017 at 01:58:38PM -0500, Theodore Kilgore wrote:
> 
> 
> On Sun, 10 Sep 2017, Thomas Dickey wrote:
> 
> >On Fri, Sep 08, 2017 at 05:57:33PM -0500, Theodore Kilgore wrote:
> >>
> >>I have recently done some upgrades, keeping current with
> >>slackware-64-current. And what has happened is that suddenly MC
> >>started to print funny characters around the panels instead of
> >
> >a screenshot would help:

In the screenshot, I see a single character, which is always the same value:
226 (octal 342).

That happens to be the first byte of the UTF-8 encoding for the various
line-drawing characters which is odd, since they are all 3-bytes:

\342\224\2140x250c  /* upper left corner */
\342\224\2240x2514  /* lower left corner */
\342\224\2200x2510  /* upper right corner */
\342\224\2300x2518  /* lower right corner */
\342\224\2340x251c  /* tee pointing left */
\342\224\2440x2524  /* tee pointing right */
\342\224\2640x2534  /* tee pointing up */
\342\224\2540x252c  /* tee pointing down */
\342\224\2000x2500  /* horizontal line */
\342\224\2020x2502  /* vertical line */
\342\224\2740x253c  /* large plus or crossover */

Those 22x's are mostly in the C1 control range (200 to 237 octal),
so it's possible that xterm is not using UTF-8 encoding, and simply
discarding the control characters (with an occasional glitch for
the tee's and plus signs).

> Attached.
> 
> >
> >+ If it's 2-3 characters rather than a single character, that indicates that
> > xterm's not using UTF-8 (a resource problem perhaps).  You would set in
> > the right-menu-mouse menu that "UTF-8 Encoding" is not checked.
> 
> This could be the problem, even though X is completely up to date
> and the file /etc/X11/app-defaults/XTerm does contain the following
> lines:
> 
> *fontMenu*utf8-mode*Label:  UTF-8 Encoding
> *fontMenu*utf8-fonts*Label: UTF-8 Fonts
> *fontMenu*utf8-title*Label: UTF-8 Titles
> 
> What is interesting about this is the following. Yesterday evening I
> did some experimenting. The xterm man page contains the following
> options
> 
> 
>-lc Turn on support of various encodings according to the
> users'
>locale setting, i.e., LC_ALL, LC_CTYPE, or LANG environment
>variables.  This is achieved by turning on UTF-8 mode
> and by
>invoking luit for conversion between locale encodings and
>UTF-8.  (luit is not invoked in UTF-8 locales.)  This
>corresponds to the locale resource.
> 
>The actual list of encodings which are supported is
> determined
>by luit.  Consult the luit manual page for further details.
> 
>See also the discussion of the -u8 option which
> supports UTF-8
>locales.
> 
>+lc Turn off support of automatic selection of locale
> encodings.
>Conventional 8bit mode or, in UTF-8 locales or with
> -u8 option,
>UTF-8 mode will be used.
> 
> 
> Both of the above options restore MC to sane behavior.

That's saying that turning the switch on or off has the same effect :-(
 
> Aksi there is the -u8 option.
> 
>-u8 This option sets the utf8 resource.  When utf8 is
> set, xterm
>interprets incoming data as UTF-8.  This sets the wideChars
>resource as a side-effect, but the UTF-8 mode set by this
>option prevents it from being turned off.  If you must turn
>UTF-8 encoding on and off, use the -wc option or the
>corresponding wideChars resource, rather than the -u8
> option.
> 
>This option and the utf8 resource are overridden by
> the -lc and
>-en options and locale resource.  That is, if xterm
> has been
>compiled to support luit, and the locale resource is not
>false this option is ignored.  We recommend using the -lc
>option or the locale: true resource in UTF-8 locales when
>your operating system supports locale, or -en UTF-8
> option or
>the locale: UTF-8 resource when your operating system does
>not support locale.
> 
> The option xterm -en UTF-8 works, too, as it is supposed to. I also
> tried I tested each one of the above options by opening an xterm and
> then typing the command. When I hit "enter" it created a new window
> beside the old one, and then opened MC in the new window.
> 
> The option xterm -en UTF-8 works, too, as it is supposed to. I 

Re: use of graphics characters recently disabled in xterm

[Thomas Dickey]

On Fri, Sep 08, 2017 at 05:57:33PM -0500, Theodore Kilgore wrote:
> 
> I have recently done some upgrades, keeping current with
> slackware-64-current. And what has happened is that suddenly MC
> started to print funny characters around the panels instead of

a screenshot would help:

+ If it's 2-3 characters rather than a single character, that indicates that
  xterm's not using UTF-8 (a resource problem perhaps).  You would set in
  the right-menu-mouse menu that "UTF-8 Encoding" is not checked.

+ If it's a single character, then that could be a problem with the video
  driver (or fontconfig, etc).  For this, you could try using xterm's
  built-in line-drawing using the "Line-Drawing Characters" menu option.

> printing vertical and horizontal lines. This happens only in an
> xterm, not in the console terminal where all remains OK. The command
> mc -a replaces the straight lines with vertical and horizontal
> dashes, but that does not look nearly so nice.

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: Pseudographics in text mode

[Thomas Dickey]

On Wed, 15 Jun 2011, Anton Shepelev wrote:


Hello all,

I  am having problems setting up mc to display pseu-
dographics characters in a text-mode virtual  termi-
nal. Only the default skin, which does not contain
double  lines,  works  well.  It  is  very   strange
because, if I 'cat' those skin files all the graphi-
cal symbols are shown correctly, so I wonder why  MC
does not see them...


MC (and ncurses/slang) is paying attention to locale, while cat is not.
It's possible to have a terminal setup to handle UTF-8 encoding without
requiring that the locale seen by programs inside it matches.



My console is in UTF-8 mode and the TERM variable is
set to linux.

Thanks in advance,
Anton
___
mc mailing list
http://mail.gnome.org/mailman/listinfo/mc



--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Missing frame

[Thomas Dickey]

On Fri, 20 May 2011, Yury V. Zaytsev wrote:


On Thu, 2011-05-19 at 13:38 -0400, Frank McCormick wrote:


For the mc problem...I ended up dl'ing the latest mc source
compiling and installing it. The Debian Sid version is REALLY old and
I had been using my own compiled version.


I remember someone to complain about that and I think it was related to
a particular slang version. You might have better luck rebuilding with
ncurses then.


for example, the problem might be that it's using a non-UTF-8-aware 
version of slang on Linux console when that's setup for UTF-8 encoding.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: keystrokes change according to runlevel

[Thomas Dickey]

On Fri, 20 May 2011, Jan Engelhardt wrote:


On Wednesday 2011-05-18 17:19, Felix Miata wrote:


Could some dev look at
https://bugzilla.novell.com/show_bug.cgi?id=400552 and either suggest
that's really a bug that should be filed in the mc tracker, or comment
there as to how to find a solution, or even propose one there?


Linux VT: (key - produces - interpreted as .. by terminfo)
Shift-F1 - ^[[25~ - kf13
Shift-F2 - ^[[26~ - kf14
Shift-F3 - ^[[28~ - kf15
Shift-F4 - ^[[29~ - kf16
Shift-F5 - ^[[31~ - kf17
Shift-F6 - ^[[32~ - kf18

Xterm:
Shift-F1 - ^[[1;2P - kf13
Shift-F2 - ^[[1;2Q - kf14
Shift-F3 - ^[[1;2R - kf15
Shift-F4 - ^[[1;2S - kf16
Shift-F5 - ^[[15;2~ - kf17
Shift-F6 - ^[[17;2~ - kf18


the xterm definitions are all extended capabilities...


So the terminfo db looks ok, so is this perhaps a slang problem?


slang doesn't use the extended key definitions in terminfo;
it uses only the conventional 2-character names in termcap.

so yes, that is a slang problem.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc from minicom

[Thomas Dickey]

On Sun, 28 Nov 2010, Kevin Wilson wrote:


Hi,
 I am trying to use mc on a machine to which I am connected via minicom
(serial  connection).
MC opens ok, but the keys are not functioning well.


minicom acts as a terminal emulator - sort of like a vt100, with color
(and odd line-drawing).  That probably means it doesn't have function
keys - vt100's don't have home/end, etc.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc from minicom

[Thomas Dickey]

On Mon, 29 Nov 2010, Eric Gillespie wrote:


On 29 November 2010 07:53, Thomas Dickey dic...@his.com wrote:


On Sun, 28 Nov 2010, Kevin Wilson wrote:

 Hi,

 I am trying to use mc on a machine to which I am connected via minicom
(serial  connection).
MC opens ok, but the keys are not functioning well.



minicom acts as a terminal emulator - sort of like a vt100, with color
(and odd line-drawing).  That probably means it doesn't have function
keys - vt100's don't have home/end, etc.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

...

If you can, try this: export TERM=vt220; then start mc. That probably has
support for more keys. I'm not entirely sure of that.


well... looking at the source for version 2.4, in src/wkeys.c it does
have some limited ability to match keys from the terminal description.
But it's limited.  Here are the (termcap) names it looks for:

static const char *func_key[] = {
  , k1, k2, k3, k4, k5, k6, k7, k8, k9, k0,
  kh, kP, ku, kl, kr, kd, kH, kN, kI, kD,
  F1, F2, NULL };

That is (more/less) function-keys 1-10, cursor-keys and the 
editing-keypad.  The names would be documented in terminfo(5).


But it's limited: it doesn't really know about application-mode.

(minicom was originally designed to just use the Linux terminal 
description, modify it a little to make it act like a vt100, and has 
probably a number of assumptions about that, still embedded in the code).


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Editing with mc

[Thomas Dickey]

On Sun, 29 Aug 2010, Helmut Hullen wrote:


Hallo, Jobst,

Du meintest am 29.08.10 zum Thema Re: Editing with mc:


1) I don't know a short cut key to get to the beginning or to the
end of a file I'm editing, what am I missing?




CTRL-Home will move you to the top of the file you are editing.
CTRL-End ditto end of file.



That's what I'm expecting, but the cursor moves only to the beginning
or the end of the line!


Same unexpected behaviour here;
mc-20100509_git (Slackware-current)


which terminal emulator are you using?

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Editing with mc

[Thomas Dickey]

On Sun, 29 Aug 2010, Helmut Hullen wrote:


Hallo, Keith,

ke...@karsites.net meinte am 29.08.10 in mc zum Thema Re: Editing with mc:


1) I don't know a short cut key to get to the beginning or to
the end of a file I'm editing, what am I missing?



CTRL-Home will move you to the top of the file you are editing.
CTRL-End ditto end of file.



That's what I'm expecting, but the cursor moves only to the
beginning or the end of the line!


[...]


   echo $TERM

tells xterm (running the machine via putty).

Maybe that's the reason. When I go to the real keyboard (and not via
putty) then echo $TERM tells linux, and Ctrl-end works as
described. With old and new versions of mc.



I use konsole terminal emulator part of KDE, under XFCE.


[...]


Ctrl keys work OK on konsole.


Under putty most (nearly all) ctrl keys work. Only ctrl end and
ctrl home seem to resist.


I would expect the individual control keys to work.  However, control
as a modifier to function keys appears to have no effect with putty.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Alt+function keys and other keys

[Thomas Dickey]

On Fri, Mar 12, 2010 at 02:14:37PM +0100, Miguel Pérez wrote:
 2010/3/12 Thomas Dickey dic...@his.com
 
  On Fri, 12 Mar 2010, Miguel Pérez wrote:
 
   It does, but they are not recognized. Here's an example of different
  alt-f1
  sequences I've seen:
 
  Konsole (TERM=konsole), native keyboard (xterm XFree 4.x.x): ^[O3P
  xterm (TERM=xterm): ^[[1;3P
  urxvt (TERM=rxvt-unicode): ^[^[[11~
  mlterm (TERM=mlterm): ^[[11;3~
 
  Midnight Commander doesn't recognize any of these. I wonder what kind of
  terminal does it expect (shouldn't it be flexibly detected from TERM?).
 
 
  terminfo should provide the details (using the convention from xterm,
   which encodes 12 function-keys with control-, shift-, alt-modifiers).
 
 
  The last I noticed, Konsole doesn't _set_ $TERM, but has a keyboard setting
  (analogous to the predefined flavors in xterm for Sun, HP, etc).
 
 
 Then something seems to be wrong, because I have TERM properly set in the
 various terminals, yet Midnight Commander doesn't seem to understand many of
 the posible escape sequences (mostly Alt/Control combinations with
 Fn/Ins/Del/Home/End and Shift+Tab).

Midnight Commander could be modified to use ncurses' extended terminal
descriptions.  Here's some detail on that:

http://invisible-island.net/ncurses/ncurses.faq.html#modified_keys

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Alt+function keys and other keys

[Thomas Dickey]

On Fri, 12 Mar 2010, Miguel P??rez wrote:


It does, but they are not recognized. Here's an example of different alt-f1
sequences I've seen:

Konsole (TERM=konsole), native keyboard (xterm XFree 4.x.x): ^[O3P
xterm (TERM=xterm): ^[[1;3P
urxvt (TERM=rxvt-unicode): ^[^[[11~
mlterm (TERM=mlterm): ^[[11;3~

Midnight Commander doesn't recognize any of these. I wonder what kind of
terminal does it expect (shouldn't it be flexibly detected from TERM?).


terminfo should provide the details (using the convention from xterm,
which encodes 12 function-keys with control-, shift-, alt-modifiers).

The last I noticed, Konsole doesn't _set_ $TERM, but has a keyboard 
setting (analogous to the predefined flavors in xterm for Sun, HP, etc).




~Miguel


2010/3/11 Thomas Dickey dic...@his.com


On Thu, 11 Mar 2010, Miguel P??rez wrote:

 What I wonder is why even on the reference terminal xterm, some key escape

sequences aren't even recognized, including simple enough ones such as
ctrl-f1 or alt-f1.



It depends on the keyboard configuration.  (The vt220 flavor won't do
much with control/F1).  The (default) Sun/PC does send different
sequences...

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net





--
Antes de imprimir este correo electr??nico, considera tu responsabilidad
medioambiental.

Please consider your environmental responsibility before printing this
email.



--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Alt+function keys and other keys

[Thomas Dickey]

On Thu, 11 Mar 2010, Miguel P??rez wrote:


What I wonder is why even on the reference terminal xterm, some key escape
sequences aren't even recognized, including simple enough ones such as
ctrl-f1 or alt-f1.


It depends on the keyboard configuration.  (The vt220 flavor won't do 
much with control/F1).  The (default) Sun/PC does send different 
sequences...


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Some keys are not properly recognized in Konsole/xterm

[Thomas Dickey]

On Thu, 11 Feb 2010, frank wrote:

The bug reports also demonstrate that they don't really understand the 
issue, and have made a few changes to make it more complicated.  (I'm not 
expecting anything productive from upstream unless a new developer takes 
over ;-)


Upstream of upstream something productive could come from the xterm 
maintainer. For instance, friendly features in xterm.


If you have not asked yourself yet why Gnome Terminal and Konsole and others 
are around, this could be the right time.


Give xterm the friendliness users are longing for and all those imitations 
will just disappear.


hmm - transparent backgrounds for people who aren't typing or reading.

etc.

awai

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Some keys are not properly recognized in Konsole/xterm

[Thomas Dickey]

On Thu, 11 Feb 2010, Thomas Dickey wrote:


On Fri, 12 Feb 2010, Oswald Buddenhagen wrote:

and maybe you find something inspiring in
http://www.midnight-commander.org/ticket/24 ;)


yes, I noticed some related reports in either Redhat or Gentoo, which add 
to my to-do list...


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Some keys are not properly recognized in Konsole/xterm

[Thomas Dickey]

On Fri, 12 Feb 2010, Oswald Buddenhagen wrote:


do in any graphical mail reader), i have to:
1) find out that i can do that at all. the man page doesn't contain the
term URL once.
2) write a regexp matching urls


See the bottom of the app-defaults file.


3) have some process which leads from a selection to opening a browser.
klipper to the rescue! yay! even more regexps!


Most people would remember how to use the paste operation (ymmv)


right. that's why all graphical muas lack that feature ... ;)


hmm - no all.  Perhaps all of the ones in front of you at the moment.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Some keys are not properly recognized in Konsole/xterm

[Thomas Dickey]

On Mon, 1 Feb 2010, Miguel P??rez wrote:


I love the ability to customize keybindings in 4.7. However, I've noticed
some keys cannot be bound because they aren't recognized properly by
Midnight Commander. When you hit an unrecognized sequence, mc will simply
skip the escape sequence up to a point and print the rest of it.

I'm using Konsole, set to the xterm (XFree 4.x.x) keyboard, and $TERM is
xterm. These are the key combinations that produce escape sequences but
aren't recognized by mc. Everything else either works, or doesn't produce a


konsole doesn't send escape sequences that match xterm.
Use infocmp konsole xterm to see this.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Some keys are not properly recognized in Konsole/xterm

[Thomas Dickey]

On Mon, 1 Feb 2010, Thomas Dickey wrote:


On Mon, 1 Feb 2010, Miguel P??rez wrote:


I love the ability to customize keybindings in 4.7. However, I've noticed
some keys cannot be bound because they aren't recognized properly by
Midnight Commander. When you hit an unrecognized sequence, mc will simply
skip the escape sequence up to a point and print the rest of it.

I'm using Konsole, set to the xterm (XFree 4.x.x) keyboard, and $TERM is
xterm. These are the key combinations that produce escape sequences but
aren't recognized by mc. Everything else either works, or doesn't produce a


konsole doesn't send escape sequences that match xterm.
Use infocmp konsole xterm to see this.


...of course that's assuming that mc relies on the terminal description
(I seem to recall some discussion where it's using separate configuration
information).

Assuming that it's actually using the terminal description, e.g., from 
ncurses, then mismatches would be due to (a) not using TERM=konsole, and 
(b) futher mismatches might be due to differences between the current 
konsole application and the ncurses description.


A quick check (using tack and TERM=konsole for konsole 2.3.2) shows no 
issues.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Glitches with MC on slackware 13.0

[Thomas Dickey]

On Tue, 19 Jan 2010, Stan. S. Krupoderov wrote:


  InputBackwardDelete = backspace; ctrl-h
  ;; backspace works, still no ctrl-h
  InputBackwardDelete = ctrl-h
  ;; :( no back delete at all


It works for me without any additional bindings in mc.keymap.
Did you try it in another terminal emulator?
(For me: konsole and urxv-unicode works properly, xterm - fail).
If you sure this is not terminal issue feel free to report
bug in mc.


It sounds like a configuration problem (but there's not enough 
information).


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: alternative key-binding to C-Shift-Enter for use in xterms?

[Thomas Dickey]

On Wed, 16 Dec 2009, MK wrote:

xterm lacks configurability in this sense, but you should be able to set 
console to allow anything, even if it means rearranging some key combos 
taken by it or KDE (since mc keys are not configurable).


actually, you can make xterm send something distinct for 
control/shift/enter, though it may be difficult to configure mc to use the 
feature effectively.


Anyway, I just use ctrl-x p (not ctlr-x ctrl-p) to get the fullpath for 
the current panel directory and then alt-enter for the filename.


--
MK halfcountp...@intergate.com
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc



--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: ncurses or slang

[Thomas Dickey]

On Wed, 23 Sep 2009, Slava Zanko wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michail Vidiassov wrote:

Dear All,

what is the preferred screen output library in the
upcoming mc 4.7 and current pre2?
I.e. if one can install both ncurses and slang2 on his system
what mc is to be compiled against, what branch is developed and tested
more active, where are bugs fewer and features more abundant?


Preferred to S-Lang (as default), but Ncurses fully supported too.

With NCurses we have some restrictions (like trouble with drawing of
double lines for boxes). S-Lang is a more powerfull library.


not really (just lack of developers for MC that happen to know both 
libraries)


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: ncurses or slang

[Thomas Dickey]

On Thu, 24 Sep 2009, Slava Zanko wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

24.09.2009 00:37, Thomas Dickey wrote:

Thomas, hi. Glad to see you in this maillist.


Preferred to S-Lang (as default), but Ncurses fully supported too.

With NCurses we have some restrictions (like trouble with drawing of
double lines for boxes). S-Lang is a more powerfull library.

not really (just lack of developers for MC that happen to know both
libraries)


Well... Drawing double lines possible in NCurses via tty_print_string()
function (not via hline() vline() and etc). In this case we (side of mc)
must take care of user encoding, terminal type and used current font. If
we use hline or vline functions (like now) then this headache of NCurses.

Now Midnight Commander (from git) have initial support of skins.
Possible to change drawing of lines via skin-file. With Ncurses library
we used vline, hline and ACS_* constants, therefore double lines not
drawing, but lines look good with any codepage of user. With S-Lang
library we used anoter way (in opposite): draw lines directly via
SLsmg_write_char. As result: we have any UTF-8 lines but we have trouble
in one-byte codepages ('LANG=C mc' or 'LANG=POSIX mc' show this trouble
as well).


All that sounds just like you're using slang's equivalent of add_wch() or 
addch(), which you can already do with ncurses.  (Either way, the solution 
depends on locale and terminal support ;-)


The one-byte codepages providing double-lines aren't available in POSIX 
locale.  ncurses has a use_legacy_coding() function to tell it that the 
display can show characters which the locale says aren't printable (though 
mixing that with a UTF-8 locale may not give good results).


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: missing line drawing in latest freebsd port

[Thomas Dickey]

On Tue, 1 Sep 2009, Viktor Štujber wrote:


Just wanted to inform that I resolved the missing line drawing issue
by coincidence.

The environment variable LANG needs to be set to en_US.UTF-8 (or
similar) to make it work. Despite a bunch of other things that were
already set to utf-8, this one was missing.


sounds good (I'd assume that LANG or LC_CTYPE would be needed).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Bold/bright colors don't work as background.

[Thomas Dickey]

On Wed, 1 Apr 2009, Josh Rickmar wrote:


On Wed, 1 Apr 2009, Andrew Borodin wrote:
OK, thanks for the reply.  I was expecting it to work with mc because I
am able to use bold colors as backgrounds in other applications like Alpine, 
for example.  I switched to a s-lang build to see if it would change 
anything, but it didn't.


alpine (perhaps you mean pico) sort-of uses the terminfo database,
but has a lot of hardcoded stuff in it.  But it's not able to do
anything to the terminal that ncurses or s-lang couldn't also do.
It may be labeling things differently however.

(not as bad as pine was - I recall reading its terminal code,
about 30,000 lines in one file ;-)


Oh well, good to know it's not a Midnight Commander bug at least.



___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc



--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Alt-o in xterm

[Thomas Dickey]

On Mon, 12 Jan 2009, Russell Shaw wrote:


Hi,
In an xterm, i could press alt-o to get both panels the same.

Now after a few X windows upgrades, alt-o gives an I with
two dots above it (0xEF, LATIN SMALL LETTER I WITH DIAERESIS)
UTF-8 locale i guess. On the linux console it gives ESC-o (0x1b6f)

How can i get mc to work in a utf-8 X setup?


man xterm (see eightBitInput, metaSendsEscape, altSendsEscape)

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: missing line drawing in latest freebsd port

[Thomas Dickey]

On Fri, 12 Dec 2008, Viktor ??tujber wrote:


The exact procedure on freebsd is to set these two options:
[ ] UTF8Build with UTF8 support
[ ] SLANGBuild with SLang library

Then, according to the following chunk of the makefile,
..if defined(WITH_UTF8)
LIB_DEPENDS+=   slang.2:${PORTSDIR}/devel/libslang2
CONFIGURE_ARGS+=--with-screen-slang
CONFIGURE_ENV+= LDFLAGS=-L${PREFIX}/lib
..elif !defined(WITH_SLANG)  (defined(WITHOUT_SLANG) || defined(MINIMAL))
CONFIGURE_ARGS+=--with-screen=ncurses
..else
CONFIGURE_ARGS+=--with-screen=mcslang
..endif


FreeBSD has ncursesw also - does mc have a configure-check for that?

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: missing line drawing in latest freebsd port

[Thomas Dickey]

On Thu, 11 Dec 2008, Viktor Štujber wrote:


Just wanted to add that as soon as I disable the '[x] build with SLang
library' option, the issue goes away. I would really like to debug the
problem myself but I don't have any suitable unix dev environment to
do so (plus it's very hard to do any GUI debugging when the project
only uses makefiles).


what does it build with in that case?



On Thu, Dec 4, 2008 at 22:29, Viktor Štujber theultram...@gmail.com wrote:

Hello again. Has there been any progress with identifying the cause of
this issue and how to resolve it?
Both me (using PuTTY) and a friend (using ) only see blank spaces
where line drawing chars are supposed to be. This affects panels,
dropdown menus and popup boxes. Mode -a only covers the panels and
doesn't look as good as the original. I tried googling for an answer
but the few hits didn't help solve the problem.


On Sat, May 17, 2008 at 7:46 PM, Viktor Štujber theultram...@gmail.com wrote:

Greetings. I come with an issue that has appeared circa 4 weeks ago,
when the freebsd ports 'mc' makefile was extended with UTF-8 support.

http://www.freebsd.org/cgi/cvsweb.cgi/ports/misc/mc/Makefile.diff?r1=1.113;r2=1.114;f=h

This modified the mc dependencies, which now require libslang2. But
when using this library, the lines around the navigation panels no
longer appear, instead there are only blank spaces. This makes mc
harder to use.

I asked some bsd people about this, and got a suggestion to remove the
dependency and instead use the previous libslang version. This seems
to work, but the ┤character is not displayed properly. Also this
change might produce undefined behavior since it's untested.

Therefore I'd like to ask for advice from the professionals here.




___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc



--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Issues with recent utf8 patch

[Thomas Dickey]

On Thu, 22 Nov 2007, Rafa?~B Mu??y?~Bo wrote:


It seems that the problem comes from the way ncurses move() works. If I
understand it correctly, if move range is outside (0..screen  width) /
(0..screen height) it moves to the previous/next column/line. When I changed


If the move is outside the screen, wmove() returns an error and does not 
move at all...



terminal size to 80x20, I got some really silly results when I've gone
up and down File menu several times. Slang variant at least paints it
correctly, though if menu is longer than the term, you can select an
option you don't see. Of course, I don't now pretty much anything about
ncurses, but some bounds checking (no move() outside screen) might help.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel



--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: colors

[Thomas Dickey]

On Wed, 22 Aug 2007, Pavel Tsekov wrote:

  Original-Nachricht 
 Datum: Tue, 21 Aug 2007 10:17:30 -0700 (PDT)
 Von: Justin Zygmont
 An: Keith Roberts
 CC: mc@gnome.org
 Betreff: Re: colors

 It seemed, typing mc -c did the trick.  In solaris the $TERM was already
 xterm, but some things are still different.

 On solaris the xterm terminfo entry does not support color. I think 
 the xtermc entry was the one which should be used if color support is 
 desired.

no - see the end of this item:

http://invisible-island.net/xterm/xterm.faq.html#xterm_terminfo

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Bold colors

[Thomas Dickey]

On Fri, 20 Apr 2007, Pavel Tsekov wrote:

 On Wed, 18 Apr 2007, Anton Monroe wrote:

 On Wed, Apr 18, 2007 at 07:36:30PM +0200, Caj Zell wrote:
 I have a slight problem with my midnight commander look. I like the fonts 
 when
 I disable color, mc -b, but running mc with colors makes the fonts look too
 bold for me. I realize this is probably not a mc issue, but maybe someone
 could give me hints in the right direction on how to change this anyhow?

 The actual font of the characters is beyond MC's control; it uses
 whatever font the terminal provides. But I think you are talking about

 That is not true. MC can turn on/off certain attributes of the screen -
 one of the being the bold attribute. The terminal would draw characters
 with the bold font instead of the normal one. Currently MC draws certain
 parts of the screen with the bold attribute turned on and this is not
 user configurable. A workaround would be to set the bold font of your
 terminal to a normal font  if it is possible.

If MC is built with ncurses, there is yet another place to adjust things:
ncurses checks the ncv (no color video) setting and suppresses video
attributes which are marked in the terminfo as incompatible with colors.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Request for discussion - how to make MC unicode capable

[Thomas Dickey]

On Tue, 27 Feb 2007, Pavel Roskin wrote:

 On Sat, 2007-02-24 at 14:57 +0200, Pavel Tsekov wrote:

 In case of Unicode, the new concept is distinction between bytes and
 characters.  Many functions need to be checked that they don't mix them.
 It's totally impractical to write a preprocessor conditional every time
 something is changed.  It's better to change to code for Unicode support
 and then think how to provide backward compatibility for the whole
 source tree with minimal changes throughout the code.

That's what I did with dialog: the largest change was to make editing
of a multibyte/multicolumn string work properly.  In doing that, I added
useful functions that could be reused to make forms line up, etc.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: xterm background colour

[Thomas Dickey]

On Thu, 25 Jan 2007, [EMAIL PROTECTED] wrote:

 Thomas Dickey [EMAIL PROTECTED] wrote:

 On Wed, 24 Jan 2007, [EMAIL PROTECTED] wrote:

 Midnight Commander changes xterm background colour to black on exit if run
 from it. I think it's a bug.

 There are two places to look: the choice of terminal description,
 and possibly a very old version of slang.  It's more likely the
 terminal description, e.g., using something like xterm-color,
 which is almost always incorrect.

 I've written unclearly a bit. XTerm background color doesn't actually 
 change. MC fills out on exit entire XTerm window by black solid blocks 
 except bottom line and prompt symbols. After running 'clear' colour of 
 all the symbols becomes normal.

If the screen is black after the prompt (and stays that way until 
cleared), then that's a problem with mc not reinitializing the colors to 
the default.  It could still be a mismatch of the terminal description
(not using the bce back-color erase capability), but can also be a bug 
in the code.  The latter is less likely.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: xterm background colour

[Thomas Dickey]

On Wed, 24 Jan 2007, [EMAIL PROTECTED] wrote:

 Midnight Commander changes xterm background colour to black on exit if run
 from it. I think it's a bug.

There are two places to look: the choice of terminal description,
and possibly a very old version of slang.  It's more likely the
terminal description, e.g., using something like xterm-color,
which is almost always incorrect.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc in xterm: mouse problem

[Thomas Dickey]

On Thu, 4 Jan 2007, Mattiassich ?kos wrote:


Hi,

I want to use mc-4.6.1 in the Konsole of KDE3.5. If I press a button on my
mouse it writes some characters into the command line:
$ #.8M ,8M#,8M-8M#-8M28M#28MB1M#B1M @[EMAIL PROTECTED] 24M#24
I tried it in xterm too, but it doesn't work also.
In a text console works everything fine.

Anybody have an idea what might be the problem?
Variable TERM=xterm.


There's a setting in mc's initialization file related to 8-bit characters.
Removing that will probably help.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: [PATCH] corrupted free inodes list

[Thomas Dickey]

On Fri, 22 Dec 2006, Leonard den Ottolander wrote:

 Hi Mikulas,

 On Wed, 2006-12-20 at 02:15 +0100, Mikulas Patocka wrote:
 --- maybe you could change double to long long but I'm not sure if it
 exists on all machines --- a configure test would probably be needed.

 Yes. Using floats for discrete counters is not such a good idea.

It's likely to be slower, but if you don't exceed the precision of the 
mantissa, you won't lose information.

The general reader, taking into account the comment about discrete is 
likely to assume that you meant information would be lost.  Since that's
not the case (for the assumed 48 bits), it's worth clarifying the comment.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Ctrl+Enter doesn\'t work in MC in xterm

[Thomas Dickey]

On Wed, 15 Nov 2006, dusan halicky wrote:

 Hi.

 If I run MC in XTERM in X.org, the Ctrl+Enter (copy current filename 
 from cursor to commandline) doesn\'t work. In text console this works 
 fine. I have Slackware 10.2. Instead of copy filename to clipboard, it 
 act like plain Enter. The result was the same on many different window 
 managers and also the same in rxvt. Any idea how to solve this? 
 Thanks...

While it's possible that Ctrl+Enter in Linux console may be using some
Linux-specific ioctl's, those would not work for portable applications
written for X.

You can use xterm's translations resource to modify this; the other
terminal emulators don't provide a comparable feature.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.

[Thomas Dickey]

On Wed, 1 Nov 2006, Pavel Tsekov wrote:

 On Wed, 1 Nov 2006, Thomas Dickey wrote:

 On Wed, 1 Nov 2006, Pavel Tsekov wrote:
 
 Yes, I read that comment. However I'm not prepared to start breaking the
 functionality of shells that I never use.
 
 This is a rather strange statement. As a developer you should try to
 go beyond your personal preferences. Changes to the subshell shall be
 tested with all supported shells and on as many platforms as possible.
 From Chet Ramey's statement it is clear that using printf is the right
 thing to do.
 
 That's his statement.  Jim Meyering's comment is more reasonable.

 His comment is related to coreutils and not bash. Anyway, he still
 agrees that printf should be used. If this is the way to go why
 shall we wait ?

He's recommending it for new scripts, not recommending that one rewrite 
existing scripts (and by noting that other shells retain the existing 
treatment, is pointing out a problem).

Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in 
existing scripts to bother with 3.2.x).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: [bug #18136] MC wont work with new bash-3.2 propeply with all directories.

[Thomas Dickey]

On Wed, 1 Nov 2006, Pavel Tsekov wrote:

 Ok. Since I am not native english speaker I cannot judge whether
 he is recommending it or not. In any case I can see why keeping
 the old behaviour of 'echo' is important for large scripts, however
 what we have in MC is nothing as big. I just feel that what Leonard
 is proposing is a hack and not an actual solution.

 Anyway - perhaps 3.3 (I'm seeing too many reports of syntax errors in 
 existing scripts to bother with 3.2.x).

 Does this mean that you think that bash 3.3 will reinstantiate the old 
 behaviour ?

Not for this (echo -e is a dead issue, though some of the discussion 
there touches on other problems). But it would be reasonable to expect it 
to fix the syntax errors.  Before rushing off to change things to 
accommodate bash 3.2, it's worth checking if the fix will work with other 
shells.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: Terminal answers

[Thomas Dickey]

On Thu, 28 Sep 2006, Wiseman wrote:

 I also noticed terminals (at least the ones I tried) use ^[ as Esc,
 and ^[xxx for all other non-printable keys. This has the very
 undesirable effect of making Esc a dead key (for which mc has a fix,
 but a delay of 1 second is far too much; I'd rather have 0 seconds).
 This also has the effect that Alt+letter is the same as Esc
 letter. Are there any terminals that will handle Esc differently, so
 that it becomes a real key you can just use normally?

not really (there were long ago some terminals that used other control
sequences without ESC, but there aren't many).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Terminal answers

[Thomas Dickey]

On Fri, 29 Sep 2006, Anton Monroe wrote:

 Hmm.  Something I've noticed in Ncurses-based apps is that blank areas
 don't erase text.  For example, in Pinfo, when I page down, some of the
 previous screen still shows in the blank areas.  It's probably a common
 problem with a simple explanation.  Some capability that needs to be
 set or unset in my terminfo entry?

Yes - that sounds as if you are using a terminal description with bce 
set, on a terminal which does not clear the background on an erase.

That reminds me that rxvt has a bug - one of the cases for erasure does 
not work - which I work around in ncurses by leaving out the bce.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Terminal answers

[Thomas Dickey]

On Wed, 27 Sep 2006, Anton Monroe wrote:

   3) You could try compiling MC with a different screen library. You
   have a choice of using the Slang library that comes with MC, or the
   version of Slang that is (probably) already on your computer, or the
   version of Ncurses that is (probably) already on your computer. Slang
   is reputedly better at dealing with broken terminfo entries than
   Ncurses, and MC uses Slang by default.  But I suppose Ncurses might
   be better in some circumstances.

That's because

a) slang used to supply hardcoded defaults to match rxvt if some
   information was missing (actually there were also some
   hardcoded defaults for a few other terminals, but rxvt was the
   target).  Most of that was removed early in the 1.4.x series.

b) slang doesn't use some capabilities that ncurses does (this
   is especially noticeable in the way it clears trailing blanks
   on a line).

   That was my situation. My SSH client for OS/2 claims to provide a
   substantial subset of the xterm-color terminal.  It doesn't say
   which version of xterm-color. I doubt if even the various Linux
   distributions all provide exactly the same terminfo files.  None of

that's true (I haven't found much use in the distributions' 
customizations)

 Some tips, in no particular order:

   The escape character is often represented by ^[, but Terminfo
   entries use \E and MC uses \e.

tic recognizes either case

   Each terminfo capability has a short name and a long name that is
   easier to understand.  Unfortunately, 'tack' and 'tput' only use the
   short forms.  Keep a list handy for reference.

I hadn't noticed that (to-do list...)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc under Eterm

[Thomas Dickey]

On Mon, 25 Sep 2006, Pavel Tsekov wrote:

 On Mon, 25 Sep 2006, Alessandro Magni wrote:
 Pity that no chars at all are printed for the graphic chars (yet they are
 present in the font I use,  -bh-luxi
 mono-medium-r-normal--0-0-0-0-m-0-iso10646-1),
 but at least mc is usable.

 This is because you are not using the right font. xterm-like terminals
 which do no support unicode - I guess Eterm is one of them - expect
 that the glyphs for the line drawing characters are found in cells 0-31.

yes/no: some terminals draw the lines directly:

modern xterm does (draws lines using X calls)

kterm draws into bitmaps which are then BLT'd to the display
(appears it did this before xterm, though I didn't notice)

MGT copied code from xterm to do this

gnome-terminal paraphrased the xterm code (no comment ;-)

The last I checked, konsole doesn't.  I seem to recall noticing one of the 
rxvt family doing this, though I agree it probably wasn't Eterm.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc-4.6.1-20060912.patch

[Thomas Dickey]

On Fri, 15 Sep 2006, Pavel Tsekov wrote:

 On Thu, 14 Sep 2006, Thomas Dickey wrote:

 The immediate cause of the problem is that (from some previous run of MC),
 the ini file says

  use_8th_bit_as_meta=1
 
 which makes MC change the KEY_RESIZE (0x199) to 0x19.

 I see it now - that's definetely a bug in MC. Thanks for tracking it down! 
 The attached patch should fix it. I'll
 apply it if you confirm that it fixes the problem for
 you.

That fixed the problem.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc-4.6.1-20060912.patch

[Thomas Dickey]

On Tue, 19 Sep 2006, Pavel Tsekov wrote:

 On Mon, 18 Sep 2006, Thomas Dickey wrote:

 On Fri, 15 Sep 2006, Pavel Tsekov wrote:
 
 On Thu, 14 Sep 2006, Thomas Dickey wrote:
 
 The immediate cause of the problem is that (from some previous run of 
 MC),
 the ini file says

use_8th_bit_as_meta=1
 
 which makes MC change the KEY_RESIZE (0x199) to 0x19.
 
 I see it now - that's definetely a bug in MC. Thanks for tracking it down! 
 The attached patch should fix it. I'll
 apply it if you confirm that it fixes the problem for
 you.
 
 That fixed the problem.

 Ok. I've just checked in the patch. Again, thanks for your time!

no problem

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc-4.6.1-20060912.patch

[Thomas Dickey]

On Fri, 15 Sep 2006, Pavel Tsekov wrote:

 On Thu, 14 Sep 2006, Thomas Dickey wrote:

 The immediate cause of the problem is that (from some previous run of MC),
 the ini file says

  use_8th_bit_as_meta=1
 
 which makes MC change the KEY_RESIZE (0x199) to 0x19.

 I see it now - that's definetely a bug in MC. Thanks for tracking it down!

no problem.  (I didn't go past that point last night since I spent most
of the time on lynx).

 The attached patch should fix it. I'll
 apply it if you confirm that it fixes the problem for
 you.

I'll test that this evening (thanks)

 I'd like to ask you to share you thoughts regarding the
 use of ncurses in MC in general. Like things that you
 don't like or think that can be implemented in a better
 way. Also if you have any information about reports of
 MC misbehaving when built with  ncurses support - please,
 let us know. I am also interested in getting MC to work
 with the widechar version of ncurses - if you could provide
 any references I'd be very grateful.

ok.  I can review it and (aside from offering suggestions on the configure 
script) perhaps offer some advice on the wide-character code.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc-4.6.1-20060912.patch

[Thomas Dickey]

On Thu, 14 Sep 2006, Pavel Tsekov wrote:

 configure --prefix=/tmp/FOO --without-gpm-mouse --with-screen=ncurses

 I've configured as you suggested above. The system is  FC5 with some missing 
 updates and MC comes from the latest snapshot tarball. I've
 stopped gpm so that it won't interfere.
...
 Mouse support does work - both buttons and the mouse wheel.

I'll check on this when I'm home this evening (have an FC5, just in case 
that is relevant, e.g., for locale).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc-4.6.1-20060912.patch

[Thomas Dickey]

On Wed, 13 Sep 2006, Pavel Tsekov wrote:

 On Tue, 12 Sep 2006, Thomas Dickey wrote:

 A fix for mc - attached.
 This patch makes MC use the mouse when built with ncurses.


 It already does. Would you elaborate why this is necessary ?

Perhaps it does in the CVS version (where can I see that?)

I was patching the 4.6.1 version, which does not.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc-4.6.1-20060912.patch

[Thomas Dickey]

On Wed, 13 Sep 2006, Pavel Tsekov wrote:

 On Wed, 13 Sep 2006, Thomas Dickey wrote:

 On Wed, 13 Sep 2006, Pavel Tsekov wrote:
 
 On Tue, 12 Sep 2006, Thomas Dickey wrote:
 
 A fix for mc - attached.
 This patch makes MC use the mouse when built with ncurses.
 
 
 It already does. Would you elaborate why this is necessary ?
 
 Perhaps it does in the CVS version (where can I see that?)
 
 I was patching the 4.6.1 version, which does not.

 If I am guessing right your patch is against the MC tarball from
 http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/.

no, I took a quick look for newer versions, but did not notice the 
snapshot (and did not see a cvsweb site, so I was not sure of the current
development status).  I used the 4.6.1 release which is 23 July 2005.

 That tarball should be based on the CVS state from yesterday - so
 it is pretty much the same as the CVS version. I am building
 MC with ncurses support for quite a while and I haven't seen
 problems with the mouse support.

perhaps you're using gpm.  I use it rarely since it generally interferes 
with X.

A quick check of the snapshot using my configuration shows the same bugs 
that I noticed in the release:

a) cursor keys are not handled properly using the slang
   configuration when running in screen.  (But see below).

b) there is no support for mouse using ncurses in xterm (or any
   other terminal supported by ncurses, of course).

I had noticed the mouse problem in 2002 when I sent a patch to Pavel 
Roskin, but had not found time then to fix it.  The problem is still the 
same.  Perhaps it would not be hard to resync my 4.6.1 patch against
your snapshot, but since the packagers I normally deal with are using 
4.6.1, that was where I started.

 Would you, please, exlpain the problem that you're seeing and the
 reasons behind your patch. Does it have something to do with
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369976 ?

not exactly.  Since I maintain ncurses, I deflect bug reports that are 
incorrectly citing ncurses.  I happened to think about MC this week since 
I noticed some comments via google on one of the newsgroups that indicated 
someone's cursor keys did not work in MC.  That might be the same issue
that I noted above.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc-4.6.1-20060912.patch

[Thomas Dickey]

On Thu, 14 Sep 2006, Pavel Tsekov wrote:

 On Thu, 14 Sep 2006, Thomas Dickey wrote:

 On Thu, 14 Sep 2006, Pavel Tsekov wrote:
 
 configure --prefix=/tmp/FOO --without-gpm-mouse --with-screen=ncurses
 
 I've configured as you suggested above. The system is  FC5 with some 
 missing updates and MC comes from the latest snapshot tarball. I've
 stopped gpm so that it won't interfere.
 ...
 Mouse support does work - both buttons and the mouse wheel.
 
 I'll check on this when I'm home this evening (have an FC5, just in case 
 that is relevant, e.g., for locale).

 Ok. I am pretty much willing to work with you to improve MC's ncurses support 
 not only regarding mouse support but in general. But I just cannot accept 
 bugreports without proof. I am sure that you see some kind of a
 problem - just let me know how to reproduce it.

I understand that.  At the moment I see that you are apparently having MC 
interpret escape sequences (since I do not see a mechanism for it reading 
the KEY_MOUSE data that ncurses would send if mousemask() were called).
That is not happening on my machine, but it is a starting point.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

mc-4.6.1-20060912.patch

[Thomas Dickey]

A fix for mc - attached.
This patch makes MC use the mouse when built with ncurses.

-- 
Thomas E. Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net
# 2006-09-12
# This patch makes MC use the mouse when built with ncurses.
# Thomas Dickey
# [EMAIL PROTECTED]
# --
# key.c|   81 ++---
# layout.c |8 ++
# 2 files changed, 86 insertions(+), 3 deletions(-)
# --
Index: src/key.c
--- mc-4.6.1+/src/key.c 2005-06-08 12:27:19.0 +
+++ mc-4.6.1-20060912/src/key.c 2006-09-12 20:40:11.0 +
@@ -488,6 +488,67 @@
 static int clicks;
 static int last_btn = 0;
 
+#if defined(USE_NCURSES)  defined(KEY_MOUSE)
+MEVENT event;
+int button;
+
+getmouse(event);
+ev-x = event.x + 1;
+ev-y = event.y + 1;
+ev-buttons = 0;
+ev-type = 0;
+
+btn = -1;
+for (button = 1; button = 3; ++button) {
+   if (BUTTON_RELEASE(event.bstate, button)) {
+   btn = 3;
+   break;
+   } else if (BUTTON_PRESS(event.bstate, button)) {
+   btn = button - 1;
+   break;
+   }
+}
+
+if (btn == 3){
+   if (last_btn) {
+   ev-type = GPM_UP | (GPM_SINGLE  clicks);
+   ev-buttons = 0;
+   last_btn = 0;
+   GET_TIME (tv1);
+   clicks = 0;
+   } else {
+   /* Bogus event, maybe mouse wheel */
+   ev-type = 0;
+   }
+} else {
+ev-type = GPM_DOWN;
+   GET_TIME (tv2);
+   if (tv1.tv_sec  (DIF_TIME (tv1,tv2)  double_click_speed)){
+   clicks++;
+   clicks %= 3;
+   } else
+   clicks = 0;
+   
+switch (btn) {
+   case 0:
+ev-buttons = GPM_B_LEFT;
+break;
+   case 1:
+ev-buttons = GPM_B_MIDDLE;
+break;
+   case 2:
+ev-buttons = GPM_B_RIGHT;
+break;
+   default:
+/* Nothing */
+   ev-type = 0;
+   ev-buttons = 0;
+break;
+}
+   last_btn = ev-buttons;
+}
+#else
+
 /* Decode Xterm mouse information to a GPM style event */
 
 /* Variable btn has following meaning: */
@@ -545,6 +606,7 @@
 /* Transform them to 1-based */
 ev-x = getch () - 32;
 ev-y = getch () - 32;
+#endif
 }
 
 static key_def *create_sequence (const char *seq, int code, int action)
@@ -756,9 +818,10 @@
 return (mod | c);
 }
 
-int get_key_code (int no_delay)
+int get_key_code (int arg_delay)
 {
 int c;
+int no_delay = (arg_delay  0);
 static key_def *this = NULL, *parent;
 static struct timeval esctime = { -1, -1 };
 static int lastnodelay = -1;
@@ -795,6 +858,17 @@
 if (c == KEY_RESIZE)
 goto nodelay_try_again;
 #endif
+#if defined(USE_NCURSES)  defined(KEY_MOUSE)
+if (c == KEY_MOUSE) {
+   if (arg_delay) {/* guess we're called from get_event() */
+   return c;
+   } else {
+   MEVENT event;
+   getmouse(event);
+   goto nodelay_try_again;
+   }
+}
+#endif
 if (no_delay) {
 nodelay (stdscr, FALSE);
 if (c == -1) {
@@ -961,7 +1035,7 @@
try_channels (0);
 
/* Try to get a character */
-   c = get_key_code (0);
+   c = get_key_code (-1);
if (c != -1)
break;
/* Failed - wait 0.1 secs and try again */
@@ -1176,8 +1250,9 @@
 
 keypad(stdscr, FALSE); /* disable intepreting keys by ncurses */
 c = getch ();
-while (c == -1)
+while (c == -1) {
 c = getch (); /* Sanity check, should be unnecessary */
+}
 learn_store_key (buffer, p, c);
 GET_TIME (endtime);
 endtime.tv_usec += LEARN_TIMEOUT;
Index: src/layout.c
--- mc-4.6.1+/src/layout.c  2005-05-27 14:19:18.0 +
+++ mc-4.6.1-20060912/src/layout.c  2006-09-12 21:20:49.0 +
@@ -598,6 +598,14 @@
 keypad (stdscr, TRUE);
 nodelay (stdscr, FALSE);
 init_colors ();
+#if defined(USE_NCURSES)  defined(KEY_MOUSE)
+mouseinterval(0);
+mousemask(
+   BUTTON1_RELEASED|   BUTTON1_PRESSED |
+   BUTTON2_RELEASED|   BUTTON2_PRESSED |
+   BUTTON3_RELEASED|   BUTTON3_PRESSED ,
+   (mmask_t *) 0);
+#endif
 if (force_ugly_line_drawing) {
for (i = 0; acs_approx[i].acscode != 0; i++) {
acs_map[acs_approx[i].acscode] = acs_approx[i].character;


signature.asc
Description: Digital signature
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: mc-4.6.1-20060912.patch

[Thomas Dickey]

On Thu, 14 Sep 2006, Pavel Tsekov wrote:

 On Wed, 13 Sep 2006, Thomas Dickey wrote:

 On Wed, 13 Sep 2006, Pavel Tsekov wrote:
 
 Do you mind to post a reference to that discussion so it can be verified ?
 
 Here's another (though I still don't see the particular one I had in mind)
 
 http://groups.google.com/group/linux.debian.bugs.dist/browse_frm/thread/a6ae02f59bed4d8f/66481938acc67375?lnk=stq=(ncurses+OR+xterm+OR+vttest+OR+cproto+OR+diffstat+OR+terminfo+OR+termcap)rnum=123hl=en#66481938acc67375

 By the way the following statements are quite incorrect:

 MC could be built with ncurses, but its maintainers have been not
 much interested in maintaining that configuration(*).

mouse doesn't work with ncurses, hasn't for more than four years.
I also noted with interest Pavel Roskin's comments four years ago
proposing to remove all of the ncurses support from MC (google isn't 
showing me the comment, or I'd provide a URL for your amusement).

I'm looking forward to see how much interested plays out...

 (*) equally, since MC for quite a while used gcc-specific code which would 
 not compile with an ANSI C compiler, I was uninterested in wasting much time 
 with it. 

yes - I encountered that (compound statement) sometime in the 90's, 
considering whether to provide a copy of it for my development group, 
found that it wouldn't compile, deleted it and resolved to not touch it 
until that was fixed. I revisited that more than once, and if you take 
the time to search on my newsgroup postings, you'll notice that I 
commented on this more than once.

When working on my patch this week, I grep'd for the compound statement,
didn't find it - and didn't find any mention of it in the changelog.
In any case, you would presumably agree that quite a while refers to
a span of years, which is accurate.

 I myself am using MC with ncurses most of the tmie. The Cygwin package
 for MC, which I maintain, is compiled against ncurses. I have spent
 considerable amount of time tracking bugs in MC to make it work
 correct with ncurses.

 I build MC on my Solaris 10 machine on a regular basis with Sun's
 compiler. I've also built MC on Tru64 with Compaq/HP's compiler.

You sound like a recent (post-2000) developer - not knowing the longterm 
history of the program.  My first encounter with it was on the order of 
ten years ago.  I don't use the tool, but recall email from Miguel asking
about my directory editor.

 You seem to try to spread misinformation regarding MC
 on every possible occasion as you did in the Debian bug
 tracking system.

hmm - it's your mailing list, but as usual, I'm reporting what I've 
observed.

Spreading misinformation is a nice way of calling someone a liar.
Don't be surprised if I regard you as poorly informed.

bye

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

mc-4.6.0-pre2

[Thomas Dickey]

perhaps you should add a --with-screen=ncursesw, to allow one to build
that configuration.  Would you like a patch?

-- 
Thomas E. Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc-4.5.99a

[Thomas Dickey]

On Wed, Feb 06, 2002 at 12:24:58AM -0500, Pavel Roskin wrote:
 Hi, Thomas!
 
 On Tue, 5 Feb 2002, Thomas Dickey wrote:
 
  One of the package porters noted that there were some bugs in mc (in the
  ncurses configuration) which do not appear in the previous stable version.
  Besides these fixes, I note that the mouse interface is broken (he was
  complaining about a problem with the editor which I haven't seen yet).
  
  The attached patch fixes resizing (perhaps I'll come back to this after lynx).
 
 I don't quite understand the situation.  Is it your patch or somebody

mine (I didn't see the contact address in the readme, so I looked in the
changelog to see who would be a good contact).

 elses?  I don't want to credit wrong people.  The patch seems to be good,
 but since there is no detailed comment, I must spent more time checking
 it.

There was more than one problem with resize:

a) the missing $ncurses_version caused resizeterm to not be found.

b) checking a report that mc didn't use the whole screen when setting
   xterm font to Unreadable, I noticed that mc died when I made the
   screen very large.  That was a buffer-overflow problem when the
   screen width was wider than 1024. (screen.c)

c) while debugging for the former bug, I tried using gdb with
   ElectricFence.  But that didn't work.  The problem was that
   mc's sigwinch handler was calling resizeterm, which performs
   malloc's, etc., which essentially hung the process.  That was
   probably leftover from my first patch in 1997 or 1998.  So
   I ifdef'd out the (unnecessary) call.  (layout.c)

d) before that (c took some work ;-), I found that mc was treating
   the resize event as a SIGTSTP.  That was fixed by the ifdef in
   key.c
 
 Please use the mailing list [EMAIL PROTECTED] next time.
 
 Lost ncurses_version is indeed a problem, but I've applied a more 
 elaborate fix.  I've applied all other patches as well.
 
 Thank you!

no problem.  When is the next version to be completed?  (So I know to come
back and fix the mouse, if needed, before then).

-- 
Thomas E. Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel