🚀 go-pugleaf

newsspam5REMOVETHIS@robf.de writes:

> Tim X <timx@nospam.dev.null> writes:
>
>> newsspam5REMOVETHIS@robf.de writes:
>>
>>> Tim X <timx@nospam.dev.null> writes:
>>>
>>>> vm-8.1.0-devo-464
>>>> GNU Emacs 22.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.12) of 2007-06-21 on
>>>> lion
>>>> OS Debian Testing
>>>>
>>>> I use a dark background as my default (black). The summary faces are
>>>> 'invisible' for unread messages (black on black) and difficult to read for
>>>> others (i.e. deleted is gray50 on black etc). 
>>>>
>>>> I set these faces through customize, but the changes only last for the current
>>>> session. When I re-start emacs, they are back to their defaults.
>>>>
>>>> Checking my .emacs, I have the following lines -
>>>>
>>>>  '(vm-summary-selected-face ((t (:background "black" :foreground "yellow" :weight bold))))
>>>>  '(vm-summary-unread-face ((t (:foreground "green"))))
>>>>
>>>> so its possible vm just isn't setting the values from my .emacs file. However,
>>>> it does appear to be saving these values to the file. 
>>>>
>>>> I also noticed this behavior running the vm-rfaddons stuff with vm 19. In
>>>> particular, I have problems with urls in the body text. They are dark blue by
>>>> default, which doesn't stand out too well on a black background. All my
>>>> attempts to configure the face through customize fail in that they only last
>>>> that current session. This was observed with both emacs 21 and emacs 22. So it
>>>> would seem whatever the issue is, it may have been around for a while (i.e. its
>>>> not just in the new 8.x stuff, but has been brought forward from the add-ons
>>>> package. 
>>>>
>>>> I will try to dig deeper when I can find time. Just alerting you to the issue
>>>> now. 
>>>
>>> Thanks, but I cannot reproduce this, it works just fine for me.
>>>
>>> I see this note in my ~/.emacs
>>>
>>> (custom-set-faces
>>>   ;; custom-set-faces was added by Custom.
>>>   ;; If you edit it by hand, you could mess it up, so be careful.
>>>   ;; Your init file should contain only one such instance.
>>>   ;; If there is more than one, they won't work right.
>>>
>>> Could you please ensure that this is not the case for you?
>>>
>>> Robert.
>>
>> No its fine and all my other face settings are working as expected. In fact,
>> the example lines I included were taken from that section inbetween face
>> settings for planner-low-priority-task-face and w3m-arrived-anchor-face.
>> Furthermore, I have observed the same behavior on two different systems which
>> have different face customization setting sections (i.e. customizations of
>> faces and colours are different, so its unlikely to be some weird interaction
>> between different packages and face customizations.)
>>
>> I'll try to cut some time on the weekend to do a bit of debugging.
>
> Please try to toggle the mode by M-x vm-summary-face-mode and
> check if it makes a difference, I have just seen a bug where the
> selected face is not set when enabling it at startup ...
>
> Also please try the latest version of vm-summary-faces.el,
> e.g. http://tinyurl.com/2erqvm ...
>
> IMHO it might be related to some settings in your ~/.vm.
>
> Could you try to disable vm-summary-faces, i.e. do not require it
> in your ~/.vm and (setq vm-enable-addons nil).  Then enable
> vm-summary-faces-mode ...
>
>> I also encountered another problem last night. I recieved an
>> e-mail with an image attachment. When I tried to view the
>> message in VM, system load whent through the roof (like over
>> 65) and I had to kill emacs to regain control. I remember this
>> occuring sometime ago when using the vm provided mime decoders,
>> which is why I moved to using perl instead. However, I wanted
>> to test VM 'out of the box' to begin with (I only customized
>> the face stuff because unread mail summary lines were invisible
>> when you have a black background under Emacs).
>
> Have you been using the VM binaries for decoding or the lisp
> code?
>
> Also in Debian they encourage the use of perl for this due to
> similar problems ... maybe I should make this the default ... 
>
>> When you tried customizing the face and couldn't reproduce the problem (i.e.
>> when you quit emacs and started it again the customzation was in effect), did
>> you happen to compare the lines in your customize section with the two I
>> posted? Just wondering if the formats were the same?
>
> I have now used your lines and it works for me, except for the
> vm-summary-selected-face.
>
> Robert.

Hi Robert,

I've upgraded VM to the latest devo branch version i.e. 
VM 8.1.0-devo-478 under Emacs 22.1.50.1 (i686-pc-linux-gnu)

This seems to have fixed the setting of face colours from the customize section
of .emacs. However, I do get the following warning in a *comp8ile-log* buffer
when I run VM with the 'Enable faces in the summary buffer' option of
vm-enable-addons. 

Warning: reference to free variable `m'

This warning does not occur if the summary faces option is not enabled. 

I did notice some 'curious' points with respect to VM and customize and I have
some suggestions. I'm willing to try and implement some of these. In fact, I
wold have done it, except I need to install bazaar, but my Debian repository is
reporting there are too many users right now, so I can't download the package. 

1. I think we should break the customize stuff up further. The current main vm
group has too much in it and it is a bit slow to create the customize buffer as
a result (plus a little overwhelming). I think it would be good to break things
up into specific customize groups that are children of the main VM customize
group (i.e. pop, imap, mime, digest, etc).

2. There is a bit of inconsistency based on when you run customize-group. If
you run it prior to having run VM, you only get a much smaller subset of
customize options (with no apparent rationale). This can be a problem is you
need to customize one of the items which is not in the group prior to running
VM. For example, I was having problems with a message that contained a large
mime attachment. I wanted to change the default base64 decoder to use the perl
modules as I've had issues with the one provided with VM (load goes through the
roof and system becomes unresponsive). However, the items for this setting are
not in the customize group until after you have run VM at least once - giving a
sort of chicken and egg problem (which I resolved by putting the values I
wanted in my .vm file). While slightly contrived example, I think you should be
able to see the possible issues. I suspect its something to do with how files
are required and possibly autoloads etc. However, I think all vm customizable
options should appear when you do a customize group on VM, regardless of
whether you have already run VM or not. 

3. There are some custom definitions which don't look quite right. In
particular
    - Inconsistency when customizing summary buffer faces. For some, you get
    the familiar face customize object that allows you to tick the options you
    want etc (i.e vm-summary-outgoing-face) while others give you a bare lisp
    expression that you have to edit 'by hand' (i.e. vm-summary-deleted-face). 
    - Some custom definitions don't look quite correct. vm-keep-crashboxes).
    This custom definition is a toggle, but if its not nil, you are supposed to
    set it to a directory to keep crash boxes in. As a toggle, you don't get
    that ability - its either nil or t. Likewise, vm-spool-files will only let
    you specify strings - you can't do the list of lists option. As the lists
    of lists option offers grater functionality, I think it should be the way
    this custom definition is done (unless you can do both - not that familiar
    with custom, so I don't know about that). 

I've noticed a couple of other little things, but they are likely something to
do with my setup - at leat I want to eliminate that possibility before raising
them.

A lot of this is really just 'nit picking' and should not be taken as
detracting from the excellent work you have been doing to keep VM alive and
enhance its functionality. As mentioned, I will try to look at some of these
and see if I can make some patches you can apply to the dev branch. My elisp
isn't great, but I should be able to fix some of this stuff (or at least make
it consistent. 

One thing I was wondering about is if you are keeping track of or have any
mechanism for communicating what people are working on. I don't want to either
be treading on others toes or simply duplicating effort of others. Maybe you
are tracking bugs/work somehow and could make that available to others to
see/update/add to?

regards,

tim 
-- 
tcross (at) rapttech dot com dot au