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

[Pavel Sanda]

Enrico Forestieri wrote:
> Yes, of course, because procmail inserted a ">" just in front of the
> "From " line in the attachment (which I do manually).
> 
> Care to share the corresponding config line(s) for procmail?

Hmm, nothing special:

:0
*List-Post: 
.lyx.devel

Pavel

[patch] support for Urdu

[Uwe Stöhr]

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


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


The patch also enables Syriac which is another RTL language supported by 
polyglossia.


regards Uwe


Urdu-Test.lyx
Description: application/lyx
 development/FORMAT   |  5 +
 lib/languages| 28 ++--
 lib/lyx2lyx/lyx_2_3.py   | 46 +-
 src/tex2lyx/Preamble.cpp | 12 ++--
 src/version.h|  4 ++--
 5 files changed, 72 insertions(+), 23 deletions(-)

diff --git a/development/FORMAT b/development/FORMAT
index e615671..36ace3e 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,11 @@ adjustments are made to tex2lyx and bugs are fixed in 
lyx2lyx.
 
 ---
 
+2016-10-23 Uwe Stöhr 
+   * Format incremented to 515: support for Urdu and Syriac:
+ \lang urdu
+ \lang syriac
+
 2016-10-22 Uwe Stöhr 
* Format incremented to 514: support for Amharic etc.:
  \lang amharic
diff --git a/lib/languages b/lib/languages
index f126e69..fa9019e 100644
--- a/lib/languages
+++ b/lib/languages
@@ -1064,13 +1064,13 @@ Language swedish
 End
 
 # not supported by babel
-#Language syriac
-#  GuiName  "Syriac"
-#  PolyglossiaName  syriac
-#  Encoding utf8
-#  RTL  true
-#  LangCode syr_SY
-#End
+Language syriac
+   GuiName  "Syriac"
+   PolyglossiaName  syriac
+   Encoding utf8
+   RTL  true
+   LangCode syr_SY
+End
 
 # not supported by babel
 Language tamil
@@ -1155,13 +1155,13 @@ Language uppersorbian
 End
 
 # not supported by babel
-#Language urdu
-#  GuiName  "Urdu"
-#  PolyglossiaName  urdu
-#  Encoding utf8
-#  RTL  true
-#  LangCode ur_PK
-#End
+Language urdu
+   GuiName  "Urdu"
+   PolyglossiaName  urdu
+   Encoding utf8
+   RTL  true
+   LangCode ur_PK
+End
 
 # vietnam must be loaded locally with babel options,
 # not globally via class options, see
diff --git a/lib/lyx2lyx/lyx_2_3.py b/lib/lyx2lyx/lyx_2_3.py
index 3a1b292..65b5188 100644
--- a/lib/lyx2lyx/lyx_2_3.py
+++ b/lib/lyx2lyx/lyx_2_3.py
@@ -441,6 +441,48 @@ def revert_khmer(document):
 "\\end_layout", ""]
 
 
+def revert_urdu(document):
+"Set the document language to English but assure Urdu output"
+
+if document.language == "urdu":
+document.language = "english"
+i = find_token(document.header, "\\language urdu", 0)
+if i != -1:
+   document.header[i] = "\\language english"
+j = find_token(document.header, "\\language_package default", 0)
+if j != -1:
+   document.header[j] = "\\language_package default"
+add_to_preamble(document, 
["\\AtBeginDocument{\setotherlanguage{urdu}}"])
+document.body[2 : 2] = ["\\begin_layout Standard",
+"\\begin_inset ERT", "status open", "",
+"\\begin_layout Plain Layout", "", "",
+"\\backslash",
+"resetdefaultlanguage{urdu}",
+"\\end_layout", "", "\\end_inset", "", "",
+"\\end_layout", ""]
+
+
+def revert_syriac(document):
+"Set the document language to English but assure Syriac output"
+
+if document.language == "syriac":
+document.language = "english"
+i = find_token(document.header, "\\language syriac", 0)
+if i != -1:
+   document.header[i] = "\\language english"
+j = find_token(document.header, "\\language_package default", 0)
+if j != -1:
+   document.header[j] = "\\language_package default"
+add_to_preamble(document, 
["\\AtBeginDocument{\setotherlanguage{syriac}}"])
+document.body[2 : 2] = ["\\begin_layout Standard",
+"\\begin_inset ERT", "status open", "",
+"\\begin_layout Plain Layout", "", "",
+"\\backslash",
+"resetdefaultlanguage{syriac}",
+"\\end_layout", "", "\\end_inset", "", "",
+"\\end_layout", ""]
+
+
 ##
 # Conversion hub
 #
@@ -452,10 +494,12 @@ convert = [
[511, [convert_ibranches]],
[512, [convert_beamer_article_styles]],
[513, []],
-   [514, []]
+   [514, []],
+   [515, []]
   ]
 
 revert =  [
+   [514, [revert_urdu, revert_syriac]],
[513, 

Re: LinuxDay @ Pisa - Oct 22nd

[Tommaso Cucinotta]

On 29/09/2016 19:02, Tommaso Cucinotta wrote:

15-min demo about LyX at the upcoming LinuxDay, on Oct 22nd in Pisa (Italy), 
and I've just been notified that this might really happen :-)!


Indeed, it happened :-)! Just a quick note that all attendees raised their hands 
when asked about familiarity with LaTeX, but only one of them knew LyX already 
(positive experience of a thesis written with LyX). Despite this, I wasn't 
assaulted & destroyed by LaTeX geeks as I was expecting :-)...

I ended up with making an overview of LyX features, +/- following those few 
slides I circulated already

  http://retis.sssup.it/~tommaso/LinuxDay-2016.pdf

I made a live demonstration of:
- LyX maths & tables editing
- graphics insertion including easy creation of .odg graphics from samples 
(local patch) and .gnuplot scripts/plots automatically graph-ed (local patch)
- advanced find & replace, including finding styles with regexps and finding 
maths
- LyX chat (local patch) through the use of a local XMPP server on my laptop
- and a few other things.

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

Got a couple of students asking off-line some more details about external 
scripting similar to what I had shown with .gnuplot :-)!

So, let's hope to get some more users and/or contributors :-)!

Cheers,

T.

Re: [LyX/master] Move class definitions inside main class

[Enrico Forestieri]

On Sun, Oct 23, 2016 at 12:26:55AM +0200, Guillaume Munch wrote:

> Le 23/10/2016 à 00:09, Enrico Forestieri a écrit :
> > On Sat, Oct 22, 2016 at 11:26:15PM +0200, Guillaume Munch wrote:
> > 
> > > commit 148b3ae773c441430311feb29eba01a765bc6c48
> > > Author: Guillaume Munch 
> > > Date:   Tue Oct 11 12:09:38 2016 +0200
> > > 
> > > Move class definitions inside main class
> > > 
> > > Prepare for following commits.
> > > 
> > > This prevent's forward-declaration, but including the TexRow header 
> > > should be
> > > inexpensive.
> > 
> > This does not compile on cygwin:
> > 
> 
> Should be fixed now.

Confirmed. Thanks.

-- 
Enrico

Re: [LyX/master] Move class definitions inside main class

[Guillaume Munch]

Le 23/10/2016 à 00:09, Enrico Forestieri a écrit :

On Sat, Oct 22, 2016 at 11:26:15PM +0200, Guillaume Munch wrote:


commit 148b3ae773c441430311feb29eba01a765bc6c48
Author: Guillaume Munch 
Date:   Tue Oct 11 12:09:38 2016 +0200

Move class definitions inside main class

Prepare for following commits.

This prevent's forward-declaration, but including the TexRow header should 
be
inexpensive.


This does not compile on cygwin:



Should be fixed now.

Re: [LyX/master] Move class definitions inside main class

[Enrico Forestieri]

On Sat, Oct 22, 2016 at 11:26:15PM +0200, Guillaume Munch wrote:

> commit 148b3ae773c441430311feb29eba01a765bc6c48
> Author: Guillaume Munch 
> Date:   Tue Oct 11 12:09:38 2016 +0200
> 
> Move class definitions inside main class
> 
> Prepare for following commits.
> 
> This prevent's forward-declaration, but including the TexRow header 
> should be
> inexpensive.

This does not compile on cygwin:

  CXX  ErrorList.o
In file included from ../../src/ErrorList.h:15:0,
 from ../../src/ErrorList.cpp:13:
../../src/TexRow.h:240:12: error: field ‘str’ has incomplete type 
‘lyx::docstring {aka std::basic_string, std::allocator >}’
  docstring str;
^
In file included from ../../src/support/debug.h:18:0,
 from ../../src/TexRow.h:31,
 from ../../src/ErrorList.h:15,
 from ../../src/ErrorList.cpp:13:
../../src/support/strfwd.h:55:64: note: declaration of ‘lyx::docstring {aka 
class std::basic_string, 
std::allocator >}’
 template class basic_string;
^
make[4]: *** [Makefile:2430: ErrorList.o] Error 1

-- 
Enrico

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

[Guillaume Munch]

Le 19/10/2016 à 12:00, Jean-Marc Lasgouttes a écrit :


@@ -1388,8 +1388,15 @@ QVariant 
GuiWorkArea::inputMethodQuery(Qt::InputMethodQuery query) const

 void GuiWorkArea::updateWindowTitle()
 {
-   d->lyx_view_->updateWindowTitle(this);
-   titleChanged(this);
+   Buffer const & buf = bufferView().buffer();
+   if (buf.fileName() != d->file_name_ || buf.isReadonly() != d->read_only_
+   || buf.lyxvc().vcstatus() != d->vc_status_ || buf.isClean() != 
d->clean_) {
+   d->file_name_ = buf.fileName();
+   d->read_only_ = buf.isReadonly();
+   d->vc_status_ = buf.lyxvc().vcstatus();
+   d->clean_ = buf.isClean();
+   titleChanged(this);
+   }
 }





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

Re: Add Assumption to Theorems.inc

[Andrew Parsloe]

On 23/10/2016 4:48 a.m., Paul A. Rubin wrote:

On 10/21/2016 10:06 PM, Andrew Parsloe wrote:

Dear LyX developers,

I find myself needing an Assumption environment every now and again
and think it should be added to Theorems.inc and its relatives. (As
far as I can tell it isn't defined in any of the
Theorems-.inc included in the Resources/layouts folder.)
I've added it to a personal version of Theorems.inc, inserting it
after Fact in the list of environments provided there.

A use case is when one has an extended argument (a chapter perhaps) in
which this assumption is part of the background to the argument and
attention should be drawn to that fact, but either (a) it would be
tiresome and get in the way of understanding if one had to bloat every
assertion (theorem, proposition, lemma, etc.) with its explicit
inclusion, or (b) the argument isn't presented in theorem/proof form
but more informally as a discussion which is to be understood against
the background of the assumption.

Although I can't find an Assumption environment defined in any
Theorems-.inc file, Theorems-refprefix.inc does define the
prefix: assu.

Andrew

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


Assumption and Assumption* are in the Theorems-AMS-Extended module and
it's "by type" variant.

Paul


Thank you Paul. I thought I had looked at *all* the modules, but clearly 
hadn't.


Andrew

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

Re: [LyX/2.2.3-staging] Status and configure for 2.2.3.

[Guillaume Munch]

Le 21/09/2016 à 22:31, Richard Heck a écrit :

commit 076736369f11016e5ed5a0a7dec0a58fc610c608
Author: Richard Heck 
Date:   Wed Sep 21 16:30:58 2016 -0400

Status and configure for 2.2.3.
---


Hi Richard,

I have rebased 2.2.3-staging branch on top of 2.2.x. You can now safely
delete this branch. I think it was meant to be rebased immediately after
2.2.2 since you had already set up configure.ac in the above commit, but
the manual 3-way merges were safe and straightforward.

Guillaume

Re: Inverted colors for cursor

[Enrico Forestieri]

On Sat, Oct 22, 2016 at 04:49:35PM +0200, Jean-Marc Lasgouttes wrote:
> 
> As LyX stands now, it is often very difficult to put the mouse cursor
> between two insets, because insets, contrary to characters, are active
> beasts. If you click a bit to close to them, something happens. This is why
> some spacing has to be kept to some extent.

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

-- 
Enrico

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

[Guenter Milde]

On 2016-10-22, Jürgen Spitzmüller wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> Am Samstag, den 22.10.2016, 16:37 +0200 schrieb Jean-Marc Lasgouttes:
>> Le 22/10/2016 à 13:40, Enrico Forestieri a écrit :
>> > Moreover, we add a new entry "LyX Default", which corresponds
>> > to what is now the default (i.e, load fontenc with the value
>> > specified
>> > in Tools->Preferences->Output->LaTeX).

>> I still wonder why we should keep this preference.

> Me, too. I opt for removing it and giving the user the possibility to
> select from the following:

> LaTeX Font Encoding Selection:Automatic
>   Custom
>   None

Sounds reasonable.

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

> Custom would be all the user set himself and ignores all fontenc
> suggestions

> None would not do any fontenc calls whatsoever.

Günter

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

[Guenter Milde]

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

>> Le 22/10/2016 à 16:58, Enrico Forestieri a écrit :
>> > > I still wonder why we should keep this preference.
>> > 
>> > Good observation. I think for backward compatibility. Otherwise we
>> > don't know what was the old default. Suppose that a user unchecked
>> > that preference, meaning that no fontenc is loaded. If we miss this
>> > info, we should convert an old [Default] to T1 (the old default),
>> > thus screwing up old documents. The same if instead that was changed
>> > to OT1, for example.

>> I think that at some point we should remove it and describe what to do in
>> Release Notes for existing documents. What I do not know is whether a few
>> people will face much work to get their documents in good shape again.

> If you ask me, I think that 99.99% of users didn't change that default.
> If someone was needing a different encoding, it is much more likely that
> he stumbled upon the custom setting in the document settings dialog
> rather than that setting in the preferences.

I'd be cautious with such estimates. After all, the document specific
setting is just 8 years old and the 8 years before changing the
LyX wide default was the only option.

Users may have set it and never thougth about it for ages.

OTOH, even a 2012 an answer at stackexcange did only know about the global
setting. (I added a comment about the per-document setting when stumbling
across it yesterday.)

Günter

Re: Master is slow

[Richard Heck]

On 10/22/2016 01:39 PM, Guillaume Munch wrote:
> Le 18/10/2016 à 21:44, Guillaume Munch a écrit :
>>
>> Profiling shows that calls to BufferParams::isExportableFormat
>> are numerous and expensive when doing char-forward (33% of the total
>> amount of CPU). This is called from GuiView::updateToolbars ->
>> GuiView::getStatus. There is room for improvement, but this is not new
>> behaviour apparently.
>>
>> I also found that calls to TabWorkArea::updateTabTexts are
>> expensive and repeatedb. This amounts to 31% of the total amount of CPU,
>> shared between QTabWidget::setTabText and QTabWidget::setTabIcon.
>> TabWorkArea::updateTabTexts is connected to the signal
>> GuiWorkArea::titleChanged.
>>
>
>
> After improvements by Richard and Jean-Marc, GuiView::getStatus is down
> to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating.

Many of the to_utf8 calls are probably "FIXME Unicode", too.

> New bottlenecks are Buffer::updateMacros (25%, of course depends on
> the document) and nothing else looks really out of place. You can
> celebrate.

I've long wondered whether the updateMacros call in
BufferView::processUpdateFlags is really necessary. As I say in a FIXME
there: We call updateMacros in updateBuffer, and if the Buffer doesn't
need updating, will the macros? I'm morally certain, at least, that we
could at least include another flag that would tell us if they did need
updating. But I don't know enough about the macro machinery to be sure
when they do and when they do not.

That said, if anyone is brave enough to do so, we could try commenting
that line out and see what happens.

Richard

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

[Guenter Milde]

On 2016-10-22, Enrico Forestieri wrote:
> On Sat, Oct 22, 2016 at 05:16:49PM +0200, Jean-Marc Lasgouttes wrote:
>> Le 22/10/2016 à 17:15, Enrico Forestieri a écrit :
>> > If you ask me, I think that 99.99% of users didn't change that default.
>> > If someone was needing a different encoding, it is much more likely that
>> > he stumbled upon the custom setting in the document settings dialog
>> > rather than that setting in the preferences.

>> How bad can it become for someone who has changed the setting?

> The main differences between OT1 and T1 are explained here:
> http://tex.stackexchange.com/questions/664/why-should-i-use-usepackaget1fontenc

> If one changed it to OT1, now he would find that bitmapped fonts are
> being used. Most probably he did that for getting vector fonts and
> now his workaround is defeated.

This is something we could/should address in [Automatic].

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

This will normally not hurt, as LyX automatically adds T2A font encoding for
Cyrillic characters. 
The only (hypothetical) instance would be the selection in the
user preamble of a font that only exists in T2A encoding in documents with
parts in a Latin-written language.

Günter

Re: Master is slow

[Guillaume Munch]

Le 18/10/2016 à 21:44, Guillaume Munch a écrit :


Profiling shows that calls to BufferParams::isExportableFormat
are numerous and expensive when doing char-forward (33% of the total
amount of CPU). This is called from GuiView::updateToolbars ->
GuiView::getStatus. There is room for improvement, but this is not new
behaviour apparently.

I also found that calls to TabWorkArea::updateTabTexts are
expensive and repeatedb. This amounts to 31% of the total amount of CPU,
shared between QTabWidget::setTabText and QTabWidget::setTabIcon.
TabWorkArea::updateTabTexts is connected to the signal
GuiWorkArea::titleChanged.




After improvements by Richard and Jean-Marc, GuiView::getStatus is down
to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating.

New bottlenecks are Buffer::updateMacros (25%, of course depends on
the document) and nothing else looks really out of place. You can celebrate.

Daniel, is it still slow for you?

Re: Candidates for stable

[Richard Heck]

On 10/22/2016 01:32 PM, Jürgen Spitzmüller wrote:
> Am Samstag, den 15.10.2016, 11:11 +0200 schrieb Jürgen Spitzmüller:
>> * Improve bibliography info display:
>> http://www.lyx.org/trac/changeset/ba171930/lyxgit
>> http://www.lyx.org/trac/changeset/2c4673af/lyxgit
>> http://www.lyx.org/trac/changeset/1c725c91/lyxgit
>> http://www.lyx.org/trac/changeset/67da1431/lyxgit
>> http://www.lyx.org/trac/changeset/b941d939/lyxgit
>> http://www.lyx.org/trac/changeset/2267f4ae/lyxgit
>> http://www.lyx.org/trac/changeset/85f1259b/lyxgit
>> http://www.lyx.org/trac/changeset/b8486ba6/lyxgit
> Now only these are left. The fixes are rather cosmetic, but make the
> bibliography display actually useful with biblatex databases.
>
> Richard, if you agree on backporting, I would cherry-pick each of the
> above commits in their chronological order.
>
> After that, my stack for stable is empty for the time being.

OK, looks safe enough.

Richard

Re: Candidates for stable

[Jürgen Spitzmüller]

Am Samstag, den 15.10.2016, 11:11 +0200 schrieb Jürgen Spitzmüller:
> * Improve bibliography info display:
> http://www.lyx.org/trac/changeset/ba171930/lyxgit
> http://www.lyx.org/trac/changeset/2c4673af/lyxgit
> http://www.lyx.org/trac/changeset/1c725c91/lyxgit
> http://www.lyx.org/trac/changeset/67da1431/lyxgit
> http://www.lyx.org/trac/changeset/b941d939/lyxgit
> http://www.lyx.org/trac/changeset/2267f4ae/lyxgit
> http://www.lyx.org/trac/changeset/85f1259b/lyxgit
> http://www.lyx.org/trac/changeset/b8486ba6/lyxgit

Now only these are left. The fixes are rather cosmetic, but make the
bibliography display actually useful with biblatex databases.

Richard, if you agree on backporting, I would cherry-pick each of the
above commits in their chronological order.

After that, my stack for stable is empty for the time being.

Thanks
Jürgen

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

Re: [LyX/master] Remove unused methods in anononymous namespace

[Richard Heck]

On 10/22/2016 11:15 AM, Jean-Marc Lasgouttes wrote:
> Le 19/10/2016 à 17:52, Jean-Marc Lasgouttes a écrit :
>> commit 4065f596ada672c58787a0f9faa2278621545ab9
>> Author: Jean-Marc Lasgouttes 
>> Date:   Wed Oct 19 17:51:32 2016 +0200
>>
>> Remove unused methods in anononymous namespace
>>
>> These have been flagged by gcc 6.
>
> Richard, OK for 2.2.3?

Yes, sure.

Richard

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

[Jürgen Spitzmüller]

Am Samstag, den 22.10.2016, 18:41 +0200 schrieb Enrico Forestieri:
> The main differences between OT1 and T1 are explained here:
> http://tex.stackexchange.com/questions/664/why-should-i-use-usepackag
> et1fontenc
> 
> If one changed it to OT1, now he would find that bitmapped fonts are
> being used. Most probably he did that for getting vector fonts and
> now his workaround is defeated.
> 
> However, more damage can result if one selected T2A as a default
> and the default setting is converted to T1 due to lack of that info.

If we use automatic setting as default, as I suggested, I don't think
that anything really serious can happen.

Jürgen

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

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

[Enrico Forestieri]

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

> Le 22/10/2016 à 17:15, Enrico Forestieri a écrit :
> > If you ask me, I think that 99.99% of users didn't change that default.
> > If someone was needing a different encoding, it is much more likely that
> > he stumbled upon the custom setting in the document settings dialog
> > rather than that setting in the preferences.
> 
> How bad can it become for someone who has changed the setting?

The main differences between OT1 and T1 are explained here:
http://tex.stackexchange.com/questions/664/why-should-i-use-usepackaget1fontenc

If one changed it to OT1, now he would find that bitmapped fonts are
being used. Most probably he did that for getting vector fonts and
now his workaround is defeated.

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

-- 
Enrico

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 16:31, Joel Kulesza wrote:

On Sat, Oct 22, 2016 at 8:19 AM, racoon > wrote:

One question: would it be helpful if one could choose copy,
paste, delete, etc. from the inset button's context menu?


