search

wavexx / python-x.el

python.el extras for interactive evaluation
https://melpa.org/#/python-x
GNU General Public License v3.0
9 stars 2 forks source link

Proposals for enhancement of the evaluation system. #8

Open vspinu opened 8 years ago

vspinu commented 8 years ago

Evaluation commands:

I think the whole evaluation system could be effectively narrowed to 4 versatile functions:

  1. send-region-fold-or-section-or-defun-or-paragraph (no output by default)
  2. send-region-fold-or-section-or-defun-or-paragraph-and-step (no output by default)
  3. send-region-or-line (with output)
  4. send-region-or-line-and-step (with output)
  5. send-buffer

The current python-shell-print-region-or-symbol should be deprecated by an inspector as proposed in #3.

I think dwim name is opaque. Longer and explicit names like above are more suggestive IMO. Currently send-dwim is most closely related to 2 but is not as flexible.

Alternatively there could be send-dwim and send-dwim-and-step and a configuration variable with a list of expansions '(fold region section defun paragraph) that users can customize. Something like (er/try-expansions).

The above system would fit nicely into ESS aswell without breaking anything. 1 would be hooked on C-M-x and 2 on C-c C-c.

What do you think? Would it make sense to strive for uniform and clean UI as above?

Enhanced section markup:

  1. Allow multiple # in front
  2. Allow missing space #---
  3. Mark blocks that you want send functions to skip with # --- #
vspinu commented 8 years ago

One correction. In ESS inhibiting output by default would be backward incompatible. I am not even sure if it's feasible given different modes of evaluation (ess-eval-visibly).

vspinu commented 8 years ago

As outlined above region-fold-or-section-or-defun-or-paragraph would basically work in one of two exclusive modes - either sections if any are present in the buffer, or paragraphs. In order to make them work simultaneously an optional delimiter for end of section must be introduced. For example a sole ## --- on the line might indicate end of section. After this delimiter evaluation commands would execute paragraphs.

wavexx commented 8 years ago

I don't think there's the need for the end-of-section marker, mostly because it's a bit asymmetrical. If you need a "region", define an alternate folding marker (you can have as many as needed). "fold" is probably a misnomer in this context, as I brutally wanted to re-use the flexible/nestable delimiter logic of folding-mode (I never use "folded" code views).

I think ESS does the right thing here, by providing many bindable functions in order for the programmer to choose his own working style. It's up to you, in the end. I'm not too fond of dwim for this reason, but it's mostly a relic right now.

The question is whether the current root function send-block-with-motion needs probably an extra layer to decide which priorities/boundaries should be in effect.

There's only one thing I'd like to keep in mind with the "and-step" behavior, is that it should take extra care when exceptions are thrown. Right now the point is moved irregardless if errors occur or not, and I don't like the behavior. Unfortunately, this requires some extra state to be kept in sync between the buffer and process.

vspinu commented 8 years ago

I don't think there's the need for the end-of-section marker, mostly because it's a bit asymmetrical.

It's optional. And only when you want to work in "paragraph" style. Of course it makes sense if section and paragraph evaluation are mashed up into one command. While I agree that having separate commands for each specific evaluation is a clean approach, it doesn't seem like the most user friendly one.

I think ESS does the right thing here, by providing many bindable functions

I think we can do better. This is why I am asking for your suggestions on possible inclusion of secton commands into core functions. Separate section eval commands are always an option.

There's only one thing I'd like to keep in mind with the "and-step" behavior, is that it should take extra care when exceptions are thrown.

This is not a big deal IMO. You can always pop the mark. You also wouldn't normally call *-step family on develpment code. This is what C-M-x is for in ESS.

wavexx commented 8 years ago

On 06/02/16 15:14, Vitalie Spinu wrote:

This is not a big deal IMO. You can always pop the mark. You also wouldn't normally call *-step family on develpment code. This is what C-M-x is for in ESS.

and-step are incredibly useful for debugging experimental code.

C-c C-j in particular, since it prints the result of each statement as a side-effect.

It's the closest equivalent to "step instruction" in a debugger. Granted, since you see the output/error, moving one line up again doesn't matter much, but it can be annoying. Plus, it's nice immediate visual feedback.