Hi,
would it be possible to remember the folding status for all open files (or all files in the recent file list) ? Each morning, I find myself folding away for a couple of minutes until happy with my files :)
Best, Matthias
daspostloch@googlemail.com schrieb:
Hi,
would it be possible to remember the folding status for all open files (or all files in the recent file list) ? Each morning, I find myself folding away for a couple of minutes until happy with my files :)
Best, Matthias
That would indeed be a lovely feature.
Best regards.
On Thu, 17 Sep 2009 15:33:56 +0200, Thomas wrote:
daspostloch@googlemail.com schrieb:
Hi,
would it be possible to remember the folding status for all open files (or all files in the recent file list) ? Each morning, I find myself folding away for a couple of minutes until happy with my files :)
Best, Matthias
That would indeed be a lovely feature.
As usual, someone needs to implement it :).
Regards, Enrico
where would I have to start? i'm a computational guy, so i know nothing about coding for geany, graphics, gtk, scintilla, etc.
On 9/17/09, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 17 Sep 2009 15:33:56 +0200, Thomas wrote:
daspostloch@googlemail.com schrieb:
Hi,
would it be possible to remember the folding status for all open files (or all files in the recent file list) ? Each morning, I find myself folding away for a couple of minutes until happy with my files :)
Best, Matthias
That would indeed be a lovely feature.
As usual, someone needs to implement it :).
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
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).
1. 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).
2. 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
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
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
Hi,
As you say folding isn't fatal (Geany has a unfold all command as fallback) so if the world can accept an occasional dud fold then its much easier.
I didn't think saving the folding in the geany.conf was a good idea because of the potential size increase and the increase in the number of times its read and written all makes for more chances for things to go wrong in a critical file. Instead maybe a geany.folding file in the same directory, then if its broken it can just be deleted.
The g_key_file format that Geany uses does allow for lists but I'm not sure how long they can be, the documentation suggests one line, but I'm sure I have seen lines continued with . But the number of sections and the number of keys is unconstrained, so, if the folding data is in a separate file, then you can have a group per file and a key per folded fold, no need to remember expanded ones thats the default.
e.g.
[file_0] filename=/home/geany/projects/geany/src/folding.c fold_123=true fold_234=true [file_1] filename=xyz.py fold_12=true
The palaver with groups named file_n is because g_key_file does not allow UTF-8 for groups or keys, only ASCII. But key values can be UTF-8 so the filenames must be values not group or key names. The number in the key is the line number, that makes each key in the group different Having the true is redundant but it allows saving the expanded fold points as false if some need arises.
Now it just needs someone to implement it :-)
Cheers Lex
PS <utopia> You are not thinking utopian enough, I want a standard interface between editors and compilers/interpretors so that:the compiler can be run in background and interfaced to by the editor for structure, syntax, completions etc, after all, while I'm editing, those extra cores are just twiddling their electronic thumbs, so lets make them work running the compiler in parallel. Then:
- the editor understands the language as well as the compiler does, including things defined in header files, template instantiations etc. - completions can be only what is legal at that point in the language - the same for function declaration tooltips - *subtle* error indicators can be available immediately (eg margin marks with tooltip messages) - compilation is complete by the time I've saved the file - and the linker, running on another core, is complete too - no need to define languages in the editor, any language with a compiler with this interface is immediately defined
Maybe if Enrico & Nick talked to the GCC guys :-D
</utopia>
On Sat, 19 Sep 2009 11:38:39 +1000, Lex wrote:
Hey,
I didn't think saving the folding in the geany.conf was a good idea because of the potential size increase and the increase in the number of times its read and written all makes for more chances for things to go wrong in a critical file. Instead maybe a geany.folding file in the same directory, then if its broken it can just be deleted.
Yes, I also think this should *not* go into geany.conf. Rather these information should go into ~/.cache/geany/foldng_state or something similar. Though I'm not sure whether it's better to store these information into one file or whether to split them into many small files (as it was also already suggested). Having them all in one big file is probably the easiest way but as you can't do much cleaning of old items (e.g. files which were opened once and then never again), this file can get very big very quickly. So, having the per-file fold information in separate files in ~/.cache/geany/fold-state/ or something, at least the user can easily clean old or even all fold information. OTOH, then there is the question about the filesystem and how good it handles many small files. But probably that's not such a big issue nowadays.
Regards, Enrico
Enrico Tröger escreveu:
Yes, I also think this should *not* go into geany.conf. Rather these information should go into ~/.cache/geany/foldng_state or something similar.
It should be *in the same* directory as eany.conf, not a fixed directory.
One very important feature os geany it to be able to change the config directory and thus have it personalized for each projects needs (and for easier backup)
just my US$0,02... Alain
Am 18.09.2009 14:17, schrieb Lex Trotman:
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
This breaks on just resaving/touching the file.
or some MD5 or SHA signature on the contents.
That means external dependencies.
Really, the easiest and simplest way I see is to store the line number if the folding mark and the content line. Then iterate through all line numbers, and strcmp() the content with the dumped one. If it doesn't match -> don't fold. That sounds pretty save to me-
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.
I think a single file would be most easy to handle.
i got a statement from neil on the state of folding remembrance in scintilla and wanted to share:
There is code in SciTE in the FoldState class in scite/src/SciTEBase.h for storing folding of buffers that aren't shown. There is also code in scite/src/SciTEBuffers.cxx for saving and loading this from file: search for "session.folds". SciTE only allows a single view on a file.
Neil
wont be looking into this for the next 3 weeks, but thanks to everyone for laying out the roadmap :) - matt
On 9/21/09, Thomas Martitiz s0523936@htw-berlin.de wrote:
Am 18.09.2009 14:17, schrieb Lex Trotman:
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
This breaks on just resaving/touching the file.
or some MD5 or SHA signature on the contents.
That means external dependencies.
Really, the easiest and simplest way I see is to store the line number if the folding mark and the content line. Then iterate through all line numbers, and strcmp() the content with the dumped one. If it doesn't match -> don't fold. That sounds pretty save to me-
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.
I think a single file would be most easy to handle.
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany