Re: [dev] st features that'd be nice

[Suraj N. Kurapati]

On Tue 18 Oct 2011 11:01:07 AM PDT, Nick wrote:
> * Find - search through scrollback (maybe using regex).

I find this to be one of URxvt's killer features.  Alt-S brings up
an interactive regexp search of the scrollback buffer: urxvtperl(3).

-- 
To understand a program you must become both the machine and the
program.


signature.asc
Description: PGP signature

Re: [dev] st features that'd be nice

[Andrew Hills]

On Tue, Oct 18, 2011 at 9:13 AM, Stefan Mark  wrote:
> For me, performance is the main issue. Drawing of 'mc' on higher
> resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on
> a reasonable fast machine. Drawing 'top' took a bit less, but not much.
> When doing so, st itself uses nearly none cpu time, but x11 took around
> 97%. (using st 0.1.1)

Strangely enough, at 1400x1050 on a Pentium M laptop running at 1GHz,
I find no performance issues running top, with a CPU usage somewhat,
but not significantly, higher than xterm's (for both st and X). This
is with st tip and 0.1.1.

Using st as an xterm replacement for some time, I found that the
missing scrollback buffer is unimportant to me, so long as I have
less, and the only real workaround I use is telling vim that it's
running in an xterm.

--Andrew Hills

Re: [dev] st features that'd be nice

[Manolo Martínez]

On 10/18/11 at 03:13pm, Stefan Mark wrote:
> On 18.10.2011 13:15, Peter John Hartman wrote:
> > Here's a feature request that should go in first: make st usable.
> > 
> For me, performance is the main issue. Drawing of 'mc' on higher
> resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on
> a reasonable fast machine. Drawing 'top' took a bit less, but not much.
> When doing so, st itself uses nearly none cpu time, but x11 took around
> 97%. (using st 0.1.1)
> 
FWIW, I'm part of (I think) a growing trend of undaunted newbies: I run dwm and
mostly text programs, but my scripting abilities are, well, limited.

I gave st a try the other day, and yes, consulting my mutt mail took forever.

Cheers,
Manolo
-- 

Re: [dev] st features that'd be nice

[Stefan Mark]

On 18.10.2011 13:15, Peter John Hartman wrote:
> Here's a feature request that should go in first: make st usable.
> 
For me, performance is the main issue. Drawing of 'mc' on higher
resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on
a reasonable fast machine. Drawing 'top' took a bit less, but not much.
When doing so, st itself uses nearly none cpu time, but x11 took around
97%. (using st 0.1.1)

Re: [dev] Some questions about st and a patch

[Eckehard Berns]

> Can anyone please try it with his favourite modifed-arrow-key-using
> software with TERM=st and TERM=xterm?

It looks like in joe st behaves exactly like xterm (which is: starting a
selction as expected with ctrl, and inserting A, B, C and Ds with shift
and alt). In Vim nothing really works regardless of the TERM settings
(Vim inserts parts of the control sequences etc.). Haven't tried
anything else. I don't use arrow keys if I can avoid them and thus am
not very familiar which software supports modifier keys with arrows.

-- 
Eckehard Berns

Re: [dev] st features that'd be nice

[Peter John Hartman]

On Tue, Oct 18, 2011 at 11:01:07AM +0100, Nick wrote:
> I just read about terminator
> , and thought a
> couple of its features sounded worth stealing (both require
> scrollback to be implemented):
> 
> * Logging - logs of terminal sessions can be saved. It only
>   makes sense to do this on command, rather than automatically
>   (as terminator does). Once scrollback exists, this becomes
>   pretty easy (just save that).
> 
> * Find - search through scrollback (maybe using regex).
> 
> Another nice thing to have would be:
> 
> * Smart reflowing of text on window resize. I think OSX's
>   terminal emulator might do this.
> 
> None of these should take much code, I think. I'd like to
> add these myself, but I'd like it even more if someone else
> did.

The logging and find are both things that tmux does, and to do them right it
does take a chunk of code.  Why should st do them?  I can't think of any
reason.  Here's a feature request that should go in first: make st usable.

Peter



-- 
sic dicit magister P
University of Toronto / Fordham University
Collins Hall B06; Office Hours TF10-12
http://individual.utoronto.ca/peterjh
gpg --keyserver pgp.mit.edu --recv-keys E0DBD3D6 

Re: [dev] Some questions about st and a patch

[Aurélien Aptel]

On Tue, Oct 18, 2011 at 12:27 PM, pancake  wrote:
> and type rm -rf ~ ; after the patch is applied

Thank you for your helpful{#`%${%&`+'${`%&NO CARRIER

Re: [dev] Some questions about st and a patch

[Aurélien Aptel]

Attached wrong patch; use this one, sorry.
diff -r 704261718508 st.c
--- a/st.c  Thu Oct 06 21:32:34 2011 +0200
+++ b/st.c  Tue Oct 18 12:20:03 2011 +0200
@@ -208,6 +208,7 @@
 static void ttyread(void);
 static void ttyresize(int, int);
 static void ttywrite(const char *, size_t);
+static void ttyprintf(const char *, ...);
 
 static void xdraws(char *, Glyph, int, int, int, int);
 static void xhints(void);
@@ -733,10 +734,27 @@
 
 void
 ttywrite(const char *s, size_t n) {
-   if(write(cmdfd, s, n) == -1)
+   if(write(cmdfd, s, n) < 0)
die("write error on tty: %s\n", SERRNO);
 }
 
+/* tty helper: slow, use it for non-frequent small stuff */
+void
+ttyprintf(const char *f, ...) {
+   char buf[1024];
+   va_list ap;
+   int n = 0;
+
+   va_start(ap, f);
+   n = vsnprintf(buf, sizeof(buf), f, ap);
+   va_end(ap);
+
+   if(n < 0 || n >= sizeof(buf))
+   die("ttyprintf: vnsprintf failed (%d/%d)", n, sizeof(buf));
+
+   ttywrite(buf, strlen(buf));
+}
+
 void
 ttyresize(int x, int y) {
struct winsize w;
@@ -1890,8 +1908,10 @@
int len;
int meta;
int shift;
+   int ctrl;
Status status;
 
+   ctrl = e->state & ControlMask;
meta = e->state & Mod1Mask;
shift = e->state & ShiftMask;
len = XmbLookupString(xw.xic, e, buf, sizeof(buf), &ksym, &status);
@@ -1905,11 +1925,21 @@
case XK_Up:
case XK_Down:
case XK_Left:
-   case XK_Right:
-   /* XXX: shift up/down doesn't work */
-   sprintf(buf, "\033%c%c", IS_SET(MODE_APPKEYPAD) ? 'O' : 
'[', (shift ? "dacb":"DACB")[ksym - XK_Left]);
-   ttywrite(buf, 3);
+   case XK_Right: {
+   char cursor = "DACB"[ksym - XK_Left];
+   char mode = IS_SET(MODE_APPKEYPAD) ? 'O' : '[';
+   int n = 1;
+
+   if(shift) n += 1;
+   if(meta)  n += 2;
+   if(ctrl)  n += 4;
+
+   if(n > 1)
+   ttyprintf("\033%c1;%d%c", mode, n, cursor);
+   else
+   ttyprintf("\033%c%c", mode, cursor);
break;
+   }   
case XK_Insert:
if(shift)
selpaste();

Re: [dev] Some questions about st and a patch

[pancake]

On 10/18/11 12:17, Aurélien Aptel wrote:

On Tue, Oct 18, 2011 at 12:14 PM, Aurélien Aptel
  wrote:

Reminder:
$ hg clone http://hg.suckless.org/st
$ patch -p1<  xterm-arrow-keys.diff

You need to cd in st after hg clone, obviously.


and type rm -rf ~ ; after the patch is applied

Re: [dev] Some questions about st and a patch

[Aurélien Aptel]

On Tue, Oct 18, 2011 at 12:14 PM, Aurélien Aptel
 wrote:
> Reminder:
> $ hg clone http://hg.suckless.org/st
> $ patch -p1 < xterm-arrow-keys.diff

You need to cd in st after hg clone, obviously.

Re: [dev] Some questions about st and a patch

[Aurélien Aptel]

On Mon, Oct 17, 2011 at 5:06 PM, Connor Lane Smith  wrote:
> I'm not a st developer, but I've had a look at this. Arrow keys do
> need to be handled in a special way, but the arrow keys don't work
> with any modifier keys.
>
> Currently st handles an arrow key by printing, eg, "\033[D". With
> shift it is "\033[1;2D", with alt "\033[1;3D", and so on. So it needs
> to detect bucky bits and react accordingly.

Unfortunately, it's not that simple.
Modifiers in terminals are handled differently in each terminal.
Sometime they are added as a parameter, sometime it's a key on its
own.
Start cat with no argument and try pressing any combination of
modifier with any arrow key in xterm and urxvt.
note: ^[ is \033 aka ESC

It seems that ncurses (which is maintained by xterm folks mind you)
doesn't even try to handle this clusterfuck [1].

On Mon, Oct 17, 2011 at 5:20 PM, Stephen Paul Weber
 wrote:
> Excellent!  I shoved this in st.c for now:
> 
> And it works! :D

It works in irssi? This is weird.
I've attached a patch to handle modifiers like xterm. Of course
modified arrow keys still don't work in emacs... Ugh. This is really
depressing.
Can anyone please try it with his favourite modifed-arrow-key-using
software with TERM=st and TERM=xterm?

Reminder:
$ hg clone http://hg.suckless.org/st
$ patch -p1 < xterm-arrow-keys.diff
$ make
$ ./st
(in st window) TERM=xterm yourapp
or, for TERM=st-xxx
(in st window) yourapp

1: http://invisible-island.net/ncurses/ncurses.faq.html#modified_keys
diff -r 704261718508 st.c
--- a/st.c  Thu Oct 06 21:32:34 2011 +0200
+++ b/st.c  Tue Oct 18 12:02:40 2011 +0200
@@ -208,6 +208,7 @@
 static void ttyread(void);
 static void ttyresize(int, int);
 static void ttywrite(const char *, size_t);
+static void ttyprintf(const char *, ...);
 
 static void xdraws(char *, Glyph, int, int, int, int);
 static void xhints(void);
@@ -733,10 +734,27 @@
 
 void
 ttywrite(const char *s, size_t n) {
-   if(write(cmdfd, s, n) == -1)
+   if(write(cmdfd, s, n) < 0)
die("write error on tty: %s\n", SERRNO);
 }
 
+/* tty helper: slow, use it for non-frequent small stuff */
+void
+ttyprintf(const char *f, ...) {
+   char buf[1024];
+   va_list ap;
+   int n = 0;
+
+   va_start(ap, f);
+   n = vsnprintf(buf, sizeof(buf), f, ap);
+   va_end(ap);
+
+   if(n < 0 || n >= sizeof(buf))
+   die("ttyprintf: vnsprintf failed (%d/%d)", n, sizeof(buf));
+
+   ttywrite(buf, strlen(buf));
+}
+
 void
 ttyresize(int x, int y) {
struct winsize w;
@@ -1890,8 +1908,10 @@
int len;
int meta;
int shift;
+   int ctrl;
Status status;
 
+   ctrl = e->state & ControlMask;
meta = e->state & Mod1Mask;
shift = e->state & ShiftMask;
len = XmbLookupString(xw.xic, e, buf, sizeof(buf), &ksym, &status);
@@ -1905,11 +1925,21 @@
case XK_Up:
case XK_Down:
case XK_Left:
-   case XK_Right:
-   /* XXX: shift up/down doesn't work */
-   sprintf(buf, "\033%c%c", IS_SET(MODE_APPKEYPAD) ? 'O' : 
'[', (shift ? "dacb":"DACB")[ksym - XK_Left]);
-   ttywrite(buf, 3);
+   case XK_Right: {
+   char cursor = (shift ? "dacb" : "DACB")[ksym - XK_Left];
+   char mode = IS_SET(MODE_APPKEYPAD) ? 'O' : '[';
+   int n = 1;
+
+   if(shift) n += 1;
+   if(meta)  n += 2;
+   if(ctrl)  n += 4;
+
+   if(n > 1)
+   ttyprintf("\033%c1;%d%c", mode, n, cursor);
+   else
+   ttyprintf("\033%c%c", mode, cursor);
break;
+   }   
case XK_Insert:
if(shift)
selpaste();

Re: [dev] st features that'd be nice

[Nick]

On Tue, Oct 18, 2011 at 12:11:55PM +0200, pancake wrote:
> On 10/18/11 12:01, Nick wrote:
> >* Logging - logs of terminal sessions can be saved. It only
> >   makes sense to do this on command, rather than automatically
> >   (as terminator does). Once scrollback exists, this becomes
> >   pretty easy (just save that).
> use script, ytscript or ttyrec.

The advantage of doing it in the terminal (once it has
scrollback) is that you can decide after something
interesting has happened "and save that", rather than
running one of those before. (though I'm not very familiar
with any of those tools).

> >* Find - search through scrollback (maybe using regex).
> we have no scrollback, and we delegate this task to
> >Another nice thing to have would be:
> >
> >* Smart reflowing of text on window resize. I think OSX's
> >   terminal emulator might do this.
> that would be cool if we supported scrollback. which is imho the
> main reason i dont use st as my main terminal

Yeah, I meant to imply above that scrollback is a more
important feature, that I'd particularly like.

Re: [dev] st features that'd be nice

[pancake]

On 10/18/11 12:01, Nick wrote:

I just read about terminator
, and thought a
couple of its features sounded worth stealing (both require
scrollback to be implemented):

* Logging - logs of terminal sessions can be saved. It only
   makes sense to do this on command, rather than automatically
   (as terminator does). Once scrollback exists, this becomes
   pretty easy (just save that).

use script, ytscript or ttyrec.


* Find - search through scrollback (maybe using regex).

we have no scrollback, and we delegate this task to

Another nice thing to have would be:

* Smart reflowing of text on window resize. I think OSX's
   terminal emulator might do this.
that would be cool if we supported scrollback. which is imho the main 
reason i dont use st as my main terminal


None of these should take much code, I think. I'd like to
add these myself, but I'd like it even more if someone else
did.

Nick

[dev] st features that'd be nice

[Nick]

I just read about terminator
, and thought a
couple of its features sounded worth stealing (both require
scrollback to be implemented):

* Logging - logs of terminal sessions can be saved. It only
  makes sense to do this on command, rather than automatically
  (as terminator does). Once scrollback exists, this becomes
  pretty easy (just save that).

* Find - search through scrollback (maybe using regex).

Another nice thing to have would be:

* Smart reflowing of text on window resize. I think OSX's
  terminal emulator might do this.

None of these should take much code, I think. I'd like to
add these myself, but I'd like it even more if someone else
did.

Nick