Re: [PATCH] vim_is_xterm() and screen

[Bram Moolenaar]

Micah Cowan wrote:

  
  Sorry for the repost; but I realized I should've drawn more attention  to
  the message with the patch in it, both so other lurkers know the threa d
  now includes a proposed patch, and so that we know what message to go
  back to if we want to refer to the code we're discussing.
 
  I have made a slight adjustment to the patch, swapping the order of
  STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using
  vim_is_xterm() instead of term_is_xterm at first, but afterwards
  replaced it for efficiency, but left the order as it was.
  
  Looks OK to me.
 
 Terrific! Does that mean it'll go in? :)

Probably, but not right now.

  If I understood your other message correctly then using xterm2 for
  'ttymouse' would not work for screen.
 
 Well... manually setting it to xterm2 will work fine (assuming screen
 is running under a supporting version of xterm): I get the full dragging
 effect, etc. But screen doesn't do t_RV, and I don't know how else you'd
 determine support for xterm2, so there doesn't seem to be a safe way
 to set ttymouse to it automatically, for screen.
 
 Towards a better solution: how straightforward do you think it'll be to
 talk the ncurses guys into adding support for some of screen's
 extensions? AFAIK, the only one I care about is the xterm mouse support;
 another interesting one is a boolean supports ansi
 setforeground/setbackground codes; but I usually infer this (if
 necessary) from the presence of setaf/setbf (not a given, but...).

I think you need to talk to more people than ncurses for changing the
termcap/terminfo entries.  But it's a good start.

- Bram

-- 
From know your smileys:
 :-FBucktoothed vampire with one tooth missing

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

xterm-mouse and terminfo [Re: [PATCH] vim_is_xterm() and screen]

[Micah Cowan]

Bram Moolenaar wrote:
 Micah Cowan wrote:
 Towards a better solution: how straightforward do you think it'll be to
 talk the ncurses guys into adding support for some of screen's
 extensions? AFAIK, the only one I care about is the xterm mouse support;
 another interesting one is a boolean supports ansi
 setforeground/setbackground codes; but I usually infer this (if
 necessary) from the presence of setaf/setbf (not a given, but...).
 
 I think you need to talk to more people than ncurses for changing the
 termcap/terminfo entries.  But it's a good start.

Well, I'll need to talk to ncurses to get the extensions added; after
that, I'll have to get the various terminal emulators, and any other
suppliers for terminfo descriptions, to actually /specify/ the
extensions; then, it'll take a good while for the various applications
(such as vim) to actually check for its presence.

Is that what you're referring to? :)

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature

Re: vim_is_xterm() and screen

[Micah Cowan]

I wrote:
 Therefore, there would seem to be no harm whatsoever in detecting screen
 as an xterm-mouse-code-capable terminal, and sending the mouse-mode
 sequence (xterm protocol, since AFAIK screen provides no way to detect
 the underlying xterm version). If the underlying terminal claims to be
 xterm or rxvt, then the user will automatically get the benefit of mouse
 support without trouble; otherwise, screen will simply ignore the
 sequence and no harm is done to other terminals (such as unrecognized
 sequence-emitters, or DEC-mouse-only terminals).

Attached is a proposed patch that effects the change I'm requesting. I
would love to get some feedback/further discussion based on it. They say
code talks, and so here is my concrete expression. :)

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Index: os_unix.c
===
--- os_unix.c	(revision 276)
+++ os_unix.c	(working copy)
@@ -2034,6 +2034,21 @@
 		|| STRCMP(name, builtin_xterm) == 0);
 }
 
