Re: [MAINTENANCE] Org orphanage?
Ihor Radchenko writes: https://github.com/flexibeast/org-vcard page explicitly says that it is looking for a new maintainer at least since 9 months ago. (The author is in CC for this thread) Indeed, and i've been actively following this discussion. :-) i've only had one bite, in private, and that was from someone who wasn't particularly familiar with either Lisps or vCard, but who was offering to pitch in alongside me. i explained that it's not that i need an assistant, it's that i need a replacement, as i can no longer be a maintainer. (i've got so much on my life plate that i'm trying to wind back my volunteer ICT commitments to a relatively small core, including my man page ports, and random straightforward contributions involving few to no hoops.) The person felt they were not suitable for such a role. Also, as a general note, i'm actually no longer using Org for contacts management, so i'm not even dogfooding org-vcard anymore. Alexis.
feature request: easy embedding of images
Hello, my fellow org-mode lovers, This is a feature request — or failing that, a request for advice on a settings configuration which could produce this functionality now. I wish org-mode had the ability to attach images to notes, display them inline, and have that work well. By “work well” I mean a few specific things: • the image is automatically resized to maintain aspect ratio and fit horizontally with a civilized margin, so that I can resize my emacs window without the image disappearing or swamping the other content. • you can still scroll the window one line height unit at a time, without the entire image being scrolled as if it were one giant line, breaking scrolling, as seems to happen on my emacs (version 28.x on Linux) • drag and drop, so I can add the image by dragging it in, for instance from a screenshot tool or from an image on a web page. • sensible defaults for storing the images bundled with notes and keeping the two associated, so that I don't subsequently live in fear of ever moving my org files Why is this valuable, to me at least? I use org to take notes all day, during meetings, on reading matter, in the development of my own thoughts. Embedding images would let me collect every kind of resource I can't reproduce by typing or copy and pasting text — photos of slides during presentations, photos of whiteboard, key snippets from websites, handwritten notes and equations, etc.. Alexis
Re: [MAINTENANCE] Org orphanage?
Ihor Radchenko writes: P.S. Does sourcehut have a notion of organizations? Not at the moment, but Drew recently blogged that the plan is to commence work on this soon: We also plan on tackling another long-awaited feature soon: user groups, or organizations. This and the other features described have been blocked on the completion of our GraphQL work, and with this work out of the way, it’s time to prepare for a flurry of new feature development to round out the alpha and finally bring the SourceHut beta into life. -- https://sourcehut.org/blog/2022-11-15-four-years/ Alexis.
Re: [O] Possible bug: Can not search for text in links - only description
On 2015-03-21T01:59:07+1100, Richard Lawrence said: RL> I am not sure if this counts as a bug or not, so someone else RL> should still address this question. Maybe this is the desired RL> behavior, given that the link text is hidden? Or maybe it's just RL> not possible to search in hidden text? Cf. the `search-invisible` variable: search-invisible is a variable defined in `isearch.el'. Its value is open Documentation: If t incremental search/query-replace can match hidden text. A nil value means don't match invisible text. When the value is `open', if the text matched is made invisible by an overlay having an `invisible' property and that overlay has a property `isearch-open-invisible', then incremental search will show the contents. (This applies when using `outline.el' and `hideshow.el'.) To temporarily change the value for an active incremental search, use M-s i. Alexis.
Re: [O] ID property generated by org-mobile
On 2015-03-20T22:45:02+1100, Randomcoder said: R> Does the ID property have any use? I know I can disable it, but R> where R> is it being used ? (the ID property that org-mobile generates for R> each heading) R> Are there any drawbacks to just disabling it with (setq R> org-mobile-force-id-on-agenda-items nil) ? R> Is it being used somewhere in particular ? i think it might be used for syncing purposes, to uniquely identify items that need to be added, removed etc. Alexis.
Re: [O] [Org-Caldav] Trouble connecting to a caldav server other Google calendar
On 2015-03-14T01:11:35+1100, Charles-H. Schulz said: CS> Browsing this list's archives I did find, however, that a CS> few other people had problems outside Google Calendar. Perhaps this might be of use? https://github.com/dengste/org-caldav/issues/45#issuecomment-68527518 (i've not yet tried it, myself, though i hope to get to doing so in the near future ) There might also be a connection with this Emacs issue: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18290 Alexis.
Re: [O] Bleeding edge in elpa
On 2015-03-10T06:21:10+1100, T.F. Torrey said: TFT> The biggest obstacle I to this that I see is that developers tend TFT> to hate the package manager and love git. This developer appreciates both, and thus particularly appreciates MELPA as well. :-) Alexis.
Re: [O] Bug: `org-edit-special` doesn't respect dedicated windows
On 2015-03-08T07:34:36+1100, Nicolas Goaziou said: NG> Alexis writes: >> Thanks for bringing my attention to this variable! However, >> setting it to 'current-window seems to have no effect; rather >> than the Org buffer being replaced by an Emacs Lisp buffer, >> either a new window is created for the latter, or an existing >> (non-dedicated) window is taken over by the latter. Am i >> missing something / doing something else wrong? >> >> (Btw, i'm using version 20150223 of Org from the orgmode.org >> ELPA - sorry i didn't mention that in my previous message!) NG> I cannot reproduce the problem with `current-window' on NG> development branch. Okay, it turns out that the problem was the `display-buffer-function` variable being set elsewhere, which prevented `org-src-window-setup` from working correctly. Sorry for the hassle. Alexis.
[O] Setting `org-src-window-setup` has no effect? [was: Re: Bug: `org-edit-special` doesn't respect dedicated windows]
Ping? On 2015-03-01T20:31:33+1100, Alexis said: A> On 2015-03-01T20:20:06+1100, Nicolas Goaziou said: NG> Org uses `org-src-window-setup' to control the display, which NG> overrides dedicated windows. You may want to customize the A> former. A> Thanks for bringing my attention to this variable! However, A> setting it to 'current-window seems to have no effect; rather than A> the Org buffer being replaced by an Emacs Lisp buffer, either a A> new window is created for the latter, or an existing A> (non-dedicated) window is taken over by the latter. Am i missing A> something / doing something else wrong? A> (Btw, i'm using version 20150223 of Org from the orgmode.org ELPA A> - sorry i didn't mention that in my previous message!) A> Alexis.
Re: [O] refiling with helm
On 2015-03-06T02:13:41+1100, Leo Ufimtsev said: LU> Hello Xebar, LU> I had the same issue. I used the file-expand-wildcards function LU> to make a list of all my org-mode files. LU> The only thing is that I have to reload my .emacs when adding org LU> files for refile to work properly. You shouldn't need to do that; once you've added a new Org file, you can just move point to the end of the `(setq myvar/org-files ...` s-expression, and press C-x C-e (`eval-last-sexp`). That should cause the `setq` to be re-evaluated, such that the new file becomes part of the value of the `myvar/org-files` variable. Alexis.
Re: [O] Emacs unresponsive while executing Sh code block
On 2015-03-06T05:40:33+1100, Giacomo M said: GM> Dear all, GM> when I C-c C-c in: #+BEGIN_SRC sh gnome-terminal #+END_SRC GM> a gnome-terminal window appears, but Emacs hangs until I close GM> it. In the *Messages* I get: GM> executing Sh code block... Wrote GM> /tmp/babel-2307H-J/ob-input-2307i3c (here Emacs hangs... then GM> I close gnome-terminal) Error reading results: GM> (beginning-of-buffer) Code block produced no output. My guess is that Emacs is waiting for the final output from `gnome-terminal`, which doesn't get sent until you close `gnome-terminal`. Alexis.
Re: [O] org-calendar-holiday and local holidays
On 2015-03-03T08:58:20+1100, Jorge A. Alfaro-Murillo said: JAA> holidays.el appends holiday-local-holidays to calendar-holidays JAA> via a defcustom, so if you set holiday-local-holidays in your JAA> .emacs, restart emacs and the local holidays are not in JAA> calendar-holidays, it is because you are calling something that JAA> loads holidays.el before you set holiday-local-holidays. JAA> If you add the code above to your .emacs and later modify your JAA> configuration and remove or move the part that loads JAA> holidays.el, then either your code will fail (because JAA> calendar-holidays is not yet defined) or calendar-holidays will JAA> have your local holidays twice and they will show twice in your JAA> agenda. JAA> I think that you should look for whatever calls holidays.el and JAA> set holiday-local-holidays before that. i just tried moving my `(setq holiday-local-holidays ...)` to the very first line of my config setup, and lo, that does result in local holidays appearing in my Org agenda. However, my config setup is a 3000+ line Org Babel file, in which i group together things that are related in my mind, and the setup for the calendar is about a third of the way through this. Thus JAA> If not, then at least use eval-after-load so that JAA> calendar-holidays is already defined when the code is run, and JAA> add-to-list so that the entries do not get added twice if they are JAA> already there: JAA> #+BEGIN_SRC emacs-lisp (eval-after-load 'holidays '(dolist JAA> (holiday holiday-local-holidays) (add-to-list 'calendar-holidays JAA> holiday)) #+END_SRC works better in my context, and is more robust, longer-term, than my original suggestion to use (setq calendar-holidays (append calendar-holidays holiday-local-holidays)) So, thank you! Although i do note that my suggestion was nevertheless within the guidelines of the documentation for `calendar-holidays`: Note that these variables have no effect on `calendar-holidays' after it has been set (e.g. after the calendar is loaded). In that case, customize `calendar-holidays' directly. i feel the above documentation could be improved by adding that `eval-after-load` should probably by used in this context, e.g.: Note that these variables have no effect on `calendar-holidays' after it has been set (e.g. after the calendar is loaded). In that case, customize `calendar-holidays' directly, for example by using `eval-after-load': (eval-after-load 'holidays '(dolist (holiday holiday-local-holidays) (add-to-list 'calendar-holidays holiday))) i'll open a GNU Emacs issue to that effect. :-) Thanks again! Alexis.
Re: [O] org-calendar-holiday and local holidays
On 2015-03-03T02:26:37+1100, Jorge A. Alfaro-Murillo said: JAA> Alexis writes: >> When i scroll down to look at the current value of >> `calendar-holidays`, however, i see that neither the current >> value nor the original value makes any reference to the >> `holiday-local-holidays` variable. And indeed, when i examine >> my agenda for next Monday, which is a local holiday i've >> specified in `holiday-local-holidays`, i can't see that local >> holiday. To fix this, i use M-: to evaluate: >> >> (setq calendar-holidays (append calendar-holidays >> holiday-local-holidays)) >> >> after which the local holiday next Monday appears in my Org >> agenda. JAA> You do not need to add that, calendar-holidays appends JAA> holiday-local-holidays when holidays.el is loaded, just restart JAA> emacs. Not in my Emacs (manually compiled 24.4.1, the most recent official stable release). My `local-holidays` variable was set for years, such that only as part of trying to help the OP did i notice that it's been obsoleted; the documentation for it says: This variable is an alias for `holiday-local-holidays'. This variable is obsolete since 23.1; use `holiday-local-holidays' instead. So i changed my init to refer to `holiday-local-holidays` instead of `local-holidays`, and restarted Emacs, and the issue persisted: the value of `holiday-local-holidays` is /not/ included in `calendar-holidays` by default. The `(setq calendar-holidays ...` line i described above is necessary to work around this. JAA> It is also not a documentation bug, at least in my emacs JAA> (25.0.50.1) the documentation of calendar-holidays says clearly: JAA> "Note that these variables [`holiday-other-holidays', JAA> `holiday-general-holidays', `holiday-local-holidays', JAA> `holiday-christian-holidays', `holiday-hebrew-holidays', JAA> `holiday-islamic-holidays', `holiday-bahai-holidays', JAA> `holiday-oriental-holidays' and `holiday-solar-holidays'] have JAA> no effect on `calendar-holidays' after it has been set JAA> (e.g. after the calendar is loaded). In that case, customize JAA> `calendar-holidays' directly." In 24.4.1, the documentation is phrased differently; it says: Additional holidays are easy to add to the list, just put them in the list `holiday-other-holidays' in your init file. Similarly, by setting any of `holiday-general-holidays', `holiday-local-holidays', `holiday-christian-holidays', `holiday-hebrew-holidays', `holiday-islamic-holidays', `holiday-bahai-holidays', `holiday-oriental-holidays', or `holiday-solar-holidays' to nil in your init file, you can eliminate unwanted categories of holidays. The aforementioned variables control the holiday choices offered by the function `holiday-list' when it is called interactively. They also initialize the default value of `calendar-holidays', which is the default list of holidays used by the function `holiday-list' in the non-interactive case. Note that these variables have no effect on `calendar-holidays' after it has been set (e.g. after the calendar is loaded). In that case, customize `calendar-holidays' directly. The intention is that (in the US) `holiday-local-holidays' be set in site-init.el and `holiday-other-holidays' be set by the user. It's the fact that, despite the above docstring, and that, as i described above, setting the value of `holiday-local-holidays` has no direct effect on `calendar-holidays` /even after a restart of Emacs/, that led me to suggest there might be a code bug or a documentation bug (e.g. maybe some variable needed to be set to `t` to ensure the value of `holiday-local-holidays` gets included in `calendar-holidays`). Since things work for you, and the phrasing for the documentation for `calendar-holidays` has changed between the most recent stable release and the development version of Emacs you're using, my guess is that there is indeed a bug in 24.4.1 and earlier that has subsequently been fixed. Later today i'll try building from the first 24.5 pretest and the master branch, and examine what happens with `holiday-local-holidays` / `calendar-holidays` in both instances. Alexis.
Re: [O] org-calendar-holiday and local holidays
[Crossposted to the help-gnu-emacs list, for possible advice on whether or not this involves a bug in GNU Emacs.] On 2015-03-02T09:29:09+1100, Melleus said: M> I'm afraid to ask. But... Anyway. Does %%(org-calendar-holiday) M> know about holiday-local-holidays? I'm not programmer, sorry. I've M> set up those local holidays but cannot see them in my agenda. You can examine the definition of an ELisp function by: 1. typing C-h f whilst on a function; 2. typing RET to take you to the documentation for that function; 3. typing TAB then RET to take you to the function definition. Starting with point on `org-calendar-holiday`, we find that: - `org-calendar-holiday` calls (if available) `calendar-check-holidays` or (otherwise) `check-calendar-holidays`; - `calendar-check-holidays` calls `calendar-holiday-list`; - `calendar-holiday-list` makes use of the `calendar-holidays` variable. We can examine the documentation for the `calendar-holidays` variable by moving point onto and typing C-h v RET. On my setup (manually compiled Emacs 24.4.1 on Debian Wheezy(+updates) x86_64 together with Org 20150223), the documentation suggests that `calendar-holidays` makes use of the `holiday-local-holidays` variable; and the documentation for `holiday-local-holidays` merely refers us back to the documentation for `calendar-holidays`. When i scroll down to look at the current value of `calendar-holidays`, however, i see that neither the current value nor the original value makes any reference to the `holiday-local-holidays` variable. And indeed, when i examine my agenda for next Monday, which is a local holiday i've specified in `holiday-local-holidays`, i can't see that local holiday. To fix this, i use M-: to evaluate: (setq calendar-holidays (append calendar-holidays holiday-local-holidays)) after which the local holiday next Monday appears in my Org agenda. Given the documentation for the `calendar-holidays` variable, the fact that i need to manually add the value of the `holiday-local-holidays` variable to `calendar-holidays` seems to me like it might be a coding or documentation bug in Emacs ? Alexis.
Re: [O] Bug: `org-edit-special` doesn't respect dedicated windows
On 2015-03-01T20:20:06+1100, Nicolas Goaziou said: NG> Org uses `org-src-window-setup' to control the display, which NG> overrides dedicated windows. You may want to customize the former. Thanks for bringing my attention to this variable! However, setting it to 'current-window seems to have no effect; rather than the Org buffer being replaced by an Emacs Lisp buffer, either a new window is created for the latter, or an existing (non-dedicated) window is taken over by the latter. Am i missing something / doing something else wrong? (Btw, i'm using version 20150223 of Org from the orgmode.org ELPA - sorry i didn't mention that in my previous message!) Alexis.
Re: [O] Set a property or take action on state change to done
On 2015-02-19T10:31:05+1100, Subhan Michael Tindall said: SMT> I know the hooks are in there somewhere, but is there any SMT> relatively straightforward way to set a particular property, or SMT> run a function to do so, when a TODO changes status to a DONE SMT> state? Perhaps use a combination of `org-after-todo-state-change-hook` and the `org-state` variable? Alexis.
[O] Bug: `org-edit-special` doesn't respect dedicated windows
Context: Manually compiled Emacs 24.4.1 on Debian Wheezy(+updates) x86_64. ECM: 1. emacs -Q 2. Split frame into two windows via `C-x 3`. 3. Make one "*scratch*" buffer window dedicated via: (a) `M-:` (b) (set-window-dedicated-p (selected-window) t) 4. Select the other window. 5. Visit file `test.org`, containing: * Test #+begin_src emacs-lisp (message "Test.") #+end_src 6. Move point within source block, do `org-edit-special`. 7. The "*scratch*" buffer window will have its contents changed to contain an Org buffer. Alexis.
Re: [O] Citation syntax and ODT
On 2015-02-24T10:25:39+1100, Richard Lawrence said: RL> Vaidheeswaran C writes: >>> But whatever style is chosen, I would still think that the >>> fact that the citation is in-text rather than parenthetical, >>> and that it has a prefix and suffix, should be represented in >>> the output. >> >> 1. When you choose 'style' (Chicago etc.) wouldn't be one of >> in-text or parenthetical already chosen for you? Stated other >> way, is the choice between parenthetical or in-text >> document-wide or is it that one could intermix the two styles >> in the same document. RL> These could be intermixed in the same document. The RL> document-level style determines how each type ultimately looks, RL> but the choice of style is (mostly) independent of using RL> parenthetical vs. in-text citations. Fwiw, it seems to me that there might be some confusion here arising from two separate usages of the word 'style': (a) 'style' to mean "writing style", i.e. which words are used, how they're put together, etc. For example, "Plain English". (b) 'style' to mean "presentation style", i.e. how words, symbols, glyphs etc. are presented visually or (for vision-impaired people) aurally. For example, the sort of things specified by Cascading Style Sheets. Thus, the citation 'style' can be independent of the presentation style used for that citation style. For examle, one might have a citation style like: [Smith 2001] which in certain contexts is expected to have a presentation style of 'bolded'. So what i understand Vaidheeswaran to be asking is: Please don't code things such that presentation style is /necessarily/ carried along with citation style. Make it so that exporting a document faithfully reproduces the citation style in the target format, but don't /force/ the presentation style used in the source format for citation style to be the presentation style used in the destination format. Vaidheeswaran, is that correct? Alexis.
Re: [O] bug#19887: 24.4; Cannot kill buffer; Wrong type argument: overlayp, nil
On 2015-02-20T18:32:12+1100, Damian Nadales said: DN> That's weird. Which buffer are you killing, the DN> Org buffer, or the new buffer that is created when pressing C-c ' DN> inside the source block? Is the latter the one I cannot kill. DN> I've only installed packages through the emacs DN> package manager, and Org mode was not one of them. The command DN> ``org-version`` reports: DN> Org-mode version 8.2.10 (release_8.2.10 @ DN> /home/dnadales/opt/share/emacs/24.4/lisp/org/) Having thought about it a bit, i seem to remember that a while back, i had the same issue as the one you're currently experiencing. (Even though, as i noted above, i can't reproduce it my current setup, a manually compiled 24.4.1 on Debian Wheezy(+updates) x86_64.) Unfortunately, i can't remember what made the problem go away; the only two things that come to mind are: * installing and using Org from the orgmode.org ELPA, i.e. (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/";) t) or * removing existing Org-related byte-compiled files (i.e. *.elc files), so that they got regenerated. Alexis.
[O] bug#19887: 24.4; Cannot kill buffer; Wrong type argument: overlayp, nil
On 2015-02-18T06:25:57+1100, Glenn Morris said: GM> Damian Nadales wrote: >> - Run emacs -Q >> >> - Create an org-mode file (i.e. ``myorgfile.org``) >> >> - Insert the following text: >> >> o #+BEGIN_SRC C++ >> >> #+END_SRC >> >> - Edit the source block by placing the cursor inside the SRC >> block. >> >> - Start C++ mode (c++-mode) >> >> - Try to kill the buffer. GM> Please do GM> M-x toggle-debug-on-error GM> repeat the problem, and post the resulting backtrace. (I can't GM> reproduce it.) Running a manually compiled Emacs 24.4.1 on Debian Wheezy(+updates) x86_64, and following the above steps, i can't reproduce this either. From the above description, i assume by the "Start C++ mode" line, you're not moving the cursor inside the source block and then doing: C-c ' (i.e. `org-edit-special`) in order to open a c++-mode buffer for editing the block contents? Alexis.
Re: [O] orgmode-contacts "wrong type arguments"
On 2015-02-17T00:17:59+1100, Tory S. Anderson said: TSA> In my efforts to improve my elisp, can anyone tell me why the code TSA> doesn't work, and what might have changed to cause it to break? TSA> Error: completion-in-region: Wrong type argument: listp, #("NAME TSA> , NAME , NAME TSA> , NAME " 0 15 (fontified TSA> nil org-category "contacts") 44 65 (fontified nil org-category TSA> "contacts") 88 99 (fontified nil org-category "contacts") 127 TSA> 141 (fontified nil org-category "contacts")) It looks like something in `completion-in-region` wanted a plain old list of items, but instead got a propertized string. For further information, check out section "31.19.2, Changing Text Properties" of the Emacs Lisp Reference Manual - in particular, the entry for the `propertize` function. Alexis.
[O] org-carddav [was: Re: ANN: org-vcard. Export/import vCards. Backwards-compatible with org-contacts.el.]
On Wed 21 January 2015, Rasmus wrote: > Gour writes: > >> On Sub, 2014-08-02 at 11:12 +1000, Alexis wrote: >> >>> 2. Using org-vcard as a library, create org-carddav (which i hope to >>> start working on shortly) in order to be able to synchronise contacts >>> stored in Org with arbitrary CardDAV servers. > > Cool stuff! Sorry i've not replied to this sooner; i've had a lot happening, and haven't been able to follow this list. Unfortunately my work on org-carddav got stymied at an early stage by this Emacs issue: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18290 Iirc, this not only presented an obstacle to interaction with Google's CardDAV service, but also with a DAViCal server i set up on my LAN. If someone familiar with the source of url-http.el reviewed this, and amended its code along the lines i suggested in my bug report - even if only in the Emacs master branch - i would happily resume working on org-carddav. :-) Alexis.
Re: [O] "org-plus-contrib" yes, "org" no!
Sharon Kimble writes: > My emacs version is in the sig, and my org-version is "Org-mode > version 8.2.10 (8.2.10-23-g1ec416-elpaplus @ > /home/boudiccas/.emacs.d/elpa/org-plus-contrib-20141208/)" so we're > in agreement, but still it happens. I've checked everywhere in my > "init.org" and I don't have a spare "(require 'org)" floating > around, its not in there at all! > > I'm puzzled! My guess is that the version of Org that comes bundled with Emacs is being loaded. If so, you could try renaming the `org` directory in your Emacs installation's `lisp` directory to e.g. `.org` so that it's not found by default, then restart Emacs. Alexis.
Re: [O] Getting "org-mobile-sync" to work.
Sharon Kimble writes: > I'm trying to get mobileorg set up and working, which has worked. But I > also want to use "org-mobile-sync.el" from ELPA, the actual package > being "org-mobile-sync-20131118.1116". Looking at the source file it > says - > > --8<---cut here---start->8--- > ;;; Commentary: > > ;; Adds delayed `org-mobile-push' upon saving files that are part of > ;; `org-mobile-files-alist'. Watches the `org-mobile-capture-file' for > ;; changes with `file-notify.el' and then invokes `org-mobile-pull'. > > ;;; Requirements: > > ;; Emacs 24.3.50 with `file-notify-support' is required for it to work. > --8<---cut here---end--->8--- > > But I can't find "file-notify.el" on my system, nor by googling for it > either. Can somebody help me to get the file please? > > How do I know if "file-notify-support" is part of my Emacs please? If i understand correctly (and if i don't, please correct me!), 24.3.50 was the base for what has become the 24.4 pre-release / release candidate series. i'm running version 24.3.94.2, via the emacs-24 branch, which contains a package `filenotify.el` (note lack of dash!), and which i can successfully `require` Perhaps this is what `org-mobile-sync` is wanting? Alexis.
Re: [O] Enforcing newlines in plain text export
Richard Lawrence writes: > Does anyone know why the behavior of "\\" is presently restricted to > appearing at the end of the line in a paragraph? Does anyone need it > to be exported literally when it appears elsewhere? When exporting code listings in any programming language which uses '\' for escaping characters in strings, and subsequently uses '\\' to mean "literal backslash", literal export is required. For example, one might have an Org document with Emacs Lisp source: - ' * A | ** B | #+begin_src emacs-lisp | (setq my-regex "(.+)") | #+end_src `- Alexis.
Re: [O] Emacs server and org-protocol
Stefan Huchler writes: > What I have more a problem with is that it often hangs have to cancel > it at least every seond time. Sounds like something that might need to be reported as a bug? Alexis.
Re: [O] Emacs server and org-protocol
Eric S Fraga writes: > The issue is not the email front-end per se but the email servers (IMAP, > POP, whatever). A couple of years ago, I ended up having to use an > email server that would take many seconds, often minutes, to access, > even just to query to find out if there was any new email. Well, i run getmail+procmail to fetch and sort my mail, so if a server is running slowly, that doesn't affect Emacs. Emacs is only affected by e.g. mu indexing newly-arrived emails, which is fast enough that i don't notice it. Alexis.
Re: [O] Emacs server and org-protocol
Fabrice Popineau writes: > Yes seconds or even much more. > This is the reason I don't use Emacs to read my mail/news anymore :-/ If i may ask, which email front-end were you using? (Gnus, perhaps?) i used to use notmuch.el, and currently use mu4e, and basically don't have this issue Alexis.
Re: [O] crypt and sync
Hannes Schulz writes: > Shouldn't org-crypt disregard property drawers? The current org-contacts format stores contact details in property drawers; were it ignored by org-crypt, all those details would be lost in the encryption process. So ignoring of property drawers by org-crypt would probably best be controlled by an in-buffer setting or an org-crypt variable. Alexis.
[O] Typo in org guide
Hi all, the org guide "Release 8.2.7c" says in page 32, "12.1 Export options": The whole set of lines can be inserted into the buffer with C-c C-e t. It should say: The whole set of lines can be inserted into the buffer with C-c C-e #. Regards
Re: [O] Triggering clock in/out from org state change and progress logging
Hi list, after struggling a bit with edebug (too many things to learn) I have traced what the problem is. For the archives: State-change logging is deferred until the command finishes and is implemented by the function 'org-add-log-setup' adding the function 'org-add-log-note' to the hook 'post-command-hook'. The details of the note are stored in global variables 'org-log-note-xxx'. That implementation prevents recursive calls to 'org-todo' (that's what my code does in order the pause the active task) from logging both the paused and the started log messages. 'org-add-log-note' will be called only once since the hook won't accept duplicated entries. Anyway, the innermost call to 'org-add-log-setup' will overwrite the variables 'org-log-note-xxx' with the details of the note being paused. The outcome is that only the state change for the paused note is being logged. Now that I know what the problem is I only have to figure a workaround. Any clue? Regards
[O] Triggering clock in/out from org state change and progress logging
Hi list, as part of learning org I'm trying to configure it so that state changes trigger clocking in/out tasks. Why testing workflow is: #+TODO: TODO(t) STRT(s!) PAUS(p!) WAIT(w!) | DONE(d!) CANC(c!) What I try to accomplish: * entering STRT pauses the active task (if any) and clocks-in the current task. * entering PAUS or WAIT clocks-out the current task (if clocking the current task). * entering TODO probably should reset the current task but I don't care at that point. Changing state and clocking in/out works great but logging is weird: * Tasks ** STRT first task - State "STRT" from "TODO" [2014-08-26 dt 12:27] :20: CLOCK: [2014-08-26 dt 12:27] :END: ** TODO second task Now I change "second task" from TODO to STRT: * Tasks ** PAUS first task - State "PAUS" from "STRT" [2014-08-26 dt 12:28] - State "STRT" from "TODO" [2014-08-26 dt 12:27] :20: CLOCK: [2014-08-26 dt 12:27]--[2014-08-26 dt 12:28] => 0:01 :END: ** STRT second task :20: CLOCK: [2014-08-26 dt 12:28] :END: "first taks" gets paused and "second task" is started and clocking but no logging "State 'STRT' from 'TODO' ..." is added to "second task". Starting a task only logs in the other task. After 6 hours struggling with that (clocked with org :) ) I can't figure why that's happening. Any clue? Thanks in advance Here's the code: (defvar arv/org-todo-entering-state-clocking-actions '(("STRT" . start) ("PAUS" . stop) ("WAIT" . stop))) (defvar arv/org-todo-state-change-triggers-clocking-enabled t) (defvar arv/org-todo-paused-state "PAUS") (defun arv/org-todo--pause-other-task () (when (org-clock-is-active) (save-excursion (org-clock-goto) (org-clock-out) (let ((arv/org-todo-state-change-triggers-clocking-enabled nil)) ; avoid recursion (org-todo arv/org-todo-paused-state) (defun arv/org-todo--state-change (from to) (when (and arv/org-todo-state-change-triggers-clocking-enabled (not (string= from to))) (let ((action (cdr (assoc to arv/org-todo-entering-state-clocking-actions (unless (null action) (cond ((eq action 'start) (arv/org-todo--pause-other-task) (org-clock-in)) ((eq action 'stop) (let ((org-state "DONE") ; hackish, review (org-clock-out-when-done t)) (org-clock-out-if-current))) (t (user-error "Unknown action."))) (defun arv/org-todo--state-change-trigger (p) (let ((type (plist-get p :type)) (from (plist-get p :from)) (to (plist-get p :to))) (when (eq type 'todo-state-change) (arv/org-todo--state-change from to (add-hook 'org-trigger-hook 'arv/org-todo--state-change-trigger)
[O] Error in org guide
Hi all, the org guide "Release 8.2.7c" says in page 20, 8.4 Clocking work time: C-c C-x C-x Cancel the current ... It should say: C-c C-x C-q Regards
[O] Capture template expansion
Hi all, org newbie here, neither proficient with org nor english, please be patient. I'm having a hard time figuring how to gather property values with completion from a capture template. 8<-[ .emacs ] (setq org-capture-templates '(("t" "Todo" entry (file+headline "gtd.org" "Tasks") "* TODO %? :PROPERTIES: :TIPUS: %^{TIPUS}p :END: "))) 8<--- 8<-[ gtd.org ]--- #+PROPERTY: TIPUS_ALL foo bar * Tasks 8<--- gtd.org defines the allowed values for TIPUS but M-x org-capture does not provides completion when evaluating %^{TIPUS}p. After expanding the template, C-c C-x p does provide completion. That's intentional? a bug in my setup? TIA
Re: [O] Some thoughts on MobileOrg and its development ....
Carlos Sosa writes: > There's a difference feature wise between MobileOrgNG[1] and > MobileOrg-Android[2], which I believe should be merged into one project. > For instance, I don't know of MobileOrgNG having a SSH synchronizer > which many people make use of, including me, but with that said, > MobileOrgNG has a far greater and friendlier interface. > > I would suggest merging both projects for the sake of a better user > experience. Well, again, the fundamental problem here is that none of these three MobileOrg* projects are being actively worked on / maintained. The last commit to MobileOrgNG was on 13 February last year (and is "149 commits ahead, 863 commits behind" MobileOrg-Android). And despite not-insignificant discussion here on the Org mailing list about the MobileOrg* projects over the last few months, none of the lead devs for any of these projects has chimed in, which suggests work on the Org ecosystem is a very low priority for them right now. So it seems to me that the likelihood of getting the two projects to work on a merge process is similarly very low. It's certainly true that someone could create a third Android-specific version of MobileOrg that combines what they feel to be the best of both Android apps. However, assuming that new app took off, we would still have two different implementations on two different platforms where fixes and improvements to code and documentation on one platform wouldn't be immediately useful and/or appropriate for the other platform. (Not to mention there'd still not be even theoretical support for platforms other than iOS and Android.) >From a purely selfish point of view, as an Android user, a new Android app combining MobileOrg-Android and MobileOrgNG would probably meet my needs in the short term. In the medium to long term, however, i'm not yet convinced that it would make the Org-on-mobile-devices situation much more sustainably active than it is now. Alexis.
Re: [O] Some thoughts on MobileOrg and its development ....
David Wagle writes: > What's involved in 'rebooting' the project? My thought involves starting from scratch. Say we use Cordova (i can't speak to the pros and cons of Cordova vs. Kivy in terms of things like functionality provided, possible barriers to contribution etc.). Cordova takes care of a certain amount of the (semi-)boilerplate code needed for each platform; and of the remainder of the code, the core functionality would need to get reimplemented in HTML/CSS/JavaScript, with 'shims' being created between this code and the surrounding platform-specific code. Consequently, i think there would likely be very little use of most of the code in either current MobileOrg project. Alexis.
Re: [O] Some thoughts on MobileOrg and its development ....
Ashton Kemerling writes: > I can say for certain that we would have to figure out the handoff of > various credentials from the old maintainers (who I am assuming would > not like to continue being maintainers) for the respective app-stores > and Dropbox tokens. Not necessarily. One could, for example, create an entirely new project on GitHub called 'MobileOrgRebooted', and create entirely new apps in the respective stores using that name. (As it is, there's not a uniformly named app in any case - we have 'MobileOrg' for iOS, and 'MobileOrg-Android' for, well, Android.) And it certainly seems to me that it would be best to start the actual coding of the reboot /first/, and only worry about naming rights issues if and when it takes off. Doing otherwise is likely to bring into play another possible obstacle to getting actual implementation happening. Alexis.
[O] Some thoughts on MobileOrg and its development ....
Hi all, In light of recent discussions about 'MobileOrg' - which seemingly actually constitutes two distinct projects for two different platforms - together with the apparent relative lack of activity of both projects, despite demand for them, i can't help but wonder if the 'MobileOrg' endeavour needs a reboot. More specifically, it seems to me that rebuilding MobileOrg as a single project on top of Apache Cordova: https://cordova.apache.org/ might be a way forward, for several reasons: * It would help ensure that basically the same set of functionality is available across platforms, modulo specific limitations/issues with specific platforms. And when people add or modify core functionality, that functionality would more easily become available to people across platforms, rather than the functionality being initially implemented on platform X, and people on platform Y having to wait for it to be implemented in its entirety. * Overall, only one lot of end-user documentation would need to be maintained. * It would enable MobileOrg to be made available for mobile platforms other than Android and iOS, such as Windows Phone and Blackberry. * The number of people available to assist with development might well be greater, due to the core development environment involving HTML, CSS and JavaScript. Barriers to entry for both regular and occasional committers would be much lower. i'm aware that Cordova has various limitations, including-but-not-limited-to the lack of native 'feel' of Cordova-based applications. However, i feel that the above advantages, combined with the my notion that Emacs users are probably less concerned with a perfectly slick UI than with having access to functionality they need/want, probably outweighs such limitations. Unfortunately, due to other existing commitments, i wouldn't be able to take point on such a reboot. But i'd definitely be willing and able to help out! Particularly in the area of contact management and syncing, of course. :-) Thoughts/comments/criticisms? Alexis.
Re: [O] ANN: org-vcard. Export/import vCards. Backwards-compatible with org-contacts.el.
Charles Philip Chan writes: > Personally I find no MUA as usable and feature rich as Gnus. ;-) Heh! i didn't mind Gnus as a news reader, despite some initial challenges in getting it set up for that; but i gave up trying to get it working to my satisfaction as an MUA. It seems to be a very capable package overall, but i decided to stick with Mutt after a number of hours wrestling with Gnus (and its user manual, which i often found more confusing than enlightening) to get even the basic functionality i wanted. Later, and in contrast, i got basic functionality within about an hour of installing mu4e; and i now have little incentive to try Gnus again as an MUA. i'm more than willing to gradually and continually tweak a system to better meet my needs, but i'm not likely to be able to get to that point when even basic setup is such a struggle But to keep this discussion more on topic :-), this issue has informed how i've designed org-vcard - i want it to be as easy to use "out of the box" as possible, including making it as easy as possible for users to take advantage of its underlying flexibility[1]. This has taken more work than it might otherwise have done, but i think it's the right approach to take. [1] i (and many others, it seems) found GNOME 3 problematic in this regard. i don't use it myself, but have in the past supported users who did, and i wasn't thrilled to find GNOME 3 had taken away GUI access to various configuration options important to my users, rather than e.g. hiding them in an "Advanced" section with "HERE BE DRAGONS!!!" warnings when people try to access those options. > I am mainly talking about bbdb3 now, since I can't remember the > variable names in bbdb2. For phone numbers one can use free form style > by calling bbdb-insert-field with a prefix or change the variable > bbdb-phone-style > > [snip] > > As for postal codes, either turn the checking off by setting > bbdb-check-postcode to nil or change the variable > bbdb-legal-postcodes *nod* Still, i'm surprised there's no default support for Australian-style phone numbers and postcodes; are there really that few Australians making use of BBDB? In any case, if some people are happy with a BBDB-based solution to managing their contacts, that's fine with me! It's just that i want an Org-based system for myself. :-) Alexis.
Re: [O] MobileOrg documentation?
David Masterson writes: > Unfortunately, this looks like Android documentation where I have an > iPhone. i didn't even realise MobileOrg was available for iOS until this moment! It looks like there are two quite separate codebases (neither of which seems to be actively maintained) which complicates things further; i can easily imagine the provided functionality between both versions gradually drifting apart .... Alexis.
Re: [O] MobileOrg
Subhan Michael Tindall writes: > There’s also a few areas I’d like to do or see some enhancements on > the mobile end, for example handling display or edit of properties is > very limited *nod* i started to address this issue with this pull request: https://github.com/matburt/mobileorg-android/pull/434 which got merged But given the lack of commits and releases more generally, i've been reticent to work on this further. Alexis.
Re: [O] ANN: org-vcard. Export/import vCards. Backwards-compatible with org-contacts.el.
Eric Abrahamsen writes: > If by properties you mean arbitrary key-value data, BBDB does indeed > support that -- properties are known as "fields", and "xfields" are > user-designated fields. Labels and values can be arbitrarily > designated by the user, and with a bit of coding you can format them > in unusual ways, or have them "do things". Ah okay - thanks for clearing that up! Alexis.
[O] Creating a new contacts style for org-vcard [was: Re: ANN: org-vcard. ...]
e) fengshu-style-properties)) (match-string 1 (dolist (level (cdr heading-levels)) (if (or (looking-at (concat level " +")) (looking-at "^ +$") (looking-at "^$")) (setq done t) ;; END main changes (setq content (concat content (org-vcard-export-line (cdr (assoc (downcase fieldtype) fengshu-style-properties)) (org-get-heading t t) (setq end-vcard t (setq content (concat content (org-vcard-export-line "END:VCARD" "" t))) (setq output (concat output content))) (if search-result (re-search-backward "\\s *:FIELDTYPE:\\s *name"))) (org-vcard-write-to-destination output destination) (cond ((string= "buffer" destination) (message "Exported contacts data to *org-vcard-export* buffer.")) ((string= "file" destination) (message "Exported contacts data to file."))) (defun org-vcard-import-to-fengshu (source destination) ;; ) --- END --- Save the file. The org-vcard-import-to-fengshu function is deliberately left as a stub; i'm just wanting to give an overall idea of how one can create new org-vcard style functionality. Most of the definition of org-vcard-export-from-fengshu comes from org-vcard-export-from-tree - i've marked the section where the former differs substantially from the latter. (e) Run the command `org-vcard-reload-styles`. (f) Open your example content in a buffer. You'll need to change the FIELDTYPEs from "cells-folder" and "emails-folder" to "cell" and "email", respectively, due to how org-vcard's property-mapping system works. You'll also need to make sure that there's a newline after the fifth instance of "address@hidden"; my code doesn't address the case where there's no such final newline. (g) Either run the `org-vcard-export` command with source "buffer", destination "buffer", style "fengshu", language "en" and version "4.0"; or enable org-vcard-mode and select the corresponding items from the Org-vCard menu. (h) Hopefully, the result should now be available in the "*org-vcard-export*" buffer. :-) Please let me know if you have any questions! Alexis.
Re: [O] ANN: org-vcard. Export/import vCards. Backwards-compatible with org-contacts.el.
Gour writes: > what do you think about BBDB-v3? Many people like it, but I must admit > I haven't take closer look at it? i haven't tried using BBDB-v3, only BBDB-v2, several years ago. i found the latter, hm, 'clunky'. (Similar to how, until the advent of mu4e, i found no Emacs-based MUA with maildir support which i found as usable as Mutt.) And iirc, part of the problem might have been lack of (full) support for Australian phone numbers and/or postcodes, which at the time i really didn't want to wrestle with. In any case, org-contacts.el has nowwhetted my appetite for an Org-based contacts solution - given the slogan "Your life in plain text", contacts management certainly seems to me to fall within Org's remit. :-) > However, I wonder whether it's flexible enough to define one's own > properties of format of one's contact data and what about syncing? i've just had a quick scan through the BBDB-v3 source, and superficially, it looks like the properties are hard-coded. Regarding syncing, the BBDB page on SourceForge suggests that existing support for this might be rather limited - i only see mention of PalmPilot syncing. i would certainly be interested to know if anyone's created CardDAV support for BBDB - given that Google Contacts can be accessed via CardDAV, and given (what i imagine to be) the large number of people syncing their Android phone's contacts with Google Contacts, such support might well be in demand! > I wish you all the best hoping org-mode users will find decent solution > for handling contacts soon. Thank you! i'm hoping my ongoing work with org-vcard might eventually contribute towards this. :-) Alexis.
Re: [O] ANN: org-vcard. Export/import vCards. Backwards-compatible with org-contacts.el.
Feng Shu writes: > Is it possible support this style? In general, i'd prefer not to implement support /myself/ for everyone's preferred style; the idea is that people implement their own style, including: * the relevant mapping structure which maps Org properties to vCard properties/types; * the org-vcard-export-from-[new style] function; and * the org-vcard-import-to-[new style] function. And, preferably, new tests to accompany the new style. :-) Then, if a new style turns out to be particularly popular, i'll consider including it in org-vcard by default. Having said all that, as a proof-of-concept, i'll try to create a mapping and export function for the style you describe, for vCard 4.0, and will post the relevant code here. :-) Alexis.
Re: [O] ANN: org-vcard. Export/import vCards. Backwards-compatible with org-contacts.el.
Gour wrote: > Excuse me for dumb question, but is this package meant to be something > like org-contacts NG (something which we would really like to have)? i don't think that's a dumb question at all! My original motivation for developing org-vcard was to create part of a pipeline for synchronising contacts between Org and my smartphone. My intended plan for this pipeline is: 1. Create org-vcard to at least enable easy export and import of vCard files between my smartphone and Org. 2. Using org-vcard as a library, create org-carddav (which i hope to start working on shortly) in order to be able to synchronise contacts stored in Org with arbitrary CardDAV servers. 3. Using org-carddav, set up a way of synchronising my Org-based contacts with my smartphone-based contacts. i'm taking this approach because: (a) The MobileOrg release process currently appears to be stalled. A few pull requests i've submitted to the project, one of which was intended as the first step in making MobileOrg org-contacts.el-aware, have been accepted, but there has been no new release including these changes/fixes. (b) (i) i feel org-contacts.el, as it stands, is too inflexible. It's only aware of a relatively small number of properties, and extending this requires directly messing around in the org-contacts.el code. i feel that this has made it difficult to expand the list of properties available, as it basically requires everyone to agree on exactly what properties to add, and how. (b) (ii) Further to (b) (i), i feel people should be able to define their own properties, in their preferred language, without having to write code for this. (b) (iii) More generally, previous discussions on this topic on this list have convinced me that it's folly to expect everyone to agree on a single style for contacts in Org, and that what is needed is a system that can easily accommodate the development of new contact styles, potentially allowing an ecosystem/marketplace of styles to develop, with particularly popular styles being considered for inclusion by default in the system. Given all the above, yes, i would like to see org-vcard become the basis for an "Org contacts NG" system. (Which, to answer Feng Shu's question, would mean that the 'tree' style would be available by default in such a system.) Whether to actually take this approach, however, is something i'll let the community decide. :-) Alexis.
[O] ANN: org-vcard. Export/import vCards. Backwards-compatible with org-contacts.el.
Hi all, i'm pleased to announce the initial release of org-vcard, a package for Org-based export and import of vCards: * Backwards-compatible with org-contacts.el. org-vcard comes with a built-in contacts style called 'flat', which adheres to org-contacts' method of structuring contacts and contact information. It not only supports the properties specified in org-contacts.el, but many other properties as well. * Basic support for vCard 4.0, 3.0 and 2.1. org-vcard is working towards full compliance with the vCard 4.0 (RFC 6350), 3.0 (RFC 2426 and RFC 4770) and 2.1 specifications. * New contacts style: 'tree'. org-vcard introduces a new style for Org contacts, called 'tree'. * Highly customisable, via Emacs' customize interface. Modify existing contact styles; change the labels used to map contact details in org-mode to various vCard properties/types, or add new ones. Create completely new contact styles by plugging in your own code to handle export and import. Further details are available on the GitHub page: https://github.com/flexibeast/org-vcard The package can be installed from MELPA, or downloaded and installed manually. Hope people find it useful! Alexis.
[O] org-contacts to vCard
Hi all, i recently posted about connecting `org-contacts` with MobileOrg: (1) https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg00971.html Part of the resulting thread was about fleshing out an 'official' spec for the org-contacts format. Another part was about using DAV as part of a putative syncing process. This has led me to start working on an `org-carddav` package[*], à la the existing `org-caldav` package (regardless of whether a DAV-based approach ends up being used for syncing between `org-contacts` and MobileOrg); this in turn has led me to start working on an `org-vcard` package. Which brings me back to the issue of the org-contacts format. The most recent post on this topic that i can find is: (2) https://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg00140.html Taking into consideration people's comments on this matter in thread (1), i'd like to propose the following: -- Define a property `ORG_CONTACTS_STYLE`. The default value is 'flat', and represents the way org-contacts currently works: ,* People ,** Alexis ,:PROPERTIES: ,:CELL: 999 999 ,:PHONE: 00 ,:EMAIL: addres...@example.com ,:END: A second value `ORG_CONTACTS_STYLE` can have is 'tree': ,* People ,** Alexis ,:PROPERTIES: ,:KIND: individual ,:FIELDTYPE: name ,:END: ,*** Landline ,:PROPERTIES: ,:FIELDTYPE: landline ,:END: , 00 ,*** Mobile ,:PROPERTIES: ,:FIELDTYPE: mobile ,:END: , 999 999 ,*** Email 1 ,:PROPERTIES: ,:PREFERRED: ,:FIELDTYPE: email ,:END: , addres...@example.com ,*** Email 2 ,:PROPERTIES: ,:FIELDTYPE: email ,:END: , addres...@example.com For each value of ORG_CONTACTS_STYLE, define a default mapping: ,#+ORG_CONTACTS_STYLE: flat ,+--+-+ ,| PROPERTIES field | vCard field | ,+--+-+ ,| [ heading with 'KIND' property ] | FN | ,| CELL | TEL;CELL| ,| MOBILE | TEL;CELL| ,| LANDLINE | TEL;HOME| ,| PHONE| TEL | ,| EMAIL| EMAIL | ,| ... | ... | ,#+ORG_CONTACTS_STYLE: tree ,+--+-+ ,| FIELDTYPE field | vCard field | ,+--+-+ ,| name | FN | ,| cell | TEL;CELL| ,| mobile | TEL;CELL| ,| landline | TEL;HOME| ,| phone| TEL | ,| email| EMAIL | ,| ... | ... | Users would be able to change and extend the above mappings as works best for them. And of course, there's potential to define entirely new mappings. `org-vcard` would then be able to export org-contacts to vCard depending on the value of ORG_CONTACTS_STYLE. And since the default value of this property would be 'flat', backwards-compatibility would be preserved. -- The reason i'm proposing a new contacts style of 'tree' is to create one that more takes advantage of Org being an outliner. Rather than having a huge flat property list with no ability to show/hide relevant groups, it seems to me to make sense to be able to do something like: ,* People ,** Alexis ,*** Work , Phone , Email ,*** Home , Phone , Email ,* Organisations ,** Acme ,*** Coyote Services , Anvils ,* Phone ,* Email , Rope ,*** Snake Oils and be able to show/hide the relevant sections as required. Further, i believe the mappings approach avoids having to make fixed and final decisions which everyone has to agree on - different people will have different needs in different use-cases. And inserting new contact data could be facilitated via an interactive function which does a `completing-read` using the values of the first column in the currently-active mapping table, then creating the relevant PROPERTIES drawer with the appropriate value(s). Finally: yes, i am personally willing to do all the coding to support this proposal. :-) What do people think? Alexis. -- [*] Though i'm already encountering the same possible issue with the `url-dav` package that i've found when trying to use `org-caldav` with a DAViCal server: https://github.com/dengste/org-caldav/issues/45 Is anyone successfully using `org-caldav` (or `url-dav`) with a DAViCal server?
Re: [O] (require 'org-publish) causes downgrade in org-version
psycho_punch writes: > I've defined my initialization script in ~/.emacs.d/init.el; I'm not sure > if it matters. So since 'ox-publish doesn't get loaded until after > initialization, I defined: > > (add-hook 'after-init-hook (lambda() (load-file > "/path/to/org-publish-project.el"))) > > I'm wondering when do the packages installed via package-install get > loaded... They get loaded when (package-initialize) is called in one's initialisation file(s). Alexis.
Re: [O] babel and computing a number of months
Alan Schmitt writes: > I need to work with dates for some code/scripts I'm writing in a > document making heavy usage of source blocks and babel evaluation. The > good news is that I have access to many programming languages, so the > bad news is I don't know which one to choose. The problem I want to > solve is the following: I want to compute the number of months between > march 1st, 2014, and the beginning of the current month (so right now > it's 3, but on may 31st it was 2). Is there an easy way to do it in a > babel supported language? How about Perl with either DateTime::Moonpig: https://metacpan.org/pod/DateTime::Moonpig or Time::Piece: https://metacpan.org/pod/Time::Piece Alexis.
Re: [O] Hiding checked items in a checkbox list (FR?)
Sergio Pokrovskij writes: > Yes (actually I have about 80 items in my Springpad list; if the full > list consists of mere 10 items, it fits the screen of my smartphone, > and there is no real need to hide the checked items). *nod* Fair enough; i was just making up some numbers in order to be concrete. > Al> 2. Initially mark all of them as 'unneeded' by checking all > Al> items with a single command. > > Possibly so. Actually all the performed items get checked as I buy > them, and those which for some reason I could not buy should preserve > their open (unchecked, unimplemented) status. So normally I need not > perform this step (provided that what I have checked at the store gets > synchronized back to the Big Brother); but in some infrequent cases it > is nice to have such a command (though I guess it can be easily done > with an M-% in emacs). *nod* > Al> 3. Uncheck (say) 3 items that are 'needed'. > Al> 4. Run org-mobile-push. > > Do I have to do it manually every time (more than once)? Aren't such > files synchronized automatically? It depends on how you've set up MobileOrg. i sync via ssh, and thus sync manually via org-mobile-push and org-mobile-pull from within Emacs. If you use e.g. Dropbox, things might be different - i can't comment on that. > Al> 5. MobileOrg displays only the 3 'needed' items; the other 7 > Al> checked (i.e. unneeded) items are hidden. > > Yes (in fact, normally there are more of them, a dozen at least). See above - at this stage, for the purposes of understanding the core of the flow you're wanting, the exact numbers don't matter so much. But in terms of potential UI access to such flows, i'll certainly keep in mind that lists might include many dozens of items. > Al> 6. As items are purchased and checked off the list, they can > Al>either: > Al>(a) remain visible; or > Al>(b) become hidden upon being checked. > > Al> Is that correct? > > Yes. Normally (b) is sufficient for me, because normally I have just > a screenful of interesting items. But I can imagine that people who > need longer shopping lists (more that one screen of them) would prefer > to have a MobileOrg command to hide the newly-checked items as well. *nod* Fair enough. i'll check the MobileOrg issues page: https://github.com/matburt/mobileorg-android/issues for any equivalent and/or similar proposals, and submit a new issue if there aren't any. Either way, i'll see what i can do about adding this functionality. :-) Note, though, that i'm not the lead developer, so i don't have any control over if/when any such functionality will be (a) included in the master branch and (b) included in a release. Alexis.
Re: [O] Hiding checked items in a checkbox list (FR?)
Sergio Pokrovskij writes: > The next problem is that MobileOrg should respect the preliminary > hiding done before the visit to the shop. I do not request that it > hide the checked (= bought) items as well (actually I'd prefer it to > leave them checked and visible; but also its hiding-on-the-fly is > quite acceptable). Sorry, but i'm not sure i follow. Do you mean something like the following example workflow? 1. Have list of (say) 10 grocery items in org-mode. 2. Initially mark all of them as 'unneeded' by checking all items with a single command. 3. Uncheck (say) 3 items that are 'needed'. 4. Run org-mobile-push. 5. MobileOrg displays only the 3 'needed' items; the other 7 checked (i.e. unneeded) items are hidden. 6. As items are purchased and checked off the list, they can either: (a) remain visible; or (b) become hidden upon being checked. Is that correct? Alexis.
Re: [O] org-contacts development
Daimrod writes: > Sure, but then how would we define the map? with a fixed set of rules? > with a user customizable map (e.g. '(("MOBILE" -> "TELL;CELL") > ("EMAIL_WORK" -> "EMAIL;TYPE=work")))? More the latter. My initial (again, brainstorming!) thinking has an user-modifiable data structure along the lines of the following: +---+++ | elisp var |org property| ~ vCard equivalent | +---+++ | org-contacts-email-work-property |EMAIL_WORK |EMAIL;TYPE=work | | org-contacts-mobile-work-property |MOBILE_WORK |TEL;CELL;TYPE=work | +---+++ English-language properties for the org property column could be provided by default, but users who wanted to use non-English property names could do so by modifying the relevant entries. > I'm not saying that it's impossible nor that we shouldn't do it but that > we need to think about it first. :) Oh 100% agreed! That's why i've started this discussion here, so as to get input, feedback, and hopefully at least rough consensus, on how to approach all this. :-) > Well, if people are willing to help, I'll see if I can come up with a > proposal. :-) Sounds good! Alexis.
Re: [O] org-contacts development
Daimrod writes: > So, as you said, we would need to define and document a specification > for org-contacts. And we need to be clear from the beginning about > what it can do and what it can not do. For example, it is unlikely > that org-contacts will be a 1:1 mapping with the vCard format in its > current form because vCard properties can have values. > > e.g. > PROP1;PROP2=VAL:FOO BAR > ^ Agreed. But it seem to me we could at least map e.g. "TEL;CELL:" (which is how my Android phone vCard-exports a mobile number) to e.g. ":MOBILE:" or ":PHONE_CELL:". And we could map things like e.g. "EMAIL;TYPE=work:" to e.g. ":EMAIL_WORK:". This is just brainstorming, however. :-) > An approach would be to keep using properties whenever it's possible > to keep the format simple when possible and use subtree instead of > properties when necessary. > > e.g. > #+BEGIN_SRC org > ,* Contact Name > ,** PHONE > :PROPERTIES: > :TYPE: WORK > :END: > - num1 > - num2 > #+END_SRC > > But then we would need a special property to indicate that a subtree > is a contact and ignore subtree without this property (just like it > does with the EMAIL property ATM). > > #+BEGIN_SRC org > ,* Contact Name > :PROPERTIES: > :TYPE: org-contacts > :END: > > ,** PHONE > :PROPERTIES: > :TYPE: WORK > :END: > - num1 > - num2 > #+END_SRC > > And of course it would be nice if we could keep as much compatibility > with the current format :) Well, to me this looks broadly similar to what Esben has proposed: https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html Although i like the idea of such a format in principle, my concern (as i noted in my reply to Esben) is that this might require a substantial modification of org-contacts.el, both to accommodate this format and to ensure backwards-compatibility. If this is indeed the case, and someone else is willing to commit to being the lead on undertaking that work, then i'll certainly support that work and write relevant MobileOrg code to work with both the new and old formats. Otherwise, from my perspective of wanting to simply add some more fields and be able to transfer contact details between MobileOrg and my phone's Contacts system, it's more than i'm willing to take on at this point. Alexis.
Re: [O] org-contacts development
Rasmus writes: > Check here: > > https://f-droid.org/repository/browse/?fdfilter=carddav&fdpage=1&page_id=0 > > DAVdroid works very well. Oh okay, i didn't realise DAVdroid was FOSS. DAVdroid makes use of the ez-vcard library, which is BSD-licensed, and certainly seems like it might be useful. However, i'm not sure to what extent the sync-specific functionality of DAVdroid can be separated from the rest of the app; superficially, it seems like it's fairly tightly integrated. But if nothing else, it does show how it can be done! Thank you. :-) Alexis.
Re: [O] org-contacts development
Alexander Baier writes: > For what it's worth, I would love to help out in any way I can. I use > org-contacts myself and know elisp well enough to also do some > implementing. But I wouldn't mind writing some documentation, either. Thank you! At this point i'm studying RFC 6350 (vCard 4) and the org-contacts.el source, trying to work out how to bring more of the former to the latter with a minimal amount of work and fuss. :-) > I, however, don't know much about Android programming or the syncing > aspect of this task. *nod* i'm not sure how much work is involved in the syncing aspect, and so my first priority is to at least be able to export individual contacts from MobileOrg to an individual vCard file that can be imported into the Android Contacts system, and vice versa. There might already be a FOSS CardDAV library for Android out there that could be used for syncing, but i've not researched that yet. Alexis.
Re: [O] org-contacts development
Bastien writes: > Alexis writes: > >> *nod* Good point i'd be happy to assign copyright to the FSF, >> myself, but i know that doing so is an issue for many people. > > Here you go! > > http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt > > :) Heh, thank you! i'll definitely make sure to complete that form and send it in. :-) Alexis.
Re: [O] Extending org-contacts with properties: naming properties
Hi Esben, The way that org-contacts currently works is that contact details are grouped together in the same PROPERTIES drawer, e.g. * Alexis :PROPERTIES: :EMAIL: ale...@example.com :PHONE: - :END: and that's what i've assumed in my MobileOrg code for parsing org-contacts data. i imagine that moving away from such a data layout would require substantial changes to the org-contacts.el code, which i have no intention of doing - particularly given the work that would be needed to ensure backwards-compatibility with people's existing data. For reference, at the moment, in my own org-contacts file, i've set up grouping via a headings hierarchy like: * Lists ** Org-mode :PROPERTIES: :EMAIL: emacs-orgmode@gnu.org :END: * People ** Mum and Dad :PROPERTIES: :PHONE: - :END: * Organisations ** Free Software Foundation :PROPERTIES: :EMAIL: i...@fsf.org :END: *** A. Person :PROPERTIES: :EMAIL: a.per...@fsf.org :END: Alexis.
Re: [O] org-contact Documentation
On Fri, 23 May 2014 15:17:04 +0200, Esben Stien wrote: > Sync'ing with ldap would also be great, but I guess that's a bit > premature. Well, if org-contacts becomes based in vCard, as i'd like, i guess it might be possible to use LDAP vCard services Alexis.
Re: [O] org-contacts development
Xebar Saram writes: > This sounds awesome, i would love syncing org contacts with my android > phone :-) It's good to know i'm not the only one wanting this functionality - gives me more incentive to actually implement it! Alexis.
Re: [O] org-contacts development
Alexander Baier writes: > About the spec, might it make sense to use a standard already in > existence as a starting point or even a major inspiration? Something > like vCard for example? Yeah, i like the idea of building on top of vCard, given how widely it's used and supported, and that it doesn't seem to be a horrible format Those who feel otherwise are going to need to speak up soon or forever hold their peace. :-) Alexis.
Re: [O] org-contacts development
Bastien writes: > Improving org-contacts.el and making it part of Org core are two > separate issues -- not everything that is part of Org core gets a > lot of attention, and some contributed packages do. Oh okay, fair enough! > I'd say: go ahead with whatever conventions you want to enforce > and the community will step up -- or just applaud :) Heh, okay. :-) > PS: Actually, being part of Org core sometimes slow down things, > because substantial contributions then need to come from people > who assign their copyright to the Free Software Foundation. *nod* Good point i'd be happy to assign copyright to the FSF, myself, but i know that doing so is an issue for many people. Alexis.
Re: [O] org-contacts development
Rasmus writes: > You could also put yourself a slightly different challenge: map > between the org-contacts-format and an carddav server that you > establish as a backend on your phone. E.g. google contacts is a > carddav server, I think. > > I use DAVdroid for syncing my calendar and my contacts with my > OwnCloud and it very, very well! I sync my agenda with my OwnCloud > using org-caldav, which works great except when you have multiple time > stamps per heading. For contacts I tried Asynk to sync my bbdb > contacts with OwnCloud, but I was using too many fields unknown to it, > and my contacts got messed up. > > Mayhaps you already thought of this approach. I think it is more > future-proof. i wasn't aware of CardDAV - thanks for pointing it out! My thoughts of how to deal with org-contacts data have indeed been revolving around vCard though, so this approach looks interesting indeed. :-) Alexis.
[O] org-contacts development
Hi all, i use org-contacts as my primary system for contact management. Consequently, i'd love to be able to make use of my org-contacts data on my Android phone. To that end, i recently wrote some code for MobileOrg-Android which adds basic PROPERTIES drawer support: https://github.com/matburt/mobileorg-android/pull/434 What i'd now like to do is to add support for transferring data back and forth between my org-contacts file and the Contacts store on my phone. The challenge is the mapping between these two systems. For example, org-contacts provides only one EMAIL property, which can contain multiple addresses separated by spaces, whereas Android's ContactsContract.CommonDataKinds.Email class is able to distinguish between different addresses for different purposes: http://developer.android.com/reference/android/provider/ContactsContract.CommonDataKinds.Email.html What would be useful would be an 'official', fleshed-out spec for org-contacts data, which handles a greater range of contact-related info. At the moment, for example, my org-contacts file makes use of the properties: #+PROPERTY: LANDLINE #+PROPERTY: MOBILE #+PROPERTY: POST #+PROPERTY: RESIDENCE A search of this list's archives for references to 'org-contacts': https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=org-contacts&submit=Search!&idxname=emacs-orgmode&max=20&result=normal&sort=date%3Alate suggests that org-contacts is something people are using heavily enough that they're writing code, ad-hoc, to provide functionality they require, e.g. http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00869.html i'm wondering if it might now be appropriate for org-contacts to become part of org-mode proper, rather than simply a contrib, to reduce unnecessary duplication of efforts. i suspect that, at the moment, a number of people interested in making use of org-contacts might be reluctant to do so (or do so more heavily) because it's not an 'official' part of org-mode. Yet contacts management seems to me to be functionality well within org-mode's remit. Fleshing out an extended spec for org-contacts data could be part of the process of making org-contacts a first-class citizen of org-mode, and provide a more solid foundation on which people can build (and share) the org-contacts functionality they're after. And in my own particular case, it would greatly facilitate my work in org-contacts / Android Contacts integration. :-) What do people think? Alexis.
Re: [O] Possible bug? Links using 'file+Emacs:' don't work.
Nicolas Goaziou writes: > Alexis writes: > >> However, 'file+emacs:' links still exhibit the incorrect behaviour i >> described in my original email, and which you experienced also. So it >> looks like there is indeed a bug here - or, the 'file+emacs:' example >> should be removed from section 4.3 of the Org manual. > > This should be fixed in master branch. > > Thank you for reporting it. Hi Nicolas, Have just tested your fix - works for me. :-) Thanks for fixing this so quickly! Alexis.
[O] Possible bug? Links using 'file+Emacs:' don't work. (Was: Re: Unable to get file link search to work)
Christian Moe writes: > Just to say, I reproduce it, so I think it's a bug. Note, the below > only happens for me when using "file+emacs:" to force opening in > emacs. The links work with regular "file:" links, or just starting the > link with "./" Since my .org files open with emacs anyway, I normally > wouldn't add "+emacs". But the manual suggests I could. Hi Christian, Thanks for taking the time to look into this! i was using 'file+emacs:' because when i just used 'file:', the .org file would be opened using 'less', not Emacs. As a result of your email, i checked out the documentation for org-open-at-point; it said that providing a prefix argument would force opening in Emacs. So i removed the '+emacs' from my example link, and then tried opening it via C-u C-c C-o - and it worked! i checked the value of org-file-apps, to see why org-open-at-point was using 'less', rather than Emacs, to open .org files. It turns out there was a typo in how i was setting the value of org-file-apps, causing it to have a nonsense value - and i guess this caused org-mode to fall back to using 'less' as a default. Setting the value of org-file-apps to a correct value - including ("org" . emacs) as part of it - resulted in 'file:' links being opened in Emacs, rather than with 'less'. However, 'file+emacs:' links still exhibit the incorrect behaviour i described in my original email, and which you experienced also. So it looks like there is indeed a bug here - or, the 'file+emacs:' example should be removed from section 4.3 of the Org manual. Thanks again! Alexis.
Re: [O] Unable to get file link search to work
Bump. Any suggestions as to whether the below is me doing something wrong (more likely) or a bug (less likely)? Thanks! Alexis writes: > Hi all, > > i'm running org-mode 8.2.5h in Emacs 24.3. > > Say i have file a.org: > > * Main > ** Group > *** Firstname Lastname > > My reading of > > http://orgmode.org/manual/External-links.html#External-links > > and > > http://orgmode.org/manual/Search-options.html#Search-options > > is that i should be able to, in b.org - which resides in the same > directory as a.org - have something like: > > [[file+emacs:a.org::*Firstname]] > > such that when i move point over that link, and enter C-c C-o > (i.e. org-open-at-point), i will be taken to a buffer containing a.org, > with point on the 'Firstname Lastname' heading. Instead, what happens is > that a new buffer is created, attached to a new file called, literally, > 'a.org::*Firstname'. > > Similarly, if in b.org i have something like: > > [[file+emacs:a.org::2]] > > i am not taken to line 2 of a.org, but instead to a new buffer attached > to a new file literally called 'a.org::2'. > > i have observed this behaviour with > org-link-search-must-match-exact-headline set to either 'query-to-create > or to nil. > > What am i doing wrong? > > > Alexis.
[O] Unable to get file link search to work
Hi all, i'm running org-mode 8.2.5h in Emacs 24.3. Say i have file a.org: * Main ** Group *** Firstname Lastname My reading of http://orgmode.org/manual/External-links.html#External-links and http://orgmode.org/manual/Search-options.html#Search-options is that i should be able to, in b.org - which resides in the same directory as a.org - have something like: [[file+emacs:a.org::*Firstname]] such that when i move point over that link, and enter C-c C-o (i.e. org-open-at-point), i will be taken to a buffer containing a.org, with point on the 'Firstname Lastname' heading. Instead, what happens is that a new buffer is created, attached to a new file called, literally, 'a.org::*Firstname'. Similarly, if in b.org i have something like: [[file+emacs:a.org::2]] i am not taken to line 2 of a.org, but instead to a new buffer attached to a new file literally called 'a.org::2'. i have observed this behaviour with org-link-search-must-match-exact-headline set to either 'query-to-create or to nil. What am i doing wrong? Alexis.
[O] Bad formatting in documentation
Hi, I just stumbled upon a bad formatting on the website ( http://orgmode.org/worg/org-faq.html ). In "Why doesn't C-c a call the agenda? Why don't some org keybindings work?", we can see #+BEGIN_SRC emacs-lisp ;; The following lines are always needed. Choose your own keys. (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode)) (global-set-key "\C-cl" 'org-store-link) (global-set-key "\C-ca" 'org-agenda) (global-set-key "\C-cb" 'org-iswitchb) #+END_SRC emacs-lisp -- Alexis Praga ___ Ph.D Student CERFACS alexis.pr...@gmail.com
[O] the "right way" to build OMPL export and import
Hi, I would love to be able to export org documents to opal, so that I can read them with the various commercial outlining apps on platforms without emacs -- e.g, iOS. The ideal thing would be if I could import OPML as well. Is anyone working on this already? If not, does anyone have any pointers on the "right way" to go about this, so that the work would go smoothly and be acceptable upstream? This seems like a good time to ask given the recent consolidation of export facilities around the internal parser org-element.el. I presume any OPML exporter should be based on that, correct? Is any one of the existing exporters a particularly clean example to work from? For OPML import, is org-element-interpret-data the best starting point? Alexis