TextEdit set size only sets current text, not subsequent text

Howdy folks, I’m a little stumped about a script with TextEdit. Basically I have a script that @ccstone provided me (over at the Keyboard Maestro forum) that retrieves several variables that were set in Keyboard Maestro, formats them and inserts them into a TextEdit document I have open.

It works great. But for some reason the text size is only set for the set of text that was inserted via the AppleScript. When I move back into that TextEdit window, the subsequent text reverts to 12pt.

I have verified that my preferences are set to have the default text size as 24. I have also noticed that when I go back into the TextEdit window, if I move the cursor up into the text that was inserted via AppleScript and then back down, it is 24pt like it should be.

Any ideas why the text size is getting set to 12pt instead of 24 as both the AppleScript and the TextEdit preferences themselves are set to?

# Auth: Christopher Stone
# dCre: 2021/10/01 21:21
# dMod: 2021/10/01 21:21
# Appl: BBEdit, Keyboard Maestro Engine
# Task: Telephone Call Record from Keyboard Maestro Variables.
# Libs: None
# Osax: None
# Tags: @Applescript, @Script, @KMF, @ccstone, @cdthomer, @Keyboard_Maestro_Engine, @TextEdit, @Telephone, @Call, @Record
# Vers: 1.00
property LF : linefeed

set {oldTIDS, AppleScript's text item delimiters} to {AppleScript's text item delimiters, LF}
tell application "Keyboard Maestro Engine"
	set callInfo to {¬
		getvariable "LB Caller", ¬
		getvariable "Site Name", ¬
		getvariable "Reference Number", ¬
		getvariable "Agent Name", ¬
		"", ¬
		""} as text
end tell
set AppleScript's text item delimiters to oldTIDS

set tempNotes to "Lionbridge Temporary Notes.rtf"

tell application "TextEdit"
	set text of document tempNotes to callInfo
	set size of document tempNotes to 24
end tell


AppleScript and TextEdit font size issues

Hey Chris,

Because Apple doesn’t give a tinker’s damn about fixing their own bugs?

There is no way I know of to work around this with AppleScript – other than using UI-Scripting – and that probably won’t work in the background.

It’s crazy that when you set all text in a document to a specific font and size that any newly typed text could be a different font and size. This should be an absolute no-brainer, but then we’re dealing with Apple…

Your workaround is easily accomplished with Keyboard Maestro.


TextEdit ⇢ Insert Text into Front Document v1.00 ⇢ 2021.10.10-23.28.26.kmmacros.zip (3.2 KB)


Jedit Ω has the exact same problem – but there’s a fairly simple scripted workaround.

# Auth: Christopher Stone
# dCre: 2021/10/10 23:06
# dMod: 2021/10/10 23:06 
# Appl: Jedit Ω
# Task: Insert Text at End of Front Document.
# Libs: None
# Osax: None
# Tags: @Applescript, @Script, @Jedit_Ω, @Insert, @Text
property |LF| : linefeed

set sampleDataStr to text 2 thru -1 of "
01 Line one.
02 Line two.
03 Line three.
04 Line four.
05 Line five."

tell application "Jedit Ω"
   tell front document
      make new paragraph at end of its text with data sampleDataStr & |LF| & |LF|
      tell its text
         set size to 14
         set font to "Menlo Regular"
      end tell
      set selected character range to {loc:(count of characters), len:1}
   end tell
end tell

  • The script leaves the last line selected. This corrects the type new text problem and doesn’t interfere with inserting new text via AppleScript.

Of course BBEdit doesn’t have the problem in the first place, since it’s a mono-font editor and has a much more robust AppleScript dictionary.


Try this:

tell application "TextEdit"
	tell document 1
		set properties of its text to {size:42.0}
	end tell
end tell

BTW, I’m just learned in this thread TextEdit is scriptable. How long has it been?

It makes one of my tasks much easier. In the past I had been installing TextWrangler on all my users’ Macs so I would have a scriptable text editor for various purposes. But that has been discontinued.

Now I can send text to TextEdit, and even make it look pretty if I need to.


That sounds like heresy! :laughing:

Man sometimes the simplest idea eludes me. I hadn’t thought of just having a simple keystroke be sent directly to TextEdit even though I use that same action on a variety of other macros. Thanks for this!

1 Like

I tried that but it still has the same issue where subsequent text is still set to the previous size unless the cursor is moved beforehand. 🤷🏻

I think it’s been scriptable for quite awhile, but as @ccstone pointed out, it’s rather buggy. He really likes using BBEdit but what I need a text editor for is extremely basic so I’m sticking with TextEdit until I can experiment with BBEdit a little more.

Hey Ed,

Decades…  :sunglasses:

If TextEdit is good enough for your needs then fine – otherwise install the full version of BBEdit – it reverts to BBEdit “Lite” after a 30 day trial period but is still scriptable and more powerful than TextWrangler ever was.


1 Like

I have BBEdit, but I can’t have my users all install it.

Why not?

The lite version is free.

It’s a company thing. They don’t want us to install things like limited versions or shareware without paying for them.


Arguably, it’s not a limited version any more. If you get BBEdit from the Apple Store, it’s a “full” working version. Extra functionality is then available as an in-app purchase, should you wish. Semantics, I know…

1 Like

I’ve added BBEdit to the list of files to install with TextWrangler as a secondary option and they they have always removed BBEdit. I will might try again, but I may just use TextEdit. While it’s not as powerful or versitle as BBEdit is or TextWranger was, it suits my purposes just fine.

(Basically I’m outputting data to a file that will save on the user’s Mac, which they can access anytime. The fact that it can now be styled may be a plus).

What text editors will your employer allow? Threaten to write a Python program to do it and see what happens… :slight_smile:

What about starting from a plain text document where the default font size is set and then RTFing all that at the end of the process?
I guess it would be more work to set font attributes to the various parts that require them, but you could end up with something that’s a bit cleaner, no?