Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Pavel Sanda
Guillaume Munch wrote:
> What do you think?

I do not really have opinion about such change. P


Re: Master is slow

2016-10-18 Thread racoon

On 19.10.2016 07:08, racoon wrote:

On 19.10.2016 07:03, racoon wrote:

On 18.10.2016 21:44, Guillaume Munch wrote:

Le 15/10/2016 à 11:39, racoon a écrit :

Typing within the master's work area is slow on my computer (while
it is
fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging
running in the background or so?


A minimal working example to reproduce the slowness could help. You
can also try to profile your installation yourself with callgrind (you
will have to adapt for windows the instructions at
https://wiki.lyx.org/FAQ/FurtherHelp#profile)


It is really as simple as I wrote. I just create an empty document and
start typing quickly. LyX 2.2.2 can follow along, but the master starts
lagging behind.

Maybe there is something strange with debug going on? I am trying to
figure it out on the other branch of this threat.


By the way this did not start recently. I remember it being slow since I
first time compiled it a while ago.


I also noticed that my self-compiled LyX starts much slower. I guess 
this also points towards my compiled version just being much slower in 
general.


Daniel



Re: Master is slow

2016-10-18 Thread racoon

On 19.10.2016 07:03, racoon wrote:

On 18.10.2016 21:44, Guillaume Munch wrote:

Le 15/10/2016 à 11:39, racoon a écrit :

Typing within the master's work area is slow on my computer (while it is
fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging
running in the background or so?


A minimal working example to reproduce the slowness could help. You
can also try to profile your installation yourself with callgrind (you
will have to adapt for windows the instructions at
https://wiki.lyx.org/FAQ/FurtherHelp#profile)


It is really as simple as I wrote. I just create an empty document and
start typing quickly. LyX 2.2.2 can follow along, but the master starts
lagging behind.

Maybe there is something strange with debug going on? I am trying to
figure it out on the other branch of this threat.


By the way this did not start recently. I remember it being slow since I 
first time compiled it a while ago.


Re: Master is slow

2016-10-18 Thread racoon

On 18.10.2016 21:44, Guillaume Munch wrote:

Le 15/10/2016 à 11:39, racoon a écrit :

Typing within the master's work area is slow on my computer (while it is
fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging
running in the background or so?


A minimal working example to reproduce the slowness could help. You
can also try to profile your installation yourself with callgrind (you
will have to adapt for windows the instructions at
https://wiki.lyx.org/FAQ/FurtherHelp#profile)


It is really as simple as I wrote. I just create an empty document and 
start typing quickly. LyX 2.2.2 can follow along, but the master starts 
lagging behind.


Maybe there is something strange with debug going on? I am trying to 
figure it out on the other branch of this threat.


Daniel


Re: Master is slow

2016-10-18 Thread racoon

On 18.10.2016 18:43, Kornel Benko wrote:

Am Dienstag, 18. Oktober 2016 um 18:30:22, schrieb racoon 

On 18.10.2016 10:13, Kornel Benko wrote:

Am Dienstag, 18. Oktober 2016 um 09:58:14, schrieb Jean-Marc Lasgouttes 


Le 18/10/2016 à 09:55, racoon a écrit :



On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote:

Le 15/10/2016 à 19:53, racoon a écrit :

Yes, I think so.


Does compiling in normal mode help to recover the original speed?


Could you remind me how to compile in non-debug mode? Is that a setting
in CMAKE that I have to uncheck or so?


Kornel? Uwe?

(I am an autoconf guy)

JMarc


Maybe this could help:
-DLYX_DEBUG=OFF -DLYX_RELEASE=ON

Kornel


I have disabled LYX_DEBUG and LYX_RELEASE in cmake gui, generated and
reconfigurated. It seems to be still the same (slow).


Why disabling LYX_RELEASE?


Sorry, I just wrote it wrongly but set it correctly. LYX_RELEASE is enabled.




Maybe the VS output is helpful?

1>-- Build started: Project: lyx_version, Configuration: Debug Win32
--
1>  -- Git-hash = 120e84a
1>  -- Created C:/LyX/LyX2.3.0-build/lyx_date.tmp
1>  -- Created C:/LyX/LyX2.3.0-build/lyx_commit_hash.tmp
2>-- Build started: Project: INSTALL, Configuration: Debug Win32 --
2>  -- Install configuration: "Debug"


No wonder, because LYX_RELEASE is disabled. Should have been
 -- Install configuration: "Release"


See above. Also tried another run of cmake but it didn't help. Is there 
something else I have to uncheck? Maybe within VS?



2>  -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/LyX.exe
2>  -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/tex2lyx.exe
2>  -- Up-to-date:
C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx_version.py
2>  -- Up-to-date:
C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx
== Build: 2 succeeded, 0 failed, 23 up-to-date, 0 skipped ==

Daniel


Btw, I use Qt5.7 on linux and don't feel any slowness.

Kornel





Re: [LyX/master] Set window title according to platform UI

2016-10-18 Thread Scott Kostyshak
On Thu, Sep 08, 2016 at 03:59:50PM +0200, Jean-Marc Lasgouttes wrote:
> commit 82808fea04315fd323ec074e8ad7865d190987d4
> Author: Jean-Marc Lasgouttes 
> Date:   Tue Sep 6 11:17:10 2016 +0200
> 
> Set window title according to platform UI
> 
> The window title is built from the current file name and its
> mofidication state. We use our own code instead of the automatic title
> bar provided when windowFileName() is set because
> 
> 1/ Qt does not keep the full path name
> 2/ Qt does not yield a nice application name
> 
> The "read only" and "version control" status are shown in the status bar:
> 
> * for read only we use the tab read only emblem (with the right size)
> * for version control, we show the name of the backend (using a new
>   vcname() method of the backend).
> 
> The iconText() of the view is not updated anymore, since this is
> deprecated in Qt5.

I get a SIGSEGV starting from this commit from the following
reproducible steps:

1. open lib/examples/fr/beamer-article.lyx
2. right-click on the include inset and go to "edit included
file"
3. press ctrl+w to close the child doc.

Backtrace is attached.

Can you reproduce?

Scott
lyx: SIGSEGV signal caught!
Sorry, you have found a bug in LyX, hope you have not lost any data.
Please read the bug-reporting instructions in 'Help->Introduction' and send us 
a bug report, if necessary. Thanks!
Bye.
Error: LyX crashed!

SIGSEGV signal caught!
Sorry, you have found a bug in LyX, hope you have not lost any data.
Please read the bug-reporting instructions in 'Help->Introduction' and send us 
a bug report, if necessary. Thanks!
Bye.
(  1) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: 
lyx::frontend::Alert::doError(std::__cxx11::basic_string const&, 
std::__cxx11::basic_string const&, bool)
(  2) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: void std::_Bind, std::allocator > const>, 
std::reference_wrapper const>, 
std::reference_wrapper))(std::__cxx11::basic_string const&, 
std::__cxx11::basic_string const&, bool)>::__call(std::tuple<>&&, std::_Index_tuple<0ul, 1ul, 2ul>)
(  3) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: void std::_Bind, std::allocator > const>, 
std::reference_wrapper const>, 
std::reference_wrapper))(std::__cxx11::basic_string const&, 
std::__cxx11::basic_string const&, bool)>::operator()<, void>()
(  4) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: 
std::_Function_handler, std::allocator > const>, 
std::reference_wrapper const>, 
std::reference_wrapper))(std::__cxx11::basic_string const&, 
std::__cxx11::basic_string const&, bool)> >::_M_invoke(std::_Any_data const&)
(  5) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: std::function::operator()() const
(  6) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: 
lyx::frontend::InGuiThread::synchronousFunctionCall()
(  7) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: 
lyx::frontend::IntoGuiThreadMover::callInGuiThread()
(  8) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: void 
lyx::frontend::InGuiThread::call const>, 
std::reference_wrapper const>, 
std::reference_wrapper))(std::__cxx11::basic_string const&, 
std::__cxx11::basic_string const&, bool)> >(std::_Bind, std::allocator > const>, 
std::reference_wrapper const>, 
std::reference_wrapper))(std::__cxx11::basic_string const&, 
std::__cxx11::basic_string const&, bool)>)
(  9) /home/scott/lyxbuilds/master/CMakeBuild/bin/lyx: void 
lyx::frontend::InGuiThread::call, 
std::allocator > const&, std::__cxx11::basic_string const&, bool), 
std::__cxx11::basic_string const, std::__cxx11::basic_string const, bool>(void 
(*)(std::__cxx11::basic_string const&, std::__cxx11::basic_string const&, bool), 
std::__cxx11::basic_string

Re: master/child assertion

2016-10-18 Thread Scott Kostyshak
On Wed, Oct 19, 2016 at 01:20:04AM +0200, Kornel Benko wrote:

> I have no crash either.

Thank you for trying. I cannot reproduce this with the above recipe
either now. I found a SIGSEGV that I don't know if it is related. I will
report that (in a different thread).

Scott


signature.asc
Description: PGP signature


Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Enrico Forestieri
On Tue, Oct 18, 2016 at 11:40:19PM +0200, Guillaume Munch wrote:
> Le 18/10/2016 à 22:05, Enrico Forestieri a écrit :
> >On Tue, Oct 18, 2016 at 09:47:28PM +0200, Guillaume Munch wrote:
> >>
> >>Yes, this can be limited to the non-nice export. How strongly do you
> >>feel about it? Given the other replies I am tempted to push my patch as is.
> >
> >I have no strong opinion on this. However, sometimes I use sed or
> >awk for changing something in the latex produced by lyx and I am
> >only concerned that
> >
> >  \begin{lstlisting}%
> >  [caption={Caption}]
> >
> >is problematic to catch with respect to
> >
> >  \begin{lstlisting}[caption={Caption}]
> >
> >which can be covered by a simple regex.
> >
> 
> Not that special use cases are less important than Günter's argument of
> better readability, but probably you would be able to find workarounds
> in this case, would you not?

As always. But I don't understand. Given your goal, this is something
only useful for the non-nice export. So, why introducing a gratuitous
change? Note that readability is subjective. I find that this change
would reduce readability.

-- 
Enrico


Re: master/child assertion

2016-10-18 Thread Kornel Benko
Am Dienstag, 18. Oktober 2016 um 19:11:42, schrieb Scott Kostyshak 

> On Tue, Oct 18, 2016 at 06:12:52PM -0400, Richard Heck wrote:
> > On 10/18/2016 05:20 PM, Scott Kostyshak wrote:
> > > On Sun, Sep 18, 2016 at 10:18:22PM -0400, Scott Kostyshak wrote:
> > >
> > >> Richard, I just wanted to make sure you saw this email. Don't worry of
> > >> course if you don't have enough time to take a look. To reproduce, you
> > >> do not need to have the XeTeX binaries. You can do the following:
> > >>
> > >> 1. open lib/examples/fr/beamer-article.lyx
> > >> 2. right-click on the include inset and go to "edit included file"
> > >> 3. go to File > Export > LaTeX (XeTeX)
> > >>
> > >> Scott
> > > Richard, I just wanted to make sure that you saw the above email. Are
> > > you able to reproduce the issue with the instructions above?
> > 
> > Sorry, busy.
> 
> No problem.
> 
> > I just tried, and no, I just get a successful export.
> 
> OK thanks for trying.
> 
> Scott

I have no crash either.

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: master/child assertion

2016-10-18 Thread Scott Kostyshak
On Tue, Oct 18, 2016 at 06:12:52PM -0400, Richard Heck wrote:
> On 10/18/2016 05:20 PM, Scott Kostyshak wrote:
> > On Sun, Sep 18, 2016 at 10:18:22PM -0400, Scott Kostyshak wrote:
> >
> >> Richard, I just wanted to make sure you saw this email. Don't worry of
> >> course if you don't have enough time to take a look. To reproduce, you
> >> do not need to have the XeTeX binaries. You can do the following:
> >>
> >> 1. open lib/examples/fr/beamer-article.lyx
> >> 2. right-click on the include inset and go to "edit included file"
> >> 3. go to File > Export > LaTeX (XeTeX)
> >>
> >> Scott
> > Richard, I just wanted to make sure that you saw the above email. Are
> > you able to reproduce the issue with the instructions above?
> 
> Sorry, busy.

No problem.

> I just tried, and no, I just get a successful export.

OK thanks for trying.

Scott


signature.asc
Description: PGP signature


Re: master/child assertion

2016-10-18 Thread Richard Heck
On 10/18/2016 05:20 PM, Scott Kostyshak wrote:
> On Sun, Sep 18, 2016 at 10:18:22PM -0400, Scott Kostyshak wrote:
>
>> Richard, I just wanted to make sure you saw this email. Don't worry of
>> course if you don't have enough time to take a look. To reproduce, you
>> do not need to have the XeTeX binaries. You can do the following:
>>
>> 1. open lib/examples/fr/beamer-article.lyx
>> 2. right-click on the include inset and go to "edit included file"
>> 3. go to File > Export > LaTeX (XeTeX)
>>
>> Scott
> Richard, I just wanted to make sure that you saw the above email. Are
> you able to reproduce the issue with the instructions above?

Sorry, busy.

I just tried, and no, I just get a successful export.

Richard



Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Guillaume Munch

Le 18/10/2016 à 22:05, Enrico Forestieri a écrit :

On Tue, Oct 18, 2016 at 09:47:28PM +0200, Guillaume Munch wrote:


Yes, this can be limited to the non-nice export. How strongly do you
feel about it? Given the other replies I am tempted to push my patch as is.


I have no strong opinion on this. However, sometimes I use sed or
awk for changing something in the latex produced by lyx and I am
only concerned that

  \begin{lstlisting}%
  [caption={Caption}]

is problematic to catch with respect to

  \begin{lstlisting}[caption={Caption}]

which can be covered by a simple regex.



Not that special use cases are less important than Günter's argument of
better readability, but probably you would be able to find workarounds
in this case, would you not?



Re: master/child assertion

2016-10-18 Thread Scott Kostyshak
On Sun, Sep 18, 2016 at 10:18:22PM -0400, Scott Kostyshak wrote:

> Richard, I just wanted to make sure you saw this email. Don't worry of
> course if you don't have enough time to take a look. To reproduce, you
> do not need to have the XeTeX binaries. You can do the following:
> 
> 1. open lib/examples/fr/beamer-article.lyx
> 2. right-click on the include inset and go to "edit included file"
> 3. go to File > Export > LaTeX (XeTeX)
> 
> Scott

Richard, I just wanted to make sure that you saw the above email. Are
you able to reproduce the issue with the instructions above?

Scott


signature.asc
Description: PGP signature


Re: Fix for vertical table border for added column

2016-10-18 Thread racoon

On 18.10.2016 21:35, racoon wrote:

I think the attached fix leads to more intuitive results for added table
borders.

This solves one strange case:
1. create a new table (with the default borders, in particular the last
row has the borders |c|)


column not row I meant.


2. add a column after the last most right) column

Actual result:
- The last two rows have the borders |c||c


Same here. Need sleep. :)




Re: Master is slow

2016-10-18 Thread Jean-Marc Lasgouttes

Le 18/10/16 à 22:10, Richard Heck a écrit :

I also found that calls to TabWorkArea::updateTabTexts are
expensive and repeatedb. This amounts to 31% of the total amount of CPU,
shared between QTabWidget::setTabText and QTabWidget::setTabIcon.
TabWorkArea::updateTabTexts is connected to the signal
GuiWorkArea::titleChanged.


Could we here have some flag that told us whether anything has changed?


I think that I removed such a test %-] Let me check.

JMarc



Re: Master is slow

2016-10-18 Thread Richard Heck
On 10/18/2016 03:44 PM, Guillaume Munch wrote:
> Le 15/10/2016 à 11:39, racoon a écrit :
>> Typing within the master's work area is slow on my computer (while it is
>> fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging
>> running in the background or so?
>>
>
>
> Profiling shows that calls to BufferParams::isExportableFormat
> are numerous and expensive when doing char-forward (33% of the total
> amount of CPU). This is called from GuiView::updateToolbars ->
> GuiView::getStatus. There is room for improvement, but this is not new
> behaviour apparently.

Yes, I've been meaning for a while to implement a simple cache here, but
just haven't had time. That would help a lot.

> I also found that calls to TabWorkArea::updateTabTexts are
> expensive and repeatedb. This amounts to 31% of the total amount of CPU,
> shared between QTabWidget::setTabText and QTabWidget::setTabIcon.
> TabWorkArea::updateTabTexts is connected to the signal
> GuiWorkArea::titleChanged.

Could we here have some flag that told us whether anything has changed?

Richard



Re: Fix for vertical table border for added column

2016-10-18 Thread racoon

On 18.10.2016 21:35, racoon wrote:

I think the attached fix leads to more intuitive results for added table
borders.

This solves one strange case:
1. create a new table (with the default borders, in particular the last
row has the borders |c|)
2. add a column after the last most right) column

Actual result:
- The last two rows have the borders |c||c

Expected result:
- They have the borders |c|c|


I also removed a redundant line:

To set a right border, i.e. setRightLine(i, true), can be removed
because it is set only if there is already a right border, i.e.
rightLine(i).


Actually, due to my changes one of the

if (rightLine(i) && rightLine(j))

collapses to

if (rightLine(j))


The case that is different with my patch now is this:

Adding a column after c| (where there is no line before the column will 
lead to cc|


Before it was c| will lead to c|c

So adding the line will "push" the border out. But I don't see that 
necessarily as a bug. Could be a feature. :)


Daniel



Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Enrico Forestieri
On Tue, Oct 18, 2016 at 09:47:28PM +0200, Guillaume Munch wrote:
> 
> Yes, this can be limited to the non-nice export. How strongly do you
> feel about it? Given the other replies I am tempted to push my patch as is.

I have no strong opinion on this. However, sometimes I use sed or
awk for changing something in the latex produced by lyx and I am
only concerned that

  \begin{lstlisting}%
  [caption={Caption}]

is problematic to catch with respect to

  \begin{lstlisting}[caption={Caption}]

which can be covered by a simple regex.

-- 
Enrico


Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Guillaume Munch

Le 18/10/2016 à 09:20, Enrico Forestieri a écrit :


Maybe this can be limited to the non "nice" export? This is the format
that is exported only for previewing and not for generating latex code
meant for later editing. Specifically, this is the .tex file you get
in the temp dir, where you could also export a single word per line.
I think this is the important export format for forward/reverse-search.



Yes, this can be limited to the non-nice export. How strongly do you
feel about it? Given the other replies I am tempted to push my patch as is.



Re: Master is slow

2016-10-18 Thread Guillaume Munch

Le 15/10/2016 à 11:39, racoon a écrit :

Typing within the master's work area is slow on my computer (while it is
fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging
running in the background or so?




Profiling shows that calls to BufferParams::isExportableFormat
are numerous and expensive when doing char-forward (33% of the total
amount of CPU). This is called from GuiView::updateToolbars ->
GuiView::getStatus. There is room for improvement, but this is not new
behaviour apparently.

I also found that calls to TabWorkArea::updateTabTexts are
expensive and repeatedb. This amounts to 31% of the total amount of CPU,
shared between QTabWidget::setTabText and QTabWidget::setTabIcon.
TabWorkArea::updateTabTexts is connected to the signal
GuiWorkArea::titleChanged.

A minimal working example to reproduce the slowness could help. You
can also try to profile your installation yourself with callgrind (you
will have to adapt for windows the instructions at
https://wiki.lyx.org/FAQ/FurtherHelp#profile)

Jean-Marc, could the calls to TabWorkArea::updateTabTexts have to do
with your work on improved titles?



Fix for vertical table border for added column

2016-10-18 Thread racoon
I think the attached fix leads to more intuitive results for added table 
borders.


This solves one strange case:
1. create a new table (with the default borders, in particular the last 
row has the borders |c|)

2. add a column after the last most right) column

Actual result:
- The last two rows have the borders |c||c

Expected result:
- They have the borders |c|c|


I also removed a redundant line:

To set a right border, i.e. setRightLine(i, true), can be removed 
because it is set only if there is already a right border, i.e. 
rightLine(i).
From 08f5e87fed92776ab9a2e7070416e0f96c57cb66 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Ram=C3=83=C2=B6ller?= 
Date: Tue, 18 Oct 2016 20:55:49 +0200
Subject: [PATCH] Fixes vertical table border for added column.

---
 src/insets/InsetTabular.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/insets/InsetTabular.cpp b/src/insets/InsetTabular.cpp
index 4df9232..82e1bd6 100644
--- a/src/insets/InsetTabular.cpp
+++ b/src/insets/InsetTabular.cpp
@@ -877,8 +877,8 @@ void Tabular::insertColumn(col_type const col, bool copy)
setBottomLine(i, bottomLine(j));
setTopLine(i, topLine(j));
setLeftLine(i, leftLine(j));
+   setRightLine(i, rightLine(j));
if (rightLine(i) && rightLine(j)) {
-   setRightLine(i, true);
setRightLine(j, false);
}
if (buffer().params().track_changes)
-- 
2.9.0.windows.1



Re: ctests: 4 failing "Unicode-characters" tests

2016-10-18 Thread Guenter Milde
On 2016-10-18, Kornel Benko wrote:
> Am Dienstag, 18. Oktober 2016 um 18:11:01, schrieb jeanpierre.chret...@free.fr

...

>> I did also run ctest both with master and branch with command

>> $ctest -R pdf2

>> and I find about 150 fails over about 350 tests in both cases. Is that
>> normal ?

> It is not 'normal'.  We expect 0 failing here before release. I tried
> the same parameter and get 3 failures.
>   3710 - UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf2 (Failed)
>   4824 - UNRELIABLE.NONSTANDARD_export/templates/IUCr-article_pdf2 
> (Failed)
>   5142 - 
> UNRELIABLE.NONSTANDARD_export/templates/ja_beamer-conference-ornate-20min_pdf2
>  (Failed)
> Which is OK, because they are marked as 'unreliable' (which means that
> the test highly depends on some platform configuration)

You can also skip the unreliable tests with

   $ctest -R pdf2 -LE unreliable
  
Günter  



Re: ctests: 4 failing "Unicode-characters" tests

2016-10-18 Thread Guenter Milde
On 2016-10-18, jeanpierre.chret...@free.fr wrote:

>> Am Donnerstag, 13. Oktober 2016 um 09:39:29, schrieb Jean-Pierre
>> Chrétien 

>> > 
>> > Maybe I should rebuild the cbuildmaster dir from scratch?
>> > 

>> I think, cleaning Testing/.lyx should be OK. 

> OK, I did it, and the failing tests (due to the userdir problem) now
> pass. But I still have failing tests, this time because of missing
> textalpha.sty package in my TeXLive distribution. This is a bit
> surprising, as textalpha was put in CTAN early this year, and my
> TeXLive 2016 was installed last June.

textalpha.sty is on CTAN since 2013 as part of "greek-fontenc".

> So I will update TeXLive as soon as I get Internet back on my Linux
> box. I understand this this is necessary before running ctest.

Yes, while LyX does not require textalpha, it is necessary to support Greek
Unicode characters in any language.

You can also just ignore the test with "greek" and "greek-extended" Unicode
characters. This is what I do with Chinese and Japanese tests...

Alternatively, you can fix http://www.lyx.org/trac/ticket/9637
and remove \usepackage{textalpha} from the user-preamble of the "Greek" tests.

Günter



Re: [LyX/master] Docstringify getLongString in general and preamble snippets in particular

2016-10-18 Thread Guillaume Munch

Le 18/10/2016 à 09:44, Jean-Marc Lasgouttes a écrit :


I agree though that it is always annoying to have to guess what kind of
string is needed. I do not think that we implement a clear policy on
that. It would be nice to have one, so that we agree on what should be
what.



From what I got from Georg's explanations, there's already a policy
which is quite clear: std::string must only contain ASCII. Therefore any
code using std::string in UTF-8 must be converted to use docstring instead.




Re: [LyX/master] Implement reverse-search in the source panel

2016-10-18 Thread Guillaume Munch

Le 18/10/2016 à 09:41, Jean-Marc Lasgouttes a écrit :

Le 18/10/2016 à 01:08, Guillaume Munch a écrit :

Le 17/10/2016 à 00:35, Guillaume Munch a écrit :

commit 01d6333db21d3ed2c16f7c958fa204ff1c52044a
Author: Guillaume Munch 
Date:   Wed Sep 7 01:36:55 2016 +0100

Implement reverse-search in the source panel

Double-clicking on a line in the source panel triggers the
selection of the
corresponding line in the Buffer View.



This feature should ease the debugging of reverse-search, do not
hesitate to use it when trying to reproduce issues.


Looks like a great feature.

The next missing bit in TeXRow is the literate feature, which changes
arbitrarily line offsets. Sweave at leaset offers a concordance file
that allows to fix that, but I suspect that it requires significant
work. Would you feel brave enough to have a look if I give you the
references?



The answer is probably "no", but it would be useful to have this
information on some ad hoc Trac ticket.

Guillaume



Re: Regular expressions (adv search) not working on Mac OS X?

2016-10-18 Thread Kornel Benko
Am Dienstag, 18. Oktober 2016 um 18:42:02, schrieb Tommaso Cucinotta 

> On 18/10/2016 17:14, Kornel Benko wrote:
> > Maybe mixed compilation units (compiled with different settings)?
> > I see 2 possibilities
> > 1.) try on _really_ clean build tree.
> 
> had clean, distclean, autogen.sh several times :-(...
> 
> However, seems the crash on start went away after
> 
>--disable-std-regex --without-included-boost --disable-stdlib-debug
> 
> (configure was hinting to disable-stdlib-debug).
> 
> And, with the above settings, I have (back) a working regex inset in Advanced 
> Find & Replace :-)!
> 
> So, the problem with Advanced F might be: how do we package on Mac OS-X ?

No, I have the same problem iff using enabled std:regex. (linux)

> Side issue: ideally, we'd like that regex inset to work with all regex libs 
> also on Linux, no?
> (except for complex/advanced regexs...)

I think 'including complex/advanced regexs...'.
ATM, the regexes in adv are totally unusable with std:regex.

>  T.

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: Master is slow

2016-10-18 Thread Kornel Benko
Am Dienstag, 18. Oktober 2016 um 18:30:22, schrieb racoon 
> On 18.10.2016 10:13, Kornel Benko wrote:
> > Am Dienstag, 18. Oktober 2016 um 09:58:14, schrieb Jean-Marc Lasgouttes 
> > 
> >> Le 18/10/2016 à 09:55, racoon a écrit :
> >>>
> >>>
> >>> On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote:
>  Le 15/10/2016 à 19:53, racoon a écrit :
> > Yes, I think so.
> 
>  Does compiling in normal mode help to recover the original speed?
> >>>
> >>> Could you remind me how to compile in non-debug mode? Is that a setting
> >>> in CMAKE that I have to uncheck or so?
> >>
> >> Kornel? Uwe?
> >>
> >> (I am an autoconf guy)
> >>
> >> JMarc
> >
> > Maybe this could help:
> > -DLYX_DEBUG=OFF -DLYX_RELEASE=ON
> >
> > Kornel
> 
> I have disabled LYX_DEBUG and LYX_RELEASE in cmake gui, generated and 
> reconfigurated. It seems to be still the same (slow).

Why disabling LYX_RELEASE?

> Maybe the VS output is helpful?
> 
> 1>-- Build started: Project: lyx_version, Configuration: Debug Win32 
> --
> 1>  -- Git-hash = 120e84a
> 1>  -- Created C:/LyX/LyX2.3.0-build/lyx_date.tmp
> 1>  -- Created C:/LyX/LyX2.3.0-build/lyx_commit_hash.tmp
> 2>-- Build started: Project: INSTALL, Configuration: Debug Win32 --
> 2>  -- Install configuration: "Debug"

No wonder, because LYX_RELEASE is disabled. Should have been
 -- Install configuration: "Release"

> 2>  -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/LyX.exe
> 2>  -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/tex2lyx.exe
> 2>  -- Up-to-date: 
> C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx_version.py
> 2>  -- Up-to-date: 
> C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx
> == Build: 2 succeeded, 0 failed, 23 up-to-date, 0 skipped ==
> 
> Daniel

Btw, I use Qt5.7 on linux and don't feel any slowness.

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: Regular expressions (adv search) not working on Mac OS X?

2016-10-18 Thread Tommaso Cucinotta

On 18/10/2016 17:14, Kornel Benko wrote:

Maybe mixed compilation units (compiled with different settings)?
I see 2 possibilities
1.) try on _really_ clean build tree.


had clean, distclean, autogen.sh several times :-(...

However, seems the crash on start went away after

  --disable-std-regex --without-included-boost --disable-stdlib-debug

(configure was hinting to disable-stdlib-debug).

And, with the above settings, I have (back) a working regex inset in Advanced Find 
& Replace :-)!

So, the problem with Advanced F might be: how do we package on Mac OS-X ?

Side issue: ideally, we'd like that regex inset to work with all regex libs 
also on Linux, no?
(except for complex/advanced regexs...)

T.



Re: Master is slow

2016-10-18 Thread racoon

On 18.10.2016 10:13, Kornel Benko wrote:

Am Dienstag, 18. Oktober 2016 um 09:58:14, schrieb Jean-Marc Lasgouttes 


Le 18/10/2016 à 09:55, racoon a écrit :



On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote:

Le 15/10/2016 à 19:53, racoon a écrit :

Yes, I think so.


Does compiling in normal mode help to recover the original speed?


Could you remind me how to compile in non-debug mode? Is that a setting
in CMAKE that I have to uncheck or so?


Kornel? Uwe?

(I am an autoconf guy)

JMarc


Maybe this could help:
-DLYX_DEBUG=OFF -DLYX_RELEASE=ON

Kornel


I have disabled LYX_DEBUG and LYX_RELEASE in cmake gui, generated and 
reconfigurated. It seems to be still the same (slow).


Maybe the VS output is helpful?

1>-- Build started: Project: lyx_version, Configuration: Debug Win32 
--

1>  -- Git-hash = 120e84a
1>  -- Created C:/LyX/LyX2.3.0-build/lyx_date.tmp
1>  -- Created C:/LyX/LyX2.3.0-build/lyx_commit_hash.tmp
2>-- Build started: Project: INSTALL, Configuration: Debug Win32 --
2>  -- Install configuration: "Debug"
2>  -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/LyX.exe
2>  -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/tex2lyx.exe
2>  -- Up-to-date: 
C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx_version.py
2>  -- Up-to-date: 
C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx

== Build: 2 succeeded, 0 failed, 23 up-to-date, 0 skipped ==

Daniel


Re: ctests: 4 failing "Unicode-characters" tests

2016-10-18 Thread Kornel Benko
Am Dienstag, 18. Oktober 2016 um 18:11:01, schrieb jeanpierre.chret...@free.fr
> 
> > Am Donnerstag, 13. Oktober 2016 um 09:39:29, schrieb Jean-Pierre
> > Chrétien 
> 
> > > 
> > > Maybe I should rebuild the cbuildmaster dir from scratch?
> > > 
> > 
> > I think, cleaning Testing/.lyx should be OK. 
> 
> OK, I did it, and the failing tests (due to the userdir problem) now pass.
> But I still have failing tests, this time because of missing textalpha.sty 
> package in my TeXLive distribution.
> This is a bit surprising, as textalpha was put in CTAN early this year, and 
> my TeXLive 2016 was installed last June.
> 
> So I will update TeXLive as soon as I get Internet back on my Linux box. I 
> understand this this is necessary before running ctest.
> 
> I did also run ctest both with master and branch with command
> 
> $ctest -R pdf2
> 
> and I find about 150 fails over about 350 tests in both cases. Is that normal 
> ?

