Re: Beta (status update #3)

[Stephan Witt]

Am 01.11.2010 um 23:42 schrieb Pavel Sanda:

 Stephan Witt wrote:
 Sorry, I went out and could not answer :-)
 
 1) I have a patch at hand to add the ability to collect stderr in system call
 and to simplify the stdout collection too. This patch doesn't change the
 current interface but adds a second one. VCS is more clean with that.
 The need to add  redirection and parse it later to split it vanishes.
 
 we are entering new flame even before posting this patch...
 to add new interface for each of the backend is not a good thing.

I meant a new interface for SystemCall with stdout and stderr parameters.

 all the code should use the same infrastructure and workarounding my request
 not to refactor vcs code base by implementing new lyxvc_for_the_sake_of_cvs
 is not the way i would like to continue ;)

Of course. That I didn't want.

 if you have the patch already feel free to post it, but...

I'll attach it - so you get the idea.

I want to
1) catch the output of failing system calls to display them in error message 
dialog
2) eventually be able to pass it up to caller for parsing it
3) simplify the tmpfile handling

 
 2) I want to complete the CVS implementation. 
 Add the missing buffer-info things. Add the diff to previous version.
 
 3) Want the readFile() issue fixed.
 
 is this beta1 critical stuf?

After my last commit in readFile() it's only the issue with file_found_hook 
being called with the wrong file name in case of autosave and emergency.
I'd like to fix it before (2) or maybe Vincent does it... For users of VCS I'd 
rate it as a serious problem - but not critical.

Stephan

Index: src/support/Systemcall.cpp
===
--- src/support/Systemcall.cpp  (Revision 35961)
+++ src/support/Systemcall.cpp  (Arbeitskopie)
@@ -207,14 +207,21 @@
 int Systemcall::startscript(Starttype how, string const  what, bool 
process_events)
 {
string outfile;
+   string errfile;
QString cmd = toqstr(parsecmd(what, outfile));
+   return startscript(how, what, outfile, errfile, process_events);
+}
 
-   SystemcallPrivate d(outfile);
 
+int Systemcall::startscript(Starttype how, string const  what,
+   std::string const  
outfile, std::string const  errfile, 
+   bool process_events)
+{
+   SystemcallPrivate d(outfile, errfile);
 
-   d.startProcess(cmd);
+   d.startProcess(toqstr(what));
if (!d.waitWhile(SystemcallPrivate::Starting, process_events, -1)) {
-   LYXERR0(Systemcall: '  cmd  ' did not start!);
+   LYXERR0(Systemcall: '  what  ' did not start!);
LYXERR0(error   d.errorMessage());
return 10;
}
@@ -226,7 +233,7 @@
}
 
if (!d.waitWhile(SystemcallPrivate::Running, process_events, 18)) {
-   LYXERR0(Systemcall: '  cmd  ' did not finished!);
+   LYXERR0(Systemcall: '  what  ' did not finished!);
LYXERR0(error   d.errorMessage());
LYXERR0(status   d.exitStatusMessage());
return 20;
@@ -234,18 +241,18 @@
 
int const exit_code = d.exitCode();
if (exit_code) {
-   LYXERR0(Systemcall: '  cmd  ' finished with exit code  
 exit_code);
+   LYXERR0(Systemcall: '  what  ' finished with exit code  
 exit_code);
}
 
return exit_code;
 }
 
 
-SystemcallPrivate::SystemcallPrivate(const std::string of) :
+SystemcallPrivate::SystemcallPrivate(const std::string out_file) :
 process_(new QProcess), 
 out_index_(0),
 err_index_(0),
-out_file_(of), 
+out_file_(out_file), 
 process_events_(false)
 {
if (!out_file_.empty()) {
@@ -262,7 +269,33 @@
 }
 
 
+SystemcallPrivate::SystemcallPrivate(const std::string out_file, const 
std::string err_file) :
+   process_(new QProcess), 
+   out_index_(0),
+   err_index_(0),
+   out_file_(out_file), 
+   err_file_(err_file), 
+   process_events_(false)
+{
+   if (!out_file_.empty()) {
+   // Check whether we have to simply throw away the output.
+   if (out_file_ != os::nulldev())
+   process_-setStandardOutputFile(toqstr(out_file_));
+   }
+   if (!err_file_.empty()) {
+   // Check whether we have to simply throw away the error output.
+   if (err_file_ != os::nulldev())
+   process_-setStandardErrorFile(toqstr(err_file_));
+   }
+   
+   connect(process_, SIGNAL(readyReadStandardOutput()), SLOT(stdOut()));
+   connect(process_, SIGNAL(readyReadStandardError()), SLOT(stdErr()));
+   

Re: Beta (status update #3)

[Stephan Witt]

Am 02.11.2010 um 07:31 schrieb Stephan Witt:

 Am 01.11.2010 um 23:42 schrieb Pavel Sanda:
 
 Stephan Witt wrote:
 

 3) Want the readFile() issue fixed.
 
 is this beta1 critical stuf?
 
 After my last commit in readFile() it's only the issue with file_found_hook 
 being called with the wrong file name in case of autosave and emergency.
 I'd like to fix it before (2) or maybe Vincent does it...
 For users of VCS I'd rate it as a serious problem - but not critical.

To illustrate my plan I post a patch - it's compiling and I tested it quickly.
I hope that's acceptable. Vincent? Do you have a better proposal?

Stephan

Index: src/Buffer.h
===
--- src/Buffer.h(Revision 35961)
+++ src/Buffer.h(Arbeitskopie)
@@ -196,6 +196,7 @@
/// emergency or autosave files, one should use \c loadLyXFile.
/// /sa loadLyXFile
ReadStatus loadThisLyXFile(support::FileName const  fn);
+   ReadStatus loadThisLyXFile(support::FileName const  fn, 
support::FileName const  on);
/// read a new document from a string
bool readString(std::string const );
/// Reloads the LyX file
@@ -209,7 +210,7 @@
 
 private:
/// read a new file
-   ReadStatus readFile(support::FileName const  fn);
+   ReadStatus readFile(support::FileName const  fn, support::FileName 
const  on);
/// Reads a file without header.
/// \param par if != 0 insert the file.
/// \return \c true if file is not completely read.
Index: src/Buffer.cpp
===
--- src/Buffer.cpp  (Revision 35985)
+++ src/Buffer.cpp  (Arbeitskopie)
@@ -847,7 +847,7 @@
os  s;
os.close();
// lyxvc in readFile
-   return readFile(fn) == ReadSuccess;
+   return readFile(fn, FileName()) == ReadSuccess;
}
 
if (readDocument(lex))
@@ -856,7 +856,7 @@
 }
 
 
-Buffer::ReadStatus Buffer::readFile(FileName const  fn)
+Buffer::ReadStatus Buffer::readFile(FileName const  fn, FileName const  on)
 {
FileName fname(fn);
Lexer lex;
@@ -872,11 +872,11 @@
ReadStatus const ret_clf = convertLyXFormat(fn, tmpFile, 
file_format);
if (ret_clf != ReadSuccess)
return ret_clf;
-   return readFile(tmpFile);
+   return readFile(tmpFile, FileName());
}
 
// InsetInfo needs to know if file is under VCS
-   lyxvc().file_found_hook(fn);
+   lyxvc().file_found_hook(on.empty() ? fn : on);
 
