Re: cmake LYX_option
Am 22.01.2011 um 16:54 schrieb Peter Kümmel:
On 22.01.2011 16:46, Stephan Witt wrote:
Peter,
is it possible to add extra library/include file search paths?
If I want to debug the aspell/hunspell I have to use my private builds on
Mac.
I want to pass it as options from command line, otherwise I have to change
the
e. g. FindASPELL.cmake to build with aspell support.
Are your changes so specific to your setup that they could not get upstream?
I think so, it's a build directory below a sibling of the lyx checkout.
But how should it look like to be acceptable for getting upstream?
May I set an optional variable as path prefix and add it?
Currently we have:
/usr/include
/usr/local/include
/usr/local/include/aspell
${_program_FILES_DIR}/gnuwin32/include
perhaps
+=
${PRIVATE_BUILD_DIR}/include
Stephan
Re: cmake LYX_option
Am 22.01.2011 um 19:54 schrieb Peter Kümmel:
On 22.01.2011 17:50, Stephan Witt wrote:
Am 22.01.2011 um 16:54 schrieb Peter Kümmel:
On 22.01.2011 16:46, Stephan Witt wrote:
Peter,
is it possible to add extra library/include file search paths?
If I want to debug the aspell/hunspell I have to use my private builds on
Mac.
I want to pass it as options from command line, otherwise I have to change
the
e. g. FindASPELL.cmake to build with aspell support.
Are your changes so specific to your setup that they could not get upstream?
I think so, it's a build directory below a sibling of the lyx checkout.
But how should it look like to be acceptable for getting upstream?
May I set an optional variable as path prefix and add it?
Currently we have:
/usr/include
/usr/local/include
/usr/local/include/aspell
${_program_FILES_DIR}/gnuwin32/include
perhaps
+=
${PRIVATE_BUILD_DIR}/include
Stephan
Or attached patch?
cmake . -DLYX_ADD_INCLUDES=/x/y/z;/a/b/c
Sorry, I didn't have any time until now...
I tried it and had no luck.
But I found another approach, I call cmake with the results I want to get:
...
-DASPELL_INCLUDE_DIR=/Users/stephan/cvs/lyx/lyx-build/SpellCheckers/include\
-DASPELL_LIBRARY_RELEASE=/Users/stephan/cvs/lyx/lyx-build/SpellCheckers/lib/libaspell.dylib\
-DHUNSPELL_INCLUDE_DIR=/Users/stephan/cvs/lyx/lyx-build/SpellCheckers/include\
-DHUNSPELL_LIBRARY=/Users/stephan/cvs/lyx/lyx-build/SpellCheckers/lib/libhunspell.dylib\
...
That way it works without touching the cmake modules files.
Stephan
Re: #7149: Crash when issuing commands through pipes with minimized view
Am 19.01.2011 um 07:41 schrieb LyX Ticket Tracker:
#7149: Crash when issuing commands through pipes with minimized view
--+-
Reporter: vfr | Owner: lasgouttes
Type: defect| Status: new
Priority: highest | Milestone: 2.0.0
Component: general | Version: 2.0.0svn
Severity: critical |Keywords: crash patch
--+-
Ticket URL: http://www.lyx.org/trac/ticket/7149#comment:19
Comment(by stwitt):
I attached a patch to fix the remaining problems.
I found the LFUN_BOOKMARK_GOTO problem too.
With LFUN_WINDOW_CLOSE the problem isn't that easy:
Should the close message be ignored when no view is current or should we
send it to the last opened view instead?
I've made another patch with an proposal for a LFUN_WINDOW_CLOSE solution.
In getStatus() LFUN_WINDOW_CLOSE is enabled when there is any view existent.
So I conclude that it is correct to choose one if no view is current.
See the attached patch. I'd like to apply it. Ok?
Stephan
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp(Revision 37306)
+++ src/frontends/qt4/GuiApplication.cpp(Arbeitskopie)
@@ -1169,10 +1169,13 @@
dispatch(FuncRequest(LFUN_BOOKMARK_SAVE, 0));
// if the current buffer is not that one, switch to it.
- BufferView * doc_bv = current_view_-documentBufferView();
+ BufferView * doc_bv = current_view_ ?
+ current_view_-documentBufferView() : 0;
if (!doc_bv || doc_bv-buffer().fileName() != tmp.filename) {
if (switchToBuffer) {
dispatch(FuncRequest(LFUN_BUFFER_SWITCH, file));
+ if (!current_view_)
+ return;
doc_bv = current_view_-documentBufferView();
} else
return;
@@ -1297,7 +1300,10 @@
// clear the last opened list, because
// maybe this will end the session
theSession().lastOpened().clear();
- current_view_-closeScheduled();
+ // check for valid current_view_
+ validateCurrentView();
+ if (current_view_)
+ current_view_-closeScheduled();
break;
case LFUN_LYX_QUIT:
@@ -1420,8 +1426,9 @@
}
if (!lcolor.setColor(lyx_name, x11_name)) {
- current_view_-message(
- bformat(_(Set-color \%1$s\ failed
+ if (current_view_)
+ current_view_-message(
+ bformat(_(Set-color \%1$s\ failed
- color is undefined or
may not be redefined),
from_utf8(lyx_name)));
@@ -1482,13 +1489,18 @@
// --- lyxserver commands
case LFUN_SERVER_GET_FILENAME: {
- LASSERT(current_view_ current_view_-documentBufferView(),
return);
- docstring const fname = from_utf8(
+ if (current_view_ current_view_-documentBufferView()) {
+ docstring const fname = from_utf8(
current_view_-documentBufferView()-buffer().absFileName());
- dr.setMessage(fname);
- LYXERR(Debug::INFO, FNAME[ fname ']');
+ dr.setMessage(fname);
+ LYXERR(Debug::INFO, FNAME[ fname ']');
+ } else {
+ dr.setMessage(docstring());
+ LYXERR(Debug::INFO, No current file for
LFUN_SERVER_GET_FILENAME);
+ }
break;
}
+
case LFUN_SERVER_NOTIFY: {
docstring const dispatch_buffer =
d-keyseq.print(KeySequence::Portable);
dr.setMessage(dispatch_buffer);
@@ -2043,6 +2055,8 @@
LastOpenedSection::LastOpened const lastopened =
session.lastOpened().getfiles();
+ validateCurrentView();
+
FileName active_file;
// do not add to the lastfile list since these files are restored from
// last session, and should be already there (regular files), or should
@@ -2064,7 +2078,7 @@
// Restore last active buffer
Buffer * buffer = theBufferList().getBuffer(active_file);
- if (buffer)
+ if (buffer current_view_)
current_view_-setBuffer(buffer);
// clear this list to save a few bytes of RAM
@@ -2152,7 +2166,7 @@
this-exit(1);
case BufferException: {
-
Re: about background compilation
Am 24.01.2011 um 09:36 schrieb Vincent van Ravesteijn: It's really nice! and pretty innocuous, so i put it in: http://www.lyx.org/trac/changeset/37304/lyx-devel/trunk I just can't get the icon to appear. Anyone else having problems with it ? Vincent Me too. I had to copy the busy.gif icon to the image resources folder manually once to solve it. Stephan
Re: Make lyx more easy to be configed as portable program
Am 18.01.2011 um 15:23 schrieb Vincent van Ravesteijn:
Unfortunately it's not the only thing you did.
You introduced the regression that only the last occurrence of
a variable gets replaced. Your assumption was that boost returns
the first match - it's the last one instead!
$LyXDir/component1/bin:$LyXDir/component2/bin =
$LyXDir/component1/bin:/path/to/lyx/component2/bin
Hmm Ok.
But the goal was to avoid the replacement of a real $ in a file name.
This goal is missed if the user passes a file name with a real $ followed
by an existing variable name. Then the bug is there again.
Then, indeed you need to escape the variable whenever it is a real $
in a filename, but you'd need to find all cases in which the user
supplies a path and which for certain do not contain any environment
variables.
I applied the patch as http://www.lyx.org/trac/changeset/37326.
To fix ticket 4177 the patch for GuiView.cpp is pending...
Is it ok to apply?
Stephan
The patch again:
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp (Revision 37244)
+++ src/frontends/qt4/GuiView.cpp (Arbeitskopie)
@@ -1950,13 +1950,14 @@
message(_(Canceled.));
return;
}
- } else
- filename = fname;
+ } else {
+ // get absolute path of file and add .lyx to the filename if
+ // necessary.
+ filename = fileSearch(string(), fname, lyx,
support::may_not_exist).absFileName();
+ }
- // get absolute path of file and add .lyx to the filename if
- // necessary.
- FileName const fullname =
- fileSearch(string(), filename, lyx,
support::may_not_exist);
+ FileName const fullname = FileName(filename);
+
if (!fullname.empty())
filename = fullname.absFileName();
Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism
Am 26.01.2011 um 15:00 schrieb Walter: I'll try to answer this - although I surely don't have so much time you had to write this. Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran a spell check for the first time. The interface is good and no doubt an improvement on previous eras, however the following struck me as possible to improve. Those items marked with [*] I consider a bug in LyX. Those items marked with [X] I consider a bug elsewhere. 1. Preferences|Language Settings|Spellchecker [*] -- Fields lack a description. Faced with having used non-US spelling in my document (for shame!), I do not want to manually set hundreds of individual words to be 'English (UK)', which using the inbuilt right sidebar interface appears to be the default way forward. (For some reason, 'English (AU)' is not even an option on my system, though that's probably my fault.) The following refers to the field Alternative language I'd guess. Thus driven to the preferences dialog, I was unsure of which mystical value to enter in to the great LyX machine. Assuming 'man aspell' would clear it up, indeed some text was located that made the expected format for the entry of a single language value probable: It follows the same format of the LANG environmental variable on most systems. It consists of the two letter ISO 639 language code and an optional two letter ISO 3166 country code after a dash or underscore. I tried this (en_AU), and it did work. However, there are two problems: - Even the first step would be a challenge for some users - I would like to add multiple values to the field, since otherwise even at this early stage of my document still hundreds of words and place names in French, German, Greek (+romanised Greek), Chinese (+romanised Chinese), etc. trip up the spell checker. (Use of these languages is frequent and scattered right throughout the document.) Ok, with this use case - mixed language documents - you are requested to mark the text appropriately. Here LyX does no guessing and there are no plans to change that. The method to do this (eg: separate multiple values with a space or comma), or indeed whether entering multiple values in to this field is at all possible remains unclear. Whilst the ideal route would be to add (relatively) complex integration code that auto-detected available spellcheckers, their dictionaries, and provided a sexy GUI for end user language selection instead of a mystical text field, I realise this is not going to happen overnight or perhaps ever. Alternative language is a - as I would rate it - cul-de-sac and shouldn't be there. If any LyX should have a mapping of available languages to alternate languages. As it is now the single value here is used for all text having the documents language as a replacement to pass on to the spell checker. So if you want to use English (UK) you don't need to change it here - simply set your document language to English (UK). The alternate language is used for all (!) languages regardless of making any sense. If you edit a french LyX-document and the alternate language is set to en_GB e. g. you'll have no fun. This is what I would rate as a bug. So this field is of very limited use and should be replaced by something else. Of course something else may have an more user friendly interface too... But it can be tricky to make it right. It heavily depends on the spell checker - aspell e. g. accepts completely different alternative language settings as hunspell or apples spell checker do. And it depends on the runtime-environment - what dictionaries are available for the user on the current machine. And we have the feature to switch between the spell checker back ends at runtime. Thus, as a relatively easy half-way fix, could we please have some increased on-screen documentation? Something like eg: 'en_GB' for aspell. may suffice for 95% of users. Until the field gets replaced or removed a tooltip may help. 2. Right click to set spellchecker language on a highlighted word fails [*] It appears that when 'Tools|Preferences|Language Settings|Spellchecker| Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right clicked, there is an option to set their language for spellchecking purposes. However, this does not appear to actually do anything! This makes it necessary for the user to select the word then use 'Edit| Language|Whatever language' to actually perform the change - pointless tedium. You propose to auto extend the selection to word boundaries when setting the language at a given position and no selection exists. That sounds sensible... 3.
Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism
Am 27.01.2011 um 15:16 schrieb Walter: This sounds ugly. Is there any similarity between spell checking APIs? Is there a cross platform, spell checking library unification / abstraction layer available? Would it be worth developing one? How difficult is it to detect known dictionaries and spell checkers on a cross-platform basis? Possible answer: http://www.abisource.com/projects/enchant/ Unfortunately enchant has big drawbacks: * missing language variety support * not available for LyX on mac And in fact it is only a wrapper around existing spell checkers - just as LyX is :-) Stephan
Re: Wrong display of spelling mark when word is followed by a non-space
Am 27.01.2011 um 16:38 schrieb Jean-Marc Lasgouttes: In a document with spell-as-you-type enabled, type LyX@. The spell marker will contain the @ character, whereas normal spell check will select LyX only. I looked a bit at the code but I do not know where to search. It's my fault. I don't know if I copied it when refactoring spell checker mismatch marking. Anyway, the patch is attached. I'll check for side-effects... Thanks for pointing this out. Stephan Index: src/Paragraph.cpp === --- src/Paragraph.cpp (Revision 37338) +++ src/Paragraph.cpp (Arbeitskopie) @@ -393,10 +393,7 @@ // check for sane arguments if (to from || from = textsize) return; - FontSpan fp = FontSpan(from, to); - // don't mark end of paragraph - if (fp.last = textsize) - fp.last = textsize - 1; + FontSpan fp = FontSpan(from, to - 1); speller_state_.setRange(fp, state); }
Re: Wrong display of spelling mark when word is followed by a non-space
Am 27.01.2011 um 17:38 schrieb Jean-Marc Lasgouttes: Le 27/01/2011 17:12, Stephan Witt a écrit : Am 27.01.2011 um 16:38 schrieb Jean-Marc Lasgouttes: In a document with spell-as-you-type enabled, type LyX@. The spell marker will contain the @ character, whereas normal spell check will select LyX only. I looked a bit at the code but I do not know where to search. It's my fault. I don't know if I copied it when refactoring spell checker mismatch marking. Anyway, the patch is attached. I'll check for side-effects... It looks reasonable, but why isn't a space after word highlighted too? Is it treated specially? That's why I wanted to check again. Currently I don't know it... I have to admit I had to become comfortable with the pos() == size() for end of paragraph idiom. Stephan
Re: Wrong display of spelling mark when word is followed by a non-space
Am 27.01.2011 um 17:38 schrieb Jean-Marc Lasgouttes: Le 27/01/2011 17:12, Stephan Witt a écrit : Am 27.01.2011 um 16:38 schrieb Jean-Marc Lasgouttes: In a document with spell-as-you-type enabled, type LyX@. The spell marker will contain the @ character, whereas normal spell check will select LyX only. I looked a bit at the code but I do not know where to search. It's my fault. I don't know if I copied it when refactoring spell checker mismatch marking. Anyway, the patch is attached. I'll check for side-effects... It looks reasonable, but why isn't a space after word highlighted too? Is it treated specially? Yes, it is. The innermost loop in method RowPainter::paintChars() stops at printable spaces. After returning and drawing the misspelled marker the space is not painted but skipped. The normal spell checker stops at word boundaries anyway. So I want to apply the patch. Stephan
Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism
Am 27.01.2011 um 14:05 schrieb Walter: Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran a spell check for the first time. The interface is good and no doubt an improvement on previous eras, however the following struck me as possible to improve. Those items marked with [*] I consider a bug in LyX. Those items marked with [X] I consider a bug elsewhere. 1. Preferences|Language Settings|Spellchecker [*] -- Fields lack a description. Faced with having used non-US spelling in my document (for shame!), I do not want to manually set hundreds of individual words to be 'English (UK)', which using the inbuilt right sidebar interface appears to be the default way forward. (For some reason, 'English (AU)' is not even an option on my system, though that's probably my fault.) The following refers to the field Alternative language I'd guess. Correct! Thus driven to the preferences dialog, I was unsure of which mystical value to enter in to the great LyX machine. Assuming 'man aspell' would clear it up, indeed some text was located that made the expected format for the entry of a single language value probable: It follows the same format of the LANG environmental variable on most systems. It consists of the two letter ISO 639 language code and an optional two letter ISO 3166 country code after a dash or underscore. I tried this (en_AU), and it did work. However, there are two problems: - Even the first step would be a challenge for some users - I would like to add multiple values to the field, since otherwise even at this early stage of my document still hundreds of words and place names in French, German, Greek (+romanised Greek), Chinese (+romanised Chinese), etc. trip up the spell checker. (Use of these languages is frequent and scattered right throughout the document.) Ok, with this use case - mixed language documents - you are requested to mark the text appropriately. Here LyX does no guessing and there are no plans to change that. On the contrary, dear fellow: the opposite has already come to pass! Demand hath begat a plan! One man, I understand, begat that plan: a module fan, Michiel Kamermans! http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html Ok, AFAIU this refers to the XeLaTeX engine and not to LyX. Of course, if someone wants to develop a solid algorithm for language guessing and can convince the LyX developer community of it and has the resources to implement and test it - it may happen. Another option would be to have a spell checker backend including this feature. http://www.ctan.org/tex-archive/macros/xetex/latex/fontwrap/ So that fonts are *autoselected* based on UNICODE range unless otherwise overridden. But alas, the user is still utterly laboured with tedious repetition of language specification (also text style selection, with the hack i use), and will remain so until LyX UI changes. Do you have an example for such a document? But it can be tricky to make it right. It heavily depends on the spell checker - aspell e. g. accepts completely different alternative language settings as hunspell or apples spell checker do. And it depends on the runtime-environment - what dictionaries are available for the user on the current machine. And we have the feature to switch between the spell checker back ends at runtime. This sounds ugly. Is there any similarity between spell checking APIs? Is there a cross platform, spell checking library unification / abstraction layer available? Would it be worth developing one? How difficult is it to detect known dictionaries and spell checkers on a cross-platform basis? I'll cite my own investigation about similarity between spell checking APIs. The focus was the management of personal word lists. We have support for different spell checker backends. All of them are able to check words, of course. But the capabilities with personal word lists differs horrible. The following table presents the results of my investigation. Feature | aspell | native (mac) | enchant | hunspell check | + | +| + | + suggest | + | +| + | + accept | + | +| + | + insert | + | +| o (2) | o (3) ispersonal? | o (1) | +| - | - remove | - | +| + (4) | - Legend: + feature is supported - feature is not supported o there are limitations: 1) aspell has the interface to enumerate the personal word list. So it's possible to implement, I have a patch for LyX at hand. 2) The versions below 1.6.0 are truncating the personal word list on open - effectively no personal word list available after restart. 3) There is no persistent state
Re: Wrong display of spelling mark when word is followed by a non-space
Am 28.01.2011 um 00:06 schrieb Jean-Marc Lasgouttes: Le 27 janv. 2011 à 21:49, Stephan Witt a écrit : Yes, it is. The innermost loop in method RowPainter::paintChars() stops at printable spaces. After returning and drawing the misspelled marker the space is not painted but skipped. The normal spell checker stops at word boundaries anyway. So I want to apply the patch. Please do. I did it. I have to check the do not mark the word at cursor position feature again. Anyway, this is more clear now. Thanks. Stephan
Re: Wrong display of spelling mark when word is followed by a non-space
Am 28.01.2011 um 08:05 schrieb Stephan Witt:
Am 28.01.2011 um 00:06 schrieb Jean-Marc Lasgouttes:
Le 27 janv. 2011 à 21:49, Stephan Witt a écrit :
Yes, it is.
The innermost loop in method RowPainter::paintChars() stops at printable
spaces.
After returning and drawing the misspelled marker the space is not painted
but skipped.
The normal spell checker stops at word boundaries anyway.
So I want to apply the patch.
Please do.
I did it. I have to check the do not mark the word at cursor position
feature again.
It has shown the following patch is needed. Ok?
Stephan
Index: src/Paragraph.h
===
--- src/Paragraph.h (Revision 37347)
+++ src/Paragraph.h (Arbeitskopie)
@@ -456,7 +456,7 @@
/// Spell checker status at position \p pos.
/// \return true if pointed position is misspelled.
- bool isMisspelled(pos_type pos) const;
+ bool isMisspelled(pos_type pos, bool check_boundary = false) const;
/// \return true if both positions are inside the same
/// spell range - i.e. the same word.
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp (Revision 37347)
+++ src/Paragraph.cpp (Arbeitskopie)
@@ -3762,9 +3762,12 @@
}
-bool Paragraph::isMisspelled(pos_type pos) const
+bool Paragraph::isMisspelled(pos_type pos, bool check_boundary) const
{
- return SpellChecker::misspelled(d-speller_state_.getState(pos));
+ bool result = SpellChecker::misspelled(d-speller_state_.getState(pos));
+ if (!result check_boundary pos 0 isWordSeparator(pos))
+ result =
SpellChecker::misspelled(d-speller_state_.getState(pos - 1));
+ return result;
}
Index: src/Text3.cpp
===
--- src/Text3.cpp (Revision 37347)
+++ src/Text3.cpp (Arbeitskopie)
@@ -71,6 +71,7 @@
#include support/lstrings.h
#include support/lyxtime.h
#include support/os.h
+#include support/textutils.h
#include mathed/InsetMathHull.h
#include mathed/MathMacroTemplate.h
@@ -467,9 +468,9 @@
cur.noScreenUpdate();
LASSERT(cur.text() == this, /**/);
- CursorSlice oldTopSlice = cur.top();
- bool oldBoundary = cur.boundary();
- bool sel = cur.selection();
+ CursorSlice const oldTopSlice = cur.top();
+ bool const oldBoundary = cur.boundary();
+ bool const oldSelection = cur.selection();
// Signals that, even if needsUpdate == false, an update of the
// cursor paragraph is required
bool singleParUpdate = lyxaction.funcHasFlag(cmd.action(),
@@ -477,9 +478,8 @@
// Signals that a full-screen update is required
bool needsUpdate = !(lyxaction.funcHasFlag(cmd.action(),
LyXAction::NoUpdate) || singleParUpdate);
- int const last_pid = cur.paragraph().id();
- pos_type const last_pos = cur.pos();
- bool const last_misspelled = lyxrc.spellcheck_continuously
cur.paragraph().isMisspelled(cur.pos());
+ bool const last_misspelled = lyxrc.spellcheck_continuously
+ cur.paragraph().isMisspelled(cur.pos(), true);
FuncCode const act = cmd.action();
switch (act) {
@@ -2184,9 +2184,10 @@
if (!cur.inTexted()) {
// move from regular text to math
needsUpdate = last_misspelled;
- } else if (cur.paragraph().id() != last_pid || cur.pos() !=
last_pos) {
+ } else if (oldTopSlice != cur.top() || oldBoundary !=
cur.boundary()) {
// move inside regular text
- needsUpdate = last_misspelled ||
cur.paragraph().isMisspelled(cur.pos());
+ needsUpdate = last_misspelled ||
+ cur.paragraph().isMisspelled(cur.pos(), true);
}
}
@@ -2212,7 +2213,7 @@
if (!needsUpdate
oldTopSlice.inset() == cur.inset()
oldTopSlice.idx() == cur.idx()
-!sel // sel is a backup of cur.selection() at the beginning of
the function.
+!oldSelection // oldSelection is a backup of cur.selection() at
the beginning of the function.
!cur.selection())
// FIXME: it would be better if we could just do this
//
Re: Wrong display of spelling mark when word is followed by a non-space
Am 28.01.2011 um 15:17 schrieb Jean-Marc Lasgouttes: Le 28 janv. 2011 à 14:22, Stephan Witt a écrit : I did it. I have to check the do not mark the word at cursor position feature again. It has shown the following patch is needed. Ok? Why not, but what does it fix (besides the cleanup)? Without patch the painting of the misspelled marker isn't correct anymore if you enter or leave a word at the end. The old isMisspelled check returned true for the position immediately after the word end. We fixed that with the previous patch... You should update the documentation of Paragraph::isMisspelled. Ah, yes. Thanks. Stephan
Re: r37352 - lyx-devel/trunk/lib
Am 28.01.2011 um 15:53 schrieb sa...@lyx.org: Author: sanda Date: Fri Jan 28 15:53:37 2011 New Revision: 37352 URL: http://www.lyx.org/trac/changeset/37352 Log: Thanks to Jose. BTW I see some people like Stephan have quite up-to-date entries :) Yes, I didn't know what to do with that... Stephan
Re: about continuous spellcheck
Am 29.01.2011 um 17:24 schrieb Edwin Leuven: i have started to use trunk for my regular work, and wondered about the following the dotted lines that underline misspelled words are difficult to see: could we draw them fatter or use the old wiggly lines? I tried to scale the thickness of the dotted line with zoom factor. Of course this is pure heuristics. If you want to play with it: have a look at the RowPainter::RowPainter constructor. when the cursor is in a misspelled word the dotted lines are not painted: is this intentional? Yes. The idea is to avoid marking unfinished words as misspelled. Stephan
Re: about continuous spellcheck
Am 29.01.2011 um 18:51 schrieb Edwin Leuven: Stephan Witt st.w...@gmx.net wrote: I tried to scale the thickness of the dotted line with zoom factor. Of course this is pure heuristics. If you want to play with it: have a look at the RowPainter::RowPainter constructor. mm, 1 pixel is too thin, 2 too thick :-/ Yes, that's tricky. Here is some room for improvements of the row painter code: * the scaling (of the line thickness) does not correspond with the vertical row distance * the scaling does not correspond with the left margin width * the scaling does not correspond with the cursor thickness (there are multiple complaints about cursor visibility already) I didn't start with it because I'm afraid to touch the rowpainter and its interaction with other painter classes. I think we want to get 2.0.0 out of the door some day. when the cursor is in a misspelled word the dotted lines are not painted: is this intentional? Yes. The idea is to avoid marking unfinished words as misspelled. i was troubled by clicking on a misspelled word and the dotted lines disappearing (these may be finished words, misspelled or not recognized by the spellchecker such as names) Unfinished refers to the word you are editing now. so on entry (mouse click or arrows) i expect to keep the underlining (a misspelled word is a misspelled word) on editing the word it may make sense to not paint the line, but even here i am not so sure since the underlining provides feedback (assuming we are updating continuously) i checked Word: no underlining when typing a new word, and misspelling is applied after the cursor leaves the word on entry of a misspelled word the underlining is maintained on edit of misspelled word the underlining is maintained until the word is spelled correctly ... what do people expect from other editors? I already checked open-office, eclipse and apple mail. All of them don't mark an unfinished word at first. Apple mail has exact the same behavior as LyX has now. Office and eclipse are doing the same as you are describing for word. Stephan
Re: trunk does no compile
Am 29.01.2011 um 19:12 schrieb Enrico Forestieri: On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote: Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: I can also share my template-based one, that avoids code replication and actually turns this burden over the odocstream class itself. Assuming the latter works fine on all architectures, this one should as well :-). Forgot to attach. just don't even try it: my own brand new automated tests just started to fail because, with that template-ish thing, at the first attempt of typing a character in text-mode LyX was asserting :-). I'm using the Enrico's patch that works fine (at least on my 64-bit machine). Yet, I think your idea is right for avoiding code duplication. Let's see whether requiring explicit instantiations works. If yes, adding a forgotten type would only require adding a single-line instantiation declaration. So, does the attach patch work for you? This patch works here too (32 bit on Mac). Stephan
Re: about continuous spellcheck
Am 29.01.2011 um 20:40 schrieb Edwin Leuven: Stephan Witt st.w...@gmx.net wrote: I didn't start with it because I'm afraid to touch the rowpainter and its interaction with other painter classes. I think we want to get 2.0.0 out of the door some day. sensible indeed did our old wiggly line die along the way btw? or can it be resuscitated? I'm innocent, I didn't kill it. It was a french man... :-) I only added the zoom adaption to reduce the complaints of users. I already checked open-office, eclipse and apple mail. All of them don't mark an unfinished word at first. Apple mail has exact the same behavior as LyX has now. Office and eclipse are doing the same as you are describing for word. so wouldn't we like to maintain the misspell marker on word entry? I changed the behavior on explicit user request. I noticed the difference in behavior as I made the implementation. To be honest, the current implementation already was no simplification of the code - to go on and add the distinction between first edit and the latter ones when painting the misspelled marker is doable, but... I may have a look, but I wouldn't wait with 2.0.0 beta4 because of that. Stephan
Re: trunk does no compile
Am 30.01.2011 um 02:23 schrieb Enrico Forestieri: On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote: Il 29/01/2011 19:12, Enrico Forestieri ha scritto: just don't even try it: my own brand new automated tests just started to fail because, with that template-ish thing, at the first attempt of typing a character in text-mode LyX was asserting :-). I'm using the Enrico's patch that works fine (at least on my 64-bit machine). Yet, I think your idea is right for avoiding code duplication. Let's see whether requiring explicit instantiations works. If yes, adding a forgotten type would only require adding a single-line instantiation declaration. So, does the attach patch work for you? If it is the same currently committed, then it is sufficient to: -) create a new file -) type any letter and kaboom! From the backtrace, it is clear that the assertion is unrelated to the otexstream class and that it only occurs when continuous spell checking is active. The culprit here is r37363. Specifically, the assertion is triggered by the following line char_type const c = d-text_[pos]; in Paragraph::isWordSeparator(). Seemingly, pos points to the position immediately after the last character in d-text_. Sorry, I was mislead by the test pos == size() at the end of isWordSeparator(). Obviously the author of that test function wants to return true for end-of-paragraph. But the test for it should come first. I did an explicitly test of that scenario and it did not crash here. But it seems I didn't enable the array bounds checker :( I fixed that with r37369. Stephan
Re: about continuous spellcheck
Am 29.01.2011 um 21:14 schrieb Stephan Witt: Am 29.01.2011 um 20:40 schrieb Edwin Leuven: Stephan Witt st.w...@gmx.net wrote: I already checked open-office, eclipse and apple mail. All of them don't mark an unfinished word at first. Apple mail has exact the same behavior as LyX has now. Office and eclipse are doing the same as you are describing for word. so wouldn't we like to maintain the misspell marker on word entry? To be honest, the current implementation already was no simplification of the code - to go on and add the distinction between first edit and the latter ones when painting the misspelled marker is doable, but... I may have a look, but I wouldn't wait with 2.0.0 beta4 because of that. Dear buffer-view/cursor-experts, I'm looking for a possibility to decide if the current cursor position is inside the word the user currently is creating. Is there any infrastructure in place to help to solve that problem? I imagine something like a range variable starting to exist when the first character of a word is entered, growing until the user leaves this area or enters some delimiter like space or punctuation. When the word is complete this range should vanish (become empty). The only thing far related to this is the anchor of cursor, AFAICS. If nothing useful exists - where to add this? How many cursors exists in parallel? I think it should be added there. Any other idea? Stephan
Re: about continuous spellcheck
Am 31.01.2011 um 14:30 schrieb Stephan Witt:
Am 29.01.2011 um 21:14 schrieb Stephan Witt:
Am 29.01.2011 um 20:40 schrieb Edwin Leuven:
Stephan Witt st.w...@gmx.net wrote:
I already checked open-office, eclipse and apple mail.
All of them don't mark an unfinished word at first.
Apple mail has exact the same behavior as LyX has now.
Office and eclipse are doing the same as you are describing for word.
so wouldn't we like to maintain the misspell marker on word entry?
To be honest, the current implementation already was no simplification
of the code - to go on and add the distinction between first edit
and the latter ones when painting the misspelled marker is doable, but...
I may have a look, but I wouldn't wait with 2.0.0 beta4 because of that.
Dear buffer-view/cursor-experts,
I'm looking for a possibility to decide if the current cursor position is
inside the word the user currently is creating. Is there any infrastructure
in place to help to solve that problem? I imagine something like a range
variable starting to exist when the first character of a word is entered,
growing until the user leaves this area or enters some delimiter like space
or punctuation. When the word is complete this range should vanish (become
empty).
The only thing far related to this is the anchor of cursor, AFAICS.
Finally I have a basically working solution. See the attached patch.
I know, I've to add some comments. Please, can anyone try it?
I'd like to apply it if possible...
Stephan
Index: src/Paragraph.h
===
--- src/Paragraph.h (Revision 37410)
+++ src/Paragraph.h (Arbeitskopie)
@@ -77,12 +77,34 @@
{
return first == s.first last == s.last;
}
-
+
inline bool inside(pos_type p) const
{
return first = p p = last;
}
+ inline size_t size() const
+ {
+ return empty() ? 0 : last - first;
+ }
+
+
+ inline FontSpan intersect(FontSpan const f) const
+ {
+ FontSpan result = FontSpan();
+ if (inside(f.first))
+ result.first = f.first;
+ else if (f.inside(first))
+ result.first = first;
+ else
+ return result;
+ if (inside(f.last))
+ result.last = f.last;
+ else if (f.inside(last))
+ result.last = last;
+ return result;
+ }
+
inline bool empty() const
{
return first last;
Index: src/DocIterator.h
===
--- src/DocIterator.h (Revision 37410)
+++ src/DocIterator.h (Arbeitskopie)
@@ -25,6 +25,7 @@
class Paragraph;
class Text;
class InsetIterator;
+class FontSpan;
DocIterator doc_iterator_begin(Buffer const * buf, Inset const * inset = 0);
DocIterator doc_iterator_end(Buffer const * buf, Inset const * inset = 0);
@@ -162,6 +163,8 @@
/// return the inner text slice.
CursorSlice const innerTextSlice() const;
///
+ FontSpan locateWord(word_location const loc) const;
+ ///
Text * text() const;
/// the containing inset or the cell, respectively
Inset * realInset() const;
Index: src/DocIterator.cpp
===
--- src/DocIterator.cpp (Revision 37410)
+++ src/DocIterator.cpp (Arbeitskopie)
@@ -192,6 +192,16 @@
}
+FontSpan DocIterator::locateWord(word_location const loc) const
+{
+ FontSpan f = FontSpan();
+
+ f.first = pos();
+ top().paragraph().locateWord(f.first, f.last, loc);
+ return f;
+}
+
+
CursorSlice const DocIterator::innerTextSlice() const
{
LASSERT(!empty(), /**/);
Index: src/Cursor.h
===
--- src/Cursor.h(Revision 37410)
+++ src/Cursor.h(Arbeitskopie)
@@ -292,6 +292,11 @@
///
void checkBufferStructure();
+ DocIterator newWord() const { return new_word_; }
+ void markEditPosition();
+ void clearEditPosition();
+ void checkEditPosition();
+
public:
//private:
@@ -305,6 +310,8 @@
BufferView * bv_;
/// the anchor position
DocIterator anchor_;
+ /// the start of the new born word
+ DocIterator new_word_;
///
mutable DispatchResult disp_;
/**
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (Revision 37410)
+++ src/Cursor.cpp (Arbeitskopie)
@@ -503,6 +503,7 @@
void Cursor::resetAnchor()
{
anchor_ = *this;
+ checkEditPosition();
}
@@ -519,6 +520,38 @@
}
+void Cursor::markEditPosition()
+{
+ if (inTexted() new_word_.empty
Re: about continuous spellcheck
Am 02.02.2011 um 10:59 schrieb Edwin Leuven:
On Wed, Feb 2, 2011 at 09:33, Stephan Witt st.w...@gmx.net wrote:
Finally I have a basically working solution. See the attached patch.
thanks! it compiles fine
I know, I've to add some comments. Please, can anyone try it?
so the idea is that words that are being typed are not marked? i don't
see this...
Sorry, one changed file was missing in patch.
This is the complete patch.
The missing file in patch is src/BufferView.cpp
Stephan
Index: src/Paragraph.h
===
--- src/Paragraph.h (Revision 37410)
+++ src/Paragraph.h (Arbeitskopie)
@@ -77,12 +77,34 @@
{
return first == s.first last == s.last;
}
-
+
inline bool inside(pos_type p) const
{
return first = p p = last;
}
+ inline size_t size() const
+ {
+ return empty() ? 0 : last - first;
+ }
+
+
+ inline FontSpan intersect(FontSpan const f) const
+ {
+ FontSpan result = FontSpan();
+ if (inside(f.first))
+ result.first = f.first;
+ else if (f.inside(first))
+ result.first = first;
+ else
+ return result;
+ if (inside(f.last))
+ result.last = f.last;
+ else if (f.inside(last))
+ result.last = last;
+ return result;
+ }
+
inline bool empty() const
{
return first last;
Index: src/DocIterator.h
===
--- src/DocIterator.h (Revision 37410)
+++ src/DocIterator.h (Arbeitskopie)
@@ -25,6 +25,7 @@
class Paragraph;
class Text;
class InsetIterator;
+class FontSpan;
DocIterator doc_iterator_begin(Buffer const * buf, Inset const * inset = 0);
DocIterator doc_iterator_end(Buffer const * buf, Inset const * inset = 0);
@@ -162,6 +163,8 @@
/// return the inner text slice.
CursorSlice const innerTextSlice() const;
///
+ FontSpan locateWord(word_location const loc) const;
+ ///
Text * text() const;
/// the containing inset or the cell, respectively
Inset * realInset() const;
Index: src/DocIterator.cpp
===
--- src/DocIterator.cpp (Revision 37410)
+++ src/DocIterator.cpp (Arbeitskopie)
@@ -192,6 +192,16 @@
}
+FontSpan DocIterator::locateWord(word_location const loc) const
+{
+ FontSpan f = FontSpan();
+
+ f.first = pos();
+ top().paragraph().locateWord(f.first, f.last, loc);
+ return f;
+}
+
+
CursorSlice const DocIterator::innerTextSlice() const
{
LASSERT(!empty(), /**/);
Index: src/Cursor.h
===
--- src/Cursor.h(Revision 37410)
+++ src/Cursor.h(Arbeitskopie)
@@ -292,6 +292,11 @@
///
void checkBufferStructure();
+ DocIterator newWord() const { return new_word_; }
+ void markEditPosition();
+ void clearEditPosition();
+ void checkEditPosition();
+
public:
//private:
@@ -305,6 +310,8 @@
BufferView * bv_;
/// the anchor position
DocIterator anchor_;
+ /// the start of the new born word
+ DocIterator new_word_;
///
mutable DispatchResult disp_;
/**
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (Revision 37410)
+++ src/Cursor.cpp (Arbeitskopie)
@@ -503,6 +503,7 @@
void Cursor::resetAnchor()
{
anchor_ = *this;
+ checkEditPosition();
}
@@ -519,6 +520,38 @@
}
+void Cursor::markEditPosition()
+{
+ if (inTexted() new_word_.empty()) {
+ FontSpan ow = locateWord(WHOLE_WORD);
+ if (ow.size() == 1)
+ new_word_ = *this;
+ }
+}
+
+
+void Cursor::clearEditPosition()
+{
+ if (!new_word_.empty())
+ new_word_.resize(0);
+}
+
+
+void Cursor::checkEditPosition()
+{
+ if (inTexted() !new_word_.empty()) {
+ if (paragraph().id() != new_word_.paragraph().id())
+ clearEditPosition();
+ else {
+ FontSpan ow = locateWord(WHOLE_WORD);
+ FontSpan nw = new_word_.locateWord(WHOLE_WORD);
+ if (nw.intersect(ow).empty())
+ clearEditPosition();
+ }
+ }
+}
+
+
bool Cursor::posBackward()
{
if (pos() == 0)
Index: src/BufferView.cpp
===
--- src/BufferView.cpp (Revision 37410)
+++ src/BufferView.cpp (Arbeitskopie)
@@ -700,6 +700,7 @@
void BufferView
Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism
Am 27.01.2011 um 14:05 schrieb Walter:
...
2. Right click to set spellchecker language on a highlighted word fails [*]
It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
clicked, there is an option to set their language for spellchecking
purposes. However, this does not appear to actually do anything!
This makes it necessary for the user to select the word then use 'Edit|
Language|Whatever language' to actually perform the change - pointless
tedium.
You propose to auto extend the selection to word boundaries when setting
the language at a given position and no selection exists. That sounds
sensible...
Hurrah!
I'm violating the rule Never listen to users again :-)
The patch to auto-select the word for language change is attached.
Would that be ok?
Stephan
Index: src/Text3.cpp
===
--- src/Text3.cpp (Revision 37410)
+++ src/Text3.cpp (Arbeitskopie)
@@ -1889,6 +1890,10 @@
Language const * lang =
languages.getLanguage(to_utf8(cmd.argument()));
if (!lang)
break;
+ if (!cur.selection()) {
+ // apply to current word
+ selectWordWhenUnderCursor(cur, WHOLE_WORD);
+ }
Font font(ignore_font, lang);
toggleAndShow(cur, this, font);
break;
Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism
Am 02.02.2011 um 11:44 schrieb Jürgen Spitzmüller: Stephan Witt wrote: The patch to auto-select the word for language change is attached. Would that be ok? Looks good for me. I've put it in. Stephan
Re: Spell checking and breaking words
Am 02.02.2011 um 15:20 schrieb Jean-Marc Lasgouttes: I stumbled an interesting bug report related to words tokening in the spell checker. I did not understand everything but it seemed interesting enough to share (Stephan?) Still alive. :-) Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=355178 Corresponding bug in OpenOffice: http://www.openoffice.org/issues/show_bug.cgi?id=64400 Thanks. I have to go through that carefully. It looks like a scenario we have to care for. The long message Walter sent to users list on January, 26 did include this issue too. http://comments.gmane.org/gmane.editors.lyx.general/67979 (Point 4) Abdel said some time in the past there are tricky issues in mozilla and openoffice... I'd guess he referred to these things. Stephan
Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism
Am 02.02.2011 um 15:46 schrieb Jean-Marc Lasgouttes:
Le 02/02/2011 11:26, Stephan Witt a écrit :
+if (!cur.selection()) {
+// apply to current word
+selectWordWhenUnderCursor(cur, WHOLE_WORD);
+}
There is no need to test for selection, selectWordWhenUnderCursor does the
right thing already.
Ah, yes.
I copied and simplified the code from LFUN_SPELLING_ADD etc. without reading
the code in selectWordWhenUnderCursor :(
I'll change it.
Stephan
Re: about continuous spellcheck
Am 02.02.2011 um 11:41 schrieb Edwin Leuven:
On Wed, Feb 2, 2011 at 11:12, Stephan Witt st.w...@gmx.net wrote:
Sorry, one changed file was missing in patch.
This is the complete patch.
ok, this works great for me. thanks!
Now I've finished the patch.
- Fix a glitch when going from text to math.
- Added comments and debug messages.
This one I'd like to commit today. Any objections?
Stephan
Index: src/Paragraph.h
===
--- src/Paragraph.h (Revision 37451)
+++ src/Paragraph.h (Arbeitskopie)
@@ -77,12 +77,34 @@
{
return first == s.first last == s.last;
}
-
+
inline bool inside(pos_type p) const
{
return first = p p = last;
}
+ inline size_t size() const
+ {
+ return empty() ? 0 : last - first;
+ }
+
+
+ inline FontSpan intersect(FontSpan const f) const
+ {
+ FontSpan result = FontSpan();
+ if (inside(f.first))
+ result.first = f.first;
+ else if (f.inside(first))
+ result.first = first;
+ else
+ return result;
+ if (inside(f.last))
+ result.last = f.last;
+ else if (f.inside(last))
+ result.last = last;
+ return result;
+ }
+
inline bool empty() const
{
return first last;
Index: src/DocIterator.h
===
--- src/DocIterator.h (Revision 37451)
+++ src/DocIterator.h (Arbeitskopie)
@@ -25,6 +25,7 @@
class Paragraph;
class Text;
class InsetIterator;
+class FontSpan;
DocIterator doc_iterator_begin(Buffer const * buf, Inset const * inset = 0);
DocIterator doc_iterator_end(Buffer const * buf, Inset const * inset = 0);
@@ -161,6 +162,9 @@
Paragraph innerParagraph() const;
/// return the inner text slice.
CursorSlice const innerTextSlice() const;
+ /// the first and last positions of a word at top cursor slice
+ /// \warning only works within text!
+ FontSpan locateWord(word_location const loc) const;
///
Text * text() const;
/// the containing inset or the cell, respectively
Index: src/DocIterator.cpp
===
--- src/DocIterator.cpp (Revision 37451)
+++ src/DocIterator.cpp (Arbeitskopie)
@@ -192,6 +192,16 @@
}
+FontSpan DocIterator::locateWord(word_location const loc) const
+{
+ FontSpan f = FontSpan();
+
+ f.first = pos();
+ top().paragraph().locateWord(f.first, f.last, loc);
+ return f;
+}
+
+
CursorSlice const DocIterator::innerTextSlice() const
{
LASSERT(!empty(), /**/);
Index: src/Cursor.h
===
--- src/Cursor.h(Revision 37451)
+++ src/Cursor.h(Arbeitskopie)
@@ -292,6 +292,15 @@
///
void checkBufferStructure();
+ /// hook for text input to maintain the new born word
+ void markEditPosition();
+
+ /// The position of the new born word
+ /// As the user is entering a word without leaving it
+ /// the result is not empty. When not in text mode
+ /// and after leaving the word the result is empty.
+ DocIterator newWord() const { return new_word_; }
+
public:
//private:
@@ -301,10 +310,18 @@
void saveBeforeDispatchPosXY();
private:
+ /// validate the new born word position
+ void checkNewWordPosition();
+ /// clear the new born word position
+ void clearNewWordPosition();
+
+private:
///
BufferView * bv_;
/// the anchor position
DocIterator anchor_;
+ /// the start of the new born word
+ DocIterator new_word_;
///
mutable DispatchResult disp_;
/**
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (Revision 37451)
+++ src/Cursor.cpp (Arbeitskopie)
@@ -503,6 +503,7 @@
void Cursor::resetAnchor()
{
anchor_ = *this;
+ checkNewWordPosition();
}
@@ -519,6 +520,54 @@
}
+void Cursor::markEditPosition()
+{
+ if (inTexted() new_word_.empty()) {
+ FontSpan ow = locateWord(WHOLE_WORD);
+ if (ow.size() == 1) {
+ LYXERR(Debug::DEBUG, start new word:
+ par: pit()
+ pos: ow.first);
+ new_word_ = *this;
+ }
+ }
+}
+
+
+void Cursor::clearNewWordPosition()
+{
+ if (!new_word_.empty()) {
+ LYXERR(Debug::DEBUG, clear new word:
+ par: pit()
+ pos: pos
Re: LyX 1.6.9
Am 05.02.2011 um 10:16 schrieb Jürgen Spitzmüller: I've uploaded tarballs here: ftp://ftp.devel.lyx.org/pub/lyx/devel/lyx-1.6.9.tar.gz ftp://ftp.devel.lyx.org/pub/lyx/devel/lyx-1.6.9.tar.bz2 Please test and use these if you want to contribute binaries. I plan to release on Monday, if I get no bad report. I hope you're interested in success stories too :-) I built the package, used it to open and preview the users guide. No problems here at all on Mac OS X. Stephan
Re: #7209: assertion when clicking on unfinished command in math
Am 07.02.2011 um 21:15 schrieb LyX Ticket Tracker: #7209: assertion when clicking on unfinished command in math Ticket URL: http://www.lyx.org/trac/ticket/7209#comment:5 ---+ Reporter: uwestoehr |Owner: poenitz Type: defect | Status: reopened Priority: high |Milestone: 1.6.9 Component: mathed | Version: 1.6.8 Severity: critical | Resolution: Keywords: | ---+ Changes (by metrics): * status: closed = reopened * resolution: fixed = Comment: I can still reproduce this (or a related bug) in beta 4. Create a displayed math inset, type \var, wait for the autocompletion to appear, then _right_ click on the backslash. Indeed this is a related bug. The menu expansion crashes now in MenuDefinition::expandSpellingSuggestions(). I tried to add an early return there if we are in math mode. If I do so I can see the real cause for the problem: the right button opens the wrong menu. It should be the math context menu and in fact it is the normal text menu. But only the first time - if the crash is avoided every following right click opens the math menu. So, there is something wrong with the menu binding. I don't know enough about that machinery... but the early return patch only hides the root cause I think. Please, can any menu expert have a look? Stephan Index: src/frontends/qt4/Menus.cpp === --- src/frontends/qt4/Menus.cpp (Revision 37549) +++ src/frontends/qt4/Menus.cpp (Arbeitskopie) @@ -756,6 +756,8 @@ WordLangTuple wl; docstring_list suggestions; Cursor const cur = bv-cursor(); + if (!cur.inTexted()) + return; Paragraph const par = cur.paragraph(); pos_type from = cur.pos(); pos_type to = from;
Re: Regression in r37463 by switt: Crash when deleting footnote
Am 08.02.2011 um 10:27 schrieb Tommaso Cucinotta: Il 08/02/2011 09:20, John McCabe-Dansted ha scritto: KEYCODES: \Aifi\[Escape]\[BackSpace]\[!Loop] To Reproduce 1) Press Alt-I, F to insert a footnote 2) Press I to insert a character in the footnote 3) Press Escape to move the cursor outside the fotenote 4) Press BackSpace to delete the footnote I then get the crash below. This appears to be a regression in r37463 by switt. I am travelling and have not manually checked this. I can reproduce on Linux on current trunk. It happens also when inserting a URL or TeX-Code. Yes, I fixed this at r37563. BTW, you meant to say it happens when deleting the inserted URL? Thanks for the report. Stephan
Re: #7209: assertion when clicking on unfinished command in math
Am 08.02.2011 um 08:02 schrieb Stephan Witt: Am 07.02.2011 um 21:15 schrieb LyX Ticket Tracker: #7209: assertion when clicking on unfinished command in math Ticket URL: http://www.lyx.org/trac/ticket/7209#comment:5 ---+ Reporter: uwestoehr |Owner: poenitz Type: defect | Status: reopened Priority: high |Milestone: 1.6.9 Component: mathed | Version: 1.6.8 Severity: critical | Resolution: Keywords: | ---+ Changes (by metrics): * status: closed = reopened * resolution: fixed = Comment: I can still reproduce this (or a related bug) in beta 4. Create a displayed math inset, type \var, wait for the autocompletion to appear, then _right_ click on the backslash. Indeed this is a related bug. The menu expansion crashes now in MenuDefinition::expandSpellingSuggestions(). I tried to add an early return there if we are in math mode. If I do so I can see the real cause for the problem: the right button opens the wrong menu. It should be the math context menu and in fact it is the normal text menu. But only the first time - if the crash is avoided every following right click opens the math menu. So, there is something wrong with the menu binding. I don't know enough about that machinery... but the early return patch only hides the root cause I think. It turns out the problem is the missing metrics info somehow. BufferView::contextMenu() tries to choose the correct context menu for cursor position. This ends up in TextMetrics::checkInsetHit() ... ... there the math inset isn't found because probably it's metrics are not correct. So, finally the covering_inset in BufferView::contextMenu() is 0 and the default context menu context-edit is the result. Unfortunately it's not a good idea to try this on a math inset. To fix it we have to correct the metrics computation time. Is this a known issue? I'd guess that's not an easy business. Stephan
Re: r37364 - lyx-devel/trunk/development/autotests
Am 09.02.2011 um 00:30 schrieb Tommaso Cucinotta: Il 08/02/2011 22:41, Jean-Marc Lasgouttes ha scritto: Le 08/02/11 19:55, Tommaso Cucinotta a écrit : AFAICS, LyX installs with all the locales in e.g. /usr/local/lyx-trunk/share/locale/, so it should be able to run in whatever language I like. The only exception may be availability of additional fonts that I may need (e.g., starting it in Chinese...). IIRC some support files are needed for each locale at system level. I'm aware of these additional language packs or similar. Since the times I studied German, I use to have 3 keyboard layouts and 3 spelling dictionaries configured on my system: Italian, English and German. And on my system I can easily start LyX in these 3 languages (just recovered the working LANG syntax): $ LANG=it_IT.UTF-8 ./src/lyx $ LANG=en_GB.UTF-8 ./src/lyx $ LANG=de_DE.UTF-8 ./src/lyx However, AFAICS, the language packs I have installed system-wide are simply groups of translations for common applications. For example: $ dpkg -l | grep -e -it ii language-pack-it1:10.10+20101204 translation updates for language Italian ii language-pack-it-base 1:10.10+20100930 translations for language Italian ii language-support-it 1:9.10+20090909 metapackage for Italian language support ii language-support-writing-it 1:10.04+20100311 Writing aids metapackage for Italian ii myspell-it 1:3.2.1-2ubuntu1 Italian dictionary for myspell ii openoffice.org-hyphenation-it 1:3.2.1-2ubuntu1 Italian hyphenation patterns for OpenOffice.org ii openoffice.org-thesaurus-it 2.0.7.gh.deb1-1.1ubuntu1 Italian Thesaurus for OpenOffice.org 2 ii thunderbird-locale-it 1:3.1.2ubuntu1 Thunderbird Italian language/region package apart from the application-specific extensions for myspell, OpenOffice and Thunderbird, the remaining packages contain translation files for system and common tools, i.e.: /usr/share/locale-langpack/it/LC_MESSAGES/ /usr/share/locale-langpack/it/LC_MESSAGES/bash.mo ... /usr/share/locale-langpack/it/LC_MESSAGES/coreutils.mo ... /usr/share/locale-langpack/it/LC_MESSAGES/pulseaudio.mo ... Differently from some OSes in which you need a different installation CD for changing the GUI language (and perhaps format your hard-drive), luckily there are OSes in which that is not needed (however you get anyway a mix of English and the lang you'd like :-) ). But unfortunately all of this is Linux-specific. After some googling, I found that the LANG variable is not used on Mac OS-X (it is there only in the terminal for some compatibility), but there are system-wide lang prefs that are set from a GUI panel :-(. Also, the issue of customizing the locale from the command-line right when launching an app seems to not be felt by anyone. So, in the end I came up with the simple solution in the attached patch (apply from within autotests/), i.e., forcing a language preferences settings for LyX when it starts. I would be grateful if any Mac user could report whether this miserably fails as well :-) I can change the interface language when running the bundled LyX.app. I didn't try the autotest on mac by I'd be surprised if it works. LyX on mac doesn't use the X-server. Stephan
PATCH: lyxrc flag to disable kerning and ligature for row painter
I've a pending patch to fix the drawing issues with Qt4.7 we have when fonts
support kerning.
Until we provide a proper solution - not likely in LyX 2.0.0 - I propose to
paint every character separately.
Stephan
Index: src/LyXRC.h
===
--- src/LyXRC.h (Revision 37639)
+++ src/LyXRC.h (Arbeitskopie)
@@ -79,6 +79,7 @@
RC_EXAMPLEPATH,
RC_EXPORT_OVERWRITE,
RC_FONT_ENCODING,
+ RC_FORCE_PAINT_SINGLE_CHAR,
RC_FILEFORMAT,
RC_FORWARD_SEARCH_DVI,
RC_FORWARD_SEARCH_PDF,
@@ -527,6 +528,8 @@
};
///
ScrollWheelZoom scroll_wheel_zoom;
+ ///
+ bool force_paint_single_char;
};
Index: src/LyXRC.cpp
===
--- src/LyXRC.cpp (Revision 37639)
+++ src/LyXRC.cpp (Arbeitskopie)
@@ -99,6 +99,7 @@
{ \\example_path, LyXRC::RC_EXAMPLEPATH },
{ \\export_overwrite, LyXRC::RC_EXPORT_OVERWRITE },
{ \\font_encoding, LyXRC::RC_FONT_ENCODING },
+ { \\force_paint_single_char, LyXRC::RC_FORCE_PAINT_SINGLE_CHAR },
{ \\format, LyXRC::RC_FILEFORMAT },
{ \\forward_search_dvi, LyXRC::RC_FORWARD_SEARCH_DVI },
{ \\forward_search_pdf, LyXRC::RC_FORWARD_SEARCH_PDF },
@@ -422,6 +423,9 @@
if (!lexrc.isOK())
return ReadError;
+ // default for current rowpainter capabilities
+ force_paint_single_char = true;
+
// format prior to 2.0 and introduction of format tag
unsigned int format = 0;
@@ -523,6 +527,10 @@
lexrc fontenc;
break;
+ case RC_FORCE_PAINT_SINGLE_CHAR:
+ lexrc force_paint_single_char;
+ break;
+
case RC_PRINTER:
lexrc printer;
break;
@@ -2180,6 +2188,14 @@
if (tag != RC_LAST)
break;
+ case RC_FORCE_PAINT_SINGLE_CHAR:
+ if (ignore_system_lyxrc ||
+ force_paint_single_char !=
system_lyxrc.force_paint_single_char) {
+ os \\force_paint_single_char \
force_paint_single_char \\n;
+ }
+ if (tag != RC_LAST)
+ break;
+
os \n#\n
# FILE SECTION ##\n
#\n\n;
@@ -2880,6 +2896,7 @@
case LyXRC::RC_ESC_CHARS:
case LyXRC::RC_EXAMPLEPATH:
case LyXRC::RC_FONT_ENCODING:
+ case LyXRC::RC_FORCE_PAINT_SINGLE_CHAR:
case LyXRC::RC_FILEFORMAT:
case LyXRC::RC_GROUP_LAYOUTS:
case LyXRC::RC_HUNSPELLDIR_PATH:
@@ -3122,6 +3139,10 @@
str = _(The font encoding used for the LaTeX2e fontenc
package. T1 is highly recommended for non-English languages.);
break;
+ case RC_FORCE_PAINT_SINGLE_CHAR:
+ str = _(Disable any kerning and ligatures for text drawing on
screen.);
+ break;
+
case RC_FILEFORMAT:
break;
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 37639)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -261,9 +261,9 @@
// Maybe a more general fix would be draw character by character
// for some predefined fonts on some platform. In arabic and
// Hebrew we already do paint this way.
- if (prev_char == 'f')
+ if (prev_char == 'f' || lyxrc.force_paint_single_char)
break;
-
+
pos = bidi_.vis2log(vpos);
if (pos font_span.first || pos font_span.last)
break;
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp(Revision 37639)
+++ src/frontends/qt4/GuiApplication.cpp(Arbeitskopie)
@@ -1839,6 +1839,13 @@
if (d-global_menubar_)
d-global_menubar_-releaseKeyboard();
+#if QT_VERSION 0x040700
+ // the option to disable kerning in rowpainter
+ // is needed only with Qt4.7.0 or better
+ lyxrc.force_paint_single_char = false;
+ system_lyxrc.force_paint_single_char = false;
+#endif
+
// create new view
int id = view_id;
while (d-views_.find(id) != d-views_.end())
Re: r37635 - lyx-devel/trunk/lib/ui
Am 13.02.2011 um 12:38 schrieb Pavel Sanda: v...@lyx.org wrote: Author: vfr Date: Sun Feb 13 11:10:28 2011 New Revision: 37635 URL: http://www.lyx.org/trac/changeset/37635 Log: Add a context menu to InsetBibItem. Vincent, while seeing you alive again... :) can you have possibly look on bugs targetted on 2.0 which are connected to the code you know? there are some bugs connected to the comparison stuff, Yesterday I tried to reproduce it... and failed. Perhaps my document to test with is not appropriate. But there are many changes last 5 months. Are you able to crash LyX currently a la ticket 6879? Stephan
Re: PATCH: lyxrc flag to disable kerning and ligature for row painter
Am 13.02.2011 um 23:15 schrieb Pavel Sanda: Stephan Witt wrote: I've a pending patch to fix the drawing issues with Qt4.7 we have when fonts support kerning. Until we provide a proper solution - not likely in LyX 2.0.0 - I propose to paint every character separately. i dont have 4.7 to test here, but obvious question is performance impact. lyx painting in fullscreen mode is slow even now... have you tried some test? I cannot see a difference here. Open the (German) Users Guide, switch to full screen, start page down until end of document it lasts 15 seconds. I tried both, with single character painter and with the old version. But it's possible LyX has no problems only on *my* hardware. I'd like to get a feedback from someone else - or I'll do the tests on Linux in VMware and see what happens. Stephan
Re: PATCH: lyxrc flag to disable kerning and ligature for row painter
Am 14.02.2011 um 10:05 schrieb Jean-Marc Lasgouttes: Le 13/02/2011 13:14, Stephan Witt a écrit : I've a pending patch to fix the drawing issues with Qt4.7 we have when fonts support kerning. Until we provide a proper solution - not likely in LyX 2.0.0 - I propose to paint every character separately. Stephan If you do that, please remove the ugly explicit test on 'f' letter. Such hardcoding looks quite ugly to me :) We have two problems: * ligatures and * kerning The test for 'f' letter is needed because 'fl' painting/cursor positioning is broken. This is broken with Qt 4.6 too. The single character painter workaround is needed for kerning painting/ cursor positioning. This is new in Qt 4.7. Since I added the lyxrc option to disable single character mode for Qt 4.7 (as Abdel wanted) and ligature painting is broken for Qt 4.6 already I have to keep the additional test for ligatures. Of course I'd like to implement and propose a nifty solution - but I don't believe it is wise to introduce this in RC project phase. The alternative is to build LyX on all platforms with Qt 4.6 and refrain from using Qt 4.7. But then the test for 'f' is needed anyway. Both hacks will vanish with the correct metrics computation and caching. See the discussing and proposals here: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg164633.html Stephan BTW: it looks like Qt 4.7 is faster as Qt 4.6 is.
Re: option key not recognized in keybindings (Mac, trunk)
Am 17.02.2011 um 03:31 schrieb BH: On Wed, Feb 16, 2011 at 11:14 AM, Pavel Sanda sa...@lyx.org wrote: BH wrote: On Mac with current trunk, the option key is not recognized for any keybindings. (The Mac standard is for option-[arrow key] to move the cursor around by words/paragraphs, so this is a real problem.) Opening up the shortcuts preferences dialog, I find that all keybindings that previously were assigned to option now indicate that they are assigned to control instead (going by the symbol displayed in the dialog); however, the control key is ignored as well. Moreover, it is not possible to change the keybindings back to option using the dialog: trying to assign optionleft to word-left results in just the left key registering in the dialog. Note: the option key is also used to enter accents and other non-standard characters; this use is not affected. It's only LyX's keybindings that ignore option. could it be related to http://www.lyx.org/trac/ticket/7292 ? pavel That's definitely the culprit. Stephan? Yes, you're right. I missed that simple test. Sorry. One is able to use Ctrl-Arrow instead of Option-Arrow but that's of course not standard on Mac. You said this is not working for you? Here I can use it. Anyway, I'll revert the change and think of another solution. Note: the accents input is broken again after that. The correct solution is more work. The problem is the merge of MetaModifier and AltModifier done by LyX. LyX shouldn't fold both Modifiers to AltModifier (Option-Key on Mac). If this distinction is possible the key bindings on mac should changed for all accented keys from Alt to Meta (if it isn't Meta already). Stephan
Re: r37687 - in dictionaries/trunk: dicts thes
Am 16.02.2011 um 01:33 schrieb jo...@lyx.org:
Author: joost
Date: Wed Feb 16 01:33:18 2011
New Revision: 37687
URL: http://www.lyx.org/trac/changeset/37687
Log:
create subdirectories for dictionaries and thesaurus
Added:
dictionaries/trunk/dicts/
dictionaries/trunk/thes/
Sorry, I was offline for two days...
The name for the subdirectory in the LyX package below the system directory
where LyX is doing the dictionary lookup is dict.
In general I don't like directory renaming on install so much.
I propose to change LyX default lookup accordingly to avoid the SVN move.
Stephan
Index: src/HunspellChecker.cpp
===
--- src/HunspellChecker.cpp (Revision 37706)
+++ src/HunspellChecker.cpp (Arbeitskopie)
@@ -77,7 +77,7 @@
/// the location below system/user directory
/// there the aff+dic files lookup will happen
- const string dictDirectory(void) const { return dict; }
+ const string dictDirectory(void) const { return dicts; }
int maxLookupSelector(void) const { return 3; }
};
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp (Revision 37706)
+++ src/AspellChecker.cpp (Arbeitskopie)
@@ -88,7 +88,7 @@
/// the location below system/user directory
/// there the rws files lookup will happen
- const string dictDirectory(void) { return dict; }
+ const string dictDirectory(void) { return dicts; }
/// there the dat+cmap files lookup will happen
const string dataDirectory(void) { return data; }
/// os package directory constants
Re: Icons
Am 17.02.2011 um 23:47 schrieb Pavel Sanda: Joost Verburg wrote: be nice to have at least a little bit of UI refresh for 2.0 :) +1 2.0 is good excuse, but it should happen before RC. i would like to make freeze more strict once we enter it. What about the hopping train image? Stephan
Re: r37716 - lyx-devel/trunk/src
Am 18.02.2011 um 08:43 schrieb Jürgen Spitzmüller:
switt wrote:
+ string h_path = addName(hpath, lang-code() + - +
lang-variety()); + // first we try lang code+variety
+ if (!lang-variety().empty() haveLanguageFiles(h_path)) {
+ hpath = h_path;
+ return true;
+ }
+ // next we try lang code only
+ h_path = addName(hpath, lang-code());
+ if (haveLanguageFiles(h_path)) {
+ hpath = h_path;
+ return true;
+ }
why don't you use lang-id() here?
I couldn't decide until now what's correct.
The lang-id() is somewhat independent of the speller backend engine.
The Aspell backend uses the id for book-keeping but not for lookup.
So I didn't want to make Hunspell depending on the id() implementation.
Yesterday I already realized that I could have used lang-lang() instead.
All in all I need a unique id for the lang pointer.
Should I revert the id() part of my last change then?
Alternatively I can rename it to hunspellID() and use it in Hunspell code.
Stephan
Re: r37716 - lyx-devel/trunk/src
Am 18.02.2011 um 10:33 schrieb Jürgen Spitzmüller: Stephan Witt wrote: Should I revert the id() part of my last change then? No. What I mean is: doesn't somethong like the attached, simpler solution work equally well? Yes, but then IMHO we should rename Language::id() to Language::hunspellID()... Stephan
Re: r37716 - lyx-devel/trunk/src
Am 18.02.2011 um 10:55 schrieb Jürgen Spitzmüller:
Stephan Witt wrote:
Yes, but then IMHO we should rename Language::id() to
Language::hunspellID()...
But Aspell uses this id() as well, doesn't it?
I meant to do it like the attached patch.
Stephan
Index: src/Language.h
===
--- src/Language.h (Revision 37726)
+++ src/Language.h (Arbeitskopie)
@@ -58,7 +58,7 @@
/// set variety (needed for rc.spellchecker_alt_lang)
void setVariety(std::string const v) { variety_ = v; }
/// create a unique ID from lang code and variety
- std::string const id() const {
+ std::string const hunspellID() const {
return variety_.empty() ? code_ : code_ + - + variety_; }
/// preamble settings after babel was called
std::string const babel_postsettings() const { return
babel_postsettings_; }
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp (Revision 37726)
+++ src/AspellChecker.cpp (Arbeitskopie)
@@ -270,14 +270,14 @@
initSessionDictionary(m, pd);
}
- spellers_[lang-id()] = m;
+ spellers_[lang-lang()] = m;
return m.e_speller ? to_aspell_speller(m.e_speller) : 0;
}
AspellSpeller * AspellChecker::Private::speller(Language const * lang)
{
- Spellers::iterator it = spellers_.find(lang-id());
+ Spellers::iterator it = spellers_.find(lang-lang());
if (it != spellers_.end())
return to_aspell_speller(it-second.e_speller);
@@ -307,7 +307,7 @@
if (!pd)
return;
pd-remove(word.word());
- Spellers::iterator it = spellers_.find(word.lang()-id());
+ Spellers::iterator it = spellers_.find(word.lang()-lang());
if (it != spellers_.end()) {
initSessionDictionary(it-second, pd);
}
@@ -316,7 +316,7 @@
void AspellChecker::Private::insert(WordLangTuple const word)
{
- Spellers::iterator it = spellers_.find(word.lang()-id());
+ Spellers::iterator it = spellers_.find(word.lang()-lang());
if (it != spellers_.end()) {
AspellSpeller * speller =
to_aspell_speller(it-second.e_speller);
aspell_speller_add_to_session(speller,
to_utf8(word.word()).c_str(), -1);
@@ -380,7 +380,7 @@
void AspellChecker::accept(WordLangTuple const word)
{
- Spellers::iterator it = d-spellers_.find(word.lang()-id());
+ Spellers::iterator it = d-spellers_.find(word.lang()-lang());
if (it != d-spellers_.end()) {
AspellSpeller * speller =
to_aspell_speller(it-second.e_speller);
aspell_speller_add_to_session(speller,
to_utf8(word.word()).c_str(), -1);
Index: src/HunspellChecker.cpp
===
--- src/HunspellChecker.cpp (Revision 37726)
+++ src/HunspellChecker.cpp (Arbeitskopie)
@@ -139,9 +139,9 @@
}
LYXERR(Debug::FILES, check hunspell path: hpath for language
lang);
- string h_path = addName(hpath, lang-code() + - + lang-variety());
+ string h_path = addName(hpath, lang-hunspellID());
// first we try lang code+variety
- if (!lang-variety().empty() haveLanguageFiles(h_path)) {
+ if (lang-hunspellID() != lang-code() haveLanguageFiles(h_path)) {
hpath = h_path;
return true;
}
@@ -178,7 +178,7 @@
Hunspell * HunspellChecker::Private::speller(Language const * lang)
{
- Spellers::iterator it = spellers_.find(lang-id());
+ Spellers::iterator it = spellers_.find(lang-lang());
if (it != spellers_.end())
return it-second;
@@ -189,7 +189,7 @@
Hunspell * HunspellChecker::Private::addSpeller(Language const * lang,string
path)
{
if (!haveDictionary(lang, path)) {
- spellers_[lang-id()] = 0;
+ spellers_[lang-lang()] = 0;
return 0;
}
@@ -197,7 +197,7 @@
FileName const dict(path + .dic);
Hunspell * h = new Hunspell(affix.absFileName().c_str(),
dict.absFileName().c_str());
LYXERR(Debug::FILES, Hunspell speller for langage lang at
dict found);
- spellers_[lang-id()] = h;
+ spellers_[lang-lang()] = h;
return h;
}
Re: r37716 - lyx-devel/trunk/src
Am 18.02.2011 um 11:34 schrieb Jürgen Spitzmüller: Jürgen Spitzmüller wrote: I meant to do it like the attached patch. I don't like the idea of putting speller-specific code to Language. Using lang() as a unique identifier is probably a good idea, though. IOW I'd move the hunspellID code to HunspellChecker. Ok. And leave the id() method in Language? And still, my proposed simplification would apply. Then there would only one lookup per language. German = de_DE German(old) = de-alt This may be ok with the dictionaries we distribute ourself. There we have control over the names. But the user may point hunspell to another location. The current lookup tries code + variety only if variety is not empty. After that it makes a lookup with code only. In case of empty variety your simplification does the same as mine. In case of non-empty variety it discards a lookup. Do want to achieve that because you think it's more correct? Stephan
Re: r37716 - lyx-devel/trunk/src
Am 18.02.2011 um 12:12 schrieb Jürgen Spitzmüller:
Stephan Witt wrote:
IOW I'd move the hunspellID code to HunspellChecker.
Ok. And leave the id() method in Language?
It is not used currentyl, so it should be ditched.
And still, my proposed
simplification would apply.
Then there would only one lookup per language.
German = de_DE
German(old) = de-alt
This may be ok with the dictionaries we distribute ourself.
There we have control over the names.
But the user may point hunspell to another location.
The current lookup tries code + variety only if variety is not empty.
After that it makes a lookup with code only.
In case of empty variety your simplification does the same as mine.
In case of non-empty variety it discards a lookup.
Do want to achieve that because you think it's more correct?
Yes. In the only case with variety we have now, german, this would load the
ngerman dictionary for german, which is obviously not correct.
Then we have this updated patch. Ok?
Stephan
Index: src/Language.h
===
--- src/Language.h (Revision 37726)
+++ src/Language.h (Arbeitskopie)
@@ -57,9 +57,6 @@
std::string const variety() const { return variety_; }
/// set variety (needed for rc.spellchecker_alt_lang)
void setVariety(std::string const v) { variety_ = v; }
- /// create a unique ID from lang code and variety
- std::string const id() const {
- return variety_.empty() ? code_ : code_ + - + variety_; }
/// preamble settings after babel was called
std::string const babel_postsettings() const { return
babel_postsettings_; }
/// preamble settings before babel is called
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp (Revision 37726)
+++ src/AspellChecker.cpp (Arbeitskopie)
@@ -270,14 +270,14 @@
initSessionDictionary(m, pd);
}
- spellers_[lang-id()] = m;
+ spellers_[lang-lang()] = m;
return m.e_speller ? to_aspell_speller(m.e_speller) : 0;
}
AspellSpeller * AspellChecker::Private::speller(Language const * lang)
{
- Spellers::iterator it = spellers_.find(lang-id());
+ Spellers::iterator it = spellers_.find(lang-lang());
if (it != spellers_.end())
return to_aspell_speller(it-second.e_speller);
@@ -307,7 +307,7 @@
if (!pd)
return;
pd-remove(word.word());
- Spellers::iterator it = spellers_.find(word.lang()-id());
+ Spellers::iterator it = spellers_.find(word.lang()-lang());
if (it != spellers_.end()) {
initSessionDictionary(it-second, pd);
}
@@ -316,7 +316,7 @@
void AspellChecker::Private::insert(WordLangTuple const word)
{
- Spellers::iterator it = spellers_.find(word.lang()-id());
+ Spellers::iterator it = spellers_.find(word.lang()-lang());
if (it != spellers_.end()) {
AspellSpeller * speller =
to_aspell_speller(it-second.e_speller);
aspell_speller_add_to_session(speller,
to_utf8(word.word()).c_str(), -1);
@@ -380,7 +380,7 @@
void AspellChecker::accept(WordLangTuple const word)
{
- Spellers::iterator it = d-spellers_.find(word.lang()-id());
+ Spellers::iterator it = d-spellers_.find(word.lang()-lang());
if (it != d-spellers_.end()) {
AspellSpeller * speller =
to_aspell_speller(it-second.e_speller);
aspell_speller_add_to_session(speller,
to_utf8(word.word()).c_str(), -1);
Index: src/HunspellChecker.cpp
===
--- src/HunspellChecker.cpp (Revision 37726)
+++ src/HunspellChecker.cpp (Arbeitskopie)
@@ -79,6 +79,11 @@
/// there the aff+dic files lookup will happen
const string dictDirectory(void) const { return dicts; }
int maxLookupSelector(void) const { return 3; }
+ const string HunspellDictionaryName(Language const * lang) {
+ return lang-variety().empty()
+ ? lang-code()
+ : lang-code() + - + lang-variety();
+ }
};
@@ -139,19 +144,13 @@
}
LYXERR(Debug::FILES, check hunspell path: hpath for language
lang);
- string h_path = addName(hpath, lang-code() + - + lang-variety());
+ string h_path = addName(hpath, HunspellDictionaryName(lang));
// first we try lang code+variety
- if (!lang-variety().empty() haveLanguageFiles(h_path)) {
- hpath = h_path;
- return true;
- }
- // next we try lang code only
- h_path = addName(hpath, lang-code());
if (haveLanguageFiles(h_path)) {
hpath = h_path;
return true;
}
- // last try with '_' replaced
Re: Foreign language marker
Am 18.02.2011 um 16:25 schrieb Jürgen Spitzmüller: Can we please make the line that marks foerign languages thinner again (preferably as in branch)? This thick rule annoys me a lot. I'll try to change that. Stephan
Re: Foreign language marker
Am 19.02.2011 um 01:42 schrieb Stephan Witt:
Am 18.02.2011 um 16:25 schrieb Jürgen Spitzmüller:
Can we please make the line that marks foerign languages thinner again
(preferably as in branch)? This thick rule annoys me a lot.
I'll try to change that.
This patch does it - separate scaling for dotted and for solid lines.
Ok to apply?
Stephan
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 37728)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -63,17 +63,26 @@
pm_(text_metrics_.parMetrics(pit)),
bidi_(bidi), change_(pi_.change_),
xo_(x), yo_(y), width_(text_metrics_.width()),
- line_thickness_(1.0), line_offset_(2)
+ solid_line_thickness_(1.0), solid_line_offset_(1),
+ dotted_line_thickness_(1.0), dotted_line_offset_(2)
{
bidi_.computeTables(par_, pi_.base.bv-buffer(), row_);
+ if (lyxrc.zoom = 200) {
+ // derive the line thickness from zoom factor
+ // the zoom is given in percent
+ // (increase thickness at 250%, 450% etc.)
+ solid_line_thickness_ = (float)(int((lyxrc.zoom + 50) / 200.0));
+ // adjust line_offset_ too
+ solid_line_offset_ = 1 + int(0.5 * solid_line_thickness_);
+ }
if (lyxrc.zoom = 100) {
// derive the line thickness from zoom factor
// the zoom is given in percent
// (increase thickness at 150%, 250% etc.)
- line_thickness_ = (float)(int((lyxrc.zoom + 50) / 100.0));
+ dotted_line_thickness_ = (float)(int((lyxrc.zoom + 50) /
100.0));
// adjust line_offset_ too
- line_offset_ = int(2 * line_thickness_) + 1;
+ dotted_line_offset_ = int(0.5 * dotted_line_thickness_) + 1;
}
x_ = row_.x + xo_;
@@ -362,9 +371,9 @@
if (lang == pi_.base.bv-buffer().params().language)
return;
- int const y = yo_ + 1 + desc + int(line_thickness_/2);
+ int const y = yo_ + solid_line_offset_ + desc +
int(solid_line_thickness_/2);
pi_.pain.line(int(orig_x), y, int(x_), y, Color_language,
- Painter::line_solid, line_thickness_);
+ Painter::line_solid, solid_line_thickness_);
}
@@ -372,9 +381,11 @@
{
// if changed the misspelled marker gets placed slightly lower than
normal
// to avoid drawing at the same vertical offset
- int const y = yo_ + (changed ? int(line_thickness_ + 1.0) : 0) +
line_offset_;
+ int const y = yo_ + solid_line_offset_ + solid_line_thickness_
+ + (changed ? solid_line_thickness_ + 1 : 0)
+ + dotted_line_offset_;
pi_.pain.line(int(orig_x), y, int(x_), y, Color_error,
- Painter::line_onoffdash, line_thickness_);
+ Painter::line_onoffdash, dotted_line_thickness_);
}
@@ -886,9 +897,9 @@
FontMetrics const fm
=
theFontMetrics(pi_.base.bv-buffer().params().getFont());
int const y_bar = change_running.deleted() ?
- yo_ - fm.maxAscent() / 3 : yo_ + line_offset_;
+ yo_ - fm.maxAscent() / 3 : yo_ + 2 *
solid_line_offset_ + solid_line_thickness_;
pi_.pain.line(change_last_x, y_bar, int(x_), y_bar,
- change_running.color(), Painter::line_solid,
line_thickness_);
+ change_running.color(), Painter::line_solid,
solid_line_thickness_);
// Change might continue with a different author or type
if (change.changed() !highly_editable_inset) {
@@ -946,9 +957,9 @@
FontMetrics const fm
=
theFontMetrics(pi_.base.bv-buffer().params().getFont());
int const y_bar = change_running.deleted() ?
- yo_ - fm.maxAscent() / 3 : yo_ + line_offset_;
+ yo_ - fm.maxAscent() / 3 : yo_ + 2 *
solid_line_offset_ + solid_line_thickness_;
pi_.pain.line(change_last_x, y_bar, int(x_), y_bar,
- change_running.color(), Painter::line_solid,
line_thickness_);
+ change_running.color(), Painter::line_solid,
solid_line_thickness_);
change_running.setUnchanged();
}
}
Index: src/rowpainter.h
===
--- src/rowpainter.h(Revision 37728)
+++ src/rowpainter.h(Arbeitskopie)
@@ -104,8 +104,10 @@
int const yo_;// current baseline
double x_;
int width_;
- float line_thickness_;
- int line_offset_;
+ float solid_line_thickness_;
+ int solid_line_offset_;
+ float dotted_line_thickness_;
+ int
Re: option key not recognized in keybindings (Mac, trunk)
Am 17.02.2011 um 07:40 schrieb Stephan Witt: Am 17.02.2011 um 03:31 schrieb BH: On Wed, Feb 16, 2011 at 11:14 AM, Pavel Sanda sa...@lyx.org wrote: BH wrote: On Mac with current trunk, the option key is not recognized for any keybindings. (The Mac standard is for option-[arrow key] to move the cursor around by words/paragraphs, so this is a real problem.) Opening up the shortcuts preferences dialog, I find that all keybindings that previously were assigned to option now indicate that they are assigned to control instead (going by the symbol displayed in the dialog); however, the control key is ignored as well. Moreover, it is not possible to change the keybindings back to option using the dialog: trying to assign optionleft to word-left results in just the left key registering in the dialog. Note: the option key is also used to enter accents and other non-standard characters; this use is not affected. It's only LyX's keybindings that ignore option. could it be related to http://www.lyx.org/trac/ticket/7292 ? pavel That's definitely the culprit. Stephan? Yes, you're right. I missed that simple test. Sorry. One is able to use Ctrl-Arrow instead of Option-Arrow but that's of course not standard on Mac. You said this is not working for you? Here I can use it. Anyway, I'll revert the change and think of another solution. Note: the accents input is broken again after that. The correct solution is more work. The problem is the merge of MetaModifier and AltModifier done by LyX. LyX shouldn't fold both Modifiers to AltModifier (Option-Key on Mac). If this distinction is possible the key bindings on mac should changed for all accented keys from Alt to Meta (if it isn't Meta already). One general question: why is Alt and Meta in LyX key bindings the same? In Qt we have four modifier keys: shift, control, alt and meta. The bind files has M as synonym for alt, and A isn't usable. If the user presses the Meta key it is translated to AltModifier and then matches the M in bind file. Why this confusion!? Isn't it better to make this consistent? Which platform needs this mixup of things? Stephan
Re: option key not recognized in keybindings (Mac, trunk)
Am 20.02.2011 um 15:11 schrieb Pavel Sanda: Stephan Witt wrote: One general question: why is Alt and Meta in LyX key bindings the same? because most of the keyboards nowadays dont have meta key? i remember to see it on some sun keyboards in one of our uni labs 10 years back. they looked archeological even at that time :) If I remember right this was mapped to Super in xev. Which platform needs this mixup of things? i guess it will be only very specialized archs which know meta. on pc based it will be emulated by alt today and with another key at mac, so our usage of 'M' looks having only historical meaning. On a mac this is very bad. I can circumvent this with many many #ifdef's but it would be easier if Alt key makes AltModifier and Meta makes MetaModifier. Another ugly solution (but somewhat logical) would be to make MetaModifier coded as A. I can understand it is a big big change to custom bind files. I don't had a really good idea until now... Stephan
Re: r37666 - lyx-devel/trunk/lib/bind
Am 14.02.2011 um 21:31 schrieb sa...@lyx.org: Author: sanda Date: Mon Feb 14 21:31:46 2011 New Revision: 37666 URL: http://www.lyx.org/trac/changeset/37666 Log: Give new shortcut for default viewing. http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg165590.html Closing #5258. Modified: lyx-devel/trunk/lib/bind/cua.bind I think this should be done for mac.bind too? Stephan
Re: r37666 - lyx-devel/trunk/lib/bind
Am 20.02.2011 um 18:08 schrieb Pavel Sanda: Stephan Witt wrote: Am 14.02.2011 um 21:31 schrieb sa...@lyx.org: Author: sanda Date: Mon Feb 14 21:31:46 2011 New Revision: 37666 URL: http://www.lyx.org/trac/changeset/37666 Log: Give new shortcut for default viewing. http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg165590.html Closing #5258. Modified: lyx-devel/trunk/lib/bind/cua.bind I think this should be done for mac.bind too? i thought mac is derived from cua. mac.bind is an alternate entry point to use instead of cua.bind. if not then we need to add it as well. Yes, I can do it. (perhaps we should share the same bindings and inherit them in both cua and mac?) This is done already for many bindings but not for all. Stephan
Re: option key not recognized in keybindings (Mac, trunk)
Am 20.02.2011 um 15:28 schrieb Pavel Sanda:
Stephan Witt wrote:
I can circumvent this with many many #ifdef's but it would be easier
if Alt key makes AltModifier and Meta makes MetaModifier.
this strikes me as a correct solution. and all our 'M' chars in bind files
should be 'A' then. however i'm doubtful about pushing this change to the tree
at the current stage of development...
Then I'd like to go with the #ifdef variant.
Attached is a patch to make it possible on Mac to bind Meta- and Alt-Modifier
separately.
Included is the change of the key bindings to preserve the standard navigation.
I'd like to put it in before RC because the result is IMHO the correct behavior.
Bennett, are you able to test this patch? If it works in principle we should
review
carefully the key bindings in mac.bind and use it.
Stephan
Index: src/frontends/KeyModifier.h
===
--- src/frontends/KeyModifier.h (Revision 37748)
+++ src/frontends/KeyModifier.h (Arbeitskopie)
@@ -21,8 +21,9 @@
enum KeyModifier {
NoModifier = 0, // no modifiers held
ControlModifier = 1, // control button held
- AltModifier = 2, // alt/meta key held
- ShiftModifier= 4 // shift key held
+ AltModifier = 2, // alt key held
+ ShiftModifier= 4, // shift key held
+ MetaModifier = 8 // meta key held
};
Index: src/KeyMap.cpp
===
--- src/KeyMap.cpp (Revision 37748)
+++ src/KeyMap.cpp (Arbeitskopie)
@@ -45,8 +45,15 @@
if (mod ControlModifier)
buf += C-;
+#ifdef USE_MACOSX_PACKAGING
+ if (mod MetaModifier)
+ buf += M-;
if (mod AltModifier)
+ buf += A-;
+#else
+ if (mod AltModifier)
buf += M-;
+#endif
if (mod ShiftModifier)
buf += S-;
Index: src/KeySequence.cpp
===
--- src/KeySequence.cpp (Revision 37748)
+++ src/KeySequence.cpp (Arbeitskopie)
@@ -70,6 +70,12 @@
i += 2;
continue;
case 'm': case 'M':
+#ifdef USE_MACOSX_PACKAGING
+ mod |= MetaModifier;
+ i += 2;
+ continue;
+#endif
+ case 'a': case 'A':
mod |= AltModifier;
i += 2;
continue;
@@ -88,6 +94,12 @@
i += 3;
continue;
case 'm': case 'M':
+#ifdef USE_MACOSX_PACKAGING
+ nmod |= MetaModifier;
+ i += 3;
+ continue;
+#endif
+ case 'a': case 'A':
nmod |= AltModifier;
i += 3;
continue;
@@ -141,6 +153,10 @@
if (mod ControlModifier)
buf += C-;
if (mod AltModifier)
+#ifdef USE_MACOSX_PACKAGING
+ buf += A-;
+ if (mod MetaModifier)
+#endif
buf += M-;
if (mod ShiftModifier)
buf += S-;
Index: src/frontends/qt4/GuiKeySymbol.cpp
===
--- src/frontends/qt4/GuiKeySymbol.cpp (Revision 37748)
+++ src/frontends/qt4/GuiKeySymbol.cpp (Arbeitskopie)
@@ -693,6 +693,8 @@
tmpkey += Qt::ControlModifier;
if (mod AltModifier)
tmpkey += Qt::AltModifier;
+ if (mod MetaModifier)
+ tmpkey += Qt::MetaModifier;
QKeySequence seq(tmpkey);
QString str;
@@ -744,8 +746,15 @@
k |= ControlModifier;
if (state Qt::ShiftModifier)
k |= ShiftModifier;
- if (state Qt::AltModifier || state Qt::MetaModifier)
+ if (state Qt::AltModifier)
k |= AltModifier;
+#ifdef USE_MACOSX_PACKAGING
+ if (state Qt::MetaModifier)
+ k |= MetaModifier;
+#else
+ if (state Qt::MetaModifier)
+ k |= AltModifier;
+#endif
return k;
}
Index: lib/bind/mac.bind
===
--- lib/bind/mac.bind (Revision 37748)
+++ lib/bind/mac.bind (Arbeitskopie)
@@ -96,10 +96,10 @@
\bind C-gword-find
\bind C-F4 buffer-close
\bind F5 screen-recenter
-\bind C-M-Up scroll line up
-\bind C-M-Down scroll line down
-\bind C-M-Prior scroll page up
-\bind C
Re: option key not recognized in keybindings (Mac, trunk)
Am 21.02.2011 um 10:59 schrieb Pavel Sanda: Stephan Witt wrote: +MetaModifier = 8 // meta key held //for mac key XXX -if (state Qt::AltModifier || state Qt::MetaModifier) +if (state Qt::AltModifier) k |= AltModifier; isn't possible we are going to break something here on other archs? You told me only a mac and old suns have a meta key ;-) But seriously, the resulting code snippet is this one: == if (state Qt::AltModifier) k |= AltModifier; #ifdef USE_MACOSX_PACKAGING if (state Qt::MetaModifier) k |= MetaModifier; #else if (state Qt::MetaModifier) k |= AltModifier; #endif == It's effectively the same for non-macs after all. Alt- and Meta-Modifier will be mapped to KeyModifier::AltModifier. +#ifdef USE_MACOSX_PACKAGING +if (state Qt::MetaModifier) +k |= MetaModifier; +#else +if (state Qt::MetaModifier) +k |= AltModifier; +#endif return k; } otherwise look ok. Thanks, I'll wait a little bit for Bennett's reply. Stephan
Re: option key not recognized in keybindings (Mac, trunk)
Am 21.02.2011 um 14:29 schrieb BH: On Mon, Feb 21, 2011 at 6:11 AM, Stephan Witt st.w...@gmx.net wrote: Thanks, I'll wait a little bit for Bennett's reply. I'm not entirely sure what the patch is supposed to do, but for the most part it seems to work. Except for opt[arrow-key], it looks like all keybindings that were formally opt have now been switch to control. Exactly. The idea is that Option-M or Option-A should move to Control-M resp. Control-A. These Option- keys should produce å and µ. The navigation short-cuts should be as close as possible to the mac standard. Is there something else I should be testing? We need to verify the changed key bindings. One problem here: The switch includes custom keybindings, which means that my keybindings have all of a sudden changed on me without warning, which is not something I think we should do to users, though I'm not sure how to handle the transition. (Fortunately, it's possible to change them back manually, but that's potentially a tedious hassle for some users like me who have many custom keybindings.) Can you give an example? As said before - for Option-M there is nothing we can do. It's a mistake it was used as short-cut for math-menu before. But others perhaps we can duplicate for Option and Control. Another problem that I noted that I assume is unrelated to this patch: with the Open documents in tabs preference setting unchecked, I can no longer open two or more documents in the same window. (Formerly I could do this by selecting a hidden document from within an already open document.) I discovered this when trying to test cmdoptleft/right, which I use (like on Firefox) to switch between tabs. Shall I create a separate bug report for this? I don't know if it should work like you describe. Vincent? Thanks for testing, Stephan
Re: option key not recognized in keybindings (Mac, trunk)
Am 21.02.2011 um 15:11 schrieb BH: On Mon, Feb 21, 2011 at 8:47 AM, Stephan Witt st.w...@gmx.net wrote: Am 21.02.2011 um 14:29 schrieb BH: On Mon, Feb 21, 2011 at 6:11 AM, Stephan Witt st.w...@gmx.net wrote: Thanks, I'll wait a little bit for Bennett's reply. I'm not entirely sure what the patch is supposed to do, but for the most part it seems to work. Except for opt[arrow-key], it looks like all keybindings that were formally opt have now been switch to control. Exactly. The idea is that Option-M or Option-A should move to Control-M resp. Control-A. These Option- keys should produce å and µ. Yes. The navigation short-cuts should be as close as possible to the mac standard. I had focused on testing keybindings with Opt in them. Testing a little more on navigation I find that Cmd[arrow keys] don't work. (They are instead mapped to Ctrl[arrow-keys].) This should be fixed -- along with the Shift variants, of course. This I did intentionally - I've mapped Cmd-Up/Down to move between the workspaces of Expose. But you're right, I should change that on my computer and correct LyX's key bindings. Here I found a list of shortcuts... http://www.hcs.harvard.edu/~jrus/Site/System%20Bindings.html Would you rate this as a correct reference? Is there something else I should be testing? We need to verify the changed key bindings. One problem here: The switch includes custom keybindings, which means that my keybindings have all of a sudden changed on me without warning, which is not something I think we should do to users, though I'm not sure how to handle the transition. (Fortunately, it's possible to change them back manually, but that's potentially a tedious hassle for some users like me who have many custom keybindings.) Can you give an example? As said before - for Option-M there is nothing we can do. It's a mistake it was used as short-cut for math-menu before. But others perhaps we can duplicate for Option and Control. As I said, these are custom keybindings. So I previously used optcmd[number] to set bookmarks; now this is ctrlcmd[number]. In every case, the change shows up in Preferences Editing Shortcuts, and I can manually change it back. Note: You are used to use optcmd[number] to set a bookmark. But I'm almost sure ctrlcmd[number] did the same before. Now this is the only short-cut which is working for you. Stephan
Re: option key not recognized in keybindings (Mac, trunk)
Am 21.02.2011 um 15:49 schrieb BH: Here I found a list of shortcuts... http://www.hcs.harvard.edu/~jrus/Site/System%20Bindings.html Would you rate this as a correct reference? Yes. Apple's list is here: http://support.apple.com/kb/HT1343 Thanks. but it looks pretty much the same. The only thing I'd question about the harvard.edu list is the use of Home and End to scroll to beginning and end of the document. I'd continue to use them as alternatives for Cmdleft/right arrow to move to beginning and end of lines. +1. On my laptop I don't have them. One problem here: The switch includes custom keybindings, which means that my keybindings have all of a sudden changed on me without warning, which is not something I think we should do to users, though I'm not sure how to handle the transition. (Fortunately, it's possible to change them back manually, but that's potentially a tedious hassle for some users like me who have many custom keybindings.) Can you give an example? As said before - for Option-M there is nothing we can do. It's a mistake it was used as short-cut for math-menu before. But others perhaps we can duplicate for Option and Control. As I said, these are custom keybindings. So I previously used optcmd[number] to set bookmarks; now this is ctrlcmd[number]. In every case, the change shows up in Preferences Editing Shortcuts, and I can manually change it back. Note: You are used to use optcmd[number] to set a bookmark. But I'm almost sure ctrlcmd[number] did the same before. Now this is the only short-cut which is working for you. This wasn't true for me. ctrl previously was entirely ignored by LyX, and so typing ctrlcmd[number] was equivalent to typing cmd[number]. (Or am I not understanding what you mean?) Hmm... I tried LyX-2.0-svn and cross checked with LyX-2.0-alpha3... If I look at the messages with keyboard debug enabled I can see that Ctrl- is detected on both. I didn't check 1.6.x though. Currently Command-Control-1 is save-bookmark 1 - we can duplicate it to Command-Option-1 etc. Stephan
Re: option key not recognized in keybindings (Mac, trunk)
Am 21.02.2011 um 16:43 schrieb BH:
Can you give an example? As said before - for Option-M there is nothing
we can do. It's a mistake it was used as short-cut for math-menu before.
But others perhaps we can duplicate for Option and Control.
As I said, these are custom keybindings. So I previously used
optcmd[number] to set bookmarks; now this is ctrlcmd[number].
In every case, the change shows up in Preferences Editing
Shortcuts, and I can manually change it back.
Note: You are used to use optcmd[number] to set a bookmark.
But I'm almost sure ctrlcmd[number] did the same before.
Now this is the only short-cut which is working for you.
This wasn't true for me. ctrl previously was entirely ignored by
LyX, and so typing ctrlcmd[number] was equivalent to typing
cmd[number]. (Or am I not understanding what you mean?)
Hmm... I tried LyX-2.0-svn and cross checked with LyX-2.0-alpha3...
If I look at the messages with keyboard debug enabled I can see
that Ctrl- is detected on both. I didn't check 1.6.x though.
Currently Command-Control-1 is save-bookmark 1 - we can duplicate
it to Command-Option-1 etc.
I guess you're right (I went back and checked with 1.6.9) -- I'm just
woefully out of date. Really, ctrl *used to be* simply ignored ...
back in the dark ages (I may be old enough to remember the dark
ages, but not so old as to question my memory on this!)
So let me give another example of what was genuinely a custom
keybinding. I had optcmdshiftB set to toggle toolbar visibility.
Now that no longer works, but instead ctrlcmdshiftB does.
This indeed I would not solve, the custom keybinding changes then.
If one want to see it this way. In fact only the opt variant isn't
accessible anymore - the ctrl variant is untouched.
I'd solve it by adding a sentence to the RELEASE-NOTES (ToDo).
I've made another patch with the following changes:
* add a check for USE_META_KEYBINDING macro
one can check the code on Linux or Windows when it's set
* check for already containing modifiers in KeySymbol::print()
not really needed - I can leave this out if controversial
* add some key state output for debug in GuiWorkArea::keyPressEvent()
not really needed either
* remove duplicate debug output from GuiApplication::processKeySym()
ditto
* overhauled and reorganized mac.bind file
now it should as close as possible to standard
the bookmark save I've moved to Command-Option-1...
If possible - Bennet, can you please apply it against clean checkout
and check if it is ok? Thanks.
Stephan
Index: src/frontends/KeyModifier.h
===
--- src/frontends/KeyModifier.h (Revision 37757)
+++ src/frontends/KeyModifier.h (Arbeitskopie)
@@ -21,8 +21,9 @@
enum KeyModifier {
NoModifier = 0, // no modifiers held
ControlModifier = 1, // control button held
- AltModifier = 2, // alt/meta key held
- ShiftModifier= 4 // shift key held
+ AltModifier = 2, // alt key held
+ ShiftModifier= 4, // shift key held
+ MetaModifier = 8 // meta key held
};
Index: src/KeyMap.cpp
===
--- src/KeyMap.cpp (Revision 37757)
+++ src/KeyMap.cpp (Arbeitskopie)
@@ -45,8 +45,15 @@
if (mod ControlModifier)
buf += C-;
+#if defined(USE_MACOSX_PACKAGING) || defined(USE_META_KEYBINDING)
+ if (mod MetaModifier)
+ buf += M-;
if (mod AltModifier)
+ buf += A-;
+#else
+ if (mod AltModifier)
buf += M-;
+#endif
if (mod ShiftModifier)
buf += S-;
Index: src/KeySequence.cpp
===
--- src/KeySequence.cpp (Revision 37757)
+++ src/KeySequence.cpp (Arbeitskopie)
@@ -70,6 +70,12 @@
i += 2;
continue;
case 'm': case 'M':
+#if defined(USE_MACOSX_PACKAGING) || defined(USE_META_KEYBINDING)
+ mod |= MetaModifier;
+ i += 2;
+ continue;
+#endif
+ case 'a': case 'A':
mod |= AltModifier;
i += 2;
continue;
@@ -88,6 +94,12 @@
i += 3;
continue;
case 'm': case 'M':
+#if defined(USE_MACOSX_PACKAGING) || defined(USE_META_KEYBINDING)
+ nmod |= MetaModifier;
+ i += 3;
+ continue;
+#endif
+ case 'a': case 'A':
nmod |= AltModifier;
i += 3;
continue;
@@ -141,6 +153,10 @@
Re: option key not recognized in keybindings (Mac, trunk)
Am 22.02.2011 um 20:37 schrieb BH: So let me give another example of what was genuinely a custom keybinding. I had optcmdshiftB set to toggle toolbar visibility. Now that no longer works, but instead ctrlcmdshiftB does. This indeed I would not solve, the custom keybinding changes then. If one want to see it this way. In fact only the opt variant isn't accessible anymore - the ctrl variant is untouched. That's fine. Good. I'd solve it by adding a sentence to the RELEASE-NOTES (ToDo). I wonder if it would be better to put it (also) someplace more prominent. I can imagine having many users, who typically don't read release notes, hitting the e-mail list complaining that LyX-2.0 breaks their treasured keybindings. Then again, I can also imagine that not happening: I just don't know. You're probably right :) I'll see if I can make it more prominent. I want to add some file to the distribution media for LyX-2.0 RC anyway. I've made another patch with the following changes: * add a check for USE_META_KEYBINDING macro one can check the code on Linux or Windows when it's set * check for already containing modifiers in KeySymbol::print() not really needed - I can leave this out if controversial * add some key state output for debug in GuiWorkArea::keyPressEvent() not really needed either * remove duplicate debug output from GuiApplication::processKeySym() ditto * overhauled and reorganized mac.bind file now it should as close as possible to standard the bookmark save I've moved to Command-Option-1... Don't do that for my sake. If CmdCtrl[number] was working before, I think we ought to preserve that. Ok, I'll change that back. If possible - Bennet, can you please apply it against clean checkout and check if it is ok? Thanks. It looks like it's working fine. All motion keys (and shifted variants) seem to work, and I haven't noticed any other problems. Great. I'll put it in then. Stephan
Re: option key not recognized in keybindings (Mac, trunk)
Am 23.02.2011 um 16:58 schrieb BH: On Wed, Feb 23, 2011 at 2:11 AM, Stephan Witt st.w...@gmx.net wrote: If possible - Bennet, can you please apply it against clean checkout and check if it is ok? Thanks. It looks like it's working fine. All motion keys (and shifted variants) seem to work, and I haven't noticed any other problems. Great. I'll put it in then. As I'm using current svn for real, I'm noting a few problems: 1. optbackspace should delete the previous word, but it doesn't: ctrlbackspace does. That should be fixed. Same for deleting the next word (optdelete instead of ctrldelete). 2. I would suggest that inserting protected, thin, and normal spaces should similarly use opt rather than ctrl. It's not obvious that I'm right here: the distinction among these kinds of spaces is a LyX feature, not a Mac feature, so we have no standards to go by. But insofar as opt is normally used to enter special characters rather than commands, it seems appropriate to use for these special space characters. I've attached a patch that makes these changes. Thanks, I agree with that. Should I apply or do you want to/can do it? Stephan
Re: r37778 - lyx-devel/trunk/src/frontends/qt4
Am 23.02.2011 um 22:06 schrieb kuem...@lyx.org: Author: kuemmel Date: Wed Feb 23 22:06:15 2011 New Revision: 37778 URL: http://www.lyx.org/trac/changeset/37778 Log: fix wrong preprocessor Modified: lyx-devel/trunk/src/frontends/qt4/GuiKeySymbol.cpp Modified: lyx-devel/trunk/src/frontends/qt4/GuiKeySymbol.cpp == --- lyx-devel/trunk/src/frontends/qt4/GuiKeySymbol.cppWed Feb 23 20:05:17 2011(r3) +++ lyx-devel/trunk/src/frontends/qt4/GuiKeySymbol.cppWed Feb 23 22:06:15 2011(r37778) @@ -748,7 +748,7 @@ k |= ShiftModifier; if (state Qt::AltModifier) k |= AltModifier; -#ifdef USE_MACOSX_PACKAGING || defined(USE_META_KEYBINDING) +#if defined(USE_MACOSX_PACKAGING) || defined(USE_META_KEYBINDING) if (state Qt::MetaModifier) k |= MetaModifier; #else Thanks. Here it did compile - but of course it had to be corrected. Stephan
Re: major bug
Am 23.02.2011 um 22:10 schrieb Peter Kümmel: On 23.02.2011 21:52, Peter Kümmel wrote: On 23.02.2011 21:37, Pavel Sanda wrote: Pavel Sanda wrote: Jürgen Spitzmüller wrote: Not currently, but here's a testcase. * View * Close error dialog * click into ERT = crash. i got it now.p bisect leads to r37749 http://www.lyx.org/trac/changeset/37749/lyx-devel/trunk and -dgb selection triggers an assert. Attached patch helps here, but needs a review. It helps on mac too... before it crashed. Stephan
Re: CT painting problems
Am 22.02.2011 um 16:05 schrieb Pavel Sanda:
Vincent van Ravesteijn wrote:
This problem has been there really for ages. It can't suddenly be a
serious problem.
it was not until i was forced to use CT lately :)
the problem is that when you have more changes in one line,
the left side marker does not really help you to catch
that some change has been done.
thanks for links, my searches didn't work since summary
does not contain neither paint nor tracking...
Please try this patch:
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 37780)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -899,7 +899,7 @@
change_running.color(), Painter::line_solid,
solid_line_thickness_);
// Change might continue with a different author or type
- if (change.changed() !highly_editable_inset) {
+ if (change.changed() /* !highly_editable_inset */) {
change_running = change;
change_last_x = int(x_);
} else
Someone was thinking it should be done this way...
The following comment is some lines above.
// If we reach the end of a change or if the author changes,
paint it.
// We also don't paint across things like tables
Stephan
PS. Should I put the rowpainter patch in? (to force the painting of every
single character with Qt4.7.X)
Re: CT painting problems
Am 24.02.2011 um 13:36 schrieb Pavel Sanda:
Stephan Witt wrote:
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 37780)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -899,7 +899,7 @@
change_running.color(), Painter::line_solid,
solid_line_thickness_);
// Change might continue with a different author or type
-if (change.changed() !highly_editable_inset) {
+if (change.changed() /* !highly_editable_inset */) {
change_running = change;
change_last_x = int(x_);
looks better for normal insets. still something is missing - it looks as if
there more independent painting modes.
one is triggered when i just press normal character - then your fix does not
work and painting line over inset disappear.
other one is when i hoover with mouse with inset. then regardless your fix
works line was there (iirc).
yet another one is when i press enter - then line is again there.
Yes, I see. I'll have a look later.
PS. Should I put the rowpainter patch in? (to force the painting of every
single character with Qt4.7.X)
ok, lets try it now.
I'll do it then.
if there are still opened bugs about those kerning/ligature problems, please
instead
of fixing, retarget them to 2.1 and add there some summary which you already
made in previous threads.
I don't know of other problems - the ligature and the kerning problems are both
fixed by these hacks.
The plan is to fix them properly. But since it has the potential to introduce
bad bugs I postponed it.
So the tickets should stay open and retarget is the correct action. The current
situation with these hacks
is the same as it was for ages. I claim that former Qt libraries did the
drawing effectively character by character.
Now this has changed and LyX is not ready to handle this. Therefor the hacks
are needed.
After 2.0 is out I want to attack this.
optimal solution is to getrid ofthis RC_ variable and kill 'ff' ligature hack
one day again...
Yes, this RC variable I introduced to make Abdel happy. There is no interface
for users.
The only purpose is to force the (currently) broken behavior for developers.
Stephan
Re: How to use pkg-config together with configure?
Am 24.02.2011 um 21:39 schrieb José Matos: On Thursday 24 February 2011 18:56:00 José Matos wrote: Hi, now that the gradings are gone :-) Hi José, I would like to solve the absence of the spellchecker in Fedora lyx packages. I have finnaly found the reason. configure is checking to see if a program compiles with -lhunspell and the this does not work since the linker does not find any such library. The right approach in this case would be to ask pkg-config: $ pkg-config hunspell --libs -lhunspell-1.2 note the suffix -1.2 above. What should I do to add this to configure in sane way? Regards, OK, based on the code for mythes detection I came with the following patch. What do you think? If it works for you... on mac it doesn't harm. Stephan
Re: CT painting problems
Am 24.02.2011 um 14:10 schrieb Stephan Witt:
Am 24.02.2011 um 13:36 schrieb Pavel Sanda:
Stephan Witt wrote:
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 37780)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -899,7 +899,7 @@
change_running.color(), Painter::line_solid,
solid_line_thickness_);
// Change might continue with a different author or type
- if (change.changed() !highly_editable_inset) {
+ if (change.changed() /* !highly_editable_inset */) {
change_running = change;
change_last_x = int(x_);
looks better for normal insets. still something is missing - it looks as if
there more independent painting modes.
one is triggered when i just press normal character - then your fix does not
work and painting line over inset disappear.
other one is when i hoover with mouse with inset. then regardless your fix
works line was there (iirc).
yet another one is when i press enter - then line is again there.
Yes, I see. I'll have a look later.
Until now I can see two problems:
1. as you noted the insets is painted with different code paths.
One cares for CT and the other not, obviously.
2. the contents of a deleted inset does not know of its state.
Does anyone know how to derive the pit and pos of the enclosing
paragraph of an inset (without cursor)?
Currently I'm really short of time and cannot walk many hours
through the code...
Stephan
Re: Cursor in LyX 2 beta4
Am 04.03.2011 um 17:04 schrieb Pavel Sanda:
Abdelrazak Younes wrote:
#ifdef Q_WS_WIN
int const CursorWidth = 2;
#else
int const CursorWidth = 1;
#endif
considering how trivial is this change and how many times it was asked,
i would accept patch for RC variable even for 2.0.
Or the zoom related approach... see patch.
Stephan
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (Revision 37853)
+++ src/frontends/qt4/GuiWorkArea.cpp (Arbeitskopie)
@@ -73,11 +73,6 @@
#include cmath
-#ifdef Q_WS_WIN
-int const CursorWidth = 2;
-#else
-int const CursorWidth = 1;
-#endif
int const TabIndicatorWidth = 3;
#undef KeyPress
@@ -128,7 +123,9 @@
class CursorWidget {
public:
- CursorWidget() {}
+ CursorWidget() {
+ recomputeWidth();
+ }
void draw(QPainter painter)
{
@@ -141,7 +138,7 @@
int bot = rect_.bottom();
// draw vertical line
- painter.fillRect(x_, y, CursorWidth, rect_.height(), color_);
+ painter.fillRect(x_, y, cursor_width_, rect_.height(), color_);
// draw RTL/LTR indication
painter.setPen(color_);
@@ -149,7 +146,7 @@
if (rtl_)
painter.drawLine(x_, bot, x_ - l, bot);
else
- painter.drawLine(x_, bot, x_ + CursorWidth + r,
bot);
+ painter.drawLine(x_, bot, x_ + cursor_width_ +
r, bot);
}
// draw completion triangle
@@ -160,8 +157,8 @@
painter.drawLine(x_ - 1, m - d, x_ - 1 - d, m);
painter.drawLine(x_ - 1, m + d, x_ - 1 - d, m);
} else {
- painter.drawLine(x_ + CursorWidth, m - d, x_ +
CursorWidth + d, m);
- painter.drawLine(x_ + CursorWidth, m + d, x_ +
CursorWidth + d, m);
+ painter.drawLine(x_ + cursor_width_, m - d, x_
+ cursor_width_ + d, m);
+ painter.drawLine(x_ + cursor_width_, m + d, x_
+ cursor_width_ + d, m);
}
}
}
@@ -196,11 +193,15 @@
}
// compute overall rectangle
- rect_ = QRect(x - l, y, CursorWidth + r + l, h);
+ rect_ = QRect(x - l, y, cursor_width_ + r + l, h);
}
void show(bool set_show = true) { show_ = set_show; }
void hide() { show_ = false; }
+ int cursorWidth() const { return cursor_width_; }
+ void recomputeWidth() {
+ cursor_width_ = 1 + int((lyxrc.zoom + 50) / 200.0);
+ }
QRect const rect() { return rect_; }
@@ -219,6 +220,8 @@
QRect rect_;
/// x position (were the vertical line is drawn)
int x_;
+
+ int cursor_width_;
};
@@ -600,6 +603,7 @@
!completer_-popupVisible()
!completer_-inlineVisible();
cursor_visible_ = true;
+ cursor_-recomputeWidth();
showCursor(p.x_, p.y_, h, l_shape, isrtl, completable);
}
Re: Cursor in LyX 2 beta4
Am 06.03.2011 um 01:35 schrieb Pavel Sanda: Stephan Witt wrote: Am 04.03.2011 um 17:04 schrieb Pavel Sanda: Abdelrazak Younes wrote: #ifdef Q_WS_WIN int const CursorWidth = 2; #else int const CursorWidth = 1; #endif considering how trivial is this change and how many times it was asked, i would accept patch for RC variable even for 2.0. Or the zoom related approach... see patch. it doesn't meet the requests i have seen up to now. the people asking for this feature wants generally much wider cursor than you propose - closer to block cursor. I cannot believe that a 4 pixel wide cursor makes sense when using 120% zoom. The space between two characters isn't big enough. A possibility - nevertheless I tried to avoid another RC variable - would be to introduce the RC variable with the option to choose automatic cursor width or a arbitrary fixed width. Should I prepare that? Stephan
Re: Cursor in LyX 2 beta4
Am 07.03.2011 um 01:02 schrieb Pavel Sanda: Stephan Witt wrote: it doesn't meet the requests i have seen up to now. the people asking for this feature wants generally much wider cursor than you propose - closer to block cursor. I cannot believe that a 4 pixel wide cursor makes sense when i can't understand 4 pixels at any normal zoom, but funny enough just next mail in users list ;) I know. ;) using 120% zoom. does this value have any meaning if you dont know which particular font is used? Of course not. But I don't know of any editor adapting the cursor width to the font size. To adapt it to screen display zoom makes sense I believe. A possibility - nevertheless I tried to avoid another RC variable - would be to introduce the RC variable with the option to choose automatic cursor width or a arbitrary fixed width. Should I prepare that? so instead of one you propose two now? :) No. Simply use automatic scaling when the width is zero. anyway, my acceptance for 2.0 was due to minimal possibility of regressions introduced when we have RC variable for width. for any magic computations its too late. even stupid spellcheck underline had many iterations and rc2 is not good experimental sand. The computation I propose is the same as for the line thickness of the foreign language marker. if its controversial issue, we can postpone it to 2.1 discussions. Surely. The more nasty issue than the fixed versus automatic cursor width is the prefs interface. The edit control pane it belongs to has heavily hand coded interface layout. No fun. Stephan
Re: Towards rc1 (status update #4, trunk frozen)
Am 07.03.2011 um 01:06 schrieb Pavel Sanda: Pavel Sanda wrote: Pavel Sanda wrote: only doc or translations can go in. trunk is completely frozen now. trunk is opened for bug fixing again. tarballs are on usual place, i'll announce rc1 at monday night. give it a try. It builds cleanly. I placed two .dmg files at aussie: * LyX-2.0.0rc1+qt4.dmg for Mac OS X Leopard (10.5) and Snow Leopard (10.6) * LyX-2.0.0rc1+qt4-tiger.dmg for Mac OS X Tiger (10.4) Stephan
Re: Towards rc1 (status update #4, trunk frozen)
Am 07.03.2011 um 11:13 schrieb Anders Ekberg: One more nasty bug on Mac (latest SnowLeopard): The alt key modifier seems to be broken. As an example, alt+m m (which should give you an inline formula) give ¹m, alt+p gives you ¼ etc. Sorry for the inconvenience... but this is (partly) intended. The Alt key is not bound to Ctrl anymore. You have to use Ctrl-m m instead. See http://www.lyx.org/trac/ticket/7292 I wrote partly because I don't understand why you get ¹m for Alt+m m. Here it makes µm... is it only on german keyboards this way? Stephan PS. Pavel, obviously I forgot to make this change more clear in the .dmg. It would be no real change to the code base if I add a README to the distribution media. Would it better to add another .dmg with this addition for RC1? On 2011-03-07 09.10, Stephan Witt st.w...@gmx.net wrote: Am 07.03.2011 um 01:06 schrieb Pavel Sanda: Pavel Sanda wrote: Pavel Sanda wrote: only doc or translations can go in. trunk is completely frozen now. trunk is opened for bug fixing again. tarballs are on usual place, i'll announce rc1 at monday night. give it a try. It builds cleanly. I placed two .dmg files at aussie: * LyX-2.0.0rc1+qt4.dmg for Mac OS X Leopard (10.5) and Snow Leopard (10.6) * LyX-2.0.0rc1+qt4-tiger.dmg for Mac OS X Tiger (10.4) Stephan
Re: Towards rc1 (status update #4, trunk frozen)
Am 07.03.2011 um 11:33 schrieb Anders Ekberg: On 2011-03-07 11.26, Stephan Witt st.w...@gmx.net wrote: Am 07.03.2011 um 11:13 schrieb Anders Ekberg: One more nasty bug on Mac (latest SnowLeopard): The alt key modifier seems to be broken. As an example, alt+m m (which should give you an inline formula) give ¹m, alt+p gives you ¼ etc. Sorry for the inconvenience... but this is (partly) intended. The Alt key is not bound to Ctrl anymore. You have to use Ctrl-m m instead. See http://www.lyx.org/trac/ticket/7292 I wrote partly because I don't understand why you get ¹m for Alt+m m. Here it makes μm... is it only on german keyboards this way? snip... OK, then I see (and it works fine and I agree it is better). I suggest to note this VERY clearly in the release notes since I guess more than me have the old shortcut in the spine. Yes, definitely! Pavel offered to add a note to the announcement... The RELEASE-NOTES contains: - On Mac OSX the modifier keys Control and Option are now treated separately. The distributed key binding for Mac OSX no longer uses the Option key for shortcuts with letters or numbers. The custom key bindings for Option/Control are mapped to the Control modifier only. This I would say a little bit shorter in the ANNOUNCE: On Mac OSX the modifier keys Control and Option are now treated separately. The distributed key binding for Mac OSX now uses the Control key only for most of the commands. Please, make some better english sentences from it. The alt+m gives an upside-down single apostrophe (as it should), but I think the e-mail encoding messed it up... Do you see the preamble bug (see previous post) or is it just my computer? Yes, but I'm not so fast to act on... I'll check soon. Stephan
Re: Towards rc1 (status update #4, trunk frozen)
Am 07.03.2011 um 11:33 schrieb Anders Ekberg: On 2011-03-07 11.26, Stephan Witt st.w...@gmx.net wrote: Am 07.03.2011 um 11:13 schrieb Anders Ekberg: One more nasty bug on Mac (latest SnowLeopard): The alt key modifier seems to be broken. As an example, alt+m m (which should give you an inline formula) give ¹m, alt+p gives you ¼ etc. Sorry for the inconvenience... but this is (partly) intended. The Alt key is not bound to Ctrl anymore. You have to use Ctrl-m m instead. See http://www.lyx.org/trac/ticket/7292 I wrote partly because I don't understand why you get ¹m for Alt+m m. Here it makes μm... is it only on german keyboards this way? snip... OK, then I see (and it works fine and I agree it is better). I suggest to note this VERY clearly in the release notes since I guess more than me have the old shortcut in the spine. The alt+m gives an upside-down single apostrophe (as it should), but I think the e-mail encoding messed it up... Do you see the preamble bug (see previous post) or is it just my computer? Sorry, I cannot reproduce it. (I tried it with the LyX.app started from the .dmg volume). Perhaps it depends on the document you start with. Is it somewhat special? Stephan
Re: Towards rc1 (status update #4, trunk frozen)
Am 07.03.2011 um 13:32 schrieb Anders Ekberg: On 2011-03-07 12.44, Stephan Witt st.w...@gmx.net wrote: Sorry, I cannot reproduce it. (I tried it with the LyX.app started from the .dmg volume). Perhaps it depends on the document you start with. Is it somewhat special? Stephan Seems to be triggered with every document for me (at least that the pasted text disappears in the Preamble). I attach an example file. Seems to be triggered by having document setting windows open for both documents at the same time. If you copy, then close Document settings, open document settings for the other document and paste then it works as expected. It also works as expected if you first open the Document settings window in the *existing* document and then create a new file, open Document settings for this new file and paste. Could it be a counter that is wrong somewhere? Hmm... do you open your documents in tabs? Stephan
Re: Towards rc1 (status update #4, trunk frozen)
Am 07.03.2011 um 14:32 schrieb Anders Ekberg: On 2011-03-07 14.29, Stephan Witt st.w...@gmx.net wrote: Am 07.03.2011 um 13:32 schrieb Anders Ekberg: On 2011-03-07 12.44, Stephan Witt st.w...@gmx.net wrote: Sorry, I cannot reproduce it. (I tried it with the LyX.app started from the .dmg volume). Perhaps it depends on the document you start with. Is it somewhat special? Stephan Seems to be triggered with every document for me (at least that the pasted text disappears in the Preamble). I attach an example file. Seems to be triggered by having document setting windows open for both documents at the same time. If you copy, then close Document settings, open document settings for the other document and paste then it works as expected. It also works as expected if you first open the Document settings window in the *existing* document and then create a new file, open Document settings for this new file and paste. Could it be a counter that is wrong somewhere? Hmm... do you open your documents in tabs? Stephan No. Now I can reproduce it. I did open the document settings of the existing first... I'll debug it today evening. Stephan
Re: Towards rc1 (status update #4, trunk frozen)
Am 07.03.2011 um 15:36 schrieb Stephan Witt: Am 07.03.2011 um 14:32 schrieb Anders Ekberg: On 2011-03-07 14.29, Stephan Witt st.w...@gmx.net wrote: Am 07.03.2011 um 13:32 schrieb Anders Ekberg: On 2011-03-07 12.44, Stephan Witt st.w...@gmx.net wrote: Sorry, I cannot reproduce it. (I tried it with the LyX.app started from the .dmg volume). Perhaps it depends on the document you start with. Is it somewhat special? Stephan Seems to be triggered with every document for me (at least that the pasted text disappears in the Preamble). I attach an example file. Seems to be triggered by having document setting windows open for both documents at the same time. If you copy, then close Document settings, open document settings for the other document and paste then it works as expected. It also works as expected if you first open the Document settings window in the *existing* document and then create a new file, open Document settings for this new file and paste. Could it be a counter that is wrong somewhere? Hmm... do you open your documents in tabs? Stephan No. Now I can reproduce it. I did open the document settings of the existing first... I'll debug it today evening. I didn't find it until now. But I tried to verify it on Linux - it is there too. No platform dependency! You have to disable the Open documents in tabs check box in preferences and follow the recipe Anders gave exactly. Interestingly the existing document is marked as changed after saving the preamble of the new document! Stephan
Re: Setting use_system_colors to true?
Am 08.03.2011 um 11:51 schrieb Jean-Marc Lasgouttes: Hello, Since we might get more system-like icons, could we set system colors to 'true' by default? Remember that the background color is not affected, for you linen lovers :) I'd happily distribute it like that for mac os. This patch I did not commit because I didn't know if it is controversial. Stephan
Re: Setting use_system_colors to true?
Am 08.03.2011 um 12:08 schrieb Jean-Marc Lasgouttes: Le 08/03/2011 12:05, Stephan Witt a écrit : Am 08.03.2011 um 11:51 schrieb Jean-Marc Lasgouttes: Hello, Since we might get more system-like icons, could we set system colors to 'true' by default? Remember that the background color is not affected, for you linen lovers :) I'd happily distribute it like that for mac os. This patch I did not commit because I didn't know if it is controversial. I'd say that next rc would be a good time to know whether it is controversial. I did it :) Stephan
Re: Bug in 2.0RC1? language changing change the language of already written text.
Am 08.03.2011 um 16:51 schrieb Ronen Abravanel: Hello, I started using LyX 2.0RC1, and by now, there is only one thing that bothers me: While I'm typing a document in one language, and then, when the cursor is right after the last word (with no space), I'm typing language hebrew in the minibuffer (or: using predefined shortcuts that commits the same). The language do changes, but the last word is also marked and it's language switched. For example, If I write one two^, and when the cursor is where the ^ is, changes the language, it will convert into one [owt], when the two is reversed, as it thinks it's in Hebrew, and the [ - ] part is marked. This is new behavior - it was not there in some previous versions of 2.0, but it's there in beta 4. Yes, this is new - but it's meant as a feature. If you change the language without any selection LyX changes the language of the word under the cursor. Do you want to change the language for the delimiter following the word? Sorry, I don't know anything about hebrew. Stephan
Re: compile 2.0rc1 on mac
Am 08.03.2011 um 18:29 schrieb William Bray: I have been testing the beta versions of Lyx 2.0 for some time on my Mac running OS 10.6.6. With the latest svn version I get the following error in the build stage regarding Hunspell: CXXHunspellChecker.o HunspellChecker.cpp:31:33: error: hunspell/hunspell.hxx: No such file or directory ... make[4]: *** [HunspellChecker.o] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ** I have not seen this listed as a bug? You are the first one without hunspell header but with hunspell library... :) My config line is ./configure --with-version-suffix=-2.0 --with-libiconv-prefix=/usr --with-x=no --disable-stdlib-debug --prefix=/Applications/Lyx-2.app --with-qt4-dir=/usr/local/qt4 --enable-build-type=release As a work around, if I add the option --with-hunspell=no to the config line, then the prerelease builds fine. The attached patch fixes this. JMarc, is this the right thing? Stephan Index: config/spell.m4 === --- config/spell.m4 (Revision 37877) +++ config/spell.m4 (Arbeitskopie) @@ -55,9 +55,11 @@ [lyx_use_hunspell=true; break;], [lyx_use_hunspell=false]) - AC_CHECK_LIB(hunspell, main, LIBS=-lhunspell $LIBS, lyx_use_hunspell=false) - if test x$lyx_use_hunspell = xfalse ; then - AC_CHECK_LIB(hunspell-1.2, main, [LIBS=-lhunspell-1.2 $LIBS lyx_use_hunspell=true], lyx_use_hunspell=false) + if test x$lyx_use_hunspell = xtrue ; then + AC_CHECK_LIB(hunspell, main, LIBS=-lhunspell $LIBS, lyx_use_hunspell=false) + if test x$lyx_use_hunspell = xfalse ; then +AC_CHECK_LIB(hunspell-1.2, main, [LIBS=-lhunspell-1.2 $LIBS lyx_use_hunspell=true], lyx_use_hunspell=false) + fi fi AC_MSG_CHECKING([whether to use hunspell]) if $lyx_use_hunspell ; then
Re: Bug in 2.0RC1? language changing change the language of already written text.
Am 08.03.2011 um 17:36 schrieb Ronen Abravanel: My most common situation in which this is a problem is the following Hebrew text (English translation) more hebrew.. For most language, you wouldn't mind if the ( ) will be in English or in other language, but Hebrew is written from right to left, which means the Parentheses are written in reverse. Meaning, if the closing parentheses will be in English, it will apear as: Hebrew text ((English Hebrew (Or something like that) there fore, the following parentheses or comma must be at the same language as the paragraph language, and not as the last-word language. I believe you. The attached patch changes this to restore the old behavior when cursor is at the word end. Ok to apply? Stephan /Users/Shared/LyX ~/cvs/lyx /Users/Shared/LyX/lyx-build/LyX-2.0.0svn.build Index: src/Text3.cpp === --- src/Text3.cpp (Revision 37877) +++ src/Text3.cpp (Arbeitskopie) @@ -1890,7 +1890,8 @@ Language const * lang = languages.getLanguage(to_utf8(cmd.argument())); if (!lang) break; - selectWordWhenUnderCursor(cur, WHOLE_WORD); + if (!cur.paragraph().isWordSeparator(cur.pos())) + selectWordWhenUnderCursor(cur, WHOLE_WORD); Font font(ignore_font, lang); toggleAndShow(cur, this, font); break;
Re: Bug in 2.0RC1? language changing change the language of already written text.
Am 08.03.2011 um 23:09 schrieb Jean-Marc Lasgouttes: Le 08/03/2011 21:54, Stephan Witt a écrit : The attached patch changes this to restore the old behavior when cursor is at the word end. Ok to apply? You can simply use WHOLE_WORD_STRICT instead of WHOLE_WORD to get this effect. Ah, ok - I didn't thought of that. But it's not exactly the same. When in front of a word the selection is not done too. That raises the question if it's better or not to use WHOLE_WORD_STRICT... When entering hebrew text is the word end at from() or at the to() pos? Stephan PS. Ronen, if you want to try it - the patch is attached. /Users/Shared/LyX ~/cvs/lyx /Users/Shared/LyX/lyx-build/LyX-2.0.0svn.build Index: src/Text3.cpp === --- src/Text3.cpp (Revision 37885) +++ src/Text3.cpp (Arbeitskopie) @@ -1890,7 +1890,7 @@ Language const * lang = languages.getLanguage(to_utf8(cmd.argument())); if (!lang) break; - selectWordWhenUnderCursor(cur, WHOLE_WORD); + selectWordWhenUnderCursor(cur, WHOLE_WORD_STRICT); Font font(ignore_font, lang); toggleAndShow(cur, this, font); break;
Re: compile 2.0rc1 on mac
Am 08.03.2011 um 23:06 schrieb Jean-Marc Lasgouttes: Le 08/03/2011 21:30, Stephan Witt a écrit : The attached patch fixes this. JMarc, is this the right thing? I think it was correct, but here is nevertheless a more idiomatic version (that subsumes José's patch too). The problem was: the result of header presence detection - aka missing header is respected by the first test for the library but not by the second test. Please and commit if it works also for you. I've tested it and it works on my system. I could reproduce the problem - somehow hunspell-1.2 was found by the linker - and it is fixed now. José, if you have time, please test it too! Yes, please. I'm almost sure, but to double check is better. Stephan
Re: [RFC] what is a word (boundary)?
Am 08.03.2011 um 18:56 schrieb Jürgen Spitzmüller: IIRC somebody already brought up this issue some time back. JMarcs mail from 2011-02-02 with subject Spell checking and breaking words. Yes, we should do something about this. Hunspell can check both complex composites constructed with (hard) hyphens (as in fifty-year-old chap) and, more interestingly, elliptical or fractal composites who use a hard hyphen in order to refer to a shared morpheme in a paired word form (as in two- and threefold or German Betriebsklima und -sicherheit). At least in German, both types of these beasts are pretty frequent, so we should pass hard hyphens to the speller if hunspell is used, instead of just trimming them off the word (as we do now). The results, at least here, are way better. Currently, for instance, Hunspell would mark -sicherheit as misspelled (since we pass sicherheit) and suggest Sicherheit and, nota bene, -sicherheit. The attached patch is an attempt in this direction. It passes hard hyphens (and nonbreakdashes) to the speller if this speller is hunspell. However, since the isWordSeparator function is not only used by the spellchecker, this change affects other things as well. For instance, currently, if you set the cursor left of the word socio-linguistics and hit Insert Index entry, only socio is copied inside the index inset. With my patch, socio-linguistics as a whole is copied inside. This seems more correct to me, at least wrt English and German, however, it is of course not suitable that the index entry generation differs wrt to the speller which is used. So my question is, should we * limit the change to the hunspell checker only, which means that we set up an extra isWordSeparator function (or an option) for the spellchecker? * treat hard hyphens not as word separators in general, i.e. ditch the canHandleSplitMorphemes() part of the patch? * make it a property of the language? Add a list of characters to include in words? We have to add this anyway to drop the escape chars field from spell checker settings. Give the spell checker backend some control over this list - aspell e. g. can remove the dash from it, hunspell would keep it. To me, the second option makes more sense, but of course this the more intrusive change. Stephan
Re: Bug in 2.0RC1? language changing change the language of already written text.
Am 09.03.2011 um 10:29 schrieb Jean-Marc Lasgouttes: Le 09/03/2011 07:24, Stephan Witt a écrit : Ah, ok - I didn't thought of that. But it's not exactly the same. When in front of a word the selection is not done too. That raises the question if it's better or not to use WHOLE_WORD_STRICT... When entering hebrew text is the word end at from() or at the to() pos? Note that this is what is used for fonts in Text::toggleFree. I would think the two actions should behave similarly. I did it that way. I had a positive feedback from Ronen. (Thanks for that.) Stephan
Re: r37887 - lyx-devel/trunk/config
Am 09.03.2011 um 18:12 schrieb Jean-Marc Lasgouttes: Le 09/03/2011 16:40, sw...@lyx.org a écrit : Author: switt Date: Wed Mar 9 16:40:03 2011 New Revision: 37887 URL: http://www.lyx.org/trac/changeset/37887 Log: do not check for hunspell libraries if header is not present Is it the patch you intended to commit? Yes, this one I've posted and tested. Why do you ask? Stephan
Re: Regression in r37463 by switt: Crash when deleting ERT from inside
Am 10.03.2011 um 04:42 schrieb John McCabe-Dansted: (Was Regression in r37463 by switt: Crash when deleting footnote) I found another bug that appears to be caused by r37463 KEYCODES: \Cla\[Delete] To Reproduce 1) Press Ctrl-L to enter ERT mode 2) Press A to enter a character 3) Press Delete to delete the ERT container. I fixed it with r37899, thank you for the report. Stephan
Re: Cursor in LyX 2 beta4
Am 07.03.2011 um 01:02 schrieb Pavel Sanda:
Stephan Witt wrote:
it doesn't meet the requests i have seen up to now. the people asking for
this
feature wants generally much wider cursor than you propose - closer to
block cursor.
I cannot believe that a 4 pixel wide cursor makes sense when
i can't understand 4 pixels at any normal zoom, but funny enough just next
mail in users list ;)
using 120% zoom.
does this value have any meaning if you dont know which particular font is
used?
A possibility - nevertheless I tried to avoid another RC variable -
would be to introduce the RC variable with the option to choose automatic
cursor width
or a arbitrary fixed width. Should I prepare that?
so instead of one you propose two now? :)
anyway, my acceptance for 2.0 was due to minimal possibility of regressions
introduced
when we have RC variable for width. for any magic computations its too late.
even stupid
spellcheck underline had many iterations and rc2 is not good experimental
sand.
So I've made a patch to add RC + prefs interface for it.
When cursor width is set to zero automatic zoom happens.
Stephan
Index: src/LyXRC.h
===
--- src/LyXRC.h (Revision 37889)
+++ src/LyXRC.h (Arbeitskopie)
@@ -65,6 +65,7 @@
RC_CONVERTER_CACHE_MAXAGE,
RC_COPIER,
RC_CURSOR_FOLLOWS_SCROLLBAR,
+ RC_CURSOR_WIDTH,
RC_DATE_INSERT_FORMAT,
RC_DEFAULT_DECIMAL_POINT,
RC_DEFAULT_LANGUAGE,
@@ -530,6 +531,8 @@
ScrollWheelZoom scroll_wheel_zoom;
///
bool force_paint_single_char;
+ ///
+ int cursor_width;
};
Index: src/LyXRC.cpp
===
--- src/LyXRC.cpp (Revision 37889)
+++ src/LyXRC.cpp (Arbeitskopie)
@@ -85,6 +85,7 @@
{ \\converter_cache_maxage, LyXRC::RC_CONVERTER_CACHE_MAXAGE },
{ \\copier, LyXRC::RC_COPIER },
{ \\cursor_follows_scrollbar, LyXRC::RC_CURSOR_FOLLOWS_SCROLLBAR },
+ { \\cursor_width, LyXRC::RC_CURSOR_WIDTH },
{ \\date_insert_format, LyXRC::RC_DATE_INSERT_FORMAT },
{ \\def_file, LyXRC::RC_DEFFILE },
{ \\default_decimal_point, LyXRC::RC_DEFAULT_DECIMAL_POINT },
@@ -360,6 +361,7 @@
completion_inline_dots = -1;
completion_inline_delay = 0.2;
default_decimal_point = .;
+ cursor_width = 1;
}
@@ -903,6 +905,10 @@
lexrc cursor_follows_scrollbar;
break;
+ case RC_CURSOR_WIDTH:
+ lexrc cursor_width;
+ break;
+
case RC_SCROLL_BELOW_DOCUMENT:
lexrc scroll_below_document;
break;
@@ -1754,6 +1760,15 @@
}
if (tag != RC_LAST)
break;
+ case RC_CURSOR_WIDTH:
+ if (ignore_system_lyxrc ||
+ cursor_width
+ != system_lyxrc.cursor_width) {
+ os \\cursor_width
+cursor_width '\n';
+ }
+ if (tag != RC_LAST)
+ break;
case RC_SCROLL_BELOW_DOCUMENT:
if (ignore_system_lyxrc ||
scroll_below_document
@@ -3005,6 +3020,7 @@
case LyXRC::RC_EXPORT_OVERWRITE:
case LyXRC::RC_DEFAULT_DECIMAL_POINT:
case LyXRC::RC_SCROLL_WHEEL_ZOOM:
+ case LyXRC::RC_CURSOR_WIDTH:
case LyXRC::RC_LAST:
break;
}
@@ -3078,6 +3094,10 @@
str = _(LyX normally doesn't update the cursor position if you
move the scrollbar. Set to true if you'd prefer to always have the cursor on
screen.);
break;
+ case RC_CURSOR_WIDTH:
+ str = _(Configure the width of the text cursor. Automatic zoom
controled cursor width used when set to 0.);
+ break;
+
case RC_SCROLL_BELOW_DOCUMENT:
str = _(LyX normally doesn't allow the user to scroll further
than the bottom of the document. Set to true if you prefer to scroll the bottom
of the document to the top of the screen);
break;
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (Revision 37889)
+++ src/frontends/qt4/GuiWorkArea.cpp (Arbeitskopie)
@@ -73,11 +73,6 @@
#include cmath
-#ifdef Q_WS_WIN
-int const CursorWidth = 2;
-#else
-int const CursorWidth = 1;
-#endif
int const TabIndicatorWidth = 3;
#undef KeyPress
@@ -128,7 +123,9 @@
class CursorWidget {
public:
- CursorWidget() {}
+ CursorWidget() {
+ recomputeWidth();
+ }
void draw(QPainter painter)
{
@@ -141,7 +138,7
Re: r37901 - in lyx-devel/trunk/src: . frontends/qt4 frontends/qt4/ui
Am 11.03.2011 um 07:11 schrieb sw...@lyx.org:
Author: switt
Date: Fri Mar 11 07:11:55 2011
New Revision: 37901
URL: http://www.lyx.org/trac/changeset/37901
Log:
now the user has control over the width of the text cursor
Modified:
lyx-devel/trunk/src/LyXRC.cpp
lyx-devel/trunk/src/LyXRC.h
lyx-devel/trunk/src/frontends/qt4/GuiPrefs.cpp
lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.cpp
lyx-devel/trunk/src/frontends/qt4/ui/PrefEditUi.ui
Modified: lyx-devel/trunk/src/LyXRC.cpp
==
--- lyx-devel/trunk/src/LyXRC.cpp Thu Mar 10 23:11:34 2011(r37900)
+++ lyx-devel/trunk/src/LyXRC.cpp Fri Mar 11 07:11:55 2011(r37901)
@@ -85,6 +85,7 @@
{ \\converter_cache_maxage, LyXRC::RC_CONVERTER_CACHE_MAXAGE },
{ \\copier, LyXRC::RC_COPIER },
{ \\cursor_follows_scrollbar, LyXRC::RC_CURSOR_FOLLOWS_SCROLLBAR },
+ { \\cursor_width, LyXRC::RC_CURSOR_WIDTH },
{ \\date_insert_format, LyXRC::RC_DATE_INSERT_FORMAT },
{ \\def_file, LyXRC::RC_DEFFILE },
{ \\default_decimal_point, LyXRC::RC_DEFAULT_DECIMAL_POINT },
@@ -360,6 +361,7 @@
completion_inline_dots = -1;
completion_inline_delay = 0.2;
default_decimal_point = .;
+ cursor_width = 1;
}
Note: on Windows this was 2 originally.
If this should continue to be the default I propose to add
\cursor_width 2 to lyxrc.dist.in for windows.
Stephan
Re: Which for MacOSX Snow Leo? Re: ANNOUNCE: LyX version 2.0.0 (release candidate 1)
Am 11.03.2011 um 14:11 schrieb Joachim Osnabryg: Am 07.03.11 23:02, schrieb Pavel Sanda: Tarballs can be found atftp://ftp.lyx.org/pub/lyx/devel/lyx-2.0/ . Binaries should follow soon. I see 2 MacOSX binaries on the server, one: LyX-2.0.0rc1+qt4-tiger.dmg second: LyX-2.0.0rc1+qt4.dmg To be sure I ask: Is the second one that which will go well on OSX 10.6.5 Snow Leopard intel, my system? Yes. The tiger version should run on your system too, but the functionality is somewhat limited. Stephan
Re: ANNOUNCE: LyX version 2.0.0 (release candidate 1)
Am 13.03.2011 um 22:39 schrieb Vincent van Ravesteijn: Op 13-3-2011 22:35, Tommaso Cucinotta schreef: Il 13/03/2011 22:25, Vincent van Ravesteijn ha scritto: Can you check whether this is fixed by r37899 ? If not, can you try to revert to r37462. Maybe it's also a regression introduced in r37463. the funny thing is that, if I write a test-case with that autotests testing machinery, then LyX passes it with no problems without crashing, and it does exactly what expected. For example: KK: a b\S\[Left]\S\[Left]x correctly produces ax on the screen without crashing :-(. But, if I do that manually, the crash is deterministic. So, I came to the conclusion that the real difference is that the testing machinery uses a clean userdir. Infact, starting lyx with -userdir /tmp/non-existent, the crash does not occur. Any clue of what I might have wrong in my ~/.lyx that causes the crash ? If you want, I can send the whole folder. T. It probably has something to do with the spellchecking as you write feature. If you remove the userdir, it will be turned off as a default, and the bug doesn't show. Obviously the afford to suppress the spellchecking as you write for the current word has no stable result. I'll propose to disable it until I have better solution - I'll send a patch tomorrow. Stephan
Re: ANNOUNCE: LyX version 2.0.0 (release candidate 1)
Am 14.03.2011 um 04:32 schrieb John McCabe-Dansted: On Mon, Mar 14, 2011 at 5:39 AM, Vincent van Ravesteijn v...@lyx.org wrote: Op 13-3-2011 22:35, Tommaso Cucinotta schreef: Il 13/03/2011 22:25, Vincent van Ravesteijn ha scritto: the funny thing is that, if I write a test-case with that autotests testing machinery, then LyX passes it with no problems without crashing, and it does exactly what expected. For example: KK: a b\S\[Left]\S\[Left]x It probably has something to do with the spellchecking as you write feature. If you remove the userdir, it will be turned off as a default, and the bug doesn't show. This appears to be the issue. FYI, the following automatically reproduces the bug: KK: \Atp\D2\t\D2i\D2\[Down]\D2s\D2\Ap\D2\As\D2 KK: \D5 a\D5 a\D5 \D5b\D5\S\[Left]\D5\S\[Left]\D5x\D5 The first line turns on the automatic spellchecking. The \D2s introduces a delay of 200 ms. According the cache-bisect.sh, the bug was indeed introduced in r37463 Indeed, the mentioned change was more fragile then I expected. Nevertheless I cannot reproduce it with SVN 37923 here. I translate the recipe (when continuous spellchecker is already enabled) to * input 3 words: a a b * select space+b by 2xShift-Left * type x There is a related bug report in trac: http://www.lyx.org/trac/ticket/7350 I attached a patch there which looks sensible - this one is not needed here. Is it possible to tell the SVN version of the source which is crashing? Stephan
Re: ANNOUNCE: LyX version 2.0.0 (release candidate 1)
Am 13.03.2011 um 22:25 schrieb Vincent van Ravesteijn: Op 13-3-2011 22:20, Tommaso Cucinotta schreef: Il 13/03/2011 21:46, Vincent van Ravesteijn ha scritto: A backtrace would be more useful :S.. I know, sorry, but I reduced the problem to a simple test-case: 1. C-n (new document) 2. a b 3. [Shift+Left][Shift-left] (select the b part, including the leading space) 4. [Space] #2 0x0063027c in __replacement_assert (this=0x1a053c8, __pos=2) at /usr/include/c++/4.4/x86_64-linux-gnu/bits/c++config.h:284 #3 std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::operator[] (this=0x1a053c8, __pos=2) at /usr/include/c++/4.4/bits/basic_string.h:743 #4 0x0061a372 in lyx::Paragraph::isWordSeparator (this=0x1a203e0, pos=2) at Paragraph.cpp:2852 #5 0x0061a4fc in lyx::Paragraph::locateWord (this=0x1a203e0, from=@0x7fff5ad0, to=@0x7fff5ad8, loc=4294967295) at Paragraph.cpp:3441 #6 0x005300a0 in lyx::DocIterator::locateWord (this=value optimized out, loc=lyx::WHOLE_WORD) at DocIterator.cpp:201 #7 0x00718e5c in lyx::Cursor::checkNewWordPosition (this=0x1a2cd68) at Cursor.cpp:563 #8 0x00719046 in lyx::Cursor::resetAnchor (this=0x1a2cd68) at Cursor.cpp:506 #9 0x007190c4 in lyx::Cursor::clearSelection (this=0x168f) at Cursor.cpp:1157 #10 0x0072b72f in lyx::cap::cutSelection (cur=..., doclear=value optimized out, realcut=value optimized out) at CutAndPaste.cpp:786 Can you check whether this is fixed by r37899 ? If not, can you try to revert to r37462. Maybe it's also a regression introduced in r37463. I don't think r37462 is related. The LyX checkout r37923 (of course including r37899) does not crash with your simple test-case. Tommaso, do you have a clean checkout of r37923 to test it? Stephan
Re: ANNOUNCE: LyX version 2.0.0 (release candidate 1)
Am 14.03.2011 um 07:59 schrieb Stephan Witt: Am 13.03.2011 um 22:25 schrieb Vincent van Ravesteijn: Op 13-3-2011 22:20, Tommaso Cucinotta schreef: Il 13/03/2011 21:46, Vincent van Ravesteijn ha scritto: A backtrace would be more useful :S.. I know, sorry, but I reduced the problem to a simple test-case: 1. C-n (new document) 2. a b 3. [Shift+Left][Shift-left] (select the b part, including the leading space) 4. [Space] #2 0x0063027c in __replacement_assert (this=0x1a053c8, __pos=2) at /usr/include/c++/4.4/x86_64-linux-gnu/bits/c++config.h:284 #3 std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::operator[] (this=0x1a053c8, __pos=2) at /usr/include/c++/4.4/bits/basic_string.h:743 #4 0x0061a372 in lyx::Paragraph::isWordSeparator (this=0x1a203e0, pos=2) at Paragraph.cpp:2852 #5 0x0061a4fc in lyx::Paragraph::locateWord (this=0x1a203e0, from=@0x7fff5ad0, to=@0x7fff5ad8, loc=4294967295) at Paragraph.cpp:3441 #6 0x005300a0 in lyx::DocIterator::locateWord (this=value optimized out, loc=lyx::WHOLE_WORD) at DocIterator.cpp:201 #7 0x00718e5c in lyx::Cursor::checkNewWordPosition (this=0x1a2cd68) at Cursor.cpp:563 #8 0x00719046 in lyx::Cursor::resetAnchor (this=0x1a2cd68) at Cursor.cpp:506 #9 0x007190c4 in lyx::Cursor::clearSelection (this=0x168f) at Cursor.cpp:1157 #10 0x0072b72f in lyx::cap::cutSelection (cur=..., doclear=value optimized out, realcut=value optimized out) at CutAndPaste.cpp:786 Can you check whether this is fixed by r37899 ? If not, can you try to revert to r37462. Maybe it's also a regression introduced in r37463. I don't think r37462 is related. The LyX checkout r37923 (of course including r37899) does not crash with your simple test-case. Hmm... now I've tried it on Linux and get the crash. I don't know the difference to Mac - but now I have a chance to find it myself. Stephan
Re: ANNOUNCE: LyX version 2.0.0 (release candidate 1)
Am 14.03.2011 um 08:34 schrieb Tommaso Cucinotta:
Il 14/03/2011 07:59, Stephan Witt ha scritto:
Am 13.03.2011 um 22:25 schrieb Vincent van Ravesteijn:
Op 13-3-2011 22:20, Tommaso Cucinotta schreef:
Il 13/03/2011 21:46, Vincent van Ravesteijn ha scritto:
A backtrace would be more useful :S..
I know, sorry, but I reduced the problem to a simple test-case:
1. C-n (new document)
2. a b
3. [Shift+Left][Shift-left] (select the b part, including the leading
space)
4. [Space]
#2 0x0063027c in __replacement_assert (this=0x1a053c8, __pos=2)
at /usr/include/c++/4.4/x86_64-linux-gnu/bits/c++config.h:284
#3 std::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t ::operator[] (this=0x1a053c8, __pos=2) at
/usr/include/c++/4.4/bits/basic_string.h:743
#4 0x0061a372 in lyx::Paragraph::isWordSeparator (this=0x1a203e0,
pos=2) at Paragraph.cpp:2852
#5 0x0061a4fc in lyx::Paragraph::locateWord (this=0x1a203e0,
from=@0x7fff5ad0, to=@0x7fff5ad8, loc=4294967295) at
Paragraph.cpp:3441
#6 0x005300a0 in lyx::DocIterator::locateWord (this=value
optimized out, loc=lyx::WHOLE_WORD) at DocIterator.cpp:201
#7 0x00718e5c in lyx::Cursor::checkNewWordPosition
(this=0x1a2cd68) at Cursor.cpp:563
#8 0x00719046 in lyx::Cursor::resetAnchor (this=0x1a2cd68) at
Cursor.cpp:506
#9 0x007190c4 in lyx::Cursor::clearSelection (this=0x168f) at
Cursor.cpp:1157
#10 0x0072b72f in lyx::cap::cutSelection (cur=..., doclear=value
optimized out, realcut=value optimized out) at CutAndPaste.cpp:786
Can you check whether this is fixed by r37899 ? If not, can you try to
revert to r37462. Maybe it's also a regression introduced in r37463.
I don't think r37462 is related.
The LyX checkout r37923 (of course including r37899) does not crash with
your simple test-case.
Tommaso, do you have a clean checkout of r37923 to test it?
yes, that's that version is crashing.
Ok, I think it's the fact on Mac my runtime does not check for array indices
out of bounds.
I don't know how to enable this with cmake+Xcode. Just another construction
area...
In my ~/.lyx I have:
\spellchecker \spellcheck_continuously
Really? You have no spell checker but have enabled spellcheck_continuously?
\spellcheck_continuously true
However, if starting with a clean userdir, then in the prefs panel I cannot
change the spellchecking options (the whole panel is grayed out).
I think you have no spell checker backend compiled in.
Regarding the crash I made more checks to validate the DocIterator before
calling locateWord().
Please try the attached patch.
Stephan
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (Revision 37923)
+++ src/Cursor.cpp (Arbeitskopie)
@@ -552,11 +552,17 @@
if (!inTexted())
clearNewWordPosition();
else {
- // forget the position of the current started word
+ // forget the position of the current new word if
// 1) the paragraph changes or
- // 2) the count of nested insets changes
- if (pit() != new_word_.pit() || depth() != new_word_.depth())
+ // 2) the count of nested insets changes or
+ // 3) the cursor pos is out of paragraph bound
+ if (pit() != new_word_.pit() ||
+ depth() != new_word_.depth() ||
+ new_word_.pos() new_word_.lastpos()) {
clearNewWordPosition();
+ } else if (new_word_.fixIfBroken())
+ // 4) or the remembered position was broken
+ clearNewWordPosition();
else {
FontSpan nw = locateWord(WHOLE_WORD);
if (nw.size()) {
@@ -2271,6 +2243,7 @@
bool const broken_anchor = anchor_.fixIfBroken();
if (broken_cursor || broken_anchor) {
+ clearNewWordPosition();
clearSelection();
return true;
}
Re: [RFC] what is a word (boundary)?
Am 15.03.2011 um 10:59 schrieb Jürgen Spitzmüller: Jürgen Spitzmüller wrote: I propose the attached patch (this is the second option). Another version. It looks sensible to me to make NOBREAKDASH isLetter(), as far as the use of this variable is concerned. (the description of it is not very clear, especially the differentiation from isChar()) Can I commit this patch? I tried it and it looks ok to me. One strange observation I've made: when using Aspell it suggests key-bindings as one possible replacement of keybindings. If I choose it it remains marked with the misspelled line. Stephan
Re: [RFC] what is a word (boundary)?
Am 15.03.2011 um 12:12 schrieb Jürgen Spitzmüller: Stephan Witt wrote: One strange observation I've made: when using Aspell it suggests key-bindings as one possible replacement of keybindings. If I choose it it remains marked with the misspelled line. AFAIK Aspell has no proper support for composites with hyphens. It just cannot deal with hyphens in input, as it were. Ok, it shouldn't propose it then perhaps. Of course we can make Aspell ignore the hyphens, but IMHO this does not really solve the problem, on the contrary. If we pass all parts of hyphenated composites as separate words to aspell (as we do now), the spell checking of composites becomes pretty dubious IMHO. The spellchecker currently happily accepts composites such as table-fruit-onion-give-with-sober-an, just because it knows any single component. As a user, I think I'd prefer the spellchecker to ask me if I'm serious in light of such beasts. Hunspell and Apples native spell checker both like it. :) Stephan
LFUN_PASTE and cursor position
Shouldn't the text cursor jump at the end of pasted text after the the insertion completed? Is there any ticket for that? Stephan
PATCH for #7361
See ticket http://www.lyx.org/trac/ticket/7361
AFAICS, the problem here is the error position at the first empty paragraph of
the document.
The attached patch stops the goto in this case.
Enrico, do you have a better solution?
Stephan
Index: src/frontends/qt4/GuiErrorList.cpp
===
--- src/frontends/qt4/GuiErrorList.cpp (Revision 37939)
+++ src/frontends/qt4/GuiErrorList.cpp (Arbeitskopie)
@@ -173,8 +173,13 @@
}
// If this paragraph is empty, highlight the previous one
- while (dit.paragraph().empty())
+ while (dit.paragraph().empty()) {
dit.backwardPos();
+ if (dit.empty()) {
+ LYXERR0(par id err.par_id invalid);
+ return false;
+ }
+ }
// Now make the selection.
// if pos_end is 0, this means it is end-of-paragraph
Re: severe problem with shaded boxes
Am 16.03.2011 um 15:10 schrieb Jürgen Spitzmüller: I cannot (yet) nail down this, and it's not always reproducible (actually, I fail to reproduce it ATM), but I report it nevertheless since it strikes me to be a severe problem (a release blocker): * insert a shaded box * go to document settings and change the shade color (I set it to grey, #DD) * press OK and note that the message bar displays weird characters (looks like binary actually) * View View * a huge popup appears, again filled with weird characters * LyX freezes or crashes, in one case it crashed down the Desktop (KDE 4.6) and X Server, losing all unapplied data I managed to reproduce this on two different machines. Can anyone reproduce this? Sorry, I cannot reproduce it on Mac with SVN. Stephan
Re: r37940 - lyx-devel/trunk/src
Am 16.03.2011 um 18:58 schrieb sw...@lyx.org:
Author: switt
Date: Wed Mar 16 18:58:27 2011
New Revision: 37940
URL: http://www.lyx.org/trac/changeset/37940
Log:
#7357 avoid an endless loop in countWords() when the to position is inside
skipped text (e. g. note inset)
Sorry for the hassle... now the endless loop is gone -
but after thinking again I realized that countWords() obviously has to different
use cases and it cannot be used as is for both.
1. Count the words of the resulting document for statistics - ignore inset
content without output.
2. Count the words to check the spelling to present a progress bar - has to
count all content.
The attached patch solves it. Furthermore it solves the problem I introduced
with
this commit with the comparison of the doc iterator with end-of-document.
Stephan
Index: src/buffer_funcs.cpp
===
--- src/buffer_funcs.cpp(Revision 37940)
+++ src/buffer_funcs.cpp(Arbeitskopie)
@@ -180,12 +185,13 @@
* notion of what to count. Since nobody ever complained about that,
* this proves (again) that any number beats no number ! (JMarc)
*/
-int countWords(DocIterator const from, DocIterator const to)
+int countWords(DocIterator const from, DocIterator const to,
+ bool skipNoOutput)
{
int count = 0;
bool inword = false;
- for (DocIterator dit = from ; dit != to !dit.empty(); ) {
+ for (DocIterator dit = from ; dit != to !dit.atEnd(); ) {
if (!dit.inTexted()) {
dit.forwardPos();
continue;
@@ -199,10 +205,10 @@
inword = false;
} else if (!par.isDeleted(pos)) {
Inset const * ins = par.getInset(pos);
- if (ins !ins-producesOutput()) {
+ if (ins skipNoOutput !ins-producesOutput()) {
//skip this inset
++dit.top().pos();
- if (dit = to)
+ if (!to.atEnd() dit = to)
break;
continue;
}
Index: src/buffer_funcs.h
===
--- src/buffer_funcs.h (Revision 37939)
+++ src/buffer_funcs.h (Arbeitskopie)
@@ -47,7 +47,8 @@
Buffer * loadIfNeeded(support::FileName const fname);
/// Count the number of words in the text between these two iterators
-int countWords(DocIterator const from, DocIterator const to);
+int countWords(DocIterator const from, DocIterator const to,
+ bool skipNoOutput = true);
/// Count the number of chars in the text between these two iterators
int countChars(DocIterator const from, DocIterator const to, bool
with_blanks);
Index: src/frontends/qt4/GuiSpellchecker.cpp
===
--- src/frontends/qt4/GuiSpellchecker.cpp (Revision 37939)
+++ src/frontends/qt4/GuiSpellchecker.cpp (Arbeitskopie)
@@ -270,8 +270,8 @@
DocIterator const begin = doc_iterator_begin(buffer());
Cursor const cur = bufferview()-cursor();
- d-progress_ = countWords(begin, cur);
- d-total_ = d-progress_ + countWords(cur, doc_iterator_end(buffer()));
+ d-progress_ = countWords(begin, cur, false);
+ d-total_ = d-progress_ + countWords(cur, doc_iterator_end(buffer()),
false);
d-count_ = 0;
return true;
}
