zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: completion: highlight matching part
Date: Sun, 03 Aug 2008 17:33:21 -0700	[thread overview]
Message-ID: <080803173321.ZM31527@torch.brasslantern.com> (raw)
In-Reply-To: <080803103117.ZM26039@torch.brasslantern.com>

[> workers]

On Aug 3, 10:31am, Bart Schaefer wrote:
} Subject: Re: completion: highlight matching part
}
} The complist module installs some defaults if $LS_COLORS is empty.  The
} problem is that the form beginning with an equal or a star is supposed
} to take precedence over those defaults, but it does not.  Instead (if
} I'm reading the code correctly) it takes precedence only over explicit
} settings of all the possible $LS_COLORS colorings.

I've tracked this (by a much more roundabout route than necessary) to
PWS's patch 25006, in which he asserts (for compatibility with GNU ls)
that "File type tests from stat should come before extension tests."

The documentation still says that extension tests win and file type
tests come last, so this should have been changed at the same time
that complist.c was modified.  But clearly in this instance we want
pattern tests to take precedence over file type tests.  I don't think
there's any equivalent in GNU ls to this particular zsh-ism, so we
have several choices:

(1) Change complist.c:putfilecol() so that pattern tests come first,
    then mode tests, and finally extension tests.

(2) Do something convoluted where we check for an extension match,
    but if we find one, try the mode tests before returning the
    extension color.  We end up with a sort of rock-paper-scissors
    behavior, where modes beat extensions beat patterns beat modes.

(3) Simply update the doc and make it impossible to do what Tomasz
    originally asked for, except in old versions of the shell that
    are not GNU ls compatible.

(4) Revert to the pre-25006 behavior.

Obviously the doc needs updating no matter what (in case 4, to point
out that we're not compatible with ls).

I have the impression that prior to this discussion the backref-using
patterns for completion coloring were not particularly widespread, so
it probably won't cause any major upheaval whichever way we go.


       reply	other threads:[~2008-08-04  0:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080801163301.GA3589@pepin.polanet.pl>
     [not found] ` <080802143558.ZM815@torch.brasslantern.com>
     [not found]   ` <20080803111423.GA11247@pepin.polanet.pl>
     [not found]     ` <080803103117.ZM26039@torch.brasslantern.com>
2008-08-04  0:33       ` Bart Schaefer [this message]
2008-08-04 19:44         ` Peter Stephenson
2008-08-04 23:54           ` Bart Schaefer
2008-08-05  0:16             ` Bart Schaefer
2008-08-05  8:13               ` Peter Stephenson
2008-08-05 10:30                 ` Rocky Bernstein
2008-08-05 10:49                   ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=080803173321.ZM31527@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).