Re: [dev] ASCII Delimited Text

[Connor Lane Smith]

On 22 May 2018 at 17:03, Silvan Jegen  wrote:
> This sounds like 'column'[0].

It's similar to column -t, except that it handles varying field counts
in a similar way to gofmt, and it can use ANSI escapes to rewrite the
output so it can stream without buffering all (or any) input or output
up front.

Thanks,
Connor

Re: [dev] ASCII Delimited Text

[Connor Lane Smith]

On 22 May 2018 at 01:24, Raphaël Proust  wrote:
> I sent the copy. I use usul regularly so I still have the whole repo
> locally.

Could you send me a copy as well? I'd also be interested to know what
sort of things you tend to use it for, in case it could be made
better.

> In what way is the elastic tabbing different from what Plan9's mc(1)?

mc columnates lines, so if you have the input:

> foo
> bar
> baz

then it will output something like:

> foo  bar  baz

Elastic tabbing, on the other hand, tabulates lines, so if you have the input:

> foo  bar  baz
> dis  establishment  arianism

then it will output something like:

> foo  barbaz
> dis  establishment  arianism

I've uploaded the source [1], but I'd not touched it in 3 years so I'm
not really sure what state it's in. There are a few things I'd planned
to add, like options for not elasticising leading tabs, and
right-aligning numeric fields, which I might get around to if I feel
like it.

[1]: https://github.com/cls/elastic

Thanks,
Connor

Re: [dev] ASCII Delimited Text

[Connor Lane Smith]

Hi,

On 21 May 2018 at 17:12, Adrian Grigore  wrote:
> I'm having problems compiling usul:

This is a surprise. Where did you get usul from? I'm not sure even I
have a copy any more! The only reason I can think of, though, is that
you need to specify the -L libdir.

I have been wondering lately about resurrecting usul, since 'tabular
munging' with Unix utilities without the ability to set $FS and $RS
can be really unpleasant, and I've had to do quite a bit of it
recently.

I did also write a program to complement usul which performs elastic
tabbing on its input, the idea being that you end up with a nice
tabular view in your terminal. I think ideally you might want 'real'
terminal support for it though, as when printing to the tty you either
need to buffer a lot of data (i.e. until a line with no FS), or you
need to do crazy tty-rewriting ANSI escapes, which it did support but
is a massive hack.

Thanks,
Connor

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] Some core tools

[Connor Lane Smith]

On 2 February 2017 at 20:08, Connor Lane Smith <c...@lubutu.com> wrote:
> > .o:
> > $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<

By which I of course mean `.c:'. We're all making mistakes today!

cls

Re: [dev] Some core tools

[Connor Lane Smith]

On 2 February 2017 at 19:54, Markus Wichmann  wrote:
> GNU make style patsubst rules, i.e.
>
> %.o: %.c
> $(CC) $(CFLAGS) -o $@ $<
>
> Those are really useful.

While GNU's syntax can be more general, that rule can be done in POSIX make:

> .c.o:
> $(CC) $(CFLAGS) -c $<

Likewise,

> .o:
> $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<

cls

Re: [dev] s - suckless shell

[Connor Lane Smith]

On 13 August 2016 at 12:31, Connor Lane Smith <c...@lubutu.com> wrote:
> IO redirection being done by separate programs, though, seems like a
> wrong decision. Streaming the data through a separate process is
> considerably less efficient than just setting a file descriptor to an
> open file, and not always equivalent in behaviour either. For example,
> `tty < $TTY` is obviously very different to `cat $TTY | tty`. In my
> opinion this is a bug in your design, and needs to be fixed.

Thinking about it a little more, you could fix this problem without
incorporating IO redirection into the shell. As it stands, your
'redir-box' only supports e.g. `foo | > bar` or `< bar | foo`.
Instead, I suggest that you allow for more than one argument, where
arguments after the first comprise a command to be executed. That is,
instead, `> bar foo` or `< bar foo`. Incidentally, this exact syntax
is supported by traditional shells. Additionally, you can then chain
them like so: `< bar > baz foo`. Thus `< $TTY tty` can be used to
solve the problem I described above.

Thanks,
Connor

Re: [dev] s - suckless shell

[Connor Lane Smith]

Hi,

I'm not quite sure about this specific design, but I do think there is
still work to be done in shell design. We've not quite got there yet,
I think.

On 12 August 2016 at 22:41,   wrote:
> Tokenization [tokenizer.c]: Instead of the strange and complex way that
> normal shells work (where "$X" is different to $X for example) s works by a
> strict tokenize -> variable expansion -> parse -> execute pipeline. This
> makes it much easier to program with and less likely for scripts to break
> simply because your CWD has a space in it.

Is there no support for 'splatting' a string into several strings? rc
has a coherent approach to this, in that each variable is not a string
but a list of strings. 'Splat' should be supported, but only when done
explicitly.

> Variable expansion [variables.c]: The expander supports both $FOO and ${FOO}
> syntax, it just resolves environment variables.

Fair enough, I think non-environment variables are probably a mistake,
at least so long as they're not easily distinguished.

But I think functions and aliases (which I take it are also missing)
are the greater evil, since they are not first-class: `xargs ll` will
not work if `ll` is a function or an alias. If such things are to
exist, they must also be able to be found in $PATH, some way or
another. They are a real wart on shell languages.

> Parsing [parser.c]: There are just 3 binary operations |, && and || and '&'
> optional at the end of a line. There is no "if" or looping or anything.
> parser.c is 85 lines of code and uses my region [region.c] based allocator
> to simplify teardown of the structure when it needs to be free'd.

Fair enough, I think loops and the like might as well be done by
separate programs. We've even got higher-order functions like xargs.

> [supporting/*.c] Instead of redirection operators like <, > and >> being
> part of the language they are simply provided as supporting programs that
> should be added to the $PATH: < is basically just cat. The redirection
> operators are all packaged together in busybox style. Similarly glob is not
> part of the language, it is a 20 line script instead. You use it like this:
> glob rm *py

I'm not sure how I feel about glob being separate, but I can see how
it might be a good idea.

IO redirection being done by separate programs, though, seems like a
wrong decision. Streaming the data through a separate process is
considerably less efficient than just setting a file descriptor to an
open file, and not always equivalent in behaviour either. For example,
`tty < $TTY` is obviously very different to `cat $TTY | tty`. In my
opinion this is a bug in your design, and needs to be fixed.

In general, I appreciate the idea of slimming down the shell into a
minimalistic language, since I think shell languages have a tendency
to bloat, which is particularly bad when you start having to escape
everything, like bash's bloody exclamation mark (in double-quoted
strings, no less!). I think what's particularly useful about a very
slimline shell like this is that we could potentially use it to try
out new features that aren't in traditional shells, rather than
assuming that those shells got it right. I don't think I'd like to use
this particular shell language in everyday usage though, but I could
see it being nice for shell scripts, where the lack of features might
well be a feature (as there's less to go wrong).

I do agree though that 's' is a bit of an unfortunate name, and rc is
not as bloated as you made it out to be. But I hardly think that rc is
the be-all and end-all of shells.

Thanks,
cls

Re: [dev] [discussion] Cooperation between terminal and graphical programs

[Connor Lane Smith]

Hi Marc,

On 25 June 2016 at 14:48, Marc Collin  wrote:
> Is there any way to get this behavior on standard Linux with suckless
> tools (dwm, st, etc)?

Previous discussion about this [1] led to the xembed utility being
added to tabbed [2], which mimics this behaviour:

> In a terminal emulator within a tabbed session, the shell alias
> $ alias surf='xembed -e surf'
> will cause `surf' to open in a new tab, unless it is run in the background,
> i.e. `surf &', in which case it will instead open in a new window.

You can also hide the tab bar to get an experience even closer to that
of Plan 9. Being able to tab back to the tty a graphical program is
associated with is also quite useful.

[1] http://lists.suckless.org/dev/1504/26507.html
[2] http://git.suckless.org/tabbed/

Thanks,
cls

[dev] Re: JIT & VM discussion

[Connor Lane Smith]

Thanks for the suggestions, everyone.

The motive for this is essentially that I'd been playing around with
designing interpreters for various Turing-incomplete programming
languages, and I kept having to design and write new abstract
machines, which seemed like a lot of wasted effort. And JIT seemed
especially nice to have, since it would reduce the interpretation
overhead, although it isn't strictly necessary. As Kamil suggests, I
think that being able to have a portable bytecode interpreter may be
key, since then the JIT can simply act as an optimisation for certain
supported platforms, and then it won't tie the program to any
particular architecture.

So I think the closest to what I'm looking for might be Dis and QBE.

My problems with Dis are that it has a lot of higher-level features
(due to Limbo), and that it assumes garbage collection. A subset might
work, but since it's unsupported now anyway it might be worth just
learning from it, instead of actually adopting it. Lua has similar
problems with high-level language features and garbage collection,
neither of which fit in C without an additional object model on top,
which I'd like to avoid.

QBE seems like it could be good, although I couldn't tell when I
looked whether the intermediate language is structured or a bytecode.
In any case, I think the way it's designed rules out a portable C
interpreter, since it has no pointer type, for instance. It might be
relatively easy to adapt to the task though.

I'll have to give it some more thought.

Thanks again,
cls

[dev] JIT & VM discussion

[Connor Lane Smith]

Hi all,

I was wondering if others had an opinion on JIT. Suppose we don't need
anything fancy like adaptive optimisation, but just wanted to compile
a program at runtime. One possibility might be to generate C code and
store that in a file and then call the C compiler and then execute the
resulting binary... But that seems a bit unpleasant, prone to
compilation failure, and not particularly lightweight either.

One solution could be simply to produce assembly code, but then that
is tied to a specific architecture, which is unfortunate. There's also
LLVM, but that is a very big and complicated dependency, which
shouldn't really be necessary if we're just jitting something quickly
and don't mind it being a little unoptimised for the sake of
simplicity and speed of compilation. We just want to portably generate
machine code and then run it.

An ideal might be something like an abstract instruction set together
with a JIT for the abstract machine. To be honest a JIT might not even
be necessary so long as it is has very little interpretation overhead,
the instruction set is general purpose and fixed, and it plays well
with the C memory model.

Does anyone have any ideas?

Thanks,
cls

Re: [dev] Different versions of suckless libutf

[Connor Lane Smith]

Hi all,

Following this past conversation, I decided to reinstate rune validity
checks in libutf. Since people seem to be using my repo as a
submodule, I decided it was best to cater for that (somewhat
questionable) use case.

> I would have liked to have separated UTF-8 and Unicode support into two
> separate libraries. Unicode has changed the definitions of valid and
> invalid codepoints a number of times, whilst UTF-8 has remained as it
> is, unchanging. Likewise, the current version of Unicode ought not be
> necessary only to parse UTF-8 sequences. However, it is clear that it is
> expected that libutf will do this, and I think adding another library as
> a dependency would undermine the appeal of a minimalist UTF-8 library.
>
> It's not a very happy situation though, since attempting to catch all
> possible sources of invalid runes, rather than only those that are truly
> malformed UTF-8, would require much more code if it were to detect them
> at the earliest possible opportunity, as is done with things like
> overlong encodings. So my solution has been to treat those as a separate
> class of error, and to detect validity of the rune, as opposed to the
> UTF-8 sequence, as a matter of postprocessing.
>
> As I say, this isn't a happy situation, but I think this is the best
> compromise between those mortal enemies, pragmatism and idealism.

So, to reiterate the above, I've separated out that check, so there
are two distinct classes of error: UTF-8 errors, and Unicode errors.
The former, which are malformed UTF-8 sequences, are detected at the
earliest instant, whilst the latter, which are just invalid according
to the Unicode consortium, are detected only after the rune value has
been unpacked. I think that's the best compromise, such as it is.

Thanks,
cls

Re: [dev] [lnanosmtp]

[Connor Lane Smith]

On 11 June 2016 at 07:34,   wrote:
> Strings are not idenpotent. In C strings, any pointer inside
> of the string is a new string. Splitting strings is only
> writing a 0. Splitting strings in Pascal strings require to
> allocate a new chunk of memory and copy all the characters.

This is fixed with slices (like in Go) though, as those are not,

struct string { size_t size; char ar[]; };

but,

struct string { size_t size; char *ptr; };

> Fixed maximum size. Pascal strings used a byte for the size,
> and it meant that you could not have strings bigger than 256.
> Of course you can increment this size to whatever you want,
> but then you waste a lot of space.

Clearly the problem with the above is that there is a word of
overhead, instead of only a byte. Although note that since you can use
`struct string s` in place of `char *s`, the pointer itself adds no
additional overhead.

> In both strings you can mess everything if you access out of the limits,
> so they have the same problem.

A size field does make it much more efficient to perform a bounds
check though, which makes it easier to be absolutely sure (albeit with
a performance hit); e.g.

bool inbounds(struct string *s, size_t n) {
return n < s->size;
}

vs.

bool inbounds(char *s, size_t n) {
for (size_t i = 0; i <= n; i++)
if (s[i] == '\0')
return false;
return true;
}

So, so long as you're willing to take the performance and space hit,
slices probably are safer. But since everything I've said above is
also true for arrays, and C arrays don't have explicit length either,
not very much is really gained. Ultimately, if you want that kind of
assurance of safety at the cost of performance, you'd probably be
better off using a memory-safe language instead of C.

Although one unfortunate side effect of C strings is that as soon as
you have to deal with the possibility of null bytes, everything gets a
bit awkward.

cls

Re: [dev] pledge(2) patches

[Connor Lane Smith]

On 6 June 2016 at 12:19, Martin Kühne  wrote:
> Can it somehow be made to keep its effect across the exec family of syscalls?

My understanding is that one can pledge not to call exec, but if one
explicitly permits exec and it *is* called, the pledge no longer holds.

cls

Re: [dev] pledge(2) patches

[Connor Lane Smith]

On 6 June 2016 at 11:51, Martin Kühne  wrote:
> I don't understand the purpose of pledge, since it's under the control
> of the programmer, but so is what the program does just as well. In
> what way is the programmer supposed to prevent himself from doing what
> they were going to do anyway?

The idea is to prevent oneself from inadvertently doing what one
*didn't* mean to do. For example, in the event of an exploit, the
process cannot be made to do something it has pledged not to. This
limits the impact of security holes.

cls

Re: [dev] Different versions of suckless libutf

[Connor Lane Smith]

On 1 June 2016 at 07:42, Ben Woolley  wrote:
> I am pretty sure you are aware of this already, but the UTF-8 RFC
> defines Unicode quirks as part of the UTF-8 definition. Even the title
> is "UTF-8, a transformation format of ISO 10646". It does not call it a
> general purpose transformation format of 31-bit integers. I didn't
> glance at other definitions, if they exist. Maybe they say something
> else.

I may have been a bit loose with the terminology. However, UTF-8 was
originally defined as an encoding of "character values in the range
(0, 0x7FFF)," as it was for UCS-4, which went beyond the mere
0x limit of Unicode at the time (which was equivalent to UCS-2).
Only later were the Unicode restrictions put in place, at the same
time that the Unicode limit was increased to 0x10 and UTF-16 was
made to use surrogates as a crutch. (And the fact that these were made
to pollute the character space demonstrates why UTF-16 is not only
useless, but worse than useless.)

It's true that it isn't defined as a general-purpose format for 31-bit
integers, but rather of "character values" that happen to be 31-bit
integers. However, the fact remains that it *is* just an encoding of
31-bit integers. Those integers are (almost) always unpacked and only
then checked for Unicode validity. It seems to me that if you have a
char32_t, you should be able to check whether that character is a
Unicode character with some function like isvalidrune(). Plan 9 seems
to have no way to do this, although my earlier libutf versions had
runelen() return 0 for invalid Unicode.

> But anyway, I am wondering why you seem to have mental pressure to
> generalize it more. Is it more of a design aesthetic thing? I can see
> that. Personally, I could see having separate functions, but I think
> they should be packaged together, because if someone really wanted to
> rip out the general pieces, they can easily do that when needed.

It probably is mostly about aesthetics. One frustration is the
dependence on the Unicode standard, since they keep changing what
values are valid or invalid (in 1996 and 2003), when the actual UTF-8
format hasn't changed one bit since 1993. So I feel that the UTF-8
codec itself should ignore those political issues and simply deal with
UTF-8 proper. You can check whether a value is valid Unicode once
you've got it from the UTF-8 stream, and do so with the same function
as you would if you were reading UTF-16 or UTF-32. Or any other format
people might use, like UTF-1 or UTF-7 (or not).

This interface (reading and validating a UTF-8 rune) may well ought to
be available as one function, but I feel that it should be a wrapper
for a more fundamental UTF-8 decoder, because the latter is 'forever
and always', whereas the former depends on whichever version of
Unicode we're on. But even if you do think that the fundamental
decoder should validate Unicode in the sense of forbidding surrogates
etc., the is*rune() and to*rune() functions, and anything that would
properly handle graphemes according to Unicode, or anything involving
canonicalisation or any of the other incredibly complicated aspects of
the Unicode standard, are nothing to do with UTF.

(Anyway, UTF-8 is really just a framing protocol for 6-bit data, with
sync and roll flags. :p)

cls

Re: [dev] Different versions of suckless libutf

[Connor Lane Smith]

On 31 May 2016 at 18:43, FRIGN  wrote:
> as a quick note, the sbase libutf is probably the most feature-rich one.
> The version by cls suffers from multiple issues, even though it might
> be the most recent.

Strictly speaking they're all by me, since I started it (and sbase) in
the first place. But there we are.

> I am currently working on a new libutf which is much simpler, much
> more secure (de/encoder) and actually gets the grapheme handling right.

One of the reasons I'm not pushing for any particular solution to the
fragmentation problem is that I'm not sure what libutf should actually
do. There are three components that are distinguishable in the Plan 9
API, which are UTF-8 (runetochar, chartorune, utf*, etc), UTF-32
(runestr*), and Unicode (is*rune, etc).

The trouble is I don't think it's necessary for a single library to do
all of these things. All UTF-8 is is an encoding of 31-bit integers,
and UTF-32 is another encoding. The stuff specific to Unicode, which
requires the latest Unicode database and all that, is really a
separate issue -- as is the rejection of certain values, like
surrogates or values over 0x10, both of which are only invalid
because of the braindead UTF-16 encoding. And grapheme handling is
another thing which has nothing actually to do with UTF.

So in earlier versions of libutf I was vigilant in rejecting those
values that Unicode say are invalid, but in my latest version on
github I've started only rejecting overlong sequences, since the
others are still (in my view) valid UTF-8 even if they aren't valid
Unicode. Is this the right thing to do? I've not yet made up my mind.
But my feeling is that the API for reading UTF-8 should be separate
from that which deals with Unicode codepoints and graphemes that so
happen to have been encoded in UTF-8. The two are essentially
orthogonal, though are often conflated.

Incidentally, I also changed my latest version to only ever need one
byte of lookahead. For one thing, the Plan 9 version will say that a
rune is not full even if it is, if it is malformed, which is fixed in
my implementation. But another thing, which is only in my latest
version, is that it always reads the fewest bytes needed to determine
that the sequence is malformed. One benefit of this is that if you're
reading with fgetc(), you can then ungetc() a byte that showed that
the sequence was malformed (say, it was too short), and you are only
guaranteed (by POSIX) to be able to ungetc() a single byte.

That may not be relevant for sbase, of course, but I'm just saying
there's a reason for the slight difference in complexity between the
version in sbase and the latest version on my github.

cls

Re: [dev] Different versions of suckless libutf

[Connor Lane Smith]

Marc -- I remember now that you emailed me about this, and it must
have slipped my mind. Sorry about that.

I personally have no strong opinion on what should be done with the
different repos, since I consider libutf to be mostly a pet project;
and I don't think there's any problem with sbase having an in-tree
fork. But it is worth noting that git.suckless.org/libutf is
unmaintained.

Thanks,
cls

Re: [dev] [dwm] [patch] config.o

[Connor Lane Smith]

On 15/05/2016, Hiltjo Posthuma  wrote:
> I'm against this idea. It is simpler to hack if everything is one file which
> is
> normal for alot of suckless tools. It is not very clear to me what is
> considered a config or "the code" neccesarily.

I personally feel that the benefits of having only one file are lost
if that file is very large. It would be nice, I think, if dwm were
split over a few files. Code dealing with different data structures
being grouped together is more helpful, I feel, than putting all of
the functions in together, alphabetically.

But I'm not sure this is how it should be done. Some functions, the
ones dealing with the mouse especially, seem out of place in config.c,
but are there because they are used as button handlers and I put all
of the functions with that signature into config.c. On reflection I
think that if this were done then the button handlers in that case
should be wrappers for another function in the core dwm code which
actually does the mouse stuff.

And as Kamil says, it would break everyone's configurations. Still, I
think the layouts at least would be better placed in the config, since
there's really no reason for them to be in dwm.c, and that would
encourage people to make their own layouts in their config instead of
being inclined to patch dwm proper.

Ultimately though I think this patch might just be too ambitious,
which is one reason I was hesitant to post it. But it may still be
food for thought.

[dev] [dwm] [patch] config.o

[Connor Lane Smith]

Hi all,

Attached is a dwm patch that pulls out all of the key and button
handlers, and all of the layouts, into a new file called config.c,
replacing config.h. The idea is that it makes it clearer what is dwm
proper and what is just a part of the default config.

I've sat on this patch for about half a year, and I've still not made
my mind up as to whether it's a good idea or not. But I thought I
might as well post it on here anyway.

Thanks,
cls
commit af3575a3388b6518de395a09e0becad0d486df76
Author: Connor Lane Smith <c...@lubutu.com>
Date:   Mon Nov 23 17:29:28 2015 +

separate config.o

diff --git a/Makefile b/Makefile
index 1ea40b7..f95c9db 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@
 
 include config.mk
 
-SRC = drw.c dwm.c util.c
+SRC = config.c drw.c dwm.c util.c
 OBJ = ${SRC:.c=.o}
 
 all: options dwm
@@ -18,11 +18,11 @@ options:
@echo CC $<
@${CC} -c ${CFLAGS} $<
 
-${OBJ}: config.h config.mk
+${OBJ}: dwm.h config.mk
 
-config.h:
-   @echo creating $@ from config.def.h
-   @cp config.def.h $@
+config.c:
+   @echo creating $@ from config.def.c
+   @cp config.def.c $@
 
 dwm: ${OBJ}
@echo CC -o $@
@@ -35,8 +35,8 @@ clean:
 dist: clean
@echo creating dist tarball
@mkdir -p dwm-${VERSION}
-   @cp -R LICENSE TODO BUGS Makefile README config.def.h config.mk \
-   dwm.1 drw.h util.h ${SRC} dwm.png transient.c dwm-${VERSION}
+   @cp -R LICENSE TODO BUGS Makefile README config.def.c config.mk \
+   dwm.1 drw.h dwm.h util.h ${SRC} dwm.png transient.c 
dwm-${VERSION}
@tar -cf dwm-${VERSION}.tar dwm-${VERSION}
@gzip dwm-${VERSION}.tar
@rm -rf dwm-${VERSION}
diff --git a/README b/README
index 7abf1cf..1208997 100644
--- a/README
+++ b/README
@@ -47,5 +47,5 @@ like this in your .xinitrc:
 
 Configuration
 -
-The configuration of dwm is done by creating a custom config.h
+The configuration of dwm is done by creating a custom config.c
 and (re)compiling the source code.
diff --git a/config.def.c b/config.def.c
new file mode 100644
index 000..dfa8a17
--- /dev/null
+++ b/config.def.c
@@ -0,0 +1,528 @@
+/* See LICENSE file for copyright and license details. */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drw.h"
+#include "util.h"
+#include "dwm.h"
+
+/* appearance */
+const char *fonts[] = {
+"Sans:size=10.5",
+"VL Gothic:size=10.5",
+"WenQuanYi Micro Hei:size=10.5",
+};
+const int nfonts = LENGTH(fonts);
+
+const char normbordercolor[] = "#44";
+const char normbgcolor[] = "#22";
+const char normfgcolor[] = "#bb";
+const char selbordercolor[]  = "#005577";
+const char selbgcolor[]  = "#005577";
+const char selfgcolor[]  = "#ee";
+const unsigned int borderpx  = 1;/* border pixel of windows */
+const unsigned int snap  = 32;   /* snap pixel */
+const int showbar= 1;/* 0 means no bar */
+const int topbar = 1;/* 0 means bottom bar */
+
+/* tagging */
+const char *tags[] = { "1", "2", "3", "4", "5", "6", "7", "8", "9" };
+const int ntags = LENGTH(tags);
+
+/* compile-time check if all tags fit into an unsigned int bit array. */
+struct NumTags { char limitexceeded[LENGTH(tags) >= sizeof(unsigned int) * 8 ? 
-1 : 1]; };
+
+const Rule rules[] = {
+   /* xprop(1):
+*  WM_CLASS(STRING) = instance, class
+*  WM_NAME(STRING) = title
+*/
+   /* class  instancetitle   tags mask isfloating   
monitor */
+   { "Gimp", NULL,   NULL,   0,1,   -1 },
+   { "Firefox",  NULL,   NULL,   1 << 8,   0,   -1 },
+};
+const int nrules = LENGTH(rules);
+
+/* layout(s) */
+const float mfact = 0.55; /* factor of master area size [0.05..0.95] */
+const int nmaster = 1;/* number of clients in master area */
+const int resizehints = 1;/* 1 means respect size hints in tiled resizals 
*/
+
+static void monocle(Monitor *m);
+static void tile(Monitor *m);
+
+const Layout layouts[] = {
+   /* symbol arrange function */
+   { "[]=",  tile },/* first entry is default */
+   { "><>",  NULL },/* no layout function means floating behavior 
*/
+   { "[M]",  monocle },
+};
+const int nlayouts = LENGTH(layouts);
+
+void
+monocle(Monitor *m)
+{
+   unsigned int n = 0;
+   Client *c;
+
+   for (c = m->clients; c; c = c->next)
+   if (ISVISIBLE(c))
+   n++;
+   if (n > 0) /* override layout symbol */
+   snprintf(m->ltsymbol, sizeof m->ltsymbol, &qu

Re: [dev] structural regular expression support for vis

[Connor Lane Smith]

On 28 March 2016 at 18:47, Connor Lane Smith <c...@lubutu.com> wrote:
> On 28 March 2016 at 18:46, Connor Lane Smith <c...@lubutu.com> wrote:
>> Diff attached, if you're interested.
>
> For real this time.

I also just discovered that it does manage to compile without those
changes if you run ./configure first. Sorry for the noise, I'm used to
Makefiles working without autoconfig.

Re: [dev] structural regular expression support for vis

[Connor Lane Smith]

On 28 March 2016 at 18:46, Connor Lane Smith <c...@lubutu.com> wrote:
> Diff attached, if you're interested.

For real this time.
diff --git a/Makefile b/Makefile
index 97adf0d..7b7d4cb 100644
--- a/Makefile
+++ b/Makefile
@@ -12,8 +12,8 @@ CONFIG_LUA ?= 1
 CONFIG_ACL ?= 0
 CONFIG_SELINUX ?= 0
 
-CFLAGS_STD ?= -std=c99 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -DNDEBUG
-LDFLAGS_STD ?= -lc
+CFLAGS_STD ?= -std=c99 -D_DARWIN_C_SOURCE -D_POSIX_C_SOURCE=200809L 
-D_XOPEN_SOURCE=700 -DNDEBUG
+LDFLAGS_STD ?= -lc -llua -lncurses -ltermkey
 
 CFLAGS_VIS = $(CFLAGS_AUTO) $(CFLAGS_TERMKEY) $(CFLAGS_CURSES) $(CFLAGS_ACL) \
$(CFLAGS_SELINUX) $(CFLAGS_LUA) $(CFLAGS_STD)
diff --git a/view.c b/view.c
index 0dd185a..8cdc31a 100644
--- a/view.c
+++ b/view.c
@@ -160,7 +160,7 @@ static void view_syntax_color(View *view) {
int token_count;
 
if (lua_isfunction(L, -4) &&  !lua_pcall(L, 3, 1, 0) && lua_istable(L, 
-1) &&
-  (token_count = lua_objlen(L, -1)) > 0) {
+  (token_count = lua_rawlen(L, -1)) > 0) {
 
size_t pos = lexer_before - (lex_text - text);
Line *line = view->topline;

Re: [dev] structural regular expression support for vis

[Connor Lane Smith]

On 27 March 2016 at 17:10, Marc André Tanner  wrote:
> You could also try `make local` which might or might not work ...

It didn't. Anyway, today I unfortunately found myself with nowt but a
Mac, though I did manage to get vis to compile. I had to make a couple
of changes to get it to work. Diff attached, if you're interested. It
needed _DARWIN_C_SOURCE because SIGWINCH is neither POSIX nor XSI.

Some problems I came across:

Just a config issue I suppose, but I kept quitting the editor by
accident, having typed 'x/foo/' without ':sam' in front of it.

If you write ':sam x' then I would expect it to split the selection
into lines (defaulting to /.*/), as 'x' would in sam. Instead it says
"bad regular expression."

':sam x/.*/g/foo/' selects those lines containing foo, but ':sam
x/.*/' followed by ':sam g/foo/' seems to result in all but the last
selection being lost.

Selections seemed dodgy after I did ':sam y/bar/'. I'm not sure what
their behaviour was after that, but it didn't seem at all consistent
again until I hit ESC.

I also got it to segfault on master, but there was a bit of
key-mashing (in the command entry box) and I haven't managed to
reproduce it.

I'll let you know if I have any more progress with it.

Thanks,
Connor

Re: [dev] structural regular expression support for vis

[Connor Lane Smith]

Hi Marc,

On 27 March 2016 at 09:16, Marc André Tanner  wrote:
> Did anyone else participating in this thread (Connor?, Greg?) bother
> to give it a try?

Sorry, it's on my to-do list, but I had some trouble compiling and
haven't got around to giving it another go. It seems there's a new
dependency, libtermkey, which isn't on Debian stable. I'll see if I
have time this afternoon.

Thanks,
Connor

Re: [dev] another text user interface for sam

[Connor Lane Smith]

On 2 March 2016 at 18:26, Maxime Coste  wrote:
> Yeah, I'd really like to get rid of boost, and possibly migrate to a
> lighter regex lib. The problem is that no currently available libs match
> the required feature set

Thanks for the list of issues. Perhaps we can work these in to a library.

>  * support lookaheads and lookbehinds, until I find a clean, alternative way
>to express 'a double quote that is not preceeded by a pair number of
>antislash' to match the closers of C strings (as an example of their
>current usage)

How about,

"([^\\"]|\\.)*"

cls

Re: [dev] another text user interface for sam

[Connor Lane Smith]

On 2 March 2016 at 16:06, Greg Reagle  wrote:
> Well sam has ISRE, but it lacks a nano/vi/emacs-like (full screen 
> interactive) TUI.

I think the key to *interactive* structural regular expressions is
that it must be possible to position oneself 'within' an expression.
Suppose you write x/re/, then sam will simply print all of the
matching substrings, just as though you'd written x/re/p. So dot does
not reflect the fact that if you added further commands then they
would be performed on each of those matches. In order to be
interactive, it must be possible to write the command interactively,
rather than composing the whole expression in one go and sending it to
the editor to evaluate. That's why multiple cursors are crucial: they
allow you to collect all the matches, then to decide how to *interact*
with them. So I don't agree that sam's structural regular expressions
are interactive in that sense. That's my main complaint.

cls

Re: [dev] another text user interface for sam

[Connor Lane Smith]

On 2 March 2016 at 15:45, Maxime Coste  wrote:
> How does sam handles parallel grouping when we get multiple incompatible 
> changes
> to the same range of text ?

It panics.

Incidentally, I notice that Kakoune uses Boost's regular expressions,
which means that reverse searches are very inefficient. That's rather
unfortunate. Have you considered using an alternative regular
expression library, if there were one with the necessary features
(like we've been discussing)?

cls

Re: [dev] another text user interface for sam

[Connor Lane Smith]

On 1 March 2016 at 20:35, Marc André Tanner  wrote:
> As an example, swapping two words with
>
>  ,x[a-zA-Z]+/{
>   g/fred/ v/./ c/jim/
>   g/jim/ v// c/fred/
>  }
>
> which is mentioned in both the sam tutorial and the cheatsheet would
> no longer work.

That's true; I suppose it depends how useful that is in general. It
might be nice to have both behaviours really, one 'seq' and one 'par'
(cf. ';' and '&' in sh). The former would suffice for most use cases,
and would be much faster. The drawback of this being that we'd have to
implement the parallel version too anyway (though we could leave that
for later).

On 1 March 2016 at 20:56, Marc André Tanner  wrote:
> Misunderstanding on my part I guess. These are just limitations of
> the regex(3) API but have no particular relevance for *structural*
> regular expressions. I.e. it is possible to build a structural
> regexp library on top of this crippled interface it probably just
> wont be particularly efficient.

Fair enough. It has those limitations in common with every other
regular expression library API I know of, though. Of course, it would
be theoretically possible to build structural regular expressions on
top of regex(3), but it would be an abomination.

> For others wanting to take a look, I guess you are referring to
> the following papers:
>
>  - Two-pass greedy regular expression parsing
>  - Optimally Streaming Greedy Regular Expression Parsing

Yes indeed.

> What is in your opinion the current state of the art technique/algorithm?

Well, I think the 'two-pass' approach, described in the first of those
papers, is particularly interesting. There's been a big resurgence of
interest in Thompson's VM-style approach to regular expressions,
probably mostly because of Russ Cox's excellent write up on them.
Which is fantastic, because it's clearly superior to the backtracking
approach. But all of that, all of the benefits, are sort of thrown out
the window as soon as you start looping over the matches of a
sufficiently nondeterministic expression. Consider the following two
structural regular expressions, which in this file have identical
matches:

$ time ssam 'x/./' rc.1 >/dev/null
real0m0.020s
user0m0.008s
sys 0m0.004s

$ time ssam 'x/(.*\n)+\n|./' rc.1 >/dev/null
real0m9.730s
user0m9.672s
sys 0m0.048s

The matches are identical, and yet the latter takes a vastly greater
amount of time -- quadratic to the size, in fact. I was originally
going to use my dictionary file as the example, but it never finished
and I had to kill sam. Yet, using the 'two-pass' approach, this could
be done in linear time. The 'lean log' they use in their paper would
take a bit more space, about one bit per byte for the above example,
but I think if we do it per block we should be able to cut down on
that massively, perhaps as little as one bit per state per block,
which would obviously be much more manageable.

I haven't thought so much about the 'optimally streaming' part yet. I
don't think it would be necessary to go to the lengths they do in
their paper, since we don't actually need strict optimality, but it
would be nice if we could reduce the amount of data we have to read in
order to get a match. One nice benefit of this is it would strike off
the bug identified in ssam(1): "Ssam consumes all of standard input
before running the script." If we were to stream data through a fairly
lazy regular expression engine then this would hopefully be pretty
easy to fix in a future ssam implementation.

Thanks,
cls

Re: [dev] another text user interface for sam

[Connor Lane Smith]

On 1 March 2016 at 17:12, Marc André Tanner  wrote:
> All commands of a group should operate on the original state of the text.

Is that strictly necessary? I know that's how sam and acme behave, but
series of commands outside those {} blocks occur in sequence (not all
performing on the original text), and to be honest that seems like it
might be more intuitive. It would also be much easier to implement.
There are probably drawbacks, but all in all I would personally be
quite happy with the more straightforward sequential behaviour. I'd
even be happy with forbidding overlapping regions being selected by
separate cursors in the first place, let alone being modified by them.

cls

Re: [dev] quirks with sam's structured regexps

[Connor Lane Smith]

On 1 March 2016 at 17:00, Connor Lane Smith <c...@lubutu.com> wrote:
> acme/regx.c certainly was derived from sam/regexp.c. See attached diff.

I forgot to also check the other files necessary for sam's command
language, but they too seem similarly derived:

* sam/cmd.c -> acme/edit.c
* sam/parse.h -> acme/edit.h
* sam/regexp.c -> acme/regx.c
* sam/xec.c -> acme/ecmd.c

cls

Re: [dev] another text user interface for sam

[Connor Lane Smith]

On 1 March 2016 at 17:12, Marc André Tanner  wrote:
> I think structural regexp will integrate nicely with multiple selections.
>
> Basically if you omit the command of a structural regexp the editor
> would switch to visual mode and add a selection for every match. If you
> are already in visual mode then the existing selections would be used
> as ranges for an implicit leading loop construct (x/ in sam).
> That is for an existing selection x/ and y/ could be used to split it.
> Similarly the conditionals g/ and v/ would be used to keep / discard
> selections.

I agree (strongly!). My main complaint with sam is its inability to
reflect the multiple selections implied by its command language. It
would be fantastic if we could get that sorted, and vis may well be a
good place to do it. That isn't incompatible with the library idea, of
course.

cls

Re: [dev] another text user interface for sam

[Connor Lane Smith]

On 29 February 2016 at 18:51, Greg Reagle  wrote:
> Another approach would be to write a structural regexp library.  Then
> structural regexp's could be available to other programs.

I've been thinking about this, actually. What might be even better is
a regular expression library which just makes it easy to build
structural regular expressions on top of it. The interfaces of common
libraries, be they Unix or Plan 9 or RE2, are not sufficiently
expressive to support this, which is why those programs that do
feature structural regular expressions have a custom engine baked in.
This would require quite careful planning of the library's API in
order to work well, though. I'm giving it some thought at the moment
anyway.

cls

Re: [dev] another text user interface for sam

[Connor Lane Smith]

On 26 February 2016 at 16:11, Greg Reagle  wrote:
> Thanks for your thoughtful reply.  What about a third option: use the core
> (editing and structural regexps) of sam (the part that runs with sam -d
> perhaps) and add a TUI.  Do we have to re-use the undocumented binary
> protocol just because samterm uses it?

I suppose that's possible, it just feels like a waste of sam's talent
as a remote editor over slow connections... Although I admit I've put
that to use only a couple of times.

Anyway, that could work. If we were to do that then I'd suggest we
first rip out all of sam's mesg and rasp code and work from there. The
code for the command line interface ought to stay.

Such a UI likely won't have some features one might really wish for
from a sregexp-driven text editor though. Still, it'd better than what
we have now.

cls

Re: [dev] another text user interface for sam

[Connor Lane Smith]

You certainly aren't alone. I expect I'm the local expert on trying to
draw blood from that stone.

The problem, aside from my not having enough time to do any worthwhile
hobby programming at the moment, is that communication between sam and
samterm is an ad hoc binary protocol, with absolutely zero
documentation (as confirmed by Rob Pike), which is quite specifically
tailored to those two programs' needs. I did manage to get the two to
communicate enough to open new windows and do basic editing of text,
but it's pretty fiddly, and I'm not sure I ever got the locking quite
right. (Certain actions cause the terminal implicitly to 'lock' so
that the user cannot interact with it, after which the editor proper
sends an 'unlock' message. I'm not sure exactly when this happens.)
Someone with more time on their hands may be able to get further than
I did with this, although there are certain UI limitations inherent in
the protocol.

This is a source of continual frustration for me. It's got to the
point where if I need to make some trickier changes to a structured
file format like BibTeX, I'll open up samterm and make the changes
with that. Literally the best tool for the job is an editor from the
'80s that hasn't been supported by anyone in god knows how long.
Beggars belief. I do think a better longterm solution would be to
implement a whole new editor with sregexps, as a reimplementation
could also support proper streaming and maybe even an awk dialect (as
described in Pike's paper on structural regular expressions), but
obviously that would require a good deal of work.

In any case, if there *were* an attempt, with more manpower, either to
reverse engineer the binary sam protocol or to implement a new editor,
then I'd be very happy to lend a hand.

Thanks,
cls

Re: [dev] [ANNOUNCE] vis-0.1: first release of a vim-like editor

[Connor Lane Smith]

I think this is pushing it for a 2015 release. But I'll be sure to
give it a go asap, 2016. :)

cls

Re: [dev] [dwm] 6.1 release

[Connor Lane Smith]

On 7 December 2015 at 15:51, Jakub Lach  wrote:
> What I'm trying to say, is that 6.1 is a little more
> POLA violating, than dwm releases used to be.

I do think it a little unfortunate that dwm release numbering means
essentially nothing. The jump from 6.0 to 6.1 was far greater than 5.9
to 6.0 was, which is surprising given that most software uses
major-minor versioning.

cls

Re: [dev] Re: [sbase] cal doesn't highlight current day

[Connor Lane Smith]

On 20 November 2015 at 13:13, FRIGN  wrote:
> I think there should be no discussion without a patch. I don't want to see
> anybody express his opinion here unless he has a patch in his attachments.

I've attached a patch. It's not too bad, although it does have ugly
escape codes. But I don't actually mind either way.

Thanks,
cls


patch
Description: Binary data

Re: [dev] Re: [sbase] cal doesn't highlight current day

[Connor Lane Smith]

On 20 November 2015 at 18:40, Connor Lane Smith <c...@lubutu.com> wrote:
> I've attached a patch. It's not too bad, although it does have ugly
> escape codes. But I don't actually mind either way.

Slightly uglier bugfix.

cls


patch
Description: Binary data

Re: [dev] a suckless hex editor

[Connor Lane Smith]

On 13 November 2015 at 20:42, pancake  wrote:
> Also, echo is a buildtin, so dont use absolute path for it

My guess is the path was added because the builtin echo may not
support the -e flag. But that's because it's non-standard -- as are
all echo flags, really -- and as Dimitris says printf should be used
instead.

Re: [dev] [PATCH 1/1] remove useless dup()

[Connor Lane Smith]

Hi,

On 8 July 2015 at 11:32, Christian Hesse l...@eworm.de wrote:
 We are ignoring return value of dup(), so just remove it.

This code was brought up a few months ago [1]. The return value is
ignored because, as STDIN_FILENO is 0 and has just been closed, the
returned new file descriptor must be 0. A number of us think that the
implicitness here is a mistake, and that dup2 should be used instead
of close  dup, but the devs apparently disagree.

[1]: http://lists.suckless.org/dev/1504/26505.html

Thanks,
cls

Re: [dev] surf release?

[Connor Lane Smith]

On 1 June 2015 at 15:33, Martti Kühne mysat...@gmail.com wrote:
 However upstream is not everyone's taste either, in that configuration
 changes require recompiling of the respective binary.

I'm quite happy using the default configuration for most tools though,
as are a lot of people. And since it's the default it's a perfectly
reasonable candidate for packaging. The only changes I would expect in
Debian would be things like using x-terminal-emulator in place of
st in dwm/config.h.

Ultimately the problem being solved is that the code in git can be
fairly unstable, as they're being actively worked on. Releases are
intended to be stable snapshots of the code. Whether or not you then
proceed to package the release is neither here nor there really.

Thanks,
cls

Re: [dev] How to use ssam in Ubuntu 14.04

[Connor Lane Smith]

On 7 May 2015 at 20:12, Teodoro Santoni asbras...@gmail.com wrote:
 ssam is an rc script. You can download it from plan9port or if i recall 
 correctly from cat-v and put it in your path.

It's also in the 9base git repo [1], just not in a release.

[1]: http://git.suckless.org/9base/tree/ssam

cls

Re: [dev] Odds and ends (2/2): $XEMBED

[Connor Lane Smith]

On 4 May 2015 at 11:56, Roberto E. Vargas Caballero k...@shike2.com wrote:
 The idea is good, but it means that you have to modify all the programs
 to accept this new feature. If you want to experiment with this idea
 you can try to add this variable in st and read it in surf.

I've written a wrapper which makes a given program support this, and
it's pretty tiny, too. Attached. Sample usage:

 #!/bin/sh
 exec 9embed -e surf $@

I've not found time to add the functionality into a terminal like st
yet, but I was happy to discover that tabbed already sets XEMBED, and
the wrapper works as expected: 'surf ' will open surf in a new
window, whereas 'surf' will open it in a new tab.

Thanks,
cls
/* (c) Connor Lane Smith, 2015 */
#include fcntl.h
#include stdio.h
#include stdlib.h
#include unistd.h

int
main(int argc, char **argv)
{
	if(argc  3) {
		fprintf(stderr, usage: %s flag cmd ...\n, argv[0]);
		return 2;
	}

	char *xembed = getenv(XEMBED);

	if(!xembed)
		goto noembed;

	int tty = open(/dev/tty, O_RDONLY);

	if(tty  0)
		goto noembed;

	pid_t pgrp = getpgrp();
	pid_t tcpgrp = tcgetpgrp(tty);

	close(tty);

	if(pgrp == tcpgrp) { // in foreground of tty
		argv[0] = argv[2];
		argv[2] = xembed;
	}
	else {
noembed:
		argv += 2;
	}

	execvp(argv[0], argv);

	perror(argv[0]); // failed to execute
	return 1;
}

Re: [dev] Odds and ends (2/2): $XEMBED

[Connor Lane Smith]

On 6 May 2015 at 11:43, Connor Lane Smith c...@lubutu.com wrote:
 I've not found time to add the functionality into a terminal like st
 yet, but I was happy to discover that tabbed already sets XEMBED, and
 the wrapper works as expected: 'surf ' will open surf in a new
 window, whereas 'surf' will open it in a new tab.

In fact, leaving that for tabbed to do could well be enough. If you
run surf so it opens in a new tab then you can switch back to the
terminal if you wish, which couldn't be done in Plan 9, but seems
reasonably useful.

With that in mind, might 9embed (perhaps under another name) be
suitable to add to the tabbed distribution?

cls

Re: [dev] Odds and ends (2/2): $XEMBED

[Connor Lane Smith]

On 6 May 2015 at 11:59, Connor Lane Smith c...@lubutu.com wrote:
 With that in mind, might 9embed (perhaps under another name) be
 suitable to add to the tabbed distribution?

Having had Christoph's approval, I've attached a patch which adds the
utility (under the name of xembed) to tabbed.

Thanks,
cls


0001-add-xembed-wrapper-utility.patch
Description: Binary data

Re: [dev] Odds and ends (2/2): $XEMBED

[Connor Lane Smith]

On 6 May 2015 at 15:28, Jason Woofenden ja...@jasonwoof.com wrote:
 If you don't replace the terminal window, then you're just talking
 about window management, which should perhaps be done with the
 window manager. The XEMBED thing only works on a few clients. The
 WM can meddle with just about all the clients.

I'm not sure this can be done for clients not supporting an XEmbed
flag, since there is no way in general to associate PIDs with XIDs.
The two processes have to be in cahoots.

 Another way you can get close to having the new graphical client
 replace your terminal is to auto-close the terminal by binding a
 key in your shell to run the program you typed in the background
 and then close the terminal.

This has a few drawbacks:

* You have to remember a new keybind, only for backgrounding X clients.
* If the command fails you can't tell or see why, since stderr is lost.
* Once the command has finished you can't go back to the terminal.

All in all, I think having a wrapper for this is worthwhile.

Thanks,
cls

Re: [dev] [ST] [PATCH] Changed type for UTF-32 codepoints from long to uint_least32_t

[Connor Lane Smith]

Hi,

On 5 May 2015 at 19:31, suigin suigin@national.shitposting.agency wrote:
 Hi all, here's a patch that changes occurences of long to uint_least32_t
 where it's being used to store UTF-32 codepoints, as was previously
 discussed. Other cases where long is used are preserved as is.

I get the feeling we should typedef uint_least32_t Rune, as in libutf,
so we don't have to have this long-winded and somewhat cryptic type
everywhere.

cls

Re: [dev] [st utf8 3/4] Change internal character representation.

[Connor Lane Smith]

On 4 May 2015 at 11:30, Roberto E. Vargas Caballero k...@shike2.com wrote:
 But uint32_t is not guaranteed to be present in all the implementations

uint32_t is guaranteed in POSIX 2004, but you may not want to rely on that.
uint32_least_t, which would suffice, is guaranteed in C99.

cls

Re: [dev] [sbase] Use of libutil

[Connor Lane Smith]

Reading the link again, it seems that the people 'helpfully'
forwarding messages to this mailing list aren't the same as those
authoring the messages. With that in mind, I'd like to stress that my
irritating is towards those doing the forwarding, i.e. Marc, and not
those just talking about the tools elsewhere, i.e. 'Cudder'. It is
perfectly reasonable to discuss the benefits and drawbacks of whatever
programming decision on another forum, and according to the etiquette
there. What isn't so reasonable is to forward those messages, given
their tone, to this mailing list. That's poor manners.

cls

Re: [dev] [sbase] Use of libutil

[Connor Lane Smith]

Hi Marc,

You really don't have to be such a twat about all this. Just offer
your suggestion without the unnecessary abrasiveness.

What I got from your link is that someone negatively compared your
work to sbase, and now you've got a bee in your bonnet over it. Are we
really going to have to put up with this noise?

Thanks,
cls

Re: [dev] [st] [PATCH] Replace close and dup with dup2.

[Connor Lane Smith]

Hi,

I'm personally in favour of using dup2. It is quite clear that
dup2(cmdfd, STDIN_FILENO) duplicates the fd into the position of
STDIN_FILENO. That's what it says. On the other hand, the combination
of close(STDIN_FILENO) and dup(cmdfd) is less efficient (two syscalls)
and also means that the reader is forced to infer that because
STDIN_FILENO, being fd 0 and therefore now the first available fd, is
the one that will be taken by the following dup -- assuming that the
close succeeded, which is not checked.

Note that dup2 came later, so earlier texts which use both close and
dup may simply be out of date. Regardless, the idiom is out of date,
and should be replaced with dup2. And even if you disagree, you have
to check the return value(s).

Thanks,
Connor

[dev] Odds and ends (1/2): next.sh

[Connor Lane Smith]

Hi all,

These are just a couple of thoughts I've had that we've discussed a
little in IRC recently. They aren't exactly earth-shattering, but I
think they might still be of use to someone.

Shell aliases which give default arguments, like alias ls='ls -1', are
useful but must be invoked from the shell, which means they aren't
'first class citizens' as programs in Unix. The solution, then, is to
have small scripts in ~/bin which wrap the program, like ~/bin/ls:

#!/bin/sh
exec /bin/ls -1 $@

The problem with this is that now we've circumvented $PATH by saying
'exec /bin/ls', an absolute path, rather than simply 'ls'. But if we
did say 'exec ls' then it would infinite loop, with ~/bin/ls executing
~/bin/ls... Our solution was 'next', a shell script which works out
the executable in $PATH to execute *after* the current one. So instead
you would say:

#!/bin/sh
exec next $0 -1 $@

This has proven quite convenient. The script is as follows:

#!/bin/sh

dir=${1%/*}
bin=${1##*/}
shift

unset flag
set -f
IFS=:

for d in $PATH; do
if [ $d = $dir ]; then
flag=1
elif [ -n $flag ]  [ -x $d/$bin ]; then
exec $d/$bin $@
fi
done

printf %s: no '%s' found beyond '%s' in \$PATH\n ${0##*/}
$bin $dir 2
exit 127

Thanks,
cls

[dev] Odds and ends (2/2): $XEMBED

[Connor Lane Smith]

Hi again,

In Plan 9, when one executes a graphical program from a terminal
window it will take over that window, so that running a graphical text
editor like Sam from a terminal is not so different from running a
line editor. This was one of my favourite things from the Plan 9 GUI.

Plan 9 Port doesn't do this, perhaps because it isn't possible in
general to identify an X window to make an X embed request to unless
you have its XID -- PIDs, for example, are unreliable (e.g. remote
programs). So, like all other X programs, running a graphical program
in Plan 9 Port will open it as a separate window, leaving the terminal
idle until the graphical program has closed.

My suggestion is that we use an environment variable, say $XEMBED, to
store the XID to which a spawned graphical process should make an
embedding request. The program would check the environment, and
whether it is a foreground process in its terminal (getpgrp() ==
tcgetpgrp(STDOUT_FILENO)). If $XEMBED is set and it is a foreground
process then it would make an X embed request.

This means that a terminal like 9term can have the same behaviour as
on Plan 9, without having to hardcode programs' embedding options, and
running a program in background is not disturbed. Programs that do not
support $XEMBED but do support X embedding would have to be wrapped
(e.g. with next.sh). But I reckon this behaviour is something worth
having.

Thanks,
cls

Re: [dev] [ls] reform ls

[Connor Lane Smith]

Hi,

On 19 April 2015 at 09:16, Quentin Rameau quinq...@gmail.com wrote:
 I noticed that ls didn't really behaved as stated by POSIX so I worked
 a little on that. Here are four patches, the second one introduce big
 changes, so I'll be glad if you could review it.

1. Rather than turning off, and refusing to turn on again, flags -Srt
in presence of -f, we could just check for -f when about to sort and
avoid that whole code path.

To be honest, it's a bit weird how -St are separate booleans, given
the fact that you could really better define the behaviour of those
flags with an enum { AlphaSort, SizeSort = 'S', TimeSort = 't' },
rather than having to always ensure that Sflag and tflag are not both
true at once. That's a general complaint, though, rather than directed
at your patches.

3. Flags -go are part of XSI, and are unnecessary in POSIX proper. In
my mind sbase shouldn't bother with XSI compatibility. But the
position of the current sbase devs on POSIX compatibility isn't
entirely clear.

On 19 April 2015 at 09:33, Lee Fallat ircsurfe...@gmail.com wrote:
 Just a question - have we (or you) considered creating programs that
 add POSIX support to other programs, rather than implementing it right
 into the program?  For example, to support cat -v, instead of adding
 code for the flag, we create another program to pipe through. Then you
 create a tiny shell script to create a POSIX-compliant program.

Well, cat -v isn't POSIX. POSIX cat has just one flag, -u, which can
actually be totally ignored if your implementation doesn't buffer.
Still, I don't think that's as easy as you might think.

For example, we might want to implement ls flags -Cmx as a separate
shell script, seeing as they only really modify the output format.
(Plan 9 did exactly this with lc and mc.) However, those flags cause
flags -ln to be ignored (since they are mutually exclusive with each
other and with flag -1), which means you do actually have to
communicate to the C program that it is not in fact in -1 mode but in
some other output mode. And once you're doing that I think you might
as well just go ahead and support the flag, to be honest.

Perhaps for *some* utilities it could work, but I don't think it's a
very general solution.

cls

Re: [dev] [ls] reform ls

[Connor Lane Smith]

On 19 April 2015 at 12:41, FRIGN d...@frign.de wrote:
  enum { AlphaSort, SizeSort = 'S', TimeSort = 't' },

 Rather use an int sorttype = 'a'; and change it while parsing the flags.

So exactly what I said except using an int instead of an enum? That's
fine too, although the compiler won't then be aware of the set of
known values during a switch statement.

On 19 April 2015 at 13:16, Quentin Rameau quinq...@gmail.com wrote:
 As for how r-flag is presently implemented it remains necessary to check,
 but it would be indeed better to put r-flag into entcmp.

To be honest, the behaviour (and name) of -f implies that it should
print out filenames as it goes rather than waiting until it has
reached the end of the directory before printing the lot, thus both
being faster and using less memory. That's why -r is to be ignored,
and -lgnos may be ignored: because they are all problematic for that
behaviour (e.g. because they require that the directory be preceded by
a total block count). Still, POSIX doesn't seem to particularly care
for it anyway. It just seems like a useless option if you don't take
advantage of the obvious optimisation.

cls

Re: [dev] [ls] reform ls

[Connor Lane Smith]

On 19 April 2015 at 15:47, Connor Lane Smith c...@lubutu.com wrote:
 That's why -r is to be ignored,
 and -lgnos may be ignored: because they are all problematic for that
 behaviour (e.g. because they require that the directory be preceded by
 a total block count).

To be clear, in my opinion -f should ignore -r and suppress the total
block count for -lgnos, and take a 'fast track' function where it just
prints directory entries as it encounters them, rather than reading
them all into memory and waiting until the end before (not) sorting
them and printing them all out at once. Otherwise why have the flag at all?

cls

Re: [dev] [st] [PATCH 4/3] tresize: remove unnecessary if

[Connor Lane Smith]

On 14 April 2015 at 13:50, Dimitris Papastamos s...@2f30.org wrote:
 dst and src are required to be valid objects even if n is 0, otherwise
 this is undefined behaviour.

I looked this up in C11. Seems to be the case:

 7.24.2.1.2. The memcpy function copies n characters from the object
 pointed to by s2 into the object pointed to by s1.

 6.2.6.1.2. Except for bit-fields, objects are composed of contiguous
 sequences of one or more bytes, ...

 124) ... there are no pointers to or arrays of bit-field objects.

An object pointed to by s1 or s2 is guaranteed to be at least 1 byte
long, so memcpy is free to dereference the first byte of either,
whether or not n  0.

I think it's a mistake that a libc actually go ahead and do this, but
the C standard suggests that it is permitted, so we should certainly
do the check.

cls

Re: [dev] A suckless issue tracker

[Connor Lane Smith]

On 6 April 2015 at 21:58, Mattias Andrée maand...@member.fsf.org wrote:
 The best solution to the problem that I know if is bugseverywhere, but
 [...] last time I used it, it was very buggy.

Well at least the name serves as a warning. :)

cls

Re: [dev] A suckless issue tracker

[Connor Lane Smith]

Hi,

On 6 April 2015 at 21:29, Mattias Andrée maand...@member.fsf.org wrote:
 I have just started on a simple issue tracker
 [Write a decent bug and issue tracking system],
 that I would like to make part of suckless.org
 and develop under your mentorship.

I'm afraid I can't help all that much, but despite FRIGN's protests,
this idea did get a fair amount of attention when it was brought up on
the mailing list a while back. The archived thread [1][2] may be of
interest to you.

[1]: http://lists.suckless.org/dev/1201/index.html#msg10574
[2]: http://lists.suckless.org/dev/1201/10574.html

Thanks,
cls

Re: [dev] sed breaks utf8 in [ ]

[Connor Lane Smith]

On 30/03/2015, FRIGN d...@frign.de wrote:
 In the end, the idea of locales is founded in some deeply-resting issue
 with self-guilt, assuming there's some African tribe which sorts ö after
 x.

They're called Swedes.

cls

Re: [dev] sed breaks utf8 in [ ]

[Connor Lane Smith]

On 30 March 2015 at 22:28, Roger rogerx@gmail.com wrote:
 No need for funky apostrophe usage within the English language.

We do however need to use English currency. £ ain't ASCII.

cls

Re: [dev] sed breaks utf8 in [ ]

[Connor Lane Smith]

On 31 March 2015 at 00:13, Roger rogerx@gmail.com wrote:
 But anyways, think I made my point.

You did: you only care for whatever encoding you personally need over
there in America. Most of us, however, are from Europe, do need UTF-8,
and reckon you can piss off.

cls

Re: [dev] [PATCH quark] Fix chroot argument

[Connor Lane Smith]

On 19 March 2015 at 22:25, Alexander Huemer alexander.hue...@xx.vu wrote:
 -   if (chroot(.) == -1) {
 +   if (chroot(chrootdir) == -1) {

This looks wrong; see line 709:

 if (chdir(chrootdir) == -1) {

So on line 713 . should be chrootdir, because it just chdir'd there.

cls

Re: [dev] Potential bug in st fallback font code

[Connor Lane Smith]

Hi,

I had a quick glance at Christoph's patch. An excerpt:

+   /* We got a default font for a not found glyph. */
+   if(!charexists  frc[i].flags == frcflags \
+unicodep == unicodep) {

I invite you to contemplate that last line.

In case Christoph needs help identifying the problem, here's a patch:

diff --git a/st.c b/st.c
index e27daf0..6397851 100644
--- a/st.c
+++ b/st.c
@@ -3398,7 +3398,7 @@ xdraws(char *s, Glyph base, int x, int y, int
charlen, int bytelen) {
break;
/* We got a default font for a not found glyph. */
if(!charexists  frc[i].flags == frcflags \
-unicodep == unicodep) {
+   frc[i].unicodep == unicodep) {
break;
}
}

The bug, which is reproducible thanks to Eric's example data, seems to
be fixed by this change.

I note that, had Eric not taken the time to post details of this bug
to the mailing list, we wouldn't have known about it, and the bug
would have lingered on. But apparently that's preferable. See no evil,
hear no evil!

cls

Re: [dev] [sbase][PATCH] Add col command

[Connor Lane Smith]

On 3 March 2015 at 13:40, Dimitris Papastamos s...@2f30.org wrote:
 This reminds me, we should really find another name for cols(1) now that
 we have col(1).

I suggested mcol(1) on IRC, given that it was originally mc(1), per Plan 9.

cls

Re: [dev] Re: [libutf] Proposal for additional rune utility functions

[Connor Lane Smith]

Hi,

On 11 February 2015 at 20:48, FRIGN d...@frign.de wrote:
 there's no need for a separate GitHub-repo. You are the maintainer and
 have the right to push your stuff to suckless, and at least I personally
 would really like to see the fresh changes here on suckless.org rather
 than some GitHub 0815 repository.

I'll consider treating the suckless repo as origin, assuming my keys
still work after all this time.

 I hacked on the mkrunetype.awk a lot and modified it so that it
 generates is*rune.c's, lowerrune.c and upperrune.c.
 The reasoning behind this is binary size, as discussed earlier. You can
 see the result here[0].
 Whereas the old implementation only supported the is*rune-checks, I
 reworked the parser so that it now automatically generates the case-
 conversion-functions toupperrune() and tolowerrune() from the
 UnicodeData.txt as well.

This looks very nice, and I'd like to merge it up into libutf. I can't
see mkrunetype.awk in the repo, though.

Thanks,
cls

[dev] Re: [libutf] Proposal for additional rune utility functions

[Connor Lane Smith]

Hi,

I've added these proposed functions, and done some other work too, on
my GitHub repo [1], which is where I maintain libutf now that I no
longer contribute particularly regularly. Please feel free to send me
any other patch proposals, either directly or via this mailing list
(preferably with a CC).

[1]: https://github.com/cls/libutf

Thanks,
Connor

[dev] Re: [libutf] Proposal for additional rune utility functions

[Connor Lane Smith]

Hi FRIGN,

It's been a while since I posted to this list. I do still maintain
libutf, though -- glad to hear it's still being of use.

It sounds like it might be a good idea to add these to the library.
However, I have some simplification suggestions, especially to avoid
memory allocation inside libutf. I've attached a file illustrating the
functions as I think they should be (albeit untested). Your
'chartorunearr' could, in this case, be implemented like so:

 Rune *p = emalloc((utflen(s) + 1) * sizeof *p);
 utftorunestr(s, p);

Does this seem alright to you?

I don't have strong opinions on the 'where to put them' question. I
suppose we could split out every function into its own file, as others
have suggested. On the other hand, if 'utftorunestr' were to go in a
larger file of functions then I would actually suggest a runestr.c,
which doesn't exist yet but may as well; see runestrcat(3).

Thanks,
cls
/* See LICENSE file for copyright and license details. */
#include stdio.h
#include utf.h

int
utftorunestr(const char *s, Rune *p)
{
	int i, n;

	for(i = 0; (n = chartorune(p[i], s)), p[i] != 0; i++)
		s += n;
	return i;
}

int
fgetrune(Rune *p, FILE *fp)
{
	char buf[UTFmax];
	int c, i = 0;

	do {
		if((c = fgetc(fp)) == EOF)
			break;
		buf[i++] = c;
	} while(!fullrune(buf, i));

	if(i == 0)
		return EOF;

	return charntorune(p, buf, i);
}

int
fputrune(const Rune *p, FILE *fp)
{
	char buf[UTFmax];

	return fwrite(buf, runetochar(buf, p), 1, fp);
}

Re: Regarding make-systems [Was: Re: [dev] Build system: redo]

[Connor Lane Smith]

I'm going to ignore the dogma subthread, because, Christ.

On 10 August 2012 11:35, Connor Lane Smith c...@lubutu.com wrote:
 These are quite easy to fix; we'd have to play around with the syntax
 and come up with our own. But I would definitely like a tool that
 solves (C) and only (C). (D) follows trivially.

So I've been thinking a little about this problem, and I came to some
conclusions. In reverse order...

(D) We would have a process which reads the depfile and waits for
input. We would have another process which decides which files have
changed, and pipes them to the first process. Reading these files, the
first process would print the appropriate commands; this goes into
sh(1), which does what it does best.

(C) Do we actually need a dependency graph? The way I see it, all we
need is a single level: if this changes, do this. That's it. No rule
targets; if a file is changed during the build the second process
will pick that up and pipe them too.

(B) The DSL should probably amount to
[[files...][\n\tcommands...]\n...]. First is default.

(A) This suggests that we need a macro system. cpp(1) would bring us
#define, #ifdefs, and #include for free. This is good, because it
means we don't need to invent our own whole scripting subsystem.

So all we'd need is for something to parse the extremely simple file
format and act as a lookup table given [[files...]\n...], and
something to watch for changes (first by timestamp and then, e.g.,
with inotify) and print them. Shouldn't be more than a couple hundred
lines of C with a little shell glue. Should be pretty nippy, too.

cls

Re: Regarding make-systems [Was: Re: [dev] Build system: redo]

[Connor Lane Smith]

Hey,

On 10 August 2012 10:48, Ciprian Dorin Craciun
ciprian.crac...@gmail.com wrote:
 As such -- if I get the suckless definition correctly (but see
 the P.S.) -- such a tool is far from the original intent because it
 does all sorts of things instead of doing exactly one correctly...

We were actually talking about this on IRC just yesterday, also in the
context of ninja:

16:47  cls i've not looked at it much yet, but
http://martine.github.com/ninja/
16:48  cls supposedly very fast build system by stripping out
unnecessary make(1) features

(I suspect we both found it the same way.)

17:12  cls maybe you could separate it out, so the part that handles
the dep graph is actually a totally different utility
17:14  cls so when you just run one build it spins of a process to
read the depfile, and then says right, these things are [new], what do
i need to do?
17:16  cls ls -R | stest -n Depfile | deps Depfile | sh

 Just for the record I didn't yet find a tool that solves exactly
 one of those concerns, but I did find `ninja` (
 http://martine.github.com/ninja ) to come closer to my vision, by
 solving only (C) and (D), leaving (A) and (B) for frontends...
 (Although I would have loved to only solve (C) which is the hardest
 part, and leave the rest to other specific tools...)

Ninja itself looks a little messy, too.

17:00  nsz it uses $ for line break..
17:00  nsz it's not clear how you can add extra dependencies to a build

17:05  nsz i don't like how there are local variables in rule with
special meanings
17:05  nsz command = ..
17:05  nsz description = ..

These are quite easy to fix; we'd have to play around with the syntax
and come up with our own. But I would definitely like a tool that
solves (C) and only (C). (D) follows trivially.

 P.S.: Everytime I hear suckless (or pythonic, or
 the-java-way, or the-unix-way, or the-favorite tool /
 language-way), it makes me thing of a dogmatic priest chanting his
 ritual... And most of the time I have the feeling that people use such
 a phrase when they can't provide a coherent argument, either for or
 against something, but they feel in their guts that they are right and
 thus they must be heard...

The same could be said of words like elegant or beautiful. There
is a certain quality to a program that we can perceive but not quite
explain in words. We can hope to design some eloquent, concise code
that solves the problem with a cunning assembly of pared-down data
structures that seem obvious only in retrospect... Aesthetics are all
about feelings in one's gut. From here on out it's stack allocation,
Indian peafowl, and the Panthéon clock.

Thanks,
cls

Re: [dev] dmenu_run: Split cache logic to dmenu_path again

[Connor Lane Smith]

Hey,

On 31 July 2012 11:31, Quentin Glidic sardemff7+suckl...@sardemff7.net wrote:
 This patch allows to run dmenu_path to update the cache using
 a packager manager hook system

Thanks, pushed to tip.

cls

Re: [dev] [PATCH] sbase: add cut

[Connor Lane Smith]

On 3 August 2012 19:02, Uriel ur...@berlinblue.org wrote:
 head(1) is utterly and completely idiotic. sed 11q is superior in
 every possible way.

% head -n -10

% sed -e :a -e '$d;N;2,10ba' -e 'P;D'

No thanks.

cls

Re: [dev] [PATCH] sbase: add cut

[Connor Lane Smith]

On 3 August 2012 22:15, Nick suckless-...@njw.me.uk wrote:
 Cool, I didn't know that syntax. Useful. Out of curiousity, is it
 codified in any standard?

Sadly not. But then, most things aren't.

cls

Re: [dev] [PATCH] sbase: add cut

[Connor Lane Smith]

On 4 August 2012 01:01, Strake strake...@gmail.com wrote:
 Not sbase head.

Maybe someone should file a bug. :p

By the way, POSIX tail accepts both positive and negative '-n'
arguments, so it would make sense if head did too. One might expect
'-c' as well. Unfortunately standards seldom make much sense.

cls

Re: [dev] [PATCH] sbase: add cut

[Connor Lane Smith]

On 4 August 2012 01:37, Uriel ur...@berlinblue.org wrote:
 Yea, because obviously what we needed is even more unportable GNU extensions.

I don't know about you, but I'd rather use an effective unportable
tool than an ineffective portable one.

cls

Re: [dev] Build system: redo

[Connor Lane Smith]

On 15 July 2012 18:54, Andreas Wagner andreasbwag...@gmail.com wrote:
 Mk is just a cleaned up version of make. In contrast, the implementations of
 redo itself and build files written for it are much simpler. Redo also
 improves on correctness.

 Check this out: http://cr.yp.to/redo.html

 I like redo, but I do think it should have been implemented in C from the
 start.

I agree. Redo is much nicer than make or mk conceptually, but I don't
think Python tools are very nice -- ^C and you've suddenly got stack
trace all over you. I'd be very interested in a C implementation,
actually.

cls

Re: [dev] [ii] exposed password on process monitoring

[Connor Lane Smith]

On 16 June 2012 16:27, markus schnalke mei...@marmaro.de wrote:
 AFAIR the environment can be displayed, too. I think it was `ps e'.
 Hence the fix is no fix.

