Re: ext_copy.py

[Richard Heck]

On 05/04/2017 07:15 PM, Andrew Parsloe wrote:
> I would like to see the following small change made to the script
> ext_copy.py for 2.3.0:
>
> Currently it contains the lines:
>
> # output directory
> to_dir = args[1]
> if targext != '.':
> to_dir += "." + targext
>
> Change this to
>
> # output directory
> if targext == '+':
> to_dir = os.path.dirname(args[1])
> else:
> to_dir = args[1]
> if targext != '.':
> to_dir += "." + targext
>
> With the change, by using the option -t + this allows a file to be
> copied back to the document directory at the same level and not
> 'buried' in a subdirectory. Some years ago I asked about this and
> Richard explained the need to use a subdirectory to prevent the
> document directory being swamped by sundry files from html export. But
> there are other use cases. I have one in which a single file is copied
> back. Not to be able to place it directly in the document directory
> seems an arbitrary and unnecessary restriction. With my proposed change
>
> python -tt $$s/scripts/ext_copy.py -e lyxdat -t + $$i $$o
>
> copies .lyxdat back to the home directory of .lyx.
> Without the + option, ext_copy.py behaves as before. (Whether + is an
> appropriate character is moot. The natural one would perhaps be . but
> that is already used.)

No objection from me.

Richard

Re: 2.3.0alpha1-1 round 2

[Scott Kostyshak]

On Wed, May 03, 2017 at 07:32:36PM -0400, Scott Kostyshak wrote:
> 
> Thanks for checking the signatures, Uwe. To be sure, I'll send the tars
> and sigs to Kornel before uploading them to the FTP.

Kornel confirmed the signatures look good. I pushed 2.3.0alpha1-1 and
uploaded the tars and binaries to our FTP. I'll wait some time for
mirrors to update and then send the announcement emails.

Scott


signature.asc
Description: PGP signature

Re: Default to Qt 4 or Qt 5 with our build systems?

[Scott Kostyshak]

On Thu, May 04, 2017 at 10:30:11PM +0200, Guillaume MM wrote:
> Le 04/05/2017 à 19:43, Pavel Sanda a écrit :
> > Guillaume MM wrote:
> > > Le 01/05/2017 ?? 18:43, Jean-Marc Lasgouttes a écrit :
> > > > We can define a lower bound for acceptable qt5 version like we do for
> > > > python 3 vs 2. I would not want a crappy qt 5.1 on a system with a
> > > > perfectly valid qt4.8.
> > > > 
> > > > Note that the end of life warning is not relevant on old systems (in 
> > > > Linux
> > > > world).
> > > > 
> > > > So, what is the minimal good qt5 version ?
> > > 
> > > Qt 5.5.1 AFAICR
> > 
> > -> RELEASE_NOTES ?
> > 
> 
> The INSTALL file is up to date. It recommends 5.6 and suggests 5.4 at least.
> 5.4 is good in theory (this was lowered after some bugs were fixed), 5.5.1
> got more testing. There is no definitive answer here.

+1

Should we also put it in RELEASE-NOTES or should we keep that only for
when something changes with respect to the previous major version?

Scott


signature.asc
Description: PGP signature

Re: attic/id_UserGuide iconv errors

[Scott Kostyshak]

On Thu, May 04, 2017 at 08:15:23PM +0200, Kornel Benko wrote:

> Thanks for the testcase.

Yes thanks for taking care of that.

Scott


signature.asc
Description: PGP signature

ext_copy.py

[Andrew Parsloe]

I would like to see the following small change made to the script 
ext_copy.py for 2.3.0:


Currently it contains the lines:

# output directory
to_dir = args[1]
if targext != '.':
to_dir += "." + targext

Change this to

# output directory
if targext == '+':
to_dir = os.path.dirname(args[1])
else:
to_dir = args[1]
if targext != '.':
to_dir += "." + targext

With the change, by using the option -t + this allows a file to be 
copied back to the document directory at the same level and not 'buried' 
in a subdirectory. Some years ago I asked about this and Richard 
explained the need to use a subdirectory to prevent the document 
directory being swamped by sundry files from html export. But there are 
other use cases. I have one in which a single file is copied back. Not 
to be able to place it directly in the document directory seems an 
arbitrary and unnecessary restriction. With my proposed change


python -tt $$s/scripts/ext_copy.py -e lyxdat -t + $$i $$o

copies .lyxdat back to the home directory of .lyx. 
Without the + option, ext_copy.py behaves as before. (Whether + is an 
appropriate character is moot. The natural one would perhaps be . but 
that is already used.)


