[O] Bug: org-babel-tangle-clean seems buggy [9.2.5 (release_9.2.5-504-g3c24be @ /home/immanuel/.emacs.d/straight/build/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. When running 'org-babel-tangle-clean on this buffer: >> [[file:foo][something]] <> [[file:bar][something else]] <> >> I get >> <> >> Given the code of that function -- especially the (while (or -- it's highly unlikely that that code does what the docstring says it does. I'm also not clear on why you'd want to remove noweb references. #+BEGIN_SRC emacs-lisp (defun org-babel-tangle-clean () "Remove comments inserted by `org-babel-tangle'. Call this function inside of a source-code file generated by `org-babel-tangle' to remove all comments inserted automatically by `org-babel-tangle'. Warning, this comment removes any lines containing constructs which resemble Org file links or noweb references." (interactive) (goto-char (point-min)) (while (or (re-search-forward "\\[\\[file:.*\\]\\[.*\\]\\]" nil t) (re-search-forward (org-babel-noweb-wrap) nil t)) (delete-region (save-excursion (beginning-of-line 1) (point)) (save-excursion (end-of-line 1) (forward-char 1) (point) #END_SRC Immanuel Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-07-17 Package: Org mode version 9.2.5 (release_9.2.5-504-g3c24be @ /home/immanuel/.emacs.d/straight/build/org/) current state: == (setq org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-link-shell-confirm-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-html-format-inlinetask-function 'org-html-format-inlinetask-default-function org-odt-format-headline-function 'org-odt-format-headline-default-function org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default org-mode-hook '((closure (org-agenda-skip-regexp org-table1-hline-regexp org-table-tab-recognizes-table\.el org-table-dataline-regexp org-table-any-border-regexp org-agenda-restriction-lock-overlay org-agenda-overriding-restriction org-agenda-diary-file org-complex-heading-regexp calendar-mode-map t) nil (setq imenu-create-index-function (quote org-imenu-get-tree))) (closure (org--rds reftex-docstruct-symbol org-element-greater-elements org-clock-history org-agenda-current-date org-with-time org-defdecode org-def org-read-date-inactive org-ans2 org-ans1 org-columns-current-fmt-compiled org-clock-current-task org-clock-effort org-agenda-skip-function org-agenda-skip-comment-trees org-agenda-archives-mode org-end-time-was-given org-time-was-given org-log-note-extra org-log-note-purpose org-log-post-message org-last-inserted-timestamp org-last-changed-timestamp org-entry-property-inherited-from org-blocked-by-checkboxes org-state org-agenda-headline-snapshot-before-repeat org-capture-last-stored-marker org-agenda-start-on-weekday org-agenda-buffer-tmp-name org-priority-regexp org-mode-abbrev-table org-mode-syntax-table buffer-face-mode-face org-tbl-menu org-org-menu org-struct-menu org-entities org-last-state org-id-track-globally org-clock-start-time texmathp-why remember-data-file org-agenda-tags-todo-honor-ignore-options iswitchb-temp-buflist align-mode-rules-list org-emphasis-alist org-emphasis-regexp-components org-export-registered-backends org-modules org-babel-load-languages org-indent-indentation-per-level org-element-paragraph-separate ffap-url-regexp org-inlinetask-min-level t) nil (add-hook (quote change-major-mode-hook) (quote org-show-all) (quote append) (quote local))) (closure (org-src-window-setup *this* org-babel-confirm-evaluate-answer-no org-src-preserve-indentation org-src-lang-modes org-link-file-path-type org-edit-src-content-indentation org-babel-library-of-babel t) nil (add-hook (quote change-major-mode-hook) (quote org-babel-show-result-all) (quote append) (quote local))) org-babel-result-hide-spec org-babel-hide-all-hashes auto-fill-mode) org-odt-format-drawer-function '(closure (hfy-user-sheet-assoc hfy-html-quote-regex hfy-html-quote-map hfy-face-to-css hfy-begin-span-handler hfy-end-span-handler archive-zip-extract nxml-auto-insert-xml-declaration-flag t) (_name contents) contents) org-archive-hook '(org-attach-archive-delete-maybe)
Re: [O] org-megaup
Thank you Nick for the help. It looks like I some kind of interference between the built-in org-mode and the most recent package available in melpa. Everything is fixed now. > On Aug 31, 2019, at 4:42, Nick Dokos wrote: > > Jean-Christophe Helary writes: > >> When I use org-megaup I get a "Invalid function: >> org-preserve-local-variables" is there a way to fix that ? >> > > org-megaup is not defined AFAICT - do you mean `org-metaup'? > > If not, disregard the rest of this message. > > If yes, I don't see any problems, so you might want to provide the > context (e.g. are trying to move subtrees up, move table rows up or > move items in a list up?) Check also the value of `org-metaup-hook' to > see if something weird crept in there. > > If it happens regardless of context, I would edebug the org-metaup > function and see where the error message comes from - BTW, > org-preserve-local-variables is a macro, not a function (so that might > have something to do with it), defined in org-macs.el. If your setup > is curdled, that might not be loaded, so try `(load-library org-macs)` > and see if that resolves if: if it does, then you have to figure out > whether there is something wrong with your setup (if it doesn't load > that file automatically) or how it got curdled (if it does). > > -- > Nick > > "There are only two hard problems in computer science: cache > invalidation, naming things, and off-by-one errors." -Martin Fowler > > Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune
Re: [O] Bug: tangling with elisp as lang in a noweb reference doesn't work [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/local/share/emacs/26.2/lisp/org/)]
No problem! I have some more coming up :-) I've been looking at getting org-babel to add line directives for languages that support it. (c, c++, haskell...). It would make literate programming for these kinds of languages much better, and other people have been complaining e.g. https://paulbatchelor.github.io/blog/posts/2018-09-21-org-babel-impressions.html Unfortunately there is no easy way to hook this into org-babel now without doing some rather intrusive work. 1) The language specific expansions don't know the file or the line a block comes from, and noweb references have already been expanded. 2) The tangle-body-hook is useless since it runs in a temp buffer that doesn't even have the major mode set for the language you're tangling to. 3) The :comments mechanism is not strong enough to allow language specific comments and it 's different for noweb vs. normal block expansion. Would there be interest in such a feature, if it doesn't change current behaviour? Immanuel On Fri, Aug 30, 2019 at 11:37 PM Nicolas Goaziou wrote: > > Hello, > > immanuel writes: > > > #+NAME: this is a test > > #+BEGIN_SRC elisp :tangle no > > > > (message \"aha\") #+END_SRC > > > > #+BEGIN_SRC elisp :noweb yes :comments noweb :tangle out.el > > first > > <> > > second > > #+END_SRC > > > > #+BEGIN_SRC elisp :tangle no > > (progn > > (org-babel-tangle) > > (with-temp-buffer > > (insert-file-contents "out.el") > > (buffer-string) > > #+END_SRC > > > > > > Doesn't work. The reason is that the function > > org-babel-expand-noweb-references uses > > > > #+BEGIN_SRC emacs-lisp > > (c-wrap (lambda (text) > > (with-temp-buffer > > (funcall (intern (concat lang "-mode"))) > > ... > > #+END_SRC > > Fixed! Thank you for the report and the analysis. > > Regards, > > -- > Nicolas Goaziou
Re: [O] org-id fixups and minor changes
Hi Carsten, Yeah – you’re right, I didn’t think that much about automated ID creation so I stopped at seconds. I agree that it would be more general with more precision but that will also add some more noise into each ID. Maybe that’s not significant. But I also wonder how common it will be to try to batch-add ID’s…? I have nothing against adding more precision though, if that’s requested. What do you think? Regarding documentation I’ll try to give it some thought. Maybe I’ll find some time to describe this area better . I wouldn’t mind changing the default from random to timestamp. But I’m not so sure about all the others? One thing that complicates things is the way attachment functionality parse the ID. If we use timestamps as the default ID it makes sense to change the default way org-attach parses the ID into folders as well. Something like “/MM/DD_and_the_rest”. But that will be a breaking changing. The existing folder-structure for attachments wouldn’t match the new any longer. Cleverness in code might solve the breakage though… If there is interest in changing the default I can try to solve the issue with the breaking change as well. Regards Gustav From: Carsten Dominik Sent: den 10 augusti 2019 00:34 To: Gustav Wikström Cc: emacs-orgmode@gnu.org Subject: Re: [O] org-id fixups and minor changes Hi Gustav, I can see that it feels more natural to use timestamps. I certainly see that relative file names are good for across-computer compatibility. You system assumes, if I see that correctly (have not studied it yet), that not more that one ID will be created per second. Or do you have something in place that will catch this, for example if someone uses the mapping API to assign IDs to a whole bunch of entries in a short time? You are right that this is not documented in the manual, even though it is used for lings and for attachments. Maybe it would be good to explain it in an appendix to the manual? Would you like to draft such a section, since you have been looking into this problem? Do you think the default setting for Org should be modified? Carsten On Fri, Aug 2, 2019 at 5:14 PM Gustav Wikström mailto:gus...@whil.se>> wrote: Hi! I've pushed a couple of fixes and changes to master related to org-id. First; a fix and a (major) speedup and method-change for how the global caching works for ID's. The change in method is that providing file's as arguments to org-id-update-id-locations no longer breaks the existing id locations. Second; I've added a customization so one can choose to cache the id-locations as relative to the org-id-locations-file instead of as absolute links. This helps a lot when running a system mirrored on multiple machines where the absolute paths to ones documents might differ, but where it's all the same relative to the org-id-locations-file. Third; I've added another ID generator method. The extremists might say the new method is not unique enough but org-mode is a personal system first and foremost, so I think there is merit to this new ID method. It creates ID's based on current timestamp and doesn't try to hide the timestamp from the user. One might call the ID's "natural" since they are contain information in themselves. Certainly a good thing for some. The new method will not be active unless explicitly chosen by the user. As a side note, if using ID's together with attachments, try this new ID-generator out by setting org-id-method to ts (short for timestamp) and change the org-attach-id-to-path-function to something like "/MM/DDTHHMMSS" for more human readable attachment folders. Org-id is next to undocumented in the manual so I didn't find a good place to add this. A few lines are added to org-news though. This is the first push by me without first doing an RFC. So, naturally, if anything is out of order mail back and/or make changes directly in the repo if needed. Tests passed anyways. Kind regards Gustav
[O] Strange interaction between ID block property, org-schedule and ical/ics export backend
Hi,
I'm starting using org-mode to replace asana, clickup, and other tools to manage
my work.
I'm trying to create a day-to-day workflow with org-mode, org-agenda Schedule
and iCalendat-export backend.
1) What exactly did you do
After creating a new entry, i run (org-id-get-create) to get a permanent ID
properties :
* Heading 1
:PROPERTIES:
:ID: xxx
:END:
foo
2) what did you expect to happen
I run org-schedule (c-c c-s), choosing a date, and Schedule date is added AFTER
block of property.
* Heading 1
:PROPERTIES:
:ID: xxx
:END:
foo
SCHEDULED <...--...>
3) What happened instead
Scheduled block is added between the HEADING and the property block...
* Heading 1
SCHEDULED <...--...>
:PROPERTIES:
:ID: xxx
:END:
foo
4) Problem with icalendar export ?
Normally org-caldav-generate-ics export command reuse the ID from property block
to generate the *.ics,
but it only works if the SCHEDULED block is after the property block.
So in this case, icalendar export generate a new UID, and don't consider the ID
which already exist.
--
Sébastien Rey-Coyrehourcq
Research Engineer UMR IDEES
02.35.14.69.30
{Stronger security for your email, follow EFF tutorial : https://ssd.eff.org/}
signature.asc
Description: This is a digitally signed message part
[O] [RFC] Org document concept + document property drawers
Hi! I'm continuing on my proposal to introduce a "document" element in org-mode and the idea of seeing everything before the first headline as the base level 0 outline for a file. I've attached two patches that I'd like some public review of before pushing to master. Patch 0001 introduces the document element into org-element.el, and some restructuring related to that. Patch 0002 makes it possible to use property drawers at the document level. I've hopefully covered all related commands to make this work. And I've added a bunch of tests to guard against future regressions. Waiting for your comments! Kind regards Gustav 0001-New-top-level-document-concept-and-minor-restructure.patch Description: 0001-New-top-level-document-concept-and-minor-restructure.patch 0002-Org-document-property-drawers.patch Description: 0002-Org-document-property-drawers.patch
Re: [O] [RFC] Org document concept + document property drawers
Gustav Wikström writes: > I'm continuing on my proposal to introduce a "document" element in > org-mode and the idea of seeing everything before the first headline > as the base level 0 outline for a file. I've attached two patches that > I'd like some public review of before pushing to master. > > Patch 0001 introduces the document element into org-element.el, and > some restructuring related to that. > > Patch 0002 makes it possible to use property drawers at the document > level. I've hopefully covered all related commands to make this work. > And I've added a bunch of tests to guard against future regressions. > > Waiting for your comments! This is a very interesting idea, and I don't want to dismiss your work, but I am concerned about how much third-party code will likely break by changing the results returned by org-element for parsing an Org buffer. I haven't thoroughly studied all of the code in your patches, so I may be wrong, but I think the breakage could be extensive. For example, simple operations like destructuring the results of org-element parsing functions may be broken. Have you done any investigation into this issue? Maybe there should be a transitional period in which the existing org-element parsing functions would work as before, and the new document-level elements would be returned by a new org-element document-level parsing function. Frankly, if there is breakage,the transition would probably take a few years, because there is a lot of code out there that has worked for years and may not be updated or replaced for years.
Re: [O] org-id fixups and minor changes
Gustav Wikström writes: > Yeah – you’re right, I didn’t think that much about automated ID > creation so I stopped at seconds. I agree that it would be more > general with more precision but that will also add some more noise > into each ID. Maybe that’s not significant. But I also wonder how > common it will be to try to batch-add ID’s…? I have nothing against > adding more precision though, if that’s requested. What do you think? For any one user, it probably won't cause a problem. But remember that Org is used by many people. If you add a method that can cause ID conflicts, it's inevitable that it will happen to someone eventually. It would be best to avoid conflicts in the first place. > I wouldn’t mind changing the default from random to timestamp. But I’m > not so sure about all the others? Please don't change the default, because the default works, and has for years. > One thing that complicates things is the way attachment functionality > parse the ID. If we use timestamps as the default ID it makes sense to > change the default way org-attach parses the ID into folders as > well. Something like “/MM/DD_and_the_rest”. But that will be a > breaking changing. The existing folder-structure for attachments > wouldn’t match the new any longer. Cleverness in code might solve the > breakage though… If there is interest in changing the default I can > try to solve the issue with the breaking change as well. Especially, please do not make a change like this. Attempted cleverness such as that should be avoided, because, considering how many users use Org, each with their own customizations and unique workflows, it's inevitable that such a change will lead to lost (or misplaced) data for some users. As a completely optional feature, it could be useful, however it would need to cope with both storage formats, because existing users would likely have data stored in the old locations when they enable the feature. Consider as well that more third-party software which uses Org formats is becoming popular, including non-Emacs software. Changes like these are much more likely to cause breakage and incompatibilities. For example, software like Orgzly and org-web are not yet even fully compatible with all of Org, but they make Org formats useful on platforms which are hard to use Emacs on. I think we should try not to make the work of those authors more difficult by making Org hard to keep up with. :)
Re: [O] Oas: a small addon to Org Mode to automatically close tasks with statistics
Hi Andrea, This is a nice idea. Here are a few notes: 1. You should implement it as a minor mode, and enable/disable the hooks there. 2. I would generally recommend using org-element to help with parsing. It will make your code much cleaner and easier to understand. Much of the searching code you currently have is unidiomatic and hard to follow, and org-element will help with that. 3. Avoid using hard-coded to-do keywords, because users may be using custom ones. Instead, use the variables and functions provided by Org that are related to to-do keywords. Use tools like apropos, Helm, or Counsel, or the Org source code, to help discover them.
