From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.devel Subject: Re: Regexp bytecode disassembler Date: Sun, 22 Mar 2020 15:22:37 -0500 Message-ID: References: <4201DF24-BCC4-4C08-9857-38207B7C10B4@acm.org> <83mu8bdriv.fsf@gnu.org> <68FB4EC3-3C67-4D07-8473-5FC671024515@acm.org> <834kuhecsr.fsf@gnu.org> <0C9FA58E-BFD8-4F6D-BAAE-0C9AE03F0286@acm.org> <83wo7dcbl8.fsf@gnu.org> <8193C9CF-41ED-47E6-9F1C-A9A63F113540@acm.org> <54862B96-5653-4BC3-9AA9-37092DCAD7B8@acm.org> <83eetkco9m.fsf@gnu.org> <0AF4553B-0BA4-4059-B969-2FCFBDE16F0B@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="93372"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Emacs developers To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 22 21:23:28 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jG783-000OD9-Pn for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Mar 2020 21:23:27 +0100 Original-Received: from localhost ([::1]:49496 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jG782-0001jo-Ro for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Mar 2020 16:23:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38065) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jG77U-0001LC-0C for emacs-devel@gnu.org; Sun, 22 Mar 2020 16:22:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jG77S-0006e4-M8 for emacs-devel@gnu.org; Sun, 22 Mar 2020 16:22:51 -0400 Original-Received: from mail-qk1-f180.google.com ([209.85.222.180]:38641) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jG77Q-0006cr-Qo; Sun, 22 Mar 2020 16:22:48 -0400 Original-Received: by mail-qk1-f180.google.com with SMTP id h14so13194219qke.5; Sun, 22 Mar 2020 13:22:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IKMIzmLTWoa9bAXqKFacsmKCbf0q6/MbZgL+BIGWnCw=; b=ciRuIFnK7RTQNDdI8W+chUL/a7LgrtIqnOvhUW+4TE1xotlS71ks4qbaQn3gTJl8rA 4wMok6vYzwtt5+//beh09atzAnejCjbYEyaacGQ520lKiVqe5W7OTL9VUmsScJEv7C4J yBhg9h9H/OpbRCggkm/+WYioDdE27ZxgFPyMLbG7kXpbhCDcq+D5JSprs3pxaeCg+Bhz 5ZF+tOoeA61mNLoork1rLvdXhxEC2L9IxPzVa9/l8qcVr5OmNEEO3W0ucgUDSzgfc5zZ 8fGaVh8CO5v4M2KbSB4HeJdbkRgPC6PsF40YN7lJDbfwvG4tr2HBb+c8lyrIxeBM+TwH cVCA== X-Gm-Message-State: ANhLgQ12CTf+4ELx15GONzFRYssGrTWvYIImM9altP6zRN7OmKCRopaP YobJpp4WEqsL6u6k8BdWMXYIdzqevpFsRKR8diY= X-Google-Smtp-Source: ADFU+vurHv73lgtCxSpzEhuPLr4v5zBQPHxP8QDNsBUcsxMJEHRTIeuVV4DCyED2mjV9ZrJe0T5gYYbcoaS0hOcODMc= X-Received: by 2002:a37:8982:: with SMTP id l124mr17187469qkd.195.1584908567882; Sun, 22 Mar 2020 13:22:47 -0700 (PDT) In-Reply-To: <0AF4553B-0BA4-4059-B969-2FCFBDE16F0B@acm.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.222.180 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245698 Archived-At: Forgive my sticking my nose in. On Sun, Mar 22, 2020 at 2:39 PM Mattias Engdeg=C3=A5rd w= rote: > > 22 mars 2020 kl. 18.06 skrev Eli Zaretskii : > > > 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) corwin@bru.st