Re: prefs2prefs.py not compatible with python3

[Stephan Witt]

Am 15.01.2017 um 00:05 schrieb Stephan Witt :
> 
> Am 14.01.2017 um 17:42 schrieb pdv :
>> 
>> The current master fails to start-up (on macOS) if the default Python is 
>> Python3.x, because prefs2prefs.py is not compatible with Python3.
> 
> This looks strange. The python people say python 2.7 is the default on Mac 
> (including the latest OS Sierra).
> 
> http://docs.python-guide.org/en/latest/starting/install3/osx/
> 
> Stephan
> 
>> 
>> In python23() in os.cpp both Python 2 and Python 3 are accepted.
>> 
>> 
>> As a temporarily workaround I've built with PYTHON="/usr/bin/python" which 
>> is the default apple-python, but that doesn't seem to help.
>> 
>> P. De Visschere

Sorry, I misunderstood - you are trying to force the use of the default 2.7 
python. I think you have to force the use of correct python at run-time. It 
doesn’t matter what your environment is at compile time. This is the correct 
behavior, IMO.

Stephan

Re: prefs2prefs.py not compatible with python3

[Stephan Witt]

Am 14.01.2017 um 17:42 schrieb pdv :
> 
> The current master fails to start-up (on macOS) if the default Python is 
> Python3.x, because prefs2prefs.py is not compatible with Python3.

This looks strange. The python people say python 2.7 is the default on Mac 
(including the latest OS Sierra).

http://docs.python-guide.org/en/latest/starting/install3/osx/

Stephan

> 
> In python23() in os.cpp both Python 2 and Python 3 are accepted.
> 
> 
> As a temporarily workaround I've built with PYTHON="/usr/bin/python" which is 
> the default apple-python, but that doesn't seem to help.
> 
> P. De Visschere
> 

Re: [LyX/master] Basic support for natbib & jurabib options

[Scott Kostyshak]

On Fri, Jan 13, 2017 at 06:24:32PM +0100, Juergen Spitzmueller wrote:
> commit fc546b7dcc793a77b44c2f3e3abc780d768a18ed
> Author: Juergen Spitzmueller 
> Date:   Fri Jan 13 18:23:42 2017 +0100
> 
> Basic support for natbib & jurabib options
> 
> This re-uses the options line edit introduced for biblatex.

I believe this commit causes several ctests to fail. A git bisect of the
ctest "elsarticle_lyx22" lead me to this commit.

To reproduce manually on current master:

$ lyx -e lyx22x elsarticle.lyx 
$ lyx -e lyx22x elsarticle.22.lyx 

If you open the created elsarticle.22.22.lyx in LyX, you get an error
message "Error reading internal layout information". Or you can do
another iteration on the command line to see the same error and more
information:

$ lyx -e lyx22x elsarticle.22.22.lyx 
LyX: Unknown TextClass tag `natbib' [around line 6 of file
/tmp/lyx_tmpdir.JNSaVdQX8201/convertLo8201.layout current token:
'natbib' context: '']
TextClass.cpp (397): Unable to convert internal layout information to
format 63
Warning: Read Error

Error reading internal layout information
$

Scott


signature.asc
Description: PGP signature

Re: [LyX/2.2.x] Assure long tooltip is correctly formatted.

[Guillaume Munch]

Le 14/01/2017 à 16:26, Kornel Benko a écrit :


I don't see it. Here it displays as a 6-liner in Slovak translation.
QT5.7
OS Mint17.3
desktop MATE

Kornel



Thanks Kornel and Jürgen for the replies. I will stop my investigation
but do not hesitate to report issues like this in the future.

Guillaume

Re: [LyX/master] Add an "Automatic" bibliography processor pref option

[Jürgen Spitzmüller]

Am Samstag, den 14.01.2017, 10:52 -0500 schrieb Richard Heck:
> Sorry, thought the change was to a BufferParam, but it's to a
> preference, isn't it?

Yes. I nevertheless bumped the prefs format meanwhile.

Jürgen

> 
> rh
> 

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

Re: [LyX/master] configure.py: Make 'notepad' last in text editor list

[Paul A. Rubin]

On 01/14/2017 06:01 AM, Guenter Milde wrote:

On 2017-01-14, Pavel Sanda wrote:

Guenter Milde wrote:

A more general question to all developers:
When checking for default viewer/editor applications during (re)configure,
should LyX
a) prefer feature rich applications, or
b) prefer small and fast-starting applications.

As I don't see any obvious choice I would prefer
c) don't mess with the order unless something really buggy starts appearing
(not so much because I believe the current order is right, but rather
not to disturb people who are used to the current situation).

Yes, this is my conclusion as well.
We should put this off until xdg-mime is safe to use.

Günter

Is there any evidence that xdg-mime/xdg-open will ever be safe? Right 
now I see two problems with it, one of which can be avoided. The 
original show-stopper was that it defaulted to opening files in the web 
browser if no default application was set. We can work around that by 
using xdg-mime to test whether a default is set in the MIME database. If 
yes, we can make xdg-open the file handler; if not, we can do what we 
currently do.


The bigger problem, in my mind, is that xdg-mime sometimes finds a 
default application, but not the one actually used by the system. I 
mentioned this in an earlier message, after stumbling on it 
accidentally. I found xdg-open using a "stale" default from 
~/.local/share/applications/mimeapps.list when the correct default was 
set in ~/.config/mimeapps.list. I haven't been able to locate any 
official document on the Freedesktop web site specifically naming the 
hierarchy of MIME database files, and I don't know enough to know 
whether ~/.config/mimeapps.list results from some applications not using 
the Freedesktop spec, or whether xdg is supposed to check that first but 
for some reason does not. In any case, unless my laptop is an outlier, 
there may be users out there for whom xdg-utils would select not the 
browser but some other incorrect (and, in one case on my laptop, not 
even installed) application.


Rather than waiting on xdg-utils to be fixed (if in fact Freedesktop 
even sees this as a bug -- I have no idea about that), should we look at 
gvfs-mime/gvfs-open (again with the stipulation that we first check 
whether a default application is set, and if not revert to our current 
practice)? It works on both my systems, but they're both running recent 
(albeit different) versions of Linux Mint. If we move in this direction, 
I think we should first ask devs with other Linux distributions to test 
it (which can be done with a simple shell script).


As far as standing pat, I can testify that this represents a PITA for 
Mint users once they upgrade to 18.1 (or maybe 18.0), because the X-Apps 
are not recognized and, depending on what else they have installed, they 
can end up with no viewers or gimp and notepad (WINE) as viewers. I have 
no idea whether any other distributions are going to move to X-Apps, so 
it may only be Mint users that are affected.


Incidentally, for people ill served by the configuration script, one way 
to reduce the pain would be to add something in the Tools > 
Preferences... dialogs that would allow the user, in one step, to set a 
new default viewer or editor for all file formats of a certain ilk (all 
PDF formats, all text formats, all image formats). Having to change the 
viewer for PDF (pdflatex) every time I reconfigure is mildly annoying; 
having to change it for multiple PDF formats after each reconfiguration 
is serious annoying.


One other thought came to mind: /if/ this is actually only a problem for 
Mint users, we could perhaps stick with the current configuration script 
and provide a separate configuration script that Mint users could 
download and install over the one that comes with the LyX package. 
That's essentially the workaround I'm using now.


Paul

prefs2prefs.py not compatible with python3

[pdv]

The current master fails to start-up (on macOS) if the default Python is 
Python3.x, because prefs2prefs.py is not compatible with Python3.


In python23() in os.cpp both Python 2 and Python 3 are accepted.


As a temporarily workaround I've built with PYTHON="/usr/bin/python" 
which is the default apple-python, but that doesn't seem to help.


P. De Visschere

Re: [LyX/master] Add an "Automatic" bibliography processor pref option

[Richard Heck]

On 01/14/2017 09:44 AM, Guillaume Munch wrote:
> Le 13/01/2017 à 23:28, Richard Heck a écrit :
>>
>> Format change?
>>
>
> It does not look like it to me. 

Sorry, thought the change was to a BufferParam, but it's to a
preference, isn't it?

rh

Re: [LyX/2.2.x] Assure long tooltip is correctly formatted.

[Kornel Benko]

Am Samstag, 14. Januar 2017 um 15:44:33, schrieb Guillaume Munch 
> Le 14/01/2017 à 10:07, Jürgen Spitzmüller a écrit :
> > Am Freitag, den 13.01.2017, 22:02 +0100 schrieb Guillaume Munch:
> >> Weird, it displays fine here at 119dfcb1. Are there precise steps
> >> that I
> >> must follow to reproduce the bug?
> >
> > * Open the BibTeX inset dialog
> > * Hit "Add"
> > * On the sub-dialog, hover over the list widget
> >
> > I get a long one-liner tooltip.
> >
> 
> 
> Here it formats as expected. In case this hides a serious
> shortcoming, can anyone else please try to reproduce this issue?
> (between ffb195b5 and 6b214804 excluded)
> 
> Have you noticed this issue at other places?
> 
> What is the Qt version, locale, OS, and desktop environment?
> 
> Thanks
> Guillaume

I don't see it. Here it displays as a 6-liner in Slovak translation.
QT5.7
OS Mint17.3
desktop MATE

Kornel

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

Re: [LyX/2.2.x] Assure long tooltip is correctly formatted.

[Jürgen Spitzmüller]

Am Samstag, den 14.01.2017, 15:44 +0100 schrieb Guillaume Munch:
> Have you noticed this issue at other places?

No.

> 
> What is the Qt version, locale, OS, and desktop environment?

Qt 5.7.1, both en_EN and de_DE, Linux (openSuse Tumbleweed), GNOME
3.22.

However, I cannot reproduce myself any longer. Strange.

Jürgen

> 
> Thanks
> Guillaume
> 

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

Re: [LyX/master] Add an "Automatic" bibliography processor pref option

[Guillaume Munch]

Le 13/01/2017 à 23:28, Richard Heck a écrit :


Format change?



It does not look like it to me. However:


/// Return the actual bibtex command (lyxrc or buffer param)
-   std::string const & bibtexCommand() const;
+   std::string const bibtexCommand() const;


I saw const-value return types a few times in the code. It seems that
this was advised in certain circumstances in old C++, but this is now
discouraged (essentially because it prevents automatic move operations
and serves no good enough purpose). See for instance
.

Guillaume

Re: [LyX/2.2.x] Assure long tooltip is correctly formatted.

[Guillaume Munch]

Le 14/01/2017 à 10:07, Jürgen Spitzmüller a écrit :

Am Freitag, den 13.01.2017, 22:02 +0100 schrieb Guillaume Munch:

Weird, it displays fine here at 119dfcb1. Are there precise steps
that I
must follow to reproduce the bug?


* Open the BibTeX inset dialog
* Hit "Add"
* On the sub-dialog, hover over the list widget

I get a long one-liner tooltip.




Here it formats as expected. In case this hides a serious
shortcoming, can anyone else please try to reproduce this issue?
(between ffb195b5 and 6b214804 excluded)

Have you noticed this issue at other places?

What is the Qt version, locale, OS, and desktop environment?

Thanks
Guillaume

Re: biblatex (features/biblatex2) branch and master/child

[Jürgen Spitzmüller]

Am Samstag, den 14.01.2017, 07:39 -0500 schrieb PhilipPirrip:
> On 01/14/2017 05:39 AM, Jürgen Spitzmüller wrote:
> > I prefer to get them without jumping through such hoops.
> 
> I'm sorry, I was switching from t'bird to some other news readdder.
> Attaching the files again.

Thanks! Should be fixed now.

Jürgen

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

Re: biblatex (features/biblatex2) branch and master/child

[PhilipPirrip]

On 01/14/2017 05:39 AM, Jürgen Spitzmüller wrote:

I prefer to get them without jumping through such hoops.


I'm sorry, I was switching from t'bird to some other news readdder.
Attaching the files again.


childOne.lyx
Description: application/lyx


childTwo.lyx
Description: application/lyx


master.lyx
Description: application/lyx

Re: Latex Error.

[Guenter Milde]

On 2017-01-14, Guenter Milde wrote:
> On 2017-01-14, Richard Heck wrote:
>> On 01/14/2017 12:11 AM, Scott Kostyshak wrote:
>>> On Sat, Jan 14, 2017 at 05:56:21PM +1300, gordon cooper wrote:

...

>> Could we at least say what the character was? Or report its location in
>> the file?

> With an 8-bit input encoding or "forced" characters like °, LyX reports
>  in the source pane and also
> the character in question in the Exort Error dialogue.

> Reporting the location in the file would be a bonus:
> With just one "exotic" character in the document, a search would be possible
> (the only problem is, that drag and drop from the Error dialogue does not
> work).
> With characters that only fail in verbatim context, a search in a larger
> document is cumbersome.

With uncodable characters, the cursor also jumps to the right place. Fine.
Maybe the error message could give some context instead only the problematic
character, just like the TeX errors.


> With "inputenc utf8", LyX only reports uncodable characters for "forced"
> conversion. LyX has currently no correct idea about which characters fail to
> be converted by [utf8]{inputenc} in verbatim context and the LaTeX error
> "TeX capacity exceeded" does not help either.


> Günter

Re: EmDash Problems

[Guenter Milde]

On 2017-01-14, Jürgen Spitzmüller wrote:
> Am Freitag, den 13.01.2017, 18:56 -0500 schrieb Richard Heck:

>> The attached files illustrate a problem that I raised, and was told
>> not to worry about, when "---" was exchanged for \textemdash. The
>> problem is that the latter does not break the way the former does.



Unfortunately, the attachemnt does not make it through the GMANE mail to
news interface...

>> What can we do about this. It's very annoying. (Note that this file is
>> format 530 from latest master.)

> \textendash and \textemdash also cause other problems:
> http://www.lyx.org/trac/ticket/10490

> IMHO we should output the ligatures rather than the macros.

OTOH, the macros allow configuration in the user preamble. 
This makes it more easy to adapt the line breaking to locale preferences,
e.g. with

\let\origtextemdash\textemdash
\renewcommand{\textemdash}{\nobreakspace\origtextemdash}

see also http://ctan.org/pkg/extdash
http://tex.stackexchange.com/questions/22419/disallowing-line-break-before-dash-en-dash-and-em-dash
http://tex.stackexchange.com/questions/32616/avoid-line-break-between-em-dash-and-the-next-word#32618

Günter

Re: [LyX/master] configure.py: Make 'notepad' last in text editor list

[Guenter Milde]

On 2017-01-14, Pavel Sanda wrote:
> Guenter Milde wrote:
>> A more general question to all developers:

>> When checking for default viewer/editor applications during (re)configure,
>> should LyX

>> a) prefer feature rich applications, or
>> b) prefer small and fast-starting applications.

> As I don't see any obvious choice I would prefer
> c) don't mess with the order unless something really buggy starts appearing
>(not so much because I believe the current order is right, but rather
>not to disturb people who are used to the current situation).

Yes, this is my conclusion as well.
We should put this off until xdg-mime is safe to use.

Günter

Re: biblatex (features/biblatex2) branch and master/child

[Jürgen Spitzmüller]

Am Samstag, den 14.01.2017, 10:45 +0100 schrieb Kornel Benko:
> They did. How to get the data:
> 1.) save the mail to a file, e.g. /tmp/childOne.lyx
> 2.) use uudeview on that file (in another directory)
>   ==> you get the undecoded childOne.lyx

I prefer to get them without jumping through such hoops.

Jürgen

> 
>   Kornel

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

Re: Latex Error.

[Guenter Milde]

On 2017-01-14, Richard Heck wrote:
> On 01/14/2017 12:11 AM, Scott Kostyshak wrote:
>> On Sat, Jan 14, 2017 at 05:56:21PM +1300, gordon cooper wrote:


>> Thanks for reporting this problem. Next time it would be helpful if you
>> sent an example file. I went ahead and created an example file and I can
>> reproduce the same problem you saw. The example file is attached. If you
>> open LyX in the terminal, you see the following message when compiling:

>>   Error 84 returned from iconv when converting from UCS-4LE to
>>   ISO-8859-15: Invalid or incomplete multibyte or wide character

>> It does not give a clue where the error comes from, and indeed the LyX
>> GUI is not helpful at all in indicating where the error might be.

>> I'm moving this thread to the lyx-devel list now. I think you wanted to
>> just give lyx-users a warning in case they come across the problem, and
>> I think potential discussion of how to improve LyX to handle this case
>> should proceed on lyx-devel.

> This kind of error does seem to crop up quite a bit. It'd be nice if we
> could say something more informative. 

> Could we at least say what the character was? Or report its location in
> the file?

With an 8-bit input encoding or "forced" characters like °, LyX reports
 in the source pane and also
the character in question in the Exort Error dialogue.

Reporting the location in the file would be a bonus:
With just one "exotic" character in the document, a search would be possible
(the only problem is, that drag and drop from the Error dialogue does not
work).
With characters that only fail in verbatim context, a search in a larger
document is cumbersome.


With "inputenc utf8", LyX only reports uncodable characters for "forced"
conversion. LyX has currently no correct idea about which characters fail to
be converted by [utf8]{inputenc} in verbatim context and the LaTeX error
"TeX capacity exceeded" does not help either.


Günter

Re: biblatex (features/biblatex2) branch and master/child

[Kornel Benko]

Am Samstag, 14. Januar 2017 um 10:15:29, schrieb Jürgen Spitzmüller 

> Am Freitag, den 13.01.2017, 20:17 + schrieb PhilipPirrip:
> > I'm reporting that the master document won't compile with a child 
> > document containing some commands specific to natbib.
> > In the attached examples, it will be because of a citation command
> > in 
> > childOne.lyx. 
> > Can this be translated on the fly? 
> 
> Can you please resend the attachments? They did not make it to the
> list.
> 
> Jürgen

They did. How to get the data:
1.) save the mail to a file, e.g. /tmp/childOne.lyx
2.) use uudeview on that file (in another directory)
==> you get the undecoded childOne.lyx

Kornel

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

Re: EmDash Problems

[Jürgen Spitzmüller]

Am Freitag, den 13.01.2017, 18:56 -0500 schrieb Richard Heck:
> The attached files illustrate a problem that I raised, and was told
> not
> to worry about, when "---" was exchanged for \textemdash. The problem
> is
> that the latter does not break the way the former does. What can we
> do
> about this. It's very annoying. (Note that this file is format 530
> from
> latest master.)

\textendash and \textemdash also cause other problems:
http://www.lyx.org/trac/ticket/10490

IMHO we should output the ligatures rather than the macros.

Jürgen

> 
> 
> Richard
> 
> 

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

Re: biblatex (features/biblatex2) branch and master/child

[Jürgen Spitzmüller]

Am Freitag, den 13.01.2017, 20:17 + schrieb PhilipPirrip:
> I'm reporting that the master document won't compile with a child 
> document containing some commands specific to natbib.
> In the attached examples, it will be because of a citation command
> in 
> childOne.lyx. 
> Can this be translated on the fly? 

Can you please resend the attachments? They did not make it to the
list.

Jürgen

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

Re: [LyX/2.2.x] Assure long tooltip is correctly formatted.

[Jürgen Spitzmüller]

Am Freitag, den 13.01.2017, 22:02 +0100 schrieb Guillaume Munch:
> Weird, it displays fine here at 119dfcb1. Are there precise steps
> that I
> must follow to reproduce the bug?

* Open the BibTeX inset dialog
* Hit "Add"
* On the sub-dialog, hover over the list widget

I get a long one-liner tooltip.

Jürgen


> 
> Guillaume
> 

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

Re: biblatex (features/biblatex2) settings dialog

[Jürgen Spitzmüller]

Am Freitag, den 13.01.2017, 19:32 + schrieb PhilipPirrip:
> Hope you don't mind if I report other findings here. Reporting on
> lyx.org 
> bug tracker takes too much time:

No, that's perfect.

> New document. Choose biblatex in Document Settings. Insert an
> option, 
> Apply. Delete the option - it remains in the arguments to biblatex
> call, 
> and it's back there when reopening the document.

Fixed.

Thanks
Jürgen

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