Re: LyX, XeTeX, bidi and Hebrew

[Guenter Milde]

On 2012-07-16, Ronen Abravanel wrote:

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

 These files produced directly by the GIT version of LyX.
 As you can see, the braces are the inverted in both the PDF and the TeX
 files.

However, they are inverted in the source file too!

* What do you get if the example is written as

שלום (שלום)

  in LyX?

* How would you write the same in OpenOffice or some other word processor?

After all, this is rather a XeTeX vs. pdfLaTeX problem: what does an
internet recherche for Hebrew polyglossia XeTeX reveal? Did you also try
LuaTeX?

Günter

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 18/07/2012 06:39, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM


Moreover, this code should not be in GuiView, but in
GuiApplication, since the function is at application level.

Attached is my attempt to move the code to GuiApplication. I am having trouble 
instantiating a GuiWorkArea. Here are the errors I get:

GuiApplication.cpp: In member function ‘virtual void 
lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest, 
lyx::DispatchResult)’:
GuiApplication.cpp:1633:8: error: invalid use of incomplete type ‘class 
lyx::frontend::GuiWorkArea’
In file included from GuiApplication.cpp:15:0:
GuiApplication.h:41:7: error: forward declaration of ‘class 
lyx::frontend::GuiWorkArea’


Try to #include GuiWorkArea.h at the start of GuiApplication.cpp.


I think that this patch also addresses the other points you raised.


It begins to look very good. See below for comments.

JMarc


+   case LFUN_BUFFER_FORALL: {
+   GuiView * cv = currentView();


What if currentView() is null? I propose to do an early return in this 
case. Or maybe this can happen when all buffers are hidden and requires 
finer codeing. I do not know whether this is only a theoretical 
possibility, this may happen when using client to do scripting. On the 
mac at least, LyX can be running witout having any open window.


Unless you want to be very complete, it is probably enough right now to 
return early.


I do not think I have seen cv used as the name of a GuiView. From a 
quick poll if the source, I suggest gv or view. The good thing about 
using a known name is that it requires less effort for the reader of the 
code.



+   Buffer * const buf = cv-currentBufferView()-buffer();


Do we have a bufferview when the LyX window is there but no buffer is open?


+   FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);


FuncRequest const funcToRun =...
(constify and no capitalization of variable names)


+   dr.setMessage(bformat(_(%1$s%2$s), msg, 
from_utf8(commandToRun)));



