Re: [ANNOUNCE] nano-8.0 is released

[Ralph Corderoy]

Hello Max,

> In my opinion it is great for copying the error output of many
> programs, which is often already in the filename:number format.

Other text editors cope with ‘nano.c:42:unwanted colon handling’ output
from compilers, etc., without breaking normal filename handling.

nano could, for example, have an option to give a make.log filename for
parsing.  It could then jump to the first error and allow moving
forwards/backwards through the list of errors.  This is aping vim's
‘QuickFix’ feature.  https://vimhelp.org/quickfix.txt.html

To just move to one line number isn't useful for compiler output and is
already provided for without breaking path handling.

> I think instead of being completely removed, it should be configurable

Every extra configuration option is that bit more room for confusion by
a novice user and extra support load in determining their configuration.
Making it configurable will add to the complaints of ‘I can't edit
foo:42’ with ‘Why doesn't editing foo:42 jump to line 42 on my other
machine?’.  I'm favour experts being able to tailor but nano is not
aimed at them.

> along with the problems you mentioned being fixed of course!

I don't think the problems can be fixed, as I laid out.  Although you
‘believe it should stay’ there is no objective rebuttal to my list of
flaws.

Ah, I see from the mailing-list archive there are other replies which
haven't CC'd me...

Chris Allegretta's suggestion to ‘only run the check if there is exactly
one colon in the filename’ is not a fix and just adds more confusion
over when the design flaw kicks in.

Benno writes:
> I like the feature (and have been using it already)

Given Benno probably decides whether the feature got added, may have
written it, and would have had pre-release access to it so now doesn't
want to lose something he's used to, I don't see this is relevant.

> So the thing is not going to go away.

It's poor design and shouldn't have been released.  My initial points
have not been answered.

> ./configure option: --disable-colonparsing

No, for a similar reason to the extra configuration option suggested
above.  It is not worthy of an option just for the maintainer's personal
preference and will create extra confusion.  And why is the default not
disabled with an enable configuration option?

> 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 have thousands from a variety of sources.  And not just log files
ending in a time, as Brand pointed out.  For Unix users, colon is just
another character.  For users with a history of Windows, it's special.

Given that regexp above, are you saying that the code only views paths
which match such a pattern as having a line-number suffix?  Or should
you have used a regexp which better matches nano's behaviour?

https://www.nano-editor.org/dist/latest/nano.html:

    The line and column numbers may also be specified by gluing them
    with colons after the filename.  (When a filename contains a colon
    followed by digits, escape the colon by preceding it with a triple
    backslash.)

The ‘triple backslash’ is making assumptions about the shell.  It would
be better to say that nano allows it to be escaped with a backslash.
Plus whether a backslash can be escaped so as to allow a filename with
backslash then colon.  And to precisely state the parsing rules of the
code as it's a bit vague at the moment compared to your regexp.

All too much complexity for what can already be sensibly achieved with
‘+42’.  Other Unix editors don't do this for good reason.  Please
reconsider.

-- 
Cheers, Ralph.