Alfred

背景在 vim 中应用 fzf.vim 插件能够进行不便的搜寻文件, 源码TAG, GIT 记录等, 最近抽空看了下 BTags 命令在 c, c++ 文件中, 无奈显示头文件中的函数申明 标签问题. 比方在头文件中有如下一个函数申明, 应用 BTags 命令是无奈显示出这个函数原型的. /*=========================================================================函 数 名： IMGVideoAlgOpen功 能： 算法初始化算法实现： 无参 数： pvHandle 算法句柄[in]emIMGAlgType 算法类型[in]pvOpen 初始化构造体指针[in]返 回 值： 返回函数调用信息===========================================================================*/int IMGVideoAlgOpen(void** pvHandle, EMIMGAlgType emIMGAlgType, void* pvOpen);剖析通过代码定位, 在 ~/.vim/bundle/fzf.vim/autoload/fzf/vim.vim 文件中, 能够看到 BTags 是通过 ctags 生成的标签. " query, [tag commands], [spec (dict)], [fullscreen (bool)]function! fzf#vim#buffer_tags(query, ...) ... let sort = has('unix') && !has('win32unix') && executable('sort') ? '| sort -s -k 5' : '' let tag_cmds = (len(args) > 1 && type(args[0]) != type({})) ? remove(args, 0) : [ \ printf('ctags -f - --sort=yes --excmd=number --language-force=%s %s 2> %s %s', get({ 'cpp': 'c++' }, &filetype, &filetype), escaped, null, sort), \ printf('ctags -f - --sort=yes --excmd=number %s 2> %s %s', escaped, null, sort)] ...endfunction通过在命令行执行 ctags 命令, 的确是没有生成函数申明的标签. ...

背景最近又迷恋上了写博客，尤其是前一段时间很想要写点东西分享一些软件的使用感想。但当写完文章想要发表时就会碰到一个问题：由于我是现在本机的编辑器中用Markdown写好了全文的内容，再发表到各个平台（曾经是GitHub Pages搭建的博客，后来又多了简书，现在再加上SegmentFault）上的，因此文章里的图片都是引用在本地磁盘上的文件路径的。这么一来，如果直接将文章源码粘贴到博客平台上——比如粘贴到SegmentFault中，那么这些本地的图片链接就无法在发布后的文章中正常显示了。如果一开始就在SegmentFault中写作也会遇到问题。SegmentFault上的文章插入图片后，并不是像普通的Markdown源码那般插入一条形式的标记的，而是像下图这样显然，这样的文章源码复制到其它平台（GitHub Pages、简书）去发布的话，必然是需要针对其中的图片标记修改一番的——比刚开始的方法或许要更麻烦。看来要解决这个图片链接在不同平台间共用的问题，必须有一处纯粹的用于存放图片文件的地方——也就是大家常说的图床了。刚开始我也放狗搜了一下，看看别人的推荐，印象中得到的答复不外乎是又○云、七○云、新○微博，以及sm.ms等。但它们要么需要注册并且实名认证，要么不纯粹，要么让人觉得随时会丢失。某个晚上忽然想到，GitHub不就是一个很好的图床么？！在GitHub上建一个仓库专门存放博客中的图片，不仅免费、完全受自己管理，而且自带CDN加速，并且我的读者群（如果真的有这么一个群体的话）也应当可以畅通地访问GitHub。放图片的仓库虽然有了，但用起来还不是很便利——因为作为写作素材的图片在我的电脑上是存放在一个单独的、非GitHub仓库的目录下的，所以如果要丢到图床上，就需要先将文件复制过去，然后执行git的add、commit、push三部曲，最后还要到GitHub上复制这张新图片的“raw”地址。这个过程很机械化，完全可以用一个Alfred的Workflow来代劳。编写Workflow编写Workflow就像编写Common Lisp中的宏一样，总是从它们的用法入手的。在我的设想中，这个Workflow的使用方式应当是：首先，按下快捷键调出Alfred的输入框，输入关键字（在我这里就叫做upload）来唤起这个Workflow；然后，输入要上传的图片文件的绝对路径并按下回车，开始在后台处理最后，上传完毕后，弹出通知来告诉我整个Workflow的概貌其实很简单第二个节点所调用的External Script是长这样子的#!/bin/bash# 将磁盘文件上传到GitHubpath=${1}pictures_dir="${HOME}/Documents/Projects/riverbed/pictures"cp “${path}” “${pictures_dir}“echo ‘文件复制完毕’file=$(basename “${path}")cd “${pictures_dir}“git add “${file}“git commit -m ‘上传一张图片’git push -u origin masterecho ‘文件已提交到GitHub’/usr/local/bin/node -e “console.log(encodeURI(‘https://raw.githubusercontent.com/Liutos/riverbed/master/pictures/${file}'));" | tr -d ‘\n’ | pbcopy获取文件的绝对路径其实很简单，在Finder中选中文件后，按下Command+Option+C即可这里使用basename命令获取文件名。并且，为了避免git打开文本编辑器要求输入commit message，向git-commit命令传递了-m选项。因为文件名含有非ASCII的字符（毕竟会有中文），需要做一次URL编码，因此用了node来做转换。在Node.js代码中用console.log输出编码后的图片URL，结尾会有一个换行符，所以用tr将其去掉。最后，输出的内容重定向给pbcopy，就将上传后的图片URL复制到剪贴板中了。如果此时正在编辑文章，便可以粘贴这个图片的链接到源码中。Alfred也提供Copy to Clipboard，用于将Workflow中上一个节点的输出复制到剪贴板中。之所以不使用，其实是因为刚开始的时候就是用的Alfred的Copy to Clipboard，结果发现git运行过程中的输出也被Alfred接收了，跟图片URL一起混进了剪贴板中。所以最后改为直接调用pbcopy。全文完。

