Re: dash patch for stable

[Enrico Forestieri]

On Thu, Jun 01, 2017 at 09:12:53PM +, Guenter Milde wrote:

> On 2017-05-26, Scott Kostyshak wrote:
> > On Fri, May 19, 2017 at 09:12:27AM -0400, Scott Kostyshak wrote:
> >> Günter has written a lot about what to do regarding em- and en-dashes.
> >> For more information, see:
> 
> >>   http://www.lyx.org/trac/ticket/10543
> 
> >> Does anyone else have feedback on what should be done on this for 2.3.0?
> 
> There is now a patch for stable attached to the ticket.
> Thanks to Enrico for the inset code.
> 
> http://www.lyx.org/trac/raw-attachment/ticket/10543/0001-Keep-distinction-of-literal-dashes-vs-ligature-dashes-in-2-2.patch
> 
> OK to commit?

Sorry, but I am opposed to this patch. You really mean to have all
en/em-dashes become ERT!!!

-- 
Enrico

Re: [LyX/master] skip graphics conversion when runparams.dryrun is true

[Enrico Forestieri]

On Thu, Jun 01, 2017 at 01:24:35PM -0400, Scott Kostyshak wrote:

> On Fri, May 05, 2017 at 08:30:51AM +0200, Tommaso Cucinotta wrote:
> > commit 0cf394dd79337b14adb2930a617c2027e0d6f2d8
> > Author: Tommaso Cucinotta 
> > Date:   Thu May 4 07:49:07 2017 +0200
> > 
> > skip graphics conversion when runparams.dryrun is true
> 
> After this commit, if I copy a selection that has an image in it, I get
> the following message:
> 
> insets/InsetGraphics.cpp (956): InsetGraphics::xhtml: Unable to prepare file 
> `/home/scott/lyxbuilds/2017-05-17/repo/lib/images/buffer-write.svgz' for 
> output. File missing?
> 
> Attached is a patch but I have no idea if it's correct.

I think the problem is in the commit itself, which contains only
this change:

-   string const output_file = prepareHTMLFile(op);
+   string const output_file;
+   if (!op.dryrun)
+   prepareHTMLFile(op);

So, output_file is always empty, whatever op.dryrun. I think that
the following change was instead meant:

-   string const output_file = prepareHTMLFile(op);
+   string const output_file = op.dryrun ? string() : prepareHTMLFile(op);

-- 
Enrico

Re: Backwards compatibility with 2.1 and older?

[Enrico Forestieri]

On Thu, Jun 01, 2017 at 08:52:18PM +, Guenter Milde wrote:

> Dear Enrico,
> 
> thank you for the patch.
> 
> On 2017-06-01, Enrico Forestieri wrote:
> > On Thu, Jun 01, 2017 at 02:12:56PM +, Guenter Milde wrote:
> 
> > Please, try the attached. I don't know what you are trying to do,
> > but I hope you are not trying to sabotage the last fixes to the
> > en/emdash mess. 
> > I would be really upset to see all of them as ert.
> > If this is a first step toward a really clean solution (to solve I
> > don't know what), that would be fine, though.
> 
> I am trying to clean up the mess after the last fixes just moved the
> problems to another area (see http://www.lyx.org/trac/ticket/10543, comment
> 3 section "LyX 2.3dev").
> 
> ERT is the only fully backwards compatible solution for 2.2. 
> 
> It can be converted to plain -- or --- in backward conversion from 2.2 to
> 2.1.
> 
> For 2.3, we can use a new "SpecialChar" inset.
> Then, 
> 
> * a "ligature dash" can be back-converted to "\twohyphens" or
>   "\threehyphens" with lyx2lyx. It will become ERT in 2.2 and
>   (unmarked) -- or --- in 2.1 and earlier.
> 
> * an ERT with just -- or --- can be converted to the SpecialChar
>   inset with lyx2lyx forward conversion from 2.2. to 2.3.

I really don't want to go again through all this, but I am fiercely
opposed to having en/em-dashes as ERT because you end up with a
mess if you have to edit those documents, unless you want to also
enter in ERT all dashes that you may need to add.
But maybe I am simply misunderstanding.
I think that the actual solution is the lesser evil. You have
problems only if the document was later edited with 2.2.
And having to manually select a preference to adjust things
is not that intolerable, IMO. And I don't consider decisive
the fact that literal and ligatures dashes may have been
mixed together. In the past I had to adapt to more cumbersome
changes.

-- 
Enrico

Re: Bad Citation Bug in 2.3dev

[Jürgen Spitzmüller]

2017-05-31 17:47 GMT+02:00 Richard Heck :

> I see what's worrying you.
>
> The way I did the code, what we record are only *manual* changes to the
> 'literal' value. Simply opening a dialog that has literal checked does
> not change the recorded setting. If you *manually* set or unset it, then
> we will remember that, and that will become the default. So we are not
> really remembering the last value that was 'used', but only the last
> value that was 'set'. This seems right to me. Just because I happen to
> open the one citation in which I do not have 'literal' set, to modify
> something else, shouldn't mean that becomes the default.
>

I see. This strikes me sensible and sane, then.


>
> Note also that we only use the remembered value for 'new' citations
> (which we detect by seeing if the key field is empty).
>
> I still think that people are going to run into the same problem I did:
> a mix of literal and non-literal dialogs causing unexpected output. So,
> in fact, I think it would be best if, for old documents (at least), we
> did default to 'literal'. But we don't do that now. We could perhaps do
> this by checking the original file format, which is held by Buffer.cpp.
> Even then, though, once the document has been saved and re-opened, so is
> now in 2.3 format, manual action will have to be taken to avoid the
> mentioned problem.
>

Hm. I see what you mean, but don't see an elegant solution.


>
> Richard
>
> PS It's probably too late for this, but is there really a good use case
> for mixing 'literal' and 'non-literal' citations in a single document?
> I.e., might this not make more sense as a document-level setting?
>

Probably depends on the personal workflow. For me, it will probably be the
default way now to use the non-literal way and just to enable literal for
specific insets as I need it (i.e., have to enter LaTeX code). I would even
prefer a setting per widget (not per dialog), but this turned out too
complicated to implement.

But maybe a preference setting for the default of new insets would fit both
workflows?

Jürgen

dash patch for stable

[Guenter Milde]

On 2017-05-26, Scott Kostyshak wrote:
> On Fri, May 19, 2017 at 09:12:27AM -0400, Scott Kostyshak wrote:
>> Günter has written a lot about what to do regarding em- and en-dashes.
>> For more information, see:

>>   http://www.lyx.org/trac/ticket/10543

>> Does anyone else have feedback on what should be done on this for 2.3.0?

There is now a patch for stable attached to the ticket.
Thanks to Enrico for the inset code.

http://www.lyx.org/trac/raw-attachment/ticket/10543/0001-Keep-distinction-of-literal-dashes-vs-ligature-dashes-in-2-2.patch

OK to commit?


Günter

Re: Backwards compatibility with 2.1 and older?

[Guenter Milde]

Dear Enrico,

thank you for the patch.

On 2017-06-01, Enrico Forestieri wrote:
> On Thu, Jun 01, 2017 at 02:12:56PM +, Guenter Milde wrote:

> Please, try the attached. I don't know what you are trying to do,
> but I hope you are not trying to sabotage the last fixes to the
> en/emdash mess. 
> I would be really upset to see all of them as ert.
> If this is a first step toward a really clean solution (to solve I
> don't know what), that would be fine, though.

I am trying to clean up the mess after the last fixes just moved the
problems to another area (see http://www.lyx.org/trac/ticket/10543, comment
3 section "LyX 2.3dev").

ERT is the only fully backwards compatible solution for 2.2. 

It can be converted to plain -- or --- in backward conversion from 2.2 to
2.1.

For 2.3, we can use a new "SpecialChar" inset.
Then, 

* a "ligature dash" can be back-converted to "\twohyphens" or
  "\threehyphens" with lyx2lyx. It will become ERT in 2.2 and
  (unmarked) -- or --- in 2.1 and earlier.

* an ERT with just -- or --- can be converted to the SpecialChar
  inset with lyx2lyx forward conversion from 2.2. to 2.3.

Günter

Re: Re-organizing templates and examples folders (#8715)

[Scott Kostyshak]

On Wed, May 03, 2017 at 08:37:17PM +, Guenter Milde wrote:
> Dear LyX developers,
> 
> with feature freeze nearing, I'd like to take up the discussion of templates
> and examples folders:

Does anyone else have comments regarding Günter's proposal? Günter, are
you volunteering to do everything you proposed?

Normally I would ask for this issue to wait until the beginning of
2.4.0, but as Julien pointed out [1], putting this in later in the
release cycle minimizes the effort of backporting.

Scott


[1] http://www.lyx.org/trac/ticket/8715#comment:3


signature.asc
Description: PGP signature

Re: 2 error in lyx 2.3

[Scott Kostyshak]

On Thu, Jun 01, 2017 at 01:03:01PM -0400, Scott Kostyshak wrote:
> On Wed, May 31, 2017 at 11:25:18AM -0400, Richard Heck wrote:
> > On 05/31/2017 07:40 AM, edu Gpl wrote:
> > > Dear Lyx Team
> > > thank you for all.
> > > i got 2 error after i upgrade from lyx 2.2.2 to 2.3 .
> > >
> > > 1st:
> > > when i generate my book, i got this msg:
> > >
> > 
> > This is a warning that means exactly what it says. If it worked in 2.2.x,
> > that was only a happy accident. You should not use "title" layouts after
> > "non-title" layouts. The solution is to move the Dedication into the title
> > area of your document.
> 
> +1
> 
> In some cases there is no change in output, but in other cases the
> situation can cause problems (e.g. one of the environments not being
> output in the PDF) with LaTeX.

I put the following in our release notes for 2.3 (at f4b14fcf). I hope
it is clear:

  * LyX now gives a warning if a document mixes title and non-title
  layouts. In some cases, this warning is harmless, but in other cases the
  document has a serious problem even though the LaTeX command does not
  exit with error. For example, create a document with a title layout,
  then a standard layout, and then an author layout, and you will see in
  the PDF that the author is not typeset as an author.

Scott


signature.asc
Description: PGP signature

error to compile lyx-2.2.3

[Felipe Formiga]

Hi all

Really sorry if I'm posting in the error place

I'm trying to compile lx-2.2.3 in a RedHat 6.8.
After I used ./configure I got this message:
---
Configuration
  Host type:   x86_64-unknown-linux-gnu
  Special build flags:  build=release c++11 use-hunspell
  C++ Compiler:g++ (4.4.7)
  C++ Compiler flags:   -std=c++0x -O2 -Wno-deprecated-declarations
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:   4.6.2
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx

Configuration of LyX was successful.
Type 'make' to compile the program,
and then 'make install' to install it.
---

After, if I try "make" I got this error message:
---
In file included from 
../../3rdparty/boost/boost/function/detail/maybe_include.hpp:23,

 from ../../3rdparty/boost/boost/function/function2.hpp:11,
 from 
../../3rdparty/boost/boost/signals/detail/named_slot_map.hpp:17,
 from 
../../3rdparty/boost/boost/signals/detail/signal_base.hpp:15,
 from 
../../3rdparty/boost/boost/signals/signal_template.hpp:22,

 from ../../3rdparty/boost/boost/signals/signal0.hpp:24,
 from ../../3rdparty/boost/boost/signal.hpp:27,
 from ./../support/ForkedCalls.h:19,
 from ForkedCalls.cpp:15:
../../3rdparty/boost/boost/function/function_template.hpp: In static 
member function \u2018static void 
boost::detail::function::void_function_obj_invoker2::invoke(boost::detail::function::function_buffer&, T0, T1) [with 
FunctionObj = std::_Bind, 
std::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]\u2019:
../../3rdparty/boost/boost/function/function_template.hpp:936: 
instantiated from \u2018void boost::function2::assign_to(Functor) [with Functor = std::_Bind(*(std::_Placeholder<1>, std::_Placeholder<2>))(pid_t, int)>, R = void, 
T0 = int, T1 = int]\u2019
../../3rdparty/boost/boost/function/function_template.hpp:727: 
instantiated from \u2018boost::function2::function2(Functor, 
typename boost::enable_if_c<(! boost::is_integral::value), int>::type) 
[with Functor = std::_Bind, 
std::_Placeholder<2>))(pid_t, int)>, R = void, T0 = int, T1 = int]\u2019
../../3rdparty/boost/boost/function/function_template.hpp:1072: 
instantiated from \u2018boost::function::function(Functor, 
typename boost::enable_if_c<(! boost::is_integral::value), int>::type) 
[with Functor = std::_Bind, 
std::_Placeholder<2>))(pid_t, int)>, R = void, T0 = pid_t, T1 = int]\u2019
../../3rdparty/boost/boost/signals/slot.hpp:111:   instantiated from 
\u2018boost::slot::slot(const F&) [with F = 
std::_Bind, std::_Placeholder<2>))(pid_t, 
int)>, SlotFunction = boost::function]\u2019

ForkedCalls.cpp:478:   instantiated from here
../../3rdparty/boost/boost/function/function_template.hpp:159: error: no 
match for call to \u2018(std::_Bind, 
std::_Placeholder<2>))(pid_t, int)>) (int, int)\u2019
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1_impl/functional:1189: 
note: candidates are: typename std::result_of<_Functor(typename 
std::result_of 0)>(_Bound_args, std::tuple<_UElements 
...>)>::type ...)>::type std::_Bind<_Functor(_Bound_args 
...)>::operator()(_Args& ...) [with _Args = int, int, _Functor = void 
(*)(pid_t, int), _Bound_args = std::_Placeholder<1>, std::_Placeholder<2>]
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1_impl/functional:1200: 
note: typename std::result_ofstd::result_of 0)>(_Bound_args, std::tuple<_UElements 
...>)>::type ...)>::type std::_Bind<_Functor(_Bound_args 
...)>::operator()(_Args& ...) const [with _Args = int, int, _Functor = 
void (*)(pid_t, int), _Bound_args = std::_Placeholder<1>, 
std::_Placeholder<2>]
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1_impl/functional:1212: 
note: typename std::result_ofstd::result_of 0)>(_Bound_args, std::tuple<_UElements 
...>)>::type ...)>::type std::_Bind<_Functor(_Bound_args 
...)>::operator()(_Args& ...) volatile [with _Args = int, int, _Functor 
= void (*)(pid_t, int), _Bound_args = std::_Placeholder<1>, 
std::_Placeholder<2>]
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1_impl/functional:1225: 
note: typename std::result_of_Functor(typename std::result_of 
0)>(_Bound_args, std::tuple<_UElements ...>)>::type ...)>::type 
std::_Bind<_Functor(_Bound_args ...)>::operator()(_Args& 

Re: lyx-2.3.0alpha1-1 crash

[PhilipPirrip]

On 05/28/2017 08:20 AM, Guillaume MM wrote:

Here is a patch, reviews are welcome.


Can't say much about the patch, but want to confirm that LyX is not 
crashing any more.


Also pinging others to review the code, I think this is a pretty nasty 
bug that definitely needs more testing.

Re: [LyX/master] skip graphics conversion when runparams.dryrun is true

[Scott Kostyshak]

On Fri, May 05, 2017 at 08:30:51AM +0200, Tommaso Cucinotta wrote:
> commit 0cf394dd79337b14adb2930a617c2027e0d6f2d8
> Author: Tommaso Cucinotta 
> Date:   Thu May 4 07:49:07 2017 +0200
> 
> skip graphics conversion when runparams.dryrun is true

After this commit, if I copy a selection that has an image in it, I get
the following message:

insets/InsetGraphics.cpp (956): InsetGraphics::xhtml: Unable to prepare file 
`/home/scott/lyxbuilds/2017-05-17/repo/lib/images/buffer-write.svgz' for 
output. File missing?