On 21 April 2012 01:25, Kurt H Maier khm-suckl...@intma.in wrote:
 I am mildly convinced that other users cannot see env data with ps -e.
 I am also vaguely determined that on linux this information comes from
 /proc/$PID/environ and is thus controlled by that file's mode.

On 21 April 2012 01:48, Ivan Kanakarakis ivan.ka...@gmail.com wrote:
 a test user here (Linux) can see the
 processes but _not_ the environment

On 21 April 2012 03:11, Nico Golde n...@ngolde.de wrote:
 [nion@nybble:~$] ls -l /proc/$$/environ
 -r 1 nion nion 0 Apr 21 04:11 /proc/7661/environ

More déjà vu.

cls

Re: [dev] swerc v. werc

[Connor Lane Smith]

Hey,

On 14 May 2012 00:10, David Krauser davidkrau...@devio.us wrote:
 What's the difference between swerc and werc?

According to Anselm, it is just simpler right now, but I intend to
make it serve pages completely statically.

cls

Re: [dev] changing sizes in the master area

[Connor Lane Smith]

Hey,

On 14 May 2012 12:29, Uli Armbruster uli.armbrus...@googlemail.com wrote:
 If you mean changing the size vertically (e.g. with two widows in the master 
 area), then no

You can, by adding or removing windows from master as appropriate. :p

cls

Re: [dev] suckless document generator for C code

[Connor Lane Smith]

Hey,

On 11 May 2012 17:45, Amit Uttamchandani amit.uttamchand...@my.csun.edu wrote:
 I'm looking for a document generator for C code. Mainly to document APIs
 to give to UI developers.

I'm of the belief that documentation generators vary between useless
and harmful. When you embed documentation into the program source
itself, you're choosing either to have very concise documentation, or
to have totally unwieldy comments. In the case of generators like
Javadoc you even include HTML in the comments, which means no one can
actually read them. Most people fall back on stupid text editing
features like code folding, so they don't have to see all this
commented nonsense, and then nobody updates the documentation anyway,
which means the entire thing is useless.

In my opinion you have two sane options: either you can keep the
documentation and source apart, and rely on yourself to keep the two
in sync; or you can stick the information for each function in the C
header file, which then acts as plaintext documentation without all
the hassle of generating HTML.

The best way to solve any problem is to remove its cause.

Connor

Re: [dev] suckless document generator for C code

[Connor Lane Smith]

On 11 May 2012 19:29, Galos, David galos...@students.rowan.edu wrote:
 Less clean than troff files for the docs, I think. And retrieval is
 definitely uglier than man headername

For the record, I do agree. My suggestion involving C header files was
meant as a kind of compromise between the two.

