Why doesn't Tidy, tidy source files that are included in the main file?

[cappy2112]

I've got a project consisting of 3 files, one of which is the main file.

The other two files are included in the main file, yet Tidy doesn't tidy thes. I have to do each file separately.

Why doens't it read in and tidy the included sources ?

Edited January 24, 2006 by cappy2112

[The Kandie Man]

It doesn't tidy the included sources because it wasn't designed to tidy included files. For example, the file.au3 and array.au3 are included in many programs. People don't really edit these files so if you were to tidy the script and it did the included files then it would have to do the file.au3 and array.au3 files as well. This would be stupid since the user didn't create the header files and doesn't need them to be cleaned up. I myself have one script with five or six header files included that i don't edit. If tidy was to clean them everytime i told it to tidy my script it would take forever and be very frustrating. Therefore you have to manually open the included files to tidy them. If you are really frustrated with this i would recommend simply copying and pasting the script in the included files into your main script file.

[cappy2112]

It doesn't tidy the included sources because it wasn't designed to tidy included files. For example, the file.au3 and array.au3 are included in many programs. People don't really edit these files so if you were to tidy the script and it did the included files then it would have to do the file.au3 and array.au3 files as well. This would be stupid since the user didn't create the header files and doesn't need them to be cleaned up. I myself have one script with five or six header files included that i don't edit. If tidy was to clean them everytime i told it to tidy my script it would take forever and be very frustrating. Therefore you have to manually open the included files to tidy them. If you are really frustrated with this i would recommend simply copying and pasting the script in the included files into your main script file.

I"m referring to MY sources that are included, as indicated in the message, not stuff that comes with AutoIt

[PsaltyDS]

I"m referring to MY sources that are included, as indicated in the message, not stuff that comes with AutoIt

That still leaves you with the original answer: it doesn't because it isn't supposed to. In all situations I can think of, that behavior would be a BUG, not a feature. You can have more than one file open at a time in SciTE, and then just hit ctl-t once in each of them... you could probably even script that!

[Jos]

I've got a project consisting of 3 files, one of which is the main file.

The other two files are included in the main file, yet Tidy doesn't tidy thes. I have to do each file separately.

Why doens't it read in and tidy the included sources ?

As mentioned, I have not designed Tidy to process more than the file being edited, for the simple fact that I assume that the Included files are already coded, functioning and Tidied by you or Tidy.

Give me one good reason why you would want to Tidy code you are not editing ?

I"m referring to MY sources that are included, as indicated in the message, not stuff that comes with AutoIt

How in the world would Tidy know what is your code and what is standard included ?

[Stumpii]

Maybe there could be a checkbox to check included user files.

The user includes are always in double quotes (#include "myfiletoinclude.au3"), the standard includes are always in angled brackets (#include <Array.au3>). This could be used to differentiate one from the other.

[Jos]

Maybe there could be a checkbox to check included user files.

The user includes are always in double quotes (#include "myfiletoinclude.au3"), the standard includes are always in angled brackets (#include <Array.au3>). This could be used to differentiate one from the other.

Not totally correct ...

It just determines the seach order, but when using #include<> you could still refer to a users own include library.

But even if we would find logic to determine this, i will not make the change to the Tidy program for the reason I defined in the first paragraph of my previous post......

Edited January 24, 2006 by JdeB

[SmOke_N]

I have to agree with with Jdeb. You would think after you do each script that you would Tidy it (At least I do). Whether it be an include or a regular file, I find myself Tidying throughout the script to make sure I don't have simple errors for 1, and I like the idea it keeps a back up 'old1' - 'old2' etc... as I'm strumming along.

I have a script that goes through the includes, and alters them, that's just one more thing that could go wrong, and when your trying to fix something, you assume that the #includes are not the issue, that the actual script that was using the #includes was. Now if you start going through Tidy you could run into other errors.

Isn't it enough that the Au3Check goes through it? I mean if you are going to make the script an executable, you don't intend for others to see the source anyway... and if they find a way to do that... what do you care if the source is all nice and neat .

I vote for not having the extra work of including the '#includes' in the tidy, that's just going to take more time in getting the job done. And as I said should be done with each #include anyway as they are being written, or finished IMHO.

My 0.02 cents...

[Gene]

Hi JdeB,

I agree with you and others with similar views as regards Tidy and this thread.

However, you addressed the idea of a user's include library. I am VERY MUCH in favor of that. I would like to be able to keep the "official" UDFs and my own and other's UDFs separate without the hassle keying in a long path. If the User UDF path was specified in an INI file it would be great. The compiler and AutoIt could look first in the "official" location and then in folder specified if any includes were not found in the "official" location. This same idea could be extended a bit and be helpful with ZIP installs as to where the "official" and "User" includes are.

Gene

Not totally correct ...

It just determines the seach order, but when using #include<> you could still refer to a users own include library.

But even if we would find logic to determine this, i will not make the change to the Tidy program for the reason I defined in the first paragraph of my previous post......

[cappy2112]

Give me one good reason why you would want to Tidy code you are not editing ?

How in the world would Tidy know what is your code and what is standard included ?

What do you mean by not editing?

I am working on a program which has 3 files at the moment?

I have all three of them open in scite, so I am editing all 3.

[cappy2112]

How in the world would Tidy know what is your code and what is standard included ?

THis could be handled any number of ways.

In a C compiler include "file.h" has a slightly different meaning from include <file.h>.

That's just one example.

[Jos]

Hi JdeB,

I agree with you and others with similar views as regards Tidy and this thread.

However, you addressed the idea of a user's include library. I am VERY MUCH in favor of that. I would like to be able to keep the "official" UDFs and my own and other's UDFs separate without the hassle keying in a long path. If the User UDF path was specified in an INI file it would be great. The compiler and AutoIt could look first in the "official" location and then in folder specified if any includes were not found in the "official" location. This same idea could be extended a bit and be helpful with ZIP installs as to where the "official" and "User" includes are.

Gene

I would prefer if we would make a change so that #Include<..> would search:

- "AutoIt3 program directory"\include for the standard includes. (This facilitates to have a seperate set of includes for Production and Beta)

- possible added directories for users own include directory. (via a registry entry ?) Think this was proposed by Valik before)

- Then looks in the Script Directory.

#include".." would go in reverse order..

[Jos]

What do you mean by not editing?

I am working on a program which has 3 files at the moment?

I have all three of them open in scite, so I am editing all 3.

Then do a Ctrl+T on the buffer you are aditing at that moment.

I have the impression you are not agreeing with any of the arguments made ... correct ?

[PsaltyDS]

THis could be handled any number of ways.

In a C compiler include "file.h" has a slightly different meaning from include <file.h>.

That's just one example.

That doesn't change the objection that actions should happen on the file that is being edited, not on others. I wouldn't want Search/Replace to happen on my include files, for example. Just because the main needs tidying, that doesn't mean the include files do. And in the vast majority of cases they wouldn't. The include files only need tidying if you change them, which means you have them open. In your case, with the main and two includes open in SciTE, just click through the three tabs and hit ctl-t on each one.

One of the ways I use Tidy is to give me intermediate backups. Every time I hit ctl-t/CR, I not only get tidied, I get a point-in-time backup to *.old<n>.au3. Once you are done messing with an include file and are only working on the main, you don't want or need to be making changes (or backups) to those files.

I like the idea of a defined user's include section, and I already use subfolders of the default Include folder for that. It might be nice to define that in an .ini setting, so it didn't have to be coded. My includes currently look like:

; Include files section
#include <array.au3>
#include <Project123\_MyIncludeFunc.au3>

Edit: Tweak dumb typo...

Edited January 24, 2006 by PsaltyDS

[cappy2112]

Then do a Ctrl+T on the buffer you are aditing at that moment.

I have the impression you are not agreeing with any of the arguments made ... correct ?

>>I have the impression you are not agreeing with any of the arguments made ... correct ?

I am not disagreeing with them.

I just think it's more convenient to have a mechanism to tidy an entire project with one click or Ctrl-T.

With 3 files, it's not that much of a problem yet, but I envision that it will grow.

So for larger projects, it's just plain inconvenient to have to tidy each one separately.

Just a thought.

[SmOke_N]

>>I have the impression you are not agreeing with any of the arguments made ... correct ?

I am not disagreeing with them.

I just think it's more convenient to have a mechanism to tidy an entire project with one click or Ctrl-T.

With 3 files, it's not that much of a problem yet, but I envision that it will grow.

So for larger projects, it's just plain inconvenient to have to tidy each one separately.

Just a thought.

Well the source for Tidy is right there in your AutoIt folder, had you attempted with any varying success on doing it yourself? (Just a question, Not to be made to sound rude or off the beaten path).

[GaryFrost]

>>I have the impression you are not agreeing with any of the arguments made ... correct ?

I am not disagreeing with them.

I just think it's more convenient to have a mechanism to tidy an entire project with one click or Ctrl-T.

With 3 files, it's not that much of a problem yet, but I envision that it will grow.

So for larger projects, it's just plain inconvenient to have to tidy each one separately.

Just a thought.

With SciTE and autoit there is no project, just individual scripts.

[PsaltyDS]

With SciTE and autoit there is no project, just individual scripts.

Doesn't AutoIT kind of have the same philosophical disclaimer Perl does? Something like: "This is a scripting language, not a general programing language. If you are doing huge/expensive projects and your mortgage depends on it, use a 'real' programming language instead."

I think I remember somebody refering to that as "WhipItUptivity" in Perl...

[cappy2112]

With SciTE and autoit there is no project, just individual scripts.

user defined script files included as part of the main script can be thought of as a project, since they are all needed for that app to run.

[cappy2112]

Doesn't AutoIT kind of have the same philosophical disclaimer Perl does? Something like: "This is a scripting language, not a general programing language. If you are doing huge/expensive projects and your mortgage depends on it, use a 'real' programming language instead."

I think I remember somebody refering to that as "WhipItUptivity" in Perl...

Who knows.

I am using Autoit because it can do things perl can't do.