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

[Ihor Radchenko]

Eugene Rakhmatulin  writes:

>> Can you try the following:
>> 1. (setq org-element--cache-self-verify 'backtrace) in your init.el
>>before loading org
>> 2. Do whatever it takes to get question marks as category in agenda
>> 3. Go to the problematic Org buffer and run
>>M-: (org-element--cache-warn "Backtrace") 
>> 4. Send the contents of the warning message here.
>
> Here we go. Hope this helps!
>
> Warning (org-element-cache): org-element--cache: Warning(p-tasks.org): 
> Backtrace
> Backtrace:
> ...

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

Best,
Ihor

Is org-block really the intended face for captions?

[Kai Harries]

Hello,

this is my first post to this mailing list.  Great thanks to all of you
that have made org-mode such a wonderful tool.

I usually have lots of code-blocks in my org-mode documents.  I recently
decided to give them another background color (by modifying the face
"org-block") to distinguish them better from the rest of the document.
That was when I noticed that the same face (org-block) was used also for
captions.  Is this really intended?  Attached is my naive attempt to
change this by applying the org-default face to the captions.  So my
question, could we change the face for captions?  Which face should be
used, org-default or should a new face be introduced?

Best regards

Kai

>From ac81515cc85edf36c2ea32028e557362a4bc6d3a Mon Sep 17 00:00:00 2001
From: Kai Harries 
Date: Sat, 29 Jan 2022 07:33:21 +0100
Subject: [PATCH] org-fontify-meta-lines-and-blocks: use org-default face for
 caption

Previous the face org-block was used for captions.  That looks quite
awkward if you decide to change the background color of org-block to
make code-blocks, etc. stand out.  TBH I don't really understand the
reasoning behind choosing org-block as face for captions but IMHO
org-default seems to me a saner choice.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index d58f6af55..8eaf5b0de 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5387,7 +5387,7 @@ by a #."
 	  (add-text-properties (line-beginning-position) (match-end 1)
 			   '(font-lock-fontified t face org-meta-line))
 	  (add-text-properties (match-end 0) (line-end-position)
-			   '(font-lock-fontified t face org-block))
+			   '(font-lock-fontified t face org-default))
 	  t)
 	 ((member dc3 '(" " ""))
 	  ;; Just a comment, the plus was not there
-- 
2.33.1

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Max Nikulin  writes:

> It could be used for one more purpose. I miss "fallback" option for 
> export snippets. E.g. if explicit raw markup is specified for HTML and 
> LaTeX, it would be nice to have something for other backends such as 
> ascii or odt. In the series of adjacent export snippets @@:...@@ may be 
> taken when backends in earlier snippets are not matched:

This reminds me about our #+begin_export export blocks and #+begin_*
special blocks. We can think of @@backend:...@@ snippets as inline
equivalent of export blocks. Special blocks do not have inline
equivalent (except maybe links abused for export by some people).

Keeping in mind the above analogy, note that export blocks do not have
fallbacks, while special blocks do (for example, see
https://github.com/alhassy/org-special-block-extras/).

Maybe we should introduce an equivalent of special blocks, but for
inline use? Or should we modify _both_ inline export snippets and export
blocks to allow fallback mechanism?

Best,
Ihor

Re: [BUG] Cached element is incorrect in file.org [9.6 (9.6-??-0c9b30e @ /Users/jeffballowe/.emacs.d/.local/straight/build-27.2/org/)]

[Ihor Radchenko]

Jeff  writes:

> Sorry for the delay responding.

No problem. This list does not have reddit pacing :)

> The problem resolved after updating Doom Emacs.

Great!

> I’m not sure why it resolved, because the org-mode version remained
> the same.

Doom Emacs uses development version of Org mode. As you update, only
latest commit number in the version is going to change:

M-x org-version
Org mode version 9.5.2 (9.5.2-g2c70ca <-- latest commit number

> I am new to emacs and so also to Doom Emacs. I’m not sure if
> it is good practice to upgrade Doom Emacs packages I’m using with my
> Doom configuration or my wait until Doom does that in a Doom Emacs
> upgrade.

You may consider Doom Emacs upgrade as slightly more stable compared to
manual update ahead of other Doom users. This particular problem with
Org appears because we introduced a major and complex change to Org. It
is not yet stable. We are fixing incoming bugs as they are reported.
Things should be more stable in a few months.

Best,
Ihor

Re: [BUG] Cached element is incorrect in file.org [9.6 (9.6-??-0c9b30e @ /Users/jeffballowe/.emacs.d/.local/straight/build-27.2/org/)]

[Jeff]

Hello, Ihor, and thank you for the very fast reply.

Sorry for the delay responding.

The problem resolved after updating Doom Emacs. I’m not sure why it resolved, 
because the org-mode version remained the same. I am new to emacs and so also 
to Doom Emacs. I’m not sure if it is good practice to upgrade Doom Emacs 
packages I’m using with my Doom configuration or my wait until Doom does that 
in a Doom Emacs upgrade. 

In any case, problem solved, at least for now.

I love org-mode! It is already a huge part of my life.

Thank you for the help.

Best,
Jeff
> On Jan 22, 2022, at 2:36 AM, Ihor Radchenko  wrote:
> 
> Jeff  writes:
> 
>> What I expected to happen: No error message when editing this file.
>> 
>> What, in fact, did happen and happens frequently (no pattern
>> discerned): I get this error message. Everything seems to work ok other than 
>> getting this error message frequently.
> 
> Thanks for the report!
> Your Org mode appears to be 1 month old. Can you try to update?
> 
> If update does not solve the problem, can you set
> org-element--cache-self-verify to 'backtrace and share the backtrace
> displayed in the message next time you see it?
> 
> Best,
> Ihor

Re: date format in agenda view

[Juan Manuel Macías]

Hi Uwe,

Uwe Brauer writes:

> How can I obtain the Spanish week names?

I have this in my init:

#+begin_src emacs-lisp
(setq calendar-week-start-day 1
  calendar-day-name-array ["domingo" "lunes" "martes" "miércoles"
   "jueves" "viernes" "sábado"]
  calendar-month-name-array ["enero" "febrero" "marzo" "abril" "mayo"
 "junio" "julio" "agosto" "septiembre"
 "octubre" "noviembre" "diciembre"])
#+end_src

(https://www.emacswiki.org/emacs/CalendarLocalization#toc18)

Best regards,

Juan Manuel 

Re: date format in agenda view

[Uwe Brauer]

>>> "JMM" == Juan Manuel Macías  writes:

> Hi Uwe,
> Uwe Brauer writes:

>> How can I obtain the Spanish week names?

> I have this in my init:

> #+begin_src emacs-lisp
> (setq calendar-week-start-day 1
>   calendar-day-name-array ["domingo" "lunes" "martes" "miércoles"
>  "jueves" "viernes" "sábado"]
>   calendar-month-name-array ["enero" "febrero" "marzo" "abril" "mayo"
>"junio" "julio" "agosto" "septiembre"
>"octubre" "noviembre" "diciembre"])
> #+end_src

Ha, thanks, I just realized I have this setting but embedded in a function in 
order to switch between English, Spanish and German. Memory☹️


smime.p7s
Description: S/MIME cryptographic signature

couldn't org-table-create-with-table\.el respect hline

[Uwe Brauer]

Hi

I start with 



| Example | Text| Dates| other   |
|-+-+--+-|
| this| comment | <2022-01-28 vie> | nothing |


That is converted to 



+-+-+--+-+
| Example | Text| Dates| other   |
+-+-+--+-+
| this| comment | <2022-01-28 vie> | nothing |
+-+-+--+-+


And is converted back to 


| Example | Text| Dates| other   |
| this| comment | <2022-01-28 vie> | nothing |


Couldn't in the last step the hlines be respected?

Regards

Uwe Brauer 

date format in agenda view

[Uwe Brauer]

Hi

I have set my language environment to spanish
and indeed org-time-stamp inserts <2022-01-28 vie>
Viernes=Friday

However I have an agenda file with entries like this 

* <2022-01-28 vie> dinner

But in agenda view it is displayed as 

Friday 28 January 2022
  file:   dinner


How can I obtain the Spanish week names?

Thanks 

Uwe Brauer 

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

[Timothy]

Hi Max,

> There is no point to discuss deprecation of $…$ and ... while usage of
> such constructs is not discouraged by the org manual

Isn’t the point of discussing depreciation now that we’d change the manual etc.
to discourage it? 😛

FWIW, I have an extra 2c to add: I think that there’s a danger in having $…$
/almost/ behave like LaTeX, as the closer it is the more surprising the edge 
cases
are, and due to the nature of Org there will /always/ be a collection of edge
cases with $…$. By comparison, \(…\) has much less ’surprising’ behaviour.

>> If we do deprecate support for $…$, it might also be a good idea to
>> see if we can add a utility function which would make it easier for
>> people to migrate existing documents to the new/alternative syntax. For
>> the same reason it is hard to reliably parse $…$ syntax, we probably
>> can’t automate that transition, but we should be able to reduce the effort
>> required to update existing documents.

Tim, as mentioned before I’m strongly in favour of a ~half decade transition
including utility functions to shift existing TeX constructs to LaTeX, and
adding warnings, well before dropping support.

All the best,
Timothy

Re: Org-syntax: Intra-word markup

[Max Nikulin]

On 05/12/2021 04:48, Tom Gillespie wrote:

Since org is a valid export backend though, perhaps this behaviour should be
reserved for @@:…@@, i.e. no export backend, which I think semantically fits
fairly nicely.


...

What this means is that @@:...@@ syntax is not actually used
in Org at all at the moment and renders as plain text. I agree that
we need to avoid @@org:..@@ because it has legitimate uses.
Making a back-end of empty string valid for parse separately
syntax thus makes @@ syntax more regular overall, and allows
@@:...@@ to be processed separately because it currently
never enters the export snippet processing.


It seems that @@:...@@ should behave significantly different from 
regular export snippet since org markup should be parsed inside.


It could be used for one more purpose. I miss "fallback" option for 
export snippets. E.g. if explicit raw markup is specified for HTML and 
LaTeX, it would be nice to have something for other backends such as 
ascii or odt. In the series of adjacent export snippets @@:...@@ may be 
taken when backends in earlier snippets are not matched:


@@html:HTML 1latex:LaTeX 1:ascii and odt 1html: HTML 
2:LaTeX, ascii, and odt 2@@.


At first I complained that it would be impossible to put export snippets 
in "parse separately" construct with @@:...@@ syntax. Likely it is not 
necessary. It is a bit verbose, but "parse separately" may be split:

   @@:part 1html:html-only::part 2@@
Empty @@:@@ is added to avoid considering @@:part 2@@ as a fallback for 
"html-only".

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

[Max Nikulin]

On 28/01/2022 02:15, Tim Cross wrote:


If we do deprecate support for $...$, it might also be a good idea to
see if we can add a utility function which would make it easier for
people to migrate existing documents to the new/alternative syntax. For
the same reason it is hard to reliably parse $...$ syntax, we probably
can't automate that transition, but we should be able to reduce the effort
required to update existing documents.


There is no point to discuss deprecation of $...$ and $$...$$ while 
usage of such constructs is not discouraged by the org manual info 
"(org) LaTeX fragmets" https://orgmode.org/manual/LaTeX-fragments.html 
and by the compact guide https://orgmode.org/guide/Embedded-LaTeX.html


Even though org syntax says that support of these constructs ought to be 
removed, users expect that they should work well.

Re: [PATCH] Intra-word markup: \relax

[Juan Manuel Macías]

Max Nikulin writes:

> I have an idea how to implement *intra*/word/ markup with minimal
> change of Org syntax. At first I had a hope that it is enough to
> introduce \relax entity that expands to empty string, but it does not
> work for second part of words: *intra*\relax{}/word/ is exported to
> intra/word/.
> So it is necessary to support consuming spaces after such entity
> similar to TeX commands:
> *intra*\relax /word/
> In Org "a\_  b" already behaves in the same way.
>
> I do not like zero-width spaces since they are invisible, so they are
> not really "text" markup. Moreover, it is better to filter them out 
> during export.
>
> Another failed idea was to use export snippet or a macro for such purpose:
> #+macro sep $1
> *intra*{{{sep()}}}/word/, *intra*@@html:@@/word/
>
> Important point that suggested solution works for all export backends.
> I do not consider explicit export snippets as a workaround since it 
> requires code for all backends in org files.

Maxim, I find the idea of \relax entity interesting. The only (minor)
drawback I find (in normal use, I mean) is the verbosity it adds.

In my case, I have already given up on the problem of marks inside words
:-(. My personal opinion: I think that, unless a completely
'revolutionary' solution emerges, it is better to leave the matter as it
is, and consider this a feature of Org rather than a bug. I suspect that
a single solution could not satisfy all tastes or all possible
scenarios, so maybe it would be nice to put a list of solutions
(including this one and also the zero space thing, and others that have
arisen or may arise) somewhere (perhaps in the manual?). What doesn't
quite convince me (and I agree with you on that) is recommending zero
width space as a sort of 'official' escape character. For the reasons
you have expressed, which I think are very fair.

Best regards,

Juan Manuel 

emacs-orgmode@gnu.org

[Max Nikulin]

On 27/01/2022 07:03, chris wrote:


First: `xdg-open "org-protocol://store-link?url=URL&title=TITLE"` from a 
terminal.

Then `M-x org-insert-link` in emacs, or not (it makes no difference).
Then cut-and-paste from non-emacs-application (e.g., Kde's Konsole, or 
Firefox) to emacs.
When doing `C-y` what it pastes is "URL", not what I have copied from 
Firefox.


Just a data point: I can not reproduce it with X11, emacs-26.3, and Org 
from git main HEAD. Maybe I will try with emacs-27 and Wayland in a few 
days.


emacs -Q -L ~/src/org-mode/lisp/ \
  -l org-protocol --eval '(server-start)' test.org
emacsclient 'org-protocol:/store-link?url=http://o.rg/&title=Tt1'
copy from firefox
C-y (org-yank) in Emacs pastes text that I copied from firefox.

In some aspects your problem looks similar to:

Max Nikulin. [PATCH] [BUG] org.el: Fix first call of `org-paste-subtree' 
Mon, 29 Nov 2021 19:02:35 +0700.

https://list.orgmode.org/so2fh1$10kj$1...@ciao.gmane.io



But why is there a `nil` here:

https://github.com/emacs-mirror/emacs/blob/19dcb237/lisp/org/org-protocol.el#L467 



And why is it working at all from `xdg-open 
"org-protocol://store-link?url=URL&title=TITLE"`, with a `nil` in that 
position?


Note: `(org-protocol-store-link "U/T")` works, `(org-protocol-store-link 
"url=U&title=T")` doesn't work. Produces link `[[url=U&title=T]]` 
instead of `[[U][T]]`.


What is the problem with nil there? New-style URIs are parsed before 
they are passed to subprotocol handlers. Why are you trying to call 
org-protocol-store-link directly?

Re: [BUG] org-protocol-store-link does not account for argument type

[Max Nikulin]

On 28/01/2022 01:15, Thuna wrote:



See the last paragraph of the docstring:


FNAME should be a property list.  If not, an old-style link of the

  ^^

form URL/TITLE can also be used."


You pass a string for *new* URI style.


I see, it seems I have misunderstood the documentation then.  My
apologies for the inconvenience.


I think, you have missed an opportunity to get a suggestion concerning 
you actual problem. You original report and the response were so brief 
that it is impossible to guess the context of the question and your goal.


Code org-protocol has enough hacks and the functions unlikely should be 
called from outside. Defining new subprotocol is likely the only case 
when it is necessary to understand arguments of functions. I suspect a 
function appropriate for your purpose is defined somewhere else.

[PATCH] Intra-word markup: \relax

[Max Nikulin]

On 02/12/2021 17:50, Denis Maier wrote:


Currently, org syntax doesn't officially seem to support intra-word 
emphasis. Am I missing something?
If the assessment is correct: Is there a reason for this? And, shouldn't 
that be officially added?


I have an idea how to implement *intra*/word/ markup with minimal change 
of Org syntax. At first I had a hope that it is enough to introduce 
\relax entity that expands to empty string, but it does not work for 
second part of words: *intra*\relax{}/word/ is exported to

intra/word/.
So it is necessary to support consuming spaces after such entity similar 
to TeX commands:

*intra*\relax /word/
In Org "a\_  b" already behaves in the same way.

I do not like zero-width spaces since they are invisible, so they are 
not really "text" markup. Moreover, it is better to filter them out 
during export.


Another failed idea was to use export snippet or a macro for such purpose:
#+macro sep $1
*intra*{{{sep()}}}/word/, *intra*@@html:@@/word/

Important point that suggested solution works for all export backends. I 
do not consider explicit export snippets as a workaround since it 
requires code for all backends in org files.From 95a0dcb1370577409388e137dae98ec4c1af5bbd Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Fri, 28 Jan 2022 18:55:54 +0700
Subject: [PATCH] Intra-word markup: \relax

lisp/org-element.el (org-element-entity-parser): Parse \relax entity
with following spaces.

lisp/org-entities.el (org-entities): Add "\relax " entities with various
number of spaces expanding to nothing.

Allow "*intra*\relax /word/" markup change withing continuous word.  It
is not enough to just add "relax" entity since while it allows
"*intra*\relax{}word", characters after "{}" are not considered as
emphasis markers "intra\relax{}/word/".  The name is similar to the TeX
command. Consuming spaces following a command is usual behavior of TeX
commands as well.
---
 lisp/org-element.el  | 2 +-
 lisp/org-entities.el | 7 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index b82475a14..83001fd74 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3159,7 +3159,7 @@ a plist with `:begin', `:end', `:latex', `:latex-math-p',
 
 Assume point is at the beginning of the entity."
   (catch 'no-object
-(when (looking-at "\\(?:\\(?1:_ +\\)\\|\\(?1:there4\\|sup[123]\\|frac[13][24]\\|[a-zA-Z]+\\)\\(?2:$\\|{}\\|[^[:alpha:]]\\)\\)")
+(when (looking-at "\\(?:\\(?1:\\(?:_\\|relax\\) +\\)\\|\\(?1:there4\\|sup[123]\\|frac[13][24]\\|[a-zA-Z]+\\)\\(?2:$\\|{}\\|[^[:alpha:]]\\)\\)")
   (save-excursion
 	(let* ((value (or (org-entity-get (match-string 1))
 			  (throw 'no-object nil)))
diff --git a/lisp/org-entities.el b/lisp/org-entities.el
index 2bd4f2fe3..f6177c471 100644
--- a/lisp/org-entities.el
+++ b/lisp/org-entities.el
@@ -526,7 +526,12 @@ packages to be loaded, add these packages to `org-latex-packages-alist'."
 		 spaces
 		 spaces
 		 (make-string n ?\x2002))
-	   space-entities)
+	   space-entities
+   ;; Add "\relax " space-eating entity family for "intra\relax *word*" markup.
+   (mapcar (lambda (n)
+ (list (concat "relax" (make-string n ? )) "" nil "" "" "" ""))
+ (number-sequence 0 20)))
+
   "Default entities used in Org mode to produce special characters.
 For details see `org-entities-user'.")
 
-- 
2.25.1

[ISSUE] Re: [PATCH] lisp/org-agenda.el: Add header to agenda clock report table

[Christopher M. Miles]

I tested this commit, it should auto append a newline character after
~org-agenda-clock-report-header~. Otherwise the header line will in same line 
with table first line.

Samim Pezeshki  writes:

> Thanks Nicolas for reviewing the changes!
>
> I applied the changes.
> Attached is the updated patch.
>
> On Fri, Jan 21, 2022 at 1:58 PM Nicolas Goaziou  
> wrote:
>
>  Hello,
>
>  Samim Pezeshki  writes:
>
>  > +(defcustom org-agenda-clock-report-header nil
>  > +  "Header for org agenda clock report mode"
>  > +  :group 'org-agenda
>  > +  :type 'string)
>
>  Please add :package-version and :safe keywords to the definition.
>
>  Also, type does not match the default value. You probably mean
>
>  (choice
>   (string :tag "Header")
>   (const :tag "No header" nil))
>
>  > +
>  >  (defun org-agenda-time-of-day-to-ampm (time)
>  >"Convert TIME of a string like \"13:45\" to an AM/PM style time string."
>  >(let* ((hour-number (string-to-number (substring time 0 -3)))
>  > @@ -4473,6 +4478,10 @@ items if they have an hour specification like 
> [h]h:mm."
>  > (setq p (plist-put p :tend clocktable-end))
>  > (setq p (plist-put p :scope 'agenda))
>  > (setq tbl (apply #'org-clock-get-clocktable p))
>  > +(when org-agenda-clock-report-header
>  > +  (put-text-property 0 (length org-agenda-clock-report-header) 'face 
> 'org-agenda-structure
>  > + org-agenda-clock-report-header)
>  > +  (insert org-agenda-clock-report-header))
>
>  Maybe:
>
>(insert (propertize org-agenda-clock-report-header 'face 
> 'org-agenda-structure))
>
>  Could you send an updated patch?
>
>  Regards,
>  -- 
>  Nicolas Goaziou
>
> [4. text/x-patch; 
> 0001-lisp-org-agenda.el-Add-header-to-agenda-clock-report.patch]...


-- 
[ 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