Re: Insert LyX Separator

[Guillaume Munch]

Le 02/04/2016 17:12, Richard Heck a écrit :


Is there a menu entry for inserting LyX separators and paragraph breaks?
I would have thought I'd find it under Insert> Formatting.





Edit > Start new environment (Alt+P Enter)

Seems convenient enough for me (also preserves the old shortcut).

Parbreak can be converted into from the contextual menu; there is no 
element in the menu because, as I understand, they are only really 
useful when converting 2.1 files into 2.2 files (tell me if I'm wrong).


Guillaume

Re: possible tag and tar of 2.2.0rc1 on Tuesday

[Guillaume Munch]

Le 01/04/2016 04:43, Scott Kostyshak a écrit :


1. At #10019 Guillaume fixed some ui regressions. The patch seems short
and logical and Stephan has tested it with success on Mac. I would still
like to see if someone can test it on Windows before it is included. If
anyone with Qt knowledge can take a look at the patch, that would also
be nice. I think normally I would not want any .ui changes in at this
point (for the reasons I listed on that ticket), but since they are
fixing regressions it would be nice to have. If someone thinks this is
important and we do not get a Windows user to test, we could potentially
put the patch in and make sure some of our Windows rc1 testers test
specifically this dialog.



To be more precise, the reason why Scott wants platform-specific tests
is because .ui changes have introduced in the past bugs showing with
certain configurations only.

The reason why this patch is important is that it solves the precise
kind of issue that Scott fears it might introduce, whereby the
dimensions of the new UI introduced with 2.0 do not take into account
the localisation and platform-specific themes. Therefore, by not having
feedback on win or a separate +1, the team would be publishing a UI
change which is known to be buggy, just to avoid bugs which we do not
know they exist.

Re: Plan for 2.2.0rc1

[Guillaume Munch]

Le 27/03/2016 23:14, Scott Kostyshak a écrit :

On Sun, Mar 27, 2016 at 09:33:12PM +0200, Uwe Stöhr wrote:


So once again, please release RC1. I don't see why we should wait any
longer.


We all want to release RC1 as soon as possible. But there are blockers.
Please see the other threads discussing these issues. We are making
progress thanks to some developers working on issues that aren't fun for
them. Hopefully we will be able to release soon.



What are those blockers? It's hard to keep track, updates on the 
situation would be helpful. I have been wondering too why RC1 was not 
out already.

Re: Beamer separators in 2.2b2

[Guillaume Munch]

Le 20/03/2016 20:41, Scott Kostyshak a écrit :

On Sat, Mar 19, 2016 at 04:10:58PM +0100, Enrico Forestieri wrote:

On Sun, Mar 13, 2016 at 01:33:32AM +0100, Enrico Forestieri wrote:


The attached patch introduces a new kind of separator, the latexpar
separator. This is exactly the same as the old parbreak one and the
only difference is the way parbreak and latexpar kinds are represented
on screen. The new latexpar is represented exactly as the old parbreak,
while a parbreak separator is now represented as a double line.

The context menu does not account for latexpar separators and only
"true" separators can be turned each into the other one.

Note that this is a format change and I don't know whether this is
allowed at this stage of development.


Scott? This seems to be a desired change, even if the patch did not
attract any attention, apparently.


Thanks for the patch. It is OK that it is a file format change. José or
Guillaume do you give a +1?



I do not have so much time to test and review right now. I do not feel 
so much concerned by the issue, I only tried to give ideas of solutions 
that are simpler and do not require a file format change. Let's hope 
José has more time to test.

Re: Issues to discuss for 2.2.0rc1

[Guillaume Munch]

Le 20/03/2016 20:48, Scott Kostyshak a écrit :


#9963
Although this is a regression, we cannot reproduce and I don't think it
is a blocker so unless someone has an idea I think we must postpone.


I agree. Also my patch worked around the most annoying part of the bug 
already.

Re: scrjura.layout

[Guillaume Munch]

Le 18/03/2016 18:09, Jürgen Spitzmüller a écrit :

Am Freitag, den 18.03.2016, 16:19 +0100 schrieb meik michalke:

allthough i've set "InToc 1" for both, they don't show up. is this
not yet
supported for flex insets?


No. This is http://www.lyx.org/trac/ticket/7790

Some work towards implementing it has already been done for forthcoming
2.2, but I understand it is not yet complete.



Even when complete, it will likely not be able to change the main table 
of contents because it has a specific code. Please open a separate 
report describing your issue like you did in your message.


You could also ask other people whether there is another way than flex 
insets for what you are trying to achieve.

Re: Plan for 2.2.0rc1

[Guillaume Munch]

Le 14/03/2016 20:15, Georg Baum a écrit :

Scott Kostyshak wrote:


Guillaume committed a fix that was tested by Enrico and Uwe. If you have
time to check it, take a look at b3bed292.


Works fine and fast for me (but I did never see the crash, only the
slowlyness).

Very nice, this is exactly what I had in mind but did not now how to
implement.




Thanks. TBH I found this solution a bit with chance: I started with
following this guide
https://doc.qt.io/qt-5/qtwidgets-itemviews-fetchmore-example.html and
then I found out that it worked well even if I fetched a million items
at once.

Re: Beamer separators in 2.2b2

[Guillaume Munch]

Le 11/03/2016 18:01, José Matos a écrit :

On Friday, March 11, 2016 05:52:46 PM Guillaume Munch wrote:

What about drawing this inset differently when it is alone in its paragraph?


I would be happy. :-)



Or adapt lyx2lyx to convert the old separator into the plain separator 
followed by the parbreak separator on the same paragraph?

Re: Beamer separators in 2.2b2

[Guillaume Munch]

Le 11/03/2016 17:28, José Matos a écrit :

On Thursday, March 10, 2016 10:48:58 PM Enrico Forestieri wrote:

In a nutshell, the old separator layout has gone and now a separator
inset is used in its place. Given that the old separator layout was
introducing a blank line in the latex output, in order to not change
the output, all converted documents use the parbreak separator (denoted
by the unfamiliar character). However, if that blank line is not essential,
you can get the familiar line back by right clicking the unfamiliar
character and changing it to the plain version.


I understand what you say but what is confusing is the representation. I
suspect that you know that. :-)

When I insert a separator between layouts, be it a Frame or an Theorem, what I
want is to have two distinct Frames or two distinct Theorems and not the same
Frame or Theorem with another standard paragraph.

The separator sign (a line at all length) conveyed that, the new sign does
not. That is what is confusing.

That the old separator added an extra line is an (unfortunate) implementation
detail.
That in one form or another I complained since last century (technically my
problem was with the way we worked implicitly with the standard paragraph).



What about drawing this inset differently when it is alone in its paragraph?

Re: [patch] fix a problem with autorepeat cursor keys

[Guillaume Munch]

Dear Andreas


Thank you very much for coming up already with a solution to your problem.

I would not be surprised that this portion of code is buggy, because
querying hasPendingEvents() inside a thread is already a weird way to
decide to drop an event. Your patch looks simple but would need to be
reviewed by somebody with some experience with threading in Qt
applications to be sure it does not risk making things weirder. (I have
some project to revisit this code for 2.3.0 because it looks like a fun
thing to learn, but now is not really the moment for me...)

In case your patch does not make it in time for 2.2 (because as far as I
understand the next step is a release candidate), can we try to see
where your issue comes from? I am thinking about the fact that there
already were issues of input methods interfering (here IBus:
). Your bug is certainly not #9362
though because one of its symptoms is that the message "system is busy"
is not displayed (and the event not dropped). I wonder whether it could
be something else. For this reason could you please try to see if you
can reproduce your issue when you run LyX with the following command line?
  XMODIFIERS= lyx

Also, since you suspect that interfering events might be coming from
timers: do you have the source view open when the bug occurs?

I am sceptical that the age of your laptop is the (sole) issue here,
because when I use valgrind to profile LyX, it also goes very slowly,
and I have never experienced issues of this sort (unless I had IBus
running).


Sincerely
Guillaume


Le 07/03/2016 01:13, Andreas Amann a écrit :

Hi,

when I use lyx-2.1.4 on an older laptop (Celeron 550, arch-linux) I
cannot use the cursor left and right keys in the usual way.  They get
stuck after moving by just one character, even if I keep the key
pressed, and then I get a staggered irregular cursor motion. The problem
is also present on the current master branch.
(Interestingly I do not see this issue with a faster computer with
otherwise similar setup).

when starting lyx with

lyx -dbg key

error messages of the form

GuiWorkArea.cpp (1053): system is busy: scroll key event ignored

appear.

The reason seems to be that there are other unrelated events pending in
the Qt eventloop (possibly timer events for cursor blinking?). This
causes lyx to drop the cursor motion events.

The attached patch against the current master branch fixes the problem
for me.  It first processes all events which are not caused by user
input, and only if this does not clear the event queue proceeds to drop
the current event.

Would you consider applying this to master (and possibly backport to
2.1.x)?

Thanks,
Andreas

Re: New versions of LyX always hang multiple times. OS X

[Guillaume Munch]

Le 03/03/2016 23:48, Jerry a écrit :

the behavior is the same--Reconfigure
runs quickly without and crashing luatex, and the Python command
appears to be running very long



I am not sure I understand.

Re: New versions of LyX always hang multiple times. OS X

[Guillaume Munch]

Le 27/02/2016 03:44, Jerry a écrit :

If I remove
/Library/TeX/texbin:/usr/texbin:/sw/bin:/sw/sbin:/opt/local/teTeX/bin:

 from the front of the PATH prefix and run Reconfigure, it runs in
15-20 seconds. The first time I saw a luatex instance in Activity
Monitor but on subsequent runs it did not appear--I suppose it's
possible that it ran so quickly that Activity Monitor did not have a
 chance to show it.

This of course has no effect on running

python -tt "/Applications/Words/LyXOuterFolder/LyX
2.2.0beta2/LyX.app/Contents/Resources/configure.py"
--with-version-suffix=-2.2
--binary-dir="/Applications/Words/LyXOuterFolder/LyX
2.2.0beta2/LyX.app/Contents/MacOS/"

from a terminal session which still stays on +Indexing TeX files...
for about 34 minutes.



Have you changed the value of PATH under both lyx 2.1 and 2.2 ?

I still do not understand why the above makes the two issues seem
unrelated whereas in your description below I get the impression that
closing the luatex processes makes you skip the 34-minute waiting time.


The luatex process starts almost as soon as I hit Reconfigure.
 I Quit it (force quit not required) using Activity Monitor.
LyX is unresponsive for about a minute, then the message

The system has been reconfigured. You need to restart LyX to
make use of any updated document class specifications.

appears. At that point, LyX seems to operate normally. Also it
 operates normally after quitting and relaunching.

Re: New versions of LyX always hang multiple times. OS X

[Guillaume Munch]

Le 26/02/2016 10:08, Jerry a écrit :

I don't know if you could infer that from my previous comments, but
more or less what happens.


I could infer, more or less :)


The luatex process starts almost as soon
as I hit Reconfigure. I Quit it (force quit not required) using
Activity Monitor. LyX is unresponsive for about a minute, then the
message

The system has been reconfigured. You need to restart LyX to make use
of any updated document class specifications.

appears. At that point, LyX seems to operate normally. Also it
operates normally after quitting and relaunching.


This makes me think that we experienced the same issue. I would suggest 
to make sure that LyX does not call inadvertently the wrong luatex 
binary from your older texlive 2013 installation. If you're sure it is 
running the most recent version, then you could try to temporarily 
remove non-essential fonts and see if it gets quicker. (I do not know 
how to safely do this on your OS.)

Re: New versions of LyX always hang multiple times. OS X

[Guillaume Munch]

Le 25/02/2016 00:54, Jerry a écrit :

On Feb 24, 2016, at 6:49 AM, Guillaume Munch <g...@lyx.org> wrote:


I may have had a similar issue involving LuaTeX taking huge amounts
of time to configure, at some point, with LyX 2.1 and TeXLive
2012/2013. It got solved by upgrading TeXLive. Jerry, do you have
lots of fonts installed?


I'm not sure what you mean. If I take your question literally, the
answer is, it seems like everything I do on my computer results in
more fonts being installed, so I would say "yes," approximately 10^9.
I can be more precise if you like. OK--according to Font Book, there
are about 450 families and most have several fonts in each family.



This has been a factor for me in the past, though it's been a while ago,
and I never really investigated the problem. When I had this problem I
would simply force-close the luatex processes, then lyx would
immediately continue as expected. If I infer correctly from your other
messages, if you only force-close the luatex processes and not lyx then
it continues normally?

Re: Warning about preview snippet

[Guillaume Munch]

Le 24/02/2016 18:32, Jean-Pierre Chrétien a écrit :

Hello,

When I open either the UserGuide or the Math manual (in English or in
French), I get this in the calling command window:

Warning: Failed to produce 1 preview snippet(s)


I don't think so.



Is this a serious problem ?
Any clue to find which snippet fails (other than bisection)?



Latex log > Open Containing Directory

then try to find the files lyxpreview*.log

Then we can see that for the User Guide, this is due to \question and 
\answer not being defined (they are defined in ERT inside branches). For 
Maths this is because the undertilde package is not installed. In either 
case there is no clear solution to make preview work.

Re: New versions of LyX always hang multiple times. OS X

[Guillaume Munch]

I may have had a similar issue involving LuaTeX taking huge amounts of
time to configure, at some point, with LyX 2.1.3 and TeXLive 2012/2013.
It got solved by upgrading TeXLive. Jerry, do you have lots of fonts
installed?



Le 24/02/2016 09:06, Jerry a écrit :


On Feb 23, 2016, at 9:46 PM, Scott Kostyshak  wrote:


On Tue, Feb 23, 2016 at 09:18:50PM -0700, Jerry wrote:


On Feb 23, 2016, at 3:28 PM, Scott Kostyshak  wrote:



Jerry does this happen even when Flexiglass is not running?


Yes. The behavior is the same, which is, using a non-new LyX but running Reconfigure, one 
instance of luatex hitting 200-250 MB (it can vary 10s of MB between Activity Monitor 
updates, which is about 3 seconds--Activity Monitor is I believe eye candy over tops) and 
roughly 20-100% of a single CPU. That luatex crashes in 4-5 minutes. The message about 
the Python command not finishing is displayed. Clicking "let it run" causes a 
message displayed that the system has been reconfigured and to restart LyX. LyX does not 
crash.

I'll try to remember to quit Flexiglass when doing LyX testing but I probably 
use it a hundred+ times a day.


I imagine it is hard. Actually the useful thing is to know whether you
can reproduce bugs that you find when Flexiglass is not running. So you
do not always have to remember to turn it off, but maybe it is hard to
remember to do it even in these cases.


Can you run that python command manually in a terminal?

Yes

Can you
reproduce the freeze when you do this?

No. The command ran for 35 minutes with almost of it with the line "+Indexing TeX 
files..." displayed.


This is important information. 35 minutes is not normal. For me it takes 9 
seconds (although I would not be surprised if it takes up to a couple of 
minutes on some computers).


There were two Python instances during this time, one possibly spawned by the 
other. It (they) appear(s) to have finished normally. In my home directory the 
following files and directories--all empty--were created. I'm going to trash 
them.


I forgot to specify that normally this command would be run from your
LyX user directory (which you can find the location of in Help > About).


+Indexing TeX files...


So this is where it pauses for a long time? How many minutes out of the
35?


Almost all--I'd guess 33-34.



+checking for default encoding (this may take a long time)


This is the only place where we say that it might take a long time. Does
the script pause here for a while?


I didn't notice it stopping for very long at all here or otherwise except as 
noted. I kept part of the terminal window visible as I did other things on my 
computer so I might have missed some details, but my strong impression is that 
everything flew by except the Indexing TeX files line. I would be happy to run 
it again if that would be helpful.

Jerry



kpathsea: Running mktextfm ecrm1000
/opt/local/share/texmf-texlive/web2c/mktexnam: Could not map source 
abbreviation  for ecrm1000.
/opt/local/share/texmf-texlive/web2c/mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; 
input ecrm1000
This is METAFONT, Version 2.7182818 (TeX Live 2015/MacPorts 2015_8) (preloaded 
base=mf)


kpathsea: Running mktexmf ecrm1000
! I can't find file `ecrm1000'.
<*> ...ljfour; mag:=1; nonstopmode; input ecrm1000

Please type another input file name
! Emergency stop.
<*> ...ljfour; mag:=1; nonstopmode; input ecrm1000

Transcript written on mfput.log.
grep: ecrm1000.log: No such file or directory
mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input 
ecrm1000' failed to make ecrm1000.tfm.
kpathsea: Appending font creation commands to missfont.log.


This doesn't look normal. I'm not sure if it's LyX's fault or your TeX
installation. Whatever it is, LyX should at least exit with error here,
no?


I have two TeX installations. One I installed from the TUG (I think that's what it's called) 
binary installer, probably TeXlive-2013, and the other as part of MacPorts, macports.org; 
this -> "texlive-bin @2015_8+x11 (active)" I think is relevant information for 
the active version from MacPorts. LyX is seeing the MacPorts version since all of MacPorts 
is in /opt/local. The TUG version from 2013 is at /usr/local/texlive/2013. I think that is 
probably the whole wad since it is 3.4 GB. I have been thinking about deleting it and 
relying on the well-maintained MacPorts version.

Jerry



Python terminal output.txt


To make sure I understand correctly, you experienced a similar problem
with LyX 2.1.x except that LyX did not crash. What is new in beta2 is
that LyX crashes. Did I get that right?

I can't remember if LyX has actually ever crashed in this respect--it rather 
seems to become unresponsive while the one or two luatex are running, 2.1.x and 
2.2.x. I seem to recall that when first running a new version I might have had 
to force-quit LyX after the two luatex instances either 

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Le 23/02/2016 21:06, Georg Baum a écrit :

Some developers postpone fun stuff because of
the rules and work on boring (but important) bugs instead, others ask for
exceptions for their fun stuff. If these exceptions are made it is quite
likely that those who postponed their work will be upset IMHO.


I know this. Actually that's what I meant when I wrote that I would not
be shocked if an exception was made, that I am in this situation. (Of
course, on the other hand I would not have agreed to delay my "fun"
further). Also, Uwe's patch does not particularly look like fun to me so
I do not suspect him to have fun at the expense of others.

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Hi Uwe,


I am offering my own reply since I do not think your messages deserved 
hostile responses.



Le 22/02/2016 23:40, Uwe Stöhr a écrit :

Am 22.02.2016 um 20:23 schrieb Georg Baum:


Le 21/02/2016 20:52, Scott Kostyshak a écrit :

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:

I also don't see a reason why this cannot be done now since otherwise
users of than languages would have to wait 2 more years until LyX 2.3.


Every LyX release in the past few years was further delayed by
last-minute
requests like this one. If we stop these last-minute changes, and improve
the test coverage we can speed up the release process a lot.


Time is not important here. The question is if adding a feature makes
sense. This change is of low risk but opens LyX for a wider audience.
Ergo a big plus for the marketing. There is also nothing specially to
test and nothing that can be broken. (all are LTR languages with either
Latin or Cyrillic script). So the question is not the time a patch is
sent but its benefit.
I cannot speak any of the languages of my patch so it would not help me
personally. I see the obvious benefit and not yet a technical reason
against this. As my goal is to spread LyX it makes sense to support as
many languages as possible.



Thank you for this effort. As I gather, developers find it too risky
anyway at this stage of development.





Yes. For every new language we need a native speaker to verify that the
result is correct. For example, support for urdu was added at
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned
out
that it was completely unusable, so that it was removed again at
http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit.


You forget the other languages added by
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit that work fine.
Take for example Hindi. This language was enabled with this patch and
people are using this (2 downloads a week of the dictionary for LyX). So
do you reapply prefer to wait until a native speaker gives his OK? Then
LyX would still not support Hindi. At first we need to attract users. If
e.g. a Macedonian user find a problem he will report it. If we don't
provide language support, we will most probably never have a Macedonian
LyX user.
Just for interest Bosnian is almost the same as Serbocroatian (the
language discussion in BiH is quite ridiculous, but OK as long as they
have peace, every party gets his "language".)


I am convinced by the details you gave; obviously you made your research 
before proposing this patch. However Georg more generally made the point 
that language support should be tested by a native speaker, which I 
would tend to agree, and obviously it is too late for that now.



Guillaume

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Le 22/02/2016 19:23, Georg Baum a écrit :

Guillaume Munch wrote:


Le 21/02/2016 20:52, Scott Kostyshak a écrit :

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:

I also don't see a reason why this cannot be done now since otherwise
users of than languages would have to wait 2 more years until LyX 2.3.


Every LyX release in the past few years was further delayed by last-minute
requests like this one. If we stop these last-minute changes, and improve
the test coverage we can speed up the release process a lot.

Besides that, every LyX release misses some features that are important for
some users. The only way to avoid this is to throw a massive amount of
developer man power upon LyX, and we all know that this won't happen.


I agree that this is unfortunate. But the same is true for any feature.
The feature freeze was over two months ago. Now we are focusing only on
bug fixes. I do not think it would be fair to make an exception for this
patch.


Exactly. Such exceptions punish those who play by the rules and reward those
who ignore the rules. This does not mean that I don't like the support for
the new languages. It is a very good thing to have, just not right now.


I would not be shocked if an exception was made. Uwe's point is that it
is low risk/high reward and that being delayed until 2.3 is quite
significant. I do not remember seeing another patch in this situation.


Because they have not been proposed. I have several easy features or bug
fixes I'd like to put in (e.g. http://www.lyx.org/trac/ticket/7404), but I
did not propose them after the freeze because I assumed that the freeze was
a freeze. Instead, I used my time for reviewing needed changes, and for
fixing show stopper bugs.


* Is the lack of these languages easy to work around if the patch is
postponed?


Yes. Load babel manually in the preamble, and disable the automatic loading
via preferences (language settings->language package=none)


* Is there any risk that the settings might be wrong (especially in ways
that cannot be fixed without another file format increase)?


Yes. For every new language we need a native speaker to verify that the
result is correct. For example, support for urdu was added at
http://www.lyx.org/trac/changeset/7eca5d94/lyxgit, and later it turned out
that it was completely unusable, so that it was removed again at
http://www.lyx.org/trac/changeset/cf9c7ad108fbc/lyxgit.





Thank you for your taking time for making these points. So nobody seem
to agree that this is as low risk / high reward as Uwe thinks (I cannot
judge by myself since I am not familiar with this part of LyX; for
instance, I thought that this would provide also spell-checking and
support for multi-language documents). Maybe this is the reply that Uwe
was looking for.

However, I still think that Uwe was justified in asking the question. A
rule allows one to say "no" without having to justify oneself but does
not preclude exceptions. I find it a bit counter-productive to try to
justify it now with arguments that are (I find) weak; for instance #7404
is nowhere near comparable: it is much more substantial and you targeted
it to 2.2.x yourself, whereas the 2-year delay was Uwe's most compelling
argument.

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Le 23/02/2016 01:51, Pavel Sanda a écrit :

Guillaume Munch wrote:

I would not be shocked if an exception was made. Uwe's point is that it
is low risk/high reward and that being delayed until 2.3 is quite
significant. I do not remember seeing another patch in this situation.


String changes break finalized translations or harass workflow for people
who work on them meanwhile... P



Yes, obviously we don't want to change the strings. Otherwise I would 
have already implemented that little checkbox to switch 
\save_transient_properties. I did not realize it did.

Re: blockers for 2.2.0?

[Guillaume Munch]

Le 22/02/2016 10:16, Jean-Marc Lasgouttes a écrit :

Le 21/02/2016 22:04, Scott Kostyshak a écrit :

We have 11 trac tickets with a 2.2.0 milestone. Any help with reducing
those 11 would be appreciated:

http://www.lyx.org/trac/query?status=accepted=reopened=assigned=new=status=2.2.0



A few comments:

  * regarding #9917, I'd appreciate if some other developers who know
about cursor and selection could look at the patch that I posted there
and give a +1 on code soundness. Then I would propose to apply it. At
worst it would not fix the bug, I think.



Before Jean-Marc's message, I moved the milestone to 2.2.x because the
results of proper testing will not be known in time. But I
agree with Jean-Marc that it could be applied right now without being
sure that it fixes the bug. (Unfortunately I am not familiar enough with
cursor & selection myself.) Here's a direct link to the patch:

http://www.lyx.org/trac/attachment/ticket/9917/0001-Reset-anchor-after-having-modified-the-cursor-not-be.patch




I am not sure that #9968, #9979, #9869 and #9633 are 2.2.0 blockers per
se, since they exist in 2.1.x too.



There is now a patch for #9869.

Re: [patch] support Bosnian, Macedonian, Piedmontese and Romansh

[Guillaume Munch]

Le 21/02/2016 20:52, Scott Kostyshak a écrit :

On Sun, Feb 21, 2016 at 06:06:14PM +0100, Uwe Stöhr wrote:

I also don't see a reason why this cannot be done now since otherwise users of
than languages would have to wait 2 more years until LyX 2.3.


I agree that this is unfortunate. But the same is true for any feature.
The feature freeze was over two months ago. Now we are focusing only on
bug fixes. I do not think it would be fair to make an exception for this
patch.


I would not be shocked if an exception was made. Uwe's point is that it
is low risk/high reward and that being delayed until 2.3 is quite
significant. I do not remember seeing another patch in this situation.

* Is the lack of these languages easy to work around if the patch is
postponed?

* Is there any risk that the settings might be wrong (especially in ways
that cannot be fixed without another file format increase)?





(The patch misses of course the necessary update of the fileformat of all
*.lyx files to keep the patch readable.)


I've been thinking about the best way to handle this. Perhaps the best
way is to update only the necessary test files with the patch you post,
and then update the rest of the files in a separate patch (that you
either post or don't).

It would be nice to be able to apply your patch and have the tex2lyx
tests still pass. What do others think is the best way?



I have been making the routine updates in separate commits (also helps 
for rebasing), and sending all the patches given by git format-patch. 
Clearer this way. Just make sure that the patches are ordered properly 
and that the boring ones come last.



Guillaume

Re: [PATCH] microtype

[Guillaume Munch]

Le 21/02/2016 08:33, Pavel Sanda a écrit :

is there some obstacle I should be aware of before implementing microtype
support via simple checkbox in document setting (plus maybe edit box for
params) which would result into simple \usepackage[...]{microtype} in header?
Is there any opposition to add it into lyx? (I dont mean 2.2 obviously.)




Good idea.


Please make sure whether this works with "plain" LaTeX (dvi), XeTeX, and/or 
LuaTeX.


In my experience, microtype works out of the box and the default values
are safe, including with xetex/luatex.

People who use custom parameters are on their own. But is there an
advantage of letting users enter custom params via a line edit, instead
of letting them write it by hand in the preamble? It does not seem to me
that the GUI helps here. Or do you have further plans for this feature?

Also, obviating the line edit, could the same not be accomplished by a
module?




2. I am aware that it should be put before various font settings in preamble
so it's spitted just in the beginning. Are you aware of any catch for the
currently produced ordering?


I haven't heard that microtype must be before font settings. My
experience is consistent with https://tex.stackexchange.com/a/162436


Guillaume

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 18/02/2016 01:58, Richard Heck a écrit :

On 02/17/2016 05:11 PM, Pavel Sanda wrote:

Guillaume Munch wrote:

The attached patch copies code from the source panel, so it is safe.

I don't know what is the current beta policy, if Scott is fine with that it has 
my +1.


Tested? If so, has my +1, too. (No time myself right now.)



Yes. Thanks. I do not care whether it is for 2.2.0 or 2.2.1. Scott's call.

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 17/02/2016 19:10, Pavel Sanda a écrit :

Joel Kulesza wrote:

My suggestion is to change the default font of the Settings->Preamble text
box to a fixed-width font because the content is effectively code.  This
change should improve readability for those that make extensive use of the
preamble.

Going a step further with the topic: would it also make sense to disable
(or make optional) line-wrapping in the preamble dialog?

I would appreciate hearing your thoughts on this.


Seems like trivial and sensible fix, if anyone comes with patch it can make
it into 2.2.0/x.




The attached patch copies code from the source panel, so it is safe.


>From 3339ed951d8bec5ac1783182baca7d51f6516326 Mon Sep 17 00:00:00 2001
From: Guillaume Munch <g...@lyx.org>
Date: Wed, 17 Feb 2016 21:45:44 +
Subject: [PATCH] Set the preamble in fixed-width font and without line breaks
 (#9966)

---
 src/frontends/qt4/GuiDocument.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index cf64849..60aee1c 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,6 +453,11 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
+	QFont font(guiApp->typewriterFontName());
+	font.setFixedPitch(true);
+	font.setStyleHint(QFont::TypeWriter);
+	preambleTE->setFont(font);
+	preambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
 	connect(preambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
 }
-- 
2.1.4

Re: 2.2.0beta1 tar balls are available

[Guillaume Munch]

Le 11/02/2016 02:40, Andrew Parsloe a écrit :



On 11/02/2016 1:28 p.m., Uwe Stöhr wrote:


I built an installer for beta 1 and uploaded it:
http://ftp.lyx.de/LyX%202.2.0beta-1/

regards Uwe


I've downloaded and installed this on a windows 7 machine. Initial
impressions are good. In particular, #9085 dealing with instant preview
and split views seems to be solved (good!). Also the inactive branch
symbol which wasn't visible in the alpha versions on windows now shows
*very* clearly in the outliner. I attach a screenshot. Is the x too
bold?



Yes, this is also what I wrote in the commit log:

Ideally, I prefer ❌ (CROSS MARK), whose description fits the purpose,
over ✖ (HEAVY MULTIPLICATION X), which looks too bold in the UI. Whereas
✕ (MULTIPLICATION X, successfully tested in Windows by Andrew) looks too
dim. But ❌ (CROSS MARK) is next to ❎ (NEGATIVE SQUARED CROSS MARK) so
it might be as problematic as the latter.

Thank you for your feedback.

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 02/02/2016 23:23, Uwe Stöhr a écrit :

Am 02.02.2016 um 22:02 schrieb Guillaume Munch:


I am sceptical, since the other patches which made your software crash
were based against master. You can try again with the same diff since
InsetMathGrid.cpp with hash 12e871a... is now in master.


I tried your patch again and now it applied without an errors or
warnings.


I am surprised that it did not crash again! I think that you can still
open a bug report for your git client.


Moreover http://www.lyx.org/trac/ticket/9944 does now not appear.


That's reassuring. I suspected indeed that something else was
responsible for such a bug.



I can now also see what you changed. You patch works fine for me so far.
I played some time with the AMS features in math.lyx.

So from my point of view I give a +1.
I cannot judge the technical details behind your patch, I can only tell
that it works.



Thanks for the review. Jean-Marc seemed also confident with such a patch
a while ago, but at this stage I would need somebody who would review
the discussion with Georg about this patch and say that they agree with
my points regarding the technical details. Otherwise this is going to
wait for 2.2.1.

Re: User pref parameters

[Guillaume Munch]

Le 12/01/2016 21:04, Guillaume Munch a écrit :


For instance, \origin is going to cause problems if any collaborator
through a VCS decides to store his own local path (which is a setting
global to lyx!). Should we not set \origin unavailable when
store_user_preferences is false? (I am seriously asking)



There is now a ticket about this, with a patch, at 
<http://www.lyx.org/trac/ticket/9958>. I do not think that it's 
important to have this before the release, but I mention it just in case.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 24/01/2016 11:57, Enrico Forestieri a écrit :



Thanks, I tested the patch and it works well. The new method
GuiPainter::path method seems safe because it is very similar to other ones
in GuiPainter. The other changes look ok, as for the symbol choice Richard
seemed positive about it. Please commit it, you have my +1.


I (reluctantly :) committed it with some small tweaks to make it more
appealing.




Why do you say reluctantly? I have already given my opinion on this new
symbol, and cannot argue on matters of taste if there is a majority of
voiced opinions in its favour. So I hope that at least both you and
Richard like it.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 24/01/2016 23:08, Enrico Forestieri a écrit :

On Sun, Jan 24, 2016 at 10:41:39PM +0100, Enrico Forestieri wrote:

On Fri, Jan 22, 2016 at 06:36:03PM -0500, Guillaume Munch wrote:


Maybe we can go with the improvements you already made for beta, and commit
this particular patch to master after release.


Fair enough. Please find attached the next iteration of the patch in
case you want to evaluate it. Note that I could not solve the problem
that a separator may be randomly selected after multiple clicks.
However, I think that this is a minor annoyance.


I found the reason of this last quirk. The multiple clicks were not
the real cause but the fact that, while clicking, the mouse could have
been moved, even if slightly. Please try the attached patch. Now the
separators should really be unselectable (by alone).



Thanks for all these investigations onto bugs, I will now be testing 
this latest patch.

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 25/01/2016 00:32, Uwe Stöhr a écrit :

Am 25.01.2016 um 00:28 schrieb Guillaume Munch:

 > Georg's commit indeed fixed the alignment, but not the width of the

column, which sometimes makes it hard to see that the first line is
left-aligned and the last one right-aligned. So you are saying that the
fix of multline was not sufficient to correctly reflect the meaning of
multline. Since #1497 was open before Georg's patch which already
improved the situation, it might be good to add a comment to the ticket
explaining why the bug is not fixed yet and what more is expected.


I am confused now. Isn't it obvious that the alignment within LyX is not
correct? Attached is the screenshot of what I see in LyX. Compare this
with the attached PDF output.



Your example illustrates what I described.




See also the attached LyX file to see what is expected (of course
without the \hfills).


My patches add a fixed gap between pairs of columns, depending on the
AMS environment. You would like this gap to behave like horizontal
springs. My changes are all I really need to work, whereas you would
like to be more faithful to the pdf output (instant preview fulfils that
purpose for me).


As I understood it the WYSIWYM concept is to give the user the feedback
of how it would appear in the output - without helpers like instant
preview.

However, even with instant preview the alignment is not correct: The
"A=Bbb" must be directly below the word "desired"


My patches introduce feedback that is currently inexistent. Being 
further "photorealistic" in the way you ask requires to dig deeper into 
the code, so I am going to ask to open new enhancement requests once my 
code is committed. My changes certainly do not preclude further 
enhancements.

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 25/01/2016 23:49, Uwe Stöhr a écrit :

Am 25.01.2016 um 07:21 schrieb Stephan Witt:


I cannot apply your patch. I get the 2 attached errors and the
TortoiseGit crashes.


It tells me that it cannot find the revision 12e871a for
InsetMathGrid.cpp. And indeed this revsion does not exists.

Guillaume, can you please send a patch file with a valid revision?

[...]


I seems that your patches make problems for TortoiseGit (I use the
latest version 1.8.16.0).
This is strange since I never had this before and the patches of the
other developers apply without any problems.


I cannot see any strange or problematic contents.


The nonexistent revision is the problem.



I am sceptical, since the other patches which made your software crash
were based against master. You can try again with the same diff since
InsetMathGrid.cpp with hash 12e871a... is now in master.

Re: [LyX/master] Always place the cursor before a separator inset when clicking

[Guillaume Munch]

Le 28/01/2016 05:47, Scott Kostyshak a écrit :

On Wed, Jan 27, 2016 at 02:23:55AM +0100, Guillaume Munch wrote:


As far as I understand, in release mode, this bug results in an
exception and emergency save, so I think it is best to solve this issue
before beta.


I am tempted to suggest we proceed towards beta despite this bug. I do
not understand the issue well though, so I would be interested in what
others think.




It looks pretty bad. Happened to me 4 times in about an hour, when
moving math insets around.

If looking for a quick fix, Enrico (or anybody else) has my +1 for a
patch along the following lines (I might not be around to commit it myself):

--- a/src/Cursor.cpp
+++ b/src/Cursor.cpp
@@ -1947,7 +1947,7 @@ bool Cursor::upDownInText(bool up, bool & 
updateNeeded)
 // Make sure that cur gets back whatever happened to dummy 
(Lgb)

 operator=(dummy);
 }
-if (pos() && paragraph().isEnvSeparator(pos() - 1))
+if (inTexted() && pos() && paragraph().isEnvSeparator(pos() - 1))
 posBackward();
 } else {
 // if there is a selection, we stay out of any inset,


Ideally this and all the similar lines should be factored into a
function, and I am also willing to review such a patch (cannot tell when
I'll have the time though).


Guillaume

Re: [LyX/master] acmsiggraph.layout: update layout for ACM siggraph 0.92

[Guillaume Munch]

Le 27/01/2016 01:58, Uwe Stöhr a écrit :

@@ -2239,10 +2343,12 @@ convert = [
 [501, [convert_fontsettings]],
 [502, []],
 [503, []],
-   [504, [convert_save_props]]
+   [504, [convert_save_props]],
+   [505, [convert_ACM_siggraph]]
]

  revert =  [
+   [504, [revert_save_props]],
 [503, [revert_save_props]],
 [502, [revert_verbatim_star]],
 [501, [revert_solution]],



Uwe, I am worried about this duplicate application of revert_save_props.

Please, apply the doc updates in a separate commit because they prevent
us from reading the commit log and spotting such errors.

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 26/01/2016 09:50, Jean-Marc Lasgouttes a écrit :

Le 25/01/2016 21:17, Guillaume Munch a écrit :

I had done this at first but then I thought that the difference in
properties at-point/not-at-point could result in differences. By reading
it again, with hindsight, of course this makes no difference, so I will
be happy to get rid of the trick entirely, my initial intention. However
I am going to replace it with a direct call to getFeatureStatus, unless
you think this is a bad idea. Thanks for spotting this circumvolution.


The question of bypassing the dispatch/getStatus mechanism is orthogonal
to what you are doing. We will need to discuss the merits of the
approach one day, but it may be important to proper scripting one day.
To be frank, I do not have clear views on the matter.




In fact, I was right in the original patch and mistaken above. The
getStatus used in the dialog is the full lyx::getStatus, not
InsetTabular::getStatus, therefore the difference AtPoint/not-AtPoint
makes a difference. So this explains that we need this "for-dialog" trick.

I have found the motivation to re-do the format increase and the patches
are now committed.

Re: [LyX/master] acmsiggraph.layout: update layout for ACM siggraph 0.92

[Guillaume Munch]

Le 27/01/2016 01:58, Uwe Stöhr a écrit :

commit c1e0b24304e67ede19f30c2ee7498386bfcf6808
Author: Uwe Stöhr 
Date:   Wed Jan 27 01:58:13 2016 +0100

 acmsiggraph.layout: update layout for ACM siggraph 0.92

 fileformat change: update fileformat for all files

diff --git a/development/FORMAT b/development/FORMAT
index cbd5064..0c8a98c 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,11 @@ adjustments are made to tex2lyx and bugs are fixed in 
lyx2lyx.

  ---

+2016-01-26 Uwe Stöhr 
+   * Format incremented to 505
+ No new parameters.
+ Convert acmsiggraph.layout to ACM siggraph version 0.92.
+



Am I mistaken or nobody gave Uwe the +1 to do this format increment?

Yesterday I had updated my series of patches on tabular-feature from
format 504 to 505, going again carefully through the checklist, updating
and checking docs, doing the careful compilation tests patch-by-patch,
as well as a final test of the features. I had announced on the list
that I was going to commit the patches. And right when everything is
ready and I am ready to push, I see that someone has made a ninja format
increase, leaving me with no choice but to start again! Then I decided
that it was better not to react on the spot and call it an evening.

If somebody reverts the unauthorized commit, I will be able to push
mines without further delay. Otherwise I will honestly have to look at
my schedule before I will be able to tell you when is the next time I
will be available to work on the patches.

Re: [LyX/master] Always place the cursor before a separator inset when clicking

[Guillaume Munch]

Le 21/01/2016 11:05, Enrico Forestieri a écrit :

On Thu, Jan 21, 2016 at 02:18:33AM -0500, Guillaume Munch wrote:

Le 20/01/2016 14:57, Enrico Forestieri a écrit :

On Wed, Jan 20, 2016 at 02:05:31AM -0500, Guillaume Munch wrote:

Le 19/01/2016 18:42, Enrico Forestieri a écrit :

On Tue, Jan 19, 2016 at 05:19:24PM -0500, Scott Kostyshak wrote:

On Sat, Jan 16, 2016 at 04:41:26PM +0100, Enrico Forestieri wrote:

commit 55b3374f3e3047a0aa7584e0737d1fcd40fe6809
Author: Enrico Forestieri <for...@lyx.org>
Date:   Sat Jan 16 16:41:04 2016 +0100

 Always place the cursor before a separator inset when clicking


Note that this commit might have triggered the assertion #9936.


Thanks. The attached patch fixes it for me.



You have added similar lines at several other places recently, after my
remarks. Should they be amended similarly?


No, the cursor is already in texted there.


Also, would it be better if you
factored the shared code in a new function?


They are only 2 lines of code, after all.



I think factoring the code is preferable in this situation. It
makes the code easier to understand and maintain. Also, it would check
for texted in all cases so it would depend on less assumptions. But I
also understand that you are very busy currently. I trust that you are
confident that no additional check for texted is required.


The check for texted (or equivalent check) is already done earlier
in the code, so there is no point in repeating it. However, I have
an updated patch that moves this code to a centralized place,
accounting for all mouse click events (single, double, etc.).




The same bug seems to arise in lyx::Cursor::upDownInText.

I had this issue four times in a short time span, every time I was
formatting math insets. I was in a rush, so I did not think about
recording a backtrace (I thought it was a known bug already reported).
Upon examination of the gdb session however I found the automatic backtrace:

(  1) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xc8c12f]
(  2) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xc8c44f]
(  3) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x5592d3]
(  4) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x543da3]
(  5) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x6be3bd]
(  6) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x9ac200]
(  7) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x8b699d]
(  8) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x8d114e]
(  9) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x886c3b]
( 10) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x544e37]
( 11) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xa0c08a]
( 12) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xa23938]
( 13) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x9ef2b2]
( 14) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x9df1fd]
( 15) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x5f3876]
( 16) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x9e17dd]
( 17) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xa39619]
( 18) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xa3c06c]
( 19) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*)
( 21) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QAbstractScrollArea::event(QEvent*)



