Re: proced.el -- operate on processes like dired

Re: proced.el -- operate on processes like dired

[Richard Stallman]

    Attached below is proced.el which allows one to operate on processes
    like dired.

I'm sending mail about proced to emacs-devel because it sounds like a
good feature to add to Emacs.

    To avoid reinventing the wheel, proced.el uses some code from
    dired.el.

Copying code from dired is a good idea, especially if it results in
greater coherence between proced and dired.  Maximizing such coherence
is really important for keeping Emacs coherent overall.

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Tue Mar 25 2008 Richard Stallman wrote:
> I'm sending mail about proced to emacs-devel because it sounds like a
> good feature to add to Emacs.

I appreciate any feedback and suggestions for improvements
(including the ugly completing-read in proced-send-signal).

Also, I'll be happy to see that proced becomes part of emacs.

I do not know much about CVS beyond checking in and checking out
existing files.  If someone can put proced.el into the emacs
repository, I can proceed from there.

Roland

Re: proced.el -- operate on processes like dired

[Mathias Dahl]

>  I appreciate any feedback and suggestions for improvements
>  (including the ugly completing-read in proced-send-signal).

It seems like a very useful feature. I see in the source code that you
asked for feedback on sorting and filtering and I think both would be
very useful. I use a nice extension to Dired that lets me resort the
listing on different fields. I type `s t' to sort on time, , `s s' to
sort on size, etc. Something similar could be done here, `s c' to sort
on command name, `s m' to sort on memory, `s C' on CPU etc. Filtering,
or marking using a regexp, would also be useful. The same commands as
in Dired can be used. `% m' to mark lines where COMMAND matches a
certain regexp, for example, `t' to toggle marks, `k' to kill (remove
visibly) lines. If I had that I think I would use proced.el and Emacs
instead of `ps -eaf | grep XYZ' in a Shell.

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Wed Mar 26 2008 Mathias Dahl wrote:
> I use a nice extension to Dired that lets me resort the listing on
> different fields. I type `s t' to sort on time, , `s s' to sort on
> size, etc.

This is not part of dired? It seems that sometimes I might like to
use such a feature.

> Something similar could be done here, `s c' to sort on command
> name, `s m' to sort on memory, `s C' on CPU etc. Filtering, or
> marking using a regexp, would also be useful. The same commands as
> in Dired can be used. `% m' to mark lines where COMMAND matches a
> certain regexp, for example, `t' to toggle marks, `k' to kill
> (remove visibly) lines. If I had that I think I would use
> proced.el and Emacs instead of `ps -eaf | grep XYZ' in a Shell.

Thanks, I'll look into that.

Roland

Re: proced.el -- operate on processes like dired

[Mathias Dahl]

>  > I use a nice extension to Dired that lets me resort the listing on
>  > different fields. I type `s t' to sort on time, , `s s' to sort on
>  > size, etc.
>
>  This is not part of dired? It seems that sometimes I might like to
>  use such a feature.

It actually uses Dired internals and only add a couple of clever bindings:

http://www.emacswiki.org/cgi-bin/wiki/dired-sort-map.el

Re: proced.el -- operate on processes like dired

[Richard Stallman]

    I use a nice extension to Dired that lets me resort the
    listing on different fields. I type `s t' to sort on time, , `s s' to
    sort on size, etc.

It would be nice to add that to Dired as well as to Proced.

RE: proced.el -- operate on processes like dired

[Drew Adams]

>     I use a nice extension to Dired that lets me resort the
>     listing on different fields. I type `s t' to sort on 
>     time, , `s s' to sort on size, etc.
> 
> It would be nice to add that to Dired as well as to Proced.

FWIW, that library, dired-sort-map.el, has this as its Commentary: "inspired by
Francis J. Wright's dired-sort-menu.el".

I use dired-sort-menu.el - very useful. (I have a few extensions to it in
dired-sort-menu+.el.)

Re: proced.el -- operate on processes like dired

