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

[Colomban Wendling]

Le 02/10/2012 05:03, Lex Trotman a écrit :
> 
> 
> On 2 October 2012 00:43, Colomban Wendling  <mailto:lists@herbesfolles.org>> wrote:
> 
> 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 doubt we make a difference when saving the config file -- since as you
said yourself saving only a part of a keyfile isn't that easy --, but I
don't know for sure.

>  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.

Again, I don't see the point.  If saving the configuration doesn't
happen because Geany get killed, if it was separated and still only
saved on change wouldn't change anything.

> 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

Oh dear, configuration on an unsafe remote.  OK, that's an argument why
saving config periodically might not be that safe -- although normally a
network failures would result in *not* saving the file, not corrupting
it (given that we use an atomic write like g_file_set_contents()).

> (not to mention potential performance issues).

Well, performance issue is inherent to periodic saving, it being session
only or whole config doesn't change anything.

> > 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 :)

Hehe, you should've rather have listed advantages ;)

> > 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.

Yeah, but you *choose* what you add, you don't add the whole project
directory but maybe on the first import.

>  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 g

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

[Colomban Wendling]

Le 02/10/2012 00:26, Matthew Brush a écrit :
> On 12-10-01 03:05 PM, Colomban Wendling wrote:
>> Le 01/10/2012 23:15, Matthew Brush a écrit :
>>> On 12-10-01 07:43 AM, Colomban Wendling wrote:
>>>> 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.
>>>>
>>>
>>> Open your favourite project in Geany and open a specific set of files
>>> you need to work on a task, get the order of the files just right,
>>> adjust the Geany window position and size and then get your find dialogs
>>> positioned just perfect on your second screen. Now unplug your computer.
>>> You will see :)
>>>
>>> For me it takes more time to get Geany back in order (finding project
>>> file since it's not saved in the recent project list[1], finding open
>>> files related to current task, since they aren't saved in recent files
>>> list[2], etc.) than it does to restart the whole computer.
>>>
>>> P.S. My workaround (because my computer crashes a lot due to Flash) is
>>> to get everything set up how I want for the current task, and then to
>>> close Geany normally to force saving of all settings and then to reopen
>>> it :)
>>
>> As I read Lex's sentence, he spoke about settings, not open files.  And
>> anyway, I don't see what separating file list from the rest of the
>> config change in that matter.  It doesn't magically brings
>> immediate/periodical saving of the file list, and we can very well save
>> everything *including the file list* without that.  So I don't see why
>> it's an argument in favor (or against) $subject.
>>
> 
> It's an argument in favour of "not rushing at quite time" (ie.

yes, but I don't see the probably obvious link between "not rushing at
quit time" and $subject.

> periodically saving the .conf file(s) instead of only on closing) since
> you said you didn't see what was so great about it.

what I meant is that *we already save when prefs changes* so I don't see
what's the problem with saving *also* at quit time.  Anyway, I think you
got my point, I got yours so there's probably no need to go further in
the explanations -- but maybe why $subject helps for that matter.

> 
> 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] Separating session file lists from config (again)

[Colomban Wendling]

Le 01/10/2012 23:15, Matthew Brush a écrit :
> On 12-10-01 07:43 AM, Colomban Wendling wrote:
>> 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.
>>
> 
> Open your favourite project in Geany and open a specific set of files
> you need to work on a task, get the order of the files just right,
> adjust the Geany window position and size and then get your find dialogs
> positioned just perfect on your second screen. Now unplug your computer.
> You will see :)
> 
> For me it takes more time to get Geany back in order (finding project
> file since it's not saved in the recent project list[1], finding open
> files related to current task, since they aren't saved in recent files
> list[2], etc.) than it does to restart the whole computer.
> 
> P.S. My workaround (because my computer crashes a lot due to Flash) is
> to get everything set up how I want for the current task, and then to
> close Geany normally to force saving of all settings and then to reopen
> it :)

As I read Lex's sentence, he spoke about settings, not open files.  And
anyway, I don't see what separating file list from the rest of the
config change in that matter.  It doesn't magically brings
immediate/periodical saving of the file list, and we can very well save
everything *including the file list* without that.  So I don't see why
it's an argument in favor (or against) $subject.

> 
> Cheers,
> Matthew Brush
> 
> [1] Well for favourite projects it might be saved, but not if it's a new
> project that hasn't experienced a closing before.
> 
> [2] Unless you count the lame GTK+ open dialog recent files list which
> is quite useless.
> ___
> 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)

[Colomban Wendling]

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.

> 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.

> 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.

> 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.

> 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).

> 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, and
that I don't like the proposed solution -- not that I have a better one.
 On the first point, I'd be happy to be proven wrong though, maybe I
just don't see the light.

Regards,
Colomban


[1]  Yes, I don't really see the point.  OK, the settings we have in
project files might be useful for the project.  Indentation type & with,
and EOL style.  First two are saved in each file by well known editors
(vim, emacs).  Generally when people put project files in their VCS it's
because those project files are used as build system too.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Moving RC styles to a file

[Colomban Wendling]

Hi guys,

I'm considering moving our hard-coded custom styles (notebook tab button
sizing, monospaced search entries and unmatched search entries) to an
external resource file (geany.gtkrc in the datadir) -- patch attached.

The main reason to do this is to make it easier to replace this by a CSS
file for my GTK3 port (attempt).  However, we can see a few other
interesting (or not) points:

+ this removes some hard-coded stuff in a few places;
+ this actually removes an overall of 16 lines, and actually 39 lines
  of code (those 23 lines being in the resource file);
+ easier to replace with a CSS file in the GTK3 port (and gives the
  same advantages than with the RC files);
- that's another file to load.

So the question is, are we happy to load another file at startup,
besides the Glade XML?  I don't think it's a performance problem,
moreover the file being probably stored in a near location to the Glade
file, but since we always tried to load as less files as possible, do we
want to add this file?

Since now we need to load the Glade file anyway, I think it's less of a
concern to add additional external files.  If we think external files
are OK, maybe we'd like to also move our custom images out of images.c
to normal files in out datadir.  Actually, we currently have 7 inline
images (aladin (logo), build, close all, and two save all, and the two
used in the completion popup), but also "normal" icons (for the symbol
list for example).

So, what do you think?

Regards,
Colomban
>From 37607d54e82dd83ea49c6422ec61563af60a66de Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Sat, 29 Sep 2012 20:18:19 +0200
Subject: [PATCH] Move custom styles to a resource file

---
 Makefile.am  |3 ++-
 data/geany.gtkrc |   23 +++
 src/notebook.c   |   11 ---
 src/search.c |   28 
 src/ui_utils.c   |   26 --
 wscript  |1 +
 6 files changed, 38 insertions(+), 54 deletions(-)
 create mode 100644 data/geany.gtkrc

diff --git a/Makefile.am b/Makefile.am
index db612be..d3035f0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -24,7 +24,8 @@ SYS_DATA_FILES = \
 	$(srcdir)/data/templates/* \
 	$(srcdir)/data/templates/files/* \
 	$(srcdir)/data/colorschemes/* \
-	$(top_srcdir)/data/geany.glade
+	$(top_srcdir)/data/geany.glade \
+	$(top_srcdir)/data/geany.gtkrc
 
 EXTRA_DIST = \
 	autogen.sh \
diff --git a/data/geany.gtkrc b/data/geany.gtkrc
new file mode 100644
index 000..7947c7d
--- /dev/null
+++ b/data/geany.gtkrc
@@ -0,0 +1,23 @@
+# custom GTK2 style for Geany
+
+# make close button on the editor's tabs smaller
+style "geany-close-tab-button-style" {
+	GtkWidget::focus-padding = 0
+	GtkWidget::focus-line-width = 0
+	xthickness = 0
+	ythickness = 0
+}
+widget "*.geany-close-tab-button" style "geany-close-tab-button-style"
+
+# use monospaced font in search entries for easier reading of regexp (#1907117)
+style "geany-monospace" {
+	font_name = "Monospace"
+}
+widget "GeanyDialogSearch.*.GtkEntry" style "geany-monospace"
+
+# set red background for GtkEntries showing unmatched searches
+style "geany-search-entry-no-match-style" {
+	base[NORMAL] = "#"
+	text[NORMAL] = "#"
+}
+widget "*.geany-search-entry-no-match" style "geany-search-entry-no-match-style"
diff --git a/src/notebook.c b/src/notebook.c
index 3bf62a4..420c4e3 100644
--- a/src/notebook.c
+++ b/src/notebook.c
@@ -535,17 +535,6 @@ static gboolean notebook_tab_bar_click_cb(GtkWidget *widget, GdkEventButton *eve
 
 void notebook_init()
 {
-	/* Individual style for the tab close buttons */
-	gtk_rc_parse_string(
-		"style \"geany-close-tab-button-style\" {\n"
-		"	GtkWidget::focus-padding = 0\n"
-		"	GtkWidget::focus-line-width = 0\n"
-		"	xthickness = 0\n"
-		"	ythickness = 0\n"
-		"}\n"
-		"widget \"*.geany-close-tab-button\" style \"geany-close-tab-button-style\""
-	);
-
 	g_signal_connect_after(main_widgets.notebook, "button-press-event",
 		G_CALLBACK(notebook_tab_bar_click_cb), NULL);
 
diff --git a/src/search.c b/src/search.c
index 68ab767..22bc29b 100644
--- a/src/search.c
+++ b/src/search.c
@@ -423,28 +423,6 @@ void search_find_selection(GeanyDocument *doc, gboolean search_backwards)
 }
 
 
-/* this will load a GTK rc style to set a monospace font for text fields(GtkEntry) in all
- * search dialogs. This needs to be done only once.
- * The monospace font should increase readibility of regular expressions containing spaces, points,
- * commas and similar (#1907117). */
-static void load_monospace_style(void)
-{
-	static const gchar *rcstyle =
-		"style \"geany-monospace\"\n" \
-		"{\n" \
-		"font_name=\"Monospa

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

[Colomban Wendling]

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.

> 
> 
> 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

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

[Colomban Wendling]

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? :)

Cheers,
Colomban

> The lists will be down during move for about 1-2 hours.
> 
> I'll send a reminder shortly before starting with the actual move next week.
> 
> 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] Bug tracker: using group for the version closing the bug

[Colomban Wendling]

Hi guys,

As you might already have noticed, I added a few groups to our tracker
reflecting the Geany versions, and I'm proposing to use those to track
the version in which the bug was/will be fixed.  I hope this will help
us to know which bugs we fixed in the current version (to help updating
NEWS), and users to know in which version their bug is fixed.

So, when you fix a bug, it'd be great if you could also set the group
field accordingly.  Or do you think it's a stupid idea?

Regards,
Colomban


PS, to every bug reporter reading this:

Please do not initially set the group, it's not the version in which you
found the bug.

However, if one of the bug you reported was fixed but doesn't have a
group assigned and you know exactly in which version it was fixed, you
can very well set the group as appropriate, that'd be awesome :)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [geany/geany] 9d2dab: Fix an off-by-one issue in sci_get_position_from_line()

[Colomban Wendling]

Le 17/09/2012 20:22, Colomban Wendling a écrit :
> Branch:  refs/heads/master
> Author:  Colomban Wendling 
> Committer:   Colomban Wendling 
> Date:Mon, 17 Sep 2012 18:22:52
> Commit:  9d2dab8fcf4aa4d2b890724b44d483d273732b3c
>  
> https://github.com/geany/geany/commit/9d2dab8fcf4aa4d2b890724b44d483d273732b3c
> 
> Log Message:
> ---
> Fix an off-by-one issue in sci_get_position_from_line()

Hum, or not, it was a issue in symbols_get_current_function().  Sorry
for that.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] SourceForge Upgrade?

[Colomban Wendling]

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/


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.


> @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.

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

[Geany-devel] Scoped Ruby declarations, with a hackish patch

[Colomban Wendling]

Hi guys,

I saw that the ruby parser don't properly generate tags declarations like:

class Foo::Bar
end

which should generate a tag "Bar" with the scope "Foo";  but it
generates a tag "Foo" and simply ignores "Bar".  This seems to apply to
modules, classes and methods at least -- almost everything.

So I wanted to fix that.  Unfortunately the scoping code in CTags don't
really support to easily put several scopes at the same "level", e.g. if
you want to push several scope you gotta handle the popping yourself.
And since there is one single block end, it's tricky to do.

Since I was way too lazy (and didn't even found a good implementation)
to fix that, I just did it the dirty way: reading the whole "Foo::Bar"
as a single tag name ("Foo.Bar") and tuning the code registering the tag
to split this on the last ".", putting the left part (if any) in the
scope.  Patch attached.  This is quite dirty, but works fine unless a
legitimate tag may include a "." in its name, which doesn't seem the
case currently looking at the parser.

Note that Ruby isn't the only language that allows such kind of scoping.
 For example, Vala allows to prefix stuff with a namespace -- and there
is the same problem here.

So, especially Nick, what do you guys think of this?  Is this patch too
dirty?  Do somebody have a better idea?  Or is this too dirty and "we
don't care because nobody writes ruby anyway"?  In one word: opinions?

Thanks,
Colomban
>From f0da754670cca4d4c3ddd0c8d7295881372ba3b6 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Thu, 6 Sep 2012 20:45:57 +0200
Subject: [PATCH] Correctly parse Ruby declarations with inline scoping

Generate the appropriate tags for declarations like:

	class Foo::Bar::Baz
	end

The implementation here is quite hackish but works fairly reliably.
---
 tagmanager/ctags/ruby.c |   38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/tagmanager/ctags/ruby.c b/tagmanager/ctags/ruby.c
index a614eb1..c7695ef 100644
--- a/tagmanager/ctags/ruby.c
+++ b/tagmanager/ctags/ruby.c
@@ -132,11 +132,26 @@ static void emitRubyTag (vString* name, rubyKind kind)
 {
 	tagEntryInfo tag;
 	vString* scope;
+	const char *this_name;
 
 	vStringTerminate (name);
 	scope = stringListToScope (nesting);
 
-	initTagEntry (&tag, vStringValue (name));
+	/* extract scope and actual name from tag name in case of tags like
+	 * "class Foo::Bar::Baz" which are parsed as a single name, "Foo.Bar.Baz" */
+	this_name = strrchr (vStringValue (name), '.');
+	if (this_name)
+	{
+		if (vStringLength (scope) > 0)
+			vStringPut (scope, '.');
+		vStringNCat (scope, name, this_name - vStringValue (name));
+		vStringTerminate (scope);
+		this_name ++;
+	}
+	else
+		this_name = vStringValue (name);
+
+	initTagEntry (&tag, this_name);
 	if (vStringLength (scope) > 0) {
 	tag.extensionFields.scope [0] = "class";
 	tag.extensionFields.scope [1] = vStringValue (scope);
@@ -230,7 +245,26 @@ static void readAndEmitTag (const unsigned char** cp, rubyKind expected_kind)
 	if (isspace (**cp))
 	{
 		vString *name = vStringNew ();
-		rubyKind actual_kind = parseIdentifier (cp, name, expected_kind);
+		vString *chunk = vStringNew ();
+		rubyKind actual_kind;
+		unsigned int i = 0;
+
+		/* parse the identifier, allowing scoping like "class Foo::Bar::Baz" */
+		while (1)
+		{
+			actual_kind = parseIdentifier (cp, chunk, expected_kind);
+			if (i++ > 0)
+vStringPut (name, '.');
+			vStringCat (name, chunk);
+			vStringClear (chunk);
+
+			if (actual_kind != K_UNDEFINED && (*cp)[0] == ':' && (*cp)[1] == ':')
+*cp += 2;
+			else
+break;
+		}
+		vStringDelete (chunk);
+		vStringTerminate (name);
 
 		if (actual_kind == K_UNDEFINED || vStringLength (name) == 0)
 		{
-- 
1.7.10.4

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

Re: [Geany-devel] Squiggle pixmap

[Colomban Wendling]

Le 05/09/2012 08:02, Matthew Brush a écrit :
> On 12-09-04 09:47 PM, Lex Trotman wrote:
>> 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
>>
> 
> It should be fine since it's using Cairo on all platforms anyway.
> 
>> 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.
>>
> 
> I agree it's not worthwhile to make it a setting. The only difference as
> far as users is concerned is that it's just faster now.
> 
>> If no one has any substantive issues in the meantime I'll commit the
>> attached patch in a couple of weeks.
>>
> 
> +1

Overall +1

> Only thing I'd change is to add a comment explaining why it was switched
> from INDIC_SQUIGGLE to the faster one.

I think it'd be fine in the commit message -- I don't think an inline
comment is required.

Cheers,
Colomban

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

Re: [Geany-devel] Ship with Grep on Windows?

[Colomban Wendling]

Le 03/09/2012 09:57, Matthew Brush a écrit :
> Hi,
> 
> It would be useful to ship the Grep binary[1] (and dependencies) with
> Geany for Windows. It could be added to the installer for not too much
> extra size[2] and would enable the "Find in Files" feature to work on
> Windows by default. Normally I wouldn't like to add more stuff to the
> installer but I think without it Geany is missing a very useful feature
> on Windows by default.
> 
> Does it sound reasonable or no?

It looks reasonable and even desirable to me, but I must admit I don't
really care since I almost never use Windows anyway…

BTW, you say it adds 1-2MB, but what's the overall size of the
installer?  If it is 2MB on a 4MB installer it looks huge, but if the
installer was already 40MB large I doubt anybody would notice.

Cheers,
Colomban

> 
> Cheers,
> Matthew Brush
> 
> [1] Probably this one? http://gnuwin32.sourceforge.net/packages/grep.htm
> [2] Based on above link maybe around 1-2 MB if its dependencies aren't
> already shipped with Geany (ex. libiconv, pcre, etc.).

___
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

[Colomban Wendling]

Le 29/08/2012 02:34, Lex Trotman a écrit :
> On 29 August 2012 04:02, Colomban Wendling  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 Home and End, 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 A and E 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  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 Something)?
>>
>> 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

> 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.

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.

> 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 home/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
2) somebody who wants to change to "display line mode" needs to change 8
bindings (well, 4 manually at least).

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


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

The thing is that we bind Home and End by default [1], so those bindings
would override the Scintilla defaults my patch sets;  and thus would
"break" the setting.  And here comes the compatibility question if we'd
like to avoid the issue.  But see that even removing the bindings
altogether would only affect people who actually changed it, e.g. 0.01%
of the users maybe (no, I'm NOT saying we can shit on 'em) so even a
break wouldn't make so much people angry.
Moreover we wouldn't need to remove those bindings if they were not
saved in the user's s

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

[Colomban Wendling]

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 Home and End, 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 A and E 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  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 Something)?

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

What about backward compatibility?


Looking forward to read you :)
Regards,
Colomban


[1]
https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3041948&group_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.
>From 5f82052cb7276bd8d1197651636a9c6ceae43f37 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Tue, 28 Aug 2012 19:41:42 +0200
Subject: [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 A and E to emulate a
Bash/Emacs-like behavior).

Closes #3041948.
---
 data/geany.glade |   31 ---
 src/editor.c |   20 ++--
 src/editor.h |1 +
 src/keyfile.c|2 ++
 src/prefs.c  |6 ++
 5 files changed, 51 insertions(+), 9 deletions(-)

diff --git a/data/geany.glade b/data/geany.glade
index 675ffbc..54f396e 100644
--- a/data/geany.glade
+++ b/data/geany.glade
@@ -2693,6 +2693,23 @@
   
 
 
+  
+Home and End keys operate on display lines
+False
+True
+True
+False
+Whether Home and End keys operate on logical or display lines.
+True
+True
+  
+  
+False
+False
+2
+  
+
+
   
 Disable Drag and Drop
 False
@@ -2706,7 +2723,7 @@
   
 False
 False
-2
+3
   
  

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

[Colomban Wendling]

Hi Matthew,

Le 04/08/2012 04:59, Matthew Brush a écrit :
> Since some plugins share dependencies, is there some way to coordinate
> both the versions of the dependencies and the build system? For example
> if Debugger and MultiTerm both depend on LibVTE, to make sure they use
> compatible API versions and depend on the same version. I'm thinking
> it's not great to require LibFoo v0.01 for one plugin and LibFoo v0.02
> for another, even if they (can) use common API (and probably do already).
> 
> I guess it's more of a build system question, is it realistic?
> 
> Common/interesting dependencies based on a quick scan of the `build`
> directory:
> 
> [...]
> 
> For most of the dependencies, I think the GEANY_CFLAGS/GEANY_LIBS would
> cover it (gtk, glib, gio(?), gmodule, gthread, etc.). For the others
> maybe there could be some tweaking of versions to at least make the
> dependency versions the same. I know for my two plugins (DevHelp and
> MultiTerm) the versions of the dependencies are not very much of a
> concern and I mostly copied existing plugins' .m4 files.
> 
> Just a few thoughts I had while mucking around with the build system.

I'm not sure I understand your concern.  Dependencies should reflect
what's needed for the package (here, the plugin) to build/run or
whatever.  Since all libraries either keep backward API compatibility or
make it possible to have both version at the same time [1] (either by
changing name/including major version in it or by following common rules
about versionning (see Libtool Versionning in your favorite manual)), I
don't see chat can be the problem.

If you have library X in version 64, and have plugin A depend on version
>= 21 and plugin B on version >= 50, both are happy.  If you had version
42 of the library, only plugin A would have built.  Nobody expects you
to install version 21 AND version 50 of the library.

So honestly I don't see what your concern is.  If plugin A can work with
version 21 of the library X but plugin B uses new stuff that is only
available since version 50, I don't see why we should either prevent
plugin A to accept version < 50 or plugin B to use that new API.

For GTK2 or GLib, we might want to ask authors whether they can stick to
a particular version, e.g. to the same version Geany requires so
hopefully one could always have the plugins if they have Geany -- unless
they depend on another library.  But IMO that's a special case for these
two libraries Geany also uses, and I don't even think that we should
really prevent one to depend on a newer version of GTK2 if they want a
feature from it.


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.


Regards,
Colomban


[1] or you just have to kill their author and/or your distributor... :(
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Code formatter

[Colomban Wendling]

Le 19/07/2012 01:50, Jacob Strohm a écrit :
> Le 18/07/2012 05:53, Matthew Brush a écrit :
>
>> I'd personally be very interested in using a plugin that can format
>> the code precisely automatically. IIRC VisualStudio does this very
>> well but is not flexible as to code style (or I didn't find the
>> preferences). I suspect it would be quite difficult to write a good
>> one that is at the same time accurate, flexible and supports
>> multiple non-similar languages (C-style vs Python, for example).
> 
> 
> Way to put the pressure on  :).  I haven't used Visual Studio's, but I
> will check it out, along with Eclipse's version.  Also, since I only
> really have experience with C-style languages, it will (initally at
> least) be focused on that.  Suggestions are always welcome.

I'm a bit late, but I just finally managed to commit my one-year-old
attempt at writing such a plugin, so I link it here if you're
interested: https://github.com/b4n/grind

I plan to finish it one day or the other, but it's not really a
high-priority thing for me (one can tell since I didn't event committed
much of it for months) because I don't have much need (or even use case)
for such a plugin.  I actually started it to answer somebody else's
wish, and I found interesting and funny to try doing it, but it was
quite big and requires time... argh, time.

Anyway, if you want to improve it, send me patch (I would review them)
or take something from it (it's under GPLv2), feel free.

Hope it helps.

Regards,
Colomban
___
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

[Colomban Wendling]

Le 28/07/2012 17:16, Vladi Belperchinov-Shabanski a écrit :
> hello,

Hi!

> this is my first post so I'd like to thank all programmers
> working on geany. it is so close to perfect :) thanks!

Welcome here then, and thanks a lot :)

