> I agree, it would be better to use HIGHLIGHT_SYNTAX. If the value is
> not a known value, then the command would be called. I prefer a called
> with fixed informations rather than %X arguments replacement. That
> means that users would have to use wrappers to translate the arguments
> to a command doing the highlighting, but that does not seems to be an
> issue to me.
The suggestion is to follow the behavior of my patch but to use the existent
variable, right? If "source-highlight --src-lang" is set as
HIGHLIGHT_SYNTAX, the command that will be called for an "@example perl"
will be "source-highlight --src-lang perl". The @example text will be
used as stdin of the command and the command stdout will be used as the
highlighted HTML. Is that correct?
> There are two modes for HIGHLIGHT_SYNTAX. Pass fragments on stdin and
> get results on stdout. In that case, I think that the only argument
> should be the $language. The other possibility is to go through input
> and output files, with fragments to be highlited separated by
>
> _______________________ $counter\n
>
> line ranges passed on the command line and the output files is supposed
> to use a range separator passed on the command line. In that case, more
> arguments should be passed, the language, the input and output files,
> the line ranges and the range separator.
Considering that you are fine with users having to write their own
wrappers, WDYT about just using the stdin and stdout instead of also
accept input/output files? So the new variable you suggested can be
used to format the data sent over stdin.
Example "-c HIGHLIGHT_SYNTAX_BULK_SEPARATOR=-->8--":
stdin:
my example fragment 1
-->8--
my example fragment 2
expected stdout:
<b>my example fragment 1</b>
-->8--
<b>my example fragment 2</b>
So we could use the same separator to identify the highlighted fragment
expecting that they came out at the same order.
> Maybe using a user-specified command could be first implemented for
> the first mode only.
Sorry, I didn't understand what you meant.
> No problem with breaking HIGHLIGHT_SYNTAX (reasonably), this is marked
> clearly as experimental.
If breaking changes are not an issue, do you think we can stop receiving
the programs and expect customers to update their HIGHLIGHT_SYNTAX
config with a command-line to be executed?
Because considering we start accepting a command-line, users will be
able to replace "-c HIGHLIGHT_SYNTAX=source-highlight" with
"-c HIGHLIGHT_SYNTAX=source-highlight --src-lang" and they will have
almost the same behaviour, except that:
1. They will not have the bulk optimization
2. They will not have the language map translation (currently, it swap
C++ to C since source-highlight does not expects C++ as --src-lang).
The same may be achievable by the other highlighters (I have only tested
with source-highlight so far).
Regarding the optimization, the document may need to have a huge number
of examples to this become an issue. For users for whom performance is
sensitive, they have the option to use the bulk option and write their
own wrapper.
This will significantly simplify the highlight logic and the tex2any
will no longer have so much knowledge on the external tools used to
highlight.
But if you think it is better to keep the current behaviour and
treat unknowns programs to be treated as command to be executed I can
just extend the current implementation to support it.
> Carlos, do you want to have a try? Since the patch will not be small,
> you'll have to do a Copyright assignment with the FSF if you do not have
> already.
Sure! I would love to try to make these changes. I never did the FSF
copyright assignment I will go after it.
