I applied a similar fix like you proposed, just omit highlighting at all if I get a
zero length match. Changes committed to CVS.

> I downloaded the latest file and installed but the version number stayed at 
> 2.5.8-2 and did not change to -3.

Sorry I forgot to increase the version number in the source code. So don't worry.

> Also is there a way to change the display of the default date. It uses 
> allot of space in the date column.

Date format = %A, %B %d

see manual!

> I have been running ELOG on FreeBSD no problem for a year now,
> but this new version 2.5.8-x doesn't seem to wanna work, it compiles fine 
> with a few warnings (see attached logs).
> But has issues with password files, now it shows message "Can't open 
> passwords.pwd" for all my logbooks. It did convert the password files to 
> xml format. I had a good hard look at file permissions and config file with 
> no luck. So I went back a version and compiled 2.5.7-1 which works just 
> fine with old password files. So something with XML & FreeBSD?...

Hard to say. The simplest would be if I could debug this.

> Version 2.5.7-1 (maybe this has been fixed in 2.5.8?)
> When I run a ./elogd -C http://elog.blah.here:88 it clones the config file 
> just fine, also seems to copy over all logbook entries.
> But once I look through them there's a fault with one of the fields it 
> copies over, so entries never show up.
> 
> It should be:
> ========================================
> Date: Tue Mar 01 19:41:29 2005
> In reply to: 24
> Work done by: someuser
> Work done at (dd/mm/yy hh:mm):  1/03/05 3:30pm
> Downtime duration: 0 min
> Planned: Yes
> Reason: Normal work
> Attachment:
> Encoding: plain
> 
> But once cloned it looks like this:
> ========================================
> Date: Tue Mar 01 19:41:29 2005
> In reply to: 24
> Work done by: someuser
> Work done at (dd/mm/yy hh: m):  1/03/05 3:30pm
> Downtime duration: 0 min
> Planned: Yes
> Reason: Normal work
> Attachment:
> Encoding: plain
> 
> 
> For some reason it looses the "m" so line 4 instead of having
> "hh:mm" has "hh: m"

Your problem is that the attribute "Work done at (dd/mm/yy hh:mm)" which
contains a ":". This character is not allowed in attributes. Unfortunately I did
not document this (and even didn't know this until now... (;-) ). So you should
use the new option

Type Work done at = datetime

this gives you at the entry mask fields for day/month/year/hour/minute to fill
out, so you don't have to write it directly into the attribute. Another option
would be to use 

Comment Work done at = Please enter as (dd/mm/yy hh:mm)

which just displays a comment below the attribute in the entry mask.

- Stefan

> Ok, i see, the problem for me now is that this attribute name has been in use for 
> half a year or so by me. So now I have 100's of logbook entries with the old name 
> in them, if I change it's name then all old logbook entries will show up with that 
> field blank. I'm not sure if there's an easy way to change that attribute's name in 
> 100's of entries in 10's of logbooks, because I wouldn't want to try doing that by 
> hand.. Any ideas? (i'm no good at scripting something like that 4 sure)

find . -name "*a.log" -exec perl -pi -e 's|Work done at (dd/mm/yy hh:mm):|Work done at:|g' {} \;

Looks a bit cryptic, but searches for all *a.log files, and starts perl to replace
all occurences of "Work done at (dd/mm/yy hh:mm)" with "Word done at:". Better try
this first with a copy of your logbook. After you successfully changed that, you
have to modify the attribute list in elogd.cfg accordingly, like

Attirbutes = ..., Work done at, ...

Please note that after each manual modification of the logbook files, you have to
restart elogd.

> Can conditional attributes be assigned as conditions?

Well, I guess the question was: "Can you implement this?" I'm sure that you
tried before.. (;-)

Yes, it is working now, I had to add some new code and fix a bug with AND'ed
conditions (via '&'). The new version is under CVS. Since you use Windows, you
have to wait for the next release.

> What I can see is that it sends with charset=US-ASCII, even if the characters are
> non-US.

That's the key point. I changed it such that elog uses now the charset defined in the
configuration file, now it should work fine. Can you give it a try? The new version is
under CVS.

So you tell me that the message body is ok with Norwegian characters, it's only the subject?
That would mean that outlook interpretes the charset only for the message body, but not for
the subject. So if you have characters with an ASCII value greater than 127, your mail
program requires to enclose it into

=?<charset>?B?+<text>?=

Do you know that the "B" is for? I would not like to "blindly" do whatever Mutt does, I
would like to understand it. If someone can point me to a document which describes this
properly, I could implement it.

Ok, I found it. It's in RFC2047 at

http://www.faqs.org/rfcs/rfc2047.html

I will try to implement it.