IC设计中值得解决的小问题（一）

数字前端设计流程中，.lib后缀的文件通常是 Synopsys Liberty 文件。这是一种描述单元时序、功耗等参数的文本文件。平时难免需要用文本工具去查看其中的内容。而 Linux 环境中经常用的文本编辑器之一就是 Vim。

一直存在的一个小问题，就是用 Vim 打开.lib文件的时候，语法高亮不正常，所有的字符，包括关键字和非关键字，通通是红彤彤的大红色。

语法高亮不正常，影响大吗？

有一点，但说不上大。

有时候心烦了，就直接敲个:syn off关掉语法高亮。还有一个小问题就是此时 Vim 的整词搜索，*也不起作用。这个影响稍微大一点，因为要多敲几下键盘，或者动用鼠标了。

说来惭愧，这么个小问题中存在了好多年，起码目前记忆鲜活的、在 A 司的前前后后好几年一直是存在的。最近又到了频繁查看.lib文件的时候，心血来潮，仔细研究了一下。

在作者的环境中，用户自定义的文件类型设置

~/.vim/filetype.vim

包含有.lib的类型检测。

augroup filetypedetecct
  au! BufRead,BufNewFile *.lib  setfiletype lib
augroup END

也有前贤们制作的对应语法设置

~/.vim/syntax/lib.vim

但执行过程中并没有生效。为什么呢？

首先查看一下 Vim 启动的时候调用了哪些文件类型检测脚本。

:scriptnames

在列出的脚本中找到类似下面的行。

~/.vim/filetype.vim

/usr/vim82/filetype.vim

第一个就是用户自定义的文件类型设置，第二个是 Vim 自带的文件类型设置。这么看就有点思路了，可能的原因是第二个 Vim 自带的文件类型设置在后面，覆盖了前面用户自定义的设置。

那么打开第二个设置看看有没有什么线索，搜索lib，可以看到默认的类型是Cobol，这看起来是一种上古的编程语言，和 Synopsys Liberty 完全不搭界。

" Cobol
au BufNewFile,BufRead *.cbl,*.cob,*.lib setf cobol

那么怎么让 Vim 系统自带的文件类型设置失效呢？找 IT 管理员直接改这个文件也许是个办法，不过求人不如求己，再看下有没有其它不影响系统的办法。

在该设置文件的开头，可以看到这么几句（这个注释看起来很不耐烦）。

" Listen very carefully, I will say this only once
if exists("did_load_filetypes")
  finish
endif
let did_load_filetypes = 1

可以看出如果我们在进入这个设置文件之前，把did_load_filetypes设成1，就不会执行它了。

为了把影响减到最小，直接把这个系统设置文件的全部内容复制到用户自定义的文件类型设置文件中，然后把Cobol那一行的*.lib删掉。

这样执行完

~/.vim/filetype.vim

之后，.lib的文件类型就识别成我们想要的lib类型了，并且did_load_filetypes也被设成1了；那么执行到

/usr/vim82/filetype.vim

时，发现did_load_filetypes已经被设成1，就直接退出该设置脚本，也就不会把*.lib设置成Cobol类型了。

考虑到目前 Synopsys Liberty 类型文件的后缀花样繁多，可以用通配符设的更通用一些。

au! BufRead,BufNewFile *.lib,*.lib_ccs_tn* setfiletype lib

多年存在的小问题，花几分钟研究清楚搞定。看着清爽的语法高亮显示效果，不禁扪心自问，为什么不早早动手把它解决呢？