Re: [O] [RFC] Standardized code block keywords
I did some tests with my documents and they look fine. Thanks for your work. (A minor remark, offtopic: If the document ends just below a source code block, no results are inserted when the block is executed. You have to insert an additional blank line, for a result to can appear.) Daniel Am Freitag 28 Oktober 2011, 20:52:48 schrieb Eric Schulte: > Nick Dokos writes: > > Eric Schulte wrote: > >> The attached updated patch fixes a bug in the original. > > > > Minor problem in applying: > > > > , > > > > | $ git apply ~/Mail/inbox/724 > > | /home/nick/Mail/inbox/724:671: trailing whitespace. > > | #+name: > > | /home/nick/Mail/inbox/724:599: new blank line at EOF. > > | + > > | warning: 2 lines add whitespace errors. > > > > ` > > The attached version fixes these issues, Thanks -- Eric
[O] Link abbreviations, org-files with searches
Hello! When defining a link-abbreviation to an org-file with a headline search I manage to get it to work with the following syntax: #+LINK: foo file:/long/path/to/file/foo.org [[foo*heading inside foo]] I have to use four ":" to be able to search, instead of the three I would expect (expecting three since the first ":" is used to declare that I want to enter a tag and the following two are used inside the tag). Is this intended behaviour? Also, it only seems to work for headline-search. I cannot get the regular search to work. Can someone confirm this behaviour? /Gustav
Re: [O] [odt] equation labels
>> On Mon, 31 Oct 2011 03:41:18 +0530, Jambunathan K said:
> Myles English writes:
>> I have found that Equations become labelled as Figures in the
>> version I am using:
>>
>> emacs 23.3.1 org-mode from git commit 71f1c1be (Oct 26) The test
>> equations in latex-mathml.org in this message:
>>
>> http://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00198.html
>>
>> are labelled as "Equation" in the odt files but when I export it
>> fresh I get "Figure".
> This was a regression. I pushed a fix few moments ago. Could you
> please pull again?
Thanks for the push, there are three things I notice now:
1) my document won't open and causes libreoffice to crash! I get:
"terminate called after throwing an instance of
what(): vector::_M_default_append" on the command line
2) the first equation in latex-mathml.org is not numbered, I would
expect this if it was using a begin{equation*} environment but not a
begin{equation}.
3) the second equation looks a bit like this:
x=root(b) (1)
Radicals
but I would have expected something like:
x=root(b)
Equation 1.: Radicals
Is there a new variable that I need to set to get (e.g.) "Equation 1."?
Just to be explicit, the test file latex-mathml.org I am referring to
contains:
#+TITLE: latex-mathml.org
#+AUTHOR:Jambunathan K
#+EMAIL: address@hidden
#+DATE: 2011-09-09 Fri
#+DESCRIPTION:
#+KEYWORDS:
#+LANGUAGE: en
#+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+LINK_UP:
#+LINK_HOME:
#+XSLT:
* LaTeX Fragments
** LaTeX Fragment1
# See org-format-latex-options
There is a equation down below.
\begin{equation}
e = \frac{1}{2}mv^2
\end{equation}
** LaTeX Fragment2
#+CAPTION: Radicals
#+LABEL: Equation:1
\begin{equation}
x=\sqrt{b}
\end{equation}
If $a^2=b$ and \( b=2 \), then the solution must be either $$
a=+\sqrt{2} $$ or \[ a=-\sqrt{2} \].
Myles
Re: [O] Link abbreviations, org-files with searches
Hello Gustav, 2011/10/31 Gustav Wikström : > Hello! > When defining a link-abbreviation to an org-file with a headline search I > manage to get it to work with the following syntax: > #+LINK: foo file:/long/path/to/file/foo.org AFAIK, this is not required. Support for linking to org headlines is already built in. > [[foo*heading inside foo]] This should be something like this: [[file:/path/to/file.org::*][Description]] > I have to use four ":" to be able to search, instead of the three I would > expect (expecting three since the first ":" is used to declare that I want > to enter a tag and the following two are used inside the tag). Is this > intended behaviour? I am not sure what you are talking about here. Could you give an example to illustrate? > Also, it only seems to work for headline-search. I cannot get the regular > search to work. Can someone confirm this behaviour? For the regular search, something like this should be sufficient: [[file:/path/to/file.org::][Description]] > /Gustav Hope this helps. PS: org-mode has amazing info documentation. Please check them out. All of these are well covered there. For tutorials, you can check the community site Worg. -- Suvayu Open source is the future. It sets us free.
Re: [O] Link abbreviations, org-files with searches
Hi Suvayu! I know about the normal links and the possibility to search with these. The thing is that I want to use an abbreviation (see sec. 4.6 in the manual) to not have to type the path for this particular link every time. Instead of typing (1) [[file:/path/to/file.org::*][Description]] I want to be able to add an abbreviation in the beginning of the file the link is in, with (2): #+LINK: foo file:/long/path/to/file/foo.org and then use this abbreviation later in the text with (3): [[foo][Description]] ,and also be able to use searches with this abbreviation. And it is this syntax that seems a bit cumbersome to use when adding headline-searching to it (requiring four ":") and does not work when trying to use regular search. Unless I'm doing something wrong. I also know that I could add the "::%s" to the link, giving (4): #+LINK: foo file:/long/path/to/file/foo.org::%s but this makes it unusable as a simple file link without search. I intend to use the link in multiple places inside my document both with and without searches, thus I'm still wondering about this syntax-issue and the non-headline search. Regards Gustav (PS. sorry for the double-mail Suvayu. ) 2011/10/31 suvayu ali > Hello Gustav, > > 2011/10/31 Gustav Wikström : > > Hello! > > When defining a link-abbreviation to an org-file with a headline search I > > manage to get it to work with the following syntax: > > #+LINK: foo file:/long/path/to/file/foo.org > > AFAIK, this is not required. Support for linking to org headlines is > already built in. > > > [[foo*heading inside foo]] > > This should be something like this: > > > [[file:/path/to/file.org::*][Description]] > > > I have to use four ":" to be able to search, instead of the three I would > > expect (expecting three since the first ":" is used to declare that I > want > > to enter a tag and the following two are used inside the tag). Is this > > intended behaviour? > > I am not sure what you are talking about here. Could you give an > example to illustrate? > > > Also, it only seems to work for headline-search. I cannot get the regular > > search to work. Can someone confirm this behaviour? > > For the regular search, something like this should be sufficient: > > [[file:/path/to/file.org::][Description]] > > > /Gustav > > Hope this helps. > > PS: org-mode has amazing info documentation. Please check them out. All >of these are well covered there. For tutorials, you can check the >community site Worg. > > -- > Suvayu > > Open source is the future. It sets us free. >
Re: [O] Link abbreviations, org-files with searches
On Mon, 31 Oct 2011 13:33:31 +0100 Gustav Wikström wrote: > Hi Suvayu! > > I know about the normal links and the possibility to search with > these. The thing is that I want to use an abbreviation (see sec. 4.6 > in the manual) to not have to type the path for this particular link > every time. > > Instead of typing (1) > > [[file:/path/to/file.org::*][Description]] > > I want to be able to add an abbreviation in the beginning of the file > the link is in, with (2): > > #+LINK: foo file:/long/path/to/file/foo.org > > and then use this abbreviation later in the text with (3): > > [[foo][Description]] > Okay now I follow you. I believe you are misunderstanding the syntax. It should be like this (copying from my test example): #+LINK: odir file:~/org/coding.org:: [[odir:Distributed%20analysis][Distributed analysis]] [[odir:#ganga][Ganga]] That said I had trouble getting the search to work with org files but I will admit I did not try hard enough. > ,and also be able to use searches with this abbreviation. And it is > this syntax that seems a bit cumbersome to use when adding > headline-searching to it (requiring four ":") and does not work when > trying to use regular search. Unless I'm doing something wrong. > > I also know that I could add the "::%s" to the link, giving (4): > > #+LINK: foo file:/long/path/to/file/foo.org::%s > > but this makes it unusable as a simple file link without search. I > intend to use the link in multiple places inside my document both > with and without searches, thus I'm still wondering about this > syntax-issue and the non-headline search. > How is it unusable? Shouldn't the following work with the above setting? [[foo:][Description]] [[foo:*][Description]] Of course I didn't have the time to test this variation, so indeed there could be a bug. :-p > Regards > Gustav > > (PS. sorry for the double-mail Suvayu. ) > No worries. Hope the above suggestions help. -- Suvayu Open source is the future. It sets us free.
Re: [O] [Accepted] Check marker is valid before use
On 2011-10-21 16:09 +0800, Carsten Dominik wrote: > Patch 994 (http://patchwork.newartisans.com/patch/994/) is now "Accepted". > > Maintainer comment: none > > This relates to the following submission: > > http://mid.gmane.org/%3Cm1ipnj8mj4.fsf%40gmail.com%3E > > Here is the original message containing the patch: Sadly the version of org-mode in emacs 24 still has the bug. Leo
[O] execute lisp function after enter a cell in a org-table
Hi, I make my tiny steps in learning elisp by trying to improve org-mode for my own needs. Recently, I came across the needs to execute a small lisp function whenever I enter the next / previous column in a org-mode table. I thought it might be interesting if I could try to keep this as general as possible. Think about calling a certain lisp function whenever you enter a certain column in a table. For my needs it would be (set-input-method 'foo) to change automatically the input method. This would allow to type in two different languages within the table. However, it could be anything else, from validating input data, change between different minor modes or automatic table formatting of the table itself (think about tables with a fixed narrow column width and an automatic extension of the current selected column), I'm still in the middle of implementing this and want to ask a) is there a general interest for such a feature? b) for some guidance from the org-mode wizards ;) I read a bit in org-table.el and there is a function "org-table-current-column" which does already half of the job. If I understand right I would have to create a new lisp function which executes the given lisp snippets for a given column (I would like to add them like normal table functions). This new function would been a hook function? As far as I read throw all possible hook functions, I could not find any which would be called within tables for each jump into a cell or column. I thought the tab-function itself (which let the cursor jump into the next column) might be used. but I am unsure about this. Similar the present way of tables to execute lisp functions is limited to updates of the table. However as far as I could understand the simple movement of the cursor does not trigger an table update. Any ideas, help and pointers to org-mode code would be nice. For learning purpose, I really want to go through this by myself, so please no "add this to your .emacs" stuff ;) Totti
Re: [O] Link abbreviations, org-files with searches
2011/10/31 Suvayu Ali : ... >> I also know that I could add the "::%s" to the link, giving (4): >> >> #+LINK: foo file:/long/path/to/file/foo.org::%s >> >> but this makes it unusable as a simple file link without search. I >> intend to use the link in multiple places inside my document both >> with and without searches, thus I'm still wondering about this >> syntax-issue and the non-headline search. >> > > How is it unusable? Shouldn't the following work with the above setting? > > [[foo:][Description]] > [[foo:*][Description]] > > Of course I didn't have the time to test this variation, so indeed there > could be a bug. :-p This works when adding "::" to the end of the link. But with this setting I cannot use the link as a simple file-link, eg. the following does not work: #+LINK: foo file:/long/path/to/file/foo.org:: [[foo][Description]] When trying to follow this link I get an error saying that there is "no such file: /long/path/to/file/foo.org::" /Gustav
[O] wrap long table formula
I have a table with 3 columns and 13 rows. Each field of the 3rd column calculates the average of the preceding rows of the 2nd column. For this I wrote formulas for 11 of 13 rows which results in a very long line. How can I wrap this line? henry -- http://literaturlatenight.de
Re: [O] wrap long table formula
On Oct 31, 2011, at 3:01 PM, henry atting wrote: > I have a table with 3 columns and 13 rows. Each field of the 3rd > column calculates the average of the preceding rows of the 2nd column. > For this I wrote formulas for 11 of 13 rows which results in a very > long line. > How can I wrap this line? You don't. You can use the equation editor to have a more convenient way to edit the equations. - Carsten
Re: [O] Link abbreviations, org-files with searches
Hi Gustav, On Mon, 31 Oct 2011 14:55:27 +0100 Gustav Wikström wrote: > This works when adding "::" to the end of the link. But with this > setting I cannot use the link as a simple file-link, eg. the following > does not work: > > #+LINK: foo file:/long/path/to/file/foo.org:: > [[foo][Description]] > > When trying to follow this link I get an error saying that there is > "no such file: /long/path/to/file/foo.org::" Of course that won't work! The resulting link is not a valid link syntax. Since you don't specify a tag, the final link looks like this: [[file:/path/to/file.org::]] which is incorrect. From a test the following worked nicely. #+LINK: odir2 file:~/org/coding.org [[odir2][link to file]] So in conclusion, if you want to use both bare file/directory links as well as headline/search links, you would have to define two separate link shortcuts. Hope that helps. -- Suvayu Open source is the future. It sets us free.
Re: [O] org-capture template property completion
While prompting the user for property "MyProtperty", Is there a way to
get completion on the "MyProperty" value while in the org-capture
bufffer?(...either ala the %^{prompt} format or by reading the
property definitions in the destination file or buffer?)
Thank You!
On Oct 29, 2011, at 7:02 AM, Bastien wrote:
Hi,
dlc writes:
I am an emacs novice attempting to use an org-capture template.
The manual
indicates completion is available while expanding %^{prompt}. Can
one get
completion on %^{prop}p for a property? I tried the same syntax
for prompt
and that did not work.
If you want to prompt the user for property "MyProperty" you need to
use
%^{MyProperty}p in the capture template.
HTH,
--
Bastien
Re: [O] wrap long table formula
Carsten Dominik writes: > On Oct 31, 2011, at 3:01 PM, henry atting wrote: > >> I have a table with 3 columns and 13 rows. Each field of the 3rd >> column calculates the average of the preceding rows of the 2nd column. >> For this I wrote formulas for 11 of 13 rows which results in a very >> long line. >> How can I wrap this line? > > You don't. > > You can use the equation editor to have a more convenient way to edit the > equations. > > - Carsten > This is great; I did not know the formula editor yet. Thanks. henry -- http://literaturlatenight.de
Re: [O] org-capture template property completion
dlc writes:
> While prompting the user for property "MyProtperty", Is there a way to
> get completion on the "MyProperty" value while in the org-capture
> bufffer?
e.g. :
:PROPERTIES:
:Effort: %^{prompt|0:10|0:20|0:30|1:00|2:00|3:00}
:END:
so you can choose the value of 'effort'?
hth
Giovanni
[O] [babel] Noweb expansion, not noweb evaluation...
Hi Eric, * Overview In order to be able to create a big code from small chunks, I need to compose with the *expanded* view of a block, instead of its *evaluated* result. I don't see how to do that while keeping the small block *executable*. * Use case A use case could explain the need in a much clearer manner. I have a SQL block that duplicates a row: #+srcname: insert-duplicate-row-with-ID #+begin_src sql :var table="order" :var column="ID" :var source_value="'73-0007'" :var target_value="'73-0008'" INSERT INTO $table ... #+end_src This block is executable, that is I can call it on the fly to make what I mean. This is good. Now, I wanna make use of that general "function" in a long stored procedure, customized to duplicate a row in a large set of tables. Something like this: #+begin_src sql :noweb yes CREATE PROCEDURE clone_row_with_ID @source_value varchar(16), @target_value varchar(16) AS <> <> ... <> GO #+end_src But this does not work, as Babel replaces the Noweb call with the results of its evaluation, not with the results of its *expansion*. Is there a way to get it working? * Workaround A very ugly workaround which I see is that: - the reference block prints out SQL code: for example, an AWK code printing SQL statement. - the general block calls Noweb, and receives the output of AWK's execution, hence expanded SQL code. But, then, the reference block is not executable anymore. Not really a workaround, then... Best regards, Seb -- Sebastien Vauban
Re: [O] Link abbreviations, org-files with searches
2011/10/31 Suvayu Ali : > Hi Gustav, > > On Mon, 31 Oct 2011 14:55:27 +0100 > Gustav Wikström wrote: > >> This works when adding "::" to the end of the link. But with this >> setting I cannot use the link as a simple file-link, eg. the following >> does not work: >> >> #+LINK: foo file:/long/path/to/file/foo.org:: >> [[foo][Description]] >> >> When trying to follow this link I get an error saying that there is >> "no such file: /long/path/to/file/foo.org::" > > Of course that won't work! The resulting link is not a valid link > syntax. Since you don't specify a tag, the final link looks like this: > > [[file:/path/to/file.org::]] > > which is incorrect. > > From a test the following worked nicely. > > #+LINK: odir2 file:~/org/coding.org > > [[odir2][link to file]] > > So in conclusion, if you want to use both bare file/directory links as > well as headline/search links, you would have to define two separate > link shortcuts. Yes, I'm aware of this. And this is the reason of my initial question. Should it really be necessary to specify two separate links to the same file when I want to both link to the file directly and link it with a search? Thus, this works: #+LINK: foo file:/long/path/to/file/foo.org [[foo*]] but this does not: #+LINK: foo file:/long/path/to/file/foo.org [[foo]] I find the use of four ":" a bit strange, but I guess this is only a limit of my understanding a.t.m. In my view the first colon should be stating the start of the "tag" and the rest of the string the tag itself. This leaves three colons for the tag which in my view is one to many. But it seems to work. And this is what I'm scratching my head about. I also suspect a bug hidden somewhere, since headlines can be searched for but not text inside the document. Anyone got any input on this? /Gustav
Re: [O] wrap long table formula
Would a column formula work? Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
It is now possible to specify multi-line properties using a property block. This should make it more natural to specify many file-wide variables through properties. For example, #+begin_property var foo=1, bar=2, baz=3, qux=4 #+end_property #+begin_src emacs-lisp (+ foo bar baz qux) #+end_src #+results: : 10 Cheers -- Eric Darlan Cavalcante Moreira writes: > I didn't check the list for 3 days and this thread became a little hard to > follow. So, forgive me if I'm "answering" the wrong E-Mail. > > > I liked Christian's idea of using a single "var" property to tell babel > which regular properties it should use as variables (ignoring any variable > not defined). This would be enough for my use cases. > > On the other hand, some way to append values to a property, such as using > some special keyword as I have suggested, could be a better solution in > order to keep consistence if people want this feature for non-babel related > properties. > > -- > Darlan > > At Sat, 22 Oct 2011 09:53:25 -0600, > Eric Schulte wrote: >> >> Darlan Cavalcante Moreira writes: >> >> > It's excellent that now babel understands multiple values in the "var" >> > property (I was one of the people that wanted this), but "There Is One More >> > Thing". >> > >> > Would it be feasible to inherit variables from parent sub-trees? >> > Effectively, I'd like to append new values in lower level sub-trees, but >> > AFAIK setting the var property in a sub-tree will still replace the value >> > set in the parent sub-tree. >> > >> >> Currently every new property specification entirely replaced previous >> specifications with the same name. >> >> > >> > That is, in the example below the level-2 sub-trees would not have the foo >> > variable passed to babel. >> > * Code with foo >> > :PROPERTIES: >> > :var: foo=1 >> > :END: >> > >> > ** Code only with bar >> >:PROPERTIES: >> >:var: bar=2 >> >:END: >> >src_block >> > ** Code only with baz >> >:PROPERTIES: >> >:var: baz=3 >> >:END: >> >src_block >> > >> > Maybe a special keyword, such as "inherit" (or "append") could be used to >> > incorporate variables defined in the parent sub-tree, such that the example >> > would become >> > * Code with foo >> > :PROPERTIES: >> > :var: foo=1 >> > :END: >> > >> > ** Code with foo and bar >> >:PROPERTIES: >> >:var: bar=2, inherit >> >:END: >> >src_block >> > ** Code with foo and baz >> >:PROPERTIES: >> >:var: baz=3, inherit >> >:END: >> >src_block >> > >> > This should not affect global variables and "inherit" would inherit >> > variables defined only in the parent sub-tree (unless it also contains the >> > inherit keyword). >> > >> > As a use case scenario, suppose I need to perform simulations for a few >> > different scenarios, each with small variations. This would allow me to >> > define common variables for a scenario in a higher level sub-tree and more >> > specific variables in the lower level sub-trees. >> > >> >> This sounds somewhat similar to my suggestion in reply to Rainer's >> email. >> >> Best -- Eric >> >> > >> > -- >> > Darlan Cavalcante >> > >> > >> > At Fri, 21 Oct 2011 22:24:25 +0200, >> > Christian Moe wrote: >> >> >> >> Hi, >> >> >> >> Yes, that works nicely, and should solve Rainer's problem. >> >> I haven't been able to think of anything else that can't be handled by >> >> properties. >> >> >> >> And I do think it's a good idea to winnow down the syntax a bit, even >> >> if things break. I just like to grumble. >> >> :-) >> >> >> >> Yours, >> >> Christian >> >> >> >> On 10/21/11 7:37 PM, Eric Schulte wrote: >> >> > Nice idea. This same issue with "var" arose when we first started >> >> > allowing header arguments to be specified inside subtree properties. >> >> > I've just implemented your suggestion so the following are now possible. >> >> > >> >> > #+PROPERTY: var foo=1, bar=2 >> >> > #+PROPERTY: cache yes >> >> > >> >> > #+begin_src emacs-lisp >> >> >(+ foo bar) >> >> > #+end_src >> >> > >> >> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: >> >> > : 3 >> >> > >> >> > and >> >> > >> >> > #+begin_src emacs-lisp :var foo="this", bar="that" >> >> >(concat foo " " bar) >> >> > #+end_src >> >> > >> >> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: >> >> > : this that >> >> > >> >> > Thanks for the suggestion and I hope the above is a sufficient >> >> > replacement for the now-missing #+BABEL: syntax. >> >> > >> >> > Cheers -- Eric >> >> >> >> >> >> -- >> Eric Schulte >> http://cs.unm.edu/~eschulte/ -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [RFC] Standardized code block keywords
Daniel Bausch writes: > I did some tests with my documents and they look fine. Thanks for your work. > Great, good to know. > > (A minor remark, offtopic: If the document ends just below a source > code block, no results are inserted when the block is executed. You > have to insert an additional blank line, for a result to can appear.) > I can't reproduce this problem. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] About commit named "Allow multi-line properties to be specified in property blocks"
Hello, I just noticed that commit (8354fd9e0f5fff04665b2272fff6376b15ec0225). Could we talk about it before pushing it, a few days before the release? I am a bit worried about the new block types being introduced recently. Some may be justified, I don't know yet, but "#+begin_property" definitely isn't. By looking at the Org syntax. what appears clearly is that Org blocks are used for contents formatting. Center blocks, quote blocks, verse blocks, special blocks, example blocks, export blocks, even src blocks (even though these blocks may be used for very different things, they exist primarily to display source code)... there's no exception. On the other hand, Org internals are controlled through keywords, property drawers, and options on blocks. As "#+begin_property" block isn't about contents. I can't see any reason for it to exist under this shape. So, again, can we discuss about another approach that would not break the logic behind Org's syntax? I don't fully grasp the problem it tries to solve, but what's wrong with, for example, "#+property: var multiple couples"? What's wrong with :var_list: x=1,y=3,z=4 in a property drawer? What's wrong with #+header: :var x=1, y=2, z=3 just above the source block? As your already know, #+header can span already on multiple lines. Hoping we can find a more elegant solution, Regards, -- Nicolas Goaziou
Re: [O] wrap long table formula
On 31.10.2011, at 19:10, Samuel Wales wrote: > Would a column formula work? Good idea! Quite likely it would. - Carsten > > Samuel > > -- > The Kafka Pandemic: http://thekafkapandemic.blogspot.com > === > Bigotry against people with serious diseases is still bigotry.
Re: [O] org-capture template property completion
almost... using %^{Effort|0:10|0:20|0:30|1:00}p in the org-template
expansion, this would match the same format as the %^{prompt} expansion.
If only the stock property is provided in the template, e.g.
%^{Effort}p ... then property completion would look in the capture
target for #+PROPERTY Effort_ALL 0:10 0:20 0:30 1:00 to provide the
value list for the choosing of 'effort'
On Oct 31, 2011, at 10:00 AM, Giovanni Ridolfi wrote:
dlc writes:
While prompting the user for property "MyProtperty", Is there a way
to
get completion on the "MyProperty" value while in the org-capture
bufffer?
e.g. :
:PROPERTIES:
:Effort: %^{prompt|0:10|0:20|0:30|1:00|2:00|3:00}
:END:
so you can choose the value of 'effort'?
hth
Giovanni
Re: [O] Bug: Publishing with auto-sitemap is broken [7.7 (release_7.7.497.gae02e)]
Hello, Bernt Hansen writes: > Publishing with an automatically generated index file is broken for me. > > With org-publish-projects set with > > :auto-sitemap t > :sitemap-filename "index.html" > :sitemap-title "Test Publishing Area" > :sitemap-style "tree" I think reverting changes on headlines in HTML and DocBook exporters is the best option for now. Does the following patch work? Regards, -- Nicolas Goaziou >From 0a6d23ac0f865829701f21a1d460cdf0647473c7 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Mon, 31 Oct 2011 20:21:06 +0100 Subject: [PATCH] Do not rely on variables defined in Org buffers only for export * lisp/org-html.el (org-export-as-html): Revert changes effectued on patch dfcb6faef11a2439b56b18a6289803361d402130. `org-heading-keyword-regexp-format' may not be defined during all the export stages. * lisp/org-docbook.el (org-export-as-docbook): Ditto. --- lisp/org-docbook.el |5 ++--- lisp/org-html.el|5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/lisp/org-docbook.el b/lisp/org-docbook.el index 6b10354..5cb9722 100644 --- a/lisp/org-docbook.el +++ b/lisp/org-docbook.el @@ -502,9 +502,8 @@ publishing directory." ;; We will use HTML table formatter to export tables to DocBook ;; format, so need to set html-table-tag here. (html-table-tag (plist-get opt-plist :html-table-tag)) - (quote-re0 (concat "^ *" org-quote-string "\\( +\\|[ \t]*$\\)")) - (quote-re(format org-heading-keyword-regexp-format - org-quote-string)) + (quote-re0 (concat "^[ \t]*" org-quote-string "\\>")) + (quote-re(concat "^\\(\\*+\\)\\([ \t]+" org-quote-string "\\>\\)")) (inquote nil) (infixed nil) (inverse nil) diff --git a/lisp/org-html.el b/lisp/org-html.el index fa3811f..8908198 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -1179,9 +1179,8 @@ PUB-DIR is set, use this as the publishing directory." (plist-get opt-plist :link-home))) (dummy (setq opt-plist (plist-put opt-plist :title title))) (html-table-tag (plist-get opt-plist :html-table-tag)) - (quote-re0 (concat "^ *" org-quote-string "\\( +\\|[ \t]*$\\)")) - (quote-re(format org-heading-keyword-regexp-format - org-quote-string)) + (quote-re0 (concat "^[ \t]*" org-quote-string "\\>")) + (quote-re(concat "^\\(\\*+\\)\\([ \t]+" org-quote-string "\\>\\)")) (inquote nil) (infixed nil) (inverse nil) -- 1.7.7.1
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
Nicolas Goaziou writes: > Hello, > > I just noticed that commit (8354fd9e0f5fff04665b2272fff6376b15ec0225). > > Could we talk about it before pushing it, a few days before the release? > > I am a bit worried about the new block types being introduced recently. > Some may be justified, I don't know yet, but "#+begin_property" > definitely isn't. > > By looking at the Org syntax. what appears clearly is that Org blocks > are used for contents formatting. Center blocks, quote blocks, verse > blocks, special blocks, example blocks, export blocks, even src blocks > (even though these blocks may be used for very different things, they > exist primarily to display source code)... there's no exception. > > On the other hand, Org internals are controlled through keywords, > property drawers, and options on blocks. > > As "#+begin_property" block isn't about contents. I can't see any reason > for it to exist under this shape. So, again, can we discuss about > another approach that would not break the logic behind Org's syntax? > > I don't fully grasp the problem it tries to solve, but what's wrong > with, for example, "#+property: var multiple couples"? What's wrong > with :var_list: x=1,y=3,z=4 in a property drawer? What's wrong > with #+header: :var x=1, y=2, z=3 just above the source block? As your > already know, #+header can span already on multiple lines. > > Hoping we can find a more elegant solution, > The only problem with a single #+PROPERTY: line is that this line could become unreadably long. By allowing such an entry to span multiple lines it becomes feasible to chain together many variables into a single property. Another approach which is easily implementable would be to use syntax like the following... #+PROPERTY: var foo=1, #+PROPERTY+: bar=2, #+PROPERTY+: baz=3, #+PROPERTY+: qux=4 #+begin_src emacs-lisp (+ foo bar baz qux) #+end_src #+results: : 10 Although I originally switched from the above to the implemented because I thought that using a block would be more consistent with Org-mode syntax. Also, the above is undesirable in its requires the PROPERTY+ lines to care about their position in the Org-mode file, which isn't normally the case. I think of #+FOO: lines as containers for anything that fits on a single line, and as blocks as containers for anything that requires a line break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML. I didn't realize that there was an extra semantics of blocks as formatting, and I'm not sure if such an association is desirable or intentional. Best -- Eric > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 2011-10-31, Eric Schulte wrote: > It is now possible to specify multi-line properties using a property > block. This should make it more natural to specify many file-wide > variables through properties. For example, Could this be changed to work using the property drawer?
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
Eric Schulte writes: > The only problem with a single #+PROPERTY: line is that this line could > become unreadably long. By allowing such an entry to span multiple > lines it becomes feasible to chain together many variables into a single > property. Another approach which is easily implementable would be to > use syntax like the following... > > > #+PROPERTY: var foo=1, > #+PROPERTY+: bar=2, > #+PROPERTY+: baz=3, > #+PROPERTY+: qux=4 Well, what about: #+begin_src org #+property: :var foo=1 #+property: :var bar=2 #+property: :var baz=3 #+property: :var qux=4 #+end_src Sure, we repeat ":var" more times, but at least, it's consistent with the rest of Org. > Although I originally switched from the above to the implemented > because I thought that using a block would be more consistent with > Org-mode syntax. No, as I said, no block has ever controlled Org internals. That's a job for keywords and property drawers. > Also, the above is undesirable in its requires the PROPERTY+ lines to > care about their position in the Org-mode file, which isn't normally > the case. Yes, "#+property+:" would be atypical in that situation. > I think of #+FOO: lines as containers for anything that fits on > a single line, and as blocks as containers for anything that requires > a line break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML. That comparison with "#+html" and "#+begin_html" doesn't hold as most "#+keyword:" syntax don't have an equivalent block "#+begin_keyword", and the other way. Look again at every block type in Org, and see if there's any equivalent use of the "#+begin_property" you're introducing. I don't think so. Moreover, some keywords can be repeated on multiple lines. Think about "#+text:" before first headline, or "#+header:" before a src block. So, clearly, "#+keyword:" isn't just about things that must fit on a single line. Also, you don't really need a line break here, since you will eventually parse the values line by line anyway, and not as a block or a paragraph. You want to add syntactic sugar. There's nothing wrong with it though, but not everyone appreciate aspartame ;) > I didn't realize that there was an extra semantics of blocks as > formatting, and I'm not sure if such an association is desirable or > intentional. It is desirable to have a logic behind syntax, and to always refer to it. Thus, is is desirable to separate syntax used for contents from syntax used for Org control. It's very different from "things on a single line vs things on multiple lines". Regards, -- Nicolas Goaziou
Re: [O] Outline and org-mode don't insert text into folded sections logically
Hi Bastien, more feedback: I just got bitten by this while editing a file with visible-mode turned on. I was trying to add some text, and the code would continuously jump to some other position. Took me a while to figure out. So I suggest to add a test for (or (not (boundp 'visible-mode)) (not visible-mode)) before doing anything. Also, this made me again think that moving point is not a good idea. - Carsten On 30.10.2011, at 16:37, Carsten Dominik wrote: > > On 30.10.2011, at 10:04, Bastien wrote: > >> Hi Carsten, >> >> Carsten Dominik writes: >> >>> - This patch covers only one of many ways to make unwanted changes >>> in an invisible area. Others would be delete, backspace, >>> kill-region, yank, kill-line, and an arbitrarily long list of >>> less obvious other commands. Full protection could only be >>> done with pre-change-hooks or so, but would then prevent >>> also programmed changes - something that would not be useful. >> >> Yes, I don't want programmed changes to be affected by this feature. >> >> But having such a warning for `org-delete' would also be useful IMHO. > > I guess you mean, org-delete-char and org-delete-backward-char > >> >>> `org-self-insert-command' is probably only ever used in an >>> interactive way, so the patch as you have written it may very >>> well function correctly. >>> >>> - All the code in org-self-insert-command is executed for each >>> keypress, so one needs to be careful to have this function >>> carry as little overhead as possible. >> >> I actually think there should be a user option >> `org-edit-invisible-send-warning' defaulting to nil. > > +1 > >> >> The request "don't let me shoot in my foot" is a common >> one, and this option would let people set this to `t'. >> >>> - Currently this chokes at the beginning of the buffer because >>> the invisibility test is also run at (1- (point)). >> >> Fixed, thanks. >> >>> - I am not sure if I understand the positioning code: (if (or (eq invisible-before-point 'outline) (eq invisible-before-point 'org-hide-block)) (goto-char (previous-overlay-change (point (org-cycle) (if (or (eq invisible-before-point 'outline) (eq invisible-before-point 'org-hide-block)) (forward-char 1)) >>> >>> So when I happen to be somewhere in the middle of invisible >>> text and press a character, it seems to me that the character >>> will be inserted at the beginning of the invisible text, and >>> not where the cursor was. >>> >>> Maybe a better solution would be to save point, unfold, >>> go back to point, throw and error and not insert the pressed >>> character. I am not sure, though. >> >> Throwing an error and not inserting the text was what my first >> patch did. I thought it was too restrictive, though. >> >> With an option `org-edit-invisible-send-warning', we could have both: >> `t' would just throw a warning, 'prevent would throw an error. > > I like that. > >> >>> Maybe you can explain your reasoning? >> >> My reasoning is that, when in the "middle" of an invisible region, >> the user does not know where the point is, hence he doesn't really >> know where he wants to insert characters. In this case, I assume >> insert at the beginning of the invisible region is a reasonable >> default. > > I have to admit that it does work well at the end of a folded headline, > and delete-backward-char there would also work fine. > > I would think, when the cursor is in the middle of an invisble regions, > the change should always be denied. > > Cheers > > - Carsten > >> >> Thanks for the feedback -- let's continue brainstorming, I think >> this feature is important. >> >> Best, >> >> -- >> Bastien >
Re: [O] Link abbreviations, org-files with searches
I did some digging and ended at the function org-link-expand-abbrev. According to the org-documentation, abbreviations should be written with: [[linkword:tag]] however the regular expression doing the matching in the function also allows the following: [[linkword::tag]] The greed of the regular expression makes it a requirement to use four colons when using abbreviation and search. Also, all types of searching works, not only the headline-search as I stated earlier. Just wanted to clear this out /Gustav 2011/10/31 Gustav Wikström : > 2011/10/31 Suvayu Ali : >> Hi Gustav, >> >> On Mon, 31 Oct 2011 14:55:27 +0100 >> Gustav Wikström wrote: >> >>> This works when adding "::" to the end of the link. But with this >>> setting I cannot use the link as a simple file-link, eg. the following >>> does not work: >>> >>> #+LINK: foo file:/long/path/to/file/foo.org:: >>> [[foo][Description]] >>> >>> When trying to follow this link I get an error saying that there is >>> "no such file: /long/path/to/file/foo.org::" >> >> Of course that won't work! The resulting link is not a valid link >> syntax. Since you don't specify a tag, the final link looks like this: >> >> [[file:/path/to/file.org::]] >> >> which is incorrect. >> >> From a test the following worked nicely. >> >> #+LINK: odir2 file:~/org/coding.org >> >> [[odir2][link to file]] >> >> So in conclusion, if you want to use both bare file/directory links as >> well as headline/search links, you would have to define two separate >> link shortcuts. > > Yes, I'm aware of this. And this is the reason of my initial question. > Should it really be necessary to specify two separate links to the > same file when I want to both link to the file directly and link it > with a search? > > Thus, this works: > > #+LINK: foo file:/long/path/to/file/foo.org > [[foo*]] > > but this does not: > > #+LINK: foo file:/long/path/to/file/foo.org > [[foo]] > > I find the use of four ":" a bit strange, but I guess this is only a > limit of my understanding a.t.m. In my view the first colon should be > stating the start of the "tag" and the rest of the string the tag > itself. This leaves three colons for the tag which in my view is one > to many. But it seems to work. And this is what I'm scratching my head > about. > > I also suspect a bug hidden somewhere, since headlines can be searched > for but not text inside the document. > > Anyone got any input on this? > /Gustav >
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
Hi, Having followed the thread on Babel and properties after the removal of the #+BABEL headers, I understand the motivation for introducing this. But I share Nicolas' feelings that a property block doesn't rhyme with existing usage of blocks and properties. There were many other ideas that came up: 1. PROPERTY+ lines (as discussed in Eric's message above). 2. A similar approach to the table formula editor (C-c ') for properties. 3. Allowing some properties to accumulate values, in particular making the :var: property for Babel blocks cumulative (slightly different versions suggested by Eric and Darlan; either would require some changes to Org's property handling), and 4. My own idea of allowing any defined property to be passed as an argument to src blocks (which would require some changes to how Babel reads its :var header args). Solutions 1-2 would solve the long lines problem. Solutions 2-4 would avoid introducing new syntax (#+BEGIN_PROPERTY or #+PROPERTY+) largely to make up for having removed old syntax (#+BABEL). Solutions 3-4 would have wide-ranging effects and would need some careful study, but I think the advantages might outweigh the risks. Yours, Christian
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
On 10/31/11 9:49 PM, Nicolas Goaziou wrote: #+begin_src org #+property: :var foo=1 #+property: :var bar=2 #+property: :var baz=3 #+property: :var qux=4 #+end_src Two problems: 1) You need to drop the colons before var. 2) The outcome is not what you expect. #+property: var foo=1 #+property: var bar=2 #+property: var baz=3 #+property: var qux=4 #+begin_src perl :results output print "foo is $foo, bar is $bar, baz is $baz, qux is $qux" #+end_src #+results: : foo is 1, bar is , baz is , qux is Because as things currently work, further assignments to the same property (var) by subsequent #+PROPERTY lines are ignored. (Whereas further assignments to the same property in property drawers further down an outline tree will `overwrite' assignments higher up.) Yours, Christian
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
Nicolas Goaziou writes: > Eric Schulte writes: > >> The only problem with a single #+PROPERTY: line is that this line could >> become unreadably long. By allowing such an entry to span multiple >> lines it becomes feasible to chain together many variables into a single >> property. Another approach which is easily implementable would be to >> use syntax like the following... >> >> >> #+PROPERTY: var foo=1, >> #+PROPERTY+: bar=2, >> #+PROPERTY+: baz=3, >> #+PROPERTY+: qux=4 > > Well, what about: > > #+property: :var foo=1 > #+property: :var bar=2 > #+property: :var baz=3 > #+property: :var qux=4 > > Sure, we repeat ":var" more times, but at least, it's consistent with > the rest of Org. > Unfortunately this won't work, the final value of the "var" property will be "qux=4" rather than "foo=1, bar=2, baz=3, qux=4". > >> Although I originally switched from the above to the implemented >> because I thought that using a block would be more consistent with >> Org-mode syntax. > > No, as I said, no block has ever controlled Org internals. That's a job > for keywords and property drawers. > I would say that the block is defining an keyword, but yes, I suppose we've never had a multi-line keyword definition structure. > >> Also, the above is undesirable in its requires the PROPERTY+ lines to >> care about their position in the Org-mode file, which isn't normally >> the case. > > Yes, "#+property+:" would be atypical in that situation. > >> I think of #+FOO: lines as containers for anything that fits on >> a single line, and as blocks as containers for anything that requires >> a line break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML. > > That comparison with "#+html" and "#+begin_html" doesn't hold as most > "#+keyword:" syntax don't have an equivalent block "#+begin_keyword", Along these lines I would also like to allow TBLFM lines to be broken over multiple lines, as I often find myself right-scrolling in a buffer to find equations in large spreadsheets. I wonder if there would be a general solution to allow *all* #keyword+ lines to have a block equivalent. > > and the other way. Look again at every block type in Org, and see if > there's any equivalent use of the "#+begin_property" you're > introducing. I don't think so. > agreed > > Moreover, some keywords can be repeated on multiple lines. Think about > "#+text:" before first headline, or "#+header:" before a src block. So, > clearly, "#+keyword:" isn't just about things that must fit on a single > line. > I don't know how #+text: works, but with #+header: the order of the blocks is not important, i.e., #+headers: :var a=1 #+headers: :cache a=2 is equal to #+headers: :cache a=2 #+headers: :var a=1 but the same is not true for #+PROPERTY: var foo=1, #+PROPERTY+: bar=2 and #+PROPERTY+: bar=2 #+PROPERTY: var foo=1, > > Also, you don't really need a line break here, since you will eventually > parse the values line by line anyway, and not as a block or a paragraph. > > You want to add syntactic sugar. There's nothing wrong with it though, > but not everyone appreciate aspartame ;) > Yes, if you dig way back into this thread you'll see the motivation, basically there are times when a user will want to specify *many* variables in a single property specification. If there is a more natural syntax I am very open to suggestions. > >> I didn't realize that there was an extra semantics of blocks as >> formatting, and I'm not sure if such an association is desirable or >> intentional. > > It is desirable to have a logic behind syntax, and to always refer to > it. Thus, is is desirable to separate syntax used for contents from > syntax used for Org control. It's very different from "things on > a single line vs things on multiple lines". > Sure, but to play devils (or my own) advocate, I would say that simplicity is important and "blocks for multi-line content" is a simpler rule than "blocks for formatting of multi-line content, and for naming multi-line data", the second being the case with code and example blocks. My goal here is to find the most natural solution which conforms to Org-modes design as well as possible, I just don't know what that would be... Cheers -- Eric > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
> > 4. My own idea of allowing any defined property to be passed as an > argument to src blocks (which would require some changes to how Babel > reads its :var header args). > I do see how this approach could be powerful, however I fear both the size of the change and the potential negative consequences of combining the property and variable name spaces. -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [PATCH] Create visibility overlays properly
* org.el (org-set-outline-overlay-data): Use outline-flag-region to make a region invisible. This ensures all necessary actions, especially adding isearch-open-invisible property, are applied. --- lisp/org.el |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index a75f96e..c4196e8 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6599,8 +6599,7 @@ DATA should have been made by `org-outline-overlay-data'." (widen) (show-all) (mapc (lambda (c) - (setq o (make-overlay (car c) (cdr c))) - (overlay-put o 'invisible 'outline)) + (outline-flag-region (car c) (cdr c) t)) data) ;;; Folding of blocks -- 1.7.2.5
Re: [O] Bug: Publishing with auto-sitemap is broken [7.7 (release_7.7.497.gae02e)]
Nicolas Goaziou writes: > Bernt Hansen writes: > >> Publishing with an automatically generated index file is broken for me. >> >> With org-publish-projects set with >> >> :auto-sitemap t >> :sitemap-filename "index.html" >> :sitemap-title "Test Publishing Area" >> :sitemap-style "tree" > > I think reverting changes on headlines in HTML and DocBook exporters is > the best option for now. > > Does the following patch work? Yes, this patch works for me. Thanks! Regards, Bernt
[O] bug#9913: 24.0.91; ELPA: OpenDocument Text exporter for Org
Jambunathan K wrote: > I would like to submit my OpenDocument Text exporter for Org to GNU ELPA. Org is already in GNU ELPA (with daily snapshots IIUC), so if your package is accepted into Org it will automatically be in GNU ELPA.
[O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, Properties can be specified in the properties drawer. But multiple-line ones cannot at present (at least not without serializing the way multiple-line macros are serialized). Therefore you propose new syntax for multiple-line properties. I propose that allowing the properties drawer to handle multiple-line properties might have 3 advantages over adding block syntax. 1: If you want a single-line property, you have a choice. If you want a multiple-line property, you have to use a block. That seems inconsistent. 2: Some people would probably have use for multiple-line properties, such as in org-contacts. Doesn't have to be Babel. People are used to the properties drawer. Also, external parsers are. 3: Nic objects to blocks without discussing them first. Perhaps upgrading properties drawer will satisfy that objection /and/ be consistent /and/ allow further uses in Org. This all presumes we're sticking with properties for Babel. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
[O] bug#9913: 24.0.91; ELPA: OpenDocument Text exporter for Org
Glenn Morris writes: > Jambunathan K wrote: > >> I would like to submit my OpenDocument Text exporter for Org to GNU ELPA. > > Org is already in GNU ELPA (with daily snapshots IIUC), so if your > package is accepted into Org it will automatically be in GNU ELPA. True. But the fact is ODT exporter is not yet part of the Org proper. Long story: Org's git repo has a ./lisp/ dir and a ./contrib/lisp/ dir. ODT exporter resides in ./contrib/lisp/ and ./contrib/odt/ directories of the git repo. Since Org's ELPA tarball contain only the main lisp files and not contrib lisp files, ODT exporter is *not* available as part of daily snapshots. Here is Org's git tree for reference: http://orgmode.org/w/?p=org-mode.git;a=tree
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
My concerns with respect to a property drawer solution are two fold. 1) In the same way that #+PROPERTY: assumes its value will live on a single line, property drawers assume that their values will live on a single line. I don't see how it will be easier to fold multi-line properties into drawers than outside of drawers. 2) It is not possible to specify file-wide properties with drawers, unlike with property lines. Thanks -- Eric Samuel Wales writes: > Hi Eric, > > Properties can be specified in the properties drawer. But > multiple-line ones cannot at present (at least not without serializing the way > multiple-line macros are serialized). > > Therefore you propose new syntax for multiple-line properties. > > I propose that allowing the properties drawer to handle multiple-line > properties might have 3 advantages over adding block syntax. > > 1: If you want a single-line property, you have a choice. If you want > a multiple-line > property, you have to use a block. That seems inconsistent. > > 2: Some people would probably have use for multiple-line properties, such > as in org-contacts. Doesn't have to be Babel. People are used to the > properties drawer. Also, external parsers are. > > 3: Nic objects to blocks without discussing them first. > > Perhaps upgrading properties drawer will satisfy that objection /and/ be > consistent /and/ allow further uses in Org. > > This all presumes we're sticking with properties for Babel. > > Samuel > > -- > The Kafka Pandemic: http://thekafkapandemic.blogspot.com > === > Bigotry against people with serious diseases is still bigotry. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Incorrect html export link for "%252F" forward slash
At Fri, 28 Oct 2011 18:15:47 -0700, Robert Hotchkiss wrote: > > > Remember to cover the basics, that is, what you expected to happen and > what in fact did happen. You don't know how to make a good report? See > > http://orgmode.org/manual/Feedback.html#Feedback > > Your bug report will be posted to the Org-mode mailing list. > > > Problem: when exporting as html an org file that has links with URLs that > contain > "%252F" for a forward slash, the resulting html link description differs > significantly from the link definition listed in the orgfile. For > example, in the following example, the org file link description is > > "Cannot reinstall an agent" > > Whereas the resulting browser link is > > href="http://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=/com.ibm.tpc_V421.doc/fqz0_r_tbs_agent_cleanup.html";>//publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=/com.ibm.tpc_V421.doc/ > fqz0_r_tbs_agent_cleanup.html > > and this link is surrounded by additional text, including the original > link description. The resulting href is correct and thus clicking on the > links takes the browser user to the correct web page, but the > extraneous and descriptive text is unexpected behavior. Thanks for the report. I can confirm this for Org 7.7, it seems to be fixed in current master, i.e. the link exports to: , | Then clean up common agent residue: http://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=%2Fcom.ibm.tpc_V421.doc%2Ffqz0_r_tbs_agent_cleanup.html";>Cannot reinstall an agent in TPC 4.2.1 InfoCenter ` Best -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgptSfIg6NN9p.pgp Description: PGP signature
Re: [O] C-c C-c not working at end of #+end_src line (was: [RFC] Standardized code block keywords)
Am Montag 31 Oktober 2011, 20:01:14 schrieb Eric Schulte: > Daniel Bausch writes: > > I did some tests with my documents and they look fine. Thanks for your > > work. > > Great, good to know. > > > (A minor remark, offtopic: If the document ends just below a source > > code block, no results are inserted when the block is executed. You > > have to insert an additional blank line, for a result to can appear.) > > I can't reproduce this problem. Ok, I played around and found that what I saw has nothing to do with a blank line existing or not, but only with the position of point. What I observed happens if point is at the end of the #+end_src line. If you press C-c C-c there then you get "Local setup has been refreshed" if there is a newline following. If the documents ends just there, then you get "org-mode fontification error". In both cases no result is produced. I think it is a very common case that one wants to execute a code block right after typing #+end_src, so that point position should "belong" to the code block. If you move one character left, so you are between r and c, then C-c C-c works as expected. If you need an example, use that #+begin_src R 42 #+end_src It even does not matter, whether there is additional text following.
