[Geany-devel] Persistency

[Stephan Aßmus]

Am Montag, den 15.12.2008, 22:33 +0100 schrieb Enrico Tröger:
> On Mon, 15 Dec 2008 22:09:16 +0100, Stephan Aßmus <superstippi at gmx.de>
> wrote:
> 
> 
> >> >> > persistency information were stored with each individual files
> >> >> > instead? Can't file metadata/attributes be used for this? (That
> >> >> > being said, I don't even know if Ubuntu has xattr support turned
> >> >> > on by default...) That method would be much more robust and
> >> >> > scalable.
> >> >> 
> >> >> Not sure if it would be portable then.
> >> >
> >> >I think the Linux kernel will support it through an emulation
> >> >layer, if
> >> 
> >> Cool if Linux does this. What about FreeBSD, NetBSD, OpenBSD, HP-UX,
> >> Solaris, Windows, MacOSX, ...?
> >
> >My argumentation is simple: 1) Persistency is a must-have, certainly
> >for cursor and scrolling offset. 2) There is no other way, really, to
> 
> which we already have for session files and projects.

I may still have some confusion left about what projects are, if it
means Geany will store the persistency info for files which are
currently not open, then you are right as far as that goes. But I simply
want it for any file I touch... :-P

> Additionally, cursor position and scrolling offset is mostly the same
> or better, a set cursor position implies scrolling it into view.
> (Except the case where the cursor is outside of the shown text part
> but it is rather weird to make this persistent.)

I think "persistency" needs to be taken as seriously as possible. I said
Linux is quite good and I really mean it, it's much better than Windows
for example. But it currently drives me mad with it's violations against
various persistency rules. For example, Nautilus does not remember what
sub-folders exactly I have expanded in a tree view. It doesn't even
remember this when I simply collapse and expand the same folder with no
other action in between. Windows/Programs pop up at "random" places, not
where I left them (I know, it's trying to optimize the screen
real-estate, but...). Session management is not turned on (in Ubuntu) by
default, and if you turn it on, it mostly does not work. The list goes
on and it really drives me nuts.

If persistency is implemented for the text files that Geany opened, it's
about "getting them back *exactly* like I left them". That means scroll
position, too. It's about not screwing with spacial memory.


> >store it elsewhere than with the file itself. Since you cannot modify
> >the actual file contents, meta-data is the only option. If you know of
> >any better way, which also supports systems that don't support file
> >meta data... the alternative - no persistency - is really not an
> >option for me.
> 
> I basically agree that meta-data is the best solution in theory. I'm
> just not sure how portable it is but as you said it's probably better
> than I assumed. Though it still fits better in a plugin than in Geany
> itself.
> I know such a feature from Mighnight Commander which stores cursor
> positions per file in a file in its configuration directory.
> But of course, this has the problems you already mentioned (no
> cleaning, the config file still has data for deleted/moved files, ...).
> Anyway, maybe this could be a start for such a plugin to get the
> desired feature working at all first and then later move the storage
> 'backend' from a plain text file to FS attributes.
> Such a plugin with a simple text file for storage should be fairly easy
> and quickly to write.

Well, if I find the time and can work out Geany's plugin API, I may as
well go the xattr route from the start.

> 
> >BTW, I know for sure that at least MacOS-X has xattr support, Solaris
> >ZFS has file meta-data as well and I would be pretty surprised if the
> >BSDs don't have xattr... Windows NTFS has meta-data... hm, that leaves
> >HP-UX from your list, but only because I don't know anything about it.
> 
> Me neither, I just mentioned HP-UX as a kind of non-mainstream OS (from
> an end-user point of view).

:-)


> >> >the filesystem has no support or has it turned off (at least so I
> >> >heard). So it's more a matter of wheather the API is available. But
> >> >what's the alternative, anyways? It would mean to create and
> >> >maintain a separate settings file for each file Geany ever opened
> >> >(or some database). And if the file is moved/renamed, there go the
> >> >settings. Worse yet, settings files will linger for files which may
> >> >have long been deleted. No, storing the settings *with* the file is
> >> >really the only solution. If the kernel or filesystem don't have
> >> >support for metadata, bad luck.
> >> 
> >> Hmm, I don't think it's worth adding support for this when we know
> >> before that only a few systems will support it at all.
> >
> >No offense, but you may want to re-check how many "few" actually is.
> 
> Hopefully you are right and I'm wrong, that'd be actually cool :).

It took a while before systems caught on to it, but meanwhile, they
mostly all support it. The problem is they didn't support it from the
beginning, like BeOS did, so it was not in peoples/developers minds, and
I suppose many people would regard it as little supported as you do, one
cannot follow everything... but me being a regular BeOS user (yes,
still!) I know how great it really is, and although most system support
it now (indeed, many for quite a long time, NTFS had it for ages), most
apps still don't make use of it.

Best regards,
-Stephan