Re: org-agenda todos list sorted by earliest deadline first
Sébastien Gendre writes: > I've tested it, but the tasks with no deadlines are still on top of the list. I am unable to reproduce on my side using latest stable Org. I used the following example org file: * TODO test1 * TODO test2 * TODO test3 DEADLINE: <2022-04-04 Mon> * TODO test4 DEADLINE: <2022-04-06 Wed> -- (setq org-agenda-sorting-strategy '((agenda deadline-down time-up habit-up priority-down timestamp-down category-keep) (todo deadline-up priority-down category-keep) (tags priority-down category-keep) (search category-keep))) The todo agenda buffer looks like: Global list of TODO items of type: ALL Press ‘N r’ (e.g. ‘0 r’) to search again: (0)[ALL] (1)TODO (2)DONE bug:TODO test3 bug:TODO test4 bug:TODO test1 bug:TODO test2 Best, Ihor
Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Max Nikulin writes: > Confirmed > > Emacs copy of Org changed the way of calling `encode-time' as a result > interpretation of last nils returned by `org-parse-string' altered from > ignored to "no DST". > > Kyle, be aware of the conflict with `org-time-string-to-time' when you > will port emacs commit dd0727e1ec1f535b9b06be88173b4d3ccd55abcb > Paul Eggert Thu Dec 16 09:40:21 2021 -0800 > encode-time simplifications Thank you, Max, for looping me into the discussion (and thanks, Ignacio, for the initial report and debugging). > New calling convention for `encode-time' exists since emacs-27.1, so it > is incompatible with yet supported emacs-26. [...] >> So I guess this is an Emacs 29 bug? I didn't know the two repositories >> could diverge like that. Should I report it to Emacs 29 maintainers? >> Or can org-mode maintainers fix it in the Emacs repository? > > The problem is a consequence of grep-refactoring of Emacs code, but > likely it should be fixed at the Org side. The long tail of 9e1b9fe62 (Port more time-related changes, 2019-08-18) My suggestion: 1. Send a report to bug-gnu-em...@gnu.org describing the issue. Ask that Paul revert those changes. I can do this at some point this week. 2. Audit and update the call sites on our side, along with some compatibility layer. The first isn't necessary, but it avoids the problem living in the Emacs master branch until the updated Org code base (main branch) is synced with it (which hasn't started yet).
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
c.bu...@posteo.jp writes: > Dear Tim > > Am 04.04.2022 17:49 schrieb Tim Cross: >> What is line-fill-mode? It isn't a 'standard' emacs mode, so must be >> some add-on? > > Sorry this was a "typo". > >> At any rate, I don't see this problem when using standard >> auto-fill-mode. With this mode, when lines wrap (because I've exceeded >> the fill column) or if I use C-q to trigger filling, the wrapped lines >> are indented correctly so that lists are preserved. > > This is not the case with me. > Please see this screenrecording > https://debianforum.de/forum/gallery/image/3641/source > > In the top window you see the relevant lines from my init.el. > In the bottom you see a orgroam capture buffer while I am tiping a > loreipsum line and exceeding the fill column. It is not intended. > > And that is how it looks like in raw org > > :PROPERTIES: > :ID: 7fe439ec-c46d-4da5-902a-3ba40cebb25e > :END: > > #+title: test > #+date: [2022-04-04 Mo 20:04] > > - Lorem ipsum dolro sit amet, consetetur sadipscing elitr, sed diam > nonumy > eirmod tempor invidunt ut > - second item >second line in second item > - > > The first list entry got its newline char automatically via > auto-fill-mode. > The second entry got its newline by myself via pressing RET. I cannot reproduce your issue using a clean Emacs. I suspect this is either something incorrect in your init.el file or something caused by org-roam (which is not part of org-mode). I note from the screenshot you provided that you are explicitly setting auto-fill-function. This is not the standard way to turn on auto-fill-mode and it could break mode specific settings for auto-filling. Instead, you should call auto-fill-mode in the appropriate mode specific hook (as specified in the emacs manual). I would suggest you try reproducing your issue in a clean Emacs e.g. emacs -Q open an org file do M-x auto-fill-mode do M-x org-capture to start a data capture do M-x auto-fill-mode to enable auto-filling in the capture buffer Add list items to the capture buffer, some long, some short and let auto-fill do the filling complete the capture When I do this, the lists are formatted correctly and long lines are wrapped with the correct item indentation. This is with GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of 2022-04-05 Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/29.0.50/lisp/org/)
Re: org-return not being given 't' for INDENT parameter
From: jebb Bungo Sent: Thu, 31 Mar 2022 10:14:43 -0400 To: zixx...@gmail.com Subject: org-return not being given 't' for INDENT parameter Hello, I am having an odd behavior with org-return. I use hard indents, and I have set 'org-adapt-indentation' to t in my .emacs file. However, I have noticed that sometimes when I press RET under a heading, instead of getting an indent to match the indentation of the heading after the *'s, point is set right at 0. For example, the expected behavior of pressing RET at the end of the line '* Heading' would be that point is placed on the next line below the heading, at column 2. I am having an issue pinpointing what is causing the error, however, as I haven't found any consistency. Sometimes RET works as expected in my files, othertimes it does not. The bug does seem to only 'fix' in between instances of Emacs. I run Emacs as a daemon, and I noticed that sometimes the files will work and other times not work, but only between instances of the daemon/between system boots. I have tried restarting org mode through the menu-bar option "restart org-mode (new version)", as well as disabling and renabling org-mode, as well as simply calling org-mode. No avail. When I tried to debug the function, I really didn't have a clue what I was doing, but I think I narrowed the issue down to org-mode not getting the right context on where point is. I think this because org-return functions as expected when called with 't' as an argument, such as (org-return t), but I get the issue when calling just (org-return), which is bound to RET. My work-around, for the time being, has just been to disable electric-indent-mode, and use C-J to get the desired behavior, as that calls (org-return-and-maybe-indent), and gives t if org-adapt-indentation is t and electric-indent-mode is disabled. I apologize if my bug report is not up to scratch, but I have tried my best to give as much detail as I can, and this is my first time trying a bug report, as I am unsure how to proceed with this on my own. Thank you, Kevan B. UPDATE: it seems to be caused by a double quote character. Upon continuing to type my notes in my journal, I noticed that I had a quote and hit RET before I remembered to close the quote, and suddenly RET worked as expected! Then, after collecting my wits and after the end of my happy dance, I moved point up and away, to the heading preceding the one I was working under, and RET didn't indent properly. It seems that the open double quote might be masking the correct context. My apologies for not specifying originally, but I am on org 9.5.2 from melpa, using emacs 27.2.
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
Dear Tim Am 04.04.2022 17:49 schrieb Tim Cross: What is line-fill-mode? It isn't a 'standard' emacs mode, so must be some add-on? Sorry this was a "typo". At any rate, I don't see this problem when using standard auto-fill-mode. With this mode, when lines wrap (because I've exceeded the fill column) or if I use C-q to trigger filling, the wrapped lines are indented correctly so that lists are preserved. This is not the case with me. Please see this screenrecording https://debianforum.de/forum/gallery/image/3641/source In the top window you see the relevant lines from my init.el. In the bottom you see a orgroam capture buffer while I am tiping a loreipsum line and exceeding the fill column. It is not intended. And that is how it looks like in raw org :PROPERTIES: :ID: 7fe439ec-c46d-4da5-902a-3ba40cebb25e :END: #+title: test #+date: [2022-04-04 Mo 20:04] - Lorem ipsum dolro sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut - second item second line in second item - The first list entry got its newline char automatically via auto-fill-mode. The second entry got its newline by myself via pressing RET.
Re: Remove old WORG page with Org Syntax (draft) in favour of new syntax page by Timothy
Hi Nicolas, > I suggest to remove references to DATA, HEADERS, LABEL, RESNAME, RESULT, > SOURCE, SRCNAME and TBLNAME in org-element-affiliated keywords, which are here > for backward-compatibility reason, but shouldn’t appear nowadays (and are not > even mentioned in the manual). > > For the same reason, I suggest removing file+sys and file+emacs, which were > (and are AFAIK) planned for removal. Done :) Should we rename org-syntax to org-syntax-old? Or would you advocate for something else? All the best, Timothy
Re: Removing obsolete function `org-truely-invisible-p'.
On 04 Apr 2022, Ihor Radchenko wrote: From bb229b4f8f78ae52962d7bc90c8b1d4993af8263 Mon Sep 17 00:00:00 2001 From: Karl Fogel Date: Thu, 31 Mar 2022 19:02:38 -0500 Subject: [PATCH] Mark function obsolete & fix spelling of its name This commit message is a bit confusing. I would mention the function name: "Mark `org-truely-invisible-p' obsolete and fix spelling of its name" * lisp/org-macs.el (org-truely-invisible-p): Move to... * lisp/org-compat.el (org-truly-invisible-p): ...here, and add... (org-truely-invisible-p): ...this compatibility alias. It does mention both names :-). But I'm happy to rewrite in the style you suggest above; I was just trying to follow the CONTRIBUTE guidelines. It is too much. We can either 1. Obsolete org-truely-invisible-p. Then, there is not much point renaming it. 2. Rename it without obsoletion. Then, there is not much point moving the function definition to org-compat. Hmm. From the prior conversation in this thread, I thought we'd decided to do both. There are two separate issues here: 1) The function is no longer used in Org Mode or Emacs. 2) Unrelatedly, the function's name has a misspelling. (1) suggests that the function should be moved to 'org-compat.el' (if I understand correctly what that file is for). (2) is usually fixed with a rename and a compatibility alias -- i.e., this is what we would do for any function, whether used or unused. In your message 87h7b5rm6f.fsf@localhost of 19 Dec 2021, you wrote: I feel slightly reluctant about removal. If nothing, this function can be a reminder about visible-mode and keeping it has little downside. Though if others think that removing would be better, I would also be fine with it. Renaming sounds reasonable. Just need to define obsolete alias for the old name in org-compat.el. My patch was based on the above, and on the fact that obsolete (i.e., unused) functions apparently get moved to org-compat.el, at least based on what I see already in that file. From: Ihor Radchenko Subject: Re: Removing obsolete function `org-truely-invisible-p'. To: Karl Fogel Cc: Org Mode Date: Sun, 19 Dec 2021 17:14:32 +0800 Message-ID: <87h7b5rm6f.fsf@localhost> I usually just leave an ML link in such cases: https://orgmode.org/list/87h7b5rm6f.fsf@localhost As long as the ML link contains the Message-ID, as appears to be the case here, yeah. Mailing list archives can move, which causes links to suddenly stop working. But if the Message-ID is in the link, then (with a little extra work) one can always find the message in the new archive. (The reason I typically include more is to make things as easy as possible for those who are searching in a local archive using their regular mailreader. But I can switch to the above way if you'd prefer.) Best regards, -Karl
Re: org-agenda todos list sorted by earliest deadline first
I've done it, but tasks with no deadlines are still on top of the list Le 4 avril 2022 13:42:26 GMT+02:00, Ihor Radchenko a écrit : >Sébastien Gendre writes: > >> My Emacs version is 27.2 and Org is 9.4.4. >> >> The value of "org-agenda-sorting-strategy" is: >> >> ((agenda habit-down time-up priority-down category-keep) >> (todo priority-down category-keep deadline-up) >> (tags priority-down category-keep deadline-up) >> (search category-keep)) > >Try to move deadline-up to beginning of the lists: > >((agenda habit-down time-up priority-down category-keep) > (todo deadline-up priority-down category-keep) > (tags deadline-up priority-down category-keep) > (search category-keep)) > >Best, >Ihor
Re: org-agenda todos list sorted by earliest deadline first
I've tested it, but the tasks with no deadlines are still on top of the list. Le 4 avril 2022 13:42:26 GMT+02:00, Ihor Radchenko a écrit : >Sébastien Gendre writes: > >> My Emacs version is 27.2 and Org is 9.4.4. >> >> The value of "org-agenda-sorting-strategy" is: >> >> ((agenda habit-down time-up priority-down category-keep) >> (todo priority-down category-keep deadline-up) >> (tags priority-down category-keep deadline-up) >> (search category-keep)) > >Try to move deadline-up to beginning of the lists: > >((agenda habit-down time-up priority-down category-keep) > (todo deadline-up priority-down category-keep) > (tags deadline-up priority-down category-keep) > (search category-keep)) > >Best, >Ihor
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
c.bu...@posteo.jp writes: > Thanks to the discussion I now can see and describe my problem clearer. > > When using line-fill-mode it does not take the current org list indention into > account. Because of this org lines like this will appear. > > - one entry with a very long text ending in the second line > end > - second entry > > This is recognized (e.g. while html export) as two one-item-lists with a > paragraph between them. > > When I press RET myself the point is correct indented but not when it is done > automatically via line-fill-mode. > > Is there a solution for this? What is line-fill-mode? It isn't a 'standard' emacs mode, so must be some add-on? At any rate, I don't see this problem when using standard auto-fill-mode. With this mode, when lines wrap (because I've exceeded the fill column) or if I use C-q to trigger filling, the wrapped lines are indented correctly so that lists are preserved.
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
c.bu...@posteo.jp writes: > Am 04.04.2022 09:16 schrieb c.bu...@posteo.jp: >> Am 04.04.2022 06:06 schrieb Ihor Radchenko: >>> A list item continues until >>> there are _2_ blank lines or until the subsequent line is not indented >= >>> current list item indentation: >> Intereseting. What 2 lines not 1 like in paragraphs. Am I right to say >> that a paragraph ends with one blank line? > > Sorry, this was misunderstanding. > > I would like to know why does a list need 2 blank lines instead of 1? For what > reason exists this rule? Main reason is because you might want a list item which consists of multiple paragraphs. A possible alternative would be to require that lists are indented and flag a list item has ended either by a new list item marker or by text which is no longer indented. However, not everyone wants to be forced to indent their lists and like to have the list item start in the '0' column so we need some other way to mark the end and 2 blank lines seems a reasonable compromise. .
Re: Remove old WORG page with Org Syntax (draft) in favour of new syntax page by Timothy
Hello, Ihor Radchenko writes: > We currently have two versions of Org syntax in WORG: > 1. https://orgmode.org/worg/dev/org-syntax.html (old, not always accurate) > 2. https://orgmode.org/worg/dev/org-syntax-edited.html (new, being >discussed in https://orgmode.org/list/871r1g936z@gmail.com) > > The old syntax page is apparently ranked higher by search engines, > creating confusion among users (see the above discussion and the below > message sent off-list). > > Maybe we can move org-syntax-edited in place of org-syntax at this > point? I personally think that Tecosaur's version is strictly superior > to the old draft, even though is can still be further improved. > > WDYT? I have no objection. However, I suggest to remove references to DATA, HEADERS, LABEL, RESNAME, RESULT, SOURCE, SRCNAME and TBLNAME in org-element-affiliated keywords, which are here for backward-compatibility reason, but shouldn't appear nowadays (and are not even mentioned in the manual). For the same reason, I suggest removing file+sys and file+emacs, which were (and are AFAIK) planned for removal. Regards, -- Nicolas Goaziou
Re: buffer displays incorrectly after capture
On Fri, Apr 1, 2022 at 3:46 PM Skip wrote: > Another manifestation of the problem shows up when using > auto-revert-mode. Starting with the single headline in a folded state > as above, when I execute the following command in a shell, > echo "* TODO bar :action:" >>capture.org > then the capture.org buffer looks like this: > * TODO foo :action:...* TODO bar :action: > > TAB unfolding the first headline shows up like this: > * TODO foo :action: > some text...* TODO bar :action: I confirmed that the buffer display bug occurs with emacs -Q. Steps to reproduce: 1. From a shell, open emacs with an empty file: emacs -Q test.org 2. From emacs, enable auto-revert-mode: M-x auto-revert-mode 3. From another shell, add text to the file: echo "* foo\nsome text\n" >>test.org 4. From emacs, fold the headline: S-TAB 5. From the shell, add more text to the file: echo "* bar\n" >>test.org 6. Observe the incorrect display of the two headlines: * foo...* bar 7. From emacs, fix the buffer display: S-TAB 8. Observe the correct display of the two headlines: * foo... * bar This bug seems to trigger when text is added indirectly to an org-mode buffer, via both capture and auto-revert. I suspect it would show up via refile as well.
[BUG] org-id-update-id-locations function documentation correction [9.5.2 (9.5.2-g846226)]
The docstring for `org-id-update-id-locations' claims that the function will scan "all files currently mentioned in `org-id-locations'". This should probably be changed to `org-id-files'. Emacs : GNU Emacs 28.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2022-02-02 Package: Org mode version 9.5.2 (9.5.2-g846226)
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
On Mon, Apr 4, 2022 at 10:34 AM wrote: > > I would like to know why does a list need 2 blank lines instead of 1? > For what reason exists this rule? > - 1 blank line in a list item with create a paragraph break as I showed in my example earlier. It will not end the list item or list. - So we need 2 blank lines if we mean to end the list. Example: - list 1 item 1 second paragraph in list 1 item 1 - list 1 item 2 - list 2 item 1 because there are 2 blank lines before this item.
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
Am 04.04.2022 09:16 schrieb c.bu...@posteo.jp: Am 04.04.2022 06:06 schrieb Ihor Radchenko: A list item continues until there are _2_ blank lines or until the subsequent line is not indented >= current list item indentation: Intereseting. What 2 lines not 1 like in paragraphs. Am I right to say that a paragraph ends with one blank line? Sorry, this was misunderstanding. I would like to know why does a list need 2 blank lines instead of 1? For what reason exists this rule?
Re: ox-latex table tabbing support.
Hi Ihor,
Thanks for the response. I updated my patched and mailed the requested
copyright form to ass...@gnu.org
Kind regards,
Bob
--
Sent with Tutanota, the secure & ad-free mailbox.
Apr 4, 2022, 12:33 by yanta...@gmail.com:
> emacs--- via "General discussions about Org-mode."
> writes:
>
>> I have implemented tabbing
>> (http://www.ctex.org/documents/latex/latex2e-html/ltx-58.html) support for
>> ox-latex. By setting #+ATTR_LATEX: :mode tabbingthe exporter will use the
>> tabbing environment.
>>
>> The benefits of using tabbing over tabular:
>> - Can span multiple pages (also possible with long tables).
>> - Cell width is fixed and does not depend on the content.
>> - Cells can overflow.
>>
>
> Looks useful. Marking your message as a patch to be tracked at
> updated.orgmode.org
>
> Some comments are below.
>
>> TINYCHANGE
>>
>
> Note that your patch >15 LOC and cannot be applied without copyright
> assignment. See https://orgmode.org/worg/org-contribute.html#copyright
>
>> -;; `org-latex--org-table' or `org-latex--math-table' functions,
>> +;; `org-latex--org-table' or `org-latex--math-table' or
>> `org-latex--org-tabbing' functions,
>>
>
> We generally try to keep all the text in source files narrower than 70
> characters (default value of fill-column). You can use fill-region to
> make Emacs autofill the comment lines.
>
>> +(defun org-latex--align-string-tabbing (table info math?)
>>
>
> It looks like math? argument is unused. Is it intentional?
>
>> + "Return an appropriate LaTeX alignment string, for the
>> +latex tabbing environment.
>> +TABLE is the considered table. INFO is a plist used as
>> +a communication channel. When optional argument MATH? is
>> +non-nil, TABLE is meant to be a matrix, where all cells are
>> +centered."
>> +(or (org-export-read-attribute :attr_latex table :align)
>> +(let ((align "")
>> + (count 0)
>> + (separator ""))
>> + (progn
>>
>
> You do not need an extra progn inside let.
>
>> +(defun org-table--org-tabbing (table contenst info)
>>
>
> ^contents
>
>> + "Return appropriate LaTeX code for an Org table, using the
>> +latex tabbing syntax.
>> +TABLE is the table type element to transcode. CONTENTS is its
>> +contents, as a string. INFO is a plist used as a communication
>> +channel.
>> +This function assumes TABLE has `org' as its `:type' property and
>> +`tabbing' as its `:mode' attribute."
>> +(let ((output (format "\\begin{%s}\n%s\n%s\\end{%s}"
>> + "tabbing"
>> + (org-latex--align-string-tabbing table info )
>> + contenst
>>
>
> ^contents
>
>
> Best,
> Ihor
>
padding-feature.patch
Description: Binary data
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
Thanks to the discussion I now can see and describe my problem clearer. When using line-fill-mode it does not take the current org list indention into account. Because of this org lines like this will appear. - one entry with a very long text ending in the second line end - second entry This is recognized (e.g. while html export) as two one-item-lists with a paragraph between them. When I press RET myself the point is correct indented but not when it is done automatically via line-fill-mode. Is there a solution for this?
Remove old WORG page with Org Syntax (draft) in favour of new syntax page by Timothy (was: Multiline list entries / Is auto-fill-mode in org(roam) usual?)
Dear all,
We currently have two versions of Org syntax in WORG:
1. https://orgmode.org/worg/dev/org-syntax.html (old, not always accurate)
2. https://orgmode.org/worg/dev/org-syntax-edited.html (new, being
discussed in https://orgmode.org/list/871r1g936z@gmail.com)
The old syntax page is apparently ranked higher by search engines,
creating confusion among users (see the above discussion and the below
message sent off-list).
Maybe we can move org-syntax-edited in place of org-syntax at this
point? I personally think that Tecosaur's version is strictly superior
to the old draft, even though is can still be further improved.
WDYT?
Best,
Ihor
c.bu...@posteo.jp writes:
> Am 04.04.2022 09:44 schrieb Ihor Radchenko:
>> WORG is also official, though serves more like a wiki and not as
>> official as the manual. In your particular case, we are currently in
>> the
>> process of updating the WORG syntax page.
>> https://orgmode.org/worg/dev/org-syntax.html is an old page explicitly
>> stating that it is a draft ("Org Syntax (draft)"). I recommend using
>> https://orgmode.org/worg/dev/org-syntax-edited.html#Items if you want
>> to
>> check more up-to-date formal syntax description.
>
> For newbies (and for me) it is unclear why there are two "version" of
> syntax documents exist. The is confusing.
>
> Minimally the worg-version should point to the "official" org-version
> and back. When googling org things the worg pages are on top most of the
> time.
Re: Removing obsolete function `org-truely-invisible-p'.
Karl Fogel writes: >>Could you prepare a patch? Having a patch may encourage more >>feedback. > > Sure; please see attached. Thanks! Marking your message as a patch to be tracked at updates.orgmode.org > From bb229b4f8f78ae52962d7bc90c8b1d4993af8263 Mon Sep 17 00:00:00 2001 > From: Karl Fogel > Date: Thu, 31 Mar 2022 19:02:38 -0500 > Subject: [PATCH] Mark function obsolete & fix spelling of its name This commit message is a bit confusing. I would mention the function name: "Mark `org-truely-invisible-p' obsolete and fix spelling of its name" > * lisp/org-macs.el (org-truely-invisible-p): Move to... > * lisp/org-compat.el (org-truly-invisible-p): ...here, and add... > (org-truely-invisible-p): ...this compatibility alias. It is too much. We can either 1. Obsolete org-truely-invisible-p. Then, there is not much point renaming it. 2. Rename it without obsoletion. Then, there is not much point moving the function definition to org-compat. > From: Ihor Radchenko > Subject: Re: Removing obsolete function `org-truely-invisible-p'. > To: Karl Fogel > Cc: Org Mode > Date: Sun, 19 Dec 2021 17:14:32 +0800 > Message-ID: <87h7b5rm6f.fsf@localhost> I usually just leave an ML link in such cases: https://orgmode.org/list/87h7b5rm6f.fsf@localhost Best, Ihor
Re: org-agenda todos list sorted by earliest deadline first
Sébastien Gendre writes: > My Emacs version is 27.2 and Org is 9.4.4. > > The value of "org-agenda-sorting-strategy" is: > > ((agenda habit-down time-up priority-down category-keep) > (todo priority-down category-keep deadline-up) > (tags priority-down category-keep deadline-up) > (search category-keep)) Try to move deadline-up to beginning of the lists: ((agenda habit-down time-up priority-down category-keep) (todo deadline-up priority-down category-keep) (tags deadline-up priority-down category-keep) (search category-keep)) Best, Ihor
Re: ox-latex table tabbing support.
emacs--- via "General discussions about Org-mode."
writes:
> I have implemented tabbing
> (http://www.ctex.org/documents/latex/latex2e-html/ltx-58.html) support for
> ox-latex. By setting #+ATTR_LATEX: :mode tabbingthe exporter will use the
> tabbing environment.
>
> The benefits of using tabbing over tabular:
> - Can span multiple pages (also possible with long tables).
> - Cell width is fixed and does not depend on the content.
> - Cells can overflow.
Looks useful. Marking your message as a patch to be tracked at
updated.orgmode.org
Some comments are below.
> TINYCHANGE
Note that your patch >15 LOC and cannot be applied without copyright
assignment. See https://orgmode.org/worg/org-contribute.html#copyright
> -;; `org-latex--org-table' or `org-latex--math-table' functions,
> +;; `org-latex--org-table' or `org-latex--math-table' or
> `org-latex--org-tabbing' functions,
We generally try to keep all the text in source files narrower than 70
characters (default value of fill-column). You can use fill-region to
make Emacs autofill the comment lines.
> +(defun org-latex--align-string-tabbing (table info math?)
It looks like math? argument is unused. Is it intentional?
> + "Return an appropriate LaTeX alignment string, for the
> +latex tabbing environment.
> +TABLE is the considered table. INFO is a plist used as
> +a communication channel. When optional argument MATH? is
> +non-nil, TABLE is meant to be a matrix, where all cells are
> +centered."
> +(or (org-export-read-attribute :attr_latex table :align)
> +(let ((align "")
> + (count 0)
> + (separator ""))
> + (progn
You do not need an extra progn inside let.
> +(defun org-table--org-tabbing (table contenst info)
^contents
> + "Return appropriate LaTeX code for an Org table, using the
> +latex tabbing syntax.
> +TABLE is the table type element to transcode. CONTENTS is its
> +contents, as a string. INFO is a plist used as a communication
> +channel.
> +This function assumes TABLE has `org' as its `:type' property and
> +`tabbing' as its `:mode' attribute."
> +(let ((output (format "\\begin{%s}\n%s\n%s\\end{%s}"
> + "tabbing"
> + (org-latex--align-string-tabbing table info )
> + contenst
^contents
Best,
Ihor
Re: [PATCH] ol.el: add description format parameter to org-link-parameters
Hugo Heagren writes: > * ol.el (org-link-parameters): add parameter `:default-description', a > string or a function. LGTM in general. Note that I proposed (and never followed up on) a similar patch in the past: https://orgmode.org/list/87pnauvxht.fsf@localhost I like that you introduced an option to set default description to string, but I have several comments on the patch itself. > - (t (condition-case nil > - (funcall org-link-make-description-function link desc) > + (org-link-make-description-function > + (funcall org-link-make-description-function link desc)) > + (t (error > + (message "Can't get link description from %S" > +(symbol-name org-link-make-description-function)) > + (sit-for 2) > + nil) It looks like you removed condition-case used to catch errors on org-link-make-description function. I am pretty sure that it is not intentional. Similar condition-case could also be used for the :default-description function. +`:default-description' + + String or function used as a default when prompting users for a + link's description. A string is used as-is, a function is + called with the full link text as the sole argument, and should + return a single string. Why not two arguments like in org-link-make-description-function? Best, Ihor
bug#54670: Clocktable :step errors
> On Fri, 1 Apr 2022 15:49:45 +, Craig Smith > said: Craig> Online documentation states the :step month, semimonth or year commands are valid. The below link is one such instance. Craig> https://www.gnu.org/software/emacs/manual/html_node/org/The-clock-table.html Craig> But, I have tried the :step commands with Emacs 25.3.1 on Windows 10, Craig> Emacs 26.3 on Windows XP and Emacs 26.3 on my Android phone through Craig> Termux. All three versions do not accept the :step month, :step Craig> semimonth or :step year command. I have concluded the :step month, Craig> semimonth or year commands were valid at one time and online Craig> documentation has not caught up with the change. It is not a big Craig> problem, but Ι thought worth bringing to your attention. I think itʼs the other way around: those variants were added in a later version of org than the one youʼre using (and the online manual thus describes them). Theyʼre definitely available in emacs-27 and later. From memory, current org still supports emacs-26, so you could try installing the latest packaged org from ELPA. Robert --
Re: Ethical problems with MathJax as default - Was: Faulty SVG width
Yuchen Guo writes: >> The license is declared in the script. You can see it by following the >> script url. It is right on top. > > True. My fault. The problem is that the declaration is not > machine-readable by LibreJS. I understand the problem, however I do not see why LibreJS could not whitelist MathJax. It is a technical limitation of current LibreJS implementation, not the problem of software freedom. > On the other hand, I think it is more preferable and more > privacy-conscious to forbid loading from Cloudflare and use a local copy > of MathJax embedded in LibreJS instead: > > - One can not trust Cloudflare. > - Even if it is trusted, Cloudflare would still (at least) > log the IP address. To clarify, software freedom has little to do with privacy. Currently, ox-html does comply with https://www.gnu.org/prep/standards/standards.html Of course, it does not mean that privacy should be ignored. If you have any ideas or patches that can improve the current situation with the mathjax coudflare link, feel free to share them. >> I am not sure what is the problem here. Apache licence does not restrict >> modifications and you can use your modified MathJax source by >> customising org-html-mathjax-options. > > Oh, I meant the freedom of the website visitor replacing MathJax with a > modified version on-the-fly, not of the website authors. That is not > trivial. greasemonkey script? I guess that one can just replace all the scripts linking to .+/MathJax.js with local script references. Best, Ihor
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
c.bu...@posteo.jp writes:
> Am 04.04.2022 06:06 schrieb Ihor Radchenko:
>> A list item continues until
>> there are _2_ blank lines or until the subsequent line is not indented
>> >=
>> current list item indentation:
>
> Intereseting. What 2 lines not 1 like in paragraphs. Am I right to say
> that a paragraph ends with one blank line?
Yes, you are right. Blank line indicates end of a paragraph.
>> Everything is described in the manual. See
>> https://orgmode.org/manual/Plain-Lists.html#Plain-Lists
>
> I showed you a worg-link. Again this is a good example why worg hurts
> more then it helps; newbies. The site looked very official.
WORG is also official, though serves more like a wiki and not as
official as the manual. In your particular case, we are currently in the
process of updating the WORG syntax page.
https://orgmode.org/worg/dev/org-syntax.html is an old page explicitly
stating that it is a draft ("Org Syntax (draft)"). I recommend using
https://orgmode.org/worg/dev/org-syntax-edited.html#Items if you want to
check more up-to-date formal syntax description.
Best,
Ihor
Ethical problems with MathJax as default - Was: Faulty SVG width
Ihor Radchenko writes: > The license is declared in the script. You can see it by following the > script url. It is right on top. True. My fault. The problem is that the declaration is not machine-readable by LibreJS. On the other hand, I think it is more preferable and more privacy-conscious to forbid loading from Cloudflare and use a local copy of MathJax embedded in LibreJS instead: - One can not trust Cloudflare. - Even if it is trusted, Cloudflare would still (at least) log the IP address. > I am not sure what is the problem here. Apache licence does not restrict > modifications and you can use your modified MathJax source by > customising org-html-mathjax-options. Oh, I meant the freedom of the website visitor replacing MathJax with a modified version on-the-fly, not of the website authors. That is not trivial. Thanks for the tip! I will certainly use a local copy of MathJax when necessary. -- Yuchen Guo
Re: Multiline list entries / Is auto-fill-mode in org(roam) usual?
Dear Ihor, thanks for your feedback. Am 04.04.2022 06:06 schrieb Ihor Radchenko: A list item continues until there are _2_ blank lines or until the subsequent line is not indented >= current list item indentation: Intereseting. What 2 lines not 1 like in paragraphs. Am I right to say that a paragraph ends with one blank line? Everything is described in the manual. See https://orgmode.org/manual/Plain-Lists.html#Plain-Lists I showed you a worg-link. Again this is a good example why worg hurts more then it helps; newbies. The site looked very official.
