| ;; Put in dotspacemacs/user-config | |
| (defun my/use-eslint-from-node-modules () | |
| (let* ((root (locate-dominating-file | |
| (or (buffer-file-name) default-directory) | |
| (lambda (dir) (file-executable-p | |
| (expand-file-name "node_modules/.bin/eslint" | |
| dir))))) | |
| (eslint (and root | |
| (expand-file-name "node_modules/.bin/eslint" | |
| root)))) |
| `emacs --daemon` to run in the background. | |
| `emacsclient.emacs24 <filename/dirname>` to open in terminal | |
| NOTE: "M-m and SPC can be used interchangeably". | |
| * Undo - `C-/` | |
| * Redo - `C-?` | |
| * Change case: 1. Camel Case : `M-c` | |
| 2. Upper Case : `M-u` | |
| 3. Lower Case : `M-l` |
| Font=Powerline Consolas | |
| ForegroundColour=131,148,150 | |
| BackgroundColour=0,43,54 | |
| CursorColour=220,50,47 | |
| Black=7,54,66 | |
| BoldBlack=0,43,54 | |
| Red=220,50,47 | |
| BoldRed=203,75,22 | |
| Green=133,153,0 | |
| BoldGreen=88,110,117 |
Thanks to @seejee for making this for me!!!
The goal of this is to have an easily-scannable reference for the most common syntax idioms in C# and Rust so that programmers most comfortable with C# can quickly get through the syntax differences and feel like they could read and write basic Rust programs.
What do you think? Does this meet its goal? If not, why not?
Emacs packages, features, files, layers, extensions, auto-loading, require,
provide, use-package… All these terms getting you confused? Let’s clear up
a few things.
Emacs files contains code that can be evaluated. When evaluated, the functions, macros and modes defined in that file become available to the current Emacs session. Henceforth, this will be termed as loading a file.
One major problem is to ensure that all the correct files are loaded, and in the
| * root topic - TAB and S-TAB to toggle folding | |
| ** child topic | |
| child topic text | |
| *** leaf topic: | |
| some text blah | |
| blah | |
| blah | |
| *** another leaf topic: | |
| # test table - TAB to cycle through columns, M-e to move point to end of cell |
tl;dr: Avoid Box<T> in general.
Actually, this rule is so important that the Rust Pointer Guide explicitly says the same. Therefore without a further ado, you should avoid Box<T> except for these three cases:
When you absolutely need a trait object (Box<Trait>). But review carefully to see if it is indeed absolutely needed; you may try to generalize things too far, for example.
When you have a recursive data structure. This may be mandatory when you have an inherently recursive data (e.g. scene graph), but it may also be a sign of the premature optimization. Again, review carefully to see if you need to write a separate data structure yourself, and use the collection crate if possible.
| #!/bin/bash | |
| # Credits to: | |
| # - http://vstone.eu/reducing-vagrant-box-size/ | |
| # - https://github.com/mitchellh/vagrant/issues/343 | |
| apt -y purge ri | |
| apt -y purge installation-report landscape-common wireless-tools wpasupplicant ubuntu-serverguide | |
| apt -y purge python-dbus libnl1 python-smartpm python-twisted-core libiw30 | |
| apt -y purge python-twisted-bin libdbus-glib-1-2 python-pexpect python-pycurl python-serial python-gobject python-pam python-openssl libffi5 |
| If you have a huge repository (in size and in history) and want to add a subfolder | |
| to your project as a submodule you can follow this example to save time and space | |
| using git's shallow clone and shallow checkout feature. It is a bit more complicated | |
| in this example because I assume that you want your submodule to track a non-default | |
| branch, called `mybranch`, instead of the `master` branch. Things could probably get | |
| a lot simpler when using the default branch. After following the commands in these | |
| examples you can use `git submodule update` and `git submodule update --remote` as normal. |