Re: [gnotepad-users] gnotepad+ 1.3.0pre4 (April-25-2000) - some thoughts

[Andy K. <ac...@ne...>]

Dermot,

> 1) The 'Apply' button in the Preferences dialog did not apply the changes
> and I had to restart gnp to make changes (eg the editing font) happen. 
> This was the first time that I ran gnp and it seems OK now.

Odd; I can't seem to reproduce this.


> 2) The GtkXmHTML (doc) does not reflect unsaved changes made to the HTML
> even though the GtkXmHTML (window) seems to.

This was (somewhat) intentional.  The way the code is currently
structured, it is easier to create a new document by simply rereading
the file from disk than to make another copy of what's (unsaved) in
memory.


> 3) Undo stops working after inserting from the HTML menu (eg Title).

Ah.  This is indeed a bug.  I believe it was introduced by the fix to
this bug (from the ChangeLog):

	- fix: repeated undos after HTML tag insertion on highlighted
          characters results in a crash (James LewisMoss).

Looks like we'll have another new (beta) version to test in the near
future...


> 4) I could leverage all your good work in a little app that I am writing
> if I could tell gnp to open another document (tab). I realise that I can
> start a whole new gnp each time but I think that it would be cleaner to
> have all the open docs available in one place.

This type of request has come up a few times in the past.  Most
recently, I responded on the mailing list:

	> The second is dividing background process (as emacsserver) and
	> opening documents command (as emacsclient).
	> Background process always running, and open buffer windows on
	> users demand. It would be useful for those who has "opening many
	> window" editing style.

	There have been a couple of requests for this in the past.  Again,
	it's a tradeoff.  I see this as useful only if gnotepad gets large
	enough such that starting another gnotepad process is really time
	consuming.

	Currently, I don't feel that gnotepad is large enough to justify this
	feature, but if gnotepad evolves (mutates?) into a more complex and
	robust editor, then this feature would certainly be needed.


> 5) Is it possible to show the full path name of the documents somewhere?
> Either a tooltip over the tab label or a status bar message would be good.
> Also the recent files menuitems (or a tooltip?) - I get lost with 6 files
> called 'index.html'.

The full pathname is show in the window title for the current
document.  Without taking up a lot of screen space, there's no good
way to display the full pathname for *all* opened documents.  I'll see
if a tooltip and/or a statusbar message can be done though.

As for files in the recent menu: I think displaying the full pathname
can be a good feature to be added as an option (in the preferences).
Some people simply don't want to clutter the recent files menu with
obscenely long paths, but others need it.


> 6) I have seen this warning several times - I don't know when.
>   Gtk-WARNING **: gtk_signal_disconnect_by_func(): 
>     could not find handler (0x8053F50) containing data (0x81C9380)
> 
> 7) I have seen this - again I don't know what caused it:
>   GLib-CRITICAL **: file gmain.c: line 500 (g_source_remove): 
>     assertion `tag > 0' failed.

Hmm, please keep an eye on this in the future.  I can't determine
exactly when those messages are produced.


> 8) What about a simple signal handler for a GtkXmHTML (doc) 'activate' to 
> load and raise the clicked URL (if it is a local HTML file)?

I'd prefer to keep browser-like features out of gnotepad+.


> 9) I know that syntax highlighting is a lot of work to achieve but I have
> done some HTML pseudo-highlighting (in perl) with the sub below. Perhaps
...

Please refer to a prior email sent to the mailing list titled "Future
version(s) of gnotepad+".  I make some comments about adding syntax
highlighting.

regards,
--andy