org-fold-core-region error: missing SPEC

[420actionunits]

I get the following stack trace when calling ORG-JIRA-GET-ISSUES from
org-jira I also get it from similar calls from ejira. After looking at
the code I think it's a problem in org and org-fold.

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-region(1312 1318 t outline)
  org-insert-property-drawer()
  org-get-property-block(1222 force)
  org-entry-put(1286 "assignee" "Carlos Konstanski")
  org-jira-entry-put(1286 "assignee" "Carlos Konstanski")
  org-jira--render-issue(#)
  mapc(org-jira--render-issue (# ...))
  org-jira--render-issues-from-issue-list((# ...))
  org-jira-get-issues((# 
...))
  #f(compiled-function ( rest) "Callback for async, DATA is the response 
from the request call.\n\nWill send a list of org-jira-sdk-issue objects to the 
list printer." #)(:data (... ... ... ... ...) 
:symbol-status success :error-thrown nil :response #s(request-response 
:status-code 200 :history nil :data ... :error-thrown nil :symbol-status 
success :url "https://ololab...; :done-p nil :settings ... :-buffer # :-raw-header "HTTP/2 200 \nda..." :-timer nil :-backend curl))
  apply(#f(compiled-function ( rest) "Callback for async, DATA is the 
response from the request call.\n\nWill send a list of org-jira-sdk-issue 
objects to the list printer." #) (:data ... 
:symbol-status success :error-thrown nil :response ...))
  request--callback(# :sync nil :headers (... ...) :parser 
jiralib--json-read :complete #f(compiled-function ( rest) "Callback for 
async, DATA is the response from the request call.\n\nWill send a list of 
org-jira-sdk-issue objects to the list printer." #) :error (lambda ... "\n\n(fn  DAT..." ...) :type "POST" 
:data ...)
  apply(request--callback # (:sync nil :headers 
(("Authorization" . "Basic Y2FybG9zLmtvbnN0YW5z...") ("Content-Type" . 
"application/json")) :parser jiralib--json-read :complete #f(compiled-function 
( rest) "Callback for async, DATA is the response from the request 
call.\n\nWill send a list of org-jira-sdk-issue objects to the list printer." 
#) :error (lambda ( --cl-rest--) "\n\n(fn 
 DATA " (apply ... ... ... --cl-rest--)) :type "POST" :data 
"{\"jql\":\"assignee = current..." :url "https://ololabs.atlassian; 
:response #s(request-response :status-code 200 :history nil :data (... ... ... 
... ...) :error-thrown nil :symbol-status success :url 
"https://ololabs.atlassian; :done-p nil :settings #3 :-buffer # :-raw-header "HTTP/2 200 \ndate: Sat, 27 ..." :-timer nil :-backend 
curl) :encoding utf-8))
  request--curl-callback("https://ololabs.atlassian.net/rest/api/2/search; 
#> "finished\n")
  apply(request--curl-callback 
("https://ololabs.atlassian.net/rest/api/2/search; #> 
"finished\n"))
  #f(compiled-function ( args2) #)(#> "finished\n")

I set a breakpoint at the beginning of function
ORG-FOLD-CORE-GET-FOLDING-SPEC-FROM-ALIAS. It runs quite a few times
successfully. Every time the input argument SPEC-OR-ALIAS has one of
these values: 'ORG-FOLD-VISIBLE or 'ORG-FOLD-HIDDEN. But at some point
the function runs with a value of 'DRAWER, and that's when it returns
NIL and the error is thrown higher up in ORG-FOLD-CORE-REGION when it
explicitly tests for a NIL result.

ORG-FOLD-CORE--SPEC-SYMBOLS has the value:

((HIDDEN . ORG-FOLD-HIDDEN) (:ALIAS . ORG-FOLD-HIDDEN)
(ORG-FOLD-HIDDEN . ORG-FOLD-HIDDEN) (VISIBLE . ORG-FOLD-VISIBLE)
(:ALIAS . ORG-FOLD-VISIBLE) (ORG-FOLD-VISIBLE . ORG-FOLD-VISIBLE))

But when a drawer wants to be added we call ORG-FOLD-REGION like this:

(ORG-FOLD-REGION (LINE-END-POSITION 0) (POINT) T (IF (EQ
ORG-FOLD-CORE-STYLE 'TEXT-PROPERTIES) 'DRAWER 'OUTLINE))

It will pass in either 'DRAWER or 'OUTLINE, neither of which are valid
given the alist they need to match against.

It would seem that any execution path that goes through
ORG-INSERT-PROPERTY-DRAWER is going to fail.

I'm still unclear on how ORG-FOLD-CORE--SPEC-SYMBOLS gets set with
this alist. Is there is an opportunity for callers to customize it?
What would be appropriate values to add for 'DRAWER and 'OUTLINE?


Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.17.8, Xaw3d scroll bars)
 of 2023-05-27
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/usr/share/emacs/30.0.50/lisp/org/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change 

[BUG] lisp/org-eldoc.el: Eldoc does not work in org source blocks

[Bruno Cardoso]

Hello everyone.

The Eldoc interface `eldoc-print-current-symbol-info' works everywhere just 
fine for me (Emacs
28.2), but it does not work inside org source blocks for elisp code. Yet, 
reverting to the
obsolete `elisp-eldoc-documentation-function' in org-eldoc's
`org-eldoc-documentation-function' works (see below). I tested it both in my 
own config and
"emacs -Q" with same results.

---
 lisp/org-eldoc.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org-eldoc.el b/lisp/org-eldoc.el
index 7137c46..24f0aa3 100644
--- a/lisp/org-eldoc.el
+++ b/lisp/org-eldoc.el
@@ -156,7 +156,8 @@
(fboundp 'elisp-eldoc-funcall))
   (let ((eldoc-documentation-functions
  '(elisp-eldoc-var-docstring elisp-eldoc-funcall)))
-(eldoc-print-current-symbol-info)))
+;;(eldoc-print-current-symbol-info)))
+(elisp-eldoc-documentation-function)))
  ((fboundp 'elisp-eldoc-documentation-function)
   (elisp-eldoc-documentation-function))
  (t; Emacs<25
-- 
2.40.1


Is this in fact a bug or should I have configured something else?

Best,

Bruno.

Editing begin_verse using edit special

[Bernt Hansen]

Hi,
I use #+begin_verse
For certain blocks in my org files 

Is there a way to allow C-c ‘ to edit this block in fundamental mode?

I always get an error that there is ‘no special evironment to edit here’ when 
trying to do C-c ‘ on a verse block

Thanks,
Bernt

Editing begin_verse using edit special

[Bernt Hansen]

Hi,
I use #+begin_verse
For certain blocks in my org files 

Is there a way to allow C-c ‘ to edit this block in fundamental mode?

I always get an error that there is ‘no special evironment to edit here’ when 
trying to do C-c ‘ on a verse block

Thanks,
Bernt

Re: Preserving leading zeros

[tomas]

On Sun, May 28, 2023 at 01:50:15PM -0400, William Denton wrote:
> On 28 May 2023, Berry, Charles wrote:
> 
> > Have you considered http://gewhere.github.io/org-bibtex ??
> > 
> > Or using the approach therein, viz. use properties to store bib data in org?
> 
> That would be great for a smaller bibliography, but I'm dealing with over
> 2,400 books [...]

> |   isbn | title| pub_date |
> |+--+--+
> | 0006145396 | A Buyer's Market | 1952 |

Perhaps not very elegant, but sticking "ISBN" in front of that would work.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Preserving leading zeros

[William Denton]

On 28 May 2023, Berry, Charles wrote:


Have you considered http://gewhere.github.io/org-bibtex ??

Or using the approach therein, viz. use properties to store bib data in org?


That would be great for a smaller bibliography, but I'm dealing with over 2,400 
books.  They're in a simple database now, with a web front end I wrote over 
twenty years ago in Perl.  Amazingly it's worked ever since, maybe with one fix 
required along the way, but some update to a library or package broke it 
recently and I haven't figured out why yet.  Even if I do, I'm thinking it's 
time to get away from that code.


I don't feel like getting into the overhead of writing a new web-based system, 
so I might try managing the database through Org with R.  I was thinking I might 
add a new book by having a table like this, which the code would read and 
operate on:


|   isbn | title| pub_date |
|+--+--+
| 0006145396 | A Buyer's Market | 1952 |

I guess I could have the code pad the left with zeros if the ISBN is a number 
with fewer than 10 digits.  That way I'd see the right ISBN on the screen, and 
if Emacs removes the zeros they get put back before it's added to the 
catalogue.


Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
CO₂: 424.57 ppm (Mauna Loa Observatory, 2023-05-27)

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Rudolf,

Thanks for testing the branch :)

> ISSUE 1: CLIPPING
>
> On my HiDPI screen, the new previews are clipped slightly at the edges.
> I had this issue before and fixed it in [1][2].  Has the same bug crept
> back?
>
> [1] 
> 
> [2] 
> 

We’re thinking of adding `--exact-bbox' to the default `dvisvgm' flags, which it
seems has a good chance of resolving this. It was originally swapped for
`--bbox=preview' (when using `dvisvgm' to get dimension info), but now we do 
this
via the LaTeX compilation stdout, and so we can go back to `--exact-bbox'.

> ISSUE 2: TIKZ
>
> I use LaTeX Babel blocks for TikZ, and these stopped working.  From the
> *Messages* buffer:
>
> Executing Latex unknown at position 846…
> Processing LaTeX file 
> /var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.tex…
> Compiling 
> /var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.tex…
> org-compile-file: File 
> “/var/folders/ky/8r5j3qz55hb94lpg1jr9vl1cgn/T/babel-ntjCLq/latex-aGIYEN.svg”
>  wasn’t producedorg babel latex failed
> PDF file produced.
>
> The linked LaTeX file compiles without errors, and a PDF file with
> correct content sits next to it.  Perhaps the preview system needs to
> wait longer?

Hmmm, not sure what’s going on. Care to provide a MWE?

> [Also notice the missing space in “producedorg”.]
>
> It would be *FABULOUS* if this patch-set could also make ’ob-babel’ use
> the same mechanism as the new previews, ’dvisvgm’ (TeX to DVI to SVG)
> instead of Inkscape (TeX to PDF to SVG).  It would fix, for example,
> scaling.  On my system, LaTeX Babel outputs everything at half of the
> correct size, and I cannot convince Inkscape to scale up to save my
> life.  The previews and ’dvisvgm’ work as expected, conversely.

The hard part was the overhauled machinery, hooking up the new system to
ob-babel should be possible without too much hassle. It might need to wait for
another patch-set though (this one is already at ~100 commits and a few thousand
lines changed).

> It would be *SUPER-FABULOUS* if the new previews worked with TikZ out of
> the box, as per the Org manual saying “any LaTeX environment is handled”
> [1] when not using MathJax.  Currently, PGF plots show as “blobs of
> letters” and the simplest TikZ pictures, such as
>
> \begin{tikzpicture}
>   \filldraw (0, 0) circle[radius = 1cm];
> \end{tikzpicture}
>
> make the preview system choke with
>
> error in process filter: org-latex-preview–svg-make-fg-currentColor: Wrong 
> type argument: stringp, nil
> error in process filter: Wrong type argument: stringp, nil

I tried this example on my computer, and it worked flawlessly (see
). If you could give me a stacktrace, that might help.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: Preserving leading zeros

[Berry, Charles]

William,

Have you considered http://gewhere.github.io/org-bibtex ??

Or using the approach therein, viz. use properties to store bib data in org?

HTH,
Chuck

> On May 28, 2023, at 7:46 AM, William Denton  wrote:
> 
> I'm thinking about moving a personal library catalogue system into Org.  This 
> would involve ISBNs, and when ISBNs had 10 digits some would have leading 
> zeros. It turns out leading zeros are removed when something looks like a 
> number.
> 

[snip]

Preserving leading zeros

[William Denton]

I'm thinking about moving a personal library catalogue system into Org.  This 
would involve ISBNs, and when ISBNs had 10 digits some would have leading zeros. 
It turns out leading zeros are removed when something looks like a number.


#+name:isbn
| 0006145396 |

#+begin_src shell :results output :var string=isbn
echo $string
#+end_src

#+RESULTS:
: 6145396

I looked at org-babel-read, which calls org-babel--string-to-number ("If STRING 
represents a number return its value"), so it looks like that's always going to 
happen.


I could use a hack like prepending an X and then removing it later, but that's a 
bit ugly.  Has anyone had this problem and worked around it some other way?




Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
CO₂: 424.57 ppm (Mauna Loa Observatory, 2023-05-27)

Re: [FR] Please add environment variable substitution in `org-display-inline-images'

[General discussions about Org-mode.]

Pan Xie  writes:

> So my proposal of the code change would be (find "pxie" in the codes):

Thanks for proposing a change.  It would be best if you produced a patch
file from this :) But someone with a bit more free time could do that as
well.

This is just FYI, and by no means a big deal, but it would become a huge
burden for the maintainers to apply the proposed changes if the
changeset becomes larger.

For future reference, I'm talking about something like this (assuming
you have git and a shell supporting IO redirect):

$ git diff this-file.el > something.diff

, or even better:

$ git commit -m commit-message...
$ git format-patch ...

In either case, you would attach the generated file in your message.

See also https://orgmode.org/worg/org-contribute.html for details.

-- 
Best,


RY

[FR] Please add environment variable substitution in `org-display-inline-images'

[Pan Xie]

Hello,

I recently found that the environment variable substitution does not
apply to inline image paths. Supposing I use a path
“/home/pxie/$Gallery/” to store all my image files, “$Gallery”
should be substituted with its corresponding value. The file link DOES
substitute the environment variables, but inline image paths not. So I
think it is a reasonable demand for the consistency.

It is also very important for my and other users' (I strongly believe)
configurations. Environment variable is the key abstraction to make
the same org document works on different machines with different path
hierarchies.

I hunt down the codes and find just one line change can fix that. In
`org-display-inline-images' function, add `substitute-in-file-name' to
the `expand-file-name' call. I can override the function with the
solution but I hope it can be added to the official codes.

So my proposal of the code change would be (find "pxie" in the codes):

#+begin_src elisp
(defun org-display-inline-images ( include-linked refresh beg end)
  "Display inline images.

An inline image is a link which follows either of these
conventions:

  1. Its path is a file with an extension matching return value
 from `image-file-name-regexp' and it has no contents.

  2. Its description consists in a single link of the previous
 type.  In this case, that link must be a well-formed plain
 or angle link, i.e., it must have an explicit \"file\" type.

Equip each image with the key-map `image-map'.

When optional argument INCLUDE-LINKED is non-nil, also links with
a text description part will be inlined.  This can be nice for
a quick look at those images, but it does not reflect what
exported files will look like.

When optional argument REFRESH is non-nil, refresh existing
images between BEG and END.  This will create new image displays
only if necessary.

BEG and END define the considered part.  They default to the
buffer boundaries with possible narrowing."
  (interactive "P")
  (when (display-graphic-p)
    (when refresh
  (org-remove-inline-images beg end)
  (when (fboundp 'clear-image-cache) (clear-image-cache)))
    (let ((end (or end (point-max
  (org-with-point-at (or beg (point-min))
    (let* ((case-fold-search t)
       (file-extension-re (image-file-name-regexp))
       (link-abbrevs (mapcar #'car
             (append org-link-abbrev-alist-local
                 org-link-abbrev-alist)))
       ;; Check absolute, relative file names and explicit
       ;; "file:" links.  Also check link abbreviations since
       ;; some might expand to "file" links.
       (file-types-re
    (format 
"\\[\\[\\(?:file%s:\\|attachment:\\|[./~]\\)\\|\\]\\[\\(
        (if (not link-abbrevs) ""
          (concat "\\|" (regexp-opt link-abbrevs))
      (while (re-search-forward file-types-re end t)
    (let* ((link (org-element-lineage
          (save-match-data (org-element-context))
          '(link) t))
   (linktype (org-element-property :type link))
       (inner-start (match-beginning 1))
       (path
        (cond
     ;; No link at point; no inline image.
     ((not link) nil)
     ;; File link without a description.  Also handle
     ;; INCLUDE-LINKED here since it should have
     ;; precedence over the next case.  I.e., if link
     ;; contains filenames in both the path and the
     ;; description, prioritize the path only when
     ;; INCLUDE-LINKED is non-nil.
     ((or (not (org-element-property :contents-begin link))
          include-linked)
      (and (or (equal "file" linktype)
   (equal "attachment" linktype))
           (org-element-property :path link)))
     ;; Link with a description.  Check if description
     ;; is a filename.  Even if Org doesn't have syntax
     ;; for those -- clickable image -- constructs, fake
     ;; them, as in `org-export-insert-image-links'.
     ((not inner-start) nil)
     (t
      (org-with-point-at inner-start
        (and (looking-at
          (if (char-equal ?< (char-after inner-start))
              org-link-angle-re
            org-link-plain-re))
         ;; File name must fill the whole
         ;; description.
         (= (org-element-property :contents-end link)
            (match-end 0))
         (match-string 2)))
      (when (and path (string-match-p file-extension-re path))
    (let ((file (if (equal "attachment" linktype)
            (progn
  (require 'org-attach)
              (ignore-errors (org-attach-expand path)))
;;; {{{ pxie changes begin
  (expand-file-name 
(substitute-in-file-name path)

;;; }}} pxie changes end
      (when (and file 

Re: org-mode for package documentation

[Payas Relekar]

Björn Bidar  writes:

> Philip Kaludercic  writes:
>
>> Christopher Dimech  writes:
>>
>>> Dear Compeers,
>>>
>>> Some months ago there had been a discussion about using org-mode
>>> to produce package documentation.  Which would allow the use of
>>> Latex3 (e.g. use of colour, floating images).
>>
>> Where/when did this happen?  Could you provide a few pointers?
>
> I don't know exactly but when use-package was merged into Emacs there
> were discussions if keeping the documentation in org-mode format is
> fine.
>
> From what I understood it is possible.

IIRC, Richard Stallman said he'd be amenable to it, _provided that_ Org
fulfilled all the requisite functionality from Texinfo.

Ihor (org maintainer) was also receptive, but I don't remember if/how
much progress happened towards the goal.

--

Re: org-mode for package documentation

[Philip Kaludercic]

Björn Bidar  writes:

> Philip Kaludercic  writes:
>
>> Christopher Dimech  writes:
>>
>>> Dear Compeers,
>>>
>>> Some months ago there had been a discussion about using org-mode
>>> to produce package documentation.  Which would allow the use of  
>>> Latex3 (e.g. use of colour, floating images).
>>
>> Where/when did this happen?  Could you provide a few pointers?
>
> I don't know exactly but when use-package was merged into Emacs there
> were discussions if keeping the documentation in org-mode format is
> fine.
>
> From what I understood it is possible.

Using org-mode to generate TeXinfo manuals is already possible, due to
the ox-texinfo backend, but I haven't been personally that satisfied
with the quality of the output, due to the lack of (easy) support for
the fine distinctions in markup that texinfo provides.  That is why the
use-package documentation had to be translated from org-mode to texinfo,
which was part of the reason the process of merging took so long.