Club Silencio

Orph, I (obviously?) do dot agree.
Let me elaborate why.

• Let’s start with the obvious: the “features”. And no, I’m not talking about syntax highlighting, plugins, etc, I’m talking about printing, spell checking, vfs support (which finally is read and write in the new_mdi branch), etc: all these features are IMHO something that every gnome application must have.
• The attention to detail: I proudly think that gedit is one of the most compliant gnome apps to the HIG and to the accessibility requirements. The same attention to details is there under the hood: a text editor is not a matter of sticking a TextView and a Menubar in a Window, gedit takes great care in handling file save properly without screwing your data, using backups, handling different file encoding and all the small things which may not be abvious at a first look. I cannot say the same about many of the other editors I looked at.
• Reliability: gedit is probably the most tested app of the ones included in the desktop, this was quite clear to me when we switched to GtkFileChooser: I don’t have stats but a large number of the file chooser bug were reported through gedit. Fragments of gedit code are pretty much everywhere in gnome and often gedit is the reference used for “How do I do that?” and this is my opinion an indication that gedit code quality is pretty good. From my limited experience fixing the UI may be hard but fixing the code is way harder

So let’s get back to your post: It seems to me that your gripes mainly get down to:

• Tabs
• Slow start up

Tabs are a controversial issue: we get *lot* of feedback from people saying that they love tabs and they are used in similar places in many gnome apps and also in many others general purpose text editors even on Windows (UltraEdit, EditPlus, etc)… however we do see your point, and in fact we discussed it many times internally: IMHO a good trade-off would be to hide the tab when just one document is open, but that’s just me.

With regard to the slow start up, I cannot do nothing but agree… I fact I think that slow start up accounts for 90% of the perceived complexity of gedit vs leafpad. What we need to do is fix it. 2.10 is faster than 2.8, and the new_mdi branch is faster than 2.10, but any help here is appreciated.

With regard to syntax highlighting and plugins, I’ll keep it short for now: I don’t think they expose complexity to the user (you click on a simple text file and you don’t even know about SH and plugins are there to hide complexity, firefox extensions show they are a good way to do this)

Since I have the rant-mode activated, I’ll also give a larger perspective on why a default text editor for GNOME should be more similar to gedit than to leafpad.
GNOME user Vs Text Editor user: while a text editor surely has it’s place in the desktop, I don’t think that they target the same average user. Every time the average GNOME user fires up a text editor means that we failed somewhere and that we need an appropriate application (for instance Tomboy rocks for note taking and editing /etc/foo.conf should definately not be needed for a user).
It seems to me that the use case you are advocating is: “let’s have a quick and dirty text editor to edit /etc/foo I use emacs for the rest anyway”, what we want to achieve with gedit is not “gemacs”, gedit is not a programmer text editor, but a *uselful* *general purpose* text editor to do real work in it without having to learn emacs or vi, suitable for latex, for html, for simple programming (if you are not the emacs or IDE type) and for composing good old text files :)