Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
Hi,
I know this is a more than one year old discussion, but I was messing
with a very similar thing a few minutes ago when wanting to add
autoindent support for SH.
Le 16/09/2010 22:17, Jiří Techet a écrit :
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 ;-).
First, note that I wasn't able to find the patch, so I'm only guessing
from reading the thread and from my own (much less complete) attempt.
So. This looks pretty good for line-based indents (but not brace match
:(), but I ran into a really annoying problem with SH:
SH should indent after then, do, etc. and unindent fi, esac,
etc. The problem is that you expect the fi line to be unindented
(e.g. use unindent_this_line), but if you type file for example, it'd
wrongly unindent that line too!
I thought about unindenting the previous line when entering the \n, but
this isn't a real solution either since re-adding a newline after a well
indented line would unindent it again. Crap.
So I haven't yet found a sensible solution for this problem -- which
wouldn't apply for '}' since it's very unlikely it's part of a bigger
word -- and would like to know it anybody got super clever ideas, or how
other editors you know handle this.
This said, I really like the idea of configurable indentation rules that
could handle languages like SH, Pascal, Ruby, Ada, etc. without the need
to hard-code it.
Regards,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
On Sun, 04 Dec 2011 19:22:55 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 04/12/2011 14:44, Dimitar Zhekov a écrit :
It turned out to be quite easy, because the two meanings are actualy
used separately...
Great!
A few comments:
* I better see the new prefs under the [serach] group, with
pref_main_ prefix stripped;
Moved them just above pref_search_current_file_dir and removed
main_. Not sure about the pref_search_ though. All [search]
settings have a dialog prefix or infix, and pref_search_ looks to me
like Preferences dialog, Search section. If that's not the case,
please rename them as you see fit.
The compatibility code became a bit worse.
* The GeanySearchPrefs struct change breaks the plugin ABI since it
changes the offset of the use_current_word field that is in the API
[1]. Since the prefs are not a whole anymore, just put one in place of
suppress_dialogs and add the other somewhere after use_current_word
(the only field in the API).
suppress_dialogs - always_wrap, hide_find_dialog at end.
--
E-gards: Jimmy
From 15fa8c054cb8f620d9b28a348d01649cd7c37f1e Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov dimitar.zhe...@gmail.com
Date: Mon, 5 Dec 2011 21:24:33 +0200
Subject: [PATCH] split always wrap search and hide find dialog pref into
always wrap search and hide find dialog
---
geany.glade | 26 +++---
src/document.c |2 +-
src/interface.c | 19 +--
src/keyfile.c | 14 --
src/search.c|8 +---
src/search.h|3 ++-
6 files changed, 56 insertions(+), 16 deletions(-)
diff --git a/geany.glade b/geany.glade
index ba18b6f..4037970 100644
--- a/geany.glade
+++ b/geany.glade
@@ -3841,11 +3841,31 @@
property name=spacing0/property
child
-widget class=GtkCheckButton id=check_ask_suppress_search_dialogs
+widget class=GtkCheckButton id=check_always_wrap_search
property name=visibleTrue/property
- property name=tooltip translatable=yesAlways wrap search around the document and hide the Find dialog after clicking Find Next/Previous/property
+ property name=tooltip translatable=yesAlways wrap search around the document/property
property name=can_focusTrue/property
- property name=label translatable=yesAlways wrap search and hide the Find dialog/property
+ property name=label translatable=yesAlways wrap search/property
+ property name=use_underlineTrue/property
+ property name=reliefGTK_RELIEF_NORMAL/property
+ property name=focus_on_clickTrue/property
+ property name=activeFalse/property
+ property name=inconsistentFalse/property
+ property name=draw_indicatorTrue/property
+/widget
+packing
+ property name=padding0/property
+ property name=expandFalse/property
+ property name=fillFalse/property
+/packing
+ /child
+
+ child
+widget class=GtkCheckButton id=check_hide_find_dialog
+ property name=visibleTrue/property
+ property name=tooltip translatable=yesHide the Find dialog after clicking Find Next/Previous/property
+ property name=can_focusTrue/property
+ property name=label translatable=yesHide the Find dialog/property
property name=use_underlineTrue/property
property name=reliefGTK_RELIEF_NORMAL/property
property name=focus_on_clickTrue/property
diff --git a/src/document.c b/src/document.c
index dbc1e39..ad437da 100644
--- a/src/document.c
+++ b/src/document.c
@@ -1939,7 +1939,7 @@ gint document_find_text(GeanyDocument *doc, const gchar *text, const gchar *orig
}
/* we searched only part of the document, so ask whether to wraparound. */
- if (search_prefs.suppress_dialogs ||
+ if (search_prefs.always_wrap ||
dialogs_show_question_full(parent, GTK_STOCK_FIND, GTK_STOCK_CANCEL,
_(Wrap search and find again?), _(\%s\ was not found.), original_text))
{
diff --git a/src/interface.c b/src/interface.c
index ce9fbff..126e794 100644
--- a/src/interface.c
+++ b/src/interface.c
@@ -2574,7 +2574,8 @@ create_prefs_dialog (void)
GtkWidget *frame36;
GtkWidget *alignment39;
GtkWidget *vbox36;
- GtkWidget *check_ask_suppress_search_dialogs;
+ GtkWidget *check_always_wrap_search;
+ GtkWidget *check_hide_find_dialog;
GtkWidget *check_search_use_current_word;
GtkWidget *check_fif_current_dir;
GtkWidget *label215;
@@ -3195,10 +3196,15 @@ create_prefs_dialog (void)
gtk_widget_show (vbox36);
gtk_container_add (GTK_CONTAINER (alignment39), vbox36);
- check_ask_suppress_search_dialogs = gtk_check_button_new_with_mnemonic (_(Always wrap search and hide the Find dialog));
- gtk_widget_show (check_ask_suppress_search_dialogs);
- gtk_box_pack_start (GTK_BOX (vbox36), check_ask_suppress_search_dialogs, FALSE, FALSE, 0);
- gtk_tooltips_set_tip (tooltips, check_ask_suppress_search_dialogs, _(Always wrap search around the document and hide the Find dialog after clicking Find
Re: [Geany-devel] Default search behavior is irritating
On Mon, 5 Dec 2011 03:21:45 +0800 Nathan Broadbent nathan@gmail.com wrote: 2009-10-14 05:49:13 ntrel: I suppose we could make the option 'Always wrap' and then change the dialog 'close' checkbox to apply to all actions. Sound OK Enrico? 2009-10-21 10:30:46 eht16: Nick, yes, sounds good. I'm glad they didn't make it. Sounds good, technically, but as Colomban pointed out, it's one thing to close the dialog after finding/marking all matches (very likely), and another to close it after the first or subsequent Next/Previous find. I'm a bit tired of the debate though, so I'm happy to just apply Dimitar's patch and close all of these feature request tickets :) You'll need to re-check the prefs after the patch is officially applied, they'll be in another group and renamed. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
Le 05/12/2011 20:27, Dimitar Zhekov a écrit : On Sun, 04 Dec 2011 19:22:55 +0100 Colomban Wendling lists@herbesfolles.org wrote: Le 04/12/2011 14:44, Dimitar Zhekov a écrit : It turned out to be quite easy, because the two meanings are actualy used separately... Great! A few comments: * I better see the new prefs under the [serach] group, with pref_main_ prefix stripped; Moved them just above pref_search_current_file_dir and removed main_. Not sure about the pref_search_ though. All [search] settings have a dialog prefix or infix, and pref_search_ looks to me like Preferences dialog, Search section. If that's not the case, please rename them as you see fit. Well, I see many prefs are prefixed with pref_*_, so it's fine. And it's not like it's that important either. The compatibility code became a bit worse. * The GeanySearchPrefs struct change breaks the plugin ABI since it changes the offset of the use_current_word field that is in the API [1]. Since the prefs are not a whole anymore, just put one in place of suppress_dialogs and add the other somewhere after use_current_word (the only field in the API). suppress_dialogs - always_wrap, hide_find_dialog at end. Applied, thanks! Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Mon, Dec 5, 2011 at 19:30, Colomban Wendling
lists@herbesfolles.org wrote:
Hi,
I know this is a more than one year old discussion, but I was messing
with a very similar thing a few minutes ago when wanting to add
autoindent support for SH.
Le 16/09/2010 22:17, Jiří Techet a écrit :
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 ;-).
First, note that I wasn't able to find the patch, so I'm only guessing
from reading the thread and from my own (much less complete) attempt.
It doesn't apply to current trunk anyway - I've discarded it because
it would need major update but more importantly, there was one
limitation I wanted to address.
The problem was that a single line could be indented several times
with single regular expression. Imagine a code like
if (foo)
{
if (bar)
{
baz();
}
}
Now imagine that you put cursor just behind the } following baz(); and
press backspace to delete it. Now if you press } at this position
again, it gets unindented again so you get
if (foo)
{
if (bar)
{
baz();
}
}
From the editors I tested, it seems they remember for which line
indentation was performed and don't perform it again. This means to
have some per-line flag which indicates this state (e.g.
NOT_INDENTABLE, INDENTABLE). When a file is loaded, all non-empty
lines would be marked as NOT_INDENTABLE and every empty line as
INDENTABLE (the newly created empty lines too). A line would stay in
INDENTABLE state even after you start typing some text. INDENTABLE
state would change to NOT_INDENTABLE under each of the following
conditions:
1. The line matches a regex - in this case is indented and shouldn't
be indented any more
2. The line is not empty, matches a regex and enter is pressed (you
have finished editing the line and don't want it to be indented when
you modify it later)
Now this approach requires some per-line data to be stored - is it
possible with Scintilla?
So. This looks pretty good for line-based indents (but not brace match
:(), but I ran into a really annoying problem with SH:
SH should indent after then, do, etc. and unindent fi, esac,
etc. The problem is that you expect the fi line to be unindented
(e.g. use unindent_this_line), but if you type file for example, it'd
wrongly unindent that line too!
I thought about unindenting the previous line when entering the \n, but
this isn't a real
Re: [Geany-devel] Default search behavior is irritating
On 12/05/2011 01:27 PM, Colomban Wendling wrote: Applied, thanks! Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*. I say we either delete the gtkbuilder branch or merge it into master. It's basically working fine for along time and I don't think anyone is testing it since it's not in master. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
On 12/05/2011 05:52 PM, Lex Trotman wrote: On Tue, Dec 6, 2011 at 12:18 PM, Matthew Brushmbr...@codebrainz.ca wrote: On 12/05/2011 01:27 PM, Colomban Wendling wrote: Applied, thanks! Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*. I say we either delete the gtkbuilder branch or merge it into master. It's basically working fine for along time and I don't think anyone is testing it since it's not in master. I agree, why hasn't it been committed already? Because only a few people have tested it and we don't have a `devel` branch for unstable code :) If no one has a reasonable objection by the end of the week I suggest you commit it Matthew. I'll have to free up some time to reconvert the Glade 2 file again (biggest part of the job). It might actually take me less time (and agony) to revert this search patch and manually re-apply it ontop of the gtkbuilder branch before merging it into master. There was a lot of little tedious things in converting the Glade 2 file to GtkBuilder and I'd really rather not go through that again (it took weeks of testing to catch all the little subtle bugs and changes). Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Additions to Addon plugin
Hi all, I've been working on an addition to the Addons plugin that gives a couple options for wrapping text with characters. It adds two check boxes to the plugin's preferences, one to enable auto wrapping and one to enable keybinded wrapping. Auto wrapping automatically wraps selected text as soon as a certain character is pressed (apostrophe, quote, back tick, left parenthesis, or left square/curly bracket) and keybinded wrapping provides eight keybindings which correspond to eight user-set pairs of characters, which will surround selected text when the keybinding is pressed. The code (two new files and modified addons.c) is here - https://github.com/pzoxiuv/Geany-Plugins/tree/master/geany-plugins-0.21.1/addons/src. Is there any way this could be eventually added to the Addons plugin? (And thanks Dimitar Zhekov for the advice you gave me in my previous thread, it was very helpful). Cheers, Alex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
On 12/05/2011 05:18 PM, Matthew Brush wrote: On 12/05/2011 01:27 PM, Colomban Wendling wrote: Applied, thanks! Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*. FWIW, it didn't actually take too long to update the gtkbuilder branch. Instead of re-converting the whole Glade 2 file I just manually added the changes to the new geany.glade using Glade 3, comparing the changes in the diff (since I don't have a patched Glade 2 running anymore) and then I added that in with the merge commit. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
[...] First, note that I wasn't able to find the patch, so I'm only guessing from reading the thread and from my own (much less complete) attempt. I'm afraid that if I had the patch it is on my broken hard drive :-S And anyway we never got it to work satisfactorily. So. This looks pretty good for line-based indents (but not brace match :(), but I ran into a really annoying problem with SH: SH should indent after then, do, etc. and unindent fi, esac, etc. The problem is that you expect the fi line to be unindented (e.g. use unindent_this_line), but if you type file for example, it'd wrongly unindent that line too! I thought about unindenting the previous line when entering the \n, but this isn't a real solution either since re-adding a newline after a well indented line would unindent it again. Crap. So I haven't yet found a sensible solution for this problem -- which wouldn't apply for '}' since it's very unlikely it's part of a bigger word -- and would like to know it anybody got super clever ideas, or how other editors you know handle this. This said, I really like the idea of configurable indentation rules that could handle languages like SH, Pascal, Ruby, Ada, etc. without the need to hard-code it. WARNING, complex topic, big post :) Quick summary of ones I know: Emacs has language specific elisp, for C: It analyzes the line to determine its syntactic symbol(s) (the kind of language construct it's looking at) and its anchor position (the position earlier in the file that CC Mode will indent the line relative to). The anchor position might be the location of an opening brace in the previous line, for example. See Syntactic Analysis. It looks up the syntactic symbol(s) in the configuration to get the corresponding offset(s). The symbol +, which means “indent this line one more level” is a typical offset. CC Mode then applies these offset(s) to the anchor position, giving the indentation for the line. The different sorts of offsets are described in c-offsets-alist. And it admits that even then it gets it wrong sometimes :( Eclipse and Netbeans also use parser results for the indent guidance. I don't think parsing the source for indent guidance is in the Geany light and small spirit, so I reject that. Instead I propose the following correct most of the time but simple option based on a combination of Jiri's and Emacs' methods: 1. Each line N has an initial indentation which is the indentation of line N-1 plus the increments/decrements for all matches to indent next line regexes that occur in liine N-1. (Note that each regex has a signed count of columns to indent/exdent) 2. The line N final indentation is the initial indentation adjusted by the increments/decrements for all matches to indent this line regexes that occur in line N Note that this is the indent, not a delta like Jiri's algorithm. It is therefore stable no matter how many times it is calculated. The question is then when to calculate and apply this indent, clearly when a line is first created by enter the indent should be applied. But what about when line content changes? Should we: 1. calculate the indent each change, and then ripple that through the file 2. calculate the indent each change and only apply it to this line 3. calculate and apply the indent to lines N and N-1 only on new line or user command 4. calculate and apply the indent on user command Option 1 is rejected because it is expensive and it will destroy manually adjusted indentation when editing an existing line and because indentation can change as you type causing distracting effects (happens with some Emacs indentation styles) Option 2 is rejected for the same reasons Option 4 is rejected because auto new line indent is really the minimum required to be called auto indentation So that leaves option 3. The upside is that new lines get a sensible indentation automatically, the downside is that lines that should be unindented won't be until enter or user command. I have used another editor that worked this way and after a while I became used to it. Note that editing an existing line won't destroy manual indentation unless you tell it to or create a new line after. The settings are two (indent this line, indent next line) lists of pairs of a regex and a signed count. These settings are per language so they should come from the filetype files. A final thought, as there is now an apply auto indent command, if there is a selection the auto indent should ripple through the whole selection. Cheers Lex Regards, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
1. calculate the indent each change, and then ripple that through the file 2. calculate the indent each change and only apply it to this line 3. calculate and apply the indent to lines N and N-1 only on new line or user command 4. calculate and apply the indent on user command Option 1 is rejected because it is expensive and it will destroy manually adjusted indentation when editing an existing line and because indentation can change as you type causing distracting effects (happens with some Emacs indentation styles) Option 2 is rejected for the same reasons Option 4 is rejected because auto new line indent is really the minimum required to be called auto indentation So that leaves option 3. The upside is that new lines get a sensible indentation automatically, the downside is that lines that should be unindented won't be until enter or user command. I have used another editor that worked this way and after a while I became used to it. Note that editing an existing line won't destroy manual indentation unless you tell it to or create a new line after. Hello, Good auto-indentation is one of the last things I'm missing after my switch from Gedit to Geany. It was something that was handled really well by the 'Smart Indent' plugin. I would like to share a short video (1:24) of the indentation behavior that I grew accustomed to: http://vimeo.com/1890098 This style of auto-indentation requires Option 1 or 2 (calculate for each change), because it unindents the 'end', 'elsif' and 'else' keywords as soon as their last characters are pressed. I did find this behavior very useful, even though I admit that it would sometimes destroy my manual indentation. You might also find it interesting to browse the code of this plugin here: https://github.com/gmate/gmate/blob/master/plugins/gedit2/smart_indent/smart_indent/__init__.py At least, it contains some good indent regexs for different languages. I might disagree that Options 1 2 are expensive. The gedit plugin even defines a very limited set of 'unindent_keystrokes', so the 'unindent' regex is only executed when one of these keys are pressed. For C, it's just :, and for Ruby, it's edfn. I also disagree that it's distracting, because I grew accustomed to it very quickly. So if it could be written in a way that supports the behavior in the video above, I would be really grateful. But no problem if not -- like you say, I can get used to any behavior after using it for a while. Thanks very much for your time! Nathan B ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
