Slower menu macros in Pro 3.0

Everything related to our flagship word processor.
Post Reply
credneb
Posts: 187
Joined: 2007-03-28 07:30:34

Slower menu macros in Pro 3.0

Post by credneb »

While different from Simeon's problem, I have found a different one of delayed response = slowed work.

I use glossary entries extensively, and numerous macros that are as simple as deleting text from the current cursor position to various positions in the text below. Glossary expansions are not greatly delayed, but the macros are, and are typically simple things such as deleting the text btw the current cursor position and the next Japanese (2-byte) character, or the 2-byte comma or sentence-ending 。 Or simply moving the cursor to select the next JPN (kana or kanji) character and setting the language to English instead of Japanese. In v2 these macros ran faster than I could type. In v3, I type faster than the macros execute (and no, I don't think I'm an especially fast typist). This includes such simple things as a keyboard shortcut assigning making text Red -- I select the text, hit F6 (in my case), and proceed, but the color change does not take effect in many cases.

Using a MPRod vintage mid-2014 with OS 10.11.16.
User avatar
martin
Official Nisus Person
Posts: 5227
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Quirky behavior in 3.0

Post by martin »

credneb wrote: 2018-10-30 12:17:02In v2 these macros ran faster than I could type. In v3, I type faster than the macros execute (and no, I don't think I'm an especially fast typist). This includes such simple things as a keyboard shortcut assigning making text Red -- I select the text, hit F6 (in my case), and proceed, but the color change does not take effect in many cases.
To be clear, is the problem that the macro is slow and thus takes effect later than you expect? Or is the problem that the macro doesn't do anything at all? Maybe you could share an example of a macro that seems slower in version 3?
credneb
Posts: 187
Joined: 2007-03-28 07:30:34

Re: Quirky behavior in 3.0

Post by credneb »

is the problem that the macro is slow and thus takes effect later than you expect?
Yes.

Here is one:

Find '(?:\\p{Hiragana}|(?<=\\p{Hiragana})\\u30FC)|(?:\\p{Katakana}|(?<=\\p{Katakana})\\u30FC)|(?:\\p{Han})', 'E'
Macro:editing macros:SetEnglishFont

where SetEnglishFont is

# SetEnglishFont
Format:Language:English (U.S.)
Format:Font:All Fonts:Courier
Format:Size:12

And a snippet of text:

is shown in (D)に示す。

with the insertion point before (D) I want to type a period after (D)to end the sentence. I invoke the macro by cmd-J and type a period_space, but the period gets inserted before (D). This is repeatable, and I don't recall it ever happening in v2.
User avatar
martin
Official Nisus Person
Posts: 5227
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Quirky behavior in 3.0

Post by martin »

Thank you for the example macros. That's helpful. I tested your macro in version 3 and it isn't particularly slow (it takes less than a second), but I do feel a slight difference in execution time. It feels ever so slightly slower than version 2.x, which I understand could interrupt your flow while typing.

I'll file this as something we should investigate. We can probably restore faster macro execution for this type of macro.

In the meantime I have one recommendation for you: change your macro code to use absolute menu paths. For example consider this command in your macro:

Code: Select all

Format:Font:All Fonts:Courier
Although this menu path is complete, it lacks a prefixed colon that tells Nisus Writer you are specifying an absolute path. If you add an initial colon to the path you will see faster menu matching. In other words use this:

Code: Select all

:Format:Font:All Fonts:Courier
We can probably add an optimization to do this automatically, at least in such obvious cases where the path really is a full absolute path.
credneb
Posts: 187
Joined: 2007-03-28 07:30:34

Re: Quirky behavior in 3.0

Post by credneb »

Martin,

Thank you. The absolute path bit is helpful and made the changes.

Is there a more concise way to write the line that finds the next 2-byte Japanese character -- including hiragana, katakana, and kanji, not including numbers and punctuation?

Regarding execution of this and similar macros, it seems to be a timing issue. I will often type a space instead of a period, and as you can imagine, hitting cmd-J-spacebar can be done in much less than one second. So I end up with a space where it's unwanted, the next character selected as wanted, and still needing to type a space.

BTW, the new typewriter scrolling feature is really great and saves a lot of time. Thanks.
User avatar
martin
Official Nisus Person
Posts: 5227
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Quirky behavior in 3.0

Post by martin »

credneb wrote: 2018-10-31 12:25:10Thank you. The absolute path bit is helpful and made the changes.
Excellent, I'm glad that helped at least for now.
Is there a more concise way to write the line that finds the next 2-byte Japanese character -- including hiragana, katakana, and kanji, not including numbers and punctuation?
Perhaps but I wouldn't worry too much about the find expression/regex. The expression speed is likely not a dominant factor in your macro.
BTW, the new typewriter scrolling feature is really great and saves a lot of time. Thanks.
Thanks for saying so, I'm happy to hear that!
Post Reply