[st] goals / non-goals for st?

[Ray Kohler]

I'm rather curious on where st will go, and what kinds of things other
terminals do that it will or won't do.

In particular:
- Is a scrollback buffer objectionable in principle, such that we
should expect to "just use GNU screen"?
- Will it implement enough of xterm's capabilities that I could lie
about $TERM and expect it to mostly work? I log into many remote
machines of various OS types and ages, and some of them don't make it
easy to install user-specific terminfo entries.

[James PIC]

Post by Ray Kohler
- Will it implement enough of xterm's capabilities that I could lie
about $TERM and expect it to mostly work? I log into many remote
machines of various OS types and ages, and some of them don't make it
easy to install user-specific terminfo entries.

Do you mean that ~/.terminfo doesn't work on that machines?

[Ray Kohler]

Post by James PIC

Post by Ray Kohler
- Will it implement enough of xterm's capabilities that I could lie
about $TERM and expect it to mostly work? I log into many remote
machines of various OS types and ages, and some of them don't make it
easy to install user-specific terminfo entries.

Do you mean that ~/.terminfo doesn't work on that machines?

I mean that I can't get sufficient access to write files in there. I
have "captive" access only, where my shell is replaced by a restricted
menu-driven app which doesn't allow me to write files into arbitrary
locations, not even under my home directory. (I also wouldn't be able
to set $TERMINFO anyway.)

There are also some rather broken machines that don't appear to have
tic installed.

[Anselm R Garbe]

Post by Ray Kohler
I'm rather curious on where st will go, and what kinds of things other
terminals do that it will or won't do.

Well my plan is to achieve *good* xterm compliance and 256 color
support. As you know xterm is not really fully vt100 or vt220
compliant, so that's also not a goal of st. Rather other features like
the integration of filters that can listen to the terminal output and
do certain things like changing the background color, to experiment
with some ideas like having different colors depending on the
directory/host you are in, or the planned st server that keeps
terminal sessions survive X shutdowns.

Post by Ray Kohler
- Is a scrollback buffer objectionable in principle, such that we
should expect to "just use GNU screen"?

Yes, though there must be an upper limit configurable, where 0 means
no limit, or until the process can't increase the buffer using
malloc() anymore...

Post by Ray Kohler
- Will it implement enough of xterm's capabilities that I could lie
about $TERM and expect it to mostly work? I log into many remote
machines of various OS types and ages, and some of them don't make it
easy to install user-specific terminfo entries.

See above, I plan to support that.

Kind regards,
Anselm

[Aurélien Aptel]

Post by Anselm R Garbe

Post by Ray Kohler
I'm rather curious on where st will go, and what kinds of things other
terminals do that it will or won't do.

Well my plan is to achieve *good* xterm compliance and 256 color
support. As you know xterm is not really fully vt100 or vt220
compliant, so that's also not a goal of st.

Full xterm support will be difficult. There are lots of features in
its terrible source code. Just check the official README, it's kind of

Post by Anselm R Garbe
Abandon All Hope, Ye Who Enter Here
This is undoubtedly the most ugly program in the distribution. It was one of
the first "serious" programs ported, and still has a lot of historical baggage.
Ideally, there would be a general tty widget and then vt102 and tek4014
subwidgets so that they could be used in other programs. We are trying to
clean things up as we go, but there is still a lot of work to do.

Post by Ray Kohler
- Is a scrollback buffer objectionable in principle, such that we
should expect to "just use GNU screen"?

IMHO the scrollback buffer is useless since you can use different
tools (as you said) to achieve that ($PAGER, screen, etc).

Post by Anselm R Garbe

Post by Ray Kohler
- Will it implement enough of xterm's capabilities that I could lie
about $TERM and expect it to mostly work? I log into many remote
machines of various OS types and ages, and some of them don't make it
easy to install user-specific terminfo entries.

GNU screen handle this by fallbacking to vt100. See
<http://www.slac.stanford.edu/comp/unix/package/epics/extensions/iocConsole/screen.1.html#lbAN>

[Uriel]

On Sun, Aug 23, 2009 at 11:41 PM, Aurélien

Post by Aurélien Aptel

Post by Anselm R Garbe

Post by Ray Kohler
I'm rather curious on where st will go, and what kinds of things other
terminals do that it will or won't do.

Well my plan is to achieve *good* xterm compliance and 256 color
support. As you know xterm is not really fully vt100 or vt220
compliant, so that's also not a goal of st.

Full xterm support will be difficult. There are lots of features in
its terrible source code. Just check the official README, it's kind of

Never mind garbeam, he is being delusional as usual.

uriel

Post by Aurélien Aptel

Post by Anselm R Garbe
                       Abandon All Hope, Ye Who Enter Here
This is undoubtedly the most ugly program in the distribution.  It was one of
the first "serious" programs ported, and still has a lot of historical baggage.
Ideally, there would be a general tty widget and then vt102 and tek4014
subwidgets so that they could be used in other programs.  We are trying to
clean things up as we go, but there is still a lot of work to do.

Post by Ray Kohler
- Is a scrollback buffer objectionable in principle, such that we
should expect to "just use GNU screen"?

IMHO the scrollback buffer is useless since you can use different
tools (as you said) to achieve that ($PAGER, screen, etc).

Post by Anselm R Garbe

Post by Ray Kohler
- Will it implement enough of xterm's capabilities that I could lie
about $TERM and expect it to mostly work? I log into many remote
machines of various OS types and ages, and some of them don't make it
easy to install user-specific terminfo entries.

GNU screen handle this by fallbacking to vt100. See
<http://www.slac.stanford.edu/comp/unix/package/epics/extensions/iocConsole/screen.1.html#lbAN>

[Anselm R Garbe]

Post by Aurélien Aptel

Post by Anselm R Garbe

Post by Ray Kohler
I'm rather curious on where st will go, and what kinds of things other
terminals do that it will or won't do.

Well my plan is to achieve *good* xterm compliance and 256 color
support. As you know xterm is not really fully vt100 or vt220
compliant, so that's also not a goal of st.

Full xterm support will be difficult. There are lots of features in
its terrible source code. Just check the official README, it's kind of

There is no plan to achieve full xterm support. I know that good xterm
support is kind of vague.

Post by Aurélien Aptel

Post by Anselm R Garbe
                       Abandon All Hope, Ye Who Enter Here
This is undoubtedly the most ugly program in the distribution.  It was one of
the first "serious" programs ported, and still has a lot of historical baggage.
Ideally, there would be a general tty widget and then vt102 and tek4014
subwidgets so that they could be used in other programs.  We are trying to
clean things up as we go, but there is still a lot of work to do.

To the xterm folks: Let me suggest to scrap the entire project and do
it from scratch ;)

Kind regards,
Anselm

[Ray Kohler]

Post by Anselm R Garbe

Post by Ray Kohler
I'm rather curious on where st will go, and what kinds of things other
terminals do that it will or won't do.

Well my plan is to achieve *good* xterm compliance and 256 color
support. As you know xterm is not really fully vt100 or vt220
compliant, so that's also not a goal of st. Rather other features like
the integration of filters that can listen to the terminal output and
do certain things like changing the background color, to experiment
with some ideas like having different colors depending on the
directory/host you are in, or the planned st server that keeps
terminal sessions survive X shutdowns.

I love the server idea. I'm using urxvtd now, and it's already very
nice. A persistent server like you propose is something I never even
thought of.

Post by Anselm R Garbe

Post by Ray Kohler
- Is a scrollback buffer objectionable in principle, such that we
should expect to "just use GNU screen"?

Yes, though there must be an upper limit configurable, where 0 means
no limit, or until the process can't increase the buffer using
malloc() anymore...

Unlimited scrollback is one of the few things I miss from my OS X
days. (Of course, the Mac Terminal's scrollback is rather broken, so I
don't miss it that much...)

In general, you're making st sound much more interesting than I hoped
it would be. I was expecting an ultra-bare-bones terminal - something
like the terminal equivalent of surf. An ultra-smart terminal is even
better :)

[Valentin]