+   Buffer * const last = theBufferList().last();
+   Buffer * b = theBufferList().first();
+   Buffer * nextBuf = 0;
+   // We cannot use a for loop as the buffer list cycles.
+   while (true) {
+   if (b != last)
+   nextBuf = theBufferList().next(b); //get next 
now bc LFUN might close current
+
+   bool const hidden = !(guiApp-currentView()  
guiApp-currentView()-workArea(*b));


No need to use guiApp- there. Are you using currentView() because cv 
could become invalid? If so, why do you use it below?


BTW, what happens if several windows are open? It looks like you are not 
going to see whether the buffers on other windows are



+   if (hidden) {
+   if (processHidden) {
+   cv-setBuffer(b);
+   lyx::dispatch(FuncToRun);
+   GuiWorkArea * const wa = 
cv-currentWorkArea();
+   wa-view().hideWorkArea(wa);


I am not sure that the intermediate wa variable is useful here.


+   }
+   }
+
+   else {
+   if (processVisible) {


else if (processvisible) { ...

Re: Undo.cpp reports an error on trunk

[Jean-Marc Lasgouttes]

Le 13/07/2012 19:21, Richard Heck a écrit :

This is why I propose to add a parameter to reload telling whether
undo should be discarded.


I just committed that change. This is an obvious candidate for branch 
(no risk, IMO).


JMarc

Re: Undo.cpp reports an error on trunk

[Jean-Marc Lasgouttes]

Le 13/07/2012 19:21, Richard Heck a écrit :

OTOH, it looks like doing a reload in after save-as is a bit harsh. Is
the goal only to sanitize IncludeInset?


It certainly wouldn't surprise me if there were something simpler we
could do. It was definitely a big hammer, that commit.

The primary goal was to deal with the fact that children, parents, etc,
may no longer be where there are supposed to be. But the Buffer contains
all kinds of pointers (e.g., in the TOC, in the reference cache, etc)
that may point to children and the like. So I'm guessing there are other
issues.


Does it mean that LyX just crashes if I remove a file that is supposed 
to be here? How rude...


JMarc

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

On Wed, Jul 18, 2012 at 11:09 AM, Guenter Milde mi...@users.sf.net wrote:

 On 2012-07-16, Ronen Abravanel wrote:

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

  These files produced directly by the GIT version of LyX.
  As you can see, the braces are the inverted in both the PDF and the TeX
  files.

 However, they are inverted in the source file too!

 * What do you get if the example is written as

 שלום (שלום)

   in LyX?

Just Hello (Hello) in hebrew
In LyX it's
שלום (שלום)


 * How would you write the same in OpenOffice or some other word
 processor?

If I *write* the same thing in a different word processor (OO, ms word or
other bidi-supported WP) I get the brace proper. If I paste the tex-code
into a word processor, it's inverted as in the PDF.


 After all, this is rather a XeTeX vs. pdfLaTeX problem: what does an
 internet recherche for Hebrew polyglossia XeTeX reveal? Did you also try
 LuaTeX?


Never seen working LuaTeX in Hebrew.


 Günter



Anyway, I fixed it (patch in my previews mail).
The bug is in the old latex\latex export: the hebrew support in LaTeX
was broken so it was fixed in LyX. now, XeTeX need to get proper text so
LyX should produce proper unicode file.

Ronen.

Re: Undo.cpp reports an error on trunk

[Richard Heck]

On 07/18/2012 06:08 AM, Jean-Marc Lasgouttes wrote:

Le 13/07/2012 19:21, Richard Heck a écrit :

OTOH, it looks like doing a reload in after save-as is a bit harsh. Is
the goal only to sanitize IncludeInset?


It certainly wouldn't surprise me if there were something simpler we
could do. It was definitely a big hammer, that commit.

The primary goal was to deal with the fact that children, parents, etc,
may no longer be where there are supposed to be. But the Buffer contains
all kinds of pointers (e.g., in the TOC, in the reference cache, etc)
that may point to children and the like. So I'm guessing there are other
issues.

Does it mean that LyX just crashes if I remove a file that is supposed 
to be here? How rude...


I can't remember exactly what the crash was. But suppose you save the 
file to a new location, then you close what used to be a child buffer. 
The original file thinks that Buffer is still a child, and it didn't get 
notified of anything because it's not the parent any longer. Etc.


Richard

Re: Undo.cpp reports an error on trunk

[Richard Heck]

On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote:

Le 13/07/2012 19:21, Richard Heck a écrit :

This is why I propose to add a parameter to reload telling whether
undo should be discarded.


I just committed that change. This is an obvious candidate for branch 
(no risk, IMO).



OK.

rh

Re: Undo.cpp reports an error on trunk

[Jean-Marc Lasgouttes]

Le 18/07/2012 16:35, Richard Heck a écrit :

On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote:

Le 13/07/2012 19:21, Richard Heck a écrit :

This is why I propose to add a parameter to reload telling whether
undo should be discarded.


I just committed that change. This is an obvious candidate for branch
(no risk, IMO).


OK.


Looks like you never backported this particular fix. If you decide to do 
it, I'll backport my patch too.


JMarc

Re: Undo.cpp reports an error on trunk

[Richard Heck]

On 07/18/2012 10:48 AM, Jean-Marc Lasgouttes wrote:

Le 18/07/2012 16:35, Richard Heck a écrit :

On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote:

Le 13/07/2012 19:21, Richard Heck a écrit :

This is why I propose to add a parameter to reload telling whether
undo should be discarded.


I just committed that change. This is an obvious candidate for branch
(no risk, IMO).


OK.


Looks like you never backported this particular fix. If you decide to 
do it, I'll backport my patch too.



Which thing didn't I backport?

rh

Re: problematic copier for JPEG figures?

[Yihui Xie]

Oops... I cannot reproduce it on the other machine, so I need to
examine this problem more carefully before I report back.

Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Wed, Jul 18, 2012 at 1:06 AM, Yihui Xie x...@yihui.name wrote:
 Hi,

 I'm not sure anyone else can reproduce this weird behavior under LyX
 2.0.4 (Ubuntu): the tex code for jpeg figures seems to be wrong.
 Suppose the jpeg file is foo.jpg; in the tex code exported from LyX it
 will become this:

 \includegraphics{\string0_path_to_foo\string.jpg, jpeg}

 pdflatex will write the text jpeg jpeg before the figure in the PDF
 output. It turns out that LyX copied foo.jpg to the temp dir as
 0_path_to_foo.jpg, jpeg. I do not understand why this happens. PNG
 figures are fine.

 Regards,
 Yihui
 --
 Yihui Xie xieyi...@gmail.com
 Phone: 515-294-2465 Web: http://yihui.name
 Department of Statistics, Iowa State University
 2215 Snedecor Hall, Ames, IA

Re: Undo.cpp reports an error on trunk

[Jean-Marc Lasgouttes]

Le 18/07/12 17:43, Richard Heck a écrit :

Looks like you never backported this particular fix. If you decide to
do it, I'll backport my patch too.


Which thing didn't I backport?


This one, I think.

JMarc

commit 9283cbdbcb3b33da28d2ecca6cd5665f39c7b388
Author: Richard Heck rgh...@comcast.net
Date:   Fri Jan 13 03:31:01 2012 +

Fix crash reported on list when renaming a child buffer and
then trying to compile.

There are really two problems here. One is that the renamed
buffer needs to be reloaded. All kinds of files, etc, may not
exist any more, if we've been saved to a new directory; our
children e.g. may not be in the right place. And, in this case,
we may no longer be a child of our old parent. Reloading will
fix all of that.

On reload, though, we need to clear our parent, since we may
not have one any more. It will get reset if need be.

Re: [LyX master] Read list of translated languages from a file

[Jean-Marc Lasgouttes]

Le 19/07/12 00:21, Jean-Marc Lasgouttes a écrit :

commit ed1515ef69d0381e9b0657cf1966f9d86e0cb25f
Author: Jean-Marc Lasgouttes lasgout...@lyx.org
Date:   Thu Jul 19 00:02:56 2012 +0200

 Read list of translated languages from a file

 The previous scheme of loading all possible translations and checking 
whether the work
 is a bit too much brute force and causes problems on Mac OS X (documents 
loaded
 with the wrong language).

 In the new scheme, autotools install a file lib/installed_translations 
that contains a list of installed languages (the .gmo files that got 
installed). This file is read
 in Languages::readInstalledTranslations and allows to set the translated() 
property
 of each language.


Kornel, this requires an adaptation of cmake (see above). On my machine 
the contents of installed _translations is just
 ar ca cs da de el en es eu fi fr gl he hu ia id it ja nb nl nn pl pt 
ro ru sk sr sv tr uk zh_CN zh_TW


Stephan, please check that this solves problems with the Mac builds.

Uwe, please check that this still works with your windows installer. If 
this requires to backport to branch I can do that.


Richard, if this solves the problems with the Mc builds, I think this 
should go to branch.


JMarc



diff --git a/configure.ac b/configure.ac
index acfa663..71a4b1c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -180,6 +180,10 @@ m4_defun([AC_GNU_SOURCE],[])
  AM_GNU_GETTEXT([no-libtool])
  AM_GNU_GETTEXT_VERSION([0.16.1])
  AC_LANG_POP(C)
+AC_CONFIG_COMMANDS([lib/installed_translation], [
+  rm -f lib/installed_translations
+  echo $CATALOGS | sed 's/\.gmo//g'  lib/installed_translations
+])

  # some standard header files
  AC_HEADER_MAJOR
@@ -371,7 +375,7 @@ AC_CONFIG_FILES([Makefile \
development/cygwin/lyxrc.dist \
development/lyx.spec \
intl/Makefile \
-  lib/lyx.desktop-temp:lib/lyx.desktop.in
+  lib/lyx.desktop-temp:lib/lyx.desktop.in \
lib/Makefile \
lib/doc/Makefile \
lib/lyx2lyx/lyx2lyx_version.py \
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 8ac88f1..2111dfb 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -8,6 +8,8 @@ dist_pkgdata_DATA = CREDITS autocorrect chkconfig.ltx 
external_templates \
encodings layouttranslations languages symbols syntax.default \
unicodesymbols

+nodist_pkgdata_DATA = installed_translations
+
  # We use DATA now instead of PYTHON because automake 1.11.2 complains.
  # Note that we chmod 755 manually this file in install-data-hook.
  dist_pkgdata_DATA += configure.py
diff --git a/src/Language.cpp b/src/Language.cpp
index 8c891fb..9f8c57e 100644
--- a/src/Language.cpp
+++ b/src/Language.cpp
@@ -196,10 +196,6 @@ bool Language::read(Lexer  lex)
encoding_ = encodings.fromLyXName(iso8859-1);
LYXERR0(Unknown encoding   encodingStr_);
}
-   // cache translation status. Calling getMessages() directly in
-   // PrefLanguage::PrefLanguage() did only work if the gui language
-   // was set to auto (otherwise all languages would be marked as 
available).
-   translated_ = getMessages(code()).available();
return true;
  }

@@ -262,8 +258,12 @@ void Languages::read(FileName const  filename)
}

// Read layout translations
-   FileName const path = libFileSearch(string(), layouttranslations);
+   FileName path = libFileSearch(string(), layouttranslations);
readLayoutTranslations(path);
+
+   // Read installed translations
+   path = libFileSearch(string(), installed_translations);
+   readInstalledTranslations(path);
  }


@@ -372,6 +372,32 @@ void Languages::readLayoutTranslations(support::FileName const 
 filename)
  }


