William Denton writes:
> So if anyone out there is using org-bullets and runs into a problem, try
> removing it and see if that helps.
Not necessarily. Recent patch (d3143feaf) removed the call to
org-element-keyword-parser completely, which was probably the real fix
;)
Best,
Ihor
"Christopher M. Miles" writes:
> My Emacs version (on M1 macOS)
>
> GNU Emacs 28.0.60 (build 1, aarch64-apple-darwin20.6.0, NS appkit-2022.60
> Version 11.6 (Build 20G165)) of 2021-10-20
>
> Thanks for your continuous working. I pulled latest fix, still not working.
I also tested using Emacs
Tim,
i wonder if the emacs variable `load-history` might be of (approximate)
help? i submit a starter routine below. as the comments say: caveat,
caveat, caveat.
i don't think something as uncertain as this would be a candidate for
normal run-time checking (and, i'm not even sure when one
Tim Cross writes:
> What would really be needed is some way to check when org is going to be
> compiled that no existing org functionality is loaded. Doubt this can be
> easily done within org itself because of a chicken and egg problem - you
> would have to load org to run the code to check if
Ihor Radchenko writes:
> "Christopher M. Miles" writes:
>
>> I put this scheduled task into a separated org file and clean
>> org-agenda-files variable, and set it
>> to only this new separated org file. Not displayed.
>
> I finally managed reproduce the problem. It only exists in Emacs <28.
Greg Minshall writes:
>> Can you try to run make before your emacs -Q -L...?
>
> make of org mode? (remote possibility: emacs?)
Org mode build process is not standard. Org mode needs to create
autoload file and generate documentation in addition to normal
byte-compilation.
Best,
Ihor
Ihor Radchenko writes:
> "Christopher M. Miles" writes:
>
>> I'm git bisect on the latest git-pulled org-mode. Still located bad commit
>> on this bad commit. Seems
>> commit also introduced other problem.
>
>> #+begin_example
>> 0ef88e2d9 * | bad @ org-agenda.el/org-agenda-get-scheduled:
> Uwe Brauer writes:
> Just to make sure I'm not misundertanding: did you try to re-indent the
> whole file? You say "when I opened my org file in question I still
> saw…", so I'm not sure if you tried to re-indent, or if you merely set
> org-adapt-indentation and expected the file to be
Ihor Radchenko writes:
> "Christopher M. Miles" writes:
>> Now I tried your latest push. The errors gone. But org-agenda entries still
>> missing. I checked
>> *Messages* buffer, no error messages, including other error special buffers.
>> no information.
>
> Agenda now uses a new algorithm
Hi Igor,
> The conversation was about keywords and similar constructs (i.e.
> ^#+keyword). You are looking at property drawer and properties inside.
> There is no preference here, though internally properties in property
> drawer are all converted to upper case.
Ok, thank you very much for the
Carlos Pita writes:
>> Org is standardized on lower case. Uppercase is used in the manual as
>> a poor man's bold, and supported for historical reasons.
>
> But C-c C-x p still inserts stuff like:
>
>:PROPERTIES:
>:ARCHIVE: ...
>:END:
>
> Maybe it should be updated or maybe I don't
"Christopher M. Miles" writes:
> I'm git bisect on the latest git-pulled org-mode. Still located bad commit on
> this bad commit. Seems
> commit also introduced other problem.
> #+begin_example
> 0ef88e2d9 * | bad @ org-agenda.el/org-agenda-get-scheduled: Use cache
> #+end_example
That's
Hi
I am sending this email to four mailing list I am using most, and I am
wondering whether this subject has came up in the past.
For years I am wondering about the different syntax for
sending/reporting/submitting bug reports.
I know of
1. org-submit-bug-report but
a.
Ihor Radchenko writes:
> "Christopher M. Miles" writes:
>> Now I tried your latest push. The errors gone. But org-agenda entries still
>> missing. I checked
>> *Messages* buffer, no error messages, including other error special buffers.
>> no information.
>
> Agenda now uses a new algorithm
Hi Carlos,
Just a minor point from me, this really should be a new thread IMO. While not
much may have happened with the IETF RFC, it’s still something on my mind that I
hope to get back to eventually.
All the best,
Timothy
On 22 October 2021, Ihor Radchenko wrote:
I cannot reproduce the problem using relatively recent Emacs master
(commit ae9bfaa891c).
A blind guess: Try to run make clean?
Thanks for checking, and the suggestion. In the end I think one or the other
two things did it:
First, rebuilding
Tim, et al.,
> These types of errors are frequently caused by a 'mixed' installation
> of org versions. This will happen if you upgrade org when org is
> already loaded in the instance of emacs used to perform the upgrade.
a question: is there any way that we can, as org starts up, detect
either
Greg Minshall writes:
> Tim, et al.,
>
>> These types of errors are frequently caused by a 'mixed' installation
>> of org versions. This will happen if you upgrade org when org is
>> already loaded in the instance of emacs used to perform the upgrade.
>
> a question: is there any way that we
Colin Baxter writes:
> Hello,
>
> Assuming such a question make sense, how do I manually reset org-persist
> for all org buffers? It's not clear to me if doing M-x
> org-element-cache-reset is sufficient.
You can reset cache in all open Org buffers via
M-: (org-element-cache-reset 'all)
Ok, great -- that fixed it! I thought I had been careful to get rid of
my old org from org elpa before I installed 9.5. However, I hadn't
considered that there was an older org still installed that had been
packaged with my emacs 27.2 installation.
So thanks very much for your quick advice.
On 23/10/2021 11:06, Kyle Meyer wrote:
Hoffmann, Jobst writes:
But I think I found the culprit:
Line 17568 of org.texi reads:
@kindex C-c C-x @
and @ starts a command, which leads to the stack overflow.
Line 17568 of org.texi should read
@kindex C-c C-x @@
witha doubled
Greg Minshall writes:
> (and, after fifteen years of vi, and now 25 of emacs, i guess i'll skip
> the spacemacs experience. :)
>
Similar past for me as well. I used vi from early/mid 80x until mid 90s
and then switched to Emacs and used standard Emacs bindings until a
couple of years ago,
Ihor Radchenko writes:
Hi Igor,
> I just tried with clean Emacs:
>
> #+beg #+begin_ -> list of completions, all in lower case
> #+BEG #+BEGIN_ -> list of completions, all in upper case
>
> Seems to be all right.
You're right, I was under the impression that completion-ignore-case = t
was the
Tim,
thanks. i see that it is more complicated.
(and, after fifteen years of vi, and now 25 of emacs, i guess i'll skip
the spacemacs experience. :)
cheers, Greg
You may find this John Kitchin's blog post illuminating.
HTH,
--
Emmanuel Charpentier
"Christopher M. Miles" writes:
> I put this scheduled task into a separated org file and clean
> org-agenda-files variable, and set it
> to only this new separated org file. Not displayed.
I finally managed reproduce the problem. It only exists in Emacs <28.
byte-compiled version of agenda
Hello all,
So, following the code: every time I ask to evaluate the gnuplot src
block in the minimal example I posted yesterday, the new-hash that is
calculated is different so the cache setting is ignored.
Digging deeper leads to me getting lost. The hash does depend on the
incorporation of
Ihor,
> > make of org mode? (remote possibility: emacs?)
>
> Org mode build process is not standard. Org mode needs to create
> autoload file and generate documentation in addition to normal
> byte-compilation.
thanks. does that mean running "make" in the org directory?
cheers, Greg
Greg Minshall writes:
> Ihor,
>
>> > make of org mode? (remote possibility: emacs?)
>>
>> Org mode build process is not standard. Org mode needs to create
>> autoload file and generate documentation in addition to normal
>> byte-compilation.
>
> thanks. does that mean running "make" in the
On Sat, Oct 23, 2021 at 9:41 AM Ihor Radchenko wrote:
>
> Carlos Pita writes:
>
> >>> But then c-a-p is very lenient since it lists lower and upper case block
> >>> variants even when I typed a lower case prefix, and upper case usually
> >>> will go first in the list, hence promoting a seemingly
On Saturday, 23 Oct 2021 at 11:13, Emmanuel Charpentier wrote:
> You may find this John Kitchin's blog
> post [...] illuminating.
Unfortunately not but thank you. It is a very useful blog post but
doesn't cover my case, where I use a :var header to refer to a
table. The table is static so I
Dear all,
the CSL style I use has footnotes. When a book is cited, it is once
cited with the full bibliographic information, and later footnotes then
reference the footnote in which this information first appeared,
shortening the later footnotes to the format "Author, (o. Fn. ),
...". (the
Carlos Pita writes:
>>> But then c-a-p is very lenient since it lists lower and upper case block
>>> variants even when I typed a lower case prefix, and upper case usually
>>> will go first in the list, hence promoting a seemingly bad practice.
>>
>> Could you clarify what is "c-a-p"?
>
> Yes, I
"Bruce D'Arcus" writes:
>> I just tried with clean Emacs:
>>
>> #+beg #+begin_ -> list of completions, all in lower
>> case
>> #+BEG #+BEGIN_ -> list of completions, all in upper
>> case
>
> Perhaps at some point the upper case should just be removed?
I am not sure if it is a good idea from
Hi,
The variable display-line-numbers-width is nil by default.
Regards,
--
Sébastien Miquel
From 2e306750caff0474aa9a6443c7d7eb68e3aca83b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Sat, 23 Oct 2021 13:28:59 +0200
Subject: [PATCH] org.el
Hello,
Vinicius Vinicius writes:
> While {{{title}}} concatenates multiple #+TITLE lines, {{{author}}} retrieves
> only the first one.
>
> MWE:
> #+TITLE: Foo
> #+TITLE: Foo2
>
> #+AUTHOR: First Author
> #+AUTHOR: Second Author
>
> {{{title}}} vs {{{author}}}
Fixed.
Thank you.
Hello,
Assuming such a question make sense, how do I manually reset org-persist
for all org buffers? It's not clear to me if doing M-x
org-element-cache-reset is sufficient.
Thanks.
Best wishes,
On 17 October 2021, Jeremie Juste wrote:
Many thanks for reporting your issue and many thanks to Greg for testing.
Sorry, I cannot reproduce the issue either. I don't think it is related
to async. Could you try with 'emacs -Q'?
Thanks to you both for testing this. It was a problem with my
Tim Cross writes:
Greg Minshall writes:
(and, after fifteen years of vi, and now 25 of emacs, i guess
i'll skip
the spacemacs experience. :)
Similar past for me as well. I used vi from early/mid 80x until
mid 90s
and then switched to Emacs and used standard Emacs bindings
until a
39 matches
Mail list logo
