Hi all,
I've got a file of C code which for part of the file has an extra single space indent on the left hand side. To fix this I'm trying to do a regex search for "^ " and replace it with "" (ie empty string). Unfortunately, this search/replace removes all space indentation which is not really what I expect.
Any clues on getting this right? Is this a bug?
Erik
On 29 September 2010 10:30, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Hi all,
I've got a file of C code which for part of the file has an extra single space indent on the left hand side. To fix this I'm trying to do a regex search for "^ " and replace it with "" (ie empty string). Unfortunately, this search/replace removes all space indentation which is not really what I expect.
Any clues on getting this right? Is this a bug?
What version are you using?
Cheers Lex
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Lex Trotman wrote:
On 29 September 2010 10:30, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Hi all,
I've got a file of C code which for part of the file has an extra single space indent on the left hand side. To fix this I'm trying to do a regex search for "^ " and replace it with "" (ie empty string). Unfortunately, this search/replace removes all space indentation which is not really what I expect.
Any clues on getting this right? Is this a bug?
What version are you using?
SVN HEAD.
Erik
On 29 September 2010 11:09, Lex Trotman elextr@gmail.com wrote:
On 29 September 2010 10:30, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Hi all,
I've got a file of C code which for part of the file has an extra single space indent on the left hand side. To fix this I'm trying to do a regex search for "^ " and replace it with "" (ie empty string). Unfortunately, this search/replace removes all space indentation which is not really what I expect.
Any clues on getting this right? Is this a bug?
What version are you using?
Cheers Lex
Actually having a bit of a think, it can't work since after replacing the first space with nothing it will find another space at the same place and remove it until it removes all the spaces at the start of the line before moving on to the next.
So its working right, just not what you want :-) & I'm not sure how to do it.
Cheers Lex
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Le 29/09/2010 03:16, Lex Trotman a écrit :
On 29 September 2010 11:09, Lex Trotman elextr@gmail.com wrote:
On 29 September 2010 10:30, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Hi all,
I've got a file of C code which for part of the file has an extra single space indent on the left hand side. To fix this I'm trying to do a regex search for "^ " and replace it with "" (ie empty string). Unfortunately, this search/replace removes all space indentation which is not really what I expect.
Any clues on getting this right? Is this a bug?
Actually having a bit of a think, it can't work since after replacing the first space with nothing it will find another space at the same place and remove it until it removes all the spaces at the start of the line before moving on to the next.
So its working right, just not what you want :-) & I'm not sure how to do it.
not sure it is "right" -- it already matched ^, so why match it again? -- but it's at least not really surprising. And it's really easy to work around, simply match the whole line: ^ (.*)$ and replace it with the captured data \1 and you're done :)
Regards, Colomban
On 29 September 2010 11:24, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 29/09/2010 03:16, Lex Trotman a écrit :
On 29 September 2010 11:09, Lex Trotman elextr@gmail.com wrote:
On 29 September 2010 10:30, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Hi all,
I've got a file of C code which for part of the file has an extra single space indent on the left hand side. To fix this I'm trying to do a regex search for "^ " and replace it with "" (ie empty string). Unfortunately, this search/replace removes all space indentation which is not really what I expect.
Any clues on getting this right? Is this a bug?
Actually having a bit of a think, it can't work since after replacing the first space with nothing it will find another space at the same place and remove it until it removes all the spaces at the start of the line before moving on to the next.
So its working right, just not what you want :-) & I'm not sure how to do it.
not sure it is "right" -- it already matched ^, so why match it again?
Because it has removed the space it matched, the so its position is back to the start of the line (which matches ^).
-- but it's at least not really surprising. And it's really easy to work around, simply match the whole line: ^ (.*)$ and replace it with the captured data \1 and you're done :)
Good one.
Cheers Lex
Regards, Colomban _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Le 29/09/2010 03:31, Lex Trotman a écrit :
On 29 September 2010 11:24, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 29/09/2010 03:16, Lex Trotman a écrit :
On 29 September 2010 11:09, Lex Trotman elextr@gmail.com wrote:
On 29 September 2010 10:30, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Hi all,
I've got a file of C code which for part of the file has an extra single space indent on the left hand side. To fix this I'm trying to do a regex search for "^ " and replace it with "" (ie empty string). Unfortunately, this search/replace removes all space indentation which is not really what I expect.
Any clues on getting this right? Is this a bug?
Actually having a bit of a think, it can't work since after replacing the first space with nothing it will find another space at the same place and remove it until it removes all the spaces at the start of the line before moving on to the next.
So its working right, just not what you want :-) & I'm not sure how to do it.
not sure it is "right" -- it already matched ^, so why match it again?
Because it has removed the space it matched, the so its position is back to the start of the line (which matches ^).
Yes I agree it is a possible understanding of the thing, but I'm not sure it is "the one".
BTW sed behaves the way Erik wants: sed 's/^ //g' file will only remove the first spaces of every lines, even though the option g is present.
Regards, Colomban
Colomban Wendling wrote:
BTW sed behaves the way Erik wants: sed 's/^ //g' file will only remove the first spaces of every lines, even though the option g is present.
So does Nedit, my text editor of choice from 1995 til a month or two ago :-).
Erik
On 29 September 2010 11:34, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 29/09/2010 03:31, Lex Trotman a écrit :
On 29 September 2010 11:24, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 29/09/2010 03:16, Lex Trotman a écrit :
On 29 September 2010 11:09, Lex Trotman elextr@gmail.com wrote:
On 29 September 2010 10:30, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Hi all,
I've got a file of C code which for part of the file has an extra single space indent on the left hand side. To fix this I'm trying to do a regex search for "^ " and replace it with "" (ie empty string). Unfortunately, this search/replace removes all space indentation which is not really what I expect.
Any clues on getting this right? Is this a bug?
Actually having a bit of a think, it can't work since after replacing the first space with nothing it will find another space at the same place and remove it until it removes all the spaces at the start of the line before moving on to the next.
So its working right, just not what you want :-) & I'm not sure how to do it.
not sure it is "right" -- it already matched ^, so why match it again?
Because it has removed the space it matched, the so its position is back to the start of the line (which matches ^).
Yes I agree it is a possible understanding of the thing, but I'm not sure it is "the one".
BTW sed behaves the way Erik wants: sed 's/^ //g' file will only remove the first spaces of every lines, even though the option g is present.
Yes because sed only operates on a line at a time and g finds all the matches in the line then makes the substitutions, it does not run the substitution multiple times.
Geany does not find all the locations first and then do the replaces, it does find, replace, go to the end of the replacement, repeat until done
The REGEX rules (Perl and POSIX which is pretty canonical :-) require left most longest greedy match, ie the ^ assertion must be tested at the current position first. To do anything else would be non-standard behavior. The REGEX engine doesn't know it has just previously done a replacement with nothing at the current position.
So I would say that the current behavior IS correct, and since Columban has given us an incantation to cover those rare situations where the standard behavior is annoying, there is no need for some non-standard special case to be added.
The only possible change might be to re-phrase "replace all" in the manual and dialog to be "repeat replacement".
Cheers Lex
Regards, Colomban _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Lex Trotman wrote:
So I would say that the current behavior IS correct,
Except that its counter intuitive and different from the behaviour of existing text editors like Nedit and Vim (:%s/^ //g).
Erik
Erik de Castro Lopo wrote:
Lex Trotman wrote:
So I would say that the current behavior IS correct,
Except that its counter intuitive and different from the behaviour of existing text editors like Nedit and Vim (:%s/^ //g).
In fact, Vim says its search and replace should do the same as sed:
http://www.felixgers.de/teaching/emacs/vi_search_replace.html
Erik
On 29 September 2010 12:59, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Erik de Castro Lopo wrote:
Lex Trotman wrote:
So I would say that the current behavior IS correct,
Except that its counter intuitive and different from the behaviour of existing text editors like Nedit and Vim (:%s/^ //g).
In fact, Vim says its search and replace should do the same as sed:
http://www.felixgers.de/teaching/emacs/vi_search_replace.html
If you actually look at the VIM manual http://vimdoc.sourceforge.net/htmldoc/usr_10.html#10.2 you find that the substitute command operates on a line by line basis like sed. So the g option searches the line, substitutes all the matches and then goes on to the next line.
Geany doesn't have a substitute command and doesn't work line by line, it repeats find/replace.
Perhaps, as you say, it should offer a substitute command that works line by line as well, but "someone has to do it" (tm) and "patches are welcome" (tm) (that right Frank ;-).
Cheers Lex
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Lex Trotman wrote:
Perhaps, as you say, it should offer a substitute command that works line by line as well, but "someone has to do it" (tm) and "patches are welcome" (tm) (that right Frank ;-).
Thats a better answer than your previous one :-).
Erik
On 29 September 2010 15:05, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
Perhaps, as you say, it should offer a substitute command that works line by line as well, but "someone has to do it" (tm) and "patches are welcome" (tm) (that right Frank ;-).
Thats a better answer than your previous one :-).
Oh, there is rarely any objection to contributions, that goes without saying.
I was noting that the current behavior is not a bug (since it behaves as specified) so it doesn't have to be fixed. nor is a change in behavior necessary (since there is a workaround to the rare "problem") so it doesn't have to be fixed. With limited resources there are far more important things to think about.
I personally don't care if someone changes it (although I think that going back to line by line operation is a step back into the time when whole files would not fit in memory, ah hey lets bring back Teco ;-).
Cheers Lex
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Wed, 29 Sep 2010 16:20:33 +1000 Lex Trotman elextr@gmail.com wrote:
Perhaps, as you say, it should offer a substitute command that works line by line as well, but "someone has to do it" (tm) and "patches are welcome" (tm) (that right Frank ;-).
Thats a better answer than your previous one :-).
Oh, there is rarely any objection to contributions, that goes without saying.
I was noting that the current behavior is not a bug (since it behaves as specified) so it doesn't have to be fixed. nor is a change in behavior necessary (since there is a workaround to the rare "problem") so it doesn't have to be fixed. With limited resources there are far more important things to think about.
Personally I think we shouldn't rematch a replaced start of line. I think this is counter intuitive. Is there a reason why the current behaviour is better?
Anyway, the reason it works as it does was because that was easier to implement.
I personally don't care if someone changes it (although I think that going back to line by line operation is a step back into the time when whole files would not fit in memory, ah hey lets bring back Teco ;-).
Not sure anyone's proposing preventing matching past a line.
Regards, Nick
On 30 September 2010 01:32, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 29 Sep 2010 16:20:33 +1000 Lex Trotman elextr@gmail.com wrote:
Perhaps, as you say, it should offer a substitute command that works line by line as well, but "someone has to do it" (tm) and "patches are welcome" (tm) (that right Frank ;-).
Thats a better answer than your previous one :-).
Oh, there is rarely any objection to contributions, that goes without saying.
I was noting that the current behavior is not a bug (since it behaves as specified) so it doesn't have to be fixed. nor is a change in behavior necessary (since there is a workaround to the rare "problem") so it doesn't have to be fixed. With limited resources there are far more important things to think about.
Personally I think we shouldn't rematch a replaced start of line. I think this is counter intuitive. Is there a reason why the current behaviour is better?
Anyway, the reason it works as it does was because that was easier to implement.
Yes I understood that, as I said the alternative is to implement the "find all and replacel" by proper substitute function which finds the occurrences first then substitutes them. I guess if you can do the internal equivalent of the find all and mark command then just substitute all marked. Actually it'd be nice to have an option for the replacements to be highlighted so I could see the places it made changes I didn't mean (does that often happen to you with change all?? :-)
I still just don't know if its worth the effort.
I personally don't care if someone changes it (although I think that going back to line by line operation is a step back into the time when whole files would not fit in memory, ah hey lets bring back Teco ;-).
Not sure anyone's proposing preventing matching past a line.
I was just commenting on how vim does it (and sed) , but thats not the way Geany should do it. see above.
Cheers Lex
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Lex Trotman wrote:
Yes I understood that, as I said the alternative is to implement the "find all and replacel" by proper substitute function which finds the occurrences first then substitutes them.
<snip>
I still just don't know if its worth the effort.
I consider it worth the effort and will probably come up with a patch some time in the next week.
Erik
On 30 September 2010 10:15, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
Yes I understood that, as I said the alternative is to implement the "find all and replacel" by proper substitute function which finds the occurrences first then substitutes them.
<snip>
I still just don't know if its worth the effort.
I consider it worth the effort and will probably come up with a patch some time in the next week.
Ok, everyone is entitled to make their own call on whats most important to them. Thank you for backing your choice up with implementation effort. If only I could find some time to do so :-(
Cheers Lex
Erik
Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 30 Sep 2010 08:53:27 +1000 Lex Trotman elextr@gmail.com wrote:
Personally I think we shouldn't rematch a replaced start of line. I think this is counter intuitive. Is there a reason why the current behaviour is better?
Anyway, the reason it works as it does was because that was easier to implement.
Yes I understood that, as I said the alternative is to implement the "find all and replacel" by proper substitute function which finds the occurrences first then substitutes them. I guess if you can do the internal equivalent of the find all and mark command then just substitute all marked.
It might be possible to record the last start of line and prevent a rematch that way, avoiding caching.
BTW, you're right that there's more important things to do, but no harm in discussing improvements IMO.
Actually it'd be nice to have an option for the replacements to be highlighted so I could see the places it made changes I didn't mean (does that often happen to you with change all?? :-)
Could be useful, although maybe better if the replacements were listed in the Messages window so you don't have to scroll through the whole document.
Regards, Nick
On 30 September 2010 21:59, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 30 Sep 2010 08:53:27 +1000 Lex Trotman elextr@gmail.com wrote:
Personally I think we shouldn't rematch a replaced start of line. I think this is counter intuitive. Is there a reason why the current behaviour is better?
Anyway, the reason it works as it does was because that was easier to implement.
Yes I understood that, as I said the alternative is to implement the "find all and replacel" by proper substitute function which finds the occurrences first then substitutes them. I guess if you can do the internal equivalent of the find all and mark command then just substitute all marked.
It might be possible to record the last start of line and prevent a rematch that way, avoiding caching.
My problem with any method that effectively changes the way the regex works, is that it would have some more corner cases that will come up later, after all its taken a while for this one to show up.
BTW, you're right that there's more important things to do, but no harm in discussing improvements IMO.
Of course, as improvements that can be done at leisure, not bugs that should be fixed ASAP.
Also, do you think you should be encouraging *me* to be suggesting changes/improvements :-D
Actually it'd be nice to have an option for the replacements to be highlighted so I could see the places it made changes I didn't mean (does that often happen to you with change all?? :-)
Could be useful, although maybe better if the replacements were listed in the Messages window so you don't have to scroll through the whole document.
The problem with listing them is that there is no context, some erroneous changes will be obvious from the change, some won't, so I will be wanting to go to the changed line so I'd expect that the message would act like a compile error and allow click to go to the line.
Cheers Lex
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, 1 Oct 2010 08:49:06 +1000 Lex Trotman elextr@gmail.com wrote:
Actually it'd be nice to have an option for the replacements to be highlighted so I could see the places it made changes I didn't mean (does that often happen to you with change all?? :-)
Could be useful, although maybe better if the replacements were listed in the Messages window so you don't have to scroll through the whole document.
The problem with listing them is that there is no context, some erroneous changes will be obvious from the change, some won't, so I will be wanting to go to the changed line so I'd expect that the message would act like a compile error and allow click to go to the line.
Yes, you could go to the line. I see your point though, that the list might not be useful if the context is important, but there may be enough cases where the line is enough. Not sure yet how the UI would expose this behaviour.
Regards, Nick