[dev] Shift-Selection in Emacs with st
I am unable to do shift selection in st (the suckless tool), with Emacs
(http://www.gnu.org/software/emacs/manual/html_node/emacs/Shift-Selection.html).
The
arrow keys also did not work in Emacs, so I fixed this by adding the
following to my config.h:
{ XK_Left, \033[D },
{ XK_Right, \033[C },
{ XK_Up,\033[A },
{ XK_Down, \033[B },
Now, when I try to shift-select (with the above fix for the arrow keys),
just the arrow keys move, as if shift key wasn't being pressed.
Thanks for making this really cool terminal, by the way (besides this,
st works perfectly in emacs, not conflicting with its keybindings like
urxvt did).
Sara
--
Nothing is too wonderful to be true, if it be consistent with the laws of
nature. ~Michael Faraday
Re: [dev] Sup and dmc
On 4/6/11, Hank D hdon...@gmail.com wrote: The problem is that mutt sucks, too. True. It can be configured to suck even less, though. But I want a minimalist alternative that's configured to suck less *at build time*. If the default for a text-based MUA is not to just display text, something's awry. IMO, MUA should simply draw a list of messages to it's console, and simply pipe message contents through mailcap, for opening in another window, overwriting the message list or (if you're living in another century than I am) forwarding to a line printer producing a hardcopy. Mutt, on the other hand, sports a built in pager. Sucks. Not to mention the very outdated model of email it uses and the lack of support for multiple email accounts. I thought that to be mostly a MTA problem. Note, though, that mutt supports multiple 'mailboxes' (switching between them is usually bound to 'c'). Really, how many MUAs out there let WMs control their windows? Claws?
Re: [dev] [surf] [PATCHES] (1) GConf URL schema handlers (2) delete _SURF_GO xprop (3) close stdout sending XID
On 4/7/11, Nick suckless-...@njw.me.uk wrote: Quoth Bjartur Thorlacius: On 4/7/11, Adam Strzelecki o...@java.pl wrote: (2) surf-2-delete-_SURF_GO-once-received.patch This xprop (atom) may be used to tell *surf* to go to specific URL. It is safer to remove this atom just after it is set in case we send some URL containing passwords or auth tokens such as http://login:mypassw...@myserver.com/ Anyway _SURF_URI will represents current page URL, so keeping _SURF_GO makes no sense. In our case it is matter of safety to not expose this one. Is there no race condition inherent? What happens if you try to read _SURF_GO just after it's set? _SURF_GO shouldn't be read, though, it's only used for telling surf to load a new page. Unless I'm misunderstanding your point. If it can't be read, then what's the original security breach?
Re: [dev] Sup and dmc
Bjartur Thorlacius svartma...@gmail.com writes: On 4/6/11, Hank D hdon...@gmail.com wrote: The problem is that mutt sucks, too. True. It can be configured to suck even less, though. But I want a minimalist alternative that's configured to suck less *at build time*. If the default for a text-based MUA is not to just display text, something's awry. IMO, MUA should simply draw a list of messages to it's console, and simply pipe message contents through mailcap, for opening in another window, overwriting the message list or (if you're living in another century than I am) forwarding to a line printer producing a hardcopy. Mutt, on the other hand, sports a built in pager. Sucks. I use no suckless MUA (gnus + mairix) but from those two mairix is more important: any MUA that does not integrate easily fast full text filtering of messages is just unusable with today's tons of mails.
Re: [dev] @bleidl, 26/03/11 19:41
Seriously, do these sites provide anything that IRC doesn't? And no, groups have no use, and thus don't count. IRC is more distributed than StatusNet twitter-clones, and has way more implementations. Most of them are terrible backdoors that are best kept locked away, but some are almost usable. Really, I'd prefer an IRC bot/logger to these μblogging *websites*. HTML is a terribly overcomplicated overkill.
Re: [dev] [surf] [PATCHES] (1) GConf URL schema handlers (2) delete _SURF_GO xprop (3) close stdout sending XID
_SURF_GO just after it's set? _SURF_GO shouldn't be read, though, it's only used for telling surf to load a new page. Unless I'm misunderstanding your point. If it can't be read, then what's the original security breach? Nick wrote it shouldn't be read, but it can. So right now you can set _SURF_GO and what you set is visible (including any passwords) using xprop, while _SURF_URI contains same URL but this time password-less. -- Adam Strzelecki
Re: [dev] DWM - Issue with nmaster under pertag
On 9 April 2011 21:46, Novar Tum novar...@yahoo.com wrote: I hope that this makes sense, not sure how else to explain it. Please let me know if you need any additional clarification. Does anyone know how this issue could be fixed, as the pertag patch does state that it should work with nmaster? Besides this small issue, I have not had any other problems with pertag (e.g. with bstack, movestack). Have you looked at using the flextile patch, which provides the functionality of both pertag and nmaster? Alex
Re: [dev] DWM - Issue with nmaster under pertag
Hi, pertag[1] does explicitly claim to be compatible with nmaster. Does anyone know whether this is an error? [1]: http://dwm.suckless.org/patches/pertag Thanks, cls
Re: [dev] DWM - Issue with nmaster under pertag
Hi, Thank you for your responses. With regard to flextile, I have looked at the patch and will use it as a last resort. I have everything set up like I want, with only this relatively minor issue persisting. I actually posted this question on the arch linux forum as well. There, a user responded that he is experiencing the same issue although he had never noticed it before (he rarely uses nmaster). Could anyone else who uses nmaster/pertag confirm this error or suggest a solution? Like Connor said, pertag states that it is compatible with nmaster. Thank you once again for the support. From: Connor Lane Smith c...@lubutu.com To: dev mail list dev@suckless.org Sent: Sat, April 9, 2011 5:48:51 PM Subject: Re: [dev] DWM - Issue with nmaster under pertag Hi, pertag[1] does explicitly claim to be compatible with nmaster. Does anyone know whether this is an error? [1]: http://dwm.suckless.org/patches/pertag Thanks, cls
Re: [dev] [st] 0.1 Feedback - Was: A few small patches
On 4/5/11, Bryan Bennett bbenn...@gmail.com wrote: C knowledge is rather low (I'm a python programmer...) so it's going Reading this line I felt an urge to reply with the words Die in hell alone. I'm going to punching uriel in the face now, for infecting me with mindless trölling. In especial considering you probably write better C than I could.
Re: [dev] [surf] [PATCHES] (1) GConf URL schema handlers (2) delete _SURF_GO xprop (3) close stdout sending XID
Adam Strzelecki o...@java.pl wrote: It is safer to remove this atom just after it is set in case we send some URL containing passwords or auth tokens I'm confused as to the state between setting _SURF_GO and removing it. It smells like a race condition to me, but then again I don't understand X11 properties. I'd like a clarification as to how security is kept in the meantime (between setting and removal of _SURF_GO).
Re: [dev] [surf] [PATCHES] (1) GConf URL schema handlers (2) delete _SURF_GO xprop (3) close stdout sending XID
On Sat, 9 Apr 2011, Bjartur Thorlacius wrote: Adam Strzelecki wrote: It is safer to remove this atom just after it is set in case we send some URL containing passwords or auth tokens I'm confused as to the state between setting _SURF_GO and removing it. It smells like a race condition to me, but then again I don't understand X11 properties. I'd like a clarification as to how security is kept in the meantime (between setting and removal of _SURF_GO). Security isn't kept. This seems like more of a prevention of accidental disclosure than real security. (And therefore pointless...?) As an example, with this patch applied, run the following: # start surf, grabbing its ID $ surf -x 52428803 # in a 'spy' terminal $ xprop -spy -id 52428803 _SURF_GO # elsewhere, update _SURF_GO: $ sprop 52428803 _SURF_GO asdf The output in the spy terminal is: _SURF_GO: not found _SURF_GO(UTF8_STRING) = 0x61, 0x73, 0x64, 0x66 == asdf _SURF_GO: not found -- Best, Ben
Re: [dev] Panels and Touch support
On Wed, 6 Apr 2011, Christoph Lohmann wrote: Hello comrades, attached is a patch for dwm, which will add real support for the _NET_WM_WINDOW_TYPE. What is this patch against? I wanted to try this out, but even the first hunk of the patch doesn't apply against hg tip. And the parent listed in the header: # Parent d92f9b65f85f19122ccc0e19ee7dca089644bd81 doesn't exist, AFAICT. -- Best, Ben
Re: [dev] Panels and Touch support
On Sun, 10 Apr 2011, Benjamin R. Haskell wrote: On Wed, 6 Apr 2011, Christoph Lohmann wrote: Hello comrades, attached is a patch for dwm, which will add real support for the _NET_WM_WINDOW_TYPE. What is this patch against? I wanted to try this out, but even the first hunk of the patch doesn't apply against hg tip. Nevermind. Found your March 24 message with the 'toolbar and focus' patch. Adding that first fixed it. That other patch doesn't live in a branch of any sort, does it? I never remember how hg does branches. -- Best, Ben