Post by Anselm R Garbe
the planned st server that keeps
terminal sessions survive X shutdowns.

Isn't that what screen's there for? :P

[Jason Thigpen]

Post by Valentin

Post by Anselm R Garbe
the planned st server that keeps
terminal sessions survive X shutdowns.

Isn't that what screen's there for? :P

If that is all you use screen for, you should probably be using dtach.

http://dtach.sourceforge.net/

[Alexander Polakov]

Yep, I dont see why we should delegate scrolling to screen. screen is
bloated GNU
software and i dont want to relay on it.

tmux is here for those who hate GNU stuff.

[Val Polyakov]

Post by Alexander Polakov

Yep, I dont see why we should delegate scrolling to screen. screen is
bloated GNU
software and i dont want to relay on it.

tmux is here for those who hate GNU stuff.

what's wrong with GNU stuff?

I mean - why hate it? :)

[Kurt H Maier]

Post by Val Polyakov
what's wrong with GNU stuff?
I mean - why hate it? :)

autotools
libtool

the list continues for about as long as gnu's catalogue

[hiro]

it sucks.

Post by Val Polyakov

Post by Alexander Polakov

Yep, I dont see why we should delegate scrolling to screen. screen is
bloated GNU
software and i dont want to relay on it.

tmux is here for those who hate GNU stuff.

what's wrong with GNU stuff?
I mean - why hate it? :)

[Szabolcs Nagy]

Post by Val Polyakov

Post by Alexander Polakov

Yep, I dont see why we should delegate scrolling to screen. screen is
bloated GNU
software and i dont want to relay on it.

tmux is here for those who hate GNU stuff.

what's wrong with GNU stuff?

the point is the 'bloat' not the 'gnu' part, although there often seem
to be a correlation between these..

browsing through the philosophy page on gnu.org there are hardly any
mentions about quality, reliability and security disciplines in
software development, they have different objectives and focus on
different matters

i think producing, distributing, publicizing free software is nice,
but not enough. there are important issues which gnu does not address
properly. an illustrative example is the gnu hello world program and
the gnu coding standard which in many ways is the opposite of the
suckless approach.

one has to get his goals right to achieve satisfying results

[Ammar James]

As long as I can get that term to be slightly transparent so I can see
all my slick wallpapers I use with dwm, then I'll be happy.

Everything else is really just a bonus.

[Uriel]

Post by Ammar James
As long as I can get that term to be slightly transparent so I can see
all my slick wallpapers I use with dwm, then I'll be happy.
Everything else is really just a bonus.

This is sarcasm, I hope, I can never tell with all the retards out there...

uriel

[Uriel]

Post by Val Polyakov

Post by Alexander Polakov

Yep, I dont see why we should delegate scrolling to screen. screen is
bloated GNU
software and i dont want to relay on it.

tmux is here for those who hate GNU stuff.

what's wrong with GNU stuff?

Wrong question.

What is *right* with GNU?

Post by Val Polyakov
I mean - why hate it? :)

Because it is a disease.

Peace

uriel

[Jordi Marine]

Maybe you can try Task Spooler [1], it do some of the thinks you want
and its very confortable.

--
jordi

[1] http://vicerveza.homeunix.net/~viric/soft/ts/

Yep, I dont see why we should delegate scrolling to screen. screen is
bloated GNU
software and i dont want to relay on it.
Another random idea for 'st' would be to redirect the IO of the terminal to
a file.
Something like piping shell applications but integrated on X. Like
overlapping buffers
thru different filter applications. This can be useful to grep the
scrolling buffer for
words, or less it, etc.. this will simplify the implementation of the
scrolling by
delegating the task to another application like more/grep/less/nl, etc...
Some years ago I thought it would be possible to hook pipes in runtime and
graphically,
that is, linking the output of a terminal to the input of another one, and
be able to bind
scrolls between them (like in vim:scrollbind). I think that this maybe a
little complex, but
by discussing with more people we can probably reach a decent solution and
new ideas
to play with st.
About the buffer size, its ok to refer as it as in bytes, but st should
keep a pointer
to the beggining of the oldest line, because we would like to keep lines
and not
part of them.
BTW i really like the background-color change idea. I would probably use it
manually
instead of at automatically, but would be good to test.
--pancake

Post by Valentin
Isn't that what screen's there for? :P

if only screen's interface for scrolling back wasn't ridiculously
uncomfortable. IMHO shift+pgup/pgdn, and horribile dictu mousewheel
scrolling are essential. On the other hand, regex search forward
backward etc would be convenient, also keyboard-based text selection
(connected to the X clipboard, which again screen cannot do).
Regards,
Mate

[Jacob Todd]

Going through the st goals / non-goals thread I've compiled this list of:

What st is going to do so far (Arg said so):
- *good* xterm compliance
- 256 colour support
- filters that change colour and shit
- server to save session in case you crash X
- unlimited scroll back buffer

and

What people want added:
- redirect the IO of the terminal to a file. (pancake)
- st should keep a pointer to the beggining of the oldest line, because we would
like to keep lines and not part of them. (pancake)
- edit previous text in the terminal like in Plan 9 and 9term (me(jt_))
- some more stuff

Goals:
- suck less

Non-goals:
- ??

Add what you want. Maybe I should make a wiki page in st.suckless.org for this?

[Rory McCann]

I just tried out ST, it seems to have very bad flickering issues just now. ls-ing a large directory made it go horrible and vim was unusable.
A feature I would like is clickable-links, that would be excellent.

Post by Jacob Todd
- *good* xterm compliance
- 256 colour support
- filters that change colour and shit
- server to save session in case you crash X
- unlimited scroll back buffer
and
- redirect the IO of the terminal to a file. (pancake)
- st should keep a pointer to the beggining of the oldest line, because we would
like to keep lines and not part of them. (pancake)
- edit previous text in the terminal like in Plan 9 and 9term (me(jt_))
- some more stuff
- suck less
- ??
Add what you want. Maybe I should make a wiki page in st.suckless.org for this?
--
Jake Todd
// If it isn't broke, tweak it!

[Aurélien Aptel]

Post by Rory McCann
I just tried out ST, it seems to have very bad flickering issues just now. ls-ing a large directory made it go horrible and vim was unusable.

We have to use pixmaps to draw faster (I'm working on this) and handle utf8.
Vim seems pretty usable to me. Did you compile the terminfo entry ?

At this point, tracking buggy escape sequence is hard because visual
glitches don't automatically points to faulty escapes handler.

Post by Rory McCann

Post by Jacob Todd
- *good* xterm compliance
- 256 colour support
- filters that change colour and shit
- server to save session in case you crash X
- unlimited scroll back buffer
and
- redirect the IO of the terminal to a file. (pancake)
- st should keep a pointer to the beggining of the oldest line, because we would
  like to keep lines and not part of them. (pancake)
- edit previous text in the terminal like in Plan 9 and 9term (me(jt_))
- some more stuff
- suck less
- ??
Add what you want. Maybe I should make a wiki page in st.suckless.org for this?

[Luka Novsak]

Post by Rory McCann
A feature I would like is clickable-links, that would be excellent.

And some way to open links without using the mouse would be nice too.

[Moritz Wilhelmy]

Post by Luka Novsak

Post by Rory McCann
A feature I would like is clickable-links, that would be excellent.

And some way to open links without using the mouse would be nice too.

sounds fine. Maybe with a keybinding and adding numbers to the link like vimperator does.

[Julien Steinhauser]

Post by Moritz Wilhelmy

Post by Luka Novsak
And some way to open links without using the mouse would be nice too.

sounds fine. Maybe with a keybinding and adding numbers to the link like vimperator does.

Lynx-cur has also the numbering link feature as an option and doesn't use
javascript for that as vimperator does.

[Mate Nagy]

Post by Julien Steinhauser

Post by Moritz Wilhelmy
sounds fine. Maybe with a keybinding and adding numbers to the link like vimperator does.

Lynx-cur has also the numbering link feature as an option and doesn't use
javascript for that as vimperator does.

the best thing about vimperator though (which makes it usable as
opposed to everything else with this approach) that you don't have to
type in the number; you can just type a few characters of the link text,
and it'll filter the suitable link candidates with each character
interactively. It'll also renumber the candidates in each step, so the
usual process is to type a few characters of the link then type in a
final 1 digit number to choose, or just press enter on the default
selection.

The point is that typing a few characters of a link is faster than
typing a few numbers, because there's one less brain-processing step
involved - you don't actually have to read the number. This has a
perceptible time overhead.

Regards,
Mate

[s***@cs.tu-berlin.de]

Post by Mate Nagy

Post by Julien Steinhauser

Post by Moritz Wilhelmy
sounds fine. Maybe with a keybinding and adding numbers to the link like vimperator does.

Lynx-cur has also the numbering link feature as an option and doesn't use
javascript for that as vimperator does.

the best thing about vimperator though (which makes it usable as
opposed to everything else with this approach) that you don't have to
type in the number; you can just type a few characters of the link text,
and it'll filter the suitable link candidates with each character
interactively. It'll also renumber the candidates in each step, so the
usual process is to type a few characters of the link then type in a
final 1 digit number to choose, or just press enter on the default
selection.
The point is that typing a few characters of a link is faster than
typing a few numbers, because there's one less brain-processing step
involved - you don't actually have to read the number. This has a
perceptible time overhead.

I usually start lynx with -nonumbers. So, a comparable approach is to type
`/` , then part of the link, then couple of times `n` and/or `N` until I
come to the desired item (last step optionally and usually not) and press
Enter. AKA (forward) search. :o)

Couple of keystrokes more, but does the job.

What I really miss from vimperator is the ability to change matching
strategies [1]. Then I'll be perfectly happy.

[1] for non-(or non-ex-)vimperator users: besides the default
behaviour, called `contains`, there are different strategies for matching
the typed text against the available links, e.g. `wordstartswith`
considering the typed search string as a concatenation of begins_with
substrings of the words of the link text. Example: `clhiysmo` matches
`click here if you suck more'

cheers

[Julien Steinhauser]

Post by s***@cs.tu-berlin.de

Post by Mate Nagy

Post by Julien Steinhauser

Post by Moritz Wilhelmy
sounds fine. Maybe with a keybinding and adding numbers to the link like vimperator does.

Lynx-cur has also the numbering link feature as an option and doesn't use
javascript for that as vimperator does.

the best thing about vimperator though (which makes it usable as
opposed to everything else with this approach) that you don't have to
type in the number; you can just type a few characters of the link text,
and it'll filter the suitable link candidates with each character
interactively. It'll also renumber the candidates in each step, so the
usual process is to type a few characters of the link then type in a
final 1 digit number to choose, or just press enter on the default
selection.
The point is that typing a few characters of a link is faster than
typing a few numbers, because there's one less brain-processing step
involved - you don't actually have to read the number. This has a
perceptible time overhead.

I usually start lynx with -nonumbers. So, a comparable approach is to type
`/` , then part of the link, then couple of times `n` and/or `N` until I
come to the desired item (last step optionally and usually not) and press
Enter. AKA (forward) search. :o)
Couple of keystrokes more, but does the job.
What I really miss from vimperator is the ability to change matching
strategies [1]. Then I'll be perfectly happy.
[1] for non-(or non-ex-)vimperator users: besides the default
behaviour, called `contains`, there are different strategies for matching
the typed text against the available links, e.g. `wordstartswith`
considering the typed search string as a concatenation of begins_with
substrings of the words of the link text. Example: `clhiysmo` matches
`click here if you suck more'
cheers
--
stanio_

You might be right for brain processing, but until now with numbers,
I haven't seen a web page which requested more than 3 keystrokes to follow
a link.
I'll try your method and do brain benchmarks.

[Richard Pöttler]

Post by Jacob Todd
- *good* xterm compliance
- 256 colour support
- filters that change colour and shit
- server to save session in case you crash X
- unlimited scroll back buffer
and
- redirect the IO of the terminal to a file. (pancake)
- st should keep a pointer to the beggining of the oldest line, because we would
like to keep lines and not part of them. (pancake)
- edit previous text in the terminal like in Plan 9 and 9term (me(jt_))
- some more stuff

The things I want from a terminal is utf-8 support. Or is that only a
font problem?
For me also speed and the scrollback buffer are important.

What do you think about transparency? I think it might collide with the
suckless-goal and decrease speed.

bye
richi

[Antoni Grzymala]

Post by Richard Pöttler
What do you think about transparency? I think it might collide with
the suckless-goal and decrease speed.

When you read a newspaper or a book do you like it to be
semi-transparent as well? I never understood the urge for translucent
terminals...

[Tadeusz Sośnierz]

Post by Antoni Grzymala

Post by Richard Pöttler
What do you think about transparency? I think it might collide with
the suckless-goal and decrease speed.

When you read a newspaper or a book do you like it to be
semi-transparent as well? I never understood the urge for translucent
terminals...

I'd actually like it, so I can walk the street with a newspaper in front
of my eyes. Anyway, I think it's a matter of taste. Wouldn't it be a better
idea to leave transparency to some composition manager, like xcompmgr? I
don't whether it works or not, but afair it can make windows transparent.
Regards
Ted

[Uriel]

Post by Antoni Grzymala

Post by Richard Pöttler
What do you think about transparency? I think it might collide with
the suckless-goal and decrease speed.

When you read a newspaper or a book do you like it to be
semi-transparent as well? I never understood the urge for translucent
terminals...

It is very easy to understand once you realize most people are *idiots*.

uriel

Post by Antoni Grzymala
--
[a]

[Aurélien Aptel]

On Wed, Oct 7, 2009 at 12:15 PM, Richard Pöttler

The things I want from a terminal is utf-8 support. Or is that only a font
problem?

The problem is that utf-8 strings contain multibyte characters. And as
of now, each byte read = a character on the screen.

For me also speed and the scrollback buffer are important.

Characters are now drawn with XDrawImageString instead of XDrawString.
The drawing routine has also been optimized but I've not commited yet.
It's pretty fast so far (I'm using aafire to benchmark).

What do you think about transparency? I think it might collide with the
suckless-goal and decrease speed.

Transparency is useless.

[Moritz Wilhelmy]

Post by Aurélien Aptel
On Wed, Oct 7, 2009 at 12:15 PM, Richard Pöttler

Post by Richard Pöttler
What do you think about transparency? I think it might collide with the
suckless-goal and decrease speed.

Transparency is useless.

Not only useless but also evil: Loading Image...
Regards

[hiro]

This is the era of Destructivism.

On Wed, Oct 7, 2009 at 9:00 PM, Moritz Wilhelmy

Post by Moritz Wilhelmy

Post by Aurélien Aptel
On Wed, Oct 7, 2009 at 12:15 PM, Richard Pöttler

Post by Richard Pöttler
What do you think about transparency? I think it might collide with the
suckless-goal and decrease speed.

Transparency is useless.

Not only useless but also evil: http://www.xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg
Regards

[Ammar James]

All you people who are against transparency are like all those BSD
folk on Freenode who troll you for wanting a colorized ls output.

Unbelievable.

[Kurt H Maier]

Post by Ammar James
All you people who are against transparency are like all those BSD
folk on Freenode who troll you for wanting a colorized ls output.
Unbelievable.

I agree. How else do they expect me to see my half-naked anime ninja
cat-girl wallpaper? I mean I know I can mousewheel the opacity down
if I hover on the titlebar, but sometimes that's just too much work!
Plus I can't afford the context-switching; that just slows down my dev
work on my php-powered social networking project for school. Aside
from that, I need to get *quick* access to my 800x600-pixel conky
status display -- I like to manually type 'sync' just to watch the i/o
number spike for a second. Anyway it's late and my mom just IMed me to
go to bed, so I'll just fire this e-mail off and get psyched about the
upcoming Windows 2000 release. It's a good thing I'm a teenager in
the late nineties, because otherwise I sure would feel dumb for caring
so much about wasteful stupid garbage like terminal transparency!

[Antoni Grzymala]

Post by Kurt H Maier

Post by Ammar James
All you people who are against transparency are like all those BSD
folk on Freenode who troll you for wanting a colorized ls output.

I don't see how a transparent (less readable) text area is relevant to a
colorized syntax-highlighted code or logfile (more readable).

Post by Kurt H Maier

Post by Ammar James
Unbelievable.

Isn't it? I still stand by the transparent newspaper analogy. It is
truly ubelievable newspapers aren't printed on translucent foil yet. NZ
and Australian banks are a step closer to world happiness -- they
started printing their banknotes on plastic, so that you can see bits of
what's underneath when you lay them on a counter.

Post by Kurt H Maier
I agree. How else do they expect me to see my half-naked anime ninja
cat-girl wallpaper? I mean I know I can mousewheel the opacity down
if I hover on the titlebar, but sometimes that's just too much work!
Plus I can't afford the context-switching; that just slows down my dev
work on my php-powered social networking project for school. Aside
from that, I need to get *quick* access to my 800x600-pixel conky
status display -- I like to manually type 'sync' just to watch the i/o
number spike for a second. Anyway it's late and my mom just IMed me to
go to bed, so I'll just fire this e-mail off and get psyched about the
upcoming Windows 2000 release. It's a good thing I'm a teenager in
the late nineties, because otherwise I sure would feel dumb for caring
so much about wasteful stupid garbage like terminal transparency!

So true. Makes me *almost have to* think you've been through it all
yourself. :)

Best,

PS. Excuse two responses in a single post. To a greener future!

[Szabolcs Nagy]

Post by Antoni Grzymala
Isn't it? I still stand by the transparent newspaper analogy. It is
truly ubelievable newspapers aren't printed on translucent foil yet. NZ

have you tried it?
walking around reading transparent newspaper does not sound convincing
i'm pretty sure it does not work if the paper has more than one page
or with low ambient lighting

[Antoni Grzymala]

Post by Szabolcs Nagy

Post by Antoni Grzymala
Isn't it? I still stand by the transparent newspaper analogy. It is
truly ubelievable newspapers aren't printed on translucent foil yet. NZ

have you tried it?
walking around reading transparent newspaper does not sound convincing
i'm pretty sure it does not work if the paper has more than one page
or with low ambient lighting

Isn't that exactly what I'm saying? Unless you mistook my sarcasm for
something I'm seriously...

[Robert C Corsaro]

Post by Szabolcs Nagy

Post by Antoni Grzymala
Isn't it? I still stand by the transparent newspaper analogy. It is
truly ubelievable newspapers aren't printed on translucent foil yet. NZ

have you tried it?
walking around reading transparent newspaper does not sound convincing
i'm pretty sure it does not work if the paper has more than one page
or with low ambient lighting

This is really funny. The sarcasm was pretty obvious to me.

[Jacob Todd]

So, whoever said they had a bunch of changes to st that fixed a bunch of stuff,
are you ever going to push those changes?

[Aurélien Aptel]

Here it is.

[Sergi Alvarez]

Post by Aurélien Aptel
Here it is.

What is it?

[Rory Rory]

You forgot to attach it?

Post by Aurélien Aptel
Here it is.

[Aurélien Aptel]

I pushed the changes back to the repo. Sorry for any confusion.
(seriously...)

Post by Rory Rory
You forgot to attach it?

Post by Aurélien Aptel
Here it is.

--
Rory

[Uriel]

Post by Ammar James
All you people who are against transparency are like all those BSD
folk on Freenode who troll you for wanting a colorized ls output.
Unbelievable.

I agree.  How else do they expect me to see my half-naked anime ninja
cat-girl wallpaper?  I mean I know I can mousewheel the opacity down
if I hover on the titlebar, but sometimes that's just too much work!
Plus I can't afford the context-switching; that just slows down my dev
work on my php-powered social networking project for school.  Aside
from that, I need to get *quick* access to my 800x600-pixel conky
status display -- I like to manually type 'sync' just to watch the i/o
number spike for a second. Anyway it's late and my mom just IMed me to
go to bed, so I'll just fire this e-mail off and get psyched about the
upcoming Windows 2000 release.  It's a good thing I'm a teenager in
the late nineties, because otherwise I sure would feel dumb for caring
so much about wasteful stupid garbage like terminal transparency!

Your satire is so good I almost believed you were being serious for a moment ^_^

You make me think that maybe there is hope for mankind after all...

Peace

uriel

--
# Kurt H Maier

[Uriel]

You mean there are actually people out there that are retarded and
brain-damaged enough to think that both transparent terminals and
colorized text are good ideas?

Why don't you take 100kg of food you collect from the garbage, have
somebody force-feed it to you, and then throw up all over your screen,
it will look just as pretty and be considerably less painful.

uriel

Post by Ammar James
All you people who are against transparency are like all those BSD
folk on Freenode who troll you for wanting a colorized ls output.
Unbelievable.

[Uriel]

On Wed, Oct 7, 2009 at 8:00 PM, Moritz Wilhelmy

Post by Moritz Wilhelmy

Post by Aurélien Aptel
On Wed, Oct 7, 2009 at 12:15 PM, Richard Pöttler

Post by Richard Pöttler
What do you think about transparency? I think it might collide with the
suckless-goal and decrease speed.

Transparency is useless.

Not only useless but also evil: http://www.xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg

Transparency is much worse than useless and evil, it is *STUPID*.

uriel

Post by Moritz Wilhelmy
Regards

[Moritz Wilhelmy]

Post by Richard Pöttler
What do you think about transparency? I think it might collide with the
suckless-goal and decrease speed.

Not only do they decrease speed and add lots of unneccessary lines of code
but also transparency makes the content unreadable and disturbs from reading
the window content.
Example: Loading Image...

So, I agree with uriel: transparency is for idiots.

[Anselm R Garbe]

Post by Moritz Wilhelmy

Post by Richard Pöttler
What do you think about transparency? I think it might collide with the
suckless-goal and decrease speed.

Not only do they decrease speed and add lots of unneccessary lines of code
but also transparency makes the content unreadable and disturbs from reading
the window content.
Example: http://xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg
So, I agree with uriel: transparency is for idiots.

When I was young I thought hey that looks cool (compared to the usual
terminals on Windows by that time). But when actually using it for a
while it hurts more and the coolness factor becomes obsolete sooner
than later. Perhaps the younger generation has better eyes and can
cope with it for a couple of years, but I haven't seen any serious
programmer that worked with translucent terminals very long...

Apart from that, all the other reasons (unnecessary complexity,
unnecessary cpu cycles, etc) are true and I agree.

Kind regards,
Anselm

[Anders Andersson]

Post by Anselm R Garbe

Post by Moritz Wilhelmy

Post by Richard Pöttler
What do you think about transparency? I think it might collide with the
suckless-goal and decrease speed.

Not only do they decrease speed and add lots of unneccessary lines of code
but also transparency makes the content unreadable and disturbs from reading
the window content.
Example: http://xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg
So, I agree with uriel: transparency is for idiots.

When I was young I thought hey that looks cool (compared to the usual
terminals on Windows by that time). But when actually using it for a
while it hurts more and the coolness factor becomes obsolete sooner
than later. Perhaps the younger generation has better eyes and can
cope with it for a couple of years, but I haven't seen any serious
programmer that worked with translucent terminals very long...
Apart from that, all the other reasons (unnecessary complexity,
unnecessary cpu cycles, etc) are true and I agree.
Kind regards,
Anselm

If you need the transparency, there are compositing window managers
that will do perfect transparency for any application you would like
to. Even if you *would* like to see everything at once, there's no
need to bloat down each application with it.

// Anders

[frederic]

Post by Anders Andersson

Post by Anselm R Garbe

Post by Moritz Wilhelmy
http://xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg

So sugar is evil, because if one eats too much of it, one may die.

Post by Anders Andersson

Post by Anselm R Garbe

Post by Moritz Wilhelmy
So, I agree with uriel: transparency is for idiots.

Often, drunk people seem to believe that other people are drunk.

Do yourself a favour: stop calling others idiots.

Post by Anders Andersson

Post by Anselm R Garbe
When I was young I thought hey that looks cool (compared to the usual
terminals on Windows by that time). But when actually using it for a
while it hurts more and the coolness factor becomes obsolete sooner
than later. Perhaps the younger generation has better eyes and can
cope with it for a couple of years, but I haven't seen any serious
programmer that worked with translucent terminals very long...

I think I'm not younger than you, and I have been working with translucent
terminals for about ten years on a daily basis.
I think the reason why I've been using them for so long is because I use
them more for the aesthetics than for the coolness factor.
Of course, my wallpaper doesn't show some lame anime character, insipid
landscape or kickass-y car.

Post by Anders Andersson

Post by Anselm R Garbe
Apart from that, all the other reasons (unnecessary complexity,
unnecessary cpu cycles, etc) are true and I agree.

I won't argue against that. Suckless software is nice, because it spares
some resources on my machine, so I can use translucent terminals :)

Post by Anders Andersson
If you need the transparency, there are compositing window managers
that will do perfect transparency for any application you would like
to.

Not exactly. Last time I tried, a compositing manager makes transparent
everything including writings, and performs true transparency. It is
significantly less comfortable than pseudo-transparency done by terminals
themselves. A comfortable translucent set up requires a accurate settings
in order to balance correctly eye-candy and easy reading.

[Kurt H Maier]

Post by frederic
So sugar is evil, because if one eats too much of it, one may die.

No, specious analogies are evil, because when you use any of them, you
sound stupid.

Post by frederic
Often, drunk people seem to believe that other people are drunk.

What?

Post by frederic
Do yourself a favour: stop calling others idiots.

No.

Post by frederic
I think I'm not younger than you, and I have been working with translucent
terminals for about ten years on a daily basis.
I think the reason why I've been using them for so long is because I use
them more for the aesthetics than for the coolness factor.

Aesthetics? Really? You've devoted effort to the aesthetics of your
terminal window? Maybe some nice drapes and little doric pilliars
will boost your productivity.

Post by frederic
A comfortable translucent set up requires a accurate settings in
order to balance correctly eye-candy and easy reading.

Drivel.

[frederic]

Post by frederic
Do yourself a favour: stop calling others idiots.

No.

Great, yet another Uriel.

[hiro]

And yet another idiot. Have fun...

Post by frederic

Post by frederic
Do yourself a favour: stop calling others idiots.

No.

Great, yet another Uriel.

[Aled Gest]

It would be nice to see a features thread that didn't degenerate into
a competition of who's the biggest cock.

While I can understand why transparency is a bad idea, people have the
freedom to want whatever they want. If the maintainers of the software
don't want a particular feature in vanilla, and a person requests a
particular feature, all the devs need to do is state that that feature
will not appear in the vanilla source.

The great thing about suckless software is that it's so easy to hack,
it's simple and unencumbered and that's how it should stay. If people
want to branch off or create a patch to extend the software with
features they desire that's their prerogative, that's the beauty of
suckless software. If I want the features of the software I use
dictated to me I'd stick with Windows, if I wanted how I use the
software dictated to me I'd stick with the GPL.

I think freedom is an essential goal of suckless software, as is an
open discussion of ideas. People shouldn't be berated for simply
discussing a feature. If you disagree with something that's fine, but
why degenerate into personal attacks?

Now, in keeping with the original theme of the thread:

A feature I wouldn't mind seeing in st would be the ability to spawn
st as a direct endpoint to a pipe (not sure if that's already
possible?). This would allow st to be used as a quick popup to display
information, or as part of a multi-terminal application like an irc
client, without needing to spawn an extra shell or consume an extra
pty.

Post by hiro
And yet another idiot. Have fun...

Post by frederic

Post by frederic
Do yourself a favour: stop calling others idiots.

No.

Great, yet another Uriel.

[Robert C Corsaro]

Take your hippy shit somewhere else. Retarded ideas will be met with
hostility here.

Post by Aled Gest
It would be nice to see a features thread that didn't degenerate into
a competition of who's the biggest cock.
While I can understand why transparency is a bad idea, people have the
freedom to want whatever they want. If the maintainers of the software
don't want a particular feature in vanilla, and a person requests a
particular feature, all the devs need to do is state that that feature
will not appear in the vanilla source.
The great thing about suckless software is that it's so easy to hack,
it's simple and unencumbered and that's how it should stay. If people
want to branch off or create a patch to extend the software with
features they desire that's their prerogative, that's the beauty of
suckless software. If I want the features of the software I use
dictated to me I'd stick with Windows, if I wanted how I use the
software dictated to me I'd stick with the GPL.
I think freedom is an essential goal of suckless software, as is an
open discussion of ideas. People shouldn't be berated for simply
discussing a feature. If you disagree with something that's fine, but
why degenerate into personal attacks?
A feature I wouldn't mind seeing in st would be the ability to spawn
st as a direct endpoint to a pipe (not sure if that's already
possible?). This would allow st to be used as a quick popup to display
information, or as part of a multi-terminal application like an irc
client, without needing to spawn an extra shell or consume an extra
pty.

Post by hiro
And yet another idiot. Have fun...

Post by frederic

Post by frederic
Do yourself a favour: stop calling others idiots.

No.

Great, yet another Uriel.

[Kurt H Maier]

People shouldn't be berated for simply discussing a feature.

People who support dumb things run the risk of mockery. I'd rather
get burned for suggesting something stupid than have this list turn
into a politically-correct hugbox support forum for the criminally
inept. If you don't like it, go hang out on another mailing list.

I'll mention here that I've altered some of my own opinions after
reading arguments on this list. The vehemence with which a person
defends a specific concept shows me how seriously they take that
concept. Similarly, the amount of whining done by someone re
ad-hominem attacks shows me that their priorities lie more toward
"internet community building" than "discussing things," so I know they

A feature I wouldn't mind seeing in st would be the ability to spawn
st as a direct endpoint to a pipe (not sure if that's already
possible?). This would allow st to be used as a quick popup to display
information, or as part of a multi-terminal application like an irc
client, without needing to spawn an extra shell or consume an extra
pty.

You want your terminal emulator to replace xmessage? Really?

[Aled Gest]

People who support dumb things run the risk of mockery.  I'd rather
get burned for suggesting something stupid than have this list turn
into a politically-correct hugbox support forum for the criminally
inept.  If you don't like it, go hang out on another mailing list.

Well if you really want me to make a point about how people who are
needlessly belligerent on inappropriate threads are evidently
incompetent at life, that's fine. I could have a field day nitpicking
the psychology of people who overcompensate for their own inferiority
by directing disproportionate aggression towards hapless randoms who
dare to suggest naive ideas. I just think development threads are more
productive when socially inept morons aren't derailing conversations
with fruitless personal attacks. You understand the inherent pitfalls
of fallacious behavior right?

You want your terminal emulator to replace xmessage?  Really?

No, I want a terminal emulator that can behave like a terminal
emulator. Last time I checked xmessage wasn't a terminal emulator.

[Kurt H Maier]

Post by Aled Gest
Well if you really want me to make a point about how people who are
needlessly belligerent on inappropriate threads are evidently
incompetent at life, that's fine. I could have a field day nitpicking
the psychology of people who overcompensate for their own inferiority
by directing disproportionate aggression towards hapless randoms who
dare to suggest naive ideas. I just think development threads are more
productive when socially inept morons aren't derailing conversations
with fruitless personal attacks. You understand the inherent pitfalls
of fallacious behavior right?

I'm sure you could have a ton of field days, describing for hours all
kinds of irrelevant crap. Maybe you can read a book about adapting to
different standards within different social groups instead of
lecturing to people who don't care. It's a mailing list. Calling
people stupid is not 'disproportionate aggression,' it's just calling
stupid people stupid. Sorry if your life has caused you to consider
honesty 'aggressive.'

Post by Aled Gest
No, I want a terminal emulator that can behave like a terminal
emulator. Last time I checked xmessage wasn't a terminal emulator.

