I’ve kept my promise of shipping smaller updates to Marked 2 more frequently. Marked is now at 2.5.21, so here’s a rundown of what’s new in the last 5 updates.
First, a bunch of fixes. I’m fixing every day.
New support for hover preview of footnotes rendered by Pandoc instead of the built-in processors.
Improved support for Highland 2 and Fountain text. Marked can once again open Highland files natively and update automatically on save.
Improved support for MarsEdit, and Marked can now open MindNode files regardless of whether you save them in Single or Package format.
A new option that will really only pertain to coders: “Only syntax highlight when language is specified.” This mimics the behavior of some other platforms, and only applies to fenced code blocks. All indented code blocks will still get syntax highlighting. If you enable this option under Preferences->Style, a fenced code block with a(ny) language specified will get syntax highlighting, e.g.
If the opening fence doesn’t have alphanumeric characters after it (and no language is specified using Markdown Extra syntax), the code will be ignored when highlighting.
I also updated the internal MathJax library, and Leanpub syntax will now work in every document if it’s enabled (Preferences->Apps). Previously it was only rendered if the current document was “Book.txt”.
Please enjoy the latest updates with my regards. If you’re updating through the automatic updater (Marked->Check for Updates), read all the way through the release notes, it’ll be worth it. Trust me.
To get Marked 2, visit marked2app.com and grab the free trial! (Also available on Setapp and the Mac App Store).
I’ve added a few new shortcuts to my astounding1 collection of macOS keybindings. You can check them all out on the project page (and, if needed, figure out what the heck I’m talking about), but here’s what’s new.
First, a simple command that’s just for convenience: shift-space to move forward one character without inserting a space or deleting anything that’s selected. It’s exactly the same as hitting the right arrow key or pressing ⌃f. I just wanted the convenience of having it in a handier location when typing. You might hate it, especially if you often linger on the shift key when hitting space, because it will lead to unexpected behavior when you’re using one of the most ingrained keys in your muscle memory (the spacebar).
As a solution to the lingering shift, if you’re not already using your hyper key with the spacebar for something else, it might make a better option (setting the binding to
^@~$\040. Mine’s been the shortcut for Dash for long enough that it would take too much getting used to.
Second, some shortcuts for changing programmer-style casing in a string. These will only be useful for people who regularly want to convert from snake_case to camelCase or vice versa. I often find myself needing to do this outside of an editor with built-in case conversion, so I made a couple of quick shortcuts.
These are all multi-stroke, mostly because I’m running out of keys these days. Ctrl-Option-c starts them, then the second key chooses the function. The first one is snake_case to camelCase. If you place your caret (edit cursor) before the underscore in “snake_case” and hit
⌃⌥c, c, it will delete the underscore and capitalize the next character, giving you “snakeCase”. It deletes the character following the caret indiscriminately, so it also works with a hyphen, or a space, or possibly a character you didn’t actually mean to delete (if your caret is in the wrong place). It just replaces the need to delete, select, and then re-type the first character as uppercase.
The second one converts to snake_case by an inverse method, inserting an underscore and lowercasing the next character. Put the caret between the “lC” in “camelCase” and hit
⌃⌥c, s and you’ll get “camel_case”.
That’s it. As always the project page and GitHub repo are updated with the new bindings.
I just got my first Synology. My Drobo crashed, and it was the second one in 5 years. Keeping a 20 TB backup in the cloud isn’t really feasible for me, so a local RAID is supposed to be the backup for less-essential data. So losing another Drobo meant potentially losing a bunch of data I’d rather keep around.
Here’s the really frustrating part of the story: after going through Drobo customer service, they diagnosed it as a chassis issue (versus a power supply issue) and offered to fix it for $375… or I could buy a new Drobo. The thing is, I’d lost trust in Drobo. Everybody has been telling me to get a Synology, so I figured it was time to invest in the switchover. I ordered a Synology DS418 (I know, I know, I now realize I should have gotten the 418play), along with 4 3.5” drives and a Drobo 5 bay to use to recover my data. The Drobo was returned and refunded as soon as I’d recovered my data. Here’s what really ticked me off, though: out of curiosity, I took the power supply from the new Drobo and plugged it into my old one. It booted perfectly and has been running fine since. All I really needed was a $35 power adapter. But, like I said, my trust level was too low and I was happy to be switching anyway.
I’m loving the Synology every bit as much as everybody said I would. A true NAS with an onboard CPU that can run a host of applications from media servers to DNS and VPN servers. Wow.
One of first things I discovered while going through all the features and packages available on the Synology was that it can run a Git server. I had no idea this was even going to be an option, so obviously I skipped everything else and dug right into getting that working. There were a few caveats to getting a truly useful system running, so I’m documenting them here.
You need SSH enabled to install the Git server. To enable SSH on your Synology, open Control Panel and go to Terminal & SNMP, then check the box for Enable SSH service.
To make using git pleasurable, you need to make sure you don’t have to type a password every time you push or pull. This is accomplished via SSH key pairs. For the purpose of the next few instructions, we’re going to pretend you don’t know how to do that, so if you do, bear with me.
Doing the following went smoothly for the root user, but I wanted to use a non-root user to administer the Git repositories. I recommend this for security reasons, so these instructions are written for a non-root user and include the steps needed to make that work.
Substitute your admin user name anywhere it says “USERNAME,” and the name of your Synology server wherever it says “SYNOLOGY_NAME.local”.
On your local machine, start by creating a pair of SSH keys. Unless you know what you’re doing and want something different, you can just hit return at every prompt.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
The key's randomart image is:
+--[ RSA 2048]----+
| .oo. |
| . o.E |
| + . o |
| . = = . |
| = S = . |
| o + = + |
| . o + o . |
| . o |
Both public and private keys are now located in
~/.ssh. The public key is
id_rsa.pub, and the private key is just
$ cd ~/.ssh
The public key is the one that gets copied to remote servers, and then compared against the private key (that’s only on your machine) at login.
Copy public key to server
You can do this manually, but there’s a great tool called
ssh-copy-id that can make it a breeze.
Option 1: Automatic way
Install ssh-copy-id if you don’t have it (
brew install ssh-copy-id)
Option 2: Manual, in one step…
cat ~/.ssh/id_rsa.pub | ssh USERNAME@SYNOLOGY_NAME.local "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 644 .ssh/authorized_keys"
Option 3: ALL THE STEPS
I offer this as a breakdown of option 2, just so you can see what’s happening.
cating the key over an ssh command, we’ll use scp to copy it to our home directory on the server:
$ scp ~/.ssh/id_rsa.pub USERNAME@SYNOLOGY_NAME.local:~/
ssh into the synology, logging in with your password:
$ ssh USERNAME@SYNOLOGY_NAME.local
Add the public key to ~/.ssh/authorized_keys (setting permissions as we go)
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 644 ~/.ssh/authorized_keys
To be clear, the directory
~/.ssh must have its permissions set to 700, and the
authorized_keys file must have permissions of 644.
Ensure home directory ownership and permissions
This is the important step that finally got non-root keyless login working on my Synology. While logged into the Synology via ssh:
$ cd /var/services/homes/
$ chown USERNAME USERNAME
$ chmod 755 USERNAME
Subbing in your actual user name for “USERNAME,” of course. We’re just making sure we’re the owner of our own directory, then setting the permissions on it to 755 (
Test it out
At this point, if all went well, we should be able to ssh into the server without a password prompt:
$ ssh USERNAME@SYNOLOGY_NAME.local
Add a shortcut (optional)
If you’re planning to ssh into your Synology often (or just want to shorten your Git remote addreses), add a shortcut to by editing
~/.ssh/config on your local machine.
Add the following lines, modifying for your setup:
If you want to be able to use this from outside networks, use whatever DDNS/port forwarding setup you’re using for remote access instead of the
And now you can just run:
$ ssh syn
And when you set up your git repo remote, it can be something like:
Install the Git server on Synology
Package Center -> Git Server
Ensure that your user has access under Git Server->Advanced Settings.
Now you have fast access to your Synology’s operating system, and a local git server to boot. I’ve found mine to be ridiculously fast compared to using offsite remote repos. Just edit an existing
git remote add [origin] ssh://syn/volume1/homes/USERNAME/repos/myrepo.git.
I wrote this up for MacStories this morning, so I won’t go into full detail, but AeroPress Timer has updated to version 3. It’s an app for timing out recipes for the Aerobie AeroPress, and this version adds the one feature I’ve most wanted from this awesome little iPhone utility: custom recipes.
It’s always had a vast selection of recipes to choose from, but being able to add my own was always my number one request. I added one for my Fellow Prismo while I was testing the beta and I’m a very contented user.
Read more at MacStories.