On Wed, 8 Feb 2012 20:15:52 +0100
Anselm R Garbe wrote:
>Btw. I would like you to use C and rc, not C and bash or something
>similar.
There were once discussion about "blessed" rc version, but AFAIR there
were no simple conclusion. What version of rc is good enough?
What I remember: Byron's vers
Ah, cool. That's exactly what I needed.
On 09.02.2012, Benjamin R. Haskell wrote:
> On Thu, 9 Feb 2012, hiro wrote:
>
>> mhm, so there's no native way on a linux?
>
> Depending on your kernel, the DMI information may be available via
> sysfs. You asked for the serial number before. I have that
* Anselm R Garbe [08.02.2012 20:11]:
> On 2 February 2012 17:20, Thomas Dean <78...@web.de> wrote:
> > On Thu, Feb 02, 2012 at 14:45:42 +0100, Uli Armbruster wrote:
> >> Means, only after refocusing mupdf, it looks fine. It doesn't depend on
> >> this certain pdf file, it happens with all pdf file
Hi all,
Implemented yes(1), sync(1) and printenv(1). Source is attached,
haven't had time to write the manpage yet.
Cheers,
stateless
/* See LICENSE file for copyright and license details. */
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
int i;
char *p;
if (argc
Hilarious. I particularly liked the way you needlessly reinvented
getenv(), and pointlessly used getopt() in printenv.
On Thu, Feb 9, 2012 at 7:15 AM, stateless wrote:
> Hi all,
>
> Implemented yes(1), sync(1) and printenv(1). Source is attached,
> haven't had time to write the manpage yet.
>
>
The SHELL macro from config.h isn't used; instead, the shell is
grabbed with getenv("SHELL"). I guess this was the default behavior
before, but the last time I used st-0.1.1 I didn't mind having bash as
my shell, so I didn't catch it--sorry. The macro should be removed
from config.def.h if it's not
On Thu, Feb 09, 2012 at 09:22:45AM -0500, Andrew Hills wrote:
> I don't have a choice of setting $SHELL when dwm is launched.
Why can't you set $SHELL?
On Thu, Feb 9, 2012 at 9:31 AM, Kurt H Maier wrote:
> Why can't you set $SHELL?
Stupid restrictions on the environment at work. I telnet into some
silly interface to launch a VNC server; all I can specify is the
window manager executable's path, and it tests to make sure it's a
binary. I guess I
Thank you!
Do you only accept software projects?
Thanks for the pointer. I just read Chapter 6 and I agree with
most of it. Is there any plans for st to go towards a ``good"
direction ? I mean using maybe unusual but saner control
or escape sequences, support all colors (2^24 or 2^32) at
the same time ? Writing a saner library than ncurses that
k
On Thu, Feb 09, 2012 at 05:25:08PM +0100, Guillaume Quintin wrote:
> Writing a saner library than ncurses that
> knows only st and try to convince other terminal emulator
> writers to do the same: support exactly the same sequences.
The logical conclusion of this approach is e.g. NeWS. NeWS faile
On Wed, Feb 08, 2012 at 03:47:00PM +0100, Aurélien Aptel wrote:
> On Wed, Feb 8, 2012 at 2:49 PM, ilf wrote:
> > I am running the same tmux session in both rxvt-unicode and st next
> > to each other. The drawing speed of st does indeed feel better than
> > before, but it's still way slower than rx
| Writing a saner library than ncurses that knows only st and try to
| convince other terminal emulator writers to do the same: support
| exactly the same sequences.
Replacing ncurses with a hardcoded library is not a workable approach.
Unix systems today are accessed from far more environments
you may probably want to look at my r_cons and r_line libraries from r2.
i do buffering, autocomplete, screen filling, and works on w32 console, and
most of terminals (st, xterm...) without guessing the termcodes. i just
hardcode them.
http://radare.org
On Feb 9, 2012, at 18:02, Chris Siebenm
On Thu, Feb 09, 2012 at 12:15:32PM +, stateless wrote:
> Hi all,
>
> Implemented yes(1), sync(1) and printenv(1). Source is attached,
> haven't had time to write the manpage yet.
>
> Cheers,
> stateless
These are slightly shorter and printenv() returns 1 when it can't find
the environment var
On Wed, Feb 08, 2012 at 11:00:09PM +0100, Anselm R Garbe wrote:
> I would like to ask you to test the slock tip.
>
> I haven't fixed the multiply numpad combo issue, however I believe I
> have fixed the issue that new clients appear on top of the black
> windows.
$ ./slock & ( sleep 1 ; st )
wil
On 9 February 2012 19:50, Eckehard Berns wrote:
> On Wed, Feb 08, 2012 at 11:00:09PM +0100, Anselm R Garbe wrote:
>> I would like to ask you to test the slock tip.
>>
>> I haven't fixed the multiply numpad combo issue, however I believe I
>> have fixed the issue that new clients appear on top of t
Hi there,
I heavily dislike the fact that dmenu now contains a reference to
getopt(). Not exactly dmenu, but stest.
Can we please remove the getopt() dependency?
Thanks,
Anselm
On 9 February 2012 10:16, Hadrian Węgrzynowski wrote:
> On Wed, 8 Feb 2012 20:15:52 +0100
> Anselm R Garbe wrote:
>
>>Btw. I would like you to use C and rc, not C and bash or something
>>similar.
>
> There were once discussion about "blessed" rc version, but AFAIR there
> were no simple conclusio
On Thu, Feb 09, 2012 at 08:19:35PM +0100, Anselm R Garbe wrote:
> On 9 February 2012 19:50, Eckehard Berns wrote:
> > $ ./slock & ( sleep 1 ; st )
> >
> > will show a terminal window on top of the black slock window. Not that I
> > could use the terminal, but it's shown.
>
> Not for me, I can't r
On 9 February 2012 20:51, Eckehard Berns wrote:
> On Thu, Feb 09, 2012 at 08:19:35PM +0100, Anselm R Garbe wrote:
>> On 9 February 2012 19:50, Eckehard Berns wrote:
>> > $ ./slock & ( sleep 1 ; st )
>> >
>> > will show a terminal window on top of the black slock window. Not that I
>> > could use
On Thu, Feb 09, 2012 at 08:57:56PM +0100, Anselm R Garbe wrote:
> Ok, I must admit I don't use xcompmgr.
*Cough* *mumble some excuse*...
> Nevertheless selecting for SubstructureNotifyMask makes sense and I
> applied a fix accordingly. Does vanilla hg tip works for you now?
Yes. I tried it seve
malloc() in yes(1) is definitely overkill. I've attached a simple
version.
#include
int
main(int argc, char **argv)
{
const char *y[] = {"","y"};
int i;
if(argc < 2)
argv=y, argc=2;
for(;;){
for(i=1; i
Hi,
here is a version of rmdir(1) in the spirit of mkfifo.c.
Felix#include
#include
#include "util.h"
int
main(int argc, char *argv[])
{
while(getopt(argc, argv, "") != -1)
exit(EXIT_FAILURE);
for(; optind < argc; optind++)
if(rmdir(argv[optind]) == -1)
eprintf("remove %s:", argv[opti
On Thu, Feb 09, 2012 at 04:06:59PM -0500, Galos, David wrote:
> malloc() in yes(1) is definitely overkill. I've attached a simple
> version.
Invoking malloc() once (resulting in O(1) additional time and space) is
overkill but using printf() in every iteration (which means firing up
the printf() pa
On Thu, Feb 09, 2012 at 10:37:51PM +0100, Lukas Fleischer wrote:
> On Thu, Feb 09, 2012 at 04:06:59PM -0500, Galos, David wrote:
> > malloc() in yes(1) is definitely overkill. I've attached a simple
> > version.
>
> Invoking malloc() once (resulting in O(1) additional time and space) is
> overkill
Do we really need multiple arguments for yes(1)? BSD doesn't.
> while(puts(argv[1]) != EOF);
cls
On Thu, Feb 09, 2012 at 10:19:55PM +, Connor Lane Smith wrote:
> Do we really need multiple arguments for yes(1)? BSD doesn't.
>
> > while(puts(argv[1]) != EOF);
Yeah. 'if (!argv[1]) argv[1] = "y";' and this gets a +1 from me :)
>
> cls
On 9 February 2012 22:44, Lukas Fleischer wrote:
> Yeah. 'if (!argv[1]) argv[1] = "y";' and this gets a +1 from me :)
It'd probably be more like,
> const char *s = (argc < 2) ? "y" : argv[1];
> while(puts(s) != EOF);
cls
On Thu, Feb 09, 2012 at 10:52:57PM +, Connor Lane Smith wrote:
> On 9 February 2012 22:44, Lukas Fleischer wrote:
> > Yeah. 'if (!argv[1]) argv[1] = "y";' and this gets a +1 from me :)
>
> It'd probably be more like,
>
> > const char *s = (argc < 2) ? "y" : argv[1];
> > while(puts(s) != EOF)
On 9 February 2012 19:20, Anselm R Garbe wrote:
> Can we please remove the getopt() dependency?
If someone writes an ARGBEGIN-style flag parser with clustering,
that's fine. Seems a bit of a waste considering getopt is POSIX, but
never mind.
cls
Anselm R Garbe writes:
> On 9 February 2012 10:16, Hadrian Węgrzynowski wrote:
>> On Wed, 8 Feb 2012 20:15:52 +0100
>> Anselm R Garbe wrote:
>>
>>>Btw. I would like you to use C and rc, not C and bash or something
>>>similar.
>>
>> There were once discussion about "blessed" rc version, but AFAI
By bloated you mean the binary size is a miniscule; practically
meaningless, amount larger than the others. That hardly counts as bloated.
On Feb 9, 2012 7:59 PM, "Christian Neukirchen"
wrote:
> Anselm R Garbe writes:
>
> > On 9 February 2012 10:16, Hadrian Węgrzynowski
> wrote:
> >> On Wed, 8
The links to Man pages are broken for some tools.
For example, http://tools.suckless.org/sic links to
http://man.suckless.org/tools/1/sic which "doesn't exist"
--
David Krauser
Anselm removed the man pages recently. Use man(1).
On Friday, 10 February 2012, Christian Neukirchen
wrote:
> Anselm R Garbe writes:
>
>> On 9 February 2012 10:16, Hadrian Węgrzynowski
wrote:
>>> On Wed, 8 Feb 2012 20:15:52 +0100
>>> Anselm R Garbe wrote:
>>>
Btw. I would like you to use C and rc, not C and bash or something
similar.
>>
36 matches
Mail list logo
