Mats, my feeling is that a lot of what needs doing here involves subjective
choices (e.g. what to call the merged file), where the most important thing
is not exactly what they are, but that someone decides one way or the other.
Basically, trust your judgement and make the changes. (And also, this is not
ferro-concrete, we can change things if something goes drastically wrong!)
Ar an ceathrú lá de mí Meitheamh, scríobh Mats Lidell:
>>>>> Aidan Kehoe <kehoea(a)parhasard.net>
writes:
> My feeling is that this is the right way to go. In your position I’d
> create a new file in XEmacs, call it syntax-ppss.el (notice that
> #'syntax-ppss is the main function exported by their syntax.el), and
> move GNU’s syntax.el into that file.
One problem though, Users of syntax-ppss get it by requiring syntax.
One user (if we exclude core GNU Emacs files) does:
http://google.com/codesearch?as_q=\(require\+'syntax\)+file%3A\.el%24
Your go-mode.el doesn’t, as far as I can see. (Probably because GNU’s
syntax.el is dumped.)
Which in our case would be require syntax-ppss instead I
guess. This might be considered a small change to those, few!?,
packages like the go-mode that actually uses syntax-ppss. (Go mode
only uses that single function by the way.)
I have earlier proposed to move the stuff in our syntax.el to subr.el
and add the new syntax.el in xemacs-base. Views on that plan?
Will the new syntax.el even work in 21.4 (which would be the point of
putting it in packages)? I get the following when I byte-compile it under
21.4:
Compiling file /Sources/emacs/lisp/emacs-lisp/syntax.el at Sat Jun 4 16:01:34 2011
While compiling the end of the data:
** The following functions are not known to be defined:
replace-regexp-in-string, string-to-syntax, with-no-warnings,
font-lock-fontify-syntactic-keywords-region,
with-silent-modifications
> Note when testing that #'syntax-ppss relies on
#'parse-partial-sexp, and I
> don’t know how compatible ours is with theirs.
If they are not then making our compatible with theirs would be a good
thing, right? That must be the overall plan for basic APIs? I assume
here that parse-partial-sexp is a basic function possibly used by many
packages.
Certainly, compatibility is a good thing, and #'p-p-s is a basic function
possibly used by many packages.
> According to the docstring, a wrapper around
#'parse-partial-sexp
> would do it. But is #'syntax-ppss faster? Does it not modify some
> global state? Does it cache things that #'parse-partial-sexp
> doesn’t? It’s just about possible that there’s no point to it, in
> which case a wrapper would be the way to go.
Huh... seems complicated. parse-partial-sexp is implemented in C as
buffer-syntactic-context is. Naively I would assume that to be
faster!? But I guess looking into the function an see what it does is
feasible.
Your idea with syntax-ppss.el is I guess a smaller step. If it later
can be removed due to overlapping functionality then why not but then
I we don't have to bother about that now.
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta