Re: Please document the caching and its user options
>>>>> Ihor Radchenko writes: > Eli Zaretskii writes: >> Let me clarify. In the scenario in which I found out about Org >> caching, I didn't use latex-preview, not at all > Sure. Org uses multiple caches. You encountered the one created > by parser. The parser cache in particular can be disabled. But not > the latex preview cache. This what I cannot understand. If the user never uses latex preview why cannot the latex preview cache be disabled? I don't want to go on and on and become a bore - I've said my piece and I will be silent from now on. Best wishes, Colin Baxter.
Re: Please document the caching and its user options
>>>>> Ihor Radchenko writes: > Eli Zaretskii writes: >>> Can we instead store them in memory? Yes, but (1) it will make >>> Emacs RAM consumption grow constantly and more and more previews >>> are generated; (2) it will require significant changes in the >>> Org mode codebase. >> >> I understand all that, but if the user wants it, and insist on >> not caching any data, let them have what they want. > It is not about letting or not letting them. I would have to > implement it. (I am ok with it, but I am not going to prioritize > my time for nice-to-haves; though I would not mind patches > submitted by interested users). >> ... My surprise was caused by your "it is impossible"; I now >> understand that you meant "not reasonable" or perhaps "users will >> not like that" instead. > I meant: > 1. not reasonable in a sense that it has downsides compared to > what we do now - save latex previews on disk 2. impossible in a > sense that we do not have an existing toggle to store cached > previews in memory. Such functionality would have to be added; and > it is not necessarily trivial to add it. I too was one of those complainers who wanted to be able to disable org-persist completely. The argument about latex preview is really a non-starter in my opinion. I never use latex-preview and I'm sure I'm not alone in this. I also would not class the disabling of org-persist to be a 'nice-to-have'. Best wishes, Colin Baxter.
Re: org-table-row face
Dear Eric, >>>>> Fraga, Eric writes: ,> On Monday, 13 May 2024 at 21:16, Colin Baxter wrote: >> Thanks, so presumably I just use set-face-attribute. ,> For many/most face aspects, I find the customize interface the ,> easiest to use. Simply ,> M-x customize-face RET org-table-row RET I don't use customize-faces at all. I've now set it in my theme file. Thanks. Colin.
Re: org-table-row face
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> I read in ORG-NEWS
>>
>> --8<---cut here---start->8---
>> Now, new ~org-table-row~ face is used on the whole table row
>> lines, including indentation and the final newline. This face, by
>> default, inherits from ~org-table~ face.
>>
>> If the new behavior is not desired, ~org-table-row~ face can be
>> changed to inherit from ~default~ face. --8<---cut
>> here---end--->8---
>>
>> It most certainly is not desired, at least not by me. However, I
>> find the remedy opaque: "org-table-row face can be changed from
>> inherit from default face". What do I actually have to do to
>> achieve this?
> Set 'inherit property of the face. For example, see 51.1.5
> Customizing Faces.
Thanks, so presumably I just use set-face-attribute.
> Would it help if I add a link to that manual page from ORG-NEWS?
Yes, thanks again.
Colin.
org-table-row face
I read in ORG-NEWS --8<---cut here---start->8--- Now, new ~org-table-row~ face is used on the whole table row lines, including indentation and the final newline. This face, by default, inherits from ~org-table~ face. If the new behavior is not desired, ~org-table-row~ face can be changed to inherit from ~default~ face. --8<---cut here---end--->8--- It most certainly is not desired, at least not by me. However, I find the remedy opaque: "org-table-row face can be changed from inherit from default face". What do I actually have to do to achieve this? Thanks.
Re: How do I get rid of this icon
>>>>> Colin Baxter writes: > How do I change this icon (or whatever it's called) :email: to the > word email between colons. > Best wishes, Solved!
How do I get rid of this icon
How do I change this icon (or whatever it's called) :email: to the word email between colons. Best wishes,
Re: Footnotes on line and not raised
Dear Christian and Juan, Thank you very much for your contributions. These are great and exactly what I want. I'll probably go with an export filter. Thank you Best Wishes, Colin Baxter.
Re: Footnotes on line and not raised
Perhaps it's not possible because I see that .footref in css support is always .
Footnotes on line and not raised
I use footnotes as [fn:1], etc. in an org-mode file which I then export to html. In the output, I see the footnotes raised slightly above the line. I do not want this. Instead, I would like the footnotes to be on the line. Is this possible? I have read the doc strings associated with the variables `org-footnote-define-inline' and `org-footnote-auto-adjust', but, frankly, I am none the wiser. Best Wishes, Colin Baxter.
Re: Disable time messages from org-persist
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> Ho do I disable messages from org-persist telling me how long it
>> took to write to gc-lock.eld? For example,
>>
>> --8<---cut here---start->8---
>> org-persist: Writing to "~/path/to/org-persist/gc-lock.eld" took
>> 3.08 sec --8<---cut
>> here---end--->8---
>>
>> I find them a distraction and the information is of no use to me.
> You can set `org-persist--report-time' to nil.
Thank you.
Disable time messages from org-persist
Ho do I disable messages from org-persist telling me how long it took to write to gc-lock.eld? For example, --8<---cut here---start->8--- org-persist: Writing to "~/path/to/org-persist/gc-lock.eld" took 3.08 sec --8<---cut here---end--->8--- I find them a distraction and the information is of no use to me. Colin Baxter.
Re: [BUG] Footnotes in section titles
> Juan Manuel Macías writes:
> Max Nikulin writes:
>> I recall some tricks with \footnotemark and \footnotetext, but I
>> do not remember details and whether it may work for section
>> titles. Complications may arise if a heading title has several
>> footnotes.
> ox-latex has 'org-latex--delayed-footnotes-definitions': "[...]
> This function is used within constructs that don't support
> \footnote{} command (e.g., an item tag). In that case,
> \footnotemark is used within the construct and the function just
> outside of it."
> The \footnotetext/\footnotemark option works well for specific
> cases, but in general I don't like to abuse this method.
>> Perhaps it is better to avoid footnotes in titles and to add some
>> phrase to the body instead.
> That is the ideal scenario. I also believe that footnotes should
> be avoided in section headings, if possible. Or at least, have
> another type of numbering (symbols, letters...). The manyfoot and
> bigfoot packages allow constructions of this type, with various
> footnote apparatus.
Indeed, but many journals *require* footnotes in titles, especially for
affiliation, email, etc.
Re: org-persist - not wanted.
>>>>> Colin Baxter writes: > I find a file called "gc-lock.eld" has been deposited un-requested > and un-wanted in ~/.emacs.d/org-persist. > I had thought I had disabled org-persist with the following > (setq org-persist-disable-when-emacs-Q t) (defun > me/advice--org-persist (old-fn args) (let (user-init-file) > (apply old-fn args))) (advice-add 'org-persist-write :around > #'me/advice--org-persist) (advice-add 'org-persist-read :around > #'me/advice--org-persist) (advice-add 'org-persist-gc :around > #'me/advice--org-persist) > This had worked fine until today. How do I now stop org-persist > depositing this - and maybe other -files. I do not want them. > I am using emacs-30.0.50 and Org mode version 9.7-pre > (release_9.6.13-998-g571186). Ignore my rant. I cannot reproduce this so it looks to be spurious.
org-persist - not wanted.
I find a file called "gc-lock.eld" has been deposited un-requested and un-wanted in ~/.emacs.d/org-persist. I had thought I had disabled org-persist with the following --8<---cut here---start->8--- (setq org-persist-disable-when-emacs-Q t) (defun me/advice--org-persist (old-fn args) (let (user-init-file) (apply old-fn args))) (advice-add 'org-persist-write :around #'me/advice--org-persist) (advice-add 'org-persist-read :around #'me/advice--org-persist) (advice-add 'org-persist-gc :around #'me/advice--org-persist) --8<---cut here---end--->8--- This had worked fine until today. How do I now stop org-persist depositing this - and maybe other -files. I do not want them. I am using emacs-30.0.50 and Org mode version 9.7-pre (release_9.6.13-998-g571186). Best wishes, Colin Baxter.
Re: worg - out of date item
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> https://orgmode.org/worg/org-tutorials/org-google-sync.html
>> suggests using the command line program 'googlecl'. That program
>> appears to have been dead for several years, at least according
>> to https://code.google.com/archive/p/googlecl/.
> Would you be interested to create a patch that removes the part of
> the tutorial dealing with gogglecl?
Ok. However, it will probably be a week or two before I have the time.
Colin Baxter.
worg - out of date item
https://orgmode.org/worg/org-tutorials/org-google-sync.html suggests using the command line program 'googlecl'. That program appears to have been dead for several years, at least according to https://code.google.com/archive/p/googlecl/. Colin Baxter.
Re: [ANM] org-timeblock: Schedule your day visually, using timeblocking technique inside Emacs
> Ilya Chernyshov writes: > Ihor Radchenko writes: >> Thanks for sharing! >> >> As I mentioned in Matrix chat, it would be nice if you could >> integrate the svg image display into Org agenda as minor mode, >> displaying the interactive svg in place of the time grid. That >> would be a welcome addition to Org core. > It's a great idea. Not for emacs -nw.
Re: org-fontify-emphasized-text
>>>>> Henrik Frisk writes: > On Mon, Jul 17, 2023, 1:23 PM Ihor Radchenko wrote: >> Henrik Frisk writes: >> >>> For the first time I tried to enable the fontification of >>> emphasized text but quickly decided I didn't want it. But I >>> can't seem to get rid of it. For example, any part of a >>> filename that is after an underscore is still printed as subtext >>> (expected if fontification is on). Is there anything else than >>> the above variable that controls this? emacs -Q works of course >>> fine. >> >> Can't get rid even after re-starting Emacs? >> > Exactly, I've had it for weeks annoyingly. Indeed, it is VERY annoying. Setting (setq org-use-sub-superscripts nil) (the default is t) seems to ensure that it does not come on even if some library puts `org-pretty-entities' to t. Best wishes, Colin Baxter.
Re: Cache must be active error
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> 1. emacs -q 2. eval in scratch buffer (add-to-list
>> 'load-path (expand-file-name "~/path/to/git/org-mode/lisp"))
>> 3. M-x org-agenda 4. Enter m 5. "Cache must be active" now
>> appears in echo area
>>
>> Am I seeing a new git/org-mode feature or a bug?
> A can reproduce. Fixed, on main.
Confirmed. Thank you very much for this.
Colin Baxter.
Re: Cache must be active error
>>>>> Max Nikulin writes: > On 03/07/2023 14:03, Colin Baxter wrote: >> 2. If I remove all the org files from my emacs-30.50.0 and >> thereby force emacs to use only org-mode from git then I see the >> error. > Have you tried to recompile Org from git or to load it uncompiled? > Concerning mixed-version loading. M-x org-version when read with > attention may contain a hint. Other tools are > `list-load-path-shadows' and > (ignore (pp (mapcar (lambda (x) (list (car x))) load-history))) > and search for "org" I now a recipe: Either with emacs-28.2 or emacs-30.0.50 do: 1. emacs -q 2. M-x org-agenda 3. Enter m 4. "Match:" appears in echo area However: 1. emacs -q 2. eval in scratch buffer (add-to-list 'load-path (expand-file-name "~/path/to/git/org-mode/lisp")) 3. M-x org-agenda 4. Enter m 5. "Cache must be active" now appears in echo area Am I seeing a new git/org-mode feature or a bug? The lisp files in git/org-mode/lisp were not byte-compiled. Colin Baxter.
Re: Cache must be active error
>>>>> Max Nikulin writes: > On 03/07/2023 00:44, Colin Baxter wrote: >>>>>>> Ihor Radchenko writes: >> > Just for context, the new version `org-element-cache-map' uses >> a > new macro `org-element-with-enabled-cache' that temporarily > >> enabled cache for the duration of `org-element-cache-map'. >> I add org-mode (from git) early to the load-path in order to >> compile new org-mode versions on the fly without closes emacs. > You may try to add > (message "org? %S" (featurep 'org)) Thanks for this tip. It reports `nil'. > before the line adding Org to load path. Check the *Messages* > buffer that it reports "nil" to ensure that Org is not loaded > through some dependencies. > When pulled commits includes changes related to macros, .elc files > affected by macro expansions must be removed before > compilation. *Incremental* builds may result in inconsistent > code. Emacs developers prefer fast, but sometimes incorrect builds > and they are rather skeptical in relation to proper support of > incremental builds. > Without removing *.elc files functions like > `byte-recompile-directory' and `batch-byte-compile' may produce > files that uses old macro versions. I've tried removing the .elc files but that doesn't seem to be the issue. 1. Forcing emacs (emacs-30.50.0) to use only its built-in org-mode then I see no error 2. If I remove all the org files from my emacs-30.50.0 and thereby force emacs to use only org-mode from git then I see the error. 3. I suspect some other org-mode library I use is causing the problem. So far, I've not found the culprit, even though it is only "m" - search for TAGS/PROPS/KEYWORDS - that gives the error. Thank you for your help. Colin Baxter.
Re: Cache must be active error
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> > This should not matter and should not cause the error. Please
>> > provide more details.
>>
>> The debugger output on the error is:
>>
>> --8<---cut here---start->8---
>> Debugger entered--Lisp error: (error "Cache must be active.")
>> (signal error ("Cache must be active.")) (error "Cache must be
>> active.") (org-element-cache-map #f(compiled-function (el)
>> #))
> Just for context, the new version `org-element-cache-map' uses a
> new macro `org-element-with-enabled-cache' that temporarily
> enabled cache for the duration of `org-element-cache-map'.
>> There is an odd feature. If I reload org-mode on a org buffer,
>> using "C- C-x !" then the error vanishes on using "C-c C-a m". If
>> I launch a new emacs (28.2 or 30.50.0) then the error returns and
>> only vanishes if I reload org-mode again.
> This sounds like you got mixed Org installation or org-element.el
> from built-in Org. If it is the case, you may need to check your
> config.
> You can also try WIP branch feature/shadowcheck that tries more to
> fight mixed version issue:
> https://git.sr.ht/~yantar92/org-mode/tree/feature/shadowcheck
> -- Ihor Radchenko // yantar92, Org mode contributor, Learn more
> about Org mode at <https://orgmode.org/>. Support Org development
> at <https://liberapay.com/org-mode>, or support my work at
> <https://liberapay.com/yantar92>
I add org-mode (from git) early to the load-path in order to compile new
org-mode versions on the fly without closes emacs.
I'll first experiment by moving
--8<---cut here---start----->8---
(add-to-list 'load-path (expand-file-name "/path/to/git/org-mode/lisp"))
--8<---cut here---end--->8---
to different points in my ~/.emacs to see if that solves the issue.
Colin Baxter.
Re: Cache must be active error
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> I now find that when I enter `m' to match an agenda
>> TAG/PROP/TODO, I get an error telling me that the "cache must be
>> active". This error is new today and I assume the result of
>> commit 948c89644.
>>
>> I have
>>
>> (setq org-element-use-cache nil) (setq
>> org-element-cache-persistent nil)
> This should not matter and should not cause the error. Please
> provide more details.
The debugger output on the error is:
--8<---cut here---start->8---
Debugger entered--Lisp error: (error "Cache must be active.")
(signal error ("Cache must be active."))
(error "Cache must be active.")
(org-element-cache-map #f(compiled-function (el) #))
(org-get-buffer-tags)
(org-make-tags-matcher nil)
(org-tags-view nil)
(funcall-interactively org-tags-view nil)
(call-interactively org-tags-view)
(org-agenda nil)
(funcall-interactively org-agenda nil)
(call-interactively org-agenda nil nil)
(command-execute org-agenda)
--8<---cut here---end--->8---
There is an odd feature. If I reload org-mode on a org buffer,
using "C- C-x !" then the error vanishes on using "C-c C-a m". If I
launch a new emacs (28.2 or 30.50.0) then the error returns and only
vanishes if I reload org-mode again.
Colin Baxter.
Cache must be active error
I now find that when I enter `m' to match an agenda TAG/PROP/TODO, I get an error telling me that the "cache must be active". This error is new today and I assume the result of commit 948c89644. I have (setq org-element-use-cache nil) (setq org-element-cache-persistent nil) Is there a solution for those of us who do not wish to use org cache (and org-persist)? Colin Baxter.
Re: [POLL] Will it be ok to allow HABIT property inheritance? (optionally)
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> > No objections have been raised.
>>
>> Well, you have not really given much time to respond.
> 2 weeks. I could have waited one month, but this is relatively
> safe breaking change.
>> Does this mean that all sub-heading with their TODOs will now
>> become habits? I would like much more information on the effects
>> of this proposal.
> Sorry if I was not clear in my original message.
> 1. STYLE will _not_ be inherited by default after the proposed
> change. 2. HABIT will be inherited if user customized
> `org-use-property-inheritance' to value of t (aka inherit all
> properties) 3. STYLE will be inherited if user explicitly added
> "STYLE" to `org-use-property-inheritance' when it is a list.
> Only (2) can be breaking.
Ok, that's good.
>> We have had `habits' for zillions of years which have worked
>> well. So why the change?
> To be able to dedicate a separate subtree or file to habits,
> automatically making all the sub-tasks habits without spamming
> property drawers setting :STYLE: habit.
Thank you very much. I understand.
Re: [POLL] Will it be ok to allow HABIT property inheritance? (optionally)
> Ihor Radchenko writes: > Ihor Radchenko writes: >> I am generally in favour of allowing STYLE to be inherited, but >> it is technically a breaking change, as I described. >> >> Let's see if anyone voices against this change. > No objections have been raised. Well, you have not really given much time to respond. Does this mean that all sub-heading with their TODOs will now become habits? I would like much more information on the effects of this proposal. We have had `habits' for zillions of years which have worked well. So why the change?
Re: Why am I being told to use "straight.el"?
>>>>> Max Nikulin writes:
> On 22/04/2023 14:51, Colin Baxter wrote:
>>>>>>> Max Nikulin writes:
>> > On 21/04/2023 23:17, Colin Baxter wrote:
>> > emacs -Q -l org-agenda Only message and scratch buffers
>> present.
> C-h e to check messages, but since errors or warnings buffer does
> not appear it should be OK.
>> >> 1. emacs > Till `org-reload' C-c C-x ! at the step 10
>> org is not > involved. Does you init file loads some Org
>> component or some Org > buffer is created at startup? To be sure
>> > M-: (featurep 'org) "No match."
> I would expect either nil or t. Did you press M-x that is
> `execute-extended-command' instead of M-: that is
> `eval-expression'? Alternatively you may execute in in the
> *scratch* buffer
> (featurep 'org)
> and C-j or C-x C-e when cursor is immediately after the closing
> parenthesis.
Sorry, my mistake. I didn't follow your recipe exactly. If enter
(featurep 'org) in the scratch buffer and do C-j then I get nil.
>> >> 2. M-x vc-dir 3. Navigate to ~/git/org-mode. 4. + (to
>> >> pull) 5. M-x compile 6. make clean 7. make
>> In the case of build org-mode, I first select "make clean" from
>> the history of "M-x compile". Then I do "M-x compile" again and
>> select "make" from the history. The effect is the same using the
>> terminal, except the outputs are now contained in emacs buffers.
> Thank you for explanation. For some reason I believed that M-x
> compile invokes make without additional prompt. So
> make clean; make
> sounds perfectly reasonable.
>> >> 8. In an eshell buffer navigate to ~/git/emacs/lisp. >> Typo!
>> I meant navigate to ~/git/org-mode/lisp. >> 9. rm *.elc >
>> Why did you decided to manually delete *.elc files? I have lost
>> at > which step you got the warning. I expect that "make clean"
>> should > remove .elc files. If I don't delete the elc files in
>> ~/git/org-mode/lisp after the first build then I do get errors.
> Do you mean that it happens on each update?
Yes. However, there was a time several months ago when I needed only
build org-mode once to update it successfully. Something then changed in
org-mode such that initially updated .elc files caused an error. I
subsequently discovered that if a went through the build process twice,
removing the .elc files after the first build, they would be accepted at
the second build.
> No .elc files should
> survive "make clean". I have not tried to reproduce it accordingly
> to your steps, but I have seen something strange related to .el
> and .elc files while experimenting with package.el.
> https://orgmode.org/worg/dev/org-build-system.html#orgd21575b
> "Compatibility and Convenience" and
>
https://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development
> suggests that
> make uncompiled
> may be a shorter path to the same point.
> However accordingly to your description I expect that you do not
> have Org loaded yet. If you can not load compiled org now it
> should cause an error after emacs restart as well.
Org-mode is already loaded, that is the git version of org that I am about to
update is already loaded. If I C-j
--8<---cut here---start->8---
(car (assoc "/org-loaddefs.el" load-history (lambda (a b)
(string-match-p b a
--8<---cut here---end--->8---
in a scratch buffer then I get "~/git/org-mode/lisp/org-loaddefs.el". I
update org-mode during a normal emacs session that may have run over
one or two days, during which time I will have used org-agenda, clocked
in and out of various times and perhaps used org-export.
Best wishes,
Colin.
Re: Why am I being told to use "straight.el"?
>>>>> Max Nikulin writes:
> On 21/04/2023 23:17, Colin Baxter wrote:
>> I will address the other points in your reply the next time I
>> update org-mode. In the meantime, I can answer some of your other
>> questions immediately.
> Thanks for info. I have asked for org git branch. I am almost sure
> it is main, but to be sure
>git -C ~/git/org-mode branch --show-current git -C
> ~/git/org-mode describe
main
> If the issue was caused by specific order of file changes, even in
> the current state output of the following command may be used for
> attempt to replay updates by git checkout + make
>git -C ~/git/org-mode reflog --max-count 20
f81ba451a (HEAD -> main, origin/main, origin/HEAD) HEAD@{0}: pull --stat:
Fast-forward
3c449cc43 HEAD@{1}: pull: Fast-forward
4929f0c55 HEAD@{2}: pull: Fast-forward
f4446ce79 HEAD@{3}: pull: Fast-forward
7c8623be9 HEAD@{4}: clone: from
https://git.savannah.gnu.org/git/emacs/org-mode.git
> I assume you build it yourself. Do you run emacs binary from
> source+build tree or from install tree (make install)?
>From a local install-tree.
> The latter
> has .el.gz files instead of .el, and at least in Emacs-28 it
> affects behavior of compilation of ELPA packages by package.el.
> Another point is that the origin of your issue might be in
> built-in version of Org. It has `org-assert-version' as
> well. Perhaps there is a bug in make rules for Org in Emacs
> tree. Could you, please, try the following for your *current*
> emacs build?
> emacs -Q -l org-agenda
Only message and scratch buffers present.
>> 1. emacs
> Till `org-reload' C-c C-x ! at the step 10 org is not
> involved. Does you init file loads some Org component or some Org
> buffer is created at startup? To be sure
> M-: (featurep 'org)
"No match."
This figures since loading org-mode is only the second load-path
adjustment done by my ~/.emacs. The first is setting the path to
slime. All other load-path adjustments, such as other org-mode
application libraries come later after org-mode itself.
> I assume that ~/git/org-mode/lisp is added to `load-path' in your
> init file.
Yes, via (add-to-list 'load-path (expand-file-name "~/git/org-mode/lisp"))
>> 2. M-x vc-dir 3. Navigate to ~/git/org-mode. 4. + (to
>> pull) 5. M-x compile 6. make clean 7. make
> I am sorry for my ignorance, I usually run make from a terminal
> independent of emacs. Doesn't M-x compile runs make, so I expect
> it is the same as
In the case of build org-mode, I first select "make clean" from the
history of "M-x compile". Then I do "M-x compile" again and select "make"
from the history. The effect is the same using the terminal, except the
outputs are now contained in emacs buffers.
> make; make clean; make
> and it is a bit strange for me.
>> 8. In an eshell buffer navigate to ~/git/emacs/lisp.
>> Typo! I meant navigate to ~/git/org-mode/lisp.
>> 9. rm *.elc
> Why did you decided to manually delete *.elc files? I have lost at
> which step you got the warning. I expect that "make clean" should
> remove .elc files.
If I don't delete the elc files in ~/git/org-mode/lisp after the first
build then I do get errors. I find that a running emacs-session at this
stage of the process is happy to load new org-mode .el files but not
.elc files. I then repeat "make clean" and "make". Now the running emacs
will load the .elc files and complete the update.
>> 10. Open any org-mode file or buffer and do C-c C-x !
> `org-reload' immediately after removing of .elc files sounds
> strange for me. At least since previous command was "make", not
> "make clean", org-loaddefs.el should exist at this moment, so
> uncompiled version should be loaded, but prefix argument should be
> used to load Org uncompiled
> C-u C-c C-x !
> If org has not been loaded before the step 10, then `org-reload'
> should-not be necessary at all.
>> 11. Return to vc-dir or eshell 12. make clean 13. make
>> 15. Return to org-mode buffer and do C-c C-x ! again.
>> 16. Update complete, usually with no warnings or errors.
> Is org-loaddefs loaded from ~/git/org-mode/lisp? It is a sanity
> check for working Org and more interesting when it is broken.
I think it must be because ~/git/org-mode/ is the first org-mode found
and not the org-mode within emacs itself. How can I check?
> emacs -Q -L ~/git/org-mode/lisp -l org-agenda
> is not affected, so the problem is solely with reloading of
> updated version without emacs restart.
Ok. I will do that.
Colin.
Re: Why am I being told to use "straight.el"?
1. emacs 2. M-x vc-dir 3. Navigate to ~/git/org-mode. 4. + (to pull) 5. M-x compile 6. make clean 7. make 8. In an eshell buffer navigate to ~/git/emacs/lisp. Typo! I meant navigate to ~/git/org-mode/lisp. Sorry about that.
Re: Why am I being told to use "straight.el"?
>>>>> Max Nikulin writes: > On 21/04/2023 20:25, Colin Baxter wrote: >>>>>>> Max Nikulin writes: I will address the other points in your reply the next time I update org-mode. In the meantime, I can answer some of your other questions immediately. > Please, specify Emacs version. GNU Emacs 30.0.50 (build 1, i686-pc-linux-gnu, X toolkit, cairo version 1.14.8, Xaw3d scroll bars) of 2023-04-19. My system is Linux 4.9.0-19-686-pae #1 SMP Debian 4.9.320-2 (2022-06-30) i686 GNU/Linux. >> > Did you get this warning when you restarted emacs? No. > Then I am completely confused what happened. Org compiled by make > should not be affected by the mixed compile issue, especially > after "make clean". How do you load updated version without > restarting of Emacs? Do you use `org-reload'? Please, try to > specify all you steps from "git pull" to first time when you got > the warning. 1. emacs 2. M-x vc-dir 3. Navigate to ~/git/org-mode. 4. + (to pull) 5. M-x compile 6. make clean 7. make 8. In an eshell buffer navigate to ~/git/emacs/lisp. 9. rm *.elc 10. Open any org-mode file or buffer and do C-c C-x ! 11. Return to vc-dir or eshell 12. make clean 13. make 15. Return to org-mode buffer and do C-c C-x ! again. 16. Update complete, usually with no warnings or errors. Colin.
Re: Why am I being told to use "straight.el"?
>>>>> Max Nikulin writes: > On 21/04/2023 16:42, Colin Baxter wrote: >> After an initial 'pull', 'make clean' and 'make', > ... >> However, I did initially receive the following warning: >> --8<---cut here---start->8--- >> It is recommended to put (straight-use-package 'org) early in the >> config. Ideally, right after the straight.el >> --8<---cut here---end--->8--- > You got this warning because it is assumed that straight.el users > are mostly affected by the mixed compile/mixed load issue. I have never used straight, and I update my org-mode every couple of days. Today was the first time I received the warning. > https://orgmode.org/worg/org-faq.html#mixed-install > Did you get this warning when you restarted emacs? No. > Next time please, save result of "ls -ltr lisp/". It sounds like > some issue with dependencies in makefiles. Perhaps something was > wrong with org-version.el, org-macs.el, org-loaddefs.el and .elc > files. Ok, will do. > Another way to get mixed versions issue is to put some require, > e.g. > (require 'org-protocol) There is no org-protocol anywhere in my ~/.emacs. Colin.
Why am I being told to use "straight.el"?
I load org-mode directly from my local copy of the org-mode git repository and update on the fly. It works well, until today. After an initial 'pull', 'make clean' and 'make', I 'cd' to lisp and 'rm *.elc'. I then updated from an org-mode buffer, successfully. I 'make clean' again followed by 'make'. I then did a further update from an org-mode buffer. The second update was successfully loaded, and subsequent launches of emacs cause no errors. However, I did initially receive the following warning: --8<---cut here---start->8--- It is recommended to put (straight-use-package 'org) early in the config. Ideally, right after the straight.el bootstrap. Moving `use-package' :straight declaration may not be sufficient if the corresponding `use-package' statement is deferring the loading. --8<---cut here---end--->8--- I do not use "packages" nor "straight", so why the recommendation? My method works perfectly well. As well as the above warning, the debugger clicked in with an "Org version mismatch" error. The path to org-mode is already loaded early (very early) in my ~/.emacs. After the update, I received no further warnings or errors from emacs, from both the active and subsequent sessions. In my opinion, all the update warnings were essentially wrong and unnecessary. So why are they there? Colin.
Re: I want minus-key to give me `-' only
>>>>> Colin Baxter writes: > In an org-mode buffer, I notice a depression of the minus-key `-' > now also gives an under-bar. I find this very annoying. I never > insert the subsequent letter `—️' whatever it's called, and I do > not want it. How do I remove this "feature" such that a depression > of the minus-key will give me immediately the minus character `-'? > Colin Baxter. Forget this request. Idiot me had set the input method to TeX and forgotten about it!
I want minus-key to give me `-' only
In an org-mode buffer, I notice a depression of the minus-key `-' now also gives an under-bar. I find this very annoying. I never insert the subsequent letter `—' whatever it's called, and I do not want it. How do I remove this "feature" such that a depression of the minus-key will give me immediately the minus character `-'? Colin Baxter.
Re: How to disable completely org-persist
> Angelo Graziosi writes: > tomas wrote: >> there is now a defvar `org-element-cache-persistent' > Ah! didn't knew that.. > Setting > (setq org-element-cache-persistent nil) > seems to work.. Indeed, although I'm not yet convinced that org-persist directories wont eventually start showing up in /tmp! Best wishes,
Re: Keys to Category Filter Agenda
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> Indeed. I understand that, but the question was about '>' not
>> '<'. The initial agenda buffer has
>>
>> < Buffer, subtree/region restriction > Remove restriction
>>
>> If I remove the restriction with >, as suggested by the initial
>> buffer, I get the date prompt. I have to enter either '<' again
>> or '|' to clear the restrictions. This information is given only
>> in org-mode info not in the initial agenda buffer.
> Initial prompt buffer only describes bindings for that buffer.
> They are totally different from agenda-mode buffer.
That is not correct for the '<' key. You are told "Restriction is only
possible in Org buffers". In my opinion the distinction of the '<' key
should be more positively indicated. The wording and arrangement of the
prompt buffer is confusing at best. It is disheartening when the
difficulties experienced by a non-specialist seem to be dismissed
out-of-hand.
Best wishes,
Re: Keys to Category Filter Agenda
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> In agenda, you can filter by category by pressing '<' when point
>> on that particular category. To remove filtering, press '<'
>> again. All this is explained in the org-mode info. However the
>> initial agenda buffer, viewed by 'C-c a', gives the keys '<' for
>> filtering but '>' to remove the restriction. This surely is wrong
>> since '>' is the key to call the org-agenda-date-prompt, or am I
>> missing something very basic here?
> You are misunderstanding agenda buffer and the initial agenda
> dialog. The former is where "<" acts as category filter. The
> dialog uses "<" to set agenda restriction, as it is explained in
> the dialog message.
Indeed. I understand that, but the question was about '>' not '<'. The
initial agenda buffer has
< Buffer, subtree/region restriction
> Remove restriction
If I remove the restriction with >, as suggested by the initial buffer,
I get the date prompt. I have to enter either '<' again or '|' to clear
the restrictions. This information is given only in org-mode info not in
the initial agenda buffer.
Best wishes,
Keys to Category Filter Agenda
In agenda, you can filter by category by pressing '<' when point on that particular category. To remove filtering, press '<' again. All this is explained in the org-mode info. However the initial agenda buffer, viewed by 'C-c a', gives the keys '<' for filtering but '>' to remove the restriction. This surely is wrong since '>' is the key to call the org-agenda-date-prompt, or am I missing something very basic here? Nest wishes, Colin Baxter.
Re: How to disable completely org-persist
>>>>> Angelo Graziosi writes:
> Colin Baxter wrote:
>> I too would like a means to disable org-persist.
> On emacs-devel there was this suggestion:
> https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00125.html
It appears to work, after removing a couple of surplus brackets from the
end of the last line.
Best wishes,
Re: How to disable completely org-persist
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> I too would like a means to disable org-persist. I don't doubt it
>> may be useful for those users with "large" org files with
>> multiply src-blocks, etc., etc., but, for me, I have not found
>> any improvement in performance. As remarked by the OP, the
>> feature should not be default-enabled.
> Note that org-persist is not only used to cache parser data for
> large files. For example, exported online images are also cached
> instead of being downloaded on every export. Other things may also
> be cached in future.
> Normally, org-persist stores the data in $XDG_CACHE_HOME. It only
> falls back to .emacs.d when cache directory does not exist. One
> can also customize the value manually.
> That being said, it should not be a big deal to allow disabling
> org-persist when desired. In fact, org-persist is already
> auto-disabled when using emacs -Q. I can add a user switch on top.
When you have time, of course, a disabling switch would be most useful -
in my opinion.
Best wishes,
Re: How to disable completely org-persist
>>>>>writes: > On Sat, Dec 03, 2022 at 01:19:47AM +0100, Angelo Graziosi wrote: >> I have already posted this to emacs-devel people (see >> https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00045.html). >> >> After a recent Emacs build from master I find `org-persist` >> directory in my `.emacs.d` folder. It brings no benefit but only >> garbage in `.emacs.d`. So how can I disable the creation of that >> folder? > Now, now... "garbage" seems unnecessarily loaded, But... >> You should not enable this by default and let people that finds >> it really useful to enable it in its own init.el. > ...I won't quibble about the default, but I'd like to have a way > to disable it, too. I too would like a means to disable org-persist. I don't doubt it may be useful for those users with "large" org files with multiply src-blocks, etc., etc., but, for me, I have not found any improvement in performance. As remarked by the OP, the feature should not be default-enabled. Best wishes, Colin Baxter.
Re: 9.6 version has 9.4 Info manual?
Dear Alain, > Alain Cochard writes: > With the 9.5.5 version > Org mode version 9.5.5 (9.5.5-g8ef620 @ > /home/cochard/.emacs.d/elpa/org-9.5.5/) > What I have in Info is > The Org Manual ** > This manual is for Org version 9.5. >Copyright ©️ 2004–2022 Free Software Foundation, Inc. > But if > Org mode version 9.6 (release_9.6-6-gd500b4 @ > /home/cochard/Org/Coch-git/org-mode/lisp/) > then > The Org Manual ** > This manual is for Org version 9.4. >Copyright ©️ 2004–2021 Free Software Foundation, Inc. You might have an INFOPATH conflict. For Org mode version 9.6 (release_9.6-6-gd500b4 @/path/to/git/org-mode/lisp/), I get the info manual to begin as: The Org Manual ** This manual is for Org version 9.6. Copyright © 2004–2022 Free Software Foundation, Inc. Best wishes,
Re: R code blocks in org version 9.5
> Naresh Gurbuxani writes: > It seems that org 9.5 has simplified header arguments for R code > blocks that use grid graphics. > Org 9.4 requires :results output graphics file > Org 9.5 requires :results output file > Do other users find the same change? > Sent from my iPhone >> On Oct 19, 2022, at 8:59 AM, Naresh Gurbuxani >> wrote: >> >> Thanks to your suggestion, I was able to narrow down the problem. >> >> My R code blocks work fine in org 9.5. When I plot graph using >> base graphics in session, it works fine. The problem is with >> lattice graphs. With below header variables, code block works >> fine. >> >> #+begin_src R :session *R* :results graphics file :file test.png >> library(lattice) print(histogram(rnorm(1))) #+end_src >> >> But this does not work. Emacs hangs. >> >> #+begin_src R :session *R* :results output graphics file :file >> test.png library(lattice) histogram(rnorm(1)) #+end_src >> >> I can simply add print command to my code blocks. Is there an >> easier solution? I'm afraid both your above examples work for me. I'm on emacs-29.0.50 and org-mode version 9.6-pre (release_9.5.5-995-g4b9aef) Best wishes
Re: [PATCH] Org Habit fix + new feature
>>>>> Morgan Smith writes: > Hello, > Colin Baxter writes: >> Please do not alter the default behaviour. When writing a paper >> or a book I use and need both logging and state changes, and I >> would prefer not to have to spend time changing my setup. > Don't worry, this shouldn't change the default behavior in the > slightest. > Morgan Thank you.
Re: [PATCH] Org Habit fix + new feature
> Morgan Smith writes: > Hello! There are two patches here. The first one is a simple bug > fix that doesn't really have anything to do with the second patch. > It just happens to be in the same spot of the code. > The second patch allows a habit to be considered done if time was > logged to it. Imagine you have an org habit like shaving. > Chances are, if you spend time doing it, it's done. I like to set > LOGGING to nil for these kinds of habits since it's redundant to > have all those state changes that tell me exactly what the logbook > already tells me. Please do not alter the default behaviour. When writing a paper or a book I use and need both logging and state changes, and I would prefer not to have to spend time changing my setup.
Re: refresh not working for org-mode from git
The solution is to use `make autoloads'. I suppose that should have been obvious to me at the beginning. After git pull (`+' in vc-dir) the working recipe is: 1. rm *.elc 2. Update in org-mode buffer using C-c C-x ! 3. make clean 4. make autoloads 5. Check update org-mode via C-c C-x! 6. make 7. Check update org-mode again via C-c C-x! Some of these steps might not be necessary. I will experiment. Thank you all again for your help. Best wishes, Colin.
Re: refresh not working for org-mode from git
Dear Ithor,
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> Recently, if I use C-c C-x ! to refresh org-mode after a git
>> pull, I get an error. I then have to close down emacs and launch
>> again. This rather defeats the object of C-c C-x !. This appears
>> to have happened only recently
> Does it help if you run make after git pull?
I will certainly try that and miss out `make clean', at least in the
first round. As I said in the email to Tim, I will try various
combinations in the build process.
Thank you for your reply.
Best wishes,
Colin.
Re: refresh not working for org-mode from git
Thank you for your detailed reply.
>>>>> Tim Cross writes:
> Colin Baxter writes:
>> Recently, if I use C-c C-x ! to refresh org-mode after a git
>> pull, I get an error. I then have to close down emacs and launch
>> again. This rather defeats the object of C-c C-x !. This appears
>> to have happened only recently
- snip -
> I wasn't aware that command even existed. However, I suspect it
> will cause issues in your use case. I'm not sure it is a good
> command to actually have given the complexities associated with
> getting a clean org build.
> In many cases, you may not run into issues - especially if you do
> a git pull frequently. However, I can see various scenarios which
> will lead to inconsistent builds. I suspect the error you are
> seeing is the result of recent work to try and identify builds
> which are likely to result in an inconsistent 'mixed' version
> build.
That could well be the case here because the technique used to work up
until quite recently (~2 weeks)
> Detecting such scenarios is difficult and relies on a
> number of heuristics, one of which is to flag a problem if the
> loaded version and the target build version don't match.
> A lot would depend on how you build (re-compile) org mode after
> doing a git pull. If you compile it in a separate Emacs instance,
> you should have less issues and reloading after the build will
> likely work. However, if your trying to build org mode within the
> running Emacs where you have already loaded org mode, I suspect
> you will run into issues. You have a slight 'chicken and egg'
> issue and will run into similar issues as the common mixed build
> problems.
Normally, I use `M-x vc-dir' to update from git, then `M-x compile'
followed by `make clean' and `make'. Finally, update org-mode in the
same emacs with an org-mode buffer present. As I said, it used to work
well.
> One thing which might work would be to ensure you run the reload
> command with the option to load from uncompiled sources BEFORE you
> run the build process and then re-run the load command after the
> build (loading compiled versions this time).
Yes, I will try that. And I will also ring all the other changes to see
what happens --- if anything.
> I have no idea how things might break given the new native
> compilation modes in Emacs. I suspect it will cause all sorts of
> issue with your workflow.
I have avoided problems here by not using native compilation. I did try
it once in the past, but I didn't think it was worth the candle since
frankly I didn't notice any change in emacs performance, possibly
because I only do simple things with emacs.
> Personally, I always update org in a fresh instance of Emacs
> (before any org functionality is loaded) and I would always
> restart Emacs after updating a major packages like org mode. I'm
> not sure why we have the reload command - I suspect it may be a
> hang over from earlier attempts to work around the mixed build
> problem. I do suspect that given new native compilation modes and
> the additional complexity ths can cause, combined with increasing
> org mode complexity, the notion of being able to pull down a new
> version, build and reload it within one emacs instance is perhaps
> flawed or at the very least, is more complex than just forcing a
> reload of org *.elc files.
Indeed. Emacs seems to have became a rather complex beast in recent
years. Perhaps it was ever thus.
Best wishes,
Colin.
refresh not working for org-mode from git
Recently, if I use C-c C-x ! to refresh org-mode after a git pull, I get an
error. I then have to close down emacs and launch again. This rather
defeats the object of C-c C-x !. This appears to have happened only recently
The Backtrace is
--8<---cut here---start->8---
Debugger entered--Lisp error: (error "Org version mismatch. Make sure that
correct `loa...")
(signal error ("Org version mismatch. Make sure that correct `loa..."))
(error "Org version mismatch. Make sure that correct `loa...")
(byte-code "\300\301!\210\302
\303\232\204\23\0\304\305!\210\306\307!\210\300\301!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\210\300\314!\210\300\315!\210\300\316!..."
[require org-macs org-git-version "release_9.5.5-821-g9bd8a9" warn "Org
version mismatch. Make sure that correct `loa..." error "Org version mismatch.
Make sure that correct `loa..." org-compat org-keys ob-eval ob-core ob-comint
ob-exp ob-table ob-lob ob-ref ob-tangle provide ob] 2)
(load "/home/redknight/git/org-mode/lisp/ob" noerror nil nil mustsuffix)
(#f(compiled-function (f) #) "ob")
(mapcar #f(compiled-function (f) #) ("ob" "ob-C" "ob-R"
"ob-awk" "ob-calc" "ob-comint" "ob-core" "ob-ditaa" "ob-dot" "ob-emacs-lisp"
"ob-eshell" "ob-eval" "ob-exp" "ob-fortran" "ob-gnuplot" "ob-latex" "ob-lisp"
"ob-lob" "ob-org" "ob-perl" "ob-plantuml" "ob-python" "ob-ref" "ob-ruby"
"ob-shell" "ob-sql" "ob-sqlite" "ob-table" "ob-tangle" "obarray" "oc"
"oc-basic" "oclosure" "ol" "ol-bbdb" "ol-bibtex" "ol-docview" "ol-eshell"
"ol-eww" "ol-gnus" "ol-info" "ol-irc" "ol-mhe" "ol-rmail" "ol-w3m" "org-agenda"
"org-capture" "org-collector" "org-compat" "org-crypt" ...))
(org-reload nil)
(funcall-interactively org-reload nil)
(call-interactively org-reload)
(popup-menu (keymap "Global Menu" ... ... ... ... ... ... ... "menu-bar"
keymap "Org Mode Menu" ... keymap ...) f10)
(x-menu-bar-open nil)
(menu-bar-open nil 1)
(funcall-interactively menu-bar-open nil 1)
(call-interactively menu-bar-open nil nil)
(command-execute menu-bar-open)
--8<---cut here---end--->8---
I also receive a warning, copied below. I do not use 'packages' but use
org-mode from a git repository and have done so with no previous issues.
--8<---cut here---start->8---
⛔ Warning (emacs): Org version mismatch. Make sure that correct `load-path' is
set early in init.el
This warning usually appears when a built-in Org version is loaded
prior to the more recent Org version.
Version mismatch is commonly encountered in the following situations:
1. Emacs is loaded using literate Org config and more recent Org
version is loaded inside the file loaded by `org-babel-load-file'.
`org-babel-load-file' triggers the built-in Org version clashing
the newer Org version attempted to be loaded later.
It is recommended to move the Org loading code before the
`org-babel-load-file' call.
2. New Org version is loaded manually by setting `load-path', but some
other package depending on Org is loaded before the `load-path' is
configured.
This "other package" is triggering built-in Org version, again
causing the version mismatch.
It is recommended to set `load-path' as early in the config as
possible.
3. New Org version is loaded using straight.el package manager and
other package depending on Org is loaded before straight triggers
loading of the newer Org version.
It is recommended to put
(straight-use-package 'org)
early in the config. Ideally, right after the straight.el
bootstrap. Moving `use-package' :straight declaration may not be
sufficient if the corresponding `use-package' statement is
deferring the loading.
--8<---cut here---end--->8---
Best wishes,
Re: Images in org-mode
>>>>> Mark Barton writes: >> On Sep 10, 2022, at 12:03 PM, Colin Baxter wrote: >> >> >> I seem to remember that the option >> >> #+ATTR_ORG: :width 100 >> >> could scale the display of an image in an org-mode file. This no >> longer works - perhaps it never did. How should I scale an image >> display in an org-mode file (not exported)? >> >> Best wishes, >> >> Colin Baxter. >> >> > Check the value set for org-image-actual-width. Mine defaulted to > t, so I changed it. There is some documentation if you use: C-h v > org-image-actual-width Yes, org-image-actual-width is the variable I need. It was set to 't' and I've now changed to a number. With the #+ATTR setting it works as per the documentation. I should have gone through the list of variables more carefully before posting. Thanks you all for your help. Best wishes, Colin.
Images in org-mode
I seem to remember that the option #+ATTR_ORG: :width 100 could scale the display of an image in an org-mode file. This no longer works - perhaps it never did. How should I scale an image display in an org-mode file (not exported)? Best wishes, Colin Baxter.
Re: org-verse-num: display verse numbers within a verse block
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> > https://gitlab.com/maciaschain/org-verse-num
>>
>> Your site tells me to turn JavaScript, enable Cookies and
>> complete a CAPTCHA, all of which I refuse to do.
>>
>> Do you have an alternative web-site?
> While I understand your frustration, please note that you really
> do not need to open GitLab/GitHub links in browser. All you need
> to do is
> git clone https://gitlab.com/maciaschain/org-verse-num
Thank you. I had tried that git clone url, or at least I thought I had:
my attempt came back unknown. I can only assume I entered a incorrect
URL. I have now successfully cloned the repository, and it looks like
something I will use.
Thanks again.
Best wishes,
Re: org-verse-num: display verse numbers within a verse block
> Juan Manuel Macías writes: > Hi all, I've added some minor improvements to my little package > 'org-verse-num', which was born out of necessity in my translation > to spanish (work-in-progress) of Homer's Odyssey (11600 verses > spread over 24 books): > https://gitlab.com/maciaschain/org-verse-num Your site tells me to turn JavaScript, enable Cookies and complete a CAPTCHA, all of which I refuse to do. Do you have an alternative web-site?
Re: commit e22b4eb7 kills formatting & color
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> I disable popups so I always receive a buffer with:
>>
>> --8<---cut here---start->8---
>> The local variables list in test.org or .dir-locals.el contains
>> values that may not be safe (*).
> Thanks!
> Can you try the attached patch?
I've applied your patch and it seems to work me. As far as I can tell
my org files and agenda now look and behave as normal.
Thanks.
Re: commit e22b4eb7 kills formatting & color
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> No, I spoke too soon. That is not the answer. For me using "emacs
>> -q", an opened org file will expand the folds using but
>> there is still no synatx coloring. This is probably not relevant
>> but my system is 32bit not 64.
> Hmm. I was able to reproduce the issue using some slightly
> non-standard settings. However, only when there is a popup window
> asking about non-safe file-local variables. Does it also happen
> for you after such a popup? Or do you have the settings marked
> safe?
I disable popups so I always receive a buffer with:
--8<---cut here---start->8---
The local variables list in test.org
or .dir-locals.el contains values that may not be safe (*).
Do you want to apply it? You can type
y -- to apply the local variables list.
n -- to ignore the local variables list.
! -- to apply the local variables list, and permanently mark these
values (*) as safe (in the future, they will be set automatically.)
i -- to ignore the local variables list, and permanently mark these
values (*) as ignored
--8<---cut here---end--->8---
I then enter "y". It's a habit of mine never to use "!" even for files I
use every day. I cannot remember ever entering "n" or "i".
Best wishes,
Re: Font-locking lost when using some local variables
Dear Julien, >>>>> Julien Cubizolles writes: > With the latest git version of org, all face specifications are > lost in the following org file after the dialog asking about the > unsafe buffer-auto-save-file-name local variable is > answered. Previous versions of org handled it without any problem. > # -*- buffer-auto-save-file-name: nil -*- * Test ** Hello I have experienced the same issue. I reported it yesterday here. The link is https://list.orgmode.org/orgmode/871qu0jo1w....@yandex.com/ Best wishes, Colin Baxter.
Re: commit e22b4eb7 kills formatting & color
>>>>> Colin Baxter writes: >>>>> Ihor Radchenko writes: >> Colin Baxter writes: >>> > Do you have any idea which particular file-local variable is > >>> leading to the breakage? >>> >>> Well I'm tempted to say all of them because I have local >>> variables in files and .dir-locals.el in many locations. But for >>> a start: >>> >>> # Local Variables: # eval: (setq org-confirm-babel-evaluate nil) >>> # eval: (setq org-adapt-indentation t) # eval: (set >>> (make-local-variable 'org-hide-emphasis-markers) t) # End: >> I am unable to see any issues with fontification starting from >> emacs -Q and loading a file containing these variables. > I think the solution for me is to delete the .elc files in > org-mode. I am about to do this and will report back. No, I spoke too soon. That is not the answer. For me using "emacs -q", an opened org file will expand the folds using but there is still no synatx coloring. This is probably not relevant but my system is 32bit not 64. Best wishes,
Re: commit e22b4eb7 kills formatting & color
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> > Do you have any idea which particular file-local variable is >
>> leading to the breakage?
>>
>> Well I'm tempted to say all of them because I have local
>> variables in files and .dir-locals.el in many locations. But for
>> a start:
>>
>> # Local Variables: # eval: (setq org-confirm-babel-evaluate nil)
>> # eval: (setq org-adapt-indentation t) # eval: (set
>> (make-local-variable 'org-hide-emphasis-markers) t) # End:
> I am unable to see any issues with fontification starting from
> emacs -Q and loading a file containing these variables.
I think the solution for me is to delete the .elc files in org-mode. I
am about to do this and will report back.
>> I am obviously missing something because I thought a local
>> variable was by definition local to a file or directory and was
>> not used until that file was opened. So why put them in effect
>> before they are needed?
> They are put into effect after the file is opened, but Org mode is
> not yet loaded. The previous default was applying file-locals
> _after_ Org mode is loaded and hence there was no way to set, for
> example, org-src-fontify-natively or org-enforce-todo-dependencies
> via file-local variables.
Thank you. Now I understand better.
Re: commit e22b4eb7 kills formatting & color
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> With the latest org-mode, my org files have lost all syntax
>> coloring and org-mode formatting. They are essentially dead. If I
>> revert commit e22b4eb7 then they come back to life with coloring
>> and formatting as usual. My files have local variables which have
>> worked perfecting ok before the e22b4eb7 commit. Have other users
>> experienced similar issues?
> The commits puts file-local and directory-local variables in
> effect _before_ loading Org mode. It means that e.g. setting up
> initial visibility can be done using directory-local variables.
> Do you have any idea which particular file-local variable is
> leading to the breakage?
> Best, Ihor
Dear Ihor,
Well I'm tempted to say all of them because I have local variables in
files and .dir-locals.el in many locations. But for a start:
# Local Variables:
# eval: (setq org-confirm-babel-evaluate nil)
# eval: (setq org-adapt-indentation t)
# eval: (set (make-local-variable 'org-hide-emphasis-markers) t)
# End:
I am obviously missing something because I thought a local variable was
by definition local to a file or directory and was not used until that
file was opened. So why put them in effect before they are needed?
Best wishes.
commit e22b4eb7 kills formatting & color
With the latest org-mode, my org files have lost all syntax coloring and org-mode formatting. They are essentially dead. If I revert commit e22b4eb7 then they come back to life with coloring and formatting as usual. My files have local variables which have worked perfecting ok before the e22b4eb7 commit. Have other users experienced similar issues? Best wishes, Colin Baxter.
Re: wrong type argument with latest org and [not] latest emacs
Excellent! Best wishes,
Re: wrong type argument with latest org and [not] latest emacs
>>>>> Alain Cochard writes:
> Colin Baxter writes on Tue 5 Jul 2022 20:24:
>> >>>>> Colin Baxter writes:
>>
>> >>>>> Ihor Radchenko writes: >> Colin Baxter
>> writes: >>> I'm sending this to emacs.orgmode
>> and emacs.devel lists.
>> >>>
>> >>> With the latest emacs:
>> >>>
>> >>>
>> >>> Debugger entered--Lisp error: (wrong-type-argument stringp
>> >>> (wrong-type-argument stringp nil)) >>>
>> format-message((wrong-type-argument stringp nil)) >>>
>> apply(format-message (wrong-type-argument stringp nil)) >>>
>> error((wrong-type-argument stringp nil)) #f(compiled-function >>>
>> (fun) # )(org-babel-remove-temporary-stable-directory)
>> >>> run-hook-wrapped(#f(compiled-function (fun) # ) org-babel-remove-temporary-stable-directory)
>>
>> >> Thanks for reporting! This likely caused by recent commit of
>> >> mine on systems with no write access to remote directory (at
>> >> least, I am unable to reproduce the steps on my system).
>>
>> >> Can you please try the attached patch?
>>
>> >> Best, Ihor
>>
>> >> From ddf6278e8fcbaa4939539277b111061b7c00f550 Mon Sep 17
>> 00:00:00 >> 2001 Message-Id: >>
>>
>> >> From: Ihor Radchenko Date: Tue, 5 Jul
>> 2022 >> 21:00:24 +0800 Subject: [PATCH] ob-core: Fix nil value of
>> >> `org-babel-temporary-stable-directory'
>>
>> >> * lisp/ob-core.el: Fallback the value of >>
>> `org-babel-temporary-stable-directory' to >>
>> `org-babel-temporary-directory' if there are issues with >>
>> directory creation.
>>
>> >> Fixes https://yhetil.org/emacs-devel/87sfnfhm6v@yandex.com
>> >> --- lisp/ob-core.el | 3 ++- 1 file changed, 2 insertions(+), 1
>> >> deletion(-)
>>
>> >> diff --git a/lisp/ob-core.el b/lisp/ob-core.el index >>
>> 6c379c121..aaf895d74 100644 --- a/lisp/ob-core.el +++ >>
>> b/lisp/ob-core.el @@ -3167,7 +3167,8 @@ (defvar >>
>> org-babel-temporary-stable-directory (expand-file-name >>
>> "babel-stable" (temporary-file-directory))) - (t nil))) + ;; >>
>> Fallback if things do not work. + (t >>
>> org-babel-temporary-directory))) "Directory to hold temporary >>
>> files created to execute code blocks. Used by >>
>> `org-babel-temp-file'. This directory will be removed on Emacs
>> >> shutdown.")) -- 2.35.1
>>
>> > Ok, that patch seems to solve the issue. I have applied the
>> patch > and I now get now error message when I close down
>> emacs-29.0.50.
>>
>> Typo! That's no error, not now error.
> So it is not the latest emacs
> GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
> 3.24.30, cairo version 1.17.4) of 2021-08-07
> but it seems related. I have no problem with
> Org mode version 9.5.4 (9.5.4-ge0b05b @
> /home/cochard/.emacs.d/elpa/org-9.5.4/)
> but if I use what I believe to be the latest org from git (pulled
> a few minutes ago):
> Org mode version 9.5.4 (release_9.5.4-609-g713598 @
> /home/cochard/Org/Coch-git/org-mode/lisp/)
> upon 'C-x C-c', I get
> org-babel-remove-temporary-stable-directory: Wrong type
> argument: stringp, nil
> and emacs does not even close. I cannot kill it either with 'C-c'
> on the terminal from which I started emacs. I have to 'kill -9
> '
It should work with org-mode release_9.5.4-610-gbdf7af.
Best wishes,
Colin Baxter.
Re: wrong type argument with latest org and latest emacs
>>>>> Colin Baxter writes: >>>>> Ihor Radchenko writes: >> Colin Baxter writes: >>> I'm sending this to emacs.orgmode and emacs.devel lists. >>> >>> With the latest emacs: >>> >>> >>> Debugger entered--Lisp error: (wrong-type-argument stringp >>> (wrong-type-argument stringp nil)) >>> format-message((wrong-type-argument stringp nil)) >>> apply(format-message (wrong-type-argument stringp nil)) >>> error((wrong-type-argument stringp nil)) #f(compiled-function >>> (fun) # )(org-babel-remove-temporary-stable-directory) >>> run-hook-wrapped(#f(compiled-function (fun) # ) org-babel-remove-temporary-stable-directory) >> Thanks for reporting! This likely caused by recent commit of >> mine on systems with no write access to remote directory (at >> least, I am unable to reproduce the steps on my system). >> Can you please try the attached patch? >> Best, Ihor >> From ddf6278e8fcbaa4939539277b111061b7c00f550 Mon Sep 17 00:00:00 >> 2001 Message-Id: >> >> From: Ihor Radchenko Date: Tue, 5 Jul 2022 >> 21:00:24 +0800 Subject: [PATCH] ob-core: Fix nil value of >> `org-babel-temporary-stable-directory' >> * lisp/ob-core.el: Fallback the value of >> `org-babel-temporary-stable-directory' to >> `org-babel-temporary-directory' if there are issues with >> directory creation. >> Fixes https://yhetil.org/emacs-devel/87sfnfhm6v@yandex.com >> --- lisp/ob-core.el | 3 ++- 1 file changed, 2 insertions(+), 1 >> deletion(-) >> diff --git a/lisp/ob-core.el b/lisp/ob-core.el index >> 6c379c121..aaf895d74 100644 --- a/lisp/ob-core.el +++ >> b/lisp/ob-core.el @@ -3167,7 +3167,8 @@ (defvar >> org-babel-temporary-stable-directory (expand-file-name >> "babel-stable" (temporary-file-directory))) - (t nil))) + ;; >> Fallback if things do not work. + (t >> org-babel-temporary-directory))) "Directory to hold temporary >> files created to execute code blocks. Used by >> `org-babel-temp-file'. This directory will be removed on Emacs >> shutdown.")) -- 2.35.1 > Ok, that patch seems to solve the issue. I have applied the patch > and I now get now error message when I close down emacs-29.0.50. Typo! That's no error, not now error. Best wishes,
Re: wrong type argument with latest org and latest emacs
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> I'm sending this to emacs.orgmode and emacs.devel lists.
>>
>> With the latest emacs:
>>
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp
>> (wrong-type-argument stringp nil))
>> format-message((wrong-type-argument stringp nil))
>> apply(format-message (wrong-type-argument stringp nil))
>> error((wrong-type-argument stringp nil)) #f(compiled-function
>> (fun) # )(org-babel-remove-temporary-stable-directory)
>> run-hook-wrapped(#f(compiled-function (fun) # ) org-babel-remove-temporary-stable-directory)
> Thanks for reporting! This likely caused by recent commit of mine
> on systems with no write access to remote directory (at least, I
> am unable to reproduce the steps on my system).
> Can you please try the attached patch?
> Best, Ihor
> From ddf6278e8fcbaa4939539277b111061b7c00f550 Mon Sep 17 00:00:00
> 2001 Message-Id:
>
> From: Ihor Radchenko Date: Tue, 5 Jul 2022
> 21:00:24 +0800 Subject: [PATCH] ob-core: Fix nil value of
> `org-babel-temporary-stable-directory'
> * lisp/ob-core.el: Fallback the value of
> `org-babel-temporary-stable-directory' to
> `org-babel-temporary-directory' if there are issues with directory
> creation.
> Fixes https://yhetil.org/emacs-devel/87sfnfhm6v@yandex.com ---
> lisp/ob-core.el | 3 ++- 1 file changed, 2 insertions(+), 1
> deletion(-)
> diff --git a/lisp/ob-core.el b/lisp/ob-core.el index
> 6c379c121..aaf895d74 100644 --- a/lisp/ob-core.el +++
> b/lisp/ob-core.el @@ -3167,7 +3167,8 @@ (defvar
> org-babel-temporary-stable-directory (expand-file-name
> "babel-stable" (temporary-file-directory))) - (t nil))) + ;;
> Fallback if things do not work. + (t
> org-babel-temporary-directory))) "Directory to hold temporary
> files created to execute code blocks. Used by
> `org-babel-temp-file'. This directory will be removed on Emacs
> shutdown.")) -- 2.35.1
Ok, that patch seems to solve the issue. I have applied the patch and I
now get now error message when I close down emacs-29.0.50.
Thank you.
Best wishes,
wrong type argument with latest org and latest emacs
I'm sending this to emacs.orgmode and emacs.devel lists. With the latest emacs: (1) emacs -q (2) M-x org-version --> Org mode version 9.5.4 (release_9.5.4-3-g6dc785 (4) C-x C-c --> emacs closes with no messages (5) Repeat (1) (6) In scratch buffer load latest org-mode by eval (add-to-list 'load-path (expand-file-name "/path/to/git/org-mode/lisp")) (7) M-x org-version --> Org mode version 9.5.4 (release_9.5.4-608-g080462 (8) C-x C-c --> emacs closes with error message --> Wrong type argument: stringp, (wrong-type-argument stringp nil) Debugging further reveals: Debugger entered--Lisp error: (wrong-type-argument stringp (wrong-type-argument stringp nil)) format-message((wrong-type-argument stringp nil)) apply(format-message (wrong-type-argument stringp nil)) error((wrong-type-argument stringp nil)) #f(compiled-function (fun) #)(org-babel-remove-temporary-stable-directory) run-hook-wrapped(#f(compiled-function (fun) #) org-babel-remove-temporary-stable-directory) run-hook-query-error-with-timeout(kill-emacs-hook) kill-emacs(nil nil) save-buffers-kill-emacs(nil) save-buffers-kill-terminal(nil) funcall-interactively(save-buffers-kill-terminal nil) call-interactively(save-buffers-kill-terminal nil nil) command-execute(save-buffers-kill-terminal) Best wishes,
Re: Clocktable parameters
>>>>> Ihor Radchenko writes:
> Colin Baxter ️ writes:
>> I find the differences between the variables
>>
>> (1) org-clocktable-defaults (2)
>> org-agenda-clockreport-parameter-plist
>>
>> hard to understand.
>>
>> Ok, (1) seems reasonably clear. It's described in `info' (there's
>> no doc-string). The variable (2) confuses me. According to its
>> doc string (there's no `info' mention) it gives parameters for a
>> clock table in the daily and weekly agendas. How is that
>> different from (1)?
>>
>> Am I correct in thinking (1) is primarily for a clock table not
>> associated with the agenda? Quite how such a clocktable would
>> arise is unclear to me.
> 8.4.2 The clock table section of the manual described the
> clocktables you can create inside Org
> buffers. org-clocktable-defaults apply for those clocktables.
> org-agenda-clockreport-parameter-plist only applies to
> org-agenda-clockreport-mode inside agenda
> views. org-clocktable-defaults is disregarded inside Org agendas.
Thank you very much for this explanation.
Best wishes,
Re: Missing from Info
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> I think that this potentially confusing to someone unfamiliar in
>> the format of an info file. I had thought of suggesting the line
>> be changed to "The next sections have further details." That
>> suggestion however is no better that what is in place already.
> I do not see much improvement using your variant as well. Also,
> note that, for example, Elisp manual is full of constructs like
> what we are discussing.
The line could be removed?
Best wishes,
Re: Missing from Info
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> The latest org-mode info has a section entitled: "13.10.2 LaTeX
>> specific export settings". At the foot of that Section is the
>> line: "The following sections have further details." There is
>> nothing following.
> I do have section 13.10.3 and the subsequent sections on my side.
> Could you please check the location of your info file by running
> M-: default-directory when inside the info buffer and
> sharing the output?
> Best, Ihor
M-: produces "/home//git/org-mode/doc/"
Is it not that the org version has indeed further sections beneath, but
these are not visible on the single info page?
Best wishes,
Missing from Info
Hello, The latest org-mode info has a section entitled: "13.10.2 LaTeX specific export settings". At the foot of that Section is the line: "The following sections have further details." There is nothing following. Best wishes,
Re: org-noter
>>>>> Uwe Brauer writes: --- Snip -- > BTW does this mode set any sort of marker in the pdf? I have never seen any marker in the pdf file. Best wishes, Colin Baxter.
Re: org-noter
Hello Uwe > Uwe Brauer writes: > Hi I am running GNU emacs master (2 month old) and have not been > able to use successfully org-noter. > When I open a pdf file with doc-view there seems no way to add a > note to the file. The documentation says one should simple press > «️i», but either with > (org-noter-notes-mode 'toggle) that binding is not defined with > org-noter-doc-mode it is but nothing happens, only garbage > collecting. Works for me using today's pull of or-mode and emacs-29.0.50.
Re: [PATCH] Re: org-agenda-clock-report-header
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> Unfortunately, I see no difference in my clock tables whether I
>> have org-agenda-clock-report-header set to t, nil or something
>> like "My-Heading", or if I put :Header: as a tag in the file
>> headline that contains the clock table, or if I write :Header t
>> in the #+BEGIN: clocktable line. You can see I'm ringing the
>> changes in ignorant desperation. I'm pretty stupid so I'm
>> obviously missing something fundamental here - but what?
> Because your clock tables in Org _files_ have nothing to do with
> agenda. There is no "Agenda clock report mode" when you create an
> ordinary clock report in Org buffers.
Well now you've really confused me because I wasn't in an agenda buffer,
I had constructed a clock table from a non-agenda org file.
Could give me a concrete example of where the variable
org-agenda-clock-report-header might be used?
Best wishes,
Re: Regarding arbitrary Org blocks
>>>>> Russell Adams writes: > On Wed, May 11, 2022 at 09:23:27PM +0300, Daniel Fleischer wrote: >> Russell Adams [2022-05-11 Wed 18:14] wrote: >> >> > Could I add some minor mode to say text-mode with >> auto-fill-mode and > aspell somewhere when opening those blocks? >> >> Hi! If you're editing text why do you need a special buffer? You >> can edit them in the orgmode buffer and enjoy all its textual >> features. > First up, it's because it used to work and now it doesn't. ;] > Second it can be very useful to work on a sub-buffer, or indirect > buffer for some content. Why shouldn't I be able to edit the > contents of that block inside an indirect buffer where my > beginning-of-buffer, end-of-buffer, word wrap, or global find and > replace are constrained to that block of text? > This works for example blocks, but no longer for verse and quote > blocks. These are native Org block types and not my fanciful made > up ones. Why should the popup work for example blocks, but not the > others? That borders on a bug, where my question was considered as > a configuration question. I very much support the idea that special and source blocks should be treatable in the same way. I'd like to be able to edit example and quote using C-c '. Best wishes, Colin Baxter.
Re: [PATCH] Re: org-agenda-clock-report-header
Hello Ihor,
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> Could more information perhaps be added to the doc string of
>> "org-agenda-clock-report-header"? And an example would be very
>> useful. As it stands at present, I haven't a clue as to what the
>> variable does and why it might be useful.
> It's literally a string inserted right before the table. There is
> nothing much to show there. See
>
https://orgmode.org/list/CAJAdVc06_tj58Je=tn42jqfutkjamqbqdcvobqxeegars_m...@mail.gmail.com
> Is version in the attached patch more clear?
> Best, Ihor
> From 9b5f5844aedfab9f36ba89ed8beca36651370c0a Mon Sep 17 00:00:00
> 2001 Message-Id:
>
<9b5f5844aedfab9f36ba89ed8beca36651370c0a.1652099870.git.yanta...@gmail.com>
> From: Ihor Radchenko Date: Mon, 9 May 2022
> 20:34:38 +0800 Subject: [PATCH] org-agenda-clock-report-header:
> Update docstring
> See https://orgmode.org/list/87o808j6si@yandex.com ---
> lisp/org-agenda.el | 6 +++--- 1 file changed, 3 insertions(+), 3
> deletions(-)
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index
> 0479a0e1f..9d38b889d 100644 --- a/lisp/org-agenda.el +++
> b/lisp/org-agenda.el @@ -1221,11 +1221,11 @@ (defcustom
> org-agenda-timegrid-use-ampm nil :type 'boolean)
> (defcustom org-agenda-clock-report-header nil - "Header for org
> agenda clock report mode" + "Header inserted before the table in
> Org agenda clock report mode." :group 'org-agenda :type '(choice
> - (string :tag "Header") - (const :tag "No header" nil)) + (string
> :tag "Header") + (const :tag "No header" nil)) :safe #'stringp
> :package-version '(Org . "9.6"))
> -- 2.35.1
Thank you for your reply and patch.
Unfortunately, I see no difference in my clock tables whether I have
org-agenda-clock-report-header set to t, nil or something like
"My-Heading", or if I put :Header: as a tag in the file headline that
contains the clock table, or if I write :Header t in the #+BEGIN:
clocktable line. You can see I'm ringing the changes in ignorant
desperation. I'm pretty stupid so I'm obviously missing something
fundamental here - but what?
Best wishes,
Colin Baxter.
org-agenda-clock-report-header
Hello, Could more information perhaps be added to the doc string of "org-agenda-clock-report-header"? And an example would be very useful. As it stands at present, I haven't a clue as to what the variable does and why it might be useful. Thank you. Colin Baxter.
Re: Cursor stays TODO creation
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> With the latest org-mode, if I set a TODO keyword then after its
>> creation the cursor stays to the left of "T". In the past it
>> would move one space beyond the "O". Is this a new feature? If it
>> is then it's a nuisance.
> Thanks for reporting! Fixed in 1ed9e4223.
Great, I can confirm that it's fixed for me.
Thank you.
Best wishes,
Colin Baxter.
Cursor stays TODO creation
Hello, With the latest org-mode, if I set a TODO keyword then after its creation the cursor stays to the left of "T". In the past it would move one space beyond the "O". Is this a new feature? If it is then it's a nuisance. Best wishes, Colin Baxter.
Re: Cannot link to files with no extension
> Nick Dokos writes:
> Nick Dokos writes:
>> Check also the value of the system-specific variable
>> `org-file-apps-{gnus,windowsnt,macos}' - whichever is applcible
>> to your case.
> That should be `org-file-apps-{gnu,windowsnt,macos}'. -- Nick
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin
> Fowler
It turns out I was clicking the wrong mouse button. On my setup, the
right-hand mouse button opens files 'b' and 'b.',
whereas the left-hand button only opens links to 'b.'. I was
not aware that the behaviour of org-mode links was mouse-button
dependent.
Best wishes,
Re: Cannot link to files with no extension
I see the problem using emacs -Q, as I reported in a previous email.
Re: Cannot link to files with no extension
Hi Nick,
>>>>> Nick Dokos writes:
> Colin Baxter writes:
>> 6. In a.org enter [[file:./z][This is file z]] and save.
>>
>> 7. Click on the link.
>>
>> 8. Message "Running less in /path/to/z ... done", but link does
>> not open.
>>
> This sounds like your `org-file-apps' is funny. What is its value?
> Check also the value of the system-specific variable
> `org-file-apps-{gnus,windowsnt,macos}' - whichever is applcible to
> your case.
I have not altered (knowingly!) my 'org-file-apps' for years. Its value
is:
--8<---cut here---start->8---
Value:
(("\\.pdf\\'" . "xpdf %s")
(auto-mode . emacs)
("\\.x?html?\\'" lambda
(file link)
(eww-open-file file))
("\\.pdf\\'" . system)
("\\.dvi\\'" . system)
("\\.ps\\'" . system))
Original value was
((auto-mode . emacs)
(directory . emacs)
("\\.mm\\'" . default)
("\\.x?html?\\'" . default)
("\\.pdf\\'" . default))
--8<---cut here---end--->8---
The odd thing is that my problem has just arisen. I don't remember
having it before say a few weeks ago.
Best wishes,
Colin.
Re: Cannot link to files with no extension
Hello, Bhavin, >>>>> Bhavin Gandhi writes: > Hello Colin, > On Wed, 9 Mar 2022 at 02:24, Colin Baxter wrote: >> Org-mode cannot link to files without an extension. I therefore >> cannot use org-store-link for org-journal files, etc. > I'm not able to reproduce this on the latest main branch. I tried > this with Emacs 28.0.91: > Opened the COPYING file from org-mode repository. Executed M-x > org-store-link Created test.org and did C-c C-l. > I was able to create a link and open it with C-c C-o. > Can you add more details like version, and steps to reproduce with > emacs -Q? > -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in Thanks for your reply. 1. Touch two files in some directory: touch a.org , touch z 2. emacs -Q 3. C-x f a.org and C-x f z 4. Write some text in each file (I suppose this is not really necessary). 5. Close the buffer z. 6. In a.org enter [[file:./z][This is file z]] and save. 7. Click on the link. 8. Message "Running less in /path/to/z ... done", but link does not open. 9. I get the same if I use C-c C-o. 10. Copy z to z.org. 11. In a.org enter [[file:./z.org][This is file z.org]] and save. 12. Link now opens if it's clicked or C-c C-o is used. This test was done with emacs-29.0.50 and org-version 9.52. I'm on Debian 4.9.290-1. I hope this helps. Best wishes, Colin.
Cannot link to files with no extension
Org-mode cannot link to files without an extension. I therefore cannot use org-store-link for org-journal files, etc. Best wishes, Colin Baxter.
typo in org-clock.el
At line 2512 :end should be :tend as in: (user-error "Clocktable `:step' can only be used with `:block' or `:tstart, :tend'"))
Re: Depreciating TeX-style LaTeX fragments
>>>>> Juan Manuel Macías writes:
> Colin Baxter writes:
>> Ah, LaTeX3 - whatever happened to that?
> If you're a LaTeX user, you're already using LaTeX3 to a very high
> extent, even if you don't see it. The current idea is not to
> replace LaTeX2e with LaTeX3 as a new version, but to gradually
> incorporate elements of LaTeX3 into the LaTeX kernel, like the new
> syntax, xparse, etc. LaTeX3 is already present in many aspects of
> LaTeX, and that is an undeniable advance. If anyone is interested
> in the state of the art, this short talk by Frank Mittelbach at
> TUG 2020 is very illustrative:
Yes, I know. My remark was tongue in cheek.
Re: Depreciating TeX-style LaTeX fragments
> Sébastien Miquel writes:
> Hi, With respect to readability, I only mean to point out that the
> $…$ syntax is one less character, and that the \(\) characters are
> quite overloaded.
Indeed. Compare something like
$g=\lim_{\delta m\to 0}(\delta F/\delta m)$
with
\(g=\lim_{\delta m\to 0}(\delta F/\delta m)\)
Backslash city! I know which one I'd prefer to read.
>> this is a good opportunity to point out that $/$$ are very much
>> second class citizens in LaTeX now, no matter what you may see in
>> old documents.
> The posts that you quote are 10 years old. As per [0] (2020),
> there will be no LaTeX3. Nor is it only old documents that use the
> $…$ syntax : looking for learning ressources (see [1]), everything
> that I find uses it. That includes The Not So Short Introduction
> to LaTeX [2] (2021) and
> https://en.wikibooks.org/wiki/LaTeX/Mathematics.
Ah, LaTeX3 - whatever happened to that?
> Although I have no evidence of this, my expectation is that the
> majority of tex users use the $…$ syntax (it is in fact widely
> used outside of tex: in most markdown flavors and texmacs for
> example). I also expect that a significant proportion of tex users
> are not aware of the \(…\) syntax. I think here of users that are
> less tech literate than most of this mailing list.
Agreed.
Best wishes,
Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
> Rudolf Adamkovič writes: > Ihor Radchenko writes: >> So, unless there is overwhelming support for changing uppercase >> defaults into lowercase and a thorough patch, I am inclined >> towards preserving the existing behaviour. > The results so far: > - For inconsistent defaults: Colin I did not write that. I wrote that I am for a default remaining a default. Whether it is "consistent" or "inconsistent" is not important. Once chosen it should stay fixed.
Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> What is the point of changing a default? Users can change to
>> whatever they like, but a default is a default - i.e. remains
>> fixed. Why a particular default arose belongs to peculiarities of
>> history. Do people really want to revisit this year after year?
>> The value of a default is irrelevant: what is important is that
>> it does not change, once it is chosen, without some very good
>> reason. I have not seen that reason in this particular case. The
>> arguments of consistency are ephemeral.
> For some more context, other functions are not really consistent
> about uppercase/lowercase: - =org-insert-structure-template=
> lowercase - =org-insert-drawer= uppercase -
> =org-insert-property-drawer= uppercase -
> =org-babel-exp-code-template= defaults to uppercase -
> =org-clock-find-position= defaults to uppercase :END: -
> =org-feed-write-status= defaults to uppercase -
> =org-inlinetask-insert-task= defaults to uppercase -
> =org-mobile-write-agenda-for-mobile= defaults to uppercase -
> =org-babel-examplify-region= lowercase
> I just looked for END vs end.
> So, unless there is overwhelming support for changing uppercase
> defaults into lowercase and a thorough patch, I am inclined
> towards preserving the existing behaviour.
Agreed.
> Changing just RESULTS keyword provides no benefit to making things
> consistent.
Agreed.
Best - Colin
Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
> Timothy writes: > Hi Gyro, >> Consider Emerson’s quote: >> >> “A foolish consistency is the hobgoblin of little minds, adored >> by little statesmen and philosophers and divines. With >> consistency a great soul has simply nothing to do.” > I think applying a quote about how societal expectations and norms > can limit the capacity for greatness of individuals, to … > capitalisation is a bit of a stretch. > FWIW, I think it would be good to be internally > consistent. #+RESULTS is currently one of the few keywords > inserted in upper case. Unless there’s a good reason to > distinguish it from other keywords (perhaps an argument could be > made that it should be treated differently because it is usually > generated, not inserted by the user?), I’d be in favour of > changing the default to be consistent. What is the point of changing a default? Users can change to whatever they like, but a default is a default - i.e. remains fixed. Why a particular default arose belongs to peculiarities of history. Do people really want to revisit this year after year? The value of a default is irrelevant: what is important is that it does not change, once it is chosen, without some very good reason. I have not seen that reason in this particular case. The arguments of consistency are ephemeral.
Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
> Rudolf Adamkovič writes: > If I remember well, Org decided to suggest with lowercase keywords > (and use uppercase keywords in the manual, for some reason). > Then, we should change "org-babel-results-keyword" from "RESULTS" > to "results". Change it for yourself. Please don't change the default.
Re: Feedback on Emacs-Jupyter
> Nathaniel Nicandro writes: > Hello all, > I'm the maintainer of the emacs-jupyter project > (https://github.com/nnicandro/emacs-jupyter) which essentially > integrates Jupyter kernels (https://jupyter.org) with Org mode > source blocks. jupyter.org in using cloudflare uses non-free js. For me, this is a significant barrier.
Re: org-journal key-bind confusion
I've changed the kbd for org-journal-new-entry to "C-c j". Simpler too. Thanks. Best wishes, Colin -
Re: org-journal key-bind confusion
Thank you for the reply.
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> There appears to be confusion between "org-journal-new-entry" and
>> "org-goto". My ME is:
>>
>> 1. emacs -Q (I used emacs-29.0.50) 2. M-x load-library
>> 3. /path/to/org-journal.el 4. C-h c 5. C-c C-j
>> 6. "C-c C-j runs the command org-journal-new-entry" 7. Create an
>> org file (say "test.org") from C-x C-f 8. C-h c 9. C-c C-j
>> 10. "C-c C-j runs the command org-goto"
> Note that org-journal is not a part of Org. From a quick glance
> at the source code, C-c C-j for org-journal only works in
> org-journal-mode.
Yes, that is correct.
> I do not see anything wrong on Org side. Moreover, this issue is
> explicitly mentioned in
>
https://github.com/bastibe/org-journal#some-key-bindings-in-org-journal-conflict-with-org-mode-key-bindings
I didn't know of the URL mentioning the issue, thanks.
Best wishes,
Colin -
org-journal key-bind confusion
There appears to be confusion between "org-journal-new-entry" and "org-goto". My ME is: 1. emacs -Q (I used emacs-29.0.50) 2. M-x load-library 3. /path/to/org-journal.el 4. C-h c 5. C-c C-j 6. "C-c C-j runs the command org-journal-new-entry" 7. Create an org file (say "test.org") from C-x C-f 8. C-h c 9. C-c C-j 10. "C-c C-j runs the command org-goto" Best wishes, Colin Baxter.
Re: Future TODOs with notes appear prematurely
>>>>> Samuel Wales writes: > a guess from everything yoyu described. i assume you are talking > about the agenda agenda daily/weekly view. please confirm. > what are the values of org-agenda-include-inactive-timestamps, > org-agenda-log-mode, and org-agenda-log-mode-items? Well, this is embarrassing. On a newly launched emacs, I cannot now reproduce what I originally saw. I am sorry for forgetting to try the obvious things before posting! > On 12/17/21, Colin Baxter wrote: >> Hello, >> >> A TODO item scheduled for a future date ordinarily does not >> appear in today's agenda. However, this is not the case if the >> TODO has a note dated today in its log drawer. The TODO item is >> now visible in today's agenda, even though it's scheduled for the >> future. If this isn't a bug then how can I keep the TODO item >> hidden until its scheduled date? >> >> Best wishes, >> >> Colin Baxter. >> >> >>
Future TODOs with notes appear prematurely
Hello, A TODO item scheduled for a future date ordinarily does not appear in today's agenda. However, this is not the case if the TODO has a note dated today in its log drawer. The TODO item is now visible in today's agenda, even though it's scheduled for the future. If this isn't a bug then how can I keep the TODO item hidden until its scheduled date? Best wishes, Colin Baxter.
Re: [BUG] Plain capture template clocks into following headline instead of given olp [9.5.1 (release_9.5.1-15-gdb4805 @ /usr/share/emacs/29.0.50/lisp/org/)]
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> If you get no response on this org-mode list, perhaps re-submit
>> it as a normal emacs bug (M-x report-emacs-bug ).
> That's not a good idea. org-mode related staff is just forwarded
> back to this list (but not even always).
Ah, I didn't know that - thanks.
> Just wait a bit until someone get free time to look into your
> report.
Re: [BUG] Plain capture template clocks into following headline instead of given olp [9.5.1 (release_9.5.1-15-gdb4805 @ /usr/share/emacs/29.0.50/lisp/org/)]
Hello Michael, > Michael Eliachevitch writes: > Hello Colin, >> This is amazing. I have run into exactly the same problem. I was >> wondering whether to report it! >> >> Oh, and I can reproduce the bug with your ECM. > Glad that I'm not alone. When you say you ran into this, is this > something that appeared to you in a recent org-version for > existing capture templates which worked in older versions? Or is > this a behavior that has been always there for capture-templates > with :clock-in? A couple of night ago, I thought I'd try experimenting with my org-capture setup. I normally have a menu with single letter choices and no hierarchy. I wrote a couple of lines, very similar to yours, but couldn't get it to work. I thought it simply indicative of my ignorance of lisp (which is profound!) and abandoned the experiment. I use org-mode version 9.5.1 and I got the same results with emacs-28.0.90, 29.0.50 and (I think) 27.2. > When I have time I might try if I can hack something to fix this, > but not sure if I have time as I'm quite busy with my PhD > currently. Btw, I'm not sure what the procedure following the bug > report will be, as I'm quite new here on the mailing list and am > still more used to working with github-issues etc, but I guess > patience is key in an open source project. If you get no response on this org-mode list, perhaps re-submit it as a normal emacs bug (M-x report-emacs-bug ). Best wishes, Colin. signature.asc Description: PGP signature
Re: [BUG] Plain capture template clocks into following headline instead of given olp [9.5.1 (release_9.5.1-15-gdb4805 @ /usr/share/emacs/29.0.50/lisp/org/)]
Hello Michael,
>>>>> Michael Eliachevitch writes:
> Hello, I found a potential bug in org which I can reproduce with a
> minimal configuration.
> I added some org-capture templates purely for clocking into tasks
> via the capture-menu. These capture templates are for things I
> want to time-track but don't want to create a special entry for
> (like eating and breaks), so I used the `plain' type with an empty
> `""' template hoping it would clock into the given olp:
> (setq org-capture-templates '(( "c" "clock into") ("cu"
> "Unintended" plain (file+olp "~/org/clock_test.org" "Time sinks"
> "Unintended") "" :clock-in t :clock-keep t :immediate-finish t)
> ("ce" "Eating" plain (file+olp "~/org/clock_test.org" "Time sinks"
> "Eating") "" :clock-in t :clock-keep t :immediate-finish t)))
> My `clock_test.org' has the following headings:
> * Time sinks ** Unintended ** Eating
This is amazing. I have run into exactly the same problem. I was
wondering whether to report it!
Oh, and I can reproduce the bug with your ECM.
Thanks for reporting it.
Best wishes,
Colin Baxter.
signature.asc
Description: PGP signature
Re: org-element-cache warning even when off
>>>>> Ihor Radchenko writes:
> Colin Baxter writes:
>> I do not have an org-persist cache present. So I wonder where is
>> the cache that I am supposedly corrupting.
> That warning is shown when org-element--parse-to throws an error
> (the parser fails). Apparently, there is some problem with Org
> parser.
>> Warning (org-element-cache): org-element--cache: Cache corruption
>> detected in todo.habits.org::539. Resetting.
> Can you try to copy the file text around 539 buffer point into
> separate Org file and check if you are seeing this kind of error
> there?
I have done this but now do not see any warning. Further, I now don't
seem to be able to re-produce the issue at all. It could that the
original warning was spurious and reflected some stale state. I did have
multiple emacsen open at the time.
I normally have org-persist on, but occasionally I need to do multiple
edits on an agenda file. On those occasions, I switch org-persist off
and move its cache out of the way in order to avoid cache corruption
warnings and to keep the syntax highlighting. I will look out for any
cache warnings if I edit any agenda files by hand again.
Best wishes,
Colin Baxter.
