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@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