Re: [patch] Fix color when branch name has a space

[Scott Kostyshak]

On Fri, Oct 14, 2016 at 04:38:31PM -0400, Scott Kostyshak wrote:

> > The second solution would be to use
> > 
> > lyx_name = cmd.getArg(0);
> > x11_name = cmd.getArg(1);
> > 
> > In this case, the syntax for set-color would be
> > set-color foo bar
> > set-color "foo bar" baz
> > set-color foo "bar baz"
> > ...
> > 
> > I really prefer this second solution. And any of these is better than
> > relying on split and rtrim.
> 
> Makes sense. I'll work on a better patch.

Is the attached what you meant? If so I would audit the other calls to
LFUN_SET_COLOR.

Scott
From 8ee7da3c15ca2ac8db338f9e8ba438b17a9029e3 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Thu, 20 Oct 2016 22:41:31 -0400
Subject: [PATCH] Fix color when branch name has a space

TODO: fix other calls to LFUN_SET_COLOR
---
 src/Buffer.cpp   | 3 ++-
 src/frontends/qt4/GuiApplication.cpp | 6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 2dcdefe..5502eca 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2716,7 +2716,8 @@ void Buffer::dispatch(FuncRequest const & func, 
DispatchResult & dr)
branch_list.add(branch_name);
branch = branch_list.find(branch_name);
string const x11hexname = 
X11hexname(branch->color());
-   docstring const str = branch_name + ' ' + 
from_ascii(x11hexname);
+   docstring const str = '"' + branch_name + '"' + 
' ' +
+ '"' + 
from_ascii(x11hexname) + '"';
lyx::dispatch(FuncRequest(LFUN_SET_COLOR, str));
dr.setError(false);
dr.screenUpdate(Update::Force);
diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp
index 81d5373..878eb64 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1735,12 +1735,12 @@ void GuiApplication::dispatch(FuncRequest const & cmd, 
DispatchResult & dr)
}
 
case LFUN_SET_COLOR: {
-   string lyx_name;
-   string const x11_name = split(to_utf8(cmd.argument()), 
lyx_name, ' ');
+   string lyx_name = cmd.getArg(0);
+   string x11_name = cmd.getArg(1);
if (lyx_name.empty() || x11_name.empty()) {
if (current_view_)
current_view_->message(
-   _("Syntax: set-color  
"));
+   _("Syntax: set-color \"\" 
\"\""));
break;
}
 
-- 
2.7.4



signature.asc
Description: PGP signature

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Thu, Oct 20, 2016 at 04:07:13PM -0700, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Wed, Oct 19, 2016 at 05:30:20PM -0700, Pavel Sanda wrote:
> > > Enrico Forestieri wrote:
> > > > On Wed, Oct 19, 2016 at 03:09:53PM -0700, Pavel Sanda wrote:
> > > > > 
> > > > > Funny thing is that my mutt read the previous message without doing
> > > > > what you describe...
> > > > 
> > > > I guess you are using the maildir format for your mailbox.
> > > 
> > > mbox here. but mutt version is somewhat archaic, that might be the cause.
> > 
> > This is weird. Are you sure those attachments actually start with
> > a "From " line in the mbox file? Maybe some email filtering program 
> > is helping you (procmail?). Another possibility is that there is
> > a configuration setting I am missing, but I was not able to find
> > anything with my search-fu abilities.
> > 
> 
> I use procmail indeed. URL below points to JMarc email as saved by procmail.
> Can your mutt process it propely as a single mail?
> http://195.113.26.193/~sanda/junk/msg.txt

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?

-- 
Enrico

Re: [patch] support for Asturian etc.

[Uwe Stöhr]

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


2 such languages are however not yet
supported by LyX. The attached patch changes this...


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


regards Uwe
 development/FORMAT   |  7 
 lib/languages| 33 ++
 lib/lyx2lyx/lyx_2_3.py   | 91 ++--
 src/tex2lyx/Preamble.cpp | 20 +--
 src/version.h|  4 +--
 5 files changed, 141 insertions(+), 14 deletions(-)

diff --git a/development/FORMAT b/development/FORMAT
index 6f8bb59..86bc183 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,13 @@ adjustments are made to tex2lyx and bugs are fixed in 
lyx2lyx.
 
 ---
 
+2016-10-21 Uwe Stöhr 
+   * Format incremented to 514: support for Amharic etc.:
+ \lang amharic
+ \lang asturian
+ \lang kannada
+ \lang khmer
+
 2016-10-16 Uwe Stöhr 
* Format incremented to 513: support for Piedmontese etc.:
  \lang bosnian
diff --git a/lib/languages b/lib/languages
index 08cf331..f126e69 100644
--- a/lib/languages
+++ b/lib/languages
@@ -129,6 +129,14 @@ Language american
LangCode en_US
 End
 
+# not supported by babel
+Language amharic
+   GuiName  "Amharic"
+   PolyglossiaName  amharic
+   Encoding utf8
+   LangCode am_ET
+End
+
 # In Babel, this is supported since v. 1.8a of babel-greek (2013-12-03)
 # We introduce it with LyX 2.2 to give the support time to settle.
 Language ancientgreek
@@ -180,6 +188,15 @@ Language armenian
LangCode hy_AM
 End
 
+# not supported by babel
+Language asturian
+   GuiName  "Asturian"
+   PolyglossiaName  asturian
+   QuoteStyle   french
+   Encoding iso8859-15
+   LangCode ast_ES
+End
+
 Language australian
GuiName  "English (Australia)"
BabelNameaustralian
@@ -695,6 +712,14 @@ Language japanese-cjk
RequiresCJK
 End
 
+# not supported by babel
+Language kannada
+   GuiName  "Kannada"
+   PolyglossiaName  kannada
+   Encoding utf8
+   LangCode kn_IN
+End
+
 # not yet supported by polyglossia
 # not supported by babel
 Language kazakh
@@ -707,6 +732,14 @@ Language kazakh
EndPostBabelPreamble
 End
 
+# not supported by babel
+Language khmer
+   GuiName  "Khmer"
+   PolyglossiaName  khmer
+   Encoding utf8
+   LangCode km_KH
+End
+
 Language korean
GuiName "Korean"
Encodingeuc-kr
diff --git a/lib/lyx2lyx/lyx_2_3.py b/lib/lyx2lyx/lyx_2_3.py
index 93bf0f6..3a1b292 100644
--- a/lib/lyx2lyx/lyx_2_3.py
+++ b/lib/lyx2lyx/lyx_2_3.py
@@ -33,7 +33,8 @@ from parser_tools import find_end_of#, find_token, 
find_tokens, \
 from parser_tools import find_token, find_end_of_inset, get_value, \
  get_bool_value
 
-#from lyx2lyx_tools import add_to_preamble, put_cmd_in_ert, get_ert, 
lyx2latex, \
+from lyx2lyx_tools import add_to_preamble, put_cmd_in_ert
+#  get_ert, lyx2latex, \
 #  lyx2verbatim, length_in_bp, convert_info_insets
 #  insert_to_preamble, latex_length, revert_flex_inset, \
 #  revert_font_attrs, hex2ratio, str2bool
@@ -356,6 +357,90 @@ def revert_romansh(document):
document.header.insert(l + 1, "\\options romansh")
 
 
+def revert_amharic(document):
+"Set the document language to English but assure Amharic output"
+
+if document.language == "amharic":
+document.language = "english"
+i = find_token(document.header, "\\language amharic", 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{amharic}}"])
+document.body[2 : 2] = ["\\begin_layout Standard",
+"\\begin_inset ERT", "status open", "",
+"\\begin_layout Plain Layout", "", "",
+"\\backslash",
+"resetdefaultlanguage{amharic}",
+"\\end_layout", "", "\\end_inset", "", "",
+"\\end_layout", ""]
+
+
+def revert_asturian(document):
+"Set the document language to English but assure Asturian output"
+
+if document.language == "asturian":
+document.language = "english"
+i = find_token(document.header, "\\language asturian", 0)
+if i != -1:
+   document.header[i] = "\\language english"
+j = find_token(document.header, "\\language_package default", 0)
+if j != -1:
+   document.header[j] = 

[patch] support for Asturian and Amharic

[Uwe Stöhr]

LyX supports already many languages which are not supported by babel but 
polyglossia (Telugu, Tamil etc.). 2 such languages are however not yet 
supported by LyX. The attached patch changes this and adds support for 
Amharic and Asturian.

This is of course a fileformat change.

regards Uwe
 development/FORMAT   |  5 +
 lib/languages| 18 ++
 lib/lyx2lyx/lyx_2_3.py   | 49 ++--
 src/tex2lyx/Preamble.cpp |  8 
 src/version.h|  4 ++--
 5 files changed, 76 insertions(+), 8 deletions(-)

diff --git a/development/FORMAT b/development/FORMAT
index 6f8bb59..fa2f202 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,11 @@ adjustments are made to tex2lyx and bugs are fixed in 
lyx2lyx.
 
 ---
 
+2016-10-21 Uwe Stöhr 
+   * Format incremented to 514: support for Amharic and Asturian:
+ \lang amharic
+ \lang asturian
+
 2016-10-16 Uwe Stöhr 
* Format incremented to 513: support for Piedmontese etc.:
  \lang bosnian
diff --git a/lib/languages b/lib/languages
index 08cf331..093d737 100644
--- a/lib/languages
+++ b/lib/languages
@@ -129,6 +129,15 @@ Language american
LangCode en_US
 End
 
+# not supported by babel
+Language amharic
+   GuiName  "Amharic"
+   PolyglossiaName  amharic
+   QuoteStyle   english
+   Encoding utf8
+   LangCode am_ET
+End
+
 # In Babel, this is supported since v. 1.8a of babel-greek (2013-12-03)
 # We introduce it with LyX 2.2 to give the support time to settle.
 Language ancientgreek
@@ -180,6 +189,15 @@ Language armenian
LangCode hy_AM
 End
 
+# not supported by babel
+Language asturian
+   GuiName  "Asturian"
+   PolyglossiaName  asturian
+   QuoteStyle   french
+   Encoding iso8859-15
+   LangCode ast_ES
+End
+
 Language australian
GuiName  "English (Australia)"
BabelNameaustralian
diff --git a/lib/lyx2lyx/lyx_2_3.py b/lib/lyx2lyx/lyx_2_3.py
index 93bf0f6..2b24679 100644
--- a/lib/lyx2lyx/lyx_2_3.py
+++ b/lib/lyx2lyx/lyx_2_3.py
@@ -33,7 +33,8 @@ from parser_tools import find_end_of#, find_token, 
find_tokens, \
 from parser_tools import find_token, find_end_of_inset, get_value, \
  get_bool_value
 
-#from lyx2lyx_tools import add_to_preamble, put_cmd_in_ert, get_ert, 
lyx2latex, \
+from lyx2lyx_tools import add_to_preamble, put_cmd_in_ert
+#  get_ert, lyx2latex, \
 #  lyx2verbatim, length_in_bp, convert_info_insets
 #  insert_to_preamble, latex_length, revert_flex_inset, \
 #  revert_font_attrs, hex2ratio, str2bool
@@ -356,6 +357,48 @@ def revert_romansh(document):
document.header.insert(l + 1, "\\options romansh")
 
 
+def revert_amharic(document):
+"Set the document language to English but assure Amharic output"
+
+if document.language == "amharic":
+document.language = "english"
+i = find_token(document.header, "\\language amharic", 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{amharic}}"])
+document.body[2 : 2] = ["\\begin_layout Standard",
+"\\begin_inset ERT", "status open", "",
+"\\begin_layout Plain Layout", "", "",
+"\\backslash",
+"resetdefaultlanguage{amharic}",
+"\\end_layout", "", "\\end_inset", "", "",
+"\\end_layout", ""]
+
+
+def revert_asturian(document):
+"Set the document language to English but assure Asturian output"
+
+if document.language == "asturian":
+document.language = "english"
+i = find_token(document.header, "\\language asturian", 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{asturian}}"])
+document.body[2 : 2] = ["\\begin_layout Standard",
+"\\begin_inset ERT", "status open", "",
+"\\begin_layout Plain Layout", "", "",
+"\\backslash",
+"resetdefaultlanguage{asturian}",
+"\\end_layout", "", "\\end_inset", "", "",
+"\\end_layout", ""]
+
+
 ##
 # Conversion hub
 #
@@ -366,10 +409,12 @@ convert = [
[510, 

Re: [PATCH] Re: Return + Return in nested environments

[Pavel Sanda]

Enrico Forestieri wrote:
> On Wed, Oct 19, 2016 at 05:30:20PM -0700, Pavel Sanda wrote:
> > Enrico Forestieri wrote:
> > > On Wed, Oct 19, 2016 at 03:09:53PM -0700, Pavel Sanda wrote:
> > > > 
> > > > Funny thing is that my mutt read the previous message without doing
> > > > what you describe...
> > > 
> > > I guess you are using the maildir format for your mailbox.
> > 
> > mbox here. but mutt version is somewhat archaic, that might be the cause.
> 
> This is weird. Are you sure those attachments actually start with
> a "From " line in the mbox file? Maybe some email filtering program 
> is helping you (procmail?). Another possibility is that there is
> a configuration setting I am missing, but I was not able to find
> anything with my search-fu abilities.
> 

I use procmail indeed. URL below points to JMarc email as saved by procmail.
Can your mutt process it propely as a single mail?
http://195.113.26.193/~sanda/junk/msg.txt

Pavel

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Wed, Oct 19, 2016 at 05:30:20PM -0700, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Wed, Oct 19, 2016 at 03:09:53PM -0700, Pavel Sanda wrote:
> > > 
> > > Funny thing is that my mutt read the previous message without doing
> > > what you describe...
> > 
> > I guess you are using the maildir format for your mailbox.
> 
> mbox here. but mutt version is somewhat archaic, that might be the cause.

This is weird. Are you sure those attachments actually start with
a "From " line in the mbox file? Maybe some email filtering program 
is helping you (procmail?). Another possibility is that there is
a configuration setting I am missing, but I was not able to find
anything with my search-fu abilities.

-- 
Enrico

Re: [PATCH] Re: Return + Return in nested environments

[Enrico Forestieri]

On Thu, Oct 20, 2016 at 03:12:50PM +0200, Jean-Marc Lasgouttes wrote:
> 
> I have searched a bit, and the only thing I have found (with my MUA
> Thunderbird)
> is to change _all_ my attachments to be base64. I'll try that, because I
> prefer to have you with me than against me ;), but I may have to revert to
> some more standard way of working.

No problem. I was suspecting I was the only one suffering this issue.
As I am an unreasonable man, I persist in trying to adapt the world
to myself instead of adapting to the world...

> >This is because mutt takes them to be separate emails placed somewhere
> >else in the list of emails and I have to search for them or edit the
> >mailbox file to add a ">" just before "From" in order to actually see
> >them as attachments.
> 
> That's very weird, if you ask me.

From the mutt manual (this From will be escaped by MUAs):

   mbox. This is a widely used mailbox format for UNIX. All messages are
   stored in a single file. Each message has a line of the form:
   From m...@cs.hmc.edu Fri, 11 Apr 1997 11:44:56 PST
   to denote the start of a new message (this is often referred to as the
   "From_" line). The mbox format requires mailbox locking, is prone to
   mailbox corruption with concurrently writing clients or misinterpreted
   From_ lines. Depending on the environment, new mail detection can be
   unreliable. Mbox folders are fast to open and easy to archive.

The last bits are the ones important to me and the reason I prefer mbox.
One can have a single mbox file in a given directory containing all email
exchanges about the documents in that directory.

-- 
Enrico

Re: Regular expressions (adv search) not working on Mac OS X?

[Guillaume Munch]

Le 20/10/2016 à 16:03, Tommaso Cucinotta a écrit :


so the issue would be to double-check whether all regex-es in
findadv.cpp can be converted to std::regex ones. But, is there a common
syntax among boost::regex and std::regex that we can use so that
libraries become interchangeable? Otherwise, if we convert all regexes
to std:: syntax, we break everything with boost.


std::regex (ECMAScript) is boost::regex minus a few perl-isms. This is
why it was decided before 2.2 to restrict to ECMAScript. (See e.g. dbce5ca.)

However we then noticed that while boost:regex is compatible with
ECMAScript for regexes, it is not for replacement strings due to a
difference in escape characters. (See e8211fb.)

When converting the regexes to the new standard we may have missed
regexes created dynamically by Adv S

Re: Some inset offset fine tuning

[Jean-Marc Lasgouttes]

Le 18/10/2016 à 12:11, racoon a écrit :

Thanks JMarc. Do I understand you correctly that you tested high res
displays and they actually create a problem with those tiny 1px spaces?


One other user tested on a HiDPI display and found that the spaces 
(which use several pixels on those displays) would increase the 
interline spacing. Therefore, TEXT_TO_INSET_OFFSET should not be used 
vertically, or at least the value should be capped to avoid increasing 
interline. Nothing terribly difficult, I guess, but it needs to be done 
carefully..



Since I can't test on a high res display: would a zoom of, say, 100 %
result in the same height in pixels of a given font on high res and low
res displays?


No. On a high res display, in order to have a given text still legible, 
the height of the font in pixel is more important.


To understand what happens, you should set zoom to 300% and step back a 
few meters from your monitor :)


We have two strategies:
1/ like in my patch, we can define methods Inset::textToInsetOffset and 
Inset::textToInsetInnerOffset maybe with shorter names :) that returns 
the pixel values equivalent to 1mm and 0.5mm (according to your changes).
2/ I can provide you with methods MetricsInfo:::textToInsetOffset and 
MetricsInfo::textToInsetInnerOffset  that returns the pixel values 
equivalent to 0.3em and 0.15em (according to your changes).


In the second case, the spacing will be larger when the font is larger, 
for example in a section title. I think that this makes sense. Anyway, 
the idea is to provide a method that gives a directly usable pixel amount.


Why these magic numbers, I hear you (almost) say? See the rambling below.

I suspect that I have lost you already, but I also wrote this down for 
my own benefit.


The short term plan could be to do your work of using the right constant 
at the right place. Then we have to use something like my patch that 
makes sure that the spacing looks good on HiDPI screens too.


Sorry for the complicated explanations :)

JMarc

==
Appendix: some computations.
==

The idea of my patch is that 1 pixel on a old-school 100dpi monitor at 
100% zoom is
1/100 inch (dpi means dots per inch), that is 0,254 millimeters. So the 
default TEXT_TO_INSET_OFFSET value of 4 pixels is actually 1mm. Then we 
can do our computations in millimeters and have LyX use the right pixel 
spacing. The class Length can do this for us.


Now that I think of it, I would say that the inset spacing should be 
proportional to the normal text spacing in the current font. This 
information is generally available at places where one wants to compute 
spacing, AFAIK. The right unit for having length that depend from 
current font is 'em' (or 'mu' if you are in math formulas).


By default, the normal font has a point size of 10 (look in 
preferences). A point size, if I understand correctly 
(https://en.wikipedia.org/wiki/Point_(typography)#Desktop_publishing_point) 
is 1/72 of inch.


Therefore, at 100dpi, a pixel is 4/3 of point. Therefore a 10 points 
font would have a pixel size of 40/3 =13.333... This pixel size is 
actually what one calls a em. We can get this value using the em() 
method of the FontMetrics class.


All this computation to say that, with this second scheme,  the value of 
one pixel on a normal font size on a normal monitor would be 3/40em and 
therefore the value TEXT_TO_INSET_OFFSET of 4 pixels is now equivalent 
to 0.3em.

Re: LyXRC - %%s/scripts

[Stephan Witt]

Am 19.10.2016 um 23:54 schrieb Tommaso Cucinotta :
> 
> On 19/10/2016 23:10, Scott Kostyshak wrote:
>> See 8b66f9ce. Perhaps the commit introduced a bug? 
> 
> might be. AFAICS, the attempt to replace $$s centrally in 
> filetools.cpp:commandPrep() fails because the string getting there, is NOT 
> the converter command as from the \converter line, but rather a dynamically 
> generated temp Python script, e.g., dumping a few vars from that method:
> 
> : python -tt "/tmp/lyx_tmpdir.kJLFtRT15943/lyxconvertQ15943.py" "disegno.gp" 
> "png"
> pos1: 18446744073709551615
> 
> (and the pos of $$s is NOT found)
> 
> Contents of that script are dumped with "-dbg any", and it's a Python ~2-page 
> script containing:
> 
>  if os.system(r'$$s/scripts/gnuplot2pdf.sh ' + '"' + infile + '"' + ' ' + '"' 
> + outfile + '"' + '') != 0:
> 
> Do you know when / under what condition, such a Python intermediate script is 
> created

src/graphics/GraphicsConverter.cpp - build_script()

> and how to prevent that?

No.

Stephan

Re: Feature: open pdf from right click on citation inset ?

[Scott Kostyshak]

On Wed, Oct 19, 2016 at 03:35:38PM -0700, Pavel Sanda wrote:

> I would start with implementing lfun, which would just take the citation
> and try to
> 1. if pdf file found, trigger pdf viewer with file path (doc dir as a base)
> 2. if url found, trigger browser with url

That sounds like a good plan.

> 3. otherwise take author & title & year and trigger browser with url like
>   
> https://scholar.google.com/scholar?as_q=title_sauthors=author_ylo=year_yhi=year
>   (this sounds cool:)

Interesting idea. I had not thought of something like that.

> Then you could just add to context menu this lfun and it would work for 
> single citations.
> There could be even more advanced version of automatically filled submenu with
> all papers in the case citation inset contains more citations. But I would 
> first
> start with the simple lfun, how far it gets.

Makes sense.

> I don't think that the security issue is really problem, you just need proper
> launcher which has as first arg binary name for the executable and second arg 
> for
> params and not our homebrew startscript.
> Since we know what the executable is (we go either html or pdf) this should
> be quite straightforward.

OK.

Thanks for the feedback. I have no idea when I would actually start work
on this, but I think we have shaped the idea enough now that I would
know where to start. Of course if anyone beats me to implementing this,
they are most welcome.

Scott


signature.asc
Description: PGP signature

Re: [PATCH] Re: Return + Return in nested environments

[Scott Kostyshak]

On Wed, Oct 19, 2016 at 11:50:06PM +0200, Enrico Forestieri wrote:
> On Wed, Oct 19, 2016 at 04:12:54PM -0400, Scott Kostyshak wrote:
> > On Wed, Oct 19, 2016 at 07:03:32PM +0200, Enrico Forestieri wrote:
> > 
> > > This is because mutt takes them to be separate emails placed somewhere
> > > else in the list of emails and I have to search for them or edit the
> > > mailbox file to add a ">" just before "From" in order to actually see
> > > them as attachments.
> > 
> > I wonder why all MUA's don't automatically escape the "From".
> 
> I think they do, but only when it is in the email body, otherwise they
> would change the attachment, which is no go. Here is how an email from
> JMarc looks like:

Ah I understand.

> > Note that I don't have to do any manual configuration for JMarc's
> > patches to show up in mutt, but I think this is due to different
> > settings for storing messages (e.g. $mbox_type).
> 
> I guess you use the maildir format.

Yes I do.

> > P.S. By the way, the following is an exciting project to follow:
> > https://github.com/neomutt/neomutt
> 
> Interesting. When NeoLyX? ;-)

That almost sounds scary.

Scott


signature.asc
Description: PGP signature

Re: LyXRC - %%s/scripts

[Scott Kostyshak]

On Wed, Oct 19, 2016 at 11:54:06PM +0200, Tommaso Cucinotta wrote:

> Do you know when / under what condition, such a Python intermediate script is 
> created and how to prevent that?

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

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Implement reverse-search in the source panel

[Jean-Marc Lasgouttes]

Le 18/10/2016 à 19:58, Guillaume Munch a écrit :

The next missing bit in TeXRow is the literate feature, which changes
arbitrarily line offsets. Sweave at leaset offers a concordance file
that allows to fix that, but I suspect that it requires significant
work. Would you feel brave enough to have a look if I give you the
references?


The answer is probably "no", but it would be useful to have this
information on some ad hoc Trac ticket.


Here it is at http://www.lyx.org/trac/ticket/10452.

JMarc

Re: Regular expressions (adv search) not working on Mac OS X?

[Tommaso Cucinotta]

On 20/10/2016 16:23, Jean-Marc Lasgouttes wrote:

But suddenly I am not sure anymore of what the problem is. The original message in this 
thread complains about "[0-9]+" not working. In theory this should work both in 
Perl regexes and ECMAscript.


need to debug a bit more, but I suspect the real issue is in some internal 
lyxfind.cpp regexps that are used only when one uses the \regexp{} inset. Apart 
from [0-9]+ not working, I had also format search (\emph{.*} or similar) not 
working, until I managed to recompile with boost!

T.

Re: [PATCH] Cache Exportable Format Info

[Jean-Marc Lasgouttes]

Le 20/10/2016 à 16:33, Richard Heck a écrit :

On 10/20/2016 09:28 AM, Jean-Marc Lasgouttes wrote:

Le 20/10/2016 à 00:13, Richard Heck a écrit :

As discussed recently, we seem to spend a lot of time figuring out what
formats are exportable. The first of the attached patches introduces
caching of this information, in a very simple way. The second and third
use this to clean up a few things elsewhere: We can just sort this list
the first time we build it now, and not have to keep sorting it later.
The last just introduces a typedef, to make things more intelligible.


As long as you checked that setDocumentClass and makeDocumentCLass are
triggered every time the export formats change, this is OK for me.

Typically, does this work when converters are changed in the prefs?


Right. I'll fix that.


And when running reconfigure?

JMarc

Re: Regular expressions (adv search) not working on Mac OS X?

[Kornel Benko]

Am Donnerstag, 20. Oktober 2016 um 16:23:05, schrieb Jean-Marc Lasgouttes 

> Le 20/10/2016 à 16:03, Tommaso Cucinotta a écrit :
> > On 20/10/2016 15:48, Jean-Marc Lasgouttes wrote:
> >> Le 18/10/2016 à 18:42, Tommaso Cucinotta a écrit :
> >>> So, the problem with Advanced F might be: how do we package on Mac
> >>> OS-X ?
> >
> > I didn't see an answer to this, yet. Do we package with std::regex on
> > Mac ? What problem in packaging using boost instead ?
> 
> These days, we use std::regex by default when it is available. We may 
> have to reconsider this policy until AF is fixed.
> 
> I do not think that it would be a problem for Stephan to build with 
> boost::regex explicitly.
> 
> >> Tommaso, since regexes are mostly write-only, you are probably the
> >> person who knows best what kind of Perl extensions you like to use.
> >
> > so the issue would be to double-check whether all regex-es in
> > findadv.cpp can be converted to std::regex ones. But, is there a common
> > syntax among boost::regex and std::regex that we can use so that
> > libraries become interchangeable? Otherwise, if we convert all regexes
> > to std:: syntax, we break everything with boost.
> 
> As I understand it, Boost::regex uses Perl syntax, which is a extension 
> of normal-people-syntax. And I do not know what is the status of 
> ECMAscript syntax (used by std::regex).
> 
> But suddenly I am not sure anymore of what the problem is. The original 
> message in this thread complains about "[0-9]+" not working. In theory 
> this should work both in Perl regexes and ECMAscript.

Actually, in this case, if you use '-dbg find', you can see that the used 
expression is
lyxfind.cpp (871): Replaced text (to be used as regex): [0-9]+
lyxfind.cpp (874): Setting regexp to : '\`[0-9]+'
lyxfind.cpp (879): Setting regexp2 to: '\`.*.*[0-9]+'

> I am confused now.
> 
> >> Otherwise, we would need some Advanced F automated tests to checks
> >> how well our regexps behave.
> >
> > some are already there, see development/autotests/findadv-re-*-in.txt.
> 
> Good. I am not sure any more that the problem we have is with internal 
> regexes... The person we need on this is Georg.
> 
> JMarc

Kornel

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

Re: [PATCH] Cache Exportable Format Info

[Richard Heck]

On 10/20/2016 09:28 AM, Jean-Marc Lasgouttes wrote:
> Le 20/10/2016 à 00:13, Richard Heck a écrit :
>> As discussed recently, we seem to spend a lot of time figuring out what
>> formats are exportable. The first of the attached patches introduces
>> caching of this information, in a very simple way. The second and third
>> use this to clean up a few things elsewhere: We can just sort this list
>> the first time we build it now, and not have to keep sorting it later.
>> The last just introduces a typedef, to make things more intelligible.
>
> As long as you checked that setDocumentClass and makeDocumentCLass are
> triggered every time the export formats change, this is OK for me.
>
> Typically, does this work when converters are changed in the prefs?

Right. I'll fix that.

Richard

Re: Regular expressions (adv search) not working on Mac OS X?

[Jean-Marc Lasgouttes]

Le 20/10/2016 à 16:03, Tommaso Cucinotta a écrit :

On 20/10/2016 15:48, Jean-Marc Lasgouttes wrote:

Le 18/10/2016 à 18:42, Tommaso Cucinotta a écrit :

So, the problem with Advanced F might be: how do we package on Mac
OS-X ?


I didn't see an answer to this, yet. Do we package with std::regex on
Mac ? What problem in packaging using boost instead ?


These days, we use std::regex by default when it is available. We may 
have to reconsider this policy until AF is fixed.


I do not think that it would be a problem for Stephan to build with 
boost::regex explicitly.



Tommaso, since regexes are mostly write-only, you are probably the
person who knows best what kind of Perl extensions you like to use.


so the issue would be to double-check whether all regex-es in
findadv.cpp can be converted to std::regex ones. But, is there a common
syntax among boost::regex and std::regex that we can use so that
libraries become interchangeable? Otherwise, if we convert all regexes
to std:: syntax, we break everything with boost.


As I understand it, Boost::regex uses Perl syntax, which is a extension 
of normal-people-syntax. And I do not know what is the status of 
ECMAscript syntax (used by std::regex).


But suddenly I am not sure anymore of what the problem is. The original 
message in this thread complains about "[0-9]+" not working. In theory 
this should work both in Perl regexes and ECMAscript.


I am confused now.


Otherwise, we would need some Advanced F automated tests to checks
how well our regexps behave.


some are already there, see development/autotests/findadv-re-*-in.txt.


Good. I am not sure any more that the problem we have is with internal 
regexes... The person we need on this is Georg.


JMarc

Re: Regular expressions (adv search) not working on Mac OS X?

[Tommaso Cucinotta]

On 20/10/2016 15:48, Jean-Marc Lasgouttes wrote:

Le 18/10/2016 à 18:42, Tommaso Cucinotta a écrit :

So, the problem with Advanced F might be: how do we package on Mac OS-X ?


I didn't see an answer to this, yet. Do we package with std::regex on Mac ? 
What problem in packaging using boost instead ?

The problem is not regex inset. It is than _internally_, Advanced F should 
only use std::regex-compatible regexes.


Sure, one thing is what is supposed to be the syntax for users of the inset, 
another thing is our internal implementation.


We would like to get eventually get rid of boost if we can.

Tommaso, since regexes are mostly write-only, you are probably the person who 
knows best what kind of Perl extensions you like to use.


so the issue would be to double-check whether all regex-es in findadv.cpp can 
be converted to std::regex ones. But, is there a common syntax among 
boost::regex and std::regex that we can use so that libraries become 
interchangeable? Otherwise, if we convert all regexes to std:: syntax, we break 
everything with boost.


Otherwise, we would need some Advanced F automated tests to checks how well 
our regexps behave.


some are already there, see development/autotests/findadv-re-*-in.txt.

T.

Re: Regular expressions (adv search) not working on Mac OS X?

[Jean-Marc Lasgouttes]

Le 18/10/2016 à 18:42, Tommaso Cucinotta a écrit :

So, the problem with Advanced F might be: how do we package on Mac OS-X ?

Side issue: ideally, we'd like that regex inset to work with all regex
libs also on Linux, no?
(except for complex/advanced regexs...)


Actually, boost::regex supports some perl features that std::regex does 
not (the latter is more like ECMAScript, from what I understand).


The problem is not regex inset. It is than _internally_, Advanced F 
should only use std::regex-compatible regexes. We would like to get 
eventually get rid of boost if we can.


The question is: is there a good tool to check which regexes use the 
Perl extensions that boost allows?


Tommaso, since regexes are mostly write-only, you are probably the 
person who knows best what kind of Perl extensions you like to use.


