Question: why not a single command for the "eepitch block" idiom?

[suhail-singh]

I am new to eev. I understand the need for having to call, in succession, something like eepitch-shell, eepitch-kill, eepitch-shell and I appreciate there being helpers such as eewrap-eepitch. However, if I understand correctly, it seems that the three invocations resulting from eewrap-eepitch are intended to be treated as a transaction and should be executed in succession. I.e., generally, one would either execute all three or none of them.

Assuming my understanding above is correct, why not have a wrapper that internally invokes the three commands in succession? I.e., why not reify the idiom into a single function (eewrap-eepitch could be updated to generate an invocation to that single function)?

[edrx]

Hi Suhail-Singh!

You're right that "generally, one would either execute all three or
none of them", but I found that there were many cases in which I just
wanted to redisplay the target buffer at the window at the right
without restarting it, and in these cases I would just execute the
(eepitch-shell)...

Here are some examples that come to my mind:

1) I run a compilation that takes several minutes - usually on
(eepitch-shell2) or (eepitch-shell3), as I try to keep (eepitch-shell)
for tasks that finish "immediately" - and I want to do other things
while the compilation goes on... and some of these other things use
eepitch blocks with (eepitch-shell), that use other target buffers.
From time to time I run just the (eepitch-shell2) or (eepitch-shell3)
to see how things are going with the compilation.

2) Imagine that I'm writing an eepitch block - with (eepitch-lua51) -
line by line, and I'm testing each line with f8 as I write it. Imagine
that some parts of it require some research - i.e., they require other
window configurations. I can do this "research" and then use just the
line with (eepitch-lua51) to redisplay my current "session" at the
window at the right.

3) Try the examples in these sections of the intros - they are about
using two different eepitch targets to control two different programs
that "talk to one another":

(find-eepitch-intro "1.2. Two targets")
(find-eepitch-intro "1.3. Two targets, two windows")

4) Take a look here:

(find-multiwindow-intro "5. Restarting eepitch targets")

You will see that the line with `find-3EE' restarts the two targets,
but the line with `find-3ee' just redisplays the targets.

  Hope that helps!
  Cheers =),
    Eduardo

P.S.: discussing here is ok, of course, but I have a slight preference
for the mailing list... if it makes no difference to you then please
send your next messages to the list! It is here:

  https://lists.nongnu.org/mailman/listinfo/eev
  https://lists.gnu.org/archive/html/eev/

[suhail-singh]

Moving thread to mailing list per request. Also cross-posting to Github. Apologies for the duplicate message.

"Eduardo Ochs" @.***> writes:

You're right that "generally, one would either execute all three or none of them", but I found that there were many cases in which I just wanted to redisplay the target buffer at the window at the right without restarting it, and in these cases I would just execute the (eepitch-shell)...

Yes, I can see value in not altering the behaviour of eepitch-shell. I wasn't proposing that the definition of eepitch-$name be altered. My proposal was for a new function (or family of functions), say, eepitch-init-$name where (eepitch-init-$name) would be equivalent to something like (progn (eepitch-$name) (eepitch-kill) (eepitch-$name)) .

-- Suhail

[edrx]

Hi Suhail!

Your message is not here yet,

  https://lists.gnu.org/archive/html/eev/

and I don't have your e-mail, so I'll answer here...

We have this, modulo comments:

  (defun eepitch-shell  () (interactive) (eepitch '(shell)))
  (defun eepitch-shell2 () (interactive) (eepitch '(shell "*shell 2*")))
  (defun eepitch-shell3 () (interactive) (eepitch '(shell "*shell 3*")))

I think that what you are proposing is this:

  (defun eepitch-shell-init  () (interactive) (eepitch-shell)  (eepitch-kill) (eepitch-shell))
  (defun eepitch-shell2-init () (interactive) (eepitch-shell2) (eepitch-kill) (eepitch-shell2))
  (defun eepitch-shell3-init () (interactive) (eepitch-shell3) (eepitch-kill) (eepitch-shell3))

• (eepitch-shell-init)
• (eepitch-shell)
echo hello

Can you play with it for some time and tell me if you like it?
If you do like it then you'll probably need more tools to make it
easier to use - like a variant of M-T:

  (find-elongkey-links "M-T  ;; eewrap-eepitch")
  (find-efunction 'eewrap-eepitch)

If you find any of these missing tools difficult - or even boring - to
write, just tell me and I'll write them for you!

  Cheers, happy hacking, etc =),
    Eduardo

[suhail-singh]

"Eduardo Ochs" @.***> writes:

I think that what you are proposing is this:

(defun eepitch-shell-init () (interactive) (eepitch-shell) (eepitch-kill) (eepitch-shell))

Yes, modulo renaming. The code below allows one to generate the definitions en masse (should one so desire).

+begin_src elisp

(defun my/eepitch-init/mk (name) "Make various eepitch-init-NAME functions." (let* ((namestr (symbol-name name)) (cmdstr (concat "eepitch-" namestr)) (cmd (intern cmdstr)) (funstr (concat "eepitch-init-" namestr)) (fun (intern funstr)) (docstr (format "Initialize %s' buffer. This function was generated bymy/eepitch-init/mk'." cmdstr))) (defun ,fun () ,docstr (interactive) (,cmd) (eepitch-kill) (,cmd)))) (defmacro my/eepitch-init/gen () (progn ,@ (mapcar 'my/eepitch-init/mk '(R bash bsh clojure coqtop dash erl eshell eshell2 eshell3 expect fennel gcl gforth ghci gnuplot gs gst guile hugs hugs98 ielm irb isympy julia ksh labltk latex lua51 lua52 lua53 lua54 luajit lualatex luatex maxima mf mitscheme mozrepl mpost mysql nodejs ocaml octave pacmd perl pforth php polyml pwsh pwsh2 python python2 python3 racket raku ruby sbcl scala scheme scsh sh shell shell2 shell3 smjs sml tcl tclsh tcsh tex tinyscheme wish yforth zsh)))) (my/eepitch-init/gen)

+end_src

-- Suhail