mailing-list for TeXmacs Users

[Massimiliano Gubinelli <address@hidden>]

Dear Giovanni,
 my understanding of the matter can be wrong (or not totally correct) however 
is as follows:

1) In order to display your document, TeXmacs need to transform the document 
tree into a series of boxes which indicate where and what put on the screen 
or on the paper. This transformation go thru several phases, one of which is 
the macro expansion phase, i.e. markup in the document is evaluated until 
primitive markup is reached, which then allows to compute boxes and the 
material which will eventually end up on your screen.

2) Every time the document is modified, for example by the user editing it 
inserting some text in some position of the document tree, TeXmacs perform 
the computations in 1) to transform the modified document tree into a new 
sequence of rendering instructions.

3) If you put some \extern markup in the document, then when TeXmacs tries to 
expand that markup it (by definition) goes on by calling the scheme procedure 
and replacing the \extern markup with the result of the scheme procedure. 
Now, the scheme procedure does not have *any* informations on where the 
\extern markup was in the document tree. So scheme cannot know if we were in 
an equation or in a piece of text.

Your confusion is to believe that in-math? returns true in a situation where 
you use \extern inside an equation. This is not true, in my understanding.

in-math? is true only if the *editor* is in math mode, that is your cursor is 
inside an equation. This is a global mode of the editor and if it happens 
that your macro is evaluated again at that moment, then the predicate returns 
true, but this does not depend on the position of your \extern in the 
document tree, but on the current position of the cursor at the moment 
TeXmacs tries to recompute that part of the tree.

Maybe this description is not totally correct (I'm not sure how and when 
exaclty TeXmacs goes to a reexpansion of the macros) but seems coherent with 
the bizzare behaviour of your macros.

Also try \extern with a procedure of the form

(define (myfunc) (if (in-math?) "+++" "xxxx")))
to see how, even when you put it in regular text, you can have "+++" if, 
right away you then enter into math mode.

HTH,
Max



> On 17. Nov 2020, at 23:29, Giovanni Piredda <address@hidden> wrote:
> 
> I am going to answer your previous message (thanks for that by the way) but 
> before that: I do not follow the explanation in this message on the 
> in-math? predicate, I have an idea of what you might mean, but maybe the 
> idea is wrong :-)
> 
> Let me write it down here.
> 
> Starting from:
> 
> "As I open the file, where I have the macro (which calls Scheme code via 
> extern) both inside math and outside math, they are all executed as if in 
> text mode.
> 
> If I edit one of them, now the predicate in-math? has effect."
> 
> you say that when I open the file TeXmacs is only typesetting (and 
> therefore uses the default function, as (in math?) returns always #f), but 
> when I am editing TeXmacs knows what I am editing and lets Scheme know. Is 
> it that?
> 
> The follow-up question in this case is how can I obtain what I want, that 
> is a different function being called ever time the macro is executed, that 
> is also at the opening of the file. The aim seems sensible to me - 
> typesetting something in one way when in math and in one way when in text 
> (as I said above, now it is working when I write/edit, it is not working if 
> I close and open again a document).
> 
> Besides, doing Document->Update all hangs the document for a one/two 
> minutes (Ubuntu 20.10, I observed it in another document too), makes the 
> macros work well (upright in math, no asterisks, so it is recognizing the 
> math), which is pretty surprising, but destroys the page setup (margins are 
> lost).
> 
> G.
> 
> 
> On 17.11.20 22:50, Massimiliano Gubinelli wrote:
>> Going back to your attempt: I think that the predicate in-math? cannot be 
>> used to check whether the typesetter is working on an equation or not. No 
>> information is passed to Scheme about the internal status of the 
>> typesetter when you call a \extern markup. You can pass informations only 
>> via parameters. So your unitSpacer has no way to know if the evaluation is 
>> inside some math markup or not.
>> 
>> The predicates in-math?, etc.. are just to check if the editor is in text, 
>> prog, or math mode, for example. Thats is completely separate on the 
>> status of the typesetter.
>> 
>> HTH,
>> 
>> Max
>> 
>> 
>> 
>>> On 17. Nov 2020, at 19:25, Giovanni Piredda <address@hidden> wrote:
>>> 
>>> I post this here because I think that while being about Scheme in TeXmacs 
>>> is still of general interest. I have found a way of circumventing both 
>>> issues (which may be ok, in case I will ask about this in another post) 
>>> but I am curious to know the reason of the behaviours I observe.
>>> 
>>> First issue.
>>> 
>>> I have defined a Scheme function with the following:
>>> 
>>> (tm-define (unitSpacer) ; default, will be used in regular text
>>>        `(hspace "0.5spc"))
>>> (tm-define (unitSpacer)
>>>        (:require (in-math?))
>>>        "*")
>>> 
>>> As far as I understand, the first definition is the default and it is 
>>> overridden by the second when I am in math.
>>> 
>>> In my tests, this happens only in open documents. At the first opening of 
>>> a document, only the first definition is used. Does anyone have a hint on 
>>> what is happening? Developers ;-) ?
>>> 
>>> ===
>>> 
>>> Second issue.
>>> 
>>> In math mode, the program I wrote outputs groups of letters, each wrapped 
>>> in a <with|math-font-shape|right primitive, and interleaved with the 
>>> character "*".
>>> 
>>> Example of output, copied from the terminal using (display ...)
>>> 
>>> <tree 2 <with|math-font-shape|right|kg>*<with|math-font-shape|right|m>>
>>> 
>>> I call this from a TeXmacs macro in math mode and I get a typeset output 
>>> where the asterisk appears as such (while I would like it to be 
>>> interpreted as an implicit multiplication)
>>> 
>>> If I copy the output from the terminal, strip the outermost <tree 
>>> primitive and place it inside a math primitive (opening the .tm file with 
>>> a text editor) the asterisks do not appear (as I thought they shouldn't).
>>> 
>>> Again, suggestions?
>>> 
>>>