Re: [dev] ASCII Delimited Text
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
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
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
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
On 2 February 2017 at 20:08, Connor Lane Smith 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
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
On 13 August 2016 at 12:31, Connor Lane Smith 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
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
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
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
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
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]
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
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
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
On 1 June 2016 at 18:43, Kamil Cholewiński wrote: > The 95% use case here is handling UTF8-encoded Unicode text. Secure by > default should be the norm, not a magic flag, not buried in a readme. Obviously nobody is arguing for magic flags or burying things in a readme. > If you need to encode an arbitrarily large integer into a stream of > bytes, then use a library specifically designed for encoding arbitrarily > large integers into streams of bytes. Or anything about arbitrarily large integers. > Yes, we're making up problems. I think you missed the point. The problem is not about what needs to be done, but about who needs to do what. You're saying that libutf, a UTF-8 library, should do Unicode validation. I am saying that Unicode validation is up to a Unicode library, and that a UTF-8 library should do nothing but parse UTF-8. If a UTF-8 stream is invalid, there are two possible sources for the fault. One is that it may contain 0xFE or 0xFF, or be overlong, in which case it is the UTF-8 that is at fault. Another is that it may be an invalid Unicode character, in which case it is not the UTF-8 that is at fault, but rather the Unicode -- and whether that is true is dependent on the current Unicode standard. So what we're talking about is what a UTF-8 library should do: should it validate Unicode, or just UTF-8? The distinction is that if we have a particular interface for Unicode concerns, like surrogates or graphemes, then only that interface needs to track the latest Unicode standard, as Ben explained, whilst the interfaces for handling UTF-8 or UTF-32 alone can be fixed, unchanging. This encourages a separation of concerns, which makes bugs less likely (as Unicode is a moving target), and also reduces bit rot (a UTF-8 library will not stop being valid if Unicode changes). As I said, the fundamental question is what libutf should actually do. Is it a UTF-8 library, or a Unicode library? It may be both, but then there is a strong argument that it should also support everything else Unicode requires, which is an awful lot. My recent inclination has been towards supporting only the raw encoding, and then a higher-level interface would handle the Unicode validation as well as everything else specific to this version of Unicode. That way we could tackle UTF-8 without having to bother with all of the other craziness. It would be a fixed, static library, without having to track the standard. Now, if someone wants to deal with Unicode then they could use a Unicode library, not just a UTF-8 library, as all that does is encode and decode. For all that stuff that is specific to a Unicode standard, and which is true no matter which encoding we use -- UTF-8, UTF-32, UTF-1, UTF-7, etc. -- that can all be put in a separate library. Thus, Unicode validation is in one place, not distributed amongst several interfaces which may be updated at different rates, use outdated Unicode, and all that sort of thing. Hence, a separation of concerns. So the question is whether libutf is meant to deal only with UTF-8 (which is constant), or other Unicode features too (which are dynamic). The arguments on either side are essentially: stability, or convenience? As I say, I've not yet made up my mind, but I don't think the problem is made up. Maybe we'll end up deciding to place libutf somewhere between the two, rejecting surrogates and values over 0x10 but stopping short of supporting the character classes of this specific Unicode version (which has changed several times already since I first wrote libutf). At the very least, I think the discussion is worth having. cls
Re: [dev] Different versions of suckless libutf
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
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
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
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
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 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, "[%
Re: [dev] structural regular expression support for vis
On 28 March 2016 at 18:47, Connor Lane Smith wrote: > On 28 March 2016 at 18:46, Connor Lane Smith 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
On 28 March 2016 at 18:46, Connor Lane Smith 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
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
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
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
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
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
On 2 March 2016 at 10:40, Maxime Coste wrote: > That has been provided by Kakoune for a looong time Not as long as I've wanted it! (My first rant on this mailing list about 'interactive structural regular expressions' was in June 2011.) But this may be what I've been looking for, thanks. cls
Re: [dev] another text user interface for sam
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
On 1 March 2016 at 17:44, Marc André Tanner wrote: > Why do you think that? For pretty much the reasons you list. Only support for NUL-terminated strings, no support for passing successive blocks, poor performance for repeated searches of particularly nondeterministic expressions, and so on. We agree for pretty much the same reasoning. (I'm not sure why you assumed otherwise.) > The corresponding section of the vis README[1] also has a few links to > existing engines / algorithms used etc. I'm very familiar with the literature. I think it's also worth looking at the work of Grathwohl et al. (2013, 2014). Anyway, this is why I say such a library would need "quite careful planning." cls
Re: [dev] another text user interface for sam
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
On 1 March 2016 at 17:00, Connor Lane Smith 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
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] quirks with sam's structured regexps
On 1 March 2016 at 12:43, Greg Reagle wrote: > That's interesting. It's funny that sam does a better job since acme is a > successor to sam. I wonder if/how they share code. acme/regx.c certainly was derived from sam/regexp.c. See attached diff. cls --- sam/regexp.c2016-03-01 16:52:35.085509675 + +++ acme/regx.c 2016-03-01 16:52:34.861508409 + @@ -1,47 +1,52 @@ -#include "sam.h" +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "dat.h" +#include "fns.h" Rangeset sel; -String lastregexp; +Rune *lastregexp; + /* * Machine Information */ typedef struct Inst Inst; - struct Inst { - longtype; /* < 0x1 ==> literal, otherwise action */ + uinttype; /* < 0x1 ==> literal, otherwise action */ union { - int rsid; - int rsubid; + int sid; + int subid; int class; - struct Inst *rother; - struct Inst *rright; - } r; + Inst *other; + Inst *right; + }; union{ - struct Inst *lleft; - struct Inst *lnext; - } l; + Inst *left; + Inst *next; + }; }; -#definesid r.rsid -#definesubid r.rsubid -#definerclass r.class -#defineother r.rother -#defineright r.rright -#defineleftl.lleft -#definenextl.lnext #defineNPROG 1024 Inst program[NPROG]; Inst *progp; Inst *startinst; /* First inst. of program; might not be program[0] */ Inst *bstartinst;/* same for backwards machine */ +Channel*rechan;/* chan(Inst*) */ typedef struct Ilist Ilist; struct Ilist { Inst*inst; /* Instruction of the thread */ Rangeset se; - Posnstartp; /* first char of match */ + uintstartp; /* first char of match */ }; #defineNLIST 127 @@ -120,35 +125,40 @@ void bldcclass(void); void -regerror(Err e) +rxinit(void) { - Strzero(&lastregexp); - error(e); + rechan = chancreate(sizeof(Inst*), 0); + lastregexp = runemalloc(1); } void -regerror_c(Err e, int c) +regerror(char *e) { - Strzero(&lastregexp); - error_c(e, c); + lastregexp[0] = 0; + warning(nil, "regexp: %s\n", e); + sendp(rechan, nil); + threadexits(nil); } Inst * newinst(int t) { if(progp >= &program[NPROG]) - regerror(Etoolong); + regerror("expression too long"); progp->type = t; - progp->left = 0; - progp->right = 0; + progp->left = nil; + progp->right = nil; return progp++; } -Inst * -realcompile(Rune *s) +void +realcompile(void *arg) { int token; + Rune *s; + threadsetname("regcomp"); + s = arg; startlex(s); atorp = atorstack; andp = andstack; @@ -169,31 +179,44 @@ operand(END); evaluntil(START); if(nbra) - regerror(Eleftpar); + regerror("unmatched `('"); --andp; /* points to first and only operand */ - return andp->first; + sendp(rechan, andp->first); + threadexits(nil); } -void -compile(String *s) +/* r is null terminated */ +int +rxcompile(Rune *r) { - int i; + int i, nr; Inst *oprogp; - if(Strcmp(s, &lastregexp)==0) - return; + nr = runestrlen(r)+1; + if(runeeq(lastregexp, runestrlen(lastregexp)+1, r, nr)==TRUE) + return TRUE; + lastregexp[0] = 0; for(i=0; is); + bstartinst = nil; + threadcreate(realcompile, r, STACK); + startinst = recvp(rechan); + if(startinst == nil) + return FALSE; optimize(program); oprogp = progp; backwards = TRUE; - bstartinst = realcompile(s->s); + threadcreate(realcompile, r, STACK); + bstartinst = recvp(rechan); + if(bstartinst == nil) + return FALSE; optimize(oprogp); - Strduplstr(&lastregexp, s); + lastregexp = runerealloc(lastregexp, nr); + runemove(lastregexp, r, nr); + return TRUE; } void @@ -206,7 +229,7 @@ if(t == CCLASS){ if(negateclass) i->type = NCCLASS; /* UGH */ - i->rclass = nclass-1; /* UGH */ + i->class = nclass-1;/* UGH */ } pushand(i, i); lastwasand = TRUE; @@ -216,12 +239,8 @@ operator(int t) { if(t==RBRA && --nbra<0) - regerror(Erightpar); + regerror("unmatched `)'"); if(t==LBRA){ -/* - * if(++cursubid >= NSUBEXP) - * regerror(Esubexp); - */ cursubid++; /* si
Re: [dev] another text user interface for sam
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
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
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
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
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
On 20 November 2015 at 18:40, Connor Lane Smith 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] Re: [sbase] cal doesn't highlight current day
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] a suckless hex editor
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()
Hi, On 8 July 2015 at 11:32, Christian Hesse 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?
On 1 June 2015 at 15:33, Martti Kühne 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
On 7 May 2015 at 20:12, Teodoro Santoni 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
On 6 May 2015 at 15:28, Jason Woofenden 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] Odds and ends (2/2): $XEMBED
On 6 May 2015 at 11:59, Connor Lane Smith 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
On 6 May 2015 at 11:43, Connor Lane Smith 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
On 4 May 2015 at 11:56, Roberto E. Vargas Caballero 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 #include #include #include 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] [ST] [PATCH] Changed type for UTF-32 codepoints from long to uint_least32_t
Hi, On 5 May 2015 at 19:31, suigin 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.
On 4 May 2015 at 11:30, Roberto E. Vargas Caballero 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
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
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.
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 (2/2): $XEMBED
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
[dev] Odds and ends (1/2): next.sh
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
Re: [dev] [ls] reform ls
On 19 April 2015 at 15:47, Connor Lane Smith 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] [ls] reform ls
On 19 April 2015 at 12:41, FRIGN 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 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
Hi, On 19 April 2015 at 09:16, Quentin Rameau 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 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] [st] [PATCH 4/3] tresize: remove unnecessary if
On 14 April 2015 at 13:50, Dimitris Papastamos 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
Hi, On 6 April 2015 at 21:29, Mattias Andrée 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] A suckless issue tracker
On 6 April 2015 at 21:58, Mattias Andrée 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] sed breaks utf8 in [ ]
On 31 March 2015 at 00:13, Roger 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] sed breaks utf8 in [ ]
On 30 March 2015 at 22:28, Roger 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 [ ]
On 30/03/2015, FRIGN 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] [PATCH quark] Fix chroot argument
On 19 March 2015 at 22:25, Alexander Huemer 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
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
On 3 March 2015 at 13:40, Dimitris Papastamos 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
Hi, On 11 February 2015 at 20:48, FRIGN 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
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
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 #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]
I'm going to ignore the "dogma" subthread, because, Christ. On 10 August 2012 11:35, Connor Lane Smith 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]
Hey, On 10 August 2012 10:48, Ciprian Dorin Craciun 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-< 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
Hey, On 31 July 2012 11:31, Quentin Glidic 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
On 4 August 2012 01:37, Uriel 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] [PATCH] sbase: add cut
On 4 August 2012 01:01, Strake 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
On 3 August 2012 22:15, Nick 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
On 3 August 2012 19:02, Uriel 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] Build system: redo
On 15 July 2012 18:54, Andreas Wagner 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
On 16 June 2012 16:27, markus schnalke 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 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 wrote: > a test user here (Linux) can see the > processes but _not_ the environment On 21 April 2012 03:11, Nico Golde 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] [surf] patch to remove resizing if small
On 11 June 2012 13:48, Nick wrote: > The most annoying feature of surf for me has been that when the > window gets quite small suddenly everything is zoomed to a tiny and > unreadable size. Oh wow, until now I'd assumed this was some Webkit misfeature. Add me to the patch tally. On 11 June 2012 14:07, pancake wrote: > surf.c: In function ‘gotheaders’: > surf.c:337:11: warning: variable ‘uri’ set but not used > [-Wunused-but-set-variable] This variable doesn't seem to have ever been used, since its inclusion in r182. > surf.c: At top level: > surf.c:800:1: warning: ‘eval’ defined but not used [-Wunused-function] eval is a function for use in config.h; it might be nice to have an example in config.def.h, which would also silence this warning. cls
Re: [dev] [surf]keybind to scroll left/right
Hey, On 24 May 2012 15:12, Hannes Blut wrote: > This is not required for a 1024x768 resolution and most people have > higher resolutions than this. This doesn't need to be mainline. Are you serious? I know we prefer minimalism, but it really would make sense to have this in mainline. Being able to scroll horizontally isn't exactly bloat. (Also, tiling can easily reduce the window dimensions to below 1024x768.) cls
Re: [dev] [dwm] dynamic environment variables
On 19 May 2012 17:36, Connor Lane Smith wrote: > It wouldn't be a perfect solution, but you could just alter your dwm > cmd functions to call a script which set the environment correctly and > then execs the given command. Or, of course, if there are only a small number of applications for which you want this to be done (i.e., your browser), you could wrap those applications in such a script, rather than something more generic. cls
Re: [dev] [dwm] dynamic environment variables
Hey, On 19 May 2012 17:26, Swiatoslaw Gal wrote: > I am wondering if it is possible to implement some (synamic) management of > environment variables, so, for example I could change HTTP_PROXY when I hook > my > laptop in a new place, and all the processes started from now on would respect > it. It wouldn't be a perfect solution, but you could just alter your dwm cmd functions to call a script which set the environment correctly and then execs the given command. Of course, this wouldn't work for processes run from terminals unless you also ran them through this script. But Unix doesn't have Plan 9's env(3), so solutions are limited. cls
Re: [dev] I messed up...used glib, dbus, and friends. Need help to fix this mistake
Hey, On 16 May 2012 17:23, Amit Uttamchandani wrote: > GIO/gvfs had interfaces to do mounts asynchronously and call a callback > function when it was done. Separate concerns: mount with mount, parallelise with pthreads (or similar). Having to build asynchronicity into each function suggests you're doing something very wrong, in one way or another. > > popen(3), or just fork/dup2/exec. > Is there a way to do these asynchronously? You can't get more asynchronous than a separate running process, can you? > I used a lot of the join and cat functions from the glib library. Not > currently using any regexes. string.h has a number of join and cat functions. Even if it doesn't have exactly what you need, it's trivial to write your own. Trivial enough that the dependency is simply not worth it. cls
Re: [dev] swerc v. werc
Hey, On 14 May 2012 00:10, David Krauser 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
Hey, On 14 May 2012 12:29, Uli Armbruster 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
On 11 May 2012 19:29, Galos, David 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] suckless document generator for C code
Hey, On 11 May 2012 17:45, Amit Uttamchandani 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] [tabbed] explicitly requesting input focus
Hey, On 30 April 2012 14:41, Ivan Kanakarakis 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 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 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 wrote: > I can't, since I'm not subscribed to the list. On 5 December 2011 21:19, Roman Z. 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 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. 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
On 23 April 2012 23:26, Mauricio Kanada wrote: > Maybe 'minimize windows' may be one 'slock' option. Clearly that is unnecessary as it can be solved by using another tool, just as you have. Adding hundreds of options to each program isn't the Unix way. By the way, HTML emails are frowned upon on this mailing list. cls
Re: [dev] slock && fullscreen
Hey, On 23 April 2012 22:28, Mauricio Kanada 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
Hey, On 20 April 2012 19:26, Eric Tse 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
On 19 April 2012 23:51, Connor Lane Smith 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 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] [ii] exposed password on process monitoring
On 19 April 2012 19:12, Strake 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
Hey, On 19 April 2012 17:34, Truls Becken 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 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] [dwm] tag changes when applications are activated
On 18 April 2012 08:57, Arian Kuschki 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] A tiny IRC connection tool
On 16 April 2012 21:45, Benjamin R. Haskell wrote: > How does it compare to the other two suckless minimalist IRC tools? In short, ircio does less. It doesn't have any real parsing of the IRC protocol aside from PING, and it's not designed for use as an IRC client. It's equivalent to netcatting into the server, except you don't have to worry about pings. Aside from that you're basically dealing with raw IRC commands, and that's why there's a large difference in SLOC. Bad for humans, great for bots. cls
Re: [dev] sbase - seq.c: help wanted
Hey, On 16 April 2012 22:34, Galos, David 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