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
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
> -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 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
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 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: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 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
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 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
10 matches
Mail list logo