Console that starts with an output
29 views
Skip to first unread message
Andrew Scholer
Nov 13, 2024, 1:29:11 PM11/13/24
to prete...@googlegroups.com
Currently, according to the schema and documentation, a console must have an input before the first output.
I would like to relax that to allow a leading output, which feels more standard for showing a sample run of a console based program. (Example below)
I would like to relax that to allow a leading output, which feels more standard for showing a sample run of a console based program. (Example below)
Are there any objections or problems that would cause?
To demonstrate the running of a program, texts would show (user input in bold):
------------------------------------------------------
Enter a decimal number 1-99:
42
That is XLII in Roman numerals
As opposed to:
------------------------------------------------------
> ./randomexename
Enter a decimal number 1-99:
42
That is XLII in Roman numerals
------------------------------------------------------> ./randomexename
Enter a decimal number 1-99:
42
That is XLII in Roman numerals
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
Rob Beezer
Nov 13, 2024, 2:53:47 PM11/13/24
to prete...@googlegroups.com
Conceptually, I think of a console as *requiring* an input, in order to get an
output. So PreTeXt is enforcing this. Of course, the schema says so, but iirc,
the code itself is organized around a template for #input that looks for an
adjacent, trailing, optional, #output. This device allows the markup to be a
sequence instead of some repeated child of #console, grouping each {#input,
#output} pair together. Generally, that sort of extra markup is desirable, but
places a burden on authors. This is a place where we cut a corner to spare
authors (and have not yet regretted it).
An alternative is #cd, which can be used *inside* a #p (like #md). But you
won't get the bolding of the user input.
Rob
On 11/13/24 10:28, Andrew Scholer wrote:
> Currently, according to the schema and documentation, a console must have an
> input before the first output.
>
> I would like to relax that to allow a leading output, which feels more standard
> for showing a sample run of a console based program. (Example below)
>
> Are there any objections or problems that would cause?
>
> To demonstrate the running of a program, texts would show (user input in bold):
> ------------------------------------------------------
> Enter a decimal number 1-99:
> *42*
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com
> <mailto:pretext-dev...@googlegroups.com>.
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/CACm44N9EPOUp4jUUKpnEXzhCcULGSYVjvWArCHGWG38RgNu11A%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CACm44N9EPOUp4jUUKpnEXzhCcULGSYVjvWArCHGWG38RgNu11A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
output. So PreTeXt is enforcing this. Of course, the schema says so, but iirc,
the code itself is organized around a template for #input that looks for an
adjacent, trailing, optional, #output. This device allows the markup to be a
sequence instead of some repeated child of #console, grouping each {#input,
#output} pair together. Generally, that sort of extra markup is desirable, but
places a burden on authors. This is a place where we cut a corner to spare
authors (and have not yet regretted it).
An alternative is #cd, which can be used *inside* a #p (like #md). But you
won't get the bolding of the user input.
Rob
On 11/13/24 10:28, Andrew Scholer wrote:
> Currently, according to the schema and documentation, a console must have an
> input before the first output.
>
> I would like to relax that to allow a leading output, which feels more standard
> for showing a sample run of a console based program. (Example below)
>
> Are there any objections or problems that would cause?
>
> To demonstrate the running of a program, texts would show (user input in bold):
> ------------------------------------------------------
> Enter a decimal number 1-99:
> That is XLII in Roman numerals
> ------------------------------------------------------
>
> As opposed to:
> ------------------------------------------------------
> > *./randomexename*
> ------------------------------------------------------
>
> As opposed to:
> ------------------------------------------------------
> Enter a decimal number 1-99:
> *42*
> That is XLII in Roman numerals
> ------------------------------------------------------
>
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/
> <http://computerscience.chemeketa.edu/people/andrew-scholer/>
> ------------------------------------------------------
>
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com
> <mailto:pretext-dev...@googlegroups.com>.
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/CACm44N9EPOUp4jUUKpnEXzhCcULGSYVjvWArCHGWG38RgNu11A%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CACm44N9EPOUp4jUUKpnEXzhCcULGSYVjvWArCHGWG38RgNu11A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Andrew Scholer
Nov 13, 2024, 4:00:42 PM11/13/24
to prete...@googlegroups.com
Pendantically, I would argue that the output almost always comes first. A prompt is output even if pretext treats it as part of the input.
More importantly, the example I provided is a staple in programming texts. It is a standard thing for an author to want to write and thus it should be supported.
You already identified one issue with <cd>; it also would not allow for different treatment of "error". (Which doesn't exist yet, but interest has been expressed in an <error> for console that is styled differently than <output>/)
I suppose there could be a <program-console-session> that is exactly like console but can start with an <output>, but that seems silly.
Currently, output in both HTML and latex produce what looks to be correct output when <console> leads with an <output>. Looking at the code, I don't see anything that groups <input> and <output> in the way you describe. In both code paths, <console> simply does <xsl:apply-templates select="input|output" />.
Unless I am missing something in the code, the schema is enforcing limits that the code does not require. So why not relax the schema to support a standard authoring convention?
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAzMS5iZWV6ZXI.1731527624%40quikprotect.
Alex Jordan
Nov 13, 2024, 4:27:27 PM11/13/24
to prete...@googlegroups.com
Maybe instead of an "output" (that PTX wants to logically tie to an
"input") there could be an element by a different name. Like an
"introduction", but named more appropriately for the terminal history
that led up to that first prompt and input?
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N-1X7NVGW-RdewvDxRCbyQhey8tpeibrqm50afNAFzV%2Bw%40mail.gmail.com.
"input") there could be an element by a different name. Like an
"introduction", but named more appropriately for the terminal history
that led up to that first prompt and input?
Andrew Scholer
Nov 14, 2024, 9:58:11 AM11/14/24
to prete...@googlegroups.com
Alex -
I don't like the idea that an author would have to learn/remember "if I want to start a console session with output I need to actually call it XXXX" when in all ways other than being the first line, it is just output.
Where exactly does PTX tie the input/output together? As far as I can tell, the code already does what I want, I just want to relax the schema to match that.
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jrc__kv8f4t10-OUTByR%3DPTXVOT-pG2KKkmS1gwanpWtJA%40mail.gmail.com.
Rob Beezer
Nov 14, 2024, 10:59:46 AM11/14/24
to prete...@googlegroups.com
> More importantly, the example I provided is a staple in programming texts. It
is a standard thing for an author to want to write and thus it should be supported.
That argument might get you somewhere. I'd like to see such examples. Scan a
is a standard thing for an author to want to write and thus it should be supported.
page or two of a print book if you have to.
> I don't see anything that groups <input> and <output> in the way you describe.
barely have the time to keep up with discussions (nobody sees the off-list
traffic) and it is 7 PM before I get a chance to write any code and I'm out of
gas. Maybe it was the now-gone #prompt element that worked this way.
> the schema is enforcing limits that the code does not require.
Any permissiveness (naive, unintentional, or intentional) is not an argument
that will go anywhere at all. This is a step beyond the common implicit
argument: "But my HTML output looks lovely, so why won't my LaTeX compile?"
Rob
Charilaos Skiadas
Nov 14, 2024, 11:35:02 AM11/14/24
to prete...@googlegroups.com
I'm the new guy here, but I am curious why this limitation is there in the first place, it doesn’t feel like it’s buying much, in my mind, but maybe I’m missing something. I appreciate trying to guide the author, but I find this particular one getting in the way more than anything.
The way I am visualizing this, “input” is just tied to what is going into the input stream, and “output” tied to what comes out of the output stream, and then maybe I would like to see an “error” for the error stream. But it is not, in my opinion tied in a “function” way, where you have to provide an input before you get an output, and you always get an output when you provide an input. I can imagine having an input that doesn’t produce a corresponding output, (e.g. just typing x=3 in the Python REPL), and so I can imagine having two consecutive inputs without an output between them. You might argue I should then combine the inputs, but there is a difference between for example:
>>> x = 3
>>> print(x)
which is two distinct inputs, and
>>> for x in range(0,4):
... print(x)
...
which is a multi-line input.
I haven’t really used the console element much up to this point, mostly using the program element for what I am doing, so maybe there’s a way to distinguish those two cases. But if the answer to the first case is to force me to put in an empty output tag in-between the two input tags, I have to say I find that a bit questionable.
Btw is there a way to specify the continuation “…" part there, similar to how you can specify the prompt? I don’t see it in the spec, but it seems to me an integral part of a console experience.
Haris
Charilaos Skiadas
Professor in Mathematics and Computer Science
Hanover College
Professor in Mathematics and Computer Science
Hanover College
--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxMy5iZWV6ZXI.1731599985%40quikprotect.
Andrew Scholer
Nov 15, 2024, 11:33:00 AM11/15/24
to prete...@googlegroups.com
Charilaos - you can add @prompt to either the console or an individual input.
https://pretextbook.org/doc/guide/html/topic-program-console.html#topic-program-console-4-3
So in a long REPL session, you could set either >>> or ... as your console input as the "default" and then override that as needed in individual inputs.
Rob -
So in a long REPL session, you could set either >>> or ... as your console input as the "default" and then override that as needed in individual inputs.
Rob -
Here are some samples of what I am talking about:
Gaddis C++:
Savitch Absolute Java:
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com.
Andrew Scholer
Nov 15, 2024, 2:49:07 PM11/15/24
to prete...@googlegroups.com
In drop-in Rob asked for context around those samples. Here are expanded versions of those pictures. In those cases, the sample run follows a program listing. The new one has a different use case - showing a sample of the expected behavior of an answer to an exercise.
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
Rob Beezer
Nov 16, 2024, 5:38:33 PM11/16/24
to prete...@googlegroups.com
Thanks, Andrew. That is very helpful for these sorts of decisions, which we
like to do very carefully. What do you, and others, think of:
* #console is interleaved #input, #output; with no restrictions on
order/precedence. New #error to be considered.
* Right now schema says #listing can hold exactly one of #program, #console.
Examples suggest a pair (#program, #console) is customary. We could add that.
I don't see an intermediate #title as very feasible, but an indication of a
trailing sample run could go into the #title on the #listing. "Conversion from
Arabic to Roman numerals, with sample run"
Rob
On 11/15/24 11:48, Andrew Scholer wrote:
> In drop-in Rob asked for context around those samples. Here are expanded
> versions of those pictures. In those cases, the sample run follows a program
> listing. The new one has a different use case - showing a sample of the expected
> behavior of an answer to an exercise.
>
> image.png
>
>
> image.png
> Savitch Absolute Java:
>> <prete...@googlegroups.com <mailto:prete...@googlegroups.com>>
>> <mailto:pretext-dev%2Bunsu...@googlegroups.com>.
like to do very carefully. What do you, and others, think of:
* #console is interleaved #input, #output; with no restrictions on
order/precedence. New #error to be considered.
* Right now schema says #listing can hold exactly one of #program, #console.
Examples suggest a pair (#program, #console) is customary. We could add that.
I don't see an intermediate #title as very feasible, but an indication of a
trailing sample run could go into the #title on the #listing. "Conversion from
Arabic to Roman numerals, with sample run"
Rob
On 11/15/24 11:48, Andrew Scholer wrote:
> In drop-in Rob asked for context around those samples. Here are expanded
> versions of those pictures. In those cases, the sample run follows a program
> listing. The new one has a different use case - showing a sample of the expected
> behavior of an answer to an exercise.
>
>
>
> image.png
>
>
> image.png
>
>
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/
> <http://computerscience.chemeketa.edu/people/andrew-scholer/>
>
> image.png
>
>
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/
>
>
> On Fri, Nov 15, 2024 at 8:32 AM Andrew Scholer <andrew....@chemeketa.edu
> <mailto:andrew....@chemeketa.edu>> wrote:
>
> Charilaos - you can add @prompt to either the console or an individual input.
> https://pretextbook.org/doc/guide/html/topic-program-console.html#topic-program-console-4-3 <https://pretextbook.org/doc/guide/html/topic-program-console.html#topic-program-console-4-3>
>
> On Fri, Nov 15, 2024 at 8:32 AM Andrew Scholer <andrew....@chemeketa.edu
> <mailto:andrew....@chemeketa.edu>> wrote:
>
> Charilaos - you can add @prompt to either the console or an individual input.
> So in a long REPL session, you could set either >>> or ... as your console
> input as the "default" and then override that as needed in individual inputs.
>
> Rob -
>
> Here are some samples of what I am talking about:
>
> Gaddis C++:
> image.png
> input as the "default" and then override that as needed in individual inputs.
>
> Rob -
>
> Here are some samples of what I am talking about:
>
> Gaddis C++:
> Savitch Absolute Java:
> image.png
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/
> <http://computerscience.chemeketa.edu/people/andrew-scholer/>
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/
>> To view this discussion visit
>> https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxMy5iZWV6ZXI.1731599985%40quikprotect <https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxMy5iZWV6ZXI.1731599985%40quikprotect>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pretext-dev...@googlegroups.com
> <mailto:pretext-dev...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pretext-dev...@googlegroups.com
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com <https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com
> <mailto:pretext-dev...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/CACm44N8h2TqC4i_wHZYUf3v8H6q-rjUBCT48g1zGKaYNUKYN%2BA%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CACm44N8h2TqC4i_wHZYUf3v8H6q-rjUBCT48g1zGKaYNUKYN%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Rob Beezer
Nov 16, 2024, 5:48:35 PM11/16/24
to prete...@googlegroups.com
Dear Haris,
Thanks for your comments. Maybe you missed that #output is optional, so I think
that much of what you describe is already feasible. The discussion has centered
on requiring the *first* child of #console to be #input.
> is there a way to specify the continuation “…" part there
In truth, I designed this for the case of illustrating a bash (or similar shell)
session. Either as a necessary evil or as the main subject of a text. So not
much thought was given to interactive sessions with interpreted languages that
rely on whitespace for meaning. ;-) @prompt has recently moved from an element
to an attribute. I'd guess automatic continuation characters might even be
useful for something like long lines in bash. Perhaps a "text utility" template
to append the continuation-symbol (recursively to each line, as these things go
in XSL) would provide the meat for this. Could be a good bite-size project for
someone. Maybe even a "new guy here" (which you really aren't anymore). ;-)
Rob
> <mailto:pretext-dev...@googlegroups.com>.
Thanks for your comments. Maybe you missed that #output is optional, so I think
that much of what you describe is already feasible. The discussion has centered
on requiring the *first* child of #console to be #input.
> is there a way to specify the continuation “…" part there
session. Either as a necessary evil or as the main subject of a text. So not
much thought was given to interactive sessions with interpreted languages that
rely on whitespace for meaning. ;-) @prompt has recently moved from an element
to an attribute. I'd guess automatic continuation characters might even be
useful for something like long lines in bash. Perhaps a "text utility" template
to append the continuation-symbol (recursively to each line, as these things go
in XSL) would provide the meat for this. Could be a good bite-size project for
someone. Maybe even a "new guy here" (which you really aren't anymore). ;-)
Rob
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com <https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com?utm_medium=email&utm_source=footer>.
Andrew Scholer
Nov 16, 2024, 7:56:25 PM11/16/24
to prete...@googlegroups.com
The redefined console sounds great.
The listing expansion makes sense as well. Perhaps a console following a program in a listing could automatically get a very generic title like "Sample run". I could also see wanting to omit the console in situations where the program becomes an activecode - essentially authoring the console as a fallback for non-interactive formats. (In web versions of programming texts that allow running code you don't see many "Sample runs", instead you are just expected to run the program.)
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAzNC5iZWV6ZXI.1731796709%40quikprotect.
Charilaos Skiadas
Nov 17, 2024, 12:01:18 PM11/17/24
to prete...@googlegroups.com
1. You are correct Rob, I was misreading the spec, hadn’t realized the output part was optional. So is the proposed change on the schema level as simple as adding a question mark after the ConsoleInput in
Console =
element console {
Component?,
attribute prompt {text}?,
attribute width {text}?,
attribute margins {text}?,
(
ConsoleInput,
ConsoleOutput?
)+
}
2. I like the possibility of adding a “text utility” template for continuation, and I am imagining the continuation would be an attribute to #console? I’m not quite sure on where this goes in the files, I haven’t really messed around much with the XSLTs. Is this something that would somehow run on the PTX input regardless of target output? Or something that needs to be added to each target transformation?
3. On the #listing redesign front my particular use case would be for two or more #programs within the same #listing. One of the parts of my book is to discuss refactorings, and in those cases one would like to pair before-after versions of the code, and/or code from multiple files (e.g. a refactoring that moved a function from one file to another would have to show how both files have changed, but it’s still a cohesive unit). I can imagine WebApp examples that would contain in one listing code from multiple files. So having multiple #programs allowed would be very useful.
Haris
Charilaos Skiadas
Professor in Mathematics and Computer Science
Hanover College
Professor in Mathematics and Computer Science
Hanover College
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N91NV%3DCw0LHJLbr_6SrtNyTaQXas8RDSU5YM5KdYsqmAw%40mail.gmail.com.
Rob Beezer
Nov 18, 2024, 11:00:48 AM11/18/24
to prete...@googlegroups.com
On 11/16/24 16:55, Andrew Scholer wrote:
> The redefined console sounds great.
Maybe no new code, but as with any change, lots of other things to do. Schema
> The redefined console sounds great.
and documentation, mostly. And a test-worthy example in the sample article.
See some more comments in other replies.
> The listing expansion makes sense as well. Perhaps a console following a program
> in a listing could automatically get a very generic title like "Sample run". I
> could also see wanting to omit the console in situations where the program
> becomes an activecode - essentially authoring the console as a fallback for
> non-interactive formats. (In web versions of programming texts that allow
> running code you don't see many "Sample runs", instead you are just expected to
> run the program.)
can always be overwritten by an authored #title. So, (a) I do not want to add a
#title to #console (that's the role/purpose of #listing, a container to hold a
#console or #program), and (b) I'm reluctant to stick an author with a defalt
title/heading that may not be what they are really after. If one #title on the
enclosing #listing is not good enough, then it suggests they want two #listing.
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/
> <http://computerscience.chemeketa.edu/people/andrew-scholer/>
>
>
> <http://computerscience.chemeketa.edu/people/andrew-scholer/>>
> >
> >
> > On Fri, Nov 15, 2024 at 8:32 AM Andrew Scholer
> <andrew....@chemeketa.edu <mailto:andrew....@chemeketa.edu>
> > <mailto:andrew....@chemeketa.edu
> >
> >
> > On Fri, Nov 15, 2024 at 8:32 AM Andrew Scholer
> <andrew....@chemeketa.edu <mailto:andrew....@chemeketa.edu>
> <mailto:andrew....@chemeketa.edu>>> wrote:
> >
> > Charilaos - you can add @prompt to either the console or an
> individual input.
> >
> https://pretextbook.org/doc/guide/html/topic-program-console.html#topic-program-console-4-3 <https://pretextbook.org/doc/guide/html/topic-program-console.html#topic-program-console-4-3> <https://pretextbook.org/doc/guide/html/topic-program-console.html#topic-program-console-4-3 <https://pretextbook.org/doc/guide/html/topic-program-console.html#topic-program-console-4-3>>
> >
> > Charilaos - you can add @prompt to either the console or an
> individual input.
> >
> > So in a long REPL session, you could set either >>> or ... as your
> console
> > input as the "default" and then override that as needed in individual
> inputs.
> >
> > Rob -
> >
> > Here are some samples of what I am talking about:
> >
> > Gaddis C++:
> > image.png
> > Savitch Absolute Java:
> > image.png
> >
> > Andrew Scholer (he/him/his)
> > Computer Science Instructor
> > Chemeketa Community College
> > 503.589.7649
> > computerscience.chemeketa.edu/people/andrew-scholer/
> <http://computerscience.chemeketa.edu/people/andrew-scholer/>
> > <http://computerscience.chemeketa.edu/people/andrew-scholer/
> console
> > input as the "default" and then override that as needed in individual
> inputs.
> >
> > Rob -
> >
> > Here are some samples of what I am talking about:
> >
> > Gaddis C++:
> > image.png
> > Savitch Absolute Java:
> > image.png
> >
> > Andrew Scholer (he/him/his)
> > Computer Science Instructor
> > Chemeketa Community College
> > 503.589.7649
> > computerscience.chemeketa.edu/people/andrew-scholer/
> <http://computerscience.chemeketa.edu/people/andrew-scholer/>
> <http://computerscience.chemeketa.edu/people/andrew-scholer/>>
> >
> >
> > On Thu, Nov 14, 2024 at 8:35 AM Charilaos Skiadas <cski...@gmail.com
> <mailto:cski...@gmail.com>
> >
> >
> > On Thu, Nov 14, 2024 at 8:35 AM Charilaos Skiadas <cski...@gmail.com
> <mailto:cski...@gmail.com>
> <mailto:pretext-dev%252Buns...@googlegroups.com>>.
> >> To view this discussion visit
> >>
> https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxMy5iZWV6ZXI.1731599985%40quikprotect <https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxMy5iZWV6ZXI.1731599985%40quikprotect> <https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxMy5iZWV6ZXI.1731599985%40quikprotect <https://groups.google.com/d/msgid/pretext-dev/MTAwMDAxMy5iZWV6ZXI.1731599985%40quikprotect>>.
> >>
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to pretext-dev...@googlegroups.com
> <mailto:pretext-dev%2Bunsu...@googlegroups.com>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to pretext-dev...@googlegroups.com
> > <mailto:pretext-dev...@googlegroups.com
> https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com <https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com> <https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pretext-dev/C9E3AA62-8790-4EA8-9F3A-034E8AD55B0E%40gmail.com?utm_medium=email&utm_source=footer>>.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to pretext-dev...@googlegroups.com
> <mailto:pretext-dev%2Bunsu...@googlegroups.com>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > to pretext-dev...@googlegroups.com
> > <mailto:pretext-dev...@googlegroups.com
> https://groups.google.com/d/msgid/pretext-dev/CACm44N8h2TqC4i_wHZYUf3v8H6q-rjUBCT48g1zGKaYNUKYN%2BA%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CACm44N8h2TqC4i_wHZYUf3v8H6q-rjUBCT48g1zGKaYNUKYN%2BA%40mail.gmail.com> <https://groups.google.com/d/msgid/pretext-dev/CACm44N8h2TqC4i_wHZYUf3v8H6q-rjUBCT48g1zGKaYNUKYN%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pretext-dev/CACm44N8h2TqC4i_wHZYUf3v8H6q-rjUBCT48g1zGKaYNUKYN%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pretext-dev...@googlegroups.com
> <mailto:pretext-dev%2Bunsu...@googlegroups.com>.
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/MTAwMDAzNC5iZWV6ZXI.1731796709%40quikprotect <https://groups.google.com/d/msgid/pretext-dev/MTAwMDAzNC5iZWV6ZXI.1731796709%40quikprotect>.
> <mailto:pretext-dev%2Bunsu...@googlegroups.com>.
> To view this discussion visit
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com
> <mailto:pretext-dev...@googlegroups.com>.
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/CACm44N91NV%3DCw0LHJLbr_6SrtNyTaQXas8RDSU5YM5KdYsqmAw%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CACm44N91NV%3DCw0LHJLbr_6SrtNyTaQXas8RDSU5YM5KdYsqmAw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com
> <mailto:pretext-dev...@googlegroups.com>.
> To view this discussion visit
Rob Beezer
Nov 18, 2024, 11:28:40 AM11/18/24
to prete...@googlegroups.com
Dear Haris,
Replies interspersed.
> 1. You are correct Rob, I was misreading the spec, hadn’t realized the output
> part was optional. So is the proposed change on the schema level as simple as
> adding a question mark after the ConsoleInput in
> Console =
> element console {
> Component?,
> attribute prompt {text}?,
> attribute width {text}?,
> attribute margins {text}?,
> (
> ConsoleInput,
> ConsoleOutput?
> )+
> }
Dropping the question mark says that for every input there is a trailing output,
one-to-one, repeatedly. I think we want a mandatory {#input or #output} to lead
so the #console cannot be empty, or maybe a {#input-#output pair or a #output}
to lead. I think the latter reflects the original request.
> 2. I like the possibility of adding a “text utility” template for continuation,
> and I am imagining the continuation would be an attribute to #console? I’m not
> quite sure on where this goes in the files, I haven’t really messed around much
> with the XSLTs. Is this something that would somehow run on the PTX input
> regardless of target output? Or something that needs to be added to each target
> transformation?
Yes, I'd imagine a @continuation attribute, much like the @prompt attribute. A
"text processing" template to prepend the character would be recursive, with
parameters: remaining text, actual character, a flag saying the first line has
been skipped. If you would like to implement this, let me know when a Drop-In
session is convenient (Tuesday or Friday) and I can walk you through some of it.
> 3. On the #listing redesign front my particular use case would be for two or
> more #programs within the same #listing. One of the parts of my book is to
> discuss refactorings, and in those cases one would like to pair before-after
> versions of the code, and/or code from multiple files (e.g. a refactoring that
> moved a function from one file to another would have to show how both files have
> changed, but it’s still a cohesive unit). I can imagine WebApp examples that
> would contain in one listing code from multiple files. So having multiple
> #programs allowed would be very useful.
About 18 months ago, I told a meeting of the faithful that PreTeXt (the
language) was feeling pretty mature. So I wouldn't say we are doing a #listing
redesign. More of a tweak.
A #listing is a FIGURE-LIKE container to hold #program and #console so they are
more identifiable. #program and #console are atomic items in that they are not
built up from smaller pieces. In this case the container is meant to hold one
item. I've just conceded letting it hold two. I'd say a before-after refactor
is two listings, titled as such. Code from multiple files is several listings.
If you put code from many files into one listing, how are you going to delineate
them? Right now, at best you will get a small amount of vertical separation.
Nothing in braille. How are you going to reference these snippets, "The fifth
code hunk in Listing 8.32"?
#figure can hold #sidebyside, whose panels can be #listing. If the lines are
short, code and its refactor could be shown side-by-side.
Multiple files could be multiple #listing inside the "rows" of a #sbsgroup
(side-by-side group) inside a #figure. Maybe they get sub-numbered
automatically (Listing 8.23(e)) - if not, that might be a good enhancement, we
do it for #figure inside #sidebyside inside #figure. One caveat, too much of
this all packed together might stress the LaTeX conversion and its page-breaking.
Rob
Replies interspersed.
> 1. You are correct Rob, I was misreading the spec, hadn’t realized the output
> part was optional. So is the proposed change on the schema level as simple as
> adding a question mark after the ConsoleInput in
> Console =
> element console {
> Component?,
> attribute prompt {text}?,
> attribute width {text}?,
> attribute margins {text}?,
> (
> ConsoleInput,
> ConsoleOutput?
> )+
> }
one-to-one, repeatedly. I think we want a mandatory {#input or #output} to lead
so the #console cannot be empty, or maybe a {#input-#output pair or a #output}
to lead. I think the latter reflects the original request.
> 2. I like the possibility of adding a “text utility” template for continuation,
> and I am imagining the continuation would be an attribute to #console? I’m not
> quite sure on where this goes in the files, I haven’t really messed around much
> with the XSLTs. Is this something that would somehow run on the PTX input
> regardless of target output? Or something that needs to be added to each target
> transformation?
"text processing" template to prepend the character would be recursive, with
parameters: remaining text, actual character, a flag saying the first line has
been skipped. If you would like to implement this, let me know when a Drop-In
session is convenient (Tuesday or Friday) and I can walk you through some of it.
> 3. On the #listing redesign front my particular use case would be for two or
> more #programs within the same #listing. One of the parts of my book is to
> discuss refactorings, and in those cases one would like to pair before-after
> versions of the code, and/or code from multiple files (e.g. a refactoring that
> moved a function from one file to another would have to show how both files have
> changed, but it’s still a cohesive unit). I can imagine WebApp examples that
> would contain in one listing code from multiple files. So having multiple
> #programs allowed would be very useful.
language) was feeling pretty mature. So I wouldn't say we are doing a #listing
redesign. More of a tweak.
A #listing is a FIGURE-LIKE container to hold #program and #console so they are
more identifiable. #program and #console are atomic items in that they are not
built up from smaller pieces. In this case the container is meant to hold one
item. I've just conceded letting it hold two. I'd say a before-after refactor
is two listings, titled as such. Code from multiple files is several listings.
If you put code from many files into one listing, how are you going to delineate
them? Right now, at best you will get a small amount of vertical separation.
Nothing in braille. How are you going to reference these snippets, "The fifth
code hunk in Listing 8.32"?
#figure can hold #sidebyside, whose panels can be #listing. If the lines are
short, code and its refactor could be shown side-by-side.
Multiple files could be multiple #listing inside the "rows" of a #sbsgroup
(side-by-side group) inside a #figure. Maybe they get sub-numbered
automatically (Listing 8.23(e)) - if not, that might be a good enhancement, we
do it for #figure inside #sidebyside inside #figure. One caveat, too much of
this all packed together might stress the LaTeX conversion and its page-breaking.
Rob
Charilaos Skiadas
Nov 18, 2024, 10:02:07 PM11/18/24
to prete...@googlegroups.com
> On Nov 18, 2024, at 11:28 AM, 'Rob Beezer' via PreTeXt development <prete...@googlegroups.com> wrote:
>
> Dear Haris,
>
> Replies interspersed.
>
>> 1. You are correct Rob, I was misreading the spec, hadn’t realized the output part was optional. So is the proposed change on the schema level as simple as adding a question mark after the ConsoleInput in
>> Console =
>> element console {
>> Component?,
>> attribute prompt {text}?,
>> attribute width {text}?,
>> attribute margins {text}?,
>> (
>> ConsoleInput,
>> ConsoleOutput?
>> )+
>> }
>
> Dropping the question mark says that for every input there is a trailing output, one-to-one, repeatedly. I think we want a mandatory {#input or #output} to lead so the #console cannot be empty, or maybe a {#input-#output pair or a #output} to lead. I think the latter reflects the original request.
Console =
element console {
Component?,
attribute prompt {text}?,
attribute width {text}?,
attribute margins {text}?,
(
ConsoleInput,
ConsoleOutput?
)+
}
Or if we are ok with a console that only contains outputs, and/or contains consecutive outputs, we could simply have:
Console =
element console {
Component?,
attribute prompt {text}?,
attribute width {text}?,
attribute margins {text}?,
}
>> 2. I like the possibility of adding a “text utility” template for continuation, and I am imagining the continuation would be an attribute to #console? I’m not quite sure on where this goes in the files, I haven’t really messed around much with the XSLTs. Is this something that would somehow run on the PTX input regardless of target output? Or something that needs to be added to each target transformation?
>
> Yes, I'd imagine a @continuation attribute, much like the @prompt attribute. A "text processing" template to prepend the character would be recursive, with parameters: remaining text, actual character, a flag saying the first line has been skipped. If you would like to implement this, let me know when a Drop-In session is convenient (Tuesday or Friday) and I can walk you through some of it.
Tuesdays are the only day that works this term. I’ll try to drop in tomorrow. Would like to at least get started, though it may end up taking a while.
>> 2. I like the possibility of adding a “text utility” template for continuation, and I am imagining the continuation would be an attribute to #console? I’m not quite sure on where this goes in the files, I haven’t really messed around much with the XSLTs. Is this something that would somehow run on the PTX input regardless of target output? Or something that needs to be added to each target transformation?
>
> Yes, I'd imagine a @continuation attribute, much like the @prompt attribute. A "text processing" template to prepend the character would be recursive, with parameters: remaining text, actual character, a flag saying the first line has been skipped. If you would like to implement this, let me know when a Drop-In session is convenient (Tuesday or Friday) and I can walk you through some of it.
>> 3. On the #listing redesign front my particular use case would be for two or more #programs within the same #listing. One of the parts of my book is to discuss refactorings, and in those cases one would like to pair before-after versions of the code, and/or code from multiple files (e.g. a refactoring that moved a function from one file to another would have to show how both files have changed, but it’s still a cohesive unit). I can imagine WebApp examples that would contain in one listing code from multiple files. So having multiple #programs allowed would be very useful.
>
> About 18 months ago, I told a meeting of the faithful that PreTeXt (the language) was feeling pretty mature. So I wouldn't say we are doing a #listing redesign. More of a tweak.
>
> A #listing is a FIGURE-LIKE container to hold #program and #console so they are more identifiable. #program and #console are atomic items in that they are not built up from smaller pieces. In this case the container is meant to hold one item. I've just conceded letting it hold two. I'd say a before-after refactor is two listings, titled as such. Code from multiple files is several listings. If you put code from many files into one listing, how are you going to delineate them? Right now, at best you will get a small amount of vertical separation. Nothing in braille. How are you going to reference these snippets, "The fifth code hunk in Listing 8.32"?
>
> #figure can hold #sidebyside, whose panels can be #listing. If the lines are short, code and its refactor could be shown side-by-side.
>
> Multiple files could be multiple #listing inside the "rows" of a #sbsgroup (side-by-side group) inside a #figure. Maybe they get sub-numbered automatically (Listing 8.23(e)) - if not, that might be a good enhancement, we do it for #figure inside #sidebyside inside #figure. One caveat, too much of this all packed together might stress the LaTeX conversion and its page-breaking.
> Rob
Haris
Rob Beezer
Nov 18, 2024, 11:32:27 PM11/18/24
to prete...@googlegroups.com
Yes, I had that (better?) thought after letting my earlier response get away.
See you tomorrow morning.
See you tomorrow morning.
Andrew Scholer
Nov 19, 2024, 12:41:50 PM11/19/24
to prete...@googlegroups.com
I like the version that complicates the Input/Output logic the least and potentially allows for multiple consecutive inputs or outputs.
Console =
element console {
Component?,
attribute prompt {text}?,
attribute width {text}?,
attribute margins {text}?,
( ConsoleInput | ConsoleOutput )+
}
}
An author might want to think of two consecutive pieces of output as separate "chunks" of their source. The example below could be authored with a single <output> that contains two lines of text, but I don't see a case for why that is better as a conceptual framing of the structure of the content.
<console>
...prompt user for their name
<output>Hello, name.</output>
<output>What is your age?</output><console>
...prompt user for their name
<output>Hello, name.</output>
...get age, do more stuff
</console>
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyMi5iZWV6ZXI.1731990745%40quikprotect.
Rob Beezer
Nov 19, 2024, 5:38:36 PM11/19/24
to prete...@googlegroups.com
Dear Haris,
Some comments on the code you shared this morning in Drop-In. (Add a link here
if you don't mind if others are able to see it.)
In your example #console, the indentation will be *really* big, since the first
line is tight to the tag. Move the first line down with proper placement and
the leading newline should get stripped automatically. That'd be a good thing
to add to the Sample Article (on the last commit of a PR).
We already talked about much of the following.
Code:
* Too much going on in mode="interior", should not be needed at all.
* test="not(@continuation = '')" (the converse can get fooled, I think)
* Realize that "xsl:for-each" changes context. Looks like you have it right.
* test="position() > 1": normally this is a big red flag. Tempting to use, but
if you are considering author's source, it counts things like comment nodes.
Which will likely mess up whatever you are doing. Here you can be *certain*
that "tokenize()" will only build #token nodes, so it is OK. Better to get in
the habit of doing:
test="preceding-sibling::token"
so only the first #token will make this condition false.
Rob
On 11/18/24 19:01, Charilaos Skiadas wrote:
Some comments on the code you shared this morning in Drop-In. (Add a link here
if you don't mind if others are able to see it.)
In your example #console, the indentation will be *really* big, since the first
line is tight to the tag. Move the first line down with proper placement and
the leading newline should get stripped automatically. That'd be a good thing
to add to the Sample Article (on the last commit of a PR).
We already talked about much of the following.
Code:
* Too much going on in mode="interior", should not be needed at all.
* test="not(@continuation = '')" (the converse can get fooled, I think)
* Realize that "xsl:for-each" changes context. Looks like you have it right.
* test="position() > 1": normally this is a big red flag. Tempting to use, but
if you are considering author's source, it counts things like comment nodes.
Which will likely mess up whatever you are doing. Here you can be *certain*
that "tokenize()" will only build #token nodes, so it is OK. Better to get in
the habit of doing:
test="preceding-sibling::token"
so only the first #token will make this condition false.
Rob
On 11/18/24 19:01, Charilaos Skiadas wrote:
Charilaos Skiadas
Nov 20, 2024, 12:19:42 AM11/20/24
to prete...@googlegroups.com
Thanks Rob! Here’s a link to it for everyone else.
or as a single commit: https://github.com/skiadas/pretext/commit/6e3693702d14f2ee5a014a04a2bfcb36d52fbf4e
I’ve made a number of changes when I looked at how it all is used in the pretext-html file. The prompt is wrapped in a “unselectable” span, then the multiline input is wrapped in a single <b>, so I thought the right approach would be to repeat the pattern for the continuations, and so in the presence of continuations each line would consist of a <span> containing the prompt or continuation, followed by a <b> that would contain the rest of the line. So the insertion of the continuation is not a pure transformation of the input text, it really involves generating more html tags.
So I ended up not placing anything in text-utilities, and just used sanitize-text to get the input text, then break it up if continuations are needed in the pretext-html file.
As it was a pattern that was used in a few places through the template, I extracted the “make an input line with a possible “prefix” <span> then a <b> “ into a separate helper template. I’ve left it in pretext-html right now as it produces html tags and didn’t feel general enough to put elsewhere. But maybe there’s a better approach that I have missed.
I set up a "determine-console-continuation” mode and a template that follows it, similar to “determine-console-prompt” and with a similar logic.
Some questions I have:
1. As far as I could tell the only two places there the "determine-console-prompt” template is used is in pretext-html and pretext-latex-common. Am I correct that to implement this we would just need to change those two places?
2. I took a very brief look at the pretext-latex-common processing of console/input, and I’m not really sure what all is going on, looks like each input line is to be wrapped in \consoleinput{} . What if anything would be the right behavior for the continuations? I’ll take a look at how the prompt is handled at some point when I have a clearer head and maybe it will all make sense.
3. It seemed to me that it made sense to make the continuation an option at the console tag level as well, same as with prompt, so I made that a fall-back case. Does that seem reasonable?
4. Would it make sense to say that “continuation” only makes sense if “prompt” is also used? Is this something that should/would be enforced somewhere? Would it be a schema limitation, a warning generated by the scripts?
5. I am assuming that some accompanying changes to the schema, and some documentation, would be needed.
6. On the HTML end, I came to recognize a problem with the new setup, namely that if someone tries to select the input code for copy-paste, they would also end up copying the continuation lines. I believe there should be some HTML solution for that though. But making them “unselectable” is not enough.
7. I think a bug/feature of the previous setting is that in the presence of a prompt, a multiline input’s followup lines would not be indented properly. For example the code:
<input prompt=“>>> ">
for x in range(0, 3):
print(x)
</input>
would end up as:
>>> for x in range(0, 3):
print(x)
Instead of the printx() line being indented 6 spaces (4 to match the prompt and 2 to match the original indenting).
I imagine it might be possible to make the transformation set a “default continuation” value to be a number of spaces matching the input length. I would be interested in adding that. But since it would change existing behavior in the absence of specified continuations, I didn't do it.
Haris
--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyMC5iZWV6ZXI.1732055913%40quikprotect.
Rob Beezer
Nov 21, 2024, 11:58:09 AM11/21/24
to prete...@googlegroups.com
Dear Haris,
I want to say: "Right. You are on the right track." Lets use Drop-In for
anything I don't catch just now.
* Basically, I think you can mimic/adjust what happens with @prompt.
* Maybe \consoleinput{} needs two arguments? This is not anything an author or
publisher sees/uses, so it can change at will, anytime.
* Maybe we have #console implemented for LaTeX and HTML (so EPUB, Jupyter), but
not for braille (iirc), so just two existing (three necessary) flavors.
* "Would it make sense to say that “continuation” only makes sense if “prompt”
is also used?" I say no. We could say that in the schema, but I'd say
enforcing it in the code is too much.
* Your example in (7) doesn't make sense to me. You've put a continuation
string into the @prompt?
I should be at Friday Drop-In.
Thanks,
Rob
> <mailto:pretext-dev...@googlegroups.com>.
I want to say: "Right. You are on the right track." Lets use Drop-In for
anything I don't catch just now.
* Basically, I think you can mimic/adjust what happens with @prompt.
* Maybe \consoleinput{} needs two arguments? This is not anything an author or
publisher sees/uses, so it can change at will, anytime.
* Maybe we have #console implemented for LaTeX and HTML (so EPUB, Jupyter), but
not for braille (iirc), so just two existing (three necessary) flavors.
* "Would it make sense to say that “continuation” only makes sense if “prompt”
is also used?" I say no. We could say that in the schema, but I'd say
enforcing it in the code is too much.
* Your example in (7) doesn't make sense to me. You've put a continuation
string into the @prompt?
I should be at Friday Drop-In.
Thanks,
Rob
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/231145CE-4166-48AB-92B1-0A468EC3C71A%40gmail.com <https://groups.google.com/d/msgid/pretext-dev/231145CE-4166-48AB-92B1-0A468EC3C71A%40gmail.com?utm_medium=email&utm_source=footer>.
Charilaos Skiadas
Nov 22, 2024, 8:42:00 PM11/22/24
to prete...@googlegroups.com
Sorry, couldn’t make it today, but I should be able to stop by on Tuesday. But I worked through the LaTeX part. I opted for not changing the consoleinput parameters and to just follow the prompt pattern. I also went ahead and prepared changes to the guide and to pretext.xml, kept them in separate commits.
But I was not able to compile the guide locally, I tried to do what the README.md in the doc/guide told me but pretext build gave m the following errors:
critical: Failed to parse project.ptx. Check the entire file, including all targets, and fix the following errors:
error: One of the targets has a missing required attribute: executables; look for the target with {'latex': 'latex', 'pdflatex': 'pdflatex', 'xelatex': 'xelatex', 'asy': 'asy', 'sage': 'sage', 'pdfpng': 'convert', 'pdfeps': 'pdftops', 'node': 'node', 'liblouis': 'file2brl'}.
For (7) what I mean is basically simply that the vertical comparison between the for loop and its contents goes away when a prompt is there, simply because the prompt moves the “for” 4 places to the right, but none of the subsequent lines are similarly indented. And on hindsight that’s probably fine, probably what someone would expect in the absence of continuation. But a part of my brain can’t help but expect to see the “p” in “print" vertically align with the “r” in “for".
Haris
Charilaos Skiadas
Professor in Mathematics and Computer Science
Hanover College
Professor in Mathematics and Computer Science
Hanover College
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwMC5iZWV6ZXI.1732208286%40quikprotect.
Reply all
Reply to author
Forward
0 new messages