Re: [Pre-PATCH 4053] Modifying other items enables OK button even when listings parameters are wrong.
Bo Peng wrote: > Jurgen, I would appreciate it if you can finish the patch (apply to > three listings-related dialogs). Otherwise, I can do it over the > weekend. I don't have time, sorry. However, I think we could also postpone this to 1.5.1. Jürgen
[Pre-PATCH 4053] Modifying other items enables OK button even when listings parameters are wrong.
Hi,
I did not know there is a virutal bool isValid() function that can be
used to determine if 'OK' should be enabled in DialogView. Clearly,
isValid should be defined in QListings, QInclude etc, and calls
validate_listings_parameter. A proper fix to bug 4053 should follow
the attached patch.
Jurgen, I would appreciate it if you can finish the patch (apply to
three listings-related dialogs). Otherwise, I can do it over the
weekend.
Thanks.
Bo
Index: src/frontends/qt4/QListings.h
===
--- src/frontends/qt4/QListings.h (revision 19162)
+++ src/frontends/qt4/QListings.h (working copy)
@@ -29,11 +29,13 @@
QListingsDialog(QListings * form);
/// get values from all the widgets and form a string
std::string construct_params();
+ ///
+ docstring validate_listings_params();
protected Q_SLOTS:
virtual void change_adaptor();
/// AFAIK, QValidator only works for QLineEdit so
/// I have to validate listingsED (QTextEdit) manually.
- void validate_listings_params();
+ void set_listings_hint();
/// turn off inline when float is clicked
void on_floatCB_stateChanged(int state);
/// turn off float when inline is clicked
@@ -63,6 +65,9 @@
virtual void update_contents();
/// build the dialog
virtual void build_dialog();
+protected:
+ ///
+ virtual bool isValid();
};
} // namespace frontend
Index: src/frontends/qt4/QListings.cpp
===
--- src/frontends/qt4/QListings.cpp (revision 19162)
+++ src/frontends/qt4/QListings.cpp (working copy)
@@ -190,9 +190,9 @@
connect(extendedcharsCB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(listingsED, SIGNAL(textChanged()), this, SLOT(change_adaptor()));
- connect(listingsED, SIGNAL(textChanged()), this, SLOT(validate_listings_params()));
+ connect(listingsED, SIGNAL(textChanged()), this, SLOT(set_listings_hint()));
connect(bypassCB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
- connect(bypassCB, SIGNAL(clicked()), this, SLOT(validate_listings_params()));
+ connect(bypassCB, SIGNAL(clicked()), this, SLOT(set_listings_hint()));
for (int n = 0; languages[n][0]; ++n)
languageCO->addItem(qt_(languages_gui[n]));
@@ -319,26 +319,29 @@
}
-void QListingsDialog::validate_listings_params()
+docstring QListingsDialog::validate_listings_params()
{
- static bool isOK = true;
InsetListingsParams par(construct_params());
docstring msg;
if (!bypassCB->isChecked())
msg = par.validate();
+ return msg;
+}
+
+
+void QListingsDialog::set_listings_hint()
+{
+ static bool isOK = true;
+ docstring msg = validate_listings_params();
if (msg.empty()) {
if (isOK)
return;
isOK = true;
listingsTB->setPlainText(
qt_("Input listing parameters on the right. Enter ? for a list of parameters."));
- okPB->setEnabled(true);
- applyPB->setEnabled(true);
} else {
isOK = false;
listingsTB->setPlainText(toqstr(msg));
- okPB->setEnabled(false);
- applyPB->setEnabled(false);
}
}
@@ -601,6 +604,12 @@
}
+bool QListings::isValid()
+{
+ return dialog_->validate_listings_params().empty();
+}
+
+
} // namespace frontend
} // namespace lyx
Re: lyx2lyx back convertion to 1.4
Bo Peng wrote: > This should have been fixed now. Yes. Thanks. Jürgen
Re: lyx2lyx back convertion to 1.4
The line is there, but there's a linebreak missing:
\begin{lstlisting}[language=Python,caption={Example Listing
float},label={lst:Example-Listing}]# Example listing float
So I did not have an extra \end_layout, but missed a \begin_layout.
This should have been fixed now.
Thanks.
Bo
[patch] fix encoding check
A user informed me that utf8-plain (for XeTeX) doesn't work because \inputenc
is called (which is exactly what utf8-plain shouldn't do).
It turned out that we use the wrong encoding check (the one of the document
language's default encoding, not the actual selected encoding), which breaks
LaTeX export as soon as a specific encoding is selected in
Document->Language. This is actually my fault.
I wonder why we didn't stumble across this earlier.
This oneline fixes it. OK to commit?
Jürgen
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp (Revision 19162)
+++ src/BufferParams.cpp (Arbeitskopie)
@@ -1411,7 +1411,7 @@
texrow.newline();
}
} else if (inputenc != "default") {
- switch (language->encoding()->package()) {
+ switch (encoding().package()) {
case Encoding::none:
break;
case Encoding::inputenc:
Re: lyx2lyx back convertion to 1.4
Bo Peng wrote:
> I just committed a patch, please test.
The line is there, but there's a linebreak missing:
\begin{lstlisting}[language=Python,caption={Example Listing
float},label={lst:Example-Listing}]# Example listing float
def func(param):
'this is a python function'
pass
\end{lstlisting}
Jürgen
Re: Slow motion while editing
Hi, so I compiled lyx with profiling enabled and without debug info, and I updated the gprof.out (same URL: http://www.dcc.uchile.cl/~gpothier/gprof.out) g On 7/20/07, Peter Kümmel <[EMAIL PROTECTED]> wrote: Guillaume Pothier wrote: > Here are the profiling results: > http://www.dcc.uchile.cl/~gpothier/gprof.out > This was using the document I already sent, typing random stuff within > floats, in paragraphs containing math insets, and in new paragraphs. > > Please tell me if I can provide more info. > g From your file: > .11 0.86 0.16 16862068 0.00 0.00 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator
Re: [patch] bug 3985: lyx2lyx conversion to 1.4.x format fails for latin2 accents
On Fri, Jul 20, 2007 at 03:11:47PM +0100, José Matos wrote: > I am not sure that affects all systems but technically you are correct, this > was fixed just for 2.3.4, right? Right: http://www.python.org/download/releases/2.3.4/NEWS.txt Apparently, it was affecting all systems. > OK. I committed a slightly more informative note: http://www.lyx.org/trac/changeset/19162 -- Enrico
Re: Keymaps
On Fri, Jul 20, 2007 at 03:46:32PM +0300, Dov Feldstern wrote:
> [EMAIL PROTECTED] wrote:
> >On Tue, 3 Jul 2007, Dov Feldstern wrote:
> >
> >>3) With a keymap, we (the LyX programmers) are in control. Two examples:
> >>(a) Almost always, a keymap switch should be accompanied by a language
> >>switch, or vice-versa.
> >
> >I'm not sure I agree about with the assumption about almost always
> >switching language.
> >
> >Let's say I'm typing a letter or some other text where I frequently
> >write different names, and these names require special characters such
> >as åäö etc. Do I really want to change the language for just the name?
> >
> >/Christian
> >
>
> Yes, you should. Technically, it's incorrect to just type in in a
> different language without letting LyX know about it.
It's not a different language.
Or would I have to write \french{Andr\'e} \german{P\"onitz} to get my
name right in LyX?
Andre'
Re: Slow motion while editing
Sorry, I forgot that flag when I compiled with profiling enabled... I'm compiling with both now, I'll report soon. g On 7/20/07, Peter Kümmel <[EMAIL PROTECTED]> wrote: Guillaume Pothier wrote: > Here are the profiling results: > http://www.dcc.uchile.cl/~gpothier/gprof.out > This was using the document I already sent, typing random stuff within > floats, in paragraphs containing math insets, and in new paragraphs. > > Please tell me if I can provide more info. > g From your file: > .11 0.86 0.16 16862068 0.00 0.00 __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator
Announcement of a hidden feature?
Lyx 1.5.0 has a new feature that you can open a lyx file with local .layout and .cls files. That is to say, if someone sends you a zip file with a lyx file and some foreign .cls and .layout files you can simply unpack and open the .lyx file. This is the result of my now-stopped 'local .layout and .cls files' efforts. It can be very useful in cases like "download this sample_thesis.zip, unpack and change appropriate parts". Should we advertise it in the announcement, or even user's guide? Index: ANNOUNCE === --- ANNOUNCE(revision 19159) +++ ANNOUNCE(working copy) @@ -249,6 +249,14 @@ you can paste the selected text using the middle button multiple times, even after the selection has been cleared. +* Limited support for local class and layout files + +Lyx can not create, but can open a .lyx file that uses local .cls and +.layout files. That is to say, you can send your co-author a .lyx file +along with customized .cls and .layout files, and s/he can work on +it without installation (the class and layout files) and reconfiguration. + + * Under the hood As usual, one big task has been the ongoing code cleanup of the LyX Bo
Re: Slow motion while editing
Guillaume Pothier wrote: > Here are the profiling results: > http://www.dcc.uchile.cl/~gpothier/gprof.out > This was using the document I already sent, typing random stuff within > floats, in paragraphs containing math insets, and in new paragraphs. > > Please tell me if I can provide more info. > g >From your file: > .11 0.86 0.16 16862068 0.00 0.00 > __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator __gnu_norm::vector std::allocator
Re: lyx2lyx back convertion to 1.4
However, while testing with the EmbeddedObjects document, I stumbled over another bug in revert_listings_inset (unrelated to unicode): revert the attached example to 1.4 and see how the line # Example listing float in the listing has disappeared I just committed a patch, please test. Bo
Re: Slow motion while editing
Here are the profiling results: http://www.dcc.uchile.cl/~gpothier/gprof.out This was using the document I already sent, typing random stuff within floats, in paragraphs containing math insets, and in new paragraphs. Please tell me if I can provide more info. g On 7/20/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote: Darren Freeman wrote: > On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote: >> I am sorry to hear that but we have no way to help you without nothing >> where the slowdown is. We need profile results! So, if you want to have >> a faster 1.5, please try to provide some. > > I would love that but I'm currently without income owing to my thesis > not being written yet :) If you can find the time to compile from a svn, compiling with profiling enabled is supposed to be easy on linux (with --enable-profile or something). > > I suspect it is related to the size of the document. No, it shouldn't be. Abdel.
Re: lyx2lyx back convertion to 1.4
However, while testing with the EmbeddedObjects document, I stumbled over another bug in revert_listings_inset (unrelated to unicode): revert the attached example to 1.4 and see how the line # Example listing float in the listing has disappeared Thanks. I will have a look. Bo
Re: lyx2lyx back convertion to 1.4
José Matos wrote:
> OK. I have just committed a fix for 4048, it follows the idea proposed by
> Georg in bug 3985.
>
> I have tried my best (to obfuscate the code). ;-)
Great!
> Please test.
Looks good from my first test (fixes Georg's test case, and the UserGuide
still seems to compile fine).
However, while testing with the EmbeddedObjects document, I stumbled over
another bug in revert_listings_inset (unrelated to unicode): revert the
attached example to 1.4 and see how the line
# Example listing float
in the listing has disappeared
The console complains:
Handling unknown body token: `# Example listing float'
Handling unknown body token: `\end_layout'
and the source looks like
--
\begin_inset ERT
status open
\begin_layout
\backslash
begin{lstlisting}[language=Python,caption={Example Listing
float},label={lst:Example-Listing}]
\end_layout
# Example listing float
\end_layout
\begin_layout Standard
def func(param):
\end_layout
\begin_layout Standard
'this is a python function'
\end_layout
\begin_layout Standard
pass
\end_layout
\begin_layout
\backslash
end{lstlisting}
\end_layout
\end_inset
--
So there's a '\begin_layout Standard' missing above this line or the one below
is set too late. I guess this is easy to fix.
Also, after reverting EmbeddedObjects, LyX 1.4 complains about several
InsetCollapsable::read: Missing 'status'-tag!
Handling unknown body token: `open'
Jürgen
listings.lyx
Description: application/lyx
Re: [Cvslog] r19150 - in /lyx-devel/trunk: RELEASE-NOTES src/Font.cpp ...
On Fri, Jul 20, 2007 at 02:42:35PM +0300, Dov Feldstern wrote: > José Matos wrote: > >On Friday 20 July 2007 09:42:40 Michael Gerz wrote: > >>Hmpf wasn't the removal of the const-ness the major reason why my > >>change tracking patch was rejected? > >> > >>Michael > > > >You are right. It seems that we need some kind of state machine to run > >across latex/docbook generation. And the OutputParams is not the answer. > > > > Long term, we certainly need to do some major rethinking of the whole > latex generation, IMO. The current situation seems very fragile. I'm not > sure what the problem is or how to make this easier, but here are some > thoughts on this. A newline-counting stream might already help a bit. I guess that's a nice little project for Bromarv for me. > Finally, we may also need a third object, which represents the current > state of the output mechanism: e.g., the current encoding. Regardless of > what LyX or latex thinks the current encoding is (or maybe they don't > even care), the output mechanism must know how the character it's about > to output is going to be encoded. Could be done by the outputstream itself, too. Andre'
Re: [PATCH] CT output (again)
On Fri, Jul 20, 2007 at 11:34:38AM +0200, Michael Gerz wrote: > Michael Gerz schrieb: > >Guys, > > > >with Dov's latest patch (#1820) committed, I was able to produce a CT > >patch that does not touch the present (non-)const-ness of OutputParams. > > > >Since I consider this bug a major CT bug (text inside deleted insets > >is displayed as unchanged text), I would like you to reconsider the > >patch for 1.5.0. > > > >In a certain sense, it is a one-liner because it effects current > >behavior only with this statement: > > > >- Change const & change = pimpl_->lookupChange(i); > >+ Change const & change = runparams.inDeletedInset ? > >runparams.changeOfDeletedInset > >+: > >pimpl_->lookupChange(i); > > > >Implementation notes: > > > >In order to fix the bug, it is necessary to pass information down the > >call stack. Prior to #1820, it would have been possible to make a > >local copy of the (const) outputparams, modify them locally, and pass > >the modified params down. However, it turns out that Dov needs to pass > >information _up_. Therefore, IMHO it is not a good idea to create > >local copies of outputParams in the same method. Instead, I modify the > >needed parameter at the beginning and reset them at the end > >(increment/decrement of inDeletedInset). > BTW: If you still don't like to add this information to OutputParams, I > have to add more parameters to several methods, e.g. to: > > void Paragraph::Pimpl::simpleTeXSpecialChars(Buffer const & buf, > BufferParams const & bparams, > odocstream & os, > TexRow & texrow, > OutputParams & runparams, > Font & running_font, > Font & basefont, > Font const & outerfont, > bool & open_font, > Change & running_change, > Layout const & style, > pos_type & i, > unsigned int & column, > value_type const c) > > IMHO 14 parameters are enough. Don't you think that a container like > OutputParams is the better solution? I am all for a container in such cases. Although i've seen functions with 57 parameters in real life, 14 is already far too much. Andre'
Re: Slow motion while editing
On Fri, Jul 20, 2007 at 06:35:52PM +1000, Darren Freeman wrote: > On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote: > > Guillaume Pothier wrote: > > > Abdel, I tried your patch and it actually makes things noticeably slower! > > > > Too bad! I guess the performance depends on the pixmap painting > > capabilities of your system. On Windows and I think Mac, it is > > definitely faster. > > What does that say about our systems... that Win and Mac require help to > run fast, or that X11 can't be helped :) The problem here is that the drawing systems are "incompatible" in so far as making something fast on one system has a certain potential to slow down other systems. On X11, and most notably on remote X11, performance is often limited by the communication speed of client and server, and increasing that requires sending little data and don't do anything requiring synchronous feed back. Otoh on Windows one gets usually pretty good (text drawing) results by doing everything locally and sending the final result in one chunk to the graphics card. Andre'
Re: lyx2lyx back convertion to 1.4
On Friday 20 July 2007 14:27:56 Jürgen Spitzmüller wrote: > - the above and some lyx2lyx issues that might be considered: 4048, 4050 > (oneliner from Anders available), 3313 (ordered in decreasing severity, > IMHO). Plus eventually Michael's patch. > > Concerning the lyx2lyx issues, I'd say since you are probably the only one > who can fix those, just go ahead and use your authority. > > Jürgen OK. I have just committed a fix for 4048, it follows the idea proposed by Georg in bug 3985. I have tried my best (to obfuscate the code). ;-) Please test. Since I gave my OK to the patch from Michael I would like to ask for testing the three so that we can release earlier next week. -- José Abílio
Re: Slow motion while editing
Abdelrazak Younes wrote: Darren Freeman wrote: On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote: I am sorry to hear that but we have no way to help you without nothing where the slowdown is. We need profile results! So, if you want to have a faster 1.5, please try to provide some. I would love that but I'm currently without income owing to my thesis not being written yet :) If you can find the time to compile from a svn, compiling with profiling enabled is supposed to be easy on linux (with --enable-profile or something). I'm incurring the same problem as Darren on svn (on FreeBSD). There is already a big time lag to type on a new document, and as the length of the document grows, the time lag becomes unbearable. On a new document, typing can catch up if you type meaningful sentences, but it cannot catch up random typing. After ten seconds of random typing, you have to wait probably more than five seconds to complete. This may not be a problem to type English, but problematic in CJK environment, because they use Input Method to convert typed keys to a sentence, and a relatively long sentence is fed to lyx *at once* (but anyway as a document becomes longer, it also becomes unbearable in English). I tried to write a small paper, but as the paper becomes longer, I found out the time lag makes lyx to an unusable level. I suspect this may be a problem of qt4 (or may not), as there is a small time lag to open a menu in qt4 compared to qt3 (although this itself is not too slow to be a problem). Unfortunately, I find no error message either. In case, the debug message with random typing is as follows. The tested machine has Xeon (nocona) 3GHz. Koji -- ParPosCache contains: Text:0x92921bc Paragraph 0: "asdf;lkasj" has point 0,36 Paragraph 1: "asdprov iu" has point 0,146 InsetCache contains: dispatch msg is SelfInsert arg[`d'] virtual void lyx::frontend::GuiWorkArea::keyPressEvent(QKeyEvent*) count=1 text=f isAutoRepeat=0 key=70 Setting key to 70, f KeySym is f isOK is 1 isMod is 0 void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, lyx::key_modifier::state) action first set to [85] void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, lyx::key_modifier::state)action now set to [85] void lyx::LyXFunc::processKeySym(lyx::KeySymbolPtr, lyx::key_modifier::state) Key [action=85][F] LyXFunc::dispatch: cmd: action: 85 arg: 'f' x: 0 y: 0 void lyx::Cursor::dispatch(const lyx::FuncRequest&) cmd: action: 85 arg: 'f' x: 0 y: 0 cursor:| anchor: inset: 0x929219c idx: 0 par: 1 pos: 116 | inset: 0x929219c idx: 0 par: 1 pos: 116 selection: 0 x_target: -1 Cursor::dispatch: cmd: action: 85 arg: 'f' x: 0 y: 0 cursor:| anchor: inset: 0x929219c idx: 0 par: 1 pos: 116 | inset: 0x929219c idx: 0 par: 1 pos: 116 selection: 0 x_target: -1 virtual void lyx::InsetText::doDispatch(lyx::Cursor&, lyx::FuncRequest&) [ cmd.action = 85] Text::dispatch: cmd: action: 85 arg: 'f' x: 0 y: 0 bool lyx::BufferView::update(lyx::Update::flags)[fitcursor = 1, forceupdate = 0, singlepar = 4] buffer: 0x9282c00 BufferView::update void lyx::BufferView::updateMetrics(bool) y1: 130 y2: 194 pit1: 1 pit2: 1 npit: 2 singlepar: 1size: 2 BufferView::updateMetrics ParPosCache contains: Text:0x92921bc Paragraph 0: "asdf;lkasj" has point 0,36 Paragraph 1: "asdprov iu" has point 0,146 InsetCache contains: void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 2 curr par: 1 default height 24 WorkArea::redraw screen #draw fdsafdsafdsafdsaasdfdsaadfasdf at 12,168 .
Re: Slow motion while editing
> Where are profiling results going to be output? i thought gprof should be used. however i didnt succeeded when running it - lyx immediately ends and gprof makes only analysis of that run. maybe some additional parameter sould be given, but i dont know which one. pavel
Re: Slow motion while editing
If you can find the time to compile from a svn, compiling with profiling enabled is supposed to be easy on linux (with --enable-profile or something). Ok I'll try it. Where are profiling results going to be output? g
Re: [patch] bug 3985: lyx2lyx conversion to 1.4.x format fails for latin2 accents
On Thursday 19 July 2007 19:10:26 Enrico Forestieri wrote: > Yes, that's it. What about the attached patch? > > -- > Enrico I am not sure that affects all systems but technically you are correct, this was fixed just for 2.3.4, right? OK. -- José Abílio
Re: Another addition to the RELEASE NOTES
José Matos wrote: On Friday 20 July 2007 13:37:36 Dov Feldstern wrote: I hope to solve this problem eventually, see discussion at http://permalink.gmane.org/gmane.editors.lyx.devel/88939. But for now, I think that adding this comment the the release notes should be enough. Dov OK. Done.
Re: [PATCH] CT output (again)
On Friday 20 July 2007 12:46:47 Michael Gerz wrote: > Just to make sure: Is OutputState 1.5.X stuff or would you (and Jürgen) > be willing with a temporary fix like the one posted before and find an > elegant solution for 1.6.0? Yes. This can go in 1.5.0 assuming the code has been tested (coming from you I have no doubts. ;-) ) and I would like to see an elegant and cleaner solution in 1.6 following the plan you have outlined. > Michael -- José Abílio
Re: lyx2lyx back convertion to 1.4
José Matos wrote: > The remaining tasks are: > - convert layout files to utf8 > - convert documentation to latest file format version > - update documentation > - other (?) The current state is, AFAICS: - the above and some lyx2lyx issues that might be considered: 4048, 4050 (oneliner from Anders available), 3313 (ordered in decreasing severity, IMHO). Plus eventually Michael's patch. Concerning the lyx2lyx issues, I'd say since you are probably the only one who can fix those, just go ahead and use your authority. Jürgen
Re: Another addition to the RELEASE NOTES
On Friday 20 July 2007 13:37:36 Dov Feldstern wrote: > I hope to solve this problem eventually, see discussion at > http://permalink.gmane.org/gmane.editors.lyx.devel/88939. But for now, I > think that adding this comment the the release notes should be enough. > > Dov OK. -- José Abílio
Re: [PATCH] CT output (again)
Michael Gerz wrote: > Just to make sure: Is OutputState 1.5.X stuff or would you (and Jürgen) > be willing with a temporary fix like the one posted before and find an > elegant solution for 1.6.0? If it's well tested, I wouldn't be opposed to it. But for 1.5.0, it's José's call. Jürgen
Re: [PATCH] CT output (again)
Michael Gerz wrote: José Matos schrieb: On Friday 20 July 2007 10:34:38 Michael Gerz wrote: IMHO 14 parameters are enough. Don't you think that a container like OutputParams is the better solution? Michael But not OutputParams. OutputParams are parameters used to control the output, as I said before you want something like OutputState. OutputParams are the public interface and OutputState would be the private interface, there is no need to mix the two even if it seems convenient. So you want me to create a new OutputState class for the two new flags, right? We might also want to add some existing parameters to the new container, too. Please note that even with this class, it might be beneficial to distinguish between parameters that are passed "down" and those that are passed "up" and "down". Just to make sure: Is OutputState 1.5.X stuff or would you (and Jürgen) be willing with a temporary fix like the one posted before and find an elegant solution for 1.6.0? Michael It seems to me that this will require major reworking in the future (see my half-baked ideas in http://permalink.gmane.org/gmane.editors.lyx.devel/90237), so we might as well use the current patch for now...? Dov
Re: patches 1820, 3613 explained
Dov Feldstern wrote: As far as the .lyx file is concerned: languages remain in effect until explicitly switched; the exception, though, is insets: inside an inset, the language is assumed to revert to the document language, unless explicitly told otherwise. Just a correction, in case anyone ever references this again: Actually, this is not correct. The language remains in effect within the scope in which it was set, and is reset to the document language at "\begin_layout Standard". So insets are behaving just like any other paragraph. This means the for two two consecutive paragraphs (just regular paragraphs, no insets or anything) which have the same language which is not the document language, the language is set explicitly inside each one. Dov
Re: [patch] typo in unicodesymbols
Jürgen Spitzmüller wrote: > > -0x00a9 "\textcopyright" "textcomp" "" # COPYRIGHT SIGN > > +0x00a9 "\\textcopyright" "textcomp" "" # COPYRIGHT SIGN > > Pardon? Oh, I see. Fixed. Jürgen
Re: Keymaps
Jean-Marc Lasgouttes wrote: "Dov" == Dov Feldstern writes: Dov> 1) As I said, this issue has come up on a few separate occasions Dov> in the past few months (mainly in connection with RTL languages), Dov> and each time there have been voices dismissing the keymap as Dov> unimportant, or even calling for abolishment of the keymap --- so Dov> I just want to explain why in my opinion it is very necessary, Dov> and make sure that we keep support for the keymap. I agree that we should keep them, but a lot of work is needed to improve them. Dov> So, I would like to (at some point, I may not get to it right Dov> away) implement the following: *) Every language can optionally Dov> have a keymap associated with it (this would require one more Dov> column in lib/languages). If the "use keyboard map" option in the Dov> preferences is on, then switching the language will automatically Dov> switch to the associated keymap. What about the opposite: allow keymaps to define an associated language, or even a list of languages. Then, when the cursor is on a text with a given language, change to a keymap that supports this language (with some algorithm that remains to determine). I am not sure why, but I prefer this option :) Maybe because it allows the user to pick the keymaps he wants to activate. It's funny, also Andrei (a.k.a. GoogleGuy) said the same thing --- that language should follow keymap. It seems backwards to me, though... I think that as much as possible, we should force users to choose a *language*, and not a keymap. See my response just now to Christian. For languages which have multiple keymaps (I don't know how common this is today, but there used to be different standards for Hebrew, for example), we'll have to think of some solution (probably the user will just have to edit lib/languages; or we can provide some frontend to that). But generally speaking, I think it would also be easier to determine a keymap given a language, than to determine a language given a keymap. And again, determining the language *is* important. Dov
Re: Keymaps
[EMAIL PROTECTED] wrote: On Tue, 3 Jul 2007, Dov Feldstern wrote: 3) With a keymap, we (the LyX programmers) are in control. Two examples: (a) Almost always, a keymap switch should be accompanied by a language switch, or vice-versa. I'm not sure I agree about with the assumption about almost always switching language. Let's say I'm typing a letter or some other text where I frequently write different names, and these names require special characters such as åäö etc. Do I really want to change the language for just the name? /Christian Yes, you should. Technically, it's incorrect to just type in in a different language without letting LyX know about it. It probably works for most European languages, but generally speaking, latex won't necessarily be able to deal with it if there are any encoding issues involved. Also (though this is probably not relevant for names), I think that if you specify the language, that will also allow LyX to use the correct spellchecker. Why *not* switch the language? The only reason I can think of is that it's more trouble. But if it would be easy to do, is there any reason not to? Dov
Another addition to the RELEASE NOTES
Hi! This should be added to the release notes. The problem was first reported here http://permalink.gmane.org/gmane.editors.lyx.devel/88806, it turned out to be related to the fact that we have now turned on the RTL option by default. I just opened a bug report for this now (bug 4051). I hope to solve this problem eventually, see discussion at http://permalink.gmane.org/gmane.editors.lyx.devel/88939. But for now, I think that adding this comment the the release notes should be enough. Dov Index: RELEASE-NOTES === --- RELEASE-NOTES (revision 19151) +++ RELEASE-NOTES (working copy) @@ -71,7 +71,20 @@ files, at least until you are sure that the upgrade went smoothly (which it almost always will). +- RTL and keymaps +Currently there is a bug where you can't use two non-RTL language keymaps if +the RTL preference is set (which is now the default). If you need to use two +non-RTL keymaps, for now you should just turn off the RTL preference (Tools -> +Preferences... -> Language settings -> Language, uncheck "Right-to-left +language support"). + +We hope to offer more comprehensive support for multiple keymaps in the future, +which will solve this bug, as well as allow more than just two keymaps. If you +have any input on this issue, please chime in on the developers mailing list, +or add your comments to http://bugzilla.lyx.org/show_bug.cgi?id=4051. + + Note: There may later be an updated list of known issues online at http://wiki.lyx.org/LyX/ReleaseNotes
Re: [PATCH] CT output (again)
José Matos schrieb: On Friday 20 July 2007 10:34:38 Michael Gerz wrote: IMHO 14 parameters are enough. Don't you think that a container like OutputParams is the better solution? Michael But not OutputParams. OutputParams are parameters used to control the output, as I said before you want something like OutputState. OutputParams are the public interface and OutputState would be the private interface, there is no need to mix the two even if it seems convenient. So you want me to create a new OutputState class for the two new flags, right? We might also want to add some existing parameters to the new container, too. Please note that even with this class, it might be beneficial to distinguish between parameters that are passed "down" and those that are passed "up" and "down". Just to make sure: Is OutputState 1.5.X stuff or would you (and Jürgen) be willing with a temporary fix like the one posted before and find an elegant solution for 1.6.0? Michael
Re: [Cvslog] r19150 - in /lyx-devel/trunk: RELEASE-NOTES src/Font.cpp ...
José Matos wrote: On Friday 20 July 2007 09:42:40 Michael Gerz wrote: Hmpf wasn't the removal of the const-ness the major reason why my change tracking patch was rejected? Michael You are right. It seems that we need some kind of state machine to run across latex/docbook generation. And the OutputParams is not the answer. Long term, we certainly need to do some major rethinking of the whole latex generation, IMO. The current situation seems very fragile. I'm not sure what the problem is or how to make this easier, but here are some thoughts on this. I think a major part of the problem is that lyx's representation of the document and latex's representation do not always coincide. For example, in LyX's eyes (well, in the .lyx file), the language of a paragraph is set inside the paragraph, and therefore is in effect only until the end of the paragraph. If the next paragraph is in the same language, the language will have to be set inside it again. OTOH, latex sets the language outside the paragraph. This means that the language is set before the first paragraph, and does not have to be reset again if the second paragraph is in the same language. These aren't major differences, but they do mean that there isn't a one-to-one mapping between the .lyx file and the latex file. Given that, during the generation we ideally should have access to two objects: one which represents the current state in terms of LyX, and one which represents the current state in terms of latex. Each of these objects should probably be an *explicit* stack; relying on the call stack will constrain us by forcing the two objects to be pushed/popped at the same time, which may not always be correct, and will also constrain how we decide to divide up the functions between different parts of the generation. Finally, we may also need a third object, which represents the current state of the output mechanism: e.g., the current encoding. Regardless of what LyX or latex thinks the current encoding is (or maybe they don't even care), the output mechanism must know how the character it's about to output is going to be encoded. I'm not sure where CT information would fit in these scheme --- probably in the third object I mentioned. But anyhow, this scheme obviously can't be implemented before 1.5.0 But perhaps the idea can at least help to figure out how this should be dealt within right now, in the current framework. As I said, these are just some thoughts, I'm not sure how sound this is... Dov
Re: [patch] typo in unicodesymbols
Uwe Stöhr wrote: > -0x00a9 "\textcopyright" "textcomp" "" # COPYRIGHT SIGN > +0x00a9 "\\textcopyright" "textcomp" "" # COPYRIGHT SIGN > > Should be > > -0x00a9 "\textcopyright" "textcomp" "" # COPYRIGHT SIGN > +0x00a9 "\\textcopyright" "textcomp" "" # COPYRIGHT SIGN Pardon? Jürgen
Re: [PATCH] CT output (again)
On Friday 20 July 2007 10:34:38 Michael Gerz wrote: > IMHO 14 parameters are enough. Don't you think that a container like > OutputParams is the better solution? > > Michael But not OutputParams. OutputParams are parameters used to control the output, as I said before you want something like OutputState. OutputParams are the public interface and OutputState would be the private interface, there is no need to mix the two even if it seems convenient. -- José Abílio
Re: Slow motion while editing
> I don't know if it is related but with the svn version compiled > yesterday there is a very noticeable lag in typing. Attached is a > file that is causing problems. i have tried your file with rc2 (on linux) and dont see any typing lag. cant try it on svn now - but is it with rc2 better for you ? pavel
Re: [PATCH] CT output (again)
Michael Gerz schrieb: Guys, with Dov's latest patch (#1820) committed, I was able to produce a CT patch that does not touch the present (non-)const-ness of OutputParams. Since I consider this bug a major CT bug (text inside deleted insets is displayed as unchanged text), I would like you to reconsider the patch for 1.5.0. In a certain sense, it is a one-liner because it effects current behavior only with this statement: - Change const & change = pimpl_->lookupChange(i); + Change const & change = runparams.inDeletedInset ? runparams.changeOfDeletedInset +: pimpl_->lookupChange(i); Implementation notes: In order to fix the bug, it is necessary to pass information down the call stack. Prior to #1820, it would have been possible to make a local copy of the (const) outputparams, modify them locally, and pass the modified params down. However, it turns out that Dov needs to pass information _up_. Therefore, IMHO it is not a good idea to create local copies of outputParams in the same method. Instead, I modify the needed parameter at the beginning and reset them at the end (increment/decrement of inDeletedInset). BTW: If you still don't like to add this information to OutputParams, I have to add more parameters to several methods, e.g. to: void Paragraph::Pimpl::simpleTeXSpecialChars(Buffer const & buf, BufferParams const & bparams, odocstream & os, TexRow & texrow, OutputParams & runparams, Font & running_font, Font & basefont, Font const & outerfont, bool & open_font, Change & running_change, Layout const & style, pos_type & i, unsigned int & column, value_type const c) IMHO 14 parameters are enough. Don't you think that a container like OutputParams is the better solution? Michael
[PATCH] CT output (again)
Guys,
with Dov's latest patch (#1820) committed, I was able to produce a CT
patch that does not touch the present (non-)const-ness of OutputParams.
Since I consider this bug a major CT bug (text inside deleted insets is
displayed as unchanged text), I would like you to reconsider the patch
for 1.5.0.
In a certain sense, it is a one-liner because it effects current
behavior only with this statement:
- Change const & change = pimpl_->lookupChange(i);
+ Change const & change = runparams.inDeletedInset ?
runparams.changeOfDeletedInset
+:
pimpl_->lookupChange(i);
Implementation notes:
In order to fix the bug, it is necessary to pass information down the
call stack. Prior to #1820, it would have been possible to make a local
copy of the (const) outputparams, modify them locally, and pass the
modified params down. However, it turns out that Dov needs to pass
information _up_. Therefore, IMHO it is not a good idea to create local
copies of outputParams in the same method. Instead, I modify the needed
parameter at the beginning and reset them at the end
(increment/decrement of inDeletedInset).
Kind regards,
Michael
Index: src/OutputParams.h
===
--- src/OutputParams.h (Revision 19151)
+++ src/OutputParams.h (Arbeitskopie)
@@ -16,6 +16,7 @@
#include "support/types.h"
#include
+#include "Changes.h"
namespace lyx {
@@ -120,6 +121,16 @@
*/
bool inComment;
+ /** Whether we are inside an inset that is logically deleted.
+ * A value > 0 indicates a deleted inset.
+ */
+ int inDeletedInset;
+
+ /** The change information of the outermost, logically deleted inset.
+ * changeOfDeletedInset shall only be evaluated if inDeletedInset > 0.
+ */
+ Change changeOfDeletedInset;
+
/** allow output of only part of the top-level paragraphs
* par_begin: beginning paragraph
*/
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp (Revision 19151)
+++ src/Paragraph.cpp (Arbeitskopie)
@@ -726,6 +726,11 @@
break;
}
+ if (lookupChange(i).type == Change::DELETED) {
+ if( ++runparams.inDeletedInset == 1)
+runparams.changeOfDeletedInset = lookupChange(i);
+ }
+
if (inset->canTrackChanges()) {
column += Changes::latexMarkChange(os, bparams, running_change,
Change(Change::UNCHANGED));
@@ -801,6 +806,10 @@
} else {
column += os.tellp() - len;
}
+
+ if (lookupChange(i).type == Change::DELETED) {
+ --runparams.inDeletedInset;
+ }
}
break;
@@ -2039,7 +2048,8 @@
runparams.moving_arg);
}
- Change const & change = pimpl_->lookupChange(i);
+ Change const & change = runparams.inDeletedInset ? runparams.changeOfDeletedInset
+ : pimpl_->lookupChange(i);
if (bparams.outputChanges && runningChange != change) {
if (open_font) {
Index: src/OutputParams.cpp
===
--- src/OutputParams.cpp (Revision 19151)
+++ src/OutputParams.cpp (Arbeitskopie)
@@ -22,7 +22,7 @@
local_font(0), encoding(enc), free_spacing(false), use_babel(false),
linelen(0), depth(0),
exportdata(new ExportData),
- inComment(false),
+ inComment(false), inDeletedInset(0), changeOfDeletedInset(Change::UNCHANGED),
par_begin(0), par_end(0),
dryrun(false)
{}
Re: [Cvslog] r19150 - in /lyx-devel/trunk: RELEASE-NOTES src/Font.cpp ...
On Friday 20 July 2007 09:42:40 Michael Gerz wrote: > Hmpf wasn't the removal of the const-ness the major reason why my > change tracking patch was rejected? > > Michael You are right. It seems that we need some kind of state machine to run across latex/docbook generation. And the OutputParams is not the answer. -- José Abílio
Re: [patch] Re: lyx2lyx back convertion to 1.4
On Friday 20 July 2007 07:33:20 Jürgen Spitzmüller wrote: > Jürgen Spitzmüller wrote: > > Which turned out to be another critical bug :-( > > http://bugzilla.lyx.org/show_bug.cgi?id=4046 > > Here's the fix. José, this was introduced with your latest cleanup. > > Jürgen OK. I suspected about this fix but I did not had time to search the solution. -- José Abílio
Re: [patch] typo in unicodesymbols
On Friday 20 July 2007 07:17:30 Jürgen Spitzmüller wrote: > OK? > > Jürgen Sure. -- José Abílio
bug 4040 - flashcards layout
Hi, I just uploaded a patch for the flashcards package to make it work with newer latex versions. It solves the a4paper issue. Uwe, which other stuff do you have to specify? Do you mean using lyx or just latex? I try to help out where I can here... (at last something where I can help maybe :-) ) Jonathan
Re: Slow motion while editing
Darren Freeman wrote: On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote: I am sorry to hear that but we have no way to help you without nothing where the slowdown is. We need profile results! So, if you want to have a faster 1.5, please try to provide some. I would love that but I'm currently without income owing to my thesis not being written yet :) If you can find the time to compile from a svn, compiling with profiling enabled is supposed to be easy on linux (with --enable-profile or something). I suspect it is related to the size of the document. No, it shouldn't be. Abdel.
Re: Slow motion while editing
Darren Freeman schrieb: On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote: I am sorry to hear that but we have no way to help you without nothing where the slowdown is. We need profile results! So, if you want to have a faster 1.5, please try to provide some. Unfortunately in cases like this the user isn't keen to publish their document for the mailing list either :) You could make your document unreable, e.g., by replacing all "b", "c", ... by "a", while preserving its structure. Michael
Re: [Cvslog] r19150 - in /lyx-devel/trunk: RELEASE-NOTES src/Font.cpp ...
[EMAIL PROTECTED] schrieb: Modified: lyx-devel/trunk/src/Paragraph.cpp URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Paragraph.cpp?rev=19150 == --- lyx-devel/trunk/src/Paragraph.cpp (original) +++ lyx-devel/trunk/src/Paragraph.cpp Fri Jul 20 03:28:20 2007 @@ -191,7 +191,7 @@ /// void simpleTeXSpecialChars(Buffer const &, BufferParams const &, odocstream &, - TexRow & texrow, OutputParams const &, + TexRow & texrow, OutputParams &, Font & running_font, Font & basefont, Font const & outerfont, @@ -662,7 +662,7 @@ BufferParams const & bparams, odocstream & os, TexRow & texrow, -OutputParams const & runparams, +OutputParams & runparams, Font & running_font, Font & basefont, Font const & outerfont, Hmpf wasn't the removal of the const-ness the major reason why my change tracking patch was rejected? Michael
Re: Slow motion while editing
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote: > I am sorry to hear that but we have no way to help you without nothing > where the slowdown is. We need profile results! So, if you want to have > a faster 1.5, please try to provide some. I would love that but I'm currently without income owing to my thesis not being written yet :) I suspect it is related to the size of the document. Profiling on my thesis would be a good idea I'm sure, but I have to find the time... Unfortunately in cases like this the user isn't keen to publish their document for the mailing list either :) Shouldn't we have a suite of test documents? Such as generating a really big LyX file using for loops to populate the paragraphs, or including heaps of floats, insets, etc. Have fun, Darren
Re: Slow motion while editing
On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote: > Guillaume Pothier wrote: > > Abdel, I tried your patch and it actually makes things noticeably slower! > > Too bad! I guess the performance depends on the pixmap painting > capabilities of your system. On Windows and I think Mac, it is > definitely faster. What does that say about our systems... that Win and Mac require help to run fast, or that X11 can't be helped :) Have fun, Darren
Re: Slow motion while editing
Darren Freeman wrote: On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote: Guillaume Pothier wrote: Ok, I also tried with --disable-stdlib-debug and I don't notice any difference. Could you please try this patch? No noticeable effect, on the same document both with and without the patch, scrolling lag is around 0.5 s, and mashing the keyboard with maybe 30 chars into an empty paragraph, gave a couple of s of catchup time. I am sorry to hear that but we have no way to help you without nothing where the slowdown is. We need profile results! So, if you want to have a faster 1.5, please try to provide some. Abdel.
Re: Slow motion while editing
Guillaume Pothier wrote: Abdel, I tried your patch and it actually makes things noticeably slower! Too bad! I guess the performance depends on the pixmap painting capabilities of your system. On Windows and I think Mac, it is definitely faster. Abdel.
