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

[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'd rather call this a bug in the script than in setProcessEnvironment and
> QProcess. Why would they need to guess what shell they have to execute.

The default shell. As is done when setProcessEnvironment is not called.

> Isn't it polite, at least, for each shell script to have a shebang line?
> http://unix.stackexchange.com/questions/87560/does-the-shebang-determine-the-shell-which-runs-the-script

It is perfectly legal to not have a shebang line and sometimes this is even
necessary. The shebang line must contain an absolute path to the shell that
has to interpret the script. These paths may vary among platforms, so one
can construct a first line that simply reexecutes the script with the
wanted shell located anywhere in the PATH variable. This is what the
"myprog" example script does: it will execute the script using the first
perl interpreter found in PATH. This is not something theoretical and it
seems it is the way texlive scripts are executed, as discussed here:
http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg169646.html

> Does the same 'bug' happen on Windows, or is this only for the shell 'bugs'
> on *nix?

A similar bug affects Windows, because batch files are not executed by
QProcess.

> Fail: "Exec format error"  in your test example only points to the fact that
> QProcess does not know it's supposed to spawn a shell and execute the script
> in it, nothing more.

No, it means that QProcess doesn't take into account the way a script
can be executed on a given platform. See the link below.

> If instead of myprog script you had a real binary executable (like
> proc->start("/usr/bin/ls") or proc->start("/usr/bin/env")) no "Exec format
> error" would appear in either case. Why?

Because QProcess is buggy:
http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg169634.html

> >>It maybe does not execute cmd_ if cmd_="some.bat", but will execute
> >>cmd_="cmd.exe /c some.bat". The shell will (hopefully) have the environment
> >>variables set by setProcessEnvironment().
> >>(bat files are not executables by themselves, are they? windows, when you
> >>click on them, starts them by opening cmd.exe first)
> >>This just means that some.bat is not a good cmd, and should be changed to
> >>"cmd.exe /c some.bat"
> >>(now... who and where uses .bat's?)
> >
> >Now I hope you are joking. What would you think if you had to call a
> >converter of yours as "bash myscript" instead of simply "myscript"?
> >Do you expect to have to do that?
> 
> Well, isn't that what Windows does?

No, it will happily execute any file whose extension is listed in PATHEXT:

C:\> echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

Here, the extension plays the same role of a shebang line.

> Isn't that why you had to go back to
> using QProcess when calling a viewer on Windows instead of the script...

No.

> You didn't want that black window to pop out, right?

This can be avoided by other means than using QProcess, which didn't
solve any real problem but only introduced new ones.

> bat files are not
> executables, they can be executed... by an executable, which is in this case
> cmd.exe.

Reasoning along these lines, it also holds true for *nix scripts.

> How many faulty converters are there in LyX? Why do they have to be run the
> same way LaTeX are, by using latexEnvCmdPrefix? Does evince (pdf
> viewer) really need TEXINPUTS variable that gets set by using
> latexEnvCmdPrefix?

There are converters that actually need to be run with the same
environment as the TeX engine. We cannot say which ones they are,
so we should assure that they run with the proper environment set.

> >Batch files are executable and you don't have to type "cmd /c some.bat"
> >to execute them but simply "some". The "cmd /c" prefix is necessary to
> >overcome the silly limitations imposed by QProcess.
> 
> 
> You type some, but Windows has to spawn a shell, cmd.com, to execute it.
> some.bat has no binary code in it, and it is not executable in that sense.

And linux has to do exactly the same in order to run a script.

> Anway... some of the developers here assumed TEXINPUTS covers even bib
> files. (see the posts on \input@path) I wouldn't mind if BIBINPUTS were not
> even configurable, make them . and the current document directory.
> I don't see why this is such a big deal. It's even standard latex behavior,
> it always searches in the current dir. The trouble with LyX is that it
> compiles in a temp dir, but does not copy any files it does not know of.

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 

[patch] Finding the generated latex file

[Guillaume Munch]

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?


Guillaume
>From 7f97044ddbe67ccd83c6460878045aabf134c443 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Mon, 2 Nov 2015 18:19:40 +
Subject: [PATCH] Add "Open directory..." button to the log dialog.

Proof of concept.
---
 src/frontends/qt4/GuiLog.cpp  |  17 +
 src/frontends/qt4/GuiLog.h|   2 +
 src/frontends/qt4/ui/LogUi.ui | 150 ++
 3 files changed, 98 insertions(+), 71 deletions(-)

diff --git a/src/frontends/qt4/GuiLog.cpp b/src/frontends/qt4/GuiLog.cpp
index 14e7aaf..1db6f99 100644
--- a/src/frontends/qt4/GuiLog.cpp
+++ b/src/frontends/qt4/GuiLog.cpp
@@ -24,8 +24,10 @@
 #include "support/FileName.h"
 #include "support/gettext.h"
 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -189,6 +191,21 @@ void GuiLog::on_nextWarningPB_clicked()
 }
 
 
+void GuiLog::on_openDirPB_clicked()
+{
+	support::FileName dir = logfile_.onlyPath();
+	QUrl qdir(toqstr(from_utf8("file://" + dir.absFileName())),
+			  QUrl::StrictMode);
+	if (dir.exists()) {
+		// Give hints in case of bugs
+		if (!qdir.isValid())
+			LYXERR0("QUrl is invalid!");
+		if (!QDesktopServices::openUrl(qdir))
+			LYXERR0("Unable to open QUrl although dir exists.");
+	}
+}
+
+
 void GuiLog::goTo(QRegExp const & exp) const
 {
 	QTextCursor const newc =
diff --git a/src/frontends/qt4/GuiLog.h b/src/frontends/qt4/GuiLog.h
index 2a9ebb6..8159836 100644
--- a/src/frontends/qt4/GuiLog.h
+++ b/src/frontends/qt4/GuiLog.h
@@ -41,6 +41,8 @@ private Q_SLOTS:
 	void on_nextErrorPB_clicked();
 	/// jump to next warning
 	void on_nextWarningPB_clicked();
+	/// open containing directory
+	void on_openDirPB_clicked();
 	/// Log type changed
 	void typeChanged(int);
 
diff --git a/src/frontends/qt4/ui/LogUi.ui b/src/frontends/qt4/ui/LogUi.ui
index ddf6ebc..6a4f49b 100644
--- a/src/frontends/qt4/ui/LogUi.ui
+++ b/src/frontends/qt4/ui/LogUi.ui
@@ -1,60 +1,68 @@
-
+
+
  LogUi
- 
-  
+ 
+  

 0
 0
-421
+454
 474

   
-  
+  

   
-  
+  
true
   
-  
-   
+  
+   
 9

-   
+   
 6

-   
-
- 
+   
+
+ 
+  Copy to Clipboard
+ 
+
+   
+   
+
+ 
   Find:
  
- 
+ 
   findLE
  
 

-   
-
- 
+   
+
+ 
   Hit Enter to search, or click Go!
  
 

-   
-
- 
+   
+
+ 
   Log Type:
  
- 
+ 
   logTypeCO
  
 

-   
+   
 
- 
+ 
   Qt::Horizontal
  
- 
+ 
   
161
20
@@ -62,41 +70,41 @@
  
 

-   
-
+   
+

-   
-
+   
+

-   
-
- 
+   
+
+ 
   Update the display
  
- 
+ 
   Update
  
- 
+ 
   true
  
 

-   
-
- 
+   
+
+ 
   Close
  
 

-   
+   
 
- 
+ 
   Qt::Horizontal
  
- 
+ 
   QSizePolicy::Expanding
  
- 
+ 
   
111
26
@@ -104,53 +112,53 @@
  
 

-   
-
- 
-  Copy to Clipboard
- 
-
-   
-   
-
- 
-  Qt::Horizontal
- 
- 
-  
-   201
-   20
-  
- 
-
-   
-   
-
- 
+   
+
+ 
   Go!
  
 

-   
-
- 
+   
+
+ 
   Jump to the next warning message.
  
- 
+ 
   Next Warning
  
 

-   
-
- 

Re: Any alpha blockers?

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 05:57:37PM -0800, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
> > Note that we missed LyX 20th birthday: while Lyrix was released circa July 
> > 1995, the first real LyX release probably happened in september 1995. The 
> > first long-lived version was 0.7, which got released at the end of 
> > september.
> >
> > Source: http://www.lyx.org/misc/archaeology/lyx-time.html
> 
> Time to sell shirts and mugs :)

Wow LyX is getting old. We should draw some grey hairs on "The LyX" [1].

Scott

[1] http://wiki.lyx.org/uploads/LyX/Logotype/lyx.png
> P

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

[PhilipPirrip]

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 ;)

Re: Any alpha blockers?

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 11:37:06AM +0100, Jean-Marc Lasgouttes wrote:
> Le 02/11/2015 03:42, Scott Kostyshak a écrit :
> >Does anyone have an issue that they think should be considered as an
> >alpha blocker?
> 
> Not me. Let's get this alpha out!

Sounds good. I should have time on Wednesday to go through the
tar-building process. I will read the docs we have on the release
process and ask if I have questions (I'm sure I will).

Scott

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

[Enrico Forestieri]

On Mon, Nov 02, 2015 at 12:26:36PM -0500, PhilipPirrip wrote:

> On 11/02/2015 10:44 AM, Enrico Forestieri wrote:
> >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.
> 
> Oh no, no, you're wrong. This is what I received from one of the well known
> developers: "Enrico is the Jedi Master of such things. I'd suggest you
> re-send this just to him."

You mean like Yoda? I don't know whether to feel flattered or offended ;)

> >>Anway... some of the developers here assumed TEXINPUTS covers even bib
> >>files. (see the posts on \input@path) I wouldn't mind if BIBINPUTS were not
> >>even configurable, make them . and the current document directory.
> >>I don't see why this is such a big deal. It's even standard latex behavior,
> >>it always searches in the current dir. The trouble with LyX is that it
> >>compiles in a temp dir, but does not copy any files it does not know of.
> >
> >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.

> Philip Pirrip wrote on 2015-09-02:
> > Since the way \input@path is being used in the biblatex hack from
> > http://wiki.lyx.org/BibTeX/Biblatex is barely legal, maybe LyX should
> > define its own command, say \LyX@basepath that'd contain the absolute
> > path to the master .lyx document (no qoutes, no curly braces - only for
> > the brave).
> > Would you be willing to do that? (being that biblatex support is nowhere
> > on the horizon yet)
> 
> Georg: After all these discussions it is clear that something like this is
> needed.
> However, I do not want to clutter all documents with that (since 95% of the
> users don't need it). I would prefer a solution where we extend the layout
> definition language so that you could use a placeholder that will be
> replaced by LyX with the master document path. Then everybody who needs this
> path could write a module that pulls in the path into a LaTeX macro in the
> most simple case, or in more advanced cases it could directly be used in the
> preamble code that needs it.

I still think this is not necessary. Instead of fiddling with \input@path,
if you are willing to add the --enable-write18 option to your call for
latex, the following lines in the preamble should do the trick:

\usepackage{catchfile,ifplatform}
\immediate\write18{kpsewhich --var-value=TEXINPUTS > \jobname.tmp}
\CatchFileDef{\temp}{\jobname.tmp}{\endlinechar=-1}
\ifwindows
  \def\getdocdir#1;#2;#3;#4\next{\gdef\docdir{#3}}
\else
  \def\getdocdir#1:#2:#3\next{\gdef\docdir{#2}}
\fi
\expandafter\getdocdir\temp\next

After that, you have the path to the document dir in the macro \docdir.
The only catch is that TEXINPUTS might be customized, but then one
could use BIBINPUTS instead, if the patch is accepted.

-- 
Enrico
diff --git a/src/support/filetools.cpp b/src/support/filetools.cpp
index 204c842..310e621 100644
--- a/src/support/filetools.cpp
+++ b/src/support/filetools.cpp
@@ -710,8 +710,12 @@ string latexEnvCmdPrefix(string const & path, string const 
& lpath)
string texinputs_prefix = lyxrc.texinputs_prefix.empty() ? string()
: os::latex_path_list(
replaceCurdirPath(path, lyxrc.texinputs_prefix));
+   string const allother_prefix = os::latex_path_list(path);
string const sep = string(1, os::path_separator(os::TEXENGINE));
string const texinputs = getEnv("TEXINPUTS");
+   string const bibinputs = getEnv("BIBINPUTS");
+   string const bstinputs = getEnv("BSTINPUTS");
+   string const texfonts = getEnv("TEXFONTS");
 
if (use_lpath) {
string const abslpath = FileName::isAbsolute(lpath)
@@ -727,13 +731,28 @@ string latexEnvCmdPrefix(string const & path, string 
const & lpath)
 
if (os::shell() == os::UNIX)
return "env TEXINPUTS=\"." + sep + texinputs_prefix
- + sep + texinputs + "\" ";
+  + sep + texinputs + "\" "
++ "BIBINPUTS=\"." + sep + allother_prefix
+  + sep + bibinputs + "\" "
++ "BSTINPUTS=\"." + sep + allother_prefix
+  + sep + bstinputs + "\" "
++ "TEXFONTS=\"."  + sep + allother_prefix
+   

Re: bug 9626: new handling of "LyX" is unintuitive

[Georg Baum]

Richard Heck wrote:

> On 10/25/2015 07:43 AM, Kornel Benko wrote:
>> Am Sonntag, 25. Oktober 2015 um 12:04:36, schrieb Georg Baum
>> 
>>> PhilipPirrip wrote:
>>>
 LibreOffice has it as "Special Characters". Fedora Linux has an
 application called "Character Map" that lists characters by, I believe,
 unicode blocks.
 And all those are just single characters. Symbols, though, can be one
 or more: Greek alpha or \LaTeX
 Just my 5 cents.
>>> After thinking more about this I now think it makes sense. I did also
>>> implement the documentation toolbar. I think the toolbar should
>>> definitely go in.
>> I like it.
> 
> Me too.
> 
>>> What do others think about the renaming?
>> Having this extra toolbar, I'd like to have the logos available also
>> under "Insert->Special Character->Logos->{LyX,TeX,LaTeX,LaTeX2e} Logo"
>>
>> I.e. new "Logos" submenu for the logos. Just my 1 cent.
> 
> This seems like an excellent idea.

I did this at d56980da954d.


>> "Special Character" itself feels OK. Maybe also "Special Symbols" ...
> 
> LibreOffice has Insert> Special Character, and that gets you to the
> dialog that our Insert> Special Character > Symbols... does. But we kind
> of break out some of the more common choices and put them on the
> submenu, so "Special Character" seems consistent to me. What makes less
> sense to me is that use of "Symbols..." for what gets you to the dialog.
> I think maybe "Symbol Chooser..." would make it clearer what this was
> going to do.

Since it looks like the majority wants to keep "Special Character", and 
there does not seem to be a consensus concerning "Symbols...", and changing 
the names would mean a lot of work in the docs, I do not want to change 
these two right now. Nevertheless, I'll consider bug 9626 now as fixed.


Georg

Re: Plan for the current testing situation

[Kornel Benko]

Am Sonntag, 1. November 2015 um 22:41:39, schrieb Scott Kostyshak 

> Thanks to all of those participating in the discussions about tests. I have
> learned a lot the last couple of weeks. Thank you also to those who have tried
> to run the tests. This to me is a great step forward. I know that the export
> tests are sloppy cheap tests, but I appreciate that some of you agree that 
> they
> do have use, at least until we have unit testing. The question now is, how can
> we get the most use out of them and how can we maximize their signal to noise
> ratio?
> 
> Ideally, I would like for commits that break tests to be on a separate git
> branch. Once the bugs exposed by a commit are fixed or the tests are fixed, or
> the .lyx files are fixed, then the branch could be merged to master. This
> allows us to presere a "0 failing tests" situation on the master branch so it
> is extremely easy to catch regressions. So my preferred policy would be: if a
> commit is found to have broken a test, either the situation is resolved within
> a day (i.e. the bug is fixed or the test is fixed) or the commit is reverted
> (and perhaps pushed to a separate remote branch). The only way I think there
> will be support for this policy is if the tests are not fragile. If tests
> commonly break even though a commit does not introduce a real bug, then this
> policy would just create a lot of pain without much use. I think that
> non-fragile export tests are a real possibility, but some changes might be
> needed to achieve this.

+1
But as you said, 'ideally'.

> Back from my dream world, the problem with the current situtation is that so
> many tests are failing (200 or so) that it makes it difficult to see if there
> are new regressions. Especially as we move forward in the release process,
> catching new regressions is extremely important. I thus propose some temporary
> measures to get a clean test output. I think that the tests that are failing
> because of known bugs should be inverted. For example, the tests that are
> failing because of the change from babel to polyglossia could be inverted and
> marked with the reason why they are inverted, and referred to in a bug report.
> Georg (who did not introduce the regressions but is kindly working on them) is
> aware of the failing tests, and is also working on better tests that are
> specific to testing language nesting, so in some sense the tests have already
> done their job and we should move on for now.

+1

> A source of fragile tests is the XeTeX tests with TeX fonts. Günter has 
> pointed
> out that exporting using XeTeX and TeX fonts could go from succeeding to
> failing because of an added package, addition of one non-ASCII character, 
> babel
> language files, font problems, and other issues. Further, we should not expect
> that many users are using XeTeX with TeX fonts because it is not common (there
> is a separate discussion we are having on discouraging such a combination).
> Thus, a good question is should we even have tests for this combination?

IMHO yes. Even if they may be 'suspended'. At least even XeTeX may evolve and 
the tests
are ready to wake up.

> 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)

> I'm not convinced that the signal to noise ratio is *so*
> low. If there is a significant chance that these tests will catch bugs that 
> our
> other tests should not, they should be kept. I thus propose to invert the
> current failures (and specify the reason each is failing) and then to treat
> future XeTeX TeX font failures as failures of fragile tests. In some sense,
> fragile tests can be OK if we know they are fragile and treat them as such. We
> could amend our policy to be such that if XeTeX + TeX font tests fail, the
> author of the commit that broke them can simply invert them without having the
> responsibility of fixing them. The advantage of still keeping them (and not
> "ignoring" them) is that the author of the commit might realize "my commit
> should not have broken these tests" and thus find a bug in the commit. For
> example, many commits do not even intend to change LaTeX. You might think that
> other tests 

Re: lyx2lyx bugs from export tests

[Georg Baum]

Richard Heck wrote:

> I think it would be a perfectly reasonable requirement from now on
> ---say, starting in the 2.3.x development cycle---that every format
> change be accompanied by some kind of test file that illustrates the use
> of the new feature (that's what it usually is) and that can be used to
> test lyx2lyx's conversions. The more aspects of the feature the file
> exercises, the better.

+1


Georg

Re: Plan for the current testing situation

[Georg Baum]

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)?

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.


Georg

Re: status update on the export tests

[Kornel Benko]

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.

Korneldiff --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} ${reverted} "lyx2lyx")
   endif()
 endif()
 set(TestName "check_load/${libsubfolder}/${f}")
