| * 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 |
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
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?
| 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 |
| `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` |
| ;; 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)))) |
| # You could also do this in emacs probably, but this is easier. | |
| export RUST_SRC_PATH=/path/to/rust/checkout/src | |
| export PATH="$PATH:/path/to/racer/binary/" |
Porting code from Python 2 to Python 3 can be a daunting task. Tools like Futureize or Modernize can do most of the mechanical work for you, and Pylint can find obvious problems with code that's meant to be 2and3 compatible. You should absolutely be using these tools as they identify the lion's share of compatibility problems. Thanks to this work, it's really never been easier to port a large codebase to Python 3.
Even with these tools, however, porting code in a way that ensures identical behavior in Python 2 and Python 3 is tough. Python is a highly dynamic language and there is a huge breadth of changes between Python 2 and Python 3. Also, while we'd all love to work in code bases with 100% unit test coverage, the reality is unfortunately often very different. Given this, it's hard if not impossible for a static analysis tool t
| solution "SDL2_Test" | |
| configurations { "debug", "release" } | |
| location("make/" .. os.get() .. "/") | |
| targetdir("bin/" .. os.get() .. "/%{cfg.buildcfg}/") | |
| objdir("obj/" .. os.get() .. "/%{cfg.buildcfg}/") | |
| project "sdl2_test" | |
| kind "WindowedApp" | |
| language "C" | |
| ; ___ _ __ ___ __ ___ | |
| ; / __|_ _ __ _| |_____ / /| __|/ \_ ) | |
| ; \__ \ ' \/ _` | / / -_) _ \__ \ () / / | |
| ; |___/_||_\__,_|_\_\___\___/___/\__/___| | |
| ; An annotated version of the snake example from Nick Morgan's 6502 assembly tutorial | |
| ; on http://skilldrick.github.io/easy6502/ that I created as an exercise for myself | |
| ; to learn a little bit about assembly. I **think** I understood everything, but I may | |
| ; also be completely wrong :-) |
