BUGS known to infest EDB (at some point).

Time-stamp: <2005-01-24 13:50:59 ttn>

Please send bug reports not covered in this file to <bug-edb@glug.org>.

Include version (from `M-x edb-version'), a snapshot of the *Database Log*
and *Backtrace* buffers (if available), the smallest possible set of files
to reproduce the bug, a description of the precise actions that triggered
the bug (starting from "emacs -q"), your observations of the actual events,
and a description of what you expected to see.

The following is to remind the EDB maintainer what means what (ignorable):

 HEADER                MEANING
 Id                    serial number of the bug
 Summary               one-line description of the buggy behavior
 Status                one of: unresolved, fix-applied, resolved
 Reported-Version      released version of EDB that demonstrates this bug
 Reported-By           either "ttn" or the someone's email address
 Reported-Date         when reported (and hopefully entered into BUGS :-)
 Fix-Applied-Summary   one-line description of the fix
 Fix-Applied-Date      when status changed to fix-applied
 Fix-Applied-Version   version at and after which no longer demonstrate the bug
 Resolved-Date         when status changed to resolved


Id: 0
Summary: No BUGS file
Status: resolved
Reported-Version: 1.23
Reported-By: ttn
Reported-Date: 2004-10-12
Fix-Applied-Summary: Write a BUGS file
Fix-Applied-Date: 2004-10-12
Fix-Applied-Version: 1.24
Resolved-Date: 2004-10-12

It's unknown whether projects w/ a BUGS file accumulate more or less bugs
than those w/o.  EDB can be used to fan these speculative embers -- cool!


Id: 1
Summary: EDB cannot manipulate the BUGS file as a database
Status: unresolved
Reported-Version: 1.24
Reported-By: ttn
Reported-Date: 2004-10-13

At the moment, everything is missing: schema, display format(s),
integration w/ maintenance methodology (e.g., "make check"), etc.


Id: 2
Summary: Function and variable names conflict w/ the rest of Emacs
Status: unresolved
Reported-Version: 1.24
Reported-By: ttn
Reported-Date: 2004-10-13

Most things have been pushed into `db-', `database-' or `db[a-z]*-'.
However, there are still quite a few exceptions, notably functions
and vars in db-time.el (e.g., `parse-time-string') and in db-types.el
(e.g., `abbreviate-state').  The latter is more of a latent conflict
than an immediately pressing one.

[Insert standard Emacs-single-namespace-is-a-PITA lament, here.]


Id: 3
Summary: Build failure
Status: fix-applied
Reported-Version: 1.23
Reported-By: jsbien@mimuw.edu.pl
Reported-Date: 2004-09-25
Fix-Applied-Summary: Use `default-directory' in `load-path' when compiling
Fix-Applied-Date: 2004-10-13
Fix-Applied-Version: 1.24

The bug report said that db-nosetf.el was not able to be loaded.

Now function `edb-byte-compile-all' unconditionally
adds `default-directory' to `load-path'.


Id: 4
Summary: Invoking `db-next-field' in data display buffer throws error
Status: unresolved
Reported-Version: 1.24
Reported-By: ttn
Reported-Date: 2004-10-13

In the data display buffer, command `M-x db-next-field' throws a "Wrong type
argument: integer-or-marker-p, nil" error since "current-field" state has not
yet been initialized (by calling `db-first-field', typically bound to TAB).

This bug is just one of many in a family.  The whole current-field tracking
and attributes-setting is extremely cumbersome; too many independent variables
requiring too much stylized access/mutation.  Fix requires rethought/redesign
using a more scalable approach based on model-view-controller and some kind of
observer protocol.

A kludge that was tried, and subsequently reverted, was to add:

  (unless dbf-this-field-beginning-pos
    (db-first-field)
    (setq arg 0))

to the beginning of `db-next-field'.  This worked for a bit but resulted in
other errors later for other commands and then also later for `db-next-field'
itself.


Id: 4
Summary: Command db-save-database signals "Wrong type argument" error
Status: fix-applied
Reported-Version: 1.24
Reported-By: nr-tkz@nifty.com
Reported-Date: 2004-11-20
Fix-Applied-Summary: Fix typo in db-rep.el introduced in EDB 1.23
Fix-Applied-Date: 2005-01-12
Fix-Applied-Version: 1.25

> EDB 1.24 fails to save database when I execute db-save-database for
> the first time after modifying it. But when I execute db-save-database
> again, no error occurs and EDB successfully saves the database. The
> error message reads as follows:
>
> database-set-modified-p: Wrong type argument: arrayp, nil
>
> The problem seems to be the argument passed to
> database-clean-data-display-buffers in database-set-modified-p, but I
> am unable to further look into the problem.
>
> EDB 1.23 does not cause this error. I send you sample database and
> format files. I am using GNU Emacs 21.3.50.1 (i386-mingw-nt5.0.2195)
> of 2004-11-02 on MS Windows.

ttn:
> there was a typo in db-rep.el introduced in all the mad refactoring.
> the following patch fixes it.
>
> diff -w -b -B -u --unified=1 -r1.58 -r1.60
> --- db-rep.el	13 Oct 2004 16:27:34 -0000	1.58
> +++ db-rep.el	12 Jan 2005 01:56:05 -0000	1.60
> @@ -101,3 +100,3 @@
>                (force-mode-line-update)))
> -          (database-clean-data-display-buffers database))))
> +          (database-clean-data-display-buffers db))))


Id: 5
Summary: Data file coding system not autodetected
Status: fix-applied
Reported-Version: 1.24
Reported-By: nr-tkz@nifty.com
Reported-Date: 2004-11-19
Fix-Applied-Summary: Honor new buffer-local var `edb-coding-system'
Fix-Applied-Date: 2005-01-14
Fix-Applied-Version: 1.25

> I am using EDB 1.24 but it fails to read some database files properly
> showing the following message: Database file is improperly formatted:
> try to read it anyway? If I answer yes, it reads database but all
> records get garbled. This happens when I deal with database files
> encoded in utf-16le which apparently have no problem.
>
> Since Emacs fails to autodetect the coding system of these files when
> I let it read them using the find-file command without specifying the
> coding system, it looks like EDB simply fails to autodetect the coding
> system when showing the above message.
>
> I wonder if there is some way to specify the coding system of database
> files when I execute the db-find-file command. I tried the
> universal-coding-system-argument command but it did not work.
>
> I send you sample database and format files (the database file
> contains some Japanese and French accented characters) along with the
> database log. I am using GNU Emacs 21.3.50.1 (i386-mingw-nt5.0.2195)
> of 2004-11-02 on MS Windows.

ttn:
> a temporary workaround:
>
>  (add-to-list 'auto-coding-alist '(".../sample.dat" . utf-16le))
>  (db-find-file ".../sample.dat")

ttn 2005-01-14 00:29:30:
> i've added support (and slight documentation) for new buffer-local var
> `edb-coding-system'.  1.x compatability constrains this support,
> however, so that it does not work for all internal layout data files
> (further discussion in bug #6).


Id: 6
Summary: Internal layout data w/ unrecognized encoding causes problems
Status: unresolved
Reported-Version: 1.25
Reported-By: ttn
Reported-Date: 2005-01-14

if we have the following scenario:
- data file is in internal layout format (schema and data together); and
- data file encoding is not automatically recognized by Emacs;

then the conventional method of using `universal-coding-system-argument'
(C-x RET c) before the I/O operation (in this case `db-find-file') only
works in cases where either:
- there is no format file (very uncommon in the above scenario); or
- the format file encoding is the same as for the data file.

a large part of the problem lies in function `db-read-database-file' which
does not properly modularize (i.e., kludgily special cases) internal layout
format data file reading.  unfortunately, the precise sequence of events
required for database access and EDB state init has been documented as part of
the public interface and thus is not fungible, if EDB 1.x compatability is to
be taken as an uncompromising requirement.

matters are complicated by the fact that multiple I/O operations are done,
proving the "internal" format not so well encapsulated as one might prefer.


Id: 7
Summary: Sorting in reverse incorrectly handles (eq obj1 obj2)
Status: resolved
Reported-Version: 1.21
Reported-By: erich.waelde@online.de
Reported-Date: 2005-01-15
Fix-Applied-Summary: Maintain arg order and invert the result
Fix-Applied-Date: 2005-01-17
Fix-Applied-Version: 1.25
Resolved-Date: 2005-01-24

When obj1 and obj2 are not "equal", to effect "reverse sort" it is enough to
invert the order of the arguments to the ordering function.  However, this
fails when obj1 and obj2 are "equal"; in that case, the return value does not
indicate "reverse" (loses the inversion property).

WRONG: (lambda (obj1 obj2) (funcall ORDFUNC obj2 obj1))
TESTS: assume ORDFUNC is `<'
       obj1 obj2  result
          1    2     nil  OK
          2    1       t  OK
          3    3     nil  WRONG

The fix is to invert the result of the ordering function unconditionally,
and take care to not disturb the order of the args passed to the ordering
function.

RIGHT: (lambda (obj1 obj2) (not (funcall ORDFUNC obj1 obj2)))
TESTS: assume ORDFUNC is `<'
       obj1 obj2  result
          1    2     nil  OK
          2    1       t  OK
          3    3       t  OK

Incidentally, this bugfix was part of some "EDB 1.21 Fixes" micro package
floating around tHe net, necessitated by many years of EDB maintainer
unresponsiveness.


Id: 8
Summary: Creation method canonicalization inconsistent
Status: resolved
Reported-Version: 1.21
Reported-By: erich.waelde@online.de
Reported-Date: 2005-01-15
Fix-Applied-Summary: Make db-canonicalize-creation-method return a list
Fix-Applied-Date: 2005-01-17
Fix-Applied-Version: 1.25
Resolved-Date: 2005-01-24

Caller expects a list, callee used to return a cons.  (Pretty ironic for a
function w/ "canonicalize" in its name.)  It now returns a list.

Incidentally, this bugfix was part of some "EDB 1.21 Fixes" micro package
floating around the net, necessitated by many years of EDB maintainer
unresponsiveness.


Id: 9
Summary: Function `locate-file' not defined
Status: resolved
Reported-Version: 1.24
Reported-By: erich.waelde@online.de
Reported-Date: 2005-01-15
Fix-Applied-Summary: Raise caller abstraction and rewrite to not use it
Fix-Applied-Date: 2005-01-18
Fix-Applied-Version: 1.25
Resolved-Date: 2005-01-24

The function `locate-file' is provided in GNU Emacs in cvs, and is thus not
widely available.  The fix is to raise the abstraction level for callers to
new func `db-locate-readable-file-prefer-cwd'.

This bug was introduced in EDB 1.24 during the mad refactoring.

Light testing was done on stock install of GNU Emacs 21.2, which does not
provide `locate-file'.


Id: 10
Summary: Missing support for "make edb.dvi"
Status: resolved
Reported-Version: 1.24
Reported-By: erich.waelde@online.de
Reported-Date: 2005-01-18
Fix-Applied-Summary: Add it back
Fix-Applied-Date: 2005-01-19
Fix-Applied-Version: 1.25
Resolved-Date: 2005-01-24

This support was dropped in the re-org for EDB versions 1.22 through 1.24.
Sorry about that. --ttn
