Talk:Comparison of text editors
|WikiProject Software / Computing||(Rated List-class)|
ISO-8859 in Notepad++ v 5.5
Current Version of Notepad++ seems not to support ISO-8859. 25 September 2009.
I would like to propose adding "Hyperlink support" as a column in the "Basic features" comparison chart. Some editors, such as Wordpad, lack what some would consider to be a very basic feature. --Stevoisiak(e) (talk) 18:38, 26 March 2014 (UTC)
Emacs file-size limit
- As usual, you did not read the references. Schily (talk) 11:09, 21 April 2015 (UTC)
- The true Emacs limit on 64 bit systems is 2 Exabytes. The 2GB limit is not due to Emacs.
- http://git.savannah.gnu.org/cgit/emacs.git/tree/src/buffer.h#n307 * http://www.gnu.org/software/emacs/manual/html_node/elisp/Integer-Basics.html * http://www.gnu.org/software/emacs/manual/html_node/emacs/Buffers.html#Buffers * http://www.emacswiki.org/emacs/EmacsFileSizeLimit * https://lwn.net/Articles/272027/
I just tried opening a 2GB zip file in 64-bit Emacs 24.4.1 on a 2GB Debian vbox and got a "memory exhausted" error (not max buffer size exceeded). Opening a 812.7MB zip file succeeds, parses the archive and shows the dired buffer. Opening a temp buffer and using insert-file inserts the file contents successfully. On an 8GB Windows 7 using the latest emacs-w64 from , the same two operations succeed with the 2GB file. Maybe the file[s] you were trying to open were executing an emacs mode that caused it to fail some other way. I remember there was a problem and I even tried to use truss to find the reason for the failure. It was neither limited /tmp size nor limited memory. For me an editor supports large files if the default compilation creates a binary that is able to deal with large files. This is true for VED but not true for emacs - if I understand you correctly, you need to manually modify the buffer size before compilation - right? Schily (talk) 16:49, 21 April 2015 (UTC)
- No, I did not modify the max buffer size, this is standard. I built the Debian Emacs myself; the only customization I made was to disable X and sound support, and maybe to enable inotify support (it's a new feature that I wanted and I forget if it was enabled by default when I built).
File size limit for editors in general
It seems that many editors have a wrong file size limit in the table. VI e.g. limits it's swap file to 128 MB by default and this results in a limit of aprox. 65 MB for editable files.
VIM definitely does not support large files, as it does not open files in large file mode. It is not clear what the real size limit is today. In 1995, it was less than 5MB. It seems that the file size is limited by the available RAM. So a 32 Bit VIM is expected to support less than 2 GB.
The only large file editor I am aware of is VED. For this reason, it seems to be wise to request references to verify large file support for the other editors mentioned in the table. Schily (talk) 11:06, 21 April 2015 (UTC)
Manage of binary files
In some sections of features should appear something like "Manage of binary files" and depending on the editor could be indicated as:
- Text only (the program reads only up to a point of a binary file or directly not open it showing an error).
- Hexadecimal (if it is a binary file, then show it as in a hex editor).
- Gibberish characters, but textual parts are readable (as this).
The idea arose from this discussion in which you will notice that many text editors for Linux (especially those with graphical interface) work as in item 1. — Preceding unsigned comment added by 22.214.171.124 (talk) 03:24, 28 April 2015 (UTC)
- There is also whether the editor is round trip compatible - whether saving the file alters the binary data in any way, regardless of how it's displayed. TextMate isn't.