Andrew

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

Re: [patch] support for document class option leqno

[Guenter Milde]

On 2017-05-03, Uwe Stöhr wrote:
> El 03.05.2017 a las 12:05, Jean-Marc Lasgouttes escribió:

...

>> So you are telling me that, when you use plain babel (TeX fonts) and 
>> arabic language, without any fancy leqno option, you do not see that the 
>> number is on the left without asking for it??? I am surprised.

> I don't understand. Yes, without the option leqno I always get the 
> numbers on the right side.

Also if you set the language to Arabic or Hebrew?

...

>> This is half-baked, IMO. Either it is super important to have a 
>> click-click interface instead of writing leqno in a text field in 
>> Document Settings, or it is not.

...
> Supporting reqno requires an explicit call of amsmath. 

This is IMO rather an argument pro "reqno" setting: 
It would be a benefit to the users if LyX takes care of the requirements.
We have the "requirements" framework in LyX, so this should be
(relatively) easy to implement.

> Moreover document classes that already don't use the default placement
> have a special reason to do so. I think we should distinguish between
> standard classes (all I know use right numbering as default) that can
> be used for texts you can design freely, and document classes for
> journals that are designed to follow publishing guidelines. With these
> journal classes the user is not allowed to format freely. Therefore I
> don't want to offer an option that would overwrite a setting that was
> most probably set to follow a submission guideline.

The AMS provides the "amsart" and "amsbook" classes that are (in your
above categorization) more "standard" than special "classes for
journals". Both default to left equation numbers and (via the required
"amsmath") provide the "reqno" option to override this default.

LyX has native support for both amsart and amsbook, so special GUI
support for "leqno" but not "reqno" seems inconsistent.

Günter

Re: Default to Qt 4 or Qt 5 with our build systems?

[Guillaume MM]

Le 04/05/2017 à 19:43, Pavel Sanda a écrit :

Guillaume MM wrote:

Le 01/05/2017 ?? 18:43, Jean-Marc Lasgouttes a écrit :

We can define a lower bound for acceptable qt5 version like we do for
python 3 vs 2. I would not want a crappy qt 5.1 on a system with a
perfectly valid qt4.8.

Note that the end of life warning is not relevant on old systems (in Linux
world).

So, what is the minimal good qt5 version ?


Qt 5.5.1 AFAICR


-> RELEASE_NOTES ?



The INSTALL file is up to date. It recommends 5.6 and suggests 5.4 at 
least. 5.4 is good in theory (this was lowered after some bugs were 
fixed), 5.5.1 got more testing. There is no definitive answer here.

Re: attic/id_UserGuide iconv errors

[Kornel Benko]

Am Donnerstag, 4. Mai 2017 um 16:08:41, schrieb Guenter Milde 


...

> I checked 0x2018, it's the LEFT SINGLE QUOTATION MARK ‘.
> 
> This appears 2 times in id_UserGuide.lyx:
> 
>   28091: description "The quote sign is output by writing ‘ \"\"\"\" '"
>   43702:  It is recommended that you always include ‘.' as one of the paths; 
> otherwise
> 
> The first one is in a description in a "CommandInset nomenclature" and is
> not found with "Search" in LyX.
> 
> The minimal example is just a copy of the nomenclature inset in a document
> with an encoding not supporting ‘.
> 
> Actually, its a general problem with unencodable characters in a
> nomenclature inset - should be reported as lyxbug (if not already done).
> 
> I fixed attic/id_UserGuide and added a minimal, specific test case to the
> "dedicated autotest documents".
> 
> Günter

Thanks for the testcase.

Kornel

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

Re: Default to Qt 4 or Qt 5 with our build systems?

[Pavel Sanda]

Guillaume MM wrote:
> Le 01/05/2017 ?? 18:43, Jean-Marc Lasgouttes a écrit :
>> We can define a lower bound for acceptable qt5 version like we do for 
>> python 3 vs 2. I would not want a crappy qt 5.1 on a system with a 
>> perfectly valid qt4.8.
>>
>> Note that the end of life warning is not relevant on old systems (in Linux 
>> world).
>>
>> So, what is the minimal good qt5 version ?
>
> Qt 5.5.1 AFAICR

-> RELEASE_NOTES ?

Re: attic/id_UserGuide iconv errors

[Guenter Milde]

On 2017-05-03, Kornel Benko wrote:
> Am Mittwoch, 3. Mai 2017 um 21:20:11, schrieb Guenter Milde 
> 
>> On 2017-04-30, Scott Kostyshak wrote:

>> > On current master if I do:

>> >   ctest -R "id_UserGuide_pdf2"

>> > I get a failed export, and iconv errors such as:

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

>> > I do not get the error when exporting in the GUI or when exporting on
>> > the command line.

>> > Can anyone else reproduce the test failure or is it something specific
>> > on my machine?

>> The test fails here, too:

> ...

>> Could be some strange CTest-script rewriting.

> I am confident it is not.
...

OK, so we can rule this out.

>> What happens if you use command line export "per hand"?

This time I did get an error when exporting from the GUI (as well as command
line):

 Error 84 returned from iconv when converting from UCS-4LE to ISO-8859-15: 
Invalid or incomplete multibyte or wide character
 ...
 Stopped at: 0x2018
 ...

I checked 0x2018, it's the LEFT SINGLE QUOTATION MARK ‘.

This appears 2 times in id_UserGuide.lyx:

  28091: description "The quote sign is output by writing ‘ \"\"\"\" '"
  43702:  It is recommended that you always include ‘.' as one of the paths; 
otherwise

The first one is in a description in a "CommandInset nomenclature" and is
not found with "Search" in LyX.

The minimal example is just a copy of the nomenclature inset in a document
with an encoding not supporting ‘.

Actually, its a general problem with unencodable characters in a
nomenclature inset - should be reported as lyxbug (if not already done).

I fixed attic/id_UserGuide and added a minimal, specific test case to the
"dedicated autotest documents".

Günter

Re: further add-ons for 2.3.0 ? (was: Re: Gnuplot format & converter script)

[Kornel Benko]

Am Donnerstag, 4. Mai 2017 um 01:06:44, schrieb Tommaso Cucinotta 

> As we're on this, a few other things I had in my tommaso/master [1], out of 
> which:
> I'd really love to have 3)...
> about 2) I'm stuck with recurring to Emacs-editing the first line of a .lyx 
> file every time I face that issue :-)...
> just pushed 1), needs to be tried by someone
> guess 4) might be debatable already for a 3.0 :-).
> 
> ... if there's interest in any of these, it may not be impossible to rebase 
> over the w.e. :-)

...

> 2) commit cb7a69b1
> Author: Tommaso Cucinotta 
> Date:   Wed Oct 19 11:18:10 2016 +0200
> 
>  Tolerate formats that are not supported by lyx2lyx.> 

Yes.

> 3) commit bf3cda7b
> Author: Tommaso Cucinotta 
> Date:   Sat Oct 15 01:14:02 2016 +0200
> 
>  Create new graphics from within LyX choosing a sample file to copy
>  from

Feels interesting.

> 4) commit 410ce81e
> Author: Tommaso Cucinotta 
> Date:   Wed Oct 16 22:55:40 2013 +0100
> 
>  LyX XMPP Chat
>  
>  This patch enables XMPP-based chatting within LyX.
>  
>  With contributions from Kornel Benko 
> 
> Thanks,
> 
>   T.

Would be nice to get this one into the master tree.

Kornel

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

Re: Gnuplot format & converter script

[Tommaso Cucinotta]

On 04/05/2017 11:53, Scott Kostyshak wrote:

Assuming we do want to embed the picture on the clipboard, the next


but I don't think any of this is actually working, copying from
an inset containing a real image file (.jpg) into LibreOffice,
it just inserts an XML header line, along with a seemingly useless
link to a file:///path/to/image-source.jpg, which is not displayed
on screen nor rendered in pdf (from within LibreOffice).
Perhaps M$Word users on Win are having a different experience ?

T.

Re: further add-ons for 2.3.0 ?

[Scott Kostyshak]

On Thu, May 04, 2017 at 09:29:49AM +0200, Tommaso Cucinotta wrote:
> On 04/05/2017 01:45, Scott Kostyshak wrote:
> > > I'd really love to have 3)...
> > 
> > Is it polished? Is there a trac ticket for this one? Or an archived
> > discussion?
> 
> http://www.lyx.org/trac/ticket/5962

Thanks.

I would say that there is a chance this could go into 2.3.0. I see only
feedback from Pavel. It would be nice to make sure there are no other
concerns about the interface.

Can you make a patch that includes the newer .ui file, and give it a
good test on current master? Does it feel completely polished and ready
to go to you? If so, please post the patch on lyx-devel in a separate
thread.

