Re: Interest in using git with lyx svn

for example i like to have personal web pages so i can run things like doxygen generated docs for lyx, sf.net provides ssh access, something even my web hosting company is unwilling to provide. I just checked and it has doxygen pre-installed.

Use module logging instead of hand-made Tee in lib/configure.py.

=== --- lib/configure.py (revision 28701) +++ lib/configure.py (working copy) @@ -8,27 +8,22 @@ # \author Bo Peng # Full author contact details are available in file CREDITS. -import sys, os, re, shutil, glob +import sys, os, re, shutil, glob, logging +# set up logging

Re: Use module logging instead of hand-made Tee in lib/configure.py.

> I am not sure if that was the original reason. logging has appeared in python > 2.3 and initially for lyx 1.4 we planned for python 2.2. I am not sure if that > is the reason FWIW I am just adding this to be fair. This might be the reason, but I did not even look for something like this when I

Re: Interest in using git with lyx svn

> > The bug database might be a problem... I know that many people dislike sourceforge but sourceforge supports pmwiki (our web), trac, and some project and bug tracking systems... http://apps.sourceforge.net/trac/sitedocs/wiki/Hosted%20Apps Bo

Re: Interest in using git with lyx svn

> Now that is has been brought up, I think we should have a close look at > sourceforge.net. I have used sourceforge for my own project for five years and I am satisfied with their services. 1. mailinglist based on mailman works. 2. I use subversion but it supports git as well.

Re: Interest in using git with lyx svn

> for example i like to have personal web pages so i can run things like doxygen > generated docs for lyx, sf.net provides ssh access, something even my web hosting company is unwilling to provide. I just checked and it has doxygen pre-installed.

An annoying problem with automatic update of reference.

Dear list, If I have a document with a reference to a program listing, Ref:A Listing_with_Label_A If I copy Listing_with_Label_A to another listing and change its label to B. Ref:A will be automatically changed to B. That is to say Ref:B Listing_with_Label_A Listing_with_Label_B.

Re: An annoying problem with automatic update of reference.

Does it make sense to only do this if there is no Label_A in the document? I copy listings inset around a lot so that I do not have to re-specify some listings parameters, and the automatic change of references have been annoying. With the attached patch, only the update of the 'first'

Re: An annoying problem with automatic update of reference.

If I copy a Listing with a label, the label is renamed to something else in order not to have two labels with the same name. Then renaming this new label should not have any effect on the existing references. This is not the case for branch. I do not have trunk to test. Bo

Re: An annoying problem with automatic update of reference.

Well, I'm using the 1.6.1 release.. .. and I really can't get two labels with the same name. OK. I am using LyX svn/branch, svnversion 28539, flash screen shows version 1.6.2svn. Now repeat after me :-) 1. create a new document 2. insert File-Child document-program listing, with label a.

Re: An annoying problem with automatic update of reference.

3. insert cross-reference a. 4. select the listings inset, copy, paste, 5. click the copied listings. **I still see label a.** This is a bug. The label should have changed to a-1 with a warning message (to be consistent with the 'normal' labels). I see. The problem with InsetListing is that

Re: An annoying problem with automatic update of reference.

We thought you were just talking about normal labels. So the problem is that the mechanism that changes duplicate labels on copying isn't working with the labels that go with listings child docs. That's what we need to fix, since we don't want duplicate labels. Yep, I remember this was on my

Re: An annoying problem with automatic update of reference.

PS. I don't like this way to insert labels. A) it seems prone for bugs, B) the label is not shown on the screen. PS2. I can't think of a good alternative right now. Attached is a patch that fixes the bug. The only question I have is whether or not CutAndPaste.cpp is the best place to update

An annoying problem with automatic update of reference.

Dear list, If I have a document with a reference to a program listing, Ref:A Listing_with_Label_A If I copy Listing_with_Label_A to another listing and change its label to B. Ref:A will be automatically changed to B. That is to say Ref:B Listing_with_Label_A Listing_with_Label_B.

Re: An annoying problem with automatic update of reference.

> Does it make sense to only do this if there is no Label_A in the > document? I copy listings inset around a lot so that I do not have to > re-specify some listings parameters, and the automatic change of > references have been annoying. With the attached patch, only the update of the 'first'

Re: An annoying problem with automatic update of reference.

> If I copy a Listing with a label, the label is renamed to something else > in order not to have two labels with the same name. Then renaming this > new label should not have any effect on the existing references. This is not the case for branch. I do not have trunk to test. Bo

Re: An annoying problem with automatic update of reference.

> Well, I'm using the 1.6.1 release.. > > .. and I really can't get two labels with the same name. OK. I am using LyX svn/branch, svnversion 28539, flash screen shows version 1.6.2svn. Now repeat after me :-) 1. create a new document 2. insert File->Child document->program listing, with label

Re: An annoying problem with automatic update of reference.

>>3. insert cross-reference a. >>4. select the listings inset, copy, paste, >>5. click the copied listings. **I still see label a.** > > This is a bug. > > The label should have changed to "a-1" with a warning message (to be > consistent with the 'normal' labels). I see. The problem with

Re: An annoying problem with automatic update of reference.

>> We thought you were just talking about normal labels. So the problem is >> that the mechanism that changes duplicate labels on copying isn't working >> with the labels that go with listings child docs. That's what we need to >> fix, since we don't want duplicate labels. > > Yep, I remember this

Re: An annoying problem with automatic update of reference.

> > PS. I don't like this way to insert labels. A) it seems prone for bugs, > B) the label is not shown on the screen. > > PS2. I can't think of a good alternative right now. Attached is a patch that fixes the bug. The only question I have is whether or not CutAndPaste.cpp is the best place to

Re: Portable LyX File Format

I hope I speak for everybody when I say it's very nice to hear from you again[*]. Thanks. I still browse list emails from time to time and you know what topic attracts me most. :-) I hope your pmwiki problem at sourceforge is fully resolved now. sourceforge.net does not allow sendmail so I

Re: Portable LyX File Format

> I hope I speak for everybody when I say it's very nice to hear from you > again[*]. Thanks. I still browse list emails from time to time and you know what topic attracts me most. :-) > I hope your pmwiki problem at sourceforge is fully resolved now. sourceforge.net does not allow sendmail so

Re: Portable LyX File Format

I'm sort of working on the subject.. How do you think of David's proposal? Do you already have your own proposal or even implementation somewhere? Bo

Re: Portable LyX File Format

Not that I am an expert but you first step is OK with me. Note that you kind of already have that with the Navigator for InsetGraphics. But the need for a manifest file/registration has not been agreed upon (my embedding approach does not need it). I disagree with your incremental approach

Re: Portable LyX File Format

We are only talking about maintaining a list of links in the Buffer structure within LyX itself, not in an external manifest file. Sorry, I have not traced the development of LyX for a while... Please, no drama this time :-) You can trust me on this. I am already retired so the most I can

Re: Portable LyX File Format

> I'm sort of working on the subject.. How do you think of David's proposal? Do you already have your own proposal or even implementation somewhere? Bo

Re: Portable LyX File Format

> Not that I am an expert but you first step is OK with me. Note that you kind > of already have that with the Navigator for InsetGraphics. But the need for a manifest file/registration has not been agreed upon (my embedding approach does not need it). I disagree with your incremental approach

Re: Portable LyX File Format

> We are only talking about maintaining a list of links in the Buffer structure > within LyX itself, > not in an external manifest file. Sorry, I have not traced the development of LyX for a while... > Please, no drama this time :-) You can trust me on this. I am already retired so the most I

Re: Portable LyX File Format

This allows for a lossless .lyx - .plyx - .lyx conversion. Although .plyx - .lyx - .plyx could be lossy, a script could be used to update the manifest of a new .plyx file based on an old .plyx file to minimize the loss. The lossy .plyx - .lyx - .plyx conversion has been the center of all

Re: Portable LyX File Format

Thanks for your thoughts. I skimmed your pdf but I'll have to give it a fuller read later. In the meantime I wanted to respond to your post. I skimmed your file and it does not seem to differ much from a previous bundling implementation. (I can be wrong here but the manifest file etc were

Re: Portable LyX File Format

I found a thread from about a year ago here which may be what you're talking about. There were several flame wars about embedding ... to a level that the whole lyx-devel mailinglist was hijacked and everyone involved was 2nd degree burned. The unfruitful discussions eventually leaded to my

Re: Portable LyX File Format

> This allows for a > lossless .lyx -> .plyx -> .lyx conversion. Although .plyx -> .lyx -> .plyx > could be lossy, a script could be used to update the manifest of a new .plyx > file based on an old .plyx file to minimize the loss. The lossy .plyx -> .lyx -> .plyx conversion has been the center

Re: Portable LyX File Format

> Thanks for your thoughts. I skimmed your pdf but I'll have to give it a > fuller read later. In the meantime I wanted to respond to your post. I skimmed your file and it does not seem to differ much from a previous bundling implementation. (I can be wrong here but the manifest file etc were

Re: Portable LyX File Format

> I found a thread from about a year ago here which may be what you're talking > about. There were several flame wars about embedding ... to a level that the whole lyx-devel mailinglist was hijacked and everyone involved was 2nd degree burned. The unfruitful discussions eventually leaded to my

Re: Collaboration with LyX

On Thu, Jan 29, 2009 at 3:11 AM, Piero Faustini pierofaust...@hotmail.com wrote: There is often discussion (or a feature request) on one of the mailing lists of how to share a LyX document with other users (LyX or non-LyX). for those who don't know it, there's a discussion on this topic on

Re: Collaboration with LyX

On Thu, Jan 29, 2009 at 3:11 AM, Piero Faustini wrote: > >> There is often discussion (or a feature request) on one of the mailing >> lists of how to share a LyX document with other users (LyX or non-LyX). > > for those who don't know it, there's a discussion on this

Re: custom fields in documents

When one has to use command-sequence to implement a menu entry, a warning light should ring (if I may say). This is useful in a few cases, but this case belongs to a personal ui file. I agree with JMarc's opinion. If we really want such menu items, we should expand the inset-info and its

Re: custom fields in documents

> >> When one has to use command-sequence to implement a menu entry, a >> warning light should ring (if I may say). This is useful in a few cases, >> but this case belongs to a personal ui file. I agree with JMarc's opinion. If we really want such menu items, we should expand the inset-info and

Re: Fail to include files differ only by extension.

On Sun, Jan 11, 2009 at 2:02 AM, Jürgen Spitzmüller juer...@spitzmueller.org wrote: Bo Peng wrote: The attached patch fixes the bug but I am not sure if this is the best solution. Looks sensible. Jürgen It is now fixed in branch: http://www.lyx.org/trac/changeset/28101 . Can anyone apply

Re: Fail to include files differ only by extension.

On Sun, Jan 11, 2009 at 2:02 AM, Jürgen Spitzmüller <juer...@spitzmueller.org> wrote: > Bo Peng wrote: >> The attached patch >> fixes the bug but I am not sure if this is the best solution. > > Looks sensible. > > Jürgen > It is now fixed in branch: http://ww

Fail to include files differ only by extension.

Hi, Everyone, This is now bug 5681. I am debating now if I should change my input files or fix lyx. :-) 1. create a document 2. insert a program listing file 'test.h' (with test content this is test.h) 3. insert another program listing file 'test.i' (with test content this is test.i) 4. (Just

Re: Fail to include files differ only by extension.

On Sat, Jan 10, 2009 at 4:36 PM, Pavel Sanda sa...@lyx.org wrote: Bo Peng wrote: Hi, Everyone, This is now bug 5681. I am debating now if I should change my input files or fix lyx. :-) fix lyx? :) I do not understand why changeExtension is needed for the INPUT type, but it should

Re: [patch] require Python 2.6 for SCons but also for LyX

I started with the SCons script and need the attached patch to get it running. Bo, can this go in or do you want to change more (comments etc.)? You mean scons already supports Python 3.0? Actually, because we distribute a version of Python under window and python 2.x will stay on any *nix

Fail to include files differ only by extension.

Hi, Everyone, This is now bug 5681. I am debating now if I should change my input files or fix lyx. :-) 1. create a document 2. insert a program listing file 'test.h' (with test content this is test.h) 3. insert another program listing file 'test.i' (with test content this is test.i) 4. (Just

Re: Fail to include files differ only by extension.

On Sat, Jan 10, 2009 at 4:36 PM, Pavel Sanda <sa...@lyx.org> wrote: > Bo Peng wrote: >> Hi, Everyone, >> >> This is now bug 5681. I am debating now if I should change my input >> files or fix lyx. :-) > > fix lyx? :) I do not understand why chang

Re: [patch] require Python 2.6 for SCons but also for LyX

> I started with the SCons script and need the attached patch to get it > running. > Bo, can this go in or do you want to change more (comments etc.)? You mean scons already supports Python 3.0? Actually, because we distribute a version of Python under window and python 2.x will stay on any *nix

Re: [Bug 5648] Key-binding for Shifte-Return doesn't work

On Thu, Jan 8, 2009 at 6:58 PM, bugzilla-dae...@aussie.lyx.org wrote: http://bugzilla.lyx.org/show_bug.cgi?id=5648 --- Additional Comments From p...@twin.jikos.cz 2009-01-09 01:58 --- Bo? The fix is trivial. Pavel, could you please submit the attached patch to branch and trunk. (I

Re: [Bug 5648] Key-binding for Shifte-Return doesn't work

On Thu, Jan 8, 2009 at 6:58 PM, wrote: > http://bugzilla.lyx.org/show_bug.cgi?id=5648 > > > --- Additional Comments From p...@twin.jikos.cz 2009-01-09 01:58 --- > Bo? The fix is trivial. Pavel, could you please submit the attached patch to branch and

Re: Patch for branch: rename [io]docfstream to [io]fdocstream

Talking about *stream, I guess you all still remember our boost::iostreams trouble with LyX 1.5.0. I recently figured out (from my own project) why boost::iostreams failed under windows. If you guys are still interested in replacing gzstream with boost::iostreams, I can prepare a patch when I get

Re: Patch for branch: rename [io]docfstream to [io]fdocstream

Talking about *stream, I guess you all still remember our boost::iostreams trouble with LyX 1.5.0. I recently figured out (from my own project) why boost::iostreams failed under windows. If you guys are still interested in replacing gzstream with boost::iostreams, I can prepare a patch when I get

Re: Evaluation of the 1.6 development cycle

Well, what is missing is that if you try to do what INSTALL.* says, you have to download things that don't exist, then you need to do some magic things, andsoforth. I can't give you more details right now, but I'll come back to it later. In addition, INSTALL.scons describes how to use scons

Re: Evaluation of the 1.6 development cycle

> Well, what is missing is that if you try to do what INSTALL.* says, you have > to download things that don't exist, then you need to do some magic things, > andsoforth. I can't give you more details right now, but I'll come back to > it later. In addition, INSTALL.scons describes how to use

Re: Developers Roadmap for 2.0

What feature do you think that LyX is missing badly? Layout editor, because it is painful to define new character layout, and define a new layout for a latex class. Embedding, because it is difficult to share my lyx documents with others. Where do you intend to work during this development

Re: Developers Roadmap for 2.0

> What feature do you think that LyX is missing badly? Layout editor, because it is painful to define new character layout, and define a new layout for a latex class. Embedding, because it is difficult to share my lyx documents with others. > Where do you intend to work during this development

Re: What's the right step to build a windows binary?

Actually, this is the first time I hear the SCons, so I looked it up in wikipeida, then I knew this is a build tool like CMake which I heard before. cmake and scons can both build lyx under windows. cmake has the advantage that it produces a native VC project, but it does not (?) build a

Re: What's the right step to build a windows binary?

> Actually, this is the first time I hear the "SCons", so I looked it up in > wikipeida, then I knew this is a build tool like CMake which I heard before. cmake and scons can both build lyx under windows. cmake has the advantage that it produces a native VC project, but it does not (?) build a

Re: What's the right step to build a windows binary?

Like: 1, install Visual C++ 2008 2, install QT with it's librarys 3, download the SVN source of Lyx 4, use some tools such as CMake or open the vcprj file directly. 5, compile and build the lyx. I have not done it for a while, but with the dependency files (the dependency files and bundle

Re: What's the right step to build a windows binary?

I'm totally new to Lyx, and I even can't find any stuff in more detail. The document on wiki is so simple, so, I still don't know how to do. I just download the package lyx-windows-deps-msvc2008, after unzipped it, I found there are many folder's like: bin lib include qt-4 .. Can

Re: What's the right step to build a windows binary?

> Like: > > 1, install Visual C++ 2008 > 2, install QT with it's librarys > 3, download the SVN source of Lyx > > 4, use some tools such as CMake or open the vcprj file directly. > 5, compile and build the lyx. I have not done it for a while, but with the dependency files (the dependency files

Re: What's the right step to build a windows binary?

> I'm totally new to Lyx, and I even can't find any stuff in more detail. The > document on wiki is so simple, so, I still don't know how to do. > > I just download the package "lyx-windows-deps-msvc2008", after unzipped it, > I found there are many folder's like: > > "bin" "lib" "include" "qt-4"

Re: Plans to announce LyX release 1.6.0

I've uploaded the Windows installers and a new dependency package to http://www.lyx.org/~joost Just tested the non-bundle version, under vista, with administrative privilege, worked perfectly. Bo

Re: Plans to announce LyX release 1.6.0

> I've uploaded the Windows installers and a new dependency package to > http://www.lyx.org/~joost Just tested the non-bundle version, under vista, with administrative privilege, worked perfectly. Bo

Re: partially wrap c++ to interface with python

2008/11/3 gh zhao [EMAIL PROTECTED]: Hello, I need some help. Lyx is too big to read the source code through. I want to know the structure of Lyx. I am writing a python program for my project. I need use boost.python to partially wrap Lyx to interface with python so that I can edit and

Re: partially wrap c++ to interface with python

2008/11/3 gh zhao <[EMAIL PROTECTED]>: > Hello, > I need some help. Lyx is too big to read the source code through. > I want to know the structure of Lyx. > > I am writing a python program for my project. > I need use boost.python to partially wrap Lyx to interface with python so > that I can

Re: Some InsetInfo glitches ...

I assume you mean shortcuts.lyx: only in the (widest) Edit table. See attached. In the userguide there are several occurences (although it's probably worst on the Mac now). Certainely we should not put multiple shrotcutS into an mbox. Maybe make even the normal single-shorcut breakable ...

Re: Some InsetInfo glitches ...

> I assume you mean shortcuts.lyx: only in the (widest) Edit table. See > attached. > > In the userguide there are several occurences (although it's probably worst > on the Mac now). Certainely we should not put multiple shrotcutS into an > mbox. Maybe make even the normal single-shorcut breakable

Re: Some InsetInfo glitches ...

On Fri, Oct 31, 2008 at 8:59 PM, Konrad Hofbauer [EMAIL PROTECTED] wrote: I played with InsetInfo (mostly -shortcut) and found a few bugs. 1) I can set the cursor into an InsetInfo by clicking on it, or by scrolling into it with the up/down cursor keys (not left/right, there it jumps over

Re: Some InsetInfo glitches ...

On Fri, Oct 31, 2008 at 8:59 PM, Konrad Hofbauer <[EMAIL PROTECTED]> wrote: > I played with InsetInfo (mostly -shortcut) and found a few bugs. > > 1) I can set the cursor into an InsetInfo by clicking on it, or by scrolling > into it with the up/down cursor keys (not left/right, there it jumps

Re: Problem with Mac-Key-Symbols (MUSTFIX)

P.S. Admitted, things might get a bit long, but IMO better a suboptimal solution than a non-compilable userguide. And help - shortcuts.py may be too wide under mac. Bo

Re: Problem with Mac-Key-Symbols (MUSTFIX)

On Tue, Oct 28, 2008 at 1:17 PM, Konrad Hofbauer [EMAIL PROTECTED] wrote: Bo Peng wrote: And help - shortcuts.py may be too wide under mac. It seems already too wide (see attached), also with Win/Linux names. I agree, but the document is at least printable/viewable. This might

Re: Problem with Mac-Key-Symbols (MUSTFIX)

> P.S. Admitted, things might get a bit long, but IMO better a suboptimal > solution than a non-compilable userguide. And help -> shortcuts.py may be too wide under mac. Bo

Re: Problem with Mac-Key-Symbols (MUSTFIX)

On Tue, Oct 28, 2008 at 1:17 PM, Konrad Hofbauer <[EMAIL PROTECTED]> wrote: > Bo Peng wrote: >> >> And help -> shortcuts.py may be too wide under mac. > > It seems already too wide (see attached), also with Win/Linux names. I agree, but the document is at least

Re: Problem with Mac-Key-Symbols (MUSTFIX)

2) InsetInfo-shortcut and InsetInfo-shortcuts do not do the same thing with respect to Mac Keybindings. Somebody else will need to fix this. I'll have a look. Thanks. I was concerned with this problem as well but I did not have a mac. Bo

Re: Problem with Mac-Key-Symbols (MUSTFIX)

On Mon, Oct 27, 2008 at 9:15 AM, Jürgen Spitzmüller [EMAIL PROTECTED] wrote: Jean-Marc Lasgouttes wrote: *** For LyX 1.6.0 *** The attached patch. Quick and dirty, but does the job. IMO a MUSTFIX, the userguide should compile. This strikes me as a good idea actually. OTOH the

Re: Problem with Mac-Key-Symbols (MUSTFIX)

> >> 2) InsetInfo->shortcut and InsetInfo->shortcuts do not do the same >> thing with respect to Mac Keybindings. Somebody else will need to fix >> this. > > I'll have a look. Thanks. I was concerned with this problem as well but I did not have a mac. Bo

Re: Problem with Mac-Key-Symbols (MUSTFIX)

On Mon, Oct 27, 2008 at 9:15 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: > Jean-Marc Lasgouttes wrote: >> > *** For LyX 1.6.0 *** >> > The attached patch. >> > Quick and dirty, but does the job. IMO a MUSTFIX, the userguide should >> > compile. >> >> This strikes me as a good idea actually.

Re: rc4 release schedule

Fixed as well. See patch attached in Bugzilla. http://bugzilla.lyx.org/show_bug.cgi?id=5349 is easy to fix as long as someone knows how to quote a string with properly. Bo

Re: rc4 release schedule

> > Fixed as well. See patch attached in Bugzilla. http://bugzilla.lyx.org/show_bug.cgi?id=5349 is easy to fix as long as someone knows how to quote a string with " properly. Bo

Re: oolatex

On Tue, Oct 14, 2008 at 1:54 PM, Joost Verburg [EMAIL PROTECTED] wrote: Jürgen Spitzmüller wrote: Joost Verburg wrote: Is it OK to change this order so oolatex will be the first choice? This was changed intentionally because oolatex failed to work on some systems:

Re: oolatex

Did you try the oolatex command or only the htlatex command that LyX uses? As far as I remember, I used the lyx export (htlatex I assume), and tex4ht command line. I got a .odf file but ooffice cannot open it. Bo

Re: oolatex

On Tue, Oct 14, 2008 at 1:54 PM, Joost Verburg <[EMAIL PROTECTED]> wrote: > Jürgen Spitzmüller wrote: >> >> Joost Verburg wrote: >>> >>> Is it OK to change this order so oolatex will be the first choice? >> >> This was changed intentionally because oolatex failed to work on some >> systems: >> >>

Re: oolatex

> Did you try the oolatex command or only the htlatex command that LyX uses? As far as I remember, I used the lyx export (htlatex I assume), and tex4ht command line. I got a .odf file but ooffice cannot open it. Bo

Re: 3 bugs with InsetInfo

On Sat, Oct 11, 2008 at 8:09 AM, Uwe Stöhr [EMAIL PROTECTED] wrote: While updating the shortcuts in the Userguide, I decided to switch to InsetInfo, but found the following 3 bugs: http://bugzilla.lyx.org/show_bug.cgi?id=5339 http://bugzilla.lyx.org/show_bug.cgi?id=5341

Re: 3 bugs with InsetInfo

On Sat, Oct 11, 2008 at 8:09 AM, Uwe Stöhr <[EMAIL PROTECTED]> wrote: > While updating the shortcuts in the Userguide, I decided to switch to > InsetInfo, but found the following 3 bugs: > http://bugzilla.lyx.org/show_bug.cgi?id=5339 > http://bugzilla.lyx.org/show_bug.cgi?id=5341 >

Re: LyX's shortcut notation is inconsistent

On Fri, Oct 10, 2008 at 9:48 AM, Uwe Stöhr [EMAIL PROTECTED] wrote: While updating the docs to follow the current shortcut notation, I noticed that it is not correct: We use Alt+D. This implies to use Alt+Shift+d. To be consistent, we should use either Alt+d or ALT+D IIRC, M+D is the same

Re: LyX's shortcut notation is inconsistent

On Fri, Oct 10, 2008 at 9:48 AM, Uwe Stöhr <[EMAIL PROTECTED]> wrote: > While updating the docs to follow the current shortcut notation, I noticed > that it is not correct: > > We use "Alt+D". This implies to use "Alt+Shift+d". To be consistent, we > should use either > "Alt+d" > or > "ALT+D"

Re: [patch] Fix bug 5297

On Tue, Sep 30, 2008 at 1:43 AM, Enrico Forestieri [EMAIL PROTECTED] wrote: Please, see http://bugzilla.lyx.org/show_bug.cgi?id=5297 for background info. Before the introduction of InsetInfo, the LaTeXConfig.lyx file was being generated from the template LaTeXConfig.lyx.in by replacing strings

Re: [patch] Fix bug 5297

On Tue, Sep 30, 2008 at 1:43 AM, Enrico Forestieri <[EMAIL PROTECTED]> wrote: > Please, see http://bugzilla.lyx.org/show_bug.cgi?id=5297 for background info. > > Before the introduction of InsetInfo, the LaTeXConfig.lyx file was being > generated from the template LaTeXConfig.lyx.in by replacing

Re: Multiple Key Bindings

yes, then we could do that. But note that there'd be no way to manage the order of the bindings then, and no indication of what they are. So I'm inclined not to allow adding a binding via the shortcut panel unless those problems are solved. And maybe we could also disallow rebinding a key

Re: Multiple Key Bindings

On Tue, Sep 23, 2008 at 8:06 PM, Bennett Helm [EMAIL PROTECTED] wrote: On Tue, Sep 23, 2008 at 9:00 PM, Bo Peng [EMAIL PROTECTED] wrote: I can have a look at the code at the end of this week if needed. Bo - while you're at it, can you have a look at: http://bugzilla.lyx.org/show_bug.cgi?id

Re: Multiple Key Bindings

>> yes, then we could do that. But note that there'd be no way to manage the >> order of the bindings then, and no indication of what they are. So I'm >> inclined not to allow "adding" a binding via the shortcut panel unless >> those problems are solved. And maybe we could also disallow rebinding

Re: Multiple Key Bindings

On Tue, Sep 23, 2008 at 8:06 PM, Bennett Helm <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 9:00 PM, Bo Peng <[EMAIL PROTECTED]> wrote: >> >> I can have a look at the code at the end of this week if needed. > > Bo - while you're at it, can you have a l

Re: [patch] Tabbing in listings

I think it is about how LyX displays the tabs. Now, the tabs are painted by QPainter and the cursor movement is guided by QFontMetrics. I tried to paint the tabs and to guide the cursor myself, but this lead to (for me) ununderstandable crashes. If you know how we can override the default

Re: [patch] Tabbing in listings

> I think it is about how LyX displays the tabs. Now, the tabs are painted by > QPainter and the cursor movement is guided by QFontMetrics. I tried to paint > the tabs and to guide the cursor myself, but this lead to (for me) > ununderstandable crashes. If you know how we can override the

Re: Fixing completion

On Sun, Sep 7, 2008 at 4:39 PM, Pavel Sanda [EMAIL PROTECTED] wrote: Stefan Schimanski wrote: Attached is a patch to replace the manual interception of keys with proper LFUNs. In fact one half of it was already implemented. Now you can also set the key to hide the popup/inline completion.

Re: Fixing completion

yes, if i manually put Tab into bind file, it starts working. when i try to use Tab via shortcuts panel, then i see \bind complete Is the rest of the patch working, and in the trunk? I can fix the shortcut dialog later. Cheers, Bo

Re: [patch] Tabbing in listings

The TAB width should be consistent for all listings in a document. You are right, that some prefer 3 characters, some 4, some only 2. So what we need is an item in the listings dialog in the document settings. 4 should be the default. The current 8 characters width is definitively too wide to

Re: Fixing completion

On Sun, Sep 7, 2008 at 4:39 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote: > Stefan Schimanski wrote: >> Attached is a patch to replace the manual interception of keys with proper >> LFUNs. In fact one half of it was already implemented. Now you can also set >> the key to hide the popup/inline

Re: Fixing completion

> yes, if i manually put Tab into bind file, it starts working. > when i try to use Tab via shortcuts panel, then i see > \bind " " "complete" Is the rest of the patch working, and in the trunk? I can fix the shortcut dialog later. Cheers, Bo

Re: [patch] Tabbing in listings

> The TAB width should be consistent for all listings in a document. You are > right, that some prefer 3 characters, some 4, some only 2. So what we need > is an item in the listings dialog in the document settings. 4 should be the > default. > The current 8 characters width is definitively too

<    1   2   3   4   5   6   7   8   9   10   >