[Juri Linkov]

>     I use a nice extension to Dired that lets me resort the
>     listing on different fields. I type `s t' to sort on time, , `s s' to
>     sort on size, etc.
>
> It would be nice to add that to Dired as well as to Proced.

This is easy to put in .emacs something like this:

;; Add different directory sorting keys
(mapc (lambda (elt)
        (define-key dired-mode-map (car elt)
          `(lambda ()
            (interactive)
            (dired-sort-other (concat dired-listing-switches ,(cadr elt))))))
      '(([(control f3)]       ""     "by name")
        ([(control f4)]       " -X"  "by extension")
        ([(control f5)]       " -t"  "by date")
        ([(control f6)]       " -S"  "by size")
        ([(control shift f3)] " -r"  "by reverse name")
        ([(control shift f4)] " -rX" "by reverse extension")
        ([(control shift f5)] " -rt" "by reverse date")
        ([(control shift f6)] " -rS" "by reverse size")))

However, we should find more convenient key bindings.

But Proced uses different sorting fields, so it should provide different
sorting methods maybe like those in `top'.

BTW, I noticed one inconsistency between Proced and Dired: in Proced
`DEL' doesn't remove the mark from the previous line, unlike Dired.

I also think that for `proced' to be useful it should be autoloaded like

;;;###autoload (autoload 'proced "proced" nil t)
(fset 'proced 'proced-mode)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: proced.el -- operate on processes like dired

[Mathias Dahl]

>  This is easy to put in .emacs something like this:
[snip]
>  However, we should find more convenient key bindings.

Did you check out dired-sort-map.el? It has good bindings, IMHO. It
does not have all those that you propose but I am sure we can think of
good letters for those extra bindings as well. Here is the guts from
the above mentioned package:

(defvar dired-sort-map (make-sparse-keymap))

(add-hook 'dired-mode-hook '(lambda () (define-key dired-mode-map "s"
dired-sort-map)))
(add-hook 'dired-mode-hook '(lambda () (define-key dired-sort-map "s"
'(lambda () "sort by Size" (interactive) (dired-sort-other (concat
dired-listing-switches "S"))))))
(add-hook 'dired-mode-hook '(lambda () (define-key dired-sort-map "x"
'(lambda () "sort by eXtension" (interactive) (dired-sort-other
(concat dired-listing-switches "X"))))))
(add-hook 'dired-mode-hook '(lambda () (define-key dired-sort-map "t"
'(lambda () "sort by Time" (interactive) (dired-sort-other (concat
dired-listing-switches "t"))))))
(add-hook 'dired-mode-hook '(lambda () (define-key dired-sort-map "n"
'(lambda () "sort by Name" (interactive) (dired-sort-other (concat
dired-listing-switches ""))))))

/Mathias

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Mon Mar 31 2008 Juri Linkov wrote:
> BTW, I noticed one inconsistency between Proced and Dired: in Proced
> `DEL' doesn't remove the mark from the previous line, unlike Dired.

This will be fixed in Proced. It's more annoying that this is
inconsistent between Dired and Ibuffer. ibuffer-unmark-backward
unmarks the buffer on the current line, unlike dired-unmark-backward.

Roland

Re: proced.el -- operate on processes like dired

[Juri Linkov]

> Juri Linkov wrote:
>> BTW, I noticed one inconsistency between Proced and Dired: in Proced
>> `DEL' doesn't remove the mark from the previous line, unlike Dired.
>
> This will be fixed in Proced. It's more annoying that this is
> inconsistent between Dired and Ibuffer. ibuffer-unmark-backward
> unmarks the buffer on the current line, unlike dired-unmark-backward.

Thanks, and new sorting commands are very useful.

