==============================================================================
From: Nelson H. F. Beebe <beebe@math.utah.edu>
Date: Thu, 27 Feb 2003
(1) The configure.in should not issue

      AC_PREFIX_DEFAULT(/usr)

    That overrides the GNU default of /usr/local, doesn't scale
    well at large sites (since /usr is machine specific, whereas
    /usr/local is generally shared across all machines of a common
    O/S and architecture), modifies vendor-provided directories, and
    requires root access for installation.

(2) GNU make standards require targets check, mostlyclean, and
    distclean, but these are missing from Makefile.in.
    yudit has veryclean, which seems to do what distclean does.

==============================================================================
From: Miikka-Markus Alhonen <Miikka-Markus.Alhonen@tigatieto.com>
Date: Tue, 19 Nov 2002 08:54:13 +0200 (EET)
* Open the attached file pgdn-problem.test with Code2000 size 48. Press
PgDn. Nothing happens, since Yudit can't find a paragraph starting at that
point, even though there are many paragraphs starting below. I think
this has something to do with the fact that even pressing up and down
arrows does not move from line to line, but from paragraph to paragraph.

This is very inconvenient, especially as you can not move to the previous
or the next line by pressing left or right arrow. I still think that doing
the expected case in LTR documents, the opposite in RTL and looping cursor
movement in mixed documents would be the best solution. If you don't want
looping, you could always prevent this behaviour by preventing line-to-line
movement all together when the next/previous line's directionality is
*different* from the present one's.

* For some cases, (de)composition needs to be done a couple of times
through. There's for instance \ufb2c, which is defined to be the
precomposed form of \ufb49\u05c1. OTOH, \ufb49 is the precomposed form
of \u05e9\u05bc, so even the long sequence \u05e9\u05bc\u05c1 should
result in the maximally precomposed glyph \ufb2c.
==============================================================================
From Gaspar Sinai 
Date: 2002-10-18
IS_RM is a converter from ISCII to UTF-8 Roman transliteration
and vice versa:

uniconv -encode IS_DV -in hindi-tulasidas.txt  | uniconv -decode IS_RM

You might expect this as a converter between Unicode and Roman
transliteration but it is not.

This may not be a bug - I just thought you might want to know :)
==============================================================================
Miikka-Markus Alhonen <miikka@tigatieto.com> Wed, 09 Oct 2002 08:45:43 +0300

Still, what should be done eventually (not necessarily at this point),
is normalization. If you have sequences like U+0061 U+0308 U+0323 and 
U+0061 U+0323 U+0308, they should look the same and even be matched   
by the same find expression etc. At the moment, however, they look the
same, if you type the sequences one character at a time (such as with
the "unicode" input). Then if you cut/paste or reload the sequences, they
look different from each other as well as different from the original
appearance, since now the first diacritic is combined with the base
letter while the second is not, and the second diacritic is shown with
the precomposed glyph.

==============================================================================
Miikka-Markus Alhonen <miikka@tigatieto.com> Sun, 6 Oct 2002 15:38:10 +0300

Write something in the editor window. Then minimize it and restore
again. If the input focus has remained in the editor window all this
time, the cursor isn't blinking anymore and keyboard presses have no
effect. Tooltips still show up just right when you move the mouse on
them. Then, if you press the mouse button on the editor window, you can
start writing text again, but still the cursor does not blink.
==============================================================================
Werner LEMBERG <wl@gnu.org> Mon Jan 01 00:00:00 1997

BTW, just found out that C-d doesn't erase a character but changes
the writing direction.  I wonder that nobody has ever complained
about that!

How can I change the number of lines `PgUp' and `PgDn' are using
for scrolling?

it is a *very* bad idea that yudit 2.1 installs into /usr and not
/usr/local by default!  Even more annoying, there is no `make
uninstall' target to fix it...

Gaspar:
Workaround: 
  ./configure --prefix=/usr/local
==============================================================================
Gaspar Sinai 2002-02-22
------------------------------------------------------------------------------
Indic in Yudit is not supposed to work well with Pango fonts. 
Please use True Type fonts. 
Devanagari and Tamil should have no (serious) problems
with Pango X11 fonts, still Yudit has better support for True Type 
fonts with Open Type layout.
==============================================================================
Miikka-Markus Alhonen <Miikka-Markus.Alhonen@tigatieto.com>
2002-01-21
------------------------------------------------------------------------------
Yudit doesn't seem to know always, if changes have been made to the buffer
or not. If one opens a file, deletes a character and then presses Undo, the
file is in fact unchanged, even though Yudit doesn't know this (the Save icon
remains red). If one presses a second Undo after this, the file becomes
unchanged. Now, this is a problem e.g. in the following case: 1) open a file 2)
delete a character 3) save 4) delete another character. Now Yudit thinks that
the buffer becomes unchanged only after three undo's, i.e. 1) restore the last
deleted character 2) restore the character before that 3) restore status
"unchanged". So, even though the buffer was saved between the two deletions,
Yudit thinks the buffer is unchanged only if it is exactly the same as when
_first_ opened. For new buffers, this means that a buffer is unchanged only
after it's made empty (!) by undoing, even while the buffer was saved several
times in between...
