Hi,
Another 1.5c. It was more fun to think about this than what I'm supposed to be doing, especially as g++ just gave me a 75 line error message (and all it wanted to say was I had an extra const that I shouldn't have)
From past experience in another system, I think the problems that Neil
is worried about are that folds are on a per line basis (confirmed by looking at the interface), but of course any saved fold data is garbage if the lines in the file have changed.
As Neil points out thats hard enough when only worrying about in-memory views, its really difficult to ensure when relating saved fold lines to an external file. You must ensure that the file hasn't changed in a way that invalidates the fold data.
The fold data therefore needs to save a suitable signature of the file to decide on its validity, I guess mtime is the minimum or some MD5 or SHA signature on the contents.
And there needs to be a way of finding the fold data for a particular file, maybe same pathname with an added extension would do, (eg /home/fred/fred.cpp.fd~ ,the ~ so it would be ignored by VCS). That is if you don't mind such files littering your src directories. If its not in the same directory it gets a little bit harder still.
Once this is "solved" it would be easy to do it in Geany, just read the fold status per line using sci_get_fold_level & sci_get_fold_expanded and reset them later with sci_toggle_fold, oh and save and restore what you read to file :-)
Cheers Lex
2009/9/18 Randy Kramer rhkramer@gmail.com:
On Friday 18 September 2009 04:19:04 am daspostloch@googlemail.com wrote:
where would I have to start? i'm a computational guy, so i know nothing about coding for geany, graphics, gtk, scintilla, etc.
I'm sure you'll get much better answers from others, but I just want to throw in my $0.02 (or maybe $0.03).
- That is a feature that I'm interested in as well. Maybe someday I'd
be in a position to help, but for now I have my hands full trying to write a lexer in a language I've, for all practical purposes, never used (C++, nor have I "really" ever used C).
- I'm not 100% sure about all I'll write here, but, iiuc, Geany uses
the Scintilla widget, and things like lexing and folding are mostly handled by the Scintilla widget. For at least two reasons, I'd suggest (and recommend) that you look into making the necessary changes at the Scintilla level, and thus I'd suggest you go to the Scintilla site, join the Scintilla mailing list, etc. The two reasons--it seems like the appropriate place to make the change, and, if you make the change there, it should be easily adaptable to geany and any one of the many other editors that uses Scintilla as its editing widget.
Aside: I'm not clear on how much work it takes to adapt a version of Scintilla with new features to an existing editor like Geany--I know there are some differences that have to be dealt with somehow--just as a potential example, SciTE (the editor that Neil Hodgson has built based on Scintilla) uses property files to store various "property" settings, but Geany uses a different file and at least slightly different approach--iiuc, the geany files are the *.conf files, and filetype.* files.
Neil Hodgson, the lead developer / maintainer of Scintilla is interested in almost the same thing--quoting from two web pages on scintilla.org:
from http://www.scintilla.org/ScintillaToDo.html:
"Persisting view state such as current folding into a stream or blob so it is easy to restore."
from http://www.scintilla.org/Future.html
"View state save/restore
"It has been pointed out that folding does not stay when you change buffers in SciTE. This is because folding is stored in the view rather than the document to allow multiple views of one document to have different folding. Other applications also use the same approach as SciTE of having one Scintilla view object and switching any of the open documents into this view to make them visible. Scintilla could have a way of persisting all internal view state into a string/stream/blob that can be given back to Scintilla to ensure its view is in the same state as when the blob was retrieved. This feature would, for ease of implementation, only work where the document had not changed between the view state save and restore and would also not allow real persistence such as to a file."
With respect to the final comment about not allowing "real persistence such as to a file"--that seems to be the limit that Neil is setting, but there's no technical reason that, especially once it's in a blob, it couldn't be stored in a file. It is probably important that the document "had not changed between the view state save and restore", and you'd have to take steps to confirm that it hadn't (or understand the consequences).
I'm being pretty vague here--I had thought about this somewhat (not so much for Scintilla/Geany, but for any editor) once upon a time. When my memory clears a little, maybe I can elaborate a little more. For, now, I'm just encouraging you to look at making the necessary changes at the Scintilla level so they are available to a wider audience.
Randy Kramer
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany