Re: [dev] [ii] how do you use it?
Kamil Cholewiński <harry6...@gmail.com> writes: > In all seriousness, ii is more of a library for use with shell scripts > and custom plumbing than a fully-featured client. It can also be a base > for a client you'd build. For example, try splitting a tmux window > horizontally, putting "out" in the upper half, and "in" in the lower. I can't say how well ii fits the bill for interactive uses, but in my experience, sic[0] is much better for writing IRC bots. In fact, sic is very very good. It takes the pain out of the low-level details of the IRC protocol, but still provides a tremendously simple interface. [0]: http://tools.suckless.org/sic/ -- \ Troels /\ Henriksen
Re: [dev] [farbfeld] version 1 release
FRIGN <d...@frign.de> writes: > | [] | 4*16-Bit BE unsigned integers [RGBA] / pixel, row-aligned | Do you mean row-major, or does row-aligned mean something more subtle? -- \ Troels /\ Henriksen
Re: [dev] [surf] Webapps in Surf
Jeroen Op 't Eynde jer...@simplistic.be writes: Hi all! I've looking for a way to run several webapps in Surf. At my workplace they use a lot of Google Apps and Hipchat. Google Apps haven't worked at all since I'm using Surf and recently also Hipchat and Google Calendar broke. I first thought this may be due to webkitgtk-2.0, so I successfully replaced it with webkitgtk-3.0 but no luck on the webapps front. Unless something has changed since last I checked, Surf does not permit the Javascript engine to access cookies. This breaks a lot of the web. -- \ Troels /\ Henriksen
Re: [dev] [surf] Webapps in Surf
Jeroen Op 't Eynde jer...@simplistic.be writes: On Thu, Mar 5, 2015 at 11:37 PM, Troels Henriksen at...@sigkill.dk wrote: Unless something has changed since last I checked, Surf does not permit the Javascript engine to access cookies. This breaks a lot of the web. Is there a way to allow this? I don't mind digging in the code, but some pointers would be nice. Actually, after digging in the code, it seems like this was fixed in a patch three years ago. Shows how much out of the loop I am. Then I have no idea what is the problem. -- \ Troels /\ Henriksen
[dev] [PATCH] Disable buffering of stdin in sic
If several lines are given to the stdin of sic in a single write() call
(by whatever is controlling sic), only the first line will be seen by
sic until the stdin file descriptor is triggered the next time. This is
due to interactions between C stdio buffering and the use of select().
sic already disables buffering on the socket FD, and with this patch,
also on stdin.diff --git a/sic.c b/sic.c
index 6b5ae96..ce6d216 100644
--- a/sic.c
+++ b/sic.c
@@ -181,6 +181,7 @@ main(int argc, char *argv[]) {
fflush(srv);
setbuf(stdout, NULL);
setbuf(srv, NULL);
+ setbuf(stdin, NULL);
for(;;) { /* main loop */
FD_ZERO(rd);
FD_SET(0, rd);
--
\ Troels
/\ Henriksen
Re: [dev] K, a low-level procedural imperative programming language
M Farkas-Dyck strake...@gmail.com writes: Given the comments on alternatives to C lately on dev@ I thought this a good time to introduce mine: http://k-lang.org/ The only implementation seems to be written in a pretty atrocious style: https://github.com/strake/pkc/blob/master/CodeGen/Common.hs Also - why care about whether or not the grammar is simple to parse if you're using something like Haskell to implement it, which can easily handle very context-dependent grammars? I'm curious about which flaws of C you are trying to fix. Sure, the syntax is simplified, and maybe the built-in numeric types are a little saner, but the benefit of such seems low compare to the cost of using such an obscure language. If you really want to substantially improve on C, I think adding a more elaborate type system, with which you can encode more invariants without run-time cost, is a more interesting approach, which can be seen in e.g. Rust. This will cost you greatly in increased implementation complexity, which I think is not to the taste of many on this list. Most of the complexity in a minimal C compiler will be in the parser, for example. -- \ Troels /\ Henriksen
Re: [dev] Simple question
Guillaume Quintin coincoin1...@gmail.com writes: Hi, I was wondering if there was some program out there that uses algorithms such as red-black trees, B-trees, binomial heaps, fibonacci heaps, etc. Do you know any ? This is just for my curiosity. The implementation of std::map in the GNU C++ library is a red-black tree. -- \ Troels /\ Henriksen
Re: [dev][project] soap - a simple xdg-open replacement
Eon S. Jeon esj...@hyunmu.am writes: Luckily, I came up with an alternative way of passing the argument. This one uses an environment variable to store the argument, and lets the shell expand the string for us. I've already implemented it, so you can check it out. https://github.com/esjeon/soap/commit/cec3f19ee151ab647dc8c5a544cb5e4277992531 This is a wonderful solution. It's even less code! -- \ Troels /\ Henriksen
Re: [dev] [surf] link hinting
Swiatoslaw Gal swiatoslaw@univie.ac.at writes: Did anyone implemented links hinting without java script? Why would you want that? It would be hundreds of lines of tremendously ugly C-code for navigating the DOM, creating CSS, installing key handlers... -- \ Troels /\ Henriksen
Re: [dev] [surf] link hinting
Swiatoslaw Gal swiatoslaw@univie.ac.at writes: Did anyone implemented links hinting without java script? Why would you want that? It would be hundreds of lines of tremendously ugly C-code for navigating the DOM, creating CSS, installing key handlers... The reason I switched javascript on default is… quite embarrassing. I use compiled form git surf with debian unstable libraries, and with javascript I experience strange crushes. For example if I follow a link from wikipædia page. I have no idea what is broken. It is certainly not surf. The same happens with Midori. I can understand that. A better solution would be to refine the Javascript-toggle, such that user-scripts (like link hinting) will be enabled, while all website Javasript will be disabled. -- \ Troels /\ Henriksen
Re: [dev] What is bad with Python
FRIGN d...@frign.de writes: Yes, that's a point. Go implements GC and other stuff in the binary, which blows its size up a lot. However, if we take the Hello-World-program as the lowest common denominator, we could calculate, that if we ported all basic tools in sbase (currently 70) to the Go language, the compiled binaries would need around 100MB-200MB _after_ stripping unnecessary stuff from it (as explained earlier). A solution to this is to implement the GC (and other runtime parts) as a dynamic library. This code would also be shared in memory by all running Go processes. (I do not use Go myself, but in the Haskell world we have a similar issue - my current project compiles to a statically linked 53MiB binary, although this is admittedly with profiling support included.) -- \ Troels /\ Henriksen
Re: [dev] wswsh: a mksh web framework
sin s...@2f30.org writes: On Thu, Dec 12, 2013 at 05:11:06PM +0100, YpN wrote: C is generally more and efficient, I suppose. On 12/12/2013 16:04, sin wrote: On Thu, Dec 12, 2013 at 03:42:52PM +, Neo Romantique wrote: Why Shell, and not C? Otherwise tool looks interesting. I don't see why this has to be done in C. Actually, I don't know C but I plan to learn it in 2014. I might consider porting it to C, for my first practise. I wrote it in mksh because this is a wonderful shell and it's really powerful. And it's how I learn new shell hacks (creating my stuff) :) 2014 is the year of C :) No, that was year 100. 2014 is the year of MMXIV. -- \ Troels /\ Henriksen
Re: [dev] alternatives to find for querying the filesystem
Andrew Gwozdziewycz w...@apgwoz.com writes: Assume that each filter halves the fileset of, say, 256 files (my /etc directory on this OSX machine has just 247 files). That's less than 512 calls with a few filters. Is that really so bad on modern hardware? If you have only 256 files, you can do almost anything and it'll still be fast. Think tens of thousands, at the very least. I like the general idea of this, but I'd advise you not to go overboard with the tool splitting. You can easily have a single filegrep tool that includes all queries about size, age and the like, paired with another tree-walking fool. -- \ Troels /\ Henriksen
Re: [dev] alternatives to find for querying the filesystem
Troels Henriksen at...@sigkill.dk writes: Andrew Gwozdziewycz w...@apgwoz.com writes: Assume that each filter halves the fileset of, say, 256 files (my /etc directory on this OSX machine has just 247 files). That's less than 512 calls with a few filters. Is that really so bad on modern hardware? If you have only 256 files, you can do almost anything and it'll still be fast. Think tens of thousands, at the very least. I like the general idea of this, but I'd advise you not to go overboard with the tool splitting. You can easily have a single filegrep tool that includes all queries about size, age and the like, paired with another tree-walking fool. Actually, on second thought, there's no way to make this fast. You *must* be able to perform filtering during tree traversal, or you may end up traversing huge subdirectories unnecessarily. -- \ Troels /\ Henriksen
Re: [dev] Bringing together OS'es terminals and their codepages
patrick295767 patrick295767 patrick295...@gmail.com writes: Would you know a technique to have a way that your application looks the same on whatever system (Linux, Mac, OS/2, Windows,..)? Use UTF-8. Seriously, different character sets are such an incredibly sucky thing that nobody should consider re-introducing them, unless necessary to interact with legacy systems. (Of course, one should consider Windows to be legacy...) Unicode also has all the weird line-drawing characters you could ever want, if you find them important. On which systems are the Latin-set of code pages still necessary? -- \ Troels /\ Henriksen
Re: [dev] Bringing together OS'es terminals and their codepages
patrick295767 patrick295767 patrick295...@gmail.com writes: I am not so sure if you can get all the unicode well displayed on most terminals. If you make a nice art / ascii graphic, you are never sure whether it will end well displayed depending on the system/terminal, that the user uses. No, but it's more likely than any other encoding (apart from plain ASCII), and it will only improve, given that almost every platform has adopted at least Unicode (and often UTF-8 specifically) as the preferred way to deal with text. I'm not saying UTF-8 is perfect, just that it's the best choice. But yeah, stay away from the weirdest characters. For example, '', which I often find useful when discussing software, is missing in many fonts. -- \ Troels /\ Henriksen
Re: [dev] Bringing together OS'es terminals and their codepages
patrick295767 patrick295767 patrick295...@gmail.com writes: Let's take an example: Let's take a well-known program: vim compiled for Windows. If you use gvim.exe in Windows, you have a perfect result. No simple problem with characters. However, if you take vim.exe (from the same directory as gvim.exe) and use it in the windows console (execute: cmd then type vim), you end up with strange chars if you are using special accents, and so on. (with a well configured terminal). I just would like to point that problems, even on well known programs, may still today be present (and quite annoying for some users). Vim has more than 20 years existence, but still, some problems may still exist with characters, although Unicode/utf-8,.. are there to make it easier. (It is a bug). That's because the standard Windows terminal is terrible. I would advise never using it. Pretty much every other terminal in works properly, because they don't try to simulate some ancient DOS abomination. -- \ Troels /\ Henriksen
Re: [dev] Bringing together OS'es terminals and their codepages
patrick295767 patrick295767 patrick295...@gmail.com writes: You are completely right. Windows is important. Another point... what about colors? You never know what the user using your program will get. Linux terminal, Windows Terminal, xterm,... e.g: http://invisible-island.net/xterm/images/contrast.jpg You really shouldn't write terminal programs that require precise colours. -- \ Troels /\ Henriksen
Re: [dev] [st] wide characters
Random832 random...@fastmail.us writes: On 04/13/2013 07:07 PM, Aurélien Aptel wrote: The ISO/IEC 10646:2003 Unicode standard 4.0 says that: The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers. utf-8 is rather straightforward to handle and process. Okay, but why not work with a unicode code point as an int? That would not be UTF-8, but UCS-4. I don't think Xlib can handle that natively. -- \ Troels /\ Henriksen
Re: [dev] [dwmstatus] Mail counter
Raphael Proust raphla...@gmail.com writes: On Fri, Dec 21, 2012 at 5:45 PM, Christoph Lohmann 2...@r-36.net wrote: Please, use English while programming. There is no justification for lo‐ calized sourcecode. I am trying to come up with one, but it's hard. Obfuscation maybe? I can think of two cases, but both are quite specific: * Education, particularly oriented towards young children who do not yet know English. It is, of course, an interesting debate whether it is more important to learn programming or English first. * Code in a domain-specific-language to be used by non-programmers. If the domain is very technical, with a large number of unique terms (for example, law), translating said terms to English may render the language less comprehensible and harder to use. In the general case, and the specific case of Suckless, English should be used. -- \ Troels /\ Henriksen
Re: [dev] [surf] adblocking
Kurt H Maier khm-suckl...@intma.in writes: On Tue, Nov 20, 2012 at 03:30:38PM +, Nick wrote: The way I do it with a local proxy means that said requests are stripped out of the HTML before reaching the browser. DNS based things will presumably fail immediately with /etc/hosts, rather than time out. But you're still wasting the bandwidth. It's insane. The bandwidth to the local proxy? How exactly is anything being wasted? -- \ Troels /\ Henriksen
[dev] Surf 0.5 released
Surf 0.5 is now available from http://surf.suckless.org. Since the last release, surf has gained a number of exciting features, for example: * No longer crashes when closing a window during loading. * Properly capitalised window class. * Something about SSL. For the next release, the surf hackers will work dilligently on supporting emerging web technologies such as cookies and file downloads. -- \ Troels /\ Henriksen
Re: [dev] [surf] eval() not needed?
sta...@cs.tu-berlin.de writes:
{ CTRL, GDK_c, eval, STRING(removeHints())
eval expects arg-v to be char**, so your STRING resolves to sth like
{ .v = (const char *[]){simplyread(false, false) } }
right?
Yes:
#define STRING(f) { .v = (char*[]){ f } }
--
\ Troels
/\ Henriksen
Re: [dev] [surf] eval() not needed?
sta...@cs.tu-berlin.de writes: Seems like eval() is not needed for some time now. The trivial patch against tip to remove it is attached. eval() was never needed per se. I put it in because you need it if you want robust keybindings to functions defined in script.js, and you need to spend a good while reading dubious documentation to figure out how to write it yourself. Maybe we could express some of the default surf commands using it, though. -- \ Troels /\ Henriksen
Re: [dev] [surf] eval() not needed?
sta...@cs.tu-berlin.de writes:
* Troels Henriksen at...@sigkill.dk [2012-07-06 09:31]:
eval() was never needed per se. I put it in because you need it if you
want robust keybindings to functions defined in script.js, and you need
Ok. Didn't know. And still don't really get it... Can you give a hint?
search of 'eval' within surf.suckless.org yields the Link hints page.
The js code invokes eval. Is this the same eval?
some time ago someone shared some js code to extract the important
textual part of a page based on counting number of paragraphs, called
simplyread. I use this quite often but to activate it I neeed to go into
insert mode to let surf not eat the keys, then press the key which the
script bound itself to (FWIW F3).
I found myself binding some xdotool magic to a regular surf keybinding
as in
xdotool key -window $0 i key -window $0 F3 key -window $0 Esc
which is sommewhat ugly. Is eval somehow related to that?
I'm not sure what you mean by insert mode. I use eval() for
Conkeror-style numbered link navigation. The actual logic is defined in
Javascript in my script.js, and I have the following bindings in my
config.h:
{ CTRL, GDK_f, eval, STRING(hintMode()) },
{ CTRL|SHIFT, GDK_f, eval, STRING(hintMode(true)) },
{ CTRL, GDK_c, eval, STRING(removeHints())
},
Creating the keybindings themselves in Javascript is brittle and bad.
--
\ Troels
/\ Henriksen
Re: [dev] [surf] port for gtk3
Swiatoslaw Gal swiatoslaw@univie.ac.at writes: Is anyone planning to port surf for gtk3? Once I have a system that uses GTK3, I'd have to do it. -- \ Troels /\ Henriksen
Re: [dev] [surf] port for gtk3
pancake panc...@youterm.com writes: On 06/19/12 12:45, Troels Henriksen wrote: Swiatoslaw Gal swiatoslaw@univie.ac.at writes: Is anyone planning to port surf for gtk3? Once I have a system that uses GTK3, I'd have to do it. are you from the past? Pretty close: I use Slackware. -- \ Troels /\ Henriksen
Re: [dev] [surf]keybind to scroll left/right
sta...@cs.tu-berlin.de writes: * Thuban thu...@singularity.fr [2012-05-24 07:53]: I was wondering if there is any way to have a keybind to scroll left or right, just like you can scroll up and down with C-k and C-j? sure. Here an example: This is a pretty useful patch that does not add any complexity. I've pushed it to mainline. -- \ Troels /\ Henriksen
Re: [dev] situ — change files in situ
Strake strake...@gmail.com writes: Hello all. I wrote a program to mutate files in situ by a given shell program, available here: http://strake.zanity.net:1104/situ/ I thought that it might be useful for some other folks here, ergo this mail. I wrote it to gain the functionality of GNU sed's -i switch in 9base sed. Unlike GNU sed's -i switch, it ought to work with any program. I wrote a similar program in C: http://sigkill.dk/projects/insitu/ It also does actual in-replace replacement (which is sometimes not what you want). Note that you can also exploit shell evaluation order: (rm foo cmd... foo) foo This will do an (almost) in-place replacement of foo. -- \ Troels /\ Henriksen
Re: [dev] [surf] manpage patch
evan.ga...@gmail.com (Evan Gates) writes: I've attached a small patch to the manpage that documents the use of SURF_USERAGENT and http_proxy environment variables. Committed, thanks, and sorry for the delay. -- \ Troels /\ Henriksen
Re: [dev] regarding surf and cookie handling
Peter Hartman peterjohnhart...@gmail.com writes: This is stil is favorable than the current approach as far as I can tell. Why? Because in Surf as it is now, cookies are not readable from Javascript, and an increasing number of sites rely on this being possible. The naive approach used in sb is not by itself useful (as already mentioned by Calvin Morrison), and I just haven't been motivated enough to do the heavier glib programming necessary to do a proper integration. As I remember my analysis, you can't use cookie-changed signal, though, as it is not sent when the file changes, but rather when the cookie object changes (and I think the file is automatically rewritten when that happens anyway). Rather, I think we will need to create an object from scratch that implements the cookie jar interface, but which uses the current mechanism of completely re-reading the file whenever a cookie is requested or given. (Nothing should prevent us from using inotify to be a bit smarter, though.) -- \ Troels /\ Henriksen
Re: [dev][surf] -c command-line option to turn off cookies
Tomas Hlavaty t...@logand.com writes: Hi all, a slightly better patch attached. looks like the attachement hasn't made it to the list so I'll try to repost it again it the message body. Would it be possible to get it into the main repository? This will still send cookies, will it not? Is that desirable? -- \ Troels /\ Henriksen
Re: [dev] regarding surf and cookie handling
Calvin Morrison mutanttur...@gmail.com writes: But, since we write out to the cookie jar frequently, wouldn't it be inefficient to be constantly re reading (and reparsing) the entire cookie file? Yes, but we're already doing that, so apparently it's not a big problem in practice. -- \ Troels /\ Henriksen
Re: [dev] regarding surf and cookie handling
Calvin Morrison mutanttur...@gmail.com writes: On 22 February 2012 08:36, Troels Henriksen at...@sigkill.dk wrote: Calvin Morrison mutanttur...@gmail.com writes: But, since we write out to the cookie jar frequently, wouldn't it be inefficient to be constantly re reading (and reparsing) the entire cookie file? Yes, but we're already doing that, so apparently it's not a big problem in practice. I was clear that we were constantly writing to the cookie jar. I was not clear that we were manually rereading it each time, now i see that the getcookies function is doing it. That seems rather inefficient also because on every request signal emitted we are reloading the cookie jar. That means it's not only every time we reload a page, but whenever the page requests new info (eg facebook while scrolling through the feed) What is a better solution, or is that the best solution? A better solution would be to cache the cookie file contents and only re-read if something has changed. The best solution, with respect to efficiency, would be to have some central cookie daemon that can send the changed cookies to the running Surf instances. Uzbl uses this last approach, but I think it's far too complicated. -- \ Troels /\ Henriksen
Re: [dev] regarding surf and cookie handling
Calvin Morrison mutanttur...@gmail.com writes: On 22 February 2012 09:17, Troels Henriksen at...@sigkill.dk wrote: Calvin Morrison mutanttur...@gmail.com writes: On 22 February 2012 08:36, Troels Henriksen at...@sigkill.dk wrote: Calvin Morrison mutanttur...@gmail.com writes: But, since we write out to the cookie jar frequently, wouldn't it be inefficient to be constantly re reading (and reparsing) the entire cookie file? Yes, but we're already doing that, so apparently it's not a big problem in practice. I was clear that we were constantly writing to the cookie jar. I was not clear that we were manually rereading it each time, now i see that the getcookies function is doing it. That seems rather inefficient also because on every request signal emitted we are reloading the cookie jar. That means it's not only every time we reload a page, but whenever the page requests new info (eg facebook while scrolling through the feed) What is a better solution, or is that the best solution? A better solution would be to cache the cookie file contents and only re-read if something has changed. The best solution, with respect to efficiency, would be to have some central cookie daemon that can send the changed cookies to the running Surf instances. Uzbl uses this last approach, but I think it's far too complicated. What about inotify? I am now thinking that would be the best. Instead of loading the file on every request, we could just check for inotify events. We can create an event for the cookie file using IN_MODIFY event. if there has been an event, then we reread. Yes, inotify would be the mechanism by which file changes are discovered, although it's not portable. I'm not certain what the Suckless Zeitgeist is on using Linux-only facilities. -- \ Troels /\ Henriksen
Re: [dev] [surf] [patch] Close stdout after printing XID
Abby Cedar abbyce...@yahoo.com.au writes: Need to close stdout otherwise it can't be used in a script until surf finishes. To test, try the below before and after the patch. Thanks, I pushed your fix. For religious reasons, I changed it to us fclose() rather than freopen(). -- \ Troels /\ Henriksen
Re: [dev] [surf] [patch] Close stdout after printing XID
Abby Cedar abbyce...@yahoo.com.au writes: Need to close stdout otherwise it can't be used in a script until surf finishes. Am I missing something? Why not just use flose(stdout)? -- \ Troels /\ Henriksen
Re: [dev] FOSDEM
Dieter Plaetinck die...@plaetinck.be writes: On Mon, 30 Jan 2012 12:31:33 + suckless-...@njw.me.uk wrote: So, FOSDEM is this weekend. Is anyone on the list coming? I'm looking forward to going, and it'd be fun to meet up with like-minded folks. Nick I'm going. Me too. Any talks you can recommend? -- \ Troels /\ Henriksen
[dev] Confusion about ii's handling of JOIN messages
ii performs some strange processing around JOIN messages, which means
that they are not handled correctly (they are put in the server buffer
with 'null' channel name). The following patch fixes that, but I can't
believe the code was in there for no reason, as it seems rather
deliberate. Could someone shed some light on this?
diff -r d163c8917af7 ii.c
--- a/ii.c Mon Oct 31 21:35:12 2011 +0100
+++ b/ii.c Wed Jan 25 13:56:03 2012 +0100
@@ -347,13 +347,7 @@
} else if(!strncmp(ERROR, argv[TOK_CMD], 6))
snprintf(message, PIPE_BUF, -!- error %s, argv[TOK_TEXT] ? argv[TOK_TEXT] : unknown);
else if(!strncmp(JOIN, argv[TOK_CMD], 5)) {
- if(argv[TOK_TEXT] != NULL){
- p = strchr(argv[TOK_TEXT], ' ');
- if(p)
-*p = 0;
- }
- argv[TOK_CHAN] = argv[TOK_TEXT];
- snprintf(message, PIPE_BUF, -!- %s(%s) has joined %s, argv[TOK_NICKSRV], argv[TOK_USER], argv[TOK_TEXT]);
+ snprintf(message, PIPE_BUF, -!- %s(%s) has joined %s, argv[TOK_NICKSRV], argv[TOK_USER], argv[TOK_CHAN]);
} else if(!strncmp(PART, argv[TOK_CMD], 5)) {
snprintf(message, PIPE_BUF, -!- %s(%s) has left %s, argv[TOK_NICKSRV], argv[TOK_USER], argv[TOK_CHAN]);
} else if(!strncmp(MODE, argv[TOK_CMD], 5))
--
\ Troels
/\ Henriksen
Re: [dev] [surf] hover fix
Jeremy Jackins jeremyjack...@gmail.com writes: this Sorry, this one can actually be applied. Thanks, applied. -- \ Troels /\ Henriksen
Re: [dev] [surf] minor fix
Peter John Hartman peterjohnhart...@gmail.com writes: Hi, I removed the eval function, and I added spatial as a variable as with plugins et al. (Frankly, I hate spatial; why is it default?) Question: Shouldn't we move spatial, plugins, etc. into config.def.h? I added this one fix (controlling spatialness) into config.def.h. I can't see why we shouldn't (although one could argue that changing true to false is equally easy in surf.c, if harder to find). -- \ Troels /\ Henriksen
Re: [dev] One Border is Not Enough
Bjartur Thorlacius svartma...@gmail.com writes:
This could be implemented as a gap between windows in tile(). Just
offset windows a few pixels more than {wh,ww} + 2*borderpx. Dwm.c is
probably more readable than the previous sentence.
You'd also need to construct a border pixmap rather than the current
single-colour border. I'm not entirely certain how those are tiled, though.
--
\ Troels
/\ Henriksen
Re: [dev] One Border is Not Enough
Bastien Dejean nihilh...@gmail.com writes: Bjartur Thorlacius: Just draw the second border on the root window. Will it work with floating windows? No. -- \ Troels /\ Henriksen
Re: [dev] [dmenu] spurious newlines
wagne...@seas.upenn.edu writes: Quoting Connor Lane Smith c...@lubutu.com: The change was intentional. The logic being that lines go in and a line comes out... Rather than some fragment of a line. (dmenu strips newlines when reading, and restores them when printing.) Is there a reason why you preferred the earlier behaviour? No reason to prefer one behavior to another here, but I do prefer consistency. =) I maintain yeganesh (see http://dmwit.com/yeganesh for more info), and profiles have started getting cluttered up with a version with a newline and a version without from people upgrading dmenu. However, as long as there's a clear policy on which versions will output an extra newline it's easy to work around by checking the output of dmenu -v first. You could also unconditionally strip trailing newlines, since they will never be part of a selection proper, but always a terminator. -- \ Troels /\ Henriksen
Re: [dev] Re: dmenu's lsx binary naming conflicts with lrzsz!
Christian Neukirchen chneukirc...@gmail.com writes: Connor Lane Smith c...@lubutu.com writes: On 28 November 2011 13:35, Christian Neukirchen chneukirc...@gmail.com wrote: Any reason we don't replace lsx with this? find -L . -maxdepth 1 -type f -perm -111 POSIX compatibility. All supported except for -maxdepth, but you can use: find -L . -type d \! -name . -prune -o -type f -perm -111 -print You'll run into problems with command line length. If rewritten to a shell loop, it'll be too slow. This has all been tried before. -- \ Troels /\ Henriksen
Re: [dev] [dwm] [PATCH] spawn_cwd - spawn from current client's cwd
Suraj N. Kurapati sun...@gmail.com writes: On Thu 24 Nov 2011 05:12:17 PM PST, Stephen Paul Weber wrote: Somebody signing messages as Suraj N. Kurapati wrote: the ability to open new programs in the currently focused client's workdir. https://github.com/sunaku/.dwm/compare/tip...spawn_cwd Does this patch just work on xterm/rxvt windows that happen to have their CWD path in the title? Not just; it works for *any* window that has a file path in its title. Alternative/additional idea: look for the process indicated by the _NET_WM_PID property, then use the working directory of that process. -- \ Troels /\ Henriksen
Re: [dev] [dwm] [PATCH] spawn_cwd - spawn from current client's cwd
Kurt Van Dijck kurt.van.di...@eia.be writes: On Fri, Nov 25, 2011 at 09:54:44AM +0100, Troels Henriksen wrote: Suraj N. Kurapati sun...@gmail.com writes: On Thu 24 Nov 2011 05:12:17 PM PST, Stephen Paul Weber wrote: Somebody signing messages as Suraj N. Kurapati wrote: the ability to open new programs in the currently focused client's workdir. https://github.com/sunaku/.dwm/compare/tip...spawn_cwd Does this patch just work on xterm/rxvt windows that happen to have their CWD path in the title? Not just; it works for *any* window that has a file path in its title. Alternative/additional idea: look for the process indicated by the _NET_WM_PID property, then use the working directory of that process. I don't understand the feature. I appears to assume that all clients run on the same host? Yes, which is not guaranteed, but often the case. -- \ Troels /\ Henriksen
Re: [dev] [surf] downloads
sta...@cs.tu-berlin.de writes: Hm, writing this, I figured out the arxiv folks are afraid of mass deonloads and DoS and just look into the user agent. So adding --user-agent foo solved the problem. Good observation. Downloading should of course use the Surf user agent. (I may have run across this problem before.) -- \ Troels /\ Henriksen
Re: [dev] [surf] downloads
Étienne Faure tinou...@gmail.com writes: Hello, I've had a small issue downloading scripts from www.vim.org: The URI ends with a php file and a variable argument. With the current wget setup, the script name isn't deduced from the header. Thus, the downloaded file's name is something like: download_script.php?src_id=1234 I managed to solve this problem using curl and its --remote-header-name. I didn't find a way to do this with wget. There is a fix for this that involves using the webkit_download_get_suggested_filename function and passing it to wget's -O option, but I can't figure out how to prevent clobbering of an already existing file by that name. Perhaps we should use curl instead. -- \ Troels /\ Henriksen
Re: [dev] [surf] downloads
sta...@cs.tu-berlin.de writes: * Troels Henriksen at...@sigkill.dk [2011-11-05 12:51]: There is a fix for this that involves using the webkit_download_get_suggested_filename function and passing it to wget's -O option, but I can't figure out how to prevent clobbering of an that might work? fn=$result_of_webkit_download_get_suggested_filename; while test -e $fn; do fn=$fn.1; done; wget -O $fn ... Yep, but it's ugly. I may put it in unless someone can devise something prettier. -- \ Troels /\ Henriksen
Re: [dev] [surf] downloads
Étienne Faure tinou...@gmail.com writes: Try this: wget 'http://www.vim.org/scripts/script.php?script_id=3792adding=dummyarguments=thatcould=bea=horriblehash=thati=veseen=oncrappy=sitesunfortunatly=ican=notfind=apublicly=availableexample=ofthis=solet=sgo=fora=hashhere=514241337a3c43a0bb28eb88de0adde1and=anotherone=K3NYV1NvZm9IeU5IRFRjbkFIdjdlV0F5cW5HbVFzeWJpcFd0UHZyenhEZklDSUNrb1VwdnN3PT0K' This only happens when things like session id or any other type of hash is appended. Though, now that I come to it, curl -JO fails as well. Only chromium succeeds with this horrible URI. Maybe we could go by a temporary file name as the same chromium does: naming it suggested filename.surfdownload, and then renaming it. Left is to find out how curl gets its correct remote header filename. What an ugly mess. Is there really no usable downloader program that can handle these (not terribly rare) cases in a simple manner? This sounds like a good candidate for a new Suckless project, although I'm partial to simply using the wget-loop for now. -- \ Troels /\ Henriksen
Re: [dev] [dwm] 2000 SLOC
Anselm R Garbe garb...@gmail.com writes: On 31 October 2011 12:42, Troels Henriksen at...@sigkill.dk wrote: Anselm R Garbe garb...@gmail.com writes: * surf (seems dead, please shout if you disagree or if anyone wants to take this on, it doesn't make sense if it is not maintained, as webkitgtk carries away) I wouldn't mind taking maintainership of Surf, if necessary. I'm already maintaining an off-tree fork with some changes (although not all of those changes are suckless, I think I have figured out some good ways to make Surf more useful). Excellent, please send me your SSH key via privmail. What, no solemn vow to uphold the sacred Suckless principles? At least I hope I still get to learn about a secret handshake or something. -- \ Troels /\ Henriksen
Re: [dev] [dwm] 2000 SLOC
Connor Lane Smith c...@lubutu.com writes: On 31 October 2011 12:27, Krnk Ktz krnk...@gmail.com wrote: What should be done about ii? Are there features requests? I mean, it is a great concept and works very well as it is, doesn't it? It works well, but the source could do with a little cleaning up. There are some weird things, like fprintf(stderr, %s, ...), no forward declarations, very few comments, for some reason it doesn't use stdio so has no buffering, etc. I also think that it has some slight bugs with robustness (it should attempt to reconnect if disconnected), but it is otherwise a very good program, and I would be sad to see it go. -- \ Troels /\ Henriksen
Re: [dev] List of tools for a CLI environment
Jimmy Tang jt...@tchpc.tcd.ie writes:
On 25 Oct 2011, at 16:48, Džen wrote:
On 25/10/2011 03:56, Evan Gates wrote:
Really wish I had an undo send feature...
(IFS=:; ls $PATH)
couldn't do better.
just showed this to a friend of mine and he cooked this up
ls ${PATH//:/ }
That will fail if any folder in $PATH contains spaces. Evan's, however,
is not only short, but also correct even under such crazy circumstances.
--
\ Troels
/\ Henriksen
Re: [dev] [dmenu] composite key not working
Swiatoslaw Gal swiatoslaw@univie.ac.at writes: What may I do to enable composite key (defined with setxkbmap as compose:rctrl) with dmenu? It works with st, though. You can't. dmenu does not implement the X11 input context protocol. It could in a few dozen lines of code, though. -- \ Troels /\ Henriksen
Re: [dev] [dmenu] composite key not working
Connor Lane Smith c...@lubutu.com writes:
Hey,
On 16/10/2011, Troels Henriksen at...@sigkill.dk wrote:
You can't. dmenu does not implement the X11 input context protocol. It
could in a few dozen lines of code, though.
I would happily accept a patch for this.
Here's a patch that solves the common cases. There's a ton of potential
issues (complex Unicode in the input) that may require more reworking,
but this patch makes dead keys work for any of the cases on my communist
European keyboard.
diff -r 2f548e0f8965 dmenu.c
--- a/dmenu.c Thu Oct 13 20:43:59 2011 +0100
+++ b/dmenu.c Sun Oct 16 15:23:29 2011 +0200
@@ -58,6 +58,7 @@
static Item *matches, *matchend;
static Item *prev, *curr, *next, *sel;
static Window win;
+static XIC xic;
static int (*fstrncmp)(const char *, const char *, size_t) = strncmp;
static char *(*fstrstr)(const char *, const char *) = strstr;
@@ -230,8 +231,10 @@
keypress(XKeyEvent *ev) {
char buf[32];
KeySym ksym;
+ int len;
+ Status status;
- XLookupString(ev, buf, sizeof buf, ksym, NULL);
+ len = XmbLookupString(xic, ev, buf, sizeof(buf), ksym, status);
if(ev-state ControlMask) {
KeySym lower, upper;
@@ -273,7 +276,7 @@
switch(ksym) {
default:
if(!iscntrl(*buf))
- insert(buf, strlen(buf));
+ insert(buf, len);
break;
case XK_Delete:
if(text[cursor] == '\0')
@@ -461,7 +464,9 @@
run(void) {
XEvent ev;
- while(!XNextEvent(dc-dpy, ev))
+ while(!XNextEvent(dc-dpy, ev)) {
+ if(XFilterEvent(ev, win))
+ continue;
switch(ev.type) {
case Expose:
if(ev.xexpose.count == 0)
@@ -479,6 +484,7 @@
XRaiseWindow(dc-dpy, win);
break;
}
+ }
}
void
@@ -486,6 +492,7 @@
int x, y, screen = DefaultScreen(dc-dpy);
Window root = RootWindow(dc-dpy, screen);
XSetWindowAttributes swa;
+ XIM xim;
#ifdef XINERAMA
int n;
XineramaScreenInfo *info;
@@ -542,6 +549,11 @@
DefaultVisual(dc-dpy, screen),
CWOverrideRedirect | CWBackPixmap | CWEventMask, swa);
+/* input methods */
+ xim = XOpenIM(dc-dpy, NULL, NULL, NULL);
+ xic = XCreateIC(xim, XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
+ XNClientWindow, win, XNFocusWindow, win, NULL);
+
XMapRaised(dc-dpy, win);
resizedc(dc, mw, mh);
drawmenu();
--
\ Troels
/\ Henriksen
Re: [dev] [surf] download patch updated
Nick suckless-...@njw.me.uk writes: Howdy, I recently got around to updating the patch posted to the list in July last year by Carlos, which builds downloading into surf rather than relying on e.g. wget. While this sounds like a bad idea, it isn't, as it's needed for horrible javascript sorts of downloads, such as from rapidshare and megaupload. Huh? I have not had trouble using wget for this. -- \ Troels /\ Henriksen
Re: [dev] [surf] download patch updated
Nick suckless-...@njw.me.uk writes: Quoth Troels Henriksen: Nick suckless-...@njw.me.uk writes: Howdy, I recently got around to updating the patch posted to the list in July last year by Carlos, which builds downloading into surf rather than relying on e.g. wget. While this sounds like a bad idea, it isn't, as it's needed for horrible javascript sorts of downloads, such as from rapidshare and megaupload. Huh? I have not had trouble using wget for this. Really? That suprises me. I suppose it may be the fault of my slightly baroque shell script... Can anyone else confirm / deny this? The only problem I've had is having to add --no-check-certificate to wget. Apart from that, any download, even one initiated by the browser, is authenticated solely through cookies (what would a javascript download be?). In theory, a download might be authenticated via session cookies or form parameters, which would be harder to pass to wget (but not impossible), although I don't recall seeing this in the wild. Actually, now that I think about it, there is another potential problem: wget may attempt to autoguess the filename, and for some URIs, this will result in a name that is too long for the file system to handle. There are two solutions to this: 1) Use webkit_download_get_suggested_filename and pass the string on to wget. This almost always works. 2) Let the user input a file name (via dmenu or whatever) for all downloads. I have done this in my own Surf fork and it works well. -- \ Troels /\ Henriksen
Re: [dev] [surf] download patch updated
Nick suckless-...@njw.me.uk writes: In other surf news, I created a page on the wiki http://surf.suckless.org/failing_sites - if anyone finds something that doesn't work in surf, please detail it there (or on the mailing list). While surf is very far from perfect, it's the most reasonable way of using today's web that I've found, and I'd rather like to keep it working. I agree. I would also like a maintainer more willing to add features, such as dwm-like rules, for customising without having to maintain your own fork. I think it is quite plausible to write a very useful, stable and (rather) suckless browser in a few thousand lines of code, but you really can't do it well in the current 800 or whatever Surf is. -- \ Troels /\ Henriksen
[dev] Re: Suckless sh
Ethan Grammatikidis eeke...@fastmail.fm writes: Anyone know why ghc is that big? I'm having trouble figuring it out. It bundles a large amount of libraries, and probably duplicate versions with profiling data as well. A self-contained GHC build (as created after compiling and prior to installation) is 182MiB on my system, and that includes Cabal (the package manager/make system), program coverage checking tools, debugging tools and a bunch of other things. Binaries generated by GHC are indeed fairly huge, but the number in the quoted email seems inflated. -- \ Troels /\ Henriksen
Re: [dev] Dooble - Was: [surf] segfault
ilf i...@zeromail.org writes: On 08-04 13:32, Cengiz Tas wrote: So what I are using instead for browsing? I mean beside FF or Chromium. Netsurf, Arora, etc. ? Netsurf lacks of Java Script and Arora development stopped for quite a long time. Anyone looked at this? http://dooble.sourceforge.net/ Dooble is a new Open Source Web browser that focuses on compactness, security, and stability. Total SLOC = 14,660 An integrated file manager is an elegant necessity. Dooble includes a colorful desktop. What is this nonsense? -- \ Troels /\ Henriksen
Re: [dev] New hardware migration
Anselm R Garbe garb...@gmail.com writes: Hi there, I just want to mention that I will migrate suckless.org to a new host during the following weeks. I take this chance also to dramatically overhaul and sweeping the wiki contents and the weirde default look and feel. My plan is to revert the basic structure of the wiki back to be more like the werc default with a side menu instead for the actual content, and a top-line menu for the different sub-domains. Most of the URLs will survive, but some crappy content will be deleted. What crappy content? Can someone remind me on the state of wmii? Is it abandoned/stalled? Is a relocation elsewhere planned yet or not? As I understand it, it moved to Google Code some time ago: http://code.google.com/p/wmii/ -- \ Troels /\ Henriksen
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
Andreas Wagner andreasbwag...@gmail.com writes: Most people here seem more concerned with and interested in radical minimalism than modularity. Don't get me wrong, I think suckless software is on many points in the spirit of the unix philosophy. I just think the principles of composition and as a result modularity and separation are being neglected. This is true, but http://suckless.org/manifest/ only mentions Unix philosophy a single time, and not as the centerpiece of the manifest, so I don't think this is a great revelation. It happens that many principles of Unix philosophy lend themselves well to simplicity and frugality, but there are also some (such as file system interfaces and extreme interpretations of the tool philosophy) that create a degree of complexity. Whether or not you believe this complexity to be worthwhile (I do) is a question of taste, but most people of Suckless seem to take the frugal road. -- \ Troels /\ Henriksen
Re: [dev] does anyone else think that suckless.org is more about bare-bones minimalism than unix philosophy
Nick suckless-...@njw.me.uk writes: On Mon, Jun 13, 2011 at 09:38:26AM -0400, Andreas Wagner wrote: I just think the principles of composition and as a result modularity and separation are being neglected. Can you give some examples of where you see this in suckless.org's software? dwm has a built-in status bar rather than using an external program. dmenu doesn't use sselp anymore (maybe a stretch). Surf has a built-in progress bar. There are probably some examples in wmii, but I do not know it well. And all of the above have very good reasons for being the way they are. -- \ Troels /\ Henriksen
Re: [dev] Experimental editor
Paul Onyschuk bl...@bojary.koba.pl writes: It has been discussed before[1]. With Sam regexps, own window manager can be handy. Some quotes: Russ Cox rsc at swtch.com wrote: The die hard sam users would disagree vehemently with you. The nice thing about sam is that it's one window, not many, making it comfortable to edit a 30-file project without getting caught up in managing windows. That just means you need a better window manager. Whatever sam does, why can't a specialised program do that as well? -- \ Troels /\ Henriksen
Re: [dev] ideas on suckless file manager
Noah Birnel nbir...@gmail.com writes: So a suckless file manager would maybe throw away the whole file manager concept and have a sort of dmenu-like multiple file selector? This patch may be useful: http://tools.suckless.org/dmenu/patches/multiselect_and_newline -- \ Troels /\ Henriksen
Re: [dev][st] Approach to adding -bg colour option to st
Aurélien Aptel aurelien.ap...@gmail.com writes: On Sun, Apr 24, 2011 at 8:10 PM, David Tweed david.tw...@gmail.com wrote: to convert DefaultBG and DefaultFG from #define's into full C variables with defaults and add option partsing code to set them according to -fg and -bg. (The simplest thing would be to make the argument be an array index rather than parsing a colour spec.) Before I start working on a patch, does that sound like the appropriate way to do this or is there a different way of handling colour that's being envisaged? A X11 parsable color is better (#rrggbb, light red, etc). This is true, because then XAllocNamedColor will handle everything for you. It is also worth considering whether to handle this via X Resources (the ~/.Xdefaults file) instead of command line options - since a terminal is not normally something you are going to start by invoking directly, but rather through a shortcut in your window manager. -- \ Troels /\ Henriksen
Re: [dev] [surf] arrows
Peter John Hartman peterjohnhart...@gmail.com writes: I'd be happy to hear of someone who has a quick-n-dirty solution to this problem. I patched my surf to check whether input focus was in a text field before processing shortcut keys. The patch is somewhere on the list. -- \ Troels /\ Henriksen
Re: [dev] openbsd is now c++ free
Gregor Best g...@ring0.de writes: On Mon, Mar 14, 2011 at 06:57:26PM +0100, pancake wrote: http://undeadly.org/cgi?action=articlesid=20110314142734 So in other words, with the new OpenBSD, one can not compile roff files that use macro sets other than -man? Sounds kind of sucky, but the removing C++ thing is a noble goal nonetheless. Well, I personally wouldn't want to use roff for anything but manpages, but I know some on this list may disagree. But I imagine OpenBSD will not prevent you from installing additional macro sets. -- \ Troels /\ Henriksen
Re: [dev] [dmenu] Patch for XDG Base Directory specification of dmenu_path
Anselm R Garbe ans...@garbe.us writes: On Sat, Jan 01, 2011 at 06:04:45PM +, Bjartur Thorlacius wrote: I think storing cache files under $HOME is even odder. $HOME is quite often accessed over a network. Storing it under /var seems saner. Or /tmp as it was in the earlier days. /tmp is wiped on system reboot, while you might like your dmenu cache to live a little longer than that. -- \ Troels /\ Henriksen
Re: [dev] [hack] Having dmenu provide hints about current selected entry
Connor Lane Smith c...@lubutu.com writes: Hey, On 26 November 2010 14:04, Dieter Plaetinck die...@plaetinck.be wrote: I would prefer if it works like this: - when you invoke dmenu, it immediately appears, and user can start typing input. as soon as dmenu is started, it starts reading stdin, however fast or slow it goes until EOF. - anytime anything happens (user changes his query or new line is read on stdin) the search results are updated in realtime accordingly. I think the code/algorithms to realize this must be pretty complicated for it to work nicely (high performance).. But your patches seem trivial, so did I miss something? No, to do this would be trivial. It's just that certain suckless people are rather aggressive to the idea of using pthreads for anything. If threads are the problem, you could do this with select() easily enough. I think people object to the complexity, however. (I don't - especially when the alternative is to loose out on a very useful feature that cannot be implemented in a simpler way.) -- \ Troels /\ Henriksen
Re: [dev] surf segfault
Gregor Best g...@ring0.de writes: On Sun, Nov 21, 2010 at 02:46:00PM +0100, Martin Kopta wrote: [...] Why is in surf.c at line /gdk_draw_rectangle(w-window,/ the w-window null pointer? (gdb) p w $5 = (GtkWidget *) 0x7fd4d00225e0 (gdb) p w-window $6 = (GdkWindow *) 0x0 That is good or bad? [...] I'd say that is because the window is already destroyed there but the widget is still alive and being updated (take that with a grain of salt though, I didn't actually read the code). A patch for this issue has been posted several times. I have posted it at least twice, at least. The problem is that the load-status-change event (or rather, the event handler) is not disabled before the window starts being destroyed. -- \ Troels /\ Henriksen
Re: [dev] A language similar to Markdown that sucks less
Alexander Teinum atei...@gmail.com writes: Maybe the idea sucks. You've missed the point of Markdown, which is readable plaintext that looks much like an email of Usenet post would. Your language seems fine, but it's not a useful replacement for Markdown, because it's clearly aimed at something entirely different. -- \ Troels /\ Henriksen
Re: [dev] [patch] add Control-G and Control-D to dmenu
Connor Lane Smith c...@lubutu.com writes: To be honest I'm surprised there's such a reaction to something so trivial as an added keybind. I'm glad this doesn't happen often or we'd never get anything done. Well, you can only paint a bike shed every so often. -- \ Troels /\ Henriksen
Re: [dev] [9buntu] first attempt -bashing needed
Kris Maglione maglion...@gmail.com writes: On Fri, Jul 30, 2010 at 09:09:08AM +0200, Jens Staal wrote: Hi all. While waiting for Sta.li to be finnished, I started playing around with a custom ubuntu build that uses plan9port as default user interface on as many levels possible (inspired by some e-mails from Anselm that were lying around on the web). I am basically a total layman on this and I have sort of leant as I went along when I built this... so there are probably a few completely useless configuration setting changes made. I'm more than a little surprised that you'd start with such an overgrown, hulking Goliath of a system such as Ubuntu. I think it says enough that it has aptitude, apt-get, apt-cache, dpkg, dpkg-*, dselect, debhelper, and devscripts, just to make a start. Then you have such abominations as Sys-V init to contend with, and the maze of tangled configuration schemes. I would have started with a simpler system like Arch or GoboLinux, or even a BSD. Or if I were feeling a bit sadistic, Gentoo, Source Mage, or Slackware. Debian, though... I'm not that sadistic. Why not Linux from Scratch? Or even Glendix... (Slackware is probably the best realistic bet, due to the simplicity.) -- \ Troels /\ Henriksen
Re: [dev] Tabbed + Surf, possible bug on closing tab
Martin Kopta mar...@kopta.eu writes: Hi everybody, I use Tabbed (0.3) with Surf (0.4.1) and there is one issue I would like to discuss. Situation: Tabbed is running with few Surf instances within. I intend to close ONE Surf instance. I use ^q or middle click (emulated using left+right) on tab name. Results: I expect that the selected one window (tab) will be closed. In most cases it is exactly so, but sometimes it happens, that many more tabs disapear. Since there is no way to bring back tabs in Tabbed, this bug is very anonying. This is because the same Surf process is responsible for multiple Windows. The display part of Surf is programmed in a very brittle way, and often dies due to X11 BadWindow errors (which can be fixed by installing an error handler that ignores those) and mysterious segfaults within the Flash plugin and some asynchronous-loading part of Webkit (which I'm not sure how to fix). A basic problem is that Surf windows are destroyed without first unregistering signal handlers, so you easily end up with handlers trying to use a halfway-destroyed window object (this happens very often if you close a window that is still loading, due to the way the progress bar works). -- \ Troels /\ Henriksen
Re: [dev] [wmii] Locale problem with uptime (loadavg in status bar) and a suggestion
Uriel ur...@berlinblue.org writes: On Wed, Jul 14, 2010 at 7:56 PM, nico n...@lifeisabug.com wrote: Hmm, actually I never had problems setting the locale. I always have LANG and LC_MESSAGES set to en_US.UTF-8 so language is still english and the other variables are set to de_DE.UTF-8 so information many apps do rely on like paper size, currency, punctuation (the fail in my case), address format and stuff like that is correct. So I'm just going to use a different uptime parsing method or is anyone having a better idea? Again, stop trying to 'use' the PoSix locale system for anything, it is completely broken and totally antithetical to how Unix is designed to work. An option would be to use p9p's user space instead of the usual GNU crap. What should you do if you don't want all your programs to write brain-dead US units and punctuation? -- \ Troels /\ Henriksen
Re: [dev] Interesting post about X11
Aled Gest himse...@gmail.com writes: Scheme *should* be used for everything because at least one good macro system has been designed for it. Lisp macros can do arbitrary computation at compile-time, and the Scheme macro system required by R6RS provides all the power of Lisp macros *and* supports a pattern-matching macro specification syntax for simple syntactic sugar. That doesn't explain *why* it should be used. Why should Scheme, or any other language with a higher level of abstraction and obfuscation, replace a relatively clean and unencumbered language like C? * Because manual memory management is a mess. * Because some data structures and algorithms (red-black trees, for a classic example) are extremely cumbersome in C compared to other languages. * Because adding on to C to fix its many small warts would be a mess (it can be less bad than C++ and still very bad). Not all modern languages have to be towers of complexity: Scheme and SML are two very simple and elegant languages, and even Haskell 98 can really be kept in your head in its entirety. Go is another example of a simple, yet modern language (built-in tuples!), one that may appeal more the crowd on this mailing list. -- \ Troels /\ Henriksen
Re: [dev] Suckless operating system
Anselm R Garbe garb...@gmail.com writes: Regarding the boot speed I disagree. I think short boot cycles can be achieved with rather more simple init systems than the insanity people got used to like the SysV style Debian insanity. A simple BSD init based or even more simple system always outperforms any smart technique in my observation. Well, for really excellent performance, you do need the ability to parallelise the init operations, so that's a bit of complexity that has actual performance benefits. I agree there is little value in the general runlevel mess. -- \ Troels /\ Henriksen
Re: [dev] [surf] Segfault bug
Gene Auyeung quaker4...@gmail.com writes: Hi, For a while I've been frustrated when I close a surf window, it takes down the process that created it, along with all windows of that process. For clicking a link in gmail will open a new window, and closing that window sometimes closes the parent window as well. Today I had some time to insert printfs into surf.c to find out what's going on. I posted a patch to fix this some time ago. There are three similar issues as far as I know: * When destroying a surf window, you will often end up with a situation in which you are in mid-takedown and have destroyed the progress bar, yet an event that wishes to update the progress bar will arrive. This will usually crash due to a BadWindow error. This can be fixed by disabling signals in the destroyclient function: g_signal_handlers_disconnect_matched(GTK_WIDGET(c-view), G_SIGNAL_MATCH_DATA, 0, 0, 0, 0, c); * Something similar to the above, although harder to fix, in which some internal part of WebKit is not done with its work by the time you g_free() it. I have not been able to figure out a way to fix this. * Fucking modules like Flash and Java not dealing well with being closed, resulting in BadWindow errors similar to the first problem. I advocate simple adding an X11 error handler that ignores BadWindow errors. This seems like a pretty standard way to do it. -- \ Troels /\ Henriksen
Re: [dev] surf 0.4 tries to free an invalid pointer
Pierre Chapuis catw...@archlinux.us writes: I installed surf 0.4 on Arch Linux and it crashed when I tried to click on a link to a binary file (actually to its own archive on suckless' website). Downloading with the right click menu works fine. I have copied its output below. The crash looks linked to Java. Most likely, the Java plugin cannot unload properly. I have registered several similar crashes with the Flash plugin (in fact, there are many serious problems with surf not shutting things down properly, but I'm not sure how they could be fixed). -- \ Troels /\ Henriksen
Re: [dev] dmenu_path rewrite in C
Mate Nagy mn...@port70.net writes: On Wed, May 19, 2010 at 12:09:33PM +0200, Premysl Hruby wrote: Conclusion: 0.7 seconds is somewhat noticeable lag. It's another question whether it's worth the effort to write the C program, but hey, it's been done already. Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) I have cache misses rather often, and the delay *is* annoying. I'd be a happy user of the C rewrite. I'm wondering, would it speed up the program if the script spawned a background process for every entry in $PATH? I imagine quite a lot of the runtime is spent waiting for I/O, so simple threading would be a win. That said, I don't think I've ever tried parallelising a shell script. -- \ Troels /\ Henriksen
Re: [dev] dmenu_path rewrite in C
Renick Bell ren...@gmail.com writes: Well, I (and others possibly) have no concern about cache miss, my files in $PATH doesn't changes every five minutes :-) So, I see no reason to have it mainline. However, dmenu is very slow when dealing with the history file in uzbl. I have frequently wanted a faster replacement. Slow how? How large is this history file? -- \ Troels /\ Henriksen
Re: [dev] dmenu_path rewrite in C
Elmo Todurov todu...@gmail.com writes: * less mallocs, less copying strings around (no noticeable change in I really think this MAX_PATH thing is a bad idea. You can argue that a system with paths that deep is broken, but I think a suckless program should be able to work in sucky environments as well. -- \ Troels /\ Henriksen
[dev] Re: [surf] line of approach
Enno Boland (Gottox) got...@gmail.com writes: 2010/5/17 pancake panc...@youterm.com: Copy URL doesn't works for images I'm open for patches to copy a pictures URI. I think, I will strip down things in surf. I have to reconsider the event system. It's a bit ugly and inconsistent atm. [snip] Way to go is to remove more complexity from surf. downloading is one of the features which never worked well and can easily be moved into a script. Moving more things into external scripts is a good idea in my opinion, but that does seem to imply having an actual extensible event system. The question is whether to make it as fully fledged as Uzbl (which can be a bit complex), or to define a simpler set with less flexibility. Of course, perhaps surf's idea of passing information via X properties makes it possible to grow an event system without making it complex at all. -- \ Troels /\ Henriksen
[dev] Simple session support for surf
in `{orphans}) { surf $url }
rm $sessionfile
case resume-locked
res=`{orphans|$dmenu}
if (! ~ $status '') exit 1
$0 purge-locked $res surf $res
# Don't deadlock on unknown commands...
case *-locked
exit 1
# Wrap a command in file locking and rerun the script.
case *
cmd=$1-locked
shift
flock -o $sessionfile -c $0^' '^$cmd^' '^$*
}
}
if not {
echo 'Cannot write to '$sessionfile [1=2]
exit 1
}
--
\ Troels
/\ Henriksen
[dev] Surf patch to disable link hover when focus is lost
Surf changes the window title to reflect the URL of the link under the
pointer. This is good, as it means you can use xmobar or dzen or some
other program to inspect links, rather than having a dedicated pane.
It is also bad, because if you switch away from surf while hovering over
a link, the surf window will have a poor title, and will be harder to
find if you use window titles for navigation.
The attached patch fixes this by reverting the hover whenever the surf
window loses focus.
diff -r 0f29cb6df0ca -r f94ad8014e32 surf.c
--- a/surf.c Wed May 12 16:39:34 2010 +0200
+++ b/surf.c Wed May 12 16:40:00 2010 +0200
@@ -102,6 +102,7 @@
static void progresschange(WebKitWebView *view, GParamSpec *pspec, Client *c);
static void reload(Client *c, const Arg *arg);
static void resize(GtkWidget *w, GtkAllocation *a, Client *c);
+static void focusout(GtkWidget *w, GtkAllocation *a, Client *c);
static void scroll(Client *c, const Arg *arg);
static void setatom(Client *c, Atom a, const char *v);
static void setcookie(SoupCookie *c);
@@ -529,6 +530,7 @@
gtk_window_set_default_size(GTK_WINDOW(c-win), 800, 600);
g_signal_connect(G_OBJECT(c-win), destroy, G_CALLBACK(destroywin), c);
g_signal_connect(G_OBJECT(c-win), key-press-event, G_CALLBACK(keypress), c);
+ g_signal_connect(G_OBJECT(c-win), focus-out-event, G_CALLBACK(focusout), c);
g_signal_connect(G_OBJECT(c-win), size-allocate, G_CALLBACK(resize), c);
if(!(c-items = calloc(1, sizeof(GtkWidget *) * LENGTH(items
@@ -724,6 +726,13 @@
}
void
+focusout(GtkWidget *w, GtkAllocation *a, Client *c) {
+ free (c-linkhover);
+ c-linkhover = NULL;
+ update(c);
+}
+
+void
scroll(Client *c, const Arg *arg) {
gdouble v;
GtkAdjustment *a;
--
\ Troels
/\ Henriksen
[dev] surf patch: bind keystrokes to snippets of Javascript
The attached patch lets you bind keys to small lines of Javascript to
run.
The intent is that the usual ~/.surf/script.js defines various methods,
which are then run by the bindings. This is much cleaner than having
script.js create its own event listeners for keybindings going outside
surf's own system.
diff -r 8671f9860efe surf.c
--- a/surf.c Tue May 11 10:16:22 2010 +0200
+++ b/surf.c Tue May 11 11:06:55 2010 +0200
@@ -67,6 +67,8 @@
static char *buildpath(const char *path);
static void cleanup(void);
+static void evalscript(WebKitWebFrame *frame, JSContextRef js, char *script, char* scriptname);
+static void evalscriptfile(WebKitWebFrame *frame, JSContextRef js, char *scriptpath);
static void clipboard(Client *c, const Arg *arg);
static void context(WebKitWebView *v, GtkMenu *m, Client *c);
static char *copystr(char **str, const char *src);
@@ -107,6 +109,8 @@
static void sigchld(int unused);
static void source(Client *c, const Arg *arg);
static void spawn(Client *c, const Arg *arg);
+static void runscript(Client *c, const Arg *arg);
+static void eval(Client *c, const Arg *arg);
static void stop(Client *c, const Arg *arg);
static void titlechange(WebKitWebView *v, WebKitWebFrame* frame, const char* title, Client *c);
static void update(Client *c);
@@ -151,15 +155,23 @@
}
void
-runscript(WebKitWebFrame *frame, JSContextRef js) {
- JSStringRef jsscript;
- char *script;
+evalscript(WebKitWebFrame *frame, JSContextRef js, char *script, char* scriptname) {
+ JSStringRef jsscript, jsscriptname;
JSValueRef exception = NULL;
- GError *error;
- if(g_file_get_contents(scriptfile, script, NULL, error)) {
- jsscript = JSStringCreateWithUTF8CString(script);
- JSEvaluateScript(js, jsscript, JSContextGetGlobalObject(js), NULL, 0, exception);
+ jsscript = JSStringCreateWithUTF8CString(script);
+ jsscriptname = JSStringCreateWithUTF8CString(scriptname);
+ JSEvaluateScript(js, jsscript, JSContextGetGlobalObject(js), jsscriptname, 0, exception);
+ JSStringRelease(jsscript);
+ JSStringRelease(jsscriptname);
+}
+
+void
+evalscriptfile(WebKitWebFrame *frame, JSContextRef js, char *scriptpath) {
+ GError *error = NULL;
+ char* script = NULL;
+ if(g_file_get_contents(scriptpath, script, NULL, error)) {
+ evalscript(frame, webkit_web_frame_get_global_context(frame), script, scriptpath);
}
}
@@ -576,7 +588,7 @@
gdk_window_add_filter(GTK_WIDGET(c-win)-window, processx, c);
webkit_web_view_set_full_content_zoom(c-view, TRUE);
frame = webkit_web_view_get_main_frame(c-view);
- runscript(frame, webkit_web_frame_get_global_context(frame));
+ evalscriptfile(frame, webkit_web_frame_get_global_context(frame), scriptfile);
settings = webkit_web_view_get_settings(c-view);
if(!(ua = getenv(SURF_USERAGENT)))
ua = useragent;
@@ -825,6 +837,18 @@
}
void
+runscript(Client *c, const Arg *arg) {
+ WebKitWebFrame *frame = webkit_web_view_get_main_frame(c-view);
+ evalscriptfile(frame, webkit_web_frame_get_global_context(frame), ((char **)arg-v)[0]);
+}
+
+void
+eval(Client *c, const Arg *arg) {
+ WebKitWebFrame *frame = webkit_web_view_get_main_frame(c-view);
+ evalscript(frame, webkit_web_frame_get_global_context(frame), ((char **)arg-v)[0], );
+}
+
+void
stop(Client *c, const Arg *arg) {
if(c-download)
webkit_download_cancel(c-download);
@@ -881,7 +905,7 @@
void
windowobjectcleared(GtkWidget *w, WebKitWebFrame *frame, JSContextRef js, JSObjectRef win, Client *c) {
- runscript(frame, js);
+ evalscriptfile(frame, js, scriptfile);
}
void
--
\ Troels
/\ Henriksen
Re: [dev] dmenu -m new%patch -d %
Martin Ellis ellis...@gmail.com writes: Hi, We had a strange situation where putting the menu in stdin was difficult. What situation is this? -- \ Troels /\ Henriksen
Re: [dev] dmenu -m new%patch -d %
Connor Lane Smith c...@lubutu.com writes: Hey, On 11/05/2010, Martin Ellis ellis...@gmail.com wrote: We had a strange situation where putting the menu in stdin was difficult. For our situation supplying the menu on the command line would be easier. Attached is a patch that provides this. I wrote one similar to this, except each argument after the flags is a menu item, and it's only +3 LOC. I'm not sure why you need a delimiter and such, but maybe this patch works for your situation. The diff is against tip, since we're real close to releasing 4.1 anyway. Thanks, cls Why not just use a simple wrapper script? I'm not very good at bourne shell, but this works: #!/bin/sh cmd=dmenu while [ $# -gt 0 ]; do case $1 in -m) shift; for elem in $@; do echo $elem done | $cmd exit 0;; *) cmd=$cmd $1;; esac shift done -- \ Troels /\ Henriksen
Re: [dev] surf patch: bind keystrokes to snippets of Javascript
Sean Whitton s...@silentflame.com writes:
Hi,
On Tue, May 11, 2010 at 02:13:01PM +0100, Sean Whitton wrote:
On Tue, May 11, 2010 at 11:10:04AM +0200, Troels Henriksen wrote:
The attached patch lets you bind keys to small lines of Javascript to
run.
The intent is that the usual ~/.surf/script.js defines various methods,
which are then run by the bindings. This is much cleaner than having
script.js create its own event listeners for keybindings going outside
surf's own system.
This works brilliantly - thank you. If anyone was wondering how to add
keybindings to your config file, this is what I have in config.h for
hinting (that works):
{ 0,GDK_f, eval, { .v = (char *[]){
hintMode(), NULL } } },
{ 0,GDK_F, eval, { .v = (char *[]){
hintMode(true), NULL } } },
{ 0,GDK_Escape, eval, { .v = (char *[]){
removeHints(), NULL } } },
... and just comment out the line document.addEventListener all the way
down to the end of the hinting script in script.js.
Don't comment any JavaScript out; this breaks the binding of the numbers
to actually use the hints. Sorry.
You can remove some of the Javascript. This is the modified
script.js I use for hint mode (it also has a minor optimisation in the
tagging loop).
/* Based on chromium plugin code, adapted by Nibble@gmail.com and
* further refined by Troels Henriksen at...@sigkill.dk */
var hint_num_str = '';
var hint_elems = [];
var hint_enabled = false;
var hint_new_win = false;
function hintMode(new_win){
hint_enabled = true;
hint_new_win = new_win;
setHints();
document.addEventListener('keydown', hintHandler, false);
hint_num_str = '';
}
function hintHandler(e){
e.preventDefault(); //Stop Default Event
var pressedKey = get_key(e);
if (pressedKey == 'Enter') {
if (hint_num_str == '')
hint_num_str = '1';
judgeHintNum(Number(hint_num_str));
} else if (/[0-9]/.test(pressedKey) == false) {
removeHints();
} else {
hint_num_str += pressedKey;
var hint_num = Number(hint_num_str);
if (hint_num * 10 hint_elems.length + 1) {
judgeHintNum(hint_num);
} else {
var hint_elem = hint_elems[hint_num - 1];
if (hint_elem != undefined hint_elem.tagName.toLowerCase() ==
'a') {
setHighlight(hint_elem, true);
}
}
}
}
function setHighlight(elem, is_active) {
if (is_active) {
var active_elem =
document.body.querySelector('a[highlight=hint_active]');
if (active_elem != undefined)
active_elem.setAttribute('highlight', 'hint_elem');
elem.setAttribute('highlight', 'hint_active');
} else {
elem.setAttribute('highlight', 'hint_elem');
}
}
function setHintRules() {
var ss = document.styleSheets[0];
ss.insertRule('a[highlight=hint_elem] {background-color: yellow}', 0);
ss.insertRule('a[highlight=hint_active] {background-color: lime}', 0);
}
function deleteHintRules() {
var ss = document.styleSheets[0];
ss.deleteRule(0);
ss.deleteRule(0);
}
function judgeHintNum(hint_num) {
var hint_elem = hint_elems[hint_num - 1];
if (hint_elem != undefined) {
execSelect(hint_elem);
} else {
removeHints();
}
}
function execSelect(elem) {
var tag_name = elem.tagName.toLowerCase();
var type = elem.type ? elem.type.toLowerCase() : ;
if (tag_name == 'a' elem.href != '') {
setHighlight(elem, true);
// TODO: ajax, select
if (hint_new_win) {
window.open(elem.href);
} else {
location.href=elem.href;
}
} else if (tag_name == 'input' (type == submit || type == button ||
type == reset)) {
elem.click();
} else if (tag_name == 'input' (type == radio || type == checkbox)) {
// TODO: toggle checkbox
elem.checked = !elem.checked;
} else if (tag_name == 'input' || tag_name == 'textarea') {
elem.focus();
elem.setSelectionRange(elem.value.length, elem.value.length);
}
removeHints();
}
function setHints() {
setHintRules();
var win_top = window.scrollY;
var win_bottom = win_top + window.innerHeight;
var win_left = window.scrollX;
var win_right = win_left + window.innerWidth;
// TODO: area
var elems = document.body.querySelectorAll('a, input:not([type=hidden]),
textarea, select, button');
var div = document.createElement('div');
var base_node = document.createElement('span');
base_node.style.cssText = ['position: absolute;',
'font-size: 13px;',
'background-color: ' + 'red' + ';',
'color: white;',
'font-weight: bold;',
'padding: 0px 1px
[dev] Disconnect signals when closing web view
The attached patch fixes a crashing bug in surf. There's still plenty of crashing bugs left, though, so the difference is probably only academic at this point (and this feels ugly anyway - what's going on with GTK signal processing?) diff -r d9957625b700 surf.c --- a/surf.c Sun May 09 22:51:26 2010 +0200 +++ b/surf.c Mon May 10 21:17:25 2010 +0200 @@ -234,6 +234,9 @@ int i; Client *p; +/* We don't want signals to pop up while we are in mid-destruction */ + g_signal_handlers_disconnect_matched(GTK_WIDGET(c-view), G_SIGNAL_MATCH_DATA, 0, 0, 0, 0, c); + gtk_widget_destroy(c-indicator); gtk_widget_destroy(GTK_WIDGET(c-view)); gtk_widget_destroy(c-scroll); -- \ Troels /\ Henriksen
Re: [dev] [surf] A debian package?
Kai Heide heide@googlemail.com writes: 2010/5/5 Thuban arrakisp...@gmail.com: Hi all! Hi Does anyone knows when the debian package could be avaiable? http://ftp-master.debian.org/new/surf_0.3-1.html The debian creed says: It's done when it's done! When is a Debian package of surf useful? You generally need to recompile it to make it do anything really interesting. -- \ Troels /\ Henriksen
[dev] [dmenu] incremental output patch
The attached match makes dmenu print out the input text as it is
entered, rather than just the final selection.
This is useful if you make surf run the following shell
script snippet...
dmenu -r -p find: |\
while read -r find; do
xprop -id $xid -f _SURF_FIND 8s -set _SURF_FIND $find
done
... which gets you [the basics of] usable incremental search.
diff -r 545ec6141dc4 dmenu.1
--- a/dmenu.1 Wed May 05 11:42:39 2010 +0100
+++ b/dmenu.1 Wed May 05 21:04:44 2010 +0200
@@ -5,6 +5,7 @@
.B dmenu
.RB [ \-i ]
.RB [ \-b ]
+.RB [ \-r ]
.RB [ \-l lines]
.RB [ \-fn font]
.RB [ \-nb color]
@@ -27,6 +28,9 @@
.B \-b
defines that dmenu appears at the bottom.
.TP
+.B \-r
+incrementally print text on standard output as it is entered.
+.TP
.B \-l lines
activates vertical list mode.
The given number of lines will be displayed. Window height will get adjusted.
diff -r 545ec6141dc4 dmenu.c
--- a/dmenu.c Wed May 05 11:42:39 2010 +0100
+++ b/dmenu.c Wed May 05 21:04:44 2010 +0200
@@ -80,6 +80,7 @@
static int ret = 0;
static int cursor = 0;
static int screen;
+static int incremental;
static unsigned int mw, mh;
static unsigned int numlockmask = 0;
static Bool running = True;
@@ -574,6 +575,10 @@
if(!pattern)
return;
+ if (incremental) {
+ fprintf(stdout, %s\n, text);
+ fflush(stdout);
+ }
plen = strlen(pattern);
item = lexact = lprefix = lsubstr = itemend = exactend = prefixend = substrend = NULL;
for(i = allitems; i; i = i-next)
@@ -770,6 +775,9 @@
}
else if(!strcmp(argv[i], -b))
topbar = False;
+ else if(!strcmp(argv[i], -r)) {
+ incremental = 1;
+ }
else if(!strcmp(argv[i], -e)) {
if(++i argc) parent = atoi(argv[i]);
}
@@ -798,7 +806,7 @@
else if(!strcmp(argv[i], -v))
eprint(dmenu-VERSION, © 2006-2010 dmenu engineers, see LICENSE for details\n);
else
- eprint(usage: dmenu [-i] [-b] [-e xid] [-l lines] [-fn font] [-nb color]\n
+ eprint(usage: dmenu [-i] [-b] [-r] [-e xid] [-l lines] [-fn font] [-nb color]\n
[-nf color] [-p prompt] [-sb color] [-sf color] [-v]\n);
if(!setlocale(LC_CTYPE, ) || !XSupportsLocale())
fprintf(stderr, warning: no locale support\n);
--
\ Troels
/\ Henriksen
Re: [dev] dmenu visibility issue (+patch)
Connor Lane Smith c...@lubutu.com writes: Hey, On 1 April 2010 23:16, anonymous aim0s...@lavabit.com wrote: What if we run 2 dmenu? You can't. Grabbing the keyboard locks out all other processes, so a second dmenu just dies silently. Yes. This will indeed be a problem if two programs both wish to keep on top, but I don't think that will happen. Most keep-on-top programs (panels) use window manager assistance to keep from occluding other windows. And even if you end up with two programs fighting for supremacy, you can still just terminate one of them, they shouldn't become unresponsive. -- \ Troels /\ Henriksen
