kwrite kate kedit 这三个编辑器有什么不同？怎样配置才能让他们自动识别文件的编码？象

aran

KDE 下为什么会有kwrite kate kedit
他们为什么不把精力放在软件的就加精上
而写三个能办同一件是的东西出来，干嘛要重复劳动。
GNOME下的GEDIT多好！~
是不是KDE下开发软件容易就多多益善？
这不是和UNIX下尽量让一个程序去做一件事，但要做的最好的精神相违背。
这样下去是不是要走WINDWOS下现在的局面，几千上万个软件去干同一件是
弄不好都干得乱七八糟。

我喜欢KDE。也想试着去接近她。可她连最基本的编辑软件都不能令我满意（如我们的文字是拼音，不是汉字就好了。）。把文件的打开和保存都设成GB系列编码，她不能自动识别UTF8编码。设成UTF8编码，她不能自动识别GB系列的编码。

seamonkey

kwrite和kate默认都使用kate-kpart，两者定位不同，krwite低端，kate定位于程序员编辑器。kwrite也可以使用vim kpart作为编辑组件。kedit使用不同的编辑组件，它支持bidi，一旦kate part的bidi支持成熟，kedit将被淘汰。kpart的强大在此体现无疑，数个功能不同的程序，包括Quanta+，kdevelop，kate，kwirte共享同一个kate-kpart，用户使用这几个程序，面对的是熟悉的编辑器设置，gedit和bluefish和anjuta做不到吧，gedit一旦打开文本文件，而编码探测错误，如何重新选择编码？

mep

yeah.
kate和kwrite的Code Folding功能很好，Gedit没有，
对喜欢Code Folding功能的程序员很有吸引力。

realwhz

Post by seamonkey
kwrite和kate默认都使用kate-kpart，两者定位不同，krwite低端，kate定位于程序员编辑器。kwrite也可以使用vim kpart作为编辑组件。kedit使用不同的编辑组件，它支持bidi，一旦kate part的bidi支持成熟，kedit将被淘汰。kpart的强大在此体现无疑，数个功能不同的程序，包括Quanta+，kdevelop，kate，kwirte共享同一个kate-kpart，用户使用这几个程序，面对的是熟悉的编辑器设置，gedit和bluefish和anjuta做不到吧，gedit一旦打开文本文件，而编码探测错误，如何重新选择编码？

gedit探测错误，那就重现打开，打开时指定编码方式

另外，编码检测算法不是万能的，不能保证总是100%正确，没办法的事儿

aran

Post by seamonkey
kwrite和kate默认都使用kate-kpart，两者定位不同，krwite低端，kate定位于程序员编辑器。kwrite也可以使用vim kpart作为编辑组件。kedit使用不同的编辑组件，它支持bidi，一旦kate part的bidi支持成熟，kedit将被淘汰。kpart的强大在此体现无疑，数个功能不同的程序，包括Quanta+，kdevelop，kate，kwirte共享同一个kate-kpart，用户使用这几个程序，面对的是熟悉的编辑器设置，gedit和bluefish和anjuta做不到吧，gedit一旦打开文本文件，而编码探测错误，如何重新选择编码？

我觉得GEDIT在保存时，再选择文件的编码方式很好。如果在写东西的时候，一会儿用GB2312编码，一会用GBK编码，最后这文件不就是混合编码了，是不是有点乱了。希望全球UTF8的时代早日到来！~
目前，我通过SMB访问WINDOWS，用GEDIT去打开共享过来的TXT文件，还没出现过有乱码的现象。
我想用KDE，好看。可是，怎么样才能让KWITE KATE同时自动识别GB系列和UTF8系列的编码？

千里孤坟

KWrite好像是Kate的技术基础，从KDE 2继承过来的，现在它是Kate组件的一个功能子集，在kdebase的源码树中kwrite的部分也是被包括在kate里的，因此它们两者不是相互独立的，还可以共用一些插件，不妨理解为一套软件的”标准版“和”加强版“那种关系。

KEdit则是为了满足最精简的文本编辑要求，尽量避免任何多余功能而存在的（除了在KDE所有程序里都无处不在的拼写检查），它的适用范围很大，对于代码、配置文件等以外的纯文本使用KEdit来编辑往往是明智的选择，例如写些短文、草稿以及处理收集的电子文章之类的。

编码问题，倒不是它们故意作对这样的：
把文件的打开和保存都设成GB系列编码，她不能自动识别UTF8编码。设成UTF8编码，她不能自动识别GB系列的编码。
这三个编辑器都以本地字符集为缺省的文本读入编码，所以才会出现这样看似存心使坏的现象。自动探测功能未被纳入也许是考虑到实现难度和成功率，当然也可能是Qt的短处，所以采取了这一相对稳妥的处理手段。

不过么，它们都是可以在文件选取框里预先指定文本的读取编码，保存时选定一个写入编码的。

如果对Windows环境有经常的信息共享要求，设定locale为GBK编码可以少掉很多烦扰，反之才是UTF-8方便，至少从现状看来。

aran

看来要LOCALE用UTF8而且又不要影响对WINDOWS下一些文件的正常读取，只有用GNOME了。

seamonkey

你就不会重新选一下编码，就在工具菜单中，重新打开都不需要。

前面说过自动探测又不是百分之百可靠的，你可以试试在zh_CN.*的locale下用gedit打开一个BIG5甚至其它任何legacy编码的文件，估计是不会探测成功的。

我觉得kate这样很好。

jhuangjiahua

这些人应该都不看菜单的

aran

老大终于显身了
菜单我是看过的。
kwirte ，kate不是有自动探测的标签，可是为什么不能自动探测？应该在某个地方可以设置的。
当打开一个乱码的文档再去选编码，是不是麻烦了点。那还不如用WINDOWS（我可是个LINUX偏执狂，LINUX一定可以做的比WINDOWS好）。我想没有谁看见乱码，心里会特别舒服的吧。
个人认为：如果用KDE，LOCALE设为GB系列的有意义。可是我要用UTF8