> Nicolas Goaziou writes:
> As a matter of fact, going to the end of an entry is not negligible, because
> of inlinetasks. Also, it is not really O(1) since it depends on the size of
> the entry. To get an idea, on my computer, moving past a 500 lines entry
> takes around 0.001s. I can imagin
John Wiegley writes:
> Thanks for discussing this with me, Nicolas. I appreciate there may be
> technical complexities involved. Could we special-case allow PROPERTIES to be
> the *very last thing* in an entry? I don't need it to float anywhere else. I
> just like it to be at the end.
I think it
i do not claim to understand the code but org-export-get-environment
is possibly calling org-id-find on entire buffer instead of subtree.
perhaps this explains why exporting a couple of lines without any
org-id link takes 15s to a minute or so.
it is always checking all of my files for org id eve
> Fixed. Thank you.
thanks.
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Ramsay's disease DOES progress. MANY people have died from it. And
ANYBODY can get it.
Denmark: free Karina Hansen NOW.
> Achim Gratz writes:
> I don't think so. Search for end of entry can be complex in itself and you
> would never know if the properties you find by looking back aren't belonging
> to an entry one level down unless you scanned the whole span again. Also,
> properties can be any size and you ha
John Wiegley writes:
>> Jonathan Leech-Pepin writes:
>> Wouldn't last item in entry scale without issues? Find end of headline
>> (start of next or end of buffer) and search backwards. If first element from
>> end is a property drawer you have it, otherwise you still know there is
>> none.
>
>
Eric S Fraga writes:
> On Tuesday, 3 Nov 2015 at 15:54, Phillip Lord wrote:
>> I am trying to implement a new backend based on the HTML export. I need
>> to do some post-processing to the source blocks that needs to be
>> optional. For some blocks I need to replace "[" with "\[" and for some I
>
> Jonathan Leech-Pepin writes:
> Wouldn't last item in entry scale without issues? Find end of headline
> (start of next or end of buffer) and search backwards. If first element from
> end is a property drawer you have it, otherwise you still know there is
> none.
That sounds even better tha
On November 3, 2015 4:31:11 PM EST, Achim Gratz wrote:
>John Wiegley writes:
>> Thanks for discussing this with me, Nicolas. I appreciate there may
>be
>> technical complexities involved. Could we special-case allow
>PROPERTIES to be
>> the *very last thing* in an entry? I don't need it to float
> Achim Gratz writes:
> Well, that's precisely the thing that doesn't scale and that Nicolas wanted
> to avoid. Putting the properties at the beginning of an entry makes the
> search pretty much constant time and if you find something else at the start
> of the entry then you know there aren'
John Wiegley writes:
> Thanks for discussing this with me, Nicolas. I appreciate there may be
> technical complexities involved. Could we special-case allow PROPERTIES to be
> the *very last thing* in an entry? I don't need it to float anywhere else. I
> just like it to be at the end.
Well, that's
> Nicolas Goaziou writes:
> I'd rather not have syntax too much customizable, for portability, ease of
> maintenance, too. There are already too many mistakes in that area.
Thanks for discussing this with me, Nicolas. I appreciate there may be
technical complexities involved. Could we specia
> From: Emanuel Evans
> Date: Tue, 03 Nov 2015 10:14:33 -0800
>
> Eli Zaretskii writes:
>
> > Are you sure this isn't a problem with Org mode? If not, can you tell
> > why you think so?
>
> Oh, I think it could definitely be a problem with Org mode, I just
> thought this would be the right pl
John Wiegley writes:
> Since it scales for my use case, can I please have a customization variable to
> relax this restriction?
I'd rather not have syntax too much customizable, for portability, ease
of maintenance, too. There are already too many mistakes in that area.
Also, please note that p
Oops.
(set org-capture-templates '(...
should be
(set org-capture-templates `(...
On Tue, Nov 3, 2015 at 12:28 PM, Nick Dokos wrote:
> Shankar Rao writes:
>
> > I'm trying to use to org-capture insert tables into a datetree that I
> use to manage my finances. Below is the capture template
Shankar Rao writes:
> I'm trying to use to org-capture insert tables into a datetree that I use to
> manage my finances. Below is the capture template I set up for it. Is there a
> way to make the table be aligned
> after I finalize the capture?
>
> Shankar
>
> -
>
> (setq org-capture-templ
* lisp/ob-calc.el (org-babel-calc-eval-string): Clean up the stack after
expression
evaluation.
---
lisp/ob-calc.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index e8b43e7..2656f27 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
* lisp/ob-calc.el (org-babel-calc-eval):
(org-babel-calc-set-env):
(org-babel-calc-reset-env):
(org-babel-calc-store-env):
(org-babel-calc-eval-string):
(org-babel-calc-eval-line): New funcion.
(org-babel-execute:calc): Rewrite to use new functions.
This also makes ob-calc useful for computing com
> Nicolas Goaziou writes:
> It is for efficiency reasons. Properties are an important feature in Org,
> letting them anywhere in a potentially long entry doesn't scale well.
Since it scales for my use case, can I please have a customization variable to
relax this restriction? I prefer PROPER
* lisp/org.el (org-store-link-props): Rewrite function to get date-timestamp*
calculations.
* lisp/org-gnus.el:
* lisp/org-mhe.el:
* lisp/org-rmail.el:
* contrib/lisp/org-mew.el:
* contrib/lisp/org-vm.el:
* contrib/lisp/org-wl.el: Remove date-timestamp* copy-paste.
* doc/org.texi: Fix `org-captur
---
lisp/org.el | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 6218a3a..a0fe644 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18328,6 +18328,26 @@ If no number is found, the return value is 0."
(s
Hello.
While my assignment is snail-mail delivered to and processed by FSF
I'd like to request comments on the following set of patches, which
contains all the patches I sent to this list before and some new ones.
I'm mainly worried by ChangeLog format and possibly unorthodox elisp
in ob-calc.
T
TINYCHANGE
---
lisp/org-clock.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 09f8391..ad423f1 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2774,7 +2774,7 @@ following structure:
(LEVEL HEADLINE TIMESTAMP TIME)
* lisp/org-agenda.el:
* lisp/org-clock.el:
* lisp/org-colview.el:
* lisp/org.el:
* contrib/lisp/org-depend.el:
* contrib/lisp/ox-taskjuggler.el: Rename (org-duration-string-to-minutes)
to (org-clocksum-string-to-minutes).
---
contrib/lisp/org-depend.el | 2 +-
contrib/lisp/ox-taskjuggler.el
* lisp/org-clock.el (org-clock-time%): Respect org-effort-durations.
This also fixes a bug with time percents looking pretty much random and adding
to a number that is less than 100% when a clock report has long intervals
(e.g. days).
---
lisp/org-clock.el | 29 +++--
1 fi
TINYCHANGE
---
lisp/org-colview.el | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index b698801..d27abc3 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -1113,6 +1113,9 @@ display, or in the #+COLUMNS line of the current buffer."
* contrib/lisp/org-notmuch.el (org-notmuch-store-link): Add date support.
* doc/org.texi: Fix `org-capture-templates' documentation.
---
contrib/lisp/org-notmuch.el | 7 ---
doc/org.texi| 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/contrib/lisp/org-notm
i am running emacs on a chromebook namely emacs 24.4.1 and org
8.3.1-87-g4ef2c0...) on
chromebrew(https://skycocker.github.io/chromebrew/) . My question:How
to make emacs org-mode open links to sites in Google Chrome?How to
make emacs org-mode open links to sites in Google Chrome
thanks in adva
Hello,
John Wiegley writes:
>> Nicolas Goaziou writes:
>
>> This is not a bug. The order is HEADLINE (SCHEDULED PROPERTIES).
>
> Ah, I had misspoken. It's not SCHEDULE-before-PROPERTIES that has broken for
> me, it is the inability to have PROPERTIES at the very end of the entry.
>
> Why mu
> Nicolas Goaziou writes:
> This is not a bug. The order is HEADLINE (SCHEDULED PROPERTIES).
Ah, I had misspoken. It's not SCHEDULE-before-PROPERTIES that has broken for
me, it is the inability to have PROPERTIES at the very end of the entry.
Why must the properties drawer appear before the
Hi,
Kaushal Modi writes:
> What are your favorite org contrib/ packages that you simply can't
> live without
ox-koma-letter.el seems to be the only contrib package I load in my init.
I have used org-drill.el in the past.
Rasmus
--
This is the kind of tedious nonsense up with which I will no
Kaushal Modi writes:
What are your favorite org contrib/ packages that you simply
can't live without, and consider them to be a part of your
org-mode core?
org-contacts and org-passwords, definitely. Sometimes I use
org-checklist.
--
Jorge.
I'm trying to use to org-capture insert tables into a datetree that I use
to manage my finances. Below is the capture template I set up for it. Is
there a way to make the table be aligned after I finalize the capture?
Shankar
-
(setq org-capture-templates
'(...
("f" "Add Tables" plain
HI all,
What are your favorite org contrib/ packages that you simply can't
live without, and consider them to be a part of your org-mode core?
For now, I compile just 3 contrib/ packages by putting the below in my local.mk:
ORG_ADD_CONTRIB = org-eldoc org-mime org-eww
--
Kaushal Modi
The issue got fixed when I changed the below in my local.mk file and
rebuilt org:
From
ORG_ADD_CONTRIB = org-mime org-eww
To
ORG_ADD_CONTRIB = org-eldoc org-mime org-eww
I figured out why I was seeing the problem:
I have org-plus-contrib installed too. So when `package-initialize`
was called,
I have bound org-capture to "C-c c" and "C-c c j" is working fine when
using the latest version of org-plus-contrib from org elpa.
Hi all,
I am on the following build of emacs:
Emacs version: GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+
Version 2.24.23)
of 2015-11-02, built using commit 5401bb8645f955b6fde8c0a5e5c8cf5ec1cab626.
./configure options:
--prefix=/home/kmodi/usr_local/apps/6/emacs/master
'CPPFLAGS=-fgnu
On Tue, 3 Nov 2015, Rainer M Krug wrote:
Hi
The following code block returns a wrong table / list:
#+begin_src R :results value list
list(1:10, 1:5)
#+end_src
#+RESULTS:
- (1 1)
- (2 2)
- (3 3)
- (4 4)
- (5 5)
- (6 1)
- (7 2)
- (8 3)
- (9 4)
- (10 5)
The result is actually in R:
In parti
On Tuesday, 3 Nov 2015 at 15:54, Phillip Lord wrote:
> I am trying to implement a new backend based on the HTML export. I need
> to do some post-processing to the source blocks that needs to be
> optional. For some blocks I need to replace "[" with "\[" and for some I
> don't.
>
> I am not sure wh
Hello,
Stelian Iancu writes:
> I have an org file with calendar appointments. I also have attachments
> to the appointments. The attachment appears in a PROPERTIES drawer.
>
> Now if I have the timestamp (plain one) before the drawer, I cannot
> open the attachment. Pressing C-c C-a o just inser
I am trying to implement a new backend based on the HTML export. I need
to do some post-processing to the source blocks that needs to be
optional. For some blocks I need to replace "[" with "\[" and for some I
don't.
I am not sure whether to use headers or switches.
So
#+begin_src java -s
st
On 03/11/15 14:46, Marco Wahl wrote:
John Wiegley writes:
Puneeth Chaganti writes:
Actually there has been introduced a constraint on the ordering planning
lines and property drawers in 8.3. See http://orgmode.org/Changes.html.>
This at least invalidates to use PROPERTIES before SCHEDULED
Hi,
on orgmode 8.3.2 I've got a large org-file. Offen, I need to export a subtree
like this:
-
* Subtree to be exported
:PROPERTIES:
:EXPORT_FILE_NAME: /PATH/TO/FOLDER/filename
:EXPORT_TITLE:
:END:
foo
-
I'd like to save the exported file in a project folder, a
John Wiegley writes:
>> Puneeth Chaganti writes:
>
>>> Actually there has been introduced a constraint on the ordering planning
>>> lines and property drawers in 8.3. See http://orgmode.org/Changes.html.>
>>> This at least invalidates to use PROPERTIES before SCHEDULED afaics.
>
>> Yes, that
Hi
Considering the following example:
--8<---cut here---start->8---
#+NAME t1
#+begin_src R :colnames yes
data.frame(a = 1:3)
#+end_src
#+RESULTS:
| a |
|---|
| 1 |
| 2 |
| 3 |
#+NAME t2
#+begin_src R :colnames yes
data.frame(b = 1:10)
#+end_src
#+RESULTS:
|
> Puneeth Chaganti writes:
>> Actually there has been introduced a constraint on the ordering planning
>> lines and property drawers in 8.3. See http://orgmode.org/Changes.html.>
>> This at least invalidates to use PROPERTIES before SCHEDULED afaics.
> Yes, that is correct and you can use th
Hi
The following code block returns a wrong table / list:
#+begin_src R :results value list
list(1:10, 1:5)
#+end_src
#+RESULTS:
- (1 1)
- (2 2)
- (3 3)
- (4 4)
- (5 5)
- (6 1)
- (7 2)
- (8 3)
- (9 4)
- (10 5)
The result is actually in R:
#+begin_src R :results output
list(1:10, 1:5)
#+end_sr
On Tue, Nov 3, 2015 at 3:26 PM, Marco Wahl wrote:
>
>
> Actually there has been introduced a constraint on the ordering planning
> lines and property drawers in 8.3. See http://orgmode.org/Changes.html.
>
> This at least invalidates to use PROPERTIES before SCHEDULED afaics.
Yes, that is correc
On Monday, 2 Nov 2015 at 15:37, Ian Barton wrote:
> Next year our mountaineering club has its 50th anniversary. On the
> 21st anniversary we published a book of articles written by members of
> the club.
[...]
> However, as a Latex
> neophyte I was wondering which of the several Latex packages w
"Mark A. Hershberger" writes:
> org-habit.el is sensitive to the ordering PROPERTIES and SCHEDULED
> and expects them /in only/ the following order:
>
> * TODO habit name
> SCHEDULED: <2015-11-03 Tue 07:00 .+1d>
> :PROPERTIES:
> :LAST_REPEAT: [2015-11-02 Mon 07:54]
> :STYLE: habit
> :END:
>
50 matches
Mail list logo
