Re: [O] `org-store-link' to skip link storing functions without touching `org-context-in-file-links'

[York Zhao]

> Yeah, org-store-link overloads ARG

Exactly!

> I think that, when negating org-context-in-file-links, the function should
> check whether a single C-u was given rather than just checking if ARG is
> non-nil.

Seems to be a reasonable solution to me. So would you go ahead and make the
change, or, would more people need to agreed on this solution?

> If someone uses C-u C-u to fall back to core Org functions, I don't see
any
> reason to assume that they also want to reverse their
> org-context-in-file-links preference.

Maybe!


Thanks,

York


On Sat, May 20, 2017 at 6:55 PM, Kyle Meyer <k...@kyleam.com> wrote:

> York Zhao <gtdplatf...@gmail.com> writes:
>
> > However, the biggest problem I'm having now is that once I loaded
> > org-git-link.el, I'm forced to always store links linking to git
> repository
> > which is not always I want because I also need to be able to store links
> > linking to the files in the working directory instead of in the git
> > repository.
> >
> > I'm aware of the 'C-u C-u' prefix of `org-store-link', however, by the
> > current design, using 'C-u C-u' negates `org-context-in-file-links',
> i.e.,
> > the link would be stored without embedding the text to search for.
>
> Yeah, org-store-link overloads ARG, and there seems to be an undesirable
> interaction here.
>
> > Is it possible to make `org-store-link' able to skip the link storing
> > functions without touching `org-context-in-file-links'?
>
> I think that, when negating org-context-in-file-links, the function
> should check whether a single C-u was given rather than just checking if
> ARG is non-nil.  If someone uses C-u C-u to fall back to core Org
> functions, I don't see any reason to assume that they also want to
> reverse their org-context-in-file-links preference.
>
> --
> Kyle
>

[O] `org-store-link' to skip link storing functions without touching `org-context-in-file-links'

[York Zhao]

Hi org-mode developers,

Recently I found it very useful to being able to store links linking to
source code in git repository. I used org-git-link.el for this purpose and
it works well.

However, the biggest problem I'm having now is that once I loaded
org-git-link.el, I'm forced to always store links linking to git repository
which is not always I want because I also need to be able to store links
linking to the files in the working directory instead of in the git
repository.

I'm aware of the 'C-u C-u' prefix of `org-store-link', however, by the
current design, using 'C-u C-u' negates `org-context-in-file-links', i.e.,
the link would be stored without embedding the text to search for.

Is it possible to make `org-store-link' able to skip the link storing
functions without touching `org-context-in-file-links'?


Thanks in advance,

York

Re: [O] Document of org-map-entries

[York Zhao]

@Nick:

Thanks for the explanation, it's very kind of you!

@John:

You are right, this actually works. However, this will also exclude the
trees
whose property value is empty, for example, the following tree will be
excluded,
which will not be excluded if "myproperty<>nil" syntax works:

* Tree
:PROPERTIES:
:myproperty:
:END:

But there's probably no point to have such empty property after all. So you
approach is acceptable. Thanks!

Regards,

York


On Thu, Oct 13, 2016 at 11:57 AM, Nick Dokos <ndo...@gmail.com> wrote:

> York Zhao <gtdplatf...@gmail.com> writes:
>
> > Thank you very much Nick.
> >
> > (info "(org) Using the mapping API") was the first doc I read which has
> very little information on how
> > to use the "match" parameter.  (info "(org) Matching tags and
> properties") does have a lot more detail
> > though.
> >
>
> Understood - I like to give more complete information for two reasons:
>
> 1) I don't know what you have seen already, so maybe I can save an
>exchange or two on the list by being more complete - and if you
>have seen it already, no harm done.
>
> 2) Perhaps I'm fooling myself, but I like to think that somebody down
>the line is going to have the same question, and if gmane ever
>comes back :-), they might be able to search the list and find the
>information that they need without having to send an email to the
>list (or even if they do, somebody might be around who remembers
>and can do the search and reply with "See this message").
>
> So no disparagement/offense meant at all, that is just my modus operandi.
>
> Regards,
> --
> Nick
>
>
>

Re: [O] Document of org-map-entries

[York Zhao]

One more question: how do I map only the entries that has a specific
property
defined? The following code didn't work.

(org-map-entries
 (lambda () (...))
 "mytag+myproperty<>nil")

Thanks,


On Thu, Oct 13, 2016 at 1:00 AM, York Zhao <gtdplatf...@gmail.com> wrote:

> Thank you very much Nick.
>
> (info "(org) Using the mapping API") was the first doc I read which has
> very little information on how to use the "match" parameter.  (info "(org)
> Matching tags and properties") does have a lot more detail though.
>
>
> On Thu, Oct 13, 2016 at 12:46 AM, Nick Dokos <ndo...@gmail.com> wrote:
>
>> York Zhao <gtdplatf...@gmail.com> writes:
>>
>>
>> > I wanted to know how to use the MATCH parameter in
>> > `org-map-entries'. I've searched extensively, but was unable to find
>> > much useful information. Can somebody please shed some lights on
>> > this?
>> >
>>
>> See
>>
>>(info "(org) Using the mapping API")
>>
>> and
>>
>>(info "(org) Matching tags and properties")
>>
>> --
>> Nick
>>
>>
>>
>

Re: [O] Document of org-map-entries

[York Zhao]

Thank you very much Nick.

(info "(org) Using the mapping API") was the first doc I read which has
very little information on how to use the "match" parameter.  (info "(org)
Matching tags and properties") does have a lot more detail though.


On Thu, Oct 13, 2016 at 12:46 AM, Nick Dokos <ndo...@gmail.com> wrote:

> York Zhao <gtdplatf...@gmail.com> writes:
>
>
> > I wanted to know how to use the MATCH parameter in
> > `org-map-entries'. I've searched extensively, but was unable to find
> > much useful information. Can somebody please shed some lights on
> > this?
> >
>
> See
>
>(info "(org) Using the mapping API")
>
> and
>
>(info "(org) Matching tags and properties")
>
> --
> Nick
>
>
>

[O] Document of org-map-entries

[York Zhao]

Hi list,

I wanted to know how to use the MATCH parameter in `org-map-entries'. I've
searched extensively, but was unable to find much useful information. Can
somebody please shed some lights on this?

Thanks,

York

Re: [O] koma letter export receiver address

[York Zhao]

Hi Rasmus,

Oop! My apology! I've totally forgot this LCO thing. When I used koma
letter for
the first time, I think I had already figured this out, and had set to using
UScommercial9. I created my own class, and assigned my class name to
`org-koma-letter-default-class'. Unfortunately, after a long time not using
it,
when I've forgot the LCO thing, ox-koma-letter.el, at some point, had
changed to
always producing "\LoadLetterOption{NF}", which overwrites the setting in
my own
class.

Instead of setting the option in each org-mode file, I changed the value of
`org-koma-letter-class-option-file' to "UScommercial9". Thanks again for
pointing this out. Because of this issue, I've actually given up using koma
letter, and have been using the old letter class for a while.

I'm wondering why using a French style as default, while the vast majority
of
the users are from the English world, I believe! Just a suggestion.


Thanks,

York


On Sat, Apr 23, 2016 at 10:18 AM, Rasmus <ras...@gmx.us> wrote:

> York Zhao <gtdplatf...@gmail.com> writes:
>
> > Sorry Rasmus, but I don't understand what you are talking about. Have you
> > sent to a wrong subject?
>
> No.
>
> As I understand you are unhappy about the default, French, letter
> template, so I'm asking if you can use another one, like DIN.
> I’ve modified your example below.
>
> Hope it helps,
> Rasmus
>
>
> #+LCO: DIN
> * Cancel my previous written consent
>   :PROPERTIES:
>   :EXPORT_DATE: 2016-03-05
>   :EXPORT_AUTHOR: York
>   :EXPORT_CLOSING: Sincerely yours,
>   :EXPORT_OPTIONS: after-closing-order:(ps cc encl) :t backaddress:t
> title:nil
>   :END:
> ** To-address
> :to:
> Receiver's address
>
> ** From
> :from:
> My address
>
> ** Dear XXX
> Blah blah blah
>
>
>
> --
> Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio
>

Re: [O] koma letter export receiver address

[York Zhao]

Sorry Rasmus, but I don't understand what you are talking about. Have you
sent to a wrong subject?

Thanks,
York


On Sat, Apr 23, 2016 at 9:18 AM, Rasmus  wrote:

> Hi,
>
> Can you just change the template to DIN or must you use the French format?
> E.g.:
>
> #+LCO: DIN
>
> Rasmus
>
> --
> Need more coffee. . .
>

Re: [O] koma letter export receiver address

[York Zhao]

> Can you please provide a minimal example where you observe the problem
from
> Emacs -q and also provide the resulting tex file?

I've already provided a minimal example on Mar 6, sent to you and this
list. The
following is that email:

  > Hi Rasmus,
  >
  > Thanks for your help. Here's my .emacs:
  >
  > #+BEGIN_SRC emacs-lisp
> (require 'org)
> (add-to-list 'load-path
 > "~/.emacs.d/lisp/vendor/org-mode/contrib/lisp")
> (require 'ox-koma-letter)
  > #+END_SRC
  >
  > M-x org-version produces:
  >
  > Org-mode version 8.3.3 (release_8.3.3-640-g2b3c72 @
  > /usr/local/share/emacs/site-lisp/org/)
  >
  > Please find attach the file "test.org" and "test.pdf" produced by
hitting C-c
  > C-e C-s k o.

For your convenience, I've attached the two files again with this post. Hope
this helps.


Thanks,
York

On Fri, Apr 22, 2016 at 5:51 AM, Rasmus <ras...@gmx.us> wrote:

> Hi,
>
> York Zhao <gtdplatf...@gmail.com> writes:
>
> > Just wanted to follow up with this issue. I just tested it with the
> latest
> > org-mode (git commit 7e320e2), the problem was still there. Any chance
> this
> > can
> > be addressed?
>
> Can you please provide a minimal example where you observe the problem
> from Emacs -q and also provide the resulting tex file?
>
> Thanks,
> Rasmus
>
> >
> > Thanks,
> > York
> >
> >
> > On Sun, Mar 6, 2016 at 8:34 PM, York Zhao <gtdplatf...@gmail.com> wrote:
> >
> >> Hi Rasmus,
> >>
> >> Thanks for your help. Here's my .emacs:
> >>
> >> #+BEGIN_SRC emacs-lisp
> >>   (require 'org)
> >>   (add-to-list 'load-path
> >>"~/.emacs.d/lisp/vendor/org-mode/contrib/lisp")
> >>   (require 'ox-koma-letter)
> >> #+END_SRC
> >>
> >> M-x org-version produces:
> >>
> >> Org-mode version 8.3.3 (release_8.3.3-640-g2b3c72 @
> >> /usr/local/share/emacs/site-lisp/org/)
> >>
> >> Please find attach the file "test.org" and "test.pdf" produced by
> hitting
> >> C-c
> >> C-e C-s k o.
> >>
> >> Thanks,
> >> York
> >>
> >> On Sun, Mar 6, 2016 at 2:06 PM, Rasmus <ras...@gmx.us> wrote:
> >> > York Zhao <gtdplatf...@gmail.com> writes:
> >> >
> >> >> Dear org-mode koma letter developers,
> >> >>
> >> >> I just noticed that when using org koma letter export, the receiver's
> >> address
> >> >> has been moved from left side to page center. Is this the new default
> >> or an
> >> >> introduced bug? If it's the new default, how do I change it back to
> the
> >> old
> >> >> behavior?
> >> >
> >> > I guess it would depend on the style/LCO files you are using.  There
> >> > should be no such change.
> >> >
> >> > Could you share an example which produces the wrong pdf when starting
> >> > Emacs without your configuration, i.e. start Emacs as "emacs -q" and
> load
> >> > ox-koma-letter.
> >> >
> >> > Thanks,
> >> > Rasmus
> >> >
> >> > --
> >> > Dung makes an excellent fertilizer
> >> >
> >> >
> >>
>
> --
> Enough with the blah blah!
>
>
>


test.pdf
Description: Adobe PDF document


test.org
Description: Binary data

Re: [O] koma letter export receiver address

[York Zhao]

Just wanted to follow up with this issue. I just tested it with the latest
org-mode (git commit 7e320e2), the problem was still there. Any chance this
can
be addressed?

Thanks,
York


On Sun, Mar 6, 2016 at 8:34 PM, York Zhao <gtdplatf...@gmail.com> wrote:

> Hi Rasmus,
>
> Thanks for your help. Here's my .emacs:
>
> #+BEGIN_SRC emacs-lisp
>   (require 'org)
>   (add-to-list 'load-path
>"~/.emacs.d/lisp/vendor/org-mode/contrib/lisp")
>   (require 'ox-koma-letter)
> #+END_SRC
>
> M-x org-version produces:
>
> Org-mode version 8.3.3 (release_8.3.3-640-g2b3c72 @
> /usr/local/share/emacs/site-lisp/org/)
>
> Please find attach the file "test.org" and "test.pdf" produced by hitting
> C-c
> C-e C-s k o.
>
> Thanks,
> York
>
> On Sun, Mar 6, 2016 at 2:06 PM, Rasmus <ras...@gmx.us> wrote:
> > York Zhao <gtdplatf...@gmail.com> writes:
> >
> >> Dear org-mode koma letter developers,
> >>
> >> I just noticed that when using org koma letter export, the receiver's
> address
> >> has been moved from left side to page center. Is this the new default
> or an
> >> introduced bug? If it's the new default, how do I change it back to the
> old
> >> behavior?
> >
> > I guess it would depend on the style/LCO files you are using.  There
> > should be no such change.
> >
> > Could you share an example which produces the wrong pdf when starting
> > Emacs without your configuration, i.e. start Emacs as "emacs -q" and load
> > ox-koma-letter.
> >
> > Thanks,
> > Rasmus
> >
> > --
> > Dung makes an excellent fertilizer
> >
> >
>

Re: [O] koma letter export receiver address

[York Zhao]

Hi Rasmus,

Thanks for your help. Here's my .emacs:

#+BEGIN_SRC emacs-lisp
  (require 'org)
  (add-to-list 'load-path
   "~/.emacs.d/lisp/vendor/org-mode/contrib/lisp")
  (require 'ox-koma-letter)
#+END_SRC

M-x org-version produces:

Org-mode version 8.3.3 (release_8.3.3-640-g2b3c72 @
/usr/local/share/emacs/site-lisp/org/)

Please find attach the file "test.org" and "test.pdf" produced by hitting C-c
C-e C-s k o.

Thanks,
York

On Sun, Mar 6, 2016 at 2:06 PM, Rasmus <ras...@gmx.us> wrote:
> York Zhao <gtdplatf...@gmail.com> writes:
>
>> Dear org-mode koma letter developers,
>>
>> I just noticed that when using org koma letter export, the receiver's address
>> has been moved from left side to page center. Is this the new default or an
>> introduced bug? If it's the new default, how do I change it back to the old
>> behavior?
>
> I guess it would depend on the style/LCO files you are using.  There
> should be no such change.
>
> Could you share an example which produces the wrong pdf when starting
> Emacs without your configuration, i.e. start Emacs as "emacs -q" and load
> ox-koma-letter.
>
> Thanks,
> Rasmus
>
> --
> Dung makes an excellent fertilizer
>
>


test.org
Description: Binary data


test.pdf
Description: Adobe PDF document

Re: [O] How to export casual letter without from and to address?

[York Zhao]

Thank you very much Eric S Fraga, H. Dieter Wilhelm, Marcin Borkowski, Nick
Dokos and Rasmus for helping me with this! I finally took Nick Dokos's approach,
and solved the problem! Here's what I did that worked:

1. In my .emacs, I added:
#+BEGIN_SRC emacs-lisp
  (add-to-list 'org-latex-classes
   '("letter" "\\documentclass[12pt]{letter}
  \\usepackage{fullpage}
  \\usepackage{setspace}"))
#+END_SRC
2. In org-mode buffer, I had the following: \\
   * Letter to Flora on 2016-03-05
   :PROPERTIES:
   :EXPORT_LATEX_CLASS: letter
   :EXPORT_LATEX_HEADER: \signature{York}
   :EXPORT_DATE: 2016-03-05 Saturday
   :EXPORT_OPTIONS: title:nil toc:nil
   :END:
   \begin{letter}{}

   \opening{Hi Flora,\\}

 Blah blah blah!

   \closing{Regards,}

   \end{letter}
3. C-c C-e l o exporting to PDF
4. Print out the PDF file


Thanks again,\\
York

On Sun, Mar 6, 2016 at 2:04 PM, Rasmus <ras...@gmx.us> wrote:
> York Zhao <gtdplatf...@gmail.com> writes:
>
>> Hi list,
>>
>> I've been wondering for a while that when using org-mode to write letters, 
>> how
>> do you export casual a letter that doesn't have from address and to address?
>
> If you really, really want to use ox-koma-letter couldn't you just set the
> addresses to @@latex:\mbox{}@@ or something similar?
>
> I think a better solution is just to use ox-latex.
>
> Rasmus
>
> --
> Dobbelt-A
>
>

[O] koma letter export receiver address

[York Zhao]

Dear org-mode koma letter developers,

I just noticed that when using org koma letter export, the receiver's address
has been moved from left side to page center. Is this the new default or an
introduced bug? If it's the new default, how do I change it back to the old
behavior?

Thanks,

York

Re: [O] How to export casual letter without from and to address?

[York Zhao]

> Yeah, this works really convenient and near automatic, I'm also using org for
> corporate meeting minutes, reports and statistics to the tax authority
> (besides Koma letters of course ;-)

Same here, using org-mode for everything. But have you ever needed to print out
a letter without "from address" and "to address"? In my case, I just needed to
print a note, sign it, and pass it to somebody on a regular basis! It doesn't
make sense having to always print my home address and her address at the
beginning because it's just a casual note.

Thanks,

York

On Sat, Mar 5, 2016 at 6:22 AM, H. Dieter Wilhelm
<die...@duenenhof-wilhelm.de> wrote:
> Eric S Fraga <e.fr...@ucl.ac.uk> writes:
>
>> On Friday,  4 Mar 2016 at 22:36, York Zhao wrote:
>>> Please share how you write notes (casual letter without "from address" and 
>>> "to
>>> address") in Emacs org-mode, print out and give to somebody.
>>
>> If you don't have the usual elements of a letter, it is not really a
>> letter so simply write it as a normal org document and export it to pdf
>> or odt or whatever you wish to send.  org itself doesn't care!  In other
>> words, why use a letter exporter (koma?) if you don't want something
>> that looks like a letter?
>
> Yeah, this works really convenient and near automatic, I'm also using
> org for corporate meeting minutes, reports and statistics to the tax
> authority (besides Koma letters of course ;-).
>
> --
> Best wishes
> H. Dieter Wilhelm
> Kelkheim, Germany
>
>

Re: [O] How to export casual letter without from and to address?

[York Zhao]

> Why use a letter exporter (koma?) if you don't want something that looks like
> a letter?

I wanted it to be a letter in all aspects, except that it doesn't have the "from
address" and "to address" in the header. More specifically, I want my letter
looks like:

  Hi Flora,

  Blah blah blah!

  Regards,

  York

> simply write it as a normal org document and export it to pdf or odt or
> whatever you wish to send.

The problem is, it seems to me that to export to pdf, LaTeX export is the only
way to go. But then you would have to choose a document class. Obviously you
can't use "article", nor "book". So my question may probably rephrase as: which
latex document class do you use to export the letter "as is"?

Thanks,

York

On Sat, Mar 5, 2016 at 5:12 AM, Eric S Fraga <e.fr...@ucl.ac.uk> wrote:
> On Friday,  4 Mar 2016 at 22:36, York Zhao wrote:
>> Please share how you write notes (casual letter without "from address" and 
>> "to
>> address") in Emacs org-mode, print out and give to somebody.
>
> If you don't have the usual elements of a letter, it is not really a
> letter so simply write it as a normal org document and export it to pdf
> or odt or whatever you wish to send.  org itself doesn't care!  In other
> words, why use a letter exporter (koma?) if you don't want something
> that looks like a letter?
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.91.1, Org release_8.3.4-626-gb62d55

Re: [O] How to export casual letter without from and to address?

[York Zhao]

Please share how you write notes (casual letter without "from address" and "to
address") in Emacs org-mode, print out and give to somebody.

Thanks,\\
York

On Fri, Mar 4, 2016 at 12:12 AM, York Zhao <gtdplatf...@gmail.com> wrote:
> Hi list,
>
> I've been wondering for a while that when using org-mode to write letters, how
> do you export casual a letter that doesn't have from address and to address?
>
> Thanks in advance,
>
> York

[O] How to export casual letter without from and to address?

[York Zhao]

Hi list,

I've been wondering for a while that when using org-mode to write letters, how
do you export casual a letter that doesn't have from address and to address?

Thanks in advance,

York

Re: [O] Intermixed date in koma-letter export

[York Zhao]

Hi Rasmus,

> Use the :EXPORT_OPTIONS: subheading options.

Thanks a lot, this really worked. I'm wondering whether this technique can
be
generalized to using subtree property :EXPORT_OPTIONS: for any #+OPTIONS
settings? I wasn't able to find this in INFO? Has this been documented
there?

Thanks,

York

On Sat, Dec 12, 2015 at 1:13 PM, Rasmus <ras...@gmx.us> wrote:

> York Zhao <gtdplatf...@gmail.com> writes:
>
> >> #+options: title:nil
> >
> > Thanks a lot! This worked, but still problematic. If I have "#+options:
> > title:centered" for letter 1 but "#+options: title:nil" for letter 2,
> > letter 2's
> > setting will override letter 1's. I.e., letter 1 will have no title now.
>
> Use the :EXPORT_OPTIONS: subheading options.
>
> > Also, I was looking into ox-koma-letter.el trying to find some clue, but
> I
> > couldn't find where it handles the "title" option.
>
> Probably in ox.el or ox-latex.el depending on what you have got in mind.
>
> > The closest I've got was `org-koma-letter-subject-format', which can be
> > set with "#+OPTIONS subject". But it seems that the "subject" option
> > works the same as the "title" option, and has exactly the same problem.
>
> I don't understand this part.  The documentation of ox-koma-letter.el is
> at the top of the file.  There’s also a tutorial on Worg.
>
> Rasmus
>
> --
> Enough with the bla bla!
>
>
>

Re: [O] Intermixed date in koma-letter export

[York Zhao]

> Yes. See here: http://orgmode.org/org.html#Export-settings

I was actually aware of this INFO, but apparently I have ignored the
following
statement:

  > ... or for a tree by setting properties (See Properties and columns)

As well as the following:

  > When exporting only a subtree, each of the previous keywords(3) can be
  > overridden locally by special node properties. These begin with
‘EXPORT_’,
  > followed by the name of the keyword they supplant. For example, ‘DATE’
and
  > ‘OPTIONS’ keywords become, respectively, ‘EXPORT_DATE’ and
‘EXPORT_OPTIONS’
  > properties.

Have no idea why I didn't see them before. Thanks a lot!

Thanks,
York


On Sun, Dec 13, 2015 at 11:29 AM, Rasmus <ras...@gmx.us> wrote:

> Hi,
>
> York Zhao <gtdplatf...@gmail.com> writes:
>
> >> Use the :EXPORT_OPTIONS: subheading options.
> >
> > Thanks a lot, this really worked. I'm wondering whether this technique
> can
> > be
> > generalized to using subtree property :EXPORT_OPTIONS: for any #+OPTIONS
> > settings? I wasn't able to find this in INFO? Has this been documented
> > there?
>
> Yes.  See here:
>
>   http://orgmode.org/org.html#Export-settings
>
> Rasmus
>
> --
> I feel emotional landscapes they puzzle me
>

Re: [O] Intermixed date in koma-letter export

[York Zhao]

> #+options: title:nil

Thanks a lot! This worked, but still problematic. If I have "#+options:
title:centered" for letter 1 but "#+options: title:nil" for letter 2,
letter 2's
setting will override letter 1's. I.e., letter 1 will have no title now.

Also, I was looking into ox-koma-letter.el trying to find some clue, but I
couldn't find where it handles the "title" option. The closest I've got was
`org-koma-letter-subject-format', which can be set with "#+OPTIONS
subject". But
it seems that the "subject" option works the same as the "title" option,
and has
exactly the same problem.

Thanks


On Sat, Dec 12, 2015 at 5:39 AM, Rasmus <ras...@gmx.us> wrote:

> Hi,
>
> York Zhao <gtdplatf...@gmail.com> writes:
>
> >> Anyway, glad that I've got a solution!
> >
> > Unfortunately, I've just noticed that the "C-s" subtree export also
> > exported the
> > heading (the "letter1" in my example), which is definitely unacceptable
> when
> > exporting a letter.
>
> #+options: title:nil
>
> Or replace "letter 1" with the actual title or subject of the letter (see
> org-koma-letter-prefer-subject for the latter).
>
> Rasmus
>
> --
> Er du tosset for noge' lårt!
>
>
>

Re: [O] Intermixed date in koma-letter export

[York Zhao]

> Anyway, glad that I've got a solution!

Unfortunately, I've just noticed that the "C-s" subtree export also
exported the
heading (the "letter1" in my example), which is definitely unacceptable when
exporting a letter.


On Fri, Dec 11, 2015 at 9:55 PM, York Zhao <gtdplatf...@gmail.com> wrote:

> > You don't need to select a subtree. Just put point in it. However, you
> are
> > missing the "C-s" in the keybindings, so you're not doing a subtree
> export.
>
> Thanks for telling me this, I didn't know before. What's interesting is
> that it
> works for "C-s" subtree export, but not for active region subtree export.
> I'm
> not sure if we should expect this to work for active region subtree
> export, but
> here's what's written in the Info file:
>
>   > Normally the entire buffer is exported, but if there is an active
> region
>   > only that part of the buffer will be exported.
>
> Anyway, glad that I've got a solution!
>
> Thanks,\\
> York
>
>
> On Fri, Dec 11, 2015 at 6:44 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
> wrote:
>
>> Hello,
>>
>> York Zhao <gtdplatf...@gmail.com> writes:
>>
>> > I selected the "letter 1" subtree, pressed C-cekp, opened the pdf file.
>> But
>> > the
>> > date is still "Dec 12, 2015".
>>
>> You don't need to select a subtree. Just put point in it. However, you
>> are missing the "C-s" in the keybindings, so you're not doing a subtree
>> export.
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
>

Re: [O] Intermixed date in koma-letter export

[York Zhao]

> You don't need to select a subtree. Just put point in it. However, you are
> missing the "C-s" in the keybindings, so you're not doing a subtree
export.

Thanks for telling me this, I didn't know before. What's interesting is
that it
works for "C-s" subtree export, but not for active region subtree export.
I'm
not sure if we should expect this to work for active region subtree export,
but
here's what's written in the Info file:

  > Normally the entire buffer is exported, but if there is an active region
  > only that part of the buffer will be exported.

Anyway, glad that I've got a solution!

Thanks,\\
York


On Fri, Dec 11, 2015 at 6:44 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,
>
> York Zhao <gtdplatf...@gmail.com> writes:
>
> > I selected the "letter 1" subtree, pressed C-cekp, opened the pdf file.
> But
> > the
> > date is still "Dec 12, 2015".
>
> You don't need to select a subtree. Just put point in it. However, you
> are missing the "C-s" in the keybindings, so you're not doing a subtree
> export.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Intermixed date in koma-letter export

[York Zhao]

No, this still doesn't work. I just tested with my .emacs having only two
lines:

#+BEGIN_SRC emacs-lisp
  (require 'org "/usr/local/share/emacs/site-lisp/org/org")
  (require 'ox-koma-letter
   (locate-user-emacs-file
"path/to/org-mode/contrib/lisp/ox-koma-letter"))
#+END_SRC
the org-mode version is from git commit "a198d81". M-x org-version gives:

Org-mode version 8.3.2 (release_8.3.2-378-ga198d8 @
/usr/local/share/emacs/site-lisp/org/)

I then copied the text from your email exactly as:

#+BEGIN_EXAMPLE
* letter 1
:PROPERTIES:
:EXPORT_DATE: 2015-10-26 Monday
:END:
** to
:to:
The Org list
** To whom it may concern,
txt
* letter 2
:PROPERTIES:
:EXPORT_DATE: 2015-12-03 Thursday
:END:
** to
:to:
list
** To whom it may concern,
txt
#+END_EXAMPLE

I selected the "letter 1" subtree, pressed C-cekp, opened the pdf file. But
the
date is still "Dec 12, 2015".

Hope this helps,\\
York

On Thu, Dec 10, 2015 at 10:45 AM, Rasmus <ras...@gmx.us> wrote:

> Hi,
>
> York Zhao <gtdplatf...@gmail.com> writes:
>
> > Thanks for your help. However, adding the :EXPORT_DATE: property doesn't
> > work. Firstly, there's an error: "PDF file produced with errors.".
>
> You have to add an address, e.g.
>
> * letter 1
> :PROPERTIES:
> :EXPORT_DATE: 2015-10-26 Monday
> :END:
> ** to
> :to:
> The Org list
> ** To whom it may concern,
> txt
> * letter 2
> :PROPERTIES:
> :EXPORT_DATE: 2015-12-03 Thursday
> :END:
> ** to
> :to:
> list
> ** To whom it may concern,
> txt
>
> > Secondly, even though it still produced a PDF output, the date is always
> > today's date which is wrong.
>
> I cannot reproduce.  I get this as part of exporting the first subtree
> (I click: C-c C-e C-s k L)
>
>  \date{2015-10-26 Monday}
>
> Hope it helps,
> Rasmus
>
> --
> Enough with the bla bla!
>
>
>

Re: [O] Intermixed date in koma-letter export

[York Zhao]

Hi Rasmus,

Thanks for your help. However, adding the :EXPORT_DATE: property doesn't
work. Firstly, there's an error: "PDF file produced with errors.".
Secondly, even though it still produced a PDF output, the date is always
today's date which is wrong.

Thanks.

On Mon, Dec 7, 2015 at 4:21 AM, Rasmus <ras...@gmx.us> wrote:

> York Zhao <gtdplatf...@gmail.com> writes:
>
> > Let's say I have two letters:
> >
> >   * Letter1
> >   ** Preamble :noexport:
> >
> >   #+DATE: 2015-10-26 Monday
> >   ** To whom it may concern,
> >
> >
> >   * Letter2
> >   ** Preamble :noexport:
> >
> >   #+DATE: 2015-12-03 Thursday
> >   ** Hi,
>
> This should work:
>
> * letter 1
> :PROPERTIES:
> :EXPORT_DATE: 2015-10-26 Monday
> :END:
> ** To whom it may concern,
>
> * letter 2
> :PROPERTIES:
> :EXPORT_DATE: 2015-12-03 Thursday
> :END:
> ** hi,
>
>
> --
> Dobbelt-A
>
>
>

[O] Intermixed date in koma-letter export

[York Zhao]

Let's say I have two letters:

  * Letter1
  ** Preamble :noexport:
  #+DATE: 2015-10-26 Monday
  ** To whom it may concern,

  * Letter2
  ** Preamble :noexport:
  #+DATE: 2015-12-03 Thursday
  ** Hi,

No matter whether I select letter1, or letter2, run `org-export-dispatch'
and choose to export koma-letter, I always get the date intermixed in the
export, i.e., "2015-10-26 Monday 2015-12-03 Thursday", instead of being
"2015-10-26 Monday" when exporting letter1, and "2015-12-03 Thursday" when
exporting letter2.

Please let me know if more information is needed.


Thanks,

Re: [O] Extremely slow org-table operations

[York Zhao]

  I learned that the hard way when I had one table - four columns, three
  simple
  addition formulas with about 1,000 entries. It seemed an eternity before
  the
  addition was completed.

 I guess the entries here mean the table rows right? Please confirm.

 You are correct; I should have said rows. In my file there were 1000 (+/-)
 rows and each row had up to three entries, not including the description
 in the first row.
 For instance (without any formulas) in the following row I entered each
 amount in columns 2,3  4.

 | this was a transaction | 100.00 | 200.00 | 300.00|

 So I considered this three entries. So actually there were 3,000 (+/-)
 entries.

OK, now I see. Charlie's problem is actually completed different from this
problem. So what Carsten Dominik mentioned doesn't apply. This is because in
Charlie's case there are 1000 rows in a table, whereas mine has only two rows.
Since my formula only calculates two rows, and calculating the table doesn't
involve data input from anywhere else, it really doesn't make sens that it has
to be slow.

Needlessly to say that `org-mode' is fantastic, but with this issue, I have to
say that `org-mode' is unhealthy. Therefore, I really hope this issue gets
addressed. Please let me know what I can do to help.


Thanks in advance,

York


On Fri, Oct 31, 2014 at 3:12 PM, Charles Millar mill...@verizon.net wrote:
 Hi York,

 York Zhao wrote:

 @Charlie Millar:

  IIRC Carsten Dominik made the following observation: org tables are
  extremely
  slow if they are used as workbooks/spreadsheets and there are many
  entries
  (many is undefined).

 Thanks for the information, could you please clarify what entry means?
 Does it
 mean org headline, or a row in an org-table?

  I learned that the hard way when I had one table - four columns, three
  simple
  addition formulas with about 1,000 entries. It seemed an eternity before
  the
  addition was completed.

 I guess the entries here mean the table rows right? Please confirm.

 You are correct; I should have said rows. In my file there were 1000 (+/-)
 rows and each row had up to three entries, not including the description
 in the first row.
 For instance (without any formulas) in the following row I entered each
 amount in columns 2,3  4.

 | this was a transaction | 100.00 | 200.00 | 300.00|

 So I considered this three entries. So actually there were 3,000 (+/-)
 entries.

 Charlie

Re: [O] Extremely slow org-table operations

[York Zhao]

@Charlie Millar:

 IIRC Carsten Dominik made the following observation: org tables are
extremely
 slow if they are used as workbooks/spreadsheets and there are many entries
 (many is undefined).

Thanks for the information, could you please clarify what entry means?
Does it
mean org headline, or a row in an org-table?

 I learned that the hard way when I had one table - four columns, three
simple
 addition formulas with about 1,000 entries. It seemed an eternity before
the
 addition was completed.

I guess the entries here mean the table rows right? Please confirm.


York


On Wed, Oct 29, 2014 at 7:40 PM, Charles Millar mill...@verizon.net wrote:

 Hi,


 York Zhao wrote:

 I think Org 8.3 should improve the situation. Please test it if you can.

 I was aware that my emacs -Q test was done against org-mode version
 8.2.x.
 However, I use the latest org-mode from Git everyday. For example, the
 version
 I'm currently using is (from M-x org-version): Org-mode version 8.3beta
 (release_8.3beta-509-g86ec0a.dirty @ /usr/local/share/emacs/site-lisp/org/).
 So
 apparently the problem had never been addressed.

  Meanwhile, I suggest to insert some subsections in your file.

 What do you mean by insert some subsections?


 Thanks


 On Wed, Oct 29, 2014 at 5:43 AM, Nicolas Goaziou m...@nicolasgoaziou.fr
 wrote:

 Hello,

 York Zhao gtdplatf...@gmail.com writes:

  A few months ago I tried Emacs 24.4 and was disappointed because almost
 all of
 the org-table operations became AT LEAST ten times slower. Because
 recently
 Emacs 24.4 gets officially released, I finally switched over. However,
 the
 problems I had several months ago were still there, i.e., in a big file,
 org-table operations are at least ten times slower. I tried profiling
 it but
 didn't help much. So I decided to report the issue here.

 [...]

  In summery, the file test.org has more than 5000 org-table tables,
 each table
 has a formula. If you move the point to the tables not too far away
 from the
 beginning of the buffer and press C-c C-c on the formula line, you
 will notice
 that the speed is very fast which is great. However, if you move the
 point far
 away enough from the beginning of the buffer (move to the end for
 example), you
 will find that C-c C-c on the formula line becomes much slower.

 Many other operations are also very slow. However, because I haven't
 been able
 to create the ECMs for those operations yet, lets focus on this one
 first.

 I think Org 8.3 should improve the situation. Please test it if you can.
 Meanwhile, I suggest to insert some subsections in your file.


 Regards,

 --
 Nicolas Goaziou


  IIRC Carsten Dominik made the following observation: org tables are
 extremely slow if they are used as workbooks/spreadsheets and there are
 many entries (many is undefined). He recommended that a spreadsheet program
 in such situations.

 I learned that the hard way when I had one table - four columns, three
 simple addition formulas with about 1,000 entries. It seemed an eternity
 before the addition was completed.

 Charlie Millar

Re: [O] Extremely slow org-table operations

[York Zhao]

 I think Org 8.3 should improve the situation. Please test it if you can.

I was aware that my emacs -Q test was done against org-mode version 8.2.x.
However, I use the latest org-mode from Git everyday. For example, the version
I'm currently using is (from M-x org-version): Org-mode version 8.3beta
(release_8.3beta-509-g86ec0a.dirty @ /usr/local/share/emacs/site-lisp/org/). So
apparently the problem had never been addressed.

 Meanwhile, I suggest to insert some subsections in your file.

What do you mean by insert some subsections?


Thanks


On Wed, Oct 29, 2014 at 5:43 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
 Hello,

 York Zhao gtdplatf...@gmail.com writes:

 A few months ago I tried Emacs 24.4 and was disappointed because almost all 
 of
 the org-table operations became AT LEAST ten times slower. Because recently
 Emacs 24.4 gets officially released, I finally switched over. However, the
 problems I had several months ago were still there, i.e., in a big file,
 org-table operations are at least ten times slower. I tried profiling it but
 didn't help much. So I decided to report the issue here.

 [...]

 In summery, the file test.org has more than 5000 org-table tables, each 
 table
 has a formula. If you move the point to the tables not too far away from the
 beginning of the buffer and press C-c C-c on the formula line, you will 
 notice
 that the speed is very fast which is great. However, if you move the point 
 far
 away enough from the beginning of the buffer (move to the end for example), 
 you
 will find that C-c C-c on the formula line becomes much slower.

 Many other operations are also very slow. However, because I haven't been 
 able
 to create the ECMs for those operations yet, lets focus on this one
 first.

 I think Org 8.3 should improve the situation. Please test it if you can.
 Meanwhile, I suggest to insert some subsections in your file.


 Regards,

 --
 Nicolas Goaziou

Re: [O] still seeing semi-regular lockups

[York Zhao]

 FWIW, I'm still getting regular lockups with the cache. I'll dig into it
 further when I have time.

I'm still being locked up from time to time, maybe less than before I guess.
What I said was that I never got the deadly problem of Lisp nesting exceeds
`max-lisp-eval-depth, and the fix had been a life saver for me.

Re: [O] still seeing semi-regular lockups

[York Zhao]

 On Mon, Jun 30, 2014 at 8:43 PM, York Zhao gtdplatf...@gmail.com wrote:

 I got the problem today, with org-mode version 815c218 in Emacs 24.3.1.
The
 error message is: if: Lisp nesting exceeds `max-lisp-eval-depth'.
Attached is
 the backtrace saved in a file. Hope this will help.

Just an update. I haven't been bitten by this deadly problem for awhile,
highly
likely that it had been fixed. Thanks a lot.

York

Re: [O] Issue with multiple references to the same footnote in LaTeX export

[York Zhao]

Hi list,

I'm re-posting this again because I just noticed that I shouldn't have
copied
the Local Variables. Now it is a smaller ECM.

If I have multiple references to the same footnote, in LaTeX export only the
first reference is a clickable link, the rest are exported as dead number
referring to the footnote definition, but not clickable links. I have
`org-footnote-section' set to `nil' by the way.

Here's ECM:

--8---cut here---start-8---
#+LaTeX_CLASS: article

* Multiple reference to the same footnote 1
This is footnote reference [fn:1]. This is another reference to the same
footnote [fn:1]

[fn:1] Footnote definition.

* Multiple reference to the same footnote 2
This is footnote reference [fn:myfootnote]. This is another reference to the
same footnote [fn:myfootnote]

[fn:myfootnote] Footnote definition.

* Multiple reference to the same footnote 3
This is footnote reference [fn:myfootnote3: Footnote definition.]. This is
another reference to the same footnote [fn:myfootnote3]

--8---cut here---end---8---

Regards,

York

Re: [O] Issue with multiple references to the same footnote in LaTeX export

[York Zhao]

Any one?


On Wed, Jul 9, 2014 at 2:07 PM, York Zhao gtdplatf...@gmail.com wrote:

 If I have multiple references to the same footnote, in LaTeX export only
 the
 first reference is a clickable link, the rest are exported as dead number
 referring to the footnote definition, but not clickable links. I have
 `org-footnote-section' set to `nil' by the way.

 Here's ECM:

 --8---cut here---start-8---
 #+LaTeX_CLASS: article

 * Multiple reference to the same footnote 1
 This is footnote reference [fn:1]. This is another reference to the same
 footnote [fn:1]

 [fn:1] Footnote definition.

 * Multiple reference to the same footnote 2
 This is footnote reference [fn:myfootnote]. This is another reference to
 the
 same footnote [fn:myfootnote]

 [fn:myfootnote] Footnote definition.

 * Multiple reference to the same footnote 3
 This is footnote reference [fn:myfootnote3: Footnote definition.]. This is
 another reference to the same footnote [fn:myfootnote3]

 * Local Variables
 # Local Variables:
 # eval: (add-to-list (make-local-variable
 'org-latex-default-packages-alist) '( setspace nil))
 # End:
 --8---cut here---end---8---

 Regards,

 York

[O] Issue with multiple references to the same footnote in LaTeX export

[York Zhao]

If I have multiple references to the same footnote, in LaTeX export only the
first reference is a clickable link, the rest are exported as dead number
referring to the footnote definition, but not clickable links. I have
`org-footnote-section' set to `nil' by the way.

Here's ECM:

--8---cut here---start-8---
#+LaTeX_CLASS: article

* Multiple reference to the same footnote 1
This is footnote reference [fn:1]. This is another reference to the same
footnote [fn:1]

[fn:1] Footnote definition.

* Multiple reference to the same footnote 2
This is footnote reference [fn:myfootnote]. This is another reference to the
same footnote [fn:myfootnote]

[fn:myfootnote] Footnote definition.

* Multiple reference to the same footnote 3
This is footnote reference [fn:myfootnote3: Footnote definition.]. This is
another reference to the same footnote [fn:myfootnote3]

* Local Variables
# Local Variables:
# eval: (add-to-list (make-local-variable
'org-latex-default-packages-alist) '( setspace nil))
# End:
--8---cut here---end---8---

Regards,

York

Re: [O] still seeing semi-regular lockups

[York Zhao]

 + zfill-org-paragraph-boundary  7,240
0%
 What is that, if I may ask?

That's in my `zfill-mode' based on `refill-mode', and the function is part
of
the machinery to handle the automatic refilling of org paragraph.

 + ac-handle-post-command 2985  56%
 + timer-event-handler1786  33%
 + redisplay_internal (C function) 131   2%
[...]

 So I suspected the `auto-complete'. I tried M-x auto-complete to turn it
off
 which worked, the typing was fast again. M-x auto-complete to turn it
back on
 and typing became extremely slow again.

 Indeed. auto-complete developers may be interested in your report. This
is not
 an Org bug, though.

Yes, it is highly possible to be a bug in `auto-complete' and I will report
it
to the `auto-complete' developers as soon as I get a bit more time. And I
totally understand if you decide not to spend time on this until I can
further
prove that this is still an org-mode problem. However, I think it might be
too
early to draw the conclusion at this point that this has nothing to do with
org-mode. This is because `auto-complete' started to manifest the problem
after
doing a bunch of org-mode specific operations, more specifically, after
running
`org-drlll' on 8 `org-mode' buffers, which suggested the possibility of the
leftover side effect introduced by org-mode operations. And the problem
could be
in `org-drlll', but also very possibly be in org-mode core because
`org-drlll'
uses the APIs provided by `org-mode' core.

Anyways, the other one I reported yesterday seemed to be related to
org-element
cache stuff and I will follow your suggestion to try to reproduce it. But I
may
not have much time this week anymore. Will definitely try it this weekend
for
sure.

Regards,

York

Re: [O] Indentation messed up after example block

[York Zhao]

 Hi list,

 I just noticed a problem that org-mode indentation gets messed up after
 example block. Here is ECM:

 #+STARTUP: indent

 * Level one
 ** Level two
 Indentation is right.

 #+BEGIN_EXAMPLE
 * Example at level one
 #+END_EXAMPLE

 Indentation is wrong.

 The asterisk followed by a space followed by text in your example block
 is recognized by org as a headline. So org thinks everything under that
 headline is the body of the headline.

I knew this is exactly the reason. But the question is shouldn't `org-mode'
ignore headlines in example block. I'm not sure whether this is easy or not
though.

 You can fix this by not letting * Example at level one start at the
 beginning of the line, but instead indent it by one or more spaces or
prefix
 it with some other character(s).

Smart workaround. Thanks.

Re: [O] still seeing semi-regular lockups

[York Zhao]

 Thank you for the report. I wasn't able to reproduce it with latest commit
 (df9ccbd). Could you try again and see if it fixes your problem?

I haven't experienced this problem since July 3, hopefully it has been
fixed.
Thank you very much for your work.

York

Re: [O] still seeing semi-regular lockups

[York Zhao]

  The exact same slowness problem happened just now. M-x
org-element-cache-reset
  didn't have any effect. Nor did setting `org-element-use-cache' to nil.
Again,
  killed the buffer and reopened didn't help.
 It looks like the problem isn't related to the cache then. Anyway, you
 could try to do some profiling (see `profiler-start').

  One thing I didn't do, unfortunately, was that I reset cache only for
the buffer
  where the slowness manifested. I think I should try reseting cache for
all the 8
  buffers too right?
 Cache is buffer dependent, so you don't need to reset cache for all of
 them (though it's simply C-u M-x org-element-cache-reset).

I haven't experienced this problem (I'm now using df9ccbd) since last
time I
reported (July 2 I guess), really hope that this problem has been fixed.
Thank
you very much for all the hard work you have done on this issue.

York

[O] Indentation messed up after example block

[York Zhao]

Hi list,

I just noticed a problem that org-mode indentation gets messed up after
example block. Here is ECM:

#+STARTUP: indent

* Level one
** Level two
Indentation is right.

#+BEGIN_EXAMPLE
* Example at level one
#+END_EXAMPLE

Indentation is wrong.

Re: [O] still seeing semi-regular lockups

[York Zhao]

The extreme slowness happened again just know. When this happened,
`org-end-of-line' command took forever until C-g. M-x
org-element-cache-reset
worked this time, i.e., after running `org-element-cache-reset' command
`org-end-of-line' became fast again.

I was using commit ca6ecf9, and the buffer was 38xx lines 168K in size.

Re: [O] still seeing semi-regular lockups

[York Zhao]

 Could you send me the document you were working on, in private, and
describe
 what you were doing before it froze?

I'm sorry but I really shouldn't send this document to anyone other than a
lawyer :-)

 or at least an equivalent file structure wise, calling the following
function
 in that document ... If you can reproduce the problem in this new buffer,
 that's fine too.

Just want to confirm that you want me to run this command in that buffer
and see
if the problem can be reproduced?

Re: [O] still seeing semi-regular lockups

[York Zhao]

  The exact same slowness problem happened just now. M-x
org-element-cache-reset
  didn't have any effect. Nor did setting `org-element-use-cache' to nil.
Again,
  killed the buffer and reopened didn't help.
 It looks like the problem isn't related to the cache then. Anyway, you
 could try to do some profiling (see `profiler-start').

  One thing I didn't do, unfortunately, was that I reset cache only for
the buffer
  where the slowness manifested. I think I should try reseting cache for
all the 8
  buffers too right?
 Cache is buffer dependent, so you don't need to reset cache for all of
 them (though it's simply C-u M-x org-element-cache-reset).

This problem happened again just now. Again, M-x org-element-cache-reset
didn't
help, nor did C-u M-x org-element-cache-reset. And it seemed that only
typing
characters were slow, took 1 or 2 seconds for a typed character to appear
on the
screen.

Again, this happened in the big buffer that has 77,xxx lines, freshly
opened. I
restarted Emacs and finished `org-drill' session on 8 files before opening
this
big file.

I then `M-x profile-start', typed a few letters and `M-x profile-report',
here's
the memory report:

+ #compiled 0x138b23111,320,032  43%
+ call-interactively4,857,849  18%
+ #compiled 0x1444275 2,170,499   8%
+ timer-event-handler   1,428,527   5%
+ #compiled 0xa6e561  1,299,957   5%
+ helm  1,058,503   4%
+ redisplay_internal (C function) 869,652   3%
+ ac-handle-post-command  695,448   2%
+ helm-M-x517,012   2%
+ helm-check-new-input215,112   0%
+ #compiled 0x1391c7d   211,328   0%
+ helm-let-internal   182,580   0%
+ helm-read-pattern-maybe 109,907   0%
+ helm-process-filtered-candidate-transformer  97,992   0%
+ helm-get-cached-candidates   87,872   0%
+ cl-mapcar82,880   0%
+ helm-update  81,536   0%
+ helm-funcall-with-source 72,380   0%
+ read-from-minibuffer 70,224   0%
+ funcall  69,721   0%
+ apply34,618   0%
+ #compiled 0xfe8ee9 33,140   0%
+ helm--compute-sources31,988   0%
+ yas--post-command-handler29,288   0%
+ org-element--parse-to29,184   0%
+ #compiled 0xfe83ad 12,520   0%
+ helm-compute-matches 12,400   0%
+ let  12,288   0%
+ byte-code 9,320   0%
+ ac-handle-pre-command 9,298   0%
+ profiler-report-rerender-calltree 8,188   0%
+ command-execute   8,188   0%
+ helm-check-minibuffer-input   8,152   0%
+ zfill-org-paragraph-boundary  7,240   0%
+ helm-internal 7,000   0%
+ sp--self-insert-command   6,060   0%
+ helm-comp-read5,200   0%
+ let*  5,028   0%
+ catch 4,204   0%
+ hl-paren-highlight4,144   0%
+ zfill-pre-command-function4,096   0%
+ save-restriction  4,096   0%
+ while 4,096   0%
+ save-excursion4,096   0%
+ helm-M-x-current-mode-map-alist   3,144   0%
+ helm-display-buffer   2,080   0%
+ profiler-report-setup-buffer  1,066   0%
+ profiler-report   1,054   0%
+ org-element--cache-before-change  1,024   0%

And CPU report:

+ ac-handle-post-command 2985  56%
+ timer-event-handler

Re: [O] still seeing semi-regular lockups

[York Zhao]

 I'm now using commit 126e2bc, this morning I did experience some funny
 things which I had never experienced before. Unfortunately I let them go. I
 will keep an eye on the new problems.

I'm now using commit fdc673d. The problem I experienced 2 days ago happened
again. The direct operations I did was that I programmatically deleted a few
table line in one table and inserted them in another table which is in the
subtree immediately following the current table. But I ended up having more
lines in the new table, most of them were duplicated. Here is roughly the
snippet of the command I used:

(defun yhj-drop-something ()
  (interactive)
  (save-excursion
(let* ((beg (line-beginning-position))
   (end (1+ (line-end-position)))
   (line (buffer-substring beg end)))
  (kill-region beg end)
  (unless (re-search-forward ^\\*+[ \t]+Newtable[ \t]*$
 (save-excursion
   (org-end-of-subtree t)) t)
(error Incompatible contents format))
  (forward-line 4)
  (unless (org-at-table-p 'any)
(error Incompatible contents format))
  (beginning-of-line)
  (insert line)
  (org-table-align)
  (org-table-sort-lines nil ?a

I can't post everything here because the command operates on my personal
contents. I have been using this snippet for years without problem. I executed
this command several times with point moved to different lines in the first
table. Each time this command is executed it is supposed to move one table
line to another table.

Hope this will help a bit and I will pay close attention next time to give more
details.

Re: [O] still seeing semi-regular lockups

[York Zhao]

 I'm now using commit fdc673d. The problem I experienced 2 days ago happened
 again. The direct operations I did was that I programmatically deleted a few
 table line in one table and inserted them in another table which is in the
 subtree immediately following the current table. But I ended up having more
 lines in the new table, most of them were duplicated. Here is roughly the
 snippet of the command I used:

 (defun yhj-drop-something ()
   (interactive)
   (save-excursion
 (let* ((beg (line-beginning-position))
(end (1+ (line-end-position)))
(line (buffer-substring beg end)))
   (kill-region beg end)
   (unless (re-search-forward ^\\*+[ \t]+Newtable[ \t]*$
  (save-excursion
(org-end-of-subtree t)) t)
 (error Incompatible contents format))
   (forward-line 4)
   (unless (org-at-table-p 'any)
 (error Incompatible contents format))
   (beginning-of-line)
   (insert line)
   (org-table-align)
   (org-table-sort-lines nil ?a

I just noticed these errors in my *messages* buffer:

user-error: Not in table data field
2 lines sorted, based on column 1
Starting egrep process...
3 lines sorted, based on column 1
4 lines sorted, based on column 1
After 0 kbd macro iterations: let: Wrong type argument: number-or-marker-p, nil
Error in post-command-hook (zfill-post-command-function): (user-error
An element cannot be parsed line 76823)
Error in pre-command-hook (zfill-pre-command-function): (user-error
An element cannot be parsed line 76823)
6 lines sorted, based on column 1

I'm not sure if the `(user-error An element cannot be parsed line 76823)' can
be of any help. Line 76823 was the last line in the table where the table lines
were being moved to (the Destination Table). This table looks like thin:

*** Source Table
|-+-+-+-+---|
| COL1| COL2| COL3| COL4|   |
|-+-+-+-+---|
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
|-+-+-+-+---|

 Destination Table
|-+-+-+-+---|
| COL1| COL2| COL3| COL4|   |
|-+-+-+-+---|
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
| Content | Content | Content | Content | A |
|-+-+-+-+---|

Re: [O] Force new page on exporting

[York Zhao]

Thought I should post an update to fix a regexp problem, hopfully somebody
else
will find it useful.

(defun yz/org-export-headline-on-new-page (contents backend info)
  Export headlines with tag `newpage' on new pages.
  (when (org-export-derived-backend-p backend 'latex)
(with-temp-buffer
  (insert contents)
  (goto-char (point-min))
  (let ((case-fold-search t))
(when (re-search-forward
   ^\\(?:sub\\)?section{.*\\(.*{newpage}\\).*$
   nil 'noerror)
  (replace-match  nil nil nil 1) ; Delete the newpage tag
  (forward-line -1)
  (insert \\newpage\n)
  (setq contents (buffer-substring (point-min) (point-max

York

Re: [O] still seeing semi-regular lockups

[York Zhao]

 OK. If you experience it again, please do

   M-x org-element-cache-reset

 in the slow buffer and see if it is responsive again.

 Another interesting test would be to try reproducing the problem with
 `org-element-use-cache' set to nil.

The exact same slowness problem happened just now. M-x org-element-cache-reset
didn't have any effect. Nor did setting `org-element-use-cache' to nil. Again,
killed the buffer and reopened didn't help.

I couldn't remember whether the big file was already opened, but I think it was
not opened yet, i.e., when the problem occurred, the file might just be opened.
What I did was that I started Emacs, run `org-drill' across 8 files (in one
session). Total size of these files was 730 KB bytes. The good thing was that
the session was finished successfully, no max-lisp-eval-depth error, and I
really hope this deadly error will never happen.

One thing I didn't do, unfortunately, was that I reset cache only for the buffer
where the slowness manifested. I think I should try reseting cache for all the 8
buffers too right?

York

Re: [O] Force new page on exporting

[York Zhao]

 My understanding is that you need extra machinery to implement ignoreheading

I had implemented machinery the ignoreheading and posted the code in the post
Wrong numbering after removal of headline. But anyways here's my code:

(defun yz/org-export-process-heading-removal (backend)
  Ignore headlines with tag `ignoreheading'.
  (save-excursion
(let ((org-allow-promoting-top-level-subtree t))
  (org-map-entries
   (lambda ()
 (when (member removeheading (org-get-local-tags))
   (org-promote-subtree)
   (delete-region (line-beginning-position)
  (progn (forward-line) (point)

(add-hook 'org-export-before-parsing-hook
  #'yz/org-export-process-heading-removal)

This code worked for ignoring the headline with tag removeheading, and did
re-numbering all the headlines properly. But:

* Latex New Page :ignoreheading:
#+latex: \newpage

 Still didn't work which I have no idea at this moment yet. Any idea?

Re: [O] Force new page on exporting

[York Zhao]

 So before parsing, you are getting rid of the ignoreheading headline (first,
 promoting it to a comment and then deleting the region), so the #+latex:
 \newpage line now belongs to headline 2 which is then parsed and discarded.

Really great catch Nick, exactly as what you pointed out. Saved me some time on
investigating, thanks.

 I think you need a filter after parsing (which of course conflicts with
 your need in the Wrong numbering... thread).

Yes, like you said before, using filter is too late because the contents is
already LaTeX content and it's impossible to prompt the tree any more.

 [fn:1] there is a removeheading vs ignoreheading inconsistency, btw.

I'm sorry for the confusion. I changed the tag name from ignoreheadline to
remomeheading in my implementation.

@Thomas,

I was using `org-export-filter-headline-functions' before but like Nick and I
said, it was not capable of promoting the subtree after removing the headline,
which is why I discarded it and used my implementation.

Maybe I will implement some addition machinery in the
org-export-before-parsing-hook when I get some time to handle this new page
thing. I will update here once that gets done.

Re: [O] still seeing semi-regular lockups

[York Zhao]

 Please update, if you can. I pushed a couple of fixes a few hours ago. It may
 solve the problem.

I noticed the new commits after my previous report. I'm now using commit
126e2bc, this morning I did experience some funny things which I had never
experienced before. Unfortunately I let them go. I will keep an eye on the new
problems.

Re: [O] Force new page on exporting

[York Zhao]

OK, hacked `org-export-filter-headline-functions' and added the facility to
force exporting a headline on new page by adding a new tag newpage to the
headline. Here is the code:

(defun yz/org-export-headline-on-new-page (contents backend info)
  Export headlines with tag `newpage' on new pages.
  (when (org-export-derived-backend-p backend 'latex)
(with-temp-buffer
  (insert contents)
  (goto-char (point-min))
  (let ((case-fold-search t))
(when (re-search-forward ^section{.*\\(.*{newpage}\\).*\n
 nil 'noerror)
  (replace-match  nil nil nil 1) ; Delete the newpage tag
  (forward-line -1)
  (insert \\newpage\n)
  (setq contents (buffer-substring (point-min) (point-max

(add-to-list 'org-export-filter-headline-functions
 #'yz/org-export-headline-on-new-page)

Re: [O] still seeing semi-regular lockups

[York Zhao]

Just suffered from extreme slowness. My Emacs had been running for about 1 hour
and I was having two org-mode buffers, one file has 3800 lines, 168 KB bytes.
And the other has 76,600 lines, 4,267,327 KB bytes. Both files had been opened
for awhile. Didn't have problem in the beginning, but then typing in the bigger
buffer became extremely slow, took at least one to two seconds for a typed
character to be displayed on the screen. Killed the buffer and then reopen it
didn't help at all. At the same time typing in the other smaller buffer didn't
have the same slowness issue. Restarted Emacs and the issue disappeared.

One of the problem I have noticed for a long time is that org-mode could become
slower and slower with use, which was exactly what I had been experiencing just
now.

[O] Wrong numbering after removal of headline

[York Zhao]

Hi list,

As an example, I have the follow org-mode buffer:

* Level1
** Level2
*** Level3

If I export this to LaTeX (C-x C-e l p), it produces the following:

--8---cut here---start-8---

Contents

1 Level1
1.1 Level2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Level3 . . . . . . . . . . . . . . . . . . . . . . . . . . .

--8---cut here---end---8---

Which is good. However, since what I need is that I don't want to produce the
level1 heading, so I added the following code:

(defun yz/org-export-ignore-headline (contents backend info)
  Ignore headlines with tag `ignoreheading'.
  (when (and (org-export-derived-backend-p backend 'latex 'html 'ascii)
 (string-match \\`.*ignoreheading.*\n (downcase contents)))
(replace-match  nil nil contents)))

(add-to-list 'org-export-filter-headline-functions
 'yz/org-export-ignore-headline)

And I added tag ignorheading to the Level1 heading. It works and produced:

--8---cut here---start-8---

0.1 Level2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0.1.1 Level3 . . . . . . . . . . . . . . . . . . . . . . . . . . .

--8---cut here---end---8---

However, the headline numbering now starts from 0 which is wrong , what I want
is:

1 Level2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Level3 . . . . . . . . . . . . . . . . . . . . . . . . . . .

Can anyone please tell me how I could achieve this?

Thanks in advance

York

Re: [O] Wrong numbering after removal of headline

[York Zhao]

 You could promote the Level2 subtree.

I had thought about this, but I don't think this will be trivial.

On Mon, Jun 30, 2014 at 3:37 PM, Thomas S. Dye t...@tsdye.com wrote:
 Aloha York,

 York Zhao gtdplatf...@gmail.com writes:

 Hi list,

 As an example, I have the follow org-mode buffer:

 * Level1
 ** Level2
 *** Level3

 If I export this to LaTeX (C-x C-e l p), it produces the following:


 Contents

 1 Level1
 1.1 Level2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 1.1.1 Level3 . . . . . . . . . . . . . . . . . . . . . . . . . . .


 Which is good. However, since what I need is that I don't want to produce the
 level1 heading, so I added the following code:

 (defun yz/org-export-ignore-headline (contents backend info)
   Ignore headlines with tag `ignoreheading'.
   (when (and (org-export-derived-backend-p backend 'latex 'html 'ascii)
  (string-match \\`.*ignoreheading.*\n (downcase contents)))
 (replace-match  nil nil contents)))

 (add-to-list 'org-export-filter-headline-functions
  'yz/org-export-ignore-headline)

 And I added tag ignorheading to the Level1 heading. It works and 
 produced:


 0.1 Level2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 0.1.1 Level3 . . . . . . . . . . . . . . . . . . . . . . . . . . .


 However, the headline numbering now starts from 0 which is wrong , what I 
 want
 is:

 1 Level2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 1.1 Level3 . . . . . . . . . . . . . . . . . . . . . . . . . . .

 Can anyone please tell me how I could achieve this?

 You could promote the Level2 subtree.

 hth,
 Tom

 --
 Thomas S. Dye
 http://www.tsdye.com

Re: [O] Wrong numbering after removal of headline

[York Zhao]

Hi Nicolas,

 Don't do that at the filter level, which is too late for heavy structure
 editing. Use `org-export-before-parsing-hook' instead.

I realized this, and had changed to use `org-export-before-parsing-hook', here
is my code:

(defun my-headline-removal (backend)
  Ignore headlines with tag `ignoreheading'.
  (save-excursion
(when (eq org-export-current-backend 'latex)
  (org-map-entries (lambda ()
 (when (member ignoreheading
(org-get-tags-at nil 'local))
   (save-excursion
 (org-map-tree 'org-promote))
   (delete-region (line-beginning-position)
  (line-end-position

(add-hook 'org-export-before-parsing-hook 'my-headline-removal)

But I'm getting the error: org-map-tree: Symbol's value as variable is void:
org-called-with-limited-levels. Any idea?

Thanks


On Mon, Jun 30, 2014 at 5:38 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
 Hello,

 York Zhao gtdplatf...@gmail.com writes:

 As an example, I have the follow org-mode buffer:

 * Level1
 ** Level2
 *** Level3

 If I export this to LaTeX (C-x C-e l p), it produces the following:


 Contents

 1 Level1
 1.1 Level2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 1.1.1 Level3 . . . . . . . . . . . . . . . . . . . . . . . . . . .


 Which is good. However, since what I need is that I don't want to produce the
 level1 heading, so I added the following code:

 (defun yz/org-export-ignore-headline (contents backend info)
   Ignore headlines with tag `ignoreheading'.
   (when (and (org-export-derived-backend-p backend 'latex 'html 'ascii)
  (string-match \\`.*ignoreheading.*\n (downcase contents)))
 (replace-match  nil nil contents)))

 (add-to-list 'org-export-filter-headline-functions
  'yz/org-export-ignore-headline)

 Don't do that at the filter level, which is too late for heavy structure
 editing.  Use `org-export-before-parsing-hook' instead.  See section
 12.14 in manual for an example.


 Regards,

 --
 Nicolas Goaziou

Re: [O] Wrong numbering after removal of headline

[York Zhao]

Finally, I got it all work and am happy with the result, here is the code:

(defun yz/org-export-ignore-headline (backend)
  Ignore headlines with tag `ignoreheading'.
  (save-excursion
(let ((org-allow-promoting-top-level-subtree t))
  (org-map-entries
   (lambda ()
 (when (member ignoreheading (org-get-tags-at nil 'local))
   (org-promote-subtree)
   (delete-region (line-beginning-position) (line-end-position

(add-hook 'org-export-before-parsing-hook 'yz/org-export-ignore-headline)

[O] Force new page on exporting

[York Zhao]

I'm selectively exporting some subtree of an org-mode buffer, like this:

* Headline1  :export:
* Headline2
* Headline3  :export:

Question is: how do I force Headline3 to be on a new page while exporting to
LaTeX?

Thanks in advance

Re: [O] Force new page on exporting

[York Zhao]

Thanks Thomas. This works but is not an ideal approach because in a complex file
it may not be so easy to find out the location to insert the \newpage
instruction. Plus, each time when inserting new exported tree between
Headline1 and Headline2 you would have to remember to move the \newpage to
the end of the new tree.

On Mon, Jun 30, 2014 at 8:49 PM, Thomas S. Dye t...@tsdye.com wrote:
 Aloha York,

 York Zhao gtdplatf...@gmail.com writes:

 I'm selectively exporting some subtree of an org-mode buffer, like this:

 * Headline1  :export:

 #+latex: \newpage

 * Headline2
 * Headline3  :export:

 Question is: how do I force Headline3 to be on a new page while exporting to
 LaTeX?

 hth,
 Tom

 --
 Thomas S. Dye
 http://www.tsdye.com

Re: [O] still seeing semi-regular lockups

[York Zhao]

 Yeah, I'm using git emacs, labeled 24.4.50.1

Did you compile Emacs from git? I have never seen the tag 24.4.50.1, are you
sure you didn't have a typo here?

On Sat, Jun 28, 2014 at 10:23 PM, Eric Abrahamsen
e...@ericabrahamsen.net wrote:
 York Zhao gtdplatf...@gmail.com writes:

 My experience of using `org-mode' (git commit 2824502 and previous 
 versions)
 with Emacs 24.3.91 (git commit 0f0917d) had been a nightmare. I got bitten 
 by
 this bug frequently, I was mad. Some of my `org-drill' entires might have 
 been
 damaged to some extent. This was a problem with Emacs 24.3.1 (3a1ce06) too 
 but
 was much better, at least not damaging my `org-drill' flies. I will have to 
 go
 back to Emacs 24.3.1. Appears to me that Emacs 24.4 may have some bad issues.

 Yeah, I'm using git emacs, labeled 24.4.50.1.

 On Sat, Jun 28, 2014 at 3:27 PM, Eric Abrahamsen
 e...@ericabrahamsen.net wrote:
 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 After feeling like I was running behind the bus for a few weeks, I may
 have finally gotten something useful.

 FWIW I *haven't* seen any log-drawer related lockups for a while now,
 not since Nicolas said he fixed some things in that direction. But in
 the past couple of days I have had a few flyspell-related lockups, and
 finally got an uncompiled backtrace.

 This has happened the same way a few times now. A longish, text-heavy
 file, with only three top-level headlines (one of them a footnote
 section), and no drawers of any sort anywhere in the document -- very
 little Org markup at all, actually. The lockup starts at random, and
 SIGUSR2 shows me a very short backtrace related to a flyspell-mode
 related advice somewhere (I didn't save this one, it's byte-compiled, if
 it's important I'll clean out more compiled files and try to get it
 again).

 I recover from that lock, turn off flyspell-mode in my org buffer, and
 within three or four commands Org locks up again. This time the
 backtrace is related to org cache, here's the one I just got, after
 calling org-end-of-line:

 http://pastebin.com/Q0g8DmUa

 Hope that's useful! Let me know if I can provide anything else.

 E

Re: [O] still seeing semi-regular lockups

[York Zhao]

I know that doesn't help much except for confirming the problem other people was
suffering. Sorry for the rant. I was too busy and too frustrated.

By the way, what does ECM stands for?

 This is an entirely different issue, since maint branch doesn't have a cache.

I must clarify that what I meant was that I used exactly the same version of
`org-mode', from git repository, with the two Emacs versions. That said, I never
used the `org-mode' version bundled with Emacs. I'm sorry for the confusion.

1. Sometimes when Emacs hangs in `org-mode', C-g wouldn't work. Waited
patiently for awhile and C-g work again. Pressing C-g produced the error
message: Error in post-command-hook (zfill-post-command-function): (quit).
Emacs hanged again, waited patiently for awhile until C-g worked again and
Emacs revived, but in an unstable state.

2. Other times when Emacs hangs in `org-mode', C-g wouldn't work until after
perhaps 20 seconds or so, hitting C-g breaks out. Emacs enters a useless
state, nothing works even C-x C-c doesn't work, but produces error: Variable
bind exceeds maximum level or something.

A few hours ago I switched back to Emacs 24.3.1, problem 1 happened once, but
never had problem 2. And editing in `org-mode' was several times more smooth and
faster. Way better. Again, I want to stress, I was using the same `org-mode'
from git repository (commit 2824502).

Hope this would help a little bit.

On Sun, Jun 29, 2014 at 9:15 PM, York Zhao gtdplatf...@gmail.com wrote:
 Yeah, I'm using git emacs, labeled 24.4.50.1

 Did you compile Emacs from git? I have never seen the tag 24.4.50.1, are you
 sure you didn't have a typo here?

 On Sat, Jun 28, 2014 at 10:23 PM, Eric Abrahamsen
 e...@ericabrahamsen.net wrote:
 York Zhao gtdplatf...@gmail.com writes:

 My experience of using `org-mode' (git commit 2824502 and previous 
 versions)
 with Emacs 24.3.91 (git commit 0f0917d) had been a nightmare. I got 
 bitten by
 this bug frequently, I was mad. Some of my `org-drill' entires might have 
 been
 damaged to some extent. This was a problem with Emacs 24.3.1 (3a1ce06) 
 too but
 was much better, at least not damaging my `org-drill' flies. I will have to 
 go
 back to Emacs 24.3.1. Appears to me that Emacs 24.4 may have some bad 
 issues.

 Yeah, I'm using git emacs, labeled 24.4.50.1.

 On Sat, Jun 28, 2014 at 3:27 PM, Eric Abrahamsen
 e...@ericabrahamsen.net wrote:
 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 After feeling like I was running behind the bus for a few weeks, I may
 have finally gotten something useful.

 FWIW I *haven't* seen any log-drawer related lockups for a while now,
 not since Nicolas said he fixed some things in that direction. But in
 the past couple of days I have had a few flyspell-related lockups, and
 finally got an uncompiled backtrace.

 This has happened the same way a few times now. A longish, text-heavy
 file, with only three top-level headlines (one of them a footnote
 section), and no drawers of any sort anywhere in the document -- very
 little Org markup at all, actually. The lockup starts at random, and
 SIGUSR2 shows me a very short backtrace related to a flyspell-mode
 related advice somewhere (I didn't save this one, it's byte-compiled, if
 it's important I'll clean out more compiled files and try to get it
 again).

 I recover from that lock, turn off flyspell-mode in my org buffer, and
 within three or four commands Org locks up again. This time the
 backtrace is related to org cache, here's the one I just got, after
 calling org-end-of-line:

 http://pastebin.com/Q0g8DmUa

 Hope that's useful! Let me know if I can provide anything else.

 E

Re: [O] still seeing semi-regular lockups

[York Zhao]

My experience of using `org-mode' (git commit 2824502 and previous versions)
with Emacs 24.3.91 (git commit 0f0917d) had been a nightmare. I got bitten by
this bug frequently, I was mad. Some of my `org-drill' entires might have been
damaged to some extent. This was a problem with Emacs 24.3.1 (3a1ce06) too but
was much better, at least not damaging my `org-drill' flies. I will have to go
back to Emacs 24.3.1. Appears to me that Emacs 24.4 may have some bad issues.

On Sat, Jun 28, 2014 at 3:27 PM, Eric Abrahamsen
e...@ericabrahamsen.net wrote:
 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 None of those three, I'm afraid! It was hanging on a variety of editing
 operations that, as far as I can tell, had little in common. There's a
 possibility that they were list-item-related, but really there wasn't
 much commonality.

 FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
 lockups. Hopefully, it may be related to your problem (which is
 different from Daimrod's).

 Thanks for the followup! I was watching Daimrod's thread, and also
 Matt's most recent posting -- that also seemed more relevant to my
 problems, which were almost solely confined to log/state notes. I've
 pulled the fix, and will let you know if I see any more problems.

 After feeling like I was running behind the bus for a few weeks, I may
 have finally gotten something useful.

 FWIW I *haven't* seen any log-drawer related lockups for a while now,
 not since Nicolas said he fixed some things in that direction. But in
 the past couple of days I have had a few flyspell-related lockups, and
 finally got an uncompiled backtrace.

 This has happened the same way a few times now. A longish, text-heavy
 file, with only three top-level headlines (one of them a footnote
 section), and no drawers of any sort anywhere in the document -- very
 little Org markup at all, actually. The lockup starts at random, and
 SIGUSR2 shows me a very short backtrace related to a flyspell-mode
 related advice somewhere (I didn't save this one, it's byte-compiled, if
 it's important I'll clean out more compiled files and try to get it
 again).

 I recover from that lock, turn off flyspell-mode in my org buffer, and
 within three or four commands Org locks up again. This time the
 backtrace is related to org cache, here's the one I just got, after
 calling org-end-of-line:

 http://pastebin.com/Q0g8DmUa

 Hope that's useful! Let me know if I can provide anything else.

 E

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

[York Zhao]

Hi Bastien,

Thank you very much for implementing this. Really appreciated. So do you think
it is a good idea to add my test (the patch) now for testing this?

For your convenience, I've attached again in this message the same patch I had
sent on April 10.

Thanks,

York


On Sun, Apr 20, 2014 at 3:56 PM, York Zhao gtdplatf...@gmail.com wrote:
 Hi Bastien,

 I apologize that I missed your reply, I discovered it until now when I was
 checking the replies in the Sent folder.

 The question is this: are we fine handling raw links in properties,
 or do we also need Org links (e.g. bracket links) there?

 To me, raw link is hardly useful because too often the web link is really 
 long,
 in which case the bracket link acts like a way of abstraction.

 Thank you very much for considering this fix.

 On Thu, Apr 17, 2014 at 2:48 PM, Bastien b...@gnu.org wrote:
 Hi York,

 York Zhao gtdplatf...@gmail.com writes:

 * Peter
 :PROPERTIES:
 :ADDRESS: xxx xxx  
 :HOME_PHONE: xxx xxx xxx
 :WORK_PHONE: xxx xxx xxx
 :URL: www.foo.bar
 :END:

 The question is this: are we fine handling raw links in properties,
 or do we also need Org links (e.g. bracket links) there?

 Speaking for me, raw links is enough, and this is what I plan to
 implement.  But maybe other users have existing use-cases for Org
 links there, I don't know.

 --
  Bastien
From df0788134a16baa9762616637c0fe7f568e3e63e Mon Sep 17 00:00:00 2001
From: York Zhao gtdplatf...@gmail.com
Date: Thu, 10 Apr 2014 21:21:15 -0400
Subject: [PATCH] test-org-element: Add test for `org-open-at-point' with link
 being heading property.

---
 testing/lisp/test-org-element.el | 9 +
 1 file changed, 9 insertions(+)

diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 576e3d3..8cfceac 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -1461,6 +1461,15 @@ e^{i\\pi}+1=0
 	(search-forward file:)
 	(org-element-property :type (org-element-context))
 
+(ert-deftest test-org-element/org-open-at-point ()
+  Test `org-open-at-point' with link being a heading property.
+  (org-test-with-temp-text
+  * Headline
+:PROPERTIES:
+:URL: point[[info:org#Top]]
+:END:
+(org-open-at-point)))
+
 
  Macro
 
-- 
1.8.4

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

[York Zhao]

Hi Bastien,

I apologize that I missed your reply, I discovered it until now when I was
checking the replies in the Sent folder.

 The question is this: are we fine handling raw links in properties,
 or do we also need Org links (e.g. bracket links) there?

To me, raw link is hardly useful because too often the web link is really long,
in which case the bracket link acts like a way of abstraction.

Thank you very much for considering this fix.

On Thu, Apr 17, 2014 at 2:48 PM, Bastien b...@gnu.org wrote:
 Hi York,

 York Zhao gtdplatf...@gmail.com writes:

 * Peter
 :PROPERTIES:
 :ADDRESS: xxx xxx  
 :HOME_PHONE: xxx xxx xxx
 :WORK_PHONE: xxx xxx xxx
 :URL: www.foo.bar
 :END:

 The question is this: are we fine handling raw links in properties,
 or do we also need Org links (e.g. bracket links) there?

 Speaking for me, raw links is enough, and this is what I plan to
 implement.  But maybe other users have existing use-cases for Org
 links there, I don't know.

 --
  Bastien

Re: [O] (org-insert-headline '(4)) should insert new headline before point

[York Zhao]

Hi Bastian,

I apologize for missing your reply until I check in the folder Sent.

I'm sorry that my bug report might not be clear enough. What I meant was that
with one prefix argument, the command `org-insert-heading' should insert a new
heading *before* the current heading, not after. In this regard the behavior
should be exactly the same as when this command is executed with no prefix
argument. I've written a test for this:

--8---cut here---start-8---
(ert-deftest yz-test-org/org-insert-heading ()
  Test `org-insert-heading' with one universal prefix argument.
  (org-test-with-temp-text
  * Headline
(org-insert-heading '(4)) ; This test will pass without prefix argument
(forward-line)
(should (looking-at \\* Headline
--8---cut here---end---8---

This test fails on current org-mode version, but will pass if you test it on the
version shipped with Emacs 24.3. Also, if you change `(org-insert-heading '(4))'
to `(org-insert-heading)' this test will pass too.

Also, with current org-mode, if you replace `(forward-line)' in the test with
`(forward-line -1)' (moving to previous line) the test will pass, which means
that the new heading had been inserted after the current heading, not before.

Let me know if this is still not clear.


Thanks,

York

On Thu, Apr 17, 2014 at 10:21 AM, Bastien b...@gnu.org wrote:
 Hi York,

 York Zhao gtdplatf...@gmail.com writes:

 (org-insert-headline '(4)) used to insert new heading before point. But this 
 had
 broken recently. According to the docstring, this command inserts new
 heading at the end of the parent subtree  ONLY if two universal prefix
 arguments is given, not one. Here's the reproducer:

 Not sure what precise error you're reporting here, but I fixed the
 docstring in the master branch -- please have a look and report if
 the behavior differs from what the docstring says.

 Thanks,

 --
  Bastien

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

[York Zhao]

Hi Bastien,

Sorry that I didn't know this was a known issue and I appreciate that you are
willing to fix it.

While I agree with Nicolas that it is more appropriate to keep org schedule line
from being a headline property, I also think it is totally legitimate to have an
org link as headline property. Sure we can always move org links out of headline
properties, but I'm sure there are times we don't want to see some of the links
all the time, we really want to hide them inside the property tree. For example,
when we put a person's information as properties, like the following:

* Peter
:PROPERTIES:
:ADDRESS: xxx xxx  
:HOME_PHONE: xxx xxx xxx
:WORK_PHONE: xxx xxx xxx
:URL: www.foo.bar
:END:

We hope we don't have to always move the link (the URL line in the properties
tree) out, i.e., we don't want to see the link all the time.

 Let's add tests when they don't fail :)

Fair enough, just make sure it will not be forgotten.

Thanks

On Fri, Apr 11, 2014 at 6:25 AM, Bastien b...@gnu.org wrote:
 Hi York,

 York Zhao gtdplatf...@gmail.com writes:

 I found a bug that `org-open-at-point' doesn't work if the link is a
 heading property.

 This is a known issue and we will address it soon.

 This used to work and was broken recently. I have written a test for
 this. The test is suppose to fail in current org-mode version. Please find
 attached my patch for the test. Hopefully I I didn't place the test in the 
 wrong
 file.

 Let's add tests when they don't fail :)

 --
  Bastien

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

[York Zhao]

Hi,

I found a bug that `org-open-at-point' doesn't work if the link is a heading
property. This used to work and was broken recently. I have written a test for
this. The test is suppose to fail in current org-mode version. Please find
attached my patch for the test. Hopefully I I didn't place the test in the wrong
file.

York
From df0788134a16baa9762616637c0fe7f568e3e63e Mon Sep 17 00:00:00 2001
From: York Zhao gtdplatf...@gmail.com
Date: Thu, 10 Apr 2014 21:21:15 -0400
Subject: [PATCH] test-org-element: Add test for `org-open-at-point' with link
 being heading property.

---
 testing/lisp/test-org-element.el | 9 +
 1 file changed, 9 insertions(+)

diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 576e3d3..8cfceac 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -1461,6 +1461,15 @@ e^{i\\pi}+1=0
 	(search-forward file:)
 	(org-element-property :type (org-element-context))
 
+(ert-deftest test-org-element/org-open-at-point ()
+  Test `org-open-at-point' with link being a heading property.
+  (org-test-with-temp-text
+  * Headline
+:PROPERTIES:
+:URL: point[[info:org#Top]]
+:END:
+(org-open-at-point)))
+
 
  Macro
 
-- 
1.8.4

[O] Patch to fix `org-test-with-temp-text'

[York Zhao]

Hi list,

I've just found a bug in `org-test-with-temp-text' and have fixed it. Please
find attached my patch for the fix. Here's the description from git commit
message:

According to the docstring, if the string point appears in TEXT then the
string point is removed and point is placed there. The problem was that
after string point was removed, the point was *not* placed at the position
of the removed text, rather, it was placed one character before that position
which is wrong. The reason is that Emacs buffer position is a number started
from 1, instead of 0, in other words, the value of `(point-min)' is 1 not 0. The
problem is addressed by adding 1 to the calculated position.

I'm going to report another bug together with a reproducer written as an
org-test. But my test relies on my fix in `org-test-with-temp-text'. Therefor,
I will appreciate it if this patch can be taken care of as soon as possible.

Thank you,

York
From 9bbfc37ab059e923c57eaa99e3a2d81144c80218 Mon Sep 17 00:00:00 2001
From: York Zhao gtdplatf...@gmail.com
Date: Wed, 9 Apr 2014 13:39:16 -0400
Subject: [PATCH] testing/org-test.el (org-test-with-temp-text): Fix point
 position

According to the docstring, if the string point appears in TEXT
then the string point is removed and point is placed there. The
problem was that after string point was removed, the point
was *not* placed at the position of the removed text, rather, it was
placed one character before that position which is wrong. The reason
is that Emacs buffer position is a number started from 1, instead of
0, in other words, the value of `(point-min)' is 1 not 0. The problem
is addressed by adding 1 to the calculated position.

TINYCHANGE
---
 testing/org-test.el | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/testing/org-test.el b/testing/org-test.el
index 879d45e..983c012 100644
--- a/testing/org-test.el
+++ b/testing/org-test.el
@@ -209,11 +209,12 @@ otherwise place the point at the beginning of the inserted text.
  (with-temp-buffer
(org-mode)
(let ((point (string-match (regexp-quote point) inside-text)))
-	  (if point
-	  (progn (insert (replace-match  nil nil inside-text))
-		 (goto-char (match-beginning 0)))
-	(progn (insert inside-text)
-		   (goto-char (point-min)
+	 (if point
+	 (progn
+	   (insert (replace-match  nil nil inside-text))
+	   (goto-char (1+ (match-beginning 0
+	   (progn (insert inside-text)
+		  (goto-char (point-min)
,@body)))
 (def-edebug-spec org-test-with-temp-text (form body))
 
-- 
1.8.4

Re: [O] Prepare release 8.2.6

[York Zhao]

Hi there,

I reported a regression a few days ago, and I just knew that you are busy
preparing a new release. Since the bug I reported is a regression, I think you
may want to consider fix it before releasing the new version. Here's the bug
report I copied from the other email I had sent to this list:

(org-insert-headline '(4)) used to insert new heading before point. But this had
broken recently. According to the docstring, this command inserts new
heading at the end of the parent subtree  ONLY if two universal prefix
arguments is given, not one. Here's the reproducer:

--8---cut here---start-8---
emacs -Q -L path/to/org-mode/lisp/ --eval \
(let ((buf (get-buffer-create \test-org\))) \
(with-current-buffer buf \
(org-mode) \
(insert \* headline 1\) \
(goto-char (line-beginning-position)) \
(org-insert-heading '(4))) \
(switch-to-buffer buf))
--8---cut here---end---8---

Thanks,

York

On Sat, Apr 5, 2014 at 3:27 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 Hello,

 R. Michael Weylandt michael.weyla...@gmail.com writes:

 A few more minor things from my .emacs:

 1) In ox-latex.el, add a `downcase` around the definition of
 mint-lang in org-latex-inline-src-block and the sexp `(or (cadr
 (assq (intern lang) org-latex-minted-langs)) lang)` in
 org-latex-src-block to respect minted's convention of putting all
 language names in lowercase.

 Thank you.

 Would you mind adding a commit message, TINYCHANGE at its end, and send
 it again with git format-patch? See

   http://orgmode.org/worg/org-contribute.html

 for more information.

 2) Add a key binding C-c C-v k for org-babel-remove result in ob-keys.el. 
 (Discussed on list but I can't find the reference)

 [...]


 Regards,

 --
 Nicolas Goaziou

Re: [O] (org-insert-headline '(4)) should insert new headline before point

[York Zhao]

Any one?

On Thu, Apr 3, 2014 at 6:59 PM, York Zhao gtdplatf...@gmail.com wrote:
 Hi list,

 (org-insert-headline '(4)) used to insert new heading before point. But this 
 had
 broken recently. According to the docstring, this command inserts new
 heading at the end of the parent subtree  ONLY if two universal prefix
 arguments is given, not one. Here's the reproducer:

 --8---cut here---start-8---
 emacs -Q -L path/to/org-mode/lisp/ --eval \
 (let ((buf (get-buffer-create \test-org\)))
 (with-current-buffer buf
 (org-mode)
 (insert \* headline 1\)
 (goto-char (line-beginning-position))
 (org-insert-heading '(4)))
 (switch-to-buffer buf))
 --8---cut here---end---8---

 Thanks

[O] (org-insert-headline '(4)) should insert new headline before point

[York Zhao]

Hi list,

(org-insert-headline '(4)) used to insert new heading before point. But this had
broken recently. According to the docstring, this command inserts new
heading at the end of the parent subtree  ONLY if two universal prefix
arguments is given, not one. Here's the reproducer:

--8---cut here---start-8---
emacs -Q -L path/to/org-mode/lisp/ --eval \
(let ((buf (get-buffer-create \test-org\)))
(with-current-buffer buf
(org-mode)
(insert \* headline 1\)
(goto-char (line-beginning-position))
(org-insert-heading '(4)))
(switch-to-buffer buf))
--8---cut here---end---8---

Thanks

Re: [O] html to org-mode

[York Zhao]

Hi John Kitchin,

What is org-rss, I couldn't find it. Can you give a link?

Thanks




On Fri, Jan 3, 2014 at 11:56 PM, Feng Shu tuma...@gmail.com wrote:

 John Kitchin jkitc...@andrew.cmu.edu writes:

  Hi everyone,
 
  I was playing around with org-rss today, and it is pretty cool. I
  would like to customize the way the subheading bodies look though,
  primarily to unescape some html things like lt;, to get rid of all
  the html tags, convert a .. to org-mode links, to download img ...
  so they can be displayed, etc...
 
  for example a body of an rss entry looks like:
 
  titlePhilip Herron: Cython Book/title
  guidhttp://redbrain.co.uk/?p=147/guid
  linkhttp://redbrain.co.uk/cython-book//link descriptionpHey
  all i thought i should really share that i actually wrote a book on
  Cython. The book has detailed examples and even shows you how you can
  extend native C/C++ applications in python by doing it for Tmux. a
  href=http://bit.ly/195ahQs;http://bit.ly/195ahQs/a/p pa
  href=http://redbrain.co.uk/wp-content/uploads/2013/12/photo.jpg;img
  class=aligncenter size-full wp-image-148 alt=photo
  src=http://redbrain.co.uk/wp-content/uploads/2013/12/photo.jpg;
  width=640 height=480 //aThe code can be found: a
  href=https://github.com/redbrain/cython-book;
 https://github.com/redbrain/cython-book/a/p/description
  pubDateTue, 10 Dec 2013 14:45:08 +/pubDate
 
  I would like this simplified to something like:
  Philip Herron: Cython Book
 
  http://redbrain.co.uk/?p=147
 
  http://redbrain.co.uk/cython-book/
  Hey all i thought i should really share that i actually wrote a book
  on Cython. The book has detailed examples and even shows you how you
  can extend native C/C++ applications in python by doing it for Tmux.
  http://bit.ly/195ahQs
 
  [[feed-images/photo.jpg]]
 
  The code can be found: https://github.com/redbrain/cython-book
 
  basically, get the html code as close to org as reasonable. i found a
  way to get an html parse tree (libxml-parse-html-region start end),
  but I can't figure out how to convert that to the text I want.
 
  Has anyone done anything like this?
 
  John

 Maybe eww can help you...

 
  ---
  John Kitchin
  Associate Professor
  Doherty Hall A207F
  Department of Chemical Engineering
  Carnegie Mellon University
  Pittsburgh, PA 15213
  412-268-7803
  http://kitchingroup.cheme.cmu.edu

 --

Re: [O] commit 5ea0228 has problem opening big org-mode file

[York Zhao]

 It could have (depending on what other files you might have had there,
 not from the Git repo).

May happen in theory, but never in real life, at least never happen on me.

 It certainly muddied the waters w.r.t. your bug report.

I had provided a reproducer proved to be straightforward and effective, period.

 For the rest of your post: no need to get defensive.

I certainly had perceived offensive atmosphere from your post, be friendly
please.


Thanks,

York

Re: [O] commit 5ea0228 has problem opening big org-mode file

[York Zhao]

 The only path that needs to be in load-path is the lisp directory for
 org-mode, which is the second line (that you say is key).

You are right on this which I didn't realize before you pointed out, thanks.
Anyways, in my configuration I always have both lines, and I'm going to delete
the first line. And also, when I was trying to reproduce the issue in a minimum
setup, I deleted the second line then the problem didn't show up which I now
realized was simply because I ended up running the `org-mode' shipped with Emacs
24.3, my bad, sorry for the confusion.

 Unless you have created your completely original way of installing Org, then
 only the second line is needed.

As explained above, yes, my `org-mode' is in some other path outside of Emacs,
e.g., foo/org-mode, which I had already explained, I'm going to delete the
first line. But it doesn't hurt to have the first line anyways right?

 If you do have created your own completely original way of installing Org,
 then please don't expect anybody else to be able to help.

It should have been clear by now that this was a real problem totally
unrelated to my own completely original way of installing Org and had been
addressed properly. I'm not sure if you had tried my reproducer.

 Yes, because you wouldn't load any of the new code.

Already explained on this in previous paragraphs.

 Maybe because your installation is borked,

No, my installation had never broken, and as we've all seen, the problem has
nothing to do with my broken installation.

 but we can't know because you never provided enough information to tell.

I'm pretty sure I had provided pretty effective reproducer with which Nicolas
had successfully reproduced the issue. By the way, it took me two hours to
isolate it from my own .emacs (over 400KB).

 There's a reason for org-submit-bug-report to exist; among other things it
 includes information about the Emacs and Org version and clueas as to how the
 installation is set up.

I didn't know that, thanks for telling me.


York

Re: [O] commit 5ea0228 has problem opening big org-mode file

[York Zhao]

 York Zhao writes:
 (add-to-list 'load-path path/to/org-mode)

 This line is not needed.

My org-mode is installed in separate directory outside of Emacs system and
therefor this line is needed in my setup, otherwise the org-mode shipped with
Emacs would be used.

 (add-to-list 'load-path path/to/org-mode/lisp)  ; this line is the
 key

 Key for what?  Did you create autoload files for this installation?

Key for reproducing the problem. I wouldn't get the problem without this line.

 Third, file yhj-mode.el has to be byte-compiled.

 You'll have to byte-compile it while the load-path is already set to
 include your Org installation, otherwise it will pick up the Org shipped
 with Emacs.

yhj-mode.el is the file used to reproduce the problem, in my system I have to
byte-compile this file, otherwise I wouldn't get the problem. But apparently
Nicolas doesn't need to byte-compile this file and still reproduced the issue.
Have no idea why.

York

Re: [O] commit 5ea0228 has problem opening big org-mode file

[York Zhao]

 Can both interested parties (York Zhao and Tom Dye) please test it and let me
 know of any problems?

Thank you for the fix, your patch worked for me.

York

Re: [O] org-capture with function type target

[York Zhao]

Hi Carsten,

Thank you.

York

Re: [O] commit 5ea0228 has problem opening big org-mode file

[York Zhao]

Oop, I didn't know that I replied to Nicolas instead of to the list because I
hitted reply instead of reply all. So I'm reposting my previous post to the
list. Here we go:

In my previous post I actually meant to say that I set `debug-on-quit', have no
idea why I did `debug-on-error'. But anyways, I'm now pretty sure it was commit
5ea0228 that causes problem because the moment I deleted the last two lines in
(define-derived-mode org-mode outline-mode Org) everything worked fine.
Demonstrated below:

(define-derived-mode org-mode outline-mode Org
   ...
  ;; Delete these two lines and everything worked.
   (report-errors File local-variables error: %s
 (hack-local-variables))
)

Also, I figured out that it was my major mode that derived from `org-mode'
didn't work, and the buffer showed in org-mode, instead of my derived mode. But
my mode is as simple as:

(define-derived-mode yhj-mode org-mode yhj
  )

With some special key bindings specific to my file that is opened in `yhj-mode'.

By the way, I had toggled `debug-on-quit', but made no difference when I hit
C-g.


Thanks,

York

On Mon, Nov 25, 2013 at 2:26 PM, Thomas S. Dye t...@tsdye.com wrote:
 Nick Dokos ndo...@gmail.com writes:

 It may be that hack-local-variables takes a long time to process a large
 file, although I don't think so: iirc, it limits itself to a tail of the
 file of a given size, or the last page of the file (demarcated by ^L),
 whichever is smaller.

 Hi Nick,

 I haven't noticed any slowdown or hangs since hack-local-variables was
 introduced.

 I have noticed that I need to answer the query about loading file local
 variables twice:

 Please type y, n, or !, or C-v to scroll: y [2 times]

 The first y has no apparent effect (except to make the second y
 effective).

 hth,
 Tom

 --
 Thomas S. Dye
 http://www.tsdye.com

Re: [O] commit 5ea0228 has problem opening big org-mode file

[York Zhao]

OK, finally I was able to reproduce the problem with a minimal setup.

First goes .emacs file:

--8---cut here---start-8---
(add-to-list 'load-path path/to/org-mode)
(add-to-list 'load-path path/to/org-mode/lisp)  ; this line is the key
(add-to-list 'load-path path/to/yhj-mode)
(require 'yhj-mode)
--8---cut here---end---8---

Second goes yhj-mode.el:

--8---cut here---start-8---
(require 'org)
(define-derived-mode yhj-mode org-mode yhj)
(provide 'yhj-mode)
--8---cut here---end---8---

Finally, file test.yz:

--8---cut here---start-8---
# -*- mode:yhj -*-
--8---cut here---end---8---

Open file test.yz and note the comment line not fortified, open *message*
buffer and note the following error:

File local-variables error: (error Lisp nesting exceeds `max-lisp-eval-depth')

There are three keys to reproduce, first, you have to make two files, .emacs and
yhj-mode.el. Second, this line must be present:

(add-to-list 'load-path path/to/org-mode/lisp)  ; this line is the key

Third, file yhj-mode.el has to be byte-compiled.

York


On Mon, Nov 25, 2013 at 5:39 PM, York Zhao gtdplatf...@gmail.com wrote:
 Oop, I didn't know that I replied to Nicolas instead of to the list because I
 hitted reply instead of reply all. So I'm reposting my previous post to 
 the
 list. Here we go:

 In my previous post I actually meant to say that I set `debug-on-quit', have 
 no
 idea why I did `debug-on-error'. But anyways, I'm now pretty sure it was 
 commit
 5ea0228 that causes problem because the moment I deleted the last two lines 
 in
 (define-derived-mode org-mode outline-mode Org) everything worked fine.
 Demonstrated below:

 (define-derived-mode org-mode outline-mode Org
...
   ;; Delete these two lines and everything worked.
(report-errors File local-variables error: %s
  (hack-local-variables))
 )

 Also, I figured out that it was my major mode that derived from `org-mode'
 didn't work, and the buffer showed in org-mode, instead of my derived mode. 
 But
 my mode is as simple as:

 (define-derived-mode yhj-mode org-mode yhj
   )

 With some special key bindings specific to my file that is opened in 
 `yhj-mode'.

 By the way, I had toggled `debug-on-quit', but made no difference when I hit
 C-g.


 Thanks,

 York

 On Mon, Nov 25, 2013 at 2:26 PM, Thomas S. Dye t...@tsdye.com wrote:
 Nick Dokos ndo...@gmail.com writes:

 It may be that hack-local-variables takes a long time to process a large
 file, although I don't think so: iirc, it limits itself to a tail of the
 file of a given size, or the last page of the file (demarcated by ^L),
 whichever is smaller.

 Hi Nick,

 I haven't noticed any slowdown or hangs since hack-local-variables was
 introduced.

 I have noticed that I need to answer the query about loading file local
 variables twice:

 Please type y, n, or !, or C-v to scroll: y [2 times]

 The first y has no apparent effect (except to make the second y
 effective).

 hth,
 Tom

 --
 Thomas S. Dye
 http://www.tsdye.com

[O] commit 5ea0228 has problem opening big org-mode file

[York Zhao]

Hi List,

I have an org-mode file that is 3230004 bytes in size. With commit 92f30ae it
can be opened without any problem. However, with commit 5ea0228 the same file
could not be opened properly.

What I did was: I opened Dired buffer, select the file, press enter, nothing
happened and Emacs locks up, hit C-g to get out, and I noticed that the file had
actually been opened, so I just visited the buffer, this time the contents of
the file appeared, but my org-tables are not fontified at all.

Just now I tried again, this time I toggled debug on error on, closed the
file, and tried to open the file, again, Emacs locks up, hit C-g and my emacs
revived, again, the file had been opened, just didn't show up. So I visited the
buffer, this time my org-tables are fontified properly.

What's the problem do you think this could be?


Thanks,

York

Re: [O] org-capture with function type target

[York Zhao]

To whom it may concern,

Please find attached my patch to address this issue. Please let me
know if the patch is acceptable.

Thanks,

York


On Sat, Nov 16, 2013 at 8:13 PM, York Zhao gtdplatf...@gmail.com wrote:
 Hi list,

 I'm been so frustrated when trying to use function as `target' in an
 org-capture' template, here is my example:

 1. Create a file ~/test.org and add a line * Level 1, make sure to add a
 newline character after the inserted line
 2. Set org-capture-template as:
 (setq org-capture-templates
   `((t
  Test
  entry
  (function
   (lambda ()
 (set-buffer (org-capture-target-buffer ~/test.org))
 (goto-char (point-max
  * Level 2
  :immediate-finish t)))
 3. Type C-c c t
 4. The result of test.org becomes:

 * Level 1
 * Level 2

 But what I wanted is:

 * Level 1
 ** Level 2

 I looked into org-capture.el and figured out that it is because when
 `:exact-position' is set, function `org-capture-place-entry' never insert
 template as a child of current entry. And `:exact-position' is set when Target
 is a function.

 I don't understand why it is designed this way, does it have to be this way?
 what can I do if I want to insert Level 2 as a child of Level 1 while 
 using
 a function as template target?


 Thanks,

 York


0001-org-capture-place-entry-Do-not-special-casing-for-ex.patch
Description: Binary data

[O] org-capture with function type target

[York Zhao]

Hi list,

I'm been so frustrated when trying to use function as `target' in an
org-capture' template, here is my example:

1. Create a file ~/test.org and add a line * Level 1, make sure to add a
newline character after the inserted line
2. Set org-capture-template as:
(setq org-capture-templates
  `((t
 Test
 entry
 (function
  (lambda ()
(set-buffer (org-capture-target-buffer ~/test.org))
(goto-char (point-max
 * Level 2
 :immediate-finish t)))
3. Type C-c c t
4. The result of test.org becomes:

* Level 1
* Level 2

But what I wanted is:

* Level 1
** Level 2

I looked into org-capture.el and figured out that it is because when
`:exact-position' is set, function `org-capture-place-entry' never insert
template as a child of current entry. And `:exact-position' is set when Target
is a function.

I don't understand why it is designed this way, does it have to be this way?
what can I do if I want to insert Level 2 as a child of Level 1 while using
a function as template target?


Thanks,

York

Re: [O] `org-drill' broken in recent commits git commits

[York Zhao]

Hi Bastien,

I have figured out that I could press S-arrow to change the date when being
asked to input a date after selected '2'. I found that if I change it to a
future date I will not be asked for this question in the current drill session
because the scheduled date has been set to a future date; however, changing to a
date before the current datehas no effect. The question is why asking me to
choose a date? It was not behaving like this and I don't think there is any
changes in `org-drill', in other words, it looks like that recent changes in
`org-mode' (not `org-drill') affected the behavior of `org-drill'.

But anyways, this is no longer a big problem and it is tolerable. Thank you very
much for the help.

York


On Wed, Feb 20, 2013 at 1:11 AM, Bastien b...@altern.org wrote:
 Hi York,

 well, I did try org-drill.el to see if there was no trivial error
 triggered by a recent change in Org's master, but found none.

 Paul, can you understand/reproduce/fix York's problem?

 Best,

 --
  Bastien

Re: [O] `org-drill' broken in recent commits git commits

[York Zhao]

Hi Bastien,

Thank you very much for the reply. Sorry that I forgot to mention my Emacs
version. I'm using GNU Emacs 24.2.1.

I just tried the scenario again with the latest `org-mode' and the symptom
changed a bit. I no longer get stuck which is good however, after typed the
character `2', I was asked to input a date, but I could only accept the default
date and was not able to change this date. Asking to input a date is a new
behavior and makes no sense especially when the default date is not changeable.
I have checked the `org-drill' and it seems that the `org-drill' hasn't been
changed for a few months.

When you test `org-drill' on the sample file have you been asked to input a
date?

Thanks,

York

On Sat, Feb 16, 2013 at 9:38 AM, Bastien b...@altern.org wrote:
 Hi York,

 York Zhao gtdplatf...@gmail.com writes:

 Hi there, `org-drill' has broken recently (after git commit
 3380460), here is the steps
 to reproduce the issue:

 1. Create a new org-mode buffer with the following contents:

 * org-drill test  :drill:
 Foo
 ** Answer
 Bar

 2. M-x org-drill
 3. Press SPACE
 4. Press `2' and you are stuck there forever until pressing `q' or C-g.

 I cannot reproduce this.  Does this happen with emacs -Q?  What is
 your version of Emacs?

 Thanks,

 --
  Bastien

[O] `org-drill' broken in recent commits git commits

[York Zhao]

Hi there, `org-drill' has broken recently (after git commit
3380460), here is the steps
to reproduce the issue:

1. Create a new org-mode buffer with the following contents:

* org-drill test  :drill:
Foo
** Answer
Bar

2. M-x org-drill
3. Press SPACE
4. Press `2' and you are stuck there forever until pressing `q' or C-g.

Thanks,

York

Re: [O] Feature suggestion

[York Zhao]

 York Zhao gtdplatf...@gmail.com writes:

 May I suggest a feature that when the point is inside a TeX source block and
 C-c C-c is pressed, instead of showing the error No org-babel-execute
 function for tex!, can we process the current tex block to output the dvi or
 pdf file?

 I'd rather define a org-babel-execute:tex function for that.

 Maybe look at org-babel-execute:* functions and suggest one?

 Thanks!

Hi Bastien,

I think this is a good idea. By `org-babel-execute:tex' do you mean
`org-babel-execute-tex'?


York

Re: [O] LaTeX export

[York Zhao]

 Read Chapter 14 of the Org-mode manual. And go to
 http://orgmode.org/worg/ and search with the keyword literate.

Thanks, I've read these already, they are helpful.

Happy New Year
York

[O] Feature suggestion

[York Zhao]

Hi,

May I suggest a feature that when the point is inside a TeX source block and
C-c C-c is pressed, instead of showing the error No org-babel-execute
function for tex!, can we process the current tex block to output the dvi or
pdf file?

Thanks,

York

Re: [O] LaTeX export

[York Zhao]

 I would use code blocks tangling

 ,
 | #+TITLE: Test
 |
 | * Test headline
 |
 | #+begin_src tex :tangle yes
 | \documentclass{article}
 | \begin{document}
 | ...
 | \end{document}
 | #+end_src
 `

 `C-c C-v t' on the block will create a .tex file with the exact content
 of the #+begin_src block.

 HTH,

 --
  Bastien

Hi Bastien,

Thanks a lot, this really works, and it sounds like literate programming. Can
you suggest some quick reading on using org-mode for literate programming?

Happy new year,

York

[O] LaTeX export

[York Zhao]

Hi there,

I'm wondering if there is a way to export ONLY the LaTeX code within
#+begin_latex and #+end_latex. I want the exact literal export without
adding anything before and after my code. The result should be exactly the same
as if I have copied the block between #+begin_latex and #+end_latex and
pasted to a new buffer.

Thanks,


York

Re: [O] org-time-stamp and org-time-stamp-inactive no longer work

[York Zhao]

 To keep this list updated, I just upgraded to the latest Emacs from git,
 compiled and linked using mingw and this problem no longer exists. Thank you 
 all
 for your help and merry Christmas.

 Thanks for the update!

 --
  Bastien

You are welcome Bastien and Merry Christmas.


York

Re: [O] org-time-stamp and org-time-stamp-inactive no longer work

[York Zhao]

 Matt reported a similar problem in

 http://thread.gmane.org/gmane.emacs.orgmode/41336/focus=41341

 But it seems the problem just ... fixed itself:

 ,
 | However, oddly, after experiencing the same issue about 6 times in a
 | row, the problem mysteriously disappeared just now, and the procedure
 | is working fine.  I have no idea what the issue is there -- I'll
 | report when I find it again.  Maybe someone on the list can give me
 | suggestions for debugging if it shows up again?
 `

 Thanks for the help David and Nick, I would say that my problem looks 
 extremely
 similar (if not exactly the same) like Matt had reported.

  1. Try to reproduce the bug with a minimal setup, just Emacs +
     uncompiled Org mode;

 I will try this at some point.

  2. If this is possible, see if it occurrs if the calendar buffer is
    already open (e.g. M-x calendar RET) -- maybe this is some kind of
    a weird race condition (?).

 I'm sure there was no calendar buffer pre-existing. The wield thing is that
 whenever this problem happens, the contents of my other buffer would be 
 replaced
 with the calendar while the name of the buffer kept unchanged.


To keep this list updated, I just upgraded to the latest Emacs from git,
compiled and linked using mingw and this problem no longer exists. Thank you all
for your help and merry Christmas.


York

Re: [O] org-time-stamp and org-time-stamp-inactive no longer work

[York Zhao]

 Matt reported a similar problem in

 http://thread.gmane.org/gmane.emacs.orgmode/41336/focus=41341

 But it seems the problem just ... fixed itself:

 ,
 | However, oddly, after experiencing the same issue about 6 times in a
 | row, the problem mysteriously disappeared just now, and the procedure
 | is working fine.  I have no idea what the issue is there -- I'll
 | report when I find it again.  Maybe someone on the list can give me
 | suggestions for debugging if it shows up again?
 `

Thanks for the help David and Nick, I would say that my problem looks extremely
similar (if not exactly the same) like Matt had reported.

  1. Try to reproduce the bug with a minimal setup, just Emacs +
     uncompiled Org mode;

I will try this at some point.

  2. If this is possible, see if it occurrs if the calendar buffer is
    already open (e.g. M-x calendar RET) -- maybe this is some kind of
    a weird race condition (?).

I'm sure there was no calendar buffer pre-existing. The wield thing is that
whenever this problem happens, the contents of my other buffer would be replaced
with the calendar while the name of the buffer kept unchanged.

Thanks,

York

[O] org-time-stamp and org-time-stamp-inactive no longer work

[York Zhao]

Hi,

I have noticed this problem for awhile and now I think it is worth reporting it
and hopefully get fixed.

Here is what happened when I hit C-c ! in org buffer:

Debugger entered--Lisp error: (wrong-type-argument window-live-p nil)
  select-window(nil)
  org-eval-in-calendar(nil t)
  byte-code(\306 \210\307\216\310\311!\312 \211\313 8)\314\315!\203!



  org-read-date(nil totime nil nil (20194 25121 578000) nil)
  org-time-stamp(nil inactive)
  org-time-stamp-inactive(nil)
  call-interactively(org-time-stamp-inactive nil nil)

Thanks,

Re: [O] org-time-stamp and org-time-stamp-inactive no longer work

[York Zhao]

 What is your version of Emacs and Org-mode?

Emacs v23.3.1 on Windows, Org-mode version 7.7 (release_7.7.625.gf18b1)

Thanks,

York

Re: [O] org-time-stamp and org-time-stamp-inactive no longer work

[York Zhao]

 Does that version exist? I just pulled and I get

 Org-mode version 7.7 (release_7.7.624.gda56)

I guess it should be (release_7.7.624.gda56) then because I always have one
commit ahead of the latest which is for my local Makefile configuration. Every
time I pulled, I rebased my commit. Sorry for the confusion.


Thank,


York

[O] org-sort doesn't work properly on active region

[York Zhao]

Hi,

When using org-sort on a selected region, it doesn't work properly, I expected
it to sort all the headlines in the region, however, not only does the region
get sorted but also, the headlines get sorted are being combinded into one line
which I don't think is correct. Hopefully somebody will take a look on
this issue.


Thanks

[O] Fwd: org-sort doesn't work properly on active region

[York Zhao]

 When using org-sort on a selected region, it doesn't work properly, I 
 expected
 it to sort all the headlines in the region, however, not only does the region
 get sorted but also, the headlines get sorted are being combinded into one 
 line
 which I don't think is correct. Hopefully somebody will take a look on
 this issue.


 Can't reproduce it with Org-mode version 7.7 (release_7.7.513.g2a5877)

 Please provide emacs version, org-mode version, an ECM (minimal example file)
 and the steps you follow *in detail*.

Thanks for the reply, my emacs version is v23.3.1, I'm using the org-mode from
git, commit a4273c (probably the latest).


York

Re: [O] org-sort doesn't work properly on active region

[York Zhao]

 4) I still cannot reproduce the problem, even with latest git.

It turns out that this was my own configuration problem and not a bug, I
apologize for the false report and appreciate Nick's help.

Thanks,


York

Re: [O] org-sort doesn't work properly on active region

[York Zhao]

 an ECM is a minimal example file: a small org file that shows the problem, as
 small as you can make it and still have it show the problem.

Thanks Nick

[O] C-M showing up everywhere in the INFO file

[York Zhao]

Hi,

I'm using the lasted org-mode from git, I used make install info to generate the
INFO file and I have verified that the file org has been copied to the info
directory of my emacs directory. I'm using Windows, and the problem is that
C-M is appearing everywhere in this INFO file which is extremely painful. What
can I do about these carriage return (0x0d)?

Thanks,

York