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 ar
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 p
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 int
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 exporte
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
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.
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 Are
* 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
>
> 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 conseq
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 app
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
#+prop
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
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 regula
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)) (
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 implementab
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?
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 kno
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"
> :sitema
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 #+PROPERT
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.
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"
definitel
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 additio
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-li
Would a column formula work?
Samuel
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.
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/p
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 muc
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
Giovann
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
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:
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][Descr
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 li
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
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
>>
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
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 contai
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.
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 wa
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 headlin
>> 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
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
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
41 matches
Mail list logo
