Re: Backport of po/Makefile.in.in ok?

[Stephan Witt]

Am 10.10.2010 um 22:56 schrieb Jean-Marc Lasgouttes:

 Le 10 oct. 10 à 17:50, Jürgen Spitzmüller a écrit :
 Actually, I do not know enough of gettext to judge if this change would have
 unwanted side effects.
 
 I don't either...
 
 Since it is a workaround, I wonder if we can limit this fix to MacOSx only or
 upgrade gettext? But as I said, I do not understand this very well.
 
 The queston is not to upgrade gettext, because the bug is not in the version 
 that we ship
 (the translation code), but in the gettext utilities that people use. So 
 developpers should
 be advised to have a recent version of gettext on OS X.
 
 Personnally, I hav no problem with my 0.18.1 from macports.

How did you get it?
I tried port search gettext and got the answer 
gettext @0.17 (devel)
GNU gettext package

So I thought it's the current version.

 I would vote for removing the workaround in trunk and advise developers to 
 update their
 machine in the relevant INSTALL file (and maybe give the workaround of 
 overriding
 MESMERGE_UPDATE on the make command line). I dislike adding too much code for 
 working
 around bugs, because this code will stay, and I suspect that some people like 
 this backup thing.

I don't need the backup feature. But in principle you're right.

Stephan

Re: Backport of po/Makefile.in.in ok?

[BH]

On Mon, Oct 11, 2010 at 2:22 AM, Stephan Witt st.w...@gmx.net wrote:
 Am 10.10.2010 um 22:56 schrieb Jean-Marc Lasgouttes:
 Personnally, I hav no problem with my 0.18.1 from macports.

 How did you get it?
 I tried port search gettext and got the answer
 gettext @0.17 (devel)
    GNU gettext package

gettext 0.18.1.1 for me. (Have you tried port selfupdate?)

BH

Re: LyX Book (was Re: External Programs and Add-On Modules for LyX)

[Pavel Sanda]

Rob Oakes wrote:
  On 10/09/2010 02:22 PM, Pavel Sanda wrote:
  if you feel energy and enthusiasm about the idea contact Uwe, he is our 
  manuals master.
  i think lyx is mature enough to deserve its own printed bible... ;)
 I will do that.  Another interesting question might be:
 
 Should that bible be the same as the version as disseminated with LyX? 

considering the manpower we have i think it should be basically the manuals.
its very untrivial to keep our manuals up-to-date, and having two different
docs is unmaintainable.

 I don't know about you, but I've always felt that the very best bibles
 were those that had lavish illustrations and generous amounts of
 additional material.

okok, so lets dont call it bible and have more humble goal... :)
pave

Re: r35591 - lyx-devel/trunk/development

[Pavel Sanda]

uwesto...@lyx.org wrote:
 Author: uwestoehr
 Date: Mon Oct 11 03:11:51 2010
 New Revision: 35591
 URL: http://www.lyx.org/trac/changeset/35591
 
 Log:
 FORMAT: forgot this in last commit
 
 Modified:
lyx-devel/trunk/development/FORMAT
 
 Modified: lyx-devel/trunk/development/FORMAT
 ==
 --- lyx-devel/trunk/development/FORMATMon Oct 11 03:05:20 2010
 (r35590)
 +++ lyx-devel/trunk/development/FORMATMon Oct 11 03:11:51 2010
 (r35591)
 @@ -7,6 +7,11 @@
  
  ---
  
 +2010-10-11 Uwe Stöhr uwesto...@web.de
 + * Format incremented to 402: fix for bug 1881
 +   no new or removed parameter, only used to handle a LaTeX
 +   output issue

Uwe would it be possible to add few words what gymnastics is done with newpage 
inset?

 +
  2010-09-19 Ronen Abravanel ron...@gmail.com
   * Format incremented to 401: support for Feynman diagrams
 new math command \Diagram

Re: Backport of po/Makefile.in.in ok?

[Stephan Witt]

Am 11.10.2010 um 13:55 schrieb BH:

 On Mon, Oct 11, 2010 at 2:22 AM, Stephan Witt st.w...@gmx.net wrote:
 Am 10.10.2010 um 22:56 schrieb Jean-Marc Lasgouttes:
 Personnally, I hav no problem with my 0.18.1 from macports.
 
 How did you get it?
 I tried port search gettext and got the answer
 gettext @0.17 (devel)
GNU gettext package
 
 gettext 0.18.1.1 for me. (Have you tried port selfupdate?)

No. I'm not familiar with macport...
I thought that port search mentions the newest available version.
Then I'll do it this way.

Stephan

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

[Pavel Sanda]

Stephan Witt wrote:
 Can you please say if this would be ok for you. (1. Attachment - Patch 2)

generally looks fine.

 The backport of the CVS-backend changes would be the 2. Attachment - Patch 3.

i see you touch svn code which iirc was not altered in trunk. this is lefotver
or you mean it?

 Regarding the locking/edit/unedit/readonly issues I'm not so sure anymore how
 it should be moved to lyxvc. Are you sure it makes sense to force readonly
 checkouts with SVN? 

i only meant to move checkoutenabled there, not readonly checkouts.

 * SVN supports explicit lock operation - CVS not.
 * CVS supports readonly checkouts - SVN not.
 
 The CVS way is like SVN: it gives the user some freedom how to collaborate.
 Both support optimistic collaboration: every user may change a file and
 they have to resolve the merge conflicts afterwards. The other options though
 are different.
 
 With CVS you may add -r as global option - the checkout/commit operation
 makes the files readonly, with edit/unedit you start or rollback changing of
 your local copy. Additionally you may use watch to get notified when someone
 issues edit/unedit/commit of a file.
 
 With SVN (probably you know it better than me) you use lock/unlock to prevent
 others from changing the same file as you.

these locks are connected with readonly status of file. i wanted to make it 
similar
as it is in RCS. after checkout-rw. after checkin-ro. with subversion this is
connected with gaining lock which is sent to server so only one user is able to 
edit file.

