Hi Sam,
I guess that you approach could work, I would have done the same.
Unfortunately the only one well acquainted with TeXmacs macro handling
optimizations (to my knowledge) is Joris and I do not know if in this
moment he has the time to follow the discussion on the list.
It would be interesting if you continue to report your progress to the
list, so that we can build some knowledge on macro writing techniques.
Ideally we would need a wiki to gather all this....
good luck!
max
On 7 avr. 11, at 10:47, Sam Liddicott wrote:
I'm supposing that the reason the whole document is "re-processed"
when I insert a list item- even when it is the last use of that
counter - is the way texmacs tries to optimise, I'm guessing that it
tracks which macros change which global data.
As I use a single macro for all of my chunks (each having a counter)
my macro gets marked as touching each of these counters, and so
anything else that also uses those counters has to gen "re-
processed" if the counter changes.
If I follow the texmacs style of defining a new command for each of
my named chunks, I suppose that will also solve my problem. It would
work along the lines of
the new-list macro - and in fact it would work like a list macro
with a custom counter that is not with'd to zero.
Please will a wizard confirm if this is likely to be so; for - and
here is the problem - I don't want to have a different macro for
each named code thread, I want the name to be a parameter.
If I am correct, will I still get the advantage with a wrapper like
this:
<assign|nf-chunk|<\macro|name|body>
<compound|<merge|nf-chunk-|<arg|name>>>
</macro>>
Would texmacs be able to realise that nf-chunk was not the macro
touching all the counters, but the inner macro?
This whole thing is based on speculation, and I'll try it of
course... but I really hope for some dialog with one who knows...
Sam
On 06/04/11 15:50, Sam Liddicott wrote:
In my case I fixed the slowness with this at the end of my
environment:
<if|<nf-last-chunklet?|<value|nf-name>>|<assign|<merge|code-line-|
<value|nf-name>|-nr>|0>>
nf-last-chunklet? uses some hackery to know if it is the last
instance of the environment (for a particular nf-name) in the
document by looking to see if there is a label defined based on the
chunklet counter with 1 added to it.
If it is the last chunklet, then the line counter does not need
preserving, and zero-ing it keeps things quick.
Sam
On 06/04/11 14:11, Sam Liddicott wrote:
I've simplified the whole deal with a new definition of list that
does not reset item-nr to 0:
<assign|list|<macro|item-render|item-transform|body|<with|current-
item|<arg|item-render>|transform-item|<arg|item-transform>|<render-
list|<arg|body>>>>>
<\enumerate>
<item>one
<item>two
<item>
<item>three
<item>four
</enumerate>
hello joe <value|item-nr>
the enumerate and "hello joe" line can be repeated a few thousand
times to bring the same problem.
I guess it is because the texmacs document is a program. When a
change is made, it has to be re-executed in it's entirety unless
it that can be optimised out.
In some cases for me, though, the counter is never re-used again
after the environment instance in which the new line is being
inserted, so it could be optimised out...
So I need to talk to someone on the nature of these optimisations
(if I am right).
Sam
_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev
--
[FSF Associate Member #2325] <http://www.fsf.org/register_form?referrer=2325
>
<http://www.openrightsgroup.org/>
_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev
_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev
