From: haj@posteo.de (Harald Jörg)
To: Emacs Developer List <emacs-devel@gnu.org>
Subject: Handling extensions of programming languages
Date: Fri, 19 Mar 2021 19:53:54 +0100 [thread overview]
Message-ID: <87o8ff560t.fsf@hajtower> (raw)
Hello List,
today I'm looking for advice or hints how to deal with a task for CPerl
mode which might have been solved for other programming languages: How
to handle extensions of the language. That's not about user-defined
functions, but about extensions that change what needs to be included in
imenu, or which affect highlighting (cumbersome but straightforward) and
indentation (tricky).
* Is it a good idea to implement each of them as a minor mode which
only makes sense in CPerl mode buffers?
* Or should the extensions be loaded by a command from CPerl mode?
* Should that be one multi-file package or should each extension go
into a package of its own? Or even a mixture of both, to allow
contributions from ELPA and Non-GNU ELPA?
* Are there templates or conventions to follow (beyond the rules how
to build packages, I'm aware of these)?
Background: In Perl, adding new syntax to the language is easy enough so
that many developers have done this and published their work as
extension modules on CPAN. Some of these extensions have become very
popular, some are quite exotic. Occasionally they are competing with
each other for the same keywords, but with different syntax.
Eventually, popular keywords might make it into the Perl core, with yet
another syntax.
My first approach was to keep all the code in one place and evaluate all
the font-lock and indenting variables at runtime, as buffer-local
variables, for the different versions. This works to some extent for
highlightingq, but fails if an extension needs different logic for
indentation.
--
Cheers,
haj
next reply other threads:[~2021-03-19 18:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 18:53 Harald Jörg [this message]
2021-03-20 17:02 ` Handling extensions of programming languages Matt Armstrong
2021-03-20 23:40 ` Harald Jörg
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=87o8ff560t.fsf@hajtower \
--to=haj@posteo.de \
--cc=emacs-devel@gnu.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).