Re: Possible bug found by cppcheck

On 9/13/19 1:09 PM, Jean-Marc Lasgouttes wrote: > In DocFileNamefilename::mangledFileName, I see: > > string const name = absFileName(); > // Now the real work > string mname = os::internal_path(name); > // Remove the extension. > mname = support::changeExtension(name, string())

Possible bug found by cppcheck

In DocFileNamefilename::mangledFileName, I see: string const name = absFileName(); // Now the real work string mname = os::internal_path(name); // Remove the extension. mname = support::changeExtension(name, string()); So the assignment of internal_path is

Re: possible bug in lyx 2.2.0 and 2.2.1

On 12/13/2016 09:53 AM, Julien Javaloyes wrote: Regarding saving in 413 version, I am already doing that File > Export > More Formats I was thinking redirect / remap the save button as save in 413 format, but don't worry, I can use the suggested solution. You can definitely remap the Save menu

Re: possible bug in lyx 2.2.0 and 2.2.1

On 12/13/2016 08:17 AM, Julien Javaloyes wrote: Dear Author of Lyx, I am experiencing a problem with the version of lyx packaged with ubuntu 16.04, 2.2.0 Scrolling within a few pages document is extremely slow. The problem is less visible with the recent update to 2.2.1, but it is still ann

possible bug in lyx 2.2.0 and 2.2.1

Dear Author of Lyx, I am experiencing a problem with the version of lyx packaged with ubuntu 16.04, 2.2.0 Scrolling within a few pages document is extremely slow. The problem is less visible with the recent update to 2.2.1, but it is still annoying. However, the latest version of lyx on win

possible bug in ReplaceValues.py

Compiling lyX 2.2.dev gives me this error because the ReplaceValues.py cannot yet handle the origin unavailable tag: Generating de/Customization.lyx Traceback (most recent call last): File "D:/LyXGit/Master/development/cmake/doc/ReplaceValues.py", line 55, in SubstituteDataInFile(args[

RE: Possible bug when using "LatexType Environment" with "LabelType Enumerate"

I have opened ticket #8126 on trac. I would like to sponsor this bug fix. -Original Message- From: Richard Heck [mailto:rgh...@comcast.net] Sent: Monday, April 09, 2012 9:49 AM To: John Carbone; LyX Developers Subject: Re: Possible bug when using "LatexType Environment" with

Re: Possible bug when using "LatexType Environment" with "LabelType Enumerate"

On 04/08/2012 11:28 PM, John Carbone wrote: When using "LatexType Environment" with "LabelType Enumerate" produces the following latex code, where "req2" is correctly identified in the GUI the same as "req1", but does not appear in the latex code: [snip] Please post this as a bug on trac. I w

Possible bug when using "LatexType Environment" with "LabelType Enumerate"

When using "LatexType Environment" with "LabelType Enumerate" produces the following latex code, where "req2" is correctly identified in the GUI the same as "req1", but does not appear in the latex code: \usepackage{babel} \begin{document} \begin{rqmt}{req1} req1 desc \begin{rqmt}{req1.1} \end{rqm

Re: Possible Bug in Export to HTML

On 04/08/2012 06:57 PM, Peter Contor wrote: Hi all. This is my first posting to this mailing list, so apologies if I'm doing something wrong. My system: Windows Vista Home Premium Version 6.0.6002 Service Pack 2 Build 6002 LyX 2.0.3 MIKTeX 2.8 Description of alleged bug: I open a new file in

Possible Bug in Export to HTML

Hi all. This is my first posting to this mailing list, so apologies if I'm doing something wrong. My system: Windows Vista Home Premium Version 6.0.6002 Service Pack 2 Build 6002 LyX 2.0.3 MIKTeX 2.8 Description of alleged bug: I open a new file in LyX, open a display style formula box (with Ct

Re: Possible bug with keyboard shortcut parsing

On Feb 5, 2012, at 7:16 PM, Jens Nöckel wrote: > Hi, > I just noticed a weird bug on Mac OS C with LyX 2.02. First I couldn't > reproduce it, but now I think I have a recipe, and hopefully someone can > confirm it. In some cases, the _sequence_ of Control-x and Control-s that > emacs keybindin

Possible bug with keyboard shortcut parsing

Hi, I just noticed a weird bug on Mac OS C with LyX 2.02. First I couldn't reproduce it, but now I think I have a recipe, and hopefully someone can confirm it. In some cases, the _sequence_ of Control-x and Control-s that emacs keybindings reserve for saving a document doesn't work. Instead, onl

Re: Problem with converter in Lyx 2.0 - possible bug?

On Sun, May 22, 2011 at 7:52 PM, Enrico Forestieri wrote: > On Sat, May 21, 2011 at 06:03:06PM +0200, Rainer M Krug wrote: > > > Hi > > > > I have defined some converters to use plantuml, and they worked under > > 1.6.9 and also the display in the LyX document works, only creation of > > a pdf (o

Re: Problem with converter in Lyx 2.0 - possible bug?

On 22.05.2011 19:52, Enrico Forestieri wrote: In this case, your only bet is recompiling LyX using the attached patch. Would disabling the definition of USE_PROCESS completely fix the issue? So why do we not a command line and settings option do switch between the two modes? Peter

Re: Problem with converter in Lyx 2.0 - possible bug?

On Sat, May 21, 2011 at 06:03:06PM +0200, Rainer M Krug wrote: > Hi > > I have defined some converters to use plantuml, and they worked under > 1.6.9 and also the display in the LyX document works, only creation of > a pdf (or any other export) does not. The conversion works as follow: > > plant

Problem with converter in Lyx 2.0 - possible bug?

Hi I have defined some converters to use plantuml, and they worked under 1.6.9 and also the display in the LyX document works, only creation of a pdf (or any other export) does not. The conversion works as follow: plantuml -> SVG SVG -> png for display SVG -> pdf for pdf When checking in the tem

Re: Possible bug: Insert->Note->(any action) copies selection to clipboard

Le 01/03/2010 21:03, Stephan Witt a écrit : I can confirm this bug for 1.6.5 branch version. This bug is a "feature" of the inset insertion code and is probably known for ages. It would not be difficult to fix, but annoying because the Clipboard API is so horrible. The simplest version would

Re: Possible bug with table line set/unset

On 03/03/2010 04:19 AM, Manoj Rajagopalan wrote: Hi lyx-devel, 1. placing the cursor *immediately outside* a table 2. using Shift- arrow key to select the entire table in one key-press, 3. unset-all-lines buttonpress on table toolbar only unsets some of the lines of the top-left cell. Seems

Possible bug with table line set/unset

Hi lyx-devel, 1. placing the cursor *immediately outside* a table 2. using Shift- arrow key to select the entire table in one key-press, 3. unset-all-lines buttonpress on table toolbar only unsets some of the lines of the top-left cell. Seems like a bug because the set/unset should entire go t

Re: Possible bug: Insert->Note->(any action) copies selection to clipboard

Am 01.03.2010 um 20:25 schrieb Manoj Rajagopalan: > > > > On Monday 01 March 2010 12:10:33 pm Vincent van Ravesteijn - TNW wrote: >> >> One note, if you report a bug for trunk, please also check whether the >> bug is in branch too (or a recently released version). Then you can mark >> the lyx

Re: Possible bug: Insert->Note->(any action) copies selection to clipboard

On Monday 01 March 2010 12:10:33 pm Vincent van Ravesteijn - TNW wrote: > > One note, if you report a bug for trunk, please also check whether the > bug is in branch too (or a recently released version). Then you can mark > the lyx version as 1.6.5 in stead of 2.0.0svn. > > Vincent I don't use

RE: Possible bug: Insert->Note->(any action) copies selection to clipboard

> I've created a bug report on trac: > > http://www.lyx.org/trac/ticket/6570 > > I'm still learning lyx-iquette and I'm sorry I jumped the gun this time > by filing a bug report before emailing the lyx-devel list. It is ok to report a bug on trac without mailing the devel list. However, when

Possible bug: crash on backing out of embedded inline math formula

Hi, I'd created a ticket for this a few days ago but I should have emailed this list first. http://www.lyx.org/trac/ticket/6564 Since filing this report I have discovered a little more and hence the issue title is more restricted than the bug itself. Basically, when using the left ar

Possible bug: Insert->Note->(any action) copies selection to clipboard

Hi, I've created a bug report on trac: http://www.lyx.org/trac/ticket/6570 I'm still learning lyx-iquette and I'm sorry I jumped the gun this time by filing a bug report before emailing the lyx-devel list. Thanks, Manoj

Re: Possible bug with bibtex parsing at startup

I've also discovered that the presence of unicode characters causes a soft failure. Issue #6534 is possibly related to this: http://www.lyx.org/trac/ticket/6534 Can the fix to this issue (escaping the unicode characters etc.) be applied to the bibtex parsing at initial startup also? That might

Possible bug with bibtex parsing at startup

Hi lyx-devel, When the abstract field has single-quotes in it (eg. Green's functions), bibtex parsing at startup fails with an error message like the following: InsetBibtex::fillWithBibKeys: Unable to read value for field: abstract, for key: Heitz-excited-states-energy-relaxation-stacked-InA

Re: [bug-report] Possible bug with file extension handling?

Hugo Vincent wrote: >> I'm trying to set up some custom file converters (which take psfrag'd EPS >> files from matlab, do some "stuff" to the annotations then render them to >> a PDF), and am distinguishing between what "stuff" gets done by file >> extension. That is, for operation A, I might ca

Re: [bug-report] Possible bug with file extension handling?

Hugo Vincent wrote: > > On 4/11/2009, at 9:13 PM, Pavel Sanda wrote: string const format = filename.guessFormatFromContents(); if (!format.empty()) return format; // try to find a format from the file extension. string const ext = getExtens

Re: [bug-report] Possible bug with file extension handling?

On 4/11/2009, at 9:13 PM, Pavel Sanda wrote: string const format = filename.guessFormatFromContents(); if (!format.empty()) return format; // try to find a format from the file extension. string const ext = getExtension(filename.absFilename());

Re: [bug-report] Possible bug with file extension handling?

Pavel Sanda wrote: > Hugo Vincent wrote: > > Hi, > > > > I'm trying to fix the end-user problem I'm having (quoted below), and think > > I found the source of the problem. > > > > Around line 121 in Format.cpp: > > string Formats::getFormatFromFile(FileName const & filename) const > > { > > > >

Re: [bug-report] Possible bug with file extension handling?

Hugo Vincent wrote: > Hi, > > I'm trying to fix the end-user problem I'm having (quoted below), and think > I found the source of the problem. > > Around line 121 in Format.cpp: > string Formats::getFormatFromFile(FileName const & filename) const > { > > string const format = filename.guess

[bug-report] Possible bug with file extension handling?

Hi, I'm trying to fix the end-user problem I'm having (quoted below), and think I found the source of the problem. Around line 121 in Format.cpp: string Formats::getFormatFromFile(FileName const & filename) const { string const format = filename.guessFormatFromContents(); if

Re: possible bug in text wrap float

James Sutherland schrieb: Hmm - dreadful silence. Please report it at http://bugzilla.lyx.org then it won't be forgotten. thanks and regards Uwe

Re: possible bug in text wrap float

Hmm - dreadful silence. I found a work-around: lift all children documents that use text wrap floats into the parent document. Then things compile without problem. This is definitely a bug in RC4 (I haven't yet tested it in RC5). James On Oct 29, 2008, at 7:21 AM, James Sutherland wrote:

Re: possible bug in text wrap float

Do any developers have any suggestions to fix this problem? James On Oct 28, 2008, at 5:09 PM, Julio Rojas wrote: Confirmed in RC4 under Vista, but it only happens if both documents are open. If I only have the child document open, I can compile it without a problem, even after the error on the

Re: possible bug in text wrap float

Confirmed in RC4 under Vista, but it only happens if both documents are open. If I only have the child document open, I can compile it without a problem, even after the error on the parent document. - Julio Rojas [EMAIL PROTECTED] On Wed, Oct 29, 2

Re: possible bug in text wrap float

I should mention: this was with 1.6rc4. On Oct 28, 2008, at 2:41 PM, James Sutherland wrote: I have hit a bug in the text wrap float, but am having a hard time creating steps to reliably reproduce it. The problem shows up by LyX shoving the following into the LaTeX output: \floatstyle{}

possible bug in text wrap float

I have hit a bug in the text wrap float, but am having a hard time creating steps to reliably reproduce it. The problem shows up by LyX shoving the following into the LaTeX output: \floatstyle{} \newfloat{}{}{} \floatname{}{} This seems to be triggered when I have a text wrap float with s

Re: Possible bug: spaces in commands in text in math editor

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Marc Lasgouttes wrote: > Spaces are irrelevant in normal TeX maths. This is why LyX does not > allow them. Yes, but if I'm in text mode (such as \text{}) inside math mode, spaces are meaningful, and they are kept by the math editor. However, when

Re: Possible bug: spaces in commands in text in math editor

"Edward Z. Yang" <[EMAIL PROTECTED]> writes: > I was using the instant preview hack detailed at > in order to get live previews of > mhchem, and the technique mostly works. However, it difficult/impossible > to edit the all but the simplest formulae inside ma

Possible bug: spaces in commands in text in math editor

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was using the instant preview hack detailed at in order to get live previews of mhchem, and the technique mostly works. However, it difficult/impossible to edit the all but the simplest formulae inside math edit

Re: Possible bug in LyX 1.5.2

On Wed, Nov 14, 2007 at 03:55:13PM +0100, [EMAIL PROTECTED] wrote: > I realised that the problem is not related to network drives but to path > names containing German "Umlaute". > > If the path name of a LyX file contains an Umlaut, LyX will claim that > the file has been externally modified when

Re: Possible bug in LyX 1.5.2

I realised that the problem is not related to network drives but to path names containing German "Umlaute". If the path name of a LyX file contains an Umlaut, LyX will claim that the file has been externally modified whenever I try to save it. Cheers, Martin

Possible bug in LyX 1.5.2

Hi all, I found what looks like a bug to me in the latest LyX release 1.5.2. I'm running the windows version and whenever I save a changed file to a network drive, LyX issues a warning claiming the file has been externally modified. When saving file changes to a local drive this problem does no

Re: TOC dialog: Possible bug in qt 4.2 or am I missing something awfully?

On Thu, May 10, 2007 at 02:00:59PM +0300, Ozgur Ugras BARAN wrote: > I am trying to solve bug 3529 and things seems to be weird. I check if the > modelItem for the TOC entry is passed correctly. For kernel/model to view > side everything seems OK. Apparently the problem is in paint mechanism of > t

Re: TOC dialog: Possible bug in qt 4.2 or am I missing something awfully?

Ozgur Ugras BARAN wrote: I am trying to solve bug 3529 and things seems to be weird. I check if the modelItem for the TOC entry is passed correctly. For kernel/model to view side everything seems OK. Apparently the problem is in paint mechanism of treeView. I did every possible trick to make the

TOC dialog: Possible bug in qt 4.2 or am I missing something awfully?

I am trying to solve bug 3529 and things seems to be weird. I check if the modelItem for the TOC entry is passed correctly. For kernel/model to view side everything seems OK. Apparently the problem is in paint mechanism of treeView. I did every possible trick to make the treeview repaint correctly

Re: [Fwd: Possible bug in Math panel-detach panel in LyxWincsv]

Ekkehart Schlicht wrote: > If I detach the "greek" panel, I obtain "greek-panel.png" below. > If I minimize it and then restore it, I obtain "greek-restored.png" > which is incomplete. Oh, cool! Thanks, Ekkehart. I'll go tell the Qt/Win Free guys. -- Angus

[Fwd: Possible bug in Math panel-detach panel in LyxWincsv]

Hi If I detach the "greek" panel, I obtain "greek-panel.png" below. If I minimize it and then restore it, I obtain "greek-restored.png" which is incomplete. Cheers Ekkehart

Re: Possible Bug in Lyx 1.3.6 (Windows)

I have found that the same problem appears if from the command line I try to execute "acrobat file.pdf". However, if I just write "file.pdf" the file is opened (it is the same as clicking twice on it from the explorer window). The problem will be solved if in Preferneces, for the PDF viewer, we

Re: Possible Bug in Lyx 1.3.6 (Windows)

B.T.Linfoot wrote: Unfortunately I can confirm Uwe's report for release 9: PDF reports : unrecoverable error : typecheck in .putdeviceprops with a corresponding Adobe report : "There was an error opening this document: This file cannot be found." PDF(dvipdfm); PDF(pdflatex); Postscript all

Re: Possible Bug in Lyx 1.3.6 (Windows)

Angus Leeming wrote: > I did suggest that you go grab an official distribution of Python... > It would appear that you need to be adding something to your "minimal" > package :-) Thanks for the hint. You load some .pyc-files in the clean_dvi.py. I added the missing files to my minimal package:

Re: Possible Bug in Lyx 1.3.6 (Windows)

Angus Leeming wrote: >> - now add a charcter in the LyX-file, so that you have e.g. "abcd" >> - use the menu View->Update->pdflatex >> >> As result nothing happens, the pdf wasn't changed >> >> - use the menu View->pdflatex >> >> As result acrobat comes up showing the old version of the pdf with

Re: Possible Bug in Lyx 1.3.6 (Windows)

Unfortunately I can confirm Uwe's report for release 9: PDF reports : unrecoverable error : typecheck in .putdeviceprops with a corresponding Adobe report : "There was an error opening this document: This file cannot be found." PDF(dvipdfm); PDF(pdflatex); Postscript all display as expected

Re: Possible Bug in Lyx 1.3.6 (Windows)

Uwe Stöhr wrote: > Angus Leeming wrote: > > >>> I also have some problems running View/Export of PDF or PS > > > Now fixed. Version 9 is available on the wiki site. > > It is still there: > > - Open acroread/acrobat without any pdf loaded > - Create a new LyX-document and save the file > - n

Re: Possible Bug in Lyx 1.3.6 (Windows)

Angus Leeming wrote: >> Accent keys don't work in general in 1.3.6. > > I suspect a Qt/WinFree bug. > > Does this help http://www.kovcomp.co.uk/acompose/ ? (They have a demo > version...) Accent keys work fine in Ruurds version so why should I use another program to fix the problem? But any

Re: Possible Bug in Lyx 1.3.6 (Windows)

Uwe Stöhr wrote: > here the debug message for Export->DVI > > --- > Converting from latex to dvi2 > Running latex > lyx::sum() using istreambuf_iterator (fast) > Converting from dvi2 to dvi > Calling python "F:/LyXTest/LyX/Resources/lyx/scripts/clean_dvi.py" >

Re: Possible Bug in Lyx 1.3.6 (Windows)

Angus Leeming wrote: >>> I also have some problems running View/Export of PDF or PS > Now fixed. Version 9 is available on the wiki site. It is still there: - Open acroread/acrobat without any pdf loaded - Create a new LyX-document and save the file - now use View->pdflatex As result acrobat

Re: Possible Bug in Lyx 1.3.6 (Windows)

Uwe Stöhr wrote: Nicolás a écrit: > In order to get this character "á" in my norwegian keyboard, I press > "Alt Gr"+ "Ž" +"a". This used to work fine in LyX 1.3.5 but in this > new version I get "Ža". Indeed, accent keys don't work in general in 1.3.6. I suspect a Qt/WinFree bug. Does thi

Re: Possible Bug in Lyx 1.3.6 (Windows)

Nicolás wrote: I also have some problems running View/Export of PDF or PS (detailed info below) View/Export PDF or PS: Converting from dvi2 to dvi Calling python C:/tools/latex/lyx136/Resources/lyx/scripts/clean_dvi.py" "mydocument.dvi" "tmpfile.out" renaming file C:/tools/latex/lyx136/temp

Re: Possible Bug in Lyx 1.3.6 (Windows)

Uwe Stöhr wrote: > I also have some problems running View/Export of PDF or PS (detailed > info below) Now fixed. Version 9 is available on the wiki site. Mee too, Export->dvipdfm and Export->pdf produces the error: "Can't run python in ~/LyX/Resources/lyx/scripts/clean" But there is no f

Re: Possible Bug in Lyx 1.3.6 (Windows)

Nicolás wrote: I also have some problems running View/Export of PDF or PS (detailed info below) View/Export PDF or PS: Converting from dvi2 to dvi Calling python C:/tools/latex/lyx136/Resources/lyx/scripts/clean_dvi.py" "mydocument.dvi" "tmpfile.out" renaming file C:/tools/latex/lyx136/temp

Possible Bug in Lyx 1.3.6 (Windows)

> In order to get this character "á" in my norwegian keyboard, I press > "Alt Gr"+ "Ž" +"a". This used to work fine in LyX 1.3.5 but in this > new version I get "Ža". Indeed, accent key don't work in general in 1.3.6. > I also have some problems running View/Export of PDF or PS (detailed > info

Re: Possible Bug in Lyx 1.3.6 (Windows)

Nicolás wrote: I also have some problems running View/Export of PDF or PS (detailed info below) View/Export PDF or PS: Converting from dvi2 to dvi Calling python C:/tools/latex/lyx136/Resources/lyx/scripts/clean_dvi.py" "mydocument.dvi" "tmpfile.out" renaming file C:/tools/latex/lyx136/temp

Possible Bug in Lyx 1.3.6 (Windows)

Hei! In order to get this character "á" in my norwegian keyboard, I press "Alt Gr"+ "´" +"a". This used to work fine in LyX 1.3.5 but in this new version I get "´a". I also have some problems running View/Export of PDF or PS (detailed info below) View/Export PDF or PS: Converting from d

possible bug in LyX 1.4

Hi, I have just compiled LyX 1.4 on a box running Red Hat Enterprise Linux. As soon as I started up LyX (using the xforms interface), the machine memory filled up, and hundreds of megabytes of error messages were produced before I killed the job. The first few lines of the error messages are as f

Re: possible bug

> "Ben" == Ben Stanley <[EMAIL PROTECTED]> writes: Ben> I am writing to let it be known that I consider this bug affects Ben> me as well, and that I consider it to be rather serious. Could Ben> you please re-consider the back-porting issue? The problem is to find someone who has both the time

Re: possible bug

I am writing to let it be known that I consider this bug affects me as well, and that I consider it to be rather serious. Could you please re-consider the back-porting issue? Ben. Jean-Marc Lasgouttes wrote: "btz64" == btz64 <[EMAIL PROTECTED]> writes btz64> when you insert a eps image in a

Re: possible bug

> "btz64" == btz64 <[EMAIL PROTECTED]> writes: btz64> Hi, I just update lyx 1.2.0 to lyx 1.2.1/ I notice an unusual btz64> behavior that was not on 1.2.0: btz64> when you insert a eps image in a figure float. You compile once btz64> to view the ps document and everything is working fine. BUT

possible bug

Hi, I just update lyx 1.2.0 to lyx 1.2.1/ I notice an unusual behavior that was not on 1.2.0: when you insert a eps image in a figure float. You compile once to view the ps document and everything is working fine. BUT if you update the eps file, and recompile the lyx file to ps document again, t

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> If there is something you really want in 1.2.1, send a (well >> tested) patch. Juergen> I've just discovered that you cleaned up the bindings for Juergen> starred sectioning commands. Well

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

Andre Poenitz wrote: > I wonder who's got the idea of localized key bindings. That's crazy to use > if you often switch languanges. IMO formating paragraphs it should be M-p > for German too, even if 'Absatz' does not has a 'p' I don't care, as long as they are memorizable and not too complic

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

John Levon <[EMAIL PROTECTED]> writes: | On Thu, Aug 15, 2002 at 06:49:03PM +0200, Andre Poenitz wrote: > >> Reminds me of some (English) guy who didn't like foreign movies (even those >> translated to English) because he was (unconciously) used to reading lips. > | There's nothing worse than dub

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

On Thu, Aug 15, 2002 at 06:49:03PM +0200, Andre Poenitz wrote: > Reminds me of some (English) guy who didn't like foreign movies (even those > translated to English) because he was (unconciously) used to reading lips. There's nothing worse than dubbed films anyway. Subtitles ! > Believe me, you

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

On Thu, Aug 15, 2002 at 05:38:28PM +0100, John Levon wrote: > You're on thin ice here. Being pathetically mono-lingual I often imagine > if Atari hadn't screwed themselves and somehow most software was > primarily German. I can tell you one thing: M-b for "Paragraph" would > infuriate me, and it w

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

On Thu, Aug 15, 2002 at 06:30:25PM +0200, Andre Poenitz wrote: > I wonder who's got the idea of localized key bindings. That's crazy to use > if you often switch languanges. IMO formating paragraphs it should be M-p > for German too, even if 'Absatz' does not has a 'p' You're on thin ice her

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Aug 15, 2002 at 06:14:30PM +0200, Juergen Spitzmueller wrote: >> I've just discovered that you cleaned up the bindings for starred sectioning >> commands. Well, I want that for german too ;-) > | I wonder who's got the idea of localized key bin

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

On Thu, Aug 15, 2002 at 06:14:30PM +0200, Juergen Spitzmueller wrote: > I've just discovered that you cleaned up the bindings for starred sectioning > commands. Well, I want that for german too ;-) I wonder who's got the idea of localized key bindings. That's crazy to use if you often switch lan

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

Jean-Marc Lasgouttes wrote: > If there is something you really want in 1.2.1, send a (well tested) > patch. I've just discovered that you cleaned up the bindings for starred sectioning commands. Well, I want that for german too ;-) Here's a patch (against 1.2.1cvs). It's not really important, bu

Re: Possible BUG in LyX 1.2.0 (ERT inset related)

> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> Jean-Marc Lasgouttes wrote: >> If somebody does it for me, I will consider to apply the patch. I >> do not have much time to do it myself. Anyway, I already would like >> to release 1.2.1 pretty soon, so some features have to be

Re: possible bug...

On Fri, Apr 12, 2002 at 03:00:11PM +0100, Angus Leeming wrote: > > The const perhaps. > > I take it you'd like me to make it more secure? > - FormatList const & formats = GImage::loadableFormats(); > + FormatList const formats = GImage::loadableFormats(); By 12.2.5., the temporary object

Re: possible bug...

On Friday 12 April 2002 2:07 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | Thinking about Herbert and Rob's list of loadable graphics formats, I > | discover the following code: > | > | string const findTargetFormat(string const & from) > | { > | typedef GImage

Re: possible bug...

Angus Leeming <[EMAIL PROTECTED]> writes: | Thinking about Herbert and Rob's list of loadable graphics formats, I | discover the following code: > | string const findTargetFormat(string const & from) | { | typedef GImage::FormatList FormatList; | FormatList const & formats = GImage::

possible bug...

Thinking about Herbert and Rob's list of loadable graphics formats, I discover the following code: string const findTargetFormat(string const & from) { typedef GImage::FormatList FormatList; FormatList const & formats = GImage::loadableFormats(); Now GImage::loadableFormats() re

[Christian Ridderström ] Re: Possible bug related to BibTex insert dialog, showing the same entry multiple times

--- Begin Message --- Hi I've attached three files that demonstrate the "bug", test.default.bib - Bib-file containing default string macros that I use in several other bib-files test.bib - The main .bib-file bib_test.lyx

Re: Anonymous CVS and a possible bug

On Thu, Jun 07, 2001 at 09:09:34AM -0400, Baruch Even wrote: > I'm trying to use LyX through a machine I have access to in the Technion, > I'm using LyX from cvs for the fun of it... > > One bug that I found was that the text didn't scroll when I passed screen > size. That is, I started to write

Anonymous CVS and a possible bug

I'm trying to use LyX through a machine I have access to in the Technion, I'm using LyX from cvs for the fun of it... One bug that I found was that the text didn't scroll when I passed screen size. That is, I started to write the abstract and it just continued on the same line even after the wind

Possible bug in Lyx 1.16fix1: folded floats and TOC

Hello, not really sure if this is a bug, rather an interface annoyance, but here goes: If I fold in all table and figure floats via the "edit" menu, and then try to jump to one figure or table by clicking on its line in the TOC window, LyX jumps to the end of my document, every time. I'd rather

Re: Possible bug-type thing

On Tue, Dec 12, 2000 at 01:33:41AM +, Sam Vere wrote: > Currently using the version supplied with Mandrake 7.2. On my screen > resolution of 800x600 the class list in the Layout -> Document dialog is > very nearly too large for the screen - I hope that 'Slides' was the last > on the list, bec

Possible bug-type thing

Currently using the version supplied with Mandrake 7.2. On my screen resolution of 800x600 the class list in the Layout -> Document dialog is very nearly too large for the screen - I hope that 'Slides' was the last on the list, because most of that is off the screen and anything below that is los

RE: clever compiler highlights possible bug...

On 18-Oct-2000 Angus Leeming wrote: > Maybe, just maybe this exercise might find a bug. > > Compiling screen.C, I find that >#550-D variable "height" was set but never used > int height; > [snip code] > > Should DrawFromTo() be passed "height" or can we scrap the pre

Re: clever compiler highlights possible bug...

Angus Leeming <[EMAIL PROTECTED]> writes: | Maybe, just maybe this exercise might find a bug. | | Compiling screen.C, I find that | #550-D variable "height" was set but never used | int height; | | The relevant code: | | void

clever compiler highlights possible bug...

Maybe, just maybe this exercise might find a bug. Compiling screen.C, I find that #550-D variable "height" was set but never used int height; The relevant code: void LyXScreen::Update(LyXText * text, int y_offset, int x_offset

Re: Possible bug in lyx-1.1.5 (fwd)

> "Carlos" == Carlos A M dos Santos <[EMAIL PROTECTED]> writes: Carlos> Program received signal SIGSEGV, Segmentation fault. 0x8132c15 Carlos> in lyxstring::lyxstring (this=0xbfbfb4ac, s=0x8384000 "%%\n%% OK, I see. Hopefully, this is fixed in 1.1.5fix1 that will be released today or tomorro

Possible bug in lyx-1.1.5 (fwd)

-- Forwarded message -- Date: Mon, 12 Jun 2000 21:33:17 + (GMT) From: Carlos A M dos Santos <[EMAIL PROTECTED]> To: Lyx Developers list <[EMAIL PROTECTED]> Subject: Possible bug in lyx-1.1.5 Hello I'm using lyx to edit my thesis. It is a quite large d

Re: Possible bug in lyx-1.1.5 - more info

On Mon, 12 Jun 2000, Carlos A M dos Santos wrote: > I'm using lyx to edit my thesis. It is a quite large document that > uses several packages and includes lots of small inlined-eps images. > The operating system is FreeBSD 3.4 with XFree86 3.3.5. I also > installed gcc/b++ 2.95.2 because LyX doe

Possible bug in lyx-1.1.5

Hello I'm using lyx to edit my thesis. It is a quite large document that uses several packages and includes lots of small inlined-eps images. The operating system is FreeBSD 3.4 with XFree86 3.3.5. I also installed gcc/b++ 2.95.2 because LyX does not compile with the stock gcc 2.7.2.3. LyX was

Re: possible bug with read only mode

Angus> Good! Must be something silly that I've introduced. Many Angus> thanks, Jean-Marc. Hmmm! My crash occurs in fl_show_form() if (and only if) I call WarnReadonly() to create this warning dialog. The citation dialog cannot be edited if the document is read only, so the warning isn't needed. I

Re: possible bug with read only mode

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Good! Must be something silly that I've introduced. Many Angus> thanks, Jean-Marc. It might also be a difference between our configuration, but it would be strange since you use tru64. JMarc

  1   2   >