Re: [O] was this intentional with the default header ":results value"
Or, fiddling a bit more. #+name: luo #+BEGIN_SRC R :results output raw library(ascii) df <- data.frame(c1="123456789123456789000",c2=2) df$c1 <- as.vector(df$c1) print(ascii(df,digits=c(0,0),include.rownames=F),type="org") #+END_SRC #+RESULTS: luo |c1 | c2 | |---+| | 123456789123456789000 | 2 | t...@tsdye.com (Thomas S. Dye) writes: > Hi Eric, > > I don't know any way to do this in Org-mode. Here is a workaround in R > that might do what you want. > > #+name: luo > #+BEGIN_SRC R :results output org > library(ascii) > df <- data.frame(c1="123456789123456789000",c2=2) > df$c1 <- as.vector(df$c1) > print(ascii(df),type="org") > #+END_SRC > > #+RESULTS: luo > #+BEGIN_ORG > | | c1| c2 | > |---+---+--| > | 1 | 123456789123456789000 | 2.00 | > #+END_ORG > > All the best, > Tom > > Eric Luo writes: > >> t...@tsdye.com (Thomas S. Dye) writes: >> >> Thanks, it's clear to me with the difference between "value" and >> "output" now. >> >> whether there is a way to tell emacs-lisp that "123456789123456789" is a >> string rather than a number. >> >> emacs-lisp handles the output as expected if the c1 has any character >> other than numbers as the following. >> , >> | #+BEGIN_SRC R >> | df <- data.frame(c1="c123456789123456789",c2=2) >> | df$c1 <- as.vector(df$c1) >> | df >> | #+END_SRC >> | >> | #+RESULTS: >> | | c123456789123456789 | 2 | >> | >> ` >> >>> Aloha Eric, >>> >>> Eric Luo writes: >>> Hi, Why in the following code block, c1 was printed as scientific notation rather then characters. , | | #+BEGIN_SRC R :results value | df <- data.frame(c1="123456789123456789",c2=2) | #+END_SRC | | #+RESULTS: | | 1.2345678912345678e+17 | 2 | ` >>> >>> With :results value the results are passed from the source language into >>> emacs-lisp and then displayed in the buffer. So, the representation of >>> things like very large numbers depends on how that was done in >>> emacs-lisp, independent of the source language conventions. In this >>> case, I suspect the number was written with a formatting string and ‘%g’ >>> which uses scientific notation if that is a shorter representation. >>> >>> But if the header :results output, the result was expected. , | | #+BEGIN_SRC R :results output | df <- data.frame(c1="123456789123456789",c2=2) | df | #+END_SRC | | #+RESULTS: | : c1 c2 | : 1 123456789123456789 2 ` >>> >>> With :results output the results aren't translated into emacs-lisp. >>> Instead, the output from the source language is collected and displayed >>> in the buffer. Thus, the output conventions of the source language are >>> respected. >>> >>> hth, >> >> >> -- Thomas S. Dye http://www.tsdye.com
Re: [O] was this intentional with the default header ":results value"
Hi Eric, I don't know any way to do this in Org-mode. Here is a workaround in R that might do what you want. #+name: luo #+BEGIN_SRC R :results output org library(ascii) df <- data.frame(c1="123456789123456789000",c2=2) df$c1 <- as.vector(df$c1) print(ascii(df),type="org") #+END_SRC #+RESULTS: luo #+BEGIN_ORG | | c1| c2 | |---+---+--| | 1 | 123456789123456789000 | 2.00 | #+END_ORG All the best, Tom Eric Luo writes: > t...@tsdye.com (Thomas S. Dye) writes: > > Thanks, it's clear to me with the difference between "value" and > "output" now. > > whether there is a way to tell emacs-lisp that "123456789123456789" is a > string rather than a number. > > emacs-lisp handles the output as expected if the c1 has any character > other than numbers as the following. > , > | #+BEGIN_SRC R > | df <- data.frame(c1="c123456789123456789",c2=2) > | df$c1 <- as.vector(df$c1) > | df > | #+END_SRC > | > | #+RESULTS: > | | c123456789123456789 | 2 | > | > ` > >> Aloha Eric, >> >> Eric Luo writes: >> >>> Hi, >>> Why in the following code block, c1 was printed as scientific notation >>> rather then characters. >>> , >>> | >>> | #+BEGIN_SRC R :results value >>> | df <- data.frame(c1="123456789123456789",c2=2) >>> | #+END_SRC >>> | >>> | #+RESULTS: >>> | | 1.2345678912345678e+17 | 2 | >>> ` >> >> With :results value the results are passed from the source language into >> emacs-lisp and then displayed in the buffer. So, the representation of >> things like very large numbers depends on how that was done in >> emacs-lisp, independent of the source language conventions. In this >> case, I suspect the number was written with a formatting string and ‘%g’ >> which uses scientific notation if that is a shorter representation. >> >> >>> But if the header :results output, the result was expected. >>> , >>> | >>> | #+BEGIN_SRC R :results output >>> | df <- data.frame(c1="123456789123456789",c2=2) >>> | df >>> | #+END_SRC >>> | >>> | #+RESULTS: >>> | : c1 c2 >>> | : 1 123456789123456789 2 >>> ` >>> >> >> With :results output the results aren't translated into emacs-lisp. >> Instead, the output from the source language is collected and displayed >> in the buffer. Thus, the output conventions of the source language are >> respected. >> >> hth, > > > -- Thomas S. Dye http://www.tsdye.com
Re: [O] was this intentional with the default header ":results value"
t...@tsdye.com (Thomas S. Dye) writes: Thanks, it's clear to me with the difference between "value" and "output" now. whether there is a way to tell emacs-lisp that "123456789123456789" is a string rather than a number. emacs-lisp handles the output as expected if the c1 has any character other than numbers as the following. , | #+BEGIN_SRC R | df <- data.frame(c1="c123456789123456789",c2=2) | df$c1 <- as.vector(df$c1) | df | #+END_SRC | | #+RESULTS: | | c123456789123456789 | 2 | | ` > Aloha Eric, > > Eric Luo writes: > >> Hi, >> Why in the following code block, c1 was printed as scientific notation >> rather then characters. >> , >> | >> | #+BEGIN_SRC R :results value >> | df <- data.frame(c1="123456789123456789",c2=2) >> | #+END_SRC >> | >> | #+RESULTS: >> | | 1.2345678912345678e+17 | 2 | >> ` > > With :results value the results are passed from the source language into > emacs-lisp and then displayed in the buffer. So, the representation of > things like very large numbers depends on how that was done in > emacs-lisp, independent of the source language conventions. In this > case, I suspect the number was written with a formatting string and ‘%g’ > which uses scientific notation if that is a shorter representation. > > >> But if the header :results output, the result was expected. >> , >> | >> | #+BEGIN_SRC R :results output >> | df <- data.frame(c1="123456789123456789",c2=2) >> | df >> | #+END_SRC >> | >> | #+RESULTS: >> | : c1 c2 >> | : 1 123456789123456789 2 >> ` >> > > With :results output the results aren't translated into emacs-lisp. > Instead, the output from the source language is collected and displayed > in the buffer. Thus, the output conventions of the source language are > respected. > > hth,
[O] preserve trailing zeros in table output from shell script
I have a reporting shell script that generates a tab-delimited table. Using it within a shell code block, org parses this nicely into an org table. But org seems to drop any trailing zeros from numeric cells. My reporting script has already done the number formatting, so I want trailing zeros preserved (both within org and in html export). What's the best way? Thanks, Joe
Re: [O] mobile-org, webdav, can't push (password not accepted)
At Sat, 14 Jul 2012 18:47:33 -0400, James Harkins wrote: > - So I thought, okay, how about synchronizing to the tablet's calendar? > Unfortunately, it seems that MobileOrg ignores timestamps in item headlines. > The item has to have either a scheduled time or a deadline. So I guess I will > need to enter redundant dates -- once in the headline for C-c a, and again > using C-c C-s. Is that correct, or a bug? Oops, sent too soon... Redundant dates are presented redundantly in emacs' agenda view! So I'll have to switch my habit from C-c . to C-c C-s. That's not so bad... never mind :) hjh -- James Harkins /// dewdrop world jamshar...@dewdrop-world.net http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman blog: http://www.dewdrop-world.net/words audio clips: http://www.dewdrop-world.net/audio more audio: http://soundcloud.com/dewdrop_world/tracks
Re: [O] mobile-org, webdav, can't push (password not accepted)
At Sat, 14 Jul 2012 12:05:16 -0400, James Harkins wrote: > > Hi, I need a little help with mobile-org and webdav. (I need to use webdav > because I live year-round in China, and the last time I tried, dropbox was > not accessible from the mainland. In any case, I prefer to keep the data > local.) OK... For testing purposes, I decided to start off with dropbox. I can switch to webdav later (but my return to China is in about 3.5 weeks, so the clock is ticking -- the original question in this thread still needs to be solved). I was able to push to dropbox, and sync on my tablet. Some issues -- - I can't find an option within MobileOrg on the tablet to look at an agenda-style view. Does it exist? (This is for android.) - So I thought, okay, how about synchronizing to the tablet's calendar? Unfortunately, it seems that MobileOrg ignores timestamps in item headlines. The item has to have either a scheduled time or a deadline. So I guess I will need to enter redundant dates -- once in the headline for C-c a, and again using C-c C-s. Is that correct, or a bug? So... interesting... a bit less than I hoped. But orgmode itself is so much better than anything else I've used, it's worth trying to make it work. Thanks, James -- James Harkins /// dewdrop world jamshar...@dewdrop-world.net http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman blog: http://www.dewdrop-world.net/words audio clips: http://www.dewdrop-world.net/audio more audio: http://soundcloud.com/dewdrop_world/tracks
[O] org-caldav: Sync Org with external calendars through CalDAV (Owncloud, Google, ...)
I have written a package 'org-caldav' which can sync items to a remote calendar server using the CalDAV protocol. The main purpose of this package is to make better use of Org in combination with Android-based mobile devices (yes, there is mobileOrg, but I have several problems with it; that's a topic for another day, though). I think org-caldav is now "good enough" to allow some testing by adventurous people. I put the code up on github here https://github.com/dengste/org-caldav I've tested the code with my Owncloud server and also with Google Calendar. Please see the Readme on how to set things up. Most importantly, please use a new, dedicated calendar for testing this package; do *not* use your precious main calendar. Also, while org-caldav should only access the calendar you provide through `org-caldav-calendar-id', you should have a backup of all your calendar data, just in case. The initial sync can take some time, depending on the number of events. Especially the CalDAV interface to Google can be quite slow at times. If the initial sync aborts for any reason, just run `org-caldav-sync' again. Note that after the initial sync, only new events will be transferred, so things should become much snappier. A few further notes regarding the code: I am relying mainly on three other packages to do the real heavy lifting, which is also why org-caldav is actually pretty small: - url-dav.el for talking to WebDAV servers (CalDAV is essentially WebDAV with a few extensions). Unfortunately, the current version of url-dav that is shipping with Emacs is broken for practically all CalDAV servers (see bug #11916), which is why I provide a patched version of url-dav.el in the above repository. You have to make sure that this patched version is loaded instead of the one in Emacs proper. I am hoping that this will be fixed in Emacs 24.2. - org-icalendar.el is doing all the conversion from org to icalendar events which are needed for CalDAV. This has the advantage that you can use all the variables from that package to control how things should be exported. The only exception is the actual org files being searched for time stamps, which is determined through `org-caldav-files'. - icalendar.el for parsing events from CalDAV. I took some code from that package to generate org items from the calendar events. The syncing between org and the external calendar is not yet really finished. I would like to have proper two-way-syncing so that you can freely change events on any side, but this is rather difficult to do and I'd first like to get some feedback on the current code. Also, I have a hunch that some Org experts around here might have some good ideas on how to properly implement this. Here's what the code can currently do: - All items in `org-caldav-files' with active time stamps are synced to the calendar. - If you change an item in one of those files in orgmode, this change will also get synced to the external calendar (to be exact: this will generate a new event and the old one will be deleted). - If you create a *new* event in the calendar through Android or any other client (like browser), this event will land in the `org-caldav-inbox' file as an org item. However: - If you *change* an item directly on the CalDAV server, this will *not* get synced back to Org. What happens exactly depends on the server (whether it renames the event or not). Just try it out. The item might even get deleted after the next sync - you have been warned. - Likewise, if you *change* and item in `org-caldav-inbox', this will not get synced back to the calendar. OK, this has gotten way too long already. Please try it out and let me know how it goes. Cheers, David
Re: [O] Using HTML or ODF to get content from Org to Word
emacs-orgmode-requ...@gnu.org writes: > > I am a bit puzzled. I thought that using the ODF-exporter would be > the format of choice to get content from Org to Word. Why do you > guys prefer HTML? The following is my opinion why I prefer using HTML to ODF for transfer to Word, but there is no reason for not using ODF for transfer files. It is more a matter of personal taste than anything else. 1. Mature support for HTML import on Word. ODF import was included in Office 2007 as an option. But HTML support has been available since Office 2000. (probably since Office '98, but it's been a while since I used that one). If you do not have the ODF facility installed in Word or if you're stuck with an older version of Office then you have to convert to Word using Libre/Open Office. That's an extra step and more conversion errors to add to the final result. 2. Less nuances to worry about. HTML is clean and a plain ASCII format at the expense of size. I am not familiar with ODF's internal structure, but I've worked on the generation of MS Open Office XML documents at work. Even though it's an XML format, there are sometimes difference in the positioning of elemements when documents are created in Word vs when they are created through a program using the MSOOXML libraries. One issue I had during testing was the inclusion of images in which they get installed on a different nodes if the document is created through the .NET API. These causes images not to show up in LibreOffice or AbiWord to crash. However they render fine in Word. My 2 cents... -- Luis Anaya papo anaya aroba hot mail punto com "Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo
[O] Google Summer of Code update
Dear all, this week, GSoC co-mentors and students spent time testing and evaluating our GSoC projects. Of the 3 ongoing projects, one will stop and the two others will continue. The "bugpile" project will stop: Thorsten produced lots of exploratory writing for the design of a web framework based on elnode and Org, and he wrote code for this. But Eric and I feel like the project is not going in the right direction. So instead of spending too much time on trying to agree about a new direction, we decided to stop the project. This is a hard decision to take, but I think this is for the best. I should thank again Thorsten here, as he's the one who convinced me to go for the GSoC this year. His code and docs remain available, and I'm sure there are lots of ideas that will survive this experience. ~$ git clone git://orgmode.org/bugpile.git http://orgmode.org/worg/org-contrib/gsoc2012/student-projects/bugpile/ Thanks also goes to Eric for his time mentoring Thorsten. And thanks goes of course to Google! Being paid to write free software is a priviledge -- even more when failing is just part of the game. Aurélien's and Andrew's projects get boosted by the mid-term deadline, check their repos: ~$ git clone git://orgmode.org/org-sync.git [Aurélien] ~$ git clone git://orgmode.org/org-merge-driver.git [Andrew] *Please* read/test/review their code as much as possible: send feedback, however premature you think it can be -- because *it is not*. I just read this blog entry - "How to recruit open-source contributors": http://redmonk.com/dberkholz/2012/07/10/how-to-recruit-open-source-contributors/ This resonates very well with what I think and what I hope we will gain from participating to the GSoC: new contributors. So, please all take a dive into the students' code, because that's how they will interact with the list. And students: please pick up questions on this list, pending issues, known bugs -- and have a go, try fix things, report more stuff. Do this in your free time :-) It will help you feel more comfortable sharing your Org (coding) experience with fellows here. Thanks for your support! -- Bastien
Re: [O] Using HTML or ODF to get content from Org to Word
Karl Voit writes:
> * Jambunathan K wrote:
>>
>> Instead of importing ODT documents right inside Microsoft Office, one
>> can have LibreOffice do the ODT->DOC(X) conversion and import the LO
>> created DOC(X) file in to Microsoft Office.
>
> As a side-mark to your great comments: LibreOffice (and
> OpenOffice.org) is able to convert documents from command line without
> having the need for opening them, invoking a save-as-process,
> choosing a different format, and closing it.
>
> If somebody needs to do (semi-automatically) conversions, take a
> look into the command line option "--convert-to".
M-x pp-eval-expresssion RET org-export-odt-convert-processes RET
will you give you this. Note the first entry.
, C-h v org-export-odt-convert-processes
| (("LibreOffice" "soffice --headless --convert-to %f%x --outdir %d %i")
|("unoconv" "unoconv -f %f -o %d %i"))
`
--
Re: [O] Using HTML or ODF to get content from Org to Word
* Jambunathan K wrote: > > Instead of importing ODT documents right inside Microsoft Office, one > can have LibreOffice do the ODT->DOC(X) conversion and import the LO > created DOC(X) file in to Microsoft Office. As a side-mark to your great comments: LibreOffice (and OpenOffice.org) is able to convert documents from command line without having the need for opening them, invoking a save-as-process, choosing a different format, and closing it. If somebody needs to do (semi-automatically) conversions, take a look into the command line option "--convert-to". > For creating DOC/DOCX/PDF files right from Org see Info node with > following title: (org) Extending ODT export. Cool :-) > ps: I have not used MS Word at all. Never? Really? Wow ... Lucky you! I once met a guy who was working in the IT industry since the seventies and he never ever used MS Windows in his life. Impressive. (His source code was completely crap but this is another story *g*) -- Karl Voit
Re: [O] new exporter
Jambunathan K writes: > Nicolas Goaziou writes: > >> Hello, >> >> Achim Gratz writes: >> >>> Yes, that has been my impression as well. Again, I can make them go >>> away by removing one of the byte-compiled files, so I rather suspect >>> another case of a macro expansion that's not quite what was intented. >>> Only this time I really don't see from the backtrace what that would >>> be. >> >> It looks like table-cells have a wrong `:parent' property when >> org-element.el is byte-compiled. In `org-element-table-cell-parser', >> replacing backquote with `list' solves the problem. > > >> This is related to modifications by side-effect of list elements, but >> I don't know why it only happens when the file is byte-compiled and why >> it only focus table cells. > > There is an interesting "pitfall" mentioned wrt `nconc' under: >(info "(elisp) Rearrangement"). > > I try to make sense of the pitfall by conjuring up this argument. This > seems right to me. > - `list' will dynamically allocate the list at runtime. It comes from > C's heap. > > - A quote list is allocated at compile time (atleast the constant > bits). It comes from memory that is allocated for global variables - > externs or static externs. Think value of list is the pointer to an > extern C variable. > > I am not sure what backquote does. > > Wrt above problem, you may want to verify the following: > 1. It works right the first time. But subsequent invocations create >side-effect. > 2. Focus on what happens to the `head' of the list. Do table-cell gets "composed" in a special way wrt other elements. > I am more or less facing similar problems wrt element translation. I am > holding off any checkin mainly because I see some undesirable > side-effects. I dont't have handle on it yet. May be it is just a coincidence that the translation involves lists and tables. ps: If only there way to see the C pointers underlying the objects one could actually sensibly see what is happening underneath. The closest I have come to doing so is to use a combination of `pp-display-expression' with (setq print-circle t). This latter part was added to my .emacs only in the last 2 days in an effort to bring out the differnce between `eq' and `equal'. For example a table like this | 1 | 2 | | a | b | gets rendered as below. Track the :parent properties, the Ns and #es and you have no ambiguity on what objects they point to. #1=(org-data nil #2=(section (:begin 2 :end 22 :contents-begin 2 :contents-end 22 :post-blank 0 :parent #1#) #3=(table (:begin 2 :end 22 :type org :tblfm nil :contents-begin 2 :contents-end 22 :value nil :post-blank 0 :parent #2#) #4=(table-row (:type standard :begin 2 :end 12 :contents-begin 3 :contents-end 11 :post-blank 0 :parent #3#) (table-cell (:begin 3 :end 7 :contents-begin 4 :contents-end 5 :post-blank 0 :parent #4#) "1") (table-cell (:begin 7 :end 11 :contents-begin 8 :contents-end 9 :post-blank 0 :parent #4#) "2")) #5=(table-row (:type standard :begin 12 :end 22 :contents-begin 13 :contents-end 21 :post-blank 0 :parent #3#) (table-cell (:begin 13 :end 17 :contents-begin 14 :contents-end 15 :post-blank 0 :parent #5#) "a") (table-cell (:begin 17 :end 21 :contents-begin 18 :contents-end 19 :post-blank 0 :parent #5#) "b")
Re: [O] New keybinding C-c C-x C-q for ̀org-clock-cancel' (was: Byte compiler warnings in org-clock.el)
On 7/13/12, Bastien wrote: > C-c C-x C-q => ̀org-clock-cancel' My gmail shows an accent there :). -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] fast todo kw / -> x
On 7/14/12, Bastien wrote: > I updated a docstring and a part of the manual to make it > clearer only letters are supported. Thanks, Bastien. :) I appreciate the clarity in the manual. Just so you know my use case: I have 49 todo keywords and will have a few more soon, so I will keep using . ? - = + ( ) ' ; . Non-alpha are useful mnemonically for me. For example, ? is for QUESTION. I specify my keywords using a struct: (make-alpha-kw :key "." :kw "NEXTREPEAT" :group :contingent :face '(:inherit org-todo :weight normal)) If I want modifiers, I add :mod. This gets mapped into the org-todo-keywords string. The advantage for me is that it keeps the keys and the modifier semantics separate. Also, it allows me to keep all keyword-related information, currently including faces and todo groups, together. The drawback for me is that org-todo-keywords combines the separate items into strings (so modifier symbols can't be used). :/ Allowing more symbols would be useful for me. If anybody wants the struct definition and mapper, I will extract and post them. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] new exporter
Nicolas Goaziou writes: > Hello, > > Achim Gratz writes: > >> Yes, that has been my impression as well. Again, I can make them go >> away by removing one of the byte-compiled files, so I rather suspect >> another case of a macro expansion that's not quite what was intented. >> Only this time I really don't see from the backtrace what that would >> be. > > It looks like table-cells have a wrong `:parent' property when > org-element.el is byte-compiled. In `org-element-table-cell-parser', > replacing backquote with `list' solves the problem. > This is related to modifications by side-effect of list elements, but > I don't know why it only happens when the file is byte-compiled and why > it only focus table cells. There is an interesting "pitfall" mentioned wrt `nconc' under: (info "(elisp) Rearrangement"). I try to make sense of the pitfall by conjuring up this argument. This seems right to me. - `list' will dynamically allocate the list at runtime. It comes from C's heap. - A quote list is allocated at compile time (atleast the constant bits). It comes from memory that is allocated for global variables - externs or static externs. Think value of list is the pointer to an extern C variable. I am not sure what backquote does. Wrt above problem, you may want to verify the following: 1. It works right the first time. But subsequent invocations create side-effect. 2. Focus on what happens to the `head' of the list. I am more or less facing similar problems wrt element translation. I am holding off any checkin mainly because I see some undesirable side-effects. --
Re: [O] was this intentional with the default header ":results value"
Aloha Eric, Eric Luo writes: > Hi, > Why in the following code block, c1 was printed as scientific notation > rather then characters. > , > | > | #+BEGIN_SRC R :results value > | df <- data.frame(c1="123456789123456789",c2=2) > | #+END_SRC > | > | #+RESULTS: > | | 1.2345678912345678e+17 | 2 | > ` With :results value the results are passed from the source language into emacs-lisp and then displayed in the buffer. So, the representation of things like very large numbers depends on how that was done in emacs-lisp, independent of the source language conventions. In this case, I suspect the number was written with a formatting string and ‘%g’ which uses scientific notation if that is a shorter representation. > But if the header :results output, the result was expected. > , > | > | #+BEGIN_SRC R :results output > | df <- data.frame(c1="123456789123456789",c2=2) > | df > | #+END_SRC > | > | #+RESULTS: > | : c1 c2 > | : 1 123456789123456789 2 > ` > With :results output the results aren't translated into emacs-lisp. Instead, the output from the source language is collected and displayed in the buffer. Thus, the output conventions of the source language are respected. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] new exporter
Nicolas Goaziou writes: > It looks like table-cells have a wrong `:parent' property when > org-element.el is byte-compiled. In `org-element-table-cell-parser', > replacing backquote with `list' solves the problem. > > This is related to modifications by side-effect of list elements, but > I don't know why it only happens when the file is byte-compiled and why > it only focus table cells. I'll try to grok this later... at least now I know where to look. > `org-element-current-element' is an internal function and (point-max) is > an unusual value, albeit sufficient for testing purpose. OK. Minor nit: if strictly an internal function (even if useful for testing) you might consider naming it org-element--current-element to make it more self-documenting. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] MobileOrg on an Android tablet?
> From: Luis Anaya > > Is anyone using MobileOrg for android on a tablet? > > I am... Vizio table running Honeycomb. Cool... I'm almost running it. Just got an Asus transformer tab. I posted a question separately about push problems :-( so I'm not there yet. > It is the android version a phone app. > In the case of mobileorg on Honeycomb, you get more area for text if > you choose to. It works ok. Keep in mind that you're organizing your > life in plain text :) Of course :-) I had read an article in pc mag about how awfully android tablet apps use screen space, which got me thinking. Now that I have one, it's not such a big deal as that guy was whining about. Looking forward to getting it all configured! James
Re: [O] new exporter
Hello, Achim Gratz writes: > Yes, that has been my impression as well. Again, I can make them go > away by removing one of the byte-compiled files, so I rather suspect > another case of a macro expansion that's not quite what was intented. > Only this time I really don't see from the backtrace what that would > be. It looks like table-cells have a wrong `:parent' property when org-element.el is byte-compiled. In `org-element-table-cell-parser', replacing backquote with `list' solves the problem. This is related to modifications by side-effect of list elements, but I don't know why it only happens when the file is byte-compiled and why it only focus table cells. > Thanks. I meanwhile had figured that the limit parameter was missing, > but not if it should always be (point-max). However since you did make > that mistake yourself, maybe you could reconsider the function signature > and perhaps making limit optional and replacing it with (point-max) if > not present (reads as nil)? It seems that it would unclutter the code > for the typical use... `org-element-current-element' is an internal function and (point-max) is an unusual value, albeit sufficient for testing purpose. Regards, -- Nicolas Goaziou
Re: [O] Using HTML or ODF to get content from Org to Word
For people taking ORG->ODT->Microsoft Office they might want to give particular attention to the formatting of - Lists - Tables in the imported document. My best guess is import will be troublefree for the most part. Only issues could be around the import of customized tables. i.e., tables created with Info node: "(org) Customizing tables in ODT export". --
Re: [O] BUG: Clocking is broken in master
Bastien writes: > Bernt Hansen writes: > >> I upgraded to release_7.8.11-174-g3ecd7a9 >> this morning and after setting my clock I can't clock in on another task >> anymore (the clock doesn't move) > > Now fixed in git, thanks for reporting this. Thanks for the quick fix Bastien :) Regards, Bernt
Re: [O] Using HTML or ODF to get content from Org to Word
If one does ORG->HTML->DOC instead of ORG->ODT->DOC, following areas could be problemsome. - Footnotes - Inlined images - do they end up right within the document or outside of it. See: http://www.libreoffice.org/download/release-notes/ https://wiki.documentfoundation.org/ReleaseNotes/3.5#ODF_1.2_Conforming_Documents https://bugs.freedesktop.org/show_bug.cgi?id=44498 , | Microsoft Office 2010 will complain that ODF 1.2 and extended documents | written by LibreOffice 3.5 are invalid (but opens them still). This is a | shortcoming in MSO2010 only supporting ODF 1.1, please see here for | further details. | | ODF 1.2 Conforming Documents | | LibreOffice 3.5 writes valid ODF 1.2 | | Microsoft Office only officially supports ODF 1.1 and complains that | ODF 1.2 and ODF 1.2 extended documents written by LibreOffice 3.5 | are invalid. | | The warning from Microsoft Office can be safely ignored, and the | "Repair" option will import the document. | | For users that find this annoying, a workaround is to open | Tools->Options->Load/Save->General and set "ODF format version" to | "1.0/1.1". However, please note that this will cause some | information to be lost when storing documents. ` Instead of importing ODT documents right inside Microsoft Office, one can have LibreOffice do the ODT->DOC(X) conversion and import the LO created DOC(X) file in to Microsoft Office. For creating DOC/DOCX/PDF files right from Org see Info node with following title: (org) Extending ODT export. ps: I have not used MS Word at all. --
[O] mobile-org, webdav, can't push (password not accepted)
Hi, I need a little help with mobile-org and webdav. (I need to use webdav because I live year-round in China, and the last time I tried, dropbox was not accessible from the mainland. In any case, I prefer to keep the data local.) I've set up the webdav server following the instructions here: http://www.howtoforge.com/how-to-set-up-webdav-with-apache2-on-ubuntu-10.04 This guide suggests two tests: connecting to webdav at the command line using cadaver, and using "connect to server" in Ubuntu's nautilus (Ubuntu 12.04). In both of those tests, I can authenticate successfully to the server. In Emacs, I made sure the org files I want to sync are under org-directory, and I think I set up the rest okay according to: http://orgmode.org/worg/org-faq.html#mobileorg_webdav Org Mobile Files: Hide Value [X] org-agenda-files [ ] org-agenda-text-search-extra-files State: STANDARD. Files to be staged for MobileOrg. More Org Mobile Directory: Hide Value /scpc:hjhmbrg@127.0.0.1:org/webdav/ State: SAVED and set. The WebDAV directory where the interaction with the mobile takes place. Org Mobile Inbox For Pull: Hide Value ~/Documents/mobileorg/from-mobile.org State: SAVED and set. But pushing from orgmode refuses to accept the password. I know I'm typing in the correct password because it works with cadaver and "connect server." I also tried the staging approach. Same problem. The org files are staged successfully. Then there's a pop-up window for the OpenSSH password, but again, if I type the exact same password I used with "sudo htpasswd," it fails to authenticate. Note again that it is *not* a general webdav problem -- I can authenticate by other methods, but whatever org is doing to log in, it isn't working. Any ideas? hjh -- James Harkins /// dewdrop world jamshar...@dewdrop-world.net http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman blog: http://www.dewdrop-world.net/words audio clips: http://www.dewdrop-world.net/audio more audio: http://soundcloud.com/dewdrop_world/tracks
Re: [O] Using HTML or ODF to get content from Org to Word
Hello Giovanni! * Giovanni Ridolfi wrote: > Karl Voit > >> I thought that using the ODF-exporter would be the format of >> choice to get content from Org to Word. Why do you guys prefer >> HTML? > > A reason could be (in my case) because we cannot have LibreOffice > installed :-( No need to do that. (Besides: there are portable-versions of LibreOffice[1] so that you can install LibreOffice on any operating system having any kind of reduced permissions. But this is not my point.) > But you're right in remembering me that "write" (and perhaps > word?) can read odf files. I will try odf, thanks! Yes, this was the thing I wanted to mention: Word is able to read in ODF. And since ODF has a *way* more similar kind of "markup" to docx, it should result in much better results than using HTML. But: I never tried it by myself. So I was wondering, if there are good arguments against using ODF in the first place and using HTML as best choice. 1. http://duckduckgo.com/?q=libreoffice+portable -- Karl Voit
Re: [O] Using HTML or ODF to get content from Org to Word (was: How to integrate org-mode in a MS Windows-/Office-based environment?)
Karl Voit Inviato: Sabato 14 Luglio 2012 11:56 Hi, Karl, >* Luis Anaya wrote: >> Using HTML for export is a good way to transfer content as has been >> suggested. > I thought that using the ODF-exporter would be > the format of choice to get content from Org to Word. Why do you > guys prefer HTML? A reason could be (in my case) because we cannot have LibreOffice installed :-( But you're right in remembering me that "write" (and perhaps word?) can read odf files. I will try odf, thanks! cheers, Giovanni
[O] was this intentional with the default header ":results value"
Hi, Why in the following code block, c1 was printed as scientific notation rather then characters. , | | #+BEGIN_SRC R :results value | df <- data.frame(c1="123456789123456789",c2=2) | #+END_SRC | | #+RESULTS: | | 1.2345678912345678e+17 | 2 | ` But if the header :results output, the result was expected. , | | #+BEGIN_SRC R :results output | df <- data.frame(c1="123456789123456789",c2=2) | df | #+END_SRC | | #+RESULTS: | : c1 c2 | : 1 123456789123456789 2 ` Thanks
[O] Using HTML or ODF to get content from Org to Word (was: How to integrate org-mode in a MS Windows-/Office-based environment?)
* Luis Anaya wrote: > > There have been a list of good suggestions of integrating org-mode with > MS products. [...] > Using HTML for export is a good way to transfer content as has been > suggested. I am a bit puzzled. I thought that using the ODF-exporter would be the format of choice to get content from Org to Word. Why do you guys prefer HTML? -- Karl Voit
Re: [O] How to integrate org-mode in a MS Windows-/Office-based environment?
Hi: There have been a list of good suggestions of integrating org-mode with MS products. I personally use org-mode primarily for task tracking rather than document generation. I use the following combination of tools and techniques: 1. I get tickets assign for review on JIRA. I capture those using jira.el . Yes, I am aware that there is a jira-org tool, but I'm used to jira.el. I get a list of tickets, highlight any new ones and store them in remember mode for inclusion into my task file. 2. I do use gnus with IMAP in which I use davmail as the conduit. If you are lucky to have exchange enabled with IMAP, then you do not need to do this. In my workplace, that's not the case. The issue of using davmail is that you get constrained to use emacs 22 being that version of gnus that is shipped in emacs 23 does not play well with davmail. I have not tried it with emacs 24. This is mostly for emails and capture any new tasks or ideas that warrant to be stored for tracking. 3. I do not normally store appointments in org-mode. I rather have my phone nagging me when a meeting is coming up. I use the weekly agenda to track deadlines. Using HTML for export is a good way to transfer content as has been suggested. In my personal case, most of my documentation stored in org-mode are meeting notes, I really do not have a need to transfer to Word being that these are for my use. -- Luis Anaya papo anaya aroba hot mail punto com "Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo
Re: [O] fast todo kw / -> x
Samuel Wales writes: > NEXTKA below is selected by "x" instead of "/", which is surprising. > > Perhaps it's worth documenting the allowable keys? I updated a docstring and a part of the manual to make it clearer only letters are supported. Thanks, -- Bastien
Re: [O] BUG! Re: Byte compiler warnings in org-clock.el
Giovanni Ridolfi writes: >> Done, thanks. > > Unfortunately this introduces a bug: FWIW, the bug was not really introduced by the fix you refer to, but by a previous hack of mine: I tried to bind `org-clock-in-last' to C-c C-x C-I, but then `org-clock-in-last' was bound to C-c C-x C-I (note the upper/lowercase "i"). -- Bastien
