Re: trac 'easyfix' tag

[Vincent van Ravesteijn]

Op 27-5-2013 22:04, Scott Kostyshak schreef:

On Mon, May 27, 2013 at 3:40 PM, Vincent van Ravesteijn v...@lyx.org wrote:

On the other hand, I'm not sure whether marking bugs as 'easyfix' will
really help.

I'm fine with this. I just wanted to see if others thought it would
*hurt* anything.

Scott

No, it doesn't hurt.

Vincent

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

Op 27-5-2013 18:05, Jean-Marc Lasgouttes schreef:

24/05/2013 15:07, Vincent van Ravesteijn:

By the way, this doesn't always work. The kill-gettext branch, for
instance, has master merged in a few times to fix merge conflicts. Now,
rebasing onto the merge-base does do no good.


Vincent, I want to merge this kill-gettext branch now. Is there 
something I should do to make it less ugly? I do not understand why it 
requires such ugly merges in the middle. What about good old hand-made 
conflict resolution?


Anyway, if you tell me to merge it as it is, it will be fine with me.

JMarc


I tested the branch a bit more.

- When you just implemented this, my LyX was translated immediately, but 
now it can't find the translations anymore. This is a pity.


I don't really understand the following:

+ if (in_build_dir_)
+return FileName(top_srcdir().absFileName() + /po/
++ c + .gmo);

So, if we run in the build dir, we look for the gmo files in the source 
dir ? Shouldn't we be looking the build dir then ? What about the attached ?


- I get an error that the language C could not be found. I know this is 
logical when the po-files can't be found, but it is a bit confusing that 
the language is C.


Vincent
From 412f013cdd7f1c70e631022d5ab4489ce60c216b Mon Sep 17 00:00:00 2001
From: Vincent van Ravesteijn v...@lyx.org
Date: Mon, 27 May 2013 21:43:50 +0200
Subject: [PATCH] Look for locale dir in the build directory

---
 src/support/Package.cpp | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index 24cf8ca..725999a 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -83,7 +83,8 @@ FileName findLyxBinary(FileName const  abs_binary);
 
 FileName const get_document_dir(FileName const  home_dir);
 
-FileName const get_locale_dir(FileName const  system_support_dir);
+FileName const get_locale_dir(FileName const  system_support_dir,
+   FileName const  build_support_dir);
 
 FileName const get_system_support_dir(FileName const  abs_binary,
string const  
command_line_system_support_dir);
@@ -130,7 +131,7 @@ Package::Package(string const  command_line_arg0,
// Find the LyX executable
lyx_binary_ = findLyxBinary(abs_binary);
 
-   locale_dir_ = get_locale_dir(system_support_dir_);
+   locale_dir_ = get_locale_dir(system_support_dir_, build_support_dir_);
 
FileName const default_user_support_dir =
get_default_user_support_dir(get_home_dir());
@@ -168,8 +169,7 @@ void Package::set_temp_dir(FileName const  temp_dir) const
 FileName Package::messages_file(string const  c) const
 {
if (in_build_dir_)
-   return FileName(top_srcdir().absFileName() + /po/
-   + c + .gmo);
+   return FileName(locale_dir_.absFileName() + / + c + .gmo);
else
return FileName(locale_dir_.absFileName() + / + c
+ /LC_MESSAGES/ PACKAGE .mo);
@@ -408,7 +408,8 @@ FileName const get_document_dir(FileName const  home_dir)
 
 // Several sources are probed to ascertain the locale directory.
 // The only requirement is that the result is indeed a directory.
-FileName const get_locale_dir(FileName const  system_support_dir)
+FileName const get_locale_dir(FileName const  system_support_dir,
+   FileName const  build_support_dir)
 {
// 1. Use the LYX_LOCALEDIR environment variable.
FileName const path_env = extract_env_var_dir(LYX_LOCALEDIR);
@@ -424,7 +425,12 @@ FileName const get_locale_dir(FileName const  
system_support_dir)
if (path.exists()  path.isDirectory())
return path;
 
-   // 3. Fall back to the hard-coded LOCALEDIR.
+   // 3. Search for build_support_dir/../po
+   path = FileName(addPath(build_support_dir.absFileName(), ../po));
+   if (path.exists()  path.isDirectory())
+   return path;
+
+   // 4. Fall back to the hard-coded LOCALEDIR.
path = hardcoded_localedir();
if (path.exists()  path.isDirectory())
return path;
-- 
1.8.0.msysgit.0

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

Op 27-5-2013 18:05, Jean-Marc Lasgouttes schreef:

24/05/2013 15:07, Vincent van Ravesteijn:

By the way, this doesn't always work. The kill-gettext branch, for
instance, has master merged in a few times to fix merge conflicts. Now,
rebasing onto the merge-base does do no good.


Vincent, I want to merge this kill-gettext branch now. Is there 
something I should do to make it less ugly? I do not understand why it 
requires such ugly merges in the middle. What about good old hand-made 
conflict resolution?


Anyway, if you tell me to merge it as it is, it will be fine with me.

JMarc


It's not that ugly. It was required to immediately fix the merge 
conflicts at the moment they arise.


First, if you would do it at the end, it would be more difficult and you 
might forget some conflicts. For example, you probably would forget the 
added 'intl' dependency of check_layout.


Second, other people that would like to try out the feature could not 
merge it directly in their master because of the merge conflicts. So, we 
can offer them a branch that can be merged into master.


Anyway, I rebased the branch onto master now. Shall I push it later ?

Vincent

Re: trac 'easyfix' tag

[Vincent van Ravesteijn]

Op 27-5-2013 21:13, Uwe Stöhr schreef:

Am 27.05.2013 20:10, schrieb Scott Kostyshak:

  Scott, please don't mark bugs as easyfix if they are apparently 
not that
  easy to fix. If this bug would be easy to fix, somebody would have 
done

  this in the last 2 years, but nothing happened.


I do not agree with the logic of "easy bug" -> "quick fix". There are
two other plausible "easy bugs" in my opinion. Easy bugs that are
labor-intensive


Hmm, this sounds illogical to me. If a bug requires much work, it is 
obviously not easy.

(Work is by definition not easy ;-) )

> and easy bugs that developers for whichever reason

don't want to fix. Both of these bug categories might be good places
for a newcommer to start.


OK, if that is the new meaning of easyfix, fine with me.


I agree that even if a bug requires much work, it can be an easyfix.

On the other hand, I'm not sure whether marking bugs as 'easyfix' will 
really help.


Vincent

Re: trac 'easyfix' tag

[Vincent van Ravesteijn]

Op 27-5-2013 21:40, Vincent van Ravesteijn schreef:

Op 27-5-2013 21:13, Uwe Stöhr schreef:

Am 27.05.2013 20:10, schrieb Scott Kostyshak:

  Scott, please don't mark bugs as easyfix if they are apparently 
not that
  easy to fix. If this bug would be easy to fix, somebody would 
have done

  this in the last 2 years, but nothing happened.


I do not agree with the logic of "easy bug" -> "quick fix". There are
two other plausible "easy bugs" in my opinion. Easy bugs that are
labor-intensive


Hmm, this sounds illogical to me. If a bug requires much work, it is 
obviously not easy.

(Work is by definition not easy ;-) )

> and easy bugs that developers for whichever reason

don't want to fix. Both of these bug categories might be good places
for a newcommer to start.


OK, if that is the new meaning of easyfix, fine with me.


I agree that even if a bug requires much work, it can be an easyfix.

On the other hand, I'm not sure whether marking bugs as 'easyfix' will 
really help.


Vincent



But please be sure that you know when something is easy to fix or not 
;).. (see bug #8664).


Vincent

Re: trac 'easyfix' tag

[Vincent van Ravesteijn]

Op 27-5-2013 22:04, Scott Kostyshak schreef:

On Mon, May 27, 2013 at 3:40 PM, Vincent van Ravesteijn <v...@lyx.org> wrote:

On the other hand, I'm not sure whether marking bugs as 'easyfix' will
really help.

I'm fine with this. I just wanted to see if others thought it would
*hurt* anything.

Scott

No, it doesn't hurt.

Vincent

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

Op 27-5-2013 18:05, Jean-Marc Lasgouttes schreef:

24/05/2013 15:07, Vincent van Ravesteijn:

By the way, this doesn't always work. The kill-gettext branch, for
instance, has master merged in a few times to fix merge conflicts. Now,
rebasing onto the merge-base does do no good.


Vincent, I want to merge this kill-gettext branch now. Is there 
something I should do to make it less ugly? I do not understand why it 
requires such ugly merges in the middle. What about good old hand-made 
conflict resolution?


Anyway, if you tell me to merge it as it is, it will be fine with me.

JMarc


I tested the branch a bit more.

- When you just implemented this, my LyX was translated immediately, but 
now it can't find the translations anymore. This is a pity.


I don't really understand the following:

+ if (in_build_dir_)
+return FileName(top_srcdir().absFileName() + "/po/"
++ c + ".gmo");

So, if we run in the build dir, we look for the gmo files in the source 
dir ? Shouldn't we be looking the build dir then ? What about the attached ?


- I get an error that the language C could not be found. I know this is 
logical when the po-files can't be found, but it is a bit confusing that 
the language is "C".


Vincent
>From 412f013cdd7f1c70e631022d5ab4489ce60c216b Mon Sep 17 00:00:00 2001
From: Vincent van Ravesteijn <v...@lyx.org>
Date: Mon, 27 May 2013 21:43:50 +0200
Subject: [PATCH] Look for locale dir in the build directory

---
 src/support/Package.cpp | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index 24cf8ca..725999a 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -83,7 +83,8 @@ FileName findLyxBinary(FileName const & abs_binary);
 
 FileName const get_document_dir(FileName const & home_dir);
 
-FileName const get_locale_dir(FileName const & system_support_dir);
+FileName const get_locale_dir(FileName const & system_support_dir,
+   FileName const & build_support_dir);
 
 FileName const get_system_support_dir(FileName const & abs_binary,
string const & 
command_line_system_support_dir);
@@ -130,7 +131,7 @@ Package::Package(string const & command_line_arg0,
// Find the LyX executable
lyx_binary_ = findLyxBinary(abs_binary);
 
-   locale_dir_ = get_locale_dir(system_support_dir_);
+   locale_dir_ = get_locale_dir(system_support_dir_, build_support_dir_);
 
FileName const default_user_support_dir =
get_default_user_support_dir(get_home_dir());
@@ -168,8 +169,7 @@ void Package::set_temp_dir(FileName const & temp_dir) const
 FileName Package::messages_file(string const & c) const
 {
if (in_build_dir_)
-   return FileName(top_srcdir().absFileName() + "/po/"
-   + c + ".gmo");
+   return FileName(locale_dir_.absFileName() + "/" + c + ".gmo");
else
return FileName(locale_dir_.absFileName() + "/" + c
+ "/LC_MESSAGES/" PACKAGE ".mo");
@@ -408,7 +408,8 @@ FileName const get_document_dir(FileName const & home_dir)
 
 // Several sources are probed to ascertain the locale directory.
 // The only requirement is that the result is indeed a directory.
-FileName const get_locale_dir(FileName const & system_support_dir)
+FileName const get_locale_dir(FileName const & system_support_dir,
+   FileName const & build_support_dir)
 {
// 1. Use the "LYX_LOCALEDIR" environment variable.
FileName const path_env = extract_env_var_dir("LYX_LOCALEDIR");
@@ -424,7 +425,12 @@ FileName const get_locale_dir(FileName const & 
system_support_dir)
if (path.exists() && path.isDirectory())
return path;
 
-   // 3. Fall back to the hard-coded LOCALEDIR.
+   // 3. Search for build_support_dir/../po
+   path = FileName(addPath(build_support_dir.absFileName(), "../po"));
+   if (path.exists() && path.isDirectory())
+   return path;
+
+   // 4. Fall back to the hard-coded LOCALEDIR.
path = hardcoded_localedir();
if (path.exists() && path.isDirectory())
return path;
-- 
1.8.0.msysgit.0

Re: lyx2lyx conversion routines

[Vincent van Ravesteijn]

Op 26-5-2013 8:53, Liviu Andronic schreef:

Hello Richard,


On Sun, May 26, 2013 at 12:24 AM, Richard Heck rgh...@lyx.org wrote:

These are just whitespace issues. I've fixed them in the attached, which are
also rebased to current trunk.


I made some partial progress. I managed to apply the first patch only
after I stripped trailing spaces from the patch _and_ changed
line-endings from CRLF (Win) to LF (Unix). I guess it's a GIT-related
Windows-Linux incompatibility.


git apply 0001-Liviu-s-chunk-patch.patch  (15337)
git apply 0001-Liviu-s-chunk-patch.patch (15337) returned '0'

However I'm still stumbling on the second, even after the
post-processing above:

git apply 0002-A-start-on-lyx2lyx-for-chunks.patch  (15371)

error: patch failed: lib/lyx2lyx/lyx_2_1.py:4152
error: lib/lyx2lyx/lyx_2_1.py: patch does not apply
error: patch failed: src/version.h:30
error: src/version.h: patch does not apply

git apply 0002-A-start-on-lyx2lyx-for-chunks.patch (15371) returned '1'
I had the same error in the first try. After correcting the eol-style of 
the patch file, everything was ok again. To correct the eol-style I used 
'dos2unix' in a Git bash shell.


Vincent

Re: Change or keep Farsi splash.lyx ?

[Vincent van Ravesteijn]

Op 26-5-2013 4:47, Scott Kostyshak schreef:

It would be nice to have doc/fa/splash.lyx export correctly as it
could be used as a template for someone wanting to write in Farsi.

The current splash.lyx file does not compile for me. After reading an
email thread [1] and instructions on the wiki [2], I get the attached
LyX file, which compiles for me.


I don't see such a thing as doc/fa/splash.lyx.


It doesn't seem correct to me because of the following issues:

I need to add the following to the LaTeX preamble manually. Should LyX
do this for me?
\DeclareTextSymbol{\guillemotright}{LFE}{62}
\DeclareTextSymbol{\guillemotleft}{LFE}{60}

The language is changed from Farsi to Arab(ArabTeX) and the document
class is changed from Article to Arabic Article. Is this right?

Nevertheless, it compiles for me and these are the settings that were
written by a user writing in Farsi.

Can Windows users get the current fa/splash.lyx to
compile (the Wiki page suggests that this should work)? Can
others compile the attached splash.lyx?


I can compile the attached splash.lyx, but the text is Left-To-Right 
instead of Right-To-Left.


Vincent

Re: [LyX master] aa.layout: updated for AA 8.2

[Vincent van Ravesteijn]

Op 26-5-2013 5:29, Uwe Stöhr schreef:

The branch, master, has been updated.

- Log -

commit e28625160a5078ffb37fc27ad3906edf5a73a31f
Author: Uwe Stöhr uwesto...@lyx.org
Date:   Sun May 26 05:29:24 2013 +0200

 aa.layout: updated for AA 8.2

diff --git a/development/FORMAT b/development/FORMAT
index 58f9016..fedfd43 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,10 @@ adjustments are made to tex2lyx and bugs are fixed in 
lyx2lyx.
  
  ---
  
+2013-05-26 Uwe Stöhr uwesto...@web.de

+   * Format incremented to 472: added 2 new abstract styles to the
+ aa.layout file



Do we now really have a new file format, just because we added new 
styles to a layout ? This also means that the LyX file format is now 
hardcoded to some version of the layout files. Is this the outcome of a 
recent discussion on whether we can upgrade layout files in a stable 
release series, or is this a trick to fire lyx2lyx ?

Re: [PATCH] Pass the binary dir to the configure script to find tex2lyx

[Vincent van Ravesteijn]

Op 26-5-2013 21:30, Stephan Witt schreef:

Am 11.04.2013 um 00:23 schrieb Julien Rioux jri...@lyx.org:


On 30/03/2013 9:46 AM, Vincent van Ravesteijn wrote:

When using CMake, the binary files are stored in build-dir/bin. LyX can't fin 
tex2lyx with the current code. So, we have to point configure.py to explicitly look 
in the binary dir.

Any objections ?

Vincent

---
  lib/configure.py|9 -
  src/support/Package.cpp |2 +-
  2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/configure.py b/lib/configure.py
index b6c453d..2ae6ec2 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -652,7 +652,10 @@ def checkConverterEntries():
  in_place = os.path.join(srcdir, '..', 'src', 'tex2lyx', 'tex2lyx')
  in_place = os.path.abspath(in_place)

-path, t2l = checkProg('a LaTeX/Noweb - LyX converter', [in_place, 
'tex2lyx' + version_suffix, 'tex2lyx'],
+in_binary_dir = os.path.join(lyx_binary_dir, 'tex2lyx')
+in_binary_dir = os.path.abspath(in_binary_dir)
+
+path, t2l = checkProg('a LaTeX/Noweb - LyX converter', [in_place, 
in_place + version_suffix, in_binary_dir, in_binary_dir + version_suffix, 
'tex2lyx' + version_suffix, 'tex2lyx'],
  rc_entry = [r'''\converter latex  lyx%% -f $$i $$o
  \converter literate   lyx%% -n -m noweb -f $$i $$o'''], 
not_found = 'tex2lyx')
  if path == '':
@@ -1394,6 +1397,7 @@ if __name__ == '__main__':
  rc_entries = ''
  lyx_keep_temps = False
  version_suffix = ''
+lyx_binary_dir = ''
  ## Parse the command line
  for op in sys.argv[1:]:   # default shell/for list is $*, the options
  if op in [ '-help', '--help', '-h' ]:
@@ -1404,6 +1408,7 @@ Options:
  --without-kpsewhich  do not update TeX files information via kpsewhich
  --without-latex-config   do not run LaTeX to determine configuration
  --with-version-suffix=suffix suffix of binary installed files
+--binary-dir=directory   directory of binary installed files
  '''
  sys.exit(0)
  elif op == '--without-kpsewhich':
@@ -1414,6 +1419,8 @@ Options:
  lyx_keep_temps = True
  elif op[0:22] == '--with-version-suffix=':  # never mind if op is not 
long enough
  version_suffix = op[22:]
+elif op[0:13] == '--binary-dir=':
+lyx_binary_dir = op[13:]
  else:
  print Unknown option, op
  sys.exit(1)
diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index dab008e..695e89f 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -141,7 +141,7 @@ Package::Package(string const  command_line_arg0,
FileName const configure_script(addName(system_support().absFileName(), 
configure.py));
configure_command_ = os::python() + ' ' +
quoteName(configure_script.toFilesystemEncoding(), 
quote_python) +
-   with_version_suffix();
+   with_version_suffix() +  --binary-dir= + 
binary_dir().absFileName();


A little bit late… but anyway…

I think it's not spaces in path name safe.

What about the attached patch?

Stephan



What about using toFilesystemEncoding() as well ?

Vincent

Re: lyx2lyx conversion routines

[Vincent van Ravesteijn]

Op 26-5-2013 8:53, Liviu Andronic schreef:

Hello Richard,


On Sun, May 26, 2013 at 12:24 AM, Richard Heck  wrote:

These are just whitespace issues. I've fixed them in the attached, which are
also rebased to current trunk.


I made some partial progress. I managed to apply the first patch only
after I stripped trailing spaces from the patch _and_ changed
line-endings from CRLF (Win) to LF (Unix). I guess it's a GIT-related
Windows-Linux incompatibility.


git apply "0001-Liviu-s-chunk-patch.patch"  (15337)
git apply "0001-Liviu-s-chunk-patch.patch" (15337) returned '0'

However I'm still stumbling on the second, even after the
post-processing above:

git apply "0002-A-start-on-lyx2lyx-for-chunks.patch"  (15371)

error: patch failed: lib/lyx2lyx/lyx_2_1.py:4152
error: lib/lyx2lyx/lyx_2_1.py: patch does not apply
error: patch failed: src/version.h:30
error: src/version.h: patch does not apply

git apply "0002-A-start-on-lyx2lyx-for-chunks.patch" (15371) returned '1'
I had the same error in the first try. After correcting the eol-style of 
the patch file, everything was ok again. To correct the eol-style I used 
'dos2unix' in a Git bash shell.


Vincent

Re: Change or keep Farsi splash.lyx ?

[Vincent van Ravesteijn]

Op 26-5-2013 4:47, Scott Kostyshak schreef:

It would be nice to have doc/fa/splash.lyx export correctly as it
could be used as a template for someone wanting to write in Farsi.

The current splash.lyx file does not compile for me. After reading an
email thread [1] and instructions on the wiki [2], I get the attached
LyX file, which compiles for me.


I don't see such a thing as "doc/fa/splash.lyx".


It doesn't seem correct to me because of the following issues:

I need to add the following to the LaTeX preamble manually. Should LyX
do this for me?
\DeclareTextSymbol{\guillemotright}{LFE}{62}
\DeclareTextSymbol{\guillemotleft}{LFE}{60}

The language is changed from Farsi to Arab(ArabTeX) and the document
class is changed from Article to Arabic Article. Is this right?

Nevertheless, it compiles for me and these are the settings that were
written by a user writing in Farsi.

Can Windows users get the current fa/splash.lyx to
compile (the Wiki page suggests that this should work)? Can
others compile the attached splash.lyx?


I can compile the attached splash.lyx, but the text is Left-To-Right 
instead of Right-To-Left.


Vincent

Re: [LyX master] aa.layout: updated for A 8.2

[Vincent van Ravesteijn]

Op 26-5-2013 5:29, Uwe Stöhr schreef:

The branch, master, has been updated.

- Log -

commit e28625160a5078ffb37fc27ad3906edf5a73a31f
Author: Uwe Stöhr 
Date:   Sun May 26 05:29:24 2013 +0200

 aa.layout: updated for A 8.2

diff --git a/development/FORMAT b/development/FORMAT
index 58f9016..fedfd43 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -11,6 +11,10 @@ adjustments are made to tex2lyx and bugs are fixed in 
lyx2lyx.
  
  ---
  
+2013-05-26 Uwe Stöhr 

+   * Format incremented to 472: added 2 new abstract styles to the
+ aa.layout file



Do we now really have a new file format, just because we added new 
styles to a layout ? This also means that the LyX file format is now 
hardcoded to some version of the layout files. Is this the outcome of a 
recent discussion on whether we can upgrade layout files in a stable 
release series, or is this a trick to fire lyx2lyx ?

Re: [PATCH] Pass the binary dir to the configure script to find tex2lyx

[Vincent van Ravesteijn]

Op 26-5-2013 21:30, Stephan Witt schreef:

Am 11.04.2013 um 00:23 schrieb Julien Rioux <jri...@lyx.org>:


On 30/03/2013 9:46 AM, Vincent van Ravesteijn wrote:

When using CMake, the binary files are stored in /bin. LyX can't fin 
tex2lyx with the current code. So, we have to point configure.py to explicitly look 
in the binary dir.

Any objections ?

Vincent

---
  lib/configure.py|9 -
  src/support/Package.cpp |2 +-
  2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/configure.py b/lib/configure.py
index b6c453d..2ae6ec2 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -652,7 +652,10 @@ def checkConverterEntries():
  in_place = os.path.join(srcdir, '..', 'src', 'tex2lyx', 'tex2lyx')
  in_place = os.path.abspath(in_place)

-path, t2l = checkProg('a LaTeX/Noweb -> LyX converter', [in_place, 
'tex2lyx' + version_suffix, 'tex2lyx'],
+in_binary_dir = os.path.join(lyx_binary_dir, 'tex2lyx')
+in_binary_dir = os.path.abspath(in_binary_dir)
+
+path, t2l = checkProg('a LaTeX/Noweb -> LyX converter', [in_place, 
in_place + version_suffix, in_binary_dir, in_binary_dir + version_suffix, 
'tex2lyx' + version_suffix, 'tex2lyx'],
  rc_entry = [r'''\converter latex  lyx"%% -f $$i $$o"""
  \converter literate   lyx"%% -n -m noweb -f $$i $$o"""'''], 
not_found = 'tex2lyx')
  if path == '':
@@ -1394,6 +1397,7 @@ if __name__ == '__main__':
  rc_entries = ''
  lyx_keep_temps = False
  version_suffix = ''
+lyx_binary_dir = ''
  ## Parse the command line
  for op in sys.argv[1:]:   # default shell/for list is $*, the options
  if op in [ '-help', '--help', '-h' ]:
@@ -1404,6 +1408,7 @@ Options:
  --without-kpsewhich  do not update TeX files information via kpsewhich
  --without-latex-config   do not run LaTeX to determine configuration
  --with-version-suffix=suffix suffix of binary installed files
+--binary-dir=directory   directory of binary installed files
  '''
  sys.exit(0)
  elif op == '--without-kpsewhich':
@@ -1414,6 +1419,8 @@ Options:
  lyx_keep_temps = True
  elif op[0:22] == '--with-version-suffix=':  # never mind if op is not 
long enough
  version_suffix = op[22:]
+elif op[0:13] == '--binary-dir=':
+lyx_binary_dir = op[13:]
  else:
  print "Unknown option", op
  sys.exit(1)
diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index dab008e..695e89f 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -141,7 +141,7 @@ Package::Package(string const & command_line_arg0,
FileName const configure_script(addName(system_support().absFileName(), 
"configure.py"));
configure_command_ = os::python() + ' ' +
quoteName(configure_script.toFilesystemEncoding(), 
quote_python) +
-   with_version_suffix();
+   with_version_suffix() + " --binary-dir=" + 
binary_dir().absFileName();


A little bit late… but anyway…

I think it's not "spaces in path name" safe.

What about the attached patch?

Stephan



What about using "toFilesystemEncoding()" as well ?

Vincent

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

On Fri, May 24, 2013 at 10:46 AM, Jean-Marc Lasgouttes
lasgout...@lyx.orgwrote:

 Le 24/05/13 10:28, Jean-Marc Lasgouttes a écrit :

  The branch, empty-length, has been updated.

 - Log --**--**
 -

 commit 85e391e43a6d7188683dacae729475**e77597415d
 Author: Jean-Marc Lasgouttes lasgout...@lyx.org
 Date:   Wed May 22 15:50:44 2013 +0200

  Latest changes from Uwe for tex2lyx and lyx2lyx

  I amended Uwe patches a bit, since empty width should be output as
width 
  in the LyX file.



 Could someone (Vincent?) take a look at this branch and tell me why the
 commits seem to be in random order wrt dates? What did I do wrong? Can I
 merge it as it is?

 JMarc


I've reset the branch now to the last commit you made. All commits from
master were somehow rebased or cherry-picked on top of the feature branch.

You can merge it into master by:

  git checkout master
  git merge empty-length -m Please supply a commit message instead of the
default

or you can rebase onto master and fix the history:

  git checkout empty-length
  git rebase master -i
  remove the commits that are there only because someone forgot something
in a previous commit
  git checkout master
  git merge empty-length (this will fast-forward master)

or you can rebase onto master and fix the history and make a merge commit:

  git checkout empty-length
  git rebase master -i
  remove the commits that are there only because someone forgot something
in a previous commit
  git checkout master
  git merge empty-length --commit -m Message (this will create a merge
commit)

or you can first fix history and then merge:

  git checkout empty-length
  git rebase -i `git merge-base master empty-length`
  fix history
  git checkout master
  git merge empty-length -m Please supply a commit message instead of the
default (this makes a merge commit)

Vincent

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

On Fri, May 24, 2013 at 3:00 PM, Richard Heck rgh...@lyx.org wrote:


 My procedure for doing this kind of thing is similar but avoids the last
 merge step


It is the question whether we want to have the merge commit, or we don't
want it.

If a feature consists of 20 small changes, it might be more useful to have
a single merge commit on the master branch instead of 20 to avoid
cluttering.


 git checkout mybranch
 # Make sure the history here is the way I want it to be, e.g.:
 git log
 git rebase -i HEAD~5


That's `git merge-base master`.

By the way, this doesn't always work. The kill-gettext branch, for
instance, has master merged in a few times to fix merge conflicts. Now,
rebasing onto the merge-base does do no good.



 # Now rebase against master
 git rebase master


You could just as well had rebased to master in the previous step (avoiding
the problem I stated above).


Vincent

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

Did you reset your local empty-length branch to 85e391e43 ? (That's your
last commit before hell broke loose)

Vincent


On Fri, May 24, 2013 at 3:18 PM, Jean-Marc Lasgouttes lasgout...@lyx.orgwrote:

 Le 24/05/13 12:20, Vincent van Ravesteijn a écrit :

  I've reset the branch now to the last commit you made. All commits from
 master were somehow rebased or cherry-picked on top of the feature branch.

 You can merge it into master by:

git checkout master
git merge empty-length -m Please supply a commit message instead of
 the default


 I get lots of errors like:

 Auto-merging src/tests/test_layout
 CONFLICT (add/add): Merge conflict in src/tests/test_layout
 Auto-merging src/insets/InsetBox.cpp
 Auto-merging src/frontends/qt4/qt_helpers.h
 Auto-merging src/frontends/qt4/qt_helpers.**cpp
 Auto-merging src/TextClass.cpp
 CONFLICT (content): Merge conflict in src/TextClass.cpp

 These should not happen.

 JMarc

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

On Fri, May 24, 2013 at 10:46 AM, Jean-Marc Lasgouttes
wrote:

> Le 24/05/13 10:28, Jean-Marc Lasgouttes a écrit :
>
>  The branch, empty-length, has been updated.
>>
>> - Log --**--**
>> -
>>
>> commit 85e391e43a6d7188683dacae729475**e77597415d
>> Author: Jean-Marc Lasgouttes 
>> Date:   Wed May 22 15:50:44 2013 +0200
>>
>>  Latest changes from Uwe for tex2lyx and lyx2lyx
>>
>>  I amended Uwe patches a bit, since empty width should be output as
>>width ""
>>  in the LyX file.
>>
>
>
> Could someone (Vincent?) take a look at this branch and tell me why the
> commits seem to be in random order wrt dates? What did I do wrong? Can I
> merge it as it is?
>
> JMarc
>

I've reset the branch now to the last commit you made. All commits from
master were somehow rebased or cherry-picked on top of the feature branch.

You can merge it into master by:

  git checkout master
  git merge empty-length -m "Please supply a commit message instead of the
default"

or you can rebase onto master and fix the history:

  git checkout empty-length
  git rebase master -i
  
  git checkout master
  git merge empty-length (this will fast-forward master)

or you can rebase onto master and fix the history and make a merge commit:

  git checkout empty-length
  git rebase master -i
  
  git checkout master
  git merge empty-length --commit -m "Message" (this will create a merge
commit)

or you can first fix history and then merge:

  git checkout empty-length
  git rebase -i `git merge-base master empty-length`
  
  git checkout master
  git merge empty-length -m "Please supply a commit message instead of the
default" (this makes a merge commit)

Vincent

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

On Fri, May 24, 2013 at 3:00 PM, Richard Heck  wrote:

>
> My procedure for doing this kind of thing is similar but avoids the last
> merge step
>

It is the question whether we want to have the merge commit, or we don't
want it.

If a feature consists of 20 small changes, it might be more useful to have
a single merge commit on the master branch instead of 20 to avoid
cluttering.


> git checkout mybranch
> # Make sure the history here is the way I want it to be, e.g.:
> git log
> git rebase -i HEAD~5
>

That's `git merge-base master`.

By the way, this doesn't always work. The kill-gettext branch, for
instance, has master merged in a few times to fix merge conflicts. Now,
rebasing onto the merge-base does do no good.



> # Now rebase against master
> git rebase master
>

You could just as well had rebased to master in the previous step (avoiding
the problem I stated above).


Vincent

Re: [LyX features/empty-length] Latest changes from Uwe for tex2lyx and lyx2lyx

[Vincent van Ravesteijn]

Did you reset your local empty-length branch to 85e391e43 ? (That's your
last commit before hell broke loose)

Vincent


On Fri, May 24, 2013 at 3:18 PM, Jean-Marc Lasgouttes <lasgout...@lyx.org>wrote:

> Le 24/05/13 12:20, Vincent van Ravesteijn a écrit :
>
>  I've reset the branch now to the last commit you made. All commits from
>> master were somehow rebased or cherry-picked on top of the feature branch.
>>
>> You can merge it into master by:
>>
>>git checkout master
>>git merge empty-length -m "Please supply a commit message instead of
>> the default"
>>
>
> I get lots of errors like:
>
> Auto-merging src/tests/test_layout
> CONFLICT (add/add): Merge conflict in src/tests/test_layout
> Auto-merging src/insets/InsetBox.cpp
> Auto-merging src/frontends/qt4/qt_helpers.h
> Auto-merging src/frontends/qt4/qt_helpers.**cpp
> Auto-merging src/TextClass.cpp
> CONFLICT (content): Merge conflict in src/TextClass.cpp
>
> These should not happen.
>
> JMarc
>

Re: RFC - offer users to set preferred float paragraph style

[Vincent van Ravesteijn]

Op 23-5-2013 2:15, Uwe Stöhr schreef:

Am 22.05.2013 07:38, schrieb Vincent van Ravesteijn:

The setting is somewhat between the the document settings and the 
preferences. The idea is to
change only the way NEW floats are inserted. Existing floats will 
not be changed by this setting.


If you would have read what I and Jurgen wrote before, this is 
exactly what we do NOT want.


I read his post carefully. I think I made it clear with my example why 
I don't agree with you here and why Ithink that 2 different features 
are needed. What do you think is wrong in my example?




Your example is not very good. What you describe in the example can be 
done perfectly with what Jurgen proposed.


For the reason that in many cases one or a few floats needs to have 
another alignment than all other floats, my setting does not change 
existing floats. 


This is not a valid reason. Jurgen's options changes existing floats, 
but only those that have the default alignment. If you've manually 
changed the alignment to be left aligned, the float will not be touched. 
So, this is not a justification for a setting that only influences new 
floats.


I really do not want an option that says how new floats are aligned. I 
do not expect this to be a property of the document. I have explained 
before why. If you do not agree, then discuss our arguments. Of course, 
for every possible workflow, one can think of an example that will work 
perfectly.


Vincent

Re: [LyX master] Add support for package options in layout files. E.g.: PackageOption tipa safe will load tipa with the safe option, if we load it.

[Vincent van Ravesteijn]

Op 23-5-2013 15:35, Richard Heck schreef:

The branch, master, has been updated.

- Log -

commit 1230372566dc571fbf76adca00453d2c6009d52b
Author: Richard Heck rgh...@lyx.org
Date:   Thu May 23 09:25:40 2013 -0400

 Add support for package options in layout files. E.g.:
PackageOption tipa safe will load tipa with the
  safe option, if we load it.




Does this require a file format bump ?

Vincent

Re: RFC - offer users to set preferred float paragraph style

[Vincent van Ravesteijn]

Op 23-5-2013 2:15, Uwe Stöhr schreef:

Am 22.05.2013 07:38, schrieb Vincent van Ravesteijn:

The setting is somewhat between the the document settings and the 
preferences. The idea is to
change only the way NEW floats are inserted. Existing floats will 
not be changed by this setting.


If you would have read what I and Jurgen wrote before, this is 
exactly what we do NOT want.


I read his post carefully. I think I made it clear with my example why 
I don't agree with you here and why Ithink that 2 different features 
are needed. What do you think is wrong in my example?




Your example is not very good. What you describe in the example can be 
done perfectly with what Jurgen proposed.


For the reason that in many cases one or a few floats needs to have 
another alignment than all other floats, my setting does not change 
existing floats. 


This is not a valid reason. Jurgen's options changes existing floats, 
but only those that have the "default" alignment. If you've manually 
changed the alignment to be left aligned, the float will not be touched. 
So, this is not a justification for a setting that only influences new 
floats.


I really do not want an option that says how new floats are aligned. I 
do not expect this to be a property of the document. I have explained 
before why. If you do not agree, then discuss our arguments. Of course, 
for every possible workflow, one can think of an example that will work 
perfectly.


Vincent

Re: [LyX master] Add support for package options in layout files. E.g.: PackageOption tipa safe will load tipa with the "safe" option, if we load it.

[Vincent van Ravesteijn]

Op 23-5-2013 15:35, Richard Heck schreef:

The branch, master, has been updated.

- Log -

commit 1230372566dc571fbf76adca00453d2c6009d52b
Author: Richard Heck 
Date:   Thu May 23 09:25:40 2013 -0400

 Add support for package options in layout files. E.g.:
PackageOption tipa safe will load tipa with the
  "safe" option, if we load it.




Does this require a file format bump ?

Vincent

Re: LyX 2.1 beta 1: due in two weeks

[Vincent van Ravesteijn]

Op 22-5-2013 9:29, Jerry schreef:


The recent work to correct slow scrolling is not included?
Jerry


I'm not sure I know which work you mean. Besides, is this really a new 
feature or just a bugfix ?


Vincent

Re: LyX 2.1 beta 1: due in two weeks

[Vincent van Ravesteijn]

Op 22-5-2013 9:29, Jerry schreef:


The recent work to correct slow scrolling is not included?
Jerry


I'm not sure I know which work you mean. Besides, is this really a new 
feature or just a bugfix ?


Vincent

Re: [LyX master] Support out of source tests in tex2lyx test runner

[Vincent van Ravesteijn]

#cp /usr/BUILD/BuildLyxGit/src/tex2lyx/test/CJKutf8.lyx 
/usr/src/lyx/lyx-git/src/tex2lyx/test/CJKutf8.lyx.lyx





Does this mean I have to manually copy and rename each file ?

I would be useful to have a CMake target just like the autotools target 
updatetests that will automatically overwrite the test cases.


Vincent

Re: [LyX master] Support out of source tests in tex2lyx test runner

[Vincent van Ravesteijn]

Op 21-5-2013 9:38, Kornel Benko schreef:


Am Dienstag, 21. Mai 2013 um 08:16:53, schrieb Vincent van Ravesteijn 
v...@lyx.org




  #cp /usr/BUILD/BuildLyxGit/src/tex2lyx/test/CJKutf8.lyx

  /usr/src/lyx/lyx-git/src/tex2lyx/test/CJKutf8.lyx.lyx

 

 



 Does this mean I have to manually copy and rename each file ?

Yes.

 I would be useful to have a CMake target just like the autotools target

 updatetests that will automatically overwrite the test cases.

It should be doable, but I am reluctant. I do not like to change 
automatically


anything in the source tree. One _has_ to (manually!) check first, if 
the change


is really OK, or if it is an error in tex2lyx.



Yes, but is not doable to copy paste numerous files manually. You should 
check it before committing of course, but that just means running 'git 
diff'. Imagine we will have tex2lyx test cases for each file format 
change, soon it will be impossible to do this manually. Besides, we can 
just use 'make updatetests'.


Vincent

LyX 2.1 beta 1: due in two weeks

[Vincent van Ravesteijn]

Dear all,

It seems that the current master has survived the Lyx Developer's 
Meeting and is still in good shape. Therefore, I intend to release the 
first beta of LyX 2.1 during the first weekend of June. In the meantime, 
the last topics can be finished, the documentation can be updated, the 
translations can be updated, and the release can be prepared.


From now on, I would like to freeze the current master and to only allow:
- important bugfixes, and
- a few remaining topics that are 'in flight'
(I will send a separate mail about which topics I know that are being 
prepared for LyX2.1)


Development of new features and/or fixes that can wait for LyX 2.1.x, or 
2.2.0, can take place in the new features repository.


Please have a look at http://wiki.lyx.org/LyX/NewInLyX21; and help to 
complete the list of new features as much as possible. Maybe Uwe would 
also appreciate some help to document the new features.


Depending on the feedback we get about this beta release, I will decide 
on whether there will be more betas, or we will jump to the final LyX 
2.1 release.


Please let me know if you have any remarks.

Vincent

Re: LyX 2.1 beta 1: due in two weeks

[Vincent van Ravesteijn]

On Tue, May 21, 2013 at 11:12 AM, Pavel Sanda sa...@lyx.org wrote:

 Vincent van Ravesteijn wrote:
  (I will send a separate mail about which topics I know that are being
  prepared for LyX2.1)

 I plan to finish the cleanup of includes in our headers/cpp files.


 Next thing I would like to do after string freeze is to go through all new
 strings and check their correctness, shouldn't be much disruptive, but
 might
 need one more release iteration for translators.

  Depending on the feedback we get about this beta release, I will decide
 on
  whether there will be more betas, or we will jump to the final LyX 2.1
  release.
 
  Please let me know if you have any remarks.


 I didn't get whether by jump to the final LyX 2.1 you mean release
 candidate
 or 2.1 release. What I have seen in previous final releases is that you
 need
 more iterations not just because of bugs but to let packagers fix *their*
 issues, so just single beta and final release is not good idea in case you
 meant it.


There must be a reason to release intermediate versions. If packagers have
problems, this could be one of the reasons.




 Also if you are heading towards final freezing it would be nicer if we know
 the time schedule sooner than 2 weeks ahead.


Yes, a nice schedule is always better. On the other hand, if people do have
new features that they definitely want to have in 2.1, they should have
communicate about it in an earlier stage when I asked for it, or they
should make sure they finish it on a two weeks notice. I asked a few months
ago what features people wanted to get in, and I'm still waiting for those
features to get ready. I can't ask again now, and wait until all new
features that are proposed now will be ready, and then ask again... etc.

Vincent

Re: LyX 2.1 beta 1: due in two weeks

[Vincent van Ravesteijn]

On Tue, May 21, 2013 at 11:12 AM, Pavel Sanda sa...@lyx.org wrote:

 Vincent van Ravesteijn wrote:
  (I will send a separate mail about which topics I know that are being
  prepared for LyX2.1)

 I plan to finish the cleanup of includes in our headers/cpp files.


Is there any urgency to do this before 2.1 release ?

Vincent

Re: RFC - offer users to set preferred float paragraph style

[Vincent van Ravesteijn]

Op 22-5-2013 1:40, Uwe Stöhr schreef:

Am 17.05.2013 10:24, schrieb Jürgen Spitzmüller:


Opinions, further proposals?


I'm fine with it as long as
a.) the default is what the classes does (i.e., always center 
content is an

opt-in, not an opt-out)


Sure. We need a layout tag to tell what the class default is.

To clarify the concept of my idea:

The setting is somewhat between the the document settings and the 
preferences. The idea is to change only the way NEW floats are 
inserted. Existing floats will not be changed by this setting.


If you would have read what I and Jurgen wrote before, this is exactly 
what we do NOT want.


Vincent

Re: [LyX master] Support out of source tests in tex2lyx test runner

[Vincent van Ravesteijn]

#cp /usr/BUILD/BuildLyxGit/src/tex2lyx/test/CJKutf8.lyx 
/usr/src/lyx/lyx-git/src/tex2lyx/test/CJKutf8.lyx.lyx





Does this mean I have to manually copy and rename each file ?

I would be useful to have a CMake target just like the autotools target 
"updatetests" that will automatically overwrite the test cases.


Vincent

Re: [LyX master] Support out of source tests in tex2lyx test runner

[Vincent van Ravesteijn]

Op 21-5-2013 9:38, Kornel Benko schreef:


Am Dienstag, 21. Mai 2013 um 08:16:53, schrieb Vincent van Ravesteijn 
<v...@lyx.org>


>

> > #cp /usr/BUILD/BuildLyxGit/src/tex2lyx/test/CJKutf8.lyx

> > /usr/src/lyx/lyx-git/src/tex2lyx/test/CJKutf8.lyx.lyx

> >

> >

>

> Does this mean I have to manually copy and rename each file ?

Yes.

> I would be useful to have a CMake target just like the autotools target

> "updatetests" that will automatically overwrite the test cases.

It should be doable, but I am reluctant. I do not like to change 
automatically


anything in the source tree. One _has_ to (manually!) check first, if 
the change


is really OK, or if it is an error in tex2lyx.



Yes, but is not doable to copy paste numerous files manually. You should 
check it before committing of course, but that just means running 'git 
diff'. Imagine we will have tex2lyx test cases for each file format 
change, soon it will be impossible to do this manually. Besides, we can 
just use 'make updatetests'.


Vincent

LyX 2.1 beta 1: due in two weeks

[Vincent van Ravesteijn]

Dear all,

It seems that the current master has survived the Lyx Developer's 
Meeting and is still in good shape. Therefore, I intend to release the 
first beta of LyX 2.1 during the first weekend of June. In the meantime, 
the last topics can be finished, the documentation can be updated, the 
translations can be updated, and the release can be prepared.


From now on, I would like to freeze the current master and to only allow:
- important bugfixes, and
- a few remaining topics that are 'in flight'
(I will send a separate mail about which topics I know that are being 
prepared for LyX2.1)


Development of new features and/or fixes that can wait for LyX 2.1.x, or 
2.2.0, can take place in the new features repository.


Please have a look at "http://wiki.lyx.org/LyX/NewInLyX21; and help to 
complete the list of new features as much as possible. Maybe Uwe would 
also appreciate some help to document the new features.


Depending on the feedback we get about this beta release, I will decide 
on whether there will be more betas, or we will jump to the final LyX 
2.1 release.


Please let me know if you have any remarks.

Vincent

Re: LyX 2.1 beta 1: due in two weeks

[Vincent van Ravesteijn]

On Tue, May 21, 2013 at 11:12 AM, Pavel Sanda <sa...@lyx.org> wrote:

> Vincent van Ravesteijn wrote:
> > (I will send a separate mail about which topics I know that are being
> > prepared for LyX2.1)
>
> I plan to finish the cleanup of includes in our headers/cpp files.
>

> Next thing I would like to do after string freeze is to go through all new
> strings and check their correctness, shouldn't be much disruptive, but
> might
> need one more release iteration for translators.
>
> > Depending on the feedback we get about this beta release, I will decide
> on
> > whether there will be more betas, or we will jump to the final LyX 2.1
> > release.
> >
> > Please let me know if you have any remarks.
>
>
> I didn't get whether by "jump to the final LyX 2.1" you mean release
> candidate
> or 2.1 release. What I have seen in previous final releases is that you
> need
> more iterations not just because of bugs but to let packagers fix *their*
> issues, so just single beta and final release is not good idea in case you
> meant it.
>

There must be a reason to release intermediate versions. If packagers have
problems, this could be one of the reasons.



>
> Also if you are heading towards final freezing it would be nicer if we know
> the time schedule sooner than 2 weeks ahead.
>
>
Yes, a nice schedule is always better. On the other hand, if people do have
new features that they definitely want to have in 2.1, they should have
communicate about it in an earlier stage when I asked for it, or they
should make sure they finish it on a two weeks notice. I asked a few months
ago what features people wanted to get in, and I'm still waiting for those
features to get ready. I can't ask again now, and wait until all new
features that are proposed now will be ready, and then ask again... etc.

Vincent

Re: LyX 2.1 beta 1: due in two weeks

[Vincent van Ravesteijn]

On Tue, May 21, 2013 at 11:12 AM, Pavel Sanda <sa...@lyx.org> wrote:

> Vincent van Ravesteijn wrote:
> > (I will send a separate mail about which topics I know that are being
> > prepared for LyX2.1)
>
> I plan to finish the cleanup of includes in our headers/cpp files.
>

Is there any urgency to do this before 2.1 release ?

Vincent

Re: RFC - offer users to set preferred float paragraph style

[Vincent van Ravesteijn]

Op 22-5-2013 1:40, Uwe Stöhr schreef:

Am 17.05.2013 10:24, schrieb Jürgen Spitzmüller:


Opinions, further proposals?


I'm fine with it as long as
a.) the default is what the classes does (i.e., "always center 
content" is an

opt-in, not an opt-out)


Sure. We need a layout tag to tell what the class default is.

To clarify the concept of my idea:

The setting is somewhat between the the document settings and the 
preferences. The idea is to change only the way NEW floats are 
inserted. Existing floats will not be changed by this setting.


If you would have read what I and Jurgen wrote before, this is exactly 
what we do NOT want.


Vincent

Re: [LyX master] Support out of source tests in tex2lyx test runner

[Vincent van Ravesteijn]

Op 30-11-2012 9:57, Kornel Benko schreef:


Am Donnerstag, 29. November 2012 um 21:51:17, schrieb Georg Baum 
georg.b...@post.rwth-aachen.de


 Kornel Benko wrote:



  Hi Georg,

  how about automatic conversion of of lyx files before checking for

  difference?

 

  Something like the attached works for me. And does not depend on 
format of


  provided lyx-files.



 This makes the tests less effective. If somebody updates the file 
format, he


 should check tex2lyx as well and update the test references at the same

 time. If all is fine, updating the references is as easy as

I am not sure, I understand. This patch effectively converts

1.) provided lyx-files (test references) to new file format, this 
should not be controversial


2.) generated lyx-files (with tex2lyx). This should not be needed

so only the second point is unclear.

 pushd buildtree/src/tex2lyx

 make updatetests

 popd

 with autotools (and cmake should have a similar command).

In cmake:

pushd buildtree

make test

popd


This command does not update the test cases, it just runs the tests.. 
right ?


How can I update the test cases using CMake ?

Vincent

Re: [LyX master] Support out of source tests in tex2lyx test runner

[Vincent van Ravesteijn]

Op 30-11-2012 9:57, Kornel Benko schreef:


Am Donnerstag, 29. November 2012 um 21:51:17, schrieb Georg Baum 



> Kornel Benko wrote:

>

> > Hi Georg,

> > how about automatic conversion of of lyx files before checking for

> > difference?

> >

> > Something like the attached works for me. And does not depend on 
format of


> > provided lyx-files.

>

> This makes the tests less effective. If somebody updates the file 
format, he


> should check tex2lyx as well and update the test references at the same

> time. If all is fine, updating the references is as easy as

I am not sure, I understand. This patch effectively converts

1.) provided lyx-files (test references) to new file format, this 
should not be controversial


2.) generated lyx-files (with tex2lyx). This should not be needed

