Re: Obsolete LFUNs?
On Tue, 5 Sep 2006, Michael Gerz wrote: Lars Gullik Bjønnes schrieb: Andre Poenitz [EMAIL PROTECTED] writes: | I've never used it in LyX, but I do use 'xp' from time to time in vi. | I know a similar function exists in emacs so I suppose there are people | that 'need' it. No. It cannot go. Basic editing function. OK. How about the other LFUNs? Anything that can bite the dust? ? drop-layouts-choice- unused in the code Might that be the LFUN for dropping down the list of paragraph environments, i.e. used for a keyboard binding? ? menu-open - unused in the code Could it be for activating the menus via the keyboard? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: generating project files with cmake
Abdelrazak Younes wrote: Joost Verburg wrote: Peter Kümmel wrote: Peter Kümmel wrote: - controller().clearParams(); +// controller().clearParams(); Is also fixes my aspell crash The crash is fixed indeed, but there is still an endless message box loop. Hum... the call to dialog().CancelButton() seems superfluous in ControlSpellchecker::checkAlive(). That may well be the cause of your crash. Could you please try out this patch? If it works then it can easily be backported to 1.4. But I still don't understand why I don't see a crash... Make sure you really link against the new aspell libraries. Peter
Re: Obsolete LFUNs?
christian == christian ridderstrom [EMAIL PROTECTED] writes: christian On Tue, 5 Sep 2006, Michael Gerz wrote: Lars Gullik Bjønnes schrieb: Andre Poenitz [EMAIL PROTECTED] writes: | I've never used it in LyX, but I do use 'xp' from time to time in vi. | I know a similar function exists in emacs so I suppose there are people | that 'need' it. No. It cannot go. Basic editing function. OK. How about the other LFUNs? Anything that can bite the dust? ? drop-layouts-choice - unused in the code christian Might that be the LFUN for dropping down the list of christian paragraph environments, i.e. used for a keyboard binding? ? menu-open - unused in the code christian Could it be for activating the menus via the keyboard? Yes, both of these are used in bindings and should definitely be be kept. JMarc
Re: Obsolete LFUNs?
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Lars Gullik Bjønnes schrieb: Andre Poenitz [EMAIL PROTECTED] writes: | I've never used it in LyX, but I do use 'xp' from time to time in vi. | I know a similar function exists in emacs so I suppose there are people | that 'need' it. No. It cannot go. Basic editing function. Michael OK. How about the other LFUNs? Anything that can bite the Michael dust? Michael ? caption-insert - no effect ? This is related to the inactive caption inset. Keep it unless this code is removed. Michael drop-layouts-choice - unused in the code Used in bindings. Michael ? environment-insert - LyX crashes The environment inset is currently not used but it may be in the future. Keep it. Michael ? file-new - replaced by buffer-new? Allows to create a file be scripting file-new foo.lyx Michael ? html-insert - replaced by url-insert? No, both coexist. The real problem is that our url inset is a mess, but removing one lfun does not help. Michael ? menu-open - unused in the code Used in bindings. Michael ? inset-scroll - not implemented at all It could probably be removed: I am not sure we need it even if inset scrolling is reimplmented for math insets (which would be great). Michael ? message - no apparent effect Displays a message in minibuffer. Intended for scripting. Michael ? dialog-show-next-inset - not implemented Should be removed. JMarc
Re: [PATCH] Re-introduce layout menu
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Jean-Marc Lasgouttes schrieb: There is a reason for example why 'Toggle read only' was not there. This is a very specialized lfun which was added at someone's request; for the casual user, it will cause more puzzlement than anything. Michael This patch removes the Read-Only entry from the menu and Michael labels some menus consistently (inside the ui file!). If we are renaming the menus themselves, wouldn't it be better to *remove* the name of the enclosing menu everywhere, like document_update-update? But I would not disagree with this patch. JMarc
Re: trunk: lyx2lyx problem
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico On Tue, Sep 05, 2006 at 06:46:23PM +0200, Enrico Forestieri Enrico wrote: Anyway, if you want to take into account that someone could actually cross-compile to mingw using cygwin, the attached patch fixes this issue. Enrico No, please don't apply this patch as it would also affect a Enrico cygwin build. Both $host_os and $build_os should be checked Enrico and it really becomes cumbersome. Let's keep it as it is now, then. JMarc
Re: generating project files with cmake
Peter Kümmel wrote: Abdelrazak Younes wrote: Joost Verburg wrote: Peter Kümmel wrote: Peter Kümmel wrote: - controller().clearParams(); +// controller().clearParams(); Is also fixes my aspell crash The crash is fixed indeed, but there is still an endless message box loop. Hum... the call to dialog().CancelButton() seems superfluous in ControlSpellchecker::checkAlive(). That may well be the cause of your crash. Could you please try out this patch? If it works then it can easily be backported to 1.4. But I still don't understand why I don't see a crash... Make sure you really link against the new aspell libraries. I am sure. I've compiled myself the csv version with your patch... Abdel.
Re: generating project files with cmake
Abdelrazak Younes wrote: Peter Kümmel wrote: Abdelrazak Younes wrote: Joost Verburg wrote: Peter Kümmel wrote: Peter Kümmel wrote: - controller().clearParams(); +// controller().clearParams(); Is also fixes my aspell crash The crash is fixed indeed, but there is still an endless message box loop. Hum... the call to dialog().CancelButton() seems superfluous in ControlSpellchecker::checkAlive(). That may well be the cause of your crash. Could you please try out this patch? If it works then it can easily be backported to 1.4. But I still don't understand why I don't see a crash... Make sure you really link against the new aspell libraries. I am sure. I've compiled myself the csv version with your patch... Abdel. And the the linker doesn't find an old one? Could I check in this boost fix? Index: support/fs_extras.C === --- support/fs_extras.C (revision 14899) +++ support/fs_extras.C (working copy) @@ -166,7 +166,7 @@ filesystem_path_error( boost::filesystem::copy_file, source, target, - fs::detail::system_error_code(errno))); + fs::lookup_error_code(errno))); } #endif } -- Peter Kümmel
Re: generating project files with cmake
Peter Kümmel wrote: Abdelrazak Younes wrote: Peter Kümmel wrote: Abdelrazak Younes wrote: Joost Verburg wrote: Peter Kümmel wrote: Peter Kümmel wrote: - controller().clearParams(); +// controller().clearParams(); Is also fixes my aspell crash The crash is fixed indeed, but there is still an endless message box loop. Hum... the call to dialog().CancelButton() seems superfluous in ControlSpellchecker::checkAlive(). That may well be the cause of your crash. Could you please try out this patch? If it works then it can easily be backported to 1.4. But I still don't understand why I don't see a crash... Make sure you really link against the new aspell libraries. I am sure. I've compiled myself the csv version with your patch... Abdel. And the the linker doesn't find an old one? Not possible, I have done this only once with MSVC... Could I check in this boost fix? I guess so yes... Lars? Index: support/fs_extras.C === --- support/fs_extras.C (revision 14899) +++ support/fs_extras.C (working copy) @@ -166,7 +166,7 @@ filesystem_path_error( boost::filesystem::copy_file, source, target, - fs::detail::system_error_code(errno))); + fs::lookup_error_code(errno))); } #endif }
Ispell and pspell still supported in 1.4?
Jean-Marc? I think it would simplify the code if we get rid of them... Abdel.
Re: generating project files with cmake
Abdelrazak Younes [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | Abdelrazak Younes wrote: | Peter Kümmel wrote: | Abdelrazak Younes wrote: | Joost Verburg wrote: | Peter Kümmel wrote: | Peter Kümmel wrote: | - controller().clearParams(); | +// controller().clearParams(); | Is also fixes my aspell crash | The crash is fixed indeed, but there is still an endless message box | loop. | | Hum... the call to dialog().CancelButton() seems superfluous in | ControlSpellchecker::checkAlive(). That may well be the cause of your | crash. Could you please try out this patch? If it works then it can | easily be backported to 1.4. | | But I still don't understand why I don't see a crash... | Make sure you really link against the new aspell libraries. | I am sure. I've compiled myself the csv version with your patch... | | Abdel. | | | And the the linker doesn't find an old one? | | Not possible, I have done this only once with MSVC... | | Could I check in this boost fix? | | I guess so yes... Lars? Of course. Does fs::lookup_errno not work with windows? Is that why fs::lookup_error_code is used instead? -- Lgb
Re: Ispell and pspell still supported in 1.4?
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Jean-Marc? I think it would simplify the code if we get Abdelrazak rid of them... You mean removing them in 1.5, right? I think the spell checker clean-up should be done by selecting a proper library. JMarc
Re: generating project files with cmake
Lars Gullik Bjønnes wrote: Of course. Does fs::lookup_errno not work with windows? Is that why fs::lookup_error_code is used instead? Seems it has heen removed, (also the exception header is empty). -- Peter Kümmel
Re: Ispell and pspell still supported in 1.4?
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Jean-Marc? I think it would simplify the code if we get Abdelrazak rid of them... You mean removing them in 1.5, right? No, I mean 1.4. Just asking if anybody has ever tested 1.4 with pspell and ispell, that's all. I think the spell checker clean-up should be done by selecting a proper library. Agreed. JMarc
Re: Obsolete LFUNs?
Jean-Marc Lasgouttes schrieb: Michael ? caption-insert - no effect ? This is related to the inactive caption inset. Keep it unless this code is removed. Hmmm. Do you want me to keep the LFUN or to remove the complete code? Michael drop-layouts-choice - unused in the code Used in bindings. Good point! I totally overlooked this aspect! Michael ? inset-scroll - not implemented at all It could probably be removed: I am not sure we need it even if inset scrolling is reimplmented for math insets (which would be great). Ok. I will prepare a patch. Michael ? message - no apparent effect Displays a message in minibuffer. Intended for scripting. Ok. Michael ? dialog-show-next-inset - not implemented Should be removed. OK. Thank you very much for your excellent explanations! Michael
Re: Obsolete LFUNs?
Michael Gerz wrote: Thank you very much for your excellent explanations! maybe they should be added as a comment at an appropriate place in the code..?
Re: Obsolete LFUNs?
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Jean-Marc Lasgouttes schrieb: ? caption-insert - no effect ? This is related to the inactive caption inset. Keep it unless this code is removed. Michael Hmmm. Do you want me to keep the LFUN or to remove the Michael complete code? There are talks about actually using these insets (although I am not sure myself why the are useful), so I'd rather keep it. JMarc
Re: Ispell and pspell still supported in 1.4?
Abdelrazak Younes wrote: No, I mean 1.4. Just asking if anybody has ever tested 1.4 with pspell and ispell, that's all. Why? Leave 1.4 alone and do a proper cleanup in 1.5. We should not remove features (even if they are broken on some platforms) in the stable series. Georg
Re: Shared Libraries
Lars Gullik Bjønnes wrote: | I have started with frontend/qt4/ but give up because qt4 needs several | functions from the other libs. | We must start at the bottom not at the top, and qt4 is at the top. What platform are you trying to do this on? I've successfully build the controllers as shared lib under linux. It seems that on linux shared libraries are not so encapsulates as on windows. -- Peter Kümmel
Re: Ispell and pspell still supported in 1.4?
On Wed, Sep 06, 2006 at 11:48:27AM +0200, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Jean-Marc? I think it would simplify the code if we get Abdelrazak rid of them... You mean removing them in 1.5, right? No, I mean 1.4. Just asking if anybody has ever tested 1.4 with pspell and ispell, that's all. The Debian package has a bugreport about ispell problems. It seems to try to select the wrong dictionary for the enviroment. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265030 Sven -- If you won't forgive me the rest of my life Let me apologize while I'm still alive I know it's time to face all of my past mistakes [Less than Jake - Rest Of My Life]
compile error
On Windows/MinGW, I get the following error message: C:\msys\home\mg\lyx-trunk\src\buffer.C:116: error: `Path' is already declared in this scope Michael
Re: trunk: lyx2lyx problem
On Wed, Sep 06, 2006 at 10:08:04AM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico On Tue, Sep 05, 2006 at 06:46:23PM +0200, Enrico Forestieri Enrico wrote: Anyway, if you want to take into account that someone could actually cross-compile to mingw using cygwin, the attached patch fixes this issue. Enrico No, please don't apply this patch as it would also affect a Enrico cygwin build. Both $host_os and $build_os should be checked Enrico and it really becomes cumbersome. Let's keep it as it is now, then. Agreed. Cross-compiling LyX/Win from another platform is not going to work because of this MSYS_AC_CANONICAL_PATH thing, but this is not a big a problem, I think. -- Enrico
scons problem
Bo? scons: *** Source `C:\msys\home\michael\lyx-trunk\boost\libs\filesystem\src\convenience.cpp' not found, needed by target `debug\boost\filesystem\src\convenience.o'. Stop.
Re: Ispell and pspell still supported in 1.4?
On Wed, Sep 06, 2006 at 11:48:27AM +0200, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Jean-Marc? I think it would simplify the code if we get Abdelrazak rid of them... You mean removing them in 1.5, right? No, I mean 1.4. Just asking if anybody has ever tested 1.4 with pspell and ispell, that's all. LyX works ok with ispell. -- Enrico
Re: scons problem
Michael Gerz schrieb:
Bo?
scons: *** Source
`C:\msys\home\michael\lyx-trunk\boost\libs\filesystem\src\convenience.cpp'
not found, needed by target
`debug\boost\filesystem\src\convenience.o'. Stop.
This patch works. I will commit it in a minute...
Michael
Index: C:/msys/home/mg/lyx-trunk/development/scons/scons_manifest.py
===
--- C:/msys/home/mg/lyx-trunk/development/scons/scons_manifest.py
(revision 14911)
+++ C:/msys/home/mg/lyx-trunk/development/scons/scons_manifest.py
(working copy)
@@ -75,10 +75,10 @@
boost_libs_filesystem_src_files = Split('''
-convenience.cpp
exception.cpp
-operations_posix_windows.cpp
-path_posix_windows.cpp
+operations.cpp
+path.cpp
+portability.cpp
''')
Re: [PATCH] Re-introduce layout menu
Jean-Marc Lasgouttes schrieb: Michael This patch removes the Read-Only entry from the menu and Michael labels some menus consistently (inside the ui file!). If we are renaming the menus themselves, wouldn't it be better to *remove* the name of the enclosing menu everywhere, like document_update-update? But I would not disagree with this patch. Without the prefixes, we might run into name clashes. Therefore, I decided to keep the prefixes and committed the patch as it is. Michael
Re: Obsolete LFUNs?
Hi,
this patch removes two obsolete LFUNs. It seems that not much effort was
spent on their development (yes, I did a global 'grep').
I will commit later today, unless someone objects (JMarc already gave
his OK).
Michael
Index: src/LyXAction.C
===
--- src/LyXAction.C (revision 14911)
+++ src/LyXAction.C (working copy)
@@ -264,7 +264,6 @@
{ LFUN_SCREEN_RECENTER, screen-recenter, ReadOnly },
{ LFUN_SCREEN_UP, screen-up, ReadOnly | NoUpdate},
{ LFUN_SCREEN_UP_SELECT, screen-up-select, ReadOnly },
- { LFUN_INSET_SCROLL, inset-scroll, ReadOnly },
{ LFUN_SELF_INSERT, self-insert, SingleParUpdate },
{ LFUN_SPACE_INSERT, space-insert, Noop },
{ LFUN_SERVER_CHAR_AFTER, server-char-after, ReadOnly },
@@ -323,7 +322,6 @@
{ LFUN_ALL_CHANGES_REJECT, all-changes-reject, Noop },
{ LFUN_DIALOG_SHOW, dialog-show, NoBuffer },
{ LFUN_DIALOG_SHOW_NEW_INSET, dialog-show-new-inset, Noop },
- { LFUN_DIALOG_SHOW_NEXT_INSET, dialog-show-next-inset, Noop },
{ LFUN_DIALOG_UPDATE, dialog-update, NoBuffer },
{ LFUN_DIALOG_HIDE, dialog-hide, Noop },
{ LFUN_DIALOG_DISCONNECT_INSET, dialog-disconnect-inset, Noop
},
Index: src/lyxfunc.C
===
--- src/lyxfunc.C (revision 14911)
+++ src/lyxfunc.C (working copy)
@@ -589,7 +588,6 @@
case LFUN_SERVER_GET_NAME:
case LFUN_SERVER_NOTIFY:
case LFUN_SERVER_GOTO_FILE_ROW:
- case LFUN_DIALOG_SHOW_NEXT_INSET:
case LFUN_DIALOG_HIDE:
case LFUN_DIALOG_DISCONNECT_INSET:
case LFUN_BUFFER_CHILD_OPEN:
@@ -1235,9 +1233,6 @@
break;
}
- case LFUN_DIALOG_SHOW_NEXT_INSET:
- break;
-
case LFUN_DIALOG_UPDATE: {
string const name = argument;
// Can only update a dialog connected to an existing
inset
Index: src/lfuns.h
===
--- src/lfuns.h (revision 14911)
+++ src/lfuns.h (working copy)
@@ -269,104 +269,102 @@
LFUN_TABULAR_FEATURE, // Jug 2728
LFUN_LAYOUT_TABULAR,// Jug 2731
// 200
- LFUN_INSET_SCROLL, // Jug 2801
LFUN_BUFFER_UPDATE,// Dekel 2805
LFUN_INDEX_INSERT, // Angus 2803
LFUN_SCREEN_FONT_UPDATE,// ARRae 2813
LFUN_PARAGRAPH_GOTO,// Dekel 2826
- // 205
LFUN_REFERENCE_NEXT,// Dekel 20010114
+ // 205
LFUN_BOOKMARK_SAVE, // Dekel 20010127
LFUN_BOOKMARK_GOTO, // Dekel 20010127
LFUN_SELECT_FILE_SYNC, // Levon 20010214
LFUN_MESSAGE, // Lgb 20010408
- // 210
LFUN_CHARS_TRANSPOSE, // Lgb 20010425
+ // 210
LFUN_ESCAPE,// Lgb 20010517
LFUN_THESAURUS_ENTRY, // Levon 20010720
LFUN_TOOLTIPS_TOGGLE, // Angus 8 Mar 2002
LFUN_OPTIONAL_INSERT, // Martin 12 Aug 2002
- // 215
LFUN_MOUSE_PRESS, // André 9 Aug 2002
+ // 215
LFUN_MOUSE_MOTION, // André 9 Aug 2002
LFUN_MOUSE_RELEASE, // André 9 Aug 2002
LFUN_MOUSE_DOUBLE, // André 9 Aug 2002
LFUN_MOUSE_TRIPLE, // André 9 Aug 2002
- // 220
LFUN_WRAP_INSERT,// Dekel 7 Apr 2002
+ // 220
LFUN_CHANGES_TRACK, // Levon 20021001 (cool date !)
LFUN_CHANGES_MERGE, // Levon 20021016
LFUN_CHANGE_ACCEPT, // Levon 20021016
LFUN_CHANGE_REJECT, // Levon 20021016
- // 225
LFUN_ALL_CHANGES_ACCEPT,// Levon 20021016
+ // 225
LFUN_ALL_CHANGES_REJECT,// Levon 20021016
LFUN_BIBITEM_INSERT,// André 14 Feb 2003
LFUN_DIALOG_SHOW,
LFUN_DIALOG_SHOW_NEW_INSET,
- // 230
- LFUN_DIALOG_SHOW_NEXT_INSET,
LFUN_DIALOG_UPDATE,
+ // 230
LFUN_DIALOG_HIDE,
LFUN_DIALOG_DISCONNECT_INSET,
LFUN_INSET_APPLY,
- // 235
LFUN_INSET_INSERT,
LFUN_INSET_MODIFY,
+ // 235
LFUN_INSET_DIALOG_UPDATE,
LFUN_INSET_SETTINGS,
LFUN_PARAGRAPH_PARAMS_APPLY,
- // 240
LFUN_PARAGRAPH_UPDATE,
LFUN_EXTERNAL_EDIT,
+ // 240
LFUN_BRANCH_INSERT,
LFUN_BOX_INSERT,
LFUN_LINE_INSERT,
- // 245
LFUN_PAGEBREAK_INSERT,
LFUN_REPEAT,
+ // 245
Re: Ispell and pspell still supported in 1.4?
Enrico Forestieri wrote: On Wed, Sep 06, 2006 at 11:48:27AM +0200, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Jean-Marc? I think it would simplify the code if we get Abdelrazak rid of them... You mean removing them in 1.5, right? No, I mean 1.4. Just asking if anybody has ever tested 1.4 with pspell and ispell, that's all. LyX works ok with ispell. That's what I wanted to know, thanks. Abdel.
Re: Ispell and pspell still supported in 1.4?
Georg Baum wrote: Abdelrazak Younes wrote: No, I mean 1.4. Just asking if anybody has ever tested 1.4 with pspell and ispell, that's all. Why? Leave 1.4 alone and do a proper cleanup in 1.5. We should not remove features (even if they are broken on some platforms) in the stable series. Agreed. I was just wondering if they were really working. Abdel.
Re: generating project files with cmake
Abdelrazak Younes wrote: But I still don't understand why I don't see a crash... Make sure you really link against the new aspell libraries. I am sure. I've compiled myself the csv version with your patch... The crash happens after spell checking has completed. So first you will get the spell checker window and see all errors in the document. After the last error has been shown you get the crash. Joost
Re: generating project files with cmake
Joost Verburg wrote: Abdelrazak Younes wrote: But I still don't understand why I don't see a crash... Make sure you really link against the new aspell libraries. I am sure. I've compiled myself the csv version with your patch... The crash happens after spell checking has completed. So first you will get the spell checker window and see all errors in the document. After the last error has been shown you get the crash. Like I said, I don't see the crash... And I've passed through the debugger to verify that speller_ is never set to 0. Abdel.
Re: generating project files with cmake
Abdelrazak Younes wrote: Joost Verburg wrote: Abdelrazak Younes wrote: But I still don't understand why I don't see a crash... Make sure you really link against the new aspell libraries. I am sure. I've compiled myself the csv version with your patch... The crash happens after spell checking has completed. So first you will get the spell checker window and see all errors in the document. After the last error has been shown you get the crash. Like I said, I don't see the crash... And I've passed through the debugger to verify that speller_ is never set to 0. Abdel. One time I've added an assert to check for speller_!=0, then the crash was also gone, maybe there is somewhere a out-of-bound access - maybe in aspell. -- Peter Kümmel
Re: generating project files with cmake
Peter Kümmel wrote: Abdelrazak Younes wrote: Joost Verburg wrote: Abdelrazak Younes wrote: But I still don't understand why I don't see a crash... Make sure you really link against the new aspell libraries. I am sure. I've compiled myself the csv version with your patch... The crash happens after spell checking has completed. So first you will get the spell checker window and see all errors in the document. After the last error has been shown you get the crash. Like I said, I don't see the crash... And I've passed through the debugger to verify that speller_ is never set to 0. Abdel. One time I've added an assert to check for speller_!=0, (speller_.get() != 0) might be safer... then the crash was also gone, maybe there is somewhere a out-of-bound access - maybe in aspell. Yes, I think something like that is happening... Abdel.
Re: generating project files with cmake
Joost Verburg wrote:
Abdelrazak Younes wrote:
Hum... the call to dialog().CancelButton() seems superfluous in
ControlSpellchecker::checkAlive(). That may well be the cause of your
crash. Could you please try out this patch? If it works then it can
easily be backported to 1.4.
But I still don't understand why I don't see a crash...
This fixes the crash. However I now get an endless loop of The
spellchecker controller has been killed message boxes.
OK, let's use a hammer then.
This patch avoid the deletion of the Aspell object. If it works, it
could be adapted for 1.4 without any feature removal (that is pspell and
ispell). Then, the spellchecker code in trunk could use a lifting...
Abdel.
Index: aspell.C
===
--- aspell.C(revision 14911)
+++ aspell.C(working copy)
@@ -23,9 +23,18 @@
using std::string;
-ASpell::ASpell(BufferParams const , string const lang)
+ASpell::ASpell(string const lang)
: els(0), spell_error_object(0)
{
+ if (!lang.empty())
+ addSpeller(lang);
+}
+
+
+void ASpell::reset(string const lang)
+{
+ els = 0;
+ spell_error_object =0;
addSpeller(lang);
}
Index: aspell_local.h
===
--- aspell_local.h (revision 14911)
+++ aspell_local.h (working copy)
@@ -30,7 +30,7 @@
/**
* Initialise the spellchecker with the given buffer params and
language.
*/
- ASpell(BufferParams const params, std::string const lang);
+ ASpell(std::string const lang = );
virtual ~ASpell();
@@ -55,6 +55,9 @@
/// give an error message on messy exit
virtual std::string const error();
+ /// reset the spellchecker with the given language.
+ void reset(std::string const lang);
+
private:
/// add a speller of the given language
void addSpeller(std::string const lang);
Index: frontends/controllers/ControlSpellchecker.C
===
--- frontends/controllers/ControlSpellchecker.C (revision 14911)
+++ frontends/controllers/ControlSpellchecker.C (working copy)
@@ -56,7 +56,12 @@
ControlSpellchecker::ControlSpellchecker(Dialog parent)
: Dialog::Controller(parent), exitEarly_(false),
oldval_(0), newvalue_(0), count_(0)
-{}
+{
+#if defined(USE_ASPELL)
+ if (lyxrc.use_spell_lib)
+ speller_.reset(new ASpell);
+#endif
+}
ControlSpellchecker::~ControlSpellchecker()
@@ -71,11 +76,8 @@
? lyxrc.isp_alt_lang
: bp.language-code();
-#if defined(USE_ASPELL)
+#if defined(USE_PSPELL)
if (lyxrc.use_spell_lib)
- return new ASpell(bp, lang);
-#elif defined(USE_PSPELL)
- if (lyxrc.use_spell_lib)
return new PSpell(bp, lang);
#endif
@@ -96,7 +98,15 @@
{
lyxerr[Debug::GUI] Spellchecker::initialiseParams endl;
+#if defined(USE_ASPELL)
+ string lang = (lyxrc.isp_use_alt_lang)
+ ? lyxrc.isp_alt_lang
+ : kernel().buffer().params().language-code();
+ static_castASpell *(speller_.get())-reset(lang);
+#else
speller_.reset(getSpeller(kernel().buffer().params()));
+#endif
+
if (!speller_.get())
return false;
@@ -111,7 +121,9 @@
Alert::error(_(Spellchecker error),
_(The spellchecker could not be started\n)
+ speller_-error());
+#ifndef USE_ASPELL
speller_.reset(0);
+#endif
}
return success;
@@ -121,7 +133,9 @@
void ControlSpellchecker::clearParams()
{
lyxerr[Debug::GUI] Spellchecker::clearParams endl;
- speller_.reset(0);
+#ifndef USE_ASPELL
+ speller_.reset(0);
+#endif
}
@@ -260,9 +274,18 @@
bool ControlSpellchecker::checkAlive()
{
+ if (!speller_.get()) {
+ Alert::error(_(The spellchecker controller has been killed\n),
+ _(Looks like a bug, please contact [EMAIL
PROTECTED]));
+ dialog().CancelButton();
+ return false;
+ }
+
if (speller_-alive() speller_-error().empty())
return true;
+ dialog().CancelButton();
+
string message;
if (speller_-error().empty())
message = _(The spellchecker has died for some reason.\n
@@ -271,8 +294,6 @@
message = _(The spellchecker has failed.\n)
+ speller_-error();
- dialog().CancelButton();
-
Alert::error(_(The spellchecker has failed), message);
return false;
}
@@ -280,7 +301,10 @@
void ControlSpellchecker::showSummary()
{
- if (!checkAlive() || count_ == 0) {
+ if (!checkAlive())
+ return;
+
+ if (count_ == 0) {
Re: generating project files with cmake
Abdelrazak Younes wrote: Like I said, I don't see the crash... And I've passed through the debugger to verify that speller_ is never set to 0. Right, so it must be a buffer overflow somewhere. You also don't get a message box loop on your system? Joost
Re: generating project files with cmake
Abdelrazak Younes [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | Abdelrazak Younes wrote: | Joost Verburg wrote: | Abdelrazak Younes wrote: | But I still don't understand why I don't see a crash... | Make sure you really link against the new aspell libraries. | I am sure. I've compiled myself the csv version with your patch... | The crash happens after spell checking has completed. | | So first you will get the spell checker window and see all errors in | the document. After the last error has been shown you get the crash. | Like I said, I don't see the crash... And I've passed through the | debugger to verify that speller_ is never set to 0. | | Abdel. | | | One time I've added an assert to check for speller_!=0, | | (speller_.get() != 0) might be safer... huh? !speller_ should be more than good enough? -- Lgb
Re: generating project files with cmake
Joost Verburg wrote: Abdelrazak Younes wrote: Like I said, I don't see the crash... And I've passed through the debugger to verify that speller_ is never set to 0. Right, so it must be a buffer overflow somewhere. You also don't get a message box loop on your system? Nope... Abdel.
Re: generating project files with cmake
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Index: aspell.C
| ===
| --- aspell.C (revision 14911)
| +++ aspell.C (working copy)
| @@ -23,9 +23,18 @@
| using std::string;
|
|
| -ASpell::ASpell(BufferParams const , string const lang)
| +ASpell::ASpell(string const lang)
| : els(0), spell_error_object(0)
| {
| + if (!lang.empty())
| + addSpeller(lang);
| +}
| +
| +
| +void ASpell::reset(string const lang)
| +{
| + els = 0;
| + spell_error_object =0;
space after =
| Index: frontends/controllers/ControlSpellchecker.C
| ===
| --- frontends/controllers/ControlSpellchecker.C (revision 14911)
| +++ frontends/controllers/ControlSpellchecker.C (working copy)
| @@ -96,7 +98,15 @@
| {
| lyxerr[Debug::GUI] Spellchecker::initialiseParams endl;
|
| +#if defined(USE_ASPELL)
| + string lang = (lyxrc.isp_use_alt_lang)
| + ? lyxrc.isp_alt_lang
| + : kernel().buffer().params().language-code();
| + static_castASpell *(speller_.get())-reset(lang);
Perhaps speller_ should be changed to a shared_ptr, so that we can use
the nicer pointer_cast.
--
Lgb
Re: generating project files with cmake
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
space after =
OK.
| Index: frontends/controllers/ControlSpellchecker.C
| ===
| --- frontends/controllers/ControlSpellchecker.C (revision 14911)
| +++ frontends/controllers/ControlSpellchecker.C (working copy)
| @@ -96,7 +98,15 @@
| {
| lyxerr[Debug::GUI] Spellchecker::initialiseParams endl;
|
| +#if defined(USE_ASPELL)
| + string lang = (lyxrc.isp_use_alt_lang)
| + ? lyxrc.isp_alt_lang
| + : kernel().buffer().params().language-code();
| + static_castASpell *(speller_.get())-reset(lang);
Perhaps speller_ should be changed to a shared_ptr, so that we can use
the nicer pointer_cast.
For 1.4 you mean? For trunk, agreed.
Abdel.
Re: generating project files with cmake
Abdelrazak Younes wrote: OK, let's use a hammer then. This patch avoid the deletion of the Aspell object. If it works, it could be adapted for 1.4 without any feature removal (that is pspell and ispell). Then, the spellchecker code in trunk could use a lifting... This patch has the same result. No crash, but a message box loop after spell checking is finished. Joost
Re: Obsolete LFUNs?
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Hi, this patch removes two obsolete LFUNs. It seems that not Michael much effort was spent on their development (yes, I did a Michael global 'grep'). Actually, they have been incompletely removed, I think. JMarc
Re: Ispell and pspell still supported in 1.4?
On Wed, Sep 06, 2006 at 12:20:26PM +0200, Sven Hoexter wrote: The Debian package has a bugreport about ispell problems. It seems to try to select the wrong dictionary for the enviroment. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265030 I don't think this is a LyX bug. At least if you don't pretend that LyX should also take care of the external programs' configuration... I mean, if an english dictionary is asked for and an english dictionary doesn't exist, it is not a LyX fault. If an american dictionary exists and you are fine with using it as if it was an english dictionary, then it is not LyX responsibility to set up the symlinks necessary to use it in that way... -- Enrico
Re: generating project files with cmake
Joost Verburg wrote: Abdelrazak Younes wrote: OK, let's use a hammer then. This patch avoid the deletion of the Aspell object. If it works, it could be adapted for 1.4 without any feature removal (that is pspell and ispell). Then, the spellchecker code in trunk could use a lifting... This patch has the same result. No crash, but a message box loop after spell checking is finished. Shit... That's weird, I see that also when not launching in step by step debugging mode (with F5). But the behaviour is OK in debugging mode! Sorry Joost but I have to give up for now... Maybe we could use pspell instead for the next windows release? Abdel.
Re: Obsolete LFUNs?
Jean-Marc Lasgouttes wrote:
Michael == Michael Gerz
[EMAIL PROTECTED] writes:
Michael Jean-Marc Lasgouttes schrieb: ? caption-insert - no effect ?
This is related to the inactive caption inset. Keep it unless this
code is removed.
Michael Hmmm. Do you want me to keep the LFUN or to remove the
Michael complete code?
There are talks about actually using these insets (although I am not
sure myself why the are useful), so I'd rather keep it.
Agreed.
The current caption support is a hack, and I think it could be better done
with an inset.
InsetEnv was supposed to be used for any environment. This is of limited use
unless implemented in a very comfortable way, because you can easily use
\begin{xxx} and \end{xxx} as ERT, but maybe somebody has a good iedea how
to do that, si I'd keep it as well.
Note that both insets can be read and written in .lyx files, only the UI is
incomplete.
Georg
Re: scons problem
On 9/6/06, Michael Gerz [EMAIL PROTECTED] wrote:
This patch works. I will commit it in a minute...
boost_libs_filesystem_src_files = Split('''
-convenience.cpp
exception.cpp
-operations_posix_windows.cpp
-path_posix_windows.cpp
+operations.cpp
+path.cpp
+portability.cpp
''')
Thanks. Are these files new? (Has boost been upgraded?)
Bo
Re: generating project files with cmake
Abdelrazak Younes wrote: Shit... That's weird, I see that also when not launching in step by step debugging mode (with F5). But the behaviour is OK in debugging mode! What do you think is the cause of the problem? A buffer overflow in Aspell? Are there any tools available to locate it? Maybe we could use pspell instead for the next windows release? Aspell is the replacement of pspell. Pspell has been deprecated many years ago. Joost
Re: scons problem
Bo Peng wrote: Thanks. Are these files new? Yes. (Has boost been upgraded?) Yes. Announced several days ago, and done yesterday. Georg
Re: scons problem
Yes. Announced several days ago, and done yesterday. Does this mean system boost (1.33.1) is no longer usable? Bo
Re: scons problem
Bo Peng wrote: Yes. Announced several days ago, and done yesterday. Does this mean system boost (1.33.1) is no longer usable? It is still usable, but not officially and only with a small patch. This was btw the case already before the upgrade to 1.34, because we fixed a header inclusion problem in our copy of 1.33. 1.34 is now required because of the boost::bind related problems that gcc 4.1 has with older releases (or the problems older boost releases have with gcc), so an unpatched 1.33 should not be used with gcc 4.1 anyway. Georg
Re: generating project files with cmake
Joost Verburg wrote: Abdelrazak Younes wrote: Shit... That's weird, I see that also when not launching in step by step debugging mode (with F5). But the behaviour is OK in debugging mode! What do you think is the cause of the problem? I don't really know... A buffer overflow in Aspell? Or in LyX, don't know for sure. Are there any tools available to locate it? I've heard good things about valgrind. But it's linux only AFAIK. Maybe we could use pspell instead for the next windows release? Aspell is the replacement of pspell. Pspell has been deprecated many years ago. double shXXXt. Ispell then? The thing is that JMarc won't accept any substantial changes to 1.4. But maybe we could clean up the spellchecker code in trunk and then backport that to 1.4 as a new aspell only controller in parallel to the existing one. Maybe JMarc will accept a solution where we build this new controller only for windows and keep the old code for other platform. Abdel.
Re: generating project files with cmake
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Maybe we could use pspell instead for the next windows release? Aspell is the replacement of pspell. Pspell has been deprecated many years ago. Abdelrazak double shXXXt. Ispell then? Trying random spellcheckers until we find one that does not trigger our memory allocation problems does not smell good IMO. Abdelrazak The thing is that JMarc won't accept any substantial Abdelrazak changes to 1.4. But maybe we could clean up the Abdelrazak spellchecker code in trunk and then backport that to 1.4 Abdelrazak as a new aspell only controller in parallel to the Abdelrazak existing one. Maybe JMarc will accept a solution where we Abdelrazak build this new controller only for windows and keep the Abdelrazak old code for other platform. I am not very keen on that. What kind of cleanups do you have in mind? Why would they help? What I want in 1.4 is - well tested changes - well understood changes - as small as possible code modifications JMarc
Re: generating project files with cmake
Abdelrazak Younes wrote: Are there any tools available to locate it? I've heard good things about valgrind. But it's linux only AFAIK. Does anyone know of such a tool for Windows? double shXXXt. Ispell then? Ispell is even older and not available for Windows. Currently there is no option other than Aspell. If we are going to switch, we should go for Enchant. This is a library that makes it is possible to support Aspell/Pspell, Ispell, HunSpell, MySpell, Uspell, Hspell and Mac OS X Applespell. For a Windows release Hunspell is the best one, it's also used by OpenOffice.org and Abiword. Joost
Re: generating project files with cmake
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Maybe we could use pspell instead for the next windows release? Aspell is the replacement of pspell. Pspell has been deprecated many years ago. Abdelrazak double shXXXt. Ispell then? Trying random spellcheckers until we find one that does not trigger our memory allocation problems does not smell good IMO. I know but I am out of idea WRT to this problem and I have spent too much time on it already. Abdelrazak The thing is that JMarc won't accept any substantial Abdelrazak changes to 1.4. But maybe we could clean up the Abdelrazak spellchecker code in trunk and then backport that to 1.4 Abdelrazak as a new aspell only controller in parallel to the Abdelrazak existing one. Maybe JMarc will accept a solution where we Abdelrazak build this new controller only for windows and keep the Abdelrazak old code for other platform. I am not very keen on that. What kind of cleanups do you have in mind? Aspell only, no more checkAlive() because we use a library... Why would they help? By simplifying the workflow... right now, it's very difficult to follow what's going on WRT to the spellcker while debugging. The only way I am going to understand the work and data flow is by simplifying the code. What I want in 1.4 is - well tested changes - well understood changes - as small as possible code modifications I know and that's why I proposed to do this aside current work. Abdel.
Re: generating project files with cmake
Jean-Marc Lasgouttes wrote: Trying random spellcheckers until we find one that does not trigger our memory allocation problems does not smell good IMO. We don't know whether LyX or Aspell is the problem. Anyway the current combination triggers the crash. Could you try to run LyX/Aspell using Valgrind on a Linux system? Joost
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
[EMAIL PROTECTED] wrote: Author: kuemmel Date: Wed Sep 6 16:45:41 2006 New Revision: 14917 URL: http://www.lyx.org/trac/changeset/14917 Log: add #include lyxexport.h to the kernel headers You should maybe put this conditionally in config.h instead. This is way it would be included only if LYX_EXPORT is defined to something. Or do you really need them in the headers? Support function should not be used in headers I guess. Just an idea... Abdel.
Re: generating project files with cmake
Joost Verburg wrote: Abdelrazak Younes wrote: Are there any tools available to locate it? I've heard good things about valgrind. But it's linux only AFAIK. Does anyone know of such a tool for Windows? I once worked with purify, but that is some time ago. See http://www-306.ibm.com/software/awdtools/purifyplus/ If we are going to switch, we should go for Enchant. This is a library that makes it is possible to support Aspell/Pspell, Ispell, HunSpell, MySpell, Uspell, Hspell and Mac OS X Applespell. That has been suggested already long time ago. I don't think that it would be too difficult to add enchant as an additional spell checker, and if everything works drop the other ones. Georg
Re: generating project files with cmake
Joost Verburg wrote: Jean-Marc Lasgouttes wrote: Trying random spellcheckers until we find one that does not trigger our memory allocation problems does not smell good IMO. We don't know whether LyX or Aspell is the problem. Anyway the current combination triggers the crash. Could you try to run LyX/Aspell using Valgrind on a Linux system? LyX/Aspell-cvs may I precise... Abdel.
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Abdelrazak Younes [EMAIL PROTECTED] writes: | [EMAIL PROTECTED] wrote: | Author: kuemmel | Date: Wed Sep 6 16:45:41 2006 | New Revision: 14917 | URL: http://www.lyx.org/trac/changeset/14917 | Log: | add #include lyxexport.h to the kernel headers | | You should maybe put this conditionally in config.h instead. This is | way it would be included only if LYX_EXPORT is defined to something. | Or do you really need them in the headers? Support function should not | be used in headers I guess. | | Just an idea... Isn't it possible to use export lists instead of doing the (imho braindead) annotation on all functions? -- Lgb
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Lars Gullik Bjønnes wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: | [EMAIL PROTECTED] wrote: | Author: kuemmel | Date: Wed Sep 6 16:45:41 2006 | New Revision: 14917 | URL: http://www.lyx.org/trac/changeset/14917 | Log: | add #include lyxexport.h to the kernel headers | | You should maybe put this conditionally in config.h instead. This is | way it would be included only if LYX_EXPORT is defined to something. | Or do you really need them in the headers? Support function should not | be used in headers I guess. | | Just an idea... Isn't it possible to use export lists instead of doing the (imho braindead) annotation on all functions? Yes, it's possible, but I haven't done it on windows. And such a list must be updated on each change. -- Peter Kümmel
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Author: kuemmel Date: Wed Sep 6 16:45:41 2006 New Revision: 14917 URL: http://www.lyx.org/trac/changeset/14917 Log: add #include lyxexport.h to the kernel headers You should maybe put this conditionally in config.h instead. This is way it would be included only if LYX_EXPORT is defined to something. Or do you really need them in the headers? Support function should not be used in headers I guess. Just an idea... Abdel. I think I've seen some headers which don't include anything but I also need there the macros. Anyway it's all a little bit experimental, and cleaning up comes later. ATM I've a support.dll and a kernel.dll, insets fails because of BufferView Co which is not part of the kernel. The kernel files are all files which don't include frontends and which remains after I've removed files to fix linker errors, I'm happy that some left. -- Peter Kümmel
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Peter Kümmel [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | Abdelrazak Younes [EMAIL PROTECTED] writes: | | | [EMAIL PROTECTED] wrote: | | Author: kuemmel | | Date: Wed Sep 6 16:45:41 2006 | | New Revision: 14917 | | URL: http://www.lyx.org/trac/changeset/14917 | | Log: | | add #include lyxexport.h to the kernel headers | | | | You should maybe put this conditionally in config.h instead. This is | | way it would be included only if LYX_EXPORT is defined to something. | | Or do you really need them in the headers? Support function should not | | be used in headers I guess. | | | | Just an idea... | | Isn't it possible to use export lists instead of doing the (imho | braindead) annotation on all functions? | | | Yes, it's possible, but I haven't done it on windows. And such a list | must be updated on each change. Better to have one platform suffer than push the ugliness on all others. -- Lgb
Re: r14918 - in /lyx-devel/branches/personal/kuemmel/sharedli...
[EMAIL PROTECTED] writes: | Author: kuemmel | Date: Wed Sep 6 17:15:42 2006 | New Revision: 14918 | | URL: http://www.lyx.org/trac/changeset/14918 | Log: | add LYXKERNEL_EXPORT If you intend to get this merged into trunk, you have to explore other options... To have a microsoft brainfart force us to uglify the code on all other platforms is not really acceptable. -- Lgb
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Lars Gullik Bjønnes wrote: Better to have one platform suffer than push the ugliness on all others. Yes I know, the Linux guys don't like it. But at the moment I don't care about it. I just wanna see if it's possible to get Dlls without huge changes. -- Peter Kümmel
Re: generating project files with cmake
Abdelrazak Younes wrote: Could you try to run LyX/Aspell using Valgrind on a Linux system? LyX/Aspell-cvs may I precise... With Aspell 0.60.4 I get the same crash. Joost
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Peter Kümmel wrote: care about it. I just wanna see if it's possible to get Dlls without huge changes. Maybe the design of lyx is s bad that it is not possible. ;) -- Peter Kümmel
Re: generating project files with cmake
Joost == Joost Verburg [EMAIL PROTECTED] writes: Joost Abdelrazak Younes wrote: Could you try to run LyX/Aspell using Valgrind on a Linux system? LyX/Aspell-cvs may I precise... Joost With Aspell 0.60.4 I get the same crash. I have 0.50.5 here, and am not very keen to update it (since other stuff depends on it...). And I am a bit busy right now. Someone else? JMarc
Re: generating project files with cmake
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg That has been suggested already long time ago. I don't think Georg that it would be too difficult to add enchant as an additional Georg spell checker, and if everything works drop the other ones. For 1.5, it would be better to use only enchant directly and simplify our workflow. JMarc
Re: Ispell and pspell still supported in 1.4?
On Wed, Sep 06, 2006 at 03:45:49PM +0200, Enrico Forestieri wrote: On Wed, Sep 06, 2006 at 12:20:26PM +0200, Sven Hoexter wrote: The Debian package has a bugreport about ispell problems. It seems to try to select the wrong dictionary for the enviroment. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265030 I don't think this is a LyX bug. At least if you don't pretend that LyX should also take care of the external programs' configuration... I mean, if an english dictionary is asked for and an english dictionary doesn't exist, it is not a LyX fault. If an american dictionary exists and you are fine with using it as if it was an english dictionary, then it is not LyX responsibility to set up the symlinks necessary to use it in that way... I've not yet investigated this issue to say who to blame for this problem. At least I can reproduce it. Anyway I did not want to say anything about this bug. I just wanted to note that someone uses ispell and seems to care about problems with it. That's all. Sven -- If you won't forgive me the rest of my life Let me apologize while I'm still alive I know it's time to face all of my past mistakes [Less than Jake - Rest Of My Life]
Re: generating project files with cmake
On Wed, Sep 06, 2006 at 05:50:14PM +0200, Jean-Marc Lasgouttes wrote: Joost == Joost Verburg [EMAIL PROTECTED] writes: Joost Abdelrazak Younes wrote: Could you try to run LyX/Aspell using Valgrind on a Linux system? LyX/Aspell-cvs may I precise... Joost With Aspell 0.60.4 I get the same crash. I have 0.50.5 here, and am not very keen to update it (since other stuff depends on it...). And I am a bit busy right now. Someone else? FWIW I use an own compiled aspell 0.60.4 and I don't see any problem. I am using mingw, so perhaps MSVC is to be blamed on this? -- Enrico
Re: Ispell and pspell still supported in 1.4?
Am Mittwoch, 6. September 2006 18:28 schrieb Sven Hoexter: On Wed, Sep 06, 2006 at 03:45:49PM +0200, Enrico Forestieri wrote: On Wed, Sep 06, 2006 at 12:20:26PM +0200, Sven Hoexter wrote: The Debian package has a bugreport about ispell problems. It seems to try to select the wrong dictionary for the enviroment. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265030 I don't think this is a LyX bug. At least if you don't pretend that LyX should also take care of the external programs' configuration... I mean, if an english dictionary is asked for and an english dictionary doesn't exist, it is not a LyX fault. If an american dictionary exists and you are fine with using it as if it was an english dictionary, then it is not LyX responsibility to set up the symlinks necessary to use it in that way... I've not yet investigated this issue to say who to blame for this problem. At least I can reproduce it. Anyway I did not want to say anything about this bug. I just wanted to note that someone uses ispell and seems to care about problems with it. That's all. I agree with Enrico that in this particular case LyX is not to blame, but the problem is more general: LyX simply asks for a dictionary that is named after the document language and does not check at all whether that is a vlid dictionary name. That works well in many cases, but not in all, and I think we need a translation list LyX language name - dictionary name for all supported languages and dictionaries. Georg
Re: generating project files with cmake
On Wed, Sep 06, 2006 at 04:53:06PM +0200, Joost Verburg wrote: Ispell is even older and not available for Windows. Currently there is no option other than Aspell. This is not true. I have compiled both aspell and ispell on Windows and can select in LyX which speller should be used. -- Enrico
cygwin + 1.4.x broken?
Dear all, Has anyone tried cygwin + lyx.1.4.x recently? I am preparing for a cygwin submission. The compiled binary seems to have some locale problem since the screen display is messed up. Looks like the unicode problem has manifested itself to the branch. :-) Bo
Re: cygwin + 1.4.x broken?
The compiled binary seems to have some locale problem since the screen display is messed up. There is an error message: 'locale en_US could not be set. Bo
Re: cygwin + 1.4.x broken?
On Wed, Sep 06, 2006 at 11:55:43AM -0500, Bo Peng wrote: Dear all, Has anyone tried cygwin + lyx.1.4.x recently? I am preparing for a cygwin submission. The compiled binary seems to have some locale problem since the screen display is messed up. Looks like the unicode problem has manifested itself to the branch. :-) I have compiled a cygwin/X11 version no more than one month ago without any problem. I'll try to build it again and report back. -- Enrico
Re: cygwin + 1.4.x broken?
On Wed, Sep 06, 2006 at 12:01:25PM -0500, Bo Peng wrote:
The compiled binary seems to have some locale
problem since the screen display is messed up.
There is an error message: 'locale en_US could not be set.
This one can be safely ignored. There is no locale support with mingw
and cygwin. This is a patch that I apply to src/messages.C to avoid
that bogus warning:
--- src/messages.C.orig 2006-08-17 17:36:46.0 +0200
+++ src/messages.C 2006-09-06 19:16:44.0 +0200
@@ -126,10 +126,10 @@
#endif
// setlocale fails (returns NULL) if the corresponding locale
// is not installed.
- // On windows (mingw) it always returns NULL.
+ // On windows (mingw and cygwin) it always returns NULL.
// Since this method gets called for every translatable
// buffer string like e.g. Figure: we warn only once.
-#ifndef _WIN32
+#if !defined(_WIN32) !defined(__CYGWIN__)
static bool warned = false;
if (!warned !lc_msgs) {
warned = true;
--
Enrico
Re: Shared Libraries
On Tue, Sep 05, 2006 at 10:37:27AM +0200, Abdelrazak Younes wrote: That's exactly the problem indeed. My earlier cleanup work is heading toward the frontend use the kernel as a library design. Once this is achieved, splitting out the toolkit specific frontend should be easy. So clearly the first candidate for a new dll is the code in frontend/qt4/. Doesn't that contradict each other? Shouldn't there be a lyxkernel.dll and the frontend using this? The controller will need some cleanup before it could be split up. I still think merging the controller into the frontend specific code would make things a grest deal simpler, more flexible _and_ smaller, even when using two frontends... Andre'
Re: Let's do the same for dialogs! (was Re: [Patch] use enum instead of strings for type of math 'hull' inset)
On Tue, Sep 05, 2006 at 03:33:36PM +0200, Abdelrazak Younes wrote:
char const * const dialognames[] = {
aboutlyx, bibitem, bibtex, box, branch, changes,...
For this I'd actually prefer a factory that's initialized by static
singleton or such.
Could you elaborate a bit please?
The different dialogs are accessed with a string key. The key could as
well be an int without any difference in behaviour, that's what I mean.
The enum requires a place where all dialogs are known (at least
conceptionally) so that we can define an
enum { dialogFoo, dialogBar }
With a factory (in an ideal world...) we could (in theory...) have a
core completely ignorant of concrete dialogs. 'lfun-insert-inset foo'
would just ask the factory to create a dialog by a generator registered
under the name 'foo'.
Andre'
Re: Shared Libraries
On Tue, Sep 05, 2006 at 10:59:41AM +0200, Abdelrazak Younes wrote: Peter Kümmel wrote: At the current stage the code is full of dependencies, and some circular could only be solved by moving functions into a other library. I think you should forget about the controller for now and concentrated on the frontend. Mathed seems also to be a good candidate. Mathed depends on the core _and_ on the painert stuff, so how could that be a good candidate to start with? Andre'
Re: mathed naming
On Tue, Sep 05, 2006 at 12:23:34PM +0200, Jean-Marc Lasgouttes wrote:
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre I plan to do some cosmetic changes to mathed/*.
Andre (1) Rename MathSqrtInset to InsetSqrt (in line with insets/*)
Andre (2) Rename the files into InsetSqrt.{h,C} (3) put everything
Andre into namespace lyx
Andre Objections?
Well, since math insets are not really insets that can be used in the
rest of LyX, it may make more sense to only rename the ones that
derive from InsetOld (and maybe even move them to src/insets/ directory?)
With Inset unification being the big goal math insets are 'real' insets.
Concerning the namespace, lyx::mathed would look nice.
I have a strong aversion against nested namespaces. One ends up with
load of line noise outweighing any benefits. Putting everything in a
namespace, however, _has_ the advantage of shielding the outside world
from us and to a certain degree us from the outside world.
Andre'
Re: Shared Libraries
On Mon, Sep 04, 2006 at 09:28:33PM +0200, Peter Kümmel wrote: I've started to build shared libraries instead of static ones, because linking is so slow under windows. I only have successfully build the support library after some small file moving (from src to support). Then I've tried to do the same with controllers, but there are so much dependencies to the executable and to the frontend that I've given up. So my question: Which libraries could in principle be build as shared libraries? In the Windows sense of 'completely selfcontained'? None I suppose... Andre'
Re: Shared Libraries
On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote: I have started with frontend/qt4/ but give up because qt4 needs several functions from the other libs. We must start at the bottom not at the top, and qt4 is at the top. Exactly. The problem with the current architecture is, of, course, that drawing is 'pushed' by the kernel, not 'pulled' by the frontend (containing th painter) Andre'
Re: generating project files with cmake
Enrico Forestieri wrote: FWIW I use an own compiled aspell 0.60.4 and I don't see any problem. I am using mingw, so perhaps MSVC is to be blamed on this? As always with memory problems, it depends on the system environment whether the crash is triggered or not. Joost
Re: generating project files with cmake
Enrico Forestieri wrote: This is not true. I have compiled both aspell and ispell on Windows and can select in LyX which speller should be used. Aspell is better than Ispell, so moving to Ispell is not an option and may only hide the bug for a while. Joost
Re: generating project files with cmake
Joost Verburg schrieb: Abdelrazak Younes wrote: Shit... That's weird, I see that also when not launching in step by step debugging mode (with F5). But the behaviour is OK in debugging mode! What do you think is the cause of the problem? A buffer overflow in Aspell? Are there any tools available to locate it? Maybe we could use pspell instead for the next windows release? Hmmm actually I don't understand all the trouble. AFAICS, Aspell 0.60.4 works well with LyX 1.4.2. Why should the situation have changed for 1.4.3? If the problem is related to MSVC or, to be more precise, is uncovered by MSVC, why don't we stick with MinGW for 1.4.3 and sort out things for 1.4.4? IMHO there is no urgent needs to switch to MSVC now. MSVC may be smarter and faster than MinGW but does it really matter? LyX 1.4.3 + Aspell + Scons + MinGW (without MSYS) seems to work. Joost, I would suggest updating the installer first (drop MSYS). Just my 2 cents, Michael
Re: compile error
Michael Gerz schrieb: On Windows/MinGW, I get the following error message: C:\msys\home\mg\lyx-trunk\src\buffer.C:116: error: `Path' is already declared in this scope Am I the only one getting this problem??? Might be a boost update problem... Michael
Re: Shared Libraries
Andre Poenitz wrote: On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote: I have started with frontend/qt4/ but give up because qt4 needs several functions from the other libs. We must start at the bottom not at the top, and qt4 is at the top. Exactly. The problem with the current architecture is, of, course, that drawing is 'pushed' by the kernel, not 'pulled' by the frontend (containing th painter) Andre' Yes, building insets is completely hopeless. And this artifact was nicely hidden by the gcc. Why has lyx not a mvc design where the model nothing knows about the view but its base class? -- Peter Kümmel
Re: [Pkg-lyx-devel] Bug#265030: Ispell and pspell still supported in 1.4?
Georg Baum: I agree with Enrico that in this particular case LyX is not to blame, but the problem is more general: LyX simply asks for a dictionary that is named after the document language and does not check at all whether that is a vlid dictionary name. That works well in many cases, but not in all, and I think we need a translation list LyX language name - dictionary name for all supported languages and dictionaries. Note that the libaspell support works well, since it uses language codes (e.g. en_US, sv_SE) instead of language names (english, swedish). I'd be all for dropping ispell support in the LyX Debian package and just tell people to use aspell. -- Pelle
Re: [Pkg-lyx-devel] Bug#265030: Ispell and pspell still supported in 1.4?
Am Mittwoch, 6. September 2006 21:15 schrieb Per Olofsson: Note that the libaspell support works well, since it uses language codes (e.g. en_US, sv_SE) instead of language names (english, swedish). You are right, I thought that the ispell dictionary names were used for all spell checkers, but that is wrong. I'd be all for dropping ispell support in the LyX Debian package and just tell people to use aspell. For debian that makes sense, because we know that a usable aspell exists, for the generic source package I'd keep it. Georg
Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...
Peter Kümmel [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | care about it. I just wanna see if it's possible to get Dlls without | huge changes. | | Maybe the design of lyx is s bad that it is not possible. ;) Works without change on linux... -- Lgb
inset-dissolve
Hi Jürgen, inset-dissolve is still broken: If you open a new document, the function is enabled (which wrong) as you can see in the menu. If you want to dissolve the non-existent inset nevertheless, LyX crashes. Michael
Active table and math toolbar
Hello, I think this patch (or a similar one) has been discussed already. Should I commit it? BTW: bottom is ignored in 1.5.0svn/qt4. The tool bar is always displayed at the top. Should I add a bugzilla report? Michael Index: default.ui === --- default.ui(revision 14919) +++ default.ui(working copy) @@ -34,7 +34,7 @@ Toolbars standard on,top extra on,top -table off,bottom -math off,bottom +table table,bottom +math math,bottom minibuffer off,bottom End
Re: [PATCH] Re-introduce layout menu
Hi John, I reconsidered things. I agree with you that it doesn't make sense to change the default menu into something that is more like classic.ui (but not completely). The result is something that satisfies neither you nor me. Nevertheless, at some point in time, we should ask the LyX users (not the developers) what they would like to see as the default. Personally, I think that the traditional Windows/Word/OOo user prefers the classic look feel but that is left to be proven. Does anybody read the lyx users mailing list regularly? What did the old guys say about the new 1.4 menu structure? [1] for example: right mouse button context menu, tutorial, adaptive hints (tell the user how to do what they just did faster), toolbar... I know that there are very clever ways. But as long as they are not implemented, it is all nothing but a dream. Michael
Re: [PATCH] Re-introduce layout menu
John, JMarc, what do you think about the patch below? The idea is to have a submenu for character styles that combines layout-specific char styles, bold/emphasize/noun style, and the font dialog. The layout-specific char styles have been moved from menu Insert. Although the styles are actually implemented as insets, the user does not think in terms of inserting something. Bold/emphasize/noun style - whether you like it or not - are frequently requested features. There is at least one bugzilla report for re-adding bold to the menu. The font dialog is listed at the end (Other...) because users should not be encouraged to use it often. Regarding the word-* functions: We might move them to the submenu as well to shorten the Edit menu (as done in the patch). However, after testing word-capitalize, I really doubt that this particular functions is very useful (why do we have it at all?). Any comments? Michael Index: stdmenus.ui === --- stdmenus.ui(revision 14919) +++ stdmenus.ui(working copy) @@ -89,14 +89,10 @@ Separator Item Find Replace...|F dialog-show findreplace Separator -Item Word in Small Capitals word-capitalize -Item Word in Uppercase word-upcase -Item Word in Lowercase word-lowcase -Separator Item Move Paragraph Up|o paragraph-move-up Item Move Paragraph Down|v paragraph-move-down Separator -Item Text Style...|S dialog-show character +Submenu Character Style...|C insert_charstyles Item Paragraph Settings...|P layout-paragraph Separator # Mathed b0rkage means these don't work properly @@ -136,6 +132,19 @@ PasteRecent End +Menu insert_charstyles +CharStyles +Separator +Item Emphasize Style|E font-emph +Item Noun Style|N font-noun +Item Bold Style|B font-bold +Separator +Item Other...|O dialog-show character +Separator +Item Uppercase word-upcase +Item Lowercase word-lowcase +End + # not much we can do to help here Menu edit_tabular Item Multicolumn|M tabular-feature multicolumn @@ -253,7 +262,6 @@ # YUCK Submenu Note|N insert_note OptSubmenu Branch|B insert_branches -OptSubmenu Character Style|y insert_charstyles Submenu File|e insert_file Item Box box-insert Frameless Separator @@ -377,10 +385,6 @@ Branches End -Menu insert_charstyles -CharStyles -End - # # DOCUMENT MENU #
Re: inset-dissolve
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Hi Jürgen, inset-dissolve is still broken: If you open a new Michael document, the function is enabled (which wrong) as you can Michael see in the menu. If you want to dissolve the non-existent Michael inset nevertheless, LyX crashes. I am currently on a rewrite of this code. I'll try to send it tomorrow. JMarc
Re: cygwin + 1.4.x broken?
On Wed, Sep 06, 2006 at 11:55:43AM -0500, Bo Peng wrote: Has anyone tried cygwin + lyx.1.4.x recently? I am preparing for a cygwin submission. The compiled binary seems to have some locale problem since the screen display is messed up. Looks like the unicode problem has manifested itself to the branch. :-) I just compiled LyX/X11 using the system qt3 library and I don't see anything weird with the screen display. -- Enrico
Re: [PATCH] Re-introduce layout menu
On Wed, Sep 06, 2006 at 11:17:51PM +0200, Michael Gerz wrote: Nevertheless, at some point in time, we should ask the LyX users (not the developers) what they would like to see as the default. Personally, I think that the traditional Windows/Word/OOo user prefers the classic look feel but that is left to be proven. Does anybody read the lyx users mailing list regularly? What did the old guys say about the new 1.4 menu structure? What would be REALLY cool is some actual UI testing in a proper lab infrastructure. But slightly cool would be something that collected real-life data on menu use, and allowed us to collect it (modulo privacy concerns etc.) Asking a self-selecting population is notoriously tricky for getting meaningful answers. regards john
Re: Active table and math toolbar
On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote: I think this patch (or a similar one) has been discussed already. Should I commit it? This is a really difficult one to decide. I can see this being enormously irritating default behaviour for some people, and we don't yet have a View-Toolbars that can easily turn it off. On the other hand, these toolbars are extremely useful. Can you point me to the discussion? BTW: bottom is ignored in 1.5.0svn/qt4. The tool bar is always displayed at the top. Should I add a bugzilla report? Sounds broken yes regards john
Re: cygwin + 1.4.x broken?
It was a font problem. I downloaded all (4 or 5) of the font packages and it fixed it. But I think the most likely font package was x-org-x11-fscl which are the scaleable fonts. This assumes that the Cygwin environment is fresh rather than the same tested environment in which LyX worked for you before in Cygwin. (6.8.99.901-1 font version #) Thank you very much. I installed xorg-x11-fscl and the problem disappears. Bo
USE_CYGWIN_PACKAGING
Hi, All,
I plan to refine and apply the attached patch to 1.4.x. This patch
lets 'scons install' generate the right kind of cygwin binary package
(with /usr/doc/ ..., strip etc). To better reflect the uniqueness of
cygwin, I have added USE_CYGWIN_PACKAGING to src/support/package.C,
which basically says that cygwin has $HOME, and .exe suffix.
JMarc, what do you think about this macro? It is nice to have but it
is not absolutely needed since I can walk around it in SConstruct.
Some autotools changes may be needed.
Bo
Index: src/support/package.C.in
===
--- src/support/package.C.in (revision 14897)
+++ src/support/package.C.in (working copy)
@@ -35,9 +35,10 @@
#include utility
#if !defined (USE_WINDOWS_PACKAGING) \
+!defined (USE_CYGWIN_PACKAGING) \
!defined (USE_MACOSX_PACKAGING) \
!defined (USE_POSIX_PACKAGING)
-#error USE_FOO_PACKAGING must be defined for FOO = WINDOWS, MACOSX or POSIX.
+#error USE_FOO_PACKAGING must be defined for FOO = WINDOWS, CYGWIN, MACOSX or POSIX.
#endif
#if defined (USE_MACOSX_PACKAGING)
@@ -389,7 +390,7 @@
// Does the grunt work for abs_path_from_binary_name()
string const get_binary_path(string const exe)
{
-#if defined (USE_WINDOWS_PACKAGING)
+#if defined (USE_WINDOWS_PACKAGING) || defined (USE_CYGWIN_PACKAGING)
// The executable may have been invoked either with or
// without the .exe extension.
// Ensure that it is present.
@@ -628,7 +629,7 @@
return AddPath(reinterpret_castchar const *(store), PACKAGE);
-#else // USE_POSIX_PACKAGING
+#else // USE_POSIX_PACKAGING or USE_CYGWIN_PACKAGING
return AddPath(home_dir, string(.) + PACKAGE);
#endif
}
Index: development/scons/SConstruct
===
--- development/scons/SConstruct (revision 14897)
+++ development/scons/SConstruct (working copy)
@@ -54,6 +54,7 @@
# some global settings
#
package_version = '1.4.3svn'
+package_cygwin_version = '1.4.3svn-1'
boost_version = '1_32'
devel_version = True
@@ -91,7 +92,7 @@
default_frontend = 'qt2'
default_prefix = '/usr'
default_with_x = True
-default_packaging_method = 'posix'
+default_packaging_method = 'cygwin'
elif os.name == 'darwin':
platform_name = 'macosx'
default_frontend = 'qt2'
@@ -144,7 +145,7 @@
allowed_values = ('aspell', 'pspell', 'ispell', 'auto', 'no') ),
# packaging method
EnumOption('packaging', 'Packaging method to use.', default_packaging_method,
-allowed_values = ('windows', 'posix', 'macosx')),
+allowed_values = ('windows', 'posix', 'macosx', 'cygwin')),
#
BoolOption('fast_start', 'Whether or not use cached tests and keep current config.h', True),
# No precompiled header support (too troublesome to make it work for msvc)
@@ -397,14 +398,15 @@
share_dir = 'Resources'
man_dir = 'Resources/man/man1'
locale_dir = 'Resources/locale'
-default_prefix = 'c:/program files/lyx'
+elif packaging_method == 'cygwin':
+share_dir = 'share/lyx'
+man_dir = 'share/man/man1'
+locale_dir = 'share/locale'
else:
share_dir = 'share/lyx'
man_dir = 'man/man1'
locale_dir = 'share/locale'
-default_prefix = '/usr/local/'
-# install to default_prefix by default
# program suffix: can be yes, or a string
if env.has_key('version_suffix'):
if env['version_suffix'] in true_strings:
@@ -792,6 +794,14 @@
else:
env['MSGFMT'] = env_cache['MSGFMT']
+# cygwin packaging requires the binaries are stripped
+if packaging_method == 'cygwin':
+if not fast_start:
+env['STRIP'] = conf.CheckCommand('strip')
+env_cache['STRIP'] = env['STRIP']
+else:
+env['STRIP'] = env_cache['STRIP']
+
# check uic and moc commands for qt frontends
if not fast_start:
if frontend[:2] == 'qt' and (conf.CheckCommand('uic') == None \
@@ -2008,23 +2018,21 @@
else:
version_suffix = ''
#
-# install lyx
-target_name = os.path.split(str(lyx[0]))[1].replace('lyx', 'lyx%s' % version_suffix)
-target = os.path.join(bin_dest_dir, target_name)
-env.InstallAs(target, lyx)
-Alias('install', target)
-#
-# install tex2lyx
-target_name = os.path.split(str(tex2lyx[0]))[1].replace('tex2lyx', 'tex2lyx%s' % version_suffix)
-target = os.path.join(bin_dest_dir, target_name)
-env.InstallAs(target, tex2lyx)
-Alias('install', target)
-#
-# install lyxclient, may not exist
-if client != None:
-target_name = os.path.split(str(client[0]))[1].replace('client', 'client%s' % version_suffix)
+# install lyx, if in release mode, try to strip the binary
+if env['STRIP'] and mode != 'debug':
+# create a builder to strip and install
+env['BUILDERS']['StripInstallAs'] = Builder(action='$STRIP $SOURCE -o $TARGET')
+
+# install executables
+for (name, obj) in (('lyx', lyx), ('tex2lyx', tex2lyx), ('client',
Re: Obsolete LFUNs?
On Tue, 5 Sep 2006, Michael Gerz wrote: > Lars Gullik Bjønnes schrieb: > > Andre Poenitz > > <[EMAIL PROTECTED]> > > writes: > > > > | I've never used it in LyX, but I do use 'xp' from time to time in vi. > > | I know a similar function exists in emacs so I suppose there are people > > | that 'need' it. > > > > No. It cannot go. Basic editing function. > > > > > OK. How about the other LFUNs? Anything that can bite the dust? > ? drop-layouts-choice- unused in the code Might that be the LFUN for dropping down the list of paragraph environments, i.e. used for a keyboard binding? > ? menu-open - unused in the code Could it be for activating the menus via the keyboard? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