it would be nice to let CVS follow such policy so all three backends are 
similar,
but maybe its not possible with CVS, dunno. it depends how you get notified - 
if there is specific command to query cvs server then we could query before 
checkout
and allow entering rw mode only in case its not edited by someone else.

 + doVCCommand(cvs update  + quoteName(owner_-filePath())
 + ++ quoteName(tmpf.toFilesystemEncoding()),
 + FileName(owner_-filePath()));

indent

pavel

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

[Stephan Witt]

Am 11.10.2010 um 17:29 schrieb Pavel Sanda:

 Stephan Witt wrote:
 Can you please say if this would be ok for you. (1. Attachment - Patch 2)
 
 generally looks fine.
 
 The backport of the CVS-backend changes would be the 2. Attachment - Patch 3.
 
 i see you touch svn code which iirc was not altered in trunk. this is lefotver
 or you mean it?

Oh, as I come along I thought: one should better check for the return status
of the svn diff command. And yes I forgot to do it like that in trunk.
Do you think it's a good idea to do it like that and change trunk accordingly?

 Regarding the locking/edit/unedit/readonly issues I'm not so sure anymore how
 it should be moved to lyxvc. Are you sure it makes sense to force readonly
 checkouts with SVN? 
 
 i only meant to move checkoutenabled there, not readonly checkouts.

You mean doing the test of readonly status for all VCS?

 * SVN supports explicit lock operation - CVS not.
 * CVS supports readonly checkouts - SVN not.
 
 The CVS way is like SVN: it gives the user some freedom how to collaborate.
 Both support optimistic collaboration: every user may change a file and
 they have to resolve the merge conflicts afterwards. The other options though
 are different.
 
 With CVS you may add -r as global option - the checkout/commit operation
 makes the files readonly, with edit/unedit you start or rollback changing of
 your local copy. Additionally you may use watch to get notified when someone
 issues edit/unedit/commit of a file.
 
 With SVN (probably you know it better than me) you use lock/unlock to prevent
 others from changing the same file as you.
 
 these locks are connected with readonly status of file. i wanted to make it 
 similar
 as it is in RCS. after checkout-rw. after checkin-ro. with subversion this 
 is
 connected with gaining lock which is sent to server so only one user is able 
 to edit file.

But that's not the general policy of SVN, isn't it? 
Wouldn't it be better to give the user some control over these details then?

 it would be nice to let CVS follow such policy so all three backends are 
 similar,
 but maybe its not possible with CVS, dunno. it depends how you get notified - 

You get a notification by e-mail. We don't use it. And we're working for a long 
time with
CVS in our company. We had rarely merge conflicts. They occur for sure when 
someone is
doing whitespace correction, the worst things happen when different 
development tools
are used. LyX is doing good here.

 if there is specific command to query cvs server then we could query before 
 checkout
 and allow entering rw mode only in case its not edited by someone else.

You may call cvs editors to check the list of current editors. But I wouldn't 
recommend
that. It doesn't work reliable. If one abandons his checkout - you are in 
trouble if he
forgot to do cvs unedit.

 +doVCCommand(cvs update  + quoteName(owner_-filePath())
 +++ quoteName(tmpf.toFilesystemEncoding()),
 +FileName(owner_-filePath()));
 
 indent

Ok.
Same as in SVN method :-)
I missed to correct it, indeed.

Stephan

Re: r35591 - lyx-devel/trunk/development

[Uwe Stöhr]

Am 11.10.2010 14:52, schrieb Pavel Sanda:


+   * Format incremented to 402: fix for bug 1881
+ no new or removed parameter, only used to handle a LaTeX
+ output issue


Uwe would it be possible to add few words what gymnastics is done with newpage 
inset?


newpage is not used in this commit.
I now documented what I have done in the bugreport of bug 1881. Is that 
enough info?


regards Uwe

LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

Hi,

I'm using SVN version from recent days, but this problem also accord in
older versions:

Sometime, when I'm right-clicking misspelled word with wiggly-red-line
beneath, and then choose the correct word from the context menu, LyX crash.
The output in the console is:

ro...@goon:~/dev/lyx/svn/lyx-devel$ ./src/lyx
/usr/include/c++/4.4/bits/basic_string.h:738: typename
_Alloc::rebind_CharT::other::reference std::basic_stringChar, Traits,
Alloc::operator[](typename _Alloc::rebind_CharT::other::size_type) [with
_CharT = wchar_t, _Traits = std::char_traitswchar_t, _Alloc =
std::allocatorwchar_t]: Assertion '__pos = size()' failed.
Aborted


I couldn't find any track ticket for this problem. Was I right?
What can I do in order to help specify the bug further?

Thanks,
Ronen

Re: #6920: Bug in typing a period (or comma) after the word fine.

[John Mac]

How do you enable / disable ligatures onscreen?


BYW, my OS is a MacOSX (Leopard).


On Mon, Oct 4, 2010 at 9:23 AM, LyX Ticket Tracker t...@lyx.org wrote:

 #6920: Bug in typing a period (or comma) after the word fine.

 --+-
  Reporter:  john3mac  |   Owner:  lasgouttes
 Type:  defect|  Status:  new
  Priority:  normal|   Milestone:  2.0.0
 Component:  general   | Version:
  Severity:  normal|Keywords:

 --+-
 Changes (by sanda):

  * keywords:  infoneeded =
  * milestone:  = 2.0.0


 Comment:

  ok at least its clear why does it show only on certain systems - those who
  have enabled ligatures onscreen.

 --
 Ticket URL: http://www.lyx.org/trac/ticket/6920#comment:5
 The LyX Project http://www.lyx.org/
 LyX -- The Document Processor

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

[Pavel Sanda]

Stephan Witt wrote:
  generally looks fine.
  
  The backport of the CVS-backend changes would be the 2. Attachment - Patch 
  3.
  
  i see you touch svn code which iirc was not altered in trunk. this is 
  lefotver
  or you mean it?
 
 Oh, as I come along I thought: one should better check for the return status
 of the svn diff command. And yes I forgot to do it like that in trunk.
 Do you think it's a good idea to do it like that and change trunk accordingly?

the code looks sane, but improvements belong rather to trunk. unless you are
fixing some real trouble i would like not touch svn code in branch.

  Regarding the locking/edit/unedit/readonly issues I'm not so sure anymore 
  how
  it should be moved to lyxvc. Are you sure it makes sense to force readonly
  checkouts with SVN? 
  
  i only meant to move checkoutenabled there, not readonly checkouts.
 
 You mean doing the test of readonly status for all VCS?

i have seen in the first patch you use function checkoutenabled again inside
cvs::checkout which we dont do anywhere else. i can see why you want it, but i
proposed to move this check into lyxvc::checkout. for svn case this does not
force readonly checkouts. (all this dicsussion is about trunk of course)

ehh, looking again on your patch, you use different way of readonly testing 
than we
do inside SVN(::isLocked). plain file_.isReadOnly makes much more problems
than 2s delay of menu launching ;)

  these locks are connected with readonly status of file. i wanted to make it 
  similar
  as it is in RCS. after checkout-rw. after checkin-ro. with subversion 
  this is
  connected with gaining lock which is sent to server so only one user is 
  able to edit file.
 
 But that's not the general policy of SVN, isn't it? 

it depends whether user pushed the button 'locking' in toolbar.
if no then no locking/readonly business is involved.

similarly i thought than when 'locking' would be toggled inside CVS mode
then you would move into this 'readonly checkout' style. but as i understand
this is determined when checkout is done, not that you control it later.(?)

i tried to describe all this in our manual if my explanations seem dark now ;)

  it would be nice to let CVS follow such policy so all three backends are 
  similar,
  but maybe its not possible with CVS, dunno. it depends how you get notified 
  - 
 
 You get a notification by e-mail.

so this is not usable for lyx.

 Same as in SVN method :-)

feel free to fix it there too :)

pavel

Re: r35591 - lyx-devel/trunk/development

[Pavel Sanda]

Uwe Stöhr wrote:
 Am 11.10.2010 14:52, schrieb Pavel Sanda:

 +   * Format incremented to 402: fix for bug 1881
 + no new or removed parameter, only used to handle a LaTeX
 + output issue

 Uwe would it be possible to add few words what gymnastics is done with 
 newpage inset?

 newpage is not used in this commit.
 I now documented what I have done in the bugreport of bug 1881. Is that 
 enough info?

well, i would expect that reading FORMAT file one immediately gets idea whats
being done and 'handle a LaTeX output issue' really doesnt say anything.
so i was asking for adding some sentence with which i can understand what
is literally changed inside .lyx file without need to crawl web or studying
commit history.

thanks,
pavel

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Pavel Sanda]

Ronen Abravanel wrote:
 What can I do in order to help specify the bug further?

1. to find a recipy how to reproduce (maybe hard)
2. at least to produce a backtrace http://wiki.lyx.org/FAQ/FurtherHelp#toc4

pavel

Re: #6920: Bug in typing a period (or comma) after the word fine.

[Pavel Sanda]

John Mac wrote:
 How do you enable / disable ligatures onscreen?

i dont think we can order qt for (not) doing this. but you can try to find some 
font
which is not intelligent enough (if you find it, then report back for other 
people...)

pavel

Branch warn

[Pavel Sanda]

i think this is relatively new

insets/ExternalTemplate.h: In constructor 'lyx::external::Template::Template()':
insets/ExternalTemplate.h:66: warning: 'lyx::external::Template::preview_mode' 
will be initialized after
insets/ExternalTemplate.h:64: warning:   'bool 
lyx::external::Template::automaticProduction'
insets/ExternalTemplate.cpp:52: warning:   when initialized here

Re: Branch warn

[Pavel Sanda]

Pavel Sanda wrote:
 i think this is relatively new
 
 insets/ExternalTemplate.h: In constructor 
 'lyx::external::Template::Template()':
 insets/ExternalTemplate.h:66: warning: 
 'lyx::external::Template::preview_mode' will be initialized after
 insets/ExternalTemplate.h:64: warning:   'bool 
 lyx::external::Template::automaticProduction'
 insets/ExternalTemplate.cpp:52: warning:   when initialized here

LayoutFile.cpp: In member function 'lyx::LayoutFileIndex 
lyx::LayoutFileList::addEmptyClass(const std::string)':
LayoutFile.cpp:230: warning: suggest explicit braces to avoid ambiguous 'else'

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

Starting program: /home/ronen/dev/lyx/svn/lyx-devel/src/lyx
[Thread debugging using libthread_db enabled]
/usr/include/c++/4.4/bits/basic_string.h:738: typename
_Alloc::rebind_CharT::other::reference std::basic_stringChar, Traits,
Alloc::operator[](typename _Alloc::rebind_CharT::other::size_type) [with
_CharT = wchar_t, _Traits = std::char_traitswchar_t, _Alloc =
std::allocatorwchar_t]: Assertion '__pos = size()' failed.

Program received signal SIGABRT, Aborted.
0x0012d422 in __kernel_vsyscall ()
(gdb) bt
#0  0x0012d422 in __kernel_vsyscall ()
#1  0x01139651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x0113ca82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x082686d0 in std::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t ::operator[](unsigned int) ()
#4  0x08252d4a in lyx::Paragraph::isWordSeparator (this=0x908f7b0, pos=24)
at Paragraph.cpp:2795
#5  0x08252f1d in lyx::Paragraph::locateWord (this=0x908f7b0,
fr...@0xbfff80e8, t...@0xbfff80dc, loc=lyx::WHOLE_WORD)
at Paragraph.cpp:3353
#6  0x08263242 in lyx::Paragraph::Private::rangeOfSpellCheck
(this=0x908f7b0)
at Paragraph.cpp:391
#7  lyx::Paragraph::spellCheck (this=0x908f7b0) at Paragraph.cpp:3632
#8  0x082d97c3 in lyx::TextMetrics::drawParagraph (this=0x909a614, pi=...,
pit=8, x=0, y=380) at TextMetrics.cpp:2135
#9  0x082da4fa in lyx::TextMetrics::draw (this=0x909a614, pi=..., x=0,
y=380)
at TextMetrics.cpp:2059
#10 0x0831a446 in lyx::BufferView::draw (this=0x90a0058, pain=...)
at BufferView.cpp:2696
#11 0x08636dab in lyx::frontend::GuiWorkArea::updateScreen (this=0x9099628)
at GuiWorkArea.cpp:1050
#12 0x0863beeb in lyx::frontend::GuiWorkArea::redraw (this=0x9099628,
update_metrics=false) at GuiWorkArea.cpp:439
---Type return to continue, or q return to quit---
#13 0x085d81d7 in lyx::frontend::WorkAreaManager::redrawAll (this=0x900e690,

