better api for programmatic use

[wbolster]

right now the only api is the copy-as-format function which inspects the prefix argument and relies on the region being active.

it would be nice to have a public function that would take two positions (begin and end) and a format argument (string, t to prompt for format, nil for default format) that would copy the text in between those two positions using the specified format.

something like this:

(defun copy-as-format-positions (beg end &optional format)
  ...)

this would allow for better use in custom commands, and also for better integration with evil-mode, which has its own concepts to define various regions (e.g. with text objects).

even better, there should be an option to not copy but only return the formatted text, which would mean it can be used in other functions.

what do you think about this? i could come up with a pr if you agree this makes sense to have.

[wbolster]

fwiw, what i am using right now to integrate with evil is this:

(evil-define-operator my-copy-as-format (beg end type)
  :move-point nil
  :repeat nil
  (interactive "<R>")
  (save-excursion
    (goto-char beg)
    (when (eq type 'line)
      (beginning-of-line))
    (push-mark (point) t t)
    (goto-char end)
    (when (eq type 'line)
      (forward-line -1)
      (end-of-line))
    (let ((current-prefix-arg t))
      (copy-as-format))
    (pop-mark)))

[sshaw]

Yes I agree, some improvements are needed.

it would be nice to have a public function that would take two positions (begin and end) and a format argument (string, t to prompt for format, nil for default format) that would copy the text in between those two positions using the specified format.

Why not just change copy-as-format to (copy-as-format START &optional END FORMAT) and modify the call to interactive to populate the args as necessary (with prefix still prompting for FORMAT)?

even better, there should be an option to not copy but only return the formatted text...

Sounds good. Maybe (copy-as-format--extract-text) can be renamed to (copy-as-format-copy START &optional END FORMAT)?

Maybe a better signature for this and copy-as-format is (copy-as-format-copy FORMAT START &optional END)? Though maybe FORMAT is better optional due to the copy-as-format-default variable... 🤔

i could come up with a pr if you agree this makes sense to have.

Sounds good!

[sshaw]

I made END optional too because the single line format will be used if there's no region.

[sshaw]

I ended writing something that I just committed.

It attempts to provide an interactive and non-interactive behavior for copy-as-format. The only problem: when not called interactively we don't want to modify the kill ring, and I forgot called-interactively-p is not really reliable...

Also multiline checking now seems a bit dirty.

Suggestions welcome. I'll have another crack at it as some point .

[wbolster]

thanks, i'll have a look later!

[Fuco1]

It attempts to provide an interactive and non-interactive behavior for copy-as-format

I think it would be more robust to have two functions, one for interactive and one for non-interactive use. The interactive version can be simply a very light wrapper just passing the arguments along and killing the extracted region (which the non-interactive version can return along with the boundaries).

[sshaw]

It attempts to provide an interactive and non-interactive behavior for copy-as-format

I think it would be more robust to have two functions, one for interactive and one for non-interactive use.

Seems to be the way to go. Especially considering called-interactively-p is not really reliable.

Suggestions for name?