I am running Geany 1.36 under CentOS 7 and just experienced a crash of the desktop which resulted in an empty file list when I reloaded Geany...
I'd like to avoid this in the future and was thinking that I might be able to group various related files into Geany Projects which I can then open/close as needed, and, importantly, were the editor to crash, I could then simply reload the project.
In my case, files I would add to individual projects are in different directories where unrelated files also exist.
Is there a way to organize my work as outlined above? Perusing the Project Organizer page for Geany it seems that I could add subdirectories with all their files to a project which does not meet my need above.
Is there another way?
Thanks.
On Mon, 4 Jul 2022 at 12:39, H agents@meddatainc.com wrote:
I am running Geany 1.36 under CentOS 7 and just experienced a crash of the desktop which resulted in an empty file list when I reloaded Geany...
I'd like to avoid this in the future and was thinking that I might be able to group various related files into Geany Projects which I can then open/close as needed, and, importantly, were the editor to crash, I could then simply reload the project.
Geany projects are just named sessions, so they may be subject to the same issues of not being saved if the desktop/os/Geany crashes. Newer Geany versions than 1.36 do save more often so that risk is reduced. And the unreleased git version even splits session from preferences.
In my case, files I would add to individual projects are in different directories where unrelated files also exist.
Geany projects (as distinct from the various project plugins like Project Organiser) doesn't care where open files are located. The plugins do care because they do extra stuff, for example load all symbols, based on what they think of as a "project" (a single tree), but AFAIK none of them stop you opening files outside that directory.
Is there a way to organize my work as outlined above? Perusing the Project Organizer page for Geany it seems that I could add subdirectories with all their files to a project which does not meet my need above.
Geany itself deliberately does not dictate layout of anything, unlike "full fat" IDEs, but as you noticed some plugins do require more limitations to do their work, but thats the plugins requirement, not Geanys.
Is there another way?
As I said above, more recent Geany versions do save the session and preferences more often in an attempt to limit the situations where its lost, maybe upgrade.
Cheers Lex
Thanks.
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
On 07/03/2022 11:03 PM, Lex Trotman wrote:
On Mon, 4 Jul 2022 at 12:39, H agents@meddatainc.com wrote:
I am running Geany 1.36 under CentOS 7 and just experienced a crash of the desktop which resulted in an empty file list when I reloaded Geany...
I'd like to avoid this in the future and was thinking that I might be able to group various related files into Geany Projects which I can then open/close as needed, and, importantly, were the editor to crash, I could then simply reload the project.
Geany projects are just named sessions, so they may be subject to the same issues of not being saved if the desktop/os/Geany crashes. Newer Geany versions than 1.36 do save more often so that risk is reduced. And the unreleased git version even splits session from preferences.
In my case, files I would add to individual projects are in different directories where unrelated files also exist.
Geany projects (as distinct from the various project plugins like Project Organiser) doesn't care where open files are located. The plugins do care because they do extra stuff, for example load all symbols, based on what they think of as a "project" (a single tree), but AFAIK none of them stop you opening files outside that directory.
Is there a way to organize my work as outlined above? Perusing the Project Organizer page for Geany it seems that I could add subdirectories with all their files to a project which does not meet my need above.
Geany itself deliberately does not dictate layout of anything, unlike "full fat" IDEs, but as you noticed some plugins do require more limitations to do their work, but thats the plugins requirement, not Geanys.
Is there another way?
As I said above, more recent Geany versions do save the session and preferences more often in an attempt to limit the situations where its lost, maybe upgrade.
Cheers Lex
Thanks.
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Thank you. It sounds like an interesting feature that is being added. The latest release seems to be 1.38 - although 1.36 is the latest available for CentOS 7/RHEL 7 - so this would be forthcoming in 1.39, or?
Apart from this new feature, it would certainly be nice to get an update of Geany for CentOS/RHEL 7...
Reading through your comments, it seems that I should rethink how I organize "projects". I have different types of projects, some of which fit nicely into the Geany paradigm where I can create a project and then add various subdirectories to it.
Other "projects" of mine consist of different types of files, eg .md, .doc, .sql, .sh, .R etc., which I have hitherto organized more along the lines of various types of binaries etc, documentation etc. separated as to "category" of files. May not be the best method for organizing though...
Perhaps I should rethink this and simply create "projects" collecting the different types of files belonging together in various project subdirectories, or multiple subdirectories under a project subdirectory.
The reason I have used the former organization is that I can then keep the binaries in ~/home/bin which is in the path. If I were to reorganize, I would lose that - if I don't add all the new binary directories to the path...
Thoughts appreciated!
Thank you. It sounds like an interesting feature that is being added. The latest release seems to be 1.38 - although 1.36 is the latest available for CentOS 7/RHEL 7 - so this would be forthcoming in 1.39, or?
Saving more often is in 1.38, splitting prefs and session will be in 1.39 (unscheduled).
Apart from this new feature, it would certainly be nice to get an update of Geany for CentOS/RHEL 7...
The Geany project does not make packages, you need to ask the distros.
Reading through your comments, it seems that I should rethink how I organize "projects". I have different types of projects, some of which fit nicely into the Geany paradigm where I can create a project and then add various subdirectories to it.
Other "projects" of mine consist of different types of files, eg .md, .doc, .sql, .sh, .R etc., which I have hitherto organized more along the lines of various types of binaries etc, documentation etc. separated as to "category" of files. May not be the best method for organizing though...
Perhaps I should rethink this and simply create "projects" collecting the different types of files belonging together in various project subdirectories, or multiple subdirectories under a project subdirectory.
Remember Geany does not dictate this, it can handle files scattered everywhere, but plugins do need to have a more constrained view, and "under one directory" is the paradigm they have chosen (IIUC, I don't use those plugins).
The reason I have used the former organization is that I can then keep the binaries in ~/home/bin which is in the path. If I were to reorganize, I would lose that - if I don't add all the new binary directories to the path...
I don't know about your projects, but in conventional build workflows (cmake, meson, autotools) it is the job of the "install" step to put binaries in the path. Install is usually a separate step since if it is installing to system directories it needs to be executed with privileges, although thats not a problem for you installing to ~.
Cheers Lex
Thoughts appreciated!
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
On 07/05/2022 08:47 PM, Lex Trotman wrote:
Thank you. It sounds like an interesting feature that is being added. The latest release seems to be 1.38 - although 1.36 is the latest available for CentOS 7/RHEL 7 - so this would be forthcoming in 1.39, or?
Saving more often is in 1.38, splitting prefs and session will be in 1.39 (unscheduled).
Apart from this new feature, it would certainly be nice to get an update of Geany for CentOS/RHEL 7...
The Geany project does not make packages, you need to ask the distros.
Reading through your comments, it seems that I should rethink how I organize "projects". I have different types of projects, some of which fit nicely into the Geany paradigm where I can create a project and then add various subdirectories to it.
Other "projects" of mine consist of different types of files, eg .md, .doc, .sql, .sh, .R etc., which I have hitherto organized more along the lines of various types of binaries etc, documentation etc. separated as to "category" of files. May not be the best method for organizing though...
Perhaps I should rethink this and simply create "projects" collecting the different types of files belonging together in various project subdirectories, or multiple subdirectories under a project subdirectory.
Remember Geany does not dictate this, it can handle files scattered everywhere, but plugins do need to have a more constrained view, and "under one directory" is the paradigm they have chosen (IIUC, I don't use those plugins).
The reason I have used the former organization is that I can then keep the binaries in ~/home/bin which is in the path. If I were to reorganize, I would lose that - if I don't add all the new binary directories to the path...
I don't know about your projects, but in conventional build workflows (cmake, meson, autotools) it is the job of the "install" step to put binaries in the path. Install is usually a separate step since if it is installing to system directories it needs to be executed with privileges, although thats not a problem for you installing to ~.
Cheers Lex
Thoughts appreciated!
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Yes, I am aware I need to ask the distro to update geany and will do so.
I think I should reorganize my "projects" so that they fit better with the Geany plugin paradigm. Should make it easier to add using git versioning as well.
Most of my "projects" are not "programming" project but consist of various types of files that belong together. The binaries are most often shell files and I can certainly copy them to ~/bin as needed to be run from there (as I said, I added ~/bin to the path a long time ago.) When not added I can open a terminal window in the appropriate project subdirectory and run them from there.
Thank you for your guidance.
On 07/05/2022 09:40 PM, H wrote:
On 07/05/2022 08:47 PM, Lex Trotman wrote:
Thank you. It sounds like an interesting feature that is being added. The latest release seems to be 1.38 - although 1.36 is the latest available for CentOS 7/RHEL 7 - so this would be forthcoming in 1.39, or?
Saving more often is in 1.38, splitting prefs and session will be in 1.39 (unscheduled).
Apart from this new feature, it would certainly be nice to get an update of Geany for CentOS/RHEL 7...
The Geany project does not make packages, you need to ask the distros.
Reading through your comments, it seems that I should rethink how I organize "projects". I have different types of projects, some of which fit nicely into the Geany paradigm where I can create a project and then add various subdirectories to it.
Other "projects" of mine consist of different types of files, eg .md, .doc, .sql, .sh, .R etc., which I have hitherto organized more along the lines of various types of binaries etc, documentation etc. separated as to "category" of files. May not be the best method for organizing though...
Perhaps I should rethink this and simply create "projects" collecting the different types of files belonging together in various project subdirectories, or multiple subdirectories under a project subdirectory.
Remember Geany does not dictate this, it can handle files scattered everywhere, but plugins do need to have a more constrained view, and "under one directory" is the paradigm they have chosen (IIUC, I don't use those plugins).
The reason I have used the former organization is that I can then keep the binaries in ~/home/bin which is in the path. If I were to reorganize, I would lose that - if I don't add all the new binary directories to the path...
I don't know about your projects, but in conventional build workflows (cmake, meson, autotools) it is the job of the "install" step to put binaries in the path. Install is usually a separate step since if it is installing to system directories it needs to be executed with privileges, although thats not a problem for you installing to ~.
Cheers Lex
Thoughts appreciated!
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Yes, I am aware I need to ask the distro to update geany and will do so.
I think I should reorganize my "projects" so that they fit better with the Geany plugin paradigm. Should make it easier to add using git versioning as well.
Most of my "projects" are not "programming" project but consist of various types of files that belong together. The binaries are most often shell files and I can certainly copy them to ~/bin as needed to be run from there (as I said, I added ~/bin to the path a long time ago.) When not added I can open a terminal window in the appropriate project subdirectory and run them from there.
Thank you for your guidance.
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
The maintainer of Geany for EPEL states that 1.38 cannot be compiled for EPEL7 but has not shared the reason. Version 1.37, however, is now in the EPEL7-testing repository.
On Mon, 11 Jul 2022 at 08:53, H agents@meddatainc.com wrote:
On 07/05/2022 09:40 PM, H wrote:
On 07/05/2022 08:47 PM, Lex Trotman wrote:
Thank you. It sounds like an interesting feature that is being added. The latest release seems to be 1.38 - although 1.36 is the latest available for CentOS 7/RHEL 7 - so this would be forthcoming in 1.39, or?
Saving more often is in 1.38, splitting prefs and session will be in 1.39 (unscheduled).
Apart from this new feature, it would certainly be nice to get an update of Geany for CentOS/RHEL 7...
The Geany project does not make packages, you need to ask the distros.
Reading through your comments, it seems that I should rethink how I organize "projects". I have different types of projects, some of which fit nicely into the Geany paradigm where I can create a project and then add various subdirectories to it.
Other "projects" of mine consist of different types of files, eg .md, .doc, .sql, .sh, .R etc., which I have hitherto organized more along the lines of various types of binaries etc, documentation etc. separated as to "category" of files. May not be the best method for organizing though...
Perhaps I should rethink this and simply create "projects" collecting the different types of files belonging together in various project subdirectories, or multiple subdirectories under a project subdirectory.
Remember Geany does not dictate this, it can handle files scattered everywhere, but plugins do need to have a more constrained view, and "under one directory" is the paradigm they have chosen (IIUC, I don't use those plugins).
The reason I have used the former organization is that I can then keep the binaries in ~/home/bin which is in the path. If I were to reorganize, I would lose that - if I don't add all the new binary directories to the path...
I don't know about your projects, but in conventional build workflows (cmake, meson, autotools) it is the job of the "install" step to put binaries in the path. Install is usually a separate step since if it is installing to system directories it needs to be executed with privileges, although thats not a problem for you installing to ~.
Cheers Lex
Thoughts appreciated!
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Yes, I am aware I need to ask the distro to update geany and will do so.
I think I should reorganize my "projects" so that they fit better with the Geany plugin paradigm. Should make it easier to add using git versioning as well.
Most of my "projects" are not "programming" project but consist of various types of files that belong together. The binaries are most often shell files and I can certainly copy them to ~/bin as needed to be run from there (as I said, I added ~/bin to the path a long time ago.) When not added I can open a terminal window in the appropriate project subdirectory and run them from there.
Thank you for your guidance.
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
The maintainer of Geany for EPEL states that 1.38 cannot be compiled for EPEL7 but has not shared the reason. Version 1.37, however, is now in the EPEL7-testing repository.
Possibly because 1.38 needs some of C++17 but the default 7 compiler is gcc 4.8 IGUC (if google understands correctly). You could try compiling Geany yourself and see if the compiler has enough C++17 working to do it, it doesn't use much of C++17. Or install an upgraded compiler, IGUC there are newer toolsets available for Centos, then compile Geany. See https://github.com/geany/geany/pull/1690/commits/8c0d06378b75bc367e7110ca5f4... for simple build options (sadly the whole point of that PR was destroyed by the trolls so it never got merged).
Cheers Lex
Users mailing list -- users@lists.geany.org To unsubscribe send an email to users-leave@lists.geany.org
Hey there,
H wrote:
I am running Geany 1.36 under CentOS 7 and just experienced a crash of the desktop which resulted in an empty file list when I reloaded Geany...
I'd like to avoid this in the future and was thinking that I might be able to group various related files into Geany Projects which I can then open/close as needed, and, importantly, were the editor to crash, I could then simply reload the project.
I've got a couple of ways to do this depending on whether the files I want to open as a project are in the same directory or not. I'll include both below even though you're working with files that are in various locations. You may have them all together in the future, so the other method may someday come in handy.
Method 1: If all of your project files are scattered in various locations, you can give Geany a list of files, including their paths, as options on the command line. For example, this will open (or create and open) your files in Geany:
geany "~/Desktop/foo.txt" "~/Documents/bar.txt" "~/Development/baz.txt"
Note that you can type the command each time or copy it into your .bashrc file as an alias or into a shortcut or into a script.
Method 2: If all of your project files are in the same directory, you can create an empty Geany project file (a file ending in the .geany extension) in that directory and give Geany a list of files as options on the command line using the Geany project file as the command's *first* option. For example, this will open (or create and open) your files in Geany and write some information about them into the Geany project file:
geany "foo.geany" "bar.txt" "baz.txt" "bat.txt"
From then on, when you want to open those files again, you can either double-click the Geany project file or use the Geany project file as an option for Geany on the command line. For example, this will open your files in Geany:
geany "foo.geany"
Note that you can see the data in Geany project files by opening them in another text editor or printing their contents into a terminal window.
On 07/04/2022 10:23 AM, Little Girl wrote:
Hey there,
H wrote:
I am running Geany 1.36 under CentOS 7 and just experienced a crash of the desktop which resulted in an empty file list when I reloaded Geany...
I'd like to avoid this in the future and was thinking that I might be able to group various related files into Geany Projects which I can then open/close as needed, and, importantly, were the editor to crash, I could then simply reload the project.
I've got a couple of ways to do this depending on whether the files I want to open as a project are in the same directory or not. I'll include both below even though you're working with files that are in various locations. You may have them all together in the future, so the other method may someday come in handy.
Method 1: If all of your project files are scattered in various locations, you can give Geany a list of files, including their paths, as options on the command line. For example, this will open (or create and open) your files in Geany:
geany "~/Desktop/foo.txt" "~/Documents/bar.txt" "~/Development/baz.txt"
Note that you can type the command each time or copy it into your .bashrc file as an alias or into a shortcut or into a script.
Method 2: If all of your project files are in the same directory, you can create an empty Geany project file (a file ending in the .geany extension) in that directory and give Geany a list of files as options on the command line using the Geany project file as the command's *first* option. For example, this will open (or create and open) your files in Geany and write some information about them into the Geany project file:
geany "foo.geany" "bar.txt" "baz.txt" "bat.txt"
From then on, when you want to open those files again, you can either double-click the Geany project file or use the Geany project file as an option for Geany on the command line. For example, this will open your files in Geany:
geany "foo.geany"
Note that you can see the data in Geany project files by opening them in another text editor or printing their contents into a terminal window.
Thank you, I am considering rethinking how I organize my different types of "projects" to fit into the second paradigm, see reply to Lex.