Link translation & relative path export_file_name
When using an +#export_file_name directive, is it possible to have links translated to match the directory offset of the target? I came across this while working on a documentation generation scheme for https://github.com/positron-solutions/elisp-repo-kit The links in the org document are correct. The links in the resulting markdown are not translated, and break. The manual has a slightly different problem. I need to translate it as if it will be exported to the root directory even though it's always in the doc directory. The links don't seem useful, and turning them off may be more correct. I haven't gotten a lot of experience with drafting texinfo yet.
[PATCH] Unindentation fixup for code blocks
When cleaning up hard indentation, I found my source blocks remaining indented. The way that org-do-remove-indentation is sensitive to invisible text. This occurs for source blocks whenever using org-modern-mode, where it makes the source blocks align left. By swapping out the arithmetic and expressions that relied on current-column, the behavior is fixed. There are several behaviors I only just found, so I don't expect a lot of precision in my fix, but the patch I came up with follows: >From 858077f0d2a7f4cd8699948229c2965f0c6bb0a1 Mon Sep 17 00:00:00 2001 From: Psionik K <73710933+psioni...@users.noreply.github.com> Date: Wed, 10 Jan 2024 18:05:53 +0900 Subject: [PATCH] when removing indentation, take into account invisible text org-current-text-indentation sets invisibility spec to nil temporarily. One behavioral difference is that the point is no longer moved forward. Therefore, arithmetic is used instead of (current-column) based math. (current-column) is inaccurate when moving the point through invisible text. --- lisp/org-macs.el | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 8def5cbb..0512cc48 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -408,13 +408,13 @@ line. Return nil if it fails." ;; Remove exactly N indentation, but give up if not possible. (when skip-fl (forward-line)) (while (not (eobp)) - (let ((ind (progn (skip-chars-forward " \t") (current-column + (let ((ind (org-current-text-indentation))) (cond ((< ind n) - (if (eolp) (delete-region (line-beginning-position) (point)) + (if (eolp) (delete-region (line-beginning-position) + (line-end-position)) (throw :exit nil))) (t (delete-region (line-beginning-position) -(progn (move-to-column n t) - (point) +(+ (line-beginning-position) n (forward-line))) ;; Signal success. t -- 2.42.0
org-(un)fill-buffer
I wrote up a small addition to the unfill package, which is very convenient for switching hard newlines out in favor of tools like visual-line-mode and adaptive-wrap. The command unfilled every list and paragraph in the entire buffer. PR is here: https://github.com/purcell/unfill/pull/11#pullrequestreview-1812645481 Steve wants to consider it for the org package itself. Questions from me: 1. will this be accepted? 2. where would it go? 3. because org is more general than unfill, I would instead name the command org-fill-buffer and we can recommend that users run in a hook: (setq-local fill-column most-positive-fixnum). After that, every call to `org-fill-buffer` will just do what they mean, just like how `fill-paragraph` will respect fill-column. I'm going to use the combination of `org-unindent-buffer` and `org-fill-buffer` in my own personal org shortcuts, but such a command is probably too much based on my personal taste. I think I will be recommending this combination to users in an upcoming video: 1. visual-fill-column 2. visual-line-mode 3. adaptive-wrap 4. configuring an org mode hook for "unfill" behavior 5. combining unindent with (un)fill in order to clean up old cruddy hard-indented, hard-newline documents
Re: [PATCH] Unindentation fixup for code blocks
> Would you also be able to create a reproducer, so that we can replicate the problem and write a test? Yeah, I just have to make some indentation text invisible. Where should such a test live? Where is your documentation on running a test? > It looks like you did not send the patch with git send-emai. Nope. Magit patch create. Attaching another patch. > This math is not accurate when tabs are present. You want to short circuit this kind of conversation. I was not actually aware of any tabs versus spaces aware functions to build on top of since I always use spaces. Had I not already found another way to correct the behavior, this would have been a dead-end I would have had to round trip. I'm presuming tests don't get their own changelog entries. Is that correct? From 965b60f58512b009778b7b5279394bf01d407c3f Mon Sep 17 00:00:00 2001 From: Psionik K <73710933+psioni...@users.noreply.github.com> Date: Wed, 10 Jan 2024 22:37:28 +0900 Subject: [PATCH] org-macs.el: org-do-remove-indentation correction * lisp/org-macs.el (org-do-remove-indentation): set `buffer-invisibility-spec' to nil before detecting the column or moving to a column. This fixes src_block indentation removal for org-modern-mode but will also correct other cases of hidden indentation. --- lisp/org-macs.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 8def5cbb..7f5d2ad8 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -408,7 +408,8 @@ line. Return nil if it fails." ;; Remove exactly N indentation, but give up if not possible. (when skip-fl (forward-line)) (while (not (eobp)) - (let ((ind (progn (skip-chars-forward " \t") (current-column + (let* ((buffer-invisibility-spec nil) + (ind (progn (skip-chars-forward " \t") (current-column (cond ((< ind n) (if (eolp) (delete-region (line-beginning-position) (point)) (throw :exit nil))) -- 2.42.0
Re: org-(un)fill-buffer
> You may instead just run No. That will have to be run manually on every element and every line of every list. I suppose let's just not talk about it further and I'll submit a patch so there's no confusion. On Wed, Jan 10, 2024 at 9:31 PM Ihor Radchenko wrote: > > Psionic K writes: > > > I wrote up a small addition to the unfill package, which is very > > convenient for switching hard newlines out in favor of tools like > > visual-line-mode and adaptive-wrap. > > > > The command unfilled every list and paragraph in the entire buffer. PR is > > here: > > https://github.com/purcell/unfill/pull/11#pullrequestreview-1812645481 > > This PR introduces a function to "unfill" a region in Org mode buffer. > > > Steve wants to consider it for the org package itself. Questions from me: > > 1. will this be accepted? > > 2. where would it go? > > 3. because org is more general than unfill, I would instead name the > > command org-fill-buffer and we can recommend that users run in a hook: > > (setq-local fill-column most-positive-fixnum). After that, every call > > to `org-fill-buffer` will just do what they mean, just like how > > `fill-paragraph` will respect fill-column. > > You may instead just run > (let ((fill-column most-positive-fixnum)) (fill-region (point-min) > (point-max))) > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> -- 남백호 대표 겸 공동 창업자 포지트론
Re: org-(un)fill-buffer
This is the org-fill-buffer command, done generically for people who want to fill or unfill the entire buffer, as is required when alternating between hard newline filling and visual line mode filling. See attached patch for docstring and commit message. From 706d5d71cdf1ed2528664bdaf714aad6bd15af6c Mon Sep 17 00:00:00 2001 From: Psionik K <73710933+psioni...@users.noreply.github.com> Date: Wed, 10 Jan 2024 23:15:26 +0900 Subject: [PATCH] org.el: introducing org-fill-buffer * lisp/org.el: (org-fill-buffer) this command walks the tree and will call fill-paragraph on every paragraph or plain-list element, enabling the user to quickly cycle between hard newlines or visual-line-mode. They can also adjust the fill, such as after removing indentation. --- lisp/org.el | 32 1 file changed, 32 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 57379c26..1becc394 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -21901,6 +21901,38 @@ modified." (org-do-remove-indentation (funcall unindent-tree (org-element-contents parse-tree +(defun org-fill-buffer () + "Fill all paragraph and plain-list elements. +This command can be used to add hard newlines or to remove them. +To add hard newlines for text filling, set `fill-column' to the +desired with. To remove hard newlines, such as to prepare the +contents for `visual-line-mode', set `fill-column' to +`most-positive-fixnum'." + (interactive) + (unless (and (eq major-mode 'org-mode)) +(user-error "Cannot fill a buffer not in Org mode")) + (letrec ((parse-tree (org-element-parse-buffer 'greater-element nil 'defer)) + (fill-tree + (lambda (contents) + (dolist (element (reverse contents)) +(let ((type (org-element-type element))) + (if (member type '(headline section)) + (funcall fill-tree (org-element-contents element)) + (save-excursion + (save-restriction + (narrow-to-region + (org-element-begin element) + (org-element-end element)) +(goto-char (point-min)) +(pcase type + (`paragraph (fill-paragraph)) + (`plain-list + (mapc (lambda (i) + (goto-char (car i)) + (fill-paragraph)) +(reverse (org-list-struct) +(funcall fill-tree (org-element-contents parse-tree + (defun org-make-options-regexp (kwds &optional extra) "Make a regular expression for keyword lines. KWDS is a list of keywords, as strings. Optional argument EXTRA, -- 2.42.0
Re: org-(un)fill-buffer
If I run fill-region on a buffer, there's a lot of errors where the lack of element awareness means filling is attempted on text that does not fill properly, such as property drawers, keywords, and even src-blocks without newline separations. The result requires way too much cleanup. It is critical to be able to unfill documents for people to migrate off of hard newlines and onto visual line mode with variable pitched fonts. I could probably convert this to a region-based command and we could shadow fill-region. It might be slightly tricky to deal with the region if it overlaps elements, but if I had to do it now, I would make the inclusion of part of an element include all of that element. On Thu, Jan 11, 2024 at 12:47 AM Ihor Radchenko wrote: > > Psionic K writes: > > >> You may instead just run > >> (let ((fill-column most-positive-fixnum)) (fill-region (point-min) > >> (point-max))) > > No. That will have to be run manually on every element and every line > > of every list. I suppose let's just not talk about it further and > > I'll submit a patch so there's no confusion. > > May you please elaborate what is wrong with `fill-region'? > > > This is the org-fill-buffer command, done generically for people who want > > to fill or unfill the entire buffer, as is required when alternating > > between hard newline filling and visual line mode filling. > > ... > > * lisp/org.el: (org-fill-buffer) this command walks the tree and will > > call fill-paragraph on every paragraph or plain-list element, enabling > > the user to quickly cycle between hard newlines or visual-line-mode. > > They can also adjust the fill, such as after removing indentation. > > I'd rather make use of the existing Emacs toggles that control filling, > so that `fill-region' works as expected. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> -- 남백호 대표 겸 공동 창업자 포지트론
Re: org-(un)fill-buffer
> smart fill prefix reliably. is that possible now? It's reasonably complete for several documents I'm converting, such as the transient showcase. Visual fill requires two modes right now: 1. visual-line-mode (usually with visual-fill-column-mode as well) 2. adaptive-wrap-prefix-mode Updating documents to this intended useage manner required an "unfill." I started off with the unfill package, which works by setting fill-column to most-positive-fixnum. Implementing an unfill buffer command uncovered the issue with fill-region in org mode. On Thu, Jan 11, 2024 at 10:12 AM Samuel Wales wrote: > > i lost track of all the visual fill stuff vs. emacs native filling vs. > org filling vs. filladapt back before visual filling was able to fill > with both a fill column and a reasonably smart fill prefix reliably. > is that possible now? > > also, if a new command is to be introduced, presumably it would work > on subtrees, paragraphs, lists, and regions, so that you could have it > not apply to informal non-org lists or code that is not in a source > block etc. > > met with alex today > yesterday he wasn't available > even thuogh he said he would be > > > On 1/10/24, Psionic K wrote: > > If I run fill-region on a buffer, there's a lot of errors where the > > lack of element awareness means filling is attempted on text that does > > not fill properly, such as property drawers, keywords, and even > > src-blocks without newline separations. The result requires way too > > much cleanup. > > > > It is critical to be able to unfill documents for people to migrate > > off of hard newlines and onto visual line mode with variable pitched > > fonts. > > > > I could probably convert this to a region-based command and we could > > shadow fill-region. It might be slightly tricky to deal with the > > region if it overlaps elements, but if I had to do it now, I would > > make the inclusion of part of an element include all of that element. > > > > On Thu, Jan 11, 2024 at 12:47 AM Ihor Radchenko > > wrote: > >> > >> Psionic K writes: > >> > >> >> You may instead just run > >> >> (let ((fill-column most-positive-fixnum)) (fill-region (point-min) > >> >> (point-max))) > >> > No. That will have to be run manually on every element and every line > >> > of every list. I suppose let's just not talk about it further and > >> > I'll submit a patch so there's no confusion. > >> > >> May you please elaborate what is wrong with `fill-region'? > >> > >> > This is the org-fill-buffer command, done generically for people who > >> > want > >> > to fill or unfill the entire buffer, as is required when alternating > >> > between hard newline filling and visual line mode filling. > >> > ... > >> > * lisp/org.el: (org-fill-buffer) this command walks the tree and will > >> > call fill-paragraph on every paragraph or plain-list element, enabling > >> > the user to quickly cycle between hard newlines or visual-line-mode. > >> > They can also adjust the fill, such as after removing indentation. > >> > >> I'd rather make use of the existing Emacs toggles that control filling, > >> so that `fill-region' works as expected. > >> > >> -- > >> Ihor Radchenko // yantar92, > >> Org mode contributor, > >> Learn more about Org mode at <https://orgmode.org/>. > >> Support Org development at <https://liberapay.com/org-mode>, > >> or support my work at <https://liberapay.com/yantar92> > > > > > > > > -- > > > > 남백호 > > 대표 겸 공동 창업자 > > 포지트론 > > > > > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com -- 남백호 대표 겸 공동 창업자 포지트론
dslide 0.4.0, last unstable release
Dslide (Domain Specific sLIDEs) is a rethought, mostly complete rewrite of org-tree-slide. Its highlight features: - using babel blocks - per-slide configuration - extensible via custom actions and support for custom EIEIO classes There is a file in the /test directory called demo.org. You can see the presentation with `dslide-deck-start' or `dslide-deck-develop' to watch progress updates be highlighted. You need my other package, `master-of-ceremonies' to complete the last slides of the presentation. https://github.com/positron-solutions/master-of-ceremonies There are a few areas I plan to change where feedback could be beneficial. Stop me if any of these choices seem unintuitive. I plan to get rid of the idea of independent `DSLIDE_SLIDE_ACTION' and `DSLIDE_SLIDE_CHILD_ACTION' and instead combine the child and slide behaviors into several distinct slide classes. The user will set `DSLIDE_CLASS` to achieve the combination of these two options. They will still accept plist style arguments for small behavior tweaks. Per-slide actions will still be supported, via `DSLIDE_EXTRA_ACTIONS' or `DSLIDE_ACTIONS' to completely override the normal actions set via customize or document properties. A user asked me to enable hiding babel blocks via setting the `:exports none`. I'm not sure if this is consistent with other uses of that option. My other option was to re-use the babel block keywords that are usually already present, adding just "hide" to the normal list of method names. You can reply directly if you like: https://github.com/positron-solutions/dslide/issues/1
How should I handle babel configuration of exports & results in Dslide?
Because live presentations are a bit different from exporting documents, I'm not always sure how options should apply. I'm not an expert on many of these options and am not sure what will feel consistent for users. For context, a user wants :exports results or :exports none to hide the babel block / results. Issue is here: https://github.com/positron-solutions/dslide/issues/1 Is their idea consistent with the expectations and usages elsewhere? To implement options from the Dslide configuration, how can I explicitly change babel block behavior from an Elisp program? What function is best for cleaning up results of a single block? I'm using `org-babel-remove-result'. Whenever the babel args are :results replace, I am clearing them on that block both at the start fo the slide and when going backwards. Should this behavior interact with :exports? As you can see, feedback will be helpful in reconciling my understanding of the docs versus users actual expectations and common usage patterns. Thanks
Structure templates moving point
As of 9.7.2 Using `org-insert-structure-template' to add comment blocks to a document where I previously added comment blocks is moving the point to unrelated comments, and definitely not to the body of the block that was just inserted. The display buffer behavior is at least no longer creating frames I didn't want, but shouldn't it be a pop-up buffer? Likely to workaround by adding more snippets and disabling the command.
Re: Structure templates moving point
I made some changes to my buffer display settings. When the structure template choice interface does not fall back to creating a frame, it does not exhibit the errant point behavior. In any case, after creating the comment block, the point should probably move inside the block like it does for source blocks.
Re: Structure templates moving point
Sorry, I didn't intend to keep digging. I would need to debug the buffer display behavior to find out why frames were being created to make a reproduction. The fallbacks I removed from `display-buffer-fallback-actions' were the ones that create frames. On Thu, Jun 6, 2024 at 7:18 PM Ihor Radchenko wrote: > Psionic K writes: > > > I made some changes to my buffer display settings. When the structure > > template choice interface does not fall back to creating a frame, it > > does not exhibit the errant point behavior. > > > > In any case, after creating the comment block, the point should > > probably move inside the block like it does for source blocks. > > Ok, but I cannot help without being able to reproduce the problem on my > side. Please provide detailed instructions how to reproduce the problem > starting from minimal Emacs config, as described on > https://orgmode.org/manual/Feedback.html#Feedback and > https://www.chiark.greenend.org.uk/~sgtatham/bugs.html > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> > -- 남백호 대표 겸 공동 창업자 포지트론
hiding image with overlays; bounds issue
Dslide needs to dynamically show and hide content. I have been relying on overlays just for ease of accounting. Text properties are a valid fallback if I decide overlays are too fiddly. I've run into a few cases where if I don't extend the overlay to underlap the beginning of an image, the overlay does not result in the image being hidden. Another case is a bit more egregious, but I couldn't put the example into dslide's demo.org file. I can probably diagnose this later with fresh eyes, but at this time, I am in need of freeing some biological memory and wanted to ask in case it's obvious what likely went wrong. The offending code hunks are the calls to `1-` here in https://github.com/positron-solutions/dslide/commit/ef9b7fe09551e0498a174a3ffa5b48b465cb1a07 Btw, this will be in the next dslide release that I am about to cut. Some cool features got added. Available in master and I appreciate running the demo.org to smoke out issues before I tag the release.
Dslide 1.0 Feature Roadmap & RFC
Earlier, a single PR for supporting babel parameters was invaluable insight into current features. I don't use org mode in every way that everyone uses org mode. Different perspectives help. I have compiled a list of everything I believe belongs in version 1.0: https://github.com/positron-solutions/dslide/issues/20 Adding macro playback support: https://github.com/positron-solutions/dslide/issues/18 This is of particular interest. Along with babel, it's another does-everything-Emacs-can-do feature. It is a feature so dslide that dslide cannot be dslide without it. How do we want it to work? What should it build on top of? The markup we will arrive at deserves intense focus. It is a place where good decisions now pay off later. Every problem with actions now is a result of markup and babel parameter choices I hadn't considered because I don't use org that way. I have gotten some nice views of Busan coming into port from the ocean while recovering from food poisoning dealt by that same ferry, and I will take this opportunity to stress the benefit of adding *fresh* hamburgers to the hamburger jar. I intend first to bring Master of Ceremonies (mc) onto MELPA. I can see at this point which features belong in mc and which ones belong in dslide. The `mc-focus' command has been extremely beneficial for creating graphics out of code and will become the focal point of mc's design.
Keyword TOC generation for GFM
Reportedly, ox-md is somehow responsible for ox-gfm generating a TOC with anchors. Don't quote me on that. I don't believe it either. Facts I actually believe: ox-gfm will generate a github flavor table if I just set `toc' to `t' at the top of my readme. However, if I try to create a partial TOC, as I have done with dslide, the normal ox-md behavior returns and I get vanilla markdown links. First report on ox-gfm: https://github.com/larstvei/ox-gfm/issues/51 You can see my toc settings here: https://raw.githubusercontent.com/positron-solutions/dslide/refs/heads/master/doc/README.org This is the line I'm using to generate a TOC at a specific point in the document: #+toc: headlines 2 What I'm looking for is vague understanding of where the problem might actually be and what pieces of code the solution might touch. I haven't touched org's exporters much and don't know where to start.
Binary Table & Babel Data Passing
Buffer text is not a good data transfer protocol for moving return values from babel block to block. It is also not a good storage medium for table data. I propose we implement more binary data passing strategies. Elisp memory is it's own source of problems, so what would likely work better is a dynamic module to store values, like a binary cache for data. Don't quote me. I didn't do a three year design analysis on this. Within the org document, such a cache would be implemented by returning truncated results to Elisp for display in an overlay. Table display can be handled much the same way. The user sees some data. Everything runs basically the same and with a similar user experience, but wildly faster. In fact, going the dynamic module route paves the way for displaying tables outside of Emacs display, getting around the limitations that make multi-line cells etc problematic. Such a table viewer could operate its own frames, support tabs etc, and bring Org much, much closer to a traditional spreadsheet application in terms of capability. But first things first, binary data passing between babel blocks and avoiding serialization for languages where the runtime can be convinced to do it should have been done two decades ago on POSIX. Next best time is now, using 2025 tools.
Completions Registry
Not just a problem for dslide but for org in general, any time a package adds keys to configure blocks or properties, these do not complete except through dabbrev etc. The keys are likely not already in documents. The only way I can reason to make them visible is to provide functions to register various completions and then let completion backends pick up on these. Some keys may even have completions for the allowable values. The values may be dynamic. Language server features are one path to wiring these into org mode without org mode and completion backends doing work. It would be generally good for the ecosystem. However the problem will remain, how can we find the keys? Even if Emacs has a conversation with a language server, someone will have to answer regarding what completions exist. I haven't really looked into the language server implementation, but if not a tree sitter grammar for parsing, the decisions around inline markup etc are critical to making progress. I haven't been a fan of the `#+attr' requirement on affiliated keywords nor the inconsistency about not applying these for headlines. While it may be ambiguous if keywords apply to immediately following elements or the document, I don't see an issue with applying to both when there is an ambiguity. I'm not sure what the conversation around inline markup looks like, but I'm in favor of any remote definition solution like footnotes where we mark the inline region or object and then fill in the details somewhere else. Inline escaping rules and general ugliness are not my preference. Some set of decisions and tree sitter grammar would enable org to make use of the tree sitter tools for parsing, probably good for org element and font locking both. Everyone knows that. Just my +1.
Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
> Do you have an example of using buffer-local variables to store > transient state? Directing me to an appropriate section of the > showcase should be plenty. It's less magic than it sounds. I basically bypassed the infix system when making transients for Master of Ceremonies. https://github.com/positron-solutions/moc `moc-dispatch` is a kind of utility dashboard for screen casting. Besides controls, it displays various states you might not see in the minibuffer or elsewhere. I used dynamic :description functions rather than infixes to display these states. It is much simpler to bring Elisp states into the interface this way. There's no need and there can be no meaning of persisting the current state of Emacs. > like the KEEP-PRED behavior of `set-transient-map' There's more. Calling (or declining to call) `setup-prefix' manually in an interactive form or using the stack manipulation commands can switch between menus and pure interactive flows. It's possible to construct flows that are more program-driven than simple KEEP-PRED or repeat maps. Obviously we can hack them both since they are functions that can manipulate the downstream flow. Transient's pre-commands are a bit complex to understand when hacking in behavior but are related to its menu stack, something transient maps don't need to express. Instead of talking about Transient's second system behaviors, we can identify and fix the worst ones. Jonas is aware of them and generally in favor of normalizing how transient meshes with interactive, as long as it doesn't break magit and all the other dependents. > > org-speed-keys > May you please elaborate? I discovered org speed keys because I was making my own speed-key system and came across the shadowed bindings. The bindings are always shadowed, even when speed keys are off. Unlike Lispy, where I customize the shadowing using keymaps, org speed keys has `org-speed-commands'. From a discoverability standpoint, it breaks some things. The commands are opaque. All I see is `org-self-insert' whereas my own bindings have unique command names on every key, another thing I copied from Lispy. Even if they have DWIM or situational behavior, it is easier to identify all behavior when starting from an entry point that doesn't implement details of other commands.
Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
> intercepts the main loop This is optional, per transient menu (prefix) and the commands within it. A common technique, used by magit and others, is to have entry point commands in the regular keymap so that many commands can be started without traversing several menus. If you want normal un-shadowed bindings active at the same time, the prefix has a slot called `transient-non-suffix' that is similar to the `:suppress' option in keymaps or setting a `t' `undefined' binding in a keymap. However the results of mixing self-insert and modal or modal and another modal are generally bad. The biggest drawbacks of transient are well known in Github issues: - Which-key discovery of Transient keymaps - Transient binding generation based on keymaps - Normalizing how to obtain arguments when being called independently as an interactive command versus being called as a Transient suffix In the short term, to punch the first two problems in the face, override the `:setup-children' method. If you know what keymap you are borrowing bindings from, you can synchronize it at display time. Regarding the normalization with interactive, if you are not using transient infixes and instead lean on the :info class and dynamic :descriptions, you can display state and store it using normal buffer-local and defvar techniques, providing visual feedback for what might be hidden states after the user gets more familiar. The commands work with or without a prefix currently active. In this usage model, you only use Transient for its flow control, display, and layout. I find the infix system to be somewhat of a distraction if you are not actually building a CLI wrapper, but you can definitely make suffixes and descriptions "smart" by reading a scope from the prefix and making custom infixes that also obtain more state when displayed. A custom infix for storing org elements or objects could certainly be a thing. I think deeper user customization is an area that is weak with transient, but only because the user actually needs to have a vision for how they want to build up stateful commands. If you're just doing prefix maps, transient and hydra are equivalent concepts. Transient becomes differentiated when you consider commands that build up state for other commands. Executing slightly modified command sentences in rapid succession is not something the user customizes casually. Complex commands only make sense when the context they depend on is populated, which naturally decides the menu flow. > I am wondering if we can work out some universal API to plug the > described action->menu->selection model into the UI that user prefers. > > Tentatively, I am thinking about the following: > > For a given Emacs "prefix" command (e.g. org-open-at-point), we define a > set of customizations: > > 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...) >PROPS is a plist defining extra properties like key-binding, display >string, maybe something else to be used in the future. > 2. Menu interface to use (transient, context-menu, embark, which-key) > 3. Layout settings for the specific interfaces. For example, transient >layout definition. Well, I'm sure you know that transient has more decisions encoded in the layout than the other options. If the data going in is a least common denominator, you need supplementary data elsewhere to achieve a good result. What I fear is a system like org-speed-keys which relies on an override of `org-self-insert' and is yet another orthogonal system. I much prefer the Lispy style of integration, which uses a keymap. Using keymaps, even if they are not active, to generate transient key bindings via :setup-children is the best way to have certain integration with other Emacs tools. How people can collaborate with me on general questions of design is to open issues on the Transient Showcase. Either I can point to an existing example or make a new one. I've been giving some thought to how to demonstrate an idea more generally of composing multiple commands and manipulating the composition to dispatch complex commands in rapid succession with minor differences. I personally have my own org speed keys solution that I've been developing for yet another more complex package I call Afterburner. These projects can become stuck in design hell when I don't have the prodding from other problem analysis, so please, bother me. https://github.com/positron-solutions/transient-showcase
Re: Completions Registry
Sorry, my initial thoughts are too far ranging. More directly, how can I inject extra values into `org-special-properties' or elsewhere so that they appear when completing `org-set-property'? Applications that use non-standard properties don't have a way AFIAK to inform these completions.
Re: Dslide 1.0 Feature Roadmap & RFC
> May animations be disabled in the slides? They are not necessary most > of the time in the real-world presentations Reasonable. I'll get this supported, as well as making "peel" an option. Peeling is currently only activated on item-reveal when :inline is t. > is way too easy to use accidentally. Why not just >C-x k? It is not like people need to quit frequently enough to have >a very simple and easy-to-reach binding just for quitting Might need a `kill-buffer-hook' but overall, seems like another better default. Recently I changed so that it goes to the slide at point. It makes sense to unbind . > (I'd also add SPC DEL) What would they do? I know SPC is often some kind of progress, but I don't use DEL bindings enough to know them. > does not go back to the slide being displayed Design-wise, there's another question: You can only see top-level headings. It might be necessary to show more of the tree before trying to support this. To support it, I need to implement `dslide-goto` at least on slide actions. I don't expect that soon because of changes I need to make. > 3. For some reason, "Every Child" slide did nothing on my side I can't think of any reason it wouldn't work. Are you using non-graphical? I can imagine that if the logic selects no animation, then no behavior is visible, but that's just a theory. > 4 "Todos and Tags" slide claims that 🤡. Fixed and pushed to master. Thanks for checking.
