建议不要只看“源码”。
可以使用 git blame 和 commit message 搜索找到如下几个 commit：
github.com/codemirror/state/commit/76d8735feb5821848fa9af551eb39c0dd0ad60b9 Use 1e9 instead of 2e9 for big integers · codemirror/state@76d8735
github.com/codemirror/view/commit/b5aa501bab1675221553780cd071b93eedb387f2 Use 1e9 instead of 2e9 for big integers · codemirror/view@b5aa501
可见这个数以前是 2e9 。作者给出的理由只有一句话：
> Several engines apparently store only 31 bits in smallints
smallint 可能是指 SQL 里的那个，但是鉴于 CodeMirror 和 SQL 除了一个编辑支持之外就没啥关系，并且“engine”加上“several”和“store”指的应该是一个实现层级的东西而非 SQL 这种接口层级的。那个人猜测应该是指 JS 引擎里的 small integer 优化，这对于实现 Uniform Representation （
https://v2ex.com/t/632869#r_8401400 ）是必要的。
假设一个 32 位的 Uniform Representation ，其中一位用于区分 pointer 类型和 small integer 类型，用于存储 integer 的就只有 31 位，再加一个符号位的话一个 small integer 的绝对值最大就是 2^30 ，差不多就是 1e9 。
楼主给的 StackOverflow 链接中大多数的数字似乎是关于“某个编辑器在特定环境下可以打开某个大小的文件”的，和“某个编辑器理论上可以打开文件大小的最大值”关系甚微。也就一个 EmEditor 的数字“up to a 248 GB limit (or 2.1 billion lines)”算得上一个理论值，这个大概是 EmEditor 用了 signed 32-bit integer 存储行数。
顺便我觉得“开源”只开放“源码”是不完全的。很多信息都隐藏在 VCS history ，issue tracker 和 code review 的过程中。源码只是个成品，它本身很难回答“为什么”的问题。社区驱动的中大型开源项目的源码反而会比较易读，就是因为这些源码之外的信息比较丰富，并且更难出现类似本主题这样的代码质量问题。毕竟这种项目里面，你想改任何的代码，都需要以书面形式说服社区 a) 你为什么要改？ b) 你为什么要这么改？