All Projects โ†’ infokiller โ†’ config-public

infokiller / config-public

Licence: MIT License
Linux/WSL config to optimize ergonomics, security, and productivity: vim/neovim, zsh, tmux, i3, emacs, vscode, ipython, jupyter, ranger, fzf, kitty, xkb, selfquant, firejail, systemd, etc

Programming Languages

shell
77523 projects
python
139335 projects - #7 most used programming language
Vim Script
2826 projects
autohotkey
350 projects
emacs lisp
2029 projects
Vim Snippet
174 projects

Projects that are alternatives of or similar to config-public

Dotfiles
๐Ÿ’พ Ian's dotfiles, utils, and Zsh/Vim/tmux configs
Stars: โœญ 554 (+3857.14%)
Mutual labels:  dotfiles, zsh, tmux, vscode
dotfiles
My collection of dotfiles
Stars: โœญ 77 (+450%)
Mutual labels:  tmux, archlinux, ipython, i3
Dotfiles
If there is a shell, there is a way!
Stars: โœญ 112 (+700%)
Mutual labels:  dotfiles, zsh, tmux, i3
.dotfiles
There's no place like ~ !
Stars: โœญ 265 (+1792.86%)
Mutual labels:  dotfiles, zsh, tmux, archlinux
Dotfiles
Get ready for dotfiles. Contains i3, i3blocks, rofi, dunst, picom, vim, tmux, and zsh.
Stars: โœญ 985 (+6935.71%)
Mutual labels:  dotfiles, zsh, tmux, i3
Dotfiles
๐Ÿ’€ dotfiles! managed by GNU stow
Stars: โœญ 85 (+507.14%)
Mutual labels:  dotfiles, zsh, tmux, i3
dotfiles
cross-platform (linux (arch), macos, android (termux), windows (WSL)) dotfiles and scripts, using yadm
Stars: โœญ 17 (+21.43%)
Mutual labels:  dotfiles, zsh, tmux, ranger
dotfiles
My dotfiles for oh-my-zsh, vim and tmux ๐Ÿ“Ÿ
Stars: โœญ 23 (+64.29%)
Mutual labels:  dotfiles, zsh, tmux
dotfiles
My personal dotfiles repository
Stars: โœญ 36 (+157.14%)
Mutual labels:  archlinux, i3, ranger
Dotfiles
Passionately crafted configs for CLI lovers ๐Ÿงโค๏ธ
Stars: โœญ 70 (+400%)
Mutual labels:  tmux, i3, ranger
dotfiles
๐Ÿก .files, including zsh, tmux, vim, and git. Also macOS setup. Good stuff.
Stars: โœญ 30 (+114.29%)
Mutual labels:  dotfiles, zsh, tmux
dotfiles
dotfiles of my linux setup
Stars: โœญ 25 (+78.57%)
Mutual labels:  dotfiles, zsh, ranger
Dot Files
โšก๏ธ Well documented, terminal centric web developer's dot files. Neovim, Zsh, Tmux, Git, etc.
Stars: โœญ 209 (+1392.86%)
Mutual labels:  dotfiles, zsh, tmux
dotfiles
Doom Emacs, a few-years old vim config, tmux, i3, zsh, polybar
Stars: โœญ 15 (+7.14%)
Mutual labels:  tmux, i3, doom-emacs
dotfiles
Your dotfiles are how you personalize your system. These are mine.
Stars: โœญ 12 (-14.29%)
Mutual labels:  dotfiles, zsh, tmux
dotfiles
Config files for i3, polybar, rofi, mpv, Xresources, kitty and some bash-things...
Stars: โœญ 52 (+271.43%)
Mutual labels:  dotfiles, zsh, i3
Dotfiles
๐Ÿ˜ˆ Vim, git, zsh, tmux, and other goodies.
Stars: โœญ 240 (+1614.29%)
Mutual labels:  dotfiles, zsh, tmux
Dotfiles
๐ŸŒธ Configuration for i3, kitty, picom, ZSH, gtk, qutebrowser, qbittorrent and more... (All tools for an arch linux new installation)
Stars: โœญ 15 (+7.14%)
Mutual labels:  dotfiles, zsh, i3
dotfiles
There is no place like ~/
Stars: โœญ 19 (+35.71%)
Mutual labels:  dotfiles, tmux, i3
dotfiles
๐Ÿš€ tmux, ohmyzsh, powerlevel10k, neovim ๐Ÿ”ง
Stars: โœญ 24 (+71.43%)
Mutual labels:  dotfiles, zsh, tmux

Public config repo

This repo contains config files (commonly called dotfiles) targeting Linux and WSL. It is my humble attempt to optimize ergonomics, security, and productivity. No doubt that I spent too much time micro-optimizing them, and I still have a psychotic urge to keep improving them. Hopefully, I'll be able to recover one day.