so only the second point is unclear.

> pushd /src/tex2lyx

> make updatetests

> popd

> with autotools (and cmake should have a similar command).

In cmake:

pushd 

make test

popd


This command does not update the test cases, it just runs the tests.. 
right ?


How can I update the test cases using CMake ?

Vincent

Re: [LyX master] support for \mbox and \fbox

[Vincent van Ravesteijn]

Op 19-5-2013 3:29, Uwe Stöhr schreef:


The best would be that you commit your changes in the 
features/empty-length branch, which
would allow me to see what happens. When everything is finished, you 
can merge this branch into

master. This is the workflow that was proposed in Milano.


Yes, but nobody could me explain how this is done. I asked Lars but he 
uses command-line only. I cannot see your branch so how can I checkout 
it? Where is it (address)?


I will play with feature branches as I promised Lars but not for this 
issue because this must go in before the first beta of LyX 2.1 meaning 
now. (I have troubles with the latest version of TortoiseGit so it 
might take longer until I can use feature branches.)

(I will send you another mail with all files.)


First, you should read the wiki. Second, you will have to figure out 
yourself how to do this with TortoiseGit, because no-one else uses this 
and you really cannot expect others to install software just to find the 
correct button for you.


Because I'm in a good mood:

1) Create a remote in your local clone of |lyx| upstream repository:
- Right-click on the directory containing your clone of the lyx repo
- Choose TortoiseGit-Settings-Git-Remote.
- Fill in the form:
  * Remote: features
  * URL: g...@git.lyx.org:features
  * Press Add new

