[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mike Scalora
Subject: Re: special treatment of colon-plus-digits in a filename
Date: Fri, 3 May 2024 09:21:06 -0600

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


On Fri, May 3, 2024 at 3:16 AM Benno Schulenberg <> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]