Re: [LyX/master] Add accelerator

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 10:57:18PM +0200, Kornel Benko wrote:

> Am Sonntag, 11. Juni 2017 um 22:19:15, schrieb Enrico Forestieri 
> 
> > On Sun, Jun 11, 2017 at 07:23:45PM +0200, Jürgen Spitzmüller wrote:
> > > Am Sonntag, den 11.06.2017, 18:32 +0200 schrieb Enrico Forestieri:
> > > > > I also think this widget should be disabled if not all necessary
> > > > > packages are installed.
> > > > 
> > > > This is problematic, because we should check for installed python
> > > > modules, which I don't think we currently do. 
> > > 
> > > This can be added to configure.py, no?
> > 
> > I see a further difficulty here. The pygments module could be installed
> > as a python 2 or python 3 module. The right python version to use is
> > determined by the used pygmentize command. So, if we are running python 2
> > and don't find the pygments module, it is not an indication that it is
> > not available. Conversely if we are running python 3 and pygments is
> > installed as a python 2 module.
> > 
> > Maybe, the only sensible thing to do is checking for a pygmentize command
> > and, if not found, warn the user but don't disable the widget.
> > 
> 
> Couldn't the test be as easy as to check output of
>   python -c "help('pygments');" 
> ?

Please, read more carefully what written above. In my case,
python -c "help('pygments');"
gives the help, but
python3 -c "help('pygments');"
produces:
No Python documentation found for 'pygments'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class.

Only the driver command knows what python has to be used.

-- 
Enrico

Re: [LyX/master] Add accelerator

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 10:19:15PM +0200, Enrico Forestieri wrote:
> 
> Maybe, the only sensible thing to do is checking for a pygmentize command
> and, if not found, warn the user but don't disable the widget.

Something like the attached.

-- 
Enrico
diff --git a/lib/configure.py b/lib/configure.py
index 1ce081cd07..8e7fedbb5a 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -1203,6 +1203,8 @@ def checkOtherEntries():
 'splitindex.class'], rc_entry = [ r'\splitindex_command "%%"' ])
 checkProg('a nomenclature processor', ['makeindex'],
 rc_entry = [ r'\nomencl_command "makeindex -s nomencl.ist"' ])
+checkProg('a python-pygments driver command', ['pygmentize'],
+rc_entry = [ r'\pygmentize_command "%%"' ])
 ## FIXME: OCTAVE is not used anywhere
 # path, OCTAVE = checkProg('Octave', ['octave'])
 ## FIXME: MAPLE is not used anywhere
@@ -1756,7 +1758,7 @@ if __name__ == '__main__':
 lyx_check_config = True
 lyx_kpsewhich = True
 outfile = 'lyxrc.defaults'
-lyxrc_fileformat = 21
+lyxrc_fileformat = 22
 rc_entries = ''
 lyx_keep_temps = False
 version_suffix = ''
diff --git a/lib/scripts/prefs2prefs_prefs.py b/lib/scripts/prefs2prefs_prefs.py
index b4acdc74d3..68b4d837dc 100644
--- a/lib/scripts/prefs2prefs_prefs.py
+++ b/lib/scripts/prefs2prefs_prefs.py
@@ -90,6 +90,10 @@
 #   default now)
 #   No conversion necessary.
 
+# Incremented to format 22, by ef
+#   Add pygmentize_command for the python pygments syntax highlighter
+#   No conversion necessary.
+
 # NOTE: The format should also be updated in LYXRC.cpp and
 # in configure.py.
 
@@ -387,5 +391,6 @@ conversions = [
[ 18, []],
[ 19, [remove_print_support]],
[ 20, []],
-   [ 21, []]
+   [ 21, []],
+   [ 22, []]
 ]
