Re: Is it alright to define-derived-mode dynamically?

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-12-25 20:35]:
> > Problem was invoking another derived mode from tabulated-list-mode
> > where the other mode did appear and it was populated but it was not
> > visible. The text I could not see but entries were there and the lines
> > in existence, just everything white.
> 
> There can only be one major mode active in a buffer at a time.
> So whenever you call a major mode function, it "removes" the previously
> set major mode.

Those were invocations of new buffers. Now it works, but I guess it
is related to `use-local-map' something as only when I moved its
position in the function it got repaired.

> >> - Don't use global variables's names for local variables.
> >
> > Did you mean:
> >
> > (defvar-local rcd-tabulated-marked-items nil
> >   "Collects IDs for tabulated list modes")
> 
> So, I meant "local" as in let-bound variables or in your particular case
> formal arguments of functions.

I remember what you mean now. It is in my case in 1-3 functions among
many. Do you think it is messing with program data? Or with
readability?

Often I will set global variable in let to temporarily change them,
like in this example `vterm-kill-buffer-on-exit'

(defun run-with-vterm (command)
  "Runs command with vterm"
  (let ((vterm-kill-buffer-on-exit t)
        (buffer (format "Running within vterm: %s" command))
        (vterm-shell command))
    (vterm buffer)))

Those formal arguments of functions they get cleaned up later when
function is perfected, they are more individually there for me to get
used to it until function is working well.