Re: [O] Preservation of white space in babel blocks, exporting to PDF
Hello, John Hendy jw.he...@gmail.com writes: Thus, I take it that the default org setting is non-nil? Actually this is an Emacs variable, and it is indeed non-nil. I am a bit frustrated by trying to be as clear as I could about the situation with reproducible examples, and then finding out the behavior was apparently obvious, but due to a variable I didn't know existed... The behaviour is not obvious. I'll try a fresh pull tomorrow as well as looking at indent-tabs-mode. This should hopefully work. It should also work if you don't change this variable but set `org-src-preserve-indentation' to a non-nil value, since I fixed that. Note that you can set this variable on a per-block basis with -i flag: #+BEGIN_SRC python -i ... #+END_SRC Regards, -- Nicolas Goaziou
Re: [O] Changing title for outline
OSX 10.9 Emacs 24.3 orgmode 8.2.5h I also tried # Local Variables: # org-beamer-outline-frame-title: Themen # End: at the end of the file and it did not work On Feb 1, 2014, at 9:23 AM, Bastien b...@gnu.org wrote: Hi Erich, Erich Neuwirth erich.neuwi...@univie.ac.at writes: Suing this at the end of file #+ Local Variables: #+ org-beamer-outline-frame-title: Themen #+ End: Brings up a prompt about changing local variables, but accepting the changes does still not produce the desired result. The header line of the outline frame still is Outline What version of Emacs and Org are you using ? -- Bastien signature.asc Description: Message signed with OpenPGP using GPGMail
[O] Strange behavior with auto-fill
I've been observing a very annoying behavior with auto fill; it persist in the latest org from git, as well as the version shipped with Emacs 24.3 for OS X. Consider starting a clean Emacs session with emacs -Q. Start a new file, foo.org. Do M-x org-mode and M-x auto-fill-mode. Now enter the following 3 lines: --- --- --- (yes, that's a bunch of dashes). Now try putting a long line in between the second and third set of dashes, and wait for auto-fill to wrap the line. Here is what I observe: --- --- This is a long line designed to exhibit a bug in auto-fill. It's ---almost as if auto-fill thinks the dashes are a comment symbol. --- Notice how after wrapping the line acquired a leading ---! Why does this happen, and how can it be turned off? --Leo
Re: [O] Changing title for outline
The attached file works fine for me. If you add local variables after finding the file, do C-c C-c on #+TITLE to refresh local variables. If you find the file while local variables are already there, you don't need it. test.org Description: Lotus Organizer -- Bastien
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Anyway, I removed it because, even if we want to keep it, it needs to be rewritten, using parser and unit tests. It also needs to be renamed. If we don't need C-c : binding, it is possible to re-implement it. Yes, that'd be nice, thanks. -- Bastien
Re: [O] Preservation of white space in babel blocks, exporting to PDF
On Sun, Feb 2, 2014 at 2:45 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, John Hendy jw.he...@gmail.com writes: Thus, I take it that the default org setting is non-nil? Actually this is an Emacs variable, and it is indeed non-nil. Gotcha. So if it interferes with org-src-preserve-indentation, that's good to know. I'm assuming that was the change you recently pushed per the last note. I am a bit frustrated by trying to be as clear as I could about the situation with reproducible examples, and then finding out the behavior was apparently obvious, but due to a variable I didn't know existed... The behaviour is not obvious. Sorry, what I meant is that at no point in our dialog did you seem surprised by my outcomes. First, you simply said you couldn't reproduce. Then you said the issue was because I was /using/ tabs (vs. spaces). When I disagreed, you clarified that saying I was /using/ tabs had really meant I had indent-tabs-mode set to non-nil. From my non-mastery of Org/emacs perspective, it appeared you knew what was going on, but revealed it in layers to me. I'll try a fresh pull tomorrow as well as looking at indent-tabs-mode. This should hopefully work. It should also work if you don't change this variable but set `org-src-preserve-indentation' to a non-nil value, since I fixed that. Note that you can set this variable on a per-block basis with -i flag: #+BEGIN_SRC python -i ... #+END_SRC Awesome. Tried both methods, both of which work exactly as I'd have hoped! - Putting =(setq org-src-preserve-indentation t)= in .emacs - No setting for the above variable, but using =-i= in the src block Thanks so much! This has perplexed me for a really long time, but I've never looked into it. I'm giving my first more major talk at a local event (talking about R + geo-spatial data as well as Shiny interactive web-apps), and wanted my code to look nice and pretty. Many thanks for enabling that!! I'll be on the lookout for somewhere on Worg where I can add the new documentation if you haven't done so already. Best regards, John Regards, -- Nicolas Goaziou
Re: [O] Assistance with patching instructions on Worg
Just confirming the change of Worg. I used the same format specified in the Worg git page: - Changed page: http://orgmode.org/worg/org-contribute.html#sec-4-2 - Worg git referred to: http://orgmode.org/worg/worg-git.html Having seen that page, I wondered if it should instructions to use `git add file.ext` if files are created? I left that alone for now, figuring that I'm at a lower-than-most level of git intelligence :) By the way, I love that Worg updates immediately now! John On Fri, Jan 31, 2014 at 4:59 PM, John Hendy jw.he...@gmail.com wrote: On Fri, Jan 31, 2014 at 4:57 PM, Josiah Schwab jsch...@gmail.com wrote: jw.he...@gmail.com writes: I was just following along with Worg, which doesn't mention doing that. I'm now thinking that `git add` must be implied in the line =make some changes (1)=? Yes, I agree; as written, there is an implicit `git add`. I think it would be reasonable to make that explicit. Will do, and thanks for the quick assistance all! John Best, Josiah
Re: [O] IDs w/ human friendly component
Yes that is a fairly simple and obvious solution. -k. On Sun, 2 Feb 2014, Daniel Clemente wrote: Have you tried changing the strange ID to the ID that you want? (e.g. 7f3b531b-f1c9-41aa-854b-37235500495f → introduction). They should be unique. I use my manually written IDs for some important headers which I want to detect from outside org. In addition there's CUSTOM_ID, but I think that's the id=… you want in HTML exports. El Sat, 1 Feb 2014 14:39:15 -0500 (EST) Ken Mankoff va escriure: I've never cared that the ID field was not human friendly. But I've just learned about the Estimate Table where you can see your estimates and actual clock time to complete tasks. If you want to see the estimates for the current tree, you need to know the ID, which is not human friendly. It seems like with IDO mode, the first few characters or words of the title, stripped of whitespace, could be pre- or ap- pended onto the ID, and then it would be easy to select IDs. If this were how IDs were created, would this break some other features? Do others see this as a good or bad thing? Or is there some other way to tell the Estimate Table to work on the local tree. Cheers, -k.
Re: [O] IDs w/ human friendly component
you can put some kind of prefix on like this: * intro to a section :PROPERTIES: :ID: intro-to-a:0f141497-f3ad-488a-b8c9-0a5c3ea53ba0 :END: #+BEGIN_SRC emacs-lisp (defun get-my-id () create an org-id with prefix based on headline (let ((s)) (setq s (replace-regexp-in-string - (nth 4 (org-heading-components (org-id-get (point) t (substring s 0 (if ( (length s) 10) 10 (length s)) (get-my-id) #+END_SRC #+RESULTS: : intro-to-a:0f141497-f3ad-488a-b8c9-0a5c3ea53ba0 John --- John Kitchin Associate Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu On Sun, Feb 2, 2014 at 12:10 PM, Ken Mankoff mank...@gmail.com wrote: Yes that is a fairly simple and obvious solution. -k. On Sun, 2 Feb 2014, Daniel Clemente wrote: Have you tried changing the strange ID to the ID that you want? (e.g. 7f3b531b-f1c9-41aa-854b-37235500495f → introduction). They should be unique. I use my manually written IDs for some important headers which I want to detect from outside org. In addition there's CUSTOM_ID, but I think that's the id=… you want in HTML exports. El Sat, 1 Feb 2014 14:39:15 -0500 (EST) Ken Mankoff va escriure: I've never cared that the ID field was not human friendly. But I've just learned about the Estimate Table where you can see your estimates and actual clock time to complete tasks. If you want to see the estimates for the current tree, you need to know the ID, which is not human friendly. It seems like with IDO mode, the first few characters or words of the title, stripped of whitespace, could be pre- or ap- pended onto the ID, and then it would be easy to select IDs. If this were how IDs were created, would this break some other features? Do others see this as a good or bad thing? Or is there some other way to tell the Estimate Table to work on the local tree. Cheers, -k.
Re: [O] Assistance with patching instructions on Worg
Hi John, thanks for the update on Worg! John Hendy jw.he...@gmail.com writes: Having seen that page, I wondered if it should instructions to use `git add file.ext` if files are created? I left that alone for now, figuring that I'm at a lower-than-most level of git intelligence :) When it comes to Git instructions, we are never explicit enough, so feel free to give as much details as you (needed) want. Thanks! -- Bastien
Re: [O] Org not preserving Python indent levels on LaTex export due to tabs
Thank you! That worked perfectly. Is '-i' not in the docs? On Sun, Feb 2, 2014 at 1:49 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, James Ryland Miller james.ryland.mil...@gmail.com writes: I'm having trouble with getting python source=code blocks to export to LaTeX properly. I've figured out what's going wrong: the exporter is inserting tab characters on lines with 2 or more indentation levels in python. If I use org to export to .tex first, and then untabify the .tex files, the indent levels are preserved (assuming the tabs correctly lined up with the corresponding python in the first place, which many times they don't). Try to set `org-src-preserve-indentation' to a non-nil value (on a very recent Org) or add a -i flag to you source block: #+BEGIN_SRC python -n -i ... #+END_SRC This should prevent Org from touching indentation within the block. Regards, -- Nicolas Goaziou
Re: [O] Org not preserving Python indent levels on LaTex export due to tabs
I think it was very recently added (i.e. yesterday) due to this thread about a very similar (same) issue: - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg81203.html I'd love to update Worg/documentation to include it... out of curiosity, where were you looking for it to be documented? That way, I can add it to the most intuitive/popular location. Thanks, John On Sun, Feb 2, 2014 at 11:32 AM, James Ryland Miller james.ryland.mil...@gmail.com wrote: Thank you! That worked perfectly. Is '-i' not in the docs? On Sun, Feb 2, 2014 at 1:49 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, James Ryland Miller james.ryland.mil...@gmail.com writes: I'm having trouble with getting python source=code blocks to export to LaTeX properly. I've figured out what's going wrong: the exporter is inserting tab characters on lines with 2 or more indentation levels in python. If I use org to export to .tex first, and then untabify the .tex files, the indent levels are preserved (assuming the tabs correctly lined up with the corresponding python in the first place, which many times they don't). Try to set `org-src-preserve-indentation' to a non-nil value (on a very recent Org) or add a -i flag to you source block: #+BEGIN_SRC python -n -i ... #+END_SRC This should prevent Org from touching indentation within the block. Regards, -- Nicolas Goaziou
Re: [O] export to ODT fails strangely
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric S Fraga e.fr...@ucl.ac.uk writes: I hope somebody can point me in the right direction. I am trying to export a large document to ODT to share with my collaborators. Exporting to LaTeX works like a charm. However, with ODT, the exporter fails with: , | OpenDocument export failed: FIXME: Resolve (paragraph (:begin 23510 :end | 23635 :contents-begin 23599 :contents-end 23629 :post-blank 1 | :post-affiliated 23599 :name fig:graph :caption (((#(Dependency graph | of major tasks in the project. 0 47 (:parent #4) :results () | [...] ` I guess you are cross-referencing to a paragraph (probably a standalone image) named fig:graph. You can probably get an ECM if you isolate both that paragraph and the link referring to it. Well, you are partially correct in that the problem has to do with my [[fig:graph]] type of links, which I assume are valid? Does the fig: maybe confuse something? In any case, I could get the document to export but only by removing all similar links. I have two figures and 6 references to these figures in my large document. I tried changing fig: to fig- in all cases but I have the same problem. Removing all the links (all I did was change [[fig to [fig) allows the file to be exported (without the links, obviously). This particular document is no longer needed. It was a grant proposal which was submitted on Thursday and will never need to be exported again so the problem no longer affects me. However, there is some problem somewhere... While I'm at it, thanks again to the org community: the process of putting together a rather large proposal went so much better thanks to org than it would have been had I had to use any alternative system! Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5h-585-g5f0ca0
Re: [O] emacs calc and src block editing
Florian Beck f...@miszellen.de writes: On 25.01.2014 13:49, Eric S Fraga wrote: There is a niggling aspect of editing source code blocks. If, while in the src block buffer (reached by C-c '), if you start up calc and request calc-copy-to-buffer to place a result in the source code being edited, the copy is actually placed in the original org buffer and subsequently lost when exiting the src buffer. In my opinion, the copy should be place in the src buffer at point. It is a feature of calc, not to copy to internal (starred) buffers. Ah. Okay, that's fine then. Thanks for your suggested advice. I haven't tried it yet but have made a note of it. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5h-585-g5f0ca0
Re: [O] how to customize date export
Mirko Vukovic mirko.vuko...@gmail.com writes:
Hello,
I could not figure out how to customize org's export of dates into latex.
I found org-export-date-timestamp-format, but that works only for the DATE
keyword.
What can work on all date-stamps in the document?
Have a look at
,[ C-h v org-latex-active-timestamp-format RET ]
| org-latex-active-timestamp-format is a variable defined in `ox-latex.el'.
| Its value is \\textit{%s}
|
| Documentation:
| A printf format string to be applied to active timestamps.
|
| You can customize this variable.
|
| [back]
`
and
,[ C-h v org-latex-inactive-timestamp-format RET ]
| org-latex-inactive-timestamp-format is a variable defined in `ox-latex.el'.
| Its value is \\textit{%s}
|
| Documentation:
| A printf format string to be applied to inactive timestamps.
|
| You can customize this variable.
|
| [back]
`
but these are quite different in intent when compared with
org-export-date-timestamp-format so they may not be what you want.
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.5h-585-g5f0ca0
[O] orgtbl-to-sqlinsert
Aloha all, I'm expecting column names in the foo( ) part of the INSERT statement. I've done my best to understand http://orgmode.org/worg/org-tutorials/multitarget-tables.org.html but appear to have failed. Can someone help? *** Experiment with orgtbl-sqlinsert #+name: test-table | one | two| |-+| | 1 | Buckle | | 2 | Shoe | | 3 | Open | | 4 | Door | #+name: test-bed #+header: :var x=test-table #+begin_src emacs-lisp (require 'orgtbl-sqlinsert) (orgtbl-to-sqlinsert x '(:sqlname foo :fmt (1 %s))) #+end_src #+results: test-bed : BEGIN TRANSACTION; : INSERT INTO foo( ) VALUES ( 1 , 'Buckle' ); : INSERT INTO foo( ) VALUES ( 2 , 'Shoe' ); : INSERT INTO foo( ) VALUES ( 3 , 'Open' ); : INSERT INTO foo( ) VALUES ( 4 , 'Door' ); : COMMIT; All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
[O] Emphasis and double space
*Unless you turn off Emacs's double space at end of sentence feature, this sentence gets filled incorrectly.* But if you add * to the second group in the variable sentence-end, it fills correctly. Should this be default? Or too brittle? Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] orgtbl-to-sqlinsert
Le 02/02/2014 21:09, Thomas S. Dye a écrit : Aloha all, I'm expecting column names in the foo( ) part of the INSERT statement. I've done my best to understand http://orgmode.org/worg/org-tutorials/multitarget-tables.org.html but appear to have failed. Can someone help? *** Experiment with orgtbl-sqlinsert #+name: test-table | one | two| |-+| | 1 | Buckle | | 2 | Shoe | | 3 | Open | | 4 | Door | #+name: test-bed #+header: :var x=test-table #+begin_src emacs-lisp (require 'orgtbl-sqlinsert) (orgtbl-to-sqlinsert x '(:sqlname foo :fmt (1 %s))) #+end_src #+results: test-bed : BEGIN TRANSACTION; : INSERT INTO foo( ) VALUES ( 1 , 'Buckle' ); : INSERT INTO foo( ) VALUES ( 2 , 'Shoe' ); : INSERT INTO foo( ) VALUES ( 3 , 'Open' ); : INSERT INTO foo( ) VALUES ( 4 , 'Door' ); : COMMIT; All the best, Tom Hi Thomas. I don't understand this behavior yet. But here is a workaround: try the #+ORGTBL: SEND feature: 1- Add a #+ORGTBL: SEND line 2- Add a BEGIN RECEIVE ORGTBL block 3- Type C-c C-c with cursor on the first pipe of the table --8---8-- #+ORGTBL: SEND faraway orgtbl-to-sqlinsert :sqlname foo :fmt (1 %s) | one | two| |-+| | 1 | Buckle | | 2 | Shoe | | 3 | Open | | 4 | Door | ;; BEGIN RECEIVE ORGTBL faraway BEGIN TRANSACTION; INSERT INTO foo( one, two ) VALUES ( 1 , 'Buckle' ); INSERT INTO foo( one, two ) VALUES ( 2 , 'Shoe' ); INSERT INTO foo( one, two ) VALUES ( 3 , 'Open' ); INSERT INTO foo( one, two ) VALUES ( 4 , 'Door' ); COMMIT; ;; END RECEIVE ORGTBL faraway --8---8--
Re: [O] [PATCH] Change to org-src-preserve-indentation documentation
Hello,
John Hendy jw.he...@gmail.com writes:
Per some other discussions on the mentioned variable, I added a bit
more information to org.texi to help other users find it's
documentation in the manual.
Thank you for the patch. It is certainly better than what we have
actually.
Some comments follow.
-This variable is especially useful for tangling languages such as
+By default, the value is @code{nil}, which means that whitespace characters
will be
+collapsed upon exporting/tangling, according to the value of
I think exporting or tangling is better than exporting/tangling, but
I'm no native speaker.
Also, I'm not sure if collapsed is very clear. During export, when the
source block is evaluated, it is removed from the buffer and, maybe,
inserted back. At this point, if `org-src-preserve-indentation' is nil,
every line is indented back to the same column as it was before. Tabs
can appear in the process.
If `org-src-preserve-indentation' is nil, global indentation is lost,
but the local one is preserved. Since no indentation happens, tabs
cannot appear in the process.
+@code{org-edit-src-content-indentation}. If set to @code{t}, code
In Texinfo, sentences have to end with two spaces. Also, the variable
doesn't need to be set to the symbol t, as any value but nil will
achieve the same result. So the sentence could start with something
like :
When non-nil, code blocks...
+blocks will be exported/tangled with whitespace preserved, exactly as they
exported or tangled, maybe
+appear in the org buffer. This variable is especially useful for
tangling languages such as
It should be Org, not org. And two spaces are required.
Regards,
--
Nicolas Goaziou
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Hello, Bastien b...@gnu.org writes: Yes, that'd be nice, thanks. Then it would be good to define precise specifications for it. For example, without a region, and not at an example block, it would probably turn the current line into a fixed-width area line. But that doesn't make sense if the line is in a verbatim area, e.g., an example block. An error could be returned then. Region handling is a bit more complex. What happens if the region doesn't start or end at the beginning of a line ? What happens if the region contains both a fixed-width area and regular lines ? Would you have any ideas about it? Regards, -- Nicolas Goaziou
Re: [O] Strange behavior with auto-fill
Hello, Leo Alekseyev dnqu...@gmail.com writes: I've been observing a very annoying behavior with auto fill; it persist in the latest org from git, as well as the version shipped with Emacs 24.3 for OS X. It is a feature. See `adaptive-fill-regexp'. You can set it to nil. Note that it will also happen in some other modes (e.g. Text mode). Regards, -- Nicolas Goaziou
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: For example, without a region, and not at an example block, it would probably turn the current line into a fixed-width area line. Yes. But that doesn't make sense if the line is in a verbatim area, e.g., an example block. An error could be returned then. Yes, a user-error. Region handling is a bit more complex. What happens if the region doesn't start or end at the beginning of a line ? Then we fix the region to start at the beginning of line before the beginning (or point), and at the beginning of line before the end (or point). What happens if the region contains both a fixed-width area and regular lines ? The same than when there is no fixed-width area: we convert the region into fixed-width. Then converting back to a regular area will be easy enough, and users are more likely to want this IMHO. Would you have any ideas about it? Here you go. Thanks in advance for your work on this! -- Bastien
Re: [O] ob-clojure: presentation of map structures?
On Sun, 2014-02-02 at 01:42 -0500, Phill Wolf wrote:
Floundering among the options, I tried :results value pp. It yielded
this:
: {\Pluto\ 5,\n \Plattsburgh\ 4,\n \Philadelphia\ 3,\n
\Sankt-Peterburg\ 2,\n \Paris\ 1,\n \Peru\ 0}\n
pprint's good intentions are evident, but they collided with a
superior force.
There was a discussion of this at the Clojure google group:
https://groups.google.com/d/msg/clojure/gthjNWfAWKo/aKwuqh2qx68J
The tabularization problem was resolved, but the pp of the map behavior
is not changed. I tried a few permutations of :results options, and did
not get close to the Clojure pprint function.
The org manual says the pp option is This
option currently supports Emacs Lisp, Python, and Ruby. E.g., :results
value pp.
Regards,
Greg
Re: [O] orgtbl-to-sqlinsert
Aloha Thierry, Thierry Banel tbanelweb...@free.fr writes: Hi Thomas. I don't understand this behavior yet. But here is a workaround: try the #+ORGTBL: SEND feature: 1- Add a #+ORGTBL: SEND line 2- Add a BEGIN RECEIVE ORGTBL block 3- Type C-c C-c with cursor on the first pipe of the table --8---8-- #+ORGTBL: SEND faraway orgtbl-to-sqlinsert :sqlname foo :fmt (1 %s) | one | two| |-+| | 1 | Buckle | | 2 | Shoe | | 3 | Open | | 4 | Door | ;; BEGIN RECEIVE ORGTBL faraway BEGIN TRANSACTION; INSERT INTO foo( one, two ) VALUES ( 1 , 'Buckle' ); INSERT INTO foo( one, two ) VALUES ( 2 , 'Shoe' ); INSERT INTO foo( one, two ) VALUES ( 3 , 'Open' ); INSERT INTO foo( one, two ) VALUES ( 4 , 'Door' ); COMMIT; ;; END RECEIVE ORGTBL faraway Yes, this works. Perhaps the table needs to be processed before it is passed to orgtbl-to-sqlinsert? Note that =orgtbl-to-sqlinsert= takes advantage of org-mode's applying the formatting to each cell /before/ checking for a line-formatting function. The header line itself and sectioning line are suppressed with the settings : :hlfmt (lambda (lst) (setq firstheader nil)) : :hline nil : :remove-nil-lines t I don't fully understand what this means, but it appears to address the table header. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] org-mobile-pull with files in multiple directories?
Hi all, I'm trying to figure out how to get org-mobile-pull to work for me. I want to be able to edit files from multiple directories via MobileOrg, e.g.: ~/org/TODO.org ~/work/TODO.org ~/my-project/TODO.org ~/org/notes/my-hobby.org I have a sync-org shell-script which copies them into a temporary directory, and then runs the following via emacs --batch --eval: (let ((org-mobile-files '(/path/to/tmpdir))) (require 'org-mobile nil 'noerror) (org-mobile-push)) org-mobile-directory is set to an scpx:... path so that the push happens via TRAMP to my public server. This all works fine. However, when I run org-mobile-pull, edits to ~/org/notes/my-hobby.org fail, and instead an error is appended to the file pointed to by `org-mobile-inbox-for-pull', e.g. * Heading not found on level 1: journal F(edit:body) [[olp:my-hobby.org:journal][a heading]] I have examined the code in org-mobile.el, and I'm pretty sure that this is due to org-mobile-locate-entry containing the following code: ... (setq file (expand-file-name file org-directory)) (setq path (mapcar 'org-link-unescape (org-split-string path /))) (org-find-olp (cons file path)) org-directory is ~/org, so it only succeeds in locating files which live directly in ~/org. Is this a known limitation, and if so, can anyone suggest a good way to work around it? Thanks! Adam
[O] bug#5753: something, something, org-mode, shift-select, something
Lennart Borgman lennart.borg...@gmail.com writes: Shift-select in cua-mode does not work in org-mode although org-replace-disputed-keys is t, org-disputed-keys are set for shift arrow keys and org-support-shift-select is always Is this problem still present in Emacs 24.3? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/
[O] mis-alignment in org-tables with Tibetan characters
Hello all, I've made an org table that includes both English and Tibetan characters, and the columns don't line up. I suspect this is because of the way Tibetan characters are displayed - they stack below and above each other, making the characters vertically taller than the English characters. You can see this same problem in the text pasted below, it behaves the same way in an org table. Any way to solve this problem? Perhaps somehow changing the height of all the text in the table? Thanks! | རྐུ་བ་| rku-ba | བརྐུས་པ་ | brkus-pa| བརྐུ་བ་ | brku-ba | རྐུས་ | rkus| | གསོ་བ་ | gso-ba | གསོས་པ་ | gsos-pa | གསོ་བ་ | gso-ba | གསོས་ | gsos| | འཆོར་བ་ | 'chor-ba | ཤོར་བ་ | shor-ba | འཆོར་བ་ | 'chor-ba |
Re: [O] mis-alignment in org-tables with Tibetan characters
Screenshot: http://oi59.tinypic.com/lz893.jpg On Sun, Feb 2, 2014 at 7:29 PM, Steffan Iverson steffan.iver...@gmail.comwrote: Hello all, I've made an org table that includes both English and Tibetan characters, and the columns don't line up. I suspect this is because of the way Tibetan characters are displayed - they stack below and above each other, making the characters vertically taller than the English characters. You can see this same problem in the text pasted below, it behaves the same way in an org table. Any way to solve this problem? Perhaps somehow changing the height of all the text in the table? Thanks! | རྐུ་བ་| rku-ba | བརྐུས་པ་ | brkus-pa| བརྐུ་བ་ | brku-ba| རྐུས་ | rkus| | གསོ་བ་ | gso-ba | གསོས་པ་ | gsos-pa | གསོ་བ་ | gso-ba | གསོས་ | gsos| | འཆོར་བ་ | 'chor-ba | ཤོར་བ་ | shor-ba | འཆོར་བ་ | 'chor-ba |