update_metrics=10) at WorkAreaManager.cpp:37
#14 0x080bea2b in lyx::Buffer::changed (this=0x8fd8950, update_metrics=6)
at Buffer.cpp:461
#15 0x083215aa in lyx::BufferView::processUpdateFlags (this=0x90a0058,
flags=3)
at BufferView.cpp:468
#16 0x08398739 in replace (bv=0x90a0058, ev=..., has_deleted=false)
at lyxfind.cpp:250
#17 lyx::replace (bv=0x90a0058, ev=..., has_deleted=false) at
lyxfind.cpp:328
#18 0x083244a0 in lyx::BufferView::dispatch (this=0x90a0058, cmd=...,
dr=...)
at BufferView.cpp:1515
#19 0x085ed394 in lyx::frontend::GuiApplication::dispatch (this=0x8c512c0,
cmd=..., dr=...) at GuiApplication.cpp:1593
#20 0x085e5869 in lyx::frontend::GuiApplication::dispatch (this=0x8c512c0,
cmd=...) at GuiApplication.cpp:1096
#21 0x081f3c9d in lyx::dispatch (action=...) at LyX.cpp:1228
#22 0x0868ac87 in lyx::frontend::Action::action (this=0x9145c90)
at Action.cpp:66
#23 0x0868ad00 in lyx::frontend::Action::qt_metacall (this=0x9145c90,
_c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfffbdc8)
at moc_Action.cpp:77
#24 0x00eaac9a in QMetaObject::metacall(QObject*, QMetaObject::Call, int,
void**) () from /usr/lib/libQtCore.so.4
---Type return to continue, or q return to quit---
#25 0x00eb93d5 in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) () from /usr/lib/libQtCore.so.4
#26 0x003efbd9 in QAction::triggered(bool) () from /usr/lib/libQtGui.so.4
#27 0x003f1dcc in QAction::activate(QAction::ActionEvent) ()
   from /usr/lib/libQtGui.so.4
#28 0x0089560c in ?? () from /usr/lib/libQtGui.so.4
#29 0x0089babb in ?? () from /usr/lib/libQtGui.so.4
#30 0x0089cac7 in QMenu::mouseReleaseEvent(QMouseEvent*) ()
   from /usr/lib/libQtGui.so.4
#31 0x004547f8 in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4
#32 0x0089e0cc in QMenu::event(QEvent*) () from /usr/lib/libQtGui.so.4
#33 0x003f64dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/libQtGui.so.4
#34 0x003fd9f7 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libQtGui.so.4
#35 0x085de96f in lyx::frontend::GuiApplication::notify (this=0x8c512c0,
receiver=0x90fe2e8, event=0xbfffc5b0) at GuiApplication.cpp:2141
#36 0x00ea5a3b in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/libQtCore.so.4
#37 0x003fc952 in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointerQWidget, bool) ()
   from /usr/lib/libQtGui.so.4
#38 0x004885cf in ?? () from /usr/lib/libQtGui.so.4
---Type return to continue, or q return to quit---
#39 0x00487511 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/libQtGui.so.4
#40 0x004b660a in ?? () from /usr/lib/libQtGui.so.4
#41 0x001825e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#42 0x001862d8 in ?? () from /lib/libglib-2.0.so.0
#43 0x001864b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#44 0x00ed15d5 in
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
() from /usr/lib/libQtCore.so.4
#45 0x004b6135 in ?? () from /usr/lib/libQtGui.so.4
#46 0x00ea4059 in

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Stephan Witt]

Am 12.10.2010 um 03:16 schrieb Ronen Abravanel:

 Starting program: /home/ronen/dev/lyx/svn/lyx-devel/src/lyx 
 [Thread debugging using libthread_db enabled]
 /usr/include/c++/4.4/bits/basic_string.h:738: typename 
 _Alloc::rebind_CharT::other::reference std::basic_stringChar, Traits, 
 Alloc::operator[](typename _Alloc::rebind_CharT::other::size_type) [with 
 _CharT = wchar_t, _Traits = std::char_traitswchar_t, _Alloc = 
 std::allocatorwchar_t]: Assertion '__pos = size()' failed.
 
 Program received signal SIGABRT, Aborted.
 0x0012d422 in __kernel_vsyscall ()
 (gdb) bt
 #0  0x0012d422 in __kernel_vsyscall ()
 #1  0x01139651 in raise () from /lib/tls/i686/cmov/libc.so.6
 #2  0x0113ca82 in abort () from /lib/tls/i686/cmov/libc.so.6
 #3  0x082686d0 in std::basic_stringwchar_t, std::char_traitswchar_t, 
 std::allocatorwchar_t ::operator[](unsigned int) ()
 #4  0x08252d4a in lyx::Paragraph::isWordSeparator (this=0x908f7b0, pos=24)
 at Paragraph.cpp:2795
 #5  0x08252f1d in lyx::Paragraph::locateWord (this=0x908f7b0, 
 fr...@0xbfff80e8, t...@0xbfff80dc, loc=lyx::WHOLE_WORD)
 at Paragraph.cpp:3353
 #6  0x08263242 in lyx::Paragraph::Private::rangeOfSpellCheck (this=0x908f7b0)
 at Paragraph.cpp:391
 #7  lyx::Paragraph::spellCheck (this=0x908f7b0) at Paragraph.cpp:3632

Hi Ronen,

thank you for doing the backtrace.
Can you please give me some details?
You're using SVN current trunk code?
What are you doing to get the crash?

Stephan

Re: Backport of po/Makefile.in.in ok?

[Stephan Witt]

Am 10.10.2010 um 22:56 schrieb Jean-Marc Lasgouttes:

> Le 10 oct. 10 à 17:50, Jürgen Spitzmüller a écrit :
>> Actually, I do not know enough of gettext to judge if this change would have
>> unwanted side effects.
> 
> I don't either...
> 
>> Since it is a workaround, I wonder if we can limit this fix to MacOSx only or
>> upgrade gettext? But as I said, I do not understand this very well.
> 
> The queston is not to upgrade gettext, because the bug is not in the version 
> that we ship
> (the translation code), but in the gettext utilities that people use. So 
> developpers should
> be advised to have a recent version of gettext on OS X.
> 
> Personnally, I hav no problem with my 0.18.1 from macports.

How did you get it?
I tried "port search gettext" and got the answer 
gettext @0.17 (devel)
GNU gettext package

So I thought it's the current version.

> I would vote for removing the workaround in trunk and advise developers to 
> update their
> machine in the relevant INSTALL file (and maybe give the workaround of 
> overriding
> MESMERGE_UPDATE on the make command line). I dislike adding too much code for 
> working
> around bugs, because this code will stay, and I suspect that some people like 
> this backup thing.

I don't need the backup feature. But in principle you're right.

Stephan

Re: Backport of po/Makefile.in.in ok?

[BH]

On Mon, Oct 11, 2010 at 2:22 AM, Stephan Witt  wrote:
> Am 10.10.2010 um 22:56 schrieb Jean-Marc Lasgouttes:
>> Personnally, I hav no problem with my 0.18.1 from macports.
>
> How did you get it?
> I tried "port search gettext" and got the answer
> gettext @0.17 (devel)
>    GNU gettext package

gettext 0.18.1.1 for me. (Have you tried port selfupdate?)

BH

Re: LyX Book (was Re: External Programs and Add-On Modules for LyX)

[Pavel Sanda]

Rob Oakes wrote:
>  On 10/09/2010 02:22 PM, Pavel Sanda wrote:
> > if you feel energy and enthusiasm about the idea contact Uwe, he is our 
> > manuals master.
> > i think lyx is mature enough to deserve its own printed bible... ;)
> I will do that.  Another interesting question might be:
> 
> Should that bible be the same as the version as disseminated with LyX? 

considering the manpower we have i think it should be basically the manuals.
its very untrivial to keep our manuals up-to-date, and having two different
docs is unmaintainable.

> I don't know about you, but I've always felt that the very best bibles
> were those that had lavish illustrations and generous amounts of
> additional material.

okok, so lets dont call it bible and have more humble goal... :)
pave

Re: r35591 - lyx-devel/trunk/development

[Pavel Sanda]

uwesto...@lyx.org wrote:
> Author: uwestoehr
> Date: Mon Oct 11 03:11:51 2010
> New Revision: 35591
> URL: http://www.lyx.org/trac/changeset/35591
> 
> Log:
> FORMAT: forgot this in last commit
> 
> Modified:
>lyx-devel/trunk/development/FORMAT
> 
> Modified: lyx-devel/trunk/development/FORMAT
> ==
> --- lyx-devel/trunk/development/FORMATMon Oct 11 03:05:20 2010
> (r35590)
> +++ lyx-devel/trunk/development/FORMATMon Oct 11 03:11:51 2010
> (r35591)
> @@ -7,6 +7,11 @@
>  
>  ---
>  
> +2010-10-11 Uwe Stöhr 
> + * Format incremented to 402: fix for bug 1881
> +   no new or removed parameter, only used to handle a LaTeX
> +   output issue

Uwe would it be possible to add few words what gymnastics is done with newpage 
inset?

> +
>  2010-09-19 Ronen Abravanel 
>   * Format incremented to 401: support for Feynman diagrams
> new math command \Diagram

Re: Backport of po/Makefile.in.in ok?

[Stephan Witt]

Am 11.10.2010 um 13:55 schrieb BH:

> On Mon, Oct 11, 2010 at 2:22 AM, Stephan Witt  wrote:
>> Am 10.10.2010 um 22:56 schrieb Jean-Marc Lasgouttes:
>>> Personnally, I hav no problem with my 0.18.1 from macports.
>> 
>> How did you get it?
>> I tried "port search gettext" and got the answer
>> gettext @0.17 (devel)
>>GNU gettext package
> 
> gettext 0.18.1.1 for me. (Have you tried port selfupdate?)

No. I'm not familiar with macport...
I thought that "port search" mentions the newest available version.
Then I'll do it this way.

Stephan

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

[Pavel Sanda]

Stephan Witt wrote:
> Can you please say if this would be ok for you. (1. Attachment - Patch 2)

generally looks fine.

> The backport of the CVS-backend changes would be the 2. Attachment - Patch 3.

i see you touch svn code which iirc was not altered in trunk. this is lefotver
or you mean it?

> Regarding the locking/edit/unedit/readonly issues I'm not so sure anymore how
> it should be moved to lyxvc. Are you sure it makes sense to force readonly
> checkouts with SVN? 

i only meant to move checkoutenabled there, not readonly checkouts.

> * SVN supports explicit lock operation - CVS not.
> * CVS supports readonly checkouts - SVN not.
> 
> The CVS way is like SVN: it gives the user some freedom how to collaborate.
> Both support "optimistic" collaboration: every user may change a file and
> they have to resolve the merge conflicts afterwards. The other options though
> are different.
> 
> With CVS you may add "-r" as global option - the checkout/commit operation
> makes the files readonly, with edit/unedit you start or rollback changing of
> your local copy. Additionally you may use watch to get notified when someone
> issues edit/unedit/commit of a file.
> 
> With SVN (probably you know it better than me) you use lock/unlock to prevent
> others from changing the same file as you.

these locks are connected with readonly status of file. i wanted to make it 
similar
as it is in RCS. after checkout->rw. after checkin->ro. with subversion this is
connected with gaining lock which is sent to server so only one user is able to 
edit file.

