Hi! 🙋🏾 I love smartparens, so thanks for all the work that's been put into it!

However, I ran into an issue today and I don't know whether it's expected or not. It seems counterintuitive to me, at least The issue concerns mhtml-mode and html-mode.

Regardless of whether this is intended or not: is there a way to make smartparens act the same in mhtml-mode as in html-mode?

Expected behavior

When in mhtml-mode, a major mode derived from html-mode, smartparens should behave the same. In particular, slurping and barfing and movement (such as sp-up-sexp) should behave the same.

Actual behavior

In mhtml-mode, slurping, barfing, and expression-based movement doesn't work or works differently than in html-mode

Steps to reproduce the problem

(Reproducible with emacs -q)

1. Use the following contents in a buffer with html-mode:

<div id="one"></div>
<div id="two"></div>

2. With the cursor at the start of the buffer, notice how sp-forward-sexp moves the cursor to the end of the first closing div tag. The opposite goes for sp-backward-sexp
3. With the cursor inside the first div (one), notice you can slurp (and subsequently barf) the following div (two)
4. Switch to mhtml-mode and attempt steps 2 and 3. Notice how the movements now don't act on the HTML tags as expressions in the same way and how slurping and barfing just doesn't work.

Backtraces if necessary (M-x toggle-debug-on-error)

Environment & version information

In recent enough smartparens you can call M-x sp-describe-system to generate this report. Please fill manually what we could not detect automatically. Edit the output as you see fit to protect your privacy.

• smartparens version: on branch master, using commit 911cc896a0f2eb8b5fbdd6fc8331523ad9889a3a from May 29th (via straight.el)
• Active major-mode: mhtml-mode
• Smartparens strict mode: nil
• Emacs version (M-x emacs-version): GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.16.0)
• Starterkit/Distribution: Vanilla
• OS: gnu/linux

Thank you!

Hi @Fuco1, any update on that tag?

Most stable Emacs packages are a great fit for Debian :-) Users who tend to want their toolset to not change (except for security fixes) prefer the Debian-packaged version on Debian stable. We also have strict policies like how packages must be coinstallable without causing issues or must declare conflicts when packages are not coinstallable, and we also work hard to make upgrades as painless as possible, and when it's not possible to do this automatically the upgrade system notifies the sysadmin required config changes...so it's not just another software stream, it's a massive systems integration project. We also have extensive (three different networks) of CI, to help with early detection of potential issues. We regularly find examples of how various assumptions create subtle (sometimes not so subtle) bugs, and from an upstream project perspective it's useful fuzzing...the end result being higher quality code for everyone, because we have a culture of working closely with upstreams rather than making Debian-specific fixes.

And yes of course lots of users prefer the excitement of bleeding edge! There's nothing wrong with that, of course, but some people's work depends on a boring and predictable toolset ;-)

At any rate, I've started testing 911cc89 and if necessary would like to collaborate on the stabilisation effort.

Set cwd according to the service's cwd

Thanks!

The first argument becomes a function name. It can't be instrumented because that would result in an invalid form such as

((edebug-after 0 1 FUNCTION) ...)

The first argument becomes a function name. It can't be instrumented because that would result in an invalid form such as

((edebug-after 0 1 FUNCTION) ...)

Modulo a previous (require 'cl-macs), the following warning results from (require 'trinary):

Error (use-package): trinary/:catch: Symbol’s function definition is void: :print-function

No the issue I am pointing to is one for smartparens documentation: it would be nice if the docs gave a minimal working use-package configuration.

That sounds pretty good to me! With elisp being the default, then.

We already have dash-fontify-mode for font-locking some Dash-isms in Elisp buffers.

Would it make sense to add something like a dash-clojure-indent-mode for picking between more Elisp-like and Clojure-like indentation? (Or conversely a dash-elisp-indent-mode, if Clojure-like indentation becomes the default in this scenario.)

This would allow projects to specify e.g.

((emacs-lisp-mode (mode . dash-clojure-indent)))

or

((emacs-lisp-mode (mode . dash-elisp-indent)))

in their dir-locals-file for easily picking one over the other.

This adds support for all reStructuredText code block syntaxes:

• .. code-block::
• .. code-block:: language
• Example::
• ::

The previously used regular expression approach is simplified. Regular expression searches are only used to find the basic syntax elements. A new search step finds ‘double colon’ code block syntax in addition to the ‘code-block::’ syntax.

The logic to figure out the language (now with a default fallback), and to detect the boundaries of the block to highlight, is now explicitly written out in elisp, using a helper from the built-in rst.el. This improves detection for indented blocks. An internal helper is extracted from the previous code, so that it can be used for for all code-block syntaxes.

Added a dependency on s.el to use its string functions, and added more (require) statements to load all used functions.

Added a sample file to aid developing and debugging.

While at it, fix all linter warnings.

Closes #4.