Re: [Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

On 4 October 2012 03:06, Dimitar Zhekov dimitar.zhe...@gmail.com wrote:

 On Tue, 2 Oct 2012 13:03:00 +1000
 Lex Trotman ele...@gmail.com wrote:

  Are all settings saved on apply? not just the prefs/project prefs ones?
  I
  thought there were some that still didn't for one reason or another,
 maybe
  that should be changed as a separate thing anyway, in which case you are
  right, the rush only applies to session data.

 Edit - Preferences - OK|Apply saves the entire geany.conf:
 dialog preferences, UI settings and file list.

 Project - Properties - OK saves the entire $project.conf: project
 settings and file list.

 File - Quit does both.


AFAICT build-set build commands-ok does neither, it assumes save at the
end, thats the problem, and why the save on quit is still needed and why
failing to save on shutdown is a breakage.
The build one is the one I know, my question is then what other dialogs or
menu items etc change settings but fail to cause a save because they still
assume save on exit?



 Saving dialog preferences and project settings on Quit does not make
 real sense, but it's the same file, so there is no reason to separate
 them. Yet they are internally separate (static) functions, see
 keyfile.c:configuration_save() and project.c:write_config().


Not sure what you mean by its the same file, its not the same file and
doesn't have the same contents?

Cheers
Lex



 --

 No interest in having 2+ sessions for a project?..

 --
 E-gards: Jimmy
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] PlugIn for Ruby Refactoring / Help overriding callbacks

[Lex Trotman]

On 2 October 2012 00:00, Rory Michele zaiba...@gmx.net wrote:

 Hi guys,

 I'm looking for help. To give you my level: I work as a (mostly ruby and
 java) programmer and have some experience on that level, but this would
 be my first bigger open-source project that I work on. So please be kind ;)



Hi Welcome,



 I would like to write a geany plugin trying to provide helpful ruby
 refactoring (I think thats the word, what I mean is looking up
 (possible) declarations and usages), that can extend or replace the
 functionality of go to tag declaration/definition. I wish for that
 because the current implementation looks only in open files as far as I
 understand and I would like to provide this on a project basis, therefor
 scanning also files not currently opened in geany.


Have you looked at both the project plugins, I think one or both do this?



 I know this is very intensiv to provide for ruby, however I'm thinking
 to provide it only at explicit wish (e.g. special button), not to bother
 the slim and fast design of geany. And as I'm doing the same for
 reverse engineering/understanding geany right now with grep, I think
 it should be possible at reasonable speed, unlike these java
 implementations that they scan and index all at the beginning and kill
 my memory ;) Now what do you think, is it appropriate to provide this
 for geany or is it against a concept or something?


I am not sure I understand what you are proposing, since would your plugin
not also kill your memory if it scans everything? It just won't do it
until you press the magic key.




 The features I currently have in mind:
  - a menu-point and keybinding for navigating to possible declarations
  - a second mode for auto-completion (maybe pressing space another
 time), that looks up possible classes the selected instance is of, to
 show only relevant tags for autocompletion
  - a menu-point and keybinding for listing possible usages (and the
 possibility to navigate there)


Just from a user point of view it might be better if your plugin just
replaced the Geany functionality rather than being an additional function,
but I guess that can be found by experiment.

The only one of the above that might be difficult(ish) is the second mode
which seems to depend on a key sequence not a simple binding.  Its not
impossible, just Geany doesn't do that and so will give you no assistance.
 Might be better as another keybinding.



 Now the Questions:
 I checked the demoplugin so in general I think I have a clue on how to
 create the plugin.
 Now what seems for me the best way to go would be to simple override the
 callbacks for the existing Go to Definition etc. keybindings (as the
 ui-buttons seem to also be using them).

The first relevant key_binding_id I would like to overide the callback
 for is GEANY_KEYS_GOTO_TAGDECLARATION.
 And it is mapped to a function in keybindings.c on line 1886.
 Now, this mapping I would like to overide. Is that possible and how? Or
 do I have to create new UI-Elements and link them to my function. I
 would not like the latter so much as the global settings for keybindings
 wouldn't have effect, wouldn't they?


Hmmm, normally plugins don't override existing keybindings, and there is an
argument that they should not set any keybindings until the user selects
which ones to use.  This is since the user can re-assign keycodes and the
plugin can't tell what system or other plugins may be using a particular
keycode.  Even if it could tell, it would normally be considered to be rude
to just splatter over it :(  This has been a problem in the past with
disagreements between plugins.

Normally plugins just add another keybinding section and let the user
assign codes, see for instance some of the plugins included with Geany for
how to (reasonably) conveniently do this.

As I noted above, in this case you may want to replace the normal
functionality when your plugin is active, but I'm not sure it is possible
at this time and you might have to intercept the keypress and grab it
before Geany sees it.  That of course adds complexity to your plugin and
makes the keybinding preferences settings wrong.


Cheers
Lex



 Thanks for your help and I'll be happy to clarify any questions
 rory
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

On 2 October 2012 00:43, Colomban Wendling lists@herbesfolles.orgwrote:

 Le 10/09/2012 06:36, Lex Trotman a écrit :
  Hi All,
 
  Its about that time of year when we have our annual discussion on
  separating session data from config/project data :)
 
  By session data I mean the list of currently open files and MRU list.
 
  The advantages (that I can see):
 
  1. Save config/project as its changed and not rushed at quit time (and
  the quit save doesn't happen in the absence of a working, portable,
  session management capability)

 TBH until proper multi-instance configuration sharing, I don't see
 what's so great with not rushing at quit time since we already also
 save one pref/project-prefs apply.


Are all settings saved on apply? not just the prefs/project prefs ones?  I
thought there were some that still didn't for one reason or another, maybe
that should be changed as a separate thing anyway, in which case you are
right, the rush only applies to session data.



  2. Save session data periodically, or as it changes, or whenever,
  without touching the config/project files.  So the config isn't at
  risk if the session save goes wrong.

 Why would the session save go wrong?  There is no reason I can think of
 that would make periodical session saving less safe than settings saving.


Read not happen for go wrong then.  Not happening because Geany is
killed by the WM/user is the most common way saving settings/sessions goes
wrong. If the save happens its unlikely to be a problem so long as its on a
local disk which isn't full.  If the project file is on a network share or
worse still, on a ftpfs/sshfs/httpfs file system then lots can go wrong
and the chances are increased by periodic saving (not to mention potential
performance issues).



  The only disadvantage for user config (that I can see) is that it adds
  one file, say geany.session.conf alongside geany.conf

 That's definitely not a problem in the $GEANY_CONF_DIR.


Agree, but I had to think of *some* disadvantage to seem fair and even
handed :)



  For project sessions just using another file in the same place as the
  project file is more of a problem since project files can be in the
  project tree and some people like to save them in VCS.  So users would
  have to make sure that their git.ignore (or whatever the other VCSes
  use) is edited each time so that the session file isn't saved in the
  VCS.

 I agree with Dimitar, if somebody is able to add a file to a VCS she
 must be able *not* to add that file.  Is there *any* VCS around that
 adds files without asking before, unless explicitly told so?  Nobody
 sane will do `git add .` or `svn add .` for committing changes.


Well, git add is part of the normal workflow, editing .gitignore isn't.
 But I guess if the project file is being stored in VCS then you would
expect .gitignore (or whatever svn etc use) to be edited already to exclude
.session and .gitignore to be stored in the VCS as well.



  A better option, especially since sessions are inherently user
  related, is to store them in the user config location (or subdirectory
  thereof).  But how to link these files to the project files?
 
  The proposal is that each project gets a UUID generated when it is
  created (or when its opened without one) which is saved in the project
  file.  This uuid is the name of the session file in the
  ${GEANY_CONFIG}/sessions directory.  That way, when a project is
  opened, it is easy to uniquely find the session file if it exists.
  Using things like filenames, project names etc will always have
  clashes.  Libuuid is used by GTK so it will always be available on all
  platforms we use and so making the UUID is one call. (Pity GTK doesn't
  expose it though)
 
  The number of session files can be left to grow like weeds, or can be
  trimmed to a (configurable) maximum number deleting the oldest when
  needed.

 PLEASE, no.  This is IMO the easiest solution to make the fix worst than
 the issue.  Not removing files would leave more and more useless files
 (not an option), and cleaning is almost impossible to do well -- your
 proposition might remove actually used sessions as easily as having 
 MAX_SESSION projects (not an option either).


Heh, heh, I was going to just say, sort by access time and delete the
oldest one before creating a new one, but then I remembered that all my
disks are mounted noatime :)


  This proposal isn't about a proper session management capability,
  there isn't one that works on enough platforms to be worth including.
 
  Any thoughts welcome.

 Reading my mail above, I see it might sound like I think $subject is
 just a bad idea.  No, I think it would be a quite good thing, and for
 weird people adding project files to their VCS [1] would be most
 welcome.  I also think that separating session and settings will
 probably help to someday improve the settings sharing between instances.

 The only problem is that I don't see immediate and tremendous gain

Re: [Geany-devel] ANN: mailing list server move

[Lex Trotman]

On 28 September 2012 06:40, Colomban Wendling lists@herbesfolles.orgwrote:

 Le 27/09/2012 22:36, Enrico Tröger a écrit :
  On 27/09/12 21:59, Colomban Wendling wrote:
  Le 27/09/2012 21:54, Enrico Tröger a écrit :
  Hi all,
 
  just as a note: I plan to move all Geany-related mailing lists from
  uvena.de to the geany.org server on Friday, October 5 2012, around
 12:00
  UTC.
 
  Great !  Just to be sure, current @uvena.de will be forwarded (at least
  for some time) to the equivalent one at @geany.org I guess, right? :)
 
  Yeah, that's the plan.
  The list names will stay the same (only top level domain changes) except
  for the main mailing list which is currently ge...@uvena.de. I guess
  I'll rename it to geany-us...@geany.org which reads better than
  ge...@geany.org.
 
  Any objections?

 Nope.  Maybe I'd rather have used something like
 {devel,users}@lists.geany.org but geany-{users,devel}@geany.org is fine
 too.



Just a thought, the website then needs updating :)

Cheers
Lex



 
 
  Regards,
  Enrico
 
 
 
 
  ___
  Geany-devel mailing list
  Geany-devel@uvena.de
  https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

Sorry for the delay in responding, somehow the mail didn't get marked as
new and I only just noticed it.

On 14 September 2012 03:15, Dimitar Zhekov dimitar.zhe...@gmail.com wrote:

 On Wed, 12 Sep 2012 11:35:48 +1000
 Lex Trotman ele...@gmail.com wrote:

  [...]
   So what should geany.conf contain? If the interface preferences remain
   there, we still must rush at quit time to save it...
 
  Getting buried in specifics far too early, need to get the principles
  right first, but in general interface things that are changed
  rarely, like window layouts, would be in geany.conf,  things like
  search data is definitely session.  I'm sure there is more discussion
  here :)

 Since it's an early discussion, I have a proposition for something I
 always wanted to have in the other IDE-s: several sessions per project.


Well, if sessions and projects are separated then it might be a useful
extension.



 For example, currently I have one project for Geany sm, another for
 regenerating my patches (the ones in sf patch tracker except sm, plus
 some others), and I usually open another (temporary) project when
 working on something else. Aside from the session, these projects are,
 and must be, absolutely identical. So:

 The project menu contains a Sessions item, which displays a dialog to
 add/remove/switch to a session.

 Each new project starts with a Default session, which can not be
 deleted.

 Whoever prefers a project for each session can simply ignore Sessions.

 Possible storage:

 $project.geany contains an UUID.

 $confdir/UUID contains a list of names sessions and the interface
 options, including the current session name.


Apart from having an intermediate link file between projects and sessions
making an extra step, what is the difference between this implementation
and the one I originally proposed?  The one that you said was too complex,
even before you added the intermediate step? :)

For those following along at home, the problem is how to find the session
file(s) when the project is opened, without saving the path in the project
file.  Any alternate ideas welcome.



 The larger a project, the more useful several sessions will be.

 I'm not sure about several project-less sessions. It will be somewhat
 confusing - should I use a project, or only a session? - but OTOH, the
 line between projects and sessions will be drawn once and for all: a
 project has it's own set of options, while a session is simply a set
 of files.


Thats certainly another way of looking at it, yes.  Makes it simple to
implement and understand.  But I bet it won't last :)



 RFC.

   (Note: the project files currectly contain the settings from Project -
   Properties and a session, but no interface options. The plugins can
   only place their own settings in the projects either, except by using
   the Project - Properties dialog.)
 
  Plugins access to the project files is another discussion.

 They must be discussed at some later point, we have save-settings and
 project-save.


I guess plugins can still access project files, but either they can't
access session files (preferred initial position until someone needs it) or
another signal is needed.

Cheers
Lex



 --
 E-gards: Jimmy
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Signal Handling

[Lex Trotman]

On 11 September 2012 11:47, Lex Trotman ele...@gmail.com wrote:
 On 11 September 2012 03:15, Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
 On Sun, 09 Sep 2012 19:41:19 -0700
 Matthew Brush mbr...@codebrainz.ca wrote:

 On 12-09-09 05:23 PM, Lex Trotman wrote:
  [...]
  So can anyone describe a useful use-case for catching SIGTERM and
  potentially refusing to exit?  And also for SIGINT.
 

 From what I see, signal_cb (used currently for SIGTERM only) looks like
 a naive attempt to replace the session management. That will never work,
 of course - either the WM will send a SIGKILL quickly (in 1-2 seconds),
 or the entire X will terminate, killing Geany.

 Thats my thoughts too, just wanting to see if anyone has any further info on 
 it.


 BTW, I'm happy to inform all Xfce users here that it's session
 management was fixed and pushed to git, so we may expect it with the
 next xfce-session versions. Using the Action Buttons plugin with
 Shutdown or Restart will still not work, but that's a different bug. Or
 maybe a feature, because the session settings specifically include the
 text ... on logout.

 Sorry I've changed DEs again :)


 For SIGINT, if it's handled, it'll ask if you want to save unsaved
 documents before closing when Ctrl+C is used from the terminal. Not
 saying whether we should handle it or not, just that it's why my tests
 included it.

 My whole X terminates if I run it from a virtual console and press
 Ctrl+C, so why should Geany handle the signal? Is this a normal
 practice for the GUI programs under X than I'm not aware of?

 And of course, the portability of signal(2) is so bad that only SIG_DFL
 and SIG_IGN can be trusted.

 Which is why it should only be handled via the mainloop, but as you
 say its very questionable if we want to do any handling of either of
 these signals anyway.

 Lets see if a reason emerges.

 Cheers
 Lex


Since Dimitar and I are in agreement that the current code is *WRONG*
and dangerous I will commit an initial patch to comment out the
sigterm handling soon.

I see no reason to have this at all, but a corrected version of the
commented out code may be added later if needed.

Cheers
Lex



 --
 E-gards: Jimmy
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Intermittent Project Close Error

[Lex Trotman]

Hi All,

I sometimes see an error on project close where the previously open files
are not restored, instead the project files are re-opened.

It only occurs very intermittently and I have not been able to find a
repeatable cause.

It has been present for a long time and is still present in the current Git
HEAD.

Has anyone else seen it and have any further information on how to trigger
it?

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] SourceForge Upgrade?

[Lex Trotman]

On 9 September 2012 21:29, Colomban Wendling lists@herbesfolles.org wrote:
 Le 09/09/2012 07:23, Matthew Brush a écrit :
 Hi,

 Is good yeah?
 https://sourceforge.net/p/upgrade?search=geany

 Why not.  I think we only really care about the project page and the
 tracker anyway, and the old tracker wasn't that awesome (especially
 since it stopped filtering the spam).

 But before going crazy, we should check whether it looks really OK, thus
 looking at it and checking a few points like:

 * Will the old URL to the tracker still work?  That'd truly be great.
 * Do we use any VCS hooks on SF?  I see they will be gone.
 * What's the implication of the donation button change?

 Etc.  BTW, I played a little with the thing a while ago in my user's
 page, you can look, and have fun with the tracker -- it's here fort
 tests don't worry.  Look at
 https://sourceforge.net/u/colombanw/geany-tickets/

 dream
 BTW, I don't know if the new thing supports it, but I'd really love VCS
 commits to close bugs when including Fixes #NNN, Closes #NNN and alike.
 /dream

 @Colomban, it's the one you mentioned was in Beta before?

 Yes, that was it.  Whether it's actually good or not I don't really
 know, but it looked shinier than the old SF.

Since SF wants us to do this, and as codebrainz points out is probably
going to force us at some point, we might as well do it.

If it makes it better, good, if it makes it worse then it hastens the
search for alternatives.

Cheers
Lex



 Cheers,
 Colomban
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

[...]
 So what should geany.conf contain? If the interface preferences remain
 there, we still must rush at quit time to save it...

Getting buried in specifics far too early, need to get the principles
right first, but in general interface things that are changed
rarely, like window layouts, would be in geany.conf,  things like
search data is definitely session.  I'm sure there is more discussion
here :)

[...] ...and if we keep these preferences it in the .session file(s?), we risk
 damaging them on some periodic save. Not so bad as losing geany.conf,
 of course, but still unpleasant.

Yes, losing session data is mildly annoying, but losing long term
settings is much more annoying.  Again this distinction helps to
separate which goes where.

[...]
 If by public you mean somewhere in the internet, I haven't seen a
 single OSS that includes with $project.geany, not even Geany itself or
 geany plugins.

No, by public I just mean used by more than one person.  And the
fact that you have to either give away sessions, or put up with the
project file changing each time you commit, could be a big part of why
nobody uses that capability.

[...]
 No, I use mostly svn. But removing file(s) from finished commits should
 not be easy (and Mercurial does not even allow it IIRC). Yet how is
 that our problem? And if it is, why should we even allow project files
 in the project tree? They can be shipped by mistake equally well.

Its a very common use-case to have the project files in the project
tree.  And it has become a general user expectation from other IDEs.
And since we keep adding settings to the project files they are slowly
becoming project files, rather than named session files that they
were originally.  Maybe they should have been called named sessions
not projects, then everyone, me included, might not put so many
settings in them.  Then we wouldn't have to separate them again as is
the point of the discussion.


 Moving the projects and sessions in ~/projects, ${GEANY_CONFIG}/projects
 or wherever can somehow be justified. But having the projects here-or-
 there,

Projects are already here or there, thats not a change.

and the sessions yet somewhere else via redirection, is a mess.
 It's a bit surprising that you, of all people, proposed such a thing.

Maybe its because I want to have both project files in VCS *and*
project sessions without VCS noise, I learned in my MBA that, given a
choice, take both :)

Better implementation suggestions welcome, its just the only one I
came up with so far that does the job :)


  [...]
 There are ~90 #if[n]def G_OS_WIN32 in Geany source. Expecting the
 session save to be operating-system portable is a bit too much.

Yeah, thats why it should be wrapped up in some library (even if its a
part of Geany) we don't want more #ifdefs in the general code.


 I have previously asked for somebody to check if SM works under GNOME3
 and Unity, but there was no response.

Can't help, don't have either.

[...]
  I guess it could support some other stuff too like window/find dialogs
  geometry/position, active tab, position within the file, etc.

 Just to clarify, stuff too like window/find dialogs means the
 interface options. If they are per session file, each project will have
 it's own appearance, something that Geany does not currently support.
 (Except with SM, and I find it very useful.)

Wasn't the intention of the discussion, but if it comes as a side effect fine.

[...]
 If we decide to continue with the single appearance (interface
 settings) for all projects, then a ${GEANY_CONFIG}/geany.interface
 would suffice, and geany.conf will be stable.

As I said, the user settings is easy, except for agreeing what goes in
which file :)


 (Note: the project files currectly contain the settings from Project -
 Properties and a session, but no interface options. The plugins can
 only place their own settings in the projects either, except by using
 the Project - Properties dialog.)

Plugins access to the project files is another discussion.

Cheers
Lex


 --
 E-gards: Jimmy
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Signal Handling

[Lex Trotman]

On 11 September 2012 03:15, Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
 On Sun, 09 Sep 2012 19:41:19 -0700
 Matthew Brush mbr...@codebrainz.ca wrote:

 On 12-09-09 05:23 PM, Lex Trotman wrote:
  [...]
  So can anyone describe a useful use-case for catching SIGTERM and
  potentially refusing to exit?  And also for SIGINT.
 

 From what I see, signal_cb (used currently for SIGTERM only) looks like
 a naive attempt to replace the session management. That will never work,
 of course - either the WM will send a SIGKILL quickly (in 1-2 seconds),
 or the entire X will terminate, killing Geany.

Thats my thoughts too, just wanting to see if anyone has any further info on it.


 BTW, I'm happy to inform all Xfce users here that it's session
 management was fixed and pushed to git, so we may expect it with the
 next xfce-session versions. Using the Action Buttons plugin with
 Shutdown or Restart will still not work, but that's a different bug. Or
 maybe a feature, because the session settings specifically include the
 text ... on logout.

Sorry I've changed DEs again :)


 For SIGINT, if it's handled, it'll ask if you want to save unsaved
 documents before closing when Ctrl+C is used from the terminal. Not
 saying whether we should handle it or not, just that it's why my tests
 included it.

 My whole X terminates if I run it from a virtual console and press
 Ctrl+C, so why should Geany handle the signal? Is this a normal
 practice for the GUI programs under X than I'm not aware of?

 And of course, the portability of signal(2) is so bad that only SIG_DFL
 and SIG_IGN can be trusted.

Which is why it should only be handled via the mainloop, but as you
say its very questionable if we want to do any handling of either of
these signals anyway.

Lets see if a reason emerges.

Cheers
Lex


 --
 E-gards: Jimmy
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Making directory?

[Lex Trotman]

Reference 
https://sourceforge.net/tracker/?func=detailaid=3440252group_id=153444atid=787791
last example the call to utils_mkdir() inside
utils_get_config_files().

Can anyone explain why a function that is meant to be listing config
files is creating an empty directory?

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Signal Handling

[Lex Trotman]

Hi All,

As pointed out here
https://sourceforge.net/tracker/?func=detailaid=3440227group_id=153444atid=787791
the current signal handling in Geany is broken.

Matthew tried my suggestion of g_unix_signal() but as Colomban noted
on IRC its a fairly new function (glib 2.30).  There was no resolution
of this after their tl;dr discussion on IRC.

I suggest that:

1. The current signal handling be removed, it is broken and
potentially extremely dangerous.  Simply letting the application exit
is safer.

2. g_signal_unix() be used when available, but the runtime
glib_check_version() must be used instead of the compile time
GLIB_CHECK_VERSION() since it is the target glib that matters, not the
build system one.  This of course requires lazy dynamic linking so
that it won't get a missing symbol error if g_signal_unix is not
available, but luckily its the default on most Linuxii.

3. Matthew has suggested adding SIGINT to the handling.  That raises
the question of why is this handling here anyway?

SIGTERM is used by window managers to signal imminent logout/shutdown.
 So there is no time for GUI checks to happen, and refusing to
shutdown is going to be ignored anyway.  For example, on my system if
Geany is running on shutdown, a warning from the WM flashes past and
goes away as the process is SIGKILLed for not dying quickly enough.

So can anyone describe a useful use-case for catching SIGTERM and
potentially refusing to exit?  And also for SIGINT.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Making directory?

[Lex Trotman]

On 9 September 2012 21:57, Enrico Tröger enrico.troe...@uvena.de wrote:
 On 09/09/12 13:11, Lex Trotman wrote:
 Reference 
 https://sourceforge.net/tracker/?func=detailaid=3440252group_id=153444atid=787791
 last example the call to utils_mkdir() inside
 utils_get_config_files().

 Can anyone explain why a function that is meant to be listing config
 files is creating an empty directory?

 Probably just to be safe.

 I agree that it looks wrong to create a directory in a function used to
 list contents of a directory.

 However, IIRC, the basic idea of the mkdir() itself was to create
 sub-directories in the user's config directory for his convenience. So
 the user sees after the first start of Geany which directories are read
 and so he sees where to place custom configs.

 The mkdir() call could be moved out of utils_get_config_files() into
 src/main.c:create_config_dir() where also other sub-directories in the
 user's config directory are created.
 Then those were all in one place which is probably good.

Hey Enrico,

That sounds like a much better suggestion.

Cheers
Lex



 Regards,
 Enrico

 --
 Get my GPG key from http://www.uvena.de/pub.asc


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

Hi All,

Its about that time of year when we have our annual discussion on
separating session data from config/project data :)

By session data I mean the list of currently open files and MRU list.

The advantages (that I can see):

1. Save config/project as its changed and not rushed at quit time (and
the quit save doesn't happen in the absence of a working, portable,
session management capability)

2. Save session data periodically, or as it changes, or whenever,
without touching the config/project files.  So the config isn't at
risk if the session save goes wrong.

The only disadvantage for user config (that I can see) is that it adds
one file, say geany.session.conf alongside geany.conf

For project sessions just using another file in the same place as the
project file is more of a problem since project files can be in the
project tree and some people like to save them in VCS.  So users would
have to make sure that their git.ignore (or whatever the other VCSes
use) is edited each time so that the session file isn't saved in the
VCS.

A better option, especially since sessions are inherently user
related, is to store them in the user config location (or subdirectory
thereof).  But how to link these files to the project files?

The proposal is that each project gets a UUID generated when it is
created (or when its opened without one) which is saved in the project
file.  This uuid is the name of the session file in the
${GEANY_CONFIG}/sessions directory.  That way, when a project is
opened, it is easy to uniquely find the session file if it exists.
Using things like filenames, project names etc will always have
clashes.  Libuuid is used by GTK so it will always be available on all
platforms we use and so making the UUID is one call. (Pity GTK doesn't
expose it though)

The number of session files can be left to grow like weeds, or can be
trimmed to a (configurable) maximum number deleting the oldest when
needed.

This proposal isn't about a proper session management capability,
there isn't one that works on enough platforms to be worth including.

Any thoughts welcome.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Squiggle pixmap

[Lex Trotman]

Hi All,

Colomban has now kindly imported the latest Scintilla into HEAD.  It
includes Matthews alternative squiggle indicator.  This improves the
performance when a significant amount of squiggly underlining is
present (think C++ compiles, when spell check doesn't like your words
etc).

I was going to make an option to select which indicator to use, but
after some thought I believe its better to simply switch to always
using the alternative because:

1. at least on Linux it looks as good as the original, this needs to
be checked on other platforms

2. reduces the incidence of performance complaints due to this
problem, so we don't have grumpy users in the first place, and don't
have to guide them through editing the setting where ever it is
located (filetypes.common probably with all the marker settings)

Note that as this should not be a commonly used setting, there is no
need for a GUI setting, or if it turns out to be common, that just
supports my argument to use it all the time.

If no one has any substantive issues in the meantime I'll commit the
attached patch in a couple of weeks.

Cheers
Lex


squiggle.patch
Description: Binary data
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Logical vs. display line movements -- answering #3041948

[Lex Trotman]

On 29 August 2012 22:39, Colomban Wendling lists@herbesfolles.org wrote:
 Le 29/08/2012 02:34, Lex Trotman a écrit :
 On 29 August 2012 04:02, Colomban Wendling lists@herbesfolles.org 
 wrote:
 Hi guys,

 I took a look at #3041948 [1] and did a prototype patch (attached) to
 fix it.  Basically it's about the behavior of the Home and End keys
 regarding wrapped lines.  We have configurable keybindings already, but
 they don't really make the editor display-line-friendly since they don't
 change the behavior of ShiftHome and ShiftEnd, aka selection extension.

 Instead of repeating me, I'll quote the attached patch:

 Add setting to make Home and End keys navigate in display coordinates

 This cannot really be mapped using the keybinding because holding
 Shift together with Home or End is expected to behave exactly the
 same as without it but extending the selection;  which is tricky to
 get using configurable bindings.

 For this setting to behave correctly, the Home and End keys should
 obviously not be bound to any action, so the default bidings of Home
 and End should most probably be removed.  Maybe the Go to [display]
 line start/end actions should be removed altogether now a global
 setting can be used to choose one behavior or the other;  but they can
 also be kept but unmapped by default, which would allow a user to map
 another key to this action (like CtrlA and CtrlE to emulate a
 Bash/Emacs-like behavior).

 Closes #3041948.

 So, what do you think?  Is this a correct way to fix this, or should we
 rather either add (4) separate configurable bindings for extending the
 selection to the start/end?  Or should we add a trick to extend
 selection when Shift is pressed together with one of the current
 bindings (that's probably not a good idea in the (unlikely) case one
 binds one of these actions to ShiftSomething)?

 Also, should we remove the bidings if we add that?  Or should be just
 not bind them by default?

 What about backward compatibility?

 Hi Colomban,

 Hey Lex,

 Backward compatibility is absolutely essential, Geany must ship
 working as it does now !!!

 I inserted other words than backward and compatibility in my mail,
 you know? :D

Hey Colomban,

My fingers typed that by themselves, they are very sensitive to any
suggestion that they should re-learn their muscle memory :)


 I don't see the point of going to the end of the visual line since
 that is just some arbitrary point at which the line is wrapped, it is
 unlikely to be significant, except you might want to add a line break
 there.  Going to the actual start and end of the line is much more
 common IMNSHO, so it should be the default (as it is now).

 This depends a lot on what's the displayed text I think.  When writing
 programming languages yes, going to the visual EOL doesn't seem so
 useful;  but if writing a long paragraph, you may want to move rapidly
 to a position that happens to be near visual EOL, so you might want to
 hit End.

There is a might multiplied by a happens to be in that paragraph,
so its still very low probability that end of display line is useful.

The one use-case I can see for display line operation is editing
million character single line HTML.  Given that this is a small
use-case I proposed the simplest and easiest to maintain solution, so
those who insist on doing that sort of thing, can set Geany up how
they want.


 Moreover, since visual lines may only be different from logical lines
 when line wrapping is enabled, one might argue that most people don't
 care for programming languages since most people don't activate line
 wrapping on them.

Yep, which is why *most* of the use of home and end and the related
select extend is physical lines, and the operation shouldn't change in
the rare occasion when wrapping is turned on.


 If a user prefers to navigate by visual line, fine, they can change
 the bindings as you said.

 The best way of handling extend selection to end of visible/real
 line would be to also make those keybindings that the user can set,
 with defaults as now and shiftalthome/end for the extend visual.
 So again Geany works as now by default, the opposite behaviour is
 available, and users who prefer it can change the bindings to make it
 their default.

 This is doable, but:

 1) it adds 4 new useless keybindings

Of course I would claim that we can ship with the the display line
actions unbound but ymmv. :)

 2) somebody who wants to change to display line mode needs to change 8
 bindings (well, 4 manually at least).

True if you want display line all the time, for the few times most
people will need that, having separate bindings don't screw with their
existing bindings.


 I totally agree however it's a perfectly OK solution, and that it has
 the main advantage of not raising any other questions.


Don't underestimate the size of that advantage :)


 However, first note that the patch I proposed do NOT change anything by
 default and WON'T break any

Re: [Geany-devel] Logical vs. display line movements -- answering #3041948

[Lex Trotman]

On 29 August 2012 04:02, Colomban Wendling lists@herbesfolles.org wrote:
 Hi guys,

 I took a look at #3041948 [1] and did a prototype patch (attached) to
 fix it.  Basically it's about the behavior of the Home and End keys
 regarding wrapped lines.  We have configurable keybindings already, but
 they don't really make the editor display-line-friendly since they don't
 change the behavior of ShiftHome and ShiftEnd, aka selection extension.

 Instead of repeating me, I'll quote the attached patch:

 Add setting to make Home and End keys navigate in display coordinates

 This cannot really be mapped using the keybinding because holding
 Shift together with Home or End is expected to behave exactly the
 same as without it but extending the selection;  which is tricky to
 get using configurable bindings.

 For this setting to behave correctly, the Home and End keys should
 obviously not be bound to any action, so the default bidings of Home
 and End should most probably be removed.  Maybe the Go to [display]
 line start/end actions should be removed altogether now a global
 setting can be used to choose one behavior or the other;  but they can
 also be kept but unmapped by default, which would allow a user to map
 another key to this action (like CtrlA and CtrlE to emulate a
 Bash/Emacs-like behavior).

 Closes #3041948.

 So, what do you think?  Is this a correct way to fix this, or should we
 rather either add (4) separate configurable bindings for extending the
 selection to the start/end?  Or should we add a trick to extend
 selection when Shift is pressed together with one of the current
 bindings (that's probably not a good idea in the (unlikely) case one
 binds one of these actions to ShiftSomething)?

 Also, should we remove the bidings if we add that?  Or should be just
 not bind them by default?

 What about backward compatibility?

Hi Colomban,

Backward compatibility is absolutely essential, Geany must ship
working as it does now !!!

I don't see the point of going to the end of the visual line since
that is just some arbitrary point at which the line is wrapped, it is
unlikely to be significant, except you might want to add a line break
there.  Going to the actual start and end of the line is much more
common IMNSHO, so it should be the default (as it is now).

If a user prefers to navigate by visual line, fine, they can change
the bindings as you said.

The best way of handling extend selection to end of visible/real
line would be to also make those keybindings that the user can set,
with defaults as now and shiftalthome/end for the extend visual.
So again Geany works as now by default, the opposite behaviour is
available, and users who prefer it can change the bindings to make it
their default.

Cheers
Lex



 Looking forward to read you :)
 Regards,
 Colomban


 [1]
 https://sourceforge.net/tracker/?func=detailatid=787791aid=3041948group_id=153444

 PS: This uses 2 new Scintilla (not yet released) commands to respect
 smart home key feature when dealing with display lines, so you'll need
 a patch for that too -- attached.
 PPS: 3rd patch is to make move to start of display line command
 respect the smart home feature, too.

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Windows Build commands

[Lex Trotman]

Hi Enrico or some other Windows dev,

Had a report on IRC from a new Windows Geany user that when they
installed Geany the C compile command was gcc -m32 “%f” -o “%e.exe”
which didn't work, but when they pressed the reset in the build
commands dialog the command changed to the normal gcc -Wall -o %e
%f which worked.

Is the build command being deliberately changed on windows builds or
is it something picked up from the build environment accidently?  And
if it is deliberate, it doesn't seem to work?

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany-Plugins Dependency Consolidation

[Lex Trotman]

On 5 August 2012 21:47, Frank Lanitz fr...@frank.uvena.de wrote:
 On Sun, 5 Aug 2012 10:21:04 +1000
 Lex Trotman ele...@gmail.com wrote:

 On 5 August 2012 03:40, Matthew Brush mbr...@codebrainz.ca wrote:
  On 12-08-04 09:41 AM, Colomban Wendling wrote:
 
  [...]
 
  So... maybe I got your point wrong, but I don't think it's any
  kind of a problem to have different dependencies from one plugin
  to another -- actually, I think each plugin should set it
  dependencies to exactly what it needs: nothing less (of course),
  and nothing more.
 
 
  You got it mostly. I just mean some way for the build system to
  handle multiple plugins sharing same dependencies like having
  webkit.m4 that enables/disables multiple plugins if not found. So
  when you configure, it says something like this:
 
checking for WebKit = x.xx ... no
   Disabling plugins: WebHelper, Devhelp, Markdown

 I don't see this, the *plugin* should define what it needs, not some
 arbitrary external build script.  My (limited) understanding of the
 plugin autofoo is that is how its done now by having local build
 scripts in each plugin.

 If they require different versions that might mean you get Webhelper
 and Devhelp but not Markdown, but your scheme won't allow that.  So if
 the Markdown dev added some new feature that needed a higher version I
 can't build the other two unless I upgrade my system :(

 We should not be forcing the *highest* version needed by plugins.

 I agree. But I also see the point of consolidation of dependencies. Its
 getting really complicated to say geany-plugins needs this dependencies,

Well, I am not sure that we should be saying geany-plugins has
dependencies anyway.  IIUC, at least Debian packages each plugin
separately anyway.  I can't speak for other distros but it makes sense
for users to be able to get just the plugins they want.

Building the whole lot from source or git is fine, plugins that don't
have their needs met don't build, but do tell you about it.

 but I think its an issue we need to solve on social level, not trying

So I agree with Colomban, that there isn't anything to solve,
different plugins have different dependencies, thats life.

However I agree that checking what dependencies are specified is
worthwhile from time to time, to make sure that the list is right in
Autofoo and the documentation.

Cheers
Lex

 to solve it with some hack. Is there any chance to get a complete list
 which plugins depend on which library out of autotools?

 Cheers,
 Frank
 --
 http://frank.uvena.de/en/

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany-Plugins Dependency Consolidation

[Lex Trotman]

On 6 August 2012 05:35, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-08-05 07:57 AM, Frank Lanitz wrote:

 On Sun, 5 Aug 2012 16:55:07 +0200
 Frank Lanitz fr...@frank.uvena.de wrote:

 For a list of the dependencies, you can look through the `build`
 directory's .m4 files and manually extract them (like I did for some
 of the shared ones previously). The ones with the highest versions
 will be the minimum version required to build geany-plugins (as a
 whole).


 Maybe building a script doing this would be a good idea.


 Having checked a couple of them I found it will be hard as they differ
 in way defining the dependencies...


 Yep and most don't specify their shared dependencies (GTK, GLIB, etc.)
 explicitly but assume that if you have the Geany, you have what they need.

Agree with you that that is bad, they should be specified so that
users can be sure that the plugin dev meant any version will do
rather than that they just forgot to specify it :)

Cheers
Lex



 Cheers,
 Matthew Brush
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany-Plugins Dependency Consolidation

[Lex Trotman]

On 5 August 2012 03:40, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-08-04 09:41 AM, Colomban Wendling wrote:

 [...]

 So... maybe I got your point wrong, but I don't think it's any kind of a
 problem to have different dependencies from one plugin to another --
 actually, I think each plugin should set it dependencies to exactly what
 it needs: nothing less (of course), and nothing more.


 You got it mostly. I just mean some way for the build system to handle
 multiple plugins sharing same dependencies like having webkit.m4 that
 enables/disables multiple plugins if not found. So when you configure, it
 says something like this:

   checking for WebKit = x.xx ... no
  Disabling plugins: WebHelper, Devhelp, Markdown

I don't see this, the *plugin* should define what it needs, not some
arbitrary external build script.  My (limited) understanding of the
plugin autofoo is that is how its done now by having local build
scripts in each plugin.

If they require different versions that might mean you get Webhelper
and Devhelp but not Markdown, but your scheme won't allow that.  So if
the Markdown dev added some new feature that needed a higher version I
can't build the other two unless I upgrade my system :(

We should not be forcing the *highest* version needed by plugins.

Cheers
Lex

   checking for LibVTE = x.xx ... no
  Disabling plugins: Debugger, MultiTerm

 Instead of:

   checking for WEBHELPER ... no
   checking for DEVHELP ... yes
   checking for MARKDOWN ... no
   checking for DEBUGGER ... no
   checking for MULTITERM ... yes
   
   Plugins:
 WebHelper   no
 Devhelp yes
 Markdownno
 Debuggerno
 MultiTerm   yes

 Cheers,
 Matthew Brush


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] patch: separated session/local config

[Lex Trotman]

On 4 August 2012 10:21, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-08-03 10:05 AM, Dimitar Zhekov wrote:

 On Thu, 2 Aug 2012 10:57:22 +1000
 Lex Trotman ele...@gmail.com wrote:

 So I think we should keep Dimitars patch available for as long as he
 cares to maintain it so individual users can add it if they want, but
 the variability makes it inappropriate to commit to Geany.



 If the changes were properly guarded out and disabled by default at
 compile-time, I see no reason not to merge the patch into master. I haven't

My problem isn't so much with the patch, it worked fine last time I
had a working DE.  Although it probably should be broken into a few
commits to separate some of the preparatory changes from the actual
SM stuff. My concern is rather with the maintenance issues if it is in
git master.  Unfortunately I expect lots of I turned it on for some
DE and it didn't work but firefox, gedit, etc does, fix it waaa
waaa waaa if we did that.

 really reviewed the changes in detail though. IMO, the patch tracker on
 sf.net is barely a step up from being local to Dimitar's hard-drive in terms
 of exposure and usefulness to general users.

Yes agree that the patch tracker isn't ideal, it probably should be a
git branch that Dimitar can maintain and then it is more visible
without increasing his workload.



 Pretty much infinitely, Geany without sm would be a big downgrade to
 me. I'm not going to support the git branch though, and it's already
 out of date.


I thought the Git branch was Eugenes and he already said it could be removed??

If my memory is right, then removing it and applying the patch to a
new_sm branch would be the way to go.



 I don't mind keeping the Git branch up to date if it helps keep some
 exposure on this useful patch, but it seems I don't get emails when the
 patch tracker is updated, so I dunno. I'm Monitoring the patch tracker but
 apparently I wasn't Watching it, so maybe now I'll get emails when there's
 updates now that I'm Watching it (unless I also have to Like it or
 Friend it or something). Of course if you want me to take the Git branch
 down instead, I can do that too.

Its SF, you have to stand on one leg, spin around three times while
the wind is in the southwest and sprinkle pixie dust, easy :)


Cheers
Lex


 Cheers,
 Matthew Brush

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] patch: separated session/local config

[Lex Trotman]

On 4 August 2012 11:14, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-08-03 05:58 PM, Lex Trotman wrote:


 I thought the Git branch was Eugenes and he already said it could be
 removed??


 See below.


 If my memory is right, then removing it and applying the patch to a
 new_sm branch would be the way to go.


 I pushed the libsm patch from the patch tracker to a new Git branch[1] a
 couple weeks ago or so, expecting to be getting emails from sf.net when the
 patch tracker was updated to queue me to apply the latest patch to the Git
 branch.

 IMO, it makes more sense to maintain it as a branch (or merging into the
 master branch) in the Git repository, even thought the patch tracker item is
 meticulously well documented/commented/updated. If Dimitar doesn't mind
 working on the Git repo instead of keeping a sf.net patch tracker item up to
 date, I'd be +1 for that.

Ah, missed that one :)

So totally agree, Dimitar should be given rights to maintain this
instead of the patch if he wants to.

Cheers
Lex


 Cheers,
 Matthew Brush

 [1]
 https://github.com/geany/geany/commit/0f07b31aa866f92dcbaf29659ead7beab60a1dde

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Indicators improvement

[Lex Trotman]

Matthew,

Try this attachment.

Cheers
Lex


Indicator.patch
Description: Binary data
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Code formatter

[Lex Trotman]

On 18 July 2012 12:32, Jacob Strohm jacobstr...@gmail.com wrote:
 Hello all,

 Does Geany have any kind of automatic code formatter, either in the core
 or as a plugin?  Looking through the plugins project/website, I didn't see
 anything like it, and if not I think I'd enjoy working on it in my free
 time, I just wanted to double check before investing a bunch of time.

No there is no such built-in although many people use custom command
to do that 
http://www.geany.org/manual/current/index.html#sending-text-through-custom-commands.

Cheers
Lex


 Thanks,
 Jacob Strohm
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Third party plugin publish and third party library bundle problem

[Lex Trotman]

On 15 July 2012 21:03, Hong Xu d...@hong.me wrote:
 On 07/15/2012 07:01 PM, Hong Xu wrote:

 On 07/15/2012 03:40 PM, Frank Lanitz wrote:

 On Sun, 15 Jul 2012 09:27:46 +0800
 Hong Xu d...@hong.me wrote:

 And, BTW, why geany-plugins project doesn't use a submodule for each
 plugin? Not all people need to clone the whole repository, and as it
 is separated to submodules, the permission control can be better for
 developers.


 IIRc this was under discussion in past but was dismissed due to adding
 complexity and little overall understanding of this. However, I don't
 think cloning the repository is this much traffic. Also a goal was to
 have plugins and its patches being reviewed before entering master to
 enforce a minimum on quality. This also includes some
 fire-and-forget-plugins of some developers as you can see from
 MAINTAINERS files there are a lot of plugins out of maintenance.


 Thanks. However, I have to make a pull request for any trivial changes
 in this way. Do you think this is unnecessary?

 In you mind, is there any advantages for geany plugins in this repo
 other than other places?


 Sorry, any *other* besides the quality enforcement?

Well, of course the geany-plugins is packaged for at least some
distros, in particular debian and ubuntu.  That will of course get
greater exposure, and maybe contributions, and also maybe bug reports
:)

BTW you mentioned a third party library, but you didn't say what
library.  It would of course have to have a suitable license to allow
it to be included.

Cheers
Lex




 Hong


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] draggable tabs - current state?

[Lex Trotman]

On 14 July 2012 20:21, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 14.07.2012 04:20, schrieb Lex Trotman:

 On 14 July 2012 07:07, Sean Felipe Wolfe ether@gmail.com wrote:

 I'd like to be able to have 2-3 columns of tabs and be able to drag +
 rearrange, something like Eclipse's draggable tab setup -- one of the
 few things I like about Eclipse.

 I assume this is non-trivial ... how horribly difficult would it be?

 Multiple columns/rows of tabs, how hard can it be?

 @#* hard, AFAICT you will have to change GTK, not Geany.

 Note drag re-ordering already works.

 Cheers
 Lex



 Can I at least have multiple sidebars with tabs being draggable between them
 (or make the message window a sidebar) ? :)

Hi Thomas,

Well, tabs are part of the GTK notebook that the edit window is in, so
to put them in a sidebar you would be re-implementing part of GTK,
maybe instead look at making the document sidebar re-orderable instead
of sorted?


 Currently Geany isn't so nice on a wide screen setup because much of the
 horizontal space is wasted, being bound to 80 or 100 column limit for source
 code. Vertical space is wasted because the message window could be a sidebar
 on wide screens.

Agree that widescreens are not a very good fit, so to maximise
vertical space I hide the message window whenever possible and put the
tabs on the left, you certainly can fit many more in there than on
top, and for me thats enough.  YMMV of course.

Although the message window contents doesn't usually use the entire
screen width, having the message window in the sidebar restricts its
width too much IMHO and of course split window wouldn't fit any more.

Cheers
Lex


 Best regards.

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Introduction

[Lex Trotman]

On 28 April 2012 12:18, Jacob Strohm jacobstr...@gmail.com wrote:
 Hello all,

 I'm interested in beginning to contribute to Geany.  I'm a freshman CS
 major and I often find myself with way too much free time and needing
 something productive to do.  As I've enjoyed using Geany, its something I'd
 like to get involved in.  However, open source (and projects in general
 written by more than 2 people) is new to me, so I'll probably take it slow
 for a while.  Any advice is greatly appreciated.


Best advice:

1. read the HACKING file

2. re-read the HACKING file :)

3. make a github clone and start hacking on something, eg a bug or
small feature, announce here so we don't have more than one person
doing it and to get advice.

4. read the HACKING file to see what you didn't understand the
importance of before you started :D

5. make a pull request on github to get it included in Geany

Cheers
Lex


 Thanks,
 Jacob
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] More Per-Project Configuration Options

[Lex Trotman]

On 10 July 2012 09:57, Braden Walters meobl...@aol.com wrote:
 Hi. I noticed a problem that affected me back in 0.2x that thankfully is
 (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem
 affects me right now, but possibly not for others, and I feel this may also
 affect me again eventually. The problem I noticed is that not all
 configuration options that may change from project-to-project are actually
 settings you can change on a per-project basis. The options that concern me
 the most are those that deal with the format of the saved file (line ending
 characters, new line at end of file (fixed in 1.22), tabs/spaces (not a
 problem), file encoding). I'm interested in the developers' opinions on
 this.


The right answer to this is that everything should be able to be
configured in a project, but that not everything has to be.  This just
means that project settings override global/user ones.  But it does
make the UI more complex, it needs another preferences dialog for
projects with an extra checkbox per field which indicates if that
value is to be saved in the project file.

This is the way the build system settings work ATM, two dialogs, and
in an effort to reduce confusion the user settings are greyed out if
the setting is set in the project file.  But it ends up needing a very
complex UI and still not all build settings supported by the system
are configurable by UI, no agreement could be reached over how to make
it non-threatening for noobs but still powerful for advanced users.
And ocassionally it provakes screems of confusion, though usually from
those who havn't RTFM and wiki.

All these problems would apply to the whole preferences system if it
worked this way.

Also it would require consideration of how this would interact with
plugin prefs.  How much visibility would plugins need and how much
more complicated would it make plugins handling of their prefs?

On the implementation side, not all of Geany prefs are handled in one
place, so it would probably mean touching quite a lot of the system.

 Someone in IRC also mentioned that if many more options become configurable
 per-project, the global application options might be rendered useless (as
 project settings will override everything). Perhaps this could be solved by
 having a way to reset individual project options (perhaps a list of all
 things that have been changed, and a Reset to Global button to reset that
 individual item so it does not appear in that project's file).

Just a save in project checkbox, that lets you save/unsave it w/o
changing the value.


 I'm curious what the core developers' opinion is on this. If it sounds good,
 I'd definitely be interested in helping make it possible (although I don't
 know the Geany code base, I could learn my way around relevant parts).

The principle is fine, but the build system experience is that the
practice is harder to balance simplicity with power.  Also, whilst the
capabilities are absolutely essential for a few use-cases, most of the
time it will go unused.

Therefore given the effort required and the likely intrusiveness of
the implementation, I don't think it should be implemented at the
moment, unless someone wants to do it in a separate fork and can get
comprehensive testing of that fork without merging it back into Geany.

Cheers
Lex


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] More Per-Project Configuration Options

[Lex Trotman]

On 10 July 2012 12:34, Braden Walters meobl...@aol.com wrote:
 Regarding the UI, I don't think it's necessary to put a checkbox next to
 everything. You could include a separate tab (something like Details)
 which would then have a list of all changes made to the individual project.
 And then a button to remove that and restore to defaults. This would
 simplify at least the UI, because it'd just be a subset of the global
 preferences with an extra tab for the Details (or whatever it'd be
 called). Does this concept make sense?

Its not just settings that have different values that should be saved
in projects. Ones that you want to make sure that they do *not* change
when user settings change also need to be stored (that was covered on
IRC).

Therefore it still needs the checkbox per setting (or some other
boolean UI mechanism), and it should be on the same page so you can
see which are set by the project and which are not.


 Regarding plugins. That could be a problem. Perhaps at first plugin
 preferences should not be available on a per-project basis, as I could
 imagine that could be something quite complex to tag onto an already big
 job. Or is there another problem regarding plugins that I am not
 recognizing?

Well plugins are maintained by people outside the project, with
varying skills and experience, time availability etc.  The Geany
project can't force plugins to do anything, so any changes need to
work as-is unless the plugin maintainer opts in to using the extra
functionality.  This is a decision by the *plugin* not Geany and so
Geany has to somehow notice and accomodate that decision as plugins
are loaded.

Cheers
Lex




 On 07/09/2012 10:26 PM, Lex Trotman wrote:

 On 10 July 2012 09:57, Braden Walters meobl...@aol.com wrote:

 Hi. I noticed a problem that affected me back in 0.2x that thankfully is
 (mostly) solved in 1.22. When I say mostly, I mean it fixes how the
 problem
 affects me right now, but possibly not for others, and I feel this may
 also
 affect me again eventually. The problem I noticed is that not all
 configuration options that may change from project-to-project are
 actually
 settings you can change on a per-project basis. The options that concern
 me
 the most are those that deal with the format of the saved file (line
 ending
 characters, new line at end of file (fixed in 1.22), tabs/spaces (not a
 problem), file encoding). I'm interested in the developers' opinions on
 this.

 The right answer to this is that everything should be able to be
 configured in a project, but that not everything has to be.  This just
 means that project settings override global/user ones.  But it does
 make the UI more complex, it needs another preferences dialog for
 projects with an extra checkbox per field which indicates if that
 value is to be saved in the project file.

 This is the way the build system settings work ATM, two dialogs, and
 in an effort to reduce confusion the user settings are greyed out if
 the setting is set in the project file.  But it ends up needing a very
 complex UI and still not all build settings supported by the system
 are configurable by UI, no agreement could be reached over how to make
 it non-threatening for noobs but still powerful for advanced users.
 And ocassionally it provakes screems of confusion, though usually from
 those who havn't RTFM and wiki.

 All these problems would apply to the whole preferences system if it
 worked this way.

 Also it would require consideration of how this would interact with
 plugin prefs.  How much visibility would plugins need and how much
 more complicated would it make plugins handling of their prefs?

 On the implementation side, not all of Geany prefs are handled in one
 place, so it would probably mean touching quite a lot of the system.

 Someone in IRC also mentioned that if many more options become
 configurable
 per-project, the global application options might be rendered useless (as
 project settings will override everything). Perhaps this could be solved
 by
 having a way to reset individual project options (perhaps a list of all
 things that have been changed, and a Reset to Global button to reset
 that
 individual item so it does not appear in that project's file).

 Just a save in project checkbox, that lets you save/unsave it w/o
 changing the value.

 I'm curious what the core developers' opinion is on this. If it sounds
 good,
 I'd definitely be interested in helping make it possible (although I
 don't
 know the Geany code base, I could learn my way around relevant parts).

 The principle is fine, but the build system experience is that the
 practice is harder to balance simplicity with power.  Also, whilst the
 capabilities are absolutely essential for a few use-cases, most of the
 time it will go unused.

 Therefore given the effort required and the likely intrusiveness of
 the implementation, I don't think it should be implemented at the
 moment, unless someone wants to do it in a separate fork

Re: [Geany-devel] Third party plugin publish and third party library bundle problem

[Lex Trotman]

On 10 July 2012 14:07, Hong Xu d...@hong.me wrote:


 On Jul 7, 2012, at 13:39, Hong Xu d...@hong.me wrote:

 Hi,

 I have developed the EditorConfig plugin for Geany 
 https://github.com/editorconfig/editorconfig-geany.

 
 EditorConfig helps developers define and maintain consistent coding styles 
 between different editors and IDEs. The EditorConfig project consists of *a 
 file format* for defining coding styles and a collection of *text editor 
 plugins* that enable editors to read the file format and adhere to defined 
 styles. EditorConfig files are easily readibly and they work nicely with 
 version control systems. Website here http://editorconfig.org
 

 However, I am confused how to publish this plugin.

 First, http://plugins.geany.org is a place for plugin list. But are the 
 third party plugins allowed here? All the pages seem working for the plugins 
 here: https://github.com/geany/geany-plugins including the download page, 
 installation page.

 Whatever the answer is, can I put my plugin in 
 https://github.com/geany/geany-plugins ? This repository seems better 
 maintained than mine.

 The second problem is that, how should I bundle a third party C library with 
 my plugin?

 Thank you!



 Would any one offer some help on this? Thank you!

Patience, the plugin project is trying to get a release out.  I am
sure they will help you as soon as they can.

Cheers
Lex



 Hong
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Treebrowser patch

[Lex Trotman]

On 6 July 2012 16:02, Frank Lanitz fr...@frank.uvena.de wrote:
 Am 06.07.2012 03:39, schrieb Lex Trotman:
 Frank, Colomban,

 Since you seem to have adopted treebrowser by the latest commits :)

 I've just done some C89/90 related changes. ... Tz tz tz. ;)

Heh, by naming the most prolific recent committers I was hoping that
one of them would ensure that the simple patch made it in before the
release, after all having a preference that can be set in several ways
but is never tested anywhere is kinda fundamental :)

Cheers
Lex


 Cheers,
 Frank

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [Geany] ANN: Geany-Themes 1.22 Released

[Lex Trotman]

On 6 July 2012 18:10, Liviu Andronic landronim...@gmail.com wrote:
 On Thu, Jun 28, 2012 at 5:18 AM, Matthew Brush mbr...@codebrainz.ca wrote:
 I'm hoping to make the releases/tarballs somewhat predictable to make it
 easier for distro package maintainers who want to create Geany-Themes
 packages. The main version number will follow Geany's and releases in
 between Geany releases will have a micro number like 1.22.1, 1.22.2, etc.

 Is there any reason for not releasing geany-themes as part of
 geany-plugins? Currently there are no geany-themes packages in either
 Ubuntu or a PPA (not sure about other distros), and being part of the
 plugins package would likely increase the probability that
 geany-themes would make the official repos.

Hi Liviu,

As you can see from the URL geany-themes are currently part of
Matthew's personal github repos so for now they can't be part of Geany
releases.

As their popularity seems to be rising, after the release I would say
that they should be included into the geany repos, also so that it
doesn't put the load so much on one person.

I wouldn't make it part of plugins though, the targets of the two
collections are somewhat different, a Geany/themes repo will let the
distros package it separately (as most seem to do with themes for
other projects).

Cheers
Lex


 Please let me know. Regards
 Liviu
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Any suggestions where message is from?

[Lex Trotman]

Hi All,

Any suggestions where the messages below come from?  I've run outa
time and patience.

(geany:2673): Gtk-CRITICAL **: IA__gtk_tree_store_remove: assertion
`VALID_ITER (iter, tree_store)' failed

(geany:2673): Gtk-CRITICAL **: IA__gtk_tree_store_remove: assertion
`VALID_ITER (iter, tree_store)' failed
*

They seem to happen when only on the first time I select a tab of
filetype None so I'm guessing its something in symbols?

Geany git HEAD, gtk 2.24.10 glib 2.30.2.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Treebrowser patch

[Lex Trotman]

Frank, Colomban,

Since you seem to have adopted treebrowser by the latest commits :)

Attached patch makes the show hidden files option work.

Bug Tree browser doesn't show hidden files - ID: 3539255

Cheers
Lex


tree.patch
Description: Binary data
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Crash when pasting a Zero-width space

[Lex Trotman]

On 27 June 2012 11:36, Lex Trotman ele...@gmail.com wrote:
 [...]

 And the answer from Neil is:

  This feature was actually contributed by ActiveState.

 We have had a report of an infinite loop in Geany when an attempt is
 made to draw a block Caret on a zero width space character (u200b).

  The backtrace makes the problem appear to be in DrawBlockCaret so
 you could switch to the standard line caret.

  There are features in Scintilla that I have accepted despite
 thinking they are a poor idea, such as the block caret. Perhaps the
 people that like this feature can work on fixing it.

 Cheers
 Lex

But another contributor to Scintilla provided the attached patch to
prevent the infinite loop.

Drawing a block cursor over a zero width character is going to be a
tough ask though :)

Cheers
Lex


scintilla.patch
Description: Binary data
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Crash when pasting a Zero-width space

[Lex Trotman]

On 26 June 2012 19:18, Harold Aling ge...@sait.nl wrote:
 A collegue of mine needed a zero-width space[1] for a breaking a word
 at a specific place in the menu of a website, so I copy/pasted mA
 (last character of first line, first character of next line) from the
 Wikipedia example, pasted it in Geany and deleted the m and the A so
 that there would only be a zero-width space left to copy by using
 ctrl-a, ctrl-c.

 Geany however crashed when there was only a zero-width space left in
 the document ;)

 Dunno if this is worth looking at, though ;)


What version and platform?  Latest git on Linux is perfectly happy
with pasting and deleting the way you did, and is also happy with
ctrl+shift+u200benter.

Cheers
Lex


 Cheers!


 Harold

 [1] http://en.wikipedia.org/wiki/Zero-width_space
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Crash when pasting a Zero-width space

[Lex Trotman]

On 26 June 2012 20:01, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 26.06.2012 11:53, schrieb Harold Aling:

 Updated to Geany 1.23 (git = 40da14b)

 1. Create a new document (ctrl-n)
 2. Copy/paste mA (already has a zero-width space in the middle)
 3. Press 'home'
 4. Press 'delete'
 5. Crash - 100% CPU


 Works for me. No crash and no 100% CPU usage.


 Geany also counts that character as 3 positions instead of 1.


 Depending on your POV, this is the correct behavior (the pos field actually
 shows the byte offset since the start of the file, hence it's 0-based also).

Yes, the column count only counts it as one though pos counts as 3.
Pos is bytes, thats a scintilla definition.

I would guess its something about the Ubuntu specials, just for comparison

08:47:15: Geany INFO: Geany 1.23 (git = 8187268), en_AU.UTF-8
08:47:15: Geany INFO: GTK 2.24.10, GLib 2.30.2

 (From the help-debug messages GUI :)

Whats yours say?

Cheers
Lex

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Crash when pasting a Zero-width space

[Lex Trotman]

On 26 June 2012 20:09, Harold Aling ge...@sait.nl wrote:
 On Tue, Jun 26, 2012 at 12:05 PM, Lex Trotman ele...@gmail.com wrote:
 On 26 June 2012 20:01, Thomas Martitz
 thomas.mart...@student.htw-berlin.de wrote:
 Am 26.06.2012 11:53, schrieb Harold Aling:

 Updated to Geany 1.23 (git = 40da14b)

 1. Create a new document (ctrl-n)
 2. Copy/paste mA (already has a zero-width space in the middle)
 3. Press 'home'
 4. Press 'delete'
 5. Crash - 100% CPU


 Works for me. No crash and no 100% CPU usage.


 Geany also counts that character as 3 positions instead of 1.


 Depending on your POV, this is the correct behavior (the pos field actually
 shows the byte offset since the start of the file, hence it's 0-based also).

 Yes, the column count only counts it as one though pos counts as 3.
 Pos is bytes, thats a scintilla definition.

 I would guess its something about the Ubuntu specials, just for comparison

 08:47:15: Geany INFO            : Geany 1.23 (git = 8187268), en_AU.UTF-8
 08:47:15: Geany INFO            : GTK 2.24.10, GLib 2.30.2

  (From the help-debug messages GUI :)

 Whats yours say?

 11:59:08: Geany INFO            : Geany 1.23 (git = 40da14b), en_US.UTF-8
 11:59:08: Geany INFO            : GTK 2.24.10, GLib 2.32.3

Oh, I'm missing a commit, never mind not relevant.

Yeah, that looks ok, your file is UTF-8 which is fine, the difference
in Glib shouldn't affect it, all I can think of is that its Ubuntu
specific, they are known to add patches to GTK, so maybe its one of
those?

Can you run Geany under gdb and get a backtrace?

Cheers
Lex


 -H-
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Crash when pasting a Zero-width space

[Lex Trotman]

[...]

And the answer from Neil is:

  This feature was actually contributed by ActiveState.

 We have had a report of an infinite loop in Geany when an attempt is
 made to draw a block Caret on a zero width space character (u200b).

  The backtrace makes the problem appear to be in DrawBlockCaret so
you could switch to the standard line caret.

  There are features in Scintilla that I have accepted despite
thinking they are a poor idea, such as the block caret. Perhaps the
people that like this feature can work on fixing it.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] IRC Channel Topic

[Lex Trotman]

Hi whoever can change,

The IRC channel topic still says 0.21 is out! While still true its a
bit behind :)

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [Geany] ANN: Geany 1.22 is out!

[Lex Trotman]

On 21 June 2012 16:10, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 18.06.2012 23:56, schrieb Enrico Tröger:

 And now also the Windows installers (with and without bundled GTK
 runtime) are available.

 On http://www.geany.org/Download/Releases and http://download.geany.org/.



 Is there any particular reason you ship the old 2.16 gtk, instead of the
 supposedly superior 2.24x?


Hi Thomas,

The question is has someone actually tested it to see if it really is
superior for Geany? ACAIK no.

Cheers
Lex


 Best regards.

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Wrong underline in german Strings

[Lex Trotman]

On 8 June 2012 18:52, theUser BL theuse...@hotmail.com wrote:

 In Version 0.21 there stand at in geany with german Strings
 Bearbeiten - Einstellungen - Terminal
 a CheckBox called Menütastenkombination deaktivieren (Vorgabe ist F10). The 
 n in Menü is underlined.

 And in the current GitHub-Version there is nothing underlined, but there stand
 Me_nütastenkombination deaktivieren (Vorgabe ist F10)

 Hope it will be fixed before the release of 1.22.

Hi,

Geany has a specific i18n mailing list that should get you to
translators, this one is for development.

Cheers
Lex


 Greatings
 theuserbl


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Would be nice to have line numbers for the HTML export plugin

[Lex Trotman]

On 8 June 2012 11:12, theUser BL theuse...@hotmail.com wrote:

 I think it would be nice to have line numbers for the HTML export plugin.

 I am not so familiar with C++, so I post it only as suggestion.

Hi,

The HTML export plugin is written in C so I am afraid that your Java
is no use :(

You are right that line numbers might be a nice option, but it would
have to be a setting, the output has been the way it is for some time
and people may be relying on it.

But as always someone has to do it, but pull requests are welcome :)

Cheers
Lex

[...]
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [geany/geany] Question on - 7b3b65: Add workaround for users with an invisible selection style

[Lex Trotman]

On 8 June 2012 22:10, Nick Treleaven nick.trelea...@btinternet.com wrote:
 On 07/06/2012 00:11, Lex Trotman wrote:

 Those people should now fix their color schemes. I could lower the
   severity to an info message.

 Don't think it makes much difference, up to you.  But we should add it


 Info messages are not shown on the console with recent GLib AIUI.


 to the incompatibilities section of NEWS iaw
 http://thread.gmane.org/gmane.editors.geany.devel/6590/focus=6594.


 There isn't an incompatibility here due to the workaround if I use g_info
 instead of g_warning (which I probably should have done anyway).


Ok, thats a solution then.

Cheers
Lex


 I'll add with anything else mentioned in the thread.

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [geany/geany] Question on - 7b3b65: Add workaround for users with an invisible selection style

[Lex Trotman]

[..]

 Debug messages are not translated. The string freeze only prevents us
 changing translated strings.


Ok.


 I guess we need to advertise the change of colour scheme behavior for
 the release, otherwise we will get lots of complaints about the
 messages (like Matthews) when people use customised schemes without
 one of the flags being true.


 I doubt we'll get lots of complaints - most people don't even read console
 messages.

Heh, you might be right about that.

 Those people should now fix their color schemes. I could lower the
 severity to an info message.

Don't think it makes much difference, up to you.  But we should add it
to the incompatibilities section of NEWS iaw
http://thread.gmane.org/gmane.editors.geany.devel/6590/focus=6594.
I'll add with anything else mentioned in the thread.

Cheers
Lex


 Regards,
 Nick

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [geany/geany] Question on - 7b3b65: Add workaround for users with an invisible selection style

[Lex Trotman]

On 4 June 2012 03:04, Nick Treleaven git-nore...@geany.org wrote:
 Branch:      refs/heads/master
 Author:      Nick Treleaven nick.trelea...@btinternet.com
 Committer:   Nick Treleaven nick.trelea...@btinternet.com
 Date:        Sun, 03 Jun 2012 17:04:03
 Commit:      7b3b65e27df77be862714e2de69aa9f61764a91b
             
 https://github.com/geany/geany/commit/7b3b65e27df77be862714e2de69aa9f61764a91b

 Log Message:
 ---
 Add workaround for users with an invisible selection style

 This is likely to be the case for any users that copied the system
 selection style line as this was incorrectly set before, but not
 applied.


Hi Nick,

Based on your answer on my ML question is this necessary?

Now that we always apply the settings, a selection style of
false,false will reset to the Scintilla default The default is to
show the selection by changing the background to light gray and
leaving the foreground the same as when it was not selected.  So
false, false shouldn't be invisible.

Of course it might be invisible on particular backgrounds, but so might c0c0c0.

Or have I still misunderstood something?

Cheers
Lex


 Modified Paths:
 --
    src/highlighting.c

 Modified: src/highlighting.c
 6 files changed, 6 insertions(+), 0 deletions(-)
 ===
 @@ -790,6 +790,12 @@ static void styleset_common(ScintillaObject *sci, guint 
 ft_id)
        sci_set_property(sci, fold.at.else, 1);

        style = common_style_set.styling[GCS_SELECTION];
 +       if (!style-bold  !style-italic)
 +       {
 +               g_warning(selection style is set to invisible - ignoring!);
 +               style-italic = TRUE;
 +               style-background = 0xc0c0c0;
 +       }
        /* bold (3rd argument) is whether to override default foreground 
 selection */
        SSM(sci, SCI_SETSELFORE, style-bold, invert(style-foreground));
        /* italic (4th argument) is whether to override default background 
 selection */


 @@ Diff output truncated at 10 characters. @@


 --
 This E-Mail was brought to you by github_commit_mail.py (Source: TBD).
 ___
 Geany-commits mailing list
 geany-comm...@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-commits
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [geany/geany] Question on - 7b3b65: Add workaround for users with an invisible selection style

[Lex Trotman]

On 5 June 2012 01:30, Nick Treleaven nick.trelea...@btinternet.com wrote:
 On 04/06/2012 07:59, Lex Trotman wrote:

 Based on your answer on my ML question is this necessary?

 Now that we always apply the settings, a selection style of
 false,false will reset to the Scintilla default The default is to
 show the selection by changing the background to light gray and
 leaving the foreground the same as when it was not selected.  So
 false, false shouldn't be invisible.

 Of course it might be invisible on particular backgrounds, but so might
 c0c0c0.

 Or have I still misunderstood something?


 Try it yourself - here I get an invisible selection if neither override is
 set. Possibly a Scintilla bug - the Scintilla default is not restored on
 calling SCI_SETSELBACK when the first argument is 0/FALSE.

Hmm,  the code certainly uses the text fg/bg if the flag isn't true
Editor.cxx:2379 so I asked Neil for clarification of the docs which
might be read either way, he confirms it is intended this way.

So we need to do something like this.  Since we are in string freeze I
guess all we can do is a fixed value, we can't add any user settings
or change the message.

I guess we need to advertise the change of colour scheme behavior for
the release, otherwise we will get lots of complaints about the
messages (like Matthews) when people use customised schemes without
one of the flags being true.


Cheers
Lex

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Selection and colour schemes

[Lex Trotman]

[...]


 I've committed a fix, and also restored using the default foreground color
 for selections, so the style information can still be seen. You're right to
 enable the default background color, as otherwise with no overrides users
 can't see any selection.

 The default is explained here:
 http://www.scintilla.org/ScintillaDoc.html#SCI_SETSELFORE

Ah, the Scintilla default, gotcha.

Cheers
Lex


 SCI_SETSELFORE(bool useSelectionForeColour, int colour)
 SCI_SETSELBACK(bool useSelectionBackColour, int colour)
 You can choose to override the default selection colouring with these two
 messages. The colour you provide is used if you set useSelection*Colour to
 true. If it is set to false, the default styled colouring is used and the
 colour argument has no effect.
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] GLib 2.32 and debug messages

[Lex Trotman]

[...]
 ?  These environment variables are documented so why is it worst than a
 configuration file somewhere?

Couple (or 3) reasons:

1. with most desktops it seems running geany from the menu or icon
won't set environment variables because no shell runs to read .bashrc
or whatever setup file

2. as far as I can find its only documented in the Glib documentation,
not somewhere even an experienced *user* is likely to look

3. As a general comment, how often have you taken ages to find that
you had to set path to make something work because no installer can
set it for you?

All should be command line options IM(not so)HO so they are explicit
and in user documentation.  The config file is just a way of saving
you having to type too much , just like gcc @file, file can be
distributed to set things.

Cheers
Lex


 The problem is that it breaks our `-v` option, since we simply turns on
 outputting INFO-level messages.  So, we need a fix or a workaround,
 something.  I see 2 solutions:

 1) simply `g_setenv(G_MESSAGES_DEBUG, all, TRUE)` when given `-v`
 (e.g. around main.c:131, `if (app-debug_mode) g_setenv(...`)

 Maybe do this for pending release ...

 I did this.

Okey dokey.


 2) output everything ourselves in `handler_log()` (log.c:115) rather
 than calling GLib's default handler.


 ... and this later for proper fix that allows us to tailor it as we
 need, unless this is very simple too.

 Well.  It's easy to output something.  It's harder to output something
 as useful as what the GLib handler can output, like including prgname,
 pid  co, an doing so to the proper stream.  Not really hard, but not
 trivial either.


Well, if we have to re-invent the wheel then don't bother.

 [...]
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Selection and colour schemes

[Lex Trotman]

Hi All,

I just pushed a fix for switching colour schemes from say dark to
default leaving selection unchanged.

But in reality the code at highlighting.c doesn't actually do what it
advertises, the comment says to override default which matches the
documentation, but in fact what the code does is to change from what
is currently set.  Of course if you are changing from default to
another colour scheme thats ok, but if you are changing from a colour
scheme that has changed this setting then what is set won't be
default.

I think the code should be:
if (common_style_set.styling[GCS_SELECTION].bold)
SSM(sci, SCI_SETSELFORE, etc...
else
SSM(sci, SCI_SETSELFORE, whatever the default is)

but I can't find where to get the real default value and have run out of time.

Any thoughts or suggestions?

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] GLib 2.32 and debug messages

[Lex Trotman]

On 2 June 2012 20:58, Colomban Wendling lists@herbesfolles.org wrote:
 Hi guys,

 Since GLib 2.32, log messages at levels INFO or DEBUG aren't output
 unless G_MESSAGES_DEBUG environment variable is set to either all or
 to include the domain the message comes from [1].

Environment variables should die, they are hidden dependencies that
don't transport to user systems.


 The problem is that it breaks our `-v` option, since we simply turns on
 outputting INFO-level messages.  So, we need a fix or a workaround,
 something.  I see 2 solutions:

 1) simply `g_setenv(G_MESSAGES_DEBUG, all, TRUE)` when given `-v`
 (e.g. around main.c:131, `if (app-debug_mode) g_setenv(...`)

Maybe do this for pending release ...


 2) output everything ourselves in `handler_log()` (log.c:115) rather
 than calling GLib's default handler.


... and this later for proper fix that allows us to tailor it as we
need, unless this is very simple too.

Cheers
Lex



 The simplest fix is of course 1.  Not sure which one is the better
 though.  Anyway, I think we need to do something about this soon.

 Thoughts?

 Cheers,
 Colomban


 [1]
 http://developer.gnome.org/glib/unstable/glib-Message-Logging.html#g-log-default-handler


 PS: BTW, if I read the `handler_log()` correctly, we block *all*
 messages when not in debug mode?  I mean, warnings, criticals and
 everything.  Do we really want that?

Probably still want criticals IMHO.

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany multicursors patch

[Lex Trotman]

Davide,

Replied on this thread rather than pollute the one discussing UI change.

see edit-format-toggle case of selection

callbacks.c:715

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany Newsletter Issue #5

[Lex Trotman]

On 28 May 2012 19:59, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 28.05.2012 11:27, schrieb Frank Lanitz:

 It's important to note that the dynamic library loading mechanism
 that loads plugins is C functionality and does not know about C++
 constructors. This means that global and static objects in the
 plugin will *not* have their constructors called when the plugin is
 loaded. Use dynamically created objects as show in the above example.


 I'm not sure this is true. libdl should handle this (i.e. call functions
 point to in the init and fini sections).

 |__attribute__ ((constructor)) and||__attribute__  ((destructor)) is
 supported works with as well.


This doesn't actually call the C++ constructors/destructors in the way
they would be in normally be if the plugin had been statically linked.

This simply labels a C function to be called at dlopen time.  It may
be used to do some initialisation, but you would have to manually call
each constructor, ... too error prone, Franks advice to create
everything dynamically is sound.

Cheers
Lex

 Best regards.
 |

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany Newsletter Issue #5

[Lex Trotman]

Hi Thomas,

Humm, dunno why it didn't work when Matthew and I tried it before, but:

$ cat test.cpp
 #include geanyplugin.h
 #include iostream


extern C
{
  PLUGIN_VERSION_CHECK(211)

  PLUGIN_SET_INFO(Test C++,Test C++, etc, etc);

  void plugin_init(GeanyData *){}
  void plugin_cleanup(void){}

}

class Test
{
public:
   Test() { std::cout  Hello from Test  std::endl; }
   ~Test() { std::cout  Bye from Test  std::endl; }
};

static Test test;

$ g++ -c test.cpp -fPIC `pkg-config --cflags ../lib/pkgconfig/geany.pc geany`
$ g++ test.o -o test.so -shared `pkg-config --libs
../lib/pkgconfig/geany.pc geany`
$ cp test.so ../lib/geany
$ geany -c ../config

does call the constructor/destructor for test.  Maybe we got the
mystery incantations wrong :)  It also works using clang++ to compile
test :)

Note, if the plugin isn't loaded the constructor is run when plugin
manager is opened and, if you havn't selected the plugin, the
destructor is run when plugin manager is closed.

When you select the plugin the destructor is run and then the
constructor is run again but this time the destructor is not run when
plugin manager is closed.

So it probably shouldn't do anything in the constructors/destructors
that is slow or that leaves a trace.

[...]

 FWIW, does anyone know why I needed to link libstdc++ explicitely in my
 testing?

As shown above Matthew is right, just use g++.

@Frank, sorry, wasn't meaning to blame you ;) just my failing .. ummm
... oh yeah, memory.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany multicursors patch

[Lex Trotman]

On 26 May 2012 04:50, Colomban Wendling lists@herbesfolles.org wrote:
 Le 23/05/2012 21:19, Davide Andreoli a écrit :
 2012/5/23 Lex Trotman ele...@gmail.com:
 [...]

 IMHO the multiselection is now small enough (3 lines)  that a plugin
 would be overkill :)

 Davide, what is the impact of enabling this, how do existing features
 interact with multiple selections? Do any Geany actions that use
 selections fail when fed a multi-selection? How does paste work? And
 what if I actually select some text (ie ctrl-swipe not just click).

 I did not found any regression nor any strangeness or conflict yet.
 Yes, you can make real multiple selections (Ctrl+Alt+Drag) and the behavior
 is quite always the expected: 'copy' while multiple selection active will
 put in the clipboard all the selected text merged, 'paste' instead will only
 paste at the primary selection, 'typing' with multiple selection will do the
 same as a single selection (selected text cleared). All other commands
 should always work normally on the primary selection(the last one done).

 After a very small time of testing I see:

 *) Replace (^H) inside selection doesn't work properly when there are
 multiple selections (the replacement is only done in the last
 selection), while it works fine with rectangular selections.

Agree this one would be expected to work in all selections, and would
be very useful.


 document_replace_sel() should probably be updated then.

 BTW, I'm wondering whether Scintilla has two distinct modes for
 rectangular/multiple selections or if a rectangular selection is a
 specialized multiple selection (in which case one single code for
 handling multisel would be enough on our side).


Rectangular selections are handled as multiple selections although
the original rectangular range is remembered so that subsequent
operations may be handled differently for rectangular selections. For
example, pasting a rectangular selection places each piece in a
vertical column. from Scintilla.

Doesn't say how its remembered though.

 *) Duplicate line/selection works just fine

 *) Toggle case of the selection is buggy, it puts the newly-cased text
 altogether on the last selection.  Works fine with rectangular selection.

maybe needs www.scintilla.org/ScintillaDoc.html#SCI_SETMULTIPASTE set


 *) Almost all selection-based actions (like Select current line(s),
 toggle line(s) commentation, etc.) only selects the line of the last
 selection


 IMO Replace and Toggle Case must be updated to work properly.  The other
 selection-based commands that doesn't handle the thing really fine would
 benefit from handling it, but their result isn't as unexpected as the
 two cited above.


Just document them to only work on single selection would be ok.

Cheers
Lex



 Regards,
 Colomban
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany multicursors patch

[Lex Trotman]

[...]

 You *must* update the documentation to match, making sure you catch
 all places where such a change might impact.

 sure! doc will be my last commit before the pull request


Thats what we all say :)





 [...]
 The multiple selection hard-coded binding (Ctrl+Alt) is shadowed by the
 rectangular selection
 binding (Ctrl). So the only way I found to make multiple selection +
 rectangular selection to work
 is to change the binding for the rect selection.

 With the patch applied you can make rectangular selection with Super and
 multiple selections with Ctrl+Alt.

 Probably you will not like the binding change (I don't like to change it,
 I'm quite used to use Ctr for rect selections)  so I'm searching another way
 to solve the binding conflict... suggestions are welcome

 As a GTK app Geany normally tries to follow the Gnome HIG
 http://developer.gnome.org/hig-book/2.32/hig-book.html#input-mouse
 section 10.1.2.

 This specifies ctrl-click as the extend selection input, and it is in
 the majority of applications.  So despite it having been a Geany
 setting for a long while, I think it should be changed now that
 multiple selection is going to be supported.

 Any suggestions for a replacement for the go to definition binding?

 this binding issue is driving me crazy!!
 I don't have a good solution :/
 The situation is:

 Ctrl+Alt+click(or drag) - multiple selections (badly hardcoded in scintilla)

Also ctrl-shift-click or drag extends the rectangular selection

These roughly match the standard definitions of bounding box select
actions and make sense.


 Ctrl+click - goto definition

Which is badly hard coded at src/editor.c:319

Note that it also does goto matching brace if the click isn't on an
identifier.

This is bad practice as we are now finding.  Goto brace has a default
keybinding and goto tag can have one.  They should not be hard coded
to mouse operations.  Although this means the user now needs two
actions not one, the current usage is non-standard and is blocking the
implementation of the standard action.  This action should be removed.


 the bind for rectangular selection is strange (at least on my Linux Mint+E17
 environment), should be Ctrl+drag, but I can make rect selection only

That is because the code mentioned above overrides it, performing the
goto action on ctrl+mouse down before it even sees the drag.

[...] with Ctr+Alt+drag :/
 This key can be changed in scintilla with the api:
 SSM(sci, SCI_SETRECTANGULARSELECTIONMODIFIER, SCMOD_SUPER, 0);
 SCMOD can be CTRL, ALT or SUPER

 the only way I found to make both rectangular and multiple selections, is to 
 set
 multiple to Super and thus:

 Ctrl+Alt+click(or drag)  -  multiple selections
 Ctrl+click  -  goto definition
 Super+drag  -  rectangular selection

 I don't like to use the Super key, and also smell some possible platform
 difference around.


As I said above we should change the deviant Geany ctrl+click behavior
so the super isn't necessary.  I guess this is going to provoke some
discussion so I'll start a new thread and maybe you should wait to see
the outcome of that.

Cheers
Lex


 btw, thanks for taking the time to follow this issue...and
 give a try at the 'supersnip' branch, it's amazing!  :D

PS can't try it at the moment, all comments by inspection.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany multicursors patch

[Lex Trotman]

On 23 May 2012 04:40, Davide Andreoli d...@gurumeditation.it wrote:
 2012/5/21 Dimitar Zhekov dimitar.zhe...@gmail.com

 On Sun, 20 May 2012 12:30:12 +0200
 Davide Andreoli d...@gurumeditation.it wrote:

  Hi all!

 Hi.

  I implemented this in editor.c (and not as an external plugin) because I
  have plans to also extend the snippets to support multi editing.
 
  Actually the patch is really simple but is just a first test, it is not
  ready as there are 3 open issue:
 
  1. do you like the feature? :)

 Yes, but would prefer it as a plugin. Extending it to snippets, well...
 doesn't seem useful to me.


 Please, give a look at the last mail (the one I replayed) in the geany ml,
 it seems I'm not the only one searching for snippets that can insert the
 same typed word in different position inside the snip.

[...]

So Davide, lets see how complex the snippet changes are going to be.
If they are small they can probably go in core, otherwise for a
function that has an uncommon use-case it should be a plugin as
Dimitar suggests.

IMHO the multiselection is now small enough (3 lines)  that a plugin
would be overkill :)

Davide, what is the impact of enabling this, how do existing features
interact with multiple selections? Do any Geany actions that use
selections fail when fed a multi-selection? How does paste work? And
what if I actually select some text (ie ctrl-swipe not just click).

You *must* update the documentation to match, making sure you catch
all places where such a change might impact.




[...]
 The multiple selection hard-coded binding (Ctrl+Alt) is shadowed by the
 rectangular selection
 binding (Ctrl). So the only way I found to make multiple selection +
 rectangular selection to work
 is to change the binding for the rect selection.

 With the patch applied you can make rectangular selection with Super and
 multiple selections with Ctrl+Alt.

 Probably you will not like the binding change (I don't like to change it,
 I'm quite used to use Ctr for rect selections)  so I'm searching another way
 to solve the binding conflict... suggestions are welcome

As a GTK app Geany normally tries to follow the Gnome HIG
http://developer.gnome.org/hig-book/2.32/hig-book.html#input-mouse
section 10.1.2.

This specifies ctrl-click as the extend selection input, and it is in
the majority of applications.  So despite it having been a Geany
setting for a long while, I think it should be changed now that
multiple selection is going to be supported.

Any suggestions for a replacement for the go to definition binding?

[...]

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

On 9 May 2012 16:54, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 09.05.2012 07:47, schrieb Lex Trotman:

 Using ctags, including locals in the tags generated from Geany source,
 slightly more than doubled the number of tags, and for some C++ I have
 around nearly four times the number.


 But you only need the tags for the current scope and can drop them if you
 enter another (non-nested) scope. This surely doesn't double or quadruple
 the tags.

You can't drop them from the tags structures because when you are
parsing you don't know which scope the cursor is in.  So you have to
add them all, then decide which ones apply to the current scope.


 If I'm editing func A I don't want the locals of func B through Z in my
 autocompletion list.

Yes, correct, but they have to be in the tags first, then tagmanager
has to be taught to choose the in-scope declaration, thats my point
the parsers do not generate the information and tagmanager/symbols.c
doesn't know how to use it

Cheers
Lex



 Best regards.

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

On 9 May 2012 17:40, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 09.05.2012 09:37, schrieb Lex Trotman:

 On 9 May 2012 16:54, Thomas Martitz
 thomas.mart...@student.htw-berlin.de  wrote:

 Am 09.05.2012 07:47, schrieb Lex Trotman:

 Using ctags, including locals in the tags generated from Geany source,
 slightly more than doubled the number of tags, and for some C++ I have
 around nearly four times the number.


 But you only need the tags for the current scope and can drop them if you
 enter another (non-nested) scope. This surely doesn't double or quadruple
 the tags.

 You can't drop them from the tags structures because when you are
 parsing you don't know which scope the cursor is in.  So you have to
 add them all, then decide which ones apply to the current scope.


 Okay, but still only for the current file and not an entire project.

Yes, Geany would only have the open files parsed, I only parsed the
entire project to see how much the number of symbols increased if you
go parse locals, by using all of Geany I got an average increase, note
I only said two times not an absolute number :)

Cheers
Lex



 Best regards.
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

On 8 May 2012 22:31, Colomban Wendling lists@herbesfolles.org wrote:
 Le 07/05/2012 18:04, Nick Treleaven a écrit :
 On 02/05/2012 05:46, Lex Trotman wrote:
 Hi All,

 To summarise since the thread has several subthreads.

 1. Tagmanager Understandability

 a. I generated the doxygen documentation for tagmanager, it works if
 you set recursive, but didn't help much:

 - if its not OOP why does it say things like TMWorkspace is derived
 from TMWorkObject and similar?

 documentation bug IMO

 I don't think so.  TM uses a more or less OOP-like approach.  See for
 example TMWorkspace:

 typedef struct
 {
    TMWorkObject work_object; /*! The parent work object */
    GPtrArray *global_tags; /*! Global tags loaded at startup */
    GPtrArray *work_objects; /*! An array of TMWorkObject pointers */
 } TMWorkspace;

 The first field (work_object) is the inherited class, here
 TMWorkObject.  And you'll see numerous places where the code uses such a
 derived structure as a TMWorkObject -- since it is one actually --,
 which looks quite like OOP.

 Or see tm_workspace.c:44:tm_create_workspace():  it uses
 tm_work_object_register() to register itself as a new type of work
 object with a few methods (or vfuncs), and the initializes iself with
 tm_work_object_init(), etc.

 I very well understand Lex's questionings about how it does actually
 work, since it brings a second OOP-style programming in C, less well
 known than GObject -- though of course less complex also, but still (BTW
 maybe porting to GObject could help?)

Thanks Colomban, that helps :)

[...]

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

Hi All,

I did a step back and got some numbers (what! hard evidence in the
discussion? :)

Using ctags, including locals in the tags generated from Geany source,
slightly more than doubled the number of tags, and for some C++ I have
around nearly four times the number.

For Geany bsearching a sorted array, four times the size is only two
more iterations, doesn't matter :)

But as Colomban pointed out, with real-time tag generation on, *most*
lookups will be from the parser, not Geany.  This is needed to see if
the name it found is a type so it can tell the statement is a
declaration. (c.c does not do this at the moment since it only looks
at top level statements and all top level statements are declarations
in {} languages).

That workload *will* be proportional to the file size.  And the number
of insertions will also be proportional to the file size.  This is a
big change from the current situation where parsing occurs rarely.

For a simple array structure then, whilst parsing, either the search
is linear, or the array is re-sorted on each insert, neither is an
attractive prospect for larger files with 4* the number of tags.

Also on examining the tags file ctags produced I found that local
variable entries did not actually get parsed, ie there was no way to
go from a local variable to its type.  All that happened was an
occurrence of the name was recorded.  Also no information about
lexical scope is recorded.  So even updating to ctags c.c wouldn't
give the information on local variables we need to handle the example
I posted earlier.

So although improving tagmanager/Colomban manager is still worthwhile,
significantly more work is needed on the parsers as well.

And in terms of handling local variables properly and allowing
contextual completion ctags looks like a dead end.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

On 8 May 2012 02:04, Nick Treleaven nick.trelea...@btinternet.com wrote:
 On 02/05/2012 05:46, Lex Trotman wrote:

 Hi All,

 To summarise since the thread has several subthreads.

 1. Tagmanager Understandability

 a. I generated the doxygen documentation for tagmanager, it works if
 you set recursive, but didn't help much:

 - if its not OOP why does it say things like TMWorkspace is derived
 from TMWorkObject and similar?


 documentation bug IMO

O-K, clearly the documenter obviously had a meaning for the term in
mind since it occurs in several places, what do you think they meant?



 - its not clear how it all goes together, the workspace contains
 global tags and work_objects, or is that files and whats the


 workspace work objects are document tags. global tags explained in geany's
 manual.

And the work objects/document tags are in a different array to global
tags if I read your comment on the next post right?



 difference between source_file and file_entry?


 It doesn't look like tm_file_entry_ is really used.

Along with your comment below and about project on the next post,
sounds like tm code could be reduced significantly.  Might help :)




 - similarly whats the difference between symbol and tag?


 tm_symbol_ doesn't seem to be used.



 2. Ability to expand tagmanager to handle names declared in lexical
 scopes (not to be confused with struct/class scopes).  Here is the
 example again with some numbers so I can refer to them

 { struct a o; struct a p;
     o./* struct a members */
    { struct b o;
      o./* struct b members */
      p./* struct a members */
    }
    o./* struct a members */
    p./* struct a members1  */
    { struct c o;
      o./* struct c members */
      p./* struct a members2  */
    }
    o./* struct a members */
    p./* struct a members */
  }

 a. yep, tries use more memory than an array, the usual speed/space,
 pick one, tradeoff :)

 b. @Nick, when you say sort by scope then name, are you wanting to
 have an entry in the table for each declaration of the name?


 no

So what did you mean?




 - If so this makes the array much bigger to search and your search
 speed depends on size, and it doesn't get you anything, you can't
 search by scope since you don't know if the name is declared in the
 scope you are in or an outer scope compare p at1  and2

 - having a single name array which then points to scope info for the
 name is a viable approach (disclosure, thats how I'm doing the symbol
 table for a language I'm developing) but the table being searched is
 usually larger than if you have nested arrays.  Being smaller these
 are faster to search if the search isn't O(1), hence the suggestion of
 trie instead of bsearch.


 the gain in simplicity makes a bigger array to search worth it. Remember,
 global tags aren't included in the workspace array of tagmanager, so we're
 not talking a big number of tags, and we have o(log n) searching.


Ok, but to date document tags don't include local variables (see
below) so they will add many more names, with lots of replication.



 4. Ctags parsers

 Agree with Nick that the parsers are usable, but if we start modifying
 them to handle local declarations then they will be totally
 incompatible with the Ctags project so I guess it doesn't matter other
 than for getting languages we don't currently parse.


 ctags c.c already parses local tags

No it doesn't AFAICT:

on brace open createTags() calls tagCheck() and nest(),

on brace open checkTag() only makes a tag for a preceding function or
contextual entity (== class, enum, namespace struct or union) it does
not look at the contents of the {},

and nest() only recurses if the { opens a class, enum, namespace,
struct, union otherwise it skips everything in the {},

so no local declarations are parsed unless I've missed something?



 5. Overloaded symbols

 Since Colombans patch, overloaded symbols are now stable for all
 practical code (I think theoretically it could get confused if the
 overloads are on the same line but thats unlikely enough to ignore for
 human generated code)


 If you're talking about master, I think I still experienced wrong parenting
 on reparsing when removing lines.

HEAD of master gives me no stability problems with C++, can't cause
any problems with C either, can you reproduce?



 6. Moving functionality from symbols.c to tagmanager

 a. Since its the 100th anniversary of the Titanic sinking, I think
 that shuffling the deckchairs is an apt analogy, the functionality
 has to be somewhere, its only useful to move it if the destination
 significantly reduces the effort required.


 I don't think I suggested moving functionality.

OK, I read it that you were suggesting that.

I wondered whether TM could
 help make symbols.c less complex. I would need to understand the complexity
 to know whether this is appropriate or not.

 Titanic comment is bizarre. My suggestion could equally apply to
 ctagsmanager.

Oh dear, misdirected attempt

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

On 8 May 2012 13:27, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-05-07 05:03 PM, Lex Trotman wrote:

 On 8 May 2012 02:04, Nick Treleavennick.trelea...@btinternet.com  wrote:

 On 02/05/2012 05:46, Lex Trotman wrote:


 4. Ctags parsers

 Agree with Nick that the parsers are usable, but if we start modifying
 them to handle local declarations then they will be totally
 incompatible with the Ctags project so I guess it doesn't matter other
 than for getting languages we don't currently parse.



 ctags c.c already parses local tags


 No it doesn't AFAICT:


 I'm guessing he's referring to the upstream CTags c.c, which does have a
 l kind for local variables (off by default). See `ctags --list-kinds=C`.
 I'm not sure if the Geany fork has this, was forked before it was added, or
 if the guy that wrote TM took it out.


Ok, I havn't looked at Ctags c.c because IIUC from other comments it
isn't really mergable with our c.c.

Does upstream c.c use tagmanager, and if so how does it structure
scopes?  (A good exercise for your compiler :)

Cheers
Lex


 Cheers,
 Matthew Brush

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Request: multithreaded tag generation?

[Lex Trotman]

On 2 May 2012 23:42, Harold Aling ge...@sait.nl wrote:
 Small update as I just dist-upgraded to the latest Xubuntu and
 recompiled Geany and Geany-plugins from git.

 Opening Geany now takes 8 minutes and 41 seconds.

 15:30:02: This is Geany 1.22 (git = 249f9bc).
 15:38:43: Project Q7 opened.

Under what circumstances?

And you never answered Jiri's request in January for information to
allow him to reproduce the problem.

Cheers
Lex



 -H-
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Rewrite reflow

[Lex Trotman]

On 1 May 2012 15:36, Eugene Arshinov earshi...@gmail.com wrote:
 On Sat, 31 Mar 2012 13:48:59 +0400
 Eugene Arshinov earshi...@gmail.com wrote:

 Hi all.

 A couple of weeks ago in Geany mailing list a discussion was raised
 about reimplementing Reflow paragraph command more correctly and
 consistently with Line breaking.  Here is a link: [1]

 Finally I got to it and created pull request #35 [2].  As always,
 suggestions are welcome.

 [1]: http://lists.uvena.de/geany/2012-March/007960.html
 [2]: https://github.com/geany/geany/pull/35

 --
 Best regards,
 Eugene.

 A reminder for myself: after the pull request is accepted (if it
 happens anytime), it would be good to check bug report [3].  This bug
 report is about cursor positioning after reflow.   Also, it would be
 good to check cursor positioning after Join lines.

 [3]:http://sf.net/tracker/index.php?func=detailaid=2875092group_id=153444atid=787791

Hi Eugene,

I investigated this problem a while ago but never did anything about
it, my analysis was that the problem was due to the replace of the
text not being an atomic operation so Scintilla updates the display
several times to account for the changes as it goes, and as you move
the lines around that causes scrolling.  Since you are now doing
everything using ordinary characters, maybe the way to do it is to get
the text from the selection, re-format the text outside scintilla,
then get target from selection and replace the target in one go.

Also I don't see how you new implementation prevents you from
splitting in the middle of a multi-byte UTF-8 encoded character?

Cheers
Lex


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

Hi All,

To summarise since the thread has several subthreads.

1. Tagmanager Understandability

a. I generated the doxygen documentation for tagmanager, it works if
you set recursive, but didn't help much:

- if its not OOP why does it say things like TMWorkspace is derived
from TMWorkObject and similar?

- its not clear how it all goes together, the workspace contains
global tags and work_objects, or is that files and whats the
difference between source_file and file_entry?

- similarly whats the difference between symbol and tag?

2. Ability to expand tagmanager to handle names declared in lexical
scopes (not to be confused with struct/class scopes).  Here is the
example again with some numbers so I can refer to them

{ struct a o; struct a p;
o./* struct a members */
   { struct b o;
 o./* struct b members */
 p./* struct a members */
   }
   o./* struct a members */
   p./* struct a members 1 */
   { struct c o;
 o./* struct c members */
 p./* struct a members 2 */
   }
   o./* struct a members */
   p./* struct a members */
 }

a. yep, tries use more memory than an array, the usual speed/space,
pick one, tradeoff :)

b. @Nick, when you say sort by scope then name, are you wanting to
have an entry in the table for each declaration of the name?

- If so this makes the array much bigger to search and your search
speed depends on size, and it doesn't get you anything, you can't
search by scope since you don't know if the name is declared in the
scope you are in or an outer scope compare p at 1 and 2

- having a single name array which then points to scope info for the
name is a viable approach (disclosure, thats how I'm doing the symbol
table for a language I'm developing) but the table being searched is
usually larger than if you have nested arrays.  Being smaller these
are faster to search if the search isn't O(1), hence the suggestion of
trie instead of bsearch.

3. Background/asynchronous whatever you want to call it parsing

a. @Colomban, you say that caches are created on first lookup, doesn't
that throw work back into the UI thread which could have been done in
the parsing thread?

4. Ctags parsers

Agree with Nick that the parsers are usable, but if we start modifying
them to handle local declarations then they will be totally
incompatible with the Ctags project so I guess it doesn't matter other
than for getting languages we don't currently parse.

5. Overloaded symbols

Since Colombans patch, overloaded symbols are now stable for all
practical code (I think theoretically it could get confused if the
overloads are on the same line but thats unlikely enough to ignore for
human generated code)

6. Moving functionality from symbols.c to tagmanager

a. Since its the 100th anniversary of the Titanic sinking, I think
that shuffling the deckchairs is an apt analogy, the functionality
has to be somewhere, its only useful to move it if the destination
significantly reduces the effort required.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

[...]

 I don't understand why tagmanager has to be replaced, why not just replace
 the parts you want to improve? Rewriting it is likely to lead to a new set
 of bugs and be hard to review and merge changes from master.


Hi Nick,

It is good to see someone supporting tagmanager rather than it just
being trashed (by the likes of me :)

One of the problems with tagmanager is its complexity, leading to
considerable wariness on the part of many of us about changing it
since we don't understand what we might break.

Actually documenting the overall structure of tagmanager and how it is
supposed to work would be a good thing, whats a workspace? what is it
meant to represent, how are scopes represented? etc.


[...]
   - a multi-cache one that, as its name suggests, maintains multiple
     caches (sorted tags arrays).  it uses a little more memory and is
     slower on insertion since it maintains several sorted lists, but a
     search on an already existing cache is very fast.


 Won't this be slow for adding many tags at once? How is this design better
 than tagmanager?

Perhaps Colomban could confirm, but my first thought is that this is
for nested scopes.

How does tagmanager handle nested scopes, or how would it need to be
modified to do so, considering the example (in C)

{ struct a o; struct a p;
   o./* struct a members */
  { struct b o;
o./* struct b members */
p./* struct a members */
  }
  o./* struct a members */
  p./* struct a members */
  { struct c o;
o./* struct c members */
p./* struct a members */
  }
  o./* struct a members */
  p./* struct a members */
}

How much needs to be changed in tagmanager so that the right
autocompletes can be provided at each comment?  (assuming c.c is
taught to parse local variables of course)

And of course the same question for Colomban.


 Given my global tags merge change (see below), I think tagmanager needs some
 changes to avoid sorting the workspace tags array each time tags are
 updated, but this is certainly doable.


   In practice I haven't yet tested anything big enough to see any
   difference in performances between these two backends, and that's
   something that probably isn't worth bothering about for now.

 * this backend abstraction might be really overkill, and maybe we
   could do better without it?;


 I don't see why having two is better. The memory overhead for a pointer
 array is not much vs. the size of the tag structures. Fast searching is
 important.


It is but is it flexible enough to be expanded to nested scopes.


 * tags (and most types) are reference-counted (so they aren't
   necessarily duplicated, e.g. in the multicache backend);


 I don't really understand src/symbols.c since the real-time parsing change,
 so don't really understand why this is needed.

Blame C++ and overloaded names I think.

[...]

 I don't really see what the problem understanding it is. I thought scope
 completion was just tm_workspace_find_scoped and related functions, not some
 tagmanager-wide problem.

I think the fact that this isn't clear is the problem :)



 Also, later in the thread he says that performance problems with
 resorting global and workspace tags cannot be fixed with the design of
 tagmanager. I've been working yesterday on improving this significantly
 by merging the new tags each time instead of resorting *all* the tags. I
 hope to commit this in the next few days.


 Cool!  I haven't done any profiling on either tagmanager or may new
 attempt, so I can't tell what's actually slow, but any improvement is
 good to have :)


 I finished the global tags merging change:
 https://github.com/geany/geany/commit/712cdd6aa0005f65bd77b15c34cd29067864628d

 IMO this should make loading global tags fast enough, even for heavy use, as
 the whole array is now only traversed once.

Excellent, good one Nick.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Lex Trotman]

[...]
 Also, later in the thread he says that performance problems with
 resorting global and workspace tags cannot be fixed with the design of
 tagmanager. I've been working yesterday on improving this significantly
 by merging the new tags each time instead of resorting *all* the tags. I
 hope to commit this in the next few days.

 Cool!  I haven't done any profiling on either tagmanager or may new
 attempt, so I can't tell what's actually slow, but any improvement is
 good to have :)


Coo, have I accidentally ignited a competition between Nick fixing
tagmanager and Colomban's potential replacement? :)

Didn't mean to, but if we get to pick the best, great :)

Cheers
Lex


 Regards,
 Colomban

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Standard Tags files

[Lex Trotman]

Hi All,

Nick has removed the instructions on re-building tags.c99 which is ok.

But it made me think, should we provide a tags.c11 as well and how
would it be best to choose between them?

IIUC C11 adds a significant number of libraries, so extra tags could be good.

But C11 is fairly new and I don't know how compliant the various
libraries are yet, any comments from C11 users?

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] gitignore needs updating?

[Lex Trotman]

Hi all,

I just noticed git status mentions some untracked files

# Untracked files:
#   (use git add file... to include in what will be committed)
#
#   .lock-wafbuild
#   po/.intlcache

and Matthew mentioned some more on IRC that appear from time to time.

Have I just not been paying attention or has the build changed and we
need to update .gitignore?

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Development of code re-formatting plugin

[Lex Trotman]

[...]

 Isn't that a Qt program?  But yes, I wanted to do something like this --
 actually each backend would export a set of options and a generic GUI
 would display them and allow to edit them.

Ok its Qt, I just read the bit that said Notepad++ and IDE
pluginability, although it looks like plugin as an external tool in
which case Qt wouldn't matter.  Just trying to keep you from getting
distracted from Tagmanager :-D

Cheers
Lex


 Cheers,
 Colomban
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Development of code re-formatting plugin

[Lex Trotman]

On 9 April 2012 20:08, Nayan Shah na...@nayanshah.com wrote:
 Hello,

 I am planning to develop a code re-formatting plugin for geany. I want it to
 be more on the lines of Notepad++'s C++ re-indent plugin which is pretty
 awesome.

 The feature could be something like : user selects bunch of text and clicks
 beautify or maybe it works on the whole file by default.

 Astyle http://astyle.sourceforge.net/ is a small automatic formatter and
 released under LGPL. It is pretty small with loads of options. and supports
 C, C++, Java code.

 Can it be used for development of the plugin ?

 Any feedback / comments would be appreciated.

Yes you could make a plugin to run astyle, but it would probably be
easier to just use it as a custom command, see
http://www.geany.org/manual/current/index.html#sending-text-through-custom-commands

Cheers
Lex


 Regards,
 --
 Nayan Shah


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Development of code re-formatting plugin

[Lex Trotman]

On 10 April 2012 09:05, Colomban Wendling lists@herbesfolles.org wrote:
 Hi,

 Le 09/04/2012 12:41, Lex Trotman a écrit :
 On 9 April 2012 20:08, Nayan Shah na...@nayanshah.com wrote:
 Hello,

 I am planning to develop a code re-formatting plugin for geany. I want it to
 be more on the lines of Notepad++'s C++ re-indent plugin which is pretty
 awesome.

 I don't know Notepad++, but I started a indenter plugin awhile ago, I'll
 try to check where it is and make the source available if it can be
 useful.  I should also finish it, but...

 The feature could be something like : user selects bunch of text and clicks
 beautify or maybe it works on the whole file by default.

 Astyle http://astyle.sourceforge.net/ is a small automatic formatter and
 released under LGPL. It is pretty small with loads of options. and supports
 C, C++, Java code.

 Can it be used for development of the plugin ?

 Any feedback / comments would be appreciated.

 Yes you could make a plugin to run astyle, but it would probably be
 easier to just use it as a custom command, see
 http://www.geany.org/manual/current/index.html#sending-text-through-custom-commands

 Unfortunately astyle does crazy stuff (like seeking back and forth) with

I can understand why it would do that to look ahead, but it would be
good if it documented that it *does not* work with pipes.

 its input, making impossible to pipe data to it (actually it'll work
 until the data size exceeds the OS's IO buffer size IIRC, but if it

Looking at the code it should give an error message if it can't seek
in the file, so it should just generate no output, but maybe thats
recent.

 exceeds that size astyle will just hang indefinitely).  Calling that
 executable requires a real file then.  The plugin I talked about
 previously has an astyle backend too, but it writes a temp file for the
 very reason above.

Does that mean it is universal and can use any beautifier?  And maybe
integrate Universal Indent GUI to set them up?

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] file attributes on a linux system

[Lex Trotman]

On 5 April 2012 19:40, worthspending worthspend...@gmail.com wrote:
 The question of how new files don't have +x using save as and do have +x
 might be answered with the following observation.

 - Create a new file File-New, then, File-Save, then, check the attribute:
  No +x on the new file
 - Create a new file File-New, then, File-Save As, then, check the
 attribute: No +x on the new file

 I'm using the Tree Browser plugin, so...
 - Create a new file by right mouse click on the directory in the tree
 browser and enter the name of the new file directly into the text field in
 the list.  Hit enter to finish and create the file.  Check the attribute and
 it has +x on the new file.

It would have been worthwhile to mention this.


 I wonder if this is worthy of filing an issue report for the tree browser
 plugin.

Yes, on the correct place.

Cheers
Lex




 On Wed, Apr 4, 2012 at 4:49 AM, Lex Trotman ele...@gmail.com wrote:

 On 4 April 2012 19:42, Lex Trotman ele...@gmail.com wrote:
  On 4 April 2012 18:52, worthspending worthspend...@gmail.com wrote:
  Ya know, I really don't even want to ask as I don't want to be a pest,
  but,
  I haven't found a good example of setting the umask prior to launching
  geany.  I would like to set the umask and  have it tied to geany only.
   I
  run a lot of unattended processes, so, the line of thinking is if I
  make
  some type of global change I could introduce a problem to another
  program.
 
  I can confirm that the save as feature works as described in this
  thread.
   No +x attribute on the saved file.
 
  Hi,
 
  In relation to your question, just do:
 
  umask 666; geany


 Ahhh, make that

 umask 111; geany

 because umask is the bits you *don't* want, allways got that wrong.

 Cheers
 Lex

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel



 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] public ui_setup_open_button_callback

[Lex Trotman]

On 6 April 2012 06:03, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-04-05 11:56 AM, Dimitar Zhekov wrote:

 Hi,

 Currently UIUtilsFuncs contain ui_path_box_new(), so a
 file-chooser-dialog button can be created programatically in a plugin.
 But there's no ui_setup_open_button_callback(), so it's impossible to
 load such a button from a .glade file and setup it, as in Geany.

 geanyprj uses ui_path_box_new(), and other plugins (saveactions,
 spellcheck, debugger, ...) create file-chooser-dialog buttons manually,
 so they seem common. I'm writing a new plugin, and would prefer to
 use .glade for the interface as much as possible (and practical).


 IMO, all this path box stuff should be deprecated in favour of the widget
 provided by the toolkit (GtkFileChooserButton). Using custom stuff like this
 makes Geany non-standard amongst other GTK+ programs and it doesn't
 provide the flexibility of the already provided widget, namely being a real
 GtkWidget and integration with Glade.

 On the other hand, I also wouldn't be opposed to a proper implementation of
 a real custom GtkWidget subclass (ex. GeanyPathBox) that can be used in
 Glade and otherwise conveniently, since I tend to find the text box next to
 the button to be more user-friendly than the widget currently provided by
 the toolkit for this purpose.

It would be fine to clean up, so long as the new version works on the
oldest GTK we support.

Cheers
Lex



 My $0.02, having thought about this before while porting to Glade and having
 previously written a GeanyPathBox widget for this use.

 Cheers,
 Matthew Brush
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] file attributes on a linux system

[Lex Trotman]

On 4 April 2012 18:52, worthspending worthspend...@gmail.com wrote:
 Ya know, I really don't even want to ask as I don't want to be a pest, but,
 I haven't found a good example of setting the umask prior to launching
 geany.  I would like to set the umask and  have it tied to geany only.  I
 run a lot of unattended processes, so, the line of thinking is if I make
 some type of global change I could introduce a problem to another program.

 I can confirm that the save as feature works as described in this thread.
  No +x attribute on the saved file.

Hi,

In relation to your question, just do:

umask 666; geany

should give you read/write only for new files.

But I am not sure how you have managed to arrange for new files to
have +x as you said in your initial post, but ones created by save-as
created without +x as you say now?

Cheers
Lex


 Thanks


 On Tue, Apr 3, 2012 at 7:39 PM, Lex Trotman ele...@gmail.com wrote:

 On 4 April 2012 09:30, Lex Trotman ele...@gmail.com wrote:
  On 4 April 2012 01:56, Alexander Eberspächer
  alex.eberspaec...@gmail.com wrote:
  On Sun, 1 Apr 2012 01:38:15 -0500
  worthspending worthspend...@gmail.com wrote:
 
  I develop ruby code on a linux box.  For all new files Geany creates,
  the file attributes are set to include the +x executable attribute.
 
  Let me briefly describe a related issue: if a file with the +x
  attribute
  is opened in Geany and Save as as chosen, the saved file will lack
  the +x attribute. Is this desired behaviour?

 Sorry initially misread your comment, you said save as

 But the reason is the same as below, it creates a new file, which will
 get its protection from the current umask.

 That *is* desired behaviour because it is how all Unix systems work,
 we should not be different.  Users would be surprised if Geany
 behavior is different to all others and there is no guarantee that we
 can actually set any specific protections since the user may not have
 sufficient permission to do so due to the umask.

 Cheers again
 Lex

 
  This occurs when the use_atomic_file_saving option is set.  It is not
  desired but it is documented behaviour and is unavoidable.  As I
  said before, set the umask before running Geany.
 
  Cheers
  Lex
 
 
  Greetings
 
  Alex
 
  ___
  Geany-devel mailing list
  Geany-devel@uvena.de
  https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel



 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] file attributes on a linux system

[Lex Trotman]

On 4 April 2012 19:42, Lex Trotman ele...@gmail.com wrote:
 On 4 April 2012 18:52, worthspending worthspend...@gmail.com wrote:
 Ya know, I really don't even want to ask as I don't want to be a pest, but,
 I haven't found a good example of setting the umask prior to launching
 geany.  I would like to set the umask and  have it tied to geany only.  I
 run a lot of unattended processes, so, the line of thinking is if I make
 some type of global change I could introduce a problem to another program.

 I can confirm that the save as feature works as described in this thread.
  No +x attribute on the saved file.

 Hi,

 In relation to your question, just do:

 umask 666; geany


Ahhh, make that

umask 111; geany

because umask is the bits you *don't* want, allways got that wrong.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] file attributes on a linux system

[Lex Trotman]

On 4 April 2012 01:56, Alexander Eberspächer
alex.eberspaec...@gmail.com wrote:
 On Sun, 1 Apr 2012 01:38:15 -0500
 worthspending worthspend...@gmail.com wrote:

 I develop ruby code on a linux box.  For all new files Geany creates,
 the file attributes are set to include the +x executable attribute.

 Let me briefly describe a related issue: if a file with the +x attribute
 is opened in Geany and Save as as chosen, the saved file will lack
 the +x attribute. Is this desired behaviour?

This occurs when the use_atomic_file_saving option is set.  It is not
desired but it is documented behaviour and is unavoidable.  As I
said before, set the umask before running Geany.

Cheers
Lex


 Greetings

 Alex

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Encoding Some More

[Lex Trotman]

Colomban,

I have found how to generate the encoding problem on a UTF-8 locale
machine, so it isn't a windows only problem.  Just specify the coding
in the file, see attached (its filetype is none).

The OP has the problem because their machine locale is CP1252 so no
coding needs to be specified but the problem is the same. [1][2][3]

Note the file will open fine, and the status line will show CP1252 but
the menu document-set encoding-etc will show UTF-8.

If the file is opened as UTF-8 the double quotes shows wrong.

Cheers
Lex

[1] http://thread.gmane.org/gmane.editors.geany.devel/5714
[2] http://article.gmane.org/gmane.editors.geany.general/6285
[3] 
https://sourceforge.net/tracker/?func=detailaid=3509407group_id=153444atid=787791


funny_encoding
Description: Binary data
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Scope completion fix/reimplementation

[Lex Trotman]

On 24 March 2012 12:09, Colomban Wendling lists@herbesfolles.org wrote:
 Hi guys,

 I re-implemented scope completion some time ago and it seems to work
 quite OK, at least far better than the current TM stuff that seem to
 provide random results -- when it provides some.

 I already posted the patch in the C++ Symbols problem, but it's here
 again, since I want you to take a look at it.

 So.  I'm wondering if you have some comments and/or options on the
 patch, and if you think that I should commit it as at least an interim
 solution until we get some working replacement for TM [1].

 Known issues (they were already present in previous implementation BTW):

  * :: triggers the same as - or ., e.g. it fetches completions
 for a variable name, not a class name.  This should be quite easy to fix
 (if we can assume :: always completes a type name).

  * Currently only a single word is used to get the scope.  E.g., if
 typing foo.bar.baz, only baz is used to find what the user wants to
 complete.  This works completely fine if there is only possible
 candidate for baz, but if there are multiple candidates, using the
 previous scoping could help to find out which one is the right one.
   Normally the attached implementation does a fair job at guessing what
 is the right thing to complete, but it still can't read your mind --
 that could even be blank, sigh.

  * We only parse global variables in many languages, so scope completion
 for local variables will probably not work -- though it works for
 sub-members, like local.member.foo.


Just for everyone's information I've been using the patch for several
days in C++ and Python with no noticable negative effects, but since
most of my use falls into the known issues list I don't see much
improvement either.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Gathering Release 1.22 incompatibilities

[Lex Trotman]

On 21 March 2012 00:09, Nick Treleaven nick.trelea...@btinternet.com wrote:
 On 20/03/2012 04:46, Lex Trotman wrote:

 +    Filetypes
 +    * Move all named styles into color schemes and keep only mappings in
 the
 +      filetypes files. Filetypes should no longer contain styling
 information,
 +      except `filetypes.common` which contains the default color scheme.
 Breaks
 +      compatibility with old filetypes files.


 I think the filetypes.* files compatibility was not broken. Rather that
 overriding filetypes style defaults will break color schemes.

After yesterday's long discussion with Matthew thats how I understand
it too (I think).  Maybe it should say Old user filetypes styles must
be removed for new themes to work or some such.


 +    Plugin API
 +    * Rename signal `project_dialog_create` to `project_dialog_open` and
 +      add new signal `project_dialog_close`. Increments plugin ABI so all
 +      plugins need re-compilation even if they don't use the signal.


 If compiling doesn't catch any new errors, I don't think the ABI should have
 been broken. Maybe it's worth reverting the ABI break?

*Technically* is not an ABI change.

Problem is there is no way of indicating that plugins need to be
updated for a perticular version of Geany, the plugins listening on
the old signal will at best just not work, at worst crash when the
signal never comes but subsequent ones do.

The current API test assumes that all APIs newer than that requested
by a plugin will work.  In situations like this Geany needs to reject
plugins that ask for an API older than the breaking change because
they might not work.  In lieu of such a capability an ABI break is the
only way we have of indicating that plugins need updating, for binary
users they just update GP and they are fine (assuming the plugins
using the signal are fixed before release).  For users who compile GP
we should add a note about updating as well as compiling, eg add to
the end of this comment Plugins using the old signal will not work
and need updating from GP prior to re-compilation


 +    User Interface
 +    * Keybinding Ctrl-t has been re-purposed from transpose line to
 +      go to tag.  Transpose line should be less used now the move
 line
 +      commands are available.


 I've now committed a workaround - see the latest 2 commits. Existing users
 should see no change on upgrading Geany, even if they never edited any
 keybindings. New users get the new keybinding defaults.

Looks good, suggest we add to the end of this comment Geany will not
change the binding if running with an existing configuration, only
when a new configuration is created


 Also, shouldn't the important/breaking things be in the same group at the
 top? Otherwise when we add the other changes they won't stand out.

I thought reading Colombans post that this was the list being gathered
at the top, maybe it needs a heading?

Cheers
Lex


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Gathering Release 1.22 incompatibilities

[Lex Trotman]

[...]

 Its incompatible with users fingers, and thats a *major* incompatibility.
 :)


 Agree. I might be able to improve this a bit with a workaround, I'll
 investigate.


Neat.


 Yeah, plugins is an important one.


 I may have missed some things but offhand is this just the project
 properties signal names that got broken API-wise?

The signal name change also bumped the API and ABI (probably
correctly? plugins using the old signal won't work, but just
re-compiling them won't fix it).  An ABI change means that all plugins
need to be re-compiled, so when approaching 1.22 release we should
liase with Frank to try to get as near a simultaneous release of
geany-plugins as possible so binary users are not left in the lurch
without plugins for long.

[...]

 Yeah, unfortunately I forgot keybindings.conf is only saved after the first
 edit. (IIUC, commit messages shouldn't be edited after they've been pushed).


Agree, I wasn't meaning to suggest changing the comment.

[...]

 Agree, I think Colomban's idea of adding incompatible/important changes to
 the NEWS file as we go, and at the top, would work well.

Sounds like we are approaching a plan.

Cheers
Lex


 Regards,
 Nick

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Gathering Release 1.22 incompatibilities

[Lex Trotman]

On 20 March 2012 13:08, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-03-19 05:29 PM, Lex Trotman wrote:

 Agree, I think Colomban's idea of adding incompatible/important changes
 to
 the NEWS file as we go, and at the top, would work well.


 Sounds like we are approaching a plan.


 This sounds like a fine idea to me. Something like the attached patch is OK?

Yep, attached adds a bit to it.

Cheers
Lex


 Cheers,
 Matthew Brush


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

diff --git a/NEWS b/NEWS
index 4e7bf87..6748d1f 100644
--- a/NEWS
+++ b/NEWS
@@ -1,8 +1,26 @@
 Geany 1.22 (unreleased)
 
+General
+* Bump dependencies to GTK = 2.16, GLib and GIO= 2.20 .
+
 Editor
 * Update Scintilla to version 2.29.
 
+Filetypes
+* Move all named styles into color schemes and keep only mappings in the
+  filetypes files. Filetypes should no longer contain styling information,
+  except `filetypes.common` which contains the default color scheme. Breaks
+  compatibility with old filetypes files.
+
+Plugin API
+* Rename signal `project_dialog_create` to `project_dialog_open` and
+  add new signal `project_dialog_close`. Increments plugin ABI so all
+  plugins need re-compilation even if they don't use the signal.
+
+User Interface
+* Keybinding Ctrl-t has been re-purposed from transpose line to
+  go to tag.  Transpose line should be less used now the move line
+  commands are available.
 
 Geany 0.21 (October 2, 2011)
 
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] C++ Symbols problem

[Lex Trotman]

Hi Colomban,

I used both patches all afternoon with no visible problems.  They seem
to work as advertised.  Will keep using, thanks.

Cheers
Lex

On 18 March 2012 08:36, Colomban Wendling lists@herbesfolles.org wrote:
 Le 13/03/2012 01:48, Lex Trotman a écrit :
 Hi All,

 Hey!

 Here's an initial patch that fixes the issue by better handling of true
 duplicate tags.  It's not necessarily the better fix for the issue,
 where maybe having the template type info would be better, but it is
 more generic since it would handle any duplicate.

 It's not much tested, but have fun :)

 Cheers,
 Colomban



 There is a problem with symbols in some C++ programs which causes some
 class members to appear and disappear or move in the sidebar.
 Needless to say this is *very* distracting.

 The minimal program to demonstrate this is:

 templatebool bclass problem;

 template class problemfalse {
 };

 template class problemtrue {
       int i_change;
 };


 The member i_change changes each time the symbols pane is updated,
 correctly showing as part of the class at line 6, then part of the
 class at line 3, then disappearing, then back to the class at line 6
 etc.

 In C++ this program has three class names:

 a) at line 1 declaration of problembool
 b) at line 3 definition of problemfalse
 c) at line 6 definition of problemtrue

 Note that these are distinct classes as if the names include bool,
 true and false.

 But neither symbols.c or the tagmanager parser includes the template
 parameters in the name, instead showing both of the classes at line 3
 and 6 as problem.

 Discussion with Colomban on IRC indicated that this may be confusing
 the symbol update algorithm.  Forcing a complete re-generation of the
 symbols did indeed stabilise the sidebar.

 I think that the problem is due to update_tree_tags() identifying the
 parent of i_change just by name so it can't tell if line 3 or line 6
 (or possibly line 1) is the parent.

 If  i_change is shown in the symbol tree as part of the class at line
 6 then it will be in the parent_tags hash with parent of problem.
 If this is taken as problemof line 3 as parent, it will delete it
 from the class at line 6 in pass 1 and as i_change is still in the
 tags list will add it to the class at line 3 since thats what the
 parent_tags hash says is its parent.

 On the next symbol update, since what it thinks is the parent of
 i_change (the class at line 3) does not in fact have i_change as a
 member, it will be deleted from the tree and the tags list, so it
 isn't added again in pass 2.

 On the next symbol update i_change is not in the tree so it isn't in
 the parent_tags hash so it is added where the tags list says is the
 correct place.

 If the order of the definitions at line 3 and 6 are reversed i_change
 just alternates on and off, suggesting that it isn't the first
 definition of the symbol problem that is the one found.

 At least I think this is the mechanism?

 Other than the hack to re-create the whole table each time, I'm not
 sure how to cure it without distinguishing the three class names, and
 that means modifying tagmanager/c.c (shudder).

 Cheers
 Lex
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Gathering Release 1.22 incompatibilities

[Lex Trotman]

On 19 March 2012 12:12, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-03-18 05:20 PM, Lex Trotman wrote:

 Hi All,

 I recently ran into Nicks change of the default keybindingctrl-t
 from transpose to gototag.  This made me realise we need to keep a
 list of incompatibilities to add to the release notes when 1.22 is
 released.


 I don't know if I'd consider changing a default keybinding an
 incompatibility as such. IMO, unless something breaks as a result of an
 upgrade, it's not really incompatible.

Its incompatible with users fingers, and thats a *major* incompatibility. :)

Basically anything that changes the UI operation (eg moved menu items,
keybindings, the new colourschemes dialog etc). should be mentioned so
users are not surprised.

You can get some *quite* nasty bug/ML reports if such changes are not
brought to the users attention.  It doesn't have to be in
incompatibilities, there can be a changed UI section as well, but I
thought just one section would be better.



 I would have thought that anything incompatible would have been
 forgotten by then unless we keep a running list, at the moment all I
 can think of is the ctrl-t and themes, but I am sure there are others.


 The only real incompatibilities I can think of are the filedefs/color
 schemes, changes to the plugin API, and the GTK+ version bump.


Yeah, plugins is an important one.


 The list also saves Git blaming to try to see what made the change and
 if it is deliberate or not.

 So any suggestions on how we should gather these?  and of any more of
 them.


 We could, at release-time, just manually scan the ChangeLog (and/or Release
 Notes) and add an asterisk to each item that changes defaults or breaks
 compatibility,

If its obvious, but for example Nicks commit comment actually said it
didn't affect users (not picking on Nick, that just happened to be the
one I just fell over), so it wouldn't be obvious.  Commit comments
often don't mention it.  So I think gathering these things as we go is
also important.

with a note at the bottom of the list to explain what the
 asterisk means.

Thats one way of presenting it yes, but I think it is best to make a
separate list in a separate section of the release notes so it has a
*chance* of being read by at least *some* users.  Little *s are too
easily overlooked.

Cheers
Lex


 Cheers,
 Matthew Brush
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] C++ Symbols problem

[Lex Trotman]

Hi All,

So that I don't look unreasonable for criticising just Geany I
investigated what many other IDEs do with the same source, basically
working my way through the wikipedia C++ IDEs list (at least the open
ones we might, erm, share code from, and that would run on my machine
without changes to its configuration).

The results are sumarised below:

Anjuta, symbols pane wrong - repeated members on both problemstrue
and problemsfalse, autocomplete failed, none offered

Code::Blocks and Codelite both failed to install due to wxWidgets
dependency problems.

Eclipse CDT, symbols pane CORRECT, autocomplete works but ignores
private/public access restrictions (minor issue)

Emacs, no symbol pane, autocomplete saw second definition only, change
order and change the offered autocomplete.

Geany, symbols pane cycles members as previously described, autocomplete-ly crap

