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