cls

Re: [dev] [tabbed] explicitly requesting input focus

[Connor Lane Smith]

Hey,

On 30 April 2012 14:41, Ivan Kanakarakis ivan.ka...@gmail.com wrote:
 it seems tabbed is requesting input focus, see line 395 on tabbed.c [0]

There was a private thread about this because the guy who reported it
didn't want to subscribe to the mailing list or something. To
summarise,

On 16 November 2011 21:06, Thomas Adam tho...@xteddy.org wrote:
 The latest change in hg for tabbed has reintroduced calls to
 XSetInputFocus() -- as per my change in tabbed (138:5eff0bc41822),
 XSetInputFocus() should not be used; there is no need for tabbed to
 take focus for itself, and doing so by-passes the window manager.

On 16 November 2011 21:16, Connor Lane Smith c...@lubutu.com wrote:
 Can you reply to the thread on the mailing list [1]? Apparently
 removing XSetInputFocus introduced a bug.

 [1]: http://lists.suckless.org/dev/1109/9350.html

On 17 November 2011 15:32, Thomas Adam tho...@fvwm.org wrote:
 I can't, since I'm not subscribed to the list.

On 5 December 2011 21:19, Roman Z. rom...@lavabit.com wrote:
 Before my XSetInputFocus patch was applied, you had to place the mouse
 pointer inside the tabbed window, otherwise all keys that you press are
 ignored by the program that's embedded in tabbed.

 I tested and confirmed this with the window managers dwm and awesomewm
 and with the embedded programs vimprobable2 and urxvt.

