Am Sat, 23 Oct 2010 15:05:26 +0900 (JST)
schrieb Teika Kazura <[email protected]>:
> On Sat, 16 Oct 2010 12:13:48 +0200, Christopher Roy Bratusek wrote:
> > I'm just wondering about the default behavior of
> > send/copy-window-to-next/previous-workspace:
> >
> > I wonder whether switching workspaces by default is desired. I mean when I
> > move a
> > window to another workspace it's 50% whether I want to go with, but when I
> > copy it, I
> > never want to go with it.
>
> Hmm, make the name "move" obsolete, and create "carry" and "push" may be
> what you want. Got no good idea for "copy". Copy-stay and copy-go?
> (Darn.) In this case, it might be better to seperate WS menu from
> the win-op-menu, so that user can choose.
Well -move is fully okay, if we don't follow the window, what about
{move,copy}-window-to-{next,previous}-workspace{,-follow}?
> # In fact, I've been wanting a command "carry" which does:
> # $ mv file1 2 3 dir/
> # $ cd dir/
> # but I haven't written this simple code for years.
I assume you use GNU Bash:
Variant #1:
mvcd () {
destination="{!#}"
mv "$...@}"
builtin cd "${destination}"
}
Variant #2 (not fully compatible, but more 1337):
mvcd () {
if [[ $1 == --help || $1 == -h ]]; then
mv --help
exit 0
elif [[ ${#} -lt "2" && ${1} != *{*,* ]]; then
echo "not enough arguments"
exit 1
fi
destination="${!#}"
if [[ "${destination}" == */ && ! -e "${destination}" ]]; then
mkdir -p "${!#}"
elif [[ -f "${destination}" ]]; then
echo "destination already exists, but is a file."
exit 1
fi
args=( "$@" )
unset args[$#-1]
set -- "${ar...@]}"
for path in "${ar...@]}"; do
test "${path:0:1}" == - && MV_OPTS+="$path " && continue
if test "${path}" == "*{,*" ; then
mv $MV_OPTS "${path}"
else mv $MV_OPTS "${path}" "${destination}"
fi
done
if [[ -d "${destination}" ]]; then
builtin cd "${destination}"
fi
}
> # This is "itchy". In firefox, when I open a link in a new tab,
> # 70% is I want to go see the new tab, but there's no control for
> # each time. Only "always go to the new tab" option is offered.
If you install Taberwocky or TabMixPlus, then you get Context-Menu entries
"Open In New
Tab in Background" and "Open In New Tab in Foreground" or whatever the englisch
labels are
> > Another thing that just came in my mind: in window-ops > toggle there's
> > "Sticky". This
> > sticky command is combined sticky and sticky-viewport, wouldn't it be
> > better to have
> > separated entries for both?
>
> Logically it's perfectly correct. Dunno the practice.
> (I don't use WS. Some windows are matched to be VP-sticky. When I want
> to carry a window to another VP slot, I make it temporarily toggle VP
> stickiness with a key binding, go there, and release it.)
>
> In fact, sawfish's "stickiness" is too ambiguous. It sometimes means
> WS-sticky, otherwise WS-VP-sticky. Should I clean this up?
I think we should do that.
Regards,
Chris
> Regards,
> Teika (Teika kazura)
