[ESS] Failed match for ess-function-pattern
Peter Meilstrup
peter.meilstrup at gmail.com
Sun Jan 12 00:16:48 CET 2014
The notion of "top level form" would need to be elaborated a little
bit anyway to account for C-like syntax -- presumably you would want
evaluation of
function(
ar, bar, blar #point here
)
{
#or point here
}
to include everything from "function" to "}" as well as the braces.
Combining it with the paragraph rule seems reasonable, I think
something like "eval from the preceding beginning-of-paragraph that is
at top level, to the next end-of-paragraph that is at top level" would
capture it.
On Sat, Jan 11, 2014 at 1:13 PM, Vitalie Spinu <spinuvit at gmail.com> wrote:
>
> I would be happy to implement this. Then we would be able to inject the
> source code reliably.
>
> A bit of an issue is the paragraph evaluation. A common pattern in R
> interactive code is to have a bunch of one-liners to be evaluated at
> once. Top-level-form evaluation will break this pattern unless we expand
> the evaluated region to the whole paragraph containing the form.
>
> Sometimes I need to evaluate an inner form as well. A natural thing
> would be to put it on C-u, but C-u is historically taken for a not very
> useful visual evaluation toggling.
>
> Any ideas/proposals are welcome.
>
> Vitalie
>
> >>> Peter Meilstrup on Fri, 10 Jan 2014 23:25:01 -0800 wrote:
>
> > Over both eval-function (which doesn't usually do what I want when I
> > have inner functions) and eval-paragraph (which doesn't when I put a
> > line break in a function definition), I would prefer a command that
> > did "evaluate all lines that include the top-level bracket enclosing
> > point." That would be easy to implement using parse-partial-sexp and
> > cover the case discussed here.
>
> > On Fri, Jan 10, 2014 at 2:05 PM, Vitalie Spinu <spinuvit at gmail.com> wrote:
> >>
> >> This is what I do:
> >>
> >> foo <- function() ..
> >> environment(foo) <- new_env
> >>
> >> It would be possible to treat this specially case separately but it
> >> would require re-factoring of a portion of ESS that is extremely
> >> brittle. I would avoid that for now.
> >>
> >> Vitalie
> >>
> >> >>> Andreas Yankopolus on Fri, 10 Jan 2014 15:52:06 -0500 wrote:
> >>
> >> > C-c C-c fails if the function contains any blank lines.
> >> > —Andreas
> >>
> >> > On Jan 10, 2014, at 15:48, Vitalie Spinu <spinuvit at gmail.com> wrote:
> >>
> >> >> What is wrong with C-c C-c? Which automatically evaluates the paragraph
> >> >> when no function at point is found.
> >> >>
> >> >> Vitalie
> >> >>
> >> >>>>> Andreas Yankopolus on Fri, 10 Jan 2014 14:18:38 -0500 wrote:
> >> >>
> >> >>> I'm using R environments to organize groups of related values and defining functions like so:
> >> >>>
> >> >>> fooFunc1 <- local(function(args) {
> >> >>> ## Doo foo 1 things
> >> >>> }, env=fooEnv)
> >> >>>
> >> >>> fooFunc2 <- local(function(args) {
> >> >>> ## Doo foo 2 things
> >> >>> }, env=fooEnv)
> >> >>>
> >> >>> Unfortunately, the local() construct appears to break ESS's ability to recognizes these as functions. Putting the pointer in such a function and evaluating (C-c, C-f) fails with: "Point is not in a function according to 'ess-function-pattern'."
> >> >>>
> >> >>> Any suggestions or fixes? I took a look at the code in ess-mode.el and don't see an obvious solution given my limited knowledge of elisp.
> >> >>>
> >> >>> I'm running ess v13.05 in Aquamacs 3.0preview5 on OS X 10.9.1. Same story in Emacs 23.4.1 on Ubuntu 13.10.
> >> >>>
> >> >>> —Andreas
> >> >>> [[alternative HTML version deleted]]
> >> >>>
> >> >>> ______________________________________________
> >> >>> ESS-help at r-project.org mailing list
> >> >>> https://stat.ethz.ch/mailman/listinfo/ess-help>
> >> > ______________________________________________
> >> > ESS-help at r-project.org mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/ess-help>
> >> ______________________________________________
> >> ESS-help at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/ess-help
More information about the ESS-help
mailing list