> I keep my ~/.config/geany dir under git so I can
> distribute my environment prefs on all machines 
> I use. unfortunately there are some config entries
> which always collide since they are "local" to the 
> current machine. those are:
> 
> [geany]
> geometry
> 
> [files]
> all-of-them-...
> 
> I modified keyfile.c to keep all those in separated
> (session/local) file so it can be excluded from git.

I understand your concern, but do splitting this into two files have any
other benefit than making it simpler to keep it in Git?  Moreover, one
could imagine to commit to git only the relevant parts of the file (git
add -p & friends).  OK, it's a bit tedious but shouldn't be required
that often, is it?

My concern is that this adds a new config file, and particularly *moves*
some settings around.  This leads to the need to maintain compatibility
code to load from one file or the other, which is always boring an ugly.

So, I'm not sure such a change is really wanted if it only addresses
configuration spreading, that could even arguably be done with a fresh
config file/by stripping uninteresting parts.

However, maybe splitting "session" things out might help towards a
better support for saving multiple instance configurations, and if we
see that such changes would help on that subject too, the noise might be
worth.  Dimitar, Eugene, Nick, Matthew, Lex..., thoughts?

> diff/patch is against 
> commit 1ce4b1fac516f89dadb639cb773c76b68cfa286b
> 
> I'd like to ask for a review of the patch?

Apart what I said above, the patch looks very clean but:

 * we use tabs for indent (width set to 4), not 2 spaces
 * as said above, you need to add backward compatibility code, to load
the prefs to the old file as a fallback.


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

Re: [Geany-devel] OSX build error: ld: unknown option: --export-dynamic

[Colomban Wendling]

Le 17/07/2012 22:43, Matthew Brush a écrit :
> On 12-07-17 01:32 PM, Sean Felipe Wolfe wrote:
>> Sorry to be kind of spammy today. Just ran into what looks like a
>> build error? I cloned the git repo, ran autogen.sh, and make is giving
>> me this error:
>>
>> -
>>
>>CC utils.o
>>CC vte.o
>>CXXLD  geany
>> ld: unknown option: --export-dynamic
>>
>> -
>>
>> This is on osx Lion. Any suggestions?
>>
>>
> 
> Yep, this and your last problem were both things I had to figure out
> too. This export dynamic problem is because Geany doesn't deal with OSX
> separately and lumps it in with "non-Windows" in the Makefile.
> Unfortunately this linker flag is invalid on OSX but is needed on Linux
> (and others?) for Glade to connect to the signal handlers at runtime.
> 
> Quick Fix: Just delete everywhere you see `-Wl,--export-dynamic` in the
> Makefile.am files (probably only in `src/Makefile.am`). We can't do this
> in Geany proper because it won't work correctly on Linux then.
> 
> Real Fix: In the configure.ac, detect OSX somehow and do an
> AM_CONDITIONAL or something like this so that the Makefile can set the
> LDFLAGS differently for OSX than other Unices. If done correctly, a
> patch would be most welcome. I can't remember if I fixed this properly
> in my changes or if I just did the quick fix.

...or we could drop our flag and let GModule pkg-config flags deal with
it.  Fixed with commit
https://github.com/geany/geany/commit/d11f9a51b939bf39c3c1676ab823147d460ede75

Regards,
Colomban

> 
> 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] Dropping Waf support?

[Colomban Wendling]

Le 16/07/2012 19:36, Enrico Tröger a écrit :
> Hey all,
> 
> this topic has been brought up already a couple of times, for example on
> [1].
> 
> What do you think about dropping Waf support in Geany and in the
> Geany-Plugins project?
> 
> While I was defending Waf in Geany, I somewhat changed my mind. Not
> because I don't like it anymore, but I increasingly see the efforts in
> maintaining two (to be exactly three for Geany) build systems is too
> much. Since the make/MSYS build system support seems to get better and
> better due to Nick's and Dimitar's work on it, I thought about dropping
> the Waf support. It seems nobody knows it well enough and probably
> except for a few users nobody is using it.
> (And obviously I don't do so much anymore and also lost a bit interest
> in maintaining forever.)
> 
> The other thing is that Waf causes often problems for distro packages,
> especially for the Debian folks [2].
> 
> So, I'd go the easy way in this case and just remove Waf. Then we only
> need to maintain the autotools based build system for non-Windows
> systems and the make based for Windows.
> 
> For Geany-Plugins, we would need to get something working on Windows but
> maybe we could re-use Geany's make based system for Windows here.
> 
> 
> What do you guys think?

I don't mind much, since I don't use Waf nor build on Windows myself.
But yes, I agree that it Autotools and Windows-specific makefiles covers
all platforms there is no need to maintain an N-th build system.

This said, the only time I wanted to build on Windows I used Waf --
though I haven't even tried the specific makefiles.

So I don't mind, but I probably won't maintain Waf either because of a
lack of interest and knowledge.

My 2¢.  Regards,
Colomban

> 
> 
> [1]
> http://sourceforge.net/tracker/index.php?func=detail&aid=3460449&group_id=153444&atid=787794
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645190
> 
> Regards,
> Enrico
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] GeanyLua: use of deprecated Scintilla features SCI_SETUSEPALETTE

[Colomban Wendling]

Le 08/07/2012 11:27, Enrico Tröger a écrit :
> Hi all,

Hi Enrico,

> since we obviously don't have a maintainer for GeanyLua, this is
> addressed to the list:
> 
> GeanyLua wraps the in the latest Scintilla deprecated features
> SCI_SETUSEPALETTE and SCI_GETUSEPALETTE.
> As far as I could see, there is no further use of these features, just
> the wrapper so they could be used in Lua scripts.
> 
> Unfortunately, since Scintilla won't define the constants used by
> GeanyLua unless compiled with INCLUDE_DEPRECATED_FEATURES defined, this
> breaks the build of GeanyLua against Geany from GIT/master (and so the
> geany-plugins build as a whole and the nightly builds).
> 
> 
> I'd suggest to simply remove those two wrapped functions from GeanyLua.
> Though that would mean a hard compatibility break. I guess that it's
> probably that simply nobody uses these functions.
> 
> However, to be more safe, we could also deprecate these functions in
> GeanyLua in some way, so that some sort of migration is possible.

What I planned to do was to keep those as-is for the release of today,
and remove them (with an update of that API using
geanylua/util/mkiface.lua) straight after the 1.22 release.

Of course, it don't resolve the break with GeanyLua 1.22/Geany 1.23.  If
this is an issue (and it can be), I see 2 solutions:

1) remove these 2 calls right now;
2) make GeanyLua 1.22 depend on Geany <= 1.22

What do you think?  I think it can still be done before the release if
needed.

Cheers,
Colomban

BTW, on PR54 I discussed this a little (with myself mostly):
https://github.com/geany/geany-plugins/pull/54



> 
> 
> What do you think?
> 
> 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

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

[Colomban Wendling]

Le 07/07/2012 19:34, Matthew Brush a écrit :
> On 12-07-06 06:25 PM, Lex Trotman wrote:
>> 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.
>>
> 
> Hi,
> 
> Compile with `-DG_FATAL_WARNINGS` and then run in gdb. It'll abort and
> you can see where it happened.

…or run in GDB with G_DEBUG=fatal-warnings envvar set.

Sorry not to have replayed to this mail but it was fixed yesterday on
IRC, leading to GP commit
https://github.com/geany/geany-plugins/commit/b6020c34cb9723a6378a381388f567c45d8c6907

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

Re: [Geany-devel] Treebrowser patch

[Colomban Wendling]

Le 06/07/2012 03:39, Lex Trotman a écrit :
> Frank, Colomban,
> 
> Since you seem to have adopted treebrowser by the latest commits :)

No no, as Frank said we just fixed small general things ;)

> Attached patch makes the show hidden files option work.
> 
> Bug "Tree browser doesn't show hidden files - ID: 3539255"

Hum, actually your patch does the contrary of what it should: it HIDES
each and every file if the config option is checked in.  You meant
`return FALSE` I guess ;)

Otherwise looks OK, I'll try it a little more and see.

Cheers,
Colomban


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

[Geany-devel] Plugins-developers: Please check the NEWS for your plugin

[Colomban Wendling]

Hi dear plugin developers,

As you probably already know, we will make a new geany-plugins release
this week-end, to go with Geany 1.22.

As usual, we need to update the NEWS file on the root geany-plugins
directory to provide a summary of the changes in this new release.  I
already made a first update, but you know better than anybody else what
changed in your plugin and what is worth noting in the NEWS [1].

So, could you please review the 1.22 NEWS and update it as needed for
your plugin?

Thank you,
Colomban


[1] Please only list noteworthy changes, like new features and important
bugfixes.  NEWS should list what the average user cares about, not each
and every changes made to the plugin.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1

[Colomban Wendling]

Le 26/06/2012 19:02, Colomban Wendling a écrit :
> Le 26/06/2012 18:11, Nick Treleaven a écrit :
>> On 25/06/2012 20:33, Dimitar Zhekov wrote:
>>> Hi. Here is a small diff (for makefile.win32 and src/makefile.win32
>>> only) that makes Geany 1.22 Win~1 compilation and installation
>>> independent of MSYS. Usage:
>>>
>>> C>  mingw32-make -f makefile.win32
>>> C>  mingw32-make -f makefile.win32 install
>>>
>>> Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had
>>> to use backslashes in the install: target, and am not sure if/how MSYS
>>> make escapes them. Win~1 fully supports forward slashes internally, but
>>> the command interpreters have only partial support.
>>
>> MSYS does treat backslashes as escapes, and I think that is a worse
>> problem than cmd.exe interpreting forward slashes as command options, as
>> it can occur in more situations. I think we should use forward slashes
>> throughout.
>>
>> Unfortunately I can't get your patch to apply against current Git, but
>> I'm not sure why (see attached file for errors). Can you/someone test if
>> it applies (maybe there's something weird happening on my Windows setup)?
> 
> It applies fine here.  I join the diff from Git after I applied the
> patch in case it helps, maybe your `git apply` will like it better?

... and here's the attachment.

> 
> OT: Nick, could you now merge the tagmanager/ tree rearrangement?
> 
> 
> Regards,
> Colomban
> ___
> Geany-devel mailing list
> Geany-devel@uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

diff --git a/makefile.win32 b/makefile.win32
index a6afe22..d29905a 100644
--- a/makefile.win32
+++ b/makefile.win32
@@ -14,19 +14,18 @@
 WINDRES = windres.exe
 CC = gcc
 CXX = g++
-CP = copy
+MD = mkdir
+CP = copy /Y
 RM = del
-MAKE = make
+MAKE = mingw32-make
 -include localwin32.mk
 
-# Note: && is needed after cd because each line is executed in a different
-# shell. (cd .. is just for clarity).
 all: config.h
-	cd tagmanager/mio && $(MAKE) -f makefile.win32 && cd ../..
-	cd tagmanager && $(MAKE) -f makefile.win32 && cd ..
-	cd scintilla && $(MAKE) -f makefile.win32 && cd ..
-	cd plugins && $(MAKE) -f makefile.win32 && cd ..
-	cd src && $(MAKE) -f makefile.win32 && cd ..
+	$(MAKE) -C tagmanager/mio -f makefile.win32
+	$(MAKE) -C tagmanager -f makefile.win32
+	$(MAKE) -C scintilla -f makefile.win32
+	$(MAKE) -C plugins -f makefile.win32
+	$(MAKE) -C src -f makefile.win32
 
 config.h: win32-config.h
 	$(CP) $< $@
@@ -39,17 +38,25 @@ clean-local:
 	-$(RM) geany_private.res geany.exe
 
 clean: deps
-	cd tagmanager/mio && $(MAKE) -f makefile.win32 clean && cd ../..
-	cd tagmanager && $(MAKE) -f makefile.win32 clean && cd ..
-	cd scintilla && $(MAKE) -f makefile.win32 clean && cd ..
-	cd plugins && $(MAKE) -f makefile.win32 clean && cd ..
-	cd src && $(MAKE) -f makefile.win32 clean && cd ..
+	$(MAKE) -C tagmanager/mio -f makefile.win32 clean
+	$(MAKE) -C tagmanager -f makefile.win32 clean
+	$(MAKE) -C scintilla -f makefile.win32 clean
+	$(MAKE) -C plugins -f makefile.win32 clean
+	$(MAKE) -C src -f makefile.win32 clean
 
 .PHONY: install
-DESTDIR='C:/Program Files/Geany'
+DESTDIR=C:\Program Files\Geany
 
-# requires admin privileges and MSYS
+# requires admin privileges
 install:
-	cp -r data $(DESTDIR)
-	cp plugins/*.dll $(DESTDIR)/lib
-	cp geany.exe $(DESTDIR)/bin
+	-$(MD) "$(DESTDIR)"
+	-$(MD) "$(DESTDIR)\bin"
+	$(CP) geany.exe "$(DESTDIR)\bin"
+	-$(MD) "$(DESTDIR)\lib"
+	$(CP) plugins\*.dll "$(DESTDIR)\lib"
+	-$(MD) "$(DESTDIR)\data"
+	$(CP) data "$(DESTDIR)\data"
+	-$(MD) "$(DESTDIR)\data\colorschemes"
+	$(CP) data\colorschemes "$(DESTDIR)\data\colorschemes"
+	-$(MD) "$(DESTDIR)\data\templates"
+	$(CP) data\templates "$(DESTDIR)\data\templates"
diff --git a/src/makefile.win32 b/src/makefile.win32
index 3929df6..b164cf8 100644
--- a/src/makefile.win32
+++ b/src/makefile.win32
@@ -77,7 +77,7 @@ $(RES): ../geany_private.rc ../icons/geany.ico
 # this calls parent clean-local target because del ../file won't work
 clean:
 	-$(RM) deps.mak *.o
-	cd .. && $(MAKE) -f makefile.win32 clean-local && cd src
+	$(MAKE) -C .. -f makefile.win32 clean-local
 
 exec:
 	$(EXECDIR)\geany.exe
@@ -85,10 +85,10 @@ exec:
 binclean:
 	$(RM) $(TARGET)
 
-$(TARGET): $(OBJS) $(RES) ../scintilla/scintilla.a ../tagmanager/mio/mio.a ../tagmanager/tagmanager.a
-	$(CXX) $(OBJS) $(RES) -o $(TARGET) \
-	../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a \
-	$(ALL_GTK_LIBS) $(WIN_LIBS)
+STLIBS = ../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a
+
+$(TARGET): $(OBJS) $(RES) $(STLIBS)
+	$(CXX) $(OBJS) $(RES) -o $(TARGET) $(STLIBS) $(ALL_GTK_LIBS) $(WIN_LIBS)
 
 deps.mak:
 	$(CC) -MM  $(CFLAGS) *.c >deps.mak
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1

[Colomban Wendling]

Le 26/06/2012 18:11, Nick Treleaven a écrit :
> On 25/06/2012 20:33, Dimitar Zhekov wrote:
>> Hi. Here is a small diff (for makefile.win32 and src/makefile.win32
>> only) that makes Geany 1.22 Win~1 compilation and installation
>> independent of MSYS. Usage:
>>
>> C>  mingw32-make -f makefile.win32
>> C>  mingw32-make -f makefile.win32 install
>>
>> Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had
>> to use backslashes in the install: target, and am not sure if/how MSYS
>> make escapes them. Win~1 fully supports forward slashes internally, but
>> the command interpreters have only partial support.
> 
> MSYS does treat backslashes as escapes, and I think that is a worse
> problem than cmd.exe interpreting forward slashes as command options, as
> it can occur in more situations. I think we should use forward slashes
> throughout.
> 
> Unfortunately I can't get your patch to apply against current Git, but
> I'm not sure why (see attached file for errors). Can you/someone test if
> it applies (maybe there's something weird happening on my Windows setup)?

It applies fine here.  I join the diff from Git after I applied the
patch in case it helps, maybe your `git apply` will like it better?

OT: Nick, could you now merge the tagmanager/ tree rearrangement?


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

Re: [Geany-devel] Does "marker_translucency" work?

[Colomban Wendling]

Le 24/06/2012 23:40, Matthew Brush a écrit :
> Hi,
> 
> I'm writing up some info on colour schemes and through testing it seems
> that "marker_translucency" doesn't do anything. Can anyone test to confirm?
> 
> It says in the manual and filetypes.common file that it's supposed to
> control the translucency of the line markers (first arg) and the search
> indicators (second arg),

Actually it speaks about "the line marker [...] and the search marker",
no indicator here.

> but it seems that the line marker is hardcoded
> to fully opaque and that the search indicator is hardcoded to a fixed
> translucency level (not fully opaque).
> 
> It's entirely possible I'm missing (or misunderstanding) something.

I'd say that the doc is not clear on what this does, but it works
properly.  These values are used for the markers 0 (GCS_MARKER_LINE,
line marker used e.g. when triggering "got tag definition") and 1
(GCS_MARKER_MARK, user marker).

These markers are generally displayed as a symbol in the marker margin
(either an arrow or a plus sign), but are drawn as a line background if
the marker margin isn't visible (View->Editor->Display Marker Margin).
The translucency value is used only when drawing that background (see
Scintilla docs:
http://www.scintilla.org/ScintillaDoc.html#SCI_MARKERSETALPHA).

The search marker (GCS_MARKER_SEARCH, which actually is an indicator)
however has an hard-coded alpha value of 60 (highlighting.c:680.


Maybe changing the docs from:

> Translucency for the line marker (first argument) and the search
> marker (second argument). Values between 0 and 256 are accepted.

to:

> Translucency for the line marker (first argument) and the user
> marker (second argument) when drawn as a line background.  Values
> between 0 and 256 are accepted.

may help.


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

Re: [Geany-devel] [PATCH] Link export plugin against libm (-lm)

[Colomban Wendling]

Le 21/06/2012 10:06, Chow Loong Jin a écrit :
> The export plugin uses the pow() function from libm without linking against
> it. It has worked so far because Geany itself has a link against libm, but
> should that be removed in the future, this would fail to resolve symbols.
> 
> Signed-off-by: Chow Loong Jin 
> ---
>  plugins/Makefile.am |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/plugins/Makefile.am b/plugins/Makefile.am
> index 88a6eba..b0be4e8 100644
> --- a/plugins/Makefile.am
> +++ b/plugins/Makefile.am
> @@ -94,7 +94,7 @@ splitwindow_la_CFLAGS   = -DG_LOG_DOMAIN=\""SplitWindow"\"
>  demoplugin_la_LIBADD= $(GTK_LIBS)
>  classbuilder_la_LIBADD  = $(GTK_LIBS)
>  htmlchars_la_LIBADD = $(GTK_LIBS)
> -export_la_LIBADD= $(GTK_LIBS)
> +export_la_LIBADD= $(GTK_LIBS) -lm
>  saveactions_la_LIBADD   = $(GTK_LIBS)
>  filebrowser_la_LIBADD   = $(GTK_LIBS)
>  splitwindow_la_LIBADD   = $(GTK_LIBS)

Applied, thanks.
___
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!

[Colomban Wendling]

Le 18/06/2012 23:56, Enrico Tröger a écrit :
> On 18/06/12 17:53, Colomban Wendling wrote:
>> We are happy to announce a new release of Geany!
>>
>> For a comprehensive list of changes please see:
>> http://www.geany.org/Documentation/ReleaseNotes
>>
>> Some highlights:
>>
>>  * Rewrite and improve theming support.
>>  * Update Scintilla to 2.29.
>>  * Full PCRE regular expression support for search and replace.
>>  * Add filetype Objective-C (Elias Pschernig).
>>  * Always load the default session if configured to do so.
>>  * Fix detection of raw strings in C and C++.
>>  * Improve support for HTML embedded filetypes.
>>  * Add translations: ar, id, lt, mn, nn, sk.
>>  * Update translations: de, es, fr, hu, it, ja, kk, lt, nl, pl, pt,
>> pt_BR, sk, sl, sv, tr, zh_CN, zh_TW.
>>
>> We want to thank all developers, translators and everyone who
>> contributed to this release with patches, feedback, bug reports and so
>> on.  Thank you!
>>
>> As usual, all downloads can be found on http://download.geany.org/.
> 
> 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/.

Great, thanks a lot!

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

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

[Colomban Wendling]

We are happy to announce a new release of Geany!

For a comprehensive list of changes please see:
http://www.geany.org/Documentation/ReleaseNotes

Some highlights:

 * Rewrite and improve theming support.
 * Update Scintilla to 2.29.
 * Full PCRE regular expression support for search and replace.
 * Add filetype Objective-C (Elias Pschernig).
 * Always load the default session if configured to do so.
 * Fix detection of raw strings in C and C++.
 * Improve support for HTML embedded filetypes.
 * Add translations: ar, id, lt, mn, nn, sk.
 * Update translations: de, es, fr, hu, it, ja, kk, lt, nl, pl, pt,
pt_BR, sk, sl, sv, tr, zh_CN, zh_TW.

We want to thank all developers, translators and everyone who
contributed to this release with patches, feedback, bug reports and so
on.  Thank you!

As usual, all downloads can be found on http://download.geany.org/.


Version number changed
--

No, don't worry, 1.22 is not a typo.  Many users told us our version
numbers didn't reflect the maturity of Geany to their eyes, and wished
it to be changed to reflect that.  So after some discussion we decided
to rename this version 1.22 instead of 0.22.


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

[Geany-devel] About ChangeLog, AUTHORS and COMMITTERS files

[Colomban Wendling]

Hi guys,

I updated the build system to generate a ChangeLog from Git's log upon
dist.  I mostly used the suggestion at
https://live.gnome.org/Git/ChangeLog and it works fine.  The format is a
bit weird for a ChangeLog, but it's complete and quite clear.  And
output a ChangeLog-style format is way harder, and seem to somewhat
require an extra script parsing stuff, which is IMO quite overkill.

So, the ChangeLog is ok.  However, Matthew and I discussed a bit some
time ago about generating AUTHORS and COMMITTERS alike, see
https://github.com/geany/geany/pull/10

Although this seems to be a quite good idea, there may be a few
problems.  Generating AUTHORS is quite easy.  It of course wouldn't keep
the "developers" vs. "contributers" distinction, but the list could e.g.
be sorted by amount of commits, so somewhat by importance.

The problem comes with COMMITTERS.  Although it's quite easy to list all
the people having committed a commit that's in geany.git's master, this
list will also include the people having committed something that later
got merged.  And then COMMITTERS becomes quite useless since it doesn't
reflect the reality.

So, is there a way to only list people having committed directly to
master, e.g. not in a branch first?  If yes, it could be a solution.  I
would possibly remove quite a bit of actually relevant commits, but it's
also likely that if a committer was legitimate it would also have
committed something straight to master (even a merge of his branch).

And if the answer to the above question is "no", what do you think is
the best?  Just keep the hand-made AUTHORS and COMMITTERS?
Auto-generate AUTHORS and keep the hand-made COMMITTERS?  Something else?

If we have a solution before tomorrow evening we could have it in 1.22,
otherwise it'll be as it is now in that release (not a big deal IMO).


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

Re: [Geany-devel] tagmanager changes - tree refactoring

[Colomban Wendling]

Le 07/06/2012 17:59, Nick Treleaven a écrit :
> On 06/06/2012 15:42, Nick Treleaven wrote:
>>> OK, I tried building it and found some fixes are necessary for the
>>> Windows makefiles - I'll commit these to a branch. After those changes,
>>> it seems to build fine.
>>
>> Now pushed to:
>> https://github.com/ntrel/geany/commits/tm/tree-refactoring
>>
>>  > Thanks for doing this, the structure is much better than before.
>>  > However, the build changes are quite substantial, so I think it
>> might be
>>  > best not to include them in the 1.22 release in case it introduces any
>>  > problems.
>>  >
>>  > Also, I found the problem with suppressed gcc warnings in tagmanager
>>  > code - it was the hardcoded -w switch (which I read as -W)!

Oh great, tricky to find out!

>>  > Unfortunately this commit will conflict with the tree refactoring. I
>>  > will try to resolve the conflicts so we can merge the branch, perhaps
>>  > after the 1.22 release?
>>
>> I also have a ctags/c.c fix I'd like to include in the release, so
>> please let me know whether to delay it until merging this branch,
>> although as I said, it might be better to leave this out of the release.
>> I'm still happy to try to fix the conflicts myself, even if we do delay
>> the merge.
> 
> I've now merged in master to my branch, same URL - surprisingly git
> didn't report any conflicts, I think because it recognizes moved files,
> even when there is some changed content, e.g. tagmanager/makefile.win32
> -> tagmanager/ctags/makefile.win32. So all I had to do was make my CFLAG
> changes to the new file tagmanager/src/makefile.win32.
> 
> I don't mind if you want to merge my branch before the release, I just
> wanted to raise the issue. Or shall I merge it now?

No you're right, it's quite large and maybe have hidden problems
(although I doubt so but only testing will show off), after the release
is better. And it's not something users mind about, so they won't notice
either way anyway.

So just push your fix to current master and we will merge the branch
after the release.  As you said, Git seems to be clever enough to deal
with the renames anyway so it shouldn't cause too much trouble merging
later anyway.

And thanks for the tests and fixes :)

Regards,
Colomban
___
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

[Colomban Wendling]

Le 02/06/2012 13:16, Lex Trotman a écrit :
> On 2 June 2012 20:58, Colomban Wendling  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.

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

>> 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.

>> 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.

>> [...]
>>
>>
>> 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.

Fixed, now we only hide info, debug and message log entries.

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

[Geany-devel] GLib 2.32 and debug messages

[Colomban Wendling]

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].

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(...`)

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


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?
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 08/05/2012 23:04, Colomban Wendling a écrit :
> Le 08/05/2012 14:12, Colomban Wendling a écrit :
>> Le 30/04/2012 19:07, Nick Treleaven a écrit :
>>> On 29/04/2012 15:47, Colomban Wendling wrote:
>>>> Le 26/04/2012 18:53, Nick Treleaven a écrit :
>>>>> On 26/04/2012 16:02, Nick Treleaven wrote:
>>>>>> On 24/04/2012 22:31, Colomban Wendling wrote:
>>>>>>> * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
>>>>>
>>>>> BTW this is a good idea to clearly separate CTags from tagmanager. If
>>>>> this change can be applied separately, perhaps it could be merged into
>>>>> master.
>>>>
>>>> It should be quite easy -- though it won't still be a vanilla CTags of
>>>> course, my own isn't either (yet?).
>>>
>>> I just thought it was a separate change from the TM rewrite.
>>
>> It could very well be I think, basically it only changes the directory
>> structure a little.  I'll try to replicate this on TM.
> 
> Here we go: https://github.com/b4n/geany/commits/tm/tree-refactoring
> Looks reasonable?
> 
> The Autotools and Waf build systems should be OK (tested & running), but
> I haven't tested the makefile.win32s; so if somebody could check them
> it'd be awesome.

Nick, could you test this?  This change should be harmless apart maybe
the makefiles.win32 update, so before pushing it it'd be good if
somebody could test and see if it builds OK.

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

Re: [Geany-devel] Geany multicursors patch

[Colomban Wendling]

Le 23/05/2012 21:19, Davide Andreoli a écrit :
> [...]
> 
> Ok, I also finished the snippets part, super-easy at the end :)
> you can find my new 'supersnip' branch at:
> https://github.com/DaveMDS/geany/tree/supersnip
> also included the multicursor 3 lines (needed)
> 
> Here you can read the description, one example and
> the commit diff for the "super snippets" patch:
> https://github.com/DaveMDS/geany/commit/c7035d58f2b8b50df96e9cd9fbf6f9e73ec2ce74
> 
> I think also this one is small enough for the core...29 lines :)
> 
> [...]

No review yet but a small test: it looks pretty good, but it has a bug:
when no %wordN% is defined but there is a %cursor%, a second selection
is created at the very position of the cursor.

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

Re: [Geany-devel] Geany multicursors patch

[Colomban Wendling]

Le 23/05/2012 21:19, Davide Andreoli a écrit :
> 2012/5/23 Lex Trotman :
>> [...]
>>
>> 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.
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).

*) 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.

*) 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.


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

Re: [Geany-devel] Incompatible UI change, removal of actions from ctrl-click

[Colomban Wendling]

Hi,

Le 24/05/2012 03:27, Lex Trotman a écrit :
> [posted to both devel and user lists, sorry to those on both]
> 
> Hi All,
> 
> Geany currently hard codes two actions to the -
> input, "goto tag" if the click is over an identifier or "goto matching
> brace" otherwise.
> 
> This blocks the standard action of "add to selection" on - click> and -.  (See Gnome HIG
> http://developer.gnome.org/hig-book/2.32/hig-book.html#input-mouse
> 10.1.2)
> 
> I did a quick check on my system and didn't find any application that
> did not comply with that guideline, so Geany is the odd one out.
> 
> Geany has not supported multiple selections so it hasn't been an issue
> (other than being non-standard and occasionally confusing users), but
> as there is a proposal to add support for multiple selections to Geany
> this non-standard behavior is now a problem.
> 
> As both actions now have a default keybinding (in Git version) I
> propose that the binding to - simply be
> removed.

Your arguments looks sensible to me, as does the ones from Dimitar in
the other thread (that this Ctrl-LMB has too many things bound to it).
Of course it'd be better if we had configurable mouse bindings, but
that's another story.

I also think that if we want to keep a mouse binding for "go to tag", we
could choose something less common -- Ctrl+Alt, Super, whatever uncommon
modifier.  Do we want to keep one?

Finally, although it's probably obvious, the multi-select feature should
have a keybinding.


Regards,
Colomban


PS: funny thing, I just discovered that Mozilla apps did support
multi-selection :)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany multicursors patch

[Colomban Wendling]

Hi,

Le 22/05/2012 20:40, Davide Andreoli a écrit :
> 2012/5/21 Dimitar Zhekov  >
> 
>> [...]
>> 
>>> 3. is there a way to really show multiple carets?
>>
>> No easy way AFAIK.
> 
> 
> hey! you are wrong :P
> 
> I found the easy way (that also solve the issue 2). I just enabled
> scintilla
> multiple selections ! in fact scintilla is able to do exactly what I was
> searching for :)
> (thank go to elextr that point me to the right direction in IRC)
> 
> ...and now the patch is just a 3 liner:
> 
> +++ b/src/editor.c
> @@ -4677,6 +4677,11 @@ static ScintillaObject
> *create_new_sci(GeanyEditor *editor)
>  /* virtual space */
>  SSM(sci, SCI_SETVIRTUALSPACEOPTIONS,
> editor_prefs.show_virtual_space, 0);
> 
> +/* multiple selection */
> +SSM(sci, SCI_SETMULTIPLESELECTION, 1, 0);
> +SSM(sci, SCI_SETADDITIONALSELECTIONTYPING, 1, 0);
> +SSM(sci, SCI_SETRECTANGULARSELECTIONMODIFIER, SCMOD_SUPER, 0);
> 
> 
> [...]

I was about to dig into the Scintilla doc to check whether that
functionality did already exist when I started reading the thread, but I
see you and Lex already found out it did :)

This is a lot better than the initial implementation and looks like an
awesome feature :)

> [...]
> 
>>> note: this is my first geany patch... plese be kind :P

Hey, welcome to the dark side of the force^W application then! :)

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

Re: [Geany-devel] geany-plugins: Autotools usage

[Colomban Wendling]

Sorry for the delay, I completely missed this mail.

Le 22/04/2012 20:14, Chow Loong Jin a écrit :
>   [...]
> 
> - "FIXME: CSS?" doesn't look like it's needed in geanygendoc -- there's a rule
>   to generate manual.html from manual.rst and manual.css. (This probably
>   shouldn't be dist'd, but Colomban would probably be in a better position to
>   answer that)

Actually there is a bug in the current build system, because the
html4css1 stylesheet should either be distributed or embedded, which
isn't currently the case.

Attached are a few patches updating the build system to properly embed
both stylesheets, and a few other updates.  I didn't commit them/made a
PR yet because #2 is likely to conflict.


Regards,
Colomban
>From b7c07dc512616b196d2705c4426d4e3c84285673 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Sat, 19 May 2012 16:59:36 +0200
Subject: [PATCH 1/3] geanygendoc: Update base stylesheet from docutils 0.8.1

---
 geanygendoc/docs/html4css1.css |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/geanygendoc/docs/html4css1.css b/geanygendoc/docs/html4css1.css
index 030cf17..8160506 100644
--- a/geanygendoc/docs/html4css1.css
+++ b/geanygendoc/docs/html4css1.css
@@ -1,6 +1,6 @@
 /*
 :Author: David Goodger (good...@python.org)
-:Id: $Id: html4css1.css 5951 2009-05-18 18:03:10Z milde $
+:Id: $Id: html4css1.css 7056 2011-06-17 10:50:48Z milde $
 :Copyright: This stylesheet has been placed in the public domain.
 
 Default cascading style sheet for the HTML output of Docutils.
@@ -38,6 +38,10 @@ blockquote.epigraph {
 dl.docutils dd {
   margin-bottom: 0.5em }
 
+object[type="image/svg+xml"], object[type="application/x-shockwave-flash"] {
+  overflow: hidden;
+}
+
 /* Uncomment (and remove this text!) to get bold-faced definition list terms
 dl.docutils dt {
   font-weight: bold }
@@ -148,16 +152,22 @@ h2.subtitle {
 hr.docutils {
   width: 75% }
 
-img.align-left, .figure.align-left{
+img.align-left, .figure.align-left, object.align-left {
   clear: left ;
   float: left ;
   margin-right: 1em }
 
-img.align-right, .figure.align-right {
+img.align-right, .figure.align-right, object.align-right {
   clear: right ;
   float: right ;
   margin-left: 1em }
 
+img.align-center, .figure.align-center, object.align-center {
+  display: block;
+  margin-left: auto;
+  margin-right: auto;
+}
+
 .align-left {
   text-align: left }
 
@@ -170,7 +180,7 @@ img.align-right, .figure.align-right {
 
 /* reset inner alignment in figures */
 div.align-right {
-  text-align: left }
+  text-align: inherit }
 
 /* div.align-center * { */
 /*   text-align: left } */
@@ -230,7 +240,7 @@ pre.address {
   margin-top: 0 ;
   font: inherit }
 
-pre.literal-block, pre.doctest-block {
+pre.literal-block, pre.doctest-block, pre.math {
   margin-left: 2em ;
   margin-right: 2em }
 
-- 
1.7.10

>From bdb96bf7a24c3c54c6dda53921a8cb0550cd0ddd Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Sat, 19 May 2012 17:01:23 +0200
Subject: [PATCH 2/3] geanygendoc: Embed base stylesheet

Don't import the base CSS stylesheet from the custom one but rather
embed both in the output HTML.
---
 geanygendoc/docs/Makefile.am |4 ++--
 geanygendoc/docs/manual.css  |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/geanygendoc/docs/Makefile.am b/geanygendoc/docs/Makefile.am
index 02df8ce..57d273d 100644
--- a/geanygendoc/docs/Makefile.am
+++ b/geanygendoc/docs/Makefile.am
@@ -14,7 +14,7 @@ plugindoc_DATA = manual.rst
 pluginhtmldoc_DATA = manual.html
 
 if BUILD_RST
-manual.html: manual.rst manual.css
-	$(AM_V_GEN) $(RST2HTML) -d --strict --stylesheet-path manual.css $< $@
+manual.html: manual.rst manual.css html4css1.css
+	$(AM_V_GEN) $(RST2HTML) -d --strict --stylesheet-path html4css1.css,manual.css $< $@
 endif BUILD_RST
 endif ENABLE_GEANYGENDOC
diff --git a/geanygendoc/docs/manual.css b/geanygendoc/docs/manual.css
index 4eff7f9..afb527e 100644
--- a/geanygendoc/docs/manual.css
+++ b/geanygendoc/docs/manual.css
@@ -6,7 +6,7 @@
 Stylesheet for use with Docutils.
 */
 
-@import url(html4css1.css);
+/*@import url(html4css1.css);*/
 
 html {
 	background-color: #ec;
-- 
1.7.10

>From 54445e987fe07e2d43968bfb97e7889b68731041 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Sat, 19 May 2012 17:03:04 +0200
Subject: [PATCH 3/3] geanygendoc: Update generated manual

---
 geanygendoc/docs/manual.html |  313 +-
 1 file changed, 310 insertions(+), 3 deletions(-)

diff --git a/geanygendoc/docs/manual.html b/geanygendoc/docs/manual.html
index c411ef8..91c202f 100644
--- a/geanygendoc/docs/manual.html
+++ b/geanygendoc/docs/manual.html
@@ -3,11 +3,318 @@
 http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
 
 
-http://docutils.sourceforge.net/"; />
+http://docutils.sourceforge.net/&

Re: [Geany-devel] gtk_separator_tool_item_new() patch

[Colomban Wendling]

Hi,

Le 29/04/2012 20:26, Dimitar Zhekov a écrit :
> Hi again, and excuse me for stuffing the list.
> 
> Actually there is 1/2 error. The plugin toolbar items are inserted
> improperly, but added to plugin_items list in the right order. So
> using "Customize Toolbar" and adding/removing items or otherwise
> changing them fixes the order.
> 
> Patch attached. Not in git format, sorry.

If I read the thing correctly, the patch is wrong because it would
possibly mixup tool items from different plugins if they aren't added at
the same time, wouldn't it?

But you're right that there is a problem.  Currently, it creates:

| Plugin_1_Item_2 Plugin_1_Item_1 | Plugin_2_Item_1 | Quit

and should create

| Plugin_1_Item_1 Plugin_1_Item_2 | Plugin_2_Item_1 | Quit

However with your patch, if plugins are added in the order
Plugin_1_Item_1, Plugin_2_Item_1, Plugin_1_Item_2, it would give:

| Plugin_1_Item_1 | Plugin_2_Item_1 Plugin_1_Item_2 | Quit

Which is also wrong (more wrong if I could say).


Getting that right seems a bit harder and would need to be able to know
what's the last item added by a given plugin.  Maybe tagging the widget
with the plugin it belongs to, and then search for the first
non-matching one would do the trick:

def get_insert_position(plugin):
pos = toolbar.get_default_insert_pos()

if plugin.autosep:
# find the last item belonging to @plugin
while pos < toolbar.get_n_items():
item = toolbar.get_item(pos)
if item.get_data("plugin") != plugin:
break

return pos

def add_item(plugin, item):
pos = get_insert_pos(plugin)

if not plugin.autosep:
plugin.autosep = create_sep()
toolbar.insert(plugin.autosep, pos)
pos += 1

item.set_data("plugin", plugin)
toolbar.insert(item, pos)

Maintaining an index don't seem really a good idea since it would be one
another thing to keep, and I don't think that adding a tool item is a
performance-critical thing so the possible overhead finding the position
(if there is already an item) should not be a problem.

Thoughts?

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

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 08/05/2012 14:12, Colomban Wendling a écrit :
> Le 30/04/2012 19:07, Nick Treleaven a écrit :
>> On 29/04/2012 15:47, Colomban Wendling wrote:
>>> Le 26/04/2012 18:53, Nick Treleaven a écrit :
>>>> On 26/04/2012 16:02, Nick Treleaven wrote:
>>>>> On 24/04/2012 22:31, Colomban Wendling wrote:
>>>>>> * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
>>>>
>>>> BTW this is a good idea to clearly separate CTags from tagmanager. If
>>>> this change can be applied separately, perhaps it could be merged into
>>>> master.
>>>
>>> It should be quite easy -- though it won't still be a vanilla CTags of
>>> course, my own isn't either (yet?).
>>
>> I just thought it was a separate change from the TM rewrite.
> 
> It could very well be I think, basically it only changes the directory
> structure a little.  I'll try to replicate this on TM.

Here we go: https://github.com/b4n/geany/commits/tm/tree-refactoring
Looks reasonable?

The Autotools and Waf build systems should be OK (tested & running), but
I haven't tested the makefile.win32s; so if somebody could check them
it'd be awesome.

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

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 30/04/2012 18:54, Nick Treleaven a écrit :
> On 29/04/2012 15:42, Colomban Wendling wrote:
>>>> * it support asynchronous parsing (though not concurrent parsing);
>>>
>>> What's the difference? Also, what does it buy us?
>>
>> What I meant when saying it's asynchronous but not concurrent is that it
>> supports launching the parsers in a separate thread, but it cannot
>> launch several parsers at once.  This is because CTags parsers aren't
>> thread-safe (have a lot of global states and no locks).
>>
>> What asynchronous parsing gives us is quite simple: no blocking.  This
>> means that a slow parser (like e.g. the HTML one on Windows before you
>> changed the regex library) wouldn't lock Geany.  Same for project
>> plugins that want to parse thousands of files:  this would still take a
>> long time, but Geany would be still usable in the meantime.
> 
> Ok. It seems a good idea to support this, but for parsing tags in open
> documents it doesn't seem particularly useful, as this ought to be fast.
> The regex problem was unusual IMO and due to an old version of GNU regex.

Right, though a really big file could also be "slow" to parse.

>> BTW, how does TagManager do fast searches?  I always though it did a
>> sorting with new attributes each time they changed, so in such
>> situations it's even worse than O(n), isn't it?
> 
> For searching, it doesn't do any sorting ever. For adding tags the work
> object (i.e. document tags) have to be sorted, which I think is good,
> but also the workspace tags are currently resorted, which I think may be
> a bad design.

If it is never resorted, it means ALL lookups are done on the same
criteria: the name.  Right?  If so, how could scope completion be fast?
 It requires a lot of different search:

1) name search for finding the type of the element to complete;
2) type search for resolving possible typedefs (recursively);
3) scope search for getting the actual results.

Or do I miss something again?

>>>> - 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?
>>
>> Well, adding a tag would require a bsearch() on each cache, yes.
>> However, adding tags is mostly done in a separate thread (if async
>> parsing it used), so it can be less of a problem.
> 
> I haven't studied your design, but I would prefer that any design is
> efficient on all threads, so the user's computer can use remaining
> performance for compiling & whatever else they want.

Yeah of course.  One possible simple improvement would be to merge only
when all tags got parsed, getting something like you did earlier with
the patch on TM global tags loading.

But yes, it would still require insertions in multiple caches; but I
though it was worth it since it provided fast search for all caches (see
above for why I though/thinks multiple cache are useful).

> Also, what about global tags? Those can add a lot of tags all at once.

I didn't tried to deal with them yet, but I naively reproduced something
like in TM, e.g. another array (cache(s)) for them, so they shouldn't
make the whole think much slower.  However I'm not certain that having a
completely separate array is really good for searching, but again, I
just replicated the TM design here.

And again, I must admin I didn't actually implemented this for real yet
anyway, so I can't really tell.

>> And a search is simply a bsearch() (O(n log n), right?) given the cache
>> already exists.  If the cache doesn't exist, it has to be created so
>> yeah on the first search it's slow.
> 
> If it can be slow enough for the user to notice this is probably bad.

As said in another mail, if it's a problem the required caches can be
hard-coded so they are created anyway.  I doesn't seem a clean thing to
me, but that's very well doable.

>> It's not strictly needed, but it makes some memory management easier,
>> and fits well with GTK memory management.  And this last point helps a
>> lot to maintain the GtkTreeStore on src/symbols.c, now tags are updated
>> and not removed.
>> But that's not new, I already added this in TM.
> 
> Yes. Is the reason the tree should be updated and not recreated to
> preserve fold states and scrollbar position? In fact

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 08/05/2012 02:03, Lex Trotman a écrit :
> On 8 May 2012 02:04, Nick Treleaven  wrote:
>> [...]
>>
>> 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 :)

Agreed at 100%!  If we could cut down TM to remove the code that's
actually not used (or not useful for us) would certainly help a lot to
towards making it easier to understand.  (BTW I think I remember
something about Jiří having done something like it a long time ago)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 02/05/2012 06:46, Lex Trotman a écrit :
> [...]
> 
> 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?

Well, yes, the UI thread gets the load (unless there is background/async
lookups too :)).  However in my approach there can be any number of
caches [1], and those caches can't really be guessed, so... but maybe
it's simply a bad approach.  Or the used caches could be hard-coded in
CTM so they never get created implicitly -- quite ugly but works).

[1] cache means:  a array of tags sorted by a given sort function.  Each
cache is then used for a particular type of lookups:
* simple completions (sort by name);
* scope completion (uses more than one cache, sorted by scope and name,
and sorted by type);
* etc. (I think there is a third one we use somewhere, can't remenber
what though)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

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?)

>> - 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.
> 
>> difference between source_file and file_entry?
> 
> It doesn't look like tm_file_entry_ is really used.
> 
>>
>> - 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 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?
> 
> no
> 
>>
>> - 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.
> 
> 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.
> 
> 
>> 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
> 
>>
>> 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.
> 
>> 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. 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.

Well, what symbols.c tries to do when updating the symbols tree is (as
documen

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 30/04/2012 19:07, Nick Treleaven a écrit :
> On 29/04/2012 15:47, Colomban Wendling wrote:
>> Le 26/04/2012 18:53, Nick Treleaven a écrit :
>>> On 26/04/2012 16:02, Nick Treleaven wrote:
>>>> On 24/04/2012 22:31, Colomban Wendling wrote:
>>>>> * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
>>>
>>> BTW this is a good idea to clearly separate CTags from tagmanager. If
>>> this change can be applied separately, perhaps it could be merged into
>>> master.
>>
>> It should be quite easy -- though it won't still be a vanilla CTags of
>> course, my own isn't either (yet?).
> 
> I just thought it was a separate change from the TM rewrite.

It could very well be I think, basically it only changes the directory
structure a little.  I'll try to replicate this on TM.

> We have a lot of changes from CTags e.g. new languages and improvements
> to existing parsers (and even CTags itself) which IMO we can't throw away.
> 
> It is possible to merge some changes from CTags but for e.g. c.c this
> has become pretty difficult. I tried this once but it ended up breaking
> the parser and I didn't work out why.
> 
> IMO the biggest issue with CTags is that it isn't really maintained and
> they rarely accept patches even when it fixes an important bug (e.g. a
> fix to regex callback parsing with ignored matches).

Yes, we can't use stock CTags everywhere.  Because we have some changes
that aren't applied upstream, and then merging would be a mess (sadly).
 And a bit also because TM changes a few things in a few CTags files to
"plug" into it -- necessary unless the parsing is done by calling the
ctags executable; which isn't necessarily better.

>>>> For avoiding resorting of workspace tags when only reparsing one source
>>>> object, we can remove the source object's old tags&  merge the new
>>>> tags.
>>>> This is all O(n) for the workspace array. I haven't looked into
>>>> implementing this yet because now it's clear you're working on a
>>>> competing change.
>>>
>>> Another option is to remove the workspace array altogether and just have
>>> Geany collate tags from each (sorted) source object when needed. Not
>>> sure the implications of this yet but it would simplify tagmanager.
>>
>> Well, tagmanager needs to know all tags to perform e.g. scope completion
>> beyond file's boundaries.  And for search too, it would need us to pass
>> it everything, or to perform a search on each document's tags and then
>> merge the result.  Doesn't sound sensible at a first glance, but maybe
>> I'm missing something.
> 
> It comes to a trade off between merging/sorting results from multiple
> tag arrays and merging/sorting the whole workspace array even when only
> one document is reparsed.
> 
> Actually I suppose the first one can cause lags which the user could
> notice if there are a lot of results, whereas the second one only causes
> problems on reparsing, which is less often than searching.

(unless real-time tag parsing is enabled)

> I'm undecided. The second one can be more serious if the calling code
> doesn't handle e.g. save all specially and the workspace array size is
> quite big. The special handling is to not update the workspace array
> until all documents have been parsed, then to resort it. If it's only
> save all, we can cope, but there may be other ways this can happen.

If TM (could) have an API for that it'd be fine, but I don't think it's
a really good idea if it becomes a hack.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 29/04/2012 14:07, Nick Treleaven a écrit :
> On 27/04/2012 06:30, Lex Trotman wrote:
>> [...]
>>>
>>> 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.
> 
>> 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.
> 
> I don't see this myself, I see some complicating issues which could be
> resolved (and I'm willing to work on them), but generally a sound design
> for what it provides and for extra things we may want to add.
> 
>> 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.
> 
> Isn't it clear from the data structures? Look at TMWorkspace. Scopes and
> other tag metadata is the same as CTags. Obviously if we had at-a-glance
> overall documentation that would be good.

What I personally blame TM for is not the data structure or overall
design, but the code.  I can't get my head around the implementation.
Every time I try to get it, I get a headache and generally no fix :(

But maybe I'm just plain stupid, or maybe I just miss one or two key
things of how it's written to get it.

> One confusing thing is that a TMTag can be used for an actual tag or for
> a file. Probably that could be cleaned up.

Agreed, that's something I think that should be quite easy to "fix" and
that would make the thing easier to understand at first (though it's not
one of the things that makes me not understand TM ;)).  BTW, do we
actually use any file tags?

- 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.
> 
> I expect the design is better in some respects (and to be fair I didn't
> look for better things), but finding a tag based on its name is
> something we are always going to want to be fast. Even for scope
> completion, you still need to lookup a tag structure from a name string.
> So I think we will always want a sorted array of tags per document that
> we can bsearch (or something equally fast).
> 
> Also, I've probably sounded quite harsh on Colomban's design, but I'm
> commenting on what I think is important. I am genuinely interested in
> why his design decisions are better. It's a lot to take in all at once,
> so probably needs some explanation. Sorry if I didn't make that clear.

Don't worry about sounding harsh or something, I totally agree that
changing for changing is not a good idea.  To be honest, there were
really two reasons why I tried to write a new tagmanager on the first place:

1) because I wasn't able to fix the current one;
2) to support asynchronous parsing.

And actually I haven't added much great design, it actually works quite
the same as does TM currently -- per-file tags, a workspace holding a
merge of all tags.

> [...]
> 
 * 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 looked at the thread about that, and from what I could tell, the
> problem was for reparsing unsaved files. Wasn't the order OK for files
> that have just been saved? (Also I don't follow what that has to do with
> reference counting).

We don't parse unsaved files at all because TM can't do that.  And
that's once another thing that should be fixed.

However I don't get the point you're talking about, maybe my answer is
OT then.


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

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 27/04/2012 07:30, Lex Trotman a écrit :
> [...]
>>>   - 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.

Not at all, sorry :)
It's only for performance, so search on different criteria can remain
fast (just a bsearch()).

> 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.

To really support such thing would require the parsers to provide a true
tree, not a flat thing.  However, my scope completion "algorithm" takes
into account a few things to try to find The Right Thing™:

1) the file in which the tag appears (e.g. tries to resolve things
locally first);
2) the "distance" in lines between the tags (e.g. the tag that comes
just before the one to complete has precedence over another one).

but this wouldn't be enough to get correct results with your example; it
would really need a tree.


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

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 26/04/2012 18:53, Nick Treleaven a écrit :
> On 26/04/2012 16:02, Nick Treleaven wrote:
>> On 24/04/2012 22:31, Colomban Wendling wrote:
>>> * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
> 
> BTW this is a good idea to clearly separate CTags from tagmanager. If
> this change can be applied separately, perhaps it could be merged into
> master.

It should be quite easy -- though it won't still be a vanilla CTags of
course, my own isn't either (yet?).

>> For avoiding resorting of workspace tags when only reparsing one source
>> object, we can remove the source object's old tags & merge the new tags.
>> This is all O(n) for the workspace array. I haven't looked into
>> implementing this yet because now it's clear you're working on a
>> competing change.
> 
> Another option is to remove the workspace array altogether and just have
> Geany collate tags from each (sorted) source object when needed. Not
> sure the implications of this yet but it would simplify tagmanager.

Well, tagmanager needs to know all tags to perform e.g. scope completion
beyond file's boundaries.  And for search too, it would need us to pass
it everything, or to perform a search on each document's tags and then
merge the result.  Doesn't sound sensible at a first glance, but maybe
I'm missing something.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Hi,

Le 26/04/2012 17:02, Nick Treleaven a écrit :
> On 24/04/2012 22:31, Colomban Wendling wrote:
>> Le 17/04/2012 18:20, Nick Treleaven a écrit :
>> Sorry for the long delays -- and also small activity -- recently.  I
>> have/had a lot of non-Geany stuff to do and stuff, the whole story, you
>> know.
> 
> No problem.
> 
>> I finally committed it and pushed it so you can see it, comment, blame,
>> flame&  more:  see https://github.com/b4n/geany/tree/wip%2Fctagsmanager
>>
>> A few points, as they comes to my mind:
>>
>> * it support asynchronous parsing (though not concurrent parsing);
> 
> What's the difference? Also, what does it buy us?

What I meant when saying it's asynchronous but not concurrent is that it
supports launching the parsers in a separate thread, but it cannot
launch several parsers at once.  This is because CTags parsers aren't
thread-safe (have a lot of global states and no locks).

What asynchronous parsing gives us is quite simple: no blocking.  This
means that a slow parser (like e.g. the HTML one on Windows before you
changed the regex library) wouldn't lock Geany.  Same for project
plugins that want to parse thousands of files:  this would still take a
long time, but Geany would be still usable in the meantime.

>> * it is under the new ctagsmanager/ directory;
>> * it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
>> * all types have different names than the tagmanager ones, though
>>currently the API is almost an 1:1 mapping -- and that's maybe a
>>huge mistake?;
> 
> 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.

I think Lex and Matthew probably summarize it quite correctly:  it's not
that TM is bad or has to be replaced; it is that (I'm) unable to
understand it enough to fix anything in it, like scope completion.
Maybe it's only me, but I tried hard :)

And the only reason why maybe TagManager would need replacement/large
changes is asynchronous parsing.  I'm not sure how hard it would be to
get it with TM -- but again, maybe it's only that I don't understand it
enough.

>> * there is 2 backends as of today:
>>- a "simple" one that is simple and that doesn't waste (too much)
>>  memory, but that searches in O(n);
> 
> Linear searching seems like a bad idea when we currently have O(log n).
> Removing x tags is O(n * x) by the look of it.

I agree it's not interesting regarding performances, and this backend
isn't meant for it.  I needed an implementation for early testing, so I
wrote it simple.  And it showed useful for testing later on too, since
because of it's simplicity it isn't bugged -- just slow :)

BTW, how does TagManager do fast searches?  I always though it did a
sorting with new attributes each time they changed, so in such
situations it's even worse than O(n), isn't it?

>>- 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?

Well, adding a tag would require a bsearch() on each cache, yes.
However, adding tags is mostly done in a separate thread (if async
parsing it used), so it can be less of a problem.

And a search is simply a bsearch() (O(n log n), right?) given the cache
already exists.  If the cache doesn't exist, it has to be created so
yeah on the first search it's slow.

> 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.

Multiple backends isn't really useful probably.  As said above, the
first was mostly a testing one, and I wanted to be able to keep both
during development for better testing.  At one point I also thou

Re: [Geany-devel] tagmanager changes

[Colomban Wendling]

Le 17/04/2012 18:20, Nick Treleaven a écrit :
> Hi,
> How's it going?

Hi,

Sorry for the long delays -- and also small activity -- recently.  I
have/had a lot of non-Geany stuff to do and stuff, the whole story, you
know.

> Lex mentioned in this mail:
> http://lists.uvena.de/pipermail/geany/2012-April/007991.html
> 
> that (according to him) you are working to 'replace it'. Maybe he's
> exaggerating, but this sounds interesting. If you have time could you
> maybe send me a link to the IRC log, or better, explain a little about
> the work on the devel list?

That's true, I have a WIP on writing a new ctags management code.  It is
far from being ready for production, and I'm not even sure the ideas in
it are really appropriate.  But yes, there is a something :)

I finally committed it and pushed it so you can see it, comment, blame,
flame & more:  see https://github.com/b4n/geany/tree/wip%2Fctagsmanager

A few points, as they comes to my mind:

* it is under the new ctagsmanager/ directory;
* it uses the same tag parsers tagmanager used, in ctagsmanager/ctags;
* it support asynchronous parsing (though not concurrent parsing);
* all types have different names than the tagmanager ones, though
  currently the API is almost an 1:1 mapping -- and that's maybe a
  huge mistake?;
* there is 2 backends as of today:
  - a "simple" one that is simple and that doesn't waste (too much)
memory, but that searches in O(n);
  - 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.

  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?;
* tags (and most types) are reference-counted (so they aren't
  necessarily duplicated, e.g. in the multicache backend);
* tag matching/finding is done using ctm_data_backend_find() (or a
  convenience wrapper), which takes 2 functions for performing the
  search:
  - a sort function, used to, heh, sort the tags to search and/or the
resulting list (the "simple" backend should use it to sort the
result; and the "multi-cache" backend uses it to sort the caches)
  - a match function, use to check whether a tag should be included in
the results.  Like the sort function it returns a strcmp()-like
value, with the only difference that it probably returns 0 for more
tags.

  It is somewhat similar to what tagmanager did, but it's more flexible
  -- and maybe complex, though many sort/match functions would already
  be provided.

* no pruning is done yet, so there is duplicate in the results;
* there is an (almost) working scope completeion implementation;
* ... I don't see anything to add, so I'll stop here :)

All this isn't of course written in stone: if we already redo a lot of
things, let's get something nice -- though IMO we'll always be better
than with tagmanager, since each time I wanted to touch it it took me
hours, and sometimes I even haven't been able to fix the problem
(thinking of e.g. scope completion...).

> 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 :)


Regards,
Colomban

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

Re: [Geany-devel] [geany/geany] 5f0963: List package dependencies only in configure.ac

[Colomban Wendling]

Le 12/04/2012 23:10, Enrico Tröger a écrit :
> On Thu, 12 Apr 2012 22:49:26 +0200, Colomban wrote:
> 
 I'm wondering if there is a way to get at least the version from the
 configuration?  Like bld.conf.libs['GTK'].atleast_version or
 something? I haven't found how to do so, but maybe you'll know :)
>>>
>>> Not completely sure what you mean by "from the configuration". From
>>> where exactly do you want to read the versions?
>>>
>>> Do you want to read the line
>>> gtk_modules="gtk+-2.0 >= 2.16 glib-2.0 >= 2.20"
>>> from configure.ac?
>>
>> No, I meant fetch the version info from the waf configure() step (lines
>> 131-134).  However we could simply put the package version info in a
>> global and use it in both places.
> 
> Yeah, that sounds good, done in
> https://github.com/geany/geany/commit/012a904e7496699b792761c12385cd289d7b6f68.

Great, looks good :)

Cheers,
Colomban

> 
> Regards,
> Enrico
> 

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

Re: [Geany-devel] [geany/geany] 5f0963: List package dependencies only in configure.ac

[Colomban Wendling]

Le 12/04/2012 22:36, Enrico Tröger a écrit :
> On Thu, 12 Apr 2012 18:47:18 +0200, Colomban wrote:
> 
> Hi,
> 
> first, nice idea about making the dependency information more central!
> 
> 
>>> Modified: wscript
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>> ===
>>> @@ -346,6 +346,7 @@ def build(bld):
>>>  bld.new_task_gen(
>>>  source  = 'geany.pc.in',
>>>  dct = {'VERSION' : VERSION,
>>> +   'DEPENDENCIES': 'gtk+-2.0 >= 2.16
>>> glib-2.0 >= 2.20', 'prefix': bld.env['PREFIX'],
>>> 'exec_prefix': '${prefix}',
>>> 'libdir': '${exec_prefix}/lib',
>>
>> I'm wondering if there is a way to get at least the version from the
>> configuration?  Like bld.conf.libs['GTK'].atleast_version or something?
>> I haven't found how to do so, but maybe you'll know :)
> 
> Not completely sure what you mean by "from the configuration". From
> where exactly do you want to read the versions?
> 
> Do you want to read the line
> gtk_modules="gtk+-2.0 >= 2.16 glib-2.0 >= 2.20"
> from configure.ac?

No, I meant fetch the version info from the waf configure() step (lines
131-134).  However we could simply put the package version info in a
global and use it in both places.

> That would be a bit hackish but definetely possible and would make
> maintaing the versions easier, a bit less obvious the fact we are using
> two build systems...(yes, I know...).

Well, although it'd make a GTK dependency version bump a little easier,
it's so hackish I doubt it's a good idea because of the potential
headache it it breaks at some point :)

Cheers,
Colomban

> 
> If so, I could write a few lines to "parse" configure.ac :).
> 
> Regards,
> Enrico
> 

___
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

[Colomban Wendling]

Le 10/04/2012 01:59, Lex Trotman a écrit :
> On 10 April 2012 09:05, Colomban Wendling  wrote:
>> Hi,
>>
>> Le 09/04/2012 12:41, Lex Trotman a écrit :
>>> On 9 April 2012 20:08, Nayan Shah  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.

Or maybe I simply misremember what was the problem and it only truncated
the output, I'm not 100% sure, though I think it was worst than that.

>> 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?

Well, "universal" is maybe a bit too presumptuous, but yeah, I wanted it
to support any intenter.   However, I made it "backend-based" style, so
it can use e.g. a library, but it then requires the backend to be
written, not simply a indenter program to exist.

> And maybe integrate Universal Indent GUI to set them up?

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.

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

Re: [Geany-devel] [geany/geany] 5f0963: List package dependencies only in configure.ac

[Colomban Wendling]

Le 12/04/2012 18:41, Colomban Wendling a écrit :
> Modified: wscript
> 1 files changed, 1 insertions(+), 0 deletions(-)
> ===
> @@ -346,6 +346,7 @@ def build(bld):
>  bld.new_task_gen(
>  source  = 'geany.pc.in',
>  dct = {'VERSION' : VERSION,
> +   'DEPENDENCIES': 'gtk+-2.0 >= 2.16 glib-2.0 >= 
> 2.20',
> 'prefix': bld.env['PREFIX'],
> 'exec_prefix': '${prefix}',
> 'libdir': '${exec_prefix}/lib',

I'm wondering if there is a way to get at least the version from the
configuration?  Like bld.conf.libs['GTK'].atleast_version or something?
 I haven't found how to do so, but maybe you'll know :)

Cheers,
Colomban
___
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

[Colomban Wendling]

Hi,

Le 09/04/2012 12:41, Lex Trotman a écrit :
> On 9 April 2012 20:08, Nayan Shah  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  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
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
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.

So yes, AStyle can be used, but no, you can't pipe it data so it can't
be used with custom commands.   However, GNUIndent can.


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

Re: [Geany-devel] geany-plugins tests failures

[Colomban Wendling]

Le 25/03/2012 17:46, Quentin Glidic a écrit :
> Hello,
> 
> While running geany-plugins tests, I hit two failures.
> 
> The first one is that cppcheck is not happy about Vala, and since
> multiterm is fully in Vala, it fails.

ACK, running cppcheck on a non-C plugin seems stupid anyway.

> The second one is that it couldn’t detect an assignment nested in an array.

ACK, "initializer element is not computable at load time" which is bad C
anyway.

> Attached two simple patches to fix these.
> 
> Cheers


BTW, my cppcheck (1.53) finds 5 things in debugger:

dbm_gdb.c:1304: error: Possible null pointer dereference: record
dbm_gdb.c:1579: error: Possible null pointer dereference: record
dbm_gdb.c:1700: error: Possible null pointer dereference: record
dbm_gdb.c:967: error: Memory pointed to by 'record' is freed twice.
debug.c:502: error: Possible null pointer dereference: expression

The first looks like a real possible problem, if exec_sync_command()
returns RC_DONE at line 618 because wait4prompt is false.

The others *may* be false positive because cppcheck guesses that if you
initialize a variable to NULL you expect that passing it "by reference"
may not change its value.  (e.g. foo=NULL; fun(&foo); ...)

However they seem to be real problems to me here.  It seems to me that
exec_sync_command() can return RC_DONE either if it has or not set the
command_record argument, in which case the caller can't know whether it
has to free the value or if it wasn't set.  So, the caller must pass a
properly NULL-initialized variable;  but then the caller also have to
check whether that variable is non-NULL before dereferencing it -- and
must free() it whatever happens.

So, IIUC:

in dbm_gdb.c on lines 1304, 1579, 1700:
 * record should be checked against NULL before passing it to strstr()

in dbm_gdb.c on line 1579:
 * record should be freed even when rc != RC_DONE (line 1578)

in dbm_gdb.c on line 967:
 * record should be re-initialized to NULL after the first free on line 963

in debug.c on line 502:
 * IIRC expression might be NULL if it happens that the W_EXPRESSION
column isn't set in the model, so a NULL check should be done before
passing expression to strlen()
 * using strlen() to check whether a string is empty seems sub-optimal
too, and you could consider using the NZV() macro from geany's utils.h
-- and this macro handles NULL too


That's all for now :)  There are also some stuff that should be fixed
for good C practices and/or C89 compliance, but I'll check these later.

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

[Geany-devel] Scope completion fix/reimplementation

[Colomban Wendling]

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".


So.  I'm now waiting for your replies :)

Cheers,
Colomban



[1] because I don't think anybody understands the TM code anymore, and
it has some flaws we can't fix -- this one for example
>From a96669230b860ae3229150715ff65621d3c37657 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Tue, 23 Aug 2011 02:20:11 +0200
Subject: [PATCH] First attempt at fixing scope completion

Actually it's a re-implementation that looks pretty well working.
---
 src/editor.c |  204 -
 1 files changed, 186 insertions(+), 18 deletions(-)

diff --git a/src/editor.c b/src/editor.c
index 67dd295..739c940 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -683,14 +683,190 @@ static void request_reshowing_calltip(SCNotification *nt)
 }
 
 
+/* mostly stolen from tm_workspace.c:match_langs() */
+static gboolean lang_matches(const TMTag *tag, langType lang)
+{
+	if (lang == -1)
+		return TRUE;
+
+	if (tag->atts.entry.file)
+	{	/* workspace tag */
+		if (lang == tag->atts.entry.file->lang)
+			return TRUE;
+	}
+	else
+	{	/* global tag */
+		if (lang == tag->atts.file.lang)
+			return TRUE;
+	}
+	return FALSE;
+}
+
+
+/* gets the real type of @name_orig by resolving the typedefs
+ * @file: (in/out) the preferred TMSourceFile, will be filled with the TMSourceFile in which the
+ *   returned is found. This may point to @NULL, but cannot be a NULL pointer */
+static const gchar *resolve_typedef(TMWorkObject **file, const gchar *type_name, langType lang)
+{
+	const TMWorkspace *ws = tm_get_workspace();
+	guint i, pass = 0;
+	GPtrArray *tag_arrays[3];
+	gboolean again;
+
+	g_return_val_if_fail(file != NULL, NULL);
+	g_return_val_if_fail(type_name != NULL, NULL);
+
+	tag_arrays[0] = (*file) ? (*file)->tags_array : NULL;
+	tag_arrays[1] = TM_WORK_OBJECT(ws)->tags_array;
+	tag_arrays[2] = ws->global_tags;
+
+	do
+	{
+		again = FALSE;
+
+		g_debug("resolving %s...", type_name);
+		for (i = 0; i < G_N_ELEMENTS(tag_arrays); i++)
+		{
+			const TMTag *tag;
+			guint j;
+
+			if (! tag_arrays[i] || tag_arrays[i]->len < 1)
+continue;
+
+			foreach_ptr_array(tag, j, tag_arrays[i])
+			{
+if (! lang_matches(tag, lang))
+	continue;
+
+if (tag->type & tm_tag_typedef_t && strcmp(type_name, tag->name) == 0 &&
+	tag->atts.entry.var_type && strcmp (type_name, tag->atts.entry.var_type) != 0)
+{
+	type_name = tag->atts.entry.var_type;
+	/* we need to resolve the new name in case it is typedefed again, trying the
+	 * file containing the typedef first */
+	again = TRUE;
+	*file = TM_WORK_OBJECT(tag->atts.entry.file);
+	tag_arrays[0] = (*file) ? (*file)->tags_array : NULL;
+	break;
+}
+			}
+		}
+		pass++;
+	}
+	while (again && pass <= 8);
+	/* 8 is an arbitrary limit not to loop infinitely on recurive self-referencing typedefs */
+
+	g_debug("resolved to %s.", type_name);
+	return type_name;
+}
+
+
+/* tries to find children of type @type_name
+ * @file: the preferred TMSourceFile (e.g. the one containing the type definitions) */
+static GPtrArray *find_type_children(TMWorkObject *file, const gchar *type_name, langType lang)
+{
+	const TMWorkspace *ws = tm_get_workspace();
+	guint i;
+	gsize len;
+	const GPtrArray *tag_arrays[3];
+	GPtrArray *children =

Re: [Geany-devel] C++ Symbols problem

[Colomban Wendling]

Le 18/03/2012 10:59, Lex Trotman a écrit :
> Hi Colomban,
> 
> I used both patches all afternoon with no visible problems.  They seem
> to work as advertised.  Will keep using, thanks.

Great then :)  I now have committed the sidebar fixes.

Cheers,
Colomban

> 
> Cheers
> Lex
> 
> On 18 March 2012 08:36, Colomban Wendling  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:
>>>
>>> templateclass problem;
>>>
>>> template<> class problem {
>>> };
>>>
>>> template<> class problem {
>>>   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 problem
>>> b) at line 3 definition of problem
>>> c) at line 6 definition of problem
>>>
>>> Note that these are distinct classes as if the names include ,
>>>  and .
>>>
>>> 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 "problem"of 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

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

Re: [Geany-devel] Wrap words Addon patch

[Colomban Wendling]

Le 21/03/2012 08:21, Frank Lanitz a écrit :
> Am 21.03.2012 00:33, schrieb Colomban Wendling:
>> Le 20/03/2012 22:14, Frank Lanitz a écrit :
>>> On Tue, 13 Dec 2011 17:46:47 +0800
>>> Nathan Broadbent  wrote:
>>>
>>>> 1. Visit https://github.com/pzoxiuv/geany-plugins-1
>>>> 2. Click 'Pull Request'
>>>> 3. In the box on the right, you will see the heading 'Head branch ·
>>>> tag · commit'. There is an input field next to "pzoxiuv/geany... @",
>>>> where you should type your branch (addons_wraptext).
>>>> 4. You can enter a title & description, and double check the commits
>>>> and changes. If everything looks good, click 'Send pull request'
>>>
>>
>> I guess you were answering to my "Wrap Word Addon patches" mail?
>>
>>> Once this is done and Nathan is happy with your code he will send the
>>> pull request to geany-plugins and most likely I will have tons of
>>> comments but finally will add it ;) 
>>
>> Hum huh heh heuu… what?  You mean I create a pull request on
>> geany/gneay-plugins right?  I don't know who's Nathan actually, but I
>> doubt he's the new addons maintainer -- or I missed some mails hard and
>> I misread the MAINTAINERS file.
> 
> Nathan build the original patch set introducing wrap word into addons
> plugin.

If I read the mails and the blame correctly, it looks to me it was Alex
Meyer :)

>> Anyway, I created a pull request on the GP repo directly, hopefully it's
>> what you meant and everything's fine.
> 
> Its fine.

Cool.


Cheers,
Colomban

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

Re: [Geany-devel] Wrap words Addon patch

[Colomban Wendling]

Le 20/03/2012 22:14, Frank Lanitz a écrit :
> On Tue, 13 Dec 2011 17:46:47 +0800
> Nathan Broadbent  wrote:
> 
>> 1. Visit https://github.com/pzoxiuv/geany-plugins-1
>> 2. Click 'Pull Request'
>> 3. In the box on the right, you will see the heading 'Head branch ·
>> tag · commit'. There is an input field next to "pzoxiuv/geany... @",
>> where you should type your branch (addons_wraptext).
>> 4. You can enter a title & description, and double check the commits
>> and changes. If everything looks good, click 'Send pull request'
> 

I guess you were answering to my "Wrap Word Addon patches" mail?

> Once this is done and Nathan is happy with your code he will send the
> pull request to geany-plugins and most likely I will have tons of
> comments but finally will add it ;) 

Hum huh heh heuu… what?  You mean I create a pull request on
geany/gneay-plugins right?  I don't know who's Nathan actually, but I
doubt he's the new addons maintainer -- or I missed some mails hard and
I misread the MAINTAINERS file.

Anyway, I created a pull request on the GP repo directly, hopefully it's
what you meant and everything's fine.

Cheers,
Colomban

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

[Geany-devel] Wrap Words Addon patches

[Colomban Wendling]

Hey,

I've a few patches for the Wrap Words Addon that fixes some serious
issues [1].

Since I'm not completely sure what's the policy on committing on G-P,
and since I'm not the Addons maintainer, I'm asking if I should push the
patches myself, create a PR on GitHub or whatever.

BTW, @Frank: if there was a decision on the G-P commit policy, I think
it'd be good for it to be written down somewhere we (I) can find it so
hopefully I'd be the last one to ask :)


Anyway, patches attached.  Feel free to commit if you like, but you can
also tell me to go ahead and commit them -- they're just waiting for me
to git push.


Cheers,
Colomban


[1] OK, I haven't tested them much, I don't use this addon myself -- but
they look correct to my C knowledge and don't introduce too obvious bugs
>From a6c0fc67b0e9c5c2dd345b6348cdc4ca567a1a99 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Sat, 17 Mar 2012 19:07:24 +0100
Subject: [PATCH 1/3] Wrap Words Addon: fix an invalid memory write

key_name allocation was one byte too small (missing alloc for the
trailing 0) and thus possibly leading to a crash.
---
 addons/src/ao_wrapwords.c |   15 +++
 1 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/addons/src/ao_wrapwords.c b/addons/src/ao_wrapwords.c
index 500c449..ff73d6c 100644
--- a/addons/src/ao_wrapwords.c
+++ b/addons/src/ao_wrapwords.c
@@ -137,14 +137,12 @@ gboolean on_key_press (GtkWidget *widget, GdkEventKey *event, gpointer user_data
 void ao_enclose_words_init (gchar *config_file_name, GeanyKeyGroup *key_group)
 {
 	GKeyFile *config = g_key_file_new();
-	gchar *key_name = g_malloc0 (9);
+	gchar key_name[] = "Enclose_x";
 	gint i;
 
 	config_file = g_strdup (config_file_name);
 	g_key_file_load_from_file (config, config_file, G_KEY_FILE_NONE, NULL);
 
-	g_stpcpy (key_name, "Enclose_x");
-
 	for (i = 0; i < 8; i++)
 	{
 		key_name [8] = (gchar) (i + '0');
@@ -157,8 +155,6 @@ void ao_enclose_words_init (gchar *config_file_name, GeanyKeyGroup *key_group)
 
 	plugin_signal_connect(geany_plugin, G_OBJECT(geany->main_widgets->window), "key-press-event",
 			FALSE, G_CALLBACK(on_key_press), NULL);
-
-	g_free (key_name);
 }
 
 void ao_enclose_words_set_enabled (gboolean enabled_w, gboolean enabled_a)
@@ -178,20 +174,16 @@ void configure_response (GtkDialog *dialog, gint response, gpointer char_tree_vi
 	GKeyFile *config = g_key_file_new();
 	gchar *config_data = NULL;
 	gchar *prior_char_str, *end_char_str;
-	gchar *key_name = g_malloc0 (9);
+	gchar key_name[] = "Enclose_x";
 	gint i;
 
-	if (response != GTK_RESPONSE_OK && response != GTK_RESPONSE_ACCEPT) {
-		g_free (key_name);
+	if (response != GTK_RESPONSE_OK && response != GTK_RESPONSE_ACCEPT)
 		return;
-	}
 
 	gtk_tree_model_get_iter_first (GTK_TREE_MODEL(chars_list), &char_iter);
 
 	g_key_file_load_from_file(config, config_file, G_KEY_FILE_NONE, NULL);
 
-	g_stpcpy (key_name, "Enclose_x");
-
 	for (i = 0; i < 8; i++)
 	{
 		key_name [8] = (gchar) (i + '0');
@@ -211,7 +203,6 @@ void configure_response (GtkDialog *dialog, gint response, gpointer char_tree_vi
 	g_free (prior_char_str);
 	g_free (end_char_str);
 	g_free (config_data);
-	g_free (key_name);
 	g_key_file_free(config);
 }
 
-- 
1.7.9.1

>From fba329e4a2a159e2ccf39a1ea7bc6ec5fc41ccd3 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Sun, 18 Mar 2012 04:26:50 +0100
Subject: [PATCH 2/3] Wrap Words Addon: don't mix declaration and code to be
 C89 compliant

---
 addons/src/ao_wrapwords.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/addons/src/ao_wrapwords.c b/addons/src/ao_wrapwords.c
index ff73d6c..be5625e 100644
--- a/addons/src/ao_wrapwords.c
+++ b/addons/src/ao_wrapwords.c
@@ -48,12 +48,14 @@ GtkListStore *chars_list;
 
 void enclose_text_action (guint key_id)
 {
+	gint selection_end;
+	gchar insert_chars [2] = {0, 0};
+	ScintillaObject *sci_obj;
+
 	if (!enclose_enabled)
 		return;
 
-	gint selection_end;
-	gchar insert_chars [2] = {0, 0};
-	ScintillaObject *sci_obj = document_get_current ()->editor->sci;
+	sci_obj = document_get_current ()->editor->sci;
 
 	if (sci_get_selected_text_length (sci_obj) < 2)
 		return;
-- 
1.7.9.1

>From ec51ba318d2976c5c11da004ea0fa9340eea0e70 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Sun, 18 Mar 2012 04:39:56 +0100
Subject: [PATCH 3/3] Wrap Words Addon: plug some memory leaks

---
 addons/src/ao_wrapwords.c |   19 +++
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/addons/src/ao_wrapwords.c b/addons/src/ao_wrapwords.c
index be5625e..a38f7d5 100644
--- a/addons/src/ao_wrapwords.c
+++ b/addons/src/ao_wrapwords.c
@@ -173,9 +173,8 @@ void ao_enclose_words_set_enabled (gboolean enabled_w, gboolean enabled_a)
 void configure_response (GtkDialog *dialog, gint response, gpointer ch

Re: [Geany-devel] Default keybinding for Zoom In

[Colomban Wendling]

Le 19/03/2012 03:06, Matthew Brush a écrit :
> Hi,
> 
> It's always bothered me that Geany uses the "wrong" keybinding for Zoom
> In, but I'm starting to think it's completely on accident. The normal
> keybinding for Zoom In on most applications is Control and Equal (same
> key as plus symbol). If you look at the default keybinding for Zoom In,
> it says plus, which sounds right, but it should really say
> plus, since you have to press Shift to get the plus
> symbol. The correct default keybinding for Zoom In should be
> equal, if it's to be like the vast majority of other software
> that supports zooming.
> 
> Is anybody opposed to me correcting this?

I don't ack.  IMHO, + is the right keybinding and the fact some
apps handle = just like + is only a facility and/or a
compatibility thing maybe.  E.g., Firefox simply accepts + or
= interchangeably, but I never actually used = since I didn't
though it even worked.

Also, I don't think that speaking of + is right, because the
fact + is available through  on qwerty/azerty keyboards should
not matter to the app or even the user.  If typing + requires using
shift, fair enough.  If it doesn't that's fine.

Moreover, how would then be handled the keypad keys?  Currently they we
simply map them to the "normal" keys, eg "KP_plus" is the same as
"plus".  With your proposal, how would you use the keypad to zoom
in/out?  I guess you couldn't since there isn't an equal sign on the keypad.
Ah, and that's also against the + representation since
there's no shift to access + on the keypad.


So you probably got it: I don't think it's a good idea.  BTW, for the
record, what are the applications using the "normal" keybinding you'd
like to see (^=)?

A few I have under the hand:
 * Mozilla products allows both
 * gnome-terminal only accepts + (no kp support)


Cheers,
Colomban

> 
> P.S. I'm only talking about US-like keyboards here, since that's all
> I've ever used.
> 
> 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] Gathering Release 1.22 incompatibilities

[Colomban Wendling]

Le 19/03/2012 01:20, Lex Trotman a écrit :
> Hi All,
> 
> I recently ran into Nicks change of the default keybinding -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 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 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.

I don't see what we did that would've been backward-incompatible that
wasn't already listed (keybinding change, themes, plugin ABI), but maybe
I also miss some...  I'll try to think a bit more if I can recall anything.

About how we should practically keep track of such changes, I suggest to
simply populate NEWS when introducing such a change (or when figuring
out it was such a change for the mentioned cases).

Cheers,
Colomban

> 
> 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] C++ Symbols problem

[Colomban Wendling]

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:
> 
> templateclass problem;
> 
> template<> class problem {
> };
> 
> template<> class problem {
>   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 problem
> b) at line 3 definition of problem
> c) at line 6 definition of problem
> 
> Note that these are distinct classes as if the names include ,
>  and .
> 
> 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 "problem"of 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

diff --git a/src/symbols.c b/src/symbols.c
index ff9c210..a055081 100644
--- a/src/symbols.c
+++ b/src/symbols.c
@@ -1258,21 +1258,105 @@ static gboolean tree_store_remove_row(GtkTreeStore *store, GtkTreeIter *iter)
 }
 
 
-/* updates @table adding @tag->name:@iter if necessary */
+/* adds a new element in the parent table if it's key is known
+ * duplicates are kept */
 static void update_parents_table(GHashTable *table, const TMTag *tag, const gchar *parent_name,
 		const GtkTreeIter *iter)
 {
-	if (g_hash_table_lookup_extended(table, tag->name, NULL, NULL) &&
+	GList **list;
+	if (g_hash_table_lookup_extended(table, tag->name, NULL, (gpointer *) &list) &&
 		! utils_str_equal(parent_name, tag->name) /* prevent Foo::Foo from making parent = child */)
 	{
-		g_hash_table_insert(table, tag->name, g_slice_dup(GtkTreeIter, iter));
+		if (! list)
+		{
+			list = g_slice_alloc(sizeof *list);
+			*list = NULL;
+			g_hash_table_insert(table, tag->name, list);
+		}
+		*list = g_list_prepend(*list, g_slice_dup(GtkTreeIter, iter));
+	}
+}
+
+
+static void free_iter_slice_list(gpointer data)
+{
+	GList **list = data;
+
+	if (list)
+	{
+		GList *node;
+		foreach_list(node, *list)
+			g_slice_free(GtkTreeIter, node->data);
+		g_list_free(*list);
+		g_slice_free1(sizeof *list, list);
 	}
 }
 
 
-static void free_iter_slice(gpointer iter)
+/* inserts a @data in @table on key @tag
+ * previous data is not overwritten if the key is duplicated, but rather the
+ * two values are kept in a list
+ * 
+ * table is: :GSList> */
+static void tags_table_insert(GHashTable *table, TMTag *tag, GList *data)
 {
-	g_slice_free(GtkTreeIter, iter);
+	GList *list = g_hash_table_lookup(table, tag);
+	list = g_list_prepend(list, data);
+	g_hash_table_insert(table, tag, list);
+}
+
+
+/* looks up the entry in @table that matches @tag the better
+ * if 

Re: [Geany-devel] C++ Symbols problem

[Colomban Wendling]

Le 17/03/2012 15:28, Colomban Wendling a écrit :
> Le 16/03/2012 11:30, Lex Trotman a écrit :
>> Hi All,
> 
> Hey,
> 
> I haven't had the time yet to try to fix the sidebar bug, but...
> 
>> So that I don't look unreasonable for criticising just Geany I
> 
> Sweet :p
> 
>> [...]
>>
>> 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).
> 
> Try the attached patch maybe.

Hum, it'd be easier with an attachment.  Here it is.


> It's not really polished and I haven't
> published it because it's not really "the right fix", but if scope
> completion is *that* broken with C++ maybe it's worth committing this at
> least as an interim solution 'till I manage to get another tagmanager
> impl working [1].  That patch is a reimpl of the feature that at least I
> can understand (no TM stuff, heh), and it shows quite good results at
> least for C (and smaaal C++ tests).
> 
> 
> Cheers,
> Colomban
> 
> 
> [1] It's somewhat on the way, but it's far from being trivial work and I
> have/had some non-geany stuff lately, so I wasn't able to work on this
> that much
> 
>> 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 mailing list
> Geany-devel@uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

>From a96669230b860ae3229150715ff65621d3c37657 Mon Sep 17 00:00:00 2001
From: Colomban Wendling 
Date: Tue, 23 Aug 2011 02:20:11 +0200
Subject: [PATCH] First attempt at fixing scope completion

Actually it's a re-implementation that looks pretty well working.
---
 src/editor.c |  204 -
 1 files changed, 186 insertions(+), 18 deletions(-)

diff --git a/src/editor.c b/src/editor.c
index 67dd295..739c940 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -683,14 +683,190 @@ static void request_reshowing_calltip(SCNotification *nt)
 }
 
 
+/* mostly stolen from tm_workspace.c:match_langs() */
+static gboolean lang_matches(const TMTag *tag, langType lang)
+{
+	if (lang == -1)
+		return TRUE;
+
+	if (tag->atts.entry.file)
+	{	/* workspace tag */
+		if (lang == tag->atts.entry.file->lang)
+			return TRUE;
+	}
+	else
+	{	/* global tag */
+		if (lang == tag->atts.file.lang)
+			return TRUE;
+	}
+	return FALSE;
+}
+
+
+/* gets the real type of @name_orig by resolving the typedefs
+ * @file: (in/out) the preferred TMSourceFile, will be filled with the TMSourceFile in which the
+ *   returned is found. This may point to @NULL, but cannot be a NULL pointer */
+static const gchar *resolve_typedef(TMWorkObject **file, const gchar *type_name, langType lang)
+{
+	const TMWorkspace *ws = tm_get_workspace();
+	guint i, pass = 0;
+	GPtrArray *tag_arrays[3];
+	gboolean again;
+
+	g_return_val_if_fail(file != NULL, NULL);
+	g_return_val_if_fail(type_name != NULL, NULL);
+
+	tag_arrays[0] = (*file) ? (*file)->tags_array : NULL;
+	tag_arrays[1] = TM_WORK_OBJECT(ws)->tags_array;
+	tag_arrays[2] = ws->global_tags;
+
+	do
+	{
+		again = FALSE;
+
+		g_debug("resolving %s...", type_name);
+		for (i = 0; i < G_N_ELEMENTS(tag_arrays); i++)
+		{
+			const TMTag *tag;
+			guint j;
+
+			if (! tag_arrays[i] || tag_arrays[i]->len < 1)
+continue;
+
+			foreach_ptr_array(tag, j, tag_arrays[i])
+			{
+if (! lang_matches(tag, lang))
+	continue;
+
+if (tag->type & tm_tag_typedef_t && strcmp(type_name, tag->name) == 0 &&
+	tag->atts.entry.var_type && strcmp (type_name, tag->atts.entry.var_type) != 0)
+{
+	type_name = tag->atts.entry.var_type;
+	/* we need to resolve the new name in case it is typedefed again, trying the
+	 * file containing the typedef first */
+	again = TRUE;
+	*file = TM_WORK_OBJECT(tag->atts.entry.file);
+	tag_arrays[0] = (*file) ? (*file)->tags_array : NULL;
+	break;
+}
+			}
+		}
+		pass++;
+	}
+	while (again && pass <= 8);
+	/* 8 is an arbitrary limit not to loop infinitely on recurive self-referencing typedefs */
+
+	g_debug("resolved to %s.", type_name);
+	return type_name;
+}
+
+
+/* tries to find children of type @type_name
+ * @file: the preferred TMSourceFile (e.g. the one containing the type definitions) */
+static GPtrArray *find_type_children(TMWorkObject *file, const gchar *type_name, 

Re: [Geany-devel] C++ Symbols problem

[Colomban Wendling]

Le 16/03/2012 11:30, Lex Trotman a écrit :
> Hi All,

Hey,

I haven't had the time yet to try to fix the sidebar bug, but...

> So that I don't look unreasonable for criticising just Geany I

Sweet :p

> [...]
> 
> 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).

Try the attached patch maybe.  It's not really polished and I haven't
published it because it's not really "the right fix", but if scope
completion is *that* broken with C++ maybe it's worth committing this at
least as an interim solution 'till I manage to get another tagmanager
impl working [1].  That patch is a reimpl of the feature that at least I
can understand (no TM stuff, heh), and it shows quite good results at
least for C (and smaaal C++ tests).


Cheers,
Colomban


[1] It's somewhat on the way, but it's far from being trivial work and I
have/had some non-geany stuff lately, so I wasn't able to work on this
that much

> 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 mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] small leak in keyfile.c

[Colomban Wendling]

Le 08/03/2012 18:06, Dimitar Zhekov a écrit :
> Hi,
> 
> configuration_reload_default_session() does not free configfile.
> Patch attached.

Thanks, committed.

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

Re: [Geany-devel] Fwd: Security issue in Terminal

[Colomban Wendling]

Le 08/03/2012 17:31, Johann SAUNIER a écrit :
> Which distros are still mounting /tmp on the hard drive rather than on a
> tmpfs file system ?

Not Debian Sid obviously:

$ /bin/df -h /tmp/
Filesystem  Size  Used Avail Use% Mounted on
tmpfs   767M   67M  700M   9% /tmp

...but Debian Stable does:

$ /bin/df -h /tmp/
Filesystem  Size  Used Avail Use% Mounted on
/dev/... 19G  3.8G   14G  22% /

> Le 8 mars 2012 00:20, "Matthew Brush"  > a écrit :
> 
> 
> Hi all,
> 
> Just forwarding this along from the Xfce list as Geany (and many
> other programs) also use this same library for the Terminal feature.
> I'm not convinced it's a big deal, but none-the-less users should be
> aware of it. See the link in the forwarded message for more information.

I don't think it's really a big deal with Geany's terminal in which I
doubt users could do much sensible enough stuff.  However yes, it's
probably worth a note, maybe in the manual.  Though, as Johann pointed
out, at least some distros are mounting tmpfs on /tmp by default so
aren't affected by the issue.


Regards,
Colomban

> 
> Cheers,
> Matthew Brush
> 
> 
>  Original Message 
> Subject: Security issue in Terminal
> Date: Wed, 07 Mar 2012 11:28:58 -0500
> From: David Rosenstrauch http://darose.net>>
> Reply-To: Xfce general discussion list  >
> To: x...@xfce.org 
> 
> Has there already been a bug report filed for this security issue in
> Terminal?
> 
> 
> http://www.climagic.org/__bugreports/libvte-scrollback-__written-to-disk.html
> 
> 
> 
> Thanks,
> 
> DR
> _
> Xfce mailing list
> x...@xfce.org 
> https://mail.xfce.org/mailman/__listinfo/xfce
> 
> http://www.xfce.org
> _
> 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] Commit messages on merges

[Colomban Wendling]

Le 04/03/2012 09:28, Frank Lanitz a écrit :
> On Sun, 04 Mar 2012 03:40:29 +0100
> Colomban Wendling  wrote:
> 
>> IMO we should not record merges when there is only one single commit
>> or when the commits are unrelated (though the latter should probably
>> be less common) and rather rebase or cherry-pick the commits.
>>
>> However, we must keep the merge when the commits are a whole thing not
>> to lose that information (when several commits are needed to
>> implement a single thing).
> 
> I agree. And in second case we have to keep care that merge message is
> informative enough to don't go into complete tree just to understand
> what have been done there. Personally I started using the git merge
> command from command line more often instead of github's web interface
> as its not satisfying my understanding. 

Same for me, moreover because I prefer to test the PR locally as a
simple branch before doing the merge, so it's not much effort than using
the GitHub UI, and it's a lot more powerful.

Cheers,
Colomban
___
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

[Colomban Wendling]

Le 28/02/2012 06:59, Frank Lanitz a écrit :
> Am 27.02.2012 08:44, schrieb 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.
> 
> It's not git. It's most likely githubs's webinterface which is causing
> the entries I'm not happy about. Using command line git merge -m "I just
> did some cool stuff" would be a bit better. Now git log e.g. looks like

I agree that the merge commits should be a bit informative on what they
do, but the branch name should be a good starting point.  In the two
examples below the branch name make me clearly think that those
"branches" (actually pull simply requests I guess) simply holds random
stuff that doesn't depend on each other.  I guess if Jiří made a single
PR it's more because he though having one per commit was overkill rather
than because these commits had strong relationship.

Maybe the "project_patches" one has some semantic, but I doubt "fixes"
does.

> commit 3bcd7fc40078efd601f0e9bed8efec971d505db2
> Merge: 3d4e8b4 5cc8a96
> Author: Matthew Brush 
> Date:   Sun Feb 26 21:04:50 2012 -0800
> 
> Merge pull request #19 from techee/fixes
> 
> Fixes
> 
> commit 3d4e8b41d419255ee1b0764fb60e45ea588bd800
> Merge: d7d5a6d ca9dca9
> Author: Matthew Brush 
> Date:   Sun Feb 26 20:50:01 2012 -0800
> 
> Merge pull request #25 from techee/project_patches
> 
> Project patches
> 
> 
>> 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.
> 
> No. This will remove most probably of e.g. additional contributors.

Rebasing doesn't lose authorship information, it just loses original
commits hierarchy.  Sometimes this hierarchy is useful (like join_lines
patches which makes a whole) and sometimes it is just useless stuff that
makes the history less readable (like Jiří's "fixes" branch where each
commit is a whole without relationship with the other).

IMO we should not record merges when there is only one single commit or
when the commits are unrelated (though the latter should probably be
less common) and rather rebase or cherry-pick the commits.

However, we must keep the merge when the commits are a whole thing not
to lose that information (when several commits are needed to implement a
single thing).


Regards,
Colomban

> Cheers,
> Frank
___
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

[Colomban Wendling]

Le 04/03/2012 02:01, Jiří Techet a écrit :
> On Mon, Feb 27, 2012 at 08:33, Matthew Brush  wrote:
>> On 12-02-26 11:20 PM, Frank Lanitz wrote:
>>>
>>> Hi folks,
>>>
>>> Just something I thought on last merges based on Jiri's patches. Its
>>> hard to understand what this merges do just by reading the commit
>>> message. Given, that we want to create the ChangeLog based on git log it
>>> will be nearly impossible to create a good ChangeLog/Newsfile if we
>>> don't keep care. Not sure how, but can we be more verbose here?
>>>
>>
>> [snip]
>>
>> Just to give everyone who hasn't checked the commits an idea of the
>> verbosity that those commit messages has.
> 
> Is it too verbose? I was trying to add some more detailed info because
> from my experience even though the patch seems to be clear now, when
> looking at it one year later I often feel like "what does the hell the
> patch do?" and "why did I write something like that?". But if it's the
> preferred way I can move the explanation into the merge comment on
> github.

Nope, it's fine IMO  --  and I think Matthew quoted them just to tell
Frank that despite the unclear merge message the commits themselves were
well explained.

> By the way, because the patches I submitted weren't related in any
> way, I think they could have been rebased on top of master instead of
> doing merge.

Agreed, I prefer not to see merges where there's no relation between
several (2+) commits.

Cheers,
Colomban

> 
> Cheers,
> Jiri
> ___
> 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

[Colomban Wendling]

Le 26/02/2012 00:31, Erik de Castro Lopo a écrit :
> Lex Trotman wrote:
> 
> [...]
> 
>> If they are used they
>> should be typedefed to a more user friendly name.
> 
> I am sure I am not the only one who considers
> 
> typedef int32_t my_project_int16_t ;
> 
> to be bad practice.

+1

> 
>> So I suggest that only the fundamental types and  types
>> size_t, nullptr_t ptrdiff_t and max_align_t should be available by
>> adding them to the secondary keyword list for C++.
> 
> Please do not conflate C++ with C.

hum:

> On 25 February 2012 08:01, Frank Lanitz  wrote:
>> [...]
>>
>> Modified Paths:
>> --
>>data/filetypes.cpp

Maybe you're confounding? :)


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

Re: [Geany-devel] Patch for Feature Request #3481844

[Colomban Wendling]

Hi,

Le 25/02/2012 23:01, Michael Hall a écrit :
> Attached is a patch to add a Unity Quicklist shortcut for Geany.  The
> patch is from "svn diff".   

Isn't that the same report than in the pull request #27? [1]  No need to
post it twice :)

Though you made me answer your mail so maybe you got what you wanted ^^

> A description of the reasons why and a screenshot of the results can
> both be found in my recent blog post:
> http://mhall119.com/2012/02/contributing-to-unity-for-non-developers-quicklists/

Well, I've a few questions, remarks or criticisms:

1) The name *must* be translatable.  IIRC you just need to prefix the
entry's name with an underscore (_) for intltool to take care of
translating it.

2) Is this a general-purpose change or a patch that only should be in
Ubuntu?  I mean, I don't know of any other distribution using Unity so
I'm not 100% sure this should be applied "upstream"...

2.1) Doesn't GNOME-Shell has something similar that could be made to
also work?  Or does it already?

3) Is the action really useful?  Launching the "geany" command while
Geany is already running already starts a new instance.


Regards,
Colomban


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

Re: [Geany-devel] Line operations

[Colomban Wendling]

Le 23/02/2012 11:08, Eugene Arshinov a écrit :
> On Mon, 6 Feb 2012 11:55:25 +0400
> Eugene Arshinov  wrote:
> 
>> On Sun, 05 Feb 2012 20:50:38 +0100
>> Colomban Wendling  wrote:
>>
>>> Le 05/02/2012 13:51, Eugene Arshinov a écrit :
>>>> Hello all.
>>>
>> [snip]
>>>
>>>> 2) I want to raise a question, do we need a "join lines" command?
>>>> This command would be a companion of the existing "reflow
>>>> paragraph" command, but in contrast with the latter, it would
>>>> only join lines, but not split them.
>>>>
>>>> This command may be useful when, let's say, you have a document
>>>> created by someone else who sticks with line breaking and inserts
>>>> \n at column 80.  Suppose that you prefer using line wrapping
>>>> instead and want to remove those \n in a peace of a document which
>>>> you're editing.  The new command would help you a bit.
>>>>
>>>> Implementation of the new "join lines" command could use the bits
>>>> of code already written for "reflow paragraph" (though, those bits
>>>> need to be extracted/refactored first).  Moreover, I already
>>>> implemented it and, if the new command seems useful to anyone, I
>>>> can put my implementation in a pull request.
>>>
>>> Not sure I see a use case for this (read: I probably wouldn't use it
>>> if it simply removes the EOLs), but why not if some wants it.  But
>>> maybe Scintilla already have a message for it and thus we'd only
>>> need to use it?
>>>
>>
>> As Lex already wrote, there is SCI_LINESJOIN.  And that's the command
>> which is already used in Geany to implement "reflow paragraph" (to be
>> more precise, two commands are used: LINESJOIN and LINESSPLIT).
>>
>> By the way, here is a related discussion: "[Geany-devel] Support
>> SCI_LINESJOIN and SCI_LINESSPLIT (patch included)" [1].  The first
>> message is authored by me :)
>>
>> [1]: http://lists.uvena.de/geany-devel/2009-July/000834.html
>>
> 
> I created pull request #26 [2] containing the implementation of the new
> "Join lines" command so that it won't get lost.

Good thing, since I finally took a look at it :)
A few remarks on the PR

Cheers,
Colomban

> 
> [2]: https://github.com/geany/geany/pull/26
> 
>> --
>> Best regards,
>> Eugene.
> ___
> 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

[Colomban Wendling]

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?

> 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.
IMO this makes the UI better than fulfilling the tools menu with various
stuff, since it's the "appropriate place" for such an item.

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?


Cheers,
Colomban

> I add the following for consideration:
> 
> 3. be aware of the performance, especially if your plugin does
> something on every keystroke or change or at startup, other plugins
> are likely to want to as well.  Just because the plugin works ok or
> your computer by itself doesn't mean it will work well when the user
> combines it with 15 others on their old notebook and they have heaps
> of files open.
> 
> And on the development side, these have been mentioned before
> ad-nauseum but still need emphasis:
> 
> 4. make your plugin compile clean with -Wall -Wextra -O2
> -Wno-unused-parameter with and without -ansi, and 64bit clean
> 5. don't use anything not *documented* in the plugin interface, a
> change in Geany can make your plugin fail if you do.  But you are
> protected against changes in the interface.
> 
> Any other thoughts?
> 
> 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] Some obsolete(?) bug reports

[Colomban Wendling]

Le 21/02/2012 19:06, Dimitar Zhekov a écrit :
> On Mon, 20 Feb 2012 21:00:44 +0100
> Colomban Wendling  wrote:
> 
>> "To run a second instance of Geany, do not specify any filenames on
>> the command-line, [...]"
>>
>> This should be reworded since it's not true since a long time one
>> need explicit -i, isn't it?  Or do I get the sentence wrong?
> 
> Well, maybe "secondary" instead of second, since I used "subsequent"
> in the previous paragraph.
> 
> -i is required only if you want to open CL files in a new instance,
> instead of passing them to an already running one (explained under
> "Command line options" before "Startup"). If you have a Geany, and
> start another from, say, your DE menu (i.e. without CL), it becomes
> (new instance) automatically.

Hum ok, that's true, my bad.  I actually never launch a second geany
without files nor -i so... :-'

So the patch is fine, I applied it thanks.

Cheers,
Colomban


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

Re: [Geany-devel] Some obsolete(?) bug reports

[Colomban Wendling]

Le 20/02/2012 20:29, Dimitar Zhekov a écrit :
> On Mon, 20 Feb 2012 20:00:38 +0100
> Colomban Wendling  wrote:
> 
>> Thanks a lot, committed.  Maybe an update of the manual to explain
>> more it needed?
> 
> Yes... An update is required because the manual explicitly says "if
> you specify CL files, only they will be opened", and refers the user
> to Recent files. So I altered the Startup section a bit.

Thanks for that update again :)

"To run a second instance of Geany, do not specify any filenames on
the command-line, [...]"

This should be reworded since it's not true since a long time one need
explicit -i, isn't it?  Or do I get the sentence wrong?

Cheers,
Colomban

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

Re: [Geany-devel] Line operations

[Colomban Wendling]

Le 19/02/2012 20:01, Eugene Arshinov a écrit :
> On Sun, 19 Feb 2012 17:24:00 +0100
> Colomban Wendling  wrote:
>
> [...]
> 
>>> The commands indeed work similarly to our own `move_lines`
>>> function.  I posted pull request #24 [3] which removes `move_lines`
>>> function and leverages the commands.  I hope it can be committed so
>>> that I can switch my effort of improving "Move lines" feature from
>>> Geany to Scintilla.
>>
>> Looks fine to -- apart of course it doesn't fix the initial problem
>> yet. At least so there would be only one copy of the functionality.
>>
>> So just to be sure we understand each other: I drop your previous pull
>> request (#21), apply this one (#24) and wait for your patch to be in
>> Scintilla?
>>
> 
> Yes.  But I don't promise that I'll post a request to Scintilla *soon*…

No big deal IMO regarding how long this bug existed without any reports
about it.  See, while I use the feature quite often, I ran into the bug
only once in real situation.

So, it's now applied;  Waits for Scintilla update :)

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

Re: [Geany-devel] Some obsolete(?) bug reports

[Colomban Wendling]

Le 20/02/2012 18:34, Dimitar Zhekov a écrit :
> On Sat, 18 Feb 2012 14:17:17 +0100
> Colomban Wendling  wrote:
> 
>> So I'd say "aye" to Dimitar since he gently volunteered :)  Moreover
>> if it is a preference I don't see any loss; but I'd better see this
>> preference turned on by default for new configurations if the restore
>> session one is on.
> 
> Here's the patch. There is no additional preference - if "Load files
> from the last session" is checked, they are loaded, and that's it.
> Though it'll be easy to make it a pref...

Thanks a lot, committed.  Maybe an update of the manual to explain more
it needed?  Though anyway I think new behavior is much more expected so
that manual would be less read anyway :)

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

Re: [Geany-devel] Line operations

[Colomban Wendling]

Le 19/02/2012 08:02, Eugene Arshinov a écrit :
> Hi there.

Hi Eugene,

> 
> Quick overview - I posted a pull request [3] which removes `move_lines`
> function and uses commands already available in Scintilla.  See below.
> 
> On Sun, 05 Feb 2012 20:50:38 +0100
> Colomban Wendling  wrote:
> 
>> Le 05/02/2012 13:51, Eugene Arshinov a écrit :
>>> Hello all.
>>
>> Hey Eugene,
>>
>>> I have several suggestions and questions about certain line
>>> operations implemented in Geany.
>>>
>>> 1) Recently I found that "move lines up/down" command does not work
>>> properly for the last line not ending with a newline.  You can
>>> easily check it yourself.  Couple of minutes ago I made a pull
>>> request [1] with an implementation of `editor.c:move_lines()` which
>>> handles the problem.  Dear unknown someone, please review and pull
>>> if it's okay.
>>
>> I know this problem, but it needed a so big code refactoring it hurts
>> (I want as a proof the fact your rewrite is... huge), so... I just
>> postponed it.  Ok, shame on me.
>>
>> I haven't reviewed the new code yet, but I'll do.  Just as a note,
>> Scintilla has a command to do that that suffers (suffered?) of the
>> exact same bug we had.  Maybe it'd be good to fix their copy and use
>> the SCI message in place of our code.
>>
>> [snip]
> 
> I didn't find those Scintilla commands (SCI_MOVESELECTEDLINES{UP,DOWN}
> to be precise) because they are not mentioned in the official Scintilla
> documentation [1], though they are of course mentioned in Scintilla.h.
> For completeness, here is the feature request for Scintilla where those
> commands came from - [2].

It is in the docs:
http://www.scintilla.org/ScintillaDoc.html#SCI_MOVESELECTEDLINESUP

> The commands indeed work similarly to our own `move_lines` function.  I
> posted pull request #24 [3] which removes `move_lines` function and
> leverages the commands.  I hope it can be committed so that I can
> switch my effort of improving "Move lines" feature from Geany to
> Scintilla.

Looks fine to -- apart of course it doesn't fix the initial problem yet.
 At least so there would be only one copy of the functionality.

So just to be sure we understand each other: I drop your previous pull
request (#21), apply this one (#24) and wait for your patch to be in
Scintilla?


Regards,
Colomban

> 
> [1]:<http://www.scintilla.org/ScintillaDoc.html>
> [2]:<https://sourceforge.net/tracker/?func=detail&aid=3304850&group_id=2439&atid=352439>
> [3]:<https://github.com/geany/geany/pull/24>
> 
> --
> Best regards,
> Eugene.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Some obsolete(?) bug reports

[Colomban Wendling]

Le 19/02/2012 01:06, Lex Trotman a écrit :
> [...]
>>>
>>> I just taught the file mangler to run geany -c so it never interrupts
>>> what a normal Geany is doing :)
>>
>> I don't think that's something everybody should need to do.
>>
> 
> Yes, true.
> 
> [...]
>> I personally do think what we do is definitely the Wrong Thing.
>> Honestly, I always have found this behavior very counter-intuitive and
>> not helpful.  I mean, if I tell Geany to restore my session, I expect it
>> to be restored whenever I start Geany, not only in some cases.
>>
> 
> Looking at it like that, then the current behaviour is wrong.
> 
> I also checked a few other apps and all restore past sessions and add
> the new file to it, so I would say this is the behaviour a user would
> expect.
> 
> 
>> OK, for me it's not a real problem since I always have one or more Geany
>> instance open, but remembering the early times I did unexpectedly lost
>> some session data because of this behavior.
>>
>> To summarize, I think that the current behavior will most likely NOT be
>> the expected one and will disturb most users.  See, even us do
>> workaround that in some ways, either using -c or having an instance
>> always open.
> 
> Or both, so I *never* saw it as a problem :)
> 
>>
>> So I'd say "aye" to Dimitar since he gently volunteered :)  Moreover if
>> it is a preference I don't see any loss; but I'd better see this
>> preference turned on by default for new configurations if the restore
>> session one is on.
>>
> 
> Colomban has been so persuasive

Hehe :D

> that I don't even think it needs
> another option, the suggested behaviour is non-destructive, so why not
> just turn restoring sessions on or off.

Agreed, another pref isn't needed, either always restore or never
restore should be enough; IMO too.

Sounds reasonable to everybody?

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

Re: [Geany-devel] Some obsolete(?) bug reports

[Colomban Wendling]

Le 19/02/2012 16:42, Enrico Tröger a écrit :
> Hey guys,
> 
> 
>>> 1. Incorrect indentation guides - ID: 2637071 [1]
>>>
>>> I opened the attached document and did not see any issues with
>>> indentation guides.  I could miss something because I rarely use the
>>> guies, but...  Maybe it was already fixed in Scintilla?
>>>
>>> Enrico replied to this report in 2009.
>>>
>>
>> I think this bug is still present if I understand it correctly. The
>> attached file causes indentation guides to be shown on the blank line
>> that has no indentation at all.
> 
> I can't reproduce it here, see attached screenshot.
> Maybe it's related to some preferences set?

I think you just don't have indent guides enabled ;)

> 
> 
> 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

Re: [Geany-devel] Some obsolete(?) bug reports

[Colomban Wendling]

Sorry for the long delay, I was busy last week (OK, no one cares anyway)

Le 18/02/2012 02:45, Lex Trotman a écrit :
> On 18 February 2012 12:13, Matthew Brush  wrote:
>> On 02/17/2012 09:42 AM, Dimitar Zhekov wrote:
>>>
>>> On Mon, 13 Feb 2012 17:14:19 -0800
>>> Matthew Brush  wrote:
>>>
> 3. "geany xyz.txt" does not load files from session - ID: 2838686 [3]
>
> Here it wasn't decided whether of not Geany should restore session.  I
> suggest we discuss this question and finally either fix the bug or mark
> it as WONTFIX.
>

 I don't often use Geany for opening files from the command line and
 usually I always have a Geany window open so if I do, it's not an issue,
 so I can't really provide a worthwhile opinion here.
>>>
>>>
>>> As the bug report states, opening a file _with your file manager_ or
>>> CLI loses the last [default] session [if no geany is running]. The
>>> complaints we usually got were "I double-clicked foo.c and lost my
>>> session", to which we usually replied "use projects". So this affects
>>> the GUI, even more than CLI.
>>>
>>
> 
> I just taught the file mangler to run geany -c so it never interrupts
> what a normal Geany is doing :)

I don't think that's something everybody should need to do.

>> Yeah, I don't usually do that either. I almost always have an instance of
>> Geany running on my 2nd monitor and if not, I'm usually not surprised by the
>> behaviour since I do use projects mostly unless I'm just quickly editing a
>> file or two.
>>
>>
>>> Why not have a vote and finally implement or wontfix it? I volunteer to
>>> write the preference, as a graphical or vaiouus preference, if we decide
>>> "aye".
>>>
>>
> 
> Since there is no "always right" answer as to how Geany should react
> I'd say "wont change" since we have well known documented behaviour
> already.

I personally do think what we do is definitely the Wrong Thing.
Honestly, I always have found this behavior very counter-intuitive and
not helpful.  I mean, if I tell Geany to restore my session, I expect it
to be restored whenever I start Geany, not only in some cases.

OK, for me it's not a real problem since I always have one or more Geany
instance open, but remembering the early times I did unexpectedly lost
some session data because of this behavior.

To summarize, I think that the current behavior will most likely NOT be
the expected one and will disturb most users.  See, even us do
workaround that in some ways, either using -c or having an instance
always open.

So I'd say "aye" to Dimitar since he gently volunteered :)  Moreover if
it is a preference I don't see any loss; but I'd better see this
preference turned on by default for new configurations if the restore
session one is on.


That's my POV of course :)

Cheers,
Colomban


> 
> Cheers
> Lex
> 
>> I have no opposition to this, though I wouldn't even know which way to vote.
>> Why not setup one of those online polls and send a message to the mailing
>> list(s) and see what happens?
>>
>> 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

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

Re: [Geany-devel] Line operations

[Colomban Wendling]

Le 05/02/2012 13:51, Eugene Arshinov a écrit :
> Hello all.

Hey Eugene,

> I have several suggestions and questions about certain line operations
> implemented in Geany.
> 
> 1) Recently I found that "move lines up/down" command does not work
> properly for the last line not ending with a newline.  You can easily
> check it yourself.  Couple of minutes ago I made a pull request [1]
> with an implementation of `editor.c:move_lines()` which handles the
> problem.  Dear unknown someone, please review and pull if it's okay.

I know this problem, but it needed a so big code refactoring it hurts (I
want as a proof the fact your rewrite is... huge), so... I just
postponed it.  Ok, shame on me.

I haven't reviewed the new code yet, but I'll do.  Just as a note,
Scintilla has a command to do that that suffers (suffered?) of the exact
same bug we had.  Maybe it'd be good to fix their copy and use the SCI
message in place of our code.


> [1]: 
> 
> 2) I want to raise a question, do we need a "join lines" command?  This
> command would be a companion of the existing "reflow paragraph"
> command, but in contrast with the latter, it would only join lines, but
> not split them.
> 
> This command may be useful when, let's say, you have a document created
> by someone else who sticks with line breaking and inserts \n at column
> 80.  Suppose that you prefer using line wrapping instead and want to
> remove those \n in a peace of a document which you're editing.  The new
> command would help you a bit.
> 
> Implementation of the new "join lines" command could use the bits of
> code already written for "reflow paragraph" (though, those bits need to
> be extracted/refactored first).  Moreover, I already implemented it
> and, if the new command seems useful to anyone, I can put my
> implementation in a pull request.

Not sure I see a use case for this (read: I probably wouldn't use it if
it simply removes the EOLs), but why not if some wants it.  But maybe
Scintilla already have a message for it and thus we'd only need to use it?


Regards,
Colomban

> 3) Here there should have been a point about some bug reports we have
> in Geany bug tracker, referring to "reflow paragraph" glitches.  As
> this message is already too long, I decided to designate a separate
> message for that (later).
> 
> Thank you for reading :)  Please write your thoughts about 1) and 2)
> 
> --
> Best regards,
> Eugene.
> ___
> 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] Running build commands on windows

[Colomban Wendling]

Hey guys,

Le 05/02/2012 01:47, Lex Trotman a écrit :
> Hi Colomban,
> 
> RE your discussion on IRC about $subject
> 
> To save you searching, some info about g_spawn not working (right) on
> windows, and that it won't be fixed:
> 
> http://article.gmane.org/gmane.editors.geany.devel/583
> 
> and it appears that it was always recognised that splitting on space
> wasn't an elegant way of generating argv for windows, and the problems
> that causes for filenames containing spaces, but nobody has been
> concerned enough to fix it :) see:
> 
> http://lists.uvena.de/geany/2007-November/002082.html
> 
> There is no discussion on why windows commands were used in the first
> place, but given the first reference above I guess it might still not
> be possible to avoid it.

Well, ok, thanks for the links.  Actually my concern wasn't much the
fact we don't use g_spawn* (though using them would've most likely
addressed them) -- though of course it'd be good to have async spawn on
Windows too.
My concern was that the code we have (the one who calls CreateProcessW()
& stuff) looked to me like it mishandled non-ASCII filenames -- and
maybe even spaces.

So hum, huh... I haven't tested everything -- far from it -- but I still
ended up with some changes, details ahead.

First, I've already pushed a few quite innocent things: [1] (code
beauty), and [2] who helps to see WTF happened if creating run script
failed.

Then, I have a few other changes, in the wip/windows-spawn-fixes of my
GitHub fork: https://github.com/b4n/geany/commits/wip/windows-spawn-fixes
The three last commits are relevant:


* da5480f68eba50308993820afb64ec1f8c4a175a - Fix
win32_expand_environment_variables() and calling code encoding usage:

I think this one if fine, and actually fixes a few encoding
misconversions in the spawn code.  The only thing I know that may be
wrong is that I removed the SearchPath() call (who at least should've
been SearchPathW()) because AFAICT from the MSDN docs, CreateProcessW()
already does the job for us (even better than we did).  If we have
something to do then it'd be NOT to search the path if we ain't got the
G_SPAWN_SEARCH_PATH flag, though it's probably not much of an issue.
The only problem I see is maybe the quoting of the arguments, but it's a
mess already and shouldn't be worst with this change.

* 694087248edeb414e5ca12452e1a2bd40e0dc62f - Write
geany_run_script.{sh,bat} in system locale encoding:

The commit message of this one almost says it all, but maybe it's not
that good actually.  I thing it is just fine, because I think the shell
won't ever do magic for us -- and Windows's cmd.exe certainly doesn't --
so it's better to give it locale-encoded data.  On most Linux boxes it
wouldn't change anything since almost all use UTF8 nowadays, but maybe
it'd even fix some problem on e.g. Linux with ISO-8859-* locale.
But again, I'm not 100% sure it's right/the best fix.

* fec4c4730df3b9104f05616e7350368d4719f205 - On windows, set the cmd.exe
codepage to the system locale:

Last but not least, something huh... let's say it works for me.  The
commit explains it, it adds a "chcp" call on top of
geany_run_script.bat, passing it the system locale.  The goal is to make
cmd.exe understand the special characters in the script (of course it
doesn't allow Unicode data @#!), so set it to use the local CP,
hopefully the one we converted the script to (see previous commit).

This made my Windows XP VM box succeed at running scripts/programs named
like "éç ßw", but not "éç ß↓" since the "↓" isn't available in
Windows1252 [3].


So.  The gain is that with these changes we can run programs with a
limited set of special characters in their filename, which wasn't
possible before, and the rest should work still the same.   I haven't
(yet?) tested spawning a build command with special chars in it, but it
should probably work -- but maybe better do some tests.


I'm bored with that Windows stuff for now, so /pause.  However, if
anybody with (or without) Windows knowledge could test (Nick?), comment
or whatever, it'd be awesome :)

Finally, take note I tested all this *ONLY* on Window XP Professional, I
don't have any 2k/Vista/7/whatever box at hand, and I have no idea what
works where.


OK, I'll stop for now, send the mail and take a rest about Windows
stuff.  Have fun ;)


Cheers,
Colomban



[1]
https://github.com/geany/geany/commit/ce21bdfb215f60c270817b641b52ba954303ce9f
[2]
https://github.com/geany/geany/commit/0a22e8a624a095161dd3bdb958243be51510aa3f

[3] though maybe it's a bad example if it isn't in the UTF-16 range,
don't know

> 
> 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] Opening unmounted GIO URIs

[Colomban Wendling]

Le 31/01/2012 02:04, Lex Trotman a écrit :
> On Tue, Jan 31, 2012 at 11:30 AM, Colomban Wendling
>  wrote:
>> Hey Nick, Matthew, Lex, Frank, Enrico, whoever cares,
>>
>> https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64
>>
>> I wrote this patch that adds automatic mounting of volumes needed to
>> open a GIO URI, so one don't have to first mount the corresponding
>> volume in Nautilus/whatever.  This make opening arbitrary URIs from the
>> CLI easier, though it's probably not needed when using a file manager
>> (who would've already mounted the volume to browse it).
>>
>> I'm quite confident mounting the volume is a good idea in theory, but
>> there is a small thing making it a bit tricky: GIO doesn't seem to
>> provide a synchronous API to do that.
> 
> My only problem with making uri operations easier is that the
> incidence of remote data loss or performance complaints will increase.

Hum, while I don't like the reason why it is a good point (remote
support not being perfect), it still IS a good point.  Though, I don't
think that we shouldn't mount the volume to make things harder, if we
really want to stop getting boring reports of users messing with their
data remotely, we should probably simply drop the remote support and let
the user do the mounts AND opens manually.  But do we want that?

>> So, it either requires the calling code to be asynchronous (which we
>> don't have yet and that don't fit well with current code), or to hack
>> around to make the asynchronous code look synchronous.
>>
>> I did the latter, and that's basically the reason why I post this mail:
>>  do you think it's too ugly, too useless, too something?
> 
> Well, shrug, what else can you do?
> 
> But if the mainloop is still running while waiting, does that mean the
> UI is still available and the user can trigger another open? Will that
> work since AFAIK none of Geany is intended to be re-entrant.

Good point.  Just two things to note:

1) It's not actually any worst than gtk_dialog_run() which does the
same, now I added a modal progress dialog [1].  We use gtk_dialog_run()
in many places and don't worry much, so maybe it's enough.

