Re: [patch] use setProcessEnvironment, not shell escape (cmd / env)

[Stephan Witt]

Am 02.11.2015 um 16:44 schrieb Enrico Forestieri :

> On Sun, Nov 01, 2015 at 11:47:42PM -0500, PhilipPirrip wrote:
> 
>> Hi Enrico, thank you  for your response. I hope the others will help us
>> resolve this too.
> 
> Given the overwhelming amount of replies, I doubt anyone is interested
> in this matter.

I'm really interested and I worked on that topic already.
(It was the thread "Yosemite + LyX" on lyx-devel.)
Unfortunately I'm too short on time, ATM.

Stephan

Re: [patch] Finding the generated latex file

[Stephan Witt]

Am 03.11.2015 um 04:58 schrieb Guillaume Munch :

> Le 02/11/2015 18:38, Guillaume Munch a écrit :
>> Le 28/10/2015 16:39, Ilan a écrit :
>>> Thanks David and Stephan.
>>> 
>>> My problem is that I'm working on a multi-file project so under the tmp
>>> directory there are several directories and the location of the Latex
>>> file
>>> depends on the file I compiled (and of course the tmp directory has a
>>> different
>>> name each time under windows).
>>> 
>>> What I used to do until few months ago is opening the Latex log, and
>>> there I
>>> saw the full path to the compiled file, so I could copy it to a Latex
>>> editor.
>>> After some updates to Lyx & Latex, I see in the log only the file name
>>> without
>>> the path.
>>> 
>>> I can (and this is what I do) to find the current tmp directory and then
>>> searching for all the Latex files to find the right one by its name.
>>> I hoped there is an option to return to the previous state of easily
>>> finding
>>> the directory with a click.
>>> 
>>> 
>> 
>> (from )
>> 
>> 
>> Dear List,
>> 
>> (continuing on lyx-devel)
>> 
>> 
>> Here's a proof-of-concept patch to add an “Open directory…” button to
>> the log dialog. I did it very quickly which is why I only call it
>> “proof-of-concept”. If we want to commit this then at least somebody
>> with better QtDesigner skills should add the button to the interface in
>> a more proper way.
>> 
>> I, too, used to spend too much time finding the proper lyxtmpdir (for
>> various reasons ranging from debugging the latex output using
>> divide-and-conquer when LyX's debugging facility was unsufficient, to
>> debugging instant preview). And I think it's not too bad to expose the
>> LyX internals in this way.
>> 
>> What do you think?
>> 
> 
> 
> Pushed at f441590c. Windows/OSX users, please report if it does not work.

It works for me on OSX. Although I'd expect user questions regarding the
attached error message on exit of LyX: 
"Cannot remove temporary directory…" or similar…

Stephan

Re: [patch] Finding the generated latex file

[PhilipPirrip]

On 11/02/2015 10:58 PM, Guillaume Munch wrote:

Pushed at f441590c. Windows/OSX users, please report if it does not work.


Hey Guillaume,
Bad news, it didn't work on Windows. Qt 4.8, VS2010, WinXP/VirtualBox
This was the error message:
lyx\src\frontends\qt4\GuiLog.cpp (207): Unable to open QUrl even though 
dir exists!



I then added another slash to your code
QUrl qdir(toqstr(from_utf8("file:///" + dir.absFileName())),
  QUrl::StrictMode);
(by the example here http://doc.qt.io/qt-4.8/qdesktopservices.html#details)
and it WORKED!




On Linux, it worked with two AND three slashes: both Qt 4.8 and Qt 5.5; 
Gnome 3.18, Fedora 23.





If I may:  to me, "Open Containing Directory"  doesn't mean much. What 
does the directory contain - the log shown above, the lyx document? How 
about "Open Compilation Directory" (or Temporary / or Folder)?


What I find would be handy to have, since you've already been messing 
around this code, is a button that would clear the temporary dir.  LyX 
sometimes gets stuck with some old log and aux files, especially after 
an error in compilation, and the only way to get rid of the error 
messages is to make a dummy change or reopen the document.

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

[Jean-Marc Lasgouttes]

Le 03/11/2015 04:57, Guillaume Munch a écrit :

commit f441590c8e0b5e970fbdd656198ec4993dfecb43
Author: Guillaume Munch 
Date:   Mon Nov 2 18:19:40 2015 +

 Add "Open Containing Directory" button to the log dialog (#9211, #9834)

 It takes the place of the "Copy to Clipboard" button which was redundant.


I get a new warning when compiling:

  GEN  moc_GuiLog.cpp
../../../../master/src/frontends/qt4/ui/LogUi.ui: Warning: Tab-stop 
assignment: 'copyPB' is not a valid widget.


JMarc

Test LyX 2.2.0 with Retina display

[Sven Goedeke]

Hey,

i would like to test LyX 2.2.0 with Retina display on MBP Retina 13 running OS 
X 10.10 or 10.11. If possible, please let me know when you have installation 
files for the development version of 2.2.0 available.

Thanks,
Sven Goedeke

Re: Unit testing

[Jean-Marc Lasgouttes]

Le 02/11/2015 21:36, Vincent van Ravesteijn a écrit :

Dear all,

I have prepared a unit test framework based on google-test (gtest). You
can see the commits at
http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests.
It includes gtest-1.7.0 (permitted by the license).


Hi Vincent,

What is the difference with the tests we current use (I mean the "make 
check" sort). The same but with better interface?


JMarc

shortcut clash with German locale

[Guenter Milde]

Dear LyXers,

when I open a fresh compiled LyX here (German locale), I get the error

  frontends/qt4/Menus.cpp (735): Menu warning: menu entries "Logos|L" and
  "Sichtbares Leerzeichen|L" share the same shortcut.

Günter

Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

[Guenter Milde]

On 2015-11-02, Scott Kostyshak wrote:
> On Mon, Nov 02, 2015 at 10:40:27PM +, Guenter Milde wrote:

Dear Scott,

>> > thanks for the patch.

>> I modified it to use UTF8 with XeTeX without the 
>> \inputencoding commands. 

...

> I would say go ahead and commit if you are satisfied with it. From what I
> understand, the patch is now a complete patch in the sense that it is a full
> step forward. 

Actually, I am not satisfied, because the "normal" use case (exporting to a
LaTeX file with inputencoding ASCII) is now worse than before. I this sense,
it is a partial patch.

For the use case "XeTeX with TeX fonts", it is overly complicated.

So I split it in two:

* to fix the regressions with "XeTeX + TeX fonts", a simple change in
  PDFOptions.cpp is sufficient. See below.
  
  The nice thing is, that this is simple, localized and only changes
  where change is required - actually a completion for the patch-set
  fixing #9740.

  >> A short test here showed that this
  >> helps with Umlauts or Cyrillic charactes in the PDF Info.

* the updated "comprehensive but incomplete" patch based on your work is now
  at http://www.lyx.org/trac/ticket/9839, so the work is not lost.
  
  With the "show output anyway" option in 2.2, the status quo is actually
  tolerable. I'll try the patch for #9830, then there is also a workaound for
  ASCII export (i.e. the user can write G\"unter instead of Günter).


> Let me know if you want me to run the export tests before/after.

Please check, if this patch cures some regressions introduced by
fixing #9740.

Günter


Exec: git 'diff' 'PDFOptions.cpp' 2>&1
Dir: /usr/local/src/lyx/src/

diff --git a/src/PDFOptions.cpp b/src/PDFOptions.cpp
index 6646888..143d715 100644
--- a/src/PDFOptions.cpp
+++ b/src/PDFOptions.cpp
@@ -174,21 +174,15 @@ void PDFOptions::writeLaTeX(OutputParams & runparams, 
otexstream & os,
opt = "\\hypersetup{" + rtrim(opt + hyperset, ",") + "}\n";
}
 
-   // hyperref expects LICR macros for non-ASCII chars. With Xe/LuaTeX 
utf-8 works, too.
-   // Usually, "(lua)inputenc" converts the input to LICR.
+   // hyperref expects LICR macros for non-ASCII chars.
+   // Usually, "(lua)inputenc" converts the input to LICR, with XeTeX 
utf-8 works, too.
// As hyperref provides good coverage for \inputencoding{utf8}, we can 
try
// this if the current input encoding does not support a character.
-   // FIXME: inputenc (part 1 of 2)
-   //   Replace the "FullUnicode" check with
-   //   check for loading of inputenc or luainputenc package
-   //   (see BufferParams::writeEncodingPreamble and 
runparams.encoding->package()).
-   //   Otherwise \inputencoding is not defined
-   //   (e.g. if "latex-encoding" is set to "ascii").
-   //   Dont forget to keep the check below (part 2) in sync!
-   if (need_unicode && enc && enc->iconvName() != "UTF-8"
-   &&!runparams.isFullUnicode()) {
-   os << "\\inputencoding{utf8}\n"
-  << setEncoding("UTF-8");
+   // FIXME: don't use \inputencoding if "inputenc" is not loaded (#9839).
+   if (need_unicode && enc && enc->iconvName() != "UTF-8") {
+   if (runparams.flavor != OutputParams::XETEX)
+   os << "\\inputencoding{utf8}\n";
+   os << setEncoding("UTF-8");
}
// If hyperref is loaded by the document class, we output
// \hypersetup \AtBeginDocument if hypersetup is not (yet)
@@ -204,11 +198,10 @@ void PDFOptions::writeLaTeX(OutputParams & runparams, 
otexstream & os,
   << "\\fi\n";
} else
os << from_utf8(opt);
-   // FIXME: inputenc (part 2 of 2)
-   if (need_unicode && enc && enc->iconvName() != "UTF-8"
-   &&!runparams.isFullUnicode()) {
-   os << setEncoding(enc->iconvName())
-  << "\\inputencoding{" << from_ascii(enc->latexName()) << 
"}\n";
+   if (need_unicode && enc && enc->iconvName() != "UTF-8") {
+   os << setEncoding(enc->iconvName());
+   if (runparams.flavor != OutputParams::XETEX)
+   os << "\\inputencoding{" << 
from_ascii(enc->latexName()) << "}\n";
}
 }
 

Re: Unit testing

[Vincent van Ravesteijn]

>> Any comments ? Shall I proceed to push this to master ?
>>
>> Vincent
>>
>
> Having a unit test framework integrated is a very good idea!
>
> Why have you chosen gtest and not QTest? Does gtest has interesting
> features which QTest does not have?

I'm not very experienced with unit testing, so I cannot tell any
details. Someone proposed gtest a long time ago on the list, and I've
seen it being used in other projects. So, it must be good enough for
us.

>
> One benefit of QTest is that it ships with the Qt installation and
> no code has to be added to the repository.

True. Most of the added code is actually not used
(tests,samples,unused autotools/MacOs/msvc code, etc.).

>
> But knowing gtest (also integrating into a existing project)
> is also good for other non-Qt projects.

Yes, as I said, I've seen it around, more than QTest (no, I don't have
usage statistics).

Vincent

Re: Unit testing

[Peter Kümmel]

Am 02.11.2015 um 21:36 schrieb Vincent van Ravesteijn:

Dear all,

I have prepared a unit test framework based on google-test (gtest). You can see 
the commits at
http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests. It 
includes gtest-1.7.0 (permitted by the
license).

Unit testing can be enabled by running CMake with -DLYX_ENABLE_UNIT_TESTS. This 
will make a target gtest-main and
unit-tests. It also create LyX.lib against which the unit testing executable is 
linked so that the functionality in the
core can be tested.

I have created a first (example) test case in tests/src/Buffer.cpp, called 
"BufferTest", which has three tests and which
is supposed to test the functionality of "lyx::Buffer".

A CMake target "unit-tests" now builds an executable running all unit-tests and 
gives an output as below. For each test
case, there is also automatically a CTest created. This test runs "unit-tests 
--gtest_filter=BufferTest" and gives a
summary. For more details, it is adviced to run the unit-tests executable 
directly (or improve CMake to capture the
output somehow).

Any comments ? Shall I proceed to push this to master ?

Vincent



Having a unit test framework integrated is a very good idea!

Why have you chosen gtest and not QTest? Does gtest has interesting
features which QTest does not have?

One benefit of QTest is that it ships with the Qt installation and
no code has to be added to the repository.

But knowing gtest (also integrating into a existing project)
is also good for other non-Qt projects.

Peter


#ctest -N
Test project C:/Users/Vincent/Documents/LyX/build/lyx/tests
   Test #1: unit_test/src/BufferTest

Total Tests: 1

#ctest -R
Test project C:/Users/Vincent/Documents/LyX/build/lyx/tests
 Start 1: unit_test/src/BufferTest
1/1 Test #1: unit_test/src/BufferTest .***Failed0.27 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.28 sec

The following tests FAILED:
   1 - unit_test/src/BufferTest (Failed)
Errors while running CTest

#unit-tests
Running main() from gtest_main.cc
[==] Running 3 tests from 1 test case.
[--] Global test environment set-up.
[--] 3 tests from BufferTest
[ RUN  ] BufferTest.NonExistingFile
[   OK ] BufferTest.NonExistingFile (0 ms)
[ RUN  ] BufferTest.NonExistingFileOperations
[   OK ] BufferTest.NonExistingFileOperations (0 ms)
[ RUN  ] BufferTest.UnicodeCharacters
..\..\..\source\gitlyx\tests\src\Buffer.cpp(45): error: Value of: string("C:/tés
t.lyx")
   Actual: "C:/t\xA8\xA6st.lyx"
Expected: fn1.absFileName()
Which is: "C:/t\xEF\xBF\xBD\xEF\xBF\xBDst.lyx"
[  FAILED  ] BufferTest.UnicodeCharacters (0 ms)
[--] 3 tests from BufferTest (0 ms total)

[--] Global test environment tear-down
[==] 3 tests from 1 test case ran. (0 ms total)
[  PASSED  ] 2 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] BufferTest.UnicodeCharacters

  1 FAILED TEST

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

[Guillaume Munch]

Le 03/11/2015 08:32, Jean-Marc Lasgouttes a écrit :

Le 03/11/2015 04:57, Guillaume Munch a écrit :

commit f441590c8e0b5e970fbdd656198ec4993dfecb43
Author: Guillaume Munch 
Date:   Mon Nov 2 18:19:40 2015 +

 Add "Open Containing Directory" button to the log dialog (#9211,
#9834)

 It takes the place of the "Copy to Clipboard" button which was
redundant.


I get a new warning when compiling:

   GEN  moc_GuiLog.cpp
../../../../master/src/frontends/qt4/ui/LogUi.ui: Warning: Tab-stop
assignment: 'copyPB' is not a valid widget.

JMarc





Thanks, I should have caught that.

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

[Guillaume Munch]

Le 03/11/2015 07:35, Kornel Benko a écrit :

Am Dienstag, 3. November 2015 um 04:57:45, schrieb Guillaume Munch 


commit f441590c8e0b5e970fbdd656198ec4993dfecb43
Author: Guillaume Munch 
Date:   Mon Nov 2 18:19:40 2015 +

 Add "Open Containing Directory" button to the log dialog (#9211, #9834)

 It takes the place of the "Copy to Clipboard" button which was redundant.



The 'Open Containing Directory' button displays an empty window here.
The displayed path is correct, but the window looks like it belongs to 'gvim' 
(text editor).

Is this really intended?



Please test again at a0783e15. But if the displayed path is really
correct, I am afraid it does not fix it.

If after that it still opens gvim, there isn't much that can be done on
the programmer's side since Qt is supposed to handle things. It seems
to be the recommended cross-platform method to open a directory. Then it
might be a configuration issue on your side. For instance, what does
"xdg-open " achieve on your system?



Guillaume

Re: [patch] Finding the generated latex file

[Guillaume Munch]

Le 03/11/2015 08:27, PhilipPirrip a écrit :

On 11/02/2015 10:58 PM, Guillaume Munch wrote:

Pushed at f441590c. Windows/OSX users, please report if it does not work.


Hey Guillaume,
Bad news, it didn't work on Windows. Qt 4.8, VS2010, WinXP/VirtualBox
This was the error message:
lyx\src\frontends\qt4\GuiLog.cpp (207): Unable to open QUrl even though
dir exists!


I then added another slash to your code
QUrl qdir(toqstr(from_utf8("file:///" + dir.absFileName())),
   QUrl::StrictMode);
(by the example here http://doc.qt.io/qt-4.8/qdesktopservices.html#details)
and it WORKED!




On Linux, it worked with two AND three slashes: both Qt 4.8 and Qt 5.5;
Gnome 3.18, Fedora 23.



Thanks for the report and the extra step in testing. Please try again
with latest master.




If I may:  to me, "Open Containing Directory"  doesn't mean much. What
does the directory contain - the log shown above, the lyx document? How
about "Open Compilation Directory" (or Temporary / or Folder)?


It opens the directory containing the chosen log — there's really no
trap about it. So I think that "Open Containing Directory" is the
clearest about what is achieved.

LyX is (almost) consistent in using Directory instead of Folder.




What I find would be handy to have, since you've already been messing
around this code, is a button that would clear the temporary dir.  LyX
sometimes gets stuck with some old log and aux files, especially after
an error in compilation, and the only way to get rid of the error
messages is to make a dummy change or reopen the document.



I think that there are already bug reports about this and I am not sure
that an additional button is the best solution. But, for very specific
usages, thanks the the new button, you can now open the directory, do
Ctrl+A and then delete…

Re: [patch] Finding the generated latex file

[Guillaume Munch]

Le 03/11/2015 08:59, Stephan Witt a écrit :

Am 03.11.2015 um 04:58 schrieb Guillaume Munch >:


Le 02/11/2015 18:38, Guillaume Munch a écrit :

Le 28/10/2015 16:39, Ilan a écrit :

Thanks David and Stephan.

My problem is that I'm working on a multi-file project so under the tmp
directory there are several directories and the location of the Latex
file
depends on the file I compiled (and of course the tmp directory has a
different
name each time under windows).

What I used to do until few months ago is opening the Latex log, and
there I
saw the full path to the compiled file, so I could copy it to a Latex
editor.
After some updates to Lyx & Latex, I see in the log only the file name
without
the path.

I can (and this is what I do) to find the current tmp directory and then
searching for all the Latex files to find the right one by its name.
I hoped there is an option to return to the previous state of easily
finding
the directory with a click.




(from )


Dear List,

(continuing on lyx-devel)


Here's a proof-of-concept patch to add an “Open directory…” button to
the log dialog. I did it very quickly which is why I only call it
“proof-of-concept”. If we want to commit this then at least somebody
with better QtDesigner skills should add the button to the interface in
a more proper way.

I, too, used to spend too much time finding the proper lyxtmpdir (for
various reasons ranging from debugging the latex output using
divide-and-conquer when LyX's debugging facility was unsufficient, to
debugging instant preview). And I think it's not too bad to expose the
LyX internals in this way.

What do you think?




Pushed at f441590c. Windows/OSX users, please report if it does not work.


It works for me on OSX. Although I'd expect user questions regarding the
attached error message on exit of LyX:
"Cannot remove temporary directory…" or similar…




Do you mean that the patch now causes this error message? Under which
circumstances precisely? Is it that if the directory is open in the
finder, then LyX cannot remove the directory? (Under Linux, Nautilus's
behaviour is to move to the parent directory if the current directory is
deleted.)

Re: [patch] Finding the generated latex file

[Stephan Witt]

Am 03.11.2015 um 17:39 schrieb Guillaume Munch :

> Le 03/11/2015 16:16, Stephan Witt a écrit :
>> Am 03.11.2015 um 16:36 schrieb Guillaume Munch :
>>> 
>>> Do you mean that the patch now causes this error message? Under which
>>> circumstances precisely? Is it that if the directory is open in the
>>> finder, then LyX cannot remove the directory? (Under Linux, Nautilus's
>>> behaviour is to move to the parent directory if the current directory is
>>> deleted.)
>> 
>> Yes, the error is displayed by LyX because it cannot remove the temporary
>> directory while it is shown in the Finder (the Nautilus of OSX).
>> 
>> I'd guess this is the common scenario for the average user:
>> check the LaTeX log, use the button, switch back to LyX and finally exit LyX 
>> -
>> which raises the mentioned error message and leaves the empty temporary
>> directory in file system.
>> 
>> It's not the patch causing the error message - it's easier to get it with the
>> patch.
>> 
> 
> So the error message is valid. The solution would be to make it clearer. 
> Maybe one could show a better message depending on the failure. If it's 
> "resource busy" then we could add to the message something like "The 
> directory might be currently in use in a different program".

Unfortunately it's a boolean state only: see FileName.cpp line 639 - 
rmdir(QFileInfo const & fi) called from FileName::destroyDirectory().

Stephan

Make master-buffer-update (and -view) compile current document when there is no master

[Joon Ro]

Hi,
I was wondering if it would be possible to make master-buffer-update (and 
-view) compile the current document when there is no master defined. It will 
reduce the psychological overhead involved with remembering to press two 
different shortcuts to achieve the same goal (compile the whole document) 
depending on document structures.
For example, I have two document projects going on, one with a master (a 
separate lyx file for each sections), the other without a master (all sections 
in one lyx file). Since I developed the habit of pressing the shortcut for 
master-buffer-update for the first project, I often find myself mistakenly 
pressing the same shortcut while I'm working on the second project, which does 
not do anything. 
Since this command is disabled when there is no master, I don't think it will 
add any confusion.
Thank you,Joon


  

Re: [patch] use setProcessEnvironment, not shell escape (cmd / env)

[Enrico Forestieri]

On Tue, Nov 03, 2015 at 02:29:32AM -0500, PhilipPirrip wrote:
> On 11/02/2015 03:16 PM, Enrico Forestieri wrote:
> >>>This last observation suggests what is the minimal change to be performed,
> >>>i.e., let the latex run work as if the document dir was the current
> >>>directory. This means setting the relevant environment variables such
> >>>that the document dir is also scanned, without replicating the setting
> >>>for TEXINPUTS. I'll prepare a patch along these lines for review.
> >>
> >>
> >>I thank you for that! I'd be glad to be the first one to test it in both
> >>Windows and Linux.
> >
> >Please, find attached the patch I come up with. It seems to work for me.
> 
> 
> No surprises here, everything worked as intended:
> Linux, WinXP, Qt 4.8, Qt 5.5, pdf, eps, pdf with eps figures, classicthesis
> template (including biblatex and biber/bibtex8), a few manuals...
> 
> 
> 
> 
> > You mean like Yoda? I don't know whether to feel flattered or offended ;)
> 
> May the force be with you... while into 2.2.0 you're pushing this.
> PLEASE ;)

Scott?

-- 
Enrico

Re: [patch] use setProcessEnvironment, not shell escape (cmd / env)

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 08:24:49PM +0100, Enrico Forestieri wrote:
> On Tue, Nov 03, 2015 at 02:29:32AM -0500, PhilipPirrip wrote:
> > On 11/02/2015 03:16 PM, Enrico Forestieri wrote:
> > >>>This last observation suggests what is the minimal change to be 
> > >>>performed,
> > >>>i.e., let the latex run work as if the document dir was the current
> > >>>directory. This means setting the relevant environment variables such
> > >>>that the document dir is also scanned, without replicating the setting
> > >>>for TEXINPUTS. I'll prepare a patch along these lines for review.
> > >>
> > >>
> > >>I thank you for that! I'd be glad to be the first one to test it in both
> > >>Windows and Linux.
> > >
> > >Please, find attached the patch I come up with. It seems to work for me.
> > 
> > 
> > No surprises here, everything worked as intended:
> > Linux, WinXP, Qt 4.8, Qt 5.5, pdf, eps, pdf with eps figures, classicthesis
> > template (including biblatex and biber/bibtex8), a few manuals...
> > 
> > 
> > 
> > 
> > > You mean like Yoda? I don't know whether to feel flattered or offended ;)
> > 
> > May the force be with you... while into 2.2.0 you're pushing this.
> > PLEASE ;)
> 
> Scott?

Please put it in. Thanks for the patch, Enrico.

Philip, thanks for your detailed testing on both Linux and Windows. That
is very important.

Scott

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 04:14:55PM +, Guillaume Munch wrote:
> Le 03/11/2015 16:10, Kornel Benko a écrit :
> >
> >It is the same, opens with gvim. But in the mean time I learned a new gvim 
> >command ':Ex[plore]', which
> >shows the content of this directory. And one can select files (e.g. click on 
> >filenames) and open them.
> >
> >For me it is OK ...
> >
> 
> OK. Only thing is that I would be reassured to know that there is indeed
> a setting in your system that determines that gvim must be chosen as a
> file browser on purpose…

Tested on Ubuntu and works as expected.

Scott

Re: [patch] Finding the generated latex file

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 06:03:36PM +0100, Stephan Witt wrote:
> Am 03.11.2015 um 17:39 schrieb Guillaume Munch :
> 
> > So the error message is valid. The solution would be to make it clearer. 
> > Maybe one could show a better message depending on the failure. If it's 
> > "resource busy" then we could add to the message something like "The 
> > directory might be currently in use in a different program".
> 
> Unfortunately it's a boolean state only: see FileName.cpp line 639 - 
> rmdir(QFileInfo const & fi) called from FileName::destroyDirectory().

A few points:

- I agree with Stephan that the likelihood of users running into this
  message is greater.

- For me the message is shown twice.

- I actually wonder if we should not show the message to the user. Who
  cares that we cannot remove the temporary directory? What if we just
  output the message on STDERR?

Scott

Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 06:49:01AM -0800, Kornel Benko wrote:
> Am Dienstag, 3. November 2015 um 12:40:22, schrieb Guenter Milde 
> 
> > On 2015-11-02, Scott Kostyshak wrote:
> > > On Mon, Nov 02, 2015 at 10:40:27PM +, Guenter Milde wrote:
> > 
> > Dear Scott,
> > 
> > >> > thanks for the patch.
> > 
> > >> I modified it to use UTF8 with XeTeX without the 
> > >> \inputencoding commands. 
> > 
> > ...
> > 
> > > I would say go ahead and commit if you are satisfied with it. From what I
> > > understand, the patch is now a complete patch in the sense that it is a 
> > > full
> > > step forward. 
> > 
> > Actually, I am not satisfied, because the "normal" use case (exporting to a
> > LaTeX file with inputencoding ASCII) is now worse than before. I this sense,
> > it is a partial patch.

OK makes sense.

> > For the use case "XeTeX with TeX fonts", it is overly complicated.
> > 
> > So I split it in two:
> > 
> > * to fix the regressions with "XeTeX + TeX fonts", a simple change in
> >   PDFOptions.cpp is sufficient. See below.
> >   
> >   The nice thing is, that this is simple, localized and only changes
> >   where change is required - actually a completion for the patch-set
> >   fixing #9740.
> > 
> >   >> A short test here showed that this
> >   >> helps with Umlauts or Cyrillic charactes in the PDF Info.
> > 
> > * the updated "comprehensive but incomplete" patch based on your work is now
> >   at http://www.lyx.org/trac/ticket/9839, so the work is not lost.
> >   
> >   With the "show output anyway" option in 2.2, the status quo is actually
> >   tolerable. I'll try the patch for #9830, then there is also a workaound 
> > for
> >   ASCII export (i.e. the user can write G\"unter instead of Günter).

Do we have a bug report for the workaround for ASCII export?

> > > Let me know if you want me to run the export tests before/after.
> > 
> > Please check, if this patch cures some regressions introduced by
> > fixing #9740.
> 
> Check with 'ctest -L suspended' (my local version)
> Now the following tests (previously not passing) pass:
>   390 - INVERTED_SEE-README.ctest_export/doc/Math_pdf4_texF (Failed)
>   702 - INVERTED_SEE-README.ctest_export/doc/de/Math_pdf4_texF (Failed)
>   870 - INVERTED_SEE-README.ctest_export/doc/es/Math_pdf4_texF (Failed)
>   1052 - INVERTED_SEE-README.ctest_export/doc/fr/Math_pdf4_texF (Failed)
>   1787 - INVERTED_SEE-README.ctest_export/examples/PDF-comment_pdf4_texF 
> (Failed)
> 
> They can now be removed from revertedTests.
> 
> checking now with 'ctest -L export -E '(lyx16|xhtml)$'
>   -> 94% tests passed, 179 tests failed out of 3041
> 
> That is, 29 tests are now better than before.
> Checking the output, all 29 are of type pdf4_texF (XeTeX + TeX fonts).
> 
> I'd say, please commit.

Thanks for checking Kornel.

Günter, thanks for your work on these tricky issues. After alpha is
released, let me know if there is anything pending that you would like
for me to work on. Since I know nothing about this topic, you would need
to break it down into simple steps like you did for me before so I can
focus on the C++.

Scott

Re: [patch] Finding the generated latex file

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 03:45:03PM +, Guillaume Munch wrote:
> Le 03/11/2015 08:27, PhilipPirrip a écrit :
> >On 11/02/2015 10:58 PM, Guillaume Munch wrote:
> >>Pushed at f441590c. Windows/OSX users, please report if it does not work.
> >
> >Hey Guillaume,
> >Bad news, it didn't work on Windows. Qt 4.8, VS2010, WinXP/VirtualBox
> >This was the error message:
> >lyx\src\frontends\qt4\GuiLog.cpp (207): Unable to open QUrl even though
> >dir exists!
> >
> >
> >I then added another slash to your code
> >QUrl qdir(toqstr(from_utf8("file:///" + dir.absFileName())),
> >   QUrl::StrictMode);
> >(by the example here http://doc.qt.io/qt-4.8/qdesktopservices.html#details)
> >and it WORKED!
> >
> >
> >
> >
> >On Linux, it worked with two AND three slashes: both Qt 4.8 and Qt 5.5;
> >Gnome 3.18, Fedora 23.
> 
> 
> Thanks for the report and the extra step in testing. Please try again
> with latest master.
> 
> 
> >
> >If I may:  to me, "Open Containing Directory"  doesn't mean much. What
> >does the directory contain - the log shown above, the lyx document? How
> >about "Open Compilation Directory" (or Temporary / or Folder)?
> 
> It opens the directory containing the chosen log — there's really no
> trap about it. So I think that "Open Containing Directory" is the
> clearest about what is achieved.
> 
> LyX is (almost) consistent in using Directory instead of Folder.
> 
> 
> >
> >What I find would be handy to have, since you've already been messing
> >around this code, is a button that would clear the temporary dir.  LyX
> >sometimes gets stuck with some old log and aux files, especially after
> >an error in compilation, and the only way to get rid of the error
> >messages is to make a dummy change or reopen the document.
> >
> 
> I think that there are already bug reports about this and I am not sure
> that an additional button is the best solution. But, for very specific
> usages, thanks the the new button, you can now open the directory, do
> Ctrl+A and then delete…

I also think there are bug reports about it. I think it is a reasonable
request, but I think that it is separate from this topic, although I
agree that you could use Guillaume's button to achieve what you want.

Also, even though I do support your feature request, it would be great
if you could make bug reports with reproducible examples so that we
could fix the bugs at the source.

Scott

RE: Make master-buffer-update (and -view) compile current document when there is no master

[Joon Ro]

> This makes sense IMHO. Please file an enhancement request at 
> http://www.lyx.org/trac/wiki/BugTrackerHome so that it does not get  
> forgotten.
Done (#9842). Thank you.
Best,JoonFrom: joon...@outlook.com
To: lyx-devel@lists.lyx.org
Subject: Make master-buffer-update (and -view) compile current document when 
there is no master
Date: Tue, 3 Nov 2015 11:32:48 -0800




Hi,
I was wondering if it would be possible to make master-buffer-update (and 
-view) compile the current document when there is no master defined. It will 
reduce the psychological overhead involved with remembering to press two 
different shortcuts to achieve the same goal (compile the whole document) 
depending on document structures.
For example, I have two document projects going on, one with a master (a 
separate lyx file for each sections), the other without a master (all sections 
in one lyx file). Since I developed the habit of pressing the shortcut for 
master-buffer-update for the first project, I often find myself mistakenly 
pressing the same shortcut while I'm working on the second project, which does 
not do anything. 
Since this command is disabled when there is no master, I don't think it will 
add any confusion.
Thank you,Joon



  

Re: [LyX/master] Fix algorithm that computes horizontal scroll offset

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 11:18:42AM +0100, Jean-Marc Lasgouttes wrote:
> commit 1f0d210ab56057f35960a3b86f5fa1e03ef8ecd0
> Author: Jean-Marc Lasgouttes 
> Date:   Tue Oct 27 16:11:01 2015 +0100
> 
> Fix algorithm that computes horizontal scroll offset
> 
> Rewrite the logic completely:
> * fix cases where the offset was reset unnecessarily
> * fix cases where the row was scrolled too much: as soon as a side of the 
> row is completely visible, there is no need to scroll more.
> * fix cases where offset would never reset

Starting with this commit, if I open e.g. the Introduction manual and I
triple click on the first line of the first paragraph (starting with
"LyX is a document preparation system...", the line is selected and the
text jumps a little to the left. If I click then on that line again, the
selection is removed and the text does not again change position. But if
I then click on a different line, the text jumps back to where it was
before.

Let me know if you cannot reproduce and want a screencast.

Scott

Re: Unit testing

[Georg Baum]

Vincent van Ravesteijn wrote:

> On Tue, Nov 3, 2015 at 2:28 PM, Jean-Marc Lasgouttes 
> wrote:
>>
>> Hi Vincent,
>>
>> What is the difference with the tests we current use (I mean the "make
>> check" sort). The same but with better interface?

The overhead to add a test with the current setup is far too high. Using 
unit tests massively does only work if you do not need to do much more than 
adding your test function somewhere.


> The current tests are all different executables, which is not really
> optimal for speed in compilation and execution and has some overhead.
> Now they all appear as different targets here and there. Using a test
> framework also gives you a bunch of tools for writing tests (automatic
> preparation and cleanup of objects, mocking, etc.). Then it gives you
> the statistics and the ability to easily select tests you want to run,
> etc.
> 
> Maybe, more importantly, having a proper framework may ignite the
> spirit of creating tests, which then might become a new habit.

I hope so;-) Thank you very much for working on the tests.

Regarding the test framework there is also boost::test (which would fit our 
needs as well). Unfortunately I have neither experience with gtest nor with 
QTest, so I don't know how it compares to these frameworks. Anyway, I think 
the most important thing is to have a working setup, so I don't care much 
which framework is used in the end.


Georg

Re: shortcut clash with German locale

[Georg Baum]

Guenter Milde wrote:

> Dear LyXers,
> 
> when I open a fresh compiled LyX here (German locale), I get the error
> 
>   frontends/qt4/Menus.cpp (735): Menu warning: menu entries "Logos|L" and
>   "Sichtbares Leerzeichen|L" share the same shortcut.

Thanks, this is fixed now. It might happen for other locales as well (if the 
L shortcut is already used), in this case the solution would be the same: 
Add a translation with a different shortcut.


Georg

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Georg Baum]

Guillaume Munch wrote:

> 
> 
> I am bringing this to the list due to the timing, due to the fact that
> it is a file format change, and due to the fact that it looks severe in
> the above context.
> 
> I suggest moving these settings to the user preferences.
> 
> Can we agree on the issue? On the solution? Is it easy to do?

I don't think there is an easy solution, because it depends on the use case. 
For example, in our documentation workflows \tracking_changes needs to be 
the same for all users, so this should not go into the preferences. For the 
other two I am not sure.


Georg

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Guillaume Munch]

Le 03/11/2015 19:49, LyX Ticket Tracker a écrit :

#9841: Preferences specific to the user and not to the file should not be 
recorded
in the file
-+
  Reporter:  gadmm|  Owner:  lasgouttes
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  2.2.0
Component:  general  |Version:  2.1.4
  Severity:  normal   |   Keywords:  fileformat
-+
  Preferences specific to the user and not to the file should not be
  recorded in the file, for instance the following:

  \justification
  \tracking_changes
  \output_changes

  The problem is when collaborating on a file and using a versioning system
  like git. Then, these settings cause needless conflicts. For
  \justification, we can simply agree on a setting, but for
  \tracking_changes and \output_changes, it is normal to turn them on and
  off many times. There is an irony to the fact that change tracking is
  meant to help with collaborative works (in fact an aggravating factor)…

  This is a great annoyance, and obviously a file format change.





I am bringing this to the list due to the timing, due to the fact that 
it is a file format change, and due to the fact that it looks severe in 
the above context.


I suggest moving these settings to the user preferences.

Can we agree on the issue? On the solution? Is it easy to do?



Guillaume

Re: Make master-buffer-update (and -view) compile current document when there is no master

[Georg Baum]

Joon Ro wrote:

> Hi,
> I was wondering if it would be possible to make master-buffer-update (and
> -view) compile the current document when there is no master defined. It
> will reduce the psychological overhead involved with remembering to press
> two different shortcuts to achieve the same goal (compile the whole
> document) depending on document structures. For example, I have two
> document projects going on, one with a master (a separate lyx file for
> each sections), the other without a master (all sections in one lyx file).
> Since I developed the habit of pressing the shortcut for
> master-buffer-update for the first project, I often find myself mistakenly
> pressing the same shortcut while I'm working on the second project, which
> does not do anything. Since this command is disabled when there is no
> master, I don't think it will add any confusion. Thank you,Joon

This makes sense IMHO. Please file an enhancement request at 
http://www.lyx.org/trac/wiki/BugTrackerHome so that it does not get 
forgotten.


Georg

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Guillaume Munch]

Le 03/11/2015 21:16, Georg Baum a écrit :

Guillaume Munch wrote:




I am bringing this to the list due to the timing, due to the fact that
it is a file format change, and due to the fact that it looks severe in
the above context.

I suggest moving these settings to the user preferences.

Can we agree on the issue? On the solution? Is it easy to do?


I don't think there is an easy solution, because it depends on the use case.
For example, in our documentation workflows \tracking_changes needs to be
the same for all users, so this should not go into the preferences. For the
other two I am not sure.



For context:

\justification : whether justification is displayed in the LyX window 
(does not affect output)


\track_changes : whether the track changes button is enabled (does not 
affect the existing contents)


\output_changes : whether the changes are displayed in the output (I can 
agree that this one could be considered as part of the document.)



For \justification, it seems obvious that this is a personal preference 
similar to the display font which should go to the preferences dialog.


For \track_changes, I do not understand your rationale for making it a 
setting of the document. It is not locked on, so the user who edits the 
documentations has to know in any case that he should track changes (if 
I had not been told to, then I'd have turned it off even if it was on).


I do not understand what you mean with "has to be the same for all 
users". It happens to be the same for all users in this case, but this 
setting is not sufficient (nor essential) for the workflow. (Also, while 
ensuring that it does what I described, I noticed that the save button 
remained disabled after altering change tracking. If it's really part of 
the document, then pushing the change tracking button should enable the 
save button!)



Also, is there a way to have settings which are per-user *and* per-file?


Lastly, in any case, conflicts do not always happen, because these 
settings are booleans, so there are only two possible configurations for 
each (conflicts happen when there are 3 different configurations). In my 
case the conflict happened because \tracking_changes and \output_changes 
are next to one another so they are treated as one by git (thus with 
four possible configurations). A solution to this particular conflict 
issue would be to not write them next to one another. But this would be 
a hack, as it is still annoying to agree about personal settings with 
co-authors.


For \output_changes, I only use it in a temporary fashion so it's more 
of a personal setting, but in any case it's ok if we keep it because of 
the previous reason: boolean settings cannot create conflicts on their 
own. So when there's just one it's fine, it's when there are many such 
settings that we have problems.



Guillaume

Re: [LyX/master] Add warning message if we do no conversion.

[Richard Heck]

On 11/01/2015 08:26 PM, Scott Kostyshak wrote:

On Sun, Nov 01, 2015 at 08:04:28PM -0500, Richard Heck wrote:

So it would only happen from the command line in which case the warning
can be ignored easily enough.

I don't know if I like this asymmetry between GUI and command line.


All I meant was that LyX never calls lyx2lyx to "convert" a format to 
itself---we check whether the format is the current format before 
calling lyx2lyx---so in that sense the warning isn't relevant to the GUI.


Richard

Re: [patch] use setProcessEnvironment, not shell escape (cmd / env)

[Richard Heck]

On 11/03/2015 06:38 PM, PhilipPirrip wrote:
Just curious: what and when executes the code in os_win32.cpp 
(os_.cpp in general). Whatever I did to test the patch, these 
functions were not called.


The one Enrico modified is called when you try to view or edit a file 
that is referenced from an external inset. In fact, it does nothing 
except on OSX. A compiler might even notice this and omit the function call.


Richard

Re: [patch] Finding the generated latex file

[Andrew Parsloe]

On 4/11/2015 11:07 a.m., Scott Kostyshak wrote:

On Tue, Nov 03, 2015 at 06:03:36PM +0100, Stephan Witt wrote:

Am 03.11.2015 um 17:39 schrieb Guillaume Munch :


So the error message is valid. The solution would be to make it clearer. Maybe one could show a 
better message depending on the failure. If it's "resource busy" then we could add to the 
message something like "The directory might be currently in use in a different program".

Unfortunately it's a boolean state only: see FileName.cpp line 639 - 
rmdir(QFileInfo const & fi) called from FileName::destroyDirectory().

A few points:

- I agree with Stephan that the likelihood of users running into this
   message is greater.

- For me the message is shown twice.

- I actually wonder if we should not show the message to the user. Who
   cares that we cannot remove the temporary directory? What if we just
   output the message on STDERR?

Scott

I have found the message helpful, particularly when developing a module 
or a latex package to work with LyX. In the latter case, the failure to 
remove the temp directory may indicate that a latex process is still 
running. (Failure of a preview snippet for instance.) From experience I 
know that this can lead to multiple occurrences of the latex executable 
running at once, and LyX becoming more and more sluggish.


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [patch] use setProcessEnvironment, not shell escape (cmd / env)

[Enrico Forestieri]

On Tue, Nov 03, 2015 at 08:30:53PM -0500, Richard Heck wrote:
> On 11/03/2015 06:38 PM, PhilipPirrip wrote:
> >Just curious: what and when executes the code in os_win32.cpp (os_.cpp
> >in general). Whatever I did to test the patch, these functions were not
> >called.
> 
> The one Enrico modified is called when you try to view or edit a file that
> is referenced from an external inset. In fact, it does nothing except on
> OSX. A compiler might even notice this and omit the function call.

More precisely, that code is used only on Windows and OSX for launching
an editor or viewer registered in the OS for that file type. One can
tell what these are by the fact that the corresponding entries are
denoted by "auto" in the preferences, instead of the name of a program.

-- 
Enrico

Re: lyx2lyx bugs from export tests

[Scott Kostyshak]

On Sun, Nov 01, 2015 at 07:43:57PM -0500, Scott Kostyshak wrote:
> On Sun, Nov 01, 2015 at 04:30:31PM -0500, Richard Heck wrote:
> 
> > The problem is that EmbeddedObjects.lyx was already format 498, and lyx2lyx
> > seems to do the wrong thing when asked to convert it to the format it
> > already is, i.e., to convert to 498.
> > 
> > I've committed a patch that simply does the null conversion in this case. As
> > I say in the commit message, this seems better than aborting with an error.
> 
> Thanks for fixing that. I agree with you. I'm not convinced we should
> have a warning, but I will bring that issue up by replying to the
> commmit instead of using this email thread for it.
> 
> Back to EmbeddedObjects.lyx---it passes with 492 but fails with 491.
> Does this suggest the format change 491 is the problem or 492? I suppose
> it is a problem of whether the bug is in backwards conversion or
> forwards conversion.
> 
> The lyx2lyx code in the commit for format 492 is responsible for
> converting back to 491, so if the bug is in backwards conversion then it
> is the (likely) problem. On the other hand, if the bug is in forwards
> conversion, then it seems the commit that introduced 491 is the (likely)
> root cause. Is that the correct thinking?

I'm still curious about this question.

Uwe, can you take a look at this bug? I think it has to do with the 491
and 492 format changes. If you look at the error, it has to do with
color. If I remember correctly, the xcolor package is used instead of
the color package or something like that (not sure that's the underlying
cause).

To be clear, the steps to reproduce on master are:

1. Open EmbeddedObjects.lyx.
2. Export to LyX 2.1.x format.
3. Open the file you just exported.
4. Try to compile with PDF (pdflatex).

Scott

Re: lyx2lyx bugs from export tests

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 06:22:11PM -0500, Scott Kostyshak wrote:
> On Sun, Nov 01, 2015 at 07:43:57PM -0500, Scott Kostyshak wrote:
> > On Sun, Nov 01, 2015 at 04:30:31PM -0500, Richard Heck wrote:
> > 
> > > The problem is that EmbeddedObjects.lyx was already format 498, and 
> > > lyx2lyx
> > > seems to do the wrong thing when asked to convert it to the format it
> > > already is, i.e., to convert to 498.
> > > 
> > > I've committed a patch that simply does the null conversion in this case. 
> > > As
> > > I say in the commit message, this seems better than aborting with an 
> > > error.
> > 
> > Thanks for fixing that. I agree with you. I'm not convinced we should
> > have a warning, but I will bring that issue up by replying to the
> > commmit instead of using this email thread for it.
> > 
> > Back to EmbeddedObjects.lyx---it passes with 492 but fails with 491.
> > Does this suggest the format change 491 is the problem or 492? I suppose
> > it is a problem of whether the bug is in backwards conversion or
> > forwards conversion.
> > 
> > The lyx2lyx code in the commit for format 492 is responsible for
> > converting back to 491, so if the bug is in backwards conversion then it
> > is the (likely) problem. On the other hand, if the bug is in forwards
> > conversion, then it seems the commit that introduced 491 is the (likely)
> > root cause. Is that the correct thinking?
> 
> I'm still curious about this question.
> 
> Uwe, can you take a look at this bug? I think it has to do with the 491
> and 492 format changes. If you look at the error, it has to do with
> color. If I remember correctly, the xcolor package is used instead of
> the color package or something like that (not sure that's the underlying
> cause).
> 
> To be clear, the steps to reproduce on master are:
> 
> 1. Open EmbeddedObjects.lyx.
> 2. Export to LyX 2.1.x format.
> 3. Open the file you just exported.
> 4. Try to compile with PDF (pdflatex).
> 
> Scott

Resending but CC'ing Uwe (I forget sometimes you prefer to be emailed
directly).

Scott

Re: [patch] use setProcessEnvironment, not shell escape (cmd / env)

[PhilipPirrip]

Just curious: what and when executes the code in os_win32.cpp 
(os_.cpp in general). Whatever I did to test the patch, these 
functions were not called.

Re: Many tex2lyx failing now on master

[Uwe Stöhr]

Am 26.10.2015 um 21:36 schrieb Vincent van Ravesteijn:


Well yes, there is no "env" command on Windows.


Thanks to Kornel this is now fixed.


Besides that, running is a nightmare:
- Somehow tex2lyx often deadlocks when outputting errors,


Indeed. When I re-run, it works.


- I need to have python in the path,


Thanks, this was important to know. I updated Development.lyx accordingly.


- It complains about not finding git to run "git ls-files"
- I need ssconvert for Gnumeric


Gnumeric dropped the Windows support so we can ignore this.


- It complains that I cannot convert fig formats to pdftex
- and more.


If it is possible, tests that require stuff not available should be 
disabled on Windows. I don't know if this is possible. if not, I can 
life with these errors.


All in all the feature works now for me and i just used it for a simple 
file format change.


many thanks again Vincent and Kornel
Uwe

Re: lyx2lyx bugs from export tests

[Uwe Stöhr]

Am 04.11.2015 um 00:23 schrieb Scott Kostyshak:


Uwe, can you take a look at this bug? I think it has to do with the 491
and 492 format changes.


Thanks for the pointer.

In lyx2lyx I forgot to add the xcolor package to the preamble. This is 
now fixed:

http://www.lyx.org/trac/changeset/493339950737c84c315c5c8cddda0cd32e945791/lyxgit

regards
Uwe

Re: lyx2lyx bugs from export tests

[Scott Kostyshak]

On Wed, Nov 04, 2015 at 01:38:37AM +0100, Uwe Stöhr wrote:
> Am 04.11.2015 um 00:23 schrieb Scott Kostyshak:
> 
> >>Uwe, can you take a look at this bug? I think it has to do with the 491
> >>and 492 format changes.
> 
> Thanks for the pointer.
> 
> In lyx2lyx I forgot to add the xcolor package to the preamble. This is now
> fixed:
> http://www.lyx.org/trac/changeset/493339950737c84c315c5c8cddda0cd32e945791/lyxgit

Thanks for the quick fix, Uwe!

I tested it and it works well. I'll run some more lyx2lyx tests to see
if I can find other bugs.

Scott

Re: getting a test version of lyx 2.2.0 for Mac with Retina display

[Scott Kostyshak]

Hi Vincent,

On Sun, Oct 11, 2015 at 10:54:15PM +0200, Vincent Viguié wrote:
> Dear developer(s)
> I am writing you after reading this thread:
> http://latex-community.org/forum/viewtopic.php?f=19=24987
> First, thank you very much for developing Lyx, a great software which I use
> on a daily basis when writing scientific papers ! Many people in my lab are
> also using it, you're doing a really awesome work :o)

Thanks for the encouragement!

> I have recently changed my computer to take a macbook with a retina display:
> would it be possible to get a test version of lyx 2.2.0 by any chance ?

Yes, I will let you know as soon as we release 2.2.0 alpha. Of course
you should be careful and back everything up and not use it for serious
work.

Scott

> Thank you very much in advance
> Best regards
> -- 
> Vincent Viguié
> 
> CIRED - Centre International de Recherche sur l'Environnement et le
> Développement
> (UMR 8568 CNRS, EHESS, Ecole des Ponts ParisTech, AgroParisTech, CIRAD)
> Site du Jardin Tropical
> 45bis, Av de la Belle Gabrielle
> F-94736 Nogent-sur-Marne
> France
> 
> Mail: vig...@centre-cired.fr
> http://www.centre-cired.fr/spip.php?article842
> 
> >> NEDUM model : http://www.centre-cired.fr/spip.php?article1602

Re: [LyX/master] Add warning message if we do no conversion.

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 08:14:30PM -0500, Richard Heck wrote:
> On 11/01/2015 08:26 PM, Scott Kostyshak wrote:
> >On Sun, Nov 01, 2015 at 08:04:28PM -0500, Richard Heck wrote:
> >>So it would only happen from the command line in which case the warning
> >>can be ignored easily enough.
> >I don't know if I like this asymmetry between GUI and command line.
> 
> All I meant was that LyX never calls lyx2lyx to "convert" a format to
> itself---we check whether the format is the current format before calling
> lyx2lyx---so in that sense the warning isn't relevant to the GUI.

I see what you mean now. Thanks.

Scott

Re: [patch] Finding the generated latex file

[PhilipPirrip]

On 11/03/2015 10:45 AM, Guillaume Munch wrote:

Bad news, it didn't work on Windows. Qt 4.8, VS2010, WinXP/VirtualBox
On Linux, it worked with two AND three slashes: both Qt 4.8 and Qt 5.5;
Gnome 3.18, Fedora 23.


Thanks for the report and the extra step in testing. Please try again
with latest master.


I report that everything works in both WindowsXP and Fedora Linux.
The file browser window showing the temporary folder disappears when LyX 
is closed on Windows, Nautilus in Linux moves to the parent directory.






It opens the directory containing the chosen log — there's really no
trap about it. So I think that "Open Containing Directory" is the
clearest about what is achieved.


OK. What I was saying is that it shows more than just a log file, but no 
problem, what's most important is that it now works.

Re: Test LyX 2.2.0 with Retina display

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 01:52:31PM +0100, Sven Goedeke wrote:
> Hey,
> 
> i would like to test LyX 2.2.0 with Retina display on MBP Retina 13 running 
> OS X 10.10 or 10.11. If possible, please let me know when you have 
> installation files for the development version of 2.2.0 available.

Hi Sven,

Thanks for getting in touch. I will make a note to let you know when we
have 2.2.0 alpha released. Of course you should back up everything be
careful when doing any serious work on an alpha release.

Scott

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Pavel Sanda]

Guillaume Munch wrote:
> For \track_changes, I do not understand your rationale for making it a 
> setting of the document. It is not locked on, so the user who edits the 
> documentations has to know in any case that he should track changes (if I 
> had not been told to, then I'd have turned it off even if it was on).

I consider it also document, not user, setting. It would cause confusions
if this setting is not transfered to my collaborators within the document.

In case it's helpful it should be trivial to change lyx format so that
output_changes & tracking_changes entries are more distant in git diffs.

Pavel

Re: Plan for the current testing situation

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 09:26:07PM +0100, Kornel Benko wrote:
> > It seems to me that the underlying causes of the XeTeX + TeX fonts tests 
> > will
> > not be fixed anytime soon (and that this is OK) so we have two options if we
> > want to clean up the test output. We can either invert the current test
> > failures or ignore all XeTeX TeX font tests. Ignoring the tests means that 
> > they
> > will not be run. Whether we invert or ignore basically depends on how low we
> > think the signal to noise ratio is. I am open to both possibilities, 
> > depending
> > on what others prefer. I do have a preference for inverting the current 
> > tests
> > (and not ignoring).
> 
> I offered a solution already. Test are going to 'revertedTests'.
> Through the file 'suspendedTests' we can select which of them should be 
> suspended.
> 
> That way we have
>   ctest -L export # to run all but suspended tests
>   ctest -L suspended # runs only suspended (which are also inverted)

OK seems reasonable.

Scott

Re: status update on the export tests

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 09:36:02PM +0100, Kornel Benko wrote:
> Am Montag, 2. November 2015 um 21:31:12, schrieb Kornel Benko 
> > Am Montag, 2. November 2015 um 11:21:09, schrieb Kornel Benko 
> > 
> > > Am Montag, 2. November 2015 um 08:36:05, schrieb Guenter Milde 
> > > 
> > > > Dear Scott and Kornel,
> > > > 
> > > > On 2015-11-02, Scott Kostyshak wrote:
> > > > > On Sun, Nov 01, 2015 at 10:36:17PM +0100, Kornel Benko wrote:
> > > > >> Am Sonntag, 1. November 2015 um 21:27:11, schrieb Guenter Milde 
> > > > >> 
> > 
> > ...
> > 
> > > > Candidates for "suspended" tests are 
> > > > 
> > > > * "fragile" documents (many packages, ERT, heavy preamble, ...), 
> > > > * "fragile" export routes (XeTeX/LuaTeX with TeX fonts), 
> > > > * non-default export routes 
> > > > 
> > > > and especially combinations of these.
> > > > 
> > > > 
> > > > Günter
> > > >   
> > > 
> > > OK, here is my suggestion
> > > 1.) We add the appropriate tests into revertedTests
> > > 
> > > The content in suspendedTests may be (in our case) e.g.
> > >   pdf4_texF
> > > 
> > >   1.a)
> > >   If a test is to be inverted, we check suspendedTest, and if 
> > > there, we ignore the testcase.
> > > 
> > > or
> > >   1.b)
> > >   Such a test may became a label "suspended" instead of "export", 
> > > so that
> > >   'ctest -L export' will be clean, but we also have the 
> > > possibility to
> > >   use 'ctest -L suspended'.
> > > 
> > > This does neither effect non-inverted nor ignored.
> > > 
> > > I prefer 1.b.
> > > 
> > 
> > Apparently nobody cares?
> > The attached works here.
> > 
> 
> Forgotten this one in the last post.
> Therefore I resend all.

I don't have much of an opinion on this. Part of me thinks that it adds
extra complication but on the other hand I understand the reasoning. If
you and Günter think it makes sense, then since no one else has an
opinion I would say go ahead. But please document the suspended tests,
what they mean, how to interpret, etc. in Development.lyx. I don't have
enough of an understanding to document it.

Thanks for your work on this! Soon hopefully the tests will be in a good
state.

Scott

> 
>   Kornel

> diff --git a/development/cmake/modules/LyXMacros.cmake 
> b/development/cmake/modules/LyXMacros.cmake
> index 2d20cb7..ea16243 100644
> --- a/development/cmake/modules/LyXMacros.cmake
> +++ b/development/cmake/modules/LyXMacros.cmake
> @@ -322,7 +322,7 @@ macro(settestlabel testname)
>  endmacro()
>  
>  macro(setmarkedtestlabel testname reverted)
> -  if(reverted)
> +  if(${reverted})
>  settestlabel(${testname} "reverted" ${ARGN})
>else()
>  settestlabel(${testname} ${ARGN})

> diff --git a/development/autotests/ExportTests.cmake 
> b/development/autotests/ExportTests.cmake
> index 50b4aa4..c3367a3 100644
> --- a/development/autotests/ExportTests.cmake
> +++ b/development/autotests/ExportTests.cmake
> @@ -137,8 +137,26 @@ endmacro()
>  
>  loadTestList(revertedTests revertedTests)
>  loadTestList(ignoredTests ignoredTests)
> +loadTestList(suspendedTests suspendedTests)
>  
> -foreach(libsubfolder doc examples templates)
> +macro(handlesuspended TestName reverted testlabel)
> +  set(mylabel ${testlabel})
> +  set(myreverted ${reverted})
> +  if (${reverted})
> +# check suspension only for reverted tests
> +findexpr(tfound TestName suspendedTests)
> +if (tfound)
> +  set(mylabel "suspended")
> +  set(myreverted 0) # if test is to be suspended, remove the 'reverted' 
> flag
> +endif()
> +  endif()
> +  setmarkedtestlabel(${TestName} ${myreverted} ${mylabel})
> +endmacro()
> +
> +# preparing to add e.g. development/mathmacro to the foreach() loop
> +foreach(libsubfolderx lib/doc lib/examples lib/templates)
> +  set(LIBSUB_SRC_DIR "${TOP_SRC_DIR}/${libsubfolderx}")
> +  string(REGEX REPLACE "^(lib|development)/" "" libsubfolder 
> "${libsubfolderx}")
>set(LIBSUB_SRC_DIR "${TOP_SRC_DIR}/lib/${libsubfolder}")
>file(GLOB_RECURSE lyx_files RELATIVE "${LIBSUB_SRC_DIR}" 
> "${LIBSUB_SRC_DIR}/*.lyx")
>list(SORT lyx_files)
> @@ -173,7 +191,7 @@ foreach(libsubfolder doc examples templates)
>  -DTOP_SRC_DIR=${TOP_SRC_DIR}
>  -DPERL_EXECUTABLE=${PERL_EXECUTABLE}
>  -P "${TOP_SRC_DIR}/development/autotests/export.cmake")
> -  setmarkedtestlabel(${TestName} ${reverted} "export")
> +  handlesuspended(${TestName} ${reverted} "export") # checking for 
> suspended lyx16 exports
>  endif()
>  if(LYX_PYTHON_EXECUTABLE)
># For use of lyx2lyx we need the python executable
> @@ -188,7 +206,7 @@ foreach(libsubfolder doc examples templates)
>"-DLYX_TESTS_USERDIR=${LYX_TESTS_USERDIR}"
>"-DLYXFILE=${LIBSUB_SRC_DIR}/${f}.lyx"
>-P "${TOP_SRC_DIR}/development/autotests/lyx2lyxtest.cmake")
> -setmarkedtestlabel(${TestName} ${reverted} "lyx2lyx")
> +handlesuspended(${TestName} 

Re: Plan for the current testing situation

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 09:21:23PM +0100, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > So in summary, regarding the XeTeX + TeX fonts, I propose the above policy
> > to start with; and if we find that there really is such a low signal to
> > noise ratio then we can change our minds and ignore them. But we will
> > never know what the signal to noise ratio is if we just ignore them now.
> 
> This does all make sense (including the snipped part). Nevertheless I'd like 
> to propose that we put some intermediate steps in:
> 
> 1) Fix the first half of bug #9744. This is an easy and safe change which 
> has the additional benefit to make most of Günters concerns about the "View 
> XeTeX" toolbar button much less important. Also, if we do not do it before 
> 2.2.0, we cannot do it for 2.2.x (file format change). Günter, maybe you 
> want to have a try yourself (if Scott agrees to do this before 2.2.0)?

I see. Seems like it would have a good benefit. Would indeed be nice to
have in 2.2.0 beta.

> 2) Set the new "automatic" value for "use non-TeX fonts" for all documents 
> that should work with XeTeX in principle
> 
> 3) Re-evaluate the test status and decide then whether some tests do still 
> need to be suspended or inverted.
> 
> My guess would be that after these three steps, the tests would be much more 
> usable, and that the tests that do then still fail would point to real 
> problems which should not be ignored.

OK so we will hold of from inverting tests, it seems you are suggesting.
I'm fine with that.

Scott

Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

[Kornel Benko]

Am Dienstag, 3. November 2015 um 12:40:22, schrieb Guenter Milde 

> On 2015-11-02, Scott Kostyshak wrote:
> > On Mon, Nov 02, 2015 at 10:40:27PM +, Guenter Milde wrote:
> 
> Dear Scott,
> 
> >> > thanks for the patch.
> 
> >> I modified it to use UTF8 with XeTeX without the 
> >> \inputencoding commands. 
> 
> ...
> 
> > I would say go ahead and commit if you are satisfied with it. From what I
> > understand, the patch is now a complete patch in the sense that it is a full
> > step forward. 
> 
> Actually, I am not satisfied, because the "normal" use case (exporting to a
> LaTeX file with inputencoding ASCII) is now worse than before. I this sense,
> it is a partial patch.
> 
> For the use case "XeTeX with TeX fonts", it is overly complicated.
> 
> So I split it in two:
> 
> * to fix the regressions with "XeTeX + TeX fonts", a simple change in
>   PDFOptions.cpp is sufficient. See below.
>   
>   The nice thing is, that this is simple, localized and only changes
>   where change is required - actually a completion for the patch-set
>   fixing #9740.
> 
>   >> A short test here showed that this
>   >> helps with Umlauts or Cyrillic charactes in the PDF Info.
> 
> * the updated "comprehensive but incomplete" patch based on your work is now
>   at http://www.lyx.org/trac/ticket/9839, so the work is not lost.
>   
>   With the "show output anyway" option in 2.2, the status quo is actually
>   tolerable. I'll try the patch for #9830, then there is also a workaound for
>   ASCII export (i.e. the user can write G\"unter instead of Günter).
> 
> 
> > Let me know if you want me to run the export tests before/after.
> 
> Please check, if this patch cures some regressions introduced by
> fixing #9740.

Check with 'ctest -L suspended' (my local version)
Now the following tests (previously not passing) pass:
390 - INVERTED_SEE-README.ctest_export/doc/Math_pdf4_texF (Failed)
702 - INVERTED_SEE-README.ctest_export/doc/de/Math_pdf4_texF (Failed)
870 - INVERTED_SEE-README.ctest_export/doc/es/Math_pdf4_texF (Failed)
1052 - INVERTED_SEE-README.ctest_export/doc/fr/Math_pdf4_texF (Failed)
1787 - INVERTED_SEE-README.ctest_export/examples/PDF-comment_pdf4_texF 
(Failed)

They can now be removed from revertedTests.

checking now with 'ctest -L export -E '(lyx16|xhtml)$'
-> 94% tests passed, 179 tests failed out of 3041

That is, 29 tests are now better than before.
Checking the output, all 29 are of type pdf4_texF (XeTeX + TeX fonts).

I'd say, please commit.

> Günter

Kornel

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

Re: Unit testing

[Vincent van Ravesteijn]

On Tue, Nov 3, 2015 at 2:28 PM, Jean-Marc Lasgouttes  wrote:
> Le 02/11/2015 21:36, Vincent van Ravesteijn a écrit :
>>
>> Dear all,
>>
>> I have prepared a unit test framework based on google-test (gtest). You
>> can see the commits at
>>
>> http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests.
>> It includes gtest-1.7.0 (permitted by the license).
>
>
> Hi Vincent,
>
> What is the difference with the tests we current use (I mean the "make
> check" sort). The same but with better interface?
>
> JMarc
>

The current tests are all different executables, which is not really
optimal for speed in compilation and execution and has some overhead.
Now they all appear as different targets here and there. Using a test
framework also gives you a bunch of tools for writing tests (automatic
preparation and cleanup of objects, mocking, etc.). Then it gives you
the statistics and the ability to easily select tests you want to run,
etc.

Maybe, more importantly, having a proper framework may ignite the
spirit of creating tests, which then might become a new habit.

Vincent

Re: [patch] Finding the generated latex file

[Stephan Witt]

Am 03.11.2015 um 16:36 schrieb Guillaume Munch :

> Le 03/11/2015 08:59, Stephan Witt a écrit :
>> Am 03.11.2015 um 04:58 schrieb Guillaume Munch > >:
>> 
>>> Le 02/11/2015 18:38, Guillaume Munch a écrit :
 Le 28/10/2015 16:39, Ilan a écrit :
> Thanks David and Stephan.
> 
> My problem is that I'm working on a multi-file project so under the tmp
> directory there are several directories and the location of the Latex
> file
> depends on the file I compiled (and of course the tmp directory has a
> different
> name each time under windows).
> 
> What I used to do until few months ago is opening the Latex log, and
> there I
> saw the full path to the compiled file, so I could copy it to a Latex
> editor.
> After some updates to Lyx & Latex, I see in the log only the file name
> without
> the path.
> 
> I can (and this is what I do) to find the current tmp directory and then
> searching for all the Latex files to find the right one by its name.
> I hoped there is an option to return to the previous state of easily
> finding
> the directory with a click.
> 
> 
 
>>> 
>>> 
>>> Pushed at f441590c. Windows/OSX users, please report if it does not work.
>> 
>> It works for me on OSX. Although I'd expect user questions regarding the
>> attached error message on exit of LyX:
>> "Cannot remove temporary directory…" or similar…
>> 
> 
> 
> Do you mean that the patch now causes this error message? Under which
> circumstances precisely? Is it that if the directory is open in the
> finder, then LyX cannot remove the directory? (Under Linux, Nautilus's
> behaviour is to move to the parent directory if the current directory is
> deleted.)

Yes, the error is displayed by LyX because it cannot remove the temporary
directory while it is shown in the Finder (the Nautilus of OSX).

I'd guess this is the common scenario for the average user:
check the LaTeX log, use the button, switch back to LyX and finally exit LyX -
which raises the mentioned error message and leaves the empty temporary
directory in file system.

It's not the patch causing the error message - it's easier to get it with the
patch.

Stephan

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

[Kornel Benko]

Am Dienstag, 3. November 2015 um 15:32:34, schrieb Guillaume Munch 

> Le 03/11/2015 07:35, Kornel Benko a écrit :
> > Am Dienstag, 3. November 2015 um 04:57:45, schrieb Guillaume Munch 
> > 
> >> commit f441590c8e0b5e970fbdd656198ec4993dfecb43
> >> Author: Guillaume Munch 
> >> Date:   Mon Nov 2 18:19:40 2015 +
> >>
> >>  Add "Open Containing Directory" button to the log dialog (#9211, 
> >> #9834)
> >>
> >>  It takes the place of the "Copy to Clipboard" button which was 
> >> redundant.
> >>
> >
> > The 'Open Containing Directory' button displays an empty window here.
> > The displayed path is correct, but the window looks like it belongs to 
> > 'gvim' (text editor).
> >
> > Is this really intended?
> >
> 
> Please test again at a0783e15. But if the displayed path is really
> correct, I am afraid it does not fix it.
> 
> If after that it still opens gvim, there isn't much that can be done on
> the programmer's side since Qt is supposed to handle things. It seems
> to be the recommended cross-platform method to open a directory. Then it
> might be a configuration issue on your side. For instance, what does
> "xdg-open " achieve on your system?
> 

It is the same, opens with gvim. But in the mean time I learned a new gvim 
command ':Ex[plore]', which
shows the content of this directory. And one can select files (e.g. click on 
filenames) and open them.

For me it is OK ...

> 
> Guillaume

Kornel



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

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

[Guillaume Munch]

Le 03/11/2015 16:10, Kornel Benko a écrit :


It is the same, opens with gvim. But in the mean time I learned a new gvim 
command ':Ex[plore]', which
shows the content of this directory. And one can select files (e.g. click on 
filenames) and open them.

For me it is OK ...



OK. Only thing is that I would be reassured to know that there is indeed
a setting in your system that determines that gvim must be chosen as a
file browser on purpose…



Guillaume


Kornel


Guillaume

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

[Kornel Benko]

Am Dienstag, 3. November 2015 um 16:14:55, schrieb Guillaume Munch 

> Le 03/11/2015 16:10, Kornel Benko a écrit :
> >
> > It is the same, opens with gvim. But in the mean time I learned a new gvim 
> > command ':Ex[plore]', which
> > shows the content of this directory. And one can select files (e.g. click 
> > on filenames) and open them.
> >
> > For me it is OK ...
> >
> 
> OK. Only thing is that I would be reassured to know that there is indeed
> a setting in your system that determines that gvim must be chosen as a
> file browser on purpose…

Not that I was aware about. I never used gvim to browse for files. Using 
dolphin, nautilus, sometimes caja.

But I have seen entries in lyxrc.default
# egrep -w gvim lyxrc.defaults|wc
--> 79
But no one of the entries looks like a directory format.
Hm, I now checked the configuration... you are right. 
Now caja is called. Thanks.

> >>
> >> Guillaume
> >

Kornel

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

Re: [patch] Finding the generated latex file

[Guillaume Munch]

Le 03/11/2015 16:16, Stephan Witt a écrit :

Am 03.11.2015 um 16:36 schrieb Guillaume Munch :


Do you mean that the patch now causes this error message? Under which
circumstances precisely? Is it that if the directory is open in the
finder, then LyX cannot remove the directory? (Under Linux, Nautilus's
behaviour is to move to the parent directory if the current directory is
deleted.)


Yes, the error is displayed by LyX because it cannot remove the temporary
directory while it is shown in the Finder (the Nautilus of OSX).

I'd guess this is the common scenario for the average user:
check the LaTeX log, use the button, switch back to LyX and finally exit LyX -
which raises the mentioned error message and leaves the empty temporary
directory in file system.

It's not the patch causing the error message - it's easier to get it with the
patch.



So the error message is valid. The solution would be to make it clearer. 
Maybe one could show a better message depending on the failure. If it's 
"resource busy" then we could add to the message something like "The 
directory might be currently in use in a different program".



Guillaume

Re: [patch] Finding the generated latex file

[Guillaume Munch]

Le 03/11/2015 16:39, Guillaume Munch a écrit :

Le 03/11/2015 16:16, Stephan Witt a écrit :

Am 03.11.2015 um 16:36 schrieb Guillaume Munch :


Do you mean that the patch now causes this error message? Under which
circumstances precisely? Is it that if the directory is open in the
finder, then LyX cannot remove the directory? (Under Linux, Nautilus's
behaviour is to move to the parent directory if the current directory is
deleted.)


Yes, the error is displayed by LyX because it cannot remove the temporary
directory while it is shown in the Finder (the Nautilus of OSX).

I'd guess this is the common scenario for the average user:
check the LaTeX log, use the button, switch back to LyX and finally
exit LyX -
which raises the mentioned error message and leaves the empty temporary
directory in file system.

It's not the patch causing the error message - it's easier to get it
with the
patch.



So the error message is valid. The solution would be to make it clearer.
Maybe one could show a better message depending on the failure. If it's
"resource busy" then we could add to the message something like "The
directory might be currently in use in a different program".




BTW while testing whether the button worked with spaces in the path, I 
noticed that LyX fails to delete the temporary folder with the message 
"/tmp/temp dir with spaces does not look like a LyX temporary directory" 
when there are spaces in the path.