Re: Regexp bytecode disassembler

[Corwin Brust]

Forgive my sticking my nose in.

On Sun, Mar 22, 2020 at 2:39 PM Mattias Engdegård <address@hidden> wrote:
>
> 22 mars 2020 kl. 18.06 skrev Eli Zaretskii <address@hidden>:
>
> > If local patching is an issue, perhaps you could rewrite the code as a
> > module?
>
> No, Fregexp_bytecode cannot be written as a module.
>
> You have made your point abundantly clear, and the code is not important. I'm 
> not going to fight.

I've been holding my breathing reading this thread in order and am I'm
devastated to see this at the moment at the conclusion.

I think this feature is really cool and very close to being aligned in
each detail.

Would it help to have someone else work at adding some information to
the internals section?

FWIW, I think this type of feature could really help people who
understand some c and some elisp to better understand how their regex
code is treated by Emacs internally.  More importantly, as people do
this and share their experiences we'll gain more understanding of the
Emacs C and elisp sources and become more able to participate in
conversations and development on this list and elsewhere.

While there are still a few points of contention that really do need
alignment, I think most of these decisions are simple to understand,
if not to make.   For me, the answers feel obvious too but I'm very,
very green.

* What should be autoloaded, if anything?

For me its nbd for to (require ) it so to be able to bind the interactive.

* Should there be an interactive command?  What should be it's inputs?

Yes!  It would be most cool if could handle either string or elisp or
maybe have a prefix arg if magic there is a bad idea?  In any case,
yes.  If that's a poor idea for whatever reason that I guess I'd side
with with Eli's view in that string is what most will expect (thus
easier to prompt for) even though I also would want to use `rx' to
make such strings.\

* What should be the documentation?

Following my own views, this is easy.  Document the interactive
command with a trail of giger-snaps inviting the reader into the elisp
and c sources, where the extra commentary already developed may indeed
be instructive.

I really appreciate the work on this feature and on this type of
feature, which helps introspect the system and leads one to better
understanding the whole of it.

Could we have another go if it, please?




--
Corwin
612-217-1742
612-298-0615 (fax)
612-695-4276 (mobile)
corwin.brust (skype)
address@hidden