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.

Add "Hyperlink support" to basic features[edit]

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)

Sed?[edit]

sed? — Preceding unsigned comment added by 86.130.100.102 (talk) 07:26, 13 May 2014 (UTC)

It's not discussed in the main topic TEDickey (talk) 08:01, 13 May 2014 (UTC)

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 181.110.89.159 (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)