F4 Font Style

As a keystroke user:
It would be nice were there a keyed path to changing a selected text’s font family without changing the formatting of individual letters/words within the selection.
Eg, change “change this text” from Georgia to a Sitka “change this text”, without standardizing (to Regular, Bold, Bold Italic, Italic) the standout BOLD and ITALIC emphasis.

Could a BLANK Font style option be added to the F4 Select Font box?
(Have I missed another keyed path to change the family w/out changing individual emphases?)

Win 10 Pro x64 [19044];
i7 7700, 32GB RAM, 2T internal drive.

Regarding the main question, I’m almost positive this font dialogue is a standard toolkit thing that can’t have its behaviour fundamentally changed.

(Have I missed another keyed path to change the family w/out changing individual emphases?)

So long as you don’t mind cleaning up the entire section at once, there is another tool you can use which can have a keyboard shortcut added to it: the Documents ▸ Convert ▸ Text to Default Formatting... menu command. Note that at the top of that dialogue you can set it to change the font family only, but in many cases it will do what you want with default settings. It also cleans up styled text so that the text conforms to what the stylesheet dictates—which for styles that conform the character style will mean removing stuff like italics. So depending on how you use styles, that may do more than you want. Take a snapshot before running the command, if you’re at all nervous about using it.

AmberV – Yes! Thx.
(The ‘fonts only’ conversion removes the text’s non-standard color, leaves original line spacing.)

The keystroke sequence through the Document menu works fine with a file that is open in a Quick Reference window …
Because QR doesn’t have the Copy To option, Alt-D-C takes me straight to Convert. (Which I follow with … -D-Spacebar-Enter.)

However, in an editor window, the Document menu includes Copy To –
For me, this is a nuisance because I have that medium-sized project (word-corpus wise, but with 25k files) that we dealt with upgrading to Windows Scrivener v3 about a year ago. …
As then and continuing, anytime I activate a menu item that triggers a file list, Scrivener takes about 20 seconds (22+ just now) to complete its routine. (It is enough time for me to step into the kitchen and refresh my drink or peel a protein bar.)

My workaround is to invoke the Documents menu, then down arrow past the Copy To (and Move To); its pace being quick enough to not wake up the Copy/Move options as the selection passes.

My cursory troubleshooting for this suggested that the gross word-corpus size has little to do with v3’s snail-crawl file list options compared to v1’s (2-4 seconds), but perhaps as Katherine suggested a year ago, it could simply be the number of files involved.
Taking this possibility and from my four-project testing, large and small, I am consolidating files as I encounter opportunities.

Another aspect of my testing suggests the question: Could it be my extensive use of cross-links, including self-referential, that I use in the 25k file project? (The cross-links are ubiquitous, probably only in a few 100s of files?)

I am sorry for the digression, probably Too Much Info … but it has been a while since I’ve surfaced my ongoing avoidance of what are clearly useful tools.

Again, thank you for the document conversion pointer (and that earlier for text coloring).

5 posts were split to a new topic: Slow menus in large projects