However, now `proced' displays only processes belonging to the current
user, and not all processes.  Could you add a filter, e.g. asking in
the minibuffer to select among values "all" and "user"?

Another feature I suggest is to put column names to the buffer's
header line, so scrolling will keep them visible in the header line.

And another small thing I suggest to rename an improper buffer name
"*Process Info*" (this can be confused with the information about
one particular process).  Maybe a better name is "*Process List*"
(this would be like "*Buffer List*").  But if this will conflict
with `list-processes' with the same buffer name, then maybe a
simple buffer name `*Proced*' would be more descriptive?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Sun May 11 2008 Juri Linkov wrote:
> However, now `proced' displays only processes belonging to the current
> user, and not all processes.  Could you add a filter, e.g. asking in
> the minibuffer to select among values "all" and "user"?

Proced already allows you to choose a "listing type" (via
proced-listing-type bound to l). Note that this is customizable via
proced-command-alist. The idea is that here you can play with the
options of ps(1) (of course, this depends greatly on the rather
different options available on different systems).

In the future I also want to a add a filter-like behavior that
allows you to either mark processes or to restrict the display to
those processes that would otherwise be marked.

(It's a bit annoying that ps(1) comes in rather many different
flavors. I want to keep it seperate as much as possible what is
achieved in proced via ps(1) itself and via the elisp layer on top
of it.)

> Another feature I suggest is to put column names to the buffer's
> header line, so scrolling will keep them visible in the header
> line.

Thanks, that's a good idea (that will probably even simplify a few
other things that work around the first line in the proced buffer
because this line does not display a process).

> And another small thing I suggest to rename an improper buffer name
> "*Process Info*" (this can be confused with the information about
> one particular process).  Maybe a better name is "*Process List*"
> (this would be like "*Buffer List*").  But if this will conflict
> with `list-processes' with the same buffer name, then maybe a
> simple buffer name `*Proced*' would be more descriptive?

As "*Process List*" is already used by list-processes, "*Proced*" is
probably best (similar to "*Ibuffer*"). Also, the code is such that
one can rename the proced buffer and have several proced buffers in
parallel that use different listing types / filters.

Roland

Re: proced.el -- operate on processes like dired

[dhruva]

Hi,
Is 'proced' supposed to work on M$ platform? I decided to give it a
try and I do not see any output other than the column header (no
process listings). I am using Emacs from HEAD on WXP built with MinGW.

-dhruva

-- 
Contents reflect my personal views only!

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Wed Mar 26 2008 Mathias Dahl wrote:
> The same commands as in Dired can be used. `% m' to mark lines
> where COMMAND matches a certain regexp, for example, `t' to toggle
> marks, `k' to kill (remove visibly) lines.

I am sorry for my ignorance...In what context is killing a useful
operation in a dired buffer? I revert my dired buffers pretty often
and this recovers any killed lines. 

If there is a command proced-do-kill-lines analogous to
dired-do-kill-lines, it might be confusing that "killing" is usually
a very different and permanent operation in the context of unix
processes. (Right now k is bound to proced-send-signal. Certainly I
could change that. But what is the most intuitive / the least
counterintuitive key binding?)

Thanks,

Roland

Re: proced.el -- operate on processes like dired

[Mathias Dahl]

>  I am sorry for my ignorance...In what context is killing a useful
>  operation in a dired buffer? I revert my dired buffers pretty often
>  and this recovers any killed lines.

Yes, that's right, revert gets the lines back. The primary reason I
use kill is to avoid information overload when working with files. I
might mark files containing some regexp and the hits might be
distributed in many remote places in the directory. Toggling and
killing brings the marked files all neatly together, letting me work
with them easily. I too thought it was a strange feature to begin
with, but now I cannot live without it.

>  If there is a command proced-do-kill-lines analogous to
>  dired-do-kill-lines, it might be confusing that "killing" is usually
>  a very different and permanent operation in the context of unix
>  processes. (Right now k is bound to proced-send-signal. Certainly I
>  could change that. But what is the most intuitive / the least
>  counterintuitive key binding?)

Yes, `kill' in this context might be confusing. What about `flush'
which is used already in `flush-lines'. Or `remove' or `delete'?

/Mathias

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Sun Mar 30 2008 Mathias Dahl wrote:
> Yes, that's right, revert gets the lines back. The primary reason I
> use kill is to avoid information overload when working with files. I
> might mark files containing some regexp and the hits might be
> distributed in many remote places in the directory. Toggling and
> killing brings the marked files all neatly together, letting me work
> with them easily.

I see, (regexp marking and) toggling and killing can go together.
-- Of course, in the end this acts like a filter that could be
implemented as such. But depending on the context one or the other
approach can be more efficient.

> Yes, `kill' in this context might be confusing. What about `flush'
> which is used already in `flush-lines'. Or `remove' or `delete'?

Thanks, I'll think about it.

Roland

Re: proced.el -- operate on processes like dired

[Chad Brown]

> Yes, `kill' in this context might be confusing. What about `flush'
> which is used already in `flush-lines'. Or `remove' or `delete'?

This seems like `hide'ing to me, and seems to match the concept of  
things like hide-show.el.

Re: proced.el -- operate on processes like dired

[Stefan Monnier]

>> I'm sending mail about proced to emacs-devel because it sounds like a
>> good feature to add to Emacs.

> I appreciate any feedback and suggestions for improvements
> (including the ugly completing-read in proced-send-signal).

> Also, I'll be happy to see that proced becomes part of emacs.

It sounds like a useful addition (although I'd have expected it to
derive from list-buffers (or ibuffer) rather than from dired).

> I do not know much about CVS beyond checking in and checking out
> existing files.  If someone can put proced.el into the emacs
> repository, I can proceed from there.

Since you've already have the necessary copyright paperwork on file, you
just need to place your file in .../emacs/lisp/proced.el and then do:

     cvs add lisp/proced.el
     ...edit lisp/ChangeLog...
     cvs commit -m "proced.el: New file."


-- Stefan

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Tue Mar 25 2008 Stefan Monnier wrote:
> It sounds like a useful addition (although I'd have expected it to
> derive from list-buffers (or ibuffer) rather than from dired).

Up to now proced is not very advanced. Also I thought that dired was
kind of the starting point for later packages like ibuffer.
Moreover, proced depends on the output of ps(1) in a similar way
like dired depends on ls(1). The different versions of ps add a bit
of extra complication, and people with access to different unix
dialects might want to give proced a try.

> Since you've already have the necessary copyright paperwork on file, you
> just need to place your file in .../emacs/lisp/proced.el and then do:
> 
>      cvs add lisp/proced.el
>      ...edit lisp/ChangeLog...
>      cvs commit -m "proced.el: New file."

Thanks, that was easier than what I expected. -- How are the
arch-tags at the end of the files generated?

Roland

Re: proced.el -- operate on processes like dired

[Glenn Morris]

"Roland Winkler" wrote:

> Thanks, that was easier than what I expected. -- How are the
> arch-tags at the end of the files generated?

By uuidgen, or Miles.

Please add a NEWS entry.

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Wed Mar 26 2008 Glenn Morris wrote:
> "Roland Winkler" wrote:
> 
> > Thanks, that was easier than what I expected. -- How are the
> > arch-tags at the end of the files generated?
> 
> By uuidgen, or Miles.

Thanks, done.

> Please add a NEWS entry.

Done.

Roland

Re: proced.el -- operate on processes like dired

[Richard Stallman]

    I do not know much about CVS beyond checking in and checking out
    existing files.  If someone can put proced.el into the emacs
    repository, I can proceed from there.

We need papers to cover it, first.  You signed papers covering your
contributions to bibtex, but nothing else.  I'll send you what you
need.

Re: proced.el -- operate on processes like dired

[T. V. Raman]

I'd definitely recommend including proced.el, have been using it
for a few days and fills an important gap.
My previous solution to this was to use view-process-mode
(available as the hm-view-process) package, but that has now
stopped working in Emacs 23.

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     Attached below is proced.el which allows one to
    Richard> operate on processes like dired.
    Richard> 
    Richard> I'm sending mail about proced to emacs-devel because
    Richard> it sounds like a good feature to add to Emacs.
    Richard> 
    Richard>     To avoid reinventing the wheel, proced.el uses
    Richard> some code from dired.el.
    Richard> 
    Richard> Copying code from dired is a good idea, especially
    Richard> if it results in greater coherence between proced
    Richard> and dired.  Maximizing such coherence is really
    Richard> important for keeping Emacs coherent overall.
    Richard> 

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: proced.el -- operate on processes like dired

[Roland Winkler]

> Is 'proced' supposed to work on M$ platform? I decided to give it a
> try and I do not see any output other than the column header (no
> process listings). I am using Emacs from HEAD on WXP built with
> MinGW.

I do not know anything about this platform. Does it give you
something like ps(1) to list system processes?

Roland

Re: proced.el -- operate on processes like dired

[Óscar Fuentes]

"Roland Winkler" <rwinkler@niu.edu> writes:

>> Is 'proced' supposed to work on M$ platform? I decided to give it a
>> try and I do not see any output other than the column header (no
>> process listings). I am using Emacs from HEAD on WXP built with
>> MinGW.
>
> I do not know anything about this platform. Does it give you
> something like ps(1) to list system processes?

Yes, if you have Cygwin installed.

By default, Cygwin's ps outputs only Cygwin processes (i.e., those that
depend on cygwin1.dll). If you want all processes, you need to pass -W.

This is part of the output of ps -a -W :

      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
        8       0       0          8    ?    0 21:24:48 *** unknown ***
      196       0       0        196    ?    0   May  7 \SystemRoot\System32\smss.exe
      240       0       0        240    ?    0   May  7 \??\E:\WIN2K\system32\winlogon.exe
      268       0       0        268    ?    0   May  7 E:\WIN2K\system32\services.exe
      280       0       0        280    ?    0   May  7 E:\WIN2K\system32\lsass.exe
      480       0       0        480    ?    0   May  7 E:\WIN2K\system32\svchost.exe
      516       0       0        516    ?    0   May  7 E:\WIN2K\system32\spoolsv.exe
      556       0       0        556    ?    0   May  7 T:\apache\Apache2\bin\Apache.exe
     2228       0       0       2228    ?    0   May  7 E:\WIN2K\Explorer.EXE
     2596       0       0       2596    ?    0   May  7 T:\emacscvs\bin1\bin\emacs.exe
     2612       0       0       2612    ?    0   May  9 k:\apps\aspell\bin\aspell.exe
     2768       0       0       2768    ?    0   May 10 E:\WIN2K\system32\cmd.exe
     2904       1    2904       2904    0  500   May 10 /usr/bin/bash
     2728       1    2728       2728    ?   18   May 10 /usr/bin/cygrunsrv
     1664    2728    1664       2800    ?   18   May 10 /usr/sbin/sshd
     2972    2904    2972       2764    0  500 19:42:14 /usr/bin/ps

-- 
Oscar

Re: proced.el -- operate on processes like dired

[Roland Winkler]

On Sun May 11 2008 Óscar Fuentes wrote:
> > I do not know anything about this platform. Does it give you
> > something like ps(1) to list system processes?
> 
> Yes, if you have Cygwin installed.

Could you please take a look at the variable proced-command-alist?
I'll be happy to add the appropriate settings for cygwin if you
could let me know what they should be. If cygwin's ps(1) is derived
from procps, it might be possible also to add settings for
proced-sorting-schemes-alist.

If you could test all this within proced, I would also be curious to
know whether you can then actually send a signal to a process from
within proced. Is the default setting of proced-signal-function
appropriate for you?

Thanks,

Roland

PS: If someone can give proced a try on any other platform not yet
explicitly considered for proced-command-alist I'll appreciate his
or her feedbacks, too!