[Geany] remembering folding status

daspostloch at googlemail.com daspostloch at xxxxx
Fri Sep 18 13:06:59 UTC 2009


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 at 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 at gmail.com>:
>> On Friday 18 September 2009 04:19:04 am daspostloch at 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
>>
>>
>>
>>
>> _______________________________________________
>> Geany mailing list
>> Geany at uvena.de
>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
>>
> _______________________________________________
> Geany mailing list
> Geany at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
>



More information about the Users mailing list