Re: [Geany-devel] editor context menu - Re: Search submenu for editor popup menu

2010-09-16 Thread Денис Корявов
May be make sense create context menu like in jEdit (context menu in
jEdit is editable)?
Is really good jEdit feature, and would be very nice if Geany have
this feature too.

-- 
WBR, Denis Koryavov.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] [PATCH 05/19] Don't be annoying when not necessary

2010-09-16 Thread Jiří Techet
On Wed, Sep 15, 2010 at 23:15, Colomban Wendling
lists@herbesfolles.org wrote:
 Hi,

 Le 16/08/2010 02:51, Erik de Castro Lopo a écrit :
 Jiří Techet wrote:


 When reloading a file with ctrl+R don't display the warning dialog
 that the unsaved changes might be lost when the file has not been
 modified.

 I've been running with this patch for about a week. Looks good to me.
 This one seems to have been applied as r5190, and I have a little
 complain about it, so perhaps it would need a little more thought.

 The problem is that reloading a document not only looses unsaved
 changes, but also undo/redo stack. This is particularly annoying if you
 hit the shortcut by accident (which I unfortunately did :( ).
 So I propose to two possible solutions:
 1) simply check whether there's possible undo/redo, and if yes, ask
 before reloading (little patch joined);
 2) the solution 1 fixes my problem, but probably not (?) for somebody
 that was annoyed by this dialog like Jiří was. So, perhaps a... setting
 (!) would be useful?

(1) is OK with me. The moment when I found the previous behaviour
annoying was when I created a new project, opened several files and
then realized that the indent indent size in the project settings was
different than the actual indents in the files. I modified the project
settings but the open files had to be reloaded in order to get the new
indent settings.

The patch was meant to fix this little annoyance I had with confirming
the dialog in a trivial way but if it's causing troubles in other
situations, it's OK with me if the patch is reverted. The above
situation is not something I run into every day.

Jiri


 What do you think?

 Regards,
 Colomban

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


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


Re: [Geany-devel] editor context menu - Re: Search submenu for editor popup menu

2010-09-16 Thread Nick Treleaven
On Thu, 16 Sep 2010 09:54:09 +1000
Lex Trotman ele...@gmail.com wrote:

  2. let the user pick say four most used top level commands since we
  are *never* going to agree on them.  Use a simplified version of the
  customise toolbar dialog.
 
  Personally I don't think it's worth doing this. Put the most useful
  things at toplevel, everything else in submenus.
 
 Ah but whats the most useful?

Things which are useful for the largest number of users. There is also
an issue of letting new users discover some useful things easily that
they might not know Geany does.

  I *never* use insert comments from the popup and rarely from the menu
 (changelog mostly) so for me having any insert comments in the popup
 is a waste of space.

Which is why a single Insert submenu would be better.

 I'm not suggesting its required, but if someone out there has the time
 to implement it this would remove all the disagreements :-)

Is it so bad to solve the disagreements using submenus?

This avoids maintenance and code complexity of popup configurability,
which I predict isn't going to be pretty. C is not a good GUI language.

  3. pack the rest in submenus.
 
  format  format submenu as now
 
  What about Commands - at least half of these are context related.
 
  insert  insert submenu including the insert comments
 
  I think at least me and Enrico use insert comments a lot, we'd like it
  to be toplevel. The other insert items could maybe be in a submenu
  (also insert alt whitespace). This would be like having Go to Tag
  Definition in toplevel but Go to Tag Declaration in a submenu as it's
  less common.
 
 And I of course use the tool differently so I don't want any inserts

Did you see my Insert submenu reply?

 and use go to declaration much more than go to definition due to the
 language I use most :-).

Correct me if wrong, but Go to declaration is only needed for function
prototypes and extern declarations, no? The feature is only useful for
C/C++, not for most users. So having to find it in the proposed popup
Search submenu is acceptable, no?

 For all user names : [insert name here] uses it differently again so
 almost no one is fully happy with a fixed menu.

As mentioned above, I'm not trying to force my preferences on anyone.
I'm trying to find a good default that is reasonable (but not ideal)
for everyone.

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


[Geany-devel] regex autoindentation - Re: [PATCH 14/19] Rewrite tab switching queue

