[dev] [dev xlsh]: fix Makefile

[Kurt Van Dijck]

On Wed, Oct 19, 2011 at 09:37:52PM +0200, Michał Siejak wrote:
> Hello.
[...]
> Source code is here: https://github.com/Nadrin/xlsh
> Example screenshot is here: https://github.com/Nadrin/xlsh/wiki
> 
> If any of you guys find it useful let me know. :) Constructive
> criticism/peer review is more than welcome.

With this patch, your Makefile works with my make (GNU Make 3.81)

Signed-off-by: Kurt Van Dijck 
---
diff --git a/Makefile b/Makefile
index a1d2b13..541ea3b 100644
--- a/Makefile
+++ b/Makefile
@@ -38,7 +38,8 @@ XLSHD_HEADERS = config.h libxlsh.h
 
 all: $(PROGRAMS)
 
-xlsh: $(XLSH_OBJ) $(XLSH_LIBS)
+xlsh: $(XLSH_OBJ)
+xlsh: LDLIBS=$(XLSH_LIBS)
 
 xlshd: $(XLSHD_OBJ)
 

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

[Kurt H Maier]

nothing.anyone says on this list is worth digitally signing and nobody
cares how you prefer to be contacted.

-- 
# Kurt H Maier

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

[Suraj N. Kurapati]

On Thu 20 Oct 2011 01:55:30 AM PDT, Stephen Paul Weber wrote:
> Does this list support MIME?

Works for me with PGP MIME.

-- 
FORTRAN rots the brain.
-- John McQuillin


signature.asc
Description: PGP signature

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

[Stephen Paul Weber]

Somebody claiming to be Andrew Hills wrote:

On Wed, Oct 19, 2011 at 9:20 PM, Stephen Paul Weber
 wrote:

Or are you complaining about filesize? Are you on dialup?


No, just complaining that it's hard to find the content in your
message when the majority of my mail reader's window is full of PGP
signature instead of words.


Right, that's what I thought.  Does this list support MIME?

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

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

[Andrew Hills]

On Wed, Oct 19, 2011 at 9:20 PM, Stephen Paul Weber
 wrote:
> Or are you complaining about filesize? Are you on dialup?

No, just complaining that it's hard to find the content in your
message when the majority of my mail reader's window is full of PGP
signature instead of words. That, and reading this list for an hour
will tell you the general opinion on inefficiency of any kind.

--Andrew Hills

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

[Stephen Paul Weber]

Somebody claiming to be Kurt H Maier wrote:

Thanks for sending out a kilobyte of text with an eleven-word reply
buried in the middle, Stephen Paul Weber.


Sorry, most mailing lists hate MIME, so I send inline.

Or are you complaining about filesize? Are you on dialup?

--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

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

[Bryan Bennett]

> Hey, at least those of us who know where to find his public key know
> that it was actually sent by him, or someone else with access to his
> computer.

Because it's vital that we know that this is from him.

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

[Andrew Hills]

On Wed, Oct 19, 2011 at 7:04 PM, Kurt H Maier  wrote:
> Thanks for sending out a kilobyte of text with an eleven-word reply
> buried in the middle, Stephen Paul Weber.

Hey, at least those of us who know where to find his public key know
that it was actually sent by him, or someone else with access to his
computer.

--Andrew Hills

Re: [dev] Introducing XLSH

[Catalin David]

Hey!

