[Top][All Lists]

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

bug#6286: General delimited literals in ruby-mode patch

From: Stefan Monnier
Subject: bug#6286: General delimited literals in ruby-mode patch
Date: Tue, 24 Apr 2012 11:43:20 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

Hi, Dmitry,

> I wrote a patch that fixes all examples except the last one (which is a
> different issue), and also supports nesting delimiters of the same type
> inside the literal: %r(//([^/])*/)

Thank you very much.

> Do I submit the final patch here, or to the Ruby Redmine tracker?

Here is fine, thanks (tho sending it to the bug-report address rather
than to emacs-devel would have been even better in this case).

> As I understand, the upstream version is maintained to be compatible
> with earlier Emacs versions, and I'm using the
> syntax-propertize-function feature here.

The maintainership is sadly unclear, indeed.  If someone could try to
bring the two versions closer (and keep them in sync) that would be very
appreciated.  Maybe it is enough to bring changes from the Ruby code to
the Emacs code and not the other way around, but only if there's a clear
understanding that the Ruby version is "deprecated" and won't see new
development.  Also, I'm not sure the Emacs version includes all the
functionality of the current Ruby code, so there's some work to do.

> Am I trying to be too clever with the syntax table in
> `ruby-syntax-propertize-general-delimiters'?  I figured it's the
> easiest way to avoid reimplementing `scan-lists'.

It doesn't strike me as too clever (actually it looks like the exact
same trick I used in perl-mode).

> In general, if I have an undercooked patch, should I post a message
> here, or just attach it to the related bug?

Attaching it to the bug report is better, in general, unless the patch
ends up attacking a larger problem.

> Why is the case of (fboundp #'syntax-propertize-rules) being nil still
> being handled, by the way?

I tried to preserve backward compatibility, to ease up merging the
two versions.

> This ruby-mode is not compatible with Emacs 23 either way.

That might be: I have not verified that it is indeed
backward compatible, I just tried to avoid consciously
introducing incompatibilities.

> -                       (or (not (eq ?/ c))
> -                           (null (nth 0 (ruby-parse-region (or begin 
> parse-start) (point)))))
> +                       ;; not a regexp or general delimited literal
> +                       (null (nth 0 (ruby-parse-region (or begin 
> parse-start) (point))))

Could you explain this part of your patch?


reply via email to

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