[Bug: 21.4.19] dired does not work properly anymore

[Stephen J. Turnbull]

Mats Lidell writes:

 > >>>>> Stephen wrote:
 > 
 > Stephen> Having a generic utility like ls(1) spit out Emacs-specific
 > Stephen> information makes me feel sick to my stomach.  Worse may be
 > Stephen> better, but this kind of worse is just bad
 > 
 > It is called cooperation :-)

Indeed it is.  The same kind of cooperation that patents enable, where
a group of vendors cooperates to mutual advantage at the expense of
portability and the users, as Uwe discovered.  Even adding features
can harm portability, you see.

The Unix philosophy has always been to have small standard tools, and
you write the fancy stuff around them.  If (fancy) dired is slow, then
the Unix Way is to fix dired; you don't bloat (standard) ls with extra
options and code that only dired uses.  It's a shame that ls has been
bloated with colorizing code, too.  What should have been done is to
give ls an XML output option with semantic tags.  As horrible as XML
is, it's standard and for what ls does parsing it is cheap and easy
via SAX.  Then you could easily write (say) CSS to configure
colorization, and have a XML+CSS viewer that replaces the tags with
pretty output.

For dired's use, it shouldn't be too hard to embed an expat parser in
XEmacs to generate a Lisp structure.  (I've got neon modularized,
which uses neon's SAX interface to generate a Lisp data structure
analogous to the one used by Fredrik Lundh's ElementTree module in
Python.  neon is *fast* compared to url.el, let me tell you!)

It has long been painful to me that GNU's Not Unix.

 > I've always wondered why dired isn't rewritten using c-level
 > primitives.  It ought to be more efficient, portable, and a dired
 > mode doesn't have to look like "ls -l" or "explorer".

If you mean avoiding a subprocess by examining the directory
ourselves, we already have the Lisp primitives needed to write ls(1)
in Lisp.  However, the people who wrote ls have already done the work
necessary to make it portable across platforms; doing that again seems
silly.  Another option would be to avoid the fork and IPC taxes by
turning ls into a library and linking to it via a module.

If you want a more polished look, we've got native widgets.

However, hardly anybody uses either modules or widgets because anybody
who wants a sizable audience has to write for GNU, which doesn't have
them.