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.
===
--- 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
> 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
>
> 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
> 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.
> 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.
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.
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'
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
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.
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
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
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
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.
> 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'
> 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
> 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
>>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
>> 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
>
> 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
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
> 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'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
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
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
> 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
> 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
> 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
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
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
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
> 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
> 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
> 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
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
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
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
>
>> 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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
> 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
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
> 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
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
> 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
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
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
> 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
> 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"
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
> 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
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
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
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 ...
> 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
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
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
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
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
> 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
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
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
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
>
>> 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
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.
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
>
> 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
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:
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
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:
>>
>>
> 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
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
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
>
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
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"
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
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
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
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
>> 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
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
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
> 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
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.
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
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
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
> 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
> 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
101 - 200 of 8038 matches
Mail list logo