GNU bug report logs - #59407
[PATCH] Add Colors to proced

Previous Next

Full log

Message #26 received at 59407 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: luangruo <at> yahoo.com, michael.albinus <at> gmx.de, 59407 <at> debbugs.gnu.org
Subject: Re: bug#59407: [PATCH] Add Colors to proced
Date: Mon, 21 Nov 2022 16:28:06 +0200

> From: Laurence Warne <laurencewarne <at> gmail.com>
> Date: Mon, 21 Nov 2022 09:07:59 +0000
> Cc: Po Lu <luangruo <at> yahoo.com>, 59407 <at> debbugs.gnu.org, 
> 	Michael Albinus <michael.albinus <at> gmx.de>
> 
>  Thanks.  Please be sure to test the new faces with the following Emacs
>  configurations:
> 
>    . GUI frames with dark background
>    . GUI frames with light background
>    . TTY frames with dark and light backgrounds and with:
>      - 8 colors
>      - 16 colors
> 
> Do you know if there's an easy way I can test the faces on 8/16 colour terminals?

For 8 colors, invoke Emacs with "-nw --color".
For 16 colors, try --color=16, and if it doesn't work, try configuring xterm
for 16 colors, then invoke Emacs with -nw.

>    (proced-run-status-code, proced-executable. proced-memory-default)
>    (proced-memory-mb, proced-pgrp): New faces. 
> 
> Minor, but do you mean to add a closing paren at the end of each line?

Yes.  You can use the command "C-x 4 a" to format the log entries, it will
do this automatically if auto-fill is turned on.

> I saw this format in the commit log:
>   (proced-run-status-code, proced-executable. proced-memory-default,
>   proced-memory-mb, proced-pgrp): New faces.

This is wrong.

>  This should probably be specified as percentage of total memory.  Or maybe
>  there should be a separate defcustom for the percentage, and the condition
>  should use both.  Just a single absolute threshold seems to cover only some
>  reasons for highlighting processes with large memory footprint.
> 
> I was thinking highlighting based on percentage memory would be more suited to the "mem" process
> attribute (granted though this is not implemented).  Though in hindsight a global threshold may not make
> sense if you're connecting to remote systems with varying amounts of RAM.  Perhaps the two thresholds
> could mark a percentage, say 10% and 50% of total memory?

Something like that, yes.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.