Alfred是一款所谓的“生产力工具”，可以理解为就是帮助Mac用户提高日常事务的处理效率的工具，在我还没有入手MBP的时候就已经（在知乎上）听闻了这款软件的大名了。实际使用了之后发现确实可以提升一些事情的处理效率，是一款值得身为程序员的读者朋友使用的应用。接下来我会举一些例子来说明一下，希望可以传达到我的感受。献上我的Alfred使用统计Alfred的Clipboard剪贴板真是一个再常用不过的功能了，我想所有的读者朋友应该都使用过复制&粘贴的功能——不管是在Windows上面的Ctrl-c Ctrl-v也好，还是在Mac上面的Command-c Command-v也罢。Alfred的Clipboard功能可以认为是一个强化版的剪贴板，它可以通过快捷键（在我的系统上设置为了Command-p）快速唤出并且支持搜索（虽然很遗憾图片没办法搜索）当需要在两个应用间复制粘贴多段内容的时候，Clipboard就派上用场了。只需要先把需要的每一段内容在一个应用中分别复制一次，打开另一个应用后唤出Clipboard，便可以把刚才复制的内容逐个粘贴进来。每当我在一些地方看到有趣的图片想要分享给微信或者QQ的朋友时，也是打开微信或者QQ后进入Alfred的Clipboard浏览——打开Clipboard后，敲入“Image”，便可以只查看记录在剪贴板中的图片了，并且还可以在发送前预览Alfred的SnippetsSnippets算是我近期才挖掘到并开始重度使用的功能，用一句话概括，就是“长话短说”。在Snippets中可以新建一个较短的关键字来代替一串较长的输入，例如我就分别用了gcd、gct，以及gmd来代替切换到develop分支、切换到test分支，以及合并develop分支这三条常用的Git操作命令之后既可以通过快捷键唤出Snippets面板的方式来输入短语，也可以直接在短语定义时勾选【Auto expandsion allowed】来做到输入短语后自动展开为完整的内容。下图演示的是输入gcd后自动展开为完整的命令我现在已经积累了很多的短语了，不仅提高了输入的速度，也降低了重复输入这些内容的出错率，实在是居家旅行coding必备。Alfred的Workflow购买Alfred的Powerpack后就可以开启Workflow的功能了，实际上，在我真正开始用Alfred之前（还在用着Windows的时候），对Alfred的了解基本上局限于“它拥有一个很强大的叫做Workflow的功能”这样，可以说，让Alfred如此闻名遐迩的就是它的Workflow特性吧——不过后来我才知道原来Mac自带一个叫做Automator的类似的功能。刚开始接触Workflow的时候，我也沉迷于在网上搜罗别人写好的来用，慢慢地才发现这些其他人经常（在知乎的答案里）列举到的Workflow，其实并不适合我。有一两个觉得眼前一亮的，在使用了一两次之后也就不怎么用了。现在，我自己写了一些Workflow，倒是显著地提升了我的开发过程。比较合适作为例子的是我写的三个用于处理时间的Workflow。一个是用于将日期时间字符串转换为UNIX时间戳（毫秒单位）的Workflow，名为gt——取的是get time之意。使用起来的效果大致如下这个Workflow最终会把结果复制到剪贴板中，便于在其它应用中使用。由于工作内容的缘故，我常常会需要获取某一个时候的UNIX时间戳（毫秒单位）。在有这个Workflow之前，我都是打开iTerm运行node，然后敲入new Date(‘2018-11-15 00:00:00’).getTime();这般的代码来得到结果的，不仅要在不同的应用间切换来切换去的，而且还需要重复地敲入new、Date，以及getTime等字眼，实在是一件很低效的事情。使用了gt之后，感觉幸福感也提高了很多。另一个Workflow名为wt——取的是what time之意，它的作用跟gt相反，是将毫秒数转换为可读的日期时间字符串，效果如下最后一个Workflow名为int——即I need time，它可以提供特定的一些时刻的时间戳，例如【今天零点】这样的特定的时刻。这三个Workflow的入口节点都是一个Script Filter，int的使用效果如下Alfred的Workflow还可以做很多的事情。它是一个入口，很适合用于不需要肉眼查看含有大段文字的结果的交互场景，例如对字符串做编码转换、计算字符串的摘要、通过AppleScript调起微信联系人，以及控制音量等等，只要好好利用，就可以提升平时的使用效率。程序员朋友们，不妨一起来发挥自己的创造力吧。