Re: [PATCH] Avoid crash in `org-file-contents' in case of network failure

[Damien Cassou]

Hi Ihor,

thank you for your review.

Ihor Radchenko  writes:
> According to our records in https://orgmode.org/worg/contributors.html,
> you haven't signed FSF copyright agreement. May you add a TINYCHANGE
> cookie to the commit message as required by
> https://orgmode.org/worg/org-contribute.html#first-patch


I've signed the FSF copyright agreement in the context of my
contributions to Emacs. Do I need to do any more paperwork?

I've added TINYCHANGE to the patch anyway.



>> +(error (if noerror
>> +   (message "%s %S" (car error) (cdr error))
>> + (signal (car error) (cdr error)
>
> I think that it will be a good idea to indicate in the `message' where
> the error is coming from. The error intercepted by this `condition-case'
> form will likely be a network error, and it may be unclear to the user
> which function is failing to make the connection.

I tried to make that a little bit clearer:

  (message "Org could't download \"%s\": %s %S" file (car error) (cdr
  error))

Do you want me to explicitly refer to the current function name?

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

tex export overshoots right margin with mixed fonts

[Rob Sargent]

Looks to me like this only happens if the last word of the line is 
"emphasized" and larger font.


I'm using emacs 28, org 9.5.5

#+OPTIONS: author:nil
#+OPTIONS: toc:nil
#+OPTIONS: date:nil
#+OPTIONS: ^:nil

#+LaTeX_HEADER: \usepackage[T1]{fontenc}
#+LaTeX_HEADER: \usepackage{libertine}
#+LATEX_HEADER: \usepackage[margin=0.70in]{geometry}
#+LATEX_HEADER: \usepackage{setspace}
#+LATEX_HEADER: \usepackage{enumitem}
#+LaTeX_HEADER: \usepackage{endnotes}

#+ATTR_LATEX: :options [noitemsep, nolistsep]
#+ATTR_LATEX: :options frame=single,backgroundcolor=\color{lightgray}

* Database Retooling
** Mapping instructions
A feature (or is it a bug) of the current processing is the "look ahead" 
feature which
scans the _=MappingInstruction=_ table for instructions "related" to the 
one in hand.  Any
found are processed along with the instruction in hand.  It was found 
that looking ahead
when there /too many/ instruction became too expensive. To guard against 
that, "extra"
records are moved to _=MappingQueue=_ table (and back again) to keep 
_=MappingInstruction=_
under approximately 5000 records.  This to-and-fro happens on a five 
minute interval,

external to the =Resolve= application.

Re: [POLL] Naming of "export features"

[Sébastien Miquel]

Hi,

Ihor Radchenko writes:

What I have in mind is an ability to parametrize the transcoders like
the following:

(org-export-define-backend 'html
  '((paragraph . ((paragraph-is-a-link? figure-transcoder :name figure)
  (:unless 'figure paragraph-transcoder
  :transcoder-conditions
  '((paragraph . ((paragraph-is-a-link? (lambda (paragraph contents 
info)...))

Several ideas in the above:
1. Name features as "transcoder conditions"
2. The transcoder conditions are now linked to specific Org AST element.
They may not only be matched against the whole parse tree + whole raw
Org text, but also against the specific branch of AST + chunk of raw
Org text corresponding to the branch + the actual exported contents
of the AST children.
3. "feature implementations" are no longer needed. Instead, export
transcoders can contain the implementation lists inline. Each
implementation is selected not only depending on the presence of the
"feature"/transcoder condition, but also depending on multiple
features or arbitrary lisp expression results.
4. :when/:prevents apply to specific (possibly named) implementations.
This makes more sense than matching against feature.
For example, presence of svg images in latex export may or may not
mean that \usepackage{svg} is being used, depending on svg
implementation. We want to match against \usepackage{svg}
specifically rather than only against the presence of svg images.


What benefits does that bring over making enabled features available in 
=info= for the usual transcoders and advising them ?


Your initial example of adding a comment to the end and beginning of the 
document can be done by advising, say, =org-latex-template= and 
concatenating some strings with its =content= argument.


--
Sébastien Miquel

Re: [POLL] Naming of "export features"

[Ihor Radchenko]

"Bruce D'Arcus"  writes:

> I'm not really following this discussion, but is this perhaps similar
> to pandoc/djot's notion of "filters"?
>
> https://github.com/jgm/djot.js#filters

Nope. Filters are org-export-filters-alist.

What we are talking about is a generic way to test Org buffer contents +
AST and including/not including something into export output according
to the test result.

Like,

1. If there are images in Org source, include image-related CSS into
   resulting html
2. If exported paragraph consists of a single image, export it as latex
   "figure" environment. Otherwise, export as proper paragraph.
3. If we include \usepackage{foo} in latex export, there is no need to
   \usepackage{bar} because "foo" loads "bar" anyway.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.

[Karl Fogel]

On 23 Feb 2023, Max Nikulin wrote:

On 23/02/2023 00:01, Karl Fogel wrote:

  (when (not (keymap-lookup nil "C-"))
    (keymap-local-set "C-" 'org-fold-hide-subtree))
So FWIW C- is not bound in Org Mode buffers for me, in 
Emacs

30.x (i.e., recent development builds).


lisp/tab-bar.el:130:  (unless (global-key-binding [(control 
tab)])
lisp/tab-bar.el:131:(global-set-key [(control tab)] 
#'tab-next))


Minibuffer file cache completion should not be relevant to Org 
buffers.


Ah, I don't use tab-bar at all (at least not as far as I know), so 
I'm not 100% sure what the above is saying.


Are you saying that the only current default binding for C- 
in Emacs is that one in tab-bar.el, and therefore we should feel 
free to rebind it in Org Mode?  If so, we should still be 
cautious, since Emacs has policies for maintaining the keybinding 
space.  Generally, the space "C-c C-" is reserved for 
major modes, so ideally we should find something in there if we 
can -- although Org Mode has used up a lot of that space already 
:-), so I'm not sure what's left, unless we decide to swap out 
some existing binding in favor of this one.


(I realize this contradicts what I said in my inital post.  I had 
forgotten that C- was not part of the mode-reserved space.)


Best regards,
-Karl

Re: Re: [POLL] Naming of "export features"

[Pedro Andres Aranda Gutierrez]

No Wayman writes:
> It appears context is king.
> All that aside, I think Ihor's proposal sidesteps the whole issue
> while addressing the complexity of the implementation.

I read
#+cite_export: processor_x options:blablabla
as
"When I want to export citations using 'processor_x' , add options
blablabla to it"

That gives enough context information, IMvHO.
And it hides the implementation specifics ...

/P
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

How to build an agenda view showing all entries whose headlines match a given regex?

[Marcin Borkowski]

Hi all,

the topic says it all.  Is it possible?  If so, how?

TIA,

-- 
Marcin Borkowski
http://mbork.pl

Re: [POLL] Naming of "export features"

[No Wayman]

Timothy  writes:

I hadn’t thought of applying the term “enrichment”. That or 
adaptation could be
a good fit. I think I like the sound of “enriching the export”, 
and I could
probably also be sold on “export adaptation” / “adaptive 
export”.


Both are horribly abstract in my opinion.
If the aim is to sound overly technical and vague, we should take 
a page from web design and call it "progressive export 
enhancements". /s

Re: [POLL] Naming of "export features"

[No Wayman]

Ihor Radchenko  writes:

I am looking at the concept again, and I feel that we may be 
missing
some flexibility here. I do not like the fact that each feature 
can only

have a simple implementation within specific backend.


Agreed


What I have in mind is an ability to parametrize the transcoders


This seems like a step in the right direction.

Re: [POLL] Naming of "export features"

[Bruce D'Arcus]

On Wed, Feb 22, 2023 at 7:23 AM Ihor Radchenko  wrote:
>
> Timothy  writes:
>
> > Here is a list of terms which I’d feel comfortable applying to the system:
> > ⁃ export features
> > ⁃ export capabilities
> > ⁃ export snippets
>
> I am looking at the concept again, and I feel that we may be missing
> some flexibility here. I do not like the fact that each feature can only
> have a simple implementation within specific backend.

I'm not really following this discussion, but is this perhaps similar
to pandoc/djot's notion of "filters"?

https://github.com/jgm/djot.js#filters

Bruce

Re: [POLL] Naming of "export features"

[No Wayman]

And to add:

https://books.google.com/ngrams/graph?content=adaption%2Cadaptation%2Ccontext%2Cenhancement%2Cenrichment%2Cfeature_start=1800_end=2019=en-2019=3

It appears context is king.
All that aside, I think Ihor's proposal sidesteps the whole issue 
while addressing the complexity of the implementation.

Re: [POLL] Naming of "export features"

[No Wayman]

⁃ Providing capabilities via snippets can be framed as akin to 
dynamically

  gaining a feature.


I understand some snippets may be used to, for example, include a 
latex package.
However, it's not a requirement that a snippet "add a 
feature/capability" to a document.
What that snippet does depends entirely on the context of the 
export (a latex snippet will not "do" anything if inserted in an 
HTML doc).
What if I want to add some metadata or a string like "Hi, Mom" in 
the preamble of the document? Would it be reasonable to say the 
document has had the "secret mom greeting" capability added, or is 
that an overly complicated way of framing it?

Is the snippet required to have a side-effect on the document?

On the obverse, the snippets are always being added depending on 
the context of the export.
`ox-contextual-snippets` is a much more concrete name than any of 
the others proposed.


Both components are crucial to the overall system, however if 
anything I view
the latter as more important and so am not a fan of describing 
this system as

“export contexts”.


How is the latter more important if it depends on the former?

As I mentioned off list, I think naming is only part of the 
problem.

The design and API are currently over-engineered.
That should be discussed before worrying about the name.

Re: Re: [BUG] #+cite_export: ... bibstyle citestyle cannot be universally used as global defaults (was: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite)

[Pedro Andres Aranda Gutierrez]

Soory for the re-post... Just setting up a new email client

On Sun, 5 Feb 2023 00:14:59 +0100 (CET) Edgar wrote:
> Dear Ihor,
> On Feb 4, 2023 at 12:31 PM, Ihor Radchenko  wrote:Edgar 
> Lux  writes:
>> For example, ... the proposed idea is
>> a bit awkward:
>>
>> ...
>> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style[...]
>> citation-style[...]
>>
>> I assumed that there is one "major" bibliography-style/citation-style.
>> However, it is not really the case in practice. The styles are combined.
> First of all, I quickly glanced at the other citation processors, and they 
> seem to have been implemented with a different design in Org. This *may* have 
> to do with biblatex being more advanced (disclaimer: I'm not saying that it 
> actually is, it's a possibility only).
> If the idea is that all processors are going to get the same syntax, I think 
> that the implementation may not suit one of them. At that point, it may be 
> that the filters will have to be adapted to specific processors in contrived 
> ways. This of course will be much dependent on the choice of processors 
> chosen to be supported by Org. Some other groups may decide to implement, for 
> example, the JabRef #+cite_export (this does not imply that JabRef is a 
> citation processor, it's just a colourful example).
>> For example, adding links to bibliography to citations is applied
>> regardless of the particular citation command being used.
>>
>> So, I am not leaning closer to only allowing options being passed to
>> "processor", but not to styles. This will at least come closer to
>> certain settings being citation package global config applied to
>> everything. If we have options applied to specific citation commands,
>> they will rather fit into citation-style/sub-style.
>>
>> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style
>> citation-style

> If it were me, I would consider just having the options as =#+cite_export: 
> processor :options "anything"=. If the bibliography-style is important for 
> the user and processor, may be default values can be provided; and let the 
> user read some documentation option which are needed to run her particular 
> processor (provided by them, not necessarily Org). Again, being completely 
> honest, I don't think that you should put a dummy (like me) making these very 
> relevant decisions.

Joining the discussion I seem to have missed before (because I was
using a less org-ish solution).
My scenario: BEAMER and LATEX are my main targets, both with BIBLATEX
and biber as backend. Works nicely, and I can include a bibliography
at the end of my presentations, which is nice for lectures.
I'm more interested in the 'processor' part, because the default
bibliography and citation style fit me. However, I think that
something like:

#+cite_export: processor bibliography-style citation-style :options
opt1=val1,opt2=val2,...

as a generalised form (for the shortened version with default styles):

#+cite_export: processor :options opt1=val1,opt2=val2,...

would be expressive enough.

Best, /PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

Re: Asking whether to "save file /var/folders/xxxxxxxxx/orgicssxPjY1" everytime I kill Emacs

[Alexei Gilev]

I reinstalled org and this solved both (related) problems.
Thank you and apologies for not having sent the proper debugged error.

A.

El jue, 23 feb 2023 a las 11:42, Ihor Radchenko ()
escribió:

> Alexei Gilev  writes:
>
> > Basically that: from yesterday, every time I kill Emacs, i get this
> message.
> > I never got this message before and I am not sure whether I should be
> > saving or not.
>
> This is related to another error you are experiencing.
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=351279ffa
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [BUG] Wrong display when URL contains "/-/" [9.6.1 (release_9.6.1-264-g236bd4)]

[Ihor Radchenko]

Rafael Laboissière  writes:

> The following content is not displaying correctly for me (see attached 
> screenshot):
>
>[[https://host/some/-/path][[pre link]​]] this is underlined, but 
> shouldn't be [[https://host/another/-/path][[post link]​]]
>[[https://host/some/path][[pre link]​]] this is okay 
> [[https://host/another/path][[post link]​]]
>
> I guess that this is caused by the presence of "/-/" substrings in the 
> URLs. Such URLs containing this substring are used, in instance, by 
> GitLab.

It is wrongly fontified as italics, which appears to be fontified using
underline face in your Emacs.

The problem is known.
See https://orgmode.org/list/87ee7c9quk.fsf@localhost

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] Wrong display when URL contains "/-/" [9.6.1 (release_9.6.1-264-g236bd4)]

[Rafael Laboissière]

Dear Org Mode developpers,

The following content is not displaying correctly for me (see attached 
screenshot):


  [[https://host/some/-/path][[pre link]​]] this is underlined, but shouldn't 
be [[https://host/another/-/path][[post link]​]]
  [[https://host/some/path][[pre link]​]] this is okay 
[[https://host/another/path][[post link]​]]

I guess that this is caused by the presence of "/-/" substrings in the 
URLs. Such URLs containing this substring are used, in instance, by 
GitLab.


Best,

Rafael Laboissière


 Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0)
  of 2023-01-18, modified by Debian
 Package: Org mode version 9.6.1 (release_9.6.1-264-g236bd4 @ 
/home/rafael/.emacs.d/el-get/org-mode/lisp/)

 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
  org-cycle-display-inline-images)
  org-persist-before-read-hook '(org-element--cache-persist-before-read)
  org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all append
local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
  org-confirm-shell-link-function 'yes-or-no-p
  outline-isearch-open-invisible-function 'outline-isearch-open-invisible
  org-agenda-before-write-hook '(org-agenda-add-entry-text)
  org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
  org-confirm-elisp-link-function 'yes-or-no-p
  org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
  org-persist-directory "/var/tmp/org-persist-l3BeFI"
  org-fold-core-isearch-open-function 'org-fold--isearch-reveal
  org-persist-before-write-hook '(org-element--cache-persist-before-write)
  org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
  org-link-shell-confirm-function 'yes-or-no-p
  org-babel-pre-tangle-hook '(save-buffer)
  org-agenda-loop-over-headlines-in-active-region nil
  org-occur-hook '(org-first-headline-recenter)
  org-metadown-hook '(org-babel-pop-to-session-maybe)
  org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow org-eww-open :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
   ("info" :follow org-info-open :export org-info-export
:store org-info-store-link :insert-description
org-info-description-as-command)
   ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
   ("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link)
   ("doi" :follow org-link-doi-open :export
org-link-doi-export)
   ("file+sys") ("file+emacs")
   ("shell" :follow org-link--open-shell)
   ("news" :follow
#[514 "\301\300\302Q\"\207"
  ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
   ("mailto" :follow
#[514 "\301\300\302Q\"\207"
  ["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
   ("https" :follow
   

Re: Re: Is there a way of putting the biblatex options in the org file?

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> Joining the discussion I seem to have missed before (because I was
> using a less org-ish solution).

Could you please reply in the linked thread? Otherwise, other
participants of that thread will not see your idea.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Asking whether to "save file /var/folders/xxxxxxxxx/orgicssxPjY1" everytime I kill Emacs

[Ihor Radchenko]

Alexei Gilev  writes:

> Basically that: from yesterday, every time I kill Emacs, i get this message.
> I never got this message before and I am not sure whether I should be
> saving or not.

This is related to another error you are experiencing.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=351279ffa

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: How to export org-agenda to ICS to show in iCal

[Ihor Radchenko]

Alexei Gilev  writes:

> Thanks for your time.
>
> When I try, however, to use functions like
> org-icalendar-combine-agenda-files or org-icalendar-export-to-ics, I get
> this error:

It would help if you provided a backtrace or, better, a reproducer
starting from Emacs -Q.

See https://orgmode.org/manual/Feedback.html#Feedback

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: bug#59882: Multiple versions of Org in load-path problem

[Ihor Radchenko]

Bhavin Gandhi  writes:

> These are init files specific to other packages installed via OS package
> manager. But those are not loaded, it seems in the above steps. I tried to
> run (featurep 'clang-format) and it returned nil, while this returns t
> in my normal Emacs instance.
> ...
> None of these load org-mode.

They just define auto-loading, but I see not how they would affect Org
loading.

Very confusing...

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: BUG: org-sbe not working anymore: Format specifier doesn’t match argument type

[Ihor Radchenko]

赵一宇  writes:

> Here is an example, in org file
>
>
> #+name: test
> #+begin_src emacs-lisp :var a :results silent
> a
> #+end_src
>
>
> Now, if I execute 
> (org-sbe "test" (a "123°34'23.34\"otherthing"))
> it would say: Reference 123°34'23.34"otherthing not found

Fixed, on main.
I made org-sbe accept quoting string values with "$".
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2e883b21a

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at