善用佳软

第一篇 群雄并起——文本编辑器的武林大会

[返回 打造全能的文本编辑器序列文章] 文本文件，是很重要的一种文件类型，它有很多优势，最重要的是它很小。在日常的学习与工作中，每个人都会或多或少要接触文本文件，这样，对文本文件进行编辑就是很平常的事情了。现在文本编辑器可谓种类繁多，鱼龙混杂。各个编辑器有它自己的优势，对编辑器的喜爱也因人而异。很普通的用户，或者说初级用户，可能用到的文本编辑器会是Windows自带的Notepad（记事本）。就我个人而言，曾经有段时间也只是使用notepad。然而对于一个程序员，notepad是远远不能满足要求的。大部分时候，也许程序员们使用的会是IDE，然而，IDE一般都比较庞大，占用资源也比较多。如果只是写一些简单的或者只是看看一些代码，似乎没有必要启动一个庞大的IDE，而notepad又没法满足要求，这个时候拥有一个好用、强大的文本编辑器就很重要了——这些文本编辑器一般都支持语法高亮等功能，方便阅读程序与程序编写。

记得在初学JAVA程序设计时，看网上的视频，一上来不会是教你使用Eclipse之类的IDE，而是使用UtralEdit、Editplus等之类的文本编辑器。使用这些编辑器作为入门有很多好处：所有代码基本都是手工输入，对于初学很有好处，而不是利用IDE的代码提示等完成的，初学者更容易理解来龙去脉，更好的入门；这些编辑器一般都比较轻量级，对于入门级教程，没有必要使用庞大的IDE，使用普通文本编辑器就可以胜任了……

使用过Unix/Linux的用户，肯定都知道vi编辑器，似乎vi之于Unix/Linux如同notepad之于Windows。然而Vi与notepad的功能却超越甚远，更不用说Vim了。

在武林大会开始之前，首先介绍一下“当世英雄人物”：

1 武林泰斗——Vi/Vim、Emacs、jEdit（免费、开源、所有平台）

武林中的泰山北斗，人人敬仰，流传于世，地位无人撼动。Vi/Vim、Emacs就是文本编辑器中的泰山北斗。

Vim：前段时间花了不少时间系统地学习了Vim，功能确实十分强大，而且有众多的插件可使用。然而，Vi/Vim的门槛比较高，很多人一开始使用会很不习惯，继而放弃使用。我在使用时也有这种感觉，然而没过多久就喜欢上了它的一些操作方式，比如：移动光标的方式，简洁的界面，经典的黑底白字等。现在我用的浏览器Firefox、Chrome都定义移动光标的快捷方式为Vim的方式，这样手不用移开键盘就很顺手地在屏幕上跳动，很是方便；很多软件，我也尽量使用快捷方式操作，隐藏菜单栏与工具栏，编程黑底白字等。由于功能强大，学习难度也大，需要长期实践才能熟练掌握，才能用起来很爽。用很多使用Vim的人的话说：Notepad等编辑器根本没法用。然而作为一个程序员，很有必要至少掌握Vi/Vim的一些基本操作。如果你决定深入地学习Vi/Vim，在网上有很多相关的学习资料，而且它的官方帮助文档很全、很详细，是学习的好资料。另外，在此推荐几篇优秀的博文供学习：善用佳软之《普通人的编辑利器——Vim》、Dieken之《程序员的编辑器——Vim》。

Emacs：对于Emacs，入门难度似乎更高，网上说不少高级程序员很喜爱。我没有接触，一来，不想花大量时间去学，没那么多精力；二来，现用的文本编辑器已经能够满足基本工作需要了。有兴趣的朋友可以在网上收集资料学习。推荐一篇优秀博文：王垠之《Emacs是一种信仰！世界最强编辑器介绍》。

jEdit：也许很多人听说过甚至使用过Vi/Vim、Emacs，但是对于jEdit却知之甚少。这段时间有使用过jEdit，开始以为它和EditPlus等是一个数量级的，用了之后才发现，该编辑器十分的灵活，功能当然就相当强大，个人觉得与Vim等是一个数量级的。因而我将其归为“武林泰斗”。jEdit最大的优势是可以通过JAVA语言编写插件。现在已经有众多jEdit插件可以使用（主页：http://www.jedit.org）。

2 武学宗师——UltraEdit、Editplus、TextPad、EmEditor等（共享、Windows）

一代宗师，深受特定领域人的爱戴和敬仰。

这些软件有一个共同特点：共享软件，有一个试用期，过后需要支付一定的费用。这些软件功能也比较强大，可以代替Notepad，不过由于是共享软件，使用有限制。当然，网上有很多破解的。具体哪一个好，应该说是各有优劣。似乎使用UltraEdit的人比较多，它的确是一款十分优秀的编辑器。

对于EditPlus与EmEditor是两款很好的软件，Polaris现在就是两者结合者使用。

注意，这些软件都只能在Windows下使用。

3 普通高手——Notepad++、Notepad2等（开源免费，可替代Notepad）

虽然不如泰山北斗、一代宗师那样闻名千里，然而实力却也不差，可称之为高手，一般人无法与之较量。

这些软件入门低，但功能强，十分适合那些不想使用记事本的初级用户。它们是记事本(Notepad)很好的替代品。

当然还有很多来参加武林大会的人物，不过由于他们实在太一般，来一般也只是捧场、凑热闹而已，在此不一一列举。

4. 不是结论的结论

就像武林界没有绝对的高手，文本编辑器一样没有最好的，只有最适合的。Emacs很强大，可是对一个很普通的用户，平常只是写写日记之类的，对电脑知识了解也不多，学习Emacs是不可能的。所以，适合每个人的编辑器可能不一样，我们应该选择一款自己喜欢的、使用起来很顺手的编辑器使用，以求达到最高效率。我的建议是：

（1）普通初级用户，觉得Notepad太一般，不能满足要求，也讨厌其界面的，可以选择使用Notepad++，Notepad2等，Polaris强烈建议使用EmEditor，至于原因，后续文章会给出；

（2）一般程序员，建议使用EditPlus、EmEditor、UtralEdit等。
如果你愿意学习，可以深入学习jEdit、Vim甚至Emacs；
如果你是一个JAVA程序员，愿意学习，推荐使用jEdit，因为它的定位就是：Programmer’s Text Editor，而且有很多插件可供使用，只要你愿意，甚至可以配置成类似Eclipse那样强大的IDE。
对于C/C++程序员，jEdit的支持也很好，不过如果愿意学习，推荐使用Vim，网上众多关于配置Vim开发环境的文章大多都是针对C/C++语言的。
如果你是一个程序员，一般人应该都会使用Eclipse之类的IDE，不过这样的IDE太庞大，很耗费资源。
如果只是些一些测试性的代码或阅读一般性的代码，还是建议用一般的文本编辑器，它们小巧且功能强大；
如果你不愿意配置，不想学那么多，在此强烈推荐UltraEdit、EditPlus和EmEditor，它们各有优劣，在后续文章中，Polaris会详细对比说明。

众多文本编辑器的比较可以参看维基百科关于《文本编辑器的比较》。另外，有兴趣的朋友可以把众多的软件下下来试试，浏览一下这些软件的样子，并选择一两款作为自己长期使用的编辑器。

polaris

,

《 “第一篇 群雄并起——文本编辑器的武林大会” 》 有 197 条评论

  8. 建议作者写得严谨一点，说这个话题本来就容易引起口水，特别是众大的vim和emacs党，一争起来没完没了。像上面把vim和emacs一起写，但只写emacs开源，好像vim不开源似的。

        • 尽力吧。没什么把握的我尽量不写，写的时候也会注意点语气。这些文章在我的博客(javaeye,51cto)上，很少有人发表评论。然后xbeta看到了，建议我发到这个上面来。才发上了来没多久，这么多评论，挺有压力。我会努力写好来。

  9. 笔者是不是连wikipedia都不看的？ EditPad Lite/Pro 都果断忽视 ，绿色，打开一个500M文件只需要一秒钟，完整支持正则表达式。跟它比 ultraedit之流算个毛线啊。

    • 可能CG行业的用户稍多。

      一些优秀的软件诸如DFusion、XSI等捆绑/内嵌SciTE作为script编辑器，客观上起到了推广作用。

    • Scite功能挺强大的,就是定义起来不方便.它的参数提示也很棒…
      可是.个人写起来不是很方便啊..lua脚本来控制缩进.这个还要去学lua的写法…-_-…
      所以感觉还是用现成的省事儿..比如ahk的脚本编辑有现成的语法高亮和提示..我就用scite的.

      • 很多语言的语法高亮和其他设置都已经有现成的文件了.设置我改建也算方便啦,都在属性文件.我现在使用有点问题的是,ahk的语法高亮和别的功能是使用单独的lexer,集成不到别的SciTE中,for ahk的SciTE中又不包含其他文件的属性.这样写多种脚本需要多个编辑器,很不方便.(AHK程序中包含的SciTE语法高亮使用asm的lexer,看的不习惯.)

    • 我从GR点进来就是想留言，是不是SciTE没人用的，呵呵，当初我拿到它的时候花了七个小时搞配置，但从此再也不用配置了，它的语法api简直是太酷了，用来写程序一点问题都没有

  11. AkelPad 也很好用啊, 同样是轻量级软件, 打开大文件速度快, 可替代系统记事本. 特点是类似火狐, 软件本身功能不多, 但是可以通过插件来扩展和定制功能. 还有一个优点是软件本身是绿色的并且有外置的自动更新程序可以同时更新软件和插件.

  13. 我是初学者
    暂时在用EmEditor
    但总觉得程序代码写起来不大顺心
    (文本和网页还可以)
    IDE太大了实在不想装…
    期待楼主更多的介绍

  17. 没有用过Notepad++的人才会认为只是普通高手级别，我是程序员，除了IDE，用的最多的就是notepad++，你用了才知道有多强大。至少是宗师级别的。

    • 确实，以前也用emeditor，后来收费了，就转向notepad++了。
      研究了一星期，现在玩转了，确实很好用。
      notepad++配合NppExec插件，轻松玩转任何程序。
      直接F5，任何文件都可以直接执行或编译执行，当然了，需要自己写bat…

    • Notepad++有用过，是优秀的软件。说实话，程序员更多的时候用的会是IDE（当然不排除少数）。我用文本编辑器一方面是用于查看一些代码或写一些测试性代码；另一方面，也是主要方面，是用于写Text文件（比如Blog），很少使用Word写，Notepad在这方面有些更能满足不了我的需求（也许有而是我没有发现）。这一序列更多的是面向普通用户。

    • notepad++宏命令貌似是不能编辑吧..
      emeditor中可编辑还支持;vbs和js….
      感觉很方便的..

      不过写程序还是用IDE比较好.尤其是java用IntelliJ IDEA实在是舒服啊..

    • 我也是程序员，UltraEdit、Editplus、TextPad、EmEditor也都用过，最终还是选择了Notepad++，免费开源，功能强大，界面也很干净，用起来很舒服，很多时候用它编写查看代码要比IDE方便。它早期的版本存在一些问题，比如Ansi编码下半个汉字和中文搜索问题，CSS语法高亮遇中文崩溃的问题，某些插件引起cpu占用高的问题等。不过最近的更新已经把这些问题都解决了，现在感觉很好用。它最大的不足可能就是打开大文件时比较慢，不过还好写代码一般用不到太大的文件。

      • 既然是程序员，要用当然用最好用的，虽然Notepad++用着不错，我也有同事在用，主要是不想学习VIM什么的，都是用一些简单功用，经常坐惯了慢车，怎么会知道高铁，反正摇摇晃晃也能到终点，建议换个新的试试，体验一把高效的感觉。

        • 我尝试过VIM，不过放弃了。我认为选择软件不一定要用最好的，而是要用最合适的。VIM可以说是功能强大，但是绝对谈不上好用，它的好用是建立在熟练操作的基础上的，而达到熟练操作的水平是需要时间和精力成本的。这个成本值得付出吗？不同的人会有不同的答案。在实际工作当中，和思考所付出的时间相比，操作上提高的那一点效率是微不足道的。我选择了N++，是因为它可以满足我的需求，否则我自然会去寻找和学习功能更强大的软件。每个人对软件都有不同的需求，没有必要都去追求功能最强大的软件。

  18. 其实大家都各有所好，各个软件也各有各的长处。有的需要长期的使用才能够发现和体会。
    相比言语犀利的嘴仗，还是更想看到更多更深入的心得教程，也可以帮助大家学到更多的东西。

    • 完全同意。没有最好，只有更好。呵呵。最适合、最顺手的才是最好的。这一序列只是我个人的一些使用心得，到底使用哪款，完全大家自己的爱好或习惯决定。

    • 此言深获我心，大家理应摒弃门户之见，共襄盛举才是。
      尺短寸长，在所难免，徒负意气之争无异于画地为牢，无裨大局。

    • 高亮显示方面目前还不行，不过作者提到将来会增强的。目前可以使用10版本的zen-coding snippets插件，ctrl+[ 就可以在相应标签间跳转，ctrl+shift+D就可以选中整个标签里的内容。np++虽然能够高亮显示，却反而没法这样操作。
      我不喜欢np++在于它把所有的东西都写入了源代码中，而Em的所有功能都是可配置的。比如np++也许能够高亮显示html的匹配标签，但是如果我想高亮bbcode如[bold][/bold]就是做不到的，除非自己改源程序然后编译，这就不能称为一个“通用”编辑器，通用编辑器应该是不论语言怎么变化，都可以通过界面、配置文件、或者脚本来配置其功能为这个语言所用的。

      • 不过，对于一般用户来说，第一眼开上去np++是很讨巧，没有很复杂的设置，所有功能即开即用。不过，这对于用户以后深入配置编辑器却有阻碍作用，拿自动缩进来说，VIM/EM可以用正则来配置什么时候缩进什么时候忽略等等，这整个过程都是可见的，用户知道在需要的时候可以去更改这个行为。但是NP++就是每支持一种语言就把这个语言的缩进方式硬编码到程序中，用户不能去更改自己的缩进方式，只能使用作者规定的方式，这其实已经不能称为“通用”编辑器了，因为不管作者再支持多少种语言，都只是这几种语言的编辑器。
        如果你喜欢np++，没问题，祝你用的开心。不过，当你不幸某天遇到一个np++不支持的语言，就只能自求多福了。多数情况下你只能抛弃你的编辑习惯，去寻找另一款编辑器了。

      • 的确，EmEditor很多地方都是可配的。Vim可配置性很强，它一般通过修改配置文件来实现。而EmEditor则是通过图形化界面，对初学者更容易。这让我想起了Windows与Linux。当然，我个人还是比较喜欢Linux的。

  23. 其实如果不是程序员，而是面对普通的文本使用者，notexpad这个早已停止更新的软件足够了，能查询字数，又很小巧，我日常工作中如果纯粹只是对付文本内容，都会打开这个。
    每次装系统都会迅速把这个弄上。

  26. 对于notepad++,想做一系列动作要怎么办呢?(包括判断,循环字符串和文件处理等)
    在Emeditor中用js完成.对notepad++不熟,估计没有这种功能.我用起来不方便.

    • 既然那么简单，那楼上的自己写一个？

      说起来容易，真正代码起来要考虑的因素太多太多，绝不仅仅像楼上写的因为“只是加载了文件的一部分而已”，所以“根本毫无技术含量。”啊。

      emeditor的编辑器感觉就是自己从头开发的（从头造这么个车轮，难度太大太大）。你倒是用windows自带的edit或richedit控件实现同样性能的看看？

      • 鄙人不才，正在实现这么一个编辑器，叫MegaxEdit.
        EmEditor的内核真的很一般，如果仔细研究过的话。很多功能是模仿Hidemaru而来。
        大文件的加载只Map一部分，StartOffset, CurrentCacheSize, Windows自带的EditControl也可以实现这个功能。
        Map的时候断行问题，向前或者向后回朔一下即可解决。
        相较而言，国人做的一个叫PilotEdit的大文件操作才算是正宗的，他的做法和我正在着手实现的算法应该有共通之处。
        现在平均性能最好的是秀丸 Hidemaru。EmEditor率先支持了模仿TextMate的Code sinippt, 占得先机。

    • 占用100M？有那么多啊。我Windows7 32位的60M左右，实在装了很多插件的基础上。jEdit的功能很强大的，只是，也许是Java本身性能的原因，性能啥稍微差点。据我所知，国外很多人用jEdit的，国内用的人比较少。

  31. 我日常使用最多的还是AptEdit Lite，因为深受善用佳软的影响，除非万不得已，一般都是使用免费软件。使用AptEdit无其它原因，主要是它支持列编辑模式，这点对于我日常工作非常重要，除了UE、MadEdit之外这个是我使用过的列编辑最好的文本编辑器了。当然也可能孤陋寡闻，有谁还知道其它免费文本编辑器支持列编辑模式的？

  35. 有文件编辑器可以对C#进行代码检查吗？
    检查下大括号是不是对得上，分号有没有写漏就可以了
    编译大工程的时候让编译器检查很费时间
    或者对对应的大括号连一条竖线
    （这个见过别人用emeditor演示过但我找不到实现方法）
    抱歉编程老手应该不会犯这种低级错误吧…

    • 基本同意，目前看来是这样，但像Emacs也是很好用的，只是大部分情况下没有必要学习而已，它能做的，VIM都做的很好

    • 对于程序员来说，花点学习vim的成本是绝对值得的，一旦顺手了那就爽了。
      有好友认为学好emacs就行了，没有办不到的事。
      所以用就用最好的，两大神器挑一用熟就不用再在众多编辑器中徘徊了。

  37. 不知道兄台仔细用过多少编辑器，起码对于这种分类方式不敢苟同。
    没用真正领略各个编辑器的强大，就唐突的给之分类，有点欠妥。硬是给编辑器配置很多，插啊插的插件，说编辑器如何如何强大，不如直接用IDE了。

    自己的经历是这样的emeditor、editplus、ultraeditor、notepad++，最后定在了pspad + notepad2，不就是个编辑器吗，何必用来分人物高低呢。

    加之对于IDE的使用，和兄台有相反的见解，越早使用IDE越好，可以更好的辅助理解Java语言元素之间的关系和语言特点，至于学的好不好，理论理解的怎么样，和工具关系不大。用文本编辑器学java，要么是条件太差，要么就是在浪费时间。传说很久的那套是骗人的。

    强烈建议用emeditor而贬低其他，只能说明兄台对它太熟悉了，有软文的嫌疑（开玩笑了）。

    别说EmEditor能替代Vim，这个题目本身就是笑话。

    说了，这么多，象是来踢场子的，不管怎么着，觉得这个系列的文章改个名字，更扎实些，本来是分享心得，何必整得亲疏分明、乌烟瘴气的

    • 各有各的见解吧。对于EmEditor替代Vim，只是一种定位，毕竟很多人不愿意或学了一阵子就像放弃Vim，而EmEditor学期却很容易，功能个人感觉很强大。而且，EmEditor可以打造成类似Vim，有Vim的插件。
      Vim、EmEditor、Editplus、UltraEdit、jEdit这几款有仔细用过。其他的虽然没有很仔细，但也查了不少资料。

    • 各有各的见解吧。对于EmEditor替代Vim，只是一种定位，毕竟很多人不愿意或学了一阵子就想放弃Vim，而EmEditor学习却很容易，功能个人感觉很强大。而且，如果喜欢Vim的一些操作方式，EmEditor可以打造成类似Vim。
      Vim、EmEditor、Editplus、UltraEdit、jEdit这几款有仔细用过。其他的虽然没有很仔细，但也查了不少资料。

        • 哥们，如果你用过VIM，再在IDE中输入代码，即使有VA的帮助，修改、复制什么的，也差了不止一点，更何况还有VIM中强大的正则表达式，还有脚本，用习惯了很难在IDE中输入。

        • IDE能提示匹配类型的变量,自动提示转换类型.
          能自动提取方法.
          正则表达式是个IDE都有吧.

          团队合作别人用IDE你不用…这也不行啊…

        • 我认为写代码更多的是处理功能逻辑，而不是玩弄字符，作为程序员，在目前普遍场合下，玩弄字符带来的效率基本上可以忽略不计了。而IDE带来的高效也是文本编辑器+plugin/addons难以达到的。

        • > 我认为写代码更多的是处理功能逻辑，而不是玩弄字符，作为程序员，在目前普遍场合下，玩弄字符带来的效率基本上可以忽略不计了。

          确实。编程最主要是思路要清晰，相比处理功能逻辑所花的时间，玩弄字符的效率确实影响不大。

        • 同意上面几位说的“写代码更多的是处理功能逻辑”，但文字处理很多时候在代码中也是需要的，像代码提取、修改、整合，没有高度的智能化，很难对分散到各处的代码进行操作，靠鼠标拖上拖下找代码，不得不说是一件很累人累手的事，如果能够做到更好，又何必不去做呢。写代码的功能逻辑和编程功底与高效的编辑器是不矛盾的，尤其是在同级别、类似水平的程序员之间，不用可能要1个小时，用了也许只是几分钟就搞定，这就是编辑器的高效的好处，我本人已经不止一次体验这种高效了。

        • 虽然现在大部分的IDE都支持正则，但很多功能都不够强大，对付一般的正则还行，稍微复杂些的就有些吃力了，并且规则有时也不通用，总不能换个IDE就学一种吧

    • 我只是就我使用的一些体会写出来，我没有说我就一定是对的，只是觉得多少会对有些人带来点好处。你们自己完全可以选择自己喜欢的。

  43. 你们慢慢骂街吧。

    我就用三个文件Editor:
    AkelPad（俄罗斯人）
    NoteXPad 1.4.5.2(中国人用汇编做的)
    SciTE（美国人）

    IDE就两个：
    Eclipse和盗版的Visual Studio 2005 TS

  45. 我觉得应该按支持的平台、功能、占用资源的大小、启动速度、打开速度、软件本身容量等做几张比较表更能说明问题。

      • 用记事本打开当然全部正常了，但用editplus,pspad,rj textad打开bootex.log文件就不正常，rj textad 打开nginx_rewrite.txt乱码。如果要转换编码除editplus正常外，其它全部乱码包括notepad++。目前僵究着notepad++，notepad2又不支持拖拽多个文件。盗版软件偶尔用一次还行，被发现的话就惨了。

        • bootex.log用了没有签名的UTF16，而且全部使用了英文字符，打开当然不正常了，因为从二进制来看，完全可以当成UTF8或者ASCII，只不过字符间插入了空格而已。作为编辑器来说，只要忠实地解释字符就可以了。如果你愿意，手工指定成UTF16就可以了。notepad确实在兼容性上很好，也因为功能简单，所以要考虑的方面少。

        • @@zhouzh2

          有没有签名，这个也是比较重要的，比如在写php使用编码为utf-8时，一定不能带BOM，否则会报错。
          照这么说的话，相当多的不认识签名的软件不适合写utf-8编码的php程序。
          PSpad在加载我U盘上的文件时不是一般的慢，受不了。
          还有没有其它好的编辑器，介绍下。

        • 不是UTF8啊，汗。UTF8不管带不带BOM大部分的编辑器都是支持的，只要注意别用notepad就可以了。支持带BOM的UTF16的编辑器其实也不少，无非是支持不带BOM的UTF16的比较少，而且大部分就算指定成UTF16也会乱码。
          我一年前自己做了一个表格，比较测试了大部分的编辑器，不过上班了以后一直没有时间整理成文贴出来。就我个人来说，要推荐首推EM，性能好，稳定，开发周期也一直处于良好的轨道上，它的自动识别编码，宏，自定义，界面，snippet，拼写检查等等，都达到了一个很好的平衡。其次Notepad2，n2性能和稳定性非常好，前提是其提供的功能能满足你的话。Scite的性能是所有Scintilla内核的编辑器中最好的，这个性能不是指大文件，而是长行多行语法着色变换查找替换等所花的反应时间。我测试它的时候还是1.6版，现在已经到2.0版了，新支持多个不连续选区，列模式大大增强抛开np++之流几条街。scite的缺点是要完全配置好用好它需要不下于配置vim的精力…N2和Scite都不支持可录制回放编辑的宏（Scite貌似可以写脚本），没记错的话打开无BOM的UTF16将乱码，也不提供EM那样NB的编码识别能力，当然在绝大多数情况下使用是没有问题的。UTF16完全还没普及，我们普通人还是很少会接触到需要切换各种codepage的稀奇古怪的东欧之流的文字吧。
          现在我有一个比较关注的编辑器，叫Hippoedit，俄国人写的，收费（但免费注册码很好拿），有非常非常多的首创特色功能，有一部分甚至在VIM中也还尚未实现（我是VIM菜鸟，也可能是我孤陋了）。我喜欢它的界面和恰到好处的feature-set，当然现在还处于成长阶段，功能完备性上尚不能跟大佬们相比，不过比N2还是强了不是一点的。
          如果希望保有notepad的兼容性，建议可以试试台湾兄弟写的Madedit，其他方面的功能比较弱没什么特别牛的，但是编码识别方面非常地强，甚至比Em还强。按照你的要求，bootex.log打开即解释成UTF16，跟notepad一模一样，不像em解释成了NULL+UTF8，还需要手动指定。Madedit的列模式也达到了很高水准，比大部分仅仅支持列选择的高明。

        • 还有一点，就是Scintilla系的编辑器的正则一直很让我崩溃。本身就是一个不完整的库，还使用了一个看着像却又不完全是perl正则的语法，不支持多行查找和多行匹配，最最崩溃是当你想查找回车的时候还要注意CR、LF的区别，不同的系统下的文件（Windows、UNIX、Mac）匹配换行要相应的用n或者r，我就常常因为一些莫名其妙的错误而泪奔。Scite，Np++，N2莫不如此。
          相反Em的正则从来没有让我失望过，标准的perl正则，支持多行查找，不管是用n匹配还是手工加回车还是混用，“.”可以设定为匹配多行，甚至支持环视，正则鼻祖VIM也不过如此吧。一句话，使用EM的正则时通常一步到位，而我用Scintilla系的编辑器常要调试很多次，也许是我个人太不熟悉了吧。

        • Hippoedit还真的没听过，好像是收费的软件呀。
          它在转换编码时会出乱码吗？？？
          目前我就试过两款软件在转换时不会出现乱码：记事本、editplus3，其它的不敢试。

        • @@zhouzh2
          HippoEDIT看上去很强大的样子，在试用中，那些文件都可以正常打开。能不能交流一下QQ：五〇二二五一二五七，注明：编辑器。

        • @@zhouzh2
          1.发现一个HippoEDIT的bug，它的自动换行功能有问题，并不能完全的自动换行，会出现半个汉字的情况。
          2.移动/删除某一行/块。在notepad++快捷键是ctrl+shift+向上/向下、ctrl+l。但在这里找不到呀。

          目前我知道的notepad++、editplus对正则支持不好。所以想找一个支持正则而且编码支持也比较好的软件。还真难找。

        • 1.是的，对中文的自动换行有问题。因为是一个编码向的编辑器，为了性能考虑计算自动换行时是按照字符数来的，因此对于多字节的字符支持有问题。
          这个我跟作者说了，他说未来会改进，不过现在的重点还是添加更重要的功能，很长一段时间内估计是只能这样了。所以说这个软件还在成长中么，呵呵。
          2.该功能肯定是有的，这些基本的编辑这个编辑器做得非常好，在我印象中要比np++强了不知多少。我现在机器上也没安装可能帮不了你，你再找找，肯定是有的，实在不行去论坛问吧，作者非常nice。
          3.“找一个支持正则而且编码支持也比较好的软件”我估计你是想找一个开源或者至少是免费的吧，不然em肯定是可以满足你的。Madedit的编码支持很好，正则用了boost库（跟em一样），只是版本应该没有em新，也不一定有em那么完整的支持，不过你可以试试，看能不能满足你。
          纯粹免费的可以试试EditpadLite。

        • @@polaris
          它的正则是不错，在用正则的时候我就打开它。比较有名的东西在公司不敢用，被公司的网管发现了会上报的。感觉HippoEDIT好像具有ededitor和notepad++的特性。

          @@zhouzh2
          回答我的问题呀

      • 1.是的，对中文的自动换行有问题。因为是一个编码向的编辑器，为了性能考虑计算自动换行时是按照字符数来的，因此对于多字节的字符支持有问题。
        这个我跟作者说了，他说未来会改进，不过现在的重点还是添加更重要的功能，很长一段时间内估计是只能这样了。所以说这个软件还在成长中么，呵呵。
        2.该功能肯定是有的，这些基本的编辑这个编辑器做得非常好，在我印象中要比np++强了不知多少。我现在机器上也没安装可能帮不了你，你再找找，肯定是有的，实在不行去论坛问吧，作者非常nice。
        3.“找一个支持正则而且编码支持也比较好的软件”我估计你是想找一个开源或者至少是免费的吧，不然em肯定是可以满足你的。Madedit的编码支持很好，正则用了boost库（跟em一样），只是版本应该没有em新，也不一定有em那么完整的支持，不过你可以试试，看能不能满足你。
        纯粹免费的你可以试试EditpadLite。

        • @@zhouzh2
          1.你说的很对,我是在找一款免费的文本编辑器，正则要强而且编码识别能力也要强。
          2.HippoEDIT看来还要等待一阵子才能上场。家里先用着emeditor、editplus。因为在公司不能用这些软件，所以np++也一直在我的电脑里，现在慢慢学着点用。
          3.有没有像editplus那样可以配置虚拟站点功能的编辑器，这样修改好一个文件后，直接ctrl+b就能看效果，就是因为这一点，所以我一直在用。

        • 1.它的line number为什么在显示的时候是不连续的？还是我没有配置好，但我实在找不到配置的地方。
          2.你有中文版的吗？

        • @ddd
          “虚拟站点功能”？不清楚你要讲的是什么，看上去绑定一个热键到外部工具调用浏览器就可以了呀。
          1. line number参见这里：http://forum.hippoedit.com/?/topic,144.msg1047.html#msg1047
          2. 没有，作者近期也没有开发多语言支持的计划。论坛上有一个hack了内核的中文版，版本很老了。

        • @@zhouzh2
          在editplus的“工具”，能看到“主机，主目录”字样，在这里配置好（但要先配置好本地虚拟主机），修改任何一个虚拟站点的文件，用ctrl+b就可以浏览了，非常的方便。

        • @@zhouzh2

          再问你个事，为什么每修改一个文件，HippoEDIT就会生成一个.xml文件呀，怎样让它不生成或者是在自己程序目录生成？？

        • ddd: 2010-09-06 11:54
          @@zhouzh2
          救命呀……
          我不知道点了什么了，菜单栏和工具栏全不显示了，怎么恢复呀？？？

          郁闷，出来了。太折腾了。不敢乱点了。

  49. VIM 我也只能用一些基本的操作
    比较复杂的自己也不会
    目前也没有这样的需求
    用软件不能太折腾
    虽然说磨刀不误砍材工

  50. 实际上，Emacs 比 Vim 要好接触

    Vim 需要理解“模式”，而 Emacs 里面根本不需要，和一般的文本编辑器没有两样，我觉得，如果没有实际接触过 Emacs 最好不要妄下断语

  52. 编辑器杂谈
    作者：HuaHope

    Scintilla的相关项目很多，官方网站的related中就列举了相当多的。只是恰如有次见到一个评论中说的，自从有了Scintilla，几乎大多数的编辑器都很少自己编写“编辑器”了，完全是加个外壳，当然编辑器控件SynEdit(delphi)、CodeMax等也功不可没。

    就Scite_ru、Scite Latex IDE而言，其实并不算是出众的Scintilla相关项目，而ScintillaLua虽然是这里看到了才知道新有了这个项目，也刚去下载了（可惜zip的解压失败，就下载的tgz的），但只是看看配置文件就知道了，其也只不过是Mitchell Foral的一个副产品，之前Mitchell Foral就有Scite Tools和Scite St，再加上后来的Textadept，这几个都是差不多的实现，除了补足SciTE的动态着色之外，还有一个snippet功能，不过也许ScintillaLua可能独立后实现的比以前更完善吧，没有看代码，但是lexer配置倒是丰富了很多，终于几乎实现了Scintilla的所有支持语言，另外一个最大的改进就是许可证终于换成了BSD，比Scite Tools的LGPL要更开放些，以至于SciTE_ru最新的版本就以及迫不及待地整合了ScintillaLua，实现了外部lexer的支持。不过从设计角度而言，Lexer采用外挂的lua脚本，处理能力毕竟有限，虽然使用llpeg灵活性增强了，但是效能无疑更低了，即便是luajit，估计也无法对付稍大一点的文件。Scintilla比较好的项目，Filerx算是不错，可惜很久就不更新了。其余的，就编辑器而言，都没能走出Scintilla的限制，也自然更难超越Scintilla自身的光环。

    其实国内基于Scintilla的项目也很多的，但真正自己写编辑器的也有，比如已经商业化的Aptedit，还有MegaxEdit等，MegaxEdit的博客中讲了一些编辑器实现技术，比如折叠等，和Scintilla实现是类似的，只是很可惜，由于没有实物，所以无法评测其功能和性能，不过虽然上面说大多数编辑器完全拿来义不好，但是MegaxEdit完全自己写，甚至字符串查找KMP算法也自己实现，实在也太过于自力更生，看日志好像还自己实现了可配置的状态机，距离正则库也差不远了，只不知道正则库是否也自己写完了：）Megax还曾经到FlexEdit网站评论过，虽然指出没有突出优势的缺点也不算错，但从其日志上描述的技术思想中感觉块着色算法虽然比Scintilla的要好，但是还是不够完善的，比如不允许循环嵌套语言，其实这个限制并不应存在，除非刻意的构造，否则几乎所有的文件中语言再怎么嵌套都是有限的，也是可以分析着色的。另至于嵌套只允许4个子语言，对于html而言就未必够用，而且如果不独立线程，即便是块着色速度对于10万行以上的大文件也依然很慢，不过Megax从09年2月就消失了，一直到这个月才又冒出来更新日志，感觉依然对lex很纠结，估计还有一段路要走。当然还有MadEdit，也是很不错的，16进制和内码做得很好，只是大文件处理能力有限，界面也不够美观。至于国人的flexedit、notepad++等，也多半只是加个壳而已。没有太多需要说的，Notepad++的插件系统倒是不错，现在的插件也非常的多，只是其中很多没有实现界面的插件并没有太多的必要，如果Notepad++实现ScitTE中的lua脚本扩展，编写脚本即可扩展类似的功能，实在没有必要做成dll，从一种扩展走向另一种封闭，只是没有深入研究过其插件系统，感觉整体设计还是不错的，不过距离几乎完全插件化的Eclipse估计还是有所差距。

    而国外的自己写编辑器模块的就要多一些，比如e texteditor，intype（早期是自己修改的Scintilla，后来好像是觉得Scintilla不够好，重新实现了自己的）,sublime text editor等等，其实编辑器技术最难，也是最核心的就只是如何对内存进行Gap操作，如果完成了这个，效率足够，其余的真的很容易，Codeproject上有一些相关的教程，但估计看完的并不多。至于Komodo、XmlSpy、LuaEdit、Autoit的编辑器、Adobe的Creative Suite套件中的ExtendScript Toolkit等，由于产品定位不同，直接使用Scintilla的编辑器也无可厚非。何况Komodo、Adobe都曾对Scintilla社区有贡献过代码，比如Scintilla中的Mac代码很多都是Adobe贡献的。

    至于MacOs下的Textmate也是自行实现的编辑器模块，不过没有测试过大文件性能，MacOs下的开发有个很好的优点，很多都是苹果内置实现了，而且MacOs本身就与脚本相当紧密，甚至自带了tcl、perl等，shell也很好用，所以MacOs下的编辑器都实现的比较好，比如BBEditor等，xcode使用起来也非常方便，不过很奇怪的是，xcode的snippet、自动补全等在输入代码后会用灰色字体将后续的补全，但是如果用户不想要这个，又会自动清除，重新补全，但实际使用中感觉文本晃动的不太舒服，尤其是多行补全时，也许有人喜欢这样的风格吧，不过也可能有设置可以关掉吧。

    当然提到编辑器，不能不提的是Unix下的Vim和Emacs，两者各有千秋，不过也有各自的缺点，要不如果过于完美，凭近乎传奇的悠久历史，早就一统江湖了，呵呵。目前两者在windows平台都还算小众，另外，两者设计也不是绝对完美的，比如vim的键盘映射，命令的内部代码全部是硬编码，如dd删除行，以及yy等就是判断是否d或y重复而实现的，虽然新命令可以做map，也依然可完全定制键盘序列，但是如果代码实现能够将键盘序列与对应功能任意由用户绑定，或者内部使用表来绑定键盘序列和其默认功能，即更灵活些就更好了，这样修改起来也很容易就可以改进键盘绑定，而不是现在功能处理分散在代码的各个地方。UltraEdit没什么太多要说的，虽然不及Vim和Emacs悠久历史，但也再过几年就开发了二十年了，足够长的时间，也足够做很多改进了，事实也是如此，现在的实在是太庞大了，一个编辑器要几十兆，不过就功能而言，除了大和全之外，16进制还可以，列模式虽然也不错，但对于东亚等复杂文字处理还是不够完善，至于作为重要特性的大文件处理性能其实也不好，用临时文件时先要复制一个副本导致速度很慢，而且占用大量硬盘，不用，就无法撤销编辑，实在是两难。何况现代编辑器的许多理念，如自定义着色Lexer、snippet等，也是很难见到。扩展性也不够好。而就体积而言，同样庞大的Emacs就远比UltraEdit要强上非常多，可见UltraEdit之臃肿，至于提到的大文件和扩展性，EmEditor就很不错，EmEditor通过基于内存映射的框架实现了一个很好的大文件编辑功能，不过EmEditor很多都依赖于插件，未必是很好的设计。如果不像Eclipse那样，有众多的拥蹙开发插件的话，而只靠开发者本身开发的话，插件系统用处并不大。更何况虽然EmEditor的脚本扩展做得不错，好像也实现了com，但是多数插件仿佛并不是脚本实现的，这和样就无形增加了第三方开发难处。开发Visual Assist可以make money，给EmEditor开发插件，估计很少有用户这么做吧，幸好EmEditor还是卖出了不少钱的，开发者一直相当积极的升级，一次版本都能发几十个beta版，现在已经是版本9了吧，相对而言，EmEditor升级对于现代编辑器功能的关注还是不错的，9中就已经实现了snippet，比起UltraEdit经过15个版本还停留在Templates模板功能上，每次的升级只是围绕着彩色的tab页，界面配置的角色化，查找窗口中的单行编辑框变成多行编辑框，应该算是比较上进的了，不是说UltraEdit做的改进不重要，只要是用户使用到的，都是最重要的功能点，但是核心功能的改进更不可或缺，否则界面做得再好，编辑效率提不高，有什么用呢。说了这么多编辑器，也提一下Editplus，虽然功能不算突出，但设计的很简洁，很中庸型的编辑器。至于pspad，开发了很多的功能，甚至包括计算器，颜色拾取器等，确实很辛苦，但是依然不够稳定，而且比起同样是delphi编写的RJ TextEd来说，功能也并不算丰富，界面也逊色些，其实delphi的界面库很好用，换肤功能也很强，虽然也许换肤对于编辑器而言过于花哨，但是只要是会接触和使用到编辑器，而不是只知道记事本和word的，编辑器多半是最最常用的工作或学习的不可或缺的工具。因此如果拥有一套美观的默认外观对于用户使用也是很有用的，毕竟爱美之心人皆有之。

  53. 撇开其他非Scintilla的编辑器不谈，就Scintilla编辑器而言，最大的缺点，也是很奇怪的，就是几乎每个项目都很少会修改Scintilla内部，Mitchell Foral的Scite Tools和Scite St、Textadept、Scintillalua算是少有的另类，其余的真的很难看到做较大功能改进的，也许为了升级更新编辑器模块方便，甚至静态编译的都很少，一律的动态链接，几乎都是完全的拿来主义。说实话，如果编辑功能只是工程的一部分，那也符合重用的开发理念，但很多工程本身就是开发编辑器，也一味的用而不改进核心功能，不仅使自身无法提高层次，不利于Scintilla发展，更使得现在大多数Scintilla同质化非常严重，譬如，Scintilla的列模式几乎每个项目都在期待，但是由于Neil一直很难决定如何很好的实现virtual space，所以所有的相关项目的列模式为人诟病已经很多年，直到2.0中实现了多选区编辑和virtual space功能才算是了却了几年来的心愿，而且就目前而言，列模式还实现得并不完善，比如列模式下的粘贴文本就无法像UltraEdit一样粘贴到每一行。不过1.76之后的代码就很少跟踪了，也没有去看这个新功能代码如何实现的，其实virtual space和列模式功能要实现很简单，只要在原先选区的Anchor和current基础上增加virtual Anchor和virtual current即可。另外每个项目都知道Scintilla内存消耗是文本自身的两倍，仅仅是为了实现style，Neil在实验项目中SinkWorld虽然对此作出了改进，但是SinkWorld进展实在非常缓慢，类似于Scintilla与SciTE，展示SinkWorld的Tentacle 也很久没有更新了。而且SinkWorld中的改进是针对于Scintilla中style的8个bit位128种style无法充分支持html这种可嵌入子语言类型很多的扩展型语言的，要实现的是动态长度的Style，这样必然会带来更严重的内存问题，其实就内存而言，打开相同的文件，Vim消耗的内存是相对而言比较少的，基本上比实际文本多一些，而其他的编辑器大多也是内存消耗很多，甚至有三倍于文本自身的，但其实内存问题并不必要用现在的style实现方式的，动态数组是一个更好的方式，不仅可以做到内存占用几乎与文本自身大小接近，而且对于识别同一style的起始结束和结束都是很有益处的，复杂度甚至可以做到常量，而不是现在的线性，需要逐个byte的去比对搜索，这点对于基于代码做分析，比如识别注释、字符串等块状文本有很重要的意义。当然，Scintilla目前最大的弱势还是在于正则库，Regex实在是一个过于简单的正则引擎，虽然Scintilla在1.77版本中就实现了正则引擎的外接口，相关项目，如Programmer’s Notepad也已经实现了使用Pcre和Xpressive分别用于Scintilla内部和配置的正则匹配，但是多半还是需要针对各个引擎库写迭代器的，这样就不免又造成了一定的门槛，使得现在大多数项目依然使用内置的功能很弱的正则库。而没有一个优秀的正则库作为支撑，就很难实现自由度很高的自动缩进、函数识别等，更重要的，Lexer就无法做成可配置。用户自由的实现如vim、emacs、textmate那样编写lexer扩展就无法成为可能。而缺少这些，对于现代的编辑器功能而言，不免是一个很大的遗憾和功能劣势。除此以外，对于大文件的支持也是Scintilla的弱势，由于内部的设计导致的双倍内存问题，使得大文件支持更为捉衿见肘，相关的一些功能，比如括号对匹配高亮，以目前的SciTE内部实现是搜索全部文本，这显然在大文件时会导致界面假死，而Notepad++则弥补了这个缺陷，将搜索限定在上下搜索2000行而已，但这对于大文件又显然是不够的。诸如此类的功能，对于大文件而言便不免会有所缺失，不过Neil很早就宣称，Scintilla并不是为大文件设计的，所以也无可厚非。何况大文件的需求比较特殊，并不能完全做到统一，也许Neil除了认为难以实现之外，还考虑到了大文件操作与系统是紧密相连的，比如windows的内存映射，其他平台的实现就不尽相同，因此严格意义上，就Scintilla不与具体系统捆绑的设计目标来说，这并不是Scintilla遗漏的功能，实际上，从某种意义而言，Scintilla已经提供了很好的框架，足以支撑外部项目使用系统函数和算法更好的处理大文件，不过所有的项目鲜有见到实现了大文件操作的，包括最流行的项目Notepad++。当然大文件本身就是很难做处理的，即便是宣称大文件处理比较好的EmEditor，打开普通的非着色文件还好，但一旦遇到着色的如cpp文件，也一样会很痛苦，因为着色是需要遍历每一个字符并采集属性的，因无法见到EmEditor的Lexer代码，不知道如何实现的。但是要解决着色问题，前提必然是Lexer线程独立，而非Scintilla现在的单线程，虽然Scintilla内部设计了一些位置信息，可以接续着色等，但对于大文档，依然会有明显的延迟。Vim要好些，可惜也没有去研究过其Lexer代码。上文提到的Megax的分块着色是一个好的解决方案，但是多线程依然是最终解决的不可或缺的，其实Scintilla Maillist中很早就几次提过多线程着色，但是Neil认为难度很大，也没有人提出可行的方案，也就不了了之了。与大文件类似的，缺失的还有全面支持UTF8，和16进制，vim和Emacs等早已经实现了内部完整支持Unicode，当然实际内码是UTF8，因为对于许多字符集而言，Utf8比Utf16等编码方式要节省内存，而Scintilla则由于扩展性，采取设置内码方式，虽然也可以支持UTF8，但是兼容多内码的设计带来了很多的效率问题，比如查找时，对于MBCS，就需要判断当前字符是否是leading字符，这样很显然会非常慢，这从SciTE设置内码为CP936等代码页后的搜索就可以很明显的看出与其他编辑器的速度差距，而且支持单一的UTF8可以更好的识别文本，比如中文的书名号配对《》，这是多内码设计所无法实现的，因为项目无法对每一种代码页都做分析，做出特定的表来识别，不过这个错不完全在Scintilla，外部项目本身可以弥补这些缺陷，可惜从开源的一些编辑器实现上看，并没有编辑器如此做。至于16进制，UltraEdit实现的比较好，虽然一些编辑器项目也实现了16进制，比如FlexEdit、Notepad++、Scite_RU等，但是FlexEdit是另外写的16进制编辑模块，不是用的Scintilla，Notepad++也是一样，HexEditor插件也是另外实现的基于树形列表Treelist的16进制编辑控件，而SciTE_Ru虽然是通过lua脚本实现了原生的Scintilla十六进制编辑，但是类似于Dos时的小窗口编辑实现的并不算好。很奇怪的是，1.78版本中实现的两个主要新特性之一的文本边栏Text margin就完全可以很好的实现16进制编辑时的偏移量显示，但是依然还是见不到有项目基于此自行实现的16进制编辑功能，也许一样要等到Scintilla完全实现内置16进制编辑才会普及吧。至于1.78中添加的另一个新特性注释行Annotation lines，很类似于xcode中设计的出错显示，不过也许visual studio等windows开发环境习惯于将错误输出到Output窗口，而只有要显示汇编时才混合代码和汇编一起显示，所以Annotation lines也是应用寥寥，平心而论，Scintilla就编辑功能的覆盖广度已经做得比较完备了，许多功能并不弱于vim、Emacs等超级编辑器，但是问题在于各项目组合基础功能之后的深度还不够，以至同质化严重的同时，各项目也功能平平，比如自动缩进，vim实现了四种缩进，auto、smart、c、以及indentexpr，而emacs则实现了gnu、java、l
    inux、python、user等多种成熟的缩进风格，提过组合，在vim和emacs中几乎常见的缩进风格都很容易实现。而SciTE实现了简单的自动缩进后，大多数基本沿用，因此缩进都不够智能，而Notepad++的插件NppAutoIndent则从一定程度上改进了Notepad++的自动缩进，可见自动缩进并非是Scintilla不能支持，而是大多数项目设计使用不当。当然SciTE还展示了lua脚本扩展，以及提过windows的消息扩展等，如Filerx就是使用外部SendMessage来操作SciTE，效果很好，可以录制和重放操作，对于文本编辑器而言，lua脚本使用SciTe的库函数接口已经足够实现绝大多数文本功能扩展。但可惜的是，大多数项目没能很好的继承SciTE这种良好的扩展性，大多数项目没有实现类似的lua系统，就是有扩展性也是另起炉灶，如Notepad++自行实现了插件系统，固然设计的还不错，但却失去了脚本的灵活，而programmer’s notepad等虽也自行实现了采用python等其他脚本语言的脚本扩展，可惜自由度却还是不如SciTE。当然同样可惜的是，依然有些扩展是需要有界面的，尤其是运行时需要引入参数的，而单纯的lua无法扩展界面，lua的几个界面库如iup，tckUI等也不能很好的担当大任，使得单纯的SciTE中的lua扩展使用并不是特别方便，再加上SciTE本身非界面化的配置不够友好，导致其用户并不是很多。至于lua和wxWidgets或者Qt虽然可以较好的互动，但是前提是SciTE不是采用这些库开发的，而即便有项目以这些界面库开发，使用lua来控制，估计需要做的事情依然很多，不够轻量化，也不符合现在网络化的发展趋势。

  54. 至于比编辑器更复杂的IDE，情况也差不多，大多数IDE现在都是Eclipse化了，另外由于Borland的黯然离开，除了微软自家的Visual Studio，考虑到跨平台，IDE多半用的不是java就是wxWidgets，如另一个与Eclipse齐名的NetBean也是java实现的。而一些小型的IDE，如Code::Blocks、Komodo等，出于开发方便，最主要的核心组件之一也很少自行开发，直接使用了Scintilla，其实，无论是从开发角度还是使用角度而言，编辑器不仅仅是IDE的基础，也同时已经具备了IDE的初步雏形，尤其是除了少数几个巨型IDE如微软的Visual Studio，Sun Java Studio，IBM Rational（基于Eclipse），以及一些CPU厂商，如Intel、Motorola的IDE等，可以有足够的实力考虑和实现包括编译器、调试器、编辑器、版本控制器等各个组件的设计开发衔接以更好的整合之外，大多数的IDE基本都是外挂式的，比如挂上GCC，SVN等等，而这些，很多编辑器其实也都可以做到，甚至包括外挂调试器，只是相对而言，由于设计目标和定位不同，IDE实现和整合的功能更多，IDE的插件系统一般也更复杂也更完善，扩展功能更容易，而这对于大多数单兵作战开发的编辑器就很少会充分的考虑到。当然类似的还有SlickEdit、UltraEdit Studio，以及以代码分析著称的Source Insight等第三方IDE，至于Emacs也可以算是IDE吧，对于此类IDE，优秀的编辑器都一样是其基础，不过就以Source Insight而言，其定位就是编辑代码文件，因此大文件操作就很少考虑，否则，以Source Insight独特的不等行高的设计，大文件的整体行高计算和显示就会是一个棘手的问题。另外SlickEdit的Slick-C，和Emacs的Lisp是比较独特的，几乎所有的功能都是用Slick-C，或者Lisp实现的，应该算是可扩展性最好的IDE设计之一。

    只是Source Insight、SlickEdit、UltraEdit、Textmate、EmEditor、Visual Assist等都有商业赢利支撑，而Eclipse、NetBean等虽开源免费，但背后也都有IBM、Sun等大型技术公司做支撑，相比较之下，开源且免费的Scintilla即便相关的项目众多，几乎占据了开源编辑器项目的半壁江山，但如果所有的项目都只是提需求，缺陷，和等待使用，那么仅靠Neil一个开发者而言，虽然Scintilla已经做得足够好了，也因坚持了近十年的不断奋斗也让人由衷感慨和钦佩，但如果Scintilla想做得更好，实在将是很艰难的前行。

    一时感慨，写得多了，希望对于关注或采用Scintilla的项目，以及致力于自行编写编辑器的能有所用。

  55. 很高兴没看到MegaxEdit没自行实现正则库，前段时间在MissDeer的博客中随手写的一篇“编辑器杂谈”中还提到了这个，开发应有所为有所不为，什么都自行实现且不论是否可以写得更好，也实在没有必要，当然例如Emacs的Richard Stallman样样精通的超级大牛除外。“编辑器杂谈”主要是针对Scintilla系编辑器写的，也评论了点现有知名编辑器，随附在后，希望一点心得有点小用。

    不过文中有几处小错还是需要指出，估计Megax是不是没有苹果机器实际试用和深入研究过Textmate，所以不太清楚？

    其一，Textmate的这个功能不是Bundle，而是Snippet，Bundle功能比这个要重要和强劲的多，Bundle构建了脚本与编辑器以及系统的关联，类似于脚本宏，MacOs上脚本体系比Windows要好很多，自带的脚本也远比Windows的JavaScript、VbScript要丰富，当然Windows的Com也异常强大，不过苹果在脚本体系的人机交互上远比Windows要好上很多。而Snippet则基本上就是文本段落辅助完成，其实Visual Studio里面就有Snippet功能，不过估计使用和研究的人更少，毕竟不是很明显的功能。Vim和Emacs也早有插件，或多或少也实现了较完整的Snippet。

    其二，Oniguruma正则库，也就是鬼车是支持循环嵌套的，其自带的帮助中写得很清楚，而且还举了实例，Megax在东京呆了这么多年，即便英文的帮助没注意，日文的帮助也应该至少读一遍的。应该说，最近流行的正则库大多数都已经实现了嵌套匹配，如脚本语言Perl、PHP、开发平台.Net、Java的正则库，以及正则库Greta等都是支持嵌套的，这个在O’Reilly《精通正则表达式》一书中有详细的描述。当然1.9.0版本之后采用Oniguruma的Ruby自然也支持嵌套正则。不过也正由于Oniguruma合入了Ruby，因此现在Oniguruma的最新代码已基本合并入Ruby开发，可惜的是，Ruby加了很多专有的定义进去，使得剥离一个最新的Oniguruma已经很难了。最容易为第三方集成使用的Oniguruma也许永远都定格在5.9.1了吧。

    其三，正因为Oniguruma支持嵌套正则，所以TextMate支持Snippet嵌套变量也就不足为奇了，因为TextMate的正则库正是Oniguruma的Cocoa移植版本，也许是OgreKit。当然由于Textmate商业软件的源码不可见，也不排除TextMate直接使用字符串函数进行解析，因为Snippet本身并不复杂，纯字符串解析也很容易。目前Snippet做的比较完善的除了TextMate，还有Intype一样的支持嵌套变量，但是e TextEditor就只能支持简单的文本了。

    其四，写伪码时最好也要注意语法，strFind.Format( “${%d:(.*?)}”, i ); 肯定编不出正则的，Escape转义字符应该写\，而不是，要不然引号就先使用转义了，再往下就自然出错。这不是TCL，TCL可以使用{}来规避，而C则不行。

    不过总得来说，基本上Snippet的实现就是这样了，不过依然有两点需要改进，一是变量的顺序，其实没有必要规定顺序。当然，如果按一次处理一个序号自然会引入顺序问题，但是如果一遍先将所有编号区域全部找出存储，并记录位置信息，再行一次性替换，就可以解决顺序问题了。其二，Tab键并不是一个完美的键，无论是TextMate，还是Intype等，都只可以用Tab前进，而无法后退，这是因为Tab本是就是缩进键，此处挪作Snippet用，从而导致一个键二次定义，从用户角度上而言是不可取的，使得用户在Snippet过程中无法缩进，例如复杂点的段落，自动缩进不完美的情景下，用户就只能退出Snippet再行修改了。因此目前TextMate等多半是在编写Snippet时就预设好缩进，在Snippet时仅仅依据上一行进行整体缩进，从而一定程度上避免了这个问题。但是也因为很难做完善，所以Shift-Tab并没有用来实现Snippet的回跳，依然还是定义为减少缩进。这个问题在 Mitchell Foral 的Scite-Tools中有提及，因此Scite-Tools在Scite的基础上使用Ruby实现了Snippet时，并没有使用Tab键，而是Ctrl的组合键，这样就轻松的完成了前进和后退，如果TextMate等跳出Tab的圈子，自然一样可以轻松后退，不过如果决定权交到用户手中也许会更好。Mitchell Foral 基于Scite的后来的最新Mod作品，如TextAdept等，Snippet又用lua重新编写了。由于Snippet自身就是Ruby或Lua脚本的便利性，Mitchell的Snippet从某种意义而言应该是比TextMate更为强大，因为此时Snippet已经是具有完备功能的脚本段，有点类似于Bundle，而不再仅仅是一段字符串了。

    Snippet作为一个非常便捷的编码辅助功能，也依然在不断发展，自解释应是目前的最新阶段，其代表就是Zen Coding，作为快速开发的典范，类CSS的语法，使得编写Html等网页语言非常迅捷，可惜，其作用域由于语法特殊性，估计也很难走出Html的编程范围了。

  56. 无论是CodeProject还是SourceForge，其朝气蓬勃的发展无一不说明开源精神的可贵和价值。从某种意义而言，每个开发者的起点都是从开源起步的，因为学习的书籍、编程的帮助，大都带有源码，而且就开源本身而言，其与商业化是隔绝的，Linux一样是一个产业，其价值不在于开放的源码本身，而在于软件服务，并不是所有的开源项目被应用时都足够的时间来深入研究的，尤其对于大多数商业公司而言，软件的延续才是最重要的，毕竟没有谁希望自己的经济只能建立在一时的欢愉之上，在自行投入人力研究得不偿失的情况下，此时专业的研究开源的公司，如RedHat等，便就成了首选。目前，诸多大型软件公司，如IBM等，纷纷从软件转型服务，也清晰的表明了此种趋势。

    而对于大多数中小开发者而言，开源带来的不仅仅是学习的机遇，更多的是减轻了开发强度，加快了开发效率和质量，更为重要的是，与商业功能库相比，掌控源码便可以更好的围绕着自己的目标进行改良。可惜的是，开源并不是无约束的任意拥有，每一个开源项目都有其自身的法则，这种法则便是每一个开源都会携带的Licence。

    平心而论，Licence实在是多得眼花缭乱，BSD、MPL、GPL、MIT等等，再加上每一个大公司，如IBM、Microsoft、Nokia等还都有自己的开源许可，且每一种规定的权益和约束都不尽相同，其约束又大都是与法律相关的，使得透彻的理解每一种许可确实成为一个艰巨的任务，但是，对于作为最终应用开源的开发者，这并不能成为不履行义务的借口。只有每个人都索取和付出，整个开源才能更加繁荣的向前进，贪婪的索取最终只会让开源凋谢，从而让贪婪也无处可取。可惜的是，很多国人对此意识淡薄，甚至明知故犯。尤其是图像视频等领域，任意占用的案例更是层出不穷，且不提绿坝软件在美国被公诉，就是诸如腾讯之类的视听产品也对开源协议置若罔闻，这实在是不应该的。对于一些国人而言，喜欢占有权益，而不喜欢履行对法则尊崇的义务，成为了中国共享软件在海外口碑不好的一个重要原因。虽然国人开发软件，经常是一窝蜂的相互抄袭，克隆，将一类软件做烂，但相较于“偷”开源软件使用，也依然还是觉得后者的行径更为恶劣，其实，现在GPL的开源还是占主流的，而GPL的知名对于二次开发者而言，不可能不知道GPL协议的相关项目必须仍以GPL进行分发，而不能闭源，但实际中，很多共享软件中连需附上的开源库的GPL Licence都不见踪影，更遑论开源了。

    也许诸如GPL的开源协议对于技术和专利制度一样，虽然对持有人的权益有了充分的保护，也能通过良性发展确保整个体系的不断发展壮大，但也并不一定对技术的发展和应用起到更为积极的作用，LGPL的引出应该就是对GPL的良性补充。但幸运的是，许多开源协议采取了更为开放的政策，应该说，在对知识和作者充分尊重的基础上，越少约束的协议越能起到更多的良好的效果。BSD、MIT等就是其中很具有代表性的协议。

    更幸运的是，就编辑器而言，开源协议的宽松以及开源项目的高质量，都使得现在编辑器呈现出生机勃勃的发展，这不仅仅包括Scintilla，SynEdit等编辑控件，还有更为知名的Vim、Emacs，以及Scite、Notepad++等完善的编辑软件。而且无论是Vim的作者Bram Moolenaar、Emacs的作者RichardStallman、Scintilla的作者Neil Hodgson，都数十年如一日不求回报的默默奉献和付出，其精神远比开源本身要来的伟大和崇高，值得每一个应用，享受着成熟的、优良的开源模块的开发者向他们致以敬意。

  57. 但是恰如之前已经指出的那样，高质量的开源有时也不可避免的带来一些弊端，就以Scintilla而言，随着近几年的知名度不断扩大，且编辑控件不但应用广泛，其开发技术难度对于大多数开发者又显得艰难时，不免使得大多数开发者更愿意使用而不愿意创造。诚然，合理的应用成熟的模块是开发软件必不可少的，不可能指望每一个软件的每一个功能都从头开始堆砌代码，而且非核心的业务也应该尽可能的引入成熟的模块以减少风险和加快开发进度，但是在第一篇杂谈中就已经指出，诸如Notepad++之类的以编辑为核心的专业编辑器，仅仅采用拿来主义是不够的，只有众多的开源衍生项目都有改进和创新的思想和努力，才能使得Scintilla母体更好的发展，可惜的是，目前大多数Scintilla项目还是以加壳为主，再加上一些界面和功能整合，尤其是包括一些主打专业编辑器的项目，也只是坐待Scintilla的更新。不客气的说，从技术层面看，SciTE无论是设计还是扩展性，比大多数的衍生项目都要实现的更完善，唯一的缺点只是没有一个良好的易用的界面而已。

    当然，Scintilla本身的设计也不是十全十美的，Vim也是如此，Emacs源码对之兴趣不大，未曾通读过，所以不敢枉下评论。而编辑器的难点和重点除了内存的GAP之外，估计就应该是Lexer和Encoding了。

    通用型的编辑器不可能像专属编辑器一样，针对每一种语言都实现一个非常完备的Lexer，目前Scintilla内置了非常多的Lexer，其优势是着色速度会很快，而缺点则是用户无法定制和扩充。而现代的编辑器，如TextMate、Vim等都可以采用正则或类似的方式自定义Lexer，应该说，这和Scintilla缺少一个很好的内置的正则库是相关的。Mitchell Foral对之用lua进行了一些改良尝试，也许功能上看起来是可以实现，但是实用性依然受限，因为只有内置，才能从根本解决效率的问题。

    就语言着色而言，Lexer必须是从头开始扫描的，因为大多数语言都是具有跨行特性的，因此任何期望从中间进行分析着色的方法都是行不通的，因为无法保证当前文本不在一个多行注释或字符串之中，这也就是MegaxEdit当初尝试动态渲染当前屏为何失败的根本原因。但是Lexer依然是可以高效的，其中MegaxEdit的分次着色是有效的技术之一，不过没有实践过，仅从理论上分析，先将跨行特性的元素全部着色，再动态着色当前屏幕应该是很好的且可行的方案，而且可以做得非常的高效。另一个重要的技术就是动态构建正则，这样才能保证对于四种文法类型也都能或多或少不同程度上的支持，尤其是对于可以用巴科斯范式描述的语言能做到比较完善的解析和着色。第三个是多线程着色，只有实现了真正的多线程着色，才能从根本上解决着色耗时与用户实时操作之间的问题，而且不仅仅是着色，包括任何与编辑操作冲突的都需要独立线程，当然独立线程带来编辑器内核复杂度的剧增，是需要精心设计和慎重考虑的，Scintilla、Vim目前好像都是单线程，应该说，单线程对于绝大多数文件而言，性能都是满足的，所以并不是必不可少。更何况在编辑时，着色还有一个更重要的技巧，就是第四个，仅对需要的片区着色，片区的范围是向上搜索当用户当前编辑点所在Style的起始位置，向下一直着色到与上一次着色时类型完全相同为止，对于大多数操作而言，编辑时的动态着色几乎都只是本行内的一小段文本，着色时间甚至可以忽略不计。如MegaxEdit中打开173万行的代码进行括号匹配，插入字符，Lexer分析，依然能够基本正常操作，正是基于此。但是需要指出的是，这里隐藏着一个潜在的危险，即括号匹配，如果没有对括号进行预处理，而是临时动态搜索的话，那么假设173万行只在起始和结束位置形成一对开闭括号，估计MegaxEdit也依然会有假死的现象。而如果采用多线程，则无论用户的编辑会导致怎样复杂的着色和括号匹配，都只需要在独立线程中不断计算就行了，当然这里也暗藏一个小技巧是，如果着色线程向下着色的范围很大，那么当线程着色范围或括号匹配超出当前屏时，先依据新的着色括号匹配更新当前屏幕，然后再继续向下进行。如果同时还实现了分片匹配，则向下也只需要将跨行的元素着色，而无须全部着色，这又必然会大大加速处理进程，因此给用户的体验就将几乎是完美的。

    但提到Lexer，就无法避开Style，Style其实是Lexer的存储标记，有了Style，就可以将Lexer的结果永久性的保存，而无须不断地动态着色，也算是用空间换取时间的一个典型，应该说，几乎所有的编辑器都有Style设计。但是目前Scintilla，以及MegaxEdit存在着独立Style的设计对于内存的需求稍显得多了些，几乎内存消耗都是文件自身的两倍以上，其实完全没有必要的，具体的在编辑器杂谈一中已经较详细的描述了可行的使用动态数组的解决方案，在此就不多赘述了。

    至于文本处理的内核编码，目前市面上内核鲜见有UTF16的，估计Megax此处是弄错了，提及编辑器的内核Unicode化，从编译角度讲，自然是UTF16，因为大多数操作系统，比如Windows，内核就是UTF16，当然不同的操作系统，BE还是LE会有所不同，但是如果是内部处理文本的编码，则编辑器的Unicode内核指的多半是UTF8，这个虽然无法对于商业化软件Editplus、EmEditor进行内部分析得到，但可以从Vim、Emacs上很清晰的了解，Vim应该是从版本6加入UTF8支持的，也许不是很准确，这只是从Vim作者Bram Moolenaar的1999年访谈中提到，具体支持UTF8的起始版本请查询Vim的更新历史。而Emacs应该是23开始支持的。之所以不使用UTF16而是UTF8，原因在编辑器杂谈一中也提到了，对于许多字符集而言，Utf8比Utf16等编码方式要节省内存，比如Ascii直接就可以等价到UTF8中，就编辑器的功能而言，大多数用来编写程序代码，而几乎所有的程序都是Ascii编码方式，当然注释、字符串等特殊元素除外，因此，编辑器内核编码选择UTF8是必要的。UTF16将带来不必要的转换和内存消耗。而对于目前诸如Scintilla的MBCS方案，虽然一样可以处理文本，但是无法更好的识别和处理文本，尤其是非英语类的匹配符号对就无法识别，如中文的书名号《》，而且UTF8的不定长和MBCS的不定长是有很大区别的，MBCS的不定长需要通过操作系统查询对应的码表才能知道当前字节所在的位置是不是字符的Leading，以及当前字符的长度，而这个查询是非常耗时的，但是UTF8直接从当前字节的char值上就可以很容易的判定字符位置及当前字符的长度，这种判定只需要简单的与或，处理速度远非MBCS可比，比UTF16或UTF32的规则字符长度也许或有不足，但处理速度应该基本属于一个数量级，加上UTF8的诸多特性，决定了其是最适合编辑器使用的内码。当然UTF8只能满足于编辑和显示，如果保存时需要转换内码，则还是有可能会有损失的，因此从某种意义上而言，对于CP936的中文编码文件，在内核UTF8的编辑器中编辑时可以任意输入其他语言的文字，但是到保存转换回CP936时，也许并不能完全保证所有的编辑可以全部正确转换，也即不是所见即所得，这也许算是UTF8内核带来的无可奈何的副作用了。不过以exe作为举例则并不妥，因为exe是没有编码的，所以强行转换自然会导致前后不一。而从编辑器的设计角度，打开CP932的文件，无论内部什么编码，不作修改，原样保存，都必须保证前后一致性的，这是编辑器必须实现的一个最最基本的特性，否则必然会导致用户无法信任和正常使用。至于编辑器的其他内存消耗，依据编辑器实现的目标不同而有所不同，行信息一般一个16位int，或者32位long型足够使用了，也就是大约每百万行多2－4兆内存，相对于文件本身，也应该是可以忽略不计的。

    与内存相关的还有文件本身，因此大文件的支持与否便成为判段编辑器是否优良的一个特性之一，对于大文件的定义很难给出标准，但是一般而言，超过本机装配内存大小的文件应该都算大文件，因为大多数情况下，编辑器都是将文本加载入内存操作的，当无法加载时，此时就需要另外的处理能力，而这种处理便是大文件处理。大文件的处理多半是通过文件映射实现的，不过这种方法的缺陷就是当系统更换映射页面时，已经脏了的数据需要写入文件，而频繁的写大文件显然性能不容忽视，另一个可行的便是Megax提到的Piece Table，其实编辑器的核心便是这个，只是这个算法深入理解不太容易，很久以前看过Scintilla的内部实现几遍也没完全看懂，再加上Scintilla内核的内存处理实现得效率很不错，因此暂未有过更新或重新编写的打算，所以也没兴趣再细看，对此也就没有了解和体会，无从分析了。如果以后实践了大文件的操作，再详细描述吧。

    最后感谢Megax提供了Oniguruma更新到5.9.2的消息，国内不知为何Oniguruma的主页被屏蔽了，而且自2007年12月22日以来两年多以来一直没有更新，因此只是跟踪着Ruby中的分支，以为合并到Ruby中不再独立开发了，看到文中提到5.9.2才知道一个月前就更新了，已经下载了，只是看Change Log感觉改动不大，不知道UTF8处理上的一个内存缺陷修复了没有，需要尝试一下才能明确了。不过Oniguruma的c++ wrapper很好写，自己实现并不难。从效率和性能的角度而言，Oniguruma是一个非常优秀的正则库，相对于PCRE等来说一是支持的编码要全，二是普通文本搜索更完善，速度更快。但是与boost中的几个正则库相比，最大的缺点就是没有迭代器，使得无法很好的普遍适用于各种场合，仅仅对一段字符串进行处理对于编辑器是远远不够的，所以要完美的集成到编辑器中，是需要修改源码的，自行加上迭代器，这样就可以通过迭代器遍历整个编辑器，从而更高效的进行搜索了，否则还需要从编辑器中拷贝出字符串，效率很低下。

    不过回到文首的开源讨论，如果有合适的组件和模块，在尊重并符合协议规范之下，还是应该尽可能的站在别人的基础之上进行开发的，知识就是应该分享和共用的，如果别人已经愿意分享了，那么又有什么理由拒绝别人的好意呢？但是当现有组件不适合，或者希望能够有所突破和创新时，就应该鼓足勇气，重新设计并付诸实践，只有这样，才能不断地推动知识和技术向前进步，而如有收获，也应该将收获进行分享，让更多的人来共用，这样才能创造更多，更大的价值，也才能更多的体现自身的价值，任何固步自封、或者只获取而不分享的行为都是不可取的。分享也并不一定排斥经济行为，开发出一流的产品，哪怕是商业化的软件，只要能够给用户带来便利，各取所需，谋生致富都未尝不可，毕竟社会是现实的，软件开发也依然要生存和生活，也正因此，任何无私奉献的开发者也更加值得尊敬。另外分享的途径也有很多，如果曾经受惠于无私的开源，那么至少也应该在需要时无私的回馈开源，恰如IBM、Sun等在利用开源赚取利润的同时，也给予了开源极大的帮助，这是一种真正的良性循环，是对开源和应用都有极大好处的，只有这样开源才能不断发展和壮大。而且并不一定是要有源码才是真正的开源，分享思路和实践经验，让其他人少走弯路，或给予他人以参考借鉴，也算是一种“开源”。这也是最近编写几篇“编辑器杂谈”的初衷了。

  60. 像notepad++这种利用软件平台唱政治戏的，不但违背了自由软件的精神，还变相强奸民意，建议大家抵制到底，从2008年一直抵制notepad++垮掉为止。

      • 你崇拜的理查斯托曼本身就是个开源神棍，产权意识淡薄，G产G妻G软件，深得TG当年神韵，称他为网络GCD亦不遑多让。此人前一段时间玩命捧中科院龙芯，在国内挨踢论坛被你们称作洋五毛，现在居然成了你眼中的反G教父，身份切换速度之快，令人震惊。

        其实我不很在意这个洋五毛的看法，也不收“匪教”的劳务费，如果抵制台独藏独也在五毛职能范围之内，那么在这个问题上，我甘愿作免费的五毛。

  64. 呵呵，真的要再次感谢善用佳软，提供这样一个平台，让同好相聚于此，如果不是这样，恐怕很难看到这样集中热烈的讨论。
    另外也要感谢楼主，正是你的帖子引发了这么热烈的争辩，也许你当初并不这样想吧，但我觉得这挺好的。
    这是个太容易引发口水的问题了，不过我很享受这些口水，哈哈，为什么我这么高兴呢？因为我对编辑器有着很大的兴趣，但并没有什么深入研究。
    对软件，我一般首先看UI，并不一定要花哨，但要不俗，UE那样臃肿的身材我是望而却步的，其次我才会注意功能实用性。
    但这个软件是否能保留在我的电脑中，就要看他的功能性了。功能性不是简单的功能堆砌，同样说到UE，他那种乱拼式的拖拉机风格，我实在是用不关，一堆堆的按钮，我觉得这实在不是用来编辑文本的。
    也就是说，不俗的UI和超凡的功能是我对软件的终极期望。但要做到二者的完美统一，也实在是难。
    所以啊，我一直在苦苦寻觅一个犹如来自极地雪狼般清爽幽幽的编辑器，可想而知，我实在还是没找到。但在很多编辑器，尤其是他们近期的版本中，似乎有了一些影子。比如E-TextEditor,AkelPad,Intype(似乎已经停止更新了)，MadEdit,Sublime TextEdior,SlickEdit，另外，基于Scintilla内核的SciteRu(可惜，中文。。。)都很不错。
    这里我没提到VIM和EMACS，不是他们不好，而是他们实在太好了，到底多好，我也不知道，但看看那繁多的插件，我就知道他的定制性是很强的，但对于我这种不算聪明又不够勤奋的人来说，那只能是个传说，偶尔用用而已。
    我一直希望有一款编辑器能犹如当年的FF横空出世，但繁忙的工作和杂乱的生活让我也没什么精力再自己去挖掘了，幸好有了这里，有了这篇帖子，我终于看到了一款与众不同的编辑器了，那就是zhouzh2提到的HippoEDIT，刚刚看了一下就被他的提示和语法着色以及类似FrieBug或VS那种对HTML代码段以节的方式表现出来的功能所吸引了（表述能力太差，我猜你没去用，看到我这么说会迷糊的，呵呵）。界面还算清爽，但可惜不是我喜欢的那种另类，我喜欢的是E或Intype那种简约清爽的布局。
    哈哈，太高兴了，我要好好研究研究这个编辑器了。另外，非常感谢zhouzh2，如果不是你，恐怕没有多少人知道这款编辑器呢。另外，在诸多回帖中，我觉得您是这方面的高手啊，真希望能提携提携这里的诸位兄弟，有博客或论坛吗？大家最好一起共同进步啊，哈哈，菜鸟对高手总是有这种奢望的。

    • 高手真是不敢当，大学里有段时间空虚的很，又对编辑器有兴趣，就花了点时间研究了下…其实也就是挑了点编辑器试试。
      我能够理解你的心情，在这个年代恐怕只有少数geek和程序员才会喜欢去研究文本编辑器吧，要找到同好是非常困难的…去大学计算机系里问问看有几个知道VIM的就会知道我们这个群体有多小众了。。。
      HippoEDIT最初是我在DonationCoder论坛里看到引发了很热烈的讨论，才注意到的。试用下来确实不错，ddd兄又问到有什么编辑器推荐，就顺带一提。
      我在blogger上有个博客，基本不去更新，被墙以后更是完全放弃了。

  68. 楼主定位为使用，正是引发讨论的根源。所以只有最适合的，无所谓最好的。
    纯粹编辑器技术的讨论实际上不是此帖的目的。
    用途和使用场景的分类，讨论适合的编辑器。更能够减少争执和口水。

  70. EmEditor的作者在官方网站发布了简体中文语言翻译的寻人启事,xbeta帮忙在文章尾巴带个ps什么的宣传下吧:)
    (xbeta注：已与对方联系，收到反馈后再广而告之，组织人员。 )

  71. 用vim一周..做文本编辑习惯性的HJKL..悲剧
    养成了vim的习惯，一辈子就离不开了..
    PS.觉得vim难于入门的可以先用一下vimtutor这个命令（linux下）
    PS2.想继续学习可以使用官方的:help。官方非常体贴的提供了中文版的文档哦^^更值得骄傲的是帮助文档是咱们大陆国人翻译的，哦也

发表回复

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。