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
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 whether "to" and "from" are equal to each other because
On Wed, Jan 08, 2003 at 11:32:10AM +0100, Andre Poenitz wrote:
> I don't use emacs. This 'default' is unreadable for me unless I set
> tabstop==8 (I usually have *shriek* 2), moreover it is a hassle to edit
Andre, Andre ... *shakes head*
/me runs
john
--
"CUT IT OUT FACEHEAD"
- jeffk
José Matos <[EMAIL PROTECTED]> writes:
| On Wednesday 08 January 2003 11:58, Lars Gullik Bjønnes wrote:
| >
| > (setq py-indent-offset 8)
| >
| > should do the trick.
| >
| > (M-x set-variable RET py-indent-offset RET 8 RET)
|
| Ok, I already knew that (trial and error), but there is a small (
On Wednesday 08 January 2003 12:37, Dekel Tsur wrote:
> >
> > And ^Q + TAB is not a reasonable solution.
>
> You need to add
> (setq-default indent-tabs-mode t)
That did the trick, thanks.
--
José Abílio
On Wed, Jan 08, 2003 at 12:27:53PM +, Jos? Matos wrote:
> On Wednesday 08 January 2003 11:58, Lars Gullik Bj?nnes wrote:
> >
> > (setq py-indent-offset 8)
> >
> > should do the trick.
> >
> > (M-x set-variable RET py-indent-offset RET 8 RET)
>
> Ok, I already knew that (trial and error), bu
On Wed, Jan 08, 2003 at 12:27:53PM +, José Matos wrote:
> Ok, I already knew that (trial and error), but there is a small (not)
> problem. It really inserts 8 spaces and not a tab. André will not like it.
I like it better than the mixed version...
Andre'
--
Those who desire to give up F
On Wednesday 08 January 2003 11:58, Lars Gullik Bjønnes wrote:
>
> (setq py-indent-offset 8)
>
> should do the trick.
>
> (M-x set-variable RET py-indent-offset RET 8 RET)
Ok, I already knew that (trial and error), but there is a small (not)
problem. It really inserts 8 spaces and not a tab. An
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| José Matos <[EMAIL PROTECTED]> writes:
|
| | On Wednesday 08 January 2003 10:32, Andre Poenitz wrote:
| | >
| | > So I'd rather have that in 'LyX style' with which emacs users _and_ I seem
| | > to be happy. Moreover, it would make the whole of L
José Matos <[EMAIL PROTECTED]> writes:
| On Wednesday 08 January 2003 10:32, Andre Poenitz wrote:
| >
| > So I'd rather have that in 'LyX style' with which emacs users _and_ I seem
| > to be happy. Moreover, it would make the whole of LyX more consistent.
|
| Lars, any clue how to force emacs
On Wednesday 08 January 2003 10:58 am, José Matos wrote:
> On Wednesday 08 January 2003 10:32, Andre Poenitz wrote:
> > So I'd rather have that in 'LyX style' with which emacs users _and_ I
> > seem to be happy. Moreover, it would make the whole of LyX more
> > consistent.
>
> Lars, any clue how
On Wednesday 08 January 2003 10:32, Andre Poenitz wrote:
>
> So I'd rather have that in 'LyX style' with which emacs users _and_ I seem
> to be happy. Moreover, it would make the whole of LyX more consistent.
Lars, any clue how to force emacs to do this?
> Andre'
--
José Abílio
On Wed, Jan 08, 2003 at 10:16:47AM +, José Matos wrote:
> The cruel truth is that we use that style since it is emacs python mode
> default.
I don't use emacs. This 'default' is unreadable for me unless I set
tabstop==8 (I usually have *shriek* 2), moreover it is a hassle to edit
for me (yes
On Wednesday 08 January 2003 10:00, Andre Poenitz wrote:
> Currently nesting there is
>
> 1. level: 4 spaces
> 2. level: 1 tab
> 3. level: 1 tab + 4 spaces
>
> etc. which is a mess when tab != 8 spaces.
>
> Is this mandatory for python or can't we simply use the same rules as in
> the rest of Ly
Currently nesting there is
1. level: 4 spaces
2. level: 1 tab
3. level: 1 tab + 4 spaces
etc. which is a mess when tab != 8 spaces.
Is this mandatory for python or can't we simply use the same rules as in
the rest of LyX?
Andre'
--
Those who desire to give up Freedom in order to gain Se
On Monday 25 February 2002 3:48 pm, Dekel Tsur wrote:
> Don't try to code it your self. Just grab the code from some GPL project.
Two reasons not to:
1. "simple" cropping, rotation, scaling is easy and "simple" is enough for
GImageXPM which is just a proof of concept image loader. The real image
On Mon, Feb 25, 2002 at 01:49:35PM +, Angus Leeming wrote:
> > The principle behind scaling is simple: It's raytracing.
> >
> > So, for each destination pixel, calculate which pixel it corresponds
> > to in the source picture.
>
> Ok, the idea is easy enough. The devil, as they say, is in th
On Monday 25 February 2002 1:49 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | On Monday 25 February 2002 11:22 am, Lars Gullik Bjønnes wrote:
> >> Angus Leeming <[EMAIL PROTECTED]> writes:
> >> | My question. Should I use c or c++ style casts with malloc. This:
On Monday 25 February 2002 1:36 pm, Asger K. Alstrup Nielsen wrote:
> On Mon, 25 Feb 2002, Angus Leeming wrote:
>
> > void GImageXPM::scale(GParams const & params)
> > {
> > if (!xpm_image_)
> > return;
> >
> > }
>
> The principle behind scaling is simple: It's raytracing.
>
> S
On Mon, 25 Feb 2002, Angus Leeming wrote:
> void GImageXPM::scale(GParams const & params)
> {
> if (!xpm_image_)
> return;
>
> }
The principle behind scaling is simple: It's raytracing.
So, for each destination pixel, calculate which pixel it corresponds
to in the source pic
On Monday 25 February 2002 11:22 am, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | My question. Should I use c or c++ style casts with malloc. This:
> the C++ variant.
Done
> Would be nice if you coult wrap the use of malloc and XpmFreeXpmImage
> in a RAII object.
When rotating the image I sometimes have to add a color "none" to the
XpmImage color table. Since this struct is controlled by libXPM, I use malloc
rather than new, so that XpmFreeXpmImage(XpmImage *) works correctly.
My question. Should I use c or c++ style casts with malloc. This:
new_xpm->c
MathInsets contain an internal cache for their "last" dimensions.
This is set during calls to metrics() and used in subsequent calls to
draw()
metrics() leaves the inset _logically_ unchanged, so I'd like to make it
const and the cache members 'mutable'.
But I know that some people don't like '
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
Why are people using :
(*iterator).whatever
rather than :
iterator->whatever
IMHO it's harder to type and read ...
john
--
"I try to keep an open mind, but not so open that my brains fall out."
- Judge Harold T. Stone
> You are allowed to look at code outside the mathed dir you know...
Somebody should have told me ;-}
Andre'
--
André Pönitz [EMAIL PROTECTED]
Andre Poenitz <[EMAIL PROTECTED]> writes:
| class foo {
| public:
| ///
| void do_it();
| private:
| ///
| int x_;
| };
Thsi one.
You are allowed to look at code outside the mathed dir you know...
Lgb
class foo {
public:
///
void do_it();
private:
///
int x_;
};
or
class foo {
public:
///
void do_it();
private:
///
int x_;
};
or
class foo
{
public:
///
void do_it
43 matches
Mail list logo