Feel free to steal anything that seems useful to you. That said, you shouldn't blindly copy stuff because:

  • I only test this repo on my machines so some things may be catastrophically broken for you
  • Some config/scripts rely on git repos I haven't published publicly yet
  • Some bits of my setup is highly optimized for my own taste and you will probably hate it

In addition, I provide absolutely no backward compatibility guarantees, and I sometimes fully reset the git history and start from scratch (though that will hopefully stop once this repo is more stable).

Specific configs that may be more interesting for you: vim, tmux, zsh, vscode, ipython, ranger, i3, bash, and probably others I forgot.

Coding guidelines

General

  • Don't split large files just for the sake of organization: it's usually better to do the organization within the file (using functions, etc). Good reasons for splitting files include:
    • There are use cases that require only using part of the file. For example, my shell configuration has separate files for defining functions and aliases (functions.sh) and for terminal settings (settings.sh), since I have a use case where only the former is needed (parsing shell aliases from IPython). In this case, using the same file for both would add cognitive burden when working on the IPython config and make the code uglier with conditionals.
    • Modularization and controlling internal dependencies. For example, if a large part of a file contains one public function that's used by other parts, and many private utility functions that are used only for implementing this public function, separating this public function and all its dependencies into a separate file can clarify the dependencies and reduce cognitive load.
    • Editors start crawling. As of 2020-05-06, I ran into issues with my vim config in files that have more than 1000 lines. It seems that vim plugin authors don't test or care about performance in these files much, and the situation may be similar in other editors.
  • Lazy load and/or async load as much as possible to make startup time fast.
  • Try to use native configuration facilities (conditionals, etc) for settings that differ between hosts. Resort to separate files only if necessary.
  • Prefer Python over Bash for complex scripts (general rule of thumb: more than 100 LOC).
  • Don't use Python for tools that should launch fast (less than 100ms). Prefer Go in this case. For example, i3-workspace-groups was written in Python, which causes some operations to have noticeable latency.
  • Code copied from an external source should have a comment with a URL to the source.
  • Directories that may contain python code should be named with underscores and not dashes, because python can't import from directories with underscores.
  • Executable files should be named using dashes to separate words, not underscores, i.e. my-tool and not my_tool. They should also have no file extension.
  • Importable files (Python or bash libraries, for example) should be named using underscores and have a file extension (.sh for shell scripts, .py for Python, etc.).

Vimscript

I roughly follow Google's style guide with the following additions:

  1. "Constants" should be named LIKE_THIS ("constants" is quoted because there aren't enforced constants in vim, this is only a convention).
  2. There's no need to define a addon-info.json for plugins since it's rarely used by plugins.
  3. There's no need to put commands, mappings, and autocommands in separate files, since I don't see any benefit in doing so.

Shell: Bash and Zsh

Many scripts in this repo are written in bash and zsh. In order to make the code easier to manage, I try to follow the Google Style Guide along with the following additions:

  1. Bash scripts start with a #!/usr/bin/env bash shebang.

  2. Functions that are private to the script and are not intended to be exported should have a leading underscore, for example _my_func. Functions that are exported from a script should never have a leading underscore, (i.e. my_func, not _my_func).

  3. printf '%s\n' "${var}" is preferred over echo "${var}" because the latter can interpret escape sequences (such as \b). However, printing string literals with not special chars is fine and shorter (echo 'message').

  4. All scripts should pass shellcheck with no warnings or errors.

  5. Single quotes are preferred over double quotes when substitution is not used.

  6. Functions should not use the function keyword and should generally use underscores to separate words, unless they're interactive shell functions that are expected to be extracted to their own executable, in which case they can use dashes.

  7. "Library scripts" (intended to be sourced from other scripts) should always use underscores in the filenames and end with a .sh filename extension, while "executable scripts" should always use dashes and without a filename extension.

  8. Files are structured as following:

    1. Shebang line (if the script is executable)
    2. Script documentation, separated from the shebang with an empty line
    3. Setting error handling options
    4. Setting ${REPO_ROOT} and other constants
    5. Sourcing other scripts
    6. Defining functions
    7. Defining a main function
    8. Calling main

    Example:

    #!/usr/bin/env bash
    #
    # This script does XYZ. Usage:
    #   my_script <arg> [opt_arg]
    
    # See https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_pipefail/
    set -o errexit -o errtrace -o nounset -o pipefail
    
    # shellcheck disable=SC2155
    readonly REPO_ROOT="$([[ ${CONFIG_GET_ROOT:-0} == 1 ]] && config-repo-root "${BASH_SOURCE[0]}" || echo "${HOME}")"
    readonly OTHER_CONST=3
    
    # shellcheck source=../../.my_scripts/lib/base.sh
    source -- "${REPO_ROOT}/.my_scripts/lib/base.sh"
    
    _private_func() {
      echo 'This is a private function'
    }
    
    main() {
      printf 'Called main with args: %s\n' "$*"
    }
    
    main "$@"

Note that old scripts may not conform to this style yet.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].