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:
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.
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");
//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));
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.
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.
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.
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.
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.
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.
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)