diff --git a/src/LyXRC.cpp b/src/LyXRC.cpp
index ae3569096e..e6244f2d2b 100644
--- a/src/LyXRC.cpp
+++ b/src/LyXRC.cpp
@@ -59,7 +59,7 @@ namespace {
 
 // The format should also be updated in configure.py, and conversion code
 // should be added to prefs2prefs_prefs.py.
-static unsigned int const LYXRC_FILEFORMAT = 21; // spitz: jbibtex_alternatives
+static unsigned int const LYXRC_FILEFORMAT = 22; // ef: pygmentize_command
 
 // when adding something to this array keep it sorted!
 LexerKeyword lyxrcTags[] = {
@@ -158,6 +158,7 @@ LexerKeyword lyxrcTags[] = {
{ "\\print_landscape_flag", LyXRC::RC_PRINTLANDSCAPEFLAG },
{ "\\print_paper_dimension_flag", LyXRC::RC_PRINTPAPERDIMENSIONFLAG },
{ "\\print_paper_flag", LyXRC::RC_PRINTPAPERFLAG },
+   { "\\pygmentize_command", LyXRC::RC_PYGMENTIZE_COMMAND },
{ "\\save_compressed", LyXRC::RC_SAVE_COMPRESSED },
{ "\\save_origin", LyXRC::RC_SAVE_ORIGIN },
{ "\\screen_dpi", LyXRC::RC_SCREEN_DPI },
@@ -241,6 +242,7 @@ void LyXRC::setDefaults()
fontenc = "default";
index_command = "makeindex -c -q";
nomencl_command = "makeindex -s nomencl.ist";
+   pygmentize_command = string();
dpi = 75;
// Because a screen is typically wider than a piece of paper:
zoom = 150;
@@ -544,6 +546,12 @@ LyXRC::ReturnValues LyXRC::read(Lexer & lexrc, bool 
check_format)
lexrc >> print_paper_flag;
break;
 
+   case RC_PYGMENTIZE_COMMAND:
+   if (lexrc.next(true)) {
+   pygmentize_command = lexrc.getString();
+   }
+   break;
+
case RC_VIEWDVI_PAPEROPTION:
if (lexrc.next())
view_dvi_paper_option = lexrc.getString();
@@ -1501,6 +1509,13 @@ void LyXRC::write(ostream & os, bool 
ignore_system_lyxrc, string const & name) c
}
if (tag != RC_LAST)
break;
+   case RC_PYGMENTIZE_COMMAND:
+   if (ignore_system_lyxrc ||
+   pygmentize_command != system_lyxrc.pygmentize_command) {
+   os << "\\pygmentize_command \"" << 
escapeCommand(pygmentize_command) << "\"\n";
+   }
+   if (tag != RC_LAST)
+   break;
case RC_TEX_EXPECTS_WINDOWS_PATHS:
// Don't write this setting to the preferences file,
// but allow temporary changes (bug 7557).
@@ -2809,6 +2824,7 @@ void actOnUpdatedPrefs(LyXRC const & lyxrc_orig, LyXRC 
const & lyxrc_new)
case LyXRC::RC_JBIBTEX_ALTERNATIVES:
case LyXRC::RC_JINDEX_COMMAND:
case LyXRC::RC_NOMENCL_COMMAND:
+   case LyXRC::RC_PYGMENTIZE_COMMAND:
case LyXRC::RC_INPUT:
case LyXRC::RC_KBMAP:
case LyXRC::RC_KBMAP_PRIMARY:
@@ -3067,6 +3083,10 @@ string const LyXRC::getDescription(LyXRCTags tag)
str = _("Define the options of makeindex (cf. man makeindex) to 
be used for nomenclatures. This might differ from the index processing 
options.");
   

Re: [LyX/master] Add accelerator

[Kornel Benko]

Am Sonntag, 11. Juni 2017 um 22:19:15, schrieb Enrico Forestieri 

> On Sun, Jun 11, 2017 at 07:23:45PM +0200, Jürgen Spitzmüller wrote:
> > Am Sonntag, den 11.06.2017, 18:32 +0200 schrieb Enrico Forestieri:
> > > > I also think this widget should be disabled if not all necessary
> > > > packages are installed.
> > > 
> > > This is problematic, because we should check for installed python
> > > modules, which I don't think we currently do. 
> > 
> > This can be added to configure.py, no?
> 
> I see a further difficulty here. The pygments module could be installed
> as a python 2 or python 3 module. The right python version to use is
> determined by the used pygmentize command. So, if we are running python 2
> and don't find the pygments module, it is not an indication that it is
> not available. Conversely if we are running python 3 and pygments is
> installed as a python 2 module.
> 
> Maybe, the only sensible thing to do is checking for a pygmentize command
> and, if not found, warn the user but don't disable the widget.
> 

Couldn't the test be as easy as to check output of
python -c "help('pygments');" 
?

Kornel

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

Re: [LyX/master] Add accelerator

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 07:23:45PM +0200, Jürgen Spitzmüller wrote:
> Am Sonntag, den 11.06.2017, 18:32 +0200 schrieb Enrico Forestieri:
> > > I also think this widget should be disabled if not all necessary
> > > packages are installed.
> > 
> > This is problematic, because we should check for installed python
> > modules, which I don't think we currently do. 
> 
> This can be added to configure.py, no?

I see a further difficulty here. The pygments module could be installed
as a python 2 or python 3 module. The right python version to use is
determined by the used pygmentize command. So, if we are running python 2
and don't find the pygments module, it is not an indication that it is
not available. Conversely if we are running python 3 and pygments is
installed as a python 2 module.

Maybe, the only sensible thing to do is checking for a pygmentize command
and, if not found, warn the user but don't disable the widget.

-- 
Enrico

Re: lyx-2.3.0alpha1-1 crash

[Guillaume MM]

Le 10/06/2017 à 00:34, Scott Kostyshak a écrit :

On Thu, Jun 01, 2017 at 01:43:11PM -0400, PhilipPirrip wrote:

On 05/28/2017 08:20 AM, Guillaume MM wrote:

Here is a patch, reviews are welcome.


Can't say much about the patch, but want to confirm that LyX is not crashing
any more.

Also pinging others to review the code, I think this is a pretty nasty bug
that definitely needs more testing.


+1 can anyone review the patch?



It is now committed at db581113.

Re: [LyX/master] Add accelerator

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 07:23:45PM +0200, Jürgen Spitzmüller wrote:

> Am Sonntag, den 11.06.2017, 18:32 +0200 schrieb Enrico Forestieri:
> > I don't think that listings is less advanced in code highlighting.
> > The advantage of minted is that it is less sensitive to the encoding.
> > All workarounds adopted for listings are not necessary for minted.
> > I also like better the way a listing is typeset, but this is a
> > personal preference. So, I would not qualify listings as less
> > advanced
> > than minted. However, a label saying "Different code highlighting"
> > is not any more informative than "Use minted".
> 
> In that case I think I'd prefer a combo box "Code highlighting package:
> Listings|Minted" or somesuch.

I tried to be minimalist in the changes, but if Scott agrees I could also
do that. This could delay trasnslations, though, as my spare time is
running out.

> "Use minted" is one of these LaTeXisms we want to avoid in the UI.

Maybe that is why pure LaTeX users don't love LyX? ;-)

> What happens if you check "Use minted" outside LaTeX BTW?

I don't understand the question. But if you mean what changes in the UI
other than the LaTeX output, the answer is that in some dialogs (listings
and child documents) some options are disabled and in the advanced
settings tab the recognized options change.

> > > And LyX should add the -shell-escape flag for
> > > minted documents (but warn the user before issuing it).
> > 
> > Hmm... I think you are opening a pandora's box. Maybe we could add
> > a toolbar button for doing that, so that the user has to
> > intentionally
> > do something for getting the -shell-escape flag.
> 
> As I said, I propose that the user has to explicitly acknowledge a
> warning message (with "Do not show again for this document" checkbox)
> before the document is processed.

Remember that we now have the needsauth (or whatever it is called) option
now, so that we could also exploit it.

> I find it much more dangerous to encourage the user to set the flag
> generally, since this might bite him with other documents quite
> horribly.

It could be a one-shot use. The flag is reset after each latex run.

> The problem of both these things is that users get an error message
> they might not understand if they try minted.

I think that minted does a good job here. This is the error you get:

! Package minted Error: You must invoke LaTeX with the -shell-escape flag.
See the minted package documentation for explanation.
Type  H   for immediate help.

-- 
Enrico

Re: [LyX/master] Add accelerator

[Guillaume MM]

Le 11/06/2017 à 16:23, Jürgen Spitzmüller a écrit :

And LyX should add the -shell-escape flag for
minted documents (but warn the user before issuing it).




Hi Jürgen, this is being discussed in this thread:

https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg200515.html

Re: [LyX/master] Add accelerator

[Jürgen Spitzmüller]

Am Sonntag, den 11.06.2017, 18:32 +0200 schrieb Enrico Forestieri:
> I don't think that listings is less advanced in code highlighting.
> The advantage of minted is that it is less sensitive to the encoding.
> All workarounds adopted for listings are not necessary for minted.
> I also like better the way a listing is typeset, but this is a
> personal preference. So, I would not qualify listings as less
> advanced
> than minted. However, a label saying "Different code highlighting"
> is not any more informative than "Use minted".

In that case I think I'd prefer a combo box "Code highlighting package:
Listings|Minted" or somesuch. "Use minted" is one of these LaTeXisms we
want to avoid in the UI.

What happens if you check "Use minted" outside LaTeX BTW?

> > I also think this widget should be disabled if not all necessary
> > packages are installed.
> 
> This is problematic, because we should check for installed python
> modules, which I don't think we currently do. 

This can be added to configure.py, no?

> We could check whether
> the pygmentize command is available, but we cannot be sure it is
> called exactly that way. Indeed, minted provides a command for
> specifying it. You can do \renewcommand{\MintedPygmentize}{pygments}
> if the command to be called is pygments instead of pygmentize,
> for example. So we risk of gratuitously disabling a functionality.
> 
> > And LyX should add the -shell-escape flag for
> > minted documents (but warn the user before issuing it).
> 
> Hmm... I think you are opening a pandora's box. Maybe we could add
> a toolbar button for doing that, so that the user has to
> intentionally
> do something for getting the -shell-escape flag.

As I said, I propose that the user has to explicitly acknowledge a
warning message (with "Do not show again for this document" checkbox)
before the document is processed.

I find it much more dangerous to encourage the user to set the flag
generally, since this might bite him with other documents quite
horribly.


The problem of both these things is that users get an error message
they might not understand if they try minted.

Jürgen

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

Re: Copying translations from 2.2.x to master?

[Georg Baum]

Kornel Benko wrote:

> So what is Uwe doing when he is re-merging? Probably calling
> development/tools/mergepo.py.

No. The workhose for remerging translations from the source code is 
po/lyx_pot.py. mergepo.py is only for merging between two branches without 
ptoducing huge nonsense diffs.

> I am not sure (because I am not expert) what
> happens on Windows. See mergepo_minimaldiff() there:
> 
> // What happens here with line endings?
> po2 = polib.pofile(source)
> 
> // This one looks good, but shouldn't we better explicitly open for
> text-mode? po1 = io.open(target, 'r', encoding='utf_8', newline=None)
> oldlines = read(po1)

lyx_pot.py opens some files explicitly with unix line ends, but not all:

output = io.open(output, 'w', encoding='utf_8', newline='\n')

I forgot all the details, but one reason for broken line ends that I do now 
remember again is this: Uwe is on windows, and receives an updated .po file 
from a translator who uses linux. Thus, the line ends are 'wrong' for his 
windows machine. I think this does not matter if he submits this as-is (git 
can cope with that), but if he remerges strings before submitting, then this 
might result in mixed line ends.

Maybe lyx_pot.py can be made more intelligent here? I am still strongly 
convinced that it is worth it to invest some time into a translations update 
machinery that is robust and does never require manual cleanup after a huge 
nonsense diff has been produced pays off in the long term.


Georg

Re: [LyX/master] Add accelerator

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 04:23:45PM +0200, Jürgen Spitzmüller wrote:

> Am Sonntag, den 11.06.2017, 13:58 +0200 schrieb Enrico Forestieri:
> > -  Use minted
> > +  Use minted
> 
> Is there a label that is less opaque to people who do not know what
> "minted" is? Something that highlights the benefits one gets when
> clicking this widget? E.g., "Advanced code highlighting" (and then
> explain it uses the minted package in the tool tip).

I don't think that listings is less advanced in code highlighting.
The advantage of minted is that it is less sensitive to the encoding.
All workarounds adopted for listings are not necessary for minted.
I also like better the way a listing is typeset, but this is a
personal preference. So, I would not qualify listings as less advanced
than minted. However, a label saying "Different code highlighting"
is not any more informative than "Use minted".

> I also think this widget should be disabled if not all necessary
> packages are installed.

This is problematic, because we should check for installed python
modules, which I don't think we currently do. We could check whether
the pygmentize command is available, but we cannot be sure it is
called exactly that way. Indeed, minted provides a command for
specifying it. You can do \renewcommand{\MintedPygmentize}{pygments}
if the command to be called is pygments instead of pygmentize,
for example. So we risk of gratuitously disabling a functionality.

> And LyX should add the -shell-escape flag for
> minted documents (but warn the user before issuing it).

Hmm... I think you are opening a pandora's box. Maybe we could add
a toolbar button for doing that, so that the user has to intentionally
do something for getting the -shell-escape flag.

-- 
Enrico

Re: [LyX/master] Add accelerator

[Jürgen Spitzmüller]

Am Sonntag, den 11.06.2017, 13:58 +0200 schrieb Enrico Forestieri:
> -  Use minted
> +  Use minted

Is there a label that is less opaque to people who do not know what
"minted" is? Something that highlights the benefits one gets when
clicking this widget? E.g., "Advanced code highlighting" (and then
explain it uses the minted package in the tool tip).

I also think this widget should be disabled if not all necessary
packages are installed. And LyX should add the -shell-escape flag for
minted documents (but warn the user before issuing it).

Jürgen

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

Re: [LyX/master] Remerge strings again after last change

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 03:46:31PM +0200, Kornel Benko wrote:

> Am Sonntag, 11. Juni 2017 um 15:27:20, schrieb Enrico Forestieri 
> 
> > On Sun, Jun 11, 2017 at 03:21:42PM +0200, Kornel Benko wrote:
> > 
> > > Am Sonntag, 11. Juni 2017 um 15:07:20, schrieb Enrico Forestieri 
> > > 
> > > > On Sun, Jun 11, 2017 at 02:59:52PM +0200, Kornel Benko wrote:
> > > > 
> > > > > Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 
> > > > > 
> > > > > > commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> > > > > > Author: Enrico Forestieri 
> > > > > > Date:   Sun Jun 11 14:02:02 2017 +0200
> > > > > > 
> > > > > > Remerge strings again after last change
> > > > > > 
> > > > > 
> > > > > This remerging in the repo while translating 'old' po file is really 
> > > > > disturbing.
> > > > > 
> > > > > Could you (and Uwe!) please leave sk.po untouched?
> > > > 
> > > > I think this is a collaborative effort. But I'll left you alone next 
> > > > time
> > > > I should remerge strings by doing git co po/sk.po after remerging.
> > > > 
> > > 
> > > And 'git co po/sk.gmo' too?
> > 
> > Sure. If there is some sort of comment field in git, you could add something
> > along the lines of "Kornel's private property: stay away". I will check
> > that before trying to modify it.
> > 
> 
> Forget it. It is not my property, I gave it to the community.
> My reaction was too fast, calmed down already. Sorry.

No problem, Kornel. Sometimes I cannot refrain from being sarcastic.

-- 
Enrico

Re: [LyX/master] Remerge strings again after last change

[Kornel Benko]

Am Sonntag, 11. Juni 2017 um 15:27:20, schrieb Enrico Forestieri 

> On Sun, Jun 11, 2017 at 03:21:42PM +0200, Kornel Benko wrote:
> 
> > Am Sonntag, 11. Juni 2017 um 15:07:20, schrieb Enrico Forestieri 
> > 
> > > On Sun, Jun 11, 2017 at 02:59:52PM +0200, Kornel Benko wrote:
> > > 
> > > > Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 
> > > > 
> > > > > commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> > > > > Author: Enrico Forestieri 
> > > > > Date:   Sun Jun 11 14:02:02 2017 +0200
> > > > > 
> > > > > Remerge strings again after last change
> > > > > 
> > > > 
> > > > This remerging in the repo while translating 'old' po file is really 
> > > > disturbing.
> > > > 
> > > > Could you (and Uwe!) please leave sk.po untouched?
> > > 
> > > I think this is a collaborative effort. But I'll left you alone next time
> > > I should remerge strings by doing git co po/sk.po after remerging.
> > > 
> > 
> > And 'git co po/sk.gmo' too?
> 
> Sure. If there is some sort of comment field in git, you could add something
> along the lines of "Kornel's private property: stay away". I will check
> that before trying to modify it.
> 

Forget it. It is not my property, I gave it to the community.
My reaction was too fast, calmed down already. Sorry.

Kornel

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

Re: [LyX/master] Remerge strings again after last change

[Kornel Benko]

Am Sonntag, 11. Juni 2017 um 15:24:09, schrieb Enrico Forestieri 

> On Sun, Jun 11, 2017 at 03:18:43PM +0200, Kornel Benko wrote:
> 
> > Am Sonntag, 11. Juni 2017 um 15:07:20, schrieb Enrico Forestieri 
> > 
> > > On Sun, Jun 11, 2017 at 02:59:52PM +0200, Kornel Benko wrote:
> > > 
> > > > Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 
> > > > 
> > > > > commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> > > > > Author: Enrico Forestieri 
> > > > > Date:   Sun Jun 11 14:02:02 2017 +0200
> > > > > 
> > > > > Remerge strings again after last change
> > > > > 
> > > > 
> > > > This remerging in the repo while translating 'old' po file is really 
> > > > disturbing.
> > > > 
> > > > Could you (and Uwe!) please leave sk.po untouched?
> > > 
> > > I think this is a collaborative effort. But I'll left you alone next time
> > > I should remerge strings by doing git co po/sk.po after remerging.
> > > 
> > 
> > Thanks.
> > 
> > The problem is, I don't need remerging 2.2 to 2.3, since I am working 
> > always the other way around.
> > My 'source' is master.
> 
> It was a mere update of strings in master, so only new strings are added.
> 

OK.

Kornel

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

Re: [LyX/master] Remerge strings again after last change

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 03:21:42PM +0200, Kornel Benko wrote:

> Am Sonntag, 11. Juni 2017 um 15:07:20, schrieb Enrico Forestieri 
> 
> > On Sun, Jun 11, 2017 at 02:59:52PM +0200, Kornel Benko wrote:
> > 
> > > Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 
> > > 
> > > > commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> > > > Author: Enrico Forestieri 
> > > > Date:   Sun Jun 11 14:02:02 2017 +0200
> > > > 
> > > > Remerge strings again after last change
> > > > 
> > > 
> > > This remerging in the repo while translating 'old' po file is really 
> > > disturbing.
> > > 
> > > Could you (and Uwe!) please leave sk.po untouched?
> > 
> > I think this is a collaborative effort. But I'll left you alone next time
> > I should remerge strings by doing git co po/sk.po after remerging.
> > 
> 
> And 'git co po/sk.gmo' too?

Sure. If there is some sort of comment field in git, you could add something
along the lines of "Kornel's private property: stay away". I will check
that before trying to modify it.

-- 
Enrico

Re: [LyX/master] Remerge strings again after last change

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 03:18:43PM +0200, Kornel Benko wrote:

> Am Sonntag, 11. Juni 2017 um 15:07:20, schrieb Enrico Forestieri 
> 
> > On Sun, Jun 11, 2017 at 02:59:52PM +0200, Kornel Benko wrote:
> > 
> > > Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 
> > > 
> > > > commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> > > > Author: Enrico Forestieri 
> > > > Date:   Sun Jun 11 14:02:02 2017 +0200
> > > > 
> > > > Remerge strings again after last change
> > > > 
> > > 
> > > This remerging in the repo while translating 'old' po file is really 
> > > disturbing.
> > > 
> > > Could you (and Uwe!) please leave sk.po untouched?
> > 
> > I think this is a collaborative effort. But I'll left you alone next time
> > I should remerge strings by doing git co po/sk.po after remerging.
> > 
> 
> Thanks.
> 
> The problem is, I don't need remerging 2.2 to 2.3, since I am working always 
> the other way around.
> My 'source' is master.

It was a mere update of strings in master, so only new strings are added.

-- 
Enrico

Re: [LyX/master] Remerge strings again after last change

[Kornel Benko]

Am Sonntag, 11. Juni 2017 um 15:07:20, schrieb Enrico Forestieri 

> On Sun, Jun 11, 2017 at 02:59:52PM +0200, Kornel Benko wrote:
> 
> > Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 
> > 
> > > commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> > > Author: Enrico Forestieri 
> > > Date:   Sun Jun 11 14:02:02 2017 +0200
> > > 
> > > Remerge strings again after last change
> > > 
> > 
> > This remerging in the repo while translating 'old' po file is really 
> > disturbing.
> > 
> > Could you (and Uwe!) please leave sk.po untouched?
> 
> I think this is a collaborative effort. But I'll left you alone next time
> I should remerge strings by doing git co po/sk.po after remerging.
> 

And 'git co po/sk.gmo' too?

Kornel

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

Re: [LyX/master] Remerge strings again after last change

[Kornel Benko]

Am Sonntag, 11. Juni 2017 um 15:07:20, schrieb Enrico Forestieri 

> On Sun, Jun 11, 2017 at 02:59:52PM +0200, Kornel Benko wrote:
> 
> > Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 
> > 
> > > commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> > > Author: Enrico Forestieri 
> > > Date:   Sun Jun 11 14:02:02 2017 +0200
> > > 
> > > Remerge strings again after last change
> > > 
> > 
> > This remerging in the repo while translating 'old' po file is really 
> > disturbing.
> > 
> > Could you (and Uwe!) please leave sk.po untouched?
> 
> I think this is a collaborative effort. But I'll left you alone next time
> I should remerge strings by doing git co po/sk.po after remerging.
> 

Thanks.

The problem is, I don't need remerging 2.2 to 2.3, since I am working always 
the other way around.
My 'source' is master.

Kornel

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

Re: [LyX/master] Remerge strings again after last change

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 02:59:52PM +0200, Kornel Benko wrote:

> Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 
> 
> > commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> > Author: Enrico Forestieri 
> > Date:   Sun Jun 11 14:02:02 2017 +0200
> > 
> > Remerge strings again after last change
> > 
> 
> This remerging in the repo while translating 'old' po file is really 
> disturbing.
> 
> Could you (and Uwe!) please leave sk.po untouched?

I think this is a collaborative effort. But I'll left you alone next time
I should remerge strings by doing git co po/sk.po after remerging.

-- 
Enrico

Re: [LyX/master] Remerge strings again after last change

[Kornel Benko]

Am Sonntag, 11. Juni 2017 um 14:03:07, schrieb Enrico Forestieri 

> commit 570ad4219eb4394399c4dc9d57a0ab76f8242047
> Author: Enrico Forestieri 
> Date:   Sun Jun 11 14:02:02 2017 +0200
> 
> Remerge strings again after last change
> 

This remerging in the repo while translating 'old' po file is really disturbing.

Could you (and Uwe!) please leave sk.po untouched?

Kornel

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

Re: [LyX/master] Change the name of the "List of listings" for minted

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 11:40:55AM +0200, Enrico Forestieri wrote:

> On Sun, Jun 11, 2017 at 11:30:08AM +0200, Enrico Forestieri wrote:
> 
> > On Sun, Jun 11, 2017 at 10:44:49AM +0200, Enrico Forestieri wrote:
> > 
> > > On Sun, Jun 11, 2017 at 10:40:34AM +0200, Enrico Forestieri wrote:
> > > 
> > > > commit ab47e48dcc525ed30b4e89b782d2ce5c81ca01c5
> > > > Author: Enrico Forestieri 
> > > > Date:   Sun Jun 11 10:38:44 2017 +0200
> > > > 
> > > > Change the name of the "List of listings" for minted
> > > > 
> > > > I actually checked that minted calls "List of Listings" the list of
> > > > listings, contrarily to the listings package.
> > > 
> > > Most probably, this requires updating the lib/layouttranslations file,
> > > but I don't know anything about this.
> > 
> > After looking around and at old commits, I think it suffices adding
> > an entry to the file. So, I am going to update all po files and then
> > use the same translation for "Listings[[List of Listings]]" for the
> > new field "List of Listings". In this way, translators don't have
> > to wonder what is this, and maybe it will help clarify what the
> > translation for "Listings[[List of Listings]]" should be.
> 
> Actually, there was already a field "List of Listings|L" and the update
> automatically took the relative translation (minus the trailing "|L"),
> for the new "List of Listings". So, there was actually nothing to do.
> In some cases, the translation of "Listings[[List of Listings]]" was
> different than the translation of "List of Listings|L", showing that there
> was some confusion about how to translate "Listings[[List of Listings]]".
> 
> I am going to commit these updates.

Done at 6ede3c5f. I hope I didn't mixed up things...

-- 
Enrico

Re: [LyX/master] Change the name of the "List of listings" for minted

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 11:30:08AM +0200, Enrico Forestieri wrote:

> On Sun, Jun 11, 2017 at 10:44:49AM +0200, Enrico Forestieri wrote:
> 
> > On Sun, Jun 11, 2017 at 10:40:34AM +0200, Enrico Forestieri wrote:
> > 
> > > commit ab47e48dcc525ed30b4e89b782d2ce5c81ca01c5
> > > Author: Enrico Forestieri 
> > > Date:   Sun Jun 11 10:38:44 2017 +0200
> > > 
> > > Change the name of the "List of listings" for minted
> > > 
> > > I actually checked that minted calls "List of Listings" the list of
> > > listings, contrarily to the listings package.
> > 
> > Most probably, this requires updating the lib/layouttranslations file,
> > but I don't know anything about this.
> 
> After looking around and at old commits, I think it suffices adding
> an entry to the file. So, I am going to update all po files and then
> use the same translation for "Listings[[List of Listings]]" for the
> new field "List of Listings". In this way, translators don't have
> to wonder what is this, and maybe it will help clarify what the
> translation for "Listings[[List of Listings]]" should be.

Actually, there was already a field "List of Listings|L" and the update
automatically took the relative translation (minus the trailing "|L"),
for the new "List of Listings". So, there was actually nothing to do.
In some cases, the translation of "Listings[[List of Listings]]" was
different than the translation of "List of Listings|L", showing that there
was some confusion about how to translate "Listings[[List of Listings]]".

I am going to commit these updates.

-- 
Enrico

Re: [LyX/master] Change the name of the "List of listings" for minted

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 10:44:49AM +0200, Enrico Forestieri wrote:

> On Sun, Jun 11, 2017 at 10:40:34AM +0200, Enrico Forestieri wrote:
> 
> > commit ab47e48dcc525ed30b4e89b782d2ce5c81ca01c5
> > Author: Enrico Forestieri 
> > Date:   Sun Jun 11 10:38:44 2017 +0200
> > 
> > Change the name of the "List of listings" for minted
> > 
> > I actually checked that minted calls "List of Listings" the list of
> > listings, contrarily to the listings package.
> 
> Most probably, this requires updating the lib/layouttranslations file,
> but I don't know anything about this.

After looking around and at old commits, I think it suffices adding
an entry to the file. So, I am going to update all po files and then
use the same translation for "Listings[[List of Listings]]" for the
new field "List of Listings". In this way, translators don't have
to wonder what is this, and maybe it will help clarify what the
translation for "Listings[[List of Listings]]" should be.

-- 
Enrico

Re: Copying translations from 2.2.x to master?

[Kornel Benko]

Am Sonntag, 11. Juni 2017 um 08:55:11, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Am Samstag, 10. Juni 2017 um 10:41:43, schrieb Georg Baum
> >> 
> >> I would suggest to use git correctly instead of fixing broken line ends
> >> again and again, producing huge nonsense diffs. We had this discussion
> >> several times in the past.
> >>
> > 
> > Maybe a problem in merging and pushing from windows.
> > Scenario to merge:
> > #: src/frontends/qt4/ui/BiblioUi.ui:244
> > with
> > #: src/frontends/qt4/ui/ColorUi.ui:73
> > results in
> > #: src/frontends/qt4/ui/BiblioUi.ui:244
> > src/frontends/qt4/ui/ColorUi.ui:73 and after push the last
> >  is converted to 
> 
> Probably. However, this does not happen with a correctly configured git: On 
> windows, both .ui and .po use windows line ends, on unix both .po and .ui 
> use unix line ends, so merging works fine in both cases. The merge script 
> works with windoes line ends IIRC, as long as all files use them.
> 

So what is Uwe doing when he is re-merging? Probably calling 
development/tools/mergepo.py.
I am not sure (because I am not expert) what happens on Windows.
See mergepo_minimaldiff() there:

// What happens here with line endings?
po2 = polib.pofile(source)

// This one looks good, but shouldn't we better explicitly open for 
text-mode?
po1 = io.open(target, 'r', encoding='utf_8', newline=None)
oldlines = read(po1)
...

Kornel


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

Re: [LyX/master] Change the name of the "List of listings" for minted

[Enrico Forestieri]

On Sun, Jun 11, 2017 at 10:40:34AM +0200, Enrico Forestieri wrote:

> commit ab47e48dcc525ed30b4e89b782d2ce5c81ca01c5
> Author: Enrico Forestieri 
> Date:   Sun Jun 11 10:38:44 2017 +0200
> 
> Change the name of the "List of listings" for minted
> 
> I actually checked that minted calls "List of Listings" the list of
> listings, contrarily to the listings package.

Most probably, this requires updating the lib/layouttranslations file,
but I don't know anything about this.

-- 
Enrico

Re: Translation of Listings in layouttranslations (was : [LyX/master] Overtake layout translations from fi.po, ja.po, zh_CN.po)

[Kornel Benko]

Am Sonntag, 11. Juni 2017 um 09:09:10, schrieb Jean-Pierre Chrétien 

> Le 10/06/2017 à 18:55, Jean-Pierre Chrétien a écrit :
> 
> >
> > French does not seem to be concerned by this call, but I reviewed one more 
> > time
> > the file and I have a doubt about the translation of
> >
> > "Listings[[List of Listings]]"
> >
> > Does this refer to the word "Listings" as it appears in the List of 
> > Listings (as
> > the double brackets indicate usually in the po file), or to the "List of
> > Listings" phrase itself ?
> 
> Coming back to the fr.po file (from where the layoutranslations are extracted 
> ?), I see this
> 
> InsetLayout TOC:Listings
>   # We need the [[List of Listings]] context, since "Listings" is also
>   # the name of the inset and translated differently.
>   # "Listings[[List of Listings]]" is the name of the "List of listings"
>   # ("Listings" is the predefined english name) in listings.sty, so it
>   # must be used here as well.
>   BabelPreamble
>   
> \addto\captions$$lang{\renewcommand{\lstlistlistingname}{_(Listings[[List of 
> Listings]])}}
>   EndBabelPreamble
> 
> This is unambiguous, my translation is currently correct, you may forget this 
> thread.
> 

Thanks. Nonetheless good questions.

Kornel

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

Re: Translation of Listings in layouttranslations (was : [LyX/master] Overtake layout translations from fi.po, ja.po, zh_CN.po)

[Jean-Pierre Chrétien]

Le 10/06/2017 à 18:55, Jean-Pierre Chrétien a écrit :



French does not seem to be concerned by this call, but I reviewed one more time
the file and I have a doubt about the translation of

"Listings[[List of Listings]]"

Does this refer to the word "Listings" as it appears in the List of Listings (as
the double brackets indicate usually in the po file), or to the "List of
Listings" phrase itself ?


Coming back to the fr.po file (from where the layoutranslations are extracted 
?), I see this


InsetLayout TOC:Listings
# We need the [[List of Listings]] context, since "Listings" is also
# the name of the inset and translated differently.
# "Listings[[List of Listings]]" is the name of the "List of listings"
# ("Listings" is the predefined english name) in listings.sty, so it
# must be used here as well.
BabelPreamble
		\addto\captions$$lang{\renewcommand{\lstlistlistingname}{_(Listings[[List of 
Listings]])}}

EndBabelPreamble

This is unambiguous, my translation is currently correct, you may forget this 
thread.


--
Jean-Pierre

Re: Copying translations from 2.2.x to master?

[Georg Baum]

Kornel Benko wrote:

> Am Samstag, 10. Juni 2017 um 10:41:43, schrieb Georg Baum
>> 
>> I would suggest to use git correctly instead of fixing broken line ends
>> again and again, producing huge nonsense diffs. We had this discussion
>> several times in the past.
>>
> 
> Maybe a problem in merging and pushing from windows.
> Scenario to merge:
> #: src/frontends/qt4/ui/BiblioUi.ui:244
> with
> #: src/frontends/qt4/ui/ColorUi.ui:73
> results in
> #: src/frontends/qt4/ui/BiblioUi.ui:244
> src/frontends/qt4/ui/ColorUi.ui:73 and after push the last
>  is converted to 

Probably. However, this does not happen with a correctly configured git: On 
windows, both .ui and .po use windows line ends, on unix both .po and .ui 
use unix line ends, so merging works fine in both cases. The merge script 
works with windoes line ends IIRC, as long as all files use them.


Georg