special treatment of colon-plus-digits in a filename

Benno Schulenberg <[email protected]> Fri, 3 May 2024 11:15:16 +0200

Newsgroups	gmane.editors.nano.devel
Message-ID	<[email protected]>

Op 01-05-2024 om 16:02 schreef Ralph Corderoy:
>> • To open a file at a certain line number, one can now use also
>>     `nano filename:number`, besides `nano +number filename`.
> 
> This smells wrong.  How do I now edit a file called ‘foo:42’?

To answer the question:  `man nano | grep colon`

> I suggest this new ‘:42’ filename-suffix feature is removed.  It's alien
> to Unix and doesn't marry well with the existing option interface.

I like the feature (and have been using it already), not only because
of the convenience of copy-pasting the output of some programs, but
also because I find it more logical: first the name of the file, then
the "address" within that file.  So the thing is not going to go away.

What I could offer is a ./configure option: --disable-colonparsing.

But if that is not good enough (maybe because people sometimes use
nano on machines they don't control), then I propose to make the
feature opt-in, via the command-line option --colonparsing and the
nanorc option 'set colonparsing'.  That way the feature won't hinder
the unsuspecting user and will still be available for those who want
it.  Would that be acceptable?


But out of curiosity, how many files do you have whose names end
with a colon followed by only digits?  When I run:

   locate --regex '\w+:[0-9]+$'

I get four results.  One is a directory, one is a file in ~/.cache
that I am unlikely to want to edit, and the other two happen to be
symlinks to the files whose names lack the coloned suffix.  So for
me this colon parsing is unlikely to ever be a problem, and thus I
doubt that in practice it will be a problem for other people.


Benno

OpenPGP_signature.asc (application/pgp-signature, 840 B)