Then using gdb I tried to check whether it was the one I thought:

(gdb) list *0xc8c12f
0xc8c12f is in lyx::doAssertWithCallstack(bool) 
(/usr/include/c++/4.9/bits/basic_string.h:293).

288   // Data Members (private):
289   mutable _Alloc_hider  _M_dataplus;
290 
291   _CharT*
292   _M_data() const _GLIBCXX_NOEXCEPT
293   { return  _M_dataplus._M_p; }
294 
295   _CharT*
296   _M_data(_CharT* __p) _GLIBCXX_NOEXCEPT
297   { return (_M_dataplus._M_p = __p); }
(gdb) list *0x5592d3
0x5592d3 is in lyx::DocIterator::paragraph() const 
(../../src/DocIterator.h:87).

82  // access to slice at tip
83  //
84  /// access to tip
85  CursorSlice & top() { return slices_.back(); }
86  /// access to tip
87  CursorSlice const & top() const { return slices_.back(); }
88  /// access to outermost slice
89  CursorSlice & bottom() { return slices_.front(); }
90  /// access to outermost slice
91  CursorSlice const & bottom() const { return slices_.front(); }
(gdb) list *0x543da3
0x543da3 is in lyx::Cursor::upDownInText(bool, bool&) 
(../../src/Cursor.cpp:1950).

1945if (bv().checkDepm(dummy, old)) {
1946updateNeeded = true;
1947// Make sure that cur gets back whatever 
happened to dummy (Lgb)
1948operator=(dummy);
1949}
1950if (pos() && paragraph().isEnvSeparator(pos() - 1))
1951 

Re: [LyX/master] Invert and document test for "longest labeling label" problem.

[Guillaume Munch]

Le 25/01/2016 19:47, Georg Baum a écrit :

Kornel Benko wrote:


Am Sonntag, 24. Januar 2016 um 22:19:25, schrieb Georg Baum



See http://www.lyx.org/trac/ticket/4595 for label insets, there are
similar bugs for other insets that expect LaTeX code. Unfortunately this
behaviour is indeed not documented as Günter noticed, and this should be
changed soon IMHO.

I am not sure whether a test is needed at all. This is expected
behaviour, and if we implement the solution suggested by Jürgen, then
this file will fail to compile forever, because of backward
compatibility.



Since the error happens only if processed by latex, we could as well
handle the string on latex export.


This is actually the plan, but non unconditionally. The outcome of various
previous discussions on this subject is that in some cases the current
implementation makes sense: Otherwise it would not be possible to enter
stuff that is not supported by LyX into these insets (or we'd need to make
the input fields some sort of mini LyX workarea, where you can also input an
ERT inset, but this would be quite complicated).

Therefore, the solution proposed by Jürgen is to have a switch "Use LaTeX
input" for those insets, and depending on the switch either export the
contents unfiltered, or with the usual escaping mechanism applied. This
switch would also ease the lyx2lyx implementation quite a bit.



I have seen this suggestion before, and thought about it in relationship
with another bug where somebody complained that it was not possible to
correctly paste lyx contents into dialogs (forgot for which purpose
exactly). IMO this would be solved by pasting the latex contents (if
available) when the tex switch is on. So, I not only like this idea but
I also think that it would be worth it to carefully craft a custom
widget to be used consistently throughout the interface (whenever
relevant), incorporating such an idea. I wanted to share this pasting
idea for some time, now done.

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 25/01/2016 15:04, Jean-Marc Lasgouttes a écrit :

Le 11/01/2016 18:54, Guillaume Munch a écrit :

Attached takes all comments into account. I hope the additional
explanations help.


OK, let's go through the patches again. I am sorry this is taking so
much time.

0001: a few remarks/questions:
- I still do not understand why the dialog, instead of using the
"for-dialog" trick, could not use directly tabular-feture to query the
status of a feature. I read your explanation, but I probably missed
something.


I had done this at first but then I thought that the difference in
properties at-point/not-at-point could result in differences. By reading
it again, with hindsight, of course this makes no difference, so I will
be happy to get rid of the trick entirely, my initial intention. However
I am going to replace it with a direct call to getFeatureStatus, unless
you think this is a bad idea. Thanks for spotting this circumvolution.



- in InsetTabular::getStatus, you could start with
 if (cmd.getArg(0) != "tabular")
 break;
   to limit nesting.


Ok


- How can InsetTabular::tabularFeatures return something else than
"true" now?


No, you are right: in fact the return value was only used to check that
the command started with "tabular" and since I moved this check out of
this function I will now change it so that it returns void. Thanks for
spotting this circumvolution.


- Are there places where one sets several features at once? Or is it
just that we this multi-arguments feature because the lfun is declared
like that?


Yes, that's what the tabular dialog does.


- The code of InsetMathCases::doDispatch is indeed strange. I suspect
that the break after cur.undispatched() should be a return; the
recordUndo seems bogus too.


I suggest just adding a FIXME for the moment instead of attempting a 
last minute fix of what's not broken (unless you see what bug this may 
cause).



- beside this, you have my +1 on the modifications in mathed/.


000[23456]: look fine to me, but I think you already got the +1

0007: OK with the update



Thanks

The next time I can work on this is tomorrow evening. If you agree with 
the above changes I can commit it straight away since the changes seem 
trivial, to spare some time.



Guillaume

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 24/01/2016 11:15, Uwe Stöhr a écrit :

Am 22.01.2016 um 02:07 schrieb Uwe Stöhr:


I tried this but cannot see a problem in LyX 2.1.4 compared to LyX 2.2
with your patches applied.


I still had your patch applied and this caused a crash:
http://www.lyx.org/trac/ticket/9944

Can you please have a look and provide a new patch? (if possible only
one patch file)




I cannot reproduce.

I placed the cursor at the bottom of the manual and scrolled back up to 
the top with the scrollbar. No crash happened. Did I miss anything?


Here are the patches as a single diff. Can you please confirm that this 
triggers your issue?



Guillaume
diff --git a/src/mathed/InsetMathGrid.cpp b/src/mathed/InsetMathGrid.cpp
index 12e871a..9161074 100644
--- a/src/mathed/InsetMathGrid.cpp
+++ b/src/mathed/InsetMathGrid.cpp
@@ -486,7 +486,7 @@ void InsetMathGrid::metrics(MetricsInfo & mi, Dimension & dim) const
 		colinfo_[col].offset_ =
 			colinfo_[col - 1].offset_ +
 			colinfo_[col - 1].width_ +
-			colinfo_[col - 1].skip_ +
+			displayColSpace(col - 1) +
 			colsep() +
 			colinfo_[col].lines_ * vlinesep();
 	}
@@ -508,7 +508,7 @@ void InsetMathGrid::metrics(MetricsInfo & mi, Dimension & dim) const
 			int const nextoffset =
 colinfo_[first].offset_ +
 wid +
-colinfo_[last].skip_ +
+displayColSpace(last) +
 colsep() +
 colinfo_[last+1].lines_ * vlinesep();
 			int const dx = nextoffset - colinfo_[last+1].offset_;
@@ -741,7 +741,7 @@ void InsetMathGrid::metricsT(TextMetricsInfo const & mi, Dimension & dim) const
 		colinfo_[col].offset_ =
 			colinfo_[col - 1].offset_ +
 			colinfo_[col - 1].width_ +
-			colinfo_[col - 1].skip_ +
+			displayColSpace(col - 1) +
 			1 ; //colsep() +
 			//colinfo_[col].lines_ * vlinesep();
 	}
@@ -953,7 +953,7 @@ int InsetMathGrid::cellWidth(idx_type idx) const
 		col_type c2 = c1 + ncellcols(idx);
 		return colinfo_[c2].offset_
 			- colinfo_[c1].offset_
-			- colinfo_[c2].skip_
+			- displayColSpace(c2)
 			- colsep()
 			- colinfo_[c2].lines_ * vlinesep();
 	}
@@ -1378,6 +1378,11 @@ char InsetMathGrid::displayColAlign(idx_type idx) const
 }
 
 
+int InsetMathGrid::displayColSpace(col_type col) const
+{
+	return colinfo_[col].skip_;
+}
+
 void InsetMathGrid::doDispatch(Cursor & cur, FuncRequest & cmd)
 {
 	//lyxerr << "*** InsetMathGrid: request: " << cmd << endl;
@@ -1827,4 +1832,56 @@ bool InsetMathGrid::getStatus(Cursor & cur, FuncRequest const & cmd,
 }
 
 
+// static
+char InsetMathGrid::colAlign(HullType type, col_type col)
+{
+	switch (type) {
+	case hullEqnArray:
+		return "rcl"[col % 3];
+
+	case hullMultline:
+	case hullGather:
+		return 'c';
+
+	case hullAlign:
+	case hullAlignAt:
+	case hullXAlignAt:
+	case hullXXAlignAt:
+	case hullFlAlign:
+		return "rl"[col & 1];
+
+	default:
+		return 'c';
+	}
+}
+
+
+//static
+int InsetMathGrid::colSpace(HullType type, col_type col)
+{
+	int alignInterSpace;
+	switch (type) {
+	case hullEqnArray:
+		return 5;
+	
+	case hullAlign:
+		alignInterSpace = 20;
+		break;
+	case hullAlignAt:
+		alignInterSpace = 0;
+		break;
+	case hullXAlignAt:
+		alignInterSpace = 40;
+		break;
+	case hullXXAlignAt:
+	case hullFlAlign:
+		alignInterSpace = 60;
+		break;
+	default:
+		return 0;
+	}
+	return (col % 2) ? alignInterSpace : 0;
+}
+
+
 } // namespace lyx
diff --git a/src/mathed/InsetMathGrid.h b/src/mathed/InsetMathGrid.h
index bd3066d..7faf938 100644
--- a/src/mathed/InsetMathGrid.h
+++ b/src/mathed/InsetMathGrid.h
@@ -258,10 +258,19 @@ protected:
 	virtual docstring eocString(col_type col, col_type lastcol) const;
 	/// splits cells and shifts right part to the next cell
 	void splitCell(Cursor & cur);
-	/// Column aligmment for display of cell \p idx.
+	/// Column alignment for display of cell \p idx.
 	/// Must not be written to file!
 	virtual char displayColAlign(idx_type idx) const;
+	/// Column spacing for display of column \p col.
+	/// Must not be written to file!
+	virtual int displayColSpace(col_type col) const;
 
+	// The following two functions are used in InsetMathHull and
+	// InsetMathSplit.
+	/// The value of a fixed col align for a certain hull type 
+	static char colAlign(HullType type, col_type col);
+	/// The value of a fixed col spacing for a certain hull type
+	static int colSpace(HullType type, col_type col);
 
 	/// row info.
 	/// rowinfo_[nrows()] is a dummy row used only for hlines.
diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 94e9ec4..82c6f98 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -349,33 +349,46 @@ bool InsetMathHull::idxLast(Cursor & cur) const
 }
 
 
+//FIXME: This has probably no effect and can be removed.
 char InsetMathHull::defaultColAlign(col_type col)
 {
-	if (type_ == hullEqnArray)
-		return "rcl"[col];
-	if (type_ == hullMultline)
-		return 'c';
-	if (type_ == hullGather)
-		return 'c';
-	if (type_ >= hullAlign)
-		return "rl"[col & 1];
-	return 'c';
+	return colAlign(type_, col);
 }
 
 
 char 

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 24/01/2016 12:04, Uwe Stöhr a écrit :

Am 22.01.2016 um 20:30 schrieb Guillaume Munch:


Can you please tell me what issue you are referring to precisely in
#1497 then?


Open the testfile I attached to
http://www.lyx.org/trac/ticket/1497

Compare the appearance in lyx with that in the PDF output:

- for multline (first formula in the testfile) the first line starts in
the output at the leftmost position, the last one at the rightmost. But
in LyX not.



Georg's commit indeed fixed the alignment, but not the width of the
column, which sometimes makes it hard to see that the first line is
left-aligned and the last one right-aligned. So you are saying that the
fix of multline was not sufficient to correctly reflect the meaning of
multline. Since #1497 was open before Georg's patch which already
improved the situation, it might be good to add a comment to the ticket
explaining why the bug is not fixed yet and what more is expected.




- for flalign (second formula in the testfile) the first 2 columns are
in the output at the leftmost position, the last 2 columns at the
rightmost. But in LyX not.

- for align (third formula in the testfile) the first 2 columns are in
the output at a position in the middle between the middle of the page
and the laft border, the last 2 columns are at the middle-right
position. But in LyX not.



My patches add a fixed gap between pairs of columns, depending on the
AMS environment. You would like this gap to behave like horizontal
springs. My changes are all I really need to work, whereas you would
like to be more faithful to the pdf output (instant preview fulfils that
purpose for me).

In addition, as far as I understand Georg tried to have such variable
gaps in the patch at http://www.lyx.org/trac/ticket/1861. The patch has
been unfinished for seven years, and what I propose instead is a simple
fix available now. The further improvements you would like to have seem
to require more work. This is why I will try to get my patches in 2.2.1
as is.


Guillaume

Re: Regression in fr.po

[Guillaume Munch]

Le 23/01/2016 03:40, Jean-Pierre Chrétien a écrit :


The reason is that I'm not through the update of fr.po for master, I have
yet to collect the changes I made to fr.po for branch since April 2015 (the
last time I synced 2.2. with 2.1) and insert them in 2.2.
Usually I do this using the diff-po.pl script available on trac. I remember
trying a merge of 2.1 into 2.2, but I thing the diff is a cleaner practice.

I do not know if there is a standard practice, using msgmerge I guess: if
so, I would expect the developers to apply it ans ask for update of the 2.2
po file.

Anyway, I will soon sync 2.1 into 2.2, before release of  beta of course (is
that still on February 7th ?).




Thanks for the info Jean-Pierre, good to know. I was assuming that the 
merge was done before starting the translations, so when I saw the 
update to fr.po on master I assumed that it had been forgotten. So this 
is entirely a false alarm.


It is also good to learn a bit more about the process, for instance I 
did not know that you made the merge yourself. This interests me in the 
perspective of the script I had written some time ago to replace "..." 
with proper ellipses, that needs to be run right after merge (but this 
will not be before 2.3). I will need to know exactly at which stage of 
the process do that.


Thank you for all your careful work on the French translation.

Lastly, Scott said that beta was going to be delayed, but I do not know 
how much.



Guillaume

Regression in fr.po

[Guillaume Munch]

Dear list,


The log at the top of fr.po in master ends as follows:


# --
# 3 avril 2014 : mise à jour pour 2.1.0
# --
# 23 mars 2015 : synchronisation avec les modifications de fr.po pour 2.1
#et traduction des nouveaux messages
#Traduction de « commit » par « validation »
#Unification de la dénomination de « FiXme »
#FiXme et TODO non traduits
# --
# 20 avril 2015 : retour à la typo Fixme au lieu de FiXme suite à un échange
# avec Jûrgen Spitzmûller
# --
# 29 décembre 2015 : mise à jour en vue de 2.2.0
# --
# 02 janvier 2016 : résolution de conflits de raccourcis
#   revue du vocabulaire du module Boîtes graphiques
# --


The same log in 2.1.x ends as follows:


# --
# 18 janvier 2015 : mise à jour pour 2.1.3
# --
# 24 février 2015 : suite traduction du manuel des légendes multilingues,
#   modification de quelques traductions
#   résolution de quelque conflits de raccourcis non 
détectés

# --
# 23 mars 2015 : correction de quelques traductions suite synchro fr.po 
pour 2.2

# --
# 19 mai 2015 : traduction des messages du module PDF forms
# --
# 18 juin 2015 : revue de la traduction des menus de formulaires PDF
# --
# 15 septembre 2015 : correction de raccourcis clavier problématiques
#(bogues #9745 & #9761) - Guillaume Munch
# --


In particular, the corrections from 15 Sept. 2015 are lost between
stable and master ("Search" and "Replace" share the same accelerator R
again in every dialog). At the time of my patch, I was told to commit to
stable because it would automatically be merged into master at string
freeze.

Were the instructions given to me the correct ones? How come we have
lost those fixes? Is it just a local problem or does that indicate that
there may be other regressions with other translations? What do we do to
repair this?

In particular during the discussion at the time it appeared that the
translation process was not properly documented, maybe people do not
yet agree on the process.


Sincerely,
Guillaume

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 21/01/2016 20:07, Uwe Stöhr a écrit :

Am 21.01.2016 um 07:06 schrieb Guillaume Munch:


The alignment is set correctly on opening. Wrong alignment appears when
modifying columns. To see the bug, try to see how the behaviour changes
when adding or deleting columns repeatedly after the first one.


I tried this but cannot see a problem in LyX 2.1.4 compared to LyX 2.2
with your patches applied. Could you give me a recipe?

Besides this, my bug report
http://www.lyx.org/trac/ticket/1497
is about the alignment within LyX and this is for me not changed with
your patch. Therefore I don't think that you fixed bug #1497 too.



Ok. Can you please tell me what issue you are referring to precisely in
#1497 then?

At first the bug is about wrong alignment in the "multline" environment.
But this has been fixed some time ago by Georg (the first line is
aligned to the left, the last line to the right).

Then you wrote "The wrong alignment of multiline equations inside LyX is
still in LyX 2.1.3", and with "multiline" I understood the other
multi-line math environments because to me multline is fixed.

In particular the above recipe is meant for align, aligned, etc.


Guillaume

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 21/01/2016 20:07, Uwe Stöhr a écrit :

Am 21.01.2016 um 07:06 schrieb Guillaume Munch:


The alignment is set correctly on opening. Wrong alignment appears when
modifying columns. To see the bug, try to see how the behaviour changes
when adding or deleting columns repeatedly after the first one.


I tried this but cannot see a problem in LyX 2.1.4 compared to LyX 2.2
with your patches applied. Could you give me a recipe?

Besides this, my bug report
http://www.lyx.org/trac/ticket/1497
is about the alignment within LyX and this is for me not changed with
your patch. Therefore I don't think that you fixed bug #1497 too.



Can you please tell me what issue you are referring to precisely in
#1497 then?

At first the bug is about wrong alignment in the "multline" environment.
But this has been fixed some time ago by Georg (the first line is
aligned to the left, the last line to the right).

Then you wrote "The wrong alignment of multiline equations inside LyX is
still in LyX 2.1.3", and with "multiline" I understood the other
multi-line math environments because to me multline is fixed.

In particular the above recipe is meant for align, aligned, etc.


Guillaume

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 21/01/2016 05:19, Enrico Forestieri a écrit :

On Wed, Jan 20, 2016 at 02:18:40AM +0100, Enrico Forestieri wrote:

On Sun, Jan 17, 2016 at 03:03:20AM +, Guillaume Munch wrote:

Le 16/01/2016 22:26, Enrico Forestieri a écrit :

On Sat, Jan 16, 2016 at 06:29:32PM +, Guillaume Munch wrote:


Le 16/01/2016 17:06, Enrico Forestieri a écrit :

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:


However, this reveals new ways of creating an "after" cursor
position:

* A visually-after cursor position appears with
Ctrl+Shift+Arrows (LFUN_*_SELECT_WORD of something like this).
It remains a right position after deselection, for instance by
doing copy and immediately paste.


I could not reproduce this one.


I can reproduce it systematically.

1. New file 2. Type something in an itemize environment 3. Enter
three times, get a separator 4. Place the cursor at the beginning
of the document 5. Ctrl+Shift+Right until the after position is
reached

optionally:

6. Do copy+paste, to get the same cursor position but with the
selection removed.


This only occurs when the separator is the last character in the
document. In this case you don't need Ctrl+Shift+Right but simply
use → to get there.


I cannot reproduce your description. My recipe works as well if there is
some paragraph after. (Also you can probably deduce from the context
that I would have noticed.)


Sorry, but it seems that I was simply using Shift+Right, even if I was
talking about Ctrl+Shift+Right... Yes, I can reproduce it and it also
happens with Left. I am attaching an updated patch taking also this into
account. I verified that it is still possible to get to that position
when randomly multiple clicking but did not discover a way to
sistematically trigger it. I fear that this may take some time to fix.
However, with this patch it should not be so easy to get after a separator.


Please, find attached an updated patch that moves the check for
separators on mouse clicks to a centralized place (also accounting
for shift-clicks and other modifiers).




Thank you for the patch, I started testing it but I would be more 
comfortable in testing it in the long term. I do not know enough about 
the architecture of mouse events to be personally confident about it.


For this patch and for the one at Wed, Jan 20, 2016 at 02:18, I also 
noticed that it skips the position right before the separator: it jumps 
from the beginning of the last word to the beginning of the first 
paragraph. It would be desirable to stop after the last word


For this patch I noticed that clicking in the right margin after a 
separator jumps to an unexpected location if the separator is in a 
collapsible inset (either at the start or the end of the inset).


Maybe we can go with the improvements you already made for beta, and 
commit this particular patch to master after release.



Guillaume

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 19/01/2016 19:00, Enrico Forestieri a écrit :

On Tue, Jan 19, 2016 at 05:27:47PM -0500, Guillaume Munch wrote:

Le 19/01/2016 16:44, Enrico Forestieri a écrit :

On Mon, Jan 18, 2016 at 10:37:23PM -0500, Guillaume Munch wrote:


Enrico: the width of the line of the plain separator changed, as you can
see, which I guess was not intended.


For the new symbol I used the width of 'n' instead of 'm'. As both kind
share the same base width, I tried to compensate choosing the width of
the plain separator as 8 times the width of 'n', while it previously
was 5 times the width of 'm'. I didn't care to measure the widths as I
deemed it not so important. Note also that this is font dependent.
You are welcome to suggest something different than 8 if you find it
is too large or too narrow with respect to the previous width.



I do not mind so much about the width itself. However what my screenshot
showed is that the line is shorter than the actual width of the spearator.
As you can see the paragraph mark is further on the right, which maybe is
confusing, and I thought was not intended.

If this is really intended, tell me and I will review your patch. Otherwise
I will be waiting for a corrected patch.


Sorry, I misunderstood. I had updated the width in metrics() but forgot to
do it in draw(). Updated patch attached.




Thanks, I tested the patch and it works well. The new method 
GuiPainter::path method seems safe because it is very similar to other 
ones in GuiPainter. The other changes look ok, as for the symbol choice 
Richard seemed positive about it. Please commit it, you have my +1.



Guillaume

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Guillaume Munch]

Le 21/01/2016 11:37, Scott Kostyshak a écrit :

On Wed, Jan 20, 2016 at 03:34:05PM +0100, Jean-Marc Lasgouttes wrote:

Good. Hopefully we can get a final review and +1 for Guillaume's pending
patches regarding #9794 and then I think we will be ready for beta.




I would like to mention that there has just been an additional 
declaration of interest by Uwe in this having this solved for 2.2, see 
.

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 19/01/2016 20:10, Uwe Stöhr a écrit :

Am 19.01.2016 um 23:45 schrieb Guillaume Munch:


Note that I do not know if it applies cleanly now.


Hmm, seems the bug in my git client is to "apply patch serial". This
means to apply 2 or more patches at once. When I apply them one after
another no problem occurs.

I did this (applied patch 1 and then patch 2) and compiled LyX without
problems.

Result: I used the attached LyX file to test and cannot see a difference
with your patch compared to LyX 2.1.4 in the LyX screen.

If you view the PDF of the file you see what I expected as alignment.
Did I make a mistake?

thanks and regards
Uwe



The alignment is set correctly on opening. Wrong alignment appears when 
modifying columns. To see the bug, try to see how the behaviour changes 
when adding or deleting columns repeatedly after the first one.


Best regards
Guillaume

Re: [LyX/master] Always place the cursor before a separator inset when clicking

[Guillaume Munch]

Le 20/01/2016 14:57, Enrico Forestieri a écrit :

On Wed, Jan 20, 2016 at 02:05:31AM -0500, Guillaume Munch wrote:

Le 19/01/2016 18:42, Enrico Forestieri a écrit :

On Tue, Jan 19, 2016 at 05:19:24PM -0500, Scott Kostyshak wrote:

On Sat, Jan 16, 2016 at 04:41:26PM +0100, Enrico Forestieri wrote:

commit 55b3374f3e3047a0aa7584e0737d1fcd40fe6809
Author: Enrico Forestieri <for...@lyx.org>
Date:   Sat Jan 16 16:41:04 2016 +0100

 Always place the cursor before a separator inset when clicking


Note that this commit might have triggered the assertion #9936.


Thanks. The attached patch fixes it for me.



You have added similar lines at several other places recently, after my
remarks. Should they be amended similarly?


No, the cursor is already in texted there.


Also, would it be better if you
factored the shared code in a new function?


They are only 2 lines of code, after all.



I think factoring the code is preferable in this situation. It
makes the code easier to understand and maintain. Also, it would check
for texted in all cases so it would depend on less assumptions. But I
also understand that you are very busy currently. I trust that you are
confident that no additional check for texted is required.

Guillaume

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Dear list,


We need to reach a conclusion on this to open the way for beta. It seems
we have come a long way on this series of patches so it would be nice to
know whether people who have participated in the discussion and asked
for modifications let us know whether they intend to let me go ahead on
this or not (hoping a move to behind Gare de Lyon went smoothly).

For the two aspects raised by Jean-Marc, I have found that it comes down
to the assumption that after the patch, "inset-modify tabular" is only
meant for tabulars and not math grids. Indeed, the only way prefs2prefs
leaves a "inset-modify tabular" command behind is if before the patch it
started with "from_dialog", and therefore did not work with math grids
before. All other "inset-modify tabular" commands are issued by the
tabular dialog and meant for tabulars as well.

We have taken our time for this series of patches (including the
Christmas disruption) and it has gone through several iterations
including implementing new conversion policies, and also I have been
testing it in master since the beginning of this month without seeing
any particular issue (though I know the interest of having tests made by
other people than me). So I feel pretty confident about it.

Let's go ahead with solving #9794 and releasing beta.


Guillaume



Le 11/01/2016 12:54, Guillaume Munch a écrit :

Le 11/01/2016 14:23, Jean-Marc Lasgouttes a écrit :

Le 08/01/2016 23:22, Guillaume Munch a écrit :

Thank you, waiting for Jean-Marc's opinion then.


A few comments on the patches. I was not able to apply them using "git
am" I am not sure how they were produced.


Strange. I rebased in the attached. If there are still issues please
give me the error message.





0001:
  * fix the log title (.sh, not .py)

0002:
  * be careful to update the commit hash when you actually commit.

  * Actually, I am not sure what this commit does here.


This is something I had to do in an earlier patch but did not know,
wanted to get confirmation. But I did not want to open a new thread just
for that.



0003:
  * I am not sure what the 'from-dialog' parameter does in the
GuiTabular dialog, so I am not really able to comment on this part.


It was used to bypass the status check of the command, because the
latter only checked the first command and therefore was incorrect for
what was coming from the dialog. I.e.:
* no keyword: broken status check
* from-dialog keyword: no status check (dispatched by the dialog)

Since we no longer use inset-modify for the interface, it makes more
sense to exchange the general and the special case, so that we now have:
* no keyword: no status check
* for-dialog: status check a single command (only passed internally by
the dialog to getStatus)




  * I'd prefer to rename getActionStatus to getFeatureStatus (or
something with feature in the name). Action is something else (in
frontend).

  * The parts that remove INSET_MODIFY handling in maths look OK at
first sight, but I cannot vouch for their general innocuousness.


UI commands are now tabular-feature. If Math receives inset-modify
tabular, then it comes from the tabular dialog, and therefore is not
meant for the math inset but the enclosing tabular. You can see that the
tabular dialog is a buggy if the cursor is located in math, and if you
click ok t says "unknown feature from-dialog".

Removing the handling of inset-modify tabular implies that inset-modify
is now dispatched by InsetMathNest, which disables it entirely (two
exceptions: InsetMathSpace and InsetMathRef). This corresponds to
current behaviour.

(I could go further and remove INSET_MODIFY from InsetMathNest. Then,
any inset-modify command would be dispatched to the enclosing text
inset. Maybe I'll do that after 2.2.)

InsetMathCases::doDispatch(): I kept the existing behaviour but do not
understand it fully. What is the effect of setting cur.undispatched()
before dispatching to the parent class? Is the setting not overridden by
the parent class?



0004: not my area of expertise


Then I rely on Georg for this one.



000[5678]: OK

0009:
  * maybe avoid the "default:" clause in InsetMathHull::isTable() and
use all the enum values.


Ok.




All in all, I like the patch, but I cannot check that it does everything
correctly.


Attached takes all comments into account. I hope the additional
explanations help.


Guillaume

Re: [LyX/master] Revert "Fix the display of column spacing in AMS environments"

[Guillaume Munch]

Le 19/01/2016 16:49, Stephan Witt a écrit :

Am 19.01.2016 um 22:40 schrieb Uwe Stöhr :


commit 360992cb9ff36f882e47036b6f6b1a5e3fe4efd7
Author: Uwe Stöhr 
Date:   Tue Jan 19 22:40:38 2016 +0100

Revert "Fix the display of column spacing in AMS environments"

This reverts commit bb5470b5d1ec1b2f7394164686d6035a0c4bce0f.

I have no clue what is with my GIT. I apologize. Can anybody please check 
if it is now OK again?


I don’t think so.

You had a merge conflict in change f1a388584fb2c043d17127d7db49c36cb8427cfa.

Sorry, I cannot help right now.




It seems you have correctly put everything back in order. git diff 
e5936b49 764a2163 shows no change for me. Please, someone double check.


Guillaume

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 19/01/2016 16:52, Uwe Stöhr a écrit :

Am 11.01.2016 um 03:21 schrieb Guillaume Munch:


See the attached for two "safe" (and easy to read) patches, if you agree
that a safe patch that we have been discussing for a month can still get
in for 2.2.


I wanted to apply the patches at once and this way destroyed my complete
git folder. Seems to be a bug in TortoiseGit. After the application it
tells me that nothing was changed, also the Git log is empty. But all
line endings are destroyed and the editor of MSVC cannot read the files
anymore.



I was not quite expecting my patch to be unsafe in this way! Please tell 
us if you find the cause.





However, I think I fixed it, re-applied the patches and tried to compile
but get:

   ..\..\..\src\mathed\InsetMathHull.cpp(1257): error C2039:
'isMutable': Is no element of 'lyx::InsetMathHull'
[D:\LyXGit\Master\compile-2010\src\mathed\mathed.vcxproj]




You are right, this is something I just forgot to remove during the 
rebase (and belongs to the third patch not proposed here). Try the 
attached (if you fixed your other bug!).


Note that I do not know if it applies cleanly now. I tried to rebase 
against newest master but your manipulation error now inteferes. I will 
have to rebase by hand.
>From fd5691e6489c34db3120ba24ce03cd496aacb134 Mon Sep 17 00:00:00 2001
From: Guillaume Munch <g...@lyx.org>
Date: Sun, 13 Dec 2015 03:32:32 +
Subject: [PATCH 1/2] Display the correct horizontal alignment in AMS
 environments

A longstanding problem... (related: #1861)

The columns in AMS math environments have a fixed alignment (colAlign() in
InsetMathGrid.cpp). We set this alignment for display (Georg's
displayColAlign()) in InsetMathHull and InsetMathSplit. This is done according
to tests and documentation for the various environments.

There is also some mechanical code factoring via colAlign().

Finally, I disable setting the horizontal alignment in InsetMathSplit, which has
no impact on the LaTeX output, and has no longer any impact on the screen. (As
for vertical alignment I discovered that it was in fact customisable for
\aligned & friends! I hope that the more faithful interface will let other
users discover that too.)
---
 src/mathed/InsetMathGrid.cpp  | 25 +
 src/mathed/InsetMathGrid.h|  5 +++--
 src/mathed/InsetMathHull.cpp  | 26 --
 src/mathed/InsetMathSplit.cpp | 37 +++--
 src/mathed/InsetMathSplit.h   |  2 ++
 5 files changed, 77 insertions(+), 18 deletions(-)

diff --git a/src/mathed/InsetMathGrid.cpp b/src/mathed/InsetMathGrid.cpp
index 536f4bd..fca5722 100644
--- a/src/mathed/InsetMathGrid.cpp
+++ b/src/mathed/InsetMathGrid.cpp
@@ -1838,4 +1838,29 @@ bool InsetMathGrid::getStatus(Cursor & cur, FuncRequest const & cmd,
 }
 
 
+// static
+char InsetMathGrid::colAlign(HullType type, col_type col)
+{
+	switch (type) {
+	case hullEqnArray:
+		return "rcl"[col % 3];
+
+	case hullMultline:
+	case hullGather:
+		return 'c';
+
+	case hullAlign:
+	case hullAlignAt:
+	case hullXAlignAt:
+	case hullXXAlignAt:
+	case hullFlAlign:
+		return "rl"[col & 1];
+
+	default:
+		return 'c';
+	}
+}
+
+
+
 } // namespace lyx
diff --git a/src/mathed/InsetMathGrid.h b/src/mathed/InsetMathGrid.h
index bd3066d..709f492 100644
--- a/src/mathed/InsetMathGrid.h
+++ b/src/mathed/InsetMathGrid.h
@@ -258,10 +258,11 @@ protected:
 	virtual docstring eocString(col_type col, col_type lastcol) const;
 	/// splits cells and shifts right part to the next cell
 	void splitCell(Cursor & cur);
-	/// Column aligmment for display of cell \p idx.
+	/// Column alignment for display of cell \p idx.
 	/// Must not be written to file!
 	virtual char displayColAlign(idx_type idx) const;
-
+	/// The value of a fixed col align for a certain hull type 
+	static char colAlign(HullType type, col_type col);
 
 	/// row info.
 	/// rowinfo_[nrows()] is a dummy row used only for hlines.
diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 097a344..78137de 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -349,28 +349,34 @@ bool InsetMathHull::idxLast(Cursor & cur) const
 }
 
 
+//FIXME: This has probably no effect and can be removed.
 char InsetMathHull::defaultColAlign(col_type col)
 {
-	if (type_ == hullEqnArray)
-		return "rcl"[col];
-	if (type_ == hullMultline)
-		return 'c';
-	if (type_ == hullGather)
-		return 'c';
-	if (type_ >= hullAlign)
-		return "rl"[col & 1];
-	return 'c';
+	return colAlign(type_, col);
 }
 
 
 char InsetMathHull::displayColAlign(idx_type idx) const
 {
-	if (type_ == hullMultline) {
+	switch (type_) {
+	case hullMultline: {
 		row_type const r = row(idx);
 		if (r == 0)
 			return 'l';
 		if (r == nrows() - 1)
 			return 'r';
+		return 'c';
+	}
+	case hullEqnArray:
+	case hullGather:
+	case hullAlign:
+	case hullAlignAt:
+	case hullXAlignAt:
+	case h

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 19/01/2016 16:44, Enrico Forestieri a écrit :

On Mon, Jan 18, 2016 at 10:37:23PM -0500, Guillaume Munch wrote:


Enrico: the width of the line of the plain separator changed, as you can
see, which I guess was not intended.


For the new symbol I used the width of 'n' instead of 'm'. As both kind
share the same base width, I tried to compensate choosing the width of
the plain separator as 8 times the width of 'n', while it previously
was 5 times the width of 'm'. I didn't care to measure the widths as I
deemed it not so important. Note also that this is font dependent.
You are welcome to suggest something different than 8 if you find it
is too large or too narrow with respect to the previous width.



I do not mind so much about the width itself. However what my screenshot 
showed is that the line is shorter than the actual width of the 
spearator. As you can see the paragraph mark is further on the right, 
which maybe is confusing, and I thought was not intended.


If this is really intended, tell me and I will review your patch. 
Otherwise I will be waiting for a corrected patch.

Re: [LyX/master] Always place the cursor before a separator inset when clicking

[Guillaume Munch]

Le 19/01/2016 18:42, Enrico Forestieri a écrit :

On Tue, Jan 19, 2016 at 05:19:24PM -0500, Scott Kostyshak wrote:

On Sat, Jan 16, 2016 at 04:41:26PM +0100, Enrico Forestieri wrote:

commit 55b3374f3e3047a0aa7584e0737d1fcd40fe6809
Author: Enrico Forestieri 
Date:   Sat Jan 16 16:41:04 2016 +0100

 Always place the cursor before a separator inset when clicking


Note that this commit might have triggered the assertion #9936.


Thanks. The attached patch fixes it for me.



You have added similar lines at several other places recently, after my 
remarks. Should they be amended similarly? Also, would it be better if 
you factored the shared code in a new function?


Guillaume

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 18/01/2016 19:19, Enrico Forestieri a écrit :

On Tue, Jan 12, 2016 at 08:00:18PM -0500, Richard Heck wrote:

On 01/12/2016 06:53 PM, Enrico Forestieri wrote:

What about a symbol like the attached one? It resembles a pilcrow with a
left pointing arrow.


That looks good to me, and of course we don't want to rely upon color,
especially red.


The attached patch implements this symbol.

I tried using GuiPainter::arc but did not succeed in convincing Qt
to draw the arc such that its ends were fitting the horizontal strokes.
As a consequence, the symbol was looking really ugly. So, I implemented
GuiPainter::path to draw paths with bezier curves and now the symbol
looks nice.




For anybody curious, here is how it looks like.

Enrico: the width of the line of the plain separator changed, as you can 
see, which I guess was not intended.

Re: [LyX/master] Update LFUNs.lyx to current format

[Guillaume Munch]

Le 16/01/2016 10:12, Georg Baum a écrit :

Guillaume Munch wrote:


I believe as well that we should not extend the already long checklist
for format changes. Updatedocs could take care of running gen_lfuns and
then update it to the latest format.


Good idea. I added the generation of LFUNs.lyx, the version updating did
exist already. However, I think we should stick to one generator of
LFUNs.lyx in git: Either we only submit files generated by gen_lfuns.py, and
not saved by LyX or lyx2lyx (this is done up to now), or we always open and
save the file with LyX after generation and before submit. Otherwise we get
lots of unwanted whitespace changes in the diffs.



Good. But if we go this way, Development.lyx has to be updated to inform
that this is now done automatically and in particular that one should
not necessarily worry if there are more changes than expected in LFUNs.lyx.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 22:26, Enrico Forestieri a écrit :

On Sat, Jan 16, 2016 at 06:29:32PM +, Guillaume Munch wrote:


Le 16/01/2016 17:06, Enrico Forestieri a écrit :

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:


However, this reveals new ways of creating an "after" cursor
position:

* A visually-after cursor position appears with
Ctrl+Shift+Arrows (LFUN_*_SELECT_WORD of something like this).
It remains a right position after deselection, for instance by
doing copy and immediately paste.


I could not reproduce this one.


I can reproduce it systematically.

1. New file 2. Type something in an itemize environment 3. Enter
three times, get a separator 4. Place the cursor at the beginning
of the document 5. Ctrl+Shift+Right until the after position is
reached

optionally:

6. Do copy+paste, to get the same cursor position but with the
selection removed.


This only occurs when the separator is the last character in the
document. In this case you don't need Ctrl+Shift+Right but simply
use → to get there.


I cannot reproduce your description. My recipe works as well if there is
some paragraph after. (Also you can probably deduce from the context
that I would have noticed.)




* A logically-after cursor position appears when double
clicking the separator inset or the line.


This one was easy. It was also occurring when triple clicking.
See attached.



It is somehow better, but it is very strange because the behaviour
is not consistent: most of the time it selects the word before, but
sometimes it selects the separator (i.e. separator is removed if I
type a key). I get the second behaviour if I quadruple-click (!!)
on the separator or after it (but this was not the only way).


So, what would be missing is a visual indication that the separator
was selected. I don't know how to do that, but maybe someone else
does.


Something else: if you place the cursor before a separator and
press enter, the separator stays on the same paragraph. Is this
voluntary?


Yes. Ideally, you are at the end of the line and pressing enter there
gets you a new paragraph.


Ok, this is just something to get used to.




Also, I was wondering whether we should remove superfluous
separators in the DEPM. This would make a lot of sense to me.


Then, the same should be done for the newline inset. For example,
hit 3 or more times Ctrl+Enter in a standard layout, then remove
everything in the paragraph before the first newline inset (such
that it is now alone on the line). Now you have an uncompilable
document. At least, it could be compiled if you had multiple
separators like that.


I disagree with your newline comparison. Having several newlines
compiles to a different latex code and makes sense, and compilation
issues have nothing to do with DEPM.



Please note that we can stay here finding much more quirks in LyX
that are annoying. The point is that they are not so annoying if
they can only be obtained with uncommon operations.


The "uncommon operations" are only recipes to reproduce consistently. Of
course they can look far-fetched. I got there by trying to reproduce
behaviour that happened by chance without trying too much. I believe you
are shooting the messenger.

The editing operations in the buffer view are a critical part of lyx,
and one that does not suffer from clumsiness so far, which is essential
in particular for the learning curve given that it is so much different
from other softwares. It worries me to introduce quirks and inconsistent
behaviour in this aspect, such as not knowing whether one has to hit del
of backspace, or why the thing suddenly disappeared.



Then, this being free software, if they annoy someone so much, he
can also propose patches.



I prefer not to reply to this or we could get into considerations quite
remote from our current concerns using the same logic.

If you are worried about my suggestion about DEPM being too much for 2.2
you can just say so. You may have noticed that I used a different
phrasing, and I was ready to say that this can be filed as an
enhancement request. Please do not worry about this last suggestion.



Guillaume

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Guillaume Munch]

Le 16/01/2016 22:43, Scott Kostyshak a écrit :

Dear all,

Hopefully we will release beta1 very soon. As far as I'm concerned, the
only thing we are waiting for is the Windows installer(s). The reason
why we are waiting for this and not just proceeding with the other parts
of the beta1 release is that there might be changes needed to the source
to clear up the build issues. These changes should be included in beta1.
There are some questions about the build process that we hope to clear
up; and if Uwe is OK with it, I think it would be great to build both an
MSVC installer and an MinGW installer. We all understand that Uwe does
not have much time, but it also seems that it might not require too much
of his time, thanks to the help from Georg, Peter, and Kornel for build
and CMake issues.

After that is cleared up, I will do some final commits and build the tar
balls. It would be nice to have a day or so where there are no commits
so that we are all encouraged to test beta1 for a day.

Please let me know if I'm missing anything.



I think we are waiting for a last input about tabular-modify: 
. I do not imagine 
there is any question of committing this between beta and release, so 
given that it has a file format change, it has to be before beta1 or not 
until 2.3. But as I understand we are nearly done and nobody is trying 
to postpone this.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 22:26, Enrico Forestieri a écrit :


It is somehow better, but it is very strange because the behaviour is not
consistent: most of the time it selects the word before, but sometimes it
selects the separator (i.e. separator is removed if I type a key). I get the
second behaviour if I quadruple-click (!!) on the separator or after it (but
this was not the only way).


So, what would be missing is a visual indication that the separator was
selected. I don't know how to do that, but maybe someone else does.



Forgot to reply to this one.

I do not know. I would agree with the logic that the separator cannot be
selected. I think the visual indication is a separate issue, the issue
being more that it does not behave in a predictable fashion.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 17:06, Enrico Forestieri a écrit :

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:


However, this reveals new ways of creating an "after" cursor position:

* A visually-after cursor position appears with Ctrl+Shift+Arrows
(LFUN_*_SELECT_WORD of something like this). It remains a right position
after deselection, for instance by doing copy and immediately paste.


I could not reproduce this one.


I can reproduce it systematically.

1. New file
2. Type something in an itemize environment
3. Enter three times, get a separator
4. Place the cursor at the beginning of the document
5. Ctrl+Shift+Right until the after position is reached

optionally:

6. Do copy+paste, to get the same cursor position but with the selection 
removed.





* A logically-after cursor position appears when double clicking the
separator inset or the line.


This one was easy. It was also occurring when triple clicking. See attached.



It is somehow better, but it is very strange because the behaviour is 
not consistent: most of the time it selects the word before, but 
sometimes it selects the separator (i.e. separator is removed if I type 
a key). I get the second behaviour if I quadruple-click (!!) on the 
separator or after it (but this was not the only way).


Something else: if you place the cursor before a separator and press 
enter, the separator stays on the same paragraph. Is this voluntary?


Also, I was wondering whether we should remove superfluous separators in 
the DEPM. This would make a lot of sense to me. There are a lot of ways 
to get superfluous separators: if I accidentally press enter 3 times 
instead of 2 while all I want is start a new paragraph, or if I do 
copy-paste...



Guillaume

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 15:52, Enrico Forestieri a écrit :

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:


Le 14/01/2016 20:13, Enrico Forestieri a écrit :

On Thu, Jan 14, 2016 at 03:59:41PM +, Guillaume Munch wrote:


We might be speaking of two different issues:

* If I click on the right-hand half of the separator, the cursor moves
after the separator both visually and logically (a position that cannot
be reached using ← and →).

* If I click further on the line to the right of the separator (does not
need to be too far away), then the cursor gets located visually to the
left and logically to the right (what could be reached using ↑ and ↓
until your patch).

To see if the cursor is logically to the left or the right of the
separator, I try to see which of Del of Backspace deletes it.


I have now found where to tweak the sources and the attached x1.diff
patch solves the issue for me.


Thanks again for taking all these remarks into account.

x1.diff works as expected, it solves both issues, and I am ready to +1 you.


Committed.


However, this reveals new ways of creating an "after" cursor position:

* A visually-after cursor position appears with Ctrl+Shift+Arrows
(LFUN_*_SELECT_WORD of something like this). It remains a right position
after deselection, for instance by doing copy and immediately paste.

* A logically-after cursor position appears when double clicking the
separator inset or the line.


I will have a look. However, this may take some time because, as already
said, I am not too familiar with this part of the code.


A second issue I just noticed is when deleting the separator: the
paragraph after should not immediately be merged with the one that
contains the deleted separator, if none is empty, I think. Hitting Del
should just remove the separator. (To test this, start with two
non-empty enumerate environments with a par break separator at the end
of the first one, and then try to delete the separator.)


I will have a look at this.


The attached x2.diff patch takes care of this. It seems that this
behavior was a deliberate choice of mine, but it was wrong, apparently.



Actually I think it was a good idea, but only when the separator is alone on
the line. Would you like to keep your code but add instead a check for the
separator being alone on its paragraph? Otherwise I can vouch for the patch,
if you prefer removing your code.


On second thought, I think it is better to not complicate the code for a
not so clear improvement. If the separator was alone on the line, that
line will be automatically removed by the DEPM mechanism. So, I committed
the patch as is.



Ok. What does DEPM stands for?

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 18:34, Enrico Forestieri a écrit :

On Wed, Jan 13, 2016 at 11:15:44PM +0100, Enrico Forestieri wrote:

On Wed, Jan 13, 2016 at 06:40:21PM +, Guillaume Munch wrote:


Maybe ¶ does not grow on you as it did on me, but ultimately it is going
to be your call.


Maybe ¶ is also easier to implement and distinguishable by its different
shading rather than color.


I just discovered the reversed pilcrow sign ⁋ (u+204b) and used this in
the attached patch. If this is acceptable as a parbreak separator there
would be no problem as regards distinguishability.



The patch seems safe to me although I am not an expert of such code.
However, for the reversed pilcrow, there was issues with it recently
(see d9524321).

I noticed something interesting: a parbreak separator can be used in the
middle of an itemize environment to start a new latex paragraph in the
item (using existing tricks to get to get the cursor after the
separator) as an alternative to using a new lyx paragraph + indentation.


Guillaume

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 22:31, Enrico Forestieri a écrit :

On Sat, Jan 16, 2016 at 07:14:56PM +, Guillaume Munch wrote:


Le 16/01/2016 18:34, Enrico Forestieri a écrit :

On Wed, Jan 13, 2016 at 11:15:44PM +0100, Enrico Forestieri wrote:

On Wed, Jan 13, 2016 at 06:40:21PM +, Guillaume Munch wrote:


Maybe ¶ does not grow on you as it did on me, but ultimately it is going
to be your call.


Maybe ¶ is also easier to implement and distinguishable by its different
shading rather than color.


I just discovered the reversed pilcrow sign ⁋ (u+204b) and used this in
the attached patch. If this is acceptable as a parbreak separator there
would be no problem as regards distinguishability.



The patch seems safe to me although I am not an expert of such code.


I have difficulties interpreting this as a +1.


I tested the patch and convinced myself that the patch was essentially 
moving block boundaries, so I am ready to +1 if we specifically test it 
on windows in case you decide for the reversed pilcrow. Thank you for 
the patch in any case.





However, for the reversed pilcrow, there was issues with it recently
(see d9524321).


I cannot see anything related to the reversed pilcrow there.


It removes 0x204B in Changes.cpp, but more importantly there is a link 
to the beginning of the discussion on the list. Essentially, it did not 
display on windows (I was able to check on windows 10). Maybe qt5 fixes 
that, and I would be able to test again after a windows installer is 
released if you decide to put it in beta. Other people would need to 
test on older versions of windows. Also you know that I prefer the 
pilcrow, but this is your call. Given that it is not something that we 
would like to change lightly, I think you would be justified in asking 
for additional tests.

Re: [LyX/master] Update LFUNs.lyx to current format

[Guillaume Munch]

Le 15/01/2016 20:32, Georg Baum a écrit :

commit 4c3b8bf7c7205e26b28b6562be11105558ec3250
Author: Georg Baum 
Date:   Fri Jan 15 21:31:57 2016 +0100

 Update LFUNs.lyx to current format

diff --git a/development/tools/gen_lfuns.py b/development/tools/gen_lfuns.py
index 8e4bc88..0fb9380 100755
--- a/development/tools/gen_lfuns.py
+++ b/development/tools/gen_lfuns.py
@@ -43,9 +43,10 @@ ID_DICT = dict(name=LFUN_NAME_ID, action=LFUN_ACTION_ID, 
notion=LFUN_NOTION_ID,
  syntax=LFUN_SYNTAX_ID, params=LFUN_PARAMS_ID, 
sample=LFUN_SAMPLE_ID, origin=LFUN_ORIGIN_ID)

  LFUNS_HEADER = """# gen_lfuns.py generated this file. For more info see 
http://www.lyx.org/
-\\lyxformat 503
+\\lyxformat 504
  \\begin_document
  \\begin_header
+\\save_transient_properties true
  \\origin /systemlyxdir/doc/
  \\textclass article
  \\begin_preamble



Is a step in Development.lyx missing?

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 14/01/2016 20:13, Enrico Forestieri a écrit :

On Thu, Jan 14, 2016 at 03:59:41PM +, Guillaume Munch wrote:


We might be speaking of two different issues:

* If I click on the right-hand half of the separator, the cursor moves
after the separator both visually and logically (a position that cannot
be reached using ← and →).

* If I click further on the line to the right of the separator (does not
need to be too far away), then the cursor gets located visually to the
left and logically to the right (what could be reached using ↑ and ↓
until your patch).

To see if the cursor is logically to the left or the right of the
separator, I try to see which of Del of Backspace deletes it.


I have now found where to tweak the sources and the attached x1.diff
patch solves the issue for me.


Thanks again for taking all these remarks into account.

x1.diff works as expected, it solves both issues, and I am ready to +1 you.

However, this reveals new ways of creating an "after" cursor position:

* A visually-after cursor position appears with Ctrl+Shift+Arrows 
(LFUN_*_SELECT_WORD of something like this). It remains a right position 
after deselection, for instance by doing copy and immediately paste.


* A logically-after cursor position appears when double clicking the 
separator inset or the line.






A second issue I just noticed is when deleting the separator: the
paragraph after should not immediately be merged with the one that
contains the deleted separator, if none is empty, I think. Hitting Del
should just remove the separator. (To test this, start with two
non-empty enumerate environments with a par break separator at the end
of the first one, and then try to delete the separator.)


I will have a look at this.


The attached x2.diff patch takes care of this. It seems that this
behavior was a deliberate choice of mine, but it was wrong, apparently.



Actually I think it was a good idea, but only when the separator is 
alone on the line. Would you like to keep your code but add instead a 
check for the separator being alone on its paragraph? Otherwise I can 
vouch for the patch, if you prefer removing your code.






If you think that hitting enter should introduce a plain separator
instead of a parbreak one, this would be accomplished in the sources
with a really trivial change. I choose a parbreak simply because it
is completely equivalent to the old Separator layout.
However, note that when importing old documents, the old Separator
layout has still to be converted to a parbreak separator, otherwise
the output might be changed.



I did not think of it this way but, yes, this would be a convenient
solution. The main advantage, I find, is the overall consistency in
the chosen solution, in particular with Alt+M P.


This would be accomplished by the attached patch.



Indeed the patch is trivial and I can vouch for it (if needed
symbolically). Please commit it if you are convinced as well that this
is a good solution.


I took this as a +1 and committed the patch.


Thanks.


Guillaume

Re: [LyX/master] Update LFUNs.lyx to current format

[Guillaume Munch]

Le 15/01/2016 20:50, Georg Baum a écrit :

Guillaume Munch wrote:


Is a step in Development.lyx missing?


IIRC we did not decide that yet. IMHO it is not required to update these
files for each format change, but some time ago we decided that for a
release all files should be up to date, and it is in the release checklist.



I believe as well that we should not extend the already long checklist 
for format changes. Updatedocs could take care of running gen_lfuns and 
then update it to the latest format.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 13/01/2016 22:03, Enrico Forestieri a écrit :

On Tue, Jan 12, 2016 at 11:48:41PM +, Guillaume Munch wrote:


Now I noticed that the "after" position can still be accessed with mouse
clicks at the end of the line. I imagine that there can still be many
commands that can produce this "after" position.


I remember that I was only able to void that position when clicking
with the mouse sufficiently far away from the end of the line. If the
click was precisely just after the last character, the damn'd cursor
was positioned there. I am afraid I don't know the part of the code
that deals with this and will not be able to correct it. I thought
that, given that the mouse has to be in a very restricted area of the
screen for that to happen, it was not much of an annoyance.


We might be speaking of two different issues:

* If I click on the right-hand half of the separator, the cursor moves
after the separator both visually and logically (a position that cannot
be reached using ← and →).

* If I click further on the line to the right of the separator (does not
need to be too far away), then the cursor gets located visually to the
left and logically to the right (what could be reached using ↑ and ↓
until your patch).

To see if the cursor is logically to the left or the right of the
separator, I try to see which of Del of Backspace deletes it.




A second issue I just noticed is when deleting the separator: the
paragraph after should not immediately be merged with the one that
contains the deleted separator, if none is empty, I think. Hitting Del
should just remove the separator. (To test this, start with two
non-empty enumerate environments with a par break separator at the end
of the first one, and then try to delete the separator.)


I will have a look at this.


If you think that hitting enter should introduce a plain separator
instead of a parbreak one, this would be accomplished in the sources
with a really trivial change. I choose a parbreak simply because it
is completely equivalent to the old Separator layout.
However, note that when importing old documents, the old Separator
layout has still to be converted to a parbreak separator, otherwise
the output might be changed.



I did not think of it this way but, yes, this would be a convenient
solution. The main advantage, I find, is the overall consistency in
the chosen solution, in particular with Alt+M P.


This would be accomplished by the attached patch.



Indeed the patch is trivial and I can vouch for it (if needed
symbolically). Please commit it if you are convinced as well that this
is a good solution.

Thanks for looking into these issues.

Also, thanks for fixing the original issue. I saw the benefits no later
than yesterday with beamer. LyX used to cause all sorts of vertical
spacing issues with beamer which I have not seen since I use 2.2.


Guillaume

Re: [LyX/master] Add \save_transient_properties parameter (#9841)

[Guillaume Munch]

Le 13/01/2016 18:20, Guillaume Munch a écrit :


i = find_token(document.header, '\\begin_header', 0)
if i = -1:
 document.warning("Malformed lyx document: Missing
'\\begin_header'!!")
 return
document.header.insert(i + 1, '\\save_transient_properties true')

That puts it at the beginning of the header, which is where LyX writes
it.


Yes, I do not mind. I understand that looking for \begin_header
instead of \origin “seems” more general, but are there precise rules or
use cases that I am unaware of that made you think that it was “wrong”?




I pushed the trivial patch after assuming that two people agreeing on 
the same piece of code is equivalent to a "+1".

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 14/01/2016 20:56, Georg Baum a écrit :

Georg Baum wrote:


Guillaume Munch wrote:


Le 11/01/2016 14:23, Jean-Marc Lasgouttes a écrit :


0004: not my area of expertise


Then I rely on Georg for this one.


I already wrote that the lyx2lyx and prefs2prefs changes are OK, so you
have my +1 for this one.


To clarify: for 0004-New-LFUN-tabular-feature-update-prefs2prefs.py.patch
from January 8,



Yes, that one. Moreover by mentioning lyx2lyx you also gave +1 for 0006 
"New LFUN tabular-feature: convert inset-modify tabular in LyX files" 
(0004 in the Jan 11th message), but Jean-Marc said OK as well.


As I understand, only "New LFUN tabular-feature (#9794)" still requires 
an OK, on two aspects: the for-dialog keyword (limit the use of the 
broken status check), and not handling "inset-modify tabular" in math 
anymore (fix weird behaviour of the tabular dialog in math cells).


Guillaume

Re: [LyX/master] Add \save_transient_properties parameter (#9841)

[Guillaume Munch]

Le 13/01/2016 17:46, Richard Heck a écrit :

On 01/12/2016 04:36 PM, Guillaume Munch wrote:


diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index 5a639cd..5361420 100644
--- a/lib/lyx2lyx/lyx_2_2.py
+++ b/lib/lyx2lyx/lyx_2_2.py
@@ -2184,6 +2184,23 @@ def revert_verbatim_star(document):
  revert_verbatim(document, True)


+def convert_save_props(document):
+" Add save_transient_properties parameter. "
+i = find_token(document.header, '\\origin', 0)
+if i == -1:
+document.warning("Malformed lyx document: Missing '\\origin'.")
+return
+document.header.insert(i, '\\save_transient_properties true')


This seems wrong. Was the idea to write it before \origin because that's
how LyX writes it? If so, that's sensible, but we can still write it if
\origin isn't there. You can do something like:

+i = find_token(document.header, '\\origin', 0)
+if i == -1:
+document.warning("Malformed lyx document: Missing '\\origin'.")
+i = find_token(document.header, '\\end_header', 0)
+if i == -1:
+document.warning("Malformed lyx document: Missing 
'\\end_header'!!")
+return
+document.header.insert(i, '\\save_transient_properties true')

In fact, in this case, we could even do:

i = find_token(document.header, '\\begin_header', 0)
if i = -1:
 document.warning("Malformed lyx document: Missing '\\begin_header'!!")
 return
document.header.insert(i + 1, '\\save_transient_properties true')

That puts it at the beginning of the header, which is where LyX writes it.


Yes, I do not mind. I understand that looking for \begin_header
instead of \origin “seems” more general, but are there precise rules or
use cases that I am unaware of that made you think that it was “wrong”?

>From 0303140e4e782b2b78009a54c99a0fab8cf9bfe5 Mon Sep 17 00:00:00 2001
From: Guillaume Munch <g...@lyx.org>
Date: Wed, 13 Jan 2016 18:16:00 +
Subject: [PATCH] Amend 5c2d0499

---
 lib/lyx2lyx/lyx_2_2.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index 5361420..ece452d 100644
--- a/lib/lyx2lyx/lyx_2_2.py
+++ b/lib/lyx2lyx/lyx_2_2.py
@@ -2186,11 +2186,11 @@ def revert_verbatim_star(document):
 
 def convert_save_props(document):
 " Add save_transient_properties parameter. "
-i = find_token(document.header, '\\origin', 0)
+i = find_token(document.header, '\\begin_header', 0)
 if i == -1:
-document.warning("Malformed lyx document: Missing '\\origin'.")
+document.warning("Malformed lyx document: Missing '\\begin_header'.")
 return
-document.header.insert(i, '\\save_transient_properties true')
+document.header.insert(i + 1, '\\save_transient_properties true')
 
 
 def revert_save_props(document):
-- 
2.1.4

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 13/01/2016 01:00, Richard Heck a écrit :

On 01/12/2016 06:53 PM, Enrico Forestieri wrote:

On Tue, Jan 12, 2016 at 11:49:54PM +0100, Enrico Forestieri wrote:

On Mon, Jan 11, 2016 at 03:04:33AM +, Guillaume Munch wrote:


For the symbol itself, my suggestion was a very elongated version of ⌟,
meant to recall the plain separator inset. But, a character that
would match the meaning would be the pilcrow sign (¶). One would just
have to make sure the a grey pilcrow sign (from end-of-paragraph marks)
is not displayed after a red pilcrow sign because this would look weird
(although could be allowed as a temporary measure). On the other hand,
what was the idea behind your suggestion of ↔ ?

The symbol should not be too large, because it can also appear at the
end of a line when importing old documents, so that the appearance
would be ugly. The ↔ is simply a symbol that cannot be exchanged with
the newline one and also gives the idea of a separator, although it
probably fails to convey the concept that it introduces a blank line
in the latex output.

What about a symbol like the attached one? It resembles a pilcrow with a left 
pointing arrow.



It's better than what we have now at least :) However I am not so fan of
hand drawn symbols. I have failed to find anything coming close to that
symbol in Unicode. I find that the left pointing arrow removes rather
than adds. But it's better.

Maybe ¶ does not grow on you as it did on me, but ultimately it is going
to be your call.



and of course we don't want to rely upon color,
especially red.



I am sceptical about this statement. Can you please develop? A contrast
between a light color and a dark color is sufficient for every
kind of color impairment.


Guillaume

Re: beta release

[Guillaume Munch]

Le 12/01/2016 20:28, Scott Kostyshak a écrit :


Can anyone +1 this issue as a beta blocker? I did not follow the
discussion closely.



I think this should be done before release. Does it mean that I have to make
it a beta blocker?


No. In my opinion, a beta blocker is something that falls into one of
the following categories:

(1) a fix for a bug that would be so annoying for the user that they
would not give beta1 a good test, and it might even scare them from
testing future pre-release versions of LyX.

(2) a fix that us developers can't test completely ourselves and we
would need a wider test base to be confident in a change before a
release with it. In this category I put Windows-specific and
Mac-specific bugs, for example. Also bugs that we weren't able to
reproduce ourselves (and thus we cannot check whether a fix really does
fix anything). I think removing the PNGs was a good example of this. I
would not have wanted to do that after beta. Thankfully one of our
alpha-testers, Andrew, caught a problem that occurs on Windows. I'm now
confident in the change and I'm glad we have it for 2.2.0.

(3) a bug fix that represents a big change and we are unsure of
possible unwanted consequences. We would not want to put this in a final
release directly.

Note that I just made up the above three categories. I would be
interested in your thoughts and the thoughts of others and would add
these to the release manager notes that I am collecting.


Not a beta blocker then.



Also, what is this timeout issue? Some people do not get new messages sent
to old threads?


I don't understand. Did I bring up the timeout issue? Which quoted text
are you referring to?


below


I looked at the thread (actually it timed out for me but I could
search the MID and found it on mail-archive here [1]).

Re: User pref parameters

[Guillaume Munch]

Le 12/01/2016 19:36, Georg Baum a écrit :

Pavel Sanda wrote:


Guillaume Munch wrote:

I am not convinced by the naming vcs_simplify_format but maybe there are
other suggestions? What about save_transient_properties or save_state ?


I am fine with save_transient_properties as well. P


me too (and I do not like vcs_simplify_format, since this is really not
limited to using a vcs).





Yet transient is not entirely accurate either.

For instance, \origin is going to cause problems if any collaborator
through a VCS decides to store his own local path (which is a setting
global to lyx!). Should we not set \origin unavailable when
store_user_preferences is false? (I am seriously asking)

Re: beta release

[Guillaume Munch]

Le 12/01/2016 22:06, Enrico Forestieri a écrit :

On Tue, Jan 12, 2016 at 04:51:34PM -0500, Scott Kostyshak wrote:

On Tue, Jan 12, 2016 at 10:45:53PM +0100, Enrico Forestieri wrote:


I hope both of you are not serious.


I was completely serious. I did not follow the issue and did not want to
invest the time when I know there were other developers who are familiar
with the issue and thus understand its importance. I think that every
developer should be allowed to propose an issue as a beta blocker and I
would prefer for a separate developer to +1 that proposal.


Then, please don't be surprised that I am scared by the fact that a
stupid thing can be tacken as a blocker.


In any case, Guillaume has withdrawn his proposal that it be a beta
blocker after a discussion on what I view a beta blocker to be (I'm
still interested in feedback on other opinions on that thread if there
are any).


If things like that are blockers, lyx 2.2 would never be released.



Dear Enrico,

Do not worry. With my original message I only meant to inquire about
what was considered a beta blocker, and also I wanted to incite people
to give their opinion about the symbol. Then Scott interpreted it as me
voting for beta blocker status. Also, now I understand that between beta
and release, more things can happen than what I thought. Sorry for the 
scare!


Guillaume

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 12/01/2016 22:49, Enrico Forestieri a écrit :

On Mon, Jan 11, 2016 at 03:04:33AM +, Guillaume Munch wrote:


Dear Enrico,


Thank you for the recent patches that took into account some of my remarks.

I have been using master a lot recently and I noticed another issue
which annoyed me: In 2.1, the behaviour when typing Enter at the
beginning of a paragraph is consistently to start a new paragraph before
it. In 2.2, the behaviour changes and sometimes it introduces a parbreak
separator instead, after a non-standard paragraph. The behaviour is now
inconsistent. I think that the introduction of a parbreak separator
after a non-standard paragraph should only happen on an empty paragraph.
This does not change the amount of Enter required to introduce a
separator from a non-standard paragraph, but restores the consistency of
introducing a new paragraph with Enter at the start of a paragraph.


Please, can you try the attached patch and report back whether it does
what you expect?


It does, thank you. That was definitely the small issue that was the
most annoying in practice. Have my "+1" for the patch.

Now I noticed that the "after" position can still be accessed with mouse
clicks at the end of the line. I imagine that there can still be many
commands that can produce this "after" position.

A second issue I just noticed is when deleting the separator: the
paragraph after should not immediately be merged with the one that
contains the deleted separator, if none is empty, I think. Hitting Del
should just remove the separator. (To test this, start with two
non-empty enumerate environments with a par break separator at the end
of the first one, and then try to delete the separator.)



Then, please let me thank you for your reports aimed at improving the
overall user experience. I only regret that they are the only ones
after almost two years from the introduction of env separators and that
they come just before a release, when the time for testing is not so
much.


Still better than users complaining during beta! or after release...

You are welcome. What might have contributed to the lack of feedback is 
that it was a sum of many small details that take time and effort to 
disentangle. This sort of issues is very hard to report. Also in my 
case, although I wanted to report them, I first wanted to understand the 
rationale, so I was waiting for some documentation, since it was marked 
as undocumented on the wiki...





Also, I wanted to say that given that I did not follow the original
conversations, I have more of a user's view on this, so I do not think
that my comments are redundant. Users, new users, now, and in two years,
are not going to care about historic reasons for such interface choices...


Agreed.


For the symbol itself, my suggestion was a very elongated version of ⌟,
meant to recall the plain separator inset. But, a character that
would match the meaning would be the pilcrow sign (¶). One would just
have to make sure the a grey pilcrow sign (from end-of-paragraph marks)
is not displayed after a red pilcrow sign because this would look weird
(although could be allowed as a temporary measure). On the other hand,
what was the idea behind your suggestion of ↔ ?


The symbol should not be too large, because it can also appear at the
end of a line when importing old documents, so that the appearance
would be ugly. The ↔ is simply a symbol that cannot be exchanged with
the newline one and also gives the idea of a separator, although it
probably fails to convey the concept that it introduces a blank line
in the latex output.


Yes, this is what I think for ↔. So what about a red ¶ ? This now seems
the appropriate choice to me for a par break. The color distance with
the end-of-paragraph marks (light grey) is sufficient.




Finally, for the entry method, you are already changing the meaning of
"Alt+M P" from "parbreak separator" to "plain separator", so in any case
you are already making a choice. I wanted to say that if the one who
implements a new feature does not think about what is the best default,
who does? I had to configure LyX for several co-authors and already have
too much settings to remember to change (enabling paragraph marks,
setting forward-search, some shortcuts...).


If you think that hitting enter should introduce a plain separator
instead of a parbreak one, this would be accomplished in the sources
with a really trivial change. I choose a parbreak simply because it
is completely equivalent to the old Separator layout.
However, note that when importing old documents, the old Separator
layout has still to be converted to a parbreak separator, otherwise
the output might be changed.



I did not think of it this way but, yes, this would be a convenient
solution. The main advantage, I find, is the overall consistency in
the chosen solution, in particular with Alt+M P.


Guillaume

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 11/01/2016 21:41, Georg Baum a écrit :

Guillaume Munch wrote:


I replace stored alignment and spacing values with computed values, only
in the case of specific grids under discussion (Eqnarray, AMS...). Thus,
defaultColAlign() can still make sense in the future for grids that rely
on stored alignment and spacing, and I do not see what makes it useful
to remove it entirely.


OK, I see. My argument for removing defaultColAlign() was that we do not
want to have dead code, but I overlooked that it is still used in the base
class, so the only thing which could be removed is the "virtual" keyword
(but I don't have a strong opinion on that).


About "defaultColAlign() is not only used for display": you mean that it
is risky to change the behaviour of stored values. Let us admit that
there is still a risk despite all my checks. Then, I proposed to keep
the default values to be extra safe just above your remark which makes
me think that you may have missed it.


I believe that I understood the intention of your patch. However, I found
surprising behaviour in mathed in the past, and the motivation for my
comments was to ensure that you do not trap into this pitfall as well.


(But in any case these stored values are necessarily wrong since they
are not saved to the file for the environments under consideration. I am
highly sceptical that a bug could remain open for so long if it caused
more than a display bug to which users got accustomed.)


There are some hidden parts of mathed which have no user interface. I would
not bet that these settings are not written under any circumstances (but I
agree that a bug in the usual cases would have been found earlier, so we can
assume they work).


Again this misses the point. There is nothing to "repair" about
defaultColSpace(). If there is still any buggy behaviour regarding the
spacing or alignment then they should be changed to read the computed
values that I introduce. Same remark about keeping defaultColSpace in
order to be extra safe.


I am sorry, you are right, I was not careful anymore at the end of the
message.


If anything, please continue! Also, this is a software that many people
(including me) depend on professionally, so I do not understand this
notion that developing LyX is supposed to be "Spaß".


Well, in total it is supposed to make fun (at least for me, otherwise I
would stop contributing).


See the attached for two "safe" (and easy to read) patches, if you agree
that a safe patch that we have been discussing for a month can still get
in for 2.2.


I started to review the patch, but stopped when I found a difference between
the old and new behaviour of InsetMathHull::defaultColAlign() for
hullRegexp, since I don't have so much time at the moment. Again, this
combination is most likely not used, but "most likely" is not enough IMHO
for a beta.

Why is it so important to fix this bug before 2.2.0 when it is known for so
many years already? BTW, it did annoy me a lot when I wrote my thesis
(therefore my attempt to fix it many vears ago), but since I did not find a
proper solution at that time I simply got used to the wrong display (which
was not too difficult).

If you were proposing to fix the bug at the beginning of the 2.3 development
cycle then we could skip most parts of this discussion and you could simply
submit it. As I understand it, we do all agree that the proposed change is
good, the only differences are in judging the risk.





As you have noticed, this hull is constrained to a single cell. It
gets right-aligned because the commit that added hullRegexp after
hullAlign in the HullType enum did not change anything to
defaultColAlign() which reads:
if (type_ >= hullAlign)
return "rl"[col & 1];
This hull is only ever used in the Advanced Search & Replace panel. It
is not used for output and not meant to appear in a lyx file (in fact if
you try to save it in a file using copy/paste, then the parsing on
opening is broken, in a way that makes me confident that it has never
been used in a lyx document). So it is not about the alignment being
"most likely" not used. It is about the fact that this hull serves a
limited purpose that obviously has nothing to do with this
right-alignment (and that can be tested in a straightforward manner).

However, if you do not have the time, this is a sufficient reason by
itself. I am not forcing you to read these patches, and you do not need
an excuse.

I am confident in the two patches and I will wait and see if somebody
else is ready to vouch for it.



Also, I find that the fact that the issue matters and that the patch is
straightforward and risk-free have been good enough reasons to solve it
at this stage.

Maybe one more thing we are in disagreement about is your implication
that this is a secondary issue just because you (and other people)
"simply got used to the wrong display". Cu

Re: User pref parameters

[Guillaume Munch]

Le 12/01/2016 02:23, Pavel Sanda a écrit :

Guillaume Munch wrote:

I understand this idea of "freezing" the setting, in order to set a
custom value on opening. The current approach I have in mind is to read
and save to a per-user-per-document (cursor-location-like) setting when
save_user_preferences is false, so that the value on opening corresponds
to the user's previous session. The two approaches are in conflict, so
one has to choose between the two.


Yep, that's basically the same conflict which started the whole issue
("choosing a setting for everybody else"). You know my opinion about the
issue, but since you are the one who implements it and there is indeed
partial overlap with "\save_user_preferences true" go ahead :)

Cosmetic thing - the naming "save_user_preferences" is confusing precisely
because there are diverging opinions what user vs document pref is
so maybe using for file format something like vcs_simplify_format
or similar would be better.




Thanks.

I am not convinced by the naming vcs_simplify_format but maybe there are
other suggestions? What about save_transient_properties or save_state ?
I would rather avoid a name that refers to a particular purpose rather
than the actual effect.


Scott, do you sum up all these messages as a "+1", as you say?

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 12/01/2016 01:42, Pavel Sanda a écrit :

Guillaume Munch wrote:

Actually yes I am documenting a new rule, but it isn't mine. The new
rule requires a LFUN format increment and a LyX format increment


Do you have by chance link to LFUN format increment discussion at hand?
(I have no clue what is meant by LFUN format number). P



I think it started on the list but moved over to
http://www.lyx.org/trac/ticket/9794 during the ML shortage.

The LFUN format number is found in LyXAction.cpp and
prefs2prefs_lfuns.py, and is used for bind and ui files.


Here's the new text in Development.lyx:

“A change to the functionality of existing LFUNs can require a 
conversion of .bind and .ui files, and therefore an increment of the 
LFUN format, as well as a conversion of Info insets in .lyx files for 
manuals. The latter cannot be done automatically and requires also a LyX 
format increase (think of e.g. someone who might have made a set of LyX 
teaching manuals for use in their own 
group)[http://www.lyx.org/trac/ticket/9794].


1. Increment the LFUN file format number in src/LyXAction.h.

2. Implement the LFUN conversion in lib/scripts/prefs2prefs_lfuns.py

3. See step [enu:updatefiles] in section [subsec:update_lyx_files] but 
instead of the updatedocs.py command, use this command: bash 
development/tools/updatelfuns.sh.


4. Update Info insets in .lyx files. To do so, increment the LyX format 
and proceed as in [subsec:update_lyx_files], steps 
[enu:Describe_format]-[enu:updatefiles]. In the lyx2lyx implementation 
([enu:Add-an-entry]th step), implement a conversion similar to the one 
in prefs2prefs_lfuns.py above, as well as a corresponding reversion; for 
this one can use convert_info_insets from lib/lyx2lyx/lyx2lyx_tools.py.”

Re: beta release

[Guillaume Munch]

Le 12/01/2016 00:30, Scott Kostyshak a écrit :

On Mon, Jan 11, 2016 at 06:28:02PM +, Guillaume Munch wrote:

Le 09/01/2016 00:15, Scott Kostyshak a écrit :


Does any one view an issue as a beta blocker?


The situation with the parbreak separator is not good and I would see
changing its symbol and fixing the insertion of an empty environment
before with Enter (described at the beginning of
<http://mid.gmane.org/n6v646$kuu$1...@ger.gmane.org>) as blocker for 2.2;
thus it would be good if it is fixed for beta.

Fortunately Enrico has already addressed a few issues and the fix for
empty environment insertion should be easy. In addition, there have been
suggestions for replacing the parbreak symbol. If anybody has an opinion
on the symbol do not hesitate to share it.


I looked at the thread (actually it timed out for me but I could search
the MID and found it on mail-archive here [1]). From what I see, there
is no response to that message. In any case, can you make a trac ticket?
This would help me because with a trac ticket I can know (1) exactly
what is the bug (2) when it is determined to be "solved" (because it
will be marked as fixedinmaster or fixed) and (3) it will be easier for
me to keep track of as a beta blocker because I review all of the issues
with a 2.2 milestone tag before releasing.

Can anyone +1 this issue as a beta blocker? I did not follow the
discussion closely.



I think this should be done before release. Does it mean that I have to 
make it a beta blocker?


I just posted the message on Sunday. I will open a bug report shortly 
but will first wait a bit for an reply from Enrico (this already helped 
reduce the number of bugs to report on the tracker).


Also, what is this timeout issue? Some people do not get new messages 
sent to old threads?

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 11/01/2016 20:30, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


What is BTW the reason why you skip recordUndo in these cases?


My understanding is that these changes do not modify the document if
store_user_prefs is false, and therefore nothing can be undone.




Yes. BTW this corresponds to tested behaviour because there was no 
recordUndo until the recent patch by Richard.

Re: User pref parameters

[Guillaume Munch]

Le 11/01/2016 10:14, Jean-Marc Lasgouttes a écrit :

Le 11/01/2016 11:07, Pavel Sanda a écrit :

Kornel Benko wrote:

This all is getting more and more confusing. Too complicated (at
least for me)


You edit document.
You decide to use git.
You set up the look/behaviour things your care about ('Is CT ON/OFF')
You freeze those settings so working with git is less annoying.


This is an issue I had too. Freezing settings seems more interesting
that setting them to false. It is more work too, maybe too much work
actually.




Dear Pavel and Jean-Marc,


I understand this idea of "freezing" the setting, in order to set a
custom value on opening. The current approach I have in mind is to read
and save to a per-user-per-document (cursor-location-like) setting when
save_user_preferences is false, so that the value on opening corresponds
to the user's previous session. The two approaches are in conflict, so
one has to choose between the two.

I see several drawbacks to "freezing":

* With "freezing", the user must know what settings are going to be
affected. This means a heavier description in the user interface, and a
feature less easy to understand.

* This is only relevant for scenarios where we want the same setting on
opening for all collaborators (or where one user
knows-better-than-everybody-else). As soon as there is no agreement, we
are back to the situation that we were trying to solve.

* The use-case of "choosing a setting for everybody else" overlaps with
the current behaviour provided by "\save_user_preferences true".

* On the other hand, it does not address the need for having the
settings entirely independent between collaborators.

Thus the per-user approach encompasses a wider set of use-cases,
overlaps less with the current behaviour, and is simpler to explain and
understand. Moreover, storing always the same value "false" is similar
to what is done in LibreOffice's corresponding feature (saving to the
.fodt format).


Guillaume

Re: beta release

[Guillaume Munch]

Le 09/01/2016 00:15, Scott Kostyshak a écrit :


Does any one view an issue as a beta blocker?


The situation with the parbreak separator is not good and I would see
changing its symbol and fixing the insertion of an empty environment
before with Enter (described at the beginning of
) as blocker for 2.2;
thus it would be good if it is fixed for beta.

Fortunately Enrico has already addressed a few issues and the fix for
empty environment insertion should be easy. In addition, there have been
suggestions for replacing the parbreak symbol. If anybody has an opinion
on the symbol do not hesitate to share it.


Guillaume

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 08/01/2016 22:26, Scott Kostyshak a écrit :

On Fri, Jan 08, 2016 at 11:06:04PM +0100, Georg Baum wrote:

Guillaume Munch wrote:



Also, because it took me a while to
figure out where the bind and ui format was defined. Nothing was
documented. (Is there a maintainer for Development.lyx who will validate
the CT'd changes?)


There is no maintainer for Development.lyx. Because of that and since it is
not supposed to be translated you don't need CT for this document IMHO.


+1. If you are just documenting something, go ahead. If you are
proposing a rule that LyX developers should follow, then this should be
discussed on the list but once there is agreement just commit (as Georg
says, no CT needed).



Actually yes I am documenting a new rule, but it isn't mine. The new
rule requires a LFUN format increment and a LyX format increment
whenever a change to LFUNs requires a prefs2prefs_lfun update.

The reason for the LyX format increment is that updating Info insets by
hand in lib/doc is not enough, because it fails to take into account all
the LyX enthusiasts around the world who may have written their own LyX
documentation for their groups. So we rely on lyx2lyx for the conversion
and we duplicate code from prefs2prefs.

In particular, an increment to the LFUN format requires an increment to
the LyX format. There is an agreement from Georg, Jean-Marc and Richard;
and I did not see any opposition to this rule during the discussion of
this requirement for my patch.


Guillaume

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 06/01/2016 20:51, Georg Baum a écrit :

Guillaume Munch wrote:


Le 03/01/2016 11:04, Georg Baum a écrit :


Really? The amount of code changes is big, and I cannot see from the
patch that it has no influence on the .tex input/output or mathml/xhtml
output. If it can not be 100% guaranteed that only the display is changed
then it is too dangerous IMHO. If only the display is changed then it
would be OK (but only because the current display is quite broken,
otherwise it would be too dangerous as well IMHO).



When you say "the patch", which one of the three are you discussing?


All.


The first one is just refactoring and you should be able to check
function by function that it does not change the meaning (apart from the
addition of the isMutable() check). Of course, I would be happier if it
was not necessary to do this sort of clean-up before working on the code.


The first one is more than refactoring. The behaviour of
InsetMathHull::display(), InsetMathHull::numberedType() and
InsetMathHull::currentMode() changed. currentMode() is used for parsing, so
I would not change it between alpha and beta. Did you find a bug with the
old behavior, or did you change it for theoretical reasons?

Also, the embedded whitespace and return value changes (as in
InsetMathHull::standardFont()) make it more difficult to verify whether the
introduction of hullUnknown was really purely mechanical. BTW, the explicit
cases in InsetMathHull::ams() were done on purpose, so that the compiler
forces us to think whether any ney type that is introduced in the future is
an AMS type or not.



You are right, I forgot that these small changes were not
straightforward. I have now made a corrected version, but I decided to
put this first patch aside for now since it is long and not essential.





For the other two, I was wondering about mathml/xhtml until I realized
that alignment is not implemented at all (I checked by reading the code
too). But, to be extra safe, I can reintroduce the default align and
spacing values to be extra sure that nothing else changes apart from the
display.


The second patch looks incomplete to me: It removes two defaultColAlign()
methods, but not the virtual one in the base class. Since defaultColAlign()
is not only used for display I don't think such a change should go in right
now.



I think that these comments miss the point of the patches. The logic of
storing the values is that inserting or deleting columns is going to
shift the values appropriately by one column. This is not the logic of
the environments under discussion, whose alignment and spacing only
depend on the column number, not the history of how the columns have
been introduced.

I replace stored alignment and spacing values with computed values, only
in the case of specific grids under discussion (Eqnarray, AMS...). Thus,
defaultColAlign() can still make sense in the future for grids that rely
on stored alignment and spacing, and I do not see what makes it useful
to remove it entirely.

About "defaultColAlign() is not only used for display": you mean that it
is risky to change the behaviour of stored values. Let us admit that
there is still a risk despite all my checks. Then, I proposed to keep
the default values to be extra safe just above your remark which makes 
me think that you may have missed it.


(But in any case these stored values are necessarily wrong since they
are not saved to the file for the environments under consideration. I am
highly sceptical that a bug could remain open for so long if it caused
more than a display bug to which users got accustomed.)




defaultColSpace() is used when creating new columns or resetting existing
ones to the default. If it does not work then it should be repaired and not
removed as in the third patch.



Again this misses the point. There is nothing to "repair" about
defaultColSpace(). If there is still any buggy behaviour regarding the
spacing or alignment then they should be changed to read the computed
values that I introduce. Same remark about keeping defaultColSpace in
order to be extra safe.





I apologize for being such a nitpicker and "Spaßbremse",



If anything, please continue! Also, this is a software that many people
(including me) depend on professionally, so I do not understand this
notion that developing LyX is supposed to be "Spaß".



but if you ever
fixed a minor bug that caused a major regression that was only noticed after
release, and felt the embarrassement when investigating a bug report and
discovering the reason of the regression, you hopefully understand that.



I am sorry about that.


Also, we should be aware that any change we are doing right now throws away
testing effort of the alpha testers. This is fine for obvious local bug
fixes, but critical for more fundamental changes.



I am aware of this! The reason for doing these quick patches
about a month ago was that they only change the display in a

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 20/12/2015 17:31, Enrico Forestieri a écrit :


Do you mean that you expect the parbreak separator to be used often on
purpose, instead of a plain separator, not just as the result of a
conversion 2.1 -> 2.2 ?


It is annoying repeating again all discussions made at the time those
insets were introduced, but let's do it. There was consensus that the
--Separator-- layout should have been dropped and something else adopted
in its place. The output should have not changed. So, as the Separator
layout was introducing a blank line after itself, the new inset come in two
versions, one not introducing a blank line and the other one introducing
it. In this way, using the parbreak separator as the default one, I was
hoping to avoid complaints. There is no provision for introducing this
separator from the gui and it should be introduced only when needed. It is
only introduced when pressing Enter at the beginning of a Standard layout
immediately following a non-standard one. In this way, it allows to
reintroduce the same environment in an intuitive way and exactly mimics
the behavior of the old Separator layout. If this is not deemed important,
then letting always introduce the plain separator is very simple. However,
when converting old documents, the parbreak separator should be used in
place of the Separator layout. So, I think that it might be more confusing
using two different versions for the same purpose.


Maybe I just fail to see its purpose and in particular why it is more
important than the plain separator.


It is not more important. I hope the above helps clarifying it.


This symbol is essentially representing a latex blank
line and I find its actual shape the best way to convey this concept. For
example, this is how a blank line would be represented in a word processor
when you ask to also show non-printable characters.


This makes no sense to me. In a word processor this symbol would
represent a new line in the final output, and this corresponds to the
new line inset in LyX.


And a newline symbol all alone on the line represents a blank line.


What about a shortened plain separator lowered to the baseline with a
small bar on the end, in other words:
* A bottom right corner ⌟ but elongated (notice that this is Unicode 1.1
and could therefore be used directly, but misses the "elongated" part)
* Something similar to the caracters ⨼ or ⏗ but lowered to the baseline
(and bigger)
* What we have now, without the arrow head, thicker, and down to the
baseline.

Attached is a mock-up using the ⌟ character (what I am actually thinking
of is a bit wider to remind of the plain separator). (Notice that it
would be nice as well to hide the paragraph mark when appropriate.)


This is already used for denoting a parbreak in change tracking and would
not be similar but exactly the same symbol. Moreover, I don't like it at
all. What about using a left-right arrow? For example ↔.



But you just said that the reason for having a "non-obtrusive" symbol
instead of a horizontal line was that it was going to be used at the end
of certain lines, and now you are telling me that the only way to
introduce it is to have it alone on a line?


See explanation above. The same inset is also used to artificially
introduce a blank line where old LyX versions were doing it.


What about:
* Shift+Enter: plain separator (and restart the environment)
* Alt+M P : parbreak separator

?


Please, you are free to start your fight for this change but I will not
follow. Generally, when I am not satisfied with a default preference
setting I simply change it. This is less stressing and easier than to deal
with long and unfruitful discussions.


But, if there was only one thing to fix before 2.2, it would be the symbol!


Certainly!




Dear Enrico,


Thank you for the recent patches that took into account some of my remarks.

I have been using master a lot recently and I noticed another issue
which annoyed me: In 2.1, the behaviour when typing Enter at the
beginning of a paragraph is consistently to start a new paragraph before
it. In 2.2, the behaviour changes and sometimes it introduces a parbreak
separator instead, after a non-standard paragraph. The behaviour is now
inconsistent. I think that the introduction of a parbreak separator
after a non-standard paragraph should only happen on an empty paragraph.
This does not change the amount of Enter required to introduce a
separator from a non-standard paragraph, but restores the consistency of
introducing a new paragraph with Enter at the start of a paragraph.


Also, I wanted to say that given that I did not follow the original
conversations, I have more of a user's view on this, so I do not think
that my comments are redundant. Users, new users, now, and in two years,
are not going to care about historic reasons for such interface choices...

For the symbol itself, my suggestion was a very elongated version of ⌟,
meant to recall the plain separator inset. But, a character that
would 

Re: [PATCH] compilation fix for libc++ in C++11 mode

[Guillaume Munch]

Le 10/01/2016 20:42, Jean-Marc Lasgouttes a écrit :

Le 08/01/16 22:50, Guillaume Munch a écrit :

I tried to look it up. It might work right now but I think we should
get rid of this subclassing entirely. It is just used for
forward-declaration and defining helper functions. I have a bad feeling
about starting to define custom constructors for STL containers
explicitly. The helper functions should not be there in the first place
and instead of forward-declaring we can just typedef Toc in a new header
file Toc.h. Anyway TocBackend.h has too many classes. I would say that
the attached patch is the proper solution, if you are willing to have a
look. This should be done independently of whether there is a bug in
clang.


Dear Guillaume,

Isn't this something we can keep for 2.3? I see no urgency for such
rewrite right now...




Dear Jean-Marc,


Since you have gotten a +1 from somebody else, sure. I was not so sure
myself, so I wanted to offer an alternative that was sure to be safe. I
think this will have to be done nevertheless, so I am going to keep it
for later.


Guillaume

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 10/01/2016 19:08, Georg Baum a écrit :
>

I looked at the patches in http://www.lyx.org/trac/ticket/9841, and I think
it is a good implementation of the consensus that has been reached earlier.
You have a +1 from me, but because this has been discussed with some strong
opinions I suggest that there should be more reviews.


Ok thanks, I will wait for more "+1".

To make it clear, do we agree that the meaning of 
"\store_user_preferences" is meant to grow over time if we stumble upon 
similar scenarios? This means that for people have chosen to set 
\store_user_preferences to false, the storage of certain preferences 
might be moved to a per-user-per-document preference between releases.




You don't need to do anything in tex2lyx besides writing the new parameter
with a default value as you did in the patch.


I mean it for the tests, as I have no familiarity with the latter.

Re: [PATCH] compilation fix for libc++ in C++11 mode

[Guillaume Munch]

Le 10/01/2016 21:26, Jean-Marc Lasgouttes a écrit :

Le 10/01/16 22:17, Guillaume Munch a écrit :

Since you have gotten a +1 from somebody else, sure. I was not so sure
myself, so I wanted to offer an alternative that was sure to be safe. I
think this will have to be done nevertheless, so I am going to keep it
for later.


Indeed Georg's comment looks like a bona fide +1.

I agree though that the refactoring is needed, although I am not sure
why you prefer to create a new Toc.h header. Actually the merging of
headers was done at the time to speed up compilation, I think.



I imagine that Toc and other classes are being forward-declared in some
headers probably for the same speed reason. Toc.h is there to provide an
alternative to the forward declarations without sacrificing speed (or
maybe my Toc.h already includes too much?). But I'd be happy to learn
about any reasons behind the current header organisation.

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 10/01/2016 21:11, Jean-Marc Lasgouttes a écrit :

Le 08/01/16 23:05, Guillaume Munch a écrit :

I agree that the current situation regarding \output_change and
\tracking_change is bad and should be fixed. I gave what I think is the
proper solution, taking into account the debate that was on the list.
The patch is very simple (see the earlier message:
http://article.gmane.org/gmane.editors.lyx.devel/159493 and:
http://www.lyx.org/trac/ticket/9841). Now what we would need for such a
change is if developers who took part in the discussion looked and say:
yes, this is the proper solution. I do not see this happening right now.
Then, what is a proper solution? You want a file format increase +
lyx2lyx + tex2lyx changes? I am more familiar with format increase now
so it's easier for me, although: 1) please not while I have another
format change pending because these things do not rebase very well, and
2) I will need help for tex2lyx. Another solution is to revert as I have
suggested.


Some questions on the second patch:
1/ can OUTPUT_CHANGES be toggled for a read-only document if user prefs
are not stored?


No. Currently one cannot enable "output changes" on a
read-only document (on 2.1.5dev). If you think that this is a bug, then
it is separate from what is being achieved with the patch. I do not
think that store_user_prefs should be have anything to do with the
possibility of enabling output_changes on a read-only document.



2/ when prefs are not stored, they are replaced by "false". Will this
always make sense to users? This is just a question that popped up in my
head, since we say "do not store" but something is actually stored.
It might just be a matter of wording of the option, actually.



For the two settings under consideration this makes sense, however the
long-term idea is to store as a per-user-per-document setting, local to
the machine (like the cursor location on opening). Hence the phrasing
"do not store *to file*".

I had a look at the implementation of per-user-per-document settings and
it has to be enhanced before being used in this manner, so for the
moment we still read the value from the lyx file.


Guillaume

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 08/01/2016 08:01, Guillaume Munch a écrit :


Ok, this is what I did.




The last patch contains a minor rephrasing that I did not try to compile
before showing it to you, because it was straightforward and unrelated
to anything we had discussed (isTable is now defined as a whitelist and
not as a blacklist for future-proofness). There was a typo, and the
correct patch is attached. I should have checked the final compilation
before sending it.


Guillaume
>From 7b9cacecbcc31c428b77d5bd9a5c0f5da40877bb Mon Sep 17 00:00:00 2001
From: Guillaume Munch <g...@lyx.org>
Date: Fri, 11 Dec 2015 20:45:57 +
Subject: [PATCH 9/9] Let tabular-feature commands fall through non-table math
 insets. (#4189)

---
 src/mathed/InsetMathHull.cpp | 37 +++--
 src/mathed/InsetMathHull.h   |  2 ++
 2 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 5b884b4..f6c1e00 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -1040,6 +1040,24 @@ void InsetMathHull::footer_write(WriteStream & os) const
 }
 
 
+bool InsetMathHull::isTable() const
+{
+	switch (type_) {
+	case hullEqnArray:
+	case hullAlign:
+	case hullAlignAt:
+	case hullXAlignAt:
+	case hullXXAlignAt:
+	case hullFlAlign:
+	case hullMultline:
+	case hullGather:
+		return true;
+	default:
+		return false;
+	}
+}
+
+
 bool InsetMathHull::rowChangeOK() const
 {
 	return
@@ -1702,6 +1720,13 @@ void InsetMathHull::doDispatch(Cursor & cur, FuncRequest & cmd)
 		break;
 	}
 
+	case LFUN_TABULAR_FEATURE:
+		if (!isTable())
+			cur.undispatched();
+		else
+			InsetMathGrid::doDispatch(cur, cmd);
+		break;
+
 	default:
 		InsetMathGrid::doDispatch(cur, cmd);
 		break;
@@ -1817,6 +1842,8 @@ bool InsetMathHull::getStatus(Cursor & cur, FuncRequest const & cmd,
 		return InsetMathGrid::getStatus(cur, cmd, status);
 
 	case LFUN_TABULAR_FEATURE: {
+		if (!isTable())
+			return false;
 		string s = cmd.getArg(0);
 		if (!rowChangeOK()
 		&& (s == "append-row"
@@ -1838,16 +1865,6 @@ bool InsetMathHull::getStatus(Cursor & cur, FuncRequest const & cmd,
 			status.setEnabled(false);
 			return true;
 		}
-		if ((type_ == hullSimple
-		  || type_ == hullEquation
-		  || type_ == hullNone) &&
-		(s == "add-hline-above" || s == "add-hline-below")) {
-			status.message(bformat(
-from_utf8(N_("Can't add horizontal grid lines in '%1$s'")),
-hullName(type_)));
-			status.setEnabled(false);
-			return true;
-		}
 		if (s == "add-vline-left" || s == "add-vline-right") {
 			status.message(bformat(
 from_utf8(N_("Can't add vertical grid lines in '%1$s'")),
diff --git a/src/mathed/InsetMathHull.h b/src/mathed/InsetMathHull.h
index 9598ad4..e02c619 100644
--- a/src/mathed/InsetMathHull.h
+++ b/src/mathed/InsetMathHull.h
@@ -236,6 +236,8 @@ private:
 	ColorCode standardColor() const;
 	/// consistency check
 	void check() const;
+	/// does it understand tabular-feature commands?
+	bool isTable() const;
 	/// can this change its number of rows?
 	bool rowChangeOK() const;
 	/// can this change its number of cols?
-- 
2.1.4

Re: [PATCH] compilation fix for libc++ in C++11 mode

[Guillaume Munch]

Le 08/01/2016 08:59, Jean-Marc Lasgouttes a écrit :

The following patch fixes compilation for me with clang and libc++ (with
autotools I set CXX="clang++ --stdlib=libc++").

This is a workaround to https://llvm.org/bugs/show_bug.cgi?id=24137
to be fixed in 3.7.1 or 3.8.0.

Can someone confirm that adding the default constructor like that is
harmless?




I tried to look it up. It might work right now but I think we should
get rid of this subclassing entirely. It is just used for
forward-declaration and defining helper functions. I have a bad feeling
about starting to define custom constructors for STL containers
explicitly. The helper functions should not be there in the first place
and instead of forward-declaring we can just typedef Toc in a new header
file Toc.h. Anyway TocBackend.h has too many classes. I would say that
the attached patch is the proper solution, if you are willing to have a
look. This should be done independently of whether there is a bug in clang.


Guillaume
>From aeaf633f7449f6fa44b0d7c0aa9b1d542be276e8 Mon Sep 17 00:00:00 2001
From: Guillaume Munch <g...@lyx.org>
Date: Fri, 8 Jan 2016 19:06:50 +
Subject: [PATCH] Simplify class structure in TocBackend

Deriving from std::vector to provide helper functions appears a touch
excessive. Use typedef instead and move helper functions to the base class. New
header Toc.h provided to replace forward-declarations.

Remove TocIterator which is useless.

Factor code with the recent method DocIterator::getInnerText(). Small correction
in the latter to check for emptiness.
---
 src/Buffer.cpp |  4 ++--
 src/BufferView.cpp |  4 ++--
 src/Changes.cpp|  2 +-
 src/DocIterator.cpp|  2 +-
 src/Makefile.am|  1 +
 src/Paragraph.h|  1 -
 src/Toc.h  | 42 ++
 src/TocBackend.cpp | 36 +++-
 src/TocBackend.h   | 40 
 src/frontends/qt4/TocModel.cpp |  3 ++-
 src/frontends/qt4/TocModel.h   |  4 ++--
 src/insets/InsetTOC.h  |  3 ++-
 12 files changed, 78 insertions(+), 64 deletions(-)
 create mode 100644 src/Toc.h

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 115a542..aae1e43 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2226,8 +2226,8 @@ void Buffer::getLabelList(vector & list) const
 
 	list.clear();
 	shared_ptr toc = d->toc_backend.toc("label");
-	TocIterator toc_it = toc->begin();
-	TocIterator end = toc->end();
+	Toc::const_iterator toc_it = toc->begin();
+	Toc::const_iterator end = toc->end();
 	for (; toc_it != end; ++toc_it) {
 		if (toc_it->depth() == 0)
 			list.push_back(toc_it->str());
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 7332ec5..b0801bf 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -2397,8 +2397,8 @@ void BufferView::gotoLabel(docstring const & label)
 
 		// find label
 		shared_ptr toc = buf->tocBackend().toc("label");
-		TocIterator toc_it = toc->begin();
-		TocIterator end = toc->end();
+		Toc::const_iterator toc_it = toc->begin();
+		Toc::const_iterator end = toc->end();
 		for (; toc_it != end; ++toc_it) {
 			if (label == toc_it->str()) {
 lyx::dispatch(toc_it->action());
diff --git a/src/Changes.cpp b/src/Changes.cpp
index 832ccac..9fa46f9 100644
--- a/src/Changes.cpp
+++ b/src/Changes.cpp
@@ -501,7 +501,7 @@ void Changes::addToToc(DocIterator const & cdit, Buffer const & buffer,
 			// ¶ U+00B6 PILCROW SIGN
 			str.push_back(0xb6);
 		docstring const & author = author_list.get(it->change.author).name();
-		Toc::iterator it = change_list->item(0, author);
+		Toc::iterator it = TocBackend::findItem(*change_list, 0, author);
 		if (it == change_list->end()) {
 			change_list->push_back(TocItem(dit, 0, author, true));
 			change_list->push_back(TocItem(dit, 1, str, output_active,
diff --git a/src/DocIterator.cpp b/src/DocIterator.cpp
index a059ad1..2ef8ddd 100644
--- a/src/DocIterator.cpp
+++ b/src/DocIterator.cpp
@@ -229,7 +229,7 @@ CursorSlice const & DocIterator::innerTextSlice() const
 DocIterator DocIterator::getInnerText() const
 {
 	DocIterator texted = *this;
-	while (!texted.inTexted()) 
+	while (texted.inMathed()) 
 		texted.pop_back();
 	return texted;
 }
diff --git a/src/Makefile.am b/src/Makefile.am
index 9446d17..098c70d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -289,6 +289,7 @@ HEADERFILESCORE = \
 	Text.h \
 	TextClass.h \
 	TextMetrics.h \
+	Toc.h \
 	TocBackend.h \
 	Trans.h \
 	Undo.h \
diff --git a/src/Paragraph.h b/src/Paragraph.h
index d0ed94b..73de6c1 100644
--- a/src/Paragraph.h
+++ b/src/Paragraph.h
@@ -49,7 +49,6 @@ class MetricsInfo;
 class OutputParams;
 class PainterInfo;
 class ParagraphParameters;
-class Toc;
 class WordLangTuple;
 class XHTMLStream;
 class otexstream;
di

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 06/01/2016 20:51, Georg Baum a écrit :


BTW, a proper solution for 9841 is much more important than these alignment
issues IMHO. The current situation is worse than before dc016de34ea.




I agree that the current situation regarding \output_change and 
\tracking_change is bad and should be fixed. I gave what I think is the 
proper solution, taking into account the debate that was on the list. 
The patch is very simple (see the earlier message: 
http://article.gmane.org/gmane.editors.lyx.devel/159493 and: 
http://www.lyx.org/trac/ticket/9841). Now what we would need for such a 
change is if developers who took part in the discussion looked and say: 
yes, this is the proper solution. I do not see this happening right now. 
Then, what is a proper solution? You want a file format increase + 
lyx2lyx + tex2lyx changes? I am more familiar with format increase now 
so it's easier for me, although: 1) please not while I have another 
format change pending because these things do not rebase very well, and 
2) I will need help for tex2lyx. Another solution is to revert as I have 
suggested.



Guillaume

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 08/01/2016 22:06, Georg Baum a écrit :


It cannot see anything wrong.

There is no maintainer for Development.lyx. Because of that and since it is
not supposed to be translated you don't need CT for this document IMHO.


Ok



Looks good (lyx2lyx and prefs2prefs, I did not follow the original
discussion, so don't comment on the main changes).



Thank you, waiting for Jean-Marc's opinion then.


Guillaume

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 08/01/2016 21:47, Georg Baum a écrit :

Is there a reason why the scripts do not have exec permissions?


I guess it is lazyness.





I would not spend any time in non-python scripts, but convert them to python
if problems occur.




So I can chmod +x all the scripts?


Guillaume

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 07/01/2016 22:09, Guillaume Munch a écrit :

Le 03/01/2016 09:46, Georg Baum a écrit :

We have a script for updating the docs, examples and templates
(development/tools/updatedocs.py), and one for updating the ui and bind
files (development/tools/updatelfuns.sh). Or did you man something else?



Is there a reason why the scripts do not have exec permissions? I
initially ran "sh updatelfuns.sh" and this failed, emptying a dozen of
files. After the second try I found that it requires bash, which would
have been chosen automatically if it had been possible to run
./updatelfuns.sh directly.



It is even more serious than I thought, because running it with sh has:
* copied every single file in the repository directory (including
untracked files) to file.old
* emptied hundreds of files (including untracked files)

Having to undo this is going to be a bit annoying but it could have been
worse. Thank you Richard for doing backups without even expecting that
this was going to happen :)

I do not wish to spend time finding out what exactly went wrong (if
someone wants to find out, my sh is Ubuntu's default which is dash) but
I suggest to add a check at the start of the script as per the attached
patch.

Is there any other script where I should add this check?


Guillaume
diff --git a/development/tools/updatelfuns.sh b/development/tools/updatelfuns.sh
index 04c8c02..f771328 100644
--- a/development/tools/updatelfuns.sh
+++ b/development/tools/updatelfuns.sh
@@ -1,5 +1,10 @@
 #!/bin/bash
 
+if [ -z "$BASH_VERSION" ]; then
+	echo "You must use bash to run this script";
+	exit 1;
+fi
+
 function do_convert {
 	for i in *; do 
 		if [ ! -f $i ]; then continue; fi

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 03/01/2016 09:46, Georg Baum a écrit :

We have a script for updating the docs, examples and templates
(development/tools/updatedocs.py), and one for updating the ui and bind
files (development/tools/updatelfuns.sh). Or did you man something else?



Is there a reason why the scripts do not have exec permissions? I
initially ran "sh updatelfuns.sh" and this failed, emptying a dozen of
files. After the second try I found that it requires bash, which would
have been chosen automatically if it had been possible to run
./updatelfuns.sh directly.

Re: #9912: Assertion when selecting the whole document with mouse for the first time

[Guillaume Munch]

From :


Le 05/01/2016 10:18, LyX Ticket Tracker a écrit :

#9912: Assertion when selecting the whole document with mouse for the first time
-+-
  Reporter:  gadmm|   Owner:  lasgouttes
  Type:  defect   |  Status:  new
  Priority:  high |   Milestone:  2.1.5
Component:  general  | Version:  2.1.4
  Severity:  major|  Resolution:
  Keywords:  assertion patch  |
-+-
Changes (by lasgouttes):

  * cc: rgheck, skostysh (added)
  * keywords:  assertion => assertion patch
  * version:  2.2.0dev => 2.1.4
  * milestone:  2.2.0 => 2.1.5


Comment:

  This patch resets the anchor properly after resetting cursor at load time.

  Candidate to master and 2.1 branch.




Thanks. Unfortunately I just had a similar assertion in a condition 
unrelated to what this patch fixes:


#5  0x00c8c710 in lyx::doAssert (
expr=expr@entry=0xd09705 "anchor_.depth() >= depth()",
file=file@entry=0xd0958a "../../src/Cursor.cpp", line=line@entry=1052)
at ../../../src/support/lassert.cpp:53
#6  0x005410ed in lyx::Cursor::normalAnchor 
(this=this@entry=0x41c8548)

at ../../src/Cursor.cpp:1051
#7  0x005414ba in lyx::Cursor::setSelection (this=0x41c8548)
at ../../src/Cursor.cpp:1126
#8  0x0073612a in lyx::BufferView::mouseSetCursor (
this=this@entry=0x41c8420, cur=..., select=)
at ../../src/BufferView.cpp:2521
#9  0x006c1503 in lyx::Text::dispatch (this=this@entry=0x25eba58,
cur=..., cmd=...) at ../../src/Text3.cpp:1616
#10 0x009aca0c in lyx::InsetText::doDispatch (
this=this@entry=0x25eba40, cur=..., cmd=...)
at ../../src/insets/InsetText.cpp:312
#11 0x008b71ec in lyx::InsetCollapsable::doDispatch 
(this=0x25eba40,

cur=..., cmd=...) at ../../src/insets/InsetCollapsable.cpp:489
#12 0x0095add2 in lyx::InsetNote::doDispatch (this=0x25eba40, 
cur=...,

cmd=...) at ../../src/insets/InsetNote.cpp:179
#13 0x00887932 in lyx::Inset::dispatch (this=0x25eba40, cur=...,
cmd=...) at ../../src/insets/Inset.cpp:319
#14 0x0054433d in lyx::Cursor::dispatch (
this=this@entry=0x7fffc6a0, cmd0=...) at ../../src/Cursor.cpp:432
#15 0x0073d89a in lyx::BufferView::mouseEventDispatch 
(this=0x41c8420,

cmd0=...) at ../../src/BufferView.cpp:2224

I was selecting text and this was not a document that I had just opened 
nor did I just use a bookmark, so as I understand the patch would not 
have prevented the above. (From now on I will work on the latest master 
with the fix, to be sure.)


I also wanted to say that I am trying to catch a dataloss crash in 
master, where a blank emergency file is produced. I do not know if it is 
related to the issue above, but it is why I am currently working with 
gdb. This dataloss crash is unrelated to math macros, because there were 
no macros in the document at the time.



Guillaume

Re: #9794: inset-modify tabular commands are incorrectly disabled

[Guillaume Munch]

Le 03/01/2016 22:26, Richard Heck a écrit :

On 01/03/2016 02:25 PM, Guillaume Munch wrote:

Le 03/01/2016 09:46, Georg Baum a écrit :

Guillaume Munch wrote:


Regarding http://www.lyx.org/trac/ticket/9794, I had two questions
below
before making the requested changes:

Le 29/12/2015 00:27, LyX Ticket Tracker a écrit :

#9794: inset-modify tabular commands are incorrectly disabled
-+-
Reporter:  gadmm|   Owner:  lasgouttes
Type:  defect   |  Status:  new
Priority:  high |   Milestone:  2.2.0
Component:  general  | Version:  2.1.3
Severity:  normal   |  Resolution:
Keywords:  regression patch fileformat  |
-+-

Comment (by gadmm):

I now have some little more time again. Only the following
remains to
do:

Replying to [comment:17 lasgouttes]:
>  * increment lyx format and add some lyx2lyx code to update info
>  insets.

I need help for "some lyx2lyx code to update info insets", if you
really want to implement these higher standards. How do I do that?


If you post a description of the needed changes on the list then
somebody
will probably come up with a prototype lyx2lyx code that you can fine
tune.



I would like to know the proper way of applying prefs2prefs_lfun from
format 3 to format 4 in the arg line in the following:

\begin_inset Info
type "shortcut"
arg "inset-modify tabular append-column"
\end_inset

(in Shortcuts.lyx).


This is our own file. I'd just update it manually.


That's what I thought and had done in an earlier version of the patches
(as well as translations).


If you want to update
it programmatically,


I thought this was your and Jean-Marc's idea. My only interest in this
is making sure that things are done in the correct way.


then you need to use lyx2lyx for that, since we're
updating a LyX file. prefs2prefs* are used to update ui, bind, etc,
files.


Then I misunderstood the comment about incrementing the lyx format
version at the same time as the lfun format. I thought the point of your
and Jean-Marc's "new idea" was to use prefs2prefs automatically from now
on inside lyx2lyx to update the info inset.


If you do want to do it via lyx2lyx, then just give me a list of
conversions and I'll write the code. This kind of thing is easy once
you've done it a few times.


The Python code in prefs2prefs_lfuns.lyx is going to be

def conv_tabular_features(line):
	line = simple_renaming(line, "inset-modify tabular from-dialog", 
"inset-modify tabular")

return simple_renaming(line, "inset-modify tabular", "tabular-feature")


If we allow ourselves to duplicate the code then I expect it to be easy
indeed, but I welcome your input if you give me the equivalent code
using the functions in lyx2lyx.




We can also change it for type="icon", which will affect many more
manuals as well, though this is superfluous given that the renaming hack
that was there before is still there. Maybe we should only bother
doing it if we decide to get rid of the renaming hack at some point.


Just let me know which you want. Easy both ways.


Let's not fix what is not broken, if people agree in this case. This
conversion can be done later by whoever gets rid of the icon name
conversion hack. Or I could use this occasion to get rid of the hack 
entirely. Easy both ways :)




Guillaume

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 03/01/2016 11:04, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


Le 01/01/16 18:57, Guillaume Munch a écrit :

Dear list,

Here's the latest version of the patch after discussion during the ML
shortage here: http://www.lyx.org/trac/ticket/9908. As I explained
there, this only affects the display. Jean-Marc, was your comment an
encouragement to push?


Yes , sort of. I cannot tell that it really works, but if it does not,
it would not be too dangerous :)


Really? The amount of code changes is big, and I cannot see from the patch
that it has no influence on the .tex input/output or mathml/xhtml output. If
it can not be 100% guaranteed that only the display is changed then it is
too dangerous IMHO. If only the display is changed then it would be OK (but
only because the current display is quite broken, otherwise it would be too
dangerous as well IMHO).



When you say "the patch", which one of the three are you discussing?

The first one is just refactoring and you should be able to check
function by function that it does not change the meaning (apart from the
addition of the isMutable() check). Of course, I would be happier if it
was not necessary to do this sort of clean-up before working on the code.

For the other two, I was wondering about mathml/xhtml until I realized
that alignment is not implemented at all (I checked by reading the code
too). But, to be extra safe, I can reintroduce the default align and
spacing values to be extra sure that nothing else changes apart from the
display.


Guillaume