[emacs-berlin] Suggested way to unset/undef/unalias stuff with emacsclient?

[Michael Heerdegen]

jman <emacs-berlin at city17.xyz> writes:

> Ok, so you're suggesting using "throwaway" definitions when playing
> and testing and then assign the final name when everything works -
> correct?
> Yes, that's certainly a way to workaround the issue, but I find it a
> bit inelegant.

Not really.  You can use the final name and just overwrite it.

What I want to say is: in your life with Emacs this will be an
insignificant thing.  There will be other things that will force you to
restart, like: Emacs crashes, Emacs freezes or gets into an inconsistent
state because of weird effects of, say, transient maps that didn't
deactivate, or any other bugs, etc. - things that are not under your
control.  Get familiar with the fact that you will need to have to
restart Emacs from time to time.

> Let me provide some examples of disadvantages of never restarting
> emacs:

BTW, I don't say you should restart often.  I say you can ignore most of
the problems you raised.

> - I change my mind about the name of a function. I'd rather undefine
> the old one and only keep the   new one. Trivial example, I've
> recently renamed "my/insert-date-YYYYMMDD" to
> "my/insert-date-YYYY-MM-DD".

`fmakunbound', if you want to go that way.  You said it would be
cumbersome to do that, that's why I didn't answer in detail.

> - Some assignments are "additive", example lists. If I make a mistake
> I can't reset to the original   state unless I restart or figure out
> how to go back to the original state.

Then in some way save the code that created those values in a file - if
it was you that created the value.  Or remove the unwanted list
elements.

> - If I enable a package by evaluating a lisp file, how can I remove
> all that it defined without   restarting?

This is the only point where I can provide a good answer:
`unload-feature'.  It works quite reliably; some changes to the
environment still may remain, though.  It's not 100% perfect.

> - If I want to test another revision of a package from git, how can I
> go back to the previous one   and be sure there are no leftovers or
> conflicts?

Same answer I think.  Apart from that: you'll see.  Or restart.  I don't
think there is a much better answer, sorry.

> - How can I test if my init.el is still fine after some changes?

What I do is: compile your init file after every change to check for a
lot of common errors.  And then: regularly see whether Emacs still "boots"
without barfing.

> - sometimes I use the scratch buffer as a playground, often with
> variables names set globally. If I   `(setq result ...)` there's a
> high risk I am overwriting something else?

If it's an existing user option that you didn't intend to change, then:
sure.  Font-lock uses a separate face for those.  Most variables without
prefix are harmless or can't be set (like `nil').  I think you should be
quite safe here.

customizable options can be restored to the original value.

> These are real examples off the top of my head that I had to deal in
> the past. How do other emacs users deal with these instead?

All ignore them.  You will shoot yourself into the foot from time to
time, but not like this, or once in your whole life.


When you are writing code, use a file from the beginning.  Regularly
compile and load in a fresh session and use high level tools to locate
problems (like unused definitions).  For learning and experimenting I
would really use a separate session, not my working session.  Just that.
There's nothing better.


Michael.