Re: texlive as support for lyx

On Sat, Jan 13, 2007 at 09:38:41AM +0100, abdelkader belahcene wrote: > Hi, > since the new available latex on linux, will be texlive instead of > tetex, I think it 's time to support the texlive instead of tetex. > [ Now the required latex for lyx 1.4.2 (is tetex) ] or I am wrong ?? AFAIK LyX

Re: [PATCH] caching translated string

Peter Kümmel wrote: Maybe this helps against the crashes, it then there will be a copy again: [...] - return from_ascii(m); + return empty_string; + CacheType::iterator it = cache_.find(m); + if (it != cache_.end()) { +

Re: inputencoding "default" again

Dov Feldstern wrote: > Georg Baum wrote: > >> I propose to change the conversion of files with "default" inputencoding >> to be the same as with "auto", together with the corresponding changes in >> LyX itself. The only difference between "auto" and "default" in LyX 1.5 >> would then be that

Re: [patch] fix bug 2721 now with attached patch

Uwe Stöhr wrote: > [1 > ** WARNING ** Unparsed material at end of special ignored. > Current input buffer is -->! /landplus90 true store<-- > ] > > This can be ignored this has no consequences an tells that the input DVI > file is in landscape. When this message doesn't appear dvipdfm doesn't >

Re: Fix bug 3092.

I agree this has nothing to do here but we have to ask this question to the user nevertheless, don't we? So where is this part of the code transferred? quitWriteBuffer() and close() are almost identical. By calling LFUN_BUFFER_CLOSE, close() is called instead. So this means that the user

FS Encoding error

Georg, Enrico, something is wrong with the file encoding in Buffer::save(). If I save changes to an (existing) file which is located in a path containing German Umlauts (Windows), an exception is thrown. The exception message isn't very useful. I says that the copy operation failed :-( The

Re: Do we support user defined layout?

[EMAIL PROTECTED] writes: | On Fri, 12 Jan 2007, Georg Baum wrote: | | > Abdelrazak Younes wrote: | > | >> Georg Baum wrote: | >>> They are not different than the translatable ones. The only problem I can | >>> imagine is that the cache could get out of date if somebody changes the | >>> layout

Re: [patch] fix bug 2721 now with attached patch

Jürgen wrote: dvips is for example also the default driver of hyperref and therefore also used when producing DVI and PDF files. But dvipdfm takes the ready DVI-file so it is driver independent. I don't understand. dvips is a converter from dvi to PostScript, dvipdfm is a converter from dvi

Re: FS Encoding error

Michael Gerz wrote: > Georg, Enrico, > > something is wrong with the file encoding in Buffer::save(). If I save > changes to an (existing) file which is located in a path containing > German Umlauts (Windows), an exception is thrown. The exception message > isn't very useful. I says that the

Re: par breaking

Abdelrazak Younes <[EMAIL PROTECTED]> writes: | private: | /// | string lang_; | + typedef std::map CacheType; | + /// Internal cache for gettext translated strings. | + /// This is needed for performance reason within \c updateLabels() | + ///

Re: [patch] fix bug 2721 now with attached patch

Uwe Stöhr wrote: > But the entry in the LaTeX-file has to be made in bufferparams.C. I'm a > code newbie so can you help me here? I would add a variable to store the > information what converter is used. How can this variable later be used for > bufferparams.C? I think you'd need to add a

Re: another small bug for status 1.5.x

On Jan 13, 2007, at 7:37 AM, Georg Baum wrote: Am Freitag, 12. Januar 2007 01:10 schrieb Bennett Helm: LyXFunc::dispatch: cmd: action: 15 arg: 'paragraph' x: 0 y: 0 LyXFunc::dispatch: primary-selection-paste [15] is disabled at this This is of course wrong. I used

Re: FS Encoding error

Georg, I am working on an alternative patch right now that fixes this and another bug (regarding backup failure). Give me some time to polish it. Michael Georg Baum schrieb: Michael Gerz wrote: Georg, Enrico, something is wrong with the file encoding in Buffer::save(). If I save

Re: Fix bug 3092.

Peter Kümmel <[EMAIL PROTECTED]> writes: | Bo Peng wrote: | > What I meant is something like follows. The patch does not work | > correctly yet, but shows my point. | > | > 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll. | > | > 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE | > | >

Re: Fix bug 3092.

Bo Peng wrote: I agree this has nothing to do here but we have to ask this question to the user nevertheless, don't we? So where is this part of the code transferred? quitWriteBuffer() and close() are almost identical. By calling LFUN_BUFFER_CLOSE, close() is called instead. Ahhh... very

Re: par breaking

Lars Gullik Bjønnes wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: | private: | /// | string lang_; | + typedef std::map CacheType; | + /// Internal cache for gettext translated strings. | + /// This is needed for performance reason within \c

[patch] fix bug 2418

The fix for this is quite simple: call ImageMagick with an additional parameter. The parameter only has an effect when at least mageMagick 6.2.6-4 is installed, for older versions it does nothing and keeps the current situation. The fix is included in my win builds for ten months now, so

Re: slow opening of docs

On Tue, Jan 09, 2007 at 07:52:10PM +0100, Edwin Leuven wrote: > Abdelrazak Younes wrote: > >Could you profile this instead: > >lyx -e text UserGuide.lyx > > another try: > > % cumulative self self total > time seconds secondscalls ms/call ms/call name > 16.00

Re: FS Encoding error

Hi, this patch fixes the encoding problem in the same way as Georg's patch. However, I also fixed a potential problem that may occur if no backup can be made successfully and I used proper variable names. Folks, could someone please check this on Linux? A second Windows expert would be

Re: [Cvslog] r16597 - /lyx-devel/trunk/src/dociterator.h

On Fri, Jan 12, 2007 at 11:09:03PM +0100, Abdelrazak Younes wrote: > Andre Poenitz wrote: > >Does this actually help? > > > >I would have expected that moving the method definition to the header > >would have been needed, too (possiby causing additional header pulled > >in) > > Year, that's what

accept/reject all changes & undo

Hi, invoking "accept/reject all changes" accidentally can be a nightmare, because you have to run "undo" as often as there are different changes in the document. The technical reason for this is that these LFUNs iteratively look for the next change in the document and accept/reject each of

Re: [Cvslog] r16597 - /lyx-devel/trunk/src/dociterator.h

Andre Poenitz wrote: On Fri, Jan 12, 2007 at 11:09:03PM +0100, Abdelrazak Younes wrote: Andre Poenitz wrote: Does this actually help? I would have expected that moving the method definition to the header would have been needed, too (possiby causing additional header pulled in) Year, that's

Re: Remaining selection/clipboard problems: How to proceed

Now that the clipboard works again on all platforms I give here a summary of the current status. Am Freitag, 5. Januar 2007 17:05 schrieb Georg Baum: > Let's start with our internal clipboard stack: This is advertised to the > user in the "paste recent" menu. If you know this it suddenly makes

Re: [patch] fix bug 2418

Am Samstag, 13. Januar 2007 18:37 schrieb Uwe Stöhr: > Can you please test it on Linux as well? Sorry, my imagemagick is too old: 6.2.4 > Note this doesn't change the output result as the problem is only the display of PDF-images within LyX. Why? I would think that it would also affect the

Re: another small bug for status 1.5.x

Am Mittwoch, 10. Januar 2007 23:46 schrieb Jean-Marc Lasgouttes: > A question: what happens to relative filenames when copy-pasting a > graphics or include inset? (the answer is probably: the same thing as > before :) Yes (i.e. nothing happens). Georg

Re: python help needed

Am Mittwoch, 10. Januar 2007 23:18 schrieb José Matos: > 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. >

Re: [Cvslog] r16671 - in /lyx-devel/trunk: development/scons/scons_man...

Am Samstag, 13. Januar 2007 22:08 schrieb [EMAIL PROTECTED]: > Add two files that are included by the beamer example file and that I forgot. > Found out by Jean-Pierre Chretien. Jean-Marc, I guess this is for 1.4.4, too? Georg

Solution: can't start 1.5svn under windows - Bo?

Uwe Stöhr schrieb: >> Another user has this problem too. I made a lot of tests the last days >> together with this user but I'm still not able to reproduce it. > It's maybe a manifest problem again. I notices tha there is the file "Microsoft.VC80.CRT.manifest" in SVN's

Re: [patch] fix bug 2418

> Why? I would think that it would also affect the conversion from pdf to eps > for plain latex output. This would be fine for me personally. In this case yes. > PS: You should fix your documentation commits before doing any further > changes IMO. What do you mean? What is broken or incorrect?

Re: [patch] move OS dependent code to proper place

On Sat, Jan 13, 2007 at 12:36:11PM +0100, Georg Baum wrote: > Am Samstag, 13. Januar 2007 09:58 schrieb Enrico Forestieri: > > On Fri, Jan 12, 2007 at 05:55:20PM +0100, Georg Baum wrote: > > > > > Enrico Forestieri wrote: > > > > > > > as a parameter introducer. To tell you the truth, the

Re: Solution: can't start 1.5svn under windows - Bo?

This was the problem!!! Now I spent two weeks of hard testing together with the users wh reported this first and I didn't came to this idea .-( When I deliver this manifest fil togehter with the Dlls mentioned in this file, it works. Congratulations on identifying the problem!! I still

Re: Remaining selection/clipboard problems: How to proceed

I am not going to do further changes, so if anybody wants fake selection on windows, persistent selection or something else please take care of that yourself. Thank you very much. I get the persistent selection patch and will try it later. I can not work on it soon because I will be extremely

Re: [patch] move OS dependent code to proper place

On Sat, Jan 13, 2007 at 12:36:17PM +0100, Georg Baum wrote: > Am Samstag, 13. Januar 2007 10:00 schrieb Enrico Forestieri: > > > Ok. I'll take into account your lack of sense of humour in the future. > > It was indeed not clear to me at all that this was intended as a joke. > Because it was

Re: [patch] move OS dependent code to proper place

On Sun, Jan 14, 2007 at 03:02:26AM +0100, Enrico Forestieri wrote: > I attach here a new version of the README.cygwin file intended to > replace the existing one. I cannot do it, so someone else will have to. I think that for better compliance with the GPL the patch should be put alongside the

session: save/restore window position bug

On Mac with the "save/restore window position" option checked, every time I quit LyX, the number stored in the session file for WindowPosY is decremented by 20, causing the LyX window to open higher and higher on the screen (eventually going off the top resulting in there being no way to

Re: session: save/restore window position bug

On 1/13/07, Bennett Helm <[EMAIL PROTECTED]> wrote: On Mac with the "save/restore window position" option checked, every time I quit LyX, the number stored in the session file for WindowPosY is decremented by 20, causing the LyX window to open higher and higher on the screen (eventually going

<    1   2