I’m on Mac OS.
I’m simply trying to write the “evaluated at” sign for definite integrals and derivatives.
When I type the “pipe” symbol, I can tab until it becomes large. But when I subscript it, the size of the bar shrinks again.
My steps:
See this video: https://imgur.com/a/bWwqH7A
Hi @alecstein
the following steps work for me on Linux:
Now you can add the subscript on the right bar without cause it to shrinks
@mutable, this does not work on MacOS. Maybe it’s a bug. As soon as I add the subscript, the bar shrinks to the size of a normal, small “|”.
Here’s a video:
Please follow the steps above.
You must to insert two vertical bars and, after typed inside at least a char, delete the left bar.
I think this behaviour of Texmacs is correct because inserting just a single text bar is ambiguous in order to match the desired height.
I now understand what you mean. I have to put the derivative inside the two pipes, then delete the left pipe. I got it to work that way. Thank you.
I found you can also use the <space> primitive to create an invisible box that causes the right delimiter of the aforementioned <around> tag to be taller.
I made a macro for myself with the <space> primitive configured to create an space box with 0 width that extends vertically -0.5em from the baseline up to 1em above the baseline. An example TeXmacs document is available here, in case you want to copy paste the macro.
Some explanatory screenshots:
I’ve got a work around. b.t.w. I definitely think this is a bug, not a feature.
Type | tab tab to get a long vertical bar. Type *, the invisible multiplication. Type _ and the bar won’t shrink.
I wouldn’t necessarily say bug, more ill-defined behaviour. The | tab tab gives a middle delimiter, which should be used between left and right delimiters (Jolly Writer Sec 4.5). Without those there is no way to define the height of the middle delimiter.
The around* in @baltakatei’s macro inserts left and right delimiters, with the left one being empty, so the right delimiter, the vertical bar takes the height of the contents preceding it.
Unfortunately, that macro only works in display formulas. You can test it in an inline formula or the rightmost cell of a eqnarray or any cell of a table, as long as the formula is complex enough.
e.g.
<eval-at|<frac|F<frac|1|2>|F>||>
Could you clarify what your intended result is and how the macro differs? I’m not sure what you mean by working or not.
Seems to work for me:
For reference, here the macro in a way it can be copied into a document’s preamble with “paste from…-> TeXmacs”
<assign|eval-at|
<macro|body|from|to|
<around*|\<nobracket\>|
<space|0|-0.5em|1em><arg|body>|
\|>
<rsup|<arg|to>> <rsub|<arg|from>>>>
The error must have something to do with the Chinese/Taiwanese language. The macro works okay if the language is English/French. My document is written in Chinese.
This is the erroneous case, language set to Chinese:
I can’t upload the image of the normal case because the forum only allows me to upload one image.
The formula is pushed to a very long distance to the right, out of the view of the current document. It should be displayed right next to g_i=.
The piece of text:
<\eqnarray>
<tformat|<table|<row|<cell|>|<cell|>|<cell|L<rsup|<around*|(|t|)>>\<approx\><big|sum><rsub|i=1><rsup|n><around*|[|l<around*|(|y<rsub|i>,
F<rsub|t-1><around*|(|x<rsub|i>|)>|)>+g<rsub|i>f<rsub|t><around*|(|x<rsub|i>|)>+<frac|1|2>h<rsub|i>
f<rsub|t><rsup|2><around*|(|x<rsub|i>|)>|]>+\<Omega\><around*|(|f<rsub|t><around*|(|x<rsub|i>|)>|)>>>|<row|<cell|>|<cell|\<#5176\>\<#4E2D\>\<#FF1A\>>|<cell|g<rsub|i>=<eval-at|<frac|\<partial\>l<around*|(|y<rsub|i>,
F<around*|(|x<rsub|i>|)>|)>|\<partial\>F<around*|(|x<rsub|i>|)>>><rsub|F<around*|(|x<rsub|i>|)>=F<rsub|t-1><around*|(|x<rsub|i>|)>><rsub|>
\<#662F\>\<#68AF\>\<#5EA6\>\<#3002\>>>|<row|<cell|>|<cell|>|<cell|h<rsub|i>=<frac|\<partial\><rsup|2>l<around*|(|y<rsub|i>,
F<around*|(|x<rsub|i>|)>|)>|\<partial\>F<around*|(|x<rsub|i>|)><rsup|2>><mid|\|>*<rsub|F<around*|(|x<rsub|i>|)>=F<rsub|t-1><around*|(|x<rsub|i>|)>>
\<#662F\> hessian\<#3002\>>>>>
</eqnarray>
Thanks for reporting this. I can’t reproduce this in the latest svn. There has been a recent fix to some problems with delimiters (revision 14644), perhaps this has been fixed already. Which version are you using?
Installed version 2.1.4
SVN revision Custom Unversioned directory
windows 11.
Do you know when will there be the next release?
New testing builds can be found at this link. Based on my experience, the recent beta builds are already quite stable.