[ESS] Failed match for ess-function-pattern

[Peter Meilstrup]

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