2) Use git fetch features to get updates to the feature branches:
- Right-click on the directory containing your clone of the lyx repo
- Choose TortoiseGit-Fetch.
- Fill out the form:
  * Remote: features or all
- Press OK.

3) Now you will see the feature branches as well:
- Right-click on the directory containing your clone of the lyx repo
- Choose TortoiseGit-Switch/Checkout
- Look in the Branch combobox and there are the branches 
remotes/features/branch


Vincent

Re: [LyX master] Fix assertion for InsetInfos of icon types

[Vincent van Ravesteijn]

Op 17-5-2013 21:53, Scott Kostyshak schreef:

On Sun, Apr 28, 2013 at 3:50 PM, Vincent van Ravesteijn v...@lyx.org wrote:
I cannot export the Spanish User Guide with pdflatex. A bisect led me 
here.


Any thoughts?

Scott 


Fixed with f8a5d7c..30f5187.

Vincent

Re: Bug during Lyx startup

[Vincent van Ravesteijn]

Op 18-5-2013 23:24, Jürgen Lange schreef:

Hello,

found a rare bug during startup of Lyx (happens only approx. in 1 of 
20 starts):

Lyx ist abgestürzt; SIGSEGV-Signal empfangen.
Lyx konnte kein temporäres Verzeichnis ... /local/Temp/lyx_tmpbuf0 
erstellen (Festplatte ist vielleicht voll?)

Disk is not full!
System: Windows 7 / Lyx 2.0.6

Greetings

--
You probably have a lot of temporary LyX directories in your local/Temp 
directory.


If you remove those, the problem will go away.

Vincent

Re: Bug during Lyx startup

[Vincent van Ravesteijn]

Op 19-5-2013 13:24, Vincent van Ravesteijn schreef:

Op 18-5-2013 23:24, Jürgen Lange schreef:

Hello,

found a rare bug during startup of Lyx (happens only approx. in 1 of 
20 starts):

Lyx ist abgestürzt; SIGSEGV-Signal empfangen.
Lyx konnte kein temporäres Verzeichnis ... /local/Temp/lyx_tmpbuf0 
erstellen (Festplatte ist vielleicht voll?)

Disk is not full!
System: Windows 7 / Lyx 2.0.6

Greetings

--
You probably have a lot of temporary LyX directories in your 
local/Temp directory.


If you remove those, the problem will go away.

Vincent



I now further reduced the chance of conflict by seeding the Qt's random 
number generator, and by increasing the number of random characters in 
the temporary filename.


See commits 30f5187..762c4ec.

Vincent

Re: [LyX master] Increase the uniqueness of the temp directories

[Vincent van Ravesteijn]

Op 19-5-2013 21:07, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

commit 762c4eca5734b4d504ab28308a10d725a4790d5c
Author: Vincent van Ravesteijn v...@lyx.org
Date:   Sun May 19 14:07:14 2013 +0200

 Increase the uniqueness of the temp directories
 
 Now, the temporary directories are composed of the PID + 8 random

 characters. This used to be the PID + 2 random characters.
 
 See also 327f7ed90dbcaad92511b962a8d1d14b46ef552a.


diff --git a/src/support/FileName.cpp b/src/support/FileName.cpp
index fa8cdac..f048930 100644
--- a/src/support/FileName.cpp
+++ b/src/support/FileName.cpp
@@ -443,7 +443,7 @@ static string createTempFile(QString const  mask)
//same file again. To make this safe the QTemporaryFile object
//needs to be kept for the whole life time of the temp file 
name.
//This can be achieved by using the TempFile class.
-   QTemporaryFile qt_tmp(mask);
+   QTemporaryFile qt_tmp(mask + .);
if (qt_tmp.open()) {
string const temp_file = fromqstr(qt_tmp.fileName());
LYXERR(Debug::FILES, Temporary file `  temp_file  ' 
created.);

You mean that QTemporaryFile doesn't find unused file name from time to time?
It shouldn't be according to qt docs.
Pavel


Maybe, this won't occur anymore after I seeded Qt's random number 
generator.  That was the most important part of the fix.


Vincent

Re: [LyX master] support for \mbox and \fbox

[Vincent van Ravesteijn]

Op 19-5-2013 3:29, Uwe Stöhr schreef:


The best would be that you commit your changes in the 
features/empty-length branch, which
would allow me to see what happens. When everything is finished, you 
can merge this branch into

master. This is the workflow that was proposed in Milano.


Yes, but nobody could me explain how this is done. I asked Lars but he 
uses command-line only. I cannot see your branch so how can I checkout 
it? Where is it (address)?


I will play with feature branches as I promised Lars but not for this 
issue because this must go in before the first beta of LyX 2.1 meaning 
now. (I have troubles with the latest version of TortoiseGit so it 
might take longer until I can use feature branches.)

(I will send you another mail with all files.)


First, you should read the wiki. Second, you will have to figure out 
yourself how to do this with TortoiseGit, because no-one else uses this 
and you really cannot expect others to install software just to find the 
correct button for you.


Because I'm in a good mood:

1) Create a remote in your local clone of |lyx| upstream repository:
- Right-click on the directory containing your clone of the lyx repo
- Choose TortoiseGit->Settings->Git->Remote.
- Fill in the form:
  * Remote: features
  * URL: g...@git.lyx.org:features
  * Press "Add new"

2) Use git fetch features to get updates to the feature branches:
- Right-click on the directory containing your clone of the lyx repo
- Choose TortoiseGit->Fetch.
- Fill out the form:
  * Remote: features or all
- Press OK.

3) Now you will see the feature branches as well:
- Right-click on the directory containing your clone of the lyx repo
- Choose TortoiseGit->Switch/Checkout
- Look in the Branch combobox and there are the branches 
"remotes/features/"


Vincent

Re: [LyX master] Fix assertion for InsetInfos of icon types

[Vincent van Ravesteijn]

Op 17-5-2013 21:53, Scott Kostyshak schreef:

On Sun, Apr 28, 2013 at 3:50 PM, Vincent van Ravesteijn <v...@lyx.org> wrote:
I cannot export the Spanish User Guide with pdflatex. A bisect led me 
here.


Any thoughts?

Scott 


Fixed with f8a5d7c..30f5187.

Vincent

Re: Bug during Lyx startup

[Vincent van Ravesteijn]

Op 18-5-2013 23:24, Jürgen Lange schreef:

Hello,

found a rare bug during startup of Lyx (happens only approx. in 1 of 
20 starts):

"Lyx ist abgestürzt; SIGSEGV-Signal empfangen."
Lyx konnte kein temporäres Verzeichnis "... /local/Temp/lyx_tmpbuf0" 
erstellen (Festplatte ist vielleicht voll?)

Disk is not full!
System: Windows 7 / Lyx 2.0.6

Greetings

--
You probably have a lot of temporary LyX directories in your local/Temp 
directory.


If you remove those, the problem will go away.

Vincent

Re: Bug during Lyx startup

[Vincent van Ravesteijn]

Op 19-5-2013 13:24, Vincent van Ravesteijn schreef:

Op 18-5-2013 23:24, Jürgen Lange schreef:

Hello,

found a rare bug during startup of Lyx (happens only approx. in 1 of 
20 starts):

"Lyx ist abgestürzt; SIGSEGV-Signal empfangen."
Lyx konnte kein temporäres Verzeichnis "... /local/Temp/lyx_tmpbuf0" 
erstellen (Festplatte ist vielleicht voll?)

Disk is not full!
System: Windows 7 / Lyx 2.0.6

Greetings

--
You probably have a lot of temporary LyX directories in your 
local/Temp directory.


If you remove those, the problem will go away.

Vincent



I now further reduced the chance of conflict by seeding the Qt's random 
number generator, and by increasing the number of random characters in 
the temporary filename.


See commits 30f5187..762c4ec.

Vincent

Re: [LyX master] Increase the uniqueness of the temp directories

[Vincent van Ravesteijn]

Op 19-5-2013 21:07, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

commit 762c4eca5734b4d504ab28308a10d725a4790d5c
Author: Vincent van Ravesteijn <v...@lyx.org>
Date:   Sun May 19 14:07:14 2013 +0200

 Increase the uniqueness of the temp directories
 
 Now, the temporary directories are composed of the PID + 8 random

 characters. This used to be the PID + 2 random characters.
 
 See also 327f7ed90dbcaad92511b962a8d1d14b46ef552a.


diff --git a/src/support/FileName.cpp b/src/support/FileName.cpp
index fa8cdac..f048930 100644
--- a/src/support/FileName.cpp
+++ b/src/support/FileName.cpp
@@ -443,7 +443,7 @@ static string createTempFile(QString const & mask)
//same file again. To make this safe the QTemporaryFile object
//needs to be kept for the whole life time of the temp file 
name.
//This can be achieved by using the TempFile class.
-   QTemporaryFile qt_tmp(mask);
+   QTemporaryFile qt_tmp(mask + ".");
if (qt_tmp.open()) {
string const temp_file = fromqstr(qt_tmp.fileName());
LYXERR(Debug::FILES, "Temporary file `" << temp_file << "' 
created.");

You mean that QTemporaryFile doesn't find unused file name from time to time?
It shouldn't be according to qt docs.
Pavel


Maybe, this won't occur anymore after I seeded Qt's random number 
generator.  That was the most important part of the fix.


Vincent

Fwd: LyX convention for squash vs. merge/rebase?

[Vincent van Ravesteijn]

-- Forwarded message --
From: Vincent van Ravesteijn v...@lyx.org
Date: Fri, May 17, 2013 at 7:47 AM
Subject: Re: LyX convention for squash vs. merge/rebase?
To: Scott Kostyshak skost...@lyx.org



On Fri, May 17, 2013 at 5:11 AM, Scott Kostyshak skost...@lyx.org wrote:

 On Thu, May 16, 2013 at 8:34 PM, Cyrille Artho c.ar...@aist.go.jp wrote:
  Hi Scott,
  IMHO many small commits are almost always a lot better.
 
  git bisect can be very useful in tracking down problems when you have
 many
  small commits. With a single huge commit, that feature is almost useless.
 
  This benefit alone outweighs the small drawback of having multiple commit
  messages. (If you used meaningful messages during your commits, they in
  themselves can also be helpful.)

 Thanks for your comments Cyrille. I committed the series here:
 0d434033..43d71022

 I'd still be interested in what others prefer for the future.

In general I like to split up things, especially if it reflects the thought
process of a change, or if things get added step-by-step, such that the
individual commits are much more comprehensible. But, I am not interested
in commits that indicate that someone changed his mind a few times, or that
he was forgotten to do something or did it wrong in the first place. For
example, a commit like English tweaks shouldn't be there in general, but
in this case it makes sense because you show what you changed in the
original patch of Yihui.

A separate thing is that we might want to merge in such a change. That
would cause the master branch to have much fewer commits (if you use
--first-parent-only).
Vincent

Re: LyX convention for squash vs. merge/rebase?

[Vincent van Ravesteijn]

  A separate thing is that we might want to merge in such a change. That
 would
  cause the master branch to have much fewer commits (if you use
  --first-parent-only).

 OK, I would like to start doing this because it is the most
 informative of how the development happened. In addition to preserving
 the thought process, it also shows what commit I was working off of.


Why would it be interesting what commit you were working off of ?



 But I've seen some LyX developers express a distaste for an empty
 (which really it is not) merge commit. For example, in the following
 link at several points it recommends rebasing over merging:
 http://wiki.lyx.org/Devel/Git

 Scott


AFAICS it only mentions that you should not create a merge commit because
you pulled the new master in. This is just an error, and these merges are
only annoying.

Vincent

Re: RFC - offer users to set preferred float paragraph style

[Vincent van Ravesteijn]

Op 17-5-2013 10:28, Jürgen Spitzmüller schreef:

Vincent van Ravesteijn wrote:

Hmm.. A document setting that doesn't say anything about the document,
but just how LyX interacts with it.

Huh? What about font sizes, margins, line height and all this stuff?
Huh ? If I change the font size, the margin, or the line height, the 
document will look different. Uwe was talking about a setting that only 
affects _new_ floats, which means that the new floats will probably look 
different as the old ones.


I just want it to be globally settable and not hardcoded for each float, 
just as you said.


Vincent

Fwd: LyX convention for squash vs. merge/rebase?

[Vincent van Ravesteijn]

-- Forwarded message --
From: Vincent van Ravesteijn <v...@lyx.org>
Date: Fri, May 17, 2013 at 7:47 AM
Subject: Re: LyX convention for squash vs. merge/rebase?
To: Scott Kostyshak <skost...@lyx.org>



On Fri, May 17, 2013 at 5:11 AM, Scott Kostyshak <skost...@lyx.org> wrote:

> On Thu, May 16, 2013 at 8:34 PM, Cyrille Artho <c.ar...@aist.go.jp> wrote:
> > Hi Scott,
> > IMHO many small commits are almost always a lot better.
> >
> > "git bisect" can be very useful in tracking down problems when you have
> many
> > small commits. With a single huge commit, that feature is almost useless.
> >
> > This benefit alone outweighs the small drawback of having multiple commit
> > messages. (If you used meaningful messages during your commits, they in
> > themselves can also be helpful.)
>
> Thanks for your comments Cyrille. I committed the series here:
> 0d434033..43d71022
>
> I'd still be interested in what others prefer for the future.
>
In general I like to split up things, especially if it reflects the thought
process of a change, or if things get added step-by-step, such that the
individual commits are much more comprehensible. But, I am not interested
in commits that indicate that someone changed his mind a few times, or that
he was forgotten to do something or did it wrong in the first place. For
example, a commit like "English tweaks" shouldn't be there in general, but
in this case it makes sense because you show what you changed in the
original patch of Yihui.

A separate thing is that we might want to merge in such a change. That
would cause the master branch to have much fewer commits (if you use
--first-parent-only).
Vincent

Re: LyX convention for squash vs. merge/rebase?

[Vincent van Ravesteijn]

> > A separate thing is that we might want to merge in such a change. That
> would
> > cause the master branch to have much fewer commits (if you use
> > --first-parent-only).
>
> OK, I would like to start doing this because it is the most
> informative of how the development happened. In addition to preserving
> the thought process, it also shows what commit I was working off of.
>

Why would it be interesting what commit you were working off of ?



> But I've seen some LyX developers express a distaste for an "empty"
> (which really it is not) merge commit. For example, in the following
> link at several points it recommends rebasing over merging:
> http://wiki.lyx.org/Devel/Git
>
> Scott
>

AFAICS it only mentions that you should not create a merge commit because
you pulled the new master in. This is just an error, and these merges are
only annoying.

Vincent

Re: RFC - offer users to set preferred float paragraph style

[Vincent van Ravesteijn]

Op 17-5-2013 10:28, Jürgen Spitzmüller schreef:

Vincent van Ravesteijn wrote:

Hmm.. A document setting that doesn't say anything about the document,
but just how LyX interacts with it.

Huh? What about font sizes, margins, line height and all this stuff?
Huh ? If I change the font size, the margin, or the line height, the 
document will look different. Uwe was talking about a setting that only 
affects _new_ floats, which means that the new floats will probably look 
different as the old ones.


I just want it to be globally settable and not hardcoded for each float, 
just as you said.


Vincent

Re: RFC - offer users to set preferred float paragraph style

[Vincent van Ravesteijn]

Op 16-5-2013 22:15, Uwe Stöhr schreef:

Dear colleagues,

we often discussed in the past about the default paragraph alignment 
for new floats. We had the discussion in Milano as well because this 
is one of the most annoying things for many users. We voted to do 
something.


That's the real politics. Voting to do something, but not deciding on 
what we're going to do.



The question is now how. Here is my proposal:

- we add a document-wide setting where th user can set how he wants to 
have new floats
- this is a document setting not a LyX preference because different 
documents may require different settings.


Hmm.. A document setting that doesn't say anything about the document, 
but just how LyX interacts with it. That doesn't feel right. I think the 
change tracking setting is already annoying enough. Why do you think 
different documents require different settings ? Either you like them 
centered, or not. Maybe this could be related to different document 
classes, but then the document classes should dictate what the default 
alignment is.


  * is the caption below the image/table or above (For example the 
common typesetting rule is that figure captions are below while table 
captions are above. Getting this right for every float is currently a 
pain.)

Any idea how you're going to enforce this setting in LyX ?


  * the alignment of the paragraph in new floats
I'd rather see that the new floats get set a default alignment. And a 
document setting to change the default of all existing floats. I will 
probably not remember to do this every time I start a new document 
before the first float I insert.


Setting this for each and every document over and over again becomes 
just as annoying as it is now. I usually don't write 100 page documents 
anymore, so the average number of floats per document is not that big 
nowadays.




Opinions, further proposals?


I'm afraid this will be too late for 2.1. This will probably light up 
some discussion, and it will take time to figure out what we're going to 
do exactly.



Vincent

Re: RFC - offer users to set preferred float paragraph style

[Vincent van Ravesteijn]

Op 16-5-2013 22:15, Uwe Stöhr schreef:

Dear colleagues,

we often discussed in the past about the default paragraph alignment 
for new floats. We had the discussion in Milano as well because this 
is one of the most annoying things for many users. We voted to do 
something.


That's the real politics. Voting to do something, but not deciding on 
what we're going to do.



The question is now how. Here is my proposal:

- we add a document-wide setting where th user can set how he wants to 
have new floats
- this is a document setting not a LyX preference because different 
documents may require different settings.


Hmm.. A document setting that doesn't say anything about the document, 
but just how LyX interacts with it. That doesn't feel right. I think the 
change tracking setting is already annoying enough. Why do you think 
different documents require different settings ? Either you like them 
centered, or not. Maybe this could be related to different document 
classes, but then the document classes should dictate what the default 
alignment is.


  * is the caption below the image/table or above (For example the 
common typesetting rule is that figure captions are below while table 
captions are above. Getting this right for every float is currently a 
pain.)

Any idea how you're going to enforce this setting in LyX ?


  * the alignment of the paragraph in new floats
I'd rather see that the new floats get set a "default alignment". And a 
document setting to change the default of all existing floats. I will 
probably not remember to do this every time I start a new document 
before the first float I insert.


Setting this for each and every document over and over again becomes 
just as annoying as it is now. I usually don't write 100 page documents 
anymore, so the average number of floats per document is not that big 
nowadays.




Opinions, further proposals?


I'm afraid this will be too late for 2.1. This will probably light up 
some discussion, and it will take time to figure out what we're going to 
do exactly.



Vincent

Re: Trac mails b0rken

[Vincent van Ravesteijn]

 
  We really thought you received everything, because you agreed on
  everything that we decided.

 Seriously: It would be good to fix this ASAP. I just browsed though the
 latest changes and saw that you asked me to look at bug 4812, but I did not
 get any mail. Therefore I believe that there are comments I should be
 notified of.


 Georg


Yes, of course it should be fixed. I'm still receiving the mails (using the
lyx.org address), so it looks like a mystery why others do not receive
them.

Vincent

Re: Diffs for Features?

[Vincent van Ravesteijn]

On Mon, May 13, 2013 at 8:41 PM, Richard Heck rgh...@lyx.org wrote:

 On 05/13/2013 01:43 PM, Pavel Sanda wrote:

 Richard Heck wrote:

 This appears to be only for the features repo. I can copy the
 post-receive
 hook from the main repo if people want diffs for this repo.

 Please, that was what I was asking for.


 Should be working.

 rh

 Some things are better, but some things are worse now.

I would still prefer to send an e-mail for each commit in the normal lyx
repositiory. Not for each push. The default hook apparently does this, but
our customized script does not. Could you please have a look at this.

For the features repository though, it is different. Either, we want to
have a single e-mail for each push, because when you merge lyx/master into
a feature branch, you do not want an e-mail for each commit in the master
branch that got merged in. Or, we have to be smart and only send an e-mail
for those commits that are not in master, but this has the problem that we
have to check agains the master in the lyx repository, not in the features
repository.

I might be able to do this, but I do not have access to the scripts.

Vincent

Knitr ERT inset ?

[Vincent van Ravesteijn]

Could anyone that has an opinion on this subject please have a look at 
bug 8514 ?


http://www.lyx.org/trac/ticket/8514

Vincent

Re: Diffs for Features?

[Vincent van Ravesteijn]

Op 14-5-2013 9:01, Vincent van Ravesteijn schreef:



On Mon, May 13, 2013 at 8:41 PM, Richard Heck rgh...@lyx.org 
mailto:rgh...@lyx.org wrote:


On 05/13/2013 01:43 PM, Pavel Sanda wrote:

Richard Heck wrote:

This appears to be only for the features repo. I can copy
the post-receive
hook from the main repo if people want diffs for this repo.

Please, that was what I was asking for.


Should be working.

rh

Some things are better, but some things are worse now.
I would still prefer to send an e-mail for each commit in the normal 
lyx repositiory. Not for each push. The default hook apparently does 
this, but our customized script does not. Could you please have a look 
at this.
For the features repository though, it is different. Either, we want 
to have a single e-mail for each push, because when you merge 
lyx/master into a feature branch, you do not want an e-mail for each 
commit in the master branch that got merged in. Or, we have to be 
smart and only send an e-mail for those commits that are not in 
master, but this has the problem that we have to check agains the 
master in the lyx repository, not in the features repository.

I might be able to do this, but I do not have access to the scripts.
Vincent


And maybe we should change [LyX xml]  to [LyX features/xml]. Especially 
when this is about the master branch of the features repository 
otherwise things get really confusing. See the mail [LyX master] 
GuiMathMatrix.cpp: remove an unused header of 14-5, 12:35.


Vincent

Re: The latest version of Qt supported in LyX?

[Vincent van Ravesteijn]

Op 14-5-2013 14:05, Ashley Shan schreef:

Hi LyX community,

What is the latest version of Qt supported in LyX? I want to use QML 
in my implementation of the corkboard view but I am not sure whether I 
can use it in LyX. I am a GSoC student applicant and this is the 
project I applied to work on; I don't know whether my proposal will be 
selected or not, but I think this project is interesting and 
rewarding, and I want to contribute to it anyway.


Thank you in advance,
Ashley

*Xueqing Shan*
Vanderbilt University, '16


I don't know whether we want to use QML for a single part of LyX while 
the rest does not.


We support Qt  = 4.5.0. Support for Qt5 is being worked on.

Vincent

Re: XHTML compile warnings

[Vincent van Ravesteijn]

Op 14 mei 2013 14:45 schreef Richard Heck rgh...@lyx.org het volgende:

 On 05/13/2013 07:52 PM, Uwe Stöhr wrote:

 Hi Richard,

 I just checked out your latest changes and get these errors when
compiling (CMake, Qt 4.8.4):

 D:\LyXGit\Master\src\output_xhtml.h(167): warning C4099:
'lyx::html::FontTag' : type name first seen using 'class' now seen using
'struct' [D:\LyXGit\Master\compile-result\src\insets\insets.vcxproj]
 D:\LyXGit\Master\src\output_xhtml.h(181): warning C4099:
'lyx::html::EndFontTag' : type name first seen using 'class' now seen using
'struct' [D:\LyXGit\Master\compile-result\src\insets\insets.vcxproj]

 could you please have a look?


 That is very strange. FontTag and EndFontTag are forward declared as
structs on lines 34 and 35, and then the definition follows on lines 167
and 181, again as structs. Perhaps your compiler does not like the forward
definition of structs and treats it as if it said class?

 Anyone?

 Richard


I already fixed this. It's hard not to, if you're confronted with a
trillion of warnings.

They were forwardly declared as class.

Vincent

Re: [LyX master] qt5: Fix use of zlib

[Vincent van Ravesteijn]

Op 14-5-2013 16:57, Jean-Marc Lasgouttes schreef:

Le mar. 14 mai 2013 16:35:23 CEST, Stephan Witt a écrit :

Ok, is auto-tools use deprecated already? :)

