How to tidy document?

[Andrew Truckle]

You know how some editors let you prettify the document by correcting all the tabs etc? How can we achieve this with Scintilla? Thank you.

[Neil Hodgson]

Andrew:

> You know how some editors let you prettify the document by correcting all the tabs etc? How can we achieve this with Scintilla?

Look in SciTE for commands like Option | Convert Line End Characters, Option | Change Indentation Settings … | Convert.

Neil

[Andrew Truckle]

Hi

It helps, but it only governs how the tabs etc are treated. It won't tidy a file up and re-tabulate etc to make it look good.

[seasoned_geek]

Well,

In RedDiamond, for now, I run Artistic Style on the file. Currently shelling out to run and dumping to a temporary file that gets reloaded into existing buffer. Admittedly brute force, but I didn't have time and patience to look into all of the licensing issues involved with bundling the library/code from AS with my editor. You will notice many OpenSource IDEs have a "style plugin" that does nothing more than shell out to Artistic Style like I do and reload the output into the edit buffer.

Up-side:

AS has an ocean of parameters, uses an external hidden config file, has pre-defined "coding styles" and when used in brute force method as above, can be completely undone with one <ctrl>-z.

Down-side:

Limited number of languages supported. If your language isn't supported it won't pretty up anything. If you want to change TABs to spaces in a data or COBOL file, you are SOL.

For brute force things like changing tabs to spaces, indent sizes, spacing around () [] {}, etc. regardless of language take a look here:

https://sourceforge.net/p/reddiamond/code/ci/master/tree/src/edtbasewidget.cpp

the code near line 2495 and 2709 should point you in the correct direction. You want to follow the logic path where "range" is WHOLE

Fundamentally you need to split your definition up or rather your requirement.

1. Converting TABs to spaces, changing tab size, changing EOL character(s), proper casing, camel casing, etc. are CONTENT CONVERSIONS.
2. "Pretty up" requires a _language specific_ coding style. It also collides with things like the Barr Group Coding Standard for Embedded Systems. This then evolves into things like MISRA Standards. Both of these standards, have the same fundamental definition of "pretty." Pretty code is code that won't kill people. This is vastly different than the coding standards of Agile shops.

You can handle the first part on your own taking guidance from the code I pointed you towards. Just be extremely careful when inside of single or double quotes unless you inform your user it is brute force only. 

The second point above is a lot more work. CppCheck, at least the free to use version, doesn't even implement full MISRA. Most of the IDEs claiming to have "plug-in support" for CppCheck shell out to run whatever you have installed. Exactly who is getting what kickback I do not know. I just find it rather amazing that the industry is right back to "Crippleware." This was big in the 1980s and dial-up BBS days. People would release Crippleware as "freeware" or "shareware" and to get full functionality you had to pay for a commercial license. Personally I find it morally reprehensible when something starts off as OpenSource with lots of people contributing, then someone takes it commercial, but that's a soap box for another day.