Eric, thanks for that, yeah I thought perhaps resizing it to the size
I wanted then setting the length back to 0 might work. It's too bad
there isn't a rb_str_reserve which IMHO would be really useful :)

Thanks for all your other feedback. It's really helpful.

On 20 March 2017 at 20:09, Eric Wong <e / 80x24.org> wrote:
> Samuel Williams <space.ship.traveller / gmail.com> wrote:
>> I have another question about the MRI source code. Perhaps it's just
>> me, but the indentation seems completely haphazard.
>>
>> Some places it's spaces. Some places its tabs. Sometimes its both for
>> no obvious reason, e.g.
>
> Officially, I think it's mixed tabs spaces, hard tabs for 8
> columns, otherwise 4 spaces.  AFAIK this is the default for GNU
> Emacs  It's documented in the the bugs.ruby-lang.org wiki
> somewhere and I've seen this style used in other projects before
> I looked at Ruby.
>
> All tabs for even levels of indentations, otherwise 4 spaces for
> the last odd level of indent.
>
> Sometimes people screw up and use only spaces, so maybe that's
> what's causing the weirdness (I can't see the actual image
> you're referring to with my setup).
>
> Anyways, for vim, I use: :set ts=8 sw=4 sts=4 noexpandtab
> (and most editors should be configurable)
>
>> I can't be the only one who has difficulty with this?
>
> No.  But MRI indentation is actually great compared to the
> wacky indentation of some GNU projects (glibc, gnulib, ...).
>
> For reference, all tabs (8 columns) is my preferred style,
> and I'd rather make deep levels of indentation (combined with
> 80 column limit) to make it easier to spot refactorable code.
>
>> On 20 March 2017 at 17:31, Samuel Williams
>> <space.ship.traveller / gmail.com> wrote:
>> > Thanks. I found the extension documentation REALLY hard to
>> > find/navigate. This is not a criticism, just a comment from someone
>> > who has not done much MRI native development. I constantly have to
>> > grep for function names in the source code, headers, etc to find
>> > anything useful. I really wish there were more documentation in
>> > headers, even just one line, see also, etc.
>
> ctags has always been invaluable for working with unfamiliar
> (and familiar source trees), along with being handy with
> git (grep/log -p/log -S), etc...  That said I've been diving
> into unfamiliar code for many years before I got to Ruby.
>
> Personally, I've rarely found API docs useful; instead I prefer
> code examples for showing how to use things (and MRI has a lot
> of that, natively), and having the underlying source of
> functions easily readable and accessible.
>
> For a long time, I did not know about README.EXT (nowadays
> extension.rdoc) but I was able to work on many C exts and MRI.
>
> Unsubscribe: <mailto:ruby-talk-request / ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Unsubscribe: <mailto:ruby-talk-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>