笔记

  • 因此 clean/smudge 没有作用。

    本身 github for mac 也没有提供编辑 .gitattributes 的地方。

    不确定是否 github for mac 压根不考虑 .gitattributes 文件?

    奇怪的是 github client 其实加入了 git-hawser 作为全局 filter。

    另外,测了一下 sourcetree 是支持 filter 的。

  • @supports (text-shadow: 0 0 .3em gray) { 
        h1 {
            color: transparent;
            text-shadow: 0 0 .3em gray; 
        }
    }

    可编译为:

    :root[data-cssrules-1] h1 {
      ...
    }
    cssSupports('text-shadow: 0 0 .3em gray')
    
    let id = 0
    function cssSupports(cssDecl) {
      let e = document.createElement('div')
      e.styl
  • https://www.zhihu.com/question/43728074/answer/96470605

    html规范里的demo:
    https://jsfiddle.net/4c63728k/

    FF/Edge: ONE TWO THREE FOUR
    Chrome/Safari: ONE THREE TWO FOUR

  • 王垠抨击过缩进语法。其中提到缩进很容易在编辑的时候弄坏,比如不小心(猫跳到键盘上?)输入或删去一些空格。而传统语法没有这个问题是因为恰好输入或删除成对的符号(花括号对或begin/end对)的概率小多了。比较来说,缩进是单点变更就会产生语义差异,因而危险。

    需要承认这是一个合理的责难。其实可以和 rm -rf / temp 的空格惨案相类比。紧凑的语法往往造成这种问题。

    不过实践上似乎并未看到或听到很多实际的惨案,即使coffee、yaml已经相当普及。

    有一些方法来克服这一问题:

    • 受控的编辑环境
    • 语法冗余结构
      • 引入类似花括号或begin/end的要素
      • 引入类似/的terminator
  • 大概去年这个时候 Swift 语言把 half-open range operator .. 改为了 ..<,引起了一些讨论。

    实际上..<运算符的最早先例是 Groovy 语言。

    而Groovy在初创之时,使用的是和 Ruby 一样的 range operator(.....),在2005年4月左右将 ... 改为了 ..<

    而最早提出以 ..< 符号作为 exclusive range 运算符的,其实正是本人。这10年前的邮件记录可在此查看:http://marc.info/?l=groovy-dev&m=113684773506831

    其实在