2011/10/19 Michał Siejak :
> Hello.
>
> Recently I've written a simple program for myself and I think it fits
> well into minimalistic suckless philosophy, so I present to you XLSH
> or eXtended Login Shell. Let me paste a chunk of relevant info from
> the README file:
>
> A simple login shell with readline functionality and PAM integration.
>  * When run stand-alone on a virtual console it can replace standard
> "login" program.
>  * When run in cooperation with X daemon component (xlshd) it can
> replace XDM/GDM/KDM.
>
> Features:
>  * Small and simple, written entirely in C.
>  * Easily hackable because of compact codebase (~1000 source lines).
>  * Uses PAM for authorization and session management.
>  * Ability to select non-default shell/window manager during logon.
>  * Entirely keyboard driven display manager replacement (when used with xlshd)
>   without the need for any fat libraries or GUI toolkits.
>  * Defaults configured before compilation, some of them can be changed by
>   setting few environment variables.
>  * Single shell script file (/etc/xlsh/xlshrc) for customizing how
>   xlshd launches xlsh.
>  * Introduces a concept of "pre-login shell" known from GNU/HURD.
>  * Only *three* important commands: 'login', 'reboot' and 'shutdown'.
>  * New commands can be easily added (if you need any) by editing xlsh.c
>  * Username autocompletion on TAB.
>  * Zenburn color scheme by default (when run under X).
>
> So that's it. I grew tired of XDM/GDM/KDM so I rolled my own solution.
> I currently run it both on my ttys and instead of XDM. It serves me
> well, I find simple keyboard shell-like interaction very comfortable
> and it fits into my awesome WM look & feel (which is also Zenburn).

Sounds pretty awesome. I was also very tired of GDM and KDM and their
bloatness. I tried SLiM at some point, but then for some reason it
stopped working (I think I did an upgrade) and had to fall back to
GDM.

I've had a Linux box for quite a while now, but I don't quite know
what needs to be done to replace GDM with XLSH. So, if anyone can help
on that, it would be great -- I'm running Ubuntu, but I am sure I can
replicate any instructions you might give for your ArchLinux box.

Also, I was wondering how it behaves on a dual screen setup (if you
got a chance to test it) and whether it automatically runs the
.xsession file (which starts DWM).

Thanks for sharing your work and I am waiting for some sort of
tutorial to make it run on my machine.

Catalin

>
> Source code is here: https://github.com/Nadrin/xlsh
> Example screenshot is here: https://github.com/Nadrin/xlsh/wiki
>
> If any of you guys find it useful let me know. :) Constructive
> criticism/peer review is more than welcome.
>
> Cheers!
> --
> Michał Siejak
>
>



-- 
**
Catalin David
M.Sc. Smart Systems 2012
B.Sc. Computer Science 2010
Jacobs University Bremen

Phone: +49-(0)1577-49-38-667

Hans-Hermann-Sieling-Strasse 2A
Bremen, 28759
Germany
**

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

[Kurt H Maier]

Thanks for sending out a kilobyte of text with an eleven-word reply
buried in the middle, Stephen Paul Weber.

-- 
# Kurt H Maier

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

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Somebody claiming to be Aurélien Aptel wrote:
>Attached wrong patch; use this one, sorry.

I can confirm that this patch works for me in irssi :D

- -- 
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJOn06ZAAoJENEcKRHOUZzeQQYP/36YhuMtSU0O1r1QZNGahAJh
wxgT0B1+aXCCQV960UCtSQeCbcEHAvL+7jkJeOLsko8LdYaCqiouQQgUIEBqO6Y9
jQSgYN0OF1Sc8EwdifzxpaiRP1tg2X/9ybor+EUQNNj9iagECqYtw4rQoCM68R9B
LutPGzqjZtkjAByOwn2cM3ft7D0IgzRCbP0lNGWFJOVICi4vmlbDX0x96bgQ/vQi
yfOcl6RaCm8IP048WbOjWMBA2RWwm2mmtxOV2gJtzx55c8zNzixyuaIxKnjh6uNr
IeGZ1sf57Edw+PrQsb+PCjaH6ebiyH5l0QKi6Xki5j5FWI8mDg2pp40oYH71Zjbt
w0YQWlFhwvH+4JCfzbDljtzWBPUi3piUweX6/GJJ8E2qmBow6wARIrouEHMA4zGt
0sygFQMzwGbMPV62qcOW2RyzmWSr6+L6vuyP51NQAQp0xIBGvdUo8Qj8KJyuJxm4
rxX3MnhFxsYChMgyHOb9tCRh8sEKx/SRTzE7r0j2iiqu9Y1hri7bR54kZkMbJFKo
XvRNwphqX/AT6q4koy0bdOOe6jmzVuizG92oZ90WnjtGluS8OKSGHd8CU3zcNw7s
1gVEq43z1FFUtxAyVKXBQvSAbyCkiK07ibIuV16Czowry9lef/sSgC40JdBmlTzP
cnGUTHipHam3/GnX+Ywy
=xakF
-END PGP SIGNATURE-

[dev] Re: dvtm keybindings

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Me again :)

I've been trying to use dvtm under st, with some strange results.  It seems 
that dvtm tries to emulate rxvt, whereas st has it's own way of doing things 
(but is closer to xterm than to rxvt).  If I run dvtm normally, keys seem to 
mostly work, but notably colour does not.  If I change TERM to st-256color 
then colour works, but some keys (notably ones where rxvt is different from 
st, such as pgup/home/end) stop working.

Though, curiously, irssi basically works in st under dvtm with 
TERM=st-256color... maybe if it gets codes it doesn't understand it falls 
back to xterm?

- -- 
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJOn0vYAAoJENEcKRHOUZzeRqQP/2+eJ01IK0/NpwedF1C+VxXy
vcR7IZ3zxw/I2akfIF3tZ2u31f09wnAbMKAcxhemJqNRc2efoLNbdr2LfgQCJUNt
pHFcuk4tJQOrZ1YGtanIqihAjXZ9vspnkK1d56GtoDy9vtsW+OLJxDSXLubqqR5Z
Q4MdgBnpw8NY5ICc3VHezJ4e1lYpVNB74IAlu5cevx+S7418i/5uzQECfDRNYaah
HlOJkACLDJE9brdxBC1JZ7DmADLrLK0N9xj1/gl/cuSxH0ydcg9QxNVxhg9BGYF2
CrjWcJSTzvbNpMPHm35k4I0kdcRasMq9bm554aCwR8S+M5EilO9kBqa8Ngqma58o
gOoDMeB1TDkzUcUKIT0p9BjD52EKc4WawGJNzocE8vETCsVpYVxaVXEVTPp+JS29
jy6eMvVKXRecIFLWeANHPCMc8Pl/7hHqa/qhC7O7VmTNM/plIYp8zPmayQyHbYQv
fP31gJXJjdvU0r2/H9e4g0UBqI2/Gieht+UMY0ny4fVY231lCVXhETKyp/YrMq2s
n32Q/YKiUJJfi/HmoJU5lIquyHIJT8itxHyFDGnbxwgfMn+C0L2yND4WCofGOkoO
OMp+0RMA5XOnmzJS0J9hXCvacOjeAIQQFA87Q58b4ht6c8MS3NYli5cZUmZxWelJ
JQhH9Gi2WiRSd7sk+EzR
=2eOC
-END PGP SIGNATURE-

[dev] Introducing XLSH

[Michał Siejak]

Hello.

Recently I've written a simple program for myself and I think it fits
well into minimalistic suckless philosophy, so I present to you XLSH
or eXtended Login Shell. Let me paste a chunk of relevant info from
the README file:

A simple login shell with readline functionality and PAM integration.
 * When run stand-alone on a virtual console it can replace standard
"login" program.
 * When run in cooperation with X daemon component (xlshd) it can
replace XDM/GDM/KDM.

Features:
 * Small and simple, written entirely in C.
 * Easily hackable because of compact codebase (~1000 source lines).
 * Uses PAM for authorization and session management.
 * Ability to select non-default shell/window manager during logon.
 * Entirely keyboard driven display manager replacement (when used with xlshd)
   without the need for any fat libraries or GUI toolkits.
 * Defaults configured before compilation, some of them can be changed by
   setting few environment variables.
 * Single shell script file (/etc/xlsh/xlshrc) for customizing how
   xlshd launches xlsh.
 * Introduces a concept of "pre-login shell" known from GNU/HURD.
 * Only *three* important commands: 'login', 'reboot' and 'shutdown'.
 * New commands can be easily added (if you need any) by editing xlsh.c
 * Username autocompletion on TAB.
 * Zenburn color scheme by default (when run under X).

So that's it. I grew tired of XDM/GDM/KDM so I rolled my own solution.
I currently run it both on my ttys and instead of XDM. It serves me
well, I find simple keyboard shell-like interaction very comfortable
and it fits into my awesome WM look & feel (which is also Zenburn).

Source code is here: https://github.com/Nadrin/xlsh
Example screenshot is here: https://github.com/Nadrin/xlsh/wiki

If any of you guys find it useful let me know. :) Constructive
criticism/peer review is more than welcome.

Cheers!
-- 
Michał Siejak

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

[Eckehard Berns]

> ..., which would be a good starting point to trace
> the problem (unless someone already knows what the problem is).

I would assume the problem is the excessive redrawing of the whole
terminal window. Each time you move the curser only one cell the whole
screen will be redrawn into a backup pixmap and then the whole pixmap
will be copied to the window.

Also, when the screen is redrawn by the application (maybe due to a page
up/down) st's draw() will be called multiple times due to the kernel
buffer size of pipes, which will result in redrawing the entire window
multiple times.

I have experimented with remembering the min and max row of changes
since the last call to draw() (and only drawing that portion of the
screen) a while ago. It adds a few lines to the code but on my system it
did lower the CPU usage of X. I stopped looking into this because I have
other issues with st besides performance at the moment (mainly xterm
compatibility - I ssh into a few machines and installing a new terminfo
everywhere is no option for me).

-- 
Eckehard Berns

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

[Nick]

On Wed, Oct 19, 2011 at 09:51:33AM -0400, Andrew Hills wrote:
> Recently I have discovered that, independent of the value of $TERM, I
> am unable to use ^C or ^\ to kill tail when following a file. I am
> required to ^Z, kill %%. However, no other program seems to have this
> problem. Has anyone else seen this behavior?

^C of tail -f works fine here.

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

[Andrew Hills]

On Wed, Oct 19, 2011 at 9:17 AM, Nick  wrote:
> st has no performance issues. The computers are slow, by
> modern standards (900Mhz CPU).

Right, and I have a similar speed and font size (and no issues), yet
users with faster machines experience degraded performance. I'm
wondering if they have significantly more characters (read: orders of
magnitude more) drawn, which would be a good starting point to trace
the problem (unless someone already knows what the problem is).

At work I use a 1600x1200 resolution and also have no performance
issues, but I also am using Xming or VNC and running it on large
expensive machines, so it's not a good comparison.

Recently I have discovered that, independent of the value of $TERM, I
am unable to use ^C or ^\ to kill tail when following a file. I am
required to ^Z, kill %%. However, no other program seems to have this
problem. Has anyone else seen this behavior?

--Andrew Hills

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

[Nick]

On Wed, Oct 19, 2011 at 09:06:25AM -0400, Andrew Hills wrote:
> The computers are fast, or st has no performance issues (and is thus fast)?

st has no performance issues. The computers are slow, by
modern standards (900Mhz CPU).

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

[Andrew Hills]

On Wed, Oct 19, 2011 at 8:30 AM, Nick  wrote:
> It isn't. I use terminus 16 on my computers, one with an
> Intel gfx card, one with an nVidia one, and they are both
> quite fast.

The computers are fast, or st has no performance issues (and is thus fast)?

--Andrew Hills

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

[Nick]

On Wed, Oct 19, 2011 at 08:24:22AM -0400, Andrew Hills wrote:
> I will check tonight. Of note is that I use a
> rather large font in my terminal to avoid straining my eyes--Terminus
> 12 or 14. This may be related.

It isn't. I use terminus 16 on my computers, one with an
Intel gfx card, one with an nVidia one, and they are both
quite fast.

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

[Andrew Hills]

On Wed, Oct 19, 2011 at 5:59 AM, Stefan Mark  wrote:
> This problems seems to be related to the radeon video driver

My notebook has a Radeon card (Mobility X1400, I think), but I forget
which driver I am using. I will check tonight. Of note is that I use a
rather large font in my terminal to avoid straining my eyes--Terminus
12 or 14. This may be related.

--Andrew Hills

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

[Stefan Mark]

On 18.10.2011 18:39, Andrew Hills wrote:
> 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.
> 
That sure is strange. Even in a small window (around 80x30), mc took
about 1s to render for me. Just typing in the last row makes X consuming
around 20% (on a 2.6ghz core2). The strange thing is, typing in the
first row only needs 6%.
This problems seems to be related to the radeon video driver, cause it
not happens on my Notebook, which has Intel graphic. I will test it on a
nvidia soon.