Re: special treatment of colon-plus-digits in a filename

Thinking out loud: what about looking for files that match with colon
parsing and without colon parsing? It would probably be very, very unusual
to be ambiguous if you knew there was a match for either. I also deal with
a lot of files that have timestamps using a colon. I like colon parsing
because that's the format used in a lot of error messages

-Mike

On Fri, May 3, 2024 at 3:16 AM Benno Schulenberg <[email protected]>
wrote:

>
> 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
>
>