+/*
+ * Return TRUE if name appears to be that of a terminal
+ * known to support the xterm-style mouse protocol.
+ * Relies on term_is_xterm having been set to its correct value.
+ */
+int
+vim_uses_xterm_mouse(name)
+char_u *name;
+{
+if (name == NULL)
+	return FALSE;
+return (STRNICMP(name, screen, 6) == 0
+		|| term_is_xterm);
+}
+
 #if defined(FEAT_MOUSE_TTY) || defined(PROTO)
 /*
  * Return non-zero when using an xterm mouse, according to 'ttymouse'.
Index: term.c
===
--- term.c	(revision 276)
+++ term.c	(working copy)
@@ -1601,6 +1601,9 @@
 int		try;
 int		termcap_cleared = FALSE;
 #endif
+#if defined(UNIX) || defined(VMS)
+int		term_uses_xterm_mouse;
+#endif
 int		width = 0, height = 0;
 char_u	*error_msg = NULL;
 char_u	*bs_p, *del_p;
@@ -1903,6 +1906,7 @@
 
 #if defined(UNIX) || defined(VMS)
 term_is_xterm = vim_is_xterm(term);
+term_uses_xterm_mouse = vim_uses_xterm_mouse(term);
 #endif
 
 #ifdef FEAT_MOUSE
@@ -1923,7 +1927,7 @@
 #endif
 	clip_init(FALSE);
 #   endif
-	if (term_is_xterm)
+	if (term_uses_xterm_mouse)
 	{
 	if (use_xterm_mouse())
 		p = NULL;	/* keep existing value, might be xterm2 */


signature.asc
Description: OpenPGP digital signature

Re: vim_is_xterm() and screen

[A.J.Mechelynck]

Micah Cowan wrote:

I wrote:

Therefore, there would seem to be no harm whatsoever in detecting screen
as an xterm-mouse-code-capable terminal, and sending the mouse-mode
sequence (xterm protocol, since AFAIK screen provides no way to detect
the underlying xterm version). If the underlying terminal claims to be
xterm or rxvt, then the user will automatically get the benefit of mouse
support without trouble; otherwise, screen will simply ignore the
sequence and no harm is done to other terminals (such as unrecognized
sequence-emitters, or DEC-mouse-only terminals).


Attached is a proposed patch that effects the change I'm requesting. I
would love to get some feedback/further discussion based on it. They say
code talks, and so here is my concrete expression. :)




Shouldn't it rather use the 'ttymouse' option? IIUC, that option is supposed 
to be set to either xterm or xterm2 at startup if the terminal is known to 
support xterm mouse codes. This is done as a result of sending the t_RV code 
and receiving an answer for it, which happens after the first file has been 
loaded and all -c commands have been processed: probably just before or just 
after the VimEnter event. IOW, you cannot test them in your vimrc or even in a 
global plugin (they are sourced too early). At the VimEnter event might be 
late enough but I haven't tested it.



Best regards,
Tony.
--
A billion here, a couple of billion there -- first thing you know it
adds up to be real money.
-- Senator Everett McKinley Dirksen

Re: vim_is_xterm() and screen

[Micah Cowan]

A.J.Mechelynck wrote:
 Micah Cowan wrote:
 Attached is a proposed patch that effects the change I'm requesting. I
 would love to get some feedback/further discussion based on it. They say
 code talks, and so here is my concrete expression. :)
 
 Shouldn't it rather use the 'ttymouse' option?

It does. :)   ...or rather, my code is what would be used to set
ttymouse's default based on the detected terminal.

 IIUC, that option is
 supposed to be set to either xterm or xterm2 at startup if the
 terminal is known to support xterm mouse codes.

My code is used at the spot where the value of the 'ttymouse' option is
set automatically by setting the 'term' option: both at startup, and
whenever the user sets it manually via :set term=.

 This is done as a result
 of sending the t_RV code and receiving an answer for it, which happens
 after the first file has been loaded and all -c commands have been
 processed: probably just before or just after the VimEnter event. IOW,
 you cannot test them in your vimrc or even in a global plugin (they are
 sourced too early). At the VimEnter event might be late enough but I
 haven't tested it

What happens, to the best of my reading, is:

1. If the terminal is detected as supporting t_RV (which basically means
that it has been detected as fully compatible), it issues that sequence
and checks for a result. If it gets an expected response, it will set
ttymouse appropriately.

2. Sometime later, but before the first file is loaded, etc, the term
option is automatically set based on the TERM environment variable.
   The term option is a magic option which causes it to check a bunch
of things, including whether xterm mouse support is enabled (at the
point where I set the term_uses_xterm_mouse var).

3. If the tty is xterm-mouse capable (before patch, if it is a full
xterm implementation), then it sets ttymouse to xterm: but only if
ttymouse doesn't already contain a setting that works for the current
terminal (thus, if t_RV is set and the xterm said it was
xterm2-compliant, ttymouse will already have been set to xterm2).

Screen is actually quite capable of understanding and transmitting
xterm2 protocol, but it doesn't provide t_RV, and so has no way of
telling vim whether it's on an xterm2-supporting xterm or not.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature

Re: vim_is_xterm() and screen

[Micah Cowan]

A.J.Mechelynck wrote:

 This is done as a result
 of sending the t_RV code and receiving an answer for it, which happens
 after the first file has been loaded and all -c commands have been
 processed: probably just before or just after the VimEnter event. IOW,
 you cannot test them in your vimrc or even in a global plugin (they are
 sourced too early). At the VimEnter event might be late enough but I
 haven't tested it.

Sorry, I meant to address this more explicitly: I tested, and under
xterm, .vimrc sees term=xterm, ttymouse=xterm (note that ttymouse later
becomes xterm2). Same for screen (except ttymouse doesn't change later).

So I was probably a little wrong about the order in which things take
place. Regardless, the code change seems to be consistent with the
current process.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature

Re: vim_is_xterm() and screen

[Micah Cowan]

Micah Cowan wrote:
 A.J.Mechelynck wrote:
 
 This is done as a result
 of sending the t_RV code and receiving an answer for it, which happens
 after the first file has been loaded and all -c commands have been
 processed: probably just before or just after the VimEnter event. IOW,
 you cannot test them in your vimrc or even in a global plugin (they are
 sourced too early). At the VimEnter event might be late enough but I
 haven't tested it.
 
 Sorry, I meant to address this more explicitly: I tested, and under
 xterm, .vimrc sees term=xterm, ttymouse=xterm (note that ttymouse later
 becomes xterm2). Same for screen (except ttymouse doesn't change later).

And, of course, term=screen, rather than xterm. :)

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature

[PATCH] vim_is_xterm() and screen

[Micah Cowan]

Sorry for the repost; but I realized I should've drawn more attention to
the message with the patch in it, both so other lurkers know the thread
now includes a proposed patch, and so that we know what message to go
back to if we want to refer to the code we're discussing.

I have made a slight adjustment to the patch, swapping the order of
STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using
vim_is_xterm() instead of term_is_xterm at first, but afterwards
replaced it for efficiency, but left the order as it was.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

Index: os_unix.c
===
--- os_unix.c	(revision 276)
+++ os_unix.c	(working copy)
@@ -2034,6 +2034,21 @@
 		|| STRCMP(name, builtin_xterm) == 0);
 }
 
+/*
+ * Return TRUE if name appears to be that of a terminal
+ * known to support the xterm-style mouse protocol.
+ * Relies on term_is_xterm having been set to its correct value.
+ */
+int
+vim_uses_xterm_mouse(name)
+char_u *name;
+{
+if (name == NULL)
+	return FALSE;
+return (term_is_xterm
+		|| STRNICMP(name, screen, 6) == 0);
+}
+
 #if defined(FEAT_MOUSE_TTY) || defined(PROTO)
 /*
  * Return non-zero when using an xterm mouse, according to 'ttymouse'.
Index: term.c
===
--- term.c	(revision 276)
+++ term.c	(working copy)
@@ -1601,6 +1601,9 @@
 int		try;
 int		termcap_cleared = FALSE;
 #endif
+#if defined(UNIX) || defined(VMS)
+int		term_uses_xterm_mouse;
+#endif
 int		width = 0, height = 0;
 char_u	*error_msg = NULL;
 char_u	*bs_p, *del_p;
@@ -1903,6 +1906,7 @@
 
 #if defined(UNIX) || defined(VMS)
 term_is_xterm = vim_is_xterm(term);
+term_uses_xterm_mouse = vim_uses_xterm_mouse(term);
 #endif
 
 #ifdef FEAT_MOUSE
@@ -1923,7 +1927,7 @@
 #endif
 	clip_init(FALSE);
 #   endif
-	if (term_is_xterm)
+	if (term_uses_xterm_mouse)
 	{
 	if (use_xterm_mouse())
 		p = NULL;	/* keep existing value, might be xterm2 */



