gnotepad+ FAQ (with answers!)

How do I?

To drag a file from gnotepad, click and hold the "File Info" button in the lower right corner of the window. While keeping the mouse button pressed, moving the mouse away from the "File Info" button will change the mouse cursor. This indicates that you can now "drag" this document to its destination.
To drop a file to gnotepad, simply drag from your destination (e.g., a file icon in your file manager) and drop it anywhere on the gnotepad window. The application you are dragging from must support Drag-and-Drop in order for this to work.

The short answer: you probably have a file that has been saved/edited under DOS/Windows. You will need to run a utility such as dos2unix to convert the file from DOS/Windows.
The long answer: DOS/Windows (text editors) use a carriage return and line feed combination to denote the end of a line of text, while Unix systems use only the line feed. Hence, there is an extra character, the carriage return, more commonly known as "Control-M" (^M). These ^M characters should be removed before editing with gnotepad.
An even longer answer: This isn't a gnotepad limitiation; it is actually a limitation in the GTK text widget, and hence, GTK itself. You will see this behavior with other editors which use the GTK text widget.

The exact cause of this probably is still unknown. However, a work-around exists: you must recompile gnotepad from source, and specify the "--disable-docunload" option to the configure script.
A more detailed explanation: document loading and unloading helps gnotepad reduce memory usage. When switching between documents, if a document you are switching away from has not been changed, it can be unloaded/freed from memory. When you switch back to it, it is reread from disk. If the file is sufficiently large, there could be a noticeable delay when the file is loaded, but for most editing jobs, it isn't noticeable. As far as gnotepad crashing, in every instance that the problem is seen, the symptoms point towards document loading. Hence by disabling the document loading feature, documents are never unloaded from memory.

gnotepad always uses the current directory from where it is executed. Hence, if you are starting gnotepad from the command line, you can simply change your directory and then execute gnotepad. It will then start from the new directory.
If you are not starting gnotepad from the command line, you are probably starting it from a menu or icon. In that case, it is up to the configuration of how gnotepad is executed/launched from that menu or icon. This differs from system to system, so refer to your desktop documentation on how to change this.

Under certain configurations, text typed will appear extremely slowly in the gnotepad window. Typically, it will be a lot slower than the actual typing! This is a side-effect of using a very fancy GTK theme. The solution is to either not use a theme at all, or try changing to a less fancier theme.

This is probably the most requested feature. Currently, there are no plans on adding such a feature to gnotepad. The reason behind this is that gnotepad leverages its editing capabilities on the GTK text widget. Since the GTK text widget doesn't have syntax highlighting, neither does gnotepad.
If a new GTK text widget comes along and has syntax highlighting, then naturally, gnotepad will have it too.
One might suggest of using a different widget, such as the GtkEditor widget, or the GtkExText widget. Older versions of the GtkEditor widget was a terrible hack, in that it required patching the GTK text widget itself, and it didn't work very well. Newer versions are still based on the GTK text widget, and is not a feasible, nor workable solution. The GtkExText widget, although pretty on the surface, is also a terrible hack that is based on the GTK text widget. The code is also heinously unmaintainable by anyone else other than the author.
The prudent user may notice that the Bluefish HTML editor has syntax highlighting (sort of), and that it only uses the GTK text widget. However, closer inspection will reveal that the solution implemented in Bluefish is extremely inefficient; memory consumption is huge, and speed/performance is terrible on all but the most trivially small files. This is not an acceptable solution for gnotepad.

There is no indicator of cursor positioning (e.g., which column of text the cursor is on), or line numbers (e.g., which line of text in the file the cursor is on). Unfortunately, this limitation has to do with the GTK text widget again. Solutions to do this with the GTK text widget may be possible, but they would be inefficient.

Again, due to limitations of the GTK text widget, this is not available by default. Any solution using the GTK text widget to implement auto-indentation would be inefficient.

gnotepad is a text editor, not a spell-checker. If you want to spell-check your document, you should use a spell-checker. e.g., ispell. In the future, there might be an interface to ispell within gnotepad for easier accessibility.

Through the GTK text widget, gnotepad has word wrapping. That is, words are wrapped to the next line in a visual manner on the screen. The line itself is not wrapped. e.g., there is no carriage return and/or line feed inserted for you to break a long line into two lines. Line wrapping is a feature typically found in word processors, which gnotepad is not.

There are no plans of gnotepad+ having plugins because plugins are stupid. gnotepad+ is a text editor, nothing more. Running a plugin requires forking/starting a new process. Unless you are manipulating an extraordinary amount of data, this is highly inefficient and a waste of time. There is no need superfluous junk like decimal to hex number convertors (which should be done by a calculator), zvt terminal windows (which should be done by a terminal emulator), or dumb little toy programs to reverse or encrypt the text (nice programming exercises, if you are still in school, but of no practical use).

gnotepad+ is a text editor, not a word processor, so will not support having multiple fonts within the same document.