Collapsable CharStyles [Beyond 1.5]
I've uploaded a patch to bugzilla
http://bugzilla.lyx.org/show_bug.cgi?id=3309#c3
that adds collapsible character styles, so you can do this:
CharStyle Endnote
InsetType Collapsable
LatexType Command
LatexName endnote
Preamble
\usepackage{endnotes}
EndPreamble
End
and suddenly have your very own endnote inset. Comments welcome.
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] remove linuxdoc from all doc files
Richard Heck wrote:
I've done this: patch attached. That said, just removing the option from
the dialog won't do anything one way or another about old files in which
it exists. Those files will still be loaded with that option, and it
won't be handled properly.
Maybe that's OK for now, but I'd have thought we should eliminate it
altogether, if we're removing it from the dialog. If so, this is a
format change, and appropriate lyx2lyx will presumably be needed (maybe
just to convert htmlurl insets into url insets). I haven't gone into
lyx2lyx, so someone else would need to do that. To eliminate this, we'd
need changes everywhere htmlurl is mentioned:
factory.cpp:430: || cmdName == htmlurl) {
insets/Inset.cpp:64: InsetName(htmlurl, Inset::HTMLURL_CODE),
insets/InsetCommandParams.cpp:166: if (name == htmlurl || name ==
url) {
Text3.cpp:1166: InsetCommandParams p(htmlurl);
But those changes are pretty obvious. It's the lyx2lyx stuff that I
don't understand.
Richard
The lyx2lyx change would probably be very trivial, something like (untested):
def convert_htmlurl(document):
\begin_inset LatexCommand htmlurl - \begin_inset LatexCommand url
for i in range(len(document.body)):
document.body[i] = document.body[i].replace(\\begin_inset LatexCommand
htmlurl,
\\begin_inset LatexCommand
url)
reversion would not be needed.
However, I'm not sure we should do all these changes now.
What happens with old LinuxDoc documents BTW?
Jürgen
Re: Text Settings Dialog [Beyond 1.5]
Richard Heck wrote: There are several large issues with this dialog collected in bug 3893. It really doesn't work very well. Here is a radical suggestion: Get rid of it in favor of character styles. So we'd have character styles like Italic, SmallCaps, and the like, accessed via the EditText Styles menu, rather than through a dialog. These could all be defined in a StdCharStyles.inc file to be included in other layouts. Yes. I also have some plans for this. There are some issues with this. At present, nesting character styles can lead to some ugly display, because the lines under the text nest and create quite a mess. I'd suggest making these optional, via a Layout setting. The attached patch gives some idea how this might work. It can be tried with these character styles: CharStyle Italic LatexType Command LatexName textit ShowBox false Font Shape Italic EndFont End One thing that needs to be done, btw, is make Font Shape Italic EndFont actually output italic font (in LaTeX) without further preamble ado. I have a patch for this, but it probably needs a format change, since we have to introduce GuiFont tags for those who want to set the font in LyX only. CharStyle SmallCaps LatexType Command LatexName textsc ShowBox false Font Shape SmallCaps EndFont End But there are still some issues here with the behavior of the cursor, as it seems to expect a border between the inset and the surrounding text, which has been removed. Another issue is that the EditText Style menu could become very crowded. It'd be nice to be able to define character styles and put them into submenus, perhaps via a setting that was something like: Submenu Shape Which would create and populate submenus. I'd prefer to have a combox (analogous to the paragraph style combox) in the toolbar instead of the menus. Jürgen Richard
Re: Collapsable CharStyles [Beyond 1.5]
Richard Heck wrote: Comments welcome. Could you please wait until 1.5.0 is done? Jürgen
Re: lyx2lyx for patch 1820
Enrico Forestieri wrote: On Wed, Jul 18, 2007 at 03:21:52AM +0300, Dov Feldstern wrote: Hi! Attached find a lyx2lyx for patch 1820. It's not perfect, though --- it actually corrupts some files which shouldn't be changed at all; if anyone wants to try and fix that, be my guest, I've just spent the past six hours on this and I'm not sure that it's doable. Also, this has only convinced me even more that it's wrong to apply a lyx2lyx fix for this patch: this is a bug fix, there were previously .lyx files which were ok, but which lyx was generating incorrect latex for, and patch 1820 fixes that. If there are lyx documents out there which patch 1820 affects, it can only do them good. All this lyx2lyx patch does is to explicitly set the language to the wrong values in all kinds of situations. FWIW, I agree with you. LyX was generating wrong LaTeX code in those cases and this should be considered as bug fix. IMO, it is laughable requiring a lyx2lyx patch in order to perpetuate the bug. Agreed. Abdel.
Re: Collapsable CharStyles [Beyond 1.5]
Jürgen Spitzmüller wrote: Richard Heck wrote: Comments welcome. Could you please wait until 1.5.0 is done? Sorry, didn't mean to distract you. It just seems as if most of us are waiting for 1.5.0 to be done---there are a few things left, not unimportant things, but not much for most of us to do 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: Patches for 1820 and 3613
Jürgen Spitzmüller wrote: Dov Feldstern wrote: So far, though, these two patches have mostly been ignored --- a few people have responded, but not many. You're not ignored. I agree that these patches should be considered, but I don't understand the stuff enough to comment (and I'm too busy for testing). Same for me, sorry Dov. I think you should be patient and wait until José, who is the one who decides and also probably the one who understands the changes, finds time to look at it. Please accept that he is also quite busy with the lyx2lyx bugs currently. While I agree with you, I also agree with Dov that we should branch 1.5 now... Abdel.
Re: Collapsable CharStyles [Beyond 1.5]
Richard Heck wrote: Sorry, didn't mean to distract you. It just seems as if most of us are waiting for 1.5.0 to be done---there are a few things left, not unimportant things, but not much for most of us to do On the contrary, this is attracting me, and I try to be resistant ;-) Jürgen
Re: Text Settings Dialog [Beyond 1.5]
Richard Heck wrote: Another issue is that the EditText Style menu could become very crowded. I can imagine a menu containing the last 10 styles used only. The last menu item would launch a dialog with a list view (or a tree view) or all available menu. It'd be nice to be able to define character styles and put them into submenus, perhaps via a setting that was something like: Submenu Shape Which would create and populate submenus. Indeed. Richard, you can play with my mvc branch if you want to test out these ideas. Abdel.
Re: Patches for 1820 and 3613
Abdelrazak Younes wrote: While I agree with you, I also agree with Dov that we should branch 1.5 now... I'm not opposed to that, but it's up to José. Jürgen
Re: [patch] remove linuxdoc from all doc files
Jürgen Spitzmüller wrote:
Richard Heck wrote:
I've done this: patch attached. That said, just removing the option from
the dialog won't do anything one way or another about old files in which
it exists. Those files will still be loaded with that option, and it
won't be handled properly.
Maybe that's OK for now, but I'd have thought we should eliminate it
altogether, if we're removing it from the dialog. If so, this is a
format change, and appropriate lyx2lyx will presumably be needed (maybe
just to convert htmlurl insets into url insets). I haven't gone into
lyx2lyx, so someone else would need to do that. To eliminate this, we'd
need changes everywhere htmlurl is mentioned:
factory.cpp:430: || cmdName == htmlurl) {
insets/Inset.cpp:64:InsetName(htmlurl, Inset::HTMLURL_CODE),
insets/InsetCommandParams.cpp:166: if (name == htmlurl || name ==
url) {
Text3.cpp:1166: InsetCommandParams p(htmlurl);
But those changes are pretty obvious. It's the lyx2lyx stuff that I
don't understand.
Richard
The lyx2lyx change would probably be very trivial, something like (untested):
def convert_htmlurl(document):
\begin_inset LatexCommand htmlurl - \begin_inset LatexCommand url
for i in range(len(document.body)):
document.body[i] = document.body[i].replace(\\begin_inset LatexCommand
htmlurl,
\\begin_inset LatexCommand
url)
reversion would not be needed.
However, I'm not sure we should do all these changes now.
It may not be critical to do this now. But
What happens with old LinuxDoc documents BTW?
Presumably, if you load one of these, it'll load fine, but if you opened
one of the URL insets and did something to it, it'd be changed from
htmlurl to url behind your back. Again, maybe not a huge problem, since
that's what the lyx2lyx change would have done, anyway. But for what
it's worth, my sense is that---modulo the lyx2lyx stuff, which I don't
understand---the changes here are simple and safe, but not critical at
this time. But this stuff should be removed before it is forgotten.
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: Collapsable CharStyles [Beyond 1.5]
Richard Heck wrote: Jürgen Spitzmüller wrote: Richard Heck wrote: Comments welcome. Could you please wait until 1.5.0 is done? Sorry, didn't mean to distract you. It just seems as if most of us are waiting for 1.5.0 to be done---there are a few things left, not unimportant things, but not much for most of us to do Just do your experiment silently in a branch ;-) Abdel.
Re: crash while dissolving tabular
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: I cannot reproduce the crash under windows but this looks familiar to an old crash you had with the Toc if you remember. I rather think it's a remainder of bug 3258. Note that in the backtrace, line 3497 in InsetTabular::doDispatch is reached, if (!is_deleted_) InsetTabularMailer(*this).updateDialog(cur.bv()); // -- this one which means that is_deleted_ is false. AFAIU your fix in revision 17568, is_deleted_ should be true in this case. Yes, it should be true but as I said, I cannot reproduce the bug so I guess it will be true for me. I'll try to debug that today to verify that. Abdel.
Re: Patches for 1820 and 3613
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: While I agree with you, I also agree with Dov that we should branch 1.5 now... I'm not opposed to that, but it's up to José. Well, as the baby is supposed to land in your hand very soon now (how many time I said this? ;-)) I think your opinion matters. Jose? Abdel.
Re: crash while dissolving tabular
Abdelrazak Younes wrote: Yes, it should be true but as I said, I cannot reproduce the bug so I guess it will be true for me. It also doesn't always crash for me (but very often). I'll try to debug that today to verify that. Please let me know if I can do something. Jürgen
[PATCH] Re: crash while dissolving tabular
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I cannot reproduce the crash under windows but this looks familiar to an
old crash you had with the Toc if you remember.
I rather think it's a remainder of bug 3258. Note that in the backtrace, line
3497 in InsetTabular::doDispatch is reached,
if (!is_deleted_)
InsetTabularMailer(*this).updateDialog(cur.bv()); // -- this
one
which means that is_deleted_ is false. AFAIU your fix in revision 17568,
is_deleted_ should be true in this case.
Here is a radical solution. I should have thought about this earlier!
The dialog will be updated in any case by the LyXFunc::dispatch() method
so the updating done in InsetTabular::dispatch() is superfluous.
I think this should go in before 1.5.0.
Abdel.
Index: insets/InsetTabular.cpp
===
--- insets/InsetTabular.cpp (revision 19102)
+++ insets/InsetTabular.cpp (working copy)
@@ -2877,13 +2877,13 @@
InsetTabular::InsetTabular(Buffer const buf, row_type rows,
col_type columns)
: tabular(buf.params(), max(rows, row_type(1)),
- max(columns, col_type(1))), buffer_(buf), scx_(0), is_deleted_(false)
+ max(columns, col_type(1))), buffer_(buf), scx_(0)
{}
InsetTabular::InsetTabular(InsetTabular const tab)
: Inset(tab), tabular(tab.tabular),
- buffer_(tab.buffer_), scx_(0), is_deleted_(false)
+ buffer_(tab.buffer_), scx_(0)
{}
@@ -3491,11 +3491,6 @@
cell(cur.idx())-dispatch(cur, cmd);
break;
}
-
- // FIXME: this accesses the position cache before it is initialized
- //resetPos(cur);
- if (!is_deleted_)
- InsetTabularMailer(*this).updateDialog(cur.bv());
}
Index: insets/InsetTabular.h
===
--- insets/InsetTabular.h (revision 19100)
+++ insets/InsetTabular.h (working copy)
@@ -824,9 +824,6 @@
mutable idx_type first_visible_cell;
///
mutable int scx_;
- /// Ugly boolean used when this inset is dissolved and
- /// InsetTabularMailer should not be used.
- bool is_deleted_;
};
Spellchecking into notes
IMO, spellchecking should be disabled into notes because one often type here some custom stuff and abbreviations such as IMO, BTW, ..., smth, manuf., etc., which aren't to be parsed by the spellchecker. IMHO, notes aren't intended to be spelled correctly. It is annoying to get useless spellchecking stops into notes every time. IMO at least a Disable notes spellchecking checkbox into the spelling dialog (or the preference pane) would be useful. Enhancement? Mael.
Re: [PATCH] Re: crash while dissolving tabular
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Here is a radical solution. I should have thought about this earlier! The dialog will be updated in any case by the LyXFunc::dispatch() method so the updating done in InsetTabular::dispatch() is superfluous. This patch - doesn't compile (is_deleted_ is still used in the destructor) Yes, I was about to send an updated patch when I noticed this: - breaks the tabular dialog (try to check something in the dialog, e.g. multicolumn; it's not possible). This is because the controller/dialog/dispatch is so brain damaged that I wonder how it worked up until now. So we need to investigate further. I am going to try to put the updateDialog() method in the Controller instead and see how it goes. Abdel.
Re: Spellchecking into notes
Mael Hilléreau wrote: Enhancement? http://bugzilla.lyx.org/show_bug.cgi?id=1509 Jürgen
Re: [PATCH] Re: crash while dissolving tabular
Abdelrazak Younes wrote: Here is a radical solution. I should have thought about this earlier! The dialog will be updated in any case by the LyXFunc::dispatch() method so the updating done in InsetTabular::dispatch() is superfluous. This patch - doesn't compile (is_deleted_ is still used in the destructor) - fixes the crash, but - breaks the tabular dialog (try to check something in the dialog, e.g. multicolumn; it's not possible). So we need to investigate further. Jürgen
[Updated PATCH] Re: crash while dissolving tabular
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Here is a radical solution. I should have thought about this earlier!
The dialog will be updated in any case by the LyXFunc::dispatch() method
so the updating done in InsetTabular::dispatch() is superfluous.
This patch
- doesn't compile (is_deleted_ is still used in the destructor)
Yes, I was about to send an updated patch when I noticed this:
- breaks the tabular dialog (try to check something in the dialog,
e.g. multicolumn; it's not possible).
This is because the controller/dialog/dispatch is so brain damaged that
I wonder how it worked up until now.
So we need to investigate further.
I am going to try to put the updateDialog() method in the Controller
instead and see how it goes.
I got a much better solution attached.
Abdel.
Index: frontends/controllers/ControlTabular.cpp
===
--- frontends/controllers/ControlTabular.cpp(revision 19100)
+++ frontends/controllers/ControlTabular.cpp(working copy)
@@ -32,16 +32,24 @@
{
// try to get the current cell
BufferView const * const bv = kernel().bufferview();
+ InsetTabular const * current_inset = 0;
if (bv) {
Cursor const cur = bv-cursor();
// get the innermost tabular inset;
// assume that it is ours
for (int i = cur.depth() - 1; i = 0; --i)
if (cur[i].inset().lyxCode() == Inset::TABULAR_CODE) {
+ current_inset = static_castInsetTabular
*(cur[i].inset());
active_cell_ = cur[i].idx();
break;
}
}
+
+ if (current_inset data.empty()) {
+ params_.reset(new Tabular(current_inset-tabular));
+ return true;
+ }
+
InsetTabular tmp(kernel().buffer());
InsetTabularMailer::string2params(data, tmp);
params_.reset(new Tabular(tmp.tabular));
Index: frontends/qt4/QTabular.cpp
===
--- frontends/qt4/QTabular.cpp (revision 19100)
+++ frontends/qt4/QTabular.cpp (working copy)
@@ -633,6 +633,8 @@
void QTabular::update_contents()
{
+ controller().initialiseParams(string());
+
Tabular const tabular(controller().tabular());
Tabular::idx_type const cell = controller().getActiveCell();
Index: insets/InsetTabular.cpp
===
--- insets/InsetTabular.cpp (revision 19102)
+++ insets/InsetTabular.cpp (working copy)
@@ -2877,20 +2877,19 @@
InsetTabular::InsetTabular(Buffer const buf, row_type rows,
col_type columns)
: tabular(buf.params(), max(rows, row_type(1)),
- max(columns, col_type(1))), buffer_(buf), scx_(0), is_deleted_(false)
+ max(columns, col_type(1))), buffer_(buf), scx_(0)
{}
InsetTabular::InsetTabular(InsetTabular const tab)
: Inset(tab), tabular(tab.tabular),
- buffer_(tab.buffer_), scx_(0), is_deleted_(false)
+ buffer_(tab.buffer_), scx_(0)
{}
InsetTabular::~InsetTabular()
{
InsetTabularMailer(*this).hideDialog();
- is_deleted_ = true;
}
@@ -3491,11 +3490,6 @@
cell(cur.idx())-dispatch(cur, cmd);
break;
}
-
- // FIXME: this accesses the position cache before it is initialized
- //resetPos(cur);
- if (!is_deleted_)
- InsetTabularMailer(*this).updateDialog(cur.bv());
}
Index: insets/InsetTabular.h
===
--- insets/InsetTabular.h (revision 19100)
+++ insets/InsetTabular.h (working copy)
@@ -824,9 +824,6 @@
mutable idx_type first_visible_cell;
///
mutable int scx_;
- /// Ugly boolean used when this inset is dissolved and
- /// InsetTabularMailer should not be used.
- bool is_deleted_;
};
Re: [Updated PATCH] Re: crash while dissolving tabular
Abdelrazak Younes wrote: I got a much better solution attached. This seems to work AFAICS. Thanks. Jürgen
Re: Text Settings Dialog [Beyond 1.5]
On Wed, Jul 18, 2007 at 01:57:40AM -0400, Richard Heck wrote: There are several large issues with this dialog collected in bug 3893. It really doesn't work very well. Here is a radical suggestion: Get rid of it in favor of character styles. So we'd have character styles like Italic, SmallCaps, and the like, accessed via the EditText Styles menu, rather than through a dialog. These could all be defined in a StdCharStyles.inc file to be included in other layouts. Great minds think alike ;-) I feel that the names should be Noun and Emphasized, as these are logical (abstract) styles. I seem to remember Juergen S inherited this project :-) - Martin
Re: [Updated PATCH] Re: crash while dissolving tabular
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: I got a much better solution attached. This seems to work AFAICS. Jose?
Re: [patch] fix drawing issue
On Wednesday 18 July 2007 06:43:17 Jürgen Spitzmüller wrote: José? OK. Jürgen -- José Abílio
Re: [Updated PATCH] Re: crash while dissolving tabular
On Wednesday 18 July 2007 10:13:58 Abdelrazak Younes wrote: Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: I got a much better solution attached. This seems to work AFAICS. Jose? OK. -- José Abílio
Re: [Updated PATCH] Re: crash while dissolving tabular
José Matos wrote: On Wednesday 18 July 2007 10:13:58 Abdelrazak Younes wrote: Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: I got a much better solution attached. This seems to work AFAICS. Jose? OK. Done. Abdel.
sys/socket.h usability... no
Intel Mac Mac OSX 10.4.01 lyx1.5.0svn Report from configure checking for fcntl... no checking for sys/select.h... (cached) yes checking sys/socket.h usability... no checking sys/socket.h presence... yes configure: WARNING: sys/socket.h: present but cannot be compiled configure: WARNING: sys/socket.h: check for missing prerequisite headers? configure: WARNING: sys/socket.h: see the Autoconf documentation configure: WARNING: sys/socket.h: section Present But Cannot Be Compiled configure: WARNING: sys/socket.h: proceeding with the preprocessor's result configure: WARNING: sys/socket.h: in the future, the compiler will take precedence configure: WARNING: ## -- ## configure: WARNING: ## Report this to lyx-devel@lists.lyx.org ## configure: WARNING: ## -- ## checking for sys/socket.h... yes
Re: sys/socket.h usability... no
Please ignore sys/socket.h usability error, there was an error in my configure command. Roger
Re: [PATCH] 3404: lyx2lyx adds too many \end_layout tokens
On Tuesday 17 July 2007 19:00:37 Bo Peng wrote: Jose: The test case of bug 3404 has multiple consecutive \begin_deeper \begin_deeper \end_deeper \end_deeper and an \end_layout is inserted before each \begin_deeper. This leads to excessive \end_layout. I am *not* familiar with lyx 1.3.x format and I do not know if there are valid cases where multiple \begin_deeper should yield multiple \end_layout. If you know the answer, the attached patch fixes bug 3404. Those are no longer valid files, it is impossible to create a file with two consecutive \begin_deeper. So if it works for your tests please put it in. Cheers, Bo The begin_deeper and end_deeper are a mess but you already know that. Two facts that I have (re)learned yesterday: - For 1.0 documents it is possible to have the body starting with \begin_deeper. - It is not true that each begin_deeper has a matching end_deeper. The foolowing file made with lyx 1.5 shows clearly this. As this example shows it is possible to have a file only with begin_deeper's and no end_deeper. :-) -- José Abílio newfile10.lyx Description: application/lyx
Re: [patch] fix doc_toc.py documentation bug 3798
On Wednesday 18 July 2007 00:25:18 Uwe Stöhr wrote: Can this go in José? Yes. regards Uwe -- José Abílio
Re: [patch] remove linuxdoc from all doc files
On Wednesday 18 July 2007 07:22:17 Richard Heck wrote: Presumably, if you load one of these, it'll load fine, but if you opened one of the URL insets and did something to it, it'd be changed from htmlurl to url behind your back. Again, maybe not a huge problem, since that's what the lyx2lyx change would have done, anyway. But for what it's worth, my sense is that---modulo the lyx2lyx stuff, which I don't understand---the changes here are simple and safe, but not critical at this time. But this stuff should be removed before it is forgotten. I propose to ignore this for the moment. It is low hanging fruit so we can take care of it at any time. Richard -- José Abílio
Re: lyx2lyx for patch 1820
On Wednesday 18 July 2007 01:21:52 Dov Feldstern wrote: Also, this has only convinced me even more that it's wrong to apply a lyx2lyx fix for this patch: this is a bug fix, there were previously .lyx files which were ok, but which lyx was generating incorrect latex for, and patch 1820 fixes that. If there are lyx documents out there which patch 1820 affects, it can only do them good. All this lyx2lyx patch does is to explicitly set the language to the wrong values in all kinds of situations. OK you convinced me. I will accept the fix to bug 1820 if you add a comment in release notes. Do we have a deal? BTW in terms of final output what could it be the difference with and without this patch applied? Was the previous output always wrong to RTL users and so people learned to avoid it? This type of answer would justify our response to this bug. -- José Abílio
Re: [patch] remove linuxdoc from all doc files
On Wednesday 18 July 2007 11:07:33 José Matos wrote: I propose to ignore this for the moment. It is low hanging fruit so we can take care of it at any time. In case it matters this really means to move this fix to 1.6 since it (possibly) involves a file format change. -- José Abílio -- José Abílio
Re: Patches for 1820 and 3613
On Wednesday 18 July 2007 07:26:09 Abdelrazak Younes wrote: I'm not opposed to that, but it's up to José. Well, as the baby is supposed to land in your hand very soon now (how many time I said this? ;-)) I think your opinion matters. Jose? I think that we should branch after releasing 1.5.0. Our initial plan involved to fork after 1.5.1 but I think that LyX has evolved a lot since then. As we all know there are bugs that will only be found after the x.y.0 release but such is life. :-) From reading the user's mailing list I know that we have lots of users testing 1.5.0 so I am very confident in the final result. After setting on bug 1820 I think the only remaining show stopper is 3613. Abdel. -- José Abílio
Re: Patches for 1820 and 3613
José Matos wrote: After setting on bug 1820 I think the only remaining show stopper is 3613. What's the status of the lyx2lyx issues? Jürgen
Re: Patches for 1820 and 3613
On Wednesday 18 July 2007 11:28:19 Jürgen Spitzmüller wrote: What's the status of the lyx2lyx issues? I think that are quite near to get to a good solution. Since the code deals with retroversion I will place the code in svn and then ask people to test it. This code had a lot of testing so I think it is near public consumption. :-) Jürgen -- José Abílio
Re: Patches for 1820 and 3613
José Matos wrote: I think that are quite near to get to a good solution. great! Jürgen
Re: [PATCH] 3404: lyx2lyx adds too many \end_layout tokens
On Tuesday 17 July 2007 19:00:37 Bo Peng wrote: I am *not* familiar with lyx 1.3.x format and I do not know if there are valid cases where multiple \begin_deeper should yield multiple \end_layout. If you know the answer, the attached patch fixes bug 3404. Cheers, Bo Committed thanks. :-) -- José Abílio
Update to the release notes
Hello, I propose to warn users of 1.5.0 regarding the downgrade to 1.4 and 1.3 documents. I intend to commit the following patch and I would appreciate suggestion to change the spelling, grammar and content of the note. Regards, -- José Abílio Index: po/POTFILES.in === --- po/POTFILES.in (revision 19114) +++ po/POTFILES.in (working copy) @@ -121,6 +121,7 @@ src/insets/InsetTOC.cpp src/insets/InsetTabular.cpp src/insets/InsetText.cpp +src/insets/InsetTheorem.cpp src/insets/InsetUrl.cpp src/insets/InsetVSpace.cpp src/insets/InsetWrap.cpp @@ -128,6 +129,7 @@ src/insets/RenderPreview.cpp src/lengthcommon.cpp src/lyxfind.cpp +src/mathed/InsetFormulaMacro.cpp src/mathed/InsetMathAMSArray.cpp src/mathed/InsetMathCases.cpp src/mathed/InsetMathGrid.cpp Index: RELEASE-NOTES === --- RELEASE-NOTES (revision 19114) +++ RELEASE-NOTES (working copy) @@ -19,13 +19,13 @@ using the local encodings. LyX-1.5 now assumes that all layout files are UTF-8 encoded. This means that non-ASCII style names are still allowed but they nust be valid UTF-8 strings. One way of doing the conversion -is to use iconv. Using bash, the script below should work: - -cd /path/to/layouts -for l in * -do - cp $l tmp.txt - iconv -f latin1 -t utf8 tmp.txt -o $l +is to use iconv. Using bash, the script below should work: + +cd /path/to/layouts +for l in * +do + cp $l tmp.txt + iconv -f latin1 -t utf8 tmp.txt -o $l done rm tmp.txt @@ -35,7 +35,17 @@ same document, the cursor position is sometimes not correctly restored when you switch from one view to the other. +- Reverting 1.5 LyX documents to previous versions +Since unicode is supported in version 1.5 the dowgrade option to 1.4 +and 1.3 lyx documents may be lossy. In those cases where no meaningful +convertion was possible the characters will be replaced by a +placeholder ???. + +We have done our best effort to make the transition the smoothest +possible, if problems remain please report them to the users mailing +list. + Note: There may later be an updated list of known issues online at http://wiki.lyx.org/LyX/ReleaseNotes
Re: [patch] remove linuxdoc from all doc files
I propose to ignore this for the moment. It is low hanging fruit so we can take care of it at any time. OK, but what about the docs? Should I remove the description of linuxdoc or not? regards Uwe
Re: Spellchecking into notes
Selon Jürgen Spitzmüller [EMAIL PROTECTED]: Mael Hilléreau wrote: Enhancement? http://bugzilla.lyx.org/show_bug.cgi?id=1509 Thanks. I searched but didn't find it... Mael.
Re: [patch] remove linuxdoc from all doc files
On Wednesday 18 July 2007 12:38:05 Uwe Stöhr wrote: OK, but what about the docs? Should I remove the description of linuxdoc or not? Remove it. regards Uwe -- José Abílio
Re: Update to the release notes
José Matos wrote: Hello, I propose to warn users of 1.5.0 regarding the downgrade to 1.4 and 1.3 documents. I intend to commit the following patch and I would appreciate suggestion to change the spelling, grammar and content of the note. Index: RELEASE-NOTES === --- RELEASE-NOTES (revision 19114) +++ RELEASE-NOTES (working copy) @@ -19,13 +19,13 @@ using the local encodings. LyX-1.5 now assumes that all layout files are UTF-8 encoded. This means that non-ASCII style names are still allowed but they nust be valid UTF-8 strings. One way of doing the conversion -is to use iconv. Using bash, the script below should work: - -cd /path/to/layouts -for l in * -do - cp $l tmp.txt - iconv -f latin1 -t utf8 tmp.txt -o $l +is to use iconv. Using bash, the script below should work: + +cd /path/to/layouts +for l in * +do + cp $l tmp.txt + iconv -f latin1 -t utf8 tmp.txt -o $l The diff above doesn't show anything different AFAICT. +- Reverting 1.5 LyX documents to previous versions +Since unicode is supported in version 1.5 the dowgrade option to 1.4 *U*nicode dow*n*grade +and 1.3 lyx documents may be lossy. In those cases where no meaningful +convertion conversion + was possible the characters will be replaced by a +placeholder ???. + +We have done our best effort to make the transition the smoothest as smooth as +possible, if problems remain please report them to the users mailing +list. developers list?
Re: Exception when opening Document-settings on Solaris
Jürgen Spitzmüller [EMAIL PROTECTED] writes: José Matos wrote: OK then. Enrico earlier agreed with this and then we will have more time to fix this properly. Done. I've also reopened the bug report with a comment. I updated from svn on July 17 evening, and the GCC3 bug is still there. I applied Enrico's last patch (try/catch solution) with success. -- Jean-Pierre BTW with trac, trying to display frontend_helpers.cpp redirects me to http://tug.org/TeXnik/ ???
Re: Assertion when leaving LyX
Jean-Pierre Chrétien [EMAIL PROTECTED] writes: Abdelrazak Younes younes.a at ... writes: [...] We need the full context to help you. Please recompile in debug mode and send us the full backtrace. [...] That's all what I get With this problem, I can't use lyx in production. 1.5.0rc2 does not have the crash, but a popup opens informing the user about the impossibility to remove the temporary dir. This seems related to gcc 3, should I upgrade (or create a location for) gcc 4 ? -- Jean-Pierre
Re: Assertion when leaving LyX
Jean-Pierre Chrétien wrote: Here are the conditions: env LD_OPTIONS=-R/usr/local/lib ./configure \ --with-version-suffix=-$VERS \ --with-frontend=qt4 --with-qt-dir=/usr/local/qt-4.2.1 \ you have to use --with-qt4-dir Jürgen
Re: Update to the release notes
José Matos wrote: --- RELEASE-NOTES (revision 19114) +++ RELEASE-NOTES (working copy) @@ -19,13 +19,13 @@ using the local encodings. LyX-1.5 now assumes that all layout files are UTF-8 encoded. This means that non-ASCII style names are still allowed but they nust be valid UTF-8 strings. One way of doing the conversion nust? -is to use iconv. Using bash, the script below should work: - -cd /path/to/layouts -for l in * -do - cp $l tmp.txt - iconv -f latin1 -t utf8 tmp.txt -o $l +is to use iconv. Using bash, the script below should work: + +cd /path/to/layouts +for l in * +do + cp $l tmp.txt + iconv -f latin1 -t utf8 tmp.txt -o $l done rm tmp.txt @@ -35,7 +35,17 @@ same document, the cursor position is sometimes not correctly restored when you switch from one view to the other. +- Reverting 1.5 LyX documents to previous versions +Since unicode is supported in version 1.5 the dowgrade option to 1.4 downgrade +and 1.3 lyx documents may be lossy. In those cases where no meaningful +convertion was possible the characters will be replaced by a +placeholder ???. + +We have done our best effort to make the transition the smoothest +possible, if problems remain please report them to the users mailing +list. + Note: There may later be an updated list of known issues online at http://wiki.lyx.org/LyX/ReleaseNotes -- Peter Kümmel
Re: Text Settings Dialog [Beyond 1.5]
Martin Vermeer wrote: On Wed, Jul 18, 2007 at 01:57:40AM -0400, Richard Heck wrote: There are several large issues with this dialog collected in bug 3893. It really doesn't work very well. Here is a radical suggestion: Get rid of it in favor of character styles. So we'd have character styles like Italic, SmallCaps, and the like, accessed via the EditText Styles menu, rather than through a dialog. These could all be defined in a StdCharStyles.inc file to be included in other layouts. Great minds think alike ;-) I feel that the names should be Noun and Emphasized, as these are logical (abstract) styles. The Text Styles stuff sets things like italic and smallcaps---\textit and \textsc---rather than the logical styles. This is part of what makes it so confusing to new users, who don't distinguish \textit from \emph. We already have the ability to set \emph via Ctrl-E, or whatever; the ability to force \textit is different. 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: Patches for 1820 and 3613
José Matos wrote: Since the code deals with retroversion I will place the code in svn and then ask people to test it. This code had a lot of testing so I think it is near public consumption. :-) Things are much better now. We have only one issue left with (some) combining characters. I think it is easy to fix and should probably be done, because it can result in dataloss (without the ???-indicators), see http://bugzilla.lyx.org/show_bug.cgi?id=3985 for some further comments. Furthermore, it would be good if the remaining issue with OHM in bug 3313 could be fixed by implementing the wrapper idea Georg proposed here: http://bugzilla.lyx.org/show_bug.cgi?id=3313#c47 Apart from that, lyx2lyx is ready AFAICS. Jürgen
[patch] bg 4026: Math bindings that require the AltGr key don't work
http://bugzilla.lyx.org/show_bug.cgi?id=4026 Another oneliner (AltGr was not listed as modifier key). Jürgen Index: src/frontends/qt4/qlkey.h === --- src/frontends/qt4/qlkey.h (Revision 19112) +++ src/frontends/qt4/qlkey.h (Arbeitskopie) @@ -33,6 +33,7 @@ case Qt::Key_Control: case Qt::Key_Meta: case Qt::Key_Alt: + case Qt::Key_AltGr: return true; } return false;
Re: [patch] bg 4026: Math bindings that require the AltGr key don't work
Jürgen Spitzmüller wrote: http://bugzilla.lyx.org/show_bug.cgi?id=4026 Another oneliner (AltGr was not listed as modifier key). Ouch... this is another must go ;-) Abdel.
Re: Update to the release notes
On Wednesday 18 July 2007 13:45:27 Abdelrazak Younes wrote: The diff above doesn't show anything different AFAICT. The text has ^M at the end of lines. -- José Abílio
Re: [patch] bg 4026: Math bindings that require the AltGr key don't work
On Wednesday 18 July 2007 17:42:40 Jürgen Spitzmüller wrote: http://bugzilla.lyx.org/show_bug.cgi?id=4026 Another oneliner (AltGr was not listed as modifier key). Jürgen OK. -- José Abílio
Re: [patch] bug 3613 (includes format change)
On Sunday 15 July 2007 19:02:06 Dov Feldstern wrote: I think I fixed the problem I was having, this patch now works. Please try applying it and then converting as many files as you have lying around from older version with it, just to make sure it doesn't break anything. Jose --- could you also take a look at the code and see if it's ok? There's still the problem with downconversion (which exists before may patches) --- I'll see if using this code I can now fix that... I will accept a patch for the lyx2lyx version if the test for the version is in lyx_1_5.py and not in LyX.py. Argh... :-) everyone wants to play with LyX.py, first Anders and now you. ;-) Version 1.5 is the right context for this change, and not LyX.py. Tell me if you need some help to do this. Dov -- José Abílio
Re: [patch] bug 3613 (includes format change)
On Sunday 15 July 2007 01:59:27 Dov Feldstern wrote: BTW, a simple lyx2lyx question, which will make life much easier: how do I get to see the debug printouts? ./lyx2lyx ... /dev/null that is the general output is sent to /dev/null and you only care with the warnings. -- José Abílio
Re: [patch] bug 3613 (includes format change)
On Sunday 15 July 2007 19:02:06 Dov Feldstern wrote: I think I fixed the problem I was having, this patch now works. Please try applying it and then converting as many files as you have lying around from older version with it, just to make sure it doesn't break anything. Jose --- could you also take a look at the code and see if it's ok? Dov. I have thought a long bit about this patch. It seems to me that are you saying that the translation from step 249 was incomplete. If that is the case what you are trying to do is to finish that convertion so you don't need a new file format, we just need to add both the convertion and the retroversion to step 249 and there is no more any special case here. Am I wrong? There's still the problem with downconversion (which exists before may patches) --- I'll see if using this code I can now fix that... Dov -- José Abílio
Re: Assertion when leaving LyX
Jürgen Spitzmüller [EMAIL PROTECTED] writes: Jean-Pierre Chrétien wrote: Here are the conditions: env LD_OPTIONS=-R/usr/local/lib ./configure \ --with-version-suffix=-$VERS \ --with-frontend=qt4 --with-qt-dir=/usr/local/qt-4.2.1 \ you have to use --with-qt4-dir Thanks for pointing this out, but it does make a change. -- Jean-Pierre
Invito - Dignità e cultura di Impresa: generazioni a confronto.
Il Gruppo Giovani Imprenditori, organizza, il prossimo 20/21 luglio nella Provincia di Potenza, presso l'Hotel Garden con sede nel Comune di Barile , il Consiglio Federale Nazionale del Gruppo Giovani Imprenditori della Confapi, tradizionale momento di confronto promosso con i giovani imprenditori del territorio nazionale ed i giovani imprenditori associati della nostra regione. Il Gruppo Giovani API BASILICATA, costituito nell'aprile 2006, è composto da giovani imprenditori uniti dall'idea di ritrovare al suo interno attraverso valori comuni, in una logica responsabile, un approccio alla cultura d'impresa sul territorio per fare sviluppo e vincere le sfide di un mercato sempre più orientato alla piccola e media impresa. In particolar modo Sabato 21 luglio, sarà promosso un convegno sul tema: Dignità e cultura di Impresa: generazioni a confronto. Integrazione, Etica e Società L'evento avrà luogo presso la sala convegni dell'Hotel Garden di Barile con inizio programmato per le ore 9.30. Saranno presenti autorità nazionali e regionali, esperti ed imprenditori associati ad Api, rappresentanti degli istituti di credito operanti in regione e rappresentanti delle altre associazioni di categoria. Il Convegno è un occasione per discutere sulla dignità di un mestiere, di una impresa, la necessità di rendere visibile il mercato e il valore di una scelta, sia di intraprendere che di continuare la tradizione familiare, nel caso di generazioni che si susseguono; parlare di accesso al credito come bisogno chiaro di analisi per le aziende per evitare che lo stesso diventi con Basilea 2 il vero buco nero dello sviluppo economico; l'etica e la società civile, intese come luoghi dove esercitare il proprio ruolo; l'integrazione, quale capacità di dialogo aperto e di rapporto con le condizioni di genere , in termini di pari opportunità,disagio, immigrazione, che possono sviluppare valore aggiunto e positivo alla cultura di impresa. Saremmo lieti di averti tra gli ospiti presenti in sala e di invitarti anche al buffet che ci sarà alla conclusione dei lavori, sempre presso l'Hotel Garden. In allegato ti inviamo il programma e le schede di partecipazione, da trasmettere eventualmente via fax alla segreteria organizzativa, allo 0971 273461. Certi di presentare alla tua cortese attenzione una iniziativa di richiamo, ti salutiamo con cordialità. Gruppo Regionale Giovani CONFAPI di Basilicata Scarica l'invito (http://www.trendexpo.it/images/stories/documents/docs/invito_web.jpg) Scarica la scheda di registrazione per il Convegno (http://www.trendexpo.it/images/stories/documents/docs/scheda_reg_covegno.pdf) Scarica la scheda di registrazione per il Consiglio (http://www.trendexpo.it/images/stories/documents/docs/scheda_reg_consiglio.pdf) Cambia la tua sottoscrizione ( http://www.trendexpo.it/index.php?option=com_acajoomact=changesubscriber=1106cle=559a0e0501318ccb9f3528549f8d34aelistid=8 ) Cancellati ( http://www.trendexpo.it/index.php?option=com_acajoomact=unsubscribesubscriber=1106cle=559a0e0501318ccb9f3528549f8d34aelistid=8 )
Re: [patch] bug 3613 (includes format change)
José Matos wrote: On Sunday 15 July 2007 19:02:06 Dov Feldstern wrote: I think I fixed the problem I was having, this patch now works. Please try applying it and then converting as many files as you have lying around from older version with it, just to make sure it doesn't break anything. Jose --- could you also take a look at the code and see if it's ok? Dov. I have thought a long bit about this patch. It seems to me that are you saying that the translation from step 249 was incomplete. If that is the case what you are trying to do is to finish that convertion so you don't need a new file format, we just need to add both the convertion and the retroversion to step 249 and there is no more any special case here. Am I wrong? Umm, I was going to say that I think you are wrong, but on second thought, I think you're right. :) What was bothering me is that there are documents lying around which have already been converted past 249, without the fix. But on second thought, the part that I put into LyX.py is exactly supposed to make sure that such documents *don't* get converted, because maybe they were only created after 249, in which case they aren't supposed to be converted at all! So what you're saying is that we actually don't need a new format, nor do we need the part I wanted to add in LyX.py --- those two things actually cancel each other out... So what we should do, is just add this new function to what happens in the conversion from 249, and everything will be the same... Yes, I believe you're right. I'll test this and send in a revised patch. Thanks! Dov
Re: lyx2lyx for patch 1820
José Matos wrote:
On Wednesday 18 July 2007 01:21:52 Dov Feldstern wrote:
Also, this has only convinced me even more that it's wrong to apply a
lyx2lyx fix for this patch: this is a bug fix, there were previously
.lyx files which were ok, but which lyx was generating incorrect latex
for, and patch 1820 fixes that. If there are lyx documents out there
which patch 1820 affects, it can only do them good. All this lyx2lyx
patch does is to explicitly set the language to the wrong values in all
kinds of situations.
OK you convinced me. I will accept the fix to bug 1820 if you add a comment in
release notes. Do we have a deal?
Deal. What exactly should the comment say --- just explain where the
problems were, and that they are now hopefully fixed?
I actually like Martin's idea of just having a placeholder format change
to go along with this --- just in case we do ever decide that some kind
of format change is needed, so we can identify what is before and what
is after the fix was applied. Does this sound right?
BTW in terms of final output what could it be the difference with and without
this patch applied? Was the previous output always wrong to RTL users and so
people learned to avoid it?
This type of answer would justify our response to this bug.
As far as I can determine, there are two main changes:
1. In certain specific cases, the text inside a footnote is displayed in
the wrong language (i.e., in the GUI it shows that it's in Hebrew, but
is printed in latex in English characters and in LTR, or vice-versa).
2. A footnote breaks the RTL sequence, so instead of logical
{A...M[1]N...Z} being displayed as {Z...N[1]M...A}, it's displayed as
{M...A}[1]{Z...N}.
Regarding case 1, I doubt that many users were actually creating
documents which included these situations. If there are such documents,
then I would guess that it's for one of the following reasons:
(a) the user did not notice that the latex was generated incorrectly (in
the GUI it displays correctly, and maybe the user didn't go over the
latex output carefully --- after all, it's only a footnote...);
(b) the user knew about this, but assumed that someday the bug would be
corrected;
(c) the user was generating the document for a non-latex backend, which
generates correct output in these situations (I don't really know how
the other backends deal with these situations; plaintext output is
correct, as far as I can tell).
In all these cases, I think that including the lyx2lyx patch would only
be detrimental.
Regarding case 2, a user could conceivably realize what was happening,
and therefore decide to write the text in the wrong logical order:
{N...Z[1]A...M}, so that it would be displayed correctly as
{Z...N}[1]{M...A}. In this case, they *would* want a lyx2lyx fix.
However, creating documents that are logically wrong is bad practice,
and could lead to other problems. For example, if such text is broken by
a line-break, it gets totally mangled... So it's not a good situation to
have gotten into in the first place, and I would argue that we should
not perpetuate it by providing a fix for it.
Regarding non-RTL users, (2) doesn't affect them so much, but (1) does.
However, if the languages being mixed are same-alphabet languages (e.g.,
European languages), then they may not even notice something is wrong,
because it would display more-or-less correctly. So in this case, I
don't think that the fix would make much of a difference, nor would the
lyx2lyx patch. But I'm not sure about this.
So, what's the upshot?
1. Can I commit the patch for 1820 (the patch itself, the cleaned-up
version at http://permalink.gmane.org/gmane.editors.lyx.devel/90016)?
2. I provide a comment explaining this (I'll try to make it as shrt as
possible) for the release notes.
3. Preferably, also add a placeholder format change to go along with it,
but no lyx2lyx for the moment?
Thanks!
Dov
Re: Patches for 1820 and 3613
Jürgen Spitzmüller wrote: Dov Feldstern wrote: So far, though, these two patches have mostly been ignored --- a few people have responded, but not many. You're not ignored. I agree that these patches should be considered, but I don't understand the stuff enough to comment (and I'm too busy for testing). I think you should be patient and wait until José, who is the one who decides and also probably the one who understands the changes, finds time to look at it. Please accept that he is also quite busy with the lyx2lyx bugs currently. Jürgen Thank you to all of you who have responded. And I'm sorry for having been impatient, I guess I'm also being a little unfair --- certainly these patches are pretty RTL-oriented, and I don't really expect non-RTL users to get them. And I often (in fact, almost always) don't respond to other people's patches, because I don't understand exactly what they're about. And I know people are busy with other things. It's just that in this case, given how close we are to a release, and given the complexity of the patches, I'd like to have them committed as soon as possible, just so that we have more opportunities of catching bugs before the official release. I don't expect other developers to actively test them that much, but I do expect them to notice if something suddenly breaks because of them, and that's what I hope to catch before the release. Or to put it differently: I don't need testing for what I mean the patch to do --- I know it's doing the right thing in that sense ;) ; it's just that I want to catch all the *unexpected* things that it's doing as well --- and the only way to catch that is by giving them as much exposure as possible, so the sooner it happens, the more chances we have of still fixing any problems which may arise before the release... Again, thanks all of you for responding :) . Dov
Re: [patch] bug 3613 (includes format change)
Dov Feldstern wrote: José Matos wrote: On Sunday 15 July 2007 19:02:06 Dov Feldstern wrote: I think I fixed the problem I was having, this patch now works. Please try applying it and then converting as many files as you have lying around from older version with it, just to make sure it doesn't break anything. Jose --- could you also take a look at the code and see if it's ok? Dov. I have thought a long bit about this patch. It seems to me that are you saying that the translation from step 249 was incomplete. If that is the case what you are trying to do is to finish that convertion so you don't need a new file format, we just need to add both the convertion and the retroversion to step 249 and there is no more any special case here. Am I wrong? Umm, I was going to say that I think you are wrong, but on second thought, I think you're right. :) What was bothering me is that there are documents lying around which have already been converted past 249, without the fix. But on second thought, the part that I put into LyX.py is exactly supposed to make sure that such documents *don't* get converted, because maybe they were only created after 249, in which case they aren't supposed to be converted at all! So what you're saying is that we actually don't need a new format, nor do we need the part I wanted to add in LyX.py --- those two things actually cancel each other out... So what we should do, is just add this new function to what happens in the conversion from 249, and everything will be the same... Yes, I believe you're right. I'll test this and send in a revised patch. Thanks! Dov Attached find a much simplified version of this patch, based on what you suggested. I'm not sure if this is what you meant, but this time I just edited the function used in format change 249 in place, so there's now no need for a new version number, nor any need for changes in LyX.py. I'm still adding a note in FORMAT, though. OK? Dov Index: lyx-devel/development/FORMAT === --- lyx-devel.orig/development/FORMAT 2007-07-18 22:13:08.0 +0300 +++ lyx-devel/development/FORMAT2007-07-18 22:15:48.0 +0300 @@ -1,6 +1,11 @@ LyX file-format changes --- +2007-07-19 Dov Feldstern [EMAIL PROTECTED] + + * updates to format 249 conversion, so that it now correctly deals with + encodings in footnotes (part of bug 3613) + 2007-06-26 Uwe Stֳ¶hr [EMAIL PROTECTED] and Dov Feldstern [EMAIL PROTECTED] * format incremented to 276: switching exsting language 'arabic' to Index: lyx-devel/lib/lyx2lyx/lyx_1_5.py === --- lyx-devel.orig/lib/lyx2lyx/lyx_1_5.py 2007-07-18 22:13:08.0 +0300 +++ lyx-devel/lib/lyx2lyx/lyx_1_5.py2007-07-18 22:27:53.0 +0300 @@ -246,10 +246,13 @@ We do this here and not in LyX.py because it is far easier to do the necessary parsing in modern formats than in ancient ones. +inset_types = [Foot, Note] if document.cjk_encoding != '': return encoding_stack = [document.encoding] +inset_stack = [] lang_re = re.compile(r^\\lang\s(\S+)) +inset_re = re.compile(r^\\begin_inset\s(\S+)) if document.inputencoding == auto or document.inputencoding == default: for i in range(len(document.body)): result = lang_re.match(document.body[i]) @@ -264,7 +267,11 @@ encoding_stack[-1] = lang[language][3] elif find_token(document.body, \\begin_layout, i, i + 1) == i: document.warning(Adding nested encoding %s. % encoding_stack[-1], 3) -encoding_stack.append(encoding_stack[-1]) +if len(inset_stack) 0 and inset_stack[-1] in inset_types: +from lyx2lyx_lang import lang +encoding_stack.append(lang[document.language][3]) +else: +encoding_stack.append(encoding_stack[-1]) elif find_token(document.body, \\end_layout, i, i + 1) == i: document.warning(Removing nested encoding %s. % encoding_stack[-1], 3) if len(encoding_stack) == 1: @@ -272,6 +279,15 @@ document.warning(Malformed LyX document: Unexpected `\\end_layout'.) else: del encoding_stack[-1] +elif find_token(document.body, \\begin_inset, i, i + 1) == i: +inset_result = inset_re.match(document.body[i]) +if inset_result: +inset_type = inset_result.group(1) +inset_stack.append(inset_type) +else: +inset_stack.append() +elif find_token(document.body, \\end_inset, i, i + 1) == i: +del inset_stack[-1] if encoding_stack[-1] != document.encoding:
Re: Patches for 1820 and 3613
Jürgen Spitzmüller wrote:
José Matos wrote:
Since the code deals with retroversion I will place the code in svn and
then ask people to test it. This code had a lot of testing so I think it is
near public consumption. :-)
Things are much better now. We have only one issue left with (some) combining
characters. I think it is easy to fix and should probably be done, because it
can result in dataloss (without the ???-indicators), see
http://bugzilla.lyx.org/show_bug.cgi?id=3985
for some further comments.
Furthermore, it would be good if the remaining issue with OHM in bug 3313
could be fixed by implementing the wrapper idea Georg proposed here:
http://bugzilla.lyx.org/show_bug.cgi?id=3313#c47
Apart from that, lyx2lyx is ready AFAICS.
Jürgen
I'm not able to revert *anything* to 1.4 or 1.3 at the moment, I think
there must be a typo or something somewhere in lyx2lyx?
Even an *empty* document (English language, any encoding) generates the
following error:
Warning: An error ocurred in 248, function revert_unicode at 0xb7d176f4
Traceback (most recent call last):
File /home/dovf/lyx-devel/lib/lyx2lyx/lyx2lyx, line 101, in ?
sys.exit(main(sys.argv))
File /home/dovf/lyx-devel/lib/lyx2lyx/lyx2lyx, line 94, in main
file.convert()
File /home/dovf/lyx-devel/lib/lyx2lyx/LyX.py, line 415, in convert
conv(self)
File /home/dovf/lyx-devel/lib/lyx2lyx/lyx_1_5.py, line 1900, in
revert_unicode
[body_string, apa] = body_string.rsplit('\n',1)
AttributeError: 'unicode' object has no attribute 'rsplit'
Error: Cannot convert file
An error occurred whilst running python -tt
'/home/dovf/lyx-devel/lib/lyx2lyx/lyx2l
I'm working with r19120 from svn, no changes to any of the lyx2lyx files
in my tree, python version:
Python 2.3.5 (#2, Jul 30 2006, 15:57:01)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)]
lyx2lyx (was: Re: Patches for 1820 and 3613)
Dov Feldstern wrote:
Jürgen Spitzmüller wrote:
José Matos wrote:
Since the code deals with retroversion I will place the code in svn and
then ask people to test it. This code had a lot of testing so I think
it is
near public consumption. :-)
Things are much better now. We have only one issue left with (some)
combining characters. I think it is easy to fix and should probably be
done, because it can result in dataloss (without the
???-indicators), see
http://bugzilla.lyx.org/show_bug.cgi?id=3985
for some further comments.
Furthermore, it would be good if the remaining issue with OHM in bug
3313 could be fixed by implementing the wrapper idea Georg proposed here:
http://bugzilla.lyx.org/show_bug.cgi?id=3313#c47
Apart from that, lyx2lyx is ready AFAICS.
Jürgen
I'm not able to revert *anything* to 1.4 or 1.3 at the moment, I think
there must be a typo or something somewhere in lyx2lyx?
Even an *empty* document (English language, any encoding) generates the
following error:
Warning: An error ocurred in 248, function revert_unicode at 0xb7d176f4
Traceback (most recent call last):
File /home/dovf/lyx-devel/lib/lyx2lyx/lyx2lyx, line 101, in ?
sys.exit(main(sys.argv))
File /home/dovf/lyx-devel/lib/lyx2lyx/lyx2lyx, line 94, in main
file.convert()
File /home/dovf/lyx-devel/lib/lyx2lyx/LyX.py, line 415, in convert
conv(self)
File /home/dovf/lyx-devel/lib/lyx2lyx/lyx_1_5.py, line 1900, in
revert_unicode
[body_string, apa] = body_string.rsplit('\n',1)
AttributeError: 'unicode' object has no attribute 'rsplit'
Error: Cannot convert file
An error occurred whilst running python -tt
'/home/dovf/lyx-devel/lib/lyx2lyx/lyx2l
I'm working with r19120 from svn, no changes to any of the lyx2lyx files
in my tree, python version:
Python 2.3.5 (#2, Jul 30 2006, 15:57:01)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)]
I see that rsplit is new in 2.4... Are we officially requiring python2.4
for lyx2lyx, or is this just an oversight?
Re: lyx2lyx for patch 1820
Dov Feldstern wrote:
José Matos wrote:
On Wednesday 18 July 2007 01:21:52 Dov Feldstern wrote:
Also, this has only convinced me even more that it's wrong to apply a
lyx2lyx fix for this patch: this is a bug fix, there were previously
.lyx files which were ok, but which lyx was generating incorrect latex
for, and patch 1820 fixes that. If there are lyx documents out there
which patch 1820 affects, it can only do them good. All this lyx2lyx
patch does is to explicitly set the language to the wrong values in all
kinds of situations.
OK you convinced me. I will accept the fix to bug 1820 if you add a
comment in release notes. Do we have a deal?
Deal. What exactly should the comment say --- just explain where the
problems were, and that they are now hopefully fixed?
I actually like Martin's idea of just having a placeholder format change
to go along with this --- just in case we do ever decide that some kind
of format change is needed, so we can identify what is before and what
is after the fix was applied. Does this sound right?
BTW in terms of final output what could it be the difference with and
without this patch applied? Was the previous output always wrong to
RTL users and so people learned to avoid it?
This type of answer would justify our response to this bug.
As far as I can determine, there are two main changes:
1. In certain specific cases, the text inside a footnote is displayed in
the wrong language (i.e., in the GUI it shows that it's in Hebrew, but
is printed in latex in English characters and in LTR, or vice-versa).
2. A footnote breaks the RTL sequence, so instead of logical
{A...M[1]N...Z} being displayed as {Z...N[1]M...A}, it's displayed as
{M...A}[1]{Z...N}.
Regarding case 1, I doubt that many users were actually creating
documents which included these situations. If there are such documents,
then I would guess that it's for one of the following reasons:
(a) the user did not notice that the latex was generated incorrectly (in
the GUI it displays correctly, and maybe the user didn't go over the
latex output carefully --- after all, it's only a footnote...);
(b) the user knew about this, but assumed that someday the bug would be
corrected;
(c) the user was generating the document for a non-latex backend, which
generates correct output in these situations (I don't really know how
the other backends deal with these situations; plaintext output is
correct, as far as I can tell).
In all these cases, I think that including the lyx2lyx patch would only
be detrimental.
Regarding case 2, a user could conceivably realize what was happening,
and therefore decide to write the text in the wrong logical order:
{N...Z[1]A...M}, so that it would be displayed correctly as
{Z...N}[1]{M...A}. In this case, they *would* want a lyx2lyx fix.
However, creating documents that are logically wrong is bad practice,
and could lead to other problems. For example, if such text is broken by
a line-break, it gets totally mangled... So it's not a good situation to
have gotten into in the first place, and I would argue that we should
not perpetuate it by providing a fix for it.
Regarding non-RTL users, (2) doesn't affect them so much, but (1) does.
However, if the languages being mixed are same-alphabet languages (e.g.,
European languages), then they may not even notice something is wrong,
because it would display more-or-less correctly. So in this case, I
don't think that the fix would make much of a difference, nor would the
lyx2lyx patch. But I'm not sure about this.
So, what's the upshot?
1. Can I commit the patch for 1820 (the patch itself, the cleaned-up
version at http://permalink.gmane.org/gmane.editors.lyx.devel/90016)?
2. I provide a comment explaining this (I'll try to make it as shrt as
possible) for the release notes.
3. Preferably, also add a placeholder format change to go along with it,
but no lyx2lyx for the moment?
Thanks!
Dov
Attached find a patch which includes:
- a placeholder format change for bug 1820
- a comment for the release notes explaining the situation
The release notes is done against Jose's patch for them, and also
includes some minor fixes to that. The only significant change is that I
changed the please report to the users list to developers list (I
think Abdel also suggested that change).
Jose --- can I commit the patch itself, along with these additions?
Dov
Index: lyx-devel/src/Buffer.cpp
===
--- lyx-devel.orig/src/Buffer.cpp 2007-07-18 23:55:43.0 +0300
+++ lyx-devel/src/Buffer.cpp2007-07-19 00:01:26.0 +0300
@@ -141,7 +141,7 @@
namespace {
-int const LYX_FORMAT = 276;
+int const LYX_FORMAT = 277;
} // namespace anon
Index: lyx-devel/development/FORMAT
===
--- lyx-devel.orig/development/FORMAT 2007-07-18 23:55:43.0 +0300
+++
Re: [patch] remove linuxdoc from all doc files
OK, but what about the docs? Should I remove the description of linuxdoc or not? Remove it. Done. Uwe
Re: [patch] fix doc_toc.py documentation bug 3798
Can this go in José? Yes. Done: http://www.lyx.org/trac/changeset/19122 Uwe
current lyx2lyx fails on Windows and leads to a crash
There are now still 2 lyx2lyx blockers left:
- export userguide to LyX 1.4.x format and open the result with LyX 1.4.4
- Crash
the reason are the characters \^{\i} and \^{\j} at the end of the userguide,
see http://bugzilla.lyx.org/show_bug.cgi?id=3958#c37
- with the latest lyx2lyx changes lyx2lyx requires admin permissions on Windows
what makes it unusable for normal Windows users. The reason is the line
temp_file = os.tmpfile()
in lyx_1_5.py, see http://bugzilla.lyx.org/show_bug.cgi?id=4033
regards Uwe
CRASH in Current SVN
http://bugzilla.lyx.org/show_bug.cgi?id=4034 To reproduce: 1. Open any file containing an InsetCommand-type inset, e.g. a label. 2. Select some material containing that inset. 3. Exit LyX. Assertion triggered in T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons] by failing check ptr != 0 in file ../boost/boost/scoped_ptr.hpp:94 Backtrace: #0 0x007be402 in __kernel_vsyscall () at ../../boost/boost/regex/v4/match_results.hpp:238 #1 0x0068fba0 in raise () at ../../boost/boost/regex/v4/match_results.hpp:238 #2 0x006914b1 in abort () at ../../boost/boost/regex/v4/match_results.hpp:238 #3 0x08975f55 in lyx::support::abort () at abort.cpp:25 #4 0x08088268 in boost::assertion_failed (expr=0x8a28800 ptr != 0, function=0x8a4e560 T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons], file=0x8a1e68d ../boost/boost/scoped_ptr.hpp, line=94) at boost.cpp:56 #5 0x082eb4bf in boost::scoped_ptrlyx::LyX::Singletons::operator- ( this=0xbfda3864) at ../boost/boost/scoped_ptr.hpp:94 #6 0x082ddac0 in lyx::LyX::emergencyCleanup (this=0xbfda385c) at LyX.cpp:1024 #7 0x080881bd in boost::emergencyCleanup () at boost.cpp:45 #8 0x08088263 in boost::assertion_failed (expr=0x8a28800 ptr != 0, function=0x8a4e560 T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons], file=0x8a1e68d ../boost/boost/scoped_ptr.hpp, line=94) at boost.cpp:55 #9 0x082eb4bf in boost::scoped_ptrlyx::LyX::Singletons::operator- ( this=0xbfda3864) at ../boost/boost/scoped_ptr.hpp:94 #10 0x082e26be in lyx::LyX::hideDialogs (this=0xbfda385c, [EMAIL PROTECTED], inset=0xa2ef120) at LyX.cpp:386 #11 0x08551772 in lyx::MailInset::hideDialog (this=0xbfda35a8) at MailInset.cpp:44 #12 0x0859003b in ~InsetCommand (this=0xa2ef120) at InsetCommand.cpp:48 #13 0x085df14e in ~InsetLabel (this=0xa2ef120) at InsetLabel.h:20 #14 0x0824702e in ~InsetList (this=0xa194134) at InsetList.cpp:53 #15 0x083875e4 in ~Paragraph (this=0xa194130) at Paragraph.cpp:1092 #16 0x080a5721 in __gnu_norm::_List_baselyx::Paragraph, std::allocatorlyx::Paragraph ::_M_clear (this=0xa439128) at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/ext/new_allocator.h:107 #17 0x081ce560 in ~RandomAccessList (this=0xa439128) at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_list.h:339 #18 0x081c1018 in __tcf_2 () at ParagraphList.h:23 #19 0x00692859 in exit () at ../../boost/boost/regex/v4/match_results.hpp:238 #20 0x0067cdf4 in __libc_start_main () at ../../boost/boost/regex/v4/match_results.hpp:238 #21 0x08069421 in _start () at ../../boost/boost/regex/v4/match_results.hpp:238 The offending line seems to be: vectorint const view_ids = pimpl_-application_-gui().viewIds(); I think what's happening is that the material saved in the selection is not being destroyed until too late. The global pimpl_ seems already to have been destroyed at this point--I think because this is all clean-up being done by C++ itself. So somehow it seems we've forgotten to destroy the cache of copied material. 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: r19077 - in /lyx-devel/branches/personal/younes/mvc/src: ...
[EMAIL PROTECTED] wrote: Author: younes Date: Sat Jul 14 15:15:51 2007 New Revision: 19077 URL: http://www.lyx.org/trac/changeset/19077 Log: Polish and bug fixing * Buffer::~Buffer(): transfer label updating from LyXView::closeBuffer() here for child documents. Looks to me like you should wrap the entire contents of this destructor in a try/catch(std::exception) block... Angus
Re: r19084 - /lyx-devel/branches/personal/younes/mvc/src/fron...
[EMAIL PROTECTED] wrote:
Author: younes
Date: Sun Jul 15 22:56:19 2007
New Revision: 19084
URL: http://www.lyx.org/trac/changeset/19084
Log:
Add focus to current Work area by default.
void GuiView::setCurrentWorkArea(WorkArea * work_area)
{
BOOST_ASSERT(work_area);
- d.tab_widget_-setCurrentWidget(static_castGuiWorkArea *(work_area));
+ GuiWorkArea * wa = static_castGuiWorkArea *(work_area);
+ d.tab_widget_-setCurrentWidget(wa);
+ wa-setFocus();
}
dynamic_cast and you should check that wa isn't null.
Angus
Re: r19083 - in /lyx-devel/branches/personal/younes/mvc/src/f...
[EMAIL PROTECTED] wrote: Author: younes Date: Sun Jul 15 21:58:22 2007 New Revision: 19083 URL: http://www.lyx.org/trac/changeset/19083 Log: Transfer q_key_state from GuiWorkArea to QKeySymbol. == --- lyx-devel/branches/personal/younes/mvc/src/frontends/qt4/QKeySymbol.h (original) +++ lyx-devel/branches/personal/younes/mvc/src/frontends/qt4/QKeySymbol.h Sun Jul 15 21:58:22 2007 @@ -81,6 +81,8 @@ QString text_; }; +/// return the LyX key state from Qt's +extern key_modifier::state q_key_state(Qt::KeyboardModifiers state); } // namespace lyx I should read all your posts before responding to one ;-) Don't think it needs the extern modifier though... A
Re: CRASH in Current SVN
On Wed, 2007-07-18 at 22:00 -0400, Richard Heck wrote: http://bugzilla.lyx.org/show_bug.cgi?id=4034 To reproduce: 1. Open any file containing an InsetCommand-type inset, e.g. a label. 2. Select some material containing that inset. 3. Exit LyX. Assertion triggered in T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons] by failing check ptr != 0 in file ../boost/boost/scoped_ptr.hpp:94 See below, I sent this to the list three weeks ago and it's probably the same bug. I didn't have a backtrace and although I see it occasionally I didn't know how to reproduce anyway. Funny that nobody replied :) Forwarded Message From: Darren Freeman [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: LyX Developers List lyx-devel@lists.lyx.org Subject: Boost assertion triggered Date: Wed, 27 Jun 2007 18:23:15 +1000 I just closed LyX, and found this on the command line. Didn't have any adverse effects. Just thought the relevant person might be interested. Have fun, Darren 8888888 Assertion triggered in T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons] by failing check ptr != 0 in file ../boost/boost/scoped_ptr.hpp:94 Assertion triggered in T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons] by failing check ptr != 0 in file ../boost/boost/scoped_ptr.hpp:94 8888888
Re: r19082 - in /lyx-devel/branches/personal/younes/mvc/src/f...
[EMAIL PROTECTED] wrote: Author: younes Date: Sun Jul 15 21:35:13 2007 New Revision: 19082 URL: http://www.lyx.org/trac/changeset/19082 Log: Allow key event processing when there is no work area. Modified: lyx-devel/branches/personal/younes/mvc/src/frontends/qt4/GuiView.cpp lyx-devel/branches/personal/younes/mvc/src/frontends/qt4/GuiWorkArea.cpp Modified: lyx-devel/branches/personal/younes/mvc/src/frontends/qt4/GuiView.cpp URL: http://www.lyx.org/trac/file/lyx-devel/branches/personal/younes/mvc/src/frontends/qt4/GuiView.cpp?rev=19082 == --- lyx-devel/branches/personal/younes/mvc/src/frontends/qt4/GuiView.cpp (original) +++ lyx-devel/branches/personal/younes/mvc/src/frontends/qt4/GuiView.cpp Sun Jul 15 21:35:13 2007 @@ -67,6 +67,8 @@ using support::FileName; using support::libFileSearch; using support::makeDisplayPath; + +extern key_modifier::state q_key_state(Qt::KeyboardModifiers state); If it's public (and it is) then publish it in GuiWorkArea.h Angus
Re: r19094 - in /lyx-devel/trunk/src: LyX.cpp LyX.h LyXFunc.c...
[EMAIL PROTECTED] wrote: Author: younes Date: Tue Jul 17 11:20:39 2007 New Revision: 19094 URL: http://www.lyx.org/trac/changeset/19094 Log: Fix this bug: 1) create a doc 2) insert an ert inset 3) right-click the inset 4) new window 5) delete the ert inset: BOOM! This commit replace the static hideDialog signal which was in effect shared by all views with a direct call to Dialog::hide(). niice ;-) A.
Re: CRASH in Current SVN
Darren Freeman wrote: On Wed, 2007-07-18 at 22:00 -0400, Richard Heck wrote: http://bugzilla.lyx.org/show_bug.cgi?id=4034 To reproduce: 1. Open any file containing an InsetCommand-type inset, e.g. a label. 2. Select some material containing that inset. 3. Exit LyX. Assertion triggered in T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons] by failing check ptr != 0 in file ../boost/boost/scoped_ptr.hpp:94 See below, I sent this to the list three weeks ago and it's probably the same bug. I didn't have a backtrace and although I see it occasionally I didn't know how to reproduce anyway. Funny that nobody replied :) Looks like the same bug to me. Not something that would have bothered people a lot, as it only seems to happen on close. Richard Forwarded Message From: Darren Freeman [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: LyX Developers List lyx-devel@lists.lyx.org Subject: Boost assertion triggered Date: Wed, 27 Jun 2007 18:23:15 +1000 I just closed LyX, and found this on the command line. Didn't have any adverse effects. Just thought the relevant person might be interested. Have fun, Darren 8888888 Assertion triggered in T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons] by failing check ptr != 0 in file ../boost/boost/scoped_ptr.hpp:94 Assertion triggered in T* boost::scoped_ptrT::operator-() const [with T = lyx::LyX::Singletons] by failing check ptr != 0 in file ../boost/boost/scoped_ptr.hpp:94 8888888 -- == 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: [Updated PATCH] Re: crash while dissolving tabular
Abdelrazak Younes wrote:
I got a much better solution attached.
Abdel.
Index: frontends/controllers/ControlTabular.cpp
===
--- frontends/controllers/ControlTabular.cpp(revision 19100)
+++ frontends/controllers/ControlTabular.cpp(working copy)
@@ -32,16 +32,24 @@
{
// try to get the current cell
BufferView const * const bv = kernel().bufferview();
+ InsetTabular const * current_inset = 0;
if (bv) {
Cursor const cur = bv-cursor();
// get the innermost tabular inset;
// assume that it is ours
for (int i = cur.depth() - 1; i = 0; --i)
if (cur[i].inset().lyxCode() == Inset::TABULAR_CODE) {
+ current_inset = static_castInsetTabular
*(cur[i].inset());
active_cell_ = cur[i].idx();
break;
Glad to here that this fixes the crash. However, the above should be
const_cast. Don't use a sledgehammer when you don't need to.
Angus
Re: Update to the release notes
José Matos wrote: Hello, I propose to warn users of 1.5.0 regarding the downgrade to 1.4 and 1.3 documents. I intend to commit the following patch and I would appreciate suggestion to change the spelling, grammar and content of the note. Regards, Index: RELEASE-NOTES === --- RELEASE-NOTES (revision 19114) +++ RELEASE-NOTES (working copy) @@ -19,13 +19,13 @@ using the local encodings. LyX-1.5 now assumes that all layout files are UTF-8 encoded. This means that non-ASCII style names are still allowed but they nust be valid UTF-8 strings. One way of doing the conversion -is to use iconv. Using bash, the script below should work: - -cd /path/to/layouts -for l in * -do - cp $l tmp.txt - iconv -f latin1 -t utf8 tmp.txt -o $l +is to use iconv. Using bash, the script below should work: + +cd /path/to/layouts +for l in * +do + cp $l tmp.txt + iconv -f latin1 -t utf8 tmp.txt -o $l done rm tmp.txt Attached is my take on it. A. Index: RELEASE-NOTES === --- RELEASE-NOTES (revision 19124) +++ RELEASE-NOTES (working copy) @@ -15,19 +15,21 @@ - User layout files must be converted to UTF-8 -In previous version, layout styles were allowed to use non-ASCII names +In previous versions, layout styles were allowed to use non-ASCII names using the local encodings. LyX-1.5 now assumes that all layout files are UTF-8 encoded. This means that non-ASCII style names are still allowed -but they nust be valid UTF-8 strings. One way of doing the conversion -is to use iconv. Using bash, the script below should work: - -cd /path/to/layouts -for l in * -do - cp $l tmp.txt - iconv -f latin1 -t utf8 tmp.txt -o $l +but they must be valid UTF-8 strings. One way of doing the conversion +is to use iconv. Using bash, the script below should work: + +#! /bin/sh + +cd /path/to/layouts +for l in * +do + cp $l tmp.txt + iconv -f latin1 -t utf8 tmp.txt -o $l done -rm tmp.txt +rm -f tmp.txt - Cursor restoration problems with Multiple-View
Re: lyx2lyx for patch 1820
On Thu, Jul 19, 2007 at 12:35:52AM +0300, Dov Feldstern wrote:
Dov Feldstern wrote:
José Matos wrote:
On Wednesday 18 July 2007 01:21:52 Dov Feldstern wrote:
Also, this has only convinced me even more that it's wrong to apply a
lyx2lyx fix for this patch: this is a bug fix, there were previously
.lyx files which were ok, but which lyx was generating incorrect latex
for, and patch 1820 fixes that. If there are lyx documents out there
which patch 1820 affects, it can only do them good. All this lyx2lyx
patch does is to explicitly set the language to the wrong values in all
kinds of situations.
OK you convinced me. I will accept the fix to bug 1820 if you add a
comment in release notes. Do we have a deal?
Deal. What exactly should the comment say --- just explain where the
problems were, and that they are now hopefully fixed?
I actually like Martin's idea of just having a placeholder format change to
go along with this --- just in case we do ever decide that some kind of
format change is needed, so we can identify what is before and what is
after the fix was applied. Does this sound right?
BTW in terms of final output what could it be the difference with and
without this patch applied? Was the previous output always wrong to RTL
users and so people learned to avoid it?
This type of answer would justify our response to this bug.
As far as I can determine, there are two main changes:
1. In certain specific cases, the text inside a footnote is displayed in
the wrong language (i.e., in the GUI it shows that it's in Hebrew, but is
printed in latex in English characters and in LTR, or vice-versa).
2. A footnote breaks the RTL sequence, so instead of logical
{A...M[1]N...Z} being displayed as {Z...N[1]M...A}, it's displayed as
{M...A}[1]{Z...N}.
Regarding case 1, I doubt that many users were actually creating documents
which included these situations. If there are such documents, then I would
guess that it's for one of the following reasons:
(a) the user did not notice that the latex was generated incorrectly (in
the GUI it displays correctly, and maybe the user didn't go over the latex
output carefully --- after all, it's only a footnote...);
(b) the user knew about this, but assumed that someday the bug would be
corrected;
(c) the user was generating the document for a non-latex backend, which
generates correct output in these situations (I don't really know how the
other backends deal with these situations; plaintext output is correct, as
far as I can tell).
In all these cases, I think that including the lyx2lyx patch would only be
detrimental.
Regarding case 2, a user could conceivably realize what was happening, and
therefore decide to write the text in the wrong logical order:
{N...Z[1]A...M}, so that it would be displayed correctly as
{Z...N}[1]{M...A}. In this case, they *would* want a lyx2lyx fix. However,
creating documents that are logically wrong is bad practice, and could lead
to other problems. For example, if such text is broken by a line-break, it
gets totally mangled... So it's not a good situation to have gotten into in
the first place, and I would argue that we should not perpetuate it by
providing a fix for it.
Regarding non-RTL users, (2) doesn't affect them so much, but (1) does.
However, if the languages being mixed are same-alphabet languages (e.g.,
European languages), then they may not even notice something is wrong,
because it would display more-or-less correctly. So in this case, I don't
think that the fix would make much of a difference, nor would the lyx2lyx
patch. But I'm not sure about this.
So, what's the upshot?
1. Can I commit the patch for 1820 (the patch itself, the cleaned-up
version at http://permalink.gmane.org/gmane.editors.lyx.devel/90016)?
2. I provide a comment explaining this (I'll try to make it as shrt as
possible) for the release notes.
3. Preferably, also add a placeholder format change to go along with it,
but no lyx2lyx for the moment?
Thanks!
Dov
Attached find a patch which includes:
- a placeholder format change for bug 1820
- a comment for the release notes explaining the situation
The release notes is done against Jose's patch for them, and also includes
some minor fixes to that. The only significant change is that I changed the
please report to the users list to developers list (I think Abdel also
suggested that change).
Jose --- can I commit the patch itself, along with these additions?
Dov
I like this solution. Indeed, a behaviour of generating
malformed documents should not be carried forward by lyx2lyx,
as no user can reasonably have relied on it.
- Martin
Index: lyx-devel/src/Buffer.cpp
===
--- lyx-devel.orig/src/Buffer.cpp 2007-07-18 23:55:43.0 +0300
+++
Collapsable CharStyles [Beyond 1.5]
I've uploaded a patch to bugzilla
http://bugzilla.lyx.org/show_bug.cgi?id=3309#c3
that adds collapsible character styles, so you can do this:
CharStyle Endnote
InsetType Collapsable
LatexType Command
LatexName endnote
Preamble
\usepackage{endnotes}
EndPreamble
End
and suddenly have your very own endnote inset. Comments welcome.
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] remove linuxdoc from all doc files
Richard Heck wrote:
> I've done this: patch attached. That said, just removing the option from
> the dialog won't do anything one way or another about old files in which
> it exists. Those files will still be loaded with that option, and it
> won't be handled properly.
>
> Maybe that's OK for now, but I'd have thought we should eliminate it
> altogether, if we're removing it from the dialog. If so, this is a
> format change, and appropriate lyx2lyx will presumably be needed (maybe
> just to convert htmlurl insets into url insets). I haven't gone into
> lyx2lyx, so someone else would need to do that. To eliminate this, we'd
> need changes everywhere htmlurl is mentioned:
> factory.cpp:430: || cmdName == "htmlurl") {
> insets/Inset.cpp:64: InsetName("htmlurl", Inset::HTMLURL_CODE),
> insets/InsetCommandParams.cpp:166: if (name == "htmlurl" || name ==
> "url") {
> Text3.cpp:1166: InsetCommandParams p("htmlurl");
> But those changes are pretty obvious. It's the lyx2lyx stuff that I
> don't understand.
>
> Richard
The lyx2lyx change would probably be very trivial, something like (untested):
def convert_htmlurl(document):
" \begin_inset LatexCommand htmlurl -> \begin_inset LatexCommand url"
for i in range(len(document.body)):
document.body[i] = document.body[i].replace("\\begin_inset LatexCommand
htmlurl",
"\\begin_inset LatexCommand
url")
reversion would not be needed.
However, I'm not sure we should do all these changes now.
What happens with old LinuxDoc documents BTW?
Jürgen
Re: Text Settings Dialog [Beyond 1.5]
Richard Heck wrote: > There are several large issues with this dialog collected in bug 3893. > It really doesn't work very well. Here is a radical suggestion: Get rid > of it in favor of character styles. So we'd have character styles like > Italic, SmallCaps, and the like, accessed via the Edit>Text Styles menu, > rather than through a dialog. These could all be defined in a > StdCharStyles.inc file to be included in other layouts. Yes. I also have some plans for this. > There are some issues with this. At present, nesting character styles > can lead to some ugly display, because the lines under the text nest and > create quite a mess. I'd suggest making these optional, via a Layout > setting. The attached patch gives some idea how this might work. It can > be tried with these character styles: > CharStyle Italic > LatexType Command > LatexName textit > ShowBox false > Font > Shape Italic > EndFont > End One thing that needs to be done, btw, is make Font Shape Italic EndFont actually output italic font (in LaTeX) without further preamble ado. I have a patch for this, but it probably needs a format change, since we have to introduce GuiFont tags for those who want to set the font in LyX only. > CharStyle SmallCaps > LatexType Command > LatexName textsc > ShowBox false > Font > Shape SmallCaps > EndFont > End > But there are still some issues here with the behavior of the cursor, as > it seems to expect a border between the inset and the surrounding text, > which has been removed. > > Another issue is that the Edit>Text Style menu could become very > crowded. It'd be nice to be able to define character styles and put them > into submenus, perhaps via a setting that was something like: > Submenu Shape > Which would create and populate submenus. I'd prefer to have a combox (analogous to the paragraph style combox) in the toolbar instead of the menus. Jürgen > Richard
Re: Collapsable CharStyles [Beyond 1.5]
Richard Heck wrote: > Comments welcome. Could you please wait until 1.5.0 is done? Jürgen
Re: lyx2lyx for patch 1820
Enrico Forestieri wrote: On Wed, Jul 18, 2007 at 03:21:52AM +0300, Dov Feldstern wrote: Hi! Attached find a lyx2lyx for patch 1820. It's not perfect, though --- it actually corrupts some files which shouldn't be changed at all; if anyone wants to try and fix that, be my guest, I've just spent the past six hours on this and I'm not sure that it's doable. Also, this has only convinced me even more that it's wrong to apply a lyx2lyx fix for this patch: this is a bug fix, there were previously .lyx files which were ok, but which lyx was generating incorrect latex for, and patch 1820 fixes that. If there are lyx documents out there which patch 1820 affects, it can only do them good. All this lyx2lyx patch does is to explicitly set the language to the wrong values in all kinds of situations. FWIW, I agree with you. LyX was generating wrong LaTeX code in those cases and this should be considered as bug fix. IMO, it is laughable requiring a lyx2lyx patch in order to perpetuate the bug. Agreed. Abdel.
Re: Collapsable CharStyles [Beyond 1.5]
Jürgen Spitzmüller wrote: Richard Heck wrote: Comments welcome. Could you please wait until 1.5.0 is done? Sorry, didn't mean to distract you. It just seems as if most of us are waiting for 1.5.0 to be done---there are a few things left, not unimportant things, but not much for most of us to do 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: Patches for 1820 and 3613
Jürgen Spitzmüller wrote: Dov Feldstern wrote: So far, though, these two patches have mostly been ignored --- a few people have responded, but not many. You're not ignored. I agree that these patches should be considered, but I don't understand the stuff enough to comment (and I'm too busy for testing). Same for me, sorry Dov. I think you should be patient and wait until José, who is the one who decides and also probably the one who understands the changes, finds time to look at it. Please accept that he is also quite busy with the lyx2lyx bugs currently. While I agree with you, I also agree with Dov that we should branch 1.5 now... Abdel.
Re: Collapsable CharStyles [Beyond 1.5]
Richard Heck wrote: > Sorry, didn't mean to distract you. It just seems as if most of us are > waiting for 1.5.0 to be done---there are a few things left, not > unimportant things, but not much for most of us to do On the contrary, this is attracting me, and I try to be resistant ;-) Jürgen
Re: Text Settings Dialog [Beyond 1.5]
Richard Heck wrote: Another issue is that the Edit>Text Style menu could become very crowded. I can imagine a menu containing the last 10 styles used only. The last menu item would launch a dialog with a list view (or a tree view) or all available menu. It'd be nice to be able to define character styles and put them into submenus, perhaps via a setting that was something like: Submenu Shape Which would create and populate submenus. Indeed. Richard, you can play with my mvc branch if you want to test out these ideas. Abdel.
Re: Patches for 1820 and 3613
Abdelrazak Younes wrote: > While I agree with you, I also agree with Dov that we should branch 1.5 > now... I'm not opposed to that, but it's up to José. Jürgen
Re: [patch] remove linuxdoc from all doc files
Jürgen Spitzmüller wrote:
Richard Heck wrote:
I've done this: patch attached. That said, just removing the option from
the dialog won't do anything one way or another about old files in which
it exists. Those files will still be loaded with that option, and it
won't be handled properly.
Maybe that's OK for now, but I'd have thought we should eliminate it
altogether, if we're removing it from the dialog. If so, this is a
format change, and appropriate lyx2lyx will presumably be needed (maybe
just to convert htmlurl insets into url insets). I haven't gone into
lyx2lyx, so someone else would need to do that. To eliminate this, we'd
need changes everywhere htmlurl is mentioned:
factory.cpp:430: || cmdName == "htmlurl") {
insets/Inset.cpp:64:InsetName("htmlurl", Inset::HTMLURL_CODE),
insets/InsetCommandParams.cpp:166: if (name == "htmlurl" || name ==
"url") {
Text3.cpp:1166: InsetCommandParams p("htmlurl");
But those changes are pretty obvious. It's the lyx2lyx stuff that I
don't understand.
Richard
The lyx2lyx change would probably be very trivial, something like (untested):
def convert_htmlurl(document):
" \begin_inset LatexCommand htmlurl -> \begin_inset LatexCommand url"
for i in range(len(document.body)):
document.body[i] = document.body[i].replace("\\begin_inset LatexCommand
htmlurl",
"\\begin_inset LatexCommand
url")
reversion would not be needed.
However, I'm not sure we should do all these changes now.
It may not be critical to do this now. But
What happens with old LinuxDoc documents BTW?
Presumably, if you load one of these, it'll load fine, but if you opened
one of the URL insets and did something to it, it'd be changed from
htmlurl to url behind your back. Again, maybe not a huge problem, since
that's what the lyx2lyx change would have done, anyway. But for what
it's worth, my sense is that---modulo the lyx2lyx stuff, which I don't
understand---the changes here are simple and safe, but not critical at
this time. But this stuff should be removed before it is forgotten.
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: Collapsable CharStyles [Beyond 1.5]
Richard Heck wrote: Jürgen Spitzmüller wrote: Richard Heck wrote: Comments welcome. Could you please wait until 1.5.0 is done? Sorry, didn't mean to distract you. It just seems as if most of us are waiting for 1.5.0 to be done---there are a few things left, not unimportant things, but not much for most of us to do Just do your experiment silently in a branch ;-) Abdel.
Re: crash while dissolving tabular
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: I cannot reproduce the crash under windows but this looks familiar to an old crash you had with the Toc if you remember. I rather think it's a remainder of bug 3258. Note that in the backtrace, line 3497 in InsetTabular::doDispatch is reached, if (!is_deleted_) InsetTabularMailer(*this).updateDialog(()); // <-- this one which means that is_deleted_ is false. AFAIU your fix in revision 17568, is_deleted_ should be true in this case. Yes, it should be true but as I said, I cannot reproduce the bug so I guess it will be true for me. I'll try to debug that today to verify that. Abdel.
Re: Patches for 1820 and 3613
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: While I agree with you, I also agree with Dov that we should branch 1.5 now... I'm not opposed to that, but it's up to José. Well, as the baby is supposed to land in your hand very soon now (how many time I said this? ;-)) I think your opinion matters. Jose? Abdel.
Re: crash while dissolving tabular
Abdelrazak Younes wrote: > Yes, it should be true but as I said, I cannot reproduce the bug so I > guess it will be true for me. It also doesn't always crash for me (but very often). > I'll try to debug that today to verify that. Please let me know if I can do something. Jürgen
[PATCH] Re: crash while dissolving tabular
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I cannot reproduce the crash under windows but this looks familiar to an
old crash you had with the Toc if you remember.
I rather think it's a remainder of bug 3258. Note that in the backtrace, line
3497 in InsetTabular::doDispatch is reached,
if (!is_deleted_)
InsetTabularMailer(*this).updateDialog(()); // <-- this
one
which means that is_deleted_ is false. AFAIU your fix in revision 17568,
is_deleted_ should be true in this case.
Here is a radical solution. I should have thought about this earlier!
The dialog will be updated in any case by the LyXFunc::dispatch() method
so the updating done in InsetTabular::dispatch() is superfluous.
I think this should go in before 1.5.0.
Abdel.
Index: insets/InsetTabular.cpp
===
--- insets/InsetTabular.cpp (revision 19102)
+++ insets/InsetTabular.cpp (working copy)
@@ -2877,13 +2877,13 @@
InsetTabular::InsetTabular(Buffer const & buf, row_type rows,
col_type columns)
: tabular(buf.params(), max(rows, row_type(1)),
- max(columns, col_type(1))), buffer_(), scx_(0), is_deleted_(false)
+ max(columns, col_type(1))), buffer_(), scx_(0)
{}
InsetTabular::InsetTabular(InsetTabular const & tab)
: Inset(tab), tabular(tab.tabular),
- buffer_(tab.buffer_), scx_(0), is_deleted_(false)
+ buffer_(tab.buffer_), scx_(0)
{}
@@ -3491,11 +3491,6 @@
cell(cur.idx())->dispatch(cur, cmd);
break;
}
-
- // FIXME: this accesses the position cache before it is initialized
- //resetPos(cur);
- if (!is_deleted_)
- InsetTabularMailer(*this).updateDialog(());
}
Index: insets/InsetTabular.h
===
--- insets/InsetTabular.h (revision 19100)
+++ insets/InsetTabular.h (working copy)
@@ -824,9 +824,6 @@
mutable idx_type first_visible_cell;
///
mutable int scx_;
- /// Ugly boolean used when this inset is dissolved and
- /// InsetTabularMailer should not be used.
- bool is_deleted_;
};
Spellchecking into notes
IMO, spellchecking should be disabled into notes because one often type here some custom stuff and abbreviations such as "IMO", "BTW", ..., "smth", "manuf.", etc., which aren't to be parsed by the spellchecker. IMHO, notes aren't intended to be spelled correctly. It is annoying to get useless spellchecking stops into notes every time. IMO at least a "Disable notes spellchecking" checkbox into the spelling dialog (or the preference pane) would be useful. Enhancement? Mael.
Re: [PATCH] Re: crash while dissolving tabular
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Here is a radical solution. I should have thought about this earlier! The dialog will be updated in any case by the LyXFunc::dispatch() method so the updating done in InsetTabular::dispatch() is superfluous. This patch - doesn't compile (is_deleted_ is still used in the destructor) Yes, I was about to send an updated patch when I noticed this: - breaks the tabular dialog (try to check something in the dialog, e.g. "multicolumn"; it's not possible). This is because the controller/dialog/dispatch is so brain damaged that I wonder how it worked up until now. So we need to investigate further. I am going to try to put the updateDialog() method in the Controller instead and see how it goes. Abdel.
Re: Spellchecking into notes
Mael Hilléreau wrote: > Enhancement? http://bugzilla.lyx.org/show_bug.cgi?id=1509 Jürgen
Re: [PATCH] Re: crash while dissolving tabular
Abdelrazak Younes wrote: > Here is a radical solution. I should have thought about this earlier! > The dialog will be updated in any case by the LyXFunc::dispatch() method > so the updating done in InsetTabular::dispatch() is superfluous. This patch - doesn't compile (is_deleted_ is still used in the destructor) - fixes the crash, but - breaks the tabular dialog (try to check something in the dialog, e.g. "multicolumn"; it's not possible). So we need to investigate further. Jürgen