it would be nice to let CVS follow such policy so all three backends are 
similar,
but maybe its not possible with CVS, dunno. it depends how you get notified - 
if there is specific command to query cvs server then we could query before 
checkout
and allow entering rw mode only in case its not edited by someone else.

> + doVCCommand("cvs update " + quoteName(owner_->filePath())
> + + " > " + quoteName(tmpf.toFilesystemEncoding()),
> + FileName(owner_->filePath()));

indent

pavel

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

[Stephan Witt]

Am 11.10.2010 um 17:29 schrieb Pavel Sanda:

> Stephan Witt wrote:
>> Can you please say if this would be ok for you. (1. Attachment - Patch 2)
> 
> generally looks fine.
> 
>> The backport of the CVS-backend changes would be the 2. Attachment - Patch 3.
> 
> i see you touch svn code which iirc was not altered in trunk. this is lefotver
> or you mean it?

Oh, as I come along I thought: one should better check for the return status
of the "svn diff" command. And yes I forgot to do it like that in trunk.
Do you think it's a good idea to do it like that and change trunk accordingly?

>> Regarding the locking/edit/unedit/readonly issues I'm not so sure anymore how
>> it should be moved to lyxvc. Are you sure it makes sense to force readonly
>> checkouts with SVN? 
> 
> i only meant to move checkoutenabled there, not readonly checkouts.

You mean doing the test of readonly status for all VCS?

>> * SVN supports explicit lock operation - CVS not.
>> * CVS supports readonly checkouts - SVN not.
>> 
>> The CVS way is like SVN: it gives the user some freedom how to collaborate.
>> Both support "optimistic" collaboration: every user may change a file and
>> they have to resolve the merge conflicts afterwards. The other options though
>> are different.
>> 
>> With CVS you may add "-r" as global option - the checkout/commit operation
>> makes the files readonly, with edit/unedit you start or rollback changing of
>> your local copy. Additionally you may use watch to get notified when someone
>> issues edit/unedit/commit of a file.
>> 
>> With SVN (probably you know it better than me) you use lock/unlock to prevent
>> others from changing the same file as you.
> 
> these locks are connected with readonly status of file. i wanted to make it 
> similar
> as it is in RCS. after checkout->rw. after checkin->ro. with subversion this 
> is
> connected with gaining lock which is sent to server so only one user is able 
> to edit file.

But that's not the general policy of SVN, isn't it? 
Wouldn't it be better to give the user some control over these details then?

> it would be nice to let CVS follow such policy so all three backends are 
> similar,
> but maybe its not possible with CVS, dunno. it depends how you get notified - 

You get a notification by e-mail. We don't use it. And we're working for a long 
time with
CVS in our company. We had rarely merge conflicts. They occur for sure when 
someone is
doing whitespace "correction", the worst things happen when different 
development tools
are used. LyX is doing good here.

> if there is specific command to query cvs server then we could query before 
> checkout
> and allow entering rw mode only in case its not edited by someone else.

You may call "cvs editors" to check the list of current editors. But I wouldn't 
recommend
that. It doesn't work reliable. If one abandons his checkout - you are in 
trouble if he
forgot to do "cvs unedit".

>> +doVCCommand("cvs update " + quoteName(owner_->filePath())
>> ++ " > " + quoteName(tmpf.toFilesystemEncoding()),
>> +FileName(owner_->filePath()));
> 
> indent

Ok.
Same as in SVN method :-)
I missed to correct it, indeed.

Stephan

Re: r35591 - lyx-devel/trunk/development

[Uwe Stöhr]

Am 11.10.2010 14:52, schrieb Pavel Sanda:


+   * Format incremented to 402: fix for bug 1881
+ no new or removed parameter, only used to handle a LaTeX
+ output issue


Uwe would it be possible to add few words what gymnastics is done with newpage 
inset?


newpage is not used in this commit.
I now documented what I have done in the bugreport of bug 1881. Is that 
enough info?


regards Uwe

LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

Hi,

I'm using SVN version from recent days, but this problem also accord in
older versions:

Sometime, when I'm right-clicking misspelled word with wiggly-red-line
beneath, and then choose the correct word from the context menu, LyX crash.
The output in the console is:

ro...@goon:~/dev/lyx/svn/lyx-devel$ ./src/lyx
/usr/include/c++/4.4/bits/basic_string.h:738: typename
_Alloc::rebind<_CharT>::other::reference std::basic_string::operator[](typename _Alloc::rebind<_CharT>::other::size_type) [with
_CharT = wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator]: Assertion '__pos <= size()' failed.
Aborted


I couldn't find any track ticket for this problem. Was I right?
What can I do in order to help specify the bug further?

Thanks,
Ronen

Re: #6920: Bug in typing a period (or comma) after the word "fine."

[John Mac]

How do you enable / disable ligatures onscreen?


BYW, my OS is a MacOSX (Leopard).


On Mon, Oct 4, 2010 at 9:23 AM, LyX Ticket Tracker  wrote:

> #6920: Bug in typing a period (or comma) after the word "fine."
>
> --+-
>  Reporter:  john3mac  |   Owner:  lasgouttes
> Type:  defect|  Status:  new
>  Priority:  normal|   Milestone:  2.0.0
> Component:  general   | Version:
>  Severity:  normal|Keywords:
>
> --+-
> Changes (by sanda):
>
>  * keywords:  infoneeded =>
>  * milestone:  => 2.0.0
>
>
> Comment:
>
>  ok at least its clear why does it show only on certain systems - those who
>  have enabled ligatures onscreen.
>
> --
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor
>

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

[Pavel Sanda]

Stephan Witt wrote:
> > generally looks fine.
> > 
> >> The backport of the CVS-backend changes would be the 2. Attachment - Patch 
> >> 3.
> > 
> > i see you touch svn code which iirc was not altered in trunk. this is 
> > lefotver
> > or you mean it?
> 
> Oh, as I come along I thought: one should better check for the return status
> of the "svn diff" command. And yes I forgot to do it like that in trunk.
> Do you think it's a good idea to do it like that and change trunk accordingly?