if (readDocument(lex)) {
Alert::error(_(Document format failure),
@@ -3647,7 +3647,7 @@
{
case 0: {
docstring str;
-   ReadStatus const ret_llf = loadThisLyXFile(emergencyFile);
+   ReadStatus const ret_llf = loadThisLyXFile(emergencyFile, fn);
bool const success = (ret_llf == ReadSuccess);
if (success) {
markDirty();
@@ -3703,7 +3703,7 @@
switch (ret)
{
case 0: {
-   ReadStatus const ret_llf = loadThisLyXFile(autosaveFile);
+   ReadStatus const ret_llf = loadThisLyXFile(autosaveFile, fn);
// the file is not saved if we load the autosave file.
if (ret_llf == ReadSuccess) {
markDirty();
@@ -3739,13 +3739,19 @@
if (ret_ra == ReadSuccess || ret_ra == ReadCancel)
return ret_ra;
 
-   return loadThisLyXFile(fn);
+   return loadThisLyXFile(fn, FileName());
 }
 
 
+Buffer::ReadStatus Buffer::loadThisLyXFile(FileName const  fn, FileName const 
 on)
+{
+   return readFile(fn, on);
+}
+
+
 Buffer::ReadStatus Buffer::loadThisLyXFile(FileName const  fn)
 {
-   return readFile(fn);
+   return readFile(fn, FileName());
 }
 
 

Re: #7008: longtable dialog regression

[Abdelrazak Younes]

On 11/02/2010 12:11 AM, LyX Ticket Tracker wrote:

#7008: longtable dialog regression
---+
  Reporter:  uwestoehr  |   Owner:  poenitz
  Type:  defect |  Status:  new
  Priority:  high   |   Milestone:  2.0.0
Component:  tabular| Version:  2.0.0svn
  Severity:  normal |Keywords:  regression
---+
  During the table dialog overhaul the following regression has been
  introduced:

  A header/footer can only be set as no content if there is a
  header/footer line but no firstheader/lastfooter line

  The old code respected this and checked in GuiTabular::updateContents()
  for this for lastfooterStatusCB.

  The new code doesn't check for this in GuiTabular::checkEnabled().

  The fix for this should be easy: replace
  lastfooterNoContentsCB-setEnabled(longtabular);
  with
  lastfooterNoContentsCB-setEnabled(longtabular  tabular.haveLTFoot()
  !tabular.haveLTLastFoot());
  in GuiTabular::checkEnabled()

  I failed to do this because I don't know how to call Tabular::haveLTFoot()
  in GuiTabular::checkEnabled().
   


The correct fix is not so easy but an easy fix would be to cache the 
value that we need in a ne boolean member that we set in paramsToDialog():


d-give_it_a_correct_name_ = tabular.haveLTFoot()  
!tabular.haveLTLastFoot());


Abdel.

Re: Beta (status update #3)

[Vincent van Ravesteijn]

  After my last commit in readFile() it's only the issue with 
file_found_hook being called with the wrong file name in case of autosave and emergency.
  I'd like to fix it before (2) or maybe Vincent does it...
  For users of VCS I'd rate it as a serious problem - but not critical.

To illustrate my plan I post a patch - it's compiling and I tested it quickly.
I hope that's acceptable. Vincent? Do you have a better proposal?

Stephan




/// emergency or autosave files, one should use \c loadLyXFile.
/// /sa loadLyXFile
ReadStatus loadThisLyXFile(support::FileName const  fn);
+   ReadStatus loadThisLyXFile(support::FileName const  fn, support::FileName 
const  on);
/// read a new document from a string
bool readString(std::string const);
/// Reloads the LyX file



I don't like this. Adding another parameter to a public function, which you 
wouldn't expect at all. Buffer only knows about autosave/emergency/backup 
files. loadThisLyXFile was supposed not to do anything with emergency/autosave 
files at all, so it is strange that it needs some extra parameter.


Let me think how to solve it properly.

Vincent

Commit logs

[Vincent van Ravesteijn]

Log:
first step to cure the VCS load problem

Log:
Partially fix #5108.
Log:
Fix bug #6997



Can I please remind you and ask you to write meaningful commit-logs. 
Logs explaining why the change has been made, why the new design or 
solution or implementation is better, what problem it fixed, why other 
solutions might be wrong although it may seem not to be at first sight 
and so forth.


I don't want to have to look into a bug to even know what the bug is 
about, so I always like at least to add a summary of the bug to the 
commit log. Furthermore, the fix might need some explanation.


In the example of the VCS load problem, please explain what the VCS load 
problem is. Please explain why it is only a first step, and what still 
needs to be done.


Thank you.

Vincent

Re: Beta (status update #3)

[Stephan Witt]

Am 02.11.2010 um 10:22 schrieb Vincent van Ravesteijn:

  
  
 After my last commit in readFile() it's only the issue with 
 file_found_hook being called with the wrong file name in case of autosave 
 and emergency.
 
  
 I'd like to fix it before (2) or maybe Vincent does it...
 
  
 For users of VCS I'd rate it as a serious problem - but not critical.
 
 To illustrate my plan I post a patch - it's compiling and I tested it quickly.
 I hope that's acceptable. Vincent? Do you have a better proposal?
 
 Stephan
 
 
 
  /// emergency or autosave files, one should use \c loadLyXFile.
  /// /sa loadLyXFile
  ReadStatus loadThisLyXFile(support::FileName const  fn);
 +ReadStatus loadThisLyXFile(support::FileName const  fn, 
 support::FileName const  on);
  /// read a new document from a string
  bool readString(std::string const );
  /// Reloads the LyX file
 
 
 I don't like this. Adding another parameter to a public function, which you 
 wouldn't expect at all. Buffer only knows about autosave/emergency/backup 
 files. loadThisLyXFile was supposed not to do anything with 
 emergency/autosave files at all, so it is strange that it needs some extra 
 parameter.
 
 
 Let me think how to solve it properly.

No problem. Thanks.

Stephan

Re: Beta (status update #3)

[Vincent van Ravesteijn]

Yes. Ive got something. Wait

Op 1 nov 2010 14:21 schreef Pavel Sanda sa...@lyx.org:

hi,

1. Richard, whats the status of a)? i'm basically waiting only for this.
could you give it top priority on your list if its not fixed yet?

2. Vincent could you put in the pending patch for b?

3. Gregory, you didn't replied to us. you have only very limited time frame
  to do so, otherwise things in 2.0 might by undesirable for you.



 short resume for things we need before releasing beta
 a) - Richard has some pending work on lyx2lyx which will finish some JMarc
work.
 b) - pending patch from Gregory Jefferis for CT, Vincent might have look
on it.
   (this is in progress, we wait for Gregory's input)

 c) #6809 - converting to older LyX versions doesn't work under standard
conditions
   (lesser importance)

c) would be nice to have, but i'm not going to stop release for it.

pavel

Re: Commit logs

[Stephan Witt]

Am 02.11.2010 um 10:29 schrieb Vincent van Ravesteijn:

 
 Log:
 first step to cure the VCS load problem
 
 Can I please remind you and ask you to write meaningful commit-logs. Logs 
 explaining why the change has been made, why the new design or solution or 
 implementation is better, what problem it fixed, why other solutions might be 
 wrong although it may seem not to be at first sight and so forth.
 
 In the example of the VCS load problem, please explain what the VCS load 
 problem is. Please explain why it is only a first step, and what still needs 
 to be done.

The VCS load problem is (was) twofold:
1. the parser of the document needs the VCS state so this state (checked by 
file_found_hook) had to be done earlier.
= first step, move it some lines up, above the readDocument() call.
2. in case of loading the autosave or emergency file the real file name has to 
be passed to file_found_hook.
= the patch I posted does this. (I missed to diff src/buffer_funcs.cpp and - 
of course - I'd fix the comments). 

To defend my short commit-logs, I'm used to work with svn command line tool and 
the -m switch.
Changing that is not easy for me, but I can do so...

Stephan

Re: feature request: edit tex files

[Yann Disser]

On 1. Nov 2010, at 14:22, Jürgen Spitzmüller wrote:

 Yann Disser wrote:
 Your arguments make sense. However, I think many people must have my
 problem. Perhaps it would be sufficient to provide a way to keep the .lyx
 file and the .tex file in sync. Whenever one of the two would get changed,
 lyx would automatically import/export. This approach would then work for
 all file formats for which there is an import and an export handler. It
 would make my life dramatically easier when trying to collaborate via
 svn/git/... 
 
 Of course, the approach has limitations, like what to do, if both files get
 modified at the same time. Also it does not deal with the preamble
 problem. But I think, even ignoring these things (by asking the user which
 file to take over), the feature would be incredibly helpful.
 
 What do you think?
 
 I agree it would be nice. But it's almost impossible. The problem is that 
 (La)TeX provides multiple ways (packages) for achieving the same thing. LyX 
 will never be able to support them all, so either your LaTeX collaborators 
 will needs to know what LyX supports (which is not what they will want to 
 know) or the LyX file will be cluttered with ERT. Also, some of the non-tex-
 relevant information will get lost on the way.
 
 So, like Pavel already notes, if you collaborate intensely with LaTeX users, 
 using a LaTeX editor is probably much more adequate.
 
 Jürgen

What would also already be very helpful would be the ability to export not the 
entire document, but only the part which is currently selected (we usually have 
one .tex file per chapter/section). At the moment I am doing this by 
copy-pasting from the source view to a text editor. But exporting individual 
parts, say sections/tables/etc..., might be very useful not only for me. And it 
should not be so difficult to implement, right? I am thinking about a checkbox 
in the export dialog à la export selection only.

Yann

Re: #6871: Missing screen update can cause assertion after lyxserver communication

[Abdelrazak Younes]

On 11/02/2010 12:31 PM, LyX Ticket Tracker wrote:

Comment(by sanda):

  But you will still have a latent bug here.

  so this 'fix' is still not fixing the root cause, right?
   


Right.

vcs load problem

[Vincent van Ravesteijn]

first step to cure the VCS load problem

Can I please remind you and ask you to write meaningful commit-logs. Logs 
explaining why the change has been made, why the new design or solution or 
implementation is better, what problem it fixed, why other solutions might be 
wrong although it may seem not to be at first sight and so forth.

In the example of the VCS load problem, please explain what the VCS load 
problem is. Please explain why it is only a first step, and what still needs to 
be done.

The VCS load problem is (was) twofold:
1. the parser of the document needs the VCS state so this state (checked by 
file_found_hook) had to be done earlier.
=  first step, move it some lines up, above the readDocument() call.


Why does the parser need to know the state ? If the state changes, do we 
then reparse the file too ? I think this stumbles on a other design 
problem.


If we have a file, we insert an InsetInfo about vcs, then we add the 
file to a vcs, will the InsetInfo be updated ? Apparently not, 
apparently the file is updated not until we parse the file again.


We probably need to have some call in updateBuffer or something that 
will update the InsetInfo's, and we call updateBuffer() probably 
somewhere after loading the file, so we don't need to register the vc 
status while reading the file.



2. in case of loading the autosave or emergency file the real file name has to 
be passed to file_found_hook.
=  the patch I posted does this. (I missed to diff src/buffer_funcs.cpp and - 
of course - I'd fix the comments).


Well, I made two public functions of Buffer: loadLyXFile and 
loadThisLyXFile. The first one takes a filename, checks for 
autosave/emergency files, and when it is sure which file exactly it 
wants to read it calls loadThisLyXFile(). So, after this point, the code 
shouldn't be adapted to the fact that LyX is reading a different file as 
the user requested.


The name of the file is already stored in d-filename, so we can just 
call lyxvc.found_file_hook(d-filename). The only reason for readFile to 
have a FileName parameter is that we might want to load a 
recovery/emergency save file instead. This brings me to the conclusion 
that the FileName parameter to loadLyXFile and loadThisLyXFile is 
already WRONG!. We do not set d-filename when calling this file, so we 
have to make sure that we call loadLyXFile and loadThisLyXFile with 
exactly the same filename as the one we supplied when creating the 
buffer. If we rename the buffer we have to explicitly call 
Buffer::setFileName.


To conclude: instead of adding a second parameter to the load*LyXFIle 
functions, I think we should lose all parameters because we already have 
this information. The problem with lyxvc only revealed this bug. Thank 
you for finding the thinko that was present in the code. But please 
don't cure the symptom but criticisize and fix the (re)design.


Please correct me if I'm wrong. I'm just thinking aloud.

Vincent

Re: vcs load problem

[Stephan Witt]

Am 02.11.2010 um 12:34 schrieb Vincent van Ravesteijn:

 
 first step to cure the VCS load problem
 Can I please remind you and ask you to write meaningful commit-logs. Logs 
 explaining why the change has been made, why the new design or solution or 
 implementation is better, what problem it fixed, why other solutions might 
 be wrong although it may seem not to be at first sight and so forth.
 
 In the example of the VCS load problem, please explain what the VCS load 
 problem is. Please explain why it is only a first step, and what still 
 needs to be done.
 The VCS load problem is (was) twofold:
 1. the parser of the document needs the VCS state so this state (checked by 
 file_found_hook) had to be done earlier.
 =  first step, move it some lines up, above the readDocument() call.
 
 Why does the parser need to know the state ? If the state changes, do we then 
 reparse the file too ?

Yes. The file is reloaded after VCS operations.

 I think this stumbles on a other design problem.
 
 If we have a file, we insert an InsetInfo about vcs, then we add the file to 
 a vcs, will the InsetInfo be updated ? Apparently not, apparently the file is 
 updated not until we parse the file again.

See above.

 We probably need to have some call in updateBuffer or something that will 
 update the InsetInfo's, and we call updateBuffer() probably somewhere after 
 loading the file, so we don't need to register the vc status while reading 
 the file.

May be. My plan was to complete CVS backend implementation and the last changes 
did disturb it seriously. 
They where overdue but for my TODO list the worst time to happen. So, I where 
tempted to make the hot fixes.

 
 2. in case of loading the autosave or emergency file the real file name has 
 to be passed to file_found_hook.
 =  the patch I posted does this. (I missed to diff src/buffer_funcs.cpp and 
 - of course - I'd fix the comments).
 
 Well, I made two public functions of Buffer: loadLyXFile and loadThisLyXFile. 
 The first one takes a filename, checks for autosave/emergency files, and when 
 it is sure which file exactly it wants to read it calls loadThisLyXFile(). 
 So, after this point, the code shouldn't be adapted to the fact that LyX is 
 reading a different file as the user requested.
 
 The name of the file is already stored in d-filename, so we can just call 
 lyxvc.found_file_hook(d-filename). The only reason for readFile to have a 
 FileName parameter is that we might want to load a recovery/emergency save 
 file instead. This brings me to the conclusion that the FileName parameter to 
 loadLyXFile and loadThisLyXFile is already WRONG!.

I agree.

 We do not set d-filename when calling this file, so we have to make sure 
 that we call loadLyXFile and loadThisLyXFile with exactly the same filename 
 as the one we supplied when creating the buffer. If we rename the buffer we 
 have to explicitly call Buffer::setFileName.
 
 To conclude: instead of adding a second parameter to the load*LyXFIle 
 functions, I think we should lose all parameters because we already have this 
 information. The problem with lyxvc only revealed this bug. Thank you for 
 finding the thinko that was present in the code.

Glad to hear this.

 But please don't cure the symptom but criticisize and fix the (re)design.

I did not have the time to follow your redesign of the buffer load operation 
closely.

 Please correct me if I'm wrong. I'm just thinking aloud.

But you cannot test it easily? I'll test your proposal...

Stephan

Re: Commit logs

[Vincent van Ravesteijn]

Log: first step to cure the VCS load problem

Can I please remind you and ask you to write meaningful commit-logs. Logs 
explaining why the change has been made, why the new design or solution or 
implementation is better, what problem it fixed, why other solutions might be 
wrong although it may seem not to be at first sight and so forth.

In the example of the VCS load problem, please explain what the VCS load 
problem is. Please explain why it is only a first step, and what still needs to 
be done.

To defend my short commit-logs, I'm used to work with svn command line tool and 
the -m switch.
Changing that is not easy for me, but I can do so...


Well, let's have a look at this example. Considering the actually change 
you made, you could have written:

- InsetInfo needs the vcs status during parsing

This is as short as the commit now, but it helps us to reveal the thinko 
I made. You already thought about why the InsetInfo was broken for VCS, 
you found out that it was caused by the fact that I put the call after 
the parse and you corrected it. Please share that info with the others.


After your commit, I now have to look back to the thread what the load 
problem consisted of, then I have to assume that this solves the 
InsetInfo problem, then I have to think for myself why this would fix a 
problem with InsetInfo, and then I find out that it's a wrong design 
that leads to this bug.


I would even go further. If you explicitly note this fact, you can ask 
yourself why I made this error. Probably because I did not know there is 
this design flaw and probably another developer later won't know this 
either. So, it would be good to add a comment to this line saying that 
this line has to be there before the call to parseDocument().


Oh wait, there is already a comment saying that InsetInfo needs it, but 
still I did it wrong. Apparently it was not clear enough to me that 
InsetInfo needs it during the parse process (because it's wrong). So, 
you could update this comment to indicate this fact, because apparently 
either the comment was not clear, or I can't read properly.


I don't want to sound a bit scholarly, I just want to share my ideas to 
improve collaboration, to improve the code design and to help each other 
in order to reach that goal.


Especially in such an opensource project, we need to check upon each 
other. A lot of us are amateur programmers, we do not work with LyX Code 
for 40 hours a week, there is noone who checks the commits as part of 
his job. We have to look at the commits in our free/spare time, so 
please make it as easy for the other developers to check what you did, 
why you did it, what it fixed and so forth.


By the way, I am happy you are doing so much work lately.

Vincent

Re: vcs load problem

[Vincent van Ravesteijn]

The VCS load problem is (was) twofold: 1. the parser of the document needs the 
VCS state so this state (checked by file_found_hook) had to be done earlier.
=   first step, move it some lines up, above the readDocument() call.

Why does the parser need to know the state ? If the state changes, do we then 
reparse the file too ?

Yes. The file is reloaded after VCS operations.


But I'm pretty sure it's not documented there either that if the status 
changes, that we need to reload the file because of InsetInfo depending 
on this ;).



We probably need to have some call in updateBuffer or something that will 
update the InsetInfo's, and we call updateBuffer() probably somewhere after 
loading the file, so we don't need to register the vc status while reading the 
file.

May be. My plan was to complete CVS backend implementation and the last changes 
did disturb it seriously.


I'm sorry.


They where overdue but for my TODO list the worst time to happen. So, I where tempted to 
make the hot fixes.



I don't criticize your hot fixes. I'm happy you found and diagnosed the 
problem.


But I think you understand that if you're correcting my commits and the 
refactoring I did, I'm eager to check whether it was a stupid mistake I 
made, whether my design was wrong, or if there is a higher order problem.





Please correct me if I'm wrong. I'm just thinking aloud.

But you cannot test it easily? I'll test your proposal...


No, I'm in a conference. Not the ideal atmosphere to update, redesign, 
refactor, code, compile, test, mail, and commit. So I stick to the 
mailing part for now :D.


Vincent

Re: vcs load problem

[Stephan Witt]

Am 02.11.2010 um 12:51 schrieb Stephan Witt:

 Am 02.11.2010 um 12:34 schrieb Vincent van Ravesteijn:
 
 
 first step to cure the VCS load problem
 Can I please remind you and ask you to write meaningful commit-logs. Logs 
 explaining why the change has been made, why the new design or solution or 
 implementation is better, what problem it fixed, why other solutions might 
 be wrong although it may seem not to be at first sight and so forth.
 
 In the example of the VCS load problem, please explain what the VCS load 
 problem is. Please explain why it is only a first step, and what still 
 needs to be done.
 The VCS load problem is (was) twofold:
 1. the parser of the document needs the VCS state so this state (checked by 
 file_found_hook) had to be done earlier.
 =  first step, move it some lines up, above the readDocument() call.
 
 Why does the parser need to know the state ? If the state changes, do we 
 then reparse the file too ?
 
 Yes. The file is reloaded after VCS operations.
 
 I think this stumbles on a other design problem.
 
 If we have a file, we insert an InsetInfo about vcs, then we add the file to 
 a vcs, will the InsetInfo be updated ? Apparently not, apparently the file 
 is updated not until we parse the file again.
 
 See above.
 
 We probably need to have some call in updateBuffer or something that will 
 update the InsetInfo's, and we call updateBuffer() probably somewhere after 
 loading the file, so we don't need to register the vc status while reading 
 the file.
 
 May be. My plan was to complete CVS backend implementation and the last 
 changes did disturb it seriously. 
 They where overdue but for my TODO list the worst time to happen. So, I where 
 tempted to make the hot fixes.
 
 
 2. in case of loading the autosave or emergency file the real file name has 
 to be passed to file_found_hook.
 =  the patch I posted does this. (I missed to diff src/buffer_funcs.cpp 
 and - of course - I'd fix the comments).
 
 Well, I made two public functions of Buffer: loadLyXFile and 
 loadThisLyXFile. The first one takes a filename, checks for 
 autosave/emergency files, and when it is sure which file exactly it wants to 
 read it calls loadThisLyXFile(). So, after this point, the code shouldn't be 
 adapted to the fact that LyX is reading a different file as the user 
 requested.
 
 The name of the file is already stored in d-filename, so we can just call 
 lyxvc.found_file_hook(d-filename). The only reason for readFile to have a 
 FileName parameter is that we might want to load a recovery/emergency save 
 file instead. This brings me to the conclusion that the FileName parameter 
 to loadLyXFile and loadThisLyXFile is already WRONG!.
 
 I agree.
 
 We do not set d-filename when calling this file, so we have to make sure 
 that we call loadLyXFile and loadThisLyXFile with exactly the same filename 
 as the one we supplied when creating the buffer. If we rename the buffer we 
 have to explicitly call Buffer::setFileName.
 
 To conclude: instead of adding a second parameter to the load*LyXFIle 
 functions, I think we should lose all parameters because we already have 
 this information. The problem with lyxvc only revealed this bug. Thank you 
 for finding the thinko that was present in the code.
 
 Glad to hear this.
 
 But please don't cure the symptom but criticisize and fix the (re)design.
 
 I did not have the time to follow your redesign of the buffer load operation 
 closely.
 
 Please correct me if I'm wrong. I'm just thinking aloud.
 
 But you cannot test it easily? I'll test your proposal...

The attached patch works.

Stephan

PS. Thank you for the lecture in other mail - (no sarcasm).
My problem is I spend to much time for LyX already. That's why I feel in a 
hurry and make mistakes.
Like solving a problem by curing the symptom.

Index: src/Buffer.cpp
===
--- src/Buffer.cpp  (Revision 35992)
+++ src/Buffer.cpp  (Arbeitskopie)
@@ -876,7 +876,7 @@
}
 
// InsetInfo needs to know if file is under VCS
-   lyxvc().file_found_hook(fn);
+   lyxvc().file_found_hook(d-filename);
 
if (readDocument(lex)) {
Alert::error(_(Document format failure),
@@ -3651,7 +3651,6 @@
bool const success = (ret_llf == ReadSuccess);
if (success) {
markDirty();
-   lyxvc().file_found_hook(fn);
str = _(Document was successfully recovered.);
} else
str = _(Document was NOT successfully recovered.);
@@ -3707,7 +3706,6 @@
// the file is not saved if we load the autosave file.
if (ret_llf == ReadSuccess) {
markDirty();
-   lyxvc().file_found_hook(fn);
return ReadSuccess;
}
return ReadAutosaveFailure;

Re: vcs load problem

[Pavel Sanda]

Vincent van Ravesteijn wrote:
 Why does the parser need to know the state ? If the state changes, do we 
 then reparse the file too ? I think this stumbles on a other design 
 problem.

 If we have a file, we insert an InsetInfo about vcs, then we add the file 
 to a vcs, will the InsetInfo be updated ? Apparently not, apparently the 
 file is updated not until we parse the file again.

 We probably need to have some call in updateBuffer or something that will 
 update the InsetInfo's, and we call updateBuffer() probably somewhere after 
 loading the file, so we don't need to register the vc status while reading 
 the file.

its a design problem and i asked about the solution several times on the list ;)
the problem is that getting up-to-date info needs launching external
programs like svn info and doing it as a part of updateBuffer is
not wise way to do it. we use currently caching inside lyxvc which knows
when its the time to refresh time better then code in updateBuffer would.

pavel

Re: vcs load problem

[Pavel Sanda]

Stephan Witt wrote:
 
 The attached patch works.

i'm happy the other occurences disappeared...
pavel

Re: vcs load problem

[Pavel Sanda]

Vincent van Ravesteijn wrote:
 If we have a file, we insert an InsetInfo about vcs, then we add the file 
 to a vcs, will the InsetInfo be updated ? Apparently not, apparently the 
 file is updated not until we parse the file again.

it will be updated, when you add file to vcs, its reloaded.

pavel

Re: vcs load problem

[Stephan Witt]

Am 02.11.2010 um 13:06 schrieb Vincent van Ravesteijn:

 
 The VCS load problem is (was) twofold: 1. the parser of the document needs 
 the VCS state so this state (checked by file_found_hook) had to be done 
 earlier.
 =   first step, move it some lines up, above the readDocument() call.
 Why does the parser need to know the state ? If the state changes, do we 
 then reparse the file too ?
 Yes. The file is reloaded after VCS operations.
 
 But I'm pretty sure it's not documented there either that if the status 
 changes, that we need to reload the file because of InsetInfo depending on 
 this ;).

It's not only the InsetInfo.
The file locking state, writable/readonly state, contents, buffer headers... to 
mention only the things I can recall quickly.
It's not that bad, to reload the file after VCS operations.

 We probably need to have some call in updateBuffer or something that will 
 update the InsetInfo's, and we call updateBuffer() probably somewhere after 
 loading the file, so we don't need to register the vc status while reading 
 the file.
 May be. My plan was to complete CVS backend implementation and the last 
 changes did disturb it seriously.
 
 I'm sorry.

As I said, you did a good move.

 They where overdue but for my TODO list the worst time to happen. So, I 
 where tempted to make the hot fixes.
 
 I don't criticize your hot fixes. I'm happy you found and diagnosed the 
 problem.
 
 But I think you understand that if you're correcting my commits and the 
 refactoring I did, I'm eager to check whether it was a stupid mistake I made, 
 whether my design was wrong, or if there is a higher order problem.

I understand. And it is better to correct the situation with your careful 
review.

 No, I'm in a conference. Not the ideal atmosphere to update, redesign, 
 refactor, code, compile, test, mail, and commit.

:-)

Stephan

Re: Beta (status update #3)

[Pavel Sanda]

Stephan Witt wrote:
  if you have the patch already feel free to post it, but...
 
 I'll attach it - so you get the idea.
 
 I want to
 1) catch the output of failing system calls to display them in error message 
 dialog
 2) eventually be able to pass it up to caller for parsing it
 3) simplify the tmpfile handling

all these are reasonable goals, but i'm convinced that together with SystemCall 
touches belong to the 2.1 devel cycle. its already beyond the threshold, all 
those
OpMode, getDiff and so on should have been used similarly on all vcs backends.
not having time to digg into the matter i didn't want to frustrate you even more
so kept silence in last vc-stuff threads, but we have to draw line somewhere.

trunk destabilized last days and i want to freeze it for any other devel than 
just
bugfixing asap.

pavel

Re: Beta (status update #3)

[Pavel Sanda]

Vincent van Ravesteijn wrote:
 Yes. Ive got something. Wait

can you share your timetable?
pavel

Re: r35970 - lyx-devel/trunk/src/frontends/qt4

[Vincent van Ravesteijn]

Author: rgheck
Date: Mon Nov  1 20:37:59 2010
New Revision: 35970
URL: http://www.lyx.org/trac/changeset/35970

Log:
Fix bug #7002. I think this is correct, but Peter should check.

May I, may I ?


func_ = f;
-   callInGuiThread();
+   if (theApp() == 0)
+   synchronousFunctionCall();
+   else
+   callInGuiThread();
}


Why not doing this check in callInGuiThread(). There already is made a 
decision whether to call it in a new thread or not:


void IntoGuiThreadMover::callInGuiThread()
{
QThread* gui_thread = QApplication::instance()-thread();
if (QThread::currentThread() == gui_thread) {
// do synchronous thing
else
// do threaded thing
}

Isn't it as simple to change this to something like:

QApplication * app = QApplication::instance();
if (!app || QThread()::currentThread() = app-thread())
// do synchronous thing
else
// do threaded thing

Vincent

Re: r35970 - lyx-devel/trunk/src/frontends/qt4

[Vincent van Ravesteijn]

 Sorry, Peter already did this.

Vincent

Re: r35867 - in lyx-devel/trunk/src/frontends/qt4: . ui

[Jean-Marc Lasgouttes]

Le 01/11/2010 14:27, Pavel Sanda a écrit :

you...@lyx.org wrote:

Modified: lyx-devel/trunk/src/frontends/qt4/ui/HyperlinkUi.ui
==
--- lyx-devel/trunk/src/frontends/qt4/ui/HyperlinkUi.ui Wed Oct 27 14:55:57 
2010(r35866)
+++ lyx-devel/trunk/src/frontends/qt4/ui/HyperlinkUi.ui Wed Oct 27 19:02:42 
2010(r35867)
@@ -1,20 +1,18 @@
+?xml version=1.0 encoding=UTF-8?


i see these lines are becoming part of our ui files more and more often.
is there anybody around to check it compiles with qt 4.2.2
which we claim to support?


Not me anymore.

JMarc

Re: feature request: edit tex files

[Jim Oldfield]

 
 I agree it would be nice. But it's almost impossible. The problem is that 
 (La)TeX provides multiple ways (packages) for achieving the same thing. LyX 
 will never be able to support them all, so either your LaTeX collaborators 
 will needs to know what LyX supports (which is not what they will want to 
 know) or the LyX file will be cluttered with ERT. Also, some of the non-tex-
 relevant information will get lost on the way.
 
 So, like Pavel already notes, if you collaborate intensely with LaTeX users, 
 using a LaTeX editor is probably much more adequate.
 
 Jürgen


I think that most people who want collaboration with LaTeX people assume that 
the way to do this as by LyX editing LaTeX directly, and they pass this idea on 
to this list, where it is (quite rightly) rejected as infeasible. I know very 
little about the implementation of LyX, so I'm sorry to be presumptuous, but it 
seems to me that there's a design idea that hasn't been cosidered.   

Putting the LyX editing LaTeX idea diagrammatically we have (requires 
fixed-width font):

original.tex
|

| (edit in LyX)

v

updated.tex


My suggestion is:


original.tex -- original.lyx

|  / |

| /  | (edit in LyX)

vL   v

updated.tex  -- updated.lyx


Note that in the final step, updated.tex is produced by assembling *all three* 
other files.  I would envisage such a program working by comparing the two .lyx 
files (presumably using LyX change tracking), then only exporting updates to 
.tex, and finally slotting them into the unaltered parts of original.tex.  I 
would imagine original.lyx would need internal references to original.tex to 
help determine where any updates would go.

This could potentially be a separate program, just as tex2lyx is (which 
incidentally is the top, rightward arrow in that diagram).

I think this would be much more realistic than getting LyX to edit LaTeX 
directly.  That does not make it easy in absolute terms though!  And it has 
downsides (such as it not really being possible to edit the preamble this way; 
I 
don't think that's a big deal though).  But I thought I should at least bring 
up 
the idea.

Jim


  

Re: r35995 - lyx-devel/trunk/src

[Pavel Sanda]

rgh...@lyx.org wrote:
 Author: rgheck
 Date: Tue Nov  2 15:50:07 2010
 New Revision: 35995
 URL: http://www.lyx.org/trac/changeset/35995
 
 Log:
 Make sure that the members of this enum get the same value on every
 platform.

btw on which platform will this enum starts on non zero number?
pavel

Re: feature request: edit tex files

[Jean-Marc Lasgouttes]

Le 01/11/2010 14:16, Yann Disser a écrit :

Well, as I said, with automatic sync I do not think it would be so
much of a nightmare anymore. And, for me at least, editing
formula-heavy .tex is also not very enjoyable.


A typical example of when tex-lyx breaks with formulas is when people
use ``helpful'' (or ``clever'') macros like
  \newcommand{\be}{\begin{equation}}
  \newcommand{\ee}{\end{equation}}

A single use of these and -- poof -- the structure of the document is 
dead. LyX would be supposed to output such horrors for the pleasure of 
being a nice cooperative tool?


The constructs are real-life ones, I am sure you saw them too. I give 
them as an example. Every LyX user trying to cooperate with some LaTeX 
user will eventually find such idiosyncrasies and complain that LyX is 
not correct for reversible translation.


Claiming that we try to do it is beginning to open pandora's box.

JMarc

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Richard Heck a écrit :

On 10/31/2010 06:38 AM, Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien a écrit :



So do we have an extra \makeatletter somewhere?


Yes, exporting my example file in LaTeX reads:

cite
\makeatletter

%% LyX specific LaTeX commands.

\AtBeginDocument{\providecommand\secref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\eqref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\lemref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\thmref[1]{\ref{#1}}}
\makeatletter
\...@ifundefined{thmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}
  {}
\...@ifundefined{lemref}
  {\def\RSlemtxt{lemma~}\newref{lem}{name = \RSlemtxt}}
  {}
\makeatother


%% Textclass specific LaTeX commands.
\theoremstyle{plain}
/cite



Currently refstyle cannot work natively with babel multilingual docs,
encapsulating strings definitions in \adddto\captions works, I've 
contacted Danie Els about this.



Is there something we can do in the meantime?


I got an anwer from Danie, I was mistaken about the multilingual feature of 
refstyle: it works all right (as \def commands are encapsulated in \extraslang 
commands) if refstyle is loaded *after* babel.


Is it possible to do this in LyX ?

In the meantime, I've found another point which the current patch misses:
part and chap are the prefixes in refstyle, so old refs are replaced by ?? if 
the Use refstyle box is checked.
I've added to convert_prettyref in lyx-2.0.py the code that you wrote last April 
and that I enhanced to convert all prefixes cha and par to chap and part.

I've added a step to deal with \newrefformat commands in the preamble.
Currently my re_newref string works as a command line in the pyton interpreter:

cite
$ python
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
 import re
 re_newref = re.compile(r\newrefformat\{(\w+)\}\{(\w+))
 m=re_newref.match('\newrefformat{cha}{Chapitre~\ref{#1}}')
 print m.group(1)
cha
 print m.group(2)
Chapitre

/cite

but not in the convert_prettyref code (beware of the extra newlines added by my 
mailer, I've posted the corresponding patch on bug #6609 anyway):


cite
  def convert_prettyref(document):
	 Converts prettyref references to neutral formatted refs, updates part and 
chapter prefixes 

re_ref = re.compile(^\s*reference\s+\(\w+):(\S+)\)
re_lab = re.compile(^\s*name\s+\(\w+):(\S+)\)
re_newref = re.compile(r\newrefformat\{(\w+)\}\{(\w+))
   # Note: step 1, \newrefformat part: and chap: susbtitutions for par: 
and cha:

i = 0
while True:
i = find_token(document.preamble, \\newrefformat{, i)
result=document.preamble[i]
document.warning(Found document.preamble[i] + result)
if i == -1:
break
m = re_newref.match(result)
if m:
prefix = m.group(1)
remain = m.group(2)
document.warning(Found  + prefix +   + result)
if prefix == cha:
prefix = chap
elif prefix == par:
prefix = part
document.preamble[i] = \\newrefformat + \{ + prefix + \} 
+ remain

i = i + 1
# Note: step 2, reference part: and chap: susbtitutions for par: 
and cha:

i = 0
while True:
i = find_token(document.body, \\begin_inset CommandInset ref, i)
if i == -1:
break
j = find_end_of_inset(document.body, i)
if j == -1:
document.warning(Malformed LyX document: No end of InsetRef)
i += 1
continue
i += 1
k = find_token(document.body, reference, i)
if k == -1 or k  j:
i = j + 1
continue
m = re_ref.match(document.body[k])
if m:
prefix = m.group(1)
suffix = m.group(2)
if prefix == cha:
prefix = chap
elif prefix == par:
prefix = part
document.body[k] = reference +  \ + prefix + : + suffix 
+ \

i = j + 1
# Note: step 3, label  part: and chap: susbtitutions for par: and 
cha:
i = 0
while True:
i = find_token(document.body, \\begin_inset CommandInset label, i)
if i == -1:
break
j = find_end_of_inset(document.body, i)
if j == -1:
document.warning(Malformed LyX document: No end of InsetRef)
i += 1
continue
i += 1
k = find_token(document.body, name, i)
if k == -1 or k  j:
i = j + 1
continue
m = re_lab.match(document.body[k])
if m:
   

Re: r35995 - lyx-devel/trunk/src

[Richard Heck]

On 11/02/2010 10:53 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:
   

Author: rgheck
Date: Tue Nov  2 15:50:07 2010
New Revision: 35995
URL: http://www.lyx.org/trac/changeset/35995

Log:
Make sure that the members of this enum get the same value on every
platform.
 

btw on which platform will this enum starts on non zero number?

   

I don't know for sure. But the file Uwe posted with #7005 had:
\html_math_output -1
which was what was causing the problem. Since we are outputting the enum 
value in BufferParams::write(), I am guessing that VC++ is starting it 
on -1? The first value is the default, and it is properly set.


Richard

Abdel

[Abdelrazak Younes]

On 11/02/2010 04:29 PM, Richard Heck wrote:

On 11/02/2010 10:53 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:

Author: rgheck
Date: Tue Nov  2 15:50:07 2010
New Revision: 35995
URL: http://www.lyx.org/trac/changeset/35995

Log:
Make sure that the members of this enum get the same value on every
platform.

btw on which platform will this enum starts on non zero number?


I don't know for sure. But the file Uwe posted with #7005 had:
\html_math_output -1
which was what was causing the problem. Since we are outputting the 
enum value in BufferParams::write(), I am guessing that VC++ is 
starting it on -1? The first value is the default, and it is properly 
set.


I don't think so. I don't know for sure but think an enum is guaranted 
to start from zero on all platform by the standard (unless if set 
otherwise). But I am pretty sure this is the case also for VC++.


Abdel.

Re: Abdel

[Richard Heck]

On 11/02/2010 11:34 AM, Abdelrazak Younes wrote:

On 11/02/2010 04:29 PM, Richard Heck wrote:

On 11/02/2010 10:53 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:

Author: rgheck
Date: Tue Nov  2 15:50:07 2010
New Revision: 35995
URL: http://www.lyx.org/trac/changeset/35995

Log:
Make sure that the members of this enum get the same value on every
platform.

btw on which platform will this enum starts on non zero number?


I don't know for sure. But the file Uwe posted with #7005 had:
\html_math_output -1
which was what was causing the problem. Since we are outputting the 
enum value in BufferParams::write(), I am guessing that VC++ is 
starting it on -1? The first value is the default, and it is properly 
set.


I don't think so. I don't know for sure but think an enum is guaranted 
to start from zero on all platform by the standard (unless if set 
otherwise). But I am pretty sure this is the case also for VC++.


Well, it can't hurt to specify that it starts from 0. And I'm not sure 
how Uwe could otherwise have gotten the line with -1.


rh

Re: Abdel

[Abdelrazak Younes]

On 11/02/2010 04:35 PM, Richard Heck wrote:

On 11/02/2010 11:34 AM, Abdelrazak Younes wrote:

On 11/02/2010 04:29 PM, Richard Heck wrote:

On 11/02/2010 10:53 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:

Author: rgheck
Date: Tue Nov  2 15:50:07 2010
New Revision: 35995
URL: http://www.lyx.org/trac/changeset/35995

Log:
Make sure that the members of this enum get the same value on every
platform.

btw on which platform will this enum starts on non zero number?


I don't know for sure. But the file Uwe posted with #7005 had:
\html_math_output -1
which was what was causing the problem. Since we are outputting the 
enum value in BufferParams::write(), I am guessing that VC++ is 
starting it on -1? The first value is the default, and it is 
properly set.


I don't think so. I don't know for sure but think an enum is 
guaranted to start from zero on all platform by the standard (unless 
if set otherwise). But I am pretty sure this is the case also for VC++.



Well, it can't hurt to specify that it starts from 0.


Sure. I even consider this good practice.


And I'm not sure how Uwe could otherwise have gotten the line with -1.


Don't know... But if this is tabular code that won't surprise me...

Abdel.

Re: r35995 - lyx-devel/trunk/src

[Pavel Sanda]

Richard Heck wrote:
 Log:
 Make sure that the members of this enum get the same value on every
 platform.
  
 btw on which platform will this enum starts on non zero number?


 I don't know for sure. But the file Uwe posted with #7005 had:
 \html_math_output -1
 which was what was causing the problem. Since we are outputting the enum 
 value in BufferParams::write(), I am guessing that VC++ is starting it on 
 -1? The first value is the default, and it is properly set.

i have hard time to believe this. isn't possible that this -1 code was
generated by some crazy code in lyx2lyx?

pavel

Re: Abdel

[Richard Heck]

On 11/02/2010 11:39 AM, Abdelrazak Younes wrote:

On 11/02/2010 04:35 PM, Richard Heck wrote:


Well, it can't hurt to specify that it starts from 0.


Sure. I even consider this good practice.


And I'm not sure how Uwe could otherwise have gotten the line with -1.


Don't know... But if this is tabular code that won't surprise me...


No, it's just from

os  \\tracking_changes   convertstring(trackChanges)  '\n'
 \\output_changes   convertstring(outputChanges)  '\n'
 \\html_math_output   html_math_output  '\n'
 \\html_be_strict   convertstring(html_be_strict)  '\n';

and somehow we get:
\html_math_output -1
in the LyX file.

rh

Re: r35995 - lyx-devel/trunk/src

[Richard Heck]

On 11/02/2010 11:41 AM, Pavel Sanda wrote:

Richard Heck wrote:
   

Log:
Make sure that the members of this enum get the same value on every
platform.

 

btw on which platform will this enum starts on non zero number?


   

I don't know for sure. But the file Uwe posted with #7005 had:
 \html_math_output -1
which was what was causing the problem. Since we are outputting the enum
value in BufferParams::write(), I am guessing that VC++ is starting it on
-1? The first value is the default, and it is properly set.
 

i have hard time to believe this. isn't possible that this -1 code was
generated by some crazy code in lyx2lyx?

   
Possible, but I checked that (and fixed a thinko). Here is the only 
place it could be:


def convert_math_output(document):
 Convert \html_use_mathml to \html_math_output 
i = find_token(document.header, \\html_use_mathml, 0)
if i == -1:
return
rgx = re.compile(r'\\html_use_mathml\s+(\w+)')
m = rgx.match(document.header[i])
newval = 0 # MathML
if m:
  val = m.group(1)
  if val != true:
newval = 2 # Images
else:
  document.warning(Can't match  + document.header[i])
document.header[i] = \\html_math_output  + newval

How do you get -1 out of that?

Richard

Re: Abdel

[Pavel Sanda]

Abdelrazak Younes wrote:
 I don't think so. I don't know for sure but think an enum is guaranted to 
 start from zero on all platform by the standard (unless if set 

older C++ standard i have (but should be the same nowadays) says:
If the first enumerator has no initializer, the value of the corresponding 
constant is zero.
(chap. 7.2, Enumeration declarations)

pavel

Re: r36001 - lyx-devel/trunk/src

[Pavel Sanda]

rgh...@lyx.org wrote:
 Author: rgheck
 Date: Tue Nov  2 16:42:45 2010
 New Revision: 36001
 URL: http://www.lyx.org/trac/changeset/36001
 
 Log:
 Perhaps this is overkill, but it can't hurt

yes, it is overkill. the quote from standard continues:

An enumerator-definition without an initializer gives the enumerator the value 
obtained by increasing the value of the previous enumerator by one.

pavel

Re: r36001 - lyx-devel/trunk/src

[Richard Heck]

On 11/02/2010 11:57 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:
   

Author: rgheck
Date: Tue Nov  2 16:42:45 2010
New Revision: 36001
URL: http://www.lyx.org/trac/changeset/36001

Log:
Perhaps this is overkill, but it can't hurt
 

yes, it is overkill. the quote from standard continues:

An enumerator-definition without an initializer gives the enumerator the value 
obtained by increasing the value of the previous enumerator by one.

   
Yes, but perhaps it makes clear to anyone who comes along later not to 
mess with the order.


Richard

Re: r35867 - in lyx-devel/trunk/src/frontends/qt4: . ui

[Uwe Stöhr]

 i see these lines are becoming part of our ui files more and more
 often.
 is there anybody around to check it compiles with qt 4.2.2
 which we claim to support?

It doesn't compile with Qt 4.2.x with this line. André once explained us 
why and that one must have at least Qt 4.3.0 to get it compilable.


However, if Jürgen doesn't use Qt 4.2 anymore I think nobody of us do 
and we will sooner or later forget to remove this line when committing 
UI stuff. So I think its best to promise only Qt 4.3.0 support for LyX 2.0.


regards Uwe

Re: r35867 - in lyx-devel/trunk/src/frontends/qt4: . ui

[Pavel Sanda]

Uwe Stöhr wrote:
  i see these lines are becoming part of our ui files more and more
  often.
  is there anybody around to check it compiles with qt 4.2.2
  which we claim to support?

 It doesn't compile with Qt 4.2.x with this line. André once explained us 
 why and that one must have at least Qt 4.3.0 to get it compilable.

yep i had vague feeling it does not compile, thanks for reminder.

 However, if Jürgen doesn't use Qt 4.2 anymore I think nobody of us do and 
 we will sooner or later forget to remove this line when committing UI 
 stuff. So I think its best to promise only Qt 4.3.0 support for LyX 2.0.

to kill this line is one liner script and scheduling this task before release
is easy. but we can increment required version in 2.1 and perhaps kill some
ifdefs in the code.

pavel

Re: Beta (status update #3)

[Stephan Witt]

Am 02.11.2010 um 13:44 schrieb Pavel Sanda:

 Stephan Witt wrote:
 if you have the patch already feel free to post it, but...
 
 I'll attach it - so you get the idea.
 
 I want to
 1) catch the output of failing system calls to display them in error message 
 dialog
 2) eventually be able to pass it up to caller for parsing it
 3) simplify the tmpfile handling
 
 all these are reasonable goals, but i'm convinced that together with 
 SystemCall 
 touches belong to the 2.1 devel cycle. its already beyond the threshold, all 
 those
 OpMode, getDiff and so on should have been used similarly on all vcs backends.
 not having time to digg into the matter i didn't want to frustrate you even 
 more
 so kept silence in last vc-stuff threads, but we have to draw line somewhere.

Where did you draw the line exactly? :-)

I read your statement as to leave the VCS class untouched for 2.0.
Vincent will solve the buffer read issue.
CVS improvement if info inset output is possible (after review) for 2.0-beta?
I'll use the current style then and one can simplify and refactor later.

When starts the 2.1 cycle, by the way? After 2.0 final release?
Would 2.0 be a branch then?

Stephan

Re: r35867 - in lyx-devel/trunk/src/frontends/qt4: . ui

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
 However, if Jürgen doesn't use Qt 4.2 anymore I think nobody of us do 
 and we will sooner or later forget to remove this line when committing 
 UI stuff. So I think its best to promise only Qt 4.3.0 support for LyX 2.0.

Personally, I do not use Qt 4.2 (but 4.7), but I use a 4.2 designer for LyX 
dialogs. I think as long as it's that easy to support Qt 4.2, we should not 
exclude it just out of lazyness. After all, there might still be some 
conservative admins out there.

Jürgen

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Jean-Pierre Chrétien a écrit :

Richard Heck a écrit :

On 10/31/2010 06:38 AM, Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien a écrit :




I got an anwer from Danie, I was mistaken about the multilingual feature 
of refstyle: it works all right (as \def commands are encapsulated in 
\extraslang commands) if refstyle is loaded *after* babel.


Is it possible to do this in LyX ?


Danie corrected a bug about : being active with the new nokeyprefix option
in refstyle 0.4 (-v0.4a, currently unpublished), and in the same new version 
0.4a he managed to avoid the need to load babel before refstyle.
Thus it does not seem urgent to do someting about the multi-lingual refstyle 
feature.


--
Jean-Pierre

Re: Beta (status update #3)

[Pavel Sanda]

Stephan Witt wrote:
 Where did you draw the line exactly? :-)

thats difficult to describe exactly :)
when you asked about some cvs improvements i thought you just want to replace
few cvs parameters and perhaphs push one two new commands, give it testing and
check the documentation. that was what i meant by being inside CVS class only.

when the first patch arrived i was surprised by the complexity, all these 
edit/unedit/gettarget methods, OpMode and so on :) but fine, when i sat down it 
was
possible to understand whats going on, though i felt some of these things should
be part of VCS class (thats what i mean being outside CVS class). i became 
definitely
nervous when you introduced the CvsStatus state machine - didnt take hours
to read it but the fact that i was not able to grasp internal logic of the code
just by going through the patch suggests that anybody who will maintain later 
this
part of code will have hard times...

the reason is that you try to handle corner cases which, admittedly, are not
handled in others backends. this is of course for discussion - my opinion till
now was that only basic support is given and anybody who wants to use VCS should
know rcs/svn reasonably well. this is stated clearly in manual and without some
commandline actions proper usage of lyx VCS is not possible.

background reason is that trying to build some reliable mechanism on the top of
3rd party tools and guess whats going from some fancy error messages is going
to be maintenance nightmare.

second thing is future - if we want to redesign VCS for something more complex
we should focus on some up-to-date concepts from bazaar or git and not creatures
from past. (personally i thing the _reliable_ thing could be including
part of code from git used internally for embedded format, perhaps with
some hooks to remote pushing, fetching... wow, this would be cool.)

in any case we need to flame longer time how the api should like.
this needs thinking and time and no pressure from approaching release.

 CVS improvement if info inset output is possible (after review) for 2.0-beta?

if its possible to make it simple and stupid using the current philosophy then 
yes.
if you need to redesign things around, please let it sleep, its too late.

 When starts the 2.1 cycle, by the way? After 2.0 final release?
 Would 2.0 be a branch then?

we should wait for for x.y.1 so people focus on bugfixing little more.
iirc this was the case for previous releases too.

pavel

Re: r35995 - lyx-devel/trunk/src

[Andre Poenitz]

On Tue, Nov 02, 2010 at 03:53:56PM +0100, Pavel Sanda wrote:
 rgh...@lyx.org wrote:
  Author: rgheck
  Date: Tue Nov  2 15:50:07 2010
  New Revision: 35995
  URL: http://www.lyx.org/trac/changeset/35995
  
  Log:
  Make sure that the members of this enum get the same value on every
  platform.
 
 btw on which platform will this enum starts on non zero number?

It's guaranteed to be zero. Adding the ... = 0 might give more clarity,
though, as in for this enum we care about the numerical values.

Andre'

Re: r35970 - lyx-devel/trunk/src/frontends/qt4

[Peter Kümmel]

On 02.11.2010 14:46, Vincent van Ravesteijn wrote:
   Sorry, Peter already did this.
 
 Vincent
 

Sorry, should have dropped a mail to the list.
But it's nice to see others have similar ideas.

Peter

Re: r35867 - in lyx-devel/trunk/src/frontends/qt4: . ui

[Peter Kümmel]

 exclude it just out of lazyness. After all, there might still be some 
 conservative admins out there.
 
 Jürgen
 

Will a conservative admin install LyX 2?

Peter

Re: RefStyle Patch

[Richard Heck]

On 11/02/2010 02:01 PM, Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien a écrit :


I got an anwer from Danie, I was mistaken about the multilingual 
feature of refstyle: it works all right (as \def commands are 
encapsulated in \extraslang commands) if refstyle is loaded *after* 
babel.


Is it possible to do this in LyX ?


Danie corrected a bug about : being active with the new nokeyprefix 
option
in refstyle 0.4 (-v0.4a, currently unpublished), and in the same new 
version 0.4a he managed to avoid the need to load babel before refstyle.
Thus it does not seem urgent to do someting about the multi-lingual 
refstyle feature.


OK, so, for the time being, anyway, we think refstyle support is 
complete? Or am I misremembering some other issue?


Richard

Re: Beta (status update #3)

[Vincent van Ravesteijn]

When starts the 2.1 cycle, by the way? After 2.0 final release?
Would 2.0 be a branch then?

we should wait for for x.y.1 so people focus on bugfixing little more.
iirc this was the case for previous releases too.

pavel


I wanted to propose to start the 2.0.x branch when you enter the 
feature-freeze/beta state. This would allow to continue redesigning and 
refactoring the code, because I stumble on this everytime I try to fix 
real problems in the codebase.


Last year we created a new trunk some days after releasing 1.6.0 (but we 
were in Berlin back then).


Other opinions ?

Vincent

Re: Beta (status update #3)

[Pavel Sanda]

Vincent van Ravesteijn wrote:
 I wanted to propose to start the 2.0.x branch when you enter the 
 feature-freeze/beta state. This would allow to continue redesigning and 
 refactoring the code, because I stumble on this everytime I try to fix real 
 problems in the codebase.

we can discuss it. what i fear is that people stop focus on 2.0 and start to 
work
new games in trunk. that said i'm aware that exactly you dont fit into this 
category
and your 1.6 bugfixing activity during 2.0 development was just perfect.
it will most probably also reduce our testing for 2.0, since most people
will just continue trunk...

another possibility is that you create personal branch is push the changes 
there.
people will still see changelongs and can comment on them.

lets hear what other people think.

 Last year we created a new trunk some days after releasing 1.6.0 (but we 
 were in Berlin back then).

2 years, but you are right ;)
pavel

Re: #6940: Check lilypond before release

[Julien Rioux]

On 01/11/2010 8:37 PM, Julien Rioux wrote:

On 01/11/2010 6:49 PM, Pavel Sanda wrote:

Julien Rioux wrote:

This is with instant preview on, opening the file examples/lilypond.lyx,
the preview fails (some lilypond code in there should be changed) and
then
this signal occurs.


thanks, can you try whether trunk, r35921 is better,
because my guess to the r35922 ... ?

pavel



It happens in combination with the --safe flag to lilypond-book... that
one doesn't accept some of the lilypond code I had put in
examples/lilypond.lyx and if I remove that the problem goes away. I'll
send a patch shortly.



Updates to examples/lilypond.lyx
  - requirements
  - gotchas
  - removed some lilypond code which made lilypond-book safe-mode unhappy

With these changes I don't see my previous crash. I tried to reproduce 
with a minimal example file but could not do it. Nevertheless there 
seems to be a crash hidden somewhere, when the generation of preview 
images fail yet LyX tries to display these images.


(That's just a guess, I'm backtrace illiterate)

Cheers,
Julien
Index: lib/examples/lilypond.lyx
===
--- lib/examples/lilypond.lyx   (revision 36007)
+++ lib/examples/lilypond.lyx   (working copy)
@@ -1,5 +1,5 @@
 #LyX 2.0.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 401
+\lyxformat 404
 \begin_document
 \begin_header
 \textclass article
@@ -12,7 +12,7 @@
 \end_modules
 \maintain_unincluded_children false
 \language english
-\inputencoding utf8
+\inputencoding auto
 \fontencoding global
 \font_roman default
 \font_sans default
@@ -29,7 +29,7 @@
 \output_sync 0
 \bibtex_command default
 \index_command default
-\paperfontsize 12
+\paperfontsize default
 \spacing single
 \use_hyperref false
 \papersize default
@@ -43,6 +43,7 @@
 \use_indices false
 \paperorientation portrait
 \suppress_date false
+\use_refstyle 0
 \index Index
 \shortcut idx
 \color #008000
@@ -97,46 +98,28 @@
 Requirements
 \end_layout
 
-\begin_layout List
-\labelwidthstring 00.00.
-LaTeX
-\begin_inset space ~
-\end_inset
-
-support: LilyPond-book version 2.1
+\begin_layout Itemize
+LilyPond-book version 2.13
 \end_layout
 
-\begin_layout List
-\labelwidthstring 00.00.
-PDFLaTeX
-\begin_inset space ~
-\end_inset
-
-support: LilyPond-book version 2.11
-\end_layout
-
 \begin_layout Paragraph
 Notes:
 \end_layout
 
 \begin_layout Standard
 LilyPond-book supports LaTeX output since version 2.1.
- PDFLaTeX requires LilyPond-book version 2.9 or older, but there are bugs
- in those early versions.
- We require version 2.11 and older because we use the -
-\begin_inset ERT
-status collapsed
-
-\begin_layout Plain Layout
-
-{}
+ However, some features used by LyX are available only in recent versions:
+ PDFLaTeX support (version 2.9), the 
+\family typewriter
+--lily-output-dir
+\family default
+ flag (version 2.11) and especially the 
+\family typewriter
+--safe
+\family default
+ flag (version 2.13).
 \end_layout
 
-\end_inset
-
--lily-output-dir flag.
-\end_layout
-
 \begin_layout Subsection
 Integration
 \end_layout
@@ -384,6 +367,65 @@
 
 \end_layout
 
+\begin_layout Standard
+Another gotcha is with subsequent lilypond snippets with 
+\family typewriter
+
+\backslash
+fret-diagram
+\family default
+ markup commands:
+\end_layout
+
+\begin_layout LyX-Code
+
+\backslash
+begin{lilypond}
+\end_layout
+
+\begin_layout LyX-Code
+  
+\backslash
+markup{ 
+\backslash
+fret-diagram-terse #x;3;2;o;1;o; }
+\end_layout
+
+\begin_layout LyX-Code
+
+\backslash
+end{lilypond}
+\end_layout
+
+\begin_layout LyX-Code
+
+\end_layout
+
+\begin_layout LyX-Code
+
+\backslash
+begin{lilypond}
+\end_layout
+
+\begin_layout LyX-Code
+  
+\backslash
+markup{ 
+\backslash
+fret-diagram-terse #x;x;o;2;3;2; }
+\end_layout
+
+\begin_layout LyX-Code
+
+\backslash
+end{lilypond}
+\end_layout
+
+\begin_layout Standard
+For some reason LilyPond-book version 2.13 barks on this when run in safe
+ mode (which you always should use, unless you know what you are doing).
+\end_layout
+
 \begin_layout Section
 LilyPond examples
 \end_layout
@@ -396,25 +438,16 @@
 
 \end_inset
 
- shows that any valid LilyPond construct can be handled, no matter how 
complicat
-ed.
+ shows a complex example using many LilyPond constructs; some inline scheme
+ code has been removed to be able to run in safe mode.
  Example 
 \begin_inset CommandInset ref
 LatexCommand ref
-reference sub:Positioning-of-markup
-
-\end_inset
-
- shows how you can mix LilyPond code with tables to display the fingering
- of guitar chords.
- And Example 
-\begin_inset CommandInset ref
-LatexCommand ref
 reference sub:Tablatures-template
 
 \end_inset
 
- shows yet another LilyPond output for guitarists.
+ shows another LilyPond output which should be interesting to guitarists.
 \end_layout
 
 \begin_layout Subsection
@@ -492,14 +525,14 @@
 
 \begin_layout Plain Layout
 
-
+%
 \backslash
 set Staff.fingeringOrientations = #'(up)
 

Re: r35867 - in lyx-devel/trunk/src/frontends/qt4: . ui

[Richard Heck]

On 11/02/2010 06:50 PM, Pavel Sanda wrote:

Peter Kümmel wrote:
   

exclude it just out of lazyness. After all, there might still be some
conservative admins out there.
   

well, conservative admins... current release of centos has 4.2.1...

   

Will a conservative admin install LyX 2?
 

the admin no, but the user can do it locally without need to compile qt
locally too. actually i have been doing exactly this on more old systems
recently...

   

Sure, but such people COULD compile Qt4 locally.

That said, it's fine with me if we switch trunk to =Qt 4.4 after the split.

rh

Re: r35867 - in lyx-devel/trunk/src/frontends/qt4: . ui

[Pavel Sanda]

Peter Kümmel wrote:
  exclude it just out of lazyness. After all, there might still be some 
  conservative admins out there.

well, conservative admins... current release of centos has 4.2.1...

 Will a conservative admin install LyX 2?

the admin no, but the user can do it locally without need to compile qt
locally too. actually i have been doing exactly this on more old systems
recently...

pavel

Re: contributions

[Richard Heck]

On 11/02/2010 04:19 PM, John Perry wrote:

to whom it may concern,

I hereby grant permission to use my contributions to LyX under the GPL
license version 2 or later.

   
Thanks. I'll get you into the CREDITS file once the message appear on 
MARC. (We reference it that way.)


rh

contributions

[John Perry]

to whom it may concern,

I hereby grant permission to use my contributions to LyX under the GPL
license version 2 or later.

regards
john perry

Re: Beta (status update #3)

[Stephan Witt]

Am 02.11.2010 um 19:27 schrieb Pavel Sanda:

 Stephan Witt wrote:
 Where did you draw the line exactly? :-)
 
 thats difficult to describe exactly :)

Wow, long text...

 when you asked about some cvs improvements i thought you just want to replace
 few cvs parameters and perhaphs push one two new commands, give it testing and
 check the documentation. that was what i meant by being inside CVS class only.

That's what I thought too at the beginning.

 when the first patch arrived i was surprised by the complexity, all these 
 edit/unedit/gettarget methods, OpMode and so on :) but fine, when i sat down 
 it was
 possible to understand whats going on, though i felt some of these things 
 should
 be part of VCS class (thats what i mean being outside CVS class). i became 
 definitely
 nervous when you introduced the CvsStatus state machine - didnt take hours
 to read it but the fact that i was not able to grasp internal logic of the 
 code
 just by going through the patch suggests that anybody who will maintain later 
 this
 part of code will have hard times...

I only introduced the getState() method because I couldn't collect the error 
message.
And I definitely do not like a program raising the error message basically 
telling
not more than something's wrong here. So I tried to reduce the likelihood of 
that.

 the reason is that you try to handle corner cases which, admittedly, are not
 handled in others backends. this is of course for discussion - my opinion till
 now was that only basic support is given and anybody who wants to use VCS 
 should
 know rcs/svn reasonably well. this is stated clearly in manual and without 
 some
 commandline actions proper usage of lyx VCS is not possible.

That's not a corner case. If you collaborate it happens that your partner commit
a change while you're editing the same document. And then - combined with the 
poor
error message - you have no chance to understand what happens. And that I'd call
a bug.

 background reason is that trying to build some reliable mechanism on the top 
 of
 3rd party tools and guess whats going from some fancy error messages is going
 to be maintenance nightmare.

Ok, I said it - at first I only want to display the message. We're doing the 
scan
already for parsing the update log etc.

 second thing is future - if we want to redesign VCS for something more complex
 we should focus on some up-to-date concepts from bazaar or git and not 
 creatures
 from past. (personally i thing the _reliable_ thing could be including
 part of code from git used internally for embedded format, perhaps with
 some hooks to remote pushing, fetching... wow, this would be cool.)
 
 in any case we need to flame longer time how the api should like.
 this needs thinking and time and no pressure from approaching release.
 
 CVS improvement if info inset output is possible (after review) for 2.0-beta?
 
 if its possible to make it simple and stupid using the current philosophy 
 then yes.
 if you need to redesign things around, please let it sleep, its too late.

No worry, basically I want to adapt the SVN idea.
Using the cvs log -r VCS::version_ command I'd like to parse the log line and 
save the result into - obviously code duplication again - some state variables
inside CVS class.

 
 When starts the 2.1 cycle, by the way? After 2.0 final release?
 Would 2.0 be a branch then?
 
 we should wait for for x.y.1 so people focus on bugfixing little more.
 iirc this was the case for previous releases too.

Hmm, didn't understand that, sorry.

Stephan

Re: Beta (status update #3)

[Richard Heck]

On 11/02/2010 02:31 AM, Stephan Witt wrote:


After my last commit in readFile() it's only the issue with file_found_hook 
being called with the wrong file name in case of autosave and emergency.
I'd like to fix it before (2) or maybe Vincent does it... For users of VCS I'd 
rate it as a serious problem - but not critical.

   

Are you sure that's still an issue? We have e.g.:

Buffer::ReadStatus Buffer::loadAutosave(FileName const  fn)
{
// Now check if autosave file is newer.
FileName const autosaveFile = getAutosaveFileNameFor(fn);

if (ret_llf == ReadSuccess) {
markDirty();
lyxvc().file_found_hook(fn);
return ReadSuccess;
}
...
}

And fn here is the file we're trying to load. That's why we calculate 
the autosave name. The same structure is in the emergency one.


rh

Re: Beta (status update #3)

[Richard Heck]

After my last commit in readFile() it's only the issue with file_found_hook 
being called with the wrong file name in case of autosave and emergency.
I'd like to fix it before (2) or maybe Vincent does it...
For users of VCS I'd rate it as a serious problem - but not critical.
 

To illustrate my plan I post a patch - it's compiling and I tested it quickly.
I hope that's acceptable. Vincent? Do you have a better proposal?

   

OK, so ignore my last message about this.

It looks to me like we are calling file_found_hook both in the emergency 
and autosave routines, and also in readFile. Perhaps the readFile call 
isn't really necessary, or can be moved somewhere else. I.e., maybe that 
shouldn't be done in readFile() at all, but done by the caller.


Richard

Re: Beta (status update #3)

[Richard Heck]

On 11/02/2010 02:31 AM, Stephan Witt wrote:

Am 01.11.2010 um 23:42 schrieb Pavel Sanda:

   

Stephan Witt wrote:
 

Sorry, I went out and could not answer :-)

1) I have a patch at hand to add the ability to collect stderr in system call
and to simplify the stdout collection too. This patch doesn't change the
current interface but adds a second one. VCS is more clean with that.
The need to add  redirection and parse it later to split it vanishes.
   

we are entering new flame even before posting this patch...
to add new interface for each of the backend is not a good thing.
 

I meant a new interface for SystemCall with stdout and stderr parameters.

   
This general structure might also allow, e.g., the actual reporting of 
lyx2lyx errors, which would be very nice.


Richard

Re: Beta (status update #3)

[Pavel Sanda]

Stephan Witt wrote:
 I only introduced the getState() method because I couldn't collect the error 
 message.

does it mean we can get rid of this CvsStatus creature and logic around if error
messages are caught?

  When starts the 2.1 cycle, by the way? After 2.0 final release?
  Would 2.0 be a branch then?
  
  we should wait for for x.y.1 so people focus on bugfixing little more.
  iirc this was the case for previous releases too.
 
 Hmm, didn't understand that, sorry.

i meant that the 2.1 cycle starts either when we release 2.0.0 or 2.0.1
but apparently there will be discussion about it.

pavel

Re: Beta (status update #3)

[Richard Heck]

On 11/02/2010 07:39 PM, Pavel Sanda wrote:

Vincent van Ravesteijn wrote:
   

I wanted to propose to start the 2.0.x branch when you enter the
feature-freeze/beta state. This would allow to continue redesigning and
refactoring the code, because I stumble on this everytime I try to fix real
problems in the codebase.
 

we can discuss it. what i fear is that people stop focus on 2.0 and start to 
work
new games in trunk. that said i'm aware that exactly you dont fit into this 
category
and your 1.6 bugfixing activity during 2.0 development was just perfect.
it will most probably also reduce our testing for 2.0, since most people
will just continue trunk...

another possibility is that you create personal branch is push the changes 
there.
people will still see changelongs and can comment on them.

lets hear what other people think.

   
Past practice has been as you describe, Pavel, much for the reasons you 
describe. I don't think it's a bad thing for us all to take a break from 
heavy changes and focus on little things for a while, even if it can be 
a bit frustrating. Personal branches are an option for any other work we 
really feel compelled to do. The real problem is that, if the new trunk 
gets refactored twice, then porting bugfixes between trunk and branch 
can become difficult.


There's a difference between refactoring because we think the code is 
ugly or hard to understand, and refactoring that is necessary to fix a 
problem the right way. Freeze means none of the former. The latter sort 
of thing can be considered on a case-by-case basis. I.e., if Vincent 
thinks fixing some bug really requires code surgery, he can post the 
patch and you can decide. He's usually right.


Richard

Re: #6940: Check lilypond before release

[Pavel Sanda]

Julien Rioux wrote:
 Updates to examples/lilypond.lyx
   - requirements
   - gotchas
   - removed some lilypond code which made lilypond-book safe-mode unhappy

thanks, its in.
pavel

Re: Beta (status update #3)

[Vincent van Ravesteijn]

It gets called again in readfile, but then with the wrong name. As discussed
in another thread we can use a single call only and use d-filename.

Op 3 nov 2010 01:06 schreef Richard Heck rgh...@comcast.net:

On 11/02/2010 02:31 AM, Stephan Witt wrote:



 After my last commit in readFile() it's only the issue with
file_found_hook being called wit...
Are you sure that's still an issue? We have e.g.:

Buffer::ReadStatus Buffer::loadAutosave(FileName const  fn)
{
   // Now check if autosave file is newer.
   FileName const autosaveFile = getAutosaveFileNameFor(fn);



   if (ret_llf == ReadSuccess) {
   markDirty();

   lyxvc().file_found_hook(fn);
   return ReadSuccess;
   }
...
}

And fn here is the file we're trying to load. That's why we calculate the
autosave name. The same structure is in the emergency one.

rh

Re: Beta (status update #3)

[Pavel Sanda]

Richard Heck wrote:
 There's a difference between refactoring because we think the code is ugly 
 or hard to understand, and refactoring that is necessary to fix a problem 
 the right way. Freeze means none of the former. The latter sort of thing 
 can be considered on a case-by-case basis. I.e., if Vincent thinks fixing 
 some bug really requires code surgery, he can post the patch and you can 
 decide. He's usually right.

for now my plan was to freeze any refactorizing which is for the sake of clean
code or good architecture. 
but as we move towards rc we should become more strict even in the rest of 
cases.
if we have some bug for 5 years it shouldn't be such a big deal to move it to 
2.1...

pavel

Re: Beta (status update #3)

[Vincent van Ravesteijn]

I would still like to move renamebuffer from guiview to buffer. Fix the vc
problems and I'll quit the refactoring for a while.

Next fun project would be to add testcode for the buffer class. This can be
done in trunk as it won't be compiled for a release.

The features I am preparing still:
- add external documents
- export with all dependent files
- search bar

Most of them is only to prepare for commit , and some GUI.

Vincent

Op 3 nov 2010 01:23 schreef Pavel Sanda sa...@lyx.org:

Richard Heck wrote:
 There's a difference between refactoring because we think the code is ugly

 ...
for now my plan was to freeze any refactorizing which is for the sake of
clean
code or good architecture.
but as we move towards rc we should become more strict even in the rest of
cases.
if we have some bug for 5 years it shouldn't be such a big deal to move it
to 2.1...

pavel

Re: Beta (status update #3)

[Richard Heck]

On 11/01/2010 09:20 AM, Pavel Sanda wrote:

hi,

1. Richard, whats the status of a)? i'm basically waiting only for this.
could you give it top priority on your list if its not fixed yet?

   
I've sent a note to JMarc asking a few questions. Once I'm absolutely 
sure what I need to do, then it will be fairly quick.


One other issue, by the way, which maybe isn't essential for beta1: I've 
written the python for the LFUN and preferences conversion routines, 
mostly, anyway. What we lack at this point is the C++ part of it: The 
part that looks for a format number, like in TextClass.cpp, and then 
launches prefs2prefs if necessary, etc. I'd much appreciate it if 
someone who understands how all that works could do this part.


The preferences part (as opposed to the LFUN) part still needs minor 
work on the python side


Richard

Re: Beta (status update #3)

[Pavel Sanda]

Richard Heck wrote:
 One other issue, by the way, which maybe isn't essential for beta1: I've 
 written the python for the LFUN and preferences conversion routines, 

i dont think this is essential issue.
pavel

Re: Beta (status update #3)

[Stephan Witt]

Am 01.11.2010 um 23:42 schrieb Pavel Sanda:

> Stephan Witt wrote:
>> Sorry, I went out and could not answer :-)
>> 
>> 1) I have a patch at hand to add the ability to collect stderr in system call
>> and to simplify the stdout collection too. This patch doesn't change the
>> current interface but adds a second one. VCS is more clean with that.
>> The need to add ">" redirection and parse it later to split it vanishes.
> 
> we are entering new flame even before posting this patch...
> to add new interface for each of the backend is not a good thing.

I meant a new interface for SystemCall with stdout and stderr parameters.

> all the code should use the same infrastructure and workarounding my request
> not to refactor vcs code base by implementing new lyxvc_for_the_sake_of_cvs
> is not the way i would like to continue ;)

Of course. That I didn't want.

> if you have the patch already feel free to post it, but...

I'll attach it - so you get the idea.

I want to
1) catch the output of failing system calls to display them in error message 
dialog
2) eventually be able to pass it up to caller for parsing it
3) simplify the tmpfile handling

> 
>> 2) I want to complete the CVS implementation. 
>> Add the missing buffer-info things. Add the diff to previous version.
>> 
>> 3) Want the readFile() issue fixed.
> 
> is this beta1 critical stuf?

After my last commit in readFile() it's "only" the issue with file_found_hook 
being called with the wrong file name in case of autosave and emergency.
I'd like to fix it before (2) or maybe Vincent does it... For users of VCS I'd 
rate it as a serious problem - but not critical.

Stephan

Index: src/support/Systemcall.cpp
===
--- src/support/Systemcall.cpp  (Revision 35961)
+++ src/support/Systemcall.cpp  (Arbeitskopie)
@@ -207,14 +207,21 @@
 int Systemcall::startscript(Starttype how, string const & what, bool 
process_events)
 {
string outfile;
+   string errfile;
QString cmd = toqstr(parsecmd(what, outfile));
+   return startscript(how, what, outfile, errfile, process_events);
+}
 
-   SystemcallPrivate d(outfile);
 
+int Systemcall::startscript(Starttype how, string const & what,
+   std::string const & 
outfile, std::string const & errfile, 
+   bool process_events)
+{
+   SystemcallPrivate d(outfile, errfile);
 
-   d.startProcess(cmd);
+   d.startProcess(toqstr(what));
if (!d.waitWhile(SystemcallPrivate::Starting, process_events, -1)) {
-   LYXERR0("Systemcall: '" << cmd << "' did not start!");
+   LYXERR0("Systemcall: '" << what << "' did not start!");
LYXERR0("error " << d.errorMessage());
return 10;
}
@@ -226,7 +233,7 @@
}
 
if (!d.waitWhile(SystemcallPrivate::Running, process_events, 18)) {
-   LYXERR0("Systemcall: '" << cmd << "' did not finished!");
+   LYXERR0("Systemcall: '" << what << "' did not finished!");
LYXERR0("error " << d.errorMessage());
LYXERR0("status " << d.exitStatusMessage());
return 20;
@@ -234,18 +241,18 @@
 
int const exit_code = d.exitCode();
if (exit_code) {
-   LYXERR0("Systemcall: '" << cmd << "' finished with exit code " 
<< exit_code);
+   LYXERR0("Systemcall: '" << what << "' finished with exit code " 
<< exit_code);
}
 
return exit_code;
 }
 
 
-SystemcallPrivate::SystemcallPrivate(const std::string& of) :
+SystemcallPrivate::SystemcallPrivate(const std::string& out_file) :
 process_(new QProcess), 
 out_index_(0),
 err_index_(0),
-out_file_(of), 
+out_file_(out_file), 
 process_events_(false)
 {
if (!out_file_.empty()) {
@@ -262,7 +269,33 @@
 }
 
 
+SystemcallPrivate::SystemcallPrivate(const std::string& out_file, const 
std::string& err_file) :
+   process_(new QProcess), 
+   out_index_(0),
+   err_index_(0),
+   out_file_(out_file), 
+   err_file_(err_file), 
+   process_events_(false)
+{
+   if (!out_file_.empty()) {
+   // Check whether we have to simply throw away the output.
+   if (out_file_ != os::nulldev())
+   process_->setStandardOutputFile(toqstr(out_file_));
+   }
+   if (!err_file_.empty()) {
+   // Check whether we have to simply throw away the error output.
+   if (err_file_ != os::nulldev())
+   process_->setStandardErrorFile(toqstr(err_file_));
+   }
+   
+   connect(process_, SIGNAL(readyReadStandardOutput()), 

Re: Beta (status update #3)

[Stephan Witt]

Am 02.11.2010 um 07:31 schrieb Stephan Witt:

> Am 01.11.2010 um 23:42 schrieb Pavel Sanda:
> 
>> Stephan Witt wrote:
>> 

>>> 3) Want the readFile() issue fixed.
>> 
>> is this beta1 critical stuf?
> 
> After my last commit in readFile() it's "only" the issue with file_found_hook 
> being called with the wrong file name in case of autosave and emergency.
> I'd like to fix it before (2) or maybe Vincent does it...
> For users of VCS I'd rate it as a serious problem - but not critical.

To illustrate my plan I post a patch - it's compiling and I tested it quickly.
I hope that's acceptable. Vincent? Do you have a better proposal?

Stephan

Index: src/Buffer.h
===
--- src/Buffer.h(Revision 35961)
+++ src/Buffer.h(Arbeitskopie)
@@ -196,6 +196,7 @@
/// emergency or autosave files, one should use \c loadLyXFile.
/// /sa loadLyXFile
ReadStatus loadThisLyXFile(support::FileName const & fn);
+   ReadStatus loadThisLyXFile(support::FileName const & fn, 
support::FileName const & on);
/// read a new document from a string
bool readString(std::string const &);
/// Reloads the LyX file
@@ -209,7 +210,7 @@
 
 private:
/// read a new file
-   ReadStatus readFile(support::FileName const & fn);
+   ReadStatus readFile(support::FileName const & fn, support::FileName 
const & on);
/// Reads a file without header.
/// \param par if != 0 insert the file.
/// \return \c true if file is not completely read.
Index: src/Buffer.cpp
===
--- src/Buffer.cpp  (Revision 35985)
+++ src/Buffer.cpp  (Arbeitskopie)
@@ -847,7 +847,7 @@
os << s;
os.close();
// lyxvc in readFile
-   return readFile(fn) == ReadSuccess;
+   return readFile(fn, FileName()) == ReadSuccess;
}
 
if (readDocument(lex))
@@ -856,7 +856,7 @@
 }
 
 
-Buffer::ReadStatus Buffer::readFile(FileName const & fn)
+Buffer::ReadStatus Buffer::readFile(FileName const & fn, FileName const & on)
 {
FileName fname(fn);
Lexer lex;
@@ -872,11 +872,11 @@
ReadStatus const ret_clf = convertLyXFormat(fn, tmpFile, 
file_format);
if (ret_clf != ReadSuccess)
return ret_clf;
-   return readFile(tmpFile);
+   return readFile(tmpFile, FileName());
}
 
// InsetInfo needs to know if file is under VCS
-   lyxvc().file_found_hook(fn);
+   lyxvc().file_found_hook(on.empty() ? fn : on);
 
if (readDocument(lex)) {
Alert::error(_("Document format failure"),
@@ -3647,7 +3647,7 @@
{
case 0: {
docstring str;
-   ReadStatus const ret_llf = loadThisLyXFile(emergencyFile);
+   ReadStatus const ret_llf = loadThisLyXFile(emergencyFile, fn);
bool const success = (ret_llf == ReadSuccess);
if (success) {
markDirty();
@@ -3703,7 +3703,7 @@
switch (ret)
{
case 0: {
-   ReadStatus const ret_llf = loadThisLyXFile(autosaveFile);
+   ReadStatus const ret_llf = loadThisLyXFile(autosaveFile, fn);
// the file is not saved if we load the autosave file.
if (ret_llf == ReadSuccess) {
markDirty();
@@ -3739,13 +3739,19 @@
if (ret_ra == ReadSuccess || ret_ra == ReadCancel)
return ret_ra;
 
-   return loadThisLyXFile(fn);
+   return loadThisLyXFile(fn, FileName());
 }
 
 
+Buffer::ReadStatus Buffer::loadThisLyXFile(FileName const & fn, FileName const 
& on)
+{
+   return readFile(fn, on);
+}
+
+
 Buffer::ReadStatus Buffer::loadThisLyXFile(FileName const & fn)
 {
-   return readFile(fn);
+   return readFile(fn, FileName());
 }
 
 

Re: #7008: longtable dialog regression

[Abdelrazak Younes]

On 11/02/2010 12:11 AM, LyX Ticket Tracker wrote:

#7008: longtable dialog regression
---+
  Reporter:  uwestoehr  |   Owner:  poenitz
  Type:  defect |  Status:  new
  Priority:  high   |   Milestone:  2.0.0
Component:  tabular| Version:  2.0.0svn
  Severity:  normal |Keywords:  regression
---+
  During the table dialog overhaul the following regression has been
  introduced:

  A header/footer can only be set as "no content" if there is a
  header/footer line but no firstheader/lastfooter line

  The old code respected this and checked in GuiTabular::updateContents()
  for this for lastfooterStatusCB.

  The new code doesn't check for this in GuiTabular::checkEnabled().

  The fix for this should be easy: replace
  lastfooterNoContentsCB->setEnabled(longtabular);
  with
  lastfooterNoContentsCB->setEnabled(longtabular&&  tabular.haveLTFoot()&&
  !tabular.haveLTLastFoot());
  in GuiTabular::checkEnabled()

  I failed to do this because I don't know how to call Tabular::haveLTFoot()
  in GuiTabular::checkEnabled().
   


The correct fix is not so easy but an easy fix would be to cache the 
value that we need in a ne boolean member that we set in paramsToDialog():


d->give_it_a_correct_name_ = tabular.haveLTFoot() && 
!tabular.haveLTLastFoot());


Abdel.

Re: Beta (status update #3)

[Vincent van Ravesteijn]

>  After my last commit in readFile() it's "only" the issue with 
file_found_hook being called with the wrong file name in case of autosave and emergency.
>  I'd like to fix it before (2) or maybe Vincent does it...
>  For users of VCS I'd rate it as a serious problem - but not critical.

To illustrate my plan I post a patch - it's compiling and I tested it quickly.
I hope that's acceptable. Vincent? Do you have a better proposal?

Stephan




/// emergency or autosave files, one should use \c loadLyXFile.
/// /sa loadLyXFile
ReadStatus loadThisLyXFile(support::FileName const&  fn);
+   ReadStatus loadThisLyXFile(support::FileName const&  fn, support::FileName 
const&  on);
/// read a new document from a string
bool readString(std::string const&);
/// Reloads the LyX file



I don't like this. Adding another parameter to a public function, which you 
wouldn't expect at all. Buffer only knows about autosave/emergency/backup 
files. loadThisLyXFile was supposed not to do anything with emergency/autosave 
files at all, so it is strange that it needs some extra parameter.


Let me think how to solve it properly.

Vincent

Commit logs

[Vincent van Ravesteijn]

Log:
first step to cure the VCS load problem

Log:
Partially fix #5108.
Log:
Fix bug #6997



Can I please remind you and ask you to write meaningful commit-logs. 
Logs explaining why the change has been made, why the new design or 
solution or implementation is better, what problem it fixed, why other 
solutions might be wrong although it may seem not to be at first sight 
and so forth.


I don't want to have to look into a bug to even know what the bug is 
about, so I always like at least to add a summary of the bug to the 
commit log. Furthermore, the fix might need some explanation.


In the example of the VCS load problem, please explain what the VCS load 
problem is. Please explain why it is only a first step, and what still 
needs to be done.


Thank you.

Vincent

Re: Beta (status update #3)

[Stephan Witt]

Am 02.11.2010 um 10:22 schrieb Vincent van Ravesteijn:

>  
>> > 
>> After my last commit in readFile() it's "only" the issue with 
>> file_found_hook being called with the wrong file name in case of autosave 
>> and emergency.
>> 
>> > 
>> I'd like to fix it before (2) or maybe Vincent does it...
>> 
>> > 
>> For users of VCS I'd rate it as a serious problem - but not critical.
>> 
> To illustrate my plan I post a patch - it's compiling and I tested it quickly.
> I hope that's acceptable. Vincent? Do you have a better proposal?
> 
> Stephan
> 
> 
> 
> > /// emergency or autosave files, one should use \c loadLyXFile.
> > /// /sa loadLyXFile
> > ReadStatus loadThisLyXFile(support::FileName const & fn);
> >+ReadStatus loadThisLyXFile(support::FileName const & fn, 
> >support::FileName const & on);
> > /// read a new document from a string
> > bool readString(std::string const &);
> > /// Reloads the LyX file
> 
> 
> I don't like this. Adding another parameter to a public function, which you 
> wouldn't expect at all. Buffer only knows about autosave/emergency/backup 
> files. loadThisLyXFile was supposed not to do anything with 
> emergency/autosave files at all, so it is strange that it needs some extra 
> parameter.
> 
> 
> Let me think how to solve it properly.

No problem. Thanks.

Stephan

Re: Beta (status update #3)

[Vincent van Ravesteijn]

Yes. Ive got something. Wait

Op 1 nov 2010 14:21 schreef "Pavel Sanda" :

hi,

1. Richard, whats the status of a)? i'm basically waiting only for this.
could you give it top priority on your list if its not fixed yet?

2. Vincent could you put in the pending patch for b?

3. Gregory, you didn't replied to us. you have only very limited time frame
  to do so, otherwise things in 2.0 might by undesirable for you.



> short resume for things we need before releasing beta
> a) - Richard has some pending work on lyx2lyx which will finish some JMarc
work.
> b) - pending patch from Gregory Jefferis for CT, Vincent might have look
on it.
   (this is in progress, we wait for Gregory's input)

> c) #6809 - converting to older LyX versions doesn't work under standard
conditions
>   (lesser importance)

c) would be nice to have, but i'm not going to stop release for it.

pavel

Re: Commit logs

[Stephan Witt]

Am 02.11.2010 um 10:29 schrieb Vincent van Ravesteijn:

> 
>> Log:
>> first step to cure the VCS load problem
> 
> Can I please remind you and ask you to write meaningful commit-logs. Logs 
> explaining why the change has been made, why the new design or solution or 
> implementation is better, what problem it fixed, why other solutions might be 
> wrong although it may seem not to be at first sight and so forth.
> 
> In the example of the VCS load problem, please explain what the VCS load 
> problem is. Please explain why it is only a first step, and what still needs 
> to be done.

The VCS load problem is (was) twofold:
1. the parser of the document needs the VCS state so this state (checked by 
file_found_hook) had to be done earlier.
=> first step, move it some lines up, above the readDocument() call.
2. in case of loading the autosave or emergency file the real file name has to 
be passed to file_found_hook.
=> the patch I posted does this. (I missed to diff src/buffer_funcs.cpp and - 
of course - I'd fix the comments). 

To defend my short commit-logs, I'm used to work with svn command line tool and 
the -m switch.
Changing that is not easy for me, but I can do so...

Stephan

Re: feature request: edit tex files

[Yann Disser]

On 1. Nov 2010, at 14:22, Jürgen Spitzmüller wrote:

> Yann Disser wrote:
>> Your arguments make sense. However, I think many people must have my
>> problem. Perhaps it would be sufficient to provide a way to keep the .lyx
>> file and the .tex file in sync. Whenever one of the two would get changed,
>> lyx would automatically import/export. This approach would then work for
>> all file formats for which there is an import and an export handler. It
>> would make my life dramatically easier when trying to collaborate via
>> svn/git/... 
>> 
>> Of course, the approach has limitations, like what to do, if both files get
>> modified at the same time. Also it does not deal with the preamble
>> problem. But I think, even ignoring these things (by asking the user which
>> file to take over), the feature would be incredibly helpful.
>> 
>> What do you think?
> 
> I agree it would be nice. But it's almost impossible. The problem is that 
> (La)TeX provides multiple ways (packages) for achieving the same thing. LyX 
> will never be able to support them all, so either your LaTeX collaborators 
> will needs to know what LyX supports (which is not what they will want to 
> know) or the LyX file will be cluttered with ERT. Also, some of the non-tex-
> relevant information will get lost on the way.
> 
> So, like Pavel already notes, if you collaborate intensely with LaTeX users, 
> using a LaTeX editor is probably much more adequate.
> 
> Jürgen

What would also already be very helpful would be the ability to export not the 
entire document, but only the part which is currently selected (we usually have 
one .tex file per chapter/section). At the moment I am doing this by 
copy-pasting from the source view to a text editor. But exporting individual 
parts, say sections/tables/etc..., might be very useful not only for me. And it 
should not be so difficult to implement, right? I am thinking about a checkbox 
in the export dialog à la "export selection only".

Yann

Re: #6871: Missing screen update can cause assertion after lyxserver communication

[Abdelrazak Younes]

On 11/02/2010 12:31 PM, LyX Ticket Tracker wrote:

Comment(by sanda):

  >But you will still have a latent bug here.

  so this 'fix' is still not fixing the root cause, right?
   


Right.

vcs load problem

[Vincent van Ravesteijn]

first step to cure the VCS load problem

Can I please remind you and ask you to write meaningful commit-logs. Logs 
explaining why the change has been made, why the new design or solution or 
implementation is better, what problem it fixed, why other solutions might be 
wrong although it may seem not to be at first sight and so forth.

In the example of the VCS load problem, please explain what the VCS load 
problem is. Please explain why it is only a first step, and what still needs to 
be done.

The VCS load problem is (was) twofold:
1. the parser of the document needs the VCS state so this state (checked by 
file_found_hook) had to be done earlier.
=>  first step, move it some lines up, above the readDocument() call.


Why does the parser need to know the state ? If the state changes, do we 
then reparse the file too ? I think this stumbles on a other design 
problem.


If we have a file, we insert an InsetInfo about vcs, then we add the 
file to a vcs, will the InsetInfo be updated ? Apparently not, 
apparently the file is updated not until we parse the file again.


We probably need to have some call in updateBuffer or something that 
will update the InsetInfo's, and we call updateBuffer() probably 
somewhere after loading the file, so we don't need to register the vc 
status while reading the file.



2. in case of loading the autosave or emergency file the real file name has to 
be passed to file_found_hook.
=>  the patch I posted does this. (I missed to diff src/buffer_funcs.cpp and - 
of course - I'd fix the comments).


Well, I made two public functions of Buffer: loadLyXFile and 
loadThisLyXFile. The first one takes a filename, checks for 
autosave/emergency files, and when it is sure which file exactly it 
wants to read it calls loadThisLyXFile(). So, after this point, the code 
shouldn't be adapted to the fact that LyX is reading a different file as 
the user requested.


The name of the file is already stored in d->filename, so we can just 
call lyxvc.found_file_hook(d->filename). The only reason for readFile to 
have a FileName parameter is that we might want to load a 
recovery/emergency save file instead. This brings me to the conclusion 
that the FileName parameter to loadLyXFile and loadThisLyXFile is 
already WRONG!. We do not set d->filename when calling this file, so we 
have to make sure that we call loadLyXFile and loadThisLyXFile with 
exactly the same filename as the one we supplied when creating the 
buffer. If we rename the buffer we have to explicitly call 
Buffer::setFileName.


To conclude: instead of adding a second parameter to the load*LyXFIle 
functions, I think we should lose all parameters because we already have 
this information. The problem with lyxvc only revealed this bug. Thank 
you for finding the thinko that was present in the code. But please 
don't cure the symptom but criticisize and fix the (re)design.


Please correct me if I'm wrong. I'm just thinking aloud.

Vincent

Re: vcs load problem

[Stephan Witt]

Am 02.11.2010 um 12:34 schrieb Vincent van Ravesteijn:

> 
 first step to cure the VCS load problem
>>> Can I please remind you and ask you to write meaningful commit-logs. Logs 
>>> explaining why the change has been made, why the new design or solution or 
>>> implementation is better, what problem it fixed, why other solutions might 
>>> be wrong although it may seem not to be at first sight and so forth.
>>> 
>>> In the example of the VCS load problem, please explain what the VCS load 
>>> problem is. Please explain why it is only a first step, and what still 
>>> needs to be done.
>> The VCS load problem is (was) twofold:
>> 1. the parser of the document needs the VCS state so this state (checked by 
>> file_found_hook) had to be done earlier.
>> =>  first step, move it some lines up, above the readDocument() call.
> 
> Why does the parser need to know the state ? If the state changes, do we then 
> reparse the file too ?

Yes. The file is reloaded after VCS operations.

> I think this stumbles on a other design problem.
> 
> If we have a file, we insert an InsetInfo about vcs, then we add the file to 
> a vcs, will the InsetInfo be updated ? Apparently not, apparently the file is 
> updated not until we parse the file again.

See above.

> We probably need to have some call in updateBuffer or something that will 
> update the InsetInfo's, and we call updateBuffer() probably somewhere after 
> loading the file, so we don't need to register the vc status while reading 
> the file.

May be. My plan was to complete CVS backend implementation and the last changes 
did disturb it seriously. 
They where overdue but for my TODO list the worst time to happen. So, I where 
tempted to make the "hot fixes".

> 
>> 2. in case of loading the autosave or emergency file the real file name has 
>> to be passed to file_found_hook.
>> =>  the patch I posted does this. (I missed to diff src/buffer_funcs.cpp and 
>> - of course - I'd fix the comments).
> 
> Well, I made two public functions of Buffer: loadLyXFile and loadThisLyXFile. 
> The first one takes a filename, checks for autosave/emergency files, and when 
> it is sure which file exactly it wants to read it calls loadThisLyXFile(). 
> So, after this point, the code shouldn't be adapted to the fact that LyX is 
> reading a different file as the user requested.
> 
> The name of the file is already stored in d->filename, so we can just call 
> lyxvc.found_file_hook(d->filename). The only reason for readFile to have a 
> FileName parameter is that we might want to load a recovery/emergency save 
> file instead. This brings me to the conclusion that the FileName parameter to 
> loadLyXFile and loadThisLyXFile is already WRONG!.

I agree.

> We do not set d->filename when calling this file, so we have to make sure 
> that we call loadLyXFile and loadThisLyXFile with exactly the same filename 
> as the one we supplied when creating the buffer. If we rename the buffer we 
> have to explicitly call Buffer::setFileName.
> 
> To conclude: instead of adding a second parameter to the load*LyXFIle 
> functions, I think we should lose all parameters because we already have this 
> information. The problem with lyxvc only revealed this bug. Thank you for 
> finding the thinko that was present in the code.

Glad to hear this.

> But please don't cure the symptom but criticisize and fix the (re)design.

I did not have the time to follow your redesign of the buffer load operation 
closely.

> Please correct me if I'm wrong. I'm just thinking aloud.

But you cannot test it easily? I'll test your proposal...

Stephan

Re: Commit logs

[Vincent van Ravesteijn]

Log: first step to cure the VCS load problem

Can I please remind you and ask you to write meaningful commit-logs. Logs 
explaining why the change has been made, why the new design or solution or 
implementation is better, what problem it fixed, why other solutions might be 
wrong although it may seem not to be at first sight and so forth.

In the example of the VCS load problem, please explain what the VCS load 
problem is. Please explain why it is only a first step, and what still needs to 
be done.

To defend my short commit-logs, I'm used to work with svn command line tool and 
the -m switch.
Changing that is not easy for me, but I can do so...


Well, let's have a look at this example. Considering the actually change 
you made, you could have written:

- "InsetInfo needs the vcs status during parsing"

This is as short as the commit now, but it helps us to reveal the thinko 
I made. You already thought about why the InsetInfo was broken for VCS, 
you found out that it was caused by the fact that I put the call after 
the parse and you corrected it. Please share that info with the others.


After your commit, I now have to look back to the thread what the load 
problem consisted of, then I have to assume that this solves the 
InsetInfo problem, then I have to think for myself why this would fix a 
problem with InsetInfo, and then I find out that it's a wrong design 
that leads to this bug.


I would even go further. If you explicitly note this fact, you can ask 
yourself why I made this error. Probably because I did not know there is 
this design flaw and probably another developer later won't know this 
either. So, it would be good to add a comment to this line saying that 
this line has to be there before the call to parseDocument().


Oh wait, there is already a comment saying that InsetInfo needs it, but 
still I did it wrong. Apparently it was not clear enough to me that 
InsetInfo needs it during the parse process (because it's wrong). So, 
you could update this comment to indicate this fact, because apparently 
either the comment was not clear, or I can't read properly.


I don't want to sound a bit scholarly, I just want to share my ideas to 
improve collaboration, to improve the code design and to help each other 
in order to reach that goal.


Especially in such an opensource project, we need to check upon each 
other. A lot of us are amateur programmers, we do not work with LyX Code 
for 40 hours a week, there is noone who checks the commits as part of 
his job. We have to look at the commits in our free/spare time, so 
please make it as easy for the other developers to check what you did, 
why you did it, what it fixed and so forth.


By the way, I am happy you are doing so much work lately.

Vincent

Re: vcs load problem

[Vincent van Ravesteijn]

The VCS load problem is (was) twofold: 1. the parser of the document needs the 
VCS state so this state (checked by file_found_hook) had to be done earlier.
=>   first step, move it some lines up, above the readDocument() call.

Why does the parser need to know the state ? If the state changes, do we then 
reparse the file too ?

Yes. The file is reloaded after VCS operations.


But I'm pretty sure it's not documented there either that if the status 
changes, that we need to reload the file because of InsetInfo depending 
on this ;).



We probably need to have some call in updateBuffer or something that will 
update the InsetInfo's, and we call updateBuffer() probably somewhere after 
loading the file, so we don't need to register the vc status while reading the 
file.

May be. My plan was to complete CVS backend implementation and the last changes 
did disturb it seriously.


I'm sorry.


They where overdue but for my TODO list the worst time to happen. So, I where tempted to 
make the "hot fixes".



I don't criticize your hot fixes. I'm happy you found and diagnosed the 
problem.


But I think you understand that if you're correcting my commits and the 
refactoring I did, I'm eager to check whether it was a stupid mistake I 
made, whether my design was wrong, or if there is a higher order problem.





Please correct me if I'm wrong. I'm just thinking aloud.

But you cannot test it easily? I'll test your proposal...


No, I'm in a conference. Not the ideal atmosphere to update, redesign, 
refactor, code, compile, test, mail, and commit. So I stick to the 
mailing part for now :D.


Vincent

Re: vcs load problem

[Stephan Witt]

Am 02.11.2010 um 12:51 schrieb Stephan Witt:

> Am 02.11.2010 um 12:34 schrieb Vincent van Ravesteijn:
> 
>> 
> first step to cure the VCS load problem
 Can I please remind you and ask you to write meaningful commit-logs. Logs 
 explaining why the change has been made, why the new design or solution or 
 implementation is better, what problem it fixed, why other solutions might 
 be wrong although it may seem not to be at first sight and so forth.
 
 In the example of the VCS load problem, please explain what the VCS load 
 problem is. Please explain why it is only a first step, and what still 
 needs to be done.
>>> The VCS load problem is (was) twofold:
>>> 1. the parser of the document needs the VCS state so this state (checked by 
>>> file_found_hook) had to be done earlier.
>>> =>  first step, move it some lines up, above the readDocument() call.
>> 
>> Why does the parser need to know the state ? If the state changes, do we 
>> then reparse the file too ?
> 
> Yes. The file is reloaded after VCS operations.
> 
>> I think this stumbles on a other design problem.
>> 
>> If we have a file, we insert an InsetInfo about vcs, then we add the file to 
>> a vcs, will the InsetInfo be updated ? Apparently not, apparently the file 
>> is updated not until we parse the file again.
> 
> See above.
> 
>> We probably need to have some call in updateBuffer or something that will 
>> update the InsetInfo's, and we call updateBuffer() probably somewhere after 
>> loading the file, so we don't need to register the vc status while reading 
>> the file.
> 
> May be. My plan was to complete CVS backend implementation and the last 
> changes did disturb it seriously. 
> They where overdue but for my TODO list the worst time to happen. So, I where 
> tempted to make the "hot fixes".
> 
>> 
>>> 2. in case of loading the autosave or emergency file the real file name has 
>>> to be passed to file_found_hook.
>>> =>  the patch I posted does this. (I missed to diff src/buffer_funcs.cpp 
>>> and - of course - I'd fix the comments).
>> 
>> Well, I made two public functions of Buffer: loadLyXFile and 
>> loadThisLyXFile. The first one takes a filename, checks for 
>> autosave/emergency files, and when it is sure which file exactly it wants to 
>> read it calls loadThisLyXFile(). So, after this point, the code shouldn't be 
>> adapted to the fact that LyX is reading a different file as the user 
>> requested.
>> 
>> The name of the file is already stored in d->filename, so we can just call 
>> lyxvc.found_file_hook(d->filename). The only reason for readFile to have a 
>> FileName parameter is that we might want to load a recovery/emergency save 
>> file instead. This brings me to the conclusion that the FileName parameter 
>> to loadLyXFile and loadThisLyXFile is already WRONG!.
> 
> I agree.
> 
>> We do not set d->filename when calling this file, so we have to make sure 
>> that we call loadLyXFile and loadThisLyXFile with exactly the same filename 
>> as the one we supplied when creating the buffer. If we rename the buffer we 
>> have to explicitly call Buffer::setFileName.
>> 
>> To conclude: instead of adding a second parameter to the load*LyXFIle 
>> functions, I think we should lose all parameters because we already have 
>> this information. The problem with lyxvc only revealed this bug. Thank you 
>> for finding the thinko that was present in the code.
> 
> Glad to hear this.
> 
>> But please don't cure the symptom but criticisize and fix the (re)design.
> 
> I did not have the time to follow your redesign of the buffer load operation 
> closely.
> 
>> Please correct me if I'm wrong. I'm just thinking aloud.
> 
> But you cannot test it easily? I'll test your proposal...

The attached patch works.

Stephan

PS. Thank you for the lecture in other mail - (no sarcasm).
My problem is I spend to much time for LyX already. That's why I feel in a 
hurry and make mistakes.
Like "solving" a problem by curing the symptom.

Index: src/Buffer.cpp
===
--- src/Buffer.cpp  (Revision 35992)
+++ src/Buffer.cpp  (Arbeitskopie)
@@ -876,7 +876,7 @@
}
 
// InsetInfo needs to know if file is under VCS
-   lyxvc().file_found_hook(fn);
+   lyxvc().file_found_hook(d->filename);
 
if (readDocument(lex)) {
Alert::error(_("Document format failure"),
@@ -3651,7 +3651,6 @@
bool const success = (ret_llf == ReadSuccess);
if (success) {
markDirty();
-   lyxvc().file_found_hook(fn);
str = _("Document was successfully recovered.");
} else
str = _("Document was NOT successfully recovered.");
@@ -3707,7 +3706,6 @@
// the file is not saved if we load the autosave file.
if (ret_llf == ReadSuccess) {
markDirty();
-

Re: vcs load problem

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> Why does the parser need to know the state ? If the state changes, do we 
> then reparse the file too ? I think this stumbles on a other design 
> problem.
>
> If we have a file, we insert an InsetInfo about vcs, then we add the file 
> to a vcs, will the InsetInfo be updated ? Apparently not, apparently the 
> file is updated not until we parse the file again.
>
> We probably need to have some call in updateBuffer or something that will 
> update the InsetInfo's, and we call updateBuffer() probably somewhere after 
> loading the file, so we don't need to register the vc status while reading 
> the file.

its a design problem and i asked about the solution several times on the list ;)
the problem is that getting up-to-date info needs launching external
programs like "svn info" and doing it as a part of updateBuffer is
not wise way to do it. we use currently caching inside lyxvc which knows
when its the time to refresh time better then code in updateBuffer would.

pavel

Re: vcs load problem

[Pavel Sanda]

Stephan Witt wrote:
> 
> The attached patch works.

i'm happy the other occurences disappeared...
pavel

Re: vcs load problem

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> If we have a file, we insert an InsetInfo about vcs, then we add the file 
> to a vcs, will the InsetInfo be updated ? Apparently not, apparently the 
> file is updated not until we parse the file again.

it will be updated, when you add file to vcs, its reloaded.

pavel

Re: vcs load problem

[Stephan Witt]

Am 02.11.2010 um 13:06 schrieb Vincent van Ravesteijn:

> 
 The VCS load problem is (was) twofold: 1. the parser of the document needs 
 the VCS state so this state (checked by file_found_hook) had to be done 
 earlier.
 =>   first step, move it some lines up, above the readDocument() call.
>>> Why does the parser need to know the state ? If the state changes, do we 
>>> then reparse the file too ?
>> Yes. The file is reloaded after VCS operations.
> 
> But I'm pretty sure it's not documented there either that if the status 
> changes, that we need to reload the file because of InsetInfo depending on 
> this ;).

It's not only the InsetInfo.
The file locking state, writable/readonly state, contents, buffer headers... to 
mention only the things I can recall quickly.
It's not that bad, to reload the file after VCS operations.

>>> We probably need to have some call in updateBuffer or something that will 
>>> update the InsetInfo's, and we call updateBuffer() probably somewhere after 
>>> loading the file, so we don't need to register the vc status while reading 
>>> the file.
>> May be. My plan was to complete CVS backend implementation and the last 
>> changes did disturb it seriously.
> 
> I'm sorry.

As I said, you did a good move.

>> They where overdue but for my TODO list the worst time to happen. So, I 
>> where tempted to make the "hot fixes".
> 
> I don't criticize your hot fixes. I'm happy you found and diagnosed the 
> problem.
> 
> But I think you understand that if you're correcting my commits and the 
> refactoring I did, I'm eager to check whether it was a stupid mistake I made, 
> whether my design was wrong, or if there is a higher order problem.

I understand. And it is better to correct the situation with your careful 
review.

> No, I'm in a conference. Not the ideal atmosphere to update, redesign, 
> refactor, code, compile, test, mail, and commit.

:-)

Stephan

Re: Beta (status update #3)

[Pavel Sanda]

Stephan Witt wrote:
> > if you have the patch already feel free to post it, but...
> 
> I'll attach it - so you get the idea.
> 
> I want to
> 1) catch the output of failing system calls to display them in error message 
> dialog
> 2) eventually be able to pass it up to caller for parsing it
> 3) simplify the tmpfile handling

all these are reasonable goals, but i'm convinced that together with SystemCall 
touches belong to the 2.1 devel cycle. its already beyond the threshold, all 
those
OpMode, getDiff and so on should have been used similarly on all vcs backends.
not having time to digg into the matter i didn't want to frustrate you even more
so kept silence in last vc-stuff threads, but we have to draw line somewhere.

trunk destabilized last days and i want to freeze it for any other devel than 
just
bugfixing asap.

pavel

Re: Beta (status update #3)

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> Yes. Ive got something. Wait

can you share your timetable?
pavel

Re: r35970 - lyx-devel/trunk/src/frontends/qt4

[Vincent van Ravesteijn]

Author: rgheck
Date: Mon Nov  1 20:37:59 2010
New Revision: 35970
URL: http://www.lyx.org/trac/changeset/35970

Log:
Fix bug #7002. I think this is correct, but Peter should check.

May I, may I ?


func_ = f;
-   callInGuiThread();
+   if (theApp() == 0)
+   synchronousFunctionCall();
+   else
+   callInGuiThread();
}


Why not doing this check in callInGuiThread(). There already is made a 
decision whether to call it in a new thread or not:


void IntoGuiThreadMover::callInGuiThread()
{
QThread* gui_thread = QApplication::instance()->thread();
if (QThread::currentThread() == gui_thread) {
// do synchronous thing
else
// do threaded thing
}

Isn't it as simple to change this to something like:

QApplication * app = QApplication::instance();
if (!app || QThread()::currentThread() = app->thread())
// do synchronous thing
else
// do threaded thing

Vincent

Re: r35970 - lyx-devel/trunk/src/frontends/qt4

[Vincent van Ravesteijn]

 Sorry, Peter already did this.

Vincent

Re: r35867 - in lyx-devel/trunk/src/frontends/qt4: . ui

[Jean-Marc Lasgouttes]

Le 01/11/2010 14:27, Pavel Sanda a écrit :

you...@lyx.org wrote:

Modified: lyx-devel/trunk/src/frontends/qt4/ui/HyperlinkUi.ui
==
--- lyx-devel/trunk/src/frontends/qt4/ui/HyperlinkUi.ui Wed Oct 27 14:55:57 
2010(r35866)
+++ lyx-devel/trunk/src/frontends/qt4/ui/HyperlinkUi.ui Wed Oct 27 19:02:42 
2010(r35867)
@@ -1,20 +1,18 @@
+


i see these lines are becoming part of our ui files more and more often.
is there anybody around to check it compiles with qt 4.2.2
which we claim to support?


Not me anymore.

JMarc

Re: feature request: edit tex files

[Jim Oldfield]

> 
> I agree it would be nice. But it's almost impossible. The problem is that 
> (La)TeX provides multiple ways (packages) for achieving the same thing. LyX 
> will never be able to support them all, so either your LaTeX collaborators 
> will needs to know what LyX supports (which is not what they will want to 
> know) or the LyX file will be cluttered with ERT. Also, some of the non-tex-
> relevant information will get lost on the way.
> 
> So, like Pavel already notes, if you collaborate intensely with LaTeX users, 
> using a LaTeX editor is probably much more adequate.
> 
> Jürgen


I think that most people who want collaboration with LaTeX people assume that 
the way to do this as by LyX editing LaTeX directly, and they pass this idea on 
to this list, where it is (quite rightly) rejected as infeasible. I know very 
little about the implementation of LyX, so I'm sorry to be presumptuous, but it 
seems to me that there's a design idea that hasn't been cosidered.   

Putting the LyX editing LaTeX idea diagrammatically we have (requires 
fixed-width font):

original.tex
|

| (edit in LyX)

v

updated.tex


My suggestion is:


original.tex --> original.lyx

|  / |

| /  | (edit in LyX)

vL   v

updated.tex  <-- updated.lyx


Note that in the final step, updated.tex is produced by assembling *all three* 
other files.  I would envisage such a program working by comparing the two .lyx 
files (presumably using LyX change tracking), then only exporting updates to 
.tex, and finally slotting them into the unaltered parts of original.tex.  I 
would imagine original.lyx would need internal references to original.tex to 
help determine where any updates would go.

This could potentially be a separate program, just as tex2lyx is (which 
incidentally is the top, rightward arrow in that diagram).

I think this would be much more realistic than getting LyX to edit LaTeX 
directly.  That does not make it easy in absolute terms though!  And it has 
downsides (such as it not really being possible to edit the preamble this way; 
I 
don't think that's a big deal though).  But I thought I should at least bring 
up 
the idea.

Jim


  

Re: r35995 - lyx-devel/trunk/src

[Pavel Sanda]

rgh...@lyx.org wrote:
> Author: rgheck
> Date: Tue Nov  2 15:50:07 2010
> New Revision: 35995
> URL: http://www.lyx.org/trac/changeset/35995
> 
> Log:
> Make sure that the members of this enum get the same value on every
> platform.

btw on which platform will this enum starts on non zero number?
pavel

Re: feature request: edit tex files

[Jean-Marc Lasgouttes]

Le 01/11/2010 14:16, Yann Disser a écrit :

Well, as I said, with automatic sync I do not think it would be so
much of a nightmare anymore. And, for me at least, editing
formula-heavy .tex is also not very enjoyable.


A typical example of when tex<->lyx breaks with formulas is when people
use ``helpful'' (or ``clever'') macros like
  \newcommand{\be}{\begin{equation}}
  \newcommand{\ee}{\end{equation}}

A single use of these and -- poof -- the structure of the document is 
dead. LyX would be supposed to output such horrors for the pleasure of 
being a nice cooperative tool?


The constructs are real-life ones, I am sure you saw them too. I give 
them as an example. Every LyX user trying to cooperate with some LaTeX 
user will eventually find such idiosyncrasies and complain that LyX is 
not correct for reversible translation.


Claiming that we try to do it is beginning to open pandora's box.

JMarc

Re: RefStyle Patch

[Jean-Pierre Chrétien]

Richard Heck a écrit :

On 10/31/2010 06:38 AM, Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien a écrit :



So do we have an extra \makeatletter somewhere?


Yes, exporting my example file in LaTeX reads:


\makeatletter

%% LyX specific LaTeX commands.

\AtBeginDocument{\providecommand\secref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\eqref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\lemref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\thmref[1]{\ref{#1}}}
\makeatletter
\...@ifundefined{thmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}
  {}
\...@ifundefined{lemref}
  {\def\RSlemtxt{lemma~}\newref{lem}{name = \RSlemtxt}}
  {}
\makeatother


%% Textclass specific LaTeX commands.
\theoremstyle{plain}




Currently refstyle cannot work natively with babel multilingual docs,
encapsulating strings definitions in \adddto\captions works, I've 
contacted Danie Els about this.



Is there something we can do in the meantime?


I got an anwer from Danie, I was mistaken about the multilingual feature of 
refstyle: it works all right (as \def commands are encapsulated in \extras 
commands) if refstyle is loaded *after* babel.


Is it possible to do this in LyX ?

In the meantime, I've found another point which the current patch misses:
part and chap are the prefixes in refstyle, so old refs are replaced by ?? if 
the "Use refstyle" box is checked.
I've added to convert_prettyref in lyx-2.0.py the code that you wrote last April 
and that I enhanced to convert all prefixes cha and par to chap and part.

I've added a step to deal with \newrefformat commands in the preamble.
Currently my re_newref string works as a command line in the pyton interpreter:


$ python
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re_newref = re.compile(r"\newrefformat\{(\w+)\}\{(\w+)")
>>> m=re_newref.match('\newrefformat{cha}{Chapitre~\ref{#1}}')
>>> print m.group(1)
cha
>>> print m.group(2)
Chapitre
>>>


but not in the convert_prettyref code (beware of the extra newlines added by my 
mailer, I've posted the corresponding patch on bug #6609 anyway):



  def convert_prettyref(document):
	" Converts prettyref references to neutral formatted refs, updates part and 
chapter prefixes "

re_ref = re.compile("^\s*reference\s+\"(\w+):(\S+)\"")
re_lab = re.compile("^\s*name\s+\"(\w+):(\S+)\"")
re_newref = re.compile(r"\newrefformat\{(\w+)\}\{(\w+)")
   # Note: step 1, \newrefformat part: and chap: susbtitutions for par: 
and cha:

i = 0
while True:
i = find_token(document.preamble, "\\newrefformat{", i)
result=document.preamble[i]
document.warning("Found document.preamble[i]" + result)
if i == -1:
break
m = re_newref.match(result)
if m:
prefix = m.group(1)
remain = m.group(2)
document.warning("Found " + prefix + " " + result)
if prefix == "cha":
prefix = "chap"
elif prefix == "par":
prefix = "part"
document.preamble[i] = "\\newrefformat" + "\{" + prefix + "\}" 
+ remain

i = i + 1
# Note: step 2, reference part: and chap: susbtitutions for par: 
and cha:

i = 0
while True:
i = find_token(document.body, "\\begin_inset CommandInset ref", i)
if i == -1:
break
j = find_end_of_inset(document.body, i)
if j == -1:
document.warning("Malformed LyX document: No end of InsetRef")
i += 1
continue
i += 1
k = find_token(document.body, "reference", i)
if k == -1 or k > j:
i = j + 1
continue
m = re_ref.match(document.body[k])
if m:
prefix = m.group(1)
suffix = m.group(2)
if prefix == "cha":
prefix = "chap"
elif prefix == "par":
prefix = "part"
document.body[k] = "reference" + " \"" + prefix + ":" + suffix 
+ "\""

i = j + 1
# Note: step 3, label  part: and chap: susbtitutions for par: and 
cha:
i = 0
while True:
i = find_token(document.body, "\\begin_inset CommandInset label", i)
if i == -1:
break
j = find_end_of_inset(document.body, i)
if j == -1:
document.warning("Malformed LyX document: No end of InsetRef")
i += 1
continue
i += 1
k = find_token(document.body, "name", i)
if k == -1 or k > j:
i = j + 1
continue
  

Re: r35995 - lyx-devel/trunk/src

[Richard Heck]

On 11/02/2010 10:53 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:
   

Author: rgheck
Date: Tue Nov  2 15:50:07 2010
New Revision: 35995
URL: http://www.lyx.org/trac/changeset/35995

Log:
Make sure that the members of this enum get the same value on every
platform.
 

btw on which platform will this enum starts on non zero number?

   

I don't know for sure. But the file Uwe posted with #7005 had:
\html_math_output -1
which was what was causing the problem. Since we are outputting the enum 
value in BufferParams::write(), I am guessing that VC++ is starting it 
on -1? The first value is the default, and it is properly set.


Richard

Abdel

[Abdelrazak Younes]

On 11/02/2010 04:29 PM, Richard Heck wrote:

On 11/02/2010 10:53 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:

Author: rgheck
Date: Tue Nov  2 15:50:07 2010
New Revision: 35995
URL: http://www.lyx.org/trac/changeset/35995

Log:
Make sure that the members of this enum get the same value on every
platform.

btw on which platform will this enum starts on non zero number?


I don't know for sure. But the file Uwe posted with #7005 had:
\html_math_output -1
which was what was causing the problem. Since we are outputting the 
enum value in BufferParams::write(), I am guessing that VC++ is 
starting it on -1? The first value is the default, and it is properly 
set.


I don't think so. I don't know for sure but think an enum is guaranted 
to start from zero on all platform by the standard (unless if set 
otherwise). But I am pretty sure this is the case also for VC++.


Abdel.

Re: Abdel

[Richard Heck]

On 11/02/2010 11:34 AM, Abdelrazak Younes wrote:

On 11/02/2010 04:29 PM, Richard Heck wrote:

On 11/02/2010 10:53 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:

Author: rgheck
Date: Tue Nov  2 15:50:07 2010
New Revision: 35995
URL: http://www.lyx.org/trac/changeset/35995

Log:
Make sure that the members of this enum get the same value on every
platform.

btw on which platform will this enum starts on non zero number?


I don't know for sure. But the file Uwe posted with #7005 had:
\html_math_output -1
which was what was causing the problem. Since we are outputting the 
enum value in BufferParams::write(), I am guessing that VC++ is 
starting it on -1? The first value is the default, and it is properly 
set.


I don't think so. I don't know for sure but think an enum is guaranted 
to start from zero on all platform by the standard (unless if set 
otherwise). But I am pretty sure this is the case also for VC++.


Well, it can't hurt to specify that it starts from 0. And I'm not sure 
how Uwe could otherwise have gotten the line with -1.


rh

Re: Abdel

[Abdelrazak Younes]

On 11/02/2010 04:35 PM, Richard Heck wrote:

On 11/02/2010 11:34 AM, Abdelrazak Younes wrote:

On 11/02/2010 04:29 PM, Richard Heck wrote:

On 11/02/2010 10:53 AM, Pavel Sanda wrote:

rgh...@lyx.org wrote:

Author: rgheck
Date: Tue Nov  2 15:50:07 2010
New Revision: 35995
URL: http://www.lyx.org/trac/changeset/35995

Log:
Make sure that the members of this enum get the same value on every
platform.

btw on which platform will this enum starts on non zero number?


I don't know for sure. But the file Uwe posted with #7005 had:
\html_math_output -1
which was what was causing the problem. Since we are outputting the 
enum value in BufferParams::write(), I am guessing that VC++ is 
starting it on -1? The first value is the default, and it is 
properly set.


I don't think so. I don't know for sure but think an enum is 
guaranted to start from zero on all platform by the standard (unless 
if set otherwise). But I am pretty sure this is the case also for VC++.



Well, it can't hurt to specify that it starts from 0.


Sure. I even consider this good practice.


And I'm not sure how Uwe could otherwise have gotten the line with -1.


Don't know... But if this is tabular code that won't surprise me...

Abdel.

Re: r35995 - lyx-devel/trunk/src

[Pavel Sanda]

Richard Heck wrote:
>>> Log:
>>> Make sure that the members of this enum get the same value on every
>>> platform.
>>>  
>> btw on which platform will this enum starts on non zero number?
>>
>>
> I don't know for sure. But the file Uwe posted with #7005 had:
> \html_math_output -1
> which was what was causing the problem. Since we are outputting the enum 
> value in BufferParams::write(), I am guessing that VC++ is starting it on 
> -1? The first value is the default, and it is properly set.

i have hard time to believe this. isn't possible that this -1 code was
generated by some crazy code in lyx2lyx?

pavel