Hi,
I saw yesterday a discussion about opening files that ends with something like ":2" [1], and even if it's already fixed, I don't feel that the behavior is neither the best nor the more intuitive.
The current behavior is to: 1) if the file exists, don't try to extract the line/column information from the name 2) otherwise, extract these information without further checks.
That's fine in most cases (who has files that ends with :<number> anyway? [2]) but what if I have a file named "file:1" and I want to open it at line 43? I'd think I just have to type "file:1:43", as I'd have done with any other file. But no, of course, it tries to open "file" at line 1, column 43. Then it's (IMO) quite like you can't open files that ends with :<number> on CLI unless you specify both line and column information (like before the bug was fixed), because the behavior is not the same than with other filenames.
I then would think it's better to do: 1) if the file exists, don't extract line/columns information 2) otherwise, try to strip line information 3) if the file exists, stop here 4) otherwise, try to strip column information from the end [3] 5) if the file exists, stop here 6) otherwise, restore the name that was given, without stripping line and column.
This seems to me to be a better behavior, since it prefers opening an existing file than a non-existing one; and if the file doesn't exist, prefer to keep the full name given. The joined patches implements this (see below).
But OTHO, it makes harder to open "file:0" at line 1 if both "file:0" and "file:0:1" exists: it needs to hack in some way, for example typing "file:0:01" rather than "file:0:1"... Then we may want to complicate the thing a little more and prefer the file that exists with the shorter filename (then given "file:0:1" we would prefer "file" at line 0, column 1 over "file:0" at line 0 over "file:0:1" if all three exists...). If so, I'd be happy to implement it :p
Any thoughts?
About the two patches: * 0001-cli-line-column-prefer-existing-files-2.patch is my original implementation, but as I rewritten it from scratch, it is very different from the original and almost all the code changes, so maybe you don't like it (thought it seems to be 37% faster [4]). * 0001-cli-line-column-prefer-existing-files.patch does the same but only changes a little the current code. It is less "beautiful" IMHO because the design doesn't fit very well what I wanted to do, but the large majority of the code is the same.
Best regards, Colomban
[1] Debain's bug #551358 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551358), even though I think it should be closed... [2] and because of this, perhaps all this email is useless and time-wasting... [3] yes, line/column has to be swapped here, but that's a detail that needlessly complicates the explanation. [4] tested with the modifications, with 3000000 passes over 6 different inputs (34.375s vs 21.677s). Yes, it probably doesn't matter, and yes I like benchmarking useless things.
On 16 August 2010 04:21, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
I saw yesterday a discussion about opening files that ends with something like ":2" [1], and even if it's already fixed, I don't feel that the behavior is neither the best nor the more intuitive.
The current behavior is to:
- if the file exists, don't try to extract the line/column information
from the name 2) otherwise, extract these information without further checks.
That's fine in most cases (who has files that ends with :<number> anyway? [2]) but what if I have a file named "file:1" and I want to open it at line 43? I'd think I just have to type "file:1:43", as I'd have done with any other file. But no, of course, it tries to open "file" at line 1, column 43. Then it's (IMO) quite like you can't open files that ends with :<number> on CLI unless you specify both line and column information (like before the bug was fixed), because the behavior is not the same than with other filenames.
I then would think it's better to do:
- if the file exists, don't extract line/columns information
- otherwise, try to strip line information
- if the file exists, stop here
- otherwise, try to strip column information from the end [3]
- if the file exists, stop here
- otherwise, restore the name that was given, without stripping line
and column.
This seems to me to be a better behavior, since it prefers opening an existing file than a non-existing one; and if the file doesn't exist, prefer to keep the full name given. The joined patches implements this (see below).
But OTHO, it makes harder to open "file:0" at line 1 if both "file:0" and "file:0:1" exists: it needs to hack in some way, for example typing "file:0:01" rather than "file:0:1"... Then we may want to complicate the thing a little more and prefer the file that exists with the shorter filename (then given "file:0:1" we would prefer "file" at line 0, column 1 over "file:0" at line 0 over "file:0:1" if all three exists...). If so, I'd be happy to implement it :p
Any thoughts?
About the two patches:
- 0001-cli-line-column-prefer-existing-files-2.patch is my original
implementation, but as I rewritten it from scratch, it is very different from the original and almost all the code changes, so maybe you don't like it (thought it seems to be 37% faster [4]).
- 0001-cli-line-column-prefer-existing-files.patch does the same but
only changes a little the current code. It is less "beautiful" IMHO because the design doesn't fit very well what I wanted to do, but the large majority of the code is the same.
Best regards, Colomban
[1] Debain's bug #551358 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551358), even though I think it should be closed... [2] and because of this, perhaps all this email is useless and time-wasting... [3] yes, line/column has to be swapped here, but that's a detail that needlessly complicates the explanation. [4] tested with the modifications, with 3000000 passes over 6 different inputs (34.375s vs 21.677s). Yes, it probably doesn't matter, and yes I like benchmarking useless things.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Colomban,
I am not criticising your attempt at improving this, instead I think the whole idea of trying to have the line and column info on the filename is wrong and will NEVER always be right until we make Geany a mind reader (although if its reading my mind it will probably still be wrong :-) because we can't think of all the ways "inventive" programmers will come up with to structure filenames with :nn on the end.
The +line --line and --column options are there to give an unambiguous position and the :line:col capability should be removed.
Just in case it was common I checked vim and emacs documentation and AFAICT neither does it. Emacs supports +line:col as an arg but not part of the filename.
Cheers Lex
Hi Lex!
Le 16/08/2010 03:25, Lex Trotman a écrit :
Hi Colomban,
I am not criticising your attempt at improving this, instead I think the whole idea of trying to have the line and column info on the filename is wrong and will NEVER always be right until we make Geany a mind reader (although if its reading my mind it will probably still be wrong :-) because we can't think of all the ways "inventive" programmers will come up with to structure filenames with :nn on the end.
The +line --line and --column options are there to give an unambiguous position and the :line:col capability should be removed.
Even though I totally agree that the :line:column filename-suffix cannot be guessed right in all cases, and will never can, I think it is really convenient. Why? because many tools (compilers, grep, etc.) outputs the line/column information this way. This means that to open the correct file at the correct line after a `rgrep -n` the only thing I have to do is to copy the whole string (which generally can be selected in a single operation since it is considered as a single "word") and pass it as an argument to geany, and, how wonderful, it does exactly what I expect! The other syntax are good and ways stricter, but aren't as useful IMO because (I speak for me) we generally don't want to open a file on a specific line unless we got that line information from somewhere else -- which is often gcc or grep.
This said, again, I don't (want to) believe that people create /real/ files that ends with :nn. I played with this kind of suffixes only after seeing the bug report, and only for the sake of it. Then I'd totally understand that you -- or anybody reasonable, not me ;) -- don't want to waste more time on this "issue" :)
Just in case it was common I checked vim and emacs documentation and AFAICT neither does it. Emacs supports +line:col as an arg but not part of the filename.
I don't believe that this should prevent Geany to do so if it is a good idea :) But perhaps it means it isn't a good idea...
Cheers, Colomban
On 16 August 2010 11:57, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi Lex!
Le 16/08/2010 03:25, Lex Trotman a écrit :
Hi Colomban,
I am not criticising your attempt at improving this, instead I think the whole idea of trying to have the line and column info on the filename is wrong and will NEVER always be right until we make Geany a mind reader (although if its reading my mind it will probably still be wrong :-) because we can't think of all the ways "inventive" programmers will come up with to structure filenames with :nn on the end.
The +line --line and --column options are there to give an unambiguous position and the :line:col capability should be removed.
Even though I totally agree that the :line:column filename-suffix cannot be guessed right in all cases, and will never can, I think it is really convenient. Why? because many tools (compilers, grep, etc.) outputs the line/column information this way. This means that to open the correct file at the correct line after a `rgrep -n` the only thing I have to do is to copy the whole string (which generally can be selected in a single operation since it is considered as a single "word") and pass it as an argument to geany, and, how wonderful, it does exactly what I expect!
I know, thats why I checked vim & emacs to see if its something that users could "expect" Geany to do, but it doesn't appear to be
I vaguely remembered them doing it a long time ago, but the memory might be faulty, or the capability might have been removed due to the sorts of problems identified here.
The other syntax are good and ways stricter, but aren't as useful IMO because (I speak for me) we generally don't want to open a file on a specific line unless we got that line information from somewhere else -- which is often gcc or grep.
But Geany parses the output of compiles/greps etc run from within it where it knows that the :line:col will always be added and then you can just click on the line in the message window. Perfect for Lazy Programmers (TM), ie me
This said, again, I don't (want to) believe that people create /real/ files that ends with :nn.
Well, I've seen systems where its used. Of course its not common or there would probably have been lots of comments by now.
I played with this kind of suffixes only after
seeing the bug report, and only for the sake of it. Then I'd totally understand that you -- or anybody reasonable, not me ;) -- don't want to waste more time on this "issue" :)
Just in case it was common I checked vim and emacs documentation and AFAICT neither does it. Emacs supports +line:col as an arg but not part of the filename.
I don't believe that this should prevent Geany to do so if it is a good idea :) But perhaps it means it isn't a good idea...
I think its not a good idea as the default since Geany can be used by other software (eg filemanagers) to open/create files with any name.
But maybe add a command line option to specify that the filename IS suffixed with :line:col so you can still paste terminal output. Perhaps -a and --at.
Cheers Lex
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 16/08/2010 04:50, Lex Trotman a écrit :
On 16 August 2010 11:57, Colomban Wendling lists.ban@herbesfolles.org wrote:
The other syntax are good and ways stricter, but aren't as useful IMO because (I speak for me) we generally don't want to open a file on a specific line unless we got that line information from somewhere else -- which is often gcc or grep.
But Geany parses the output of compiles/greps etc run from within it where it knows that the :line:col will always be added and then you can just click on the line in the message window. Perfect for Lazy Programmers (TM), ie me
Yeah, but needs to have thought of calling grep from Geany, which is not always the case for me :-/
Just in case it was common I checked vim and emacs documentation and AFAICT neither does it. Emacs supports +line:col as an arg but not part of the filename.
I don't believe that this should prevent Geany to do so if it is a good idea :) But perhaps it means it isn't a good idea...
I think its not a good idea as the default since Geany can be used by other software (eg filemanagers) to open/create files with any name.
If the file exists, that's not a problem, neither now nor with my patch, since Geany will detect that it exists and open it as-is, without trying to strip the line/columns.
And with my patch it's even better, since if the file to be opened at a given line/column doesn't exist, it forgets the line and columns and opens the full path as given -- no line/column stripping. I think that the only problem users can see with the behavior of the patch is if they have the files "foo:0" and "foo:0:1" and they want to open "foo:0" at line 1 with the :nn syntax.
I mean, with the patch, Geany can be used transparently with files that have :nn suffixes -- apart using the :nn suffix to open at a given line/column that doesn't always do magic (but almost).
But maybe add a command line option to specify that the filename IS suffixed with :line:col so you can still paste terminal output. Perhaps -a and --at.
Perhaps it's a possibility, yes -- even though I'd prefer to be able to set it as the default.
Cheers, Colomban
Since I have $EDITOR set to Geany I don't know what software will call it with what filenames. One piece of software I use occasionally uses filename:nn as a temp file name & I have to change name each time :-(. So I have some minor interest in fixing it (but use it rarely enough that I hadn't even filed a bug yet ;-).
I think its not a good idea as the default since Geany can be used by other software (eg filemanagers) to open/create files with any name.
If the file exists, that's not a problem, neither now nor with my patch, since Geany will detect that it exists and open it as-is, without trying to strip the line/columns.
Understood that, no problem here, its a definite improvement.
And with my patch it's even better, since if the file to be opened at a given line/column doesn't exist, it forgets the line and columns and opens the full path as given -- no line/column stripping.
Thats ok too.
I think that the only problem users can see with the behavior of the patch is if they have the files "foo:0" and "foo:0:1" and they want to open "foo:0" at line 1 with the :nn syntax.
What about if you have "file" and you want to create "file:nn" as a new file (my example above)? IIUC it will instead open "file" at line nn?
I mean, with the patch, Geany can be used transparently with files that have :nn suffixes -- apart using the :nn suffix to open at a given line/column that doesn't always do magic (but almost).
But maybe add a command line option to specify that the filename IS suffixed with :line:col so you can still paste terminal output. Perhaps -a and --at.
Perhaps it's a possibility, yes -- even though I'd prefer to be able to set it as the default.
Just alias ga to geany --at & save even more typing ;-)
Cheers Lex
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 17/08/2010 02:52, Lex Trotman a écrit :
Since I have $EDITOR set to Geany I don't know what software will call it with what filenames. One piece of software I use occasionally uses filename:nn as a temp file name & I have to change name each time :-(. So I have some minor interest in fixing it (but use it rarely enough that I hadn't even filed a bug yet ;-).
[...]
I think that the only problem users can see with the behavior of the patch is if they have the files "foo:0" and "foo:0:1" and they want to open "foo:0" at line 1 with the :nn syntax.
What about if you have "file" and you want to create "file:nn" as a new file (my example above)? IIUC it will instead open "file" at line nn?
Yes, exactly. Now the question is, is this a problem? If yes (regarding you first remark, it seems to be), then I don't see any other solution than effectively disable this.
I mean, with the patch, Geany can be used transparently with files that have :nn suffixes -- apart using the :nn suffix to open at a given line/column that doesn't always do magic (but almost).
But maybe add a command line option to specify that the filename IS suffixed with :line:col so you can still paste terminal output. Perhaps -a and --at.
Perhaps it's a possibility, yes -- even though I'd prefer to be able to set it as the default.
Just alias ga to geany --at & save even more typing ;-)
Yeah true, didn't thought of it, that's not a big deal. I could even alias geany to geany --whatever not to heave to think of it -- just need to it. Then if everybody's OK with this (Nick, Enrico?), I could implement it -- or anybody else, don't mind ;)
But -- stop me if I'm wrong -- perhaps the reverse can be fine too? say, setting $EDITOR to geany --no-whatever? Not sure it works nor it's better, just to suggest.
Regards, Colomban
On 20 August 2010 04:04, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 17/08/2010 02:52, Lex Trotman a écrit :
Since I have $EDITOR set to Geany I don't know what software will call it with what filenames. One piece of software I use occasionally uses filename:nn as a temp file name & I have to change name each time :-(. So I have some minor interest in fixing it (but use it rarely enough that I hadn't even filed a bug yet ;-).
[...]
I think that the only problem users can see with the behavior of the patch is if they have the files "foo:0" and "foo:0:1" and they want to open "foo:0" at line 1 with the :nn syntax.
What about if you have "file" and you want to create "file:nn" as a new file (my example above)? IIUC it will instead open "file" at line nn?
Yes, exactly. Now the question is, is this a problem? If yes (regarding you first remark, it seems to be), then I don't see any other solution than effectively disable this.
I mean, with the patch, Geany can be used transparently with files that have :nn suffixes -- apart using the :nn suffix to open at a given line/column that doesn't always do magic (but almost).
But maybe add a command line option to specify that the filename IS suffixed with :line:col so you can still paste terminal output. Perhaps -a and --at.
Perhaps it's a possibility, yes -- even though I'd prefer to be able to set it as the default.
Just alias ga to geany --at & save even more typing ;-)
Yeah true, didn't thought of it, that's not a big deal. I could even alias geany to geany --whatever not to heave to think of it -- just need to it. Then if everybody's OK with this (Nick, Enrico?), I could implement it -- or anybody else, don't mind ;)
But -- stop me if I'm wrong -- perhaps the reverse can be fine too? say, setting $EDITOR to geany --no-whatever? Not sure it works nor it's better, just to suggest.
Well its possible too, sensible applications should accept $EDITOR having options, but I would have $EDITOR point to a shell script which runs Geany with the options just in case. All possible, just more trouble & then only allows one file.
I don't really mind either way & as you are the one doing the work you can choose.
Cheers Lex
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 19/08/2010 21:43, Lex Trotman a écrit :
I mean, with the patch, Geany can be used transparently with files that have :nn suffixes -- apart using the :nn suffix to open at a given line/column that doesn't always do magic (but almost).
But maybe add a command line option to specify that the filename IS suffixed with :line:col so you can still paste terminal output. Perhaps -a and --at.
Perhaps it's a possibility, yes -- even though I'd prefer to be able to set it as the default.
Just alias ga to geany --at & save even more typing ;-)
Yeah true, didn't thought of it, that's not a big deal. I could even alias geany to geany --whatever not to heave to think of it -- just need to it. Then if everybody's OK with this (Nick, Enrico?), I could implement it -- or anybody else, don't mind ;)
But -- stop me if I'm wrong -- perhaps the reverse can be fine too? say, setting $EDITOR to geany --no-whatever? Not sure it works nor it's better, just to suggest.
Well its possible too, sensible applications should accept $EDITOR having options, but I would have $EDITOR point to a shell script which runs Geany with the options just in case. All possible, just more trouble & then only allows one file.
"then only allows one file." why? I don't see what would be the problem of something like this? geany --some-option --no-whatever "$@" Should accept anything as arguments, one file, two files, options, ... no?
I don't really mind either way & as you are the one doing the work you can choose.
As already said, I just played with this after having seen a report, I personally don't mind to see the "bug" fixed, so as far as there is still a way to support these suffixes (which I mind about), I'll be fine.
So I think other thoughts on this would be a plus; then I think I'll wait a little longer, hoping for other opinions.
Regards, Colomban
On 20 August 2010 05:55, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 19/08/2010 21:43, Lex Trotman a écrit :
I mean, with the patch, Geany can be used transparently with files that have :nn suffixes -- apart using the :nn suffix to open at a given line/column that doesn't always do magic (but almost).
But maybe add a command line option to specify that the filename IS suffixed with :line:col so you can still paste terminal output. Perhaps -a and --at.
Perhaps it's a possibility, yes -- even though I'd prefer to be able to set it as the default.
Just alias ga to geany --at & save even more typing ;-)
Yeah true, didn't thought of it, that's not a big deal. I could even alias geany to geany --whatever not to heave to think of it -- just need to it. Then if everybody's OK with this (Nick, Enrico?), I could implement it -- or anybody else, don't mind ;)
But -- stop me if I'm wrong -- perhaps the reverse can be fine too? say, setting $EDITOR to geany --no-whatever? Not sure it works nor it's better, just to suggest.
Well its possible too, sensible applications should accept $EDITOR having options, but I would have $EDITOR point to a shell script which runs Geany with the options just in case. All possible, just more trouble & then only allows one file.
"then only allows one file." why? I don't see what would be the problem of something like this? geany --some-option --no-whatever "$@" Should accept anything as arguments, one file, two files, options, ... no?
True too.
Cheers Lex
I don't really mind either way & as you are the one doing the work you can choose.
As already said, I just played with this after having seen a report, I personally don't mind to see the "bug" fixed, so as far as there is still a way to support these suffixes (which I mind about), I'll be fine.
So I think other thoughts on this would be a plus; then I think I'll wait a little longer, hoping for other opinions.
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel