Considerations on IME - Japanese in SynEdit (probably all other IME users too)

[Martin_fr]

from SynEdit perspective. All you want to know is that's the state of the composition (what's the clauses are (if any defined), what raw input text is). Then you could "redraw" the right size according to the width of composting text .
Knowledge about clauses is needed to draw correct underlines.

Try it in SynEdit (with both modes.) And with today's latest 1.5.

I can read the clause info from the system. But I can not currently draw underlines, that leave a tiny gap. So that is for sometime in the future.

I also have to see how well I can suppress other underlines.

The rest of the questions has not yet been answered.

[skalogryz]

malcome approved the fix. That's far more reliable than me testing anything

[Martin_fr]

That was only "overwrite selection"

That is why I opened the topic here. We started discussing in mantis, and adding more and more IME related issues or features.

[Martin_fr]

I added

Code: [Select]

    property OnIMEStart: TNotifyEvent read FOnIMEStart write FOnIMEStart;
    property OnIMEEnd: TNotifyEvent read FOnIMEEnd write FOnIMEEnd;

So outside the IDE, you can enable/disable additional highlights any way you want to.

[skalogryz]

That is why I opened the topic here. We started discussing in mantis, and adding more and more IME related issues or features.

well... somehow we need to bring more CJK community people here. They could test (patch) for sure.
I remember that one of the guys gave a link to Chinese Lazarus forum.
Links are dead now.

[malcome]

Hi Martin,
I am trying Microsoft Visual C++ 2010 Express for now.
He respects IME drawing. See attached image.

[malcome]

I am trying Geany, He respects IME.
But He seems to have the cruel bug.
Your Editor is great.

[Martin_fr]

I do not have Geany. Visual Studio is a good idea.
I have the 2010 Express version. That uses the equivalent to "Handled by System".

"Handled by system" is less work for the IDE. And it means, that the IDE can not control the highlight. (actually, it could probably set font, and background color...)

Not "Handled by system" (full integration) is more work for the IDE, but allows all the extras.

So comparing the full integration to a "handled by system" is not possible, they are different things.

We do not know, if visual studio wants to set those colors, since it technically can not.

-----------------
Anyway, ignoring if it should or should not.
And also, that some of it might not be trivial to fix, so if it was agreed to be fixed, the fix would probably be someday later.

**IF** it was done, what should be drawn?

*Currently the font color does follow context. If you type in a string, the font is blue. Similar in a comment. (if you type outside a string it is red (should maybe be black, shortcoming of the highlighter))
Should the text in the IME be blue, while typing in a string/comment? Or Should it be black.?

*If you use "Highlight current line", then the background of the current line is light-green.
If the IME is open on that line, should the IME show a white background, or follow the light green?

*If a breakpoint is set on that line, the background is red.
If the IME is open on that line, should the IME show a white background, or follow the red?

*Current word highlight:
You answered already => you do not want this highlight.
If the highlight, would use the font color (and there was no frame, no background) Should IME allow it?

*User defined word - highlight (see wiki) http://wiki.lazarus.freepascal.org/New_IDE_features_since#Multiple_user_defined_word_highlight.2Fmarkup
Should IME show them? All? None? Some in some cases?

[Martin_fr]

As noted on mantis:

Code: [Select]

  FImeMarkupSelection.MarkupInfo.BackPriority := 99999; // or higher, overrides all other backgrounds
  FImeMarkupSelection.MarkupInfo.Background := clWhite; // whatever your back color is

  FImeMarkupSelection.MarkupInfo.ForePriority := 99999; // or higher, overrides all other backgrounds
  FImeMarkupSelection.MarkupInfo.Foreground:= clBlock;// whatever your font color is
That will set background and foreground color fixed.

Code: [Select]

  FImeMarkupSelection.MarkupInfo.StylePriorityrePriority := 99999; // or higher, overrides all other backgrounds
  FImeMarkupSelection.MarkupInfo.Style:= [];
  FImeMarkupSelection.MarkupInfo.StyleMask:= [fsBold, fsItalic, fsUnderline];
This will REMOVE all styles


Unfortunately, this does not work for frames. They can not currently be removed. That needs changes to parts of the highlight system.

[Martin_fr]

Which one is best? Compare the distance.

First is default / current

line 555

Code: [Select]

        cp^.cLineHeight := TCustomSynEdit(FriendEdit).LineHeight;
        cp^.cLineHeight := TCustomSynEdit(FriendEdit).LineHeight + 1;
        cp^.cLineHeight := TCustomSynEdit(FriendEdit).LineHeight + 2;


[malcome]

IMHO, Same space as in case of "IME handled by system".

BTW
Actually, this is very tiny problem.
Because we use IME, only a comment part or the string constant part in IDE Source Editor.
It means that only "IME handled by system" is enough.
I am a programmer too, So I can understand your feel that you'd like to make the effort the leading role.
Above is only about "IDE Source Editor", not about "TSynEdit Component".

[Martin_fr]

Well I dont mind adding an option on the color. But I need to understand the exact details.

In the IDE it is pascal in most times (so comment and string).
But even then, someone may have green comments, and blue strings. Then what, should that part of color be preserved?

If a person writes there own highlighter, then what should be preserved?

See the list of questions I posted.

----------------------
The 2nd part is that suppressing the color is not that simple.

Well not if done in SynEdit. Using OnIMEStarted you can do what you want.....

Look at the code I posted. works for background color. But not for frames. So this is a task I might to later.

But If so, then I try to figure out the details now. Then open an issue on mantis, with the details, and later take care of it.

[malcome]

Isn't below link helpful? for now
https://api-dev.bugzilla.mozilla.org/show_bug.cgi?id=159263

[malcome]

I read a link a little, It seems to be very hard task....
I think it's better to pour your wonderful ability into other big ones...

They worked for 4 years....

[Martin_fr]

https://api-dev.bugzilla.mozilla.org/show_bug.cgi?id=159263#c5

I think this is not bug.
Because on Mozilla, IME composition string is drawn by Mozilla.
But on many other applications, that is drawn by IME(on composition window).
We cannot get the IME color settings with WinAPIs.
Because the APIs is not existing.

Please differ between
1) "drawn by IME" (== handled by system)
2) drawn by app / full integration

-----------------
(1) should work in SynEdit. However the IME uses proportional font. SynEdit has no influence on this.

(2) As in the quote: Those colors are NOT known.

-----------------

What can be done:

A) I can add configuration for IME colors to SynEdit/IDE

B) I can look at disabling only parts of other highlights. e.g such other highlights that make the IME underline hard to spot.


As I said NOT all of it will be now.

-----------------

I found another  issue for all "drawn by app / full integration" (wordpad, open-office, Firefox...)

If the IME text is partly scrolled of the screen , you can not see the current convert target (underlined/drop-box). IT does not scroll in when needed.

Do you think this should scroll to the convert-target, even if that means caret is scrolled off screen?

-----------------

You can always make changes to your SynEdit.