Enhance and cleanup "filling" code

[vspinu]

I am pretty sure we can simplify and generalize current filling code quite a bit. Particularly through a smart use of fill-forward-paragraph-function. This way filling would work with fill-region and not just with fill-paragraph.

Filling of the code seems to work as expected but there are still issues with roxygen blocks. Particularly filling of examples.

[lionel-]

UI-wise I think we can simplify as well. When fill-paragraph is called some lines down in a function call, it shouldn't reformat the whole call but only the arguments / terms after point. So that (with ¶ representing point):

call(arg1, arg2, arg3¶, arg4)

Would cycle to:

# Cycle 1: Column-filling
call(arg1, arg2,
     arg3¶, arg4)

# Cycle2: One expr per line
call(arg1, arg2,
     arg3¶,
     arg4)

And C-u M-q, would rearrange the parentheses as well:

call(arg1, arg2,
     arg3¶, arg4
)

call(arg1, arg2,
     arg3¶,
     arg4
)

The opening parenthesis would only be rearranged on it's own line if point is on the function name, on the parenthesis or on the first argument.

With consistent cycling between "fill to column" and "fill one object per line", that should cover all cases I can think of, and it's still easy to rearrange the whole call by calling up-list. (And eventually calling up-list in a continuation will travel to the continuation start as well.)

[lionel-]

For the record, R6 or ggproto objects are instances where this kind of formatting is really useful:

call(arg1, arg2,
  arg3¶,
  arg4
)

[vspinu]

Cycle 1: Column-filling

BTW, if there is no change during the cycle I think we need to skip a cycle and invoke next refiling style. With your example you need to press twice to get to stage 2 and there is no change on first cycle.

it shouldn't reformat the whole call but only the arguments / terms after point

That would mean navigating to the beggining of the call whenever you need to reformat the whole call. I am not quite convinced if it's really useful. Even if first argument is special in some way (R6) I find it more aesthetically appealing to put all other arguments on the separate lines. We can have this a the third step in the cycle if you are really convinced it's so useful.

And C-u M-q, would rearrange the parentheses as well:

I think this is a bit minor and I am not completely sure we can achieve it without the advice. The aim is to avoid advices as much as we can. We can have this last paranthesis configurable because it's more of a personal style than a contextual thing.

[lionel-]

We can have this a the third step in the cycle if you are really convinced it's so useful.

The problem is to control how many arguments should stay on first line. R6 has one, ggproto has 2. Other derived tools may have 3. There's no other easy way to control the number of first-line arguments I think.

We can have this last paranthesis configurable because it's more of a personal style than a contextual thing.

In Hadley's style of coding, it is completely contextual. I agree we should avoid advices but it'd be great to find a way to control parentheses. I regularly use these three formatting:

# Typically for lists or dplyr-like verbs
call(
  arg1,
  arg2
)

# Typically for calls like stop()
call(arg1,
  arg2)

# Typically for OO defs
call(arg1,
  arg2,
  arg3,
  arg4
)

I think my proposal above provide full and consistent control to produce any kind of formatting.

That would mean navigating to the beggining of the call whenever you need to reformat the whole call.

I bound a key to backward-up-list a while ago and that's been one of the most productive enhancement in my workflow this year.

[lionel-]

We can call the proposed behaviour "partial refilling", and have a user variable to enable/disable it.

[vspinu]

The problem is to control how many arguments should stay on first line.

But your proposal solves it by positioning the cursor at the point where the split should happen. You can do just that in the third step of the cycle.

and have a user variable to enable/disable it.

Yes. This is always an option, but then most users will not discover the disabled functionality. People tend to stick with defaults.

I regularly use these three formatting:

We can have cycles configurable, like (style1 style2 ..). Then we can have an alternative style cycle (also configurable) which is triggered by C-u.

[lionel-]

But your proposal solves it by positioning the cursor at the point where the split should happen. You can do just that in the third step of the cycle.

How would it work exactly to choose the split point?

We can have cycles configurable, like (style1 style2 ..). Then we can have an alternative style cycle (also configurable) which is triggered by C-u.

Yup that's what I envisioned at first. I think the above proposal is simpler and requires no extra configuration, though this would be fine as well.

[lionel-]

but then most users will not discover the disabled functionality. People tend to stick with defaults.

I think we should replace the pdf doc with a few markdown vignettes accessible from github to provide tips on how to use ESS / R-mode. Even though I'm an ESS contributor I never read the ESS doc because I'm as lazy as anyone else :). But well written and organised vignettes are discoverable and convenient to read / skim.

[vspinu]

How would it work exactly to choose the split point?

The point where you started the cycling, just as with your proposal.

Yup that's what I envisioned at first.

Ok. Then let's make this. Dedicating C-u only to parenthesis is a bit shortsighted. Who knows what kind of filling styles you will come up with tomorrow ;)

never read the ESS doc because I'm as lazy as anyone else :

Yes. ESS docs are bad, let's face it.

a few markdown vignettes accessible from github to provide tips

Indeed. The idea is to have very parsimonious docs on usage and configuration, and maybe a screencast or two. Then have a separate r-config repo with a bunch of user contributed full featured configuration files for people to get inspired from. You can contribute one for evil users.

Let's keep up the standards as high as we can. This is why next step is really cleaning stuff up and leaving well organized, well documented and strictly necessary code inside the repo.

[lionel-]

The point where you started the cycling, just as with your proposal.

Ah ok, I like this!

Let's keep up the standards as high as we can. This is why next step is really cleaning stuff up and leaving well organized, well documented and strictly necessary code inside the repo.

I wish I had already finished with the thesis to help you with this :/

[vspinu]

I wish I had already finished with the thesis to help you with this :/

Me to :). I thought it will take a day or so, but it's has been two days in a row and I don't quite see the end of it. In any case you will have to really help me to clear the clouds in r-syntax and r-indent. But that's not urgent at all. So go ahead and focus on the thesis.

I think I brought it to a usable stage more or less. Now I can move forward and put some basic pint together. This weekend hopefully.

[lionel-]

In any case you will have to really help me to clear the clouds in r-syntax and r-indent.

I think the best way forward is to fix some of the rough edges (avoid dynamic scoping etc) and then wait until I have time to figure it out. These parts are stable and internal so they can always be changed later.

I think I brought it to a usable stage more or less. Now I can move forward and put some basic pint together.

Great! So it won't be called emint after all? ;)

[vspinu]

So it won't be called emint after all? ;)

It's one letter too long. I like it, but then you have to think about mode prefixes pint-r-, pint-shell- etc and here one letter counts. emint is bit more difficult to type due to locations of letters on standard keyboard.

Two other options are emi - for multiple interaction and epi for process interaction.

[lionel-]

and here one letter counts.

True.

Two other options are emi - for multiple interaction and epi for process interaction.

I like emi. I also like epic, but can't think of a meaning for the c. Emacs process interaction comrade?

[vspinu]

:D, epid - emacs process interaction for dummies.

It can in principle be as simple as ei with ei-r-, ei-inspect-, ei-debug- etc as third party packages.

[lionel-]

ei may be confusing wrt eieio.

epid - emacs process interaction for dummies.

epic, emacs process interaction for champs ;)

Edit: I do like ei a lot though.