the code looks sane, but improvements belong rather to trunk. unless you are
fixing some real trouble i would like not touch svn code in branch.

> >> Regarding the locking/edit/unedit/readonly issues I'm not so sure anymore 
> >> how
> >> it should be moved to lyxvc. Are you sure it makes sense to force readonly
> >> checkouts with SVN? 
> > 
> > i only meant to move checkoutenabled there, not readonly checkouts.
> 
> You mean doing the test of readonly status for all VCS?

i have seen in the first patch you use function checkoutenabled again inside
cvs::checkout which we dont do anywhere else. i can see why you want it, but i
proposed to move this check into lyxvc::checkout. for svn case this does not
force readonly checkouts. (all this dicsussion is about trunk of course)

ehh, looking again on your patch, you use different way of readonly testing 
than we
do inside SVN(::isLocked). plain file_.isReadOnly makes much more problems
than 2s delay of menu launching ;)

> > these locks are connected with readonly status of file. i wanted to make it 
> > similar
> > as it is in RCS. after checkout->rw. after checkin->ro. with subversion 
> > this is
> > connected with gaining lock which is sent to server so only one user is 
> > able to edit file.
> 
> But that's not the general policy of SVN, isn't it? 

it depends whether user pushed the button 'locking' in toolbar.
if no then no locking/readonly business is involved.

similarly i thought than when 'locking' would be toggled inside CVS mode
then you would move into this 'readonly checkout' style. but as i understand
this is determined when checkout is done, not that you control it later.(?)

i tried to describe all this in our manual if my explanations seem dark now ;)

> > it would be nice to let CVS follow such policy so all three backends are 
> > similar,
> > but maybe its not possible with CVS, dunno. it depends how you get notified 
> > - 
> 
> You get a notification by e-mail.

so this is not usable for lyx.

> Same as in SVN method :-)

feel free to fix it there too :)

pavel

Re: r35591 - lyx-devel/trunk/development

[Pavel Sanda]

Uwe Stöhr wrote:
> Am 11.10.2010 14:52, schrieb Pavel Sanda:
>
>>> +   * Format incremented to 402: fix for bug 1881
>>> + no new or removed parameter, only used to handle a LaTeX
>>> + output issue
>>
>> Uwe would it be possible to add few words what gymnastics is done with 
>> newpage inset?
>
> newpage is not used in this commit.
> I now documented what I have done in the bugreport of bug 1881. Is that 
> enough info?

well, i would expect that reading FORMAT file one immediately gets idea whats
being done and 'handle a LaTeX output issue' really doesnt say anything.
so i was asking for adding some sentence with which i can understand what
is literally changed inside .lyx file without need to crawl web or studying
commit history.

thanks,
pavel

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Pavel Sanda]

Ronen Abravanel wrote:
> What can I do in order to help specify the bug further?

1. to find a recipy how to reproduce (maybe hard)
2. at least to produce a backtrace http://wiki.lyx.org/FAQ/FurtherHelp#toc4

pavel

Re: #6920: Bug in typing a period (or comma) after the word "fine."

[Pavel Sanda]

John Mac wrote:
> How do you enable / disable ligatures onscreen?

i dont think we can order qt for (not) doing this. but you can try to find some 
font
which is not intelligent enough (if you find it, then report back for other 
people...)

pavel

Branch warn

[Pavel Sanda]

i think this is relatively new

insets/ExternalTemplate.h: In constructor 'lyx::external::Template::Template()':
insets/ExternalTemplate.h:66: warning: 'lyx::external::Template::preview_mode' 
will be initialized after
insets/ExternalTemplate.h:64: warning:   'bool 
lyx::external::Template::automaticProduction'
insets/ExternalTemplate.cpp:52: warning:   when initialized here

Re: Branch warn

[Pavel Sanda]

Pavel Sanda wrote:
> i think this is relatively new
> 
> insets/ExternalTemplate.h: In constructor 
> 'lyx::external::Template::Template()':
> insets/ExternalTemplate.h:66: warning: 
> 'lyx::external::Template::preview_mode' will be initialized after
> insets/ExternalTemplate.h:64: warning:   'bool 
> lyx::external::Template::automaticProduction'
> insets/ExternalTemplate.cpp:52: warning:   when initialized here

LayoutFile.cpp: In member function 'lyx::LayoutFileIndex 
lyx::LayoutFileList::addEmptyClass(const std::string&)':
LayoutFile.cpp:230: warning: suggest explicit braces to avoid ambiguous 'else'

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

Starting program: /home/ronen/dev/lyx/svn/lyx-devel/src/lyx
[Thread debugging using libthread_db enabled]
/usr/include/c++/4.4/bits/basic_string.h:738: typename
_Alloc::rebind<_CharT>::other::reference std::basic_string::operator[](typename _Alloc::rebind<_CharT>::other::size_type) [with
_CharT = wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator]: Assertion '__pos <= size()' failed.

Program received signal SIGABRT, Aborted.
0x0012d422 in __kernel_vsyscall ()
(gdb) bt
#0  0x0012d422 in __kernel_vsyscall ()
#1  0x01139651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x0113ca82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x082686d0 in std::basic_string::operator[](unsigned int) ()
#4  0x08252d4a in lyx::Paragraph::isWordSeparator (this=0x908f7b0, pos=24)
at Paragraph.cpp:2795
#5  0x08252f1d in lyx::Paragraph::locateWord (this=0x908f7b0,
fr...@0xbfff80e8, t...@0xbfff80dc, loc=lyx::WHOLE_WORD)
at Paragraph.cpp:3353
#6  0x08263242 in lyx::Paragraph::Private::rangeOfSpellCheck
(this=0x908f7b0)
at Paragraph.cpp:391
#7  lyx::Paragraph::spellCheck (this=0x908f7b0) at Paragraph.cpp:3632
#8  0x082d97c3 in lyx::TextMetrics::drawParagraph (this=0x909a614, pi=...,
pit=8, x=0, y=380) at TextMetrics.cpp:2135
#9  0x082da4fa in lyx::TextMetrics::draw (this=0x909a614, pi=..., x=0,
y=380)
at TextMetrics.cpp:2059
#10 0x0831a446 in lyx::BufferView::draw (this=0x90a0058, pain=...)
at BufferView.cpp:2696
#11 0x08636dab in lyx::frontend::GuiWorkArea::updateScreen (this=0x9099628)
at GuiWorkArea.cpp:1050
#12 0x0863beeb in lyx::frontend::GuiWorkArea::redraw (this=0x9099628,
update_metrics=false) at GuiWorkArea.cpp:439
---Type  to continue, or q  to quit---
#13 0x085d81d7 in lyx::frontend::WorkAreaManager::redrawAll (this=0x900e690,

