Hi all,
this is my first mail to this list, so I want to tell you that Geany is quite a cool editor and IDE. Although I am using it as an editor only, since the project format of the project I am working on does not seem to be supported (cmake). I searched the archives a bit and saw that someone is working on a cmake plugin.
I also searched the archives on the following problem, but it didn't turn up much: My problem is that Geany does not store any persistency information with the files I edit. I take it that it would do that if I were working on a project. Every time I open a file again which I 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 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.
Best regards, -Stephan
Hi,
On Mon, 15 Dec 2008 11:28:00 +0100 Stephan Aßmus superstippi@gmx.de wrote:
this is my first mail to this list, so I want to tell you that Geany is quite a cool editor and IDE. Although I am using it as an editor only, since the project format of the project I am working on does not seem to be supported (cmake). I searched the archives a bit and saw that someone is working on a cmake plugin.
Geany doesn't support any build systems really. Projects are not for managing build systems.
I also searched the archives on the following problem, but it didn't turn up much: My problem is that Geany does not store any persistency information with the files I edit. I take it that it would do that if I were working on a project. Every time I open a file again which I
Geany saves session information when closing a project or quitting Geany (without a project open).
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.
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.
This could be done as a plugin to handle support for persistency when any file is closed/reopened. Probably this shouldn't be in the core.
Regards, Nick
Am Montag, den 15.12.2008, 13:37 +0000 schrieb Nick Treleaven:
On Mon, 15 Dec 2008 11:28:00 +0100 Stephan Aßmus superstippi@gmx.de wrote:
this is my first mail to this list, so I want to tell you that Geany is quite a cool editor and IDE. Although I am using it as an editor only, since the project format of the project I am working on does not seem to be supported (cmake). I searched the archives a bit and saw that someone is working on a cmake plugin.
Geany doesn't support any build systems really. Projects are not for managing build systems.
I was just trying to explain why I couldn't use Geany's project feature.
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.
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 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.
This could be done as a plugin to handle support for persistency when any file is closed/reopened. Probably this shouldn't be in the core.
Ok, I may look into writing my own plugin then, I guess. Already needed to build Geany from source to get the newest version... persistency is really something very important to any application that deals with documents, and if it's missing, it's very annoying for the user. Obviously I'm under time pressure, so I can't promise anything... and when I am done with my current project, I don't have to use Linux anymore and the system I normally use has metadata support everywhere and all the apps use it, so my pressure for this feature in Geany is then much lower...
Anyways, don't get me wrong though, Geany is very nice otherwise. :-)
Best regards, -Stephan
On Mon, 15 Dec 2008 15:02:32 +0100 Stephan Aßmus superstippi@gmx.de wrote:
Am Montag, den 15.12.2008, 13:37 +0000 schrieb Nick Treleaven:
On Mon, 15 Dec 2008 11:28:00 +0100 Stephan Aßmus superstippi@gmx.de wrote:
this is my first mail to this list, so I want to tell you that Geany is quite a cool editor and IDE. Although I am using it as an editor only, since the project format of the project I am working on does not seem to be supported (cmake). I searched the archives a bit and saw that someone is working on a cmake plugin.
Geany doesn't support any build systems really. Projects are not for managing build systems.
I was just trying to explain why I couldn't use Geany's project feature.
I don't see why using CMake is incompatible with using projects, but anyway...
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 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.
OK, sounds like a neat way to implement it.
This could be done as a plugin to handle support for persistency when any file is closed/reopened. Probably this shouldn't be in the core.
Ok, I may look into writing my own plugin then, I guess. Already needed to build Geany from source to get the newest version...
See: http://www.geany.org/manual/hacking.html#writing-plugins
If you have any questions, just ask.
persistency is really something very important to any application that deals with documents, and if it's missing, it's very annoying for the user. Obviously I'm under time pressure, so I can't promise
Personally I use sessions, but full persistency would be a cool feature.
Regards, Nick
Am Montag, den 15.12.2008, 16:16 +0000 schrieb Nick Treleaven:
On Mon, 15 Dec 2008 15:02:32 +0100 Stephan Aßmus superstippi@gmx.de wrote:
Am Montag, den 15.12.2008, 13:37 +0000 schrieb Nick Treleaven:
On Mon, 15 Dec 2008 11:28:00 +0100 Stephan Aßmus superstippi@gmx.de wrote:
this is my first mail to this list, so I want to tell you that Geany is quite a cool editor and IDE. Although I am using it as an editor only, since the project format of the project I am working on does not seem to be supported (cmake). I searched the archives a bit and saw that someone is working on a cmake plugin.
Geany doesn't support any build systems really. Projects are not for managing build systems.
I was just trying to explain why I couldn't use Geany's project feature.
I don't see why using CMake is incompatible with using projects, but anyway...
Well, if I can somehow use our existing top-level CMakeLists.txt and treat it as project in Geany, I am all ears! :-) Or, in another words, how would you go about it?
Best regards, -Stephan
On Mon, 15 Dec 2008 17:56:39 +0100 Stephan Aßmus superstippi@gmx.de wrote:
I don't see why using CMake is incompatible with using projects, but anyway...
Well, if I can somehow use our existing top-level CMakeLists.txt and treat it as project in Geany, I am all ears! :-) Or, in another words, how would you go about it?
As I said, Geany core projects* don't know anything about build systems. AFAICT you could use geany projects to record session files, cursor positions, etc. Just try it.
* Not to be confused with the geanyprj plugin.
Regards, Nick
Am Montag, den 15.12.2008, 17:14 +0000 schrieb Nick Treleaven:
On Mon, 15 Dec 2008 17:56:39 +0100 Stephan Aßmus superstippi@gmx.de wrote:
I don't see why using CMake is incompatible with using projects, but anyway...
Well, if I can somehow use our existing top-level CMakeLists.txt and treat it as project in Geany, I am all ears! :-) Or, in another words, how would you go about it?
As I said, Geany core projects* don't know anything about build systems. AFAICT you could use geany projects to record session files, cursor positions, etc. Just try it.
So basically, I would create a new "core project" and manually add all my files to it? And then I would have to manually sync the CMakeLists.txt and the project. Otherwise I don't see the benefit over using Geany as I do know, where it simply remembers the files I had opened the last time I run it.
Best regards, -Stephan
On Mon, 15 Dec 2008 18:26:28 +0100, Stephan Aßmus superstippi@gmx.de wrote:
Am Montag, den 15.12.2008, 17:14 +0000 schrieb Nick Treleaven:
On Mon, 15 Dec 2008 17:56:39 +0100 Stephan Aßmus superstippi@gmx.de wrote:
I don't see why using CMake is incompatible with using projects, but anyway...
Well, if I can somehow use our existing top-level CMakeLists.txt and treat it as project in Geany, I am all ears! :-) Or, in another words, how would you go about it?
As I said, Geany core projects* don't know anything about build systems. AFAICT you could use geany projects to record session files, cursor positions, etc. Just try it.
So basically, I would create a new "core project" and manually add all my files to it? And then I would have to manually sync the CMakeLists.txt and the project. Otherwise I don't see the benefit over
Adding files to a project in Geany doesn't add a relation between the files and project, files in a project in Geany is just an extended way of session management, i.e. Geany will re-open all files you had opened when the project was opened last time.
using Geany as I do know, where it simply remembers the files I had opened the last time I run it.
Plus things like 'make in basepath' and a per-project run command. Further features are to come, namely per-project properties like template data and some editor prefs like indentation. But this still needs to be discussed, designed and finally implemented.
Regards, Enrico
Am Montag, den 15.12.2008, 21:04 +0100 schrieb Enrico Tröger:
On Mon, 15 Dec 2008 18:26:28 +0100, Stephan Aßmus superstippi@gmx.de wrote:
Am Montag, den 15.12.2008, 17:14 +0000 schrieb Nick Treleaven:
On Mon, 15 Dec 2008 17:56:39 +0100 Stephan Aßmus superstippi@gmx.de wrote:
I don't see why using CMake is incompatible with using projects, but anyway...
Well, if I can somehow use our existing top-level CMakeLists.txt and treat it as project in Geany, I am all ears! :-) Or, in another words, how would you go about it?
As I said, Geany core projects* don't know anything about build systems. AFAICT you could use geany projects to record session files, cursor positions, etc. Just try it.
So basically, I would create a new "core project" and manually add all my files to it? And then I would have to manually sync the CMakeLists.txt and the project. Otherwise I don't see the benefit over
Adding files to a project in Geany doesn't add a relation between the files and project, files in a project in Geany is just an extended way of session management, i.e. Geany will re-open all files you had opened when the project was opened last time.
using Geany as I do know, where it simply remembers the files I had opened the last time I run it.
Plus things like 'make in basepath' and a per-project run command. Further features are to come, namely per-project properties like template data and some editor prefs like indentation. But this still needs to be discussed, designed and finally implemented.
Ok, thanks for clearing that up. It's not useful for me, though, since neither will "make" work in the "basepath" of my project, nor will a single run command do me good, since the project has very many different sub-targets and I could want to run any of them at any time.
At least the embedded Terminal is saving me some screen real-estate. Would be nice to be able to attach more than one of them. Also, I noticed a bug with that Terminal: If I "svn commit" from within it, I have "nano" set as SVN_EDITOR. The keyboard shortcuts inside nano do not work in the embedded Terminal, and there is actually no way to get out of nano.
Best regards, -Stephan
On Mon, 15 Dec 2008 21:53:43 +0100, Stephan Aßmus superstippi@gmx.de wrote:
At least the embedded Terminal is saving me some screen real-estate. Would be nice to be able to attach more than one of them. Also, I noticed a bug with that Terminal: If I "svn commit" from within it, I have "nano" set as SVN_EDITOR. The keyboard shortcuts inside nano do not work in the embedded Terminal, and there is actually no way to get out of nano.
RTFM :). http://www.geany.org/manual/0.15/#vte-tab-in-preferences-dialog
Preferences->Terminal->Override Geany keybindings
Regards, Enrico
Am Montag, den 15.12.2008, 22:02 +0100 schrieb Enrico Tröger:
On Mon, 15 Dec 2008 21:53:43 +0100, Stephan Aßmus superstippi@gmx.de wrote:
At least the embedded Terminal is saving me some screen real-estate. Would be nice to be able to attach more than one of them. Also, I noticed a bug with that Terminal: If I "svn commit" from within it, I have "nano" set as SVN_EDITOR. The keyboard shortcuts inside nano do not work in the embedded Terminal, and there is actually no way to get out of nano.
RTFM :). http://www.geany.org/manual/0.15/#vte-tab-in-preferences-dialog
Preferences->Terminal->Override Geany keybindings
Thanks! I actually saw that before, but it didn't penetrate my brain...
Best regards, -Stephan
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.
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, ...?
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.
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 :).
Regards, Enrico
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
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. 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.)
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.
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 :).
Regards, Enrico
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
On Mon, 15 Dec 2008 22:57:13 +0100 Stephan Aßmus superstippi@gmx.de wrote:
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.
This is a cool idea, and personally a plugin that works on Linux would be great. Once something is there, maybe people will add patches to support different OS's file attribute systems. (Or maybe there's a xattr library ported to Windows, who knows). Thanks for bringing it up, I didn't know about it before.
Regards, Nick
Am Dienstag, den 16.12.2008, 12:40 +0000 schrieb Nick Treleaven:
On Mon, 15 Dec 2008 22:57:13 +0100 Stephan Aßmus superstippi@gmx.de wrote:
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.
This is a cool idea, and personally a plugin that works on Linux would be great. Once something is there, maybe people will add patches to support different OS's file attribute systems. (Or maybe there's a xattr library ported to Windows, who knows). Thanks for bringing it up, I didn't know about it before.
I've done a little research yesterday. Linux and NetBSD both have sys/xattr.h with identical API. Although FreeBSD is supposed to have support for xattr since some versions (default in "UFS2" and used for ACLs), I could not find out which header makes the API accessible and indeed if the API is xattr compatible. MacOS-X is said to have "xattr" support, but I have not yet tried to find which header defines it and so on. Windows at least has the technical feature in NTFS, although it most likely won't be available through the xattr API. Indeed there is a specification for using "Extended Attributes" in FAT which is shared between OS/2 and Windows... Solaris has arbitrary meta-data support through "file stream forks" since version 9. Maybe it's not even restricted to ZFS. Don't know yet if the xattr API is available, though. I also found mention that NFS supports xattr, though I don't remember if I read since which version. :-)
Anyway, your approach is definitely very reasonable - people familiar with their respective platform should implement it, whomever it bothers the most that the feature is not available to them...
That's my findings so far. Oh, and there is a FreeDesktop.org recommendation on the attribute naming scheme of meta-data to avoid clashes. So Geany would write an attribute "user.geany.docstate" or similar. Writing/reading the attr through sys/xattr.h would be incredibly simple. Only I have not yet looked at the available plug-in hook functions. Is there a hook to mess with the document state after a document has been loaded, right before the text would be displayed? The question mainly targets whether or not I would need to worry about "flickering" or "jumping" of the text when I set the scrollbar position.
Best regards and thanks for the helpful discussion, -Stephan
On Tue, 16 Dec 2008 14:09:18 +0100 Stephan Aßmus superstippi@gmx.de wrote:
That's my findings so far. Oh, and there is a FreeDesktop.org
Cool. Also there's info here for others reading this thread: http://en.wikipedia.org/wiki/Extended_file_attributes
recommendation on the attribute naming scheme of meta-data to avoid clashes. So Geany would write an attribute "user.geany.docstate" or similar. Writing/reading the attr through sys/xattr.h would be incredibly simple. Only I have not yet looked at the available plug-in
Yes, looks straightforward.
hook functions. Is there a hook to mess with the document state after a document has been loaded, right before the text would be displayed? The question mainly targets whether or not I would need to worry about "flickering" or "jumping" of the text when I set the scrollbar position.
Not sure about this. You would connect to the "document-open" signal, it's possible the drawing doesn't start until the signal has been handled.
http://www.geany.org/manual/reference/signals.html
Regards, Nick