You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think I made the wrong decision to confine the DIY rep implementation to a Makefile. I think we should use shell-scripts as for the built-ins. These could, of course, include a Makefile (as does MTT). However, I do think it best to include all the languages in the one script, and the script always returns 2 (or some other non-zero error) if it does not implement a particular language.
Interface:
We extend mtt to include representation-specific options:
mtt [mtt-options] sys [rep-options] newrep lang
mtt then tries to run:
mtt_rep_newrep [rep-options] lang
...if the rep does not exist, mtt proper is invoked (as at present). But this also happens if mtt_rep_newrep returns 2 as above.
I think this overcomes the problem you mention in the previous mail. That is, newrep can extend (or indeed replace) built-in representations to include new languages.
All DIY reps can be interrogated by mtt e.g.:
mtt_rep_newrep --help writes helpful text to standard output
mtt_rep_newrep --usage writes usage info to standard output
mtt_rep_newrep --texi wites texinfo documentation to standard output
This provides the basis for a comprehensive help facility in mtt.
I like the idea of a single file for all of this; thus the script would contain other files and write them as
necessary.
The text was updated successfully, but these errors were encountered:
As discussed, we need a new DIY rep.
Here is what I propose:
Implementation:
I think I made the wrong decision to confine the DIY rep implementation to a
Makefile
. I think we should use shell-scripts as for the built-ins. These could, of course, include aMakefile
(as does MTT). However, I do think it best to include all the languages in the one script, and the script always returns 2 (or some other non-zero error) if it does not implement a particular language.Interface:
We extend mtt to include representation-specific options:
mtt [mtt-options] sys [rep-options] newrep lang
mtt then tries to run:
mtt_rep_newrep [rep-options] lang
...if the rep does not exist, mtt proper is invoked (as at present). But this also happens if
mtt_rep_newrep
returns 2 as above.I think this overcomes the problem you mention in the previous mail. That is,
newrep
can extend (or indeed replace) built-in representations to include new languages.All DIY reps can be interrogated by mtt e.g.:
mtt_rep_newrep --help
writes helpful text to standard outputmtt_rep_newrep --usage
writes usage info to standard outputmtt_rep_newrep --texi
wites texinfo documentation to standard outputThis provides the basis for a comprehensive help facility in mtt.
I like the idea of a single file for all of this; thus the script would contain other files and write them as
necessary.
The text was updated successfully, but these errors were encountered: