Re: proced.el [was: docstrings in dired.el]

[Roland Winkler <roland.winkler@physik.uni-erlangen.de>]

> > > Well, maybe at least consider refactoring the current Lisp code so
> > > that the code which relies on `ps' is limited to a few functions with
> > > well-defined interfaces.  Then someone else could reimplement them in
> > > a portable fashion.
> > 
> > That's what I try anyway.
> 
> That's good to hear.  I hope, as part of that, you are planning on
> refactoring the usage of proced-command-alist and
> proced-sorting-schemes-alist to hide the dependency on `ps's options
> behind some more general API.

Well, on my GNU/linux system I have procps that supports sorting. As
far as I have been able to find out about ps for other system types,
they do not support any sorting. This is a bit nasty, because
sorting the cooked values in the output of ps can give different
results than sorting the raw data. Also, the START field gives me
some trouble. For systems like SunOS (then called STIME), it can
have values like "May 20" (note the space) and "17:55:11". Working
around such things for sorting and filtering will be ugly.
(I consider the START field as one of those proced should support
for sorting and filtering.)

> > I tend to think it is better to leave this unportable code in Lisp
> > than to move it to C, because I think the amount of unportable
> > code in C would be much much more.
> 
> Now I have a challenge in hand to prove that you are wrong.

If it gives a unified elisp interface, that would be nice...

> Obviously I can't decide what you work on, but let's not forget
> that we lived happily without proced at all (not even some simpler
> replacement), so I think there are more important things on which
> to work.

...Yet I agree with Stefan that a very fancy piece of code is
probably not worth the effort. 

I looked into the code of procps and found it very intransparent. On
the other hand, it seemed to me that the major complications in
procps concern the many different variants and dialects for the
options it can digest and the output it generates. Procps tries to
be a replacement for all the different versions and behaviors. Yet
the part of the code that collects the process information from the
system apparently does not contain, e.g., system-dependent
preprocessor flags. (Maybe I looked into the wrong part of the code,
but I didn't find them.) So maybe it is possible to have a not too
complicated emacs primitive that collects and returns the
information on system process (maybe with only one switch to
distinguish between user processes and all processes). Then the
cooking (sorting, filtering, etc.) could be done probably with less
effort in elisp.

Roland