[O] Advance notice of birthdays in org-mode via org-contacts
I'm trying to come up with a better way to give myself advanced notice on some peoples' birthdays coming up. Right now, I use the following in a `cal.org` file to give me notice in agenda that birthdays are coming up: ``` * BDays :bday: %%(org-contacts-anniversaries "BIRTHDAY") ``` The generally feeds off a `contacts.org` entry of the nature: ``` *** John Wick :PROPERTIES: :EMAIL: therealj...@notthepuppy.com :BIRTHDAY: 1975-06-06 :END: ``` What I'd like is to get, on virtually all birthdays , a week's notice through due soon (which I'll sort out in org-super-agenda in the view). Alternatively, is there a nicer way to tag or otherwise note some birthdays in the `contacts.org` so that I could note special people (close friends, family, etc) where I could set a specific advanced notice period so that I have time to do something special for them etc? Would love to hear peoples' approaches to this. In general, if I'm not looking out 2 weeks ahead (I spend most time in the day view), I can get surprised. thanks! Daryl.
[O] Show APPTs every day in Agneda
Hi, I've APPTs like "Vacation" that last 14 days or so. Is there an option/way to show such an APPT for every concerned day, and not only for the border days, so that when I for example want to make a doctor's appointment I see for the respective day that I'm on vacation on that day? TIA, Michael.
[O] manual errata
org 9.2 pdf manual In Chapter 8, p. 78 function org-mark-entry-for-agenda action C-c C-x C-k This function doesn't exist in my version of org-mode (9.2.3) -- = Ian Garmaise Consultant Phorix Solutions Group ia...@phorixsol.com Toronto cell: 416.432.2251 NYC: 917.512.9535 https://www.linkedin.com/in/igarmaise/ http://www.PhorixSol.com
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi again! > -Original Message- > From: Ihor Radchenko > Sent: den 14 december 2018 03:16 > To: Gustav Wikström > Cc: emacs-orgmode > Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options > > > 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. I just wanted to say I'm working on this. More info will come in a separate thread soon! Kind regards, Gustav
Re: [O] [RFC] Link-type for attachments, more attach options
Hi again, Some updates, and a fresh patch...! I won't say that much here since the patch speaks for itself (It contains a chapter to be added to ORG-NEWS). It's patch 0002 that is the important one. See sidenote below for a comment about patch 0001. I have to mention that the patch has grown quite a lot. With the Additional changes, I've taken the liberty to promote attachments to a level-1 headline within the documentation! Please review the new and improved" patch. > -Original Message- > From: Nicolas Goaziou > Sent: den 27 november 2018 10:40 > To: Gustav Wikström > Cc: emacs-orgmode > Subject: Re: [RFC] Link-type for attachments, more attach options > > Hello, > > Gustav Wikström writes: > > > Too bad, "@" was growing on me. @ is currently automatically set as > > a tag when attaching files to nodes. > > You probably customized `org-attach-auto-tag' because this is not the > default behaviour. It adds "ATTACH" tag automatically. Yeah, you're right. My bad! > I prefer not to consider Gmail and Outlook as references, or even > standards. As another data point, Gnus uses "Attachment: " to list > attachments. I won't argue any longer. And I'll do as you say. Attachment: it is! > > Yeah, I don't know why it's configured like that from the start. A bit > > convoluted. Not > > sure of what way to go forward though. I can see at least two paths: > > > > 1) Rename `org-attach-allow-inheritance' to > > `org-attach-enable-inheritance' and always make attachments inherited > > when that is set to "t". Deprecate "ATTACH_DIR_INHERIT". With this I'd > > also change the precedence-logic between ATTACH_DIR & ID properties > > and make ID-based attachment inherit as well. The properties > > ATTACH_DIR and ID should be inherited from the closest node when > > resolving attachments, with ATTACH_DIR having precedence over ID if > > both exist for the same node. > > Why defining `org-attach-enable-inheritance' at all? There is already > `org-use-property-inheritance' for this. We do not need another > conflicting variable. > > I don't think we should inherit ID properties either. ID is defined > outside "org-attach.el", so this library shouldn't mess with its > meaning. Does inheriting ID properties give anything valuable? Inheriting ID's for attachments is actually valuable. It makes it possible, for example, to add attachment-links in subheadings to the node the attachment is defined on. After having used this for quite some time now it feels quite natural to have inheritance switched on for attachments. No negative side-effects at all. > > 2) remove `org-attach-allow-inheritance' and only rely on the > > "ATTACH_DIR_INHERIT" property of any of the parent nodes to decide if > > the "ATTACH_DIR" property should be inherited. This would be a smaller > > change from the user's perspective, where we're basically saying you > > cannot disable inheritance, but it's only active when a node has the > > ATTACH_DIR_INHERIT-property. > > > > I prefer path (1). > > So do I, with the remarks above. I went with path (1) and tried to fit it into the already existing property inheritance framework. > > +This list shows the full set of built-in external link types, > > +including examples for each: > > + > > +| Link Type | Description | Example| > > +|---+--+---| > > +| http | web | > > =http://www.astro.uva.nl/=dominik= | > > +| https | secure web | =https://orgmode.org/= | > > +| doi | DOI for electronic resources | =doi:10.1000/182= | > > +| file | file-links | > > =file:/home/dominik/images/jupiter.jpg= | > > +| | | > > =/home/dominik/images/jupiter.jpg= (same as above)| > > +| | | =file:papers/last.pdf= | > > +| | | =./papers/last.pdf= (same as > > above) | > > +| | | > > =file:/ssh:me@some.where:papers/last.pdf= (remote)| > > +| | | > > =/ssh:me@some.where:papers/last.pdf= (same as above) | > > +| | | =file:sometextfile::NNN= > > (jump to line number)| > > +| | | =file:projects.org= | > > +| | | =file:projects.org::some > > words= (text search) [fn:28] | > > +| | | =file:projects.org::*task > > title= (headline search)| > > +| @ | links to attachments | =@:projects.org= | > > +| | | =@:projects.org::some words= > > (text search) | > > +| docview | doc-view mode| > > =docview:papers/last.pdf::NNN= | > > +| id| Link to heading by id| > > =id:B7423F
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Feng Shu, > -Original Message- > From: Feng Shu > Sent: den 4 januari 2019 13:22 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > I like this feature very much! I'm glad! I've just now sent an updated patch to the mailing-list. It contains quite substantial changes. Maybe you care to review it as well? Best Gustav
[O] s-right in agenda seems inconsistent
this is the best bug report i can do although it is not to my standards. i hope it makes sense. [to make the bug report even worse, recent org is not working for me so all i can do is offer you 9.1.14] in agenda org-agenda-do-date-later s-right i often have a bunch of repeaters that are scheduled, which show up today [not as past scheduled]. i do s-right on them, and some go to today, while some go to tomorrow. this feels inconsistent. i'd like them to all go to tomorrow. idk if this might be a matter of internal logic, or a bug, but it forces me to actually look at the date that s-right goes to. i'd like to be confident that they will all be treated the same. perhaps some are being moved immediately to today a la the variable while others are normally being moved. perhaps this is because some are /actually/ today while others are /repeated to/ today. org-agenda-move-date-from-past-immediately-to-today is t. these settings wfm but i suspect might be related. i think a consistent s-right behavior would be a great option if this is not a bug, and a great thing to have if it is a bug. (setq org-agenda-show-future-repeats nil) (setq org-agenda-prefer-last-repeat t) thanks. please ignore if not make sense. i cannot do better at this time.
Re: [O] s-right in agenda seems inconsistent
p.s. i should point out that i am ok with not having an indicator that they are different from one another -- i just want the s-right behavior to work identically for both. i'd be ok with all going to today or all going to tomorrow, but prefer all going to tomorrow. [an indicator of some type that it is a repeated instance would be great if it were possible, just not necessary.]
