Re: Bug: Org manual: Structure Editing: Clarify commands which use the Transient Mark region [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /tmp/.emacs.d.tmp.99712ad4-61f4-4464-b003-d6d4eea9b98f/org-plus-contrib
Kyle Meyer writes: > I'll apply the patch to do so in a day or two if no one raises an > objection. Applied with 4b26289f0.
org-pop-mode
This is something I've wanted for years in org-mode, but which in some ways could actually be _offensive_ to its ideals. If you're an outline purist, look away. It's something we can do with plain lists: work on a list item at level X, then make a sublist at level X+1, and then "pop" back up to the same list item you had been working on at level X, without needing a new header. You just adjust the indentation. + Some stuff at this level. + More stuff at this level. Might even have multiple paragraphs. - a sublevel, for a digression And back to the same higher level, even without a new bullet. I use org-mode to keep daily notes at work, sometimes almost stream-of-consciousness, and often wished I could digress and then pop back. So, I present a pre-alpha version, https://gist.github.com/clsn/09ac4b098b6ad7366bb5e0bc2d5f of org-pop-mode. To "pop" back up, create a headline at the level you're popping back to, and give it a tag of "contd", and the headline text should not be something important. Instructions and explanations are in the comments of the file (the part about installing from MELPA is a lie, though). Any feedback? ~mark
Re: Survey: changing a few default settings for Org 9.4
On 2/19/20 2:39 AM, Bastien wrote: - org-hide-emphasis-markers => t Just to note: I've been working on a minor-mode in which the emphasis markers are "invisible" but not hidden (i.e. they still take up space, they're just in 'org-hide face or something similar), except when the point is closeby, at which point they become visible. The extra space is pretty ugly, I'll grant, but this does avoid the sudden jerks as text shifts when characters become visible. Also, in org-variable-pitch-mode, the emphasis markers are also reduced in size, so the extra space is not quite as obvious. Does this sound interesting to anyone? Right now the code is kind of a mess, but it could be refined. ~mark
Spaces in bare URLs?
So, in the "new" org-mode, we've done away with standard percent-encoding of URLs, in favor of a more... idiosyncratic method using backslashes. So... what is one supposed to do about spaces in URLs? When they're in [[link format]], with or without a description, it's no problem, but org-mode has a long tradition of support for "bare" URLs too. We're used to being able to type a URL or other link format and have it work, right? And that doesn't seem (to me) to be a thing that we'd want to abandon. In org-mode 9.1.9, I can type "info:elisp#Syntactic%20Font%20Lock" and it'd work. (Maybe not the greatest example, since %-encoding is seen more with http-based URIs, but still). The percent-encoding is well-established and reliable, and you can *count* on it when nothing else works, because you can always fall back on plain ascii. But that won't work in org-mode 9.3.6. Nor will "info:elisp#Syntactic Font Lock" or "info:elisp#Syntactic\ Font\ Lock" or any other variant I've tried, short of putting it inside [[]]s or <>s (in other words, no longer using a bare URL). I think dropping percent-escaping of URLs was a bad idea, in terms of breaking past usage and lack of consistency with the standard used for URLs everywhere else. But I don't know what impelled the decision to drop it, so I might well be missing something important. At any rate, it does leave a hole in what org-mode can do, a thing it used to be able to do and can't anymore. Is there a right way to do this? (without using delimiters.) I haven't yet looked at how this interacts with org-protocol's store-link transaction. ~mark
tangling from multiple files
I've seen this question around e.g. stack overflow, but none of the answers I found seems really satisfactory. I'd like to share a set of begin_src / end_src blocks in a.org between b.org and c.org; in particular b.org and c.org contain noweb references to names defined in a.org. Is there a better way than using (org-babel-lob-ingest "a.org")? This seems a bit clunky, requiring manual action every time a.org changes. For example, here is a.org #+name: x.scm #+begin_src scheme (define x 1) #+end_src #+name: y.scm #+begin_src scheme (define y 2) #+end_src and here is b.org. You can imagine c is similar, but maybe swaps the order of x and y #+begin_src scheme :tangle "b.scm" :noweb strip-export <> <> #+end_src # Local Variables: # eval: (org-babel-lob-ingest "a.org") # End:
Stuck projects in custom agenda not documented?
I tried to add stuck projects to my block agenda, but I did not find the relevant keyword. Then I googled and it found this discussion which mentions the stuck keyword: https://old.reddit.com/r/orgmode/comments/96z3el/display_list_of_stuck_projects_in_the_agenda/e45yx8p/ Shouldn't this 'stuck' keyword appear on the Block Agenda manual page along with other ones? https://orgmode.org/manual/Block-agenda.html
Re: ox-confluence.el: omit radio target links (that end up being dead links)
Hi, * Karl Voit wrote: > > As stated on [1] I do have an issue with export to Confluence markup > via org-mode/contrib/lisp/ox-confluence.el and radio targets[2]. > > When I am using a snippet like: > >| - <> :: this is the explanation to this weird term >| >| [...] >| >| Please respect the foo bar everyhere. > > ... it gets exported like that: > >| - *foo bar* - this is the explanation to this weird term >| >| [...] >| >| Please respect the [foo bar|foo bar] everyhere. > > These "[foo bar|foo bar]" snippets are then interpreted by > Confluence as links to the Confluence pages named "foo bar" which > usually don't exist. > > I think it would be a good improvement to ignore radio links in the > ox-confluence output. Meanwhile, somebody posted a fix on [1]: (defun export-radio-links-as-plain-text (link desc info) (when (string= "radio" (org-element-property :type link)) desc)) (advice-add #'org-confluence-link :before-until #'export-radio-links-as-plain-text) Maybe this is a good idea to include this in the official source code? > [1] > https://www.reddit.com/r/emacs/comments/fk5z1b/how_to_remove_foo_barfoo_bar_links_via/ > I'm asking how to search/replace current expressions as a > short-term workaround. > > [2] https://orgmode.org/manual/Radio-Targets.html -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
ox-confluence.el: omit radio target links (that end up being dead links)
Hi! As stated on [1] I do have an issue with export to Confluence markup via org-mode/contrib/lisp/ox-confluence.el and radio targets[2]. When I am using a snippet like: | - <> :: this is the explanation to this weird term | | [...] | | Please respect the foo bar everyhere. ... it gets exported like that: | - *foo bar* - this is the explanation to this weird term | | [...] | | Please respect the [foo bar|foo bar] everyhere. These "[foo bar|foo bar]" snippets are then interpreted by Confluence as links to the Confluence pages named "foo bar" which usually don't exist. I think it would be a good improvement to ignore radio links in the ox-confluence output. Thanks! [1] https://www.reddit.com/r/emacs/comments/fk5z1b/how_to_remove_foo_barfoo_bar_links_via/ I'm asking how to search/replace current expressions as a short-term workaround. [2] https://orgmode.org/manual/Radio-Targets.html -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ox.html causes w3c xhtml validation
Dear Kyle, > Kyle Meyer writes: > Thanks for reporting back. Arne sent an equivalent patch (see > sibling thread), verifying that LibreJS worked with it. I applied > that in 661696036 (ox-html: escape & in license magnets, > 2020-03-15), so we should be all set. I've done a fresh git-pull of org-mode and all works well again. Thank you and Arne for your work in resolving the issue. Best wishes, Colin.
