Re: Errors with vref on de/Additional.lyx with lualatex

[Kornel Benko]

Am Mittwoch, 19. Juli 2017 um 22:23:32, schrieb Kornel Benko 
> Am Mittwoch, 19. Juli 2017 um 19:48:49, schrieb Guenter Milde 
> 
> > On 2017-07-19, Kornel Benko wrote:
> >
> > > [-- Type: text/plain, Encoding: 7bit --]
> >
> > > Am Mittwoch, 19. Juli 2017 um 15:00:16, schrieb Kornel Benko 
> > > 
> > >> So, maybe better we could omit \textcompwordmark in mono fonts.
> >
> > > This patch works for me. It uses vphantom{}, but only between '<<' and 
> > > '>>'.
> >
> > See my other post for alternatives solving the "missing character" error
> > with Unicode fonts for \textcompwordmark.
>
> I have read it. I understand the usage and I don’t insist on removing 
> textcompwordmark any longer.
>
> > If you insist on changing away from textcompwordmark, this should be limited
> > to TU, i.e. done in
> > bool Paragraph::Private::latexSpecialTU(char_type const c, otexstream & os,
> >
> >
> > Günter
>
> I don't insist. I would insist on removing textcompwordmark in mono fonts, 
> but did not see an easy way.

It turned out, it is easy. Output for desired ligatures with the attached patch 
is:
"\\vphantom{}" if mono mono-fonts
"\\textcompwordmark " else.

To disable ligature for '>>' and '<<' the output is "\\vphantom{}"

Korneldiff --git a/lib/doc/de/Additional.lyx b/lib/doc/de/Additional.lyx
index 5ccd07b..539aa6d 100644
--- a/lib/doc/de/Additional.lyx
+++ b/lib/doc/de/Additional.lyx
@@ -41,9 +41,9 @@ shapepar
 \language_package default
 \inputencoding auto
 \fontencoding global
-\font_roman "lmodern" "default"
-\font_sans "lmss" "default"
-\font_typewriter "lmtt" "default"
+\font_roman "lmodern" "DejaVu Serif [bitstream]"
+\font_sans "lmss" "DejaVu Sans [bitstream]"
+\font_typewriter "lmtt" "DejaVu Sans Mono [bitstream]"
 \font_math "auto" "auto"
 \font_default_family default
 \use_non_tex_fonts false
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 73157e6..622477b 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1378,8 +1378,8 @@ bool Paragraph::Private::latexSpecialT1(char_type const c, otexstream & os,
 		// but we should avoid ligatures
 		if (i + 1 >= int(text_.size()) || text_[i + 1] != c)
 			return true;
-		os << "\\textcompwordmark" << termcmd;
-		column += 19;
+		os << "\\vphantom{}";
+		column += 16;
 		return true;
 	case '|':
 		os.put(c);
diff --git a/src/insets/InsetSpecialChar.cpp b/src/insets/InsetSpecialChar.cpp
index bbf54cf..293541c 100644
--- a/src/insets/InsetSpecialChar.cpp
+++ b/src/insets/InsetSpecialChar.cpp
@@ -424,7 +424,15 @@ void InsetSpecialChar::latex(otexstream & os,
 		os << "\\LyXZeroWidthSpace" << termcmd;
 		break;
 	case LIGATURE_BREAK:
-		os << "\\textcompwordmark" << termcmd;
+		if (rp.local_font != 0) {
+			FontFamily ff = rp.local_font->fontInfo().family();
+			if (ff == TYPEWRITER_FAMILY)
+os << "\\vphantom{}";
+			else
+os << "\\textcompwordmark" << termcmd;
+		}
+		else
+			os << "\\textcompwordmark" << termcmd;
 		break;
 	case END_OF_SENTENCE:
 		os << "\\@.";


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

Re: [LyX/master] Try to end the neverending fixIfBroken saga

[Jean-Marc Lasgouttes]

Le 20/07/2017 à 23:52, Kornel Benko a écrit :

I can feel with you. Please don't kill the messenger.


Should be better now. Thanks Kornel.

JMarc

Re: [LyX/master] Try to end the neverending fixIfBroken saga

[Kornel Benko]

Am Donnerstag, 20. Juli 2017 um 23:28:57, schrieb Jean-Marc Lasgouttes 

> Le 20/07/2017 à 23:26, Kornel Benko a écrit :
> > Sorry, but after this commit I cannot load doc/de/Additional.lyx anymore.
> > Immediate crash.
> > Rechecking with
> > #git checkout 4d09650
> > ...
> > # make
> > with this version it is loadable.
> 
> I really love this :) Sometime I think that I should just revert to 
> no-check version, but at the same time I learn a lot about weirdness in 
> LyX by doing this. I am just ashamed to make all of you my guinea pigs.
> 
> JMarc

I can feel with you. Please don't kill the messenger.

Kornel

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

Re: [LyX/master] Try to end the neverending fixIfBroken saga

[Jean-Marc Lasgouttes]

Le 20/07/2017 à 23:26, Kornel Benko a écrit :

Sorry, but after this commit I cannot load doc/de/Additional.lyx anymore.
Immediate crash.
Rechecking with
#git checkout 4d09650
...
# make
with this version it is loadable.


I really love this :) Sometime I think that I should just revert to 
no-check version, but at the same time I learn a lot about weirdness in 
LyX by doing this. I am just ashamed to make all of you my guinea pigs.


JMarc

Re: [LyX/master] Try to end the neverending fixIfBroken saga

[Kornel Benko]

Am Donnerstag, 20. Juli 2017 um 11:31:11, schrieb Jean-Marc Lasgouttes 

> commit fc7fb6a5642bf8163276797c1602dd1395e2aef7
> Author: Jean-Marc Lasgouttes 
> Date:   Thu Jul 20 11:18:20 2017 +0200
> 
> Try to end the neverending fixIfBroken saga
> 
> This is a fixup to the  series of commits 522516d9, d0acc3e5, 13c3c148.
> 
> Actually the right thing to consider in all situations is isActive(),
> which really means `can a cursor be in there?'.
> 
> Improve the description of isActive() and editable() in Inset.h.
> 
> Set isActive() to false for InsetInfo, since no cursor should ever go 
> there.
> 
> Again part of #10667.


Sorry, but after this commit I cannot load doc/de/Additional.lyx anymore.
Immediate crash.
Rechecking with
#git checkout 4d09650
...
# make
with this version it is loadable.

Kornel

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

Re: Options for resolving the minted + shell-escape issue

[Richard Heck]

On 07/20/2017 01:21 AM, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 19.07.2017, 16:37 +0200 schrieb Enrico Forestieri:
>> The attached patch takes into account all of these ideas. As a
>> disclaimer,
>> note that I am providing it only because I am now familiar with this
>> part
>> of the code and can quickly come up with a patch. But I am not
>> endorsing it.
> I propose to apply this patch and return to productivity.

I would agree with that.

Richard

Re: Any descriptions of the security aspects (related to needauth and shell-escape)?

[Guillaume MM]

Le 19/07/2017 à 16:59, Richard Heck a écrit :

On 07/19/2017 02:22 AM, Christian Ridderström wrote:

Hi,

When having tried to contribute to the discussion on needauth and
shell-escape I've felt that it's quite difficult to get a good picture
of things like:
- Goals of design, what are we trying to achieve
- Principle of design and system
- Assumed threat models, and perhaps list threat scenarios we _don't_
try to protect against

The e-mail threads are ... long, sometimes confusing and I suspect
contains at least a few misunderstandings.  So I would like to ask
(not being optimistic), if there's some design description anywhere?


No, as usual, there is not. The needauth mechanism was developed by
Tommaso in response
to security worries about certain sorts of converters, e.g., the ones
for R and related worries
about the use of gnuplot. (It may have been the latter that got him
interested.) Once that was on
board, Enrico decided to employ at least a somewhat similar mechanism to
support minted.sty,
and for whatever reason, that set off alarm bells which, in retrospect,
should have gone off
earlier. So we find ourselves in the middle of things.

Richard




Yes Richard, (smaller) alarm bells could have gone off a month earlier
if I had paid attention to the gnuplot discussion. They went off when
Scott explicitly asked about extending the use of needauth, and it did
not seem to have changed the course of things.

For 2.3 Scott chose to ask "what can we do for LyX to be the safest?"
rather than the obvious solution to get beta out. I find it reasonable
and a worthwhile time investment.

Guillaume

Re: Can shell-escape take advantage of needauth framework?

[Guillaume MM]

Le 19/07/2017 à 11:47, Pavel Sanda a écrit :

Guillaume MM wrote:

Le 18/07/2017 ?? 23:27, Jean-Marc Lasgouttes a écrit :

Le 18/07/2017 ?? 23:24, Christian Ridderström a écrit :

The threat model is one important aspect, but it's difficult for us to
know who uses LyX and in which industries. Or how many users there are at
all. And how many of them that use converters.  If we can achieve good
security we don't need to care about user / usage statistics though.

If we talk principles, I think we should aim for really good security and
then discuss compromises for what's not doable. But I do think we could
do a whole lot better than the current 'needauth'.


+1


You start driving me to the wall.


To clarify, this +1 is about the ideal approach to securing the UI.

For 2.3, like Jürgen, I vote for getting back to productivity quickly,
and I do not need to repeat what was to me the realistic solution for
meeting the beta deadline.


Where you have been when there was huge discussion about details of these
mechanisms with Tommasso?


The discussion was not about designing a secure UI for extending the
realm of unsafe converters. Needauth was a much needed improvement, and
I actually try not to be a PITA in general (really). Moreover, Helge had
said what had to be said about its limitations in terms of security.

And between us, I try to steer away from discussions on the list unless
really necessary, to the point that I have been avoiding making
developments which I knew would involve discussions :( I mean, look at
the thread I found back in the archives exactly during the time frame of
the needauth discussion:
.
Do you think that I am incited me to contribute to discussions more than
is really necessary when they tend to become this embarrassing and
everybody acts as if this is normal?




Meep! Principle 1: "Things don???t become unsafe all by themselves
(Explicit authority)". This means in particular: the secure settings are
the default.


Yep. Isn't it the case with needauth right now?


Indeed, this is how needauth increased security.

Thank you for your involvement in the thread.

Guillaume

Re: Can shell-escape take advantage of needauth framework?

[Guillaume MM]

Le 19/07/2017 à 16:47, Richard Heck a écrit :

On 07/19/2017 05:06 AM, Pavel Sanda wrote:

Christian Ridderström wrote:

I just did a test with gnuplot. In the LyX settings I had unchecked 'Forbid
of use of needauth converters' and unchecked 'Use needauth option'. Then I
opened a LyX doc with a gnuplot script. Result: LyX tried to run the script
due to the preview, without asking or alerting me.

In my opinion this demonstrates a case where the security is _not_ good
enough, as I don't think it'd very difficult to trick someone into
unchecking these boxes.

I think at the end it boils down to the question whether we rather want
LyX for unaware users who can't handle any responsibility or we want
to allow advanced features for more hackish crowd of people.

I obviously stay in the hackish campground ground but understand your
fear for the poor.

I would offer two quick options here:
1. Rename 'Forbid of use of needauth converters' to something scary
so users have red flag.
2. Let the machinery alive, but move the flags from UI to RC files,
and forcing people to edit them, so they have time to think
what they are doing instead of randomly clicking.


I've suggested this, too. Just to be clear, you just have to remove the
UI for this setting. It
can stay in the same file, which can just be edited.



Not sure if what is being discussed is for 2.3 or for an ideal 
implementation, but ideally what about:


1. No "needauth" preferences (do not allow needauth from being disabled).
2. The dialog has a checkbox "I have read the above and I understand the
consequences", unchecked by default, which one has to check before
clicking "allow" or "always allow for the document". This checkbox is
remembered per-user (this replaces the "forbid use of needauth" option).
3. For command-line only (without GUI), have a command-line options
--needauth=[never(default)|always|ask].

Assuming other principles are implemented (visibility, revocability,
etc.), then IMO 2. is all we need as a secure GUI, and 3. all that is
needed for a secure command line (for a needauth implementation that
satisfies other principles).

Re: [LyX/master] Fixup the fixup d0acc3e57044: use editable()/isActive()

[Jürgen Spitzmüller]

Am Donnerstag, den 20.07.2017, 14:57 +0200 schrieb Jean-Marc
Lasgouttes:
> > Technically, insets with a dialog are also "editable".
> 
> No, now we say that they "have settings". The notion of editable is 
> really related to entering in the inset with a cursor. 

I see. Didn't know. This strikes me like a rather idiosyncratic use of
"editing". I would prefer if the function name would be more clear
about what that means.

> > isEditableInWorkarea()
> > 
> > (as opposed to: via dialog)
> 
> But editable, isActive and descendable are already about that.

Yes, I wasn't questioning the meaning, but the expression (name).

Jürgen

> 
> JMarc

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

Re: [LyX/master] Fixup the fixup d0acc3e57044: use editable()/isActive()

[Jean-Marc Lasgouttes]

Le 20/07/2017 à 14:08, Jürgen Spitzmüller a écrit :

Am Donnerstag, den 20.07.2017, 12:32 +0200 schrieb Jean-Marc
Lasgouttes:

Le 20/07/2017 à 11:52, Jürgen Spitzmüller a écrit :

The reason probably is that the naming of these functions is not
really
good.


Indeed.


As I understand your comments, shouldn't it be something like:

cursorCanEnter() (editable())


Well technically cursor can enter a closed InsetCollapsable (with
find)


Technically, insets with a dialog are also "editable".


No, now we say that they "have settings". The notion of editable is 
really related to entering in the inset with a cursor. The problem is 
that there are several ways to enter.



isEditableInWorkarea()

(as opposed to: via dialog)


But editable, isActive and descendable are already about that.

JMarc

Re: [LyX/master] Fixup the fixup d0acc3e57044: use editable()/isActive()

[Jürgen Spitzmüller]

Am Donnerstag, den 20.07.2017, 12:32 +0200 schrieb Jean-Marc
Lasgouttes:
> Le 20/07/2017 à 11:52, Jürgen Spitzmüller a écrit :
> > The reason probably is that the naming of these functions is not
> > really
> > good.
> 
> Indeed.
> 
> > As I understand your comments, shouldn't it be something like:
> > 
> > cursorCanEnter() (editable())
> 
> Well technically cursor can enter a closed InsetCollapsable (with
> find)

Technically, insets with a dialog are also "editable".

> 
> It is a pity that cursorable does not exist.
> 
> > isWorkareaEditable() (isActive())
> 
> The name WorkArea is already used.

isEditableInWorkarea()

(as opposed to: via dialog)

is actually what I meant.

Jürgen

> 
> And of course I did not mention descendable(BufferView*) yet :)
> 
> JMarc

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

Re: [LyX/master] Fixup the fixup d0acc3e57044: use editable()/isActive()

[Jean-Marc Lasgouttes]

Le 20/07/2017 à 11:52, Jürgen Spitzmüller a écrit :

Am Donnerstag, den 20.07.2017, 11:38 +0200 schrieb Jean-Marc
Lasgouttes:

Sigh. It turns out I understood the whole isActive/editable/nargs
issue
only vaguely.


The reason probably is that the naming of these functions is not really
good.


Here is a patch that simplifies the code. The only difference is that 
editable() is now true for inner math insets. I am not sure whether it 
can affect the Compare feature. The other uses should be OK.


I do not think it should go to master, but rather in 2.4 as an early 
cleanup action.


JMarc
From 6c549578b78d768b81f50d354d30c223ff32efb0 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 20 Jul 2017 12:11:46 +0200
Subject: [PATCH] Cleanup editable and isActive

The only intended change of behavior in this patch is that on-toplevel
math inset will now return editable()==true when isActive() is true.

The situation is now the following:

Semantics:
* isActive: true if a cursor can be placed in this inset
* editable: true if the cursor movement operations will enter this inset.

Definition:
* default: isActive() == (nargs() > 0)
* override: isActive() == false for InsetMathRef and InsetInfo
* defaut: editable() == isActive()
* override: editable() == false for closed InsetCollasapable()
---
 src/BufferView.cpp  | 1 +
 src/Compare.cpp | 2 ++
 src/DocIterator.cpp | 5 +
 src/insets/Inset.cpp| 6 --
 src/insets/Inset.h  | 6 +++---
 src/insets/InsetInfo.h  | 2 --
 src/insets/InsetTabular.h   | 2 --
 src/insets/InsetText.h  | 2 --
 src/mathed/InsetMathHull.h  | 2 --
 src/mathed/InsetMathMacroTemplate.h | 2 --
 src/mathed/InsetMathNest.cpp| 6 --
 src/mathed/InsetMathNest.h  | 2 --
 12 files changed, 7 insertions(+), 31 deletions(-)

diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 2f25636..782f86b 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -792,6 +792,7 @@ bool BufferView::moveToPosition(pit_type bottom_pit, pos_type bottom_pos,
 			// shortened. Otherwise, setCursor may crash
 			// lyx when the cursor can not be set to these
 			// insets.
+			// FIXME: why can't we use the auto_open_ mechanism in this case?
 			size_t const n = dit.depth();
 			for (size_t i = 0; i < n; ++i)
 if (!dit[i].inset().editable()) {
diff --git a/src/Compare.cpp b/src/Compare.cpp
index 796eb19..684ba21 100644
--- a/src/Compare.cpp
+++ b/src/Compare.cpp
@@ -470,6 +470,7 @@ static bool equal(Inset const * i_o, Inset const * i_n)
 	// FIXME: This fails if the parameters of the insets differ.
 	// FIXME: We do not recurse into InsetTabulars.
 	// FIXME: We need methods inset->equivalent(inset).
+	// FIXME: shouldn't this use isActive() instead?
 	if (i_o->editable() && !i_o->asInsetMath()
 		  && i_o->asInsetText())
 		return true;
@@ -842,6 +843,7 @@ void Compare::Impl::processSnake(DocRangePair const & rp)
 	DocPair it = rp.from();
 	for (; it.o < rp.o.to; ++it) {
 		Inset * inset = it.o.text()->getPar(it.o.pit()).getInset(it.o.pos());
+		// FIXME: consider using isActive() instead
 		if (inset && inset->editable() && inset->asInsetText()) {
 			// Find the inset in the paragraph list that will be pasted into
 			// the final document. The contents of the inset will be replaced
diff --git a/src/DocIterator.cpp b/src/DocIterator.cpp
index 38f2393..6375142 100644
--- a/src/DocIterator.cpp
+++ b/src/DocIterator.cpp
@@ -381,10 +381,7 @@ void DocIterator::forwardPos()
 void DocIterator::forwardPosIgnoreCollapsed()
 {
 	Inset * const nextinset = nextInset();
-	// FIXME: the check for asInsetMath() shouldn't be necessary
-	// but math insets do not return a sensible editable() state yet.
-	if (nextinset && !nextinset->asInsetMath()
-	&& !nextinset->editable()) {
+	if (nextinset && !nextinset->editable()) {
 		++top().pos();
 		return;
 	}
diff --git a/src/insets/Inset.cpp b/src/insets/Inset.cpp
index b458c81..5ea0c2a 100644
--- a/src/insets/Inset.cpp
+++ b/src/insets/Inset.cpp
@@ -484,12 +484,6 @@ bool Inset::directWrite() const
 }
 
 
-bool Inset::editable() const
-{
-	return false;
-}
-
-
 bool Inset::hasSettings() const
 {
 	return false;
diff --git a/src/insets/Inset.h b/src/insets/Inset.h
index f10ab3f..758429e 100644
--- a/src/insets/Inset.h
+++ b/src/insets/Inset.h
@@ -348,14 +348,14 @@ public:
 	virtual bool isActive() const { return nargs() > 0; }
 	/// can the contents of the inset be edited on screen ?
 	// equivalent to isActive except for closed InsetCollapsable
-	virtual bool editable() const;
-	/// has the Inset settings that can be modified in a dialog ?
-	virtual bool hasSettings() const;
+	virtual bool editable() const { return isActive(); }
 	/// can we go further down on mouse click?
 	/// true for InsetCaption, InsetCollapsables (not ButtonOnly), InsetTabular
 	virtual bool descendable(BufferView const &) const { 

Re: [LyX/master] Fixup the fixup d0acc3e57044: use editable()/isActive()

[Jean-Marc Lasgouttes]

Le 20/07/2017 à 11:52, Jürgen Spitzmüller a écrit :

The reason probably is that the naming of these functions is not really
good.


Indeed.


As I understand your comments, shouldn't it be something like:

cursorCanEnter() (editable())


Well technically cursor can enter a closed InsetCollapsable (with find)

It is a pity that cursorable does not exist.


isWorkareaEditable() (isActive())


The name WorkArea is already used.

And of course I did not mention descendable(BufferView*) yet :)

JMarc

Re: [LyX/master] Fixup the fixup d0acc3e57044: use editable()/isActive()

[Jürgen Spitzmüller]

Am Donnerstag, den 20.07.2017, 11:38 +0200 schrieb Jean-Marc
Lasgouttes:
> Sigh. It turns out I understood the whole isActive/editable/nargs
> issue 
> only vaguely.

The reason probably is that the naming of these functions is not really
good.

As I understand your comments, shouldn't it be something like:

cursorCanEnter() (editable())
isWorkareaEditable() (isActive())

Jürgen



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

Re: [LyX/master] Fixup the fixup d0acc3e57044: use editable()/isActive()

[Jean-Marc Lasgouttes]

Le 20/07/2017 à 03:34, Scott Kostyshak a écrit :


Open the attached .lyx file. Make sure that the cursor is at the
beginning and that the footnote inset is not visible on the screen. Then
do a find for the word "find".

Expected: that Lyx opens the inset and highlights the word "find".
Actual: LyX places the cursor before the inset and leaves the inset
closed.


Sigh. It turns out I understood the whole isActive/editable/nargs issue 
only vaguely.


I fixed this in master now at fc7fb6a56  and tried to document what the 
functions actually do. I have to backport this to stable. Richard, OK? 
If you prefer, I can just revert the whole fixifbroken modifications 
from stable, which will unfix #10667. It might be safer, after all. I am 
confident about the fix, but it is the the fourth time that I am 
confident about what is the right thing to do.


JMarc