Request: options for disabling all the presets?

[SPiCaRiA]

Hi,

Thank you for the great package. I personally enjoy the org-defblock and org-deflink macros very much for defining my own things!

However, the package comes with a rich presets (some may conflict with my own ones) and features (like documentation) that I don't use, but it seems that we don't have a good way to disable them and only keep the core infrastructures. Currently I'm maintaining a local package carved from this package as a compromise, but I do hope that the package itself can allow more choices.

Thanks!

[alhassy]

Hello,

Thank you for the great package.

You're very welcome 😁

I personally enjoy the org-defblock and org-deflink macros very much for defining my own things!

I'm glad to hear it!

Would you please tell me what you're using it for? Besides the presets in this package, I have no idea what people are actually using this for.

However, the package comes with a rich presets (some may conflict with my own ones)

I'd love to hear more about this. Which block types are you conflicting with. What is the nature of the conflict? Could you share your definitions please.

and features (like documentation) that I don't use,

I suppose unused features are a bit of a bloat on the Emacs runtime, but is there a pressing concern to remove/hide/disable unused features?

but it seems that we don't have a good way to disable them and only keep the core infrastructures. Currently I'm maintaining a local package carved from this package as a compromise, but I do hope that the package itself can allow more choices.

I currently am going through an extensive refactor ---improving data-structures, methods, and docs--- and I have split-up the library into "Core" and "Derived". However, these are internal separations; not user-visible ones.

Can you please elaborate on the benefits of making the split?

Thanks,

Musa

[RagnarGrootKoerkamp]

Not OP, but I'm also using this library for my blog :)

By default, when I enable this library #+begin_details gets rendered using a big green box around it, which does not fit the overall style.
But I was writing my thesis in org mode, and also needed some links to theorems (eg search Theorem 17 here), and those seem to require that the plugin is enabled. Consequently, I just redefined all my #+begin_details environment to #+begin_detail (singular) by adding a new hugo shortcode, just to avoid them rendering in 'weird' ways (theme commit, blog commit).

