0. Gaspar
==========
o Need a better SUniMap.cpp SBMap.cpp. Cuurent ones have
  serious speed problems. May need a better .my format.
o need to document -d -dimension and yudit.editor.dimension.
o swindow/SFontFB.cpp need a total rewrite.
    it should not have any descent in order to have good box drawing.
o need to chase memory leaks
o need better font wuary for native fonts. Passing xlfd is a bad idea.
  setfontsize should be passed seperatelly.

1. From: Juan Rafael Fernández García <jrfern@bigfoot.com>
=========================================================
o Opening yudit gives me
     X11Impl.cpp:
     BadMatch (invalid parameter attributes)

o In the Input Methods list, most methods start with a capital
	letter, while others don't. Is it intentional? is there some
	order in the list? (most of it is alphabetic, but...)

2. Ondrej Karny <opal@terezinstudies.cz>
=======================================
 I did some work the speed issues, attached is patch
with some easy takes.
 
 Some of the trivial methods that ended on top of the
time histogram would serve better as inlines. The most
prominent ones are converted in the supplied patch -
probably the rest is worthless. I kept the original ones
in the *.cpp files, enclosed in #if 0 / #endif, as it
seems you are generating source code documentation from
them (maybe I'm wrong and you can delete them safely).
 
 SObject class contains factory counter that is
autoincremented on construction and decremented on destruction.
You may turn on debugging mode and track for high-level
memory leaks this way, but I would consider such help really
marginal, compared to the fact that the virtual destructor
of SObject is inside the Top30 - for a function that does
nothing! So I suggest to change SObject in abstract virtual
class without destructor and get rid of the counter (maybe
provide a preprocessor symbol to enable it in specialized
builds?).
 
 I also changed portions of SBVector::equals.
 
 The non-trivial methods (SGEngine::scan/render,
SBHashtable::rehash, SMapItem::getKey, SShared::ensure)
moved on top of the profile only after these changes applied.
I'm sure you understand I don't have the time to spent on
these non-trivial changes.
 
 
 Note that enclosed patch is cumulative, against pristine
version 2.3 - it contains all my changes so far.
 
2. Raphael
==========
o  Unfortunately, cyberbit.ttf is missing some important characters,namely,

 HEBREW LIGATURE YIDDISH DOUBLE YOD
 HEBREW LIGATURE YIDDISH VAV YOD
 HEBREW LIGATURE YIDDISH DOUBLE VAV

Whom do I complain to?

Yudit makes a minor error in rendering this font.  In RTL mode, if I type,
for instance, 'o', which gives me ALEF + QAMATS, then the bottom dot of the
QAMATS (it looks like a "T" under the letter) is not erased as I type
subsequent letters, pushing the existing letters to the right.

o Gaspar - can not reproduce this.
- > I was unable to get the cyberbit font to engage by placing it in the
- > distribution's data/ directory; I had to make a link to it from my
- > ~/.yudit/data directory as well.
- 
- I wonder why... Aha maybe because it looks at '/usr/share/yduit/fonts'
- (as it should).

I have placed it in (prefix)/share/yudit/fonts/cyberbit.ttf ; that alone
didn't seem to work.

o  If I delete the window via the window manager, I get a segmentation fault;
in the previous version, I got a screen asking for confirmation.
The problem is at SBVector.cpp:89, buffer->count++; buffer is a nil pointer at
this stage.

o  I also once got a segfault when I used the window manager to move the
screen around before doing any input. (Not reproducable.)

o   I am getting the message:
 SEventBSD: miracle happened with timer...

o  I don't know how to make a keymap for which the <return> key is
significant.  I want "m <return>" to turn into a different character than other
"m"s (in Hebrew/Yiddish, a final form of the letter is needed.)

o  How should I use the clipboard (in X11 terms, the cut buffer) to enter
information that is to be processed by the current keyboard mapping and
	 have built a more comprehensive Yiddish keyboard mapping.  One of the- > things it does is combine "sh" to give a single letter, shin.  If I really
- > want the "s" and "h" to stand alone, I can insert a space between them and
- > then back over them.  Is there a better way?  I tried to map a character (|)
- > to nothing to use as a separator, but mytool doesn't like that.
- 
- In a kmap file it should accept <space>0x7c<space> 
- for '|'

The problem is that an empty right-hand side is rejected.  That is, mytool does
not accept

 " 0x7c = "

- > 2.  If I reverse direction to RTL and my first stroke is the beginning of
- > both a multikey mapping in the map and a single-key mapping, and I don't
- > continue with the multikey stroke, then the original key is displayed twice,
- > once in English and once in single-key mapping.

o Gaspar can not reporduce 
 Try this:
 use the Hungarian keymap.
 switch to RTL
 type o"

You will see an extra o with red underline.
displayed in the current direction?

Tony:
====
Yes, we can say that the new yudit is, indeed, 
an improvement. Esthetically, it is a big move 
forward. Also, it handles more input methods, 
doesn't it. Having cyberbit fonts included and 
running as the default is a very smart move. It 
works out of the box. Being able to switch directions 
for input is great, as is the undo function. 
I was able to search and replace Japanese 
characters with the latest beta (had to guess 
that "replace x y" would do 
that; some other users might not be quite so 
intuitive, especially if they are just starting 
out). 

The initial instructions should be clearer, 
I think. Please recall my phone call to you. 
If I hadn't been able to speak to you on the 
phone and find out those simple things (like 
the use of ctrl-o, and how to work with the 
encodings in the new yudit), I would not 
have been able to proceed. 

I think all people who use computers need 
two step documentation. This is because 
they are lazy, busy or both. If something 
does basically what they need it to do after 
reading being set up and after they have read 
maybe a page of text, they are happy. Next, 
they are ready to fine tune everything. For 
that they are often prepared to study for 
hours, because they are convinced that the 
time will be worth it. For me, as I know 
you and the editor, I know it would be 
worth it. But this is less true of the 
average user, I think. 

> Do you need anything else? 

* As I mentioned some days ago, I prefer to be able to 
use the return key when saving the file and when approving 
the quitting of yudit when a modified (unsaved) file is 
in the editor. 
* I prefer the encoding on a menu. I think that is one of 
the significant merits of the old yudit. If there is no 
room for that as a menu, maybe you can have yudit bring 
up a pop-up menu (like the kind that comes up now when 
the user pushes the "save" key) when ctrl-o is invoked. 

* I prefer that yudit remembers the last encoding (probably 
a good idea to have it remember everything that happened last 
time except):
* I prefer that yudit does not remember the last input method. 

reasons for the above two points: 
there are no f-keys or menu with which to change the encoding 
easily. there are for the input method (there is ctrl-o, but 
that takes a bit more key tapping). 

there are presently some complications when switching kinput 
on and off (see below); better to have it off and turn it on 
when the need arises. 

* Kinput. 
I mentioned these complications on the phone: 

Leaving kinput with f1 will leave a trail of 
garbage on the screen which must be deleted. 
This can be partially alleviated by pushing 
shift + space, backspacing to delete the one 
space that has been entered, and then going 
to f1. I don't mind it because I am used to 
having to do something similar in the old 
yudit. Others might. 

All for now. 

From MAILER-DAEMON Thu Mar  1 09:26:40 2001
Date: Thu, 1 Mar 2001 09:26:40 +0900 (JST)
From: Mail System Internal Data <MAILER-DAEMON@yudit.org>
Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
X-IMAP: 0983406400 0000000000
Status: RO

This text is part of the internal format of your mail folder, and is not
a real message.  It is created automatically by the mail system software.
If deleted, important folder data will be lost, and it will be re-created
with the data reset to initial values.

From gsinai@yudit.org Thu Mar  1 09:21:14 2001 +0900
Status: R
X-Status: 
X-Keywords:
Return-Path: <rfinkel@mail.csse.monash.edu.au>
Received: from localhost (gsinai@localhost [127.0.0.1])
	by suse.blue-edge-tech.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA20137
	for <gsinai@localhost>; Thu, 1 Mar 2001 09:21:13 +0900
Delivered-To: yuditorg-gsinai@yudit.org
Received: from mail.yudit.org
	by localhost with POP3 (fetchmail-5.1.2)
	for gsinai@localhost (single-drop); Thu, 01 Mar 2001 09:21:14 +0900 (JST)
Received: (qmail 27380 invoked from network); 1 Mar 2001 00:18:53 -0000
Received: from tarma.csse.monash.edu.au (130.194.224.168)
  by mailserv2.iuinc.com with SMTP; 1 Mar 2001 00:18:53 -0000
Received: (from rfinkel@localhost)
	by tarma.csse.monash.edu.au (8.9.3+Sun/8.9.3) id LAA29656
	for gsinai@yudit.org; Thu, 1 Mar 2001 11:18:49 +1100 (EST)
Message-Id: <200103010018.LAA29656@tarma.csse.monash.edu.au>
From: rfinkel@mail.csse.monash.edu.au (Raphael Finkel)
Date: Thu, 1 Mar 2001 11:18:49 -0500
X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98)
To: Gaspar Sinai <gsinai@yudit.org>
Subject: Re: Yudit: new translations needed

-------- from Gaspar Sinai <gsinai@yudit.org>, Feb 28, Re: Yudit: new translations needed
-
- You always find some bug.

Maybe when I retire I will take a position finding bugs in software.  I think I
have a gift for it.

- I just wonder how you could put a right-to-left 
- newline (newline is directionless) is yudit! If you can recall how it
- happened please tell me. I removed the offending line-116 (see
- attached) but I am really interested how it happens.

It is almost certainly happening on your end.  The messages.po file you sent me
attached to your mail differs in 7 places from the one I put in
www.csse.monash.edu.au/~rfinkel/private/ .  In most of those cases, you have
inserted a RTL carriage return.  Your file gives me 5 instances of
STextLine::insert unmatched STextType::PDF .  Mine gives me none.
I agree that I had a bad lineend on line 116.  I have fixed it and placed
it at www.csse.monash.edu.au/~rfinkel/private/messages1.po .

By the way, I notice that the glyph info is not coming out in Yiddish in the
beta version, even though other internationalization is.  (I am still doing the
final link by hand.)

- I am working on profiling/speeding-up/fighting memory-leak things 
- but if you think of something that would be very useful (right 
- aligment of text?) I may be able to put that in. Also I have no 
- feedback, except from you, in bidi isssues yudit has.

A few random things.

1.  When a combining character glyph is unavailable in the first font in the
list for the current font selection, you look at other fonts in the list.
Would it be better to manually compose (by superposition) in this case, to keep
the font appearance uniform, and only resort to later fonts on the list for
primary glyphs that are missing?

2.  Alignment is a tricky subject.  You don't want to build a word processor,
just a text editor, so you don't want to introduce formatting codes into the
text files.  Still, you might let the user choose preferred directionality for
the display.  A button on the toolbar would be enough.  RTL means right flush
and number columns from the right.

3.  An autowrap feature would be nice.  I use the one in vi heavily.  When you
exceed n columns on a line during typein, the editor takes the last
space-delimited word and shoves it to the next line.

4.  If a single keystroke kmaps to several that involve combining characters,
Yudit combines them.  If I enter a base character followed by a combining
character, Yudit does not combine them.  But if I write out the file and read
it in, Yudit now combines them.  

	a.  We could live with it as it is.
	b.  We could always combine if possible; no matter how a combining
	character is entered, it combines with the previous character.
	c.  We could place an invisible separator before any manually-entered
	combiner (I expect there is such a Unicode code) to prevent it from
	combining, even when we read in the file again.
	d.  We could have a button that causes all combinations within a selected
	text (or the whole file, if no selection) to be displayed combined, no
	matter how they were entered.
	e.  Something else.

I prefer d or b.  Anyone who wants c could put in the unicode for the separator
manually.  d seems clumsy, but it at least makes for consistent rendering.

5.  There ought to be a way to select the entire file.  In general, the set of
editing commands that can be bound to keystrokes should be greatly expanded.

Raphael


