Re: [PATCH worg] Using asteriks as list item bullets.
Ihor Radchenko writes: > I have updated the patch after rewording and changing the commit message > to comply with > https://orgmode.org/worg/org-contribute.html#commit-messages > > See the attached. Applied onto master via 9b93143f. Best, Ihor
Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]
alain.coch...@unistra.fr writes: > Is someone using natbib/bibtex (say) expected to never ever use > 'basic'? (I don't know.) If so, perhaps there is indeed no need to > implement the feature. Otherwise, it seems to me that not > implementing it amounts to having to give up on @string altogether. AFAIU, oc-natbib/oc-bibtex also do not support @string because they also rely upon the built-in Emacs parser for bib files. I have submitted a bug report to Emacs devs [1]. Hopefully it can be fixed on Emacs side without a need to switch the bibtex parser. [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56475 Best, Ihor
Re: [BUG] org-agenda-prepare-buffers does not save restrictions
On 09/07/2022, Ihor Radchenko wrote: > Two more comments. Attached is the updated patch. PS: I noticed that the `org-timer.el` example in https://orgmode.org/worg/org-contribute.html has a single space between sentences. Other examples on the page seem fine though. Best regards, -- Al >From fcaff9b583c46c0d147aaf4c7e3647f689d54894 Mon Sep 17 00:00:00 2001 From: Al Haji-Ali Date: Sun, 10 Jul 2022 09:46:26 +0100 Subject: [PATCH] lisp/org.el: Save restrictions in all agenda file buffers. * lisp/org.el (org-agenda-prepare-buffers): Call `org-with-wide-buffer' for every buffer in the agenda, instead of calling `save-excursion'/'`save-restrictions' just for the current buffer, to save restrictions in all buffers. Use `with-current-buffer' instead of `save-excursion'/'`set-buffer'. TINYCHANGE --- lisp/org.el | 78 + 1 file changed, 37 insertions(+), 41 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 661efeb9c..3d4de5b4f 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15031,49 +15031,45 @@ When a buffer is unmodified, it is just killed. When modified, it is saved "Create buffers for all agenda files, protect archived trees and comments." (interactive) (let ((inhibit-read-only t) - (org-inhibit-startup org-agenda-inhibit-startup) - pos) + (org-inhibit-startup org-agenda-inhibit-startup)) (setq org-tag-alist-for-agenda nil org-tag-groups-alist-for-agenda nil) -(save-excursion - (save-restriction - (dolist (file files) - (catch 'nextfile - (if (bufferp file) - (set-buffer file) - (org-check-agenda-file file) - (set-buffer (org-get-agenda-file-buffer file))) - (widen) - (org-set-regexps-and-options 'tags-only) - (setq pos (point)) - (or (memq 'category org-agenda-ignore-properties) - (org-refresh-category-properties)) - (or (memq 'stats org-agenda-ignore-properties) - (org-refresh-stats-properties)) - (or (memq 'effort org-agenda-ignore-properties) -(unless org-element-use-cache - (org-refresh-effort-properties))) - (or (memq 'appt org-agenda-ignore-properties) - (org-refresh-properties "APPT_WARNTIME" 'org-appt-warntime)) - (setq org-todo-keywords-for-agenda - (append org-todo-keywords-for-agenda org-todo-keywords-1)) - (setq org-done-keywords-for-agenda - (append org-done-keywords-for-agenda org-done-keywords)) - (setq org-todo-keyword-alist-for-agenda - (append org-todo-keyword-alist-for-agenda org-todo-key-alist)) - (setq org-tag-alist-for-agenda - (org--tag-add-to-alist - org-tag-alist-for-agenda - org-current-tag-alist)) - ;; Merge current file's tag groups into global - ;; `org-tag-groups-alist-for-agenda'. - (when org-group-tags - (dolist (alist org-tag-groups-alist) - (let ((old (assoc (car alist) org-tag-groups-alist-for-agenda))) - (if old - (setcdr old (org-uniquify (append (cdr old) (cdr alist - (push alist org-tag-groups-alist-for-agenda) - (goto-char pos) +(dolist (file files) + (catch 'nextfile +(with-current-buffer +(if (bufferp file) +file + (org-check-agenda-file file) + (org-get-agenda-file-buffer file)) + (org-with-wide-buffer + (org-set-regexps-and-options 'tags-only) + (or (memq 'category org-agenda-ignore-properties) + (org-refresh-category-properties)) + (or (memq 'stats org-agenda-ignore-properties) + (org-refresh-stats-properties)) + (or (memq 'effort org-agenda-ignore-properties) + (unless org-element-use-cache + (org-refresh-effort-properties))) + (or (memq 'appt org-agenda-ignore-properties) + (org-refresh-properties "APPT_WARNTIME" 'org-appt-warntime)) + (setq org-todo-keywords-for-agenda + (append org-todo-keywords-for-agenda org-todo-keywords-1)) + (setq org-done-keywords-for-agenda + (append org-done-keywords-for-agenda org-done-keywords)) + (setq org-todo-keyword-alist-for-agenda + (append org-todo-keyword-alist-for-agenda org-todo-key-alist)) + (setq org-tag-alist-for-agenda + (org--tag-add-to-alist + org-tag-alist-for-agenda + org-current-tag-alist)) + ;; Merge current file's tag groups into global + ;; `org-tag-groups-alist-for-agenda'. + (when org-group-tags + (dolist (alist org-tag-groups-alist) + (let ((old (assoc (car alist) org-tag-groups-alist-for-agenda))) + (if old + (setcdr old (org-uniquify (append (cdr old) (cdr alist + (push alist org-tag-groups-alist-for-agenda) (setq org-todo-keywords-for-agenda (org-uniquify org-todo-keywords-for-agenda)) (setq org-todo-keyword-alist-for-agenda -- 2.25.1
Can citeproc be installed without using MELPA? (was: @string abbreviation in bib file not honored in (basic) org-cite)
András Simonyi writes: >> The problem with parsebib is that it does not even have license >> (I do not see any in https://github.com/joostkremers/parsebib). If >> parsebib were a part of Emacs core or at least a part of ELPA, we would >> also be able to use it in Org core. > > looking into the source code (parsebib.el), the library seems to be > under a BSD-type license. Then, I am wondering if parsebib can be added to ELPA or at least non-GNU ELPA. The same can be said for all other dependencies of citeproc.el and for citeproc itself. Ideally, users should not need to add non-default package repos just to add support for CSL in Org. Best, Ihor
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Juan Manuel Macías writes: > I'm attaching a patch with a proposal to unify in a single constant > (named `org-latex-language-alist') > `org-latex-polyglossia-language-alist' and > `org-latex-babel-language-alist', along with some necessary (minor) > modifications in `org-latex-guess-polyglossia-language' and > `org-latex-guess-babel-language' > > The new list, which is not exhaustive, is built taking as a reference > the documentation of Babel and Polyglossia in their latest versions > within TeX live 2021. It also assumes the latest improvements in the > babel package (on the current state of the art regarding the babel and > polyglossia packages, see this previous thread: > https://list.orgmode.org/87wnmv4s87@posteo.net/). I have also > corrected some minor inconsistencies in the previous two lists. Thanks! This looks like an improvement. However, we may need to preserve the old defconsts for the time being and declare them obsolete. Otherwise, the patch looks fine from a cursory look. Best, Ihor
Re: Alternatives to clocking in/out for reporting time
Russell Adams writes: >> Can you then formulate what exactly you want to achieve? >> Do you want to consider only agenda items? All the timestamps in the >> matching items or maybe just some? > > I typically use agenda for the month with logbook view and inactive > timestamps enabled. > > I'd love to iterate over the list of all timestamps from that view. You can. What you need to know about agenda buffers is that various useful information is stored in text properties. Every agenda line, which corresponds to a headline contains a non-nil 'org-hd-marker text property. In log mode, there will also be non-nil 'date and 'time-of-day text properties. You can examine the full list yourself by running M-x describe-text-properties with point at an agenda entry. Hope it helps. Best, Ihor
Re: change headings to list but have a nested numeration?
Uwe Brauer writes: > I start with this part > > * The pseudo code > ** The actual Matlab code > ** Initialisation > *** Details > > Which is converted via org-ctrl-c-minus > to > * The pseudo code > - The actual Matlab code > - Initialisation > - Details > > However here the structure depends on the indentation and that might not > be that rebust would it be possible to convert to such a structure: > > * The pseudo code > 1. The actual Matlab code > 2. Initialisation > 1.1 Details AFAIK, using "-" is hard-coded in org-toggle-item. Also, 1.1 is not a valid list bullet. So, you need to implement alternative bullet support yourself. Patches are welcome! Best, Ihor
Re: [BUG] org-agenda-prepare-buffers does not save restrictions
Al Haji-Ali writes: > On 09/07/2022, Ihor Radchenko wrote: >> Two more comments. > Attached is the updated patch. Thanks! Applied onto main via bc33c0133. > PS: I noticed that the `org-timer.el` example in > https://orgmode.org/worg/org-contribute.html > has a single space between sentences. Other examples on the page seem fine > though. Fixed. Best, Ihor
Re: [PATCH v4] ol.el: add description format parameter to org-link-parameters
On 08/07/2022 02:57, Hugo Heagren wrote: Since the last version of this patch, I have: Thank you, this version should be more reliable. tl;dr The question is: what is the Good Behaviour when :default-description is set to something, which is meant to return a string and returns 'nil instead? Should it be treated like an empty string, or as an error? Just an idea: if the :default-description function returns "" then use empty description, if it returns nil then try `org-link-make-description-function'. Unsure if it is better but I would consider `or' instead of `cond': (or description (let ((make (org-link-get-parameter type :default-description))) (and make (condition-case ; ... ))) (and org-link-make-description-function (condition-case ; ... )) desc) So it becomes a kind of responsibility chain and nil becomes a valid and useful value. I am in doubts concerning "default-description" as the parameter name. I would consider either more specific "insert-description" or shorter "description". Concerning the former, sometimes I do not mind to have default description for export shared by most of backends without necessity to explicitly write :export function handling all backends. E.g. for generate https://orgmode.org/manual/Protocols.html target and 'info "(org) Protocols"' description that is suitable for LaTeX/PDF, HTML, Markdown. If something like this were implemented, default-description would become ambiguous if it is related to insert or to export. +(defmacro test-ol-with-link-parameters-as (type parameters &rest body) [...] + ;; Copy all keys in `parameters' and their original values to + ;; `orig-parameters'. For `parity': nil = odd, non-nill = even + `(let (parity orig-parameters) + (dolist (p ',parameters) Have I missed something or the whole macro may be simplified to just copy `org-link-parameters'? `(let ((org-link-parameters (copy-tree org-link-parameters))) (org-link-set-parameters ,type ,@parameters) ,@body)) Otherwise `gensym'-generated name should be used instead of hardcoded rtn to avoid accidental modification of the variable by the body code: + (let ((_ (org-link-set-parameters ,type ,@parameters)) + ;; Do body + (rtn (progn ,@body))) In addition, `declare' form should be added to `defmacro' to specify which argument is considered as its body. +(setq type + (cond My opinion is that it should be inside (let ((initial-input ... and maybe even be a sibling of (def (org-link-get-parameter type to keep related code more local. - ((not org-link-make-description-function) desc) + (desc) + ((org-link-get-parameter type :default-description) + (let ((def (org-link-get-parameter type :default-description))) I have not tested, so I may be wrong in respect to the following. It seems, you rises priority of desc value that earlier was a fallback. The reason why I am in doubts, is that it seems, desc is initialized from current link description when point is withing an existing link and in such cases desc likely should be preserved. I can not say that I like that it is responsibility of all description functions to return the desc argument if it is supplied. (t (condition-case nil (funcall org-link-make-description-function link desc) Notice that before you modification `funcall' was guarded by "(not org-link-make-description-function)" test. I like the idea of description specific to link type and it is sour that previous attempts to implement the feature was not completed.
Patch: Add a missing option to org-src-window-setup
Hi, I was trying to customize org-src-window-setup and noticed that "plain" was not an option, despite being documented. I checked the commit and it seems the implementation was added but the choice list in the defcustom was not updated. Best, Matt Rudary 0001-org-src.el-Add-plain-to-org-src-window-setup-customi.patch Description: Binary data
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
On 03/10/2021 22:28, Juan Manuel Macías wrote:
Hi all,
I'm attaching a patch with a proposal to unify in a single constant
(named `org-latex-language-alist')
`org-latex-polyglossia-language-alist' and
`org-latex-babel-language-alist', along with some necessary (minor)
modifications in `org-latex-guess-polyglossia-language' and
`org-latex-guess-babel-language'
I would consider structures with named fields (alists or plists) for a
case of adding some additional settings (Font name? But it is rather
defcustom than defconst)
("es" . (:babel "spanishmx" :poliglossia "spanish" :poliglossia-variant
"mexican")
M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
Tim Cross writes: > Juan Manuel Macías writes: > > Thanks Juan. It will be fairly trivial to compile the information you > have provided into a basic org document which I can then add to org. If > on the other hand you would prefer to write it up, all I need is an org > document which is based on the (current) org 'worg' template, which is > very simple i.e. > > #+:begin_src org > > #+TITLE: [No title for now, please update] > #+AUTHOR: Worg people > #+OPTIONS:H:3 num:nil toc:t \n:nil ::t |:t ^:t -:t f:t *:t tex:t d:(HIDE) > tags:not-in-toc > ... Maybe Org can provide this template simply from M-x? Would you find such addition useful? Best, Ihor
Re: Alternatives to clocking in/out for reporting time
I also use org-mode clocking to record time spent.
But instead of modifying/configuring org-mode, I use a post-processing
Python script to collect and summarize clocked times.
locale.setlocale(locale.LC_ALL, '')
# ...
def extract_times(line):
# CLOCK: [-mm-dd WKD HH:MM]--[-mm-dd WKD HH:MM] => HH:MM
m = re.search('CLOCK:\s*\[(.+? .+? .+?)\]--\[(.+? .+?
.+?)\]\s*=>\s*(.+)', line)
if m:
ts = m.group(1)
start = datetime.datetime.strptime(ts, '%Y-%m-%d %a %H:%M')
ts = m.group(2)
stop = datetime.datetime.strptime(ts, '%Y-%m-%d %a %H:%M')
tm = m.group(3)
spent = datetime.datetime.strptime(tm, '%H:%M')
spent = datetime.timedelta(hours = spent.hour, minutes =
spent.minute)
logging.debug('time={}, spent={}'.format(line.strip(), spent))
return (start, stop, spent)
Together with properties or tags or some other means, you can summarize
and round collected times as needed.
This can be done in any other (scripting) language, of course.
setlocale is needed here, because I have German weekday names.
Kind regards, Olaf
Russell Adams writes:
> I make extensive use of timestamps for billing (timesheet)
> purposes. I'm looking to automate this more, and I find the existing
> clocking system inadequate. I'm hoping someone can point me in the
> right direction.
>
> Today I have log mode enabled so that each time I close a TODO item,
> it records the date and time it was closed. At regular intervals while
> working I add inactive timestamps to my notes. I've mapped that to a
> single key, so it's quite fast. If I switch tasks, have an update,
> made progress I want to note to myself, or leave and return I add an
> inactive timestamp. I have well over 1000 inactive timestamps in my
> current file.
>
> Later I can open my agenda view on the working file, choose my
> timespan (week or month), enable log mode to show when items were
> closed, and then enable inactive timestamps to view all of the
> timestamps. This itemizes all the events organized by time into a
> timeline.
>
> It's fairly straightforward from that timeline to count my hours based
> on the record of where I spent my time. It is unfortunately a very
> manual process.
>
> I find Org's clocking to be too detailed, and that it doesn't play
> well with dynamically organized hierarchies of notes. I frequently
> create and close subtasks, or switch parts of the tree. Clocking each
> one is too much overhead, and too granular. I don't need to provide
> down to the minute reports of each item. It also doesn't appear to
> allow rounding of values, so I still have to adjust the results.
>
> What I envision is a way to count items in the agenda view to produce
> a time report. Counting any inactive timestamp as 15 minutes, where if
> a half hour or more is logged I round up to bill the hour. Closed TODO
> items should count toward billing that whole hour. Clearly this should
> be customized.
>
> The point is that I'm not worried about accounting time by task,
> instead I'm aggregating tasks into accounting by whole hours.
>
> I'm looking at org-element, and it appears I'd have to do my own
> agenda style scan of the whole tree to find items to classify by
> hour. While I'm somewhat proficient at elisp, that sounds like a steep
> wall to climb.
>
> Is there an iterative way to review items in an agenda view so I can
> do the math to produce a report?
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
> https://www.adamsinfoserv.com/
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
On Mon, 4 Jul 2022 at 17:32, Ihor Radchenko wrote: > > While looking at the *Messages* buffer, I came across the command > > y-or-n-p-insert-y. There are commands for n, and other keys. When we > > press y, M-p etc, these commands get executed. So, even if we manage to > > fix the initial example in Emacs, the hook will still run while one is > > in the minibuffer. > > This explains the observed behavior. Apart from these commands triggering the post-command-hook, there is one additional time it gets executed. This is the place when y-or-n-p calls read-from-minibuffer. When read-from-minibuffer executes, this-command remains my-test-command. > A possible fix could be let-binding post-command-hook to > (delq #'org-add-log-note post-command-hook), though we may get a similar > issue in other context in future. > > A better fix may relate to the fact that org-add-log-setup is usually > used to run org-add-log-note at the end of current command. y-or-n-p or > any other kind of command (e.g. added via advice) will break this > assumption we use. So, org-add-log-setup could also store > `this-command', say, in `org-log-note-this-command' and > `org-add-log-note' can then execute only when `this-command' is the same > with `org-log-note-this-command'. WDYT? I had something similar in my mind, something like we check if this-command is org-* (not very robust). Your idea makes sense to me. But this won't work when read-from-minibuffer is called as it doesn't seem to change this-command when it runs. I had created an Emacs bug report: https://debbugs.gnu.org/56425 -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
PATCH: [PATCH] Allow bulk agenda actions to take log notes
Currently org-agenda-bulk-action is completely broken if anything tries to take a log note during the action, this patch fixes it by storing log note setup variables in a list, and then taking one log note, and duplicating it over all affected items. Please CC me when responding as I'm not subscribed. Regards, Max 0001-Allow-bulk-agenda-actions-to-take-log-notes-a-note-f.patch Description: Binary data
Re: M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
Ihor Radchenko writes: > Tim Cross writes: > >> Juan Manuel Macías writes: >> >> Thanks Juan. It will be fairly trivial to compile the information you >> have provided into a basic org document which I can then add to org. If >> on the other hand you would prefer to write it up, all I need is an org >> document which is based on the (current) org 'worg' template, which is >> very simple i.e. >> >> #+:begin_src org >> >> #+TITLE: [No title for now, please update] >> #+AUTHOR: Worg people >> #+OPTIONS:H:3 num:nil toc:t \n:nil ::t |:t ^:t -:t f:t *:t tex:t >> d:(HIDE) tags:not-in-toc >> ... > > Maybe Org can provide this template simply from M-x? > Would you find such addition useful? > That could be a good and easy addition. If we can streamline the worg submission process, we can probably improve the worg content quite a bit. Only drawback I can see is that should we want to change the template, we would have to wait until a new version is released and then you will still have a mix of templates as lots of people will wait until next Emacs version etc. The question I guess comes down to how often we would need to change the template - probably very infrequently. I do plan to change the current template, but if anything, that will be simplifying it. I will add this idea to the TODO list!
Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?
Tim Cross writes: > Thanks Juan. It will be fairly trivial to compile the information you > have provided into a basic org document which I can then add to org. If > on the other hand you would prefer to write it up, all I need is an org > document which is based on the (current) org 'worg' template, which is > very simple i.e. > > #+:begin_src org > > #+TITLE: [No title for now, please update] > #+AUTHOR: Worg people > > #+OPTIONS:H:3 num:nil toc:t \n:nil ::t |:t ^:t -:t f:t *:t tex:t d:(HIDE) > tags:not-in-toc > #+STARTUP:align fold nodlcheck hidestars oddeven lognotestate > > #+SEQ_TODO: TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@) > > #+TAGS: Write(w) Update(u) Fix(f) Check(c) > #+LANGUAGE: en > > #+PRIORITIES: A C B > #+CATEGORY: worg > > #+HTML_LINK_UP:index.html > #+HTML_LINK_HOME: https://orgmode.org/worg/ > > # This file is released by its authors and contributors under the GNU > # Free Documentation license v1.3 or later, code examples are released > # under the GNU General Public License v3 or later. > > # This file is the default header for new Org files in Worg. Feel free > # to tailor it to your needs. > > #+end_src Thanks so much for all the pointers, Tim. I can collect and clean up (and possibly expand) all the information I've put in this thread and make an Org document with this template. I agree with Ihor that the template would be a great addition to Org-Mode. Best regards, Juan Manuel
Re: Can citeproc be installed without using MELPA? (was: @string abbreviation in bib file not honored in (basic) org-cite)
On Sun, Jul 10 2022, Ihor Radchenko wrote: > András Simonyi writes: > >>> The problem with parsebib is that it does not even have license >>> (I do not see any in https://github.com/joostkremers/parsebib). If >>> parsebib were a part of Emacs core or at least a part of ELPA, we would >>> also be able to use it in Org core. >> >> looking into the source code (parsebib.el), the library seems to be >> under a BSD-type license. Yes, it is. It's a single file and the license is at the top. I can add a separate license file if that's necessary. > Then, I am wondering if parsebib can be added to ELPA or at least > non-GNU ELPA. The same can be said for all other dependencies of > citeproc.el and for citeproc itself. I'd have no problem if it were added to non-GNU ELPA. GNU ELPA is a little difficult because I don't have a copyright assignment on file. (It's proven a little difficult to get someone in the company to sign the corporate waiver...) -- Joost Kremers Life has its moments
[possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
Considering some discussions in the parent thread, I think maybe it
wouldn't hurt to ensure a minimal preamble when the output is compiled
with LuaLaTeX or XelaTeX, so that some very basic fontspec configuration
is loaded to be able to read PDFs in non-Latin scripts.
But before proposing the patch directly, I'd like to discuss its
structure. I think (IMHO) that a certain balance should be ensured
between a) users who don't want to mess with fontspec and want something
more out-of-the-box and b) users who prefer to be in control when
compiling with LuaTeX and XeTeX.
I think maybe it would be nice to let LaTeX do the work, via a
conditional from the iftex package (idea taken from pandoc).
The structure of the patch could be this:
1. There could be a defcustom, something like 'org-latex-use-fontspec'
(I would vote for nil by default).
2. There would be three variables for the default fonts: roman, sans and
mono. By default, the FreeSerif, FreeSans and FreeMono fonts could be
set as default value, since they are very ubiquitous and have a very
good coverage for non-Latin scripts.
3. A variable (something like 'org-latex-fontspec-default-configuration') would
return something like this:
(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)
(and this string would be added at some point to org-latex-make-preamble)
4. Conclusion: I think the good thing about letting LaTeX do the
conditional work with iftex is that it saves us less invasive code on
our end. I also think that other more complex approaches, such as
searching for the fonts present in the system and adding them according
to the document scripts, would lead us to a completely slippery slope.
Of course, a list of recommended free-licensed fonts could be included
in the documentation.
WDYT?
Best regards,
Juan Manuel
Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
Sorry, I forgot to add quotes :-) "\\usepackage{iftex}...\\fi"
Juan Manuel Macías writes:
> (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)
Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
Juan Manuel Macías writes:
> Considering some discussions in the parent thread, I think maybe it
> wouldn't hurt to ensure a minimal preamble when the output is compiled
> with LuaLaTeX or XelaTeX, so that some very basic fontspec configuration
> is loaded to be able to read PDFs in non-Latin scripts.
>
> But before proposing the patch directly, I'd like to discuss its
> structure. I think (IMHO) that a certain balance should be ensured
> between a) users who don't want to mess with fontspec and want something
> more out-of-the-box and b) users who prefer to be in control when
> compiling with LuaTeX and XeTeX.
>
> I think maybe it would be nice to let LaTeX do the work, via a
> conditional from the iftex package (idea taken from pandoc).
>
> The structure of the patch could be this:
>
> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).
>
> 2. There would be three variables for the default fonts: roman, sans and
> mono. By default, the FreeSerif, FreeSans and FreeMono fonts could be
> set as default value, since they are very ubiquitous and have a very
> good coverage for non-Latin scripts.
>
> 3. A variable (something like 'org-latex-fontspec-default-configuration')
> would return something like this:
>
> (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)
>
> (and this string would be added at some point to org-latex-make-preamble)
>
> 4. Conclusion: I think the good thing about letting LaTeX do the
> conditional work with iftex is that it saves us less invasive code on
> our end. I also think that other more complex approaches, such as
> searching for the fonts present in the system and adding them according
> to the document scripts, would lead us to a completely slippery slope.
> Of course, a list of recommended free-licensed fonts could be included
> in the documentation.
>
> WDYT?
>
I'll prefix this by being very clear that I'm so out of my depth, I know
nothing! I'm an Australian who lives on the worlds largest
island. Despite being a country where 1/4 people have at least one
parent born in a non-english speaking country, Australia is at this time
monolingual. As a consequence, I've never had to deal with fonts other
than trying to select one which 'looks nice'. This tends to be something
I leave to Latex as my aesthetic skills are only slightly better than my
language skills!
Like many, I have had to struggle with fonts at one time or another -
typically, it was with respect to type formatting of mathematics/logic
and it was what got me using Latex originally (30+ years ago). I rarely
need to do this now.
So, my perspective on this is fairly basic.
- I think the move to luatex is important for org, especially given
the rise of packages which use/need it
- It seems like luatex could make org easier to use for those who do
need support for other non-latin languages and especially for those
who need to work in multiple languages.
- For many simpler people like me, I just want it to work. When I
export to a PDF document, I want to continue to have people say
"Wow, that is a good looking document, what is your secret" and I
can reply, "Don't use MS Office!". I don't want to mess with
selecting fonts, defining font specs etc. I want good defaults.
- For many people, it seems fonts are a very personal and important
component and they want the power to manage them at a lower
level. Therefore, support for this user is as important as my use
case. They need to be able to adapt their document to their
preferred fonts without having to code elisp or low level latex/tex.
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.
but as I said, I know nothing
Re: Alternatives to clocking in/out for reporting time
On 7/10/22, Ihor Radchenko wrote: > Every agenda line, which corresponds to a headline contains a non-nil > 'org-hd-marker text property. In log mode, there will also be non-nil > 'date and 'time-of-day text properties. You can examine the full list idk if this is helpful but at one point long ago i /seemed/ to occasionally need to do the following. (or (get-text-property 0 'org-marker s) (get-text-property 0 'org-hd-marker s ;;do this to get to the org outline buffer from the ;;agenda buffer if you need other data that org-entry-get ;;cannot extract ;; ;;(b (and m (marker-buffer m ;;;(if b ;;;(with-current-buffer b ;;; (goto-char m)
Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note
Bhavin Gandhi writes: >> A better fix may relate to the fact that org-add-log-setup is usually >> used to run org-add-log-note at the end of current command. y-or-n-p or >> any other kind of command (e.g. added via advice) will break this >> assumption we use. So, org-add-log-setup could also store >> `this-command', say, in `org-log-note-this-command' and >> `org-add-log-note' can then execute only when `this-command' is the same >> with `org-log-note-this-command'. WDYT? > > I had something similar in my mind, something like we check if > this-command is org-* (not very robust). Your idea makes sense to > me. But this won't work when read-from-minibuffer is called as it > doesn't seem to change this-command when it runs. Then, we will also need to save (recursion-depth) value and check for it in addition to this-command. Best, Ihor
Re: org-capture and fast selection of tags
Christian Heinrich writes: > Today, I went through your init.org on github (it's ... huge) and couldn't > find anything there > either. That's because I rarely need to set standard tags when capturing staff. So, I am content with entering tags manually. > ... Do you have an idea > on how to use fast selection of tags (using shortcuts) when capturing an > entry? > ... > I first thought that using %(org-set-tags-command) should work; but the > capture-buffer is narrowed > (i.e., no tags are available),... %(org-with-wide-buffer (org-set-tags-command)) may work. Of course, we may also implement a proper capture selection for %^g template. As usual, patches are welcome. Best, Ihor
Re: Can citeproc be installed without using MELPA? (was: @string abbreviation in bib file not honored in (basic) org-cite)
Joost Kremers writes: >>> looking into the source code (parsebib.el), the library seems to be >>> under a BSD-type license. > > Yes, it is. It's a single file and the license is at the top. I can add a > separate license file if that's necessary. It is not required. Just a bit confusing - Github is only able to detect license info when you have a dedicated license file. Hence, Github currently treats your repo as unlicensed - no license info is listed in the "Info" sidebar. >> Then, I am wondering if parsebib can be added to ELPA or at least >> non-GNU ELPA. The same can be said for all other dependencies of >> citeproc.el and for citeproc itself. > > I'd have no problem if it were added to non-GNU ELPA. GNU ELPA is a little > difficult because I don't have a copyright assignment on file. (It's proven a > little difficult to get someone in the company to sign the corporate > waiver...) non-GNU ELPA is also fine. The idea is to avoid asking users to add extra package repo configuration. It will be the best if M-x package-install just works. ELPA and non-GNU ELPA should be available by default in newer Emacs versions. Best, Ihor
Re: M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
Tim Cross writes: > Only drawback I can see is that should we want to change the template, > we would have to wait until a new version is released and then you will > still have a mix of templates as lots of people will wait until next > Emacs version etc. The template can be automatically updated by the command, possibly after asking user. Best, Ihor
Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
Juan Manuel Macías writes:
> Considering some discussions in the parent thread, I think maybe it
> wouldn't hurt to ensure a minimal preamble when the output is compiled
> with LuaLaTeX or XelaTeX, so that some very basic fontspec configuration
> is loaded to be able to read PDFs in non-Latin scripts.
+1
> But before proposing the patch directly, I'd like to discuss its
> structure. I think (IMHO) that a certain balance should be ensured
> between a) users who don't want to mess with fontspec and want something
> more out-of-the-box and b) users who prefer to be in control when
> compiling with LuaTeX and XeTeX.
>
> I think maybe it would be nice to let LaTeX do the work, via a
> conditional from the iftex package (idea taken from pandoc).
>
> The structure of the patch could be this:
>
> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).
Does it mean that unicode text (like це or 这个) will not be exported by default?
> 2. There would be three variables for the default fonts: roman, sans and
> mono. By default, the FreeSerif, FreeSans and FreeMono fonts could be
> set as default value, since they are very ubiquitous and have a very
> good coverage for non-Latin scripts.
+1
But can someone check if Free* fonts are available on Windows and Mac by
default? If not, can we distribute these fonts with Org?
> 3. A variable (something like 'org-latex-fontspec-default-configuration')
> would return something like this:
>
> (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)
>
> (and this string would be added at some point to org-latex-make-preamble)
Makes sense. Though I'd rather use format-spec instead to allow
arbitrary order of variable formatting.
> 4. Conclusion: I think the good thing about letting LaTeX do the
> conditional work with iftex is that it saves us less invasive code on
> our end. I also think that other more complex approaches, such as
> searching for the fonts present in the system and adding them according
> to the document scripts, would lead us to a completely slippery slope.
> Of course, a list of recommended free-licensed fonts could be included
> in the documentation.
>
> WDYT?
This unified preamble approach is consistent with what we do now.
However, our currently used large preambles will slow down compilation.
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.
Best,
Ihor
Re: M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
Ihor Radchenko writes: > Tim Cross writes: > >> Only drawback I can see is that should we want to change the template, >> we would have to wait until a new version is released and then you will >> still have a mix of templates as lots of people will wait until next >> Emacs version etc. > > The template can be automatically updated by the command, possibly after > asking user. > Not sure I understand. Maybe we are imagining different things? If org has a template to assist in creating an org file suitable for worg and then we need to update that template for some reason, where would that new 'update' come from in order to be automatically updated?
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > PCI compliance is not required by law but is considered > mandatory through court precedent. The crucial questions would be: required _of whom_, in what circumstances? > > I wonder if users could run the free version of that JS code > > while talking with Stripe. > You could try replacing it in your browser. Yes, that's what I'm thinking of. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
Tim Cross writes: >> The template can be automatically updated by the command, possibly after >> asking user. >> > > Not sure I understand. Maybe we are imagining different things? > > If org has a template to assist in creating an org file suitable for > worg and then we need to update that template for some reason, where > would that new 'update' come from in order to be automatically updated? By "updated" I meant downloaded from orgmode.org Best, Ihor
Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
Juan Manuel, > 1. There could be a defcustom, something like 'org-latex-use-fontspec' > (I would vote for nil by default). i just wanted to check: the "nil" case is for those of us who just want it to work "out of the box"? and, in the non-nil case, it would be up to the user to use "fontspec", or whatever? cheers, Greg
Re: M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
Ihor Radchenko writes: > Tim Cross writes: > >>> The template can be automatically updated by the command, possibly after >>> asking user. >>> >> >> Not sure I understand. Maybe we are imagining different things? >> >> If org has a template to assist in creating an org file suitable for >> worg and then we need to update that template for some reason, where >> would that new 'update' come from in order to be automatically updated? > > By "updated" I meant downloaded from orgmode.org > OK, that would probably work. We would need to have some sort of version tracking so that the template function can know when there is a new template available - probably doable with either a comment in the template file or perhaps adding a custom http header using nginx's headers module. Advantage of the header is you could do a quick query without having to download and parse the template file to get version info. Will add it to the list
Re: M-x org-create-worg-article command? (was: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?)
Tim Cross writes: >> By "updated" I meant downloaded from orgmode.org >> > > OK, that would probably work. We would need to have some sort of > version tracking so that the template function can know when there is a > new template available - probably doable with either a comment in the > template file or perhaps adding a custom http header using nginx's > headers module. Advantage of the header is you could do a quick query > without having to download and parse the template file to get version > info. I do not think that we need to go this far. The template will anyway be a few kb. The ping time to query template version may take longer than downloading. Instead, we can simply use org-persist to download the template and then set some reasonable value of expiry (or just use the default 30 days). Then, the template will be refreshed monthly, which is not a big deal IMHO. I do not expect that we need to update the template more frequently. Best, Ihor
Re: Links to javascript-based websites from orgmode.org: Paypal and Github
Richard Stallman writes: > > PCI compliance is not required by law but is considered > > mandatory through court precedent. > > The crucial questions would be: required _of whom_, in what circumstances? If I understood it correctly, it’s required of the platform. They do not have the option to ship other code if they want their site to be allowed to process credit card data. But this is guesswork on my side. > > > I wonder if users could run the free version of that JS code > > > while talking with Stripe. > > > You could try replacing it in your browser. > > Yes, that's what I'm thinking of. The decentraleyes extension might be able to automate that: https://decentraleyes.org/test/ https://git.synz.io/Synzvato/decentraleyes Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: [PATCH] Re: link error when file missing
Ihor Radchenko writes: > Alan Wehmann writes: > >> Thanks for your reply. In my personal case I've modified "org-open-file" to >> throw an error for a non-existing file. In my case, clearly Emacs is not >> happy with a non-existing file--at least if it is a PDF file meant to be >> viewed by docview. Option 1 could have "org-docview-open" throw an error >> for a non-existing file, I suppose. You describe option 2 as risking >> existing configs. I am uninformed on such an issue. I only use Org from >> within Emacs. If a future problem occurs because I modified >> "org-open-file", I'll deal with it when it occurs. > > I thought more about this and I do not think that modifying > org-open-file is a good idea. The current behaviour could be useful for > people who would like to auto-create, say, .org/.txt files just by > typing a link and opening it. Even .svg files could be created like > this. > > So, I propose to update ol-docview instead. See the attached patch. Applied onto main via c231e93b5. Best, Ihor
Re: [PATCH] Re: [ISSUE] Re: [PATCH] lisp/org-agenda.el: Add header to agenda clock report table
Ihor Radchenko writes: > "Christopher M. Miles" writes: > >> 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. > > Reasonable concern. > The attached patch should fix it. Applied onto main via 53e6aa866. Best, Ihor
[BUG] right shift list checkbox with [Alt-Right] caused error by option org-list-demote-modify-bullet
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
