Thank you for your responses.
Please let me state that both the argumentation found at .../quotes.html
as well as the handling of this issue provide an example, where intention
and effect do very obviously diverge.
I don't want to aggravate the discussion in any way.
But please let me fill in, what even the Google AI is able to concede
and write up in clearly outlined ways, after a very short prompt.
And please hold this against the arguments in .../quotes.html,
which are actually not upholding in everyday life - just because of the
way that optical pattern recognition works, and because of variation
in the chosen way of display (i.e.: sometimes quotes, sometimes none),
for things without actual differences (i.e.: collection of filenames),
generates the kind of input that is most difficult input to understand.
And meaningless overhead, while technically interpretable, confuses humans.
So: Here's Google's rating of the current mode of operation:
1. Visual Disruption and Failure of Column Alignment
Inconsistent Padding: Quotes dynamically change line lengths across columns.
Broken Grid: Tabular outputs lose their vertical alignment structure.
Human Error: Uneven visual lines force the eye to track shifting boundaries.
False Security: Column spacing already isolates multi-word filenames safely
in standard terminal grids.
2. Failure of Double-Click Selection (Terminal UX)
Broken Workflows: Double-clicking a quoted filename copies the literal
quotes into the clipboard.
Manual Cleanup: Users must manually delete quotation marks after pasting
paths into commands.
Wasted Actions: Extra keystrokes directly lower developer productivity
across daily tasks.
Native Handling: Modern shells already use smart-selection delimiters
without requiring hardcoded output styling.
3. Visual Noise and Reduced Readability
High Cognitive Load: Intermittent quoting creates unpredictable text
patterns.
Scanning Obstacles: Commas, dots, and quotes blend together visually in
high-density directories.
Cluttered Data: Decorative characters hide the actual string content during
rapid visual scans.
Design Paradox: The feature tries to fix rare boundary edge cases by
degrading everyday readability.
Let me just add to that:
If you only look at the examples of .../quotes.htm, you'll immediately see how
much more
visually demanding and confusing every single example with the interspersed
quotes is.
And you haven't even tried to *quickly and reliably select* text by double
clicking at that stage.
Plus, you've already deliberately or unknowingly chosen unrealistically short
examples -
while column formatting (without disruptive quotes) would be much more helpful
(over quotes),
when more files, with names of different lengths, would be displayed - such as
in real life.
A human does, after all, NOT process the output of ls character by character,
carefully registering and processing every quote that he encounters on that way.
But a human processes everything they see at the same time - visually - in 2D,
not char by char -
and that's where reliable and regular formatting becomes much more visually
helpful,
than any bird-shit-like quotes, sometimes interspersed, sometimes absent,
resulting in a very irregular distribution, which is extremely difficult to
comprehend,
because the underlying pattern can NOT EVEN be recognized easily at all.
So, what you're doing makes reading and use by humans MORE difficult, and MORE
error prone.
And, to quote your last comment:
> By that standard it'll be a bug no matter what the maintainers do, since
> feelings are strong on both sides of the issue. So by this reasoning,
> maintainers might as well do nothing.
Yes, absolutely.
That would indeed have been the best idea in so many UI changes introduced over
the last years.
And this suggestion:
> ...
> alias ls="ls -N"
> in your .profile or whatever.
I know that. But that can only solve the problem for one system, or even for
one user account, depending on how it's done.
But the problem is far greater than fixing one system: Without a clear need,
and just because the majority was not looking
(as they never expected the surprise that came), a change was implemented.
Afterwards, everybody, who wants a system,
whose output remains *simple* to understand and simple to use, must make a
configuration change
(=something that only advanced users can actually do) on *every* single system
they want to bring back in order.
And *that* is what you sell as "welcoming new users" (tm).
And even when a user manages to fix all their current systems - and can feel
safe and sound again "at home" again -
they'll still be surprised by the newer, visually and operationally disruptive
behaviour,
whenever they come across a system they haven't manually reverted to the
previously normal and proven useful behaviuor yet.
Normally, if there is not a *definitive* need to fix something, and a clear
advantage in the fix, it shouldn't be changed.
And not existing users forced to revert a fix or be annoyed in all future on
every system they ever encounter.
And become incompatible with "mainstream" on the way.
Anyway. I see the discussion is futile.
The case was already lost in this issue, when somebody inflicted the change on
unsuspecting users, while noone was expecting this.
It might merely be left as an example and case study on how things are going
these days :-) -
and as a warning, that things once broken by "improvements", can hardly ever be
mended again.
Not even by forks - because the number needed wouldn't be practical - and
masses of incompatibilities would ensue.
Thanks you for your reading time and kind regards! js.
