On Sun, Jan 03, 2016 at 11:46:04AM -0500, Richard Heck wrote:
> On 01/03/2016 11:18 AM, Scott Kostyshak wrote:
> > On Sun, Jan 03, 2016 at 11:01:42AM -0500, Richard Heck wrote:
> >> On 01/03/2016 10:59 AM, Scott Kostyshak wrote:
> >>> On Sun, Jan 03, 2016 at 02:37:23PM +0100, Jean-Marc Lasgouttes w
On 01/03/2016 11:18 AM, Scott Kostyshak wrote:
> On Sun, Jan 03, 2016 at 11:01:42AM -0500, Richard Heck wrote:
>> On 01/03/2016 10:59 AM, Scott Kostyshak wrote:
>>> On Sun, Jan 03, 2016 at 02:37:23PM +0100, Jean-Marc Lasgouttes wrote:
Le 03/01/2016 10:15, Scott Kostyshak a écrit :
>> Attac
On Sun, Jan 03, 2016 at 11:01:42AM -0500, Richard Heck wrote:
> On 01/03/2016 10:59 AM, Scott Kostyshak wrote:
> > On Sun, Jan 03, 2016 at 02:37:23PM +0100, Jean-Marc Lasgouttes wrote:
> >> Le 03/01/2016 10:15, Scott Kostyshak a écrit :
> Attached patch OK? If so, I would put it in at the begi
On 01/03/2016 10:59 AM, Scott Kostyshak wrote:
> On Sun, Jan 03, 2016 at 02:37:23PM +0100, Jean-Marc Lasgouttes wrote:
>> Le 03/01/2016 10:15, Scott Kostyshak a écrit :
Attached patch OK? If so, I would put it in at the beginning of the
2.3.0 cycle.
From 0edbc7f52f4ecb288389e94f87e73
On Sun, Jan 03, 2016 at 02:37:23PM +0100, Jean-Marc Lasgouttes wrote:
> Le 03/01/2016 10:15, Scott Kostyshak a écrit :
> >>Attached patch OK? If so, I would put it in at the beginning of the
> >>2.3.0 cycle.
> >
> >> From 0edbc7f52f4ecb288389e94f87e7388d5c466166 Mon Sep 17 00:00:00 2001
> >>From: S
Le 03/01/2016 10:15, Scott Kostyshak a écrit :
Attached patch OK? If so, I would put it in at the beginning of the
2.3.0 cycle.
From 0edbc7f52f4ecb288389e94f87e7388d5c466166 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak
Date: Fri, 18 Dec 2015 21:58:22 -0500
Subject: [PATCH] Do not initializ
On Fri, Dec 18, 2015 at 10:13:29PM -0500, Scott Kostyshak wrote:
> On Thu, Dec 10, 2015 at 05:52:15PM -0500, Richard Heck wrote:
> > On 12/10/2015 03:09 AM, Scott Kostyshak wrote:
> > > On Wed, Dec 09, 2015 at 10:10:42AM +0100, Jean-Marc Lasgouttes wrote:
> > >> Le 09/12/2015 06:54, Scott Kostyshak
On Thu, Dec 10, 2015 at 05:52:15PM -0500, Richard Heck wrote:
> On 12/10/2015 03:09 AM, Scott Kostyshak wrote:
> > On Wed, Dec 09, 2015 at 10:10:42AM +0100, Jean-Marc Lasgouttes wrote:
> >> Le 09/12/2015 06:54, Scott Kostyshak a écrit :
> >>> Regarding the following code:
> >>>
> >>> -
> >>> vo
On 12/10/2015 03:09 AM, Scott Kostyshak wrote:
> On Wed, Dec 09, 2015 at 10:10:42AM +0100, Jean-Marc Lasgouttes wrote:
>> Le 09/12/2015 06:54, Scott Kostyshak a écrit :
>>> Regarding the following code:
>>>
>>> -
>>> void Text::selectWord(Cursor & cur, word_location loc)
>>> {
>>> LBUFERR(thi
On Wed, Dec 09, 2015 at 10:10:42AM +0100, Jean-Marc Lasgouttes wrote:
> Le 09/12/2015 06:54, Scott Kostyshak a écrit :
> >Regarding the following code:
> >
> >-
> >void Text::selectWord(Cursor & cur, word_location loc)
> >{
> > LBUFERR(this == cur.text());
> > CursorSlice from = cur.top();
Le 09/12/2015 06:54, Scott Kostyshak a écrit :
Regarding the following code:
-
void Text::selectWord(Cursor & cur, word_location loc)
{
LBUFERR(this == cur.text());
CursorSlice from = cur.top();
CursorSlice to = cur.top();
getWord(from, to, loc);
-
It is not easy to know whe
On 12/09/2015 12:54 AM, Scott Kostyshak wrote:
> Regarding the following code:
>
> -
> void Text::selectWord(Cursor & cur, word_location loc)
> {
> LBUFERR(this == cur.text());
> CursorSlice from = cur.top();
> CursorSlice to = cur.top();
> getWord(from, to, loc);
> -
>
> It is not
On Thu, Oct 17, 2002 at 05:25:22PM +0200, Lars Gullik Bjønnes wrote:
> qttableview is bad... but that is a qt file... why do we have it in
> our tree?
Because we use it, obviously.
john
--
"It's a cardboard universe ... and if you lean too hard against it, you fall
through."
- Philip
> > I just browsed through the qt code and encontered some code (QBrowseBox
> > and others) that's done using some style that's not even close to "LyX
> > Standard".
qbrowsebox is not my code but Kalle's (qkbrowser.[Ch] from klyx)
> Others ? Please name them explicitly. Edwin - can you please cle
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Oct 17, 2002 at 05:25:22PM +0200, Lars Gullik Bjønnes wrote:
>
>> qttableview is bad... but that is a qt file... why do we have it in
>> our tree?
>
| Because we use it, obviously.
Why is it taken out of the qt sources so that we can include it? Is
On Thu, Oct 17, 2002 at 05:48:36PM +0200, Lars Gullik Bjønnes wrote:
> Why is it taken out of the qt sources so that we can include it? Is it
> not part of any QT version?
It is not included in the Qt 3 library.
regards
john
--
"It's a cardboard universe ... and if you lean too hard against it,
On Thu, Oct 17, 2002 at 09:37:57AM +0200, Andre Poenitz wrote:
> I just browsed through the qt code and encontered some code (QBrowseBox
> and others) that's done using some style that's not even close to "LyX
> Standard".
Others ? Please name them explicitly. Edwin - can you please clean this
u
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 17, 2002 at 03:58:08PM +0100, John Levon wrote:
>> Others ? Please name them explicitly. Edwin - can you please clean this
>> up ?
>
| Small things. In the time I search for them I could fix it myself.
| I think BrowseBox was really the worst
On Thu, Oct 17, 2002 at 03:58:08PM +0100, John Levon wrote:
> Others ? Please name them explicitly. Edwin - can you please clean this
> up ?
Small things. In the time I search for them I could fix it myself.
I think BrowseBox was really the worst.
Andre'
--
Those who desire to give up Freedom i
On Tue, Dec 04, 2001 at 06:03:52PM +1000, Allan Rae wrote:
> Because by "any length" I also meant really simple stuff like for
> example:
>
> if (p
> && !p->empty()) {
> }
I find this much more disruptive to read than
if (p && !p->empty()) {
}
Actually, th
On Tue, 4 Dec 2001, Andre Poenitz wrote:
> On Tue, Dec 04, 2001 at 03:57:34PM +1000, Allan Rae wrote:
> > preferred. Like this one instead of above?
> >
> > if (any length a && any length b && any length c) {
> > }
>
> If it fits on a line, it should be ok. But then, why don't you put the test
>
On Tue, Dec 04, 2001 at 03:57:34PM +1000, Allan Rae wrote:
> preferred. Like this one instead of above?
>
> if (any length a && any length b && any length c) {
> }
If it fits on a line, it should be ok. But then, why don't you put the test
in some function with some meaningful name and write
On Mon, 3 Dec 2001, Juergen Vigna wrote:
>
> On 03-Dec-2001 John Levon wrote:
>
> > what's with the bogus change to the bracing in my changes to
> > BufferView_pimpl.C:checkInsetHit() ?
>
> if you have multiple lines in a () then the opening { should go on it's
> own line, at least that is what I
Patch ok?
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
Index: Recommendations
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/Code_rules/Recommendations,v
retrieving revision
On Mon, Dec 03, 2001 at 04:27:04PM +0100, Lars Gullik Bjønnes wrote:
> btw. very long if's is most often a symphtom that something else is
> wrong.
I think we should start at this point.
"Avoid conditions that span more than a line" in Recommendations?
Andre'
--
André Pönitz .
On Mon, Dec 03, 2001 at 04:27:04PM +0100, Lars Gullik Bjønnes wrote:
> btw. very long if's is most often a symphtom that something else is
> wrong.
normally a temporary variable should be used, or a separate function for
the test returning a bool
john
--
"Faced with the prospect of rerea
On Mon, Dec 03, 2001 at 04:20:45PM +0100, Juergen Vigna wrote:
> if you have multiple lines in a () then the opening { should go on it's
> own line, at least that is what I do because otherwise I sometimes don't
> see where a block starts.
/me doesn't spot anything in codingstyle about that ...
On 03-Dec-2001 John Levon wrote:
> what's with the bogus change to the bracing in my changes to
> BufferView_pimpl.C:checkInsetHit() ?
if you have multiple lines in a () then the opening { should go on it's
own line, at least that is what I do because otherwise I sometimes don't
see where a blo
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > (*iterator).whatever
| >
| > rather than :
| >
| > iterator->whatever
| >
| > IMHO it's harder to type and read ...
|
| I don't know. I use the latter...
Of course anotehr reason to use (*it).afd
is that this shows rather explicilty that
> (*iterator).whatever
>
> rather than :
>
> iterator->whatever
>
> IMHO it's harder to type and read ...
I don't know. I use the latter...
Andre'
--
André Pönitz [EMAIL PROTECTED]
On 9 Mar 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | Why are people using :
> |
> | (*iterator).whatever
> |
> | rather than :
> |
> | iterator->whatever
> |
> | IMHO it's harder to type and read ...
>
> gcc 2.7.2 did not support the -> operator f
Hi,
On Fri, 9 Mar 2001, John Levon wrote:
JL| Why are people using :
JL|
JL| (*iterator).whatever
JL|
JL| rather than :
JL|
JL| iterator->whatever
the operator-> requires to return a pointer .. which is sometimes not
possible to implement in an iterator, specifically, if the iterator
John Levon <[EMAIL PROTECTED]> writes:
| Why are people using :
|
| (*iterator).whatever
|
| rather than :
|
| iterator->whatever
|
| IMHO it's harder to type and read ...
gcc 2.7.2 did not support the -> operator for iterators.
but we can switch now.
Lgb
On Wed, 1 Dec 1999, Fabio Scardigli wrote:
> Dear Sirs,
>
> I have the LyX version 1.0.4 (downloaded from your Primary LyX Site).
> I have also LaTex 2.09 (or LaTex 2e).
>
> I would like to use the style file "espcrc2.sty" within LyX.
I'm not familiar with this style but from your description
On Tue, Apr 20, 1999 at 09:55:10AM +0200, Roman Maurer wrote:
> John Weiss wrote:
> >
> > [...] The founder/head of every Translation Project must provide
> > an Addendum to the Style Sheet, in his native tongue. [...]
>
> Do you plan to include this addendums in the Style Sheet itself?
> This
> "John" == John Weiss <[EMAIL PROTECTED]> writes:
John> Attached below is the latest version of the Documentation Style
John> Sheet. It now contains a new section designed to aid
John> translators.
Commited to cvs.
JMarc
John Weiss wrote:
>
> [...] The founder/head of every Translation Project must provide
> an Addendum to the Style Sheet, in his native tongue. [...]
Do you plan to include this addendums in the Style Sheet itself?
This is impossible unless new versions of LyX support Unicode.
Different nations
37 matches
Mail list logo
