unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: haj@posteo.de (Harald Jörg)
To: Matt Armstrong <matt@rfc20.org>
Cc: Emacs Developer List <emacs-devel@gnu.org>
Subject: Re: Handling extensions of programming languages
Date: Sun, 21 Mar 2021 00:40:18 +0100	[thread overview]
Message-ID: <87r1k94cnx.fsf@hajtower> (raw)
In-Reply-To: <87im5lhi6i.fsf@rfc20.org> (Matt Armstrong's message of "Sat, 20 Mar 2021 10:02:45 -0700")

Matt Armstrong <matt@rfc20.org> writes:

> I'm not an expert in this topic it pertains to Emacs itself, but I've
> always editor and development tools interesting and so have paid
> attention to these issues over the years.

Thanks for sharing your insights!

> [...]
> Very good Emacs support for languages with flexible syntax, which have a
> high level of faithfulness to the language, or even "perfect"
> faithfulness, all seem to rely on tools native to the language and
> external to Emacs, usually by way of some sort of external server.
> [...] The common theme seems to be using the interpreter/compiler
> itself to parse, without relying on the editor to understand the code
> deeply.

This is fine.  For Perl, this has some limitations since you actually
need to run parts of the code to find out whether it compiles (or, more
precise, whether it can be interpreted correctly).  This might be
undesired, e.g. for security reasons with "unknown" code.

> For a different approach, you have examples of complete or nearly
> complete parsers written in Emacs Lisp.
> [...]
> The drawback here is that, by design, any syntax extensions and
> local mini-DSLs, etc., must also have parsers written in Emacs Lisp.

Exactly!  "How hard can that be?" -- Damian Conway, in a presentation
which shows, among other tricks, a ~2000-line Perl regular expression
which matches (not actually parses) Perl code.

I *guess* that Emacs Lisp is well suited for a pragmatic/heuristic
approach, and I want to give it a try.

> (info "(ccmode)Custom Macros") is an example of how cc-mode supports a
> limited form of syntax extension.

Many thanks!  This is the sort of pointers I'm after.  I'll take a look
how this is implemented.

> I think most modes in Emacs Lisp take a pragmatic approach, using
> heuristics that get the job done most of the time without being too
> computationally expensive.  The SMIE package is a generalization of this
> idea, see (info "(elisp)SMIE").

> I am not aware of anything like SMIE that allows for languages
> extensions to be "plugged in" in a general way.

Well, I have my doubts that Perl is a good candidate for SMIE, and
trying to use SMIE in CPerl mode would be a major rewrite anyway.  I
guess the Emacs Losp basics (font-lock-add-keyword, hooks) will have to
do the job.

-- 
Cheers, and again thanks for your time,
haj



  reply	other threads:[~2021-03-20 23:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 18:53 Handling extensions of programming languages Harald Jörg
2021-03-20 17:02 ` Matt Armstrong
2021-03-20 23:40   ` Harald Jörg [this message]
2021-03-21  2:18     ` Clément Pit-Claudel
2021-03-21 11:41       ` Harald Jörg
2021-03-21 12:39         ` Stefan Monnier
2021-03-21 15:48           ` Harald Jörg
2021-03-21 17:59             ` Stefan Monnier
2021-03-22 14:08               ` Handling extensions of programming languages (Perl) Harald Jörg
2021-03-22 14:48                 ` Stefan Monnier
2021-03-22 17:32                   ` Harald Jörg
2021-03-22 18:27                     ` Stefan Monnier
2021-03-22 19:31                       ` Harald Jörg
2021-03-22 19:58                         ` [OFFTOPIC] " Stefan Monnier
2021-03-22 22:05                           ` Harald Jörg
2021-03-22 22:24                             ` Stefan Monnier
2021-03-22 23:43                               ` Harald Jörg
2021-03-23  3:49                                 ` [OFFTOPIC] " Stefan Monnier
2021-03-30 18:41             ` Handling extensions of programming languages Stephen Leake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r1k94cnx.fsf@hajtower \
    --to=haj@posteo.de \
    --cc=emacs-devel@gnu.org \
    --cc=matt@rfc20.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).