Re: LyXRC - %%s/scripts

[Scott Kostyshak]

On Sun, Oct 23, 2016 at 09:47:10PM +0200, Tommaso Cucinotta wrote:

> For me, this [1] fixes the issue: commit d5495caa in tommaso/master

Thanks for coming up with a fix and sorry for the trouble my commit
caused.

> FYI, with this patch, I can finally have a proper patch for gnuplot scripts: 
> a6053cf9

Nice, I know that comes up occassionally on the list. It's good to know
we can make some progress on it.

Scott


signature.asc
Description: PGP signature

Re: please revert: [LyX/2.2.x] Better title for ViewSource

[Richard Heck]

On 10/23/2016 06:38 PM, Guillaume Munch wrote:
>
> I can revert the menu name to "Source Pane" in 2.2.x for the
> documentation reasons you gave. I can also revert it in master if
> the majority wants it. But I hope that my explanation reassured
> you.
>

I think that's a good idea for 2.2.x, and I'm sorry I didn't catch it
before.
As you say, the rest of the commit is fine, and helpful.

Richard

Re: Possible Qt5 bugs (bug 10436)

[Scott Kostyshak]

On Sun, Oct 23, 2016 at 09:36:46PM +0200, Jean-Marc Lasgouttes wrote:

> It would be nice to report at least the first issue (see
> GuiFontMetrics::width), but I do not know how to make a self contained Qt
> program for this kind of thing. How minimal can I afford to be?

I have had unfortunately avoided making Qt bug reports for the same
reason. Perhaps ask on Qt's dev mailing list?

> While the second issue is about an undocumented flag, it is probably worth
> reporting too.

> I'd also be happy to have reports that the patch works in your favorite
> weird configuration.

It works well for me in very limited testing.

> + lyxerr << "WIDTH[" << s << "]=" << w <

Re: [LyX/master] Correctly track ulem commands with change tracking

[Guillaume Munch]

Le 24/10/2016 à 01:00, Enrico Forestieri a écrit :

On Sun, Oct 23, 2016 at 11:52:55PM +0200, Guillaume Munch wrote:


The code does look fragile to me. I do not think that asking that
developers care about maintainability is being overzealous. Then, maybe
I am mistaken about the code and you got to something found maintainable
enough after thinking about it a lot, such that you did not feel the
need asking for advice. In that case, maybe all the misunderstandings
comes indeed from a different appreciation of what effort is asked.

But to know this we would need to speak about the code. Every time I
want to discuss your commits, I know that you are going to take things
personally, to the point that sometimes I just prefer to let it off
before even asking. I do not know another LyX developer who reacts like
you do.


It's not what you say but how you say it.


Before arguing that I am not the official maintainer, ask yourself who
was the only one who tested several of your big changes and spent a lot
of time writing detailed testcases (lots of them!)? And where would LyX
be if I had not?


I think you have an enormous ego and presumptuous manners.
I have nothing more to add to this discussion. Good bye.



Yeah, I see how this comes across, this is not what I meant, does not
correspond to what I think, and I regret writing this. The discussion
went nowhere I wanted and I regret starting it. I will no longer send
such messages to the list in the future.

Re: [LyX/master] Correctly track ulem commands with change tracking

[Enrico Forestieri]

On Sun, Oct 23, 2016 at 11:52:55PM +0200, Guillaume Munch wrote:
> 
> The code does look fragile to me. I do not think that asking that
> developers care about maintainability is being overzealous. Then, maybe
> I am mistaken about the code and you got to something found maintainable
> enough after thinking about it a lot, such that you did not feel the
> need asking for advice. In that case, maybe all the misunderstandings
> comes indeed from a different appreciation of what effort is asked.
> 
> But to know this we would need to speak about the code. Every time I
> want to discuss your commits, I know that you are going to take things
> personally, to the point that sometimes I just prefer to let it off
> before even asking. I do not know another LyX developer who reacts like
> you do.

It's not what you say but how you say it.

> Before arguing that I am not the official maintainer, ask yourself who
> was the only one who tested several of your big changes and spent a lot
> of time writing detailed testcases (lots of them!)? And where would LyX
> be if I had not?

I think you have an enormous ego and presumptuous manners.
I have nothing more to add to this discussion. Good bye.

-- 
Enrico

Re: please revert: [LyX/2.2.x] Better title for ViewSource

[Guillaume Munch]

Le 23/10/2016 à 23:20, Uwe Stöhr a écrit :

commit a36706c3ffe9570588962a5ad3206d57e63ffcfd
Author: Guillaume Munch 
Date:   Sun Aug 28 21:57:17 2016 +0100

Better title for ViewSource


Sorry for being quite rude here:
I am strictly opposed to these changes. LyX 2.2.x are bugfix releases.
If the developers agree also some new features can go in. But these
string changes are completely unnecessary in a bugfix release.

The documentation is for all 2.2.x releases, as their title says. Unless
bugs are fixed, there is no reason to change menu names. The consequence
is that the docs of 2.2.x would differ for every release in a way that
new users don't find the appropriate menu name.

I can also not find a discussion where we made a decision to rename menu
names without fixing a bug in a bugfix release.

Therefore please revert these renamings.

In general, what is the benefit of renaming
"Source Pane|S"
to
"Code Preview Pane|P" ?
I cannot see any advantage other than a lot of works to update the docs
and the Wiki pages.
Moreover, this changes the accelerator key. So you force users to learn
a new one one an unchanged feature.
Source is the Code.  So what?

thanks and regards



Hi Uwe,


You are not being rude at all, in fact you are quite polite. And it is
not too late to re-open an old discussion given that nothing has been
released yet.

First, surely you do not mean to revert the entire commit. The main
purpose of the patch is to change the title of GuiViewSource to "LaTeX
(pdflatex) preview", "LyXHTML preview", etc. The default title "Code
Preview" does not appear in practice. I think you are mainly referring
to the change in the menu name.

During the discussions, I saw some confusion about the meaning of
"source" and "code", and you even say that they mean the same to you.
This is not true, and this change is meant for people who make the
distinction. You say that it does not fix a bug, but I already explained
that the former name introduced the confusion that LyX is a LaTeX
editor. Maybe I was not clear enough, I am really concrete here: I saw
new users (coming from LaTeX) focusing on GuiViewSource, trying hard to
"edit" the ViewSourceWidget, thinking it was really the source, and
ending up very disappointed.

I have to admit that I was careless about changing the accelerator. I
understand your point. I think that the best solution instead is to have
"Code Preview Pane|S" as a reminiscence of the former name (just like
GuiViewSource is going to remain GuiViewSource). I am ready to have this
cosmetic discrepancy to fix such an issue.

I can revert the menu name to "Source Pane" in 2.2.x for the
documentation reasons you gave. I can also revert it in master if
the majority wants it. But I hope that my explanation reassured
you.


Guillaume

Re: [LyX/master] Correctly track ulem commands with change tracking

[Guillaume Munch]

Le 23/10/2016 à 22:53, Enrico Forestieri a écrit :

On Sun, Oct 23, 2016 at 07:02:31PM +0200, Guillaume Munch wrote:


Le 23/10/2016 à 18:38, Enrico Forestieri a écrit :

commit dea5ba16de1b98d93cf30ab65119bc2364a7ac2b
Author: Enrico Forestieri 
Date:   Sun Oct 23 18:23:41 2016 +0200

Correctly track ulem commands with change tracking

LyX assumes that everything in \lyxdeleted is struck out by ulem
and increases the corresponding counter. However, deleted display
math material is struck out using tikz. As we also take into
account the deletion of underlined display math (in order to
properly position such material vertically), we have to take
care that the count is correct.



This code (this commit and previous related commits) looks fragile to
me. Did you not prefer to present a (full and tested) patch on the list
and ask other people about it before committing?


Sorry, but I think that your comments are unwarranted and overzealous.
Moreover, this is something that you should pretend from a novice.
I think I know when something should be submitted for review before
committing. And you are not the official maintainer. Please, try
to be less off-putting. Thank you.



The code does look fragile to me. I do not think that asking that
developers care about maintainability is being overzealous. Then, maybe
I am mistaken about the code and you got to something found maintainable
enough after thinking about it a lot, such that you did not feel the
need asking for advice. In that case, maybe all the misunderstandings
comes indeed from a different appreciation of what effort is asked.

But to know this we would need to speak about the code. Every time I
want to discuss your commits, I know that you are going to take things
personally, to the point that sometimes I just prefer to let it off
before even asking. I do not know another LyX developer who reacts like
you do.

Before arguing that I am not the official maintainer, ask yourself who
was the only one who tested several of your big changes and spent a lot
of time writing detailed testcases (lots of them!)? And where would LyX
be if I had not?

I wish we could speak about the code instead.


Guillaume

please revert: [LyX/2.2.x] Better title for ViewSource

[Uwe Stöhr]

commit a36706c3ffe9570588962a5ad3206d57e63ffcfd
Author: Guillaume Munch 
Date:   Sun Aug 28 21:57:17 2016 +0100

Better title for ViewSource


Sorry for being quite rude here:
I am strictly opposed to these changes. LyX 2.2.x are bugfix releases. 
If the developers agree also some new features can go in. But these 
string changes are completely unnecessary in a bugfix release.


The documentation is for all 2.2.x releases, as their title says. Unless 
bugs are fixed, there is no reason to change menu names. The consequence 
is that the docs of 2.2.x would differ for every release in a way that 
new users don't find the appropriate menu name.


I can also not find a discussion where we made a decision to rename menu 
names without fixing a bug in a bugfix release.


Therefore please revert these renamings.

In general, what is the benefit of renaming
"Source Pane|S"
to
"Code Preview Pane|P" ?
I cannot see any advantage other than a lot of works to update the docs 
and the Wiki pages.
Moreover, this changes the accelerator key. So you force users to learn 
a new one one an unchanged feature.

Source is the Code.  So what?

thanks and regards
Uwe

Re: procmail (was: [PATCH] Re: Return + Return in nested environments)

[Enrico Forestieri]

On Sat, Oct 22, 2016 at 09:55:02PM -0700, Pavel Sanda wrote:

> Enrico Forestieri wrote:
> > Yes, of course, because procmail inserted a ">" just in front of the
> > "From " line in the attachment (which I do manually).
> > 
> > Care to share the corresponding config line(s) for procmail?
> 
> Hmm, nothing special:
> 
> :0
> *List-Post: 
> .lyx.devel

Ok, thanks anyway.

-- 
Enrico

Re: [LyX/master] Correctly track ulem commands with change tracking

[Enrico Forestieri]

On Sun, Oct 23, 2016 at 07:02:31PM +0200, Guillaume Munch wrote:

> Le 23/10/2016 à 18:38, Enrico Forestieri a écrit :
> > commit dea5ba16de1b98d93cf30ab65119bc2364a7ac2b
> > Author: Enrico Forestieri 
> > Date:   Sun Oct 23 18:23:41 2016 +0200
> > 
> > Correctly track ulem commands with change tracking
> > 
> > LyX assumes that everything in \lyxdeleted is struck out by ulem
> > and increases the corresponding counter. However, deleted display
> > math material is struck out using tikz. As we also take into
> > account the deletion of underlined display math (in order to
> > properly position such material vertically), we have to take
> > care that the count is correct.
> 
> 
> This code (this commit and previous related commits) looks fragile to
> me. Did you not prefer to present a (full and tested) patch on the list
> and ask other people about it before committing?

Sorry, but I think that your comments are unwarranted and overzealous.
Moreover, this is something that you should pretend from a novice.
I think I know when something should be submitted for review before
committing. And you are not the official maintainer. Please, try
to be less off-putting. Thank you.

-- 
Enrico

Re: [LyX/master] Correctly track ulem commands with change tracking

[Enrico Forestieri]

On Sun, Oct 23, 2016 at 09:09:22PM +0200, Guillaume Munch wrote:

> Le 23/10/2016 à 19:55, Richard Heck a écrit :
> > On 10/23/2016 01:02 PM, Guillaume Munch wrote:
> > > Le 23/10/2016 à 18:38, Enrico Forestieri a écrit :
> > > > commit dea5ba16de1b98d93cf30ab65119bc2364a7ac2b
> > > > Author: Enrico Forestieri 
> > > > Date:   Sun Oct 23 18:23:41 2016 +0200
> > > > 
> > > > Correctly track ulem commands with change tracking
> > > > 
> > > > LyX assumes that everything in \lyxdeleted is struck out by ulem
> > > > and increases the corresponding counter. However, deleted display
> > > > math material is struck out using tikz. As we also take into
> > > > account the deletion of underlined display math (in order to
> > > > properly position such material vertically), we have to take
> > > > care that the count is correct.
> > > 
> > > 
> > > This code (this commit and previous related commits) looks fragile to
> > > me. Did you not prefer to present a (full and tested) patch on the list
> > > and ask other people about it before committing?
> > 
> > Looked pretty straightforward to me. This is a very common use of an
> > OutputParams flag. In any event, I take it that this fixed a bug in some of
> > the previous work Enrico did on this. It's not usually our policy to
> > require
> > discussion of that kind of thing.
> > 
> > Where we do always want discussion is with significant changes of behavior,
> > and especially of UI-related changes that affect the user experience. If
> > I'm
> > remembering correctly, there has been some such discussion around how
> > deleted displayed math is handled.
> > 
> 
> Yes, each of the commits looks straightforward. Some of the flags
> were already there indeed. And yes, the change in behaviour has been
> discussed and is most welcome.
> 
> I meant something else. It seems that "common use of an OutputParams flag"
> results in having the logic of a feature scattered all around in tiny bits
> of code. I am worried that this is not going to be easy to
> maintain.
> 
> When I make small or large changes to the code I always try to give back
> something more modular than what I start with. So I wonder whether this
> logic could be centralized in some way.

Maybe you should try to understand the code in Paragraph::latex.
After I did that, it seemed so straightforward to me to not
require further comments.

-- 
Enrico

Re: LyXRC - %%s/scripts

[Tommaso Cucinotta]

On 20/10/2016 18:11, Scott Kostyshak wrote:

I have no idea. If you don't figure out the problem/fix, I can probably
take a look at this next week.


For me, this [1] fixes the issue: commit d5495caa in tommaso/master

FYI, with this patch, I can finally have a proper patch for gnuplot scripts: 
a6053cf9

T.

[1]
tommaso@tommylap:~/lyx-trunk-ws/lyx$ git show d5495caa
commit d5495caa
Author: Tommaso Cucinotta 
Date:   Sun Oct 23 21:35:56 2016 +0200

Fix bug in replacement of "$$s/" in converter commands, introduced in 
8b66f9ce.

diff --git a/src/graphics/GraphicsConverter.cpp 
b/src/graphics/GraphicsConverter.cpp
index ebb074cb..67b1580f 100644
--- a/src/graphics/GraphicsConverter.cpp
+++ b/src/graphics/GraphicsConverter.cpp
@@ -229,7 +229,7 @@ static string const move_file(string const & from_file, string 
const & to_file)
 static void build_conversion_command(string const & command, ostream & script)
 {
// Store in the python script
-   script << "\nif os.system(r'" << command << "') != 0:\n";
+   script << "\nif os.system(r'" << commandPrep(command) << "') != 0:\n";

// Test that this was successful. If not, remove
// ${outfile} and exit the python script

Possible Qt5 bugs (bug 10436)

[Jean-Marc Lasgouttes]

The following patch posted to
   http://www.lyx.org/trac/ticket/10436
works around two probable Qt5 bugs related to Arabic text:

 * with Qt5, QFontMetrics::width does not return the correct value for 
some Arabic text


 * Likewise, the undocumented layout flags TextForceRightToLeft and
TextForceLeftToRight do not work properly with Arabic text when trying 
to restrict the width of QTextLine. Again the width of text is not 
computed properly.


It might be that the two issues are related. In any case, they do not
happen with Latin text where right-to-left direction is enforced. And
they do not happen with Qt4.

It would be nice to report at least the first issue (see 
GuiFontMetrics::width), but I do not know how to make a self contained 
Qt program for this kind of thing. How minimal can I afford to be?


While the second issue is about an undocumented flag, it is probably 
worth reporting too.


I'd also be happy to have reports that the patch works in your favorite 
weird configuration.


JMarc


>From 0a66b79ab82f033ec1afa44a11bb57fad83151d3 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Sun, 23 Oct 2016 20:52:01 +0200
Subject: [PATCH] Work around issues with Qt5 and Arabic text

This fixes two particular problems

* with Qt5, it seems that QFontMetrics::width does not return the
  correct value for some Arabic text; this patch uses QTextLayout
  instead to compute a string width

* Likewise, the undocumented layout flags TextForceRightToLeft and
  TextForceLeftToRight do not work with Arabic text; this patch uses
  unicode override characters instead.

It might be that the two issues are related. In any case, they do not
happen with latin text where right-to-left direction is enforced. And
they do not happen with Qt4.

Additionally, remove dead code in GuiFontMetrics::pos2x().

Fixes bug #10436.
---
 src/frontends/qt4/GuiFontMetrics.cpp | 41 +---
 1 file changed, 33 insertions(+), 8 deletions(-)

diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index eade8cc..27dda7c 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -146,7 +146,17 @@ int GuiFontMetrics::width(docstring const & s) const
 	int * pw = strwidth_cache_[qba];
 	if (pw)
 		return *pw;
-	int w = metrics_.width(toqstr(s));
+	// For some reason QMetrics::width returns a wrong value with Qt5
+	// int w = metrics_.width(toqstr(s));
+	QTextLayout tl;
+	tl.setText(toqstr(s));
+	tl.setFont(font_);
+	tl.beginLayout();
+	QTextLine line = tl.createLine();
+	tl.endLayout();
+	int w = int(line.naturalTextWidth());
+
+	lyxerr << "WIDTH[" << s << "]=" << w < x)
+	if ((force && line.textLength() == offset) || int(line.naturalTextWidth()) > x)
 		return false;
 	x = int(line.naturalTextWidth());
-	// The -1 is here to account for the leading zerow_nbsp.
-	s = s.substr(0, line.textLength() - 1);
+	// The offset is here to account for the extra leading characters.
+	s = s.substr(0, line.textLength() - offset);
 	return true;
 }
 
-- 
2.9.3

Re: [LyX/master] Correctly track ulem commands with change tracking

[Guillaume Munch]

Le 23/10/2016 à 19:55, Richard Heck a écrit :

On 10/23/2016 01:02 PM, Guillaume Munch wrote:

Le 23/10/2016 à 18:38, Enrico Forestieri a écrit :

commit dea5ba16de1b98d93cf30ab65119bc2364a7ac2b
Author: Enrico Forestieri 
Date:   Sun Oct 23 18:23:41 2016 +0200

Correctly track ulem commands with change tracking

LyX assumes that everything in \lyxdeleted is struck out by ulem
and increases the corresponding counter. However, deleted display
math material is struck out using tikz. As we also take into
account the deletion of underlined display math (in order to
properly position such material vertically), we have to take
care that the count is correct.



This code (this commit and previous related commits) looks fragile to
me. Did you not prefer to present a (full and tested) patch on the list
and ask other people about it before committing?


Looked pretty straightforward to me. This is a very common use of an
OutputParams flag. In any event, I take it that this fixed a bug in some of
the previous work Enrico did on this. It's not usually our policy to
require
discussion of that kind of thing.

Where we do always want discussion is with significant changes of behavior,
and especially of UI-related changes that affect the user experience. If
I'm
remembering correctly, there has been some such discussion around how
deleted displayed math is handled.



Yes, each of the commits looks straightforward. Some of the flags
were already there indeed. And yes, the change in behaviour has been
discussed and is most welcome.

I meant something else. It seems that "common use of an OutputParams 
flag" results in having the logic of a feature scattered all around in 
tiny bits of code. I am worried that this is not going to be easy to

maintain.

When I make small or large changes to the code I always try to give back 
something more modular than what I start with. So I wonder whether this 
logic could be centralized in some way.



Guillaume

Re: [LyX/master] Correctly track ulem commands with change tracking

[Richard Heck]

On 10/23/2016 01:02 PM, Guillaume Munch wrote:
> Le 23/10/2016 à 18:38, Enrico Forestieri a écrit :
>> commit dea5ba16de1b98d93cf30ab65119bc2364a7ac2b
>> Author: Enrico Forestieri 
>> Date:   Sun Oct 23 18:23:41 2016 +0200
>>
>> Correctly track ulem commands with change tracking
>>
>> LyX assumes that everything in \lyxdeleted is struck out by ulem
>> and increases the corresponding counter. However, deleted display
>> math material is struck out using tikz. As we also take into
>> account the deletion of underlined display math (in order to
>> properly position such material vertically), we have to take
>> care that the count is correct.
>
>
> This code (this commit and previous related commits) looks fragile to
> me. Did you not prefer to present a (full and tested) patch on the list
> and ask other people about it before committing?

Looked pretty straightforward to me. This is a very common use of an
OutputParams flag. In any event, I take it that this fixed a bug in some of
the previous work Enrico did on this. It's not usually our policy to
require
discussion of that kind of thing.

Where we do always want discussion is with significant changes of behavior,
and especially of UI-related changes that affect the user experience. If
I'm
remembering correctly, there has been some such discussion around how 
deleted displayed math is handled.

Richard

Re: [LyX/master] On export, mark the start of the first paragraph

[Guillaume Munch]

Le 23/10/2016 à 19:02, Guillaume Munch a écrit :

Le 23/10/2016 à 18:17, Enrico Forestieri a écrit :

commit 9ba76e6c40738f9bd0d45d4cdb00a9842d47feec
Author: Enrico Forestieri 
Date:   Sun Oct 23 18:04:13 2016 +0200

On export, mark the start of the first paragraph

No newline is written after \begin{document}, such that
the afterParbreak method would return false. This misleads
the code that outputs a display math in an ulem command
to emit a newline command instead of \noindent, causing
latex errors. This occurs only if the math is at the very
start of a document, without anything before it.
---
 src/Buffer.cpp |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 67d4b3d..df3ae9f 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -1891,6 +1891,10 @@ void Buffer::writeLaTeXSource(otexstream & os,
 os.texrow().start(TexRow::beginDocument());
 os << "\\begin{document}\n";

+// mark the start of a new paragraph by simulating a newline,
+// so that os.afterParbreak() returns true at document start
+os.lastChar('\n');
+



I do not understand. Is os.lastChar('\n') not already called at the end
of os << "\\begin{document}\n" ?




Never mind, the answer is that os.lastChar('\n') behaves differently
when called the second time. (Somehow I did not get Enrico's comment.)

Re: [LyX/master] Correctly track ulem commands with change tracking

[Guillaume Munch]

Le 23/10/2016 à 18:38, Enrico Forestieri a écrit :

commit dea5ba16de1b98d93cf30ab65119bc2364a7ac2b
Author: Enrico Forestieri 
Date:   Sun Oct 23 18:23:41 2016 +0200

Correctly track ulem commands with change tracking

LyX assumes that everything in \lyxdeleted is struck out by ulem
and increases the corresponding counter. However, deleted display
math material is struck out using tikz. As we also take into
account the deletion of underlined display math (in order to
properly position such material vertically), we have to take
care that the count is correct.



This code (this commit and previous related commits) looks fragile to
me. Did you not prefer to present a (full and tested) patch on the list
and ask other people about it before committing?

Re: [LyX/master] On export, mark the start of the first paragraph

[Guillaume Munch]

Le 23/10/2016 à 18:17, Enrico Forestieri a écrit :

commit 9ba76e6c40738f9bd0d45d4cdb00a9842d47feec
Author: Enrico Forestieri 
Date:   Sun Oct 23 18:04:13 2016 +0200

On export, mark the start of the first paragraph

No newline is written after \begin{document}, such that
the afterParbreak method would return false. This misleads
the code that outputs a display math in an ulem command
to emit a newline command instead of \noindent, causing
latex errors. This occurs only if the math is at the very
start of a document, without anything before it.
---
 src/Buffer.cpp |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 67d4b3d..df3ae9f 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -1891,6 +1891,10 @@ void Buffer::writeLaTeXSource(otexstream & os,
os.texrow().start(TexRow::beginDocument());
os << "\\begin{document}\n";

+   // mark the start of a new paragraph by simulating a newline,
+   // so that os.afterParbreak() returns true at document start
+   os.lastChar('\n');
+



I do not understand. Is os.lastChar('\n') not already called at the end
of os << "\\begin{document}\n" ?

Re: Highlight text in style dialog via soul

[Joel Kulesza]

On Sun, Oct 23, 2016 at 9:25 AM, racoon  wrote:

>
> You might be able to create a module for soul. But, as far as I know, it
> is not possible to utilize the text style dialog for this. So that might
> not be too different from the PDF Comments module user interface wise. I
> don't have the capacity to dig into this at the moment. But maybe you can
> find someone else who is interested. You could always create an enhancement
> request in trac (http://www.lyx.org/trac/wiki/BugTrackerHome).
>

Having it more integrated than a module is what I would hope for.  Indeed,
I'll create the enhancement request but I first wanted to ask if anyone
knew how to do it (because I figured it would have been a standard
feature).

Highlight text in style dialog via soul

[racoon]

On 23.10.2016 17:13, Joel Kulesza wrote:
> On Sun, Oct 23, 2016 at 9:01 AM, racoon  > wrote:
>
>
> On 23.10.2016 16:55, Joel Kulesza wrote:
>
>
>
> Speaking of highlighting: is there a way to highlight text in
> LyX (e.g.,
> \hl{...} via soul) without ERT?  I can change its color, but 
not its

> background...
>
>
> The PDF Comments module's (Document > Settings > Modules) PDF Markup
> (Insert > Custom Inset) might help (Help > Specific Manuals > PDF
> comments).
>
>
> Thanks for the quick reply.  I'll have to explore that module more for
> other purposes as well.  However, the default highlighting color is
> blue.  This can be changed, but there is a lot of overhead here to do
> something that should probably be in Text Style dialog if all a user
> wants is highlighted text without all the PDF hooks.
>
> Perhaps the default color is something to attack in terms of sensible
> defaults in the short term and adding highlighting to Text Style is a
> long term change?

You might be able to create a module for soul. But, as far as I know, it 
is not possible to utilize the text style dialog for this. So that might 
not be too different from the PDF Comments module user interface wise. I 
don't have the capacity to dig into this at the moment. But maybe you 
can find someone else who is interested. You could always create an 
enhancement request in trac (http://www.lyx.org/trac/wiki/BugTrackerHome).

Re: LinuxDay @ Pisa - Oct 22nd

[Tommaso Cucinotta]

On 23/10/2016 01:27, Tommaso Cucinotta wrote:

[more or less, all things included in my tommaso repo, linux-day-2016 branch, 
perhaps I'll polish and push something else tomorrow]


pushed, details below [1].
http://git.lyx.org/?p=developers/tommaso/lyx.git;a=shortlog;h=refs/heads/linux-day-2016

T.

commit 58cd3b3f
Author: Tommaso Cucinotta 
Date:   Sun Oct 23 13:16:19 2016 +0200

Remove assert on advanced find with knitr module (#10444).

commit 7d6cbd87
Author: Tommaso Cucinotta 
Date:   Wed Oct 19 11:18:10 2016 +0200

Tolerate formats that are not supported by lyx2lyx.

commit d4ae1e6b
Author: Tommaso Cucinotta 
Date:   Mon Oct 17 08:44:16 2016 +0200

Enable graphics generation from external gnuplot scripts (draft).

Two major TODOs:
1. remove ugly abs path, which is there to work around 8b66f9ce, which
   broke %%s
2. convert the gnuplot2pdf.sh script to Python for portability

commit Author: Tommaso Cucinotta 
Date:   Sat Oct 15 01:14:02 2016 +0200

Create new graphics from within LyX choosing a sample file to copy from.

commit e85b0d01
Author: Tommaso Cucinotta 
Date:   Wed Oct 16 22:55:40 2013 +0100

LyX XMPP Chat

This patch enables XMPP-based chatting within LyX.

With contributions from Kornel Benko 

Re: [LyX/master] Fix Ticket #9741 misleading name for font-encoding setting "default".

[Jürgen Spitzmüller]

Am Sonntag, den 23.10.2016, 08:45 +0200 schrieb Jürgen Spitzmüller:
> In the meantime, could you please revert your original change? I
> think
> it is clear that we will change the strings, but differently.

Since you didn't do it, I did.

Jürgen

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

Re: Inverted colors for cursor

[Joel Kulesza]

On Sun, Oct 23, 2016 at 9:01 AM, racoon  wrote:

>
> On 23.10.2016 16:55, Joel Kulesza wrote:
>
>>
>>
>> Speaking of highlighting: is there a way to highlight text in LyX (e.g.,
>> \hl{...} via soul) without ERT?  I can change its color, but not its
>> background...
>>
>
> The PDF Comments module's (Document > Settings > Modules) PDF Markup
> (Insert > Custom Inset) might help (Help > Specific Manuals > PDF comments).


Thanks for the quick reply.  I'll have to explore that module more for
other purposes as well.  However, the default highlighting color is blue.
This can be changed, but there is a lot of overhead here to do something
that should probably be in Text Style dialog if all a user wants is
highlighted text without all the PDF hooks.

Perhaps the default color is something to attack in terms of sensible
defaults in the short term and adding highlighting to Text Style is a long
term change?

If you want to discuss this further, let's start another email thread to
keep things compartmentalized and keep this thread on track regarding
inverted cursors.  My apologies for diverting it to this degree already.

request to test Urdu support for LyX

[Uwe Stöhr]

Dear Jamil,

2 years ago you kindly tested LyX's support for Urdu. You found out that 
we had some font display bugs:

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

Since LyX 2.2 this bug is fixed and we also added some more support for 
right-to-left languages.


Now we want to enable full Urdu support and need your help in testing 
it. We therefore ask you to

- install LyX 2.2 (if possible 2.2.2)
- replace the file "languages" in LyX's installation folder with the 
attached one

- restart LyX and create some documents using Uru

You might encounter these 2 know issues that affect all RTL languages:
http://www.lyx.org/trac/ticket/10435
http://www.lyx.org/trac/ticket/10436
But since these bugs are independent of Urdu, they should not prevent us 
to support Urdu in the next major LyX release.


many thanks in advance and best regards
Uwe
##
#
# Languages supported by LyX.
#
# Syntax:
#
# Language 
#   GuiName""
#   HasGuiSupport  
#   BabelName  
#   PolyglossiaName
#   PolyglossiaOpts""
#   Encoding   
#   FontEncoding   
#   QuoteStyle 
#   InternalEncoding   
#   RTL
#   AsBabelOptions 
#   LangCode   
#   LangVariety
#   PreBabelPreamble
# 
#   EndPreBabelPreamble
#   PostBabelPreamble
# 
#   EndPostBabelPreamble
#   Requires   
# End
#
#
# NOTES:
#
# * Omitted elements will be treated as empty (if string) or "false"
#   (if boolean).
# * When HasGuiSupport is true, the language is candidate to appear in
#   the list of possible GUI languages in the Preferences dialog. It
#   will actually appear there only if a corresponding .mo file can be
#   found among the translations. When several languages correspond to
#   the same translation -- like English, English (US) and English
#   (UK) -- try to select the entry that is most generic -- here
#   English.
# * The QuoteStyle arguments correspond to the following styles:
#   - danish:  >>text<<  >text<   (inward guillemets)
#   - english: ``text''  `text'   (66_99)
#   - french:  <> (outward guillemets)
#   - german:  ,,text``  ,text`   (99/66)
#   - polish:  ,,text''  ,text'   (99/99)
#   - swedish: ''text''  'text'   (99_99)
#   Note that the option names have been selected (rather arbitrarily)
#   because the respective styles are common in the respective countries.
#   Of course this does not imply any fixed relation to those countries.
# * Encoding is the default encoding used with TeX fonts.
#   It is only used if Document > Settings > Language > Encoding
#   is set to "Language Default" and "use non-TeX fonts" is FALSE.
# * InternalEncoding is used to tell LyX that babel internally sets a
#   non-standard font encoding (such as hebrew to LHE or greek to LGR).
#   If True, LyX cares for characters/macros that do not exist in
#   some font encodings ("<", ">", "|" and straight quote).
#   It is not required for standard encodings like T2A. See bug #5091.
# * "FontEncoding none" tells LyX that fontenc should not be loaded with this
#   language.
# * AsBabelOptions advices LyX to pass the languages locally to babel, not
#   globally to the class. Some languages (basically those not directly
#   supported by babel) need this.
#   FIXME: in this case, we might still need to pass the other languages
#  globally, for the use of other packages (such as varioref).
# * LangCode is also used for spellchecking and thesaurus, where the
#   dictionaries are named accordingly. Thus, check this when introducing/
#   changing language codes (especially aspell, thesaurus).
#   TODO: maybe use Best Current Practice (BCP 47) codes for LangCode
# http://www.rfc-editor.org/rfc/bcp/bcp47.txt
# http://www.w3.org/International/articles/language-tags/
# http://www.iana.org/assignments/language-subtag-registry
# * LangVariety is used by the aspell spellchecker to differentiate
#   dictionaries for different varieties of a given language (e.g. German
#   pre-1998 and post-1998 spelling). The aspell dictionaries are named
#   language[_REGION][-variety].multi, e.g. de-alt.multi for "German (old
#   spelling)" (see http://aspell.net/man-html/Dictionary-Naming.html)
#
##

#
# LyX-internal languages
#

Language ignore
GuiName  "Ignore"
BabelNameignore
PolyglossiaName  ignore
Encoding iso8859-1
LangCode ignore
End

Language latex
GuiName  "LaTeX"
Encoding iso8859-1
LangCode latex
End

#
# Real languages
#

# not yet supported by polyglossia
Language afrikaans
GuiName  "Afrikaans"
BabelName

Re: Inverted colors for cursor

[racoon]

On 23.10.2016 16:55, Joel Kulesza wrote:

On Sun, Oct 23, 2016 at 8:39 AM, racoon > wrote:


I guess these are very limited applications as to the changes that
occur background color wise during usage.


I disagree: one can both select text (highlighting it to operate on it)
and highlight the text (e.g., through syntax highlighting).  In
particular, Vim can look like a veritable Christmas tree with different
colors everywhere.  However, this is all up to user preferences.  The
defaults are quite sane.

Speaking of highlighting: is there a way to highlight text in LyX (e.g.,
\hl{...} via soul) without ERT?  I can change its color, but not its
background...


The PDF Comments module's (Document > Settings > Modules) PDF Markup 
(Insert > Custom Inset) might help (Help > Specific Manuals > PDF comments).



Every user interface provides certain default that can't be changed
by the user because the user might not (and does not want to)
consider all the consequences. However, I personally have no problem
with having a preference for inverted cursor in general.


True, but I think that (a) the option is there in LyX already so it
should be preserved and (b) part of open source philosophy is freedom to
choose ... which may extend down to cursor color.


OSX is no application. ;) I know you mean LyX of course.


Aye.  I'm able and willing to work on all three major OSs, but choose
OSX.  However, I very quickly install LyX and Vim no matter where I am
if I will be there for any length of time.

Re: [LyX/master] unicodesymbols fixes.

[Guillaume Munch]

Le 23/10/2016 à 13:18, Guillaume Munch a écrit :


1942c1942
< \textrm{created with \textbf{\textbackslash frac}} &  &
\textrm{created with \textbf{\textbackslash cfrac}}\\
---

\textrm{created with \textbf{⧵frac}} &  & \textrm{created with

\textbf{⧵cfrac}}\\



As I understand, Günter fixed this at 6ff89c4b9 (I missed it before,
sorry). I am still curious for the questions below, if anybody knows.



Also, and more importantly, this shows that some changes to
lib/[unicode]symbols are in fact file format changes. Is it expected in
this case? Is it easy to see which kind of changes to these files are
file-format-changing and which ones are not?

Re: Inverted colors for cursor

[Joel Kulesza]

On Sun, Oct 23, 2016 at 8:39 AM, racoon  wrote:
>
>
> I guess these are very limited applications as to the changes that occur
> background color wise during usage.


I disagree: one can both select text (highlighting it to operate on it) and
highlight the text (e.g., through syntax highlighting).  In particular, Vim
can look like a veritable Christmas tree with different colors everywhere.
However, this is all up to user preferences.  The defaults are quite sane.

Speaking of highlighting: is there a way to highlight text in LyX (e.g.,
\hl{...} via soul) without ERT?  I can change its color, but not its
background...


> Every user interface provides certain default that can't be changed by the
> user because the user might not (and does not want to) consider all the
> consequences. However, I personally have no problem with having a
> preference for inverted cursor in general.


True, but I think that (a) the option is there in LyX already so it should
be preserved and (b) part of open source philosophy is freedom to choose
... which may extend down to cursor color.


> OSX is no application. ;) I know you mean LyX of course.
>

Aye.  I'm able and willing to work on all three major OSs, but choose OSX.
However, I very quickly install LyX and Vim no matter where I am if I will
be there for any length of time.

Re: [patch] support for Urdu

[Uwe Stöhr]

Am 23.10.2016 um 13:26 schrieb Jean-Marc Lasgouttes:


I do not see the code that make the LaTeX output work.


One does not need special LaTeX code, that is the advantage of 
LuaTeX/XeTeX with polyglossia. No more nasty hacks. If one tells 
polyglossia that the following text is in Urdu, LuaTeX and XeTeX will 
handle it correctly. I googled around a lot and it seems that people are 
happy with this.
As I understood it, ArabTeX was once invented in times of 8bit chars and 
its last release is therefore from 2004. Arabi was once created to 
handle Arabic script despite that LaTeX could not handle Unicode input. 
XeTeX and LuaTeX can handle Unicode input and I also found out that one 
can e.g. also use Korean via polyglossia and then also no special LaTeX 
commands are necessary. So as I understood it, with an Unicode-TeX 
engine one can use any language like a language using Latin script.
And yes, LyX uses this already. Look e.g. at Telugu: we support it for 
years, it has its own script system but we don't need any special LaTeX 
code.


Nevertheless I just sent a mail to the Urdu guy who once tested our Urdu 
support. I hope he could have a look.


> Why would we have

lots of hardcoded tests for arabic and friends but not urdu?? Did you
look at each of these tests as I advised and then decided that each of
them was unnecessary for Urdu?


No, since I did not know that we need special tests for the different 
languages. I can also not find these tests, where are they? Could you 
please what I should do with the Arabic tests for Urdu? That would be 
nice since I never used these tests yet.


thanks and regards
Uwe

Re: Inverted colors for cursor

[racoon]

On 23.10.2016 16:20, Joel Kulesza wrote:

On Sun, Oct 23, 2016 at 1:02 AM, racoon > wrote:

However, since there are clear benefits of an inverted cursor (think
about the poor person with red cursor who happens to land in an
inset that has a red background by default, like insets of modules
not available on her system), there should at least be an option in
the prefs then. If you are against making this optional I think the
only sensible default is an inverted cursor.

He or she brought this on themselves and must live with the
consequence.  Red may become blue when they've figured out their
mistake.  Or, they just don't use red backgrounds. Please be wary of
saving users from themselves with no recourse especially when sensible
defaults are provided.

I know no applications where you can set the cursor color.

Two immediately spring to mind: OSX Terminal & cross-platform Vim.


I guess these are very limited applications as to the changes that occur 
background color wise during usage.



Certainly, the users can get themselves into trouble when they change
highlighting to conflict with normal text entry and now things have
disappeared.  However, they've made it their own and no developer should
fault them for it.  If it doesn't work, they can change it to something
else.  Interestingly, a cottage industry as sprung up around providing
color schemes for terminal applications and Vim.


Every user interface provides certain default that can't be changed by 
the user because the user might not (and does not want to) consider all 
the consequences. However, I personally have no problem with having a 
preference for inverted cursor in general.



P.S. It's interesting that my two most relied-upon applications are
named with three letters.


OSX is no application. ;) I know you mean LyX of course.

Daniel

Re: Inverted colors for cursor

[Joel Kulesza]

On Sun, Oct 23, 2016 at 1:02 AM, racoon  wrote:

>
>> However, since there are clear benefits of an inverted cursor (think
> about the poor person with red cursor who happens to land in an inset that
> has a red background by default, like insets of modules not available on
> her system), there should at least be an option in the prefs then. If you
> are against making this optional I think the only sensible default is an
> inverted cursor.


He or she brought this on themselves and must live with the consequence.
Red may become blue when they've figured out their mistake.  Or, they just
don't use red backgrounds. Please be wary of saving users from themselves
with no recourse especially when sensible defaults are provided.


> I know no applications where you can set the cursor color.


Two immediately spring to mind: OSX Terminal & cross-platform Vim.

Certainly, the users can get themselves into trouble when they change
highlighting to conflict with normal text entry and now things have
disappeared.  However, they've made it their own and no developer should
fault them for it.  If it doesn't work, they can change it to something
else.  Interestingly, a cottage industry as sprung up around providing
color schemes for terminal applications and Vim.

- Joel

P.S. It's interesting that my two most relied-upon applications are named
with three letters.

Re: Inverted colors for cursor

[racoon]

On 23.10.2016 16:11, Joel Kulesza wrote:

On Sun, Oct 23, 2016 at 12:41 AM, racoon > wrote:

On 22.10.2016 20:35, Enrico Forestieri wrote:

On Sat, Oct 22, 2016 at 04:49:35PM +0200, Jean-Marc Lasgouttes
wrote:


As LyX stands now, it is often very difficult to put the
mouse cursor
between two insets, because insets, contrary to characters,
are active
beasts. If you click a bit to close to them, something
happens. This is why
some spacing has to be kept to some extent.


Actually, as LyX works at the moment, 2.2.2, it *im*possible to
click between two frames or buttons, e.g. two ERTs or two labels. So
the space doesn't really help there. This is partly due to a
"interaction area" translated to the right. But maybe that should be
changed.

Can't we make it such that clicks too near to boundaries are
ignored?


That seems sensible to me. Or if there is some space in between
insets then at least not have it as being part of the inset.


Again, I ask for caution here.  How does one delineate "too near"? I may
be missing something with this argument.  However, in an already narrow
situation, being forced to click almost the exact center will become a
greater challenge if some clickability is removed from near the elements
on the edge.


The idea of distinguishing between outer and inner inset offsets should 
help here. By keeping the inner offset large enough it seems possible to 
avoid a too "narrow situation".

Re: Inverted colors for cursor

[Joel Kulesza]

On Sun, Oct 23, 2016 at 12:41 AM, racoon  wrote:

> On 22.10.2016 20:35, Enrico Forestieri wrote:
>
>> On Sat, Oct 22, 2016 at 04:49:35PM +0200, Jean-Marc Lasgouttes wrote:
>>
>>>
>>> As LyX stands now, it is often very difficult to put the mouse cursor
>>> between two insets, because insets, contrary to characters, are active
>>> beasts. If you click a bit to close to them, something happens. This is
>>> why
>>> some spacing has to be kept to some extent.
>>>
>>
> Actually, as LyX works at the moment, 2.2.2, it *im*possible to click
> between two frames or buttons, e.g. two ERTs or two labels. So the space
> doesn't really help there. This is partly due to a "interaction area"
> translated to the right. But maybe that should be changed.
>
> Can't we make it such that clicks too near to boundaries are ignored?
>>
>
> That seems sensible to me. Or if there is some space in between insets
> then at least not have it as being part of the inset.
>

Again, I ask for caution here.  How does one delineate "too near"? I may be
missing something with this argument.  However, in an already narrow
situation, being forced to click almost the exact center will become a
greater challenge if some clickability is removed from near the elements on
the edge.

Re: [LyX/master] Do some caching of window title and related UI

[Guillaume Munch]

Le 23/10/2016 à 13:57, Jean-Marc Lasgouttes a écrit :

Le 23/10/2016 à 13:55, Guillaume Munch a écrit :

By the way, since we appreciate the value of static checks, it is
possible to use the new syntax for signal/slot connections, which allows
us to know during compilation that it is mistyped or that the signal or
the slot does not exist. When we are ready to drop qt4.


What does the new syntax look like?


https://wiki.qt.io/New_Signal_Slot_Syntax



I duly added a Q_EMIT in the above code.



Thank you

Re: [LyX/master] Do some caching of window title and related UI

[Jean-Marc Lasgouttes]

Le 23/10/2016 à 13:55, Guillaume Munch a écrit :

By the way, since we appreciate the value of static checks, it is
possible to use the new syntax for signal/slot connections, which allows
us to know during compilation that it is mistyped or that the signal or
the slot does not exist. When we are ready to drop qt4.


What does the new syntax look like?

I duly added a Q_EMIT in the above code.

JMarc

Re: [LyX/master] Do some caching of window title and related UI

[Guillaume Munch]

Le 23/10/2016 à 13:42, Guillaume Munch a écrit :

Le 23/10/2016 à 13:27, Jean-Marc Lasgouttes a écrit :

Le 22/10/2016 à 22:36, Guillaume Munch a écrit :

I know that this is not really followed in LyX currently but I suggest
to write "Q_EMIT titleChanged(this)" instead. This is meant to warn the
reader that something they do not expect can happen. (And similarly
whenever a signal is emitted.) The keyword is usually "emit" but Qt
keywords are disabled in LyX for some reason.


It should be Qt's job to enforce this.


Yes, so much more could and should be checked by the compilers!




By the way, since we appreciate the value of static checks, it is 
possible to use the new syntax for signal/slot connections, which allows 
us to know during compilation that it is mistyped or that the signal or 
the slot does not exist. When we are ready to drop qt4.

Re: [LyX/master] Do some caching of window title and related UI

[Guillaume Munch]

Le 23/10/2016 à 13:27, Jean-Marc Lasgouttes a écrit :

Le 22/10/2016 à 22:36, Guillaume Munch a écrit :

I know that this is not really followed in LyX currently but I suggest
to write "Q_EMIT titleChanged(this)" instead. This is meant to warn the
reader that something they do not expect can happen. (And similarly
whenever a signal is emitted.) The keyword is usually "emit" but Qt
keywords are disabled in LyX for some reason.


It should be Qt's job to enforce this.


Yes, so much more could and should be checked by the compilers!


I cannot look up each and every
method in frontends/qt4 to see whether it is a signal or not.


Neither can the reader. If you happen to know that it is a signal, it is
an appreciated effort of documentation.

Re: [LyX/master] Do some caching of window title and related UI

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 22:36, Guillaume Munch a écrit :

I know that this is not really followed in LyX currently but I suggest
to write "Q_EMIT titleChanged(this)" instead. This is meant to warn the
reader that something they do not expect can happen. (And similarly
whenever a signal is emitted.) The keyword is usually "emit" but Qt
keywords are disabled in LyX for some reason.


It should be Qt's job to enforce this. I cannot look up each and every 
method in frontends/qt4 to see whether it is a signal or not.


JMarc

Re: [patch] support for Urdu

[Jean-Marc Lasgouttes]

Le 23/10/2016 à 04:09, Uwe Stöhr a écrit :

Support for Urdu was once denied because of font problems. The
corresponding bug reported by an Urdu-speaking LyX user is fixed in LyX
2.2: http://www.lyx.org/trac/ticket/9066

Therefore I don't see a reason why LyX cannot support Urdu. Attached is
the patch and a LyX testfile to play with.


I do not see the code that make the LaTeX output work. Why would we have 
lots of hardcoded tests for arabic and friends but not urdu?? Did you 
look at each of these tests as I advised and then decided that each of 
them was unnecessary for Urdu?


JMarc

Re: [LyX/master] unicodesymbols fixes.

[Guillaume Munch]

Le 08/10/2016 à 16:59, Günter Milde a écrit :

commit efa844702c3844f5bb72ae3218ce175890a67db3
Author: Günter Milde 
Date:   Sat Oct 8 16:57:52 2016 +0200

unicodesymbols fixes.

force=utf8 is required for most characters provided by add-on packgages
and (almost) all mathematical characters, because these are not
set up for inputencs utf8

unicodesymbols.py failed here (python 2.7 under Linux) before the simple fix
included in this commit.




Hi,


This commit results in the following difference in doc/MathMath.lyx
after saving:

1942c1942
< \textrm{created with \textbf{\textbackslash frac}} &  & 
\textrm{created with \textbf{\textbackslash cfrac}}\\

---
> \textrm{created with \textbf{⧵frac}} &  & \textrm{created with 
\textbf{⧵cfrac}}\\

18774c18774
< \mathbf{\int_{n}^{2}f(\theta)=\Gamma}\qquad\textrm{equation with 
\textbackslash mathbf}

---
> \mathbf{\int_{n}^{2}f(\theta)=\Gamma}\qquad\textrm{equation with ⧵mathbf}
18792c18792
< \boldsymbol{\int_{n}^{2}f(\theta)=\Gamma\qquad\textrm{equation with 
\textbackslash boldsymbol}}

---
> \boldsymbol{\int_{n}^{2}f(\theta)=\Gamma\qquad\textrm{equation with 
⧵boldsymbol}}



At first I thought of a bug but if you look closely, \textbackslash is
not replaced by \ but by ⧵ (U+29F5 REVERSE SOLIDUS OPERATOR).

Is this change expected? Is it correct? It seems to result in incorrect
behaviour to me:
* when activating Use non-TeX fonts, it gets output as U+29F5 whereas
U+5C is meant.
* in normal text, \textbackslash remains unchanged by your patch, but
when doing copy-paste from the above formulae to normal text, one gets
U+29F5 (thought it is hidden until one enables Use non-TeX fonts).

Also, and more importantly, this shows that some changes to
lib/[unicode]symbols are in fact file format changes. Is it expected in
this case? Is it easy to see which kind of changes to these files are
file-format-changing and which ones are not?


Thank you,
Guillaume

Re: Supposed to be bolded page number not bolded in index

[Jürgen Spitzmüller]

Am Sonntag, den 23.10.2016, 08:42 +0200 schrieb Jürgen Spitzmüller:
> Since we now have PassThruChars, it would be easy to treat the
> special
> characters in index entries literally (see attached patch).
> 
> This would restore what many people seem to be accustomed to and
> expect, to the extend of the (probably few) users that really want a
> |
> character in the index.

I have to add that the behavior is internally inconsistent at the
moment. In order to get a literal ! or @, you have to escape those
characters ("! and "@, respectively), only the | shows the opposite
behavior. So I think the patch would increase internal consistency. On
the other hand, it might further decrease external consistency, since
normally, ERT is to be used to get verbatim output.

In the long term, I think the ideal solution would be that all of these
special characters are escaped by default (so @, | and ! really output
these glyphs), and that the functions they provide in indexes (sort
key, indexical hierarchy, page number formatting) are natively
implemented via sub-insets. But this requires major UI work and lyx2lyx
 conversion/reversion.

So, for the time being, I would apply the patch.

Jürgen

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

Re: [LyX/master] Fix Ticket #9741 misleading name for font-encoding setting "default".

[Guenter Milde]

On 2016-10-22, Guenter Milde wrote:
> On 2016-10-22, Enrico Forestieri wrote:
>> On Sat, Oct 22, 2016 at 05:16:49PM +0200, Jean-Marc Lasgouttes wrote:

>>> How bad can it become for someone who has changed the [lyrc.fontenc]
>>> setting?

...

>> However, more damage can result if one selected T2A as a default
>> and the default setting is converted to T1 due to lack of that info.

> This will normally not hurt, as LyX automatically adds T2A font encoding for
> Cyrillic characters. 

> The only (hypothetical) instance would be the selection in the
> user preamble of a font that only exists in T2A encoding in documents with
> parts in a Latin-written language.

However, problems may arise for the rare case of a user preferring/requiring
a non-standard font encoding like LY1.

Günter

LyX unstable

[Guillaume Munch]

Dear list,

As announced previously in a message that was probably missed
(),
and after discussions, I have created a branch, kept in sync with
master, which reads and writes the stable format, together with a
documentation of the workflow for maintaining such a branch. I would
like to push it to the main repository on an experimental basis.

This branch is meant to open testing of master features to a wider
audience, either because compatibility with the stable format is
required, or because it is found safer to constantly have stable as a
fallback. It is also meant as an experiment to prove that it is possible
and even easy to maintain such a branch. A second step will be to create
an Ubuntu PPA for it to increase its audience.

Using it daily allowed me in several occasions to find bugs in master,
and also in several occasions we have noticed that feedback on a new
feature came very late, after much effort was already spent on it. I
hope this branch will help with the situation.

Sincerely,
Guillaume

Modules dialogue

[Andrew Parsloe]

In an earlier email I managed to overlook the Assumption environment, 
provided in the Theorems-AMS-Extended module, as Paul indicated. OK, 
more of this kind of thing is to be expected as I enter my dotage, but 
when I view the modules dialogue it looks as if it has outgrown its 
current arrangement. Have a look at the Theorems modules in the 
Available window. The window isn't wide enough for many of these 
(particularly AMS-Extended) to show the relevant part on the right of 
each entry which distinguishes one from another without using the slider.


Few documents have more than a module or five attached to them. Most of 
the Selected window is wasted space. I wonder if the two Defaults 
buttons in the penultimate row couldn't be shrunk to fit into the gap in 
the bottom row. The Selected window could then be moved below the 
description window (and expanded horizontally), the Add/Delete buttons 
moved to the right in the space now available, and the Up/Down buttons 
brought down beside and to the right of the newly sited Selected window. 
The space freed by moving the buttons could now be used to expand the 
Available window horizontally. That would allow the names of modules 
with long ones, like "Theorems (AMS-Extended, Numbered by Type)" to be 
read at a glance.


(In fact I want "Theorems (AMS-Extended, Numbered by Type within 
Chapters)", an even longer title, but LyX doesn't provide this out of 
the box, although it is easy to create using those provided as models.)


Andrew

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

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 16:49, Jean-Marc Lasgouttes wrote:

Le 22/10/2016 à 14:53, racoon a écrit :

On 22.10.2016 14:38, Joel Kulesza wrote:

With the ability to tweak the cursor color, I agree with Daniel's
suggestion to implement the inverted color patch.


Sorry, I did not make myself clear before. I am suggesting to not let
the user choose the cursor color but instead enforce inverted color. I
think an inverted cursor has the benefit of being visible in any
situation while the downsides seem small. I think most people are either
working with a very light or very dark background. In that case the
cursor would be almost black or almost white, respectively. I think that
is the setting most people use anyway.


As someone who has written his fair share of sentences containing the
words "most people", I can tell you this: this is wrong. There are
people who have set their cursor to bright red for the whole OS and will
complain if LyX does not do that (I do not know them, but I am sure that
they exist). There are people who have some strange color layout that
makes no sense to you and would not be happy with your inverted cursor.


However, since there are clear benefits of an inverted cursor (think 
about the poor person with red cursor who happens to land in an inset 
that has a red background by default, like insets of modules not 
available on her system), there should at least be an option in the 
prefs then. If you are against making this optional I think the only 
sensible default is an inverted cursor.



I would not say that this is a well-known UI paradigm, and there are
probably reasons for that...


I know no applications where you can set the cursor color. There are 
some that don't have an inverted cursor. Like Mozilla Thunderbird which 
I am just writing in this email. However, this is a bad decision on 
their side since someone might want to write their emails in html format 
and set the background color to black. Then the fun is over.



As LyX stands now, it is often very difficult to put the mouse cursor
between two insets, because insets, contrary to characters, are active
beasts. If you click a bit to close to them, something happens. This is
why some spacing has to be kept to some extent.


It is actually already now impossible due to the extra space around 
insets that are counted as interactive area of insets (see my answer to 
Enrico).


Daniel

Re: [LyX/master] Fix Ticket #9741 misleading name for font-encoding setting "default".

[Jürgen Spitzmüller]

Am Samstag, den 22.10.2016, 18:02 + schrieb Guenter Milde:
> > The first option (which should be the default, IMHO) uses whatever
> font
> > encoding is considered appropriate for the given language(s) and
> > backend. We determine that via the fontenc option in languages.
>   
>   Please also take into account the font setting itself: [Default]
> should
>   trigger OT1 and (for languages expecting something different) a
> warning
>   unless we know the class selects an appropriate font.

You probably mean [Automatic] here.

We can implement whatever is considered necessary in that routine. This
is analoguous to the "Automatic" babel/polyglossia thing we already
have.

In the meantime, could you please revert your original change? I think
it is clear that we will change the strings, but differently.

Jürgen

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

Re: Supposed to be bolded page number not bolded in index

[Jürgen Spitzmüller]

Am Samstag, den 22.10.2016, 08:53 +0200 schrieb Jürgen Spitzmüller:
> Am Freitag, den 21.10.2016, 16:15 -0700 schrieb Richard Opheim:
> > Whoa. I'm supposed to be able to put |textbf at the end of an index
> > entry tag and get a bolded page number in the index. At least it
> > worked in the pre-2 versions of LyX. Now that I've upgraded to
> > 2.2.2,
> > it doesn't work any more. (See attached file).
> > Windows 10, Memoir class doc.
> 
> Put the "|" in a TeX Mode inset (aka ERT). This prevents it from
> being
> tranformed into a LaTeX macro (\textbar) on output (which is
> necessary
> to get the bar symbol in some font encodings).

Since we now have PassThruChars, it would be easy to treat the special
characters in index entries literally (see attached patch).

This would restore what many people seem to be accustomed to and
expect, to the extend of the (probably few) users that really want a |
character in the index.

What do you think?

Jürgen

> Jürgendiff --git a/lib/layouts/stdinsets.inc b/lib/layouts/stdinsets.inc
index fb74215..af5bc16 100644
--- a/lib/layouts/stdinsets.inc
+++ b/lib/layouts/stdinsets.inc
@@ -354,6 +354,7 @@ InsetLayout Index
 	CustomParsfalse
 	ForcePlaintrue
 	ContentAsLabeltrue
+	PassThruChars @|!
 End
 
 InsetLayout Box


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

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 20:35, Enrico Forestieri wrote:

On Sat, Oct 22, 2016 at 04:49:35PM +0200, Jean-Marc Lasgouttes wrote:


As LyX stands now, it is often very difficult to put the mouse cursor
between two insets, because insets, contrary to characters, are active
beasts. If you click a bit to close to them, something happens. This is why
some spacing has to be kept to some extent.


Actually, as LyX works at the moment, 2.2.2, it *im*possible to click 
between two frames or buttons, e.g. two ERTs or two labels. So the space 
doesn't really help there. This is partly due to a "interaction area" 
translated to the right. But maybe that should be changed.



Can't we make it such that clicks too near to boundaries are ignored?


That seems sensible to me. Or if there is some space in between insets 
then at least not have it as being part of the inset.


Daniel

Re: Candidates for stable

[Jürgen Spitzmüller]

Am Samstag, den 22.10.2016, 13:35 -0400 schrieb Richard Heck:
> OK, looks safe enough.

Thanks, all done now.

Jürgen

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