Re: Bug?
Am 29.10.2010 um 16:36 schrieb Richard Heck: On 10/29/2010 10:23 AM, Jürgen Spitzmüller wrote: Frederick Noronha wrote: Letterine is for creating drop caps. It works fine for me, EXCEPT when there is an inverted comma in the text such as I’d told you Sure, and I told you what the problem is and how to circumvent it. Use a straight ' instead of the ’, which does not seem to be covered by the encoding you use. Which is to say: If you really want to use that, then change the encoding. Or do as Jürgen said. :-) In ERT box: I'd told you gets I’d told you in output. Stephan
PATCH InfoInset
I've got a crash when place info-insert buffer vcs-date into CVS controlled
file.
The attached patch helps, but I'm not sure if there's some more elegant
solution.
Any opinions?
Stephan
Index: src/insets/InsetInfo.cpp
===
--- src/insets/InsetInfo.cpp(Revision 35929)
+++ src/insets/InsetInfo.cpp(Arbeitskopie)
@@ -437,9 +437,12 @@
else if (name_ == vcs-date)
itype = LyXVC::Date;
string binfo = buffer().lyxvc().revisionInfo(itype);
- if (binfo.empty())
- setText(bformat(_([[%1$s unknown]]),
from_utf8(name_)));
- else
+ if (binfo.empty()) {
+ docstring fmt = _([[%1$s unknown]]);
+ if (fmt.empty())
+ fmt = from_ascii([[%1$s unknown]]);
+ setText(bformat(fmt, from_utf8(name_)));
+ } else
setText(from_utf8(binfo));
break;
}
Re: PATCH InfoInset
Am 30.10.2010 um 15:59 schrieb Stephan Witt: I've got a crash when place info-insert buffer vcs-date into CVS controlled file. The attached patch helps, but I'm not sure if there's some more elegant solution. Any opinions? I rephrase my question... The crash is the ASSERT in bformat(). The translation of the format arg below results in an empty string. setText(bformat(_([[%1$s unknown]]), from_utf8(name_))); This code construct is quite common. I think, if the translation fails, the untranslated string is the result, isn't it? What's the problem here? Stephan
Re: PATCH InfoInset
Am 31.10.2010 um 10:11 schrieb Vincent van Ravesteijn: It is caused by the brackets. Wasn't this the way to indicate the context of a string? I think you now have an empty string in the context [[...]]. This is again translated as an empty string. Thanks, now I see. So it was a bad idea to change (r34187) setText(_(Unknown buffer info)); to setText(bformat(_([[%1$s unknown]]), from_utf8(name_))); setText(bformat(_(%1$s unknown[[BufferInfo]]), from_utf8(name_))); seems more correct then. Currently I'm a bit surprised that I cannot use the info dialog anymore. It crashes at line 217 of InsetCommandParams.cpp (LASSERT in default of switch missing the INFO_CODE case) What happens here? I guess the latest changes to the dialog code were not as trivial as one thought... Stephan Vincent Op 31 okt 2010 08:51 schreef Stephan Witt st.w...@gmx.net: Am 30.10.2010 um 15:59 schrieb Stephan Witt: I've got a crash when place info-insert buffer vcs-date into CVS controlled file. The attache... I rephrase my question... The crash is the ASSERT in bformat(). The translation of the format arg below results in an empty string. setText(bformat(_([[%1$s unknown]]), from_utf8(name_))); This code construct is quite common. I think, if the translation fails, the untranslated string is the result, isn't it? What's the problem here? Stephan
Re: [patch] support for multirow vertical offset
Am 31.10.2010 um 17:10 schrieb Uwe Stöhr: Am 31.10.2010 16:07, schrieb Jürgen Spitzmüller: The only issue I see right now is that one cannot set a multirow via the dialog What else do you see that is not yet also in LyX 1.6.x? Yes, but this issue is quite tricky. I'm not even sure it is solvable without a complete rewrite of the tabular UI- Inset communication (i.e., introduce InsetTabularParams). And it must be fixed for 2.0 of course. We need Abdel's help here. He has imlemented the new Apply/OK scheme and I'm sure he knows a solution. I mean it works for setting multicolumns so it should work also for multirows using the same tabular UI - Inset communication. Abdel? I had just a first deeper look into the current tabular code during the recent days (where I fixed some issues), and I observed that the new stuff (e.g. the mutlirow code) was not integrated properly in many respects. I really like to have this cleaned up and working before adding even more complexity to the code. I currently see only the problem mentioned above now: http://wiki.lyx.org/Devel/Multirow I think my patch doesn't increase the complexity a lot -- the edit field is only used when a cell is multirow. Have you tested my patch? Maybe I have overseen something and if you find a bug or regression. Then I will of course agree with you it is better to postpone. (Without testing it is like judging a book by its cover ;-) ) Same critics come usually from the users. As it was my idea to support multirow I'm responsible for that mistake and therefore want to fix this missing part of the implementation. Putting this not in right now would mean that users have to wait another year at least until multirows are really usable without TeX-code. Can it therefore go in? I think I tested the patch carefully and it is moreover rather straight forward. As said, I would prefer to get the tabular dialog in shape before adding new stuff. But this is just my personal opinion of course. OK, lets wait for additional opinions. I can understand both of you. You want to get your patch in and the new features added. And Jürgen wants to consolidate code and behavior. But I've to admit, I agree more with Jürgen. Currently I cannot work on the buffer-info of VCS anymore because the InsetInfo dialog doesn't work anymore because of the ASSERTs. I didn't test the tabular dialogs lately - and I didn't test your patch - but one cannot move on before the current state is not fixed. The support for multi-row cells would be nice. But if it conflicts with the LyX release plans you should wait with the discussion until Pavel is back. Stephan
Re: PATCH InfoInset
Am 31.10.2010 um 20:10 schrieb Richard Heck: On 10/31/2010 11:10 AM, Stephan Witt wrote: Currently I'm a bit surprised that I cannot use the info dialog anymore. It crashes at line 217 of InsetCommandParams.cpp (LASSERT in default of switch missing the INFO_CODE case) What happens here? I guess the latest changes to the dialog code were not as trivial as one thought... Found the cause of this one After your change (r35952) LyX doesn't link anymore. Did you forget any part of your change set? Stephan
Re: Unicode help
Am 01.11.2010 um 05:25 schrieb Daron Wilson: Hi all. I've recently started using LyX, and I've downloaded the 2.0 alpha 6 version used with Mac OS X. I have only one issue so far, and that concerns the use of Unicode, in particular polytonic Greek (entered using the Polytonic Greek keyboard layout supplied by Apple). I'm relatively new to Unicode, so I apologize upfront if my terminology or understanding of how it works is a little off. Whenever I input a Greek character with any kind of combining accent, the correct combination is entered, but LyX repeats the vowel, minus the accents. For example, trying to input circumflex-upsilon always results in circumflex-upsilon upsilon: ῦ always turns into ῦυ. The same thing happens for any letter combined with accent marks. The problem does not happen in any of the other document editing programs on my Mac, so I'm assuming this is something within LyX itself. You're right. More exactly it's within a library framework the LyX package contains - the Qt library, responsible for display I/O of LyX. It's a known problem. You may find a discussion of that here: http://www.lyx.org/trac/ticket/6706 I have wondered if this has something to do with some kind of automatic-replacement feature in LyX, but I don't know enough to figure it out. Thanks in advance for any solutions or pointers in the right direction. The solution is to fix the problem in the Qt-libraries. I think it will be fixed with the next LyX package (hopefully beta1). Stephan
Re: r35960 - lyx-devel/trunk/src/insets
Am 01.11.2010 um 07:41 schrieb Vincent van Ravesteijn:
+ if (binfo.empty()) {
+ docstring fmt = _(%1$s unknown[[InsetNote]]);
+ setText(bformat(fmt, from_utf8(name_)));
+ } else
InsetNote ?
Sorry. Should be InsetInfo. I mixed it up while trying to fix the
latest compile problems, I'll correct that.
Please remember that this should be helpful for the translators to
correctly translate the unknown part.
And I have no clue what should be unknown here :S..
(The value of the vcs buffer-info inset indexed by name is empty.
The replacement in this case is e. g. vcs-author unknown.
The translator has to translate the word unknown.)
I had to lookup your smiley in some smiley table manually ;-)
I don't know how to be more helpful to the translator.
Stephan
buffer read and vcs info inset
In the current state of buffer read the vcs info inset output is broken.
The attached patch helps. Ok to apply?
But, there is one problem left.
When reading the autosave or emergency file the wrong pathname is passed to
lyxvc().file_found_hook().
That's why the additional calls I introduced in r35937. But it's too late for
info inset when called after readFile().
The real pathname should be restored and passed in readFile(). Has someone a
better proposal?
Stephan
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (Revision 35961)
+++ src/Buffer.cpp (Arbeitskopie)
@@ -875,6 +875,9 @@
return readFile(tmpFile);
}
+ // InsetInfo needs to know if file is under VCS
+ lyxvc().file_found_hook(fn);
+
if (readDocument(lex)) {
Alert::error(_(Document format failure),
bformat(_(%1$s ended unexpectedly, which means
@@ -884,8 +887,6 @@
}
d-file_fully_loaded = true;
- // InsetInfo needs to know if file is under VCS
- lyxvc().file_found_hook(fn);
d-read_only = !fname.isWritable();
params().compressed = fname.isZippedFile();
saveCheckSum();
Re: r35960 - lyx-devel/trunk/src/insets
Am 01.11.2010 um 11:07 schrieb Kornel Benko:
Am Montag, 1. November 2010 schrieb Stephan Witt:
Am 01.11.2010 um 07:41 schrieb Vincent van Ravesteijn:
+ if (binfo.empty()) {
+ docstring fmt = _(%1$s unknown[[InsetNote]]);
+ setText(bformat(fmt, from_utf8(name_)));
+ } else
InsetNote ?
Sorry. Should be InsetInfo. I mixed it up while trying to fix the
latest compile problems, I'll correct that.
Please remember that this should be helpful for the translators to
correctly translate the unknown part.
And I have no clue what should be unknown here :S..
(The value of the vcs buffer-info inset indexed by name is empty.
The replacement in this case is e. g. vcs-author unknown.
The translator has to translate the word unknown.)
I had to lookup your smiley in some smiley table manually ;-)
I don't know how to be more helpful to the translator.
For instance %1$s unknown[[vcs-author]]
as that gives a hint to author. In some languages unknown depends also on
gender of vcs-author
vcs-author is on case out of:
* vcs-revision
* vcs-tree-revision
* vcs-author
* vcs-date
* vcs-time
These strings will substitute %1$s in front of the word unknown.
In case of translations depending on gender one has to think of e. g. keyword
unknown.
But as I understand gettext that's not the aim of the context. It's used to make
multiple translations for the same string depending of the context in interface.
We may abuse it and make the context dynamic:
docstring fmt = _(%1$s unknown[[ + name_ + ]]);
setText(bformat(fmt, from_utf8(name_)));
But that would not work without some N_() magic and then the translator has to
provide 5 translations.
Looks like overkill.
Stephan
Re: r35960 - lyx-devel/trunk/src/insets
Am 01.11.2010 um 15:21 schrieb Kornel Benko:
Am Montag 01 November 2010 schrieb Stephan Witt:
Am 01.11.2010 um 11:07 schrieb Kornel Benko:
Am Montag, 1. November 2010 schrieb Stephan Witt:
Am 01.11.2010 um 07:41 schrieb Vincent van Ravesteijn:
+ if (binfo.empty()) {
+ docstring fmt = _(%1$s
unknown[[InsetNote]]); + setText(bformat(fmt,
from_utf8(name_))); + } else
InsetNote ?
Sorry. Should be InsetInfo. I mixed it up while trying to fix the
latest compile problems, I'll correct that.
Please remember that this should be helpful for the translators to
correctly translate the unknown part.
And I have no clue what should be unknown here :S..
(The value of the vcs buffer-info inset indexed by name is empty.
The replacement in this case is e. g. vcs-author unknown.
The translator has to translate the word unknown.)
I had to lookup your smiley in some smiley table manually ;-)
I don't know how to be more helpful to the translator.
For instance %1$s unknown[[vcs-author]]
as that gives a hint to author. In some languages unknown depends also
on gender of vcs-author
vcs-author is on case out of:
* vcs-revision
* vcs-tree-revision
* vcs-author
* vcs-date
* vcs-time
These strings will substitute %1$s in front of the word unknown.
In case of translations depending on gender one has to think of e. g.
keyword unknown. But as I understand gettext that's not the aim of the
context. It's used to make multiple translations for the same string
depending of the context in interface. We may abuse it and make the
context dynamic:
docstring fmt = _(%1$s unknown[[ + name_ + ]]);
setText(bformat(fmt, from_utf8(name_)));
But that would not work without some N_() magic and then the translator has
to provide 5 translations.
Looks like overkill.
Yes, but then why not the full sentence?
docstring fmt = _(vcs-revision unknown)
We need to know what is unknown to translate the sentence corectly anyway.
There is no sentence to translate.
Remember that I didn't invent that string stuff.
I fixed a crash (ASSERT when doing the documented info-insert buffer vcs-date
in an CVS controlled LyX document) and now I have the feeling that it's harder
to get that string change through as to reorganize the whole inset dialog
hierarchy.
I can do what you propose... but I don't like it.
Stephan
Re: PATCH InfoInset
Am 01.11.2010 um 15:34 schrieb Pavel Sanda: Stephan Witt wrote: setText(_(Unknown buffer info)); to setText(bformat(_([[%1$s unknown]]), from_utf8(name_))); setText(bformat(_(%1$s unknown[[BufferInfo]]), from_utf8(name_))); seems more correct then. why to put [[BufferInfo]] there? I don't know. I didn't introduce the [[..]] construct. Stephan
Re: r35937 - lyx-devel/trunk/src
Am 01.11.2010 um 15:49 schrieb Pavel Sanda: sw...@lyx.org wrote: Author: switt Date: Sat Oct 30 22:05:55 2010 New Revision: 35937 URL: http://www.lyx.org/trac/changeset/35937 Log: after successfuly load of autosave or emergency file the VCS state has to be checked for the original name i find disseminating of file_found_hook in various places of buffer routines bad idea. Me too. it used to be in one place and would be cool if it remains so. Stephan could you please have look whether its possible to push it at one place in the load hierarchy? I did it already (having a look :-)). The resulting question was not answered until now. See the mail with subject buffer read and vcs info inset. I'd code the invers operation for getEmergencyFileNameFor() and getAutosaveFileNameFor(). Then I'd use the result in readFile() to pass to file_found_hook(). The other possibility I can see is to pass the original filename as optional argument. What should I do? Stephan
Re: PATCH InfoInset
Am 01.11.2010 um 15:58 schrieb Pavel Sanda: Stephan Witt wrote: Stephan Witt wrote: setText(_(Unknown buffer info)); to setText(bformat(_([[%1$s unknown]]), from_utf8(name_))); setText(bformat(_(%1$s unknown[[BufferInfo]]), from_utf8(name_))); seems more correct then. why to put [[BufferInfo]] there? I don't know. I didn't introduce the [[..]] construct. okok :) please kill it, its only for specific translating needs. I did it. Hopefully you see it like me... ...the from_utf8 can safely be replaced by from_ascii. So I did that too. Stephan
Re: r35960 - lyx-devel/trunk/src/insets
Am 01.11.2010 um 16:18 schrieb Pavel Sanda:
Kornel Benko wrote:
Well, this is exactly the case here, as %1$s may have different gender in
slovak for
values like vcs-revision and vcs-author. And I am acting as some
translator here too.
i understand, but inventing some machinery for this corner case is really
overkill.
The nicest solution could be the attached patch.
But as said already that requires the translators to translate 5 strings...
(I'd also say that it's overkill.)
Stephan
Index: src/insets/InsetInfo.cpp
===
--- src/insets/InsetInfo.cpp(Revision 35965)
+++ src/insets/InsetInfo.cpp(Arbeitskopie)
@@ -426,21 +426,25 @@
break;
}
LyXVC::RevisionInfo itype = LyXVC::Unknown;
- if (name_ == vcs-revision)
+ docstring emsg = _(buffer-info name unknown);
+ if (name_ == vcs-revision) {
itype = LyXVC::File;
- else if (name_ == vcs-tree-revision)
+ emsg = _(vcs-revision not available);
+ } else if (name_ == vcs-tree-revision) {
itype = LyXVC::Tree;
- else if (name_ == vcs-author)
+ emsg = _(vcs-tree-revision not available);
+ } else if (name_ == vcs-author) {
itype = LyXVC::Author;
- else if (name_ == vcs-time)
+ emsg = _(vcs-author not available);
+ } else if (name_ == vcs-time) {
itype = LyXVC::Time;
- else if (name_ == vcs-date)
+ emsg = _(vcs-time not available);
+ } else if (name_ == vcs-date) {
itype = LyXVC::Date;
+ emsg = _(vcs-date not available);
+ }
string binfo = buffer().lyxvc().revisionInfo(itype);
- if (binfo.empty())
- setText(bformat(_(%1$s unknown), from_ascii(name_)));
- else
- setText(from_utf8(binfo));
+ setText(binfo.empty() ? emsg : from_utf8(binfo));
break;
}
case LYX_INFO:
Re: Beta (status update #3)
Am 01.11.2010 um 16:48 schrieb Pavel Sanda: Richard Heck wrote: 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? Will do. great. anybody around having something more to be push in before beta? from then i would like to freeze enhacements (maybe except small nonintrusive changes which we will decide case by case) and _mainly_ any kind of refactorization which is not part of fixing some particular bug. 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. 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. Stephan
Re: Beta (status update #3)
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()));
+ connect
Re: Beta (status update #3)
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: Beta (status update #3)
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: Commit logs
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: vcs load problem
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: vcs load problem
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
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)
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: Beta (status update #3)
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)
Am 03.11.2010 um 01:05 schrieb 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? I said this to explain why the resulting code change was so big. The problem with the error messages lead me to the status check implementation. Now it is in place I think it's much better with it then without it. I'd say it should not be dropped. Please, ask your questions you have regarding CvsStatus and I'll explain. Should I add comments? I'll do that anyway. BTW, did you follow my change to the manual Additional.lyx? Is it ok? Stephan
Re: Beta (status update #3)
Am 03.11.2010 um 12:21 schrieb Pavel Sanda: Stephan Witt wrote: The problem with the error messages lead me to the status check implementation. Now it is in place I think it's much better with it then without it. I'd say it should not be dropped. Please, ask your questions you have regarding CvsStatus and I'll explain. the darkest thing was how/when are states supposed to switch from one to another. The status switch is not done by LyX. It happens by using cvs commands or saving changes of the document. It's only queried to make a qualified decision what to ask the user or what operation to deny. E. g. You have a modified checkout cvs states Locally modified. If another user commits his change cvs states Needs Merge. If your checkout is clean instead it says Needs Checkout. you can always guess something from code, but in case you make bug it would be hard job for anyone else to guess what was the intention. So adding more comments would help... BTW, did you follow my change to the manual Additional.lyx? Is it ok? yes, i quickly came through it few days ago to make clear idea how are the reserved checkouts related to locking in other backends. since i was able to understand, it looks fine ;) I'll accept the changes then. most probably you want some changes in wiki too. Will have a look. Stephan
Re: Beta (status update #3)
Am 02.11.2010 um 22:43 schrieb Stephan Witt:
Am 02.11.2010 um 19:27 schrieb Pavel Sanda:
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.
Here another patch including:
* CVS helper method to ease system calls with output redirection (really
trivial ;-))
* changes to use that helper method
* CVS revision information retrieval in local cache variables
* Scan log file after CVS::repoUpdate() and warn the user when conflicts found
* extended CVS::revisionInfo() implementation
Ok to commit?
Stephan
Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 36011)
+++ src/VCBackend.h (Arbeitskopie)
@@ -261,6 +261,21 @@
// revision number from scanMaster
std::string version_;
+ /**
+* doVCCommandWithOutput
+* - call out to the version control utility
+* - it is able to collect output in a file
+* @param cmd the command to execute
+* @param path the path from which to execute
+* @param output the path where to store output
+* @param reportError display of low level error message dialog
+* @return exit status
+*/
+ int doVCCommandWithOutput(std::string const cmd,
+ support::FileName const path,
+ support::FileName const output,
+ bool reportError = true);
+
/// return the quoted pathname if Directory or filename if File
virtual std::string const getTarget(OperationMode opmode) const;
/// collect the diff of file or directory against repository
@@ -280,6 +295,14 @@
virtual CvsStatus getStatus();
/// convert enum to string
virtual docstring toString(CvsStatus status) const;
+
+ /// cache the info values of current file revision
+ /// author, date and time of commit
+ std::string rev_author_cache_;
+ std::string rev_date_cache_;
+ std::string rev_time_cache_;
+ /// fills the cache values, returns true if successfull.
+ bool getRevisionInfo();
};
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp (Revision 36011)
+++ src/VCBackend.cpp (Arbeitskopie)
@@ -56,11 +56,12 @@
if (owner_)
owner_-setBusy(false);
- if (ret reportError)
+ if (ret reportError) {
frontend::Alert::error(_(Revision control error.),
bformat(_(Some problem occured while running the
command:\n
- '%1$s'.),
- from_utf8(cmd)));
+ '%1$s'.\n),
+ from_utf8(cmd)));
+ }
return ret;
}
@@ -478,6 +479,14 @@
}
+int CVS::doVCCommandWithOutput(string const cmd, FileName const path,
+ FileName const output, bool reportError)
+{
+ string redirection = output.empty() ? :+
quoteName(output.toFilesystemEncoding());
+ return doVCCommand(cmd + redirection, path, reportError);
+}
+
+
CVS::CvsStatus CVS::getStatus()
{
FileName tmpf = FileName::tempName(lyxvcout);
@@ -486,9 +495,8 @@
return StatusError;
}
- if (doVCCommand(cvs status + getTarget(File)
- ++ quoteName(tmpf.toFilesystemEncoding()),
- FileName(owner_-filePath( {
+ if (doVCCommandWithOutput(cvs status + getTarget(File),
+ FileName(owner_-filePath()), tmpf)) {
tmpf.removeFile();
return StatusError;
}
@@ -517,7 +525,44 @@
return status;
}
+bool CVS::getRevisionInfo()
+{
+ FileName tmpf = FileName::tempName(lyxvcout);
+ if (tmpf.empty()) {
+ LYXERR(Debug::LYXVC, Could not generate logfile tmpf);
+ return false;
+ }
+
+ if (doVCCommandWithOutput(cvs log -r + version_ + +
getTarget(File),
+ FileName(owner_-filePath()), tmpf)) {
+ tmpf.removeFile();
+ return false;
+ }
+
+ ifstream ifs(tmpf.toFilesystemEncoding().c_str());
+ static regex const reg(date: (.*) (.*) (.*); author: (.*); state:
(.*);(.*));
+ bool result = false;
+ while (ifs) {
+ string line;
+ getline(ifs, line);
+ LYXERR(Debug::LYXVC, line \n);
+ if (prefixIs(line, date:)) {
+ smatch sm
Re: Release cycle proposal
Am 03.11.2010 um 12:13 schrieb Abdelrazak Younes: People should have two checkout: branch and trunk, period. I have three: * branch, * trunk for work and another * trunk for trying out my patches before posting to list. Stephan
Re: Beta (status update #3)
Am 04.11.2010 um 00:32 schrieb Pavel Sanda:
Stephan Witt wrote:
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.
Here another patch including:
* CVS helper method to ease system calls with output redirection (really
trivial ;-))
please save somewhere the previous patch we need to use the same calling
conventions
for all the stuff. hopefully lyx2lyx routines output can be fixed too with
slightly changed one.
Yes. And yes, I have it at hand.
-if (ret reportError)
+if (ret reportError) {
frontend::Alert::error(_(Revision control error.),
bformat(_(Some problem occured while running the
command:\n
- '%1$s'.),
-from_utf8(cmd)));
+ '%1$s'.\n),
+from_utf8(cmd)));
+}
why this '}' ?
A leftover from previous patch.
I can live without it. :-)
int rc = update(File, tmpf);
string log;
string const res = scanLogFile(tmpf, log);
-if (!res.empty())
+if (!res.empty()) {
frontend::Alert::error(_(Revision control error.),
bformat(_(Error when updating from repository.\n
You have to manually resolve the conflicts
NOW!\n'%1$s'.\n\n
After pressing OK, LyX will try to reopen the
resolved document.),
from_local8bit(res)));
chmm, we dont use from_local8bit on other places.
things go wrong with nonascii filenames?
It's used in SVN::checkOut() too.
And it's the result of scanLogFile parser and not a filename.
I think, the general problem is the switch from std::string to docstring and
vice versa.
It is std::string what is used for interface of VCS classes. but the alerts use
docstrings...
@@ -807,8 +863,26 @@
string CVS::revisionInfo(LyXVC::RevisionInfo const info)
{
-if (info == LyXVC::File)
-return version_;
+if (!version_.empty()) {
+if (rev_author_cache_.empty()) {
+if (!getRevisionInfo()) {
+rev_author_cache_ = to_local8bit(_(unknown
author));
+rev_date_cache_ = to_local8bit(_(unknown
date));
+rev_time_cache_ = to_local8bit(_(unknown
time));
this code breaks the current practise - either we return true value or empty
string in unknown case, which will be handled on the hierarchy above.
and i think i see latent translating bug in the handling code above. wanted to
check it but why the hell LC_MESSAGES=cs_CZ src/lyx doesn't work anymore for
trunk...
I'll use an explicit getRevisionInfo() success state flag and return string()
instead. Ok?
Stephan
Re: Beta (status update #3)
Am 04.11.2010 um 14:45 schrieb Pavel Sanda:
Stephan Witt wrote:
string CVS::revisionInfo(LyXVC::RevisionInfo const info)
{
- if (info == LyXVC::File)
- return version_;
+ if (!version_.empty()) {
+ if (rev_author_cache_.empty()) {
+ if (!getRevisionInfo()) {
+ rev_author_cache_ = to_local8bit(_(unknown
author));
+ rev_date_cache_ = to_local8bit(_(unknown
date));
+ rev_time_cache_ = to_local8bit(_(unknown
time));
this code breaks the current practise - either we return true value or empty
string in unknown case, which will be handled on the hierarchy above.
and i think i see latent translating bug in the handling code above. wanted
to
check it but why the hell LC_MESSAGES=cs_CZ src/lyx doesn't work anymore for
trunk...
I'll use an explicit getRevisionInfo() success state flag and return
string() instead. Ok?
not sure what exactly do you mean :)
That's how I understood your comment, but the new patch is not ready...
Like that:
string CVS::revisionInfo(LyXVC::RevisionInfo const info)
{
if (!version_.empty()) {
if (!have_rev_info_) {
if (!getRevisionInfo())
LYXERR(Debug::LYXVC,
Could not retrieve revision info for
version_
of getTarget(File));
have_rev_info_ = true;
}
switch (info) {
case LyXVC::File:
return version_;
case LyXVC::Author:
return rev_author_cache_;
case LyXVC::Date:
return rev_date_cache_;
case LyXVC::Time:
return rev_time_cache_;
default: ;
}
}
return string();
}
Stephan
Re: Beta (status update #3)
Am 04.11.2010 um 16:15 schrieb Pavel Sanda: Stephan Witt wrote: I'll use an explicit getRevisionInfo() success state flag and return string() instead. Ok? not sure what exactly do you mean :) That's how I understood your comment, but the new patch is not ready... Like that: i'm basically happy that the duplicated strings disappeared. lyxerr looks more approriate inside getRevisionInfo. Ok. iirc svn used ? hack for this, but do as you wish.. Yes, this I didn't like. Stephan
Re: Beta (status update #3)
Am 04.11.2010 um 16:52 schrieb Stephan Witt:
Am 04.11.2010 um 16:15 schrieb Pavel Sanda:
Stephan Witt wrote:
I'll use an explicit getRevisionInfo() success state flag and return
string() instead. Ok?
not sure what exactly do you mean :)
That's how I understood your comment, but the new patch is not ready...
Like that:
i'm basically happy that the duplicated strings disappeared.
lyxerr looks more approriate inside getRevisionInfo.
Ok.
Now I've finished the patch and have a fundamental problem:
When a document contains vcs buffer-info insets like vcs-author the reload
crashes. The culprit is the owner_-setBusy(false); in VCS::doVCCommand().
The cursor cannot be changed when the buffer load is in progress - it seems.
I solved it with using the reportError flag to suppress the cursor changes.
I'm sure - it's not the correct solution. But I cannot solve this in a better
way.
Please help. I'm frustrated. One possible change is to move the info inset
variable
initialization into file_found_hook()... but this is a static method - again
more to change then planned.
Anyway, the patch is attached (with the reportError/cursor logic).
I'd appreciate any comment. (I fear SVN is affected by that too!)
Stephan
Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 36088)
+++ src/VCBackend.h (Arbeitskopie)
@@ -261,6 +261,21 @@
// revision number from scanMaster
std::string version_;
+ /**
+* doVCCommandWithOutput
+* - call out to the version control utility
+* - it is able to collect output in a file
+* @param cmd the command to execute
+* @param path the path from which to execute
+* @param output the path where to store output
+* @param reportError display of low level error message dialog
+* @return exit status
+*/
+ int doVCCommandWithOutput(std::string const cmd,
+ support::FileName const path,
+ support::FileName const output,
+ bool reportError = true);
+
/// return the quoted pathname if Directory or filename if File
virtual std::string const getTarget(OperationMode opmode) const;
/// collect the diff of file or directory against repository
@@ -280,6 +295,15 @@
virtual CvsStatus getStatus();
/// convert enum to string
virtual docstring toString(CvsStatus status) const;
+
+ /// cache the info values of current file revision
+ /// author, date and time of commit
+ std::string rev_author_cache_;
+ std::string rev_date_cache_;
+ std::string rev_time_cache_;
+ /// fills the cache values, returns true if successfull.
+ void getRevisionInfo();
+ bool have_rev_info_;
};
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp (Revision 36088)
+++ src/VCBackend.cpp (Arbeitskopie)
@@ -49,18 +49,19 @@
int VCS::doVCCommand(string const cmd, FileName const path, bool
reportError)
{
- if (owner_)
+ if (owner_ reportError)
owner_-setBusy(true);
int const ret = doVCCommandCall(cmd, path);
- if (owner_)
+ if (owner_ reportError)
owner_-setBusy(false);
- if (ret reportError)
+ if (ret reportError) {
frontend::Alert::error(_(Revision control error.),
bformat(_(Some problem occured while running the
command:\n
- '%1$s'.),
- from_utf8(cmd)));
+ '%1$s'.\n),
+ from_utf8(cmd)));
+ }
return ret;
}
@@ -366,6 +367,7 @@
{
master_ = m;
file_ = f;
+ have_rev_info_ = false;
scanMaster();
}
@@ -478,6 +480,14 @@
}
+int CVS::doVCCommandWithOutput(string const cmd, FileName const path,
+ FileName const output, bool reportError)
+{
+ string redirection = output.empty() ? :+
quoteName(output.toFilesystemEncoding());
+ return doVCCommand(cmd + redirection, path, reportError);
+}
+
+
CVS::CvsStatus CVS::getStatus()
{
FileName tmpf = FileName::tempName(lyxvcout);
@@ -486,9 +496,8 @@
return StatusError;
}
- if (doVCCommand(cvs status + getTarget(File)
- ++ quoteName(tmpf.toFilesystemEncoding()),
- FileName(owner_-filePath( {
+ if (doVCCommandWithOutput(cvs status + getTarget(File),
+ FileName(owner_-filePath()), tmpf)) {
tmpf.removeFile();
return StatusError;
}
@@ -517,7 +526,51 @@
return status;
}
+void CVS::getRevisionInfo()
+{
+ if (have_rev_info_)
+ return;
+ have_rev_info_ = true;
+ FileName tmpf
Re: Beta (status update #3)
Am 05.11.2010 um 21:27 schrieb Vincent van Ravesteijn: Now I've finished the patch and have a fundamental problem: When a document contains vcs buffer-info insets like vcs-author the reload crashes. The culprit is the owner_-setBusy(false); in VCS::doVCCommand(). The cursor cannot be changed when the buffer load is in progress - it seems. I solved it with using the reportError flag to suppress the cursor changes. I'm sure - it's not the correct solution. But I cannot solve this in a better way. Please help. I'm frustrated. Fixed in http://www.lyx.org/trac/changeset/36140. Thanks. I finally avoided the owner_-setBusy calls. But your fix is a good move anyway. (I fear SVN is affected by that too!) Yes, it is. Currently I cannot test this - see Pavels mails also... I cannot open any LyX document anymore - lyx2lyx needs a fix. It constantly states: Warning: 405: Format not supported. Warning: Quitting. Error: Conversion script failed .../playground/Apostrophe.lyx is from an older version of LyX, but the lyx2lyx script failed to convert it. I'm glad I did the final tests before... Stephan
Re: vcs load problem
Am 05.11.2010 um 22:30 schrieb Vincent van Ravesteijn: first step to cure the VCS load problem Is it now completely fixed after r36145 ? 99,9% yes... :-) I have to start over with a new document to verify it. Though I'm nearly sure it works. My proposed patch was included in yours. Stephan
Re: r36153 - lyx-devel/trunk/src
Am 06.11.2010 um 03:21 schrieb sa...@lyx.org:
Author: sanda
Date: Sat Nov 6 03:21:04 2010
New Revision: 36153
URL: http://www.lyx.org/trac/changeset/36153
Log:
Fix RCS part of #6396. Btw revert is slightly broken now...
Patch 1 should fix it... ok?
Patch 2 implements Compare with older revision for CVS... ok?
Stephan
Index: src/LyXVC.cpp
===
--- src/LyXVC.cpp (Revision 36154)
+++ src/LyXVC.cpp (Arbeitskopie)
@@ -208,7 +208,7 @@
}
-void LyXVC::revert()
+bool LyXVC::revert()
{
LYXERR(Debug::LYXVC, LyXVC: revert);
@@ -223,6 +223,7 @@
if (ret == 0)
vcs-revert();
+ return ret == 0;
}
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp (Revision 36154)
+++ src/frontends/qt4/GuiView.cpp (Arbeitskopie)
@@ -2701,9 +2701,10 @@
case LFUN_VC_REVERT:
LASSERT(buffer, return);
- buffer-lyxvc().revert();
- reloadBuffer(*buffer);
- dr.suppressMessageUpdate();
+ if (buffer-lyxvc().revert()) {
+ reloadBuffer(*buffer);
+ dr.suppressMessageUpdate();
+ }
break;
case LFUN_VC_UNDO_LAST:
Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 36152)
+++ src/VCBackend.h (Arbeitskopie)
@@ -91,6 +91,10 @@
/// parse information from the version file
virtual void scanMaster() = 0;
+ /// make a relative version identifier
+ /// suitable for RCS and CVS
+ bool makeRCSRevision(std::string const version, std::string revis)
const;
+
// GUI container for doVCCommandCall
int doVCCommand(std::string const cmd, support::FileName const
path, bool reportError = true);
/**
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp (Revision 36152)
+++ src/VCBackend.cpp (Arbeitskopie)
@@ -65,6 +65,40 @@
}
+bool VCS::makeRCSRevision(string const version, string revis) const
+{
+ string rev = revis;
+
+ if (isStrInt(rev)) {
+ int back = convertint(rev);
+ // if positive use as the last number in the whole revision
string
+ if (back 0) {
+ string base;
+ rsplit(version, base , '.' );
+ rev = base + . + rev;
+ }
+ if (back == 0)
+ rev = version;
+ // we care about the last number from revision string
+ // in case of backward indexing
+ if (back 0) {
+ string cur, base;
+ cur = rsplit(version, base , '.' );
+ if (!isStrInt(cur))
+ return false;
+ int want = convertint(cur) + back;
+ if (want = 0)
+ return false;
+
+ rev = base + . + convertstring(want);
+ }
+ }
+
+ revis = rev;
+ return true;
+}
+
+
/
//
// RCS
@@ -306,32 +340,9 @@
bool RCS::prepareFileRevision(string const revis, string f)
{
string rev = revis;
+ if (!VCS::makeRCSRevision(version_, rev))
+ return false;
- if (isStrInt(rev)) {
- int back = convertint(rev);
- // if positive use as the last number in the whole revision
string
- if (back 0) {
- string base;
- rsplit(version_, base , '.' );
- rev = base + . + rev;
- }
- if (back == 0)
- rev = version_;
- // we care about the last number from revision string
- // in case of backward indexing
- if (back 0) {
- string cur, base;
- cur = rsplit(version_, base , '.' );
- if (!isStrInt(cur))
- return false;
- int want = convertint(cur) + back;
- if (want = 0)
- return false;
-
- rev = base + . + convertstring(want);
- }
- }
-
FileName tmpf = FileName::tempName(lyxvcrev_ + rev + _);
if (tmpf.empty()) {
LYXERR(Debug::LYXVC, Could not generate logfile tmpf);
@@ -898,15 +909,32 @@
}
-bool CVS::prepareFileRevision(string const , string )
+bool CVS::prepareFileRevision(string const revis, string f)
{
- return
Re: r36153 - lyx-devel/trunk/src
Am 06.11.2010 um 03:44 schrieb Stephan Witt:
Am 06.11.2010 um 03:21 schrieb sa...@lyx.org:
Author: sanda
Date: Sat Nov 6 03:21:04 2010
New Revision: 36153
URL: http://www.lyx.org/trac/changeset/36153
Log:
Fix RCS part of #6396. Btw revert is slightly broken now...
Patch 1 should fix it... ok?
Forgot to add the LyXVC.h change.
Stephan
Index: src/LyXVC.cpp
===
--- src/LyXVC.cpp (Revision 36154)
+++ src/LyXVC.cpp (Arbeitskopie)
@@ -208,7 +208,7 @@
}
-void LyXVC::revert()
+bool LyXVC::revert()
{
LYXERR(Debug::LYXVC, LyXVC: revert);
@@ -223,6 +223,7 @@
if (ret == 0)
vcs-revert();
+ return ret == 0;
}
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp (Revision 36154)
+++ src/frontends/qt4/GuiView.cpp (Arbeitskopie)
@@ -2701,9 +2701,10 @@
case LFUN_VC_REVERT:
LASSERT(buffer, return);
- buffer-lyxvc().revert();
- reloadBuffer(*buffer);
- dr.suppressMessageUpdate();
+ if (buffer-lyxvc().revert()) {
+ reloadBuffer(*buffer);
+ dr.suppressMessageUpdate();
+ }
break;
case LFUN_VC_UNDO_LAST:
Index: src/LyXVC.h
===
--- src/LyXVC.h (Revision 36152)
+++ src/LyXVC.h (Arbeitskopie)
@@ -98,7 +98,7 @@
bool lockingToggleEnabled() const;
/// Revert to last version
- void revert();
+ bool revert();
/// Undo last check-in.
void undoLast();
Re: r36153 - lyx-devel/trunk/src
Am 06.11.2010 um 03:44 schrieb Stephan Witt:
Am 06.11.2010 um 03:21 schrieb sa...@lyx.org:
Author: sanda
Date: Sat Nov 6 03:21:04 2010
New Revision: 36153
URL: http://www.lyx.org/trac/changeset/36153
Log:
Fix RCS part of #6396. Btw revert is slightly broken now...
Patch 1 should fix it... ok?
A more complete solution including the check of VCS::revert() success.
Stephan
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp (Revision 36154)
+++ src/frontends/qt4/GuiView.cpp (Arbeitskopie)
@@ -2701,9 +2701,10 @@
case LFUN_VC_REVERT:
LASSERT(buffer, return);
- buffer-lyxvc().revert();
- reloadBuffer(*buffer);
- dr.suppressMessageUpdate();
+ if (buffer-lyxvc().revert()) {
+ reloadBuffer(*buffer);
+ dr.suppressMessageUpdate();
+ }
break;
case LFUN_VC_UNDO_LAST:
Index: src/LyXVC.h
===
--- src/LyXVC.h (Revision 36152)
+++ src/LyXVC.h (Arbeitskopie)
@@ -98,7 +98,7 @@
bool lockingToggleEnabled() const;
/// Revert to last version
- void revert();
+ bool revert();
/// Undo last check-in.
void undoLast();
Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 36159)
+++ src/VCBackend.h (Arbeitskopie)
@@ -57,7 +57,7 @@
// can be this operation processed in the current RCS?
virtual bool lockingToggleEnabled() = 0;
/// revert current edits
- virtual void revert() = 0;
+ virtual bool revert() = 0;
// should a confirmation before revert requested?
virtual bool isRevertWithConfirmation() = 0;
/// FIXME
@@ -147,7 +147,7 @@
virtual bool lockingToggleEnabled();
- virtual void revert();
+ virtual bool revert();
virtual bool isRevertWithConfirmation();
@@ -214,7 +214,7 @@
virtual bool isRevertWithConfirmation();
- virtual void revert();
+ virtual bool revert();
virtual void undoLast();
@@ -340,7 +340,7 @@
virtual bool lockingToggleEnabled();
- virtual void revert();
+ virtual bool revert();
virtual bool isRevertWithConfirmation();
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp (Revision 36159)
+++ src/VCBackend.cpp (Arbeitskopie)
@@ -267,13 +267,15 @@
}
-void RCS::revert()
+bool RCS::revert()
{
- doVCCommand(co -f -u + version_ +
+ if (doVCCommand(co -f -u + version_ +
+ quoteName(onlyFileName(owner_-absFileName())),
- FileName(owner_-filePath()));
+ FileName(owner_-filePath(
+ return false;
// We ignore changes and just reload!
owner_-markClean();
+ return true;
}
@@ -831,7 +833,7 @@
}
-void CVS::revert()
+bool CVS::revert()
{
// Reverts to the version in CVS repository and
// gets the updated version from the repository.
@@ -839,7 +841,7 @@
switch (status) {
case UpToDate:
if (vcstatus != NOLOCKING)
- unedit();
+ return 0 == unedit();
break;
case NeedsMerge:
case NeedsCheckout:
@@ -856,7 +858,7 @@
bformat(_(The document %1$s is not in repository.\n
You have to check in the first revision
before you can revert.),
file)) ;
- break;
+ return false;
}
default: {
docstring const file = owner_-fileName().displayName(20);
@@ -864,9 +866,10 @@
bformat(_(Cannot revert document %1$s to repository
version.\n
The status '%2$s' is unexpected.),
file, toString(status)));
- break;
+ return false;
}
}
+ return true;
}
@@ -1294,15 +1297,17 @@
}
-void SVN::revert()
+bool SVN::revert()
{
// Reverts to the version in SVN repository and
// gets the updated version from the repository.
string const fil = quoteName(onlyFileName(owner_-absFileName()));
- doVCCommand(svn revert -q + fil,
- FileName(owner_-filePath()));
+ if (doVCCommand(svn revert -q + fil,
+ FileName(owner_-filePath(
+ return false;
owner_-markClean();
+ return true;
}
Index: src/LyXVC.cpp
===
--- src/LyXVC.cpp (Revision 36159)
+++ src/LyXVC.cpp
Re: r36162 - lyx-devel/trunk/src
Am 06.11.2010 um 13:32 schrieb sa...@lyx.org:
Author: sanda
Date: Sat Nov 6 13:32:47 2010
New Revision: 36162
URL: http://www.lyx.org/trac/changeset/36162
Log:
Comment
Thank you, better indeed.
I made an attempt to really compute a SVN::isRevertWithConfirmation() result.
I used svn status to substitute svn diff - this should be cheaper.
The isModified() helper method can be used for SVN::isCheckInWithConfirmation()
too.
Does this make sense?
Stephan
Index: src/VCBackend.h
===
--- src/VCBackend.h (Revision 36161)
+++ src/VCBackend.h (Arbeitskopie)
@@ -376,6 +376,8 @@
bool isLocked() const;
/// acquire/release write lock for the current file
void fileLock(bool lock, support::FileName const tmpf, std::string
status);
+ /// check for local modification
+ bool isModified();
private:
support::FileName file_;
Index: src/VCBackend.cpp
===
--- src/VCBackend.cpp (Revision 36161)
+++ src/VCBackend.cpp (Arbeitskopie)
@@ -1073,21 +1073,26 @@
return N_(Error: Could not generate logfile.);
}
- doVCCommand(svn commit -m \ + msg + \
- + quoteName(onlyFileName(owner_-absFileName()))
- ++ quoteName(tmpf.toFilesystemEncoding()),
- FileName(owner_-filePath()));
-
string log;
- string res = scanLogFile(tmpf, log);
- if (!res.empty())
- frontend::Alert::error(_(Revision control error.),
+
+ if (isModified()) {
+ doVCCommand(svn commit -m \ + msg + \
+ +
quoteName(onlyFileName(owner_-absFileName()))
+ ++
quoteName(tmpf.toFilesystemEncoding()),
+ FileName(owner_-filePath()));
+
+ string res = scanLogFile(tmpf, log);
+ if (!res.empty())
+ frontend::Alert::error(_(Revision control error.),
_(Error when committing to repository.\n
- You have to manually resolve the problem.\n
- LyX will reopen the document after you press
OK.));
- else
+ You have to manually resolve the problem.\n
+ LyX will reopen the document after you press
OK.));
+ else
+ fileLock(false, tmpf, log);
+ } else {
fileLock(false, tmpf, log);
-
+ }
+
tmpf.erase();
return log.empty() ? string() : SVN: + log;
}
@@ -1102,30 +1107,36 @@
}
-bool SVN::isCheckInWithConfirmation()
+bool SVN::isModified()
{
- // FIXME one day common getDiff and perhaps OpMode for all backends
-
+ // FIXME one day common getDiff/isModified and perhaps OpMode for all
backends
FileName tmpf = FileName::tempName(lyxvcout);
if (tmpf.empty()) {
LYXERR(Debug::LYXVC, Could not generate logfile tmpf);
return true;
}
- doVCCommandCall(svn diff + quoteName(owner_-absFileName())
- ++ quoteName(tmpf.toFilesystemEncoding()),
- FileName(owner_-filePath()));
+ doVCCommand(svn status +
quoteName(onlyFileName(owner_-absFileName()))
+ ++
quoteName(tmpf.toFilesystemEncoding()),
+ FileName(owner_-filePath()));
+
+ ifstream ifs(tmpf.toFilesystemEncoding().c_str());
+ string line;
+ bool result = false;
+
+ while (!result ifs) {
+ getline(ifs, line);
+ result = !line.empty();
+ }
+ return result;
+}
- docstring diff = tmpf.fileContents(UTF-8);
- tmpf.erase();
-
- if (diff.empty())
- return false;
-
- return true;
+bool SVN::isCheckInWithConfirmation()
+{
+ return isModified();
}
-
-
+
+
// FIXME Correctly return code should be checked instead of this.
// This would need another solution than just plain startscript.
// Hint from Andre': QProcess::readAllStandardError()...
@@ -1342,7 +1353,7 @@
bool SVN::isRevertWithConfirmation()
{
//FIXME owner diff
- return true;
+ return !owner_-isClean() || isModified();
}
Re: r36162 - lyx-devel/trunk/src
Am 06.11.2010 um 14:13 schrieb Pavel Sanda: Stephan Witt wrote: Thank you, better indeed. I made an attempt to really compute a SVN::isRevertWithConfirmation() result. I used svn status to substitute svn diff - this should be cheaper. The isModified() helper method can be used for SVN::isCheckInWithConfirmation() too. Does this make sense? i was reconciled with the fact revert confirmation remains as it was since the whole machinery looks like a bloat. it makes sense with committing which you use ten times a day, but i can hardly remember when i used reversal. also when using it i always want to see diff, so going to commandline anyway... secondly i guess that you can't use svn status without parsing (non empty != modified) Yes. This I had in mind already - svn status ? for example. its output so it maybe cheaper in terms of CPU but not in code complexity. Ok. I'll drop it then. Otherwise I don't have any open VCS issue which fits 2.0 for now. The Additional manual needs accept changes but not only mine. most probably you want some changes in wiki too. I tried to locate in wiki what you mention - but failed. Do you refer to wiki.lyx.org? What should I look up? For the time after 2.0 release: In addition to the SystemCall and refactoring stuff I think Register can be improved. The Register operation does not register child documents, images et al. I'd like to propose to let Register open a dialog with * the opportunity to choose the backend for initial use and avoid using RCS blindly * a list of document components (children, etc) to add to the register operation * the option to control locking/reserved checkout You may have your plans too - I only wanted to mention my idea. Stephan
Re: r36162 - lyx-devel/trunk/src
Am 06.11.2010 um 15:51 schrieb Stephan Witt: Am 06.11.2010 um 14:13 schrieb Pavel Sanda: Stephan Witt wrote: most probably you want some changes in wiki too. I tried to locate in wiki what you mention - but failed. Do you refer to wiki.lyx.org? What should I look up? Ah, I finally found something. Did you refer to http://wiki.lyx.org/Mac/VersionControl ? This is indeed really outdated. I couldn't find it because I searched for CVS and SVN ;-) Stephan
Re: New Mac user seek advice (mostly offtopics)
Am 06.11.2010 um 23:27 schrieb BH:
On Sat, Nov 6, 2010 at 5:22 PM, Abdelrazak Younes you...@lyx.org wrote:
Hi there,
My employer just got me a brand new MacBook Pro. I am not impressed so far
by MacOS so called legendary user friendlyness but I am trying to get used
to it right now.
The modern desktops with Linux and Windows had done much work to shorten the
distance.
I'm a long time Linux user and Windows hater. I had to learn the Apple way to
do the
tasks too. But I have to admit now - for many tasks you easily can get the job
done.
And most developer documentation is in an extra-ordinary good state.
But if you hit a limit - then you have a problem, like with any other system.
Only Linux makes a difference here - at the cost of your time...
Anyway, I need to install development stuff. I've downloaded latest XCode
and Qt SDK. Now I need to know if I'd better use fink or MacPort (or
something else?) for package...
More generally, Bennett, Stefan, any advice?
Thanks in advance,
I (and Stephan I believe) use MacPorts, though fink should work fine
as well. I have been using cmake (with the precompiled Qt package),
though I haven't used cmake to generate an XCode project. Stephan uses
autotools (with self-compiled Qt?).
I'm using
* macports for autotools, cmake, etc.
* Xcode for compiler and IDE (cmake based project)
* self compiled Qt 4.6.3 library (because of #6706 is fixed then)
* self compiled hunspell and aspell libraries (frameworks)
* a Dictionaries collection (which needs to be checked in)
* for automake builds the script development/LyX-Mac-binary-release.sh
* for cmake generation the script mkcmake.sh (attached)
(which needs a first release build with autotools for Resources)
* to use hunspell and aspell with cmake I patched the development/cmake files
All the stuff is living in a common directory and the results are bundled
below the subdirectory lyx-build.
.../lyx
.../lyx/lyx-devel (svn checkout)
.../lyx/qt-everywhere-opensource-src-4.6.3 (source tar content from Nokia -
patched)
.../lyx/Dictionaries (collection of zip files from different sources)
.../lyx/hunspell-1.2.9 (source tar content)
.../lyx/aspell-0.60.6 (source tar content - patched to solve 32/64 bit issues)
.../lyx/lyx-build/LyX-2.0.0svn.build (automake build stage)
.../lyx/lyx-build/LyX-2.0.0svn.app (automake result)
.../lyx/lyx-build/lyx-cmake (Xcode project)
.../lyx/lyx-build/... etc.
When developing new code I'm using Xcode.
For release builds and final tests I'm using autotools.
I think CMake currently isn't able to produce a Xcode project with package
build capabilities.
So I didn't try it and use our LyX-Mac-binary-release.sh script instead.
Stephan
mkcmake.sh
Description: Binary data
Index: development/cmake/modules/LyXMacros.cmake
===
--- development/cmake/modules/LyXMacros.cmake (Revision 36164)
+++ development/cmake/modules/LyXMacros.cmake (Arbeitskopie)
@@ -57,6 +57,7 @@
MAIN_DEPENDENCY ${_tmp_FILE}
)
set(${_ui} ${${_ui}} ${_header})
+ SET_SOURCE_FILES_PROPERTIES(${_header} GENERATED)
endforeach (_current_FILE)
endmacro(LYX_ADD_UI_FILES)
Index: development/cmake/modules/FindASPELL.cmake
===
--- development/cmake/modules/FindASPELL.cmake (Revision 36164)
+++ development/cmake/modules/FindASPELL.cmake (Arbeitskopie)
@@ -50,12 +50,14 @@
/usr/local/include
/usr/local/include/aspell
${_program_FILES_DIR}/gnuwin32/include
+ /Users/stephan/cvs/lyx/lyx-build/SpellChecker.lib/include
)
FIND_LIBRARY(ASPELL_LIBRARY_RELEASE NAMES aspell aspell-15 libaspell
libaspell-15
PATHS
/usr/lib
/usr/local/lib
+ /Users/stephan/cvs/lyx/lyx-build/SpellChecker.lib/lib
)
# msvc makes a difference between debug and release
Index: development/cmake/modules/FindHunspell.cmake
===
--- development/cmake/modules/FindHunspell.cmake(Revision 36164)
+++ development/cmake/modules/FindHunspell.cmake(Arbeitskopie)
@@ -3,10 +3,10 @@
find_library(HUNSPELL_LIBRARY libhunspell)
else()
#find_library(HUNSPELL_LIBRARY NAME hunspell PATH /usr/local/lib
/usr/lib NO_DEFAULT_PATH)
- find_library(HUNSPELL_LIBRARY NAMES hunspell hunspell-1.2 PATHS
/usr/local/lib /usr/lib /usr/lib64)
+ find_library(HUNSPELL_LIBRARY NAMES hunspell hunspell-1.2 PATHS
/Users/stephan/cvs/lyx/lyx-build/SpellChecker.lib/lib /usr/local/lib
/usr/lib /usr/lib64)
endif()
-FIND_PATH(HUNSPELL_INCLUDE_DIR hunspell/hunspell.hxx)
+FIND_PATH(HUNSPELL_INCLUDE_DIR hunspell/hunspell.hxx PATHS
/Users/stephan/cvs/lyx/lyx-build/SpellChecker.lib/include)
# handle the QUIETLY and REQUIRED arguments and
Re: New Mac user seek advice (mostly offtopics)
Am 07.11.2010 um 10:58 schrieb Liviu Andronic: On Sun, Nov 7, 2010 at 10:21 AM, Abdelrazak Younes you...@lyx.org wrote: Mac user friendliness is an acquired taste. Just as Windows or any other desktop then :-) But it seems that MacOS wants to impose me a way of working and I really don't like it. I find it particularly irritating that I cannot maximize all windows the same way. Safari for example only maximizes vertically. I hope LyX is not doing the same. Also, the only way to resize a window seems to be the grip control on the bottom right... Why not install Linux on the Mac, then? From what I understand, the latest Macs are fully compatible with x86. I tried it and I'd recommend the use of VirtualBox instead. I don't know the hardware resources of Abdels mac book... but it should work really good. Linux distros are not optimal for the mac book hardware. The usual nasty details like fan control, battery lifetime etc are not well supported. I cannot judge the latest distros - but as I tried I could work without power-supply 4 times longer with Mac OS X as with (SuSE) Linux. Stephan
Re: New Mac user seek advice (mostly offtopics)
Am 07.11.2010 um 19:52 schrieb Pavel Sanda: Stephan Witt wrote: I'm using * self compiled Qt 4.6.3 library (because of #6706 is fixed then) into INSTALL.MacOSX? What exactly? It's described there already how to make a self compiled Qt library. Regarding the patch - the link is in ticket #6706 mentioned. At the time of investigating it Qt 4.7 was beta. I didn't find the time until now to test if it's fixed in Qt4.7 release. Stephan
Re: New Mac user seek advice (mostly offtopics)
Am 07.11.2010 um 21:54 schrieb Pavel Sanda: Stephan Witt wrote: I'm using * self compiled Qt 4.6.3 library (because of #6706 is fixed then) into INSTALL.MacOSX? What exactly? we suggest to use lyx with qt 4.6.2? Ah ok, it doesn't make a difference AFAICS. 4.6.2 is working well too (except the bug mentioned in #6706). I gave 4.6.3 a try and it's the latest 4.6 version. Stephan
Re: New Mac user seek advice (mostly offtopics)
Am 07.11.2010 um 22:02 schrieb Stephan Witt: Am 07.11.2010 um 21:54 schrieb Pavel Sanda: Stephan Witt wrote: I'm using * self compiled Qt 4.6.3 library (because of #6706 is fixed then) into INSTALL.MacOSX? What exactly? we suggest to use lyx with qt 4.6.2? Ah ok, it doesn't make a difference AFAICS. 4.6.2 is working well too (except the bug mentioned in #6706). I gave 4.6.3 a try and it's the latest 4.6 version. To be clear: the bug is in 4.6.3 present too. That's why the patch is needed... Stephan
Re: New Mac user seek advice (mostly offtopics)
Am 07.11.2010 um 22:19 schrieb Vincent van Ravesteijn: To be clear: the bug is in 4.6.3 present too. That's why the patch is needed... Stephan Which bug are we talking about here ? The bug is described in ticket #6706. It's not in LyX, it's in Qt - therefore the LyX ticket was closed. But the problem is real. Stephan
Re: New Mac user seek advice (mostly offtopics)
Am 08.11.2010 um 09:34 schrieb Vincent van Ravesteijn: To be clear: the bug is in 4.6.3 present too. That's why the patch is needed... Stephan Which bug are we talking about here ? The bug is described in ticket #6706. It's not in LyX, it's in Qt - therefore the LyX ticket was closed. But the problem is real. Stephan I would have left the bug open until we can confirm that the bug is solved in Qt. According to Qt's website, the bug is fixed in Qt 4.7.0. Are you able to check that ? Yes, later. But read Bennetts mail in this thread. He says it works. At the cost of nasty font render problems. These were already discussed. It depends on the display font how bad the rendering is. The root cause may be that the text fragment passed to Qt string draw differs from the text fragment(s) used to calculate the screen position. Most affected are ligatures. Stephan
Re: r36200 - lyx-devel/trunk
Am 07.11.2010 um 22:20 schrieb Jean-Marc Lasgouttes: Le 7 nov. 10 à 22:08, sw...@lyx.org a écrit : Author: switt Date: Sun Nov 7 22:08:23 2010 New Revision: 36200 URL: http://www.lyx.org/trac/changeset/36200 Log: we now require gettext version 0.18 at least Why is that? Shall we do the same for all of LyX? We could use this version as included gettext. It's the requirement for gettext tools, AFAIK. Otherwise the build stops because of bugs in the tools. My work-around was denied with the argument encourage people to update. Do you remember? ;-) Stephan
Re: New Mac user seek advice (mostly offtopics)
Am 08.11.2010 um 09:49 schrieb Vincent van Ravesteijn: ... At the cost of nasty font render problems. These were already discussed. It depends on the display font how bad the rendering is. The root cause may be that the text fragment passed to Qt string draw differs from the text fragment(s) used to calculate the screen position. Most affected are ligatures. These problems need to get fixed ;). Yes. I don't know how difficult it is. BTW, is this a problem only on Mac OSX platform? Stephan
Re: instructions for upgrade from LyX 1.6.7 to 2.0 beta 1?
Am 11.11.2010 um 07:42 schrieb Justin Wood: Hi gang. As LyX 2.0 beta 1 is now released, I thought I'd make the switch over (OS X 10.6). Hi Justin, good to have brave users who are going to test beta release of LyX 2.0. But it's beta and not clear exactly when the release will happen. So I hope, you're using it with copies of your important documents. It installs and runs fine, but as best I can tell there is no automated import of LyX 1.6.7 settings. Yes, the automated import is on the agenda only. The needed scripts are unfinished or at least the integration of them. Are there any (draft) instructions available for walking the upgrade path? Are there any backwards compatibility issues or conflicts to watch out for, or can the existing LyX-1.6 user directory pretty much just be copied across? Yes, there are backwards compatibility issues. I never did copy the user directory and the plan is to make the transition with the help of converter scripts. Ditto for migrating actual documents. That is done automatically and should work. After saving the documents they'll have the new 2.0 format. In the near future LyX 1.6 will be able to read LyX 2.0 documents. That's not the case already. So, as said above, you should start with copies of your documents since there is no easy way to go back. Thanks! And very much looking forward to using this shiny new creature. Have fun. Stephan
Re: Spellchecker not active, command disable
Am 11.11.2010 um 10:18 schrieb Waluyo Adi Siswanto: I just compile lyx-2.0.0beta1 using the following commands: ./configure --with-version-suffix=-2.0.0beta1 make sudo make install everything ok no errors, When ./configure is run the available spellchecker header and libraries are checked. You may find the cause when studying config.log - I have it like that: ... checking aspell.h usability... yes checking aspell.h presence... yes checking for aspell.h... yes checking for new_aspell_config in -laspell... yes checking whether to use aspell... yes checking for name of aspell framework... Aspell.framework checking for ENCHANT... checking whether to use enchant... no checking hunspell/hunspell.hxx usability... yes checking hunspell/hunspell.hxx presence... yes checking for hunspell/hunspell.hxx... yes checking for main in -lhunspell... yes checking whether to use hunspell... yes ... Configuration Host type:powerpc-apple-darwin8 Special build flags: warnings use-aspell use-hunspell C Compiler: gcc ... but when I run lyx-2.0.0beta1, the spellchecker is not active. If I see the from the preference, it is grey (see the attachment) Unfortunately you missed to attach the screen shot. Stephan
Re: Spellchecker not active, command disable
Am 11.11.2010 um 11:13 schrieb Waluyo Adi Siswanto: checking aspell.h usability... yes checking aspell.h presence... yes checking for aspell.h... yes checking for new_aspell_config in -laspell... yes checking whether to use aspell... yes checking for name of aspell framework... Aspell.framework checking for ENCHANT... checking whether to use enchant... no checking hunspell/hunspell.hxx usability... yes checking hunspell/hunspell.hxx presence... yes checking for hunspell/hunspell.hxx... yes checking for main in -lhunspell... yes checking whether to use hunspell... yes when I see the config.log, it looks not found, some errors (see config.log in the attachment). You have to install the development package for aspell (and/or hunspell if you like to use it). I have (with OpenSuSE): % rpm -q -v -f /usr/include/aspell.h aspell-devel-0.60.6-28.2.i586 % Don't ask me how to install it with Ubuntu. But my lyx-1.6.7, it has ispell, aspell and hspell. But you didn't build it yourself? Stephan
Re: Spellchecker not active, command disable
Am 12.11.2010 um 00:33 schrieb Emil Pavlov: На 11.11.2010 10:18, Waluyo Adi Siswanto написа: I just compile lyx-2.0.0beta1 using the following commands: ./configure --with-version-suffix=-2.0.0beta1 make sudo make install everything ok no errors, but when I run lyx-2.0.0beta1, the spellchecker is not active. If I see the from the preference, it is grey (see the attachment) My lyx-1.6.7 works ok with the spellchecker. What was wrong my compilation? or how to make the spellchecker active? PS: I am in Ubuntu 10.04 Regards waluyo I confirm that the spellchecker is not activated by default. You are building LyX yourself and are using autotools (configure and make)? Did you read my answers to Waluyos message? What's the content of the file config.log? (grep for aspell and/or hunspell) Do you have the developer package for your spell checker software installed? It's not explicitly mentioned in INSTALL instructions... but you have to add the development packages for the spell checker tools to compile LyX with spell checker support. It's optional but enabled per default if found. Stephan OS: Linux Mint 9 Best regards, Emil
Re: Python2 issue
Am 12.11.2010 um 15:27 schrieb Pavel Sanda: Vincent van Ravesteijn wrote: can somebody on windows try the existence of python2 executable? No trace of it in neither 2.7 or 3.1.2 (but we supply Python ourselves in the windows installer). and mac people? Nope. Sorry... % which python /usr/bin/python % python --version Python 2.6.1 % which python2 % python2 -bash: python2: command not found % Stephan
Re: Spellchecker not active, command disable
Am 12.11.2010 um 07:43 schrieb Stephan Witt: Am 12.11.2010 um 00:33 schrieb Emil Pavlov: На 11.11.2010 10:18, Waluyo Adi Siswanto написа: I just compile lyx-2.0.0beta1 using the following commands: ./configure --with-version-suffix=-2.0.0beta1 make sudo make install everything ok no errors, but when I run lyx-2.0.0beta1, the spellchecker is not active. If I see the from the preference, it is grey (see the attachment) My lyx-1.6.7 works ok with the spellchecker. What was wrong my compilation? or how to make the spellchecker active? PS: I am in Ubuntu 10.04 Regards waluyo I confirm that the spellchecker is not activated by default. You are building LyX yourself and are using autotools (configure and make)? Did you read my answers to Waluyos message? What's the content of the file config.log? (grep for aspell and/or hunspell) Do you have the developer package for your spell checker software installed? It's not explicitly mentioned in INSTALL instructions... but you have to add the development packages for the spell checker tools to compile LyX with spell checker support. It's optional but enabled per default if found. Would this patch be appropriately? Stephan Index: INSTALL === --- INSTALL (Revision 36271) +++ INSTALL (Arbeitskopie) @@ -69,6 +69,13 @@ If, however, your version of Qt does not use fontconfig, then TeX fonts should be added to the font path. 'man xset' is your friend. +To build LyX with spell checking capabilities included you have to install +the development packages of one of the following libraries: +* aspell (http://aspell.net/) +* hunspell (http://hunspell.sourceforge.net/) +* enchant (http://www.abisource.com/projects/enchant/) + + * Other things to note If you make modifications to files in src/ (for example by applying a
Re: r36271 - lyx-devel/trunk/src/frontends/qt4/ui
Am 12.11.2010 um 21:55 schrieb sa...@lyx.org: Author: sanda Date: Fri Nov 12 21:55:33 2010 New Revision: 36271 URL: http://www.lyx.org/trac/changeset/36271 Log: Kill disabled items of advanced search, they won't be implemented any time soon. Modified: lyx-devel/trunk/src/frontends/qt4/ui/FindAndReplaceUi.ui /Users/stephan/cvs/lyx/lyx-devel/src/frontends/qt4/FindAndReplace.cpp: In member function ‘void lyx::frontend::FindAndReplaceWidget::findAndReplace(bool, bool)’: /Users/stephan/cvs/lyx/lyx-devel/src/frontends/qt4/FindAndReplace.cpp:463: error: ‘expandMacrosCB’ was not declared in this scope make[6]: *** [FindAndReplace.o] Error 1 Stephan
Re: [patch] Single Instance LyX
Am 13.11.2010 um 13:46 schrieb Jean-Marc Lasgouttes: Le 13 nov. 10 à 12:29, Enrico Forestieri a écrit : I don't know how that single instance enforcement is attained, but if that is true, you should not be able to launch a new instance of lyx by using the --no-remote switch. So, launch lyx a first time, then try to get a new instance using lyx --no-remote. Do you now have two different instances or not? Actually, when LyX is launched via its icon or by double clicking a document, the lyx binary is invoked with a special (-ss I think) argument pointing to the existing instance. The new file to load appears as a window system message. So, when launching LyX from the command line, your patch should do the right thing (tm). I tested it on Mac and it works as it should. With --no-remote a new instance is started. Otherwise the running LyX opens a new window. I'd say it's ok. Only rare corner cases - e. g. a stopped LyX instance - may be a problem now. Stephan
Re: r36200 - lyx-devel/trunk
Am 13.11.2010 um 22:30 schrieb Jean-Marc Lasgouttes: Le 08/11/2010 09:44, Stephan Witt a écrit : Why is that? Shall we do the same for all of LyX? We could use this version as included gettext. It's the requirement for gettext tools, AFAIK. Otherwise the build stops because of bugs in the tools. My work-around was denied with the argument encourage people to update. Do you remember? ;-) Sorry, I remember now. It is not funny to get old, you know! Yes, I know. I've to admit that you're a little bit right, too. My work-around patch was targeted for 1.6 and 2.0 includes it already. It was said to make both environments similar... what would you say? I think it's weird for a maintainer to have different build environments for branch and trunk. Now for 1.6 we have higher requirements than for 2.0. Stephan
Re: MacOS/CMake/Qt4.7 compilation report
Am 14.11.2010 um 12:44 schrieb Abdel Younes: On Nov 14, 2010, at 12:23 PM, Stephan Witt wrote: Am 14.11.2010 um 09:16 schrieb Abdel Younes: Hello, I am trying to use cmake on MacOS (10.6). I didn't on purpose read the Mac INSTALL/README in order to judge how easy it is to compile LyX under MacOS. So far, I am pleased. big kudoes to Peter/Kornel/Stefan/Bennett! Fine. Thanks for the kudos. Deserved. And sorry for misspelling your first name. No problem. Here is what I did: 1) install the latest Xcode 3.something, not so much for Xcode but because it brings in gcc and MacOS development libraries. One question here: before installing Xcode, did you have the svn command line tool, already? Or comes it with Xcode only? Perhaps you have tested this and can remember? Yes, it came with XCode. It was not there before. For the average user that may be a problem when it comes to version control with LyX. But that's out of the scope of LyX... 2) install Qt-4.7 from Nokia 3) install cmake from cmake web site cmake is in macports too. maybe it's good enough and easier to install - in terms of key strokes... 4) install MacPorts 5) update MacPorts: sudo port -v selfupdate 6) install gmake:sudo port -v selfupdate gmake makes a difference? I don't know but XCode didn't bring in make really? Hmm... I have it in /usr/bin. and MacPorts only offered GNU make (sudo install gmake) ... Now I am going to install Latex (any recommendation here?) MacTeX is the one I've installed here. I did not test any other. I installed that now; seems to work. But there is no update program, is there? Sorry, I don't know. I mean so that we are not forced to download the 1.6Gb package when you want to upgrade... Stephan
Re: 1.6.8 tarball uploaded
Am 14.11.2010 um 12:12 schrieb Jürgen Spitzmüller: I've uploaded a tarball here: ftp://ftp.devel.lyx.org/pub/lyx/devel/lyx-1.6.8.tar.gz Please give it a try! I did it. It looks like a good one, complete and compilable. The release build for Mac will be done by Bennett, I hope. Stephan
Re: MacOS native spellchecking bug
Am 14.11.2010 um 12:37 schrieb Abdel Younes: Hi Stephan, The first built I made enabled the native spellchecker, I didn't install other engine yet. I would like to report a bug, I am not sure this bug is only for MacOS with the native engine: 1) Open UserGuide.lyx 2) Copy the whole text of Section 1.1 3) Create a new Document and set the language to French 4) Paste the clipboard 5) Select the whole text and set the language to French in order to get rid of the foreign language underlining Result: many words are rightfully maked as misspelled but some of them are not: beautiful, poetry, etc 6) Righ-click on beautiful Result 1: the Add to personal dictionary item appears in the context menu Result 2: beautiful is now correctly marked as misspelled. This is the kind of problems that you have in programs such as Thunderbird or OpenOffice when you switch the language. I hope this is fixable. I will try now to install and compile with hunspell to see if I can reproduce. But I guess I will not because the bug is really in the native MacOS engine to which we send full paragraphs. Hunspell or Aspell should (I hope) not be affected because we spellcheck word by word. I tried it with aspell and more - but not all - words are marked as misspelled. And it's stable - in the sense of words being not misspelled on screen and when using the context menu it remaining correct. So it's better with aspell from the users POV. Stephan
Re: MacOS native spellchecking bug
Am 14.11.2010 um 13:17 schrieb Abdel Younes: On Nov 14, 2010, at 1:01 PM, Stephan Witt wrote: Am 14.11.2010 um 12:37 schrieb Abdel Younes: Hi Stephan, The first built I made enabled the native spellchecker, I didn't install other engine yet. I would like to report a bug, I am not sure this bug is only for MacOS with the native engine: 1) Open UserGuide.lyx 2) Copy the whole text of Section 1.1 3) Create a new Document and set the language to French 4) Paste the clipboard 5) Select the whole text and set the language to French in order to get rid of the foreign language underlining Result: many words are rightfully maked as misspelled but some of them are not: beautiful, poetry, etc 6) Righ-click on beautiful Result 1: the Add to personal dictionary item appears in the context menu Result 2: beautiful is now correctly marked as misspelled. This is the kind of problems that you have in programs such as Thunderbird or OpenOffice when you switch the language. I hope this is fixable. I will try now to install and compile with hunspell to see if I can reproduce. But I guess I will not because the bug is really in the native MacOS engine to which we send full paragraphs. Hunspell or Aspell should (I hope) not be affected because we spellcheck word by word. I tried it with aspell and more - but not all - words are marked as misspelled. And it's stable - in the sense of words being not misspelled on screen and when using the context menu it remaining correct. Some words are valid French words, that's why. have - ??? uses - ??? Maybe have is checked as hâve. But uses? Anyway, aspell is more accurate for now. Stephan
Re: [patch] Single Instance LyX
Am 13.11.2010 um 14:59 schrieb Enrico Forestieri: On Sat, Nov 13, 2010 at 01:57:54PM +0100, Stephan Witt wrote: Am 13.11.2010 um 13:46 schrieb Jean-Marc Lasgouttes: Le 13 nov. 10 à 12:29, Enrico Forestieri a écrit : I don't know how that single instance enforcement is attained, but if that is true, you should not be able to launch a new instance of lyx by using the --no-remote switch. So, launch lyx a first time, then try to get a new instance using lyx --no-remote. Do you now have two different instances or not? Actually, when LyX is launched via its icon or by double clicking a document, the lyx binary is invoked with a special (-ss I think) argument pointing to the existing instance. The new file to load appears as a window system message. So, when launching LyX from the command line, your patch should do the right thing (tm). I tested it on Mac and it works as it should. With --no-remote a new instance is started. Otherwise the running LyX opens a new window. I'd say it's ok. Only rare corner cases - e. g. a stopped LyX instance - may be a problem now. Maybe less than it would appear. If LyX crashed leaving behind a stale pipe, this is detected and no running instance is assumed to be present. Of course, if LyX did not crash but is somehow stalled, then we would have the problem that a document will never be opened, unless using the --no-remote switch or killing the stalled instance. This is the price to pay for this feature, I am sorry. Yes, I didn't want to search for problems. It was meant as a praise. Stephan
Re: OSX Problem
Am 15.11.2010 um 02:43 schrieb Richard Heck: I think I followed all the instructions for building svn on OSX, but on trying to start it I got the following: rgheck:/cvs/lyx-devel/trunksrc/lyx -userdir ~/lyxsvn Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/ or in the resources directory of your application bundle. Abort trap Anyone know what's wrong here? Same happens if I try to run the installed app. Which Qt do you use? It seems to be a Cocoa build... I never tried this route. This is on my TODO list. Stephan
Re: r36200 - lyx-devel/trunk
Am 14.11.2010 um 23:01 schrieb Jean-Marc Lasgouttes: Le 14/11/2010 00:07, Stephan Witt a écrit : Yes, I know. I've to admit that you're a little bit right, too. My work-around patch was targeted for 1.6 and 2.0 includes it already. It was said to make both environments similar... what would you say? I think it's weird for a maintainer to have different build environments for branch and trunk. Now for 1.6 we have higher requirements than for 2.0. I would not be against asking for a newer gettext version, but we have to make sure that it works on on windows. I do not remember what the constraints are there. OTOH, we can continue to distribute 0.16.1 in our sources (necessary for building) but tell mac users to use the tools from 0.18. That's a possibility. I would propose to remove the workaround from trunk. Me too. Should I do it? Another question regarding lyx's trac: I've changed the component of #7035 to version control. http://www.lyx.org/trac/ticket/7035 After that it's owned by nob...@lyx.org. Shouldn't it be some real person? Stephan
Re: compilation of lyx 2 beta 1 destroyed my linux
Am 15.11.2010 um 13:20 schrieb Gour: On Mon, 15 Nov 2010 04:15:39 -0800 (PST) Marcelo == Marcelo Acuña mv...@yahoo.com.ar wrote: Marcelo This morning I configured lyx beta 1 and start the compilation. Marcelo During the course of the compilation it appeared a message of Marcelo error: segment violation. It was trying to read the error Marcelo message when I noticed that the computer was hung. I reset it Marcelo and now, during the starting, shows an error as if it did not Marcelo have installed operating system. I have debian lenny 5.0.5, Marcelo for amd64. Did it eat your cat as well? More seriously... you have a hardware problem. Check your computer components, e. g. with a linux installation disc. I'd guess either the hard disk died or some main board component is malfunctioning. The latter may result in a corrupted hard disk... Nevertheless the subject line of your e-mail is funny. But I can understand that you are not happy about that. Stephan
Re: #7035: version tracking fails with error in running RCS ci
Am 15.11.2010 um 13:42 schrieb LyX Ticket Tracker: #7035: version tracking fails with error in running RCS ci -+-- Reporter: kuhn | Owner: nob...@… Type: defect | Status: new Priority: high | Milestone: 2.0.0 Component: version control | Version: 2.0.0svn Severity: major|Keywords: -+-- Changes (by sanda): * keywords: tracking = * priority: normal = high * severity: normal = major Old description: Created (registered) a version of a simple one-sentence lyx document. Tried to Check in Changes... After first entering a log message in the pop-up box, I received an error pop-up that says: Some problem occured while running the command: 'ci -q -u -m newfile1.lyx'. I have RCS version 5.7 installed on Ubuntu Jaunty Thanks New description: Created (registered) a version of a simple one-sentence lyx document. Tried to Check in Changes... After first entering a log message in the pop-up box, I received an error pop-up that says: Some problem occured while running the command: 'ci -q -u -m newfile1.lyx'. I have RCS version 5.7 installed on Ubuntu Jaunty Thanks -- Comment: it's not clear which LyX version was used by the ticket creator kuhn 1.6.6 Are you sure? The LyX-version in ticket is 2.0.0svn... (is it the default?) there seem to be more catches. if you have already created archive and try to commit 1.6.6 version it will collapse too... i will look later on this. For 2.0.0 I propose the attached patch to cure the buffer load/readonly problem. But maybe it has to be solved in another way. Vincent, can you have a look, please? Stephan Ticket URL: http://www.lyx.org/trac/ticket/7035#comment:3 Index: src/Buffer.cpp === --- src/Buffer.cpp (Revision 36303) +++ src/Buffer.cpp (Arbeitskopie) @@ -888,8 +888,8 @@ } d-file_fully_loaded = true; - d-read_only = !fname.isWritable(); - params().compressed = fname.isZippedFile(); + d-read_only = !d-filename.isWritable(); + params().compressed = d-filename.isZippedFile(); saveCheckSum(); return ReadSuccess; }
Re: #7035: version tracking fails with error in running RCS ci
Am 15.11.2010 um 14:00 schrieb Pavel Sanda: Stephan Witt wrote: it's not clear which LyX version was used by the ticket creator kuhn 1.6.6 Are you sure? The LyX-version in ticket is 2.0.0svn... (is it the default?) sorry, i meant the file is done in 1.6.6. the error is from 2.0.0 of course Ok, it seems so. But then the description of the ticket is very short. Too short. How comes that the file he checked in is 1.6.6 format? Perhaps the ticket creator can answer this and the questions I asked in ticket... Stephan
PATCH for ticket 7026
The attached patch for http://www.lyx.org/trac/ticket/7026 seems to be correct.
The only thing: I don't understand why it should crash with isdigit() instead
of iswdigit()...
Stephan
Index: src/support/lstrings.cpp
===
--- src/support/lstrings.cpp(Revision 36309)
+++ src/support/lstrings.cpp(Arbeitskopie)
@@ -323,9 +323,7 @@
docstring::const_iterator cit = str.begin();
docstring::const_iterator const end = str.end();
for (; cit != end; ++cit) {
- if (*cit == ' ')
- continue;
- if (isdigit((*cit)))
+ if (iswdigit((*cit)))
return true;
}
return false;
Re: PATCH for ticket 7026
Am 16.11.2010 um 09:53 schrieb Enrico Forestieri:
On Tue, Nov 16, 2010 at 07:56:55AM +0100, Stephan Witt wrote:
The attached patch for http://www.lyx.org/trac/ticket/7026 seems to be
correct.
Maybe yes, maybe not. isdigit(c) tests whether c is one of 0,1,2,...,9
while iswdigit(wc) tests whether wc is a wide-character code representing
a character of class digit in the program's current locale.
So, they both return true for 0,1,2,...,9 but iswdigit() returns true also
when isdigit() returns false.
Yes, the only use of hasDigit() is to test if a word contains digits.
The spell checker wants to ignore words with digits.
Therefor the isdigit() is wrong for digits not represented by ascii 0..9.
So, I tend to say that iswdigit() is more correct for this task.
Stephan
The only thing: I don't understand why it should crash with isdigit()
instead of iswdigit()...
That could be a platform/compiler related bug.
Index: src/support/lstrings.cpp
===
--- src/support/lstrings.cpp (Revision 36309)
+++ src/support/lstrings.cpp (Arbeitskopie)
@@ -323,9 +323,7 @@
docstring::const_iterator cit = str.begin();
docstring::const_iterator const end = str.end();
for (; cit != end; ++cit) {
-if (*cit == ' ')
-continue;
-if (isdigit((*cit)))
+if (iswdigit((*cit)))
return true;
}
return false;
--
Enrico
Re: PATCH for ticket 7026
Am 16.11.2010 um 11:52 schrieb Vincent van Ravesteijn:
On Tue, Nov 16, 2010 at 7:56 AM, Stephan Witt st.w...@gmx.net wrote:
The attached patch for http://www.lyx.org/trac/ticket/7026 seems to be
correct.
When I grep for isdigit I see the following sollution somewhere else
in the source:
diff --git a/src/support/lstrings.cpp b/src/support/lstrings.cpp
index ed2b9f9..2081fd6 100644
--- a/src/support/lstrings.cpp
+++ b/src/support/lstrings.cpp
@@ -325,7 +325,7 @@ bool hasDigit(docstring const str)
for (; cit != end; ++cit) {
if (*cit == ' ')
continue;
- if (isdigit((*cit)))
+ if (*cit 0x80 isdigit((*cit)))
return true;
}
return false;
This will work too I guess.
In the sense of avoid the crash...
The purpose of hasDigit() is to test for occurrences of digits to avoid spell
check of words with digits.
A docstring may very well contain digits coded outside the range of 0x00 ..
0x7F (ascii 0-9).
Unicode contains more numeral in different encodings.
Stephan
Re: autoconf 2.68 in branch
Am 17.11.2010 um 18:40 schrieb Enrico Forestieri: On Wed, Nov 17, 2010 at 04:21:49PM +0100, Jürgen Spitzmüller wrote: Enrico Forestieri wrote: Jürgen, may I apply the attached patch to allow autoconf 2.68? The change to libtool.m4 simply avoids the innocuous (in our case) warnings which are now issued by AC_LINK_IFELSE if the first argument is not conforming. See http://lists.gnu.org/archive/html/autoconf/2010-09/msg00069.html I tested it on solaris and it worked flawlessly. Please wait a bit until branch is open again (I'm waiting unil we have at least one win32 installer). No problem. The modifications to configure.ac triggered an autoreconfigure that bypassed my customized autogen.sh. Then, I was tired of the innocuous warnings and tried to avoid them. It's already almost a month that I am using 2.68 in branch without problems. Mee too... Stephan
Re: PATCH for ticket 7026
Am 16.11.2010 um 18:00 schrieb Enrico Forestieri: On Tue, Nov 16, 2010 at 01:16:38PM +0100, Vincent van Ravesteijn wrote: This will work too I guess. In the sense of avoid the crash... The purpose of hasDigit() is to test for occurrences of digits to avoid spell check of words with digits. A docstring may very well contain digits coded outside the range of 0x00 .. 0x7F (ascii 0-9). Unicode contains more numeral in different encodings. Stephan Are you sure that the numeric characters in other parts of the spectrum cannot occur in real words that need to be spellchecked. An example to prove that this can be the case is in Chinese: ??? means '3', but ?? means triangle. Ok, I don't know what iswdigit() returns for ???, and I guess that spellchecking for Chinese makes no sense, but you get the idea. It would be worse if there is some language in which such a numeric character occurs for example in 10% of all words (as some common ending or something), then 10% of the words is not spellchecked. It feels like we are trying to be smart, but I'd feel better if we then exactly know what we do and which words are not spellchecked and why. Besides, I read on this website:http://linux.about.com/library/cmd/blcmdl3_iswdigit.htm The wide character class digit always contains exactly the digits '0' to '9'., so I'm not sure whether it has any added value. I experimented a bit on solaris. Using the attached isdigit.c program I get the output in (the also attached) isdigit.out. As you can see, the output is incorrect outside the ascii range and the program segfaults, too. However, if I stick an #undef isdgit right after #include ctype.h, I get no crash and the correct result: $ ./isdigit 48 0x30 49 0x31 50 0x32 51 0x33 52 0x34 53 0x35 54 0x36 55 0x37 56 0x38 57 0x39 which is exactly the same as the output of the attached iswdgit.c program. So, using the macro version of isdigit() produces wrong results if the argument is not in the ascii range and also a crash. Using iswdigit() produces the same result as the function version of isdigit(). Moral: either we stick an #undef isdigit in our code or we switch to iswdigit(). However, in this case, some locale expert should clarify under what conditions the output of iswdigit() differs from that of isdigit(). I had to think about this further... 1. isdigit() is only one example for the problems with wchar_t. The same problem exists with isalnum() et. al. * isalnum() in output_xhtml.cpp, function cleanAttr(docstring const str) * or isalpha() in InsetRef::getFormattedCmd() 2. iswdigit() et. al. depends on the current locale. Shouldn't the locale depend on the document language? Then it would be iswdigit_l() etc... 3. in lstrings.cpp is a isDigit(char_type) implementation... There is some use of ucs4_to_qchar() and this again has a comment saying it's a hack. If it's correct to use isDigit() then hasDigit can use that. 4. Other numerals like 1/3 or roman numeral one thousand M etc. should be classified as digits as well. I don't know what the correct solution would be... I'd use neither the #undef isdigit nor the range check with less then 0x80. I'd use some iswctype() or iswctype_l() solution. And all uses of non-wchar_t ctype function for char_type arguments should be verified. Stephan
Re: r36363 - lyx-devel/trunk/src/frontends/qt4/ui
Am 18.11.2010 um 10:32 schrieb Enrico Forestieri: On Thu, Nov 18, 2010 at 07:39:12AM +0100, Stephan Witt wrote: Am 18.11.2010 um 05:32 schrieb uwesto...@lyx.org: Author: uwestoehr Date: Thu Nov 18 05:32:32 2010 New Revision: 36363 URL: http://www.lyx.org/trac/changeset/36363 Log: SpellcheckerUi.ui: set button policy to maximum because the Ignore buttons were much to large, depending on the size of LyX's main window Modified: lyx-devel/trunk/src/frontends/qt4/ui/SpellcheckerUi.ui Sorry, but you broke it. Is it any better after r36367? No, it's ok with r36369. Is it ok for other platforms too? Stephan
Re: #7035: version tracking fails with error in running RCS ci
Am 18.11.2010 um 12:43 schrieb Vincent van Ravesteijn: Vincent? Yes, it's on the radar. The fix is ok, it's exactly the same as the way we fixed it for lyxvc().file_found_hook. Now I started wondering what we should do if we load an emergency save and it appears that the original file is read-only. Then we don't want to make the loaded emergency save read-only as we cannot save it then (IIRC). You can save it then with changed name. The situation you describe is not impossible. But it should not happen by LyX - only with external tools. E. g. rcs checkin with command line after the emergency save or restore from some backup. If the file is read-only there should be no emergency save. If it's there something strange happened. The user should save the file with modified file name then. Stephan
Re: r36363 - lyx-devel/trunk/src/frontends/qt4/ui
Am 18.11.2010 um 11:43 schrieb Stephan Witt: Am 18.11.2010 um 10:32 schrieb Enrico Forestieri: On Thu, Nov 18, 2010 at 07:39:12AM +0100, Stephan Witt wrote: Am 18.11.2010 um 05:32 schrieb uwesto...@lyx.org: Author: uwestoehr Date: Thu Nov 18 05:32:32 2010 New Revision: 36363 URL: http://www.lyx.org/trac/changeset/36363 Log: SpellcheckerUi.ui: set button policy to maximum because the Ignore buttons were much to large, depending on the size of LyX's main window Modified: lyx-devel/trunk/src/frontends/qt4/ui/SpellcheckerUi.ui Sorry, but you broke it. Is it any better after r36367? No, it's ok with r36369. Is it ok for other platforms too? I tried it on linux... it seems it's back to the state at r36362. The culprit may be the vertical spacer and its interaction with the buttons. If the buttons are not stretchable they are moved into each other on Mac. If they are stretchable they are to tall on Linux (and on Windows?). I tried to make the spacer stretchable with the property sizePolicy... but it didn't work. :( I'm using Qt4.6.2 on Mac, will try 4.7 later... Stephan
Re: #7035: version tracking fails with error in running RCS ci
Am 18.11.2010 um 13:19 schrieb Pavel Sanda: Stephan Witt wrote: The situation you describe is not impossible. But it should not happen by LyX - only with external tools. E. g. rcs checkin with command line after the emergency save or restore from some backup. on the other hand when somebody starts to externally play with our files he should be able to recover himself also... if its easy to support such scenarios why not, but if it leads to some eeary code ;) That's what I did want to say. Stephan
Re: r36363 - lyx-devel/trunk/src/frontends/qt4/ui
Am 18.11.2010 um 12:53 schrieb Stephan Witt: Am 18.11.2010 um 11:43 schrieb Stephan Witt: Am 18.11.2010 um 10:32 schrieb Enrico Forestieri: On Thu, Nov 18, 2010 at 07:39:12AM +0100, Stephan Witt wrote: Am 18.11.2010 um 05:32 schrieb uwesto...@lyx.org: Author: uwestoehr Date: Thu Nov 18 05:32:32 2010 New Revision: 36363 URL: http://www.lyx.org/trac/changeset/36363 Log: SpellcheckerUi.ui: set button policy to maximum because the Ignore buttons were much to large, depending on the size of LyX's main window Modified: lyx-devel/trunk/src/frontends/qt4/ui/SpellcheckerUi.ui Sorry, but you broke it. Is it any better after r36367? No, it's ok with r36369. Is it ok for other platforms too? I tried it on linux... it seems it's back to the state at r36362. The culprit may be the vertical spacer and its interaction with the buttons. If the buttons are not stretchable they are moved into each other on Mac. If they are stretchable they are to tall on Linux (and on Windows?). I tried to make the spacer stretchable with the property sizePolicy... but it didn't work. :( I'm using Qt4.6.2 on Mac, will try 4.7 later... That didn't help. And I'd say that had to be expected. The (hopefully) correct layout is in r36373 now. The spacer widget was the problem indeed. Now it looks good on Mac and Linux. Windows LyX I cannot check... sorry. Stephan
Re: r36363 - lyx-devel/trunk/src/frontends/qt4/ui
Am 19.11.2010 um 03:01 schrieb Uwe Stöhr: In the next mail (to respect the list size limit of 50kB per mail) I'll attach is the ui-file that fixes the problem for me and also a screenshot with it. Here they are. Can you please give the ui-file a try and make a screenshot how it looks on MacOS and Linux? thanks and regards Uwe SpellcheckerUi.uiSpellChecker-fixed.png You didn't read my mails from yesterday 12:53 and 18:12? I've commit a working layout for Mac and Linux already. You replied to the old message. So I want to ask first if you can check the SVN state r36373 with windows. If not, I'll try your .ui file. Stephan PS. There was a ticket for Mac OS about bad dialog layout. I cannot find it anymore. I fixed it for Mac OS and introduced the problem you tried to solve. Your solution reverted my fix - that's why I said you broke it. I didn't expect the Qt-Layout widgets being platform dependent.
Re: #7043: Add to personal dictionary appears to do nothing
Am 19.11.2010 um 07:20 schrieb LyX Ticket Tracker: #7043: Add to personal dictionary appears to do nothing -+-- Reporter: quietbritishjim | Owner: lasgouttes Type: defect | Status: new Priority: normal | Milestone: 2.0.0 Component: spell| Version: 2.0.0svn Severity: normal |Keywords: -+-- Comment(by stwitt): The menu item Add to personal dictionary *is available* when the cursor is on a misspelled word. That's true for all spell checker interfaces - aspell, hunspell, enchant and apple native. The menu item Remove from personal dictionary is available only for learned words. Only the apple native interface has a method hasLearned(word), AFAIK. Aspell provides a method to enumerate the learned words. So it can be done manually. After implementing hasLearned() for aspell I tried to add the remove() implementation... and didn't find it in the aspell API. :( Ouch. One should never make assumptions... Google revealed this instead: http://old.nabble.com/Using-aspell-programmatically-td28445298.html == Re: Using aspell programmatically by Kevin Atkinson May 04, 2010; 11:29pm On Tue, 4 May 2010, John P. Hartmann wrote: On the programmatic front, I can add words to the dictionary by aspell_speller_add_to_personal. How do I remove a word from the dictionary? Sorry, this is currently unsupported. == Now, we're in trouble. Stephan
Re: r36363 - lyx-devel/trunk/src/frontends/qt4/ui
Am 19.11.2010 um 08:54 schrieb Enrico Forestieri: On Fri, Nov 19, 2010 at 07:36:54AM +0100, Stephan Witt wrote: I've commit a working layout for Mac and Linux already. Sorry Stephan, but I cannot confirm that your fix works. I tried Windows, Linux Debian, and Solaris. In all cases it is still broken. That's bad. Then I'll try the ui file Uwe sent. Stephan
Re: r36363 - lyx-devel/trunk/src/frontends/qt4/ui
Am 19.11.2010 um 09:15 schrieb Stephan Witt: Am 19.11.2010 um 08:54 schrieb Enrico Forestieri: On Fri, Nov 19, 2010 at 07:36:54AM +0100, Stephan Witt wrote: I've commit a working layout for Mac and Linux already. Sorry Stephan, but I cannot confirm that your fix works. I tried Windows, Linux Debian, and Solaris. In all cases it is still broken. That's bad. Then I'll try the ui file Uwe sent. ...and that's the result: it doesn't work on Mac. The svn revision 36363 and the new one Uwe sent have the same behavior. I'd say the layout management of Qt on Mac is sub-optimal here. :( Then we should revert to revision 36363 for now or use the version Uwe sent. I'll commit the revert to revision 36363. Uwe, you may commit your newest version if you like it more. I'll try to work with nested layouts later - perhaps that works. Stephan
Re: r36363 - lyx-devel/trunk/src/frontends/qt4/ui
Am 19.11.2010 um 14:52 schrieb Enrico Forestieri: On Fri, Nov 19, 2010 at 10:12:34AM +0100, Stephan Witt wrote: Am 19.11.2010 um 09:15 schrieb Stephan Witt: Am 19.11.2010 um 08:54 schrieb Enrico Forestieri: On Fri, Nov 19, 2010 at 07:36:54AM +0100, Stephan Witt wrote: I've commit a working layout for Mac and Linux already. Sorry Stephan, but I cannot confirm that your fix works. I tried Windows, Linux Debian, and Solaris. In all cases it is still broken. That's bad. Then I'll try the ui file Uwe sent. ...and that's the result: it doesn't work on Mac. The svn revision 36363 and the new one Uwe sent have the same behavior. I'd say the layout management of Qt on Mac is sub-optimal here. :( Then we should revert to revision 36363 for now or use the version Uwe sent. I'll commit the revert to revision 36363. Uwe, you may commit your newest version if you like it more. I'll try to work with nested layouts later - perhaps that works. Stephan, does the attached layout file work on Mac? No. Unfortunately not. :( Am 19.11.2010 um 16:48 schrieb Uwe Stöhr: You didn't read my mails from yesterday 12:53 and 18:12? I've commit a working layout for Mac and Linux already. You replied to the old message. So I want to ask first if you can check the SVN state r36373 with windows. I read your post before replying and the screenshot I sent was made with r36373. This I didn't know. I'm interested in a screenshot with the latest SVN showing how the broken dialog looks on MacOS. See attached. As it works on Windows and Linux, there must be a bug in the Qt ui-file handling and we should report that to Nokia and André to get this fixed in the next Qt 4.7.x release. Yes. I suspect a problem within Qt's layout mechanics on Mac OS X. When a vertical spacer with QSizePolicy::ExpandFlag is placed below the buttons, the buttons shrink too much. Stephan The screen shot made with revision 36398: inline: Bildschirmfoto 2010-11-19 um 17.40.35.png
Re: r36363 - lyx-devel/trunk/src/frontends/qt4/ui
Am 20.11.2010 um 00:44 schrieb Enrico Forestieri: On Fri, Nov 19, 2010 at 05:48:05PM +0100, Stephan Witt wrote: Am 19.11.2010 um 14:52 schrieb Enrico Forestieri: Stephan, does the attached layout file work on Mac? No. Unfortunately not. :( Hmm. Last attempt. What about the attached one? Again... the buttons are squeezed together. The same with the version I got from Edwin. Thank you too. I'm almost sure it's a Qt bug. Either the buttons are to lowly when asked how much vertical space they need or the vertical spacer is too aggressive... Stephan
Re: lyx2.0 modifies read-only files!
Am 22.11.2010 um 01:10 schrieb Vincent van Ravesteijn: Op 21-11-2010 22:07, Sebastian Guttenberg schreef: I have tested again, and the behavior has changed a bit. This time the read-only file was respected. Let me give you something reproducible. Just do the following steps: * start a new file and save it as test.lyx (don't close it) * open a terminal and change the file permissions to read-only: chmod a-w test.lyx * continue editing your file in lyx and save it. You won't have problems in doing so. If I open files that are read-only already before opening them with lyx, the behaviour depends on the lyx-version of the file: * read-only lyx1.6.5 files can be overwritten * read-only lyx2.0 files are marked as read-only and cannot be overwritten - Sebastian So, the only bug is that when LyX2.0 opens a LyX1.6.5 file, the read-only flag is not set correctly? This is the same problem as reported in bug http://www.lyx.org/trac/ticket/7035 and discussed in the following thread http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg163371.html. I will fix this. That would be nice. It would solve the version control bug. One thing I'm not sure is the change for the assignment of params().compressed in the patch I sent. The only reason why I adjusted it because I did want to be consistent. Perhaps you should omit it and fix the read-only state issue alone... Stephan
Re: r36430 - lyx-devel/trunk/src
Am 22.11.2010 um 12:50 schrieb Enrico Forestieri: On Mon, Nov 22, 2010 at 12:33:17PM +0100, Pavel Sanda wrote: Abdelrazak Younes wrote: On 11/22/2010 09:57 AM, you...@lyx.org wrote: Author: younes Date: Mon Nov 22 09:57:33 2010 New Revision: 36430 URL: http://www.lyx.org/trac/changeset/36430 Log: Work around bug #6920. This disables ligatures with involving 'f' character. Bennett, Stefan, please check that. its fixed here now. Juergen this problem is also in branch. I cannot reproduce this bug with any font (including DejaVu) on Linux, Windows and Solaris, with or without this patch. I verified that the ligatures are present at U+FB00-U+FB04, so it cannot be due to their presence or absence (tested with Qt 4.6.3 and 4.7.0). So, what triggers it? I don't know if you already have an answer. I think the surprising fact is - it has nothing to do with unicode ligatures. The problem is the too clever font rendering of Qt. Similar to the TeX engine. E. g. you typeset the word infinite. The fi ligature is rendered automatically if the font has the appropriate capabilities. Currently this happens only for rare circumstances. Abdel's solution is like a hard coded ligature-break. When fi is found LyX will render f and i instead. Abdel, I'm sorry to say that, but I don't think it's sufficient. This fi ligature is only one example. There are others, for sure. And Bennett presented another incarnation of this bug in his mail today. Please, correct me if I'm wrong... I understand, it's very hard to solve correctly. I guess, the text metrics machinery of LyX is not ready to handle that. Qt proposes the use of QTextLayout. In QFontMetrics::width() one can read: \warning This function will produce incorrect results for Arabic characters or non-spacing marks in the middle of a string, as the glyph shaping and positioning of marks that happens when processing strings cannot be taken into account. When implementing an interactive text control, use QTextLayout instead. Stephan
Re: r36430 - lyx-devel/trunk/src
Am 22.11.2010 um 09:58 schrieb Abdelrazak Younes: On 11/22/2010 09:57 AM, you...@lyx.org wrote: Author: younes Date: Mon Nov 22 09:57:33 2010 New Revision: 36430 URL: http://www.lyx.org/trac/changeset/36430 Log: Work around bug #6920. This disables ligatures with involving 'f' character. Bennett, Stefan, please check that. Regardless of my already mentioned concerns... I tried it and it works for infinite but not for fix. Stephan
Re: #7043: Add to personal dictionary appears to do nothing
Am 19.11.2010 um 08:49 schrieb Stephan Witt: Am 19.11.2010 um 07:20 schrieb LyX Ticket Tracker: #7043: Add to personal dictionary appears to do nothing -+-- Reporter: quietbritishjim | Owner: lasgouttes Type: defect | Status: new Priority: normal | Milestone: 2.0.0 Component: spell| Version: 2.0.0svn Severity: normal |Keywords: -+-- Comment(by stwitt): The menu item Add to personal dictionary *is available* when the cursor is on a misspelled word. That's true for all spell checker interfaces - aspell, hunspell, enchant and apple native. The menu item Remove from personal dictionary is available only for learned words. Only the apple native interface has a method hasLearned(word), AFAIK. Aspell provides a method to enumerate the learned words. So it can be done manually. After implementing hasLearned() for aspell I tried to add the remove() implementation... and didn't find it in the aspell API. :( Ouch. One should never make assumptions... Google revealed this instead: http://old.nabble.com/Using-aspell-programmatically-td28445298.html == Re: Using aspell programmatically by Kevin Atkinson May 04, 2010; 11:29pm On Tue, 4 May 2010, John P. Hartmann wrote: On the programmatic front, I can add words to the dictionary by aspell_speller_add_to_personal. How do I remove a word from the dictionary? Sorry, this is currently unsupported. == Now, we're in trouble. It took me a while to make the investigation about the status quo. Here it is: We have support for different spell checker backends. All of them are able to check words, of course. But the capabilities with personal word lists differs horrible. The following table presents the results of my investigation. Feature | aspell | native (mac) | enchant | hunspell check | + | +| + | + suggest | + | +| + | + accept | + | +| + | + insert | + | +| o (2) | o (3) ispersonal? | o (1) | +| - | - remove | - | +| + | - Legend: + feature is supported - feature is not supported o there are limitations: 1) aspell has the interface to enumerate the personal word list. So it's possible to implement, I have a patch for LyX at hand. 2) The versions below 1.6.0 are truncating the personal word list on open - effectively no personal word list available after restart. 3) There is no persistent state for personal word lists. When I implemented the LFUN_SPELLING_ADD for apples spell checker I introduced LFUN_SPELLING_REMOVE because it was possible there and it looks strange to have the possibility to add a word to a personal dictionary without the option to remove it later. Enchant manages it's own personal word lists. There is some rumor on the net already to consolidate the spelling for the whole desktop. https://wiki.ubuntu.com/ConsolidateSpellingLibs I don't know how long it would last to get some result. How to proceed? The options I see: 1) leave it as it is. Add to personal dictionary with all backends and remove only for apples native spell checker. 2) act like enchant and manage the personal word list in LyX, at least for aspell and hunspell. 3) remove support for aspell and hunspell. That sounds a little bit aggressive. Please, if someone has any hint or opinion - I'd like to hear it. Stephan
Re: #7043: Add to personal dictionary appears to do nothing
Am 23.11.2010 um 18:46 schrieb Jürgen Spitzmüller: Stephan Witt wrote: How to proceed? The options I see: 1) leave it as it is. Add to personal dictionary with all backends and remove only for apples native spell checker. This is fine with me. How would you rate the idea to manipulate aspell's personal word list (pwl) directly? That would perhaps bypass the missing remove feature and make aspell backend more usable. Do you know some external aspell tool to manage the pwl? 2) act like enchant and manage the personal word list in LyX, at least for aspell and hunspell. if it's not too much work. I'll think about it. Perhaps, this can be inspired by enchant somehow. 3) remove support for aspell and hunspell. That sounds a little bit aggressive. no way. Enchant is missing crucial features (most notably language variety support). Don't worry :-) I didn't want to do so. I forgot to mention: enchant is the only backend I cannot add to LyX on mac. It claims to be a library with minimal external dependencies and includes this: #include glib.h #include gmodule.h #include glib/gstdio.h Stephan
Re: no continuous spell check on beta1, but it works fine on svn
Am 25.11.2010 um 20:53 schrieb Jose Quesada: Hi, I can get no continuous spell check on beta1, but it works fine on svn. I have attached the output of the .configure command on both trees. Nothing that I can see points at lyx missing spelling libs on the beta1 (the diff seems fine). Any idea what could be wrong? The checkbox for continuous spell check is definitely on for both... That looks weird indeed. Which spell checker backend do you use? Is it the same when you change it? E. g. from aspell to hunspell... And there is a difference in compiler optimization flags. Can you try to configure with identical release build options? Both with --enable-build-type=development (or release or prerelease) Stephan
PATCH for GuiSpellchecker.cpp to simplify on_replacePB_clicked()
I cannot see why on_replacePB_clicked is so different from
on_replaceAllPB_clicked.
Does anybody have an explanation?
The attached patch would simplify on_replacePB_clicked a lot and works.
Stephan
Index: src/frontends/qt4/GuiSpellchecker.cpp
===
--- src/frontends/qt4/GuiSpellchecker.cpp (Revision 36542)
+++ src/frontends/qt4/GuiSpellchecker.cpp (Arbeitskopie)
@@ -214,20 +214,12 @@
void GuiSpellchecker::on_replacePB_clicked()
{
docstring const replacement =
qstring_to_ucs4(d-ui.replaceCO-currentText());
+ docstring const data = replace2string(
+ replacement, qstring_to_ucs4(d-ui.wordED-text()),
+ true, true, false, false);
LYXERR(Debug::GUI, Replace ( replacement ));
- /*
- Slight hack ahead: we want to use the dispatch machinery
- (see bug #6217), but self-insert honors the ``auto region
- delete'' setting, which is not wanted here. Creating a new
- ad-hoc LFUN seems overkill, but it could be an option (JMarc).
- */
- bool const ard = lyxrc.auto_region_delete;
- lyxrc.auto_region_delete = true;
- dispatch(FuncRequest(LFUN_SELF_INSERT, replacement));
- lyxrc.auto_region_delete = ard;
- // fix up the count
- --d-count_;
+ dispatch(FuncRequest(LFUN_WORD_REPLACE, data));
check();
}
Re: PATCH for GuiSpellchecker.cpp to simplify on_replacePB_clicked()
Am 27.11.2010 um 18:02 schrieb Jean-Marc Lasgouttes: Le 27/11/2010 16:05, Stephan Witt a écrit : I cannot see why on_replacePB_clicked is so different from on_replaceAllPB_clicked. Does anybody have an explanation? The attached patch would simplify on_replacePB_clicked a lot and works. I complicated an already existing code in order to be able to use dispatch, and it seems that I missed something. Are you sure the --count has to be dropped? I've tried both versions. At that time it seems to be correct. Now I'm not sure anymore. There is some miserable interaction with the different paths to check(). It happens from inside GuiSpellchecker::updateView() implicitly and explicitly from the ...clicked() callbacks. You can see this with ignore when at the last mistake: 1. the user hits ignore 2. LyX moves forward and triggers a check() via updateView() 3. this check reaches the end and reports the summary 4. back to ignore callback another check() is called and the summary report happens again. The first summary report presents another count as the second one. So, I'll have to investigate again. Stephan
Re: PATCH for GuiSpellchecker.cpp to simplify on_replacePB_clicked()
Am 27.11.2010 um 18:53 schrieb Stephan Witt:
Am 27.11.2010 um 18:02 schrieb Jean-Marc Lasgouttes:
Le 27/11/2010 16:05, Stephan Witt a écrit :
I cannot see why on_replacePB_clicked is so different from
on_replaceAllPB_clicked.
Does anybody have an explanation?
The attached patch would simplify on_replacePB_clicked a lot and works.
I complicated an already existing code in order to be able to use dispatch,
and it seems that I missed something.
Are you sure the --count has to be dropped?
I've tried both versions. At that time it seems to be correct.
Now I'm not sure anymore.
There is some miserable interaction with the different paths to check().
It happens from inside GuiSpellchecker::updateView() implicitly and
explicitly from the ...clicked() callbacks.
You can see this with ignore when at the last mistake:
1. the user hits ignore
2. LyX moves forward and triggers a check() via updateView()
3. this check reaches the end and reports the summary
4. back to ignore callback another check() is called and the summary report
happens again.
The first summary report presents another count as the second one.
So, I'll have to investigate again.
The result is the next patch:
1. start check in updateView only once
2. instead of count_ manipulation skip over replaced word
3. correct the absolute word count
Better?
Stephan
Index: src/frontends/qt4/GuiSpellchecker.cpp
===
--- src/frontends/qt4/GuiSpellchecker.cpp (Revision 36542)
+++ src/frontends/qt4/GuiSpellchecker.cpp (Arbeitskopie)
@@ -152,7 +152,7 @@
void GuiSpellchecker::updateView()
{
- if (hasFocus())
+ if (hasFocus() d-count_ == 0)
check();
}
@@ -214,20 +214,13 @@
void GuiSpellchecker::on_replacePB_clicked()
{
docstring const replacement =
qstring_to_ucs4(d-ui.replaceCO-currentText());
+ docstring const data = replace2string(
+ replacement, qstring_to_ucs4(d-ui.wordED-text()),
+ true, true, false, false);
LYXERR(Debug::GUI, Replace ( replacement ));
- /*
- Slight hack ahead: we want to use the dispatch machinery
- (see bug #6217), but self-insert honors the ``auto region
- delete'' setting, which is not wanted here. Creating a new
- ad-hoc LFUN seems overkill, but it could be an option (JMarc).
- */
- bool const ard = lyxrc.auto_region_delete;
- lyxrc.auto_region_delete = true;
- dispatch(FuncRequest(LFUN_SELF_INSERT, replacement));
- lyxrc.auto_region_delete = ard;
- // fix up the count
- --d-count_;
+ dispatch(FuncRequest(LFUN_WORD_REPLACE, data));
+ forward();
check();
}
@@ -307,6 +300,11 @@
showSummary();
return;
}
+
+ // current misspelled word has to be counted too.
+ ++d-count_;
+ ++d-progress_;
+
if (!isVisible())
show();
Re: PATCH for GuiSpellchecker.cpp to simplify on_replacePB_clicked()
Am 27.11.2010 um 19:49 schrieb Jean-Marc Lasgouttes: Le 27/11/2010 19:45, Stephan Witt a écrit : The result is the next patch: 1. start check in updateView only once 2. instead of count_ manipulation skip over replaced word 3. correct the absolute word count Better? I cannot tell. This code is very fragile (although better than in 1.6), only thorough testing is efficient. Hmm... in principle my tests succeed. I'd say it's better now. But I detected another bug: If the last word of the document is misspelled and one hit ignore the move forward is a noop and the misspelled word is checked again. And so on... How can I detect this situation reliable in ignore callback? In other words how can I tell if the given word is the last one? Stephan
Re: PATCH for GuiSpellchecker.cpp to simplify on_replacePB_clicked()
Am 27.11.2010 um 21:13 schrieb Stephan Witt: Am 27.11.2010 um 19:49 schrieb Jean-Marc Lasgouttes: Le 27/11/2010 19:45, Stephan Witt a écrit : The result is the next patch: 1. start check in updateView only once 2. instead of count_ manipulation skip over replaced word 3. correct the absolute word count Better? I cannot tell. This code is very fragile (although better than in 1.6), only thorough testing is efficient. Hmm... in principle my tests succeed. I'd say it's better now. BTW, it seems to fix #7087. http://www.lyx.org/trac/ticket/7087 Stephan
Re: PATCH for GuiSpellchecker.cpp to simplify on_replacePB_clicked()
Am 27.11.2010 um 21:13 schrieb Stephan Witt:
Am 27.11.2010 um 19:49 schrieb Jean-Marc Lasgouttes:
Le 27/11/2010 19:45, Stephan Witt a écrit :
The result is the next patch:
1. start check in updateView only once
2. instead of count_ manipulation skip over replaced word
3. correct the absolute word count
Better?
I cannot tell. This code is very fragile (although better than in 1.6),
only thorough testing is efficient.
I detected another bug:
If the last word of the document is misspelled and one hit ignore
the move forward is a noop and the misspelled word is checked again.
And so on...
How can I detect this situation reliable in ignore callback?
In other words how can I tell if the given word is the last one?
The last patch for today. :-)
I introduce another state member to detect the end of forward movement.
This solves the mentioned problem above.
Stephan
Index: src/frontends/qt4/GuiSpellchecker.cpp
===
--- src/frontends/qt4/GuiSpellchecker.cpp (Revision 36542)
+++ src/frontends/qt4/GuiSpellchecker.cpp (Arbeitskopie)
@@ -57,7 +57,7 @@
struct GuiSpellchecker::Private
{
- Private() : progress_(0), count_(0) {}
+ Private() : progress_(0), count_(0), stuck_(false) {}
Ui::SpellcheckerUi ui;
/// current word being checked and lang code
WordLangTuple word_;
@@ -66,6 +66,8 @@
int progress_;
/// word count
int count_;
+ /// flag for last move forward success
+ bool stuck_;
};
@@ -152,15 +154,18 @@
void GuiSpellchecker::updateView()
{
- if (hasFocus())
+ if (hasFocus() d-count_ == 0)
check();
}
void GuiSpellchecker::forward()
{
+ DocIterator from = bufferview()-cursor();
+
dispatch(FuncRequest(LFUN_ESCAPE));
dispatch(FuncRequest(LFUN_CHAR_FORWARD));
+ d-stuck_ = from == bufferview()-cursor();
}
@@ -214,20 +219,13 @@
void GuiSpellchecker::on_replacePB_clicked()
{
docstring const replacement =
qstring_to_ucs4(d-ui.replaceCO-currentText());
+ docstring const data = replace2string(
+ replacement, qstring_to_ucs4(d-ui.wordED-text()),
+ true, true, false, false);
LYXERR(Debug::GUI, Replace ( replacement ));
- /*
- Slight hack ahead: we want to use the dispatch machinery
- (see bug #6217), but self-insert honors the ``auto region
- delete'' setting, which is not wanted here. Creating a new
- ad-hoc LFUN seems overkill, but it could be an option (JMarc).
- */
- bool const ard = lyxrc.auto_region_delete;
- lyxrc.auto_region_delete = true;
- dispatch(FuncRequest(LFUN_SELF_INSERT, replacement));
- lyxrc.auto_region_delete = ard;
- // fix up the count
- --d-count_;
+ dispatch(FuncRequest(LFUN_WORD_REPLACE, data));
+ forward();
check();
}
@@ -239,6 +237,7 @@
qstring_to_ucs4(d-ui.wordED-text()),
true, true, true, true);
dispatch(FuncRequest(LFUN_WORD_REPLACE, data));
+ forward();
check(); // continue spellchecking
}
@@ -282,6 +281,13 @@
{
LYXERR(Debug::GUI, Check the spelling of a word);
+ // last move forward failed
+ if (d-stuck_) {
+ d-stuck_ = false;
+ showSummary();
+ return;
+ }
+
DocIterator from = bufferview()-cursor();
DocIterator to;
WordLangTuple word_lang;
@@ -307,6 +313,11 @@
showSummary();
return;
}
+
+ // current misspelled word has to be counted too.
+ ++d-count_;
+ ++d-progress_;
+
if (!isVisible())
show();
Re: no continuous spell check on beta1, but it works fine on svn
Am 29.11.2010 um 02:17 schrieb Jose Quesada: Hi Stefan, Running the beta1 code with --enable-build-type= development I get the attached output (lyx doesn't start). This happens because of the format change of the languages file. You have compiled the new parser code but not the new language file. It depends on your build setup how to solve that. I propose to start over: * a clean checkout * run ./autogen.sh and configure * compile and install You cannot use the beta1 install directory with svn binary and vice versa. I have both enchant and Aspell in the drop menu. I was using enchant when all this happened. Enchant is a wrapper to the real spell checker engine. I don't like it much, it's another level of obfuscation without any debug mechanism. Please try with aspell... Stephan Thanks, -jose On Thu, Nov 25, 2010 at 9:59 PM, Stephan Witt st.w...@gmx.net wrote: Am 25.11.2010 um 20:53 schrieb Jose Quesada: Hi, I can get no continuous spell check on beta1, but it works fine on svn. I have attached the output of the .configure command on both trees. Nothing that I can see points at lyx missing spelling libs on the beta1 (the diff seems fine). Any idea what could be wrong? The checkbox for continuous spell check is definitely on for both... That looks weird indeed. Which spell checker backend do you use? Is it the same when you change it? E. g. from aspell to hunspell... And there is a difference in compiler optimization flags. Can you try to configure with identical release build options? Both with --enable-build-type=development (or release or prerelease) Stephan -- Best, -Jose Jose Quesada, PhD. Research scientist, Max Planck Institute, Center for Adaptive Behavior and Cognition, Berlin http://www.josequesada.name/ http://twitter.com/Quesada dev-flag-out.txt
Re: LyX 2.0 - some bugs
Am 29.11.2010 um 04:26 schrieb Michal: On Sun, 28 Nov 2010 21:15:44 +0100 Pavel Sanda sa...@lyx.org wrote: [...] Michal, thanks for your feedback. you reported however too many bugs to deal with them directly in this list. please push them into bugzilla so we can deal each of them individually. I kind of hoped that at least some of the bugs are simple enough to disappear after just mentioning them :) Reporting 9 bugs on bugzilla seems like a time-consuming task, so I can't promise anything, but I'll try, probably in a few days. I don't want to be offending. But honestly, fixing bugs is a time-consuming task too. And I've not seen any bug disappearing by mentioning. Some bugs are resorting when the sun light is raising... ...but I've not heard of it about software bugs. :-) Stephan
Re: PATCH for GuiSpellchecker.cpp to simplify on_replacePB_clicked()
Am 27.11.2010 um 23:13 schrieb Stephan Witt: Am 27.11.2010 um 21:13 schrieb Stephan Witt: Am 27.11.2010 um 19:49 schrieb Jean-Marc Lasgouttes: Le 27/11/2010 19:45, Stephan Witt a écrit : The result is the next patch: 1. start check in updateView only once 2. instead of count_ manipulation skip over replaced word 3. correct the absolute word count Better? I cannot tell. This code is very fragile (although better than in 1.6), only thorough testing is efficient. I detected another bug: If the last word of the document is misspelled and one hit ignore the move forward is a noop and the misspelled word is checked again. And so on... How can I detect this situation reliable in ignore callback? In other words how can I tell if the given word is the last one? The last patch for today. :-) I introduce another state member to detect the end of forward movement. This solves the mentioned problem above. I did more tests and it works with normal text, table, floats and math environment. I'd like to commit this patch. Ok? While testing I found a problem with the function countWords() in buffer_funcs.cpp. It does not return the correct result when words in tables are to be counted. E. g. if I duplicate a row with three words the resulting word count is the same as without that row. Stephan