signature.asc
Description: PGP signature


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] vim_is_xterm() and screen

[Bram Moolenaar]

Micah Cowan wrote:

 Sorry for the repost; but I realized I should've drawn more attention to
 the message with the patch in it, both so other lurkers know the thread
 now includes a proposed patch, and so that we know what message to go
 back to if we want to refer to the code we're discussing.
 
 I have made a slight adjustment to the patch, swapping the order of
 STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using
 vim_is_xterm() instead of term_is_xterm at first, but afterwards
 replaced it for efficiency, but left the order as it was.

Looks OK to me.

If I understood your other message correctly then using xterm2 for
'ttymouse' would not work for screen.

-- 
From know your smileys:
 :-DBig smile

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: [PATCH] vim_is_xterm() and screen

[Micah Cowan]

Bram Moolenaar wrote:
 Micah Cowan wrote:
 
 Sorry for the repost; but I realized I should've drawn more attention to
 the message with the patch in it, both so other lurkers know the thread
 now includes a proposed patch, and so that we know what message to go
 back to if we want to refer to the code we're discussing.

 I have made a slight adjustment to the patch, swapping the order of
 STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using
 vim_is_xterm() instead of term_is_xterm at first, but afterwards
 replaced it for efficiency, but left the order as it was.
 
 Looks OK to me.

Terrific! Does that mean it'll go in? :)

 If I understood your other message correctly then using xterm2 for
 'ttymouse' would not work for screen.

Well... manually setting it to xterm2 will work fine (assuming screen
is running under a supporting version of xterm): I get the full dragging
effect, etc. But screen doesn't do t_RV, and I don't know how else you'd
determine support for xterm2, so there doesn't seem to be a safe way
to set ttymouse to it automatically, for screen.

Towards a better solution: how straightforward do you think it'll be to
talk the ncurses guys into adding support for some of screen's
extensions? AFAIK, the only one I care about is the xterm mouse support;
another interesting one is a boolean supports ansi
setforeground/setbackground codes; but I usually infer this (if
necessary) from the presence of setaf/setbf (not a given, but...).

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] vim_is_xterm() and screen

[Gary Johnson]

On 2007-05-09, Micah Cowan [EMAIL PROTECTED] wrote:

 Towards a better solution: how straightforward do you think it'll be to
 talk the ncurses guys into adding support for some of screen's
 extensions? AFAIK, the only one I care about is the xterm mouse support;
 another interesting one is a boolean supports ansi
 setforeground/setbackground codes; but I usually infer this (if
 necessary) from the presence of setaf/setbf (not a given, but...).

The ncurses guys is Thomas Dickey, who frequents a number of lists 
and newsgroups,  and who would probably be willing to discuss it 
with you.  Contact information is here:

   http://www.gnu.org/software/ncurses/

Look for Who's Who and What's What.  You might also consider 
joining the bug-ncurses-request mailing list, which is open to 
anyone interested in helping with the development and testing of 
this package.

I would imagine the process would be more a matter of convincing 
Thomas to accept the concept, the design, and any patches you would 
submit, rather than the ncurses guys adding this support 
themselves.

Regards,
Gary

-- 
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
 | Spokane, Washington, USA

Re: [PATCH] vim_is_xterm() and screen

[Micah Cowan]

