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  wrote:

> York Zhao  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  wrote:

> York Zhao  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  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  wrote:
>
>> York Zhao  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  wrote:

> York Zhao  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  wrote:

> York Zhao  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  wrote:

> Hi,
>
> York Zhao  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  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  wrote:
> >> > York Zhao  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  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  wrote:
> > York Zhao  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  wrote:
> York Zhao  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  wrote:
> York Zhao  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
 wrote:
> Eric S Fraga  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  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  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]

> 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  wrote:

> Hi,
>
> York Zhao  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]

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  wrote:

> York Zhao  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]

> #+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  wrote:

> Hi,
>
> York Zhao  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  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 
> wrote:
>
>> Hello,
>>
>> York Zhao  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 
wrote:

> Hello,
>
> York Zhao  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  wrote:

> Hi,
>
> York Zhao  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  wrote:

> York Zhao  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  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  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 
>> wrote:
>>
>>> Hello,
>>>
>>> York Zhao  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  wrote:
> Hello,
>
> York Zhao  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  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  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] 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]

>> + 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] 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:

+ #11,320,032  43%
+ call-interactively4,857,849  18%
+ # 2,170,499   8%
+ timer-event-handler   1,428,527   5%
+ #  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%
+ #   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%
+ # 33,140   0%
+ helm--compute-sources31,988   0%
+ yas--post-command-handler29,288   0%
+ org-element--parse-to29,184   0%
+ # 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-handler1786  33%
+ redisplay_internal (C function) 131   2%
+ 

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 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.

[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 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

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] 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]

> 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] 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]

> 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] 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.

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]

> 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]

> 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] 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]

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

This should work, but didn't, I will figure out why when I have some time.

> Also, see the LaTeX commands \pagebreak and \clearpage, which do generally the
> same thing but in slightly different ways.

I was aware of these, but if \newpage doesn't work I don't think these will
work. But thank you very much anyway.

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  wrote:
> Aloha York,
>
> York Zhao  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

[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] 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)

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  wrote:
> Hello,
>
> York Zhao  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]

> 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  wrote:
> Aloha York,
>
> York Zhao  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

[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] 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  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
>  wrote:
>> York Zhao  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
>>>  wrote:
>>>> Eric Abrahamsen  writes:
>>>>
>>>>> Nicolas Goaziou  writes:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Eric Abrahamsen  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]

> 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
 wrote:
> York Zhao  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
>>  wrote:
>>> Eric Abrahamsen  writes:
>>>
>>>> Nicolas Goaziou  writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> Eric Abrahamsen  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
 wrote:
> Eric Abrahamsen  writes:
>
>> Nicolas Goaziou  writes:
>>
>>> Hello,
>>>
>>> Eric Abrahamsen  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  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  wrote:
>> Hi York,
>>
>> York Zhao  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 
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: [[info:org#Top]]
+:END:"
+(org-open-at-point)))
+
 
  Macro
 
-- 
1.8.4

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  wrote:
> Hi York,
>
> York Zhao  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,

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  wrote:
> Hi York,
>
> York Zhao  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] 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  wrote:
> Hi York,
>
> York Zhao  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 
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: [[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 "" appears in TEXT then the
string "" is removed and point is placed there. The problem was that
after string "" 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 
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 "" appears in TEXT
then the string "" is removed and point is placed there. The
problem was that after string "" 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 "") 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  wrote:
> Hello,
>
> "R. Michael Weylandt"  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  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  wrote:

> John Kitchin  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 <, to get rid of all
> > the html tags, convert  to org-mode links, to download 
> > so they can be displayed, etc...
> >
> > for example a body of an rss entry looks 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.  > href="http://bit.ly/195ahQs";>http://bit.ly/195ahQs  > href="http://redbrain.co.uk/wp-content/uploads/2013/12/photo.jpg";> > 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" />The code can be found:  > href="https://github.com/redbrain/cython-book";>
> https://github.com/redbrain/cython-book
> > Tue, 10 Dec 2013 14:45:08 +
> >
> > 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] 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]

> 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] 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]

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  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  wrote:
>> Nick Dokos  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]

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  wrote:
> Nick Dokos  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  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  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  wrote:
> Hi York,
>
> York Zhao  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 
>> 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 
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  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

[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]

> 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

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
>>
>> 
>>
>> 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
>
> 
>
> 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

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

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

[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-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

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

[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

[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] "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