On 10 December 2011 21:18, Thomas Adam tho...@fvwm.org wrote:
 Then the solution to that problem is to listen for EnterNotify events
 instead and set focus to c-win as appropriate.

On 11 December 2011 13:47, Roman Z. rom...@lavabit.com wrote:
 The aim is to be able to type in keys even when the mouse is not inside
 the window.  I don't see how EnterNotify events, which occur when the
 mouse enters the window, have anything to do with it.

That was the end of the discussion. I have to say, if it's a choice
between using XSetInputFocus or only receiving input when the mouse is
over the XEmbed window, I'm going with XSetInputFocus.

Thanks,
cls

Re: [dev] slock fullscreen

[Connor Lane Smith]

Hey,

On 23 April 2012 22:28, Mauricio Kanada mkan...@yahoo.com wrote:
 When slock runs, the screens gets black for 1 sec, and backs normal again.
 When I minimize my vm, I see that 'slock' was terminated.

slock cannot grab the keyboard if it has already been grabbed by
another client. VirtualBox grabs the keyboard; we can't do anything
about this. The solution is to simply defocus your VM when running
slock.

Thanks,
cls

Re: [dev] Nmaster Patch

[Connor Lane Smith]

Hey,

On 20 April 2012 19:26, Eric Tse xxsash...@gmail.com wrote:
 Trying to get nmaster patch to work on dwm-hg (dwm 6.0)

nmaster is in mainline since dwm 6.0; you don't need to patch.

cls

Re: [dev] [ii] exposed password on process monitoring

[Connor Lane Smith]

Hey,

On 19 April 2012 17:34, Truls Becken truls.bec...@gmail.com wrote:
 $ ii 
 $ cat ~/irc/freenode_login_script  ~/irc/irc.freenode.net/in

 No need for the program to implement password support at all really.

'ii -k' sends the server a PASS message, which must be done before
NICK or USER. This is unrelated to nickserv etc.

On 19 April 2012 17:24, Ivan Kanakarakis ivan.ka...@gmail.com wrote:
 I was thinking in having -k with no argument to go search for a file
 like oftc.passwd and grab the password from there.

How about making 'ii -k -' read the password from stdin? Flags with
optional arguments are bad, imo.

cls

Re: [dev] [ii] exposed password on process monitoring

[Connor Lane Smith]

On 19 April 2012 19:12, Strake strake...@gmail.com wrote:
 Worse yet are flags whose semantics vary by argument.
 k flag takes literal password, not file name.
 If we want such a feature we ought to add a new flag, as in attached patch.

I understand your position, but I think we should have just one PASS
flag, not two. My preferred option would be to have a single flag, -k,
which takes no argument, and require that passwords be read from
stdin.

On a somewhat related note, it seems strange that both ii and sic have
default hosts which are actually different. In my opinion the -h flag
should be made mandatory, with no default host.

Thanks,
cls

Re: [dev] [ii] exposed password on process monitoring

[Connor Lane Smith]

On 19 April 2012 23:51, Connor Lane Smith c...@lubutu.com wrote:
 In my opinion the -h flag
 should be made mandatory, with no default host.

Sorry, it's -h in sic, -s in ii (which is confusing, too.)

On 20 April 2012 00:19, Nico Golde n...@ngolde.de wrote:
 I don't really like putting that in a file.

Well, in bash you could just 'ii -k  pass'.

 I'm more in favor of something simpler as the following currently:

 If if you don't want to leak your password use the environment variable and 
 not -k then...

Why didn't I think of that? I'd rather something like $IIPASS (which
better describes its function), but other than that I totally support
this approach.

Thanks,
cls

Re: [dev] [dwm] tag changes when applications are activated

[Connor Lane Smith]

On 18 April 2012 08:57, Arian Kuschki arian.kusc...@googlemail.com wrote:
 for some time now, not sure how long, dwm changes the displayed tag when an
 application is activated.

The blame here is either with dwm or the application, depending on the
way you look at it. Essentially, dwm supports the _NET_ACTIVE_WINDOW
EWMH client message, and your application sends it. I'm not sure dwm
should support this, as it doesn't really make sense given dwm's
tagging paradigm.

You can disable it by commenting out lines 543 to 549 in dwm.c, the
else if(cme-message_type == netatom[NetActiveWindow]) block.

Thanks,
cls

Re: [dev] sbase - seq.c: help wanted

[Connor Lane Smith]

Hey,

On 16 April 2012 22:34, Galos, David galos...@students.rowan.edu wrote:
 After some testing I realized that my regex was inaccurate--I forgot to
 encase it in '^$'. If everyone here's cool with REG_EXTENDED, I changed it to
 ^([^%]|%%)*%[ +-]?[0-9]*.?[0-9]*[fFgGeE]([^%]|%%)*$
 Which seemed clearer, and survived more testing.

I'm confused about why we need to use a regular expression here. We
can do this with a few loops and some ifs. Using regexes in seq(1)
really, really concerns me.

cls

Re: [dev] st utf8 printing

[Connor Lane Smith]

On 14 April 2012 16:12, Bjartur Thorlacius svartma...@gmail.com wrote:
 The curses version is a TUI; it uses characters rather than arbitrary
 icons or drawing graphics.

So do other vim GUIs. It's a text editor. Looking at my vim I just see
a lot of text. Text which I edit.

But that aside, the distinction between TUIs and GUIs is completely
artificial. The only difference is that a TUI *cannot* display
images, even when it might be useful. A well-designed text editor GUI
will be pretty much entirely text too.

cls

[dev] Lightweight UTF-8 library

[Connor Lane Smith]

Hey all,

I've written a UTF-8 library based on Plan 9's libutf API, with a
bunch of improvements [1].

I've tested it on various correct and incorrect inputs and it seems to
be 100% Unicode compliant (unlike Plan 9), but if anyone finds any
bugs please tell me.

Might this be useful to have on hg.suckless.org?

[1]: http://lubutu.com/code/utf8-library

Thanks,
cls

Re: [dev] Lightweight UTF-8 library

[Connor Lane Smith]

On 14 April 2012 19:24, Nick suckless-...@njw.me.uk wrote:
 Also, a bit of documentation would be nice, just a sentence saying
 what each function does, plus an example of its use. I know it isn't
 complicated to work out from the function names, but it's still nice
 to have around.

The functions have descriptive comments in the source. You could also
look at the Plan 9 man pages, as Robert says. The relevant page,
rune(2) [1] is now linked on the library webpage. I suppose I could
write my own manpage too.

 Oh, and maybe a make install rule.

I'm unsure about the namespacing issues etc with respect to this. I
suspect utf.h and utf.o / libutf.a are potentially quite clash-prone.

[1]: http://man.cat-v.org/plan_9/2/rune

cls

Re: [dev] situ — change files in situ

[Connor Lane Smith]

Hey,

On 13 April 2012 14:14, Troels Henriksen at...@sigkill.dk wrote:
 Note that you can also exploit shell evaluation order

Of course, that doesn't wait to see whether cmd succeeds.

I wonder whether a situ-like could be used to produce a diff of the
original file, rather than a complete second copy. Programs like sed
don't generally make that many changes, so if we were to connect situ
to the file and the cmd's stdout we could compute the diff and then
patch the original file once cmd exits 0. If someone could get that
working it would be pretty sweet.

Thanks,
cls

Re: [dev] st utf8 printing

[Connor Lane Smith]

On 13 April 2012 15:07, Stephen Paul Weber singpol...@singpolyma.net wrote:
 People use vim from a GUI?

vim *is* a GUI. It's not a line editor, is it? libcurses is a GUI
toolkit too, it just happens to abstract over the hack that is ANSI
escapes.

cls

Re: [dev] situ — change files in situ

[Connor Lane Smith]

On 13 April 2012 16:04, Strake strake...@gmail.com wrote:
 I'm not sure why — this method seems ultimately functionally equivalent to 
 mine.
 Perhaps I fail to ken your logic here.

Your method, while simpler, requires 2n space to 'situ' a length n
file. A suitable patch format would require only enough space to store
the changes to the original file. The outcome would be identical, but
if we're trying to sed only a few changes in a large file it would be
more efficient in terms of storage.

cls

Re: [dev] situ — change files in situ

[Connor Lane Smith]

On 13 April 2012 16:37, Strake strake...@gmail.com wrote:
 True, if we trim the start and finish lazily

That depends on the diff format. diff -e, for example, could work well.

 but worst-case diff
 algorithm space usage is worse — quadratic, if I'm not mistaken.

That's true. Although, diff is worst-case quadratic in the number of
lines, not bytes. And the fact is the worst-case can be avoided: we
don't really *need* the longest common subsequence, only an
approximation to it. If we exceed some threshold we can simply
'plump'.

To be clear, I don't mean to dismiss either existing situ, this would
just be nice to have as well.

cls

[dev] [9base] troff: unterminated macro error

[Connor Lane Smith]

Hey,

9base troff has a bug when compiling on OS X (yeah, I know). sprintf
is a macro, which means the (weird) macros OUT and ERROR in tdef.h
fail with unterminated argument list invoking macro 'sprintf'. The
attached patch fixes this.

Thanks,
cls


9base-troff.diff
Description: Binary data

Re: [dev] xid of a current window

[Connor Lane Smith]

On 25 March 2012 12:42, Anselm R Garbe garb...@gmail.com wrote:
 http://tronche.com/gui/x/xlib/input/XGetInputFocus.html

Note that a Window is an integer, specifically the window's XID.

cls

Re: [dev] Links on tutorial page

[Connor Lane Smith]

Hey,

On 25 February 2012 23:29, Jason Ryan jasonwr...@gmail.com wrote:
 Is there any reason the links to the xinitrc example point to something called
 webconverger?

Link rot. That used to point, as you might expect, to a .xinitrc.

Thanks,
cls

Re: [dev] dwm 6.0 xinerama video

[Connor Lane Smith]

Hey,

On 22 February 2012 08:30, Uli Armbruster uli.armbrus...@googlemail.com wrote:
 You named the video ... NEW Xinerama support. Just curious, what was it 
 like before? I've only been using dwm with two monitors since version 6.0 
 came out.

I think it's a jokey reference to the dwm page [1], which says

 NEW dwm creates a view for each Xinerama screen.

Despite having Xinerama support since version 5.0, released in 2008. :p

[1]: http://dwm.suckless.org

cls