Re: [dev] simple terminal : about fonts
So could some users give me the value of their config.h:font[] ? I'm quite happy with: Fantasque Sans Mono:pixelsize=16:antialias=true:autohint=false It looks great for reading text, and it's easy to tell il1| apart, and ({[ look very distinct as well. My only beef is that the ascii single quote looks exactly like the unicode apostrophe/smart-close-single-quote. -- Jason
Re: [dev] [dwm] [PATCH] support _NET_SUPPORTING_WM_CHECK
On 2015-05-11 09:47AM, Martti Kühne wrote: Is this one for the wiki or mainline? I don't think it would get used (much) on the wiki, since it doesn't create a user-visible feature. My hope is that it'll make some software behave better under dwm, though I only did enough research to find out that gtk+ 3.3.8+ will stop polling the WM regularly if this feature is present. I ran out of time/interest before I figured out what gtk+ does with this information it wants so badly. Hopefully it's for more than just working around bugs in compiz. -- Jason
Re: [dev] sple - A simple PDF links/emails extracotr.
Well, surprise, surprise, I was thinking about sed instead of falling asleep for a bit last night. I was excited about finally finding a way to print out multiple (possibly transformed) matches per line, but my solution was messy. Also, it was a little buggy (zero-length outputs broke it.) Here's the cleanest thing I could find today: sed -ne 's/THING/\n\0\n/g' -e 's/\(^[^\n]*\n\|\(\n\)\)\([^\n]*\)\n[^\n]*/\2\3/gp' So to print out all matches, each on their own line (even if there's multiple matches on the same line) you do your normal s/// and add \n on either side of what you want printed, then you add these sed args: -e 's/\(^[^\n]*\n\|\(\n\)\)\([^\n]*\)\n[^\n]*/\2\3/gp' So for extracting links from a pdf, that would be: pdftohtml -stdout foo.pdf | sed -ne 's/href=\([^]\+\)/\n\1\n/g' -e 's/\(^[^\n]*\n\|\(\n\)\)\([^\n]*\)\n[^\n]*/\2\3/gp' If you've got GNU sed, you can replace the ' -e ' in the middle with ;, or for a little speed boost: ;T;. -- Jason On 2015-05-06 11:19PM, Jason Woofenden wrote: Hi Hypsurus, I hope you're having fun coding. Don't let me detract from that. But if you just need to extract links from pdfs, you can do so with existing tools, eg: pdftohtml -stdout foo.pdf | sed -ne 's/\(^\|\n\)\n\([^\n]*\)\n[^\n]*/\1\2/gp; t; s/href=\([^]\+\)/\n\n\1\n/g; D' Sorry if that sed thing is more complex than it needs to be. I'm just learning the other sed commands besides s///. The extra complexity with the \ns is to handle multiple links on the same line. -- Jason
Re: [dev] sple - A simple PDF links/emails extracotr.
On 2015-05-07 05:07PM, Jochen Sprickerhof wrote: * Jason Woofenden ja...@jasonwoof.com [2015-05-07 10:09]: pdftohtml -stdout foo.pdf | sed -ne 's/href=\([^]\+\)/\n\1\n/g' -e 's/\(^[^\n]*\n\|\(\n\)\)\([^\n]*\)\n[^\n]*/\2\3/gp' I would use grep ;). Using my urlselct from [1] I would write: pdftotext foo.pdf - | urlselect Cheers Jochen [1] http://lists.suckless.org/dev/1504/26641.html Ooh, grep -o is great! So I guess my sed trick is only needed if you want to print less than the whole match, or need to do some sort of transformation (eg lowercasing part of it.) -- Jason
Re: [dev] Odds and ends (2/2): $XEMBED
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. 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. tabbed is neato, and I'd probably use it, (at least for a while) if I was happier with surf, but I can't help thinking that the cleaner and more generally useful solution is to build whatever tabbing features you want into the WM. That way you can have tabs with whatever windows you want. 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. I did this trick to create a run-dialog with zsh. Here's the zsh keybind that does the important magick: bindkey -s ^M ^E /dev/null 21 ! ; exit\n This would be a little cleaner if you set your WM to stack new windows just after the focused one. -- Jason
[dev] [dwm] [PATCH] support _NET_SUPPORTING_WM_CHECK
As documented here: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317670464 --- I developed this in the hopes that it would fix issues with feh running fullscreen. It didn't help with that (feh using the innacurate _MOTIF_WM_HINTS method) but it should at least stop gtk+ 3.3.8+ from polling regularly for WM features. The change to gtk+ is discussed here: https://bugzilla.gnome.org/show_bug.cgi?id=666921 dwm.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/dwm.c b/dwm.c index 169adcb..1e53a68 100644 --- a/dwm.c +++ b/dwm.c @@ -62,7 +62,7 @@ enum { CurNormal, CurResize, CurMove, CurLast }; /* cursor */ enum { SchemeNorm, SchemeSel, SchemeLast }; /* color schemes */ enum { NetSupported, NetWMName, NetWMState, NetWMFullscreen, NetActiveWindow, NetWMWindowType, - NetWMWindowTypeDialog, NetClientList, NetLast }; /* EWMH atoms */ + NetWMWindowTypeDialog, NetClientList, NetSupportingWMCheck, NetLast }; /* EWMH atoms */ enum { WMProtocols, WMDelete, WMState, WMTakeFocus, WMLast }; /* default atoms */ enum { ClkTagBar, ClkLtSymbol, ClkStatusText, ClkWinTitle, ClkClientWin, ClkRootWin, ClkLast }; /* clicks */ @@ -1526,6 +1526,7 @@ setup(void) { netatom[NetWMWindowType] = XInternAtom(dpy, _NET_WM_WINDOW_TYPE, False); netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, _NET_WM_WINDOW_TYPE_DIALOG, False); netatom[NetClientList] = XInternAtom(dpy, _NET_CLIENT_LIST, False); + netatom[NetSupportingWMCheck] = XInternAtom(dpy, _NET_SUPPORTING_WM_CHECK, False); /* init cursors */ cursor[CurNormal] = drw_cur_create(drw, XC_left_ptr); cursor[CurResize] = drw_cur_create(drw, XC_sizing); @@ -1744,6 +1745,12 @@ updatebars(void) { m-barwin = XCreateWindow(dpy, root, m-wx, m-by, m-ww, bh, 0, DefaultDepth(dpy, screen), CopyFromParent, DefaultVisual(dpy, screen), CWOverrideRedirect|CWBackPixmap|CWEventMask, wa); + XChangeProperty(dpy, root, netatom[NetSupportingWMCheck], XA_WINDOW, 32, + PropModeReplace, (unsigned char *) (m-barwin), 1); + XChangeProperty(dpy, m-barwin, netatom[NetSupportingWMCheck], XA_WINDOW, 32, + PropModeReplace, (unsigned char *) (m-barwin), 1); + XChangeProperty(dpy, m-barwin, netatom[NetWMName], XA_STRING, 8, + PropModeReplace, (unsigned char *) dwm, 3); XDefineCursor(dpy, m-barwin, cursor[CurNormal]-cursor); XMapRaised(dpy, m-barwin); } -- 2.1.4
Re: [dev] [surf] [PATCH] Simplify eval arg handling
On 2015-04-23 08:06PM, Jochen Sprickerhof wrote: Ok, it does make sense, I had overlooked it because eval() is usually not called. The arg-v is passed to evalscript() which expects an char*. Both implementations (before and after your patch) pass a char*. But (assuming I'm reading the code correctly) they don't pass the same address. Below I've removed the typecasts to make the difference more obvious. Pre-patch, the old code is passing: arg-v[0] which could also be written: *(arg-v) and after the patch: arg-v I just want to be clear that (as I read it anyway) this is not just a semantic change, but it changes what the code does. Sorry I don't know how to test this function to check which behavior is correct. -- Jason
Re: [dev] [surf] [PATCH] Simplify eval arg handling
This is making my brain hurt, but I'm pretty sure this change dereferences arg-v one fewer times. Does arg-v point directly to a string, or to a pointer to a string? -- Jason On 2015-04-22 05:30PM, Jochen Sprickerhof wrote: --- surf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/surf.c b/surf.c index 87c10ef..75fa5db 100644 --- a/surf.c +++ b/surf.c @@ -1314,7 +1314,7 @@ static void eval(Client *c, const Arg *arg) { WebKitWebFrame *frame = webkit_web_view_get_main_frame(c-view); evalscript(webkit_web_frame_get_global_context(frame), - ((char **)arg-v)[0], ); + (char *)arg-v, ); } static void -- 2.1.4
[dev] [dwm] [PATCH] create _MOTIF_WM_HINTS atom
Some clients (such as feh) check for the existance of this atom like so: XInternAtom(disp, _MOTIF_WM_HINTS, True); to see how/if they can get fullscreen. Also my first hit on a web search for x11 howto fullscreen says to check for this atom: http://www.tonyobryan.com/index.php?article=9 Note that they do not check if this atom is set on any window, just that it's been created before. So this patch may make no difference for you if you've run something like spectrwm in this X11 session. If I run ``feh -F *.png`` without that atom, the keys don't work (they go to the terminal that spawned feh) and feh complains about my WM (you can quit by right-clicking). With this patch (or running anything else that creates the atom) I can use the feh keybingings as normal. --- dwm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/dwm.c b/dwm.c index 169adcb..ace62c1 100644 --- a/dwm.c +++ b/dwm.c @@ -1526,6 +1526,7 @@ setup(void) { netatom[NetWMWindowType] = XInternAtom(dpy, _NET_WM_WINDOW_TYPE, False); netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, _NET_WM_WINDOW_TYPE_DIALOG, False); netatom[NetClientList] = XInternAtom(dpy, _NET_CLIENT_LIST, False); + XInternAtom(dpy, _MOTIF_WM_HINTS, False); /* clients may request borderless/fullscreen */ /* init cursors */ cursor[CurNormal] = drw_cur_create(drw, XC_left_ptr); cursor[CurResize] = drw_cur_create(drw, XC_sizing); -- 2.1.4
[dev] Introducing JasonWoof
Hi all, Just wanted to introduce myself. I'm new to this mailing list, though I've been in the chatroom for a bit. I've been coding since 1992, when I was 12. I've dabbled with various free software projects over the years. My most significant contribution in this area is VoR: http://sametwice.com/vor Lately, I've been hacking on dwm quite a bit, and st a little. I've made some changes that I think should be merged upstream, some that should perhaps land in the patches directory, and some that are probably too weird and/or hacky for either. I'm making an effort to match your coding style, patch conventions, etc., but please train me as needed :) Now I'll refresh my memory on how to get git to send patches, and send in my first dwm patch. -- Jason