| # Reconstructed via infocmp from file: /usr/share/terminfo/t/tmux-256color | |
| tmux-256color|tmux with 256 colors, | |
| OTbs, OTpt, am, hs, km, mir, msgr, xenl, AX, G0, | |
| colors#256, cols#80, it#8, lines#24, pairs#32767, U8#1, | |
| acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, | |
| bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, | |
| clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=^M, | |
| csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, | |
| cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C, | |
| cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM, |
macOS has ncurses version 5.7 which doesn't ship the terminfo description for tmux. There're two ways that can help you to solve this problem.
Instead of tmux-256color you can use screen-256color, place this command into your ~/.tmux.conf.
set-option -g default-terminal "screen-256color"
macOS has ncurses version 5.7 which does not ship the terminfo description for tmux. There're two ways that can help you to solve this problem.
Instead of tmux-256color, use screen-256color which comes with system. Place this command into ~/.tmux.conf or ~/.config/tmux/tmux.conf(for version 3.1 and later):
GitHub uses the following CSS font stack to display code:
font-family: SFMono-Regular, Consolas, Liberation Mono, Menlo, Courier, monospace;Chrome will use SFMono-Regular when that font is installed locally, but Firefox will not. Workaround: Add the following CSS to your Firefox profile's userContent.css file:
@font-face {
dist/main.css grows by 400K!/\.wp-/, /\.post-type/, /myfancylightbox/.../resource/assets/styles!/node_modules/**/* only?purgecss start ignore, strategically placed, to the rescue!
| /* eslint-env node */ | |
| /* eslint-disable no-console, dot-notation */ | |
| const fse = require('fs-extra'); | |
| const readline = require('readline'); | |
| // const platform = 'mw_less'; | |
| // const platform = 'mw_scss'; | |
| const platform = 'cosmos'; |
| <?php | |
| class comments_reloaded extends \Walker_Comment { | |
| var $tree_type = 'comment'; | |
| var $db_fields = array( | |
| 'parent' => 'comment_parent', | |
| 'id' => 'comment_ID' | |
| ); | |
| // start_lvl – Wrapper for child comments list, starts the list before the elements are added. |
| // first run: | |
| // yarn add glob-all purgecss-webpack-plugin --dev | |
| /* | |
| config/webpack/environment.js | |
| PurgeCSS configuration for Rails 5 + Webpacker + Tailwind CSS + Vue.js | |
| Optionally, put this in production.js if you only want this to apply to production. | |
| For example, your app is large and you want to optimize dev compilation speed. | |
| */ |
| #change de URL of the repo | |
| repo=<repo_url.git> | |
| tools=(trellis bedrock sage) #tool from roots.io | |
| subtrees=(trellis site site/web/app/themes/sage) #folder structure for the tools | |
| #init repo | |
| git init | |
| git remote add origin ${repo} | |
| touch .gitignore |
This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.
For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai