Pavel Sanda wrote:
i just tried this patch and seems to work correctly.
Works fine for me too. Attached is the patch against current trunk.
if there are no other comments, i'll put it in.
lfuns will be sorted later.
I wonder if something needs to be done on reversion to 1.5.x. IOW, is
Pavel Sanda wrote:
i just tried this patch and seems to work correctly.
Works fine for me too. Attached is the patch against current trunk.
if there are no other comments, i'll put it in.
lfuns will be sorted later.
I wonder if something needs to be done on reversion to 1.5.x. IOW, is
On Friday 26 September 2008 14:18:03 Vincent van Ravesteijn - TNW wrote:
Lyx 1.6.0svn didn't support tabs either. It writes the tabs into the
.lyx file, but only reading a .lyx file didn't work properly. I solved
this by just adding two terms to Lexer.cpp (see below)
Isn't this the same for
Uwe Stöhr wrote:
This is not really a fileformat change. When you revert a listing to LyX
1.5, the TABs will be erased as LyX 1.5 doesn't support TABs. But what I
can do is to try to convert the TABs via lyx2lyx to 4 spaces. Should I do
this?
Yes, if the output is sufficient.
In any case, I'd
Vincent van Ravesteijn - TNW schrieb:
Lyx 1.6.0svn didn't support tabs either. It writes the tabs into the
.lyx file, but only reading a .lyx file didn't work properly. I solved
this by just adding two terms to Lexer.cpp (see below)
I see here still a problem:
A TAB is by default 8 characters
Lyx 1.6.0svn didn't support tabs either. It writes the tabs into the
.lyx file, but only reading a .lyx file didn't work properly. I
solved
this by just adding two terms to Lexer.cpp (see below)
I see here still a problem:
A TAB is by default 8 characters long in a textfile. But this makes
Vincent van Ravesteijn - TNW schrieb:
This can be set via de listings-option
tabsize=4.
The default tabsize defined in the listings package is 8. This means we
should add tabsize=4 as a default option, but we have to make sure that
the user can override this. It is probably the best to
That it won't be lost: Attached is the complete patch against current trunk including the fileformat
and lyx2lyx stuff. As José decided, this won't go in before rc3 is out.
regards Uwe
Index: development/FORMAT
===
---
Just or information, I found btw. a crash bug in listings
(independent of your work I think):
http://bugzilla.lyx.org/show_bug.cgi?id=5287
regards Uwe
I think I'll pass this to Jmarc, it has to do something with:
Just or information, I found btw. a crash bug in listings (independent
of your work I think):
http://bugzilla.lyx.org/show_bug.cgi?id=5287
regards Uwe
I pass this one to JMarc. It has something to do with:
http://www.lyx.org/trac/changeset/26428
Vincent
>> Pavel Sanda wrote:
>>
>> i just tried this patch and seems to work correctly.
Works fine for me too. Attached is the patch against current trunk.
>> if there are no other comments, i'll put it in.
>> lfuns will be sorted later.
>
> I wonder if something needs to be done on reversion to
>>> Pavel Sanda wrote:
>>>
>>> i just tried this patch and seems to work correctly.
>
>Works fine for me too. Attached is the patch against current trunk.
>
>>> if there are no other comments, i'll put it in.
>>> lfuns will be sorted later.
>>
>> I wonder if something needs to be done on
On Friday 26 September 2008 14:18:03 Vincent van Ravesteijn - TNW wrote:
> Lyx 1.6.0svn didn't support tabs either. It writes the tabs into the
> .lyx file, but only reading a .lyx file didn't work properly. I solved
> this by just adding two terms to Lexer.cpp (see below)
>
> Isn't this the same
Uwe Stöhr wrote:
> This is not really a fileformat change. When you revert a listing to LyX
> 1.5, the TABs will be erased as LyX 1.5 doesn't support TABs. But what I
> can do is to try to convert the TABs via lyx2lyx to 4 spaces. Should I do
> this?
Yes, if the output is sufficient.
In any case,
Vincent van Ravesteijn - TNW schrieb:
Lyx 1.6.0svn didn't support tabs either. It writes the tabs into the
.lyx file, but only reading a .lyx file didn't work properly. I solved
this by just adding two terms to Lexer.cpp (see below)
I see here still a problem:
A TAB is by default 8 characters
>> Lyx 1.6.0svn didn't support tabs either. It writes the tabs into the
>> .lyx file, but only reading a .lyx file didn't work properly. I
solved
>> this by just adding two terms to Lexer.cpp (see below)
>
>I see here still a problem:
>A TAB is by default 8 characters long in a textfile. But
Vincent van Ravesteijn - TNW schrieb:
This can be set via de listings-option
tabsize=4.
The default tabsize defined in the listings package is 8. This means we
should add tabsize=4 as a default option, but we have to make sure that
the user can override this. It is probably the best to
That it won't be lost: Attached is the complete patch against current trunk including the fileformat
and lyx2lyx stuff. As José decided, this won't go in before rc3 is out.
regards Uwe
Index: development/FORMAT
===
---
> Just or information, I found btw. a crash bug in listings
>(independent of your work I think):
> http://bugzilla.lyx.org/show_bug.cgi?id=5287
>
> regards Uwe
I think I'll pass this to Jmarc, it has to do something with:
> Just or information, I found btw. a crash bug in listings (independent
>of your work I think):
> http://bugzilla.lyx.org/show_bug.cgi?id=5287
>
> regards Uwe
I pass this one to JMarc. It has something to do with:
http://www.lyx.org/trac/changeset/26428
Vincent
On 25/09/2008 00:53, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
-
-
+ { LFUN_LISTINGS_TAB_INSERT, listings-tab-insert,
SingleParUpdate, Edit },
maybe we can use LFUN_TAB_INSERT, so we can re-use it somewhere else when
needed?
What about
Vincent van Ravesteijn - TNW wrote:
Shift-Tab aka. BackTab; it should be used in a Listing inset, when the
cursor is right after a space or Tab or when there is a selection.
so the only difference to the current backspace is that it also knows
to eat 4 spaces in one step, right? i'm not sure
Abdelrazak Younes wrote:
+ { LFUN_LISTINGS_TAB_INSERT, listings-tab-insert,
SingleParUpdate,
Edit },
maybe we can use LFUN_TAB_INSERT, so we can re-use it somewhere else when
needed?
What about LFUN_UNICODE_INSERT? (unicode-insert put here the symbol for
tab).
Shift-Tab aka. BackTab; it should be used in a Listing inset, when
the
cursor is right after a space or Tab or when there is a selection.
so the only difference to the current backspace is that it also knows
to eat 4 spaces in one step, right? i'm not sure this is not
overdesigned, just to
Vincent van Ravesteijn - TNW wrote:
No, it also works on a selection, then it eats a tab or spaces from the
beginning of each line spanned by the selection. This is extremely
useful if you want to indent/unindent multiple lines in one action.
doxy, doxy, doxy ! :)
pavel
Vincent van Ravesteijn wrote:
Et voila, .. (oh no, no more french on the list...)
i just tried this patch and seems to work correctly.
if there are no other comments, i'll put it in.
lfuns will be sorted later.
pavel
Vincent van Ravesteijn wrote:
+ LASSERT(pit paragraphs().size(), /**/);
+ LASSERT( pit paragraphs().size(), /**/ );
+ LASSERT(cur.pit() = 0 cur.pit()
paragraphs().size(), /**/);
btw gcc gives warnings about those
On 25/09/2008 13:37, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
+ LASSERT(pit paragraphs().size(), /**/);
+ LASSERT( pit paragraphs().size(), /**/ );
+ LASSERT(cur.pit()= 0 cur.pit()
Abdelrazak Younes [EMAIL PROTECTED] writes:
Make that a pit int(paragraphs().size()). But this kind of assertion is not
needed, this is already detected in debug mode by the stl.
But why is pit an int?
JMarc
On 25/09/2008 14:32, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes[EMAIL PROTECTED] writes:
Make that a pit int(paragraphs().size()). But this kind of assertion is not
needed, this is already detected in debug mode by the stl.
But why is pit an int?
That's historical:
Abdelrazak Younes [EMAIL PROTECTED] writes:
That's historical: pit_type == pos_type == int
From what I remember, there was a reason for pos (we use -1 to get
labelfont, or something), but not for pit, is it?
JMarc
On 25/09/2008 15:04, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes[EMAIL PROTECTED] writes:
That's historical: pit_type == pos_type == int
From what I remember, there was a reason for pos (we use -1 to get
labelfont, or something), but not for pit, is it?
AFAIR, the only
Abdelrazak Younes [EMAIL PROTECTED] writes:
AFAIR, the only reason that was given to me when I wanted to change
pit_type to size_t is that we are not sure of out of bound issues that
may appear in loops. I am quite confident nowadays that there will be
no such issue. So fine with me if you
On 25/09/2008 15:16, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes[EMAIL PROTECTED] writes:
AFAIR, the only reason that was given to me when I wanted to change
pit_type to size_t is that we are not sure of out of bound issues that
may appear in loops. I am quite confident nowadays that
Pavel Sanda wrote:
Et voila, .. (oh no, no more french on the list...)
i just tried this patch and seems to work correctly.
if there are no other comments, i'll put it in.
lfuns will be sorted later.
I wonder if something needs to be done on reversion to 1.5.x. IOW, is this a
file format
On 25/09/2008 00:53, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
-
-
+ { LFUN_LISTINGS_TAB_INSERT, "listings-tab-insert",
SingleParUpdate, Edit },
maybe we can use LFUN_TAB_INSERT, so we can re-use it somewhere else when
needed?
What about
Vincent van Ravesteijn - TNW wrote:
> Shift-Tab aka. BackTab; it should be used in a Listing inset, when the
> cursor is right after a space or Tab or when there is a selection.
so the only difference to the current backspace is that it also knows
to eat 4 spaces in one step, right? i'm not sure
Abdelrazak Younes wrote:
>>> + { LFUN_LISTINGS_TAB_INSERT, "listings-tab-insert",
>>> SingleParUpdate,
>>> Edit },
>>>
>>
>> maybe we can use LFUN_TAB_INSERT, so we can re-use it somewhere else when
>> needed?
>>
>
> What about LFUN_UNICODE_INSERT? (unicode-insert tab>).
>> Shift-Tab aka. BackTab; it should be used in a Listing inset, when
the
>> cursor is right after a space or Tab or when there is a selection.
>
>so the only difference to the current backspace is that it also knows
>to eat 4 spaces in one step, right? i'm not sure this is not
> overdesigned,
Vincent van Ravesteijn - TNW wrote:
> No, it also works on a selection, then it eats a tab or spaces from the
> beginning of each line spanned by the selection. This is extremely
> useful if you want to indent/unindent multiple lines in one action.
doxy, doxy, doxy ! :)
pavel
Vincent van Ravesteijn wrote:
> Et voila, .. (oh no, no more french on the list...)
i just tried this patch and seems to work correctly.
if there are no other comments, i'll put it in.
lfuns will be sorted later.
pavel
Vincent van Ravesteijn wrote:
> + LASSERT(pit < paragraphs().size(), /**/);
> + LASSERT( pit < paragraphs().size(), /**/ );
> + LASSERT(cur.pit() >= 0 && cur.pit() <
> paragraphs().size(), /**/);
btw gcc gives warnings
On 25/09/2008 13:37, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
+ LASSERT(pit< paragraphs().size(), /**/);
+ LASSERT( pit< paragraphs().size(), /**/ );
+ LASSERT(cur.pit()>= 0&& cur.pit()<
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Make that a pit< int(paragraphs().size()). But this kind of assertion is not
> needed, this is already detected in debug mode by the stl.
But why is pit an int?
JMarc
On 25/09/2008 14:32, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes<[EMAIL PROTECTED]> writes:
Make that a pit< int(paragraphs().size()). But this kind of assertion is not
needed, this is already detected in debug mode by the stl.
But why is pit an int?
That's historical:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> That's historical: pit_type == pos_type == int
>From what I remember, there was a reason for pos (we use -1 to get
labelfont, or something), but not for pit, is it?
JMarc
On 25/09/2008 15:04, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes<[EMAIL PROTECTED]> writes:
That's historical: pit_type == pos_type == int
> From what I remember, there was a reason for pos (we use -1 to get
labelfont, or something), but not for pit, is it?
AFAIR, the only
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> AFAIR, the only reason that was given to me when I wanted to change
> pit_type to size_t is that we are not sure of out of bound issues that
> may appear in loops. I am quite confident nowadays that there will be
> no such issue. So fine with me if
On 25/09/2008 15:16, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes<[EMAIL PROTECTED]> writes:
AFAIR, the only reason that was given to me when I wanted to change
pit_type to size_t is that we are not sure of out of bound issues that
may appear in loops. I am quite confident nowadays that
Pavel Sanda wrote:
>> Et voila, .. (oh no, no more french on the list...)
>
> i just tried this patch and seems to work correctly.
> if there are no other comments, i'll put it in.
> lfuns will be sorted later.
I wonder if something needs to be done on reversion to 1.5.x. IOW, is this a
file
Vincent van Ravesteijn - TNW wrote:
Here it is. It allows :
-inserting tabs,
-removing tabs and spacing by backtab,
-copying code with tabs from other applications.
Vincent, have you worked on this lately? if we want to have it in before rc3,
the time is short :)
pavel
Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
Here it is. It allows :
-inserting tabs,
-removing tabs and spacing by backtab,
-copying code with tabs from other applications.
Vincent, have you worked on this lately? if we want to have it in
before rc3,
the time is
Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
Here it is. It allows :
-inserting tabs,
-removing tabs and spacing by backtab,
-copying code with tabs from other applications.
Vincent, have you worked on this lately? if we want to have it in
before rc3,
the time is
Vincent van Ravesteijn wrote:
PS. I still used the 'old' LFUNs, I didn't want to stir the patch too
much.. so small steps at a time (changing the LFUNs is not a large
change to this patch).
An attempt to add two LFUNs for tabbing is Listings. If you like the
names (I'm never that good in
Vincent van Ravesteijn wrote:
Vincent van Ravesteijn wrote:
PS. I still used the 'old' LFUNs, I didn't want to stir the patch too
much.. so small steps at a time (changing the LFUNs is not a large
change to this patch).
An attempt to add two LFUNs for tabbing is Listings. If you like the
Vincent van Ravesteijn wrote:
-
-
+ { LFUN_LISTINGS_TAB_INSERT, listings-tab-insert,
SingleParUpdate, Edit },
maybe we can use LFUN_TAB_INSERT, so we can re-use it somewhere else when
needed?
+/*!
+ * \var lyx::FuncCode lyx::LFUN_LISTINGS_TAB_DELETE
+ * \li Action: Delete a
-
-
+{ LFUN_LISTINGS_TAB_INSERT, listings-tab-insert,
SingleParUpdate,
+Edit },
maybe we can use LFUN_TAB_INSERT, so we can re-use it somewhere else
when needed?
Is possible..
+/*!
+ * \var lyx::FuncCode lyx::LFUN_LISTINGS_TAB_DELETE
+ * \li Action: Delete a tab or upto an
Vincent van Ravesteijn - TNW wrote:
> Here it is. It allows :
> -inserting tabs,
> -removing tabs and spacing by backtab,
> -copying code with tabs from other applications.
Vincent, have you worked on this lately? if we want to have it in before rc3,
the time is short :)
pavel
Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
> Here it is. It allows :
> -inserting tabs,
> -removing tabs and spacing by backtab,
> -copying code with tabs from other applications.
Vincent, have you worked on this lately? if we want to have it in
before rc3,
the time
Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
> Here it is. It allows :
> -inserting tabs,
> -removing tabs and spacing by backtab,
> -copying code with tabs from other applications.
Vincent, have you worked on this lately? if we want to have it in
before rc3,
the time
Vincent van Ravesteijn wrote:
PS. I still used the 'old' LFUNs, I didn't want to stir the patch too
much.. so small steps at a time (changing the LFUNs is not a large
change to this patch).
An attempt to add two LFUNs for tabbing is Listings. If you like the
names (I'm never that good in
Vincent van Ravesteijn wrote:
Vincent van Ravesteijn wrote:
>
> PS. I still used the 'old' LFUNs, I didn't want to stir the patch too
> much.. so small steps at a time (changing the LFUNs is not a large
> change to this patch).
>
An attempt to add two LFUNs for tabbing is Listings. If you like
Vincent van Ravesteijn wrote:
> -
> -
> + { LFUN_LISTINGS_TAB_INSERT, "listings-tab-insert",
> SingleParUpdate, Edit },
maybe we can use LFUN_TAB_INSERT, so we can re-use it somewhere else when
needed?
> +/*!
> + * \var lyx::FuncCode lyx::LFUN_LISTINGS_TAB_DELETE
> + * \li Action:
>> -
>> -
>> +{ LFUN_LISTINGS_TAB_INSERT, "listings-tab-insert",
SingleParUpdate,
>> +Edit },
>
>maybe we can use LFUN_TAB_INSERT, so we can re-use it somewhere else
when needed?
>
Is possible..
>> +/*!
>> + * \var lyx::FuncCode lyx::LFUN_LISTINGS_TAB_DELETE
>> + * \li Action:
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
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
>> 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
> 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
Vincent van Ravesteijn - TNW wrote:
src/frontends/qt4/GuiFontMetrics.cpp :
The line metrics_.width(ucs4_to_qchar(c)) wasn't working properly for
tabs
(returned the size of a single space instead of 8). That's why { c !=
'\t'} is
necessary in the following:
i would put that
Vincent van Ravesteijn - TNW schrieb:
Here it is. It allows :
-inserting tabs,
-removing tabs and spacing by backtab,
-copying code with tabs from other applications.
Pasting C++ Code to a listings inset doesn't work:
Try to copy this code
~Impl()
{
Pasting C++ Code to a listings inset doesn't work:
Actually, it does work. Did you try Edit-Paste Special-Plain Text (or
Ctrl-Shift-V). It looks like that Paste is binded to Paste, Join Lines
or something like that.
Looks sensible. The size of a TAB is the width of 8 typewriter
characters.
Vincent van Ravesteijn - TNW schrieb:
Pasting C++ Code to a listings inset doesn't work:
Actually, it does work. Did you try Edit-Paste Special-Plain Text (or
Ctrl-Shift-V). It looks like that Paste is binded to Paste, Join Lines
or something like that.
Yes my fault, I used Ctrl-v not
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
Vincent van Ravesteijn - TNW wrote:
> src/frontends/qt4/GuiFontMetrics.cpp :
>
>The line "metrics_.width(ucs4_to_qchar(c))" wasn't working properly for
> tabs
>(returned the size of a single space instead of 8). That's why {&& c !=
> '\t'} is
>necessary in the following:
i would
Vincent van Ravesteijn - TNW schrieb:
Here it is. It allows :
-inserting tabs,
-removing tabs and spacing by backtab,
-copying code with tabs from other applications.
Pasting C++ Code to a listings inset doesn't work:
Try to copy this code
~Impl()
{
>> Pasting C++ Code to a listings inset doesn't work:
Actually, it does work. Did you try Edit->Paste Special->Plain Text (or
Ctrl-Shift-V). It looks like that Paste is binded to "Paste, Join Lines"
or something like that.
> Looks sensible. The size of a TAB is the width of 8 typewriter
>
Vincent van Ravesteijn - TNW schrieb:
Pasting C++ Code to a listings inset doesn't work:
Actually, it does work. Did you try Edit->Paste Special->Plain Text (or
Ctrl-Shift-V). It looks like that Paste is binded to "Paste, Join Lines"
or something like that.
Yes my fault, I used Ctrl-v not
> 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
78 matches
Mail list logo
