| #!/usr/bin/bash | |
| # Goal: move workspace $1 to the currently focused output, move the workspace on the current output | |
| # to the output where $1 was. | |
| # The workspace we want to end up on | |
| dest_ws=$1 | |
| # The output where the destination ws resides | |
| output_of_dest_ws=$(i3-msg -t get_workspaces | jq .[] | jq -r 'select(.name == "'$dest_ws'").output') | |
| # The currently focused output |
It's come to my attention that some people have been spamming issue trackers with a link to this gist. While it's a good idea to inform people of the situation in principle, please do not do this. By all means spread the word in the communities that you are a part of, after verifying that they are not aware yet, but unsolicited spam is not helpful. It will just frustrate people.
A number of things have happened since the last update.
Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.
Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.
The Wayland project seems to operate like they were starting a greenfield project, whereas at the same time they try to position Wayland as "the X11 successor", which would clearly require a lot of thought about not breaking, or at least providing a smooth upgrade path for, existing software.
In fact, it is merely an incompatible alternative, and not e
This steps should help working remotely with Sublime Text. They are meant to be incremental, just setting up SFTP will go a long way.
I have all my code on my laptop, edit locally and automatically push the files to my server.
I never edit "tracked" files on the server directly.
I sometimes modify untracked files on the server using rmate (see below).
\o will be a regular 'o' in this context.
| \033[38;2;23;147;209m ▄ | |
| ▟█▙ | |
| ▟███▙ | |
| ▟█████▙ | |
| ▟███████▙ | |
| ▂▔▀▜██████▙ | |
| ▟██▅▂▝▜█████▙ | |
| ▟█████████████▙ | |
| ▟███████████████▙ | |
| ▟█████████████████▙ |
| #!/bin/bash | |
| if [[ $1 == "dark" ]]; then | |
| UI_THEME_GTK="Mojave-dark" | |
| UI_THEME_QT="KvMojave" | |
| UI_ICONS="Faenza-Ambiance" | |
| VIM_BG="dark" | |
| elif [[ $1 == "light" ]]; then | |
| UI_THEME_GTK="Mojave-light" | |
| UI_THEME_QT="KvMojaveLight" |
| #!/bin/bash | |
| (( ${#} >= 3 )) || { echo "usage: $(basename ${0}) github-username archive-file [files | directories]"; exit 1; } | |
| exec >${2} | |
| zero='${0}' | |
| cat <<SCRIPT | |
| #!/usr/bin/env bash | |
| usage() { | |
| echo "usage: bash ${zero} identity-file" |
| # OBJECTIVE: Install Arch Linux with encrypted root and swap filesystems with an ENCRYPTED BOOT and boot from UEFI. We will | |
| also decrypt and mount our entire encrypted system using a single LUKS passphrase entry. | |
| # Note: This method supports both dedicated Arch installs and those who wish to install Arch on a multi-OS-UEFI booting system. | |
| # External USB HDD/SSD Installers Notes: Encrypted Arch installs can be booted and run from an external USB HDD or SSD, but | |
| # only when the installation is correctly set up. There are several necessary changes to my standard procedure you'll want | |
| # to make during the install process. Read my External USB HDD/SSD Installation section below before proceeding. |