Subject: Screen 4.0.3 @ GNU FTP (existing release)

From: Micah Cowan <[email-masked]>
Date: Thu, 07 Aug 2008 12:15:31 -0700

FYI, the 4.0.3 sources are now also available at ftp.gnu.org, in
addition to the uni-erlangen.de site.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/

_______________________________________________
screen-users mailing list
[email-masked]
http://lists.gnu.org/mailman/listinfo/screen-users

---

From: "Jean-Yves Levesque" <[email-masked]>
Date: Fri, 8 Aug 2008 10:17:46 -0400

On 8/7/08, Micah Cowan <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
o

  Are they the sources including the vertical  split or not?

  jy

-- 
Je ne parle qu'en mon nom.
I am only speaking for myself.

---

From: Adam Lazur <[email-masked]>
Date: Fri, 8 Aug 2008 08:09:31 -0700

>   Are they the sources including the vertical  split or not?

You could download the tarball and check if you're really interested...

4.0.3 is the release from 2006, so no, it does not include vertical
split.

-- 
Adam Lazur

---

From: "Jean-Yves Levesque" <[email-masked]>
Date: Fri, 8 Aug 2008 13:08:20 -0400

I am probably more interested in knowing when the
next release (including the vertical split) would
be officially out (I am using the git version curretnly).

---

From: Micah Cowan <[email-masked]>
Date: Fri, 08 Aug 2008 12:07:20 -0700

> be officially out (I am using the git version curretnly).

Yeah, that's why this was a very minor note, rather than a major
announcement. It's not so much a release announcement (which would also
have gone to [email-masked]), as a note that the ftp.gnu.org (which is
intended to be the primary release site) is now less incomplete than it
was. :)

I may be wrong, but I think we could be looking at a 4.1.0 release
around the turn of the year. Sadrul (especially) and I have been killing
bugs at a fairly quick rate, and we're down to about 20 bugs currently
being tracked against the 4.1.0 release (with more that have been marked
for later releases):
https://savannah.gnu.org/bugs/?group=screen&func=browse&set=custom&msort=1&custom_sb1[]=0&assigned_to[]=0&resolution_id[]=0&priority[]=0&severity[]=0&status_id[]=1&plan_release_id[]=101&release_id[]=0&details[]=&summary[]=&advsrch=1&msort=1&chunksz=50&spamscore=5&report_id=195&sumORdet=0&morder=priority%3C&sumOrdet=0&order=custom_sb1

I do expect that there will be more than those 20 bugs to fix before we
can release: layouts and groups need more refinement and
playing-around-with before a 4.1.0 release can be done, and may need
some additional supporting features (though not many, I think). Then
there needs to be a testing period, probably (although a good many
people are happily using the git sources).

Of course, if you'd like to hurry up the process, feel free to submit
patches against the bugs that are left, so we can finish it up. :)

- --
Micah J. Cowan

---

From: Stephane Chazelas <[email-masked]>
Date: Fri, 8 Aug 2008 21:00:19 +0100

On Fri, Aug 08, 2008 at 12:07:20PM -0700, Micah Cowan wrote:
[...]
> patches against the bugs that are left, so we can finish it up. :)
[...]

Hi Micah,

it's nice to see activity going on on screen again! Thanks for
the effort!

I've had a look at a bug report with patch that I had submitted
some time ago: https://savannah.gnu.org/bugs/?11021
The state says "needs discussion". I'm happy to discuss. Is
there any objection to the fix I'm suggesting? The only
comment on that bug, is about saying that "mouse is
already supported" which is not relevant to the issue.

Best regards,
Stéphane

---

From: Micah Cowan <[email-masked]>
Date: Fri, 08 Aug 2008 14:18:02 -0700

> already supported" which is not relevant to the issue.

I think the discussion I wished to have, was whether there was agreement
that in all cases we would wish the mouse sequences to go to the filter,
rather than the application. I would think that in many cases, one would
 wish the reverse (say if the application is vim, and the filter doesn't
get mouse sequences).

In order to be done right, it might be necessary for screen to determine
which tty the mouse-tracking sequence was sent on (app's or filter's).

OTOH, a case might be made that none of this applies when the filter
spec has "." as the first character. I'm not confident enough in my
knowledge/experience with filters to make such a judgment, which is why
I wanted to discuss it. :)

BTW, you might want to add yourself to that bug's Cc list (if you lack
an account, you should still be able to add yourself, by filling in a
captcha).

- --
Micah J. Cowan

---

From: Stephane Chazelas <[email-masked]>
Date: Sat, 9 Aug 2008 00:14:27 +0100

On Fri, Aug 08, 2008 at 02:18:02PM -0700, Micah Cowan wrote:
[...]
>  wish the reverse (say if the application is vim, and the filter doesn't

Sorry, 

I shouldn't have brought that thing about the mouse because it
is not at all about that, and it seemed to have confused
everybody.

A mouse event is exactly like a keyboard event, upon a keypress,
the tty sends a character or character sequence to screen.
Screen will generate a character for the window that currently
has the focus, and/or any filter that is configure to filter the
input. For a xterm-like mouse event it's the same thing, the tty
sends a character sequence to screen. screen might translate it
if there are split screen and send that to the current windows
and/or filter if the filter is configured to get the input.
That's what screen does already at the moment, it's all fine.

But my bug report was not at all about that.

There are some control sequences that you send to the terminal,
and the terminal /replies/ with another one.

One of them is the one to query the cursor (*not* mouse cursor)
position: Report Cursor Position (CPR): if your application
writes \e[6n to the slave side of its pty, xterm will reply with
the cursor position. It will write something like \e[4;1R to the
master side of the terminal, so that if the application reads
from the slave side, it will get those characters as if the user
had typed ESC [ 4 ; 1 R.

Just like xterm, screen supports that CPR sequence. The
difference with the pressing of a key or mouse button is that it
is initiated by an application talking to screen. And screen
makes up its response by itself. The host terminal is not
queried, screen might even be detached.

At the moment, the sequence that screen replies with (the cursor
(not mouse cursor, just text cursor) position like \e[4;1R) goes
to the application OK, but it doesn't go to a filter that is
configured to get the input (first character is "." as in exec
.!.), contrary to the mouse events. And I was saying it is not
right because they are inputs all the same, it's as if the user
had typed ESC [ 4 ; 1 R. So that's my bug report, nothing to do
with mouse.

Now, to explain why I brought the mouse thing up that confused
everybody: one example for which it would be useful to have the
filter see those /answers/ from screen is that it could allow
you to give mouse support to any application, for instance
"vi" (the good old vi, not vim which has support for mouse of
its own already) or GNU info. If you have a filter that
intercepts all the input (including the responses to the Report
Cursor Position), you can make that filter so that it intercepts
mouse events. That part works OK at the moment. Upon a click,
the filter is able to determine the position of the mouse
cursor because that's encoded in the character sequence that it
can read. Then that filter can issue a CPR to get the position
of the cursor. Unfortunately, at the moment, it cannot get the
answer because it is not sent to it, only to the application.
But if it could, it could have the information about both the
current cursor position and the position of the screen where the
user mouse-clicked so that it could for instance send the correct
sequence of <Ctrl-F> and <Ctrl-N> to tell "info" to move the
cursor localtion to where the user clicked.

I hope it clarifies it a bit.

Best regards,
Stéphane

---

From: Micah Cowan <[email-masked]>
Date: Fri, 08 Aug 2008 18:52:53 -0700

> is not at all about that, and it seemed to have confused

<snip example using CPR, rather than mouse-tracking>

I was aware that the issue wasn't specific to mouse-reporting. What I
didn't realize is that the issue actually fails to apply at _all_ to
mouse-reporting. Your talk about mouse support is possibly even more of
a red herring than you knew. :)

The concerns I brought up in my previous response still apply, whether
mouse-tracking is concerned or not: should "screen-generated" responses
be sent to the filtering process in all cases, or is that likely to
confuse filters which weren't set up for it?

> which tty the mouse-tracking sequence was sent on (app's or filter's).

is equally applicable if you replace "mouse-tracking sequence" with "CPR
sequence".

However, what I did not realize is that mouse-tracking sequences are
_already_ always sent to the filter, and not the application, with or
without the patch you provided. I was assuming that it worked through
the same mechanism that response to CPR use. However, after some digging
around, I realize now that this is not at all the case: screen responds
to CPR internally, and issues its response directly to the application.
However, when screen sees mouse-tracking requests, it passes it on to
the host terminal (that part I already knew), and then when it sees
mouse-state reports, it leaves the report in-stream (if it's for the
correct position), and simply adjusts the information. I had been
thinking the information got swallowed up, and re-reported via Report()
or similar.

So, my concern whether screen-generated responses holds somewhat less
weight as an impedement to your patch, since mouse-tracking sequences
(which are also "responses" to application (or filter) requests), are
_already_ always sent to the filter's input, leading to an inconsistency.

However, the concern still remains, that if I apply your patch, it may
be that filters that didn't send/don't expect a response to an
application-sent CPR may be confused/broken. I'm thinking that it might
be more robust if screen were to note which tty the CPR (or other
request) came down (application or pseudo), and send the response back
on the same one.

For consistency, one could also consider having screen swallow up
mouse-tracking responses, and reissue them down only the ttys on which
requests had been seen.

But that wouldn't be a general solution, since other term-specific
query/responses couldn't be caught by Screen, and so would always end up
at the filter end in any case. So, perhaps I should simply apply your
patch to obtain a general _and_ consistent solution (if a potentially
existing-filters-breaking one), and have done with it.

...which is why this is a discussion, and not a rant. Feedback, anyone? :)

- --
Micah J. Cowan

---

From: Stephane Chazelas <[email-masked]>
Date: Mon, 11 Aug 2008 10:58:56 +0100

Hi Micah,

I don't agree with that. If I filter the input to vim, I don't
see why I would expect part of the input not to go through the
filter.

But I'm talking here only of filters that filters the input,
that is what is otherwise being sent to the applications (what
applications read from their slave, or what they would have read
in the absence of a filter).

That includes characters sent upon a key press (or return) or
mouse button press or motion if the application requested mouse
tracking, screen -X stuff, responses to "report" sequences and
so on.

By trying to be clever and guess and select which of those a
filter author might be interested in, I fear that we lose in
clarity and flexibility.

It should be up to the filter to select what it is interested
in: anyway, if it filters the input to a curses like
application, it has to know how to cope with character sequences
sent upon <Left>, <Home>, <F*> keys and so on. The <kMouse> key
is just another character sequence, you may consider for
instance that there's a key for every character cell on the
window.

Every time I try to use filters, I have to scratch my head for a
while as it's quite complex. Having *all* the input go through
filters that have "." as the first character is the fd
specification looks like the most sensible thing to do to me and
what a user would expect.

It allows filters to do stuff on all the sorts of input. If you
leave one sort of input out, that means less flexibility, as
that's one thing a filter can't do anything on anymore, or you
have to provide with an alternative way for them to do it and
that would add complexity.

> I wanted to discuss it. :)

I'm not too sure about what you mean with "which tty the
mouse-tracking sequence was sent on" in the context of
mouse-tracking.

Do you mean the sequence that enables mouse tracking, or the
sequence sent by the terminal when a mouse button is pressed
when mouse-tracking in enabled?

For the escape sequences sent by the terminal upon a button
press, it's like any other key press IMO. The sequence should go
to the window that has focus, and if there's a filter on input
for that window, it should go to the filter instead.

Like if you do :exec ... vim
That vim should overwrite what is currently running, and mouse
should work.

At the moment, mouse is working. What is not working is if vim
sends some "report" queries, it doesn't see the answer.

Actually, you can observe that vim takes some time to start up
and my guess is because it times out waiting for the answer to
some "query terminal type" sequence.

Best regards,
Stéphane

---

From: Juergen Weigert <[email-masked]>
Date: Mon, 11 Aug 2008 21:13:20 +0200

> ...which is why this is a discussion, and not a rant. Feedback, anyone? :)

When I originally implemented filters, the concept was, that everything
should pass through the filter process. 

A filter that relies on some data bypassing the filter, is a bad filter and
should be fixed, IMO.

Filter syntax and semantics are horribly complex, and possibly got quite
broken over time. I haven't used any recently.

        cheers,
                Js.

-- 
 o \  Juergen Weigert      unix-software __/ _=======.=======_     
<V> | [email-masked]         creator    __/        _---|____________\/    
 \  |            0179/2069677      __/          (____/            /\
(/) | ____________________________/              _/ \_ vim:set sw=2 wm=8

---

From: Micah Cowan <[email-masked]>
Date: Mon, 11 Aug 2008 12:28:09 -0700

> broken over time. I haven't used any recently.

Well, that's certainly reason enough to fix it, then. :) Thanks for
clarifying, Juergen.

It may also be that this was never working properly; I expect that not
many filters issue terminal queries, so who would have noticed?

- --
Micah J. Cowan