merge.
- Sort all of the existing options and re-indent per Tidy standards. This is
simply for cosmetic effect.
- Allow the iterator to return all options again, even "internal" options.
Things are too embedded with N_TIDY_OPTIONS, etc., to try to hide them.
- Instead, simply add documentation to LibTidy users that they shouldn't use
internal options.
- Also added `TidyInternalCategory` to `TidyConfigCategory` without adding a
new field to the struct. API users should check for this category before
use.
- Defined a two character macro for `TidyInternalCategory` for use in
`option_defs[]`.
- Changed struct `option_defs[]` to reflect the new category for affected
options.
- Removed string indicating * refers to internal options, since it no longer
applies.
- Regen'd all strings for previous point.
- `tidy.c` now checks for `TidyInternalCategory` everywhere in order to
suppress output.
- Updated strings files to match.
- Inhibit internal options from being output via the iterator. Internals should
never have the chance to be exposed if they shouldn't be use.
- Added tidySetEmacsFile() and TidyGetEmacsFile() to the public API, and use it
instead of secret API to set the filename in the console application.
The end result is that `gnu-emacs-file` (and also `doctype-mode`) officially no
longer exist to CLI users nor to API users, and tidy console behaves properly
by using a published API to set the filename for emacs.
- TidySlideStyle
- TidyBurstSlides
- Added documentation for TidyEmacsFile, since it's a valid option.
- Because TidyEmacsFile is a valid option, tweaked tidy.c so that it can
be specified in a configuration file without being overwritten by the console
app. Why a user might do this is dumb, but who are we to stop them.
- Consolidated all output string definitions enums into `tidyenum.h`, which
is where they belong, and where they have proper visibility.
- Re-arranged `messages.c/h` with several comments useful to developers.
- Properly added the key lookup functions and the language localization
functions into tidy.h/tidylib.c with proper name-spacing.
- Previous point restored a *lot* of sanity to the #include pollution that's
been introduced in light of these.
- Note that opaque types have been (properly) introduced. Look at the updated
headers for `language.h`. In particular only an opaque structure is passed
outside of LibTidy, and so use TidyLangWindowsName and TidyLangPosixName
to poll these objects.
- Console application updated as a result of this.
- Removed dead code:
- void TY_(UnknownOption)( TidyDocImpl* doc, char c );
- void TY_(UnknownFile)( TidyDocImpl* doc, ctmbstr program, ctmbstr file );
- Redundant strings were removed with the removal of this dead code.
- Several enums were given fixed starting values. YOUR PROGRAMS SHOULD NEVER
depend on enum values. `TidyReportLevel` is an example of such.
- Some enums were removed as a result of this. `TidyReportLevel` now has
matching strings, so the redundant `TidyReportLevelStrings` was removed.
- All of the PO's and language header files were regenerated as a result of
the string cleanup and header cleanup.
- Made the interface to the library version and release date consistent.
- CMakeLists.txt now supports SUPPORT_CONSOLE_APP. The intention is to
be able to remove console-only code from LibTidy (for LibTidy users).
- Updated README/MESSAGES.md, which is *vastly* more simple now.
This is intended to make it very, very easy to update the POT and all of the POs when
changes are made to `language_en.h`. Used without an sha-1 hash, untranslated strings
(i.e., the "source" strings) are updated in the POT/PO's.
However if you specify an --sha=HASH (or -c HASH) option, then the script will use git
to examine the `language_en.h` file from that specified commit, determing the strings
that have changed, and mark all of these strings as `fuzzy` in the POs. This will serve
as a flag to translators that the original has changed. In addition, this `fuzzy` flag
will appear in the headers as "(fuzzy) " in the item comments.
If a translator edits the header directly, he should remove the "(fuzzy )" in the
comment. Then when the PO is rebuilt, the fuzzy flag will be removed automatically.
The reverse is also true; if a translator is working with the PO, he or she should
clear the fuzzy flag and the comment will be adjusted accordingly in the generated
header.
