Re: Bug? org-id-find not finding some IDs

2022-08-04 Thread Jack Kamm
Ihor Radchenko  writes:

> This is indeed inconsistent. The current behaviour is to scan only files
> where it is known that IDs are present.
>
> Can you try the attached patch?

Thanks, Ihor. I tried your patch and it solved my issue -- both the
minimal example I sent, as well as the related issue I was experiencing
with org-caldav.

Jack



Re: [PATCH v2] lisp/ob-plantuml.el: Insert results in buffer

2022-08-04 Thread Ihor Radchenko
Joseph Turner  writes:

> When :results header arg is set to a value that doesn't include
> "file", insert txt output in buffer below src block.

This looks reasonable. Thanks!

> -  (let* ((out-file (or (cdr (assq :file params))
> -(error "PlantUML requires a \":file\" header argument")))
> +  (let* ((do-export (member "file"
> +(split-string (cdr (assq :results params)

Let's take this opportunity and fix another omission in ob-plantuml.
:results may generally contain Elisp sexps to be evaluated and the whole
split-string busyness is not accurate. Please use :result-params list
instead of :results.

Also, can you please update the ob-plantuml documentation according to
the changes made. The current version is in
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-plantuml.html

You will need to create a patch against
https://git.sr.ht/~bzg/worg/tree/master/item/org-contrib/babel/languages/ob-doc-plantuml.org
repo.

Best,
Ihor



Re: Tracking todo state changes AND automatically change to done when all children are done

2022-08-04 Thread Ihor Radchenko
>
> Okay, I understand. Sorry for the duplicate, I didn't see this thread.


No problem. It's not like that thread is obviously related. I found the
relation in the root cause, after debugging.

Also, I don't understand why, but when I click on it, no site is
> accessible. I tried to remove the "@localhost", also nothing.
> Do you know how to follow the thread ?


Copy-paste the link manually? IDK. The link works on my side.
I guess you can search "org-auto-repeat-maybe: error "Can’t expand
minibuffer to full frame" and missing log note
" subject in
https://list.orgmode.org/

On Fri, Aug 5, 2022 at 10:11 AM Cletip Cletip 
wrote:

> Okay, I understand. Sorry for the duplicate, I didn't see this thread.
>
> Also, I don't understand why, but when I click on it, no site is
> accessible. I tried to remove the "@localhost", also nothing.
> Do you know how to follow the thread ?
>
> Thanks you again for your help.
>
> On Fri, 5 Aug 2022, 03:26 Ihor Radchenko,  wrote:
>
>> Cletip Cletip  writes:
>>
>> > So, can we consider this as a bug?
>>
>> Yup. And the linked thread may be the fix or at least something close.
>>
>> Best,
>> Ihor
>>
>>


Re: ?bug in org-fold-core

2022-08-04 Thread Ihor Radchenko
Sharon Kimble  writes:

>> I am not sure if I understand what you mean. Can you explain in more details?
>
> Sure. This is one entry where 'org-lint' shows as '533 Link to non-existent 
> local file ":~/path/to/directory/"'
>
> =
> *** dired
> # [[file+emacs:~/path/to/directory/]] ;;; opens dired at that directory
> [[file::~/path/to/directory/]] ;;; opens dired at that directory
> =
>
> This is the full org-lint for my 'instructions.org' file -
>
> =
>533 low   Link to non-existent local file ":~/path/to/directory/"

This is nothing wrong on Org side. Just an indication for you that you
have issues with Org markup in your Org file. I suggest fixing them, for
your own safety - Org may behave incorrectly on incorrect Org documents.

>>> Is it possible for it to have a file-only way of reverting to the old way 
>>> of 'file-local variables' please? As it currently stands, no org-headings 
>>> are
>>> shown in the colours that other org-files are showing them, and its 
>>> giving the appearance of org-mode not reading and displaying it!
>>
>> If you have no fontification, please update Org. This issue has been
>> fixed in a yesterday's commit.
>>
> 
> I'm now running using 'Org mode version 9.5.4 (release_9.5.4-706-g4702a7 @ 
> /home/boudiccas/git/org-mode/lisp/)'. Is this the most recent version please? 
> Git pull says that its up-to-date.

This is some very strange Org version - we have no commit 4702a7. I
suggest removing your local copy and re-fetch Org from our official
repo. See https://orgmode.org/

> I'm not sure what you mean by 'no fontification'? The instructions file has 
> the usual org-headings, and the occasional drawer. Can you elucidate please?

I probably misunderstood you. I do not understand what you mean by

>>> ... no org-headings are shown in the colours that other org-files
>>> are showing them, and its giving the appearance of org-mode not
>>> reading and displaying it!"

Best,
Ihor



Re: Odd characters in the fast tags selection interface

2022-08-04 Thread Ihor Radchenko
Hanno  writes:

> However, I have noticed some oddities with the characters that are being
> associated as keys to the entries in the interface:
>
> - after "a..z" runs out, '{', '|' and '}' are being used which seems
>   reasonable -- but after that, I get '\200' and similar before reaching
>   '©'...

This is indeed true, but what can we do? There are only that many
characters in the keyboard. We may instead start using two-key
combinations for tags beyond #26, similar to org-capture. Patches are
welcome!

> - when defining my own keys, they are not displayed in the top; instead
>   their characters are missing in the 'a'..'z' range leaving more room
>   for odd and very difficult-to-type characters
>
> I am therefore wondering: can I limit the range of characters being
> used? Can I force characters defined in =org-tag-persistent-alist= to be
> shown on top? Is this behavior maybe a bug?

I think that it would make sense to have `org-tag-persistent-alist`
staff being shown on top. Unless there are objections I can merge this
trivial change.

> I attach an org-file that demonstrates the issue when opened with =emacs
> -Q= and after evaluating the included source block.

Thanks! This was very helpful.

Best,
Ihor



Re: Tracking todo state changes AND automatically change to done when all children are done

2022-08-04 Thread Cletip Cletip
Okay, I understand. Sorry for the duplicate, I didn't see this thread.

Also, I don't understand why, but when I click on it, no site is
accessible. I tried to remove the "@localhost", also nothing.
Do you know how to follow the thread ?

Thanks you again for your help.

On Fri, 5 Aug 2022, 03:26 Ihor Radchenko,  wrote:

> Cletip Cletip  writes:
>
> > So, can we consider this as a bug?
>
> Yup. And the linked thread may be the fix or at least something close.
>
> Best,
> Ihor
>
>


Re: Internal link to resulting image from source block

2022-08-04 Thread Ihor Radchenko
reza  writes:

>> They way to work around the problem is providing explicit name anchor to
>> the results block:
>> 
>> 
>> #+name: html transformation
>> #+begin_src plantuml :file img/transformation-html.svg :exports results 
>> :mkdirp yes
>> file org
>> file html
>> org -> html : org-html-publish-to-html
>> #+end_src
>> 
>> #+name: html transformation result
>> #+RESULTS: html transformation
>> [[file:img/transformation-html.svg]]
>> 
>> Now I want to include an internal link to this figure with [[html
>> transformation result]]. This works now.
>> 
>> 
>> Though I do agree that the current behaviour is not intuitive in this
>> specific scenario. When a user provides :exports results, it would make
>> sense to inherit all the affiliated keywords, including #+name and
>> possibly various #+attr_* to the results of evaluation.
>> 
>> On the other hand, inheriting may be tricky. I can imagine situations
>> when such inheritance is not desired and a user actually prefers to
>> state the results keywords manually.
>> 
>> I am not sure what would be the best way to handle the situation at hand
>> while not breaking the other :exports variants.
>
> Shall I file a bug report? As a beginner I assumed that the name tag 
> gets carried over to the result and I still think it is a sensible 
> solution, but I could imagine that is perhaps not a very explicit behavior.

This email is already a bug report :)

However, we cannot just blindly carry over the name tag to the result.

Consider a case when you have ":results both" in your src block. Where
should the [[html transformation]] link refer to? The src block? The
resulting image?

Best,
Ihor



Re: folding problems

2022-08-04 Thread Ihor Radchenko
"Fraga, Eric"  writes:

> Maybe unrelated but I will add that the recent changes to how local
> variables are processed is breaking my usage of org quite seriously.  To
> be clear: I am not complaining: it's my fault for tracking the bleeding
> edge of development for both org and Emacs.  But I thought I would
> mention what I am seeing just in case it's useful.
>
> An example: when exporting a long document which has many src blocks,
> each of those blocks is now being loaded and local variables (which
> include dir local variables) are being evaluated (which they were not
> before, I guess?).  I don't know if this is an org change or an Emacs
> change?
>
> The src blocks are likely loaded by org because I am using engraved for
> formatting the src blocks on export.  This is a nightmare if any of the
> variables are considered unsafe as it requires confirmation for each
> such case.
>
> And if some src block mode needs a special input method, this is causing
> the export to fail:
>
> activate-input-method: Can’t activate input method ‘TeX’
>
> although I am not sure, at this point, where/when this is happening.

If you have some time, can you try the attached patch?

> I will need to revert to an older version of org as I need to get work
> done. There's too much breaking to spend the time at the moment
> investigating.   But no worries: that's what git is for! 

Sorry for this. This is one of those innocently-looking changes that can
cause unforeseen consequences.

Best,
Ihor

>From 197bbbd91c54b28516ec6818f57bb07539fcfd9f Mon Sep 17 00:00:00 2001
Message-Id: <197bbbd91c54b28516ec6818f57bb07539fcfd9f.1659663319.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Fri, 5 Aug 2022 09:33:44 +0800
Subject: [PATCH] org-export: Do not try to load file/directory-locals in
 export buffer

* lisp/org.el (org-inhibit-local-variables): New variable controlling
loading file-local and directory-local variables when `org-mode' is
being loaded.
(org-mode): Use `org-inhibit-local-variables'.
* lisp/ox.el (org-export--generate-copy-script): Disable loading local
variables in the export buffer.

Fixes https://orgmode.org/list/87fsichwo0@ucl.ac.uk
---
 lisp/org.el | 5 -
 lisp/ox.el  | 8 ++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 9549ec5f0..12214ecbb 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4691,6 +4691,8 @@ (defvar org-element-cache-persistent); Defined in org-element.el
 (defvar org-element-use-cache); Defined in org-element.el
 (defvar org-mode-loading nil
   "Non-nil during Org mode initialisation.")
+(defvar org-inhibit-local-variables nil
+  "Unless nil, Org mode will not load file/directory-local variables.")
 ;;;###autoload
 (define-derived-mode org-mode outline-mode "Org"
   "Outline-based notes management and organizer, alias
@@ -4719,7 +4721,8 @@ (define-derived-mode org-mode outline-mode "Org"
 ;; Apply file-local and directory-local variables, so that Org
 ;; startup respects them.  See
 ;; https://list.orgmode.org/587be554-906c-5370-2cf2-f08b14fa5...@gmail.com/T/#u
-(hack-local-variables 'ignore-mode-settings)
+(unless org-inhibit-local-variables
+  (hack-local-variables 'ignore-mode-settings))
 (org-load-modules-maybe)
 (org-install-agenda-files-menu)
 (when (and org-link-descriptive
diff --git a/lisp/ox.el b/lisp/ox.el
index fa6f3f19a..57d375b35 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2623,8 +2623,12 @@ (defun org-export--generate-copy-script (buffer)
   (lambda ()
 	(let ((inhibit-modification-hooks t))
 	  ;; Set major mode. Ignore `org-mode-hook' as it has been run
-	  ;; already in BUFFER.
-	  (let ((org-mode-hook nil) (org-inhibit-startup t)) (org-mode))
+	  ;; already in BUFFER.  Ignore loading local variables as
+	  ;; well.
+	  (let ((org-mode-hook nil)
+(org-inhibit-startup t)
+(org-inhibit-local-variables t))
+(org-mode))
 	  ;; Copy specific buffer local variables and variables set
 	  ;; through BIND keywords.
 	  (pcase-dolist (`(,var . ,val) varvals)
-- 
2.35.1



Re: Tracking todo state changes AND automatically change to done when all children are done

2022-08-04 Thread Ihor Radchenko
Cletip Cletip  writes:

> So, can we consider this as a bug?

Yup. And the linked thread may be the fix or at least something close.

Best,
Ihor




Odd characters in the fast tags selection interface

2022-08-04 Thread Hanno

Hej,

I use the fast tags selection interface (=org-set-tags-command= with
=org-use-fast-tag-selection= set to =t=) to quickly add several tags to
a heading. I have both tags and keys defined in
=org-tag-persistent-alist= and use
=org-complete-tags-always-offer-all-agenda-tags= to complete the
selection with various other tags that I have used in my agenda files.

However, I have noticed some oddities with the characters that are being
associated as keys to the entries in the interface:

- after "a..z" runs out, '{', '|' and '}' are being used which seems
  reasonable -- but after that, I get '\200' and similar before reaching
  '©'...

- when defining my own keys, they are not displayed in the top; instead
  their characters are missing in the 'a'..'z' range leaving more room
  for odd and very difficult-to-type characters

I am therefore wondering: can I limit the range of characters being
used? Can I force characters defined in =org-tag-persistent-alist= to be
shown on top? Is this behavior maybe a bug?

The org version I am using is around 2 months old at this point I am afraid.

I attach an org-file that demonstrates the issue when opened with =emacs
-Q= and after evaluating the included source block.

Thanks and cheers,

Hanno


--
Hanno Perrey
https://hoowl.se


test_org-set-tags-command.org
Description: Lotus Organizer


Re: Internal link to resulting image from source block

2022-08-04 Thread reza
On 8/4/22 04:37, Ihor Radchenko wrote:
> 
> Nothing really wrong on your side. It is probably an omission on the Org
> sid >
> Executing the above code produces
> 
> #+RESULTS: html transformation
> [[file:img/transformation-html.svg]]
> 
> However, it is currently impossible to link to such results paragraph by
> itself - only to the parent src block. Since you are using :exports
> results, the export code does not "see" the src block; only the results
> block which cannot be referenced. Hence, the error.

I assumed it was something like this, but thank you for the clarification.
> They way to work around the problem is providing explicit name anchor to
> the results block:
> 
> 
> #+name: html transformation
> #+begin_src plantuml :file img/transformation-html.svg :exports results 
> :mkdirp yes
> file org
> file html
> org -> html : org-html-publish-to-html
> #+end_src
> 
> #+name: html transformation result
> #+RESULTS: html transformation
> [[file:img/transformation-html.svg]]
> 
> Now I want to include an internal link to this figure with [[html
> transformation result]]. This works now.
> 
> 
> Though I do agree that the current behaviour is not intuitive in this
> specific scenario. When a user provides :exports results, it would make
> sense to inherit all the affiliated keywords, including #+name and
> possibly various #+attr_* to the results of evaluation.
> 
> On the other hand, inheriting may be tricky. I can imagine situations
> when such inheritance is not desired and a user actually prefers to
> state the results keywords manually.
> 
> I am not sure what would be the best way to handle the situation at hand
> while not breaking the other :exports variants.

Shall I file a bug report? As a beginner I assumed that the name tag 
gets carried over to the result and I still think it is a sensible 
solution, but I could imagine that is perhaps not a very explicit behavior.

Cheers,
Reza


OpenPGP_0xC375C6AF05125C52.asc
Description: application/pgp-keys


OpenPGP_signature
Description: PGP signature


Re: folding problems

2022-08-04 Thread Fraga, Eric
Ihor,

folding is now fine.  But only by disabling (reverting) the early
loading of local file variables.  Which I'm doing as it was breaking too
many things.  Org is back to being usable.

-- 
Eric S Fraga, @ericsfraga:matrix.org, GnuPG: 0xc89193d8fffcf67d


Re: Tracking todo state changes AND automatically change to done when all children are done

2022-08-04 Thread Cletip Cletip
So, can we consider this as a bug?

Le jeu. 4 août 2022 à 17:01, Ihor Radchenko  a écrit :

> Cletip Cletip  writes:
>
> > Hello to all,
> >
> > I am trying to do what is in the title of this mail, but there is
> something
> > surprising:
> >
> > Everything works perfectly well, except when inserting statistics cookies
> > (for the parent obviously). Indeed, when changing the state of the
> subtask,
> > the lines like this :
> >
> > - State " new state" from "old state" [2022-08-04 Thu 16:09]
> >
> > are not saved under the subtask, but always under the main heading.
>
> This is likely related to
> https://orgmode.org/list/871qu8ccvr.fsf@localhost
> CCing Bhavin.
>
> > To reproduce this curious behavior, you only need this configuration:
>
> Confirmed.
>
> Something inside `org-todo' call in the hook triggers recursive-edit
> that, in turn, triggers premature call to post-command-hook containing
> note saving function.
>
> Best,
> Ihor
>


Re: folding problems

2022-08-04 Thread Fraga, Eric
Maybe unrelated but I will add that the recent changes to how local
variables are processed is breaking my usage of org quite seriously.  To
be clear: I am not complaining: it's my fault for tracking the bleeding
edge of development for both org and Emacs.  But I thought I would
mention what I am seeing just in case it's useful.

An example: when exporting a long document which has many src blocks,
each of those blocks is now being loaded and local variables (which
include dir local variables) are being evaluated (which they were not
before, I guess?).  I don't know if this is an org change or an Emacs
change?

The src blocks are likely loaded by org because I am using engraved for
formatting the src blocks on export.  This is a nightmare if any of the
variables are considered unsafe as it requires confirmation for each
such case.

And if some src block mode needs a special input method, this is causing
the export to fail:

activate-input-method: Can’t activate input method ‘TeX’

although I am not sure, at this point, where/when this is happening.

And, no, unfortunately I don't know if emacs -Q solves these issues.  I
did try and it does seem like the local variable aspect happens; it's
just that my export is so tailored that other things break for not being
defined in emacs -Q and so I cannot fully export my document.

I will need to revert to an older version of org as I need to get work
done. There's too much breaking to spend the time at the moment
investigating.   But no worries: that's what git is for! 

Thank you,
eric

PS -if any of the above is the fault of changes to Emacs, I will post on
the devel list.

-- 
: Eric S Fraga, with org release_9.5.4-706-g4702a7 in Emacs 29.0.50

Re: Tracking todo state changes AND automatically change to done when all children are done

2022-08-04 Thread Ihor Radchenko
Cletip Cletip  writes:

> Hello to all,
>
> I am trying to do what is in the title of this mail, but there is something
> surprising:
>
> Everything works perfectly well, except when inserting statistics cookies
> (for the parent obviously). Indeed, when changing the state of the subtask,
> the lines like this :
>
> - State " new state" from "old state" [2022-08-04 Thu 16:09]
>
> are not saved under the subtask, but always under the main heading.

This is likely related to
https://orgmode.org/list/871qu8ccvr.fsf@localhost
CCing Bhavin.

> To reproduce this curious behavior, you only need this configuration:

Confirmed.

Something inside `org-todo' call in the hook triggers recursive-edit
that, in turn, triggers premature call to post-command-hook containing
note saving function.

Best,
Ihor



Re: folding problems

2022-08-04 Thread Fraga, Eric
On Thursday,  4 Aug 2022 at 22:34, Ihor Radchenko wrote:
> Are you able to reproduce starting from emacs -Q?

No, I am not able to reproduce with -Q unfortunately.

I'll investigate when time permits.
Thank you,
eric

-- 
: Eric S Fraga, with org release_9.5.4-706-g4702a7 in Emacs 29.0.50

Re: folding problems

2022-08-04 Thread Ihor Radchenko
"Fraga, Eric"  writes:

> In the screenshot example, it seems to be part of the cache information
> on a results line from a src block in a subheading of the illustrative
> example:
>
> #+results[7dc3bf0b2288ae445ec4a381d3aabdc73515a957]: somesrcblock
>
> Most of my headings show similar hex strings (as most of my content
> includes src blocks and results).  I'm not sure what is responsible and
> haven't tried to track anything down yet but thought I would mention
> this issue.

Are you able to reproduce starting from emacs -Q?

I just tried the following example file, and it works just fine for me.

-
#+STARTUP: show3levels
* this level 1
** this level 2
*** this level 3
 this level 4
#+results[7dc3bf0b2288ae445ec4a381d3aabdc73515a957]: somesrcblock
-

Best,
Ihor



Tracking todo state changes AND automatically change to done when all children are done

2022-08-04 Thread Cletip Cletip
Hello to all,

I am trying to do what is in the title of this mail, but there is something
surprising:

Everything works perfectly well, except when inserting statistics cookies
(for the parent obviously). Indeed, when changing the state of the subtask,
the lines like this :

- State " new state" from "old state" [2022-08-04 Thu 16:09]

are not saved under the subtask, but always under the main heading.

To reproduce this curious behavior, you only need this configuration:

  (setq org-todo-keywords
'((sequence "TODO(t!)" "|" "DONE(d!)" )))

  (defun org-summary-todo (n-done n-not-done)
"Switch entry to DONE when all subentries are done, to TODO otherwise."
(let (org-log-done org-log-states) ; turn off logging
  (org-todo (if (= n-not-done 0) "DONE" "TODO"

  (add-hook 'org-after-todo-statistics-hook 'org-summary-todo)

;;(setq org-log-into-drawer t) ;;to have a logbook


and try on an org document like this one:


* TODO heading [0/1]

- State "DONE" from "TODO" [2022-08-04 Thu 16:09]

** TODO change the state of this heading !


My org-mode version is 9.5.2 (release_9.5.2-25-gaf6f12 @
/usr/share/emacs/28.1/lisp/org/).


Thank you in advance for your answers


Re: [PATCH] Re: the comment environment does not work for checkboxes

2022-08-04 Thread Ihor Radchenko
Uwe Brauer  writes:

>> See the attached patch.
>
> Are you going to commit that patch to master any time soon?
> I just pulled but cannot see it.

The patch task is scheduled for this Sunday.

> BTW, do you have any idea why columnview needs to many iterations if the 
> number of headings and parameters (I sent a bug report, but it seems a border 
> case, since nobody replied)

Sorry, I am not very familiar with columnview code. Hence, I did not
really investigate many of you patches hoping that someone else can
comment.

Best,
Ihor



folding problems

2022-08-04 Thread Fraga, Eric
Hello all,

Just a quick heads up: I have just built emacs from git and updated org
also from git.  Having changed my org files to remove

  (org-content 3)

lines from hooks and file local variables, replacing them with the
appropriate STARTUP setting, I am sort of back where I was except that
folding an org file shows a lot of garbage text.  See attached
screenshot where the heading is "** Illustrative example".  This
unexpected text was not visible before upgrading and the org file has
not changed except for the addition of the startup line and the deletion
of the org-content line.

In the screenshot example, it seems to be part of the cache information
on a results line from a src block in a subheading of the illustrative
example:

#+results[7dc3bf0b2288ae445ec4a381d3aabdc73515a957]: somesrcblock

Most of my headings show similar hex strings (as most of my content
includes src blocks and results).  I'm not sure what is responsible and
haven't tried to track anything down yet but thought I would mention
this issue.

Thank you,
eric

-- 
: Eric S Fraga, with org release_9.5.4-706-g4702a7 in Emacs 29.0.50


Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved

2022-08-04 Thread Max Nikulin

On 04/08/2022 17:04, Juan Manuel Macías wrote:

Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist'

improved.


Thank you, Juan Manuel. The patch looks like what I was trying to 
suggest. However I have not tried to implement fontenc on the top of it.



+   (format "\\1\\2%s}"
+   (or language language-ini-only))


Likely never variant is ideal. Maybe language should be always in :babel 
and :babel-ini-only should be boolean. I am not sure though that it will 
not make code more complex in other places, so feel free to ignore this 
comment.





Re: [PATCH] Re: the comment environment does not work for checkboxes

2022-08-04 Thread Uwe Brauer

> Uwe Brauer  writes:

> Thanks for the heads-up!
> Comment blocks are not supposed to contain Org markup, and thus it indeed
> makes sense to support them in org-edit-special and in structure
> templates.

> See the attached patch.

Are you going to commit that patch to master any time soon?
I just pulled but cannot see it.

BTW, do you have any idea why columnview needs to many iterations if the number 
of headings and parameters (I sent a bug report, but it seems a border case, 
since nobody replied)


Uwe 


smime.p7s
Description: S/MIME cryptographic signature


Re: ?bug in org-fold-core

2022-08-04 Thread Sharon Kimble
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ihor Radchenko  writes:

> Sharon Kimble  writes:
>
>> I now have this showing in my 'instructions.org'
>> =
>> # -*- coding: utf-8; mode: org -*-
>> #+STARTUP: show2levels
>>
>> # #+STARTUP: overview 
>> =
>>
>> This file seems to be showing most of the problems, and looking at it in 
>> 'org-lint' there are many problems. But this file is just some problems that 
>> I've found and their solutions, so it shows the wrong way
>> to do something and then the correct way.
>
> I am not sure if I understand what you mean. Can you explain in more details?

Sure. This is one entry where 'org-lint' shows as '533 Link to non-existent 
local file ":~/path/to/directory/"'

=
*** dired
# [[file+emacs:~/path/to/directory/]] ;;; opens dired at that directory
[[file::~/path/to/directory/]] ;;; opens dired at that directory
=

This is the full org-lint for my 'instructions.org' file -

=
   533 low   Link to non-existent local file ":~/path/to/directory/"
  3736 low   Possible incomplete block "#+BEGIN_SRC bash -n   ;; then put in 
code which will have line numbering done automatically, and end with"
  3737 low   Invalid block closing line "#+END_SRC ;; use '>
 14597 nil   Duplicate target <>
 14631 nil   Duplicate target >
 14636 nil   Duplicate target >
 14644 nil   Duplicate target >
 14652 nil   Duplicate target >
 14893 nil   Unknown fuzzy location " $(uname) == 'Darwin' "
 14905 nil   Unknown fuzzy location " -f "$venv/bin/activate" && -z 
"$VIRTUAL_ENV" "
 14929 nil   Unknown fuzzy location " $2 =~ $re "
=


>
>> Is it possible for it to have a file-only way of reverting to the old way of 
>> 'file-local variables' please? As it currently stands, no org-headings are
>> shown in the colours that other org-files are showing them, and its 
>> giving the appearance of org-mode not reading and displaying it!
>
> If you have no fontification, please update Org. This issue has been
> fixed in a yesterday's commit.
>

I'm now running using 'Org mode version 9.5.4 (release_9.5.4-706-g4702a7 @ 
/home/boudiccas/git/org-mode/lisp/)'. Is this the most recent version please? 
Git pull says that its up-to-date.

I'm not sure what you mean by 'no fontification'? The instructions file has the 
usual org-headings, and the occasional drawer. Can you elucidate please?

Thanks
Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.4
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLromkdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1uNYw//Yw1j9FtpRzQDKd/p
zseXcqZqfsQi6QeOHjtcpV9Mg2lNOa1kU0Ox/AJLS+4GCra3n/wOEJSyrqpHeNBA
TokS4J4FPowazROxCrlWU/PxSUN7y2MMOK++o3K6X6UG/l+m2xcZ0OqTsbQAxKgS
bEwQnvRr7kdD7FNMVtX18WUWjOvL+Ko2o7YylmlmR5W6q7z+J8dIapb7q2wYiD4u
7VQh9SdBQ4MY8rrOVJEhLqQY0hWXyr84fO2mE/jM8KLwQCdQN3fLw8E7d5Gc8gSV
BFMEltCAG5Go0/xxuJyuGZpNjw0Eeyib+J8DhocRoqQ3PIX/cNRIDOu2xe3QjO5A
eH2eDcSDegUvQvzY2CKOrLhfFiNkT3jdz6qnn8mM7j4aqtJc/xqjCIHp5xu37jcn
8EJ3M20rlA6g5lAYi6GeceUhYgqRoJeMZL9SLKODmsZU+zAwFzC7aW11YgCq8S5A
Iq4X1oOBX4Xx58Mzw/m8fRSsnh3wu1rWEgwqrLF0xdY6ctXFO8JKiSsMJ2iD535X
geLVFQV0bOW8YI0WO8WxwpML5jOD4zCl7KnxCk2kqRQmiVm/7vy4pHi87K61kyfp
caASYq96bedKQjdVyzGpf7wtfzMqSO4nQI7d6lh9K7oc9maIxplb7tDP8SQinRBe
OCi1dgS21t2aEEoCCAwS0Hlhbh0=
=uq5L
-END PGP SIGNATURE-



Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved

2022-08-04 Thread Juan Manuel Macías
Hi, Ihor,

Ihor Radchenko writes:

> Thanks! I have some minor comments on the patch.
>
>> From b06cdd45198f470a135efad2cd1d8b22ab7e2f22 Mon Sep 17 00:00:00
> 2001
>> From: Juan Manuel Macias 
>> Date: Sun, 31 Jul 2022 02:31:08 +0200
>> Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist'
> improved.
>
> No dot after the firs message line, please.
>
>> +  '(("am" . (:babel-ini-only "amharic" :polyglossia "amharic" :
> lang-name "Amharic"))
>> +("ar" . (:babel "arabic" :polyglossia "arabic" :lang-name
> "Arabic"))
>
> A simpler form would be
> ("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name
> "Amharic")
>
>> +"Alist between language code and corresponding properties, such
>> +as Babel/Polyglossia options and language names.
>
> The first line of the docstring should fit 80 characters and be a full
> sentence. It is needed to make sure that eldoc can display the short
> docstring in the message area.
>
>> +- `:poliglosia' the name of the language loaded by the Polyglossia
> LaTeX package
>
> `:polyglossia', I think.
>
>> +- `:babel-ini-only' the name of the language loaded by Babel
>> +  exclusively through the new ini files method.
>
> May we put some kind of reference to LaTeX docs here?
>
>> +  (let ((language (let* ((lang (plist-get info :language))
>> + (plist (cdr
>> + (assoc lang org-latex-language-alist
>> +;; Here the actual name of the LANGUAGE or LANG
> is used
>
> Please end the comment sentence with ".".

Thanks for your comments and patience, and sorry again for the typos.

I am attaching a new fixed version of the patch. If everything is ok, I
get down to work with the Manual and NEWS. I think it would be nice to
add a few usage examples, and some links to the Babel and Polyglossia
documentation.

Best regards,

Juan Manuel 


>From 3d67d46cfc3e2f4a8feab1fed0598912700118a6 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Thu, 4 Aug 2022 11:54:01 +0200
Subject: [PATCH] lisp/ox-latex.el: `org-latex-language-alist' improved

* (org-latex-language-alist): Alist between language code and
corresponding properties, such as Babel/Polyglossia options and
language names.  Each element of the list consists of a cons cell,
where car is the language code and cdr is a property list.
* (org-latex-guess-babel-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex-guess-polyglossia-language): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
* (org-latex--format-spec): Modified to adapt the function to
the new structure of `org-latex-language-alist'.
---
 lisp/ox-latex.el | 290 +++
 1 file changed, 140 insertions(+), 150 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index c56f9d347..69d01b9c7 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -173,110 +173,107 @@
 ;;; Internal Variables
 
 (defconst org-latex-language-alist
-  ;; TODO: replace this list with a property list (the actual
-  ;; implementation is not very robust).
-  '(("am" "amharic" "*")
-("ar" "arabic")
-("ast" "asturian" "*")
-("bg" "bulgarian")
-("bn" "bengali" "*")
-("bo" "tibetan" "*")
-("br" "breton")
-("ca" "catalan")
-("cop" "coptic" "*")
-("cs" "czech")
-("cy" "welsh")
-("da" "danish")
-("de" "ngerman" "german" "german")
-("de-at" "naustrian" "german" "austrian")
-("dsb" "lsorbian" "*")
-("dv" "divehi" "*")
-("el" "greek")
-("el-polyton" "polutonikogreek" "greek" "polytonic")
-("en" "american" "english" "usmax")
-("en-au" "australian" "english" "australian")
-("en-gb" "british" "english" "uk")
-("en-nz" "newzealand" "english" "newzealand")
-("en-us" "american" "english" "usmax")
-("eo" "esperanto")
-("es" "spanish")
-("es-mx" "spanishmx" "spanish" "mexican")
-("et" "estonian")
-("eu" "basque")
-("fa" "farsi")
-("fi" "finnish")
-("fr" "french")
-("fr-ca" "canadien" "french" "canadian")
-("fur" "friulan")
-("ga" "irish")
-("gd" "scottish")
-("gl" "galician")
-("he" "hebrew")
-("hi" "hindi")
-("hr" "croatian")
-("hsb" "uppersorbian" "sorbian" "upper")
-("hu" "magyar")
-("hy" "armenian" "*")
-("ia" "interlingua")
-("id" "bahasai" "*")
-("is" "icelandic")
-("it" "italian")
-("kn" "kannada" "*")
-("la" "latin")
-("la-classic" "classiclatin" "latin" "classic")
-("la-medieval" "medievallatin" "latin" "medieval")
-("la-ecclesiastic" "ecclesiasticlatin" "latin" "ecclesiastic")
-("lo" "lao" "*")
-("lt" "lithuanian")
-("lv" "latvian")
-("ml" "malayalam" "*")
-("mr" "maranthi" "*")
-("nb" "norsk" "norwegian" "bokmal")
-("nl" "dutch")
-("nn" "nynorsk" "norwegian" "nynorsk")
-("no" "norsk")
-("oc" "occitan")
-("pl" "polish")
-("pms" "piedmontese")
-("pt" "portuges")
-("pt-br" 

Re: ?bug in org-fold-core

2022-08-04 Thread Ihor Radchenko
Sharon Kimble  writes:

> I now have this showing in my 'instructions.org'
> =
> # -*- coding: utf-8; mode: org -*-
> #+STARTUP: show2levels
>
> # #+STARTUP: overview 
> =
>
> This file seems to be showing most of the problems, and looking at it in 
> 'org-lint' there are many problems. But this file is just some problems that 
> I've found and their solutions, so it shows the wrong way
> to do something and then the correct way.

I am not sure if I understand what you mean. Can you explain in more details?

> Is it possible for it to have a file-only way of reverting to the old way of 
> 'file-local variables' please? As it currently stands, no org-headings are
> shown in the colours that other org-files are showing them, and its 
> giving the appearance of org-mode not reading and displaying it!

If you have no fontification, please update Org. This issue has been
fixed in a yesterday's commit.

Best,
Ihor



Re: ?bug in org-fold-core

2022-08-04 Thread Sharon Kimble
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ihor Radchenko  writes:

> Sharon Kimble  writes:
>
>> I've just updated to 'Org mode version 9.5.4 (release_9.5.4-706-g4702a7 @ 
>> /home/boudiccas/git/org-mode/lisp/)' and I'm getting this error report from 
>> org-fold-core (I think) -
>>
>> =
>> Debugger entered--Lisp error: (error "Calling ‘org-fold-core-region’ with 
>> missing SPEC")
>>   signal(error ("Calling ‘org-fold-core-region’ with missing SPEC"))
>>   error("Calling `org-fold-core-region' with missing SPEC")
>>   org-fold-core-region(652018 652093 t outline)
>>   org-cycle-content--text-properties(2)
>>   org-content(2)
>>   eval((org-content 2) t)
>>   #f(compiled-function (var val) "Set local variable VAR with value VAL.\nIf 
>> VAR is `mode', call `VAL-mode' as a function unless it's\nalready the major 
>> mode." #)(eval (org-content 2))
>>   apply(#f(compiled-function (var val) "Set local variable VAR with value 
>> VAL.\nIf VAR is `mode', call `VAL-mode' as a function unless it's\nalready 
>> the major mode." #) (eval (org-content 2)))
>>   hack-one-local-variable(eval (org-content 2))
>>   hack-local-variables-apply()
>>   hack-local-variables(ignore-mode-settings)
>>   org-mode()
>
> This is not a bug. This is a changed behaviour of file-local variables.
> Now, they are loaded early before most of the Org setup is done in the
> buffer; before folding is configured. Hence, the error.
>
> Note that a proper setting of startup visibility should be done via
> #+startup keyword:
>
> #+STARTUP: show2levels
>
Thanks for replying.

I now have this showing in my 'instructions.org'
=
# -*- coding: utf-8; mode: org -*-
#+STARTUP: show2levels

# #+STARTUP: overview 
=

This file seems to be showing most of the problems, and looking at it in 
'org-lint' there are many problems. But this file is just some problems that 
I've found and their solutions, so it shows the wrong way
to do something and then the correct way. Is it possible for it to have a 
file-only way of reverting to the old way of 'file-local variables' please? As 
it currently stands, no org-headings are
shown in the colours that other org-files are showing them, and its giving 
the appearance of org-mode not reading and displaying it!

Thanks
Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.4
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLrk6kdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1sVEg/+P8SaFo8ahnpmiaIX
5Ckv5gS8KFIQOPE3cEX0pHs5d9RTHPJiHhGQ2CodgnqhAExU0ppvK3z4uIkmw6ln
YJoHhd/eLWAt2BpnktJ6TDHDIohdtG8ih8U1re5DqZMASSTPRBgsKhvadYMGHCU3
q5nYgfd26A0TB3i6qRgVPrlaUzGfMTM4TozI0KnuAoOa8IDh7dSRHMusZDsjNpuN
Z8TJN79rXxAkz6lSL5C1cgkykJqm1nG7zPdq09tdPIwuartBrnPsrHmAA6EFDOv2
hYpSh91AORaAV8/sSffyy7IX58DWDL6AQ+HBvWGtuR5f3xLV4mP3MnP3YF44DpTr
HeTdZt4KjPlpZSqcuv36Zko9k2idX1BNWHZCc0e7ZpTAGVP0j+s7qqycejrerZfR
R8L07O4uJ1sSZJJ8tupp9NnQMVpznvF5xxjfq7uG8pbIvM7eKbqpbJWMzea8949P
YM2zxcLa08fk6SeV27riK0Bm4R37ERuaPfZefFyxxsIWD4xH4elQqDQSvxQr7TZl
bv3R9Jm72jM+tEcWzh4dr1re/lErpvKJuWiTcuf5TtUwujY7wOIBSH8oPDxReeWE
GMMrybHjO7dk5TArCMkSGfYrDvgW6M8MB2BFeMeqJxZa8WJFnRkq3/Va1FQkLhGt
eDJF7uaJkx9e2t+OmcWxsI9MT5U=
=4yAA
-END PGP SIGNATURE-



Re: ?bug in org-fold-core

2022-08-04 Thread Ihor Radchenko
Sharon Kimble  writes:

> I've just updated to 'Org mode version 9.5.4 (release_9.5.4-706-g4702a7 @ 
> /home/boudiccas/git/org-mode/lisp/)' and I'm getting this error report from 
> org-fold-core (I think) -
>
> =
> Debugger entered--Lisp error: (error "Calling ‘org-fold-core-region’ with 
> missing SPEC")
>   signal(error ("Calling ‘org-fold-core-region’ with missing SPEC"))
>   error("Calling `org-fold-core-region' with missing SPEC")
>   org-fold-core-region(652018 652093 t outline)
>   org-cycle-content--text-properties(2)
>   org-content(2)
>   eval((org-content 2) t)
>   #f(compiled-function (var val) "Set local variable VAR with value VAL.\nIf 
> VAR is `mode', call `VAL-mode' as a function unless it's\nalready the major 
> mode." #)(eval (org-content 2))
>   apply(#f(compiled-function (var val) "Set local variable VAR with value 
> VAL.\nIf VAR is `mode', call `VAL-mode' as a function unless it's\nalready 
> the major mode." #) (eval (org-content 2)))
>   hack-one-local-variable(eval (org-content 2))
>   hack-local-variables-apply()
>   hack-local-variables(ignore-mode-settings)
>   org-mode()

This is not a bug. This is a changed behaviour of file-local variables.
Now, they are loaded early before most of the Org setup is done in the
buffer; before folding is configured. Hence, the error.

Note that a proper setting of startup visibility should be done via
#+startup keyword:

#+STARTUP: show2levels

Best,
Ihor



?bug in org-fold-core

2022-08-04 Thread Sharon Kimble
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've just updated to 'Org mode version 9.5.4 (release_9.5.4-706-g4702a7 @ 
/home/boudiccas/git/org-mode/lisp/)' and I'm getting this error report from 
org-fold-core (I think) -

=
Debugger entered--Lisp error: (error "Calling ‘org-fold-core-region’ with 
missing SPEC")
  signal(error ("Calling ‘org-fold-core-region’ with missing SPEC"))
  error("Calling `org-fold-core-region' with missing SPEC")
  org-fold-core-region(652018 652093 t outline)
  org-cycle-content--text-properties(2)
  org-content(2)
  eval((org-content 2) t)
  #f(compiled-function (var val) "Set local variable VAR with value VAL.\nIf 
VAR is `mode', call `VAL-mode' as a function unless it's\nalready the major 
mode." #)(eval (org-content 2))
  apply(#f(compiled-function (var val) "Set local variable VAR with value 
VAL.\nIf VAR is `mode', call `VAL-mode' as a function unless it's\nalready the 
major mode." #) (eval (org-content 2)))
  hack-one-local-variable(eval (org-content 2))
  hack-local-variables-apply()
  hack-local-variables(ignore-mode-settings)
  org-mode()
  set-auto-mode-0(org-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(# 
"~/.emacs.d/org/instructions.org" nil nil "~/.emacs.d/org/instructions.org" 
(34277755 2068))
  find-file-noselect("/home/boudiccas/.emacs.d/org/instructions.org")
  desktop-restore-file-buffer("/home/boudiccas/.emacs.d/org/instructions.org" 
"instructions.org" nil)
  byte-code("\10\11\236A\206\10\0\305\n\13\f#\207" [desktop-buffer-major-mode 
desktop-buffer-mode-handlers desktop-buffer-file-name desktop-buffer-name 
desktop-buffer-misc desktop-restore-file-buffer] 4)
  desktop-create-buffer(206 "/home/boudiccas/.emacs.d/org/instructions.org" 
"instructions.org" org-mode (auto-fill-mode abbrev-mode visual-line-mode 
override-global-mode anzu-mode auto-complete-mode TeX-PDF-mode 
highlight-symbol-mode global-auto-revert-mode org-indent-mode flyspell-mode 
yas-minor-mode undo-tree-mode hi-lock-mode guide-key-mode hungry-delete-mode 
which-key-mode flx-ido-mode ivy-mode wrap-region-mode google-this-mode 
org-autolist-mode project-persist-mode super-save-mode ivy-explorer-mode 
counsel-mode auto-capitalize) 13221 (13959 nil) nil nil ((indent-tabs-mode) 
(buffer-display-time 25316 54568 39118 551000) (buffer-file-coding-system . 
utf-8-unix) (truncate-lines)))
  eval-buffer(# nil 
"/home/boudiccas/.emacs.d/desktop/emacs.desktop" nil t)  ; Reading at buffer 
position 24870
  load-with-code-conversion("/home/boudiccas/.emacs.d/desktop/emacs.desktop" 
"/home/boudiccas/.emacs.d/desktop/emacs.desktop" t t)
  load("/home/boudiccas/.emacs.d/desktop/emacs.desktop" t t t)
  desktop-read()
  eval-buffer(# nil 
"/home/boudiccas/.emacs.d/config22.el" nil t)  ; Reading at buffer position 
478700
  load-with-code-conversion("/home/boudiccas/.emacs.d/config22.el" 
"/home/boudiccas/.emacs.d/config22.el" nil nil)
  load("/home/boudiccas/.emacs.d/config22.el" nil nil t)
  load-file("~/.emacs.d/config22.el")
  org-babel-load-file("~/.emacs.d/config22.org")
  eval-buffer(# nil "/home/boudiccas/.emacs.d/init.el" nil t)  
; Reading at buffer position 471
  load-with-code-conversion("/home/boudiccas/.emacs.d/init.el" 
"/home/boudiccas/.emacs.d/init.el" t t)
  load("/home/boudiccas/.emacs.d/init" noerror nomessage)
  startup--load-user-init-file(#f(compiled-function () #) #f(compiled-function () #) 
t)
  command-line()
  normal-top-level()
=

I've attempted to run bug-hunter-file against it, and its says that there are 
no problems with it, so I'm puzzled as to what's going on?

Is it a bug against org-fold-core, or something in my file, please?

Thanks
Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.4
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLrfdQdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1vsXg/9ENnsH0lYkYud0xkG
xnPVO8tvhky02beb0vXU8EEnEdz9Kl0xOnh8Jl0x7/Jfc4MG4dWjfEXSq2Axd4Pp
g83CH76gOYZvd+93X8RbzyoSr6QFtfH76o5i/RMh71LD9C1OpBKYasYuGjsKhyQy
lRBnYDL0UCGGbnm4OVI3iHUDhtPZBd248lRfTzDSpSW4Pn1RzjexTgRuyXwa7s01
Nqd/9u1/ihyZaxkRAuUA8eR2tpFSP/AyHdtf8U/7cy5afBhNj+mgrT3G8s1NjPAM
3ChowAt9ZgxVmQaTrxbSVHsh0HONJuOZtUARCJoOu7HAyb5imTSG5XqSZbALD6yF
OmrfA5c8VywXw738oiYCc3el8AvC3gVI6lrLDcQWGy7GFVUV+t7PjSf3MixeWY7p
9wLlthpMl3g6mL9On7+cZx4HTdeu+032PpsvaPdjvQLC3btnDBi3qf+/b/ym6bOs
mjI/T4YilYTbZQYSPILPX94j4MDWrb6U4N5iWbLFrZjAqsURJiIi5OG99nsRfcau
pY8bJDfJWDs9C5UrdYvMQxj0L2z0dAfmaufFi6thuhf5bG64QvE/37UwihxYczT8
YsXI7H2GtjIxzKQBLYy1NJRTI8l7b0NaoP8oa/P9jAT3ZLcn5EcUIiX3fgYUiDjW
ckOssPZPNISplNF3IARIOEAhfrs=
=O87p
-END PGP SIGNATURE-