Hm, hm.. good to learn about all this.. As I said before, this is not my home playground at all, but for me the following makes sense:
Do not store the folding status in src (i can hear the uproar in my mind already), but rather in some other place where viewing-history-related stuff lives. had the suggestion for scintilla-level not come, i'd have voted for a [folding] section in geany.conf, right below the recent-files-section.
in it you would have as many arrays/lists (of some sort and of unconstrained length) of integers as you have recent files. integer number i in array Y then means:
IF (editor starts up with (or opens) recent file Y AND the file Y has a possible folding point at line i) THEN fold the darn thing up at line i.
ELSE IF (it doesnt have a valid folding point possibility at line i) THEN it means the folding stuff is corrupted, i.e. the file has changed with something other than geany. in this case, both things are ok to do: erase _all_ folding history for recent file Y (present it unfoldedly) or ignore that and try if any other folding points match.
The folding information should be saved if the last instance of a recent file is closed.
Basically, this means that your folding information gets lost if you do an SVN update (no free lunch here) or if you commited the blasphemy of not editing with geany (well deserved here :) or that you may get incorrect folds if either svn or alien-edit by chance preserved any (or all) folding possibilities at the same lines as before the edit.
but the important thing is that - i think - nothing really can break, so you don't need to check for file changes/status. if there's s.th. to fold, fine go ahead. if there's not, well, the worst thing that can happen is that you get the state you now get when firing up geany or that s.th. is folded you did not want folded before an alien changed the file.
but this sounds well acceptable to me, doesnt it?
best, matt
P.S. @lex: same for me: 2 days of gdb and folding suddenly becomes VERY important :)
P.P.S. <utopian mode> as the topic of .fd~ files has come up, let me share a brief vision: it has never occured to me why not ALL code whatsoever should not be one pure code file and another one for comments, where the comments are "anchored" in the pure code and all editors/IDEs would have a horizontally split window with code left and comments right. some standards regulations body would then define a standard for code folding information for both code and comments along with other practical stuff to be used across IDEs. </utopian mode>
On 9/18/09, Lex Trotman elextr@gmail.com wrote:
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
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany