Re: [Texmacs-dev] How texmacs is so slow for my macro

[Sam Liddicott]

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
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/texmacs-dev


--
[FSF Associate Member #2325] 
<http://www.fsf.org/register_form?referrer=2325>

<http://www.openrightsgroup.org/>