Done COLORDIR enhancement

[Steve Fabian]

1/ A new color selection category to refer to files and directories in junction-based subtree. Suppose c:\abc\junction\ is a directory junction or a symlink. The new category would display all entries c:\abc\junction\* in the associated color.

2/ Permit user specification of colors for combined attributes, i.e., a unique color for files with RH attributes. The simplest syntax would just allow the file selection by attribute syntax for color selection.
--
Steve

 

[rconn]

1/ A new color selection category to refer to files and directories in junction-based subtree. Suppose c:\abc\junction\ is a directory junction or a symlink. The new category would display all entries c:\abc\junction\* in the associated color.

Why would this be useful?

2/ Permit user specification of colors for combined attributes, i.e., a unique color for files with RH attributes. The simplest syntax would just allow the file selection by attribute syntax for color selection.

Why can't you do that with the existing .and. / .or. / .xor. / .not. keywords?

 

[Steve Fabian]

From: rconn

| Quote:
| Originally Posted by Steve F�bi�n
| 1/ A new color selection category to refer to files and directories
| in junction-based subtree. Suppose c:\abc\junction\ is a directory
| junction or a symlink. The new category would display all entries
| c:\abc\junction\* in the associated color.
|
| Why would this be useful?

For the same reason coloring junctions is useful, for example, it informs you whether or not it is the primary entry.

| Quote:
| 2/ Permit user specification of colors for combined attributes, i.e.,
| a unique color for files with RH attributes. The simplest syntax
| would just allow the file selection by attribute syntax for color
| selection.
|
| Why can't you do that with the existing .and. / .or. / .xor. / .not.
| keywords?

Sorry, I did not properly RTFM, though it is hard to find, it is in a portion of the help where the last highlighted item is "Extended wildcards" (highlighted because it is a link). Indeed it is more flexible than the file selection syntax. OTOH the latter is much more compact, esp. if one could use color codes as well as color names.
--
Steve

 

[rconn]

For the same reason coloring junctions is useful, for example, it informs you whether or not it is the primary entry.

But surely the files in the junctions are going to have their own colors? Or are you suggesting overriding all existing colorizations and everything in a junction is one color?

It can be done, as long as you don't mind all of your DIR's / PDIR's getting MUCH, MUCH slower, as TCC will have to search backwards through all the parent directories (for *every* file) until it gets to the root, to determine if any of them is a junction.

 

[Steve Fabian]

From: rconn
| Quote:
| Originally Posted by Steve F�bi�n
|| For the same reason coloring junctions is useful, for example, it
|| informs you whether or not it is the primary entry.
|
| But surely the files in the junctions are going to have their own
| colors? Or are you suggesting overriding all existing colorizations
| and everything in a junction is one color?

Most of the time I do not colorize files by type, so that in fact would be the case. The primary use of color in fact would be to determine whether the PATH of the directory entry is physical or symbolic.
| It can be done, as long as you don't mind all of your DIR's / PDIR's
| getting MUCH, MUCH slower, as TCC will have to search backwards
| through all the parent directories (for *every* file) until it gets
| to the root, to determine if any of them is a junction.
I would think you are much too clever to repeat that search for every branch and leaf of the tree. Regardless, wouldn't DIR and PDIR slow down only when this special kind of colorization is actually requested?
BTW, could a colorization OPTION be added to the TREE command (not as a default)?
--
Steve

 

[rconn]

I would think you are much too clever to repeat that search for every branch and leaf of the tree.

That cannot be done without rewriting about 10,000 lines of DIR code. (Hint: this is extremely unlikely to happen, given a single request for a extreme edge condition.)

Regardless, wouldn't DIR and PDIR slow down only when this special kind of colorization is actually requested?

With my approach, yes. With your approach, no.

BTW, could a colorization OPTION be added to the TREE command (not as a default)?

Not easily.