Talk:Comparison of text editors

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Software / Computing  (Rated List-class)
WikiProject icon This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 List  This article has been rated as List-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.

ISO-8859 in Notepad++ v 5.5[edit]

Current Version of Notepad++ seems not to support ISO-8859. 25 September 2009.

Emacs file-size limit[edit]

The given source mentions size only for 32-bit systems; the comment regarding 64-bit systems is unsourced. TEDickey (talk) 09:27, 21 April 2015 (UTC)

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.
??? I have never been able to edit files > aprox. 500M even with a 64 bit Emacs and this was on the same system where I could edit a 6GB file with no problem using VED. Please give a reliable source for your claim. Schily (talk) 14:38, 21 April 2015 (UTC)

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 [1], 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[edit]

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[edit]

In some sections of features should appear something like "Manage of binary files" and depending on the editor could be indicated as:

  1. Text only (the program reads only up to a point of a binary file or directly not open it showing an error).
  2. Hexadecimal (if it is a binary file, then show it as in a hex editor).
  3. 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 (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.
Yea, vi edits binary files but shortens "lines" and removes null bytes. In 1982, working editors have been EMACS from James Gosling and VED from UNOS. Not sure which editors today are OK as I use ved ;-) Schily (talk) 12:46, 28 April 2015 (UTC)

What about VS Code?[edit]

-- (talk) 16:05, 13 June 2016 (UTC)

+1 for VS Code, it's gained widespread adoption and is arguably one of the better-known and more successful TypeScript projects. It's notable enough to have its own Wikipedia page, and because it's (apparently) not derived from any major previously existing editor, I believe it deserves a mention here. Julesmazur (talk) 15:14, 8 November 2016 (UTC)

VS Code is primarily an integrated development environment, which happens to have a source code editor. Those are specializations which make it fit under one or both of those topics, but not really as a text editor. As usual there's other stuff (about a quarter of this page could be trimmed without losing anything relevant to the topic). TEDickey (talk) 21:04, 8 November 2016 (UTC)


The section named localisation has less than 20 languages in the list. Nowadays, most softwares, especially text editors come with localisation support for 50+ languages. It would be difficult to add all those languages in the columns and the table will be too long. So, It would be better to write the supported languages next to the editors If there are many languages, say 60+ a short text like 60+ languages in the cell would suffice. -தமிழ்க்குரிசில் (talk) 15:49, 6 July 2016 (UTC)