Re: Could not find LaTeX command for character '⌃' (code point 0x2303)

[Stephan Witt]

Am 20.02.2019 um 22:57 schrieb Joseph M. Kelly :
> 
> Thanks Stephan!  That worked great.  Didn’t expect a reply so quickly.

Fine, glad to hear that.

One thing you should have in mind:
in case you update your LyX to 2.4.x you should delete the modified version of 
the unicodesymbols file from your user directory.
On update LyX for Mac creates a new copy of the user directory as LyX-2.4 as 
sibling of the LyX-2.3 folder. 
On first startup the copy is made and you should remove the copy afterwards.
For 2.4.x the workaround is not needed anymore and has the potential to be a 
problem. 
And no, LyX 2.4 is not released yet.

Stephan

> 
> The help is much appreciated,
>Joe
> 
>> On Feb 20, 2019, at 4:29 PM, Stephan Witt  wrote:
>> 
>> Am 20.02.2019 um 22:27 schrieb Stephan Witt :
>>> 
>>> Am 20.02.2019 um 20:42 schrieb Joseph M. Kelly :
 
 Hi:
 
 First, thanks for making LyX available.  I hope to use it to replace Word 
 and MathType completely.
 
 I am running Mac OS X 10.13.6.  I downloaded and installed the binary of 
 LyX v. 2.3.2 thereby replacing an older version.  I started reading 
 tutorial and decided to convert it to a PDF. That is when I got the export 
 error:
 
 Could not find LaTeX command for character '⌃' (code point 0x2303)
 
 Some characters of your document are probably not representable in the 
 chosen encoding.
 Changing the document encoding to utf8 could help.
 
 So, I downloaded and installed the latest Latex version using MacTex 
 20180417. I then deleted LyX from my applications folder and reinstalled 
 it.
 
 Same problem when I try to export either the Tutorial or the User’s Guide.
 
 I tried to run unicode-insert 0x2303 using the LyX command palette but as 
 these are read only documents no luck
 
 Any suggestions on how to fix this for all future documents as an up caret 
 ^ is used a lot.
>>> 
>>> First, I’m able to confirm your issue. The unicode "UP ARROWHEAD“ is 
>>> generated by the info-inset for the short-cuts. 
>>> 
>>> Somehow this is solved with LyX 2.4 but I don’t know how.
>>> 
>>> A possible workaround for 2.3 could be to place some TeX code for 0x2303 in 
>>> the file unicodesymbols.
>>> You may copy the file 
>>> /Applications/LyX.app/Contents/Resources/unicodesymbols to the folder
>>> ~/Library/Application\ Support/LyX-2.3/unicodesymbols and add the TeX code 
>>> for it there.
>> 
>> Sorry, I have to correct my wording: you should copy the file unicodesymbols 
>> from the folder
>> /Applications/LyX.app/Contents/Resources to the folder 
>> ~/Library/Application\ Support/LyX-2.3.
>> 
>> Stephan
>> 
>>> 
>>> I’m not familiar with the syntax of this file and also don’t know the best 
>>> TeX code to typeset the character '⌃'.
>>> I’ve tried it with a line like this:
>>> 
>>> 0x2303 "Ctrl" "" "" "" "" # UP ARROWHEAD
>>> 
>>> and this worked for me. Perhaps some other developer can chime in and 
>>> propose a proper solution.
>>> 
>>> Hope this helps,
>>> Stephan
> 

Re: patch: added document language malayalam

[Joe Doe]

I made some changes. I don't know the changes I made to lib/lyx2lyx/lyx_2_3.py is correct. Please help me to complete the changes please.Please find the patches.~ Joice21.02.2019, 07:38, "Richard Kimberly Heck" :On 2/20/19 12:43 PM, Jean-Marc Lasgouttes wrote: Le 20/02/2019 à 16:23, Pavel Sanda a écrit : On Wed, Feb 20, 2019 at 09:04:59AM +, Joice Joseph wrote: Hi, last day. I had send a patch file which introduced language support for Malayalam - an Indic language like Tamil and Telugu. I didn't placed the definition in the correct (alphabetic order) place. So I had changed the patch placing it correctly. babel have support for Malayalam now. So, I have included that as well. Please merge with the main code base and make it available for everyone please. Please find the attached patch with this email. Hello and welcome here! I am afraid this patch is not enough, see e.g. this commit which introduces different langauge support: https://www.lyx.org/trac/changeset/d9c52c7a3f06ec892cd2e36d0d20998bc99b2fd8/lyxgit Uwe is not much around these days, but maybe someone else could give you a helping hand if the hint above is too difficult... I am not a specialist either but the changes boil down to three parts: 1/ Introduce a new LyX document version (because older versions of LyX will not be able to read a document in malayalam. We increase version number at each change. Note that this means that the new language will only be available with LyX 2.4.0. This is annoying, but we do not add new language sto stable releases. Concerns: src/version.h 2/ update the mechanism that converts old documents to new format (trivial, nothing to do) and to revert documents using malayalam to older format. This is the ugly part in the commit shown by Pavel, and unfortunately I do not know how to do it Concerns: stuff in lib/lyx2lyxI can probably find time to do these parts on Thursday. 3/ implement LaTeX importation. In proactice, one just has to add the language names to some array. This shouid probably use the lib/language file, but it is not done currently.I can also figure that part out, but for now it could be left as TODO.RikiFrom 550d89a05ae076520c9d1e8748dd00c19ea8914e Mon Sep 17 00:00:00 2001
From: Joice 
Date: Thu, 21 Feb 2019 09:55:50 +0530
Subject: [PATCH 2/2] Support for malayalam language

---
 development/FORMAT |  3 +++
 lib/lyx2lyx/lyx_2_3.py | 25 -
 lib/lyx2lyx/lyx_2_4.py |  2 ++
 src/version.h  |  4 ++--
 4 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/development/FORMAT b/development/FORMAT
index b87d395bc3..a568b44bc5 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -7,6 +7,9 @@ changes happened in particular if possible. A good example would be
 
 ---
 
+2019-02-21 Joice Joseph 
+* Format incremented to 567: Support for Malayalam:
+\lang malayalam
 
 2018-10-29  Guy Rutenberg 
 	* format incremeneted to 566: Fix direction of Hebrew parentheses in the LyX file.
diff --git a/lib/lyx2lyx/lyx_2_3.py b/lib/lyx2lyx/lyx_2_3.py
index ef79484f96..3569e702b9 100644
--- a/lib/lyx2lyx/lyx_2_3.py
+++ b/lib/lyx2lyx/lyx_2_3.py
@@ -319,6 +319,26 @@ def revert_asturian(document):
 "resetdefaultlanguage{asturian}",
 "\\end_layout", "", "\\end_inset", "", "",
 "\\end_layout", ""]
+def revert_malayalam(document):
+"Set the document language to English but assure Malayalam output"
+
+if document.language == "malayalam":
+document.language = "english"
+i = find_token(document.header, "\\language malayalam", 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{malayalam}}"])
+document.body[2 : 2] = ["\\begin_layout Standard",
+"\\begin_inset ERT", "status open", "",
+"\\begin_layout Plain Layout", "", "",
+"\\backslash",
+"resetdefaultlanguage{malayalam}",
+"\\end_layout", "", "\\end_inset", "", "",
+"\\end_layout", ""]
+
 
 
 def revert_kannada(document):
@@ -2233,10 +2253,13 @@ convert = [
[541, [convert_allowbreak]],
[542, [convert_mathnumberpos]],
[543, [convert_mathnumberingname]],
-   [544, [convert_minted]]
+   [544, [convert_minted]],
+   [567, []]
+
   ]
 
 revert =  [
+   [567, [revert_malayalam]],
[543, [revert_minted, revert_longtable_lscape]],
[542, [revert_mathnumberingname]],
[541, [revert_mathnumberpos]],
diff --git a/lib/lyx2lyx/lyx_2_4.py b/l

Re: patch: added document language malayalam

[Richard Kimberly Heck]

On 2/20/19 12:43 PM, Jean-Marc Lasgouttes wrote:
> Le 20/02/2019 à 16:23, Pavel Sanda a écrit :
>> On Wed, Feb 20, 2019 at 09:04:59AM +, Joice Joseph wrote:
>>> Hi, last day. I had send a patch file which introduced language support
>>> for Malayalam - an Indic language like Tamil and Telugu. I didn't
>>> placed
>>> the definition in the correct (alphabetic order) place. So I had
>>> changed
>>> the patch placing it correctly. babel have support for Malayalam now.
>>> So, I have included that as well.
>>>
>>> Please merge with the main code base and make it available for everyone
>>> please.
>>>
>>> Please find the attached patch with this email.
>>
>> Hello and welcome here!
>>
>> I am afraid this patch is not enough, see e.g. this commit which
>> introduces different
>> langauge support:
>> https://www.lyx.org/trac/changeset/d9c52c7a3f06ec892cd2e36d0d20998bc99b2fd8/lyxgit
>>
>>
>> Uwe is not much around these days, but maybe someone else could give
>> you a helping hand
>> if the hint above is too difficult...
>
> I am not a specialist either but the changes boil down to three parts:
>
> 1/ Introduce a new LyX document version (because older versions of LyX
> will not be able to read a document in malayalam. We increase version
> number at each change.
>
> Note that this means that the new language will only be available with
> LyX 2.4.0. This is annoying, but we do not add new language sto stable
> releases.
>
> Concerns: src/version.h
>
> 2/ update the mechanism that converts old documents to new format
> (trivial, nothing to do) and to revert documents using malayalam to
> older format. This is the ugly part in the commit shown by Pavel, and
> unfortunately I do not know how to do it
>
> Concerns: stuff in lib/lyx2lyx

I can probably find time to do these parts on Thursday.


> 3/ implement LaTeX importation. In proactice, one just has to add the
> language names to some array. This shouid probably use the
> lib/language file, but it is not done currently.

I can also figure that part out, but for now it could be left as TODO.

Riki

Re: [LyX/master] Honor Update::SinglePar properly

[Scott Kostyshak]

On Wed, Feb 20, 2019 at 11:04:55PM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/02/2019 à 20:51, Scott Kostyshak a écrit :
> > > Note that this commit may (will?) produce bad update at some places, since
> > > we have been ignoring this flag for so long. We have now to discover the
> > > places where it was forgotten. I think it is worth the it because we avoid
> > > redraws (thing moving cursor inside large table).
> > 
> > Would it be helpful for us to test (locally) on 2.3.x branch? The git
> > cherry-pick is clean. Is there any other commit I should cherry-pick
> > that this depends on?
> 
> Yes, this should work. I considered doing it, but anyway my daily use of LyX
> 2.3 period is finished for this year :) If you can do this locally, it will
> probably be useful.

Good to know. I'll do that.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Honor Update::SinglePar properly

[Jean-Marc Lasgouttes]

Le 20/02/2019 à 20:51, Scott Kostyshak a écrit :

Note that this commit may (will?) produce bad update at some places, since
we have been ignoring this flag for so long. We have now to discover the
places where it was forgotten. I think it is worth the it because we avoid
redraws (thing moving cursor inside large table).


Would it be helpful for us to test (locally) on 2.3.x branch? The git
cherry-pick is clean. Is there any other commit I should cherry-pick
that this depends on?


Yes, this should work. I considered doing it, but anyway my daily use 
of LyX 2.3 period is finished for this year :) If you can do this 
locally, it will probably be useful.


Thanks,
JMarc

Re: Could not find LaTeX command for character '⌃' (code point 0x2303)

[Joseph M. Kelly]

Thanks Stephan!  That worked great.  Didn’t expect a reply so quickly.

The help is much appreciated,
   Joe

> On Feb 20, 2019, at 4:29 PM, Stephan Witt  wrote:
> 
> Am 20.02.2019 um 22:27 schrieb Stephan Witt  >:
>> 
>> Am 20.02.2019 um 20:42 schrieb Joseph M. Kelly :
>>> 
>>> Hi:
>>> 
>>> First, thanks for making LyX available.  I hope to use it to replace Word 
>>> and MathType completely.
>>> 
>>> I am running Mac OS X 10.13.6.  I downloaded and installed the binary of 
>>> LyX v. 2.3.2 thereby replacing an older version.  I started reading 
>>> tutorial and decided to convert it to a PDF. That is when I got the export 
>>> error:
>>> 
>>> Could not find LaTeX command for character '⌃' (code point 0x2303)
>>> 
>>> Some characters of your document are probably not representable in the 
>>> chosen encoding.
>>> Changing the document encoding to utf8 could help.
>>> 
>>> So, I downloaded and installed the latest Latex version using MacTex 
>>> 20180417. I then deleted LyX from my applications folder and reinstalled it.
>>> 
>>> Same problem when I try to export either the Tutorial or the User’s Guide.
>>> 
>>> I tried to run unicode-insert 0x2303 using the LyX command palette but as 
>>> these are read only documents no luck
>>> 
>>> Any suggestions on how to fix this for all future documents as an up caret 
>>> ^ is used a lot.
>> 
>> First, I’m able to confirm your issue. The unicode "UP ARROWHEAD“ is 
>> generated by the info-inset for the short-cuts. 
>> 
>> Somehow this is solved with LyX 2.4 but I don’t know how.
>> 
>> A possible workaround for 2.3 could be to place some TeX code for 0x2303 in 
>> the file unicodesymbols.
>> You may copy the file 
>> /Applications/LyX.app/Contents/Resources/unicodesymbols to the folder
>> ~/Library/Application\ Support/LyX-2.3/unicodesymbols and add the TeX code 
>> for it there.
> 
> Sorry, I have to correct my wording: you should copy the file unicodesymbols 
> from the folder
> /Applications/LyX.app/Contents/Resources to the folder ~/Library/Application\ 
> Support/LyX-2.3.
> 
> Stephan
> 
>> 
>> I’m not familiar with the syntax of this file and also don’t know the best 
>> TeX code to typeset the character '⌃'.
>> I’ve tried it with a line like this:
>> 
>> 0x2303 "Ctrl" "" "" "" "" # UP ARROWHEAD
>> 
>> and this worked for me. Perhaps some other developer can chime in and 
>> propose a proper solution.
>> 
>> Hope this helps,
>> Stephan

Re: Could not find LaTeX command for character '⌃' (code point 0x2303)

[Stephan Witt]

Am 20.02.2019 um 22:27 schrieb Stephan Witt :
> 
> Am 20.02.2019 um 20:42 schrieb Joseph M. Kelly :
>> 
>> Hi:
>> 
>> First, thanks for making LyX available.  I hope to use it to replace Word 
>> and MathType completely.
>> 
>> I am running Mac OS X 10.13.6.  I downloaded and installed the binary of LyX 
>> v. 2.3.2 thereby replacing an older version.  I started reading tutorial and 
>> decided to convert it to a PDF. That is when I got the export error:
>> 
>> Could not find LaTeX command for character '⌃' (code point 0x2303)
>> 
>> Some characters of your document are probably not representable in the 
>> chosen encoding.
>> Changing the document encoding to utf8 could help.
>> 
>> So, I downloaded and installed the latest Latex version using MacTex 
>> 20180417. I then deleted LyX from my applications folder and reinstalled it.
>> 
>> Same problem when I try to export either the Tutorial or the User’s Guide.
>> 
>> I tried to run unicode-insert 0x2303 using the LyX command palette but as 
>> these are read only documents no luck
>> 
>> Any suggestions on how to fix this for all future documents as an up caret ^ 
>> is used a lot.
> 
> First, I’m able to confirm your issue. The unicode "UP ARROWHEAD“ is 
> generated by the info-inset for the short-cuts. 
> 
> Somehow this is solved with LyX 2.4 but I don’t know how.
> 
> A possible workaround for 2.3 could be to place some TeX code for 0x2303 in 
> the file unicodesymbols.
> You may copy the file /Applications/LyX.app/Contents/Resources/unicodesymbols 
> to the folder
> ~/Library/Application\ Support/LyX-2.3/unicodesymbols and add the TeX code 
> for it there.

Sorry, I have to correct my wording: you should copy the file unicodesymbols 
from the folder
/Applications/LyX.app/Contents/Resources to the folder ~/Library/Application\ 
Support/LyX-2.3.

Stephan

> 
> I’m not familiar with the syntax of this file and also don’t know the best 
> TeX code to typeset the character '⌃'.
> I’ve tried it with a line like this:
> 
> 0x2303 "Ctrl" "" "" "" "" # UP ARROWHEAD
> 
> and this worked for me. Perhaps some other developer can chime in and propose 
> a proper solution.
> 
> Hope this helps,
> Stephan

Re: Could not find LaTeX command for character '⌃' (code point 0x2303)

[Stephan Witt]

Am 20.02.2019 um 20:42 schrieb Joseph M. Kelly :
> 
> Hi:
> 
> First, thanks for making LyX available.  I hope to use it to replace Word and 
> MathType completely.
> 
> I am running Mac OS X 10.13.6.  I downloaded and installed the binary of LyX 
> v. 2.3.2 thereby replacing an older version.  I started reading tutorial and 
> decided to convert it to a PDF. That is when I got the export error:
> 
> Could not find LaTeX command for character '⌃' (code point 0x2303)
> 
> Some characters of your document are probably not representable in the chosen 
> encoding.
> Changing the document encoding to utf8 could help.
> 
> So, I downloaded and installed the latest Latex version using MacTex 
> 20180417. I then deleted LyX from my applications folder and reinstalled it.
> 
> Same problem when I try to export either the Tutorial or the User’s Guide.
> 
> I tried to run unicode-insert 0x2303 using the LyX command palette but as 
> these are read only documents no luck
> 
> Any suggestions on how to fix this for all future documents as an up caret ^ 
> is used a lot.

First, I’m able to confirm your issue. The unicode "UP ARROWHEAD“ is generated 
by the info-inset for the short-cuts. 

Somehow this is solved with LyX 2.4 but I don’t know how.

A possible workaround for 2.3 could be to place some TeX code for 0x2303 in the 
file unicodesymbols.
You may copy the file /Applications/LyX.app/Contents/Resources/unicodesymbols 
to the folder
~/Library/Application\ Support/LyX-2.3/unicodesymbols and add the TeX code for 
it there.

I’m not familiar with the syntax of this file and also don’t know the best TeX 
code to typeset the character '⌃'.
I’ve tried it with a line like this:

0x2303 "Ctrl" "" "" "" "" # UP ARROWHEAD

and this worked for me. Perhaps some other developer can chime in and propose a 
proper solution.

Hope this helps,
Stephan

Re: [LyX/master] Honor Update::SinglePar properly

[Scott Kostyshak]

On Wed, Feb 20, 2019 at 06:46:16PM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/02/2019 à 14:37, Jean-Marc Lasgouttes a écrit :
> > commit 9bdc0dab31337fd6788d587127842eb3558881ae
> > Author: Jean-Marc Lasgouttes 
> > Date:   Wed Feb 20 12:01:44 2019 +0100
> > 
> >  Honor Update::SinglePar properly
> 
> Note that this commit may (will?) produce bad update at some places, since
> we have been ignoring this flag for so long. We have now to discover the
> places where it was forgotten. I think it is worth the it because we avoid
> redraws (thing moving cursor inside large table).

Would it be helpful for us to test (locally) on 2.3.x branch? The git
cherry-pick is clean. Is there any other commit I should cherry-pick
that this depends on?

Scott


signature.asc
Description: PGP signature

Re: LyX's git VC backend: allow for multi-line commit messages and wrap to standard?

[Scott Kostyshak]

On Wed, Feb 20, 2019 at 09:40:24AM +0100, Pavel Sanda wrote:
> On Tue, Feb 19, 2019 at 11:35:53PM -0500, Scott Kostyshak wrote:
> > I'm not sure when I would get to doing this, but for LyX's Git VC
> > backend, would it be OK if I added support for multi-line commit
> > messages?
> 
> Sounds good.
> 
> > I could format it similar to how Vim does it by default:
> > 
> > - Subject line should be 50 characters. The user could enter more
> >   characters, but the additional characters will be marked in a
> >   different color, signaling that the recommended 50 has been exceeded.
> > 
> > - There should be a blank line between the subject line and the body.
> > 
> > - Wrap the body of the commit message to 72 characters.
> > 
> > I'm not familiar with LyX's code. I'm guessing I should do as much as
> > possible in the VC abstraction class, so that current and future
> > backends could also optionally choose to have such features?
> 
> That would be desirable, though you will need to check how that
> will work with older VCSs, like RCS - I'm not even sure it accepts
> multilines. 

OK.

> If you are going to encode newlines directly into commandline parameter
> it's worth to ask how that fares in win/mac systems because they treat
> them differently...

Good point. I hadn't thought of that potential complication. Maybe it is
better to use "git commit -F ".

Scott


signature.asc
Description: PGP signature

Could not find LaTeX command for character '⌃' (code point 0x2303)

[Joseph M. Kelly]

Hi:

First, thanks for making LyX available.  I hope to use it to replace Word and 
MathType completely.

I am running Mac OS X 10.13.6.  I downloaded and installed the binary of LyX v. 
2.3.2 thereby replacing an older version.  I started reading tutorial and 
decided to convert it to a PDF. That is when I got the export error:

Could not find LaTeX command for character '⌃' (code point 0x2303)

Some characters of your document are probably not representable in the chosen 
encoding.
Changing the document encoding to utf8 could help.

So, I downloaded and installed the latest Latex version using MacTex 20180417. 
I then deleted LyX from my applications folder and reinstalled it.

Same problem when I try to export either the Tutorial or the User’s Guide.

I tried to run unicode-insert 0x2303 using the LyX command palette but as these 
are read only documents no luck

Any suggestions on how to fix this for all future documents as an up caret ^ is 
used a lot.

Thanks for the help,
   Joe Kelly

Re: [LyX/master] ctest update: Set non-TeX fonts in documents, update comments and tags.

[Kornel Benko]

Am Mittwoch, 20. Februar 2019 16:45:29 CET schrieb Guenter Milde 
:
> On 2019-02-16, Kornel Benko wrote:
> > Am Freitag, 15. Februar 2019 22:57:53 CET schrieb Guenter Milde 
> > :
> >> On 2019-02-15, Kornel Benko wrote:
> >> > Am Freitag, 15. Februar 2019 06:47:00 CET schrieb Guenter Milde 
> >> > :
> 
> > ...
> 
> >> This leaves the following tests affected by my changes useSystemFonts.py:
> 
> >> > Remaining tests now:
> >> >  1771 - export/doc/attic/eu_Customization_dvi3_systemF (Failed)
> >> >  1776 - export/doc/attic/eu_Customization_pdf4_systemF (Failed)
> >> >  1778 - export/doc/attic/eu_Customization_pdf5_systemF (Failed)
> 
> > I don't get it. They compile here fine with TL18 _and_ TL17
> 
> ... but you reported them as failing with my (now reverted) changes to
> useSystemFonts.pl.

It's the other way around. They failed to compile before you reverted.

> 
> >> "Hand-compiling" the document with XeTeX and "default" non-TeX fonts works
> >> here. 
> 
> >> This would mean that some side-effect of my changes (that did not
> >> include changes to documents with lang == eu) changed the document from
> >> working to failing.
> 
> > Yes, the default in font seems to be not working here. Hand-compiling
> > gives:
> > Missing character: There is no ȧ (U+0227) in font 
> > [lmroman10-regular]:+tlig;!
> > ] [73] [74] [75] (./eu_Customization.aux
> > Language basque already loaded; id is 4))
> 
> >> Also, this would mean that getting rid of the "hidden" font replacement
> >> alltogether should not harm in this "attic" case!
> 
> Checking again, I could reproduce the failure, so it seems we would need
> a dedicated test version of this document with non-tex fonts or keep the
> script based font replacement for this specific case.

Yes.

> 
> >> >  6320 - export/examples/sr/Braille_dvi3_systemF (Failed)
> >> >  6325 - export/examples/sr/Braille_pdf4_systemF (Failed)
> 
> >> Hand-compiling works fine with the default (i.e. LatinModern) system fonts,
> >> so there is no need for font changes.
> 
> > Hand-compiling here gives:
> > ! Package polyglossia Error: The current roman font does not contain the 
> > Cyrill
> > ic script!
> > (polyglossia)Please define \cyrillicfont with 
> > \newfontfamily.
> 
> > See the polyglossia package documentation for explanation.
> 
> > This is with TL18 _and_ TL17
> 
> This is actually a Polyglossia bug: the document language is "Serbian
> (Latin Script)" yet Polyglossia throws an error (despite there is no
> character missing and there is no need for a Cyrillic-supporting font).
> Solving #8035 would also work around this Polyglossia bug, so I suggest
> to invert sr/Braille_pdf4_systemF referencing lyxissue #8035 instead of
> replacing the font.
> 
> I will look into this over the next weeks.
> 
> 
> Günter
>

Thanks,
Kornel

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

Re: [LyX/master] Honor Update::SinglePar properly

[Jean-Marc Lasgouttes]

Le 20/02/2019 à 14:37, Jean-Marc Lasgouttes a écrit :

commit 9bdc0dab31337fd6788d587127842eb3558881ae
Author: Jean-Marc Lasgouttes 
Date:   Wed Feb 20 12:01:44 2019 +0100

 Honor Update::SinglePar properly


Note that this commit may (will?) produce bad update at some places, 
since we have been ignoring this flag for so long. We have now to 
discover the places where it was forgotten. I think it is worth the it 
because we avoid redraws (thing moving cursor inside large table).


JMarc

 
 The SinglePar update flags has been a no-op for a long time without

 naybody noticing. This means that the current paragraph was
 always rebroken and redrawn, even when only moving the cursor around.
 
 Now we only do that when Update::SinglePar has been specified. This

 means that there may be cases where update will not be correct
 anymore, because this flag has not been specified. These places will
 have to be found and fixed.
 
 Update PAINTING_ANALYSIS.

---
  development/PAINTING_ANALYSIS |   28 
  src/BufferView.cpp|   18 ++
  2 files changed, 14 insertions(+), 32 deletions(-)

diff --git a/development/PAINTING_ANALYSIS b/development/PAINTING_ANALYSIS
index 32bc93a..a52a036 100644
--- a/development/PAINTING_ANALYSIS
+++ b/development/PAINTING_ANALYSIS
@@ -20,15 +20,9 @@ following section. Some actions are proposed.
  
  ** SinglePar update
  
-The flag Update::SinglePar is set in many places but never acted on.

-Instead, metrics update is skipped whenever the recorded height of
-current paragraph did not change and Update::Force was not specified.
-Is it better to keep that (which incurs extra work) or to condition it
-on Update::SinglePar? If the first solution is kept, the flag
-SingleParUpdate shall be removed.
-
-Moreover, I fail to see (yet) where the 'single' part of the program
-is acted on.
+This flag only has an effect in the current BufferView, but I think it
+is useful in other views too. Doing this will require some work on the
+update pipeline, though.
  
  ** Buffer::change issues
  
@@ -40,6 +34,7 @@ a good value? NoScreenUpdate?

  On a related note, what is the semantics of a call to
  Buffer::changed(false)? What does the caller mean?
  
+

  ** How to avoid redraw with FitCursor when the cursor is already OK?
  
  In this case, we invoke Buffer::change(false) with drawing disabled

@@ -60,12 +55,6 @@ cursor.
  
  * Clean-up of drawing code
  
-** Make SinglePar update flag useful again.

-
-The current code can be very expensive when moving cursor inside a
-huge table, for example. We should test the flag again, although this
-will probably lead to some glitches here and there.
-
  ** Set Row::changed() in a finer way
  
  *** singleParUpdate

@@ -139,15 +128,14 @@ DecorationUpdate). It triggers a recomputation of the 
metrics when either:
   + Update::Force has been specified
   + Update::FitCursor has been specified and there is a need to scroll
 the display.
- + the current paragraph, after rebreak, does not have the same height as in
-   existing metrics. Note that the Update::SinglePar flag is *never*
-   taken into account.
+ + Update::SinglePar has been specified and the current paragraph has
+   not changed height.
  
  If a computation of metrics has taken place, Force is removed from the

  flags and ForceDraw is added instead.
  
-It is OK to call processUptateFlags several times before an update. In

-this case, the effects are cumulative.processUpdateFlags execute the
+It is OK to call processUpateFlags several times before an update. In
+this case, the effects are cumulative. processUpdateFlags executes the
  metrics-related actions, but defers the actual drawing to the next
  paint event.
  
diff --git a/src/BufferView.cpp b/src/BufferView.cpp

index 35a126b..a46420e 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -500,11 +500,6 @@ void BufferView::processUpdateFlags(Update::flags flags)
 */
buffer_.updateMacros();
  
-	// SinglePar is ignored for now (this should probably change). We

