Talk:Comparison of text editors/Archive 1

message: It seems that this discussion and article are including information about the editors and features applicable to use in web-editing. Is there any reason why some of the other editors listed in List of HTML editors#Text/HTML editors are not also here?  (TopStyle and Macromedia HomeSite for instance)
Since the Comparison of HTML editors is pointing to Comparison of text editors for all non-WYSIWYG HTML editors, it'd probably be good to cover them here.  Thoughts? jwilkinson 16:36, 20 April 2006 (UTC)
thread_title: Inclusion of other text/code-based HTML editors?

message: Several editors can edit multiple documents by displaying one document buffer and hiding the rest.  This is similar to a tabbed window interface, except no tabs are shown.
Most of the vi clones support such a MDI, including vim and nvi.  IIRC, even traditional vi has primitive support for such an interface.
Although I'm not an emacs user, I believe that XEmacs and GNU Emacs also can edit multiple files in a similar fashion.
Perhaps we need an 'other' column for MDI?  Or we could call it 'tabless tabs'  ;)
(Oopsie -- missed the comment by Smjg 14:34, 11 Mar 2005.  He basically states the same thing.)
Serious suggestion:  We add a 'hidden buffers' column to MDI.
:Yeah, the columns need to be reordered/redefined. In the table, there are some SDI editors with window splitting, but window splitting is placed under MDI. Look confusing. (Can we call them MDI when they have window splitting?) Minghong 09:40, 17 Mar 2005 (UTC)
replies: text:  They should only have a 'Yes' in this column if they actually allow the panes of the split window to display different documents at the same time. -- Smjg 11:22, 17 Mar 2005 (UTC)
thread_title: Ack!  Yet more questions about MDI

message: I haven't changed the 'shell integration' values for vi or vim, but 
doesn't the '!' command (run shell command) count as shell integration for vi/vim?  I left the value as 'N/A', since I may be misunderstanding shell integration.
Could someone please clarify this?
In addition, wouldn't vim's 'visual mode' count as column mode editing, or am I missing something?
:Originally I added "shell integration" for text editors can add items on Windows Explorer's context menu. But now it seems to be not only GUI shell, but also command-line shell... I don't know about vim, but column edit mode refers to the ability to selection vertically . --Minghong 08:50, 9 Mar 2005 (UTC)
replies: text: In that case, the column title should be changed. Many people who use operating systems other than MS Windows will understand "shell integration" to mean the ability to start a shell from within the editor or to insert the output of system commands in the buffer. Burschik 15:22, 10 Mar 2005 (UTC)
thread_title: Shell integration and Column mode editing

message: We should better combine it into one reference of the Emacs manual... --Minghong 20:40, 11 Mar 2005 (UTC)
thread_title: 16 references for just Emacs?!

message: The table shows that EditPlus does not support regex find/replace.  That is false.  I use that feature in EditPlus practically every day.
:Just be bold and update it. ;-) Minghong 09:20, 19 Mar 2005 (UTC)
thread_title:  Small Correction 

message: I just added jEdit to the comparison, but found that for most options were i had to say 'no' there is a plugin available. This is because jEdit is built to provide only core functionality, which can be expanded by plugin, much like Firefox.
Adding an indication like Yes* or Plugin (and/or Script, Macro) for options that are available through plugins,scripts or macro's would give a lot more information i guess
:Add it as footnote then. For example, see comparison of web browsers. --minghong 11:13, 13 Apr 2005 (UTC)
thread_title:  Add an indication for feature available through plugins, scripts? 

message: Under Programming features, I thought that "Brace matching" seemed more correct than "Bracket matching", that is, the feature to match paired "{" and "}" characters, not "[" and "]".  I was going to change it, but I did a little research first.  I found that "Brace" is more American-English, and after looking over Bracket, I found that name is used to cover square brackets, braces, and parentheses as a group.  Most editors that support matching one of these support the others.  So, instead, I merely linked "Bracket matching" to Bracket, so that people could figure out the same thing I did.  I thought I'd share my reasoning here, before someone else makes the same mistake I almost did.  --A D Monroe III 14:24, 21 July 2005 (UTC)
thread_title:  Bracket/Brace matching 

message: Why has somebody decided that ASCII, UTF-8 and UTF-16 are the only encodings worth listing?  Moreover, are there such things as editors that can read a file in a certain encoding but can't save in it?
We also ought to address the issue of Unicode conformance.  This isn't the same as merely supporting UTF encodings.  It also means preserving all Unicode characters and never misdeclaring an encoding.  For example, TextPad is one that isn't Unicode conformant even thouugh it does support UTF-8 and UTF-16.   Maybe add a "Unicode conformance" column under Encoding support or somewhere? -- Smjg 11:06, 16 September 2005 (UTC)
thread_title:  Encodings and Unicode conformance 

message: Just as there are different levels of supporting a given encoding, there are different levels of supporting a given line break style.  Possibilities:
* not supporting a certain LBS at all (e.g. Notepad with anything but CR+LF)
* read-only support - can open files with this LBS, but can't save with it (a few simplistic editors probably do this, including one I've written as a library demo)
* ability to read, render correctly and preserve on saving, but with newly-typed line breaks coming out only in the native format
* ability to auto-detect the LBS and save with all line breaks (old and new) in this style
* letting the user choose which LBS to use
What level of support is required to qualify for a "Yes" in this table? -- Smjg 12:20, 16 September 2005 (UTC)
thread_title:  Line break support 

message: To me this entire article seems to be missing the point. These are TEXT editors. Who cares if I can upload to FTP or write scripts if it takes weeks or months for me to learn the whole feature set? How about stuff like filesize, loading times, learning curve, popularity and the size of the community supporting it?
:Do you mean the filesize of files being edited, or the size of the executable (on all platforms, of both static and dynamically linked binaries)? As for files, these are plain text files, not large documents. Also, popularity and learning curve doesn't make much of a fact, meaning they would simply be biased.
:This article answers most of the questions a programmer / web designer could have about a text editor. Believe it or not, they do care if you can write scripts or upload to FTP. --Parasti 01:35, 15 December 2005 (UTC)
replies: text: Popularity and learning curve make wonderful facts.  It is not biased to suggest that Mac OS X has a weaker community of support than Windows, or that Mac OS X has a much lower learning curve than Linux.  These are clear facts.  It could and should influence people's decision over what OS to choose.  This article is currently aimed at experts and programmers, and is of little use to the majority of users.  There is a disgusting amount of tables, so much redundancy.  This should be reduced to one table with a SMALL selection of important, universal criteria.  Perhaps there could be ONE more table with a small selection of advanced features as well.  No more.
216.198.93.154 17:53, 7 March 2006 (UTC)
thread_title: Missing the point

message: Notepad_Plus_Plus|Notepad++ is by Wikipedian Don Ho, but do not put User: stuff in article Fplay 00:55, 12 December 2005 (UTC)
thread_title:  Wikipedian editor 

message: Currently "Multiple undo/redo" is listed under "Programming features" but I think putting it under "Basic features" would be more intuitive. --Tokek 14:03, 18 January 2006 (UTC)
thread_title:  "Multiple undo/redo" feature 

message: This article is currently aimed at experts and programmers, and is of little use to the majority of users. There is a disgusting amount of tables, so much redundancy. This should be reduced to one table with a SMALL selection of important, universal criteria. Perhaps there could be ONE more table with a small selection of advanced features as well. No more. Klondike 17:55, 7 March 2006 (UTC)
thread_title:  Redundancy 

message: Please add a column for Mac OS 9. A lot of schools etc. must use "legacy software" due to funding limits, lack of technical expertise, and lack of will. 204.108.72.26 21:33, 18 May 2006 (UTC)
replies: text: 204.108.72.26, though I would disagree with this myself, you are encouraged to be bold. ~Linuxerist  E/L/T 03:17, 20 May 2006 (UTC)
thread_title:  OS 9 

message: Bruce Wampler's TVX editor, and its successors, are missing here. Is there a reason? ww 20:54, 19 June 2006 (UTC)
thread_title: Wampler's TVX, VIDE missing

message: This change is in a grey area, I think.  Should editors be listed as supporting the Windows operating system if it requires Cygwin?  At the very least there should be a footnote. -- Heptite (T) (C) (@) 03:29, 27 June 2006 (UTC)
thread_title:  Cygwin = Windows support? 

message: What about editor for Pocket PC platform? Where should it be put?
Sedimin 09:12, 6 July 2006 (UTC)
thread_title:  Pocket PC editor 

message: What is Graphical Shell integration? As a user of EditPad on Windows and TextWrangler on the Mac, I don't really see a difference there. Yet BBEdit is listed as a Yes and EditPad a No (TextWrangler isn't listed in this table yet). While it's possible this is a difference between BBEdit and TextWrangler, I can't really add TextWrangler until I know what the goal of this column is. -- Steven Fisher 18:48, 3 August 2006 (UTC)
thread_title:  Graphical shell integration?