Re: Recent folding issues

[William Denton]

On 11 July 2022, Jack Kamm wrote:


2. When folded, I frequently found multiple headlines to be displayed on
the same line, like so:

* Headline 1...
* Headline 2...* Headline 3...
* Headline 4

Hitting Shift-Tab a few times (org-global-cycle) usually fixed the
problem.


That's very much like a problem I've been getting (see the message I just sent 
to the list), which Ihor has also been helping with.  For me, just now when the 
problem happened again (I realize this is anecdotal, not reproducible) hitting 
TAB a lot on the headline might work, but hitting TAB on other headlines did 
nothing, and Shift-TAB would expand /some/ headlines but not the one where the 
pointer was!


So I'm in the same boat as you, and trying various things to figure out what's 
going on.



Cheers,

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: Folded headlines with text showing where it shouldn't

[William Denton]

On 3 June 2022, Ihor Radchenko wrote:


William Denton  writes:


For me, this looks like either a mixed installation (please post the
output of M-x org-version) or some third-party package misbehaving.


M-x org-version says:

Org mode version 9.5.3 (release_9.5.3-511-g8e69ad @ 
/usr/local/src/org-mode/lisp/)


Is /usr/local/src/org-mode/lisp/ the folder where you installed the
latest Org version? (If not, this is likely the problem or part of the
problem).


First of all, thanks for following up on this---I'm slow to respond, but 
appreciate your help in narrowing this down.  The problem's been happening 
again, and tonight I can follow up with some details.


That directory is where I installed Org.  It's where I pull down the source tree 
with Git.



Usually, the problem you are seeing is when something is interfering
with 'invisible text property of links/other folded text.

Can you post the value of org-link-parameters on your system?


This is a new variable to me!  I've never done anything with it, but it's got a 
lot in it.


Value:
(("attachment" :follow org-attach-follow :complete org-attach-complete-link)
 ("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)
 ("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)
 ("id" :follow org-id-open)
 ("file+sys")
 ("file+emacs")
 ("shell" :follow org-link--open-shell)
 (#1="news" :follow #f(compiled-function
   (url arg)
   #))
 (#3="mailto" :follow #f(compiled-function
 (url arg)
 #))
 (#6="https" :follow #f(compiled-function
(url arg)
#))
 (#7="http" :follow #f(compiled-function
   (url arg)
   #))
 (#8="ftp" :follow #f(compiled-function
  (url arg)
  #))
 ("help" :follow org-link--open-help :store org-link--store-help)
 ("file" :complete org-link-complete-file)
 ("elisp" :follow org-link--open-elisp))
Original value was nil


You may also put the cursor onto unexpectedly visible link and check the
output of M-x describe-text-properties. Then, put the cursor right after
the link and run M-x describe-text-properties again. Then, share the
output.


Here's a screenshot of the problem I get:

https://www.miskatonic.org/tmp/org-problem.png

And here's the output of describe-text-properties when the pointer is in the 
link that shouldn't be there:


Text content at position 56157:

There are 3 overlays here:
 From 55909 to 56345
  face hl-line
  priority -50
  window   #
 From 56149 to 56170
  evaporatet
  invisibleorg-link
  isearch-open-invisible delete-overlay
  org-invisibleorg-link
  priority 1
 From 56151 to 56168
  evaporatet
  invisibleorg-link-description
  isearch-open-invisible ignore
  isearch-open-invisible-temporary ignore
  org-invisibleorg-link-description
  priority 2


There are text properties here:
  face org-link
  font-lock-multiline  t
  fontifiedt
  help-echo"LINK: fig_rereading_pct"
  htmlize-link (:uri "fig_rereading_pct")
  isearch-open-invisible org-fold-core--isearch-show
  isearch-open-invisible-temporary org-fold-core--isearch-show-temporary
  keymap   [Show]
  line-prefix  [Show]
  mouse-face   highlight
  org-fold--spec-org-fold-outline--876068932062118346 org-fold-outline
  org-fold--spec-org-link-description-global org-link-description
  org-fold--spec-org-link-global org-link
  wrap-prefix  [Show]


If you don't have time to dig into the problem, you can also set
org-fold-core-style to 'overlays in your config to activate legacy
folding support. It will most likely solve the immediate issue on your
side and let you work on more pressing things involving your Org
workflow.


I've changed this (which was also mentioned in another thread yesterday) and 
will try it out for a while to see if that makes a difference.


Thanks again,

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

BUG+PATCH org-capture hangs under Cygwin/X

[Max Mikhanosha]

Due to various reasons I'm now using Cygwin/X Emacs, and for this emacs,
(gui-get-selection) method is kind of slow (about 0.2) seconds.

While this is not a big deal usually, (org-get-x-clipboard) calls
(gui-get-selection) 4 times with different formats (utf8, text,
compound-text and string).

On top of that, (org-capture-fill-template) calls (org-get-x-clipboard) 3
times with PRIMARY, CLIPBOARD and SECONDARY, and then calls it again to
make values for the ^%C expansion.

In addition it also calls (current-kill 0), which in itself calls
(gui-selection-value), which also may call (gui-get-selection up to 4
times), and has a side effect of clearing the clipboard if
select-use-clipboard is true.

All of the above calls are made even if template parameters don't have any
expansions that reference selection.

This results in org-capture having about 16 second hang for me on Cygwin/X
when clipboard and selection are completely empty.

Attached patch changes it so that we only call (org-get-x-clipboard) and
(current-kill 0) lazily. The logic had not changed, we just don't pre-cache
values that we don't need.


0001-org-capture-fix-hang-under-Cygwin-X-emacs.patch
Description: Binary data

Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]

[Ihor Radchenko]

Gustavo Barros  writes:

> But not to bump empty handed, I did some investigation on this, and I 
> think I know why the problem happens.

Thanks for the detailed analysis!

> What I'm not sure is why this condition is there in the first place. 
> That's the only place where the let-bound `todayp' is used in the 
> function, so I may be missing why it exists and the purpose of this 
> condition.  But one side-effect of it is that, if you happen to do a 
> repeating task ahead of schedule, you won't see the change of todo state 
> in the agenda.

I dug through the old commits and found where this behaviour has been
introduced:

Commit 0bbf3a9bd message details the current behaviour and its caveats:

>> When marking a repeated entry DONE in the daily or weekly agenda, that
>> task would previously still be shown as TODO, because the repeater
>> immediately restores the TODO state after moving the time stamp.  This
>> is bad feedback.
>> 
>> This problem was hard to fix.  Because the same line may be present in
>> other lines in the same weekly agenda, we cannot simply update all
>> lines related to this entry.
>> 
>> What we do now is this:  Before the repeater does its work in shifting
>> the time stamp and resetting the TODO keyword, we take a snapshot of
>> the headline as it looks then.  And then, when we update the agenda
>> view, we change only the line at the cursor instead of all lines
>> related to this entry.  We also make sure that this is only so if the
>> cursor is in a daily/weekly agenda, on TODAY's date.
>> 
>> There still remain possible inconsistencies.  For example, if you have
>> a daily repeating task in the weekly agenda, and you move the cursor a
>> few days into the future and mark it DONE there, the entry will
>> actually be marked DONE for today, but still show up in today's task
>> list as TODO.  refreshing the agenda will fix the display in such an
>> unlikely case.
>> 
>> Thanks to Jack ??? for noticing and reporting this issue.

As you can see, the todayp condition is avoiding issues with weekly
agenda when the same habit is displayed multiple times.

The problem you observed is also noted and left unresolved.

Ideas how to deal with the described are welcome!

Best,
Ihor

Re: Org mode escape characters

[Ihor Radchenko]

David Boss  writes:

>  You tell me to "surround" slashes by zero-width-space characters, to keep 
> them from being taken as italic escapes.OK. First problem: what, exactly, is 
> the zero-width space character? I won't be entering text with my fingers, a 
> lispfunction I wrote will be inserting the characters I need. So, exactly 
> what 8-bit value is a zero-width-escape? ?The example in 17.12 seems 
> to put the zero-escape after the control character it's supposed to affect, 
> but then theeffect of it balances forward. 12.6 tells me I also have to put a 
> comma before any line beginning with a star, despitethe fact that my only 
> purpose was to deal with italics. I need to write a function which works, 
> first time, every time;I can't keep playing around with each piece of text it 
> applies to, until it works on that one. OK, helping me get afunction written 
> is not your job, but I shouldn't need .odt and/or pandoc; I should not have 
> needed your help,at all: plain vanilla copy/paste in emacs should bring along 
> text properties within the scope of the copied text.
> Still, I do appreciate your help.

Org does not perform any kind of format conversion when you kill
selection by default.

There is however a third-party package that provides some (limited?)
support for clipboard conversion: https://github.com/jkitchin/ox-clip

Note that Org is a markup format with all the relevant advantages and
disadvantages. The requirement to escape some special symbols is
one of the disadvantages.

You can insert zero-width space using C-x 8  or by its hex number
or directly copying it to (insert "​").

Note that Org does provide the means to convert Org markup into
alternative markups like HTML. This is done using export functionality:
https://orgmode.org/manual/Exporting.html#Exporting

Hope it helps.

Best,
Ihor

Re: Alternatives or org-capture?

[Christopher M. Miles]

I'm currently maintaining org-contacts (well, inactively)

Here is my own org-contacts' org-capture template, maybe you want to check out 
as reference:

#+begin_src emacs-lisp
(add-to-list 'org-capture-templates
   `("C" ,(format "%s\tContacts"
  (all-the-icons-material "contacts" :face 
'all-the-icons-blue-alt))
 entry (file (lambda () (car org-contacts-files)))
 "* %^{NAME}
:PROPERTIES:
:DIR:  %\\1
:DATE: %^U
:AVATAR: %^{Avatar}
:NICK: %^{Nick}
:NAME(Chinese): %^{Name(Chinese)}
:NAME(English): %^{Name(English)}
:GENDER: %^{Gender|Transgender|Male|Female}
:RELATIONSHIP: %^{Relationship|Internet|Meet|Friend|Good Friend|Boy Friend|Girl 
Friend|Workmate|Classmate|Schoolmate}
:FIRST-MEET: %^U  %^{How is the first-time meet? when? where? how?}
:MOBILE: %^{Mobile Phone}
:EMAIL: %^{Email}
:GitHub: %^{GitHub}
:ADDRESS(home): %^{address(home)}
:ADDRESS(live): %^{address(live)}
:LANGUAGES: %^{Languages|Chinese|Chinese, English|English|Japanese|Korean}
:EDUCATION: %^{Education}
:School(university):
:SKILLS: %^{Skills|Programming|Economy}
:Programming-Skills: %^{Programming Skills|Emacs|Web|Computer System|Cloud 
Computation}
:Programming-Languages: %^{Programming Languages|LISP|Common Lisp|Clojure|Emacs 
Lisp|Java|C/C++|Python|Ruby|PHP}
:OCCUPATION: %^{Occupation|Programmer|Freelancer|Businessman|Servant|Arter}
:HOBBIES: %^{Hobbies|Reading|Music|Movie|Travel}
:END:"
 :empty-lines 0
 :jump-to-captured t)
   :append)
#+end_src


-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: Recent folding issues

[Ihor Radchenko]

Jack Kamm  writes:

> I started noticing a couple issues with folding, after updating my
> org-mode in recent months:

May you provide the output of M-x org-version?

> 1. Inserting text below or above a folded headline will cause it to
> unfold. I am not sure if this is an intentional change, but I find the
> new behavior confusing -- usually I am trying to enter a new headline,
> and the unfolding causes me to lose my context and forget what level I
> wanted my new headline to be.

I cannot reproduce. Please, update your Org to the latest version, try
to reproduce, and provide the detailed steps required to obtain the
confusing behaviour you are seeing.
See https://orgmode.org/manual/Feedback.html

> 2. When folded, I frequently found multiple headlines to be displayed on
> the same line, like so:
>
> * Headline 1...
> * Headline 2...* Headline 3...
> * Headline 4
>
> Hitting Shift-Tab a few times (org-global-cycle) usually fixed the
> problem.

Again, I cannot reproduce. If you can reliably obtain this erroneous
behaviour, please give us the information how to reproduce it. Then, we
will be able to fix it.

> After reading ORG-NEWS, I found out about org-fold-core-style, and have
> set it to 'overlays, which solved both of my problems.
>
> However, this makes me wonder whether it should be the default
> value. The help for it says:
>
>> Can be either ‘text-properties’ or ‘overlays’.
>> The former is faster on large files, while the latter is generally
>> less error-prone.
>
> Since the latter is less error-prone, shouldn't it be the default? And
> then a user can switch the value if they have really large files and
> need better performance. It's great that performance is being improved
> for large files, but I'm not sure this is ready to be the default yet.

I now clarified the docstring of org-fold-core-style.
"Error-prone" there refers to third-party packages that are relying on
the old implementation detail of folding.

Note that this feature is not a part of the stable Org release. It is
the development branch. We are trying our best to avoid bugs, but bugs
are pretty hard to avoid when introducing major changes like this.

Of course, we will fix the reported bugs given that enough information
is provided to reproduce them.

So, no, 'overlays should not be the default. You may also check out
https://blog.tecosaur.com/tmio/2022-05-31-folding.html

Best,
Ihor

Re: Alternatives or org-capture?

[Tim Cross]

ypuntot  writes:

> I'm going to start using org-contacts. And, with that, I would like to use 
> org-capture or yankpad. Which one would you recommend using?
> I have been trying to use org-capture but it doesn't seem too intuitive for 
> me :$ 
>
> I saved time ago a tutorial for yankpad, and it looked nice. 
> Does org-capture deserve more effort or could yankpad be more friendly and as 
> useful? 
>
> Best regards 
>

The first thing to note is that org-contacts is a contrib package and
not actually part of org itself.

Where org-contacts can be really useful is when you use Emacs to read
your email. For most Emacs based MUAs, you will be able to configure the
MUA to use org-contacts to collect contact information and for
auto-completion of addresses etc. For example, the mu4e manual has a
short page about using org-contacts with mu4e.

I don't know yankpad, but from a quick look it seems to only be a basic
template system. Org capture is not quite the same - it is functionality
used to capture data and store it in an org file in a specific
format. Where it is really powerful is through its template expansion capability
which will be automatically filled in with data extracted from
the source buffer you are in when you run it. For example, if your using
a MUA which has org support, you can have an org-contgacts template
which will be automatically filled in with contact data from the current
message your viewing, you can have the message-id automatically added
and even have a permanent link to the email as well as other meta data
like date/time etc.

If your going to be using org mode a bit, I strongly recommend you spend
the time to get to understand org-capture. Because it is built into org
mode it is an integral part of many org mode based workflows. The
org-contrib package uses it to streamline collection of contact data and
it is a core part of how org-contacts works. If your going to use
something else like yankpad, you may as well not worry aboutg
org-contacts and just roll your own using yankpad and an org file as
your contacts database.  

As to documentation for org-contacts - there isn't much I could
find. The best source is really the source code, particularly the
'commentry' section. The ELPA package description also has some
information. and there are a few blogs, video etc which you can use to
piece things together.

Recommend you get to know/understand org-capture first and the rest will
become much clearer.

[PATCH] oc-csl: Add support for sub-bibliographies

[András Simonyi]

Dear All,

the attached patch adds support for filter-based sub-bibliographies in the "csl"
org-cite export processor. It supports the same syntax for specifying
filters as the biblatex processor and supports some of the biblatex
filter types, concretely, entry-type and keyword based filtering. It
also supports filtering based on CSL type (as opposed to bib(la)tex
type) and using any Lisp predicate as a filter.

best wishes,
András
From 50db7f8ae94cf9a3799eccdf3d7ee69a2e7c4505 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Mon, 11 Jul 2022 19:13:48 +0200
Subject: [PATCH] oc-csl.el: Add support for sub-bibliographies

* lisp/oc-csl.el (org-cite-csl--rendered-bibliographies): New function
to collect all #+print_bibliography keywords with their properties and
call Citeproc to render all sub-bibliographies in one go as required
by the API.  Return the formatted bibliographies as values in an alist
in which keys are the #+print_bibliography keyword options as plists.
Cache the return value in the export communication channel.
(org-cite-csl--bibliography-filter): New helper function to convert
plists representing #+print_bibliography options to the alist filter
form expected by Citeproc.
(org-cite-csl--rendered-citations): Call
`org-cite-csl--rendered-bibliographies' before rendering citations to
make sure that the complete sub-bibliography information is added to
the processor and, therefore, citation numbers are correct.
(org-cite-csl--render-bibliography): Instead of directly calling
Citeproc to render the bibliography, call
`org-cite-csl--rendered-bibliographies' and retrieve the formatted
bibliography from its return value based on the options passed as the
`props' argument.
---
 etc/ORG-NEWS   | 13 +++-
 lisp/oc-csl.el | 83 +-
 2 files changed, 88 insertions(+), 8 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4cda357f1..ce8675dea 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -239,7 +239,7 @@ This behaviour can be changed by supplying a =:align= parameter.
 
 The tabbing environment can be useful when generating simple tables which
 can be span multiple pages and when table cells are allowed to overflow.
-*** Support for =nocite= citations in the "csl" export processor
+*** Support for =nocite= citations and sub-bibliographies in the "csl" export processor
 
 The "csl" citation export processor now supports =nocite= style
 citations that add items to the printed bibliography without visible
@@ -251,6 +251,17 @@ instance,
 #+end_src
 
 includes all available items in the printed bibliography.
+
+The "csl" export processor now also supports sub-bibliographies that
+show only a subset of the references based on some criterion.  For
+example,
+
+#+begin_src org
+#+print_bibliography: :type book :keyword ai
+#+end_src
+
+prints a sub-bibliography containing the book entries with =ai= among
+their keywords.
 ** New functions and changes in function arguments
 
 *** New function ~org-element-cache-map~ for quick mapping across Org elements
diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index a2bd6653c..0b2fe5c41 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -90,11 +90,23 @@
 ;; The part of the suffix before the locator is appended to reference's prefix.
 ;; If no locator term is used, but a number is present, then "page" is assumed.
 
+;; Filtered sub-bibliographies can be printed by passing filtering
+;; options to the "print_bibliography" keywords.  E.g.,
+;;
+;;#+print_bibliography: :type book keyword: emacs
+;;
+;; If you need to use a key multiple times, you can separate its
+;; values with commas, but without any space in-between:
+;;
+;;#+print_bibliography: :keyword abc,xyz :type article
+
 ;; This library was heavily inspired by and borrows from András Simonyi's
 ;; Citeproc Org () library.
 ;; Many thanks to him!
 
 ;;; Code:
+(require 'cl-lib)
+(require 'map)
 (require 'bibtex)
 (require 'json)
 (require 'oc)
@@ -559,6 +571,10 @@ OUTPUT using Citeproc."
 	  (citeproc-append-citations structures processor))
 	(when nocite-ids
 	  (citeproc-add-uncited nocite-ids processor))
+;; All bibliographies have to be rendered in order to have
+;; correct citation numbers even if there are several
+;; sub-bibliograhies.
+(org-cite-csl--rendered-bibliographies info)
 	(let (result
 	  (rendered (citeproc-render-citations
 			 processor
@@ -572,6 +588,62 @@ OUTPUT using Citeproc."
 	  (plist-put info :cite-citeproc-rendered-citations result)
 	  result
 
+(defun org-cite-csl--bibliography-filter (bib-props)
+  "Return the sub-bibliography filter corresponding to bibliography properties.
+
+BIB-PROPS should be a plist representing the properties
+associated with a \"print_bibliography\" keyword, as returned by
+`org-cite-bibliography-properties'."
+  (let (result
+	(remove-keyword-colon (lambda (x) (intern (substring 

Re: fontsets

[Juan Manuel Macías]

Hi, Timothy,

Timothy writes:

> Yep, so in my config’s implementation I have an alist of fontset names and
> individual fonts. For something part of org-mode itself, we’d probably want to
> add a format level to this, something like:
>
> ┌
> │ ((fontset-name .
> │   ((serif .
> │ ((pdflatex . "\\usepackage{myserif}")
> │  (lualatex . "etc.")
> │  (html . "and so on")))
> │(sans ...) ... ))
> │ (another-fontset ...) ...)
> └
>
> Actually, now that I think of it maybe it would be better to seperate out the
> fontsets and fots, e.g.
>
> ┌
> │ ;; Fonts
> │ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
> │  (myfontb ...)
> │  ...)
> │ ;; Fontsets
> │ ((myfontset .
> │   ((sans . myfonta)
> │(serif . myfontb)
> │(mono . myfontc)
> │...))
> │  ...)
> └
>
>> In any case, I think it would also be nice if the user could add only
>> one family for roman, sans, mono or math, if he/she prefers it that way.
>> Something like:
>>
>> #+options: rmfont:Minion Pro
>
> Sure. There’s another bit of functionality in my config which I think is worth
> noting, you can add a -sans/-serif/-mono suffix to the fontset name to 
> override
> the default body text font.

I see. I like your approach. And the idea of fontsets also seems very
productive. I suppose that a minimum configuration in fontspec
(Scale=MatchLowercase) should be ensured, in order to balance the
x-height when using fonts from different families in a single document[1].

The fact that all of this can also be "reusable" for other outputs such as
html, is a not insignificant plus! I definitely really like all of these
ideas and I don't think there is any contradiction with a balance
between those users who are content with minimal out-of-the-box font
configuration to be able to read non-latin characters, and those who
want more control over fontspec (font features, etc). And there are also
the users (me among them) who leave little or almost no space for Org to
write the preamble for us :-)

On the other hand, maybe (I think) it would be nice not to differentiate
between xelatex and lualatex, since at least at this level both engines
support the same fontspec settings.

[1] I have to add, by the way, that MatchLowercase is not always a
panacea. In many cases, and depending on the fonts, it may be better to
allow some contrast between families. Maybe it would be nice to add to
the documentation or to worg (at least for users who may be interested
in these topics) some basic recommendations for combining families (for
example, combining a bodoni with a bembo is usually a catastrophic
marriage :-).

Best regards,

Juan Manuel

Re: [feature] Consistent fixed indentation of headline data

[Valentin Lab]

Many thanks for your warm welcome, kind review and suggestions.
I do not provide a corrective patch in this email, but it'll come soon 
depending on possible other remarks or follow-ups of this email.


On 07/07/2022 12:41, Ihor Radchenko wrote:

Valentin Lab  writes:

Note that we rarely change the defaults. This particular change came
after extensive discussion:
https://orgmode.org/list/878s4x3bwh@gnu.org
Also, it has been documented in https://orgmode.org/Changes.html
I recommend reviewing the changes every time you update Org to new
version.



These links are very informative and give me much more insight on the 
current situation. Sorry if I didn't know how to get this info by 
myself. I've read the full thread you've linked.



Note that introducing a new customization should be documented in
etc/ORG-NEWS file and probably also in the manual (17.4.2 Hard
indentation).


Yes, I was aware of that, but didn't want to spend to much time if my 
contribution was deemed not pertinent.




Also, I am not sure if we really need a new custom variable. We already
have many. What about simply allowing an integer value of
org-adapt-indentation?



Well, my guess was that the "adapt" word in `org-adapt-indentation' was 
referring to adaptive (in other words: "changing") indentation depending 
on the depth of the outline. It seemed at first un-natural to force a 
fixed behavior here. This is why I went with a sub-behavior of when 
`org-adapt-indentation' was set to nil, a way to tell that we didn't 
want adaptive indentation. It also had the advantage to separate the 
implementation and help writing code that would not break the existing 
behaviors.


Of course, I'm completely okay to go with your suggestion. Although, I'm 
at a lack of inspiration about what would be the best option here: 
wouldn't a simple integer as you suggest hide the fact that this will 
target only the headline data ? Could we think of more structured value, 
perhaps like a cons =(`headline-data . 2)= ? I'm afraid these additions 
could be seen as bringing some unwanted complexity.


Although I'm expressing some doubts, I'm ready to implement it using an 
integer on `org-adapt-indentation' as you suggest. Just wanted to make 
sure it seem sound to everyone before committing to a change that is not 
that trivial (well, compared to actual changes).




TINYCHANGE

Signed-off-by: Valentin Lab 


Note that your patch is _not_ a tiny change (not <15 LOC).
See https://orgmode.org/worg/org-contribute.html#first-patch and
https://orgmode.org/worg/org-contribute.html#copyright
Would you consider signing the copyright assignment papers with FSF?


Ok, I was not sure about that (counting the actual functional code 
change was still under 15LOC, but I guess test counts also). I'm in the 
process of signing the copyright assignment papers.





@@ -18371,6 +18386,9 @@ ELEMENT."
;; a footnote definition.
(org--get-expected-indentation
 (org-element-property :parent previous) t))
+  ((and (not (eq org-headline-data-fixed-indent-level nil))
+ (memq type '(drawer property-drawer planning node-property clock)))
+ org-headline-data-fixed-indent-level)
;; Otherwise, move to the first non-blank line above.


Why clock? It does not belong to property drawers.



I probably lack some important knowledge here to understand your point. 
Here's what I understand: `clock' type targets the 'CLOCK:' keyword (and 
not direct timestamps, I added a test to make sure). AFAIK, these 
'CLOCK:' lines are made with 'C-c C-x C-i/o' and usually appears in 
between a ':LOGBOOK:' drawer. However older implementation of org-mode 
did not include these 'CLOCK: ...' lines in logbook drawers. My 
intention here, was to make sure that even these orphaned 'CLOCK: ...' 
lines, when appearing before any content, would be considered as 
headline data, and as such, be indented by the fixed amount.


I definitively consider the logbook (and clock out of logbooks), 
property drawer, and planning info ("SCHEDULED", "DEADLINE") as headline 
data and are all targeted for indentation. In my code, if I remove 
`clock' in the list of types, the intended test about 'CLOCK:' fails...



@@ -1216,6 +1259,13 @@
  (org-test-with-temp-text "* H\n:PROPERTIES:\n:key:\n:END:"
(org-indent-region (point-min) (point-max))
(buffer-string)
+  ;; ;; Indent property drawers according to `org-adapt-indentation'.
+  ;; (let ((org-adapt-indentation 'headline-data))
+  ;;   (should
+  ;;(equal "* H\n  :PROPERTIES:\n  :key:\n  :END:\n\ncontent2"
+  ;;   (org-test-with-temp-text "* 
H\n:PROPERTIES:\n:key:\n:END:\n\ncontent"
+  ;; (org-indent-region (point-min) (point-max))
+  ;; (buffer-string)


This test is commented. Is it intentional?


My bad ! and an interesting talking point. I'm removing these 

Alternatives or org-capture?

[ypuntot]

I'm going to start using org-contacts. And, with that, I would like to use 
org-capture or yankpad. Which one would you recommend using? I have been trying 
to use org-capture but it doesn't seem too intuitive for me :$

I saved time ago a tutorial for yankpad, and it looked nice.
Does org-capture deserve more effort or could yankpad be more friendly and as 
useful?


Best regards

NB: I can't find the documentation for org-contacts, not sure if it's just me.

Re: fontsets (was: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful..."))

[Timothy]

Hi Juan,

> When you talk about fontset, I understand that you mean lists of
> families with their options that you have previously defined, is that
> right?

Yep, so in my config’s implementation I have an alist of fontset names and
individual fonts. For something part of org-mode itself, we’d probably want to
add a format level to this, something like:

┌
│ ((fontset-name .
│   ((serif .
│ ((pdflatex . "\\usepackage{myserif}")
│  (lualatex . "etc.")
│  (html . "and so on")))
│(sans ...) ... ))
│ (another-fontset ...) ...)
└

Actually, now that I think of it maybe it would be better to seperate out the
fontsets and fots, e.g.

┌
│ ;; Fonts
│ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
│  (myfontb ...)
│  ...)
│ ;; Fontsets
│ ((myfontset .
│   ((sans . myfonta)
│(serif . myfontb)
│(mono . myfontc)
│...))
│  ...)
└

> In any case, I think it would also be nice if the user could add only
> one family for roman, sans, mono or math, if he/she prefers it that way.
> Something like:
>
> #+options: rmfont:Minion Pro

Sure. There’s another bit of functionality in my config which I think is worth
noting, you can add a -sans/-serif/-mono suffix to the fontset name to override
the default body text font.

All the best,
Timothy

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Max Nikulin]

On 11/07/2022 21:23, Juan Manuel Macías wrote:

Max Nikulin writes:

\ifpdftex, \ifPDFTeX
True if PDFTEX is in use (whether writing PDF or DVI), so this is true
for documents processed with both the latex and pdflatex commands.

So the code says: if pdfTeX is used, do nothing; else, add this (luatex
and xetex related) code.


Likely it is not relevant to Org, but for the following document

\documentclass{article}
\usepackage{ifpdf}
\begin{document}
\ifpdf PDF\else Not PDF\fi
\end{document}

I get "PDF" when I use pdflatex and "Not PDF" when I run latex.


Yes, that is true, sorry. I don't work with math. But:

\setmathrm{⟨font name⟩}
\setmathsf{⟨font name⟩}
\setmathtt{⟨font name⟩}
\setboldmathrm{⟨font name⟩}

Now, weren't we talking about ensuring a minimum readability out of the
box in case non-Latin characters are used?


Mathematical expressions may contain non-latin characters as well. 
\text{} may be a rescue (anyway such expression usually appears poorly 
formatted), but if I remember correctly, it is better to use math mode 
commands to get accurate spaces in accordance to TeX design. So math 
fonts with wider coverage is somewhere close to minimum readability.

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Max Nikulin]

On 10/07/2022 03:22, Juan Manuel Macías wrote:


LuaTeX and XeTeX are
digital typesetting systems. They are not word processors.


I have skimmed through the discussion happened exactly a year ago
https://list.orgmode.org/orgmode/scuirf$m7o$1...@ciao.gmane.io/
and I should repeat that you are too much concentrated on books and 
carefully designed camera-ready files.


LaTeX is a kind of word processor as well in the sense that it is used 
for notes that are not intended to be published. In some cases it is 
merely a tool to make readable a text heavy loaded with math. Balance of 
efforts and quality is quite different. As much as possible should be 
delegated to "word processor". Forcing users to select particular fonts 
makes documents less portable, it increases a chance that a colleague 
does not have a font installed on your machine or you get a file 
requiring a proprietary font you do not have.


For such quick notes the feature currently provided by browser, office, 
etc. is indispensable: list of implicit fallbacks to find some available 
font having glyphs missed in the primary fonts.


I do not mind that LuaLaTeX alleviated issues with configuring of fonts, 
so it is more convenient for books or decorated documents. Personally I 
was quite happy with PdfLaTeX fonts I get out of the box without 
necessity to override ≥ 6 font families. I did not use hieroglyphs or 
fancy Unicode characters, but with LuaLaTeX they anyway require setting 
of additional fonts. My current impression is that LuaLaTeX may be 
significant step forward for publishers, but for quick notes it is a 
kind of trade-off.

Re: Org mode escape characters

[Max Nikulin]

On 11/07/2022 09:36, David Boss wrote:
I generally run in Fundamental mode. Since ASCII is really only a 7-bit 
code, I use the high bit to indicate italics.

...
I want to be able to copy an emacs buffer, with some characters having 
italic mode set, and paste that into an email compose buffer, and have 
the italics set in the email buffer; this should work, but it doesn't, who
knows, who cares, why not. But if I copy/paste a .odt file, with 
italicized characters, the italics show up as intended, in the email 
buffer.


You did not provided any detail which email client and which OS you are 
using. I do not know how it is implemented on Windows, but on Linux 
applications declares several MIME types for selection: UTF8_STRING, 
text/html, etc. Applications that can insert formatted text use HTML, 
pure text application query plain text. To inspect available types the 
following command may be used:


xclip -target TARGETS -out -selection CLIPBOARD

AFAIK emacs can not provide several types for selection content and 
xclip does not have such feature as well. When you are sure that namely 
formatted text is required, you can try to feed markup to xclip -target 
text/html.


I do not think that Org is appropriate tool for your purpose, escaping 
is tricky, zero-width spaces when used in such case should be removed 
from the target document. Constructing org-element AST directly may be 
more reliable.


Within Emacs yank-handler text property may help to copy text from your 
specific encoding to other buffers.

Recent folding issues

[Jack Kamm]

I started noticing a couple issues with folding, after updating my
org-mode in recent months:

1. Inserting text below or above a folded headline will cause it to
unfold. I am not sure if this is an intentional change, but I find the
new behavior confusing -- usually I am trying to enter a new headline,
and the unfolding causes me to lose my context and forget what level I
wanted my new headline to be.

2. When folded, I frequently found multiple headlines to be displayed on
the same line, like so:

* Headline 1...
* Headline 2...* Headline 3...
* Headline 4

Hitting Shift-Tab a few times (org-global-cycle) usually fixed the
problem.

After reading ORG-NEWS, I found out about org-fold-core-style, and have
set it to 'overlays, which solved both of my problems.

However, this makes me wonder whether it should be the default
value. The help for it says:

> Can be either ‘text-properties’ or ‘overlays’.
> The former is faster on large files, while the latter is generally
> less error-prone.

Since the latter is less error-prone, shouldn't it be the default? And
then a user can switch the value if they have really large files and
need better performance. It's great that performance is being improved
for large files, but I'm not sure this is ready to be the default yet.

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Juan Manuel Macías]

Timothy writes:

> As an illustrative example, if I include this in one of my documents and 
> create
> a PDF:
> ┌
> │ #+options: fontset:biolinum
> └
>
> Then I’ll get text with:
> ⁃ libertine roman as the serif font
> ⁃ biolinum as the serif, and default, font
> ⁃ source code pro as the mono font
> ⁃ newtxmath as the maths font
>
> Similarly I can do `fontset:noto' and you can guess what that does.

I think it's a very good idea to be able to add the options using
#+options:..., forgive the redundancy :-)

When you talk about fontset, I understand that you mean lists of
families with their options that you have previously defined, is that
right? 

In any case, I think it would also be nice if the user could add only
one family for roman, sans, mono or math, if he/she prefers it that way.
Something like:

#+options: rmfont:Minion Pro

Best regards,

Juan Manuel 

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Juan Manuel Macías]

Max Nikulin writes:

>>   \\relax
>>   \\else
>
> Is it the case of latex as the old engine with tex->dvi->ps workflow
> besides new XeTeX and LuaTeX? However such engine is not used by Org.

According to the iftex documentation (p. 2):

\ifpdftex, \ifPDFTeX
True if PDFTEX is in use (whether writing PDF or DVI), so this is true
for documents processed with both the latex and pdflatex commands.

So the code says: if pdfTeX is used, do nothing; else, add this (luatex
and xetex related) code.

>>   \\usepackage{fontspec}
>>   \\usepackage{unicode-math}
>>   \\defaultfontfeatures{Scale=MatchLowercase}
>>   \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>>   \\setmainfont{%s}
>>   \\setsansfont{%s}
>>   \\setmonofont{%s}
>>   \\fi
>>   org-latex-fontspec-mainfont
>>   org-latex-fontspec-sansfont
>>   org-latex-fontspec-monofont)
>
> Too many variables to my taste. It can be single property list. If I
> remember correctly, changing of mainfont requires setting of a
> consistent font for mathematics, so more options may be required.

Yes, that is true, sorry. I don't work with math. But:

\setmathrm{⟨font name⟩}
\setmathsf{⟨font name⟩}
\setmathtt{⟨font name⟩}
\setboldmathrm{⟨font name⟩}

Now, weren't we talking about ensuring a minimum readability out of the
box in case non-Latin characters are used? I assume that by default the
mathematical notation is assured, although the default mathematical font
may be typographically or aesthetically incompatible with the chosen
text fonts. For example, Computer Modern and FreeSerif are antipodes in
design. The first is a Didotian font and the second is a times style
typeface. But I think that what is sought here is that certain (non
latin) glyphs are represented in the PDF, beyond other typographical or
aesthetic considerations. My idea here is that a) the user who doesn't
want to mess with all these issues has a minimum of readability out of
the box; b) the user who wants to have full control over the fontspec
options has the possibility to do so; c) the user who does not want Org
to write the preamble under any circumstances (that is, people like me),
has the possibility of continuing doing so.

> Finally, default value may be language-dependent or alternative font
> set may be activated when non-latin characters are detected in the
> document.

If I had to choose between both options, I would prefer the second one.
But don't you think it would be much simpler to ensure the readability
of non-Latin characters (at least in a high percentage) by means of
three default fonts (roman, sans, mono), and let the user who needs
another font be able to choose it freely, simply by changing the value
of those variables? Generally, users working with a certain non-Latin
script are already used to using a certain font (I mean, they haven't
suddenly teleported into the digital world), and they know perfectly
well which fonts to use for their use case and their language. And for
those users who are a bit more lost, a list of recommended fonts can be
added to the documentation (many of which are already installed on their
system or are included with TeX live).

The other more extreme possibility is to default to GNU unifont
(https://unifoundry.com/unifont/index.html). With this font I think the
readability of almost everything is ensured (although it is a horrible
font, but it is not the case here). Or Google's Noto Fonts (but I don't
remember now what license terms those fonts are under).

Best regards,

Juan Manuel 

Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]

[Gustavo Barros]

Hi All,

On Fri, 29 Oct 2021 at 21:40, Ihor Radchenko  wrote:


Gustavo Barros  writes:

The glitch is that some repeated tasks, when marked done in the 
Agenda, 
show no visual feedback that the action has taken place, as usual, 
and 
if you refresh the Agenda, they just vanish, which demonstrates the 
action had indeed taken place in the agenda file, just not shown in 
the 
Agenda buffer itself.  And, as far as I can tell, this happens to 
repeated tasks, scheduled in future.  For tasks scheduled for today 
or 
in the past, they appear to be done as expected.


Confirmed

Best,
Ihor


This is a respectful bump on this one.

But not to bump empty handed, I did some investigation on this, and I 
think I know why the problem happens.


At `org-agenda-todo' when a task is a repeating one, the value of 
`org-agenda-headline-snapshot-before-repeat' stored at `org-todo' may or 
may not replace `newhead' depending on some conditions, which are:


#+begin_src emacs-lisp
(when (and org-agenda-headline-snapshot-before-repeat
   (not (equal org-agenda-headline-snapshot-before-repeat
   newhead))
   todayp)
 (setq newhead org-agenda-headline-snapshot-before-repeat
just-one t))
#+end_src

So that `newhead' is set to `org-agenda-headline-snapshot-before-repeat' 
only if `todayp' is non-nil.  And, indeed, this seems to be the 
condition which results in the missing visual feedback reported here. 
I've tried without it, and it works.  (I'm currently using built-in 
9.5.2, but I think there's no change in the function to current release 
9.5.4 and also, light testing with the latter suggests no change in the 
reported issue).


What I'm not sure is why this condition is there in the first place. 
That's the only place where the let-bound `todayp' is used in the 
function, so I may be missing why it exists and the purpose of this 
condition.  But one side-effect of it is that, if you happen to do a 
repeating task ahead of schedule, you won't see the change of todo state 
in the agenda.


Best regards,
Gustavo.

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Timothy]

Hi Ihor & co.,

> As I recall, Timothy has been working on simplifying preamble
> generation. If we do not put unnecessary packages into preamble,
> compilation will be significantly faster.
>
> If Timothy can come up with a patch some time soon, I’d prefer to have a
> more targeted preamble. Otherwise, the proposed approach is the way to
> go.

Yep, I’ve got something in my config currently that intercepts LaTeX preamble
creation and generates it only the fly from a list of detected features based on
the exported document and capability providers. I use this in my config to
automatically switch to LuaLaTeX when necessary and use pdfLaTeX the rest of the
time.

This should also be able to be able clean up some of the currently kludgy
preamble modifications like in oc-csl.el.

This has been on the back-burner for a while (I want to implement this is a way
that can be generalised across all output backends), but I’ll see if I can make
some progress and hopefully have a preliminary patch set in the next few weeks.

Lastly, there’s something extra I want to note. If we talk about including a
font customisation, I’d advocate for supporting font sets, not fonts. Once
again, this is something I’m a fan of from my config, and this could potentially
be supported across multiple export formats.

As an illustrative example, if I include this in one of my documents and create
a PDF:
┌
│ #+options: fontset:biolinum
└

Then I’ll get text with:
⁃ libertine roman as the serif font
⁃ biolinum as the serif, and default, font
⁃ source code pro as the mono font
⁃ newtxmath as the maths font

Similarly I can do `fontset:noto' and you can guess what that does.

All the best,
Timothy

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Juan Manuel Macías]

Tim Cross writes:

> Juan, if I understand your proposal correctly, I think your on the right
> track. It sounds like what you are proposing would have almost no impact
> on basic users like me, but would allow those with more demanding
> requirements to adjust without too much effort. I originally raised the
> question regarding what would need to change with the switch to uatex to
> ensure that we do actually get things positioned to enable people to
> exploit the benefits and not just switch out one tool for another which
> only appears to be a little slower. I think what you are suggesting
> addresses that concern. 

Tim, thanks a lot for your interesting comments.

Indeed, I think that LuaTeX is a good direction for the TeX ecosystem.
And it seems that the third edition of The LaTeX Companion makes the way
clear:

https://tex.stackexchange.com/questions/612573/the-latex-companion-3rd-edition/612586

Of course, LuaTeX is still a kind of cyborg (someone defined it that
funny way :-). TeX has not been rewritten here from scratch (that would
have been preferable), but LuaTeX has brought, in my opinion, two
revolutionary things: being able to control TeX internals from a
scripting language as light and minimalist as Lua (which drastically
influences the creation of packages every increasingly powerful and
sophisticated for all areas) and the fact that TeX is finally native
unicode. From the latter, of course, follows the fact that the user is
no longer dependent on Computer Modern and can choose whatever font he
wants, just like in any other modern textual software, from a simple
word processor to more advanced tools like InDesign-style dtp programs.

Even though pdfTeX was light years ahead of InDesign, this simple
operation of choosing the font or font family has always been horribly
difficult in LaTeX. There were a few packages that incorporated specific
font families (Times, Fourier, etc.), but if one wanted to manually
install Adobe Garamond in pdfTeX ---for example---, the process became
absurdly long and cumbersome. Now in LuaLaTeX and XelaTeX that is as
simple as doing it in libreoffice.

Of course, TeX and LaTeX have always had their historical typeface,
Computer Modern, which is almost like one of their distinguishing
features. This extreme reliance on Computer Modern has often given
people who don't use LaTeX the misconception that any document made in
LaTeX always looks the same.

Despite the fact that I feel enormous admiration for Donald Knuth, and I
believe that to a greater or lesser extent many or almost all of us are
indebted to him, I believe that the design of Computer Modern is not
good and has many legibility problems (imho), especially legibility
screen (precisely because of its Didot-style design, with such a marked
contrast between the strokes). Since there is a thread on this list
about accessibility, it's worth remembering that Computer Modern isn't
exactly an easy-to-read font. Of course, you have to put things in their
historical context. When TeX was created there was nothing similar to
what we have today in fonts, there was no truetype or opentype, there
were no free fonts either. It was all to do. And, naturally, if one
creates "a new typesetting system intended for the creation of beautiful
books" (Texbook page 5, Preface), it would be somewhat strange if this
new typesetting system were born without a typeface to show the world
the excellence of TeX. For that reason Knuth created Metafont and the
Computer Modern font.

Now with LuaTeX and XeTeX choosing the font, any font, is easy, fast and
trivial.

> but as I said, I know nothing

I don't think so. Knowing (or not knowing) things or facts (after all, all
of this is just "data") is not the same as being wise and speaking
wisely :-)

Best regards,

Juan Manuel 

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Max Nikulin]

On 11/07/2022 03:23, Juan Manuel Macías wrote:


3. A variable (something like 'org-latex-fontspec-default-configuration') would 
return something like this:

(format
  \\usepackage{iftex}
  \\ifpdftex


I like the idea of unified preamble suitable for pdflatex and lualatex. 
For pdftex \usepackage[...]{fontenc} line may be added here.



  \\relax
  \\else


Is it the case of latex as the old engine with tex->dvi->ps workflow 
besides new XeTeX and LuaTeX? However such engine is not used by Org.



  \\usepackage{fontspec}
  \\usepackage{unicode-math}
  \\defaultfontfeatures{Scale=MatchLowercase}
  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
  \\setmainfont{%s}
  \\setsansfont{%s}
  \\setmonofont{%s}
  \\fi
  org-latex-fontspec-mainfont
  org-latex-fontspec-sansfont
  org-latex-fontspec-monofont)


Too many variables to my taste. It can be single property list. If I 
remember correctly, changing of mainfont requires setting of a 
consistent font for mathematics, so more options may be required.


ox-latex has some code searching for e.g. \usepackage[...]{inputenc} in 
the current configuration to avoid adding of extra copy. It would be 
great to have something similar for fontspec commands. I guess, it is 
harder to detect, since per-language font configuration may be required 
as babel options.


Finally, default value may be language-dependent or alternative font set 
may be activated when non-latin characters are detected in the document.

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Juan Manuel Macías]

Juan Manuel Macías writes:

> By the way, although I've already commented on it in some post in the
> parent thread, i think this package I wrote might be useful for doing a
> quick visual test of a font (including opentype features test), using
> org-latex-preview (compiling with LuaTeX). It can be done on any font
> marked in dired. There are three options: insert arbitrary characters,
> insert the Unicode code of the characters, or display a specimen of the
> font. The default specimen is in the file specimen.tex, which can be
> edited to add examples and languages.
>
> Some screenshots:
>
> https://i.imgur.com/3faKSjA.png
>
> https://i.imgur.com/OJfUcO9.png

Sorry, I forgot the link:

https://gitlab.com/maciaschain/org-font-spec-preview

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Juan Manuel Macías]

Stefan Nobis writes:

> Juan Manuel Macías  writes:
>
>> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
>> (I would vote for nil by default).
>
> I would vote to activate this by default.

I voted nil because of the available fonts issue. But I think what you
say below is a good idea, so it could be activated by default

>> (format
>>  \\usepackage{iftex}
>>  \\ifpdftex
>>  \\relax
>>  \\else
>>  \\usepackage{fontspec}
>>  \\usepackage{unicode-math}
>>  \\defaultfontfeatures{Scale=MatchLowercase}
>>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>>  \\setmainfont{%s}
>>  \\setsansfont{%s}
>>  \\setmonofont{%s}
>>  \\fi
>>  org-latex-fontspec-mainfont
>>  org-latex-fontspec-sansfont
>>  org-latex-fontspec-monofont)
>
> I would prefer to make it easier to stick with the default fonts. So
> only add the font selection commands (including defaultfontfeatures)
> when the font variables are non-nil. If no font has been explicitly
> chosen, just use the default (in case of lualatex Latin Modern).
>
> For me, it does not matter whether the 'org-latex-fontspec-*'
> variables have a default of nil or set to the Free* fonts or something
> else. For my configuration, I would set these variable to nil in order
> to get the LaTeX default fonts and would like to go with the default
> preamble of Org and then add to this on a per document basis.
>
> This way, the whole configuration would be a little more composable, I
> think.

Sounds like a good idea and I agree. If I understand correctly, if the
sans, roman, and mono font variables (or any of them) are non-nil,
enable font selection. Otherwise, leave the default Latin Modern font.

By the way, although I've already commented on it in some post in the
parent thread, i think this package I wrote might be useful for doing a
quick visual test of a font (including opentype features test), using
org-latex-preview (compiling with LuaTeX). It can be done on any font
marked in dired. There are three options: insert arbitrary characters,
insert the Unicode code of the characters, or display a specimen of the
font. The default specimen is in the file specimen.tex, which can be
edited to add examples and languages.

Some screenshots:

https://i.imgur.com/3faKSjA.png

https://i.imgur.com/OJfUcO9.png

To create font tables I often use the LaTeX package unicodefonttable. An
example of usage within Org:

#+header: :headers '("\\usepackage{unicodefonttable}")
#+begin_src latex :imagemagick yes :iminoptions -density 600 :results raw 
:results file :file -2256080143431736233.png
\displayfonttable*[range-start=1F00,range-end=1FFE]{Old Standard}
\displayfonttable*[range-start=0600,range-end=06FF]{FreeSerif}
#+end_src

A screenshot:

https://i.imgur.com/Fwsg7bb.png

Maybe it could also be added as an emergency fallback font GNU Unifont:

https://unifoundry.com/

Best regards,

Juan Manuel 

Re: [BUG] right shift list checkbox with [Alt-Right] caused error by option org-list-demote-modify-bullet

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> When setting this option:
>
> #+begin_src emacs-lisp
> (setq org-list-demote-modify-bullet '(("+" . "-") ("-" . "+") ("*" . "+")))
> #+end_src
>
> I right shift list checkbox with [Alt-Right] caused error:
> ...
> Become:
>
> - [ ] list item 1
>   [ ] ] list item 2
> #+end_src

Thanks for reporting!
Fixed on main via 654005394.

Best,
Ihor

Re: [Sporadically?,] Google does not properly crawl/index the Org mailing list archives?

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> I (quickly) searched the list but did not find that the issue was
> raised before, so here I go.
>
> I had saved for myself an excerpt from the list archive.  I wanted to
> consult again the whole thread, so I type into Google:
>
>"primarily latex/natbib users like john"
>
> and I get:
>
>Your search - "primarily latex/natbib users like john" - did not
>match any documents.
>
> But I do find it by performing the same search with Duckduckgo
> (https://duckduckgo.com/).

FYI, on my side, DuckDuckGo yields 0 results. So, apparently it depends
on your location.

> So what can be going on?  Can it be a problem on my side?  (Indeed,
> depending on the computer on which I perform the Google search,
> sometimes I am provided with the "results without quotes" -- although
> the target message does not seem to be there).  A problem on the Org
> site (that Duckduckgo managed to overcome)?
>
> At any rate, I thought this might be worth reporting.

AFAIK, GNU mailing lists are poorly indexed. I am not sure why. Note
that Org ML archive is fully available at
https://lists.gnu.org/archive/html/emacs-orgmode/
and
https://list.orgmode.org/

Best,
Ihor

Re: Org mode escape characters

[Ihor Radchenko]

David Boss  writes:

> Org mode is very crude: it indicates italics by surrounding text by slashes, 
> and so,
> what if the original text contained slashes, intended as ordinary
> text, not escape characters? What if the slashes themselves are
> intended to be italicized?

You can then surround them by zero-width spaces. See 
https://orgmode.org/manual/Escape-Character.html#Escape-Character

> Is there some way to tell Org mode to use different escape characters?

No, currently.

> Or to make ordinary emacs characters with the italic property, copy
> and paste, like God intended?

Probably htmlize? https://github.com/hniksic/emacs-htmlize

Best,
Ihor

Re: [PATCH] org-src.el: Add plain to org-src-window-setup customization

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> Bastien, could you please add Matt to tiny change contributor list?

Done in https://git.sr.ht/~bzg/worg/commit/f7825a7c, also sorting the
list of names.

-- 
 Bastien

Org mode escape characters

[David Boss]

I generally run in Fundamental mode. Since ASCII is really only a 7-bit code, I 
use the high bit to indicate italics. I wrote a Java program for printing; it 
makes all characters 16-bit, despite their starting as 8-bit,so no problem. For 
emacs, I wrote the necessary hooks to catch high bits in a file's 8-bit 
characters; on readin, the high bits are cleared, and characters intended to be 
italic get an italic property, instead; on writeout, characters with the italic 
property get their high bits set; no sweat, the hooks work.
I want to be able to copy an emacs buffer, with some characters having italic 
mode set, and paste that into an email compose buffer, and have the italics set 
in the email buffer; this should work, but it doesn't, whoknows, who cares, why 
not. But if I copy/paste a .odt file, with italicized characters, the italics 
show up as intended, in the email buffer. But, how to generate the .odt file? 
Pandoc, of course, but pandoc only eats emacsfiles if they're Org mode. So, I 
wrote a lisp function, to generate the Org mode file I need, from  
fundamental-mode-plus-hooks emacs. And yes, pandoc will eat the Org mode file, 
as intended, and convert it to .odt, as intended, and I can copy/paste the 
.odt, and italics show up, as intended, in the email buffer. Except,
Org mode is very crude: it indicates italics by surrounding text by slashes, 
and so,
what if the original text contained slashes, intended as ordinary text, not 
escape characters? What if the slashes themselves are intended to be italicized?
Is there some way to tell Org mode to use different escape characters? Or to 
make ordinary emacs characters with the italic property, copy and paste, like 
God intended?


 David Boss

[Sporadically?,] Google does not properly crawl/index the Org mailing list archives?

[Alain . Cochard]

Hello.  

I (quickly) searched the list but did not find that the issue was
raised before, so here I go.

I had saved for myself an excerpt from the list archive.  I wanted to
consult again the whole thread, so I type into Google:

   "primarily latex/natbib users like john"

and I get:

   Your search - "primarily latex/natbib users like john" - did not
   match any documents.

But I do find it by performing the same search with Duckduckgo
(https://duckduckgo.com/).

So what can be going on?  Can it be a problem on my side?  (Indeed,
depending on the computer on which I perform the Google search,
sometimes I am provided with the "results without quotes" -- although
the target message does not seem to be there).  A problem on the Org
site (that Duckduckgo managed to overcome)?

At any rate, I thought this might be worth reporting.


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 106]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Stefan Nobis]

Juan Manuel Macías  writes:

> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).

I would vote to activate this by default.

> (format
>  \\usepackage{iftex}
>  \\ifpdftex
>  \\relax
>  \\else
>  \\usepackage{fontspec}
>  \\usepackage{unicode-math}
>  \\defaultfontfeatures{Scale=MatchLowercase}
>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>  \\setmainfont{%s}
>  \\setsansfont{%s}
>  \\setmonofont{%s}
>  \\fi
>  org-latex-fontspec-mainfont
>  org-latex-fontspec-sansfont
>  org-latex-fontspec-monofont)

I would prefer to make it easier to stick with the default fonts. So
only add the font selection commands (including defaultfontfeatures)
when the font variables are non-nil. If no font has been explicitly
chosen, just use the default (in case of lualatex Latin Modern).

For me, it does not matter whether the 'org-latex-fontspec-*'
variables have a default of nil or set to the Free* fonts or something
else. For my configuration, I would set these variable to nil in order
to get the LaTeX default fonts and would like to go with the default
preamble of Org and then add to this on a per document basis.

This way, the whole configuration would be a little more composable, I
think.

-- 
Until the next mail...,
Stefan.

Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

[Stefan Nobis]

Ihor Radchenko  writes:

> But can someone check if Free* fonts are available on Windows and
> Mac by default?

I just checked TeXLive (on MacOS, but should be the same on all
systems): The Free* fonts are part of TeXLive as truetype and as
opentype versions (and partly in other formats).

For Windows I remember vaguely that some prefer the MikTeX
distribution (TeXLive is also available for Windows and has the same
fonts as everywhere). A short search shows that the gnu-freefont set
is also availabe for MikTeX, but I currently don't know whether it
will be installed with a default MikTeX installation.

> This unified preamble approach is consistent with what we do now.
> However, our currently used large preambles will slow down compilation.

Not that much. The time consuming packages like tikz/pgf (used by
beamer) are not part of out default preamble. There is not that much
speed to gain (all times are for a single lualatex run):

1) Only hyperref loaded, no other packages:
   0.46s user 0.10s system 99% cpu 0.568 total

2) Complete default preamble for lualatex:
   0.48s user 0.14s system 99% cpu 0.623 total

3) The same as above, but with babel and mathtools:
   0.51s user 0.15s system 99% cpu 0.673 total

4) And another variant (same as before, but package caption instead of
   capt-of):
   0.53s user 0.14s system 98% cpu 0.674 total

5) Back to our default preamble, but adding fontspec:
   0.60s user 0.14s system 99% cpu 0.748 total

6) With fontspec, unicode-math, babel, mathtools, caption:
   1.02s user 0.19s system 99% cpu 1.220 total

Therefore most of out default packages (and even the addition of
babel) does not change much for the speed of compilation. I don't
think its worth to try to further optimize this default preamble.

Adding fontspec and especially unicode-math adds quite some time, so
maybe its worth to take care to only add these if necessary (only for
lualatex/xelatex and only if e.g. if a font has been selected or math
seems to be used in the document).

And, by the way, our preamble is neither large nor complex. For my
LaTeX documents, the preamble is usually *much* larger. :)


Here is the test file for the default preamble (but with mathtools
instead of amsmath and with babel; test run 3):

--8<---cut here---start->8---

% Intended LaTeX compiler: lualatex
\documentclass{article}
\usepackage[english, safe=none, math=normal]{babel}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\date{\today}
\title{Test Document}
\hypersetup{
 pdfcreator={Emacs 28.1 (Org mode 9.5.4)},
 pdflang={English}}
\begin{document}
This is a short test document.
\end{document}

--8<---cut here---end--->8---


Here is the test file for the last run with all extra packages:

--8<---cut here---start->8---

% Intended LaTeX compiler: lualatex
\documentclass{article}
\usepackage{fontspec}
\usepackage[english, safe=none, math=normal]{babel}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage[warnings-off={mathtools-colon,mathtools-overbracket}]{unicode-math}
\usepackage{caption}
\usepackage{hyperref}
\date{\today}
\title{Test Document}
\hypersetup{
 pdfcreator={Emacs 28.1 (Org mode 9.5.4)},
 pdflang={English}}
\begin{document}
This is a short test document.
\end{document}

--8<---cut here---end--->8---



-- 
Until the next mail...,
Stefan.

[BUG] right shift list checkbox with [Alt-Right] caused error by option org-list-demote-modify-bullet

[Christopher M. Miles]

When setting this option:

#+begin_src emacs-lisp
(setq org-list-demote-modify-bullet '(("+" . "-") ("-" . "+") ("*" . "+")))
#+end_src

I right shift list checkbox with [Alt-Right] caused error:

#+begin_src org
,* test

- [ ] list item 1
- [ ] list item 2

Become:

- [ ] list item 1
  [ ] ] list item 2
#+end_src


-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature