Re: Options for resolving the minted + shell-escape issue

[Tommaso Cucinotta]

On 17/07/2017 15:18, Enrico Forestieri wrote:

I don't understand if the 'needauth' is new in LyX 2.3.0 or already existed.


This is new to 2.3.0 and is instead deemed a security improvement. Yes,
security is improved by allowing running dangerous converters.


I have to step in for a clarification:

1) without the needauth mechanism, LyX would run arbitrary R code snippets 
embedded within a .lyx code whenever you tried to compile your doc, without 
asking anything, without telling the user, etc, such R code could even grab 
your ~/.ssh/ folder and upload it to a remote site, or just rm -rf $HOME/ 
(delete your entire home folder)

2) needauth was added as a safety measure that tags those potentially dangerous 
converters (the one executing R scripts) as 'needauth' (i.e., needs user's 
authorization before being run), so that, whenever LyX tries to run that 
converter, it will ask the user first

Therefore, it should be quite clear that needauth is a security improvement 
(compared with LyX supporting R/sweave/knitr without needauth).

3) I liked to propose addition of support for running Gnuplot scripts as well, 
with the corresponding converter tagged as a 'needauth' one
[ this last feature cannot be tagged as a security enhancement, but it's not 
more dangerous than what we already had with R scripting ]


The text indicates to me that it's possible for a document to store some
kind of setting that allows a converter (here external program) to be run
in an automated manner without my manual intervention or consent.


it is possible to use preferences settings in THREE possible combinations:

A) forbid any use of any 'needauth' converters altogether (will be the default 
for all users), that means users trying to compile a doc embedding a R script 
would see a dialog telling them that it was not possible to convert that part 
of the document because it is unsafe and the preferences options forbid it

  \use_converter_needauth_forbidden true

