Re: [dev] [ubase] pager

[Mattias Andrée]

On Thu, 2 Feb 2017 20:42:06 +0100
Josuah Demangeon  wrote:

> I started such a tool recently.  It is probably not
> suckless, as it is already 1600 loc, but can properly
> display a man page, colour escape codes and content from
> UTF-8-test.txt and UTF8-demo.txt without ncurses.
> 
> http://github.com/josuah/iode
> 
> If this one sucks, I would be glad to see the
> implementation, as I will learn a lot from it.
> 
> I have also seen rirc (irc client) that does not use
> ncurses for its interface.
> 
> http://github.com/rcr/rirc/blob/master/draw.c
> 

Well, this is embarrassing, I forgot to check you program
before starting on ul(1). However, I just ran

MAN_KEEP_FORMATTING=y man man | ./iode

and it is not able to display it properly, which is the
only thing I have implemented in ul(1) so far. But I'll
see if there are parts that can be reused.

maandree


pgpM43HF0vrpf.pgp
Description: OpenPGP digital signature

[dev] [st] Request for comments, cursor blink

[Andy Valencia]

I really liked the idea of st, but the alternate cursors don't
work well without blinking--too hard to spot.  Attached is my
first attempt at adding code to a suckless project, comments
welcome.

Thanks,
Andy Valenciadiff --git a/st.c b/st.c
index fbcd9e0..4e7ab10 100644
--- a/st.c
+++ b/st.c
@@ -134,7 +134,7 @@ enum term_mode {
 	MODE_MOUSESGR= 1 << 12,
 	MODE_8BIT= 1 << 13,
 	MODE_BLINK   = 1 << 14,
-	MODE_FBLINK  = 1 << 15,
+	MODE_CURSORBLINK = 1 << 15,
 	MODE_FOCUS   = 1 << 16,
 	MODE_MOUSEX10= 1 << 17,
 	MODE_MOUSEMANY   = 1 << 18,
@@ -390,6 +390,7 @@ static void strparse(void);
 static void strreset(void);
 
 static int tattrset(int);
+static int cursorset(int);
 static void tprinter(char *, size_t);
 static void tdumpsel(void);
 static void tdumpline(int);
@@ -1612,6 +1613,25 @@ ttyresize(void)
 		fprintf(stderr, "Couldn't set window size: %s\n", strerror(errno));
 }
 
+/*
+ * cursorset()
+ *	Check for cursor attr
+ */
+int
+cursorset(int attr)
+{
+	/* For now, only ATTR_BLINK is considered */
+	switch (xw.cursor) {
+	case 0: /* Blinking Block */
+	case 1: /* Blinking Block (Default) */
+	case 3: /* Blinking Underline */
+	case 5: /* Blinking bar */
+		return(1);
+	default:
+		return(0);
+	}
+}
+
 int
 tattrset(int attr)
 {
@@ -4008,6 +4028,12 @@ xdrawcursor(void)
 
 	if (IS_SET(MODE_HIDE))
 		return;
+	if (cursorset(ATTR_BLINK)) {
+		if ((term.mode & MODE_CURSORBLINK) == 0) {
+			/* Every other time, leave unpainted */
+			return;
+		}
+	}
 
 	/* draw the new one */
 	if (xw.state & WIN_FOCUSED) {
@@ -4393,8 +4419,10 @@ run(void)
 			ttyread();
 			if (blinktimeout) {
 blinkset = tattrset(ATTR_BLINK);
-if (!blinkset)
+if (!blinkset) {
 	MODBIT(term.mode, 0, MODE_BLINK);
+}
+blinkset |= cursorset(ATTR_BLINK);
 			}
 		}
 
@@ -4409,7 +4437,7 @@ run(void)
 		dodraw = 0;
 		if (blinktimeout && TIMEDIFF(now, lastblink) > blinktimeout) {
 			tsetdirtattr(ATTR_BLINK);
-			term.mode ^= MODE_BLINK;
+			term.mode ^= (MODE_BLINK | MODE_CURSORBLINK);
 			lastblink = now;
 			dodraw = 1;
 		}

Re: [dev] structural regular expression support for vis

[Marc André Tanner]

On Fri, Feb 03, 2017 at 10:00:37AM +, Raphaël Proust wrote:
> On 2 February 2017 at 17:46, Marc André Tanner  wrote:
> >Sam supports a count specifier: s2/pattern/replacement/ only replaces
> >the second occurrence of pattern. This is currently not supported but
> >can be mimicked using:
> >
> > :/pattern/ // c/replacement/
> >
> >A more general variant of the count concept might be later integrated
> >into the x, y and/or g, v commands. Comments and syntax suggestions
> >welcome.
> 
> My sam addressing is rusty, but IIRC, `/pattern/+/pattern/` search for
> the second match of `/pattern/`. (The `+` operator for addresses:
> “a1+a2  The address a2 evaluated starting at the end of a1.”)

That is correct, but `+` can be elided here. Also when pattern is
omitted the last used one is substituted in (this might be missing
from the vis man page, but it is mentioned in sam(1)). Hence 
`/pattern///` is an abbreviation of your `/pattern/+/pattern/`.

> Maybe, rather than a special case for `s`, this suggest that the

Yes special cases should be avoided, but as illustrated above this is
actually not the case here.

> address `n/pattern/` could be read as `n` times `/pattern/` which is
> `/pattern/+…+/pattern/`. Would that interfere with the other
> addressing modes?

Yes, with the current semantics it searches for `pattern` at the end
of line `n`.

> I think it's ok because compound addresses all use
> explicit operators (`+`, `-`, `,`, `;`). As a result, `2/pattern/` is
> distinguishable from `2+/pattern/`, `2-/pattern/`, etc.

As mentioned above `+` can be elided, hence `2+/pattern/` and
`2/pattern/` are equivalent.

> Alternatively, a command to manipulate dot collections could be used
> to provide a "2nd match replacement" feature. In this case, new
> operations say `h` and `t` (short for head and tail) would select,
> respectively, the first of the multiple selected dots and all but the
> first dot.
> 
> :x/pattern/ t h c/replacement/

Not sure this is flexible enough? How would you generalize this to
operate on the n-th dot in a convenient way?

I thought about introducing a count specifier for either `x` and `y`
or `g` and `v`. Because these commands take a regular expression not
an address the count is unambiguous here:

 x3/pattern/ command
 x/pattern/ g3 command

would only execute command for the third match. Similarly, `y` and `v`
would execute it for all but the third match.

> >  * Multi file support is not really well supported:
> >
> > - The X and Y commands currently operate on windows, not files.
> >   Meaning that if a file is being displayed in multiple windows
> >   a given command will be executed once for every window. This is
> >   desired in certain cases (e.g. `:X q` to close all windows without
> >   unsaved changes) and unwanted in others (e.g.
> >
> > :X 0i,/* ISC licensed */\n
> >
> >   to add a license template to the top of every file).
> 
> So currently `X` is more like vim's `windo`. I use `bufdo` more often.
> I'm undecided whether offering both is worth the added complexity and
> features.

I think it would be much cleaner to add both variants rather than
duplicate some functionality. If we had a proper way to loop through
files some vi originated commands like `bdelete` might become obsolete
and could be removed.

> IIRC, X (and Y) can only appear at the beginning of the command.

I think they can be used arbitrarly, but "only one instance of either
`X` or `Y` may appear in a single command". This is actually currently
not enforced by vis.

Thanks for your comments!

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617

Re: [dev] [dmenu] problem with parameters

[Ian Remmler]

On Fri, Feb 03, 2017 at 04:29:10PM +0100, Tobias Girstmair wrote:
> I don't know what to say to you: No, it doesn't. 
> (I believe this to be a bug?)

I believe you are conflating the behavior of dmenu and dmenu_run.
dmenu returns "jj s" with success exit code, like the man page says it
will.  dmenu_run executes "jj s".

> On Fri, Feb 03, 2017 at 03:35:36AM +0100, Quentin Rameau wrote:
> > > That's interesting. It doesn't do what you (and the man page; missed 
> > > that, mea culpa) described
> > 
> > Yes it does.
> > 
> 

-- 
- Ian.

Re: [dev] [dmenu] problem with parameters

[Tobias Girstmair]

I don't know what to say to you: No, it doesn't. 
(I believe this to be a bug?)

On Fri, Feb 03, 2017 at 03:35:36AM +0100, Quentin Rameau wrote:
> > That's interesting. It doesn't do what you (and the man page; missed 
> > that, mea culpa) described
> 
> Yes it does.
> 

Re: [dev] structural regular expression support for vis

[Connor Lane Smith]

On 3 February 2017 at 10:00, Raphaël Proust  wrote:
> One thing that always bothers me with regexes is that the same syntax
> (parens) is used for both overriding precedence (e.g., `(foo)*` to
> specify that star operates on the sequence `foo`) and groups (to be
> recalled with `\1`–`\9`).
>
> Anyone else is bothered by this?

In PCRE, `(foo)' is for capturing groups, whilst `(?:foo)' is purely
for precedence. So the two are at least distinguished, even if the
syntax is rather unfortunate. There's also `(?Pfoo)', which
makes the capture more explicit. Capturing groups are generally a mess
anyway though, e.g. their behaviour under Kleene star.

cls

Re: [dev] structural regular expression support for vis

[Raphaël Proust]

On 3 February 2017 at 10:00, Raphaël Proust  wrote:
> On 2 February 2017 at 17:46, Marc André Tanner  wrote:
>> […]
>>  * Multi file support is not really well supported:
>>
>> - The X and Y commands currently operate on windows, not files.
>>   Meaning that if a file is being displayed in multiple windows
>>   a given command will be executed once for every window. This is
>>   desired in certain cases (e.g. `:X q` to close all windows without
>>   unsaved changes) and unwanted in others (e.g.
>>
>> :X 0i,/* ISC licensed */\n
>>
>>   to add a license template to the top of every file).
>
> […]

I re-read the man page (this time all the way through) and realised
that most of this part of my answer didn't make sense in the context
of vis. Here's a revised comment.


So currently `X` is more like vim's `windo`. I use `bufdo` more often,
but there are no background buffers in vis so the situation is a bit
different.

Your use case (closing all the windows) can actually be achieved by
cycling through the buffers and using the `:bdelete` command. This
works because `q` has a special version that applies to all the
windows of the same buffer. This shows a few possible alternatives:

- All appropriate commands have two distinct version: one for window,
one for buffer.
- A wrapper function toggles between the different behaviours (similar
to the `:vertical` command in vim).
- A prefix or suffix to these commands toggles between the different
behaviours (similar to the `!` suffix to toggle behaviour of some
functions).

The functions that would be affected: q/delete, earlier/later,
map-window/unmap-window. Any other?




Cheers,
-- 
__
Raphaël Proust

Re: [dev] [sbase] [tar] some errors

[willy]

Willy Gfn wrote:
> Michael Forney wrote:
> > On 12/24/16, Cág  wrote:
> > > Markus Wichmann wrote:
> > >
> > >> Well, that looks like it might be problematic, doesn't it? Especially
> > >> when you find out, that the size of h->name there is 100 bytes. path
> > >> contains, of course, the entire file path relative to the starting
> > >> directory. In short, you will get this error message whenever trying to
> > >> package files with a total relative path length of more than 100
> > >> characters.
> > >
> > > Indeed, I've just tried to compress an extracted Linux kernel
> > > (that doesn't have .git folder), it went without errors. Thanks for
> > > pointing out.
> > >
> > > But when I tried to extract it, it still said "malformed tar archive".
> > > Here's the part with it: http://git.suckless.org/sbase/tree/tar.c#n404
> > 
> > Fixing up tar bugs in sbase has been on my TODO list for a while. It's
> > the one tool I'm not using from sbase.
> > 
> > One thing that might be related is that in various places, it uses
> > eread(..., BLKSIZE), expecting that exactly BLKSIZE bytes are written
> > (skipblk, xt, unarchive). But, if you are extracting from a pipe
> > hooked up to a decompression program, it may be less than that. When
> > this happens, it calls chktar on a random piece of data from the
> > archive, which fails the checksum check.
> > 
> > I think we should add a readall function to libutil, similar to the
> > writeall function I sent in a patch set a few weeks ago.
> > 
> > I think I have a pending patch to make the "malformed tar archive"
> > errors more specific, but it's on a different computer and I am
> > visiting family for the holidays. If you want to try and debug the
> > error, I'd start with trying to figure out why it thinks it is
> > malformed. I suspect it is due to a bad checksum.
> 
> Bumping this thread because I've been testing it a bit. I attached a
> patch to make the error more descriptive, and this patch shows that the
> most common error (to me) is a bad magic and that is certainly because the
> magic is checked before the checksum. Sometimes the magic check pass,
> but it then fails on the checksum.
> 
> This is indeed due to a short read from a pipe, because if you try to
> print the said "bad magic", you end up with a chunk of the previously
> extracted file. I will look into this "readall" function to submit
> a patch.
> 
> Something worth noticing is that I only encountered this bug with bzip2
> when it's compiled against musl. I couldn't reproduce it with glibc.

I managed to fix this bug by changing the eread() function. I'll send
an email with my patches in a new thread.

Re: [dev] [sbase] [tar] some errors

[willy]

Michael Forney wrote:
> On 12/24/16, Cág  wrote:
> > Markus Wichmann wrote:
> >
> >> Well, that looks like it might be problematic, doesn't it? Especially
> >> when you find out, that the size of h->name there is 100 bytes. path
> >> contains, of course, the entire file path relative to the starting
> >> directory. In short, you will get this error message whenever trying to
> >> package files with a total relative path length of more than 100
> >> characters.
> >
> > Indeed, I've just tried to compress an extracted Linux kernel
> > (that doesn't have .git folder), it went without errors. Thanks for
> > pointing out.
> >
> > But when I tried to extract it, it still said "malformed tar archive".
> > Here's the part with it: http://git.suckless.org/sbase/tree/tar.c#n404
> 
> Fixing up tar bugs in sbase has been on my TODO list for a while. It's
> the one tool I'm not using from sbase.
> 
> One thing that might be related is that in various places, it uses
> eread(..., BLKSIZE), expecting that exactly BLKSIZE bytes are written
> (skipblk, xt, unarchive). But, if you are extracting from a pipe
> hooked up to a decompression program, it may be less than that. When
> this happens, it calls chktar on a random piece of data from the
> archive, which fails the checksum check.
> 
> I think we should add a readall function to libutil, similar to the
> writeall function I sent in a patch set a few weeks ago.
> 
> I think I have a pending patch to make the "malformed tar archive"
> errors more specific, but it's on a different computer and I am
> visiting family for the holidays. If you want to try and debug the
> error, I'd start with trying to figure out why it thinks it is
> malformed. I suspect it is due to a bad checksum.

Bumping this thread because I've been testing it a bit. I attached a
patch to make the error more descriptive, and this patch shows that the
most common error (to me) is a bad magic and that is certainly because the
magic is checked before the checksum. Sometimes the magic check pass,
but it then fails on the checksum.

This is indeed due to a short read from a pipe, because if you try to
print the said "bad magic", you end up with a chunk of the previously
extracted file. I will look into this "readall" function to submit
a patch.

Something worth noticing is that I only encountered this bug with bzip2
when it's compiled against musl. I couldn't reproduce it with glibc.
diff --git a/tar.c b/tar.c
index 71719b0..e274874 100644
--- a/tar.c
+++ b/tar.c
@@ -29,6 +29,12 @@ enum Type {
RESERVED  = '7'
 };
 
+enum Error {
+   BADCHKSUM,
+   BADMAGIC,
+   BADPATH
+};
+
 struct header {
char name[100];
char mode[8];
@@ -71,6 +77,12 @@ static const char *filtertools[] = {
['z'] = "gzip",
 };
 
+static const char *errors[] = {
+   [BADCHKSUM] = "bad checksum",
+   [BADMAGIC]  = "bad magic",
+   [BADPATH]   = "empty filename"
+};
+
 static void
 pushdirtime(char *name, time_t mtime)
 {
@@ -351,8 +363,10 @@ skipblk(ssize_t l)
char b[BLKSIZ];
 
for (; l > 0; l -= BLKSIZ)
-   if (!eread(tarfd, b, BLKSIZ))
+   if (!eread(tarfd, b, BLKSIZ)) {
+   fprintf(stderr, "skipblk: failed to read %d bytes\n", 
BLKSIZ);
break;
+   }
 }
 
 static int
@@ -407,27 +421,36 @@ chktar(struct header *h)
char tmp[8], *err;
char *p = (char *)h;
long s1, s2, i;
+   int errnum;
 
-   if (h->prefix[0] == '\0' && h->name[0] == '\0')
+   if (h->prefix[0] == '\0' && h->name[0] == '\0') {
+   errnum = BADPATH;
goto bad;
-   if (h->magic[0] && strncmp("ustar", h->magic, 5))
+   }
+   if (h->magic[0] && strncmp("ustar", h->magic, 5)) {
+   errnum = BADMAGIC;
goto bad;
+   }
memcpy(tmp, h->chksum, sizeof(tmp));
for (i = 0; i < sizeof(tmp); i++)
if (tmp[i] == ' ')
tmp[i] = '\0';
s1 = strtol(tmp, , 8);
-   if (s1 < 0 || *err != '\0')
+   if (s1 < 0 || *err != '\0') {
+   errnum = BADCHKSUM;
goto bad;
+   }
memset(h->chksum, ' ', sizeof(h->chksum));
for (i = 0, s2 = 0; i < sizeof(*h); i++)
s2 += (unsigned char)p[i];
-   if (s1 != s2)
+   if (s1 != s2) {
+   errnum = BADCHKSUM;
goto bad;
+   }
memcpy(h->chksum, tmp, sizeof(h->chksum));
return;
 bad:
-   eprintf("malformed tar archive\n");
+   eprintf("malformed tar archive: %s\n", errors[errnum]);
 }
 
 static void

Re: [dev] [sbase] tar fails to extract bzip2

[willy]

Michael Forney wrote:
> On 2/2/17, willy  wrote:
> > At this point, I'm not sure where to look at, or even if the bug
> > really lies in tar and not in bzip2.
> > I checked the size (both octal and converted) and the value is good. So
> > I'm not sure why the headers are not well read.
> > In the case of the archive above, the error occurs on the last entry,
> > but depending on the archives, it can occur on the second entry or in
> > the middle, there's no rule.
> >
> > I hope my example are clear to define what the issue is. Would anyone
> > have an idea?
> 
> It's a tar bug. See http://lists.suckless.org/dev/1612/30865.html.

Ah, I wasn't aware of this. Thanks for the input. It seems odd that the
bug only triggers when bzip2 is linked against musl though..

Re: [dev] Some core tools

[Cág]

Mattias Andrée wrote:

> I'm not convinced mk(1) is less sucky
> than POSIX make(1), but it may be less
> sucky than many make(1) implementations.

There is also bmake(1)[0], a port of NetBSD's
make(1)[1]. OpenBSD has their own
make(1)[2] as well.


Cág

[0]:
http://www.crufty.net/help/sjg/bmake.html
[1]:
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/make/
[2]:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/make/

Re: [dev] Some core tools

[sylvain . bertrand]

On Thu, Feb 02, 2017 at 06:45:49PM +0100, Mattias Andrée wrote:
> I'm work on implementing make(1)

In theory, linux kbuild should be a good reference for the minimum set of
makefile extensions to code. Well, in theory, the guys paid full-time at the
linux fondation to work on kbuild, should have constraint themselves to use the
bare minimum of makefile extensions, and be honest about it (they aren't, be
carefull). suckless: better have a bit more roughness in the makefile than
depends on super duper makefile extensions... which would make coding an
alternative to make something crazy or insane.
It's like C, the bare minimum of extensions would be those required to compile
a kernel like linux (a good part of C89 syntax is already to much, hence
even more with C99), but the gcc inline assembly is critical. The "right"
answer would be to abstract away what's really needed (minimal) from a C
toolchain for a reasonable linux build (even clang/llvm people failed).

-- 
Sylvain

Re: [dev] structural regular expression support for vis

[Raphaël Proust]

On 2 February 2017 at 17:46, Marc André Tanner  wrote:
> […]
> In the meantime lots of bugs have been fixed. I would like to encourage
> all sam/acme users who are also somewhat familiar with vi(m) to try out
> current master of vis and report back on their experience:
>
>   https://github.com/martanne/vis
>   http://repo.or.cz/w/vis.git

I'll try it in the next few days and report. A few comments now.


>  * Changes do not need to be in sequence, but only non-overlapping i.e.
>the following works as expected:
>
> :x/Emacs/ { d i/V/ a/i/ }
>
>  * The s (substitute) command was dropped. Instead :x/pattern/c/replacement/
>can be used for global search and replacement. The registers \1-\9 refer
>to sub expression matches. & contains the complete matched text, hence:
>
> :x/Vi/ c/>&
>has the same effect as:
>
> :x/Vi/ { i/>/ a/Sam supports a count specifier: s2/pattern/replacement/ only replaces
>the second occurrence of pattern. This is currently not supported but
>can be mimicked using:
>
> :/pattern/ // c/replacement/
>
>A more general variant of the count concept might be later integrated
>into the x, y and/or g, v commands. Comments and syntax suggestions
>welcome.

My sam addressing is rusty, but IIRC, `/pattern/+/pattern/` search for
the second match of `/pattern/`. (The `+` operator for addresses:
“a1+a2  The address a2 evaluated starting at the end of a1.”)

Maybe, rather than a special case for `s`, this suggest that the
address `n/pattern/` could be read as `n` times `/pattern/` which is
`/pattern/+…+/pattern/`. Would that interfere with the other
addressing modes? I think it's ok because compound addresses all use
explicit operators (`+`, `-`, `,`, `;`). As a result, `2/pattern/` is
distinguishable from `2+/pattern/`, `2-/pattern/`, etc.


Alternatively, a command to manipulate dot collections could be used
to provide a "2nd match replacement" feature. In this case, new
operations say `h` and `t` (short for head and tail) would select,
respectively, the first of the multiple selected dots and all but the
first dot.

:x/pattern/ t h c/replacement/

Capital letters `H` and `T` can be used for “the last” and “all but the last”.

This second approach is also much more powerful because it is not
restricted to addresses but in any command (included in nested `{…}`).
In a way, sam already had iterator (x y) and filter (g, G) and these h
and t simply add other forms of collection management.

Some of the number-before-address conciseness can be recovered in this
heads-and-tails approach by allowing counts for the `h`, `t`, `H` and
`T` commands. E.g., `:x/pattern/ t10 h c/replacement/`.




>  * Multi file support is not really well supported:
>
> - The X and Y commands currently operate on windows, not files.
>   Meaning that if a file is being displayed in multiple windows
>   a given command will be executed once for every window. This is
>   desired in certain cases (e.g. `:X q` to close all windows without
>   unsaved changes) and unwanted in others (e.g.
>
> :X 0i,/* ISC licensed */\n
>
>   to add a license template to the top of every file).

So currently `X` is more like vim's `windo`. I use `bufdo` more often.
I'm undecided whether offering both is worth the added complexity and
features.

IIRC, X (and Y) can only appear at the beginning of the command. Maybe
there can be longer named commands for sifting through specifically
buffers or windows, and then there is the matter of deciding which
should X default to.

Additionally, it might be interested to sift through the files of the
current directory (e.g., to apply a command to each of the .c files).
I guess it is less important because vis seem to support globbing in
`:e` by default.





Cheers,
-- 
__
Raphaël Proust