On Fri, Jul 11, 2014 at 09:47:33PM +0200, Markus Teich wrote:
> I disagree. Well designed code is also depending on well designed data
> structures. Data structures, especially core functionality ones, are not
> easily
> changed or even replaced by other ones in a later state of delelopment. They
Carlos Torres wrote:
> I agree with this approach, its how st has evolved and it makes sense.
I disagree. Well designed code is also depending on well designed data
structures. Data structures, especially core functionality ones, are not easily
changed or even replaced by other ones in a later sta
On Thu, Jul 10, 2014 at 6:32 PM, Dimitris Papastamos wrote:
> There are many ways to do this, I'd go for the simplest approach in terms of
> code
> readability and stop worrying about performance.
>
> If it is slow or memory hungry, it can be fixed later incrementally.
>
I agree with this approa
On Fri 11 Jul 2014 at 06:35:50 PDT Dimitris Zervas wrote:
Well, it's good to have an idea of what am I going to do, after this patch set.
I was thinking of a super easy implementation, nearly without a buffer.
Spit the chars to the screen and replace characters on the fly.
When a buffer is neede
On July 11, 2014 4:26:12 PM EEST, Charlie Kester wrote:
>On Fri 11 Jul 2014 at 06:06:39 PDT Charlie Kester wrote:
>>On Fri 11 Jul 2014 at 01:48:39 PDT Maxime Coste wrote:
>>>On Thu, Jul 10, 2014 at 03:59:01PM -0700, Charlie Kester wrote:
I agree. Start by identifying the editing operations th
On Fri 11 Jul 2014 at 06:06:39 PDT Charlie Kester wrote:
On Fri 11 Jul 2014 at 01:48:39 PDT Maxime Coste wrote:
On Thu, Jul 10, 2014 at 03:59:01PM -0700, Charlie Kester wrote:
I agree. Start by identifying the editing operations that the data
structure must support, no matter how it is impleme
On Fri 11 Jul 2014 at 01:48:39 PDT Maxime Coste wrote:
On Thu, Jul 10, 2014 at 03:59:01PM -0700, Charlie Kester wrote:
I agree. Start by identifying the editing operations that the data
structure must support, no matter how it is implemented. Those
operations will form the API for your data en
> -l rt is a posix requirement
>
> (certain standard symbols may only be available for linking if the
> specified -l flags are given to c99, see the extended description in
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11_13
>
> so yes, to avoid toolchain issues a
On Thu, Jul 10, 2014 at 03:59:01PM -0700, Charlie Kester wrote:
> On Thu 10 Jul 2014 at 15:46:13 PDT Dimitris Papastamos wrote:
> >On Fri, Jul 11, 2014 at 01:43:16AM +0300, Dimitris Zervas wrote:
> >>First of all, we haven't even agree in which data structure will we use.
> >>Buffer gap, piece tabl
On Fri, Jul 11, 2014 at 12:32 AM, Dimitris Papastamos wrote:
> There are many ways to do this, I'd go for the simplest approach in terms of
> code
> readability and stop worrying about performance.
That. The reason sandy uses a double-linked list of lines is obviously
not performance, but code s
10 matches
Mail list logo
