Igor Programming Tool (IPT) for formatting and linting your code

Thank you for this nice tool, which I already tried out.

I don't know whether it is OK to post feedback here, but a couple comments for now:

- First, I would like to note that ANSI escape code parsing is apparently switched off by default on windows which makes the output from this tool near unreadable. It took me quite some head-scratching to get this to work, but I followed this guide in the end:

https://stackoverflow.com/questions/51680709/colored-text-output-in-pow…

It would help to have a short tutorial for different command-line tools and / or an option to switch off formatted output (sorry if this already exists, but I couldn't find it)

- During installation, there is an option to create a desktop shortcut, but this does nothing apparently. I don't know what this would be useful for in any case since it is a command-line tool.

- Apparently, ipt lint and ipt lint -i shows different output for my files (the latter showing MUCH more warnings). I guess this is intended, but I don't get it. Does the -i flag include a setting for a more limited set of checks?

> I don't know whether it is OK to post feedback here, but a couple comments for now

Totally fine for me.

> First, I would like to note that ANSI escape code parsing is apparently switched off by default on windows which makes the output
> from this tool near unreadable. It took me quite some head-scratching to get this to work, but I followed this guide in the end:
> https://stackoverflow.com/questions/51680709/colored-text-output-in-pow…
> It would help to have a short tutorial for different command-line tools and / or an option to switch off formatted output (sorry if this already exists, but I couldn't find it)

We don't do any autodetection if ANSI escape codes are supported. You can use the `--color=no` switch to turn it off. I've made a note to document that. `ipt --help` has all the documentation for the top-level switches and `ipt <cmd> --help` for cmd.

> During installation, there is an option to create a desktop shortcut, but this does nothing apparently. I don't know what this would be useful for in any case since it is a command-line tool.

I've made a note and will followup.

> - Apparently, ipt lint and ipt lint -i shows different output for my files (the latter showing MUCH more warnings). I guess this is intended, but I don't get it. Does the -i flag include a setting for a more limited set of checks?

I'm suprised to hear that `ipt lint -i` shows more warnings. I would have expected the opposite as `-i` implies `--fix` which fixes linting warnings/errors instead of only warning. Do you have an MWE?

Thank you for the quick reply. I meant that 'ipt lint -i' shows much less warnings than 'ipt lint'. But the file itself is never changed in either case, so I wonder what -i is for then. I'll attach a test file. With the latter command I get two warnings and with the former about 6 warnings as output. If I understand you correctly, some warnings do not appear because they are apparently fixed (without actually being fixed in my case). Note that the file is properly formatted and overwritten via ipt format -i.

Regarding the formatting, I personally am not so fond of (see also the testfile before formatting):

- inline comments getting 'unaligned'. I have usually an aligned column for comments with enough visual distance, which I find much easier to read than comments tacked directly behind code.

- tabs for panel control elements being replaced without aligning equal signs (pos={}, size={} etc.). I have panel code also heavily aligned to make the code easily readable.

- equal signs of #pragma not being aligned

The latter two I can 'fix' myself, e.g., by setting an IPT_FORMAT_OFF there. But I am not willing to go through all my hundred comments to realign them after formatting, so no use for this particular feature for me now. It would be great to have a switch for 'leave comment indentation alone'. (Yes, I am aware that this kind of commenting might be considered bad style, but I want comments to sit out of the way and not in-between actual code if I can avoid it).

> If I understand you correctly, some warnings do not appear because they are apparently fixed (without actually being fixed in my case).
 

That's definilty odd. We'll have a look.

> - inline comments getting 'unaligned'. I have usually an aligned column for comments with enough visual distance, which I find much easier to read than comments tacked directly behind code.

That's getting into the taste area. I actually prefer comments in their own lines instead of trailing comments. But that is not something ipt can fix. Now of course we could a flag to keep comments, but until now we tried very hard to not have any knobs for the formatter. The reason is that the complexity of testing and documentation explodes with knobs. A bad example is clang-format (formatter for C++) where you even have tools like https://clang-format-configurator.site/ to help with writing the config file.

> - tabs for panel control elements being replaced without aligning equal signs (pos={}, size={} etc.). I have panel code also heavily aligned to make the code easily readable.

We try to always use recreation macros where the macro code is stored in separate files. So I rarely look at GUI code like that. I'll make a note.

> - equal signs of #pragma not being aligned

I need to think about this one.

Hello, I am one of the developers of this tool. First of all, I appreciate your feedback.

> - Apparently, ipt lint and ipt lint -i shows different output for my files (the latter showing MUCH more warnings). I guess this is intended, but I don't get it. Does the -i flag include a setting for a more limited set of checks?

I looked into the details. Apparently, if we have at least one warning or error for that specific file, nothing changes. We always try to have no warnings in our code, so this bug went unnoticed until now.

> First, I would like to note that ANSI escape code parsing is apparently switched off by default on windows which makes the output from this tool near unreadable.

Interesting, because on my Windows it worked right out of the box, so I didn't think much about it. But I use the modern Windows Terminal and VS code all the time. We can update our documentation to highlight this problem. The solution is to add `--color=no` to your arguments.

Thank you for the follow-up. Regarding the ANSI support, it may be that you have set everything up a long time ago to work with the terminal. I can have a look at another PC, but it initially didn't work ... neither with the terminal nor with Powershell both in ver. 5.1 or 7.5. I just tested it, and color=no works under these circumstances at least.

Another small thing: When there is a warning about a switch statement, the parser seems to include either the \r or \n or something else in the output. See the attached image.

In case a line termination (\r, \n or \r\n) is part of the code with error, we print a replacement character ⏎ [1] to the output. This is only visible if Windows is setup to use Unicode, which is unfortunately not the default and requires administrative changes [2]. I'll create an internal issue, so we can fix this and add some documentation.

[1]: https://www.compart.com/en/unicode/U+23CE

[2]: https://superuser.com/a/1435645