
Prettify code

tony
Case-corrects Igor function and operation names, and removes trailing whitespace.
Note that the file containing this code will be loaded as an independent module. You'll have to show hidden items in the procedure browser to see the code.
Edit: I've removed the code snippet from this post. Follow the link to the 'text editing tools' code snippet to find a more recent version.

Forum

Support

Gallery
Igor Pro 9
Learn More
Igor XOP Toolkit
Learn More
Igor NIDAQ Tools MX
Learn More
The updated version posted above ignores quoted text and blocks of code representing proc pictures, provided that the selection starts before the Picture keyword. If I have got this right, Prettify will case-correct only words that are colored by Igor's syntax highlighting as operation or function names.
July 10, 2020 at 01:47 am - Permalink
Great that you have everything in one package now. Feel free to add my align comments code as well, so that we have everything in one neat file.
July 12, 2020 at 09:16 pm - Permalink
I posted the file with everything as a new thread in code snippets forum. Any user can edit.
July 13, 2020 at 03:47 am - Permalink
I've played around with it. And it is quite useful! Are you using github for other projects? Collaboration is more easily there IMHO.
I'm posting below a modified version.
Changes:
- Properly bailout on old IP
- Factor out mask creation and ignore window recreation macros as well
- Made hardcoded customization constants into optional parameters
- Added code to prettify all procedure files in a disc folder
- Handle ignoreList without trailing semicolon
- Simplify trailing whitespace removal
- Allow custom eol character
With that I could prettify some 60k LOC project using
Prettify#prettifyfolder("e:projekte:mies-igor:Packages:MIES", eol = "\n", customList = "variable;string;static;threadsafe;StringMatch", ignoreList="graph;proc;panel")
It does still compile and I could not yet spot any errors.
July 16, 2020 at 06:12 am - Permalink
In reply to I've played around with it… by thomas_braun
Very nice. I wouldn't have had the confidence to let it loose on a collection of files like that. Good to know that it seems to work.
Why do you mask window macros?
There is a missing semicolon following MultiThread in the version you forked (1.5).
For trailing whitespace, i would retain the conditional to allow whitespace on a line that doesn't have non-whitespace:
My aim was to remove truly trailing whitespace, but keep indentation tabs in otherwise empty lines. Maybe you can do this with some tricksy regex?
I don't use GitHub for Igor code.
July 16, 2020 at 10:19 am - Permalink
> Why do you mask window macros?
I don't want to prettify machine generated code. As I also don't edit window macros manually but regenerate them.
> There is a missing semicolon following MultiThread in the version you forked (1.5).
Thanks, fixed.
> For trailing whitespace, i would retain the conditional to allow whitespace on a line that doesn't have non-whitespace.
I'm using git's builtin whitespace checks and these also flag trailing whitespace on otherwise empty lines. What is the purpose of keeping that?
If you want to keep that whitespace I would add an early return like
July 16, 2020 at 10:47 am - Permalink
In reply to > Why do you mask window… by thomas_braun
Igor's editor does auto-indentation by inserting tabs on a new line to match the indentation level of the preceding line. I prefer not to erase that. It could be a configurable option, maybe retaining tabs but removing trailing spaces.
July 16, 2020 at 11:54 pm - Permalink
In reply to I've played around with it… by thomas_braun
I thought I would incorporate the extensions to the code provided by @thomas_braun into the TextEditTools procedure, but came across a couple of problems.
Most importantly, I think that procedure files that have been edited in Igor could have either line feed or returns (ASCII 10 or 13) at the end of lines. The wrong value for eol will truncate the file contents. So don't use the PrettifyFolder function unless you are absolutely sure that every ipf file has the same kind of line break! The code overwrites all the ipf files in the folder, so unless you know what you're doing it's best to avoid using that function entirely.
I think it would be safer to add a robust check for the type of line break for each file.
I checked that byte order mark is left intact.
The revised method for stripping trailing whitespace doesn't allow for selecting and prettifying just a part of a line, but that is easily fixed.
September 10, 2020 at 10:10 am - Permalink
Thanks for looking into that again.
First of all, I always have all code in version control. So even if a random tool destroys my code I don't loose any work. Maybe I should have pointed that our more clearly.
And I also standardize EOLs using the stock git support.
If you want to handle files with differing EOLs I think the best approach is to first normalize them, https://github.com/AllenInstitute/MIES/blob/dacf218d93523ee2c8a7acaafea… should do the trick.
September 10, 2020 at 03:18 pm - Permalink
In reply to Thanks for looking into that… by thomas_braun
Yeah, I figured that you would be coding in a proper development setup, but many Igor users are likely to be less aware of such things.
I was surprised to discover that my collection of ipf files has variable EOLs. Occasionally I code in Sublime Text, but I suspect that one cannot rely even on files that were created by Igor on the same platform to always have the same EOL, so users should be cautious!
For anyone following this thread, none of this affects the functionality of the prettify function used within Igor, i.e. selecting text within a procedure window and prettifying selected code is unaffected by and has no effect on the structure of the saved file.
September 11, 2020 at 02:34 am - Permalink