FRIGN wrote:
> On Tue, 15 Jul 2014 19:55:16 +0200
> Markus Teich wrote:
>
> > Why do you overwrite the blanks before checking if they are blanks? If the
> > file
> > format specifies these characters as blanks, they should be checked for.
> > Otherwise the format specification should not say „bl
On Tue, 15 Jul 2014 19:55:16 +0200
Markus Teich wrote:
> Why do you overwrite the blanks before checking if they are blanks? If the
> file
> format specifies these characters as blanks, they should be checked for.
> Otherwise the format specification should not say „blank“ but „any one byte“.
T
Rafa Garcia Gallego wrote:
> One thing I like from sandy is that it sets the selection when finding
> (instead of highlighting the term in another silly way). Maybe we can keep
> this in sandy-vi, so that:
>
>/foocbar
>
> Works as you expect, despite not being 100% vi(m) compatible.
Heyho,
Heyho,
FRIGN wrote:
> char *
> readimage(int fd, int *w, int *h)
I like returning a pointer to the data instead of using a separate argument for
data.
> buf[9] = buf[19] = buf[29] = '\0';
Why do you overwrite the blanks before checking if they are blanks? If the file
format specifies thes
On Tue, Jul 15, 2014 at 6:10 PM, Markus Teich
wrote:
>> i never got the "." command to do much other than repeat the latest insert or
>> delete...(probably me).
> I find it quite handy as an easy way of interactive search and replace.
> Instead
> of „:%s/bla/blub/gc“ I can just „*“ on the word, „
On Mon, Jul 14, 2014 at 09:05:07AM -0500, Eric Pruitt wrote:
> - A line was indented using spaces despite the rest of the code using
> tabs.
Applied, thanks!
--
Roberto E. Vargas Caballero
On Tue, 15 Jul 2014 17:35:59 +0100
Alex Anderson wrote:
Hey Alex,
> * why have fixed-size width and height fields if they're between
> "blank" bytes? Is for simpler read code?
it's been done this way to make parsing easier. Knowing the header is
always 30 chars long saves you from having to fi
On Mon, 14 Jul 2014 14:54:42 -0400
Charlie Murphy wrote:
> I'm looking for something like this[1] but with conversion tools for
> other formats.
Now, let's take a look at the proposition:
Bytes Description
9 ASCII string: "imagefile"
1 Blank
9 Right-justified, blank-padded A
On Tue, Jul 15, 2014 at 06:10:57PM +0200, Markus Teich wrote:
> Carlos Torres wrote:
> > i never got the "." command to do much other than repeat the latest insert
> > or
> > delete...(probably me).
>
> Heyho,
>
> I find it quite handy as an easy way of interactive search and replace.
> Instead
Looks nice.
A couple of questions:
* why have fixed-size width and height fields if they're between
"blank" bytes? Is for simpler read code?
* is "blank" ASCII-blank, or '0x00'? (From the write-code, it looks like ASCII)
On 15 July 2014 17:28, FRIGN wrote:
> On Mon, 14 Jul 2014 14:54:42 -0400
On Mon, 14 Jul 2014 14:54:42 -0400
Charlie Murphy wrote:
> [1]: http://pastebin.com/vZEcxte3
As this expires, here's the full text:
###
This is an easy-to-parse image format that works well in pipelines.
Inspired by Netpbm and the Plan 9 image format.
Bytes Description
9 ASCII string
On Mon, 14 Jul 2014 14:54:42 -0400
Charlie Murphy wrote:
> I'm looking for something like this[1] but with conversion tools for
> other formats.
>
> [1]: http://pastebin.com/vZEcxte3
This is awesome. Like Martti, I'm also really interested in a simple
image-format and would help you.
Cheers
F
Carlos Torres wrote:
> i never got the "." command to do much other than repeat the latest insert or
> delete...(probably me).
Heyho,
I find it quite handy as an easy way of interactive search and replace. Instead
of „:%s/bla/blub/gc“ I can just „*“ on the word, „cw“ or „s5“ once and then hit
„n“
Hey,
On Tue, Jul 15, 2014 at 4:20 AM, Rafa Garcia Gallego
wrote:
> TODO: need to extend the repeat framework (i.e. the '.' command) to
> store operations, multiplication and their parameters.
This reminds me of the record option in vim with
q
@ to replay...
i never got the "." command to do
q...@c9x.me wrote:
> If you only have one C file, headers are not necessary.
Heyho,
I think if you come up with a well designed API for e.g. the modal keyhandling,
it is worth to separate the functionality, so it can be reused in other
projects. This also happened to dra?w.[ch] in dwm, dmenu, etc
On Sun, Jul 13, 2014 at 12:00:44AM +0300, Dimitris Zervas wrote:
> Why are we stuck not to use headers?
> I thought it just was not needed.
> Apart from the 10 lines difference, is there any other reason?
> Performance maybe?
If you only have one C file, headers are not necessary.
-- mpu
On Tue, Jul 15, 2014 at 1:51 PM, Martti Kühne wrote:
> Looks pretty okay to me
Meaning I would help you writing a converter to png, then some
standard library could do the rest, like *magick.
cheers!
mar77i
On Mon, Jul 14, 2014 at 8:54 PM, Charlie Murphy wrote:
> Hello,
>
> Is there an image format that's simpler than PPM and that supports
> alpha transparency? PPM's syntax is too flexible; to parse an image
> you have to skip arbitrary whitespace in the header. You can't
> simply read() it.
>
> I'
On July 15, 2014 11:20:44 AM EEST, Rafa Garcia Gallego
wrote:
>Hi,
>
>With Dimitris' recent vi(m) bindings came a bug.
>
>BUG: operations added via multiplication appear as a set of unchained
>single Undo(s). They should be chained so they are undone / redone
>together.
I've not looked at the und
Hi,
With Dimitris' recent vi(m) bindings came a bug.
BUG: operations added via multiplication appear as a set of unchained
single Undo(s). They should be chained so they are undone / redone
together.
Which made me realize:
TODO: need to extend the repeat framework (i.e. the '.' command) to
sto
On Mon, Jul 14, 2014 at 6:50 PM, Charlie Kester wrote:
>> I just wanted your opinion in implementing a feature inside the code
>> or calling it via sh.
Let's try to keep as many possible text operations "scripted out" as
possible. Right now this holds true for:
- Buffer C&P (xsel | tee)
- Autoin
21 matches
Mail list logo