Gnat programming Studio, symbols pane didn't work, autocomplete didn't
work, program was so slow it was unusable so test was cut short

Kdevelop could not install because I wouldn't let it install most of
KDE as well :(

Monodevelop, symbols pane didn't work at all, autocomplete didn't work
at all (help didn't work so I couldn't figure out why)

Netbeans, symbols pane CORRECT, autocomplete CORRECT including
adhering to private/public access restrictions.

Qt creator installed and ran but would not create even a plain C++
project without full qt install 1GB which I won't do :(

And Matthew kindly tried xcode for me, symbols pane correct,
autocomplete did not work

Unfortunately that leaves Geany as the worst of those that worked at all :(

In fact it would even be better if . and - autocomplete was turned
off for C++ rather than offering complete crap (and that isn't related
to this particular file unfortunately).

As my brain is now drained from all those, I leave it to someone else
to suggest some idea of a path forward.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] C++ Symbols problem

[Lex Trotman]

Hi All,

There is a problem with symbols in some C++ programs which causes some
class members to appear and disappear or move in the sidebar.
Needless to say this is *very* distracting.

The minimal program to demonstrate this is:

templatebool bclass problem;

template class problemfalse {
};

template class problemtrue {
int i_change;
};


The member i_change changes each time the symbols pane is updated,
correctly showing as part of the class at line 6, then part of the
class at line 3, then disappearing, then back to the class at line 6
etc.

In C++ this program has three class names:

a) at line 1 declaration of problembool
b) at line 3 definition of problemfalse
c) at line 6 definition of problemtrue

Note that these are distinct classes as if the names include bool,
true and false.

But neither symbols.c or the tagmanager parser includes the template
parameters in the name, instead showing both of the classes at line 3
and 6 as problem.

Discussion with Colomban on IRC indicated that this may be confusing
the symbol update algorithm.  Forcing a complete re-generation of the
symbols did indeed stabilise the sidebar.

I think that the problem is due to update_tree_tags() identifying the
parent of i_change just by name so it can't tell if line 3 or line 6
(or possibly line 1) is the parent.

If  i_change is shown in the symbol tree as part of the class at line
6 then it will be in the parent_tags hash with parent of problem.
If this is taken as problemof line 3 as parent, it will delete it
from the class at line 6 in pass 1 and as i_change is still in the
tags list will add it to the class at line 3 since thats what the
parent_tags hash says is its parent.

On the next symbol update, since what it thinks is the parent of
i_change (the class at line 3) does not in fact have i_change as a
member, it will be deleted from the tree and the tags list, so it
isn't added again in pass 2.

On the next symbol update i_change is not in the tree so it isn't in
the parent_tags hash so it is added where the tags list says is the
correct place.

If the order of the definitions at line 3 and 6 are reversed i_change
just alternates on and off, suggesting that it isn't the first
definition of the symbol problem that is the one found.

At least I think this is the mechanism?

Other than the hack to re-create the whole table each time, I'm not
sure how to cure it without distinguishing the three class names, and
that means modifying tagmanager/c.c (shudder).

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] C++ Symbols problem

[Lex Trotman]

 Cheers
 Lex

PS my mention on IRC of possible namespace problems as well just
turned out to be my typing a brace in the wrong place :-P
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Markers

[Lex Trotman]

On 12 March 2012 06:25, Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
 On Sun, 11 Mar 2012 12:33:07 +1100
 Lex Trotman ele...@gmail.com wrote:

 I don't think much is needed:

 1. Scintilla already provides the special symbol SC_MARK_AVAILABLE to
 indicate that the mark is available.

 I already replied to this [1]. Unless we want each plugin to allocate
 it's markers for each document, possibly receiving different numbers,
 we should have a bitmap in Geany.

 3. When a plugin needs a marker for a document it should search for
 one that is available on that document and use that, and set it back
 to available when it no longer needs it and on unload.  There are only
 32 to search so it isn't IMHO worth implementing anything faster.

 Oh, I see. So any plugin with markers must keep track of each document
 it allocated markers in. This is not going to be fun.

 why should
 a C language plugin steal markers froma Python file when the Python
 plugin also needs them??

 To be able to allocate markers #s in plugin_init(), and free them in
 plugin_cleanup(). To be able to work without tracking document file
 type changes.

Hi Dimitar,

Any plugin that is filetype specific must know which documents are its type.

I wouldn't expect (for example) GeanyLatex to interfere with my C#
programming.  Similarly I wouldn't expect the debugger plugin to try
to work on a language gdb doesn't understand, eg Java.

Maybe you should contact Matthew, during a conversation we had on IRC
he revealed a prototype for manageing all such limited resources, not
just markers, in a consistent manner.

Since the SC_MARK_AVAILABLE isn't, erm, available, for other recources
such as indicators, Matthew uses the suggested boolean map method.

@Frank, this would give a single consistent interface to acquire and
release all limited resources, markers, indicators, margins and
styles.

Cheers
Lex


 [1]
 http://lists.uvena.de/pipermail/geany-devel/2012-February/006629.html

 --
 E-gards: Jimmy
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Usage of plugin_help()

[Lex Trotman]

[...]
 Question is, what do we really want to have behind that function?

 The delivery format is less important than actually providing help.

 I guess that's set. But how would such a thing look like?

Well, since you are trying to get GP plugins to provide a ReST
formatted readme why not make it a recommendation for a ReST formatted
help which the GP build script can turn into an installed html file.
So the plugin_help() just needs to call utils_open_browser().

Use the same css as Geany's manual and get a consistent look and feel.

As to content, first guess recommended layout:

How to use
--
What it does, menu items, keybindings

Preferences
---
blah

How to configure
--
blah

The last is only needed if there is configuration beyond the
preferences settings.


Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Markers

[Lex Trotman]

On 11 March 2012 17:16, Alexander Petukhov de...@apetukhov.ru wrote:

 So all we need is the initialisation, and probably a common search
 routine for the convenience of plugins (although that isn't absolutely
 needed).  The smaller the patch the more likely someone has time to
 test it and commit it.



 I would vote for having utility functions that manages a list of available
 markers
 instead of letting plugins manually find those that are marked with
 SC_MARK_AVAILABLE.

 I can imagine a situation when some plugin set its markers for several
 documents but didn't do it for others,
 so when another plugin tries to set it's own markers it came to that markers
 idenifiers for the same markers are different in different documents that
 means it's another job to keep track of it.

Well, the plugins are just going to have to do this anyway, why should
a C language plugin steal markers froma Python file when the Python
plugin also needs them??

Cheers
Lex


 having such functions as utils_ui_get_marker(), utils_ui_free_marker() seems
 more clear and robust.

 Regards,
 Alex

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Usage of plugin_help()

[Lex Trotman]

Hi Frank,

Good question.


 Well... which means its not really defined what the user will expect
 once he push the button. Therefore we do have at least 2.5 major behaviors:
 - Geany is calling a browser and opening a webpage with info (spellcheck
 plugin)

Which gets a 404 error for me, and anyway expecting online connection
for a local plugin is *very* rude. If you provide a webpage make it
local.  And if it is online make sure it is available!

 - Its opening a message window with
        * a short info about plugin (e.g. geanyLaTeX)
        * a long help text about plugin (e.g. geanymacro)

Neither of these provide much help, if its called help then provide
*user* help, not something useless. /rant

 Question is, what do we really want to have behind that function?

The delivery format is less important than actually providing help.

That said, a webpage provides some formatting that helps to structure
the information, but it does need to meet the good webpage guide as
defined by me ;-)  (can be resized, uses my default text size, not
more than 40em wide text lines, *nothing* is pixel based, works in all
major browsers)

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Where have the thirdparty plugins gone?

[Lex Trotman]

On 2 March 2012 13:32, Matthew Brush mbr...@codebrainz.ca wrote:
 On 12-03-01 02:52 PM, Dominic Hopf wrote:

 Hi everyone,

 Lex pointed me to the issue, that the pages for the third-party plugins
 at http://plugins.geany.org/ are empty. I have to admit, that I maybe am
 not that up-to-date and thus, am not sure what actually happened to
 those plugins.

 Last thing I know of them is, that they were in the same SVN repository
 at SourceForge as Geany-Plugins. After the migration to GitHub they are
 gone - I guess that is intended.

 Does anyone know what happened to them? Do they exist anymore and just
 in another place? Or should I really remove them from the website?

 Regards,
 Dominic


 Hi,

 For as long as I can remember those 3rd party plugins pages have been blank
 there.

 Geany Mini Script was always outside of the real plugins source tree in
 SVN and was removed for Git. IIRC someone has recently shown interest in
 maintaining it and so IMO it should go into Geany-Plugins proper (ie. not
 3rd party) with a working README.

Well, thats up to the new maintainer.  IIUC the idea was that plugins
could be housed in the geany-plugins repo so people could find them,
but not have the be part of the combined plugins if the developer did
not want, or was unable to meet, the build or release schedule
requirements of the combined release.

Maybe Frank can say what the arrangement is intended to be now git
does things differently?


 I have no idea what the other 2 are for, but like I said, I've noticed them
 before and IIRC they never had any content there or code in the
 Geany-Plugins project (at least since I've been around, maybe Git can tell
 for sure?).

I am not sure where embrace got to in its inclusion, it was created in
2009 according to ML search.

There was some discussion about August last year looking for a
maintainer for embrace, some bloke called Matthew was pushing an
unofficial plugin called zencoding as an alternative, but that hasn't
become official yet either ;-)

I guess no maintainer was found. :-)

The only ML reference to externdbg is one from Dominic being confused
what it was, so its totally unknown AFAICT.

Cheers
Lex


 Cheers,
 Matthew Brush


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Commit messages on merges

[Lex Trotman]

[...]

 I guess if we can filter out merge commits and only show the real commit
 information it should be good?

 (See other message with individual commit messages)

Yeah, IMO git gives us lots of un-needed merge messages, not much more
we can really say other than merged master into branch, so we will
have to filter them for human consumption in newsletters anyway.

The alternative is to always re-base before committing merged branches
to master, which is probably better since we don't care how the
developer got to the end point and all the commits and merges she made
on the way, we just care what the commit to master does.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [geany/geany] 795ee4: Merge pull request #28 from RetroX/patch-1

[Lex Trotman]

On 25 February 2012 19:35, Frank Lanitz fr...@frank.uvena.de wrote:
 On Sat, 25 Feb 2012 10:43:10 +1100
 Lex Trotman ele...@gmail.com wrote:

 On 25 February 2012 09:44, Thomas Martitz
 thomas.mart...@student.htw-berlin.de wrote:
  Am 24.02.2012 23:34, schrieb Lex Trotman:
 
  I don't agree with this change, the types are just that, types, not
  keywords, they should not be highlighted as keywords.  They are not
  always available.  This change should be reverted.
 
 
  The list contained types before the commit and the commit just
  added more for completeness.
 
  I suggest using the secondary for types instead.

 Yes, good idea, if I understand the comment in
 highlightingmappings.h:206 it is meant for types.

 Cheers
 Lex

 PS the existing list contains the fundamental types that are always
 available without headers, these new ones need a header (though size_t
 is used so much that almost any header will do :)


 I did like that idea adding more often used one. But you are right
 cleaning up a bit and maybe resorting them would be might a ice idea.

 Cheers,
 Frank

Hi Frank,

I think Thomas' idea of adding those that are not fundamental types to
the secondary list is the right thing, they get highlighted as types
not keywords and as you say the common ones are then available.  Best
of both worlds :).

I think all the ones that were originally in the list were fundamental
in C++11, so its only the new ones IIUC.

I was going to do it today but havn't had time.

Cheers
Lex



 --
 http://frank.uvena.de/en/

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [geany/geany] 795ee4: Merge pull request #28 from RetroX/patch-1

[Lex Trotman]

I don't agree with this change, the types are just that, types, not
keywords, they should not be highlighted as keywords.  They are not
always available.  This change should be reverted.

Cheers
Lex

On 25 February 2012 08:01, Frank Lanitz git-nore...@geany.org wrote:
 Branch:      refs/heads/master
 Author:      Frank Lanitz fr...@frank.uvena.de
 Committer:   Frank Lanitz fr...@frank.uvena.de
 Date:        Fri, 24 Feb 2012 21:01:08
 Commit:      795ee4cf4bea525814b5793a6771d3da78f6c863
             
 https://github.com/geany/geany/commit/795ee4cf4bea525814b5793a6771d3da78f6c863

 Log Message:
 ---
 Merge pull request #28 from RetroX/patch-1

 Added size_t, ptrdiff_t, intN_t to filetypes.cpp.


 Modified Paths:
 --
    data/filetypes.cpp

 Modified: data/filetypes.cpp
 2 files changed, 1 insertions(+), 1 deletions(-)
 ===
 @@ -3,7 +3,7 @@

  [keywords]
  # all items must be in one line
 -primary=alignas alignof and and_eq asm auto bitand bitor bool break case 
 catch char char16_t char32_t class compl const constexpr const_cast continue 
 decltype default delete do double dynamic_cast else enum explicit export 
 extern false final float for friend goto if inline int long mutable namespace 
 new noexcept not not_eq nullptr operator or or_eq override private protected 
 public register reinterpret_cast return short signed sizeof static 
 static_assert static_cast struct switch template this thread_local throw true 
 try typedef typeid typename union unsigned using virtual void volatile 
 wchar_t while xor xor_eq
 +primary=alignas alignof and and_eq asm auto bitand bitor bool break case 
 catch char char16_t char32_t class compl const const_cast constexpr continue 
 decltype default delete do double dynamic_cast else enum explicit export 
 extern false final float for friend goto if inline int int8_t int16_t int32_t 
 int64_t long mutable namespace new noexcept not not_eq nullptr operator or 
 or_eq override private protected ptrdiff_t public register reinterpret_cast 
 return short signed sizeof size_t static static_assert static_cast struct 
 switch template this thread_local throw true try typedef typeid typename 
 union unsigned using virtual void volatile wchar_t while xor xor_eq
  secondary=
  # these are some doxygen keywords (incomplete)
  docComment=attention author brief bug class code date def enum example 
 exception file fn namespace note param remarks return see since struct throw 
 todo tparam typedef var version warning union



 --
 This E-Mail was brought to you by github_commit_mail.py (Source: TBD).
 ___
 Geany-commits mailing list
 geany-comm...@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-commits
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [geany/geany] 795ee4: Merge pull request #28 from RetroX/patch-1

[Lex Trotman]

On 25 February 2012 09:44, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 24.02.2012 23:34, schrieb Lex Trotman:

 I don't agree with this change, the types are just that, types, not
 keywords, they should not be highlighted as keywords.  They are not
 always available.  This change should be reverted.


 The list contained types before the commit and the commit just added more
 for completeness.

 I suggest using the secondary for types instead.

Yes, good idea, if I understand the comment in
highlightingmappings.h:206 it is meant for types.

Cheers
Lex

PS the existing list contains the fundamental types that are always
available without headers, these new ones need a header (though size_t
is used so much that almost any header will do :)


 Best regards.
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Plugins Guidance

[Lex Trotman]

On 23 February 2012 01:13, Colomban Wendling lists@herbesfolles.org wrote:
 Le 21/02/2012 05:15, Lex Trotman a écrit :
 In another thread
 http://lists.uvena.de/geany/2012-February/007808.html a couple of
 things were mentioned about guidelines for plugins to be good
 citizens.  So I thought it worthwhile gathering any suggestions so the
 docs could be updated in one go.

 Items mentioned to date:

 1. don't set default keybindings, users will be annoyed if you
 override their personal bindings.  Always let the user tell the plugin
 what to use.

 I'm not convinced that saying not set default is the best solution to
 the conflict problem.  Couldn't Geany simply not override an already
 existent keybinding when installing a plugin's one?

Thats possible, but does Geany know that it is a plugin setting the
keybinding?

If we can do it, might it not also cause user confusion when
keybindings are not applied?  What about when adding several plugins
some of which clash in keybindings?

There would have to be some sort of notification (I guess by plugin
manager?) and that in itself is also probably annoying.

And even if the plugin didn't have a default shortcut, I guess if the
user set one and the plugin saved it, then the user unloaded the
plugin, set the same keybinding somewhere else and then re-loaded the
plugin you still get a clash so detecting it and notifying the user is
needed in any case.

(Sorry no solutions, just questions)


 2. don't spread menu items through the Geany menus, users don't know
 where to look and if several plugins add things to the same place the
 menu may become unworkable.  You don't know what other plugins the
 user will enable at the same time.

 I'm not sure about this one either, though I understand that too many
 items everywhere may become a problem.

 But if the plugin provides a feature like, say, uniqueness (ref. thread
 in the general ml), the menu would better fit in edit-format or
 something;  and e.g. GeanyGenDoc places an item in editor context
 menu-insert.

Well, its only the plugin developers idea of where it belongs,
personally I would not want uniqueness in format.  Also if we change
the Geany menu all the plugins have to scramble to fix themselves.

 IMO this makes the UI better than fulfilling the tools menu with various
 stuff, since it's the appropriate place for such an item.

Just try getting agreement on appropriate, its a bikeshed.  Unless
the plugin has a preference to choose tools or somewhere else.


 I understand that if 10k plugins adds items in various menus it'd start
 to be annoying, but OTOH, is a tool menu with 10k items really better?

Well, at least its isolated and the usability of the rest of Geany
isn't impacted.

I don't think that there is a clear cut solution, but IMHO on balance
it is better to keep the mess constrained to one place.

[...]

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Plugins Guidance

[Lex Trotman]

[...]
 IMO, if it's a simple plugin and provides a generic editor feature Geany is
 missing, it would be fine to put it in the corresponding menu (ex.
 Edit-Format-Remove Duplicate Lines),

Thats the problem, I would never have looked for remove duplicate
under format, for me if it goes in the standard menu it goes in
commands, maybe under duplicate line command.

 but if it's a big plugin with lots of
 menu items, even if they fit better in the regular menus, they should still
 be put in a submenu inside the Tools menu. That's my opinion anyway.

Agree here, one top level one in tools and the rest under it.  Except
for complete units of functionality like debug that should go in the
top level.

Maybe there should be a filetype specific top level item too, where
all the language specific plugins could put stuff, and over time we
could migrate language specific things to it.

Cheers
Lex


 Cheers,
 Matthew Brush


 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel