auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AUCTeX-devel] RE: Contribution to AUCTeXâ


From: Vincent Belaïche
Subject: [AUCTeX-devel] RE: Contribution to AUCTeXâ
Date: Mon, 19 Jul 2010 08:24:06 +0200


[...]

>
> > 2) how to change the interface for marking section/node (use two
> > different functions, use a different meaning for the universal prefix
> > argument...)
>
> The comparison of nodes and chapter structuring commands in the Texinfo
> manual (see (info "(texinfo)Two Paths")) describes both concepts of
> being technically independent of each other. That's one of the reasons
> I think we should have two separate marking functions, one for nodes and
> one for chapter structuring commands. I'd consider the latter one more
> relevant for AUCTeX.
>

The reason why I had thought of a single function is that you then need
a single keybinding (C-c *). I can split into two functions, but then
you should please provide me with the keybinding to be used for nodes.

Note that the current function works for chapter structuring
Texinfo commands by default, so it fulfills your point that "you'd consider
the latter one more relevant for AUCTeX"

[...]

> > (make-local-variable 'outline-level)
> > (setq outline-level 'texinfo-outline-level))
>
> In your last mail you wrote the following about
> `Texinfo-structuring-command-re':
>
> | I however declared Texinfo-structuring-command-re as a defvar to avoid
> | memory duplication (ie when there are several Texinfo buffer the same
> | string will be used in memory).
>
> Are you sure the above code would really accomplish that? Wouldn't
> there still be a separate string in memory for each buffer where
> `outline-regexp' is set? 

The memory will be allocated separately for the symbols as the
outline-regexp symbol is buffer local, but each symbol instance will
point to the same string. So yes, memory for the string is saved.


> I don't actually know how memory would be
> allocated in a case like the above, but I'd assume that you could only
> save memory here if you'd assign the symbol
> `Texinfo-structuring-command-re' to `outline-regexp' and evaluate the
> symbol once you need the value.
>

Just make the following experiment: inside buffer A evaluate

;----------------------------------------------------------------------
(make-local-variable 'toto)
(setq toto "TOTO")
(setq titi toto)
;----------------------------------------------------------------------

Then inside buffer B evaluate

;----------------------------------------------------------------------
(make-local-variable 'toto)
(setq toto titi)
(aset toto 0 ?X)
;----------------------------------------------------------------------

Then go back to buffer A and evaluate 

;----------------------------------------------------------------------
toto
;----------------------------------------------------------------------

What you get is "XOTO". This shows that toto points to the _same_ string
instance both in A and B, although B and A use different symbol
instances for toto.

Replace toto by outline-regexp and titi by
Texinfo-structuring-command-re and you get what we have.

> Personally I'd rather live with a little bit more memory consumption
> than obfuscating the code like in the example above.
>

What I consider obfuscating is that there could be different values of
outline-regexp for different buffers, This seems quite unlikely. 

I agree that because you need one more symbol
Texinfo-structuring-command-re, and the memory thereof, and the extra
code to make the string value comparison and revert to prior behaviour
if the strings are different, then memory saving may be non-existing if
there are only two buffers, but sometimes you grep on lots of files, and
you may have significantly more than two buffers.

Anyhow, if you make a point that I should come back to the prior simpler
coding, I am not so strongly opinionated on this, and I can do it if you
were not convinced by what precedes. I have been so much involved in
embedded systems in my professional life, that I am sometimes a bit to
obsessed with resource consumptions.

> --
> Ralf

  Vincent.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]