You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After using the package for a few weeks, I find there's a pattern in my usage which
doesn't fit the working model for the package. perhaps you'll agree this should be changed...
The common case of moving between windows is usually just that, I want to switch to another
window and keep working right away, but I find myself waiting for the idle-time to finish each time.
The relatively less common task of resizing windows (or splitting, but i just use C-x 2/3), I would
prefer to do by manually activating the win-switch mode and having a much longer idle time (or perhaps even
an explicit toggle binding) to get everything looking the way I want it to and then switch back to
normal work. as it is I find myself racing to hit the binding before the idle-time runs out
(the complete opposite of case 1).
as it is, these two things are conflated into one value of win-switch-idle-time, which i'm forced to set at
an intermediate value which is both not terrible and not very good for either use-case.
I suggest either making window movement mode-less and making the enter/exit switch-mode be based
on a toggle key-binding, rather then a timed mechanism.
another way might be to have each of these be controlled by a separate idle-time variable,
with the addition of an exit-mode-now binding. this would maintain the expected behavior for veteran users,
while someone with my own preferences could set one idle-time to 0 and the other to infinity and manually
enter/exit the mode: cake->have&&eat->+1!
Thanks again for putting this out, it's a great convenience.
The text was updated successfully, but these errors were encountered:
Hi again and thanks for the ideas. My apologies for my delayed response; it's been a crazy time this past few weeks.
I see exactly what you are saying and agree that that would be useful. Let me think it over a bit, but something along the lines of your second solution strikes me as the way to go. I'll work on that change.
I'm guessing you are aware of this, but regarding your #1, there are two other options for exiting the mode without waiting: using any non-command key, which is re-echoed as though typed fresh or using the exit key (u by default). So for instance doing C-x o C-a will switch and move to the beginning of the line (exiting the mode) and C-x o u will switch and exit the mode. I find that I've gotten used to automatically using the exit key when my next key will be one of the directions but otherwise just keep typing, though your mileage may vary. Of course, this doesn't obviate the need for your suggestion, but I thought it might be useful to point out.
Hi again,
After using the package for a few weeks, I find there's a pattern in my usage which
doesn't fit the working model for the package. perhaps you'll agree this should be changed...
The common case of moving between windows is usually just that, I want to switch to another
window and keep working right away, but I find myself waiting for the idle-time to finish each time.
The relatively less common task of resizing windows (or splitting, but i just use C-x 2/3), I would
prefer to do by manually activating the win-switch mode and having a much longer idle time (or perhaps even
an explicit toggle binding) to get everything looking the way I want it to and then switch back to
normal work. as it is I find myself racing to hit the binding before the idle-time runs out
(the complete opposite of case 1).
as it is, these two things are conflated into one value of win-switch-idle-time, which i'm forced to set at
an intermediate value which is both not terrible and not very good for either use-case.
I suggest either making window movement mode-less and making the enter/exit switch-mode be based
on a toggle key-binding, rather then a timed mechanism.
another way might be to have each of these be controlled by a separate idle-time variable,
with the addition of an exit-mode-now binding. this would maintain the expected behavior for veteran users,
while someone with my own preferences could set one idle-time to 0 and the other to infinity and manually
enter/exit the mode: cake->have&&eat->+1!
Thanks again for putting this out, it's a great convenience.
The text was updated successfully, but these errors were encountered: