change the processing of init files

[ler762]

• add a new "-no-config" command line option to not read any initialization file

• refactor init file processing so that only one file is read
  The search order is:

1. command line "-config xxx" or "-no-config" options
2. environment variable HTML_TIDY=xxx
3. ~/.tidyrc
4. /etc/tidy.conf

[geoffmcl]

See issue #752 for a comment on this PR... in general I do not see the need for this...

Or at least needs a hefty discussion...

[geoffmcl]

@ler762 sorry, but think we have to close this PR...

There are several reasons for this, but the main one is technical. Somehow github has got it wrong...

Github shows ler762 wants to merge 1 commit into htacg:next from unknown repository... what is this unknown repository? not a lot of confidence in that...

And when I tried to use the command line to make a merge into a branch to do testing, it failed... saying some patch, or something, is missing... huh?

Usually works, and is one way admin has to merge a PR into a branch, build, and test, before the final merge to stable next... that is without cloning the full fork...

It does still show This branch has no conflicts with the base branch, thus the Merge Button is enabled... but does not feel safe... so it should be closed...

I am not sure it is your fault, but did you do something drastic to your fork after setting up the PR? Or something else...

Or is is that PR #755 was closed, and it contains the same commit 84b3e80 as here... good to know if true, but do not know...

But aside from that it is quite incomplete, even if eventually conceptually accepted...

1. It introduces a new undocumented option, -no-config - this needs to be added, and documented...
2. The man tidy help text, in man/tidy1.xsl.in - would need to be adjusted...
3. May conflict with PR Issue 752 #764, which more exactly addresses mute in ~/.tidyrc runs fine but triggers exit(1) #752, and contains several other needed fixes...
4. Is moved into the loop and seems to ignore the fact that tidy supports multiple options1 input1.html option2 input2.html ... on the command line...

The 4th may not be a problem, but needs to be thought through, tested, discussed, etc...

Finally, if you want to pursue this Feature Request then open an issue for it first, to discuss it, although various comments are scattered in other issues - maybe bring them together -

At this time I am not convinced it is needed or desired, except by you of course, and perhaps @blacktrash, not sure... sorry...

Am really puzzled why github shows unknown repository, and fails an admin test merge... any thoughts on why very much appreciated... just to be able to help, report, understand, advise in future... thanks...

[ler762]

@geoffmcl no problem - go ahead and close it.

... did you do something drastic to your fork after setting up the PR?
Am really puzzled why github shows unknown repository ...

I've deleted & recreated my fork on github a couple of times. I'm treating it as a temporary sandbox vs. something that has to be maintained - which might be a Bad Idea.

I'll try to pull all the comments together and create a new issue/feature request.

[geoffmcl]

@ler762 well if github maintained some type of check-sum for a fork, then I guess deleting & recreating that fork might put it in a tizzy fit ;=))

One pet dislike I have about such sort of hidden config files is that -h, and specially the new -help-env, do not spell it out clear enough... could do more...

It does mention /etc/tidy.conf, and ~/.tidyrc, which is good, but does not mention if one or either exists... like it does mention that $HTML_TIDY is set or not, but then not whether the file exists, if set...

While this does not directly relate to the order in which these are processed, for issues like #742, asking the user to show an enhanced output of -help-env would go a long way to clearing this up...

And that help text would need to also be adjusted if the order of processing is changed...

Look forward to any new feature request... thanks...