When I issue a Find, with regular expression like "[^Q]*Q", Geany behaves strangely: the highlight (the string found) spans many lines. The "[^Q]*" matches as if the lines were joined. (The search is *not* line-based.)
Do you experience the same? Why does geany behave like this? How to alter this behaviour?
Le 31/07/2014 19:52, Péter a écrit :
When I issue a Find, with regular expression like "[^Q]*Q", Geany behaves strangely: the highlight (the string found) spans many lines. The "[^Q]*" matches as if the lines were joined. (The search is *not* line-based.)
Do you experience the same?
Yes
Why does geany behave like this?
For technical reasons, and because although I started some work for line-based RE support, I didn't finish it (yet).
If you're interested in the technical reason, it's quite simple: we use a multiline-capable regex engine and we pass it a pointer to the whole buffer instead of feeding it line-by line -- hence allowing it to perform multi-line matches.
How to alter this behaviour?
First, let's see why it doesn't already do what you want: even though the DOTALL option is not enabled (which means "." won't match a newline), you can match newlines (e.g. with "\n"). But as you use a "not" range (anything but "Q"), and newline are not part of this range (they admittedly aren't "Q"s), they get included.
So, to work this around, use "anything but Q or newline": [^Q\r\n]
Regards, Colomban
On 1 August 2014 04:27, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 31/07/2014 19:52, Péter a écrit :
When I issue a Find, with regular expression like "[^Q]*Q", Geany behaves strangely: the highlight (the string found) spans many lines. The "[^Q]*" matches as if the lines were joined. (The search is *not* line-based.)
Do you experience the same?
Yes
Why does geany behave like this?
For technical reasons, and because although I started some work for line-based RE support, I didn't finish it (yet).
If you're interested in the technical reason, it's quite simple: we use a multiline-capable regex engine and we pass it a pointer to the whole buffer instead of feeding it line-by line -- hence allowing it to perform multi-line matches.
And thats the right thing to do IM(NS)HO.
To make searches anchored to lines you need to explicitly us the anchors ^ and $, and to facilitate this we set MULTILINE mode by default though you can set flags in the regex (?m).
Cheers Lex
How to alter this behaviour?
First, let's see why it doesn't already do what you want: even though the DOTALL option is not enabled (which means "." won't match a newline), you can match newlines (e.g. with "\n"). But as you use a "not" range (anything but "Q"), and newline are not part of this range (they admittedly aren't "Q"s), they get included.
So, to work this around, use "anything but Q or newline": [^Q\r\n]
Regards, Colomban _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Le 01/08/2014 03:00, Lex Trotman a écrit :
On 1 August 2014 04:27, Colomban Wendling lists.ban@herbesfolles.org wrote:
[...]
For technical reasons, and because although I started some work for line-based RE support, I didn't finish it (yet).
If you're interested in the technical reason, it's quite simple: we use a multiline-capable regex engine and we pass it a pointer to the whole buffer instead of feeding it line-by line -- hence allowing it to perform multi-line matches.
And thats the right thing to do IM(NS)HO.
Not really, but it's for sure a useful feature, yet it can be annoying at times.
To be clear, I never wanted to remove multi-line regex support, just add an option for single-line ones.
Regards, Colomban
[...]
And thats the right thing to do IM(NS)HO.
Not really, but it's for sure a useful feature, yet it can be annoying at times.
To be clear, I never wanted to remove multi-line regex support, just add an option for single-line ones.
Yeah, if you have both its fine, multi-line can usually be made to act like per-line, but not the other way round.
Cheers Lex
Regards, Colomban _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Colomban Wendling wrote:
Do you experience the same?
Yes
use "anything but Q or newline": [^Q\r\n]
OK, I accept it.
[^Q\n]*Q works. (Finds only inside one line.)
Lex Trotman wrote:
though you can set flags in the regex (?m).
I did not really succeed to use it. (I found the http://www.geany.org/manual/gtk/glib/glib-regex-syntax.html page.)
Neither of these worked: (?m)[^Q]*Q (?s)[^Q]*Q (?-m)[^Q]*Q (?-s)[^Q]*Q
On 1 August 2014 19:39, Péter peter20@mpp.hu wrote:
Colomban Wendling wrote:
Do you experience the same?
Yes
use "anything but Q or newline": [^Q\r\n]
OK, I accept it.
[^Q\n]*Q works. (Finds only inside one line.)
We were not sure what you were actually trying to achieve, but if this does it then thats ok. :)
Lex Trotman wrote:
though you can set flags in the regex (?m).
I did not really succeed to use it. (I found the http://www.geany.org/manual/gtk/glib/glib-regex-syntax.html page.)
Neither of these worked: (?m)[^Q]*Q (?s)[^Q]*Q (?-m)[^Q]*Q (?-s)[^Q]*Q
The above page says:
Characters that might indicate line breaks are never treated in any special way when matching character classes, whatever line-ending sequence is in use, and whatever setting of the G_REGEX_DOTALL and G_REGEX_MULTILINE options is used. A class such as [^a] always matches one of these characters.
So the [^Q] still matches the newline. Note that unlike some editors, Geany stores the line ends in the buffer like any other character, so it can match like any other character. Hence Colomban's suggestion above to include the newline in the character class you don't want matched.
The multiline flag only affects the anchors (^ and $).
Cheers Lex
-- Péter
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users