Re: [LyX/master] Allow toggling (no)limits only after mathop symbol

2018-09-20 Thread Jean-Marc Lasgouttes

Le 03/09/2018 à 18:01, Jean-Marc Lasgouttes a écrit :

commit 7b7ed64a0e760eccad5fff7fa944b983d0bed025
Author: Jean-Marc Lasgouttes 
Date:   Mon Sep 3 17:49:54 2018 +0200

 Allow toggling (no)limits only after mathop symbol
 
 In particular, introduce the new InsetMathScript::allowLimits method

 that checks for that and honor it in getStatus/ddoDispatch.


Riki,

Can I backport this (along with the fixup at 6cfd733dea70b)?

JMarc


---
  src/mathed/InsetMathScript.cpp |   42 ++-
  src/mathed/InsetMathScript.h   |2 +
  2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/src/mathed/InsetMathScript.cpp b/src/mathed/InsetMathScript.cpp
index 8c6416a..2f66b0f 100644
--- a/src/mathed/InsetMathScript.cpp
+++ b/src/mathed/InsetMathScript.cpp
@@ -365,6 +365,20 @@ void InsetMathScript::drawT(TextPainter & pain, int x, int 
y) const
  }
  
  
+// FIXME: See InsetMathSymbol::takesLimits, which seems to attempt the

+// same in a hardcoded way. takeLimits use is currently commented out in
+// InsetMathScript::metrics. It seems that the mathop test is general
+// enough, but only time will tell.
+bool InsetMathScript::allowsLimits() const
+{
+   if (nuc().empty())
+   return false;
+   // Only makes sense for insets of mathop class
+   if (nuc().back()->mathClass() != MC_OP)
+   return false;
+   return true;
+}
+
  
  bool InsetMathScript::hasLimits() const

  {
@@ -375,8 +389,9 @@ bool InsetMathScript::hasLimits() const
return false;
  
  	// we can only display limits if the nucleus wants some

-   if (nuc().empty())
+   if (!allowsLimits())
return false;
+   // FIXME: this is some hardcoding done in InsetMathSymbol::metrics.
if (!nuc().back()->isScriptable())
return false;
  
@@ -735,6 +750,9 @@ void InsetMathScript::doDispatch(Cursor & cur, FuncRequest & cmd)

//LYXERR("InsetMathScript: request: " << cmd);
  
  	if (cmd.action() == LFUN_MATH_LIMITS) {

+   // only when nucleus allows this
+   if (!allowsLimits())
+   return;
cur.recordUndoInset();
if (!cmd.argument().empty()) {
if (cmd.argument() == "limits")
@@ -758,15 +776,19 @@ bool InsetMathScript::getStatus(Cursor & cur, FuncRequest 
const & cmd,
FuncStatus & flag) const
  {
if (cmd.action() == LFUN_MATH_LIMITS) {
-   if (!cmd.argument().empty()) {
-   if (cmd.argument() == "limits")
-   flag.setOnOff(limits_ == 1);
-   else if (cmd.argument() == "nolimits")
-   flag.setOnOff(limits_ == -1);
-   else
-   flag.setOnOff(limits_ == 0);
-   }
-   flag.setEnabled(true);
+   // only when nucleus allows this
+   if (allowsLimits()) {
+   if (!cmd.argument().empty()) {
+   if (cmd.argument() == "limits")
+   flag.setOnOff(limits_ == 1);
+   else if (cmd.argument() == "nolimits")
+   flag.setOnOff(limits_ == -1);
+   else
+   flag.setOnOff(limits_ == 0);
+   }
+   flag.setEnabled(true);
+   } else
+   flag.setEnabled(false);
return true;
}
  
diff --git a/src/mathed/InsetMathScript.h b/src/mathed/InsetMathScript.h

index c1589b1..d29ffbd 100644
--- a/src/mathed/InsetMathScript.h
+++ b/src/mathed/InsetMathScript.h
@@ -138,6 +138,8 @@ private:
/// shifts the superscript to the right, and a negative value shifts the
/// subscript to the left.
int nker(BufferView const * bv) const;
+   /// can one change how scripts are drawn?
+   bool allowsLimits() const;
/// where do we have to draw the scripts?
bool hasLimits() const;
/// clean up empty cells and return true if a cell has been deleted.





Re: LyX SVG output size wrong

2018-09-20 Thread Jean-Marc Lasgouttes

Le 20/09/2018 à 14:24, Daniel a écrit :
I just tried a conversion via Inkscape which works fine. Maybe there is 
a way to replace the conversion via rsvg-convert with Inkscape?


Inkscape is used when rsvg-convert is not available. Otherwise, you can 
change it by hand in your preferences.


JMarc


Re: LyX SVG output size wrong

2018-09-20 Thread Jean-Marc Lasgouttes

Le 20/09/2018 à 14:23, Daniel a écrit :

On 20/09/2018 14:00, Jean-Marc Lasgouttes wrote:

Le 20/09/2018 à 13:43, Daniel a écrit :

No idea what my converter is. How do I find out?


I just tried out online SVG to PNG converters. With Imagick the 
result was fine. However, with another tool that (like...) used rsvg 
the result was the same as in LyX. So maybe rsvg does not handle 
them correctly or needs some argument or so?


To find what your svg converter is, go In Tools>Preferences>File 
Handling>Converters, and look at the converters from svg to something 
else.


It's rsvg-convert then.


If you can get the rsvg-convert people to tell us how we are supposed to 
handle images, there may be things we can do.


JMarc


Re: Newline can cause text before to shift upward

2018-09-20 Thread Jean-Marc Lasgouttes

Le 08/09/2018 à 00:38, Scott Kostyshak a écrit :

In some cases, when I break a line, the text to the left of the break is
shifted upwards. See the attached screenshots. In case it is difficult
to see how "abc" changes from flipping back and forth in your image
viewer, you can run the following command:

   compare -compose difference 1of2_before_jump.png 2of2_after_jump.png diff.png

Would it be a valid feature request to not have the upward shift of
"abc" in this situation, or is the "jump" actually desired? If it would
be a valid feature request, I would not expect this issue to be high
priority.


I tried briefly and cannot reproduce. I cannot tell where this comes 
from, unfortunately.


JMarc


Re: Indentation bars not adjusted to limited text width

2018-09-20 Thread Jean-Marc Lasgouttes

Le 15/09/2018 à 07:54, Daniel a écrit :
Others wondered as well and even created patches. I never came around 
doing the final changes you suggested though.


https://www.lyx.org/trac/ticket/9376


Indeed, I forgot about it... :( I will not have time to work on that though.

JMarc



Re: LyX SVG output size wrong

2018-09-20 Thread Jean-Marc Lasgouttes

Le 20/09/2018 à 13:43, Daniel a écrit :

No idea what my converter is. How do I find out?


I just tried out online SVG to PNG converters. With Imagick the result 
was fine. However, with another tool that (like...) used rsvg the 
result was the same as in LyX. So maybe rsvg does not handle them 
correctly or needs some argument or so?


To find what your svg converter is, go In Tools>Preferences>File 
Handling>Converters, and look at the converters from svg to something else.


This report from 2016 seems to point to a rsvg bug:
http://www.imagemagick.org/discourse-server/viewtopic.php?t=30591

JMarc


Re: LyX SVG output size wrong

2018-09-20 Thread Jean-Marc Lasgouttes

Le 20/09/2018 à 13:14, Daniel a écrit :

On 20/09/2018 10:58, Jean-Marc Lasgouttes wrote:

Le 20/09/2018 à 10:21, Daniel a écrit :
This leads to the middle and right text in the attached file having 
different sizes in LyX while they have the same size in other 
applications I tested.


It looks like we do not pass any information to the svg converter 
concerning dpi.


A few questions:

* what is you dpi setting in LyX?


I couldn't find a setting for this in LyX.


* what is your zoom setting in LyX?


120%.

But both of these question concern just the representation within LyX 
and not in the output which I was mainly concerned about.


Very good point. I did not get that initially.

I think that at this point it would be a good idea to open a ticket. 
Unfortunately, I am not sure we will be able to do something about it.


JMarc


Re: Two small mathed quibbles.

2018-09-20 Thread Jean-Marc Lasgouttes

Le 18/09/2018 à 12:49, Andrew Parsloe a écrit :

Could you show a screenshot? I do not see it.
I've attached screenshots (15.6" Acer laptop screen). To the left a T 
with a prime (a single quote mark '), to the right a T without a prime, 
separated by \quad, at 150% and 200% zoom.


I see it on windows, but not on linux (with TImes New Roman). I am not 
sure how to debug this. It could be a Qt issue, or it could be our tfault.


Is it more delicate because the cursor is too small to be seen? What 
kind of setup do your have? What would you suggest to do?
On reflection I don't think this is worth worrying about. The cursor 
keys are always available.


And also Ctrl+a to select a cell (can be repeated to grow the selection).

JMarc


Re: Format 63

2018-09-20 Thread Jean-Marc Lasgouttes

Le 20/09/2018 à 08:17, Andrew Parsloe a écrit :
I have studiously avoided git to date. I pondered the matter for a 
couple of days then bravely set forth, following the instructions at 
https://www.lyx.org/HowToUseGIT, section 4, to create a clone of the lyx 
repository on my computer, and then section 7 on changing the source.


Congratulations!

JMarc


Re: LyX SVG output size wrong

2018-09-20 Thread Jean-Marc Lasgouttes

Le 20/09/2018 à 10:21, Daniel a écrit :

Inkscape/Libre/Firefox: 1pt = 1.333px = 1.333


This corresponds to a setting of 96dpi. But obviously the number of 
pixels depends on your zoom setting in firefox/libreoffice..., doesn't it?



LyX: 1pt = 1px = 1


This leads to the middle and right text in the attached file having 
different sizes in LyX while they have the same size in other 
applications I tested.


It looks like we do not pass any information to the svg converter 
concerning dpi.


A few questions:

* what is you dpi setting in LyX?

* what is your zoom setting in LyX?

* what is your svg->* converter?

I see here the same as what you describe. My system does not have 
rsvg-convert installed, so conversion is done by inkscape to EPS (why 
EPS? No idea).


JMarc



Re: LyX SVG output size wrong

2018-09-19 Thread Jean-Marc Lasgouttes

Le 19/09/2018 à 23:54, Daniel a écrit :
The link you gave assumes that everything is displayed at 90dpi (which 
gives the 1.25 once you know that 1pt is 1/72th of inch).


I have no idea of how computations are done for svg images : external 
program rsvg, qt, inkscape...


But what matters is that the output is accurate, or not? The SVG spec 
sets 1px = 1pt independent of the resolution. Then it's the job of the 
program, like LyX (or whatever LyX is using to output SVG) to output it 
correctly. And this is not done correctly.


You mean 1.25px, right? I do not say I am giving a solution. I am 
thinking aloud. I do not even know what code (is it ours?) is to blame.


JMarc


Re: LyX SVG output size wrong

2018-09-19 Thread Jean-Marc Lasgouttes

Le 19/09/2018 à 22:45, Daniel a écrit :

"1pt" equals "1.25px" (and therefore 1.25 user units)

https://www.w3.org/TR/SVG11/coords.html#Units

The basic problem is that LyX treats 1 svg pixel as 1pt rather than 0.8pt.


The link you gave assumes that everything is displayed at 90dpi (which 
gives the 1.25 once you know that 1pt is 1/72th of inch).


I have no idea of how computations are done for svg images : external 
program rsvg, qt, inkscape...


JMarc



Re: Non-native dialog

2018-09-18 Thread Jean-Marc Lasgouttes

Le 18/09/2018 à 15:06, Daniel a écrit :

On 18/09/2018 08:45, Jean-Marc Lasgouttes wrote:

Le 17/09/2018 à 19:34, Jürgen Spitzmüller a écrit :

I wonder if a better solution is a widget that collects (and maybe
categorizes) files from given paths and let you click on it. Like
LibreOffice has it (see attachment, although LyX's definitely would
look different). This would open fro the menu if you click on "New from
Template..." or "Open Example file...".


We could definitely use a combox for ui elements (bind files, ui 
files, keyboard...).


I thought the widget is for interaction with LyX and its .lyx files, 
i.e. open, save, etc.


It is for selecting files in general. And we use it in Preferences.

JMarc


Re: Two small mathed quibbles.

2018-09-18 Thread Jean-Marc Lasgouttes

Le 04/09/2018 à 02:02, Andrew Parsloe a écrit :

Working with mathed in 2.3.1, I've noted a couple of small items.

1. Some primes need more space. Lowercase: t', d'; uppercase T', E', F'. 
(T' is the worst.) This is using the default Times New Roman at 150% zoom.


Could you show a screenshot? I do not see it.

2. It seems much harder now to select a subscript with the mouse in an 
inline formula without selecting the symbol it is attached to, e.g. 
selecting 'i' with the mouse in $f_{i}$, particularly when there is 
another line of text in the same paragraph below the formula. This was 
always a bit fiddly but seems to be considerably more delicate now.


Is it more delicate because the cursor is too small to be seen? What 
kind of setup do your have? What would you suggest to do?


JMarc


Re: [LyX/master] needauth is not needed for Sweave>LyX

2018-09-18 Thread Jean-Marc Lasgouttes

Le 12/09/2018 à 17:35, Richard Kimberly Heck a écrit :

On 09/12/2018 09:28 AM, Jean-Marc Lasgouttes wrote:

Le 12/09/2018 à 15:22, Jean-Marc Lasgouttes a écrit :

commit 23dbacb636c2ac616967669ec038ab0d5c8b9dd3
Author: Jean-Marc Lasgouttes 
Date:   Wed Sep 12 15:14:56 2018 +0200

  needauth is not needed for Sweave>LyX
   Indeed this relies on tex2lyx and does not run R scripts.
   The same holds for Knitr>LyX


Riki, this is candidate for 2.3.2. Unless of course I got something
wrong.


Your call. I do not use Sweave, etc, so am ignorant about this.


Thanks, I backported it.

JMarc



Re: [LyX/master] Use symbols file to lookup entities for delimiters. Fixes bug #8280.

2018-09-18 Thread Jean-Marc Lasgouttes

Le 14/09/2018 à 02:53, Scott Kostyshak a écrit :

On Mon, Jun 11, 2018 at 10:52:07AM +0200, Jean-Marc Lasgouttes wrote:

Le 09/06/2018 à 05:16, Scott Kostyshak a écrit :

If I open Math.lyx, select all, and copy, I get the following messages:

mathed/MathStream.cpp (715): Unable to find `\{' in the mathWordList.
mathed/MathStream.cpp (715): Unable to find `\}' in the mathWordList.

I can reproduce to soon after this commit, so I'm guessing it has always
been here.

Any ideas how to fix it?


I looks like the beginning of the function catters for ()<>[], but not \{\}.


The beginning of convertDelimToXMLEscape()? I only see a special case
for '<' and '>'.


Indeed. I do not know anymore what I referred to...

JMarc


Re: Non-native dialog

2018-09-18 Thread Jean-Marc Lasgouttes

Le 17/09/2018 à 19:34, Jürgen Spitzmüller a écrit :

I wonder if a better solution is a widget that collects (and maybe
categorizes) files from given paths and let you click on it. Like
LibreOffice has it (see attachment, although LyX's definitely would
look different). This would open fro the menu if you click on "New from
Template..." or "Open Example file...".


We could definitely use a combox for ui elements (bind files, ui files, 
keyboard...).


JMarc


Re: Cycle for some insets in InsetMathNest::idxNext ?

2018-09-17 Thread Jean-Marc Lasgouttes

Le 16/09/2018 à 07:33, Kornel Benko a écrit :

Am Samstag, 15. September 2018 21:45:33 CEST schrieb Scott Kostyshak 
:

Consider the attached .lyx file. When navigating to the cells of the
\overset and \stackrel, I would prefer for "tab-navigation" to cycle.

The attached patch does that, but I imagine that in other situations, we
do not want to cycle in this part of the code. If there is interest in
cycling in some situations and not in others, we could think of adding a
bool.

Any thoughts?


I like (but I have not tried it yet) the idea of cycling. I think that 
if we change the behavior, it should be the same for all insets.


I experimented with libreoffice and MS Word, and both inset a new line 
when using 'tab' in the last cell of a table. This is also an 
interesting idea. We could use either that or cycling depending on insets.


JMarc


Re: [ANNOUNCE] LyX 2.3.1 Released

2018-09-16 Thread Jean-Marc Lasgouttes

Le 16/09/2018 à 17:40, Richard Kimberly Heck a écrit :

Public release of LyX version 2.3.1
===

We are proud to announce the release of LyX 2.3.1. This is the first
maintenance release in the 2.3.x series.


I have to thank you for all the hard work you put in actually get this 
release out.


JMarc


Re: Cycle for some insets in InsetMathNest::idxNext ?

2018-09-16 Thread Jean-Marc Lasgouttes

Le 16/09/2018 à 21:07, Scott Kostyshak a écrit :

* Enter the inset -> cursor is between '$' and 'X_{n}'
* [Tab] -> cursor is between 'X_{n}' and '\stackrel[2]{1}{\rightarrow}'
* [Tab] -> cursor is between '\stackrel[2]{1}{\rightarrow}' and 'a'
* [Tab] -> cursor is between  'a' and '$'
* [Tab] -> cursor is between '$' and 'X_{n}'

But that is another issue.


Makes sense.


Actually not, because Tab moves from cell to cell, not inside a cell. 
What you are looking for is bound to Ctrl-Left/Right, if I am not mistaken.


But the bug is that Tab should do nothing when there is only one cell in 
the inset. I will fix that.


JMarc



Re: Indentation bars not adjusted to limited text width

2018-09-14 Thread Jean-Marc Lasgouttes

Le 14/09/2018 à 14:25, Kornel Benko a écrit :

Am Freitag, 14. September 2018 13:52:19 CEST schrieb Jean-Marc Lasgouttes 
:

Le 14/09/2018 à 13:50, Kornel Benko a écrit :

I don't see any effect, lyx behaves the same independent of the setting. What 
exactly should I see?


In full screen mode, when the width of text is limited, the depth-bars
are now drawn close to the text and not in the left of the margin.

JMarc


Ah, OK. Never used this mode.


Me neither. Actually I wonder why this functionality is limited to 
full-screen mode.


JMarc



Re: Freeze of LyX when pressing

2018-09-14 Thread Jean-Marc Lasgouttes

Le 14/09/2018 à 14:11, Daniel a écrit :
When viewing one of my complexer documents, LyX freezes for a couple of 
seconds before starting the typesetting process. Did anyone else notice 
that? I do not remember having that issue before.


I could try to come up with a minimal example if the problem didn't come 
up before.


I do not know about that. An example would be nice.

JMarc



Re: Indentation bars not adjusted to limited text width

2018-09-14 Thread Jean-Marc Lasgouttes

Le 14/09/2018 à 13:50, Kornel Benko a écrit :

I don't see any effect, lyx behaves the same independent of the setting. What 
exactly should I see?


In full screen mode, when the width of text is limited, the depth-bars 
are now drawn close to the text and not in the left of the margin.


JMarc


Re: Change in character thickness when selecting

2018-09-12 Thread Jean-Marc Lasgouttes

Le 12/09/2018 à 17:57, Daniel a écrit :
I seem to remember that a change in character thickness when selecting 
used to be a more widespread problem in LyX. As far as I can it is 
almost entirely gone. The only case I just stumbled upon was when a 
background color, for example mathbg, is set to "transparent".


This might happen indeed... But does this transparent color do something 
useful? I do not think that we handle it.


JMarc



Re: Change layout on paste only when the whole paragraph is copied

2018-09-12 Thread Jean-Marc Lasgouttes

Le 12/09/2018 à 16:01, Daniel a écrit :
I am not so sure about the original paragraph becoming default layout. 
I guess it is not uncommon to replace the content of a paragraph by 
something else while cutting its content before the replacement. 
(Libre office, for example, does not set the paragraph to default 
either.)


Furthermore, I guess the only difference between delete and cut should 
be that the latter moves stuff into the clipboard. At least that is how 
it works in my experience.


In some sense, the semantics of your original proposal is "selecting the 
whole paragraph selects the layout too". In this sense, the layout could 
be deleted with Delete too.


I understand this might be too much or inconvenient at times, but we 
should definitely not go towards complicated semantics that are supposed 
to do the right thing according to what we believe the user is doing. I 
really dislike when I have to fight against office 2010 "guessing" what 
I am wanting to do.


My point is that I would prefer to have a semantics of what happens that 
can be explained on one sentence rather than many ad-hoc behaviors. It 
is like the code that removes leading spaces of paragraphs of #10503. 
Somebody probably had a use case in mind when implementing what seems so 
stupid to us today.


JMarc


Re: Change layout on paste only when the whole paragraph is copied

2018-09-12 Thread Jean-Marc Lasgouttes

Le 12/09/2018 à 10:48, Kornel Benko a écrit :

The question is, do you want to copy the layout too, or not.
And what about other char features, like serif, bold, italic?
I for one prefer to copy also all possible information.


I think that explicit font change should be copied. But it makes sense 
that layout information is not relevant for a short part of a paragraph.


JMarc


Re: Change layout on paste only when the whole paragraph is copied

2018-09-12 Thread Jean-Marc Lasgouttes

Le 12/09/2018 à 10:33, Daniel a écrit :
I understand that LyX needs some way to copy layouts from one place to 
another. However, I suggest that the layout is changed only if the whole 
paragraph is copied, i.e. only if I would copy "I am number one".


Note also that my suggestion is how Libre Writer works. And there is yet 
a further difference: it changes the layout only if the current layout 
is standard. I am not as sure about the latter feature but it might be 
worth changing this as well.


I would agree with both conditions actually (full paragraph and only for 
standard layout)


Note however that ms office does it a bit differently:
* the change only happens if the invisible character at the end of the 
paragraph is selected It is actually a bit difficult to select the whole 
paragraph without this element, due to I-am-smarter-than-you-are 
selection behavior.


* the change also happens when receiving paragraph layout is not standard

I think I prefer the libreoffice behavior, but I am not sure.

Finally, this should also probably be coupled with doing the right thing 
when putting a note around a paragraph: the layout should kep copied to 
the receiving paragraph, but also removed from the original paragraph.


Therefore I propose that in the case of a Cut operation, the layout is 
_moved_ to the new paragraph and the original one becomes default layout.


JMarc


Re: Indentation bars not adjusted to limited text width

2018-09-11 Thread Jean-Marc Lasgouttes

Le 11/09/2018 à 16:05, Scott Kostyshak a écrit :

On Tue, Sep 11, 2018 at 10:28:14AM +0200, Jean-Marc Lasgouttes wrote:

Le 10/09/2018 à 10:40, Daniel a écrit :

When setting Preferences > Editing > Control > Limited text width, the
indentation bars are not adjusted to the new text width but stay at the
left border of the work area. Is that a bug or a feature? I tend to
think its a bug because it makes it harder to see where a bar belongs
to.


Please file a bug and assign it to me.


For archive purposes, the bug was opened here:

   https://www.lyx.org/trac/ticket/11286


I committed a fix to master. Please try it and tell me whether I broke 
something. This is a real possibility since this code is a bit 
mysterious to me.


JMarc


Re: Indentation bars not adjusted to limited text width

2018-09-11 Thread Jean-Marc Lasgouttes

Le 10/09/2018 à 10:40, Daniel a écrit :
When setting Preferences > Editing > Control > Limited text width, the 
indentation bars are not adjusted to the new text width but stay at the 
left border of the work area. Is that a bug or a feature? I tend to 
think its a bug because it makes it harder to see where a bar belongs to.


Please file a bug and assign it to me.

JMarc



Re: [LyX/master] Aesthetics: off-by-one in line drawing

2018-09-11 Thread Jean-Marc Lasgouttes

Le 11/09/2018 à 02:48, Scott Kostyshak a écrit :

Scott, would you say it is worth backporting?


I would say only if we want testing (I use the 2.3.x branch the most).


So we do not really care, right? Let's skip it, then.

JMarc



Re: [LyX/master] Aesthetics: off-by-one in line drawing

2018-09-10 Thread Jean-Marc Lasgouttes

Le 23/07/2018 à 17:19, Jean-Marc Lasgouttes a écrit :

commit ad954a32a525828bd03bf2c8241252e60394cbc3
Author: Jean-Marc Lasgouttes 
Date:   Mon Jul 23 17:07:48 2018 +0200

 Aesthetics: off-by-one in line drawing
 
 It is a general problem when doing graphics to know where a line

 begins and where it ends pixel-wise. At the instigation of Scott, and
 with the use of the kmag magnifier, this commit corrects 3 areas:
 
 * foreign marks were larger than the row element they were supposed to

   mark. This could lead to moving lines, depending on paint ordering.
 
 * visible spaces were drawn outside of their box (select a single

   space to see this).
 
 * the `L' blinking caret would leave a cursor dropping because the

   horizontal part was too wide.


Scott, would you say it is worth backporting?

JMarc


---
  src/RowPainter.cpp|2 +-
  src/frontends/qt4/GuiWorkArea.cpp |4 ++--
  src/insets/InsetSpace.cpp |   12 ++--
  3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/RowPainter.cpp b/src/RowPainter.cpp
index 16b144e..efc4021 100644
--- a/src/RowPainter.cpp
+++ b/src/RowPainter.cpp
@@ -159,7 +159,7 @@ void RowPainter::paintForeignMark(Row::Element const & e) 
const
int const desc = e.inset ? e.dim.descent() : 0;
int const y = yo_ + min(3 * pi_.base.solidLineOffset() / 2 + desc,
row_.descent() - 1);
-   pi_.pain.line(int(x_), y, int(x_ + e.full_width()), y, Color_language,
+   pi_.pain.line(int(x_), y, int(x_ + e.full_width() - 1), y, 
Color_language,
  Painter::line_solid, pi_.base.solidLineThickness());
  }
  
diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp

index e6d993c..45c4469 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -150,9 +150,9 @@ public:
painter.setPen(color_);
if (l_shape_) {
if (rtl_)
-   painter.drawLine(x_, bot, x_ - l, bot);
+   painter.drawLine(x_, bot, x_ - l + 1, bot);
else
-   painter.drawLine(x_, bot, x_ + caret_width_ + 
r, bot);
+   painter.drawLine(x_, bot, x_ + caret_width_ + r 
- 1, bot);
}
  
  		// draw completion triangle

diff --git a/src/insets/InsetSpace.cpp b/src/insets/InsetSpace.cpp
index fd8c261..ddb85b7 100644
--- a/src/insets/InsetSpace.cpp
+++ b/src/insets/InsetSpace.cpp
@@ -355,18 +355,18 @@ void InsetSpace::draw(PainterInfo & pi, int x, int y) 
const
int const h = theFontMetrics(pi.base.font).xHeight();
int xp[4], yp[4];
  
-	xp[0] = x;

+   xp[0] = x + 1;
yp[0] = y - max(h / 4, 1);
if (params_.kind == InsetSpaceParams::NORMAL ||
params_.kind == InsetSpaceParams::PROTECTED ||
params_.kind == InsetSpaceParams::VISIBLE) {
-   xp[1] = x; yp[1] = y;
-   xp[2] = x + w; yp[2] = y;
+   xp[1] = x + 1; yp[1] = y;
+   xp[2] = x + w - 2; yp[2] = y;
} else {
-   xp[1] = x; yp[1] = y + max(h / 4, 1);
-   xp[2] = x + w; yp[2] = y + max(h / 4, 1);
+   xp[1] = x + 1; yp[1] = y + max(h / 4, 1);
+   xp[2] = x + w - 2; yp[2] = y + max(h / 4, 1);
}
-   xp[3] = x + w;
+   xp[3] = x + w - 2;
yp[3] = y - max(h / 4, 1);
  
  	Color col = Color_special;






Re: [LyX/master] Fix disappearing blue language underline.

2018-09-10 Thread Jean-Marc Lasgouttes

Le 10/09/2018 à 05:09, Richard Kimberly Heck a écrit :

On 09/09/2018 02:12 PM, Jean-Marc Lasgouttes wrote:

Le 20/07/2018 à 15:28, Jean-Marc Lasgouttes a écrit :

commit 8e9e05067014a7c5fad501a0f4e8ffbb56eed165
Author: Jean-Marc Lasgouttes 
Date:   Fri Jul 20 15:23:55 2018 +0200

  Fix disappearing blue language underline.
   Make sure that the blue language underline is not below the
bottom of
  the row. Otherwise, it can disappear when the next row is painted.


Riki, can this be backported to 2.3.2?


Sure.


Done at

>
> Riki
> .

JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-09-10 Thread Jean-Marc Lasgouttes

Le 10/09/2018 à 05:09, Richard Kimberly Heck a écrit :

On 09/09/2018 02:15 PM, Jean-Marc Lasgouttes wrote:

Le 20/07/2018 à 00:30, Jean-Marc Lasgouttes a écrit :

commit 8651cd89f6cc16c4e17f197fbbcfe979d09f01c9
Author: Jean-Marc Lasgouttes 
Date:   Fri Jul 20 00:26:41 2018 +0200

  Draw top/bottom rules heavier for booktab
   This gives a better idea of the TeX output, even though the
width are
  not correct.


Riki,

Can I backport to 2.3.2 (along with fixup 84328c85388cc)?


OK.


Done at d371a43.

JMarc


Re: elsarticle

2018-09-05 Thread Jean-Marc Lasgouttes

Le 04/09/2018 à 14:03, Kornel Benko a écrit :

Am Dienstag, 4. September 2018 12:35:52 CEST schrieb Jürgen Spitzmüller 
:

2018-09-03 18:11 GMT+02:00 Kornel Benko :


Ah, yes, I forgot. So, since they don't respond, we don't care?



We could insist. Try to fix the problem ourselves in the cls and provide
them with a patch. Ask for help on stackexchange ...

Jürgen



This is not so trivial. They use the created .aux file for infos about
counter too. But on the first run, this file does not exist. Rerunning
the compilation makes everything work.
If there only would have been the message 'Rerun latex' in the log-file :(


What if we added something like

AddToPreamble
  \IfFileExists{\jobname.aux}{}{\message{Re-run LaTeX to get counters 
right}}

End

Note that I did not try any of it and there are certainly several error 
in this code, but the idea should work, I think.


JMarc


Re: For non-math operators, disable change limits or use \mathop?

2018-09-05 Thread Jean-Marc Lasgouttes

Le 03/09/2018 à 21:56, Scott Kostyshak a écrit :

On Mon, Sep 03, 2018 at 06:04:42PM +0200, Jean-Marc Lasgouttes wrote:

Le 30/08/2018 à 06:52, Scott Kostyshak a écrit :

The \limits command only works for math operators, but we enable
MATH_LIMITS whenever there are limits. This leads to an error if the
limits are not on a math operator. See the attached error.lyx. We can
use \mathop to convert to a math operator, and then there is no error.
See no_error.lyx.

An alternative would be to just disable MATH_LIMITS if the symbol is not
a math operator.


Please try what I just pushed to master at 7b7ed64a0e76.


Tested and works well! Thanks.


Actually it did not work with under/overbrace. Fixed now.

JMarc


Re: 2.3.1-1 compilation error on ubuntu 18.04.1 LTS "unsafe absolute working directory name"

2018-09-05 Thread Jean-Marc Lasgouttes

Le 05/09/2018 à 14:25, Kornel Benko a écrit :

Am Mittwoch, 5. September 2018 14:04:50 CEST schrieb Micha H. Werner 
:

currently, compilation of LyX2.3.1-1 fails on Ubuntu 18.04.1 LTS.

This is the complete output of ./configure:

root@dell:/local/lyx# ./configure


Why do you do this as root?
And why in the source dir?


configuring LyX version 2.3.0
checking for build type... release
checking for version suffix...
checking whether Qt5 is requested... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... configure: error: unsafe
absolute working directory name




According to configure, the directory name contains unsafe characters (one of 
>>"#$&'`<<).


What does "pwd" return?

JMarc


Re: For non-math operators, disable change limits or use \mathop?

2018-09-03 Thread Jean-Marc Lasgouttes

Le 30/08/2018 à 06:52, Scott Kostyshak a écrit :

The \limits command only works for math operators, but we enable
MATH_LIMITS whenever there are limits. This leads to an error if the
limits are not on a math operator. See the attached error.lyx. We can
use \mathop to convert to a math operator, and then there is no error.
See no_error.lyx.

An alternative would be to just disable MATH_LIMITS if the symbol is not
a math operator.


Please try what I just pushed to master at 7b7ed64a0e76. I disable the 
toggling of limits, but it is still possible to create a bad formula: 
insert \[ \int\limits_x \], then replace the \int with a X.


I think the limits_ variable should be moved to the last math inset of 
the nucleus of the script inset, but it is difficult to get right.


JMarc


Re: mathed backslash replace magic

2018-09-03 Thread Jean-Marc Lasgouttes

Le 02/09/2018 à 05:21, Scott Kostyshak a écrit :

If I highlight "A" in mathed and type \mathbb, the "A" is
replaced by \mathbb{A}. I like that. Would we want the same behavior if
we select something and type \not ?


Actu
ally, \not is special: it is a zero width character. Type "=", put 
cursor in front of it, type "\not" and voilà!


JMarc


Re: Windows Installer for Testing

2018-09-01 Thread Jean-Marc Lasgouttes

Le 01/09/2018 à 11:09, Jürgen Spitzmüller a écrit :

The crucial info we need is what makes this so slow only on Windows
(and not on any other OS). Can we do profiling on Win?


Could we have a document that exhibits the problem?

JMarc



Re: Windows Installer for Testing

2018-08-31 Thread Jean-Marc Lasgouttes

Le 31/08/2018 à 13:27, Daniel a écrit :
Unfortunately, LyX 2.3.1 is not usable for me. Many simple things take a 
couple of seconds, like when I press enter for a new paragraph, delete 
something, click on another paragraph, etc.


That is very very weird. I have to give it a go. A couple of seconds is 
a lot.


JMarc


Re: [LyX/master] Make Qt5 the default for building

2018-08-29 Thread Jean-Marc Lasgouttes

Le 29/08/2018 à 13:27, Pavel Sanda a écrit :

Anyone have thoughts about whether to do this in stable? Once 2.3.1 is out?


I think it would unnecessarily break build scripts for distro maintainers
and does not provide some new functionality, just defaults...


I'd say the same.

JMarc


Re: [patch] ditch date-insert

2018-08-18 Thread Jean-Marc Lasgouttes
Le 18 août 2018 16:26:14 GMT+02:00, "Jürgen Spitzmüller"  a 
écrit :
>The attached patch strips date-insert (and the related rc entry and
>helper functions) from master. The function is obsoleted by the more
>flexible and powerful date info-insets.
>
>Objections?
>Jürgen

Not from me.

JMarc

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

2018-08-03 Thread Jean-Marc Lasgouttes
Le 3 août 2018 03:44:51 GMT+02:00, ci-...@inria.fr a écrit :
>PASS: tests/test_ExternalTransforms
>PASS: tests/test_ListingsCaption
>FAIL: tests/test_layout
>PASS: tests/test_Length

Hello,

The test test_layout is failing. Could someone have a look ?

JMarc


Re: 2.3.1

2018-07-30 Thread Jean-Marc Lasgouttes
Le 30 juillet 2018 04:21:14 GMT+02:00, Richard Kimberly Heck  
a écrit :
>Anyone have issues that need resolving before I freeze strings?
>Thinking
>to do that on Tuesday...
>
>Riki

Not me.

JMarc

Re: 7 compilation errors in current master

2018-07-28 Thread Jean-Marc Lasgouttes
Le 28 juillet 2018 01:33:24 GMT+02:00, "Uwe Stöhr"  a écrit :
>After a long time I could compile LyX. While the 2.3.x branch works 
>well, I get these compilation errors in current master:
>
>   D:\LyXGit\Master\src\insets\InsetTabular.cpp(6575): error C2664: 
>'void lyx::swap(lyx::Counters &,lyx::Counters &)': cannot convert 
>argument 1 from 'lyx::Inset::std::col_type' to 'lyx::Counters &' 

All these errors are actually the same. I did this swap thing using advice from 
the web, but I do not understand what c++ does there.

Can someone revert the offending commit ? I am mostly far from a computer
for the coming month :)

JMarc


Re: [LyX/master] Amend 79cf3f5ec10

2018-07-25 Thread Jean-Marc Lasgouttes

Le 25/07/2018 à 13:40, Jürgen Spitzmüller a écrit :

Am Mittwoch, den 25.07.2018, 12:16 +0200 schrieb Jean-Marc Lasgouttes:

Le 25/07/2018 à 11:42, Juergen Spitzmueller a écrit :

commit d1ec35a0dc839ddc27caebed75dd71e60cc6764f
Author: Juergen Spitzmueller 
Date:   Wed Jul 25 11:38:56 2018 +0200

  Amend 79cf3f5ec10
  
  Some InfoInsets have to be LTR always.


Why don't you test for type_ == SHORTCUT_INFO or SHORTCUTS_INFO in
forceLTR() instead of introducing this boolean?


because we use localized strings if the action is unknown or no binding
exists, and this string can be RTL.


I see. So you could actually do
  force_ltr_ = bp.language->rightToLeft() ;
in InsetInfo::updateBuffer().


Anyway, I am currently looking into a more general solution wrt #5348.


Great.

JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-25 Thread Jean-Marc Lasgouttes

Le 25/07/2018 à 11:40, Daniel a écrit :
Even if you know what you are doing it can be helpful to have visual 
guides. I am sure you could do (or maybe you do) programming in a plain 
text editor. Still many people prefer editors that support highlighting. 
Why again does the thicker line that separates head and body of the 
table not help to get a better overview of the table?


Call me an heretic, but sometimes I use several \midrule in a table. It 
did not occur to me that it was forbidden outside of header/footer 
separation. And I do not use \cmidrules in normal operation.


I don't see how a thicker line at the top and bottom of a table that 
*indicates* a formal table encourages people to use that style. In 
contrast a better separation in complex tables of the header and body 
and footer may do so.


Hmm.

I see. I guess we had different aims in mind. Yours was to distinguish 
formal from non-formal tables. Mine was to enhance readability and 
provide a structural indication of what the final table will look like 
(which in turn might encourage people using it).


I am going to return to the previous version for now. We'll see in a 
month whether a mutiny in favor of bolder rules grows.


JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-25 Thread Jean-Marc Lasgouttes

Le 25/07/2018 à 11:44, Daniel a écrit :
ps. A further but more complicated version of (1) is to simulate a 
smaller thickness by using a 2px rule that consist of a black and half 
transparent black line.


Well, typically, I do not intend to do complicate clever tricks... 
People will probably complain this this is blurry.


I apologise for just making clever suggestions without making my hands 
dirty with programming. At the moment that is all I can do. Let me know 
if it isn't helpful.


I am not going to spend a long amount of time on this right now anyway. 
What I propose is to revert my last patch for now. I leave for one month 
of vacation tonight anyway. I will only occasionally read e-mail and 
probably not provide code.


JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-25 Thread Jean-Marc Lasgouttes

Le 25/07/2018 à 09:08, Daniel a écrit :

Thanks. I think it looks good. I prefer it.


So we disagree ;)

Attached is a comparison with a PDF output (one with, roughly, the same 
table size and one with, roughly, the same font size).


Note that when the table is larger in pdf, the rulles are thicker too 
(they are in em). This makes sense, but the thickness here is to be 
compared to the 'blackness' of the font (I am not sure of my 
typographical technical terms). I still think that the top/bottom lines 
are too thick.


I take it that the thicker first and second lines are just eye cady 
while the thicker line(s) in between fulfill the more important function 
of making it easier to distinguish between, for example, the head and 
the foot of the table and the body.


The thick top/bottom lines convey that the table is a formal table. It 
is not eye candy, it is a WYSYWYM indicator.


The fact that incomplete les are thinner *is* eye candy. Only people 
doing complicated tables care about it, and these people are supposed to 
know what they are doing. I want to do something that encourages people 
to use formal tables (there were talks about setting it as default), but 
do not attract too much the eye. Having a thinner line for incomplete 
lines would be eye candy IMO. But I am not a specialist in formal tables.



Anyway, here are a couple of alternatives with some reason for it:

(1) Make all thicker lines the same width (2px).

Reason: The thicker first and second line are not confused with other 
lines because of their special location.


What do you call first and second? I (3), it looks like top/bottom, but 
here ??



(2) Have only the lines in between thick (2px).

Reason: The thicker first and second lines are only eye candy anyway.


???

(3) Have only the first and second line thick (2px), as in your first 
version.


Reason: The thicker first and second lines are there only to indicate 
that the table is formal/a booktab.


That was precisely my point.


JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-24 Thread Jean-Marc Lasgouttes

Le 24/07/2018 à 18:58, Daniel a écrit :

Send an enjoyable lyx file...


If I understood you correctly you offer to create a screenshot for me. 
Attached is the standard example from booktabs package (probably it will 
become more vegetarian friendly in a future version).


Here is a screenshot at the default 150% zoom. I think that the bold 
line attracts too much the eye and is a hindrance for focusing on the 
contents of the document (typical issue with bold in typography). YMMV.


JMarc




Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-24 Thread Jean-Marc Lasgouttes

Le 24/07/2018 à 17:33, Daniel a écrit :

I did it now and don't like much. It is in though for your enjoyment.


Damn. No enjoyment for me at the moment since I cannot complile LyX. But 
if it lookes like with CSS (attached), I would have indeed enjoyed it.


Send an enjoyable lyx file...

JMarc


Re: [LyX/master] Aesthetics: off-by-one in line drawing

2018-07-24 Thread Jean-Marc Lasgouttes

Le 24/07/2018 à 04:51, Richard Kimberly Heck a écrit :

I am sure thee are other off-by-one errors like that, keep them coming

Riki, assuming that Scott's eyes hurt less now, this is candidate for
branch.


Your choice, 2.3.1 or 2.3.2.


Riki,

Can I also backport the following commit? It is the vertical equivalent 
of the off-by-one thing and they touch the same code.


JMarc

commit 8e9e05067014a7c5fad501a0f4e8ffbb56eed165
Author: Jean-Marc Lasgouttes 
Date:   Fri Jul 20 15:23:55 2018 +0200

Fix disappearing blue language underline.

Make sure that the blue language underline is not below the bottom of
the row. Otherwise, it can disappear when the next row is painted.


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-24 Thread Jean-Marc Lasgouttes

Le 24/07/2018 à 01:56, Joel Kulesza a écrit :

If something is not yet correct, I propose to revert the whole thing
and go back to the time when nobody complained ;)


I hope this doesn't occur but rather the initial salvo of changes are kept.


I will wait to see what the general wisdom is between the "bold" 
solution and the prior "half baked one". Please tell me all what you prefer.


JMarc



Re: [LyX/master] Aesthetics: off-by-one in line drawing

2018-07-24 Thread Jean-Marc Lasgouttes

Le 24/07/2018 à 03:46, Scott Kostyshak a écrit :

Riki, assuming that Scott's eyes hurt less now, this is candidate for
branch.


It would bother me if I came across it in my work-related documents, but
I only came across the issue when looking into something else, so
there's no rush on my behalf.


I was just kidding. These things are very simple, so I will put them in 
2.3.1.


JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-23 Thread Jean-Marc Lasgouttes

Le 23/07/2018 à 22:46, Daniel a écrit :

On 23/07/2018 20:40, Jean-Marc Lasgouttes wrote:

Le 23/07/2018 à 20:26, Daniel a écrit :
With 3 pixels for heavy, I will have to take the width into account 
in table cells height computation, while I have conveniently decided 
to ignore it for now :)


Why is it that you would have to take it into account? So far zooming 
keeps the cell padding (emprty space around cell content) fixes. So 
nothing would overlap or so.


I do not know, I have not tried it. But I suspect thatit would seem 
too bold. I may try to do it if I find the time.


I think it will look good.


OK I see you point. You will not stop until I comply.

I did it now and don't like much. It is in though for your enjoyment.

If something is not yet correct, I propose to revert the whole thing and 
go back to the time when nobody complained ;)


JMarc



Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-23 Thread Jean-Marc Lasgouttes

Le 23/07/2018 à 20:26, Daniel a écrit :
With 3 pixels for heavy, I will have to take the width into account in 
table cells height computation, while I have conveniently decided to 
ignore it for now :)


Why is it that you would have to take it into account? So far zooming 
keeps the cell padding (emprty space around cell content) fixes. So 
nothing would overlap or so.


I do not know, I have not tried it. But I suspect thatit would seem too 
bold. I may try to do it if I find the time.


Yes, barely visible does not sound good. Strange that there is no in 
between 1 and 2 for HiDPI displays. Well, would only solve the "problem" 
for those diaplys anyway.


It is possible, as long as we use doubles (aka real numbers) instead of 
integers all over out painting system. That would require a fair amount 
of changes.


JMarc



Re: [LyX/master] Aesthetics: off-by-one in line drawing

2018-07-23 Thread Jean-Marc Lasgouttes

Le 23/07/2018 à 17:19, Jean-Marc Lasgouttes a écrit :

commit ad954a32a525828bd03bf2c8241252e60394cbc3
Author: Jean-Marc Lasgouttes 
Date:   Mon Jul 23 17:07:48 2018 +0200

 Aesthetics: off-by-one in line drawing
 
 It is a general problem when doing graphics to know where a line

 begins and where it ends pixel-wise. At the instigation of Scott, and
 with the use of the kmag magnifier, this commit corrects 3 areas:
 
 * foreign marks were larger than the row element they were supposed to

   mark. This could lead to moving lines, depending on paint ordering.
 
 * visible spaces were drawn outside of their box (select a single

   space to see this).
 
 * the `L' blinking caret would leave a cursor dropping because the

   horizontal part was too wide.


I am sure thee are other off-by-one errors like that, keep them coming

Riki, assuming that Scott's eyes hurt less now, this is candidate for 
branch.


JMarc


---
  src/RowPainter.cpp|2 +-
  src/frontends/qt4/GuiWorkArea.cpp |4 ++--
  src/insets/InsetSpace.cpp |   12 ++--
  3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/RowPainter.cpp b/src/RowPainter.cpp
index 16b144e..efc4021 100644
--- a/src/RowPainter.cpp
+++ b/src/RowPainter.cpp
@@ -159,7 +159,7 @@ void RowPainter::paintForeignMark(Row::Element const & e) 
const
int const desc = e.inset ? e.dim.descent() : 0;
int const y = yo_ + min(3 * pi_.base.solidLineOffset() / 2 + desc,
row_.descent() - 1);
-   pi_.pain.line(int(x_), y, int(x_ + e.full_width()), y, Color_language,
+   pi_.pain.line(int(x_), y, int(x_ + e.full_width() - 1), y, 
Color_language,
  Painter::line_solid, pi_.base.solidLineThickness());
  }
  
diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp

index e6d993c..45c4469 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -150,9 +150,9 @@ public:
painter.setPen(color_);
if (l_shape_) {
if (rtl_)
-   painter.drawLine(x_, bot, x_ - l, bot);
+   painter.drawLine(x_, bot, x_ - l + 1, bot);
else
-   painter.drawLine(x_, bot, x_ + caret_width_ + 
r, bot);
+   painter.drawLine(x_, bot, x_ + caret_width_ + r 
- 1, bot);
}
  
  		// draw completion triangle

diff --git a/src/insets/InsetSpace.cpp b/src/insets/InsetSpace.cpp
index fd8c261..ddb85b7 100644
--- a/src/insets/InsetSpace.cpp
+++ b/src/insets/InsetSpace.cpp
@@ -355,18 +355,18 @@ void InsetSpace::draw(PainterInfo & pi, int x, int y) 
const
int const h = theFontMetrics(pi.base.font).xHeight();
int xp[4], yp[4];
  
-	xp[0] = x;

+   xp[0] = x + 1;
yp[0] = y - max(h / 4, 1);
if (params_.kind == InsetSpaceParams::NORMAL ||
params_.kind == InsetSpaceParams::PROTECTED ||
params_.kind == InsetSpaceParams::VISIBLE) {
-   xp[1] = x; yp[1] = y;
-   xp[2] = x + w; yp[2] = y;
+   xp[1] = x + 1; yp[1] = y;
+   xp[2] = x + w - 2; yp[2] = y;
} else {
-   xp[1] = x; yp[1] = y + max(h / 4, 1);
-   xp[2] = x + w; yp[2] = y + max(h / 4, 1);
+   xp[1] = x + 1; yp[1] = y + max(h / 4, 1);
+   xp[2] = x + w - 2; yp[2] = y + max(h / 4, 1);
}
-   xp[3] = x + w;
+   xp[3] = x + w - 2;
yp[3] = y - max(h / 4, 1);
  
  	Color col = Color_special;






Re: [LyX/master] Do the actual drawing in the paint event

2018-07-23 Thread Jean-Marc Lasgouttes

Le 20/07/2018 à 13:50, Scott Kostyshak a écrit :

With high zoom levels, I noticed a separate issue. It is much more
minor, but in case it is related I will describe it. The blue lines
change length based on cursor movement. It is very subtle, but if you
flip between the attached screenshots, you will see the blue lines
changing length based on the cursor position. In case it is difficult to
see, I attach difference.png. Zoom in and look at the red dots on the
ends of a couple of the blue lines.


I can reproduce this problem. As I see it, the blue line of text goes 
over the blue line of insets (this happens around insets). Therefore, 
when only insets are painted, the erase the extra pixels.


JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-23 Thread Jean-Marc Lasgouttes

Le 23/07/2018 à 15:19, Joel Kulesza a écrit :
On Mon, Jul 23, 2018 at 7:09 AM, Jean-Marc Lasgouttes 
mailto:lasgout...@lyx.org>> wrote:


I could set the width of cmidrule to 0, with would be the same as 1
for normal screens and a **barely visible one-real-pixel wide line
on Mac Retina**.



Please don't do this.


I hoped someone would say that ;)

JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-23 Thread Jean-Marc Lasgouttes

Le 23/07/2018 à 10:16, Daniel a écrit :
Okay, got it. And using 3 pixel for heavy, 1 pixel for thin, and 2 pixel 
for medium doesn't look good? A reason to even trade-off some of the 
good looks is that having only partly a distinction between different 
lines might be misleading.


With 3 pixels for heavy, I will have to take the width into account in 
table cells height computation, while I have conveniently decided to 
ignore it for now :)


Note that the distinction between \midrule and \cmidrule is kind if 
obvious since one of them does not cover all columns. We ar esomewher 
ein the middle between WYSYWYG and WYSYWIM here. I just want to convey 
what a booktab look like. I could set the width of cmidrule to 0, with 
would be the same as 1 for normal screens and a barely visible 
one-real-pixel wide line on Mac Retina.


JMarc


Re: [LyX/master] Improve DEPM

2018-07-23 Thread Jean-Marc Lasgouttes

Le 23/07/2018 à 04:15, Richard Kimberly Heck a écrit :

It sounds good in principle.

Is this a possibility for 2.3.x? If so, you can commit to stable once
2.3.1 is out. Then it should get lots of testing.


I had tentatively set set milestone 2.3.2 for ticket #10503.

JMarc


Re: [LyX/master] Improve DEPM

2018-07-22 Thread Jean-Marc Lasgouttes

Le 22/07/2018 à 23:23, Jean-Marc Lasgouttes a écrit :

commit 20976e81fb25899ee8d3ec5ed941fda6b453f59f
Author: Jean-Marc Lasgouttes 
Date:   Sun Jul 22 22:13:44 2018 +0200

 Improve DEPM
 
 Now any sequence of spaces around old cursor will be removed, even at

 start or end of paragraph. Sequences of more than 2 characters are
 also taken into account.
 
 The version of DEPM which acts on a sequence of paragraphs is also

 rewritten to match the local one.


Hopefully I did not break anything wrt DEPM, but testing is appreciated.

What I would like to do, though is
1/ disable DEPM in read-only document
2/ use undo to be able to rollback such changes

Would anyone oppose to that. I remember that years ago Vincent for
example disagreed, but since he is not around anymore... ;)

JMarc


---
  src/Text.h|4 ---
  src/Text2.cpp |   73 
  2 files changed, 52 insertions(+), 25 deletions(-)

diff --git a/src/Text.h b/src/Text.h
index f09acc8..b54277b 100644
--- a/src/Text.h
+++ b/src/Text.h
@@ -348,10 +348,6 @@ private:
/// The InsetText owner shall have access to everything.
friend class InsetText;
  
-	// fix the cursor `cur' after a characters has been deleted at `where'

-   // position. Called by deleteEmptyParagraphMechanism
-   static void fixCursorAfterDelete(CursorSlice & cur, CursorSlice const & 
where);
-
// At cursor position 0, try to merge the paragraph with the one before 
it.
// Ignore change tracking, i.e., physically remove the end-of-par 
character
bool backspacePos0(Cursor & cur);
diff --git a/src/Text2.cpp b/src/Text2.cpp
index 869684e..d8a9114 100644
--- a/src/Text2.cpp
+++ b/src/Text2.cpp
@@ -780,9 +780,11 @@ bool Text::cursorDownParagraph(Cursor & cur)
  }
  
  
-// fix the cursor `cur' after a characters has been deleted at `where'

+namespace {
+// fix the cursor `cur' after characters has been deleted at `where'
  // position. Called by deleteEmptyParagraphMechanism
-void Text::fixCursorAfterDelete(CursorSlice & cur, CursorSlice const & where)
+void fixCursorAfterDelete(CursorSlice & cur, CursorSlice const & where,
+ pos_type from, pos_type to)
  {
// Do nothing if cursor is not in the paragraph where the
// deletion occurred,
@@ -790,8 +792,8 @@ void Text::fixCursorAfterDelete(CursorSlice & cur, CursorSlice 
const & where)
return;
  
  	// If cursor position is after the deletion place update it

-   if (cur.pos() > where.pos())
-   --cur.pos();
+   if (cur.pos() > from)
+   cur.pos() = max(from, cur.pos() - (to - from));
  
  	// Check also if we don't want to set the cursor on a spot behind the

// pagragraph because we erased the last character.
@@ -799,6 +801,8 @@ void Text::fixCursorAfterDelete(CursorSlice & cur, CursorSlice 
const & where)
cur.pos() = cur.lastpos();
  }
  
+}

+
  
  bool Text::deleteEmptyParagraphMechanism(Cursor & cur,

Cursor & old, bool & need_anchor_change)
@@ -840,23 +844,35 @@ bool Text::deleteEmptyParagraphMechanism(Cursor & cur,
bool const same_par_pos = depth == cur.depth() - 1 && same_par
&& old.pos() == cur[depth].pos();
  
-	// If the chars around the old cursor were spaces, delete one of them.

+   // If the chars around the old cursor were spaces, delete some of
+   // them , but only if the cursor has really moved.
if (!same_par_pos) {
-   // Only if the cursor has really moved.
-   if (old.pos() > 0
-   && old.pos() < oldpar.size()
-   && oldpar.isLineSeparator(old.pos())
-   && oldpar.isLineSeparator(old.pos() - 1)
-   && !oldpar.isDeleted(old.pos() - 1)
-   && !oldpar.isDeleted(old.pos())) {
-   oldpar.eraseChar(old.pos() - 1, 
cur.buffer()->params().track_changes);
+   // find range of spaces around cursors
+   int from = old.pos();
+   while (from > 0
+  && oldpar.isLineSeparator(from - 1)
+  && !oldpar.isDeleted(from - 1))
+   --from;
+   int to = old.pos();
+   while (to < oldpar.size() - 1
+  && oldpar.isLineSeparator(to)
+  && !oldpar.isDeleted(to))
+   ++to;
+
+   // If we are not at the extremity of the paragraph, keep one 
space
+   if (from != to && from > 0 && to < oldpar.size())
+   ++from;
+
+   // Remove spaces and adapt cursor.
+   

Re: #11201: LyX crashing when adding citation from Zotero using LyZ

2018-07-22 Thread Jean-Marc Lasgouttes

Le 22/07/2018 à 20:36, Jean-Marc Lasgouttes a écrit :

Le 22/07/2018 à 19:33, Thomas DiPrete a écrit :
I found this in the console from 7/17, which is the date I reported 
the bug.  I hope it is helpful. I've attached to this message the 
several versions.


I am not sure that this contains more information about what LyX is 
doing at this time. I am not a Zotero user, so trying to reproduce the 
problem on my side is a bit complicated.


PS: please do not reply by e-mail, it is better for us if interaction 
takes place on trac.


JMarc


Re: #11201: LyX crashing when adding citation from Zotero using LyZ

2018-07-22 Thread Jean-Marc Lasgouttes

Le 22/07/2018 à 19:33, Thomas DiPrete a écrit :
I found this in the console from 7/17, which is the date I reported the 
bug.  I hope it is helpful. I've attached to this message the several 
versions.


I am not sure that this contains more information about what LyX is 
doing at this time. I am not a Zotero user, so trying to reproduce the 
problem on my side is a bit complicated.


If you enable View>Message Pane, you will see something like the 
attached image on the bottom of the windows. Click on Settings (the tab 
on the right), then on "(o) Selected" and then double click on lyxserver 
so that it says "yes".


After that, if you reproduce the crashing procedure, you should find the 
relevant lyx messages in Console.app before the crash dump. I do not 
have a mac at hand, I can unfortunately not be more precise.


JMarc



Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-22 Thread Jean-Marc Lasgouttes

Le 22/07/2018 à 18:59, Daniel a écrit :
But I am a bit lost. You state the widths above as em fractions but say 
that the values are integers. Do you mean that the list of widths widths 
above are as defined in the booktab package but you are using integer 
values to set the line width in LyX?


The em values are indeed what booktabs defines. However, they all 
correspond to <1 pixel values except when dpi is very high. So I have 
hardcoded to 2 pixels for heavy and 1 pixel for thin. A reason for not 
taking dpi into account is that no everybody agree that  lines should 
become thicker with zoom.


JMarc


Re: Failing exports

2018-07-22 Thread Jean-Marc Lasgouttes

Le 22/07/2018 à 14:57, Jean-Marc Lasgouttes a écrit :

Le 22/07/2018 à 14:06, Kornel Benko a écrit :

bisect led to
d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91 is the first bad commit
commit d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91
Author: Juergen Spitzmueller 
Date:   Tue Jul 10 07:11:59 2018 +0200

 Disallow any inset inside ERT


Not a lyx2lyx issue, then. Good.


Thanks for the bisect BTW. I find them so long and inconvenient to do 
that I try to avoid them (in this case, I asked you because I thought it 
was one of the two recent lyx2lyx changes :).


JMarc


Re: Failing exports

2018-07-22 Thread Jean-Marc Lasgouttes

Le 22/07/2018 à 14:06, Kornel Benko a écrit :

bisect led to
d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91 is the first bad commit
commit d41c3f27d9192bd3b0de89a04ccf2fcf16bb4c91
Author: Juergen Spitzmueller 
Date:   Tue Jul 10 07:11:59 2018 +0200

 Disallow any inset inside ERT


Not a lyx2lyx issue, then. Good.

JMarc


 Attempting to do this crashes in master, and is not supported anyway.

:04 04 9a0e94fc78f55cf266b3de53907516b776d51bf7 
e7e6f5812075fbb01963a024f4130050d04a15eb M  src

Kornel





Re: Failing exports

2018-07-22 Thread Jean-Marc Lasgouttes

Le 22/07/2018 à 11:08, Kornel Benko a écrit :

Am Sonntag, 22. Juli 2018 10:32:59 CEST schrieb Jürgen Spitzmüller 
:

Am Sonntag, den 22.07.2018, 09:59 +0200 schrieb Kornel Benko:

It is \ only. Search for instance for ' sungsmittel', then open the
ERT to the left.


Not here. See screenshot. Are you sure yours is a clean checkout?


Yes, checked multiple times.
BUT
there is something fishy with lyx2lyx probably.
Compare orig snippet with converted to 2.4.
And, in fact, using lyx2.3 I _can_ compile.


Can you tell which of the recent lyx2lyx changes is faulty? The relevant 
ticket is

https://www.lyx.org/trac/ticket/11200

JMarc



Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-21 Thread Jean-Marc Lasgouttes

Le 21/07/2018 à 19:50, Daniel a écrit :

The widths are:
heavy=0.008em
thin=0.05em
cmid=0.03em

If I do use these values, I can only see a difference between heavy 
and thin beyond 180% zoom (at 100dpi) and the 3 width are different 
only over 300% zoom.


So I do not really see how I could differentiate these 3 values.


So, on HiDPI displays I set 1px, 1.5px, and 2px, and on non HiDPI 
displays 1px, 2px, and 3px. But I worked with pixel so that was easier 
to solve.


For now all our values are integers. It is still possible to do 
something about it, but I am not sure how important it is.


JMarc



Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-21 Thread Jean-Marc Lasgouttes

Le 21/07/2018 à 12:55, Daniel a écrit :
- a rule is thickest if and only if (it is the first or last) *and* it 
stretches along the whole with of the table,


right?


No, I will fix it asap.

And from there, and maybe while you are at it, it might not be far from 
implementing the other line style:


- a rule is medium thick (i.e. factor 1.5) if and only if (it is not the 
first nor last) *and* it stretches along the whole with of the table.


The widths are:
heavy=0.008em
thin=0.05em
cmid=0.03em

If I do use these values, I can only see a difference between heavy and 
thin beyond 180% zoom (at 100dpi) and the 3 width are different only 
over 300% zoom.


So I do not really see how I could differentiate these 3 values.

JMarc


Re: [LyX/master] Do the actual drawing in the paint event

2018-07-20 Thread Jean-Marc Lasgouttes

Le 20/07/2018 à 13:50, Scott Kostyshak a écrit :

On Thu, Jul 19, 2018 at 07:14:27PM +, Jean-Marc Lasgouttes wrote:

Le 16/07/2018 à 13:34, Scott Kostyshak a écrit :

To reproduce, open the attached file (which is related to the Hebrew
splash.lyx), and place the cursor at the top of the file, then press the
down arrow repeatedly. At some point, the blue lines disappear in some
places and then reappear.


Does the situation change if you zoom in?


I can still reproduce the issue at high zoom levels. I take it by your
question that you cannot reproduce? Perhaps another instance of
different Qt versions? If so, perhaps you should not spend time on it.


OK, I can reproduce actually. I committed a possible fix, please tel me 
if it is OK.


JMarc


Re: [LyX/master] Draw top/bottom rules heavier for booktab

2018-07-19 Thread Jean-Marc Lasgouttes

Le 20/07/2018 à 00:30, Jean-Marc Lasgouttes a écrit :

commit 8651cd89f6cc16c4e17f197fbbcfe979d09f01c9
Author: Jean-Marc Lasgouttes 
Date:   Fri Jul 20 00:26:41 2018 +0200

 Draw top/bottom rules heavier for booktab
 
 This gives a better idea of the TeX output, even though the width are

 not correct.


Please try it out. If people like it, it can be backported.

JMarc


---
  src/insets/InsetTabular.cpp |   34 --
  1 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/src/insets/InsetTabular.cpp b/src/insets/InsetTabular.cpp
index 5499719..ebe4ba6 100644
--- a/src/insets/InsetTabular.cpp
+++ b/src/insets/InsetTabular.cpp
@@ -4211,35 +4211,43 @@ void InsetTabular::drawSelection(PainterInfo & pi, int 
x, int y) const
  }
  
  
+namespace {

+
+void tabline(PainterInfo const & pi, int x1, int y1, int x2, int y2,
+ bool drawline, bool heavy = false)
+{
+   ColorCode const col = drawline ? Color_tabularline : 
Color_tabularonoffline;
+   pi.pain.line(x1, y1, x2, y2, pi.textColor(col),
+drawline ? Painter::line_solid : 
Painter::line_onoffdash,
+(heavy ? 2 : 1) * Painter::thin_line);
+}
+
+}
+
+
  void InsetTabular::drawCellLines(PainterInfo & pi, int x, int y,
 row_type row, idx_type cell) const
  {
y -= tabular.rowAscent(row);
int const w = tabular.cellWidth(cell);
int const h = tabular.cellHeight(cell);
-   Color const linecolor = pi.textColor(Color_tabularline);
-   Color const gridcolor = pi.textColor(Color_tabularonoffline);
  
  	// Top

bool drawline = tabular.topLine(cell)
|| (row > 0 && tabular.bottomLine(tabular.cellAbove(cell)));
-   pi.pain.line(x, y, x + w, y,
-   drawline ? linecolor : gridcolor,
-   drawline ? Painter::line_solid : Painter::line_onoffdash);
+   bool heavy = tabular.use_booktabs && row == 0 && tabular.topLine(cell);
+   tabline(pi, x, y, x + w, y, drawline, heavy);
  
  	// Bottom

drawline = tabular.bottomLine(cell);
-   pi.pain.line(x, y + h, x + w, y + h,
-   drawline ? linecolor : gridcolor,
-   drawline ? Painter::line_solid : Painter::line_onoffdash);
+   heavy = tabular.use_booktabs && row == tabular.nrows() - 1 && drawline;
+   tabline(pi, x, y + h, x + w, y + h, drawline, heavy);
  
  	// Left

col_type const col = tabular.cellColumn(cell);
drawline = tabular.leftLine(cell)
|| (col > 0 && tabular.rightLine(tabular.cellIndex(row, col - 
1)));
-   pi.pain.line(x, y, x, y + h,
-   drawline ? linecolor : gridcolor,
-   drawline ? Painter::line_solid : Painter::line_onoffdash);
+   tabline(pi, x, y, x, y + h, drawline);
  
  	// Right

x -= tabular.interColumnSpace(cell);
@@ -4250,9 +4258,7 @@ void InsetTabular::drawCellLines(PainterInfo & pi, int x, 
int y,
drawline = tabular.rightLine(cell)
   || (next_cell_col < tabular.ncols()
   && tabular.leftLine(tabular.cellIndex(row, 
next_cell_col)));
-   pi.pain.line(x + w, y, x + w, y + h,
-   drawline ? linecolor : gridcolor,
-   drawline ? Painter::line_solid : Painter::line_onoffdash);
+   tabline(pi, x + w, y, x + w, y + h, drawline);
  }
  
  





Re: [LyX/master] Do the actual drawing in the paint event

2018-07-19 Thread Jean-Marc Lasgouttes

Le 16/07/2018 à 13:34, Scott Kostyshak a écrit :

To reproduce, open the attached file (which is related to the Hebrew
splash.lyx), and place the cursor at the top of the file, then press the
down arrow repeatedly. At some point, the blue lines disappear in some
places and then reappear.


Does the situation change if you zoom in?

I see similar things when the underlines positions are below the bottom 
of the row and are therefore erased by the next row. I see two solutions:

* adjust the lines to be inside rows

* adjust row height to contain the rows.

JMarc


Re: [LyX/master] Amend 30ec879, Add a translator as a fallback to Qt inner one

2018-07-19 Thread Jean-Marc Lasgouttes

Le 19/07/2018 à 00:36, Jean-Marc Lasgouttes a écrit :

Le 19/07/2018 à 00:31, Kornel Benko a écrit :
Yes. Content inside the '#if' 0' serves as example only, and is 
already also in po-file.


It is in the po file because it is indicated here (look at older code). 
The #if 0 is because I feared that clever compilers would complain.


I removed the #if 0/#endif.

JMarc



Re: [RFC][PATCH] Change dialog language without restarting

2018-07-19 Thread Jean-Marc Lasgouttes

Le 19/07/2018 à 10:21, Kornel Benko a écrit :

Works nice.
For easy change of GUI-language a function would be handy too :)

For buffer we have
buffer-language
so
gui-language
comes in mind.


I give up for now. There are too many places where translation is done 
explicitly.


JMarc


Re: thoughts about LyX's future and proposals

2018-07-19 Thread Jean-Marc Lasgouttes

Le 19/07/2018 à 15:28, mn a écrit :

What would be some middle ground here?


Of course the right attitude is somewhere in the middle. My message came 
ou harsher than it should have.



I certainly do not want to impose my will on a dev, do not want to be a
member of a committee.

But a lot of features I'd like to see implemented or bugs fixed (even
readymade solutions I proposed) just do not materialize, certainly not
in a timeframe that gets me excited.


The problem I see is that, as a developer, I need some incentive to work 
on a feature. If I look back on stuff that I implemented, the categories 
are:


* a feature that I happen to need (extended literate programming 
support, little annoyances I have when using LyX)


* something that interests me and that I presume to be generally 
desirable (speed, better rendering...)


* something that nobody asks for but that needs to be done if we want to 
go forward (unicode support for tex2lyx, large code cleanup to get rid 
of accumulated cruft)


* something I began because I though it was easy but that proves to be 
very complicated (math formulae display). After starting, it is too late 
to stop :)


* small things that people requested and I know how to do while reading 
the bug report.


In conclusion, it is a match between a need and someone able/willing to 
provide a solution.
I do not think that we will be able to go very far from this equilibrium 
point.


What is not in these categories for example is conversion to/from MS Word:

* I do not use Word if I can avoid to

* converters are pretty difficult and the result is often mediocre; 
tex2lyx is already very difficult to get right, and LyX is supposed to 
be close to LaTeX.


Therefore I do not see any compelling reason to embark in this endeavour.


There is just not enough *systematic* user feedback.
Error reports, user-ml private feedback are certainly not showing the
devs a complete and accurate or representative picture.


It is indeed in this "negociation" phase that we can make progress to 
find good matches. Things are not easy though. There a lot of tickets on 
trac that either point to issues or propose well designed features that 
I do not have time to work on. Racoon, for example has written plenty of 
these and I feel bad about neglecting most f them. I do have almost 10 
years old bug reports taunting me in my mail box :)



As can be seen in the email exchange above: Devs have quite distinct
impressions and personal opinions on the situation.


Do we ? ;)


I think a compromise might involve a more quantified user feedback,
maybe for the ticket tracker?

Currently only the devs assign priority to a ticket. How about adding a
running counter on which users might then vote?


I see these voting things on some bug trackers but I am not sure that 
they help. Having a feature highly voted on does not guarantee that it 
is fixable or that somebody has the time/urging/capacity to implement 
it. This can even create frustration from users.


As Pavel mentioned, there is the Features page that serves a similar 
purpose. We should maybe move the ones that have been implemented 
somewhere else, so that the green highlight does not catch the eye so much.



In any case I think Uwe's idea should be reconcilable with JMarc's
stance on that. I see a benefit for everyone involved if that could be
implemented. Devs still choose what to do next, what seems to them the
most taxing problem or the nicest thing to add, but with an awareness of
a more objective quality of what others think about that.


We definitely need to find ways forward. But the number of active 
developers is not that big.
Of course, we will try to be supportive of users who want to try a toe 
in the cold water of development !


Best regards,
JMarc


Re: [RFC][PATCH] Change dialog language without restarting

2018-07-19 Thread Jean-Marc Lasgouttes

Le 19/07/2018 à 00:52, Kornel Benko a écrit :

Any comments? Should I do it differently? Should I do it at all?


I would welcome it (if that is not too much work of course).
Sometimes it is handy to switch the GUI-language while checking own 
translations.


I will see whether I can finish it in finite time. The goal is to get 
rid of the "restart LyX for changes to take effect" dialog.


JMarc


Re: [LyX/master] Amend 30ec879, Add a translator as a fallback to Qt inner one

2018-07-18 Thread Jean-Marc Lasgouttes

Le 19/07/2018 à 00:31, Kornel Benko a écrit :

Yes. Content inside the '#if' 0' serves as example only, and is already also in 
po-file.


It is in the po file because it is indicated here (look at older code). 
The #if 0 is because I feared that clever compilers would complain.


JMarc


[RFC][PATCH] Change dialog language without restarting

2018-07-18 Thread Jean-Marc Lasgouttes
The following patch implements a way to retranslate dialogs when the GUI 
language changes. For now I only did About and Bibtex. I have yet to 
understand how to do Bibitem and other InsetParamWidget children.


Comments welcome. Is this worth doing, considering that it requires work 
(but not so much code).


In some cases, the situation is a bit complicated, like the long tooltip 
defined explicitly in InsetBibtex. Note that for this case, it is 
possible to use html:

https://stackoverflow.com/questions/17221621/how-to-set-qt-tooltip-width

Any comments? Should I do it differently? Should I do it at all?

JMarc

>From 24cbbff3f145f4f20fc0dc5a3344c382658d5be5 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 19 Jul 2018 00:13:28 +0200
Subject: [PATCH] Proof of concept: retranslate dialogs on the fly

This patch shows how to change the language of dialogs seemlessly
without restarting LyX. Currently only About and Bibtex are done. The
first uses DialogView and the second GuiVIew. The changes are minimal,
although there are details to handle...

The trick is to use the functon retranslateUi which is created by uic
in the ui_*.h files. This requires unfortunately to call the function
explicitely in each dialog.
---
 src/frontends/qt4/Dialog.cpp |  7 ---
 src/frontends/qt4/Dialog.h   |  9 -
 src/frontends/qt4/DialogView.cpp |  2 +-
 src/frontends/qt4/DockView.cpp   |  2 +-
 src/frontends/qt4/GuiAbout.cpp   | 16 ++--
 src/frontends/qt4/GuiAbout.h |  6 ++
 src/frontends/qt4/GuiApplication.cpp | 11 +++
 src/frontends/qt4/GuiApplication.h   |  2 ++
 src/frontends/qt4/GuiBibtex.cpp  | 13 ++---
 src/frontends/qt4/GuiBibtex.h|  5 +
 src/frontends/qt4/GuiDialog.cpp  |  2 +-
 src/frontends/qt4/GuiView.cpp| 14 +-
 src/frontends/qt4/GuiView.h  |  2 ++
 13 files changed, 74 insertions(+), 17 deletions(-)

diff --git a/src/frontends/qt4/Dialog.cpp b/src/frontends/qt4/Dialog.cpp
index 2369738c5c..b74be6825f 100644
--- a/src/frontends/qt4/Dialog.cpp
+++ b/src/frontends/qt4/Dialog.cpp
@@ -44,8 +44,9 @@ using namespace lyx::support;
 namespace lyx {
 namespace frontend {
 
-Dialog::Dialog(GuiView & lv, QString const & name, QString const & title)
-	: name_(name), title_(title), lyxview_(lv)
+Dialog::Dialog(GuiView & lv, QString const & name,
+   QString const & prefix, QString const & title)
+	: name_(name), title_prefix_(prefix), title_(title), lyxview_(lv)
 {}
 
 
@@ -171,7 +172,7 @@ void Dialog::prepareView()
 	checkStatus();
 
 	QWidget * w = asQWidget();
-	w->setWindowTitle(title_);
+	w->setWindowTitle(title_prefix_ + qt_(title_));
 
 	QSize const hint = w->sizeHint();
 	if (hint.height() >= 0 && hint.width() >= 0)
diff --git a/src/frontends/qt4/Dialog.h b/src/frontends/qt4/Dialog.h
index 5f958e79d0..71360d09d8 100644
--- a/src/frontends/qt4/Dialog.h
+++ b/src/frontends/qt4/Dialog.h
@@ -55,13 +55,17 @@ public:
 	/// \param name is the identifier given to the dialog by its parent
 	/// container.
 	/// \param title is the window title used for decoration.
-	Dialog(GuiView & lv, QString const & name, QString const & title);
+	Dialog(GuiView & lv, QString const & name,
+	   QString const & prefix, QString const & title);
 
 	virtual ~Dialog();
 
 	virtual QWidget * asQWidget() = 0;
 	virtual QWidget const * asQWidget() const = 0;
 
+	/// This should be implemented by each dialog
+	virtual void retranslate() {};
+
 	/// Session key.
 	/**
 	 * This key must be used for any session setting.
@@ -263,6 +267,7 @@ public:
 protected:
 	///
 	void setTitle(QString const & title) { title_ = title; }
+	void setTitlePrefix(QString const & prefix) { title_prefix_ = prefix; }
 	///
 	virtual void apply();
 	/// To be called when the buffer view has changed
@@ -274,6 +279,8 @@ private:
 	 */
 	QString const name_;
 	///
+	QString title_prefix_;
+	///
 	QString title_;
 	///
 	GuiView & lyxview_;
diff --git a/src/frontends/qt4/DialogView.cpp b/src/frontends/qt4/DialogView.cpp
index 9b114ec507..b715dafece 100644
--- a/src/frontends/qt4/DialogView.cpp
+++ b/src/frontends/qt4/DialogView.cpp
@@ -18,7 +18,7 @@ namespace lyx {
 namespace frontend {
 
 DialogView::DialogView(GuiView & lv, QString const & name, QString const & title)
-	: QDialog(), Dialog(lv, name, "LyX: " + title)
+	: QDialog(), Dialog(lv, name, "LyX: ", title)
 {
 	connect(, SIGNAL(bufferViewChanged()),
 	this, SLOT(onBufferViewChanged()));
diff --git a/src/frontends/qt4/DockView.cpp b/src/frontends/qt4/DockView.cpp
index de9a51c78f..4845f240a8 100644
--- a/src/frontends/qt4/DockView.cpp
+++ b/src/frontends/qt4/DockView.cpp
@@ -21,7 +21,7 @@ namespace frontend {
 DockView::DockView(GuiView & parent, QString const & name,
QString const & title, Qt::Doc

Re: [LyX/master] Amend 30ec879, Add a translator as a fallback to Qt inner one

2018-07-18 Thread Jean-Marc Lasgouttes

Le 18/07/2018 à 23:34, Richard Kimberly Heck a écrit :

diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp
index e04c392..f009bfc 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -689,6 +689,10 @@ public:
_("Reconfigure");
_("Quit %1"));
  #endif
+   _("");
+   // Already in po: "Cancel", ""
+   _("Apply"); // Already in po: ""
+   _("Reset"); // Already in po: "" "R" "Rese"


Did you want these ones to be outside the #if 0?


I guess he did not :) I am not sure anyway whether this #if 0 is needed. 
Are there compilers which are going to complain about that?


JMarc


Re: [LyX/master] More QDialogButtonBox

2018-07-17 Thread Jean-Marc Lasgouttes
Le 18 juillet 2018 02:19:22 GMT+02:00, Kornel Benko  a écrit :
>Works. That is very nice. I started with the most often used
>   "", "Apply" and "Reset"
>used for instance at paragraph-settings.
>
>   Kornel

Very good. Can I let you take over from now and commit once you are confident 
that all needed translations are in?

JMarc


Re: [LyX/master] More QDialogButtonBox

2018-07-17 Thread Jean-Marc Lasgouttes

Le 18/07/2018 à 00:44, Jean-Marc Lasgouttes a écrit :

Le 10/07/2018 à 12:53, Jürgen Spitzmüller a écrit :

Am Dienstag, den 10.07.2018, 11:24 +0200 schrieb Jean-Marc Lasgouttes:

A solution would be to create our own QTranslator child that does
the
translation using the po files and falls back to Qt otherwise. I can
give it a go next week.


I would prefer the other way round: try Qt and provide a fallback
solution if necessary. The translations of strings for "Apply", "Reset"
etc. differ between OSes/DEs, and LyX should adapt to the context here.


Does Qt really change its own translations? In which case?

Anyway, here is a patch. If you want to se the missing translations, use 
"-dbg locale". You will found that there are many strings passed there, 
and I do not know why they are used.


I have not updated all po files for now. Kornel, could you try it out 
and check that this is what you need? You will have to add words to 
translate to GuiApplication.cpp.


JMarc


Grmf.


>From cbc2d9ec500141162332b8ef9692a9babb3e44e9 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 18 Jul 2018 00:41:09 +0200
Subject: [PATCH] Add a translator as a fallback to Qt inner one

This reuses code intended only for mac manus and generalizes it. The
list of strings to add to po files is found in
GuiTranslator::translate.

This is useful now that LyX relies on QDialogButtonBox class for its
dialogs. Indeed many languages are not covered natively by Qt.

It is possible to enable the "locace" debug channel to see what
strings are not covered and should be added to our own translation
tables.

In order to make things easier, a new method getIfFound() has been
added to the Messages class, which returns an empty string when no
translation has been found, as Qt's translate() does.
---
 src/frontends/qt4/GuiApplication.cpp | 49 
 src/support/Messages.cpp | 13 
 src/support/Messages.h   |  5 ++-
 3 files changed, 46 insertions(+), 21 deletions(-)

diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index 25eff65ec2..e04c392474 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -664,16 +664,10 @@ public:
 };
 
 
-
-//
-// Mac specific stuff goes here...
-//
-
-
-class MenuTranslator : public QTranslator
+class GuiTranslator : public QTranslator
 {
 public:
-	MenuTranslator(QObject * parent)
+	GuiTranslator(QObject * parent = nullptr)
 		: QTranslator(parent)
 	{}
 
@@ -687,15 +681,30 @@ public:
 	  const char * /*comment*/ = 0) const
 #endif
 	{
-		string const s = sourceText;
-		if (s == N_("About %1")	|| s == N_("Preferences")
-|| s == N_("Reconfigure") || s == N_("Quit %1"))
-			return qt_(s);
-		else
-			return QString();
+#if 0
+		// Here we declare the strings that need to be translated from Qt own GUI
+		// This is needed to include these strings to po files
+		_("About %1");
+		_("Preferences");
+		_("Reconfigure");
+		_("Quit %1"));
+#endif
+		docstring s = getGuiMessages().getIfFound(sourceText);
+		// This test should eventually be removed when translations are updated
+		if (s.empty())
+			LYXERR(Debug::LOCALE, "Missing translation for `"
+			   << string(sourceText) << "'");
+		return toqstr(s);
 	}
 };
 
+
+
+//
+// Mac specific stuff goes here...
+//
+
+
 #ifdef Q_OS_MAC
 // QMacPasteboardMimeGraphics can only be compiled on Mac.
 
@@ -944,8 +953,10 @@ struct GuiApplication::Private
 	FontLoader font_loader_;
 	///
 	ColorCache color_cache_;
-	///
+	/// the built-in Qt translation mechanism
 	QTranslator qt_trans_;
+	/// LyX gettext-based translation for Qt elements
+	GuiTranslator gui_trans_;
 	///
 	QHash socket_notifiers_;
 	///
@@ -1025,7 +1036,9 @@ GuiApplication::GuiApplication(int & argc, char ** argv)
 
 	qsrand(QDateTime::currentDateTime().toTime_t());
 
-	// Install translator for GUI elements.
+	// Install LyX translator for missing Qt translations
+	installTranslator(>gui_trans_);
+	// Install Qt native translator for GUI elements.
 	installTranslator(>qt_trans_);
 
 #ifdef QPA_XCB
@@ -1044,10 +1057,6 @@ GuiApplication::GuiApplication(int & argc, char ** argv)
 	// FIXME: Do we need a lyxrc setting for this on Mac? This behaviour
 	// seems to be the default case for applications like LyX.
 	setQuitOnLastWindowClosed(false);
-	// This allows to translate the strings that appear in the LyX menu.
-	/// A translator suitable for the entries in the LyX menu.
-	/// Only needed with Qt/Mac.
-	insta

Re: [LyX/master] More QDialogButtonBox

2018-07-17 Thread Jean-Marc Lasgouttes

Le 10/07/2018 à 12:53, Jürgen Spitzmüller a écrit :

Am Dienstag, den 10.07.2018, 11:24 +0200 schrieb Jean-Marc Lasgouttes:

A solution would be to create our own QTranslator child that does
the
translation using the po files and falls back to Qt otherwise. I can
give it a go next week.


I would prefer the other way round: try Qt and provide a fallback
solution if necessary. The translations of strings for "Apply", "Reset"
etc. differ between OSes/DEs, and LyX should adapt to the context here.


Does Qt really change its own translations? In which case?

Anyway, here is a patch. If you want to se the missing translations, use 
"-dbg locale". You will found that there are many strings passed there, 
and I do not know why they are used.


I have not updated all po files for now. Kornel, could you try it out 
and check that this is what you need? You will have to add words to 
translate to GuiApplication.cpp.


JMarc


Re: thoughts about LyX's future and proposals

2018-07-17 Thread Jean-Marc Lasgouttes

Le 17/07/2018 à 02:17, Uwe Stöhr a écrit :

So what can be done? In my opinion, we should
- define the goal of LyX together with our users. Maybe the result is 
to hide background stuff, maybe it is the opposite. Whatever it might 
be, that should be the base for future development.
- setup a "board of development" that take care of user feedback and 
who define the things the next version of LyX should have. Such a 
board should only be 50% consist of developers. Translators are not 
treated as developers. The idea is to see what people really need and 
to organize its development so that several developers develop a 
certain feature.


I only made these 2 proposals and thought they are worth to be considered.
It is OK not to agree, but what about other ideas or do you think we 
should just continue as we did the last months? I mean criticism should 
be constructive. So I would her your ideas for future development.


OK, here are my _final_ words on the subject then. Considering the 
number of active developers, we do not have that much free goodwill to 
spend on design by committee. I already have a day job, thanks. I am not 
looking for a new boss telling me what I should be doing during my free 
time.


Despite your insistence that we do not love our users, I do my best. If 
it is not good enough for you, so be it.


I hope this is a clear enough answer, it is as constructive as I can be.

JMarc

PS:  remember that LyX is a platypus: something so weirdly designed that 
everybody is surprised that it even exists. I understand you would 
better have something useful like a cow or a duck. However, these are 
boring animals and everybody loves platypuses :)


Re: [LyX/master] More QDialogButtonBox

2018-07-10 Thread Jean-Marc Lasgouttes

Le 10/07/2018 à 12:14, Kornel Benko a écrit :

Am Dienstag, 10. Juli 2018 11:52:28 CEST schrieb Jean-Marc Lasgouttes 
:

Le 10/07/2018 à 11:34, Kornel Benko a écrit :

A solution would be to create our own QTranslator child that does the
translation using the po files and falls back to Qt otherwise. I can
give it a go next week.

JMarc


That would be nice :)


Do we have a list of entries that we need? We already have some for the
Mac menus (so that the special code there could be removed). I propose
to create entries like "[Qt]" or, if you prefer, without the [Qt]
context.


I just checked: Apply Cancel Close Ok Reset


I am sure there are other strings: at least there are the special menus 
names on macOS.


And shall I add a context?

JMarc


Re: [LyX/master] More QDialogButtonBox

2018-07-10 Thread Jean-Marc Lasgouttes

Le 10/07/2018 à 11:34, Kornel Benko a écrit :

A solution would be to create our own QTranslator child that does the
translation using the po files and falls back to Qt otherwise. I can
give it a go next week.

JMarc


That would be nice :)


Do we have a list of entries that we need? We already have some for the 
Mac menus (so that the special code there could be removed). I propose 
to create entries like "[Qt]" or, if you prefer, without the [Qt] 
context.


JMarc


Re: [LyX/master] More QDialogButtonBox

2018-07-10 Thread Jean-Marc Lasgouttes

Le 10/07/2018 à 11:24, Jean-Marc Lasgouttes a écrit :

In German GUI it looks OK, but unfortunately not in Slovak.
Could not find the needed language package.


A solution would be to create our own QTranslator child that does the 
translation using the po files and falls back to Qt otherwise. I can 
give it a go next week.


I see we already have a MenuTranslator for macOS. I will have to study this.

JMarc


Re: [LyX/master] More QDialogButtonBox

2018-07-10 Thread Jean-Marc Lasgouttes

Le 10/07/2018 à 11:04, Kornel Benko a écrit :

Am Dienstag, 10. Juli 2018 10:38:00 CEST schrieb Jürgen Spitzmüller 
:

Am Dienstag, den 10.07.2018, 10:24 +0200 schrieb Kornel Benko:

There is a small glitch in using QDialogButtonBox:: ...
The translation is done with respect to the local language (e.g env
LANG, LANGUAGE)
and not with respect to then lyx-GUI language.

For instance
QDialogButtonBox::Cancel
displays "Abbrechen" because my LANGUAGE environment is set to
"de_DE".


I suppose the same applies to file dialog, warning dialog and all other
native qt dialogs we use, right?


Yes :(


It might be possible to force Qt locale to the one we want.


Moreover, if QT does not have the correct translation, it uses the
English version.


But these are the most basic strings of any OS.


In German GUI it looks OK, but unfortunately not in Slovak.
Could not find the needed language package.


A solution would be to create our own QTranslator child that does the 
translation using the po files and falls back to Qt otherwise. I can 
give it a go next week.


JMarc


Re: LyX Windows Installer, Final?

2018-07-08 Thread Jean-Marc Lasgouttes

Le 08/07/2018 à 08:33, Richard Kimberly Heck a écrit :

That will create a LyX-something.zip file containing what's needed for
Windows. I've
been creating the actual installer on Windows itself, basically
following the directions
in Uwe's Readme.txt file.


Isn't it possible to use the fedora-packaged mingw32-nsis?

JMarc

PS: I tested briefly the binary, which seems to work well. However, when 
I wanted to install paper.cls (to check on of you reports), texlive told 
me that I cannot update my texlive 2017. So I decided to upgrade to 
texlive 2018, and it is still installing itself after 1h45 :(


JMarc


Re: Code Preview Pane does not update when composite characters are entered

2018-07-05 Thread Jean-Marc Lasgouttes

Le 26/06/2018 à 06:41, Scott Kostyshak a écrit :

To reproduce:

1. Switch keyboard layout to Spanish.
2. Start a new LyX document.
3. Go to View > Code Preview Pane.
4. Make sure the box "Automatic update" is checked.
5. Enter <<é>> by pressing <<'>> and then <>.

When I do that, nothing shows for me in the preview pane. If I then
enter e.g. "e", then it does update.


This is now ticket https://www.lyx.org/trac/ticket/11183

And this is fixed in master at ad5548cf.

As your bisect showed, this is related to input methods handling (dead 
characters go through there). As I touched sensitive parts of the code, 
I'd appreciate if someone who knows about input methods could confirm 
that the situation is not worse than it was.


This is candidate for branch, although not urgent for 2.3.1 if we fear 
it might break something. Personally, I am nervous when touching the 
semantics of LFUN_SELF_INSERT :)


JMarc


Re: Code Preview Pane does not update when composite characters are entered

2018-07-04 Thread Jean-Marc Lasgouttes

Le 26/06/2018 à 06:41, Scott Kostyshak a écrit :

To reproduce:

1. Switch keyboard layout to Spanish.
2. Start a new LyX document.
3. Go to View > Code Preview Pane.
4. Make sure the box "Automatic update" is checked.
5. Enter <<é>> by pressing <<'>> and then <>.

When I do that, nothing shows for me in the preview pane. If I then
enter e.g. "e", then it does update.


Confirmed. Another issue is that entering hat-accent+space in mathed now 
inserts a ^ instead of creating a superscript.


JMarc


Re: [LyX/master] Unbreak completion in text mode

2018-07-04 Thread Jean-Marc Lasgouttes

Le 03/07/2018 à 17:44, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

Could you give me a step-by-step example where triangle does not appear
before you switch tab?


Super easy, just launch lyx, create new file, write "hel" and no triangle.


This is normal, since completion is done according to other words 
present in documents



Open the example with figure+note, edit the note, triangle appears.


Because "help" appears somewhere, right?


Go back to tab1, hit enter and write "hel" again. The triangle is there now.


Yes, the word "help" from the other tab is used to propose a completion.

ATM there is no way to inhibit completion but you can set "minimum 
characters for words that should be completed" to 100 to effectively 
disable the feature.


JMarc


Re: [LyX/master] Unbreak completion in text mode

2018-07-04 Thread Jean-Marc Lasgouttes

Le 04/07/2018 à 04:40, Richard Kimberly Heck a écrit :

On 07/03/2018 07:18 PM, Pavel Sanda wrote:

Jean-Marc Lasgouttes wrote:

Le 03/07/2018 ?? 15:01, Pavel Sanda a écrit :

So it might be that indentation vs completion issue was here always,
but for some reason the new patch enables (by default disabled) completion
even for users like me who never used it in the text...

Now in texted in master, completion is off when there is a selection. Let's
go to the next problem now :)

I can confirm that the problem is fixed now.
I vote for backporting if Riki agrees.


If JMarc thinks it is ok.



I just backported it.

JMarc


Re: [LyX/master] Fix compilation on case insensitive filesystems

2018-07-04 Thread Jean-Marc Lasgouttes

Le 04/07/2018 à 09:54, Stephan Witt a écrit :

Am 04.07.2018 um 09:48 schrieb Enrico Forestieri :


commit dfd6afb7409fac345a26d5b16d967d3f4c5f7fa1
Author: Enrico Forestieri 
Date:   Wed Jul 4 09:42:04 2018 +0200

Fix compilation on case insensitive filesystems

In such filesystems, including either Magic.h or magic.h does not
make any difference and the one or other file is included depending
on the search order. In this case, Magic.h was trying to include
itself instead of including magic.h.



Thank you! I had the same problem on Mac and wasn’t fast enough to propose your 
solution.


I missed this issue indeed. Thanks for taking care of it.

JMarc


Re: [LyX/master] Unbreak completion in text mode

2018-07-03 Thread Jean-Marc Lasgouttes

Le 03/07/2018 à 15:01, Pavel Sanda a écrit :

I have disabled Automatic inline completion for text in Preferences.
I create first new document and no completion rtiangle is there.
I open different document with that figure+note I used to show the triangle
painting problem recently and suddenly the triangle appears.
I switch back to the first document and triangle for completion appears as well!


Disabling automatic completion does not disable the triangle, only the 
completion shown in gray. So it is normal that you see the triangle, 
even though you do not like it. We do not have a way to completely 
disable completion. The only bug that I see is that the triangle doe 
snot appear right away.


Could you give me a step-by-step example where triangle does not appear 
before you switch tab?


JMarc


Re: [LyX/master] Unbreak completion in text mode

2018-07-03 Thread Jean-Marc Lasgouttes

Le 03/07/2018 à 15:01, Pavel Sanda a écrit :

So it might be that indentation vs completion issue was here always,
but for some reason the new patch enables (by default disabled) completion
even for users like me who never used it in the text...


Now in texted in master, completion is off when there is a selection. 
Let's go to the next problem now :)


JMarc


Re: [LyX/master] Unbreak completion in text mode

2018-07-03 Thread Jean-Marc Lasgouttes

Le 03/07/2018 à 15:01, Pavel Sanda a écrit :

I am puzzled by the completion behaviour in the current master.

I have disabled Automatic inline completion for text in Preferences.
I create first new document and no completion rtiangle is there.
I open different document with that figure+note I used to show the triangle
painting problem recently and suddenly the triangle appears.
I switch back to the first document and triangle for completion appears as well!

So it might be that indentation vs completion issue was here always,
but for some reason the new patch enables (by default disabled) completion
even for users like me who never used it in the text...

Rings a bell?


It does not ring a bell as in "I know what to do", but at least it makes 
more sense. Please open two separate tickets. I will have some time 
during this month and I will try to work through the list of thing to do.


JMarc


Re: [LyX/master] Unbreak completion in text mode

2018-07-03 Thread Jean-Marc Lasgouttes

Le 03/07/2018 à 12:24, Daniel a écrit :

On 14/06/2018 17:46, Pavel Sanda wrote:

Could we disable completion when the cursor stands
at the end of selected text, so the lfun for nesting in command-sequence
takes priority over completion?


The cursor can be at the beginning of a selection and still I would 
expect it to behave the same as if it would at the end of a selection.


So you mean that completion should be disabled if there is a selection? 
That makes sense.


JMarc


Re: [LyX/master] Unbreak completion in text mode

2018-07-03 Thread Jean-Marc Lasgouttes

Le 03/07/2018 à 10:32, Pavel Sanda a écrit :

Well, this is design question. Should nesting have priority over completion or 
not?

I think it's fine if completion wins in case you are in the middle of writing 
some
word. But clearly you doing something different when the block is selected.


I can easily do this selection change. However, I am very surprised that 
this is related to my recent change. Are you sure this did not happen in 
2.3.0 or 2.2.x?


JMarc


Re: [LyX/master] Unbreak completion in text mode

2018-07-02 Thread Jean-Marc Lasgouttes

Le 02/07/2018 à 22:59, Pavel Sanda a écrit :

Pavel Sanda wrote:

Often now when you hit tab completion menu appears instead of nesting
which is annoying. Could we disable completion when the cursor stands
at the end of selected text, so the lfun for nesting in command-sequence
takes priority over completion?


Should I file it on bugzilla or are you still on the track?


Please file a bug. Is it really only when there is a selection?

JMarc


  1   2   3   4   5   6   7   8   9   10   >