Re: [PATCH] Change default mathbg and add mathhoverbg.
On Wed, Jun 06, 2007 at 12:39:32AM +0200, Enrico Forestieri wrote: On Wed, Jun 06, 2007 at 12:28:54AM +0200, Andre Poenitz wrote: On Tue, Jun 05, 2007 at 11:48:25PM +0200, Enrico Forestieri wrote: On Tue, Jun 05, 2007 at 11:37:48PM +0200, Jean-Marc Lasgouttes wrote: Bo == Bo Peng [EMAIL PROTECTED] writes: Bo I can not imagine anything else you might want to experiment in Bo 1.6.0. Get rid of the corners and use background instead in order to avoid those extra blank pixels? What when insets are nested? Are you proposing to use a different colour for each nested inset? Nah... I think it might be sufficient do color the innermost inset still containing the cursor. As I already said, what is the difference with respect to simply showing the corners without reserving space for them? The corners would not overwrite inset contents. Nevertheless we'd lose visual information this way, as right now we also see the nesting leading to the cursor position which _I_ find rather helpful (otherwise there weren't these cure l'll corners anyway...) You can get that info by looking at the status line. Too far away. Andre'
Re: [PATCH] Change default mathbg and add mathhoverbg.
On Wed, Jun 06, 2007 at 12:53:49AM +0200, Enrico Forestieri wrote: I tried that a while ago and this is no good as the corners cover part of the content, especially if you have a small font. Well, you can't eat your cake and still have it... We have to decide what is worse. The current behavior has been there for ages, and the only problem is that one could miss a missing space after a math inset. I think that I can live with this limitation, but suddenly it becomes something so vital that it is preferable turning the LyX screen into a Christmas tree (thanks for this definition meant for effect, Edwin :) Depends on your definition of 'ages'... If you are leaving an inset using arrow left or right and this inset is nested in another inset, show the corners of the new inset but don't move the cursor. When leaving an inset with arrow left/right, you actually move the cursor only if there is no containing inset. Even if the cursor is not moved, it logically belongs to an inset or another. Which one you can tell by looking at the status line. Status line is good for exact information, but when entering a complex formula one does not want to look on the formula, at the status line, at the formula, at the status line etc. Actually, this works quite well in texmacs, but I prefer the LyX way, too. However, if I have to decide between a Christmas tree and this last behavior, I don't have any doubt... I don't know if there's a bug open on this issue, but if there is one, I think that this one of those WONTFIX cases. Fine with me. Andre'
Re: Converter problem with Mac OS packages
On Wed, Jun 06, 2007 at 01:01:30AM +0200, Mael Hilléreau wrote: Le 6 juin 07 à 00:40, Andre Poenitz a écrit : On Wed, Jun 06, 2007 at 12:37:31AM +0200, Mael Hilléreau wrote: Le 6 juin 07 à 00:23, Andre Poenitz a écrit : It would make sense to compute checksum only if the timestamp is different: it then saves the conversion process in the case no new modifications exist (i.e. the file was saved but not modified). That assumes that changed files cannot have the same time stamp. Even if that might hold true in most cases POSIX guarantees only 1 sec resolution, FAT has 2 IIRC. One can have tons of changes in that time ??? I think you're incredibly productive if you can modify AND save a graphic file more than one time per second! We are talking about automated conversion, aren't we? I thought we were talking about automated conversion arising after a manual external file modification. But if not, could you explain further? !! But if we suppose that, then you won't care to wait the next second for a screen update to come up ;) Is it only screen update, or is it also correctness of conversion? This was joking. Nevertheless, IMHO the timestamp is a good solution for almost 99,% of time. The remaining 0,0001% being outdated screens, unless you can compile/modif/save/recompile in less than 1 sec... (however, assuming that file formats are different for on screen preview and for output...) Anyway, we may agree that when dealing with graphics, the CRC should only be computed when timestamps are identical, do we? Not sure. Different timestamps and equal contents might be possible in which case it'd probably be not the worst solution to do nothing. Andre'
Re: Annoying Mac Bug....
Am 06.06.2007 um 00:03 schrieb Mael Hilléreau:
Le 5 juin 07 à 19:20, Richard Heck a écrit :
Can someone on Mac sort this out: http://bugzilla.lyx.org/
show_bug.cgi?id=3818? I think I know what needs to be done, but
I'm not on Mac. See my comments. Should be simple.
Tested on Intel Mac OS 10.4.9, with 1.5.0rc1: your #ifdef
USE_NATIVE_FILEDIALOG fixes the problem.
No, it doesn't. USE_NATIVE_FILEDIALOG is not defined in callback.cpp
on any platform. Putting an #ifdef around the part is like #ifdef
0. The right patch is attached.
Stefan
Index: src/callback.cpp
===
--- src/callback.cpp(Revision 18677)
+++ src/callback.cpp(Arbeitskopie)
@@ -127,6 +127,7 @@
{
string fname = buffer-fileName();
string const oldname = fname;
+ bool askForOverwriteConfirmation = true;
if (newname.empty()) {
@@ -158,11 +159,16 @@
fname = makeAbsPath(fname).absFilename();
if (!isLyXFilename(fname))
fname += .lyx;
+
+ // either the dialog asks for overwriting or we do it below
+ if (fileDlg.asksForOverwriteConfirmation())
+ askForOverwriteConfirmation = false;
} else
fname = newname;
FileName const filename(fname);
- if (fs::exists(filename.toFilesystemEncoding())) {
+ if (askForOverwriteConfirmation
+ fs::exists(filename.toFilesystemEncoding())) {
docstring const file = makeDisplayPath(fname, 30);
docstring text = bformat(_(The document %1$s already
exists.\n\n
Do you want to over-write that
document?), file);
Index: src/frontends/qt4/FileDialog.cpp
===
--- src/frontends/qt4/FileDialog.cpp(Revision 18677)
+++ src/frontends/qt4/FileDialog.cpp(Arbeitskopie)
@@ -180,4 +180,13 @@
}
+bool FileDialog::asksForOverwriteConfirmation()
+{
+#ifdef USE_NATIVE_FILEDIALOG
+ return true;
+#else
+ return false;
+#endif
+}
+
} // namespace lyx
Index: src/frontends/FileDialog.h
===
--- src/frontends/FileDialog.h (Revision 18677)
+++ src/frontends/FileDialog.h (Arbeitskopie)
@@ -77,6 +77,9 @@
support::FileFilterList const filters,
docstring const suggested);
+ /// Does the dialog ask for an overwrite confirmation itself?
+ bool asksForOverwriteConfirmation();
+
private:
class Private;
friend class Private;
nodoubleconfirmationonmac.patch
Description: Binary data
PGP.sig
Description: Signierter Teil der Nachricht
Re: Fixing #3790, 3801, 3809 in the only right way, no further patchworks!
The reason for the crash:
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (Revision 18674)
+++ src/Cursor.cpp (Arbeitskopie)
@@ -1438,18 +1438,33 @@
Font Cursor::getFont() const
{
+ // The logic here should more or less match to the
Text::setCurrentFont
+ // logic, i.e. the cursor height should give a hint what will happen
+ // if a character is entered.
+
// HACK. far from being perfect...
- int s = 0;
// go up until first non-0 text is hit
// (innermost text is 0 in mathed)
+ int s = 0;
for (s = depth() - 1; s = 0; --s)
if (operator[](s).text())
break;
CursorSlice const sl = operator[](s);
Text const text = *sl.text();
- Font font = text.getPar(sl.pit()).getFont(
- bv().buffer()-params(),
- sl.pos(),
+ Paragraph const par = text.getPar(sl.pit());
+
+ // on boundary, so we are really at the character before
+ pos_type pos = sl.pos();
+ if (pos 0 boundary())
+ --pos;
+
+ // on space? Take the font before (only for RTL boundary stay)
+ if (pos 0 par.isSeparator(pos)
Here we have to check for pos == sl.lastpos() as well:
// on space? Take the font before (only for RTL boundary stay)
if (pos 0) {
if (pos == sl.lastpos()
|| (par.isSeparator(pos) !text.isRTLBoundary(buffer(), par,
pos)))
--pos;
}
+ !text.isRTLBoundary(buffer(), par, pos))
+ --pos;
+
+ // get font at the position
+ Font font = par.getFont(bv().buffer()-params(), pos,
outerFont(sl.pit(), text.paragraphs()));
return font;
PGP.sig
Description: Signierter Teil der Nachricht
Re: How to make Lyx DRAMATICALLY better.
On Tuesday 05 June 2007 23:17:31 Andre Poenitz wrote: Buts it would be sufficient if only insets that _do_ have a variable background would have that member. OK. I did not notice that it was in the base member but then it makes sense to be static since that is a property of the class not of the particular instance. Andre' -- José Abílio
Re: Converter problem with Mac OS packages
Mael == Mael Hilléreau [EMAIL PROTECTED] writes: Mael Le 6 juin 07 à 00:04, Jean-Marc Lasgouttes a écrit : The complexity depends on the total size of the data. A big file is worse than a small directory. Mael Just a last word on this: the complexity doesn't depend on the Mael total size of the data, it depends on the total amount of data Mael processing, which may not be proportional. Yes. (Ha! I got the last word!) JMarc
Re: How to make Lyx DRAMATICALLY better.
Bo == Bo Peng [EMAIL PROTECTED] writes: No, you are making my problems ;-) When I want to change background I have to take into account mathhoverbg, too. Please, remove that. Bo This part is true, but the same goes to buttonbg and Bo buttonhoverbg. No because these do not use the window background color by default. JMarc
Re: How to make Lyx DRAMATICALLY better.
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Tue, Jun 05, 2007 at 10:07:40PM +0100, José Matos wrote: On Tuesday 05 June 2007 19:16:08 Andre Poenitz wrote: Right. Commit 17913 added int InsetBase::background_color_ to InsetBase that used to be 16 bytes a while ago. Andre' Cann't that be a class method instead of an instance method? (In C++ parlance mode a static class method/data I think). Andre Not really, as this assumes that all inset backgrounds are Andre equal. Andre Buts it would be sufficient if only insets that _do_ have a Andre variable background would have that member. Why don't we just use a virtual mathod? Is it really necessary to customize each inset's color. JMarc
Re: How to make Lyx DRAMATICALLY better.
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Or replace the corners by a change of color of the inset that is currently edited. Andre That would be the _outermost_ inset that's being edited? Don't know :) JMarc
Re: [PATCH] Change default mathbg and add mathhoverbg.
On Tuesday 05 June 2007 23:53:49 Enrico Forestieri wrote: LyX screen into a Christmas tree (thanks for this definition meant for effect, Edwin :) What do you have against the Christmas tree? After all we always release the stable version on Christmas so I don't see any problem following the traditions of the season. ;-) -- José Abílio
Re: [PATCH] 3810 --add check for evince
Richard == Richard Heck [EMAIL PROTECTED] writes:
Richard I didn't change the order except for inserting evince, but I
Richard agree. I'd do this:
Richard checkViewer('a Postscript previewer', ['evince',
Richard 'kghostview', 'gv', 'ghostview -swap'],
Yes, but I'd propose to put kghostview before evince by symmetry with
PDF (and because lyx is a qt app).
JMarc
Re: [PATCH] Change default mathbg and add mathhoverbg.
Andre == Andre Poenitz [EMAIL PROTECTED] writes: I think it might be sufficient do color the innermost inset still containing the cursor. As I already said, what is the difference with respect to simply showing the corners without reserving space for them? Andre The corners would not overwrite inset contents. +1 Nevertheless we'd lose visual information this way, as right now we also see the nesting leading to the cursor position which _I_ find rather helpful (otherwise there weren't these cure l'll corners anyway...) You can get that info by looking at the status line. Andre Too far away. +1 JMarc
Re: [PATCH] Change default mathbg and add mathhoverbg.
Andre == Andre Poenitz [EMAIL PROTECTED] writes: I don't know if there's a bug open on this issue, but if there is one, I think that this one of those WONTFIX cases. Andre Fine with me. +1 JMarc
Re: Fixing #3790, 3801, 3809 in the only right way, no further patchworks!
One relevant point from there to here, though: I'm not sure you'll be able to do away with bidi entirely. For example, as I suggest in that thread, for visual mode I think we'll have to use vis2log and log2vis. And once we're using anything Bidi related in cursor movement, we'll have to solve the problem for that anyway; so is it still worth going through with all this? It'll just make us have the bidi logic in *two* places instead of one, and in a slightly different form, to boot... We have two places already and with the current implementation we will always have them. But reducing the number of references to the bidi object makes it much simpler because the Font information for RTL is much more stable. There are basically two kinds of information about bidi we use at the moment: 1) RTL or LTR at one position 2) relations between visual - logical positions For 1 the font information is enough, so no bidi object whatsoever needed. This information is in the font of each character. Of course also boundary detection is part of 1. For 2 of course we need more global knowledge of a complete line. And here we cannot avoid the Bidi class. But the place where 2 is used are only a little part of the LTR/RTL related code. So reducing the bidi accesses to case 2 is already a big step forward in code quality. It's hard to follow multiple patches at once, especially if they are not totally separated in a logical way (for example, I'm pretty sure that nobidi.patch includes a change which actually belongs in rtlepmnobidi.patch --- specifically the change at hunk @@ -1161,7 +1153,8 @@ in Text2.cpp) --- and they also don't apply cleanly over each other because of that... I very warmly recommend using quilt (the best place I've found for getting started with it is here: http://www.coffeebreaks.org/ blogs/wp-content/archives/talks/2005/quilt/quiltintro-s5.html) --- I only started using it about a month ago, and I already can't understand how one can develop code without it. It is a wonderful tool aimed specifically at making it easier to handle multiple patches. It'll take you at most a few days to get used to, and it makes life so much easier. There are also a few alternatives mentioned, I haven't tried them myself, though... Sounds interesting. Thanks! Will look into it. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Bugzilla Bookmarklet
Richard Heck wrote: In Firefox, you can create a bookmark and put the above as the URL. Then choosing the bookmark will pop up a dialog asking for the bug number and send you there. FWIW, in Konqueror, you can define Web shortcuts. Defininig the shortcut lyxbug: http://bugzilla.lyx.org/[EMAIL PROTECTED] I need just insert lyxbug:2007 in the adress widget to get to bug 2007. Jürgen
Re: Annoying Mac Bug....
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan No, it doesn't. USE_NATIVE_FILEDIALOG is not defined in
Stefan callback.cpp on any platform. Putting an #ifdef around the
Stefan part is like #ifdef 0. The right patch is attached.
+bool FileDialog::asksForOverwriteConfirmation()
+{
+#ifdef USE_NATIVE_FILEDIALOG
+ return true;
+#else
+ return false;
+#endif
+}
Are you sure about that? What about windows for example?
QFileDialog has a confirmOverwrite that looks very sweet to me. I can
it can be set or queried, depending on what we want to achieve.
JMarc
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Richard == Richard Heck [EMAIL PROTECTED] writes: Richard Jean-Marc Lasgouttes wrote: update toc and list of xxx seems to me an expensive operation. Can it be done on demand? I mean, maybe we can add a 'refresh'/'regenerate' button in the outline panel; and update 'list of listings' and such only if this menu item is clicked. This is how it used to be in the good old time, but Abdel decided that automatic was cooler... Richard Cooler, definitely, and this is what users will expect, Richard especially with the navigate menu. So there is also the Richard question about how one might regenerate the navigation menu. The navigation menu is regenerated just before displaying it. At least this is what it used to do, without much overhead. JMarc
Re: Converter problem with Mac OS packages
Le 6 juin 07 à 08:03, Andre Poenitz a écrit : This was joking. Nevertheless, IMHO the timestamp is a good solution for almost 99,% of time. The remaining 0,0001% being outdated screens, unless you can compile/modif/save/recompile in less than 1 sec... (however, assuming that file formats are different for on screen preview and for output...) Anyway, we may agree that when dealing with graphics, the CRC should only be computed when timestamps are identical, do we? Not sure. Different timestamps and equal contents might be possible in which case it'd probably be not the worst solution to do nothing. It seems to me that you're thinking of situations which are really improbable... As I said above, one never opens a figure into its editor in order to save the file without changing it! If you don't think so, please could you give me an example? Mael.
Re: Annoying Mac Bug....
Am 06.06.2007 um 09:36 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan No, it doesn't. USE_NATIVE_FILEDIALOG is not defined in
Stefan callback.cpp on any platform. Putting an #ifdef around the
Stefan part is like #ifdef 0. The right patch is attached.
+bool FileDialog::asksForOverwriteConfirmation()
+{
+#ifdef USE_NATIVE_FILEDIALOG
+ return true;
+#else
+ return false;
+#endif
+}
Are you sure about that? What about windows for example?
QFileDialog has a confirmOverwrite that looks very sweet to me. I can
it can be set or queried, depending on what we want to achieve.
Well, at the moment confirmOverwrite is set to false for the non-
native dialog. You might question this decision and set it to true,
and change the asksForOverwriteConfirmation then accordingly. But
that's not matter of my patch. It's only about the static
getSaveFileName (was it called like that, don't have the code
here...) method used for the native dialog.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: Annoying Mac Bug....
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan Well, at the moment confirmOverwrite is set to false for the Stefan non- native dialog. You might question this decision and set Stefan it to true, and change the asksForOverwriteConfirmation then Stefan accordingly. But that's not matter of my patch. It's only Stefan about the static getSaveFileName (was it called like that, Stefan don't have the code here...) method used for the native Stefan dialog. One can pass the following options to getSaveFileName: QFileDialog::DontConfirmOverwrite Don't ask for confirmation if an existing file is selected. By default confirmation is requested. So (1) your patch was correct :) (2) we could force confirmation in the non-native case too and simplify our code. JMarc
Re: Annoying Mac Bug....
Am 06.06.2007 um 09:49 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan Well, at the moment confirmOverwrite is set to false for the Stefan non- native dialog. You might question this decision and set Stefan it to true, and change the asksForOverwriteConfirmation then Stefan accordingly. But that's not matter of my patch. It's only Stefan about the static getSaveFileName (was it called like that, Stefan don't have the code here...) method used for the native Stefan dialog. One can pass the following options to getSaveFileName: QFileDialog::DontConfirmOverwrite Don't ask for confirmation if an existing file is selected. By default confirmation is requested. Was looking into the docs for that, but didn't see it :) So (1) your patch was correct :) (2) we could force confirmation in the non-native case too and simplify our code. And force any frontend (even if we have only one currently) to do that overwrite dialog? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Annoying Mac Bug....
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: (2) we could force confirmation in the non-native case too and simplify our code. Stefan And force any frontend (even if we have only one currently) to Stefan do that overwrite dialog? Yes. Just document it. JMarc
Re: [PATCH] 3810 --add check for evince
On Wed, 2007-06-06 at 09:29 +0200, Jean-Marc Lasgouttes wrote:
Richard == Richard Heck [EMAIL PROTECTED] writes:
Richard I didn't change the order except for inserting evince, but I
Richard agree. I'd do this:
Richard checkViewer('a Postscript previewer', ['evince',
Richard 'kghostview', 'gv', 'ghostview -swap'],
Yes, but I'd propose to put kghostview before evince by symmetry with
PDF (and because lyx is a qt app).
I only just paid attention to this thread because I built the latest LyX
and found that I don't like this change :) Sorry if my comment is
repeated.
I was sitting there, in bewilderment, because my overview of all the
pages on the left was missing! I tried, oh how I tried. Couldn't be
anything I did since five minutes ago, could it? Hmm. Wasn't using
evince before!
I've changed mine back to kghostview so I can navigate tons of boring
pages to find the one modification I made in LyX. Until LyX is able to
jump me to the location in the PS/PDF where my cursor is, I will always
require some help when navigating to that spot. Evince just isn't up to
it!
Have fun,
Darren
Re: Annoying Mac Bug....
Am 06.06.2007 um 09:55 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: (2) we could force confirmation in the non-native case too and simplify our code. Stefan And force any frontend (even if we have only one currently) to Stefan do that overwrite dialog? Yes. Just document it. You make a patch? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Change tracking and replace: unexpected behavior
Bennett Helm wrote: On Jun 5, 2007, at 9:52 AM, Jean-Marc Lasgouttes wrote: Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes: Jürgen Bennett Helm wrote: Create a document with multiple occurrences of foo. Turn change tracking on, select a chunk of text (including some occurrences of foo), and delete. Now go to the top and turn change tracking *off*. Using Edit Find Replace, Replace all instances of foo with bar. The instances of foo in the change-tracked deleted text have now been replaced with instances of bar, but they are no longer deleted. This is unexpected -- at least by me. Jürgen Here's a patch for replace all. As noted on bugzilla, I'm not Jürgen sure we should restrict manual replace. I think we should restrict manual replace too (if possible). It should not be allowed to do with replace something that would not be possible via normal editing. I agree with the last sentence, but notice that the patch doesn't do this! When change tracking is turned off, it is entirely possible to delete -- remove from the file -- text that is marked as deleted. Then you simply commit (parts of) that deletion, albeit without using the change tracking machinery. I see nothing very wrong with that. Nonetheless, I think even manual replace ought to skip deleted text. It's not expected behavior even on manual replace to replace deleted text with undeleted text (as the patch currently allows). And I don't think we should replace deleted text with deleted text either: that obscures the document history which is part of the point of change tracking. If you turn off change tracking and edit, then surely all new stuff should be without the change tracking markings. (i.e. not deleted or marked as inserted by someone.) You may be able to add inside a deleted region, but that should split the deleted region in two. A user wanting something different should turn the change tracking on and use it. Adding deleted text is a lot like lying about what happened. Helge Hafting
Re: How to make Lyx DRAMATICALLY better.
Enrico Forestieri wrote: Maybe we can try to avoid not having a space after math. I mean, when you leave a math inset by hitting the space bar, LyX does not insert a space after the math and perhaps it should. I think that this change would cure the vast majority of missing space after math cases. Yes - adding a normal space in this case seems ok - the user pressed space after all. If she don't want a space, she can delete it again (it was added to the text, not added during latex export.) The user that knows she don't need a space can exit the math with right-arrow instead. Helge Hafting
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
I think we have basically two things to discuss now: 1) the space issue at the boundaries between RTL/LTR 2) the visual movement Maybe we should seperate it to keep the overview, using two different topics... Stefan PGP.sig Description: Signierter Teil der Nachricht
Spaces on RTL boundaries
Continuing the discussion about the space issue here.
I have implemented Georg's idea/hint to allow spaces on both sides of
the RTL/LTR boundary, but let the empty-paragraph-mechanism (EPM, the
algorithm which among other things kills double spaces) take care of
double spaces around boundaries. Of course this needs the vis2log/
log2vis functions from the bidi object to get the logical position of
the character visually next to a space. I tried to make the usage as
safe as possible, i.e. ask for the range of the bidi cache and so on.
You will find the patches attached, to be applied in this order:
no_bidi_isboundary.patch
no_bidi_setcurrentfont.patch
cursor_get_font.patch
rtl_spaces.patch
@Dov: quilt is nice, thanks again for the hint
The patch of interest here is the last one, inlined below.
The basic idea is that the EPM considers the spaces in abc [ WERBEH]
ghi to be next to each other. So starting with abc[ WERBEH]ghi you
can enter space behind the abc and continue writing, or change your
mind after the space and the EPM takes away the new space:
abc|[ WERBEH]ghi = abc |[ WERBEH]ghi = abc|[ WERBEH]ghi
Similary for abc [|WERBEH]ghi.
Opinions?
Stefan
Index: lyx-devel/src/Bidi.cpp
===
--- lyx-devel.orig/src/Bidi.cpp 2007-06-06 10:16:43.0 +0200
+++ lyx-devel/src/Bidi.cpp 2007-06-06 10:38:19.0 +0200
@@ -95,7 +95,11 @@
pos_type const body_pos = par.beginOfBody();
for (pos_type lpos = start_; lpos = end_; ++lpos) {
- bool is_space = par.isLineSeparator(lpos);
+ bool is_space = false;
+ // We do not handle spaces around an RTL segment in a special way
anymore.
+ // Neither does LaTeX, so setting is_spacs to false makes the view
in LyX
+ // consistent with the output of LaTeX later. The old setting
was:
+ // is_space = par.isLineSeparator(lpos);
pos_type const pos =
(is_space lpos + 1 = end_
!par.isLineSeparator(lpos + 1)
Index: lyx-devel/src/Text.cpp
===
--- lyx-devel.orig/src/Text.cpp 2007-06-06 10:18:59.0 +0200
+++ lyx-devel/src/Text.cpp 2007-06-06 10:38:19.0 +0200
@@ -732,8 +732,20 @@
return;
}
BOOST_ASSERT(cur.pos() 0);
- if ((par.isLineSeparator(cur.pos() - 1) || par.isNewline(cur.pos()
- 1))
-!par.isDeleted(cur.pos() - 1)) {
+
+ // get character position visually in front of cur.pos()
+ pos_type prevpos;
+ bool ok = true;
+ if (cur.boundary())
+ prevpos = cur.pos() - 1;
+ else
+ ok = getPosVisuallyAway(cur.pos(), cur.boundary(), -1,
prevpos);
+
+ // no space if previous was space (or newline),
+ if (ok
+0 = prevpos prevpos par.size()
+(par.isLineSeparator(prevpos) ||
par.isNewline(prevpos))
+!par.isDeleted(prevpos)) {
static bool sent_space_message = false;
if (!sent_space_message) {
cur.message(_(You cannot type two spaces this way.
Index: lyx-devel/src/Text2.cpp
===
--- lyx-devel.orig/src/Text2.cpp2007-06-06 10:30:11.0 +0200
+++ lyx-devel/src/Text2.cpp 2007-06-06 10:38:19.0 +0200
@@ -1114,6 +1114,42 @@
}
+bool Text::getPosVisuallyAway(pos_type const start, bool boundary,
+ int visualDist, pos_type pos)
+{
+ if (!lyxrc.rtl_support) {
+ pos = start + visualDist;
+ return true;
+ }
+
+ // go to previous character on boundary, and later correct that
+ pos_type corrected_start = start;
+ if (boundary)
+ --corrected_start;
+
+ if (!bidi.inRange(corrected_start))
+ return false;
+
+ // Convert to visual position
+ pos_type vstart = bidi.log2vis(corrected_start);
+
+ // Go to visually next char
+ bool backward = bidi.level(corrected_start) 1;
+ pos_type vpos = backward ? (vstart - visualDist) : (vstart +
visualDist);
+ if (!bidi.inRange(vpos))
+ return false;
+
+ // And convert back to logical position
+ pos = bidi.vis2log(vpos);
+
+ // and finally correct the boundary again
+ if (boundary)
+ ++pos;
+
+ return true;
+}
+
+
bool Text::deleteEmptyParagraphMechanism(Cursor cur,
Cursor old, bool need_anchor_change)
{
@@ -1148,25 +1184,40 @@
// If the chars around the old cursor were spaces, delete one
Re: Fixing #3790, 3801, 3809 in the only right way, no further patchworks!
The updated patches, to be applied in this order:
no_bidi_isboundary.patch
no_bidi_setcurrentfont.patch
no_bidi_setcurrentfont.patch
Description: Binary data
no_bidi_isboundary.patch
Description: Binary data
As suggested by Dov, the discussion about spaces around RTL/LTR will
be continued in the other thread. I have also posted these two
patches there because the following RTL advances are based on this.
Stefan
Am 06.06.2007 um 09:13 schrieb Stefan Schimanski:
The reason for the crash:
Index: src/Cursor.cpp
===
--- src/Cursor.cpp (Revision 18674)
+++ src/Cursor.cpp (Arbeitskopie)
@@ -1438,18 +1438,33 @@
Font Cursor::getFont() const
{
+ // The logic here should more or less match to the
Text::setCurrentFont
+ // logic, i.e. the cursor height should give a hint what will
happen
+ // if a character is entered.
+
// HACK. far from being perfect...
- int s = 0;
// go up until first non-0 text is hit
// (innermost text is 0 in mathed)
+ int s = 0;
for (s = depth() - 1; s = 0; --s)
if (operator[](s).text())
break;
CursorSlice const sl = operator[](s);
Text const text = *sl.text();
- Font font = text.getPar(sl.pit()).getFont(
- bv().buffer()-params(),
- sl.pos(),
+ Paragraph const par = text.getPar(sl.pit());
+
+ // on boundary, so we are really at the character before
+ pos_type pos = sl.pos();
+ if (pos 0 boundary())
+ --pos;
+
+ // on space? Take the font before (only for RTL boundary stay)
+ if (pos 0 par.isSeparator(pos)
Here we have to check for pos == sl.lastpos() as well:
// on space? Take the font before (only for RTL boundary stay)
if (pos 0) {
if (pos == sl.lastpos()
|| (par.isSeparator(pos) !text.isRTLBoundary(buffer(), par,
pos)))
--pos;
}
+ !text.isRTLBoundary(buffer(), par, pos))
+ --pos;
+
+ // get font at the position
+ Font font = par.getFont(bv().buffer()-params(), pos,
outerFont(sl.pit(), text.paragraphs()));
return font;
PGP.sig
Description: Signierter Teil der Nachricht
[Fwd: keyboard issue with 1.5rc1]
This problem appeared on the user list. I can confirm that the problem is the same with a Norwegian keyboard. This is a regression. Original Message from [EMAIL PROTECTED] Hi everyone, This new version sure is really nice! I only have a little discomfort regarding key strokes. With 1.4 when I was in text mode and, for instance, typed Altm[ a math inset would automatically open with a full pair of brakets, the same for greek letters and so forth with all math symbols. With the new version I don't know how to do the same. When I try as before to insert directly greek letters then nothing happens (except a Command disabled message in the status bar). I need first to create an inset. That's annoying. But worse still is that when I'm within a math inset and type Altm[ I only end up with a single braket... I guess the reason is that to enter a [ I need to type AltGr5 and the program first processes AltGr, not coinsidering the two strokes as a single character. I was wondering if this were a new feature, and if so how I could tune it, or if I need to put some config file somewhere in the bindings, or if I did something wrong... though I felt I only compiled it and installed it and did nothing more unwise! I am willing to submit any necessary file if that helps, but I wouldn't know which. thank you for any answer, and for this nice piece of soft! Loïc Teyssier Config: - LyX 1.5rc1 Qt-4.2.1 and Qt-3.3.7 Debian Linux (etch) P6 (Intel Core2) French keyboard
Outline panel hidden at inappropriate times
I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following situations, the outline panel is hidden whereas it should remain visible: 1. Open several documents (e.g. User's guide and Introduction), show the outline, and close one of the documents; 2. Open one or more documents, show the outline, and execute a buffer- switch command (M-x, buffer-switch, enter) with or without the optional parameter. Anyone can confirm that this is a bug? Mael.
[PATCH] bug 3799: View=Toolbars=XXX produces confusing output in status line
http://bugzilla.lyx.org/show_bug.cgi?id=3799
I took a look at this bug and could not refrain from making some
changes to the toolbar code in the process.
This patch:
- gets rid of toolbar-toggle-state lfun, and adds a parameter
allowauto to toogle-toolbar instead.
- adds useful status messages when toggling a toolbar.
It is not critical for release, so I can hold it if somebody wants. I
tried to test it and I do not think I changed the behaviour of the
toolbars. The only change is that now the View Toolbar menu will show
either
[X] maths (auto)
or
[ ] maths (auto)
depending of the current visibility of the toolbar. I think it is
better anyway.
BTW, there are horrors in Toolbars.cpp like the TurnOnFlag
C-style macro (yuck) but I tried to avoid getting carried away.
JMarc
Index: src/LyXAction.cpp
===
--- src/LyXAction.cpp (révision 18688)
+++ src/LyXAction.cpp (copie de travail)
@@ -364,7 +364,6 @@ void LyXAction::init()
{ LFUN_WINDOW_NEW, window-new, NoBuffer },
{ LFUN_WINDOW_CLOSE, window-close, NoBuffer },
{ LFUN_UNICODE_INSERT, unicode-insert, Noop },
- { LFUN_TOOLBAR_TOGGLE_STATE, , NoBuffer },
{ LFUN_TOOLBAR_TOGGLE, toolbar-toggle, NoBuffer },
{ LFUN_NOMENCL_INSERT, nomencl-insert, Noop },
{ LFUN_NOMENCL_PRINT, nomencl-print, Noop },
Index: src/MenuBackend.cpp
===
--- src/MenuBackend.cpp (révision 18688)
+++ src/MenuBackend.cpp (copie de travail)
@@ -789,9 +789,10 @@ void expandToolbars(Menu tomenu)
for (; cit != end; ++cit) {
docstring label = _(cit-gui_name);
- // frontends are not supposed to turn on/off toolbars, if they cannot
- // update ToolbarBackend::flags. That is to say, ToolbarsBackend::flags
- // should reflect the true state of toolbars.
+ // frontends are not supposed to turn on/off toolbars,
+ // if they cannot update ToolbarBackend::flags. That
+ // is to say, ToolbarsBackend::flags should reflect
+ // the true state of toolbars.
//
// menu is displayed as
// on/off review
@@ -801,7 +802,7 @@ void expandToolbars(Menu tomenu)
if (cit-flags ToolbarInfo::AUTO)
label += _( (auto));
tomenu.add(MenuItem(MenuItem::Command, label,
-FuncRequest(LFUN_TOOLBAR_TOGGLE_STATE, cit-name)));
+FuncRequest(LFUN_TOOLBAR_TOGGLE, cit-name + allowauto)));
}
}
Index: src/frontends/LyXView.h
===
--- src/frontends/LyXView.h (révision 18688)
+++ src/frontends/LyXView.h (copie de travail)
@@ -156,7 +156,7 @@ public:
/// get toolbar state
ToolbarInfo::Flags getToolbarState(std::string const name);
/// toggle toolbar state
- void toggleToolbarState(std::string const name);
+ void toggleToolbarState(std::string const name, bool allowauto);
/// update the menubar
void updateMenubar();
/// update the status bar
Index: src/frontends/Toolbars.cpp
===
--- src/frontends/Toolbars.cpp (révision 18688)
+++ src/frontends/Toolbars.cpp (copie de travail)
@@ -187,7 +187,7 @@ ToolbarInfo::Flags Toolbars::getToolbarS
}
-void Toolbars::toggleToolbarState(string const name)
+void Toolbars::toggleToolbarState(string const name, bool allowauto)
{
ToolbarBackend::Toolbars::iterator cit = toolbarbackend.begin();
ToolbarBackend::Toolbars::iterator end = toolbarbackend.end();
@@ -203,8 +203,10 @@ void Toolbars::toggleToolbarState(string
} else if (flags ToolbarInfo::AUTO) {
TurnOffFlag(AUTO);
TurnOnFlag(OFF);
- } else if ((flags ToolbarInfo::MATH) || (flags ToolbarInfo::TABLE)
-|| (flags ToolbarInfo::REVIEW)) {
+ } else if (allowauto
+((flags ToolbarInfo::MATH)
+ || (flags ToolbarInfo::TABLE)
+ || (flags ToolbarInfo::REVIEW))) {
// for math etc, toggle from on - auto
TurnOffFlag(ON);
TurnOnFlag(AUTO);
@@ -213,7 +215,7 @@ void Toolbars::toggleToolbarState(string
TurnOffFlag(ON);
TurnOnFlag(OFF);
}
- cit-flags = static_castlyx::ToolbarInfo::Flags(flags);
+ cit-flags = static_castToolbarInfo::Flags(flags);
return;
}
}
Index: src/frontends/LyXView.cpp
===
--- src/frontends/LyXView.cpp (révision 18688)
+++ src/frontends/LyXView.cpp (copie de travail)
@@ -353,7 +353,7 @@ ToolbarInfo::Flags LyXView::getToolbarSt
}
-void LyXView::toggleToolbarState(string const name)
+void LyXView::toggleToolbarState(string const name, bool allowauto)
{
// it is possible to get current toolbar status like this,...
// but I decide to obey the order of ToolbarBackend::flags
@@ -361,7 +361,7 @@ void LyXView::toggleToolbarState(string
// toolbars_-saveToolbarInfo();
//
// toggle state on/off/auto
- toolbars_-toggleToolbarState(name);
+ toolbars_-toggleToolbarState(name, allowauto);
// update toolbar
[PATCH] Bug 3818: Save and replace asks twice whether to overwrite (Re: Annoying Mac Bug....)
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: http://bugzilla.lyx.org/show_bug.cgi?id=3818 Stefan You make a patch? OK. It turns out to be easier to disable overwrite control for the native dialog. Could some osx user test this patch? JMarc Index: src/frontends/qt4/FileDialog.cpp === --- src/frontends/qt4/FileDialog.cpp (révision 18688) +++ src/frontends/qt4/FileDialog.cpp (copie de travail) @@ -84,9 +84,14 @@ FileDialog::Result const FileDialog::sav #ifdef USE_NATIVE_FILEDIALOG docstring const startsWith = from_utf8( makeAbsPath(to_utf8(suggested), to_utf8(path)).absFilename()); - result.second = from_utf8(internal_path(fromqstr( + QString const name = QFileDialog::getSaveFileName(qApp-focusWidget(), - toqstr(title_), toqstr(startsWith), toqstr(filters.as_string()) ; + toqstr(title_), + toqstr(startsWith), + toqstr(filters.as_string()), + 0, + QFileDialog::DontConfirmOverwrite); + result.second = from_utf8(internal_path(fromqstr(name))); #else LyXFileDialog dlg(title_, path, filters, private_-b1, private_-b2); #if QT_VERSION != 0x040203
Re: [PATCH] Textclass cleanup
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Hi, here comes a new version of an old patch. I took into Michael account comments by Jürgen Uwe. Michael OK? Yes. JMarc
Re: [patch] KeyMap bug (again)
Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov Hi! I haven't gotten any responses to the patch I sent in Dov yesterday, so I took the opportunity to open a bug for this in Dov bugzilla (http://bugzilla.lyx.org/show_bug.cgi?id=3811). Dov There are explanations there regarding the patch (which is also Dov attached here). Please make sure it makes sense, and if so --- Dov could someone please commit? The patch looks good to me. One question: what about the other call to translateAndInsert (for the accent lfuns)? Shouldn't it get a switchKeymap too? Am I right that switchKeyMap assumes that the primary keymap is ltr and the secondary rtl? This is ugly. JMarc
Re: [PATCH] Bug 3818: Save and replace asks twice whether to overwrite (Re: Annoying Mac Bug....)
Am 06.06.2007 um 12:21 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: http://bugzilla.lyx.org/show_bug.cgi?id=3818 Stefan You make a patch? OK. It turns out to be easier to disable overwrite control for the native dialog. Could some osx user test this patch? JMarc bug3818.diff OK, looks good and works. One question: why is overwrite written over- write in the dialog? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Change tracking and replace: unexpected behavior
On Jun 6, 2007, at 4:38 AM, Helge Hafting wrote: Bennett Helm wrote: On Jun 5, 2007, at 9:52 AM, Jean-Marc Lasgouttes wrote: Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes: Jürgen Bennett Helm wrote: Create a document with multiple occurrences of foo. Turn change tracking on, select a chunk of text (including some occurrences of foo), and delete. Now go to the top and turn change tracking *off*. Using Edit Find Replace, Replace all instances of foo with bar. The instances of foo in the change-tracked deleted text have now been replaced with instances of bar, but they are no longer deleted. This is unexpected -- at least by me. Jürgen Here's a patch for replace all. As noted on bugzilla, I'm not Jürgen sure we should restrict manual replace. I think we should restrict manual replace too (if possible). It should not be allowed to do with replace something that would not be possible via normal editing. I agree with the last sentence, but notice that the patch doesn't do this! When change tracking is turned off, it is entirely possible to delete -- remove from the file -- text that is marked as deleted. Then you simply commit (parts of) that deletion, albeit without using the change tracking machinery. I see nothing very wrong with that. I don't either. Nonetheless, I think even manual replace ought to skip deleted text. It's not expected behavior even on manual replace to replace deleted text with undeleted text (as the patch currently allows). And I don't think we should replace deleted text with deleted text either: that obscures the document history which is part of the point of change tracking. If you turn off change tracking and edit, then surely all new stuff should be without the change tracking markings. (i.e. not deleted or marked as inserted by someone.) You may be able to add inside a deleted region, but that should split the deleted region in two. In general I see nothing wrong with this; my only complaint was that it is unexpected for this to happen during search and replace. A user wanting something different should turn the change tracking on and use it. Adding deleted text is a lot like lying about what happened. There are legitimate reasons for wanting to turn change tracking on and off, depending on what you're doing. I tend to turn it on only when I'm making a major revision to a particular part of a document, especially when I have doubts about whether the revision is an improvement; I then turn it off when making minor changes (like fixing typos or grammatical errors). If I change my mind about what word to use for describing something and want to do a global replace, I turn change tracking off since I don't want change tracking for this change cluttering up the screen (or the printed text if I choose to show changes). But then I don't want LyX to turn a deleted search term into an undeleted replace term; rather, I want deleted text ignored. The same goes with manual search and replace, in part for this reason and in part for the reason you give: adding deleted text would be like lying. Bennett
Re: Outline panel hidden at inappropriate times
On Jun 6, 2007, at 5:38 AM, Mael Hilléreau wrote: I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following situations, the outline panel is hidden whereas it should remain visible: 1. Open several documents (e.g. User's guide and Introduction), show the outline, and close one of the documents; This is a known problem, though I couldn't find a bug report for it. (Was I just not searching hard enough?) 2. Open one or more documents, show the outline, and execute a buffer-switch command (M-x, buffer-switch, enter) with or without the optional parameter. (Quicker way to switch documents with mac.bind: opttab.) I cannot confirm this: switching documents for me leaves the TOC drawer open. Bennett
Re: [PATCH] Bug 3818: Save and replace asks twice whether to overwrite (Re: Annoying Mac Bug....)
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Could some osx user test this patch? JMarc bug3818.diff Stefan OK, looks good and works. Jose, can I commit? Stefan One question: why is overwrite written over- write in the Stefan dialog? Good question. It looks like it is not plain English. I propose to make a separate patch for that, but before I do so, could some native English speaker chime in? JMarc
Re: Fixing #3790, 3801, 3809 in the only right way, no further patchworks!
On Wednesday 06 June 2007 10:17:42 Stefan Schimanski wrote: As suggested by Dov, the discussion about spaces around RTL/LTR will be continued in the other thread. I have also posted these two patches there because the following RTL advances are based on this. Stefan OK. -- José Abílio
Re: [PATCH] Bug 3818: Save and replace asks twice whether to overwrite (Re: Annoying Mac Bug....)
On Wednesday 06 June 2007 13:06:34 Jean-Marc Lasgouttes wrote: Stefan OK, looks good and works. Jose, can I commit? OK. -- José Abílio
Re: [PATCH] bug 3799: View=Toolbars=XXX produces confusing output in status line
On Wednesday 06 June 2007 10:43:10 Jean-Marc Lasgouttes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3799 I took a look at this bug and could not refrain from making some changes to the toolbar code in the process. This patch: - gets rid of toolbar-toggle-state lfun, and adds a parameter allowauto to toogle-toolbar instead. - adds useful status messages when toggling a toolbar. OK. -- José Abílio
Implement a function to collapse/expand Chapters
Hello I'm new to this list and hope i subscribed correctly to read the answers to my proposal. I'm a LyX user for one year now and think that LyX is the best way to write Documents with LaTeX/MikTeX. Beside all the good functions that LyX have, i miss one little function which can be really usefull at the daily working. I think you all know several Programming IDE's like VS, Sharpdevelop, Eclipse and so one. There you can expand or collapse function blocks by clicking on a small plus-minus-symbol left to the block. It is possible to implement such a function to expand or collapse chapters in the lyx-writing view? I hope i get answers that i can discuss this proposal with you. Bye, Thomas
Re: [PATCH] Bug 3818: Save and replace asks twice whether to overwrite (Re: Annoying Mac Bug....)
On Jun 6, 2007, at 8:06 AM, Jean-Marc Lasgouttes wrote: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Could some osx user test this patch? JMarc bug3818.diff Stefan OK, looks good and works. Jose, can I commit? Stefan One question: why is overwrite written over- write in the Stefan dialog? Good question. It looks like it is not plain English. I propose to make a separate patch for that, but before I do so, could some native English speaker chime in? You mean take over Angus' job? Overwrite is better. Bennett
Re: Outline panel hidden at inappropriate times
Le 6 juin 07 à 14:44, Bennett Helm a écrit : On Jun 6, 2007, at 8:31 AM, Mael Hilléreau wrote: Le 6 juin 07 à 13:58, Bennett Helm a écrit : On Jun 6, 2007, at 5:38 AM, Mael Hilléreau wrote: I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following situations, the outline panel is hidden whereas it should remain visible: 1. Open several documents (e.g. User's guide and Introduction), show the outline, and close one of the documents; This is a known problem, though I couldn't find a bug report for it. (Was I just not searching hard enough?) The closest bug I found is 3740. But that's a different bug, right? You're reporting that the TOC drawer is closing rather than remaining open but having the list collapse, right? Right. 2. Open one or more documents, show the outline, and execute a buffer-switch command (M-x, buffer-switch, enter) with or without the optional parameter. (Quicker way to switch documents with mac.bind: opttab.) I know that, but I encountered this problem because I use a shortcut bound to a command sequence... I cannot confirm this: switching documents for me leaves the TOC drawer open. Do you use the command buffer (M-x) and type the 'buffer-switch' command? I tried both and could not confirm with either. Do you use 1.5.0svn? Mael. PS: I didn't send my last mail to the list. Sorry about this; it is shown above...
Re: Outline panel hidden at inappropriate times
On Jun 6, 2007, at 8:57 AM, Mael Hilléreau wrote: 2. Open one or more documents, show the outline, and execute a buffer-switch command (M-x, buffer-switch, enter) with or without the optional parameter. (Quicker way to switch documents with mac.bind: opttab.) I know that, but I encountered this problem because I use a shortcut bound to a command sequence... I cannot confirm this: switching documents for me leaves the TOC drawer open. Do you use the command buffer (M-x) and type the 'buffer-switch' command? I tried both and could not confirm with either. Do you use 1.5.0svn? Yes. Bennett
Re: Outline panel hidden at inappropriate times
Le 6 juin 07 à 15:12, Bennett Helm a écrit : On Jun 6, 2007, at 8:57 AM, Mael Hilléreau wrote: 2. Open one or more documents, show the outline, and execute a buffer-switch command (M-x, buffer-switch, enter) with or without the optional parameter. (Quicker way to switch documents with mac.bind: opttab.) I know that, but I encountered this problem because I use a shortcut bound to a command sequence... I cannot confirm this: switching documents for me leaves the TOC drawer open. Do you use the command buffer (M-x) and type the 'buffer-switch' command? I tried both and could not confirm with either. Do you use 1.5.0svn? Yes. Ok, so this one is probably fixed on svn. Mael.
Re: Outline panel hidden at inappropriate times
On Jun 6, 2007, at 9:24 AM, Mael Hilléreau wrote: Le 6 juin 07 à 15:12, Bennett Helm a écrit : On Jun 6, 2007, at 8:57 AM, Mael Hilléreau wrote: 2. Open one or more documents, show the outline, and execute a buffer-switch command (M-x, buffer-switch, enter) with or without the optional parameter. (Quicker way to switch documents with mac.bind: opttab.) I know that, but I encountered this problem because I use a shortcut bound to a command sequence... I cannot confirm this: switching documents for me leaves the TOC drawer open. Do you use the command buffer (M-x) and type the 'buffer- switch' command? I tried both and could not confirm with either. Do you use 1.5.0svn? Yes. Ok, so this one is probably fixed on svn. But it's not a problem I've encountered previously, and I've checked that it's not a problem for 1.5.0-RC1. What version are you using? Bennett
Re: [PATCH] Bug 3818: Save and replace asks twice whether to overwrite (Re: Annoying Mac Bug....)
José == José Matos [EMAIL PROTECTED] writes: José On Wednesday 06 June 2007 13:06:34 Jean-Marc Lasgouttes wrote: Stefan OK, looks good and works. Jose, can I commit? José OK. Applied. JMarc
Re: Outline panel hidden at inappropriate times
Le 6 juin 07 à 15:40, Bennett Helm a écrit : On Jun 6, 2007, at 9:24 AM, Mael Hilléreau wrote: Le 6 juin 07 à 15:12, Bennett Helm a écrit : On Jun 6, 2007, at 8:57 AM, Mael Hilléreau wrote: 2. Open one or more documents, show the outline, and execute a buffer-switch command (M-x, buffer-switch, enter) with or without the optional parameter. (Quicker way to switch documents with mac.bind: opttab.) I know that, but I encountered this problem because I use a shortcut bound to a command sequence... I cannot confirm this: switching documents for me leaves the TOC drawer open. Do you use the command buffer (M-x) and type the 'buffer- switch' command? I tried both and could not confirm with either. Do you use 1.5.0svn? Yes. Ok, so this one is probably fixed on svn. But it's not a problem I've encountered previously, and I've checked that it's not a problem for 1.5.0-RC1. What version are you using? Precisely 1.5.0rc1 on Intel Mac OS X.4.9. Mael.
Re: Outline panel hidden at inappropriate times
Mael Hilléreau wrote: I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following situations, the outline panel is hidden whereas it should remain visible: 1. Open several documents (e.g. User's guide and Introduction), show the outline, and close one of the documents; This has been fixed in current svn, or should have been: http://www.lyx.org/trac/changeset/18651. This was bug 3701. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] bug 3799: View=Toolbars=XXX produces confusing output in status line
José == José Matos [EMAIL PROTECTED] writes: José On Wednesday 06 June 2007 10:43:10 Jean-Marc Lasgouttes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3799 I took a look at this bug and could not refrain from making some changes to the toolbar code in the process. This patch: - gets rid of toolbar-toggle-state lfun, and adds a parameter allowauto to toogle-toolbar instead. - adds useful status messages when toggling a toolbar. José OK. Applied. JMarc
Re: Implement a function to collapse/expand Chapters
Thomas Schmidt wrote: Hello I'm new to this list and hope i subscribed correctly to read the answers to my proposal. We shall see. I'm a LyX user for one year now and think that LyX is the best way to write Documents with LaTeX/MikTeX. Beside all the good functions that LyX have, i miss one little function which can be really usefull at the daily working. I think you all know several Programming IDE's like VS, Sharpdevelop, Eclipse and so one. There you can expand or collapse function blocks by clicking on a small plus-minus-symbol left to the block. It is possible to implement such a function to expand or collapse chapters in the lyx-writing view? Possible, sure. Then again, if you use the DocumentOutline, you may be able to accomplish a lot of what you would get from this kind of folding, so I'm not sure who, if anyone, will be inspired to do this, and it won't happen any time soon, as we're at feature freeze for 1.5.0. The best thing to do at this point is to file an enhancement bug at bugzilla.lyx.org. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] over-write=overwrite (was Re: [PATCH] Bug 3818: Save and replace asks twice whether to overwrite (Re: Annoying Mac Bug....))
Bennett == Bennett Helm [EMAIL PROTECTED] writes:
Good question. It looks like it is not plain English. I propose to
make a separate patch for that, but before I do so, could some
native English speaker chime in?
Bennett You mean take over Angus' job?
Exact :)
Bennett Overwrite is better.
So be it.
Jose'?
JMarc
Index: src/callback.cpp
===
--- src/callback.cpp (révision 18688)
+++ src/callback.cpp (copie de travail)
@@ -165,9 +165,9 @@ bool writeAs(Buffer * buffer, string con
if (fs::exists(filename.toFilesystemEncoding())) {
docstring const file = makeDisplayPath(fname, 30);
docstring text = bformat(_(The document %1$s already exists.\n\n
- Do you want to over-write that document?), file);
- int const ret = Alert::prompt(_(Over-write document?),
- text, 0, 1, _(Over-write), _(Cancel));
+ Do you want to overwrite that document?), file);
+ int const ret = Alert::prompt(_(Overwrite document?),
+ text, 0, 1, _(Overwrite), _(Cancel));
if (ret == 1)
return false;
Index: src/LyXFunc.cpp
===
--- src/LyXFunc.cpp (révision 18690)
+++ src/LyXFunc.cpp (copie de travail)
@@ -1073,10 +1073,10 @@ void LyXFunc::dispatch(FuncRequest const
if (fs::exists(filename.toFilesystemEncoding())) {
docstring text = bformat(
_(The file %1$s already exists.\n\n
- Do you want to over-write that file?),
+ Do you want to overwrite that file?),
makeDisplayPath(filename.absFilename()));
- if (Alert::prompt(_(Over-write file?),
- text, 0, 1, _(Over-write), _(Cancel)) != 0)
+ if (Alert::prompt(_(Overwrite file?),
+ text, 0, 1, _(Overwrite), _(Cancel)) != 0)
break;
}
command += lyxrc.print_to_file
@@ -2057,9 +2057,9 @@ void LyXFunc::doImport(string const ar
docstring const file = makeDisplayPath(lyxfile.absFilename(), 30);
docstring text = bformat(_(The document %1$s already exists.\n\n
- Do you want to over-write that document?), file);
- int const ret = Alert::prompt(_(Over-write document?),
- text, 0, 1, _(Over-write), _(Cancel));
+ Do you want to overwrite that document?), file);
+ int const ret = Alert::prompt(_(Overwrite document?),
+ text, 0, 1, _(Overwrite), _(Cancel));
if (ret == 1) {
lyx_view_-message(_(Canceled.));
Index: src/Exporter.cpp
===
--- src/Exporter.cpp (révision 18688)
+++ src/Exporter.cpp (copie de travail)
@@ -80,11 +80,11 @@ int checkOverwrite(FileName const file
{
if (fs::exists(filename.toFilesystemEncoding())) {
docstring text = bformat(_(The file %1$s already exists.\n\n
- Do you want to over-write that file?),
+ Do you want to overwrite that file?),
makeDisplayPath(filename.absFilename()));
- return Alert::prompt(_(Over-write file?),
+ return Alert::prompt(_(Overwrite file?),
text, 0, 2,
- _(Over-write), _(Over-write all),
+ _(Overwrite), _(Overwrite all),
_(Cancel export));
}
return 0;
Re: Outline panel hidden at inappropriate times
Le 6 juin 07 à 15:54, Richard Heck a écrit : Mael Hilléreau wrote: I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following situations, the outline panel is hidden whereas it should remain visible: 1. Open several documents (e.g. User's guide and Introduction), show the outline, and close one of the documents; This has been fixed in current svn, or should have been: http:// www.lyx.org/trac/changeset/18651. This was bug 3701. I tested, its ok for me. Sorry, I didn't see the bug. Mael.
Re: [PATCH] Hover over mathed show mathed corners.
I deem that this will be more acceptable than my previous patch. I was wrong so this is now http://bugzilla.lyx.org/show_bug.cgi?id=3825 . Cheers, Bo
dictionary
hello, i try to install lyx 1.5 but it' impossible to download aspell dictionary(english or italian). i tried to install them before or after lyx installation but they don't work Filippo
Re: Outline panel hidden at inappropriate times
Mael Hilléreau wrote: Le 6 juin 07 à 15:54, Richard Heck a écrit : Mael Hilléreau wrote: I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following situations, the outline panel is hidden whereas it should remain visible: 1. Open several documents (e.g. User's guide and Introduction), show the outline, and close one of the documents; This has been fixed in current svn, or should have been: http://www.lyx.org/trac/changeset/18651. This was bug 3701. I tested, its ok for me. Sorry, I didn't see the bug. No problem. There are a lot of them Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Bug 3823 -- bad color output for LyXNotes
The patch fixes the bug. OK to commit?
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: LaTeXFeatures.cpp
===
--- LaTeXFeatures.cpp (revision 18689)
+++ LaTeXFeatures.cpp (working copy)
@@ -491,8 +491,9 @@
// shadecolor for shaded
if (mustProvide(framed) mustProvide(color)) {
RGBColor c = RGBColor(lcolor.getX11Name(Color::shadedbg));
+ //255.0 to force conversion to double
packages \\definecolor{shadecolor}{rgb}{
- c.r/255 ',' c.g/255 ',' c.b/255 }\n;
+ c.r/255.0 ',' c.g/255.0 ',' c.b/255.0 }\n;
}
// lyxskak.sty --- newer chess support based on skak.sty
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Richard == Richard Heck [EMAIL PROTECTED] writes: Richard The patch fixes the bug. OK to commit? It would be nice to round the values to 2 decimal places. JMarc
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Jean-Marc Lasgouttes wrote: The navigation menu is regenerated just before displaying it. At least this is what it used to do, without much overhead. Well, it doesn't do this now. Open the Embedded Objects manual; go to some figure, and delete some characters from the caption. (Do not highlight and delete. That regenerates. Just delete.) Exit the caption (again, you have to be careful how you do this, as some actions regenerate) and open NavigateList of Figures. Not updated. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Jean-Marc Lasgouttes wrote: Richard == Richard Heck [EMAIL PROTECTED] writes: Richard The patch fixes the bug. OK to commit? It would be nice to round the values to 2 decimal places. Can you tell me off-hand how to do that here? rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Richard == Richard Heck [EMAIL PROTECTED] writes: Richard Jean-Marc Lasgouttes wrote: Richard == Richard Heck [EMAIL PROTECTED] writes: Richard The patch fixes the bug. OK to commit? It would be nice to round the values to 2 decimal places. Richard Can you tell me off-hand how to do that here? I would try os setprecision(2) ... but then there might be a need to reset the precision later. JMarc
[PATCH] Bug 3821: Odd middle-click behavior
The issue here is that middle-click of external material pastes where
the cursor WAS, not where one clicks. This works, but I don't know if
it's best. I can't seem to figure out where the cursor position is set
in the other branch: You don't get this behavior with pastes of internal
selections.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: Text3.cpp
===
--- Text3.cpp (revision 18689)
+++ Text3.cpp (working copy)
@@ -1047,8 +1047,10 @@
bv-switchKeyMap();
bv-buffer()-markDirty();
finishUndo();
- } else
+ } else {
+bv-mouseSetCursor(cur); //bug 3821
lyx::dispatch(FuncRequest(LFUN_PRIMARY_SELECTION_PASTE, paragraph));
+ }
}
// we have to update after dePM triggered
Re: dictionary
i try to install lyx 1.5 but it' impossible to download aspell dictionary(english or italian). i tried to install them before or after lyx installation but they don't work if you are on win arch maybe this can help you http://www.mail-archive.com/[EMAIL PROTECTED]/msg56072.html pavel
[PATCH-updateded] Bug 3823
An improved version, per JMarc's suggestions. This one OK?
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: LaTeXFeatures.cpp
===
--- LaTeXFeatures.cpp (revision 18689)
+++ LaTeXFeatures.cpp (working copy)
@@ -491,8 +491,11 @@
// shadecolor for shaded
if (mustProvide(framed) mustProvide(color)) {
RGBColor c = RGBColor(lcolor.getX11Name(Color::shadedbg));
+ //255.0 to force conversion to double
+ int const stmSize = packages.precision(2);
packages \\definecolor{shadecolor}{rgb}{
- c.r/255 ',' c.g/255 ',' c.b/255 }\n;
+ c.r/255.0 ',' c.g/255.0 ',' c.b/255.0 }\n;
+ packages.precision(stmSize);
}
// lyxskak.sty --- newer chess support based on skak.sty
[PATCH] Add \varrho and its icon to toolbar
LyX supports \varrho, but there is no this symbol on the toolbar. I made a patch to add this one. Please see attached. varrho.diff Description: Binary data
Re: [PATCH-updateded] Bug 3823
Richard == Richard Heck [EMAIL PROTECTED] writes: Richard An improved version, per JMarc's suggestions. This one OK? Yes (you tried it, right?) JMarc
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Well, it doesn't do this now. Open the Embedded Objects manual; go to some figure, and delete some characters from the caption. (Do not highlight and delete. That regenerates. Just delete.) Exit the caption (again, you have to be careful how you do this, as some actions regenerate) and open NavigateList of Figures. Not updated. I noticed this as well and this is pretty annoying. Maybe I will track it down later. Bo
import Chinese TeX file issue
I suppose you use a class file different than those default lyx-supported classes, such as ctexartutf8.cls. In this case, you must install the layout file before you can convert a .tex file to lyx. Only putting the layout file in the dir of the .tex file does not work. In addition, the layout file must be named as the same name of the class you use in your .tex file. Hangzai
Re: [PATCH] over-write=overwrite (was Re: [PATCH] Bug 3818: Save and replace asks twice whether to overwrite (Re: Annoying Mac Bug....))
On Wednesday 06 June 2007 15:01:57 Jean-Marc Lasgouttes wrote: Jose'? JMarc OK. -- José Abílio
Re: [PATCH-updateded] Bug 3823
On Wednesday 06 June 2007 17:02:01 Richard Heck wrote: An improved version, per JMarc's suggestions. This one OK? rh OK. -- José Abílio
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Richard Heck wrote:
c.r/255.0 ',' c.g/255.0 ',' c.b/255.0
An alternative would be to require xcolor instead of color (we require this
anyway nowadays) and use \definecolor{shadecolor}{RGB}{}. Then you don't
have to do any calculation.
Jürgen
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Juergen Spitzmueller wrote:
Richard Heck wrote:
c.r/255.0 ',' c.g/255.0 ',' c.b/255.0
An alternative would be to require xcolor instead of color (we require this
anyway nowadays) and use \definecolor{shadecolor}{RGB}{}. Then you don't
have to do any calculation.
I don't really know anything about LaTeX color handling, so I'm happy to
have you (and others who do) make this call. I guess the only other
thing that would need changing is the InsetNote::validate() routine.
By the way, is it intentional that the default menu doesn't provide for
shaded and framed notes? but only for the other three types? It took me
a while to figure out how even to insert these shaded things.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Richard Heck wrote: I don't really know anything about LaTeX color handling, so I'm happy to have you (and others who do) make this call. I guess the only other thing that would need changing is the InsetNote::validate() routine. Yes, just requiring xcolor should do. By the way, is it intentional that the default menu doesn't provide for shaded and framed notes? but only for the other three types? I don't think so. It took me a while to figure out how even to insert these shaded things. Actually, I wasn't aware of them either. Jürgen
Re: How to make Lyx DRAMATICALLY better.
On Wed, Jun 06, 2007 at 09:24:48AM +0200, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Tue, Jun 05, 2007 at 10:07:40PM +0100, José Matos wrote: On Tuesday 05 June 2007 19:16:08 Andre Poenitz wrote: Right. Commit 17913 added int InsetBase::background_color_ to InsetBase that used to be 16 bytes a while ago. Andre' Cann't that be a class method instead of an instance method? (In C++ parlance mode a static class method/data I think). Andre Not really, as this assumes that all inset backgrounds are Andre equal. Andre Buts it would be sufficient if only insets that _do_ have a Andre variable background would have that member. Why don't we just use a virtual mathod? I don't know. This is obviously a sensible solution. Is it really necessary to customize each inset's color. I don't think so. Andre'
Re: Annoying Mac Bug....
On Wed, Jun 06, 2007 at 09:54:37AM +0200, Stefan Schimanski wrote: Am 06.06.2007 um 09:49 schrieb Jean-Marc Lasgouttes: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan Well, at the moment confirmOverwrite is set to false for the Stefan non- native dialog. You might question this decision and set Stefan it to true, and change the asksForOverwriteConfirmation then Stefan accordingly. But that's not matter of my patch. It's only Stefan about the static getSaveFileName (was it called like that, Stefan don't have the code here...) method used for the native Stefan dialog. One can pass the following options to getSaveFileName: QFileDialog::DontConfirmOverwrite Don't ask for confirmation if an existing file is selected. By default confirmation is requested. Was looking into the docs for that, but didn't see it :) So (1) your patch was correct :) (2) we could force confirmation in the non-native case too and simplify our code. And force any frontend (even if we have only one currently) to do that overwrite dialog? Yes. Dialogs are a pure frontend matter, and so is to a certain degree logic related to dialogs. Andre'
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Juergen Spitzmueller wrote:
Richard Heck wrote:
c.r/255.0 ',' c.g/255.0 ',' c.b/255.0
An alternative would be to require xcolor instead of color (we require this
anyway nowadays) and use \definecolor{shadecolor}{RGB}{}. Then you don't
have to do any calculation.
\providecolor{LyXshadecolor}{RGB}{...}to be save
Herbert
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Herbert Voss wrote:
Juergen Spitzmueller wrote:
Richard Heck wrote:
c.r/255.0 ',' c.g/255.0 ',' c.b/255.0
An alternative would be to require xcolor instead of color (we require this
anyway nowadays) and use \definecolor{shadecolor}{RGB}{}. Then you don't
have to do any calculation.
\providecolor{LyXshadecolor}{RGB}{...}to be save
ah just saw, that you need it for package framed, then
shadecolor is correct ...
Herbert
Re: Bugzilla Bookmarklet
Richard Heck schrieb:
[EMAIL PROTECTED] wrote:
On Tue, 5 Jun 2007, Bernhard Roider wrote:
Richard Heck schrieb:
I finally got around to writing this:
javascript:(function(){var x; x=prompt(Enter bug number:, );
if(x!=null){document.location.href=http://bugzilla.lyx.org/show_bug.cgi?id=;
+ x; }} )();
I'll put it on the wiki at some point.
what about this:
javascript:(function(){var x = %s; if (x==%+s) x=prompt(Enter
bug number:, );
if(x!=null){document.location.href=http://bugzilla.lyx.org/show_bug.cgi?id=;
+ x; }} )();
assigning a shortcut, say lb, to the bookmarklet you can either type
lb bug# return
and get no prompt or
lb return
and are prompted for the bug#
If you want, I can add a prompt on the wiki's development pages that
accepts a bug number and jumps you to that bug.
/Christian (who didn't understand what the bookmarklet thing is)
PS. In Opera, I'd just define a dedicated search for it, so that
entering e.g.
b 232
will get you to bug 232.
In Firefox, you can create a bookmark and put the above as the URL. Then
choosing the bookmark will pop up a dialog asking for the bug number and
send you there.
I didn't really understand the shortcut bit. How do we do that?
In the properties of the Bookmark the keyword is the shortcut. enter the shortcut in the address
field an press return - ping!
You mean this?
Bernhard
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Herbert Voss wrote:
\providecolor{LyXshadecolor}{RGB}{...} to be save
BTW, Herbert, which definition is to be preferred to fix bug 3817:
http://bugzilla.lyx.org/show_bug.cgi?id=3817
\newcommand{\lyxadded}[3]{{\color{lyxadded}#3}}
\newcommand{\lyxdeleted}[3]{{\color{lyxdeleted}\st{#3}}}
or
\newcommand{\lyxadded}[3]{\bgroup\color{lyxadded}#3\egroup}
\newcommand{\lyxdeleted}[3]{\bgroup\color{lyxdeleted}\st{#3}\egroup}
Jürgen
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Juergen Spitzmueller wrote: Richard Heck wrote: I don't really know anything about LaTeX color handling, so I'm happy to have you (and others who do) make this call. I guess the only other thing that would need changing is the InsetNote::validate() routine. Yes, just requiring xcolor should do. Well, for the time being, I'm just going to commit what I had, with a comment to the effect that there is another way to do it. I'm not sure there's enough time to test a more extensive change right now and, as I said, I never use color. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Bo Peng wrote: Well, it doesn't do this now. Open the Embedded Objects manual; go to some figure, and delete some characters from the caption. (Do not highlight and delete. That regenerates. Just delete.) Exit the caption (again, you have to be careful how you do this, as some actions regenerate) and open NavigateList of Figures. Not updated. I noticed this as well and this is pretty annoying. Maybe I will track it down later. Anything that fixed the TOC behavior would also fix this. But it would be possible to separate these and have the TOC update only by explicit request (say) whereas the menu updated when it was shown. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Add Framed and Shaded to Notes Menu
As said. Neither Jurgen nor I knew these existed. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto Index: stdmenus.inc === --- stdmenus.inc (revision 18689) +++ stdmenus.inc (working copy) @@ -394,7 +394,9 @@ Menu insert_note Item LyX Note|N note-insert Note Item Comment|C note-insert Comment + Item Framed Note|F note-insert Framed Item Greyed Out|G note-insert Greyedout + Item Shaded Note|S note-insert Shaded End Menu insert_branches
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Anything that fixed the TOC behavior would also fix this. But it would be possible to separate these and have the TOC update only by explicit request (say) whereas the menu updated when it was shown. When I insert 'update toc' message to 'TocBackend::update()', I find that it is called whenever section title is updated, but not when, for example, a caption of InsetListings is modified. I am *not* going to call update each time when some caption is updated, because there are too many such cases, and it is *not* necessary to update Toc, which is by my standard an expansive option, each time. Because Outline panel already has a 'update' button, I guess for this purpose, I will simply call update when navigation menu is clicked. Bo
Re: [PATCH] Add Framed and Shaded to Notes Menu
On Wed, Jun 06, 2007 at 03:43:55PM -0400, Richard Heck wrote: As said. Neither Jurgen nor I knew these existed. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto Index: stdmenus.inc === --- stdmenus.inc (revision 18689) +++ stdmenus.inc (working copy) @@ -394,7 +394,9 @@ Menu insert_note Item LyX Note|N note-insert Note Item Comment|C note-insert Comment + Item Framed Note|F note-insert Framed Item Greyed Out|G note-insert Greyedout + Item Shaded Note|S note-insert Shaded End Menu insert_branches I came up simultaneously with the attached... why the different order? Seems the new items were added to stdmenus.ui (defunct, but still in my local tree), not stdmenus.inc ;-/ - Martin Index: stdmenus.inc === --- stdmenus.inc(revision 18579) +++ stdmenus.inc(working copy) @@ -395,6 +395,8 @@ Item LyX Note|N note-insert Note Item Comment|C note-insert Comment Item Greyed Out|G note-insert Greyedout + Item Framed|F note-insert Framed + Item Shaded|S note-insert Shaded End Menu insert_branches
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
On Wed, Jun 06, 2007 at 08:53:36PM +0200, Juergen Spitzmueller wrote:
Herbert Voss wrote:
\providecolor{LyXshadecolor}{RGB}{...} to be save
BTW, Herbert, which definition is to be preferred to fix bug 3817:
http://bugzilla.lyx.org/show_bug.cgi?id=3817
\newcommand{\lyxadded}[3]{{\color{lyxadded}#3}}
\newcommand{\lyxdeleted}[3]{{\color{lyxdeleted}\st{#3}}}
or
\newcommand{\lyxadded}[3]{\bgroup\color{lyxadded}#3\egroup}
\newcommand{\lyxdeleted}[3]{\bgroup\color{lyxdeleted}\st{#3}\egroup}
I'm not Herbert, but I think I am able to answer this ;-)
Both forms are equivalent, indeed \bgroup and \egroup are defined
as \let\bgroup={ \let\egroup=} by TeX. The macro forms are useful
because you can include them in a definition without worrying
about how they nest. I mean that you can do something like:
\def\beginlarge{\bgroup\large}
\def\endlarge{\egroup}
after which you can use
xxx \beginlarge yyy \endlarge zzz
to typeset yyy in large size.
--
Enrico
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
Enrico Forestieri wrote:
Both forms are equivalent, indeed \bgroup and \egroup are defined
as \let\bgroup={ \let\egroup=} by TeX. The macro forms are useful
because you can include them in a definition without worrying
about how they nest.
I see. Many thanks for the explanation.
(time to learn some TeX primitives ...)
Jürgen
Re: [PATCH] Add Framed and Shaded to Notes Menu
Martin Vermeer wrote: On Wed, Jun 06, 2007 at 03:43:55PM -0400, Richard Heck wrote: As said. Neither Jurgen nor I knew these existed. I came up simultaneously with the attached... why the different order? I thought I'd alphabetize the ones after LyX Note. It doesn't much matter, though. Feel free to commit whichever one you like. rh Seems the new items were added to stdmenus.ui (defunct, but still in my local tree), not stdmenus.inc ;-/ - Martin Index: stdmenus.inc === --- stdmenus.inc(revision 18579) +++ stdmenus.inc(working copy) @@ -395,6 +395,8 @@ Item LyX Note|N note-insert Note Item Comment|C note-insert Comment Item Greyed Out|G note-insert Greyedout + Item Framed|F note-insert Framed + Item Shaded|S note-insert Shaded End Menu insert_branches -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Update Toc when navigation menu is clicked.
As discussed in another thread, it is not a good idea to update Toc
whenever, e.g., the caption of an InsetListings is changed. This is
because
1. TocBackend::update() is expensive by my standard
2. Too many things will break Toc (such as removal of an inset).
3. Toc does not need to be updated all the time.
The outline panel has its own update button, the only remaining case
is the navigation menu. The following patch does exactly this:
Index: src/MenuBackend.cpp
===
--- src/MenuBackend.cpp (revision 18692)
+++ src/MenuBackend.cpp (working copy)
@@ -704,6 +704,7 @@
FuncRequest(LFUN_NOACTION)));
return;
}
+ const_castBuffer*(buf)-tocBackend().update();
// Add an entry for the master doc if this is a child doc
Buffer const * const master = buf-getMasterBuffer();
OK to apply? (The attached patch also show caption, not filename for
InsetInclude, a minor correction of the Toc behavior).
Cheers,
Bo
Index: src/insets/InsetInclude.cpp
===
--- src/insets/InsetInclude.cpp (revision 18692)
+++ src/insets/InsetInclude.cpp (working copy)
@@ -889,7 +889,7 @@
if (!caption.empty()) {
Toc toc = toclist[listing];
docstring const str = convertdocstring(toc.size() + 1)
-+ . + params_[filename];
++ . + from_utf8(caption);
// This inset does not have a valid ParConstIterator
// so it has to use the iterator of its parent paragraph
toc.push_back(TocItem(pit, 0, str));
Index: src/insets/InsetListingsParams.cpp
===
--- src/insets/InsetListingsParams.cpp (revision 18692)
+++ src/insets/InsetListingsParams.cpp (working copy)
@@ -830,7 +830,12 @@
{
// is this parameter defined?
mapstring, string::const_iterator it = params_.find(param);
- return (it == params_.end()) ? string() : it-second;
+ string par = (it == params_.end()) ? string() : it-second;
+ if (prefixIs(par, {) suffixIs(par, }))
+ return par.substr(1, par.size() - 2);
+ else
+ return par;
+
}
Index: src/MenuBackend.cpp
===
--- src/MenuBackend.cpp (revision 18692)
+++ src/MenuBackend.cpp (working copy)
@@ -704,6 +704,7 @@
FuncRequest(LFUN_NOACTION)));
return;
}
+ const_castBuffer*(buf)-tocBackend().update();
// Add an entry for the master doc if this is a child doc
Buffer const * const master = buf-getMasterBuffer();
Re: [PATCH] Add Framed and Shaded to Notes Menu
On Wednesday 06 June 2007 21:26:22 Richard Heck wrote: I thought I'd alphabetize the ones after LyX Note. It doesn't much matter, though. Feel free to commit whichever one you like. +1 Please, could one of you toss a coin and submit that option? ;-) rh -- José Abílio
Re: [PATCH] Update Toc when navigation menu is clicked.
On Wednesday 06 June 2007 21:49:56 Bo Peng wrote: OK to apply? (The attached patch also show caption, not filename for InsetInclude, a minor correction of the Toc behavior). Cheers, Bo OK OK. :-) -- José Abílio
Re: [PATCH] Update Toc when navigation menu is clicked.
On 6/6/07, José Matos [EMAIL PROTECTED] wrote: On Wednesday 06 June 2007 21:49:56 Bo Peng wrote: OK to apply? (The attached patch also show caption, not filename for InsetInclude, a minor correction of the Toc behavior). Cheers, Bo OK OK. :-) Done. Bo
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
The way to solve this might be to put some appropriate code into InsetCaption::notifyCursorLeaves(). I do not think it is a good idea to update Toc during editing, because simple add/remove of sections, change of environment will break Toc, so it is close to impossible to consider all cases and update Toc. Because TocBackend::update() is expansive, I even think we should remove all such calls triggered by, e.g., changing the environment of a paragraph to section. Instead, we can think of a good way to update Toc when the outline panel is *used*. (The case when the navigation menu is *used* is solved by r18693.) Cheers, Bo
Re: Spaces on RTL boundaries
Stefan Schimanski wrote: Continuing the discussion about the space issue here. I have implemented Georg's idea/hint to allow spaces on both sides of the RTL/LTR boundary, but let the empty-paragraph-mechanism (EPM, the algorithm which among other things kills double spaces) take care of double spaces around boundaries. Of course this needs the vis2log/log2vis functions from the bidi object to get the logical position of the character visually next to a space. I tried to make the usage as safe as possible, i.e. ask for the range of the bidi cache and so on. You will find the patches attached, to be applied in this order: no_bidi_isboundary.patch no_bidi_setcurrentfont.patch cursor_get_font.patch rtl_spaces.patch @Dov: quilt is nice, thanks again for the hint Yeah, isn't it? :) The patch of interest here is the last one, inlined below. The basic idea is that the EPM considers the spaces in abc [ WERBEH]ghi to be next to each other. So starting with abc[ WERBEH]ghi you can enter space behind the abc and continue writing, or change your mind after the space and the EPM takes away the new space: abc|[ WERBEH]ghi = abc |[ WERBEH]ghi = abc|[ WERBEH]ghi Similary for abc [|WERBEH]ghi. Opinions? Stefan Stefan, I like it! I haven't gone over the code at all yet, I hope to be able to do that over the weekend, maybe. But in terms of the behavior --- I like it a lot. And it solves all of the related crashes that I know of. And I think that it's the right approach in terms of not using any magic (except while typing in, if you can all the EPM magic...). I didn't think I would like the EPM business, but now that I see what you mean, I think it's a good idea! There are still some minor issues to work out, though: 1) type 'abc' F12 space 'def' F12 space 'ghi' You get this (visually): abc[FED ] ghi Shouldn't the EPM have gotten rid of one of the spaces between 'D' and 'g'? 2) This one I'm not able to reproduce reliably: sometimes I'm losing a space which should *not* be lost: after playing around on a boundary, trying to insert spaces and watching them magically disappear, I sometimes lose also the last space that was there. Again, I don't have a recipe for reproducing this yet, so I may be wrong, but I suggest trying to play around there. Or maybe a solution to the above issue will solve this, too. I'll try to go over the code in the next few days, and it would be great if other bidi users could test this and see what they have to say about it. But as far as I'm concerned, this is OK to go in (preferably with a fix for the above issues; but even without them, I think it's better than the current situation), so that we can get as much testing as possible before the final release. Thanks again, Stefan!
Re: Fixing #3790, 3801, 3809 in the only right way, no further patchworks!
Stefan Schimanski wrote: The updated patches, to be applied in this order: no_bidi_isboundary.patch no_bidi_setcurrentfont.patch As suggested by Dov, the discussion about spaces around RTL/LTR will be continued in the other thread. I have also posted these two patches there because the following RTL advances are based on this. Stefan These both have my OK. I haven't done any extensive testing of this, so I imagine there may still be some issues to be worked out, or at least some minor tweaks we may want to make --- but I think that the sooner these go in, the more testing they'll get before the final release... Dov
Re: [patch] KeyMap bug (again)
Jean-Marc Lasgouttes wrote: Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov Hi! I haven't gotten any responses to the patch I sent in Dov yesterday, so I took the opportunity to open a bug for this in Dov bugzilla (http://bugzilla.lyx.org/show_bug.cgi?id=3811). Dov There are explanations there regarding the patch (which is also Dov attached here). Please make sure it makes sense, and if so --- Dov could someone please commit? The patch looks good to me. One question: what about the other call to translateAndInsert (for the accent lfuns)? Shouldn't it get a switchKeymap too? I imagine it should, too. Is the keymap really actually used for the accents? How does one insert an accent? Perhaps the accent lfuns should actually call (dispatch?) the SELF_INSERT lfun, instead of inserting the accent character themselves? I don't use accents, so I really don't know about this... Am I right that switchKeyMap assumes that the primary keymap is ltr and the secondary rtl? This is ugly. It looks like it (but I'm sure you know this code at least as well as I do, I only just looked at it for the first time when trying to solve this issue, and I didn't look too deeply then, either)... and yes, it's not great. It would be nice (especially for when we'll want to get Hebrew + English + Arabic working, for example) to be able to have many keymaps. But this is really a separate issue from the current one, and shouldn't hold this up for now... JMarc
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Hi, If you need help testing the RTL support I'm willing to help as much as I can. I write most of my files in Hebrew and therefore I use RTL a lot. I may need a bit of guiding on how to compile the patches... (I don't have much experience in using patches). Sincerely, Ran Rutenberg Hi Ran (and any other would-be Bidi testers), Please try out the patches from http://permalink.gmane.org/gmane.editors.lyx.devel/86921 and let us know (preferably in a reply to that thread, but I reply to here is also fine) how you feel about the proposed behavior. Working with patches is as follows (this is for linux, I don't know how it's done on other platforms): given a source tree in ~/lyx-devel/ (you should usually svn update before applying the patches), and a patch file x.patch, you apply the patch like this: cd ~/lyx-devel patch -p1 x.patch where the -p1 says that one level of the directory hierarchy in the patch file should be stripped in order to match with the current location: if you look at one of the above patches, you'll see that there are separate sections for each file, with a header that looks like this: Index: lyx-devel/src/Bidi.cpp === --- lyx-devel.orig/src/Bidi.cpp2007-06-06 10:16:43.0 +0200 +++ lyx-devel/src/Bidi.cpp2007-06-06 10:38:19.0 +0200 since the path in the patch starts at lyx-devel/, and since you're already there, you want the first level to be stripped from the name, and from the current directory the file to patch should be found using only src/Bidi.cpp, without the leading lyx-devel (because you're already in it). Note that this would also work if your tree is called xyz rather than lyx-devel --- that's part of the beauty of path-stripping. So you can just apply the patches one after the other (but the order is important). To unapply a patch, just add the -R (reverse) flag. Of course, when unapplying, the opposite order should be used, i.e., the last patch applied should be removed first. Finally, note that if for any reason your tree is different from the tree on which the patch was created (because you have local modifications, or just because the tree itself has been updated since the patch was created), the patch may not apply cleanly. In this case, the output will say something like failed to apply Hunk #3, and a reject file is created which tells you what was not applied. This is the slightly more complicated part if you're new to patches, but hopefully for now you won't have to deal with it... Hope this helps! Dov
Re: [PATCH] 3810 --add check for evince
I was sitting there, in bewilderment, because my overview of all the pages on the left was missing! I tried, oh how I tried. Couldn't be anything I did since five minutes ago, could it? Hmm. Wasn't using evince before! I had the same experience! My beamer slide suddenly does not display in full screen and is cramped to a corner. It took me quite a while to realize that kpdf is called instead of acroread. What is the motivation for this order change? Bo