-   // set it ourselves below, at the price of always rebreaking the
-   // paragraph at cursor. This can be expensive for large tables.
-   flags = flags & ~Update::SinglePar;
-
// First check whether the metrics and inset positions should be updated
if (flags & Update::Force) {
// This will update the CoordCache items and replace Force
@@ -512,15 +507,14 @@ void BufferView::processUpdateFlags(Update::flags flags)
updateMetrics(flags);
}
  
-	// Detect whether we can only repaint a single paragraph.

+   // Detect whether we can only repaint a single paragraph (if we
+   // are not already redrawing all).
// We handle this before FitCursor because the later will require
// correct metrics at cursor position.
-   if (!(flags & Update::ForceDraw)) {
-   i

Re: patch: added document language malayalam

[Jean-Marc Lasgouttes]

Le 20/02/2019 à 16:23, Pavel Sanda a écrit :

On Wed, Feb 20, 2019 at 09:04:59AM +, Joice Joseph wrote:

Hi, last day. I had send a patch file which introduced language support
for Malayalam - an Indic language like Tamil and Telugu. I didn't placed
the definition in the correct (alphabetic order) place. So I had changed
the patch placing it correctly. babel have support for Malayalam now.
So, I have included that as well.

Please merge with the main code base and make it available for everyone
please.

Please find the attached patch with this email.


Hello and welcome here!

I am afraid this patch is not enough, see e.g. this commit which introduces 
different
langauge support:
https://www.lyx.org/trac/changeset/d9c52c7a3f06ec892cd2e36d0d20998bc99b2fd8/lyxgit

Uwe is not much around these days, but maybe someone else could give you a 
helping hand
if the hint above is too difficult...


Hello,

I am not a specialist either but the changes boil down to three parts:

1/ Introduce a new LyX document version (because older versions of LyX 
will not be able to read a document in malayalam. We increase version 
number at each change.


Note that this means that the new language will only be available with 
LyX 2.4.0. This is annoying, but we do not add new language sto stable 
releases.


Concerns: src/version.h

2/ update the mechanism that converts old documents to new format 
(trivial, nothing to do) and to revert documents using malayalam to 
older format. This is the ugly part in the commit shown by Pavel, and 
unfortunately I do not know how to do it


Concerns: stuff in lib/lyx2lyx

3/ implement LaTeX importation. In proactice, one just has to add the 
language names to some array. This shouid probably use the lib/language 
file, but it is not done currently.


Concerns: stuff in src/tex2lyx.



I agree this looks very intimidating, but this is the best advice I can 
offer right now. Maybe someone with better knowledge can chime in.


JMarc

Re: [LyX/master] ctest update: Set non-TeX fonts in documents, update comments and tags.

[Guenter Milde]

On 2019-02-16, Kornel Benko wrote:
> Am Freitag, 15. Februar 2019 22:57:53 CET schrieb Guenter Milde 
> :
>> On 2019-02-15, Kornel Benko wrote:
>> > Am Freitag, 15. Februar 2019 06:47:00 CET schrieb Guenter Milde 
>> > :

> ...

>> This leaves the following tests affected by my changes useSystemFonts.py:

>> > Remaining tests now:
>> >1771 - export/doc/attic/eu_Customization_dvi3_systemF (Failed)
>> >1776 - export/doc/attic/eu_Customization_pdf4_systemF (Failed)
>> >1778 - export/doc/attic/eu_Customization_pdf5_systemF (Failed)

> I don't get it. They compile here fine with TL18 _and_ TL17

... but you reported them as failing with my (now reverted) changes to
useSystemFonts.pl.


>> "Hand-compiling" the document with XeTeX and "default" non-TeX fonts works
>> here. 

>> This would mean that some side-effect of my changes (that did not
>> include changes to documents with lang == eu) changed the document from
>> working to failing.

> Yes, the default in font seems to be not working here. Hand-compiling
> gives:
> Missing character: There is no ȧ (U+0227) in font [lmroman10-regular]:+tlig;!
> ] [73] [74] [75] (./eu_Customization.aux
> Language basque already loaded; id is 4))

>> Also, this would mean that getting rid of the "hidden" font replacement
>> alltogether should not harm in this "attic" case!

Checking again, I could reproduce the failure, so it seems we would need
a dedicated test version of this document with non-tex fonts or keep the
script based font replacement for this specific case.


>> >6320 - export/examples/sr/Braille_dvi3_systemF (Failed)
>> >6325 - export/examples/sr/Braille_pdf4_systemF (Failed)

>> Hand-compiling works fine with the default (i.e. LatinModern) system fonts,
>> so there is no need for font changes.

> Hand-compiling here gives:
> ! Package polyglossia Error: The current roman font does not contain the 
> Cyrill
> ic script!
> (polyglossia)Please define \cyrillicfont with \newfontfamily.

> See the polyglossia package documentation for explanation.

> This is with TL18 _and_ TL17

This is actually a Polyglossia bug: the document language is "Serbian
(Latin Script)" yet Polyglossia throws an error (despite there is no
character missing and there is no need for a Cyrillic-supporting font).
Solving #8035 would also work around this Polyglossia bug, so I suggest
to invert sr/Braille_pdf4_systemF referencing lyxissue #8035 instead of
replacing the font.

I will look into this over the next weeks.


Günter

Re: patch: added document language malayalam

[Pavel Sanda]

On Wed, Feb 20, 2019 at 09:04:59AM +, Joice Joseph wrote:
> Hi, last day. I had send a patch file which introduced language support
> for Malayalam - an Indic language like Tamil and Telugu. I didn't placed
> the definition in the correct (alphabetic order) place. So I had changed
> the patch placing it correctly. babel have support for Malayalam now.
> So, I have included that as well.
> 
> Please merge with the main code base and make it available for everyone
> please.
> 
> Please find the attached patch with this email.

Hello and welcome here!

I am afraid this patch is not enough, see e.g. this commit which introduces 
different
langauge support:
https://www.lyx.org/trac/changeset/d9c52c7a3f06ec892cd2e36d0d20998bc99b2fd8/lyxgit

Uwe is not much around these days, but maybe someone else could give you a 
helping hand
if the hint above is too difficult...

Cheers,
Pavel

patch: added document language malayalam

[Joice Joseph]

please find the patch with this email.

Thank you, Joice Joseph

From 9e25662a802c8fc2d455155b0f92b35b0e0d44f7 Mon Sep 17 00:00:00 2001
From: Joice 
Date: Wed, 20 Feb 2019 00:26:10 +0530
Subject: [PATCH] Added support for malayalam document.

---
 lib/languages | 9 +
 1 file changed, 9 insertions(+)

diff --git a/lib/languages b/lib/languages
index d409ce0ba5..02cca4ab59 100644
--- a/lib/languages
+++ b/lib/languages
@@ -320,6 +320,15 @@ Language bahasam
 	DateFormats  "dd  |d MMM |dd/MM/"
 	LangCode ms_MY
 End
+# not supported by babel
+Language malayalam
+	GuiName  "Malayalam"
+	PolyglossiaName  malayalam
+	Encoding utf8
+	DateFormats  "dd  |d MMM |dd-MM-"
+	LangCode ml_IN
+End
+
 
 Language basque
 	GuiName  "Basque"
-- 
2.20.1

Re: patch: added document language malayalam

[Joice Joseph]

Hi, last day. I had send a patch file which introduced language support
for Malayalam - an Indic language like Tamil and Telugu. I didn't placed
the definition in the correct (alphabetic order) place. So I had changed
the patch placing it correctly. babel have support for Malayalam now.
So, I have included that as well.

Please merge with the main code base and make it available for everyone
please.

Please find the attached patch with this email.

Thank you, Joice Joseph

On 20/2/19 12:30 AM, Joice wrote:
> please find the patch with this email.
>
> Thank you, Joice Joseph
>
From f5041d5f5325709bb8b126bbdde9aa6ce96e2143 Mon Sep 17 00:00:00 2001
From: Joice 
Date: Wed, 20 Feb 2019 14:28:24 +0530
Subject: [PATCH] Added Malayalam language support.

---
 lib/languages | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/languages b/lib/languages
index d409ce0ba5..261728cb9d 100644
--- a/lib/languages
+++ b/lib/languages
@@ -1002,6 +1002,16 @@ Language macedonian
 	Provides textcyrillic
 End
 
+Language malayalam
+	GuiName  "Malayalam"
+	BabelNamemalayalam
+PolyglossiaName  malayalam
+	Encoding utf8
+QuoteStyle   english
+	DateFormats  "dd  |d MMM |dd-MM-"
+	LangCode ml_IN
+End
+
 # not supported by babel
 Language marathi
 	GuiName  "Marathi"
-- 
2.20.1

Re: LyX's git VC backend: allow for multi-line commit messages and wrap to standard?

[Pavel Sanda]

On Tue, Feb 19, 2019 at 11:35:53PM -0500, Scott Kostyshak wrote:
> I'm not sure when I would get to doing this, but for LyX's Git VC
> backend, would it be OK if I added support for multi-line commit
> messages?

Sounds good.

> I could format it similar to how Vim does it by default:
> 
> - Subject line should be 50 characters. The user could enter more
>   characters, but the additional characters will be marked in a
>   different color, signaling that the recommended 50 has been exceeded.
> 
> - There should be a blank line between the subject line and the body.
> 
> - Wrap the body of the commit message to 72 characters.
> 
> I'm not familiar with LyX's code. I'm guessing I should do as much as
> possible in the VC abstraction class, so that current and future
> backends could also optionally choose to have such features?

That would be desirable, though you will need to check how that
will work with older VCSs, like RCS - I'm not even sure it accepts
multilines. 
If you are going to encode newlines directly into commandline parameter
it's worth to ask how that fares in win/mac systems because they treat
them differently...

Pavel