Re: [BUG] Questionmarks in org-agenda instead of file names [9.5.2 (9.5.2-g3154c2 @ /Users/eugr/.emacs.d/straight/build/org/)]

[Eugene Rakhmatulin]

On Fri, Jan 28, 2022 at 10:16 PM Ihor Radchenko  wrote:

> This is a big strange.
> Can you try to repeat the same steps, but removing the contents of
> org-persist-directory before opening Emacs?

So, I've removed this directory on both computers - haven't been able
to reproduce this bug so far... However even before I've done this it
was intermittent with no clear pattern, so I'll keep monitoring, but
let's hope it was some kind of cache issue after Org upgrade from 9.3
to the current version...

Re: [PATCH] Add support for $…$ latex fragments followed by a dash

[João Pedro de Amorim Paula]

On 01 February 2022 22:00, Rudolf Adamkovič  wrote:

> Me, I cannot use any of these "pretty" features because, simply put,
> they break plain text.  For example, they cause misaligned tables and
> make the text overflow the fill column, which I keep at 72 columns.

I know that this is a bit divergent from the original subject -- and
also keep in mind that this shouldn't be considered a solution to the
problem, given that it should be considered for all users with different
fonts --, but there are fonts that enforce Unicode (all characters, from
what I understand, Unicode included) characters to be exactly 1 unit
width, i.e. Unicode characters are the same widths as other characters.
At least I can guarantee that any of the Term (all characters are the
same length, but has ligatures) or Fixed (same as Term but no ligatures)
for Iosekva [1] have this given property.

[1] https://typeof.net/Iosevka/

Best regards,

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [PATCH] Add support for $…$ latex fragments followed by a dash

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> We can theoretically make a change to support "-", but then it will be
> logical to support $i$th as well. […]

I do not know about others, but supporting the dash alone would mean a
world to me.  In fact, I never use \(\) for anything else in all my Org
documents.  That dash, though, it constantly gets into my way.

> 1. Fontify \(...\) replacing the brackets with a single character. For
>example:
>
>   \(...\) -> ⁅...⁆

Me, I cannot use any of these "pretty" features because, simply put,
they break plain text.  For example, they cause misaligned tables and
make the text overflow the fill column, which I keep at 72 columns.

> 2. Provide convenient way to input \(\) brackets through
>electric-pair-mode or trough org-cdlatex-mode.

This would help a bit.

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass, 1871/1872

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [PATCH] Add support for $…$ latex fragments followed by a dash

[Max Nikulin]

manual states:



Text within the usual LaTeX math delimiters. To avoid conflicts with
currency specifications, single ‘$’ characters are only recognized as
math delimiters if the enclosed text contains at most two line breaks,
is directly attached to the ‘$’ characters with no whitespace in
between, and if the closing ‘$’ is followed by whitespace, punctuation
or a dash. For the other delimiters, there is no such restriction, so

  ^^

when in doubt, use ‘\(...\)’ as inline math delimiters.


It is even more interesting. Support of dash likely was unintentionally 
lost in the following commit:

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6779f8f424883ffd202e24cbd8bb4e241db294b0
that generalizes handling of punctuation, unfortunately dash and 
apostrophe are not always belong to punctuation symbols in *text* modes. 
That commit even updates manual to a less precise phrase, however .texi 
file only, so the change was lost. Nicolas later restored apostrophe in 
the commit c0369a798470763f8f3c69cf2079c3a194635feb



False positive with the proposed patch:

 > Balance decreased from $10 to negative value ($-2 approximately)

certainly it is more rare than $n$-th valid case.

Tim, as mentioned before I’m strongly in favour of a ~half decade 
transition


Half of decade already passed since dash after currency symbol was 
broken so maybe it is better to fix current state by updating the manual 
(including bugfix branch) and by adding some tests.


P.S. It is deja vu, I almost certainly saw quite recent discussions 
whether punctuation may be handled in some regexps in more generic way. 
Consequences may be similar in respect to characters that are almost 
punctuation...

Re: [BUG] Confirmation message for elisp links is badly formatted [9.5.2 (9.5.2-gfbff08 @ /home/omarantolin/.emacs.d/elpa/org-9.5.2/)]

[Max Nikulin]

On 31/01/2022 18:38, Timothy wrote:


Thanks for the report, I’ve fixed this in b3ceafd0 :)


Timothy, could you, please, commit a similar fix for shell: links. They 
have the same problem introduced in the same commit 
http://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a486d9cbd7491741554944a116f81b02f6b35e4b


(old function name was org--open-elisp-link and the code was surrounded 
with quotes)

[FR][org-cite][oc-basic] Display Editor of Volume in Completion Table

[psychosis]

Hello,

when executing org-cite-insert with the oc-basic processor, the 
“author”-field in the completion table is empty for edited volumes. 
Is it possible to set the “editor”-field as a fallback in case the 
“author”-field is empty, as is the case for edited volumes?



Thanks and regards,

Paul

[FR][org-cite][oc-basic] Persistent Cache for Bibliography

[psychosis]

Hello,

thanks to everybody who contributed to the excellent org-cite. I am 
satisfied with oc-basic, but org-cite-insert takes ten minutes on first 
execution to load the .bib-file. (This was already discussed here: 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00466.html)
After the first execution however the .bib-file is loaded immediately. 
I assume this has to do with the cache mentioned here: 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-11/msg00067.html.
Unfortunately it seems that this cache does not persist after emacs is 
terminated. Would it be possible to make it persistent to eliminate the 
load time on the first execution of org-cite-insert?



Regards,

Paul

Re: [BUG] Confirmation message for elisp links is badly formatted [9.5.2 (9.5.2-gfbff08 @ /home/omarantolin/.emacs.d/elpa/org-9.5.2/)]

[Timothy]

Hi Max,

> Timothy, could you, please, commit a similar fix for shell: links. They have 
> the
> same problem introduced in the same commit
> 

Pushed in e7ea951 :)

All the best,
Timothy

Re: [BUG] elisp links: cluttered prompt due to text properties

[Max Nikulin]

On 11/11/2021 21:58, Max Nikulin wrote:

Try to "open" the following link (C-c C-o)

[[elisp:(require 'org-capture)][M-: (require 'org-capture)]]

Actual behavior:

 > Execute #("(require 'org-capture)" 0 22 (face org-warning)) as Elisp? 
(yes or no)


Expected behavior:

 > Execute "(require 'org-capture)" as elisp? (yes or no)


Accordingly to

Timothy. [BUG] Confirmation message for elisp links is badly formatted 
[9.5.2 (9.5.2-gfbff08 @ /home/omarantolin/.emacs.d/elpa/org-9.5.2/)]

Mon, 31 Jan 2022 19:38:18 +0800.
https://list.orgmode.org/87v8y0m8xa@gmail.com

fixed in b3ceafd0