2010-09-16 Thread Nick Treleaven
On Thu, 16 Sep 2010 10:23:41 +1000
Lex Trotman ele...@gmail.com wrote:

  By the way, the last
  commit in my tree performes indentation based on regex matching as I
  was proposing some time ago. I haven't published it yet because there
  are already quite many of my patches pending here and I want them to
  be reviewed first. Anyway, if you (or anyone else) are interested, you
  can have a look.

We're interested, I've thought for a while how this could be useful.

 I couldn't get this to work at all, it printed calling indent this
 line all the time but didn't indent :-(

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


Re: [Geany-devel] [PATCH 14/19] Rewrite tab switching queue

2010-09-16 Thread Nick Treleaven
On Wed, 15 Sep 2010 21:34:52 +0200
Jiří Techet tec...@gmail.com wrote:

  Thanks, I'd like to commit this now. I realize it's been a while, but
  the patch doesn't apply cleanly and I can't see any commits since that
  would have caused conflicts. Any chance you could update and resubmit
  please?
 
 Hi Nick,
 
 no problem, I have just rebased all my patches on top of mainline.
 This particular patch is attached.

Thanks, but still no joy. The problem is these 2 hunks:

 @@ -599,7 +599,7 @@ static void on_document_close(GObject *obj, GeanyDocument 
 *doc)
   {
   GeanyDocument *last_doc;
  
 - last_doc = g_queue_peek_head(mru_docs);
 + last_doc = g_queue_peek_nth(mru_docs, 1);
  
   if (DOC_VALID(last_doc)  document_get_current() == doc)
   {
 @@ -607,8 +607,10 @@ static void on_document_close(GObject *obj, 
 GeanyDocument *doc)
   document_get_notebook_page(last_doc));
   }
   g_queue_remove(mru_docs, doc);
 -
 - g_idle_add(on_idle_close, NULL);
 + /* this prevents the pop up window from showing when there's a 
 single
 +  * document */
 + if 
 (gtk_notebook_get_n_pages(GTK_NOTEBOOK(main_widgets.notebook)) == 2)
 + g_queue_clear(mru_docs);
   }
  }

I haven't been able to work out where they apply to. It didn't seem
that a conflict had been introduced since your first patch for this
code, but maybe I'm missing something.

 You can find the remaining pending
 patches under for_review3 branch here:
 
 http://gitorious.org/~techy/geany/gproject-geany

 If you wish me to resubmit them by email, just tell me - I would

Thanks - no need to resend. I can download the patches.

 really like to see the patches extending geany's API to be a part of
 mainline so my gproject plugin would not depend on patched geany and
 could be moved among other plugins repository.

I've applied some this afternoon, will get through them soon hopefully.

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


Re: [Geany-devel] [PATCH 14/19] Rewrite tab switching queue

2010-09-16 Thread Thomas Martitz

 On 16.09.2010 02:23, Lex Trotman wrote:

Hi Jiri,

I couldn't get this to work at all, it printed calling indent this
line all the time but didn't indent :-(

I only had half an hour so I couldn't investigate much.



I have the same experience. Auto-indentation doesn't seem to work 
anymore (e.g. when hitting enter after on a line that ends with {, or 
when typing }).


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


Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)

2010-09-16 Thread Jiří Techet
On Thu, Sep 16, 2010 at 19:27, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
  On 16.09.2010 02:23, Lex Trotman wrote:

 Hi Jiri,

 I couldn't get this to work at all, it printed calling indent this
 line all the time but didn't indent :-(

 I only had half an hour so I couldn't investigate much.


 I have the same experience. Auto-indentation doesn't seem to work anymore
 (e.g. when hitting enter after on a line that ends with {, or when typing
 }).

I have just re-tested it again and it works on my machine (I have
forgotten one trace in the code - that's what you see in the console).
A quick question: have you read the commit log?

This patch makes it possible to specify several regex patterns for every
filetype which determine under what condition the indentation is performed.
The pattern variables are specified under the [settings] section of the
given filetype and their value is the regex to be used. The variables are
as follows:

* indent_this_line_regex - the match is performed after every keystroke
  and if the regex matches, the indentation is performed on the current
  line
* indent_next_line_regex - the match is performed only when enter is
  pressed. The indentation is applied on the next line
* unindent_this_line_regex - like indent_this_line_regex but
unindents instead
* unindent_next_line_regex - like indent_next_line_regex but indents instead

Comments and strings are detected from the lexer so these can be ignored
inside the patterns. For instance these are very basic rules for GNU
indent style:

indent_next_line_regex=^.*\\{[[:blank:]]*$
unindent_this_line_regex=^[[:blank:]]*\\}$
indent_this_line_regex=^[[:blank:]]+\\{$
unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$

By commenting-out the last two lines you get ANSI indentation style.
If you replace \\{ and \\} with begin and end, respectively, you
get analogous rules for pascal. Notice the double-escaping of { and } -
the first escape sequence is for the keyfile ini format (so for the
regex itself \\ becomes \).

This means that in order to make it work e.g. for C, you have to edit

~/.config/geany/filedefs/filetypes.c

(or the corresponding file under /usr/local/share/geany) and add

indent_next_line_regex=^.*\\{[[:blank:]]*$
unindent_this_line_regex=^[[:blank:]]*\\}$
indent_this_line_regex=^[[:blank:]]+\\{$
unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$

under the [settings] section (+ restart geany). Please let me know if
it works (but also in the opposite case ;-).

Jiri


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

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


Re: [Geany-devel] [PATCH 14/19] Rewrite tab switching queue

2010-09-16 Thread Jiří Techet
On Thu, Sep 16, 2010 at 17:52, Nick Treleaven
nick.trelea...@btinternet.com wrote:
 On Wed, 15 Sep 2010 21:34:52 +0200
 Jiří Techet tec...@gmail.com wrote:

  Thanks, I'd like to commit this now. I realize it's been a while, but
  the patch doesn't apply cleanly and I can't see any commits since that
  would have caused conflicts. Any chance you could update and resubmit
  please?

 Hi Nick,

 no problem, I have just rebased all my patches on top of mainline.
 This particular patch is attached.

 Thanks, but still no joy. The problem is these 2 hunks:

 @@ -599,7 +599,7 @@ static void on_document_close(GObject *obj, 
 GeanyDocument *doc)
       {
               GeanyDocument *last_doc;

 -             last_doc = g_queue_peek_head(mru_docs);
 +             last_doc = g_queue_peek_nth(mru_docs, 1);

               if (DOC_VALID(last_doc)  document_get_current() == doc)
               {
 @@ -607,8 +607,10 @@ static void on_document_close(GObject *obj, 
 GeanyDocument *doc)
                               document_get_notebook_page(last_doc));
               }
               g_queue_remove(mru_docs, doc);
 -
 -             g_idle_add(on_idle_close, NULL);
 +             /* this prevents the pop up window from showing when there's a 
 single
 +              * document */
 +             if 
 (gtk_notebook_get_n_pages(GTK_NOTEBOOK(main_widgets.notebook)) == 2)
 +                     g_queue_clear(mru_docs);
       }
  }

 I haven't been able to work out where they apply to. It didn't seem
 that a conflict had been introduced since your first patch for this
 code, but maybe I'm missing something.

I see, the patch depends on the When closing tab, return to the
document at the top of the MRU list commit. This is actually a commit
I'd really like to see in geany so even though I could make the patch
independent of this commit, I would like both to be applied in which
case their separation doesn't make sense.

Please see the attached files. First apply tab_closing.patch and then
tab_switching.patch. Everything should apply cleanly now.

Jiri


 You can find the remaining pending
 patches under for_review3 branch here:

 http://gitorious.org/~techy/geany/gproject-geany

 If you wish me to resubmit them by email, just tell me - I would

 Thanks - no need to resend. I can download the patches.

 really like to see the patches extending geany's API to be a part of
 mainline so my gproject plugin would not depend on patched geany and
 could be moved among other plugins repository.

 I've applied some this afternoon, will get through them soon hopefully.

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

diff --git a/src/keybindings.c b/src/keybindings.c
index 4cf2992..0d227c5 100644
--- a/src/keybindings.c
+++ b/src/keybindings.c
@@ -597,7 +597,17 @@ static void on_document_close(GObject *obj, GeanyDocument *doc)
 {
 	if (! main_status.quitting)
 	{
+		GeanyDocument *last_doc;
+
+		last_doc = g_queue_peek_head(mru_docs);
+
+		if (DOC_VALID(last_doc)  document_get_current() == doc)
+		{
+			gtk_notebook_set_current_page(GTK_NOTEBOOK(main_widgets.notebook),
+document_get_notebook_page(last_doc));
+		}
 		g_queue_remove(mru_docs, doc);
+
 		g_idle_add(on_idle_close, NULL);
 	}
 }
diff --git a/src/notebook.c b/src/notebook.c
index a1d10bd..0a4af68 100644
--- a/src/notebook.c
+++ b/src/notebook.c
@@ -551,15 +551,6 @@ notebook_tab_close_clicked_cb(GtkButton *button, gpointer user_data)
 /* Always use this instead of gtk_notebook_remove_page(). */
 void notebook_remove_page(gint page_num)
 {
-	gint curpage = gtk_notebook_get_current_page(GTK_NOTEBOOK(main_widgets.notebook));
-
-	/* Focus the next page, not the previous */
-	if (curpage == page_num  file_prefs.tab_order_ltr)
-	{
-		gtk_notebook_set_current_page(GTK_NOTEBOOK(main_widgets.notebook), curpage + 1);
-	}
-
-	/* now remove the page (so we don't temporarily switch to the previous page) */
 	gtk_notebook_remove_page(GTK_NOTEBOOK(main_widgets.notebook), page_num);
 
 	tab_count_changed();
diff --git a/src/keybindings.c b/src/keybindings.c
index 0d227c5..3d54cd0 100644
--- a/src/keybindings.c
+++ b/src/keybindings.c
@@ -562,17 +562,12 @@ static void init_default_kb(void)
 }
 
 
-/* before the tab changes, add the current document to the MRU list */
-static void on_notebook_switch_page(void)
+static void update_mru_docs_head(GeanyDocument *doc)
 {
-	GeanyDocument *old = document_get_current();
-
-	/* when closing current doc, old is NULL.
-	 * Don't add to the mru list when switch dialog is visible. */
-	if (old  !switch_in_progress)
+	if (doc)
 	{
-		g_queue_remove(mru_docs, old);
-		g_queue_push_head(mru_docs, old);
+		g_queue_remove(mru_docs, doc);
+		g_queue_push_head(mru_docs, doc);
 
 		if (g_queue_get_length(mru_docs)  MAX_MRU_DOCS)
 			g_queue_pop_tail(mru_docs);
@@ -580,16 +575,21 @@ static void on_notebook_switch_page(void)
 }
 
 
-/* 

Re: [Geany-devel] editor context menu - Re: Search submenu for editor popup menu

2010-09-16 Thread Jiří Techet
On Thu, Sep 16, 2010 at 13:57, Nick Treleaven
nick.trelea...@btinternet.com wrote:
 On Thu, 16 Sep 2010 09:54:09 +1000
 Lex Trotman ele...@gmail.com wrote:

  2. let the user pick say four most used top level commands since we
  are *never* going to agree on them.  Use a simplified version of the
  customise toolbar dialog.
 
  Personally I don't think it's worth doing this. Put the most useful
  things at toplevel, everything else in submenus.

 Ah but whats the most useful?

 Things which are useful for the largest number of users. There is also
 an issue of letting new users discover some useful things easily that
 they might not know Geany does.

  I *never* use insert comments from the popup and rarely from the menu
 (changelog mostly) so for me having any insert comments in the popup
 is a waste of space.

 Which is why a single Insert submenu would be better.

 I'm not suggesting its required, but if someone out there has the time
 to implement it this would remove all the disagreements :-)

 Is it so bad to solve the disagreements using submenus?

 This avoids maintenance and code complexity of popup configurability,
 which I predict isn't going to be pretty. C is not a good GUI language.


Where I really see an advantage of having the context menu
customisable are plugin actions. With my gproject plugin and my
not-publicly-released ctags plugin I also added several items at the
top of the context menu (plus separators). I can imagine that if
several plugins do a similar thing, the context menu gets pretty messy
(someone will put the new items to the top, someone to the bottom,
someone will use separators, someone not, ...) Also the menu starts
growing even if the user doesn't really use the context menu item of
the given plugin.

This is why I really like the Lex's idea of having a fixed set of
items in the menu that are always present (possibly containing
submenus) and a variable set of configurable items. If the
configurable items can be arbitrary items from the keybindings list,
the plugins won't have to add their own items into the context menu
and the user can only pick those he wishes to be present. It's not
necessary to have submenus in the customisable part of the menu - a
plain list of items would be fine. By default the variable list could
also contain the questionable entries that someone wishes to be
present in the menu and someone not. Those who don't want to have them
can just remove them if they wish.

Of course this would require some work...

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


Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)

2010-09-16 Thread Thomas Martitz

 On 16.09.2010 22:17, Jiří Techet wrote:

I have just re-tested it again and it works on my machine (I have
forgotten one trace in the code - that's what you see in the console).
A quick question: have you read the commit log?


I admit I didn't because it looked so long and I was tired :)


  This means that in order to make it work e.g. for C, you have to edit

~/.config/geany/filedefs/filetypes.c

(or the corresponding file under /usr/local/share/geany) and add

indent_next_line_regex=^.*\\{[[:blank:]]*$
unindent_this_line_regex=^[[:blank:]]*\\}$
indent_this_line_regex=^[[:blank:]]+\\{$
unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$

under the [settings] section (+ restart geany). Please let me know if
it works (but also in the opposite case ;-).





I see. I assumed it would default to how it works in mainline.

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


Re: [Geany-devel] [Patch] : On closing the last tab create new untitled document.

2010-09-16 Thread Erik de Castro Lopo
Nick Treleaven wrote:

 On Thu, 16 Sep 2010 08:32:05 +1000
 Erik de Castro Lopo mle+to...@mega-nerd.com wrote:
 
Well, the responses are all positive. But I don't think that
keybindings.c is the best place for this code. What about writing it
as an idle callback from document_remove_page?
   
   Actually, doesn't even need a callback. Attached patch moves
   the code I initially had in keybindings.c to the end of the
   document_remove_page() function in document.c.
  
  Actually attached the patch this time.
 
 Haven't tested, but seems that this would leave a prepended new
 document when loading a project session. It probably does need
 the idle callback.

Ok, I'll have a look. I actually don't use project sessions
so I'll have to have a play around.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)

2010-09-16 Thread Lex Trotman
On 17 September 2010 06:17, Jiří Techet tec...@gmail.com wrote:
 On Thu, Sep 16, 2010 at 19:27, Thomas Martitz
 thomas.mart...@student.htw-berlin.de wrote:
  On 16.09.2010 02:23, Lex Trotman wrote:

 Hi Jiri,

 I couldn't get this to work at all, it printed calling indent this
 line all the time but didn't indent :-(

 I only had half an hour so I couldn't investigate much.


 I have the same experience. Auto-indentation doesn't seem to work anymore
 (e.g. when hitting enter after on a line that ends with {, or when typing
 }).

 I have just re-tested it again and it works on my machine (I have
 forgotten one trace in the code - that's what you see in the console).
 A quick question: have you read the commit log?

    This patch makes it possible to specify several regex patterns for every
    filetype which determine under what condition the indentation is performed.
    The pattern variables are specified under the [settings] section of the
    given filetype and their value is the regex to be used. The variables are
    as follows:

    * indent_this_line_regex - the match is performed after every keystroke
      and if the regex matches, the indentation is performed on the current
      line
    * indent_next_line_regex - the match is performed only when enter is
      pressed. The indentation is applied on the next line
    * unindent_this_line_regex - like indent_this_line_regex but
 unindents instead
    * unindent_next_line_regex - like indent_next_line_regex but indents 
 instead

    Comments and strings are detected from the lexer so these can be ignored
    inside the patterns. For instance these are very basic rules for GNU
    indent style:

    indent_next_line_regex=^.*\\{[[:blank:]]*$
    unindent_this_line_regex=^[[:blank:]]*\\}$
    indent_this_line_regex=^[[:blank:]]+\\{$
    unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$

Yes, I read the instructions (rare I admit) and I copied these regexen.

I'll see if I get time to look at it some more today or tomorrow.

Note that unless you are going to add the regexes to all filetypes
then Geany still needs to behave as it currently does when there is no
filetype regex(es).

Cheers
Lex


    By commenting-out the last two lines you get ANSI indentation style.
    If you replace \\{ and \\} with begin and end, respectively, you
    get analogous rules for pascal. Notice the double-escaping of { and } -
    the first escape sequence is for the keyfile ini format (so for the
    regex itself \\ becomes \).

 This means that in order to make it work e.g. for C, you have to edit

 ~/.config/geany/filedefs/filetypes.c

 (or the corresponding file under /usr/local/share/geany) and add

 indent_next_line_regex=^.*\\{[[:blank:]]*$
 unindent_this_line_regex=^[[:blank:]]*\\}$
 indent_this_line_regex=^[[:blank:]]+\\{$
 unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$

 under the [settings] section (+ restart geany). Please let me know if
 it works (but also in the opposite case ;-).

 Jiri


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

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

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


Re: [Geany-devel] editor context menu - Re: Search submenu for editor popup menu

2010-09-16 Thread Lex Trotman
On 16 September 2010 21:57, Nick Treleaven
nick.trelea...@btinternet.com wrote:
 On Thu, 16 Sep 2010 09:54:09 +1000
 Lex Trotman ele...@gmail.com wrote:

  2. let the user pick say four most used top level commands since we
  are *never* going to agree on them.  Use a simplified version of the
  customise toolbar dialog.
 
  Personally I don't think it's worth doing this. Put the most useful
  things at toplevel, everything else in submenus.

 Ah but whats the most useful?

 Things which are useful for the largest number of users.

A pessimistic interpretation of this is: If its not C we're not interested :-)

There is also
 an issue of letting new users discover some useful things easily that
 they might not know Geany does.

Discovery should be in the main menus that are always visible, not in
popups which are hidden.


  I *never* use insert comments from the popup and rarely from the menu
 (changelog mostly) so for me having any insert comments in the popup
 is a waste of space.

 Which is why a single Insert submenu would be better.

Yes, erm I thought thats what I proposed and below you were proposing
to also have insert(s) in the top level, my misunderstanding.


 I'm not suggesting its required, but if someone out there has the time
 to implement it this would remove all the disagreements :-)

 Is it so bad to solve the disagreements using submenus?

It doesn't solve which commands go in the top level of the popup for
greatest convenience, which was the only bit I was suggesting as
configurable.


 This avoids maintenance and code complexity of popup configurability,
 which I predict isn't going to be pretty. C is not a good GUI language.

Too true, so make it manually edited configuration for now.


  3. pack the rest in submenus.
 
  format  format submenu as now
 
  What about Commands - at least half of these are context related.
 
  insert  insert submenu including the insert comments
 
  I think at least me and Enrico use insert comments a lot, we'd like it
  to be toplevel. The other insert items could maybe be in a submenu
  (also insert alt whitespace). This would be like having Go to Tag
  Definition in toplevel but Go to Tag Declaration in a submenu as it's
  less common.

 And I of course use the tool differently so I don't want any inserts

 Did you see my Insert submenu reply?

As I said above, I read this as implying you also wanted insert
item(s) in the toplevel, not just in the submenu.


 and use go to declaration much more than go to definition due to the
 language I use most :-).

 Correct me if wrong, but Go to declaration is only needed for function
 prototypes and extern declarations, no?

For C, for C++ the function declaration is part of the class
declaration and is separate from the definition.  The class
declaration has more information and is used much more often than the
prototype/extern declaration is in C.

 The feature is only useful for
 C/C++, not for most users. So having to find it in the proposed popup
 Search submenu is acceptable, no?

Well, if goto definition is in the top level then I'd say no :-) it
needs to be the other way round for C++ users.  And I would have
thought that there were other languages that made the distinction
between declarations and definitions, not just C/C++.


 For all user names : [insert name here] uses it differently again so
 almost no one is fully happy with a fixed menu.

 As mentioned above, I'm not trying to force my preferences on anyone.
 I'm trying to find a good default that is reasonable (but not ideal)
 for everyone.

And I'm trying to suggest that it would be better for users to be able
to pick their own ideal.

It may be that no one who is interested has enough time to implement
it, even without a GUI, but if we don't ask we won't get :-).

Once at least some configuration is available then things like Jiri's
suggestion become possible as further extensions.

Cheers
Lex


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

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