Re: org-cycle-internal-local unfold a plain list in parent
Hi Yasushi, Yasushi SHOJI writes: > I see a plain list unfolded when I cycle a sub headline. Fixed in maint with commit 5021bada9, thanks again for reporting this. -- Bastien
Re: Bug: Babel+R handles spaces wrongly in tables [9.3.6 (release_9.3.6 @ /home/cassou/.emacs.d/lib/org/lisp/)]
Hi Damien and Jeremie, Jeremie Juste writes: > The following patch will at least harmonize the results towards the > data.frame. I see the patch has been applied - thanks! I'm marking this bug as resolved right now, feel free to reopen it if I'm wrong. Thanks, -- Bastien
Re: Bug: org-table-wrap-region incorrectly places the wrapped region [9.4 (9.4-elpaplus @ /home/marko/.emacs.d/elpa/org-plus-contrib-20200914/)]
Hi Marko, Marko Schuetz-Schmuck writes: > Marking the region from the 'I' of "Includes" to the space just left of > the right bottom column border and calling org-table-wrap-region > > | Includes all aspects of| > | information about | > | proposed project. | > > wraps correctly to > > | Includes all aspects | > | of information about | > | proposed project.| > > But when I mark the same region in this table > > || > | Includes all aspects of| > | information about | > | proposed project. | > > it results in an error message "Not in table data field". Fixed in maint with commit eedbe286e, thanks again for reporting this. -- Bastien
Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi Bastien, On Sat, 01 May 2021 at 13:02, Bastien wrote: Hi Gustavo, Gustavo Barros writes: I just found a misbehaving of `org-insert-heading-respect-content': when it's called before the first heading in the buffer, it breaks the structure of that fist heading by inserting a new heading on the line the previous heading existed. Fixed with commit fb3030188 in the maint branch, thanks a lot. Please test it and report any problem you may encounter. Thank you very much. I just tested the fix and, indeed, `org-insert-heading-respect-content' no longer breaks the structure of the first heading. However, if I may add a nitpick, the value of `org-blank-before-new-entry' does not seem to be honored in this case. For default values, a distance of one blank line is ensured to the next heading. In the report's ECM, after the fix, the new heading is inserted immediately before it. (I'm not sure it is really `org-blank-before-new-entry' which is at play here, but the behavior is not the same before the first heading than it is after it, with respect to blank lines). Best, Gustavo.
Re: [PATCH] Possibility of using alternative separators in macros
Hi all,
Thanks for your comments, Bastien and Nicolas.
I think macros can work out of the box as a perfect 'backend' for those
LaTeX commands that include at least one argument with textual content.
In my case they are very useful to 'extend' the markup language. Apart
from the LaTeX example that I put previously
(\foreignlanguage{lang}{short-text}), there are commands like
\textsc{text in small caps}, \textcolor{color}{text}, and so on. When
one of the arguments consists of textual content, even if it is a short
text, it can be tedious to escape constantly commas[1]. Anyway, I
understand that my use case may not be that of the rest of the users,
and what is a 'problem' for me, it may not be seen as a problem by other
users; therefore, I fully understand Bastien's warnings about making a
modification to something that already works fine, and has been working
fine since always.
Nicolas's suggestion seemed the most reasonable, or the least
destructive, in the hypothetical scenario that there would be a great
demand among users of an alternative separator. Now I see unlikely,
however, that such a demand exists ;-) So, if my use case is a minority,
of course I agree with give up this proposal...
[1] To mitigate 'comma issue' I wrote a function that escapes commas
when saving document :-D
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Bastien writes:
>
>> thank you for the patch. I understand the general idea, but I think
>> we should be careful not to overload the macro syntax - escaping the
>> coma seems okay to me. I'm closing this suggestion.
>>
>> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
>> course insist on rejecting it.
>
> This is a followup to a previous discussion in this mailing list, in
> which Juan Manuel explained his use-case for a different argument
> separator in macros. I noticed then that there was an opening for
> a backward compatible syntax extension for it. As I was also not certain
> it would be a good idea overall, I suggested him to start a new, more
> visible, thread with the proposal, and collect feedback.
>
> So, maybe it is a bit early to close it.
>
> BTW, I would like to amend the proposed syntax, so as to limit friction
> with the rest of Org. What would be more reasonable is the following:
>
>{{{macroname·(...)}}}
>
> where · is either nothing or a _single_ printable non-alphanumeric
> non-space non-parenthesis character that isn't already meaningful in
> Org. For example, if for some reason, we limit ourselves to ASCII
> characters only, the set of allowed separators would be:
>
>! % & , ; ? `
>
> So, again, I'm not saying we should do this. TBH, I'm not convinced by
> the idea of duplicate syntax (comma-escaping and alternate characters)
> for the same thing. But hard-core macro users may have a word to say
> about it.
>
> WDYT?
>
> Regards,
Re: [Feature Request] More flexibility in org-speed-commands customization
Hi Bastien, On Sat, 01 May 2021 at 13:24, Bastien wrote: Hi Gustavo, Gustavo Barros writes: I don't know if there is a strong reason to hard-code the set of keys in `org-speed-commands-default'. But, if there isn't, could you consider (somehow) exposing the whole set of `org-speed-commands' to user customization? Well, no, I don't see a strong reason to hard-code the set of speedy keys. See the attached patch, which proposes to use just one option `org-speed-commands'. This would be a breaking change, but I don't think we do otherwise. Would this suit your needs? What do you think about the change? Thank you for seeing to this. Yes, the patch corresponds pretty much to what I had in mind. That's the way I'd go there too. And it's not about my needs here, I can verify it is safe to override the defconst and do so (as indeed I do). I was thinking more of that kind of user which would be uncertain if they could, and might eventually refrain from using a nice feature for framing it an "expert kind of stuff". A possible way to mitigate breakage here can be at hand, since we ended up with a third name (a proper one, btw). You could mark `org-speed-commands-user' as obsolete but keep it, for the due time as usual, and append it to `org-speed-commands' somehow (no need to distinguish them in `org-speed-command-help' though). Those who had overriden `org-speed-commands-default' are on their own, of course, as they shouldn't have done that in the first place. ;-) Best regards, Gustavo.
Re: Free up C-c SPC/org-table-blank-field?
On 04/28/21 05:50 AM, Bastien wrote: > Eric Abrahamsen writes: > >> That took a while, for such a simple patch! Hope this is acceptable. > > ... and it took a while to install it, but finally done with commit > 7a1c8cadf. > > Thanks! Awesome, thank you!
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Bastien, On Sat, 01 May 2021 at 17:28, Bastien wrote: Hi Gustavo, Gustavo Barros writes: The Org line commands -- `org-beginning-of-line', `org-end-of-line', and `org-kill-line' -- all take due care for the presence of `visual-line-mode' to do the right thing if it is turned on. However, when `visual-line-mode' is indeed on, the bindings on `visual-line-mode-map' shadow Org's bindings, so that we actually get `beginning-of-visual-line', `end-of-visual-line', and `kill-visual-line' for the usual keybindings, instead of the much nicer specialized Org commands. Fixed in the maint branch with commit ccd513a3c, thanks! Thank you! Gustavo.
Re: Bug: org-toggle-link-display and org-hide-emphasis-markers [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]
Hi Bastien, On Sat, 01 May 2021 at 13:42, Bastien wrote: Hi Gustavo, Gustavo Barros writes: when using `org-hide-emphasis-markers', making links visible with `org-toggle-link-display' also unhides the emphasis markers. I believe this to be unexpected behavior (it certainly is to me), but I might be wrong here, given that the emphasis markers are explicitly set to a `org-link' invisible property (which see). thanks for reporting this, I've committed 842ab092a in maint which should fix it. Thank you for looking into this, and for the fix. I hope the change does not break anyone's code: perhaps some people use custom code to hide/show emphasis markers based on the org-link invisible property specs. In any case, I don't think `org-toggle-link-display' should display emphasis markers. I'm not sure either. Perhaps that was the reason why `org-link' was used as the invisibility property there in the first place. If you think that is a concern, perhaps adding something as `org-emph' to the invisibility specs and using it there instead of leaving the markers in the default group might be a good idea. This way it would be possible to toggle the markers selectively, as it is done with the links. I'm not sure this is granted, but one reasonable hypothesis why `org-link' was used there in the first place is that some degree of selective toggling of the markers was somehow demanded. Best, Gustavo.
Re: [PATCH] ob-tangle.el: Speed up tangling
Hi Sébastien, Sébastien Miquel writes: > Indeed, I hadn't thought to run the tests, sorry. I've fixed my code > and modified the `block-order` test in order for it to pass. Applied with commit a2cb9b853, thank you very much for the updated patch. > The patch does modify the order of the tangled blocks. When several > blocks with different languages are tangled to the same file, they > used to be grouped according to language, and are now tangled in the > order in which they appear. I assumed this was an oversight in the > previous code, but since this test exists, maybe it was intended ? > > Nicolas Goaziou wrote this test, perhaps he could comment on this. Sure, feel free to adapt the code further if needed after discussing this. Thanks, -- Bastien
Re: Bug: SETUPFILE and visual-line-mode [9.3 (release_9.3 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Hi Caio, Bastien writes: > thanks for reporting this -- it seems to be a variant of what Gustavo > has been reporting in this thread: > > https://orgmode.org/list/87a6zkv3m2@gmail.com/ > > ... for which I don't have a solution yet. I'm confirming this bug > for https://updates.orgmode.org. Fixed with commit ccd513a3c in the maint branch. Thanks! -- Bastien
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Gustavo, Gustavo Barros writes: > The Org line commands -- `org-beginning-of-line', `org-end-of-line', and > `org-kill-line' -- all take due care for the presence of > `visual-line-mode' to do the right thing if it is turned on. However, > when `visual-line-mode' is indeed on, the bindings on > `visual-line-mode-map' shadow Org's bindings, so that we actually get > `beginning-of-visual-line', `end-of-visual-line', and `kill-visual-line' > for the usual keybindings, instead of the much nicer specialized Org > commands. Fixed in the maint branch with commit ccd513a3c, thanks! -- Bastien
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Kyle Meyer writes: > Kyle Meyer writes: > >> Ah, sorry for not writing that more clearly. By the above, I wasn't >> saying that the ones I commented on were the _only_ ones I see with >> Emacs 24.5 on maint. > > I've dealt with a few more. Thank you both very much! -- Bastien
Re: A small idea to simplify (further) time input in the date/time prompt
Hi Bastien, On Sat, 01 May 2021 at 12:40, Bastien wrote: Hi Gustavo, sorry for the slow reply. I applied this patch in master with commit e8562a332. Thanks! Thank you very much! Looking forward to enjoy this one. Best, Gustavo.
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Kyle Meyer writes: > Ah, sorry for not writing that more clearly. By the above, I wasn't > saying that the ones I commented on were the _only_ ones I see with > Emacs 24.5 on maint. I've dealt with a few more. * ob-C.el:477:1:Error: Unknown upattern `(quote integerp)' Introduced by 38f87a26b (ob-C.el: Fix a number a regressions related to table parameters, 2021-04-29). Fixed by 8bd3bd093. * org-agenda.el:10851:1:Warning: the following functions are not known to be defined: [...] window-font-width I mentioned upthread (<87czubrqh6@kyleam.com>) that I didn't think this was easy to solve with a wrapper. Instead I've added a fallback to the previous calculation, which was in action for a long time and is certainly better than a void-function error (94837fc6b). * Compiler-macro error for python-syntax-context: (void-function python-syntax--context-compiler-macro) I don't know what's going on here. This is triggered by (python-syntax-context 'string) in ob-python. That looks like it should work on Emacs 24, where python.el has python-syntax--context-compiler-macro. Despite the message from the compiler, evaluating (python-syntax-context 'string) directly seems to work as expected, so perhaps this doesn't actually cause ob-python breakage. Aside from the harmless ol-eww warnings already mentioned, that leaves the funcall-interactively instances.
Re: [PATCH] ob-tangle.el: Speed up tangling
Hi Bastien, Bastien writes: The compiler is complaining with In toplevel form: ob-tangle.el:196:1: Warning: Variable ‘modes’ left uninitialized Also, it breaks these two tests for me: 2 unexpected results: FAILED ob-tangle/block-order FAILED ob-tangle/continued-code-blocks-w-noweb-ref Indeed, I hadn't thought to run the tests, sorry. I've fixed my code and modified the `block-order` test in order for it to pass. The patch does modify the order of the tangled blocks. When several blocks with different languages are tangled to the same file, they used to be grouped according to language, and are now tangled in the order in which they appear. I assumed this was an oversight in the previous code, but since this test exists, maybe it was intended ? Nicolas Goaziou wrote this test, perhaps he could comment on this. Regards, -- Sébastien Miquel >From 2aa09e8d2f4e8703190e9035d711508c11b3a8eb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sat, 1 May 2021 21:18:44 +0200 Subject: [PATCH] ob-tangle.el: Improve tangling * lisp/ob-tangle.el (org-babel-tangle-collect-blocks): Group collected blocks by tangled file name. (org-babel-tangle): Avoid quadratic behavior in number of blocks and set modes before writing to file. * testing/lisp/test-ob-tangle.el (ob-tangle/block-order): Update test. --- lisp/ob-tangle.el | 151 - testing/lisp/test-ob-tangle.el | 2 +- 2 files changed, 74 insertions(+), 79 deletions(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 4c0c3132d..36144d6ae 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -225,67 +225,55 @@ matching a regular expression." (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info 'light (user-error "Point is not in a source code block" path-collector) - (mapc ;; map over all languages - (lambda (by-lang) - (let* ((lang (car by-lang)) - (specs (cdr by-lang)) - (ext (or (cdr (assoc lang org-babel-tangle-lang-exts)) lang)) - (lang-f (org-src-get-lang-mode lang)) - she-banged) - (mapc - (lambda (spec) - (let ((get-spec (lambda (name) (cdr (assoc name (nth 4 spec)) - (let* ((tangle (funcall get-spec :tangle)) - (she-bang (let ((sheb (funcall get-spec :shebang))) - (when (> (length sheb) 0) sheb))) - (tangle-mode (funcall get-spec :tangle-mode)) - (base-name (cond - ((string= "yes" tangle) - (file-name-sans-extension - (nth 1 spec))) - ((string= "no" tangle) nil) - ((> (length tangle) 0) tangle))) - (file-name (when base-name - ;; decide if we want to add ext to base-name - (if (and ext (string= "yes" tangle)) - (concat base-name "." ext) base-name - (when file-name - ;; Possibly create the parent directories for file. - (let ((m (funcall get-spec :mkdirp)) - (fnd (file-name-directory file-name))) - (and m fnd (not (string= m "no")) - (make-directory fnd 'parents))) - ;; delete any old versions of file - (and (file-exists-p file-name) - (not (member file-name (mapcar #'car path-collector))) - (delete-file file-name)) - ;; drop source-block to file - (with-temp-buffer - (when (fboundp lang-f) (ignore-errors (funcall lang-f))) - (when (and she-bang (not (member file-name she-banged))) + (mapc ;; map over file-names + (lambda (by-fn) + (let ((file-name (car by-fn))) + (when file-name + (let ((lspecs (cdr by-fn)) + (fnd (file-name-directory file-name)) + modes make-dir she-banged lang) + ;; drop source-blocks to file + ;; We avoid append-to-file as it does not work with tramp. + (with-temp-buffer + (mapc + (lambda (lspec) + (let* ((block-lang (car lspec)) + (spec (cdr lspec)) + (get-spec (lambda (name) (cdr (assq name (nth 4 spec) + (she-bang (let ((sheb (funcall get-spec :shebang))) + (when (> (length sheb) 0) sheb))) + (tangle-mode (funcall get-spec :tangle-mode))) + (unless (string-equal block-lang lang) + (setq lang block-lang) + (let ((lang-f (org-src-get-lang-mode lang))) + (when (fboundp lang-f) (ignore-errors (funcall lang-f) + ;; if file contains she-bangs, then make it executable + (when she-bang + (unless tangle-mode (setq tangle-mode #o755))) + (when tangle-mode + (add-to-list 'modes tangle-mode)) + ;; Possibly create the parent directories for file. + (let ((m (funcall get-spec :mkdirp))) + (and m fnd (not (string= m "no")) + (setq make-dir t))) + ;; Handle :padlines unless first line in file + (unless (or (string= "no" (funcall get-spec :padline)) +(= (point) (point-min))) + (insert "\n")) + (when (and she-bang (not she-banged))
Re: [PATCH] org-agenda.el: Add a M-, binding for org-priority-show
On Sat, 1 May 2021 at 11:45, Bastien wrote: > Kyle Meyer writes: > > With a C-u, org-agenda-priority calls org-priority-show. So perhaps > > instead of adding a new binding, the documentation should be improved. > > I pushed a small enhancement for org-agenda-priority's docstring > with commit e080eb759. > > I am reluctant adding another keybinding to the agenda especially > since there is no keybinding for `org-priority-show'. Thanks, that sounds like a better approach.
Re: Transforming table and then exporting as CSV
Pankaj Jangid writes: [...] > Same org file has multiple tables, so I am asking for “Table Name”. I > want to do two improvements: > > 1. When asking for table name, I want to offer all the table names in >the file as completion options. You could collect names with something like (require 'subr-x) (let (names) (org-table-map-tables (lambda () (when-let ((name (org-element-property :name (org-element-at-point (push name names))) 'quiet) (nreverse names)) and then pass those as the collection to completing-read. > 2. Current table at point as default You could get that with (and (org-at-table-p) (save-excursion (goto-char (org-table-begin)) (org-element-property :name (org-element-at-point and pass that as the default for completing-read. > 3. I want to run the function from command line. Like, > > --8<---cut here---start->8--- >emacs --batch enet_2021_22.org -l enet.el --eval="(enet-export > \"APR2021\")" > --8<---cut here---end--->8--- > >Do I need to change the (interactive...) part in any way to enable >this? I think that'd be the cleanest way, yes. You could change (interactive "MTable Name: ") into (interactive (list (completing-read ...)))
Re: [PATCH] LaTeX export: arbitrary float environments
Thomas S. Dye writes: > Aloha Timothy, :waves: > Sorry for the clumsy patch, which I guess would also benefit from an addition > to > the manual, as well? No problem, we all start somewhere :) (and I know I'm still making mistakes) An update to the manual to describe the changed behaviour would be good. If you'd like you could wait till a core maintainer says this looks good before going to that effort, or you could add it in now so it's all in a single patch --- as long as something happens. > Larger question: do we really want to tinker with ob-latex in this way? Or, > should changes like this patch follow a path indicated by Tim Cross and into > their own package, say ob-latex-ex, which might someday replace ob-latex if it > proved useful and stable? I don't think LaTeX support is likely to leave Org any time soon, so at least until a core maintainer tells you otherwise I'd be inclined to proceed with your current patch. If this was a huge/transformational change I may be more uncertain, but this looks fairly simple to me at least. -- Timothy > All the best, > Tom > > Timothy writes: > >> Hi Thomas, >> >> On the surface, this looks reasonable to me :) >> >> Just commenting on some technicalities with the patch itself: >> - In ORG-NEWS it would be good to wrap the content over multiple lines >> instead of having a single 270 char line :) >> - You seem to have an anomalous change to the ob-python :return entry >> - I don't think your patch subject follows the convention for Org, it >> should be: >> "main file/feature: overall change summary" >> so, something like >> "ox-latex: allow for arbitrary float environments" >> rather than >> "LaTeX export: arbitrary float environments" >> >> Thanks for the patch :) >> >> Timothy
Re: [PATCH] avoid loading major modes when exporting to file
Bastien writes: > This even be "auto-mode-alist" instead of "(auto-mode-alist nil)". Ah, it can indeed. > I'm still unsure the patch is correct: what if people *need* major > mode initialization before any contents is exported to a file? I haven't responded to this concern, because I haven't been able to conceive of a single situation where loading the normal-mode for the exported file could be desirable. >> I think the commit description is pretty thorough, so give that a look. >> TLDR; it makes `org-export-to-file' behave a bit more nicely. > > I find it useful to have a small description of the change and why it > is needed in the body of the email, when a patch is attached. I think I may have been become overly used to how convenient mu4e is for showing patches inline . For the sake of anyone just looking at the Email body, here's what I considered to be an informative commit message, subtly reworded: Currently, when `org-export-to-file' is called it activated the major mode for that file type based on `auto-mode-alist'. This can be mildly annoying in various ways as loading the major mode: 1. makes the export take longer 2. can produce unwanted "noise" while initialising, namely warnings and errors related to the mode itself 3. can produce spurious files like an .auctex-auto folder By locally binding `auctex-auto' to nil all of these undesirable behaviours can be avoided. -- Timothy
Re: Bug: org-plot gives Invalid function error
Timothy writes: > I think it makes sense to leave this open until a fix has been > applied. Done, thanks. -- Bastien
Re: [PATCH] LaTeX export: arbitrary float environments
Aloha Timothy, Thanks for your kind response. Sorry for the clumsy patch, which I guess would also benefit from an addition to the manual, as well? Larger question: do we really want to tinker with ob-latex in this way? Or, should changes like this patch follow a path indicated by Tim Cross and into their own package, say ob-latex-ex, which might someday replace ob-latex if it proved useful and stable? All the best, Tom Timothy writes: Hi Thomas, On the surface, this looks reasonable to me :) Just commenting on some technicalities with the patch itself: - In ORG-NEWS it would be good to wrap the content over multiple lines instead of having a single 270 char line :) - You seem to have an anomalous change to the ob-python :return entry - I don't think your patch subject follows the convention for Org, it should be: "main file/feature: overall change summary" so, something like "ox-latex: allow for arbitrary float environments" rather than "LaTeX export: arbitrary float environments" Thanks for the patch :) Timothy -- Thomas S. Dye https://tsdye.online/tsdye
Re: Bug: org-plot gives Invalid function error
Bastien writes: >>> plot '/tmp/org-plotiPs0To' using 1:3 with histograms title 'H-index' >> >> This is not valid gnuplot command to create histograms. > > I'm closing this bug now - feel free to reopen it if I misunderstood > the thread. The bug has been identified, but not fixed. I should get to this within the next few days, as long as I don't get distracted. I think it makes sense to leave this open until a fix has been applied. -- Timothy
Re: Separator "::" -> what is it for in headlines?
Why does the separator "::" work with headlines? > It doesn't seem to have any effect for me, it gets handled as part of the headline, both in fontification and in exports: [image: image.png] [image: image.png] Which is, as I understand it, as it should be, since it doesn't have any special meaning in headlines. In your case it seems indeed to be getting fontified as if it were a list. What version of Org do you have? I am using 9.5 on Emacs 27.2. --Diego
Re: Bug: org-plot gives Invalid function error
Hi Ihor and Timothy, Ihor Radchenko writes: > Of course, the described bug may be related to something else. > [after some testing...] > Of course, it is: > >> plot '/tmp/org-plotiPs0To' using 1:3 with histograms title 'H-index' > > This is not valid gnuplot command to create histograms. I'm closing this bug now - feel free to reopen it if I misunderstood the thread. -- Bastien
Re: Bug: Org bold emphasis gobbles leading stars on next headline [9.3.7 (release_9.3.7-710-g3f04ad @ /home/n/.emacs.d/straight/build/org/)]
Hi, Bastien writes: > Indeed, I can reproduce this bug with latest Org. FWIW I cannot reproduce this anymore (with latest Org and Emacs), I'm closing this bug now. Feel free to reopen it if necessary. -- Bastien
Re: org-goto and org-store-link/org-id-get-create
Bastien writes: > Applied in maint with commit 0a8079b4d, thanks a lot! Er, sorry, I should have explained why I applied it to maint too, on top of applying it to master three days ago: first of all, this is a bugfix, and I also want to take the opportunity of releasing Org 9.4.6 so that more people can test it before Org 9.5. -- Bastien
Re: [PATCH] avoid loading major modes when exporting to file
Hi Timothy, Timothy writes: > Another little patch, this time a one-liner. This even be "auto-mode-alist" instead of "(auto-mode-alist nil)". I'm still unsure the patch is correct: what if people *need* major mode initialization before any contents is exported to a file? > I think the commit description is pretty thorough, so give that a look. > TLDR; it makes `org-export-to-file' behave a bit more nicely. I find it useful to have a small description of the change and why it is needed in the body of the email, when a patch is attached. Otherwise, you can configure git send-mail to send a patch to the list as an email and then we can discuss the explanation part that you can add after the change log part. Thanks, -- Bastien
Re: bug#47820: [PATCH] org-table-import: Give option to import interactively even if filename doesn't match
On 2021-05-01, 18:06 +0200, Bastien wrote: > I let you and Nicolas move forward on separators guessing, because so > far I'm not really convinved Org should try to be too clever here. Yes! Nicolas has also convinced me on that front. There was some misunderstanding on my side as I was considering Elisp (my first Lisp) to be a general purpose language and Org tables it's CSV library. Even though due to the very nature of Lisp most of this possible but Org is not a right place for this. -- Utkarsh Singh http://utkarshsingh.xyz
Re: org-goto and org-store-link/org-id-get-create
Applied in maint with commit 0a8079b4d, thanks a lot! Ihor Radchenko writes: > Bastien writes: > >> Can you provide a patch for this? > > Sure. Attached. -- Bastien
Re: Bug: org-toggle-link-display and org-hide-emphasis-markers [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]
Hi Gustavo, Gustavo Barros writes: > when using `org-hide-emphasis-markers', making links visible with > `org-toggle-link-display' also unhides the emphasis markers. I believe > this to be unexpected behavior (it certainly is to me), but I might be > wrong here, given that the emphasis markers are explicitly set to a > `org-link' invisible property (which see). thanks for reporting this, I've committed 842ab092a in maint which should fix it. I hope the change does not break anyone's code: perhaps some people use custom code to hide/show emphasis markers based on the org-link invisible property specs. In any case, I don't think `org-toggle-link-display' should display emphasis markers. -- Bastien
Re: [Feature Request] More flexibility in org-speed-commands customization
Hi Gustavo,
Gustavo Barros writes:
> I don't know if there is a strong reason to hard-code the set of keys
> in `org-speed-commands-default'. But, if there isn't, could you
> consider (somehow) exposing the whole set of `org-speed-commands' to
> user customization?
Well, no, I don't see a strong reason to hard-code the set of speedy
keys. See the attached patch, which proposes to use just one option
`org-speed-commands'.
This would be a breaking change, but I don't think we do otherwise.
Would this suit your needs? What do you think about the change?
--
Bastien
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 07ff85349..5da606b36 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -696,28 +696,6 @@ star at the beginning of the headline, you can do this:
(const :tag "At beginning of headline stars" t)
(function)))
-(defcustom org-speed-commands-user nil
- "Alist of additional speed commands.
-This list will be checked before `org-speed-commands-default'
-when the variable `org-use-speed-commands' is non-nil
-and when the cursor is at the beginning of a headline.
-The car of each entry is a string with a single letter, which must
-be assigned to `self-insert-command' in the global map.
-The cdr is either a command to be called interactively, a function
-to be called, or a form to be evaluated.
-An entry that is just a list with a single string will be interpreted
-as a descriptive headline that will be added when listing the speed
-commands in the Help buffer using the `?' speed command."
- :group 'org-structure
- :type '(repeat :value ("k" . ignore)
- (choice :value ("k" . ignore)
- (list :tag "Descriptive Headline" (string :tag "Headline"))
- (cons :tag "Letter and Command"
- (string :tag "Command letter")
- (choice
-(function)
-(sexp))
-
(defcustom org-speed-command-hook
'(org-speed-command-activate org-babel-speed-command-activate)
"Hook for activating speed commands at strategic locations.
@@ -737,7 +715,7 @@ hook. The default setting is `org-speed-command-activate'."
:version "24.1"
:type 'hook)
-(defconst org-speed-commands-default
+(defcustom org-speed-commands
'(("Outline Navigation")
("n" . (org-speed-move-safe 'org-next-visible-heading))
("p" . (org-speed-move-safe 'org-previous-visible-heading))
@@ -762,8 +740,7 @@ hook. The default setting is `org-speed-command-activate'."
("l" . org-metaleft)
("R" . org-shiftmetaright)
("L" . org-shiftmetaleft)
-("i" . (progn (forward-char 1) (call-interactively
-'org-insert-heading-respect-content)))
+("i" . (progn (forward-char 1) (call-interactively 'org-insert-heading-respect-content)))
("^" . org-sort)
("w" . org-refile)
("a" . org-archive-subtree-default-with-confirmation)
@@ -782,8 +759,7 @@ hook. The default setting is `org-speed-command-activate'."
(":" . org-set-tags-command)
("e" . org-set-effort)
("E" . org-inc-effort)
-("W" . (lambda(m) (interactive "sMinutes before warning: ")
- (org-entry-put (point) "APPT_WARNTIME" m)))
+("W" . (lambda (m) (interactive "sMinutes before warning: ") (org-entry-put (point) "APPT_WARNTIME" m)))
("Agenda Views etc")
("v" . org-agenda)
("/" . org-sparse-tree)
@@ -792,7 +768,27 @@ hook. The default setting is `org-speed-command-activate'."
("?" . org-speed-command-help)
("<" . (org-agenda-set-restriction-lock 'subtree))
(">" . (org-agenda-remove-restriction-lock)))
- "The default speed commands.")
+ "Alist of speed commands.
+
+The car of each entry is a string with a single letter, which
+must be assigned to `self-insert-command' in the global map.
+
+The cdr is either a command to be called interactively, a
+function to be called, or a form to be evaluated.
+
+An entry that is just a list with a single string will be
+interpreted as a descriptive headline that will be added when
+listing the speed commands in the Help buffer using the `?' speed
+command."
+ :group 'org-structure
+ :type '(repeat :value ("k" . ignore)
+ (choice :value ("k" . ignore)
+ (list :tag "Descriptive Headline" (string :tag "Headline"))
+ (cons :tag "Letter and Command"
+ (string :tag "Command letter")
+ (choice
+(function)
+(sexp))
(defun org-print-speed-command (e)
(if (> (length (car e)) 1)
@@ -815,11 +811,8 @@ hook. The default setting is `org-speed-command-activate'."
(unless org-use-speed-commands
(user-error "Speed commands are not activated, customize `org-use-speed-commands'"))
(with-output-to-temp-buffer "*Help*"
-(princ "User-defined Speed commands\n===\n")
-(mapc #'org-print-speed-command org-speed-commands-user)
-(princ "\n")
-(princ "Built-in Speed commands\n===\n")
-(mapc #'org-print-speed-command org-speed-commands-default))
+(princ "Speed commands\n===\n")
+(mapc
Re: bug#47820: [PATCH] org-table-import: Give option to import interactively even if filename doesn't match
Hi Utkarsh, Utkarsh Singh writes: > Actually, I proposed a revised patch in the following tread (which also > include more patches building up on this patch): > https://orgmode.org/list/87zgxpwqa7@gmail.com/T/#m38de818718a71f670fbc21b7abb8c789ef485181 thanks for the heads up. I thought applying this first patch would help clarify the discussion on this other thread, as the problem is different. I let you and Nicolas move forward on separators guessing, because so far I'm not really convinved Org should try to be too clever here. Thanks, -- Bastien
Re: Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi Gustavo, Gustavo Barros writes: > I just found a misbehaving of `org-insert-heading-respect-content': when > it's called before the first heading in the buffer, it breaks the > structure of that fist heading by inserting a new heading on the line > the previous heading existed. Fixed with commit fb3030188 in the maint branch, thanks a lot. Please test it and report any problem you may encounter. Thanks, -- Bastien
Re: Fwd: Bug: Texinfo export: Inline images are NOT rendered in INFO viewer [9.4.5 (release_9.4.5-354-g40b70c @ /home/rameshnedunchezian/src/org-mode/lisp/)]
On 30/04/21 7:25 pm, Nicolas Goaziou wrote: > Hello, > > Ramesh Nedunchezian writes: > >> Bug: Texinfo export: Inline images are NOT rendered in INFO viewer > > Fixed. Thank you. Verified. Thanks.
Re: A small idea to simplify (further) time input in the date/time prompt
Hi Gustavo, sorry for the slow reply. I applied this patch in master with commit e8562a332. Thanks! -- Bastien
Re: [PATCH] Add 'simple option to org-fast-tag-selection-single-key.
Hi tumashu, tumashu writes: > This is v2 patch, use completing-read-multipul. Thanks for the patch. You can already do this: (setq org-use-fast-tag-selection nil) Then you'll be able to select tags the way you implemented it with this simple mode. -- Bastien
Re: bug#47820: [PATCH] org-table-import: Give option to import interactively even if filename doesn't match
Hi Bastien, On 2021-05-01, 10:51 +0200, Bastien wrote: > Hi Utkarsh, > > Utkarsh Singh writes: > >> Can we give small flexibility in choosing the filename interactively for >> `org-table-import'? Currently org-table-import will just throw an error >> when file name doesn't have .txt, .csv or .tsv as extension. > > Applied in master as commit 7c99d1555, thanks. > > Please see the commit changelog for future patches: > https://code.orgmode.org/bzg/org-mode/commit/7c99d1555 > > Also https://orgmode.org/worg/org-contribute.html#commit-messages give > more detailed directions. Actually, I proposed a revised patch in the following tread (which also include more patches building up on this patch): https://orgmode.org/list/87zgxpwqa7@gmail.com/T/#m38de818718a71f670fbc21b7abb8c789ef485181 Btw, thank you for this and I will try to keep original tread updated from next time. -- Utkarsh Singh http://utkarshsingh.xyz
Re: [PATCH] ob-tangle.el: Speed up tangling
Hi Sébastien, thanks for the patch! I applied against master and tested it. The compiler is complaining with In toplevel form: ob-tangle.el:196:1: Warning: Variable ‘modes’ left uninitialized Also, it breaks these two tests for me: 2 unexpected results: FAILED ob-tangle/block-order FAILED ob-tangle/continued-code-blocks-w-noweb-ref Let me know if you manage to pass all the test (or fix them...) and silent the warning. Thanks! -- Bastien
Re: [PATCH] etc/ORG-NEWS: Announce clocktable per-file time percentages (':formula %')
Hi Alan, "Alan D. Salewski" writes: > Sure thing; included below. Applied in master as commit a2403321a, thanks! -- Bastien
Re: [PATCH] Bug: fragile org refile cache
On 29/04/2021 23:08, Ihor Radchenko wrote: My experience is exactly opposite. Or maybe I miss something. Can you elaborate? Some additions. org-outline-path-cache is used solely by org-refile-get-targets (maybe there are some calls in other packages) but it efficiency is questionable. It was not clear for me earlier that the cache is reset before each scan through a buffer. So if org-refile-use is disabled, org-outline-path-cache from previous run of org-refile or org-goto is not used as well. A query to org-outline-path-cache requires at least one backward search and hash lookup. During sequential scan in org-refile-get-targets it is enough to have previous heading path to update it when new heading is found. I think, org-outline-path-cache should be deprecated. Just cleanup heading text: I have realized what is wrong with this benchmark. It runs so fast because it matches no headings, so it never spent time for cleaning them up. (benchmark-run 1 (goto-char (point-min)) (while (re-search-forward "^\\*+" nil t) (let ((case-fold-search nil)) (beginning-of-line) should be added before next call and (end-of-line) somewhere later in while body. (looking-at org-complex-heading-regexp) (if (not (match-end 4)) "" ;; Remove statistics cookies. (org-trim (org-link-display-format (replace-regexp-in-string "\\[[0-9]+%\\]\\|\\[[0-9]+/[0-9]+\\]" "" (match-string-no-properties 4 => (0.013364877 0 0.0) On 29/04/2021 21:12, Ihor Radchenko wrote: For the cleaned heading text, I do not think that re-calculating the heading text on each change is a good idea. It may degrade typing latency. Yet, an acceptable approach could be simply invalidating cache for the changed headings. Then, outline paths can be re-calculated on changed headings when needed. I agree that it is enough to invalidate cleaned heading on edit to refresh it in org-refile-get-targets. On the other hand, I still prefer text properties since they could be fetched even if some lines have been added or removed before. Position-based cache is useless in such cases. Concerning typing latency, it should be postponed and resumed when no new edits is performed for certain period of time (~1s). However I am unsure if it is possible to accurately track all affected lines since later changes can add/remove lines before the line scheduled for invalidation. On 30/04/2021 02:17, Tim Cross wrote: I suspect the reason it is not done automatically is that getting that right for all use cases is very hard to do without adding adverse impact to performance. A cache which is marked as 'dirty' too often results in too frequent cache refresh operations, but at the same time, determining what changes in an org file actually invalidate the cache can be a process intensive operation. I believed that idea risen in this thread was to regenerate cache instead of spitting "Please regenerate the refile cache with `C-0 C-c C-w'" leaving more tricky cases for the user.
[PATCH] etc/ORG-NEWS: Announce clocktable per-file time percentages (':formula %')
On Sat, May 1, 2021, at 05:52, Bastien wrote: > Hi Alan, > > applied in master as commit 9aa9f3b1f. > > Thanks you very much! Great, and thank /you/ for all the work you do on org-mode! > Can you announce this by providing a patch for etc/ORG-NEWS? > > -- > Bastien Sure thing; included below. 8< * etc/ORG-NEWS: New entry announcing clocktable calculation and display of per-file time percentages, when ':formula %' is used. TINYCHANGE Signed-off-by: Alan D. Salewski --- etc/ORG-NEWS | 17 + 1 file changed, 17 insertions(+) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 0c822d029..d08e3f68f 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -235,6 +235,23 @@ tags including from both buffer local and user defined persistent global list (~org-tag-alist~ and ~org-tag-persistent-alist~). Now option ~org-complete-tags-always-offer-all-agenda-tags~ is honored. +*** Clocktable option =:formula %= now shows the per-file time percentages + +This change only has an effect when multiple files are contributing to +a given clocktable (such as when =:scope agenda= has been specified). +The existing behavior is that such tables have an extra 'File' column, +and each individual file that contributes has its own summary line +with the headline value '*File time*'. Those summary rows also +produce a rollup time value for the file in the 'Time' column. + +Prior to this change, the built-in =%= formula did not produce a +calculation for those per-file times in the '%' column (the relevant +cells in the '%' column were blank). With this change, the +percentage contribution of each individual file time to the total +time is shown. + +The more agenda files you have, the more useful this behavior becomes. + ** Miscellaneous *** Missing or empty placeholders in "eval" macros are now nil They used to be the empty string. -- a l a n d. s a l e w s k i ads@salewski.email salew...@att.net https://github.com/salewski
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes: > Kyle Meyer writes: > >> Here are a few notes on ones present in maint that I've glanced at. > > I confirm that there are no warning using Emacs 25.3.1 on maint. > > For Emacs 24.5.1, I see that following in addition to what you > mentioned: Ah, sorry for not writing that more clearly. By the above, I wasn't saying that the ones I commented on were the _only_ ones I see with Emacs 24.5 on maint.
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Applied as commit 5f619205e with a change log in the commit message. Thanks! Ihor Radchenko writes: >>> In end of data: >>> ob-gnuplot.el:299:1:Warning: the function ‘file-local-name’ is not known to >>> be > > This does not appear on maint. Only on master. The patch for master attached. -- Bastien
Re: prettify-symbols-mode in org agenda?
William Xu writes:
>> (org-agenda-highlight-todo): Preserve composition property used,
>> i.e. by `prettify-symbols-mode'.
>
> It looks like this change is not really needed, my emacs is built from
> git master. Maybe the 'composition property is now preserved
> automatically in the buffer?
This change is needed, for example, when you change todo-state using
`org-agenda-todo'. Refreshing the agenda line in
org-agenda-highlight-todo involves
(insert (format org-agenda-todo-keyword-format s))
`insert' will destroy the 'composition as 'composition is set by
pretty-symbols to be self-destructed on change.
Having said that, I can now see an easier approach to deal with the
problem: simply wrap insert into `with-silent-modifications'
Amended patch with some minor refactoring is attached.
Best,
Ihor
>From b6edd24d4477467e05b69258eccef58d48b39676 Mon Sep 17 00:00:00 2001
Message-Id:
From: Ihor Radchenko
Date: Sat, 1 May 2021 20:09:10 +0800
Subject: [PATCH] Make sure that fontification is preserved in agenda
Preserve fontification and composition of headlines and tags in
agenda. If the headlines/tags are not yet fontified when building
agenda, make sure that they are fontified in the original Org mode
buffers first.
In addition, tags alignment is now done pixelwise to avoid alignment
issues with variable-pitch symbols that may appear in fontified Org
mode buffers. The alignment is utilising :align-to specification,
which means that the alignment will be automatically updated as the
agenda buffer is resized.
* lisp/org-macs.el (org-string-width): Refactor old code and add
optional argument to return pixel width. The old code used manual
parsing of text proerpties to find which parts of string are visible.
The new code defers this work to Emacs display engine via
`window-text-pixel-size'. The visibility settings of current buffer
are taken into account.
(org-buffer-substring-fontified): New function getting fontified
substring from current buffer.
* lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
org-agenda-get-deadlines, org-agenda-get-scheduled): Use
org-buffer-substring-fontified to get fontified heading.
(org-agenda-fix-displayed-tags): Fontify tags.
(org-agenda-highlight-todo): Preserve composition property used,
i.e. by `prettify-symbols-mode'. The composition is usually set to be
removed on text change, so we do the changes inside
`with-silent-modifications'.
(org-agenda-align-tags): Use pixel width and (space . :align-to)
'display property to align tags in agenda.
---
lisp/org-agenda.el | 63 --
lisp/org-macs.el | 108 ++---
2 files changed, 83 insertions(+), 88 deletions(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index bd9d466a6..5add0e092 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -5562,7 +5562,7 @@ (defun org-agenda-get-todos ()
ts-date-pair (org-agenda-entry-get-agenda-timestamp (point))
ts-date (car ts-date-pair)
ts-date-type (cdr ts-date-pair)
- txt (org-trim (buffer-substring (match-beginning 2) (match-end 0)))
+ txt (org-trim (org-buffer-substring-fontified (match-beginning 2) (match-end 0)))
inherited-tags
(or (eq org-agenda-show-inherited-tags 'always)
(and (listp org-agenda-show-inherited-tags)
@@ -5973,7 +5973,7 @@ (defun org-agenda-get-progress ()
clockp (not (or closedp statep))
state (and statep (match-string 2))
category (org-get-category (match-beginning 0))
- timestr (buffer-substring (match-beginning 0) (point-at-eol)))
+ timestr (org-buffer-substring-fontified (match-beginning 0) (point-at-eol)))
(when (string-match "\\]" timestr)
;; substring should only run to end of time stamp
(setq rest (substring timestr (match-end 0))
@@ -6254,7 +6254,7 @@ (defun org-agenda-get-deadlines ( with-hour)
(let* ((category (org-get-category))
(level (make-string (org-reduced-level (org-outline-level))
?\s))
- (head (buffer-substring (point) (line-end-position)))
+ (head (org-buffer-substring-fontified (point) (line-end-position)))
(inherited-tags
(or (eq org-agenda-show-inherited-tags 'always)
(and (listp org-agenda-show-inherited-tags)
@@ -6469,7 +6469,7 @@ (defun org-agenda-get-scheduled ( deadlines with-hour)
(tags (org-get-tags nil (not inherited-tags)))
(level (make-string (org-reduced-level (org-outline-level))
?\s))
- (head (buffer-substring (point) (line-end-position)))
+ (head (org-buffer-substring-fontified (point) (line-end-position)))
(time
(cond
;; No time of day designation if it is only a
@@ -6856,6 +6856,15 @@ (defun org-agenda-fix-displayed-tags (txt tags add-inherited hide-re)
x))
tags ":")
(if have-i "::" ":"))
+ (let ((tag-string (when (string-match org-tag-group-re txt)
+ (match-string 0
Re: stability of toc links
Nicolas Goaziou writes: > I pointed out some concerns I have about the robustness of this system > already. I don't think you answered to any of them. I fear we may be > communicating past each other in this thread. Sorry about that. I'll try to address the bits I've missed in these last few emails. Just in reference to the part of your prior email that I didn't address in my reply, > I don't think such a system would preserve properties offered by > `org-export-get-reference', for example in non-latin languages. Looking back on your recent email where you list properties: > references consist of alphanumeric characters only, so they are /de > facto/ compatible with any target format; This is uses characters from [a-z0-9-] > references are guaranteed to be unique in the document; The suffixed number I mentioned ensures this. > cross-references between documents are stable. I'm not quite sure what to make of this. > Also, header content is not stable enough: when you're linking to the > custom ID, you may be able to change the title and yet preserve the > link. Custom IDs still work, so I don't quite see the point here. > I pointed out some concerns I have about the robustness of this system > already. If there are any other concerns than what I've covered above, I'm afraid they have slipped past me. -- Timothy
Re: stability of toc links
Timothy writes:
> Nicolas Goaziou writes:
>
>> I don't think such a system would preserve properties offered by
>> `org-export-get-reference', for example in non-latin languages. Also,
>> header content is not stable enough: when you're linking to the custom
>> ID, you may be able to change the title and yet preserve the link.
>>
>> However, your proposal may be an improvement over
>> `org-export-get-reference' in the context of "ox-html.el", that I don't
>> know. That's the second way I wrote about.
>
> My proposal basically replaces the random hex generating function in
> `org-export-get-reference' with a call to a function
> `org-reference-contraction' which takes a header and outputs a string
> like "some-header-string" and then has digits appended should it be
> non-unique (i.e. "some-header-string-2", "some-header-string-3").
> For certain recognised blocks (e.g. src and example blocks) it appends
> ",{block}--{n}", for example: "some-header-string,code--1".
>
> I consider this to be quite a nice improvement.
This is mostly what Texinfo exporter does, too. So it must be suitable
in some contexts, indeed.
However, I wouldn't consider it as an improvement over generic
`org-export-get-reference'. I pointed out some concerns I have about the
robustness of this system already. I don't think you answered to any of
them. I fear we may be communicating past each other in this thread.
Regards,
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Bastien writes: > could you provide a patch for these two warnings for the maint branch? >> In end of data: >> ob-gnuplot.el:299:1:Warning: the function ‘file-local-name’ is not known to >> be This does not appear on maint. Only on master. The patch for master attached. >> In org-display-inline-images: >> org.el:16554:57:Warning: reference to free variable ‘image-map’ Kyle already dealt with it. Best, Ihor >From d57d51007392f41645b78a28e8ef14132b42c324 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sat, 1 May 2021 21:54:13 +0800 Subject: [PATCH] Use org version of file-local-name for compatibility with Emacs 25 --- lisp/ob-gnuplot.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ob-gnuplot.el b/lisp/ob-gnuplot.el index c0a9ff13a..a9b8e65e5 100644 --- a/lisp/ob-gnuplot.el +++ b/lisp/ob-gnuplot.el @@ -101,7 +101,7 @@ (defun org-babel-gnuplot-process-vars (params) org-babel-temporary-directory "/gnuplot/" (file-remote-p val 'host) -(file-local-name val +(org-babel-local-file-name val (if (and (file-exists-p local-name) ;; only download file if remote is newer (file-newer-than-file-p local-name val)) local-name -- 2.26.3
Re: stability of toc links
Nicolas Goaziou writes:
> I don't think such a system would preserve properties offered by
> `org-export-get-reference', for example in non-latin languages. Also,
> header content is not stable enough: when you're linking to the custom
> ID, you may be able to change the title and yet preserve the link.
>
> However, your proposal may be an improvement over
> `org-export-get-reference' in the context of "ox-html.el", that I don't
> know. That's the second way I wrote about.
My proposal basically replaces the random hex generating function in
`org-export-get-reference' with a call to a function
`org-reference-contraction' which takes a header and outputs a string
like "some-header-string" and then has digits appended should it be
non-unique (i.e. "some-header-string-2", "some-header-string-3").
For certain recognised blocks (e.g. src and example blocks) it appends
",{block}--{n}", for example: "some-header-string,code--1".
I consider this to be quite a nice improvement.
--
Timothy
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Kyle Meyer writes: > Here are a few notes on ones present in maint that I've glanced at. I confirm that there are no warning using Emacs 25.3.1 on maint. For Emacs 24.5.1, I see that following in addition to what you mentioned: Compiling /home/yantar92/Git/org-mode/lisp/ob-python.el... Compiler-macro error for python-syntax-context: (void-function python-syntax--context-compiler-macro) Compiling /home/yantar92/Git/org-mode/lisp/ob-C.el... In toplevel form: ob-C.el:477:1:Error: Unknown upattern `(quote integerp)'
Re: prettify-symbols-mode in org agenda?
Ihor Radchenko writes:
> Bastien writes:
>
>> Thanks for bringing this idea up.
>>
>> If allowing prettify-symbols-mode in Org agenda mode does not slow
>> down the agenda display and does not create spacing problems, then
>> yes, why not.
>
> Here is the patch. It will be great if other people test it first, as I
> rewrote it from advised functions in my personal config.
Works for me. Thanks!
> (org-agenda-highlight-todo): Preserve composition property used,
> i.e. by `prettify-symbols-mode'.
It looks like this change is not really needed, my emacs is built from
git master. Maybe the 'composition property is now preserved
automatically in the buffer?
-William
> @@ -7110,7 +7119,8 @@ (defun org-agenda-limit-interactively (remove)
> (defun org-agenda-highlight-todo (x)
>(let ((org-done-keywords org-done-keywords-for-agenda)
> (case-fold-search nil)
> - re)
> + re
> +composition-property)
> (if (eq x 'line)
> (save-excursion
> (beginning-of-line 1)
> @@ -7119,10 +7129,12 @@ (defun org-agenda-highlight-todo (x)
> (when (looking-at (concat "[ \t]*\\.*\\(" re "\\) +"))
> (add-text-properties (match-beginning 0) (match-end 1)
>(list 'face (org-get-todo-face 1)))
> - (let ((s (buffer-substring (match-beginning 1) (match-end 1
> +(setq composition-property (plist-get (text-properties-at
> (match-beginning 1)) 'composition))
> + (let ((s (org-buffer-substring-fontified (match-beginning 1)
> (match-end 1
> (delete-region (match-beginning 1) (1- (match-end 0)))
> (goto-char (match-beginning 1))
> - (insert (format org-agenda-todo-keyword-format s)
> + (insert (format org-agenda-todo-keyword-format s))
> + (add-text-properties (match-beginning 1) (match-end 1) (list
> 'composition composition-property)
>(let ((pl (text-property-any 0 (length x) 'org-heading t x)))
> (setq re (get-text-property 0 'org-todo-regexp x))
> (when (and re
Re: wip-cite status question and feedback
On Fri, Apr 30, 2021 at 5:48 PM Denis Maier wrote: > Yes, this should be equivalent to the behaviour in pandoc. > > However, as I've said before, this behaviour is only correct in American > English. Denis and I are working on sorting out the details of how to address this off-list ATM. But I'm tentatively thinking this could be addressed by splitting the MOVE-PUNCTUATION parameter in two, so that we have: MOVE-PUNCTUATION: Move punctuation character following citation before it, when applicable (for example [TODO]). PUNCTUATION-INSIDE-QUOTES: If a quotation mark precedes the citation, move punctuation before it, too, unless [TODO] So for the examples Nicolas posted, this: (org-cite-wrap-citation citation info t) … would change to this: (org-cite-wrap-citation citation info t t) ... and to get the British/German output it would be: (org-cite-wrap-citation citation info t nil) More when we figure out if this is feasible, with example input/output, etc. Bruce
Re: Bug: org-columns does not respect global-visual-line-mode for long text within headlines
Hello, Nick Savage writes: > I'm filing a bug in relation to org-columns and its interactions with > global-visual-line-mode, which I do not think is expected behaviour. > > 1. Start `emacs -Q' > 2. Create /tmp/test.org (or something like this) > 3. Enable M-x global-visual-line-mode > 4. Insert the following (or something like it, the purpose is to have > a line that wraps on your screen with global-visual-line-mode enabled, > you may need to add more characters if necessary) > * test headline > cc > > 5. Collapse headline, activate org-columns (C-c C-x C-c) on the headline. > 6. Toggle visibility of headline, note that the line no longer wraps > and instead acts as if global-visual-line-mode was not enabled. > > I am investigating now but I thought I would post this as a bug > regardless. The trace below is for the release of org-mode with > 28.0.50, but I can confirm that it is the same on the current master. FWIW, I confirm this, too. This has bugged me for a long time now! Regards, -- Nicolas Goaziou
Re: stability of toc links
Hello, Timothy writes: > Nicolas Goaziou writes: > >> With the above in mind, I think there are two ways to "improve TOC links >> stability": >> >> 1. Improve the system behind `org-export-get-reference', e.g., so it >>behaves better during plain export. But please keep in mind that >>current major properties must be preserved. >> >> 2. Use an hybrid system in HTML exporter, much like Texinfo's. >> >> Those two ways are orthogonal; both may solve the current issue >> independently on the other. My gut feeling is the second way is easier >> to achieve, at least on the short term. > > I'm not quite sure what you mean by a hybrid system, As I explained, it is a system where the back-end generates its own references, and relies on `org-export-get-reference' as a robust fall-back system. Have a look at `org-texinfo--get-node' function to see what I mean. > but I think generating informative references based on header content > is a nice improvement that also make links much more stable. I don't think such a system would preserve properties offered by `org-export-get-reference', for example in non-latin languages. Also, header content is not stable enough: when you're linking to the custom ID, you may be able to change the title and yet preserve the link. However, your proposal may be an improvement over `org-export-get-reference' in the context of "ox-html.el", that I don't know. That's the second way I wrote about. Regards, -- Nicolas Goaziou
Separator "::" -> what is it for in headlines?
Why does the separator "::" work with headlines? Example: * Headline with separator :: This would be the description of a list, but what is it here? 2.6 Plain Lists /Description /list items are unordered list items, and contain the separator ‘::’ to distinguish the description term from the description. - Sean Astin :: He plays Sam, Frodo's friend. I still remember him very well from his role as Mikey Walsh in /The Goonies/.
Re: stability of toc links
Nicolas Goaziou writes: > With the above in mind, I think there are two ways to "improve TOC links > stability": > > 1. Improve the system behind `org-export-get-reference', e.g., so it >behaves better during plain export. But please keep in mind that >current major properties must be preserved. > > 2. Use an hybrid system in HTML exporter, much like Texinfo's. > > Those two ways are orthogonal; both may solve the current issue > independently on the other. My gut feeling is the second way is easier > to achieve, at least on the short term. I'm not quite sure what you mean by a hybrid system, but I think generating informative references based on header content is a nice improvement that also make links much more stable. Forgive me if this is an overly simplistic quicktake. -- Timothy.
Re: stability of toc links
Hello, Tim Cross writes: > Given this is not the first time we have seen a similar discussion > regarding link stability for external references, perhaps it would be > good to summarise and put it on worg for reference? > > First attempt - let me know if I've got it close! > [...] > The org publish facility already includes the necessary internal > facilities to support internal link consistency across published > versions. You can use publish to publish a single file. Currently, the > internal links need to be referenced/used in order to ensure consistency > across published versions. This is currently true. > If stability of TOC links across versions is required, using publish is > the preferred mechanism. If we would want to make it easier for the user > to create published pages with consistent internal TOC links, we would > be better off enhancing the publish mechanism rather than trying to add > such facilities to the HTML export function. I would nuance the latter. In a nutshell, Org provides a reference generation mechanism, with the function `org-export-get-reference', which has with some interesting properties. Major ones are: - references consist of alphanumeric characters only, so they are /de facto/ compatible with any target format; - references are guaranteed to be unique in the document; - cross-references between documents are stable. It has obvious drawbacks, as noted already: - references themselves are not informative; - dangling links (i.e., not being cross-referenced) are not stable. So, it was implemented as an adequate fall-back mechanism, one that would not let down export back-end developers. It is clearly not suitable for every need; I don't think such a system exists (but I would love to be wrong). It is important to understand that relying on `org-export-get-reference' is optional, when a better local solution exists. For example, Texinfo exporter relies on that function only as a last resort, and will circumvent it whenever it can. See `org-texinfo--get-node'. With the above in mind, I think there are two ways to "improve TOC links stability": 1. Improve the system behind `org-export-get-reference', e.g., so it behaves better during plain export. But please keep in mind that current major properties must be preserved. 2. Use an hybrid system in HTML exporter, much like Texinfo's. Those two ways are orthogonal; both may solve the current issue independently on the other. My gut feeling is the second way is easier to achieve, at least on the short term. Regards, -- Nicolas Goaziou
Re: prettify-symbols-mode in org agenda?
Bastien writes:
> Thanks for bringing this idea up.
>
> If allowing prettify-symbols-mode in Org agenda mode does not slow
> down the agenda display and does not create spacing problems, then
> yes, why not.
Here is the patch. It will be great if other people test it first, as I
rewrote it from advised functions in my personal config.
Best,
Ihor
>From 787181ac85c75b2a99e3098b066f9086536c4aa6 Mon Sep 17 00:00:00 2001
Message-Id: <787181ac85c75b2a99e3098b066f9086536c4aa6.1619872197.git.yanta...@gmail.com>
From: Ihor Radchenko
Date: Sat, 1 May 2021 20:09:10 +0800
Subject: [PATCH] Make sure that fontification is preserved in agenda
Preserve fontification and composition of headlines and tags in
agenda. If the headlines/tags are not yet fontified when building
agenda, make sure that they are fontified in the original Org mode
buffers first.
In addition, tags alignment is now done pixelwise to avoid alignment
issues with variable-pitch symbols that may appear in fontified Org
mode buffers. The alignment is utilising :align-to specification,
which means that the alignment will be automatically updated as the
agenda buffer is resized.
* lisp/org-macs.el (org-string-width): Refactor old code and add
optional argument to return pixel width. The old code used manual
parsing of text proerpties to find which parts of string are visible.
The new code defers this work to Emacs display engine via
`window-text-pixel-size'. The visibility settings of current buffer
are taken into account.
(org-buffer-substring-fontified): New function getting fontified
substring from current buffer.
* lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
org-agenda-get-deadlines, org-agenda-get-scheduled): Use
org-buffer-substring-fontified to get fontified heading.
(org-agenda-fix-displayed-tags): Fontify tags.
(org-agenda-highlight-todo): Preserve composition property used,
i.e. by `prettify-symbols-mode'.
(org-agenda-align-tags): Use pixel width and (space . :align-to)
'display property to align tags in agenda.
---
lisp/org-agenda.el | 65 +--
lisp/org-macs.el | 108 ++---
2 files changed, 86 insertions(+), 87 deletions(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index bd9d466a6..b7699afa1 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -5562,7 +5562,7 @@ (defun org-agenda-get-todos ()
ts-date-pair (org-agenda-entry-get-agenda-timestamp (point))
ts-date (car ts-date-pair)
ts-date-type (cdr ts-date-pair)
- txt (org-trim (buffer-substring (match-beginning 2) (match-end 0)))
+ txt (org-trim (org-buffer-substring-fontified (match-beginning 2) (match-end 0)))
inherited-tags
(or (eq org-agenda-show-inherited-tags 'always)
(and (listp org-agenda-show-inherited-tags)
@@ -5973,7 +5973,7 @@ (defun org-agenda-get-progress ()
clockp (not (or closedp statep))
state (and statep (match-string 2))
category (org-get-category (match-beginning 0))
- timestr (buffer-substring (match-beginning 0) (point-at-eol)))
+ timestr (org-buffer-substring-fontified (match-beginning 0) (point-at-eol)))
(when (string-match "\\]" timestr)
;; substring should only run to end of time stamp
(setq rest (substring timestr (match-end 0))
@@ -6254,7 +6254,7 @@ (defun org-agenda-get-deadlines ( with-hour)
(let* ((category (org-get-category))
(level (make-string (org-reduced-level (org-outline-level))
?\s))
- (head (buffer-substring (point) (line-end-position)))
+ (head (org-buffer-substring-fontified (point) (line-end-position)))
(inherited-tags
(or (eq org-agenda-show-inherited-tags 'always)
(and (listp org-agenda-show-inherited-tags)
@@ -6469,7 +6469,7 @@ (defun org-agenda-get-scheduled ( deadlines with-hour)
(tags (org-get-tags nil (not inherited-tags)))
(level (make-string (org-reduced-level (org-outline-level))
?\s))
- (head (buffer-substring (point) (line-end-position)))
+ (head (org-buffer-substring-fontified (point) (line-end-position)))
(time
(cond
;; No time of day designation if it is only a
@@ -6856,6 +6856,15 @@ (defun org-agenda-fix-displayed-tags (txt tags add-inherited hide-re)
x))
tags ":")
(if have-i "::" ":"))
+ (let ((tag-string (when (string-match org-tag-group-re txt)
+ (match-string 0 txt
+(when tag-string
+ (with-temp-buffer
+(save-match-data
+ (let ((org-inhibit-startup t)) (org-mode))
+ (insert "* X" tag-string)
+ (font-lock-ensure))
+(setf (substring txt (match-beginning 0) (match-end 0)) (buffer-substring 4 (point-max))
txt)
(defvar org-agenda-sorting-strategy) ;; because the def is in a let form
@@ -7110,7 +7119,8 @@ (defun org-agenda-limit-interactively (remove)
(defun org-agenda-highlight-todo (x)
(let
Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
Hi Bastien, Thank you very much again for your kind suggestions. Bastien writes: > I'm copying Eric, a poweruser of the LaTeX backend, so that he can > perhaps comment on the general usefulness of this addition. I think these additions (line numbers, optical centering of the poem, etc.) can be useful (IMHO) for the correct representation of poetry (generally in Humanities), since the verse.sty package is a sort of 'unofficial' replacement for the standard LaTeX verse environment, which has certain limitations. > The patch lacks a commit message - see this explanations: > https://orgmode.org/worg/org-contribute.html#commit-messages Sorry again for not including a commit message. If the patch it is finally accepted, I can submit a new version that includes a commit message (and a few minor fixes I made to the code). Best regards, Juan Manuel
Re: [PATCH] Babel: remove LaTeX environment -type #+results
Bastien writes: > Applied in master as commit b90b850ae. > > Can you add a etc/ORG-NEWS entry for this? Great! News entry added. -- Timothy
Re: [PATCH] org-capture.el: Add new capture template option :refile-to
Hi Richard, thanks for this addition! I think ":refile-targets" is more straightforward. I applied your patch with this change and a slightly modified commit message. Also, I documented this in the manual and added an entry to etc/ORG-NEWS. Thanks! -- Bastien
Re: wip-cite status question and feedback
Hello, Denis Maier writes: > However, as I've said before, this behaviour is only correct in > American English. TO quuote the Chicago Manual of Style 6.9: "In an > alternative system, sometimes called British Style (as described in > the /New Oxford Style Manual ...) ... only those punctuation points > that appeared in the original material are included within the > quotation marks." The same would be correct for German. Do you have an > idea if/how this could be implemented? This punctuation dance is done through an optional argument in `org-cite-wrap-citation' (off by default). It is up to the citation processors to activate it, according to their own rules, e.g., after checking "language" keyword with (plist-get info :language) or simply by letting users decide what to do through a defcustom. I don't think we can do more in that area. > Again the Chicago Manual, 6.10: "Colons and semicolons---unlike > periods and commas---follow closing quotation marks; question marks > and exclamation points follow closing quoation marks unless they > belong within the quoted matter." I understand colons and semicolons should not move within the quote. But should they be moved before the note? I.e., should the following happen ... foo" [cite:@a]; =>... foo";[1] or should it be? ... foo" [cite:@a]; =>... foo"[1]; IIUC, commas should also be moved within the quotes: ... foo" [cite:@a], =>... foo,"[1] Am I correct? Concerning question marks and exclamation points, I assume we can safely consider that if they belong to the quoted matter, they are already included in the quotes. So the only case left to consider is the following: ... foo" [cite:@a]? =>... foo"?[1] Is that right? > I don't know if there is a general rule and how much of this should be > configurable. How costly would that be? I'd like to avoid any configuration variable in "oc.el", which is only meant to be as the toolbox for processor developers. However, if required, configuration would happen through an optional argument, possibly the same as the one activating the punctuation dance. I.e., when non-nil, it can only provide a list of punctuation characters to consider moving around, with rules explaining if they should be included in a preceding quote. Since this would be backward compatible, we don't need to implement it for now if the use-case is, at this point, purely hypothetical. Thank you for the feedback! Regards, -- Nicolas Goaziou
Re: [PATCH] LaTeX export: arbitrary float environments
Hi Thomas, On the surface, this looks reasonable to me :) Just commenting on some technicalities with the patch itself: - In ORG-NEWS it would be good to wrap the content over multiple lines instead of having a single 270 char line :) - You seem to have an anomalous change to the ob-python :return entry - I don't think your patch subject follows the convention for Org, it should be: "main file/feature: overall change summary" so, something like "ox-latex: allow for arbitrary float environments" rather than "LaTeX export: arbitrary float environments" Thanks for the patch :) Timothy
Re: [PATCH] Babel: remove LaTeX environment -type #+results
Hi Timothy, Timothy writes: > I think there's potential for some really nice experiences leveraging > Org's latex rendering in combination with some languages' symbolic maths > ability. Applied in master as commit b90b850ae. Can you add a etc/ORG-NEWS entry for this? -- Bastien
Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
Hi Juan, Sorry it's still taking a while for your patch to be looked at. Assuming it does get merged, it would be good to check if you'd be willing to write a manual entry to accompany this (in a separate patch works). Thanks again for the patch, Timothy. Juan Manuel Macías writes:
Re: [PATCH] org-src.el Do not ask to revert unmodified buffers
Timothy writes: > Hi pillule, should we consider this patch cancelled? It is already :) -- Bastien
Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
Hi Juan, Juan Manuel Macías writes: > I am attaching a new version of my patch for adding LaTeX attributes to > verse blocks. Following the kind suggestions from Timothy, I have also > documented this new features that I propose. I don't know if I have done > it correctly and in the right place... thanks a lot -- we need to wait for the FSF copyright assignment process to be finished in order to accept this patch. I'm copying Eric, a poweruser of the LaTeX backend, so that he can perhaps comment on the general usefulness of this addition. The patch lacks a commit message - see this explanations: https://orgmode.org/worg/org-contribute.html#commit-messages Let us know if you need more directions and how to produce a patch that we can more easily apply. Thanks! -- Bastien
Re: [PATCH] org-src.el Do not ask to revert unmodified buffers
Hi pillule, should we consider this patch cancelled? pillule writes: > You are right I clearly missed org-src-ask-before-returning-to-edit-buffer > Don't know how . . . > > Sorry for the noise.
Re: [PATCH] ob-plantuml: Add PlantUML block post-processing.
Hi Nick, Nick Daly writes: > +(org-babel-plantuml-post-process out-file) Note that I had to remove the line above from your second patch. Can you confirm it is not necessary for your second patch to work? Thanks, -- Bastien
Re: [PATCH] org-agenda.el: Add a M-, binding for org-priority-show
Hi Kyle and Adam, Kyle Meyer writes: > With a C-u, org-agenda-priority calls org-priority-show. So perhaps > instead of adding a new binding, the documentation should be improved. I pushed a small enhancement for org-agenda-priority's docstring with commit e080eb759. I am reluctant adding another keybinding to the agenda especially since there is no keybinding for `org-priority-show'. Thanks, -- Bastien
Re: [PATCH] ob-sql: blocks without :engine get stuck in org-edit-src-code on indent
Hi Ivan, thanks for the explanations. I applied your patch in maint with commit 45ca597f9, adding a commit message to it. See https://orgmode.org/worg/org-contribute.html#commit-messages Thanks, -- Bastien
Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing
Hi Emily, thanks for the patch and sorry to reactivate this old thread. Did you find time to make the tests and, perhaps, to update the patch? Please let us know - thanks! -- Bastien
Re: [PATCH] Possibility of using alternative separators in macros
Nicolas Goaziou writes: > So, again, I'm not saying we should do this. TBH, I'm not convinced by > the idea of duplicate syntax (comma-escaping and alternate characters) > for the same thing. But hard-core macro users may have a word to say > about it. FWIW I'm not convinced too but I'd also love to hear from other macro users here, and I'll definitely follow your call here. -- Bastien
Re: [PATCH] Possibility of using alternative separators in macros
Nicolas Goaziou writes: > So, maybe it is a bit early to close it. Okay, thanks for the heads up, I'm reopening then. -- Bastien
Re: [PATCH] org-protocol: Make org protocol defaults work on windows
Hi, Maxim Nikulin writes: > On 20/11/2020 23:26, Robert wrote: >> Attached a little patch to make the default org-protocol >> handlers work on windows. > > Unsure, but the issue might be addressed by the following change: > https://code.orgmode.org/bzg/org-mode/commit/928e67df > org-protocol: Allow slashes after sub-protocol I'm optimistically closing this patch. If the OP confirmes it is still needed and Maxim confirms it is correct, we can apply a new one. Thanks, -- Bastien
Re: [PATCH] Possibility of using alternative separators in macros
Hello,
Bastien writes:
> thank you for the patch. I understand the general idea, but I think
> we should be careful not to overload the macro syntax - escaping the
> coma seems okay to me. I'm closing this suggestion.
>
> I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of
> course insist on rejecting it.
This is a followup to a previous discussion in this mailing list, in
which Juan Manuel explained his use-case for a different argument
separator in macros. I noticed then that there was an opening for
a backward compatible syntax extension for it. As I was also not certain
it would be a good idea overall, I suggested him to start a new, more
visible, thread with the proposal, and collect feedback.
So, maybe it is a bit early to close it.
BTW, I would like to amend the proposed syntax, so as to limit friction
with the rest of Org. What would be more reasonable is the following:
{{{macroname·(...)}}}
where · is either nothing or a _single_ printable non-alphanumeric
non-space non-parenthesis character that isn't already meaningful in
Org. For example, if for some reason, we limit ourselves to ASCII
characters only, the set of allowed separators would be:
! % & , ; ? `
So, again, I'm not saying we should do this. TBH, I'm not convinced by
the idea of duplicate syntax (comma-escaping and alternate characters)
for the same thing. But hard-core macro users may have a word to say
about it.
WDYT?
Regards,
--
Nicolas Goaziou
Re: [PATCH] Add font-lock rule for inline export snippets
Hi Timothy, Timothy writes: > The latest in my visually-oriented (mostly) short patch series, adding > basic fontification to inline export snippets --- @@comment:these > things@@. Applied in master with commit eef9027c, thanks! I also added a note in etc/ORG-NEWS. -- Bastien
Re: [PATCH] fix point position shifting in some org-src instances
Applied in maint as commit 400d2d9fd, with a minor modification of the commit message. Thanks! -- Bastien
Re: [PATCH] org-clock.el: clocktable ':formula %' now includes per-file time pct
Hi Alan, applied in master as commit 9aa9f3b1f. Thanks you very much! Can you announce this by providing a patch for etc/ORG-NEWS? -- Bastien
Re: Emacs Lisp book (was: Step by step tutorial on Worg on how to create a new export backend)
On 2021-05-01, at 10:37, Timothy wrote: > Marcin Borkowski writes: > >> Surprise, surprise! >> >> The book is out! >> >> Before you get too excited - it's not complete yet. I published a draft >> on Leanpub, which is a platform for publishing (and selling) books in >> progress. I plan to finish it by September, but if you want to take >> a peek, here is a coupon code for you to get it for free (the coupon is >> valid for a week)! >> >> https://leanpub.com/hacking-your-way-emacs/c/f23s5unGtLf0 >> >> Best, > > Interesting. I wanted to take a peek but I can't see how to view it for > free ... I may be blind though. Sorry, my email was meant as a private message to Jean-Christophe. Sorry for the noise. You can get a free sample on https://leanpub.com/hacking-your-way-emacs - it's the introduction and the first chapter. Best, -- Marcin Borkowski http://mbork.pl
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
Hi Anthony, Anthony Carrico writes: > The original implementation flip-flops between cached and normal > classes (six statements removed in the original patch), whereas my > clone adds and removes a class name from the classList (three > statements inserted in the original patch). Thanks - I replayed this change with commit dcd7b576b in maint. > I did intend to make a > material change which would create a new public domain implementation > of the original API. I did not intended to disrespect Carsten's work > or to detract from it, and I apologize to anyone who did not consider > it to be a good-faith gesture. I did honestly believe that the > org-mode code base would welcome a public domain clone of the script > functionality to resolve the issue at hand. Absolutely no need to apologize here! Sorry if my message was read as a reproach, it was definitely not. > I did offer an opinion on license insertion: My opinion is that > org-export is a means to save an org-mode file in html format, and > that org-mode authors don't view their documents as derivative works > of the org-export markup. I still believe inserting a license into > exported documents is a mistake. FWIW I also think inserting Javascript in HTML export is wrong. Commit bb24248b8 turns `org-html-head-include-scripts' to nil by default, I advertized the change in etc/ORG-NEWS. > Bastien: You certainly have my permission to use my > CodeHighlightOn/CodeHighlightOff implementation as you see fit, > including licensing it under the GPLv3+ Done, thanks for explicitely permitting this. In general, I tend to agree that we should get rid of this small Javascript snippet and that the feature provided is not critical, but let's keep it until someone shows that he can reactivate it with some existing Javascript library. Thanks, -- Bastien
Re: [PATCH] ob-plantuml: Add PlantUML block post-processing.
Hi Nick, Nick Daly writes: > Nick Daly writes: > >> Please see the attached patch that allows for post-processing of >> PlantUML diagrams based on the exported file extension. > > If the above patch was too generic and heavy-weight for consideration, > please see this alternative, simpler, patch. It just adds a flag that, > when enabled, runs for SVG images exported via PlantUML. Yes, I think the smallest change here is better, we'll see if others want to the bigger one later on. Applied as commit 7da20ff21, with some small modifications, thanks. -- Bastien
Re: [PATCH] Have C-c C-c recognise #+plot lines
Eric S Fraga writes: > On Saturday, 1 May 2021 at 08:56, Bastien wrote: >> I have fixed this with commit ee507de47, can you confirm? > > Seems to work just fine now. Thank you. Thanks for confirming! -- Bastien
Re: bug#47820: [PATCH] org-table-import: Give option to import interactively even if filename doesn't match
Hi Utkarsh, Utkarsh Singh writes: > Can we give small flexibility in choosing the filename interactively for > `org-table-import'? Currently org-table-import will just throw an error > when file name doesn't have .txt, .csv or .tsv as extension. Applied in master as commit 7c99d1555, thanks. Please see the commit changelog for future patches: https://code.orgmode.org/bzg/org-mode/commit/7c99d1555 Also https://orgmode.org/worg/org-contribute.html#commit-messages give more detailed directions. Thanks, -- Bastien
Re: could a :var header argument refer to a data table in another file?
On Saturday, 1 May 2021 at 07:58, Michael Welle wrote: > I smell something strange going on here ;). Synchronicity, aka great minds think alike. :-) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-405-g0a689b
Re: [PATCH] Have C-c C-c recognise #+plot lines
Hi Bastien, On Saturday, 1 May 2021 at 08:56, Bastien wrote: > I have fixed this with commit ee507de47, can you confirm? Seems to work just fine now. Thank you. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-405-g0a689b
Re: Emacs Lisp book (was: Step by step tutorial on Worg on how to create a new export backend)
Marcin Borkowski writes: > Surprise, surprise! > > The book is out! > > Before you get too excited - it's not complete yet. I published a draft > on Leanpub, which is a platform for publishing (and selling) books in > progress. I plan to finish it by September, but if you want to take > a peek, here is a coupon code for you to get it for free (the coupon is > valid for a week)! > > https://leanpub.com/hacking-your-way-emacs/c/f23s5unGtLf0 > > Best, Interesting. I wanted to take a peek but I can't see how to view it for free ... I may be blind though. -- Timothy
Re: [PATCH] Possibility of using alternative separators in macros
Hi Juan, thank you for the patch. I understand the general idea, but I think we should be careful not to overload the macro syntax - escaping the coma seems okay to me. I'm closing this suggestion. I'm cc'ing Nicolas: if he thinks it's a useful addition, I won't of course insist on rejecting it. Thanks, -- Bastien
Emacs Lisp book (was: Step by step tutorial on Worg on how to create a new export backend)
On 2020-02-16, at 01:46, Jean-Christophe Helary wrote: > Aren't you supposed to write a book about Emacs already ? ;) Surprise, surprise! The book is out! Before you get too excited - it's not complete yet. I published a draft on Leanpub, which is a platform for publishing (and selling) books in progress. I plan to finish it by September, but if you want to take a peek, here is a coupon code for you to get it for free (the coupon is valid for a week)! https://leanpub.com/hacking-your-way-emacs/c/f23s5unGtLf0 Best, -- Marcin Borkowski http://mbork.pl
Re: [PATCH] Have C-c C-c recognise #+plot lines
Hi Eric, Eric S Fraga writes: > On Thursday, 29 Apr 2021 at 02:04, Timothy wrote: >> Have you had a chance to test this out? > > Further on this, I don't have time to debug right now but the patch > seems to have broken org table recalculation, specifically C-u C-c C-c > on a table. I have fixed this with commit ee507de47, can you confirm? Thanks, -- Bastien