Gary Johnson wrote:
 On 2007-05-09, Micah Cowan [EMAIL PROTECTED] wrote:
 
 Towards a better solution: how straightforward do you think it'll be to
 talk the ncurses guys into adding support for some of screen's
 extensions? AFAIK, the only one I care about is the xterm mouse support;
 another interesting one is a boolean supports ansi
 setforeground/setbackground codes; but I usually infer this (if
 necessary) from the presence of setaf/setbf (not a given, but...).
 
 The ncurses guys is Thomas Dickey, who frequents a number of lists 
 and newsgroups,  and who would probably be willing to discuss it 
 with you.  Contact information is here:
 
http://www.gnu.org/software/ncurses/
 
 Look for Who's Who and What's What.  You might also consider 
 joining the bug-ncurses-request mailing list, which is open to 
 anyone interested in helping with the development and testing of 
 this package.

Thanks for that!

 I would imagine the process would be more a matter of convincing 
 Thomas to accept the concept, the design, and any patches you would 
 submit, rather than the ncurses guys adding this support 
 themselves.

Fair enough. :)

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/




signature.asc
Description: OpenPGP digital signature

vim_is_xterm() and screen

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Some folks who like to use vim under GNU screen, myself included, would
like the ability for vim to automatically support xterm mouse escape
sequences. Would it be a workable solution for vim to include screen
as one of the initial strings for terms that trigger truth for
vim_is_xterm()?

I'm guessing that a problem for this, might be the fact that if vim
detects xterm-ish terminals, it automatically tries the t_RV sequence
out, which isn't dependably valid for screen.

If this is the case, perhaps there could be a vim_might_be_xterm(),
which could set ttymouse to xterm, on the off-chance that the terminal
may send it xterm-style mouse sequences, but leave t_RV empty so that it
doesn't risk sending unrecognized stuff that the terminal may choose to
display directly?

The thing is, is that users of screen are able to use some other
programs, such as elinks, and will wonder why vim can't work just as
well. Are there any real impediments to it doing so?

I suspect that my solution could actually be made much more simple by
simply assuming that all terms might be xterm, thus eliminating the
need to actually implement a function (just set ttymouse to xterm by
default, again leaving t_RV).

Thanks for your feedback.

References:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214083
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/113227

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGQBn/7M8hyUobTrERAh1OAJ4ryRB55gWXGwmErt2gHkSVRkIOdwCfSwi8
qD+sS9zpdm3I/Wpsp+hcWHY=
=8CI4
-END PGP SIGNATURE-

Re: vim_is_xterm() and screen

[Bram Moolenaar]

Micah Cowan wrote:

 Some folks who like to use vim under GNU screen, myself included, would
 like the ability for vim to automatically support xterm mouse escape
 sequences. Would it be a workable solution for vim to include screen
 as one of the initial strings for terms that trigger truth for
 vim_is_xterm()?

No, because screen is not an xterm.  The screen termcap/terminfo entry
differs from xterm.
 
 I'm guessing that a problem for this, might be the fact that if vim
 detects xterm-ish terminals, it automatically tries the t_RV sequence
 out, which isn't dependably valid for screen.
 
 If this is the case, perhaps there could be a vim_might_be_xterm(),
 which could set ttymouse to xterm, on the off-chance that the terminal
 may send it xterm-style mouse sequences, but leave t_RV empty so that it
 doesn't risk sending unrecognized stuff that the terminal may choose to
 display directly?
 
 The thing is, is that users of screen are able to use some other
 programs, such as elinks, and will wonder why vim can't work just as
 well. Are there any real impediments to it doing so?
 
 I suspect that my solution could actually be made much more simple by
 simply assuming that all terms might be xterm, thus eliminating the
 need to actually implement a function (just set ttymouse to xterm by
 default, again leaving t_RV).

There doesn't appear to be a standard for mouse escape sequences.  And
termcap/terminfo is too limited for the features of modern terminal
emulaters.  That means the only choice for Vim is to implement mouse
support for each terminal separately.  If screen uses the same codes as
xterm then this should be relatively simple.

It's about time termcap/terminfo gets updated to support the features we
need, instead of hacking solutions in all programs.  I'm afraid I don't
have time for this (the original development of termcap was closely
related to the early development of vi).

