Re: [O] Patch for testing `org-open-at-point'

[Bastien]

Hi Achim,

Achim Gratz  writes:

> Bastien writes:
>> Achim Gratz  writes:
>>> Shouldn't the test check that the desired target is actually
>>> reached?
>>
>> That would be too complicated.  Checking that `org-open-at-point'
>> does not throw an error is enough IMO.
>
> I don't think so.  Implemented a check for that in 8e72c8fcfa.

Okay, thanks.  I pushed a small update, separating tests where we test
that `org-open-at-point' correctly opens the link at point, and tests
where we only tests that it correctly runs in a specific context.

-- 
 Bastien

Re: [O] How to find the headline matching a string

[Thorsten Jolitz]

Eric Abrahamsen  writes:

> Thorsten Jolitz  writes:
>
>> Chris Poole  writes:
>>
>>> Eric Abrahamsen:
 the `org-map-entries' function can be given a scope of 'agenda
>>>
>>> That worked perfectly, thanks. Here's what I ended up with:
>>>
>>> (org-map-entries (lambda ()
>>> (when (equal title (org-get-heading t t))
>>> (org-entry-put (point) "TODO" "DONE")))
>>> tag 'agenda)
>>
>> As much as I like the powerful `org-map-entries', I wonder if it will
>> coexist with `org-element-map' in the future, since it does not use the
>> new parser. 
>>
>> Whats the recommendation here? Should one rather use 
>>
>> ,---
>> | (org-element-map (org-element-parse-buffer) 'headline (lambda () ...))
>> `---
>>
>> nowadays, or do both functions serve different purposes, or is it just a
>> matter of taste?
>
> Interesting! I wasn't even aware of org-element-map, thanks for that.
> Obviously I don't know the answer to your question, but they do seem to
> do very similar things. On the other hand, `org-element-map' won't do
> multiple files, and if you want to restrict to certain elements you have
> to do the matching logic yourself (as opposed to `org-map-entries's
> agenda-style search string).
>
> I'd be curious, too, to hear if `org-map-entries' is going to get EOL'd
> at some point. I suppose it's safe so long as `org-scan-tags' remains
> the heart of the agenda process.
>
> Here's my stab at two roughly equivalent functions, one using
> org-element, the other older function. Just for the hell of it I tried
> using "benchmark" to profile them, but have no idea if the results mean
> much of anything. Most importantly, I don't really know if
> `org-element-parse-buffer' ends up using the cache or not -- I assume
> not.
>
> (defun my-find-title-element-map (title)
>   (interactive "sTitle: ")
>   (let ((files (org-agenda-files))
>   found)
> (dolist (f files)
>   (with-current-buffer (org-get-agenda-file-buffer f)
>   (org-element-map (org-element-parse-buffer 'headline)
>   'headline
> (lambda (hl)
>   (when (string= title (org-element-property :title hl))
> (push (move-marker (make-marker)
>(org-element-property :begin hl))
>   found))
> found))
>
>
> (defun my-find-title-entries-map (title)
>   (interactive "sTitle: ")
>   (let (found)
> (org-map-entries
>  (lambda ()
>(when (string= title (org-get-heading t t))
>(push (move-marker (make-marker)
>   (line-beginning-position))
>  found)))
>  nil 'agenda)
> found))
>
> (benchmark-run 100 (my-find-title-element-map "Unique Heading Text"))
> => (164.576821235 142 23.892782392000186)
>
> (benchmark-run 100 (my-find-title-entries-map "Unique Heading Text"))
> => (58.111630133 36 6.04777874516)

This is interesting too - and a bit surprising. On my machine, the
org-element based function takes almost 4 times as long as the
org-map-entries based function:

#+BEGIN_SRC emacs-lisp
(defun my-find-title-element-map (title)
  (interactive "sTitle: ")
  (let ((files (org-agenda-files))
found)
(dolist (f files)
  (with-current-buffer (org-get-agenda-file-buffer f)
(org-element-map (org-element-parse-buffer 'headline)
'headline
  (lambda (hl)
(when (string= title (org-element-property :title hl))
  (push (move-marker (make-marker)
 (org-element-property :begin hl))
found))
found))
#+END_SRC

#+results:
: my-find-title-element-map

#+BEGIN_SRC emacs-lisp
(defun my-find-title-entries-map (title)
  (interactive "sTitle: ")
  (let (found)
(org-map-entries
 (lambda ()
   (when (string= title (org-get-heading t t))
 (push (move-marker (make-marker)
(line-beginning-position))
   found)))
 nil 'agenda)
found))
#+END_SRC

#+results:
: my-find-title-entries-map

#+BEGIN_SRC emacs-lisp :results raw
 (benchmark-run 30 (my-find-title-element-map "Unique Heading Text"))
#+END_SRC

#+results:
(160.439753043 735 76.66140414599985)

# => (164.576821235 142 23.892782392000186)

#+BEGIN_SRC emacs-lisp :results raw
 (benchmark-run 30 (my-find-title-entries-map "Unique Heading Text"))
#+END_SRC

#+results:
(37.97359562205 123 12.137436705999733)

# => (58.111630133 36 6.04777874516)


-- 
cheers,
Thorsten

Re: [O] How to find the headline matching a string

[Eric Abrahamsen]

Thorsten Jolitz  writes:

> Eric Abrahamsen  writes:
>
>> Thorsten Jolitz  writes:
>>
>>> Chris Poole  writes:
>>>
 Eric Abrahamsen:
> the `org-map-entries' function can be given a scope of 'agenda

 That worked perfectly, thanks. Here's what I ended up with:

 (org-map-entries (lambda ()
 (when (equal title (org-get-heading t t))
 (org-entry-put (point) "TODO" "DONE")))
 tag 'agenda)
>>>
>>> As much as I like the powerful `org-map-entries', I wonder if it will
>>> coexist with `org-element-map' in the future, since it does not use the
>>> new parser. 
>>>
>>> Whats the recommendation here? Should one rather use 
>>>
>>> ,---
>>> | (org-element-map (org-element-parse-buffer) 'headline (lambda () ...))
>>> `---
>>>
>>> nowadays, or do both functions serve different purposes, or is it just a
>>> matter of taste?
>>
>> Interesting! I wasn't even aware of org-element-map, thanks for that.
>> Obviously I don't know the answer to your question, but they do seem to
>> do very similar things. On the other hand, `org-element-map' won't do
>> multiple files, and if you want to restrict to certain elements you have
>> to do the matching logic yourself (as opposed to `org-map-entries's
>> agenda-style search string).
>>
>> I'd be curious, too, to hear if `org-map-entries' is going to get EOL'd
>> at some point. I suppose it's safe so long as `org-scan-tags' remains
>> the heart of the agenda process.
>>
>> Here's my stab at two roughly equivalent functions, one using
>> org-element, the other older function. Just for the hell of it I tried
>> using "benchmark" to profile them, but have no idea if the results mean
>> much of anything. Most importantly, I don't really know if
>> `org-element-parse-buffer' ends up using the cache or not -- I assume
>> not.

> This is interesting too - and a bit surprising. On my machine, the
> org-element based function takes almost 4 times as long as the
> org-map-entries based function:

I guess it shouldn't be too surprising -- the org element stuff is
completely parsing the entire buffer on every pass. The other function
probably boils down to passing a few targeted regexps over the buffer.
I've sneakily cc'd Nicolas to see what he thinks. My guess is we could
replace the call to org-element-parse-buffer with something that
creates/accesses the cached version of the parse tree, and things would
go much more swiftly.

E

Re: [O] Tests do not work

[Cecil Westerhof]

2014-06-02 20:17 GMT+02:00 Achim Gratz :

> Bastien writes:
> > I'd rather add the tests to the Org archives.
>
> Done.
>

​I​

​just downloaded again from:
http://orgmode.org/

But get the same error as before.

-- 
Cecil Westerhof

Re: [O] Tests do not work

[Bastien]

Cecil Westerhof  writes:

> ​I​
>  
> ​just downloaded again from:
>     http://orgmode.org/
>
> But get the same error as before.

As the website says, the tarballs that you download from
http://orgmode.org are built from the latest stable version,
which is currently 8.2.6.

Achim fixed this for the next stable version, which is not
released.

-- 
 Bastien

Re: [O] org-contacts development

[Michael Strey]

Hi Daimrod,

On 2014-05-29, Daimrod wrote:

> Hmm, I kinda like this. It seems a bit verbose but it's better than
> having multiple values per properties (IMHO).
>
> Though, if we adopt this scheme, we would need to add some helper
> bindings/functions so that we don't have to fill this by hands.

I'm using yasnippets and have snippets for organizations, job-related
contacts and private contacts.

I have attached them.

C-c C-x p helps to fill in optional properties.

I have all my contacts in one buffer with the following settings

#+BEGIN_SRC org
* Buffer settings
#+STARTUP: overview
#+STARTUP: hidestars
#+STARTUP: indent
#+TAGS: ADMIN(i) CHEF(f) EINKAUF(k) PRIVAT(t) SEKRETARIAT(s) 
#+TAGS: AUTO(u) BROADCASTER(b) DAB(d) DVB(v) EMPFÄNGER(m) HOCHSCHULE(h) 
NETZBETREIBER(n) SYSTEM(y) B2B B2C REG
#+TAGS: MAIL(l) PRESSE(e) KUNDE COMPETITOR
#+TAGS: ABI CI FAMILIE FREUNDE SCHULE TAICHI TURNEN
#+SEQ_TODO: TODO(t) NEXT(n) WAITING(w) | DONE(d) CANCELLED(c)
#+PROPERTY: Contact_Type_ALL individual organization
#+PROPERTY: Language_ALL de en ru
#+PROPERTY: Phone_1_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_2_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_3_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_4_Type_ALL Work Home Fax Mobile
#+PROPERTY: Address_1_Type_ALL Work Home Post
#+PROPERTY: Address_2_Type_ALL Work Home Post
#+PROPERTY: Address_3_Type_ALL Work Home Post
#+PROPERTY: Website_1_Type_ALL Work Home
#+PROPERTY: Website_2_Type_ALL Work Home
#+END_SRC


>> Other user defined properties can be added and mapped to the appropriate
>> user defined keys during export.
>
> I'm not sure to understand what you mean. Could you give more details
> and maybe an example?

Actually, my statement was trivial.  Orgmode allows to define and add
every kind of additional properties.  What I wanted to say was that it
is possible to export those additional properties to Google Contacts as
well.

I have for instance the property :Language: that is not part of the
Google API.  I use it to store the preferred language of correspondence
for my job-related contacts for mailing actions.

Google Contacts accepts such fields in the CSV file to import and
creates user defined fields from them.


>> Please note that org-collector tries to convert property values from
>> strings into numbers if possible.  For postal codes with leading Zeros
>> this can lead to unexpected results.  I did not find any other way to
>> solve this problem than to add a national code like in the following
>> example
>>
>> :Address_1_Code:  01169
>> would lead to "1169" in the propview table.
>>
>> so I replaced it with
>> :Address_1_Code:  DE-01169
>
> What is `org-collector' and when does it happen?

>From the Orgmode manual:

"An alternative way to capture and process property values into a table
is provided by Eric Schulte's org-collector.el which is a contributed
package.  It provides a general API to collect properties from entries
in a certain scope, and arbitrary Lisp expressions to process these
values before inserting them into a table or a dynamic block."

I'm using org-collector to create a table that can be exported to CSV
for import into Google Contacts (and maybe other contact managers).

> I've done a quick test and the 0 appears in `org-contacts-db'.

Yes, everything is fine with org-contacts.  The problem comes only from
org-collector.  The reason is org-collector's feature to allow Lisp
expressions to process property values.  Therefore it uses the function
`org-babel-read' that detects Lisp expressions and converts strings into
numbers.

So this remark is only relevant for those who want to follow my track with the
org-collector export.

-- 
Michael Strey 
www.strey.biz

#name : Contact Individual
#key : contact
#contributor : Michael Strey <[EMAIL PROTECTED]>
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
 ${1:surname}, ${2:name}
:LOGBOOK:
- Contact added: [`(org-read-date nil nil "+0d")`]
:END:

:PROPERTIES:
:Contact_Type: individual
:Organization_1_Type: company
:Organization_1_Value: ${3:organisation}
:Organization_1_Department: ${4:devision}
:Organization_1_Title: ${5:title}
:FN: $2 $1
:Given_Name: $2
:Family_Name: $1
:Nickname: $19 $1
:Address_1_Type: Work
:Address_1_Street: ${6:adr1}
:Address_1_Box: ${7:adr2}
:Address_1_Extension: ${8:adr3}
:Address_1_City: ${9:city}
:Address_1_Region: ${10:state} 
:Address_1_Code: ${11:zip_code}
:Address_1_Country: ${12:country}
:Email_1_Type: Work
:Email_1_Value: ${13:company_email}
:Phone_1_Type: Work
:Phone_1_Value: ${14:tel}
:Phone_2_Type: Mobile
:Phone_2_Value: ${15:mobile}
:Phone_3_Type: Fax
:Phone_3_Value: ${16:fax}
:Website_1_Type: Work
:Website_1_Value: http://$17
:Language: $18
:END:
$0
#name : Contact Individual (private)
#key : privat
#contributor : Michael Strey <[EMAIL PROTECTED]>
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
 ${1:surname}, ${2:name}   :NEW:
:LOGBOOK:
- Contact added: [`(org-read-date nil nil "+0d

Re: [O] Tests do not work

[Cecil Westerhof]

2014-06-03 12:11 GMT+02:00 Bastien :

> Cecil Westerhof  writes:
>
> > ​I​
> >
> > ​just downloaded again from:
> > http://orgmode.org/
> >
> > But get the same error as before.
>
> As the website says, the tarballs that you download from
> http://orgmode.org are built from the latest stable version,
> which is currently 8.2.6.
>
> Achim fixed this for the next stable version, which is not
> released.
>

​I interpreted:
I'd rather add the tests to the Org archives.

That they where added to the current one.

But no problem: I can wait till the next release. :-)

-- 
Cecil Westerhof

[O] org-agenda-mode: Symbol's value as variable is void: org-agenda-archives-mode

[Thorsten Jolitz]

Hi List, 
after updating yesterday to 

#+begin_src emacs-lisp
  (call-interactively 'org-version)
#+end_src

#+results: 
: Org-mode version 8.2.6 (release_8.2.6-1123-g024a05 @
/usr/share/emacs/24.3/lisp/org/lisp/)

I got this error when opening the agenda today:

,--
| org-agenda-mode: Symbol's value as variable is void: org-agenda-archives-mode
`--

A quick google search led to a solution from this
[[http://irreal.org/blog/?p=2030][Blog]] entry posted on 2013-08-02:

Put this in init.el
,-
| (setq org-agenda-archives-mode nil)
| (setq org-agenda-skip-comment-trees nil)
| (setq org-agenda-skip-function nil)
`-

Is this a bug/regression or a personnal setup thing?

-- 
cheers,
Thorsten

Re: [O] org-agenda-mode: Symbol's value as variable is void: org-agenda-archives-mode

[Bastien]

Hi Thorsten,

Thorsten Jolitz  writes:

> Is this a bug/regression or a personnal setup thing?

Probably something in your setup.

Can you try

  emacs -l ~/minimal.el

with minimal.el containing something like

  (add-to-list 'load-path "~/install/git/org-mode/lisp/")
  (require 'org)

then call M-x org-agenda RET ?

-- 
 Bastien

Re: [O] how to use :options-alist in org-export-define-derived-backend ?

[Bastien]

Hi Nicolas,

Nicolas Richard  writes:

> I'm trying to play with the exporter but I'd like my back-end to have no
> toc by default. I tried
>
> (org-export-define-derived-backend 'mytest 'html
>   :translate-alist
>   ;; don't use the template, concentrate on the toc.
>   (list (cons 'template (lambda (a _) a))) 
>   :options-alist
>   '((:with-toc nil "toc" nil)))
>
> IIUC, the last "nil" up there should be the default value for :with-toc.

I used this in contrib/lisp/ox-rss.el

  :options-alist
  '((:with-toc nil nil nil) ;; Never include HTML's toc

with `nil' instead of "toc".

Perhaps some hint lies down here (like "toc" indicating the exporter
should rely on the buffer-local value of `org-export-with-toc'?) but
I'm not really sure, I hope Nicolas can clarify.

-- 
 Bastien

Re: [O] how to use :options-alist in org-export-define-derived-backend ?

[Nicolas Goaziou]

Hello,

Nicolas Richard  writes:

> I'm trying to play with the exporter but I'd like my back-end to have no
> toc by default. I tried
>
> (org-export-define-derived-backend 'mytest 'html
>   :translate-alist
>   ;; don't use the template, concentrate on the toc.
>   (list (cons 'template (lambda (a _) a))) 
>   :options-alist
>   '((:with-toc nil "toc" nil)))
>
> IIUC, the last "nil" up there should be the default value for :with-toc.
> Unfortunately, exporting like this:
>
> (with-temp-buffer
>   (insert "* foo\n** bar\nsome content")
>   (org-export-to-buffer 'mytest "*test*")
>   (pop-to-buffer "*test*"))
>
> will show a table of contents.

FWIW, I cannot reproduce it.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-agenda-mode: Symbol's value as variable is void: org-agenda-archives-mode

[Thorsten Jolitz]

Bastien  writes:

Hi Bastien,

> Thorsten Jolitz  writes:
>
>> Is this a bug/regression or a personnal setup thing?
>
> Probably something in your setup.

yes, apparently,

> Can you try
>
>   emacs -l ~/minimal.el
>
> with minimal.el containing something like
>
>   (add-to-list 'load-path "~/install/git/org-mode/lisp/")
>   (require 'org)
>
> then call M-x org-agenda RET ?

because this works.
Thx

-- 
cheers,
Thorsten

Re: [O] src blocks not fontified

[Shiyuan]

I can only find htmlfontify in ELPA, but not htmlize. Which ELPA repository
will have htmlize?  Or I need to install the .el file manually. I can find
the htmlize.el in the following link, but not sure it's up to date.
http://www.emacswiki.org/emacs-ja/htmlize.el.

Thank you.


On Sun, Jun 1, 2014 at 3:46 PM, Omid  wrote:

> One way is to use the package htmlize, which you can install from ELPA
> using M-x package-install RET htmlize
>
> http://www.emacswiki.org/emacs/Htmlize
>
> Omid
>
> Sent from my Emacs
>
> On 06/01/2014 06:40 PM, Shiyuan wrote:
> > That solves the problem. Thanks Omid.
> > Should this be the default setup? It seems more nature to fontify the
> > src block than not.
> >
> > Also, when I export the org file to html, the src block is not fontified
> > in the resulting html webpage. Is there another option to turn this
> > function on? Thanks.
> >
> >
> > On Sun, Jun 1, 2014 at 3:17 PM, Omid  > > wrote:
> >
> > Hi Shiyuan,
> >
> > Add
> >
> > (setq org-src-fontify-natively t)
> >
> > to your .emacs.
> >
> > Omid
> >
> > Sent from my Emacs
> >
> > On 06/01/2014 06:13 PM, Shiyuan wrote:
> > > Hi,
> > > I am using Emacs 24.3 with the built-in org mode(7.9.3). The
> src
> > > code block is not fontified (Emacs is started with -Q option)
> > > #+BEGIN_SRC emacs-lisp
> > > (defun org-xor (a b)
> > >   "Exclusive or."
> > > (if a (not b) b))
> > > #+END_SRC
> > >
> > > This is my first time to use org-mode, so I could miss some setup
> > > steps.Do I need to do any setup in my .emacs if I just use the
> > built-in
> > > org?
> > >
> > > Thanks.
> > >
> > > Shiyuan
> >
> >
>

Re: [O] src blocks not fontified

[Nick Dokos]

Shiyuan  writes:

> I can only find htmlfontify in ELPA, but not htmlize. Which ELPA
> repository will have htmlize?  Or I need to install the .el file
> manually. I can find the htmlize.el in the following link, but not
> sure it's up to date.  
> http://www.emacswiki.org/emacs-ja/htmlize.el. 
>

htmlize.el is included in the contrib/lisp directory of org (but I'm not
sure if contrib is part of the ELPA org distribution - it is available
if you get org from the git repo or from the tarball). The one I have
says:

,
| ;;; htmlize.el --- Convert buffer text and decorations to HTML.
| 
| ;; Copyright (C) 1997-2013 Hrvoje Niksic
| 
| ;; Author: Hrvoje Niksic 
| ;; Keywords: hypermedia, extensions
| ;; Version: 1.43
`

Nick

Re: [O] problem with org-caldav and ox-icalendar: UID property wrapping

[David Engster]

David Engster writes:
> Nicolas Goaziou writes:
>> Eric S Fraga  writes:
>>> I have tracked this down to org-icalendar outputing wrapped lines even
>>> for UID entries:
>>>
>>> ,
>>> | BEGIN:VEVENT
>>> | DTSTAMP:20140507T114443Z
>>> | UID:0400[...]00
>>> |  00[...]6
>>> | DTSTART;TZID=Europe/London:20120403T06
>>> `
>>
>> AFAIU RFC 5545, all lines longer than 75 octets, including UID lines,
>> are expected to be folded. Therefore I think ox-icalendar is right.
>
> Yes, it is.
>
> I've already rewritten that part in org-caldav, but it needs more
> testing. I'll push a fix in the coming days.

Well, that took a bit longer, but I pushed it now...

-David

Re: [O] DTD prohibited

[AW]

Am Dienstag, 3. Juni 2014, 00:34:58 schrieb James Harkins:
> Bastien  gnu.org> writes:
> > Hi Alexander,
> > 
> > AW  t-online.de> writes:
> > > Now, Word no longer can open the html-documents produced by orgmode. The
> 
> error
> 
> > > message is (translated from German): "DTD prohibited".
> > 
> > You may want to customize `org-html-doctype' but you probably need to
> > digg further to know what DTD is prohibited exactly.
> 
> Apparently, all of them:
> 
> http://en.m.wikipedia.org/wiki/Document_Type_Definition
> 
> Under "Security":
> 
> ~~
> An XML DTD can be used to create a denial of service (DoS) attack by
> defining nested entities that expand exponentially, or by sending the XML
> parser to an external resource that never returns.[10]
> 
> For this reason, .NET Framework provides a property that allows prohibiting
> or skipping DTD parsing, [10] and recent versions of Microsoft Office
> applications (Microsoft Office 2010 and higher) refuse to open XML files
> that contain DTD declarations.
> ~~
> 
> So, if org ODT export now depends on a DTD, then we'd have to say that we
> don't support exported files that open in MS Word.
> 
> hjh


Hi, 

thank you, I started again digging into this strange thing and the culprit 
seems the first line of the html-file:



If I remove this line, no error.  And removing simply 

xml version="1.0" 

helped as well. Courious. Because of such behaviour I hate Word, but ...

Source: http://stackoverflow.com/a/15816168

Regards,

Alexander

Re: [O] how to use :options-alist in org-export-define-derived-backend ?

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Perhaps some hint lies down here (like "toc" indicating the exporter
> should rely on the buffer-local value of `org-export-with-toc'?) but
> I'm not really sure, I hope Nicolas can clarify.

I spoke too soon. I had `org-export-with-toc' set to nil.

Anyway, this bug is due to a cheesy workaround in order to get original
file name or buffer name if no title is provided. It should work in
maint now, but I suggest to get rid of that behaviour in master, as
suggested in a recent thread.

WDYT?


Regards,

-- 
Nicolas Goaziou

Re: [O] How to find the headline matching a string

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> I guess it shouldn't be too surprising -- the org element stuff is
> completely parsing the entire buffer on every pass. The other function
> probably boils down to passing a few targeted regexps over the buffer.
> I've sneakily cc'd Nicolas to see what he thinks. My guess is we could
> replace the call to org-element-parse-buffer with something that
> creates/accesses the cached version of the parse tree, and things would
> go much more swiftly.

I didn't look closely into the issue, but I think the main reason is
that Element parses headlines thoroughly, including all properties,
scheduled keywords, which is not, by default, the case for
`org-map-entries'.

For most use-cases, you don't need the parser for headlines, as their
grammar is context free. IOW, `org-element-parse-buffer' doesn't predate
`org-map-entries'.


Regards,

-- 
Nicolas Goaziou

Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes

[Nicolas Goaziou]

Hello,

Achim Gratz  writes:

> I'm not wedded to the name, maybe "export" has a nicer ring to it (but
> that#s also been used differently in Babel, just like almost anything
> else you#d be able to come up with).

True.

> What I'm talking about is the list of blocks that never can be export
> blocks (CENTER, QUOTE, SRC, COMMENT, EXAMPLE, VERSE).  These can be
> flagged as errors, anything else is the responsibility of the user.

On second thought, we shouldn't bother too much about it, let the user
provide any keyword, and turn it into a block of the same name.

So, for example, both

  #+include: "file.html" html

and

  #+include: "file.html" center

are valid, even though the second one makes little sense.

It is close to your initial approach, minus the "wrap" keyword, which
seems unnecessary. If you agree with this suggestion, do you volunteer
to finalize it, along with the required documentation?


Regards,

-- 
Nicolas Goaziou

Re: [O] How to find the headline matching a string

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> I guess it shouldn't be too surprising -- the org element stuff is
>> completely parsing the entire buffer on every pass. The other function
>> probably boils down to passing a few targeted regexps over the buffer.
>> I've sneakily cc'd Nicolas to see what he thinks. My guess is we could
>> replace the call to org-element-parse-buffer with something that
>> creates/accesses the cached version of the parse tree, and things would
>> go much more swiftly.
>
> I didn't look closely into the issue, but I think the main reason is
> that Element parses headlines thoroughly, including all properties,
> scheduled keywords, which is not, by default, the case for
> `org-map-entries'.
>
> For most use-cases, you don't need the parser for headlines, as their
> grammar is context free. IOW, `org-element-parse-buffer' doesn't predate
> `org-map-entries'.

Interesting, thanks! I think at first we were unsure if org-map-entries
was going to stay around in the long term, but it sounds like it's not
going anywhere.

E

Re: [O] still seeing semi-regular lockups

[Eric Abrahamsen]

Daimrod  writes:

> Bastien  writes:
>
>> Hi Eric,
>>
>> Eric Abrahamsen  writes:
>>
>>> After Nicolas made the last round of improvements to the caching
>>> mechanism I got far fewer hangs with Org, but they are still happening.
>>> Maybe once a day or so, on average, editing something in an Org buffer
>>> causes emacs to hang, and my fans to spin up, and there we are until I
>>> kill emacs.

[...]

> By the way, if you want to see in which part the infloop occurs, you can
> attach a gdb debugger to the running emacs, source the
> /src/.gdbinit file and use the `xbacktrace' command.
>
> $ gdb  
> gdb) source /src/.gdbinit
> ...
> gdb) xbacktrace
>
> You can also use the `bt' command but it contains much more noise.

I got another one just now (while moving from one org table cell to the
next), and that was the gdb backtrace:

"avl-tree--do-delete" (0xbfffe858)
"avl-tree-delete" (0xbfffe998)
"byte-code" (0xbfffeaa0)
"byte-code" (0xbfffec30)
"org-element--cache-process-request" (0xbfffedd8)
"byte-code" (0xbfffeef0)
"org-element--cache-sync" (0xb0a8)
"org-element-at-point" (0xb1e8)
"org-mode-flyspell-verify" (0xb338)
"flyspell-word" (0xb478)
"byte-code" (0xb580)
"flyspell-post-command-hook" (0xb784)

Not much, and probably not that useful. I'll start running org
uncompiled, and try the debug-on-event trick.

FWIW, this was the first lockup that *didn't* occur in a logbook
drawer -- that's where I usually get them. Either a full lockup, or else
the cache goes wonky so that adding log notes (or even just navigating
in the drawer) gives me that "bound on wrong side of point" you get when
you try to search forwards, backwards.

E