If not, this should help:

diff --git a/src/tex2lyx/Makefile.am b/src/tex2lyx/Makefile.am
index 5be47e7..c547802 100644
--- a/src/tex2lyx/Makefile.am
+++ b/src/tex2lyx/Makefile.am
@@ -18,6 +18,7 @@ DEFAULT_INCLUDES =

  AM_CPPFLAGS += -DTEX2LYX -DNO_LAYOUT_CSS $(PCH_FLAGS) 
-I$(top_srcdir)/src/tex2lyx \

 -I$(top_srcdir)/src -I$(top_builddir) $(BOOST_INCLUDES)
+AM_CPPFLAGS += $(QT4_CPPFLAGS) $(QT4_CORE_INCLUDES)

  TEST_FILES = \
 test/runtests.py \

tex2lyx requires QtCore now… This violates the KISS paradigm, IMHO.


Especially to define some weird define. This should be done in 
autotools/cmake not in the source like that.


JMarc


Yes, I'll do it differently.

Vincent

Re: [LyX master] qt5: Fix use of zlib

[Vincent van Ravesteijn]

Op 14-5-2013 17:09, Vincent van Ravesteijn schreef:

Op 14-5-2013 16:57, Jean-Marc Lasgouttes schreef:

Le mar. 14 mai 2013 16:35:23 CEST, Stephan Witt a écrit :

Ok, is auto-tools use deprecated already? :)

If not, this should help:

diff --git a/src/tex2lyx/Makefile.am b/src/tex2lyx/Makefile.am
index 5be47e7..c547802 100644
--- a/src/tex2lyx/Makefile.am
+++ b/src/tex2lyx/Makefile.am
@@ -18,6 +18,7 @@ DEFAULT_INCLUDES =

  AM_CPPFLAGS += -DTEX2LYX -DNO_LAYOUT_CSS $(PCH_FLAGS) 
-I$(top_srcdir)/src/tex2lyx \

 -I$(top_srcdir)/src -I$(top_builddir) $(BOOST_INCLUDES)
+AM_CPPFLAGS += $(QT4_CPPFLAGS) $(QT4_CORE_INCLUDES)

  TEST_FILES = \
 test/runtests.py \

tex2lyx requires QtCore now… This violates the KISS paradigm, IMHO.


Especially to define some weird define. This should be done in 
autotools/cmake not in the source like that.


JMarc


Yes, I'll do it differently.

Vincent


Done at 4738ba0f.

Vincent

Re: [LyX master] Fix check_layout and adhere casing to other tests

[Vincent van Ravesteijn]

Op 14-5-2013 20:56, Georg Baum schreef:

Vincent van Ravesteijn wrote:


The branch, master, has been updated.

- Log -

commit 6f16814d3b9f51907cadfb97282d95ee769cb6fe
Author: Vincent van Ravesteijn v...@lyx.org
Date:   Tue May 14 18:41:33 2013 +0200

 Fix check_layout and adhere casing to other tests

The case was the same as that of the class which was tested (but I don't
care).


Georg


Sorry, you're right, the other tests refer to lower case files indeed.

Vincent

Re: [LyX master] qt5: Fix use of zlib

[Vincent van Ravesteijn]

Op 14-5-2013 22:00, Julien Rioux schreef:

On 14/05/2013 10:10 AM, Stephan Witt wrote:

This breaks the compilation of tex2lyx:

In file included from 
/Users/stephan/git/lyx/src/tex2lyx/../Lexer.cpp:23:
/Users/stephan/git/lyx/src/tex2lyx/../support/gzstream.h:35:18: 
error: QtCore: No such file or directory


Stephan





Master is still not compilable here, I need the patch below to be able 
to compile.Is this the correct fix?


commit 442907e29a2b9ff89f1bce1fac85a4e789f5e00d
Author: Julien Rioux jri...@lyx.org
Date:   Tue May 14 21:53:08 2013 +0200

Compilation fix.

diff --git a/src/frontends/qt4/GuiAbout.cpp 
b/src/frontends/qt4/GuiAbout.cpp

index ae9a2a3..09834d4 100644
--- a/src/frontends/qt4/GuiAbout.cpp
+++ b/src/frontends/qt4/GuiAbout.cpp
@@ -23,6 +23,7 @@
 #include support/Package.h

 #include QDate
+#include QFile
 #include QTextStream

 using namespace lyx::support;




Yes, that is correct. I fixed this.

Vincent

Re: Trac mails b0rken

[Vincent van Ravesteijn]

>
> >
> > We really thought you received everything, because you agreed on
> > everything that we decided.
>
> Seriously: It would be good to fix this ASAP. I just browsed though the
> latest changes and saw that you asked me to look at bug 4812, but I did not
> get any mail. Therefore I believe that there are comments I should be
> notified of.
>
>
> Georg
>

Yes, of course it should be fixed. I'm still receiving the mails (using the
lyx.org address), so it looks like a mystery why others do not receive
them.

Vincent

Re: Diffs for Features?

[Vincent van Ravesteijn]

On Mon, May 13, 2013 at 8:41 PM, Richard Heck  wrote:

> On 05/13/2013 01:43 PM, Pavel Sanda wrote:
>
>> Richard Heck wrote:
>>
>>> This appears to be only for the features repo. I can copy the
>>> post-receive
>>> hook from the main repo if people want diffs for this repo.
>>>
>> Please, that was what I was asking for.
>>
>
> Should be working.
>
> rh
>
> Some things are better, but some things are worse now.

I would still prefer to send an e-mail for each commit in the normal lyx
repositiory. Not for each push. The default hook apparently does this, but
our customized script does not. Could you please have a look at this.

For the features repository though, it is different. Either, we want to
have a single e-mail for each push, because when you merge lyx/master into
a feature branch, you do not want an e-mail for each commit in the master
branch that got merged in. Or, we have to be smart and only send an e-mail
for those commits that are not in master, but this has the problem that we
have to check agains the master in the lyx repository, not in the features
repository.

I might be able to do this, but I do not have access to the scripts.

Vincent

Knitr ERT inset ?

[Vincent van Ravesteijn]

Could anyone that has an opinion on this subject please have a look at 
bug 8514 ?


http://www.lyx.org/trac/ticket/8514

Vincent

Re: Diffs for Features?

[Vincent van Ravesteijn]

Op 14-5-2013 9:01, Vincent van Ravesteijn schreef:



On Mon, May 13, 2013 at 8:41 PM, Richard Heck <rgh...@lyx.org 
<mailto:rgh...@lyx.org>> wrote:


On 05/13/2013 01:43 PM, Pavel Sanda wrote:

Richard Heck wrote:

This appears to be only for the features repo. I can copy
the post-receive
hook from the main repo if people want diffs for this repo.