Side note: it took me quite some time to get the internal links working properly. For anyone interested, this is what I ended up with. I mostly copied it from somewhere else and then modified until it worked (since I don't really know elisp...).

[SPiCaRiA]

@alhassy Thank you for the reply, and it's exciting to know that you have a refactor plan on the table!

I guess my request can be discussed for the following two cases:

I'd love to hear more about this. Which block types are you conflicting with. What is the nature of the conflict? Could you share your definitions please.

Regarding this one, I'm actually running into something similar to what @RagnarGrootKoerkamp described - I want to redefine the remark and theorem blocks for my own needs.

I suppose unused features are a bit of a bloat on the Emacs runtime, but is there a pressing concern to remove/hide/disable unused features?

Technically saying, I don't think it's that a big deal, I just did it when I kept my local copy of the package. On the other hand, it does feel way cleaner to be able to choose what gets defined. I guess I'm thinking about snippet plugins when I'm talking about this - they provide an optional presets, but keep the core as a good infrastructure. I believe we can come up with a list of plugins that fit into this idea, and I feel that org-special-block-extras can be one of them.

Thanks!

[alhassy]

@SPiCaRiA It seems that your problem and that of @RagnarGrootKoerkamp can be solved by you redefining the blocks already conveniently provided by this package, like so:

#+begin_details "Proof details" :title-color pink :background-color orange
We shall prove “1 + 1 = 2” using the axiomatic approach outlined in Russell and
Whitehead's work …
#+end_details

1. Export to HTML with org-special-block-extras mode enabled
2. Press    C-x C-e   after the final closing parens below, and re-export to see the change.

(org-defblock details (title "Details" background-color "#e5f5e5" title-color "green")
  "Enclose contents in a folded up box, for HTML."
   (format "LOOK, my own details block: <details> <summary> %s </summary> %s </details>" title contents))

Does that seem to address both of your concerns?

---

@SPiCaRiA Can you elaborate here. What plugin list are you referring to?

I guess I'm thinking about snippet plugins when I'm talking about this - they provide an optional presets, but keep the core as a good infrastructure. I believe we can come up with a list of plugins that fit into this idea, and I feel that org-special-block-extras can be one of them.

---

(since I don't really know elisp...).

@RagnarGrootKoerkamp Perhaps this will help: https://github.com/alhassy/ElispCheatSheet/blob/master/CheatSheet.pdf

[SPiCaRiA]

@SPiCaRiA It seems that your problem and that of @RagnarGrootKoerkamp can be solved by you redefining the blocks already conveniently provided by this package, like so:

#+begin_details "Proof details" :title-color pink :background-color orange
We shall prove “1 + 1 = 2” using the axiomatic approach outlined in Russell and
Whitehead's work …
#+end_details

@alhassy Thank you for the information. Actually when I looked back to my comments in my config, I realized that this is not my real pain point (really sorry about the confusion).

I actually wanted to undefine blocks - for the remark environment, I want to fallback to Org mode's default behavior of a naive \begin{remark}...\end{remark}, and there doesn't seem to be a good way to do this.

@SPiCaRiA Can you elaborate here. What plugin list are you referring to?

I guess I'm thinking about snippet plugins when I'm talking about this - they provide an optional presets, but keep the core as a good infrastructure. I believe we can come up with a list of plugins that fit into this idea, and I feel that org-special-block-extras can be one of them.

Regarding this one, a good example is the YASnippet plugin - installing yasnippet alone only gives you the infrastructure for snippets, and the default presets are in a separate yasnippet-snippets plugin.

Of course, we don't have that many things to be a separate plugin. Another good example is the smartparens plugin, which puts its default configurations in a smartparens-config file. Users who want them shall add (require 'smartparens-config) to their config files (see here).

Generally, I think it is a good practice to do so - splitting the core functionalities from the cool presets. At the end, it is really a matter of personal taste. But for my own use case, I would like to be able to undefine them as I've discussed in the remark case above.

---

Lastly, a nit fix that I added to my local copy is the macro indentation:

(cl-defmacro org-defblock (name kwds &optional link-display docstring &rest body)
  "docstring..."
  (declare (indent defun))
  ...)

which ensures that the body of a org-defblock will be indented like that of a defun (relevant Elisp manual section here).

Hope that helps!

[alhassy]

@SPiCaRiA Please use the org-undefblock macro to remove org-special-block-extras support for any block of your choosing.

(cl-defmacro org-undefblock (name &rest _)
  "Remove `org-special-block-extras' support for NAME special blocks.

For example, if you have

    (org-defblock shout () (upcase contents))

Then, LaTeX export of

    #+begin_shout
    hello, world
    #+end_shout

results in

    HELLO, WORLD

To remove this support, simply add an “un” after the “-”
in the “org-defblock” declaration:

    (org-undefblock shout () (upcase contents))

Now, the original Org source exports to LaTeX as

    \\begin{shout}
    hello, world
    \\end{shout}

As such, “shout” now exports with the default Org behaviour
for special blocks.

Note: Link support is also removed, so that “ [[shout: hello, world ]] ”
no longer LaTeX-exports to “HELLO, WORLD” but instead exports to
“ \\url{shout: hello, world } ”.
"
  `(progn (fmakunbound ',(intern (format "org-block/%s" name)))
          (setq org--supported-blocks (cl-remove ',name org--supported-blocks))
          (fmakunbound  ',(intern (format "org-link/%s" name)))
          (--each '(:export :face :follow :display :keymap :help-echo)
            (setf (plist-get (org-link-set-parameters ,(format "%s" name)) it) nil))
          (message ,(format "“%s” is no longer recognised by ‘org-special-block-extras’." name))))

This code is part of the epic-refactor branch.

I am not yet convinced about the need for separating the library into two parts, but thank-you for your pointers for how other packages are doing it. I will give it more thought.