JavaScript beautify only selected text

Hi there,
The TAD library contains an action that beautifys the whole draft. I copied and modified it so that it only works on the selected text, but this causes Drafts to crash sometimes. Here’s the relevant code:

   let txt = editor.getSelectedText();
   txt = js_beautify(txt, JSON.parse(strContent));
   return txt;

Does anybody have an idea what might be wrong with this approach? I’m quite new to Drafts scripting, so it might be something quite dumb.

That’s rather spooky. There will actually be a version to do just that in the next release of the library, as well as being able to apply it to any draft - not just the current one. I was documenting it this morning.

Here’s the string function the library will include.

// Reformat the string as a JavaScript string.
String.prototype.TA_devBeautifyJS = function()
	//Load the beautifier library
	require(tadLib.beautifierLibName + ".js");

	//Attempt to read in any custom settings and beautify the content of the current draft
	let fmCloud = FileManager.createCloud();
	let strSettings = fmCloud.readString("/Library/Scripts/" + tadLib.beautifierSettings + ".json");
	if (typeof strSettings == "undefined")
		//File not found, so we'll call the beautify function on the content without any additional settings.
		app.displayInfoMessage("Using default JS Beautifer settings");
		return js_beautify(this);
		//File found, so pass that in as JSON for some non-default settings.
		app.displayInfoMessage("Using custom JS Beautifer settings");
		return js_beautify(this, JSON.parse(strSettings));

Then you would call it in this sort of way.

strFormattedJavaScript = strUnformattedJavaScript.TA_devBeautifyJS();

Your code has no function definition so it should not require a return. Similarly you are working with the editor rather than the draft, so there’s no need to update(). I think therefore the following should suffice.


Hope that helps.

Would either of you mind pointing to the original TAD script?


I couldn’t actually reproduce this crash later. The return was there because I copied from an actual function definition. Thanks a lot for your answer!
It’s a cool idea to add this to String, because one can then loop over all the code fence blocks in a document and beautify them one by one.


Just to add to the above with a bit more detail, the original function is TadMiscellaneous.TA_devBeautifyJSDraft() in the TADpoLe library that is installed in the set-up of the core ThoughtAsylum Action Group.

Since the need to split the ever-growing action group up, the existing action that utilises that function is now in the Scripting section of the ThoughtAsylum - Power User action group. The action is TAD-Beautify JavaScript. It runs the formatting process against the current draft.

I was actually looking at this so recently because I’ve created a little action to try and help fix unformatted code blocks that come up on the forum. It was at that point that I realised I’d put the beautification function under the miscellaneous grouping and that it was for the current draft. Not useful for what I was trying to do, and I guess I hadn’t tidied that one up enough when I launched the library (I’d been using the function for quite a couple of years to tidy my own code). It makes much more sense to tie it to a string. The next update will use the string function above. There’s a convenience draft function to process a draft (not necessarily the current one, but it could be), and the miscellaneous one is effectively legacy, but I’m leaving it in place and it will utilise the other functions instead so I only have one bit of code to maintain.

I’m also expecting to tweak it a bit further, so the function above is unlikely be the final version of that code, but any calls to it should effectively function just the same after it is updated. There’s something I want to include in it to support another Drafts project I’m working on, but that won’t be out for a while yet.

1 Like

May I suggest that you put in a note about the beautifier.json file? It is not immediately obvious

  • that that is it’s name (one has to read the code for that)
  • where it is located (same)

Perhaps it might be possible to not force an extension on the filename? There’s nothing wrong with .json, the extension is also hidden in the source… So I’d rather specify “blafoo” in the config part and be sure that the file “blafoo” is read then having to make sure that it’s this there and blafoo.json in the filesystem.

A short reference to beautify´s github repository would also be nice so that one can find the info on config file’s content more easily.

1 Like

In the documentation for the function, it references that it will use the default settings (as listed in the explicit link to the GitHub default settings) from the library’s settings if the file specified in the library beautifierSettings property is not present.

i.e. it is not necessarily a file called beautifer.json - that’s the default name the library comes with, but the user can specify it to be whatever they like.

The settings file is explained in the configuration file section how-to information on the library home page.

I can see two aspects here that could benefit from additional detail. The first is the inclusion or exclusion of the file extension; I’ll probably add some code around that as well as something a little more explicit in the documentation (which I’ll add to my working version shortly). Secondly, the description of the action that currently utilises this could maybe do with some extra referencing.

I would argue that storing the file as JSON is preferable, but maybe also specifying it with the extension too. The file has to be a JSON file, and the JSON extension will allow text editors to readily identify it as JSON format for syntax highlighting and validation. Not making it JSON (but keeping the format) would lose the options around highlighting and validation without the user having to take additional actions.

That’s in the function description - both the link to the default settings mentioned above, and a separate one to the GitHub library.

The additional change I eluded to earlier is to do with the specification of the JSON being passed in and making it easier to vary it, so I’ll keep the above in mind as I work on the amendments.

1 Like

I have completely overlooked that. And now I found the link in the intro (should have continued to read …) and got myself an action to open that.

I agree. I just wanted to propose that one specifies the complete file name in the configuration instead of the name without the .json extension. The documentation does not make it clear that “.json” is appended automatically:

Default setings will be used unless a JSON file is present (name specified by beautifierSettings library property)

That’s in there now for the next update. It will accept with or without, but will use a revised default of with.

Not exactly sure when it will be pushed out. I would like to get a few more things off the to-do list and on the done list before I put the next update out.