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?
__
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,
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
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
Congratulations on the new release.
It should be possible to specify a timezone such as
Europe/Rome for the date input. That works in TZ
to control the output, so it should work in the input too.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
='TZ="Europe/Paris" 2004-10-31
06:30'
Sun, 31 Oct 2004 01:30:00 -0400
That does the job, but it is not documented in the manual.
Could you document it, and add these examples?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Perhaps you can simply filter the output of pr through a filter
to eliminate the offending newline(s)?
Maybe I could, but that seems to be an answer to the wrong question.
The question is not how I can get good printouts. The question is
how to make our various programs work right togeth
Omitting the trailer causes GNU pr to try to print on
the very last line of the output page, which is a portability hassle:
some printers and printer emulators ignore newline before formfeed on
the last line of a page, while others don't.
Wouldn't the trailer force a move to the
Sorry, I see I wasn't clear. By "omitting the trailer" I meant that
GNU pr attempted to print on the very last line of the output page,
omitting the usual trailer of 5 blank lines at the bottom of the
output page.
Ok, I guess we should try that.
_
I see. But, anyway, "ls (coreutils) 4.5.4" has a bug. If
this version of "ls" is already widely spread, shouldn't
Emacs pay special attention to such a buggy "ls"?
Maybe it should. It depends how hard that is to do, versus how
hard it is for people to upgrade coreutils. Is a fixed
14 matches
Mail list logo
