Richard Stallman <[EMAIL PROTECTED]> writes:
> I recall we discussed this, but I don't recall if we solved the
> problem. Did we decide on any solution?
I don't recall anyone designing anything specific, but here are some
thoughts. Current "ls -l --dired" outputs something like this:
drwx
Richard Stallman <[EMAIL PROTECTED]> writes:
> I think a better solution is if we can turn off the new "feature"
> of adapting the column widths to the data.
One way would be to extend --format to allow fairly arbitrary formats
that can specify column widths. For example, Emacs could do this:
I think a better solution is if we can turn off the new "feature"
of adapting the column widths to the data. It is simple and clean.
Both this and your suggestion would only work with GNU ls, so in that
regard neither one has an advantage.
Meyering, what do you think?
__
> I think a better solution is if we can turn off the new "feature"
> of adapting the column widths to the data. It is simple and clean.
> Both this and your suggestion would only work with GNU ls, so in that
> regard neither one has an advantage.
Another solution is to assume that the current bu
On Thu, Sep 23, 2004 at 12:45:31PM -0400, Richard Stallman wrote:
> I think a better solution is if we can turn off the new "feature"
> of adapting the column widths to the data. It is simple and clean.
It maybe a bit less work, but it's certainly not "better" -- without the
auto-adjustment featu
> I think a better solution is if we can turn off the new "feature"
> of adapting the column widths to the data. It is simple and clean.
> Both this and your suggestion would only work with GNU ls, so in that
> regard neither one has an advantage.
>
> Meyering, what do you think?
Ideally ls would
Another solution is to assume that the current buffer and the one new line
have used the same ls options and contain the same number of space-separated
fields. Based on this, you can add spaces so as to align the fields in the
new line to the field of the other lines.
That would b
> I think a better solution is if we can turn off the new "feature"
> of adapting the column widths to the data.
One way would be to extend --format to allow fairly arbitrary formats
that can specify column widths. For example, Emacs could do this:
ls --format='%11m %2l %8o
It maybe a bit less work, but it's certainly not "better" -- without the
auto-adjustment feature, it "simply" would use absurdly large amounts of
whitespace _just in case_ a file happens to be hundreds of gigabytes in size
and have thousands of links.
If ls does what ls used to do,
> Another solution is to assume that the current buffer and the one new
> line have used the same ls options and contain the same number of
> space-separated fields. Based on this, you can add spaces so as to
> align the fields in the new line to the field of the other lines.
> Th
Ideally ls would accept a new --format=FMT option that would
work like find's printf format string. Then it'd be easy to
add a new option to make ls use a format string with fixed
widths to restore the old behavior.
Would you like to implement that?
If that's the solution you pref
> That would be rather unreliable, since it would need to figure out the
> number of spaces between fields in both the new output and the old
> buffer. The gains that we got from --dired would be lost.
> I won't accept this approach.
Of course, the filename part would be deter
problem, we here add spaces to try and re-align the
+ ;; fields as needed. Since this is purely aesthetic, it is of utmost
+ ;; importance that it doesn't mess up anything like
+ ;; `dired-move-to-filename'. To this end, we limit ourselves to adding
+ ;; spaces only, and to only add t
Ok, you've convinced me. If no one else sees a problem,
please install your patch.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
> Ok, you've convinced me. If no one else sees a problem,
> please install your patch.
I've installed it. But as mentioned, this is lightly tested.
Please people who use dired, beat on it (whether or not your `ls' does
funny realignment: it's important that the new code shouldn't make things
wor
15 matches
Mail list logo
