[dev] [st] Shift Tab does not work
I use Vim, and there you can cycle forward through completion using Tab and backward using Shift+Tab, this does not work in st, but it works in xterm. I tested against tip. Though I guess there is some interesting stuff going on with this, since in general it seems tab sends ^I and thus you can cycle forward using ctrl+i, however shift+ctrl+i does not cycle in Vim in xterm. Though I guess this is to be expected since iirc you cant shift control codes. Of course to be fair in Vim one can work without this since you can cycle forward using ctrl+n, thus this is a minor problem. Still this is a small discrepancy between xterm and st that might not have been intended to be there.
Re: [dev] [st] Add a newline to the string printed in die
Am 11.12.2012 um 12:38 schrieb Marc Andre Tanner m...@brain-dump.org: Please send patches as attached files. Since we are using now git, it is easier and logic send the patches in this way, so the code of the patch can be included and modified in replies. You only have to use git am if you want to incorpore then to the main repository ,and it will keep the correct author and commiter, that I can see this information is lost now (I think it is not the correct way put a 'thanks' in the commit message). I won’t accept such patches. Please send attached files. I won’t imple‐ ment the outdated mbox or Maildir format for this. That is retarded. Inline patches which facilitate commenting are the prefered patch format. Get familiar with your git tools. I agree and while there, maybe learn to use your MUA as well. Regards, Joerg
Re: [dev] [st] Add a newline to the string printed in die
Am 11.12.2012 um 18:34 schrieb Christoph Lohmann 2...@r-36.net: I don’t know why people prefer to see the big patches inline, Ideally the patches are small :) so you have the scroll past the whole patch to the next e‐mail, when you are So, scrolling is a problem for you? I do shift+g usually. using a pager to read your e‐mail. What? May I suggest to start learning how to use a MUA and the according Editor? It’s easier when the MUA is filtering the patch file out, by simply showing, that some properly formatted patch is attached, which you can download, What? Download the patch? In what retarded way are you accessing mails? Even if MIME sucks, It sucks. People don’t know how to properly format e‐mails, so they will toppost on top of long patches and simply attach the whole thing. Whats wrong with having patch again in the reply at the bottom? Regards, Joerg
Re: [dev] [st] Shift Tab does not work
But, it's error-prone to have two places to keep track of what keys get mapped. So, I fixed this for myself a while ago by removing mappedkeys entirely. Patch attached. I agree with you that it is error-prone, but if we remove it then each time a key is pressed it is necessary look up in table, but the usual case (a latin key) it is the worst case, look in the table until the end. Since keyboard typing depend of the user, it is not a big problem (good typists can type 200 keys per minute) so the performance penalty will not be able noticeable. Doing a binary search (bsearch call) is not easy, since define a order in these key assignation is hard, so I think the best strategy is the sequencial search. My suggestion is applying your patch and try get a better solution.
Re: [dev] [st] Shift Tab does not work
Greetings.
On Thu, 13 Dec 2012 20:46:11 +0100 Benjamin R. Haskell suckl...@benizi.com
wrote:
On Thu, 13 Dec 2012, Roberto E. Vargas Caballero wrote:
Looking in the repository I can see that the commit 16ccf (Fix tab
key) inserted this code, and I have tested that is such commit it was
working, so we have a regression. I am going try now a bisection and
try locate which commit broken this key.
The bisect indicates that the commit whichs performs the regression is
2b652 (Optimizing the key lookup to the X11 function key), Which does
that if the event is smaller than 0xFF00, then the lookup is not
performed, but how we can see in keysymdef.h:
#define XK_ISO_Left_Tab 0xfe20
So the solution is modify the line 2731 of st.c (if((k 0x) 0xFF00)).
I will send a patch soon for this issue.
This can be fixed by changing in config.{,def.}h:
-static KeySym mappedkeys[] = { -1 };
+static KeySym mappedkeys[] = { XK_ISO_Left_Tab };
But, it's error-prone to have two places to keep track of what keys get
mapped. So, I fixed this for myself a while ago by removing mappedkeys
entirely. Patch attached.
As said by Roberto, your patch will let st traverse the whole key array
on each keypress. That’s why the simple check was applied and if you re‐
ally want to map some other key – which is stated in the comment above
that one –, use this array. This is purely an optimisation to save CPU
cycles.
I’ve changed the check for the special keys so XK_ISO_Left_Tab is now
checked in the array. Thanks for the bug report.
Sincerely,
Christoph Lohmann
[dev] Focus previously focused window
Hello, I was wondering if anyone knows of a patch that provides the means to return to the previously focused window (if it exists). That is, for example, if I'm on window1 and launch a window2, MOD+p (say) would take me back to window1. Thanks Manolo --
Re: [dev] Focus previously focused window
On Thu, Dec 13, 2012 at 03:04:01PM -0500, Manolo Martínez wrote:
Hello,
I was wondering if anyone knows of a patch that provides the means to
return to the previously focused window (if it exists). That is, for
example, if I'm
on window1 and launch a window2, MOD+p (say) would take me back to
window1.
You can try the attached patch. Alt-Ctrl-j brings you back to the previous
window. Pressing Alt-Ctrl-j once more, you get to the one before that, and
so on. With Alt-Ctrl-k you go forward again.
Andreas
# HG changeset patch
# Parent dfd36140a7bcac030bf22a2e81892c0bf3bb52a6
cycle through focus stack
diff --git a/config.def.h b/config.def.h
--- a/config.def.h
+++ b/config.def.h
@@ -60,6 +60,10 @@
{ MODKEY, XK_b, togglebar, {0} },
{ MODKEY, XK_j, focusstack, {.i = +1 } },
{ MODKEY, XK_k, focusstack, {.i = -1 } },
+ { MODKEY|ShiftMask, XK_j, cycletiled, {.i = +1 } },
+ { MODKEY|ShiftMask, XK_k, cycletiled, {.i = -1 } },
+ { MODKEY|ControlMask, XK_j, cycleglobal,{.i = +1 } },
+ { MODKEY|ControlMask, XK_k, cycleglobal,{.i = -1 } },
{ MODKEY, XK_i, incnmaster, {.i = +1 } },
{ MODKEY, XK_d, incnmaster, {.i = -1 } },
{ MODKEY, XK_h, setmfact, {.f = -0.05}
},
diff --git a/dwm.c b/dwm.c
--- a/dwm.c
+++ b/dwm.c
@@ -173,6 +173,8 @@
static void configurenotify(XEvent *e);
static void configurerequest(XEvent *e);
static Monitor *createmon(void);
+static void cycleglobal(const Arg *arg);
+static void cycletiled(const Arg *arg);
static void destroynotify(XEvent *e);
static void detach(Client *c);
static void detachstack(Client *c);
@@ -644,6 +646,61 @@
XSync(dpy, False);
}
+void
+cycleglobal(const Arg *arg)
+{
+ Client *c = selmon-stack, *cn;
+
+ if(!c)
+ return;
+
+ if (c-snext) {
+ unfocus(selmon-sel,False);
+
+ for(cn = c; cn-snext; cn = cn-snext);
+
+ if (arg-i 0) {
+ if (selmon-sel) {
+ cn-snext = selmon-stack;
+ c = selmon-stack = selmon-stack-snext;
+ cn-snext-snext = NULL;
+ }
+ } else {
+ c = cn;
+ }
+ }
+
+ if(!ISVISIBLE(c)) {
+ c-mon-seltags ^= 1;
+ c-mon-tagset[c-mon-seltags] = c-tags;
+ }
+ focus(c);
+ arrange(c-mon);
+}
+
+void
+cycletiled(const Arg *arg)
+{
+ Client *c = nexttiled(selmon-clients),*cn;
+ if(!selmon-lt[selmon-sellt]-arrange || !c ||
!(cn=nexttiled(c-next)))
+ return;
+
+ if (arg-i 0) {
+ detach(c);
+ for(; cn-next; cn = cn-next);
+ cn-next = c;
+ c-next = NULL;
+ c = nexttiled(selmon-clients);
+
+ } else {
+ for(c=cn; (cn=nexttiled(cn-next)) != NULL; c=cn);
+ detach(c);
+ attach(c);
+ }
+ focusstack(arg);
+ arrange(c-mon);
+}
+
Monitor *
createmon(void) {
Monitor *m;
Re: [dev] Focus previously focused window
On 12/13/12 at 10:16pm, Andreas Amann wrote: On Thu, Dec 13, 2012 at 03:04:01PM -0500, Manolo Martínez wrote: Hello, I was wondering if anyone knows of a patch that provides the means to return to the previously focused window (if it exists). That is, for example, if I'm on window1 and launch a window2, MOD+p (say) would take me back to window1. You can try the attached patch. Alt-Ctrl-j brings you back to the previous window. Pressing Alt-Ctrl-j once more, you get to the one before that, and so on. With Alt-Ctrl-k you go forward again. Andreas Thanks a lot. I will give it a try. I have to ask: how you just come up with it, prompted by my question? If so, double thanks. Manolo
Re: [dev] Focus previously focused window
On 12/13/12 at 03:20pm, Eric Pruitt wrote: Hey Manolo, On Thu, Dec 13, 2012 at 03:04:01PM -0500, Manolo Martínez wrote: I was wondering if anyone knows of a patch that provides the means to return to the previously focused window (if it exists). That is, for example, if I'm on window1 and launch a window2, MOD+p (say) would take me back to window1. There's the swapfocus patch at http://dwm.suckless.org/patches/swapfocus. The downside to this patch is that it remembers _only_ the most recently selected window, and changing tag sets or opening and closing windows will often strip you of the ability to go back to a previously selected client. I wrote an alternate version of swapfocus that sorta works on a per-tag basis. See the patch comments for an explanation of the sorta part. That patch had its own problems as well, specifically that due to the way I wrote it, opening a new window would throw of the previous client selection at times. Some days ago, I decided to take a completely different approach and wrote the lastclient.diff patch that is also attached. With this patch, every time a window is focused, the time the window was focused is recorded. When you call the lastclient function, the most recently focused window is selected which eliminates problems with changing tags, but depending on your workflow, the focused timestamp base approach may throw you off at times. Eric Thanks! I'm sure one of these will do the trick. The use case is pretty simple, actually. Manolo