I don't see how this could hurt.  My workflow now is usually to position
the cursor in front of the element I want, shift, right arrow, and
hotkey cut/copy. It works reasonably well for me.

See attached for a couple screenshots of regions where this comes into
play.  To me, it seems narrow already (note that on a non 4K/5K monitor,
this will likely look huge; however scale until the font is 11pt and
you'll see the narrowness).  The screenshot where the cursor is within
the frontmatter inset before the ERT is part of where my concern lies in
the figure->subfigures case (and especially if TikZ is being used for
the subfigures).  At that point, there are lots of nested boxes to
navigate around.


Thanks. Yes, the idea is actually to have different offsets for outer 
and inner spaces. So spaces within insets, like where the cursor is in 
your second screen shot will not disappear. Right now the spaces are set 
to a fixed amount of pixel which leads to a dilemma: either it is hard 
to distinguish from a space on low res screens or it is too small on 
high res screens. We'll see, maybe this can be resolved by having 
scalable spaces. JMarc already paved the way a bit.


Daniel

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

[Guillaume Munch]

Le 22/10/2016 à 17:16, Jean-Marc Lasgouttes a écrit :

Le 22/10/2016 à 17:15, Enrico Forestieri a écrit :

If you ask me, I think that 99.99% of users didn't change that default.
If someone was needing a different encoding, it is much more likely that
he stumbled upon the custom setting in the document settings dialog
rather than that setting in the preferences.


How bad can it become for someone who has changed the setting?



The setting can just be deprecated and hidden, instead of removed
straight away. New versions of LyX would save the former global default
with the file after conversion.

The only bad case is if the file is open and converted on an
installation with a global setting the document was not made for. But
this is only the issue we already have.

Re: Inverted colors for cursor

[Guillaume Munch]

Le 22/10/2016 à 15:20, racoon a écrit :

However, I am at the moment considering to change LyX's spacing such
that the cursor before an element starts directly at the element. As is
the case with normal characters. It is just a thought for now. This
would only be sensible when the cursor automatically changes color when
placed at a border because it would become (almost) invisible otherwise.


Thanks for the inverted cursor, I find this idea sensible. I like the 
one above less though.



I guess, even these spacing setting could be a setting in the
preference. We'll see.


Please, let us try to find sensible defaults instead of introducing new
settings.

Re: Add Assumption to Theorems.inc

[Paul A. Rubin]

On 10/21/2016 10:06 PM, Andrew Parsloe wrote:

Dear LyX developers,

I find myself needing an Assumption environment every now and again 
and think it should be added to Theorems.inc and its relatives. (As 
far as I can tell it isn't defined in any of the 
Theorems-.inc included in the Resources/layouts folder.) 
I've added it to a personal version of Theorems.inc, inserting it 
after Fact in the list of environments provided there.


A use case is when one has an extended argument (a chapter perhaps) in 
which this assumption is part of the background to the argument and 
attention should be drawn to that fact, but either (a) it would be 
tiresome and get in the way of understanding if one had to bloat every 
assertion (theorem, proposition, lemma, etc.) with its explicit 
inclusion, or (b) the argument isn't presented in theorem/proof form 
but more informally as a discussion which is to be understood against 
the background of the assumption.


Although I can't find an Assumption environment defined in any 
Theorems-.inc file, Theorems-refprefix.inc does define the 
prefix: assu.


Andrew

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

Assumption and Assumption* are in the Theorems-AMS-Extended module and 
it's "by type" variant.


Paul

Re: For $100, would you change a default font?

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 05:35, Paul Johnson a écrit :

I use LyX all the time. I love it and encourage everybody to try it.

I usually get great results.Except when I am in a hurry and forget to
change default fonts. In particular, I've been stung by the combination
of the listings class and default typewriter font.  Last week,  I threw
in a lot of R code with "<-" printed to pdf as "< ". There were
invisible dashes. I did not notice and printed handouts for a group.
Other symbols have gone missing, sometimes ~ in verbatim class is invisible.


I am surprised. Could you provide an example? But I understand the 
frustration when printouts made in a hurry come out wrong. Lastly, it 
was the printer which happily printed PDFs from an usb key, but without 
accents and ligatures :)


JMarc

Re: [LyX/master] Update local boost version to version 1.62

[Jean-Marc Lasgouttes]

Le 21/10/2016 à 18:02, Richard Heck a écrit :

What shall we do about 2.2.x? The warnings with gcc 6 are annoying, so
I guess we will eventually have to update for branch.


They are indeed annoying. This seems a good time to do it for stable,
since we just did a release and have lots of time for testing.


Done now.

JMarc

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

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 17:15, Enrico Forestieri a écrit :

If you ask me, I think that 99.99% of users didn't change that default.
If someone was needing a different encoding, it is much more likely that
he stumbled upon the custom setting in the document settings dialog
rather than that setting in the preferences.


How bad can it become for someone who has changed the setting?

JMarc

Re: [LyX/master] Remove unused methods in anononymous namespace

[Jean-Marc Lasgouttes]

Le 19/10/2016 à 17:52, Jean-Marc Lasgouttes a écrit :

commit 4065f596ada672c58787a0f9faa2278621545ab9
Author: Jean-Marc Lasgouttes 
Date:   Wed Oct 19 17:51:32 2016 +0200

Remove unused methods in anononymous namespace

These have been flagged by gcc 6.


Richard, OK for 2.2.3?

JMarc




---
 src/frontends/qt4/Menus.cpp|8 
 src/mathed/MathAutoCorrect.cpp |   14 +++---
 src/mathed/MathParser.cpp  |   18 --
 3 files changed, 7 insertions(+), 33 deletions(-)

diff --git a/src/frontends/qt4/Menus.cpp b/src/frontends/qt4/Menus.cpp
index 78639b9..da1160a 100644
--- a/src/frontends/qt4/Menus.cpp
+++ b/src/frontends/qt4/Menus.cpp
@@ -319,8 +319,6 @@ public:
///
size_t size() const { return items_.size(); }
///
-   MenuItem const & operator[](size_t) const;
-   ///
const_iterator begin() const { return items_.begin(); }
///
const_iterator end() const { return items_.end(); }
@@ -682,12 +680,6 @@ void MenuDefinition::read(Lexer & lex)
 }


-MenuItem const & MenuDefinition::operator[](size_type i) const
-{
-   return items_[i];
-}
-
-
 bool MenuDefinition::hasFunc(FuncRequest const & func) const
 {
for (const_iterator it = begin(), et = end(); it != et; ++it)
diff --git a/src/mathed/MathAutoCorrect.cpp b/src/mathed/MathAutoCorrect.cpp
index 2af6c4b..1743111 100644
--- a/src/mathed/MathAutoCorrect.cpp
+++ b/src/mathed/MathAutoCorrect.cpp
@@ -75,13 +75,6 @@ bool Correction::read(idocstream & is)
 }