2) The only (easy) way to trigger the volume mounting code is currently
to open an URI pointing to an unmounted volume from the CLI.  All other
ways of of opening remote files (File->Open, URI list DnD, ..) almost
surely needs the volume to be already mounted.  OK, this only makes a
buggy behavior less likely, it doesn't prevent it completely.


The sad story is that GLib/GIO actually HAS the API needed to make this
work completely fine (g_main_context_push/pop_thread_default(),
g_file_supports_thread_contexts()), but GVfsDaemon doesn't support it.
BTW, GVfsDaemon seems to lack plenty of things, see the other mail...

> Its a pity our old friend g_replace_contents doesn't work safely,
> otherwise we could g_file_new_from_uri, g_file_read to read it and
> g_file_replace_contents to write it, and let GIO do what it is meant
> to, sigh.

I think you're a bit too optimistic/naive.  AFAIK, GIO won't ever mount
you a volume implicitly just because you want to read from it.  Actually
it's unlikely it can, because it might require user interaction, like
asking an username or a password.  And GEdit itself does call
g_file_mount_enclosing_volume().

>> Basically, points I see in a pros/cons:
>>
>> + allows to open URIs on unmounted volumes;
>> + as a cause, makes Geany handle URIs more naturally;
>> + mount is tried only as a last resort, so doesn't impact already
>> working situations;
>>
>> - code is a bit hackish (the loop thing), though it works fine [1];
>> - may be slow if mounting the volume is slow (since it is synchronous);
>> - may not be really useful in practice (since people probably open URI
>> through the file manager, who will mount the volume).
>>
> 
> Well I can't comment on its utility since I never edit anything
> remotely anyway. (but I guess that was a comment anyway).

I don't edit much remote files myself and prefer either local edit +
upload or simply Git :)  -- but yes, was a useful comment, thanks :)


Cheers,
Colomban


[1]
https://github.com/b4n/geany/commit/540e6b28d8ce461b44f6fd4dce32c38167bca99b

> 
> 
> Cheers
> Lex
> 
>>
>> So... thoughts?
>>
>>
>> Cheers,
>> Colomban
>>
>>
>> [1] only problem might be that idle/timeout callbacks (e.g. main loop
>> sources) can still run during the mount -- though, I don't see why it'd
>> be an actual problem for us
> 
> See question above
> 
>> 

Re: [Geany-devel] Opening unmounted GIO URIs

[Colomban Wendling]

Le 31/01/2012 20:14, Enrico Tröger a écrit :
> On Tue, 31 Jan 2012 01:30:58 +0100, Colomban wrote:
> 
> Ho Colomban and the rest,
> 
>> https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64
>>
>> I wrote this patch that adds automatic mounting of volumes needed to
>> open a GIO URI, so one don't have to first mount the corresponding
>> volume in Nautilus/whatever.  This make opening arbitrary URIs from the
> 
> whatever = Gigolo!
> 
> :)
> 
> 
>> I'm quite confident mounting the volume is a good idea in theory, but
>> there is a small thing making it a bit tricky: GIO doesn't seem to
>> provide a synchronous API to do that.
>>
>> So, it either requires the calling code to be asynchronous (which we
>> don't have yet and that don't fit well with current code), or to hack
>> around to make the asynchronous code look synchronous.
>>
>> I did the latter, and that's basically the reason why I post this mail:
>> do you think it's too ugly, too useless, too something?
> 
> I basically like the idea.
> If I remember correctly, the relevant code is also called when starting
> Geany and the main GUI isn't yet shown. If so, I see one
> big problem: 

Actually opening from CLI is ~ the only way to trigger the code since
most other would need the volume to be already mounted.  So startup and
remote control.

> if the mount won't finish in a short time, the user doesn't know what's
> happening and probably only notices that Geany doesn't start because no
> GUI is shown.
> So, I think at the very least we would need some sort of timeout, a
> short timeout, to cancel the mount operation if it takes too long. Not
> sure what exactly is 'too long', maybe a few seconds.
> Or even better (and more complex) we would show the user a dialog with
> a pulsing progressbar or so stating that a mount operation is in
> progress. A cancel button would be a big bonus but probabaly not
> necessarily needed.

Good point, here you go with a dialog, pulse & cancel:
https://github.com/b4n/geany/commit/540e6b28d8ce461b44f6fd4dce32c38167bca99b

Having a modal dialog also has the advantage of blocking user
interaction on the main window, addressing a part of Lex's worries.

Just as a funny note, implementing all this required some more hackery
because GVfsDaemon (bridge of all remote FS) doesn't actually honor
cancellation even though the API is supposed to provide it.


So, here it is with a progress dialog & cancellation support.  I tested
it a bit, particularly the opening a second URI from the CLI while
waiting to mount a first one, and it looked like it worked fine: mounted
the stuff and/or asked for details, each after the other, no weird
concurrency.
Though, if anyone wants to test it a bit more, it can't be wrong.

Comments still welcome of course :)


Cheers,
Colomban

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

[Geany-devel] Opening unmounted GIO URIs

[Colomban Wendling]

Hey Nick, Matthew, Lex, Frank, Enrico, whoever cares,

https://github.com/b4n/geany/commit/01fd682674286dada6d6b77d0e3064c89a28df64

I wrote this patch that adds automatic mounting of volumes needed to
open a GIO URI, so one don't have to first mount the corresponding
volume in Nautilus/whatever.  This make opening arbitrary URIs from the
CLI easier, though it's probably not needed when using a file manager
(who would've already mounted the volume to browse it).

I'm quite confident mounting the volume is a good idea in theory, but
there is a small thing making it a bit tricky: GIO doesn't seem to
provide a synchronous API to do that.

So, it either requires the calling code to be asynchronous (which we
don't have yet and that don't fit well with current code), or to hack
around to make the asynchronous code look synchronous.

I did the latter, and that's basically the reason why I post this mail:
 do you think it's too ugly, too useless, too something?

Basically, points I see in a pros/cons:

+ allows to open URIs on unmounted volumes;
+ as a cause, makes Geany handle URIs more naturally;
+ mount is tried only as a last resort, so doesn't impact already
working situations;

- code is a bit hackish (the loop thing), though it works fine [1];
- may be slow if mounting the volume is slow (since it is synchronous);
- may not be really useful in practice (since people probably open URI
through the file manager, who will mount the volume).


So... thoughts?


Cheers,
Colomban


[1] only problem might be that idle/timeout callbacks (e.g. main loop
sources) can still run during the mount -- though, I don't see why it'd
be an actual problem for us
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] get build command from a plugin

[Colomban Wendling]

Le 30/01/2012 23:22, Lex Trotman a écrit :
> On Tue, Jan 31, 2012 at 5:13 AM, Dimitar Zhekov
>  wrote:
>> On Mon, 30 Jan 2012 14:08:59 +1100
>> Lex Trotman  wrote:
>>
 How can I $subject?
>>>
>>> At the moment you can't officially access any of the build system from
>>> a plugin.
>>
>> [::surprise::]
>>
>>> Initially I exposed some of the build system (see comments starting /*
>>> * in build.h/c) but concerns were raised that this exposed the
>>> implementation so it was removed.
>>
>> I don't see anything starting with /**, and there are lots of /* *...
> 
> Thats because none of them are "officially" exposed, the space
> prevents doxygen from picking them up so they are not in the plugin
> doc.
> 
>>
>>> My attempts to proactively define an interface that does not expose
>>> any implementation structures was also rejected, so there is
>>> officially no way.
>>
>> Hmmm... Have you tried something simple, like:
>>
>> const gchar *build_get_command(ft, index, part)
>>
>> Where:
>>
>> ft = filetype | independent | exec
> 
> existing enum GeanyBuildGroup, we shouldn't add an extra enum that can
> get out of step
> 
>> index = 0, 1, ...
>> part = label | command | workdir
> 
> existing enum GeanyBuildCmdEntries, as above
> 
>>
>> rval = NULL if index is too big or some other argument is invalid.
> 
> Yeah, if all you need is read-only access, I'll just change
> build_get_current_menu_item() to return only one field, means that you
> have to make three calls though.  It does all the checks to return
> NULL already.  build_get_current_menu_item() is not officially in the
> API and it isn't used internally so it can be changed.
> 
> Now do I return the gchar * and trust you not to write to it, or copy
> the string and trust you to free it?  Maybe return const gchar* so you
> you are warned not to change it or free it.

Yes, return const gchar *.  Returning internal data as gchar * is
neither a great idea nor a common idiom in Geany/GLib/GTK; and
duplicating just for the fun is less handy to use for the caller and
only has the real advantage that a future implementation could drop that
internal representation and simply compute it.  But const gchar * should
be enough to tell the caller not to touch the data, if somebody actually
modifies it and it cause problems, I'd say "you deserved it".


Cheers,
Colomban

> 
>>
>> Of course, it's not much different than the current build_get_*()
>> functions, but doesn't expose any build structures. And I guess
>> people will need the effective value, not some particular source.
>>
> 
> Yeah, see above, build_get_current_menu_item gets what you call the
> effective value (it returns the source, but if you don't want it I
> won't return it).
> 
>>> I guess you need to request the parts you need, and those will be
>>> exposed in the usual ad-hoc way.
>>
>> Some home_ft/project specific commands. They're not hard to get, but
>> re-reading the key files is hardly the right thing.
>>
> 
> And reading the files wouldn't get any changes the user has made this
> session since they are not saved until Geany closes.
> Does above suit you?
> 
> 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 mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] GIT commit mails format

[Colomban Wendling]

Le 15/01/2012 23:53, Enrico Tröger a écrit :

On Sun, 15 Jan 2012 13:35:35 -0800, Matthew wrote:


On 01/15/2012 12:03 PM, Lex Trotman wrote:

[...]

What do you think?

If we agree to change the commit mails to this format, I'd deploy
the script soon.



I'd very much like it, and I'm fine with the format :)



Hi Enrico,

Actually I've become used to the standard github commit emails and
clicking on the link for the diff.

Especially for large changes like geany.html or geany.glade (despite
Matthew and Colomban "promising" the diffs will get smaller with
3.8.1) not being blasted by large diffs is good.  I can choose what I
want to see, and don't get the two line diff of geany.txt cut off
because the huge geany.html diff exceeds the size limit.

I don't suppose that you could let registration for the commit ML
allow a choice of which we want?


Nope.
The only option would be two separate mailing lists.

Though the general idea about the diffs was to limit the diff size to
something like 100kb (as it was before in the SF SVN commit mails) or
any other value which we consider reasonable.



Or make it so no diff is shown for autogenerated files like geany.html
and geany.glade ?

It'd be the best of both worlds then, IMO.


Yeah, a little hackish but would solve the problem probably well enough
together with a general max commit diff size limit.


Why not, until we finally understand how the $@!% Glade choose to output 
in one order or another.  But please keep the info the file got 
modified, don't drop it entirely :)


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

Re: [Geany-devel] encoding combo boxes bug

[Colomban Wendling]

Le 20/01/2012 00:07, Lex Trotman a écrit :

On Fri, Jan 20, 2012 at 9:58 AM, Lex Trotman  wrote:

On Thu, Jan 19, 2012 at 11:53 PM, Nick Treleaven
  wrote:

Hi,
I'm seeing wrong encoding names in the encoding combo boxes on the Files tab
of the Prefs dialog. E.g. where it should say UTF-8 I see Hebrew. Another
Glade-related bug?


Sort of, according to glade combo_new_encoding, combo_open_encoding
and combo_eol all share the same underlying list model.

So when we initialise them, all the entries go in the same list, so
all three show the encodings twice and the end of line entries at the
bottom.

Two of these need to be pointed to different list models.


PS the two encodings combos could probably share the same list, so
long as we only initialise it once in prefs.c, but eol needs its own
list


Thanks for the catch & analysis, it's now fixed -- actually I did broke 
it in ca922e0ddc8022283ec3c1f49aaa15ab7c5ba213, stupid me.


@All: I added ui_builder_get_object() to be able to fetch a non-widget 
(list store here) from prefs.c, but I'm not completely sure it's the 
prefect fix.  If you have any idea on how to improve this, spread them! :)


@Nick: how did you generate the Glade file for 
21cd7bb2139fd67644e5777bb8e6387d34473d09 "Add Project overrides for 
'Saving files' checkbox options"?  When I do use Glade 3.8.1 do modify 
the file it keeps reordering prefs/project dialogs...  Just wondering, 
actually committing the move isn't really harmful -- apart that it 
renders the diff unreadable, stupid Glade.



Regards,
Colomban



Cheers
Lex



I don't have Glade 3.8.1 (need 3.10 for another project) so I
shouldn't do it, someone with the right Glade care to create two new
list models.

Cheers
Lex



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


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

Re: [Geany-devel] Whither goest CTRL-Q?

[Colomban Wendling]

Le 14/01/2012 01:06, Ross McKay a écrit :

G'day,

I pulled the latest from git late yesterday, and just noticed that
CTRL-Q no longer binds to Quit.

a) was this intentional?
b) is there a way to put this back? (can't see it in key bindings)

cheers,
Ross


They should be back in master, thanks for noticing.

Cheers,
Colomban

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

Re: [Geany-devel] Fixing Glade File (was Re: Whither goest CTRL-Q?)

[Colomban Wendling]

Le 14/01/2012 03:24, Matthew Brush a écrit :

Hi,

For whatever reason in commit c85b89afdd880b7a6aac42f953bab83d3938a4a3
(fixing the project dialog), Glade removed the accelerators (and
adjustments) from geany.glade.

I'm looking for a clever way to fix this without having to manually edit
the Glade XML, add the dropped stuff back manually, or revert and redo
all my changes from that commit.

Any hints/ideas?

P.S. I tried just copying the whole XML block for the project notebook
(where all my *intended* changes were) into the non-broken version just
before that commit, and it worked somewhat, but there's been changes to
this chunk of code in a later commit, so those don't work.


Well... I managed to get it done with sed + handwriting, that was a bit 
boring but not that hard.


Hope it's fixed now.

Cheers,
Colomban



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: MAINTAINERS file

[Colomban Wendling]

Le 07/01/2012 16:00, Frank Lanitz a écrit :

On Fri, 6 Jan 2012 23:42:39 +0100
Frank Lanitz  wrote:


* What's the exact difference between Supported and Maintained?  The
only difference I see is that "supported" has the word "paid" in the
description, but I doubt that most of us get paid for this in
particular, and I also doubt it changes anything on how good is the
support (hobby vs. job).


My fault. I wanted to change this but missed it. I wanted to
s/supported/paid for ... (Even I don't know anybody at the moment who
is getting paid with Geany stuff ;) )


I suggest to use paid instead of supported and change current usage of
supported to maintained.


I'm still not sure what that fact someone is paid or not changes, but 
otherwise it looks fine and clearer to me.


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

Re: [Geany-devel] GtkFileChooser "recent" annoyance

[Colomban Wendling]

Le 20/12/2011 19:18, Colomban Wendling a écrit :
> Le 20/12/2011 05:07, Matthew Brush a écrit :
>> Hi,
>>
>> Is anyone opposed to me committing the trivial patch attached here.  The
>> comment I think describes it well enough, and if you're using recent
>> GTK+ 2.24.x you probably already know about it.
>>
>> I didn't want to commit without asking since maybe some people will find
>> this new "feature"[1][2] useful, I personally find it extremely
>> annoying, but I wouldn't want to fix it at the expense of annoying others.
> 
> While I agree the recent list is not useful most of the time (probably
> even annoying since I don't know that dir) for me either, I doubt $HOME
> is really best.
>
> I see 2 alternative, and I think better, choices:
> 
> 1) use the basedir of the currently opened file;
> 2) use the "current dir" (e.g. dir from where Geany was started) [1].
>AFAIK this will be $HOME for panel/shell-launched apps.
> 
> And maybe add an hidden option in case ppl actually like the GTK feature?

Hum, actually we already have a setting allowing the user to choose the
directory to show by default in the open dialog (general -> startup ->
startup folder), so annoyed user can easily change the default.

OTOH, while I personally don't like the feature very much and still
thinks such a change shouldn't have happened in GTK2 as it did, I don't
find really comfortable working this around.
IMHO, if this really annoys people, the GTK guys should either revert
the patch or add a GtkSetting for whether to use it or not.  It'd fix
the thing for all apps, and wouldn't require ugly workarounds.

So I'd finally vote against applying the patch, since we do actually
have a quite easy way to work it around that's IMO better than the patch.


Regards,
Colomban


> Cheers,
> Colomban
> 
> 
> [1] maybe not on Windows where I think the "current dir" is always the
> binary location?
> 
>>
>> Cheers,
>> Matthew Brush
>>
>> [1]
>> https://live.gnome.org/DocumentCentricGnome/Help%20the%20user%20choose%20a%20place%20to%20put%20a%20new%20file
>>
>> [2] I think we can safely assume Geany users (ie. programmers) already
>> know how to manage files :)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany-Plugins: MAINTAINERS file

[Colomban Wendling]

Le 06/01/2012 10:29, Frank Lanitz a écrit :
> Hi folks,
> 
> We have just added a MAINTAINERS into git to add a single point to find
> who is responsible for a plugin. Please be so kind and sending in
> patches or updating the file on your own for your plugins to show who is
> maintaining etc. File contains a little header with very brief
> instructions to do so.

Oops sorry, I completely forgot to do it myself.  Now done.

Just a few questions:

* What's the exact difference between P and M?  Do we really expect to
have a maintainer but somebody else that deals with the patches?

* What's the exact difference between Supported and Maintained?  The
only difference I see is that "supported" has the word "paid" in the
description, but I doubt that most of us get paid for this in
particular, and I also doubt it changes anything on how good is the
support (hobby vs. job).

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

Re: [Geany-devel] Weird Segfault Crash

[Colomban Wendling]

Le 03/01/2012 14:36, Nick Treleaven a écrit :
> On 02/01/2012 15:54, Nick Treleaven wrote:
>> On 02/01/2012 14:33, Colomban Wendling wrote:
>>>> encodings_convert_to_utf8_from_charset(utf8_name, (gsize) -1, ...)
>>>> >
>>>> > Is it OK the cast a negative number to `gsize` and will it have the
>>>> > desired effect for that function? The `-1` here is supposed to tell
>>>> the
>>>> > encoding function that the string is nul terminated and is to be
>>>> > measured with `strlen()` IIUC.
>>> It's ugly, but AFAIK it'll work fine everywhere since it's casted back
>>> to gssize in that function. But you're right, it should definitely be a
>>> gssize parameter. Unfortunately this function is in the plugin API, and
>>> I'm not sure of the implications of changing that parameter's type...
>>
>> That should be fixed. I'm not sure whether it needs an ABI break or not
>> (guess not), but if the parameter can be -1 then make it gssize.
> 
> Now fixed in Git. I decided an ABI break wasn't needed.

OK, cool.  Let's just hope it don't lead to weird behavior, I'm still
not 100% sure of what would happen even though I'm quite confident it'll
work at least on x86 (and actually a test of mine shows it does on my
x86_64 box :) ).

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

Re: [Geany-devel] Weird Segfault Crash

[Colomban Wendling]

Hi,

Le 02/01/2012 06:01, Matthew Brush a écrit :
> Hi,
> 
> I'm having some random crashes, possibly due to bad tag files?  Patch
> attached "fixes" the segfault, but I'm pretty sure it's not the
> "correct" fix.

Well, you spotted a quite complex bug in tag encoding management...
what we currently do is to assume tag's strings are encoded in the
document's encoding, which is probably true for document tags but not
necessarily for global tags.

I'm not sure what would be the right fix... we either need to always
have the same encoding in a TMTag (better be UTF8), or we need to have a
way to find what's the tag's encoding (e.g. a new TMTag field, ouch).

Your change at least prevents a crash, but it skips completely the tag.
 It's probably better than crashing, but still not perfect.  Another bad
solution would be to do something like [1].

This said, I'm pretty sure that if you get this bug you have some tags
with non-ASCII characters, which is huh... weird.  The only language I
know would work with such mixed-encoding non-ASCII names is Python3 --
and even there it's considered bad practice to use the feature :D

So, I'm not sure what we should do here, but we probably do something.
Any idea?

> 
> P.S. I also noticed in this block of code::
> 
> encodings_convert_to_utf8_from_charset(utf8_name, (gsize) -1, ...)
> 
> Is it OK the cast a negative number to `gsize` and will it have the
> desired effect for that function? The `-1` here is supposed to tell the
> encoding function that the string is nul terminated and is to be
> measured with `strlen()` IIUC.

It's ugly, but AFAIK it'll work fine everywhere since it's casted back
to gssize in that function.  But you're right, it should definitely be a
gssize parameter.  Unfortunately this function is in the plugin API, and
I'm not sure of the implications of changing that parameter's type...


Cheers,
Colomban

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