One final question which is important if we will put in a significant
feature at this point: do you think you will have time the next few
weeks to fix something related to this patch if bugs are found or
changes need to be made?

Thanks for your work on this issue. It is always nice to see an
8-year-old feature requests implemented! I wonder if Mark (the OP of the
trac ticket) is still a LyX user.

Scott


signature.asc
Description: PGP signature

Re: Gnuplot format & converter script

[Scott Kostyshak]

On Thu, May 04, 2017 at 07:52:00AM +0200, Tommaso Cucinotta wrote:
> On 04/05/2017 01:36, Scott Kostyshak wrote:
> > Works well! I found what I think is unexpected behavior: if I select the
> > graphics inset (e.g. after I have followed your instructions and clicked
> > on "run" and everything looks good), and copy it, I am presented with
> > the authorization dialog.  [...] Can you reproduce?
> 
> yes, and it is unexpected that the converter question comes on the Copy
> operation, not the Paste one!
> 
> In my stack trace I'm seeing
> 
> convert - Converter.cpp:462
> prepareHTMLFile - InsetGraphics.cpp:940
> ...
> writeLyXHTMLSource - Buffer.cpp:2239
> putClipboard - CutAndPaste.cpp:574
> copySelection - CutAndPaste.cpp:1042
> 
> interestingly, just above the copySelection() line, we can see:
> 
>   // We do not need to produce images, etc.
>   runparams.dryrun = true;
> 
> as a consequence, I came up with the attached patch that solves the
> annoyance for me, but I'm not expert of this area of the code, so
> can please someone review?
> (I just checked that I can still copy and paste the graphics as before)

Thanks for looking into it. It seems we are generating the image for
storing the text/html MIME on the clipboard. That actually doesn't seem
strange to me if we want to embed the image in the clipboard. Does that
actually work? I tried copy/pasting from LyX with an image to
LibreOffice and I don't get the picture. I get a placeholder. If I try
from the browser, I get the embedded picture.

Assuming we do want to embed the picture on the clipboard, the next
question is should we run the converter again? Or if the format we
already have stored for the preview is lossless (e.g. vector) then won't
it be more efficient to convert from that than to rerun the converter?
Perhaps it would just be difficult to do that.

Scott


signature.asc
Description: PGP signature

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 04.05.2017 um 10:21 schrieb Jean-Marc Lasgouttes :
> 
> Le 02/05/2017 à 22:26, mn a écrit :
>>> Mike, did ever get a chance to test with the patch that I sent? I am a
>>> bit lost whether this restores the performance. Is there a big
>>> difference in terms of memory use?
>> 
>> I tested that build.
>> I wrote about it on April 19.
> 
> I somehow missed this message.
> 
>> I liked to use it since then for anything Hebrew.
>> Performance was quite noticeably improved.
>> With Hebrew this was not perfect but much,  much better.
> 
> So we might want to include it. Stephan, what do you think. It would be nice 
> for 2.2.3 too.

I propose to include it (that’s why I CCed the lyx-devel list). 
It would be good for 2.2.3 probably. I hope to compare it with Instruments 
soon. 

Stephan

> 
>> But with Arabic it seemed too unstable overall to do anything meaningful.
>> That meant for me: long running tests in regard of memory usage were not
>> really feasible.
> 
> What do you mean by unstable? Is it related to this patch or to LyX in 
> general.
> 
>> Since my main mac machine is a traveling laptop it is also quite
>> inconvenient to have LyX sitting there idling at >0% CPU with not even a
>> document open.
> 
> This is unfortunate indeed. Is it possible to get a trace of what is hapening 
> with Instruments?
> 
>> I shelved that more rigorous looking-at-memory-thing in longer runs
>> until the official alpha would be out.
>> Searching the threads, I am confused now.
>> As I read Stephan announced some binary 'for later' quite a while ago,
>> but they are not on ftp?
> 
> Note that the patch we are discussing here is not in alpha1.
> 
>> That and my second line in this mail and snippets on the ML seemingly
>> citing stuff I never got through the list and also cannot find on the
>> archives on the net: Is there something wrong with the list?
>> Although, that might just be spillover from off-list talk or my memory
>> fooling me.
>> Are there binaries for alpha out that were announced?
> 
> I do not think so.
> 
> JMarc

Re: further add-ons for 2.3.0 ?

[Tommaso Cucinotta]

On 04/05/2017 01:45, Scott Kostyshak wrote:

I'd really love to have 3)...


Is it polished? Is there a trac ticket for this one? Or an archived
discussion?


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

thanks,

T.