Maintain order about ebib HOT 6 CLOSED

You sometimes talk about entries where I think you mean fields, because your example is also about fields. Anyway, the two commits you refer to is where I switched from storing individual entries as a hash table (in a larger hash table) to storing them as association lists (in a hash table). The former was always confusing me because it wasn't always clear in my head which hash table I was looking at... Using alists made that easier.

The cause of the problem, however, seems to be that when reading a .bib file, Ebib pushes fields onto the alist that is going to make up the new entry, so that the list ends up in the reverse order from what it is in the .bib file. I'll fix that, because you're right, the current behaviour is unpractical in certain circumstances.

I will also fix the way individual field values are stored/updated. It seems inefficient to call ebib-db-set-entry in ebib-db-set-field-value, especially given that it's fairly easy to modify the entry alist directly.

from ebib.

I made a change that should fix this issue, please test it and see if it works.

from ebib.

Yes, that works (except for bug #43). All those calls to append are very costly, though.

Wouldn't it make more sense to e.g. always store entries in reverse, and only re-reverse them writing?

from ebib.

Sorry about the parenthesis. I pushed something without checking whether it works...

Anyway, I guess you're right about append. So I pushed another commit that reverts that change and uses reverse on saving instead. It seems to work for me, let me know if you run into trouble again.

from ebib.

Still works, thanks :)

from ebib.

Whew. :-)

from ebib.