\cyrtext and \textcyr in the preabmle

[PhilipPirrip]

Why is LyX now adding this to every document, regardless of the class 
and latex font encoding used and even in empty documents:


%% LyX specific LaTeX commands.
\DeclareRobustCommand{\cyrtext}{%
  \fontencoding{T2A}\selectfont\def\encodingdefault{T2A}}
\DeclareRobustCommand{\textcyr}[1]{\leavevmode{\cyrtext #1}}


I think such interventions should be kept minimal.

Re: Understanding the painting process (André, Abdel, Lars, please read)

[Abdelrazak Younes]

On 03/10/2015 23:46, Jean-Marc Lasgouttes wrote:

Le 03/10/2015 11:50, Abdelrazak Younes a écrit :

I propose to get rid of pm::insetDimension.


pm is bv dependent; so it should nicely adapt to it containing bv.


I would think that bv::cordCache is bv dependent too...


Sure.


I do not understand your point here.

And currently something is wrong:
http://www.lyx.org/trac/ticket/9756


In this ticket you say pm is buffer dependent, this should not be the 
case. Paragraphs are Buffer dependent and pms are bv dependent, this is 
my point.
Obviously there is a bug here, is it only for SplitView? Or also for 
mutiple windows?






I think you should keep pm::insetDimension and remove bv::coordCache
completely instead. Design should be in the end like this:

* bv contains one tm
* tm contains multiple pm (tm can refer to the top InsetText or not)
* pm contains multiple insetDimension, one per inset in the paragraph.


Note that:
* coordcache also contains dimensions and positions for inner math 
insets.


MathInset should not be special in theory but, AFAIR, MathInset mixes up 
the contents and the metrics and it was too difficult to split that like 
for Paragraph and PM. This was also not fully necessary because 
MathInsets do not adapt they form depending on the bv size.
In any case, I don't see why pm could not contains dimensions and 
positions for inner math insets as well. A math inset is always inside a 
paragraph or another math inset.


* having a global bv coordinate cache allows to know where a mouse 
click lands (hovering, clicking...). It is doable with bv>tm>pm too, 
but this defeats the idea of a good old cache.


AFAIU the only difference between the global bv cache and what I am 
proposing is that the bv will ask its tm which will ask its pm which 
will ask its inset metrics. But maybe I don't follow you.





SingleParUpdate would not be necessary if all elements did their job
correctly. I also guess that SingleParUpdate assumes that there is only
one InsetText, which is of course not true. We should aim to remove this
flag.


In some cases, I still believe that it makes sense for the code to 
indicate that only the current paragraph has been changed. This is 
something that the code cannot guess without rebreaking the paragraph 
(which is expensive).


My point is that each insets or paragraph should know if something has 
changed inside it. SingleParUpdate is a top->down mechanism because the 
LFUN mechanism is always top down.
I guess it should be possible for each tm to ask its pms if it needs to 
be recalculated. That's why I think the global SingleParUpdate flag 
should not necessary.



On a related note, what is the semantics of a call to
Buffer::changed(false)? What does the caller mean?


That the buffer contents and only the content content is changed. I
guess this signal is abused for some other purpose.


I cannot parse your first sentence. 


Buffer::changed(bool) means that buffer contents and only that.

And what does it means to have a buffer which contents is changed 
without having updated metrics?


I don't remember exactly... maybe that this change is not visible and 
thus doesn't need new metrics?



Couldn't this be done on demand? I suspect this could be
made transparent by doing it in the proper metrics-fetching method.


Maybe yes. You would have to assess if the on-demand computation does
not slow down the minimal scrolling case.


I do not really see how it could slow it down.


With the pre-computed pm you don't have to compute again if you stay 
within the metrics limit of this paragraph when scrolling a bit.


Abdel.

Re: Understanding the painting process (André, Abdel, Lars, please read)

[Jean-Marc Lasgouttes]

Le 04/10/2015 12:07, Abdelrazak Younes a écrit :

And currently something is wrong:
http://www.lyx.org/trac/ticket/9756


In this ticket you say pm is buffer dependent, this should not be the
case. Paragraphs are Buffer dependent and pms are bv dependent, this is
my point.


You are right, I indicated this in the ticket.


AFAIU the only difference between the global bv cache and what I am
proposing is that the bv will ask its tm which will ask its pm which
will ask its inset metrics. But maybe I don't follow you.


Actually with the new code, the row object contains the dimension of the 
insets it contains, so that it is not really necessary to have a per pm 
cache.


With the bv::coordCache system, an inset can now what is its dimension 
in a buffer view, without knowing where it is in the document. This is 
therefore more powerful than a per-pm cache.



My point is that each insets or paragraph should know if something has
changed inside it. SingleParUpdate is a top->down mechanism because the
LFUN mechanism is always top down.
I guess it should be possible for each tm to ask its pms if it needs to
be recalculated. That's why I think the global SingleParUpdate flag
should not necessary.


I see. I am not sure how to do it though.


That the buffer contents and only the content content is changed. I
guess this signal is abused for some other purpose.


I cannot parse your first sentence.


Buffer::changed(bool) means that buffer contents and only that.


And then, what is the expected action?


And what does it means to have a buffer which contents is changed
without having updated metrics?


I don't remember exactly... maybe that this change is not visible and
thus doesn't need new metrics?


In this case, I would say that nothing needs to be done.

JMarc

UTF-8 in string literals and translation strings in particular

[Guillaume Munch]

Deal list,

Has there been some discussion already about allowing UTF-8 in the 
source code, in particular for translatable strings? Is this something 
we long for?



Guillaume

Re: [LyX/master] Fix compilation with MSVC in c++98 mode

[Uwe Stöhr]

Am 01.10.2015 um 23:10 schrieb Guillaume Munch:


commit 39343d65af804d83803b16557b624f3cc024cc21
Author: Guillaume Munch 
Date:   Mon Sep 28 18:13:19 2015 +0100

 Fix compilation with MSVC in c++98 mode


Hello Guillaume,

welcome on board of LyX! And also many thanks for fixing the 
compilability. Now I can compile LyX's master again.


best regards
Uwe