Re: wip-cite status question and feedback
Hello, denis.maier.li...@mailbox.org writes: > Bruce has already sent a link to Pandoc's org-mode Reader where you > can find the citation modes. The standard (markdown) implementation > can be found here: > https://github.com/jgm/pandoc/blob/f2b337768e95c8903f65e597f7d8cd81938dacc3/src/Text/Pandoc/Readers/Markdown.hs > Thank you. > Anyway, currently there are basically three modes: > - NormalCitation > - SuppressAuthor > - AuthorInText [...] > So: > [@doe] => NormalCitation > [-@doe] => SuppressAuthor > @doe argues ... => AuthorInText > -@doe [23] => SuppressAuthor Let's assume Org implements SuppressAuthor as "-@doe", so far it has: | Syntax| Mode| Sample output | |---+-+---| | @doe or [cite:@doe] | AuthorInText| Doe (2020)| | -@doe or [cite:-@doe] | AuthorInText + SuppressAuthor | (2020)| | [@doe] or [(cite):@doe] | NormalCitation | (Doe, 2020) | | [-@doe] or [(cite):-@doe] | NormalCitation + SuppressAuthor | (2020)| So, we could mix suppress author with some other style, although this seems useless for the time being. Current syntax is not great because it is ad-hoc, and not very future-proof, if new modes appear. Also, the "(cite)" key is a bit mouthful, "citep" might have been prettier. Anyway, is it complete enough? Also, there is some ambiguity between modes applying reference-wise, i.e., "suppress author", and modes applying to the whole reference, i.e., NormalCitation and AuthorInText. Therefore, I'm wondering: has the following any meaning? [cite: -@doe; @foo] [(cite): -@doe; @foo] > Depending on CSL's future development there might well be other > citations modes. I personally think there's much to learn from > biblatex, but that's a different debate... As a related node, from Biblatex, we may also need, e.g., [(Cite):...], but this was rejected for some reason a long time ago. Regards, -- Nicolas Goaziou
Re: Bug: org-insert-item behaves weirdly and then fails
Hello, Jarmo Hurri writes: > Consider the following org file: > > # --- > 1. Some text [fn:: foo] > > 2. > > 3. with items > # --- > > The bug can be reproduced with the following: > 1. go to the end of first line > 2. press M-return , that is (org-meta-return) > 3. return to step 1 > > You will notice that item numbers will first start to behave weirdly, > then eventually an error will be thrown. Indeed. This should now be fixed. Thank you. Regards, -- Nicolas Goaziou
Re: wip-cite status question and feedback
Hello, "Bruce D'Arcus" writes: > Another question on the syntax. > > Does it support something like this in the pandoc syntax? > > Doe [-@doe19] argues ... No it doesn't. That seems reasonable to include. I add it to my TODO list. > The minus sign signals to suppress the author rendering, so that you > end up with: > > Doe (2019) > > ... instead of: > > Doe (Doe, 2019) > > I know latex works differently, but this is simple, and very flexible. Speaking of which, I read about the "citation modes", which may be preferred over "suppress author". What are these citation modes? How do you combine them if "suppress author" is one of the "citation modes". Do citation modes apply on a reference, or a complete citation, which possibly contains multiple references? Also, on a related subject, now I remember [@key] is not a shorthand for [cite:@key]; the former is meant as "author in text" style. Regards, -- Nicolas Goaziou
Re: wip-cite status question and feedback
Hello, "Bruce D'Arcus" writes: > Note that in CSL processors, the locators are meaningful key-values, > basically; not plain text strings. OK, but it is enough for Org to feed a CSL processor with, e.g., key-> "@doe99" prefix -> "see " suffix -> ", pp. 33-35" Then CSL processor does its job to extract whatever information it needs. Am I right? > While I of course can't speak for John, I would hope and expect org > ref to support the new syntax. > > I would hope and expect the same of other packages (like ebib) that > use their own custom syntax. I hope so, too. But it would help if developers could chime in and tell what API Org should provide. This is particularly important since Org will only provide the API, without any specialized implementation. More on this at the end of the message. > 1. just have a super simple citation export formatter, with (per >above) room to configure an external one Sure. Org should provide default export for citations in LaTeX, ASCII, HTML, Texinfo and ODT. Suggestions are more than welcome. > 2. while I don't know its status, include citeproc-org in org and > emacs I think citeproc-el should ship with Emacs, but I cannot speak for Emacs; it would be nice to ask Emacs developers about it. > I'd say if citeproc-org is far along and free of substantial bugs, 2 > might make sense. I am, of course, biased, but CSL's been widely > deployed in the wild for more than a decade, and there are thousands > of available styles. > > Otherwise, and more likely, 1 would be the best path; users get basic > output formatting for citations, but then can plug in more elaborate > tools (citeproc-org, citeproc-hs*, etc.) if they need them. Option 2 makes a lot of sense if citeproc-el is integrated with Emacs. Until them, I agree that option 1 is the way to go at the moment. > WDY about that? Sounds like a plan. Let me summarize it a bit : 1. [ ] Finalize Org citation syntax. It is mostly good, but we need to decide about the following points: - [ ] Should it include both "(cite):" and "cite:", i.e., does it make sense to provide a (very limited) style specification piece wise? - [ ] Should it include /global/ prefix and suffix? - [ ] Should we keep the short specification, i.e., "[@key]"? - [ ] What kind of markup do we allow in a citation? At the moment the exhaustive list is: bold, code, entity, italic, latex-fragment, strike-through, subscript, superscript, underline, verbatim and line breaks. 2. [ ] Decide about API Org should provide for it to be useful. Here are some low hanging fruits: - [ ] List all ".bib" files associated to the document, - [ ] List all citations, - [ ] Return citation key at point, if any. - Anything else? Moreover, we need to decide about how external processors could plug into the export framework. - [ ] For example, it could be a simple variable bound to a list of functions. Each function accepts three arguments: the export back-end, as a symbol, the full citation, as a list of triplets (key, prefix, suffix) along with global prefix/suffix, and the usual INFO communication channel. Does it need more? - [ ] Also, the prefix/suffix may contain some Org markup, so this needs to be also processed. Should it happen before, or after the external processor does its job? I.e., should the function translate into Org or target format? 3. [ ] Specify the kind of basic translation that be done out of the box? Ideally, every non-derived back-end should do something, even basic. Therefore, we need to propose some translation pattern for each of the following: - [ ] ASCII - [ ] HTML - [ ] LaTeX - [ ] ODT - [ ] Texinfo 4. Anything else? We need help, or at least opinion, from actual implementors to go further. I'm CC'ing some of them. I can take care of the implementation (with some time, my plate is full at the moment), but I'm mostly incompetent about design issues. So, what about ticking off some items? Regards, -- Nicolas Goaziou
Re: wip-cite status question and feedback
uot;see " is the prefix of the first citation reference, not a global prefix. > While I do wonder if the syntax could be simplified, my main hope is that > it actually gets merged to master and deployed, to harmonize the variety of > different ways emacs tools (org-ref, ebib, pandoc, etc.) are dealing with > citation links in org currently. If the syntax is practical, we could merge it, yes. Maybe that's the way forward, after all. But then? What library is going to use it? Org Ref is well established and is unlikely to switch to the new syntax. It would be nice if both syntax could converge at some point, though. The point of the new syntax is to make it easier for this kind of extension. "citeproc-el" is not included in Emacs, so integrating "citeproc-org" in Org may not be helpful at this point. Since Org is bundled with Emacs, it cannot use external libraries. WDYT? Regards, -- Nicolas Goaziou
Re: Bug: org-agenda-tag-filter-preset not respected [9.3.6 (9.3.6-19-gf360f9-elpaplus @ /home/jorge/.config/emacs/elpa/27.0/develop/org-plus-contrib-20200302/)]
Hello, Jorge P. de Morais Neto writes: > Hi. I am sorry for insisting, but this bug report is a month old and > has not been added to <https://orgmode.org/worg/org-issues.html>. AFAIK, this file is not maintained anymore. Note that it strength was not the HTML report, but the fact that you could import the Org counterpart in your agenda files. > I have just tested and reproduced it with Emacs 27 -- emacs-27 branch, > snapshot from [2020-04-04 sáb] -- and org-plus-contrib 20200406. > > In this situation, is it OK to remind you of the bug every month? Certainly. Unfortunately, no one volunteered to fix the issue so far. You may want to have a look at it, you will certainly get help doing so. Otherwise, you are welcome to bump the report from time to time. Regards, -- Nicolas Goaziou
Re: negative values for EFFORT result in error when switching to column view
Heiko Schmidt writes: > This is exactly the reason why I'd love to have negative values for > the durations. It would open the possibility of doing something like > "accounting" of time. I think you can do accounting of time without introducing negative duration. Basic accounting implies having two categories. You expect them to be "positive" and "negative", but it could also be "positive in property A" and "positive in property B". > I'm working with self defined duration units and it would be of great > value to be able to calculate the balance for planned and done work > time. I don't use clocking. > > What'd be wrong about having -0:30 h, -30 min, -2.5 h, -3 d or -3 m? > It'd be an addition no change so there would hoefully be no > incompatibilities. > > Maybe even 3m -3d be or -3m 3d could be of use. No incompatibility doesn't mean no cost. It adds code complexity. You also have to maintain the feature later on, make sure it doesn't break future code, etc. Moreover, I'm not convinced about the general need for such a feature. Of course, it is possible that I may be missing the point. Org folks may want to chime in and correct me if I do. > As I see there is org-duration.el - Have the changes to be made only > there? I think so. But I suggest to check if you cannot do otherwise (again, I'm sure you can).
Re: Do something useful with ".+" and hours repeaters
Hello, Kyle Meyer writes: > You could use floor's DIVISOR argument: > > (floor (- (org-time-stamp-to-now ts t)) 60) Good catch! I keep forgetting about this argument. I added tests, mentioned the change in ORG-NEWS, and applied the patch. I hesitated using the UPDOWN optional argument from `org-timestamp-change' (i.e., obey to `org-time-stamp-rounding-minutes'), but eventually decided to ignore it for now. We can always reconsider this later on. Thank you. Regards, -- Nicolas Goaziou
Re: Problem
Hello, Eric S Fraga writes: > On Monday, 6 Apr 2020 at 07:49, Charles Millar wrote: >> Just ran the same file with the following versions >> >> Org mode version 9.3.6 (release_9.3.6-449-gb99357 @ >> /usr/local/share/org-mode/lisp/) >> GNU Emacs 28.0.50 (build 87, x86_64-pc-linux-gnu, GTK+ Version >> 3.24.14, cairo version 1.16.0) of 2020-04-06 > > okay, one less variable. > > have you tried this with "emacs -Q" in case there's something in your > configuration? This happens because `org-latex-hyperref-template' is empty, which is a valid use-case. I fixed it in both maint and master. Thanks to you two for the report and the debugging help. Regards, -- Nicolas Goaziou
Re: negative values for EFFORT result in error when switching to column view
Hello, Heiko Schmidt writes: > When M-x org-columns I'd like to see column view with the balanced sum > of the hours planned and the hours really worked, but I get an error > > cond: Invalid duration format: "-2 h" > > I know I'm using old versions but this problem is also on newer > versions. Effort property accepts a specific, and well defined type of value: a duration. Such values cannot be negative, as explained in the error message. You may, however, use a different property for your use-case, and apply column view on it. Regards, -- Nicolas Goaziou
Re: Why is `org-element-affiliated-keywords' a var when `org-element--affiliated-re' is a const?
Hello, Johan Tolö writes: > Dear all, > > I want to add my own org-element affiliated keyword "REF" in order > to provide a reference to some other part of an org mode document > (or another document) for a link. > > For example: > > #+NAME: a-figure > #+REF: [[file:another_document.org]] > > [[file:a-figure.png]] > > I want to use `org-element-context' to get the link element and > use `org-element-property' to get the `REF' property. > > I tried changing `org-element-affiliated-keywords' in order to > define my own keyword. This is never picked up by > `org-element-context' since it uses `org-element--affiliated-re' > which is defined as a const and thus is never updated to reflect > the change to `org-element-affiliated-keywords'. The help text for > `org-element--affiliated-re' even mentions changing > `org-element-affiliated-keywords'. > > Is this an oversight or am I trying to use this is a way that is > not intended? Syntax is not meant to be changed by users. Also, `org-element-affiliated-keywords' is a defconst. You might abuse #+header: affiliated keyword to add a reference. Regards, -- Nicolas Goaziou
Do something useful with ".+" and hours repeaters
Hello, Someone on #org-mode (sorry, I cannot remember the nickname) reported that ".+" repeater style was not handling properly (not handling at all, actually) hours spans. As a reminder, ".+" means "repeat, starting from today as the base date". With hours, it seems logical to "repeat, starting from now as the base date". The attached patch does that. WDYT? -- Nicolas Goaziou >From 19ee311eb35bc4cde08e61bc485a679df2d584dd Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Sun, 5 Apr 2020 15:47:45 +0200 Subject: [PATCH] Handle ".+" repeater style for hours * lisp/org.el (org-auto-repeat-maybe): Handle ".+" repeater style for hours. * doc/org-manual.org (Repeated tasks): Add an example. --- doc/org-manual.org | 4 lisp/org.el| 11 --- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 5f55e9bd5..ee054a744 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -6337,6 +6337,10 @@ special repeaters =++= and =.+=. For example: ,** TODO Check the batteries in the smoke detectors DEADLINE: <2005-11-01 Tue .+1m> Marking this DONE will shift the date to one month after today. + +,** TODO Play a major third while pushing the bird through the door + DEADLINE: <2019-04-05 08:00 Sun .+1h> + Marking this DONE shifts the date to exactly one hour from now. #+end_example #+vindex: org-agenda-skip-scheduled-if-deadline-is-shown diff --git a/lisp/org.el b/lisp/org.el index 06891b8bd..b9742514d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10146,9 +10146,14 @@ This function is run automatically after each state change to a DONE state." (repeater-type (match-string 1 ts))) (cond ((equal "." repeater-type) - ;; Shift starting date to today. - (org-timestamp-change (- (org-today) (time-to-days time)) - 'day)) + ;; Shift starting date to today, or now if + ;; repeater is by hours. + (if (equal what "h") + (org-timestamp-change + (floor (/ (- (org-time-stamp-to-now ts t)) 60)) + 'minute) + (org-timestamp-change (- (org-today) (time-to-days time)) + 'day))) ((equal "+" repeater-type) (let ((nshiftmax 10) (nshift 0)) -- 2.26.0
Re: modify frame title in beamer export
Hello, "Gürtler, Martin" writes: > I'd like to modify the frame title in beamer export based on > properties or priority as this is possible in latex export. > > In latex export, one can set the variable > org-latex-format-headline-function to the name of a function that > creates the content of the headline. I was able to use this in > latex export. > > As beamer export is derived from latex export I had hoped that this > would automatically work for beamer export as well, but this > is not the case, the headlines in beamer export are not modified. > > A second question is, whether one could also use properties to > format the headlines. The arguments of the user supplied function > include tags, but not properties. I suggest to create a function modifying the headline element in the parse tree, and add it to `org-export-filter-parse-tree-functions'. This way, you have access to all properties and what not, and can replace the headline by whatever you need. E.g., (untested): (defun my-beamer-frame-title-filter (ast backend info) (cond ((not (org-export-derived-backend-p 'beamer)) ast) (t (org-element-map ast 'headline (lambda (h) (when (equal (org-export-get-node-property :A h) "foo") (org-element-put-property h :title "FOO!"))) info) ast))) HTH, -- Nicolas Goaziou
Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]
Hello, Marco Wahl writes: > Since the change has been in place since 2017 what's the right thing to > do? > > - Wait a while for someone speaking out to keep the state as it is now? > If nobody shows up, just change back to inserting to the left? That, and documenting it in ORG-NEWS, sounds good. > - Introduce a customizable variable for inserting to the left? Please don't. > - Add a parameter to org-table-insert-column to control insertion > left/right and possibly even the number of columns? `org-table-insert-row' has indeed a parameter to control side of insertion. It would make sense to have it in `org-table-insert-column', too. I still think the default should be changed, tho. Regards, -- Nicolas Goaziou
Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]
Eric S Fraga writes: > And I believe that a reasonable expectation is symmetry with inserting a > row. The way I think of it is the arrow indicates to make space by > moving columns/rows in that direction. Most spreadsheets work in this > way, in my experience (but I could be wrong). I understand now. Thanks. Then I agree with you, it would be better to change the behaviour instead of the documentation. > Unfortunately, this only inserts a cell, not a column. Indeed. Regards,
Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]
Hello, Eric S Fraga writes: > On Monday, 30 Mar 2020 at 23:22, Kyle Meyer wrote: >> It looks like the documentation became stale with b8d473a04 (org-table: >> Insert new column to the right instead of the left, 2017-11-19). Thanks >> for updating it. > > Annoyingly, I would have preferred to have the column inserted to the > left of the current column as this would be consistent with the > insertion of rows. It gets me every time I try to insert a column as I > then have to shift columns. And there's no way to insert a column at > the beginning of the row easily. Whereas adding a new column to the end > is trivial: type anything after the last |. > > Could we leave the documentation as it is and change the behaviour? Well, since I apparently made the change, I have to speak for it. When one presses M-S-Right in order to create a new column, I think a reasonable expectation is : 1. to move point to the right, 2. to move point in the newly created column. Consequently, a reasonable expectation is to create the column to the right. Note that adding a column to the beginning of the row is easy: just type "|" near the beginning of the first cell. Does that make sense? Regards, -- Nicolas Goaziou
Re: Bug: Latex-Export does not respect custom latex section hierarchy [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
Hello, Lukas Juhrich writes: > Following the manual[1], I wanted to extend `org-latex-classes` to > support `paragraph` as a fourth level instead of enumerating. > However, everything after the third entry in an `org-latex-classes` > entry is ignored. See `org-export-headline-levels' Regards, -- Nicolas Goaziou
Re: Automatic formatting of the table as you type
Hello, ndame writes: > The other day a code was posted on Reddit which automatically formats > the table as you type: > > https://i.imgur.com/lorIDhY.gif > > > The code looks pretty simple, the actual formatting code is only a few lines > and it might even be possible to rewrite it to simplify it even more: > > https://reddit.com/r/emacs/comments/fosdi2/orgtableautoalignmode_minor_mode_for_auto/ > > > Org should provide this feature out of the box as an optional minor > mode like org-indent-mode. It provides a much nicer user experience > than the current behavior where the table falls apart when you type in > it until you press TAB or such. The idea is nice, and probably a step in the right direction, but `org-at-table-p' and `org-table-align' are not lightweight functions. In some common situations, e.g., when the table is a bit large, or when it is located away from the start of a section, typing in the table may feel sluggish. Therefore, I wonder if Org should include it unless it is optimized in most situations. As a side note, the table doesn't realign when you add a space in a cell. Regards, -- Nicolas Goaziou
Re: New org-store-link on headlines contains tags
Hello, stardiviner writes: > Hi, Nicolas, I found the link part is fixed, Another itch is that the link > description part still contains the statistic cookie [1/2]. For example: > > #+begin_src org > * headline statistics [/] > > [[*headline statistics][headline statistics [/]]] > #+end_src OK. I removed it. Thank you. Regards, -- Nicolas Goaziou
Re: Spaces in bare URLs?
Hello, "Mark E. Shoulson" writes: > 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 Unfortunately, that wasn't reliable. As it is not idempotent, you can never know how many times you need to decode an URL before sending it. Imagine I have a file called "foo%2000.org". Should I link it file:foo%252000.org or file:foo%2000.org? You prefer the former. But what if I forget about the rules? Now, what Org is expected to do with file:foo%252000.org ? Decoding it unconditionally lead to bug reports scattered throughout the years. So did ignoring encoding. The thing is URL encoding is not for human consumption, i.e., we shouldn't have to deal with it. > and you can *count* on it when nothing else works, because you can > always fall back on plain ascii. Current backslash escaping is also well established, and as much ASCII-like as anyone would expect. > 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). True, but that's a minor annoyance. You apparently prefer to encode a URL manually, replacing each space with %20 (and other characters with more baroque escape sequences), rather than adding <...> (or [[...]]) around it and be done with it. Perhaps this one was the bad idea, after all? > 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.) It was not a bad idea. It is not perfect, but it is still better than what we had, because it is unambiguous. You can still use <...> delimiters, or, as you noted, [[...]]. I understand it breaks your workflow, but there is no loss of feature, and no hole either: you can still link to URL with spaces in it. Regards, -- Nicolas Goaziou
Re: fill-paragraph fills planning line; blank line possibility
Hello, Samuel Wales writes: > recent maint -- but i have not got an mwe. i could be doing something wrong. > > * x > SCHEDULED: <2020-03-15 Sun> > mada wakaranai to omou kedo, ima no meeru wa sono koto asdfa muri ni > suru kanosei ga aru. > > if i fill that using m-x fill-paragraph, it fills the planning line also. > > perhaps somebody might know what i am doing wrong or if this is a bug. You are using the wrong function. It should be `org-fill-paragraph'. `fill-paragraph' knows nothing about Org syntax. Hence the result you are observing. Regards, -- Nicolas Goaziou
Re: [PATCH] ox-html.el: Use HTTPS for link to W3 HTML validator
Hello, Augustin Fabre writes: > Subject: [PATCH] ox-html.el: Use HTTPS for link to W3 HTML validator > > * lisp/ox-html.el (org-html-validation-link): Use HTTPS link to W3 > HTML validator. Applied. Thank you! Regards, -- Nicolas Goaziou
Re: [PATCH] Add NO-STATS switch to org-get-heading
Nicolas Goaziou writes: > This assumes statistics cookie is always located at the end of the > title, before the tags. This is not required by the syntax. > > Syntax can evolve, but it could introduce many backward > incompatibilities, so it must be discussed first. Also, note that statistics cookies are not tied to headlines, unlike tags or TODO keywords. They can be located almost anywhere in the document (e.g., in plain lists). So, it seems strange to add it to `org-get-heading'.
Re: [PATCH] Add NO-STATS switch to org-get-heading
Hello, Brice Waegeneire writes: > * lisp/org-element.el (org-element-context): Handle headlines only > containing a statistics cookie. > * lisp/org.el (test-org/get-heading): Add regex capture group 6 for > statistics cookie. > (org-get-heading): Add NO-STATS argument, if > non-nil, will not return the statistics cookie. > * testing/lisp/test-org.el (test-org/get-heading): Add 3 tests using the > NO-STATS argument. This assumes statistics cookie is always located at the end of the title, before the tags. This is not required by the syntax. Syntax can evolve, but it could introduce many backward incompatibilities, so it must be discussed first. Regards, -- Nicolas Goaziou
Re: removal of org-maybe-keyword-time-regexp
Hello, Eric Abrahamsen writes: > I would have liked to know what the "something else" was! Or even "Org > link regexps have been rewritten", something like that. I added an obsolescence warning about it in "org-compat.el". It will still break upstream, since there is no replacement for the variable. > Looks like commit "Move link-related core functions out of \"org.el\"". > Nearly a year ago -- I wasn't paying attention! But defining link > regexps as aliases of other link regexps meant that the regexps matched, > but the match groups were off: that led to silent failure, and took > quite a while to debug. I guess I would have preferred a loud failure. Most variables were only renamed. It's possible that a few of them changed match groups, but that was probably not intentional (I cannot remember). The only intended change was `org-link-bracket-re', which is documented in ORG-NEWS. Regards, -- Nicolas Goaziou
Re: removal of org-maybe-keyword-time-regexp
Hello, Eric Abrahamsen writes: > But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a > simply explanatory string. You're right. However, I'm not sure what the CURRENT-NAME should be, besides "don't use this, you probably want something else" Also, my suggestions still holds: it is useful to warn upstream about it. > I was also recently bit by the removal of a bunch of regexps (in my > case, link regexps), and it would have been useful to have some sort of > a pointer, either in the obsolescence message or in the docs, about what > we're supposed to do instead. I'm not sure about what "bunch of regexps" you are talking about. Regards, -- Nicolas Goaziou
Re: removal of org-maybe-keyword-time-regexp
Hello, Julien Cubizolles writes: > I'm using org-caldav (https://github.com/dengste/org-caldav/) to > synchronize the calendar on my Android phone and Org. Recently this > synchronization stopped working because org-caldav relies on > org-maybe-keyword-time-regexp that has been dropped from Org. As a > workaround, could this variable be reintroduced in org so as not to > break this very useful package ? Could you contact upstream instead? AFAICT, they use this variable only twice. The first occurrence doesn't seem useful (they check for a planning info keyword in a headline, which cannot happen), it is probably enough to look for `org-ts-regexp-both'. I'm not sure about the second one. I guess it would be better for them to use something like: (and (re-search-forward "org-planning-line-re" nil t) (org-at-planning-p) (progn (org-skip-whitespace) (looking-at org-ts-regexp-both))) The (small) issue here is that we cannot properly deprecate a variable that is not replaced with something else (i.e., we're not using `define-obsolete-variable-alias' here). Regards, -- Nicolas Goaziou
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
Hello,
"Dauer, Michael" writes:
> worked at least with 9.1.x, but not anymore
>
> * test
> dfgfas
> {{{author}}}
> dasfas
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: raw replace not working
Hello, Roger Mason writes: > Hello, > > I using Org mode version 9.2.3 (release_9.2.3-390-gfb5091 @ > /home/rmason/.emacs.d/org-git/lisp/) in GNU Emacs 26.3 (build 1, > amd64-portbld-freebsd11.3, X toolkit, Xaw3d scroll bars). > > Here is an ECM: > > #+begin_src shell :results raw replace > #!/usr/bin/env zsh > > mkdir -p Supercell > for i in 1 2 3 > do > touch Supercell/111_stuff.cif > done > ls Supercell > > #+end_src > > #+RESULTS: > 111_stuff.cif > 111_stuff.cif > 111_stuff.cif > > Is there something I'm doing wrong or is this a limitation of org > 9.2.3? It is a limitation of Org. Raw results cannot be replaced because Org cannot know what is the result. You may wrap the output within a drawer. Regards, -- Nicolas Goaziou
Re: org-link containing square brackets
Hello, Joseph Vidal-Rosset writes: > I sent this email to this list: > > https://lists.gnu.org/archive/html/emacs-orgmode/2019-07/msg00123.html > > Unfortunately, the code of hs/replace function that contains > > %5BGmail%5D/ See ORG-NEWS for Org 9.3. I think this should be \[Gmail\]/ Regards, -- Nicolas Goaziou
Re: Bug: org-babel-expand-noweb-references: FIXEDCASE=nil
Hello, Sebastian Miele writes: > org-babel-expand-noweb-references in the current master branch ends with: > > (replace-regexp-in-string noweb-re (lambda...) body nil t 2) > > I.e., the FIXEDCASE argument to replace-regexp-in-string is nil. This > has the effect that in > > #+BEGIN_SRC elisp :noweb-ref AA > (ignore) > #+END_SRC > > #+BEGIN_SRC elisp :noweb yes > <> > #+END_SRC > > the second block is expanded as "(IGNORE)". That probably is a bug. > FIXEDCASE should be t. Indeed! Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: New org-store-link on headlines contains tags
Hello, stardiviner writes: > I found the new org-store-link on headlines contains tags. I don't think this > is > a good way. Because some users like me might change tags. Will that caused Org > open link failure in future if this open link function modified or others. I > think just headline text is good. WDYT? Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: Nested quote blocks?
Hello, Tim Visher writes: > Is there a way to get nested quotes blocks to work? No, you cannot nest quote blocks. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Surely custom code for file links. Haven't dug much deeper since the > issue is solved by the attached patch. Certainly, but that means `org-export-link-as-file' is not working at some level. Since adding a hook is better, and the function was not used anymore, I removed it: it is not necessary. > I'll apply the patch then, unless already taken care of by you or > Bastien! :) Applied. Thank you. Regards, -- Nicolas Goaziou
Re: problem when linking to headlines?
Hello, Alan Schmitt writes: > I have these two files: > > link1.org: > > * Test > > link2.org: > > [[file:link1.org::*Test][Test]] > > When I click on the first link, I get this in a dired buffer (there is > no error). > > /home/schmitta/tmp: > wildcard link1.org::*Test > zsh:1: no matches found: link1.org::*Test > > I'm using Org Mode 9.4, and this issue started occurring recently after > I upgraded org. > > Is this a consequence of the recent change on file links? How can I > debug which link handler is used? Oops. Fixed. Thank you! The link handler is "file", using `org-link-open-as-file' to follow it. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Expanding attachment-links in the buffer makes the link type no longer > be attachment. What makes you think that? The link type is preserved during the substitution, according to the (concat "attachment" ...). > I would prefer if we explicitly set the link type to > files here instead. Storing intermediate state in an attachment link > types makes less sense imo. > > One issue with the current way it's done is that images are treated > differently between attachment links and file links. For HTML exports, > file links are wrapped in a div with class figure where expanded > attachment links are not. It would be nice to investigate why this happens. > Letting org-attach-expand-links do the full > transform to file links would solve that issue. That also > means :export is not needed for org-link-set-parameters. > > Patch attached if you agree to this. Of course! This is what I suggested, like, 6 weeks ago (although, at this time, I was thinking about having the substitution in "ox.el"). Regards, -- Nicolas Goaziou
Re: Document backward-incompatible change in ORG-NEWS?
Hello, Bastien writes: > This is fixed in master but I won't if we should document this bug > fix in ORG-NEWS (or if org-store-link was just momentarily broken.) You are right. This deserves an entry in ORG-NEWS. > If org-store-link was storing the todo keyword, perhaps we can add > a command similar to this one to help users fix broken links: > > (defun org-fix-links () > "Fix ill-formatted internal links. > E.g. replace [[*TODO Headline][headline]] by [[*Headline][headline]]. > Go through the buffer and ask for the replacement." > (interactive) > (visible-mode 1) > (save-excursion > (goto-char (point-min)) > (while (re-search-forward org-link-any-re nil t) I think this is inefficient. It would be better to search directly for (format "\\[\\[\\*%s\\s-+" (regexp-opt org-todo-keywords-1 t)) > (let* ((raw (match-string 2)) >(desc (match-string 3)) >fix new) > (when (and raw desc Why does DESC matter here? We probably want to also replace [[*TODO foo]] > (string-match-p > (concat "^\*" (regexp-opt org-todo-keywords-1) Typo: the correct regexp is "^\\*" > "\\s-+\\(.+\\)$") > raw)) > (setq new (replace-regexp-in-string >(concat (regexp-opt org-todo-keywords-1) "\\s-+") >"" raw)) > (set-text-properties 0 (length new) nil new) Why do you remove all text properties? Also, see `org-no-properties'. Regards, -- Nicolas Goaziou
Re: Strange Org <> OS interaction w/ bad ID
Hello, Ken Mankoff writes: > I thought named IDs were supposed to go into CUSTOM_ID properties > rather than ID properties. Is this incorrect? ID are meant to be automatically generated, and stored in a database. They can work across documents. CUSTOM_ID, OTOH are use-defined values, internal to the document. > Does anyone know why Org is parsing files in random folders when > I have a bad ID and a <>? I don't. You may want to check `org-id-files', or walk the hash table `org-id-locations'. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Bastien writes: > Thanks a lot -- feel free to apply it when you think it's okay. I'd like to hear from Gustav, too, since this affects the changes he introduced. If you are in a hurry, we can also apply it. Up to you. > Also, perhaps can you or Gustav suggest a way to test the new feature > so that we can test this new code? I don't use the feature. I just tried to avoid introducing regressions. It is related to how attachments are opened, and exported. I guess testing should focus on this, in particular export of attached images, i.e., attachements with an image extension. > Do you want to do this for 9.4 or can it be done later on? This can be done later on. I don't have time to work on this. Of course, if someone wants to do it, that would be great, too. Regards, -- Nicolas Goaziou
Re: Survey: changing a few default settings for Org 9.4
Hello, Bastien writes: > Archenoth writes: > >> The tab key is extremely easy to hit, and having a fully formed block >> created by typing a short string of characters makes the >> tab-completion lizard-part of my brain happy in a way that key chord >> combos simply don't. > > You say it better than I did - I will see if I can add a completion > mechanism to `org-insert-structure-template' that is not to hackish. Note that the "the TAB is extremely easy to hit" is not really an argument here. It is no more true than "< s TAB" is faster than "C-c C-, s", i.e., it depends on users, as we already observed. More generally, this discussion is not about "Is Org Tempo useful?". The answer is simple: yes, it is for some users. No need to argue about that. But you can also find plenty of useful Org extensions in "contrib/", or any ELPA. This does not mean they should all ship with Org. Deciding if an extension should or should not go into Org proper is usually not an easy decision. In this case, a strong argument against it is: there is already a template mechanism available out of the box, why would we provide two of them? I think we should focus on this topic, rather than personal preferences. Regards, -- Nicolas Goaziou
Re: testing org-bbdb-anniversaries
Hello, rrandr...@gmail.com (Andrés Ramírez) writes: > I eval 'org-bbdb-anniversaries' that lead me to > > --8<---cut here---start->8--- > Debugger entered--Lisp error: (void-variable date) > (car date) [...] > above is intended behaviour? Sadly, yes. Like most diary-related stuff, it expects the `date' variable to be globally bound. > I would like to to check an specific date on bbdb-records 2020-02-29 > and that date should return me a result that would confirm me > org-bbdb-anniversaries is loading my entries on agenda, otherwise a > warning message should appear on emacs startup. > > Which is the right way of checking org-bbdb-anniversaries is loading my > entries? Something like (let ((date '(2 29 2020))) (org-bbdb-anniversaries)) should do. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Following up,
Nicolas Goaziou writes:
> This is the first part of the suggested changes. These do not touch
> attachment modifications, but rather improve the tooling in "ol.el".
This second patch removes most of the "attachment" leakage in the code
base (mainly "org-element.el" and "ox-*.el"). The features should be the
same as before. Let me know if there's anything wrong.
The only thing left is to refactor the ability to display "attachment"
links as inline images. For now, this is hard-coded in "org.el", but
this should not be the case.
As a third phase, I suggest to add a new parameter in
`org-link-parameters', for example :inlineable. This parameter would be
either a boolean, or a function transforming the path. For example,
"file" links should set it to t and "attachment" links to
`org-attach-expand'. Then `org-display-inline-images' should collect
link types with this flag, apply the transformation, and display images
accordingly.
Regards,
--
Nicolas Goaziou
>From e5ccffcf617f3d04d97840873c0b16913eb65369 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Thu, 20 Feb 2020 09:29:21 +0100
Subject: [PATCH] Do not leak "attachment" links
* lisp/ol.el (org-link-open): Remove "attachment" for special cases.
* lisp/org-attach.el (org-attach-expand-links):
(org-attach-follow): New functions.
(org-attach-link-expand): Remove function.
* lisp/org-element.el (org-element-link-parser):
* lisp/ox-ascii.el (org-ascii-link):
* lisp/ox-html.el (org-html-link):
* lisp/ox-latex.el (org-latex--inline-image):
(org-latex-link):
* lisp/ox-man.el (org-man-link):
* lisp/ox-md.el (org-md-link):
* lisp/ox-odt.el (org-odt-inline-image-rules):
(org-odt-link):
* lisp/ox-texinfo.el (org-texinfo-inline-image-rules):
(org-texinfo-link): Remove "attachment" from special cases.
---
lisp/ol.el | 5 +
lisp/org-attach.el | 45 +++--
lisp/org-element.el | 10 +-
lisp/ox-ascii.el| 23 +--
lisp/ox-html.el | 6 +-
lisp/ox-latex.el| 23 ---
lisp/ox-man.el | 17 ++---
lisp/ox-md.el | 10 ++
lisp/ox-odt.el | 11 ++-
lisp/ox-texinfo.el | 10 +-
10 files changed, 66 insertions(+), 94 deletions(-)
diff --git a/lisp/ol.el b/lisp/ol.el
index 76454d2db..e9bed3972 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -75,7 +75,6 @@
(declare-function org-src-source-type "org-src" ())
(declare-function org-time-stamp-format "org" (&optional long inactive))
(declare-function outline-next-heading "outline" ())
-(declare-function org-attach-link-expand "org-attach" (link &optional buffer-or-name))
;;; Customization
@@ -1027,9 +1026,7 @@ for internal and \"file\" links, or stored as a parameter in
(pcase type
;; Opening a "file" link requires special treatment since we
;; first need to integrate search option, if any.
- ((or "file" "attachment")
- (when (string= type "attachment")
- (setq path (org-attach-link-expand link)))
+ ("file"
(let* ((option (org-element-property :search-option link))
(path (if option (concat path "::" option) path)))
(org-link-open-as-file path
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index d073291a2..97a7236e4 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -41,6 +41,8 @@
(declare-function dired-dwim-target-directory "dired-aux")
(declare-function org-element-property "org-element" (property element))
+(declare-function org-element-type "org-element" (element))
+(declare-function org-export-link-as-file "org-export" (path description backend info))
(defgroup org-attach nil
"Options concerning attachments in Org mode."
@@ -646,22 +648,36 @@ See `org-attach-open'."
Basically, this adds the path to the attachment directory."
(expand-file-name file (org-attach-dir)))
-(defun org-attach-link-expand (link &optional buffer-or-name)
- "Return the full path to the attachment in the LINK element.
-Takes LINK which is a link element, as defined by
-`org-element-link-parser'. If LINK `:type' is attachment the
-full path to the attachment is expanded and returned. Otherwise,
-return nil. If BUFFER-OR-NAME is specified, LINK is expanded in
-that buffer, otherwise current buffer is assumed."
- (let ((type (org-element-property :type link))
- (file (org-element-property :path link))
- (pos (org-element-property :begin link)))
-(when (string= type "attachment")
- (with-current-buffer (or buffer-or-name (current-buffer))
- (goto-char pos)
- (org-attach-expand file)
+(defun org-attach-expan
Re: org link to OCaml comment
Hello, Alan Schmitt writes: > I understand, and I can be careful (and easily fix the link if needed). > If `org-store-link' could do it for me, that would be perfect. I pushed some changes to `org-store-link' in order to fix this. Please report if there is anything wrong. Regards, -- Nicolas Goaziou
Re: Survey: changing a few default settings for Org 9.4
Hello, Bastien writes: > Well, let's agree to disagree on this one. > > org-tempo and C-c C- fill two different use cases: the first one for > fast block insertion while typing, the second one for e.g. when the > region is selected. I don't understand. C-c C-, combination is as fast as Org Tempo: C-c C-, s : 3 keys < s TAB : 3 keys I can agree to disagree, but I don't buy the "fast block insertion while typing" argument: they are as fast. We could even add an "expert" interface that would not display the help menu for an even faster C-c C-, experience. And, about the "while typing" part, C-c C-, can be used anywhere amidst a line. One true argument in favor of Org Tempo, however, is its extensibility. IIRC, it can also insert non-block templates, e.g., "#+include:", whereas C-c C-, cannot. Org has built-in completion for these, tho. > M-x customize-option RET org-modules seems okay to me. Then you may belong to the happy few that happen to find Customize interface "okay". :> I was speaking about "init.el" hacking. One must be cautious when setting Org modules: it requires to be set before Org is loaded. >> By the way, this does not belong to the same category as other >> defcustoms discussed. This is only tangential to "how does Org should >> look and feel by default". It relates to: should Org provide multiple >> snippet extensions, knowing this is not a central feature, and Org is >> often seen as bloated by Emacs devs? I don't think so, no matter how >> useful this feature can be for some users. > > I'll be more receptive to this argument when animate-birthday-present > is not in Emacs's core anymore :) That's true. But I think they do have a point, though. Also, my question is still open: is there any strong reason to provide, out of the box, two template mechanisms in Org? This is genuine question. In any case, I don't think it is just a matter of personal preference, like defcustoms. There should be some clear design decision behind the answer. Let's un-bundle this issue from the rest of the poll, and think about it separately. > That said, I'm receptive to the idea that Org could be more focused to > its core functionalities. E.g., I think we could be more minimalistic > about the ol-* and ox-* libraries in Org. H. This is another topic. "ox-" are fine, IMO, even though I'm not sure about the health of "ox-odt" these days. "ol-*" libraries make sense as long as the suffix is bundled with Emacs. E.g.,"ol-eww" is fine, but "ol-w3m" could be an external module. A real issue, however, lies within "ob-*". Many of them require libraries external to Emacs. There's a running bug report about it, IIRC. We may not ship them with Emacs. But, again, this is another topic. Regards, -- Nicolas Goaziou
Re: Survey: changing a few default settings for Org 9.4
Hello, Bastien writes: > - Add org-tempo to org-modules > > Last but not least: we had long discussions about this one in the > past. Expansion of the " the beginning of the line has been turned off. I have IRL met with > Org users* who just thought the feature was broken/deleted, without > having/taking the time/knowledge/guts to look for the things they > can turn on. I am all for turning this on again, letting experts > disabling the feature if they don't want it. > > * We have regular meetings with https://www.emacs-doctor.com/ This is not a good default, at least for beginners, because Org provides a better solution out of the box. There are also better solutions outside Org (e.g., Yasnippet). It is only valuable for existing users, who relied on this feature, and don't want to switch. It's perfectly understandable, but it is also fair to assume they can add (require 'org-module) to their own configuration. _Removing_ the module, OTOH, is subtle. By the way, this does not belong to the same category as other defcustoms discussed. This is only tangential to "how does Org should look and feel by default". It relates to: should Org provide multiple snippet extensions, knowing this is not a central feature, and Org is often seen as bloated by Emacs devs? I don't think so, no matter how useful this feature can be for some users. Regards, -- Nicolas Goaziou
Re: Documentation: Side effects of org-entry-properties and others
Hello, D writes: > The same is true for org-element-lineage, but I am not so sure whether > it is intended for hacking purposes as much as org-entry-properties. > Sadly, I have no overview over the scope of this issue, so I do not know > whether my suggestion is unrealistic (for example, because it would mean > adding warnings practically everywhere). I think this is unrealistic. If you need to save match data, execute non-trivial code, and use the saved match data, I suggest to use `save-match-data'. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Bastien writes: > I'm not sure why the distinction between :open and :follow is needed > in the context of the discussion for exporting attachments: is it > because attachment need to be "open", not just followed? The motivation is that the new behaviour for `:follow' is not compatible with the previous one, since the signature changed. So, we have two options: either we write a workaround, as is done for :export (i.e., `condition-case' with `wrong-number-of-arguments'), or we add new keywords so old code still works during transition. Thinking about it, we can stick to a single solution, e.g., the `condition-case' workaround. Therefore we do not need to introduce a new keyword. However, all "ol-" libraries need to be updated. I'll do that instead. Regards, -- Nicolas Goaziou
Re: ox-html: Bug or feature for export of title and meta information?
Hello, Jens Lechtenboerger writes: > Based on the treatment of meta elements for author and description > in that function, alternatives might use org-element-interpret-data > (author) or not (description). I do not understand the role of > org-element-interpret-data to generate author information. `org-element-interpret-data' means: "down with HTML, go back to Org syntax". IOW, it mean the author is supplied as-is. > Which “non exportable objects” can be skipped by that function (as > mentioned in a comment in org-html--build-meta-info)? Should they also > be skipped for description or title? That non-exportable part is confusing. I think (org-element-interpret-data auth) is sufficient. I pushed a change in that direction. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Bastien writes: > FWIW, I'm for delaying the removal for 9.5, not 9.4. Sure, I added it back. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello,
Kyle Meyer writes:
> It looks like a good direction to go.
Thank you for the feedback!
I fixed the various typos you mentioned.
> As far as I can see (by looking at the diff and quickly testing), the
> file+{sys,emacs} functionality is being removed. That's probably
> okay/intended, given that it was marked as deprecated in 9.0. But
> perhaps it's worth mentioning in ORG-NEWS that this functionality has
> now been removed entirely.
Good catch! That is subconscious, actually. I considered removing them,
then hesitated, and it all ended up in an intermediate state. Removing
it properly would require to remove :application property in the parser,
too. At some point, this functionality needs to go, but it is not
necessarily now. I can add it back if needed. Otherwise, I will remove
it completely in a subsequent patch.
Removing this feature may not break existing documents, however. Indeed,
with the suggested tooling, we may simply make "file+sys" and
"file+emacs" aliases for "file" in "org-compat.el". IOW, they would do
nothing more than regular file links, except maybe send an obnoxious
message to the user (linter already does this).
I didn't write the required ORG-NEWS entry because we are not settled on
the final design. I agree all the changes discussed here have to be
mentioned in that file.
Regards,
--
Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Bastien writes: >>> Now, I'm not sure who wants to try implementing Nicolas suggestion to >>> let ox.el expand attachments into file links: since you both know the >>> issue better than I do, I suggest one of you can try? >> >> I will try to propose a patch by tomorrow evening. > > Thanks! > > If things are okay, I'll then have some time on sunday to prepare for > the release on monday. This is the first part of the suggested changes. These do not touch attachment modifications, but rather improve the tooling in "ol.el". In a nutshell: `org-link-parameters' accepts a new property, :open, which is like :follow, but function installed there is called with a universal prefix argument. It could replace :follow altogether, but for compatibility reasons, they both live side by side for the moment. Also, :export function is called with a fourth argument, the export info channel. I updated the export back-ends to handle the new signature, and provided a compatibility layers for link libraries in the wild, which may still use three arguments. There are two new tools: `org-link-open-as-file' and `org-export-link-as-file'. They can be used as helper functions for, respectively, :open and :export functions. WDYT? Regards, -- Nicolas Goaziou >From 59172eb6c5edd5e74a6fd248e975065437bf5072 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Fri, 14 Feb 2020 10:00:15 +0100 Subject: [PATCH 1/2] Extend export tooling in link parameters * lisp/ol.el (org-link-parameters): Allow a fourth "info" argument for `:export' property. Expound docstring. * lisp/ox.el (org-export-custom-protocol-maybe): Accept a fourth optional argument. * lisp/ox-ascii.el (org-ascii--describe-links): (org-ascii-link): * lisp/ox-beamer.el (org-beamer-link): * lisp/ox-html.el (org-html-link): * lisp/ox-latex.el (org-latex-link): * lisp/ox-man.el (org-man-link): * lisp/ox-md.el (org-md-link): * lisp/ox-odt.el (org-odt-link): * lisp/ox-org.el (org-org-link): * lisp/ox-texinfo.el (org-texinfo-link): * contrib/lisp/ox-groff.el (org-groff-link): Provide expected fourth argument. * lisp/ox.el (org-export-link-as-file): New function. * lisp/ol.el (org-link-parameters): Add reference to new function in docstring. * testing/lisp/test-ox.el (test-org-export/link-as-file): Add tests. (test-org-export/custom-protocol-maybe): Update tests. --- contrib/lisp/ox-groff.el | 2 +- lisp/ol.el | 99 ++-- lisp/ox-ascii.el | 4 +- lisp/ox-beamer.el| 2 +- lisp/ox-html.el | 2 +- lisp/ox-latex.el | 2 +- lisp/ox-man.el | 4 +- lisp/ox-md.el| 2 +- lisp/ox-odt.el | 2 +- lisp/ox-org.el | 4 +- lisp/ox-texinfo.el | 2 +- lisp/ox.el | 37 +++ testing/lisp/test-ox.el | 32 +++-- 13 files changed, 146 insertions(+), 48 deletions(-) diff --git a/contrib/lisp/ox-groff.el b/contrib/lisp/ox-groff.el index 9f7d3f11f..9f0a32432 100644 --- a/contrib/lisp/ox-groff.el +++ b/contrib/lisp/ox-groff.el @@ -1248,7 +1248,7 @@ INFO is a plist holding contextual information. See ((string= type "file") (org-export-file-uri raw-path)) (t raw-path (cond - ((org-export-custom-protocol-maybe link desc 'groff)) + ((org-export-custom-protocol-maybe link desc 'groff info)) ;; Image file. (imagep (org-groff-link--inline-image link info)) ;; import groff files diff --git a/lisp/ol.el b/lisp/ol.el index ce53b3e69..f850a5313 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -86,42 +86,93 @@ :group 'org) (defcustom org-link-parameters nil - "An alist of properties that defines all the links in Org mode. + "Alist of properties that defines all the links in Org mode. + The key in each association is a string of the link type. -Subsequent optional elements make up a plist of link properties. +Subsequent optional elements make up a property list for that +type. + +All properties ar optional. However, the most important ones +are, in this order, `:follow', `:export', and `:store', described +below. + +`:follow' + + Function that takes the link path (a string) as an argument and + \"opens\" the link. + +`:export' + + Function that accepts three mandatory arguments : + - the path, as a string, + - the description as a string, or nil, + - the export back-end. + + Optionally, it may accept the export communication channel as + a fourth argument, in case you need using Org Export tooling, + e.g., `org-export-link-as-file'. + + When nil, export for that type of link is delegated to the + back-end. + +`:store' + + Function responsible for storing the link. See the function + `org-store-link-functions' for a description of the expected + arguments.
Re: ox-html: Bug or feature for export of title and meta information?
Hello, Bastien writes: > I see org-export-options-alist is not mentioned in the manual - would > it be worth mentioning it in the "Adding Export Back-ends" section? I don't think so. It is a constant, which may only matter when you write an export-backend. Its value is not even particularly important since any back-end can ignore it. Only its syntax really matters, as pointed out in, e.g., `org-export-define-derived-backend' docstring. To sum it up, I see it is an implementation detail. The manual might, however, be more rigorous about what keywords each back-end really interprets. I don't know how, and where, it could fit, tho. Regards, -- Nicolas Goaziou
Re: ox-html: Bug or feature for export of title and meta information?
Hello, Jens Lechtenboerger writes: > the W3C Markup Validator [1] disagrees with this output from > ox-html (which I reduced to the essential parts): OK. I was talking about the Org syntax. I misread your initial report. I won't comment about the generated HTML. If needed, the HTML exporter can prevent parsing TITLE keyword. Regards, -- Nicolas Goaziou
Re: ox-html: Bug or feature for export of title and meta information?
Completing myself, Nicolas Goaziou writes: > General export rules are described in ox.el (org-export-options-alist), > then each export back-end define its own specificities (look at the > back-end definition). This doesn't mean the manual cannot be improved, of course. Improvements are welcome in that area.
Re: ox-html: Bug or feature for export of title and meta information?
Hello, Jens Lechtenboerger writes: > 1. Export to HTML when the title contains markup, say this one: > > #+TITLE: This does *not* work What does not work? > The HTML title element contains a nested b element, which is > invalid as only text is allowed. Who said that? The above is perfectly valid. > 2. The documentation does not explain which headers are exported how > to HTML. Some keywords have are more important than others, since they have a special meaning during export, e.g., TITLE vs. RANDOM_FOO. General export rules are described in ox.el (org-export-options-alist), then each export back-end define its own specificities (look at the back-end definition). Regards, -- Nicolas Goaziou
Re: Custom image link types in LaTeX
Hello, Bastien writes: > solomon theNinja writes: > >> I'll be happy to implement exporting custom image links myself, given >> time, if that's the issue. > > Sure, please go ahead! If your change is more than 15 lines or so, > you might need to sign the FSF copyright assignment: > > https://orgmode.org/request-assign-future.txt > >> - If it was not clear, in "custom links" I'm referring to links >> defined with `org-link-set-parameters` that have a special export >> behavior. > > Yes, that's what they are for. Note that I need to slightly improve the tooling in "ol.el", so I suggest to wait for these changes, as it might make this feature trivial. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Bastien writes: > Now, I'm not sure who wants to try implementing Nicolas suggestion to > let ox.el expand attachments into file links: since you both know the > issue better than I do, I suggest one of you can try? I will try to propose a patch by tomorrow evening. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Gustav Wikström writes: > What makes attachment links not be a core link type? 1. Org Attach is not loaded by default 2. Implementing Org syntax doesn't require to implement attachments Attachment links are in the same category as Docview links, for example. There is no "docview" occurrence in "org-element.el". We have been there already. > As I see it we have two categories here: Core = those inside Org mode. > Not core = those in external libraries. No other distinction needs to > be made. If a link type is inside Org mode, let it then use the > special properties that Org mode provides. Sure thing, but you use the wrong ones! > Attachment links need to be treated just as file links in most > regards. Since file-links have special logic which attachment links > also needs. Thus a reference to attachment in org-element.el. Nothing > strange here, nothing breaking and the parser is still self-contained. Attachement links should live only in "org-attach.el": like 99% of other links do live in their own library. They do not require a special treatment. Again, the parser is not self-contained if it references org-attach.el. > Maybe time for Bastien to step in. Because I can't remove the > reference to attachment in org-element.el without breaking it's > functionality. Which, btw, was broken before adding the reference in > org-element.el. The thing that started this discussion in the first > place. We're in a better place now. We're not. The way it is implemented is not correct. For opening link, attachment links should use the :follow link parameter. The "following" function can extract the search option, if any, and the file name, then call `org-open-file' appropriately. You're doing it backwards and modify `org-open-file' instead. Additional links are not supposed to modify "ol.el". For exporting link, it should use the :export link parameter. The "exporting" function can extract the search option, if any, and the file name. It can then re-create a file link object, and call `org-export-data' on it. You're also doing it backwards here and prefer to modify each export back-end instead. > Attachment links works as intended. It would be a pity to have to > change that because of your argument that attachment links aren't > "core" enough to be mentioned in org-element.el. I strongly insist that it should be removed. I gave you ways to solve the issue. If you need anything else, let me know, but please consider implementing them.
Re: attachment: link type export to HTML invalid attach dir
Gustav Wikström writes: > Ah, you mean the reference on line 3216. No, I don't think it can be > removed. And I honestly don't think it should be either. It's there to > let attachment links mirror the peculiarities of file links. It's > needed for feature compatibility. I don't see the issue with that. > It's a core link type and it needs the information. That particular > logic doesn't affect the parse tree. It's there only to give > attachment links the same properties as file links. I disagree. This is not a core link type. The issue is that the parser should self-contained. Please use a different way to obtain the information; we already discussed it and suggested multiple solutions.
Re: [Help] Preparing for the release of Org 9.4 tomorrow
Hello, Gustav Wikström writes: > This should be fixed since commit a24c8c481f though, no? > > https://code.orgmode.org/bzg/org-mode/commit/a24c8c481f63113215e66a70382d93cce82c9c7e AFAICT, there still is an "attachment" mark in "org-element.el", at line 3216. Would that be an omission? Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Unless search-option applies as a general construct for all link types > I don't think it should be in the parser. Given the discussion we've > had about design of the parser from before. I.e. if the parser isn't > supposed to know anything about the specific types themselves, all > properties of the parsed elements have to make sense for all types of > links. So either search-option remains but is parsed in exactly the > same way for all link types, or it's not there at all. And if it's not > available in the parser, the file link interpreters (that still might > need to be constructed) gets to parse the :search-option from the > raw-link as it wishes itself. > > Given the above paragraph, the :path and :search-option property > doesn't make sense in the parser. :raw-link is enough. Less ambiguous > names for :path and :search-option would be :file-path > and :file-search-option. But that's sub-typing. We've already > concluded that that should not belong to the parser. I don't have much time, I apologize if I'm not clear. I disagree with you conclusion. Sub-typing is necessary in the parser. The `link' object is complex, so it needs categories or types. There are plain links, angle links, square links. In this last category, there are internal links, which include coderefs, fuzzy links, custom id, file links, and, "links with an explicit scheme part". For each of these categories, it is fine to have specific properties, like search-options. Note that this is sub-typing per syntax, not by meaning. This is what should not move, unless absolutely necessary. For example, attachment links belong to "square links with an explicit 'attachment' scheme part". That is all the parser needs to know. Now, it is true that [[file:...]] links are put in the same category as [[~/...]] links, for practical reasons, i.e., you wouldn't want them to differ in meaning. But this is a breach in the categories above. We might ignore the :search-option part in file links, but it's very easy to get, and, more importantly, we must extract the filename, so further parsing is necessary. > I agree that option 1 is suboptimal. :search-option isn't obvious as > a property for all link types. Since option 3 is fairly trivial, > option 2 isn't necessary either. For attachment links to reuse > the :search-option semantics, without the hard-coding we're currently > doing, I see one option where attachment link higher order functions > could reuse file link higher order functions. Those file link higher > order functions don't exist yet as far as I know. Higher order functions for what? `org-open-file' is such a higher order function for opening file links. There is no higher order function for exporting because each exporter handles file links differently. A higher order function for parsing doesn't mean much, since the consumer is not known yet. At this point, the best thing to do is to clarify what you need. I probably do not understand it. > True that. There is a balance to strike. Maybe it's time to pull in > the org element document into the manual? I vote for that at least. I have no strong opinion on that. It may fit into an appendix, indeed, or even as a section in first appendix: "Hacking", e.g. "Using the Parser API". > Ok, sure. Let the syntax be as rigid as possible, and let > extensibility to that be dealt with in auxiliary parsing/interpreting > functions. I guess that would be the approach, put in different words. > Still correct? It seems correct. > It might be seducing but I'm not sold. I'd rather have an > attachment-link exporter explicitly reuse functionality for exporting > file links than automatic translation. For that to be possible, there > first is a need for a file link exporter function. I don't see how that would be possible, since it would be different for each back-end. Again, do you have a more precise idea about what it would do? > And the current implementation (since the patch) is good enough imo, > for now, and until anyone of us does some file link refactoring. There is an "attachement" reference left in "org-element.el" at the moment. Can it be removed safely? I'm Cc'ing Bastien because that particular point should be solved before any release, IMO. Regards, -- Nicolas Goaziou
Re: [Help] Preparing for the release of Org 9.4 tomorrow
Hello, Bastien writes: > I would like to release Org 9.4 tomorrow, during the "I love Free > Software Day 2020" campaign: https://fsfe.org/campaigns/ilovefs/ > > Can you all (re)submit blocking bugs and issues? Please don't as long as "org-element.el" retain references to attachment links. Regards, -- Nicolas Goaziou
Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link
Hello, Bastien writes: > Nicolas Goaziou writes: > >> How would I dare to have an opinion m'lord? Only yours matters. > > Such sarcastic remarks hurt. Indeed! But I eventually overcame the pain. Thank you for caring! :) Last time we disagreed, you grossly concluded with: Future maintainers may of course interpret the recommendations of the FSF differently, but that's mine for now. As far as my understanding permits, this means: "I'm am the one in charge. I know what I'm doing. Discussion closed. Next." I find this stance dubious, whatever the subject is, or if you are right or wrong. To make my point go through, I'm now pushing it up to the absurd. My intent is to warn, not to hurt. > I may have done something (or worse, many things!) that frustrate you > somehow, but using irony is not a good way to communicate on mailing > lists. I know that is not a good way to communicate. I also believe that lecturing others about communication on mailing lists, or social behaviour in general, is not helpful either. Unless, of course, you think being patronizing is more acceptable here than being ironic. I hope you don't. Regards, -- Nicolas Goaziou
Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link
Hello, Bastien writes: > Nicolas, does it look good to you? How would I dare to have an opinion m'lord? Only yours matters. Christoffer, unfortunately, this patch is incorrect. It doesn't account for a zero :post-blank value. For the record, (1- (org-element-property :end ...)) is always a bad idea. I pushed a fix, with a test. I let you check if the issue is resolved on your side, and close the bug report if appropriate. Thank you for the report. -- Nicolas Goaziou
Re: babel comma escape with :wrap
Hello,
Matt Huszagh writes:
> There appears to be no way to disable the comma escape when using :wrap
> for a babel source block.
>
> I'm essentially trying to replicate this example from the manual
>
> #+NAME: attr_wrap
> #+BEGIN_SRC sh :var data="" :var width="\\textwidth" :results output
>
>echo "#+ATTR_LATEX: :width $width"
>echo "$data"
> #+END_SRC
>
> #+HEADER: :file /tmp/it.png
> #+BEGIN_SRC dot :post attr_wrap(width="5cm", data=*this*) :results drawer
>
>digraph{
>a -> b;
>b -> c;
>c -> a;
>}
> #+end_src
>
> #+RESULTS:
> :RESULTS:
> #+ATTR_LATEX :width 5cm
> [[file:/tmp/it.png]]
> :END:
>
> But, my result type is a link not a drawer (which are mutually
> exclusive). So, to get the same wrapping effect, I need to use the :wrap
> argument. However, the comma escape negates attr_wrap's effect with this
> code
Could you clarify what you obtain, and what is wrong with it?
Thank you!
Regards,
--
Nicolas Goaziou
Re: babel link bug
Hello, Matt Huszagh writes: > - (let ((file (and (member "file" result-params) > -(cdr (assq :file params) > + (let ((file (cdr (assq :file params This patch is wrong, with it, :file parameter alone would imply file result, which is not sufficient. See commit 26ed66b23335eb389f1f2859e409f46f66279e15 "link" format is only meant to be used with "file" output. Regards, -- Nicolas Goaziou
Re: org link to OCaml comment
Hello, Alan Schmitt writes: > Thank you for the explanation. Is there a way to either escape the > parentheses (maybe url-encode them), *shivers* Please never suggest again url-encoding links in Org! ;) We only got out of this hell recently. I don't want to dive in again. > or to automatically not include the closing one as you suggest when > creating the link? There is some specific syntax in links. More specifically, the following are meaningful: - a star at the beginning of the link (or search option) - a hash at the beginning of the link - forward slashes around the link - parenthesis around the link I think that `org-store-link' should be careful about it and prevent these pathological cases if necessary. In any other situation, however, I think the user is responsible for not using these specific constructs. WDYT? Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
chment links into their file link counterpart automatically. >> This would avoid adding specific code in every export back-end. However, >> export back-end would miss the opportunity to handle attachment links >> specifically. This is one way or the other. > > Let's settle with option two for now. As it's defined in the patch. Too bad. I still think that first option is more seducing. Transparently turning attachment links into file links at export time would prevent some headache in exporters out there. It boils down to adding a function that transforms "attach" links into "file" links, e.g., `org-export--expand-attachments', and insert it in `org-export-as', right after (org-export--remove-uninterpreted-data tree info). Regards, -- Nicolas Goaziou
Re: org link to OCaml comment
Hello, Alan Schmitt writes: > The strange part is that linking to arbitrary code works. It seems that > the OCaml comment syntax is problematic here. Link enclosed within parens meant coderef links, i.e., the syntax is reserved. You can probably remove the closing parenthesis to avoid this. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > That was kind of what I was trying to do, by allowing subtyping, so > that the parser would be more knowledgeable about particular types of > links, by allowing extended attributes. Maybe not implemented in the > most extensible way though I'll admit. Just to be clear, I firmly believe Element library should be as low-level as possible. Ideally (we're not there yet), it should not depend on any other part of Org. It should be the step (largely) above "re-search-forward". So, extending the parser to include knowledge to some other library in Org is not an option. Element is expected to dumbly stick to Org syntax, without knowing what it means. > My suggestion to the link parser would be to have the following properties as > the catch-all properties for links: > - type :: Which type of link protocol applies. E.g. file, http, ftp, > attachment, duckduckgo (ex. for a custom link abbreviation to search ddg) > - raw-path :: The path to use for the particular protocol. Would contain > everything in the link following "protocol:" > - format :: Which format the link has. Plain, bracket or angular bracket Barring custom link abbreviations, this is already the case. > - description :: The description part of the link > ([[protocol:path][description]]) Description is not meaningful here. This is parsed content. > - begin, end, post-blank :: The default properties used for all elements. Not > sure if contents-begin and contents-end are a part here as well. They are when the link has contents, i.e., a description. > As you've stated previously, from a performance perspective maybe it > will be best to not expand the specific properties and instead let the > expansion of those be handled in code by the link type owner (e.g. > org-attach.el for attachment links). More than performance, this is a design issue. > Ah yes. Just briefly looking at the docview code. Docview doesn't seem > to use the parser when extracting information about that "go to page" > information from the link. Which means docview links doesn't really > care how the link information is encoded in the parser anyways. Indeed. However, higher level functions, e.g., org-open-link, do care about it and ensure that "ol-docview.el" really processes a link. > Maybe if docview were allowed to encode custom docview information > into the parsed link in the parser it and others could reused that > encoded information later? Docview would be able to add > a ":go-to-page" option, for example. Just a thought. I'm quite sure this is a wrong way to go. > Most link types probably won't need custom link properties anyways. > But could maybe let the parser know stuff by use of higher order > functions? Or push for being important enough to be included into Org > and allowed to be known by the parser. Only syntax changes can go into the parser. Attachment links are regular links, not something that requires extending Org's syntax. Note that this is not the case of file links, which have a special syntax, e.g., [[./cat.jpg]]. > Ok, got it. Thanks for explaining. I'll admit it hasn't been totally > clear to me what the best way forward is. After refreshing my > understanding on links the conclusion I came to was that link > abbreviations in its current form was not a fitting concept for > attachment links. Attachments are pretty much similar to file links > though, so even if my intention isn't to blur the meaning they will > and should be treated very similar, since functionality is so similar. Functionality may be familiar, but their syntax is not the same, therefore, the differences should be handled elsewhere. > Speaking from the perspective of attachment links, if there were > a file link type exporter function available that could be used by > attachment links without code duplication. Where would live that function? ox.el is not an option since every exporter treats file links differently. As suggested already (I think) we could add a phase in ox.el that would expand attachment links into their file link counterpart automatically. This would avoid adding specific code in every export back-end. However, export back-end would miss the opportunity to handle attachment links specifically. This is one way or the other. > Yes, and the function that implements that would also need the user > argument as input. In addition to the link path. Patch welcome. I see no objection to extending :follow link parameter in "ol.el". > Anyways, patch attached that makes org-element not know about > attachments any longer, and moves most of the responsibility to > org-attach.el. The exporters still needs to know to use the new > function inside org-attach.el though. Thank you. Please apply it. Now we can try improving the situation for exporters. Regards, -- Nicolas Goaziou
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes: > Thanks for the clarification. I was not sure if it is intended. > I was mislead about this 2 times because of docstring, though it is > clear from the source code. I fixed the docstring. Thank you. >> Luckily, headlines are exactly where you do _not_ need Element library. >> `org-back-to-heading' and `org-up-heading-safe' will always be faster, >> and as accurate. I.e., the code operating on headlines is usually >> distinct from the code handling other elements. > > Well. `org-back-to-heading` + `org-up-heading-safe` take more than 15% of > my agenda generation time (I have really huge number of headings + > multiple custom skip functions). I was hoping to use cache for speed > up. Cache will not help you here. `org-up-heading-safe' and `org-back-to-heading' are faster than `org-element-at-point' + cache. Moreover, custom skip functions are a pain. They prevent any form of caching during agenda creation. IMO, Agenda (or its re-implementation) should do without them. >> You can parse the full document and get all the :parent properties >> filled. That's not the job for `org-element-at-point'. > > I once tried to do exactly this, but I did not manage to figure out how > to obtain element at point from full parse tree (from inside an agenda > skip function). Is it possible? It is possible but not implemented. >> Note that `org-element-cache' was disabled a while ago because it could >> introduce freezes. I think this is related to how this part handles >> `before-change-functions' and `after-change-functions'. Anyway, YMMV. > > I see... I don't know how useful the cache is except my idea about > using cache to speed up agenda. But I was stuck with the :parent > property issue and did not play much further since that time. I once started to implement Agenda-specific caching, but stopped as it would have entailed rewriting much of the Agenda code. It would have been a pain. Even switching "org-agenda.el" to lexical binding is difficult (and isn't done yet). Some re-implementation of Agenda (e.g., org-super-agenda + org-ql) may be better wrt caching.
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hello, Ihor Radchenko writes: >> Probably the docstring needs to be adapted - Nicolas knows this area >> better than me. > > Do you mean that :parent property may not always be present? `org-element-at-point' returns only a partial parse tree. It never goes higher than the current top-level element, i.e., from an element, you cannot go up to the headline just following :parent. Luckily, headlines are exactly where you do _not_ need Element library. `org-back-to-heading' and `org-up-heading-safe' will always be faster, and as accurate. I.e., the code operating on headlines is usually distinct from the code handling other elements. > If so, it is quite disappointing. It would be helpful to be able to find > parent of any element at point (especially, in conjunction with > org-element-cache). At least, optionally. You can parse the full document and get all the :parent properties filled. That's not the job for `org-element-at-point'. > I was counting on this feature to try speeding up my agenda generation > (using org-element-cache). Note that `org-element-cache' was disabled a while ago because it could introduce freezes. I think this is related to how this part handles `before-change-functions' and `after-change-functions'. Anyway, YMMV. Regards, -- Nicolas Goaziou
Re: getting item information in an export filter?
Hello, John Kitchin writes: > In > https://emacs.stackexchange.com/questions/55231/org-mode-export-html-add-name-attirbute-to-checkbox-input > > there was a question about modifying a checkbox export. I wrote an answer > using a custom translate function in a derived backend, where I could get > the name of the parent list pretty easily. > > It seems like that should also be possible in a filter, but I don't > understand how to find the parent list in that case. I think it is buried > in the info. > > Is there a general way to get to the org-element information for something > in an export filter function? No, there's no simple way to access the element. Filters, with a few exceptions, are meant to operate on strings, not on the parse tree. They are usual meant as a simple way to transform the output. I.e., they are intentionally dumbed down. You could however, use the parse-tree filter to modify the parse tree before export. Regards, -- Nicolas Goaziou
Re: Strangely recognized non-lists and non-headers.
D writes: > On 02.02.20 12:59, Nicolas Goaziou wrote: >> Long story short. Don't use this function, it is not correctly >> implemented at the moment. The correct way to check if you're in a list >> is something like: >> >> (org-element-lineage (org-element-at-point) '(plain-list) t) > > I tried that out, but it still seems to recognize source code as > headlines, replacing the predicate does not change the behavior. Of course. You cannot have headlines within a source block. You need to escape them with commas. I'm just pointing out that the code above is the right way to check if you're in a list.
Re: Strangely recognized non-lists and non-headers.
Hello, D writes: > I use org-list-in-valid-context-p as a quick hack to check if what I am > looking at is actually a list. Long story short. Don't use this function, it is not correctly implemented at the moment. The correct way to check if you're in a list is something like: (org-element-lineage (org-element-at-point) '(plain-list) t) Regards, -- Nicolas Goaziou
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Bastien writes: > Future maintainers may of course interpret the recommendations of > the FSF differently, but that's mine for now. Of course, sir.
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Bastien writes: > My point is that distinguishing trivial vs. non-trivial parts of a > change may be subject to interpretation. When in doubt, I recommend > staying on the safe side of not accepting a change that is more than > 15 lines of "maybe-significant" changes. AFACT, there was no doubt involved when I said "15 lines of non-trivial code". > Yes, in this case there is no new idea, but this is irrelevant to the > discussion, I thought we had a discussion about it recently, but my memories may be brittle. > since ideas cannot be copyrighted anyway. I knew I shouldn't have used this word. Fair enough. Replace it with "process", or whatever has a copyright meaning. > Well, I hope I clarified my point, which is to stay on safe side of > asking contributors to sign the FSF papers when the importance of the > change can be subject to intepretation. If your point (I didn't get it actually) is "interpretation is hard, let's not interpret anything and count everything as significant", well, I think this is not a good way to look at the problem. But that's fine, as long as it suits you. Regards,
Re: org-mode functional programming library
Hello, "Dwarshuis, Nathan J" writes: > I recently authored an package called "om.el" which is a functional > org-mode API akin to dash.el primarily using org-element. Briefly, it > provides a library of (mostly) pure functions that manipulate the > parse tree generated by org-element.el, and uses this to either edit > or query the buffer with all the advantages of functional programming > (eg lack of side effects, referential transparency, easier testing, > etc). The github repo for om.el is here: > https://github.com/ndwarshuis/om.el. > > I'm posting to the mailing list a) for general feedback on this > package and b) because I am wondering if this would be a good package > to include with org-mode itself rather than in another repository such > as MELPA. The code for om.el is tightly integrated with org-element.el > and it might make sense for development between these to be closely > intertwined. Thank you for this thorough work. Note that code going into Org proper cannot rely on external libraries, e.g., "s.el" or "dash.el". So it may make sense to integrate it, but not in its current form. Is it possible to write it without these libraries, and without re-inventing the wheel? Note that, at some point, Org will support "seq.el", i.e., when we drop support for Emacs 24. Skimming through your code, I read a lot of griefs against Element library (inconvenient, unfortunate, buggy, inconsistent... I stopped there). I agree on most points, of course. Though, there are a few cases where you seem to miss the point. Also, the way you handle plain lists is not how it is done in Org. Anyway, it could be beneficial for both Org and your library to discuss the points above and improve the parser. WDYT? I didn't check, but how do you alter the buffer when applying changes to the parse tree? Is it optimized, e.g., only changed lines are replaced? Or are you deleting the whole thing and replacing it with the interpreted stuff? Note that Org has hardly ever access to the full parse-tree, because parsing a whole buffer is too slow. So, because of these limitations, I wonder if your library can be used efficiently to alter the buffer. Regards, -- Nicolas Goaziou
Re: Displaying remote images
Hello, Jack Kamm writes: > Thank you for reviewing my patch. I'm attaching an updated patch in > response to your review. Applied. Thank you. I also simplified the allowed symbols for the new variable a bit, and added a docstring for the internal function. Regards, -- Nicolas Goaziou
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Hello, Bastien writes: > Nicolas Goaziou writes: > >> TINYCHANGE is only about the number of non-trivial lines of code in >> your patch (15 or so). > > I would not say "non-trivial lines" of code. > > The change should be less *than 15 lines or so* to be accepted. > > I may be wrong, but this is how I read this: > https://www.gnu.org/prep/maintain/maintain.html I disagree. As stated in this page, only lines of code significant copyright-wise count. Commenting a line of code, changing indentation (e.g., when you wrap a `let') do not count. You cannot copyright an indentation change. Nor a symbol renaming (this example is even given in the page above). Also, applying the same change multiple times may count /at most/ once. So, I stand on my ground: there is a "non-trivial" part to take into consideration when counting locs. I would go even further: when you transform a string regexp into a rx regexp, there is no line to count, because there is no new idea to copyright in the first place. This is a trivial change. Anyway, I think arguing here is just wasting our time. Regards, -- Nicolas Goaziou
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Hello, Dan Drake writes: > Thank you, Nicolas, for the review of my first patch. I've updated my code > and have the new patch attached. Thank you! > I didn't inline the "time to minutes to keep function"; yes, that function > is very short, but the function name makes the intent/purpose of the code > obvious, and the org-clock-resolve a bit more readable. If it's important > to inline that -- performance concerns about the function call overhead, > accepting org-mode/emacs coding style, etc. -- I'm willing to do that. If you think it makes the code more readable, which is debatable IMO, one option is to simply add a comment where it is going to be inlined. It is not about speed or Org coding style, but generally speaking, defining a global function out of a one-liner, just to use it once, does not sound reasonable. You may define it in a `let' within the function, but I'm still confident that a comment and plain inlining is more than enough. > I added an entry to ORG-NEWS for version 9.4. Great! > I didn't write any tests, as the change seems so simple, and UI-focused. > But again, if that's a dealbreaker, I can work on doing that. It's certainly not a deal breaker in this case, but a regression test more or less guarantees a future code refactoring will not unwillingly break your feature. Test can come later, or even never, that's your call. No worries. Regards, -- Nicolas Goaziou
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Hello, Dan Drake writes: > I asked about a way to specify a time when using org-resolve-clock instead > of a number of minutes: > > https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00010.html > > I've implemented this myself and a patch is attached. Comments welcome -- > my change works, but I'm not sure about coding style, and right now there's > no error checking. Thank you. Some comments follow. > I marked the patch as a tiny change, but it does add a new menu option and > behavior to org-resolve-clock, so there may be an argument that it's not, > from a user perspective, a "tiny change", but code-wise it's quite simple: > the core logic really isn't more than "ask the user for a time and > subtract". TINYCHANGE is only about the number of non-trivial lines of code in your patch (15 or so). > +(defun time-to-mins-to-keep (start-time) > + "Asks the user for a time and returns the number of minutes > +from START-TIME to that time." > + (floor (/ (float-time > + (time-subtract (org-read-date t t) start-time)) 60))) The name of the function is wrong, it should start with "org-clock". Also, docstring's first line must contain a full sentence. Anyway, this is used only once in your patch, I suggest to inline in instead. > + (or (and (memq ch '(?k ?K)) > +(read-number "Keep how many minutes? " default)) > + (and (memq ch '(?t ?T)) > + (time-to-mins-to-keep last-valid See above about inlining. Would you mind adding an ORG-NEWS entry, and, if possible, writing a test? Regards, -- Nicolas Goaziou
Re: [Question] adding document global properties drawer
Hello, stardiviner writes: > I found I can add property with name input name like "kk", "hello" etc, but > can't add property "CATEGORY". Is there some limitation on document level > property? I still cannot reproduce it. Regards, -- Nicolas Goaziou
Re: org-contrib: Taskjuggler effort calculated via org instead of TJ3?
Hello, Benjamin Kästner writes: > On version 9.3 (9.3-elpaplus @ > $HOME/.emacs.d/elpa/org-plus-contrib-20191203/), `ox-taskjuggler' > exports the :Effort: property calculated via > `org-duration-to-minutes', e.g. 2d get exported as 48.0h instead of > the literal 2d. > > This is unexpected and makes the Taskjuggler export unusable for me in > the current form. Is there a rationale for this? I don't know. I removed the transformation. Thank you for the report. Regards, -- Nicolas Goaziou
Re: Asymptote figure in footnote
Hello, Jarmo Hurri writes: > Do you have an idea of how to control the size of the pic in the > footnote? The default is .9\linewidth. I figured a workaround (below), > but would prefer the structure above. I don't know how to do that in an inline footnote, but, in this case, I would certainly use a regular footnote containing an Asymptote source block. Regards, -- Nicolas Goaziou
Re: [Question] adding document global properties drawer
Hello, stardiviner writes: > In an *empty* Org file buffer, I press =[C-c C-x p]= to add properties > drawer. It > works fine. But when the Org buffer has nodes already like this: > > #+begin_src org > | > > ,* node 1 > > context > #+end_src > > The "|" means the cursor point. > > Then I press =[C-c C-x p]= again try to add document global properties > drawer, It > insert nothing. No modification on buffer at all. Is this a bug? FWIW, I could not reproduce it. Regards, -- Nicolas Goaziou
Re: Displaying remote images
Hello,
Jack Kamm writes:
> Apologies for the delay on this. I've now got a more complete patch for
> displaying remote images inline. Since downloading many remote images
> could potentially hang Emacs on a slow connection, I've added an option
> to control whether remote images are displayed. I've also added an
> option to cache the remote images by visiting them in Emacs buffers.
Thank you.
> The default behavior is not to display remote images, but to issue a
> message that references the option that controls remote image display.
I think displaying a message in this case can be annoying. It means the
default value is not satisfying for anyone.
> +(defcustom org-display-remote-inline-images 'skip-warn
> + "How to display remote inline images.
> +Possible values of this option are:
> +
> +skip-warn Don't display, and emit a message about it.
> +skip-silent Don't display, and don't warn about it.
> +download-always Always download and display remote images.
> +cache-in-buffer Display remote images, and open them in separate buffers
> for
> + cache'ing. Silently update the image buffer when a file
> + change is detected."
> + :type '(choice
> + (const skip-warn)
> + (const skip-silent)
> + (const download-always)
> + (const cache-in-buffers))
> + :group 'org-appearance)
I suggest to drop the `skip-warn' value altogether, and use
`skip-silent', renamed as `skip', as the default value.
It also needs a :package-version and a :safe keyword.
> +(defun org-inline-image--buffer-unibyte ()
> + (string-make-unibyte (buffer-substring-no-properties
> + (point-min) (point-max
I'm surprised such a function is necessary. In any case, it should be
named `org--inline-image-buffer-unibyte'.
> +(defun org-inline-image--create (file width)
It should be named `org--inline-image-create' or
`org--create-inline-image'.
> + (let* ((remote-p (file-remote-p file))
> + (file-or-data
> + (if remote-p
I suggest to move the `if' within the `pcase' with an initial `guard'.
> + (pcase org-display-remote-inline-images
> + (`download-always (with-temp-buffer (insert-file-contents file)
> +
> (org-inline-image--buffer-unibyte)))
Wouldn't `insert-file-contents-literally' fit the bill instead?
> + (`cache-in-buffers (let ((revert-without-query '(".*")))
> + (with-current-buffer
> + (find-file-noselect file)
> +(org-inline-image--buffer-unibyte
Wouldn't the RAW argument from `find-file-noselect' prevent
`org-inline-image--buffer-unibyte' from being used?
> + (`skip-warn (message
> + (concat "Set `org-display-remote-inline-images'"
> + " to display remote images."))
Use continuation delimiter instead.
> + nil)
> + (`skip-silent nil)
> + (_ (message (concat "Invalid value of "
> + "`org-display-remote-inline-images'"))
Ditto.
Regards,
--
Nicolas Goaziou
Re: Asymptote figure in footnote
Hello,
Jarmo Hurri writes:
> This has to be a borderline case, but I need some Asympote-generated
> figures in footnotes. The following does not seem to work.
>
> [fn:: src_asy[:filename foo.pdf]{size(8cm,0); draw (unitcircle);}]
The following works here:
[fn:: src_asymptote[:file foo.pdf]{size(8cm,0); draw (unitcircle);}]
Regards,
--
Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Gustav Wikström writes: > Ok, noted. To my defense I was thinking more in the terms of subtyping > then hardcoding. Because we have multiple link types which try to > share an interface. But the interface isn't perfect for all different > kinds of links. Then, I suggest to improve the interface. > So it doesn't seem too farfetched that some of those link types would > benefit from additional custom properties, specific for those types. > =application= and =search-option= for example isn't universally > applicable to all link types. As a side note, :application is on its way out, i.e., "file+emacs" stuff is in "org-compat.el". Also, IIRC, "docview" links have "go to page" option, and they don't touch the parser. > What I'm trying to argue for here is: Maybe it's not that crazy after > all to allow links to have additional properties in the parser based > on its type? (While certainly still trying to avoid it if possible!) If new link types may not function correctly without touching the parser, how do you create new link types out of Org's core? This is not modular at all. > (Off topic) I'm sorry to hear that you think I'm intentionally making > things fuzzy. Not at all! My wording is terrible. When I wrote Also, you sometimes seem to blur, on purpose, the difference between "attachment" and "file" links. I meant something like: It seems to me that your intent is to have "attachment" links transparently become "file" links to the user. Hence my suggestion to use link abbreviations. There's nothing negative in it. > One can indeed use the buffer position to derive the part of the path > that comes from the subtree. But leaving it at that puts more > requirements on the user of the parsed link in order to use it. And higher order functions in "org-attach" could take care of it. Note that expanding a link in the parser means all attachment links are always expanded, even if they are not used. There's a cost to consider. Besides, parser focus on the contents of the buffer. I think it is out of its scope to infer file names for abbreviation links. It's more the job of the parts consuming the parsed data. > There is no :raw-path available in the properties for a parsed link. > If there were we surely wouldn't have this conversation and I'd be > using that already! :) I meant :raw-link, sorry. > I.e. I like this suggestion. I considered using the :raw-link > property, but the way it's currently used by the parser (i.e. > expanding abbreviations) stopped me. Please take how link abbreviations are handled in the parser out of the equation. I already stated this is not a good way to handle them. We should probably expand them in a "temp-link" variable, and parse it, while keeping original link in :raw-link (barring white spaces fixes). That would not be perfect either, because we would still be inferring stuff. That's another topic, really. Let's just ignore it for now. > So, we're discussing regarding attachment as either: an abbreviation > or a proper separate link type? I'm not sure what other options we > have? I personally can't categorize it as an abbreviation since that > is handled by a separate piece of code with other specifications. I.e. > attachment wouldn't fit well inside org-link-abbrev-alist. What makes you think it wouldn't fit well? > Attachments should function in the same way as file links, with search > options and all. But be limited to the current set of attached files. This isn't incompatible with the above, AFAICT. > That's basically the way it was before the patches to fix stardiviners > issues. Except not functioning well enough. It would require quite > some code in org-attach to replicate existing file links > functionality. Mostly code duplication I presume. I didn't read stardiviner issues. Would you mind summarizing them? Or, at least could you explain what is not functioning well enough? Anyhow, you may have missed the "let's spot the needs and improve these tools" part. If current tools lead to code duplication, we can fix that. > The raw-path option sounds better to my ears. Except I was meaning :raw-link :) > One improvement I can think of (outside of the discussion above) is to > make it possible to pass the argument to org-link-open along to each > separate link type specialization. Isn't that the job of :follow when defining a new link type? > That one has bugged me for some time now, when I've wanted to force > opening attachment links in emacs but couldn't. IMO, forcing users to open stuff in a specific, non-configurable, way is a bad idea. Why would we know better than them?
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Functionally it's in a good (and maintainable) state right now, in my > opinion. But I do understand that the contextual attribute added to > the parser may require some discussion. This is not my main gripe here, although I'm not convinced that extra attribute is warranted. My concern is that you hard-code "attachment" type in the parser. I don't think this is the correct way to handle the situation. Some link types specifically handle files, e.g., "docview", yet do not need a special treatment in the parser. Note that "file" links have a good reason to be treated specially there, besides their obvious importance, as their type can be omitted. E.g., [[~/file.org]]. OTOH, I see no strong reason to handle "attachments" in here, since they behave like any other link type. Worse, the parser is more or less the definition of the Org syntax. Therefore, including "attachment" in the parser is a signal meaning that in order to fully implement Org syntax, e.g., in another language, one need to support attachment links. Attachment links are undoubtedly useful, but they are not core, at all. So, I feel uneasy about leaking that type of link in the Element library. Also, you sometimes seem to blur, on purpose, the difference between "attachment" and "file" links. If there should be no difference of treatment between them, as I already suggested, you may want to consider "attachment" as some functional link abbreviation. Then the "attachment" type doesn't really exist, much like the "bugzilla" link type from the manual. In any case, we need a proper definition, a proper category too, for "attachment" links. Meanwhile, modifying the parser is just grasping at straws. > I argue that the attachment folder is a part of the attachment link, > even though the information is found at a different location in the > document (i.e. as a property to nodes in the document hierarchy). > Parsing an attachment link would then be incomplete if that > information is discarded. I argue that the buffer position of the attachment link and the path as written in the link are enough to fully expand the attachment file name. If I'm wrong, which could be, I probably didn't invest enough time in the Attach changes, then having the expanded form in :path and the initial form in :raw-path is enough. > One option to adding an attribute could be to modify existing > properties by adding the attachment folder to, for example, the path > property. But that means to remove information about what was written > as path in the original link. There is :raw-path for that purpose. > So I argue to keep path as the original path. But that means extra > information is needed to also make it work in the filesystem. If we > would translate an attachment link to a file link in ox.el that means > we remove the option for exporters to decide for themselves what to do > with the link. And I think the exporter should have that option. :) Let's first think about what category of object an attachment link belongs to. Then we can discuss about how to export it. Again, if "attachment" == "file", the exporters shouldn't treat them differently. If "attachment" is a new link type, it should define its own rules in its own library, namely "org-attach.el". > Right now the ASCII exporter for example outputs attachment links as > attachment:expanded_path instead of file:expanded_path. Since the link > type actually is attachment. And for a solemnly textual export the > exported information should be kept as close to source as possible. So > either we explicitly and always say attachment-links *are* file-links > in disguise (i.e. even change type in the parser), or we don't say > that, and then don't say that all the way to the edge of the system. > And let the uses of the link type decide themselves what to do. Which > is what I propose. As I explained above, your proposal is not crystal clear. My gut feeling is that "attachment" links are just a regular link type, that can be opened, and exported, like "file" links. They should live in "org-attach.el", using the provided tools to define new link types, like almost every other link types do. If those tools are not enough to express all the subtleties of "attachment" links, then let's spot the needs and improve those tools. That will benefit to every developer that wants to implement a new link type, what creating another corner case in the parser cannot do. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Ok, so change pushed... I'm sorry, but this is going too fast. We're discussing core design here (the parser), and I couldn't even answer your proposal. Let's at least reach an agreement on the change to make. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Gustav Wikström writes: > Hardcoding the translation of attachment-links into file-links in an > in-between layer (ox.el - that is somewhat complicated as well) is not > transparent and I think best to avoid. Even if an attachment link is > /very/ similar to a file link it may be best still to treat them for > what they are. If some export back-ends out in the wild don't work > with attachment-links today then so be it. But let's at least make it > easy to fix! So I'll try to remove the hard coding of org-attach > invocation and instead make the attachment-path when parsed by > org-element return a path that is an actual file-system path out of > the box. I'll see what I figure out in terms of code I suppose...! > > What do you say? It is true that Element library expands link abbreviations right before parsing a link, and an attachment is similar to a local link abbreviation. This is not great because some information is lost in the process: interpreting the parse tree will not bring the abbreviation back, only its expanded form. Actually, `org-link-expand-abbrev' is called so that the parser knows what is the true type of the link, since abbreviations could expand to anything. OTOH, attachments can only expand to a "file" link, so the motivation for expansion doesn't hold. Besides, there's no good reason to store redundant, or even remote, information in the parse tree. The parser needs to be as low level as possible. Moreover, the issue encountered here is specific to export, so it makes sense to solve at the export level, i.e., in "ox.el". This is not trivial though, as it needs to be done very early, much link footnotes. Indeed, since the meaning of the link is position dependent, including parts of a document, or executing arbitrary code can mess it up. IOW expansion should happen in `org-export--prepare-file-contents', i.e., within every included piece of text, and in `org-export-as', somewhere after `org-export-expand-include-keyword' call, but before Babel code execution. HTH, Regards,
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Ah yes. Found the culprit for this issue. Hopefully the last one. The > exporter doesn't actually move the point in the buffer during the > export. So org-attach-expand tried to expand from the first character > in the buffer. This should be fixed from a few minutes ago. I'm not sure hard-coding attachment links in exporters in the best way forward. For example, exporters in the wild may not cope with them before a long time, if ever. There is some code duplication, too. If attachments links are similar to file links from an export point of view, then I suggest to add a phase in ox.el to expand the former into the latter, before even using export back-ends. This way, there is no change required in the exporters, shipped in or not. Regards, -- Nicolas Goaziou
Re: (setq org-hide-emphasis-markers t) + markup + lists + Visible only = blank list items
Hello,
Michael Dixon writes:
> I’m running Org 9.3.1 and Emacs 27.0.60, which I compile myself.
>
> I discovered that if I have (setq org-hide-emphasis-markers t) in my
> config, and I create an ordered or unordered list where there are list
> items only containing marked up text, and then I export Visible only
> (C-v), those list items export as blank lines (other than the bullet
> or number).
>
> For example, if I have an org file with the following:
>
> * Heading
> This is some text. And following is a list.
> 1. ~with code~
> 2. some text ~with code~
> 3. some text
>
> And back to a new paragraph
>
> It will export to LaTeX/PDF as:
> Heading
> This is some text. And following is a list.
>
> some text with code
> some text
> And back to a new paragraph
> If I look at the LaTeX source that was exported for the list, this is what it
> looks like:
> \begin{enumerate}
> \item
> \item some text \texttt{with code}
> \item some text
> \end{enumerate}
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: ol-notmuch.el first line, incorrect filename: org-notmuch.el
Hello, Duianto - writes: > Problem: > The first line of `ol-notmuch.el` shows the filename as: `org-notmuch.el` > https://code.orgmode.org/bzg/org-mode/src/3a6061e787efc9793ce1b7445a1f2502f679b40e/contrib/lisp/ol-notmuch.el#L1 Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: Bug: refiling gobbles a newline and absorbs the next heading [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Hello, Miguel Morin writes: > It's interesting that you are unable to reproduce the result. I have > Emacs 26.3 (9.0) on macOS Mojave 10.14.6. I have reproduced it with > `emacs -q`, so the problem is not my init file. Then I don't know what > the culprit is and am curious and available to try things to find it. OK. I can reproduce it. Actually, this is a _visual_ problem, the document is not mangled at all. If you do S-TAB on the document you will notice that everything is at the right place. I'm not saying there is no bug, but it is much less bad than I thought. I have no clue about the reason for this. Regards, -- Nicolas Goaziou
Re: [PATCH] org-manual: Use ol-man.el in "Adding Hyperlink Types"
Hello, Tom Gillespie writes: > This is a tiny change to the manual to account for the change from org > -> ol in the org-man example. There may be other references in the > manual that have similar issues but I did not check. Applied. Thank you. > TINYCHANGE I removed this since you have signed FSF papers. Regards, -- Nicolas Goaziou
Re: Bug: refiling gobbles a newline and absorbs the next heading [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Hello,
Miguel Morin writes:
> I put "refiling" in the title as that is the moment when things go awry, so I
> noticed it when I refiled items.
>
> I updated Org to 9.3.1 and confirm that the bug is still present. Because I
> got some compatibility problems, I tested it with `emacs -q`, in which I
> didn't have email, and then drafted the email after reverting to the built-in
> 9.1.9.
>
> Below is the relevant part to reproduce the bug. What do you mean by
> ECM? Error Correction Mode? Engineering Change Management?
Complete Minimal Example, using French wording order, which is more or
less what you did provide.
> Start a file at `~/test.org` with:
>
> ```
> * heading 1
>
> * heading 2
>
> * heading 3
> ```
>
> Set this capture template:
>
> ```
> (setq org-capture-templates
> '(("t" "Todo" entry (file+headline "~/test.org" "heading 1")
>"* TODO %?\n")))
> ```
>
> add a capture item, delete newlines from the end of the org-capture buffer,
> and refile to "heading 3". The heading next to the refiled item is gobbled
> and both the org-capture item and the gobbled "heading 2" move to "heading 3".
>
> [![Empty lines method, step 1 - create an org-capture item][1]][1]
>
> [![Empty lines method, step 2 - delete lines from end of org-capture
> buffer][2]][2]
>
> [![Empty lines method, step 3 - refile][3]][3]
>
> [1]: https://i.stack.imgur.com/6cUlo.png
> [2]: https://i.stack.imgur.com/GPwg8.png
> [3]: https://i.stack.imgur.com/tzAJI.png
FWIW, I cannot reproduce it with your recipe. Maybe someone else could.
Regards,
--
Nicolas Goaziou
Re: Bug: org-babel-expand-noweb-references is very slow [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
Hello,
Vladimir Nikishkin writes:
> I am attaching the file in which tangling is still slow.
>
> The file is quite big, but that alone doesn't seem to be the reason
> for slowliness (I tried adding 1M-long words in the random places of
> the previous mwe).
>
> You can see the result by C-c C-v C-v'ing the code block at the
> "Ramanujan numbers" heading.
>
> Below is the profiler report for C-c C-v C-v'ing.with the heaviest
> blocks expanded:
This is because you're using :noweb-ref, which _is_ slow, although you
apparently don't need it in the document. Use name keyword instead,
e.g.,
#+name: primetest
#+begin_src scheme :exports both :results output
(define (smallest-divisor n)
(find-divisor n 2))
(define (find-divisor n test-divisor)
(cond ((> (square test-divisor) n) n)
((divides? test-divisor n) test-divisor)
(else (find-divisor n (+ test-divisor 1)
(define (divides? a b) (= (remainder b a) 0))
(define (prime? n)
(= n (smallest-divisor n)))
#+end_src
Regards,
--
Nicolas Goaziou
Re: Format of Effort estimates should be mentioned in its Info node
Hello, Jean-Christophe Helary writes: >> On Jan 4, 2020, at 14:20, Kisaragi Hiu wrote: >> >> It didn't work for me because I gave it "10m" which actually means 10 >> months, I've realized. >> >> Still, Durations as defined by org-duration.el should be described in the >> manual like how Timestamps are. > > This does look like a potential contribution to the package. I'm not sure would be pertinent to create a whole section for duration format: these are not quite as ubiquitous as timestamps. However, they are used here and there so it may be better to add a few words in the appropriate sections, the main one being obviously "Effort Estimates". Anyway, patches welcome! :) Regards, -- Nicolas Goaziou