Which extant terminal emulators behave the way your proposed
functionality describes?

[Aled Gest]

Post by Kurt H Maier
I'm sure you could have a ton of field days, describing for hours all
kinds of irrelevant crap.  Maybe you can read a book about adapting to
different standards within different social groups instead of
lecturing to people who don't care.  It's a mailing list.  Calling
people stupid is not 'disproportionate aggression,' it's just calling
stupid people stupid.  Sorry if your life has caused you to consider
honesty 'aggressive.'

Perhaps in your eagerness to overreact you missed the point I was
making, so I'll simplify it for you:

Filling development threads with "you're an idiot" ... "no you"
detracts from the thread's ability to develop.

Post by Kurt H Maier
Which extant terminal emulators behave the way your proposed
functionality describes?

In terms of using pipes to communicate with other programs, all of
them. In terms of doing so without consuming a PTY or spawning a child
process, none that I know of.

Are you suggesting that we shouldn't develop new software because no
existing software does what we want? I've seen no strict definition
specifying how a terminal emulator must communicate with other
processes. Whether it acts like a host process spawning a child and
communicating through a PTY, or gets spawned as a child process itself
reading and writing directly through pipes, it's still a terminal
emulator.

[Kurt H Maier]

Post by Aled Gest
In terms of doing so without consuming a PTY or spawning a child
process, none that I know of.
Are you suggesting that we shouldn't develop new software because no
existing software does what we want? I've seen no strict definition
specifying how a terminal emulator must communicate with other
processes. Whether it acts like a host process spawning a child and
communicating through a PTY, or gets spawned as a child process itself
reading and writing directly through pipes, it's still a terminal
emulator.

I'm suggesting that if you want two clearly distinct jobs done, and
they share a lot of similar code, you extract the duplicate code into
a library and then write two applications against that library. In
this case, we should wind up with st, which consumes PTYs and emulates
a terminal, and we should wind up with your thing, which still sounds
closer to dzen than a term app.

Loading up application code with disparate functionality isn't any good.

[Aled Gest]

Post by Kurt H Maier
I'm suggesting that if you want two clearly distinct jobs done, and
they share a lot of similar code, you extract the duplicate code into
a library and then write two applications against that library.

No you weren't.

Post by Kurt H Maier
 In this case, we should wind up with st, which consumes PTYs and emulates
a terminal, and we should wind up with your thing, which still sounds
closer to dzen than a term app.
Loading up application code with disparate functionality isn't any good.

I've got no problem with the terminal part of st being modularized and
being called from a separate stub that handles how it connects to
other processes.

The particular method I was thinking of to implement the functionality
I want would actually reduce the code complexity of st by removing the
code to allocate PTYs and spawn a child process.

If you removed the spawning code from st, to implement an xterm like
terminal you could have a separate program that allocates a PTY with
itself on the controlling end, and spawns st attached to the other
end, and then execs itself to a shell which inherits the controlling
end of the PTY. That way you've effectively got something that does
the same job, but you've removed complexity from st itself, and you've
increased flexibility.

[Kurt H Maier]

Post by Aled Gest
No you weren't.

My clarification of my position was exactly as connected to previous
statements as your accusation of the garbage you were spouting about
no new functionality or whatever. Incidentally, this thread now
stands as a counterexample to your hypothesis regarding the inability
of petty argument to coexist with useful development discussion.
Thanks for your help in this matter.

Post by Aled Gest
I've got no problem with the terminal part of st being modularized and
being called from a separate stub that handles how it connects to
other processes.

That would be necessary anyway if the 'st daemon' idea were to be implemented.

Post by Aled Gest
That way you've effectively got something that does
the same job, but you've removed complexity from st itself, and you've
increased flexibility.

More importantly, it allows the attachment of st frontends other than
xlib-based ones to the controlling process, meaning that there can be
directfb or console-based frontends, among other things.

[Moritz Wilhelmy]

Post by Kurt H Maier
More importantly, it allows the attachment of st frontends other than
xlib-based ones to the controlling process, meaning that there can be
directfb or console-based frontends, among other things.

Sounds like st will be a great project once it is working
I like the idea of splitting the pty part from core.

Regards

[Aled Gest]

Post by Kurt H Maier
My clarification of my position was exactly as connected to previous
statements as your accusation of the garbage you were spouting about
no new functionality or whatever.  Incidentally, this thread now
stands as a counterexample to your hypothesis regarding the inability
of petty argument to coexist with useful development discussion.
Thanks for your help in this matter.

Don't kid your self. The most recent suggestion you made had no
correlation to anything you said or implied in previous posts
pertaining to our debate.

Post by Kurt H Maier

Post by Aled Gest
I've got no problem with the terminal part of st being modularized and
being called from a separate stub that handles how it connects to
other processes.

That would be necessary anyway if the 'st daemon' idea were to be implemented.

Post by Aled Gest
That way you've effectively got something that does
the same job, but you've removed complexity from st itself, and you've
increased flexibility.

More importantly, it allows the attachment of st frontends other than
xlib-based ones to the controlling process, meaning that there can be
directfb or console-based frontends, among other things.

Exactly, improved flexibility / modularity that reduces code
complexity is win win in my book.

[Uriel]

Post by Aled Gest

Post by Kurt H Maier
I'm sure you could have a ton of field days, describing for hours all
kinds of irrelevant crap.  Maybe you can read a book about adapting to
different standards within different social groups instead of
lecturing to people who don't care.  It's a mailing list.  Calling
people stupid is not 'disproportionate aggression,' it's just calling
stupid people stupid.  Sorry if your life has caused you to consider
honesty 'aggressive.'

Perhaps in your eagerness to overreact you missed the point I was
Filling development threads with "you're an idiot" ... "no you"
detracts from the thread's ability to develop.

This might be true, but also sometimes the only proper way to react to
a stupid idea is to point out that it is stupid.

Post by Aled Gest

Post by Kurt H Maier
Which extant terminal emulators behave the way your proposed
functionality describes?

In terms of using pipes to communicate with other programs, all of
them. In terms of doing so without consuming a PTY or spawning a child
process, none that I know of.
Are you suggesting that we shouldn't develop new software because no
existing software does what we want? I've seen no strict definition
specifying how a terminal emulator must communicate with other
processes. Whether it acts like a host process spawning a child and
communicating through a PTY, or gets spawned as a child process itself
reading and writing directly through pipes, it's still a terminal
emulator.

That the concept of 'pty' still exists in the year 2009 is quite
fucking amazing. I'm surprised we don't carry punchcards around
anymore.

uriel

[Aurélien Aptel]

Post by Uriel

Post by Aled Gest
A feature I wouldn't mind seeing in st would be the ability to spawn
st as a direct endpoint to a pipe (not sure if that's already
possible?). This would allow st to be used as a quick popup to display
information, or as part of a multi-terminal application like an irc
client, without needing to spawn an extra shell or consume an extra
pty.

I also like this idea. And I think it's pretty easy to implement :
exec your program instead of the shell. You may have to hack a bit
with dup.

Post by Uriel

Post by Aled Gest
Are you suggesting that we shouldn't develop new software because no
existing software does what we want? I've seen no strict definition
specifying how a terminal emulator must communicate with other
processes. Whether it acts like a host process spawning a child and
communicating through a PTY, or gets spawned as a child process itself
reading and writing directly through pipes, it's still a terminal
emulator.

That the concept of 'pty' still exists in the year 2009 is quite
fucking amazing. I'm surprised we don't carry punchcards around
anymore.

I was thinking the exact same thing when I wrote the pty part.
They're not well documented, they're really dated and every OS handle
them differently (when they handle them at all), some functions are
POSIX, some of them BSD-only (but are implemented in linux...).

On a different subject, the current design of st is not really adapted
to the things it's supposed to do (see the goal page). When I started
st (originaly bt) I just wanted a simple terminal (simple as in simple
tiny and sane xterm replacement) but the suckless goals are obviously
different. So st will need a rewrite at some point. (thank you captain
obvious, etc)

[Uriel]

