lyx2lyx round-trip (was: lyx2lyx problems ...)

2018-01-22 Thread Guenter Milde
On 2018-01-22, Kornel Benko wrote:

> Thanks to Günter, the ligature-problem is gone.

Unfortunately, the ligature-problem is not completely gone, just the
tests pass.

> I expanded the lyx2lyx test so, the an error is emitted at 10th
> repeated run to export lyx16x.

> If two consecutive created lyx-files are identical, the test stops
> without error. if a created lyx-file is not loadable, test stops with
> error.

Could you post (or mail me, if it is too large) a list of the
tests that fail with the 10th round-trip?

> Now, for example, export/doc/nb/Tutorial_lyx16 adds at each run following
> data to the created lyx-file.

>> % Added by lyx2lyx
>> %  for proper underlining
>> \PassOptionsToPackage{normalem}{ulem}
>> \usepackage{ulem}
>> \let\cite@rig\cite
>> \newcommand{\b@xcite}[2][\%]{\def\def@pt{\%}\def\pas@pt{#1}
>>   \mbox{\ifx\def@pt\pas@pt\cite@rig{#2}\else\cite@rig[#1]{#2}\fi}}
>> \renewcommand{\underbar}[1]{{\let\cite\b@xcite\uline{#1}}}

> Though this creates loadable file, it is no longer compilable.
> Pdf-exporting such a file.


>   ! LaTeX Error: Command \b@xcite already defined.
>  Or name \end... illegal, see p.192 of the manual.
...

Yes, I realized this when exploring the UserGuide_lyx16 error.
I will have a look into this and similar round-trip issues.
Hopefully, we can reduce the maximum number of round-trips for most documents.

Thanks,
Günter




Re: Slow Installer Download

2018-01-22 Thread Pavel Sanda
Pavel Sanda wrote:
> Joel Kulesza wrote:
> > I mentioned that mainly out of generality and being unsure if mirrors were
> > hidden behind URL masking.  My approach to download is:
> > 
> >- stable: lyx.org->Downloads->click OS X .dmg link.
> >- dev: lyx.org->Downloads->Pre-releases, navigate to release of interest.
> 
> There is no "masking behind", if you go this route you always get connected
> to our main ftp, which is in Paris.
> 
> I just tried to download from this server in Prague (2-3MB/s) and
> San Diego (600 KB/s), all is in between academic networks, so I can

Actually using ethernet connected machine instead of wifi connected
machine I get 40MB/s in Prague so there is two order of magnitude
drop for the hop over the big pond which is little bit surprising...

Pavel


Re: SSH problem

2018-01-22 Thread Jean-Marc Lasgouttes

Le 22/01/2018 à 15:58, Kornel Benko a écrit :

Is this the same as dsa?
# cd ~/.ssh
# file *.pub
==> id_dsa.pub: OpenSSH DSA public key


Yes. In the file the key starts with ssh-dss.

JMarc


Re: Slow Installer Download

2018-01-22 Thread Pavel Sanda
Joel Kulesza wrote:
> I mentioned that mainly out of generality and being unsure if mirrors were
> hidden behind URL masking.  My approach to download is:
> 
>- stable: lyx.org->Downloads->click OS X .dmg link.
>- dev: lyx.org->Downloads->Pre-releases, navigate to release of interest.

There is no "masking behind", if you go this route you always get connected
to our main ftp, which is in Paris.

I just tried to download from this server in Prague (2-3MB/s) and
San Diego (600 KB/s), all is in between academic networks, so I can
easily see that using private provider in Seoul would drop 70 to KB/s.

> > What are the thoughts on establishing a secondary presence on an external
> > site (Github, GitLab, etc.) that releases and signatures, etc. would be
> > hosted on?  Even if this was informal for testers, etc., it might provide
> > hosting with additional bandwidth at no cost.

We alread have that and call it ftp mirrors, but you need to select them 
manually.
I would suggest, that you try to download from japanese mirror in Seoul
and american (UCSD) mirror in US and report back if your download speed is 
better.

If that does not help you might want write to your senator regarding the net 
neutrality :)
Jokes aside, if there is wider complaint from other users, we can explain more
clearly on the web, that we have mirrors or use services which have automatic
mirror forwarding according to your location (I believe sourceforge was doing
it some time ago).

Pavel



Re: SSH problem

2018-01-22 Thread Kornel Benko
Am Montag, 22. Januar 2018 um 15:47:27, schrieb Jean-Marc Lasgouttes 

> Le 22/01/2018 à 15:41, Jean-Marc Lasgouttes a écrit :
> > Le 22/01/2018 à 15:23, Jürgen Spitzmüller a écrit :
> >> Any idea? Do I need to create and submit new SSH keys? And if so, to
> >> whom?
> > 
> > Indeed, your existing key for git uses ssh-dss. It might be a good thing 
> > to generate a new one and send the public part to me. I'll update it on 
> > the server.
> > 
> > JMarc
> 
> Note to others: I see 9 of you still using ssh-dss. It is probably time 
> to upgrade...
> 
> JMarc

Is this the same as dsa?
# cd ~/.ssh
# file *.pub
==> id_dsa.pub: OpenSSH DSA public key

Kornel


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


lyx2lyx problems (nothing to do with '--' ligatures)

2018-01-22 Thread Kornel Benko
Thanks to Günter, the ligature-problem is gone.

I expanded the lyx2lyx test so, the an error is emitted at 10th
repeated run to export lyx16x.

If two consecutive created lyx-files are identical, the test stops without 
error.
if a created lyx-file is not loadable, test stops with error.

Now, for example, export/doc/nb/Tutorial_lyx16 adds at each run following
data to the created lyx-file.

> % Added by lyx2lyx
> %  for proper underlining
> \PassOptionsToPackage{normalem}{ulem}
> \usepackage{ulem}
> \let\cite@rig\cite
> \newcommand{\b@xcite}[2][\%]{\def\def@pt{\%}\def\pas@pt{#1}
>   \mbox{\ifx\def@pt\pas@pt\cite@rig{#2}\else\cite@rig[#1]{#2}\fi}}
> \renewcommand{\underbar}[1]{{\let\cite\b@xcite\uline{#1}}}

Though this creates loadable file, it is no longer compilable.
Pdf-exporting such a file.


! LaTeX Error: Command \b@xcite already defined.
   Or name \end... illegal, see p.192 of the manual.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
  ... 
 
l.68 ...s@pt\cite@rig{#2}\else\cite@rig[#1]{#2}\fi}}
  
Your command was ignored.
Type  Ito replace it with another command,
orto continue without it.

Kornel


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


Re: Extending layouts

2018-01-22 Thread Jean-Marc Lasgouttes

Le 22/01/2018 à 10:10, racoon a écrit :
So LyX should load the library's stdinset.inc first and then load the 
code that extends it next.


Richard, who ran into similar problems as I did, suggested that LyX 
could be enhanced by automatically looking for and loading an .ext file, 
e.g. stdinset.inc.ext.


I think that is a good idea and this concept could be used for other 
sorts of layout files, like .modules.


One idea that I do not like about the .ext file idea is that it does not 
scale when you want to extend a file that has already been extended, 
which might happen if we had a site directory as proposed in 
http://www.lyx.org/trac/ticket/10326.


One idea I had about that is to change the behavior of Input (which 
searches for files in user dir, then build dir, and finally system dir) 
so that it skips to the next level when doing recursive input. Example:


* In user_dir/foo.layout, if I do "Input foo.layout", it will search in 
build dir, and then system dir

* in build_dir/foo.layout, it will try only sys_dir/foo.layout

The same will work if we add a site directory.

Would that fix your issue, or are there cases where it would not do what 
you expect?


JMarc


Extending layouts

2018-01-22 Thread racoon

I am bringing over a topic from the general list for dev discussion:

By default LyX loads standard layouts and insets. Is there a way to 
extend them without overwriting the default .inc file and without using 
a module?


Let's say I want to extend the standard Note style.

I don't want to use a module since I want to make a non-optional change 
to the Note inset. For example, I want to use another font size for all 
LyX notes.


If I understood correctly, I can just put a copy of the stdinset.inc 
file from the library to the user directory. But this will have the 
unwelcome effect to overwrite whatever is in the stdinset.inc in the 
library directory. So, to avoid unwanted consequences, I will have to 
update my user stdinset.inc every time the library stdinset.inc changes, 
for example, in a new version of LyX.


So I would rather like to *extend* the current library file by just the 
font-size changes by


InsetLayout Note:Note
CopyStyle Note
Font
Size Small
EndFont
End

So LyX should load the library's stdinset.inc first and then load the 
code that extends it next.


Richard, who ran into similar problems as I did, suggested that LyX 
could be enhanced by automatically looking for and loading an .ext file, 
e.g. stdinset.inc.ext.


I think that is a good idea and this concept could be used for other 
sorts of layout files, like .modules.


Daniel