[Geany-devel] [PATCH] Behavior of opening filenames with colons from the command line

Colomban Wendling lists.ban at xxxxx
Sun Aug 15 18:21:05 UTC 2010


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

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,

[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
[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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cli-line-column-prefer-existing-files.patch
Type: text/x-patch
Size: 1304 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20100815/e3a338d0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cli-line-column-prefer-existing-files-2.patch
Type: text/x-patch
Size: 2031 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20100815/e3a338d0/attachment-0001.bin>

More information about the Devel mailing list