Re: [PATCH]: ox-latex: omit empty date
On 01/08/2022 17:55, emacs--- via General discussions about Org-mode. wrote:
*later in this mail)*
;; Date.
(let ((date (and (plist-get info :with-date) (org-export-get-date
info
(if (string-match-p "^\{.*\}$" (org-export-data date info))
(format "\\date%s\n" (org-export-data date info))
(format "\\date{%s}\n" (org-export-data date info
I am against such code.
_Why mostly:_
At the moment the code escapes the provided brackets and the current
behaviour is
#+date: {my}{fancy}{date} -> \date\{my\}\{fancy\}\{date\}
#+date: @@latex:{my}{fancy}{date}@@
Anyway such date is not suitable for other backends.
I think, custom command name and "#+latex_header:" with such command is
proper solution.
It is possible to choose some combination of existing options like
#+options: date:t
#+date:
as instruction to not add the \date command, but I think it would be
confusing for users and anyway a breaking change for some of them.
I suppose, reverting the patch was the proper step.
Re: commit e22b4eb7 kills formatting & color
> Colin Baxter writes: > Ihor Radchenko writes: >> Colin Baxter writes: >>> > Do you have any idea which particular file-local variable is > >>> leading to the breakage? >>> >>> Well I'm tempted to say all of them because I have local >>> variables in files and .dir-locals.el in many locations. But for >>> a start: >>> >>> # Local Variables: # eval: (setq org-confirm-babel-evaluate nil) >>> # eval: (setq org-adapt-indentation t) # eval: (set >>> (make-local-variable 'org-hide-emphasis-markers) t) # End: >> I am unable to see any issues with fontification starting from >> emacs -Q and loading a file containing these variables. > I think the solution for me is to delete the .elc files in > org-mode. I am about to do this and will report back. No, I spoke too soon. That is not the answer. For me using "emacs -q", an opened org file will expand the folds using but there is still no synatx coloring. This is probably not relevant but my system is 32bit not 64. Best wishes,
Re: commit e22b4eb7 kills formatting & color
> Ihor Radchenko writes: > Colin Baxter writes: >> > Do you have any idea which particular file-local variable is > >> leading to the breakage? >> >> Well I'm tempted to say all of them because I have local >> variables in files and .dir-locals.el in many locations. But for >> a start: >> >> # Local Variables: # eval: (setq org-confirm-babel-evaluate nil) >> # eval: (setq org-adapt-indentation t) # eval: (set >> (make-local-variable 'org-hide-emphasis-markers) t) # End: > I am unable to see any issues with fontification starting from > emacs -Q and loading a file containing these variables. I think the solution for me is to delete the .elc files in org-mode. I am about to do this and will report back. >> I am obviously missing something because I thought a local >> variable was by definition local to a file or directory and was >> not used until that file was opened. So why put them in effect >> before they are needed? > They are put into effect after the file is opened, but Org mode is > not yet loaded. The previous default was applying file-locals > _after_ Org mode is loaded and hence there was no way to set, for > example, org-src-fontify-natively or org-enforce-todo-dependencies > via file-local variables. Thank you. Now I understand better.
Re: commit e22b4eb7 kills formatting & color
Colin Baxter writes: > > Do you have any idea which particular file-local variable is > > leading to the breakage? > > Well I'm tempted to say all of them because I have local variables in > files and .dir-locals.el in many locations. But for a start: > > # Local Variables: > # eval: (setq org-confirm-babel-evaluate nil) > # eval: (setq org-adapt-indentation t) > # eval: (set (make-local-variable 'org-hide-emphasis-markers) t) > # End: I am unable to see any issues with fontification starting from emacs -Q and loading a file containing these variables. > I am obviously missing something because I thought a local variable was > by definition local to a file or directory and was not used until that > file was opened. So why put them in effect before they are needed? They are put into effect after the file is opened, but Org mode is not yet loaded. The previous default was applying file-locals _after_ Org mode is loaded and hence there was no way to set, for example, org-src-fontify-natively or org-enforce-todo-dependencies via file-local variables. Best, Ihor
Re: commit e22b4eb7 kills formatting & color
> Ihor Radchenko writes: > Colin Baxter writes: >> With the latest org-mode, my org files have lost all syntax >> coloring and org-mode formatting. They are essentially dead. If I >> revert commit e22b4eb7 then they come back to life with coloring >> and formatting as usual. My files have local variables which have >> worked perfecting ok before the e22b4eb7 commit. Have other users >> experienced similar issues? > The commits puts file-local and directory-local variables in > effect _before_ loading Org mode. It means that e.g. setting up > initial visibility can be done using directory-local variables. > Do you have any idea which particular file-local variable is > leading to the breakage? > Best, Ihor Dear Ihor, Well I'm tempted to say all of them because I have local variables in files and .dir-locals.el in many locations. But for a start: # Local Variables: # eval: (setq org-confirm-babel-evaluate nil) # eval: (setq org-adapt-indentation t) # eval: (set (make-local-variable 'org-hide-emphasis-markers) t) # End: I am obviously missing something because I thought a local variable was by definition local to a file or directory and was not used until that file was opened. So why put them in effect before they are needed? Best wishes.
Re: commit e22b4eb7 kills formatting & color
Colin Baxter writes: > With the latest org-mode, my org files have lost all syntax coloring and > org-mode formatting. They are essentially dead. If I revert commit > e22b4eb7 then they come back to life with coloring and formatting as > usual. My files have local variables which have worked perfecting ok > before the e22b4eb7 commit. Have other users experienced similar issues? The commits puts file-local and directory-local variables in effect _before_ loading Org mode. It means that e.g. setting up initial visibility can be done using directory-local variables. Do you have any idea which particular file-local variable is leading to the breakage? Best, Ihor
Re: change headings to list but have a nested numeration?
>>> "IR" == Ihor Radchenko writes: > Uwe Brauer writes: >> I see, several observations. >> >> 1. For headings there is a third party package called >> ‘org-outline-numbering.el’. Which provides a mode that display >> headings in such a numbering scheme, however using overlays, as >> far as I can see. > FYI, we have a built-in org-num-mode. Thanks for pointing this out to me, but it does not work for lists only for headings (as its doc string explains), but lists are based on indenting so that seems a lot harder than headings Regards Uwe -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH]: ox-latex: omit empty date
> emacs--- via "General discussions about Org-mode."
> writes:
>
>> My use case is very niche and be solved by changing my custom latex date
>> command by renaming it as for example \mydate.
>>
>> Adding extra options like with_date:nil seems overkill for this small issue.
>>
>
> I agree; I think we shouldn't change basic behavior for more advanced
> usages unless it's something many people are interested in and we keep a
> backward compatibility.
>
>> A second option would be is to analyze the data format in the org file.
>> If for example the date is specified as
>> #+date: {day}{something}
>>
>
> The thing is \date is a macro with one parameter, a string. That's way
> \date{} doesn't do anything and \date{\today} prints today's date where
> \today return today's date as a string. Starting to introduce new kinds
> of inputs - e.g. {y}{m}{d} - to the \date macro would just confuse
> people, I think.
>
It is an optional use pattern and the old options wil still work.
The following code would "mostly" does the trick (I come back at the mostly term
later in this mail) ;; Date.
(let ((date (and (plist-get info :with-date) (org-export-get-date info
(if (string-match-p "^\{.*\}$" (org-export-data date info))
(format "\\date%s\n" (org-export-data date info))
(format "\\date{%s}\n" (org-export-data date info
Dates can now de set as, and exported to:
#+date: some date -> \date{some date}
#+date: my {date} -> \date{my \{date\}}
#+date: {my}{fancy}{date} -> \date{my}{fancy}{date}
#+date: {} -> \date{}
Why mostly:
At the moment the code escapes the provided brackets and the current behaviour
is
#+date: {my}{fancy}{date} -> \date\{my\}\{fancy\}\{date\}
#+date: {} -> \date\{\}
which is not correct and I cant seem to find a good way to alter the format
command to
not escape the special characters. Tips are appreciated.
A general Remark: I feel that passing latex options by their literal value i.e.
including all
latex formatting and brackets, would be a good general addition to the
exporter. I can
imagine use cases where the author command is also overwritten to format names
differently
at different locations in the document. As in
#+author: {title}{name}{sir name}
#+author: {name}{thanks}{special thanks}
It gives the end user way more control over the final document and does not
break any
backward compatibility.
Kind regards
Bob
Re: [PATCH]: ox-latex: omit empty date
emacs--- via "General discussions about Org-mode."
writes:
> My use case is very niche and be solved by changing my custom latex date
> command by renaming it as for example \mydate.
>
> Adding extra options like with_date:nil seems overkill for this small issue.
I agree; I think we shouldn't change basic behavior for more advanced
usages unless it's something many people are interested in and we keep a
backward compatibility.
> A second option would be is to analyze the data format in the org file.
> If for example the date is specified as
> #+date: {day}{something}
The thing is \date is a macro with one parameter, a string. That's way
\date{} doesn't do anything and \date{\today} prints today's date where
\today return today's date as a string. Starting to introduce new kinds
of inputs - e.g. {y}{m}{d} - to the \date macro would just confuse
people, I think.
Daniel
Re: [PATCH]: ox-latex: omit empty date
On 31/07/2022 09:38, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
All the above makes sense. Do I miss something?
>>>
>>> To be precise, \date is not exported to LaTeX file, but current date
>>> appears in PDF. That is why I consider the change as a breaking one.
>>>
>>> Try to export to PDF the following document.
>>>
>>> >8
>>> #+options: title:t
>>> # #+options: date:nil
>>> # #+date:
>>> #+title: Title
>>> test
>>> 8<
>>>
>>> PDF file is produced with current date. Before the patch it was possible
>>> to suppress date in PDF file by removing comment for either "#+options:
>>> date:nil" or for "#+date:". With current main branch HEAD some other
>>> workaround is required. I think, it is not what is expected from the
>>> description of the #+options: keyword:
>>>
>>
>> Agree. I did not know about this LaTeX default.
>>
>> Bob, do you have any ideas? I am inclined to revert the patch.
>>
>
> We may ask the maintainer of ox-latex Daniel Fleischer if a better way to
> handle \date exists.
>
> Bob, could you, please, provide more detail concerning your use case and the
> purpose of the patch?
>
I was only looking at removing the empty date command string from my tex files.
But I acknowledge the fact that it now generates an unwanted default date in
the
latex pdf file when "date:nil" is provided.
In my use case, my template overwrites the date command and a date should be
passed as
\date{day}{month}{year}.
My template uses different formats for the date in different locations of the
text.
E.g. copyright notice, front cover, preface,...
My use case is very niche and be solved by changing my custom latex date
command by renaming it as for example \mydate.
Adding extra options like with_date:nil seems overkill for this small issue.
A second option would be is to analyze the data format in the org file.
If for example the date is specified as
#+date: {day}{something}
and the regex \{.*\} matches, then the date can be used as
and we use
(format "\\date%s\n" (org-export-data date info
instead of
(format "\\date{%s}\n" (org-export-data date info
This is non breaking and would not require any extra options to be passed on to
the exporter.
In this case, the date can also be suppressed by using
#+date: {}
Kind regards,
Bob
commit e22b4eb7 kills formatting & color
With the latest org-mode, my org files have lost all syntax coloring and org-mode formatting. They are essentially dead. If I revert commit e22b4eb7 then they come back to life with coloring and formatting as usual. My files have local variables which have worked perfecting ok before the e22b4eb7 commit. Have other users experienced similar issues? Best wishes, Colin Baxter.
