> Is there something else  which is making this difficult to do?

Not really, but hsearch() & Co. are not available under Windows, so I have to extract the
source code from the GNU C libarary or so. Since the last discussion I had lots of other
topics on my to-do list, such as mirroring and cloning, but the speed issue is getting more
and more up on the priority list.

There are too many <table> tags when displaying a singel entry.  E.g.
in http://midas.psi.ch/elogs/Config+Examples/1 the row 'Configuration Name'
is not aligned with the others (see attachment).

Looking at the HTML one sees that there are <table> tags for each row
which should not be there:

<tr><td><table width="100%" cellpadding=0 cellspacing=0><tr><td nowrap
class="attribname">Author:</td><td class="attribvalue">
Stefan Ritt&nbsp</td>
</tr></table></td></tr>

> There are too many <table> tags when displaying a singel entry.  E.g.
> in http://midas.psi.ch/elogs/Config+Examples/1 the row 'Configuration Name'
> is not aligned with the others (see attachment).

The <table> tags are there on purpose. As you can combine several attributes
into one line (see this forum for example), it's necessary to make an
independent <table> for each line. This causes the shifting as you noted
correctly. To avoid this, simple increase the width of the attribute name field
in the CSS file. Edit <elo>/themes/default/default.css, find the section with
".attibname" and change the width from 150px to 200px, such as

.attribname {
  width:200px;
  background-color:#CCCCFF;
  border:1px solid #0000FF;
  border-top:1px solid white;
  border-left:1px solid white;
  padding:3px;
}

I tried this with http://midas.psi.ch/elogs/Config+Examples/1, and it wroked
fine (see attachment). [I had to increase the text size a bit in my browser to
reproduce the initial problem]

> > There are too many <table> tags when displaying a singel entry.  E.g.
> > in http://midas.psi.ch/elogs/Config+Examples/1 the row 'Configuration Name'
> > is not aligned with the others (see attachment).
> 
> The <table> tags are there on purpose. As you can combine several attributes
> into one line (see this forum for example), it's necessary to make an
> independent <table> for each line. 

Couldn't one include the extra <table> tag only when there is really more than
one attribute per line.  All other lines could then be aligned properly.

To increase the width is not really a solution, since this depends on the
text size used.  See attachment with really big text.

Everything after curly parenthesis is ignored in attribute entry boxes 
like 'Subject' above

What I typed in the subject line was exatcly this:

  'curly parenthesis problem {abc}'

I was trying to do some hard coded spaces using:

Thread display = For: $Date for Shutdown.   $DataCenter:
$short summary. Coordinator: $Shutdown Coordinator.

The spacing actually works mthe first time, but upon going back into editing
the config file, the coded spaces are gone, replaced with real spaces, and
when saved all real multiple spaces are, as one would expect, ignored.  The
spacing reverts back to normal.

I tried other html tags but these show up as literals.

Thanks

Under 2.5.4-2 build1.460, when I edit the demo elogd.cfg the following happens:

- I start with
URL = http://cde-tx32-sds01.subdom.dom.com:8080/

- When I go to edit the global section of the config file, the *display* of
the string is changed to:
URL = <a
href="http://cde-tx32-sds01.subdom.dom.com:8080/">http://cde-tx32-sds01.subdom.dom.com:8080/</a>

- Saving this results in an error in that the rendered url is invalid.

Our current running version is 2.5.4-build1.413 and this behavior is not
evident.  I've looked through the diffs but could not identify the genesis
of this new behavior.

Thanks

I think the text display of ASCII files, which is new in version
2.5.4, is not a good idea.  E.g. I had a large ps file attached
to one entry and it took a long time display this entry (over DSL).
Then I saw that the ps-file is displayed as text, which is not really 
useful.  

Probably it is fine to display only files ending in '.txt' per default.
In addition a file that has more than say 1000 lines should probably 
also not be displayed (as default, optional OK).  

Cheers, Heiko