2008-08-10 11:17 |
@沈臻豪(foxtail)
悠久的是UE,不过UE的内核不是Unicode,这点很让人失望。我经常需要在中日英之间切换,Unicode是必须的。而且UE的版本更新太快,启动内存20M,不小啊。EM的最新版本比较强大,对于超大文件有着非常好的支持。基础架构也比较好,语法扩展也很方便,内核支持Unicode,插件架构比较好。如果非要选一个比较好的,我认为是最新版本EM。我以前一直用Editplus,不过它更新的很慢,有些功能做的也不尽如人意。我想做的就是集这几家所长,最主要的是我想提供一个命令工具,像vi那样,这个非常有用,我认为。
回复 更多评论
2008-08-10 21:26 |
嗯,我试用了,做的还不错。scintilla可以直接定义document的encoding,这样就解决了unicode的问题,嗯,不错,scintilla很强大。压力很大,我得加快进度了,在基础控件上得加把劲。用户使用感觉上也得加油。flexedit似乎是个中国人写的,里面的command实现的挺有意思,我是费了劲使用管道输入输出重定向来实现的,它倒好,直接嵌入了ConsoleWindow。另外它似乎没有实现打印,呵呵。目前在国内真正让我佩服的中国人做的编辑器是LiteEdit,它已经很长时间没更新了,作者功力不错,网上可以找到源代码。其它的编辑器,还没发现中国人做的太好的。欢迎继续讨论,有任何问题,都可以讨论,呵呵。
回复 更多评论
2009-03-25 12:12 |
很期待这款编辑器,我觉博主是不是可以考虑放出一些版本来让大家试用了
其实骂声能够促进进步的
如果决定opensource的话,可以先放在googlecode上呀,多一些人来修改BUG,博主也好其中精力在核心开发上
我一直在找一款轻便又方便的编辑器
回复 更多评论
2010-02-23 12:03 |
@AptEdit
很荣幸能得到您的评论.
前阵子过年了,没来得及回,不好意思。
试用了您的AptEdit,确实很不错。本人也浸淫编辑器数年,因此就不在拍马屁了,呵呵。
AptEdit在基础架构上似乎有点性能问题,尤其是光标的定位。在打开《鬼吹灯》这篇小说时候在文章头部
进行插入删除操作的时候会感到明显延迟。在进行较长的行自动换行的时候也可以明显地感到延迟。我想可能
是你光标定位算法或者判断重绘区域较为缓慢所致。我猜测你可能用了行链表结构。因此也导致了打开较大带文法的文件
的时候进行光标滚动会感到明显滞顿。呵呵,瞎猜的
另外,保存行状态(正常,编辑过,保存过)你可以用bitset,这样你就可以不用让修改该过的行即使撤销也依然显示红色了,还节省内存。
你的词法分析做的挺不错的,我为了图省事,当遇到影响下一行的状态的时候会一直往下分析直到该行状态不变为止。
在外观上AptEdit应该尽量simple, 我不太喜欢重绘过的Menu. 现在流行的秀丸,Editplus, EmEditor, sakura啊,都极其简洁。
所以我现在也在考虑做成单进程多线程的,看起来是SDI,但是只有一个实例,就像WORD那样。我对编辑器外围的这些东西不太感兴趣,所以这么多年了
一直研究编辑器本身,不过坦白的说做外围的这些条条框框还是非常麻烦的。
很高兴看到AptEdit开卖了,不知道卖的如何啊,可以的话,我也打算拿出来卖,MegaxEdit的平均性能还是刚刚的~(笑)
Best regards.
回复 更多评论