Attached is a patch but I have no idea if it's correct.

Scott
diff --git a/src/insets/InsetGraphics.cpp b/src/insets/InsetGraphics.cpp
index 16a482f..2a0a90a 100644
--- a/src/insets/InsetGraphics.cpp
+++ b/src/insets/InsetGraphics.cpp
@@ -952,8 +952,10 @@ docstring InsetGraphics::xhtml(XHTMLStream & xs, 
OutputParams const & op) const
prepareHTMLFile(op);
 
if (output_file.empty()) {
-   LYXERR0("InsetGraphics::xhtml: Unable to prepare file `" 
-   << params().filename << "' for output. File missing?");
+   if (!op.dryrun) {
+   LYXERR0("InsetGraphics::xhtml: Unable to prepare file 
`" 
+   << params().filename << "' for output. File 
missing?");
+   }
string const attr = "src='" + params().filename.absFileName() 
+ "' alt='image: " + output_file + "'";
xs << html::CompTag("img", attr);


signature.asc
Description: PGP signature

Re: #10119: Shortcut Control-M

[Scott Kostyshak]

On Thu, Jun 01, 2017 at 01:03:15PM -0400, Scott Kostyshak wrote:
> On Tue, May 30, 2017 at 05:50:10PM +0200, Luca Brandolini wrote:
> > I forgot to mention that this strange behavior started with LyX 2.2.0 since 
> > in LyX 2.1.5 the Italian keyboard used to work smoothly.
> 
> This is an important detail.
> 
> Stephan, if it also worked for you on 2.1.5, do you think it would be
> worth a bisect?

I think it's also possible that it was a change in Qt behavior. Would be
good to know.

Scott


signature.asc
Description: PGP signature

Re: Bug #10295

[Scott Kostyshak]

On Tue, May 30, 2017 at 03:13:30PM -0400, Richard Heck wrote:
> On 05/29/2017 12:05 PM, Scott Kostyshak wrote:
> > On Tue, May 16, 2017 at 10:18:05PM -0400, Richard Heck wrote:
> >> Can anyone test the fix for this bug posted at
> >>
> >> http://www.lyx.org/trac/ticket/10295
> >>
> >> It'd be nice to have a decent version for beta1.
> > I can't reproduce the bug. Can anyone reproduce and then check that
> > Richard's patch makes it go away?
> 
> JMarc confirmed it. We should try to get this into beta, but I won't be
> able to get to it for a day or two.

I agree.

Scott


signature.asc
Description: PGP signature

Re: #10119: Shortcut Control-M

[Scott Kostyshak]

On Tue, May 30, 2017 at 05:50:10PM +0200, Luca Brandolini wrote:
> I forgot to mention that this strange behavior started with LyX 2.2.0 since 
> in LyX 2.1.5 the Italian keyboard used to work smoothly.

This is an important detail.

Stephan, if it also worked for you on 2.1.5, do you think it would be
worth a bisect?

Scott


signature.asc
Description: PGP signature

Re: 2 error in lyx 2.3

[Scott Kostyshak]

On Wed, May 31, 2017 at 11:25:18AM -0400, Richard Heck wrote:
> On 05/31/2017 07:40 AM, edu Gpl wrote:
> > Dear Lyx Team
> > thank you for all.
> > i got 2 error after i upgrade from lyx 2.2.2 to 2.3 .
> >
> > 1st:
> > when i generate my book, i got this msg:
> >
> 
> This is a warning that means exactly what it says. If it worked in 2.2.x,
> that was only a happy accident. You should not use "title" layouts after
> "non-title" layouts. The solution is to move the Dedication into the title
> area of your document.

+1

In some cases there is no change in output, but in other cases the
situation can cause problems (e.g. one of the environments not being
output in the PDF) with LaTeX.

Scott


signature.asc
Description: PGP signature

Re: syntax error in po files due to Windows line endings

[Scott Kostyshak]

On Tue, May 30, 2017 at 10:47:45AM +0200, Kornel Benko wrote:
> Am Montag, 29. Mai 2017 um 23:10:06, schrieb Scott Kostyshak 
> 
> > On master when I do (CMake)
> > 
> > make layouttranslations1
> > 
> > I get
> > 
> > OSError: Syntax error in po file 
> > /home/scott/lyxbuilds/master/repo/po/ar.po (line 35)
> > 
> > and indeed there are Windows line endings.
> > 
> > Scott
> 
> Yes, and if corrected in this file, we get errors in ca.po.
> 
> The same error as already corrected by Georg more than once.
> (See 7fa742d186a188)

I see, thanks for the reference.

Scott


signature.asc
Description: PGP signature

Re: 2 error in lyx 2.3

[Scott Kostyshak]

On Wed, May 31, 2017 at 02:40:40PM +0300, edu Gpl wrote:
> Dear Lyx Team
> thank you for all.
> i got 2 error after i upgrade from lyx 2.2.2 to 2.3 .

In the future, please specifiy whether you mean 2.3.0alpha1 or the
current master branch on Git.

Also note that you should not use an alpha1 for serious work without
being very careful. I apologize for not making a bigger deal about this
in the announcement.

Finally, thank you for testing the development of 2.3.0! This is very
helpful to us and please let us know if you find any regressions.

Scott


signature.asc
Description: PGP signature

Re: Backwards compatibility with 2.1 and older?

[Enrico Forestieri]

On Thu, Jun 01, 2017 at 02:12:56PM +, Guenter Milde wrote:
> 
> Below is a "stub patch", that tries to achieve this but fails due to my
> limite understanding of C++ and LyX code.
> I copy-pasted from Text.cpp and factory.cpp and did some edits.
> However, in a test file (2.1 file containing ---), the inserted ERT was
> empty and the console showed
> 
>   Lexer.cpp (934): Missing 'ert'-tag in InsetERT::string2params. Got -- 
> instead. Line: 0
> 
> Also, I would prefer the new-created ERT-insets to be "closed" (less
> distractive in the GUI).

Please, try the attached. I don't know what you are trying to do,
but I hope you are not trying to sabotage the last fixes to the
en/emdash mess. I would be really upset to see all of them as ert.
If this is a first step toward a really clean solution (to solve I
don't know what), that would be fine, though.

-- 
Enrico
diff --git a/src/Text.cpp b/src/Text.cpp
index 038553ba44..617e782701 100644
--- a/src/Text.cpp
+++ b/src/Text.cpp
@@ -52,6 +52,7 @@
 #include "insets/InsetText.h"
 #include "insets/InsetBibitem.h"
 #include "insets/InsetCaption.h"
+#include "insets/InsetERT.h"
 #include "insets/InsetNewline.h"
 #include "insets/InsetNewpage.h"
 #include "insets/InsetArgument.h"
@@ -508,10 +509,15 @@ void Text::readParToken(Paragraph & par, Lexer & lex,
else
par.insert(par.size(), from_ascii("---"), font, 
change);
} else {
-   if (token == "\\twohyphens")
-   par.insertChar(par.size(), 0x2013, font, 
change);
-   else
-   par.insertChar(par.size(), 0x2014, font, 
change);
+   InsetERT * ert = new InsetERT(buf, 
InsetCollapsable::Collapsed);
+   if (token == "\\twohyphens") {
+   ert->setText(from_ascii("--"), font,
+buf->params().track_changes);
+   } else {
+   ert->setText(from_ascii("---"), font,
+buf->params().track_changes);
+   }
+   par.insertInset(par.size(), ert, font, change);
}
} else if (token == "\\backslash") {
par.appendChar('\\', font, change);

Re: Backwards compatibility with 2.1 and older?

[Guenter Milde]

Dear Richard,

On 2017-05-31, Richard Heck wrote:
> On 04/26/2017 03:49 PM, Guenter Milde wrote:
>> Dear LyX developers,

>> How important is backwards compatibility for documents generated with LyX
>> 2.1 or older?

>>a) no need to restore after it's broken by 2.2.
>>b) good but not required 
>>c) small changes tolerable as long as documents
>>   open and compile
>>d) 100% backwards compatibility whenever possible.

> I believe the rule is (d).

>> Unfortunately, LyX 2.2 breaks backwards compatibility regarding the
>> line-break behaviour of em-dash and en-dash (changed behaviour for
>> documents using "ligature dashes").

>> Full backwards compatibility with pre-2.2 documents requires separate
>> representations for "ligature dashes" and "literal dashes". As 2.2 has
>> only "literal dashes", we would need a representation for
>> "ligature-dashes" in documents generated with LyX 2.1 or older.

>> Which of the alternatives do you prefer in case we want to restore
>> compatibility?

>> a) -- and --- as ERT

> This seems the simplest.

Below is a "stub patch", that tries to achieve this but fails due to my
limite understanding of C++ and LyX code.
I copy-pasted from Text.cpp and factory.cpp and did some edits.
However, in a test file (2.1 file containing ---), the inserted ERT was
empty and the console showed

  Lexer.cpp (934): Missing 'ert'-tag in InsetERT::string2params. Got -- 
instead. Line: 0

Also, I would prefer the new-created ERT-insets to be "closed" (less
distractive in the GUI).

Günter

diff --git a/src/Text.cpp b/src/Text.cpp
index 4e593ddf23..790d0bf354 100644
--- a/src/Text.cpp
+++ b/src/Text.cpp
@@ -52,6 +52,7 @@
 #include "insets/InsetText.h"
 #include "insets/InsetBibitem.h"
 #include "insets/InsetCaption.h"
+#include "insets/InsetERT.h"
 #include "insets/InsetNewline.h"
 #include "insets/InsetNewpage.h"
 #include "insets/InsetArgument.h"
@@ -516,10 +517,15 @@ void Text::readParToken(Paragraph & par, Lexer & lex,
else
par.insert(par.size(), from_ascii("---"), font, 
change);
} else {
+   auto_ptr inset;
if (token == "\\twohyphens")
-   par.insertChar(par.size(), 0x2013, font, 
change);
+   inset.reset(new InsetERT(buf,
+   
InsetERT::string2params(to_utf8(_("--");
else
-   par.insertChar(par.size(), 0x2014, font, 
change);
+   inset.reset(new InsetERT(buf,
+   
InsetERT::string2params(to_utf8(_("--");
+   /* inset->setBuffer(*buf); */
+   par.insertInset(par.size(), inset.release(), font, 
change);
}
} else if (token == "\\backslash") {
par.appendChar('\\', font, change);

Re: cmake and make install

[Kornel Benko]

Am Donnerstag, 1. Juni 2017 um 11:38:54, schrieb Cor Blom 
> Op 01-06-17 om 09:57 schreef Kornel Benko:
> > Am Donnerstag, 1. Juni 2017 um 08:56:06, schrieb Cor Blom 
> > 
> > 
> > What is this BuildService about?
> 
> This buildservice is used to build the openSUSE distribution. It's like 
> Ubuntu's PPA. I want to see if cmake is a usuable alternative for 
> building the lyx package for openSUSE. I am the maintainer of the 
> official package in the distro. And I like a challenge.
> 
> >>
> >> make
> > 
> > Here it should be
> > 'make package'
> 
> If I understand correctly this is for creating a package on a local 
> computer, but not usable for distribution packaging.

There should be no difference ... you could at least try.
Cpack installs in a fake-root and creates a package from the fake-installed data
The result of using the rpm is, from my POV, like 'make install'.

> > 
> >> make install
> > 
> > Here: sudo rpm -U lyx23-2.3.0-something.rpm
> > 
> >> (the "%cmake"  macro inheritis all kind of openSUSE settings).
> > 
> > Which ones?
> 
> Expanded it becomes this:
> 
> find . -name CMakeLists.txt -exec sed -i -re 
> '/^[[:blank:]]*[sS][eE][tT][[:blank:]]*\([[:blank:]]*(CMAKE_BUILD_TYPE|CMAKE_COLOR_MAKEFILE|CMAKE_INSTALL_PREFIX|CMAKE_VERBOSE_MAKEFILE).*\)/{s/^/#IGNORE
>  
> /}' '{}' +

Outch. What went wrong if not using this command?
I AM interested.
Specifically
CMAKE_VERBOSE_MAKEFILE will be reset with -DLYX_QUIET=ON
CMAKE_INSTALL_PREFIX will be set on the commandline

> mkdir -p build
> cd build
> /usr/bin/cmake .. '-GUnix Makefiles' -DCMAKE_INSTALL_PREFIX:PATH=/usr

The following three settings are not used
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share

[snip]

> >>
> >> make: *** No rule to make target 'install'.  Stop.
> > 
> > That is surprising. What is the output of 'make help'? It should be the list
> > of all targets.
> > Here it is:
> > #make help|grep install
> > ... install/local
> > ... install/strip
> > ... list_install_components
> > ... install
> > 
> 
> As I don't build locally I don't have access to "make help". I will look 
> into that later, when I've more time. (I'm not in a hurry to solve this).
> 
> Thanks for the help,
> 
> Cor

Kornel

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

Re: cmake and make install

[Cor Blom]

Op 01-06-17 om 09:57 schreef Kornel Benko:

Am Donnerstag, 1. Juni 2017 um 08:56:06, schrieb Cor Blom 

What is this BuildService about?


This buildservice is used to build the openSUSE distribution. It's like 
Ubuntu's PPA. I want to see if cmake is a usuable alternative for 
building the lyx package for openSUSE. I am the maintainer of the 
official package in the distro. And I like a challenge.




make


Here it should be
'make package'


If I understand correctly this is for creating a package on a local 
computer, but not usable for distribution packaging.





make install


Here: sudo rpm -U lyx23-2.3.0-something.rpm


(the "%cmake"  macro inheritis all kind of openSUSE settings).


Which ones?


Expanded it becomes this:

find . -name CMakeLists.txt -exec sed -i -re 
'/^[[:blank:]]*[sS][eE][tT][[:blank:]]*\([[:blank:]]*(CMAKE_BUILD_TYPE|CMAKE_COLOR_MAKEFILE|CMAKE_INSTALL_PREFIX|CMAKE_VERBOSE_MAKEFILE).*\)/{s/^/#IGNORE 
/}' '{}' +

mkdir -p build
cd build
/usr/bin/cmake .. '-GUnix Makefiles' -DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share 
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 -DCMAKE_BUILD_TYPE=RelWithDebInfo 
'-DCMAKE_C_FLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -Wall 
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -DNDEBUG' 
'-DCMAKE_CXX_FLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -Wall 
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -DNDEBUG' 
'-DCMAKE_Fortran_FLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -DNDEBUG' 
'-DCMAKE_EXE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' 
'-DCMAKE_MODULE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined 
-Wl,-z,now' '-DCMAKE_SHARED_LINKER_FLAGS=-Wl,--as-needed 
-Wl,--no-undefined -Wl,-z,now' -DLIB_SUFFIX=64 
-DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF 
-DCMAKE_COLOR_MAKEFILE:BOOL=OFF -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF 
-DCMAKE_MODULES_INSTALL_DIR=/usr/share/cmake/Modules -DLYX_INSTALL=ON 
-DLYX_USE_QT=QT5 -DLYX_EXTERNAL_BOOST=OFF -DLYX_PROGRAM_SUFFIX=ON 
-DLYX_ASPELL=OFF -DLYX_HUNSPELL=ON -DLYX_ENCHANT=ON





I'm stuck with the "make install" part. The first two steps are running
fine. I get the following error:

make: *** No rule to make target 'install'.  Stop.


That is surprising. What is the output of 'make help'? It should be the list
of all targets.
Here it is:
#make help|grep install
... install/local
... install/strip
... list_install_components
... install



As I don't build locally I don't have access to "make help". I will look 
into that later, when I've more time. (I'm not in a hurry to solve this).


Thanks for the help,

Cor

Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 30/05/2017 à 21:12, Richard Heck a écrit :

Richard, this is about using QTextlayout caching for MacOS with Qt5.
Qt5 is supposed to do caching, but it is very inefficient on MacOS
with ancient Hebrew. OK for 2.2.4?


Sure.


Thanks. I just did it.

JMarc

Re: cmake and make install

[Kornel Benko]

Am Donnerstag, 1. Juni 2017 um 08:56:06, schrieb Cor Blom 
> Hi,
> 
> I'm experimenting with building lyx (2.3 git) with cmake in the openSUSE 
> BuildService. I'm using the following commands:

What is this BuildService about?

> %cmake \
>  -DLYX_INSTALL=ON \

Why don't you use
-DLYX_CPACK=ON
-DCPACK_BINARY_RPM:BOOL=ON
instead?
That way you should get rpm package.

>  -DLYX_USE_QT=QT5 \
>  -DLYX_EXTERNAL_BOOST=OFF \
>  -DLYX_PROGRAM_SUFFIX=ON \
>  -DLYX_ASPELL=OFF \
>  -DLYX_HUNSPELL=ON \
>  -DLYX_ENCHANT=ON

I would add also
-DLYX_LOCALVERSIONING=ON

> 
> make

Here it should be
'make package'

> make install

Here: sudo rpm -U lyx23-2.3.0-something.rpm

> (the "%cmake"  macro inheritis all kind of openSUSE settings).

Which ones?

> I'm stuck with the "make install" part. The first two steps are running 
> fine. I get the following error:
> 
> make: *** No rule to make target 'install'.  Stop.

That is surprising. What is the output of 'make help'? It should be the list
of all targets.
Here it is:
#make help|grep install
... install/local
... install/strip
... list_install_components
... install


> Is there a solution?

Do you use different directories for build and sources?
I don't know how different your BuildService uses our cmake-files.

> Thanks,
> 
> Cor
> 
> P.S.: my experimenting can be found here:
> 
> https://build.opensuse.org/package/show/home:cornelisbb:lyx-unstable/lyx-qt5


Kornel

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

cmake and make install

[Cor Blom]

Hi,

I'm experimenting with building lyx (2.3 git) with cmake in the openSUSE 
BuildService. I'm using the following commands:


%cmake \
-DLYX_INSTALL=ON \
-DLYX_USE_QT=QT5 \
-DLYX_EXTERNAL_BOOST=OFF \
-DLYX_PROGRAM_SUFFIX=ON \
-DLYX_ASPELL=OFF \
-DLYX_HUNSPELL=ON \
-DLYX_ENCHANT=ON

make

make install

(the "%cmake"  macro inheritis all kind of openSUSE settings).

I'm stuck with the "make install" part. The first two steps are running 
fine. I get the following error:


make: *** No rule to make target 'install'.  Stop.

Is there a solution?

Thanks,

Cor

P.S.: my experimenting can be found here:

https://build.opensuse.org/package/show/home:cornelisbb:lyx-unstable/lyx-qt5