@@ -202,7 +220,7 @@ foreach(libsubfolder doc examples templates)
 -DPARAMS_DIR=${TOP_SRC_DIR}/development/autotests
 -DWORKDIR=${CMAKE_CURRENT_BINARY_DIR}/${LYX_HOME}
 -P "${TOP_SRC_DIR}/development/autotests/check_load.cmake")
-  setmarkedtestlabel(${TestName} ${reverted} "load")
+  handlesuspended(${TestName} ${reverted} "load")
   set_tests_properties(${TestName} PROPERTIES RUN_SERIAL ON)
 endif()
 getoutputformats("${LIBSUB_SRC_DIR}/${f}.lyx" formatlist)
@@ -234,7 +252,7 @@ foreach(libsubfolder doc examples templates)
 -DTOP_SRC_DIR=${TOP_SRC_DIR}
 -DPERL_EXECUTABLE=${PERL_EXECUTABLE}
 -P 

Unit testing

[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

#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: [patch] use setProcessEnvironment, not shell escape (cmd / env)

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 09:16:41PM +0100, Enrico Forestieri wrote:
> On Mon, Nov 02, 2015 at 12:26:36PM -0500, PhilipPirrip wrote:
> 
> > On 11/02/2015 10:44 AM, Enrico Forestieri wrote:
> > >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.
> > 
> > Oh no, no, you're wrong. This is what I received from one of the well known
> > developers: "Enrico is the Jedi Master of such things. I'd suggest you
> > re-send this just to him."
> 
> You mean like Yoda? I don't know whether to feel flattered or offended ;)

It is indeed ambiguous. Darth Vader was also a jedi I believe... :)

Scott

Re: status update on the export tests

[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.

Korneldiff --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} ${reverted} "lyx2lyx")
   endif()
 endif()
 set(TestName "check_load/${libsubfolder}/${f}")
@@ -202,7 +220,7 @@ foreach(libsubfolder doc examples templates)
 -DPARAMS_DIR=${TOP_SRC_DIR}/development/autotests
 -DWORKDIR=${CMAKE_CURRENT_BINARY_DIR}/${LYX_HOME}
 -P "${TOP_SRC_DIR}/development/autotests/check_load.cmake")
-  setmarkedtestlabel(${TestName} ${reverted} "load")
+  handlesuspended(${TestName} ${reverted} "load")
   set_tests_properties(${TestName} PROPERTIES RUN_SERIAL ON)
 endif()
 getoutputformats("${LIBSUB_SRC_DIR}/${f}.lyx" formatlist)
@@ -234,7 +252,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") # check for suspended pdf/dvi exports
 endif()
   endforeach()
 endforeach()
INV.*pdf4_texF


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

Re: Any alpha blockers?

[Guenter Milde]

Dear Scott,

On 2015-11-02, Scott Kostyshak wrote:

> In fact, at some point (I guess for 1.6?) the criteria for going from
> beta to RC was that there is no dataloss bug. The only dataloss bug
> with a 2.2.0 milestone is #9362.

I don't think it is an alpha blocker, but #9830 is in fact a dataloss bug:

* go to Document>Settings>PDF Properties>General Header Information) 

* activate Hyperref support (if not already active) 

* insert text with a ", e.g. 

 print("hello world")

  in the title field.
  
* Save

* Reopen

* Export to PDF: the title will be

 print(

Actually, the part `"hello world"` is already lost when closing the
Document>Settings dialogue, as it is not stored in the LyX file
but you will normally not realize this.


Besides this, #9830 prevents us from making documents more robust avoiding
non-ASCII characters in the PDF Header Information
(e.g. replacing Stöhr with St\"{o}hr) to solve some export test issues.


Günter

Re: status update on the export tests

[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 
>> 

>> > Could we introduce a new status "suspended" - meaning just skip the
>> > test until a known bug is solved as we know the result is
>> > insignificant until then?

> As Kornel mentions, we have "ignoredTests" for this.

Not exactly, see below.

>> We already have such (specified in file "ignoredTests"). But as this
>> tests are never executed, nobody cares for them anymore.
>> The tests here are such, that we know, we never resolve them.

> I agree. We should not use ignored tests for temporary issues. Once we
> put something in ignoredTests chances are strong that we will forget
> about them for a long time.

This is why I said "suspended": 

Suggestion:

  Specified in file "suspendedTests") with the reason for suspending
  (bug report, commit that turned hidden problems into export failure, ...)
  
  These tests are normally skipped, but they are not forgotten.
  
  The tests here are such, that we know, we can resolve them but their
  failure is a minor issue that can be postponed (comparable to enhancement
  requests in Trac).
  
  Suspending instead of reverting also frees us from the need to reassess
  them if a change in the "real life documents" or a fix makes them pass
  again. Instead, they could/should be revised at a time we have fixed
  major known problems and no release pressure...
  
  
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
  
  
  

Re: status update on the export tests

[Guenter Milde]

On 2015-11-02, Scott Kostyshak wrote:

> Good point. On the other hand, if we make regex changes then it is
> harder to revert them. Problems have come up before of us
> misconstructing the regexes.

If possible, make separate regexp patterns for separate "fail reasons".
Then, we just have to delete one regexp if the cause for the inversion is
gone...

Günter

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

[PhilipPirrip]

On 11/02/2015 10:44 AM, Enrico Forestieri wrote:

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.


Oh no, no, you're wrong. This is what I received from one of the well 
known developers: "Enrico is the Jedi Master of such things. I'd suggest 
you re-send this just to him."

I'd say they all trust your judgment.



You type some, but Windows has to spawn a shell, cmd.com, to execute it.
some.bat has no binary code in it, and it is not executable in that sense.


And linux has to do exactly the same in order to run a script.


With one difference: windows has one single shell, and linux - how 
many?, half a million?





Anway... some of the developers here assumed TEXINPUTS covers even bib
files. (see the posts on \input@path) I wouldn't mind if BIBINPUTS were not
even configurable, make them . and the current document directory.
I don't see why this is such a big deal. It's even standard latex behavior,
it always searches in the current dir. The trouble with LyX is that it
compiles in a temp dir, but does not copy any files it does not know of.


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.







BTW; I once before suggested there should be a command similar to 
\input@path defined, that will contain the path to the current document 
folder with absolutely no latex formatting in it.
That could be used in modules for LaTeX packages that have no support in 
LyX. The fact that LyX compiles its documents in a temp folder makes the 
implementation of such (underground, but still) enhancements very hard. 
Georg, are you reading this?



Philip Pirrip wrote on 2015-09-02:
> Since the way \input@path is being used in the biblatex hack from
> http://wiki.lyx.org/BibTeX/Biblatex is barely legal, maybe LyX should
> define its own command, say \LyX@basepath that'd contain the absolute
> path to the master .lyx document (no qoutes, no curly braces - only for
> the brave).
> Would you be willing to do that? (being that biblatex support is nowhere
> on the horizon yet)

Georg: After all these discussions it is clear that something like this 
is needed.

However, I do not want to clutter all documents with that (since 95% of the
users don't need it). I would prefer a solution where we extend the layout
definition language so that you could use a placeholder that will be
replaced by LyX with the master document path. Then everybody who needs 
this

path could write a module that pulls in the path into a LaTeX macro in the
most simple case, or in more advanced cases it could directly be used in 
the

preamble code that needs it.

Re: [patch] Finding the generated latex file

[Andrew Parsloe]

On 3/11/2015 7:38 a.m., Guillaume Munch wrote:

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).
Your proposed button would also solve #9211 "Make the lyxpreview.log 
files accessible within LyX".


Andrew


And I think it's not too bad to expose the LyX internals in this way.

What do you think?


Guillaume



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

Re: [patch] Finding the generated latex file

[Guillaume Munch]

Le 02/11/2015 21:10, Andrew Parsloe a écrit :

Your proposed button would also solve #9211 "Make the lyxpreview.log
files accessible within LyX".




I agree, part of this idea comes from all the times I had to debug lyx
previews (but not only).


For the interface, I also propose to substitute the extant “Copy to
clipboard” button with this “Open directory...” button to avoid making
the interface heavier. Indeed, “Copy to clipboard” is twice redundant:
1. With “open directory” one can open the original log file in an editor.
2. One can already do Ctrl+A in the dialog, or right mouse button ▷
Select all, then copy.

Any user of the "Copy to clipboard" button would object?


I propose to commit the attached which solves the UI issues of the
previous patch.



Guillaume
>From ea6b85adc95be9625a203f35009edfe5ee0deee5 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Mon, 2 Nov 2015 18:19:40 +
Subject: [PATCH] Add "Open directory..." button to the log dialog.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It takes the place of the “Copy to Clipboard” button which was redundant.
---
 src/frontends/qt4/GuiLog.cpp  | 19 +++
 src/frontends/qt4/GuiLog.h|  2 ++
 src/frontends/qt4/ui/LogUi.ui |  5 +++--
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/frontends/qt4/GuiLog.cpp b/src/frontends/qt4/GuiLog.cpp
index 14e7aaf..427e989 100644
--- a/src/frontends/qt4/GuiLog.cpp
+++ b/src/frontends/qt4/GuiLog.cpp
@@ -24,8 +24,10 @@
 #include "support/FileName.h"
 #include "support/gettext.h"
 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -189,6 +191,23 @@ void GuiLog::on_nextWarningPB_clicked()
 }
 
 
+void GuiLog::on_openDirPB_clicked()
+{
+	support::FileName dir = logfile_.onlyPath();
+	if (!dir.exists())
+		return;
+	QUrl qdir(toqstr(from_utf8("file://" + dir.absFileName())),
+			  QUrl::StrictMode);
+	// Give hints in case of bugs
+	if (!qdir.isValid()) {
+		LYXERR0("QUrl is invalid!");
+		return;
+	}
+	if (!QDesktopServices::openUrl(qdir))
+		LYXERR0("Unable to open QUrl even though dir exists!");
+}
+
+
 void GuiLog::goTo(QRegExp const & exp) const
 {
 	QTextCursor const newc =
diff --git a/src/frontends/qt4/GuiLog.h b/src/frontends/qt4/GuiLog.h
index 2a9ebb6..8159836 100644
--- a/src/frontends/qt4/GuiLog.h
+++ b/src/frontends/qt4/GuiLog.h
@@ -41,6 +41,8 @@ private Q_SLOTS:
 	void on_nextErrorPB_clicked();
 	/// jump to next warning
 	void on_nextWarningPB_clicked();
+	/// open containing directory
+	void on_openDirPB_clicked();
 	/// Log type changed
 	void typeChanged(int);
 
diff --git a/src/frontends/qt4/ui/LogUi.ui b/src/frontends/qt4/ui/LogUi.ui
index ddf6ebc..ebbc9dd 100644
--- a/src/frontends/qt4/ui/LogUi.ui
+++ b/src/frontends/qt4/ui/LogUi.ui
@@ -1,3 +1,4 @@
+
 
  LogUi
  
@@ -105,9 +106,9 @@
 


-
+
  
-  Copy to Clipboard
+  Open directory...
  
 

-- 
2.1.4

"view XeTeX" toolbar button

[Guenter Milde]

On 2015-11-02, Scott Kostyshak wrote:
> On Sun, Nov 01, 2015 at 10:31:32PM +, Guenter Milde wrote:
>> On 2015-11-01, Scott Kostyshak wrote:

...

>> >> While there is a use case for LuaTeX and TeX fonts, I can't see a
>> >> reason to use XeTeX instead of pdflatex with TeX fonts!

>> > The use case that I have in mind is simply that I expect our users might
>> > use such a combination. If we don't want to support the combination, we
>> > should output a useful error message explaining why, or just disable the
>> > combination. If not, users will use it. 

>> Or treat the combination XeTeX + TeX fonts as a non-standard use case
>> that we do not prevent but discourage.

> OK but how do we discourage? In the documentation? What about one of
> those warning boxes that has the checkbox "don't show this warning
> again". So the first time a user tries to compile with XeTeX and TeX
> fonts it warns them "It is not useful to use XeTeX and TeX fonts. You
> might prefer to use PDF (pdfTeX) or use PDF (XeTeX) with system fonts
> by going to Document > Settings > Fonts.

Yes, something in this line. Another idea would be to pop up this explanation
only if an error occurs

+1 less "noise"
-1 no warning for problems that do not lead to compiling errors

With #9744 fixed, this warning window would also come up rather seldom anyway.

>> This is similar to, e.g. the "language default (without inputenc)" option
>> for the inputencoding: this option fails inevitably without additional user
>> input in the LaTeX preamble.

> OK but I think it is a stranger case that a user goes into the settings
> and changes that than just click on the button for PDF (XeTeX).

Yes, this is the reasoning behind #9744:

>> This is, basically, what I want in Ticket #9744: the toolbar button would
>> call XeTeX with Unicode fonts by default.

The simpler approach would be to prominently document that 
not all choices in "view other formats" are suited for any document and give
examples:

* long documents with "View EPS (cropped)" or "View PDF (cropped)"
* documents relying on ERT with "View HTML"
* documents using TeX fonts with XeTeX

Of course, these approaches can be combined.

Günter

Re: status update on the export tests

[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 
> >> 
> 
> >> > Could we introduce a new status "suspended" - meaning just skip the
> >> > test until a known bug is solved as we know the result is
> >> > insignificant until then?
> 
> > As Kornel mentions, we have "ignoredTests" for this.
> 
> Not exactly, see below.
> 
> >> We already have such (specified in file "ignoredTests"). But as this
> >> tests are never executed, nobody cares for them anymore.
> >> The tests here are such, that we know, we never resolve them.
> 
> > I agree. We should not use ignored tests for temporary issues. Once we
> > put something in ignoredTests chances are strong that we will forget
> > about them for a long time.
> 
> This is why I said "suspended": 
> 
> Suggestion:
> 
>   Specified in file "suspendedTests") with the reason for suspending
>   (bug report, commit that turned hidden problems into export failure, ...)
>   
>   These tests are normally skipped, but they are not forgotten.
>   
>   The tests here are such, that we know, we can resolve them but their
>   failure is a minor issue that can be postponed (comparable to enhancement
>   requests in Trac).
>   
>   Suspending instead of reverting also frees us from the need to reassess
>   them if a change in the "real life documents" or a fix makes them pass
>   again. Instead, they could/should be revised at a time we have fixed
>   major known problems and no release pressure...
>   
>   
> 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.

Kornel


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

Re: lyx2lyx bugs from export tests

[Kornel Benko]

Am Sonntag, 1. November 2015 um 20:14:40, schrieb Richard Heck 
> On 11/01/2015 08:05 PM, Scott Kostyshak wrote:
> > On Sun, Nov 01, 2015 at 09:56:55PM +0100, Georg Baum wrote:
> >> Scott Kostyshak wrote:
> >>
> >>> On Sun, Nov 01, 2015 at 11:52:08AM -0500, Richard Heck wrote:
>  On 11/01/2015 11:37 AM, Scott Kostyshak wrote:
> 
> > Since you brought it up though, Kornel and I have discussed comparing
> > the .tex files. While we understand that the .lyx files are not expected
> > to be the same (for the reason you mentioned above), do you think it is
> > reasonable to expect the LaTeX output to be the same?
> >> If you want to test lyx2lyx, then I would strongly advise to test lyx2lyx
> >> alone, without LyX. This would be exactly the same procedure as we do with
> >> tex2lyx: For each test case, keep the expected output of lyx2lyx as
> >> reference, and verify once (when creating the test), that LyX will produce
> >> the correct output. When testing, do only compare the lyx2lyx output 
> >> against
> >> the refernce. If you keep LyX (and even pdflatex) in the chain, then you
> >> will be testing lyx2lyx, LyX and pdflatex at the same time, which will
> >> increase the probability of failing tests, and the search for the cause 
> >> will
> >> be more difficult.
> > Agreed. This would be nice. The "lyx2lyx" tests I'm doing now are just
> > cheap tests, which I think are better than no tests. I will add your
> > suggestion to the TestsToDo file. Hopefully someone will be interested
> > in implementing them someday.
> 
> I think it would be a perfectly reasonable requirement from now on 
> ---say, starting in the 2.3.x development cycle---that every format 
> change be accompanied by some kind of test file that illustrates the use 
> of the new feature (that's what it usually is) and that can be used to 
> test lyx2lyx's conversions. The more aspects of the feature the file 
> exercises, the better.

+1

> So if the new format is 500, then we'd have:
>  499-old.lyx and 500-forward.lyx
> to test the forward conversion, and
>  500-new.lyx and 499-backward.lyx
> to test the backward conversion. Writing a few scripts to run everything 
> and compare the results should be easy enough.
> 
> One surely ought to be producing such files anyway to test the lyx2lyx 
> routines one is writing.
> 
> Richard

There already is a lyx2lyx test. But this looks only if a convert to the newest 
format
is 'successfull'. It does not check if the resulting .lyx file is compilable.

You get the list of lyx2lyx tests with 'ctest -L lyx2lyx -N'

Kornel

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

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

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 10:40:27PM +, Guenter Milde wrote:
> On 2015-11-01, Guenter Milde wrote:
> > Dear Scott,
> 
> > thanks for the patch.
> 
> I modified it to use UTF8 with XeTeX without the 
> \inputencoding commands. A short test here showed that this
> helps with Umlauts or Cyrillic charactes in the PDF Info.
> 
> Give it a try.

Nice. I am not able to test it because I don't understand the underlying
issue, but I did look at the code and it looks good to me. I have a
couple picky comments about using tabs instead of spaces below (by the
way, there are ways of configuring Git to catch these types of
formatting inconsistencies, as well as your editor. Ask on the list if
curious).

> + if (inputenc_loaded)

replace spaces with tab?

> + if (inputenc_loaded)

replace spaces with tabs?


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. I know there are other things you want to do, but I think this
patch is a self-contained step forward and not a partial patch. If that's
correct, then I suggest you commit.

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

Scott

Re: [patch] Finding the generated latex file

[Guillaume Munch]

Le 02/11/2015 23:50, Scott Kostyshak a écrit :

On Mon, Nov 02, 2015 at 09:49:24PM +, Guillaume Munch wrote:

Le 02/11/2015 21:10, Andrew Parsloe a écrit :

Your proposed button would also solve #9211 "Make the lyxpreview.log
files accessible within LyX".




I agree, part of this idea comes from all the times I had to debug lyx
previews (but not only).


For the interface, I also propose to substitute the extant “Copy to
clipboard” button with this “Open directory...” button to avoid making
the interface heavier.


I think this is a good idea.


Indeed, “Copy to clipboard” is twice redundant:
1. With “open directory” one can open the original log file in an editor.


I was a little worried that some users would get overwhelmed when they
open the directory and there are possibly many files, but...


2. One can already do Ctrl+A in the dialog, or right mouse button ▷
Select all, then copy.


this assuages my concern.

The "Open directory..." could also get rid of the "Show Output Anyway"
button for the same reasoning as (1) above. I like the "Show Output
Anyway" button how it is, but I'm not sure if that's because I just got
used to it. If others prefer one less button though, I would be OK with
that.


To be clear, this is a different dialog right? So are you suggesting to 
add this “Open directory” button to the other dialog as well? I'd keep 
the “Show Output Anyway” button, for the reason you mentioned: there can 
be many files. What do others think?



Any ideas for a clearer button label than “Open directory...”?

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

[Guenter Milde]

On 2015-11-01, Guenter Milde wrote:
> Dear Scott,

> thanks for the patch.

I modified it to use UTF8 with XeTeX without the 
\inputencoding commands. A short test here showed that this
helps with Umlauts or Cyrillic charactes in the PDF Info.

Give it a try.

Günter

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

diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 537178e..de39309 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -1577,7 +1577,7 @@ bool BufferParams::writeLaTeX(otexstream & os, 
LaTeXFeatures & features,
}
 
// handle inputenc etc.
-   writeEncodingPreamble(os, features);
+   bool const inputenc_loaded = writeEncodingPreamble(os, features);
 
// includeonly
if (!features.runparams().includeall && !included_children_.empty()) {
@@ -1903,7 +1903,7 @@ bool BufferParams::writeLaTeX(otexstream & os, 
LaTeXFeatures & features,
 
OutputParams tmp_params = features.runparams();
pdfoptions().writeLaTeX(tmp_params, os,
-   features.isProvided("hyperref"));
+   features.isProvided("hyperref"), 
inputenc_loaded);
// set back for the rest
lyxpreamble.clear();
// correctly break URLs with hyperref and dvi output
@@ -2924,19 +2924,20 @@ docstring BufferParams::getGraphicsDriver(string const 
& package) const
 }
 
 
-void BufferParams::writeEncodingPreamble(otexstream & os,
+bool BufferParams::writeEncodingPreamble(otexstream & os,
 LaTeXFeatures & features) const
 {
// "inputenc" package not required with non-TeX fonts.
if (useNonTeXFonts)
-   return;
+   return false;
// "inputenc"  fails with XeTeX (even in 8-bit compatiblitly mode) and 
with TeX fonts,
// (this is a bug in the "inputenc" package see #9740).
if (features.runparams().flavor == OutputParams::XETEX)
-   return;
+   return false;
// For LuaTeX with TeX fonts, we can load
// the "luainputenc" package with the specified encoding(s) (see below).
 
+   bool use_inputenc = features.isProvided("inputenc");
if (inputenc == "auto") {
string const doc_encoding =
language->encoding()->latexName();
@@ -2973,6 +2974,7 @@ void BufferParams::writeEncodingPreamble(otexstream & os,
os << "]{luainputenc}\n";
else
os << "]{inputenc}\n";
+   use_inputenc = true;
}
if (package == Encoding::CJK || features.mustProvide("CJK")) {
if (language->encoding()->name() == "utf8-cjk"
@@ -2998,6 +3000,7 @@ void BufferParams::writeEncodingPreamble(otexstream & os,
os << "]{luainputenc}\n";
else
os << "]{inputenc}\n";
+   use_inputenc = true;
break;
case Encoding::CJK:
if (encoding().name() == "utf8-cjk"
@@ -3017,6 +3020,7 @@ void BufferParams::writeEncodingPreamble(otexstream & os,
os << "\\usepackage{CJK}\n";
}
}
+   return use_inputenc;
 }
 
 
diff --git a/src/BufferParams.h b/src/BufferParams.h
index b5ab65e..e3ff4f1 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -412,7 +412,8 @@ public:
/// return supported drivers for specific packages
docstring getGraphicsDriver(std::string const & package) const;
/// handle inputenc etc.
-   void writeEncodingPreamble(otexstream & os, LaTeXFeatures & features) 
const;
+/// return true if (lua)inputenc is written here or already provided
+   bool writeEncodingPreamble(otexstream & os, LaTeXFeatures & features) 
const;
///
std::string const parseFontName(std::string const & name) const;
/// set up the document fonts
diff --git a/src/PDFOptions.cpp b/src/PDFOptions.cpp
index 6646888..b4e91df 100644
--- a/src/PDFOptions.cpp
+++ b/src/PDFOptions.cpp
@@ -90,7 +90,7 @@ void PDFOptions::writeFile(ostream & os) const
 
 
 void PDFOptions::writeLaTeX(OutputParams & runparams, otexstream & os,
-   bool hyperref_already_provided) const
+   bool hyperref_already_provided, bool 
inputenc_loaded) const
 {
// FIXME Unicode
string opt;
@@ -176,20 +176,21 @@ void PDFOptions::writeLaTeX(OutputParams & runparams, 
otexstream & os,
 
// hyperref expects LICR macros for non-ASCII chars. With Xe/LuaTeX 
utf-8 works, too.
// Usually, "(lua)inputenc" converts the input to LICR.
-   // As hyperref provides good coverage for \inputencoding{utf8}, we can 
try
-   // this if the current input encoding 

Re: [patch] Finding the generated latex file

[Scott Kostyshak]

On Mon, Nov 02, 2015 at 09:49:24PM +, Guillaume Munch wrote:
> Le 02/11/2015 21:10, Andrew Parsloe a écrit :
> >Your proposed button would also solve #9211 "Make the lyxpreview.log
> >files accessible within LyX".
> >
> 
> 
> I agree, part of this idea comes from all the times I had to debug lyx
> previews (but not only).
> 
> 
> For the interface, I also propose to substitute the extant “Copy to
> clipboard” button with this “Open directory...” button to avoid making
> the interface heavier.

I think this is a good idea.

> Indeed, “Copy to clipboard” is twice redundant:
> 1. With “open directory” one can open the original log file in an editor.

I was a little worried that some users would get overwhelmed when they
open the directory and there are possibly many files, but...

> 2. One can already do Ctrl+A in the dialog, or right mouse button ▷
> Select all, then copy.

this assuages my concern.

The "Open directory..." could also get rid of the "Show Output Anyway"
button for the same reasoning as (1) above. I like the "Show Output
Anyway" button how it is, but I'm not sure if that's because I just got
used to it. If others prefer one less button though, I would be OK with
that.

Scott

Re: Any alpha blockers?

[Jean-Marc Lasgouttes]

Le 02/11/2015 09:03, Guenter Milde a écrit :

Besides this, #9830 prevents us from making documents more robust avoiding
non-ASCII characters in the PDF Header Information
(e.g. replacing Stöhr with St\"{o}hr) to solve some export test issues.


I agree that this bug is annoying, but it is certainly not related to 
2.2. I'll fix it when I find time.


JMarc

Re: Upgrade to boost 1.59?

[Peter Kümmel]

Am 02.11.2015 um 11:40 schrieb Jean-Marc Lasgouttes:

Le 01/11/2015 16:51, Scott Kostyshak a écrit :

On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:

Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:

On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:


I have it documented somewhere. Should I put it in development.lyx ?


If you are able to find it easily then I would say yes, please do. Even
though Peter already did the update it could be useful in the future.

Scott



Just call in boost extract.sh with the path to the new boot version,
then "git add --all", commit. That's it.


Thanks, Peter. It is good to know it is so straightforward.


Can it happen that we should remove some of the files too?


The scripts removes all existing files and adds all found by bcp.
Four files were deleted, ( git diff 04be61ea8 --name-status | grep D )

But bcp is called with these headers:

boost/any.hpp \
boost/assert.hpp \
boost/bind.hpp \
boost/crc.hpp \
boost/cstdint.hpp \
boost/format.hpp \
boost/function.hpp \
boost/functional.hpp \
boost/lexical_cast.hpp \
boost/noncopyable.hpp \
boost/regex.hpp \
boost/scoped_array.hpp \
boost/scoped_ptr.hpp \
boost/shared_ptr.hpp \
boost/signal.hpp \
boost/signals/connection.hpp \
boost/signals/trackable.hpp \
boost/tokenizer.hpp \
boost/tuple/tuple.hpp \
boost/mpl/string.hpp \
boost/mpl/fold.hpp \
boost/mpl/size_t.hpp \
boost/functional/hash.hpp \

so, when something has changed there, then we have
too much headers in our repository.



But indeed, thanks for updating.

JMarc

Re: Upgrade to boost 1.59?

[Jean-Marc Lasgouttes]

Le 01/11/2015 16:51, Scott Kostyshak a écrit :

On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:

Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:

On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:


I have it documented somewhere. Should I put it in development.lyx ?


If you are able to find it easily then I would say yes, please do. Even
though Peter already did the update it could be useful in the future.

Scott



Just call in boost extract.sh with the path to the new boot version,
then "git add --all", commit. That's it.


Thanks, Peter. It is good to know it is so straightforward.


Can it happen that we should remove some of the files too?

But indeed, thanks for updating.

JMarc

Re: Any alpha blockers?

[Jean-Marc Lasgouttes]

Le 02/11/2015 03:42, Scott Kostyshak a écrit :

Does anyone have an issue that they think should be considered as an
alpha blocker?


Not me. Let's get this alpha out!

Note that we missed LyX 20th birthday: while Lyrix was released circa 
July 1995, the first real LyX release probably happened in september 
1995. The first long-lived version was 0.7, which got released at the 
end of september.


Source: http://www.lyx.org/misc/archaeology/lyx-time.html

JMarc

Re: [patch] Finding the generated latex file

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 12:11:08AM +, Guillaume Munch wrote:

> >The "Open directory..." could also get rid of the "Show Output Anyway"
> >button for the same reasoning as (1) above. I like the "Show Output
> >Anyway" button how it is, but I'm not sure if that's because I just got
> >used to it. If others prefer one less button though, I would be OK with
> >that.
> 
> To be clear, this is a different dialog right? So are you suggesting to add
> this “Open directory” button to the other dialog as well?

Yes, in this case we could have the "Open directory" button in the place
of "Show Output Anyway" and would not need it in the LaTeX Log dialog.
But I just realized that if the compilation is successful, we can only
get to the LaTeX Log dialog so my idea is not good because we might want
to access the temporary directory even on a successful compilation.


> I'd keep the “Show
> Output Anyway” button, for the reason you mentioned: there can be many
> files. What do others think?
> 
> 
> Any ideas for a clearer button label than “Open directory...”?

I do not like all first letters capitalized, but it seems that is the
current style so we should stick with that. Also I don't think we should
have "...". That is for if another dialog *in LyX* is expected to follow
a click of that button. If I am mistaken on that we should rename "Show
Output Anyway" to have "..." also.

Looking at what other programs do in similar (but slightly different)
situations:

evince and firefox both have:
Open Containing Folder

fslint has:
Open Folder

filelight has:
Open File Manager Here

chromium has:
Show in folder

As for my personal preference, I might like "Open temporary dir" or
"Open temp dir" because it might be nice to emphasize that the directory
is temporary (e.g. it might be deleted soon!). Also that is how we refer
to it technically so if there are any user questions about "the
temporary" directory we will understand exactly which directory is being
referred to, as opposed to "I opened the directory, but...". I suppose
there is room for confusion though, since technically the temporary
directory is actually the parent folder of the lyx_tmpbuf0 directory. In
summary, I don't have a strong preference.

Scott

Re: [patch] Finding the generated latex file

[Guillaume Munch]

Le 03/11/2015 00:41, Scott Kostyshak a écrit :

On Tue, Nov 03, 2015 at 12:11:08AM +, Guillaume Munch wrote:


The "Open directory..." could also get rid of the "Show Output Anyway"
button for the same reasoning as (1) above. I like the "Show Output
Anyway" button how it is, but I'm not sure if that's because I just got
used to it. If others prefer one less button though, I would be OK with
that.


To be clear, this is a different dialog right? So are you suggesting to add
this “Open directory” button to the other dialog as well?


Yes, in this case we could have the "Open directory" button in the place
of "Show Output Anyway" and would not need it in the LaTeX Log dialog.
But I just realized that if the compilation is successful, we can only
get to the LaTeX Log dialog so my idea is not good because we might want
to access the temporary directory even on a successful compilation.



I'd keep the “Show
Output Anyway” button, for the reason you mentioned: there can be many
files. What do others think?


Any ideas for a clearer button label than “Open directory...”?


I do not like all first letters capitalized, but it seems that is the
current style so we should stick with that.


I make a quick search and you're right, title capitalization on buttons 
is a thing and is even recommended in some HIGs. (Title capitalization 
does not exist in French so I never noticed that in my apps.)



Also I don't think we should
have "...". That is for if another dialog *in LyX* is expected to follow
a click of that button. If I am mistaken on that we should rename "Show
Output Anyway" to have "..." also.


No, I think you are right.



Looking at what other programs do in similar (but slightly different)
situations:

evince and firefox both have:
Open Containing Folder

fslint has:
Open Folder

filelight has:
Open File Manager Here

chromium has:
Show in folder

As for my personal preference, I might like "Open temporary dir" or
"Open temp dir" because it might be nice to emphasize that the directory
is temporary (e.g. it might be deleted soon!). Also that is how we refer
to it technically so if there are any user questions about "the
temporary" directory we will understand exactly which directory is being
referred to, as opposed to "I opened the directory, but...". I suppose
there is room for confusion though, since technically the temporary
directory is actually the parent folder of the lyx_tmpbuf0 directory. In
summary, I don't have a strong preference.


Ok. My preference is for "Open Containing Directory" which I find more 
intuitive. It is still more specific than "the directory" so it has some 
of the advantages that you mention. Also, the path already makes it 
clear that it is not part of the user's personal files.

Re: [patch] update modernCV layout file

[Pavel Sanda]

Guenter Milde wrote:
> > Stating more than that sounds like overkill.
> 
> I still favour specifying a required TeXLive version based on these
> considerations. 
> 
> If we take the conservative route, this would be TeXLive 2012 that ships
> with the current CentOS (v. 7).

Quickly skimming through web I see Ubuntu LTS 12.04 supported till 2017
and having texlive 2009. That much for conservative side :)
Pavel

Re: [patch] Finding the generated latex file

[Scott Kostyshak]

On Tue, Nov 03, 2015 at 01:05:58AM +, Guillaume Munch wrote:

> >Looking at what other programs do in similar (but slightly different)
> >situations:
> >
> >evince and firefox both have:
> >Open Containing Folder
> >
> >fslint has:
> >Open Folder
> >
> >filelight has:
> >Open File Manager Here
> >
> >chromium has:
> >Show in folder
> >
> >As for my personal preference, I might like "Open temporary dir" or
> >"Open temp dir" because it might be nice to emphasize that the directory
> >is temporary (e.g. it might be deleted soon!). Also that is how we refer
> >to it technically so if there are any user questions about "the
> >temporary" directory we will understand exactly which directory is being
> >referred to, as opposed to "I opened the directory, but...". I suppose
> >there is room for confusion though, since technically the temporary
> >directory is actually the parent folder of the lyx_tmpbuf0 directory. In
> >summary, I don't have a strong preference.
> 
> Ok. My preference is for "Open Containing Directory" which I find more
> intuitive. It is still more specific than "the directory" so it has some of
> the advantages that you mention. Also, the path already makes it clear that
> it is not part of the user's personal files.

Makes sense. Your preference is also the closest to the most common one
of the programs I found (evince and firefox).

Scott

RFC: better submenu for tables

[Uwe Stöhr]

If you open the submenu of tables you see many entries. In my opinion 
too many, at least too many for laptops with small screens.


In general I think it should be less crowded. Thus a proposal:

- everything is removed for which we also have toolbar button. (If users 
disabled the automatic show of the table toolbar they apparently don't 
use tables that much and the table settings dialog is sufficient)


- As result everything can be removed, but these settings are added:
  - set/unset formal table
  - set/unset longtable

The result will be a small and clean submenu.

opinions?

thanks and regards
Uwe

Re: Any alpha blockers?

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Note that we missed LyX 20th birthday: while Lyrix was released circa July 
> 1995, the first real LyX release probably happened in september 1995. The 
> first long-lived version was 0.7, which got released at the end of 
> september.
>
> Source: http://www.lyx.org/misc/archaeology/lyx-time.html

Time to sell shirts and mugs :)
P

Re: [patch] Finding the generated latex file

[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.

Re: Upgrade to boost 1.59?

[Jean-Marc Lasgouttes]

Le 02/11/2015 12:34, Peter Kümmel a écrit :

The scripts removes all existing files and adds all found by bcp.
Four files were deleted, ( git diff 04be61ea8 --name-status | grep D )


OK, thanks.


But bcp is called with these headers:

[...]

so, when something has changed there, then we have
too much headers in our repository.


Indeed.

JMarc