B) allow for using 'needauth' converters in the normal/designed mode, i.e., only after 
gaining user's authorization through a confirmation dialog that pops up on-demand 
per-converter invocation and per-document (but it's not asked again once the converted 
image is cached, so a second compilation of the same doc would NOT ask anything, because 
LyX would use images from its cache in ~/.lyx/cache/*): users can check a "don't ask 
me again for this document" if they trust the document, and there's quite a few 
converters therein, so any further 'needauth' converter in the doc is run without further 
auth question

  \use_converter_needauth_forbidden false
  \use_converter_needauth true

C) allow for using 'needauth' converters in the old unsafe way, as per status 
quo before 'needauth' was merged in: any converter is just run, including 
'needauth' ones, without asking anything; after commit [8a4fcd3d/lyxgit], when 
a user tries to get to this configuration from the preferences, he/she gets an 
additional SECURITY WARNING dialog explaining how unsafe/dangerous an action 
they're doing -- at this point, if users go on and approve the config options 
change, then they're assumed to know what they're doing

  \use_converter_needauth_forbidden false
  \use_converter_needauth false

There's an additional patch worked out in the TT below, which I like to think 
of as the final solution:

D) execute any converter within a protected/safe sandbox, this can easily be 
accomplished on Ubuntu/Linux using AppArmor, but it's not easy to merge such a 
change unless there's a portable corss-OS way -- albeit, for Linux users, this 
would be THE right way to go (with an initial transient until the AppArmor 
rules are correctly tunes, which I cannot claim is a trivial task). This would 
require no needauth, because the converter could be restricted to write only 
within a temporary folder, and be forced into having no network access, then 
only the created image file would be copied back from there, and anything else 
trashed away.

I hope the above clarifies.


but
consider the following example:
I create a document with some embedded code to be run by converters. It's
my document, I trust it. Then I e-mail it to a colleague or perhaps my
customer for review. Time goes by and eventually I get the document back
from review, but the review took longer than expected and my next deadline
was yesterday, so I'm in a hurry and build "my" document.


this is an excellent scenario to add to the list of additional enhancements, 
thanks; just TT-ified it:

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

The enhancement that was already discussed back long ago, was an expiry 
timestamp
of the user's authorization, so that, when user says "don't ask me again", this
will be remembered only for X days, weeks, months, then it will expire, and if
the same doc is opened back 1y later, one would be warned again.

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

Another discussed one was about hashing the content 

Re: Living with shell-escape: Using two LyX instances - critique invited

[Tommaso Cucinotta]

On 28/07/2017 23:17, Tommaso Cucinotta wrote:

Actually, I have to check how the above "-x lyxrc-apply " behaves w.r.t. 
options not mentioned, e.g., whether reset to the default, or it does what one might be 
tempted to imagine, i.e., just override the mentioned options, leaving others as from 
prefs file.


just verified that the behavior seems the one you'd imagine, i.e.:
1) "Format..." is just one of the many prefs recognized tags, it can be omitted 
without problems
2) without recurring to weirdnesses of the Linux shell that allows to send a command 
options including "\n", one can simply use the -x option multiple times and 
specify the pref options to modify; I've modified the section accordingly, in 
http://wiki.lyx.org/Devel/SafetyAndSecurity#sDevel.SafetyAndSecurity_11

It's a bit long to write -x "lyxrc_appy \\option value", but the option is 
there nonetheless, so there's no need for another -Doption=value syntax.

T.

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Tue, Jul 25, 2017 at 09:16:15PM +0200, Enrico Forestieri wrote:

> I am also investigating the possibility of attaching a context menu to
> the red icon in the status bar.

This is now done in the attached patch. Hovering with the mouse over the
red icon a warning is shown, and right clicking shows a popup menu that
allows to disable the shell escape option for the current document.

-- 
Enrico
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index a9cc619060..d7e827fc2a 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -55,6 +55,7 @@
 #include "ParagraphParameters.h"
 #include "ParIterator.h"
 #include "PDFOptions.h"
+#include "Session.h"
 #include "SpellChecker.h"
 #include "sgml.h"
 #include "texstream.h"
@@ -980,6 +981,8 @@ int Buffer::readHeader(Lexer & lex)
errorList.push_back(ErrorItem(_("Document header error"), s));
}
 
+   params().shell_escape = 
theSession().shellescapeFiles().find(absFileName());
+
params().makeDocumentClass();
 
return unknown_tokens;
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 22e84778fe..c16c308c21 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -459,6 +459,7 @@ BufferParams::BufferParams()
html_css_as_file = false;
display_pixel_ratio = 1.0;
 
+   shell_escape = false;
output_sync = false;
use_refstyle = true;
use_minted = false;
diff --git a/src/BufferParams.h b/src/BufferParams.h
index c20601e2ac..bc5c10d194 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -535,6 +535,8 @@ public:
std::string html_latex_end;
///
bool html_css_as_file;
+   /// allow the LaTeX backend to run external programs
+   bool shell_escape;
/// generate output usable for reverse/forward search
bool output_sync;
/// custom LaTeX macro from user instead our own
diff --git a/src/Converter.cpp b/src/Converter.cpp
index 489f5df439..c9bce7f2db 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -279,20 +279,52 @@ OutputParams::FLAVOR 
Converters::getFlavor(Graph::EdgePath const & path,
 }
 
 
-bool Converters::checkAuth(Converter const & conv, string const & doc_fname)
+bool Converters::checkAuth(Converter const & conv, string const & doc_fname,
+  bool use_shell_escape)
 {
-   if (!conv.need_auth())
+   string conv_command = conv.command();
+   bool const has_shell_escape = contains(conv_command, "-shell-escape")
+   || contains(conv_command, "-enable-write18");
+   if (conv.latex() && has_shell_escape && !use_shell_escape) {
+   docstring const shellescape_warning =
+ bformat(_("The following LaTeX backend has been "
+   "configured to allow execution of external programs "
+   "for any document:"
+   "%1$s"
+   "This is a dangerous configuration. Please, "
+   "consider using the support offered by LyX for "
+   "allowing this privilege only to documents that "
+   "actually need it, instead."),
+   from_utf8(conv_command));
+   frontend::Alert::error(_("Security Warning"),
+   shellescape_warning , false);
+   } else if (!conv.latex())
+   use_shell_escape = false;
+   if (!conv.need_auth() && !use_shell_escape)
return true;
-   const docstring security_warning = bformat(
- _("The requested operation requires the use of a converter 
from "
-   "%2$s to %3$s:"
+   size_t const token_pos = conv_command.find("$$");
+   bool const has_token = token_pos != string::npos;
+   string const command = use_shell_escape && !has_shell_escape
+   ? (has_token ? conv_command.insert(token_pos, "-shell-escape ")
+: conv_command.append(" -shell-escape"))
+   : conv_command;
+   docstring const security_warning = (use_shell_escape
+   ? bformat(_("The following LaTeX backend has been requested "
+   "to allow execution of external programs:"
+   "%1$s"
+   "The external programs can execute arbitrary commands on "
+   "your system, including dangerous ones, if instructed to do "
+   "so by a maliciously crafted LyX document."),
+ from_utf8(command))
+   : bformat(_("The requested operation requires the use of a "
+   "converter from %2$s to %3$s:"
"%1$s"
-   "This external program can execute arbitrary commands on 
your "
-   "system, including dangerous ones, if instructed to do so by a "
-   "maliciously crafted .lyx document."),
- from_utf8(conv.command()), from_utf8(conv.from()),
- from_utf8(conv.to()));
-   if 

Re: Living with shell-escape: Using two LyX instances - critique invited

[Tommaso Cucinotta]

On 27/07/2017 23:08, Christian Ridderström wrote:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden true'

This is lyx-unsafe:

./src/lyx -x 'lyxrc-apply Format 22
\use_converter_needauth_forbidden false
\use_converter_needauth false'


I haven't added this to the wiki page as I don't understand the 'Format 22' 
part.

Perhaps you could explain it, or add it to the page?

Would this be applied after LyX preferences/config has been read, but before a 
document is opened?


couldn't study this for long, I just noticed that, when you click the Apply button from 
the Prefs dialog, we trigger the LYXRC_APPLY LFUN, and we pass as argument a string being 
an exact copy of a whole preferences file, including the first line "Format 
22", carriage returns, backslashes, and even comments #... :-). I assume the Format 
line is useful to allow for format upgrade(s) when starting a new version of LyX with a 
~/.lyx/preferences file written by an older version.
Actually, I have to check how the above "-x lyxrc-apply " behaves w.r.t. 
options not mentioned, e.g., whether reset to the default, or it does what one might be 
tempted to imagine, i.e., just override the mentioned options, leaving others as from 
prefs file.

T.

Re: [LyX/master] Add Jûrgen's changes in Additional.lyx to log file

[Jürgen Spitzmüller]

Am Freitag, den 28.07.2017, 18:34 +0200 schrieb Jean-Pierre Chrétien:
> Le 28/07/2017 à 18:28, jpc a écrit :
> > commit 91c078b7c5ca21bcf5b8ba3746b9794ae8256a8d
> > Author: jpc 
> > Date:   Fri Jul 28 18:27:22 2017 +0200
> > 
> >  Add Jûrgen's changes in Additional.lyx to log file
> 
> Hello Jürgen
> 
> I collected your recent changes in the docUpdates file, but it seems
> that you 
> are not finished yet, you're still working on the vc section.
> Please tell me when tou are finished with your editions of the file,
> thanks.

I'm done now. Thanks for the collection.

> 
> BTW, are you sure that the two Bibliographic references should be
> supressed ?

Yes, these are the only two manuals that have been referred to via
Bbiliography. All others have direct hyperlink references, so I did
that for these two, as well.

Jürgen

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

Re: [LyX/master] Add Jûrgen's changes in Additional.lyx to log file

[Jean-Pierre Chrétien]

Le 28/07/2017 à 18:28, jpc a écrit :

commit 91c078b7c5ca21bcf5b8ba3746b9794ae8256a8d
Author: jpc 
Date:   Fri Jul 28 18:27:22 2017 +0200

 Add Jûrgen's changes in Additional.lyx to log file


Hello Jürgen

I collected your recent changes in the docUpdates file, but it seems that you 
are not finished yet, you're still working on the vc section.

Please tell me when tou are finished with your editions of the file, thanks.

BTW, are you sure that the two Bibliographic references should be supressed ?

--
Jean-Pierre

RE: #10706: My created vector graphics ? symbol inputs to LyX but does not export to PDF XeTex

[Vilis I. Lietuvietis]

Hi Spitz:

Your suggestion below did not work for me. But this following solution written 
by Kornel Benko, which is similar to yours, does work.  The only adjustment I 
had to make was that in LyX I had to reduce the gigantic size of the anchor by 
highlighting (selecting) the ERT, then selecting Text Style Customized, and 
then selecting the smallest font size available "tiny" .  This reduced the huge 
anchor down to normal text size in my pdf output. LyX is working very well for 
me now for writing my large 550 pages academic book. 

https://www.mail-archive.com/lyx-users@lists.lyx.org/msg105363.html

My computer setup prevented me from sending a thank you note to Kornel Benko. I 
do not know his email address. Maybe you can let him know his solution worked 
for me.

Thanks,

Vilis Lietuvietis

Estland


-Original Message-
From: LyX Ticket Tracker [mailto:t...@lyx.org]
Sent: Friday, June 16, 2017 5:23 PM
To: vi...@neti.ee; lasgout...@lyx.org
Subject: Re: #10706: My created vector graphics ? symbol inputs to LyX but does 
not export to PDF XeTex

#10706: My created vector graphics ⚓ symbol inputs to LyX but does not export to
PDF XeTex
-+--
 Reporter:  Vilis|   Owner:  lasgouttes
 Type:  enhancement  |  Status:  new
 Priority:  normal   |   Milestone:
Component:  general  | Version:  unspecified
 Severity:  normal   |  Resolution:
 Keywords:   |
-+--

Comment (by spitz):

 This is U+2693 (Anchor)

 Possible LaTeX macros:

 1. {{{\anchor}}} (package dingbat)
 2. {{{\anchor}}} (package arev)
 3. {{{\faAnchor}}} (package fontawesome)

 We cannot use (2.) since it changes the sf font to arev. Dingbat strikes e
 the only sensible possibility.

 @Vilis, as a workaround, insert {{{\usepackage{dingbat to the preamble
 and {{{\anchor}}} (in TeX mode) at the point where the symbol should
 appear.

--
Ticket URL: 
The LyX Project 
LyX -- The Document Processor

Re: alternatives for dashes (please vote)

[Pavel Sanda]

Guenter Milde wrote:

Thanks Guenter for the summary.

> Patch [72a488d7/lyxgit] introduced the new buffer setting
> "use_dash_ligatures" that controls the latex output of dashes as either
> font ligatures or Unicode/LICR. 
> The setting can be changed under Document>Settings>Fonts.
> The "use_dash_ligatures" setting is set based on fileformat version, not
> content. The default is "true".  

I tend to agree with f). It's not nice that we have such option in the prefs,
but since we screw the situation already we at least give user some power to
fix things onwards from 2.3 in his own way. 

And some exclamation mark in RELEASE_NOTES.

I could even imagine some measure for the last 2.2 stable.  It could still make
it to debian stretch LTS; 2.2 did not make it fortunately to ubuntu LTS at all
(sign that we are releasing way too fast :)).  Such measure would preserve
<2.2 docs to be safely saved without conversion to 2.2 literals and allow
smooth transition to 2.3...

Pavel

Re: alternatives for dashes (please vote)

[Jean-Marc Lasgouttes]

Le 28/07/2017 à 11:09, Guenter Milde a écrit :

• allow line breaks after em- and en-dash with re-definition using
   \allowbreak:
   
 \let\origtextemdash\textemdash

 \renewcommand{\textemdash}{\origtextemdash\allowbreak}


I would vote against such redefinitions, which are IMO bound to cause us 
trouble one day (I used to be very fond of these clever tricks). We 
should adapt to whatever LaTeX provides, and complain loudly when 
different engines are not able to agree about what the strategy should be.


That leaves with only 6 solutions to consider.

However, I wonder whether  a solution can always works. Consider the 
case of French typography. Even though it is usual to use spacing, we 
are supposed to do like this:


Les incises –~même si tout le monde ne les aime pas~– sont très utiles.

So the inner space has to be unbreakable, which is probably the case in 
other languages too. My knowledge of typography is limited on this 
point, but isn't it the case when there is no space?


I think the 2.3 behavior, as I understand it (aka ``pick your poison'') 
at least has the benefit of being predictable.


JMarc

Re: Build failed in Jenkins: Build branch "master" » ubuntu-latest-qt5-cmake #316

[Kornel Benko]

Am Freitag, 28. Juli 2017 um 03:11:50, schrieb ci-...@inria.fr
> In file included from /build/lyx/src/support/FileMonitor.h:20:0,
>  from /build/lyx/src/support/FileMonitor.cpp:14:
> /build/lyx/src/support/signals.h:15:30: fatal error: boost/signals2.hpp: No 
> such file or directory
> compilation terminated.

This means, we still use something from boost.

Kornel

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

Build failed in Jenkins: Build branch "master" » ubuntu-latest-qt5-cmake #317

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/317/--
[...truncated 439 lines...]
[  2%] Generating gl/Tutorial.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/gl /build/lyx/lib/doc/gl/Tutorial.lyx > 
/build/lyx/build/doc/gl/Tutorial.lyx
[  2%] Generating hu/Intro.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/hu /build/lyx/lib/doc/hu/Intro.lyx > 
/build/lyx/build/doc/hu/Intro.lyx
[  2%] Generating hu/Tutorial.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/hu /build/lyx/lib/doc/hu/Tutorial.lyx > 
/build/lyx/build/doc/hu/Tutorial.lyx
[  2%] Generating uk/Intro.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/uk /build/lyx/lib/doc/uk/Intro.lyx > 
/build/lyx/build/doc/uk/Intro.lyx
[  2%] Generating MergedManuals.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/. /build/lyx/lib/doc/MergedManuals.lyx > 
/build/lyx/build/doc/MergedManuals.lyx
[  2%] Generating es/DocumentoPostizo2.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/DocumentoPostizo2.lyx > 
/build/lyx/build/doc/es/DocumentoPostizo2.lyx
[  3%] Generating es/Math.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/Math.lyx > 
/build/lyx/build/doc/es/Math.lyx
[  3%] Generating es/UserGuide.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/UserGuide.lyx > 
/build/lyx/build/doc/es/UserGuide.lyx
[  3%] Generating es/Shortcuts.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/Shortcuts.lyx > 
/build/lyx/build/doc/es/Shortcuts.lyx
[  3%] Generating es/DocumentoPostizo1.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/DocumentoPostizo1.lyx > 
/build/lyx/build/doc/es/DocumentoPostizo1.lyx
[  3%] Generating es/Additional.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/Additional.lyx 
> /build/lyx/build/doc/es/Additional.lyx
[  3%] Generating es/Formula-numbering.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/Formula-numbering.lyx > 
/build/lyx/build/doc/es/Formula-numbering.lyx
[  3%] Generating es/EmbeddedObjects.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/EmbeddedObjects.lyx > 
/build/lyx/build/doc/es/EmbeddedObjects.lyx
[  3%] Generating es/Intro.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es /build/lyx/lib/doc/es/Intro.lyx > 
/build/lyx/build/doc/es/Intro.lyx
[  4%] Generating es/Customization.lyx
cd /build/lyx/build/doc && /usr/bin/python2 
/build/lyx/development/cmake/doc/ReplaceValues.py 
LYX_USERDIR_VER=LYX_USERDIR_23x LYX_DIR_VER=LYX_DIR_23x \origin\ 
unavailable=\origin\ /systemlyxdir/doc/es 
/build/lyx/lib/doc/es/Customization.lyx > 
/build/lyx/build/doc/es/Customization.lyx
[  4%] Generating es/Tutorial.lyx
cd 

Re: alternatives for dashes (please vote)

[Guenter Milde]

On 2017-07-27, Pavel Sanda wrote:

> Could you expand little bit, what e) means 

Examples:

• allow line breaks after em- and en-dash with re-definition using
  \allowbreak:
  
\let\origtextemdash\textemdash
\renewcommand{\textemdash}{\origtextemdash\allowbreak}

• allow line breaks after em- and en-dash with re-definition using ligatures:

\renewcommand{\textemdash}{---}

* For LuaTeX with non-TeX fonts, you need to make the EM DASH character active

\catcode`\—=13
\protected\def—{\textemdash\allowbreak}

  or

\catcode`\—=13
\protected\def—{---}


* In XeTeX with non-TeX fonts, the literal dash behaves like a ligature
  dash by default.
  
  (You can change this to \text*dash like behaviour with the preamble
  setting \XeTeXdashbreakstate=0).
  
See http://www.lyx.org/trac/ticket/10543#comment:1
and the examples
http://www.lyx.org/trac/raw-attachment/ticket/10543/emdash-line-breaks.lyx
http://www.lyx.org/trac/raw-attachment/ticket/10543/emdash-line-breaks.2.lyx


> what f) the current 2.3alpha behavior is?

Patch [72a488d7/lyxgit] introduced the new buffer setting
"use_dash_ligatures" that controls the latex output of dashes as either
font ligatures or Unicode/LICR. 
The setting can be changed under Document>Settings>Fonts.
The "use_dash_ligatures" setting is set based on fileformat version, not
content. The default is "true".  

See http://www.lyx.org/trac/ticket/10543#comment:2 and
http://www.lyx.org/trac/ticket/10543#comment:3

Günter

Re: alternatives for dashes (please vote)

[Enrico Forestieri]

On Fri, Jul 28, 2017 at 12:51:39AM +0200, Pavel Sanda wrote:

> Guenter Milde wrote:
> > Comments and votes welcome.
> ...
> > e) re-define \textemdash
> > f) keep the current 2.3alpha behaviour
> 
> Could you expand little bit, what e) means and what f) the current 2.3alpha
> behavior is? Thanks. Pavel

IMO, f) is the best compromise. Only a small percentage of pre 2.2 documents
using literal dashes may be affected, but the vast majority of documents
not edited with 2.2 (i.e., old documents created with version 2.1 or previous)
and those created with 2.2 are fine. So, I have no doubt that nothing has
to be done as regard dashes. What matters is not that an issue may occur but
the probability by which that issue will occur. All envisaged issues are low
probability issues, so they are not really issues.

-- 
Enrico

Re: [LyX/master] Additional.lyx: Fix advice wrt overfull \hboxes

[Jean-Pierre]

Le 28 juillet 2017 08:44:11 GMT+02:00, Juergen Spitzmueller  a 
écrit :
>commit 55e0978b14d0136ddf02fa93b65b5f4db84d7f7d
>Author: Juergen Spitzmueller 
>Date:   Fri Jul 28 08:42:24 2017 +0200
>
>Additional.lyx: Fix advice wrt overfull \hboxes
>
>  The advice given here, "You can ignore these messages", is just plain
>wrong (ironically, this very document is the best example).

True, it was even worse in French, the translator had written "these stupid 
messages", I corrected recently, but I will review the phrase again.
Maybe a hint about the draft mode stressing visually the boxes would be welcome 
there ?


-- 
Jean-Pierre