Re: [LyX/master] Improve error message a bit more.

[Richard Heck]

On 05/01/2018 02:38 PM, Kornel Benko wrote:
>
> Am Dienstag, 1. Mai 2018 13:55:56 CEST schrieb Richard Heck
> :
>
> > On 04/26/2018 01:43 AM, Kornel Benko wrote:
>
> > >
>
> > > Am Donnerstag, 26. April 2018 00:44:52 CEST schrieb Richard Kimberly
>
> > > Heck :
>
> > >
>
> > > > commit 821e10154739aa23191998b88a4bb7d9e0390628
>
> > >
>
> > > > Author: Richard Kimberly Heck 
>
> > >
>
> > > > Date:   Wed Apr 25 18:43:49 2018 -0400
>
> > >
>
> > > >
>
> > >
>
> > > > Improve error message a bit more.
>
> > >
>
> > > > 
>
> > >
>
> > > > Sorry to Kornel, who had already updated sk.po!
>
> > >
>
> > >  
>
> > >
>
> > > No problem. Sometimes I wish, some messages to translate were split
>
> > > into more parts.
>
> > >
>
> > > Like
>
> > >
>
> > > bformat(_("Part 1") + _("Part 2") + ... ), from_ascii(filePath(;
>
> > >
>
> > > Is that possible?
>
> > >
>
> > >  
>
> > >
>
> > > On very long strings (see for instance the usage message) this would
>
> > > be handy.
>
> > >
>
> > >  
>
> > >
>
> >
>
> > Can you explain how that would be handy? How would you want
>
> > to split it up in this case?
>
>  
>
> Take for instance the help message.
>
> Command line switches (case sensitive):
>
> -help summarize LyX usage
>
> -userdir dir set user directory to dir
>
> -sysdir dir set system directory to dir
>
> -geometry WxH+X+Y set geometry of the main window
>
> -dbg feature[,feature]...
>
> select the features to debug.
>
> Type `lyx -dbg' to see the list of features
>
> -x [--execute] command
>
> where command is a lyx command.
>
> -e [--export] fmt
>
> where fmt is the export format of choice. Look in
>
> Tools->Preferences->File Handling->File Formats->Short Name
>
> to see which parameter (which differs from the format name
>
> in the File->Export menu) should be passed. To export to
>
> the document's default output format, use 'default'.
>
> Note that the order of -e and -x switches matters.
>
> -E [--export-to] fmt filename
>
> where fmt is the export format of choice (see --export),
>
> and filename is the destination filename.
>
> -i [--import] fmt file.xxx
>
> where fmt is the import format of choice
>
> and file.xxx is the file to be imported.
>
> -f [--force-overwrite] what
>
> where what is either `all', `main' or `none',
>
> specifying whether all files, main file only, or no files,
>
> respectively, are to be overwritten during a batch export.
>
> Anything else is equivalent to `all', but is not consumed.
>
> --ignore-error-message which
>
> allows you to ignore specific LaTeX error messages.
>
> Do not use for final documents! Currently supported values:
>
> * missing_glyphs: Fontspec `missing glyphs' error.
>
> -n [--no-remote]
>
> open documents in a new instance
>
> -r [--remote]
>
> open documents in an already running instance
>
> (a working lyxpipe is needed)
>
> -v [--verbose]
>
> report on terminal about spawned commands.
>
> -batch execute commands without launching GUI and exit.
>
> -version summarize version and build info
>
>  
>
> It would be handy if each switch would have own translation. Changing
> a dot anywhere, and you go crazy searching for the difference.
>

That one is easy: It's just a single string, and it could just be split.
I suppose the
question is: Is it worth making work now for the translators by doing so
in order
possibly to save them work later?

>  In your case,
>
>    bformat(_("The directory path to the
> document\n%1$s\n"
>
>    "contains spaces, but your TeX installation
> does "
>
>    "not allow them. You should save the file
> to a directory "
>
> "whose name does not contain spaces."),
> from_ascii(filePath(;
>
> There are 2 phrases.
>
> The directory path to the document\n%1$s\n"
>
>    "contains spaces, but your TeX installation
> does not allow them."
>
> and
>
> "You should save the file to a directory whose name does not contain
> spaces.
>

Re: [LyX/master] Improve error message a bit more.

[Richard Heck]

On 04/26/2018 01:43 AM, Kornel Benko wrote:
>
> Am Donnerstag, 26. April 2018 00:44:52 CEST schrieb Richard Kimberly
> Heck :
>
> > commit 821e10154739aa23191998b88a4bb7d9e0390628
>
> > Author: Richard Kimberly Heck 
>
> > Date:   Wed Apr 25 18:43:49 2018 -0400
>
> >
>
> > Improve error message a bit more.
>
> > 
>
> > Sorry to Kornel, who had already updated sk.po!
>
>  
>
> No problem. Sometimes I wish, some messages to translate were split
> into more parts.
>
> Like
>
> bformat(_("Part 1") + _("Part 2") + ... ), from_ascii(filePath(;
>
> Is that possible?
>
>  
>
> On very long strings (see for instance the usage message) this would
> be handy.
>
>  
>

Can you explain how that would be handy? How would you want
to split it up in this case?

Riki



signature.asc
Description: OpenPGP digital signature

Re: [LyX/master] Fix #10858 compiler warnings.

[Richard Heck]

On 05/01/2018 11:27 AM, Scott Kostyshak wrote:
> On Sat, Dec 16, 2017 at 04:41:40AM +0000, Richard Heck wrote:
>> commit b954f478e31e640f292f865a5c41c65565e5c02a
>> Author: Richard Heck 
>> Date:   Fri Dec 15 23:41:32 2017 -0500
>>
>> Fix #10858 compiler warnings.
>> ---
>>  src/mathed/InsetMathHull.cpp |   16 +++-
>>  src/support/gzstream.cpp |2 +-
>>  2 files changed, 8 insertions(+), 10 deletions(-)
> A git bisect suggests that this caused the following change for me:
>
> When I export the attached .lyx file, I get the following message in the
> terminal:
>
> mathed/InsetMath.cpp (91): InsetMath::metricsT(Text) called directly!
>
> With the non-MWE that I originally saw this, I get that message repeated
> many times.

Hmm. The attached fixes it, and also explains a bit why it's happening.

JMarc?

Riki

diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 8398347..1da9363 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -2321,8 +2321,11 @@ bool InsetMathHull::readQuiet(Lexer & lex)
 int InsetMathHull::plaintext(odocstringstream & os,
 OutputParams const & op, size_t max_length) const
 {
-   // Try enabling this now that there is a flag as requested at #2275.
-   if (buffer().isExporting() && display()) {
+   // We could put buffer().isExporting() here, as requested
+   // at #2275, but this ends up being called to construct the
+   // TOC during output, and that leads to the warning:
+   //   mathed/InsetMath.cpp (91): InsetMath::metricsT(Text) called 
directly!
+   if (0 && display()) {
Dimension dim;
TextMetricsInfo mi;
metricsT(mi, dim);

Re: LyX banner language

[Richard Heck]

On 04/26/2018 08:41 AM, Jean-Pierre Chrétien wrote:
> Le 20/04/2018 à 11:05, Jürgen Spitzmüller a écrit :
>> Am Mittwoch, den 18.04.2018, 18:05 +0200 schrieb Jean-Pierre Chrétien:
>>> What do you think?
>>
>> Frankly, I think neither of this looks really convincing. I do not have
>> a better idea myself, though.
>
> There does not seem much enthusiasm from other developers, just Kornel
> who prefers the version number alone with a large font.
>
> I'd suggest that you apply your 11107.diff patch, which replaces hard
> coded text by translatable one. It allows translators to put whatever
> appropriate sentence which fits in with their language, either a
> translation of 'The Document Processor' or just 'Welcome'.
>
> Scott ? Riki ? What is your feeling about this issue ?

That seems reasonable to me.

Riki

Re: SIGSEGV when copy/pasting a child doc

[Richard Heck]

On 04/24/2018 01:10 AM, Scott Kostyshak wrote:
> I can reproduce on master and on 2.3.x.
>
> To reproduce:
>
> 1. download the attached 3 documents and put them in the same directory.
> 2. open master_copy_from.lyx in one LyX instance
> 3. in the dialog that comes up, click "cancel"
> 4. open master_copy_to.lyx in a *separate* LyX instance
> 5. highlight the child inset in master_copy_from.lyx and do ctrl+c to copy.
> 6. go to the other LyX instance, highlight the child inset there, and do
>ctrl+v to paste.
>
> I think it's important that question1.lyx's master document (the one in
> question1.lyx's document settings) does not exist. I don't think it's
> important that child.lyx (which is included in master_copy_from.lyx)
> does not exist.
>
> I get a SIGSEGV with the attached backtrace (from master).
>
> Can anyone reproduce?

I will have a look later. For now, I'll just mention that this bug
    https://www.lyx.org/trac/ticket/10360
sounds somewhat similar.

Riki

Re: Problem with message "The file ... changed on disk."

[Richard Heck]

On 04/17/2018 03:24 AM, racoon wrote:
> On 08/04/2018 04:17, Richard Kimberly Heck wrote:
>> On 04/07/2018 06:13 PM, Scott Kostyshak wrote:
>>> On Fri, Apr 06, 2018 at 10:47:29PM +, Richard Kimberly Heck wrote:
 On 04/06/2018 04:03 AM, racoon wrote:
> Hi,
>
> I am getting the message "The file ... changed on disk." even
> though I
> just saved the file a minute ago or so and it isn't opened anywhere
> else. My hunch is that it relates to the syncing with Spider Oak. Did
> anyone experience a similar problem or know what's going on?
 That seems likely. Did the timestamp change?
>>> Not sure how useful it is, but I tested (on Linux) and if I have the
>>> .lyx file open and just use the touch command externally, I am not
>>> given
>>> the message.
>>
>> Wild guess on my part, and apparently not a good one.
>>
>> I suppose the first thing to do is to turn off Spider Oak's autosync and
>> see if that makes the problem go away.
>
> With Spider Oak tuned off I did not get the messages and they
> reappeared once it was turned on again.

OK, so there's something Spider Oak is doing when it syncs this stuff.

I have Spider Oak as well, though I don't use the auto-sync feature, but
I can activate it and see if I see the same behavior.

Riki

Re: Update on 2.3.0 situation and Windows-specific issues

[Richard Heck]

On 03/15/2018 11:45 AM, Uwe Stöhr wrote:
> Am 14.03.2018 um 04:31 schrieb Richard Heck:
>
>> If this dialog is popped at the very beginning of the installation,
>> before ANYTHING is actually done, then it is impossible that the
>> MiKTeX installation
>> should be affected.
>
> This is not true and I don't get why I cannot make this clear to you.

I was talking about whether anything would happen *as a result of
someone running
the installer*. I understand that there are *other* ways that the MiKTeX
installation can
be damaged, as happened to your mother. That is a really horrible MiKTeX
bug, and
there is nothing we can do about it.

> I decided that I cannot stand for an installer that can send many
> users into serious
> troubles despite I know a way to prevent this.

The only issue here is: Do we add a dialog of the sort in question? The
installer with
that dialog cannot cause any new problems, because either: (1) the
person installs LyX
and it updates MiKTeX just as you want; (2) the person does not install
LyX, in which
case they are in the same situation they were before, because the
installer was a no-op.
Granted, they might screw up their MiKTeX installation eventually, but
that is a
MiKTeX bug and ought to be dealt with at that level.

> The installer for LyX 2.3.1 will return to the old behavior. 

Why? Won't that just break the installations of people still using 2.2.3?

Richard

Re: popup IPA toolbar

[Richard Heck]

On 03/14/2018 01:19 PM, mike wrote:
> On 14/03/2018 16:55, Jürgen Spitzmüller wrote:
>> 2018-03-14 17:43 GMT+01:00 mike > >:
>>
>> Is there anything else I need to know on this general topic
>> because I intend to do some serious work using all this?
>>
>>
>> If you mean work as in "using the feature", then no. I suppose you
>> have read Help > Specific Manuals > Linguistics, and you are aware of
>> the wiki page http://wiki.lyx.org/LyX/LinguistLyX ?
>>
>> Jürgen
>
> Thank you very very much.  This is all totally brilliant.  Is this all
> documented in one place?  It should be.  I did look at the manual and
> the wiki but if the content of today's discussion is all in one place
> in either of them I missed it which is entirely possible.  Whoever
> developed all this is a genius/are geniuses.  I have to think it had
> to be you you are so knowledgeable about it all.  As for your answer
> to my question 'If you mean work as in "using the feature", then no'
> that's really all I need to know.  Thanks again for all your help and
> especially your patience.

Yes, Jürgen did the work on IPA and a lot of the lingusitics modules.
And yes, it's damn good work.

If there is something here that you think should be documented in one
place, then probably the wiki would be a good place to put it.
User-written documentation is a great thing, because it really reflects
the experience of someone who was coming at this stuff cold.

Richard

Re: Windows Installer: Future Issues

[Richard Heck]

On 03/13/2018 09:43 PM, Uwe Stöhr wrote:
> Am 12.03.2018 um 04:32 schrieb Richard Heck:
>
>> That is a serious mistake: to focus on "average users". But it has
>> clearly become pointless to discuss this any longer.
>
> Dear Richard,
>
> I cannot leave this commented because it is too fundamental. I tried
> to calm down, but cannot.

Pardon me if this seems presumptuous, but it does seem to me as if you
are much too invested,
emotionally, in these issues. We are talking about software.

> What is LyX for? It is a frontend for LaTeX. It is designed to hide
> LaTeX from the users. 

That is your opinion, I understand. But I disagree. It is true that LyX
makes it possible to
take advantage of LaTeX's typesetting abilities without knowing anything
about LaTeX
*as long as your needs are very basic*. It is misleading to tell people
anything else, and I do
not myself see why we should cater specially to users whose needs remain
at such a basic
level. To me, what is most valuable about LyX is how it *eases the
learning curve* for
people who are new to LaTeX. Honestly: Look at the kinds of posts we get
on lyx-users.
The great majority of these are actually about LaTeX. I wonder how many
users we LOSE
because of false advertising: users who think LyX will make it possible
for them to do all
kinds of things that you simply can't do without knowing some LaTeX.
E.g., change how
section titles are displayed. It's a very simple thing to want to do,
but it is actually very
hard to do in LyX, as opposed to Word, and for good reason.

There's a real change of mindset involved in moving from Word etc to LyX
and LaTeX
that we understate at our peril.

>> It has become a serious problem the extent to which *MiKTeX* bugs now
>> delay LyX releases,
>
> When did we had the last time a delay because of a bug in MiKTeX?

There have been at least two such occasions since I've been branch
maintainer. I can
look up the emails if you like. And this one has been really painful,
requiring three or
four different installers before we even got to the release.

> We had much, much more problems in the past with ImageMagick. I had to
> create
> many installer builds because of this program.

I know, and I have had to upload them. This is just the same problem.
LyX should not be
integrated with such programs the way it apparently is on Windows. OSX
and Linux users
do not have these issues. We do not need new installers, because the
installation of LyX is
independent of these other programs. They can be upgraded independently,
if users need
new features or bug fixes, or not, if they do not. I do not see why we
cannot do something
similar on Windows.

>> LyX was never meant to be so closely integrated with a particular LaTeX
>> distribution, and it was a mistake to make it so.
>
> Again, please try our LyX under windows by yourself before you continue.
> take a Win users without knowledge of LaTeX and they should use TeXLive. 

I am not saying you should integrate LyX instead with TeXLive. I am
saying that it
would be a lot better for everyone if the Windows installer, just as on
OSX or Linux,
ONLY installed LyX and did not try to manage everything else. To try to
do what you
have been trying to do is to try to do something *impossible*.

Please read what follows carefully.

I do understand why you'd like to manage everything on which LyX
depends: TeX,
ImageMagick, etc, etc, etc. It's a great idea to have a package
management system
that handles all those dependencies. But you are consigning yourself to
misery if you
are going to try create such a thing yourself on Windows just for LyX.
The various
Linux distributions have HUGE TEAMS of people who work on nothing else.
It is
a HUGE project to do this. Linxu distros are incredibly careful about
what updates they
incorporate into various releases; they distinguish 'long term' releases
from 'bleeding
edge' releases; and so forth. Whereas LyX on Windows, by contrast, seems
to be
vulnerable to every update of every piece of software on which it
depends. That
makes LyX, or our users, way too vulnerable to bugs that turn up in
other programs
on which we rely. Ask José about it. He has a lot of experience. And the
problems
we have just had with MiKTeX make this all the more apparent.

Granted, users who decided to install MiKTeX with LyX would still have
those
problems. But then those would be *MiKTeX* problems, not our problems, and
not problems that would delay the release of a MAJOR version for a week
or more.
Can't you see how ridiculous that is?

It's a valiant effort what you are trying to do, but in the end it has
created a huge
problem both for you and for the rest of the LyX community.

Richard

Re: Update on 2.3.0 situation and Windows-specific issues

[Richard Heck]

On 03/13/2018 09:48 PM, Uwe Stöhr wrote:
> Am 13.03.2018 um 04:17 schrieb Scott Kostyshak:
>
>> I definitely agree that every additional dialog is an additional
>> possibility for confusion. I think where we disagree is on the benefit
>> that the dialog could bring.
>
> Yes. You don't understand that users who don't about LaTeX and deny
> the update can end
> up with a completely screwed up MiKTeX. 

If this dialog is popped at the very beginning of the installation,
before ANYTHING
is actually done, then it is impossible that the MiKTeX installation
should be affected.
That is as obvious as it could possibly be. The 'install' should be a
no-op if the user
cancels.

Richard

Re: [LyX/master] Fix known_escaped_chars

[Richard Heck]

On 03/13/2018 08:34 AM, Jürgen Spitzmüller wrote:
>
> commit ab4e9adf8626e0f1d5afea59bc58ebcce341dc98
> Author: Juergen Spitzmueller
> Date:   Tue Mar 13 13:00:58 2018 +0100
>
>     Fix known_escaped_chars
>
>
> Should go to 2.3.2-staging (fixes a regression introduced by
> 624a6642e93367).

OK.

Re: Failing tex2lyx test

[Richard Heck]

On 03/13/2018 08:03 AM, Jürgen Spitzmüller wrote:
> 2018-03-13 12:24 GMT+01:00 Kornel Benko  >:
>
> #0  strlen () at ../sysdeps/x86_64/strlen.S:106
> #1  0x7f5abf26043c in std::__cxx11::basic_string std::char_traits, std::allocator >::compare(char
> const*) const ()
> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #2  0x005b403d in std::operator== std::char_traits,
> std::allocator > (__lhs=" ",
>     __rhs=0x34333231302b2d20  0x34333231302b2d20>)
>     at /usr/include/c++/5/bits/basic_string.h:4939
> #3  0x0060c359 in lyx::is_known (str=" ",
>     what=0x72c5a0  namespace)::known_escaped_chars+64>)
>     at /usr2/src/lyx/lyx-git/src/tex2lyx/tex2lyx.cpp:84
>
>  
> Oh, I see. Silly me. Should be fixed in master (at least the crash).
> Is the other issue fixed as well?
>
> In any case, should also go to 2.3.2-staging.

OK.

rh

Re: Diagnosing a crash

[Richard Heck]

On 03/12/2018 07:36 PM, Paul A. Rubin wrote:
> Hi all,
>
> I have a very perplexing but utterly repeatable crash that I'm trying
> to diagnose, to determine whether I should file a ticket (or whether
> it's not a LyX issue). I'd appreciate any insight. Apologies for the
> length of what follows.

Any time LyX crashes, it is a problem. The error may be coming from
elsewhere, but we should deal with it. So I'd suggest filing a ticket.

Richard

Re: [LyX/master] Paint \dot & \ddot more like a dot

[Richard Heck]

On 03/12/2018 09:31 AM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> commit e41c80e224bfd89497e9cf9ddea73f1e635587e8
>> Author: Pavel Sanda 
>> Date:   Mon Mar 12 13:40:52 2018 +0100
>>
>> Paint \dot & \ddot more like a dot
>> 
>> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg204183.html
> Richard this might go to 2.3 as well if you want.
> But it needs ack from mac and win person that \ddot & \dot works as expected 
> there.

Fine for 2.3.2-staging when you get confirmation.

Richard

Re: Windows Installer: Future Issues

[Richard Heck]

On 03/12/2018 12:44 AM, Andrew Parsloe wrote:
> On 12/03/2018 4:32 p.m., Richard Heck wrote:
>> On 03/11/2018 04:52 PM, Uwe Stöhr wrote:
>>> Am 11.03.2018 um 18:12 schrieb Scott Kostyshak:
>>>
>>>> I think that's what we're doing. The basic disagreement we have is
>>>> that
>>>> I think adding a dialog will bring more benefit than harm.
>>> And I made clear why I am opposed to this.
>>> In the end it costs my spare time if something does not work. Users
>>> will contact me in this case. Therefore I focus on average users.
>> That is a serious mistake: to focus on "average users". But it has
>> clearly become pointless to discuss this any longer.
>>
>> If users are contacting YOU because of issues with the installer, then
>> that is the problem, as others have already said.
>>
>> I do not know how we should resolve this matter now. But, longer term,
>> we need someone to create a Windows installer that JUST installs LyX,
>> much the way the OSX installer does. As JMarc said, users on OSX seem to
>> manage to install a LaTeX distribution, etc, independently. Surely
>> Windows users can manage to do the same.
>>
>> It has become a serious problem the extent to which *MiKTeX* bugs now
>> delay LyX releases, require updated installers (two or three for every
>> minor version), and the like. And the problems of 'average users', so
>> far as I can see, are almost all due to tight integration with MiKTeX.
>> It is far from clear to me why we actively promote, and almost require,
>> on Windows, the use of a LaTeX distribution that is so unstable that
>> simply reconfiguring LyX can (apparently) break it.
>>
>> LyX was never meant to be so closely integrated with a particular LaTeX
>> distribution, and it was a mistake to make it so. I understand the
>> desire to offer a simpler installation process that gives the user a
>> fully functional LyX installation (though, since no such thing is
>> offered on any other platform, I'm a bit skeptical about how essential
>> this really is). But, at the very least, if we are going to 'integrate'
>> some LaTeX distribution into an offical LyX product, then we should make
>> it one that is stable: the LaTeX equivalent of an Ubuntu LTS release,
>> that cannot so easily be broken.
>>
>> Richard
>>
> Uwe provides two installers at present, one of which does NOT install
> MiKTeX and which could be used, if I understand right, with any LaTeX
> distribution (or at least TeXLive or MiKTeX). This is the one that
> I've always used -- mainly from using dial up until a few years ago. 
> The bundle installer was far too big to download by dial up. I used
> Uwe's installer-1 for 2.3.0 and have used 2.3.0 every day through the
> problem period without issues. Possibly the lack of problems for me is
> because I didn't use the MiKTeX console for updating MiKTeX but the
> older update program (miktex-update_admin.exe). (In fact I wasn't
> aware that there was such a thing as the console until reading about
> it in the present discussion.)

I know there are these two installers, but it was my understanding from
the present discussion that even the basic installer was affected by the
MiKTeX bugs we've been fighting. Perhaps I misunderstood, but Scott
asked a very explicit question along those lines.

If you're right, then perhaps what we need to do is simply offer the
basic installer 'officially' and not the bundle.

Richard

Windows Installer: Future Issues

[Richard Heck]

On 03/11/2018 04:52 PM, Uwe Stöhr wrote:
> Am 11.03.2018 um 18:12 schrieb Scott Kostyshak:
>
>> I think that's what we're doing. The basic disagreement we have is that
>> I think adding a dialog will bring more benefit than harm.
>
> And I made clear why I am opposed to this.
> In the end it costs my spare time if something does not work. Users
> will contact me in this case. Therefore I focus on average users. 

That is a serious mistake: to focus on "average users". But it has
clearly become pointless to discuss this any longer.

If users are contacting YOU because of issues with the installer, then
that is the problem, as others have already said.

I do not know how we should resolve this matter now. But, longer term,
we need someone to create a Windows installer that JUST installs LyX,
much the way the OSX installer does. As JMarc said, users on OSX seem to
manage to install a LaTeX distribution, etc, independently. Surely
Windows users can manage to do the same.

It has become a serious problem the extent to which *MiKTeX* bugs now
delay LyX releases, require updated installers (two or three for every
minor version), and the like. And the problems of 'average users', so
far as I can see, are almost all due to tight integration with MiKTeX.
It is far from clear to me why we actively promote, and almost require,
on Windows, the use of a LaTeX distribution that is so unstable that
simply reconfiguring LyX can (apparently) break it.

LyX was never meant to be so closely integrated with a particular LaTeX
distribution, and it was a mistake to make it so. I understand the
desire to offer a simpler installation process that gives the user a
fully functional LyX installation (though, since no such thing is
offered on any other platform, I'm a bit skeptical about how essential
this really is). But, at the very least, if we are going to 'integrate'
some LaTeX distribution into an offical LyX product, then we should make
it one that is stable: the LaTeX equivalent of an Ubuntu LTS release,
that cannot so easily be broken.

Richard

Re: [LyX/master] tex2lyx: support tipa \t*{} macro.

[Richard Heck]

On 03/11/2018 01:38 PM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 11.03.2018, 11:47 +0100 schrieb Juergen Spitzmueller:
>> commit cc6f2dae8219b40cd8602f70110926296403a0f7
>> Author: Juergen Spitzmueller
>> Date:   Sun Mar 11 11:46:37 2018 +0100
>>
>> tex2lyx: support tipa \t*{} macro.
> Another candidate for 2.3.2-staging.
>
> Furthermore this one (who was not sent to the lyx-cvs list for some
> reason):
>
> http://www.lyx.org/trac/changeset/8184f08f4af/lyxgit

OK.

rh

Re: Update on 2.3.0 situation and Windows-specific issues

[Richard Heck]

On 03/11/2018 01:12 PM, Scott Kostyshak wrote:
> On Sun, Mar 11, 2018 at 04:34:49PM +, Uwe Stöhr wrote:
>> Am 11.03.2018 um 05:08 schrieb Scott Kostyshak:
>>
 So there are already 3 possible workarounds for experienced users in the 
 LyX
 installer and these options are all translated.
>>> That behavior sounds good. My concern though is that even experienced
>>> users will not guess that LyX will update MiKTeX. Once they realize, it
>>> may be too late.
>> Can we please focus on the basics?
> I think that's what we're doing. The basic disagreement we have is that
> I think adding a dialog will bring more benefit than harm. You disagree.
> This is the basic disagreement we must focus on. From this disagreement,
> everything else follows. The only decision we need to make as a group is
> whether to provide this extra dialog or not.

I cannot for the life of me see why adding a warning that proceeding
with the installation will require updating MikTeX, and giving the user
the option to abort the installation, could cause any problems at all.
If there's a worry that this will confuse some users, then we could add
text that says something like: If you do not use LaTeX outside of LyX,
then it is safe for you to proceed.

Richard

Re: [LyX/master] tex2lyx: support for URW Classico, MinionPro and the new Libertine fonts.

[Richard Heck]

On 03/11/2018 06:14 AM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 11.03.2018, 11:13 +0100 schrieb Juergen Spitzmueller:
>> commit a3836d990926dfd8e7e35b266274c372c72206ce
>> Author: Juergen Spitzmueller 
>> Date:   Sun Mar 11 11:12:42 2018 +0100
>>
>> tex2lyx: support for URW Classico, MinionPro and the new
>> Libertine fonts.
>> ---
> Candidate for 2.3.2-staging.

OK.

RK

Re: Update on 2.3.0 situation and Windows-specific issues

[Richard Heck]

On 03/09/2018 09:16 AM, Uwe Stöhr wrote:
> Am 09.03.2018 um 05:58 schrieb Uwe Stöhr:
>
>> Am 09.03.2018 um 05:34 schrieb Scott Kostyshak:
>>
>>>  From what I understand, I think we still need to come to an
>>> agreement on
>>> whether to provide a dialog to the user asking if they would like to
>>> either cancel the installation or proceed and have the installer update
>>> MiKTeX.
>>
>> Please, I wrote now so many mails explaining the situation! I cannot
>> do more.
>
> The feedback from user Elloh on the list encourages me to act. His
> screwed MiKTeX was the result that the installer for LyX 2.2.3 cannot
> update the system, even if you choose during the installation process
> to do so. Therefore I fear that users installing LyX 2.2.3 will get
> similar problems.
>
> Richard, can I release a new installer for LyX 2.2.3 or do you release
> 2.2.4 within few days?

We will be releasing 2.2.4 shortly.

Richard

Re: [LyX/master] tex2lyx: chapterbib support

[Richard Heck]

On 03/09/2018 07:32 AM, Jürgen Spitzmüller wrote:
> Am Freitag, den 09.03.2018, 13:31 +0100 schrieb Juergen Spitzmueller:
>> commit af6933c06f603beca3d8684f56217243cbff1f94
>> Author: Juergen Spitzmueller
>> Date:   Fri Mar 9 13:30:52 2018 +0100
>>
>> tex2lyx: chapterbib support
> Candidate for 2.3.2-staging.

OK.

rh

Re: [LyX/master] Fix crash when citeengine is unknown.

[Richard Heck]

On 02/16/2018 12:24 PM, Jürgen Spitzmüller wrote:
> 2018-02-16 18:05 GMT+01:00 Richard Heck  <mailto:rgh...@lyx.org>>:
>
> On 02/14/2018 01:21 PM, Jürgen Spitzmüller wrote:
> > Am Mittwoch, den 14.02.2018, 12:50 -0500 schrieb Richard Heck:
> >> I wonder if what we really need to do here is add the 'unknown'
> cite
> >> engine the way we do unknown layouts. Otherwise, if, say, the
> font is
> >> modified in Document>Settings, then I am guessing we won't save the
> >> document with the same engine it had before: It isn't known there.
> >> That
> >> would mean we needed some other way to tell if the engine was
> 'real',
> >> rather than testing the pointer, but we do all of this with
> 'unknown'
> >> layouts.
> > Makes sense. Alas, I cannot look more closely now. Heading off to a
> > conference.
>
> I can have a look at this next week if you like. Good little
> project
>
>
> Yes, please.

Question that popped up while looking at this

Is it possible for more than one citeengine to be loaded by a document
at one
time? If so, how (other than by editing the LyX file itself)? Assuming
it is not
possible, then is it OK to change BufferParams::cite_engine_ to a
std::string
(and simplify code elsewhere)?

Richard

Re: Update on 2.3.0 situation and Windows-specific issues

[Richard Heck]

On 03/08/2018 12:08 AM, Scott Kostyshak wrote:
> On Sat, Mar 03, 2018 at 08:26:17PM +, Scott Kostyshak wrote:
>
>> If we do not go forward with the release as discussed in the preceding
>> paragraph, another question is: should we wait another few days to see
>> if we are ready to release the Windows binaries so we can announce
>> everything together, or should we announce without the Windows binaries?
> I'm still interested in your thoughts on the above. From what I
> understand, there are still pending MiKTeX bugs for which we are waiting
> for fixes. Releasing now without the Windows binaries would take some
> pressure off: We can wait for the MiKTeX bug fixes, produce a new
> installer, and get some testing of the installer without rushing and
> without delaying the rest of the 2.3.0 release.
>
> On the other hand, of course it is nice to release everything together,
> and releasing without Windows binaries might cause some confusion to
> users.

Did you suggest at one point releasing just the installer and not the
bundle? Can we do that? It seems unfortunate to delay the release
altogether just because MiKTeX has bugs.

Richard

Re: [LyX/master] Fix the implementation of new libertine package

[Richard Heck]

On 03/06/2018 02:01 AM, Jürgen Spitzmüller wrote:
> Am Samstag, den 03.03.2018, 08:29 +0100 schrieb Jürgen Spitzmüller:
>> Am Freitag, den 02.03.2018, 12:18 +0100 schrieb Juergen Spitzmueller:
>>> commit 905516fd706a90148a458f9936c565cbe5fcfcff
>>> Author: Juergen Spitzmueller
>>> Date:   Fri Mar 2 12:17:33 2018 +0100
>>>
>>> Fix the implementation of new libertine package
>>> 
>>> Needs to go to 2.3.1-staging
>> Jürgen
> Richard, did you see this?

Apparently not. Go ahead

rh




signature.asc
Description: OpenPGP digital signature

Re: Solution: Summary for the Win installer problem

[Richard Heck]

On 03/05/2018 07:33 PM, Uwe Stöhr wrote:
> Am 05.03.2018 um 23:46 schrieb Richard Heck:
>
>> Uwe, even if LyX will not work without the updated installation, we
>> CANNOT update the user's LaTeX installation without asking for
>> permission---which means giving them the option to cancel the entire
>> install. Otherwise, we can break things, as in the thread Scott posted.
>
> What? So I should deliver a LyX installer leading to a broken LaTeX
> that can only be fixed by reinstalling MiKTeX? That cannot be the goal!

The proposal is to *abort* the LyX installation, if the user does not
want to update. You can explain in a dialog that LyX will not work
otherwise. But you cannot screw with their system without their
permission. Really.

The obvious thing here is to ask about this before doing anything else.
Do not touch ANYTHING until you have permission to proceed.

> I don't get your point. What is the problem of updating a package
> handling system?

The point is that we do not affect people's systems without permission.
Otherwise, we get reports like
    https://latex.org/forum/viewtopic.php?f=19&t=30919
which is unacceptable.

> Under Linux you also have to do this if you want to be able to obtain
> packages in future.
> In this case it is even worse, whenever you you decide to update
> packages by yourself and invoke MiKTeX's update manually you break
> your package handling system. So also LyX 2.2.3 users can get a broken
> system even without installing LyX. But the consequence is that they
> then cannot user LyX anymore.

This sounds like a MiKTeX bug that we do not need to make worse.

Frankly, I find the whole Windows packaging system deeply worrying. We
do not do anything like this on OSX---package some TeX distribution with
our own code---and I am not sure you understand the way Linux works. For
one thing, there is no single way Linux works, since all of this is
highly dependent upon the distribution. And note: If some Linux distro
messes this up, then WE do not get blamed for it, because WE do not
release those packages.

As Scott said some time ago, it is very strange indeed if LyX's basic
functionality breaks because of a change in some external program's
package-handling mechanism. LyX should not be that entwined with
external programs.

Richard

Re: Solution: Summary for the Win installer problem

[Richard Heck]

On 03/05/2018 03:18 PM, racoon wrote:
> On 05.03.2018 20:16, Uwe Stöhr wrote:
>> Am 05.03.2018 um 19:37 schrieb racoon:
>>
>>> However, it does not give the user a choice on whether to update
>>> MiKTeX or not.
>>
>> Yes, that is correct and I explained now in several mails why and
>> that there is no other option.
>
> Sorry, I have a bit of a hard time following the discussion.
>
> Why is forcing the user to make a choice between going ahead with the
> setup and cancelling no option?

Uwe, even if LyX will not work without the updated installation, we
CANNOT update the user's LaTeX installation without asking for
permission---which means giving them the option to cancel the entire
install. Otherwise, we can break things, as in the thread Scott posted.

Richard

Re: [LyX/master] tex2lyx: support biblatex

[Richard Heck]

On 03/05/2018 07:03 AM, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
>> I thought 2.3.1 was supposed to be either for urgent stuff or just be 
>> merged with 2.3.2. No I do not know...
> My understanding was similar, i.e. 2.3.2-staging will be actually merged
> into 2.3.1 if there is no immediate 2.3.1 release fixing some urgent 
> problem...

Yes.

rh

Re: [LyX/master] tex2lyx: support biblatex

[Richard Heck]

On 03/05/2018 03:37 AM, Jürgen Spitzmüller wrote:
> Am Montag, den 05.03.2018, 09:32 +0100 schrieb Jean-Marc Lasgouttes:
>> I thought 2.3.1 was supposed to be either for urgent stuff or just
>> be 
>> merged with 2.3.2. No I do not know...
> I thought, since 2.3.1-staging does not contains really urgent stuff,
> that 2.3.1 is released with urgent fixes (but without staging) if
> urgent issues arise, and else with 2.3.1 staging.

My thought was: urgent stuff and super-duper-safe stuff to
2.3.1-staging, in case we need an
emergency release.

This one looks a bit more extensive. I'd say 2.3.2-staging for now.

rh

Re: [LyX/master] tex2lyx: support qualified citation lists (biblatex)

[Richard Heck]

On 03/04/2018 02:14 PM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 04.03.2018, 20:12 +0100 schrieb Juergen Spitzmueller:
>> commit 0915e814814ab26732b6dd13fc1740cfbf64b5b4
>> Author: Juergen Spitzmueller
>> Date:   Sun Mar 4 20:12:27 2018 +0100
>>
>> tex2lyx: support qualified citation lists (biblatex)
> This one's rather 2.3.2 stuff.

OK.

r

Re: [LyX/master] tex2lyx: refsection and bibbysection support (biblatex)

[Richard Heck]

On 03/04/2018 11:31 AM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 04.03.2018, 17:30 +0100 schrieb Juergen Spitzmueller:
>> commit 1a3dbbf07ad837a685af93bf3d1d1a784e0d27ae
>> Author: Juergen Spitzmueller 
>> Date:   Sun Mar 4 17:29:59 2018 +0100
>>
>> tex2lyx: refsection and bibbysection support (biblatex)
> Candidate for 2.3.1.

OK.

rh

Re: [LyX/master] tex2lyx: consider options passed via \PassOptionsToPackage

[Richard Heck]

On 03/04/2018 10:50 AM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 04.03.2018, 16:48 +0100 schrieb Juergen Spitzmueller:
>> commit 476401a76f8bdb3dd2c2a482b2088f00dbe501d9
>> Author: Juergen Spitzmueller
>> Date:   Sun Mar 4 16:45:37 2018 +0100
>>
>> tex2lyx: consider options passed via \PassOptionsToPackage
> Candidate for 2.3.1.

OK.

rh

Re: Summary for the Win installer problem

[Richard Heck]

On 03/02/2018 02:16 PM, Uwe Stöhr wrote:
> Here is the final analysis:
>
> - there is definitely no Virus or so, these false positives can be
> ignored
>
> - there is a bug in LyX we need to fix:
> https://www.lyx.org/trac/ticket/11053
>
> - I created a new installer that forces a silent MiKTeX update. This
> assures that every user gets the current MiKTeX package handling system.

I don't know a lot about Windows, but let me just ask: Do we really want
to force people to upgrade some other package when they install LyX? And
do it without asking? Might they not be using MiKTeX otherwise and not
want to upgrade it?

Richard

Re: [LyX/master] Filter in citation dialog is not respected when reloading databaze.

[Richard Heck]

On 03/01/2018 06:52 PM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> commit 3cb271cedad2e75c8f8e1860119d6b326d90c186
>> Author: Pavel Sanda 
>> Date:   Fri Mar 2 00:49:15 2018 +0100
>>
>> Filter in citation dialog is not respected when reloading databaze.
>> ---
>>  src/frontends/qt4/GuiCitation.cpp |1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/frontends/qt4/GuiCitation.cpp 
>> b/src/frontends/qt4/GuiCitation.cpp
>> index d7d225b..cc1e7e5 100644
>> --- a/src/frontends/qt4/GuiCitation.cpp
>> +++ b/src/frontends/qt4/GuiCitation.cpp
>> @@ -233,6 +233,7 @@ void GuiCitation::on_restorePB_clicked()
>>  {
>>  init();
>>  updateFilterHint();
>> +filterPressed();
>>  }
> I actually wondered why updateFilterHint is used here.
> Anyway, what about 2.3.2-staging? 

OK.

Richard

Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #794

[Richard Heck]

On 02/28/2018 01:25 PM, ci-...@inria.fr wrote:
> https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/794/--
> Started by an SCM change
> Building remotely on lyx-linux1 (linux) in workspace 
> 
> [WS-CLEANUP] Deleting project workspace...
> java.io.IOException: Failed to mkdirs: 
> 
>   at hudson.FilePath.mkdirs(FilePath.java:1191)

Out of disk space?

Re: Planning to announce 2.3.0 around 17h00 UTC

[Richard Heck]

On 02/28/2018 01:11 AM, Scott Kostyshak wrote:
> I'm planning to announce 2.3.0 around 17h00 UTC unless someone reports a
> major issue and suggests delaying.
>
> The biggest pending issue is that the 2.3.0 Windows binary is not
> working for racoon, but perhaps this is because of having tested
> pre-releases. The Windows installer seems to work fine for a couple of
> others on the list, so I'm not sure what's wrong.

It looks to me as though we have a problem on Windows. At least two
users reported
a failure to find pdflatex.exe after installation. I'd prefer to delay
the release rather than
have that problem affect tons of people.

Richard

Re: Tar balls and binaries have been uploaded

[Richard Heck]

On 02/27/2018 12:12 PM, Scott Kostyshak wrote:
> On Tue, Feb 27, 2018 at 06:19:06AM +, Scott Kostyshak wrote:
>> On Mon, Feb 26, 2018 at 10:02:58PM +, Jürgen Lange wrote:
>>> Hello,
>>>
>>> the binary LyX-230-Installer-1.exe (Windows 10) downloaded from
>>>
>>> ftp://ftp.lyx.org/pub/lyx/bin/2.3.0/
>>>
>>> seems to contain Trojan:Win32/Azdem.A!cl
>> Thanks for this report, Jürgen.
>>
>> Note related reports:
>>
>> https://www.mail-archive.com/search?l=mid&q=20171227013449.i43xa5exdrgoc643%40steph
>>
>> I'm CC'ing our Windows packager.
> Note also that Qt seems to have this issue pop up as well:
>
> https://www.mail-archive.com/search?l=mid&q=CALckqK2FSPSU3SkAudKkOBLgeTs%2BuKm5XgcJPAMh3O3cf6wgjg%40mail.gmail.com
> https://www.mail-archive.com/search?l=mid&q=CAKN5Pd%3Df1TaAA-kAiqTqd5vmQjAgbyazS2isUu3cqgD6Vkwurg%40mail.gmail.com

Note that both of those emails say it is the Qt libraries that are being
flagged.

R

Re: Trac Links to HTTPS

[Richard Heck]

On 02/22/2018 04:24 PM, Jean-Marc Lasgouttes wrote:
> Le 22/02/2018 à 20:59, Richard Heck a écrit :
>> Do we necessarily want to do that? I'm not sure why someone would prefer
>> to access via http instead of https, but I'm also not sure why we
>> shouldn't
>> permit them to do so, if they so wish. This would also provide some kind
>> of protection against https failures.
>
> That would help when I click on one of those old links sent by trac
> notifications.
>
> Google.com or mozilla.org do redirect to https.

Yes, my worry is our certificate. At the moment, I'm the only one who
gets notified
when it's about to expire, etc. If it did, then of course people would
get errors when
going via https and, if we automatically redirected  Let me find
time to re-do the
certificate so that it's attached to our group developers email, and
then I'll do the
redirect.

Richard

Re: commit ca4426e broke macos-build

[Richard Heck]

On 02/25/2018 03:37 PM, Patrick De Visschere wrote:
> Commit ca4426e (bugfix #10888) broke (at least my) macos-build (qt5.10 and 
> macos 10.12);
> A change from menu to menuptr in Menus.cpp escaped attention.

Thanks. QtCreator has this great ability to rename variables, but it
skips code that's #if'd out.

Richard

Re: [LyX/master] We don't want external change to automatically marked the buffer dirty.

[Richard Heck]

On 02/25/2018 09:00 AM, Pavel Sanda wrote:
> Pavel Sanda wrote: >> commit 2df82c4a44b7f95d27070f575e69206a790edb27 Author: 
> Pavel Sanda
>>  Date: Sun Feb 25 14:49:21 2018 +0100 >> >> We don't
want external change to automatically marked the buffer >> dirty. >> >>
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg203995.html > >
>> Richard, 2.3.2?

OK.

R

Re: Trac Links to HTTPS

[Richard Heck]

On 02/22/2018 10:58 AM, Jean-Marc Lasgouttes wrote:
> Le 21/02/2018 à 18:14, Richard Heck a écrit :
>> I finally figured out how to make the links in the emails that trac
>> sends use https, so I have done that. Please let me know if there are
>> any issues.
>>
>
> Great. And what about global redirection from http to https?

Do we necessarily want to do that? I'm not sure why someone would prefer
to access via http instead of https, but I'm also not sure why we shouldn't
permit them to do so, if they so wish. This would also provide some kind
of protection against https failures.

Richard

Re: [LyX/master] Improve documentation of inset-(begin|end)(|-select)

[Richard Heck]

On 02/22/2018 11:07 AM, Jean-Marc Lasgouttes wrote:
> Le 22/02/2018 à 17:05, Jean-Marc Lasgouttes a écrit :
>> commit f4693ef8ab68c978c42bb987634eabcad92d592d
>> Author: Jean-Marc Lasgouttes 
>> Date:   Thu Feb 22 17:00:54 2018 +0100
>>
>>  Improve documentation of inset-(begin|end)(|-select)
>>   Make it clear that it can go at the beginning/end of the
>> document.
>
> Richard, in 2.3.2-staging?

OK.

Richard

Re: New policy for 2.3.x branch

[Richard Heck]

On 02/21/2018 04:48 AM, Jean-Marc Lasgouttes wrote:
> Le 20/02/2018 à 22:03, Scott Kostyshak a écrit :
>> Dear all,
>>
>> Do you have any planned commits to the 2.3.x branch before 2.3.0 is
>> released? What is the commit and by when are you prepared to commit it?
>
> I do not have any.
>
> JMarc


Nor I.

Richard

Trac Links to HTTPS

[Richard Heck]

I finally figured out how to make the links in the emails that trac
sends use https, so I have done that. Please let me know if there are
any issues.

Richard

Re: Fix Problem With Background Export Cancellation

[Richard Heck]

On 02/19/2018 11:30 PM, Scott Kostyshak wrote:
> On Tue, Feb 20, 2018 at 03:51:50AM +0000, Richard Heck wrote:
>> Please see attached patch.
> I will test this when I have time. Is there any known problem? The last
> time I tested, I just compiled the Embedded Objects manual and canceled
> it at various times (e.g. after 0.5 seconds, 1, second, 5 seconds).
> There were a lot of problems but this patch sounds like it addresses
> them.

The only problem I know if is the one mentioned: Failure actually to
abort the export, as opposed just to whatever part of it is happening at
the moment.

Richard

Fix Problem With Background Export Cancellation

[Richard Heck]

Please see attached patch.


>From 9577e22ad00c2ad13f48224b8fc5c87f9286db80 Mon Sep 17 00:00:00 2001
From: Richard Heck 
Date: Mon, 19 Feb 2018 22:43:44 -0500
Subject: [PATCH] Fix a problem with background cancellation.

The problem was that, if we killed export when some graphic was
being converted, it would only cancel that process, and then it
would just continue with the next one. To deal with that, we need
to do a few things:
1. Modify the return values for some of the Converters routines,
   so we can tell when something has been canceled.
2. Throw an exception from InsetGraphics when this has happened
   during LaTeX or HTML export, but ONLY when the Buffer is a
   clone. We shouldn't be able to 'cancel' export when we're, say,
   generating code for the preview pane, but this keeps us on the
   safe side, I think.
That exception then has to be caught, obviously, back in the
export routines in Buffer.

Probably Coverity will be unhappy about something here, but I'll
deal with that problem as it arises.
---
 src/Buffer.cpp | 13 +++--
 src/Converter.cpp  | 62 ++
 src/Converter.h| 22 ---
 src/frontends/qt4/GuiView.cpp  |  4 +--
 src/insets/ExternalSupport.cpp |  6 ++--
 src/insets/InsetGraphics.cpp   | 19 ++---
 src/insets/InsetInclude.cpp|  8 --
 7 files changed, 88 insertions(+), 46 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 7cabe6fce1..8051135bd1 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -1102,7 +1102,7 @@ bool Buffer::importFile(string const & format, FileName const & name, ErrorList
 		return false;
 
 	FileName const lyx = tempFileName("Buffer_importFileXX.lyx");
-	if (theConverters().convert(0, name, lyx, name, format, "lyx", errorList)) {
+	if (theConverters().convert(0, name, lyx, name, format, "lyx", errorList) == Converters::SUCCESS) {
 		bool const success = readFile(lyx) == ReadSuccess;
 		removeTempFile(lyx);
 		return success;
@@ -1702,6 +1702,7 @@ bool Buffer::makeLaTeXFile(FileName const & fname,
 	try {
 		writeLaTeXSource(os, original_path, runparams, output);
 	}
+	catch (ConversionException const &) { return false; }
 	catch (EncodingException const & e) {
 		docstring const failed(1, e.failed_char);
 		ostringstream oss;
@@ -2113,7 +2114,10 @@ void Buffer::makeLyXHTMLFile(FileName const & fname,
 	updateBuffer(UpdateMaster, OutputUpdate);
 	updateMacroInstances(OutputUpdate);
 
-	writeLyXHTMLSource(ofs, runparams, FullSource);
+	try {
+		writeLyXHTMLSource(ofs, runparams, FullSource);
+	}
+	catch (ConversionException const &) { return; }
 
 	ofs.close();
 	if (ofs.fail())
@@ -4298,9 +4302,12 @@ Buffer::ExportStatus Buffer::doExport(string const & target, bool put_in_tempdir
 	ErrorList & error_list = d->errorLists[error_type];
 	string const ext = theFormats().extension(format);
 	FileName const tmp_result_file(changeExtension(filename, ext));
-	bool const success = converters.convert(this, FileName(filename),
+	Converters::RetVal const retval = converters.convert(this, FileName(filename),
 		tmp_result_file, FileName(absFileName()), backend_format, format,
 		error_list);
+	if (retval == Converters::KILLED)
+		return ExportCancel;
+	bool success = (retval == Converters::SUCCESS);
 
 	// Emit the signal to show the error list or copy it back to the
 	// cloned Buffer so that it can be emitted afterwards.
diff --git a/src/Converter.cpp b/src/Converter.cpp
index d433f83c98..3d15374ff9 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -384,18 +384,20 @@ bool Converters::checkAuth(Converter const & conv, string const & doc_fname,
 }
 
 
-bool Converters::convert(Buffer const * buffer,
+Converters::RetVal Converters::convert(Buffer const * buffer,
 			 FileName const & from_file, FileName const & to_file,
 			 FileName const & orig_from,
 			 string const & from_format, string const & to_format,
 			 ErrorList & errorList, int conversionflags)
 {
 	if (from_format == to_format)
-		return move(from_format, from_file, to_file, false);
+		return move(from_format, from_file, to_file, false) ?
+		  SUCCESS : FAILURE;
 
 	if ((conversionflags & try_cache) &&
 	ConverterCache::get().inCache(orig_from, to_format))
-		return ConverterCache::get().copy(orig_from, to_format, to_file);
+		return ConverterCache::get().copy(orig_from, to_format, to_file) ?
+		  SUCCESS : FAILURE;
 
 	Graph::EdgePath edgepath = getPath(from_format, to_format);
 	if (edgepath.empty()) {
@@ -427,20 +429,20 @@ bool Converters::convert(Buffer const * buffer,
 	_("Converter killed"),
 	bformat(_("The running converter\n %1$s\nwas killed by the user."), 
 		from_utf8(command)));
-return false;
+return KILLED;
 			}
 			if (to_file.isReadableFile()) {
 if (conversionflags 

Re: Results of small poll - download speed of LyX installers & where we go from there

[Richard Heck]

On 02/19/2018 06:32 PM, Pavel Sanda wrote:
> Hi,
>
> This is what we got from the poll on users list when it comes to the download 
> speeds.
> Unfortunately the results do not include regions which I was mostly 
> interested in
> and where I saw complaints about the speed.
>
> US(CA); 1.88MB/s;  academic network;  M: UCSD(89.4MB/s), PL(6.83M/s), 
> SA(8.85M/s), GR (6.36M/s)
> US(OR); 808KB/s;   local ISP; M: UCSD(2MB/s)
> US(FL); 1.33MB/s;  residential LAN;
> US(TX); 20-100KB/s; hotel wifi;   M: UCSD(2.89MB/s), SA(1.42MB/s)(!), 
> GR(163KB/s)
> US(MI); 1.14MB/s;  residential cable; M: UCSD(11.6MB/s)
> US(NM); 7.23MB/s;  business network;  M: UCSD(23.8MB/s)
> US(NM): 90 KB/s;   residential ISP;   M: UCSD(9.5MB/s)
> Ca(Qe): 242 KB/s;  academic network;  M: UCSD(393 KB/s)
> NZ(Du); 800 kB/s;  fibre network; M: UCSD(1.4 MB/s), PL(650 kB/s), SA(540 
> kB/s), GR(780 kB/s)
> Tr;   2-3MB/s;   Turknet, local ISP;
> EU(Cz); 44.6MB/s;  academic network;  M: UCSD(16.3MB/s), PL(25.5MB/s), 
> SA(14.3MB/s), GR(12.0MB/s)
> EU(Pt); 40.8MB/s;  academic network;
> EU(Pt); 4.26MB/s;  local ISP;
> EU(De); 414KB/s;   local ISP;
> EU(De); 495KB/s;   Home-WLAN; M: UCSD(2,86 MB/s)
> Eu(De); 929 KB/s;  Office LAN;M: UCSD((6,40 MB/s))
>
>
> I'd say we don't have serious problems in EU/US, but I came up with
> neat solution for ppl suffering with connectivity problems - we could
> publish torrents for two large files we currently distribute: win bundle
> install & mac .dmg. Other are small enough to make it even on small
> ftp speeds.
>
> From our side only one change in release process is needed - 
> creating torrent and putting on ftp next to other binaries (and .sig
> file for security purpose). And perhaps one section in on Download
> page, I'll take care of this one.
>
> Richard(/Scott?) would it be doable for you to just add this one step
> on top of what you currently do while releasing?

No problem for me, but I'd need instructions.

Richard

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Richard Heck]

On 02/19/2018 01:07 PM, Jürgen Spitzmüller wrote:
> Am Montag, den 19.02.2018, 17:46 + schrieb José Abílio Matos:
>> One doubt that I have about this is if there is any difference here
>> between the file converted by lyx2lyx and the file re-saved by lyx.
>> Is there any relevant difference? (I'm leaving in really soon and I
>> do not have to test it right now)
> Most probably it is (if only the Standard that is then saved as "Plain
> Layout", but that's what seems to be intended according to the analysis
> above).

Yes, that's correct. But it will be silently corrected when the file is
loaded. That was what was intended, for the reason I gave elsewhere:
Whether to use PlainLayout is determined by a layout setting, to which
we do not have access in lyx2lyx. (Note, by the way, that if that
setting changes for some reason, then LyX will do The Right Thing and
reset to default, or PlainLayout, or whatever.)

Richard

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Richard Heck]

On 02/19/2018 10:40 AM, Jürgen Spitzmüller wrote:
> Am Montag, den 19.02.2018, 13:01 +0100 schrieb Kornel Benko:
>> OK, got it down to this:
> Excellent. Here is my analysis. 
>
> Since this is a very old document, it has "\layout Standard" in insets.
> Now as of format 315 (for LyX 1.6), we switched to "\begin_layout
> PlainLayout" and shortly afterwards "\begin_layout Plain Layout" inside
> insets. But we do not actually convert "Standard" to "Plain Layout"
> (probably since it is hard to predict where to do that and since we
> rely on LyX doing that anyway), so the insets keep having
> "\begin_layout Standard".
>
> Now the convert_separator routine (format 475) checks whether we are
> inside a text inset precisely by looking for "Plain Layout". This of
> course fails here, hence the separator is inserted (lyx_2_2.py:186ff.)
>
> I am not sure if there is an easy fix for this. The "real" fix would be
> to actually change Standard to PlainLayout in 315, but I suppose there
> were reasons for not doing that.

The one you mentioned, basically: Whether to use PlainLayout is set by
information in the layout files (ForcePlain), to which we do not have
access.

But you found a solution, so good!

Richard

Re: [LyX/2.3.2-staging] * eu.po - update from Inaki.

[Richard Heck]

On 02/17/2018 01:22 PM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> commit f135013b3075f3e077f05b5fcc2bdc9e86825f4c
>> Author: Pavel Sanda 
>> Date:   Sat Feb 17 19:01:53 2018 +0100
>>
>> * eu.po - update from Inaki.
>> commit 2136af92b5b64f4488e765f52bf5a41d27106e9c
>> Author: Pavel Sanda 
>> Date:   Sat Feb 17 19:07:02 2018 +0100
>>
>> * layouttranslations reviewed by Inaki
> .. sorry Richard, these two commits should go to 2.3.x not staging...
> I can revert, but merge will cause trouble anyway I think.

Whatever you think is best will be fine with me.

Richard

> Pavel

Re: [LyX/master] Fix crash when citeengine is unknown.

[Richard Heck]

On 02/14/2018 01:21 PM, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 14.02.2018, 12:50 -0500 schrieb Richard Heck:
>> I wonder if what we really need to do here is add the 'unknown' cite
>> engine the way we do unknown layouts. Otherwise, if, say, the font is
>> modified in Document>Settings, then I am guessing we won't save the
>> document with the same engine it had before: It isn't known there.
>> That
>> would mean we needed some other way to tell if the engine was 'real',
>> rather than testing the pointer, but we do all of this with 'unknown'
>> layouts.
> Makes sense. Alas, I cannot look more closely now. Heading off to a
> conference.

I can have a look at this next week if you like. Good little project

Richard

status.23x

[Richard Heck]

If you make any commits to the staging branches, please update the
status.23x file. Sorry to have forgotten to create it and to issue that
reminder earlier.

Richard

Re: [LyX/2.3.2-staging] Oops, asInsetGrpahics is new to master.

[Richard Heck]

On 02/15/2018 03:48 PM, Pavel Sanda wrote:
> commit 25741ca5bd2ff4c7eb55de0fabfa41bbf476c77e
> Author: Pavel Sanda 
> Date:   Thu Feb 15 21:48:23 2018 +0100
>
> Oops, asInsetGrpahics is new to master.

It would be fine to copy that into 2.3.2-staging.

Richard

Re: [LyX/master] Unify graphics-groups inside marked block functionality.

[Richard Heck]

On 02/15/2018 05:52 AM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> commit b88ed81e7f1d2f59bb606351d95e093380b4eead
>> Author: Pavel Sanda 
>> Date:   Thu Feb 8 21:33:37 2018 +0100
>>
>> Unify graphics-groups inside marked block functionality.
>> 
>> Fixes #11026.
> Richard, can this go to 2.3.2? P

Yes, sure.

rh

Re: Staging Branches

[Richard Heck]

On 02/14/2018 01:09 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>>> can we merge the painting branch into 2.3.1 staging?
>>> I'm inclusively working on master without larger issues for quite some time
>>> now. That does not say anything about mac/win arch, but the sooner we start
>>> testing the better.
>> I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is
>> reserved for emergencies, more or less.
> If you plan to wait for couple months with 2.3.1 release as stated then 
> I'm afraid I'm lost why to introduce this 2.3.1 vs 2.3.2 bifurcation, but
> whatever leads to paintbranch merge is good for me.

We don't really know how long 2.3.1 will be. There have been times in
the past did a release within a month. If we don't need to do anything
super-fast, then I'll just merge 2.3.2-staging into 2.3.1-staging.

Richard

Re: [LyX/master] Fix sideset hints, part of bug #11015.

[Richard Heck]

On 02/14/2018 01:02 PM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> commit 584b83d33c50a8bd88e1baae9b6d4dcbadcf0b82
>> Author: Pavel Sanda 
>> Date:   Sat Feb 3 17:51:00 2018 +0100
>>
>> Fix sideset hints, part of bug #11015.
> Richard, 2.3.1 or 2?

Seems fine for 2.3.1.

rh

Re: Staging Branches

[Richard Heck]

On 02/14/2018 12:17 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>> I've just created two staging branches: 2.3.1-staging and 2.3.2-staging.
>> Rules for committing to these are the same as for stable branch, i.e.,
>> clear it with me first.
> Richard/JMarc,
>
> can we merge the painting branch into 2.3.1 staging?
> I'm inclusively working on master without larger issues for quite some time
> now. That does not say anything about mac/win arch, but the sooner we start
> testing the better.

I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is
reserved for emergencies, more or less.

Richard

Re: Staging Branches

[Richard Heck]

On 02/14/2018 11:13 AM, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 14.02.2018, 10:15 -0500 schrieb Richard Heck:
>> I've just created two staging branches: 2.3.1-staging and 2.3.2-
>> staging.
>> Rules for committing to these are the same as for stable branch,
>> i.e.,
>> clear it with me first.
>>
>> As usual, the reason to create these is that we have some fixes
>> piling
>> up already, and I don't want to forget them.
> So we now have 5 branches to care for? (2.2.x, 2.3.x, the two stagings, and 
> master)

Not for very long. And things committed to 2.3.x (which is all but
closed) do not also need to be committed to the staging branches. I'll
deal with merging everything when the time comes.

Richard

Re: 2.2.4

[Richard Heck]

On 02/14/2018 12:04 PM, Guenter Milde wrote:
> On 2018-02-14, Richard Heck wrote:
>> Since we are approaching the 2.3.0 release, that means we are also
>> approaching the last release of the 2.2.x series. I'd like to freeze
>> strings and notify our translators on Sunday or Monday, so if there is
>> anything left you'd like to do there, let me know ASAP.
> You may have a look at the recent changes to lyx2lyx in master.
> There are some bugs solved and some improvements.
> OTOH, there has been no wide testing besides the ctest test suite,
> so there may be some new bugs instead of the old ones.

Probably I'll not grab that, but just lyx2lyx from 2.3.x.

Thanks, by the way, for all the work on lyx2lyx. I usually try to polish
it myself during the pre-release process, but I've just been too busy.

Richard

Re: [LyX/master] Fix crash when citeengine is unknown.

[Richard Heck]

On 02/14/2018 11:12 AM, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 14.02.2018, 10:11 -0500 schrieb Richard Heck:
>>> I wonder how that happens. 
>> LyXCiteEngine const * CiteEnginesList::operator[](string const & str)
>> const
>> {
>> LyXCiteEnginesList::const_iterator it = englist_.begin();
>> for (; it != englist_.end(); ++it)
>> if (it->getID() == str) {
>> LyXCiteEngine const & eng = *it;
>> return ŋ
>> }
>> return 0;
>> }
>>
>> The crucial point seems to be that we are in a const function, so we
>> return a null pointer. Boom.
> It didn't mean technically. That's clear. I mean how the empty string
> comes into the LyX file. Any sane LyX 2.3 document should have _some_
> cite engine set.

Oh, sorry. It's not empty in the LyX file. The value is coming from the
bibliography part of the GuiDocument:

    QString const engine =
        biblioModule->citeEngineCO->itemData(
                biblioModule->citeEngineCO->currentIndex()).toString();

This index was supposed to be set from the engine read from the LyX
file. But that engine doesn't exist, so it didn't get set properly.
Probably that needs to be taken into account.

>
>>
>>> Anyway, would be the following more safe (if
>>> we have an unknown non-empty string)?
>>>
>>>return theCiteEnginesList[fromqstr(engine)]
>>> && theCiteEnginesList[fromqstr(engine)]->getCiteFramework()
>>>== "biblatex";
>>>
>>> This should also cover the empty case.
>> Maybe what would be best is to create and use
>> CiteEnginesList::hasEngine(const & string). Then add an assertion to the 
>> function quoted above. This is how things are done in other places.
> Maybe, but for now, isn't a check whether the pointer is null better
> than checking just the string emptiness?

In light of what was said above, this is equivalent at this point in the
code. But there seem to be other places in GuiDocument that we rely upon
the pointer not to be null, and we need also to do something about
those. Also at BufferParams::useBiblatex().

I wonder if what we really need to do here is add the 'unknown' cite
engine the way we do unknown layouts. Otherwise, if, say, the font is
modified in Document>Settings, then I am guessing we won't save the
document with the same engine it had before: It isn't known there. That
would mean we needed some other way to tell if the engine was 'real',
rather than testing the pointer, but we do all of this with 'unknown'
layouts.

Richard

2.2.4

[Richard Heck]

Since we are approaching the 2.3.0 release, that means we are also
approaching the last release of the 2.2.x series. I'd like to freeze
strings and notify our translators on Sunday or Monday, so if there is
anything left you'd like to do there, let me know ASAP.

Richard

Staging Branches

[Richard Heck]

I've just created two staging branches: 2.3.1-staging and 2.3.2-staging.
Rules for committing to these are the same as for stable branch, i.e.,
clear it with me first.

As usual, the reason to create these is that we have some fixes piling
up already, and I don't want to forget them.

Richard

Re: Plan for final steps of 2.3.0 release

[Richard Heck]

On 02/14/2018 09:34 AM, Jean-Marc Lasgouttes wrote:
> Le 13/02/2018 à 07:53, Jürgen Spitzmüller a écrit :
>> Am Dienstag, den 13.02.2018, 01:54 +0100 schrieb Uwe Stöhr:
>>> In my opinion a major version should contain all major bugfixes. Here
>>> we
>>> have a menu entry for a feature that doesn't work. This is no good
>>> advertisement for LyX.
>>> We have a working fix that is well tested on Windows. If we know that
>>> it
>>> works also well on MacOS I think it is safe. Jürgen, please correct
>>> me
>>> if I am wrong.
>>
>> I would be more easy if we could test the fix a bit, so I'd prefer
>> 2.3.1. (push it immediately after 2.3.0 is out).

I have just created a 2.3.1-staging branch. Please commit there.

Richard

Re: [LyX/master] Implement buffer-anonymize more efficiently

[Richard Heck]

On 02/12/2018 08:39 AM, Jean-Marc Lasgouttes wrote:
> Le 12/02/2018 à 14:38, Jean-Marc Lasgouttes a écrit :
>> commit 1dba36c7cec6aeec2576e7a99e2967e867076a01
>> Author: Jean-Marc Lasgouttes 
>> Date:   Wed Feb 7 15:35:46 2018 +0100
>>
>>  Implement buffer-anonymize more efficiently
>>   The work is done now in Paragraph::anonymize().
>>   Move the handling of the lfun to Buffer class.
>
> Richard, this is candidate for 2.3.2 (no hurry).

I have just created a 2.3.2-staging branch. (As usual, I'm worried about
forgetting things.) Please commit there.

Richard

Re: [LyX/master] Fix crash when citeengine is unknown.

[Richard Heck]

On 02/14/2018 03:04 AM, Jürgen Spitzmüller wrote:
> Am Montag, den 12.02.2018, 16:31 -0500 schrieb Richard Heck:
>>>  src/frontends/qt4/GuiDocument.cpp |6 ++
>>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/frontends/qt4/GuiDocument.cpp
>>> b/src/frontends/qt4/GuiDocument.cpp
>>> index 85318bc..8149b50 100644
>>> --- a/src/frontends/qt4/GuiDocument.cpp
>>> +++ b/src/frontends/qt4/GuiDocument.cpp
>>> @@ -4007,6 +4007,12 @@ bool GuiDocument::isBiblatex() const
>>> biblioModule->citeEngineCO->itemData(
>>> biblioModule->citeEngineCO-
>>>> currentIndex()).toString();
>>>  
>>> +   // this can happen if the cite engine is unknown, which
>>> can happen
>>> +   // if one is using a file that came from someone else,
>>> etc. in that
>>> +   // case, we crash if we proceed.
>>> +   if (engine.isEmpty())
>>> +   return false;
>>> +
>>> return theCiteEnginesList[fromqstr(engine)]-
>>>> getCiteFramework() == "biblatex";
>>>  }
>>>  
> I wonder how that happens. 

LyXCiteEngine const * CiteEnginesList::operator[](string const & str) const
{
    LyXCiteEnginesList::const_iterator it = englist_.begin();
    for (; it != englist_.end(); ++it)
        if (it->getID() == str) {
            LyXCiteEngine const & eng = *it;
            return ŋ
        }
    return 0;
}

The crucial point seems to be that we are in a const function, so we
return a null pointer. Boom.

> Anyway, would be the following more safe (if
> we have an unknown non-empty string)?
>
>return theCiteEnginesList[fromqstr(engine)]
>   && theCiteEnginesList[fromqstr(engine)]->getCiteFramework()
>  == "biblatex";
>
> This should also cover the empty case.

Maybe what would be best is to create and use
CiteEnginesList::hasEngine(const & string). Then add an assertion to the
function quoted above. This is how things are done in other places.

Richard

Re: [LyX/master] Also fix chapter layout in tufte-book.

[Richard Heck]

On 02/13/2018 03:36 AM, Pavel Sanda wrote:
> Richard Heck wrote:
>> commit 5f1b32f8c5770c316f3fcb107b0ad88f910e3617
>> Author: Richard Heck 
>> Date:   Mon Feb 12 16:29:54 2018 -0500
>>
>> Also fix chapter layout in tufte-book.
> Did you actually tried that? I knew about this one, but for some reason the 
> spacing was not that bad in this case.

I think the chapter font is a bit smaller, but it looked fine to me. We
can switch it to 3 if you think it's better.

Richard

Re: Plan for final steps of 2.3.0 release

[Richard Heck]

On 02/12/2018 07:54 PM, Uwe Stöhr wrote:
> Am 13.02.2018 um 00:19 schrieb Scott Kostyshak:
>>> https://www.lyx.org/trac/ticket/9139
>>
>> I don't see the advantage of doing this at a major version. Even if
>> there is an advantage, I don't think that so soon before the final
>> release is the right time for this non-trivial patch. From what I
>> understand, this temporary file name stuff is tricky. I know you've
>> tested the patch and it works for you, but I'm worried there could be
>> hidden problems.
>
> In my opinion a major version should contain all major bugfixes. Here
> we have a menu entry for a feature that doesn't work. This is no good
> advertisement for LyX.

It hasn't worked for quite a while, apparently.

> We have a working fix that is well tested on Windows. If we know that
> it works also well on MacOS I think it is safe. Jürgen, please correct
> me if I am wrong.

We're likely to have a fairly quick 2.3.1 release. How quick will depend
upon the feedback, but there are a number of things lined up already for
2.3.x, so it'll be a couple months at most.

Richard

Re: [LyX/master] Fix crash when citeengine is unknown.

[Richard Heck]

On 02/12/2018 04:27 PM, Richard Heck wrote:
> commit 5ee3396459602e0982234cab064c5c960af7e4fc
> Author: Richard Heck 
> Date:   Mon Feb 12 16:26:27 2018 -0500
>
> Fix crash when citeengine is unknown.

Scott, this is also needed in 2.3.x. Trivial and completely safe crash-fix.

Richard


> ---
>  src/frontends/qt4/GuiDocument.cpp |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/src/frontends/qt4/GuiDocument.cpp 
> b/src/frontends/qt4/GuiDocument.cpp
> index 85318bc..8149b50 100644
> --- a/src/frontends/qt4/GuiDocument.cpp
> +++ b/src/frontends/qt4/GuiDocument.cpp
> @@ -4007,6 +4007,12 @@ bool GuiDocument::isBiblatex() const
>   biblioModule->citeEngineCO->itemData(
>   
> biblioModule->citeEngineCO->currentIndex()).toString();
>  
> + // this can happen if the cite engine is unknown, which can happen
> + // if one is using a file that came from someone else, etc. in that
> + // case, we crash if we proceed.
> + if (engine.isEmpty())
> + return false;
> +
>   return theCiteEnginesList[fromqstr(engine)]->getCiteFramework() == 
> "biblatex";
>  }
>  

Re: [patch] Chapter top spacing - regression

[Richard Heck]

On 02/12/2018 03:17 PM, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
>> Le 10/02/2018 ?? 04:04, Richard Heck a écrit :
>>> Yes, so that is the one JMarc guessed, though the real culprit is
>>> e7827264e7e.
>>> I would guess that the simple layout solution originally proposed is
>>> correct, then. This commit just removed special handling for chapters,
>>> so what's happening now is kind of what should have happened all along.
>> +1
> Fixed at 149f03d403.
>
> Scott, 2.3.0 or 2.3.1? 

FWIW, I'd suggest 2.3.0. It's totally cosmetic and safe, but annoying
for people with small screens.

Richard

Re: [LyX/2.3.x] Remove sections 6.7 and 6.4 from Additional manual (obsolete classes egs and aguplus) Edit LaTeXConfig.lyx accordingly Move teaplates/AGUTeX.lyx to teaplates/obsolete

[Richard Heck]

On 02/12/2018 05:55 AM, Jean-Marc Lasgouttes wrote:
> Le 12/02/2018 à 11:48, Jean-Pierre Chrétien a écrit :
>> Le 12/02/2018 à 11:32, jpc a écrit :
>>> commit 92adecb6e04024422930e7f7b60af1149d15c669
>>> Author: jpc 
>>> Date:   Mon Feb 12 11:30:18 2018 +0100
>>>
>>>     Remove sections 6.7 and 6.4 from Additional manual
>>> (obsolete classes egs and aguplus)
>>>     Edit LaTeXConfig.lyx accordingly
>>>     Move teaplates/AGUTeX.lyx to teaplates/obsolete
>>
>> Richard, should this be ported to 2.2? I guess not for section 6.4,
>> as LyX-2.2.0 was released before aguplus was obsoleted. What about
>> section 2.7? egs is obsolete since 2001, AFAIU.
>>
>
> I think that 2.2.0 release date is irrelevant here, isn't it?

Well, if the layout file is still in 2.2.x, then I guess we want to keep
that section.

So, Jean-Pierre: If the layout files exist in 2.2.x, then do not remove;
otherwise, do remove.

Richard

Re: Plan for final steps of 2.3.0 release

[Richard Heck]

On 02/10/2018 01:51 PM, Scott Kostyshak wrote:
> What is your feeling on how stable our 2.3.x branch currently is? I have the 
> feeling that it is quite stable and that we should now make plans for the 
> next step in the release process. I propose to make the final 2.3.0 release 
> in about two weeks. What are your thoughts? Should we make a rc3 release? 
> Should we wait longer than two weeks?

I have been using 2.3.x for regular work for a few months now, because I
needed some of the new features. I've had no problems with it at all.

I am also in favor of going ahead with the release. As JMarc said, we
can release 2.3.1 quickly if need be.

Richard

Re: [patch] Chapter top spacing - regression

[Richard Heck]

On 02/09/2018 05:25 PM, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
>> Le 09/02/2018 ?? 19:48, Pavel Sanda a écrit :
> Could it be the removal of chapter hardcoding at e7827264 ?
 If that is not the commit that changed behavior, I could do a bisect if
 it would help.
>>> No this won't be the commit. If you can still compile 2.0-2.1 development
>>> on your computer then please bisect.
>> Why won't it be the commit?
> Because I was capable to revert the patch.  Anyway, I had fun session via ssh
> over the globe to one forgotten machine and bisect leads to d6709df3d76baf
> which is more or less your shot, without layout2layout.py changes which are
> probably needed to visualize the problem...

Yes, so that is the one JMarc guessed, though the real culprit is
e7827264e7e.

I would guess that the simple layout solution originally proposed is
correct, then. This commit just removed special handling for chapters,
so what's happening now is kind of what should have happened all along.

Richard

Re: [patch] Chapter top spacing - regression

[Richard Heck]

On 02/07/2018 05:00 PM, Pavel Sanda wrote:
> Hi,
>
> I already wrote about this some time ago, switching to 2.3 made going through
> the documents with chapters somewhat annoying on small screens because third 
> of
> my monitor is taken by vertical space. Eg. after loading tutorial on my laptop
> I can't read even the first paragraph because of the empty space.
>
> This was not the case with 2.0 as you can see in attached screenshot
> (little blurry due to high compression).
>
> Left-most lyx 2.0, middle lyx 2.3, right lyx 2.3 with the attached patch.
> I look at git history and the change was not caused by the layout file,
> so my speculation is that some painting routines changed.
> Anyway I propose to change the layout file as it seems most straightfoward.
>
> Opinions?

No objection, but I agree that there must be some underlying cause. I'll
guess that maybe the size of the Chapter font is now being used to
calculate what "4" means, whereas maybe it was the size of the base font
previously?

Richard

>
> Pavel

Re: 2.3.0rc2 tar balls have been uploaded

[Richard Heck]

On 02/02/2018 12:23 PM, Jean-Pierre Chrétien wrote:
> Le 02/02/2018 à 02:59, Richard Heck a écrit :
>> On 02/01/2018 01:59 PM, Scott Kostyshak wrote:
>>> On Tue, Jan 30, 2018 at 02:37:28AM +, Scott Kostyshak wrote:
>>>
>>>>> 
>>>>> +checking list of textclasses...
>>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/svglobal3.layout
>>>>> has no
>>>>> \DeclareXXClass line.
>>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/ectaart.layout
>>>>> has no
>>>>> \DeclareXXClass line.
>>>>> [...]
>>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/bxjsbook.layout
>>>>> has no
>>>>> \DeclareXXClass line.
>>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/letter.layout
>>>>> has no
>>>>> \DeclareXXClass line.
>>>>> 
>>>> I see these also. We should figure this out, but it's good to know it
>>>> doesn't cause any problem.
>>
>> It very much would cause a problem in certain cases, namely, if you use
>> --without-latex-config, or if there's some later problem with
>> chkconfig.ltx. Then textclass.lst is empty.
>>
>>> git bisect suggests 731c9fb4 caused the change.
>>
>> I put in some debugging code, and the regex simply isn't matching the
>> lines of the file the way it is supposed to. Ever.
>>
>> The attached patch fixes it for me. It looks like one of those weird
>> double-escaping problems. I'm not sure why the switch to binary strings
>> would cause this, but apparently it does.
>
> I patched lyx-2.3.0rc2 with it, and same behavior.
>
> In the preceding mail, I stated that I did not see anymore the 'no
> \DeclareXXClass line' messages when I launched lyx-2.3.0.rc2 again.
> In fact, to trigger again the messages, I have to remove ~/.lyx-2.3.0rc2.

You can just remove textclass.lst. Alternatively, run configure.py
manually with
    --without-latex-config
and then inspect textclass.lst. If it's empty, that's a problem. If it's
not, we're good.

> If I do this and patch (no recompilation required, right?), I still
> get the messages. 

You don't need to recompile, but you would need to re-run "make
install". Otherwise,
the old configure.py is still being used from /usr/local/share/lyx/ or
whatever.

Richard

Re: Binary regexes in configure.py

[Richard Heck]

On 02/01/2018 09:11 PM, Richard Heck wrote:
> On 02/01/2018 08:59 PM, Richard Heck wrote:
>> On 02/01/2018 01:59 PM, Scott Kostyshak wrote:
>>> On Tue, Jan 30, 2018 at 02:37:28AM +, Scott Kostyshak wrote:
>>>
>>>>> 
>>>>> +checking list of textclasses...
>>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/svglobal3.layout has no
>>>>> \DeclareXXClass line.
>>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/ectaart.layout has no
>>>>> \DeclareXXClass line.
>>>>> [...]
>>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/bxjsbook.layout has no
>>>>> \DeclareXXClass line.
>>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/letter.layout has no
>>>>> \DeclareXXClass line.
>>>>> 
>>>> I see these also. We should figure this out, but it's good to know it
>>>> doesn't cause any problem.
>> It very much would cause a problem in certain cases, namely, if you use
>> --without-latex-config, or if there's some later problem with
>> chkconfig.ltx. Then textclass.lst is empty.
>>
>>> git bisect suggests 731c9fb4 caused the change.
>> I put in some debugging code, and the regex simply isn't matching the
>> lines of the file the way it is supposed to. Ever.
>>
>> The attached patch fixes it for me. It looks like one of those weird
>> double-escaping problems. I'm not sure why the switch to binary strings
>> would cause this, but apparently it does.
> I think the reason is because we are no longer using the r'...' construct.
>
> There seems also to be a similar issue, though not one that is actually
> causing a problem, with some other regexes later. The updated patch also
> fixes those.
>
> I noticed that Enrico has things like "\\s" as well (search "declare =")
> rather than just "\s". The latter seems to work, but I'm curious what
> exactly is going on here.

I finally figured out what's happening here, so I've pushed this fix to
master. I'll wait for your OK for 2.3.x.

Richard

Binary regexes in configure.py

[Richard Heck]

On 02/01/2018 08:59 PM, Richard Heck wrote:
> On 02/01/2018 01:59 PM, Scott Kostyshak wrote:
>> On Tue, Jan 30, 2018 at 02:37:28AM +, Scott Kostyshak wrote:
>>
>>>> 
>>>> +checking list of textclasses...
>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/svglobal3.layout has no
>>>> \DeclareXXClass line.
>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/ectaart.layout has no
>>>> \DeclareXXClass line.
>>>> [...]
>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/bxjsbook.layout has no
>>>> \DeclareXXClass line.
>>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/letter.layout has no
>>>> \DeclareXXClass line.
>>>> 
>>> I see these also. We should figure this out, but it's good to know it
>>> doesn't cause any problem.
> It very much would cause a problem in certain cases, namely, if you use
> --without-latex-config, or if there's some later problem with
> chkconfig.ltx. Then textclass.lst is empty.
>
>> git bisect suggests 731c9fb4 caused the change.
> I put in some debugging code, and the regex simply isn't matching the
> lines of the file the way it is supposed to. Ever.
>
> The attached patch fixes it for me. It looks like one of those weird
> double-escaping problems. I'm not sure why the switch to binary strings
> would cause this, but apparently it does.

I think the reason is because we are no longer using the r'...' construct.

There seems also to be a similar issue, though not one that is actually
causing a problem, with some other regexes later. The updated patch also
fixes those.

I noticed that Enrico has things like "\\s" as well (search "declare =")
rather than just "\s". The latter seems to work, but I'm curious what
exactly is going on here.

Richard

diff --git a/lib/configure.py b/lib/configure.py
index 95203fcb6e..5d91650a2f 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -1276,6 +1276,7 @@ def processLayoutFile(file, bool_docbook):
 "scrbook" "scrbook" "book (koma-script)" "false" "scrbook.cls" "Books"
 "svjog" "svjour" "article (Springer - svjour/jog)" "false" 
"svjour.cls,svjog.clo" ""
 '''
+
 def checkForClassExtension(x):
 '''if the extension for a latex class is not
provided, add .cls to the classname'''
@@ -1285,8 +1286,8 @@ def processLayoutFile(file, bool_docbook):
 return x.strip()
 classname = file.split(os.sep)[-1].split('.')[0]
 # return ('LaTeX', '[a,b]', 'a', ',b,c', 'article') for 
\DeclareLaTeXClass[a,b,c]{article}
-p = 
re.compile(b'^\s*#\s*\\Declare(LaTeX|DocBook)Class\s*(\[([^,]*)(,.*)*\])*\s*{(.*)}\s*$')
-q = re.compile(b'^\s*#\s*\\DeclareCategory{(.*)}\s*$')
+p = 
re.compile(b'^\s*#\s*Declare(LaTeX|DocBook)Class\s*(\[([^,]*)(,.*)*\])*\s*{(.*)}\s*$')
+q = re.compile(b'^\s*#\s*DeclareCategory{(.*)}\s*$')
 classdeclaration = b""
 categorydeclaration = b'""'
 for line in open(file, 'rb').readlines():
@@ -1311,9 +1312,9 @@ def processLayoutFile(file, bool_docbook):
 if qres != None:
  categorydeclaration = b'"%s"' % (qres.groups()[0])
  if classdeclaration != b"":
- return classdeclaration + b" " + categorydeclaration
+ return classdeclaration + b" " + categorydeclaration + b"\n"
 if classdeclaration != b"":
-return classdeclaration + b" " + categorydeclaration
+return classdeclaration + b" " + categorydeclaration + b"\n"
 logger.warning("Layout file " + file + " has no \DeclareXXClass line. ")
 return b""
 
@@ -1511,7 +1512,7 @@ def processModuleFile(file, filename, bool_docbook):
 We expect output:
   "ModuleName" "filename" "Description" "Packages" "Requires" 
"Excludes" "Category"
 '''
-remods = re.compile(b'\DeclareLyXModule\s*(?:\[([^]]*?)\])?{(.*)}')
+remods = re.compile(b'DeclareLyXModule\s*(?:\[([^]]*?)\])?{(.*)}')
 rereqs = re.compile(b'#+\s*Requires: (.*)')
 reexcs = re.compile(b'#+\s*Excludes: (.*)')
 recaty = re.compile(b'#+\s*Category: (.*)')
@@ -1635,7 +1636,7 @@ def processCiteEngineFile(file, filename, bool_docbook):
 We expect output:
   "CiteEngineName" "filename" "CiteEngineType" "CiteFramework" 
"DefaultBiblio" "Description" "Packages"
 '''
-remods = re.compile(b'\DeclareLyXCiteEngine\s*(?:\[([^]]*?)\])?{(.*)}')
+remods = re.compile(b'DeclareLyXCiteEngine\s*(?:\[([^]]*?)\])?{(.*)}')
 redbeg = re.compile(b'#+\s*DescriptionBegin\s*$')
 redend = re.compile(b'#+\s*DescriptionEnd\s*$')
 recet = re.compile(b'\s*CiteEngineType\s*(.*)')

Re: 2.3.0rc2 tar balls have been uploaded

[Richard Heck]

On 02/01/2018 01:59 PM, Scott Kostyshak wrote:
> On Tue, Jan 30, 2018 at 02:37:28AM +, Scott Kostyshak wrote:
>
>>> 
>>> +checking list of textclasses...
>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/svglobal3.layout has no
>>> \DeclareXXClass line.
>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/ectaart.layout has no
>>> \DeclareXXClass line.
>>> [...]
>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/bxjsbook.layout has no
>>> \DeclareXXClass line.
>>> Layout file /usr/local/share/lyx-2.3.0rc2/layouts/letter.layout has no
>>> \DeclareXXClass line.
>>> 
>> I see these also. We should figure this out, but it's good to know it
>> doesn't cause any problem.

It very much would cause a problem in certain cases, namely, if you use
--without-latex-config, or if there's some later problem with
chkconfig.ltx. Then textclass.lst is empty.

> git bisect suggests 731c9fb4 caused the change.

I put in some debugging code, and the regex simply isn't matching the
lines of the file the way it is supposed to. Ever.

The attached patch fixes it for me. It looks like one of those weird
double-escaping problems. I'm not sure why the switch to binary strings
would cause this, but apparently it does.

Richard

diff --git a/lib/configure.py b/lib/configure.py
index 95203fcb6e..7a67a3ee5f 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -1276,6 +1276,7 @@ def processLayoutFile(file, bool_docbook):
 "scrbook" "scrbook" "book (koma-script)" "false" "scrbook.cls" "Books"
 "svjog" "svjour" "article (Springer - svjour/jog)" "false" 
"svjour.cls,svjog.clo" ""
 '''
+
 def checkForClassExtension(x):
 '''if the extension for a latex class is not
provided, add .cls to the classname'''
@@ -1285,8 +1286,8 @@ def processLayoutFile(file, bool_docbook):
 return x.strip()
 classname = file.split(os.sep)[-1].split('.')[0]
 # return ('LaTeX', '[a,b]', 'a', ',b,c', 'article') for 
\DeclareLaTeXClass[a,b,c]{article}
-p = 
re.compile(b'^\s*#\s*\\Declare(LaTeX|DocBook)Class\s*(\[([^,]*)(,.*)*\])*\s*{(.*)}\s*$')
-q = re.compile(b'^\s*#\s*\\DeclareCategory{(.*)}\s*$')
+p = 
re.compile(b'^\s*#\s*Declare(LaTeX|DocBook)Class\s*(\[([^,]*)(,.*)*\])*\s*{(.*)}\s*$')
+q = re.compile(b'^\s*#\s*DeclareCategory{(.*)}\s*$')
 classdeclaration = b""
 categorydeclaration = b'""'
 for line in open(file, 'rb').readlines():
@@ -1311,9 +1312,9 @@ def processLayoutFile(file, bool_docbook):
 if qres != None:
  categorydeclaration = b'"%s"' % (qres.groups()[0])
  if classdeclaration != b"":
- return classdeclaration + b" " + categorydeclaration
+ return classdeclaration + b" " + categorydeclaration + b"\n"
 if classdeclaration != b"":
-return classdeclaration + b" " + categorydeclaration
+return classdeclaration + b" " + categorydeclaration + b"\n"
 logger.warning("Layout file " + file + " has no \DeclareXXClass line. ")
 return b""
 

Re: LyX version 2.3.0rc2 available

[Richard Heck]

On 02/01/2018 12:19 AM, Scott Kostyshak wrote:
> On Thu, Feb 01, 2018 at 05:06:52AM +, Joel Kulesza wrote:
>> On Tue, Jan 30, 2018 at 11:36 PM, Scott Kostyshak  wrote:
>>
>>> You can download LyX 2.3.0rc2 from ftp://ftp.lyx.org/pub/lyx/devel/.
>>>
>>>
>> Colleagues,
>>
>> Given my recent faulty assumption on how the download site and associated
>> mirrors work, what are your thoughts on the wording change:
>>
>> You can download LyX 2.3.0rc2 from ftp://ftp.lyx.org/pub/lyx/devel/ (based
>> in Paris) or a closer mirror listed at: http://www.lyx.org/Download#toc11.
> I'm fine with the change if others support it.

Fine with me.

Richard

Re: Citation Label Undo/Redo Bug

[Richard Heck]

On 01/28/2018 03:31 AM, Jürgen Spitzmüller wrote:
> Am Samstag, den 27.01.2018, 17:28 -0500 schrieb Richard Heck:
>> I guess what we need to do here is mark the citation labels as
>> invalid,
>> so they will all be recalculated. So we need a
>> Buffer::invalidateCiteLabels() routine, which is obviously easy, and
>> we
>> need to decide when to call it. I'm thinking we do NOT want to do
>> this
>> every time we do an undo or redo. Recalculating the cite labels won't
>> take that long, but if there were a lot of them So maybe what we
>> should do is check what the cite engine and type are before we do the
>> undo or redo, and if they are different afterwards, then we
>> invalidate
>> the cite labels.
>>
>> Jürgen, JMarc, what do you think?
> Makes sense.

This is now bug #11055, fixed in master.

Scott, it is up to you about 2.3.0. It's really a very old bug, so I
don't think it's crucial.

Richard

Citation Label Undo/Redo Bug

[Richard Heck]

On 12/20/2017 12:34 PM, Richard Heck wrote:
> On 12/20/2017 01:43 AM, Scott Kostyshak wrote:
>> Note that a7677bfb (the reversion commit) introduced another issue:
>> To reproduce:
>>
>> 1. Open e.g. tufte-handout.lyx (any LyX file with a citation inset will
>> reproduce)
>> 2. Scroll down to a citation inset and remember how it looks. e.g.
>> "[#Bringhurst2005]".
>> 3. Go to Document > Settings > Bibliography and change BibTeX to
>> Biblatex. Press "OK".
>> 4. Undo.
>>
>> The citation inset is not restored to the same as before,
>> "[#Bringhurst2005]". Instead, it looks the same as before undo:
>> "Bringhurst 2005".
>

Oddly, it works for me the first time I undo, but it won't work the next
time. Also, if I hit "Redo", then the labels do not update.

I guess what we need to do here is mark the citation labels as invalid,
so they will all be recalculated. So we need a
Buffer::invalidateCiteLabels() routine, which is obviously easy, and we
need to decide when to call it. I'm thinking we do NOT want to do this
every time we do an undo or redo. Recalculating the cite labels won't
take that long, but if there were a lot of them So maybe what we
should do is check what the cite engine and type are before we do the
undo or redo, and if they are different afterwards, then we invalidate
the cite labels.

Jürgen, JMarc, what do you think?

Richard

Re: [LyX/2.2.x] Fix bug #8782.

[Richard Heck]

On 01/25/2018 02:18 AM, Scott Kostyshak wrote:
> On Wed, Dec 20, 2017 at 05:34:44PM +0000, Richard Heck wrote:
>
>> Presumably need to do something similar here. I'll have a look.
> Ping. I don't think this is urgent but since I think it's a regression
> it would be nice to make sure it's nothing too bad.

Will try to look tomorrow.

Richard

Re: Extending layouts

[Richard Heck]

On 01/23/2018 03:49 AM, Jean-Marc Lasgouttes wrote:
>
> Now that I think about it, the advantage of using a special syntax is
> that there is not need to specify the file name, which makes the code
> safer.
>
> Idead of syntax:
>   Input 
>   Input *
>   InputParent

I had a similar thought: something like class inheritance. The last of
these looks best to me.

Richard

Re: Extending layouts

[Richard Heck]

On 01/22/2018 04:23 AM, Jean-Marc Lasgouttes wrote:
> 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?

My sense, from our previous discussion, is that this would work in the
cases racoon had in mind. But I'm not sure why this wouldn't scale. We
could of course look also for *.ext.ext.

These ideas could also probably be combined.

Richard

Re: AddToToc does not work as expected

[Richard Heck]

On 01/18/2018 05:12 PM, racoon wrote:
> Hi,
>
> I boldly tried to add all enumerated items to the outliner by adding
> the following to the Local Layout:
>
>
> OutlinerName enum "Enumerates"
>
> Style Enumerate
>     CopyStyle Enumerate
>     AddToToc enum
>     IsTocCaption true
> End
>
>
> Unfortunately, it seems not to work. And I am wondering whether this
> is as intended or not.
>
> First, when adding different items to a list, like
>
> 1. One
> 2. Two
> 3. Three
>
> They do not get separated in the toc. The output will be one item that
> reads
>
> 1. One 2. Two 3. Three

I don't think anyone had using enums in mind when writing this code.
There will need to be some special handling for this case. Please file a
bug.

> Second, the toc item gets updated only after a new item or paragraph
> is started after it. So if one only writes
>
> Test
> 1. One
>
> and then does not add another paragraph after it but sets the cursor
> only back to the first "Test" line, then no item is generated.

There are some TOC bugs involving missing updates. This looks like another.

Richard

Re: LyX & feature wishes

[Richard Heck]

> LyX does much of what I need, but there are a few things I miss. Some
> of these are related to what FrameMaker refer to as “object tags”, I
> guess. In LyX: Graphics (click on a LyX graphics), under LaTeX and LyX
> options: the possibility to define Graphics Groups is extremely
> useful… when I import plots generated in MATLAB, I can assign the same
> graphics group to these plots, and get a consistent size of these. If
> I change the definition of the group, this immediately propagates to
> all plots within the group.
>
> A key suggestion is to **extend** this to other objects. Thus:
> 1. I have spent tens of hours trying to get a consistent look for
> Program Listing. It would be really, really helpful if I can assign a
> Program Listing to a “program listing group”, where I define computer
> language, possible numbering of lines, location of line numbering,
> fonts for line numbering, fonts for code, line breaks, tabs, etc.,etc.
> Thus, I’d like to be able to define groups such as “Displayed-MATLAB”,
> “InLine-MATLAB”, “Displayed-Python”, etc., etc. Such a possibility
> would be priceless for getting a consistent look.
>
> 2. Similarly: styles for Floats would be useful. By default, all
> floats seem to be left adjusted. I tend to use center adjustment of
> figures/tables and caption. If I could set a default, or define a
> group – that would be useful.
>

These seem like sensible ideas. Feel free to file enhancement requests
on the bug tracker. Probably much of the code can all but be reused.
I.e., if you know any programming at all, you might well be able to do
this yourself. Pavel Sanda wrote the graphics group code and is still
active here, so he could give pointers, too.

> 3. I tend to experiment a bit with my notation. What symbol should I
> use for dimensionless variables? I have tried with math expressions
> with bar decoration, with subscript asterisk, etc., etc. I should
> probably have defined macros for this (but haven’t looked too much
> into that possibility).
>

Yes, you should use macros for this. It is one of the things they are for.

> Instead I have used the Math Find/Replace option.

Advanced F&R is known to be...not as good as it could be. It could use
some TLC, probably a serious rewrite, but it's not getting it at the
moment.

If you need to do serious replacement in this kind of way, then you are
probably better off opening the LyX file in a good text editor and doing
it there. (Back it up first!!) Or use a perl or python script. That's
what a lot of people do. You can really do quite powerful things that
way. It's one of the big advantages of LyX's native format being a text
file. Of course, you have to learn a bit about the file format to do
this, but you can always ask questions here.

> It would be nice if there was an option so that ordinary text (i.e.,
> not enclosed in $.$ or $$.$$) is left out of the replacement.

This seems independently a good idea.

> When I preview documents, LyX often gives me error messages – which
> very often are difficult to decipher.
>
> It would be useful with some improvement (if possible) in what exactly
> is wrong when I get error messages,

LyX is just relaying the error messages from LaTeX (assuming that is the
backend you are using). These are known sometimes to be confusing. (Is
there any compiler for which that is not true?)

> and in which part of the document I should look for problems. 

LyX tries hard to do this. LaTeX reports the line on which the error is
found, and LyX has a table that correlates those with positions in the
LyX file. Failures to report the right location may be LyX bugs and can
be reported as such. But LaTeX sometimes reports the error in weird
places. An unclosed group, for example, wouldn't be noticed until some
later point.

> With the current level of information (ok – it may be that I simply
> don’t understand how to debug), I essentially end up with a binary
> search of the document… remove the last half of the document and see
> if the error message persists, if persists, then re-insert the latter
> part and remove the first quarter, etc., etc. Not particularly
> efficient, and prone to “accidents”.

So, even with raw LaTeX, this is often the best available strategy. Or
asking at lyx-users first.

Richard

Re: Beamer & Outliner broken

[Richard Heck]

On 01/14/2018 04:12 AM, Pavel Sanda wrote:
> Andrew Parsloe wrote:
>> On 14/01/2018 7:59 a.m., Pavel Sanda wrote:
>>> Here we go:
>>> put beamer_test.lyx & beamer_test.tex.orig to our git tree.
>>> then outline & beamer test should be smt like:
>>>
>>> rm beamer_test.tex
>>> lyx -x 'command-sequence file-open beamer_test.lyx ; buffer-begin ; repeat 
>>> 150 outline-down; repeat 150 outline-up ; buffer-export pdflatex ; repeat 
>>> 150 outline-down; buffer-reload dump ; lyx-quit '
>>> diff -u beamer_test.tex beamer_test.tex.orig
>>> ... if diff is noneempty fail the test ...
>>>
>>>
>>> Doable?
>>> Pavel
>> I notice buffer-export in a command-sequence. Is this going to be 
>> compatible with threaded export (#8346)? (When I've tried doing this in the 
>> past, the commands following the buffer-export are initiated before the 
>> export is complete, resulting in a mess.)
> Do you have reproducible recipy? We clone the buffer before we start
> export, and we do this cloning synchronously. Only after cloning
> asynchronous call is done on the cloned document, thus I have problem
> to see why you should experience any problem...

I've certainly heard of this: As Andrew said, buffer-export basically
returns immediately, even if the export process itself takes an hour.
That's because the export happens in a separate thread.

There was another bug recently that made me think we shouldn't use
clones when exporting from the command line, but I can't remember which
one. I can't think it would be that hard to check use_gui or whatever
before cloning.

Richard

Re: [LyX/master] Fix Null-checking issue detected by Coverity.

[Richard Heck]

On 01/11/2018 08:23 AM, Jürgen Spitzmüller wrote:
> 2018-01-11 13:44 GMT+01:00 Juergen Spitzmueller  >:
>
> commit 974553d8583954aa7741c4dc0ce83f9ca812b03b
> Author: Juergen Spitzmueller mailto:sp...@lyx.org>>
> Date:   Thu Jan 11 13:43:35 2018 +0100
>
>     Fix Null-checking issue detected by Coverity.
> ---
>  src/Paragraph.cpp |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
> index fc5b941..3c26bf1 100644
> --- a/src/Paragraph.cpp
> +++ b/src/Paragraph.cpp
> @@ -1429,14 +1429,12 @@ bool
> Paragraph::Private::latexSpecialT3(char_type const c, otexstream & os,
>
>  void Paragraph::Private::validate(LaTeXFeatures & features) const
>  {
> -       Buffer const & buf = inset_owner_->buffer();
> -       BufferParams const & bp = features.runparams().is_child
> -               ? buf.masterParams() : buf.params();
>         if (layout_->inpreamble && inset_owner_) {
>                 // FIXME: Using a string stream here circumvents
> the encoding
>                 // switching machinery of odocstream. Therefore the
>                 // output is wrong if this paragraph contains content
>                 // that needs to switch encoding.
> +               Buffer const & buf = inset_owner_->buffer();
>                 otexstringstream os;
>                 os << layout_->preamble();
>                 size_t const length = os.length();
> @@ -1490,6 +1488,8 @@ void
> Paragraph::Private::validate(LaTeXFeatures & features) const
>         }
>
>         // then the contents
> +       BufferParams const bp = features.runparams().is_child
> +               ? features.buffer().masterParams() :
> features.buffer().params();
>         for (pos_type i = 0; i < int(text_.size()) ; ++i) {
>                 char_type c = text_[i];
>                 if (c == 0x0022) {
>
>
>
> I suppose this should also go to 2.3.x.

+1

rh

Re: Outline pane can't be used after initial launch

[Richard Heck]

On 01/05/2018 08:31 AM, Pavel Sanda wrote:
> Richard Heck wrote:
>> Works fine here (master with qt5).
> Joel Kulesza wrote:
>> I cannot reproduce.
> Scott Kostyshak wrote:
>> Neither can I.
> Kornel Benko wrote:
>> For me, even the "4. after undocking outliner no more responds to mouse 
>> input"
>> does not apply.
>
> Anyone of you running with Qt 5.7.1? P

5.9.2 here.

Richard

Re: Outline pane can't be used after initial launch

[Richard Heck]

On 01/04/2018 01:00 PM, Pavel Sanda wrote:
> I see this with qt5, both master & 2.3:
>
> 1. launch lyx (which does not have outline shown from previous session)
> 2. new file & open outliner
> 3. undock outliner while moving it out of lyx main window
> 4. after undocking outliner no more responds to mouse input
> 5. close lyx
> 6. start lyx
> 7. remembered outliner responds normally to mouse commands

Works fine here (master with qt5).

Richard

Re: Beamer usage again

[Richard Heck]

On 12/30/2017 06:56 PM, Joel Kulesza wrote:
> On Sun, Dec 31, 2017 at 1:55 AM, Jürgen Spitzmüller  > wrote:
>
> Am Samstag, den 30.12.2017, 10:48 +0100 schrieb Pavel Sanda:
> > I think we can safely go for it.
> > Given that we already have two overlay item in the menu, we might
> > want to group
> > them at the end of insert menu?
>
> Done.
>
>
> Jürgen,
>
> I pulled 9f9c2e02 and applied the 9261 patch.  From there, attempting
> to use Insert > Frame gives me a crash. 

Can someone put the 9261 patch on trac so it's more accessible?

rh

Re: Beamer usage again

[Richard Heck]

On 12/30/2017 05:52 AM, José Abílio Matos wrote:
>
> On Saturday, 30 December 2017 10.40.19 WET Jürgen Spitzmüller wrote:
>
> > Right. I am talking about the layout format here, though.
>
> >
>
> > Jürgen
>
>  
>
> Oops. :-)
>
> You are right.
>
>  
>
> IIRC we have been a little bit more permissive in this case. :-)
>

But I think the same rule should apply, if only because the layout
format becomes
part of the file format via local layout. But there's also an issue
about sharing layout
files across minor versions.

That said, this strikes me too as enough of an improvement to warrant a
late change.
I've found these same aspects of the Beamer implementation unintuitive.

Richard

Re: Beamer usage again

[Richard Heck]

On 12/30/2017 06:00 AM, Jürgen Spitzmüller wrote:
> Am Samstag, den 30.12.2017, 11:30 +0900 schrieb Joel Kulesza:
>> I've tried to demonstrate with screen recording what I tried to
>> illustrate with my screenshot previously.  There are places I can
>> position the cursor where the Edit menus vary and produce varying
>> behavior.  I would expect that anywhere between "Frame" and the
>> horizontal separator to have the ability to pre/append a Frame and to
>> have it be created properly. Please use the MWE attached to further
>> explore the variation in the edit menu entries based on cursor
>> position and eventual action outcome: whether a self-contained frame
>> is inserted, or not.
> I have fixed the second problem (appending from the separator) in
> master. Please test.
>
> I am not sure how to fix the first issue. Actually, the procedure
> works. The problem ist, though, that an empty new frame is inserted,
> which is rightly deleted again by the delete empty paragraphs
> mechanism. This is really hard to fix in a general way.

KeepEmpty 1?

rh

Re: Suggestion: fixed preamble element for logical markup

[Richard Heck]

On 12/14/2017 01:30 AM, Scott Kostyshak wrote:
> On Wed, Dec 13, 2017 at 03:39:38PM +, Paul Johnson wrote:
>> Dear LyX-developers.
>>
>> Happy Holidays to you from Kansas!
>>
>> Would you consider making the preamble created by LyX more
>> "predictable" from the settings, and less dependent on the actual
>> content in the document?  Recently I wished, while using Logical
>> Markup module, that it would insert preamble code,  *even if I did not
>> use them yet in this particular document*. So far, the only example of
>> this need I've found is this one:
> I'm not sure, but I think I've come across a similar case.
>
> I use the FiXme module, and I include the following in my preamble:
>
> % Makes it so FiXme notes always show up (e.g. without draft mode).
> % If not wrapped in "if" and if there do not happen to be any FiXme
> % insets, the following gives an undefined control sequence error
> % because LyX will not load the package.
> \@ifpackageloaded{fixme}{\fxsetup{draft,
> targetlayout=changebar,targetface=\bfseries\itshape}}
>
> As you can guess by the above comment, I ran into a similar problem as
> you did and had to add the "if" condition. Before, I did not protect it
> with \@ifpackageloaded, so when I removed the FiXme insets, I received
> an error.

In response to the original question: One of the nice things about
modules is that they can so easily be modified by the user. In this
case, you can copy logicalmkup.module to the layouts/ subdirectory of
your user directory, then take whatever 'conditional' preamble code you
want and put it into an "AddToPreamble / EndPreamble" block. Then that
stuff gets written unconditionally. (LyX will load your 'local' copy if
it finds one instead of the system copy.)

For the most part, though, we try not to pollute the preamble with
unneeded code. Many of us have to export LaTeX to send to journals, etc,
and in theorems-ams.inc, for example, every theorem environment has
associated preamble code. Writing all that to every file would be a bad
idea.

Richard Heck

Re: Beamer usage again

[Richard Heck]

On 12/28/2017 05:07 PM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> Jürgen Spitzmüller wrote:
>>> Am Donnerstag, den 28.12.2017, 10:24 +0100 schrieb Jürgen Spitzmüller:
>b) maybe there is some visual way to signalize that nesting is needed?
 I thought about something like auto-nesting. But this is certainly
 tricky to implement.
>>> Done in master. Please test.
>> I am lost. What should I see/check? Pavel
> Now I see what you mean. Is the fact that enter in frame environment leads to 
> new line with (again) frame environment instead of (say) standard environment 
> intentional?

Yes, it works just like Theorem. Note that the Frame environment does
NOT need to be nested, whereas Standard does have to be. This takes a
little getting used to, but in the end I think it works.

Richard

Re: Should child docs inherit trust for needauth converter?

[Richard Heck]

On 12/28/2017 03:40 AM, Scott Kostyshak wrote:
> On Mon, May 29, 2017 at 04:07:00PM +, Scott Kostyshak wrote:
>> I have a master document and several child documents that use knitr. If
>> I click on "Run", which is the prompt from the master, I am still
>> prompted for each child.
>>
>> I'm conflicted by what I think is the ideal behavior. I'm also biased
>> since I find the multiple prompts annoying (but this is only temporary
>> and easily solved).
>>
>> I suppose the way to think through it is the following: Is there an
>> example where you would want to trust the parent but not trust the
>> child?
>>
>> Perhaps you get the prompt for the parent, and say "I looked through
>> this document and looked at the knitr chunks and know that none of the
>> code is malicious" so I trust the document, and then a prompt for the
>> child doc comes and you say "I did not know that the child doc used
>> knitr, I want to check it also for malicious code". That's the best
>> example I can come up with, but I'm not very convinced by it.
>>
>> I suppose in cases of security, unless I can make a sound-proof argument
>> to get rid of the additional prompts, we should just keep them.
>>
>> Any thoughts?
> Any thoughts?

No, but only because I do not really use such things.

rh

Re: [LyX/master] Allow makeindex, nomencl, and bibtex runs to be canceled, too.

[Richard Heck]

On 12/27/2017 09:34 AM, Jürgen Spitzmüller wrote:
> Am Freitag, den 22.12.2017, 00:58 +0100 schrieb Richard Heck:
>> commit b5e5c2576a8ed83faa52d0a35bb15dc54a8b1a91
>> Author: Richard Heck 
>> Date:   Thu Dec 21 18:46:06 2017 -0500
>>
>> Allow makeindex, nomencl, and bibtex runs to be canceled, too.
> As of this commit, BibTeX errors are no longer properly reported via
> the error dialog. In case of a BibTeX error, LyX just quits with a
> cryptic message: "No output file was generated."

Can you try the attached? Looks like I was over-enthusiastic about aborting.

rh

diff --git a/src/LaTeX.cpp b/src/LaTeX.cpp
index 79824217b8..494c68f1cf 100644
--- a/src/LaTeX.cpp
+++ b/src/LaTeX.cpp
@@ -286,7 +286,7 @@ int LaTeX::run(TeXErrors & terr)
// onlyFileName() is needed for cygwin
int const ret = 

runMakeIndex(onlyFileName(idxfile.absFileName()), runparams);
-   if (ret)
+   if (ret == Systemcall::KILLED)
return ret;
rerun = true;
}
@@ -299,7 +299,7 @@ int LaTeX::run(TeXErrors & terr)
// FIXME: Sort out the real problem in DepTable.
if (head.haschanged(nlofile) || (nlofile.exists() && 
nlofile.isFileEmpty())) {
int const ret = runMakeIndexNomencl(file, ".nlo", ".nls");
-   if (ret)
+   if (ret == Systemcall::KILLED)
return ret;
rerun = true;
}
@@ -331,7 +331,7 @@ int LaTeX::run(TeXErrors & terr)
updateBibtexDependencies(head, bibtex_info);
int exitCode;
rerun |= runBibTeX(bibtex_info, runparams, exitCode);
-   if (exitCode)
+   if (exitCode == Systemcall::KILLED)
return exitCode;
FileName const blgfile(changeExtension(file.absFileName(), 
".blg"));
if (blgfile.exists())
@@ -387,7 +387,7 @@ int LaTeX::run(TeXErrors & terr)
updateBibtexDependencies(head, bibtex_info);
int exitCode;
rerun |= runBibTeX(bibtex_info, runparams, exitCode);
-   if (exitCode)
+   if (exitCode == Systemcall::KILLED)
return exitCode;
FileName const blgfile(changeExtension(file.absFileName(), 
".blg"));
if (blgfile.exists())
@@ -410,7 +410,7 @@ int LaTeX::run(TeXErrors & terr)
// onlyFileName() is needed for cygwin
int const ret = runMakeIndex(onlyFileName(changeExtension(
file.absFileName(), ".idx")), runparams);
-   if (ret)
+   if (ret == Systemcall::KILLED)
return ret;
rerun = true;
}

Re: SVN ignorance

[Richard Heck]

On 12/26/2017 02:46 PM, Scott Kostyshak wrote:
> Thanks to JMarc for getting SVN access set up for me. However, I've
> never used SVN for development. I've gone through
>
>   https://wiki.lyx.org/Devel/Subversion
>
> and
>
>   http://www.lyx.org/HowToUseSVN
>
> but I still have questions.
>
> My first question is: is there a simple command I can run to check that
> my SVN access works correctly (e.g. that I have the right password)?

Make some trivial change (whitespace) and try commiting it.

> Second, how can I checkout the website files, make a simple change, and
> push those changes? From what I understand, "svn commit" is similar to
> git commit + git push. Is that right? When I look at "svn commit --help"
> I do not see an option for dry-run.
>
> Is it something like the following?
>
> svn co svn://svn.lyx.org/lyx/www-user/trunk www-user
> cd www-user
> # make changes (e.g. update news and rss)
> make

You'll only need to run that in misc/rss/.

> # the following will ask me for my user name and password
> svn commit

Yes, though it may also have saved those from previously.

Other useful commands: svn status, svn diff, svn revert.

Richard

Re: Broken export from command line in master

[Richard Heck]

On 12/24/2017 01:52 PM, Kornel Benko wrote:
> Am Sonntag, 24. Dezember 2017 um 11:17:43, schrieb Richard Heck 
> 
>> On 12/24/2017 12:13 AM, Scott Kostyshak wrote:
>>> On Sun, Dec 24, 2017 at 04:35:26AM +, Richard Heck wrote:
>>>
>>>> Backtrace?
>>> Attached. Are you able to reproduce?
>> Looks like my hypothesis was correct. Try the attached.
>>
>> I thought we didn't use clones when exporting from the command line. We
>> probably
>> shouldn't.
>>
>> rh
> Works here (with this patch)

Committed, then.

rh

Re: Improve copying of citation insets from LyX + BibTeX to LyX + Biblatex ?

[Richard Heck]

On 12/24/2017 06:19 AM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 24.12.2017, 00:16 -0500 schrieb Scott Kostyshak:
>> If I copy a citation of the form "author (year)" from a .lyx file
>> that
>> uses BibTeX to a .lyx file that uses Biblatex, it shows up as "author
>> year". Should we improve this or would the complication not be worth
>> it?
> Here, the style is maintained. How are your settings exactly? (Here:
> Source BibTeX (Natbib), Target Biblatex).

Didn't we fix something very like this recently? I seem to recall there
may also have been a problem along these lines that was left.

Richard

Re: Broken export from command line in master

[Richard Heck]

On 12/24/2017 12:13 AM, Scott Kostyshak wrote:
> On Sun, Dec 24, 2017 at 04:35:26AM +0000, Richard Heck wrote:
>
>> Backtrace?
> Attached. Are you able to reproduce?

Looks like my hypothesis was correct. Try the attached.

I thought we didn't use clones when exporting from the command line. We
probably
shouldn't.

rh

diff --git a/src/support/Systemcall.cpp b/src/support/Systemcall.cpp
index 93166b5c46..fe8c23fb23 100644
--- a/src/support/Systemcall.cpp
+++ b/src/support/Systemcall.cpp
@@ -403,7 +403,7 @@ void SystemcallPrivate::startProcess(QString const & cmd, 
string const & path,
 bool SystemcallPrivate::waitAndCheck()
 {
Sleep::millisec(100);
-   if (theApp()->cancel_export) {
+   if (theApp() && theApp()->cancel_export) {
// is there a better place to reset this?
process_->kill();
state = Killed;

Re: Broken export from command line in master

[Richard Heck]

On 12/23/2017 03:36 PM, Scott Kostyshak wrote:
> Try to export e.g. Additional manual on the command line:
>
>   lyx -e pdf2 Additional.lyx
>
> I get a SIGSEGV.
>
> I did a bisect and got the following:
>
>   The first bad commit could be any of:
>   12b03b30f4528f764f8b46c099ea85ba9d996da2
>   b5e5c2576a8ed83faa52d0a35bb15dc54a8b1a91
>   12f972754660b47be59668501258bf36c35b0454
>   cf782dfc68d11499f491f896646f96ea914b087d
>   165c9e92a400e8fdc00ef3e74eb68b34bfbcc6d5
>   1c7b9676b04d98581ce3a0c714aef82f5d38177c
>   35eabe1ea7c942503e3f65f3bbb6b89a965216c4
>   We cannot bisect more!

I suspect it could be somewhere like:

bool SystemcallPrivate::waitAndCheck()
{
    Sleep::millisec(100);
    if (theApp()->cancel_export) {

I think theApp() is null from the command line. I don't think we should be
here at all, but perhaps we are. Anyway, we could check that theApp() is not
null first.

Richard