In LyX 1.4.4svn, Fedora Core 4, I find that when I view dvi files
using the "Show changes in output" facility, the dvipost utility is
not automatically run so the changes are not coloured. I have created
a "Change DVI" type that has "dvipost $$i $$o" as its converter.
However, surely LyX should b
I have been noticing that LyX 1.4.4svn outputs invalid latex in "Show
changes in output" in a number of situations. One simple one is that
it outputs
\section*{\changestart{}Ackowledgements\changeend{}
which causes errors. It should instead output:
\changestart{}\section*{Ackowledgements}\
On Jan 10, 2007, at 4:28 PM, Georg Baum wrote:
Am Mittwoch, 10. Januar 2007 10:39 schrieb Abdelrazak Younes:
This I agree is a good goal. I was afraid that you intended to
replaced
the internal Clipboard for all platforms. If that is not the case
then I
think this will be a very good contr
Georg Baum wrote:
> It could, and it would probably not be more than 50 additional lines of
> code
Cool. Meanwhile, I filed an enhancement request:
http://bugzilla.lyx.org/show_bug.cgi?id=3096
Jürgen
> "José" == José Matos <[EMAIL PROTECTED]> writes:
>> José, can this version go in please?
José> Assuming it works I like your solution. :-) Does anyone has a
José> strong objection to this patch?
As Georg said, this is not something we are supposed to add now, but
since it is done...
A
On Wednesday 10 January 2007 9:33 pm, Georg Baum wrote:
> Ah, now I know the problem: If we add string literals to document.body we
> need to prefix them with u to get unicode string literals: u'bla'. Now I
> know where to search.
That is enough to drive anyone (read me) crazy. :-)
> Georg
--
On Wednesday 10 January 2007 9:28 pm, Georg Baum wrote:
>
> I cleaned the patch up and tested it a bit more. The clipboard does now
> only go through a file if lyx2lyx is used. I also removed some debugging
> stuff and put the remaining one in an if(debugging), because that avoids
> some string con
Am Mittwoch, 10. Januar 2007 01:00 schrieb Enrico Forestieri:
> No, the problem is that something is messed up. Apparently,
> document.body[i] may already be in unicode format.
Yes, that is done in LyX.py.
> See for example:
> http://www.red-mercury.com/blog/eclectic-tech/python-mystery-of-the-d
Am Mittwoch, 10. Januar 2007 10:39 schrieb Abdelrazak Younes:
> This I agree is a good goal. I was afraid that you intended to replaced
> the internal Clipboard for all platforms. If that is not the case then I
> think this will be a very good contribution to 1.5 new Clipboard
> functionality.
Am Mittwoch, 10. Januar 2007 22:08 schrieb Dov Feldstern:
> *) Apparently Qt still isn't working perfectly, either --- why is it so
> dependent on the locale settings? It seems to me that the locale setting
> should not affect whether or not bidi is applied.
I believe that _we_ are causing qt to
Guy Rutenberg wrote:
Hi,
Further more when typing hebrew when LC_CTYPE is configured to a valid
value, and not setting the text as "language hebrew" in LyX (that causes
lyx
to treat the Hebrew as English or the default language) the hebrew text is
displayed right,
Totally correct? Or just t
Georg Baum <[EMAIL PROTECTED]> writes:
> > I was a little scared by the changes found in development/FORMAT, and
> > I'm starting to think that it would be easier to parse the generated
> > TeX directly.
> Definitely not. Proper TeX parsing is a nightmare.
That's surely true. But it (TeX) is a s
Given that quitWriteAll() is called in all the cases above, maybe
you can stick there your code?
Without looking at the code, maybe,
1. quiteWriteAll() may not have a cursor. (Can be called in non-GUI mode?)
2. I will have to switch to a buffer, set cursor to get the pid. It is
much easier to
On Thu, Jan 11, 2007 at 02:29:27PM +1800, Bo Peng wrote:
> > Maybe I don't know what you exactly mean, but whatever the method
> > you use to quit (menu or click on the X in the right upper corner),
> > GuiView::closeEvent() is called. There you can already find some
> > code for saving geometry an
Maybe I don't know what you exactly mean, but whatever the method
you use to quit (menu or click on the X in the right upper corner),
GuiView::closeEvent() is called. There you can already find some
code for saving geometry and cursor position of opened files.
What I meant was that GuiView::clos
On Thu, Jan 11, 2007 at 12:18:19PM +1800, Bo Peng wrote:
> WHY CANNOT WE take the time to fire LFUN_BUFFER_CLOSE, and
> LFUN_WINDOW_CLOSE when lyx exists? When lyx takes shortcuts to quit,
> proper cleanup in these CLOSE events may be bypassed.
Maybe I don't know what you exactly mean, but whatev
Hi,
I did further testing on the issue and found out that the problem occurs
only when the locale that is set in LC_CTYPE (directly or via LANG) is a
valid locale.
For example the display of Hebrew will be wrong if LC_CTYPE is set to en_US
but it will be correct when set to he, en, he_US or any o
On Sun, Jan 07, 2007 at 09:35:45AM +0100, Tribulations Parallèles wrote:
> On Sunday 07 January 2007 00:22, Tribulations Parallèles wrote:
> > Hi everybody
> >
> > When I try to include this EPS figure in development version of LyX (fresh
> > SVN devel update), LyX crashes:
> >
> > http://paratribu
This patch uses both pit and id to locate a bookmark.
1. both pit and id are used to locate a position. Pit is saved by session.
2. moveToPosition now returns id and pit of the new position and
update bookmark if necessary. These happens:
* when id is invalid (Uwe's case), pit is used, and boo
Hi,
please find attached some patches (the "diff.out" file) for LyX-1.4.3.
1. the patch to "src/insets/insetlatexaccent.C" (author Jean-Marc
Lasgouttes) solves the problem with "special caron" for some special
Czech and Slovak characters (d,l,L,t) - LaTeX recognizes them with the
standard
On Jan 10, 2007, at 6:00 AM, Abdelrazak Younes wrote:
Bennett Helm wrote:
On Mac, at least, I have some arrow navigation problems with
today's 1.5svn.
Previously, I reported that pressing down-arrow causes the cursor
to jump 2 lines down. That has now been fixed. However, now the
cursor s
lamikr wrote:
Hi
I have now used lyx for a while for writing my master thesis and I am
now quite happy to the it's usage with bibtex, separation of chapters to
own includeable files, etc... While writing my text and thinking what to
write, I have however often noticed that I want to separate the
Andrea Censi wrote:
> Hello to all, and happy new year!
>
> For my own fun (something related to this:
> http://maruku.rubyforge.org/) I want to parse LyX files. I am only
> interested in basic stuff (paragraphs, lists, inline and block math)
Note that all math is directly stored as TeX. I would
Jürgen Spitzmüller wrote:
> Abdelrazak Younes wrote:
>> This I agree is a good goal. I was afraid that you intended to replaced
>> the internal Clipboard for all platforms.
That is Bo, not me.
>> If that is not the case then I
>> think this will be a very good contribution to 1.5 new Clipboard
Hello to all, and happy new year!
For my own fun (something related to this:
http://maruku.rubyforge.org/) I want to parse LyX files. I am only
interested in basic stuff (paragraphs, lists, inline and block math)
I have some questions:
1) is there already a Ruby parser for LyX? ("Ruby" as in
htt
Abdelrazak Younes wrote:
> This I agree is a good goal. I was afraid that you intended to replaced
> the internal Clipboard for all platforms. If that is not the case then I
> think this will be a very good contribution to 1.5 new Clipboard
> functionality. An html formatted Clipboard would be nice
Bennett Helm wrote:
On Mac, at least, I have some arrow navigation problems with today's
1.5svn.
Previously, I reported that pressing down-arrow causes the cursor to
jump 2 lines down. That has now been fixed. However, now the cursor
seems to "remember" a particular horizontal position when m
Georg Baum wrote:
Abdelrazak Younes wrote:
Quite frankly I am not very confident that you can achieve the same
performance as the internal Clipboard.
I did not aim for that. And note that I currently have a lot of debug
output, and also some unneeded conversions string -> stringstream ->
stri
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
However, now the cursor seems to "remember" a particular horizontal
position when moving up or down in a document when using the arrow
keys or page-up/down. That is, if I click the mouse somewhere in
the
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
Edwin> Jean-Marc Lasgouttes wrote:
>>> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
>>
Edwin> Abdelrazak Younes wrote:
Could you profile this instead: lyx -e text UserGuide.lyx
>>
Edwin> another try:
>> Since you are using
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> However, now the cursor seems to "remember" a particular horizontal
>> position when moving up or down in a document when using the arrow
>> keys or page-up/down. That is, if I click the mouse somewhere in
>> the document windo
Georg Baum wrote:
Bo Peng wrote:
I do not think you need to do lyx2lyx stuff. Technically speaking,
what we need is boost::serialization which is quite fast from my
experience.
Please note that I am still not interested at all in replacing the internal
clipboard. What I want is a stable forma
[EMAIL PROTECTED] wrote:
I agree that a stack of bookmarks has limited use, because the poor user has
no idea of what boomark #5 actually is at a given time (a moving target).
That is why I display filename of a bookmark. Previously, the poor
user has to face ice-cold bookmark 1/2/3/4/5.
Well
Bennett Helm wrote:
On Mac, at least, I have some arrow navigation problems with today's
1.5svn.
Previously, I reported that pressing down-arrow causes the cursor to
jump 2 lines down. That has now been fixed.
Really? Nothing has changed in this field recently AFAIK. This is good
anyway ;-)
Jean-Marc Lasgouttes wrote:
"Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
Edwin> Abdelrazak Younes wrote:
Could you profile this instead: lyx -e text UserGuide.lyx
Edwin> another try:
Since you are using oprofile, you could try to obtain a call graph
instead of a flat profile. This is
On Wednesday 10 January 2007 8:03 am, Jean-Marc Lasgouttes wrote:
>
> Well, the labels (which are an existing latex construct, but also
> anchors in docbook I guess) can be seen as bookmarks that are saved
> with the document. Currently Insert>Crossrefs is the main way to
> navigate through them [g
Uwe Stöhr wrote:
> I see me commits in svnlog as well as in trac:
> http://www.lyx.org/trac/timeline
But probably not in the private svnlog mailing list where every developer
was subscribed to by Lars.
Georg
Bo Peng wrote:
> I do not think you need to do lyx2lyx stuff. Technically speaking,
> what we need is boost::serialization which is quite fast from my
> experience.
Please note that I am still not interested at all in replacing the internal
clipboard. What I want is a stable format to interoperat
Abdelrazak Younes wrote:
> Quite frankly I am not very confident that you can achieve the same
> performance as the internal Clipboard.
I did not aim for that. And note that I currently have a lot of debug
output, and also some unneeded conversions string -> stringstream ->
string, so I believe t
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> After the unicode merge to trunk in summer we discussed the
Georg> Of course that means that all "default" documents that are
Georg> already converted to 1.5 would not be valid anymore.
We can afford that.
Georg> IMO this is better
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
Edwin> Abdelrazak Younes wrote:
>> Could you profile this instead: lyx -e text UserGuide.lyx
Edwin> another try:
Since you are using oprofile, you could try to obtain a call graph
instead of a flat profile. This is possible if your linux
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> I think that the LIFO -> FIFO change should be enough.
Bo> This is very simple, and has been done. I am not going to add
Bo> support for bookmark-save 2/3/4/5 right now, not because it is
Bo> difficult to do, but because I dislike the menu items
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> If we are going to this route, we should stop a bit and remember
>> that we already have something named label, and it is probably not
>> necessary to implement them _again_.
Bo> What exactly is this label? I can see inset->label that actually
43 matches
Mail list logo