-void Correction::write(odocstream & os) const
-{
-   os << "from: '" << from1_ << "' and '" << from2_
-  << "' to '" << to_ << '\'' << endl;
-}
-
-
 bool Correction::correct(MathAtom & at, char_type c) const
 {
//LYXERR(Debug::MATHED,
@@ -98,6 +91,13 @@ bool Correction::correct(MathAtom & at, char_type c) const


 #if 0
+void Correction::write(odocstream & os) const
+{
+   os << "from: '" << from1_ << "' and '" << from2_
+  << "' to '" << to_ << '\'' << endl;
+}
+
+
 idocstream & operator>>(idocstream & is, Correction & corr)
 {
corr.read(is);
diff --git a/src/mathed/MathParser.cpp b/src/mathed/MathParser.cpp
index 1e615d2..4b0e538 100644
--- a/src/mathed/MathParser.cpp
+++ b/src/mathed/MathParser.cpp
@@ -401,8 +401,6 @@ public:
bool parse1(InsetMathGrid & grid, unsigned flags, mode_type mode,
bool numbered);
///
-   MathData parse(unsigned flags, mode_type mode);
-   ///
int lineno() const { return lineno_; }
///
void putback();
@@ -435,8 +433,6 @@ private:
///
void push_back(Token const & t);
///
-   void pop_back();
-   ///
Token const & prevToken() const;
///
Token const & nextToken() const;
@@ -501,12 +497,6 @@ void Parser::push_back(Token const & t)
 }


-void Parser::pop_back()
-{
-   tokens_.pop_back();
-}
-
-
 Token const & Parser::prevToken() const
 {
static const Token dummy;
@@ -786,14 +776,6 @@ docstring Parser::parse_verbatim_item()
 }


-MathData Parser::parse(unsigned flags, mode_type mode)
-{
-   MathData ar(buffer_);
-   parse(ar, flags, mode);
-   return ar;
-}
-
-
 bool Parser::parse(MathData & array, unsigned flags, mode_type mode)
 {
InsetMathGrid grid(buffer_, 1, 1);

Re: Inverted colors for cursor

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 17:08, racoon a écrit :

But I guess one could argue that this is a WYSIWYG thing and the only
thing we need in LyX is to clearly see whether a space is a "real" space
or not.


We can allow for spacing as long as it is smaller enough than interword 
space. What needs to be done is really dependent on the inset. I hope to 
land soon a rewrite of mathed spacing that will be helpful in this 
respect, but there is still a lot if extra space around formulas that 
can be problematic. The Superscrit/subscript text inset is bad in this 
respect too.


JMarc

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

[Enrico Forestieri]

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

> Le 22/10/2016 à 16:58, Enrico Forestieri a écrit :
> > > I still wonder why we should keep this preference.
> > 
> > Good observation. I think for backward compatibility. Otherwise we
> > don't know what was the old default. Suppose that a user unchecked
> > that preference, meaning that no fontenc is loaded. If we miss this
> > info, we should convert an old [Default] to T1 (the old default),
> > thus screwing up old documents. The same if instead that was changed
> > to OT1, for example.
> 
> I think that at some point we should remove it and describe what to do in
> Release Notes for existing documents. What I do not know is whether a few
> people will face much work to get their documents in good shape again.

If you ask me, I think that 99.99% of users didn't change that default.
If someone was needing a different encoding, it is much more likely that
he stumbled upon the custom setting in the document settings dialog
rather than that setting in the preferences. 

-- 
Enrico

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 17:07, racoon wrote:

On 22.10.2016 17:02, Jean-Marc Lasgouttes wrote:

Le 22/10/2016 à 16:57, racoon a écrit :

The cursor policy isn't fancy but just what other writer apps have. That
is also where I had the idea about treating insets as characters is
from. But as I said, this is just something to consider. You seem to
suggest it's a bad idea. :)


Can you point me to a way to see this with LibreOffice, so that I see
how it behaves?


Sure. Insert a graphic (small or resize it so two graphics would fit
next to each other) and set it's anchor to "As Character", e.g. via the
context menu. Then copy it and paste it so there are two next to each
other.


But I guess one could argue that this is a WYSIWYG thing and the only 
thing we need in LyX is to clearly see whether a space is a "real" space 
or not.

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 17:02, Jean-Marc Lasgouttes wrote:

Le 22/10/2016 à 16:57, racoon a écrit :

The cursor policy isn't fancy but just what other writer apps have. That
is also where I had the idea about treating insets as characters is
from. But as I said, this is just something to consider. You seem to
suggest it's a bad idea. :)


Can you point me to a way to see this with LibreOffice, so that I see
how it behaves?


Sure. Insert a graphic (small or resize it so two graphics would fit 
next to each other) and set it's anchor to "As Character", e.g. via the 
context menu. Then copy it and paste it so there are two next to each other.


Daniel

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

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 16:58, Enrico Forestieri a écrit :

I still wonder why we should keep this preference.


Good observation. I think for backward compatibility. Otherwise we
don't know what was the old default. Suppose that a user unchecked
that preference, meaning that no fontenc is loaded. If we miss this
info, we should convert an old [Default] to T1 (the old default),
thus screwing up old documents. The same if instead that was changed
to OT1, for example.


I think that at some point we should remove it and describe what to do 
in Release Notes for existing documents. What I do not know is whether a 
few people will face much work to get their documents in good shape again.


JMarc

Re: Inverted colors for cursor

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 16:57, racoon a écrit :

The cursor policy isn't fancy but just what other writer apps have. That
is also where I had the idea about treating insets as characters is
from. But as I said, this is just something to consider. You seem to
suggest it's a bad idea. :)


Can you point me to a way to see this with LibreOffice, so that I see 
how it behaves?


JMarc

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

[Jürgen Spitzmüller]

Am Samstag, den 22.10.2016, 16:37 +0200 schrieb Jean-Marc Lasgouttes:
> Le 22/10/2016 à 13:40, Enrico Forestieri a écrit :
> > Moreover, we add a new entry "LyX Default", which corresponds
> > to what is now the default (i.e, load fontenc with the value
> > specified
> > in Tools->Preferences->Output->LaTeX).
> 
> I still wonder why we should keep this preference.

Me, too. I opt for removing it and giving the user the possibility to
select from the following:

LaTeX Font Encoding Selection:  Automatic
Custom
None

The first option (which should be the default, IMHO) uses whatever font
encoding is considered appropriate for the given language(s) and
backend. We determine that via the fontenc option in languages.

Custom would be all the user set himself and ignores all fontenc
suggestions

None would not do any fontenc calls whatsoever.

Jürgen

> 
> JMarc
> 

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

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

[Enrico Forestieri]

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

> Le 22/10/2016 à 13:40, Enrico Forestieri a écrit :
> > Moreover, we add a new entry "LyX Default", which corresponds
> > to what is now the default (i.e, load fontenc with the value specified
> > in Tools->Preferences->Output->LaTeX).
> 
> I still wonder why we should keep this preference.

Good observation. I think for backward compatibility. Otherwise we
don't know what was the old default. Suppose that a user unchecked
that preference, meaning that no fontenc is loaded. If we miss this
info, we should convert an old [Default] to T1 (the old default),
thus screwing up old documents. The same if instead that was changed
to OT1, for example.

OTOH, that global preference is dangerous, because if someone sends
you a document expecting a given fontenc (achieved by the sender by
changing this pref) and you have a different default, everything may
screw up. So, having this as a globlal preference is not ideal,
apparently.

-- 
Enrico

Re: Inverted colors for cursor

[racoon]

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

Le 22/10/2016 à 15:20, racoon a écrit :

However, I am at the moment considering to change LyX's spacing such
that the cursor before an element starts directly at the element. As is
the case with normal characters. It is just a thought for now. This
would only be sensible when the cursor automatically changes color when
placed at a border because it would become (almost) invisible otherwise.
I guess, even these spacing setting could be a setting in the
preference. We'll see.


I think this is a too radical solution. The is some space between
characters and there should be some space etween insets and other stuff.
I understand the problem of extra space around insets, but when it makes
you enforce new fancy cursor policies, then you know this is going too
far :)


The cursor policy isn't fancy but just what other writer apps have. That 
is also where I had the idea about treating insets as characters is 
from. But as I said, this is just something to consider. You seem to 
suggest it's a bad idea. :)


Daniel

Re: Some inset offset fine tuning

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 11:33, racoon a écrit :

Does anyone happen to know where the area of insets for clicks and hover
with the mouse is set? I don't mean the paintings but the interaction.
There seem to be several problems with it I could have a look at.

1. The area if off by a couple of pixels, i.e. translated to the right.
2. The area includes the spaces around the insets.


Normally, the area is the whole dimension of the inset, that is 
everything that is added in metrics() method. For layout and mouse 
purpose, an inset is defined by its (x, y) position and its dimension.


What you describe can happen when metrics() computes in one way, but 
draw() uses different logic to compute offsets.


JMarc

Re: Inverted colors for cursor

[Jean-Marc Lasgouttes]

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

On 22.10.2016 14:38, Joel Kulesza wrote:

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


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


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


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


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


JMarc

Re: Inverted colors for cursor

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 15:20, racoon a écrit :

However, I am at the moment considering to change LyX's spacing such
that the cursor before an element starts directly at the element. As is
the case with normal characters. It is just a thought for now. This
would only be sensible when the cursor automatically changes color when
placed at a border because it would become (almost) invisible otherwise.
I guess, even these spacing setting could be a setting in the
preference. We'll see.


I think this is a too radical solution. The is some space between 
characters and there should be some space etween insets and other stuff. 
I understand the problem of extra space around insets, but when it makes 
you enforce new fancy cursor policies, then you know this is going too 
far :)


JMarc

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

[Jean-Marc Lasgouttes]

Le 22/10/2016 à 13:40, Enrico Forestieri a écrit :

Moreover, we add a new entry "LyX Default", which corresponds
to what is now the default (i.e, load fontenc with the value specified
in Tools->Preferences->Output->LaTeX).


I still wonder why we should keep this preference.

JMarc

Re: Inverted colors for cursor

[Joel Kulesza]

On Sat, Oct 22, 2016 at 8:19 AM, racoon  wrote:

> One question: would it be helpful if one could choose copy, paste, delete,
>> etc. from the inset button's context menu?
>>
>
I don't see how this could hurt.  My workflow now is usually to position
the cursor in front of the element I want, shift, right arrow, and hotkey
cut/copy. It works reasonably well for me.

See attached for a couple screenshots of regions where this comes into
play.  To me, it seems narrow already (note that on a non 4K/5K monitor,
this will likely look huge; however scale until the font is 11pt and you'll
see the narrowness).  The screenshot where the cursor is within the
frontmatter inset before the ERT is part of where my concern lies in the
figure->subfigures case (and especially if TikZ is being used for the
subfigures).  At that point, there are lots of nested boxes to navigate
around.

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 15:59, Joel Kulesza wrote:

On Sat, Oct 22, 2016 at 7:55 AM, racoon > wrote:


The benefit of removing (or almost removing) space around insets is
to make sure it is not mistaken for a "real" space. Since many
insets are working just like characters it seems reasonable to make
the spacing around them similar.


I see, fair enough.


Yes, the selecting is already a bit tricky. But maybe that can be
fixed as well...


Yes, please make sure this is sufficiently handled before being
released.  As a user of a 4K monitor at work and 5K at home: making
things more narrow / pixel-measured concerns me.  If OS X builds can be
made available, I'd be happy to help test / provide feedback.


Yes, selecting an inset with the mouse is generally cumbersome. One 
question: would it be helpful if one could choose copy, paste, delete, 
etc. from the inset button's context menu?

Re: Inverted colors for cursor

[Joel Kulesza]

On Sat, Oct 22, 2016 at 7:55 AM, racoon  wrote:
>
>
> The benefit of removing (or almost removing) space around insets is to
> make sure it is not mistaken for a "real" space. Since many insets are
> working just like characters it seems reasonable to make the spacing around
> them similar.
>

I see, fair enough.


> Yes, the selecting is already a bit tricky. But maybe that can be fixed as
> well...
>

Yes, please make sure this is sufficiently handled before being released.
As a user of a 4K monitor at work and 5K at home: making things more narrow
/ pixel-measured concerns me.  If OS X builds can be made available, I'd be
happy to help test / provide feedback.

Thanks for taking an active development role lately on such varied items.
It's great to see!  My hope is that once I complete my degree I can do the
same.

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 15:47, Joel Kulesza wrote:

On Sat, Oct 22, 2016 at 7:20 AM, racoon > wrote:


However, I am at the moment considering to change LyX's spacing such
that the cursor before an element starts directly at the element. As
is the case with normal characters. It is just a thought for now.
This would only be sensible when the cursor automatically changes
color when placed at a border because it would become (almost)
invisible otherwise. I guess, even these spacing setting could be a
setting in the preference. We'll see.


That's an interesting thought, but I'll admit I'm having a hard time
visualizing it.  What benefit do you see from the modified spacing?
Wouldn't putting the two things closer together make it yet harder to
see?  How will this effect selecting things (will one have to be even
more precise)?


The benefit of removing (or almost removing) space around insets is to 
make sure it is not mistaken for a "real" space. Since many insets are 
working just like characters it seems reasonable to make the spacing 
around them similar.


Yes, the selecting is already a bit tricky. But maybe that can be fixed 
as well...


Daniel

Re: Inverted colors for cursor

[Joel Kulesza]

On Sat, Oct 22, 2016 at 7:20 AM, racoon  wrote:

>
> However, I am at the moment considering to change LyX's spacing such that
> the cursor before an element starts directly at the element. As is the case
> with normal characters. It is just a thought for now. This would only be
> sensible when the cursor automatically changes color when placed at a
> border because it would become (almost) invisible otherwise. I guess, even
> these spacing setting could be a setting in the preference. We'll see.
>

That's an interesting thought, but I'll admit I'm having a hard time
visualizing it.  What benefit do you see from the modified spacing?
Wouldn't putting the two things closer together make it yet harder to see?
How will this effect selecting things (will one have to be even more
precise)?

Re: [patch] support for Asturian etc.

[Uwe Stöhr]

Am 21.10.2016 um 01:58 schrieb Uwe Stöhr:


There are in fact 4 such languages that are not RTL/BiDi. Attached is
therefore a better patch with support for these.


OK, it is now in. Since all languages are non-RTL, they behave like all 
other languages supported in polyglossia but not babel.


The Python masters perhaps know a cleaner solution for the lyx2lyx 
reversion code. However the reversion works and assures that the output 
would have the correct language.


regards Uwe

Re: For $100, would you change a default font?

[Uwe Stöhr]

Am 22.10.2016 um 08:43 schrieb Jürgen Spitzmüller:


Why don't you simply set your preferred "default font" and hit "Save as
Document Defaults"?
Then this will be _your_ personal default.


Hi Paul,

now that you got what you wanted for free, maybe you want to support LyX 
anyway with a donation? ;)

http://www.lyx.org/Donate

regards Uwe

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 15:10, Joel Kulesza wrote:

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

Daniel

On Sat, Oct 22, 2016 at 6:54 AM, Joel Kulesza > wrote:

Why not let inversion be the default behavior and then let users
choose?  Perhaps I want my cursor to also stand out from my text...


 Sorry for top-posting the prior couple comments, early-morning
emailing, habit, and default interface behavior all stymie me.

Regardless, to expound a bit on the previous reply: my overarching point
is that developers providing what they believe to be the most sensible
defaults is quite reasonable.  However, preventing (or perhaps worse:
taking away) the ability for a user to change it to his/her preference
does not seem reasonable (the user may have a different belief in what
is "most sensible").

Furthermore, because the option is currently there, folks might miss it
if/when removed/disabled.  It's also not clear to me what significant
savings is made by removing the option to choose the color versus
allowing it to interact gracefully with the background / cursor color
relationship.  Use case scenarios:

 1. Set the background, it updates the cursor to be the inverse,
notifies the user (since they are already in the dialog), and the
user can then update the cursor to the preferred color
 2. Set the cursor, and it changes.

Adding one additional notification doesn't seem like much a burden to
the user vs. the savings gained when a user wonders "why did my cursor
change?"  This is so because I would suspect users aren't changing the
background color very often.


Thanks. Yes, it would be possible to make it default and leave it up to 
the user to disable this setting.


However, I am at the moment considering to change LyX's spacing such 
that the cursor before an element starts directly at the element. As is 
the case with normal characters. It is just a thought for now. This 
would only be sensible when the cursor automatically changes color when 
placed at a border because it would become (almost) invisible otherwise. 
I guess, even these spacing setting could be a setting in the 
preference. We'll see.


Daniel

Re: Inverted colors for cursor

[Joel Kulesza]

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

Daniel

On Sat, Oct 22, 2016 at 6:54 AM, Joel Kulesza  wrote:

> Why not let inversion be the default behavior and then let users choose?
> Perhaps I want my cursor to also stand out from my text...
>

 Sorry for top-posting the prior couple comments, early-morning emailing,
habit, and default interface behavior all stymie me.

