Am Montag, den 15.12.2008, 21:15 +0100 schrieb Enrico Tröger:
On Mon, 15 Dec 2008 15:02:32 +0100, Stephan Aßmus superstippi@gmx.de wrote:
have closed meanwhile, the scrollbar and cursor are at the top of the file, the selection is lost. Wouldn't it be much better if that
The selection and precise scrollbar position are currently not saved with sessions. Cursor position is.
Would be nice, though. Although selection may be off when the file contents change through an external app.
I personally don't like saving any selection information at all. How could this be useful? Additionally, selections are easy to loose (or discard) in general, partly on intention, and so why storing them persistent between sessions? For instance, let's say you open a bunch of files in Geany for which selection information has been stored before and the selections are restored. Ok cool but once you click somewhere in the file the selection is lost and all the efforts to store them are useless.
Agreed, storing the selection is the least useful out of the persistency features I mentioned. However, believe it or not, I actually had some use for it once. Granted, it's quite a rare use case and just for the sake of persistency, storing the selection may bring more problems than usefulness (ie when it's off due to outside changes to the file).
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 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.
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.
File meta-data is incredibly useful. There may be nice features from certain OS's to ignore for the sake of cross-platform compatibility, but IMHO, meta-data support is not one of those.
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.
Anyway, of course the above only applies when we are talking about Geany's core, if you intend to write a plugin your are free to make it as non-portable as possible :).
As I said, I'm currently working on this project and am forced to use Linux and Geany seems to be quite a decent editor so far. During the project, I doubt I find the time, and afterwards, I probably don't have to use Linux anymore... :-) I may be making it sound like I dislike Linux or something, but it's actually quite good, it's just not my regular system. So please don't mistake anything I say...
Best regards, -Stephan