Re: [BUG] Checkbox item is broken in html export with table content [9.6 (9.6-??-bed47b437 @ /Users/hw/.emacs.d/.local/straight/build-28.1/org/)]
On 02/01/2023 15:50, Ihor Radchenko wrote: Max Nikulin writes: If an item contains block-level element then text paragraphs should be wrapped with ..., however there is no reason to put checkboxes outside of first paragraphs. Timothy, may you take a look? This is a bit non-trivial because paragraph is transcoded before the containing list item. So, we may need to pair parent lookup and child lookup in the transcoders - not ideal. It seems, the only way is to prepend checkbox symbol in `org-html-paragraph' (unless it is a descriptive list). The function already has an exception for list items. The hack to get cleaner HTML markup becomes dirtier.
Re: Intention of verbatim text?
writes: > My current solution is to convert ~code~ to code and > =verbatim= to verbatim. > > In that case the user can decide himself how to render them. In my > default CSS I would render the ~code~ in monospace with a light gray > background (different from the whole page background) and =verbatim= > with monospace only but without extra background color. > I think I would agree in an approach which leverages the power of CSS is the best approach. My own personal preference would be to have as much of the rendering/formatting of various elements managed by CSS classes as possible as this would make it much easier for users to change how things are rendered by modifying the CSS classes. Frameworks like Bulma (https://bulma.io) show how powerful just using CSS can be. Much easier to modify a CSS class than change a tag.
Re: [MAINTENANCE] Org orphanage?
Ihor Radchenko writes: > Bastien writes: > >> To be sure that we are not miscommunicating, my point is that we can >> advertize https://orgmode.org/worg/org-orphanage.html as a place where >> anyone can document orphan Org packages, then once there are enough >> packages on this page, we can try solving the other problem, that of >> providing a new shelter for these packages. Does that make sense? > > I am not sure why we need to wait with an optional offer. You mean, the optional offer of providing a proper shelter for orphan packages? > Merely announcing an orphan package without moving to sr.ht is also ok, > I think. Yes, that's what I think too: maintaining worg/org-orphanage.org is very useful. -- Bastien
[TASK] Enhance Worg HTML styling (was: [BUG] worg-setup.org is outdated)
Tim Cross writes: > A significant re-design of the worg styling is required in order to get > a presentation which both looks good and which works with respect to > accessibility requirements. I don't believe the current styles are > workable. Someone with greater CSS fu than me might do better, but from > what I could tell, the basic underlying premise for the existing styles > is flawed. I suspect it would be possible to 'fix' things, but it would > be a major style re-working. Strong +1 on working on Worg's styling. The task may be daunting, but we can also tackle it incrementally. >From memory, orgmode.org/worg is visited by ~30k persons each month, that 1000 persons per day. A patch enhancing the .css will make 1000 persons happiers each day. Who would like to help? -- Bastien
Re: [TASK] Enhance Worg HTML styling (was: [BUG] worg-setup.org is outdated)
Bastien Guerry writes on Wed 4 Jan 2023 11:21: > Strong +1 on working on Worg's styling. > > The task may be daunting, but we can also tackle it incrementally. > > >From memory, orgmode.org/worg is visited by ~30k persons each month, > that 1000 persons per day. A patch enhancing the .css will make 1000 > persons happiers each day. So far it was an obscure discussion for, but as a visitor of orgmode.org/worg I now feel concerned. What's wrong with Worg's styling? A specific example might be enlightening. (Enhancement for some can be deterioration for others.) Regards -- EOST (École et Observatoire des Sciences de la Terre) ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 110] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | [ slot available for rent ]
Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,
* Max Nikulin [2023-01-03 15:18]: > Eduardo, I am sorry, but from my opinion it is too much. Perhaps you are > just not realizing that resources of developers are rather limited. Getting > rid of `read-char-exclusive' in Org menus requires significant amount of > work. Yeah, right, I have spent few hours to make GNU Emacs package: rcd-org-export.el -- use Org to export Org: 2022-12-25 18:16:06.397296+03 https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-org-export-el-use-Org-to-export-Org-76272.html And from there I developed RCD Dashboard on 2022-12-25 17:44:11.336142+03 GNU Emacs package: rcd-dashboard.el -- Tool to build Emacs dashboards: https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-dashboard-el-Tool-to-build-Emacs-dashboards-76668.html And now I have full set of dashboards with people being assigned to tasks, plans, programs, projects, agenda, etc. Because I can't agree to your statements, that is why I use the user friendly Org mode based RCD Org Export Dashboard instead of standard Org blocking, user-unfriendly one. > Nobody argues that it would be a great improvement, but it is > necessary to make changes that are not obvious at first glance. It > would lead to confusing behavior otherwise. Nothing is obvious when it is not obvious. I got it. > Jean might be happy with the posted mock-up. The posted mock-up is not any more mock-up but daily used dashboard to export Org. > Unfortunately that code is too far from been ready to be used for > all users. So how far? Like few hours? > E.g. it does not use `org-export-registered-backends', not to > mention that all menus in the package should be consistent. I am aware of it, thanks. Feel free to make it. Do you really need it? Though, we speak here of non-blicking Org Export, and there are many ways to do it, we speak of decisions that are not user friendly, made before more than 10 years. There was enough time to use whatever one wish. I can't wait for somebody in mainstream Org to make it user friendly, mouse clickable, and so there is enough of it for you to adapt it to your own needs as in main stream. If you people wish. If you look at the RCD Dashboard, then how "menus" should look like may be left to user to decide. So far nobody uses my package that I know, and in that case, I will not keep improving what is not so far found as interesting for users. It works for me so well. That is why I use it. Feel free to bend your fingers with C-c C-e C-a C-f C-s, and I will keep using the mouse device to export Org. > It is OK to have a bunch of repetitive code for a demo, but it can > not be taken as is. You have not say that you like the functionality. Underlying repetitive stuff is not important. And I rather like that repetitive style than the Gordian knot of the Org code. > I am lost what is your actual needs after your request to rewrite > the export dispatcher for you. It can be rewritten in simple text, actually in Org mode alone it can work. That is up to those who are interested. Why develop something when there is no interest? I guess it must be 5-6 years that I was talking about sharing headings by e-mail, XMPP, SMS, etc. and since then I have received bunch of dollars because of those features. None of it was implemented in Org, because sharing is not part of it, or decisions, or developers burdens, etc. That is example of "why develop features when there is no interest for it". Good that Emacs is extensible by every user, otherwise it would be one way road with Org. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Bug? org-assert-version does not prevent mixed install
Ihor, I am still puzzled why you can not reproduce messed version compilation issue. I can not figure out what I am missing. I think, the case below is easier than dealing with packages: Consider the following file compile-broken.el where ~/src/org-mode contains git main HEAD version: (load "org") (let ((org-dir "~/src/org-mode/lisp")) (add-to-list 'load-path org-dir) (byte-recompile-directory org-dir 0 :force)) remove lisp/*.elc files, run "make autoloads" and emacs -Q -l compile-broken.el It causes messed version compilation. Side note: On attempt to quit (C-x C-c) I get org-clock-kill-emacs-query: Symbol’s function definition is void: org-clocking-buffer and I had to use `kill-emacs' at this point. Exit hooks should not be so aggressive. Next session demonstrates the issue: emacs -Q -L ~/src/org-mode/lisp/ -l org There is a way to get Org completely broken. Let's simulate pulling of bundled org through some dependency and configuring new directory afterwards: emacs -Q -l org --eval "(add-to-list 'load-path \"~/src/org-mode/lisp/\")" /tmp/test.org Version mismatch is not detected, but RET causes eval-buffer: Symbol’s function definition is void: org-assert-version I have no idea how to fight with such cases. If you still can not reproduce with Emacs <= 28.1 then I may only suggest to check (locate-library "org-macs") and to remind about (list-load-path-shadows). I have no other ideas besides your environment is not clean and development Org version is available to Emacs. On 28/12/2022 16:46, Ihor Radchenko wrote: Max Nikulin writes: Notice that `org-assert-version' works for compiled files only. I think that most reliable approach in this situation would be pulling `org-assert-version' into a dedicated new file, similar to what you suggested below. That way, we will not have feature cashes. I considered it before and discarded at first since when an Org version having such file is loaded then old version is used in the case of messed version compilation. As a result, modification of `org-assert-version' is ignored in the compiled version. I reconsidered my opinion, though I still can not get really robust problem detection. Emacs-27.1 and its built-in Org version is assumed below. Since `org-assert-version' has effect in compiled files only, we need some file with minimal dependencies that certainly will be compiled. It might be org-assert-version.el itself. However then it be required always rather than wrapped into `eval-when-compile' and should have (org-assert-version) call inside. However, I am concerned about what is going to happen if wrong org-version is defined during compilation. `org-assert-version' can then be compiled with wrong org-version value and later produce similar obscure error. If an old Org version is not loaded then the warning appears, so the assertion works. A couple of issues: - it does not suggest messed version compilation (reinstalling or removing *.elc files and recompiling) - due to long text just last paragraph about straight may be visible to the user. Perhaps it is better to expand https://orgmode.org/worg/org-faq.html#mixed-install and use a more concise message with this link. I have tried the following: - move `org-assert-version' definition to org-assert-version.el, add (org-assert-version) call to this file to have at least one file compiled. - add (require 'org-assert-version) before (org-assert-version) to other files. The warning appears unless built-in Org is loaded before adding new version to `load-path'. So we may proceed this way. Some details concerning compilation errors in the case of Emacs-27.1 and Org main: - org.el is compiled (to my surprise) - most of libraries not loaded before compilation, e.g. all ox-*.el files fails. The reason is that they require org-elemnt that requires org-persist. The latter fails to call `org-file-name-concat' (that is missed in loaded org-compat) and breaks creation of the .elc file. Finally, there is a way to not have org-assert-version.el loaded during regular sessions. Most of elisp files should have (eval-when-compile (require 'org-assert-version)) (org-assert-version) It should ensure latest `org-assert-version' definition during installing of a new Org version. The issue is that compilation of arbitrary file may fail and I am unsure if it is reasonable to introduce another file to ensure compiled variant and to require it everywehere (eval-when-compile (require 'org-assert-version)) (org-assert-version) (require 'org-assert-version-call) with org-assert-version-call.el (eval-when-compile (require 'org-assert-version)) (org-assert-version) (provide 'org-assert-version-call)
Re: Is function 'org-insert-property-drawer' usable?
On 31/12/2022 23:24, alain.coch...@unistra.fr wrote: For me, C-u C-c C-x d does insert a 'PROPERTIES' drawer, but M-x org-insert-property-drawer does not. I suppose, the idea is to invoke it like C-u M-x org-insert-drawer On 01/01/2023 20:23, Ihor Radchenko wrote: Ruijie Yu via writes: According to the source code of `org-insert-drawer', I think the manual is saying that when ARG is non-nil, the function simply calls `org-insert-property-drawer'. However, `org-insert-property-drawer' is not declared interactive, so you wouldn't be able to M-x it. I guess we can just make it into a command. I see no downsides. At least it was an intentional change: commit 471ddbd14e2bb3e7689cdca5e6a461e54b8be9d8 Author: Bastien Guerry Date: Thu Jan 26 09:18:10 2012 +0100 Improve `org-insert-drawer' and related documentation. * org.el (org-insert-property-drawer): Not an interactive command anymore. (org-insert-drawer): With a prefix argument, insert a property drawer. Check for headline within the region before inserting the drawer. Don't include special drawers in the completion table. (org-mode-map): New keybinding `C-c C-x d' for `org-insert-drawer'. * org.texi (Drawers): How to insert/complete drawers. Thanks to Nicolas Goaziou for the discussion and the patch.
CUSTOM_id ignored on blocks by ox-beamer
Hello, I’m writing course slides in org-mode (exported currently to beamer, but I want to also have html export in the long run), and I have trouble linking blocks (for theorems or definitions), as the CUSTOM_ID property is ignored by ox-beamer on blocks. I see this issue has already been raised on the list (https://list.orgmode.org/87lflg9ts2@nicolasgoaziou.fr/T/), and looking at the code it seems that it still needs to be modified. Unfortunately the code for org-beamer--format-block is quite complex and I do not see how to change it to add a label. Could someone on the list please give me a hand? Best, Alan signature.asc Description: PGP signature
Using header-args to set default TODO state?
I've been wondering if it's possible to define a default todo-state for all items appearing under a headline, like * shopping list :PROPERTIES: :header-args: todo-state: TOBUY :END: ** bananas ** bread so when calling org-agenda both bananas and bread have the todo-state TOBUY applied to them. Obviously placing "todo-state" after :header-args: doesn't work, it's just an example of how I imagine it could work.
Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,
Pointers for you Eduardo: (find-efunction 'org-export-dispatch) (find-efunction 'org-export--dispatch-ui) (progn (find-efunction 'org-export--dispatch-ui) (forward-line 48)) (progn (find-efunction 'org-export--dispatch-ui) (search-forward "Export scope")) (find-efunction 'org-export-define-backend) (find-library "ox-html") (progn (find-library "ox-html") (search-forward "Export to HTML")) -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,
* Max Nikulin [2023-01-03 15:18]: > Jean might be happy with the posted mock-up. Unfortunately that code is too > far from been ready to be used for all users. E.g. it does not use > `org-export-registered-backends', not to mention that all menus in the > package should be consistent. It is OK to have a bunch of repetitive code > for a demo, but it can not be taken as is. After looking into it, into `org-export-registered-backends', I will not use it, neither follow the chain of poor design. Users can get the choice otherwise in my package. I can have my own setup and recognition of various exports. I can't follow the bad design that happen to take place, so I will not lean on this below, I find that complex, while it need not be. Value: (#s(org-export-backend :name texinfo :parent nil :transcoders ((bold . org-texinfo-bold) (center-block . org-texinfo-center-block) (clock . org-texinfo-clock) (code . org-texinfo-code) (drawer . org-texinfo-drawer) (dynamic-block . org-texinfo-dynamic-block) (entity . org-texinfo-entity) (example-block . org-texinfo-example-block) (export-block . org-texinfo-export-block) (export-snippet . org-texinfo-export-snippet) (fixed-width . org-texinfo-fixed-width) (footnote-definition . org-texinfo-footnote-definition) (footnote-reference . org-texinfo-footnote-reference) (headline . org-texinfo-headline) (inline-src-block . org-texinfo-inline-src-block) (inlinetask . org-texinfo-inlinetask) (italic . org-texinfo-italic) (item . org-texinfo-item) (keyword . org-texinfo-keyword) (line-break . org-texinfo-line-break) (link . org-texinfo-link) (node-property . org-texinfo-node-property) (paragraph . org-texinfo-paragraph) (plain-list . org-texinfo-plain-list) (plain-text . org-texinfo-plain-text) (planning . org-texinfo-planning) (property-drawer . org-texinfo-property-drawer) (quote-block . org-texinfo-quote-block) (radio-target . org-texinfo-radio-target) (section . org-texinfo-section) (special-block . org-texinfo-special-block) (src-block . org-texinfo-src-block) (statistics-cookie . org-texinfo-statistics-cookie) (strike-through . org-texinfo-strike-through) (subscript . org-texinfo-subscript) (superscript . org-texinfo-superscript) (table . org-texinfo-table) (table-cell . org-texinfo-table-cell) (table-row . org-texinfo-table-row) (target . org-texinfo-target) (template . org-texinfo-template) (timestamp . org-texinfo-timestamp) (underline . org-texinfo-underline) (verbatim . org-texinfo-verbatim) (verse-block . org-texinfo-verse-block)) :options ((:texinfo-filename "TEXINFO_FILENAME" nil nil t) (:texinfo-class "TEXINFO_CLASS" nil org-texinfo-default-class t) (:texinfo-header "TEXINFO_HEADER" nil nil newline) (:texinfo-post-header "TEXINFO_POST_HEADER" nil nil newline) (:subtitle "SUBTITLE" nil nil parse) (:subauthor "SUBAUTHOR" nil nil newline) (:texinfo-dircat "TEXINFO_DIR_CATEGORY" nil nil t) (:texinfo-dirtitle "TEXINFO_DIR_TITLE" nil nil t) (:texinfo-dirdesc "TEXINFO_DIR_DESC" nil nil t) (:texinfo-printed-title "TEXINFO_PRINTED_TITLE" nil nil t) (:texinfo-classes nil nil org-texinfo-classes) (:texinfo-format-headline-function nil nil org-texinfo-format-headline-function) (:texinfo-node-description-column nil nil org-texinfo-node-description-column) (:texinfo-active-timestamp-format nil nil org-texinfo-active-timestamp-format) (:texinfo-inactive-timestamp-format nil nil org-texinfo-inactive-timestamp-format) (:texinfo-diary-timestamp-format nil nil org-texinfo-diary-timestamp-format)
Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,
> Can you send to me - here to the mailing list - a version of
> `org-export-dispatch', and also of other functions if needed, in which
> the parts that call `read-char-exclusive' are replaced by something
> non-blocking?
There is no Org version of menu that does not block. That it is there
is due to initial notion that some functions should be run on single
key, which is not bad in itself. Then people followed and continued
developing on that foundation creating tangled functions.
(find-function 'org-export--dispatch-ui)
So in Org, currently, there is only the blocking way. Functions in Org
Export or Org Agenda, can't be inspected interactively by using
commands like {C-h k}, you can inspect sources directly.
What you are asking is what my package offers:
GNU Emacs package: rcd-org-export.el -- use Org to export Org:
https://gnu.support/gnu-emacs/packages/GNU-Emacs-package-rcd-org-export-el-use-Org-to-export-Org-76272.html
You may inspect how functions look like:
(find-function 'org-html-export-as-html)
Then description:
org-html-export-as-html is an autoloaded interactive byte-compiled
Lisp function in ‘ox-html.el’.
(org-html-export-as-html &optional ASYNC SUBTREEP VISIBLE-ONLY
BODY-ONLY EXT-PLIST)
Basically ASYNC, SUBTREEP, VISIBLE-ONLY and BODY-ONLY are expected to
be either NON-NIL or NIL, and by using those switches, you use the
function to export.
What the function:
(find-function 'org-export--dispatch-ui)
does is making sure to "highlight" (irony) when user press this or
that key, like when user press the highlighted "h", that then the
subsequent key like "H" appears highlighted, indicating to user that
after pressing first key, there are just few other options left.
Then in general Org Export works like this:
First the underlying information:
- It recognizes which export are available. What is worse, because of
the not well taught design every OTHER package for Org export lean
on the same blocking interface foundation, and keep adding to it!
This is because developers of extensions for Emacs do not have other
choice, or their package would not be included in
org-export-dispatch
Bad design, dictates more bad design.
And if you ask me, of course that even simple change to interface
creates havoc in all of those known and unknown Org export packages.
Then there is the Org Broom that makes sure some apparently large,
objectively small problems, end up under the carpet.
Then visibly what Org Export does for user is following:
- Show to user options to toggle variables like ASYNC, SUBTREEP,
VISIBLE-ONLY, BODY-ONLY, they are supposed to be handled in real
time.
- Recognize which various exports among hundreds of them are available
and display them for user to press one among hundreds of possible
key combinations
- Then export function is invoked with paramenters ASYNC SUBTREEP
VISIBLE-ONLY BODY-ONLY EXT-PLIST, while some exports not support all
of them
To develop export library requires adapting to previously embedded or
hard coded expectation of mainstream Org.
Notion is now that the interface will be changed to transient, which
does something similar more or less. I don't know of mouse support in
transient, but what I have seen, it does not look like it.
For you to make eev based export is easy, just toggling of variables
and recognizing which export options are there, generating temporary
eev buffers as usual.
Objective reality points
- Within Emacs there are many multi key commands. If user wish to see
which key follows which key, can use packages like `which-key' or
similar.
Thus, it is superficial to involve some kind of highlighting single
keys. That idea could have work very good for developer who made
it. If I get used to it and acquire habit of it, I will keep using
it and develop more by same principle.
- That toggling variables need blocking screen is not coherent, as it
doesn't. A derived mode may define any keys, and instead of "C-b"
there can be simply "b" for "body-only" toggling.
- Using control key, like C-b, to toggle variables makes sense only in
writable buffers.
- For each single export users are forced by design to again click
"C-c C-e" and again invoke "h H" or other similar functions. This
fact alone makes Org less usable.
- Using emacsclient during Org Export is not feasible.
- Emacs get blocked.
- It ignores mouse and normal keyboard movements, it blocks Emacs and
invoking emacsclient during Org Export or Org Agenda gives
surprising impossible looking effects; this will not change with
transient adoption.
- Usability get forgotten.
- Package RCD Org Export, proves, that export screen may remain all the
time visible, without blocking Emacs, and user may within seconds
export to various different formats.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansu
[PATCH] org-datetree.el: Allow datetrees with TODO, priority, tags
Hi,
Here is a patch that allows to find datetree headlines that contain tags,
TODO or priority keywords.
Sometimes you need to set TODOs or tags to such headlines. When you do
this, next time you capture under this datetree, you get a new datetree
with the same date in the same file, which is annoying. This patch fixes it.
From 4d3194adf417ae5bad78c35a783ebca7974b8167 Mon Sep 17 00:00:00 2001
From: Ilya Chernyshov
Date: Thu, 15 Dec 2022 02:08:15 +0600
Subject: [PATCH] lisp/org-datetree.el: Allow datetrees with TODO, priority,
tags
* org-datetree.el (org-datetree--find-create-group,
org-datetree-find-iso-week-create): Allow finding a datetree with
TODO keyword, priority keyword or tag group.
* testing/lisp/test-org-datetree.el
(test-org-datetree/find-date-create,
test-org-datetree/find-iso-week-create): Add tests for a datetree with
tags, TODO or priority keywords.
* etc/ORG-NEWS (Datetree structure headlines can now have tags, TODO, priority keywords): Document the change.
* doc/org-manual.org: Update datetree definition.
---
doc/org-manual.org| 2 +-
etc/ORG-NEWS | 7 ++
lisp/org-datetree.el | 42 +++
testing/lisp/test-org-datetree.el | 16
4 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index f3b77ebad..4dfa91a94 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -22507,7 +22507,7 @@ level.
,*** 2022-10-08 Saturday
#+end_example
-Tags are allowed in the tree structure.
+Tags, TODO, priority keywords are allowed in the tree structure.
[fn:31] This is always the other, not the user. See the variable
~org-link-from-user-regexp~.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c5d9bdf6e..794bdf143 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -55,6 +55,13 @@ document header:
,#+LATEX_HEADER: \DefineVerbatimEnvironment{lstlisting}{Verbatim}{...whatever...}
#+END_src
+** New features
+*** Datetree structure headlines can now have tags, TODO, priority keywords
+
+~org-datetree-find-iso-week-create~ and
+~org-datetree--find-create-group~ functions can now find datetree
+headlines with tags, TODO or priority keywords
+
* Version 9.6
** Important announcements and breaking changes
diff --git a/lisp/org-datetree.el b/lisp/org-datetree.el
index 035ef047a..37e1ddf96 100644
--- a/lisp/org-datetree.el
+++ b/lisp/org-datetree.el
@@ -97,17 +97,28 @@ If time-period is month, then group entries by month."
(goto-char (point-min))
(let ((year (calendar-extract-year d))
(month (calendar-extract-month d))
- (day (calendar-extract-day d)))
+ (day (calendar-extract-day d))
+ (regexp-prefix (concat "^\\*+\\(?: +" (regexp-opt org-todo-keywords-1) "\\)?"
+ "\\(?: +\\[#.\\]\\)?"))
+ (tags-re "\\(?:[ \t]+:[[:alnum:]_@#%%:]+:\\)?[ \t]*$"))
(org-datetree--find-create
- "^\\*+[ \t]+\\([12][0-9]\\{3\\}\\)\\(\\s-*?\
-\\([ \t]:[[:alnum:]:_@#%%]+:\\)?\\s-*$\\)"
+ (concat
+regexp-prefix
+" +\\([12][0-9]\\{3\\}\\)"
+tags-re)
year)
(org-datetree--find-create
- "^\\*+[ \t]+%d-\\([01][0-9]\\) \\w+$"
+ (concat
+regexp-prefix
+" +%d-\\([01][0-9]\\) \\w+"
+tags-re)
year month)
(when (eq time-grouping 'day)
(org-datetree--find-create
- "^\\*+[ \t]+%d-%02d-\\([0123][0-9]\\) \\w+$"
+ (concat
+ regexp-prefix
+ " +%d-%02d-\\([0123][0-9]\\) \\w+"
+ tags-re)
year month day)
;;;###autoload
@@ -144,20 +155,31 @@ will be built under the headline at point."
(iso-date (calendar-iso-from-absolute
(calendar-absolute-from-gregorian d)))
(weekyear (nth 2 iso-date))
- (week (nth 0 iso-date)))
+ (week (nth 0 iso-date))
+ (regexp-prefix (concat "^\\*+\\(?: +" (regexp-opt org-todo-keywords-1) "\\)?"
+ "\\(?: +\\[#.\\]\\)?"))
+ (tags-re "\\(?:[ \t]+:[[:alnum:]_@#%%:]+:\\)?[ \t]*$"))
;; ISO 8601 week format is %G-W%V(-%u)
(org-datetree--find-create
- "^\\*+[ \t]+\\([12][0-9]\\{3\\}\\)\\(\\s-*?\
-\\([ \t]:[[:alnum:]:_@#%%]+:\\)?\\s-*$\\)"
+ (concat
+regexp-prefix
+" +\\([12][0-9]\\{3\\}\\)"
+tags-re)
weekyear nil nil
(format-time-string "%G" time))
(org-datetree--find-create
- "^\\*+[ \t]+%d-W\\([0-5][0-9]\\)$"
+ (concat
+regexp-prefix
+" +%d-W\\([0-5][0-9]\\)"
+tags-re)
weekyear week nil
(format-time-string "%G-W%V" time))
;; For the actual day we use the regular date instead of ISO week.
(org-datetree--find-create
- "^\\*+[ \t]+%d-%02d-\\([0123][0-9]\\) \\w+$"
+ (concat
+regexp-prefix
+" +%d-%02d-\\([0123][0-9]\\) \\w+"
+tags-re)
year month day
(defun org-datetree--find-create
diff --git a/testing/l
Re: [TASK] Enhance Worg HTML styling (was: [BUG] worg-setup.org is outdated)
alain.coch...@unistra.fr writes: > Bastien Guerry writes on Wed 4 Jan 2023 11:21: > > > Strong +1 on working on Worg's styling. > > > > The task may be daunting, but we can also tackle it incrementally. > > > > >From memory, orgmode.org/worg is visited by ~30k persons each month, > > that 1000 persons per day. A patch enhancing the .css will make 1000 > > persons happiers each day. > > So far it was an obscure discussion for, but as a visitor of > orgmode.org/worg I now feel concerned. What's wrong with Worg's > styling? A specific example might be enlightening. (Enhancement for > some can be deterioration for others.) > As a simple example, try increasing the font size and see what happens to the menus. Keep in mind that some users require a very large font (for example, I use a 26 or 28 pt font. The current site is not good from an accessibility perspective, renders inconsistently with different browsers, does not have consistent keyboard navigation, arguably has inconsistent styling in some areas etc. If you are able to use the defaults (default font and size, default fg/bg colors, normal 'desktop' screen, things seem ok. However, once you need different fonts, different size text, different fg/bg colors or are using a mobile device or assistive technologies, like a screen reader, things rapidly degrade. There have also been numerous other issues (many have already been addressed) such as broken links, links to data which doesn't exist or has wrong MIME type, issues associated with file name case etc. There is also a fair amount of inconsistency in how pages are presented - some seem to have good navigation support while others do not, some pages seem to fit into an overall 'site map' while others seem to be out in their own island etc. As a result, the ability to effectively browse the site and follow 'threads' of information is often challenging. Perhaps even more unfortunate is that sometimes, you can come across some good information in the worg site, but finding that same information again at a latter date is often extremely challenging.
