Re: [O] Concatenating Org property values from parent subtrees
Hi,
Check out the following code:
(defvar org-concatenated-properties '("AA")
"A list of property names (strings), which should be computed via
concatenation with the parent properties.")
(define-advice org-entry-get (:around (oldfun pom property &optional inherit
literal-nil) concatenate-parents-maybe)
"Concatenate the PROPERTY value with its parent entries' values if the
PROPERTY is in `org-concatenated-properties' list."
(if (not (member property org-concatenated-properties))
(apply oldfun pom property inherit literal-nil)
(let ((value-here (funcall oldfun pom property nil 't))
(value (funcall oldfun pom property inherit 't)))
(if value-here
(format "%s%s" (org-with-wide-buffer
(if (org-up-heading-safe)
(or (org-entry-get nil property inherit
literal-nil) "")
""))
(funcall oldfun pom property inherit literal-nil))
(when value
(org-with-wide-buffer
(org-up-heading-safe)
(org-entry-get nil property inherit literal-nil)))
Best,
Ihor
Michael Welle writes:
> Hello,
>
> Michael Welle writes:
> [...]
>> (defun hmw/org-prop-append(prop value)
>> (save-excursion
>> (org-up-heading-safe)
>> (format "%s %s" value (cdr (assq prop
>>(car
>> (org-babel-params-from-properties)))
>>
>> (defalias 'A 'hmw/org-prop-append)
>
> and I just realise that it works with code blocks only. I guess the way
> to get general property values has to be adapted.
>
> Regards
> hmw
>
signature.asc
Description: PGP signature
Re: [O] An Org-based productivity tool
Hi, One suggestion would be to distinguish between different types of work. For example, you may value more an important project you need to work on, but do not like, in comparison with another project you really like doing. This can be done, for example, by weighting the time spent on different tasks according to the task urgency/arbitrary multiplier. A comment on the example output. Some people (like me) can spend too much time just staring at the kind of output you provided. I found it more efficient to have a single number/phrase indication if I need to work harder or not. The full output might still be shown to adjust the overall productivity, but, say, once per day/week. Best, Ihor Marcin Borkowski writes: > Hi Orgers, > > I am making an Org-mode-based tool to help boost my productivity. > > I am constantly fighting a losing battle with distractions. I figured > out that showing me how much time I spent goofing around would help me > stay on track (being a math geek and a gamer, my "let's break my > yesterday's score" and similar instincts kick in immediately, too). So > far, I have these in my prototype: > > - a notification (recurring every n seconds) that I'm not clocking > anything, > > - some stats about what I spent my time on and what my efficiency (i.e., > percentage of time I spent working from the point when I started > counting to now) is, > > - info about how much work I need to do in order to meet my set goal, > and how much will it take if my efficiency remains constant, > > - a warning when my efficiency is lower than a set value, and info about > how much work I need to do to bump it up to that value. > > Here's an example output (with some partially faked data): > > --8<---cut here---start->8--- > 39min of your workday (10%) has passed, and you have 5h 31min left. > > work - 30min spent (12% of your goal of 4h and 75% of your workday so far) >3h 30min remaining (4h 39min with your current efficiency of 75%). >You need 9min of uninterrupted work to get back to 80% efficiency. > > eating - 4min spent (10% of your workday so far) > > bathroom - 2min spent (5% of your workday so far) > > unclassified - 0min spent (0% of your workday so far) > > Unclocked time so far: 3min. > --8<---cut here---end--->8--- > > My questions are: > > - is anyone interested in something like this? > > - are there any features you would like to have? (I have some ideas, > too.) > > - does anyone have an idea of how to /name/ this project? > > TIA, > > -- > Marcin Borkowski > http://mbork.pl > -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature
Re: [O] An Org-based productivity tool
> To motivate people focusing on there work, something like the link below > could be > an idea, especially for gamers ;) > > https://habitica.com/static/home It would be great to integrate it with Org. Roland Everaert writes: > Regarding auto-clocking, you should look at what norang did. > > http://doc.norang.ca/org-mode.html > > To motivate people focusing on there work, something like the link below > could be > an idea, especially for gamers ;) > > https://habitica.com/static/home > > Samuel Wales writes: > >> auto-clocking might be interesting. >> >> there would be a concept of a dominating clocking entry similar to >> dominating file. i.e. if where you are is not a clocking entry, go up >> until you find one that is. if you find none at top level, you create >> a clock entry in the logbook there. >> >> if you switch buffers or move around, you clock out and in where you >> were and are. every few minutes, you try to clock in where you are, >> or the dominating clocking entry. this is done with timers. idle >> time might go to a special clocking entry. >> >> or something like that. the idea is that you don't have to remember >> to clock in and out. >> >> On 10/10/18, Marcin Borkowski wrote: >>> >>> On 2018-10-10, at 18:50, William Denton wrote: >>> On 10 October 2018, Marcin Borkowski wrote: > I am making an Org-mode-based tool to help boost my productivity. > ... > - is anyone interested in something like this? I am---I'd love to see what you come up with. I'm doing something similar, but much less fancy, with clock tables and some R: https://www.miskatonic.org/2017/11/16/clocktableii/ I need to do one more post about that to wrap it up. It's working well for me, but warnings about not being clocked in to something, and better understanding of what I'm doing based on headings or tags, would be useful. >>> >>> Thanks for your kind words! >>> >>> It's not that fancy (yet?), but has one big advantage over clock tables: >>> it updates dynamically (using org-clock-out-hook), so it's fast. Also, >>> as you could see, it does some simple calculations. >>> >>> And for the record: it's based on properties, not tags - but that is >>> a minor issue. >>> >>> Best, >>> >>> -- >>> Marcin Borkowski >>> http://mbork.pl >>> >>> > > > -- > Luke, use the FOSS > > Sent from Emacs > signature.asc Description: PGP signature
Re: [O] An Org-based productivity tool
I mean something like what we have for calendar sync. The data can be stored/edited both in the service and in relevant org files. Roland Everaert writes: > Ihor Radchenko writes: > >>> To motivate people focusing on there work, something like the link below >>> could be >>> an idea, especially for gamers ;) >>> >>> https://habitica.com/static/home >> >> It would be great to integrate it with Org. > > What do you mean, create an interface to the service or duplicating the > service in Emacs/Org Mode? > >> >> >> Roland Everaert writes: >> >>> Regarding auto-clocking, you should look at what norang did. >>> >>> http://doc.norang.ca/org-mode.html >>> >>> To motivate people focusing on there work, something like the link below >>> could be >>> an idea, especially for gamers ;) >>> >>> https://habitica.com/static/home >>> >>> Samuel Wales writes: >>> >>>> auto-clocking might be interesting. >>>> >>>> there would be a concept of a dominating clocking entry similar to >>>> dominating file. i.e. if where you are is not a clocking entry, go up >>>> until you find one that is. if you find none at top level, you create >>>> a clock entry in the logbook there. >>>> >>>> if you switch buffers or move around, you clock out and in where you >>>> were and are. every few minutes, you try to clock in where you are, >>>> or the dominating clocking entry. this is done with timers. idle >>>> time might go to a special clocking entry. >>>> >>>> or something like that. the idea is that you don't have to remember >>>> to clock in and out. >>>> >>>> On 10/10/18, Marcin Borkowski wrote: >>>>> >>>>> On 2018-10-10, at 18:50, William Denton wrote: >>>>> >>>>>> On 10 October 2018, Marcin Borkowski wrote: >>>>>> >>>>>>> I am making an Org-mode-based tool to help boost my productivity. >>>>>>> ... >>>>>>> - is anyone interested in something like this? >>>>>> >>>>>> I am---I'd love to see what you come up with. I'm doing something >>>>>> similar, but much less fancy, with clock tables and some R: >>>>>> >>>>>> https://www.miskatonic.org/2017/11/16/clocktableii/ >>>>>> >>>>>> I need to do one more post about that to wrap it up. It's working >>>>>> well for me, but warnings about not being clocked in to something, and >>>>>> better understanding of what I'm doing based on headings or tags, >>>>>> would be useful. >>>>> >>>>> Thanks for your kind words! >>>>> >>>>> It's not that fancy (yet?), but has one big advantage over clock tables: >>>>> it updates dynamically (using org-clock-out-hook), so it's fast. Also, >>>>> as you could see, it does some simple calculations. >>>>> >>>>> And for the record: it's based on properties, not tags - but that is >>>>> a minor issue. >>>>> >>>>> Best, >>>>> >>>>> -- >>>>> Marcin Borkowski >>>>> http://mbork.pl >>>>> >>>>> >>> >>> >>> -- >>> Luke, use the FOSS >>> >>> Sent from Emacs >>> > > > -- > Luke, use the FOSS > > Sent from Emacs signature.asc Description: PGP signature
Re: [O] An Org-based productivity tool
Well, you could associate a reward to that kind of tasks. For example, you can allow yourself to work half a day. Alternatively, you can make a task you would like to do (say, watch a new movie) to be blocked until the unwanted task is done. "Peter Neilson" writes: > On Thu, 11 Oct 2018 10:03:15 -0400, Bingo wrote: > >> Le 10 octobre 2018 21:45:53 GMT+05:30, Marcin Borkowski >> a écrit : >> >>> >>> - a warning when my efficiency is lower than a set value, and info >>> about >>> how much work I need to do to bump it up to that value. >>> >> >> Nice, but it has an anti-feature. For procrastinators, warnings >> frequently have negative effects. It can be understood in multiple ways : >> >> 1. "What the hell" effect : As Dr Art Marckman tells in the book "Smart >> Change" , there is a "what the hell" effect where the victim goofs off >> even more to the extent of giving up a goal if he realizes that he is >> falling behind schedule, or has goofed off more than was advisable. The >> solution is to forgive oneself, and not beat oneself up. This warning >> looks like beating oneself up. >> >> 2. Showing how much work needs to be done to catch up goes against some >> self improvement philosophies. E.g. dividing work into subtasks helps in >> not getting overwhelmed by the amount of work. Or the recommendation to >> plan breaks in addition to planning to slog, otherwise the plan to slog >> becomes overwhelming and procrastinators give up. >> >> Of course, if it works for you, go for it. > > Sabotage of the TODO list ... > > Managing the flow of my own work sometimes runs into unintended sabotage, > perpetrated by others or by me. The offending tasks are often large, > incapable of division, and not immediately crucial. For example, somewhere > in the middle of my list of "Get it done some other time, but not now," > tasks is this one: "Repair the International 454 tractor." It rests > comfortably on that list unless I either (1) need to use that tractor, or > (2) hear my wife telling me, "Why don't you ever get the 454 running? You > never get anything done around here! I need to use its bucket, and the > Mahindra doesn't have one." From that point onward, and my "TODO" thoughts > about writing, about programming, or about training horses are derailed. > In case (1) I need to figure out some other approach, like maybe using the > Mahindra. In case (2) my wife is right--as always--and my tendency is to > stop doing anything at all. > > My org mode TODO list is absolutely no help when I encounter one of these > show-stoppers. If anything, the list is an additional albatross adding to > my already encroaching depression. > > Maybe I need a brain-wave detector, connecting through emacs-lisp AI code > to a huge Pomodoro-style graphic display, that will alert me when I am > goofing off, falling asleep, or practicing mental evasion. > signature.asc Description: PGP signature
Re: [O] How to make agenda generation faster
> I've thought about this for a while. It seems to me that the issue is > that Org buffers are, of course, plain-text buffers. There is no > persistent, in-memory representation other than the buffer, so whenever > Org needs structured/semantic data, it must parse it out of the buffer, > which is necessarily rather slow. If there were a way to keep an > outline tree in memory, parallel to the buffer itself, that would allow > operations like search, agenda, etc. to be greatly sped up. FYI A while ago I saw some cache implementation in org-element.el. Take a look at org-element--cache variable definition and the code below. (defvar org-element--cache nil "AVL tree used to cache elements. Each node of the tree contains an element. Comparison is done with `org-element--cache-compare'. This cache is used in `org-element-at-point'.") Best, Ihor Adam Porter writes: > Nicolas Goaziou writes: > >>> my understanding is that code that runs with lexical-binding enabled >>> is generally faster. >> >> Not really. But it's certainly easier to understand since it removes one >> class of problems. > > From what I've read, the byte-compiler can optimize better when > lexical-binding is used. > >> Instead of re-inventing the wheel, or putting efforts into a >> wheel-like invention, wouldn't it make sense to actually work on Org >> Agenda itself? >> >> So again, wouldn't it be nice to think about Org Agenda-ng? > > As a matter of fact, what's now called org-ql-agenda was originally > called org-agenda-ng. I factored org-ql out of it and realized that it > should probably be its own, standalone package. Then I renamed > org-agenda-ng to org-ql-agenda, so I could reasonably keep them in the > same repo, and because I don't know if I will ever develop it far enough > to be worthy of the name org-agenda-ng. It started as an experiment to > build a foundation for a new, modular agenda implementation, and maybe > it could be. > >> I didn't look closely at org-ql, but I had the idea of splitting the >> Agenda in two distinct parts. One would be responsible for collecting, >> possibly asynchronously, and caching data from Org documents. The other >> one would provide a DSL to query and display the results extracted from >> the output of the first part. The second part could even be made generic >> enough to be extracted from Org and become some part of Emacs. >> Displaying filtered data, maybe in a timeline, could be useful for other >> packages. Unfortunately, I don't have time to work on this. Ah well. > > I've thought about this for a while. It seems to me that the issue is > that Org buffers are, of course, plain-text buffers. There is no > persistent, in-memory representation other than the buffer, so whenever > Org needs structured/semantic data, it must parse it out of the buffer, > which is necessarily rather slow. If there were a way to keep an > outline tree in memory, parallel to the buffer itself, that would allow > operations like search, agenda, etc. to be greatly sped up. > > But how would that work in Emacs? Theoretically, we could write some > code, applied on self-insert-command, to update the "parallel tree > structure" as the user manipulates the plain-text in the buffer > (e.g. add a new node when the user types a "*" to create a new heading), > and also apply it to functions that manipulate the outline structurally > in the buffer. But, of course, that sounds very complicated. I would > not relish the idea of debugging code to keep a cached tree in sync with > a plain-text buffer outline. :) > > Besides that, AFAIK there would be no way to do it asynchronously other > than calling out to a child Emacs process (because elisp is still > single-threaded), printing and reading the data back and forth (which > would tie up the parent process when reading). Maybe in the future > elisp will be multithreaded... > > Anyway, org-ql tries to do some of what you mentioned. It does > rudimentary, per-buffer, per-query caching (as long as the buffer is not > modified, the cache remains valid), which helps when there are several > Org files open that are referred to often but not as often modified. > And the query and presentation code are separated (org-ql and > org-ql-agenda). > > I don't know how widely it's used, but the repo is getting some regular > traffic, and I'm using it as the backend for my org-sidebar package. > I'd be happy if it could be made more generally useful, or if it could > be helpful to Org itself in some way. Contributions are welcome. > > signature.asc Description: PGP signature
Re: [O] An Org-based productivity tool
FYI "Note taker and org-clock-in enforcer" https://github.com/roman/clocker.el Best, Ihor Marcin Borkowski writes: > Hi Orgers, > > I am making an Org-mode-based tool to help boost my productivity. > > I am constantly fighting a losing battle with distractions. I figured > out that showing me how much time I spent goofing around would help me > stay on track (being a math geek and a gamer, my "let's break my > yesterday's score" and similar instincts kick in immediately, too). So > far, I have these in my prototype: > > - a notification (recurring every n seconds) that I'm not clocking > anything, > > - some stats about what I spent my time on and what my efficiency (i.e., > percentage of time I spent working from the point when I started > counting to now) is, > > - info about how much work I need to do in order to meet my set goal, > and how much will it take if my efficiency remains constant, > > - a warning when my efficiency is lower than a set value, and info about > how much work I need to do to bump it up to that value. > > Here's an example output (with some partially faked data): > > --8<---cut here---start->8--- > 39min of your workday (10%) has passed, and you have 5h 31min left. > > work - 30min spent (12% of your goal of 4h and 75% of your workday so far) >3h 30min remaining (4h 39min with your current efficiency of 75%). >You need 9min of uninterrupted work to get back to 80% efficiency. > > eating - 4min spent (10% of your workday so far) > > bathroom - 2min spent (5% of your workday so far) > > unclassified - 0min spent (0% of your workday so far) > > Unclocked time so far: 3min. > --8<---cut here---end--->8--- > > My questions are: > > - is anyone interested in something like this? > > - are there any features you would like to have? (I have some ideas, > too.) > > - does anyone have an idea of how to /name/ this project? > > TIA, > > -- > Marcin Borkowski > http://mbork.pl > signature.asc Description: PGP signature
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
Re: [O] Bug: org-back-to-heading with inline tasks above point [9.1.14 (9.1.14-3-geb9955a-elpaplus @ /home/yantar92/.emacs.d/elpa/org-plus-contrib-20180924/)]
Thanks! Did not know about `org-with-limited-levels'. After reading the function docstring again, I see that it behaved correctly. However, it seems that `org-back-to-heading' is not really used according to the docstring in the org source code: - `org-agenda' with subtree restriction: the results are different if you call it below or above an inline task. - `org-attach', `org-attach-dir', `org-attach-tag', with point below/above an inline task behave differently - the following functions from org.el behave depending on the point position (below or above an inline task): `org-entry-beginning-position', `org-entry-end-position', `org-get-heading', `org-get-entry', `org-insert-heading-after-current', `org-promote', `org-demote', `org-move-subtree-down', etc. Some of the functions above give very unexpected results if the point is below an inline task. Would it make sense to add org specific macros to Hacking section of org manual? It is sometimes difficult to guess that some of these macros even exist. Best, Ihor Nicolas Goaziou writes: > Hllo, > > yanta...@gmail.com writes: > >> Consider calling =org-back-to-heading= for the following org entry: >> >> #+begin_src org >> * Sample entry >> >> Some text. >> >> *** TODO Inline task >> *** END >> >> Some more text. >> >> ->(point)<- >> >> Yet another piece of text. >> #+end_src >> >> The expected behaviour is that the point moves to the first line of the >> entry. >> However, the point moves to the end of the inline task. >> >> Indeed, the wrong behaviour is because =outline-regexp= variable is set >> to ="\\*+ "=, which includes inline tasks. > > This is the desired effect. Use the macro `org-with-limited-levels' to > ignore headlines. > > Regards, > > -- > Nicolas Goaziou signature.asc Description: PGP signature
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Gustav, > I'm not sure I follow your suggestion regarding changing the > implementation. But anyhow I don't think the implementation is heavy > and at risk of cumbersome code duplication. My opinion ofc 😊 Sure. The code is not that complicated. > I like the idea of a function that would symbolically links folders > from "ID"-folder structure to a hierarchy-folder structure, based on > the name and path of the org-file and its headings containing the > links. I probably wouldn't use it much myself though. Not until > org-mode starts working better with multiple files, allowing us to > more easily define "org-mode libraries". I am wondering what you mean by "org-mode libraries". Can you explain further? Also, another thought about the attachment: links. It would be useful to implement links to attachments, which are not in the current org entry. For example, something like "attachment:ORG-ID:file-name", where ORG-ID refers to ID of an arbitrary org entry. Best, Ihor Gustav Wikström writes: > Hi Ihor, > > I'm not sure I follow your suggestion regarding changing the implementation. > But anyhow I don't think the implementation is heavy and at risk of > cumbersome code duplication. My opinion ofc 😊 > > I like the idea of a function that would symbolically links folders from > "ID"-folder structure to a hierarchy-folder structure, based on the name and > path of the org-file and its headings containing the links. I probably > wouldn't use it much myself though. Not until org-mode starts working better > with multiple files, allowing us to more easily define "org-mode libraries". > > /G > >> -Original Message- >> From: Ihor Radchenko >> Sent: den 3 november 2018 04:38 >> To: Gustav Wikström ; Marco Wahl >> Cc: emacs-orgmode >> Subject: 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 co
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, >Generalize org-agenda by allowing us to have multiple ones, and make them > more general by thinking of them as a set of views that works on sets of > files. Maybe this is not for all, but I would appreciate to create multiple > "agendas" (even though I'd call them "libraries" in instead), and possibly > also an aggregate agenda consisting of other agendas. Isn't this already in org? You can use custom agendas with multiple "agendas" (custom commands) and set the files they operate on with org-agenda-files within custom commands. >If two org-mode files exist in the same folder with different names, it > would be awesome to think of (and work with) them as two top-level headings > inside one org-mode buffer. Similar to two level-1 headings inside an > org-mode file. For this to work all properties we can define for regular > headings should be possible to define for these "level-0 headings". For > example an attachment-folder or ID, a deadline, scheduled date, or > TODO-keyword should in that case be configurable on the whole file. I guess > some new conventions regarding syntax and existing properties would have to > be created as well. You can do something like below. It is pretty much what you want, except I am not sure how to update the headings from local org files. Current org version does not allow `:results replace` on raw org output. * Main heading #+name: org-files-here #+begin_src bash ls *.org #+end_src #+begin_src emacs-lisp :var files=org-files-here() :var stars=(make-string (car (org-heading-components)) ?*) :results raw replace drawer (let ((files (mapcar #'car files))) (cl-loop for file in files concat (with-current-buffer (find-file-noselect file) (concat (format "* %s\n" (buffer-file-name)) (replace-regexp-in-string "^\\*" (concat "*" stars) (buffer-string)) #+end_src Best, Ihor Gustav Wikström writes: > Hi, > >> -Original Message- >> From: Ihor Radchenko >> Sent: den 18 november 2018 01:42 >> To: Gustav Wikström ; Marco Wahl >> >> Cc: emacs-orgmode >> Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options >> >> Hi Gustav, >> >> > I like the idea of a function that would symbolically links folders >> > from "ID"-folder structure to a hierarchy-folder structure, based on >> > the name and path of the org-file and its headings containing the >> > links. I probably wouldn't use it much myself though. Not until >> > org-mode starts working better with multiple files, allowing us to >> > more easily define "org-mode libraries". >> >> I am wondering what you mean by "org-mode libraries". Can you explain >> further? > > This goes a bit off topic; But what I mean is mainly two things: > 1) Generalize the org-agenda so that we can have multiple ones > >Generalize org-agenda by allowing us to have multiple ones, and make them > more general by thinking of them as a set of views that works on sets of > files. Maybe this is not for all, but I would appreciate to create multiple > "agendas" (even though I'd call them "libraries" in instead), and possibly > also an aggregate agenda consisting of other agendas. > > 2) Make files function as virtual "level-0 headings" > >If two org-mode files exist in the same folder with different names, it > would be awesome to think of (and work with) them as two top-level headings > inside one org-mode buffer. Similar to two level-1 headings inside an > org-mode file. For this to work all properties we can define for regular > headings should be possible to define for these "level-0 headings". For > example an attachment-folder or ID, a deadline, scheduled date, or > TODO-keyword should in that case be configurable on the whole file. I guess > some new conventions regarding syntax and existing properties would have to > be created as well. > >> >> Also, another thought about the attachment: links. >> It would be useful to implement links to attachments, which are not in the >> current org entry. >> For example, something like "attachment:ORG-ID:file-name", where ORG-ID >> refers to ID of an arbitrary org entry. > > I wouldn't call that attachment-links, but rather ID-based links (since > attachments are local based on either headline ID or attach-dir of the > current headline). ID links exist already but link to headlines. > > If you rather see ID-based attachments as some kind of global attachments for > all your org-mode files, I'd think the link-type should reflect that and be > called something like "ID-attachment:file-name", "ID-@:file-name", > "@ID:file-name" and be a separate link-type. > >> >> Best, >> Ihor >> >> > > Kind regards > Gustav signature.asc Description: PGP signature
Re: [O] Feature request - Decouple org's keybindings from their functions
> Decoupling is not a good idea. Because it will let user define too much > keybindings. And User can define keybinding in Emacs easily. Emacs is > powerful for customization. I disagree. It is against emacs philosophy. It is one of the key features of emacs that users can redefine keybindings if they need to (but do not have to do it). I do not like loosing this feature without a strong reason. > And user need convention for Org default keybindings so that when Org > users communications can know what he did. For example, when I said [C-c > C-c] in Org, Every Org users know it. You can as well say `M-x org-ctrl-c-ctrl-c` and be understood. Best, Ihor stardiviner writes: > Decoupling is not a good idea. Because it will let user define too much > keybindings. And User can define keybinding in Emacs easily. Emacs is > powerful for customization. > > And user need convention for Org default keybindings so that when Org > users communications can know what he did. For example, when I said [C-c > C-c] in Org, Every Org users know it. > > -- > [ stardiviner ] >I try to make every word tell the meaning what I want to express. > >Blog: https://stardiviner.github.io/ >IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 > signature.asc Description: PGP signature
Re: [O] FW: [RFC] Link-type for attachments, more attach options
> No, it's not there. I know of the custom agendas and use it currently. But I
> cannot anywhere specify more than one org-agenda-files parameter, for
> example.
I just tried:
#+begin_src emacs-lisp
(setq org-agenda-custom-commands
(quote (("v" "Test" tags-todo nil
((org-agenda-files '("~/Org/inbox.org"
("w" "Test 2" tags-todo nil
((org-agenda-files
'("~/Knowledge_base/2016/Private/Get_started_with_org_mode/get_started_org_mode.org")))
#+end_src
It works fine for me.
> No, that's not what I want. What I'm talking about is extending org-mode
> conceptually with the concept of 0-level headlines, where the body of that
> "headline" would be everything before the first headline in a file, and where
> I could specify (for example) an attachment-directory and be able to use it
> with this new syntax to link to attached files. I guess I took it a bit far
> with the example of visualizing multiple files from a folder as separate
> headlines inside a single emacs-buffer though. It would be cool to be able to
> do that but my intention was more about introducing the 0-level headline
> concept.
Yeah. But someone needs to volunteer with the patch.
It would be even better if these 0-level headings can be edited from the
referencing file.
Regards,
Ihor
Gustav Wikström writes:
> Hi,
>
>> -Original Message-
>> From: Ihor Radchenko
>> Sent: den 20 november 2018 15:01
>> To: Gustav Wikström
>> Cc: emacs-orgmode
>> Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options
>>
>> Hi,
>>
>> >Generalize org-agenda by allowing us to have multiple ones, and make
>> them more general by thinking of them as a set of views that works on sets
>> of files. Maybe this is not for all, but I would appreciate to create
>> multiple "agendas" (even though I'd call them "libraries" in instead), and
>> possibly also an aggregate agenda consisting of other agendas.
>>
>> Isn't this already in org? You can use custom agendas with multiple
>> "agendas" (custom commands) and set the files they operate on with org-
>> agenda-files within custom commands.
>
> No, it's not there. I know of the custom agendas and use it currently. But I
> cannot anywhere specify more than one org-agenda-files parameter, for
> example.
>
>>
>> >If two org-mode files exist in the same folder with different names, it
>> would be awesome to think of (and work with) them as two top-level headings
>> inside one org-mode buffer. Similar to two level-1 headings inside an org-
>> mode file. For this to work all properties we can define for regular
>> headings should be possible to define for these "level-0 headings". For
>> example an attachment-folder or ID, a deadline, scheduled date, or TODO-
>> keyword should in that case be configurable on the whole file. I guess some
>> new conventions regarding syntax and existing properties would have to be
>> created as well.
>>
>> You can do something like below. It is pretty much what you want, except I
>> am not sure how to update the headings from local org files. Current org
>> version does not allow `:results replace` on raw org output.
>>
>> * Main heading
>>
>> #+name: org-files-here
>> #+begin_src bash
>> ls *.org
>> #+end_src
>>
>> #+begin_src emacs-lisp :var files=org-files-here() :var stars=(make-string
>> (car (org-heading-components)) ?*) :results raw replace drawer (let ((files
>> (mapcar #'car files)))
>> (cl-loop for file in files
>> concat (with-current-buffer (find-file-noselect file)
>> (concat (format "* %s\n" (buffer-file-name))
>> (replace-regexp-in-string "^\\*" (concat "*" stars)
>> (buffer-string)) #+end_src
>
> No, that's not what I want. What I'm talking about is extending org-mode
> conceptually with the concept of 0-level headlines, where the body of that
> "headline" would be everything before the first headline in a file, and where
> I could specify (for example) an attachment-directory and be able to use it
> with this new syntax to link to attached files. I guess I took it a bit far
> with the example of visualizing multiple files from a folder as separate
> headlines inside a single emacs-buffer though. It would be cool to be able to
> do that but my intention was more about introducing the 0-level headline
> concept.
>
> Thanks for your idea and suggestion though!
>
>>
>> Best,
>> Ihor
>
> Kind Regards,
> Gustav
>
signature.asc
Description: PGP signature
Re: [O] How to pass shell command result to :post source-block?
See the code below: #+NAME: ansi-escape-filter #+begin_src emacs-lisp :var data="" (with-temp-buffer (insert data) (ansi-color-apply-on-region (point-min) (point-max)) (buffer-string)) #+end_src #+RESULTS: ansi-escape-filter #+begin_src sh :dir /sudo:: :results output :post ansi-escape-filter(data=*this*) tree /var/spool/postfix/ #+end_src `:results output` is needed to avoid parsing the shell output as a table. `data=*this*` is needed to pass the output to `ansi-escape-filter`. You can also check the example in the org info page for the :post header argument. Best, Ihor stardiviner writes: > I want to processing the shell ANSI escaping characters correctly or > just filter them out for display result correctly in Emacs. > > Here is my try: > > #+NAME: ansi-escape-filter > #+begin_src emacs-lisp > (ansi-color-apply-on-region (point-min) (point-max)) > #+end_src > > #+begin_src sh :dir /sudo:: :post ansi-escape-filter > sudo tree /var/spool/postfix/ > #+end_src > > #+RESULTS[<2019-01-19 10:58:39> f6d16244322abbd4fbe01bfaa084ac6bdd66a62c]: > : nil > > The second source block's result is supposed to be result of command > =sudo tree /var/spool/postfix/= instead of =nil=. > > Can someone help me how to do this correctly? > > -- > [ stardiviner ] >I try to make every word tell the meaning what I want to express. > >Blog: https://stardiviner.github.io/ >IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 > > signature.asc Description: PGP signature
Re: [O] Interaction of Agenda with DEADLINE & SCHEDULED
Hi, There seems to be not much interest about this email, so I doubt that the described functionality will be added to org any time soon. However, let me try to give you some hints, which might be useful for your personal config. > For example, how would one create a custom agenda view that > > - shows all accomplished tasks within the DEADLINE last week > - shows all accomplished tasks that missed the DEADLINE last week > > Then does the same for the coming week, i.e. > > - show all tasks which are due in the next week, i.e., within the > DEADLINE > - show all tasks which are overdue There is org-super-agenda package (https://github.com/alphapapa/org-super-agenda), which already have a part of the functionality. You can use :scheduled and :deadline selectors as a starting point to achieve what you want. A more direct way to approach this is a custom skip function. As a starting point, see my own skip function for filter todo items with deadline, but scheduled in future: #+begin_src emacs-lisp (defun org-agenda-skip-deadlines-before-schedule () "Skip tasks, with deadline and scheduled in future and tasks without deadline." (require 'org-agenda) (org-with-wide-buffer (let* ((tmp-deadline-time (flet ((org-back-to-heading (&rest args) t)) ; we should be at heading already and it consumes too much cpu time otherwise (org-get-deadline-time (point (tmp-scheduled-time (org-get-scheduled-time (point))) (tmp-cur-deadline (time-to-days tmp-deadline-time)) (tmp-cur-schedule (time-to-days tmp-scheduled-time)) (tmp-cur-day (time-to-days (apply #'encode-time (append '(0 0 0) (list (nth 1 org-agenda-current-date)) (list (nth 0 org-agenda-current-date)) (list (nth 2 org-agenda-current-date))) (when (or (not tmp-deadline-time) (and tmp-scheduled-time tmp-deadline-time (> tmp-cur-schedule tmp-cur-day) ;;(> tmp-cur-deadline tmp-cur-day) )) (re-search-forward (org-get-limited-outline-regexp) nil 'noerror) (point) #+end_src > Ideally, the interaction could even be more informational, so for > example, analysis of the available work time next week (assuming 40 > hours for example) vs. the total estimated effort of all of the above > tasks, helping to answer the question of whether all tasks are even > achievable given the amount of available work time. > > Another potential -and very valuable- analysis could be a recommendation > of order given DEADLINE, priority and effort over a period of time, for > example the next week. What should one do first, then second, etc. to > maximize output over a given period of time? What you want here is actually quite a complicated optimization problem, which probably deserves a separate full project of its own. I cannot comment much on this part since effort estimates never worked for me. Best, Ihor Stephan Fabel writes: > When creating a custom agenda view, it is often desirable to express a > relationship between a given task and meaningful dates, such as DEADLINE > and SCHEDULED. It seems that with org-mode, and especially in the agenda > view, it is not (yet?) possible to express that. > > For example, how would one create a custom agenda view that > > - shows all accomplished tasks within the DEADLINE last week > - shows all accomplished tasks that missed the DEADLINE last week > > Then does the same for the coming week, i.e. > > - show all tasks which are due in the next week, i.e., within the > DEADLINE > - show all tasks which are overdue > > Ideally, the interaction could even be more informational, so for > example, analysis of the available work time next week (assuming 40 > hours for example) vs. the total estimated effort of all of the above > tasks, helping to answer the question of whether all tasks are even > achievable given the amount of available work time. > > Another potential -and very valuable- analysis could be a recommendation > of order given DEADLINE, priority and effort over a period of time, for > example the next week. What should one do first, then second, etc. to > maximize output over a given period of time? > > I have been looking for a discussion of these type of questions in the > documentation, worg and other places like EmacsWiki and haven't really > found anything. > > Thanks for any pointers, > > Stephan > > > > signature.asc Description: PGP signature
Re: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Dear Dmitrii, I strongly support the proposal. Another use case for me is to speed up agenda creation. I usually do not like to split my org files into too many. However, it results in very large and slow org buffers later. If I can store some parts of the org files externally and only show them if some condition is met (say, for certain todo state of the parent entry), it would speed up my agenda and the buffer navigation quite significantly. Example: #+begin_src org * Projects ** 2019 *** TODO Project 1 :ORG: # the project contents is stored in an external file :PROPERTIES: :ORG-FILE: project1.org :END: # beginning of a lense, which is linked to project1.org Heading 1 Heading 2 And many headings below # ... # end of the lense *** HOLD Project 2 :ORG: :PROPERTIES: :ORG-FILE: project2.org :END: # beginning of another lense # nothing is included here because the project state is =HOLD= # end of the lense #+end_src Let me put some historical context to this proposal. There was a discussion of similar feature in emacs-dev last year. The idea was to implement nested buffers: https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html There are also several projects, which implement part of the functionality you described: - mmm-mode: https://github.com/purcell/mmm-mode - polymode: https://github.com/polymode/polymode Best, Ihor Dmitrii Korobeinikov writes: > I have written a proposal for buffer lenses which could prove useful in > Org-mode, especially for interacting with code. > If you are interested, please, see this link: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35419 -- Ihor Radchenko, signature.asc Description: PGP signature
[O] bug#35419: Fwd: Re: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
--- Begin Message --- Dear Dmitrii, I strongly support the proposal. Another use case for me is to speed up agenda creation. I usually do not like to split my org files into too many. However, it results in very large and slow org buffers later. If I can store some parts of the org files externally and only show them if some condition is met (say, for certain todo state of the parent entry), it would speed up my agenda and the buffer navigation quite significantly. Example: #+begin_src org * Projects ** 2019 *** TODO Project 1 :ORG: # the project contents is stored in an external file :PROPERTIES: :ORG-FILE: project1.org :END: # beginning of a lense, which is linked to project1.org Heading 1 Heading 2 And many headings below # ... # end of the lense *** HOLD Project 2 :ORG: :PROPERTIES: :ORG-FILE: project2.org :END: # beginning of another lense # nothing is included here because the project state is =HOLD= # end of the lense #+end_src Let me put some historical context to this proposal. There was a discussion of similar feature in emacs-dev last year. The idea was to implement nested buffers: https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html There are also several projects, which implement part of the functionality you described: - mmm-mode: https://github.com/purcell/mmm-mode - polymode: https://github.com/polymode/polymode Best, Ihor Dmitrii Korobeinikov writes: > I have written a proposal for buffer lenses which could prove useful in > Org-mode, especially for interacting with code. > If you are interested, please, see this link: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35419 -- Ihor Radchenko, signature.asc Description: PGP signature --- End Message --- -- Ihor Radchenko, signature.asc Description: PGP signature
[O] bug#35453: 26.1; Poor performance of vertical-motion in large org buffer
Not sure why, but my reply did not show up in the mailing list. Resending. > I'm not sure I understand: is your problem with vertical-motion, or in > general with moving by lines in that file's buffer? The problem is actually more general. I had a poor performance on line motion, re-search-forward, and outline-based motion. However, performance of the latter commands seems to depend on the visibility state of the buffer. I was only able to reproduce the issue for vertical-motion. > So instead of skipping > all that hidden text in one go, vertical-motion loops over those 17.5K > overlays examining the properties of each one of them. And that takes > time. Make sense. Though it was very weird for me that I did not have a gradual performance degradation on that file. The motion suddenly became much slower in a single day (the file size did not change significantly). I do not remember for sure, but I suspect that it might have something to deal with org-lint, which somehow introduced extra property drawers in the file. > Of course, if someone comes up with ideas how to speed up > vertical-motion without changing what Org does with overlays and/or > how overlays are implemented, such ideas will be most welcome. Rather dumb idea. Currently, vertical-motion just loops over all the intervals in the buffer. What if we optimise next-single-char-property-change and use it in vertical-motion? Say, the interval data structure can extended. In addition to the currently available pointers to next and previous intervals, each (or just 'invisible') property of the interval might also contain a pointer to next/previous interval with different property value. Then, by increasing the structure size a bit, we can significantly speed up the buffer motion commands. Best, Ihor Eli Zaretskii writes: >> From: 'Ihor Radchenko' >> Date: Thu, 25 Apr 2019 14:23:06 +0800 >> >> C-n and C-p are extremely slow (>10 sec to move one visual line) when >> moving around a large org buffer in overview state, especially right >> after opening the file. >> The issue seems to be with low-level vertical-motion command - M-: >> (vertical-motion 1) also takes >10sec on some lines. >> >> Steps to reproduce (emacs -Q): >> 1. Open the attached org file >> 2. C-n, C-n, C-n, C-n >> 3. Observe emacs hanging for >10sec. > > I'm not sure I understand: is your problem with vertical-motion, or in > general with moving by lines in that file's buffer? > > If the problem is the latter, then my advice to Org users is to use > "C-c C-n/C-p" and "C-c C-f/C-b", not the normal cursor motion > commands, because Org makes the latter very slow when a large portion > of a large buffer is hidden. I will now try to explain why. > > This buffer's size is around 1MB and 42K lines, and the part between > the 3rd and the 4th heading holds its lion's share: almost 40K lines > of text. When C-n calls vertical-motion, the latter needs to find the > buffer position displayed directly below the place where you typed > C-n. Since much of the text between these places, vertical-motion > needs to skip the invisible text as quickly as possible, because from > the user's POV that text "doesn't exist": it isn't on the screen. > However, Org makes this skipping exceedingly hard, because (1) it uses > overlays (as opposed to text properties) to hide text, and (2) it puts > an awful lot of overlays on the hidden text: there are 18400 overlays > in this file's buffer, 17500 of them between the 3rd and the 4th > heading. Because of this, vertical-motion must examine each and every > overlay as it moves through the text, because each overlay can > potentially change the 'invisible' property of text, or it might have > a display string that needs to be displayed. So instead of skipping > all that hidden text in one go, vertical-motion loops over those 17.5K > overlays examining the properties of each one of them. And that takes > time. > > Profiling shows that 80%(!) of the CPU time is spent in the function > overlays_at which looks for overlays at a given buffer position, and > 10% more in marker_position (because overlay endpoints are markers). > So 90% of the time you wait for the cursor to move is spent processing > overlays. > > Compare this with Outline mode, which places a single overlay on the > entire hidden text between headings. If you visit the same file in > Outline mode, C-n will be much, much faster. > > So with the current implementation of Org and overlays, Org users are > well advised not to make such large bodies in their Org files, and if > they do, definitely not to use C-n and C-p for vertical motion. > > Of course, if someone comes up with ideas how to speed up > vertical-motion without changing what Org does with overlays and/or > how overlays are implemented, such ideas will be most welcome. -- Ihor Radchenko
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Dear Dmitrii, > Indirect buffers give the answer to the issue of sharing some textual data > between several buffer. Note that indirect buffers always share *all* the contents with the master buffer. As a result, it may not be easy to make things like flyspell work on code blocks in org-mode, if these code blocks are treated as lenses. > (1) A question: when an indirect buffer is created and some region is > narrowed to, is the rest of the buffer duplicated in memory somewhere? If > this is so, there could be a useful efficiency-related modification to > indirect buffers, which would allow "hard-narrowing": not duplicating the > rest of the base buffer. There is no duplication of the buffer content in indirect buffers. Internally, indirect buffer's content is a pointer to the main buffer content. If you modify text in any of the indirect buffers or in the main buffer, the text is modified in all of them and in the main buffer. Only the buffer-local variables are duplicated. You can refer to "27.11 Indirect Buffers" in the elisp manual for details. > The next immediately outstanding question is: > (2) how can "embedding" (of a buffer as a part of another buffer as an > area) be done efficiently? This could possibly be approached as two > problems: (i) displaying the area and (ii) interacting with it. > Any ideas? These issues have been discussed in https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html. As I remember, the discussion stopped without a clear conclusion. It was not clear how to separate the main buffer contents from the nested buffer (I treat them as analogue of the buffer lenses). Another issue was how the keymaps and buffer-local variables would interact when the point is within a lense. It was not clear what should be the priority. Best, Ihor Dmitrii Korobeinikov writes: > I found a clarification on how mmm-mode works. > > https://github.com/polymode/polymode/issues/187 >> mmm-mode also allows having multiple major modes depending on cursor > position in the buffer. However, it does not fully replace major mode > locally. This mode is only taking care about keymap, menu, local variables, > font-lock, and indentation. It does not really take care about the minor > modes and does not run the submode hooks either. > > Just to reiterate, polymode's idea is to switch between indirect buffers, > one for each major mode. > > OK, detail largely disregarded, I now can draw a bird-eye view comparison > between lenses and multi-mode modes. > > - Neither polymode nor mmm-mode treat a region as if it were truly on its > own in a seperate buffer. > > Effects: no stuff like seperate truncation options, implied syntax checking > and so on. > > - Moreover, the region must be a part of the buffer. > > Effects: no data sharing between buffers, no possibility of stitching > different buffers together, etc. > > Now, with these out of the way. > > Indirect buffers give the answer to the issue of sharing some textual data > between several buffer. > (1) A question: when an indirect buffer is created and some region is > narrowed to, is the rest of the buffer duplicated in memory somewhere? If > this is so, there could be a useful efficiency-related modification to > indirect buffers, which would allow "hard-narrowing": not duplicating the > rest of the base buffer. > > The next immediately outstanding question is: > (2) how can "embedding" (of a buffer as a part of another buffer as an > area) be done efficiently? This could possibly be approached as two > problems: (i) displaying the area and (ii) interacting with it. > Any ideas? -- Ihor Radchenko,
Re: [O] Structured links to headings with endless depth
Dear Michael, > ... I want self-explaining links with the already existing and > complete heading structure and don't want to add any ID, CUSTOM_ID or > <>. See this example: I am wondering why you are strictly against ID properties. The IDs can be set automatically. The property drawer can be hidden (see https://stackoverflow.com/questions/17478260/completely-hide-the-properties-drawer-in-org-mode) and will not clutter you org file. An arbitrary id link can be self-explaining if you add a proper link description: [[id:your_id][composer_1/work_1/movement_1]]. Moreover it is not fragile against refiling or duplicate entries. Best, Ihor Michael Brand writes: > Hi all > > On Wed, Mar 14, 2018 at 7:58 AM Michael Brand > wrote: > >> ,(arbitrarily more levels upwards) >> , * [...] >> ,* >> , * >> ,* TODO >> , * :5: >> ,- The tag 5 is my rating of this audio recording. >> ,- The audio recording is stored under the file path >> , [...]/.mp3 >> , >> ,* TODO [...] >> , - The theme is very similar to this prelude >> ,[[/://]]. >> ,* [...] >> , - [...] like in this piano concert >> ,[[/:/]]. > > Despite all the valuable recommendations in this thread I implemented > something simple for my very specific use case of a music database > where I want self-explaining links with the already existing and > complete heading structure and don't want to add any ID, CUSTOM_ID or > <>. See this example: > > #+begin_src org > ,#+STARTUP: oddeven showeverything > > Specs for outline path of links to a heading, any combinations allowed > including none: > - "/" delimits headings of adjacent levels. > - A leading "/" requires matching the top level heading. > - "//" delimits heading levels with 0 to n discarded heading levels > between them. > > Demo examples: > - Goes to tag 1: [[*Chopin/Prelude]] > - Goes to tag 2: [[*/Prelude]] > - Goes to tag 3: [[*d/c//b/a]] > - Goes to tag 4: [[*d/c/b/a]] > ,* Foo > ,** Bach > ,*** Prelude > ,** Chopin > ,*** Prelude :1: > ,* Prelude :2: > ,* d > ,** c > ,*** Bar > , Baz > ,* b > ,** a :3: > ,*** b > , a :4: > #+end_src > > Limitations of this simplified implementation: > - Export of links with a path to a heading is not supported. > - Links to a heading with "/" that existed before are broken. > - There may be other issues for your use case already discussed in the > current thread ( > http://lists.gnu.org/archive/html/emacs-orgmode/2018-03/msg00231.html > ). > > Due to the limitations this implementation is for private use only and > not meant to be commited upstream although the format of the attached > patches might imply that. > > Michael > From 3a594dfa9967ed4fd70aae04559dde757fb21b1b Mon Sep 17 00:00:00 2001 > From: Michael Brand > Date: Mon, 6 May 2019 18:17:52 +0200 > Subject: [PATCH 1/2] org-get-heading: New parameter no-cookie > > * lisp/ol.el (org-link-search): Remove regexps for comment and cookie. > * lisp/org.el (org-get-heading:): New parameter no-cookie used above. > --- > lisp/ol.el | 10 ++ > lisp/org.el | 11 +-- > 2 files changed, 11 insertions(+), 10 deletions(-) > > diff --git a/lisp/ol.el b/lisp/ol.el > index a6f76a39f..f5bd63e96 100644 > --- a/lisp/ol.el > +++ b/lisp/ol.el > @@ -1108,18 +1108,12 @@ of matched result, which is either `dedicated' or > `fuzzy'." > (format "%s.*\\(?:%s[ \t]\\)?.*%s" > org-outline-regexp-bol > org-comment-string > - (mapconcat #'regexp-quote words ".+"))) > - (cookie-re "\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]") > - (comment-re (format "\\`%s[ \t]+" org-comment-string))) > + (mapconcat #'regexp-quote words ".+" >(goto-char (point-min)) >(catch :found > (while (re-search-forward title-re nil t) >(when (equal words > - (split-string > -(replace-regexp-in-string > - cookie-re "" > - (replace-regexp-in-string > - comment-re "" (org-get-heading t t t) > + (split-string (org-get-heading t t t t t))) > (throw :found t))) > nil))) >(beginning-of-line) > diff --git a/lisp/org.el b/lisp/org.el > index 94713a7e5..48f7874ac 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -6938,12 +6938,14 @@ So this will delete or add empty lines." > (insert (make-string n ?\n)) > (move-to-column column))) > > -(defun org-get-heading (&optional no-tags no-todo no-priority no-comment) > +(defun org-get-heading (&optional > + no-tags no-todo no-priority no-comment no-cookie) >"Return the heading of the current entry, without the stars. > When NO-TAGS is non-nil, do
Re: [O] How to calculate all time durations in a file automatically?
Dear Martin, Just go to the beginning of buffer and (while (re-search-forward org-clock-line-re) (org-ctrl-c-ctrl-c)) . Or you can use keyboard macros ;) Best, Ihor Martin Schroeder writes: > I have imported a bunch of log lines with CLOCK periods from another > program into an org file but I have forgotten to calculate periods. So > my time lines look like this: > > CLOCK: [2019-03-27 Wed 19:30]--[2019-03-27 Wed 21:30] > > Instead of this: > > CLOCK: [2019-03-27 Wed 19:30]--[2019-03-27 Wed 21:30] => 2:00 > > I can now no longer check in on any task until I fix all these ranges > in all of my agenda files. So I have to go to each one and do C-c C-c. > > Surely there has to be a better way but in my searching with a giant > flashlight I was not able to find it yet. Can anybody point me in the > right direction? >
[O] bug#35453: 26.1; Poor performance of vertical-motion in large org buffer
> There are no intervals in this story. The way overlays are > implemented, they don't use intervals (if by that you mean the > facilities in intervals.c). Someone was working on making overlays > more efficient by changing the low-level implementation details, but > that work is yet unfinished. I see. Hope that overlays will be optimised eventually... Eli Zaretskii writes: >> From: Ihor Radchenko >> Cc: 35...@debbugs.gnu.org >> Date: Sun, 05 May 2019 09:05:46 +0800 >> >> > Of course, if someone comes up with ideas how to speed up >> > vertical-motion without changing what Org does with overlays and/or >> > how overlays are implemented, such ideas will be most welcome. >> >> Rather dumb idea. >> Currently, vertical-motion just loops over all the intervals in the >> buffer. What if we optimise next-single-char-property-change and use it >> in vertical-motion? Say, the interval data structure can extended. In >> addition to the currently available pointers to next and previous >> intervals, each (or just 'invisible') property of the interval might >> also contain a pointer to next/previous interval with different property >> value. Then, by increasing the structure size a bit, we can >> significantly speed up the buffer motion commands. > > There are no intervals in this story. The way overlays are > implemented, they don't use intervals (if by that you mean the > facilities in intervals.c). Someone was working on making overlays > more efficient by changing the low-level implementation details, but > that work is yet unfinished.
Re: [O] Structured links to headings with endless depth
> There must be good reasons why some more > users than just me sometimes prefer the format B over A: Fair enough. Thanks for the clarification. Best, Ihor Michael Brand writes: > Hi Ihor > > On Tue, May 7, 2019 at 5:27 AM Ihor Radchenko wrote: > >> I am wondering why you are strictly against ID properties. > > To me this looks like a misunderstanding. I use the ID often but my > weighting of the different advantages is not the same in all cases. > Some situations where no ID can be seen as an advantage: Looking at > the raw view (for example visible-mode during ediff), looking at the > raw file (when in the other world outside of Org mode), the time it > can take to not find an ID in all the ID files when the target file or > ID is not accessible, etc. There must be good reasons why some more > users than just me sometimes prefer the format B over A: > > #+name: A > #+begin_src org > - [[id:8e5c5d87-291e-469b-a8e4-15704610c82c][The heading name]] > ,* The heading name > :PROPERTIES: > :ID: 8e5c5d87-291e-469b-a8e4-15704610c82c > :END: > #+end_src > > #+name: B > #+begin_src org > - [[*The heading name]] > ,* The heading name > #+end_src > > Michael
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Dear Dmitrii, Regarding the question about buffer-lens interaction. Let's take even more complicated example: To run the command, the user hits some key combination, which happens to be bound to different commands in the main buffer and in the lense buffer (i.e. the main buffer is in org-mode, the lense is in mingus-mode, and the key is C-d). What should be the behaviour in such a case? run the commands in both the buffers? decide depending on the point position? It is easy to make up similar complicated examples if you consider some exotic major modes in the lense buffer. I think that it would be more effective if someone decide on some basic approach for the low-level implementation of the lense-mode (which probably involves modifying emacs C-level source code) and continue the discussion according to the benefits/limitations of that kind of implementation. Best, Ihor Dmitrii Korobeinikov writes: > Dear Ihor, > >> Note that indirect buffers always share *all* the contents with the master >> buffer. As a result, it may not be easy to make things like flyspell >> work on code blocks in org-mode, if these code blocks are treated as >> lenses. > > I tried flyspell w/ different dictionaries on 2 buffers. > The dictionary is switched every time I switch into one of the buffers. > You are right, ispell and the like working w/ a file directly would have to > learn to work w/ indirect buffers by managing multiple simultaneous > processes. > Fortunately, that doesn't seem like a big hurdle. > >>> (1) A question: when an indirect buffer is created and some region is >>> narrowed to, is the rest of the buffer duplicated in memory somewhere? If >>> this is so, there could be a useful efficiency-related modification to >>> indirect buffers, which would allow "hard-narrowing": not duplicating the >>> rest of the base buffer. >> >> There is no duplication of the buffer content in indirect buffers. >> Internally, indirect buffer's content is a pointer to the main buffer >> content. If you modify text in any of the indirect buffers or in the >> main buffer, the text is modified in all of them and in the main buffer. >> Only the buffer-local variables are duplicated. >> You can refer to "27.11 Indirect Buffers" in the elisp manual for >> details. > > Bad choice of wording on my side, I didn't mean duplication, but rather > keeping unnecessary info, like text properties in the newly created > indirect buffer, in the regions which were "permanently" chosen to be > narrowed-out. > Anyway, this is a premature optimization for now. > >> > The next immediately outstanding question is: >> > (2) how can "embedding" (of a buffer as a part of another buffer as an >> > area) be done efficiently? This could possibly be approached as two >> > problems: (i) displaying the area and (ii) interacting with it. >> > Any ideas? >> >> These issues have been discussed in >> https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html. >> As I remember, the discussion stopped without a clear conclusion. It was >> not clear how to separate the main buffer contents from the nested >> buffer (I treat them as analogue of the buffer lenses). Another issue >> was how the keymaps and buffer-local variables would interact when the >> point is within a lense. It was not clear what should be the priority. > > The short answer is probably that lens-mode looks at the changes to the > buffer and decides what's what. > Here is my vision for this. > > Say, you have an indirect buffer, call it A, it's base has contents: > >> line 1 >> line 2 >> line 3 > > Also, there is a buffer, call it B, where we want to embed A, with contents: > >> word 1 >> instruction: lens that displays A >> word 2 > > Lens-mode decides to identify the second line as a lens and constructs > layout of the file. > >> [text] >> [lens#A] >> [text] > > Now, construct and display the final buffer as: > >> word 1 >> line 1 >> line 2 >> line 3 >> word 2 > > The core question: how is this "displaying" done. > In part, somewhat like how indirect buffers function. > A displayed piece of text is a pointer/reference to the text in the > indirect buffer. > Of course, this should be done in a way so that the modes running in B > don't change the properties of the text (following the layout constructed > by lens-mode as in the example above). Though, this might better&easier be > done at the display unit level. > > What about interaction? > Well, when the cursor is inside the lens, the controller decides what to do > w/ each keybinding, whether to redirect it to the indirect buffer or not. > And what about the case when borders are crossed? > As I see it, any code that executes - does so as is. > For instance, consider a buffer with a lens (contents: "lens"), which looks > like this: "word1 lens word2". > Place the cursor on the first word, run a command to remove 2 words. > Now there are to possibilities here, depending on the implementation of the > function which does the removal: > 1.
[O] Bug: Inaccurate doc-string for org-image-actual-width [9.2.3 (9.2.3-17-g4df705-elpaplus @ /home/yantar92/.emacs.d/elpa/org-plus-contrib-20190513/)]
The doc-string for org-image-actual-width states that image width can be set using #+ATTR.* keyword (note that it is all capital letters). However, org-display-inline-images only looks for lower-case #+attr_: (re-search-forward "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)" (org-element-property :post-affiliated paragraph) t) If case-fold-search is set to 't, and the value of org-image-actual-width is set to a list, #+ATTR_ORG: :width specifications are always ignored, while they should not. Best, Ihor Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit) of 2019-04-29 Package: Org mode version 9.2.3 (9.2.3-17-g4df705-elpaplus @ /home/yantar92/.emacs.d/elpa/org-plus-contrib-20190513/) -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
[O] Bug: Incorrect behaviour of org-schedule when defining a time interval [9.2.3 (9.2.3-17-g4df705-elpaplus @ /home/yantar92/.emacs.d/elpa/org-plus-contrib-20190513/)]
When defining a time interval using org-schedule, I can usually type something like "2pm+2" and get "SCHEDULED: <2019-07-09 Tue 14:00-16:00>". However, typing "11pm+2" leads to incorrect behaviour. The result is "SCHEDULED: <2019-07-09 Tue 23:00-25:00>", which is obviously wrong. Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit) of 2019-04-29 Package: Org mode version 9.2.3 (9.2.3-17-g4df705-elpaplus @ /home/yantar92/.emacs.d/elpa/org-plus-contrib-20190513/)
Re: [O] Bug: Incorrect behaviour of org-schedule when defining a time interval [9.2.3 (9.2.3-17-g4df705-elpaplus @ /home/yantar92/.emacs.d/elpa/org-plus-contrib-20190513/)]
Thanks for the clarification. I never saw this format earlier. Matthew Piziak writes: >> obviously wrong > > It's natural to think so, but my Org mode correctly interprets `Tue > 25:00` as being equivalent to `Wed 01:00`. That includes agenda > scheduling filters. > > This format is used in the real world sometimes too, especially for > things like TV showings that span across the midnight boundary, as in > your example.
Re: [O] Bug: Incorrect behaviour of org-schedule when defining a time interval [9.2.3 (9.2.3-17-g4df705-elpaplus @ /home/yantar92/.emacs.d/elpa/org-plus-contrib-20190513/)]
> That includes agenda scheduling filters. I recently tried to use the format. Actually, agenda fails to recognise schedule interval like "SCHEDULED: <2019-07-23 Tue 23:00-29:00>". The task is not shown in agenda view with error "org-duration-to-minutes: Invalid duration format: "+5:00"". The problem is reproducible with emacs -Q. Best, Ihor Matthew Piziak writes: >> obviously wrong > > It's natural to think so, but my Org mode correctly interprets `Tue > 25:00` as being equivalent to `Wed 01:00`. That includes agenda > scheduling filters. > > This format is used in the real world sometimes too, especially for > things like TV showings that span across the midnight boundary, as in > your example.
Re: [O] [RFC] Link-type for attachments, more attach options
Hi, > ATTACH_DIR_INHERIT is no longer supported and is +removed. I just found that removing ATTACH_DIR_INHERIT broke my current configuration. I do not use ATTACH_DIR property - all the attachment folders are created using ID. Also, I use ID property to store links to entries. Therefore, inheriting ATTACH_DIR does nothing for me and inheriting ID always gives the current entry's id value. At the end, I cannot make a common attachment directory for the whole subtree, like I was able to do with ATTACH_DIR_INHERIT. Regards, Ihor Gustav Wikström writes: > Hi! > >> > + (if should-get >> > + (progn (message "Running git annex get \"%s\"." path-relative) >> > + (call-process "git" nil nil nil "annex" "get" path-relative)) >> > +(error "File %s stored in git annex but it is not available, and was >> > not >> retrieved" >> > + path)) >> >> Nitpick: >> >> (unless should-get >> (error "File %S stored in git annex but unavailable" path)) >> (message "Running git annex get %S." path-relative) >> (call-process ...) > > Ok, fixed. > >> > +Selective means to respect the inheritance setting in >> > +`org-use-property-inheritance'." >> >:group 'org-attach >> > + :type '(choice >> > +(const :tag "Don't use inheritance" nil) >> > +(const :tag "Inherit parent node attachments" t) >> > +(const :tag "Respect org-use-property-inheritance" selective) >> > +) >> >> Dangling paren spotted. > > Fixed. > >> > + (setq attachment (or (org-attach-dir) >> > + (quote "Can't find an existing attachment-folder"))) >> >> You forgot to remove that weird quote. Maybe you meant `error'? > > Hmm, actually no. But the code is pretty bad so I've refactored it a > bit. The purpose of the change is for org-attach to give an indication > of the active attachment path, or to signal that there is none. But > for that I don't really need a separate variable. Thus it's slightly > refactored for code-clarity. > >> > +(if attach-dir >> > + (progn (if (not (file-directory-p attach-dir)) >> > + (make-directory attach-dir t)) >> > + attach-dir) >> > + (error "No attachment directory is associated with the current >> > node" >> >> Same nitpick as above: >> >> (unless attach-dir >> (error "No attachment ...")) >> (if (file-directory-p attach-dir) attach-dir >> (make-directory attach-dir)) > > Ok, fixed. > >> > +(defun org-attach-dir-from-id (id) >> > + "Creates a path based on `org-attach-id-dir' and ID." >> > + (expand-file-name >> > + (funcall org-attach-id-to-path-function id) >> > + (expand-file-name org-attach-id-dir))) >> >> Creates path -> Return a file name. > > Fixed. > >> > +of the entry. Creates relative links if `org-attach-dir-relative' >> > +is t. >> >> Nitpick: >> >> is t -> is non-nil. > > Ah, true. Fixed. > >> If tests pass, feel free to apply the patches in master. Thank you! > > Got it. Aaand one test failure. That test is unrelated to my changes > though, and fails also on master. Test-org-table/copy-down. So I'll > try to apply my patch asap regardless of that one test failing. > > Just one more thing - a few days back I added a row to lisp/ox-html.el > regarding inline-images. I'm including that change as well since it > relates 100% to the new attachment link. I looked in the other > export-backends too but didn't add anything due to lack of time for > testing. Maybe the additions for other backends is as trivial as for > html. So someone who regularly export to those backends might want to > suggest patches for them to make attachment links to images actually > display as images? > > Final patches attached for full disclosure before applying them. > >> >> Regards, >> >> -- >> Nicolas Goaziou > From 3cbe356b0a9d1a98848df0fa09ba306392995b88 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Gustav=20Wikstr=C3=B6m?= > Date: Sun, 26 May 2019 03:34:34 +0200 > Subject: [PATCH 1/2] org-test, test-org-element, test-org, test-ox, > test-property-inheritance > > * org-test.el: > > Fix org-test-with-temp-text-in-file. Make it work with , as > some tests already expect it to do! Also make it fail more gracefully > by still removing temporary buffers and files. > > Improve org-test-in-example-file. Make it behave similar to > org-test-with-temp-text and org-test-with-temp-text-in-file, in that > it will return the last evaluated expression. > > * testing/lisp/test-org-element.el > > Fix a temp-text strings so that it doesn't have an initial newline. > > * testing/lisp/test-org.el > > Minor cleanup to align code-structure with other tests. Nothing > changes in the test execpt style. > > * testing/lisp/test-ox.el > > Fix a couple of temp-text strings so that they don't have initial > newlines. > > ** test-org-export/expand-include > > Test specification was wrong, due to org-test-with-temp-text-in-file > not previously working with . Since that is fixed in this > patch the
Re: [O] [RFC] Link-type for attachments, more attach options
Dear Gustav, Thanks for the update. For now, I fixed the problem for me with the following advice: #+begin_src emacs-lisp (define-advice org-attach-dir (:filter-return (dir) yant/org-attach-use-attach-dir-inheritance -100) "Use :ATTACH_DIR_INHERIT: property." (let ((attach-dir-inherited (and (org-entry-get-with-inheritance "ATTACH_DIR_INHERIT") (not (org-entry-get (point) "ATTACH_DIR_INHERIT" nil)) (org-with-point-at org-entry-property-inherited-from (org-attach-dir) (or attach-dir-inherited dir))) #+end_src Regards, Ihor Gustav Wikström writes: > Hi Ihor, > >> -Original Message- >> From: Ihor Radchenko >> Sent: den 27 juli 2019 16:56 >> To: Gustav Wikström ; Nicolas Goaziou >> >> Cc: emacs-orgmode@gnu.org >> Subject: Re: [O] [RFC] Link-type for attachments, more attach options > >> I just found that removing ATTACH_DIR_INHERIT broke my current >> configuration. I do not use ATTACH_DIR property - all the attachment >> folders are created using ID. Also, I use ID property to store links to >> entries. Therefore, inheriting ATTACH_DIR does nothing for me and >> inheriting ID always gives the current entry's id value. At the end, I >> cannot make a common attachment directory for the whole subtree, like I >> was able to do with ATTACH_DIR_INHERIT. > > Ah, yes. That is an unfortunate side effect of ID properties having > other use-cases outside of attachments. I thought about that for some > time during the development but didn't get to implement any solution > for it. The way I thought to do it was to create an algorithm that > looks through the outline hierarchy at successively lower hierarchy > for an ID property that has a corresponding attachment folder. If no > folder exist for the ID attribute at the given level, the inherit > functionality would continue to look at a lower level until a folder > was found. I imagined the algorithm to look for both ID and DIR > properties at each level and stop at the first property that had an > existing attachment folder, with DIR taking precedence at each level > if for some reason both ID and DIR based folders existed. > > Adding such functionality means going outside the scope of current > property inheritance in Org mode. It adds some complexity but maybe > it's warranted to do so here? But, as mentioned, I only got to the > point of thinking about it, I didn't implement it. > > If someone wants to take up the challenge of implementing it then the > starting point should be to modify org-attach-dir, replacing > org-entry-get with something similar to the algorithm mentioned above. > > I might get to it at some point as well, but my motivation lies > elsewhere right now (document-level stuff... see other threads by > me). > > Kind regards > Gustav
Re: [O] Links in Org-mode : Clunky
Dear Nathan, > Has anyone coded such a plugin or am I missing some cool Helm-fu? Not exactly the same, but see the code below. Note that the code does not support creating CUSTOM_ID. Instead, it silently creates an ID if it does not exist (see (org-id-get ... 'create)). The helm completion will work if it is enabled globally. #+begin_src emacs-lisp (defvar org-id-history nil "ID completion history for id: link type.") (defvar org-id-cache nil "ID completion cache for id: link type.") (defun org-id-prompt-id () "Prompt for the id during completion of att-id: link." (let ((org-refile-history org-id-history) (org-refile-cache org-id-cache) (org-refile-target-verify-function nil)) (let ((prompt-ans (org-refile-get-location "Select org entry"))) (prog1 (or (org-id-get (seq-find #'markerp prompt-ans) 'create) (user-error "Cannot find ID of the entry: %s" prompt-ans)) (setq org-id-history org-refile-history) (setq org-id-cache org-refile-cache) (defun org-id-link-complete (&optional arg) "Completion function for id: link." (let* ((id (org-id-prompt-id))) (format "id:%s" id))) (org-link-set-parameters "id" :complete #'org-id-link-complete) #+end_src Regards, Ihor Nathan Neff writes: > Hello all, > > I've always found that the links in org-mode are basically > very clunky to try to use in a quick fashion. > > To my understanding (see my other question about CUSTOM_ID > versus ID) it's a good practice to store either a CUSTOM_ID or ID > - (still can't grok the difference) and then store a hyperlink to that > CUSTOM_ID or ID. > > By storing a hyperlink to CUSTOM_ID or ID my heading can change, > but this won't matter. I can also move the heading to another file, and > links > to it will still work. > > However, I find that it's pretty clunky to store a CUSTOM_ID or ID > for a heading, and then copy the link, and then paste it where I want to > use it. Granted, it's not very difficult using org-store-link and > org-insert-link, > but it's just not as easy as I would think it would be. > > I've recently stumbled on Helm and was wondering if anyone has coded some > kind of function that would show me a list of my headings, and create a > CUSTOM_ID > or ID for the heading and then copy a link to that heading so that I could > easily paste it. > > Let's say I'm typing some stuff and want to insert a link to another > heading, I would > press some key combo and a helm search would come up. I would find the > heading that > I want to link to. If the heading has a CUSTOM_ID property, then a link to > that CUSTOM_ID > would be inserted at the text where my cursor is. If there's not a > CUSTOM_ID property perhaps a prompt for a CUSTOM_ID could pop up. Once I > enter the CUSTOM_ID, the link is created and copied to my cursor location / > clipboard. > > Has anyone coded such a plugin or am I missing some cool Helm-fu? > > Thanks, > --Nate
[O] [Feature proposal] Add :description function to org-link-parameters
Hi,
Wondering if anyone is interested in adding a new org-link property to
customise generating the link description.
For now, there is global org-link-make-description-function, which is
shared among all the link types. If would be more convenient if the
description function can be set independently for different link types.
I propose to use :description property in org-link-parameters. A sample
implementation working with current org version is below:
#+begin_src emacs-lisp
(defun yant/org-make-link-description-function (link desk)
"Return description of the link LINK according to :description link property.
Return DESK if :desk is not set."
(let ((fun (org-link-get-parameter (car (split-string link ":"))
:description)))
(if (functionp fun)
(funcall fun link desk)
desk)))
(setq org-make-link-description-function
#'yant/org-make-link-description-function)
#+end_src
Example usage:
#+begin_src emacs-lisp
(defun org-id-link-desk (link desk)
"Description function for id: link."
(let ((id (cadr (split-string link ":"
(org-with-point-at (org-id-find id 'marker)
(s-replace "||" "/" (yant/task-fulltitle)
(org-link-set-parameters "id"
:desk #'org-id-link-desk)
#+end_src
Best,
Ihor
--
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: [O] [Feature proposal] Add :description function to org-link-parameters
Oops. Indeed, :desk should be replaced with :description. I used :desk property in my personal config, but it may be confusing for others. Best, Ihor John Kitchin writes: > This sounds reasonable. I was a little confused with the mixture of > of description and desk in the code below. If you replace desk with > description everywhere in your code is that what you mean? > > Ihor Radchenko writes: > >> Hi, >> >> Wondering if anyone is interested in adding a new org-link property to >> customise generating the link description. >> >> For now, there is global org-link-make-description-function, which is >> shared among all the link types. If would be more convenient if the >> description function can be set independently for different link types. >> >> I propose to use :description property in org-link-parameters. A sample >> implementation working with current org version is below: >> >> #+begin_src emacs-lisp >> (defun yant/org-make-link-description-function (link desk) >> "Return description of the link LINK according to :description link >> property. >> Return DESK if :desk is not set." >> (let ((fun (org-link-get-parameter (car (split-string link ":")) >> :description))) >> (if (functionp fun) >> (funcall fun link desk) >> desk))) >> >> (setq org-make-link-description-function >> #'yant/org-make-link-description-function) >> #+end_src >> >> Example usage: >> >> #+begin_src emacs-lisp >> (defun org-id-link-desk (link desk) >> "Description function for id: link." >> (let ((id (cadr (split-string link ":" >> (org-with-point-at (org-id-find id 'marker) >> (s-replace "||" "/" (yant/task-fulltitle) >> >> (org-link-set-parameters "id" >> :desk #'org-id-link-desk) >> #+end_src >> >> Best, >> Ihor > > > -- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu > -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
[O] Bug: org-sort-entries does not preserve folded drawers [9.1.13 (9.1.13-dist @ /home/yantar92/.emacs.d/straight/build/org/)]
org-sort-entries seems to unfold everything in the subtree even if no modification was done to the buffer during sorting. Steps to reproduce: Consider the following org file: #+begin_src org ,* a :PROPERTIES: :ID: 279e797c-f4a7-47bb-80f6-e72ac6f3ec55 :END: :DRAWER: Blah :END: ,** test #+end_src 1. emacs -Q 2. Fold all the drawers and entries in the buffer 3a. Call M-x org-sort-entries p 3b. Call M-: (org-sort-entries nil ?p) RET Expected behaviour for 3a: Subtree is unfolded, all the property drawers are folded, buffer is unchanged Observed behaviour for 3a: Subtree is unfolded, all the property drawers are also unfolded, buffer is marked modified Expected behaviour for 3b: Subtree is folded, all the property drawers are folded, buffer is unchanged Observed behaviour for 3b: Subtree is unfolded, all the property drawers are also unfolded, buffer is marked modified Regards, Ihor Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit) of 2019-04-29 Package: Org mode version 9.1.13 (9.1.13-dist @ /home/yantar92/.emacs.d/straight/build/org/) -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: [O] Bug: org-sort-entries does not preserve folded drawers [9.1.13 (9.1.13-dist @ /home/yantar92/.emacs.d/straight/build/org/)]
Thanks! Carsten Dominik writes: > Hi Ihor, > > thank you for the report. > It would be too much work to *preserve* the visibility state of everything > in the sorting area, but you are right, the drawers at lease should be > closed. I fixed this, the fix is in master. > > Carsten > > On Sat, Aug 3, 2019 at 8:22 AM Ihor Radchenko wrote: > >> >> org-sort-entries seems to unfold everything in the subtree even if no >> modification was done to the buffer during sorting. >> >> Steps to reproduce: >> >> Consider the following org file: >> #+begin_src org >> ,* a >> :PROPERTIES: >> :ID: 279e797c-f4a7-47bb-80f6-e72ac6f3ec55 >> :END: >> :DRAWER: >> Blah >> :END: >> >> ,** test >> #+end_src >> >> 1. emacs -Q >> 2. Fold all the drawers and entries in the buffer >> 3a. Call M-x org-sort-entries p >> 3b. Call M-: (org-sort-entries nil ?p) RET >> >> >> Expected behaviour for 3a: Subtree is unfolded, all the property drawers >> are folded, buffer is unchanged >> Observed behaviour for 3a: Subtree is unfolded, all the property drawers >> are also unfolded, buffer is marked modified >> >> Expected behaviour for 3b: Subtree is folded, all the property drawers >> are folded, buffer is unchanged >> Observed behaviour for 3b: Subtree is unfolded, all the property drawers >> are also unfolded, buffer is marked modified >> >> Regards, >> Ihor >> >> >> >> >> Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit) >> of 2019-04-29 >> Package: Org mode version 9.1.13 (9.1.13-dist @ >> /home/yantar92/.emacs.d/straight/build/org/) >> -- >> Ihor Radchenko, >> PhD, >> Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) >> State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong >> University, Xi'an, China >> Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg >> >> >> -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Bug: Agenda fails to parse time interval like 23:00-29:00 [9.1.9 (release_9.1.9-65-g5e4542 @ /home/yantar92/.emacs.d/straight/build/org/)]
I have one scheduled item like the following:
* test
<2019-12-05 Thu 23:00-29:00>
This kind of item fails to be parsed by agenda because of incorrect
treatment of 23:00-29:00 time interval
Specifically, calling
(org-agenda-format-item nil #("test" 0 3 (face org-level-1 org-category
"schedule" fontified t)) " " "schedule" nil #("<2019-12-02 Mon 23:00-29:00>"
... ) ...)
yields (org-get-time-of-day "29:00" 'string t) -> "+5:00", which is then
passed to (org-duration-to-minutes "+5:00"), resulting in error.
Regards,
Ihor
Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0)
of 2019-11-25
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/home/yantar92/.emacs.d/straight/build/org/)
Re: Bug: Agenda fails to parse time interval like 23:00-29:00 [9.1.9 (release_9.1.9-65-g5e4542 @ /home/yantar92/.emacs.d/straight/build/org/)]
> What makes you think the time interval above is correct? I would also > expect an error from that time specification. I also thought that it is incorrect (and posted a bug report since it is what is produced by typing 11pm+6 in org-read-date). However, I got a reply that 23:00-29:00 is a valid time interval format [1]. Best, Ihor [1] https://lists.gnu.org/archive/html/emacs-orgmode/2019-07/msg00039.html Nicolas Goaziou writes: > Hello, > > 'Ihor Radchenko' writes: > >> I have one scheduled item like the following: >> >> * test >> <2019-12-05 Thu 23:00-29:00> >> >> This kind of item fails to be parsed by agenda because of incorrect >> treatment of 23:00-29:00 time interval > > What makes you think the time interval above is correct? I would also > expect an error from that time specification. > > Regards, > > -- > Nicolas Goaziou
Re: Bug: Agenda fails to parse time interval like 23:00-29:00 [9.1.9 (release_9.1.9-65-g5e4542 @ /home/yantar92/.emacs.d/straight/build/org/)]
[Resending without a link since your mail server classified my previous message as spam] > What makes you think the time interval above is correct? I would also > expect an error from that time specification. I also thought that it is incorrect (and posted a bug report since it is what is produced by typing 11pm+6 in org-read-date). However, I got a reply that 23:00-29:00 is a valid time interval format (see "Bug: Incorrect behaviour of org-schedule when defining a time in"). Best, Ihor Nicolas Goaziou writes: > Hello, > > 'Ihor Radchenko' writes: > >> I have one scheduled item like the following: >> >> * test >> <2019-12-05 Thu 23:00-29:00> >> >> This kind of item fails to be parsed by agenda because of incorrect >> treatment of 23:00-29:00 time interval > > What makes you think the time interval above is correct? I would also > expect an error from that time specification. > > Regards, > > -- > Nicolas Goaziou
Asynchronous org-agenda-redo
I am thinking if it is possible to implement org-agenda-redo asynchronously. Rebuilding agenda should normally not affect any buffer except agenda buffer. So, it should be sufficient to block any agenda modifying commands in the agenda buffer, redo the agenda buffer in separate thread, and replace the old agenda with the calculated one. Then, emacs should remain responsive while updating agenda (except for modifying the agenda buffer). For example, this naive code kind of works (forgetting that buffer-local variables will not be passed to the thread): (define-advice org-agenda-redo (:around (oldfun &optional all) make-async) (make-thread oldfun "org-agenda-redo")) The problem is that emacs does not become responsive... Another approach would be using async.el package, which allows calling arbitrary function in subordinate emacs process. Then, the main emacs instance should not be "frozen" (I use same approach for tangling and it works fine). However, the question is how to pass the .org and agenda buffers to this subordinate process. Opening the .org files there is not a good option since it would give too much overhead to this asynchronous agenda. Any suggestions? Alternative ideas? Best, Ihor
Re: Asynchronous org-agenda-redo
Hi Diego, > I cannot answer your question, but I am curious about using async together > with tangling, since for some of my buffers, tangling takes some time and > freezes Emacs in the process. Do you have some examples of this that you > could share? See the relevant code from my config below. Let me know if you have any questions or suggestions. Also, my config is written in the way that everything related to user interaction can be disabled if I load emacs for tangling (with org-tangle-flag). This is to speed up the async process. #+begin_src emacs-lisp (defvar yant/org-babel-tangle-async-process-list nil "Plist of (file . process) for all the currently running async tangle processes.") (defun yant/org-babel-tangle-async (file &optional target-file lang) "Invoke `org-babel-tangle-file' asynchronously." (require 'async) (let ((oldproc (plist-get yant/org-babel-tangle-async-process-list file))) (when (or (not oldproc) (async-wait oldproc)) (message "Tangling %s..." (buffer-file-name)) (plist-put yant/org-babel-tangle-async-process-list file (async-start (let ((args (list file target-file lang))) `(lambda () (require 'org) (setq org-tangle-flag t) (load "~/.emacs.d/config.el") (apply #'org-babel-tangle-file ',args))) (let ((message-string (format "Tangling (%S %S %S) completed." file target-file lang))) `(lambda (result) (message ,message-string (defvar yant/auto-tangle-list nil "List of files, which can be safely tangled on save. The list is saved between Emacs sessions.") (when init-flag (use-package savehist :config (add-to-list 'savehist-additional-variables 'yant/auto-tangle-list)) (savehist-mode +1) (defun yant/toggle-buffer-auto-tangle (arg) "Toggle auto tangling of a buffer." (interactive "P") (if (not (eq major-mode 'org-mode)) (message "Org-mode is not active in buffer \"%s\"" (buffer-name)) (cond ((not arg) (if (member (buffer-file-name) yant/auto-tangle-list) (progn (setq yant/auto-tangle-list (delete (buffer-file-name) yant/auto-tangle-list)) (message "Auto tangling disabled for %s" (buffer-file-name))) (add-to-list 'yant/auto-tangle-list (buffer-file-name)) (message "Auto tangling enabled for %s" (buffer-file-name ((or (and (not (listp arg)) (> arg 0)) (equal arg '(4))) (add-to-list 'yant/auto-tangle-list (buffer-file-name)) (message "Auto tangling enabled for %s" (buffer-file-name))) (t (setq yant/auto-tangle-list (delete (buffer-file-name) yant/auto-tangle-list)) (message "Auto tangling disabled for %s" (buffer-file-name)) (bind-key "C-c C-*" #'yant/toggle-buffer-auto-tangle org-mode-map)) (defun yant/org-babel-tangle-current-buffer-async () "Tangle current buffer asynchronously." (when (and (eq major-mode 'org-mode) (member (buffer-file-name) yant/auto-tangle-list)) (yant/org-babel-tangle-async (buffer-file-name (add-hook 'after-save-hook #'yant/org-babel-tangle-current-buffer-async) #+end_src Diego Zamboni writes: > Hi Ihor, > > I cannot answer your question, but I am curious about using async together > with tangling, since for some of my buffers, tangling takes some time and > freezes Emacs in the process. Do you have some examples of this that you > could share? > > Thanks, > --Diego > > > On Thu, Dec 12, 2019 at 9:21 AM Ihor Radchenko wrote: > >> I am thinking if it is possible to implement org-agenda-redo >> asynchronously. >> >> Rebuilding agenda should normally not affect any buffer except agenda >> buffer. So, it should be sufficient to block any agenda modifying >> commands in the agenda buffer, redo the agenda buffer in separate >> thread, and replace the old agenda with the calculated one. >> Then, emacs should remain responsive while updating agenda (except for >> modifying the agenda buffer). >> >> For example, this naive code kind of works (forgetting that buffer-local >> variables will not be passed to the thread): >> >> (define-advice org-agenda-redo (:around (oldfun &optional all) make-async) >> (make-thread oldfun "org-agenda-redo")) >> >> The problem is that emacs does not become responsive... >> >> Another approach would be using asyn
Re: Asynchronous org-agenda-redo
oo long to refresh, you might > consider org-ql's views/saved-searches as an alternative. The built-in > caching in org-ql significantly improves performance, especially when > refreshing views. > > -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: Asynchronous org-agenda-redo
> Org Agenda code does not wait for keyboard input; it's busy building the > agenda. This is the case with most code in Emacs: it's not written to > be asynchronous, and it doesn't return to the main thread until done. > So you can sprinkle yields here and there and maybe be able to move > point around while some code is running, but that will decrease > performance, as well as introducing another level of complexity and > another class of bugs (e.g. what if the user modifies a buffer while the > agenda code is scanning it?). Thanks for the explanation. > AFAIK there exists no way to do such a thing. Buffers are not designed > to be serialized/deserialized like that. You could try writing some > Elisp code to do it, but the end result would probably be much slower > than existing agenda code, as well as more difficult to debug. Yeah. Even re-initialisation of, for example, overlays in org buffer is likely to take too much time. > As you can see in org-agenda.el, it's complicated. Remember that an > Emacs process is like a Lisp image, full of state. The more symbols and > other structures you copy to the async Emacs process (by printing and > reading them as text, remember), the slower it's going to be--and it > will always be slower than not using async. > Asynchronous code is not faster; it's generally slower because of > yielding and synchronization. I see now that generating agenda in separate process will cause too much overheads. Anyway, I will try to throw yields into agenda code just to check how bad the performance can degrade. > org-ql doesn't use skip functions, just queries. Skip functions are essentially used-defined queries as soon as the queries are tested against every headline. I can rewrite my skip functions into queries, but I don't expect much improvement since org-ql seems to use org-entry-get, which is the main performance bottleneck for my agenda generation. Best, Ihor adam Porter writes: > Ihor Radchenko writes: > >>> Be sure to read the Emacs Lisp manual regarding threads. They are >>> cooperative, so functions called as threads must yield back to the main >>> thread for Emacs to do anything else before the function returns. >> >> I tried to read the manual, but I clearly misunderstand something. >> The manual says: >> >>> Currently, thread switching will occur upon explicit request via >>> ‘thread-yield’, when waiting for keyboard input... >> >> So, except directly calling thread-yield, it should be possible to >> trigger switching the current thread when keyboard input is expected. >> I tried the following demo code: >> >> (defun test () >> (let ((a 0)) >> (dotimes (_ 5) >> (setq a (1+ a)) >> (sleep-for 2) >> (message "%s" a >> >> (progn ;This should return to command loop quickly >> (make-thread #'test) >> (message "Executed...")); `eval-last-sexp' here >> >> I can move around the buffer while the progn is running. >> However, it is not the case with `org-agenda-redo' for a reason I do not >> fully understand. > > Org Agenda code does not wait for keyboard input; it's busy building the > agenda. This is the case with most code in Emacs: it's not written to > be asynchronous, and it doesn't return to the main thread until done. > So you can sprinkle yields here and there and maybe be able to move > point around while some code is running, but that will decrease > performance, as well as introducing another level of complexity and > another class of bugs (e.g. what if the user modifies a buffer while the > agenda code is scanning it?). > >>> 1. The process would have to load the same Org buffers, which takes >>> time, especially in large buffers. Depending on configuration, it >>> can take some time, indeed. >> >>> 3. Ensuring that configuration and state between the main Emacs process >>> and the separate, agenda-generating process is not necessarily >>> simple. Consider as well that if a buffer had unsaved changes, >>> those would not be readable by the other process, which would lead >>> to invalid results. One could force the buffers to be saved first, >>> but that may not always be desirable, as saving buffers can have >>> side effects. >> >> Why cannot org-buffer simply be copied into the subordinate process? If >> all be buffer-locals, text properties, and overlays are copied directly >> from the main emacs process, there may be no need to even initialise >> org-mode (the idea is to do something
Re: Asynchronous org-agenda-redo
>> Asynchronous code is not faster; it's generally slower because of >> yielding and synchronization. > Anyway, I will try to throw yields into agenda code just to check how > bad the performance can degrade. With the following code, org-agenda-redo runs for 21 second on my system, while without threads it is 16 seconds. However, emacs remains responsive during rebuilding agenda! (define-advice org-agenda-redo (:around (oldfun &optional all) make-async) (make-thread (lambda () (funcall oldfun all)) "org-agenda-redo")) (define-advice org-agenda-skip-eval (:around (oldfun form) make-async) (thread-join (make-thread (lambda () (funcall oldfun form)) "org-agenda-skip-eval"))) The problem, of course, is that touching agenda buffer and org buffers may be risky while org-agenda-redo is running. Wondering if it is possible to block user commands during that time. Best, Ihor Ihor Radchenko writes: >> Org Agenda code does not wait for keyboard input; it's busy building the >> agenda. This is the case with most code in Emacs: it's not written to >> be asynchronous, and it doesn't return to the main thread until done. >> So you can sprinkle yields here and there and maybe be able to move >> point around while some code is running, but that will decrease >> performance, as well as introducing another level of complexity and >> another class of bugs (e.g. what if the user modifies a buffer while the >> agenda code is scanning it?). > > Thanks for the explanation. > >> AFAIK there exists no way to do such a thing. Buffers are not designed >> to be serialized/deserialized like that. You could try writing some >> Elisp code to do it, but the end result would probably be much slower >> than existing agenda code, as well as more difficult to debug. > > Yeah. Even re-initialisation of, for example, overlays in org buffer is > likely to take too much time. > >> As you can see in org-agenda.el, it's complicated. Remember that an >> Emacs process is like a Lisp image, full of state. The more symbols and >> other structures you copy to the async Emacs process (by printing and >> reading them as text, remember), the slower it's going to be--and it >> will always be slower than not using async. > >> Asynchronous code is not faster; it's generally slower because of >> yielding and synchronization. > > I see now that generating agenda in separate process will cause too much > overheads. > Anyway, I will try to throw yields into agenda code just to check how > bad the performance can degrade. > >> org-ql doesn't use skip functions, just queries. > > Skip functions are essentially used-defined queries as soon as the > queries are tested against every headline. > I can rewrite my skip functions into queries, but I don't expect much > improvement since org-ql seems to use org-entry-get, which is the main > performance bottleneck for my agenda generation. > > Best, > Ihor > > adam Porter writes: > >> Ihor Radchenko writes: >> >>>> Be sure to read the Emacs Lisp manual regarding threads. They are >>>> cooperative, so functions called as threads must yield back to the main >>>> thread for Emacs to do anything else before the function returns. >>> >>> I tried to read the manual, but I clearly misunderstand something. >>> The manual says: >>> >>>> Currently, thread switching will occur upon explicit request via >>>> ‘thread-yield’, when waiting for keyboard input... >>> >>> So, except directly calling thread-yield, it should be possible to >>> trigger switching the current thread when keyboard input is expected. >>> I tried the following demo code: >>> >>> (defun test () >>> (let ((a 0)) >>> (dotimes (_ 5) >>> (setq a (1+ a)) >>> (sleep-for 2) >>> (message "%s" a >>> >>> (progn ;This should return to command loop quickly >>> (make-thread #'test) >>> (message "Executed...")); `eval-last-sexp' here >>> >>> I can move around the buffer while the progn is running. >>> However, it is not the case with `org-agenda-redo' for a reason I do not >>> fully understand. >> >> Org Agenda code does not wait for keyboard input; it's busy building the >> agenda. This is the case with most code in Emacs: it's not written to >> be asynchronous, and it doesn't return to the main thread until done. >> So you can sprinkle yields here and there and maybe be able to mov
Re: Asynchronous org-babel-tangle (was Re: Asynchronous org-agenda-redo)
Thanks for the feedback. > - For me, the tangle works if I only load the org library in the > sub-process, so I disabled the loading of my config. I guess this depends > heavily and what other configuration one has loaded, but I think for > tangling, not much else is needed :) Note that your version tangling may not work as expected if your init file changes any default headers args affecting the tangling. For example, I set (:comments . "link") in my init file. Not loading init file would disallow detangling in my case. > - In you code, the process-list variable was not actually being modified > since plist-put returns the new value but does not modify the > variable. (facepalm) > I > tried a few variations wrapping the plist-put in (setq ...), and adding > corresponding code to clear the element after the tangle was finished, but > could not get it to work. Well. Things did not work because plist-put compares keys by #'eq, which returns nil on equal strings. > - I wanted my code to report the time the tangle took. This works well by > passing the time as the result of the initial lambda. Interestingly, it > works if I return the time already formatted as a string (as in my code) > but not if I return the result of (float-time ..) directly. Thanks for this neat idea. Will also grab it to my config. float-time did not work because of bug in async.el. It uses backward-sexp to find the returned value of the lambda (in the process buffer). But backwards-sexp fails on float (it moves point just after the point). Best, Ihor Diego Zamboni writes: > Hi Ihor, > > On Thu, Dec 12, 2019 at 4:00 PM Ihor Radchenko wrote: > >> See the relevant code from my config below. Let me know if you have any >> questions or suggestions. >> > > Thank you, this was extremely helpful. I am now using a modified version of > your code (see below) with the following comments/questions: > > - For me, the tangle works if I only load the org library in the > sub-process, so I disabled the loading of my config. I guess this depends > heavily and what other configuration one has loaded, but I think for > tangling, not much else is needed :) > > - In you code, the process-list variable was not actually being modified > since plist-put returns the new value but does not modify the variable. I > tried a few variations wrapping the plist-put in (setq ...), and adding > corresponding code to clear the element after the tangle was finished, but > could not get it to work. As this is not really critical for me, I just > removed the whole process-checking code, significantly simplifying the rest. > > - I wanted my code to report the time the tangle took. This works well by > passing the time as the result of the initial lambda. Interestingly, it > works if I return the time already formatted as a string (as in my code) > but not if I return the result of (float-time ..) directly. > > Here's my code: > > #+begin_src emacs-lisp > (defun zz/org-babel-tangle-async (file) > "Invoke `org-babel-tangle-file' asynchronously." > (message "Tangling %s..." (buffer-file-name)) > (async-start >(let ((args (list file))) > `(lambda () > (require 'org) > ;;(load "~/.emacs.d/init.el") > (let ((start-time (current-time))) > (apply #'org-babel-tangle-file ',args) > (format "%.2f" (float-time (time-since start-time)) >(let ((message-string (format "Tangling %S completed after " file))) > `(lambda (tangle-time) > (message (concat ,message-string > (format "%s seconds" tangle-time))) > > (defun zz/org-babel-tangle-current-buffer-async () > "Tangle current buffer asynchronously." > (zz/org-babel-tangle-async (buffer-file-name))) > #+end_src > > Thanks again for your help, and for the inspiration to finally get this > done, it had been bugging me for a while :) > > --Diego > > > >> Also, my config is written in the way that everything related to user >> interaction can be disabled if I load emacs for tangling >> (with org-tangle-flag). This is to speed up the async process. >> >> #+begin_src emacs-lisp >> (defvar yant/org-babel-tangle-async-process-list nil >> "Plist of (file . process) for all the currently running async tangle >> processes.") >> >> >> (defun yant/org-babel-tangle-async (file &optional target-file lang) >> "Invoke `org-babel-tangle-file' asynchronously." >> (require 'async) >> (
Re: Asynchronous org-babel-tangle (was Re: Asynchronous org-agenda-redo)
Thanks for the feedback. > - For me, the tangle works if I only load the org library in the > sub-process, so I disabled the loading of my config. I guess this depends > heavily and what other configuration one has loaded, but I think for > tangling, not much else is needed :) Note that your version tangling may not work as expected if your init file changes any default headers args affecting the tangling. For example, I set (:comments . "link") in my init file. Not loading init file would disallow detangling in my case. > - In you code, the process-list variable was not actually being modified > since plist-put returns the new value but does not modify the > variable. (facepalm) > I > tried a few variations wrapping the plist-put in (setq ...), and adding > corresponding code to clear the element after the tangle was finished, but > could not get it to work. Well. Things did not work because plist-put compares keys by #'eq, which returns nil on equal strings. > - I wanted my code to report the time the tangle took. This works well by > passing the time as the result of the initial lambda. Interestingly, it > works if I return the time already formatted as a string (as in my code) > but not if I return the result of (float-time ..) directly. Thanks for this neat idea. Will also grab it to my config. float-time did not work because of bug in async.el. It uses backward-sexp to find the returned value of the lambda (in the process buffer). But backwards-sexp fails on float (it moves point just after the point). P.S. I just noticed that async tangle fails when I try to tangle into "/sudo::filename". Not even sure how to fix it. Best, Ihor Diego Zamboni writes: > Hi Ihor, > > On Thu, Dec 12, 2019 at 4:00 PM Ihor Radchenko wrote: > >> See the relevant code from my config below. Let me know if you have any >> questions or suggestions. >> > > Thank you, this was extremely helpful. I am now using a modified version of > your code (see below) with the following comments/questions: > > - For me, the tangle works if I only load the org library in the > sub-process, so I disabled the loading of my config. I guess this depends > heavily and what other configuration one has loaded, but I think for > tangling, not much else is needed :) > > - In you code, the process-list variable was not actually being modified > since plist-put returns the new value but does not modify the variable. I > tried a few variations wrapping the plist-put in (setq ...), and adding > corresponding code to clear the element after the tangle was finished, but > could not get it to work. As this is not really critical for me, I just > removed the whole process-checking code, significantly simplifying the rest. > > - I wanted my code to report the time the tangle took. This works well by > passing the time as the result of the initial lambda. Interestingly, it > works if I return the time already formatted as a string (as in my code) > but not if I return the result of (float-time ..) directly. > > Here's my code: > > #+begin_src emacs-lisp > (defun zz/org-babel-tangle-async (file) > "Invoke `org-babel-tangle-file' asynchronously." > (message "Tangling %s..." (buffer-file-name)) > (async-start >(let ((args (list file))) > `(lambda () > (require 'org) > ;;(load "~/.emacs.d/init.el") > (let ((start-time (current-time))) > (apply #'org-babel-tangle-file ',args) > (format "%.2f" (float-time (time-since start-time)) >(let ((message-string (format "Tangling %S completed after " file))) > `(lambda (tangle-time) > (message (concat ,message-string > (format "%s seconds" tangle-time))) > > (defun zz/org-babel-tangle-current-buffer-async () > "Tangle current buffer asynchronously." > (zz/org-babel-tangle-async (buffer-file-name))) > #+end_src > > Thanks again for your help, and for the inspiration to finally get this > done, it had been bugging me for a while :) > > --Diego > > > >> Also, my config is written in the way that everything related to user >> interaction can be disabled if I load emacs for tangling >> (with org-tangle-flag). This is to speed up the async process. >> >> #+begin_src emacs-lisp >> (defvar yant/org-babel-tangle-async-process-list nil >> "Plist of (file . process) for all the currently running async tangle >> processes.") >> >> >> (defun yant/org-babel-tangle-async (file &optional target-file lan
Re: Asynchronous org-agenda-redo
> So, of course, you can call custom > functions in queries, even your own skip functions (with `not', of > course), but in most cases, they can be covered with built-in > predicates. Unfortunately, it does not seem to be the case for me. My main agenda view needs to take into account multiple properties, which cannot be handled within framework of built-in org-ql predicates (AFAIK): - =:SHOWFROMTIME:= (always inheriting) :: The purpose of this is to be able to assign specific projects for different days of week or, say, show the home items only in the evening of weekdays and not annoy me at work when I cannot do it any way. Hence, I can focus on the items I really need to do now in this agenda. Additionally, the time of the day after midnight is treated specially here. If =org-extend-today-until= is not 0 and the current time is before its value, the current time is still considered to be yesterday. - =:SHOWFROMDATE:= :: The purpose of this is to be able to postpone the scheduled tasks for future if I cannot do it. The property is formatted as an org date. This property is especially useful if there is something more pressing, so that there is a temptation to reschedule less pressing event to another day. If the more pressing task is done earlier than expected, the postponed tasks can be still find in normal agenda view (not in the [[id:ff70b03f-3876-4b2b-9aab-c3209bd31cb8][focused]] one). - =:SHOWDATES:= (always inheriting) :: It contains dairy =sexps= to set when the project should be shown. For example, I may want to work on Saturday once or twice, but the working items should not be shown on weekend normally. Hence, I can define it. Or some things can only be done on specific dates (say, going to some shop, which is open few days a week only) > org-entry-get is only called for the (property) predicate. It's the > correct way to get Org properties, because it handles special > properties, inheritance, etc. However, when possible, queries are > optimized to a whole-buffer regexp search that finds possible matches. > So, for example, a query like '(property "owner" "yantar") would be > optimized to a whole-buffer regexp search that would be very fast. See > function org-ql--query-preamble. Thanks for the info! I did not know about this optimisation in org-ql. org-entry-get consumes most of cpu time while building my agenda views. Though I don't think that there will be much difference for me since most of my property conditions in agenda involve inherited properties. Regards, Ihor Adam Porter writes: > Ihor Radchenko writes: > >>> org-ql doesn't use skip functions, just queries. >> >> Skip functions are essentially used-defined queries as soon as the >> queries are tested against every headline. > > Skip functions aren't necessary with org-ql, because the query itself > can have arbitrary Lisp code. So, of course, you can call custom > functions in queries, even your own skip functions (with `not', of > course), but in most cases, they can be covered with built-in > predicates. > >> I can rewrite my skip functions into queries, but I don't expect much >> improvement since org-ql seems to use org-entry-get, which is the main >> performance bottleneck for my agenda generation. > > org-entry-get is only called for the (property) predicate. It's the > correct way to get Org properties, because it handles special > properties, inheritance, etc. However, when possible, queries are > optimized to a whole-buffer regexp search that finds possible matches. > So, for example, a query like '(property "owner" "yantar") would be > optimized to a whole-buffer regexp search that would be very fast. See > function org-ql--query-preamble. > > >
Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Recipe: 1. Create an org file with the following contents: * 1 ** 2 2. emacs -Q 3. Open the file 4. Put the point at the end of the second headline 5. M-: (message "%s" (org-element-at-point)) Expected behaviour: According to org-element-at-point docstring, "Properties depend on element or object type, but always include :begin, :end, :parent and :post-blank properties.". Hence, it is expected to have :parent property set to the first headline. Observed behaviour: (headline (:raw-value 2 :begin 6 :end 13 :pre-blank 0 :contents-begin nil :contents-end nil :level 2 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 2 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 6 :title 2)) No :parent property is returned. Best, Ihor Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2019-12-16 Package: Org mode version 9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)
Re: Emacs bug 37890; killing capture buffer
Dear Michael, > BTW, what is the canonical place to report org-mode bugs? Emacs bug > reports are not (takes a long time until someone even notices) -- I > thought this list would be good...or is there a better place? @Adam > it's ok if you answer, though I'm a bit disappointed that no one else > seems to care so far... You can try M-x org-submit-bug-report ;) Then it becomes clear that you are in the right place already. Best, Ihor Michael Heerdegen writes: > Adam Porter writes: > >> I guess you're asking me, since I'm the only other person in this >> thread--but I'm not an Org maintainer, so my opinion isn't very >> important. IMO, the hooks are worth considering, however they should be >> done very, very carefully, because bad things can happen when functions >> called in kill hooks don't work as expected (e.g. they can make it very >> difficult to kill a buffer or the Emacs process, especially for an >> average user). > > Yes, all true. I didn't even check if the code I posted breaks any org > commands that kill the buffer. So far it's only meant for demonstration > (and my personal usage). > > Will my request be noticed here, or do you think I should report it to > some other place? > >> > BTW, what about my question whether my original bug report can be >> > closed? >> >> I haven't seen your bug report. Was there discussion about it >> previously? > > No, no discussion at all. As I said, it is Emacs bug #37890, this was > my issue: > > | I want to capture an APPT with `org-capture'. I the pop-up buffer to > | edit the item I move the date to the second line and add text after the > | date (personal preference). That loses the final newline in > | CAPTURE-todo.org. As a result, the headline of the item following the > | item to be inserted gets appended to the last line of the text: > | > | ** APPT Abc > |<2019-10-23 Mi> > | text... ** APPT 8:30 Important Appointment > | > | breaking the whole item. The user should somehow be prevented from that > | happening. > > It seems it has been resolved, just without noticing my bug report. If > you can confirm that the cited issue has been cared about, I'll close it > as done. > > BTW, what is the canonical place to report org-mode bugs? Emacs bug > reports are not (takes a long time until someone even notices) -- I > thought this list would be good...or is there a better place? @Adam > it's ok if you answer, though I'm a bit disappointed that no one else > seems to care so far... > > > Thanks, > > Michael. >
Bug: org-tempo expansion comments out the following src block when org-src-tabs-natively is 't [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Recipe: 1. emacs -Q 2. Execute the following lisp code: (setq org-src-tab-acts-natively t) (require 'org-tempo) (push (cons "el" "src emacs-lisp") org-structure-template-alist) 3. Create the following org file: #+begin_src emacs-lisp #+end_src 4. Put the point before the code block 5.1. Type
Re: Bug: org-tempo expansion comments out the following src block when org-src-tabs-natively is 't [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
> I did not need to add this line to confirm the behavior: > >> (push (cons "el" "src emacs-lisp") org-structure-template-alist) Note the 5.2 part of the recipe. It is probably caused by the same reason, but the consequence is that the following code block is being commented, sometimes out of the screen. I accidentally commented several parts of my emacs configuration because of this. > If you really need ` > You might use `C-c C-,' as long as you have no other templates > defined. I prefer to use `' instead of `C-c C-, e l C-o' simply because it takes one less key press and less modifier keys. And I do have other templates. > Right. The issue seems to be that `org-tempo-add-block' puts `>' > elements in its recipe for converting `org-structure-template-alist' > to `tempo-org-template-*' values. > > Those are innocuous when `org-src-tab-acts-natively' is nil. The most straightforward solutions are deleting the `'>' elements from the template or temporary setting the `org-src-tabs-acts-natively' to nil. Best, Ihor "Berry, Charles" writes: >> On Dec 18, 2019, at 5:07 AM, Ihor Radchenko wrote: >> >> Recipe: >> >> 1. emacs -Q >> 2. Execute the following lisp code: >> >> (setq org-src-tab-acts-natively t) >> (require 'org-tempo) > > I did not need to add this line to confirm the behavior: > >> (push (cons "el" "src emacs-lisp") org-structure-template-alist) >> >> 3. Create the following org file: >> >> >> >> #+begin_src emacs-lisp >> #+end_src >> >> 4. Put the point before the code block >> >> 5.1. Type > >> Observed behaviour: >> >> #+begin_src >> >> >> #+begin_src emacs-lisp >> #+end_src >> > > > Right. The issue seems to be that `org-tempo-add-block' puts `>' elements in > its recipe for converting `org-structure-template-alist' to > `tempo-org-template-*' values. > > Those are innocuous when `org-src-tab-acts-natively' is nil. > > But when `org-src-tab-acts-natively' is `t', an attempt is made to indent > within the src block, which I guess is where the trouble lies as an error > occurs which prevents the remainder of the template from being inserted. > > If you really need ` > You might use `C-c C-,' as long as you have no other templates defined. > > HTH, > > Chuck
[FWD from emacs-orgmode] Re: Bug: About org-submit-bug-report [9.3 (release_9.3 @ /usr/local/share/emacs/27.0.50/lisp/org/)]
[Forwarding this to emacs-devel] The naming convention for mode-specific bug reporting seems to be confusing. The bug reporting functions are often not easy to discover without knowing the explicit command name (especially with emacs default completion interface). For example see recent message in emacs-orgmode (below). > I want to suggest to make `report-org-bug' and alias for the command > `org-submit-bug-report'. That's the name I expected (considering > "report-emacs-bug"), also some other Emacs packages name their bug > reporting command according to this scheme. The additional name would > make this important command more discoverable. Another convention for bug report command is *mode*-report-bug/*mode*-bug-report: calc-report-bug reftex-report-bug eshell-report-bug gnuplot-bug-report c-submit-bug-report Though several modes are also using the naming similar to org-submit-bug-report: c-submit-bug-report diredp-send-bug-report org-edna-submit-bug-report I am thinking if it would make sense to develop more standardised command name conventions for bug reporting and add them to (elisp)Emacs Lisp:Preparing Lisp code for distribution Then, the built-in emacs packages might be changed to follow those conventions and improve discoverability of bug reporting capabilities. Also, an information that different major modes may have they own bug reporting tools might be mentioned in the default template shown in report-emacs-bug. What do you think? Regards, Ihor Michael Heerdegen writes: > Hello, > > I want to suggest to make `report-org-bug' and alias for the command > `org-submit-bug-report'. That's the name I expected (considering > "report-emacs-bug"), also some other Emacs packages name their bug > reporting command according to this scheme. The additional name would > make this important command more discoverable. > > Second point: When you think it is a trivial task for a common user > please consider to add some text to the initial buffer contents of the > message buffer created by this command explaining where one can search > for existing reports (to avoid duplicates and reports about things that > are just pitfalls etc). My buffer included a link to a page explaining > how to create a good report but there this information is also missing, > although I think it would be a good place. > > TIA, > > Michael. > > Emacs : GNU Emacs 27.0.50 (build 41, x86_64-pc-linux-gnu, GTK+ Version > 3.24.13) > of 2019-12-20 > Package: Org mode version 9.3 (release_9.3 @ > /usr/local/share/emacs/27.0.50/lisp/org/) >
Bug: org-babel-execute:emacs-lisp does not allow changing window configuration from within code block [9.3 (release_9.3 @ /home/yantar92/.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. Recipe: 1. emacs -Q 2. Create the following org file #+begin_src emacs-lisp (split-window-below) #+end_src 3. Execute the source block Observed behaviour: The block returns, but the window is not splitted Expected behaviour: The window is splitted The reason of the observed behaviour is that org-babel-execute:emacs-lisp wraps the code block evaluation into save-window-excursion. Thus window manipulation is impossible from within babel blocks. The real case scenario when one would need to change window layout from within babel block is a window setup for a project development. If certain project requires working with specific window configuration, this can be defined by adding all the setup into a babel block somewhere in the project. Then, the layout could be applied just by hitting C-c C-c on the code block once one need to work on the project. However, it is not possible with the current org-babel-execute:emacs-lisp implementation. Best regards, Ihor Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2019-12-17 Package: Org mode version 9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/) -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Bug: org-agenda-open-link disallow permanenly changing point position while opening some links (e.g. elisp:) [9.3 (release_9.3 @ /home/yantar92/.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. Recipe: 1. emacs -Q 2. Open the following org file * TODO 1 elisp:end-of-buffer ** TODO 2 blah 3. M-x org-agenda < t 4. Move point to "TODO 1" in agenda 5. C-c C-o yes Expected behaviour: The point in the org file moves to the end of the file Observed behaviour: The point does not move The cause of the observed behaviour is the following code in org-agenda-open-link: (with-current-buffer buffer (setq trg (and (string-match org-link-bracket-re l) (match-string 1 l))) (if (or (not trg) (string-match org-link-any-re trg)) (org-with-wide-buffer (goto-char marker) (when (search-forward l nil lkend) (goto-char (match-beginning 0)) (org-open-at-point))) ;; This is an internal link, widen the buffer (switch-to-buffer-other-window buffer) (widen) (goto-char marker) (when (search-forward l nil lkend) (goto-char (match-beginning 0)) (org-open-at-point The code opens the link in two ways depending whether the link is "internal link" or not. If it is not "internal", following the link is enclosed into save-excursion (from org-with-wide-buffer). Thus, the moving point does not have any effect when following some links In my real life scenario, I have a custom link, which executes some elisp to add a new row in a table from the current item and move the point to that table. However, there is no way to keep the point position with the current org-agenda-open-link implementation, unless the condition for "internal link" is broadened. Best regards, Ihor Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2019-12-17 Package: Org mode version 9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/) This email may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are notified that any use, dissemination, distribution, or copying of this email, or any attachment, is strictly prohibited. Please delete the email immediately and inform the sender. Thank You
Re: Asynchronous org-agenda-redo
> That's a very elegant way to add the threading! Thanks for kind words. > The performance penalty > is noticeable, but the tradeoff could be worth it in some cases, like a > background agenda refresh on a timer, or after a "remote" edit. I can > imagine an org-agenda-refresh-async command that would add that advice > and remove them in an unwind-protect. That may be a good way to go. Probably, even refreshing agenda in a separate copy of agenda buffer, so that the current version remains usable. > The first thing that comes to mind is to set buffer-read-only on each > buffer before it is scanned, and unset it when done with a buffer. That > might not be doable with advice. This is not enough. If you accidentally move the point in the buffer being processed by agenda, the results may be unpredictable (org-agenda-get-* functions move across the buffer with re-search-forward). Any ideas how to deal with this? Best, Ihor Adam Porter writes: > Ihor Radchenko writes: > >>>> Asynchronous code is not faster; it's generally slower because of >>>> yielding and synchronization. >> >>> Anyway, I will try to throw yields into agenda code just to check how >>> bad the performance can degrade. >> >> With the following code, org-agenda-redo runs for 21 second on my >> system, while without threads it is 16 seconds. However, emacs remains >> responsive during rebuilding agenda! >> >> (define-advice org-agenda-redo (:around (oldfun &optional all) make-async) >> (make-thread (lambda () (funcall oldfun all)) "org-agenda-redo")) >> (define-advice org-agenda-skip-eval (:around (oldfun form) make-async) >> (thread-join (make-thread (lambda () (funcall oldfun form)) >> "org-agenda-skip-eval"))) > > That's a very elegant way to add the threading! The performance penalty > is noticeable, but the tradeoff could be worth it in some cases, like a > background agenda refresh on a timer, or after a "remote" edit. I can > imagine an org-agenda-refresh-async command that would add that advice > and remove them in an unwind-protect. > >> The problem, of course, is that touching agenda buffer and org buffers >> may be risky while org-agenda-redo is running. >> Wondering if it is possible to block user commands during that time. > > The first thing that comes to mind is to set buffer-read-only on each > buffer before it is scanned, and unset it when done with a buffer. That > might not be doable with advice. > >
Re: refile captured to all opened Org buffer files as targets
[offtopic] > I recently created an org-capture template for elfeed, it is finished. Could you share your capture template? stardiviner writes: > I recently created an org-capture template for elfeed, it is finished. Now I > have an idea is to refile it to all currently opened Org buffer files. So I > created an function for ~org-refile-targets~ variable. > > #+begin_src emacs-lisp > (defun org-refile-targets-all-files () > "Use all currently opened Org buffer files as org-refile targets." > (mapcar 'buffer-file-name > (seq-filter (lambda (buffer) (if-let (file (buffer-file-name > buffer)) (f-ext? file "org"))) ; filter Org buffers > (buffer-list > #+end_src > > Then set ~org-refile-targets~ to use upper custom function > > #+begin_src emacs-lisp :eval no > (setq org-refile-targets '((nil :maxlevel . 3) ; current buffer headlies >(org-agenda-files :maxlevel . 2) ; agenda files > headlines >(org-refile-targets-all-files :maxlevel . 3) ; all > opened Org buffer files headlines >)) > #+end_src > > Can I add this as a patch to Org Mode repository? > > -- > [ stardiviner ] >I try to make every word tell the meaning what I want to express. > >Blog: https://stardiviner.github.io/ > IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 > > -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: refile captured to all opened Org buffer files as targets
Thanks!
org-web-tools--html-to-org-with-pandoc is an interesting idea. I was
using elfeed-insert-html for this purpose.
Also, note that your capture may be messed up when the rss content
contains org-mode text. A real-case scenario from Stack Exchange rss:
> I'd like to find a way to jump to a location in an org-mode file while
> automatically unfolding only the heading at the location I'm jumping to and
> all its parent headings (but not any sibling headings).
>
> For example, if I have this org-mode file:
>
> * A
> ** AA
If you insert the rss entry contents as is, two unexpected headings will
be created.
I use the following to escape possible org-mode text:
(setq content-text (with-temp-buffer (when content
(if (eq
content-type 'html)
(elfeed-insert-html content)
(insert
content)))
(let
((org-babel-min-lines-for-block-output 0)) ;; handle org-mode syntax in body
(org-escape-code-in-region (point-min) (point-max)))
(buffer-string)))
Best,
Ihor
stardiviner writes:
> Ihor Radchenko writes:
>
>> [offtopic]
>>
>>> I recently created an org-capture template for elfeed, it is finished.
>>
>> Could you share your capture template?
>
> Sure, here it is:
>
> #+begin_src emacs-lisp
> ;; support Org Mode Capture template
> (defun my/org-capture-elfeed-title ()
> (with-current-buffer "*elfeed-entry*"
> (elfeed-entry-title elfeed-show-entry)))
> (defun my/org-capture-elfeed-date ()
> (with-current-buffer "*elfeed-entry*"
> (format-time-string
> "[%Y-%m-%d %a %H:%M]"
> (seconds-to-time (elfeed-entry-date elfeed-show-entry)
> (defun my/org-capture-elfeed-source ()
> (with-current-buffer "*elfeed-entry*"
> (let ((feed (elfeed-entry-feed elfeed-show-entry)))
> (elfeed-feed-title feed
> (defun my/org-capture-elfeed-content ()
> (with-current-buffer "*elfeed-entry*"
> (let* ((content (elfeed-deref (elfeed-entry-content elfeed-show-entry)))
>(type (elfeed-entry-content-type elfeed-show-entry))
>(feed (elfeed-entry-feed elfeed-show-entry))
>(base-url (and feed (elfeed-compute-base (elfeed-feed-url feed)
> (if content
> (if (eq type 'html)
> (org-web-tools--html-to-org-with-pandoc content)
> (insert content))
>
> (add-to-list 'org-capture-templates
> '("R" "Capture elfeed [R]SS feed content to Org buffer"
>entry (file "")
>"* %(my/org-capture-elfeed-title)
> :PROPERTIES:
> :SOURCE: %(my/org-capture-elfeed-source)
> :DATE(original): %(my/org-capture-elfeed-date)
> :DATE: %u
> :END:
>
> %(my/org-capture-elfeed-content)"
>:empty-lines 1
>:jump-to-captured t))
> #+end_src
>
> If possible, I might submit this PR to elfeed.el repository.
>
> --
> [ stardiviner ]
>I try to make every word tell the meaning what I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>
Re: Bug (with fix): org-tempo-add-block incorrectly inserts comma before next `#+begin_src' during expansion [9.3.2 (9.3.2-8-g47b104-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20200127/)]
\n(fn URL)"]
> )
>("http" :follow
> #[257 "\301\300\302Q!\207" ["http" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
>("ftp" :follow
> #[257 "\301\300\302Q!\207" ["ftp" browse-url ":"] 5
> "\n\n(fn URL)"]
> )
>("help" :follow org-link--open-help)
>("file" :complete org-link-complete-file)
>("elisp" :follow org-link--open-elisp)
>("doi" :follow org-link--open-doi))
> org-agenda-file-regexp "\\`[^.].*\\.org\\(\\.gpg\\)?\\'"
> org-link-elisp-confirm-function 'yes-or-no-p
> org-todo-keyword-faces '(("TODO" :foreground "red" :weight bold)
> ("NEXT" :foreground "blue" :weight bold)
> ("NOW" :foreground "orange" :weight bold)
> ("SOMETIME" :foreground "deep sky blue" :weight
> bold)
> ("DONE" :foreground "forest green" :weight bold)
> ("WAITING" :foreground "orange" :weight bold)
> ("INACTIVE" :foreground "magenta" :weight bold)
> ("CANCELLED" :foreground "forest green" :weight
> bold)
> ("MEETING" :foreground "forest green" :weight bold))
> org-capture-after-finalize-hook '(#[0
> "\300 \210\301\302\303\304
> !\"A\305\232\205 \306 \207"
> [org-save-all-org-buffers assoc name
> frame-parameters selected-frame
> "remember"
> delete-frame]
> 4]
>)
> org-tab-before-tab-emulation-hook '(org-tempo-complete-tag)
> org-super-agenda-groups '((:name "Today:" :time-grid t)
>(:name "NOW Tasks:" :todo "NOW")
>(:name "Overdue Tasks:" :scheduled past)
>(:name "Today's Tasks:" :scheduled today)
>(:name "Future Tasks:" :scheduled future))
> org-startup-truncated nil
> org-show-context-detail '((agenda . local) (bookmark-jump . lineage)
>(isearch . lineage) (default . ancestors)
> (org-goto . local)
>(occur-tree . local) (link-search . local)
>(tags-tree . local))
> org-src-window-setup 'current-window
> org-confirm-babel-evaluate 'my-org-confirm-babel-evaluate
> org-deadline-warning-days 90
> org-agenda-custom-commands '(("c" "Simple agenda view" ((agenda "") (alltodo
> "")))
> ("X" "Agenda" ((agenda "") (alltodo))
>((org-agenda-ndays 10)
> (org-agenda-start-on-weekday nil)
> (org-agenda-start-day "-1d")
> (org-agenda-start-with-log-mode t))
>)
> )
> org-directory “/path/to/org/"
> org-default-notes-file “/path/to/org/my_notes.org"
> )
>
--
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
> Probably the docstring needs to be adapted - Nicolas knows this area > better than me. Do you mean that :parent property may not always be present? If so, it is quite disappointing. It would be helpful to be able to find parent of any element at point (especially, in conjunction with org-element-cache). At least, optionally. I was counting on this feature to try speeding up my agenda generation (using org-element-cache). Best, Ihor Bastien writes: > Hi Ihor, > > Ihor Radchenko writes: > >> According to org-element-at-point docstring, "Properties depend on >> element or object type, but always include :begin, :end, :parent and >> :post-blank properties.". > > Probably the docstring needs to be adapted - Nicolas knows this area > better than me. > > Best, > > -- > Bastien -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
> `org-element-at-point' returns only a partial parse tree. It never goes > higher than the current top-level element, i.e., from an element, you > cannot go up to the headline just following :parent. Thanks for the clarification. I was not sure if it is intended. I was mislead about this 2 times because of docstring, though it is clear from the source code. > Luckily, headlines are exactly where you do _not_ need Element library. > `org-back-to-heading' and `org-up-heading-safe' will always be faster, > and as accurate. I.e., the code operating on headlines is usually > distinct from the code handling other elements. Well. `org-back-to-heading` + `org-up-heading-safe` take more than 15% of my agenda generation time (I have really huge number of headings + multiple custom skip functions). I was hoping to use cache for speed up. > You can parse the full document and get all the :parent properties > filled. That's not the job for `org-element-at-point'. I once tried to do exactly this, but I did not manage to figure out how to obtain element at point from full parse tree (from inside an agenda skip function). Is it possible? > Note that `org-element-cache' was disabled a while ago because it could > introduce freezes. I think this is related to how this part handles > `before-change-functions' and `after-change-functions'. Anyway, YMMV. I see... I don't know how useful the cache is except my idea about using cache to speed up agenda. But I was stuck with the :parent property issue and did not play much further since that time. Best, Ihor Nicolas Goaziou writes: > Hello, > > Ihor Radchenko writes: > >>> Probably the docstring needs to be adapted - Nicolas knows this area >>> better than me. >> >> Do you mean that :parent property may not always be present? > > `org-element-at-point' returns only a partial parse tree. It never goes > higher than the current top-level element, i.e., from an element, you > cannot go up to the headline just following :parent. > > Luckily, headlines are exactly where you do _not_ need Element library. > `org-back-to-heading' and `org-up-heading-safe' will always be faster, > and as accurate. I.e., the code operating on headlines is usually > distinct from the code handling other elements. > >> If so, it is quite disappointing. It would be helpful to be able to find >> parent of any element at point (especially, in conjunction with >> org-element-cache). At least, optionally. > > You can parse the full document and get all the :parent properties > filled. That's not the job for `org-element-at-point'. > >> I was counting on this feature to try speeding up my agenda generation >> (using org-element-cache). > > Note that `org-element-cache' was disabled a while ago because it could > introduce freezes. I think this is related to how this part handles > `before-change-functions' and `after-change-functions'. Anyway, YMMV. > > Regards, > > -- > Nicolas Goaziou -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: [O] Is it possible to pass variable to variables of src block?
Hi David, One thing you can do is to make a code block, which will generate another code block, running your script with different arguments. Let me illustrate with a simple example: #+name: printecho #+BEGIN_SRC sh :var a=1 echo $a; #+END_SRC #+name: genscript #+BEGIN_SRC sh :var cmd="printecho" :results raw output :wrap "src sh :noweb yes :results output" echo "cat << EOF" for x in "1" "2" "3" "4" "5" "6" "something"; do echo "<<$cmd(a=\"$x\")>>"; done #+END_SRC #+RESULTS: genscript #+BEGIN_src sh :noweb yes :results output cat << EOF <> <> <> <> <> <> <> #+END_src #+RESULTS: : 1 : 2 : 3 : 4 : 5 : 6 : something Hope it helps. P.S. Does anyone know why the following does not evaluate noweb recursively? #+BEGIN_SRC sh :noweb yes :results output <> #+END_SRC Regards, Ihor Xi Shen writes: > Hi Michael, > > Yes, I think this is a way to my previous question. But what I really want > to achieve is to loop through a list of server names and execute a script > on them. > > Say I have 20 different database server. How can I do a loop with each > server? > > > Regards, > David > > > On Wed, Dec 6, 2017 at 5:34 PM Michael Welle wrote: > >> Hello, >> >> Xi Shen writes: >> >> > Hi, >> > >> > http://orgmode.org/manual/var.html >> > >> > This wiki explains how to use variable inside a src block. But I wonder >> if >> > it is possible to specify variable to the variables in the src >> definition. >> > >> > E.g. for the sql src block, I want to execute a script on different >> server. >> > I want to define a variable for the ":dbhost" variable. >> did you think about something like this? >> >> >> (setq hmw/dbhost "db1") >> >> #+BEGIN_SRC sql :dbhost (symbol-value 'hmw/dbhost) :dbuser weather >> :database environment :engine postgresql >> select time, temperature from weather limit 20; >> #+END_SRC >> >> Regards >> hmw >> >> -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature
[O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]
This email may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are notified that any use, dissemination, distribution, or copying of this email, or any attachment, is strictly prohibited. Please delete the email immediately and inform the sender. Thank You The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you. --- Begin Message --- 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 http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. org-clock-in in org-clock.el calculates org-clock-total-time via calling (org-clock-sum-current-item (org-clock-get-sum-start)). However, org-clock-get-sum-start returns the time in UTC, which is not considered by org-clock-sum-current-time. My time zone if UTC+8 and org-clock-mode-line-total is 'today. Hence org-clock-total-time is gives total time starting from 8am today (which is midnight in UTC) instead of midnight in UTC+8. Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, X toolkit) of 2017-12-06 Package: Org mode version 9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/) -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature --- End Message ---
[O] Bug: List does not fold correctly with inline tasks in the middle [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]
1. Create the following same org file: * Test - blah - a - b - c *** List folding stops here :PROPERTIES: :ID: 27eb85b6-114f-437f-9424-b28d400f6aa9 :END: *** END - everything here and below folds on tab at =**...END= - f 2. Try to fold at =-blah=. Everything started from inline task is not folded, while should. 3. Try to fold at =*... END=. Everything below *is* folded, while should not. Regards, Ihor Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, X toolkit) of 2017-12-06 Package: Org mode version 9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/) -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature
Re: [O] Bug: List does not fold correctly with inline tasks in the middle [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]
I am dumb... Forgot to load 'org-inlinetask 'Ihor Radchenko' writes: > 1. Create the following same org file: > * Test > - blah > - a > - b > - c > *** List folding stops here > :PROPERTIES: > :ID: 27eb85b6-114f-437f-9424-b28d400f6aa9 > :END: > *** END > - everything here and below folds on tab at =**...END= > - f > > 2. Try to fold at =-blah=. Everything started from inline task is not > folded, while should. > > 3. Try to fold at =*... END=. Everything below *is* folded, while should > not. > > Regards, > Ihor > > > Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, X toolkit) > of 2017-12-06 > Package: Org mode version 9.1.4 (9.1.4-13-g84cb63-elpa @ > /home/yantar92/.emacs.d/elpa/org-20171218/) > -- > Ihor Radchenko, > PhD Student > Singapore University of Technology and Design, > 8 Somapah Road Singapore 487372 > Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg > Tel: +6584017977 -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature
Re: [O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]
(while (not yant/check-from-field-before-sending-bug-report) (insert "I will always check my From field before sending bug report.\n")) P.S. Does anyone know how to set alternative default sending account for bug reporting specifically? Regards, Ihor Samuel Wales writes: > in friendly jest: > > On 12/21/17, Ihor Radchenko wrote: >> intended recipient, you are hereby notified that any use, dissemination, >> distribution, or copying of this message, or any attachment, is strictly >> prohibited. If you have received this email in error, please inform the > > all those people who read the archives have to send you email and > delete the archives! > > that poor bot! it is being told to send you email for each message! > it is disseminating! or maybe distributing! > > i'm gonna prohibit you from combing your hair for the next week! > because you received this email! i'll bet you think this email is > about you! don't you! don't you! > > -- > The Kafka Pandemic: <http://thekafkapandemic.blogspot.com> > > The disease DOES progress. MANY people have died from it. And ANYBODY > can get it at any time. > > "You’ve really gotta quit this and get moving, because this is murder > by neglect." --- > <http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>. > -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature
Re: [O] Searching all attachments in org-files
Dear Narendra,
Here is what I am using:
(defun org-att-complete-link (&optional arg)
"Completion dispatcher for att: links (rewritten from org-attach-open)"
(let* ((attach-dir (org-attach-dir t))
(files (org-attach-file-list attach-dir))
(file (if (= (length files) 1)
(car files)
(completing-read "att: "
(mapcar #'list files) nil t)))
(path (expand-file-name file attach-dir)))
(concat "att:" file)))
(add-to-list 'org-link-abbrev-alist '("att" . org-attach-expand-link))
(org-link-set-parameters
"att"
:complete 'org-att-complete-link)
Regards,
Ihor
Narendra Joshi writes:
> Hi,
>
> Is there a way to quick get a link to an existing attachment? A lot of
> times, I find myself referring to the same file. I like to keep files as
> attachments so that they are committed with my org-files. Any help here,
> either in fixing my workflow or helping me figure out how to get a link
> to an existing file that is attached to an org-heading, would be greatly
> appreciated.
>
> Thanks,
> --
> Narendra Joshi
>
--
Ihor Radchenko,
PhD Student
Singapore University of Technology and Design,
8 Somapah Road Singapore 487372
Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg
Tel: +6584017977
signature.asc
Description: PGP signature
Re: [O] Tags aliases
Dear Eduardo, I am not aware about aliases explicitly, but you can use tag hierarchy in your use case: http://orgmode.org/manual/Tag-hierarchy.html#Tag-hierarchy It will be something like #+TAGS: [ food : vegetables snack ] Regards, Ihor Eduardo Mercovich writes: > Dear Orgers. > > Orgmode has extensive support for tags. However, even after some > extensive search (maybe I used the wrong keywords) I couldn't > found info on how to create tags aliases. > > As an example, lets assume we have a heading with the tag :snack: > and another with :vegetables:. And I'd like to be able to find > them both when searching for :food:. > How can we do this? > > As always, thanks a lot for your time and attention... :) > > > -- > eduardo mercovich > > Donde se cruzan tus talentos > con las necesidades del mundo, > ahí está tu vocación. > (Anónimo) > -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature
Re: [O] TODO in org-mode
Hi, Welcome to Org mode community. You will need to add your org file to agenda_files (org->file list for agenda->add/move current file...). If you want to learn more about basic concepts, it may be also a good idea to watch Rainer König's org mode tutorial series (https://www.youtube.com/watch?v=sQS06Qjnkcc&list=PLVtKhBrRV_ZkPnBtt_TD1Cs9PJlU0IIdE). P.S. I recommend you to familiarize yourself with key bindings. Using menu is very too much slower. Regards, Ihor "M. P." writes: > I know this is basic but I am having difficulty getting TODO states to work. > In ORG I select new heading than TODO from the menu but I don’t understand > how to save this so that it works with things like agenda view? -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature
Re: [O] New feature? Remove duplicate subheadings, preserving order
Is there any possible way to prevent it more reliably? I am aware of org-catch-invisible-edits, but this is obviously not enough. Does it make sense to generate some kind of subtree based diff after each change, so that user can review all recent changes in org files? Ihor Adam Porter writes: > Nick Dokos writes: > >> There be dragons. >> >> The problem is that some things happen invisibly and far away from >> where you are, so you don't know about it and you don't find out for a >> couple of weeks. Undo and automatic backups are useless in that case. >> >> That *has* happened: there have been multiple postings in the ML about >> such problems. Whenever it has happened, the devs have always modified >> org to make it safer: that is the prudent thing to do and the correct >> course of action IMO. >> >> Hell hath no fury like an orgmode user who lost part of his/her >> precious org file because of an errant keystroke a month ago and was >> not aware of the loss until it was too late. > > Indeed. Maybe I'm just paranoid, but having worked with Org code a bit, > I still wonder sometimes if I have ever accidentally wiped out a subtree > without noticing. Would I ever notice that it's missing? Even if it's > stored in git or a backup, how can I restore something that I don't know > needs restoring? > > Some of this is simply the nature of computers, I think--a keystroke > here, a blink of the eye there, and poof, the data is gone. If the > point is in one buffer when my fingers press C-c C-x C-w, but my eyes > are in another buffer, does the subtree still get deleted? :) > > And despite how great Emacs and Org are, this is one area in which their > power may make them more vulnerable to such issues. Their use of global > state and special variables also makes unintended consequences easier to > achieve. > > This is why I think we should always be very careful. Org is nothing if > we can't trust it to keep our data safe! :) > > -- Ihor Radchenko, PhD Student Singapore University of Technology and Design, 8 Somapah Road Singapore 487372 Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg Tel: +6584017977 signature.asc Description: PGP signature
Re: [O] properties using other properties
I recommend looking into org-edna
(http://www.nongnu.org/org-edna-el/#conditional_forms).
You can try to use "has-property" in combination with "set-property" as
a TRIGGER.
Alternatively, you can customize org-property-changed-functions (see
https://www.reddit.com/r/emacs/comments/7gr9ps/add_logbook_entry_and_note_on_orgmode_property/)
and reimplement org-edna functionality for your purposes.
Regards,
Ihor
cpb writes:
> Is there a way to set properties using other properties? Doesn't matter
> if its on export only, though it would be nice to have it in-situ.
>
> here's an example (obviously doesn't work), where a project properties
> for the project client only needs the CLIENT property filled, the rest
> of it automatically populates on export. Would save having to duplicate
> the data where there are a lot of projects.
>
>
> * client1
> :PROPERTIES:
> :CUSTOM_ID:client1
> :NAME: a client
> :ADDRESS: an address
> :EMAIL:an email
> :URL: a website
> :END:
>
> * project1
> :PROPERTIES:
> :CUSTOM_ID:project1
> :NAME: a project
> :CLIENT: client1
> :CLIENT_NAME: {{{property(NAME,#{{{property(CLIENT)}}})}}}
> :CLIENT_ADDRESS: {{{property(ADDRESS,#{{{property(CLIENT)}}})}}}
> :CLIENT_EMAIL: {{{property(EMAIL,#{{{property(CLIENT)}}})}}}
> :EXPORT_FILE_NAME: ./a_project
> :END:
>
> project: {{{property(NAME)}}}
> for: {{{property(CLIENT)}}}
> {{{property(CLIENT_ADDRESS)}}}
> {{{property(CLIENT_EMAIL)}}}
>
--
Ihor Radchenko,
PhD Student
Singapore University of Technology and Design,
8 Somapah Road Singapore 487372
Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg
Tel: +6584017977
signature.asc
Description: PGP signature
Re: Visibility cycling with inline tasks 2
Michael Dauer writes: > Hi, > > Was something wrong with my previous report or is nobody interested in > inline tasks? Your report is fine, but please note the following (https://orgmode.org/worg/org-mailing-list.html): >> What to do if you don't receive an answer >> If your email is referenced on updates.orgmode.org, it will get the >> attention of the maintainers when they have enough time. (Remember >> they work on a volunteer basis.) >> >> If your email is not referenced there and you think it deserves more >> attention, you can do this: >> >> If it is a bug report, check that you provided enough information, >> especially the Org and Emacs versions and a step-by-step recipe to >> reproduce the bug. >> >> If it is a question, give more information on what you tried, why you >> still have the question and why the answer may be of interest for >> other subscribers. >> >> If you have nothing special to add to your first message and just >> want to "bump" the thread, please wait at least one month before >> doing so. Your issue is probably fixed in my personal dev branch at https://github.com/yantar92/org Best, Ihor
Re: Visibility cycling with inline tasks 2
Michael Dauer writes: > I wanted to help you with testing. But I could not find a branch dev in > that repo. I did not mean literally "dev" branch. The default branch there is my local patches I plan to merge to Org eventually. > Anyway, I'll wait for it to be populated into the main repo. When should I > retry there? I will prepare the patch for the main repo and post a reply to your original bug report once I get time to do it. Best, Ihor
Re: [PATCH] org-manual.org: Some correction of Installation section
Max Nikulin writes: > - I am in doubts whether "emacs -Q -L ~/src/org-mode/lisp" way to try > version from git is important enough for the manual. I have added a > separate patch however to discuss such change. I feel that it should not be in the manual. However, it may be helpful addition to https://orgmode.org/contribute.html Also, I'd recommend "emacs -Q -L ~/src/org-mode/list -l org", making sure that the right version of Org mode is loaded regardless of the local config. Best, Ihor
Re: The align of time is not beautiful as 9.4 when I update to org 9.5.
tumashu writes: > Hello: > > > When I update to org 9.5, I find that the align of time like "7:00" has > been changed. > > I think the new style is not beautiful as old style. > > 1. New style look like not align to the first char, for the width of 9 looks > like > 1 > 2. the old style is align ":" It has been reported in https://orgmode.org/list/87czr6uhhk@alphapapa.net However, the problem is not reproducible. Are you able to provide a recipe? Best, Ihor
Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)
Robert Klein writes: > When trying to run a table with missing values with ob-gnuplot.el > there's a “:missing value” option. ob-gnuplot is supposed to put the > “value” into the place of empty cell values before calling on gnuplot. > It doesn't do this currently. Confirmed The problem is partially because of the way `org-table--to-generic-cell' works. It disallows custom processing of empty table cells unless both :raw and :backend arguments are supplied to `orgtbl-to-generic'. The attached patch should fix the issue, though it may be more reasonable to fix orgtbl-to-generic logic. Nicolas, Is there a rationale behind bypassing :fmt and :hfmt for empty table cells in `org-table--to-generic-cell'? In this patch, I have to work around this using :raw parameter in `orgtbl-to-generic' call. I do not feel like such workaround should be needed. Best, Ihor >From 7033289d7e717eb841d550fbdbc0cc878b96cd32 Mon Sep 17 00:00:00 2001 Message-Id: <7033289d7e717eb841d550fbdbc0cc878b96cd32.1633005978.git.yanta...@gmail.com> From: Ihor Radchenko Date: Thu, 30 Sep 2021 20:40:37 +0800 Subject: [PATCH] ob-gnuplot: Honour :missing argument * lisp/ob-gnuplot.el (org-babel-gnuplot-table-to-data): Force applying `org-babel-gnuplot-quote-tsv-field' to empty table cells when converting org tables to gnuplot input. By default, `orgtbl-to-generic' ignores :fmt for empty table cells. We need to set :raw to non-nil AND :backend to non-nil to force custom formatting of empty table cells. Fixes https://orgmode.org/list/20210617211347.59e4d...@happy.intern.roklein.de --- 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 6489c23f5..120aaa18e 100644 --- a/lisp/ob-gnuplot.el +++ b/lisp/ob-gnuplot.el @@ -272,7 +272,7 @@ (defun org-babel-gnuplot-table-to-data (table data-file params) (orgtbl-to-generic table (org-combine-plists - '(:sep "\t" :fmt org-babel-gnuplot-quote-tsv-field) + '(:sep "\t" :fmt org-babel-gnuplot-quote-tsv-field :raw t :backend ascii) params) data-file) -- 2.32.0
Re: [PATCH] Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]
Sébastien Miquel writes: > I had done some testing, and some more recently. The patch only affects > latex-fragments and org entities to be edited which do not need to start > at a > beginning of line (latex-fragments, inline src blocks, footnote > definitions). Also looks fine for me. Best, Ihor
Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)
Ihor Radchenko writes: > The attached patch should fix the issue, though it may be more > reasonable to fix orgtbl-to-generic logic. Given Nicholas' reply, changing orgtbl-to-generic may not be a good idea and break other code using orgtbl-to-generic. Applied as ddee7b617 on bugfix Best, Ihor Fixed
Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)
Nicolas Goaziou writes: > I'm not sure. I wrote this some years ago. I guess the rationale at that > time was that it didn't feel useful to apply a format to an empty cell. > For example, if you use `:fmt "$%s$"', I assume you wouldn't want to get > "$$" in otherwise empty cells. Also makes sense. At this point, third-party code is likely to rely on the existing logic, so I do not see any reason to insist on changing org-table. To avoid confusion, can we change the docstring explicitly saying that empty cells are ignored? (see the attached) Best, Ihor >From 60365a164147dfc71f0047661c143b54064a459b Mon Sep 17 00:00:00 2001 Message-Id: <60365a164147dfc71f0047661c143b54064a459b.1633060596.git.yanta...@gmail.com> From: Ihor Radchenko Date: Fri, 1 Oct 2021 11:40:54 +0800 Subject: [PATCH] orgtbl-to-generic: Mention that :fmt is ignored for empty cells * lisp/org-table.el (orgtbl-to-generic): Amend docstring mentioning that :fmt is ignored for empty table cells. --- lisp/org-table.el | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lisp/org-table.el b/lisp/org-table.el index 89c57fb06..3fed15054 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -5649,6 +5649,9 @@ (defun orgtbl-to-generic (table params) (:fmt (2 \"$%s$\" 4 (lambda (c) (format \"$%s$\" c + The format is ignored for empty fields. Use :raw t with non-nil + :backend option to force formatting empty fields. + :hlstart :hllstart :hlend :hllend :hsep :hlfmt :hllfmt :hfmt Same as above, specific for the header lines in the table. -- 2.32.0
Re: Visibility cycling with inline tasks 2
No Wayman writes: > I can confirm the issue you've outlined on latest 'main'. > To me it looks like the problem is in `org-inline-hide-tasks'. > I don't use inline tasks, so I'm not sure what the exact expected > behavior is, > but that function uses a `while' during `org-cycle-hook' to > iterate through all of the headings. > My intuition is that it's overshooting a boundary and toggling > visibility on more than it should. > > Does the attached patch behave more in line with what you expect? Your patch will fail with the following counterexample (when there is a subheading containing an inlinetask inside current heading): * Example ** heading 1 x ** heading 2 *** TODO Test access with provided credentials x *** END *** subheading *** TODO State "high value" targets :@CB: x *** END ** heading 3 x The recepy is same with original: 1. emacs -Q 2. paste the following snipped (right into the scratch buffer) 3. execute the two commands at the end C-x C-e for each 4. collapse all (TAB TAB) 5. expand Example (TAB) 5. go to heading 2 and expand it (TAB) I propose an alternative patch. See the attached. Best, Ihor >From ec78cbc00b4e2abf201149b76ce41df87869627f Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Fri, 1 Oct 2021 14:03:47 +0800 Subject: [PATCH] org-inlinetask.el: Fix visibility cycling for inlinetasks * lisp/org-inlinetask.el (org-inlinetask-hide-tasks): Make sure that we loop over inlinetasks inside current section only. `org-inlinetask-goto-end' moves point to the end of the inlinetask element. If an inlinetask is followed by a heading, the function logic will treat the heading as the beginning of another inline task. Prevent it by moving the point at the end of the END line of the inlinetask. Fixes https://list.orgmode.org/orgmode/CAP7OBx+rs-7v4jstEFYC4u0=0nz3xjkfb3cnrwedvjmwrtv...@mail.gmail.com/ --- lisp/org-inlinetask.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el index 3379a2e46..6320be12b 100644 --- a/lisp/org-inlinetask.el +++ b/lisp/org-inlinetask.el @@ -338,7 +338,8 @@ (defun org-inlinetask-hide-tasks (state) (or (org-inlinetask-at-task-p) (and (outline-next-heading) (org-inlinetask-at-task-p))) (org-inlinetask-toggle-visibility) - (org-inlinetask-goto-end)) + (org-inlinetask-goto-end) + (backward-char)) (defun org-inlinetask-remove-END-maybe () "Remove an END line when present." -- 2.32.0
Re: searching agenda from TRAMP
JARZz writes: > I don't know what happens behind the scenes exactly, but it takes a good > minute or to load my agenda with all the files, and it can take 10-15 minutes > to search through them for a specific string. This problem also happens when > I used sshfs, which makes me believe more strongly the problem is, again, not > with the ssh connection itself, but with the indexing. Does opening org files manually take a lot of time for you? Are you using org-id? Can you track down the problematic function using M-x profiler-start / profiler-report? Best, Ihor
Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)
Nicolas Goaziou writes: >> At this point, third-party code is likely to rely on the existing logic, >> so I do not see any reason to insist on changing org-table. > > If you think it is overall an improvement, feel free to discuss it. I'm > merely pointing out what was the initial intent, not necessarily how it > should be. I feel that it would be more consistent, though not necessary an improvement. Special formatting for empty cells is probably a rare need---much more rare compared to skipping them. I am fine with current behaviour if it is documented. It's just that it caught me by surprise while fixing the current bug report. >> To avoid confusion, can we change the docstring explicitly saying that >> empty cells are ignored? (see the attached) > Sure. Thanks. Applied as 60365a164 on main. Best, Ihor
Re: Need absolute org-attach-id-dir to attach in buffers without filename
Nick Anderson writes: > I have an org-mode file that contains headings with attachments. When I > `org-mime-org-buffer-htmlize' I get an error, `"Need absolute > `org-attach-id-dir' to attach in buffers without filename"'. > `org-attach-id-dir' has the value `data/'. I get this error even when I > am in the buffer for the file, not simply a capture buffer. This seems > to come [from org-attach]. I cannot reproduce. Can you provide a recipe? Best, Ihor
Re: Bug: font-lock error with - in code-mode [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]
"Dr. Arne Babenhauserheide" writes:
> When parsing the following code:
>
> Am richtigen Ort zur richtigen Zeit (=+=; 1x pro Abenteuer im richtigen
> Moment auftauchen), Computeraffinität (=+= oder =++=; Bonus von 3 oder 6),
> Kurze Aufmerksamskeitsspanne (~-~), Photographisches Gedächtnis (=+=),
> Primitive Technologie (~-~), Schreckhaft (~-~), Schrecklich Schusselig (~-~),
> Toller Laptop (=+=) oder Verträumt (~-~).
>
> The fourth line is highlighted as code beginning at the first ~-~ until
> the final closing paren (")") of the paragraph.
Confirmed
The fix is attached.
Best,
Ihor
>From a4c864b7f983a135e8debbc32d8ef4ff3f2e89f4 Mon Sep 17 00:00:00 2001
Message-Id:
From: Ihor Radchenko
Date: Fri, 1 Oct 2021 17:47:02 +0800
Subject: [PATCH] org-do-emphasis-faces: Never treat closing marker as next
opening marker
* lisp/org.el (org-do-emphasis-faces): Make sure that we never match
ending marker of an emphasis as a beginning marker of another
emphasis. For example, in "(~-~) test (~+~)" "~) test (~" is a valid
code match unless we move point to the end the first code emphasis
completely during parsing.
Fixes https://orgmode.org/list/87fsujp7mc@web.de
---
lisp/org.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/org.el b/lisp/org.el
index 9608b52ee..9f68182d9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4855,6 +4855,7 @@ (defun org-do-emphasis-faces (limit)
'(invisible t))
(add-text-properties (match-beginning 3) (match-end 3)
'(invisible t)))
+(goto-char (match-end 0))
(throw :exit t)
(defun org-emphasize (&optional char)
--
2.32.0
Re: searching agenda from TRAMP
JARZz writes: >> Does opening org files manually take a lot of time for you? >> >> Are you using org-id? >> >> Can you track down the problematic function using M-x profiler-start / > > These are good questions. > I *do* use org-id. I started doing this more recently. I use a package called > super-links. That could be a cause of it? Can you temporarily set org-id-track-globally to nil and try whatever commands is slow for you? > I can run profiler-start but I'm not sure what I'm looking for. Everything > works OK (as far as I can tell), it's only when I want to search something > specific it takes forever and a half. But of course, I'll take the advise > above and try to run clean Emacs, see what happens then. As a generic advice, you can do profiler-start -> run the command that you know is slow -> profiler-report -> post the report here. Profiler report can be as helpful as debugger backtrace when tracking down performance issues. Best, Ihor
Re: org-attach-use-inheritance inherits from sibling
Johan Tolö writes: > Hi, > I have set 'org-attach-use-inheritance' to t. If a heading has no > parents it seems to inherit from the first heading in the file > which has either the ID or DIR property set, ie from the first > sibling above it. I'm guessing this is not the expected behaviour? I cannot reproduce on current main. Are you still seeing this problem? Best, Ihor
Re: Bug: font-lock error with - in code-mode [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]
Bastien writes: > Hi Ihor, > > Ihor Radchenko writes: > >> The fix is attached. > > Looks good, feel free to apply in the bugfix branch. Done (fa315986a). Marking the bug as fixed. Should I also merge main with bugfix every time? Best, Ihor
Re: Bug: font-lock error with - in code-mode [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]
Also marking patch as applied
Re: Bug: font-lock error with - in code-mode [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]
Bastien writes: > Ihor Radchenko writes: > >> Should I also merge main with bugfix every time? > > You should merge bugfix into main, yes (but not main into bugfix.) Thanks for the clarification. It indeed makes sense, but I was not sure if merging too frequently is ok or not. Best, Ihor
Re: Elegant way to export org to Markdown ?
Jean-Christophe Helary writes: > I'm trying to work with SourceHut (sr.ht) and right now they only accept > Markdown syntax for their readme/wiki files. > > Since I work in Emacs/org-mode to write my documents (and try to stick to > that), I'd like to know if there is an elegant way to export org syntax to > MarkDown. > > I was thinking that the export-dispatch had an option for Plain Text / > Markdown, but that doesn't seem to be the case. I think you just need to load the markdown export backend in your config: (require 'ox-md) Best, Ihor
Re: Elegant way to export org to Markdown ?
Jean-Christophe Helary writes: > My follow-up question is, most of the ox-stuff seem to be installed by > default, as far as I can tell. Why is ox-md not ? Not most. The default export backends are: > org-export-backends is a variable defined in org.el. > > Value > (ascii html icalendar latex odt) You can also customise this variable instead of direct (require 'ox-md) Why not all backends are loaded? Mostly to reduce Org loading speed that some people complain about. Best, Ihor
[PATCH] Bug: Unintended column added to table [9.4.6 (9.4.6-gab9f2a @ /home/user/.emacs.d/elpa/org-9.4.6/)]
Ihor Radchenko writes: > spect...@mail.com writes: > >> In a preexisting org table, hitting can add a new, unintended column >> >> Bug: After the 2nd iteration, org adds a unintended new column. Further >> iteration adds more columns. > > Confirmed > > The problem appears somewhere inside org-table-justify-field-maybe And here is the fix. I am not familiar with org-table codebase, so feedback would be appreciated. Best, Ihor >From 36485b234d607be16cc06912dc85b9984a0142af Mon Sep 17 00:00:00 2001 Message-Id: <36485b234d607be16cc06912dc85b9984a0142af.1633157571.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sat, 2 Oct 2021 14:44:30 +0800 Subject: [PATCH] org-table.el: Do not create new field when at EOL after table line * lisp/org-table.el (org-table-justify-field-maybe): Do not treat "|$" as unclosed table field. Fixes https://orgmode.org/list/trinity-2561db57-1561-470b-982f-0d91ddf4f145-1629900012884@3c-app-mailcom-lxa06 --- lisp/org-table.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index 89c57fb06..e34872fb4 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -4436,7 +4436,7 @@ (defun org-table-justify-field-maybe (&optional new) (col (org-table-current-column))) (when (> col 0) (skip-chars-backward "^|") - (if (not (looking-at " *\\([^|\n]*?\\) *\\(|\\|$\\)")) + (if (not (looking-at " *\\(?:\\([^|\n]*?\\) *\\(|\\)\\|\\([^|\n]+?\\) *\\($\\)\\)")) (setq org-table-may-need-update t) (let* ((align (nth (1- col) org-table-last-alignment)) (width (nth (1- col) org-table-last-column-widths)) -- 2.32.0
Re: Elegant way to export org to Markdown ?
Jean-Christophe Helary writes: > Next (related) question: > > Why that ugly number in front of headers defined with in HTML ? I have little knowledge about HTML export... I blind guess is that you may disable org-export-with-section-numbers (see "14.1.5 Options for the exporters" section of the manual) As for "ugly", it is probably subjective. Can you share a screenshot and suggest a concrete improvement? Also, are you on Org 9.5? I have seen some patches in that area lately. Best, Ihor
Re: Stable 9.5: invalid function (date date)
Jarmo Hurri writes:
> Greetings.
>
> I just installed (stable) 9.5. from GNU ELPA, and tried to see what my
> agenda for today looks like. The agenda is empty, and I got error
>
> Debugger entered--Lisp error: (invalid-function (date date))
>
> with backtrace
>
> (date date)()
> org-agenda-get-day-entries("/home/jarmo/projects/gtd/faq.org" (10 2 2021)
> :deadline :scheduled :timestamp :sexp)
Looks like garbled installation. Can you try to re-install Org?
Best,
Ihor
Re: [PATCH] Re: New source block results option for attaching file to node
Ryan Scott writes: >(default-directory > -(or (and dir (file-name-as-directory dir)) default-directory)) > +(or (and dir (if (eq dir 'attach) > +(org-attach-dir t) > + (file-name-as-directory dir))) > + default-directory)) This does not always work. Some ob-*.el code (namely, ob-lisp have the following: (let ((dir (if (assq :dir params) (cdr (assq :dir params)) default-directory))) As you can see, :dir parameter is overriding default-directory. If :dir is set to symbol 'attach, execution will fail. I think that you also need to override :dir in the parameter list and put actual path to attachment dir instead of symbol. That way, we will not need to change every possible ob-*.el implementation to account for new 'attach option. Also, marking this as patch. Best, Ihor
Re: Manually/programmatically adding a state transition message
Trevoke writes: > I've looked at the code around adding a log-note and it looks like it might > be automatable but there's a lot of pieces I don't know in there, so if > there's a way to add just a state transition with a programmatically > provided note, I'll take that, please :) It may be fragile, but you can try let-binding (org-inhibit-logging 'note) around elisp org-todo call Best, Ihor
Re: Advice for new feature 'image block` for new `sketch-mode` package
dalanicolai writes: > As svg is just xml, for small sketches I would prefer to insert directly > the xml > into the org-buffer within an image block, in which I can quickly toggle > showing > the image using `C-c C-c` (or `org-toggle-inline-images`). Also, exporting > such > xml should work perfectly fine when exporting to e.g. html. > I guess a normal source block is not suitable, because I would like to > create > the image overlay directly within the block. I am happy to (help) > implement(ing) > such a feature, but I thought it would be wise to first discuss and > 'enquire' > for suggestions here. You can try to define a special block and add appropriate org-ctrl-c-ctrl-c-hook to display the overlay. For defining special blocks, you can try https://github.com/alhassy/org-special-block-extras/ Hope it helps. Best, Ihor
Re: ox-bibtex incorrectly renders bibtex entries with slashes.
Vladimir Nikishkin writes: > Does anybody have a workaround for this? Note that ox-bibtex is not a part of Org now. Maybe you try using new org-cite syntax instead? It should support HTML natively. Best, Ihor
Re: Re : Re: Capture abort: Symbol’s function definition is void: turn-on-org-provide
Joseph Vidal-Rosset writes: > I got the following backtrace: Err... This looks strange. Can you try re-installing Org? Or otherwise go to org-capture.el, M-x eval-buffer, and try to get backtrace again (hopefully, it can become more readable then). Best, Ihor
[PATCH] Bug: Indenting empty description list item leaves point at beginning of line [9.4.4]
Bodertz writes: > As you can see, point is at the beginning of the line. I think it > should be after the dash, as is the case when indenting plain list > items. The fix is attached. Best, Ihor >From 63870bec28e59732cbbdf8b2534f6ece96e2d5d8 Mon Sep 17 00:00:00 2001 Message-Id: <63870bec28e59732cbbdf8b2534f6ece96e2d5d8.1633171544.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sat, 2 Oct 2021 18:32:34 +0800 Subject: [PATCH] org-list: Do not move point when promoting/demoting items * lisp/org-list.el (org-list-struct-apply-struct): Make sure the origin marker is not moved to bol when promoting/demoting item in special case: - item - :: * testing/lisp/test-org-list.el (test-org-list/indent-item): Add test Fixes https://orgmode.org/list/87o88hlkvv@gmail.com --- lisp/org-list.el | 5 - testing/lisp/test-org-list.el | 10 +- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index 2bd9dc4d9..b6ab14f84 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -1866,7 +1866,10 @@ (defun org-list-struct-apply-struct (struct old-struct) (looking-at org-list-full-item-re) ;; a. Replace bullet (unless (equal old-bul new-bul) - (replace-match new-bul nil nil nil 1)) +(save-excursion + (replace-match "" nil nil nil 1) + (goto-char (match-end 1)) + (insert-before-markers new-bul))) ;; b. Replace checkbox. (cond ((equal (match-string 3) new-box)) diff --git a/testing/lisp/test-org-list.el b/testing/lisp/test-org-list.el index 3689a172f..e3d904b1e 100644 --- a/testing/lisp/test-org-list.el +++ b/testing/lisp/test-org-list.el @@ -298,7 +298,15 @@ (ert-deftest test-org-list/indent-item () (push-mark (point) t t) (goto-char (point-max)) (let (org-list-demote-modify-bullet) (org-indent-item)) - (buffer-string) + (buffer-string + ;; When point is right after empty item, do not move point. + (should + (= 13 + (org-test-with-temp-text " +- item +- ::" +(org-indent-item) +(point) (ert-deftest test-org-list/indent-item-tree () "Test `org-indent-item-tree' specifications." -- 2.32.0
Re: Grabbing the link to a message on the archive
Max Nikulin writes: > Unfortunately I have no idea how to get Message-ID having a link to > particular message on lists.gnu.org without search by e.g. subject and > author. It can be parsed from the html. Something like below (it is my home-made parser, but I think the idea should be clear): (org-capture-ref-set-bibtex-field :key (org-capture-ref-query-dom :tag 'form :tag 'input :attr '(name . "d") :attr 'value)) Best, Ihor
Re: Bug: org-map-entries calls file-exists-p when SCOPE is nil [9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)]
Rodrigo Morales writes: > #+BEGIN_EXAMPLE > Non-existent agenda file ~/foo.org. [R]emove from list or [A]bort? > #+END_EXAMPLE Confirmed
