[O] dynamic block :block thismonth seems not correct
I have this two dynamic block: ``` ** REPEAT Weekly Org-Agenda Review :fragment: SCHEDULED: <2018-11-03 Sat .+1w> :PROPERTIES: :LAST_REPEAT: [2018-10-27 Sat 16:09] :END: :LOGBOOK: - State "DONE" from "REPEAT" [2018-10-27 Sat 16:09] - State "DONE" from "REPEAT" [2018-10-04 Thu 18:10] - State "DONE" from "REPEAT" [2018-05-23 Wed 12:49] - State "DONE" from "REPEAT" [2018-05-03 Thu 18:53] - State "DONE" from "REPEAT" [2018-02-19 Mon 20:24] - State "DONE" from "REPEAT" [2018-01-26 Fri 19:15] - State "DONE" from "REPEAT" [2018-01-13 Sat 10:23] :END: #+BEGIN: clocktable :maxlevel 5 :scope agenda-with-archives :block thisweek :fileskip0 t :indent t #+CAPTION: Clock summary at [2018-11-02 Fri 14:17], for week 2018-W44. | File | Headline |Time | | | |+--+-+---+--| || ALL *Total time* | *1d 6:43* | | | |+--+-+---+--| | Computer Todos.org | *File time* | ** | | | || Computer Todos [8/24] |0:07 | | | || \_ Setup database for Backup Disk... | | 0:07 | | || Downloads [6/62] |1:24 | | | || \_ Download E-Book [2/36] | | 1:24 | | || \_record to Org all issues "OFFLINE" 离线... | | | 1:24 | |+--+-+---+--| | Code.org | *File time* | ** | | | || Config [15/42] |0:12 | | | || \_ Firefox can't input Chinese [3/3] | | 0:12 | | || Code [20/69] |0:59 | | | || \_ parse my accounting (随手记) data [11/21]| | 0:59 | | || Issues [14/49] | 1d 1:31 | | | || \_ Org export to iPad Clojure... | | 23:20 | | || \_ox-epub export inline image error [1/1] | | | 2:28 | || \_ox-epub exported source block has big... | | | 4:51 | || \_ Elpy can't get code completion on... | | 0:05 | | || \_ hl-sexp is disabled when in Edebug [7/8] | | 0:02 | | || \_ org coderef does not support use file... | | 2:00 | | || \_ Conky invalid file or directory [7/8] | | 0:04 | | || Features [30/138] |0:07 | | | || \_ company-sclang: configure sclang for... | | 0:07 | | |+--+-+---+--| | Learn Programming Plan.org | *File time* | ** | | | || Crack |2:23 | | | || \_ Reverse Engineering [0/0] | | 2:23 | | || \_Binary/Hex Editor parsing binary file... | | | 2:23 | #+END: ** REPEAT Monthly Org-Agenda Review SCHEDULED: <2018-11-04 Sun .+1m> :PROPERTIES: :LAST_REPEAT: [2018-10-04 Thu 18:10] :END: :LOGBOOK: - State "DONE" from "REPEAT" [2018-10-04 Thu 18:10] - State "DONE" from "REPEAT" [2018-05-04 Fri 11:38] - State "DONE" from "REPEAT" [2018-02-19 Mon 20:28] - State "REPEAT" from "TODO" [2017-12-21 Thu 15:29] - State "DONE" from "REPEAT" [2017-12-02 Sat 21:01] :END: #+BEGIN: clocktable :maxlevel 5 :scope agenda-with-archives :block thismonth :fileskip0 t :indent t #+CAPTION: Clock summary at [2018-11-02 Fri 14:41], for November 2018. | File | Headline | Time | | | |--++--+--+--| |
Re: [O] Display-level automatic subtree numbering
NICOLAS> As I was offline for a few days, I toyed a bit with this. I NICOLAS> wrote the following library. I didn't test it thoroughly. I NICOLAS> didn't write regression tests either. ERIC> Although I probably won't use this often, I have tried it out ERIC> and it seems to work very well. I've only tried a couple of ERIC> articles where numbering makes some sense. Looks good too. +1 for releasing the org-num.el lib. Ciao, Marco
Re: [O] Bug: Capture template insertion fails with #+FOO [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/phil/.emacs.d/elpa/org-9.1.14/)]
On Fri, 2 Nov 2018 at 01:35, Nicolas Goaziou wrote: > > Philip Hudson writes: > > > Here's a minimal failing capture-completed template: > > > > --- Cut here -- > > > > #+FOO: bar > > > > * Baz > > -- Cut here -- > > I would like to see you capture template in its elisp form, i.e., as set > in `org-capture-templates'. > > Thank you. Why? This is a regression. -- Phil Hudson http://hudson-it.ddns.net Pretty Good Privacy (PGP) ID: 0x4E482F85
Re: [O] [PATCH] org-attach: Allow attaching file from visited buffer
Hello, Eric Danan writes: > Sorry for the slow reply. Sorry for the even slower reply. > I tried something similar to your second proposal (mimicking > `org-attach-dired-to-subtree'), but more convenient in my opinion and > not losing the method choice. It mimicks the mechanism to store links: > there is a new command `org-store-attachment' (to which one could give > a global keybinding such as `C-c a`) that stores an attachment to the > current buffer in a new variable `org-stored-attachments', and > `org-attach-attach', when called interactively, prompts to select an > attachment from this variable if it is non nil (the attachment is then > removed from the variable). See attached patch (yes I've signed the > FSF papers). > > "Storing an attachment" simply means storing the buffer file name or, > if there is none, the buffer name, to the variable (there may be a > better terminology for that). Then `org-attach-attach' detects if the > "file" is actually the name of a non-file-visiting buffer and uses > `write-file' rather than the specified or default method in that case. > So we keep the method choice and don't need to add a specific command > for buffers to the dispatcher. If you think it's not worth introducing > complications for allowing to attach non-file-visiting buffers, we > could simply prevent this in `org-store-attachment'. I also made it so > that if `org-store-attachment' is called from a dired buffer, then the > file at point is stored rather than the dired buffer itself. This sounds interesting, but I have the feeling that would be a bit complicated in practice. I assume that when you want to attach a document to a node, you're already at the node. Ideally, it should be possible to attach something in one step from here. With your proposal, you need to first mark a buffer as an attachment, then go back to the node and attach it properly. Moreover, when you marked something as an attachment, changed your mind, and now want to attach something else, `org-store-attachment' prevents from doing this. The variable shadows other options when it is non-nil. There are also issues, e.g., what happens if the buffer marked as an attachment has been killed? > This can certainly be improved, but I hope it is sufficient for you to > judge whether you think it is a good idea or not. I eventually added, in "next" branch (Org 9.3), something much simpler. Pressing from the attach dispatcher offers to choose a buffer from the list of active buffers, and save its contents to a file in the attachment directory. Does it suit your needs? > - We could add a mechanism for making `org-attach-attach' > unconditionally read a file name, ignoring `org-stored-attachments' > (i.e. a prefix argument, distinct from the one to visit the attachment > directory). We could also add a command to clear > `org-stored-attachments' from the dispatcher. That would solve second problem, but not the others. > I understand that other users may not like this mechanism and prefer > different solutions (or leaving things as they are). There was a > recent suggestion to make the list of commands in the attachment > dispatcher customizable: > > http://lists.gnu.org/archive/html/emacs-orgmode/2018-06/msg00139.html > > Do you think it would make sense to do so? It could make sense to allow customizing attachment actions, if anyone wants try implementing it. Thank you for your work and for the ideas! Regards, -- Nicolas Goaziou
Re: [O] [PATCH] org-attach: Allow attaching file from visited buffer
Hello, I eventually added, in "next" branch (Org 9.3), something much simpler. Pressing from the attach dispatcher offers to choose a buffer from the list of active buffers, and save its contents to a file in the attachment directory. Does it suit your needs? Yes, thanks. It could make sense to allow customizing attachment actions, if anyone wants try implementing it. I may try it when I find some time but probably not very soon. Eric
Re: [O] Bug: Org Table Performance Issue/Regression
> On Sep 3, 2018, at 2:59 AM, Nicolas Goaziou wrote: > > I think master branch behaves better now. Could you confirm it? It behaves better and is usable again. It's still not quite as fast as version 8.2.10 that came with Emacs 25.3, but I think I’m using Org tables in an atypical way and have a workaround for my particular situation. Thanks for the work and fixes. Tim
Re: [O] Full-width characters break column display
Nicolas Goaziou writes: > The problem is that > > (string-width "何か") > > equals > > (string-width "") > > i.e, 4 characters, but both strings do not have the same length > visually. > > As long as the two sexps above disagree, it seems difficult to support > this. Oh. OK, so now I feel stupid: I was convinced full-width chars were twice the width of half-width chars… and it turns out the names are treacherous, and they are actually not. I guess this is a font / display issue then, and not an org-mode issue. Sorry for having bothered you and thank you! Leo
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, nice to hear that you find it useful! I don’t have access to apply the patch myself. So I’d be happy if one of the frequent maintainers could help out with that, and at the same time look a bit at the quality of it. I’ve used most of the functionality personally for well over a year in my local setup and just now took the time to repackage it into something reusable. Hopefully it’s seen as “good enough” to warrant a merge into one of the org-mode branches! From my perspective the patch adds a lot of utility to the attachment-functionality. Regards Gustav From: tumashu Sent: den 1 november 2018 02:46 To: Gustav Wikström Cc: emacs-orgmode Subject: Re:[O] FW: [RFC] Link-type for attachments, more attach options Hello, this feature seem to be very useful, what is this patch status? At 2018-10-21 15:53:38, "Gustav Wikström" mailto:gus...@whil.se>> wrote: Hi, I’ve attached a patch with some suggested additions to org-attach. Patch comments below. Please review. Kind regards Gustav ___ Patch comments: * Add new linktype "attached" for attachments A new linktype "attached" is added in order to reduce link-duplication when wanting to link to files in attached folders of nodes. This works for both ID-based attachments and ATTACH_DIR. Inline images will trigger also for attachments, as well as search-decorations in the links. The goal is to make the functionality for attached-links mirror file-links. * Add further options for ATTACH_DIR When working with ATTACH_DIR there are now a couple of new options available: - org-attach-dir-inherit-by-default - org-attach-dir-create-if-not-exist - org-attach-dir-relative Descriptions of them can be found in the commit for each new customization. * Documentation in org-manual Org-manual is updated with the new link-type as well as some minor cleanup in the documentation related to external links and attachments.
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Marco, Nice to hear you like it! Yeah, I'm pretty happy with that functionality as well. Use it all the time to quickly add links to attached files. One use case I have for this (as an example) is for projects and tasks. I have a 'tasks.org' file with nodes for each of my tasks and each of my projects. Usually, if the task is about some digital work, there are files involved with it. So I have a convention to add folders next to the 'tasks.org' file with names like 'YYMM [task/project title]', and attach the folder to each task/project node. C-c C-l attached RET then makes it super-easy to refer to particular files within that folder, from within the node in the 'tasks.org' file! Another use case is for my 'digital brain', where it's also fairly common for me to have attachment folders where I want to refer to files within them. Images for example, that then will be displayed in the org-mode file. Haven't settled on whether I should use auto-managed ID's for these folders, or :ATTACH_DIR: properties though. Currently using a bit of both... I'm not familiar with the 'next' branch and the plans for integrating it into 'master'. But if 'master' is to offensive to merge into straight away, 'next' sounds like a good option! Kind regards Gustav -Original Message- From: Marco Wahl Sent: den 1 november 2018 17:01 To: Gustav Wikström Subject: Re: FW: [RFC] Link-type for attachments, more attach options The following message is a courtesy copy of an article that has been posted to gmane.emacs.orgmode as well. Hi Gustav, I played a bit with your proposition. I like it; in particular the completion function to insert links from the attachment directory with C-c C-l attached RET It seems natural to me to have a more specific link type for attached files. In my opinion your patch should be applied to the 'next' branch. My 2ct, Marco
Re: [O] Help with sharing emacs-org presentation
Thanks, Jens, for your comment! I understand your point of view! My point is that Org mode is not ubiquitous and most people (esp. non-programmers) do not use emacs. But I do concur that Org mode is great for collaboration IF a team can agree to using it. Thanks for your interesting references! I am glad to learn about "single source" and OER. Your OER material looks fascinating: I don't know that .org file can be rendered instantaneously as HTML on GitLab. ~ Feiming On Wed, Oct 31, 2018 at 2:39 AM Jens Lechtenboerger < lech...@wi.uni-muenster.de> wrote: > On 2018-10-25, Feiming Chen wrote: > > > I gave a talk on emacs-org in a local workshop (Government Advances > > in Statistical Programming) in Washington D.C. yesterday. I'd like to > > share the slides and org source file with the community (see attached). > > Thanks for sharing! > > I wonder why you stress the following: > - Not good for collaborative use (unlike Microsoft Office). > - Good for private, non-collaborative use. > > My view is the opposite: Org mode is excellent for collaboration as > it is plain text, suitable for diff/merge in Git repositories. > Thanks to the separation of contents from style, > cross-organizational collaboration is possible, which I find *very* > hard with any office tool: Changing a document master leads to all > kinds of layout destruction. Switching to a different corporate > identity is just hard with what-you-see-is-what-you-get tools. > > In contrast, Org mode can be a basis for what is called Single > Sourcing [1] in the context of technical writing. > > You can see my approach towards Open Educational Resources with Org > mode at [2]. > > Best wishes > Jens > > [1] http://rockley.com/articles/Single_Sourcing_and_Technology.pdf > [2] https://gitlab.com/oer/OS >
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Gustav, Thanks for the patch! I am a heavy user of org attachments, so it is pleasant that someone spent a time to implement this useful feature into org. A comment regarding the code. Your new link types appears to reimplement some of the code for the "file:" links. Would it make more sense to implement the "attachment:" link type as abbreviation? I mean something like the code below: (defun yant/process-att-abbrev (arg) "Return `org-attach-dir' for the current entry." (s-concat (org-attach-dir 'CREATE) arg)) (add-to-list 'org-link-abbrev-alist (cons "att" "file:%(yant/process-att-abbrev)")) (defun org-att-link-complete (&optional arg) "Completion function for att: link." (let* ((ref-dir (org-attach-dir 'CREATE)) (filelink (let ((default-directory ref-dir)) (org-file-complete-link))) (filepath (apply #'s-concat (cdr (s-split ":" filelink) (format "att:%s" filepath))) (org-link-set-parameters "att" :complete #'org-att-link-complete) Also, is anyone interested in automatic placing of org attachments into a folder structure, which mirrors the org path? Something like in the following Stack Exchange question: https://emacs.stackexchange.com/questions/26412/human-readable-directory-tree-with-org-attach Best, Ihor Gustav Wikström writes: > Hi Marco, > > Nice to hear you like it! Yeah, I'm pretty happy with that functionality as > well. Use it all the time to quickly add links to attached files. > > One use case I have for this (as an example) is for projects and tasks. I > have a 'tasks.org' file with nodes for each of my tasks and each of my > projects. Usually, if the task is about some digital work, there are files > involved with it. So I have a convention to add folders next to the > 'tasks.org' file with names like 'YYMM [task/project title]', and attach the > folder to each task/project node. C-c C-l attached RET then makes it > super-easy to refer to particular files within that folder, from within the > node in the 'tasks.org' file! > > Another use case is for my 'digital brain', where it's also fairly common for > me to have attachment folders where I want to refer to files within them. > Images for example, that then will be displayed in the org-mode file. Haven't > settled on whether I should use auto-managed ID's for these folders, or > :ATTACH_DIR: properties though. Currently using a bit of both... > > I'm not familiar with the 'next' branch and the plans for integrating it into > 'master'. But if 'master' is to offensive to merge into straight away, 'next' > sounds like a good option! > > Kind regards > Gustav > > -Original Message- > From: Marco Wahl > Sent: den 1 november 2018 17:01 > To: Gustav Wikström > Subject: Re: FW: [RFC] Link-type for attachments, more attach options > > The following message is a courtesy copy of an article that has been posted > to gmane.emacs.orgmode as well. > > Hi Gustav, > > I played a bit with your proposition. I like it; in particular the > completion function to insert links from the attachment directory with > > C-c C-l attached RET > > It seems natural to me to have a more specific link type for attached files. > > In my opinion your patch should be applied to the 'next' branch. > > > My 2ct, > Marco > signature.asc Description: PGP signature
