CVS lyx: Weird behavior of End key
Hi folks, When I press the End key, sometimes the cursor ends up at the last character *before* the end of the line. For example, in the following line, imagine that the | symbol is where the cursor is: The |quick brown fox jumped over the lazy dog. I hit the End key: The quick brown fox jumped over the lazy dog|. This is new, as of a few days ago. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: CVS lyx: Weird behavior of End key
Kayvan A. Sylvan wrote: > Hi folks, > > When I press the End key, sometimes the cursor ends up at the last > character *before* the end of the line. > > For example, in the following line, imagine that the | symbol is where > the cursor is: > > > The |quick brown fox jumped over the lazy dog. > > I hit the End key: > > The quick brown fox jumped over the lazy dog|. > > This is new, as of a few days ago. Short explanation: the cause is that there was two bugs cancelling each other and I removed one of them. The fix shouldn't be hard. Longer explanation: endpos() returned a 2-past-the-end position for the last row in the paragraph (and a 1-past-the-end for all other rows). This caused a lot of weird problems and was solved. The End key was *hacked* to go to 1 char before the end (position endpos() - 1) because in the middle of the paragraph rows normally end with a space. Because of the bug above this worked also with last rows. Look here http://marc.theaimsgroup.com/?t=10625218817&r=1&w=2 Regards, Alfredo
Re: [PATCH] qt branches fix
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | Juergen Spitzmueller wrote: > >> Juergen Spitzmueller wrote: >>> BTW do you have any idea why (un)collapsing branches sets the document's >>> state to "changed"? >> >> Actually this happens with any collapsable inset (ERT, footnote, note >> etc.). > | I believe it is intended, because the state collapsed/uncollapsed gets | saved. there is a bug on bugzilla about this. And the document is not logically changing so this "changed" should imo not happen. -- Lgb
Re: [PATCH] qt branches fix
[EMAIL PROTECTED] (Juergen Spitzmueller) writes: | Alfredo Braunstein wrote: >> I believe it is intended, because the state collapsed/uncollapsed gets >> saved. > | I see. Yes, that makes sense. No... it does not... -- Lgb
Re: [PATCH] qt branches fix
Lars Gullik Bjønnes wrote: > | I believe it is intended, because the state collapsed/uncollapsed gets > | saved. > > there is a bug on bugzilla about this. And the document is not > logically changing so this "changed" should imo not happen. > Mmm... ok. Why don't you apply John's patch on bugzilla then? Alfredo
cvs complie error
I just saw the following in the LyX Roadmap, "theorem support, allow the user to create its own kinds of theorem like environments" (drowling) I imediatly downloaded the latest CVS version. (b.t.w.) What is the current status of the theorem support? Anyway, here is the result of the compilation g++-3.0 -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -I/usr/X11R6/include -g -O -W -Wall -c math_mathmlstream.C -MT math_mathmlstream.lo -MD -MP -MF .deps/math_mathmlstream.TPlo math_mathmlstream.C: In destructor `WriteStream::~WriteStream()': math_mathmlstream.C:48: no match for `std::basic_ostream >& << char' operator ../../src/lyxfont.h:310: candidates are: std::ostream& operator<<(std::ostream&, const LyXFont&) ../../src/lyxfont.h:434: std::ostream& operator<<(std::ostream&, LyXFont::FONT_MISC_STATE) math_mathmlstream.h:72: WriteStream& operator<<(WriteStream&, const MathAtom&) math_mathmlstream.h:74: WriteStream& operator<<(WriteStream&, const MathArray&) .. 2000 similar lines math_mathmlstream.C:315: OctaveStream& operator<<(OctaveStream&, const char*) math_mathmlstream.C:322: OctaveStream& operator<<(OctaveStream&, char) math_mathmlstream.C:329: OctaveStream& operator<<(OctaveStream&, int) math_inset.h:261: std::ostream& operator<<(std::ostream&, const MathAtom&) math_data.h:175: std::ostream& operator<<(std::ostream&, const MathArray&) make[3]: *** [math_mathmlstream.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 I guess this can have something to do with me usig an old system! The compilation with the version 2.95.4 compiler, I got error for not finding . My system! (using debian 3.0 linux (stable) Configuration Host type: i686-pc-linux-gnu Special build flags:warnings assertions xforms-image-loader compression C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++-3.0 (3.0.4) C++ Compiler flags: -g -O -W -Wall Linker flags: XForms Frontend: libXpm version: 4.11 libforms version: 0.89.5
new layout files for g-brief2
Hello I just created layout files and examples for the g-brief2 latex style. This style is the successor of g-brief. Its more flexible and looks nicer Please send me comments. Please apply to lyx-cvs. You will find the files here: http://www.fkurth.de/~felix/g-brief2.tgz More Information and Examples about g-brief2 are here: http://www.ctan.org/tex-archive/macros/latex/contrib/g-brief/ thanks Felix -- Felix Kurth pgp public key: http://www.fkurth.de/keys/felix.fkurth.asc key fingerprint: D401 DCF8 2BF8 50DF 2FAD 8136 C29B 83EE C0A1 F2AD pgp0.pgp Description: signature
Re: cvs complie error
Gandalf GreyHair wrote: > Anyway, here is the result of the compilation > > g++-3.0 -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost > -I/usr/X11R6/include -g -O -W -Wall -c math_mathmlstream.C -MT > math_mathmlstream.lo -MD -MP -MF .deps/math_mathmlstream.TPlo > > > math_mathmlstream.C: In destructor `WriteStream::~WriteStream()': > math_mathmlstream.C:48: no match for `std::basic_ostreamstd::char_traits >& << char' operator > ../../src/lyxfont.h:310: candidates are: std::ostream& >operator<<(std::ostream&, const LyXFont&) Adding #include to the .C file should resolve the problem. Once you get things to compile please post us a diff (cvs diff > compile.diff) and we'll roll the changes into the tree. Regards, -- Angus
Re: [PATCH] qt branches fix
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> | I believe it is intended, because the state collapsed/uncollapsed gets >> | saved. >> >> there is a bug on bugzilla about this. And the document is not >> logically changing so this "changed" should imo not happen. >> > | Mmm... ok. Why don't you apply John's patch on bugzilla then? time time time -- Lgb
Re: InsetExternal should work again...
Angus Leeming wrote: > The attach patch (committed) gets rid of th dynamic_casts in > InsetExternal and generally cleans things up a little. > > Christian, could you see whether it now works with gcc 2.96? Compiles and works with gcc 2.95.4 + stlport. Georg
Re: [patch] tex2lyx improvements
Asger Kunuk Alstrup wrote:
> Just a clarifying question: How well do we handle a round-trip of the
> User guide now? I.e. open the user guide, export to LaTeX, then use
> your patched version of tex2lyx to import the LaTeX. Then export again,
> and compare to the original export. Diff is your friend - especially
> ignoring white space.
The roundtrip works quite well.
The main problems are:
- Each loop adds stuff to the preamble
- Something is wrong with nesting lists, see \subsubsection{Example \#1: The
Six-fold Way and Mixed Nesting}. I don't understand how the nesting stuff
should work, and I have only simple nested lists in my document, so I won't
do anything on that.
- The problem Andre mentioned with commands taking an optional argument.
- Unmatched begin_layout / end_layout pairs inside a table
I have more trouble with non lyx-generated documents. The main problem is
the fact that Parser::tokenize() unconditionally removes all whitespace
after a command. parse_text() then adds unconditionally whitespace at some
places. This makes it impossible to parse verbatim environments. Another
problem is that there are commands where whitespace matters, for example
after a \hspace{}.
I started to implement a strategy where Parser::tokenize() does not remove
any whitespace. This is instead shifted to parse_text(), where it is only
removed if it is needed. This adds some lines to text.C. It is not finished
yet, but works already better than the original version.
Comments? If nobody has objections, I'll finish this.
Georg
Re: [patch] tex2lyx improvements
Jean-Marc Lasgouttes wrote:
> Georg> - handle optional arg to \item as ERT in itemize environment,
> Georg> since LyX does not support it directly
>>> I do not like the way this one is implemented. You have all the
>>> information you need in the layout file. Instead of testing against
>>> "itemize", you need something like (untested) if
>>> (context.layout->labeltype != LABEL_MANUAL) {
>
> Georg> I don't really know how the layout files work, but it sounds
> Georg> sensible.
>
> Let me know is it does not work.
It does.
Georg
Re: [patch] tex2lyx improvements
Georg Baum wrote:
> - Each loop adds stuff to the preamble
Yes. The preamble stuff has no intelligence at all. It just dumps
output.
> I have more trouble with non lyx-generated documents. The main
> problem is the fact that Parser::tokenize() unconditionally removes
> all whitespace after a command. parse_text() then adds
> unconditionally whitespace at some places. This makes it impossible
> to parse verbatim environments. Another problem is that there are
> commands where whitespace matters, for example after a \hspace{}.
> I started to implement a strategy where Parser::tokenize() does not
> remove any whitespace. This is instead shifted to parse_text(),
> where it is only removed if it is needed. This adds some lines to
> text.C. It is not finished yet, but works already better than the
> original version.
>
> Comments? If nobody has objections, I'll finish this.
André has noted in the past that the current implementation is a hack
that 'worked well enough for him'. I think that you should keep going
with the 'clean' solution that you describe.
Regards,
Angus
Re: cvs complie error
Gandalf GreyHair wrote: > I guess this can have something to do with me usig an old system! The > compilation with the version 2.95.4 compiler, I got error for not finding > . The STL of gcc 2.95 ist too old. > My system! (using debian 3.0 linux (stable) Me too (with updated qt3 from ftp.kde.org). After installing libstlport4.5-dev (included in woody), the following configure command worked for me: QTDIR=/usr/share/qt3 ./configure --with-frontend=qt --enable-maintainer-mode --with-extra-inc=/usr/include/stlport CXXFLAGS="-DCXX_GLOBAL_CSTD -ftemplate-depth-30 -nostdinc++" LDFLAGS="-lstlport -lm" (This is one line, the line breaks are inserted by the mailer) Georg
Re: InsetExternal should work again...
Georg Baum wrote: >> Christian, could you see whether it now works with gcc 2.96? > > Compiles and works with gcc 2.95.4 + stlport. Many thanks, Georg -- Angus
Re: cvs complie error
> to the .C file should resolve the problem. Once you get things to > compile please post us a diff (cvs diff > compile.diff) and we'll > roll the changes into the tree. Here are some changes I had to do. I guess that some compilers can figure it out by it self that it needs to include and such things. My old compiler could not, which is a good thing! I have attached the cvs diff > mypatch.diff to this posting. But there are still errors! g++-3.0 -g -O -W -Wall -o tex2lyx FloatList.o Floating.o counters.o lyxlayout.o lyxtextclass.o lyxlex.o lyxlex_pimpl.o boost.o context.o gettext.o lyxfont.o texparser.o tex2lyx.o preamble.o math.o table.o text.o ../support/.libs/libsupport.a ../../boost/libs/regex/src/.libs/libboostregex.a -lz ../support/.libs/libsupport.a(filetools.o): In function `lyx::support::NormalizePath(std::basic_string, std::allocator > const&)': /home/gunnar/LyXDEVEL/lyx-devel/src/support/filetools.C:695: undefined reference to `boost::RegEx::RegEx[in-charge](char const*, bool)' ../support/.libs/libsupport.a(filetools.o): In function `lyx::support::NormalizePath(std::basic_string, std::allocator > const&)': Regards, Gunnar Lindholm. ? mypatch.diff ? q Index: po/POTFILES.in === RCS file: /cvs/lyx/lyx-devel/po/POTFILES.in,v retrieving revision 1.362 diff -r1.362 POTFILES.in 172a173 > src/insets/render_preview.C 192d192 < src/support/path_defines.C Index: src/frontends/controllers/ControlPreamble.h === RCS file: /cvs/lyx/lyx-devel/src/frontends/controllers/ControlPreamble.h,v retrieving revision 1.12 diff -r1.12 ControlPreamble.h 15c15 < --- > #include Index: src/frontends/controllers/ControlSendto.h === RCS file: /cvs/lyx/lyx-devel/src/frontends/controllers/ControlSendto.h,v retrieving revision 1.10 diff -r1.10 ControlSendto.h 15c15 < --- > #include Index: src/frontends/xforms/XMiniBuffer.h === RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/XMiniBuffer.h,v retrieving revision 1.16 diff -r1.16 XMiniBuffer.h 17a18 > #include Index: src/graphics/GraphicsTypes.C === RCS file: /cvs/lyx/lyx-devel/src/graphics/GraphicsTypes.C,v retrieving revision 1.12 diff -r1.12 GraphicsTypes.C 11a12 > #include Index: src/insets/insetbibitem.C === RCS file: /cvs/lyx/lyx-devel/src/insets/insetbibitem.C,v retrieving revision 1.34 diff -r1.34 insetbibitem.C 12c12 < --- > #include Index: src/insets/insetcite.C === RCS file: /cvs/lyx/lyx-devel/src/insets/insetcite.C,v retrieving revision 1.67 diff -r1.67 insetcite.C 13c13 < --- > #include Index: src/insets/insetfootlike.C === RCS file: /cvs/lyx/lyx-devel/src/insets/insetfootlike.C,v retrieving revision 1.30 diff -r1.30 insetfootlike.C 11a12 > #include Index: src/insets/insetref.C === RCS file: /cvs/lyx/lyx-devel/src/insets/insetref.C,v retrieving revision 1.75 diff -r1.75 insetref.C 10a11 > #include Index: src/mathed/math_mathmlstream.C === RCS file: /cvs/lyx/lyx-devel/src/mathed/math_mathmlstream.C,v retrieving revision 1.39 diff -r1.39 math_mathmlstream.C 12c12 < --- > #include