It is not 'normal'.  We expect 0 failing here before release. I tried the same 
parameter and get 3 failures.
3710 - UNRELIABLE.NONSTANDARD_export/examples/fa/splash_pdf2 (Failed)
4824 - UNRELIABLE.NONSTANDARD_export/templates/IUCr-article_pdf2 
(Failed)
5142 - 
UNRELIABLE.NONSTANDARD_export/templates/ja_beamer-conference-ornate-20min_pdf2 
(Failed)
Which is OK, because they are marked as 'unreliable' (which means that the test 
highly depends on some platform configuration)

> More generally, is there somewhere on trac a file containing the list of 
> tests currently failing (perhaps not the 5000 tests available, but e.g the 
> pdf2 tests
> as I tried here)?

Not that I were aware of.

Kornel


signature.asc
Description: This is a digitally signed message part.


Re: ctests: 4 failing "Unicode-characters" tests

2016-10-18 Thread jeanpierre . chretien

> Am Donnerstag, 13. Oktober 2016 um 09:39:29, schrieb Jean-Pierre
> Chrétien 

> > 
> > Maybe I should rebuild the cbuildmaster dir from scratch?
> > 
> 
> I think, cleaning Testing/.lyx should be OK. 

OK, I did it, and the failing tests (due to the userdir problem) now pass.
But I still have failing tests, this time because of missing textalpha.sty 
package in my TeXLive distribution.
This is a bit surprising, as textalpha was put in CTAN early this year, and my 
TeXLive 2016 was installed last June.

So I will update TeXLive as soon as I get Internet back on my Linux box. I 
understand this this is necessary before running ctest.

I did also run ctest both with master and branch with command

$ctest -R pdf2

and I find about 150 fails over about 350 tests in both cases. Is that normal ?
More generally, is there somewhere on trac a file containing the list of tests 
currently failing (perhaps not the 5000 tests available, but e.g the pdf2 tests
as I tried here)?

-- 
Jean-Pierre





Re: Some inset offset fine tuning

2016-10-18 Thread racoon

On 18.10.2016 09:37, Jean-Marc Lasgouttes wrote:

I had a go earlier to replace TEXT_TO_INSET_OFFSET with a function that
computes the length according to current zoom and screen resolution. I
abandonned the patch (attached) for now because it created problems for
vertical spacing.


Yes, maybe the differentiations between the horizontal spacing and 
vertical that I did could be helpful there. I'll take a look.


Daniel


Re: Regular expressions (adv search) not working on Mac OS X?

2016-10-18 Thread Kornel Benko
Am Dienstag, 18. Oktober 2016 um 16:58:02, schrieb Tommaso Cucinotta 

> On 17/10/2016 23:24, Kornel Benko wrote:
> > Please try with std:regex enabled. 
> 
> just realized I was missing libboost_regex-dev, that's why configure was not
> using nor linking to that lib. After adding that, and compiling with
> 
>--without-included-boost --disable-std-regex

Here I think you should use
 --with-included-boost --enable-std-regex
The error does not show if boost:regex is used.

> I have now a spectacular
> 
> tommaso@tommylap:~/lyx-trunk-ws/lyx$ ./src/lyx -dbg any
> terminate called after throwing an instance of 'std::bad_alloc'
>what():  std::bad_alloc
> Aborted (core dumped)
> 
> Kornel, any clue?
> 
> Thx,
> 
>  T.

Maybe mixed compilation units (compiled with different settings)?

I see 2 possibilities
1.) try on _really_ clean build tree.
2.) try with cmake.

Kornel


signature.asc
Description: This is a digitally signed message part.


Re: Regular expressions (adv search) not working on Mac OS X?

2016-10-18 Thread Tommaso Cucinotta

On 17/10/2016 23:24, Kornel Benko wrote:
Please try with std:regex enabled. 


just realized I was missing libboost_regex-dev, that's why configure was not
using nor linking to that lib. After adding that, and compiling with

  --without-included-boost --disable-std-regex

I have now a spectacular

tommaso@tommylap:~/lyx-trunk-ws/lyx$ ./src/lyx -dbg any
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

Kornel, any clue?

Thx,

T.



Re: Some inset offset fine tuning

2016-10-18 Thread racoon

On 18.10.2016 09:37, Jean-Marc Lasgouttes wrote:

Le 17/10/2016 à 01:28, racoon a écrit :

Though I have a non-high resolution display. Maybe it does not look as
good on a high-res display. If so, maybe there should be an adjustment
for high-res displays?


I had a go earlier to replace TEXT_TO_INSET_OFFSET with a function that
computes the length according to current zoom and screen resolution. I
abandonned the patch (attached) for now because it created problems for
vertical spacing. You are welcome to borrow parts of it (the margins are
already in).


Thanks JMarc. Do I understand you correctly that you tested high res 
displays and they actually create a problem with those tiny 1px spaces?



You would be welcome to have a look at it. Another option would be to
have a length in em, that is relative to the current font. That would
make the inset spacing comparable to normal spacing in the enclosing
space. This is the best solution IMO, but I am not sure that the font
information is available when we need it.


Since I can't test on a high res display: would a zoom of, say, 100 % 
result in the same height in pixels of a given font on high res and low 
res displays?


Daniel



Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Guenter Milde
On 2016-10-18, Jean-Marc Lasgouttes wrote:
> Le 18/10/2016 à 01:10, Guillaume Munch a écrit :
>> captions in listings appear as:

>>   \begin{lstlisting}%
>>   [caption={Caption}]
>>   \end{lstlisting}

> In this case and in the sub-caption case, I do not think that LaTeX 
> needs the "%".

Whitespace after a macro (\begin) is ignored, after "\begin{something}" not.
Even if it will not necessarily change something in the output, it is safer
to escape it with %.

Günter



Re: Master is slow

2016-10-18 Thread Kornel Benko
Am Dienstag, 18. Oktober 2016 um 09:58:14, schrieb Jean-Marc Lasgouttes 

> Le 18/10/2016 à 09:55, racoon a écrit :
> >
> >
> > On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote:
> >> Le 15/10/2016 à 19:53, racoon a écrit :
> >>> Yes, I think so.
> >>
> >> Does compiling in normal mode help to recover the original speed?
> >
> > Could you remind me how to compile in non-debug mode? Is that a setting
> > in CMAKE that I have to uncheck or so?
> 
> Kornel? Uwe?
> 
> (I am an autoconf guy)
> 
> JMarc

Maybe this could help:
-DLYX_DEBUG=OFF -DLYX_RELEASE=ON

Kornel


signature.asc
Description: This is a digitally signed message part.


Re: Master is slow

2016-10-18 Thread Jean-Marc Lasgouttes

Le 18/10/2016 à 09:55, racoon a écrit :



On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote:

Le 15/10/2016 à 19:53, racoon a écrit :

Yes, I think so.


Does compiling in normal mode help to recover the original speed?


Could you remind me how to compile in non-debug mode? Is that a setting
in CMAKE that I have to uncheck or so?


Kornel? Uwe?

(I am an autoconf guy)

JMarc



Re: reducing file size of images shipped within LyX

2016-10-18 Thread Jean-Marc Lasgouttes

Le 14/10/2016 à 11:46, mn a écrit :

These are really low hanging fruit:
Image files are suboptimally compressed.



Vector: processed 1435 files saving 2.2 MB ( 56% )
in about 20 seconds

Results from a fresh download of 2.2.2 mac.

If someone could just once recompress those files in the devel-tree the
benefits should propagate from there.


Hi mn,

What I am worried about for example for svg files is that the files may 
become difficult to edit with inkscape as a result.


For example scour (http://codedread.com/scour/), another svg scrubber 
(as they say) has a warning to this effect.


So this would be something to do when packaging binaries, for example.

JMarc


Re: Master is slow

2016-10-18 Thread racoon



On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote:

Le 15/10/2016 à 19:53, racoon a écrit :

Yes, I think so.


Does compiling in normal mode help to recover the original speed?


Could you remind me how to compile in non-debug mode? Is that a setting 
in CMAKE that I have to uncheck or so?


Daniel


Re: Master is slow

2016-10-18 Thread Jean-Marc Lasgouttes

Le 15/10/2016 à 19:53, racoon a écrit :

Yes, I think so.


Does compiling in normal mode help to recover the original speed?

JMarc


On 15.10.2016 18:39, Jean-Marc Lasgouttes wrote:

Did you compile in debug mode ?




Re: [LyX/master] Docstringify getLongString in general and preamble snippets in particular

2016-10-18 Thread Jean-Marc Lasgouttes

Le 18/10/2016 à 01:08, Guillaume Munch a écrit :

Le 17/10/2016 à 00:35, Guillaume Munch a écrit :

commit 1f945177b9628b213c60872df88f2d155c3d6c54
Author: Guillaume Munch 
Date:   Sun Sep 25 12:37:40 2016 +0200

Docstringify getLongString in general and preamble snippets in
particular

Prepare ground for TexRow InPreamble



I can rename getLongString into getLongDocstring if people are more
comfortable with that.


We already have many 'docstring asString()' methods, so I am not sure we 
need that.


I agree though that it is always annoying to have to guess what kind of 
string is needed. I do not think that we implement a clear policy on 
that. It would be nice to have one, so that we agree on what should be what.


JMarc



Re: [LyX/master] Implement reverse-search in the source panel

2016-10-18 Thread Jean-Marc Lasgouttes

Le 18/10/2016 à 01:08, Guillaume Munch a écrit :

Le 17/10/2016 à 00:35, Guillaume Munch a écrit :

commit 01d6333db21d3ed2c16f7c958fa204ff1c52044a
Author: Guillaume Munch 
Date:   Wed Sep 7 01:36:55 2016 +0100

Implement reverse-search in the source panel

Double-clicking on a line in the source panel triggers the
selection of the
corresponding line in the Buffer View.



This feature should ease the debugging of reverse-search, do not
hesitate to use it when trying to reproduce issues.


Looks like a great feature.

The next missing bit in TeXRow is the literate feature, which changes 
arbitrarily line offsets. Sweave at leaset offers a concordance file 
that allows to fix that, but I suspect that it requires significant 
work. Would you feel brave enough to have a look if I give you the 
references?


JMarc



Re: [LyX/master] Add the customary 1-pixel gap before MathMacroTemplate to better see cursor

2016-10-18 Thread Jean-Marc Lasgouttes

Le 18/10/2016 à 01:10, Guillaume Munch a écrit :

Yes, both metrics and painting were taken into account when writing the
patch, and what you see is the result.


It did not look obvious from the patch, but I do trust you on this!

JMarc



Re: Some inset offset fine tuning

2016-10-18 Thread Jean-Marc Lasgouttes

Le 17/10/2016 à 01:28, racoon a écrit :

I just tried to do some fine tuning on the inset offsets (minimalistic
and classic so far).


Hi racoon,

I am glad you are looking at this. I agree that small offsets are better.


Though I have a non-high resolution display. Maybe it does not look as
good on a high-res display. If so, maybe there should be an adjustment
for high-res displays?


I had a go earlier to replace TEXT_TO_INSET_OFFSET with a function that 
computes the length according to current zoom and screen resolution. I 
abandonned the patch (attached) for now because it created problems for 
vertical spacing. You are welcome to borrow parts of it (the margins are 
already in).


You would be welcome to have a look at it. Another option would be to 
have a length in em, that is relative to the current font. That would 
make the inset spacing comparable to normal spacing in the enclosing 
space. This is the best solution IMO, but I am not sure that the font 
information is available when we need it.


JMarc

From a6c9f8a782d561ccea0bd5c2bb70c71527280c0e Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 12 Nov 2015 10:19:08 +0100
Subject: [PATCH] Replace hardcoded TEXT_TO_INSET_OFFSET by dynamic value

The value is counted as 1 millimeter now (the same at 100 dpi). We also ensures 
that it measures at least 1 pixel.

Similarly, the Workarea default margin is now 2.5mm instead of being hardcoded 
to 10.

This should improve the situation for HiDPI systems.
---
 src/BufferView.cpp   |  6 --
 src/RowPainter.cpp   |  2 +-
 src/frontends/qt4/GuiFontMetrics.cpp |  6 +++---
 src/frontends/qt4/GuiPainter.cpp |  4 ++--
 src/insets/Inset.cpp |  9 +
 src/insets/Inset.h   |  2 +-
 src/insets/InsetCaption.cpp  |  8 
 src/insets/InsetCollapsable.cpp  |  6 +++---
 src/insets/InsetIPA.cpp  | 12 ++--
 src/insets/InsetPhantom.cpp  |  4 ++--
 src/insets/InsetPreview.cpp  | 12 ++--
 src/insets/InsetTabular.cpp  |  4 ++--
 src/insets/InsetText.cpp | 28 ++--
 src/insets/RenderGraphic.cpp | 18 +-
 src/insets/RenderPreview.cpp |  2 +-
 15 files changed, 67 insertions(+), 56 deletions(-)

diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 0030f33..902f8a7 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -351,11 +351,13 @@ BufferView::~BufferView()
 
 int BufferView::rightMargin() const
 {
+   // THe value used to be hardcoded to 10, which is 2.5mm at 100dpi
+   int const default_margin = Length(2.5, Length::MM).inPixels(0);
// The additional test for the case the outliner is opened.
if (!full_screen_ ||
!lyxrc.full_screen_limit ||
-   width_ < lyxrc.full_screen_width + 20)
-   return 10;
+   width_ < lyxrc.full_screen_width + 2 * default_margin)
+   return default_margin;
 
return (width_ - lyxrc.full_screen_width) / 2;
 }
diff --git a/src/RowPainter.cpp b/src/RowPainter.cpp
index ce5780b..3d360d4 100644
--- a/src/RowPainter.cpp
+++ b/src/RowPainter.cpp
@@ -540,7 +540,7 @@ void RowPainter::paintLast()
FontMetrics const & fm = theFontMetrics(font);
int const size = int(0.75 * fm.maxAscent());
int const y = yo_ - size;
-   int const max_row_width = width_ - size - 
Inset::TEXT_TO_INSET_OFFSET;
+   int const max_row_width = width_ - size - 
Inset::textToInsetOffset();
int x = is_rtl ? nestMargin() + changebarMargin()
: max_row_width - row_.right_margin;
 
diff --git a/src/frontends/qt4/GuiFontMetrics.cpp 
b/src/frontends/qt4/GuiFontMetrics.cpp
index 8d0b026..d4f3585 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -237,9 +237,9 @@ bool GuiFontMetrics::breakAt(docstring & s, int & x, bool 
const rtl, bool const
 void GuiFontMetrics::rectText(docstring const & str,
int & w, int & ascent, int & descent) const
 {
-   static int const d = Inset::TEXT_TO_INSET_OFFSET / 2;
+   static int const d = Inset::textToInsetOffset() / 2;
 
-   w = width(str) + Inset::TEXT_TO_INSET_OFFSET;
+   w = width(str) + Inset::textToInsetOffset();
ascent = metrics_.ascent() + d;
descent = metrics_.descent() + d;
 }
@@ -250,7 +250,7 @@ void GuiFontMetrics::buttonText(docstring const & str,
int & w, int & ascent, int & descent) const
 {
rectText(str, w, ascent, descent);
-   w += Inset::TEXT_TO_INSET_OFFSET;
+   w += Inset::textToInsetOffset();
 }
 
 
diff --git a/src/frontends/qt4/GuiPainter.cpp b/src/frontends/qt4/GuiPainter.cpp
index 2b024d8..af75547 100644
--- a/src/frontends/qt4/GuiPainter.cpp
+++ b/src/frontends/qt4/GuiPainter.cpp
@@ -533,10 +533,10 @@ 

Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Jean-Marc Lasgouttes

Le 18/10/2016 à 01:10, Guillaume Munch a écrit :

captions in listings appear as:

  \begin{lstlisting}%
  [caption={Caption}]
  \end{lstlisting}


In this case and in the sub-caption case, I do not think that LaTeX 
needs the "%".


JMarc



Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Enrico Forestieri
On Tue, Oct 18, 2016 at 01:10:36AM +0200, Guillaume Munch wrote:

> Le 17/10/2016 à 04:12, Pavel Sanda a écrit :
> > Guillaume Munch wrote:
> > > Dear list,
> > > 
> > > The attached patches add safe line breaks ("%\n") to the output, to
> > > crucially increase the precision of forward/reverse-search and error
> > > reporting of captions. This is especially useful as these captions
> > > introduce a discontinuity in the TexRow. The change is trivial but since
> > > this modifies the LaTeX output I prefer to ask for any objection.
> > 
> > How ugly (in terms of chunked text) the LaTeX code becomes now for people 
> > who
> > actually use LaTeX source after the export?
> > 
> 
> Hi Pavel,
> 
> captions in listings appear as:
> 
>   \begin{lstlisting}%
>   [caption={Caption}]
>   \end{lstlisting}
> 
> instead of:
> 
>   \begin{lstlisting}[caption={Caption}]
>   \end{lstlisting}
> 
> and sub-captions show up as:
> 
>   \begin{figure}
>   \subfloat[Sub-caption]%
>   {Sub-figure}
> 
>   \caption{Caption}
>   \end{figure}
> 
> instead of:
> 
>   \begin{figure}
>   \subfloat[Sub-caption]{Sub-figure}
> 
>   \caption{Caption}
>   \end{figure}
> 
> 
> What do you think?

Maybe this can be limited to the non "nice" export? This is the format
that is exported only for previewing and not for generating latex code
meant for later editing. Specifically, this is the .tex file you get
in the temp dir, where you could also export a single word per line.
I think this is the important export format for forward/reverse-search.

-- 
Enrico


Re: [patch] Increase precision of TexRow in captions

2016-10-18 Thread Guenter Milde
On 2016-10-17, Guillaume Munch wrote:
> Le 17/10/2016 à 04:12, Pavel Sanda a écrit :
>> Guillaume Munch wrote:
>>> Dear list,

>>> The attached patches add safe line breaks ("%\n") to the output, to
>>> crucially increase the precision of forward/reverse-search and error
>>> reporting of captions. This is especially useful as these captions
>>> introduce a discontinuity in the TexRow. The change is trivial but since
>>> this modifies the LaTeX output I prefer to ask for any objection.

>> How ugly (in terms of chunked text) the LaTeX code becomes now for
>> people who actually use LaTeX source after the export?


> Hi Pavel,

> captions in listings appear as:

>\begin{lstlisting}%
>[caption={Caption}]
>\end{lstlisting}

> instead of:

>\begin{lstlisting}[caption={Caption}]
>\end{lstlisting}

> and sub-captions show up as:

>\begin{figure}
>\subfloat[Sub-caption]%
>{Sub-figure}

>\caption{Caption}
>\end{figure}

> instead of:

>\begin{figure}
>\subfloat[Sub-caption]{Sub-figure}

>\caption{Caption}
>\end{figure}


> What do you think?

IMO, this is an improvement also regarding the readibility of the source.

+1 from me

Günter



Re: Some inset offset fine tuning

2016-10-18 Thread racoon

On 17.10.2016 01:28, racoon wrote:

I just tried to do some fine tuning on the inset offsets (minimalistic
and classic so far).

[...]


Because my message did not go through to the list at first, I posted it 
on trac:


http://www.lyx.org/trac/ticket/10441

Daniel