Re: Folded headlines with text showing where it shouldn't
William Denton writes: > I've had a problem lately that is related to folding headlines but I'm not > sure > how to narrow it down (short of turning on debugging, which I can do). I > wonder > if anyone else has seen this kind of thing happen or can recommend something > I > should look for or do when next it happens. > > I was working on a file and did a SHIFT-RET to collapse all the headlines. I > saw this, with a bit of text appearing in a headline where it shouldn't be: > > (This is with Emacs and Org built from source on 22 May; Org was at > 8e69adabe2026. Maybe it's been fixed since then but I haven't seen this > mentioned, so I thought I'd grab a screenshot while I could.) For me, this looks like either a mixed installation (please post the output of M-x org-version) or some third-party package misbehaving. Can you try to open that file from emacs -Q? See https://orgmode.org/manual/Feedback.html Best, Ihor
Re: BUG: org cycling regression when using the legacy folding style overlays
Kaushal Modi writes: > Oddly, I was able to reproduce that error 2 times in an emacs -Q session, > but after resetting the Org element cache, that error went away. So turns > out that the same cache can be reused between emacs -Q and regular Emacs > sessions? org-persist-directly does have a default value and it may use cache located in $XDG_CACHE_DIR/org-persist. It is probably a good idea not to load cache when emacs -Q is called, but I am not sure how to detect it. Best, Ihor
Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Sébastien Miquel writes: >> #+name: documentation >> This is a sample function documentation. >> Because there are "quotes", it must be escaped and cannot be directly >> used as noweb-reference. >> >> #+name: doc-escape >> #+begin_src emacs-lisp :var str="" :tangle no >> (prin1-to-string (string-trim-right str)) >> #+end_src >> >> #+begin_src emacs-lisp :tangle yes >> (defun test () >> <> >> t) >> #+end_src > I had converted my uses (tangling code, not text/documentation) to > this but I ended up reverting. Can you provide more concrete examples? > Some drawbacks: > + doesn't work for all languages (does work for LaTeX) Which languages do not work? > + the tangle gets very noisy: not only are the result of execution > printed in the echo buffer, but emacs visits the tangling buffer > and moves the point to each block. > Perhaps this is a bug that can be fixed. Did you try to play with :results header argument to disable messages? What exactly went unexpected? > + src block execution also resets the noweb cache, slowing down > tangle, though I have not tried to measure the effect. I am not sure what you are referring to here. Can you elaborate? Best, Ihor
Re: [BUG] org-element--cache: Unregistered buffer [9.5.3 (9.5.3-g4dda0d @ c:/Users/scott/.emacs.d/straight/build/org/)]
Scott Otterson writes: > Having just updated to emacs 28.1, I'm seeing the warning > > org-element--cache: Unregistered buffer > > every time I open a .org file. I also notice that org-superstar no longer > works. > > These problems persist if I delete my .emacs.d and let straight.el rebuild > everything. Thanks for reporting! You appear to use straight.el. Can you please share the output of M-x org-version? straight.el is known to create problems when Org is loaded late in you config. See https://github.com/radian-software/straight.el/issues/947 Also, can you try to open the problematic files using bare Emacs starting from emacs -Q? See https://orgmode.org/manual/Feedback.html Best, Ihor
Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
Juan Manuel Macías writes: > Ihor Radchenko writes: > >> Sounds reasonable. However, a more consistent way to handle line numbers >> would be using switches, like what we do in EXAMPLE blocks. See >> org-element-example-block-parser and 12.6 Literal Examples section of >> the manual. > > (I didn't remember that I had sent this patch...). > > I'll take a look at the function you mention, when I have some time. In > any case, keep in mind that there are some conventions in verse > numbering: the white lines (separation between stanzas) are never > numbered and there is a sequence: 5 (first verse alwais remains > unnumbered) ... 10 ... 15 ..., which can be chosen using the :lines > attribute. :lines t defaults to a sequence of 5 verses. I chose this > syntax to follow the syntax of verse numbering with output to LaTeX > (another patch of mine that is already included in Org. In that case, > the 'verse' LaTeX package is used). The default switches syntax was originally designed for code block and it generally supports continuous numbering across several subsequent code blocks or starting the numbering from certain line. Will such features be useful for verses? Do you know if customizing :lines 5 to something other than 5 is often needed? Maybe it can be an export option? Best, Ihor
Re: [BUG] org-element-warnings when accidentially inserting "z" into timestamp [9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/)]
Gregor Zattler writes: > Now I realized, that even after quitting and restarting > Emacs, I cannot insert a timestamp, I get the following > error message: > > org-parse-time-string: Not an Org time string: [20zznn22-05-30 Mo 11:34] > > And then there is a dangling > > CLOCK: > > line without timestamps at the expected line in my org file. > > It took a while till I realized that there was a corrupted > timestamp in my org file a few clock lines below. > > It would be helpful, if the message contained the file name > and probably even the line number. Could you please create an example file and detail the steps how you got the error? Best, Ihor
Re: Proposal: 'executable' org-capture-templaes
Arthur Miller writes: > Instead of hardcoding the actual work in the conditional statement, there > should > be a function to be called, so org-capture would setup its own work, some > random > "exec" menu like here would setup its own and so on. I haven't look at other > parts of org you have mentioned, so I am not yet sure if the approach would > work > for all the kids in the block. I don't think it would that much harder to > refactor this out, but I might be wrong, since I am not that familiar with > org code. There are several slightly more complex things in org-agenda (you can set extra switches in agenda menu to affect the subsequent command - see agenda restriction), but please by all means go ahead if you have interest in this area. > Factoring this out of Org itself, as suggested by RMS in the link you posted > might be much more work though. I haven't looked at that, and question is if > that is really worth the effort? I would agree with him that things like > org-table and date/time handling would be great to have in entire Emacs, > without > need to load org, at least bigger parts of it. If I remember well, table mode > started outside of org as its own minor mode and got merged into org. This is not an immediate goal. Rather a justification that we generally aim for a more modular code structure. >> The above statement is a hint that patches are welcome :) > > As said, I am not that well familiar with org in-depth, and with other places > that might need to be factored out, so I don't promise anything. Initially I > just got a quick idea while working on a project of mine with org-capture, and > hacked the 'org-capture' function to implement my idea :). Feel free at ask anything if you encounter difficulties. It is not always trivial to convert something that works for you personally into something suitable for all the people using Org. Best, Ihor
Re: BUG: org cycling regression when using the legacy folding style overlays
Kaushal Modi writes: > I read the ORG-NEWS: > >> The new folding backend breaks some of the =outline-*= functions that >> rely on the details of visibility state implementation in >> =outline.el=. The old Org folding backend was compatible with the >> =outline.el= folding, but it is not the case anymore with the new >> backend. From now on, using =outline-*= functions is strongly >> discouraged when working with Org files. > > It says that the new folding backend won't work with outline.el. But > in this case, I am still using the old backend. > Are the outline.el functions expected to stop working for the old backend too? org-fold-core-style 'overlays is not enabling the old backend, but rather enables legacy support in the new backend. Strictly speaking, I can simplify the 'overlays option to work exactly like the old backend, but it will also require changing some other defaults, which is awkward. Also, it will discourage non-complying packages to keep using outline.el and instead ask users to change to the old backend. I would prefer to avoid this. 'overlays option is intended to be a emergency solution for people experiencing major issues with the new folding mechanism. It will be eventually removed. Best, Ihor
Re: BUG: org cycling regression when using the legacy folding style overlays
On Mon, May 30, 2022 at 7:45 PM Ihor Radchenko wrote: > Your code__collapse_all_posts block makes use of hide-subtree from > outline.el. Please, do not use it. outline.el is no longer considered > compatible with Org. It was not in the past, and even more so now. This > has been announced in ORG-NEWS. I read the ORG-NEWS: > The new folding backend breaks some of the =outline-*= functions that > rely on the details of visibility state implementation in > =outline.el=. The old Org folding backend was compatible with the > =outline.el= folding, but it is not the case anymore with the new > backend. From now on, using =outline-*= functions is strongly > discouraged when working with Org files. It says that the new folding backend won't work with outline.el. But in this case, I am still using the old backend. Are the outline.el functions expected to stop working for the old backend too? I replaced hide-subtree with org-fold-hide-subtree and my subtree collpasing function seems to work as before even with org-fold-core-style set to 'overlays. I will update this thread if I see any issue with that. Thanks!
Folded headlines with text showing where it shouldn't
I've had a problem lately that is related to folding headlines but I'm not sure how to narrow it down (short of turning on debugging, which I can do). I wonder if anyone else has seen this kind of thing happen or can recommend something I should look for or do when next it happens. I was working on a file and did a SHIFT-RET to collapse all the headlines. I saw this, with a bit of text appearing in a headline where it shouldn't be: https://www.miskatonic.org/tmp/org-01.png I went to the headline and hit RET. It expanded, and now the bit of text was appearing a sub headline: https://www.miskatonic.org/tmp/org-02.png Expanding that headline shows what it looks like normally: https://www.miskatonic.org/tmp/org-03.png The "Tidyverse" there is a link. I think that's a part of the problem: if I remember right, every time I've seen this happen, it's a link that is displayed out of place. (This is with Emacs and Org built from source on 22 May; Org was at 8e69adabe2026. Maybe it's been fixed since then but I haven't seen this mentioned, so I thought I'd grab a screenshot while I could.) Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: export a org table to ascii format (tabs) are not conserved, culprit orgtbl-to-tsv?
i was thinking of a nother element when i said div. i meant pre On 5/30/22, Samuel Wales wrote: > some web ui support some subset of html. i think blogger does. then > you might have a div. which i think [not sure] might enforce line > breaks and also be monospace, or something like that. [pardon my html > ignorance.] > > On 5/30/22, Tim Cross wrote: >> >> Uwe Brauer writes: >> >>> Hi >>> >>> I wanted to export a 4x4 table to ascii to insert it into a web fill in >>> interface. However the column get distorted. I tried to tabify or >>> untabify the buffer but it did not help. >>> >>> >>> The problem also occurs when I export the table using the >>> orgtbl-to-tsv >>> >>> #+begin_example >>> | Course | L | M | X >>> | >>> J | V | >>> |--+-+-+-+-+-| >>> | Statistics | 10:30-11:30 | | 10:00-11:20 >>> | >>> | 10:30-11:30 | >>> | Differential Equations | 12:30-13:30 | | 13:00-14:15 >>> | >>> | 12:30-13:30 | >>> | Master | 14:30-15:30 | | 15:30-16:30 >>> | >>> 14:30-15:30 | | >>> | Numerical Analysis :00-19:00 | 18:00-19:00 | 18:00-19:00 | 18:00-19:00 >>> | >>> | 7.5 | >>> | | | | >>> | >>> 19:00-20:00 | | >>> |--+-+-+-+-+-| >>> | | | | >>> | >>> | | >>> >>> #+end_example >>> >>> >>> Converted to >>> >>> #+begin_example >>> Course L M X J V >>> Statistics 10:30-11:30 10:00-11:20 10:30-11:30 >>> Differential Equations 12:30-13:30 13:00-14:15 >>> 12:30-13:30 >>> Master 14:30-15:30 15:30-16:30 14:30-15:30 >>> Numerical Analysis 18:00-19:00 18:00-19:00 18:00-19:00 >>> 18:00-19:00 >>> 19:00-20:00 >>> #+end_example >>> >>> >>> Any idea what is wrong here? >>> >>> >> >> I think you might be working under a false expectation. A quick look at >> the exported table example and it looks to be correct to me - values are >> tab separated, with is what a tsv format is. There is no requirement >> that the columns should be aligned, only that they are separated by >> tabs. >> >> With regards to more formatted output options, a common issue is with >> respect to the fonts people use. If the font being used to view th >> eoutput is a proportional font rather than a fixed width one, then all >> formatting will be broken. Most web interfaces tend to use proportional >> fonts due to their more pleasing look for most people. This is also why >> tables sent via email often don't look right for the recipient - they >> are using a proportional or condensed font. >> >> As you have no control over the fonts used by those viewing your ASCII >> content, you cannot reliably make it look well formatted. Either you >> have to do HTML, some form of markdown or some other format with >> enforces tgable alignment. >> >> If your entering data into a web UI, I would not have any expectations >> regarding the final formatting as that will depend heavily on what the >> backend does to the supplied input and how the data is presented to >> anyone looking at that output. >> >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: export a org table to ascii format (tabs) are not conserved, culprit orgtbl-to-tsv?
some web ui support some subset of html. i think blogger does. then you might have a div. which i think [not sure] might enforce line breaks and also be monospace, or something like that. [pardon my html ignorance.] On 5/30/22, Tim Cross wrote: > > Uwe Brauer writes: > >> Hi >> >> I wanted to export a 4x4 table to ascii to insert it into a web fill in >> interface. However the column get distorted. I tried to tabify or >> untabify the buffer but it did not help. >> >> >> The problem also occurs when I export the table using the >> orgtbl-to-tsv >> >> #+begin_example >> | Course | L | M | X | >> J | V | >> |--+-+-+-+-+-| >> | Statistics | 10:30-11:30 | | 10:00-11:20 | >> | 10:30-11:30 | >> | Differential Equations | 12:30-13:30 | | 13:00-14:15 | >> | 12:30-13:30 | >> | Master | 14:30-15:30 | | 15:30-16:30 | >> 14:30-15:30 | | >> | Numerical Analysis :00-19:00 | 18:00-19:00 | 18:00-19:00 | 18:00-19:00 | >> | 7.5 | >> | | | | | >> 19:00-20:00 | | >> |--+-+-+-+-+-| >> | | | | | >> | | >> >> #+end_example >> >> >> Converted to >> >> #+begin_example >> Course L M X J V >> Statistics 10:30-11:30 10:00-11:20 10:30-11:30 >> Differential Equations 12:30-13:30 13:00-14:15 >> 12:30-13:30 >> Master 14:30-15:30 15:30-16:30 14:30-15:30 >> Numerical Analysis 18:00-19:00 18:00-19:00 18:00-19:00 >> 18:00-19:00 >> 19:00-20:00 >> #+end_example >> >> >> Any idea what is wrong here? >> >> > > I think you might be working under a false expectation. A quick look at > the exported table example and it looks to be correct to me - values are > tab separated, with is what a tsv format is. There is no requirement > that the columns should be aligned, only that they are separated by > tabs. > > With regards to more formatted output options, a common issue is with > respect to the fonts people use. If the font being used to view th > eoutput is a proportional font rather than a fixed width one, then all > formatting will be broken. Most web interfaces tend to use proportional > fonts due to their more pleasing look for most people. This is also why > tables sent via email often don't look right for the recipient - they > are using a proportional or condensed font. > > As you have no control over the fonts used by those viewing your ASCII > content, you cannot reliably make it look well formatted. Either you > have to do HTML, some form of markdown or some other format with > enforces tgable alignment. > > If your entering data into a web UI, I would not have any expectations > regarding the final formatting as that will depend heavily on what the > backend does to the supplied input and how the data is presented to > anyone looking at that output. > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: BUG: org cycling regression when using the legacy folding style overlays
On Mon, May 30, 2022, 7:45 PM Ihor Radchenko wrote: > Kaushal Modi writes: > > > I was trying to create a minimal reproducible example for a different > > issue and I ended up with this other issue that I didn't expect and so > > I am reporting that first. > > > > Issue: Opening an Org file gives (wrong-number-of-arguments # > looking-at> 2) error. > > Do I understand correctly that your reproducer has nothing to do with > this error? > Oddly, I was able to reproduce that error 2 times in an emacs -Q session, but after resetting the Org element cache, that error went away. So turns out that the same cache can be reused between emacs -Q and regular Emacs sessions? Your code__collapse_all_posts block makes use of hide-subtree from > outline.el. Please, do not use it. outline.el is no longer considered > compatible with Org. It was not in the past, and even more so now. This > has been announced in ORG-NEWS. > Thanks! I definitely missed that. I'll read up on how to do the same without hide-subtree. >
Re: BUG: org cycling regression when using the legacy folding style overlays
Kaushal Modi writes: > I was trying to create a minimal reproducible example for a different > issue and I ended up with this other issue that I didn't expect and so > I am reporting that first. > > Issue: Opening an Org file gives (wrong-number-of-arguments # looking-at> 2) error. Do I understand correctly that your reproducer has nothing to do with this error? > 1. Clone https://gitlab.com/kaushalmodi/org-mode-mwe to a temp > directory (say, in /tmp) > 2. cd to the org repo and check out the main branch. The Org version > used when creating this report was release_9.5.3-520-g4dda0d. > 3. emacs -Q -L ./lisp/ > /tmp/org-mode-mwe/bug-recipes/collapse-all-post-subtrees/t.org & > 4. Evaluate the "code__fold_style" src block in that test file; it > sets the fold style to overlays > 5. Evaluate the "code__collapse_all_posts" src block; this code hides > all the subtrees with non-empty values for EXPORT_FILE_NAME or > CUSTOM_ID properties. Your code__collapse_all_posts block makes use of hide-subtree from outline.el. Please, do not use it. outline.el is no longer considered compatible with Org. It was not in the past, and even more so now. This has been announced in ORG-NEWS. Best, Ihor
BUG: org cycling regression when using the legacy folding style overlays
Hello, I was trying to create a minimal reproducible example for a different issue and I ended up with this other issue that I didn't expect and so I am reporting that first. Issue: Opening an Org file gives (wrong-number-of-arguments # 2) error. = Warning (org-element-cache): org-element--cache: Org parser error in t.org::88. Resetting. The error was: (wrong-number-of-arguments # 2) Backtrace: nil Please report this to Org mode mailing list (M-x org-submit-bug-report). = Recipe: 1. Clone https://gitlab.com/kaushalmodi/org-mode-mwe to a temp directory (say, in /tmp) 2. cd to the org repo and check out the main branch. The Org version used when creating this report was release_9.5.3-520-g4dda0d. 3. emacs -Q -L ./lisp/ /tmp/org-mode-mwe/bug-recipes/collapse-all-post-subtrees/t.org & 4. Evaluate the "code__fold_style" src block in that test file; it sets the fold style to overlays 5. Evaluate the "code__collapse_all_posts" src block; this code hides all the subtrees with non-empty values for EXPORT_FILE_NAME or CUSTOM_ID properties. If you skip step 4, you will find the collapsing of all subtrees where EXPORT_FILE_NAME or CUSTOM_ID is set happens as expected in step 5. But if you evaluate step 4, most (or all?) subtrees remain uncollapsed. Additionally, once step 4 + 5 are evaluated, the default TAB binding that should cycle a subtree's visibility also starts behaving erratically. For example, move cursor to line 68 (* Image / Figure) in the test file t.org after completing all of the above steps. You will find these lines visible: = * Image / Figure :image: ** Image links :PROPERTIES: :EXPORT_FILE_NAME: image-links :EXPORT_DATE: 2017-07-15T07:49:44-04:00 :END: = Hit TAB once, and now you see this: it hid only the title of the subtree heading under it, but still shows the property drawer expanded! = * Image / Figure :image: :PROPERTIES: :EXPORT_FILE_NAME: image-links :EXPORT_DATE: 2017-07-15T07:49:44-04:00 :END: = Hit TAB once again, you will see: = * Image / Figure :image: ** Image links... = Now if you move the point to line 69 (* Image links), hitting the TAB will not do any kind of cycling at all. -- Kaushal Modi
Re: # Comments export
Juan Manuel Macías writes: > Eric S Fraga writes: > >> I use drawers for this and then have specific processing of different >> types of drawers, depending on target. >> >> For instance, I might have :note: drawers (similar to inline tasks) with >> the following processing (for odt export; similar for LaTeX): >> >> --8<---cut here---start->8--- >> (setq-local org-odt-format-drawer-function >> (lambda (name contents) >> (if (string= name "note") >> (progn >> (format "> text:background=\"#00\">%s" contents) >> --8<---cut here---end--->8--- >> >> (progn because I used to do more in there...) > > I use a special type of footnote, which is exported to LaTeX as pdf > annotations (with the pdfannotate package) and to odt as comments. The > use of footnotes allows me to put comments and annotations within the > paragraph: > > https://list.orgmode.org/877de55cjf@posteo.net/ > I think this is a much better solution. I don't like the idea of adding the ability to export comments - the whole point of comments are to provide content which is NOT exported. If you find you have content as comments which you then want to export, my view would be that these are not 'comments' in the sense of org-mode. These sound like notes or annotations and there is likely a better approach than treating them as org comments. Org comments are probably best thought of as comments about org content and not org content per se. If you want your comments to appear as part of yhour exported data at some level, they are no longer comments, but rather a different class of content and should be categorised using one of the org content block types or a footnote.
Re: a simple(r) html export format (like org-mime)
Uwe Brauer writes: > Hi > > Although the vanilla html export backend produces nice html, I sometimes need > a > simpler solution[1], like the one produced by org-mime (which is for email). > Does anybody know about such an exporter? > You seem to be aware of htmlise and I have no other suggestions. However, I would also recommend you test things before adopting any specific solution. It sounds like you want to input HTML formatted data into a web interface _Moodle). There will almost certainly be (or at least should be) significant restrictions on what HTML content you are allowed to input via such interfaces. In fact, most well written web interfaces would escape or strip out any embedded HTML in input due to the very real security risks such input represents. A lot will depend o the platform your trying to use and what options it provides. For example, org-mode has support for uploading data to confluence (Atlatian's team collaboration suite). This is done via a RPC facility confluence provides and therefore can provide a nice interface. More manual solutions might be to generate a markdown export of your org buffer - for example, when a site uses Github markdown, you can use the ox-gfm exporter to generate a markdown version of your contgent which you can then cut and paste into the input area of the web interface (assuming it supports Github markdown). You mentioned moodle. I would look to see what markdown flavour moodle supports and then see if you can find a markdown exporter for org which supports that flavour. You may at least then be able to generate versions of your content you can cut and paste into the moodle UI. Moodle is open source, so theoretically, you could do something more sophisticated, given sufficient time and motivation.
Re: export a org table to ascii format (tabs) are not conserved, culprit orgtbl-to-tsv?
Uwe Brauer writes: > Hi > > I wanted to export a 4x4 table to ascii to insert it into a web fill in > interface. However the column get distorted. I tried to tabify or > untabify the buffer but it did not help. > > > The problem also occurs when I export the table using the > orgtbl-to-tsv > > #+begin_example > | Course | L | M | X | >J | V | > |--+-+-+-+-+-| > | Statistics | 10:30-11:30 | | 10:00-11:20 | > | 10:30-11:30 | > | Differential Equations | 12:30-13:30 | | 13:00-14:15 | > | 12:30-13:30 | > | Master | 14:30-15:30 | | 15:30-16:30 | > 14:30-15:30 | | > | Numerical Analysis :00-19:00 | 18:00-19:00 | 18:00-19:00 | 18:00-19:00 | > | 7.5 | > | | | | | > 19:00-20:00 | | > |--+-+-+-+-+-| > | | | | | > | | > > #+end_example > > > Converted to > > #+begin_example > CourseL M X J V > Statistics10:30-11:30 10:00-11:20 10:30-11:30 > Differential Equations12:30-13:30 13:00-14:15 > 12:30-13:30 > Master14:30-15:30 15:30-16:30 14:30-15:30 > Numerical Analysis18:00-19:00 18:00-19:00 18:00-19:00 > 18:00-19:00 > 19:00-20:00 > #+end_example > > > Any idea what is wrong here? > > I think you might be working under a false expectation. A quick look at the exported table example and it looks to be correct to me - values are tab separated, with is what a tsv format is. There is no requirement that the columns should be aligned, only that they are separated by tabs. With regards to more formatted output options, a common issue is with respect to the fonts people use. If the font being used to view th eoutput is a proportional font rather than a fixed width one, then all formatting will be broken. Most web interfaces tend to use proportional fonts due to their more pleasing look for most people. This is also why tables sent via email often don't look right for the recipient - they are using a proportional or condensed font. As you have no control over the fonts used by those viewing your ASCII content, you cannot reliably make it look well formatted. Either you have to do HTML, some form of markdown or some other format with enforces tgable alignment. If your entering data into a web UI, I would not have any expectations regarding the final formatting as that will depend heavily on what the backend does to the supplied input and how the data is presented to anyone looking at that output.
Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Hi, Ihor Radchenko writes: Thinking about the whole idea of :noweb-trans more, I see little benefit compared to something like: #+name: documentation This is a sample function documentation. Because there are "quotes", it must be escaped and cannot be directly used as noweb-reference. #+name: doc-escape #+begin_src emacs-lisp :var str="" :tangle no (prin1-to-string (string-trim-right str)) #+end_src #+begin_src emacs-lisp :tangle yes (defun test () <> t) #+end_src I had converted my uses (tangling code, not text/documentation) to this but I ended up reverting. Some drawbacks: + doesn't work for all languages (does work for LaTeX) + the tangle gets very noisy: not only are the result of execution printed in the echo buffer, but emacs visits the tangling buffer and moves the point to each block. Perhaps this is a bug that can be fixed. + src block execution also resets the noweb cache, slowing down tangle, though I have not tried to measure the effect. As stated in the OP, I find it unfortunate that org does not provide any way to tangle the content of a src block to a string representing this code. If anyone shows any interest, I've provided two possible implementations in this thread, that I can rebase. Regards, -- Sébastien Miquel
Re: export a org table to ascii format (tabs) are not conserved, culprit orgtbl-to-tsv?
On Monday, 30 May 2022 at 17:48, Uwe Brauer wrote: > The problem also occurs when I export the table using the > orgtbl-to-tsv The hint is in the name: tsv means "tab separated values" so each entry (stripped of trailing spaces) is separated by a tab character (\t, o11, 0x09). If you look at the exported text carefully, you'll find that there is only one character between each entry and C-x = will tell you what that character is. -- : Eric S Fraga, with org release_9.5.3-511-g8e69ad in Emacs 29.0.50
export a org table to ascii format (tabs) are not conserved, culprit orgtbl-to-tsv?
Hi I wanted to export a 4x4 table to ascii to insert it into a web fill in interface. However the column get distorted. I tried to tabify or untabify the buffer but it did not help. The problem also occurs when I export the table using the orgtbl-to-tsv #+begin_example | Course | L | M | X | J | V | |--+-+-+-+-+-| | Statistics | 10:30-11:30 | | 10:00-11:20 | | 10:30-11:30 | | Differential Equations | 12:30-13:30 | | 13:00-14:15 | | 12:30-13:30 | | Master | 14:30-15:30 | | 15:30-16:30 | 14:30-15:30 | | | Numerical Analysis :00-19:00 | 18:00-19:00 | 18:00-19:00 | 18:00-19:00 | | 7.5 | | | | | | 19:00-20:00 | | |--+-+-+-+-+-| | | | | | | | #+end_example Converted to #+begin_example Course L M X J V Statistics 10:30-11:30 10:00-11:20 10:30-11:30 Differential Equations 12:30-13:30 13:00-14:15 12:30-13:30 Master 14:30-15:30 15:30-16:30 14:30-15:30 Numerical Analysis 18:00-19:00 18:00-19:00 18:00-19:00 18:00-19:00 19:00-20:00 #+end_example Any idea what is wrong here? Regards Uwe Brauer -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine.
a simple(r) html export format (like org-mime)
Hi Although the vanilla html export backend produces nice html, I sometimes need a simpler solution[1], like the one produced by org-mime (which is for email). Does anybody know about such an exporter? Thanks Uwe Brauer Footnotes: [1] I will insert the htmlised buffer in some moodle interface, since I found its native html editor too cumbersome. -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine.
Re: [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps
On 30/05/2022 21:00, Ihor Radchenko wrote: - (let* ((mime-type (mailcap-extension-to-mime (or ext ""))) + (let* ((mime-type (if (executable-find "file") +(shell-command-to-string + (format "%s --brief --mime-type --dereference %s" + (executable-find "file") (shell-quote-argument (executable-find "file")) For the case of a directory with spaces or other characters interpreted by shell in the PATH environment. Unsure if "file" command variants exist that do not support --dereference. Another pitfalls with `shell-command-to-string' is that it provides no way to handle errors. I would consider 2>/dev/null to not consider error message as MIME type and `mailcap-extension-to-mime' as fallback when "file" command fails. (let* ((file-executable (executable-find "file")) (mime-type-file (and file-executable (shell-command-to-string (format "%s --brief --mime-type --dereference %s 2>/dev/null" ; ... ))) (mime-type (if (org-string-nw-p mime-type-file) mime-type-file (mailcap-extension-to-mime (or ext ""))) + (shell-quote-argument (convert-standard-filename file + (mailcap-extension-to-mime (or ext "" Max Nikulin writes: 3. With your patch and the following additional entry in ~/.mailcap (notice "text" instead of "application" and just "emacs") text/x-shellscript; emacs %s; test=test -n "$DISPLAY" new Emacs session is started. It is a problem but partially it is caused by incorrect mailcap configuration. Unlike "text/plain" that would be handled by view-mode unless `mailcap-mime-data' were erased in Emacs-27, "text/x-shellscript" is handled by less on my main system due to mailcap while I would expect same Emacs session. I am confused here. org-file-apps-gnu says that we rely on mailcap: ((remote . emacs) (system . mailcap) (t . mailcap)) So, is (3) following what you would expect from mailcap (regardless whether it is incorrectly configured or not)? Wrong configuration of mailcap is none of Org business - we need not to be "smart" and fix user "errors". They may be deliberate. Ihor, I am afraid that your patch may break some subtle equilibrium existing despite discrepancy in MIME type names for shell script. Worst scenario: without the patch shell scripts are opened in the same Emacs session, with it attempt to open a script silently fails due to "less" handler requiring a terminal. I admit that your patch may improve handling of e.g. images, however it is more rare case when an image file has no suffix, while it is quite common for various scripts (shell, python, perl, etc.) I have not tried emacs-28 yet or some other full fledged desktop environment (in VM). There is no official MIME type for shell scripts http://www.iana.org/assignments/media-types/media-types.xhtml so definitions "text" or "application", "x-sh" or "x-shellscript" vary. E.g. https://wiki.debian.org/ShellScript : "The MIME type of shell scripts is nowadays text/x-shellscript but other systems may still use application/x-shellscript." Emacs uses application/x-sh for the .sh suffix. There is no association for this type in `mailcap-mime-data'. The "file" command reports "text/x-shellscript". I have neither "application/x-sh" nor "text/x-shellscript" in /etc/mailcap (Ubuntu-20.04), there are only several entries for "application/x-shellscript". That is why your patch should not make handling of shell scripts worse... till mailcap and "file" will start to use the same type. In some cases it may be handy to launch remote viewer from a host accessed through ssh, but let's leave it aside. This is exactly why you can always customize org-file-apps. I am confused by this phrase. `org-file-apps' is ignored for remote files, otherwise more care would be required for executing "file". I added the extra argument as you suggested. See the new version of the patch. Though my man tells me that --dereference is the default. Not on your system apparently. I have no idea. Quick search have not provided a changelog, but I have noticed https://bugs.astron.com/view.php?id=29 (mailcap-extension-to-mime "sh") => "text/x-sh" run-mailcap --norun examples/org/script/tstorg.sh Error: no "view" mailcap rules found for type "application/x-sh" And "text/x-shellscript" as above. This should not matter for us. As long as mailcap-mime-info returns something meaningful, we should be good to go. Unless mailcap-mime-info itself is buggy. Following a link to a shell script from an org file (without customization) I expect that it is opened in the same Emacs session. Maybe my expectation is wrong and system-wide handler (gedit, kate, etc.) should be launched. It seems current status
Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
Ihor Radchenko writes: > Sounds reasonable. However, a more consistent way to handle line numbers > would be using switches, like what we do in EXAMPLE blocks. See > org-element-example-block-parser and 12.6 Literal Examples section of > the manual. (I didn't remember that I had sent this patch...). I'll take a look at the function you mention, when I have some time. In any case, keep in mind that there are some conventions in verse numbering: the white lines (separation between stanzas) are never numbered and there is a sequence: 5 (first verse alwais remains unnumbered) ... 10 ... 15 ..., which can be chosen using the :lines attribute. :lines t defaults to a sequence of 5 verses. I chose this syntax to follow the syntax of verse numbering with output to LaTeX (another patch of mine that is already included in Org. In that case, the 'verse' LaTeX package is used). Verse numbering is a special case. In fact, a long time ago I wrote this package: https://gitlab.com/maciaschain/org-verse-num Best regards, Juan Manuel
Re: [BUG] org-element-warnings when accidentially inserting "z" into timestamp [9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/)]
Hi Ihor, * Ihor Radchenko [2022-05-30; 19:51]: > Gregor Zattler writes: > >> I accidentally inserted a "z" into a closing timestamp in a >> clockline like so: 20zznn22-05-30 >> >> This happened because I use key chors and didn't enter the >> chord fast enough. >> >> >> This produced a *Warnings* buffer of 2,3 MB size. > > Possibly a duplicate of > https://list.orgmode.org/orgmode/87tuh88kjv.fsf@localhost/ > > I just pushed a fix upstream. Can you please check again with the latest > Org? this seems to have solved the warnings -Problem. No warning any more (I saved the org-persistent cache and tested with the cache which was involved in the bug reprot and with a fresh one). Now I realized, that even after quitting and restarting Emacs, I cannot insert a timestamp, I get the following error message: org-parse-time-string: Not an Org time string: [20zznn22-05-30 Mo 11:34] And then there is a dangling CLOCK: line without timestamps at the expected line in my org file. It took a while till I realized that there was a corrupted timestamp in my org file a few clock lines below. It would be helpful, if the message contained the file name and probably even the line number. Thanks for fixing this so quick. Ciao, -- Gregor
[PATCH v3] Re: Bug in 9.5.3 org--file-default-apps
Max Nikulin writes:
> However, in my opinion, it does not address original Craig's issue. The
> patch improves handling of *non-text* files requiring *external*
> viewers, while Craig complained that behavior for shell script is
> incorrect and his problem is tightly bound to erased `mailcap-mime-data'.
Ideally, we need a feedback from him.
For emacs-27 specifically, we might need to work around the bug.
However, I am not sure what would be the best way to do it. The easiest
can be changing the default value of org-file-apps-gnu on Emacs 27
specifically to not use mailcap at all. But I am pretty sure that we can
do better.
> I can not reproduce behavior he observed exactly, Org does not opens
> shell scripts by less, but it tries and silently (it is expected) fails.
>
> My results (emacs-27):
> 1. If there is no mailcap files at all, the script is opened
> in the same emacs session that is correct from my point of view.
> 2. If I add ~/.mailcap
> text/plain; less '%s'; needsterminal
> then I get silent failures
> Running less /etc/profile...done
> 3. With your patch and the following additional entry in ~/.mailcap
> (notice "text" instead of "application" and just "emacs")
> text/x-shellscript; emacs %s; test=test -n "$DISPLAY"
> new Emacs session is started. It is a problem but partially
> it is caused by incorrect mailcap configuration.
> Unlike "text/plain" that would be handled by view-mode
> unless `mailcap-mime-data' were erased in Emacs-27,
> "text/x-shellscript" is handled by less on my main system
> due to mailcap while I would expect same Emacs session.
I am confused here. org-file-apps-gnu says that we rely on mailcap:
((remote . emacs)
(system . mailcap)
(t . mailcap))
So, is (3) following what you would expect from mailcap (regardless
whether it is incorrectly configured or not)? Wrong configuration of
mailcap is none of Org business - we need not to be "smart" and fix user
"errors". They may be deliberate.
> I read implementation of `org-open-file' once more and now I see that
> currently remote files can not be processed by mailcap code path even
> with custom `org-file-apps', so thank you for explanation. In some cases
> it may be handy to launch remote viewer from a host accessed through
> ssh, but let's leave it aside.
This is exactly why you can always customize org-file-apps.
>> - (let* ((mime-type (mailcap-extension-to-mime (or ext "")))
>> + (let* ((mime-type (if (executable-find "file")
>
> I would consider (and ... (not remp)) despite currently it is redundant.
> Just to mitigate consequences if other parts of this complicated
> function will be modified. On the other hand
> `start-process-shell-command' is not ready for remote files anyway, so
> major cleanup would be required.
I would be in favor of a cleanup (by someone™), but I am against
redundancy. Such redundancy may mask bugs making them difficult to
debug. Not to mention code readability.
>> +(shell-command-to-string
>> + (format "%s --brief --mime-type %s"
>> + (executable-find "file")
>> + (shell-quote-argument
>> (convert-standard-filename file
>
> It is not enough to cure my paranoia. However the following case is
> rather pathological
>
> mkdir 'Program Files'
> ln -s /usr/bin/file 'Program Files'/
> PATH="$HOME/Program Files:$PATH" \
> emacs -Q -L ~/src/org-mode/lisp/ ~/examples/org/open-script.org &
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>string-match("/" nil 0)
>split-string(nil "/")
>mailcap-mime-info("/bin/bash: line 1: /home/ubuntu/Program: No such
> f...")
>(let* ((mime-type (if (executable-find "file")
> (shell-command-to-string (format "%s --brief --mime-type %s"
> (executable-find "file") (shell-quote-argument
> (convert-standard-filename file (mailcap-extension-to-mime (or ext
> "" (command (mailcap-mime-info mime-type))) (if (stringp command)
> (setq cmd command) (setq cmd 'emacs)))
Well. If we want to be this paranoid, could you write a generic safe
shell-command wrapper that takes care of various edge cases? Then, we
can add that wrapper to org-macs and reuse it in various places where we
need to run external command.
> Another corner case:
>
> file --brief --mime-type tstorg-sh-symlink
> inode/symlink
> file --brief --mime-type --dereference tstorg-sh-symlink
> text/x-shellscript
I added the extra argument as you suggested. See the new version of the
patch. Though my man tells me that --dereference is the default. Not on
your system apparently.
>> + (executable-find "file")
>> + (shell-quote-argument
>> (convert-standard-filename file
>> + (mailcap-extension-to-mime (or ext ""
>
> Actually
Re: Proposal: 'executable' org-capture-templaes
Ihor Radchenko writes:
> Arthur Miller writes:
>
>>> By "generic" I did not mean general-purpose all-functional framework.
>>> We just need something to remove code duplication in
>>> org-export-dispatch, org-agenda, org-capture, org-set-tags-command, etc
>>> They all share pretty similar code to generate dialogues.
>>>
>>> As for familiarity, I understand and it is exactly the reason why I
>>> suggested to factor out the menu code from capture templates.
>>
>> I am not really familiar with those other dialogues but org-capture, so I
>> only
>> had that one in the mind. Yes, I agree if the similar code is used/shared in
>> several places than it does make sense to refactor it out.
>
> This refactoring could be a practical way to get something similar to
> your proposal into Org core. At least, if the menus are factored out
> appropriately.
As I see from 'org-capture' function, it does not seem to be terribly hard to
factor menu creation out. There seem to be two parts: template selection which
is already done by 'org-capture-select-template' function, and then the main
work that one has to implement on its own, which is specific to whatever one
would like to implement. I just did a quick refactor to test the idea:
#+begin_src emacs-lisp
(require 'org-capture)
(defun org-menu ( goto keys)
(interactive "P")
(let* ((entry (org-capture-select-template keys)))
(cond
((equal entry "C")
(customize-variable 'org-capture-templates))
((equal entry "q")
(user-error "Abort"))
(t
(let ((f (nth 2 entry)))
(if (not f) (error "Missing function specification.")
(if (commandp f) (call-interactively f)
(if (functionp f) (funcall f)
(error "Invalid function specification.")
(defun org-capture-some-menu ()
(interactive)
(let ((org-capture-templates
`(("F" "Functions")
("Fh" "Hello World"
(lambda ()
(message "Hello, World")))
("Ff" "Find file" ,(function find-file)
(org-menu)))
(define-key global-map (kbd "C-S-m") #'org-capture-some-menu)
#+end_src
Instead of hardcoding the actual work in the conditional statement, there should
be a function to be called, so org-capture would setup its own work, some random
"exec" menu like here would setup its own and so on. I haven't look at other
parts of org you have mentioned, so I am not yet sure if the approach would work
for all the kids in the block. I don't think it would that much harder to
refactor this out, but I might be wrong, since I am not that familiar with org
code.
Factoring this out of Org itself, as suggested by RMS in the link you posted
might be much more work though. I haven't looked at that, and question is if
that is really worth the effort? I would agree with him that things like
org-table and date/time handling would be great to have in entire Emacs, without
need to load org, at least bigger parts of it. If I remember well, table mode
started outside of org as its own minor mode and got merged into org.
> The above statement is a hint that patches are welcome :)
As said, I am not that well familiar with org in-depth, and with other places
that might need to be factored out, so I don't promise anything. Initially I
just got a quick idea while working on a project of mine with org-capture, and
hacked the 'org-capture' function to implement my idea :).
/a
Re: [PATCH] org-imenu-get-tree: Allow parent headings to be selected themselves
Adam Porter writes: > Please see the attached patch that remedies a longstanding, simple > shortcoming in Org's Imenu support. I tried to test your patch starting from emacs -Q and I am unable to select parent headings. Could you provide a detailed example demonstrating the difference before/after the patch? Best, Ihor
Re: [PATCH] "Cache corruption detected" when editing CLOCK timestamp by hand
Ihor Radchenko writes: >> Minimal reproducer: >> >> 1. Create an empty org file and open it >> 2. Yank the following string: "CLOCK: [2021-10-22 Fri 10:41]--[2021]" >> 3. M-: (org-element-at-point) > > The attached is tentative fix for cases like the above. Applied onto main via 4dda0d7a8. This may also fix https://list.orgmode.org/8735grjq2e.fsf@no.workgroup/T/#u > Should we consider the above CLOCK line as a valid running clock or > maybe it should be parsed as a paragraph? I am still leaving this question open despite applying the above patch. At least, we need to get the bug fixed. Best, Ihor
Re: [BUG] org-element-warnings when accidentially inserting "z" into timestamp [9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/)]
Gregor Zattler writes: > I accidentally inserted a "z" into a closing timestamp in a > clockline like so: 20zznn22-05-30 > > This happened because I use key chors and didn't enter the > chord fast enough. > > > This produced a *Warnings* buffer of 2,3 MB size. Possibly a duplicate of https://list.orgmode.org/orgmode/87tuh88kjv.fsf@localhost/ I just pushed a fix upstream. Can you please check again with the latest Org? Best, Ihor
Re: # Comments export
Eric S Fraga writes: > I use drawers for this and then have specific processing of different > types of drawers, depending on target. > > For instance, I might have :note: drawers (similar to inline tasks) with > the following processing (for odt export; similar for LaTeX): > > --8<---cut here---start->8--- > (setq-local org-odt-format-drawer-function > (lambda (name contents) > (if (string= name "note") > (progn > (format " text:background=\"#00\">%s" contents) > --8<---cut here---end--->8--- > > (progn because I used to do more in there...) I use a special type of footnote, which is exported to LaTeX as pdf annotations (with the pdfannotate package) and to odt as comments. The use of footnotes allows me to put comments and annotations within the paragraph: https://list.orgmode.org/877de55cjf@posteo.net/ Best regards, Juan Manuel
[BUG] org-element-warnings when accidentially inserting "z" into timestamp [9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/)]
Ciao, Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. Dear org mode developers, Ihor, I accidentally inserted a "z" into a closing timestamp in a clockline like so: 20zznn22-05-30 This happened because I use key chors and didn't enter the chord fast enough. This produced a *Warnings* buffer of 2,3 MB size. Next time I provoced this it was only 66 KB *Warnings* I use org mode as build a few weeks ago, dunno if this still of interest. Since the backtrace contains private information I would rather not send it to the list, but to an individual maybe!? If this backtraces are of interest, whom should I send them to? Ciao; Gregor Emacs : GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2022-05-15 Package: Org mode version 9.5.3 (release_9.5.3-471-gebbef7.dirty @ /home/grfz/src/org-mode/lisp/) -- Gregor
[PATCH] org-imenu-get-tree: Allow parent headings to be selected themselves
Hi, Please see the attached patch that remedies a longstanding, simple shortcoming in Org's Imenu support. Thanks, AdamFrom 00104b2b9246b19cdb02bbce993d120581dc9f0e Mon Sep 17 00:00:00 2001 From: Adam Porter Date: Mon, 30 May 2022 02:59:06 -0500 Subject: [PATCH] org-imenu-get-tree: Allow parent headings to be selected themselves Imenu only allows leaf nodes to be chosen. In programming language buffers, non-leaf nodes are "virtual" nodes, i.e. categories like "functions" or "variables" rather than actual locations in the buffer. But in Org buffers, non-leaf nodes are headings, which the user may want to select with Imenu. So now, for a non-leaf node (i.e. headings that have children), we push an extra item to the result, without including its children, so that it can be listed and selected in Imenu as a leaf node. --- lisp/org-compat.el | 5 + 1 file changed, 5 insertions(+) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 7041976..e9c53cf 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -1053,6 +1053,11 @@ This also applied for speedbar access." (let* ((m (point-marker)) (item (propertize headline 'org-imenu-marker m 'org-imenu t))) (push m org-imenu-markers) + (when (save-excursion (org-goto-first-child)) + ;; Entry has children: push an extra item for entry + ;; itself so it can be selected (Imenu only allows + ;; selection of leaf nodes). + (push (cons item m) (aref subs level))) (if (>= level last-level) (push (cons item m) (aref subs level)) (push (cons item -- 2.7.4
Re: # Comments export
On Sunday, 29 May 2022 at 00:46, Ypo wrote: > I wanted to export my #comments so I could share my notes with more > people, using HTML export. I would export all of them. I use drawers for this and then have specific processing of different types of drawers, depending on target. For instance, I might have :note: drawers (similar to inline tasks) with the following processing (for odt export; similar for LaTeX): --8<---cut here---start->8--- (setq-local org-odt-format-drawer-function (lambda (name contents) (if (string= name "note") (progn (format "%s" contents) --8<---cut here---end--->8--- (progn because I used to do more in there...) -- : Eric S Fraga, with org release_9.5.3-511-g8e69ad in Emacs 29.0.50