Regardless, to expound a bit on the previous reply: my overarching point is
that developers providing what they believe to be the most sensible
defaults is quite reasonable.  However, preventing (or perhaps worse:
taking away) the ability for a user to change it to his/her preference does
not seem reasonable (the user may have a different belief in what is "most
sensible").

Furthermore, because the option is currently there, folks might miss it
if/when removed/disabled.  It's also not clear to me what significant
savings is made by removing the option to choose the color versus allowing
it to interact gracefully with the background / cursor color relationship.
Use case scenarios:

   1. Set the background, it updates the cursor to be the inverse, notifies
   the user (since they are already in the dialog), and the user can then
   update the cursor to the preferred color
   2. Set the cursor, and it changes.

Adding one additional notification doesn't seem like much a burden to the
user vs. the savings gained when a user wonders "why did my cursor change?"
 This is so because I would suspect users aren't changing the background
color very often.

Re: Inverted colors for cursor

[Joel Kulesza]

Why not let inversion be the default behavior and then let users choose?
Perhaps I want my cursor to also stand out from my text...

On Sat, Oct 22, 2016 at 6:53 AM, racoon  wrote:

> On 22.10.2016 14:38, Joel Kulesza wrote:
>
>> With the ability to tweak the cursor color, I agree with Daniel's
>> suggestion to implement the inverted color patch.
>>
>
> Sorry, I did not make myself clear before. I am suggesting to not let the
> user choose the cursor color but instead enforce inverted color. I think an
> inverted cursor has the benefit of being visible in any situation while the
> downsides seem small. I think most people are either working with a very
> light or very dark background. In that case the cursor would be almost
> black or almost white, respectively. I think that is the setting most
> people use anyway.
>
> Daniel
>
> On Sat, Oct 22, 2016 at 5:07 AM, racoon > > wrote:
>>
>> I am confused now. Yes, you can change the cursor color in the
>> current version of LyX. And the checked Use System Settings checkbox
>> is visible in Joel's screenshot. If it is unchecked the cursor color
>> can be changed. But I suggest to abandon this option and go for an
>> inverted cursor color.
>>
>> Daniel
>>
>>
>> On 22.10.2016 12:11, Jean-Marc Lasgouttes wrote:
>>
>> Then it would mean that the change can be done in system prefs.
>>
>> JMarc
>>
>> Le 22 octobre 2016 08:42:18 GMT+02:00, racoon > > a écrit :
>>
>> Wait a sec. Might be that this is because you use system
>> colors?
>>
>>
>> Daniel
>>
>>
>>
>>

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 14:38, Joel Kulesza wrote:

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


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


Daniel


On Sat, Oct 22, 2016 at 5:07 AM, racoon > wrote:

I am confused now. Yes, you can change the cursor color in the
current version of LyX. And the checked Use System Settings checkbox
is visible in Joel's screenshot. If it is unchecked the cursor color
can be changed. But I suggest to abandon this option and go for an
inverted cursor color.

Daniel


On 22.10.2016 12:11, Jean-Marc Lasgouttes wrote:

Then it would mean that the change can be done in system prefs.

JMarc

Le 22 octobre 2016 08:42:18 GMT+02:00, racoon > a écrit :

Wait a sec. Might be that this is because you use system
colors?


Daniel

Re: Inverted colors for cursor

[Joel Kulesza]

Interesting, yes, the options are different when that checkbox is selected
(I would have expected them to remain the same but be overridden by the
system colors).  Furthermore, unchecking that box (which is checked, by
default, I believe), permits me to change colors for items like the shaded
box (that I reported on in Ticket 10420).

I will update the ticket with a suggestion to "grey out" the color box when
System Colors is checked.  This should direct users to the right place
and/or right option to enable/disable.

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

On Sat, Oct 22, 2016 at 5:07 AM, racoon  wrote:

> I am confused now. Yes, you can change the cursor color in the current
> version of LyX. And the checked Use System Settings checkbox is visible in
> Joel's screenshot. If it is unchecked the cursor color can be changed. But
> I suggest to abandon this option and go for an inverted cursor color.
>
> Daniel
>
>
> On 22.10.2016 12:11, Jean-Marc Lasgouttes wrote:
>
>> Then it would mean that the change can be done in system prefs.
>>
>> JMarc
>>
>> Le 22 octobre 2016 08:42:18 GMT+02:00, racoon  a écrit :
>>
>>> Wait a sec. Might be that this is because you use system colors?

>>>
>>> Daniel
>>>
>>
>>

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

[Enrico Forestieri]

On Fri, Oct 21, 2016 at 11:16:30PM +, Guenter Milde wrote:

> On 2016-10-21, Enrico Forestieri wrote:
> > On Fri, Oct 21, 2016 at 07:05:29PM +, Guenter Milde wrote:
> >> On 2016-10-21, Enrico Forestieri wrote:
> 
> >> > I think that the old "None (no fontenc)" was more than adequate.
> >> > This tells that *LyX* is not going to select any encoding.
> 
> >> However, it was inconsistent. The same font dialog uses [Default] when
> >> LyX is not going to select any font. Also the internal name is
> >> "default".
> 
> > It is because the default encoding has been T1 since ever. I also think
> > that it is unfortunate that selecting everything to be default, instead
> > one finds that lyx is not producing a pristine latex file such as
> > \documentclass{article}
> > \begin{document}
> > \end{document}
> > but this is historical. Each program has his quirks, and this one has
> > been there since the beginning. 
> 
> Until 2008, "default" meant unequivocally "pristine latex". 
> LyX provided only a LyX-wide setting
> Tools>Preferences>Output>LaTeX>Use_LaTeX_font_encoding. Allowed values
> were a comma-separted list of font encodings or the special value
> "default" for "don't load fontenc".
> 
> Confusion started, when per-document fontenc setting was added in
> [df329341a/lyxgit] to fix bug #5730. As the LyX-wide setting was kept, we
> ended up with two defaults: the LyX-wide setting and the LaTeX (or
> documentclass) default.
> 
> Unfortunatly, the GUI name "Default" was chosen for the LyX-wide default.
> Since then, selecting "Default" in the font encoding GUI inserts
> additional code and usually leads to a font encoding differing from the
> document class default.
>   
> > This is something that one gets accustomed to. Expert users know how to
> > deal with it, 
> 
> Even experts and developers get this wrong:
> 
> E.g. Ticket #7334 "bitmapped fonts are still default" was closed as "wontfix"
> with the comment
> 
>we have the policy to not alter the class defaults (by default).
> 
> However, the problem is actually caused by the font encoding deviating from
> the class default. Sticking to the policy would have solved it (but
> created others).
> 
> > while novices don't mind and only want something that
> > works and looks good.
> 
> Documents with LyX's default settings still use bitmap fonts and don't
> look good (unless you installed CM-Super).
> 
> ...
> 
> > Given what said above, having "LyX Default" instead of simply
> > "Default" may be Ok (to differentiate from a consistency point of
> > view), but another default (Class default) without any classification
> > can be confusing. 
> 
> > So, it would be better to add "(no fontenc)", but then I still think
> > that "None (no fontenc)" is better and doesn't need to be deciphered
> > because it has always been like that. 
> 
> I prefer keeping "Default" in both GUI names, because the first ensures
> compatiblity with the current naming and the second with the "Default"s
> in the lines below. In a complex situation, confused is better than
> misled.
> 
> > Hence, old users know what it means, 
> 
> My experience is that many old users got it wrong all the time...
> 
> > while new users will learn its meaning. For them, having "Class
> > default" is not any clear and more confusing, IMHO.
> 
> This was Jürgens choice, my preference is "LaTeX Default" with a tooltip: 
> 
>   Use the documentclass' default encoding, don't load the fontspec package
> 
> Jürgen pointed out, that "no fontenc" may be misleading, as fontenc
> could be loaded by a package or the document class. I could live with 
> "LaTeX Default (no fontenc)" as a pragmatic way to tell users where to
> click to avoid fontenc loading by LyX.

Thanks for this detailed explanation. It makes clearer to me your
rationale. Now I agree with you and make an even more radical proposal.
Let's leave [Default] as the default, but now [Default] means
"LaTeX default", i.e., no fontenc. In other words we rename
"None (no fontenc)" to "Default" and make it the default (sorry for the
pun). Moreover, we add a new entry "LyX Default", which corresponds
to what is now the default (i.e, load fontenc with the value specified
in Tools->Preferences->Output->LaTeX). Of course, this means that a
lyx2lyx conversion has to be added, so that documents produced with
previous versions have their [Default] changed to [LyX Default].
In this way, new documents get no fontenc loading by default and
old documents continue working as usual. Who likes to always load
fontenc, can open Document->Settings, select [LyX Default] and
"Save as Document Defaults" their choice.

This is the cleanest way to proceed, IMHO.

-- 
Enrico

Re: Inverted colors for cursor

[racoon]

I am confused now. Yes, you can change the cursor color in the current 
version of LyX. And the checked Use System Settings checkbox is visible 
in Joel's screenshot. If it is unchecked the cursor color can be 
changed. But I suggest to abandon this option and go for an inverted 
cursor color.


Daniel

On 22.10.2016 12:11, Jean-Marc Lasgouttes wrote:

Then it would mean that the change can be done in system prefs.

JMarc

Le 22 octobre 2016 08:42:18 GMT+02:00, racoon  a écrit :

Wait a sec. Might be that this is because you use system colors?


Daniel

Re: Inverted colors for cursor

[Jean-Marc Lasgouttes]

Then it would mean that the change can be done in system prefs.

JMarc

Le 22 octobre 2016 08:42:18 GMT+02:00, racoon  a écrit :
>>Wait a sec. Might be that this is because you use system colors?
>
>Daniel

Re: Some inset offset fine tuning

[racoon]

On 21.10.2016 16:29, Jean-Marc Lasgouttes wrote:

Le 21/10/2016 à 16:18, racoon a écrit :

Just an update of the fix. No work done on the scaling yet or other
insets yet. But I realised that the cursor takes the space of the first
pixels of the character. So the space between insets has at least to be
two rather than one pixel wide. I have also attached my test file. I
have tested an measured now without anti-aliasing.


A question: I still see some 1 pixel explicit offset. What is it?
Cursor? Note that cursor width can be tuned in the preferences.

Even if scaling is not  in scope yet, it would be nice to understand
what each pixel value is and how it should scale. For example, I tend to
think that al borders (default width) should have a scalable width.
Maybe cursor too.


Does anyone happen to know where the area of insets for clicks and hover 
with the mouse is set? I don't mean the paintings but the interaction. 
There seem to be several problems with it I could have a look at.


1. The area if off by a couple of pixels, i.e. translated to the right.
2. The area includes the spaces around the insets.

Daniel

Re: For $100, would you change a default font?

[Jürgen Spitzmüller]

Am Freitag, den 21.10.2016, 22:35 -0500 schrieb Paul Johnson:
> I use LyX all the time. I love it and encourage everybody to try it. 
> 
> I usually get great results.Except when I am in a hurry and forget to
> change default fonts. In particular, I've been stung by the
> combination of the listings class and default typewriter font.  Last
> week,  I threw in a lot of R code with "<-" printed to pdf as "< ".
> There were invisible dashes. I did not notice and printed handouts
> for a group. Other symbols have gone missing, sometimes ~ in verbatim
> class is invisible.
> 
> It is easy to fix by setting typewriter to Latin modern or other
> font, but in an emergency, I always forget.

Why don't you simply set your preferred "default font" and hit "Save as
Document Defaults"?

Then this will be _your_ personal default.

We do not set a specific default font in LyX because this is class-
dependent.

Jürgen

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

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 04:10, Joel Kulesza wrote:

On Fri, Oct 21, 2016 at 3:56 PM, racoon > wrote:

On 21.10.2016 21:47, Joel Kulesza wrote:

Instead of this, I would rather see a customizable cursor color
in the
Preferences -> Colors dialog.  I would not want to have my cursor a
different color than my text (black on the default page
background, by
necessity).


This is already implemented in

Tools > Preferences... > Look & Feel > Colors > cursor

However, on my suggestion if you work on a rather light background,
like the default sepia, it will look black. At least I could not
tell the difference. So not having it "perfect" black might be a
price worth paying.


I don't see it there (see attached).  Am I missing something?


Wait a sec. Might be that this is because you use system colors?

Daniel

Re: Inverted colors for cursor

[racoon]

On 22.10.2016 04:10, Joel Kulesza wrote:

On Fri, Oct 21, 2016 at 3:56 PM, racoon > wrote:

On 21.10.2016 21:47, Joel Kulesza wrote:

Instead of this, I would rather see a customizable cursor color
in the
Preferences -> Colors dialog.  I would not want to have my cursor a
different color than my text (black on the default page
background, by
necessity).


This is already implemented in

Tools > Preferences... > Look & Feel > Colors > cursor

However, on my suggestion if you work on a rather light background,
like the default sepia, it will look black. At least I could not
tell the difference. So not having it "perfect" black might be a
price worth paying.


I don't see it there (see attached).  Am I missing something?


Strange (see attached). You are on LyX 2.2.2 and OS X, right?

Daniel