Please, that was what I was asking for.


Should be working.

rh

Some things are better, but some things are worse now.
I would still prefer to send an e-mail for each commit in the normal 
lyx repositiory. Not for each push. The default hook apparently does 
this, but our customized script does not. Could you please have a look 
at this.
For the features repository though, it is different. Either, we want 
to have a single e-mail for each push, because when you merge 
lyx/master into a feature branch, you do not want an e-mail for each 
commit in the master branch that got merged in. Or, we have to be 
smart and only send an e-mail for those commits that are not in 
master, but this has the problem that we have to check agains the 
master in the lyx repository, not in the features repository.

I might be able to do this, but I do not have access to the scripts.
Vincent


And maybe we should change [LyX xml]  to [LyX features/xml]. Especially 
when this is about the master branch of the features repository 
otherwise things get really confusing. See the mail "[LyX master] 
GuiMathMatrix.cpp: remove an unused header" of 14-5, 12:35.


Vincent

Re: The latest version of Qt supported in LyX?

[Vincent van Ravesteijn]

Op 14-5-2013 14:05, Ashley Shan schreef:

Hi LyX community,

What is the latest version of Qt supported in LyX? I want to use QML 
in my implementation of the corkboard view but I am not sure whether I 
can use it in LyX. I am a GSoC student applicant and this is the 
project I applied to work on; I don't know whether my proposal will be 
selected or not, but I think this project is interesting and 
rewarding, and I want to contribute to it anyway.


Thank you in advance,
Ashley

*Xueqing Shan*
Vanderbilt University, '16


I don't know whether we want to use QML for a single part of LyX while 
the rest does not.


We support Qt  >= 4.5.0. Support for Qt5 is being worked on.

Vincent

Re: XHTML compile warnings

[Vincent van Ravesteijn]

Op 14 mei 2013 14:45 schreef "Richard Heck"  het volgende:
>
> On 05/13/2013 07:52 PM, Uwe Stöhr wrote:
>>
>> Hi Richard,
>>
>> I just checked out your latest changes and get these errors when
compiling (CMake, Qt 4.8.4):
>>
>> D:\LyXGit\Master\src\output_xhtml.h(167): warning C4099:
'lyx::html::FontTag' : type name first seen using 'class' now seen using
'struct' [D:\LyXGit\Master\compile-result\src\insets\insets.vcxproj]
>> D:\LyXGit\Master\src\output_xhtml.h(181): warning C4099:
'lyx::html::EndFontTag' : type name first seen using 'class' now seen using
'struct' [D:\LyXGit\Master\compile-result\src\insets\insets.vcxproj]
>>
>> could you please have a look?
>
>
> That is very strange. FontTag and EndFontTag are forward declared as
structs on lines 34 and 35, and then the definition follows on lines 167
and 181, again as structs. Perhaps your compiler does not like the forward
definition of structs and treats it as if it said "class"?
>
> Anyone?
>
> Richard
>

I already fixed this. It's hard not to, if you're confronted with a
trillion of warnings.

They were forwardly declared as class.

Vincent

Re: [LyX master] qt5: Fix use of zlib

[Vincent van Ravesteijn]

Op 14-5-2013 16:57, Jean-Marc Lasgouttes schreef:

Le mar. 14 mai 2013 16:35:23 CEST, Stephan Witt a écrit :

Ok, is auto-tools use deprecated already? :)

If not, this should help:

diff --git a/src/tex2lyx/Makefile.am b/src/tex2lyx/Makefile.am
index 5be47e7..c547802 100644
--- a/src/tex2lyx/Makefile.am
+++ b/src/tex2lyx/Makefile.am
@@ -18,6 +18,7 @@ DEFAULT_INCLUDES =

  AM_CPPFLAGS += -DTEX2LYX -DNO_LAYOUT_CSS $(PCH_FLAGS) 
-I$(top_srcdir)/src/tex2lyx \

 -I$(top_srcdir)/src -I$(top_builddir) $(BOOST_INCLUDES)
+AM_CPPFLAGS += $(QT4_CPPFLAGS) $(QT4_CORE_INCLUDES)

  TEST_FILES = \
 test/runtests.py \

tex2lyx requires QtCore now… This violates the KISS paradigm, IMHO.


Especially to define some weird define. This should be done in 
autotools/cmake not in the source like that.


JMarc


Yes, I'll do it differently.

Vincent

Re: [LyX master] qt5: Fix use of zlib

[Vincent van Ravesteijn]

Op 14-5-2013 17:09, Vincent van Ravesteijn schreef:

Op 14-5-2013 16:57, Jean-Marc Lasgouttes schreef:

Le mar. 14 mai 2013 16:35:23 CEST, Stephan Witt a écrit :

Ok, is auto-tools use deprecated already? :)

If not, this should help:

diff --git a/src/tex2lyx/Makefile.am b/src/tex2lyx/Makefile.am
index 5be47e7..c547802 100644
--- a/src/tex2lyx/Makefile.am
+++ b/src/tex2lyx/Makefile.am
@@ -18,6 +18,7 @@ DEFAULT_INCLUDES =

  AM_CPPFLAGS += -DTEX2LYX -DNO_LAYOUT_CSS $(PCH_FLAGS) 
-I$(top_srcdir)/src/tex2lyx \

 -I$(top_srcdir)/src -I$(top_builddir) $(BOOST_INCLUDES)
+AM_CPPFLAGS += $(QT4_CPPFLAGS) $(QT4_CORE_INCLUDES)

  TEST_FILES = \
 test/runtests.py \

tex2lyx requires QtCore now… This violates the KISS paradigm, IMHO.


Especially to define some weird define. This should be done in 
autotools/cmake not in the source like that.


JMarc


Yes, I'll do it differently.

Vincent


Done at 4738ba0f.

Vincent

Re: [LyX master] Fix check_layout and adhere casing to other tests

[Vincent van Ravesteijn]

Op 14-5-2013 20:56, Georg Baum schreef:

Vincent van Ravesteijn wrote:


The branch, master, has been updated.

- Log -

commit 6f16814d3b9f51907cadfb97282d95ee769cb6fe
Author: Vincent van Ravesteijn <v...@lyx.org>
Date:   Tue May 14 18:41:33 2013 +0200

 Fix check_layout and adhere casing to other tests

The case was the same as that of the class which was tested (but I don't
care).


Georg


Sorry, you're right, the other tests refer to lower case files indeed.

Vincent

Re: [LyX master] qt5: Fix use of zlib

[Vincent van Ravesteijn]

Op 14-5-2013 22:00, Julien Rioux schreef:

On 14/05/2013 10:10 AM, Stephan Witt wrote:

This breaks the compilation of tex2lyx:

In file included from 
/Users/stephan/git/lyx/src/tex2lyx/../Lexer.cpp:23:
/Users/stephan/git/lyx/src/tex2lyx/../support/gzstream.h:35:18: 
error: QtCore: No such file or directory


Stephan





Master is still not compilable here, I need the patch below to be able 
to compile.Is this the correct fix?


commit 442907e29a2b9ff89f1bce1fac85a4e789f5e00d
Author: Julien Rioux 
Date:   Tue May 14 21:53:08 2013 +0200

Compilation fix.

diff --git a/src/frontends/qt4/GuiAbout.cpp 
b/src/frontends/qt4/GuiAbout.cpp

index ae9a2a3..09834d4 100644
--- a/src/frontends/qt4/GuiAbout.cpp
+++ b/src/frontends/qt4/GuiAbout.cpp
@@ -23,6 +23,7 @@
 #include "support/Package.h"

 #include 
+#include 
 #include 

 using namespace lyx::support;




Yes, that is correct. I fixed this.

Vincent

[PATCH] Implement the use of [[Context]] for placeholders

[Vincent van Ravesteijn]

When placeholders are used, the context can indicate what will be
substituted for the placeholder (e.g. %1$s[[date]], %1$s[[time]]).
---

Any objections to this patch ? I think it will be helpful for the translators.

Vincent

 README.localization  |  5 +++--
 src/support/Messages.cpp | 27 +--
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/README.localization b/README.localization
index 52280f9..2f77eec 100644
--- a/README.localization
+++ b/README.localization
@@ -71,8 +71,9 @@ appear in your translations! Please take them exactly as they 
are or you may
 experience crashes when running LyX.
 
 [[Context]] is used to distinguish otherwise identical strings, which could
-have different translations depending on the Context. [[Context]] appears only
-in msgid string and should not be repeated in the translated version.
+have different translations depending on the Context. It can also be used to
+indicate what is substituted for a placeholder. [[Context]] appears only in
+msgid string and should not be repeated in the translated version.
 
 {} refer to counters and must not be translated. An example would be:
 msgid Algorithm \\arabic{theorem}
diff --git a/src/support/Messages.cpp b/src/support/Messages.cpp
index 1f56f4d..0ce9d55 100644
--- a/src/support/Messages.cpp
+++ b/src/support/Messages.cpp
@@ -105,19 +105,26 @@ void cleanTranslation(docstring  trans)
  Some english words have different translations, depending on
  context. In these cases the original string is augmented by
  context information (e.g. To:[[as in 'From page x to page
- y']] and To:[[as in 'From format x to format y']]. This
- means that we need to filter out everything in double square
- brackets at the end of the string, otherwise the user sees
- bogus messages. If we are unable to honour the request we
- just return what we got in.
+ y']] and To:[[as in 'From format x to format y']]. Also, 
+ when placeholders are used, the context can indicate what will
+ be substituted for the placeholder (e.g. %1$s[[date]], %1$s
+ [[time]]). This means that we need to filter out everything 
+ in double square brackets at the end of the string, otherwise
+ the user sees bogus messages. If we are unable to honour the
+ request we just return what we got in.
*/
static docstring const ctx_start = from_ascii([[);
static docstring const ctx_end = from_ascii(]]);
-   size_t const pos1 = trans.find(ctx_start);
-   if (pos1 != docstring::npos) {
-   size_t const pos2 = trans.find(ctx_end, pos1);
-   if (pos2 != docstring::npos)
-   trans.erase(pos1, pos2 - pos1 + 2);
+   while (true) {
+   size_t const pos1 = trans.find(ctx_start);
+   if (pos1 != docstring::npos) {
+   size_t const pos2 = trans.find(ctx_end, pos1);
+   if (pos2 != docstring::npos) {
+   trans.erase(pos1, pos2 - pos1 + 2);
+   continue;
+   }
+   }
+   break;
}
 }
 
-- 
1.8.0.msysgit.0

Re: Should the 2.1 milestone be dropped or changed to 2.2?

[Vincent van Ravesteijn]

Op 13 mei 2013 20:39 schreef Vincent van Ravesteijn v...@lyx.org het
volgende:


 Op 13 mei 2013 16:18 schreef Scott Kostyshak skost...@lyx.org het
 volgende:
 
  Now that LyX 2.1 is coming up, many tickets are being dealt with. For
  these tickets, if they aren't likely to make it into 2.1, the
  milestone is being dropped. Is this what's normally done? I was
  expecting the milestone to be changed to 2.2.
 
  Is it correct that the tickets with milestone 2.1 that don't make it
  into to 2.1 will not be treated like tickets with no milestone?
 
  Perhaps this is a good thing. This would force us to think about all
  of the milestones of all unmarked tickets. There are probably some old
  tickets that are being ignored that should have been marked with a
  milestone.
 
  Scott

 The following represents my opinion.

 Bugs that are rather new, and bugs that might or should be fixed will keep
 the milestone 2.1. If they dont get fixed zoon, they will be retargeted to
 2.1.X or 2.2.0.

 Bugs that have not been touched since they got retargeted from 2.0 to 2.1
 (because back then nobody worked on it) will lose the milestone.

 Vincent

Re: CMake for Apple?

[Vincent van Ravesteijn]

Op 13 mei 2013 20:58 schreef Georg Baum georg.b...@post.rwth-aachen.de
het volgende:

 Abdelrazak Younes wrote:

  I think it is worth investing time in it. At the meeting everybody
  agreed that we should have one build system in the long run. But to make
  cmake official we need to achieve the following:
  1) implement the missing feature of autotools in cmake, especially for
  MAC as I believe that Linux/Unix is complete thanks to the hard work of
  Peter first and then Kornel.
  2) Deprecate autotools
  3) update the documentation (Readme/Wiki/etc)
  4) allow some time for developers to fully switch to cmake
  5) remove autotools when we are done, hopefully before 2.1, if not for
  2.2.
 
  The one point that still needs discussion is GLOB versus explicit file
  listing. While GLOB is IMO a very nice feature I know and understand
  others dislike it. So I guess we also need to do this in cmake.

 The usage of GLOB in cmake is the only reason why I still use autotools.
It
 interferes with my style of working (where it can happen that some play
.cpp
 files lie around), and it is also dangerous for making official builds:
 These should only compile stuff which is explicitly listed, otherwise you
 could easily end up with unreproducable compilations. Therefore I'd add
one
 item to the top of the list:

Just a wild idea: Only add cpp-files that are version tracked by git.

Vincent

[PATCH] Implement the use of [[Context]] for placeholders

[Vincent van Ravesteijn]

When placeholders are used, the context can indicate what will be
substituted for the placeholder (e.g. "%1$s[[date]], %1$s[[time]]).
---

Any objections to this patch ? I think it will be helpful for the translators.

Vincent

 README.localization  |  5 +++--
 src/support/Messages.cpp | 27 +--
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/README.localization b/README.localization
index 52280f9..2f77eec 100644
--- a/README.localization
+++ b/README.localization
@@ -71,8 +71,9 @@ appear in your translations! Please take them exactly as they 
are or you may
 experience crashes when running LyX.
 
 [[Context]] is used to distinguish otherwise identical strings, which could
-have different translations depending on the Context. [[Context]] appears only
-in msgid string and should not be repeated in the translated version.
+have different translations depending on the Context. It can also be used to
+indicate what is substituted for a placeholder. [[Context]] appears only in
+msgid string and should not be repeated in the translated version.
 
 {} refer to counters and must not be translated. An example would be:
 msgid "Algorithm \\arabic{theorem}"
diff --git a/src/support/Messages.cpp b/src/support/Messages.cpp
index 1f56f4d..0ce9d55 100644
--- a/src/support/Messages.cpp
+++ b/src/support/Messages.cpp
@@ -105,19 +105,26 @@ void cleanTranslation(docstring & trans)
  Some english words have different translations, depending on
  context. In these cases the original string is augmented by
  context information (e.g. "To:[[as in 'From page x to page
- y']]" and "To:[[as in 'From format x to format y']]". This
- means that we need to filter out everything in double square
- brackets at the end of the string, otherwise the user sees
- bogus messages. If we are unable to honour the request we
- just return what we got in.
+ y']]" and "To:[[as in 'From format x to format y']]". Also, 
+ when placeholders are used, the context can indicate what will
+ be substituted for the placeholder (e.g. "%1$s[[date]], %1$s
+ [[time]]). This means that we need to filter out everything 
+ in double square brackets at the end of the string, otherwise
+ the user sees bogus messages. If we are unable to honour the
+ request we just return what we got in.
*/
static docstring const ctx_start = from_ascii("[[");
static docstring const ctx_end = from_ascii("]]");
-   size_t const pos1 = trans.find(ctx_start);
-   if (pos1 != docstring::npos) {
-   size_t const pos2 = trans.find(ctx_end, pos1);
-   if (pos2 != docstring::npos)
-   trans.erase(pos1, pos2 - pos1 + 2);
+   while (true) {
+   size_t const pos1 = trans.find(ctx_start);
+   if (pos1 != docstring::npos) {
+   size_t const pos2 = trans.find(ctx_end, pos1);
+   if (pos2 != docstring::npos) {
+   trans.erase(pos1, pos2 - pos1 + 2);
+   continue;
+   }
+   }
+   break;
}
 }
 
-- 
1.8.0.msysgit.0

Re: Should the 2.1 milestone be dropped or changed to 2.2?

[Vincent van Ravesteijn]

Op 13 mei 2013 20:39 schreef "Vincent van Ravesteijn" <v...@lyx.org> het
volgende:

>
> Op 13 mei 2013 16:18 schreef "Scott Kostyshak" <skost...@lyx.org> het
> volgende:
> >
> > Now that LyX 2.1 is coming up, many tickets are being dealt with. For
> > these tickets, if they aren't likely to make it into 2.1, the
> > milestone is being dropped. Is this what's normally done? I was
> > expecting the milestone to be changed to 2.2.
> >
> > Is it correct that the tickets with milestone 2.1 that don't make it
> > into to 2.1 will not be treated like tickets with no milestone?
> >
> > Perhaps this is a good thing. This would force us to think about all
> > of the milestones of all unmarked tickets. There are probably some old
> > tickets that are being ignored that should have been marked with a
> > milestone.
> >
> > Scott
>
> The following represents my opinion.
>
> Bugs that are rather new, and bugs that might or should be fixed will keep
> the milestone 2.1. If they dont get fixed zoon, they will be retargeted to
> 2.1.X or 2.2.0.
>
> Bugs that have not been touched since they got retargeted from 2.0 to 2.1
> (because back then nobody worked on it) will lose the milestone.
>
> Vincent
>

Re: CMake for Apple?

[Vincent van Ravesteijn]

Op 13 mei 2013 20:58 schreef "Georg Baum" 
het volgende:
>
> Abdelrazak Younes wrote:
>
> > I think it is worth investing time in it. At the meeting everybody
> > agreed that we should have one build system in the long run. But to make
> > cmake official we need to achieve the following:
> > 1) implement the missing feature of autotools in cmake, especially for
> > MAC as I believe that Linux/Unix is complete thanks to the hard work of
> > Peter first and then Kornel.
> > 2) Deprecate autotools
> > 3) update the documentation (Readme/Wiki/etc)
> > 4) allow some time for developers to fully switch to cmake
> > 5) remove autotools when we are done, hopefully before 2.1, if not for
> > 2.2.
> >
> > The one point that still needs discussion is GLOB versus explicit file
> > listing. While GLOB is IMO a very nice feature I know and understand
> > others dislike it. So I guess we also need to do this in cmake.
>
> The usage of GLOB in cmake is the only reason why I still use autotools.
It
> interferes with my style of working (where it can happen that some play
.cpp
> files lie around), and it is also dangerous for making official builds:
> These should only compile stuff which is explicitly listed, otherwise you
> could easily end up with unreproducable compilations. Therefore I'd add
one
> item to the top of the list:

Just a wild idea: Only add cpp-files that are version tracked by git.

Vincent

Re: CMake for Apple?

[Vincent van Ravesteijn]

So I cannot answer the question. Isn't the autotools build the
official one?


Up to now yes, except for Windows.

I was trying to advocate yesterday that we should really move to cmake 
on all platforms. I guess this is already a lost battle...


Hmm.. your chances are not that bad really.

Vincent

Re: [features/refs/heads/kill-gettext] UserGuide.lyx: next revision step

[Vincent van Ravesteijn]

Since commit 704328d3488c75733ddeb9ad5439b1907e323e39 there is no diff sent to 
the list anymore.

Stephan



This commit is not sent to the list indeed.  Commit  03f98402f (Fix 
crash with FindAndReplaceUi) is sent to the list twice ;)..


Vincent

Re: Trac mails b0rken

[Vincent van Ravesteijn]

Op 12-5-2013 20:56, Pavel Sanda schreef:

Georg Baum wrote:

Indeed it seems if CC myself with lyx unrelated email it works, if I'm
CC-ed either as sanda or sa...@lyx.org I get nothing (the @lyx.org mail
work fine itself though).

I don't get any trac mail either, but I do get the cvs list emails to the
.lyx.org address.

Hm. That means that all the mass triage of 2.1 milestoned bugs with all
the posted questions will be ignored.

Pavel


I got them all.

Vincent

Re: Trac mails b0rken

[Vincent van Ravesteijn]

On Sunday, May 12, 2013, Pavel Sanda sa...@lyx.org wrote:
 Vincent van Ravesteijn wrote:
 I got them all.

 ldm conspiracy  :))


We really thought you received everything, because you agreed on everything
that we decided.

Vincent

Re: CMake for Apple?

[Vincent van Ravesteijn]

So I cannot answer the question. Isn't the autotools build the
official one?


Up to now yes, except for Windows.

I was trying to advocate yesterday that we should really move to cmake 
on all platforms. I guess this is already a lost battle...


Hmm.. your chances are not that bad really.

Vincent

Re: [features/refs/heads/kill-gettext] UserGuide.lyx: next revision step

[Vincent van Ravesteijn]

Since commit 704328d3488c75733ddeb9ad5439b1907e323e39 there is no diff sent to 
the list anymore.

Stephan



This commit is not sent to the list indeed.  Commit  03f98402f (Fix 
crash with FindAndReplaceUi) is sent to the list twice ;)..


Vincent

Re: Trac mails b0rken

[Vincent van Ravesteijn]

Op 12-5-2013 20:56, Pavel Sanda schreef:

Georg Baum wrote:

Indeed it seems if CC myself with lyx unrelated email it works, if I'm
CC-ed either as sanda or sa...@lyx.org I get nothing (the @lyx.org mail
work fine itself though).

I don't get any trac mail either, but I do get the cvs list emails to the
.lyx.org address.

Hm. That means that all the mass triage of 2.1 milestoned bugs with all
the posted questions will be ignored.

Pavel


I got them all.

Vincent

Re: Trac mails b0rken

[Vincent van Ravesteijn]

On Sunday, May 12, 2013, Pavel Sanda <sa...@lyx.org> wrote:
> Vincent van Ravesteijn wrote:
>> I got them all.
>
> ldm conspiracy  :))
>

We really thought you received everything, because you agreed on everything
that we decided.

Vincent

Re: [LyX master] Automatic horiz/vert switch also for Advanced Tab (completing e3677975).

[Vincent van Ravesteijn]

Op 5-5-2013 16:10, Tommaso Cucinotta schreef:

The branch, master, has been updated.

- Log -

commit bd9e8fecd3f4b6d537e8805d2021ca62c3ca588e
Author: Tommaso Cucinotta tomm...@lyx.org
Date:   Sun May 5 15:09:53 2013 +0100

 Automatic horiz/vert switch also for Advanced Tab (completing e3677975).

  
diff --git a/src/frontends/qt4/ui/FindAndReplaceUi.ui b/src/frontends/qt4/ui/FindAndReplaceUi.ui

index 7a5cbaf..51a08cc 100644
--- a/src/frontends/qt4/ui/FindAndReplaceUi.ui
+++ b/src/frontends/qt4/ui/FindAndReplaceUi.ui
@@ -20,13 +20,13 @@
 stringTabWidget/string
/property
property name=currentIndex
-   number0/number
+   number1/number
/property



Tommaso,

Was this change intended ?

For me, it makes LyX crash when requesting the Find and Replace pane.

Vincent

Re: [LyX master] Automatic horiz/vert switch also for Advanced Tab (completing e3677975).

[Vincent van Ravesteijn]

Op 5-5-2013 16:10, Tommaso Cucinotta schreef:

The branch, master, has been updated.

- Log -

commit bd9e8fecd3f4b6d537e8805d2021ca62c3ca588e
Author: Tommaso Cucinotta 
Date:   Sun May 5 15:09:53 2013 +0100

 Automatic horiz/vert switch also for Advanced Tab (completing e3677975).

  
diff --git a/src/frontends/qt4/ui/FindAndReplaceUi.ui b/src/frontends/qt4/ui/FindAndReplaceUi.ui

index 7a5cbaf..51a08cc 100644
--- a/src/frontends/qt4/ui/FindAndReplaceUi.ui
+++ b/src/frontends/qt4/ui/FindAndReplaceUi.ui
@@ -20,13 +20,13 @@
 TabWidget


-   0
+   1




Tommaso,

Was this change intended ?

For me, it makes LyX crash when requesting the Find and Replace pane.

Vincent

Re: Unit testing: The Small Plan

[Vincent van Ravesteijn]

Op 7-5-2013 10:57, Elmar Hinz schreef:

Hello list,

I'd like to come up with a small plan for getting started with unit 
testing:


I would like to see some examples of mocking  and injection.

I tried to write some tests using the google framework, and started with 
the Buffer class. This immediately gives you the problem that it is 
dependent on a large number of other classes. So, this would mean that 
you have to fake a large part of the LyX codebase.


Then I tried to link against all libraries of LyX, but then I ran into 
problems that the application was not initialized (e.g., Package, 
translations etc.)


I'm afraid we can't do much testing until the above is solved.

My attempt thus far can be found at: 
git://git.lyx.org/developers/vfr/lyx.git


That is not really kosher, but at least a simple way to get started 
directly.


It is done by use of a simple preprocessor directive:

#public_on_testing

Once a wall of tests is created to ensure the behaviour of the given API,
more skilled approaches can be introduced.


Ideally, one would not need to care about private variables because we 
are only interested in that the public interface does what it is 
supposed to do. Right ?


Vincent

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR

[Vincent van Ravesteijn]

Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:
Does anybody know somethng about this bug? Is it true that tables in 
ltr mode should have ltr columns? What does this mean anyway?


JMarc


Yes, I 'fixed' it.

It isn't about tables, it is about a two column document.

It means that you read the right side of the page before the left side.

Vincent

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR

[Vincent van Ravesteijn]

Op 7 mei 2013 23:15 schreef Jean-Marc Lasgouttes lasgout...@lyx.org het
volgende:

 Le 07/05/13 22:41, Vincent van Ravesteijn a écrit :

 Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:

 Does anybody know somethng about this bug? Is it true that tables in
 ltr mode should have ltr columns? What does this mean anyway?

 JMarc


 Yes, I 'fixed' it.

 It isn't about tables, it is about a two column document.

 It means that you read the right side of the page before the left side.


 Do you have a pointer?

 JMarc


Bug 6389.

Vincent

Re: Unit testing: The Small Plan

[Vincent van Ravesteijn]

Op 7-5-2013 10:57, Elmar Hinz schreef:

Hello list,

I'd like to come up with a small plan for getting started with unit 
testing:


I would like to see some examples of mocking  and injection.

I tried to write some tests using the google framework, and started with 
the Buffer class. This immediately gives you the problem that it is 
dependent on a large number of other classes. So, this would mean that 
you have to fake a large part of the LyX codebase.


Then I tried to link against all libraries of LyX, but then I ran into 
problems that the application was not initialized (e.g., Package, 
translations etc.)


I'm afraid we can't do much testing until the above is solved.

My attempt thus far can be found at: 
git://git.lyx.org/developers/vfr/lyx.git


That is not really kosher, but at least a simple way to get started 
directly.


It is done by use of a simple preprocessor directive:

#public_on_testing

Once a wall of tests is created to ensure the behaviour of the given API,
more skilled approaches can be introduced.


Ideally, one would not need to care about private variables because we 
are only interested in that the public interface does what it is 
supposed to do. Right ?


Vincent

Re: Fwd: [Bug 347378] Re: Two columns in Hebrew is in LTR

[Vincent van Ravesteijn]

Op 7-5-2013 22:31, Jean-Marc Lasgouttes schreef:
Does anybody know somethng about this bug? Is it true that tables in 
ltr mode should have ltr columns? What does this mean anyway?


JMarc


Yes, I 'fixed' it.

It isn't about tables, it is about a two column document.

It means that you read the right side of the page before the left side.

Vincent