On Sat, Oct 31, 2009 at 11:11 AM, Aurélien Aptel

Post by Aurélien Aptel

Post by Uriel
That the concept of 'pty' still exists in the year 2009 is quite
fucking amazing. I'm surprised we don't carry punchcards around
anymore.

I was thinking the exact same thing when I wrote the pty part.
They're not well documented, they're really dated and every OS handle
them differently (when they handle them at all), some functions are
POSIX, some of them BSD-only (but are implemented in linux...).
On a different subject, the current design of st is not really adapted
to the things it's supposed to do (see the goal page). When I started
st (originaly bt) I just wanted a simple terminal (simple as in simple
tiny and sane xterm replacement) but the suckless goals are obviously
different. So st will need a rewrite at some point. (thank you captain
obvious, etc)

Nah, Arg just has no clue. Let him write his own terminal with his own
retarded 'features' if he wants one. I have not tried st, but I do
like your original goal.

uriel

[Uriel]

Post by Kurt H Maier

Post by Aled Gest
Well if you really want me to make a point about how people who are
needlessly belligerent on inappropriate threads are evidently
incompetent at life, that's fine. I could have a field day nitpicking
the psychology of people who overcompensate for their own inferiority
by directing disproportionate aggression towards hapless randoms who
dare to suggest naive ideas. I just think development threads are more
productive when socially inept morons aren't derailing conversations
with fruitless personal attacks. You understand the inherent pitfalls
of fallacious behavior right?

I'm sure you could have a ton of field days, describing for hours all
kinds of irrelevant crap.  Maybe you can read a book about adapting to
different standards within different social groups instead of
lecturing to people who don't care.  It's a mailing list.  Calling
people stupid is not 'disproportionate aggression,' it's just calling
stupid people stupid.  Sorry if your life has caused you to consider
honesty 'aggressive.'

I disagree, there *is* "disproportionate aggression" in this list, I
at least try to be disproportionately "aggressive". There is nothing
wrong with this, it is exercising the most fundamental human right:
free speech. As for its purpose, I agree that in some cases it is
probably counter-productive, but that is for the "aggressive" person
to worry about, and I still think that in some cases it can be a
useful rhetorical technique to bring attention to something that might
pass unnoticed otherwise.

tl;dr: Being an asshole can be a good way to make a point. (Not to say
that I'm good at it, but I'm trying to improve my asshole-skills.)

Post by Kurt H Maier

Post by Aled Gest
No, I want a terminal emulator that can behave like a terminal
emulator. Last time I checked xmessage wasn't a terminal emulator.

Which extant terminal emulators behave the way your proposed
functionality describes?

I have no clue, but you wanted to use a program that behaves like
existing programs, why don't you use the existing programs?

Reading from stdin is a basic and fundamental Unix design, and should
be applied where it makes sense, I think it makes quite a bit of sense
here.

uriel

[Uriel]

Post by Aled Gest

People who support dumb things run the risk of mockery.  I'd rather
get burned for suggesting something stupid than have this list turn
into a politically-correct hugbox support forum for the criminally
inept.  If you don't like it, go hang out on another mailing list.

Well if you really want me to make a point about how people who are
needlessly belligerent on inappropriate threads are evidently
incompetent at life, that's fine. I could have a field day nitpicking
the psychology of people who overcompensate for their own inferiority
by directing disproportionate aggression towards hapless randoms who
dare to suggest naive ideas. I just think development threads are more
productive when socially inept morons aren't derailing conversations
with fruitless personal attacks. You understand the inherent pitfalls
of fallacious behavior right?

You are learning well... the dark side of the force is strong with you.

(Ok, I suck at quoting Star Wars, whatever, it is a retarded film anyway ;P)

Post by Aled Gest

You want your terminal emulator to replace xmessage?  Really?

No, I want a terminal emulator that can behave like a terminal
emulator. Last time I checked xmessage wasn't a terminal emulator.

Then buy yourself a typewriter.

uriel

[Jacob Todd]

Post by Aled Gest
the psychology of people who overcompensate for their own inferiority

Psychology is pseudo-science.

[Moritz Wilhelmy]

Post by Kurt H Maier
You want your terminal emulator to replace xmessage? Really?

xmessage can read from pipes?

I like the idea of adding this feature to st... but maybe it should be
done by adding a patch to st.

Best Regards
Moritz

[Kurt H Maier]

Post by Moritz Wilhelmy
xmessage can read from pipes?

Yes.

[Nicolai Waniek]

Post by Moritz Wilhelmy
xmessage can read from pipes?

make xmessage read from stdin with the "-file -" option, e.g.
echo "mmh" | xmessage -file -

regards,
Nicolai

[Uriel]

Post by Aled Gest
A feature I wouldn't mind seeing in st would be the ability to spawn
st as a direct endpoint to a pipe (not sure if that's already
possible?). This would allow st to be used as a quick popup to display
information, or as part of a multi-terminal application like an irc
client, without needing to spawn an extra shell or consume an extra
pty.

You want your terminal emulator to replace xmessage?  Really?

Actually I think this a good idea, xmessage is awful, and the job of a
sane terminal is to display text, so a sane terminal should be able to
simply and elegantly replace xmessage. (In Plan 9 rio windows are used
to display text for example during the installer, a cool thing is that
you can actually dynamically update the text in another window from a
script.)

uriel

[Nils]

Post by Aled Gest
It would be nice to see a features thread that didn't degenerate into
a competition of who's the biggest cock.

Thank you for this post.

If I look at the rest of this discussion it really makes me wonder why
I'm still subscribed to this mailing list.

[Andrew Antle]

Post by Nils

Post by Aled Gest
It would be nice to see a features thread that didn't degenerate into
a competition of who's the biggest cock.

Thank you for this post.
If I look at the rest of this discussion it really makes me wonder why
I'm still subscribed to this mailing list.

Because it's hilarious! Especially when Lamb Sandwich starts whining.

[Nils]

Post by Andrew Antle
Because it's hilarious! Especially when Lamb Sandwich starts whining.

It's nothing but arrogant, unfriendly and wannabe-elitist to talk like
this on a public mailing list.

And I'm not even going to respond to Uriels mails.

[Jessta]

Post by Nils

Post by Andrew Antle
Because it's hilarious! Especially when Lamb Sandwich starts whining.

It's nothing but arrogant, unfriendly and wannabe-elitist to talk like
this on a public mailing list.

But totally hilarious.
Most people don't like being told they are wrong, so challenging
people to defend their ideas means they'll put more work in to making
you understand their idea to try to make you change your mind.
The more aggressive your challenge, the effort they'll put in to defence.
It's a good way to discuss things with random people and this mailing
list does it really well.

[A.J. Gardner]

Post by Jessta

Post by Nils

Post by Andrew Antle
Because it's hilarious! Especially when Lamb Sandwich starts whining.

It's nothing but arrogant, unfriendly and wannabe-elitist to talk like
this on a public mailing list.

But totally hilarious.
Most people don't like being told they are wrong, so challenging
people to defend their ideas means they'll put more work in to making
you understand their idea to try to make you change your mind.
The more aggressive your challenge, the effort they'll put in to defence.
It's a good way to discuss things with random people and this mailing
list does it really well.

Some of the most morbidly fascinating highlights from this mailing
list: 1) some people respond enthusiastically and with great vitriol
to innocent-yet-ignorant comments, 2) they relentlessly pursue an
"ignorant" poster with pointless berating as if they'll convince
anyone of anything, 3) they defend this behavior as if it's actually
helpful, and 4) they have little to no concern for the wasted time of
the people who have to sift through their garbage to get to anything
relevant or helpful.

Yes, Uriel: we all have delete functionality. However, it's not the
responsibility of subscribers to waste their time deleting
non-dev-related emails. Just stop sending them.

It is my humble opinion that the [dev] mailing list contributors just
stick to [dev]-related topics. Please stop responding to emails as if
this is Reddit. Yes, we know--you've got something snarky to say,
someone hurt your feelings, you know things about stuff and feel
compelled to share, and everyone should conform to the way you think
about the world. But no one cares. So don't even bother sending that
email unless it's about development.

I subscribed so I could learn something about software development,
not about how badly some of you communicate.

[Uriel]

Post by Nils

Post by Aled Gest
It would be nice to see a features thread that didn't degenerate into
a competition of who's the biggest cock.

Thank you for this post.
If I look at the rest of this discussion it really makes me wonder why
I'm still subscribed to this mailing list.

There is no law that requires you to read every post sent to a maling
list. Also, I'm sure no matter how retarded your mail client is, it
has a delete function.

uriel

[Moritz Wilhelmy]

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe

Post by Moritz Wilhelmy
http://xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg

So sugar is evil, because if one eats too much of it, one may die.

Post by Anders Andersson

Post by Anselm R Garbe

Post by Moritz Wilhelmy
So, I agree with uriel: transparency is for idiots.

Often, drunk people seem to believe that other people are drunk.
Do yourself a favour: stop calling others idiots.

Post by Anders Andersson

Post by Anselm R Garbe
When I was young I thought hey that looks cool (compared to the usual
terminals on Windows by that time). But when actually using it for a
while it hurts more and the coolness factor becomes obsolete sooner
than later. Perhaps the younger generation has better eyes and can
cope with it for a couple of years, but I haven't seen any serious
programmer that worked with translucent terminals very long...

I think I'm not younger than you, and I have been working with
translucent terminals for about ten years on a daily basis.
I think the reason why I've been using them for so long is because I use
them more for the aesthetics than for the coolness factor.
Of course, my wallpaper doesn't show some lame anime character, insipid
landscape or kickass-y car.

Post by Anders Andersson

Post by Anselm R Garbe
Apart from that, all the other reasons (unnecessary complexity,
unnecessary cpu cycles, etc) are true and I agree.

I won't argue against that. Suckless software is nice, because it spares
some resources on my machine, so I can use translucent terminals :)

Post by Anders Andersson
If you need the transparency, there are compositing window managers
that will do perfect transparency for any application you would like
to.

Not exactly. Last time I tried, a compositing manager makes transparent
everything including writings, and performs true transparency. It is
significantly less comfortable than pseudo-transparency done by terminals
themselves. A comfortable translucent set up requires a accurate settings
in order to balance correctly eye-candy and easy reading.

I doubt st will implement transparency for obvious reasons, so if you want
transparency use either $compositing_wm or another terminal.

I personally don't like transparent terminals and I don't think they add any-
thing to my coolness factor (and they aren't even for). If I'd like to impress
people with how cool linux is I would use KDE4 or gnome whatever.

This thread is about the features st should implement and transparency surely
is a thing that shouldn't be implemented by st, so we should probably abandon
this topic.

Best Regards
Moritz

[frederic]

Post by Moritz Wilhelmy
This thread is about the features st should implement and transparency
surely is a thing that shouldn't be implemented by st, so we should
probably abandon this topic.

I totally agree that transparency shouldn't be part of the features of st,
althought I do use transparent. I thought that a point of view more
elaborate than "transparency is for idiots" and such could be of some
interest.

[Uriel]

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe

Post by Moritz Wilhelmy
http://xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg

So sugar is evil, because if one eats too much of it, one may die.

And make the world a better place as a result.

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe

Post by Moritz Wilhelmy
So, I agree with uriel: transparency is for idiots.

Often, drunk people seem to believe that other people are drunk.

And often idiots are just idiots.

Post by frederic
Do yourself a favour: stop calling others idiots.

Do yourself and the world a favour and go use Gnome, or even better OS X.

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe
When I was young I thought hey that looks cool (compared to the usual
terminals on Windows by that time). But when actually using it for a
while it hurts more and the coolness factor becomes obsolete sooner
than later. Perhaps the younger generation has better eyes and can
cope with it for a couple of years, but I haven't seen any serious
programmer that worked with translucent terminals very long...

I think I'm not younger than you, and I have been working with translucent
terminals for about ten years on a daily basis.

And now we have conclusive evidence that using translucent terminals
for extended periods of time damages the brain!

Thanks for sacrificing yourself as guinea pig for this essential and
fascinating scientific research project.

Post by frederic
I think the reason why I've been using them for so long is because I use
them more for the aesthetics than for the coolness factor.
Of course, my wallpaper doesn't show some lame anime character, insipid
landscape or kickass-y car.

What have you got as wallpaper? A picture of your but?

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe
Apart from that, all the other reasons (unnecessary complexity,
unnecessary cpu cycles, etc) are true and I agree.

I won't argue against that. Suckless software is nice, because it spares
some resources on my machine, so I can use translucent terminals :)

Post by Anders Andersson
If you need the transparency, there are compositing window managers
that will do perfect transparency for any application you would like
to.

Not exactly. Last time I tried, a compositing manager makes transparent
everything including writings, and performs true transparency. It is
significantly less comfortable than pseudo-transparency done by terminals
themselves. A comfortable translucent set up requires a accurate settings in
order to balance correctly eye-candy and easy reading.

I know that many enjoy so much the mental-masturbatory process of
configuring and "tuning" their desktops to death, but some of us
managed to outgrow our pre-adolescent vices and actually use computers
to get work done, hell, or even to have *actual* fun like watching
films or perhaps playing games, instead of spending a lifetime
pretending that the look of our work area is some kind of third rate
kitsch 'art work'.

Peace

uriel

[Jordi Marine]

you are a compulsive replier, you haven't time to use a computer

Post by Uriel

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe

Post by Moritz Wilhelmy
http://xinutec.org/~pippijn/files/img/collection/why-transparency-is-evil.jpg

So sugar is evil, because if one eats too much of it, one may die.

And make the world a better place as a result.

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe

Post by Moritz Wilhelmy
So, I agree with uriel: transparency is for idiots.

Often, drunk people seem to believe that other people are drunk.

And often idiots are just idiots.

Post by frederic
Do yourself a favour: stop calling others idiots.

Do yourself and the world a favour and go use Gnome, or even better OS X.

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe
When I was young I thought hey that looks cool (compared to the usual
terminals on Windows by that time). But when actually using it for a
while it hurts more and the coolness factor becomes obsolete sooner
than later. Perhaps the younger generation has better eyes and can
cope with it for a couple of years, but I haven't seen any serious
programmer that worked with translucent terminals very long...

I think I'm not younger than you, and I have been working with translucent
terminals for about ten years on a daily basis.

And now we have conclusive evidence that using translucent terminals
for extended periods of time damages the brain!
Thanks for sacrificing yourself as guinea pig for this essential and
fascinating scientific research project.

Post by frederic
I think the reason why I've been using them for so long is because I use
them more for the aesthetics than for the coolness factor.
Of course, my wallpaper doesn't show some lame anime character, insipid
landscape or kickass-y car.

What have you got as wallpaper? A picture of your but?

Post by frederic

Post by Anders Andersson

Post by Anselm R Garbe
Apart from that, all the other reasons (unnecessary complexity,
unnecessary cpu cycles, etc) are true and I agree.

I won't argue against that. Suckless software is nice, because it spares
some resources on my machine, so I can use translucent terminals :)

Post by Anders Andersson
If you need the transparency, there are compositing window managers
that will do perfect transparency for any application you would like
to.

Not exactly. Last time I tried, a compositing manager makes transparent
everything including writings, and performs true transparency. It is
significantly less comfortable than pseudo-transparency done by terminals
themselves. A comfortable translucent set up requires a accurate settings in
order to balance correctly eye-candy and easy reading.

I know that many enjoy so much the mental-masturbatory process of
configuring and "tuning" their desktops to death, but some of us
managed to outgrow our pre-adolescent vices and actually use computers
to get work done, hell, or even to have *actual* fun like watching
films or perhaps playing games, instead of spending a lifetime
pretending that the look of our work area is some kind of third rate
kitsch 'art work'.
Peace
uriel

--
Atentament.
Jordi Mariné

[poz]

Post by Jordi Marine
you are a compulsive replier, you haven't time to use a computer

Very well-known dicease: Loading Image...