-- 
From know your smileys:
 :-)-O  Smiling doctor with stethoscope

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: vim_is_xterm() and screen

[Micah Cowan]

Doh! I accidentally sent this directly to Bram, instead of to list :/

Bram Moolenaar wrote:

 I'm guessing that a problem for this, might be the fact that if vim
 detects xterm-ish terminals, it automatically tries the t_RV sequence
 out, which isn't dependably valid for screen.

 If this is the case, perhaps there could be a vim_might_be_xterm(),
 which could set ttymouse to xterm, on the off-chance that the terminal
 may send it xterm-style mouse sequences, but leave t_RV empty so that it
 doesn't risk sending unrecognized stuff that the terminal may choose to
 display directly?

 The thing is, is that users of screen are able to use some other
 programs, such as elinks, and will wonder why vim can't work just as
 well. Are there any real impediments to it doing so?

 I suspect that my solution could actually be made much more simple by
 simply assuming that all terms might be xterm, thus eliminating the
 need to actually implement a function (just set ttymouse to xterm by
 default, again leaving t_RV).

 There doesn't appear to be a standard for mouse escape sequences.  And
 termcap/terminfo is too limited for the features of modern terminal
 emulaters.  That means the only choice for Vim is to implement mouse
 support for each terminal separately.  If screen uses the same codes as
 xterm then this should be relatively simple.

The de facto standard (aside from the limited support that /is/ offered
via terminfo) would seem to be xterm... plus maybe whatever it is that
gpm uses.

 It's about time termcap/terminfo gets updated to support the features we
 need, instead of hacking solutions in all programs.  I'm afraid I don't
 have time for this (the original development of termcap was closely
 related to the early development of vi).

But you already have hacked support into your programs for mouse
support. Now that you've done that, couldn't you just open it up a bit?
Is there anything wrong with always recognizing the appropriate xterm
sequences (provided that they don't first match a valid terminfo entry)?
This is the approach that elinks seems to take, and I don't see any
particular reason why vim couldn't do this as well.

I agree that fixing terminfo is the right solution, but that doesn't
mean you shouldn't hack the working solution in now. You have already
done so, or you wouldn't have any mouse support for the various
xterm-like consoles in the first place.

I'd be happy to write the patch (it should be pretty straightforward); I
just want to get some agreement on the correct action to take.

-- 
Thanks,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/




signature.asc
Description: OpenPGP digital signature

Re: vim_is_xterm() and screen

[Gautam Iyer]

On Tue, May 08, 2007 at 03:04:10PM -0700, Micah Cowan wrote:

  It's about time termcap/terminfo gets updated to support the
  features we need, instead of hacking solutions in all programs.  I'm
  afraid I don't have time for this (the original development of
  termcap was closely related to the early development of vi).
 
 But you already have hacked support into your programs for mouse
 support. Now that you've done that, couldn't you just open it up a
 bit? Is there anything wrong with always recognizing the appropriate
 xterm sequences (provided that they don't first match a valid terminfo
 entry)? This is the approach that elinks seems to take, and I don't
 see any particular reason why vim couldn't do this as well.
 
 I agree that fixing terminfo is the right solution, but that doesn't
 mean you shouldn't hack the working solution in now. You have already
 done so, or you wouldn't have any mouse support for the various
 xterm-like consoles in the first place.
 
 I'd be happy to write the patch (it should be pretty straightforward);
 I just want to get some agreement on the correct action to take.

I for one would *love* to see this. I use mrxvt all the time. The
terminal codes for mrxvt are somewhere between xterm and rxvt, thus
mrxvt should have its own terminal type. However a *lot* of programs
(including Vim and w3m) simply refuse to use the mouse if the terminal
name is not rxvt or xterm.

The ugly hack used my mrxvt right now is to install it's terminfo entry
under the name rxvt!

Numerous mrxvt users have complained about this. It would be nice if
things could be made to work correctly with other terminals.

GI

PS: Mrxvt's mouse reporting is the same as the old xterm style mouse
reporting.

-- 
Reading while sunbathing makes you well-red.

Re: vim_is_xterm() and screen

