Re: [O] Is there a new method to set no line break when export to plain text
Hello, windy writes: > Start from Org-mode 8, the plain text export is fixed width with line > break and it is very unconvenient to show in the text edit like libreoffice > and so on. > > I also try (setq org-ascii-text-width 10) in my .emacs but the title > and the author align to the middle in 10, it is very ugly and . > > I don't know why org-mode 8 start to fix width of plain text with > line break, How I conquer it ? Is there anyone have good idea? You can add a paragraph filter (see `org-export-filter-paragraph-functions') that removes newline characters from the output. Regards, -- Nicolas Goaziou
Re: [O] Bug: Blocks spill their background color [8.3beta (release_8.3beta-1145-g45555d @ /home/simen/src/org-mode/lisp/)]
Hello, Simen Heggestøyl writes: > When positioned at the end of an outline node, blocks will spill their > background color (defined by the `org-block-end-line' face) when the > node is folded. > > To see this, paste the following lines into an Org buffer, and make > sure that a background color is set for `org-block-end-line': > > > * One > #+BEGIN_SRC > #+END_SRC > This is OK, it won't spill. * Two This will spill. > #+BEGIN_SRC > #+END_SRC > * Three > Spill is gone now. > > > When the node "Two" is folded, the background color will still be > painted all the way to the right fringe (as can be viewed here: > http://folk.uio.no/simenheg/org-spill.png). This becomes especially > prominent when using a theme that sets a background color for > `org-block-end-line', for instance the built-in Leuven theme. AFAICT, there's not much we can do about it. It seems to be inherent to how overlays and text properties work. You can insert a blank line after your second block. Regards, -- Nicolas Goaziou
Re: [O] [bug, org-table] new hline doesn't update formula
Rasmus writes: > Nicolas Goaziou writes: >>> Consider this example: >>> >>> |---+---+---| >>> | a | b | c | >>> | d | e | f | >>> |---+---+---| >>> | 1 | 2 | 3 | >>> | 4 | 5 | 6 | >>> |---+---+---| >>> | 5 | 7 | 9 | >>> #+TBLFM: @5=vsum(@II..@III) [...] >> What should happen to the formula if hline is inserted between |1|2|3| >> and |4|5|6|? > > Good question. I'm not sure. While not necessarily the most obvious I > think in that case the formula should be unchanged. But it's not > obvious. Another tricky example | 1 | || | 2 | | 3 | | 4 | || | 5 | || | 14 | #+TBLFM: @6=vsum(@I..@III) What if we insert a hline between |3| and |4|? I assume it should become "@I..@". Yet, the difference between it and the case before is subtle, and hard to explain. That leads me to the next question: should we really mess with this? Regards,
Re: [O] A Microsoftesque detail in org
I agree with Rasmus' position. Just because the org format is plain text, doesn't mean the Emacs keybindings have to act identically to, say, Notepad. Otherwise, what's Emacs for? Similarly, I don't expect TAB to insert tabs into an org-mode document. While there can be a bit of a culture shock getting used to org's "do the useful thing" as opposed to "do the literal thing", I think it's an advantage of the system, not a disadvantage. Headers are sacred in org-mode, so breaking headers with RET seems suboptimal when there's vastly more things you'd care about. Similarly in tables, or drawers or timestamps or... That said, it would be nice to have some sort of customization variable to allow the literal behaviour, but set by default to the current behaviour (similar to org-support-shift-select). BrettW On Mon, May 18, 2015 at 7:15 AM, Rasmus wrote: > Hi Jarmo, > > Jarmo Hurri writes: > > > Rasmus writes: > > >> With your behavior you can (i) break the TODO tag; (ii) break the > cookie; > >> (iii) break the tag. At least (i) and (ii) are quite destructive. > > > > I am not sure what you mean, since a single undo will always heal the > > line again, regardless of where you break it. > > Sure. But that seems orthogonal to the problem at hand. Re (i): Assume > TODO is keyword. We don't know that TO is. Re (ii): [#B] is a cookie. > [#B is not. (iii) iii :tag: is a tag :ta is not. The editor should not > easily produce invalid syntax. > > In any case it's very easy to rebind keys in a hook. If you write a > org.texi patch on how to get purist keybindings we can add it. > > > I am a BIG fan of the Org mode slogan "Your life in plain text." The > > power of plain text has been demonstrated over and over again. You can > > run text manipulating commands on it, you can process it with a large > > array of different programming languages. > > Nobody is disputing that. > > > An undo is a basic text editing feature that everyone should > > know. Reassigning non-standard behaviour to the return key is - in my > > opinion - against the ideology. > > I see that you use Gnus. Did you by any change use RET to open the > article? It's bound to gnus-summary-scroll-up. > > In Emacs25, or maybe even before, RET in at least lisp mode started to > indent automatically via electric-indent-mode. Are you against this? > > What I will agree on is that it would be better if Org used more > "standard" mechanism and e.g. cleverly hooked newline. However, Org > targets a number of versions of Emacs (ATM: 23-25), making this hard. > > >> The attached patch re-enables breaks in region four of > >> org-complex-heading-regexp, i.e. from the cookie up to tags. A quick > >> test suggests it works nicely. > >> > >> WDYT? > > > > Given enough time, I could come up with a situation where I would run a > > keyboard macro in which I would expect the return key to break the line, > > regardless of where I was on that line (in a tag or whatever). > > In that case there's C-o C-e or M-x newline... > > > I am a very minor player in this game, but I would really, _really_ like > > Org to remain as true to it's slogan as possible. > > I'm still don't see this point. There's Org, "the format", which should > ideally be easy to use in any editor (I wrote a basic syntax parser for > texworks). It's plaintext. Then there's org-mode, the principal editor > of Org. It supposed to be a nice environment for composing text. > > —Rasmus > > -- > This is the kind of tedious nonsense up with which I will not put > > >
Re: [O] Export org file to Mardown (github flavour)
Kaviraj Kanagaraj wrote: > I am facing a problem with converting org file to markdown. While > converting i find html in it. but I want to be in github flavour markdown. > Any ideas??. > I have found that org-gfm.el would help.. But I dont know how to setup > custom backend for markdown export.. That's certainly not the sexiest answer, but you might want to take a look at Pandoc. Best regards, Seb -- Sebastien Vauban
Re: [O] get name of source block
Andreas Leha wrote: > for quite some time I've had the following in my .emacs: > > ;; This Snippet returns the name of the current source block. > ;; An elisp block to simplify the =:prologue= definition. > ;; Author: Eric Schulte > ;; It is useful to insert the debug message 'Entering foo()' as output. > ;; For R code blocks, enable it with this line: > ;; #+PROPERTY: header-args:R :session *R* :prologue (format "print(\"entering > %s\")" (get-current-name)) > (defun get-current-name () > (or (when org-babel-current-src-block-location > (save-excursion > (goto-char org-babel-current-src-block-location) > (while (and (forward-line -1) > (looking-at org-babel-multi-line-header-regexp))) > (when (looking-at org-babel-src-name-w-name-regexp) > (org-no-properties (match-string 3) > "")) > > That had stopped working during export (my main use-case) a few weeks > back. Now, org-babel-src-name-w-name-regexp is gone from the source > so that this snippet is completely broken. > > I would like to again have the name of the source block displayed > during execution of src blocks. Is there a function in org already? > And if not, how would the proposed function look like so that it works > during export as well? Seems to come from: * 49a656a ob-core: Remove `org-babel-src-name-w-name-regexp' (2015-05-01) * cec47a6 ob-core: Change `org-babel-named-src-block-regexp-for-name' signature (2015-05-01) Maybe looking at the diff would give you the way to translate the regexp into some newer form? Best regards, Seb -- Sebastien Vauban
Re: [O] A Microsoftesque detail in org
Brett Witty writes: > I agree with Rasmus' position. Just because the org format is plain text, > doesn't mean the Emacs keybindings have to act identically to, say, > Notepad. Otherwise, what's Emacs for? Similarly, I don't expect TAB to > insert tabs into an org-mode document. > > While there can be a bit of a culture shock getting used to org's "do the > useful thing" as opposed to "do the literal thing", I think it's an > advantage of the system, not a disadvantage. Headers are sacred in > org-mode, so breaking headers with RET seems suboptimal when there's vastly > more things you'd care about. Similarly in tables, or drawers or timestamps > or... OK - this makes sense. But instead of jumping to the next line, a splitting of the header into two would make more sense, keeping the correct syntax. Jumping to the next line is actually counter intuitive, as this is pure movement. Cheers, Rainer > > That said, it would be nice to have some sort of customization variable to > allow the literal behaviour, but set by default to the current behaviour > (similar to org-support-shift-select). > > BrettW > > On Mon, May 18, 2015 at 7:15 AM, Rasmus wrote: > >> Hi Jarmo, >> >> Jarmo Hurri writes: >> >> > Rasmus writes: >> >> >> With your behavior you can (i) break the TODO tag; (ii) break the >> cookie; >> >> (iii) break the tag. At least (i) and (ii) are quite destructive. >> > >> > I am not sure what you mean, since a single undo will always heal the >> > line again, regardless of where you break it. >> >> Sure. But that seems orthogonal to the problem at hand. Re (i): Assume >> TODO is keyword. We don't know that TO is. Re (ii): [#B] is a cookie. >> [#B is not. (iii) iii :tag: is a tag :ta is not. The editor should not >> easily produce invalid syntax. >> >> In any case it's very easy to rebind keys in a hook. If you write a >> org.texi patch on how to get purist keybindings we can add it. >> >> > I am a BIG fan of the Org mode slogan "Your life in plain text." The >> > power of plain text has been demonstrated over and over again. You can >> > run text manipulating commands on it, you can process it with a large >> > array of different programming languages. >> >> Nobody is disputing that. >> >> > An undo is a basic text editing feature that everyone should >> > know. Reassigning non-standard behaviour to the return key is - in my >> > opinion - against the ideology. >> >> I see that you use Gnus. Did you by any change use RET to open the >> article? It's bound to gnus-summary-scroll-up. >> >> In Emacs25, or maybe even before, RET in at least lisp mode started to >> indent automatically via electric-indent-mode. Are you against this? >> >> What I will agree on is that it would be better if Org used more >> "standard" mechanism and e.g. cleverly hooked newline. However, Org >> targets a number of versions of Emacs (ATM: 23-25), making this hard. >> >> >> The attached patch re-enables breaks in region four of >> >> org-complex-heading-regexp, i.e. from the cookie up to tags. A quick >> >> test suggests it works nicely. >> >> >> >> WDYT? >> > >> > Given enough time, I could come up with a situation where I would run a >> > keyboard macro in which I would expect the return key to break the line, >> > regardless of where I was on that line (in a tag or whatever). >> >> In that case there's C-o C-e or M-x newline... >> >> > I am a very minor player in this game, but I would really, _really_ like >> > Org to remain as true to it's slogan as possible. >> >> I'm still don't see this point. There's Org, "the format", which should >> ideally be easy to use in any editor (I wrote a basic syntax parser for >> texworks). It's plaintext. Then there's org-mode, the principal editor >> of Org. It supposed to be a nice environment for composing text. >> >> —Rasmus >> >> -- >> This is the kind of tedious nonsense up with which I will not put >> >> >> -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] javascript:; Re: Is there a new method to set no line break when export to plain text
Thanks for you reply I am sorry for that but how to set the variable ? I totally know nothing about emacs elisp. maybe I must to learn it in some day. I try (setq org-export-filter-paragraph-functions nil) seems no working 在2015年05月18 15时18分, "Nicolas Goaziou"写道: Hello, windy writes: > Start from Org-mode 8, the plain text export is fixed width with line > break and it is very unconvenient to show in the text edit like libreoffice > and so on. > > I also try (setq org-ascii-text-width 10) in my .emacs but the title > and the author align to the middle in 10, it is very ugly and . > > I don't know why org-mode 8 start to fix width of plain text with > line break, How I conquer it ? Is there anyone have good idea? You can add a paragraph filter (see `org-export-filter-paragraph-functions') that removes newline characters from the output. Regards, -- Nicolas Goaziou
Re: [O] [bug] TODO [/] cookie not updating if list has inline task
On Sunday, 17 May 2015 at 21:44, Rasmus wrote: > Eric S Fraga writes: > >> I'm not sure I understand what is misleading about the above? The note >> is indeed intended to belong to the first item on the list. > > The misleading part, IMO, is that it is not obvious whether the > inlinetasks belong to the list item or not. Normally something that > belong to the item in indented, which is not possible here. I guess, for me, the "inline" part of the name indicates that this element is always part of the surrounding element? Of course, this doesn't mean the parser treats it as such and it looks like it doesn't. >> However, we are starting to see that inline tasks are indeed a bit of >> kludge and impact on org structures significantly so maybe we can remove >> this capability once inline annotations, as discussed in another thread, >> are implemented? > > FWIW, I did not like the syntax Nicolas suggested in that thread. It > reminded me too much of *XML (which is also true with inlinetasks BTW). > [I, did, however, only add a star to the thread rather than replying]. I'm not too bothered with the syntax. I can get used to (almost) anything. However, as I and others have commented in the inline annotations thread, there is some worry about the syntax become too overbearing in the attempt to have it do too much. Back to inline tasks in lists, for the checkbox use case, I can easily use special environments instead of inline tasks. In general, however, I would still like to be able to use inline tasks within lists. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1136-g0e7062
[O] ox-bibtex using the x.bib in different path
Hi, everyone, I am using org-plus-contrib/ox-bibtex.el to combine bibtex output in html and latex. When I use a same x.bib like: #+BIBLIOGRAPHY: x unsrturl it works well But if I use a x.bib at different path and the src like: #+BIBLIOGRAPHY: /home/name/dropbox/x unsrturl or #+BIBLIOGRAPHY: $HOME/dropbox/x unsrturl it shows "Executing bibtex2html failed" As the link show: http://emacs.stackexchange.com/questions/3375/loading-bibtex-file-in-org-mode-file , we shoud hack the ox-bibtex.el and change the TMPDIR. Is anyone have a hacked ox-bibtex.el or any idea to the problem? I am using the emacs24.4.1 under ubuntu 14.04, the org-mode version is 8.2.10
Re: [O] A Microsoftesque detail in org
Rainer M Krug writes: > OK - this makes sense. But instead of jumping to the next line, a > splitting of the header into two would make more sense, keeping the > correct syntax. That is literally what my patch does IF you are in region four (more or less) of org-complex-heading-regexp. > Jumping to the next line is actually counter intuitive, as this is pure > movement. It's what it does in tables (most of the time). What would be better? —Rasmus -- However beautiful the theory, you should occasionally look at the evidence
Re: [O] [bug, org-table] new hline doesn't update formula
Nicolas Goaziou writes: > That leads me to the next question: should we really mess with this? Maybe not. Perhaps there's a reason for the current implementation. —Rasmus -- . . . It begins of course with The Internet. A Net of Peers
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou writes: > Hello, > > Eric Abrahamsen writes: > >> We're just talking about annotations-plus-metadata here, right? Not >> actual in-text TODOs? > > I'm not convinced in-text TODOs would be interesting, because they would > make building the agenda an order of magnitude slower. IMO you need not. But perhaps I'm extrapolating from my use-case. I guess it would be inconsistent not to include it. > My concerns about syntax are: > > - it should not cripple readability of the document > - it needs to mark both objects (inline) and elements, even multiple > elements (e.g., two paragraphs) > > In particular, the last point is difficult to handle for the parser. > Indeed, any syntax is either contained in a paragraph or stops one, so > this syntax should be a bit "outside" the parser. > > Anyway, here we go for another proposal. > > In-text markers: > > [@:ID]...[@] While we have opening and closing tags for formatting (e.g. bold), I dislike the above. It seems like asking for trouble; it would seem one could easily loose track and delete one end of the tag and not the other. IOW: [@:ID1]... [@:ID2]...[@]...[@] seems like asking for trouble as I could easily delete an opening pair. But note that I am more interested in an inline noting/todo functionality as opposed to annotation functionality. Also, for annotation, would it not be annoying, in review session say, to have the notes so "far away" from the text? Perhaps not with the right helping tools. —Rasmus > ID is expected to be unique, and consists of alphanumeric characters > only. Markers are allowed anywhere standard syntax is (e.g., paragraphs, > verse blocks, table cells, captions, parsed keyword). > > Both makers have to be found within the same section, i.e, one cannot > annotate across headlines. Annotations can be nested but cannot > partially overlap. > > From the parser point of view, Element can recognize such markers, but > will not be able to "associate" them since they exist above structure of > the document. > > One important limitation is that example or source blocks cannot be > annotated, Therefore I also suggest creating a new affiliated keyword, > > #+ANNOTATE: ID > > which will annotate the whole element it is applied to. > > Some examples: > > [@:1]Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do > eiusmod > tempor incididunt ut labore et [@:2]dolore magna[@] aliqua. > > Ut enimad minim veniam, quis nostrud exercitation ullamco laboris nisi > ut aliquip ex ea commodo consequat.[@] > > #+ANNOTATE: foo > #+BEGIN_SRC emacs-lisp > (+ 1 1) > #+END_SRC > > Then references are collected in a dedicated section, much like > footnotes (e.g., `org-annotation-section'), although it cannot be nil. > > Annotations start at column 0 > > [@:ID:AUTHOR-ID] OTHER-AUTHOR-ID > CONTENTS > > where: > > - ID obviously refers to in-text markers' ID, > > - AUTHOR-ID consists of word and blank characters only. If empty, it >may default to `user-login-name'. > > - OTHER-AUTHOR-ID is also optional. It is meant for empty contents. >During export, it could be possible to select annotation from >a single source, e.g., > > #+OPTIONS: @:student1 > > - CONTENTS consists of either comments and non-comments. Any >non-comment is considered as data to replace (if in-text markers are >not sticked to each other), or insert (when they are) during export. > >Comments will be displayed as a conversation thread by a special >function in "org-annotate.el". > > This syntax allows to copy annotation from another author, e.g. > >[@:1:teacher] ># This is wrong, it should be "foo". >foo > >[@:1:student1] teacher > >[@:2:teacher] ># Please reformulate. > >[@:2:student1] ># What about "bar"? >bar > > Timestamps, if needed, can be inserted in comments. > > WDYT? -- Enough with the bla bla!
Re: [O] Display :PROPERTIES: drawers?
M-x org-version: Org-mode version 8.2.10 (8.2.10-40-gc763fa-elpa @ ~/.emacs.d/elpa/org-20150511/) But I'm looking straight at the on-line manual, section "Export Options," 12.3, and there is no "prop: Toggle inclusion of property drawers, or list properties to include (‘org-export-with-properties’)." I'm guessing this is supposed to be an #+OPTIONS thing, right? On Sun, May 17, 2015 at 11:36 PM, Thomas S. Dye wrote: > Then it might be a version issue. I'm looking at Org-mode version > 8.3beta (release_8.3beta--gf8d1d3 @ > /Users/dk/.emacs.d/src/org-mode/lisp/). > > What version are you using? > > All the best, > Tom > > Lawrence Bottorff writes: > > > Sorry, not seeing any > > > > prop: Toggle inclusion of property drawers, or list properties to include > > (‘org-export-with-properties’). > > > > in 12.3 (online manual). Tried > > > > #+OPTIONS: prop:t > > > > in my buffer and it didn't work either. > > > > On Sun, May 17, 2015 at 7:08 PM, Thomas S. Dye wrote: > > > >> Lawrence Bottorff writes: > >> > >> > Sorry, but I can't find any reference to org-export-with-properties . > >> Where > >> > might it be mentioned? > >> > >> See 12.3 Export settings, > >> > >> > >> > , > >> | ‘prop:’ Toggle inclusion of property drawers, or list properties > to > >> include > >> | (‘org-export-with-properties’). > >> > >> > ` > >> > >> hth, > >> Tom > >> > >> -- > >> Thomas S. Dye > >> http://www.tsdye.com > >> > > Sorry, not seeing any > > > > prop: Toggle inclusion of property drawers, or list properties to > > include (‘org-export-with-properties’). > > > > in 12.3 (online manual). Tried > > > > #+OPTIONS: prop:t > > > > in my buffer and it didn't work either. > > > > On Sun, May 17, 2015 at 7:08 PM, Thomas S. Dye wrote: > > > > Lawrence Bottorff writes: > > > > > Sorry, but I can't find any reference to > > org-export-with-properties . Where > > > might it be mentioned? > > > > See 12.3 Export settings, > > > > > > , > > > > | ‘prop:’ Toggle inclusion of property drawers, or list properties > > to include > > | (‘org-export-with-properties’). > > > > ` > > > > > > hth, > > Tom > > > > -- > > Thomas S. Dye > > http://www.tsdye.com > > > > > > > > -- > Thomas S. Dye > http://www.tsdye.com >
Re: [O] get name of source block
Hi Sebastien, Sebastien Vauban writes: > Andreas Leha wrote: >> for quite some time I've had the following in my .emacs: >> >> ;; This Snippet returns the name of the current source block. >> ;; An elisp block to simplify the =:prologue= definition. >> ;; Author: Eric Schulte >> ;; It is useful to insert the debug message 'Entering foo()' as output. >> ;; For R code blocks, enable it with this line: >> ;; #+PROPERTY: header-args:R :session *R* :prologue (format >> "print(\"entering %s\")" (get-current-name)) >> (defun get-current-name () >> (or (when org-babel-current-src-block-location >> (save-excursion >> (goto-char org-babel-current-src-block-location) >> (while (and (forward-line -1) >> (looking-at org-babel-multi-line-header-regexp))) >> (when (looking-at org-babel-src-name-w-name-regexp) >> (org-no-properties (match-string 3) >> "")) >> >> That had stopped working during export (my main use-case) a few weeks >> back. Now, org-babel-src-name-w-name-regexp is gone from the source >> so that this snippet is completely broken. >> >> I would like to again have the name of the source block displayed >> during execution of src blocks. Is there a function in org already? >> And if not, how would the proposed function look like so that it works >> during export as well? > > Seems to come from: > > * 49a656a ob-core: Remove `org-babel-src-name-w-name-regexp' Goaziou> (2015-05-01) > * cec47a6 ob-core: Change `org-babel-named-src-block-regexp-for-name' > signature (2015-05-01) > > Maybe looking at the diff would give you the way to translate the regexp > into some newer form? > > Best regards, > Seb Yes, I was lazy and following the change to `org-babel-named-src-block-regexp-for-name' is easy enough. But how does that solve my first problem? During export (and preview (C-c C-v v)) the code block name is not displayed. Here is an expample: --8<---cut here---start->8--- #+PROPERTY: header-args:R :session *testR* :prologue (format "print(\"entering %s\")" (get-current-name)) * Setup:noexport: #+begin_src emacs-lisp :results none (defun get-current-name () (or (when org-babel-current-src-block-location (save-excursion (goto-char org-babel-current-src-block-location) (while (and (forward-line -1) (looking-at org-babel-multi-line-header-regexp))) (when (looking-at (org-babel-named-src-block-regexp-for-name)) (org-match-string-no-properties 9 "")) (message (get-current-name)) #+end_src * Test echo name during export Execute this source block (C-c C-c) and look into *testR*. There should be a message "entering testname". Export this file and look into *testR*. The message is "entering ". #+name: testname #+begin_src R 1:10 #+end_src --8<---cut here---end--->8--- Thanks, Andreas
Re: [O] A Microsoftesque detail in org
Rasmus writes: > Rainer M Krug writes: > >> OK - this makes sense. But instead of jumping to the next line, a >> splitting of the header into two would make more sense, keeping the >> correct syntax. > > That is literally what my patch does IF you are in region four (more > or less) of org-complex-heading-regexp. Sorry - I did not look into the patch - but that sounds perfect. > >> Jumping to the next line is actually counter intuitive, as this is >> pure movement. > > It's what it does in tables (most of the time). What would be better? For me, tables area a slightly different story, as they can not contain line breaks. OK - you could argue headers neither. I think you got me there. But the syntax in a table is more "abstract" then in a straight header. Is you have priorities, tags, ... it is different, story. But as you are asking, one more consistent possibility for tables would be to *split* the cell where the cursor sits, (as in normal text) and create a new empty row below the one the cursor is in with the cell containing the remainder of the cell above. So: | test 1 | re | t | | test 2 | a | b | | test 3 | c | d | with cursor in the space in "test 2" would become | test 1 | re | t | | test 2 | a | b | | 2 || | | test 3 | c | d | But I would not suggest due to the table nature. Cheers, Rainer > > —Rasmus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Export org file to Mardown (github flavour)
Hello, Sebastien Vauban writes: > Kaviraj Kanagaraj wrote: >> I am facing a problem with converting org file to markdown. While >> converting i find html in it. but I want to be in github flavour markdown. >> Any ideas??. >> I have found that org-gfm.el would help.. But I dont know how to setup >> custom backend for markdown export.. > > That's certainly not the sexiest answer, but you might want to take > a look at Pandoc. What's wrong with (require 'ox-gfm)? Regards, -- Nicolas Goaziou
Re: [O] javascript:; Re: Is there a new method to set no line break when export to plain text
windy writes: > I am sorry for that but how to set the variable ? I totally know > nothing about emacs elisp. > > maybe I must to learn it in some day. I try (setq > org-export-filter-paragraph-functions nil) seems no working Something like this (defun my-ascii-unfill-paragraph (text backend info) (and (eq backend 'ascii) (replace-regexp-in-string "\n *" " " text))) (add-to-list 'org-export-filter-paragraph-functions #'my-ascii-unfill-paragraph) Regards,
Re: [O] get name of source block
Hello, Andreas Leha writes: > During export (and preview (C-c C-v v)) the code block name is not > displayed. See `org-babel-exp-code-template'. Regards, -- Nicolas Goaziou
Re: [O] Marking/highlighting text temporarily
Rasmus writes: > While we have opening and closing tags for formatting (e.g. bold), I > dislike the above. It seems like asking for trouble; it would seem one > could easily loose track and delete one end of the tag and not the other. > IOW: [@:ID1]... [@:ID2]...[@]...[@] seems like asking for trouble as I > could easily delete an opening pair. We can implement a function in org-annotate.el to remove an annotation. You don't need to do it by hand. > But note that I am more interested in an inline noting/todo functionality > as opposed to annotation functionality. Inline noting is Text[@:1][@] * Annotations [@:1:] My note. I don't know what is a TODO functionality since you suggest to not make it appear in the agenda. > Also, for annotation, would it not be annoying, in review session say, to > have the notes so "far away" from the text? Perhaps not with the right > helping tools. Again, not with proper tooling, e.g, remote editing like footnotes. Regards,
Re: [O] A Microsoftesque detail in org
Titus von der Malsburg writes: > On 2015-05-17 Sun 14:15, Rasmus wrote: With your behavior you can (i) break the TODO tag; (ii) break the cookie; (iii) break the tag. At least (i) and (ii) are quite destructive. >>> >>> I am not sure what you mean, since a single undo will always heal >>> the line again, regardless of where you break it. >> >> Sure. But that seems orthogonal to the problem at hand. Re (i): Assume >> TODO is keyword. We don't know that TO is. Re (ii): [#B] is a cookie. >> [#B is not. (iii) iii :tag: is a tag :ta is not. The editor should not >> easily produce invalid syntax. > > I disagree with that last statement. I’m not aware of any Emacs mode > (or any other text editor for that matter) that prevents me from > producing invalid syntax. A text editor preventing invalid syntax is > actually not even desirable because the path from one syntactically > valid state of the document to the next often leads through invalid > states. If you really want to prevent temporarily invalid documents, > the result is going to be some kind of GUI application, not a text > editor. While that may be a valid solution for some people, it is > certainly not the Emacs way of doing things. Exactly! I would prefer that by default there is no "intelligence" in the return key, but more intelligence can be added as an option. (The problem with Microsoft programs is exactly the fact that too much "intelligence" is the default.) I leave it to the wiser men to decide. Over and out from me. Jarmo
Re: [O] Export org file to Mardown (github flavour)
Nicolas Goaziou wrote: > Sebastien Vauban writes: > >> Kaviraj Kanagaraj wrote: >>> I am facing a problem with converting org file to markdown. While >>> converting i find html in it. but I want to be in github flavour markdown. >>> Any ideas??. >>> I have found that org-gfm.el would help.. But I dont know how to setup >>> custom backend for markdown export.. >> >> That's certainly not the sexiest answer, but you might want to take >> a look at Pandoc. > > What's wrong with (require 'ox-gfm)? I guess I read too quickly... Best regards, Seb -- Sebastien Vauban
Re: [O] A Microsoftesque detail in org
On 18 May 2015, Brett Witty wrote: While there can be a bit of a culture shock getting used to org's "do the useful thing" as opposed to "do the literal thing", I think it's an advantage of the system, not a disadvantage. Headers are sacred in org-mode, so breaking headers with RET seems suboptimal when there's vastly more things you'd care about. I'm on this side too. I like the current behaviour. Bill -- William Denton ↔ Toronto, Canada ↔ https://www.miskatonic.org/
Re: [O] Marking/highlighting text temporarily
Hi, Nicolas Goaziou writes: >> But note that I am more interested in an inline noting/todo functionality >> as opposed to annotation functionality. > > Inline noting is > > > Text[@:1][@] > > * Annotations > > [@:1:] My note. My guess would be that most notes are short. For such notes, but not necessarily for longer notes, [@:NOTE] would be more convenient. Though I don't know what the "@" signifies. I think whatever is the value of #+TODO makes more sense as prefixes. I don't think it would be easy to convince coauthors of documents, who are not using Emacs, that this is something "easy" to use. I guess not many people do XML in Nano or Notepad, since keeping track of opening and closing tags is a pain. Formatting tags, e.g. *, are somehow natural and shorter. Blocks are "easy" to see. > I don't know what is a TODO functionality since you suggest to not make > it appear in the agenda. E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]". I don't need that in my agenda. >> Also, for annotation, would it not be annoying, in review session say, to >> have the notes so "far away" from the text? Perhaps not with the right >> helping tools. > > Again, not with proper tooling, e.g, remote editing like footnotes. But this is a change to the *format*, not its principal editor. —Rasmus -- Er du tosset for noge' lårt!
Re: [O] Display :PROPERTIES: drawers?
Lawrence Bottorff writes: > M-x org-version: Org-mode version 8.2.10 (8.2.10-40-gc763fa-elpa @ > ~/.emacs.d/elpa/org-20150511/) > > But I'm looking straight at the on-line manual, section "Export Options," > 12.3, and there is no "prop: Toggle inclusion of property drawers, or list > properties to include (‘org-export-with-properties’)." I'm guessing this > is supposed to be an #+OPTIONS thing, right? Yes, it is an export option. The on-line version of the manual is for the stable version, 8.2.10. This must be an option that was introduced in 8.3. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Display :PROPERTIES: drawers?
I'm running version Org-mode version 8.2.7b (8.2.7b-2-g798733-elpa @, it's not there in my version. > -Original Message- > From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org > [mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On > Behalf Of Thomas S. Dye > Sent: Monday, May 18, 2015 6:40 AM > To: Lawrence Bottorff > Cc: emacs-orgmode@gnu.org > Subject: Re: [O] Display :PROPERTIES: drawers? > > Lawrence Bottorff writes: > > > M-x org-version: Org-mode version 8.2.10 (8.2.10-40-gc763fa-elpa @ > > ~/.emacs.d/elpa/org-20150511/) > > > > But I'm looking straight at the on-line manual, section "Export Options," > > 12.3, and there is no "prop: Toggle inclusion of property drawers, or > > list properties to include (‘org-export-with-properties’)." I'm > > guessing this is supposed to be an #+OPTIONS thing, right? > > Yes, it is an export option. The on-line version of the manual is for the > stable > version, 8.2.10. This must be an option that was introduced in 8.3. > > hth, > Tom > > -- > Thomas S. Dye > http://www.tsdye.com This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you.
Re: [O] A Microsoftesque detail in org
On Mon, May 18, 2015 at 06:33:51PM +1000, Brett Witty wrote: > > While there can be a bit of a culture shock getting used to org's "do the > useful thing" as opposed to "do the literal thing", I think it's an > advantage of the system, not a disadvantage. Headers are sacred in > org-mode, so breaking headers with RET seems suboptimal when there's vastly > more things you'd care about. Similarly in tables, or drawers or timestamps > or... Actually, the headline behaviour was a shock to me as a long time user! I would have reported it if only I had some time to be more involved. As for headlines being sacred, I realise they may have a lot of meta information. However the keyword is "may", they are all optional. Even the most primary candidate for "protection", tags, are optional! As long as we can undo, I do not think any hand holding is necessary. As for Rasmus's examples of similar behaviour in other modes, I don't like them either. Unfortunately again, I'm too short on time to fix the behaviour in my setup. That said, this is just my personal opinion. As long as there ways to get the "normal" behaviour back, I'm happy. If there are no easy ways to get it back, I'll live with it. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] get name of source block
Hi Nicolas, Nicolas Goaziou writes: > Hello, > > Andreas Leha writes: > >> During export (and preview (C-c C-v v)) the code block name is not >> displayed. > > See `org-babel-exp-code-template'. > Thanks for looking into this. If I get you correctly, you are suggesting a way to have the name of the code block shown in the exported file. What I am after is to have the name of the code block shown *in the R session* during evaluation at export (to easily see where things fail). Sorry for being unclear. If your hint helps there as well, could you elaborate a bit? Thanks, Andreas
Re: [O] Display :PROPERTIES: drawers?
So this feature is on the way, it's already in a beta version, i.e., just wait? I saw a rather involved work-around on emacs.stackexchange.com, but I won't fool with it if this feature is soon to hit ELPA, which is how I get my org-mode. On Mon, May 18, 2015 at 10:35 AM, Subhan Michael Tindall < subh...@familycareinc.org> wrote: > I'm running version Org-mode version 8.2.7b (8.2.7b-2-g798733-elpa @, it's > not there in my version. > > > -Original Message- > > From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org > > [mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On > > Behalf Of Thomas S. Dye > > Sent: Monday, May 18, 2015 6:40 AM > > To: Lawrence Bottorff > > Cc: emacs-orgmode@gnu.org > > Subject: Re: [O] Display :PROPERTIES: drawers? > > > > Lawrence Bottorff writes: > > > > > M-x org-version: Org-mode version 8.2.10 (8.2.10-40-gc763fa-elpa @ > > > ~/.emacs.d/elpa/org-20150511/) > > > > > > But I'm looking straight at the on-line manual, section "Export > Options," > > > 12.3, and there is no "prop: Toggle inclusion of property drawers, or > > > list properties to include (‘org-export-with-properties’)." I'm > > > guessing this is supposed to be an #+OPTIONS thing, right? > > > > Yes, it is an export option. The on-line version of the manual is for > the stable > > version, 8.2.10. This must be an option that was introduced in 8.3. > > > > hth, > > Tom > > > > -- > > Thomas S. Dye > > http://www.tsdye.com > > > This message is intended for the sole use of the individual and entity to > which it is addressed and may contain information that is privileged, > confidential and exempt from disclosure under applicable law. If you are > not the intended addressee, nor authorized to receive for the intended > addressee, you are hereby notified that you may not use, copy, disclose or > distribute to anyone the message or any information contained in the > message. If you have received this message in error, please immediately > advise the sender by reply email and delete the message. Thank you. >
Re: [O] A Microsoftesque detail in org
Suvayu Ali writes: > As for Rasmus's examples of similar behaviour in other modes, I don't > like them either. Unfortunately again, I'm too short on time to fix the > behaviour in my setup. So far nobody has felt strongly enough about this to supply a patch, even to org.texi or, I think, worg. Here's an untested start to get rid of those pesky Microsoftesque detail in org-mode (with-eval-after-load 'org (add-hook 'org-mode-hook (defun org-keyboard-purist () (org-defkey org-mode-map (kbd "RET") nil) (mapc (lambda (key) (org-defkey org-mode-map key nil)) (list [(control return)] [(shift control return)] [(meta return)]) —Rasmus -- It was you, Jezebel, it was you
[O] \nbsp trick to get prefixed superscript to work?
I saw an earlier discussion about Emacs/org-mode superscript and subscript
behavior. My issue is I want to do a chem isotope of an element. In
standard Latex format I would do this:
$^{147}$Pm or leaving off the $ and turning on Emacs' display of UTF-8 (
C-c C-x \ ) just ^{147}Pm
but it doesn't work in either Emacs or org-mode, however
Pm^{147} does, i.e., putting the super-/subscript /after/ Pm. Also,
$^{147}Pm$ does work, although it converts the Pm into italicized text upon
export. Also
\nbsp^{147}Pm works in both Emacs and org-mode, but upon standard export to
HTML, it works in the TOC and down in the actual text, but not in the
"Contents" section (not used in Latex export).
Apparently, chemists cannot do Emacs and/or org-mode when they want to
prefix the super- bzw. sub-script without a kudge?
LB
Re: [O] Marking/highlighting text temporarily
Rasmus writes: > My guess would be that most notes are short. For such notes, but not > necessarily for longer notes, [@:NOTE] would be more convenient. This is very limited: you cannot write two paragraphs in your note. > Though I don't know what the "@" signifies. AnnoTate? > I think whatever is the value of #+TODO makes more sense as prefixes. You turn every annotation into a task. Again, this is very restrictive. > I don't think it would be easy to convince coauthors of documents, who are > not using Emacs, that this is something "easy" to use. I guess not many > people do XML in Nano or Notepad, since keeping track of opening and > closing tags is a pain. My sole focus is Emacs users, tho. > Formatting tags, e.g. *, are somehow natural and shorter. Blocks are > "easy" to see. > >> I don't know what is a TODO functionality since you suggest to not make >> it appear in the agenda. > > E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]". I > don't need that in my agenda. Since you're talking about "TODO functionality", what features would this share with regular tasks, defined with headlines or inlinetasks? > But this is a change to the *format*, not its principal editor. Do you think tables are particularly nice to write if you work outside of Org mode? There is no clause about being easy to edit from Nano in Org. Anyway, we're speaking of two different things, e.g., I think it's important to be able to mark exactly which part of the document you're annotating. [TODO: ...] cannot do that. Regards,
Re: [O] Marking/highlighting text temporarily
On Monday, 18 May 2015 at 15:16, Rasmus wrote: > Nicolas Goaziou writes: [...] >> I don't know what is a TODO functionality since you suggest to not make >> it appear in the agenda. > > E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]". I > don't need that in my agenda. Exactly. I use inlinetasks a lot for file local TODO items that are not meant to appear in my agenda. They are notes for things I need to do, typically, to finish a paper. Being able to "C-c / t" to find them all easily is great. I would expect the same functionality from any replacement. In terms of format, I also dislike opening and closing tags except for short formatting uses. I would prefer [COMMENT: this is very interesting] and [TODO: I need to update this]. Or even [[TODO:...]] to be less worried about running into problems with text use of [...]. But I think that's already been dismissed... -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1136-g0e7062
Re: [O] \nbsp trick to get prefixed superscript to work?
Lawrence Bottorff writes:
> I saw an earlier discussion about Emacs/org-mode superscript and
> subscript behavior. My issue is I want to do a chem isotope of an
> element. In standard Latex format I would do this:
>
> $^{147}$Pm or leaving off the $ and turning on Emacs' display of
> UTF-8 ( C-c C-x \ ) just ^{147}Pm
>
> but it doesn't work in either Emacs or org-mode, however
>
> Pm^{147} does, i.e., putting the super-/subscript /after/ Pm. Also,
>
> $^{147}Pm$ does work, although it converts the Pm into italicized text
> upon export. Also
>
> \nbsp^{147}Pm works in both Emacs and org-mode, but upon standard
> export to HTML, it works in the TOC and down in the actual text, but
> not in the "Contents" section (not used in Latex export).
>
> Apparently, chemists cannot do Emacs and/or org-mode when they want to
> prefix the super- bzw. sub-script without a kudge?
>
This seems to work fine for me both for latex and html (with MathJax)
export:
--8<---cut here---start->8---
* Dating with \(^{14}\)C.
Dating with \(^{14}\)C.
--8<---cut here---end--->8---
Nick
Re: [O] \nbsp trick to get prefixed superscript to work?
On Monday, 18 May 2015 at 11:43, Lawrence Bottorff wrote: > Apparently, chemists cannot do Emacs and/or org-mode when they want to > prefix the super- bzw. sub-script without a kudge? I've recently have had to start writing papers with significant amounts of chemistry in them. I simply use the mhchem package which supports all types of chemical notation... org is quite happy with it for simple entries although you may need to @@...@@ escape more complex entries. However, if you wanted something portable, i.e. that could export to other targets, then this won't help you. Sorry! -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1136-g0e7062
Re: [O] \nbsp trick to get prefixed superscript to work?
I think what Eric is referring to is:
#+latex_header: \usepackage[version=3]{mhchem}
@@latex:\ce{^{147}Pm}@@
that exports for me.
\nbsp{}^{147}Pm also seems to work, but might put an extra space in.
you might prefer \phantom{}^{147}Pm
John
---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Mon, May 18, 2015 at 12:09 PM, Eric S Fraga wrote:
> On Monday, 18 May 2015 at 11:43, Lawrence Bottorff wrote:
> > Apparently, chemists cannot do Emacs and/or org-mode when they want to
> > prefix the super- bzw. sub-script without a kudge?
>
> I've recently have had to start writing papers with significant amounts
> of chemistry in them. I simply use the mhchem package which supports
> all types of chemical notation... org is quite happy with it for simple
> entries although you may need to @@...@@ escape more complex entries.
>
> However, if you wanted something portable, i.e. that could export to
> other targets, then this won't help you. Sorry!
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1136-g0e7062
>
>
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou writes: >> My guess would be that most notes are short. For such notes, but not >> necessarily for longer notes, [@:NOTE] would be more convenient. > > This is very limited: you cannot write two paragraphs in your note. Fine whit me. For that I I have inlinetasks. >> Though I don't know what the "@" signifies. > > AnnoTate? I did not see that coming. That's a "meh" from me :) >> I think whatever is the value of #+TODO makes more sense as prefixes. > > You turn every annotation into a task. Again, this is very restrictive. I don't think so, e.g. #+TODO: DISCUSS DISAGREE | RESOLVED DROPPED And judging from the manual people are doing much more complicated stuff than that (my usage is pretty simple). > Since you're talking about "TODO functionality", what features would > this share with regular tasks, defined with headlines or inlinetasks? The tags. They are notes related to say a sentence, so you put a note at the end of a sentence. Spatial TODOs. > Anyway, we're speaking of two different things, e.g., I think it's > important to be able to mark exactly which part of the document you're > annotating. I agree they are different. > [TODO: ...] cannot do that. Its virtues are compactness, being similar to a list, being C-k friendly, and, IMO, more intuitive. –Rasmus -- There are known knowns; there are things we know that we know
Re: [O] Marking/highlighting text temporarily
Eric S Fraga writes: > On Monday, 18 May 2015 at 15:16, Rasmus wrote: >> Nicolas Goaziou writes: >>> I don't know what is a TODO functionality since you suggest to not make >>> it appear in the agenda. >> >> E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]". I >> don't need that in my agenda. > > Exactly. I use inlinetasks a lot for file local TODO items that are not > meant to appear in my agenda. They are notes for things I need to do, > typically, to finish a paper. Being able to "C-c / t" to find them all > easily is great. I would expect the same functionality from any > replacement. Would it be bad if I admit I have no idea how to use sparse trees? The remind me of Vim, except in Vim i eventually figured out that I could quit it via :q. I would probably use occur or a restricted agenda. I would want inlinetodos in my "global"/usual agenda. > In terms of format, I also dislike opening and closing tags except for > short formatting uses. I would prefer [COMMENT: this is very > interesting] and [TODO: I need to update this]. Or even [[TODO:...]] to > be less worried about running into problems with text use of [...]. I think [[TODO:]] is a link... Rasmus -- Got mashed potatoes. Ain't got no T-Bone. No T-Bone
Re: [O] Marking/highlighting text temporarily
Rasmus writes: > Fine whit me. For that I I have inlinetasks. Then it cannot even replace inlinetasks. > The tags. They are notes related to say a sentence, so you put a note at > the end of a sentence. Spatial TODOs. I still don't get it, sorry. > Its virtues are compactness, being similar to a list, being C-k friendly, > and, IMO, more intuitive. But, IMO, totally useless for general annotations. This probably means they shouldn't share the same syntax. Note I'm all for replacing inlinetasks with something else (i.e., change syntax), albeit this is no simple task. However, that was not my proposal. Regards,
Re: [O] Marking/highlighting text temporarily
Nicolas Goaziou writes: >> Fine whit me. For that I I have inlinetasks. > > Then it cannot even replace inlinetasks. Is that a goal? >> Its virtues are compactness, being similar to a list, being C-k friendly, >> and, IMO, more intuitive. > > But, IMO, totally useless for general annotations. I think "totally useless" stretching it. Two examples. [@:1] My sentence on foo [@] and something else * Annotations [@:1:Nicolas] Remember to refer to bar #+TODO: Notes/Nicolas My sentence on foo [Notes/Nicolas: Remember to refer to bar] and something else. The latter is less precise, but I would still prefer it. I guess you could add references to an endnote for long notes, which would bring it closer to killing org-inlinetasks. > This probably means they shouldn't share the same syntax. Note I'm all > for replacing inlinetasks with something else (i.e., change syntax), > albeit this is no simple task. I don't particularly care for them either. —Rasmus -- This space is left intentionally blank
Re: [O] [bug, org-table] new hline doesn't update formula
Rasmus writes: > Nicolas Goaziou writes: > >> That leads me to the next question: should we really mess with this? > > Maybe not. Perhaps there's a reason for the current implementation. Agreed. However, it seems a good opportunity to alert the user to the fact that Org didn't touch the table formulas because it doesn't know what's right or wrong and expects the user to clean up. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
[O] org-export-dispatch not bound to C-c C-e.
`org-export-dispatch' is not anymore bound to C-c C-e. Instead C-c C-e triggers `outline-show-entry'. Seems like a bug because the documentation still says that C-c C-e should launch the export menu. Tested with git master. Titus signature.asc Description: PGP signature
Re: [O] Marking/highlighting text temporarily
Hi all, Actually, having pondered this whole annotation and task business while heading home after work on the train, I think all I would like is a simple annotation scheme with no need for tasks etc. We have plenty of support for tasks with headlines. What we don't have is simple annotations. I use inlinetasks for annotations yet these are clumsy, as we have seen. What the notation for annotations should be I leave to others, especially those that might implement something. However, it should allow for hiding of annotations while editing an org buffer, it should be possible to list all annotations (sparse tree functionality), to jump from one to the next and it should provide the hooks for exporting in various ways, with customisable formatting. Just my 2¢ worth. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1147-g0e5069.dirty
Re: [O] \nbsp trick to get prefixed superscript to work?
John Kitchin wrote:
> I think what Eric is referring to is:
>
> #+latex_header: \usepackage[version=3]{mhchem}
>
> @@latex:\ce{^{147}Pm}@@
>
> that exports for me.
>
> \nbsp{}^{147}Pm also seems to work, but might put an extra space in.
>
> you might prefer \phantom{}^{147}Pm
Or using the zero-width char (via the predefined entity \zwnj in Org)?
Best regards,
Seb
--
Sebastien Vauban
[O] math in footnotes not exported correctly when a buffer is narrowed
I've noticed a bug in org-mode's LaTeX exporting of footnotes when a buffer is narrowed to a particular section. To reproduce, try to export the following org-file to a LaTeX document, and inspect the resulting LaTeX code -- it will have stripped the math environment off of "\tau_s": * Test Section Here we test whether the footnote is exported correctly [1]. Be sure to narrow the buffer to this section only before doing a LaTeX export. * Footnotes [1] $\tau_s$ is blah blah blah. Let me know if there's a workaround for this (apart from just "don't narrow the buffer"). Thanks! Regards, Mark
Re: [O] math in footnotes not exported correctly when a buffer is narrowed
QUIT POST User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:0fc8KGlZBY/hiuAUPyLuqJkSoEw= Mark Edgington writes: > Let me know if there's a workaround for this (apart from just "don't > narrow the buffer"). Thanks! It was fixed a while ago in master. Are you using 8.2? Rasmus -- Together we'll stand, divided we'll fall
Re: [O] Marking/highlighting text temporarily
Rasmus writes: > Eric S Fraga writes: > >> On Monday, 18 May 2015 at 15:16, Rasmus wrote: >>> Nicolas Goaziou writes: I don't know what is a TODO functionality since you suggest to not make it appear in the agenda. >>> >>> E.g. "Sentence about BAR [TODO: add reference to FOO and check BAZ]". I >>> don't need that in my agenda. >> >> Exactly. I use inlinetasks a lot for file local TODO items that are not >> meant to appear in my agenda. They are notes for things I need to do, >> typically, to finish a paper. Being able to "C-c / t" to find them all >> easily is great. I would expect the same functionality from any >> replacement. > > Would it be bad if I admit I have no idea how to use sparse trees? The > remind me of Vim, except in Vim i eventually figured out that I could quit > it via :q. > > I would probably use occur or a restricted agenda. > > I would want inlinetodos in my "global"/usual agenda. > >> In terms of format, I also dislike opening and closing tags except for >> short formatting uses. I would prefer [COMMENT: this is very >> interesting] and [TODO: I need to update this]. Or even [[TODO:...]] to >> be less worried about running into problems with text use of [...]. > > I think [[TODO:]] is a link... We're coming back around to the beginning of the conversation! I still think we started off talking about two different things. One is a replacement for inlinetasks that's actually inline. The other is an annotation system that could be used for collaboration, and might be taking aim at Track Changes in some way. It looks like we've gone off in the inlinetasks direction. I'll admit that what I really want is an honest-to-goodness first-class-citizen inline TODO. Something attached to a specific run of text, that has a TODO keyword and tags. Probably scheduling? Probably not properties, I don't know. Personally I'd prefer that the contents of the TODO were hidden (a la links), because (like Eric F) I would use this for notes on pieces of writing, and having big ugly chunks of highlighted spaghetti in the middle of a paragraph makes it hard to write. How technically difficult would that be? If it slows down agenda creation too badly, maybe we could have a user option that defaults to skipping inline todos in agenda creation. I was lukewarm about Nicolas' earlier syntax proposal because it simply doesn't seem distinct enough from footnotes. Just some random reactions, Eric
Re: [O] org-export-dispatch not bound to C-c C-e.
Titus von der Malsburg writes: > `org-export-dispatch' is not anymore bound to C-c C-e. Instead C-c C-e > triggers `outline-show-entry'. Seems like a bug because the > documentation still says that C-c C-e should launch the export menu. > > Tested with git master. No. You are using a patch I sent to the list which removed this by accident. If you remove that patch everything will be OK. Sorry about that Titus. Rasmus -- Together we will make the possible totay impossible!
Re: [O] Marking/highlighting text temporarily
On 2015-04-24, at 08:19, Vikas Rawal wrote: > I am revising a long book manuscript, and would like to mark parts of text > (not just the headlines) just to remind myself that these need to be dealt > with. > > What could be an the easy way of doing it? Well, it seems that the thread went somewhere else (completely), but it just occured to me that you might want Bookmark+ (in case nobody mentioned it). You have normal Emacs bookmarks but on Drew-steroids, among others you can /highlight/ all bookmarks in a buffer. (And AFAIR you can have a dedicated bookmark file for e.g. one project, so that you effectively have "categories" of bookmarks.) > Vikas Hth, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