Otherwise, we would need some Advanced F automated tests to checks how 
well our regexps behave.


JMarc

Re: [LyX/master] Docstringify getLongString in general and preamble snippets in particular

[Jean-Marc Lasgouttes]

Le 18/10/2016 à 19:59, Guillaume Munch a écrit :

From what I got from Georg's explanations, there's already a policy
which is quite clear: std::string must only contain ASCII. Therefore any
code using std::string in UTF-8 must be converted to use docstring instead.


That makes much sense, but I did not find it written this clearly in our 
docs.


JMarc

Re: Redundant Methods?

[Jean-Marc Lasgouttes]

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

In BufferParams, we have both an isExportable method and an
isExportableFormat method. Is there actually any functional difference
between these? The latter may be slightly different, in that it passes
the only_viewable flag to exportableFormats. But that could be handled
quite differently, by just returning false if the format isn't viewable.


I am sure that right now you know more than most of us about this 
converters business :)


JMarc

Re: [PATCH] Re: Return + Return in nested environments

[Jean-Marc Lasgouttes]

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

Yes, good for both. It will get much more testing in stable, and we are
presumably some ways from 2.2.3.


Thanks, I did that.

JMarc

Re: [patch] Increase precision of TexRow in captions

[Jean-Marc Lasgouttes]

Le 18/10/2016 à 12:06, Guenter Milde a écrit :

Whitespace after a macro (\begin) is ignored, after "\begin{something}" not.
Even if it will not necessarily change something in the output, it is safer
to escape it with %.


Fair enough.

JMarc

Re: [PATCH] Cache Exportable Format Info

[Jean-Marc Lasgouttes]

Le 20/10/2016 à 00:13, Richard Heck a écrit :

As discussed recently, we seem to spend a lot of time figuring out what
formats are exportable. The first of the attached patches introduces
caching of this information, in a very simple way. The second and third
use this to clean up a few things elsewhere: We can just sort this list
the first time we build it now, and not have to keep sorting it later.
The last just introduces a typedef, to make things more intelligible.


As long as you checked that setDocumentClass and makeDocumentCLass are 
triggered every time the export formats change, this is OK for me.


Typically, does this work when converters are changed in the prefs?

JMarc

Re: [PATCH] Re: Return + Return in nested environments

[Jean-Marc Lasgouttes]

Le 19/10/2016 à 19:03, Enrico Forestieri a écrit :

On Wed, Oct 19, 2016 at 06:20:51PM +0200, Jean-Marc Lasgouttes wrote:


Thanks, it seems to work well. Here is the combo commit, for reference.


Jean-Marc, please, can you use some kind of encoding (base64,
quoted-printable or whatever) when attaching patches that start
with the word "From"?


I have searched a bit, and the only thing I have found (with my MUA 
Thunderbird)
is to change _all_ my attachments to be base64. I'll try that, because I 
prefer to have you with me than against me ;), but I may have to revert 
to some more standard way of working.



This is because mutt takes them to be separate emails placed somewhere
else in the list of emails and I have to search for them or edit the
mailbox file to add a ">" just before "From" in order to actually see
them as attachments.


That's very weird, if you ask me.

JMarc

Re: [LyX/master] Add shell wrapper for Maxima on MacOSX The command line utility of Maxima is inside the Maxima.app bundle and isn't named "maxima"

[Jean-Marc Lasgouttes]

Le 20/10/2016 à 06:54, Stephan Witt a écrit :

Am 20.10.2016 um 06:35 schrieb Stephan Witt :


commit b37d6c9e941068bbf29281ca854687c7717e0d4d
Author: Stephan Witt 
Date:   Thu Oct 20 06:35:13 2016 +0200

   Add shell wrapper for Maxima on MacOSX
   The command line utility of Maxima is inside the Maxima.app bundle and isn't named 
"maxima"
---
development/MacOSX/Makefile.am |2 +-
development/MacOSX/maxima  |   13 +
2 files changed, 14 insertions(+), 1 deletions(-)


I tried to check my change with "make dist" and failed with:

make[2]: *** No rule to make target `export/ja/wrong_auto_encoding.lyx', needed 
by `distdir'.  Stop.
make[1]: *** [distdir] Error 1
make: *** [dist] Error 2


There is only a export/latex/ja_wrong_auto_encoding.lyx file - how should this 
be solved?


This is a consequence of the following commit:

commit d1a41a9bdc8da0ee402ecffc89079bcc92e6cf36
Author: Günter Milde 
Date:   Thu Sep 15 17:17:34 2016 +0200

ctests: Test dedicated LaTeX test samples with LaTeX export only.

Move them to a subdir, ignore this subdir for other tests.


Günter, what was the plan? Add all the files to Makefile.am, or only 
some of them. I can fix the Makefile.am, but only if I know what to do.


JMarc