update_metrics=10) at WorkAreaManager.cpp:37
#14 0x080bea2b in lyx::Buffer::changed (this=0x8fd8950, update_metrics=6)
at Buffer.cpp:461
#15 0x083215aa in lyx::BufferView::processUpdateFlags (this=0x90a0058,
flags=3)
at BufferView.cpp:468
#16 0x08398739 in replace (bv=0x90a0058, ev=..., has_deleted=false)
at lyxfind.cpp:250
#17 lyx::replace (bv=0x90a0058, ev=..., has_deleted=false) at
lyxfind.cpp:328
#18 0x083244a0 in lyx::BufferView::dispatch (this=0x90a0058, cmd=...,
dr=...)
at BufferView.cpp:1515
#19 0x085ed394 in lyx::frontend::GuiApplication::dispatch (this=0x8c512c0,
cmd=..., dr=...) at GuiApplication.cpp:1593
#20 0x085e5869 in lyx::frontend::GuiApplication::dispatch (this=0x8c512c0,
cmd=...) at GuiApplication.cpp:1096
#21 0x081f3c9d in lyx::dispatch (action=...) at LyX.cpp:1228
#22 0x0868ac87 in lyx::frontend::Action::action (this=0x9145c90)
at Action.cpp:66
#23 0x0868ad00 in lyx::frontend::Action::qt_metacall (this=0x9145c90,
_c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfffbdc8)
at moc_Action.cpp:77
#24 0x00eaac9a in QMetaObject::metacall(QObject*, QMetaObject::Call, int,
void**) () from /usr/lib/libQtCore.so.4
---Type  to continue, or q  to quit---
#25 0x00eb93d5 in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) () from /usr/lib/libQtCore.so.4
#26 0x003efbd9 in QAction::triggered(bool) () from /usr/lib/libQtGui.so.4
#27 0x003f1dcc in QAction::activate(QAction::ActionEvent) ()
   from /usr/lib/libQtGui.so.4
#28 0x0089560c in ?? () from /usr/lib/libQtGui.so.4
#29 0x0089babb in ?? () from /usr/lib/libQtGui.so.4
#30 0x0089cac7 in QMenu::mouseReleaseEvent(QMouseEvent*) ()
   from /usr/lib/libQtGui.so.4
#31 0x004547f8 in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4
#32 0x0089e0cc in QMenu::event(QEvent*) () from /usr/lib/libQtGui.so.4
#33 0x003f64dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/libQtGui.so.4
#34 0x003fd9f7 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libQtGui.so.4
#35 0x085de96f in lyx::frontend::GuiApplication::notify (this=0x8c512c0,
receiver=0x90fe2e8, event=0xbfffc5b0) at GuiApplication.cpp:2141
#36 0x00ea5a3b in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/libQtCore.so.4
#37 0x003fc952 in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) ()
   from /usr/lib/libQtGui.so.4
#38 0x004885cf in ?? () from /usr/lib/libQtGui.so.4
---Type  to continue, or q  to quit---
#39 0x00487511 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/libQtGui.so.4
#40 0x004b660a in ?? () from /usr/lib/libQtGui.so.4
#41 0x001825e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#42 0x001862d8 in ?? () from /lib/libglib-2.0.so.0
#43 0x001864b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#44 0x00ed15d5 in
QEventDispatcherGlib::processEvents(QFlags)
() from /usr/lib/libQtCore.so.4
#45 0x004b6135 in ?? () from /usr/lib/libQtGui.so.4
#46 0x00ea4059 in
QEventLoop::processEvents(QFlags) () from
/usr/lib/libQtCore.so.4
#47 0x00ea44aa in 

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Stephan Witt]

Am 12.10.2010 um 03:16 schrieb Ronen Abravanel:

> Starting program: /home/ronen/dev/lyx/svn/lyx-devel/src/lyx 
> [Thread debugging using libthread_db enabled]
> /usr/include/c++/4.4/bits/basic_string.h:738: typename 
> _Alloc::rebind<_CharT>::other::reference std::basic_string Alloc>::operator[](typename _Alloc::rebind<_CharT>::other::size_type) [with 
> _CharT = wchar_t, _Traits = std::char_traits, _Alloc = 
> std::allocator]: Assertion '__pos <= size()' failed.
> 
> Program received signal SIGABRT, Aborted.
> 0x0012d422 in __kernel_vsyscall ()
> (gdb) bt
> #0  0x0012d422 in __kernel_vsyscall ()
> #1  0x01139651 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2  0x0113ca82 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3  0x082686d0 in std::basic_string std::allocator >::operator[](unsigned int) ()
> #4  0x08252d4a in lyx::Paragraph::isWordSeparator (this=0x908f7b0, pos=24)
> at Paragraph.cpp:2795
> #5  0x08252f1d in lyx::Paragraph::locateWord (this=0x908f7b0, 
> fr...@0xbfff80e8, t...@0xbfff80dc, loc=lyx::WHOLE_WORD)
> at Paragraph.cpp:3353
> #6  0x08263242 in lyx::Paragraph::Private::rangeOfSpellCheck (this=0x908f7b0)
> at Paragraph.cpp:391
> #7  lyx::Paragraph::spellCheck (this=0x908f7b0) at Paragraph.cpp:3632

Hi Ronen,

thank you for doing the backtrace.
Can you please give me some details?
You're using SVN current trunk code?
What are you doing to get the crash?

Stephan