TaskPaper 3.5 Korean text performance

Continuing the discussion from TaskPaper 3.5 Preview (236):

@telemachus77 I’m going to put some time into this problem again… no promises, but I’ll at least try again. Can you help me out by again:

  1. Provide me with a file that’s big enough to demonstrate the problem.
  2. Please make sure that you can reproduce the problem with default theme settings (that is just choose an empty file as your stylesheet). And also choose “Actual Size” zoom level.

Anyone else… please add to this thread if you notice slow typing performance. It should be that typing remains fast with 10’s of thousands of lines. But in some cases (Korean text being one) it seems to slow down much before that. I’m interested if its only Korean, or other languages as well.

We Discussed this issue before…^^

:writing_hand:forum link

and check it plz

http://telemachus.d.pr/15pPw

I have not noticed any problems with Korean input using the 2-set Korean input method on the newest preview version of TP3. Certainly nothing like that screen capture from @telemachus77.

Thanks.
the other Korean user says “it’s ok 3.5”…

Maybe there is something that I miss.

I wll try 3.5 preview this weekend.

same problem…

in KOREAN text
the consonants and vowels separated

Check this out.

it appears only preview Version.

@jessegrosjean

I am with you now. I can confirm that this is happening. I noticed that it only happens on files that have been saved. When I type in the unsaved sample file that comes up when you create a new document, there is no problem.

I need an example I can understand and reproduce.

What I’ve tried:

  1. Open new TaskPaper document.
  2. Switch to 3-Set Korean input method
  3. Type “jesse” keys on my keyboard. Result is “연ㅕ”
  4. Save document. Type “jesse” keys on my keyboard. Result is “연ㅕ”
  5. Type same thing in TextEdit. Result is “연ㅕ”

This is pretty much an impossible thing for me to understand without key by key instructions for what to input and what should happen. Help appreciate! :slight_smile:

  1. Open a new document.
  2. Switch to 2-set Korean input.
  3. Type dkssjdgktpdy
  4. It should produce “안녕하세요”

Instead it produces “안ㄴㅕㅇ하세요”

You see, sometimes it separates the individual “letters” that make up the syllabic forms … ㄴㅕㅇ instead of 녕.

1 Like

Ohh I think I may have just made a small bit of progress.

First I tried everything that you said and it gave me correct results every time, no matter of document was saved or not saved. But then something changed, and it started to give me the wrong “안ㄴㅕㅇ하세요” result. The one thing that I noticed was that when it was giving me the correct results I didn’t see any text input underline under the text as I was typing. But now (that it’s giving me the incorrect answer) I am seeing that text input underline. Like this:

Does that match your experience? Also are you doing this latest round of testing on 10.12?

Note, when I type the same thing in TextEdit I doing see the underlying when inputing 2-Set Korean. So I’m guessing that seeing it is an indicator of a problem… but I have no idea what it might be.

Yes. That does match my experience and I am on 10.12

The underline is an indicator that you are still inputing valid combinations of characters. Typically, when you input an invalid combination, it completes whatever character you have and moves on to the next. So, what is happening seems to be that TaskPaper is sometimes prematurely moving on to the next character regardless of whether you are inputing a valid combination.

That’s also my understanding… but isn’t it odd that TextEdit never shows the underlying when using 2-Set Korean? Is that correct? That’s the part that confuses me (or one part anyway).

I think I might have a fix for this now. Still a bunch of oddities, but I think TaskPaper is behaving better then TextEdit anyway. Here’s the behavior that I see with 2-Set Korean now:

  1. In all cases when I type “dkssjdgktpdy” the result is “안녕하세요”

  2. After restart. Open TaskPaper, and start typing in first new doc … I do not see the “marked text” underline that you would normally expect when composing characters. But after creating another window in TaskPaper (either open new document, or create new window on existing document) the behavior changes so that I DO see that marked text underline. And … this behavior remains even if I quite and restart TaskPaper. I need to do a system restart to (for a single document) get back the old (incorrect behavior I think) where I don’t see the marked text underline for a single document.

  3. Very odd, but it seems like for other apps that I run on OS X (such as TextEdit) they have (and continue to have) this same initial behavior … they input Korean 2-Set correctly, but they never show the “marked text” underline. Even after I open multiple windows.

  4. The one exception that I’ve found seems to be Safari, it always show (correctly I think) the marked text underline when composing character in Korean 2-Set.

  5. All very odd! But I “think” it’s fixed for the next TaskPaper release. (Not for 3.5), but will probably be in 3.5.1.

In case any programmers run into a similar problem this is what I needed to change in TaskPaper to fix the problem.

  1. I want TaskPaper to automatically autocomplete tags as code editors do. I’ve implemented that by overriding keyDown in the NSTextView … and if a partial tag (that matches an existing tag) is being typed then I call self.complete(nil). In my code that figures out if an existing tag is being typed I call self.rangeForUserCompletion. That seems to cause the problem… if I call that method when hasMarkedText is true it breaks the input. So now I first check if hasMarkedText is true, and if so I skip the possibility of auto competing tags.
1 Like

@telemachus77 @walton Can you give the latest preview a try and see if it fixes the input issues?

Seems to be working much better for me. I will let you know if I continue to see any problems.

1 Like