emacs-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112522: * lisp/progmodes/ruby-mo


From: Stefan Monnier
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r112522: * lisp/progmodes/ruby-mode.el: First cut at SMIE support.
Date: Wed, 22 May 2013 19:01:17 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>> No, indeed.  It does mostly work to test the syntax-ppss behavior, tho,
>> because a bug in it will typically cause bugs in indentation as well.
>> IOW it does largely test syntax-table and syntax-propertize, but it
>> doesn't test the font-lock-keywords part.
> That's largely true, with the exception that some syntax-propertization is
> mostly performed for the sake of appearance. An unpropertized regexp literal
> without unpaired parens or quotes inside is unlikely to fail the test.

True.  Tho most bug reports about regexp literals do include such
unpaired quotes or parens (since that's the case where the lack of
special treatment really hurts), so I'd expect most "test cases" in the
test/indent directory to include such entries.

>> We could potentially test it by calling htmlfontify-buffer.
> So, there would be a reference html file everyone would have to update after
> making a change in indent/ruby.rb?

Probably.  Tho you could potentially change the test so it first
un-htmlizes the file, then runs font-lock, then htmlfontify, in which
case the file stored in test/indent would be the html version.

I guess that sounds more like enriched-mode than htmlfontify-buffer.

>>> ruby-mode also has customization variables that change indentation behavior
>>> (at least one, for now, and we should add more). How do you propose to
>>> test that?
>> Indeed, that's a widespread limitation with the current system.
> I suppose we could set the variables via file-local vars mechanism, but
> that'll require us to have multiple files, one per combination of variables.

Yes.

> Or introduce some new kind of preprocessing, say, treat the same kind of
> comment in the middle of the file as an indication to stop, change the
> values, and indent the part of the file below with new values applied.

We could, but then we'd lose the easy way to test&debug interactively by
simply visiting the file.  ERT isn't much worse in that case (and the
two aren't mutually exclusive: use test/indent the general indentation
rules, and use ERT rules to check how indentation obeys the various
indentation variables).


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]