Start New (Parent) Environment

[racoon]

It seems impossible to get LyX to start a new "Only" environment *via* 
Edit > Start New (Parent) Environment. (Other environments are affected 
too.)


Please open the attached file and try to insert a new Only environment 
in the already created frame.


Maybe I am overlooking something.

Daniel


new parent environment.lyx
Description: application/lyx

Re: #10481: Hardening LyX against potential misuse

[Tommaso Cucinotta]

On 04/12/2016 18:37, Guillaume Munch wrote:

If there are n graphics, then are there n dialogs when opening the file
for the first time?


it asks as many times as there are (uncached) graphics needing 'needauth'
converters,unless you hit the "Run, and don't ask again for the same doc"
button.

T.

Re: Outliner problem

[Scott Kostyshak]

On Mon, Dec 05, 2016 at 02:27:50PM +1300, Andrew Parsloe wrote:
> Working on two documents at once with different levels of headings reveals a
> problem with the outliner. If doc1 has, say, 3 levels (chap., sec., subsec.)
> and doc2 has none, then the slider indicating how many levels to display is
> dominated by doc2. Setting the slider for doc1 to show 3 levels, then
> switching to doc2 zeros it again. Switching back to doc1, it stays at the
> zero setting. When one is constantly switching between the documents, this
> becomes irritating. (I don't know what the "keep" checkbox is supposed to
> do, but it certainly doesn't retain the doc1 setting.) It would be good if
> the slider setting "stuck" to a document.
> 
> I experimented by adding a couple of heading levels to doc2. Switching
> between the documents shows the slider remembers 2 levels now. The smaller
> number of levels still dominates.

I would say create a bug report for this and specify the component
"outliner". I think there are several known fundamental problems with
the outliner, perhaps necessitating a big rewrite to work around some
issues. So if we have all the bugs up there, then when someone does
finally get annoyed enough to tackle the mess, there will not be a
shortage of information.

Scott


signature.asc
Description: PGP signature

Outliner problem

[Andrew Parsloe]

Working on two documents at once with different levels of headings 
reveals a problem with the outliner. If doc1 has, say, 3 levels (chap., 
sec., subsec.) and doc2 has none, then the slider indicating how many 
levels to display is dominated by doc2. Setting the slider for doc1 to 
show 3 levels, then switching to doc2 zeros it again. Switching back to 
doc1, it stays at the zero setting. When one is constantly switching 
between the documents, this becomes irritating. (I don't know what the 
"keep" checkbox is supposed to do, but it certainly doesn't retain the 
doc1 setting.) It would be good if the slider setting "stuck" to a document.


I experimented by adding a couple of heading levels to doc2. Switching 
between the documents shows the slider remembers 2 levels now. The 
smaller number of levels still dominates.


Andrew

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

Re: [LyX/master] Fix display and output of math macros with optional arguments

[Enrico Forestieri]

On Sun, Dec 04, 2016 at 12:22:23AM -0500, Richard Heck wrote:
> 
> Looks good to me.

Committed at 9435dd6b.

-- 
Enrico

Re: cumbersome behavior when switching output-engines regarding inputenc

[mn]

On 04.12.16 20:44, Guenter Milde wrote:
> On 2016-12-04, mn wrote:
 There might be some incorrect or unexpected behavior when switching
 output engines in LyX, because Xetex does not support input-encoding
 settings:
> 
 To reproduce:
 Start a document, go to setup:
> 
 - first try something for pdflatex and
 define under language: input encodig to other (here it was utf8)
 (then close dialog, reopen dialog and)
> 
>>> Which encoding did you select?
> 
>> Switched from "language default" to "Custom: utf8"
> 
> I suppose the standard "Unicode (utf8), right?
> 
Correct.

 - switch to fonts, set these to any combination of luatex/Xetex.
> 
>>> Did you mean "tick the 'use non-TeX fonts'" button which activates the
>>> "fontspec" package for use of Unicode-encoded fonts?
> 
>> Yes, switch to "Use non-TeX fonts (via XeTeX/LuaTeX)"
> 
>>> With "use non-TeX fonts", both the input encoding and the font
>>> encoding are set to "utf-8", overriding any setting under
>>> Settings>Language>Encoding.
> 
 Try to compile the document.
> 
 It will complain that inputenc is not suitable for the chosen engine.
> 
>>> Not here. It just compiles.
> 
>> I just retook the steps I outlined above again and had the same error again.
> 
> There must be something else in your document. Try with File>New and see
> whether this produces the error.  If yes, send the document. If not, tell
> what else is needed.
> 

"Language Package: Always Babel" (a remnant default)
one line in the preamble loading Minion Pro.

Source View for Format LyX displays
"\inputencoding utf8"
while set for default-output: XeTeX
To be sure I attached a small file demoing the error as is.


greetings
Mike


input-err.lyx
Description: application/lyx

Re: LyX and (ancient) Hebrew

[Guy Rutenberg]

Hi,

On 3 December 2016 at 23:51, Scott Kostyshak  wrote:

> >
> > If I may offer some suggestions... I am not a programmer who can
> implement
> > this, but I use Hebrew in LyX quite often, including ancient Hebrew with
> > everything on it. Xetex is the only one, in my experience, that is really
> > working.
>
> Good to know. I wonder if we should set our Hebrew manuals to XeTeX by
> default.


XeTeX is by far the best option today to typeset Hebrew and LyX should
default to it. Culmus-latex and ivritex (the old ways to get Hebrew
working) are no longer actively maintained as they are inferior in almost
any sense.

A while a go I wrote a simple tutorial to get an Hebrew document working
using LyX and XeTeX.

https://www.guyrutenberg.com/2015/03/21/creating-a-hebrew-document-in-lyx-2-1-with-xetex/

Regards,
Guy

module basic

[Ian Wilder]

Hey guys,

I just compiled master and fired it up to poke around.
It launches ok but when I try and create a new document I'm met with a 
dialogue saying:


The module basic has been requested by
this document but has not been found in the list of
available modules. If you recently installed it, you
probably need to reconfigure LyX.

Any thoughts?

My platform is: Darwin Kernel Version 16.1.0 (MacOS Sierra)
My configure command is: ./configure 
--with-qt-dir=/opt/local/libexec/qt5 --enable-qt5 
--prefix=/Users/ian/Applications/LyX-master.app


Thanks,
Ian

Re: cumbersome behavior when switching output-engines regarding inputenc

[Guenter Milde]

On 2016-12-04, mn wrote:


> On 04.12.16 16:09, Guenter Milde wrote:
>> On 2016-12-03, mn wrote:

>>> There might be some incorrect or unexpected behavior when switching
>>> output engines in LyX, because Xetex does not support input-encoding
>>> settings:

>>> To reproduce:
>>> Start a document, go to setup:

>>> - first try something for pdflatex and
>>> define under language: input encodig to other (here it was utf8)
>>> (then close dialog, reopen dialog and)

>> Which encoding did you select?

> Switched from "language default" to "Custom: utf8"

I suppose the standard "Unicode (utf8), right?

>>> - switch to fonts, set these to any combination of luatex/Xetex.

>> Did you mean "tick the 'use non-TeX fonts'" button which activates the
>> "fontspec" package for use of Unicode-encoded fonts?

> Yes, switch to "Use non-TeX fonts (via XeTeX/LuaTeX)"

>> With "use non-TeX fonts", both the input encoding and the font
>> encoding are set to "utf-8", overriding any setting under
>> Settings>Language>Encoding.

>>> Try to compile the document.

>>> It will complain that inputenc is not suitable for the chosen engine.

>> Not here. It just compiles.

> I just retook the steps I outlined above again and had the same error again.

There must be something else in your document. Try with File>New and see
whether this produces the error.  If yes, send the document. If not, tell
what else is needed.

> ###
> ! Package inputenc Error: inputenc is not designed for xetex or luatex.
> (inputenc)only UTF-8 supported.

> See the inputenc package documentation for explanation.
> Type  H   for immediate help.
>  ...

> l.158 \endinput

This should not happen with "use non-TeX fonts".

> For xelatex or lualatex save the document in UTF-8 encoding
> and do not use inputenc, or use the [utf8] option.

LyX does not use inputenc if "non-TeX fonts" are used. The setting under
language>encoding is ignored.

> ###

> But I found that my usual way of invoking MinionPro for default roman
> for pdflatex is apparently the culprit:

> The preamble-code
> \usepackage[textosf,mathlf]{MinionPro}

> seems to trigger the behavior outlined above.

> Although I fail to see why.
> None of the related .sty-files pull in inputenc?

The full log will tell you, which file loaded inputenc.
All loaded files are logged and nesting is indicated by ().


>>> But then going back to doc-settings and just trying to unset the
>>> other(utf8)-option back to default is inaccessible (greyed out).
>>> To do anything about that you have to first also unset your
>>> font-settings back to choices for pdflatex.

>> Did changing the input encoding setting under Language>Encoding help
>> to make
>> your document compile again? Which setting was required? Did it work with
>> "non-TeX fonts" later?


> Yes. For both tests when it failed and also when I noticed this behavior
> in another document: unsetting first "Use non-TeX-fonts" and then
> changing input encoding back to default, then rechecking "Use
> non-TeX-Fonts" produced a PDF that compiled with XeTeX and looked as
> expected.

Strange. 

> Together with the apparent trigger mentioned above I currently do not
> understand why un/checking inputenc:utf8 in LyX's gui has any influence
> on this situation if it is ignored by LyX for XeTeX in he way you decribed.

It would be interesting to see the diff of the exported files with
and without Language>Encoding set to utf8. 
You may spot a difference either with View>Source (complete document or
preamble) or File>Export>latex (XeTeX).

Günter

Re: [LyX/master] Cosmetic changes to the needauth dialogs

[Enrico Forestieri]

On Sun, Dec 04, 2016 at 06:38:42PM +0100, Guillaume Munch wrote:

> commit 588d939722f4a516e8e4a932086e574bc3b13065
> Author: Guillaume Munch 
> Date:   Sun Dec 4 18:28:03 2016 +0100
> 
> Cosmetic changes to the needauth dialogs
> 
> * Use rich text for this complicated message
> 
> * More concise
> 
> * Fix line breaking issues
> 
> * Remove "Do not show again" checkbox
> 
[...]
>  
> +// FIXME: This dialog has issues with line breaking and size, in particular 
> with
> +// html. But it could easily be reimplemented as a QMessageBox using
> +// QMessageBox::setCheckBox() available starting from Qt 5.2
>  class GuiToggleWarningDialog : public QDialog, public Ui::ToggleWarningUi
>  {
>  public:

If this is true, it would be better to actually reimplement it and
conditionally compile for Qt >= 5.2, otherwise this risks staying so
for ever (or almost so).

-- 
Enrico

Re: #10481: Hardening LyX against potential misuse

[Kornel Benko]

Am Sonntag, 4. Dezember 2016 um 18:51:15, schrieb Guillaume Munch 
> Le 04/12/2016 à 18:06, Tommaso Cucinotta a écrit :
> > On 28/11/2016 00:42, Tommaso Cucinotta wrote:
> >> On 27/11/2016 13:52, Guillaume Munch wrote:
> >>> * Converters>Security is located below the converter configuration,
> >>> which leads to think that they are converter properties instead of
> >>> global settings. What about placing it above the converter list?
> >>
> >> Same problem with the Converter Cache option already, isn't it?
> >>
> >> Let me propose the attached fix for both at once.
> >
> > just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm
> > it shows up as intended ...
> >
> 
> How is it supposed to show up? Can you send a screenshot? Here only the
> font of "Converters Definition" changed, and I still find it unclear.

Dialog looks good. There seems to be missing  in

"The requested operation requires the use of a converter from %2$s 
to %3$s:"
"%1$sThis external program can 
execute "
"arbitrary commands on your system, including dangerous ones, if 
instructed "
"to do so by a maliciously crafted .lyx document."

Kornel


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

Re: Crash in stable

[Enrico Forestieri]

On Sun, Dec 04, 2016 at 07:01:51PM +0100, Guillaume Munch wrote:

> Le 04/12/2016 à 18:48, Enrico Forestieri a écrit :
> > I am confused now. You make a convoluted patch justifying it by saying
> > that it was done in view of a proper fix. The simpler one-liner has the
> > same effect and actually would not be possible if the proper fix was in
> > place. Given that it is not backported to branch, the simpler fix is
> > preferable. But I am not going to argue further, as I don't seem to be
> > able to follow your logic.
> > 
> 
> And I am not going to argue further, because I gave reasons for why it
> is preferable to have the one closest to master out of the two.

Amen

-- 
Enrico

Re: Crash in stable

[Guillaume Munch]

Le 04/12/2016 à 18:48, Enrico Forestieri a écrit :

I am confused now. You make a convoluted patch justifying it by saying
that it was done in view of a proper fix. The simpler one-liner has the
same effect and actually would not be possible if the proper fix was in
place. Given that it is not backported to branch, the simpler fix is
preferable. But I am not going to argue further, as I don't seem to be
able to follow your logic.



And I am not going to argue further, because I gave reasons for why it
is preferable to have the one closest to master out of the two.

Re: #10481: Hardening LyX against potential misuse

[Scott Kostyshak]

On Sun, Dec 04, 2016 at 06:06:57PM +0100, Tommaso Cucinotta wrote:
> On 28/11/2016 00:42, Tommaso Cucinotta wrote:
> > On 27/11/2016 13:52, Guillaume Munch wrote:
> > > * Converters>Security is located below the converter configuration,
> > > which leads to think that they are converter properties instead of
> > > global settings. What about placing it above the converter list?
> > 
> > Same problem with the Converter Cache option already, isn't it?
> > 
> > Let me propose the attached fix for both at once.
> 
> just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm it 
> shows up as intended ...

I did not follow this conversation closely, but here are my comments:

Keep in mind that most LyX users do not know what a file cache is.  Can
you describe exactly what's being cached in the tooltip? Maybe you could
use the word "remembered" instead of "cached" in the tooltip because it
is a more user-friendly word?

A tooltip for maximum age would also be useful. e.g. "after this amount
of days, ..."

I wonder if the cache should expire after e.g. 60 days, or after 60 days
since the last use of the file. For example, I (think I) would want it
to be 60 days since the last use of the file, but I don't know if that's
what would be best for the general user.

I think you want some kind of validator for the maximum age. I put in a
negative number and after saving it turned it into 49651.3. I'm guessing
you want to restrict to only non-negative integers? Look at other places
we use validators for similar text boxes.
Also what would happen if I put in 0? Does that effectively mean the
converter file cache is disabled? Or is it a special value that means
"never expire"?

Thanks for your work on this!

Scott


signature.asc
Description: PGP signature

Re: #10481: Hardening LyX against potential misuse

[Guillaume Munch]

Le 04/12/2016 à 18:06, Tommaso Cucinotta a écrit :

On 28/11/2016 00:42, Tommaso Cucinotta wrote:

On 27/11/2016 13:52, Guillaume Munch wrote:

* Converters>Security is located below the converter configuration,
which leads to think that they are converter properties instead of
global settings. What about placing it above the converter list?


Same problem with the Converter Cache option already, isn't it?

Let me propose the attached fix for both at once.


just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm
it shows up as intended ...



How is it supposed to show up? Can you send a screenshot? Here only the
font of "Converters Definition" changed, and I still find it unclear.

Re: Crash in stable

[Enrico Forestieri]

On Sun, Dec 04, 2016 at 06:21:53PM +0100, Guillaume Munch wrote:

> Le 04/12/2016 à 17:04, Enrico Forestieri a écrit :
> > 
> > Weak arguments, given that you say the patch was written with the
> > proper fix in mind (which is not in stable).
> 
> It is probably clear to Enrico (I hope) but maybe less to people who did
> not follow the discussions and the mentioned commits too closely, that
> "proper fix" refers to the pointer becoming invalid. This fix is
> only meant to avoid bugs of the same kind in the future. Enrico's
> "one-liner" does nothing about it. It is not in stable because nobody
> is asking to backport it, because it would be useless there. Then this
> fix for a problem B is supposed to be somehow related to the qualities
> of a solution to problem A in stable, and if he is serious then I have
> to admit that then his argument escapes me.

I am confused now. You make a convoluted patch justifying it by saying
that it was done in view of a proper fix. The simpler one-liner has the
same effect and actually would not be possible if the proper fix was in
place. Given that it is not backported to branch, the simpler fix is
preferable. But I am not going to argue further, as I don't seem to be
able to follow your logic.

> > It would be better if you post your patches to stable for approval
> > and comments before committing them.
> > 
> 
> In fact there was a private exchange with Richard on Friday when I saw
> the report, apologies to the list for not being included in the
> recipients but I was away without access to my usual git
> configuration, and I wanted to spare people time wasted in a duplicate
> fix. But from the discussion it was clear to me that Richard intended to
> backport 79a947c9 in case it worked.

Hmmm...

-- 
Enrico

Re: #10481: Hardening LyX against potential misuse

[Guillaume Munch]

Le 28/11/2016 à 00:42, Tommaso Cucinotta a écrit :


eh eh, what about remembering 'needauth' (as well as cursor pos) only for
those files in the recent files list :-), and collapse the 3 lists into
a single one, and a single session section ?


Two problems I see with this idea is that migrating the user session is
going to require some work which can be avoided, and also that the three
lists may have different age/length requirements, for instance the
recent files is limited to what you see in the menu.




* Please see the attached patch for a few suggestions


looks great, HTML provides a much better graphics :-), feel free to push !



Done




* Converters>Security is located below the converter configuration,
which leads to think that they are converter properties instead of
global settings. What about placing it above the converter list?


Same problem with the Converter Cache option already, isn't it?

Let me propose the attached fix for both at once.


You made me realise that the converter cache option is indeed global.
So it's good to fix both, thanks.



browse to the Sweave converters, and you'll see
the needauth option in the extraflags, guess we can edit as well from
the dialog, can't we?


Ok, I did not realise.



1. graphics on-screen conversion & display, used with my (local) gnuplot
patch,
   so I insert a .gnuplot image file, and I see its produced output pic
on screen,
   ..., after a few warnings about running needauth converters :-)...


If there are n graphics, then are there n dialogs when opening the file
for the first time?


what else, what are further calls to converters?



Thanks for the explanations, I don't see other calls to converters.

Guillaume

Re: LyX and (ancient) Hebrew

[mn]

On 04.12.16 17:58, Scott Kostyshak wrote:
> On Sun, Dec 04, 2016 at 05:38:14PM +0100, mn wrote:
> 
>> Something like an MWE is attached.
>> Here, it triggers slowness on loading the file into a fresh LyX session.

> I cannot reproduce with just your example. But if I select all and then
> paste 10 times, then I can get some slowness with cursor movement,
> selection and scrolling.

Pasting this paragraph 10 times is enough to make LyX really glacial.

> Note that if you have continuous spellcheck enabled and source preview,
> these two things can slow down cursor movement.

Source view is usually closed.
When I tested it with continuous spell-check enabled it is indeed much
much slower than without.
Then again the spell-checkers seem to be quite clueless about what's
written there.
Setting spellchecker to either "aspell" or "native" seems to improve the
situation somewhat but it's hard to quantify which of both options is
better. Regarding speed, both are clearly superior to hunspell, which
slows LyX to an absolute crawl. But aspell and native seem to just
ignore all the hebrew text?
Nothing is marked with both of them enabled, whereas hunspell seems to
mark a lot of the text as somehow incorrect.

Re: Crash in stable

[Guillaume Munch]

Le 04/12/2016 à 17:04, Enrico Forestieri a écrit :


Weak arguments, given that you say the patch was written with the
proper fix in mind (which is not in stable).


It is probably clear to Enrico (I hope) but maybe less to people who did
not follow the discussions and the mentioned commits too closely, that
"proper fix" refers to the pointer becoming invalid. This fix is
only meant to avoid bugs of the same kind in the future. Enrico's
"one-liner" does nothing about it. It is not in stable because nobody
is asking to backport it, because it would be useless there. Then this
fix for a problem B is supposed to be somehow related to the qualities
of a solution to problem A in stable, and if he is serious then I have
to admit that then his argument escapes me.


It would be better if you post your patches to stable for approval

> and comments before committing them.




In fact there was a private exchange with Richard on Friday when I saw
the report, apologies to the list for not being included in the
recipients but I was away without access to my usual git
configuration, and I wanted to spare people time wasted in a duplicate
fix. But from the discussion it was clear to me that Richard intended to
backport 79a947c9 in case it worked.

Re: #10481: Hardening LyX against potential misuse

[Tommaso Cucinotta]

On 28/11/2016 00:42, Tommaso Cucinotta wrote:

On 27/11/2016 13:52, Guillaume Munch wrote:

* Converters>Security is located below the converter configuration,
which leads to think that they are converter properties instead of
global settings. What about placing it above the converter list?


Same problem with the Converter Cache option already, isn't it?

Let me propose the attached fix for both at once.


just pushed as [f0f555b5/lyxgit], would be good if anyone could confirm it 
shows up as intended ...

Thx,

T.

Re: LyX and (ancient) Hebrew

[Scott Kostyshak]

On Sun, Dec 04, 2016 at 05:38:14PM +0100, mn wrote:

> Something like an MWE is attached.
> Here, it triggers slowness on loading the file into a fresh LyX session.

Thanks for your persistence and this example!

I cannot reproduce with just your example. But if I select all and then
paste 10 times, then I can get some slowness with cursor movement,
selection and scrolling.

Note that if you have continuous spellcheck enabled and source preview,
these two things can slow down cursor movement.

Scott


signature.asc
Description: PGP signature

Re: LyX and (ancient) Hebrew

[mn]

On 04.12.16 02:50, Scott Kostyshak wrote:
> On Sat, Dec 03, 2016 at 10:26:17PM +0100, mn wrote:
>> On 03.12.16 21:43, Scott Kostyshak wrote:
>>
 BTW:
 Until now I only had simple and short strings entered myself into an
 otherwise empty document.
 Copying this rather complex but still short example into LyX makes it
 quite slow to handle and beachballing a lot. There seems to be a problem
 handling this (script or unicode or whatnot).
>>>
>>> Good to know. Can you give some enumerated simple steps to reproduce?
>>> And where exactly do you see the slow part? (when copying, when
>>> pasting?) I do not see slowness, but I think it's because I
>>> misunderstood. Please do this in a separate email to lyx-devel so we can
>>> separate the conversations.
>>>
>>
>> 1. new document
>> 2. output font set to Xetex/SBL-Hebrew
>> 3. main document language set to English
>> 4. paste Hebrew text
>> beachball
>> 5. set pasted text to language Hebrew
>> beachball
>> 6. paste English text
>> beachball
>> 7. set English text to language English
>> beachball
>> 7. scrolling
>> beachball then quite slow scrolling
>> 8. resize window,
>> short beachball
>> 9. pasting the same English block again
>> beachball
>> 10 pasting English block again
>> beachball or delay (delay is ~ for 2-3 seconds)
>>
>> It seems to occur right after the clipboard buffer gets pasted into the
>> editor buffer / LyX's system.
>> Source of the text was OSHB sword module copied from Alkitab.
>> (i.e. I do not know if that has problems on its own)
>> But it seems to be an unproblematic block of characters in other
>> Mac-applications (speed-wise).
> 
> I can't reproduce on Ubuntu. Stephan, can you reproduce on Mac?
> 

One interesting tidbit:
After copying and pasting Gen 1 in vocalized Hebrew three times into the
document and alternating this with three paragraphs in English:
LyX starts to beachball for >5 seconds (up to a minute) for every action
taken. That is 5 seconds for one cursor movement one character position
to the right for example. Opening LyX's preferences takes around 20
seconds while beachballing.
When a new document tab is then opened and no Hebrew is there, then the
speed is back to normal. For every action taken. Insert as mush latin
characters as you like.
Until you start with Hebrew again.

Something like an MWE is attached.
Here, it triggers slowness on loading the file into a fresh LyX session.

For proper PDF-output you will need the SBL-Hebrew font as specified in
the preamble from here:
https://www.sbl-site.org/educational/BiblicalFonts_SBLHebrew.aspx

greetings
mn






GenXeTeX.lyx
Description: application/lyx

Re: Crash in stable

[Enrico Forestieri]

On Sun, Dec 04, 2016 at 01:01:13PM +0100, Guillaume Munch wrote:

> Le 04/12/2016 à 12:25, Enrico Forestieri a écrit :
> > On Sun, Dec 04, 2016 at 11:57:29AM +0100, Guillaume Munch wrote:
> > 
> > > Le 04/12/2016 à 00:57, Enrico Forestieri a écrit :
> > > > On Sat, Dec 03, 2016 at 11:59:33PM +0100, Guillaume Munch wrote:
> > > > > 
> > > > > This is the same as
> > > > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196794.html. I
> > > > > have now backported the fix.
> > > > 
> > > > Hmmm... a quite convoluted patch. There was a one-liner fixing this.
> > > > 
> > > 
> > > But then you are repeating the discussion above. What point are you
> > > trying to make?
> > 
> > Given two equivalent patches, the simpler is preferable.
> > 
> 
> The patch which is preferable is the one that deviates the less from
> master, because:
>  * it is already tested,
>  * it causes fewer merge conflicts with future backports.
> 
> In this case indeed, the backported code is still in master because it
> was written with the proper fix at e0e765f6a98 in mind, as I explained
> in the previous discussion.

Weak arguments, given that you say the patch was written with the
proper fix in mind (which is not in stable). It would be better if
you post your patches to stable for approval and comments before
committing them.

-- 
Enrico

Re: cumbersome behavior when switching output-engines regarding inputenc

[mn]

On 04.12.16 16:09, Guenter Milde wrote:
> On 2016-12-03, mn wrote:
>
>> There might be some incorrect or unexpected behavior when switching
>> output engines in LyX, because Xetex does not support input-encoding
>> settings:
>
>> To reproduce:
>> Start a document, go to setup:
>
>> - first try something for pdflatex and
>> define under language: input encodig to other (here it was utf8)
>> (then close dialog, reopen dialog and)
>
> Which encoding did you select?
>

Switched from "language default" to "Custom: utf8"

>> - switch to fonts, set these to any combination of luatex/Xetex.
>
> Did you mean "tick the 'use non-TeX fonts'" button which activates the
> "fontspec" package for use of Unicode-encoded fonts?
>

Yes, switch to "Use non-TeX fonts (via XeTeX/LuaTeX)"

> With "use non-TeX fonts", both the input encoding and the font
encoding are
> set to "utf-8", overriding any setting under Settings>Language>Encoding.
>
>> Try to compile the document.
>
>> It will complain that inputenc is not suitable for the chosen engine.
>
> Not here. It just compiles.
>

I just retook the steps I outlined above again and had the same error again.

###
! Package inputenc Error: inputenc is not designed for xetex or luatex.
(inputenc)only UTF-8 supported.

See the inputenc package documentation for explanation.
Type  H   for immediate help.
 ...

l.158 \endinput

For xelatex or lualatex save the document in UTF-8 encoding
and do not use inputenc, or use the [utf8] option.

###

But I found that my usual way of invoking MinionPro for default roman
for pdflatex is apparently the culprit:

The preamble-code
\usepackage[textosf,mathlf]{MinionPro}

seems to trigger the behavior outlined above.

Although I fail to see why.
None of the related .sty-files pull in inputenc?

>> But then going back to doc-settings and just trying to unset the
>> other(utf8)-option back to default is inaccessible (greyed out).
>> To do anything about that you have to first also unset your
>> font-settings back to choices for pdflatex.
>
> Did changing the input encoding setting under Language>Encoding help
to make
> your document compile again? Which setting was required? Did it work with
> "non-TeX fonts" later?
>

Yes. For both tests when it failed and also when I noticed this behavior
in another document: unsetting first "Use non-TeX-fonts" and then
changing input encoding back to default, then rechecking "Use
non-TeX-Fonts" produced a PDF that compiled with XeTeX and looked as
expected.

Together with the apparent trigger mentioned above I currently do not
understand why un/checking inputenc:utf8 in LyX's gui has any influence
on this situation if it is ignored by LyX for XeTeX in he way you decribed.

>> This is wrong imho.
>
>> I think LyX should keep these settings for the usage case "switching
>> engines" but gracefully ignore inputenc settings for Xetex.
>
>> This was presumably intended to keep users from messing with inputenc
>> once Xetex was the chosen output engine for a document, but it is
>> confusing when you only find out later that you might have to use Xetex
>> instead of pdflatex.
>
> There is an important distinction between "use XeTeX/LuaTeX" and "use
> Unicode fonts" that even major LaTeX packages get wrong.
>
> Also, the custom counsel "use XeTeX" or "use LuaTeX" given to users with
> font problems or script problems is misleading. Switching the engine does
> not help without switching the fonts, too. Usually, this implies use
of the
> "fontspec" package, in LyX by ticking the "use non-TeX fonts" button.
>
> You can use XeTeX or LuaTeX and 8-bit TeX fonts (and there are rare but
> valid use cases).
>
> However, because even the creators of the basic "inputenc" package did
> get this wrong and added a test, XeTeX can no longer be used with
> inputenc when the input encoding is set to something other than "ascii".
> Therefore, LyX overrides the user-choice in Settings>Language>Encoding
> with XeTeX and 8-bit TeX-fonts. This can lead to errors when the document
> contains characters that LyX cannot convert to ascii.

Thanks for the explanation.
greetings
Mike

Re: cumbersome behavior when switching output-engines regarding inputenc

[Guenter Milde]

On 2016-12-03, mn wrote:

> There might be some incorrect or unexpected behavior when switching
> output engines in LyX, because Xetex does not support input-encoding
> settings:

> To reproduce:
> Start a document, go to setup:

> - first try something for pdflatex and
> define under language: input encodig to other (here it was utf8)
> (then close dialog, reopen dialog and)

Which encoding did you select?

> - switch to fonts, set these to any combination of luatex/Xetex.

Did you mean "tick the 'use non-TeX fonts'" button which activates the
"fontspec" package for use of Unicode-encoded fonts?

With "use non-TeX fonts", both the input encoding and the font encoding are
set to "utf-8", overriding any setting under Settings>Language>Encoding.


> Try to compile the document.

> It will complain that inputenc is not suitable for the chosen engine.

Not here. It just compiles.

> But then going back to doc-settings and just trying to unset the
> other(utf8)-option back to default is inaccessible (greyed out).
> To do anything about that you have to first also unset your
> font-settings back to choices for pdflatex.

Did changing the input encoding setting under Language>Encoding help to make
your document compile again? Which setting was required? Did it work with
"non-TeX fonts" later?

> This is wrong imho.

> I think LyX should keep these settings for the usage case "switching
> engines" but gracefully ignore inputenc settings for Xetex.

> This was presumably intended to keep users from messing with inputenc
> once Xetex was the chosen output engine for a document, but it is
> confusing when you only find out later that you might have to use Xetex
> instead of pdflatex.

There is an important distinction between "use XeTeX/LuaTeX" and "use
Unicode fonts" that even major LaTeX packages get wrong.

Also, the custom counsel "use XeTeX" or "use LuaTeX" given to users with
font problems or script problems is misleading. Switching the engine does
not help without switching the fonts, too. Usually, this implies use of the
"fontspec" package, in LyX by ticking the "use non-TeX fonts" button.

You can use XeTeX or LuaTeX and 8-bit TeX fonts (and there are rare but
valid use cases). 

However, because even the creators of the basic "inputenc" package did
get this wrong and added a test, XeTeX can no longer be used with
inputenc when the input encoding is set to something other than "ascii".
Therefore, LyX overrides the user-choice in Settings>Language>Encoding
with XeTeX and 8-bit TeX-fonts. This can lead to errors when the document
contains characters that LyX cannot convert to ascii.

Günter

Re: Crash in stable

[Guillaume Munch]

Le 04/12/2016 à 12:25, Enrico Forestieri a écrit :

On Sun, Dec 04, 2016 at 11:57:29AM +0100, Guillaume Munch wrote:


Le 04/12/2016 à 00:57, Enrico Forestieri a écrit :

On Sat, Dec 03, 2016 at 11:59:33PM +0100, Guillaume Munch wrote:


This is the same as
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196794.html. I
have now backported the fix.


Hmmm... a quite convoluted patch. There was a one-liner fixing this.



But then you are repeating the discussion above. What point are you
trying to make?


Given two equivalent patches, the simpler is preferable.



The patch which is preferable is the one that deviates the less from
master, because:
 * it is already tested,
 * it causes fewer merge conflicts with future backports.

In this case indeed, the backported code is still in master because it
was written with the proper fix at e0e765f6a98 in mind, as I explained
in the previous discussion.

Re: Crash in stable

[Enrico Forestieri]

On Sun, Dec 04, 2016 at 11:57:29AM +0100, Guillaume Munch wrote:

> Le 04/12/2016 à 00:57, Enrico Forestieri a écrit :
> > On Sat, Dec 03, 2016 at 11:59:33PM +0100, Guillaume Munch wrote:
> > > 
> > > This is the same as
> > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196794.html. I
> > > have now backported the fix.
> > 
> > Hmmm... a quite convoluted patch. There was a one-liner fixing this.
> > 
> 
> But then you are repeating the discussion above. What point are you
> trying to make?

Given two equivalent patches, the simpler is preferable.

-- 
Enrico

Re: Crash in stable

[Guillaume Munch]

Le 04/12/2016 à 00:57, Enrico Forestieri a écrit :

On Sat, Dec 03, 2016 at 11:59:33PM +0100, Guillaume Munch wrote:


This is the same as
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196794.html. I
have now backported the fix.


Hmmm... a quite convoluted patch. There was a one-liner fixing this.



But then you are repeating the discussion above. What point are you
trying to make?