[A.J.Mechelynck]

Micah Cowan wrote:
[...]

But you already have hacked support into your programs for mouse
support. Now that you've done that, couldn't you just open it up a bit?
Is there anything wrong with always recognizing the appropriate xterm
sequences (provided that they don't first match a valid terminfo entry)?
This is the approach that elinks seems to take, and I don't see any
particular reason why vim couldn't do this as well.

[...]

There are conflicts between xterm mouse codes and DEC mouse codes. See :help 
'ttymouse' for details (and, maybe, for a way of telling Vim which mouse is 
installed).



Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
221. Your wife melts your keyboard in the oven.

Re: vim_is_xterm() and screen

[Micah Cowan]

A.J.Mechelynck wrote:
 Micah Cowan wrote:
 [...]
 But you already have hacked support into your programs for mouse
 support. Now that you've done that, couldn't you just open it up a bit?
 Is there anything wrong with always recognizing the appropriate xterm
 sequences (provided that they don't first match a valid terminfo entry)?
 This is the approach that elinks seems to take, and I don't see any
 particular reason why vim couldn't do this as well.
 [...]
 
 There are conflicts between xterm mouse codes and DEC mouse codes. See
 :help 'ttymouse' for details (and, maybe, for a way of telling Vim
 which mouse is installed).

Hrm, yes, that could be a problem. I'm guessing the conflict has to do
with vim needing to actually signal to the terminal which style of mouse
code to send? (I had forgotten that this signal was necessary, which is
silly, since bad things would happen if it wasn't.)

Alright, then, looks like the only way forward is to fix terminfo, as
Bram has suggested. I just noticed that the screen info manual has a
section on termcap extensions that it supports, including a XT boolean
to indicate support for xterm mouse and OSC (with which I'm not
familiar). Perhaps that would be appropriate to prod the ncurses guys to
support...

Except, if it really is a conflict, I'm wondering how does elinks
manages to do it?

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/




signature.asc
Description: OpenPGP digital signature

Re: vim_is_xterm() and screen

[Micah Cowan]

A.J.Mechelynck wrote:
 Micah Cowan wrote:
 [...]
 But you already have hacked support into your programs for mouse
 support. Now that you've done that, couldn't you just open it up a bit?
 Is there anything wrong with always recognizing the appropriate xterm
 sequences (provided that they don't first match a valid terminfo entry)?
 This is the approach that elinks seems to take, and I don't see any
 particular reason why vim couldn't do this as well.
 [...]
 
 There are conflicts between xterm mouse codes and DEC mouse codes. See
 :help 'ttymouse' for details (and, maybe, for a way of telling Vim
 which mouse is installed).

I did some digging in the screen source code, and determined that when
screen receives DECSET with one of the mouse-reporting params (9, 1000,
1001), it first checks (using the stupid name magic, unless the user
happens to be using termcap instead of terminfo, and has the special
screen extension for xterm included) which of the terminals connected to
a session (there may be more than one) support the xterm controls, and
then sets mouse mode on the terminals that have been detected as xterms
corresponding to the sequence it got. Then all sequences that the
terminal sends get passed through to the application.

For those terminals that are not detected as xterms (have either the
string xterm or rxvt in the terminal name), the mode is not sent
through at all.

Therefore, there would seem to be no harm whatsoever in detecting screen
as an xterm-mouse-code-capable terminal, and sending the mouse-mode
sequence (xterm protocol, since AFAIK screen provides no way to detect
the underlying xterm version). If the underlying terminal claims to be
xterm or rxvt, then the user will automatically get the benefit of mouse
support without trouble; otherwise, screen will simply ignore the
sequence and no harm is done to other terminals (such as unrecognized
sequence-emitters, or DEC-mouse-only terminals).

I propose that rather than using vim_is_xterm() to determine xterm-style
mouse support, a separate function, vim_supports_xterm_mouse() [or
somesuch] be used, which would currently return (vim_is_xterm() ||
terminal is screen).

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/




signature.asc
Description: OpenPGP digital signature