Hi,
I have been using Geany without the C filetype and opening all C files
as C++. I use about 50% each of C and C++, and since I merged the two
filetypes quite a few of headaches went away.
Some of the benefits:
- C or C++ tags always work
- Special highlighting of C++ keywords so I know to avoid in C
- All C and C++ constructs always work
- No ambiguity of *.h files (except w/ Obj-C)
Some of the drawbacks:
- Using C++ build commands for C doesn't make much sense
(although some claim compiling plain C as C++ to be a virtue)
- The default C++ extension wouldn't be suitable for plain C
Some non-issues (AFAICT):
- Both filetypes already use the same Scintilla C++ lexer
- For Geany's purposes the CTags C++ parser works for both C and C++
It might be useful to only have one filetype for both. I'm content
editing my config files locally, but I just thought it worth discussing
to see if I'm mistaken on the perceived benefits/drawbacks.
Cheers,
Matthew Brush
Hi Guys,
Is the regular expression capability broken in 1.25 and 1.26
In 1.24, if I pop up the Find dialogue on a simple text file, I can search for \n with reg. expressions ticked and I find the end of the line.
If I do this in 1.25 or 1.26, it does not find the end of the line and claims it cannot find \n.
I notice single line reg. exp. was added at 1.25.
Thanks...M
Hi folks,
Since a few releases I'm experiencing some not optimal way of
development which is surely caused by the long history we already have
on g-p as well as by the many people around luckily contributing to the
plugins collection: More and more plugins are going into some kind of an
orphaned state. There is some maintainer available but not really
responsive e.g. due to workload at reallife etc. However, at the end
some of the plugins are still compiling but not effectively working any
more with recent Geany version or its documentation is really outdated
-- when I was preparing the commits for waf removing I have seen plugins
still depending on Geany 0.16 ... I'm pretty sure, if they would, they
would compile any more ;)
Also the documentation of each plugin are differing in style, size and
quality much. (and I have to include the plugins I'm maintaining here
100% too). At github we already got a bunch of bug reports and pull
requests for plugins waiting for any response. Also there is a long
backlog at sf I've been told.
This is what I was thinking of to improve the situation (the overall
experience for our users)
1) Deactivating all plugins / out comment all plugins from MAINTAINERS
2) Cleaning off NEWS, Changelog etc. from individual plugin folders
3) Moving documentation of all plugins into a structure like
doc/<pluginname> to get a real fitting (online) manual. At this
point update documentation and bring them to some markup stil (Rest?
md? Docbook? I don't care at this point)
4) Moving all plugins into a subfolder like plugins/<pluginname> to
clean up / of g-p a little
5) Reactivating plugins by a pull request of the actual (old|new)
maintainer maybe doing steps 2-4 and comment back in the plugin in
MAINTAINERS. Also I would be happy if at this point po/POTFILES.in
is reviewed etc.
6) Release a cleaned up g-p
7) Post 1.27 puring not update plugins from src tree
What do you think about this idea? I would combine this with some
release goals like complete support of Geany Gtk3 stack (if applicable).
Timeschedule: 1-4 until Xmas 2015, 5-6 until March.
Cheers,
Frank
Hi again Jiri,
It was a long meeting, continuing into dinner and drinks, but now I'm home
and continue my reply to your message. I've turned off the digest-function,
there should be no more delay in correspondence.
First though, I'd like to say something; when we talk about differences
between projects, I don't see that as something negative - actually the
opposite. Differences means the projects can extend each other instead of
being just similar. So, if PO (Project Organizer) has functionality that D
(Djynn) does not, then that can make D better, and vice versa; should they
somehow merge. If you see what I mean?
> I can describe the vision of PorjectOrganizer. What I tried to make was a
> file-aware Geany project (Geany itself doesn't know about the files, it
> just stores base directory, build options and some common settings for
> project) in a minimalistic way and reuse as much as possible from Geany
> itself without duplicating functionality.
Yes, we think the same in many ways :) PO is designed for large or huge
projects with hundreds or thousands of files, and D is designed to handle
many smaller projects, because that's what I mostly work with. My projects
rarely have more than a few hundred source files at most. Workspaces isn't
a very important part of D, rather, like in Eclipse, all projects are
listed in the tree-view at once and sometimes it becomes too many projects
to have in one listing, so the workspaces function makes it possible to
organise projects into groups. I may group all PHP-projects into one
workspace, and all C projects into one, or my company's projects into one
workspace, and my private projects into one etc. you get the point. All in
all, D is designed to give quicker access to project's files, so is PO, and
if we stick to that as the basic "vision", then anything else is just
various "solutions" to the same problem: project file access.
> There's a single glob file pattern list per project in ProjectOrganizer
> defined in project properties. The advantage of a glob pattern over regex
> is that Geany uses it too and it can be passed to the Find in Files dialog
> so a pattern defined at a single place in the project config is used for
> everything.
Well, I see no problem here, why limit to glob or regex? Why not give the
choice to use either with a checkbox/radio?
PO mirrors the project directory and filters files; D picks directories and
adds as folders in the project tree, each folder can either filter the
files in the mirrored directory or pick specific files, naming or
organising of files and folders does not have to mirror the file system,
but can be moved anyway you like.
> You can attach an arbitrary number of "external directories" to a project
> in ProjectOrganizer and have their files displayed in the sidebar (and get
> them indexed with the tag manager if needed). It's just not per file but
> per directory.
Exactly, and PO has some really nice functions for finding in files, which
D does not, and D doesn't have indexing of symbols.
> * Djynn can have multiple workspaces, ProjectOrganizer just uses Geany's
> single "workspace" (basically the "recent projects" list).
Instead of hundreds of files in each project, I have lots and lots of
projects and "recent projects" list would not work for me, I need to
organise them into groups. So what is useful all depends on how we work.
> For me this is sufficient, I find the workspace concept a bit too
> heavyweight for an editor like Geany. Switching between recent projects
> using Geany's built-in functionality is nice and simple.
No, it's not heavyweight, in that case I'd say PO's functionality to handle
hundreds or thousands of project files is heavyweight for a minimalistic
IDE. On the contrary I'd say that unless it makes the program very
complicated to use, and eats up lots of CPU or memory, it's lightweight. D
is extremely lightweight, it uses very little CPU and memory, and is
extremely simple to use. Workspaces organise projects into groups, projects
and sessions organise files into groups. It's all about how you work, what
you need and find useful, often it's a matter of taste, and mostly of
course practicality.
> However, if the project open/close methods are added to the API, some
> workspace manager plugin could be made and it could even coexist with the
> ProjectOrganizer plugin.
Well, D is coexisting with PO already, so, yes, I see no problem here.
> * ProjectOrganizer's project has a single session (like Geany) while Djynn
> can have multiple.
Sessions is just a function I need all the time, perhaps you work
differently, but for me it's invaluable :) I've only added functionality
because that's what I make use of, otherwise it's removed. D had a list of
open documents, which was removed when I noticed Addons-plugin has that as
a button in the panel; and I use that even more than I use D.
> I don't know if I'd ever use more sessions per project so I'm not planning
> to add it to ProjectOrganizer.
Well, so you admit then that PO is "what you need in Geany", and it's not
actually designed for a more general use?
> Again, this is quite independent of the ProjectOrganizer functionality and
> could be done in a separate plugin.
Yes, of course, but I prefer to have the sessions list in the project
sidepanel, and D has a configuration for choosing a separate sidepanel of
its own or as a tab in the main sidepanel; this was a request in the
wishlist that I implemented and later found useful. Again, I see no reason
to limit functionality that is useful.
> * There's a single project file/definition in ProjectOrganizer, if I
> understand correctly there are two in Djynn.
No, there are one per project, one per session, and one for the D plugin
configurations. The project configuration-files have their own format and
are not conf-files. I've considered using a SQLite3 database instead, which
I think would be more elegant in a way, but the current files can be edited
in Geany, so that's a plus.
> I find the ProjectOrganizer way better in this case.
Yes, that is your privilege of course, we can agree to disagree, I see no
problem there.
> * Files belonging to a project are defined similarly in both plugins (glob
> patterns vs regex), there's a possibility to add files external to the
> project directory in both plugins.
>
> More or less similar.
In my opinion, both can be extended to become much better. D is limited to
what I've had time to include in functionality, and I have some ideas that
have yet to be created, but would be practical. I don't really care which
of PO or D is better, my consideration is how can either become better.
> * In Djynn there is the possibility to add individual files, the tree can
> be reorganized by drag and drop. There's no such thing in ProjectOrganizer
> which basically mirrors the file system structure.
Yes, PO has search functions and indexing of symbols, and D has some
additional functionality in the tre-view popup menu. They are different,
it's not a bad thing.
> Contrary to Djynn, ProjectOrganizer is designed to work for huge projects
> with thousands of files. When working on such big projects with many
> collaborators, files and directories get renamed, deleted, added quite
> often and what you manually add to the project gets invalid in this case.
> Updating the project every time you make "git pull" is very annoying. For
> this reason there's no configuration describing how the tree should look
or
> what files are in the project - just a directory (plus the external
> directories) and a glob pattern. I know this might be limiting a bit for
> you but I'd really like to keep it this way.
Yes, PO is designed for that kind of project management in mind, D isn't. D
is designed for smaller projects, like Geany for example. Geany has 99
files in /src, so if I were working on Geany I'd add /src and /plugins to
the project as dynamically loaded directories, and would probably add
autotools-files in a folder I'd name something like "build", the README,
NEWS etc. file would go into a folder too. If those files change, I'd just
update the project, but they rarely do so it's not really a problem, it's
the /src and /plugins directories that changes more often so they need to
load dynamically.
D projects are designed to be worked with, and to be easily changed when
the project changes. It's not designed to have all files, but to have the
files I work with and need quick access to. If there are thousands of
files, usually only a part of them is what I'm working on. Personally I
couldn't handle thousands of source files, I'd refuse working on such a
project - unless of course I'm assigned to work on a particular part of
those files, in which case the D project would only contain the files I'm
working on.
> Do you think the "vision" of ProjectOrganizer is somehow compatible with
> your vision of Djynn or is its minimalistic approach too limiting for you?
I use all the functionality of D myself, and anything else has already been
removed because I didn't use it. It's a living project that expands with
new needs and ideas, and time to realise them. So, yes, removing any
functionality of what I already have would be limiting to what I'm used to
work with. Fortunately I don't have to.
My impression of what you're writing is that PO is perfect and complete in
your opinion, and you see no reason to expand with more functionality, is
that correct? On the contrary, for me D is limited by the fact that I don't
have time to add more functionality, and would do so otherwise; it's far
from complete or perfect. I'd happily add the functionality that PO has
already that D is missing, I would consider it enriching the project.
I can't see that we have an agreement Jiri, but it's far from a meaningless
conversation.
Cheers,
Per
-------------
Hi Thomas,
> document_close_all() is useful on its own because there's an important
> detail: it's transactional. Either all or no documents are closed. As a
> consequence, if one or more docs spawned a dialog (because of being
> unsaved) and that dialog is cancelled, then no file is closed.
>
> This is what's done when Geany exits. This is impossible with just doing
> document_close() in a loop (unless you export
> document_account_for_unsaved()).
>
> So yes, document_close_all() should be exported.
Having considered that document_close_all() closes all or nothing, it's
better to close all with the option to save unsaved files, than nothing
happens when switching sessions. Therefore document_close_all() can very
well be exported, but I will not use it myself any longer.
> Right, Per should do the pull request, since he asks for the function.
Yes, I can do that :-)
Regards,
Per
Hi all,
We often get contributions for adding custom filetypes to Geany, and we
even have some in the source tree already. We tend to not want to add
them to Geany repo, usually due to limited functionality, or limited
popularity.
I would like to propose that we add a new repository to Github, similar
to geany-themes, where we add any custom filetypes that are useful, but
perhaps aren't up to par or popular enough to add to Geany proper. This
would give a single place to get them all at once (via Git or Github Zip
file download), and also a repo for packagers to use should they want to
provide a package.
Inside the repo we could have the README or some other file cataloging
all the filetypes, along with who contributed them, their status, like
whether tag parsing works, syntax lexing, and such meta info. As a
start, we could add all of the filetypes from the Wiki[0], any useful
ones from pull requests, and even any questionable ones already in Geany
(if there are any). We could also add some shell script or something to
install them into a user's home dir all at once, if that's useful.
What do you think?
Cheers,
Matthew Brush
[0]: http://wiki.geany.org/config/start
Hi folks,
I know there are reasons to use the digest version of a mailing list.
But: Just replying is ending up in two bad things:
- Bad subject
I have no clue what is Devel Digest Vol 1530, Issue 3 is referring to
- Broken thread
I know, most webmailers don't support threading or something as e.g.
Apple mail is neither. However, having a look onto e.g.
http://lists.geany.org/pipermail/devel/2015-December/thread.html you
can see what I'm referring to. So don't use threading end up in a
bigger chance interested people cannot/will not read you comments
Thanks,
Frank
P.S. I vote for deactivate digest function at all on our mailing lists.
Hi Jiri,
I get a digest on daily basis, didn't see your message until now, and my
phone managed to send the previous reply quite unfinished. Anyhow, I'll
respond as well I can.
> I have written some notes below how Djynn's project management differs
from
> ProjectOrganizer and some rationale for why I went that way. In my opinion
> the core functionality is quite similar.
Fine :)
> This is the same in ProjectOrganizer. Moreover, ProjectOrganizer stores
its
> config into the standard Geany project file so there's a single project
> file. I believe there are two project files in your case the Djynn one and
> the Geany one and this "two-project" thing makes things a bit confusing
for
> users. Did you know you can store your config options into the Geany
> project file using the API?
Actually, Djynn has a config file for each project, and for each session,
but workspaces are in djynn.conf with the rest of plugin configurations.
Yes, I know I can use Geany config, but decided not to clutter it with too
much data.
> This is how it's in Geany too, there's just a single session per project -
> on project opening your previous session is restored.
The reason I've made a separation between projects and sessions is purely
of practical reasons, I switch between sessions all the time, though they
don't nesessarily need to be projects. So sessions have nothing to do with
projects.
> Since ProjectOrganizer is an extension of Geany project, there's no
> distinction between Geany project and ProjectOrganizer project - they are
> one.
Yes, I see that.
> ProjectOrganizer does basically nothing with sessions and uses Geany's
> session management.
Well, in that regard, I didn't make Djynn to extend Geany, but rather
modify to do what I needed. As such, I've also changed the built in
commenting function, I wanted the comments at start of lines, not at the
indent, etc. Also, most functionality is based on how Geany worked in 2012,
and at that time GProject didn't do things my way, so to speak. I had been
working with CodeBlocks, and wanted a similar yet simpler project
environment. It was never intended as anything but for personal usage.
> I don't think it's so different, IMO the only big extra things in Djynn
are
> the workspace management and session management.
Perhaps you should have a look at the plugin? They work quite differently
from what I can see. I'll upload a corrected version to Launchpad this
evening, have a meeting today.
> I can describe the vision of PorjectOrganizer. What I tried to make was a
> file-aware Geany project (Geany itself doesn't know about the files, it
> just stores base directory, build options and some common settings for
> project) in a minimalistic way and reuse as much as possible from Geany
> itself without duplicating functionality.
Sorry, but I wasn't as considerate in making Djynn, it was not designed to
extend Geany, but to modify, as I wrote earlier.
I'll return in a few hours and respond to the rest then. Thank you for your
reply, and have a good day!
Regards,
Per
Hi Jiri,
> I have written some notes below how Djynn's project management differs
from
> ProjectOrganizer and some rationale for why I went that way. In my opinion
> the core functionality is quite similar.
>
> On Wed, Dec 16, 2015 at 4:09 PM, Per L?wgren <per.lowgren(a)gmail.com>
wrote:
>
> > Hello,
> >
> > I reply to all of your posts in one message. Hope that's ok.
> >
> > Basically, the terminology Djynn use is:
> > * workspace: a set of projects
> >
>
> There's nothing like that in ProjectOrganizer - as I didn't want to
> duplicate functionality which is already in Geany, I just kept things
> simple in this respect so switching between projects is done using Geany's
> standard project opening functionality and recent projects. Maybe we could
> increase the number of the shown recent projects so it's easier to open
> projects for people with many projects.
>
>
> > * project: a set of files, organised into a directory tree, that may or
> > may not be opened
> >
>
> This is the same in ProjectOrganizer. Moreover, ProjectOrganizer stores
its
> config into the standard Geany project file so there's a single project
> file. I believe there are two project files in your case the Djynn one and
> the Geany one and this "two-project" thing makes things a bit confusing
for
> users. Did you know you can store your config options into the Geany
> project file using the API?
>
>
> > * session: a set of opened documents in the editor
> >
>
> This is how it's in Geany too, there's just a single session per project -
> on project opening your previous session is restored.
>
>
> >
> > In Geany, a project is the configuration of the project, including
editing
> > and building.
> >
>
> Since ProjectOrganizer is an extension of Geany project, there's no
> distinction between Geany project and ProjectOrganizer project - they are
> one.
>
>
> In answer to your question: The session manager; it switches between
> > sessions, and stores many sessions. When switching between sessions, all
> > opened documents are stored in the present session's file; then all
opened
> > documents are closed; then the documents in the next session are opened.
> >
>
> ProjectOrganizer does basically nothing with sessions and uses Geany's
> session management.
>
>
> >
> >
> > > Sounds like reasonable usage, I think you can just open Geany pull
> > request
> > > to make these public. To make a function public, you just need to:
> > >
> > > 1. Prefix the implementation with GEANY_API_SYMBOL.
> > > 2. Add some user-visible API documentation with a docstring (see other
> > API
> > > functions in the code to have an idea how it should look)
> > > 3. Move the function declarations above GEANY_PRIVATE in the header.
> > >
> > > That's about it.
> >
> > That would work on my computer, but not on Launchpad, or for anyone
else.
> >
>
> Here I meant you could make a pull request to Geany so it can be merged to
> Geany and available for everyone in the next release.
>
> The Project Organizer is an interesting plugin, they are similar, but
works
> > very differently.
> >
>
> I don't think it's so different, IMO the only big extra things in Djynn
are
> the workspace management and session management.
>
> If we can agree on a common "vision", I'd happily contribute to that.
> >
>
> I can describe the vision of PorjectOrganizer. What I tried to make was a
> file-aware Geany project (Geany itself doesn't know about the files, it
> just stores base directory, build options and some common settings for
> project) in a minimalistic way and reuse as much as possible from Geany
> itself without duplicating functionality.
>
>
> > Djynn has regex pattern add files on a per directory basis, i.e. you can
> > add a directory and tell to search files according to pattern, and
recurse
> > into subfolders,
> >
>
> There's a single glob file pattern list per project in ProjectOrganizer
> defined in project properties. The advantage of a glob pattern over regex
> is that Geany uses it too and it can be passed to the Find in Files dialog
> so a pattern defined at a single place in the project config is used for
> everything.
>
> but you can still have fixed files added too; e.g. you can add files from
> > the project source directory, and also add `~/.config/project/file.conf`
> > etc.
> >
>
> You can attach an arbitrary number of "external directories" to a project
> in ProjectOrganizer and have their files displayed in the sidebar (and get
> them indexed with the tag manager if needed). It's just not per file but
> per directory.
>
> To sum up the differences:
>
> * Djynn can have multiple workspaces, ProjectOrganizer just uses Geany's
> single "workspace" (basically the "recent projects" list).
>
> For me this is sufficient, I find the workspace concept a bit too
> heavyweight for an editor like Geany. Switching between recent projects
> using Geany's built-in functionality is nice and simple.
>
> However, if the project open/close methods are added to the API, some
> workspace manager plugin could be made and it could even coexist with the
> ProjectOrganizer plugin.
>
> * ProjectOrganizer's project has a single session (like Geany) while Djynn
> can have multiple.
>
> I don't know if I'd ever use more sessions per project so I'm not planning
> to add it to ProjectOrganizer.
>
> Again, this is quite independent of the ProjectOrganizer functionality and
> could be done in a separate plugin.
>
> * There's a single project file/definition in ProjectOrganizer, if I
> understand correctly there are two in Djynn.
>
> I find the ProjectOrganizer way better in this case.
>
> * Files belonging to a project are defined similarly in both plugins (glob
> patterns vs regex), there's a possibility to add files external to the
> project directory in both plugins.
>
> More or less similar.
>
> * In Djynn there is the possibility to add individual files, the tree can
> be reorganized by drag and drop. There's no such thing in ProjectOrganizer
> which basically mirrors the file system structure.
>
> Contrary to Djynn, ProjectOrganizer is designed to work for huge projects
> with thousands of files. When working on such big projects with many
> collaborators, files and directories get renamed, deleted, added quite
> often and what you manually add to the project gets invalid in this case.
> Updating the project every time you make "git pull" is very annoying. For
> this reason there's no configuration describing how the tree should look
or
> what files are in the project - just a directory (plus the external
> directories) and a glob pattern. I know this might be limiting a bit for
> you but I'd really like to keep it this way.
>
> Do you think the "vision" of ProjectOrganizer is somehow compatible with
> your vision of Djynn or is its minimalistic approach too limiting for you?
>
> Cheers,
>
> Jiri
>
> What they were suggesting would work for others and not just your own
> computer.
> What was meant here is to:
>
> 1. /Fork geany on github./
> 2. Modify geany's code to add GEANY_API_SYMBOL to the functions you
> want made public.
> 3. Add API documentation
> 4. Move the function declarations above GEANY_PRIVATE in the header.
> 5. /Commit the changes to your fork on github./
> 6. /Create a "pull request" from /_/within github's web interface/_/,
> requesting pulling the changes in to the core product./
>
> That way, everyone benefits :-)
>
> I've been considering doing this myself to get some functionality back
> for my plugins since they fixed the symbols for linux.
Hi Steve,
Thank you for the input!
At the moment I think I'll keep my plugin third party and stick with the
public API as it is. There is one plugin for managing projects already, and
seems superfluous with another. I keep the plugin publicly available
because it's there and might as well be :-)
Regards,
Per
> Hi,
>
> The API has been fixed to not leak symbols, which it did for a few
> recent versions. The only functions that are public, which is how it's
> always been, are those documented in the API reference[0]. That you were
> able to compile and link against private symbols was a bug in Geany. If
> you need those functions though, they can likely be added to the public
> API with a pull request.
>
> Cheers,
> Matthew Brush
>
>
> [0]: http://www.geany.org/manual/reference/
Hello Matthew,
Apparently filetypes_detect_from_document isn't needed since an instance of
GeanyFiletype is a member of GeanyDocument, I just noticed, so that solved
itself.
I can probably find an alternative workaround for document_close_all, e.g.
iterate document_index(0) until it returns NULL, and call document_close;
so I think should be ok too.
The project functions however, since Djynn is meant to integrate with the
internal Geany project manager, with functions for opening and closing
projects. I believe Geany would be enhanced by the possibility for plugins
to open and close projects. When creating a Djynn-project a Geany-project
is generated automatically, and when opening and closing Djynn-projects,
the Geany-projects are opened and closed too. It's been working very well,
seamlessly and invisibly, and would be a loss if I had to cut out the
Geany-project integration.
When I began working with Djynn, I actually only wanted a tree-view of the
project files for my projects. Since I'm working on many projects I needed
quick access to files from the various projects without having to find them
with Thunar (it's my preferred file manager). Then merging projects with
Geany was the natural next step.
I'm not sure if anyone but me is really using my plugin, it's only designed
for my personal needs, but I'd really be happy if anyone else had use for
it as well.
Anyway, I'm sure document_close_all could be used by many plugins, but
filetypes_detect_from_document is not needed. The project functions would
be much appreciated. That's all on my xmas wishlist :)
Per