+void Languages::readInstalledTranslations(support::FileName const  filename)
+{
+   Lexer lex;
+   lex.setFile(filename);
+   lex.setContext(Languages::read);
+
+   // 1) read all installed gmo files names
+   setstring installed_translations;
+   string lang_code;
+   while (lex.isOK()) {
+   lex  lang_code;
+   installed_translations.insert(lang_code);
+   }
+
+   // 2) mark all corresponding languages as translated.
+   LanguageList::iterator lit = languagelist.begin();
+   LanguageList::iterator const lend = languagelist.end();
+   for ( ; lit != lend ; ++lit) {
+   if (installed_translations.count(lit-second.code())
+   || installed_translations.count(token(lit-second.code(), 
'_', 0)))
+   lit-second.translated(true);
+   }
+
+}
+
+
  Language const * Languages::getLanguage(string const  language) const
  {
if (language == reset)
diff --git a/src/Language.h b/src/Language.h
index 71b6777..fb1158b 100644
--- a/src/Language.h
+++ b/src/Language.h
@@ -50,6 +50,8 @@ public:
bool rightToLeft() const { return rightToLeft_; }
/// Is an (at least partial) translation of this language 

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, July 18, 2012 4:14 AM

JMarc,

Thank you for your guidance. Attached is an updated patch and below I respond 
to your comments.

Scott

Try to #include GuiWorkArea.h at the start of GuiApplication.cpp.

That works.

 + case LFUN_BUFFER_FORALL: {
 + GuiView * cv = currentView();

What if currentView() is null? I propose to do an early return in this
case. Or maybe this can happen when all buffers are hidden and requires
finer codeing. I do not know whether this is only a theoretical
possibility, this may happen when using client to do scripting. On the
mac at least, LyX can be running witout having any open window.

Unless you want to be very complete, it is probably enough right now to
return early.

I wouldn't mind trying to address this if you think that would be better. For 
now I don't allow for this situation by disabling the function in getStatus. I 
didn't realize that it's possible to have a hidden window without a visible 
window. The current patch disables the function in this situation. I don't know 
how to check for the existence of a hidden buffer without a visible buffer.

I do not think I have seen cv used as the name of a GuiView. From a
quick poll if the source, I suggest gv or view. The good thing about
using a known name is that it requires less effort for the reader of the
code.

Done.

 + Buffer * const buf = cv-currentBufferView()-buffer();

Do we have a bufferview when the LyX window is there but no buffer is open?

I put in some checks.

 + FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);

FuncRequest const funcToRun =...
(constify and no capitalization of variable names)

Done.

 + dr.setMessage(bformat(_(%1$s%2$s), msg, 
 from_utf8(commandToRun)));

 + Buffer * const last = theBufferList().last();
 + Buffer * b = theBufferList().first();
 + Buffer * nextBuf = 0;
 + // We cannot use a for loop as the buffer list cycles.
 + while (true) {
 + if (b != last)
 + nextBuf = theBufferList().next(b); //get next 
 now bc LFUN might close current
 +
 + bool const hidden = !(guiApp-currentView()  
 guiApp-currentView()-workArea(*b));

No need to use guiApp- there. Are you using currentView() because cv
could become invalid? If so, why do you use it below?

Done.

BTW, what happens if several windows are open? It looks like you are not
going to see whether the buffers on other windows are

If there are more windows open, buffer-forall iterates over the buffers in the 
current window, treating a buffer as hidden as designated in the current 
window. When a new window is opened it treats all of the open buffers as 
hidden. The default of buffer-forall of not iterating over hidden buffers is 
thus nice in the case that a user doesn't know what a hidden buffer is or 
doesn't know that the buffers in the other windows would be affected by 
buffer-forall because they are automatically available as hidden.

 + if (hidden) {
 + if (processHidden) {
 + cv-setBuffer(b);
 + lyx::dispatch(FuncToRun);
 + GuiWorkArea * const wa = 
 cv-currentWorkArea();
 + wa-view().hideWorkArea(wa);

I am not sure that the intermediate wa variable is useful here.

Done.diff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..872721a 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120718
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..3767e31 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,28 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers in the current window.
+ * \li Syntax: buffer-forall [BUFFER-TYPE] LFUN-COMMAND
+ * \li Params: BUFFER-TYPE: visible|hidden|both default: default: visible   
+   LFUN-COMMAND: The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n

export to odt and HTML (Word)

[Jack Tanner]

On my LyX 2.0.4, Windows, export to odt and HTML (Word) is very broken. For
example, at times I get this in messages:

23:14:21.748:
C:\Users\lunacy\AppData\Local\Temp\lyx_tmpdir.Hp8096\lyx_tmpbuf3t4ht my-doc.tex
-cooxtpipes -coo -ewin32/tex4ht.env 
23:14:21.751: --- error --- Illegal storage address

but then I also get:

23:14:21.772: Successful export to format: odt
23:18:42.401: Automatic save done.

Naturally, the export fails, i.e., neither the temp dir nor the actual doc dir
contain an exported file.

Re: LyX, XeTeX, bidi and Hebrew

[Guenter Milde]

On 2012-07-16, Ronen Abravanel wrote:

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

> These files produced directly by the GIT version of LyX.
> As you can see, the braces are the inverted in both the PDF and the TeX
> files.

However, they are inverted in the source file too!

* What do you get if the example is written as

שלום (שלום)

  in LyX?

* How would you write the same in OpenOffice or some other "word processor"?

After all, this is rather a XeTeX vs. pdfLaTeX problem: what does an
internet recherche for "Hebrew polyglossia XeTeX" reveal? Did you also try
LuaTeX?

Günter

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 18/07/2012 06:39, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM


>Moreover, this code should not be in GuiView, but in
>GuiApplication, since the function is at application level.

Attached is my attempt to move the code to GuiApplication. I am having trouble 
instantiating a GuiWorkArea. Here are the errors I get:

GuiApplication.cpp: In member function ‘virtual void 
lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest&, 
lyx::DispatchResult&)’:
GuiApplication.cpp:1633:8: error: invalid use of incomplete type ‘class 
lyx::frontend::GuiWorkArea’
In file included from GuiApplication.cpp:15:0:
GuiApplication.h:41:7: error: forward declaration of ‘class 
lyx::frontend::GuiWorkArea’


Try to #include "GuiWorkArea.h" at the start of GuiApplication.cpp.


I think that this patch also addresses the other points you raised.


It begins to look very good. See below for comments.

JMarc


+   case LFUN_BUFFER_FORALL: {
+   GuiView * cv = currentView();


What if currentView() is null? I propose to do an early return in this 
case. Or maybe this can happen when all buffers are hidden and requires 
finer codeing. I do not know whether this is only a theoretical 
possibility, this may happen when using client to do scripting. On the 
mac at least, LyX can be running witout having any open window.


Unless you want to be very complete, it is probably enough right now to 
return early.


I do not think I have seen "cv" used as the name of a GuiView. From a 
quick poll if the source, I suggest "gv" or "view". The good thing about 
using a known name is that it requires less effort for the reader of the 
code.



+   Buffer * const buf = >currentBufferView()->buffer();


Do we have a bufferview when the LyX window is there but no buffer is open?


+   FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);


FuncRequest const funcToRun =...
(constify and no capitalization of variable names)


+   dr.setMessage(bformat(_("%1$s%2$s"), msg, 
from_utf8(commandToRun)));



+   Buffer * const last = theBufferList().last();
+   Buffer * b = theBufferList().first();
+   Buffer * nextBuf = 0;
+   // We cannot use a for loop as the buffer list cycles.
+   while (true) {
+   if (b != last)
+   nextBuf = theBufferList().next(b); //get next 
now bc LFUN might close current
+
+   bool const hidden = !(guiApp->currentView() && 
guiApp->currentView()->workArea(*b));


No need to use guiApp-> there. Are you using currentView() because cv 
could become invalid? If so, why do you use it below?


BTW, what happens if several windows are open? It looks like you are not 
going to see whether the buffers on other windows are



+   if (hidden) {
+   if (processHidden) {
+   cv->setBuffer(b);
+   lyx::dispatch(FuncToRun);
+   GuiWorkArea * const wa = 
cv->currentWorkArea();
+   wa->view().hideWorkArea(wa);


I am not sure that the intermediate wa variable is useful here.


+   }
+   }
+
+   else {
+   if (processVisible) {


else if (processvisible) { ...

Re: Undo.cpp reports an error on trunk

[Jean-Marc Lasgouttes]

Le 13/07/2012 19:21, Richard Heck a écrit :

This is why I propose to add a parameter to reload telling whether
undo should be discarded.


I just committed that change. This is an obvious candidate for branch 
(no risk, IMO).


JMarc

Re: Undo.cpp reports an error on trunk

[Jean-Marc Lasgouttes]

Le 13/07/2012 19:21, Richard Heck a écrit :

OTOH, it looks like doing a reload in after save-as is a bit harsh. Is
the goal only to sanitize IncludeInset?


It certainly wouldn't surprise me if there were something simpler we
could do. It was definitely a big hammer, that commit.

The primary goal was to deal with the fact that children, parents, etc,
may no longer be where there are supposed to be. But the Buffer contains
all kinds of pointers (e.g., in the TOC, in the reference cache, etc)
that may point to children and the like. So I'm guessing there are other
issues.


Does it mean that LyX just crashes if I remove a file that is supposed 
to be here? How rude...


JMarc

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

On Wed, Jul 18, 2012 at 11:09 AM, Guenter Milde  wrote:

> On 2012-07-16, Ronen Abravanel wrote:
>
> > [-- Type: text/plain, Encoding: quoted-printable --]
>
> > These files produced directly by the GIT version of LyX.
> > As you can see, the braces are the inverted in both the PDF and the TeX
> > files.
>
> However, they are inverted in the source file too!
>
> * What do you get if the example is written as
>
> שלום (שלום)
>
>   in LyX?
>
Just "Hello (Hello)" in hebrew
In LyX it's
שלום (שלום)


> * How would you write the same in OpenOffice or some other "word
> processor"?
>
If I *write* the same thing in a different word processor (OO, ms word or
other bidi-supported WP) I get the brace proper. If I paste the tex-code
into a word processor, it's inverted as in the PDF.


> After all, this is rather a XeTeX vs. pdfLaTeX problem: what does an
> internet recherche for "Hebrew polyglossia XeTeX" reveal? Did you also try
> LuaTeX?
>

Never seen working LuaTeX in Hebrew.

>
> Günter
>
>

Anyway, I fixed it (patch in my previews mail).
The "bug" is in the "old" latex\latex export: the hebrew support in LaTeX
was broken so it was fixed in LyX. now, XeTeX need to get proper text so
LyX should produce proper unicode file.

Ronen.

Re: Undo.cpp reports an error on trunk

[Richard Heck]

On 07/18/2012 06:08 AM, Jean-Marc Lasgouttes wrote:

Le 13/07/2012 19:21, Richard Heck a écrit :

OTOH, it looks like doing a reload in after save-as is a bit harsh. Is
the goal only to sanitize IncludeInset?


It certainly wouldn't surprise me if there were something simpler we
could do. It was definitely a big hammer, that commit.

The primary goal was to deal with the fact that children, parents, etc,
may no longer be where there are supposed to be. But the Buffer contains
all kinds of pointers (e.g., in the TOC, in the reference cache, etc)
that may point to children and the like. So I'm guessing there are other
issues.

Does it mean that LyX just crashes if I remove a file that is supposed 
to be here? How rude...


I can't remember exactly what the crash was. But suppose you save the 
file to a new location, then you close what used to be a child buffer. 
The original file thinks that Buffer is still a child, and it didn't get 
notified of anything because it's not the parent any longer. Etc.


Richard

Re: Undo.cpp reports an error on trunk

[Richard Heck]

On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote:

Le 13/07/2012 19:21, Richard Heck a écrit :

This is why I propose to add a parameter to reload telling whether
undo should be discarded.


I just committed that change. This is an obvious candidate for branch 
(no risk, IMO).



OK.

rh

Re: Undo.cpp reports an error on trunk

[Jean-Marc Lasgouttes]

Le 18/07/2012 16:35, Richard Heck a écrit :

On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote:

Le 13/07/2012 19:21, Richard Heck a écrit :

This is why I propose to add a parameter to reload telling whether
undo should be discarded.


I just committed that change. This is an obvious candidate for branch
(no risk, IMO).


OK.


Looks like you never backported this particular fix. If you decide to do 
it, I'll backport my patch too.


JMarc

Re: Undo.cpp reports an error on trunk

[Richard Heck]

On 07/18/2012 10:48 AM, Jean-Marc Lasgouttes wrote:

Le 18/07/2012 16:35, Richard Heck a écrit :

On 07/18/2012 05:46 AM, Jean-Marc Lasgouttes wrote:

Le 13/07/2012 19:21, Richard Heck a écrit :

This is why I propose to add a parameter to reload telling whether
undo should be discarded.


I just committed that change. This is an obvious candidate for branch
(no risk, IMO).


OK.


Looks like you never backported this particular fix. If you decide to 
do it, I'll backport my patch too.



Which thing didn't I backport?

rh

Re: problematic copier for JPEG figures?

[Yihui Xie]

Oops... I cannot reproduce it on the other machine, so I need to
examine this problem more carefully before I report back.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Wed, Jul 18, 2012 at 1:06 AM, Yihui Xie  wrote:
> Hi,
>
> I'm not sure anyone else can reproduce this weird behavior under LyX
> 2.0.4 (Ubuntu): the tex code for jpeg figures seems to be wrong.
> Suppose the jpeg file is foo.jpg; in the tex code exported from LyX it
> will become this:
>
> \includegraphics{\string"0_path_to_foo\string".jpg, jpeg}
>
> pdflatex will write the text "jpeg jpeg" before the figure in the PDF
> output. It turns out that LyX copied foo.jpg to the temp dir as
> "0_path_to_foo.jpg, jpeg". I do not understand why this happens. PNG
> figures are fine.
>
> Regards,
> Yihui
> --
> Yihui Xie 
> Phone: 515-294-2465 Web: http://yihui.name
> Department of Statistics, Iowa State University
> 2215 Snedecor Hall, Ames, IA

Re: Undo.cpp reports an error on trunk

[Jean-Marc Lasgouttes]

Le 18/07/12 17:43, Richard Heck a écrit :

Looks like you never backported this particular fix. If you decide to
do it, I'll backport my patch too.


Which thing didn't I backport?


This one, I think.

JMarc

commit 9283cbdbcb3b33da28d2ecca6cd5665f39c7b388
Author: Richard Heck 
Date:   Fri Jan 13 03:31:01 2012 +

Fix crash reported on list when renaming a child buffer and
then trying to compile.

There are really two problems here. One is that the renamed
buffer needs to be reloaded. All kinds of files, etc, may not
exist any more, if we've been saved to a new directory; our
children e.g. may not be in the right place. And, in this case,
we may no longer be a child of our old parent. Reloading will
fix all of that.

On reload, though, we need to clear our parent, since we may
not have one any more. It will get reset if need be.

Re: [LyX master] Read list of translated languages from a file

[Jean-Marc Lasgouttes]

Le 19/07/12 00:21, Jean-Marc Lasgouttes a écrit :

commit ed1515ef69d0381e9b0657cf1966f9d86e0cb25f
Author: Jean-Marc Lasgouttes 
Date:   Thu Jul 19 00:02:56 2012 +0200

 Read list of translated languages from a file

 The previous scheme of loading all possible translations and checking 
whether the work
 is a bit too much "brute force" and causes problems on Mac OS X (documents 
loaded
 with the wrong language).

 In the new scheme, autotools install a file lib/installed_translations 
that contains a list of installed languages (the .gmo files that got 
installed). This file is read
 in Languages::readInstalledTranslations and allows to set the translated() 
property
 of each language.


Kornel, this requires an adaptation of cmake (see above). On my machine 
the contents of installed _translations is just
 ar ca cs da de el en es eu fi fr gl he hu ia id it ja nb nl nn pl pt 
ro ru sk sr sv tr uk zh_CN zh_TW


Stephan, please check that this solves problems with the Mac builds.

Uwe, please check that this still works with your windows installer. If 
this requires to backport to branch I can do that.


Richard, if this solves the problems with the Mc builds, I think this 
should go to branch.


JMarc



diff --git a/configure.ac b/configure.ac
index acfa663..71a4b1c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -180,6 +180,10 @@ m4_defun([AC_GNU_SOURCE],[])
  AM_GNU_GETTEXT([no-libtool])
  AM_GNU_GETTEXT_VERSION([0.16.1])
  AC_LANG_POP(C)
+AC_CONFIG_COMMANDS([lib/installed_translation], [
+  rm -f lib/installed_translations
+  echo $CATALOGS | sed 's/\.gmo//g' > lib/installed_translations
+])

  # some standard header files
  AC_HEADER_MAJOR
@@ -371,7 +375,7 @@ AC_CONFIG_FILES([Makefile \
development/cygwin/lyxrc.dist \
development/lyx.spec \
intl/Makefile \
-  lib/lyx.desktop-temp:lib/lyx.desktop.in
+  lib/lyx.desktop-temp:lib/lyx.desktop.in \
lib/Makefile \
lib/doc/Makefile \
lib/lyx2lyx/lyx2lyx_version.py \
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 8ac88f1..2111dfb 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -8,6 +8,8 @@ dist_pkgdata_DATA = CREDITS autocorrect chkconfig.ltx 
external_templates \
encodings layouttranslations languages symbols syntax.default \
unicodesymbols

+nodist_pkgdata_DATA = installed_translations
+
  # We use DATA now instead of PYTHON because automake 1.11.2 complains.
  # Note that we "chmod 755" manually this file in install-data-hook.
  dist_pkgdata_DATA += configure.py
diff --git a/src/Language.cpp b/src/Language.cpp
index 8c891fb..9f8c57e 100644
--- a/src/Language.cpp
+++ b/src/Language.cpp
@@ -196,10 +196,6 @@ bool Language::read(Lexer & lex)
encoding_ = encodings.fromLyXName("iso8859-1");
LYXERR0("Unknown encoding " << encodingStr_);
}
-   // cache translation status. Calling getMessages() directly in
-   // PrefLanguage::PrefLanguage() did only work if the gui language
-   // was set to auto (otherwise all languages would be marked as 
available).
-   translated_ = getMessages(code()).available();
return true;
  }

@@ -262,8 +258,12 @@ void Languages::read(FileName const & filename)
}

// Read layout translations
-   FileName const path = libFileSearch(string(), "layouttranslations");
+   FileName path = libFileSearch(string(), "layouttranslations");
readLayoutTranslations(path);
+
+   // Read installed translations
+   path = libFileSearch(string(), "installed_translations");
+   readInstalledTranslations(path);
  }


@@ -372,6 +372,32 @@ void Languages::readLayoutTranslations(support::FileName const 
& filename)
  }


+void Languages::readInstalledTranslations(support::FileName const & filename)
+{
+   Lexer lex;
+   lex.setFile(filename);
+   lex.setContext("Languages::read");
+
+   // 1) read all installed gmo files names
+   set installed_translations;
+   string lang_code;
+   while (lex.isOK()) {
+   lex >> lang_code;
+   installed_translations.insert(lang_code);
+   }
+
+   // 2) mark all corresponding languages as translated.
+   LanguageList::iterator lit = languagelist.begin();
+   LanguageList::iterator const lend = languagelist.end();
+   for ( ; lit != lend ; ++lit) {
+   if (installed_translations.count(lit->second.code())
+   || installed_translations.count(token(lit->second.code(), 
'_', 0)))
+   lit->second.translated(true);
+   }
+
+}
+
+
  Language const * Languages::getLanguage(string const & language) const
  {
if (language == "reset")
diff --git a/src/Language.h b/src/Language.h
index 71b6777..fb1158b 100644
--- a/src/Language.h
+++ b/src/Language.h
@@ -50,6 +50,8 @@ public:
bool rightToLeft() const { return rightToLeft_; }
/// Is an (at least partial) 

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, July 18, 2012 4:14 AM

JMarc,

Thank you for your guidance. Attached is an updated patch and below I respond 
to your comments.

Scott

>Try to #include "GuiWorkArea.h" at the start of GuiApplication.cpp.

That works.

>> + case LFUN_BUFFER_FORALL: {
>> + GuiView * cv = currentView();

>What if currentView() is null? I propose to do an early return in this
>case. Or maybe this can happen when all buffers are hidden and requires
>finer codeing. I do not know whether this is only a theoretical
>possibility, this may happen when using client to do scripting. On the
>mac at least, LyX can be running witout having any open window.

>Unless you want to be very complete, it is probably enough right now to
>return early.

I wouldn't mind trying to address this if you think that would be better. For 
now I don't allow for this situation by disabling the function in getStatus. I 
didn't realize that it's possible to have a hidden window without a visible 
window. The current patch disables the function in this situation. I don't know 
how to check for the existence of a hidden buffer without a visible buffer.

>I do not think I have seen "cv" used as the name of a GuiView. From a
>quick poll if the source, I suggest "gv" or "view". The good thing about
>using a known name is that it requires less effort for the reader of the
>code.

Done.

>> + Buffer * const buf = >currentBufferView()->buffer();

>Do we have a bufferview when the LyX window is there but no buffer is open?

I put in some checks.

>> + FuncRequest FuncToRun = lyxaction.lookupFunc(commandToRun);

>FuncRequest const funcToRun =...
>(constify and no capitalization of variable names)

Done.

>> + dr.setMessage(bformat(_("%1$s%2$s"), msg, 
>> from_utf8(commandToRun)));

>> + Buffer * const last = theBufferList().last();
>> + Buffer * b = theBufferList().first();
>> + Buffer * nextBuf = 0;
>> + // We cannot use a for loop as the buffer list cycles.
>> + while (true) {
>> + if (b != last)
>> + nextBuf = theBufferList().next(b); //get next 
>> now bc LFUN might close current
>> +
>> + bool const hidden = !(guiApp->currentView() && 
>> guiApp->currentView()->workArea(*b));

>No need to use guiApp-> there. Are you using currentView() because cv
>could become invalid? If so, why do you use it below?

Done.

>BTW, what happens if several windows are open? It looks like you are not
>going to see whether the buffers on other windows are

If there are more windows open, buffer-forall iterates over the buffers in the 
current window, treating a buffer as hidden as designated in the current 
window. When a new window is opened it treats all of the open buffers as 
hidden. The default of buffer-forall of not iterating over hidden buffers is 
thus nice in the case that a user doesn't know what a hidden buffer is or 
doesn't know that the buffers in the other windows would be affected by 
buffer-forall because they are automatically available as hidden.

>> + if (hidden) {
>> + if (processHidden) {
>> + cv->setBuffer(b);
>> + lyx::dispatch(FuncToRun);
>> + GuiWorkArea * const wa = 
>> cv->currentWorkArea();
>> + wa->view().hideWorkArea(wa);

>I am not sure that the intermediate wa variable is useful here.

Done.diff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..872721a 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120718
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..3767e31 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,28 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers in the current window.
+ * \li Syntax: buffer-forall [] 
+ * \li Params: : <visible|hidden|both default:> default: visible   
+   : The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible d

export to odt and HTML (Word)

[Jack Tanner]

On my LyX 2.0.4, Windows, export to odt and HTML (Word) is very broken. For
example, at times I get this in messages:

23:14:21.748:
C:\Users\lunacy\AppData\Local\Temp\lyx_tmpdir.Hp8096\lyx_tmpbuf3>t4ht my-doc.tex
"-cooxtpipes -coo" -ewin32/tex4ht.env 
23:14:21.751: --- error --- Illegal storage address

but then I also get:

23:14:21.772: Successful export to format: odt
23:18:42.401: Automatic save done.

Naturally, the export fails, i.e., neither the temp dir nor the actual doc dir
contain an exported file.