Re: [PATCH] Re: Adding target and custom id links doesn't ask for description
> > > Carlos, have you tried Ihor's patch? I like the intention, but I do not > see any effect. > Yes, I've tested it with target and custom_id links and, as you said, there is no change in behavior. The entire URL is still pasted and no chance to edit it is given to the user. Best regards -- Carlos
Re: [PATCH] Re: Adding target and custom id links doesn't ask for description
> > > I suggest to set description to nil and thus ask the user in such > scenario. > I'm fine with that. Alternatively the default may be the target or custom id (that is, the same that is in the link part), again letting the user change it. Thanks! Best regards, Carlos
Re: Adding target and custom id links doesn't ask for description
A few more details. My org-mode version 9.5.4 (9.5.4-ge0b05b). This is the link that org-insert-link inserts for <>: [[here][file:~/Desktop/Org/capturas.org::here]] This is the link that org-insert-link inserts for CUSTOM_ID = cusid: [[#cusid][file:~/Desktop/Org/capturas.org::#cusid]] Perhaps description and link are swapped? In both cases the full path is redundant since the link is pointing to the current file, but the verbosity is arguably less adequate for the description field. Best regards — Carlos
Adding target and custom id links doesn't ask for description
Hi all, When storing a <> or CUSTOM_ID link with org-store-link and then adding it with C-c C-l, org doesn’t ask for a description but automatically inserts an ugly description like: ~/Desktop/Org/captures.org::target or: ~/Desktop/Org/captures.org::#7EFBCEA1-0D17-45B9-A125-10FE581752F8 The entire path is inserted even when the target itself is simply “target”. But, more importantly, no chance to change the description is given to the user. This behavior is not observed when an ID link is stored, which seems pretty inconsistent since there is no clear difference wrt the CUSTOM_ID case. The inconvenience of this behavior and the inconsistent treatment of ID vs CUSTOM_ID makes me believe that this is not intended but a bug (perhaps a regression, but I’ve not been using org-mode for long enough to say). The source of this behavior is in org-store-link: ;; If store function actually set `:description' property, use ;; it, even if it is nil. Otherwise, fallback to link value. (setq desc (if (plist-member org-store-link-plist :description) (plist-get org-store-link-plist :description) link))) so that auto-desc is later assumed in org-insert-link, even then the store function has provided no description at all! Best regards — Carlos
Re: [BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Hi Ihor, On Thu, Nov 18, 2021 at 7:28 AM Ihor Radchenko wrote: > > Carlos Pita writes: > > > I see no reason why a match inside b2 will hide b1 and b3 but not a > > and c (I'm referring to the headings, not the contents). > > I think you misread the docstring for org-show-context-detail: Sorry, I don't concur here. This is in the docstring I'm interested in (org-occur): The tree will show the lines where the regexp matches, and any other context defined in ‘org-show-context-detail’, which see. It might be that org-show-context-detail is used for org-reveal, but this says it's also used for org-occur, which makes sense. Besides, there is occur-tree when using the command ‘org-occur’ (‘C-c / /’) as a context for org-show-context-detail and it indeed makes a difference in what is shown and what is hidden. > This variable does not control how much text is hidden, but rather how > much context is revealed around a folded text. > Your misunderstanding may come from the fact that you are interested in > org-occur, which first folds everything inside lowest-level headings. It's not very relevant to my concern if things are first hidden and then revealed, because that will just change my question to why top-levels are not hidden to begin with. Again: The tree will show the lines where the regexp matches, and any other context defined in ‘org-show-context-detail’, which see. The top-level headings in my example don't match the regexp and are not part of the context that org-show-context-detail should reveal with my current configuration. I cannot help concluding that this fact contradicts the documentation. Moreover, even if a escape clause were found in the documentation, the examples I've presented show a behavior that is clearly different for the top-level compared to any other level and that alone calls for some kind of explanation IMO, as it is now it seems arbitrary, perhaps there is an obvious reason for this that I'm failing to grasp. > Consider agenda views. The relevant default value in I indeed considered the agenda, but I prefer using a sparse tree. I have a file with a large number of brief notes in top level headings and it's useful to see the expanded matching notes, the behaviour of org-occur is ideal in this regard, instead the agenda only shows the headings and even in follow mode it's more cumbersome than merely pressing M-g n/p directly in the target buffer. The problem I have now is that hundreds of unmatching headings are still shown just because they happen to be at the top-level. I see I could demote them or just use the agenda, it's no big deal after all. But because of all the reasons above I judge that the current behavior is not right, that's the reason for my report. Nevertheless, thank you for your suggestions, as always. Best regards, Carlos
Re: [BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
As a concrete example: * a ca * b ** ba cba ** bb cbb ** bc cbc * c cc Then C-c / / cbb: * a... * b... ** bb cbb ... * c... This is also true going deeper into the hierarchy: * a ca * b ** ba cba ** bb *** bba cbba *** bbb cbbb *** bbc cbbc ** bc cbc * c cc Then C-c / / cbbb: * a... * b... ** bb... *** cbbb cbbb ... * c... It's just the top-level that gets a special treatment.
Re: [BUG] Weird sparse tree folding [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Hi Ihor, > > Maybe I'm not getting how this is supposed to work, but it makes no > > sense to me. > > M-x org-reveal (C-c C-r) Thanks for the tip, I didn't know about this and it indeed seems useful in order to avoid unfolding everything else. That said, my report was about the expansion of: * a... ** b3 c3 ... to: * a... ** b3 c3 ... c4 ... when pressing TAB at the beginning of the first ... That seems wrong to me, at least I'm not finding any way to make sense of it. Maybe it's just that TAB should be disallowed there, I don't know. Best regards, Carlos
Re: [BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Hi Ihor, > Can you elaborate? If the docstring is not clear enough, we can easily > improve it. Consider for example: minimal show current headline; if point is not on headline, also show entry So if you have: * a * b ** b1 ** b2 ** b3 * c I see no reason why a match inside b2 will hide b1 and b3 but not a and c (I'm referring to the headings, not the contents). The only way to change the documentation to convey that is to state an explicit exception for the top level, but that seems extremely ad hoc. Perhaps there is a rationale, some presumption about what is in the top-level take makes it a valuable context no matter what the preferred context detail is set to, but if that's the case I find it too opinionated. Best regards, Carlos
[BUG] Agenda query trailing spaces [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Hi all,
when I press [ or ] to add additional words to the agenda query but then
immediately abort the prompt with C-g without actually adding any new
word, a trailing extra space is added to the query. After doing the same
n times, the query includes n trailing spaces.
Best regards,
Carlos
Emacs : GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin20.6.0, NS
appkit-2022.60 Version 11.6 (Build 20G165))
of 2021-11-14
Package: Org mode version 9.5 (release_9.5-225-g494c20.dirty @
/Users/carlos/Install/Source/org-mode/lisp/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-directory "~/Documents"
org-bibtex-headline-format-function '(closure
(org-id-locations
org-agenda-search-view-always-boolean org-agenda-overriding-header
t)
(entry) (cdr (assq :title entry)))
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-export-before-parsing-hook '(org-attach-expand-links)
org-default-notes-file "~/Documents/Capturas.org"
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-mode-hook '((closure
(org-agenda-skip-regexp org-table1-hline-regexp
org-table-tab-recognizes-table\.el
org-table-dataline-regexp org-table-any-border-regexp
org-agenda-restriction-lock-overlay
org-agenda-overriding-restriction org-agenda-diary-file
org-complex-heading-regexp t)
nil (setq imenu-create-index-function 'org-imenu-get-tree))
(closure
(org--rds reftex-docstruct-symbol
org-element-greater-elements visual-fill-column-width org-clock-history
org-agenda-current-date org-with-time org-defdecode org-def
org-read-date-inactive org-ans2 org-ans1
org-columns-current-fmt-compiled org-clock-current-task
org-clock-effort org-agenda-skip-function
org-agenda-skip-comment-trees org-agenda-archives-mode
org-end-time-was-given org-time-was-given
org-log-note-extra org-log-note-purpose org-log-post-message
org-last-inserted-timestamp
org-last-changed-timestamp org-entry-property-inherited-from
org-blocked-by-checkboxes org-state
org-agenda-headline-snapshot-before-repeat
org-agenda-buffer-name org-agenda-start-on-weekday
org-agenda-buffer-tmp-name org-priority-regexp
org-mode-abbrev-table org-mode-syntax-table
org-element-use-cache org-element-cache-persistent
buffer-face-mode-face org-tbl-menu org-org-menu
org-struct-menu org-entities org-last-state
org-id-track-globally org-clock-start-time texmathp-why
remember-data-file org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist
calc-embedded-open-mode calc-embedded-open-formula
calc-embedded-close-formula align-mode-rules-list
org-emphasis-alist org-emphasis-regexp-components
org-export-registered-backends org-modules
crm-separator org-babel-load-languages
org-id-overriding-file-name org-indent-indentation-per-level
org-element-paragraph-separate org-agenda-buffer-name
org-inlinetask-min-level t)
nil (add-hook 'change-major-mode-hook 'org-show-all 'append
'local))
(closure
(org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no org-babel-tangle-uncomment-comments
org-src-preserve-indentation org-src-lang-modes
org-edit-src-content-indentation
org-babel-library-of-babel t)
nil (add-hook 'change-major-mode-hook
#'org-babel-show-result-all 'append 'local))
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-confirm-shell-link-function 'yes-or-no-p
org-reveal-start-hook '(org-decrypt-entry)
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-elisp-link-function 'yes-or-no-p
org-cycle-separator-lines 1
org-todo-keywords '((sequence "TODO" "NEXT" "|" "DONE"))
outline-minor-mode-buttons '(("▶" "▼" outline--valid-char-p))
org-support-shift-select t
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-preview-latex-default-process 'dvisvgm
org-persist-before-write-hook '(org-element--cache-persist-before-write)
org-tab-first-hook
Re: Weird gap in agenda mode-line
> I don't see this in my agenda view. Image attached. This is because there is a span in your case (Day). The space is still there but it's not an extra one. The space in: " " ;; <- this is the extra space '(:eval (org-agenda-span-name org-agenda-current-span)) should be conditional to the expression below evaluating to something different than the empty string. Best regards, Carlos
[BUG] Weird sparse tree folding [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Hi all,
with this content:
* a
** b1
c1
** b2
c2
** b3
c3
** b4
c4
** b5
c5
I create a sparse tree for c3: C-/ / c3
I get this:
* a...
** b3
c3
...
Expanding the three dots at the bottom:
* a...
** b3
c3
...
c4
...
The new three dots are not expandable.
Maybe I'm not getting how this is supposed to work, but it makes no
sense to me.
Best regards,
Carlos
---
Emacs : GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin20.6.0, NS
appkit-2022.60 Version 11.6 (Build 20G165))
of 2021-11-14
Package: Org mode version 9.5 (release_9.5-225-g494c20.dirty @
/Users/carlos/Install/Source/org-mode/lisp/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-directory "~/Documents"
org-bibtex-headline-format-function '(closure
(org-id-locations
org-agenda-search-view-always-boolean org-agenda-overriding-header
t)
(entry) (cdr (assq :title entry)))
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-export-before-parsing-hook '(org-attach-expand-links)
org-default-notes-file "~/Documents/Capturas.org"
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-mode-hook '((closure
(org-agenda-skip-regexp org-table1-hline-regexp
org-table-tab-recognizes-table\.el
org-table-dataline-regexp org-table-any-border-regexp
org-agenda-restriction-lock-overlay
org-agenda-overriding-restriction org-agenda-diary-file
org-complex-heading-regexp t)
nil (setq imenu-create-index-function 'org-imenu-get-tree))
(closure
(org--rds reftex-docstruct-symbol
org-element-greater-elements visual-fill-column-width org-clock-history
org-agenda-current-date org-with-time org-defdecode org-def
org-read-date-inactive org-ans2 org-ans1
org-columns-current-fmt-compiled org-clock-current-task
org-clock-effort org-agenda-skip-function
org-agenda-skip-comment-trees org-agenda-archives-mode
org-end-time-was-given org-time-was-given
org-log-note-extra org-log-note-purpose org-log-post-message
org-last-inserted-timestamp
org-last-changed-timestamp org-entry-property-inherited-from
org-blocked-by-checkboxes org-state
org-agenda-headline-snapshot-before-repeat
org-agenda-buffer-name org-agenda-start-on-weekday
org-agenda-buffer-tmp-name org-priority-regexp
org-mode-abbrev-table org-mode-syntax-table
org-element-use-cache org-element-cache-persistent
buffer-face-mode-face org-tbl-menu org-org-menu
org-struct-menu org-entities org-last-state
org-id-track-globally org-clock-start-time texmathp-why
remember-data-file org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist
calc-embedded-open-mode calc-embedded-open-formula
calc-embedded-close-formula align-mode-rules-list
org-emphasis-alist org-emphasis-regexp-components
org-export-registered-backends org-modules
crm-separator org-babel-load-languages
org-id-overriding-file-name org-indent-indentation-per-level
org-element-paragraph-separate org-agenda-buffer-name
org-inlinetask-min-level t)
nil (add-hook 'change-major-mode-hook 'org-show-all 'append
'local))
(closure
(org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no org-babel-tangle-uncomment-comments
org-src-preserve-indentation org-src-lang-modes
org-edit-src-content-indentation
org-babel-library-of-babel t)
nil (add-hook 'change-major-mode-hook
#'org-babel-show-result-all 'append 'local))
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-confirm-shell-link-function 'yes-or-no-p
org-reveal-start-hook '(org-decrypt-entry)
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-elisp-link-function 'yes-or-no-p
org-cycle-separator-lines 1
org-todo-keywords '((sequence "TODO" "NEXT" "|" "DONE"))
outline-minor-mode-buttons '(("▶" "▼" outline--valid-char-p))
org-support-shift-select t
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-preview-latex-default-process 'dvisvgm
[BUG] org-occur doesn't hide unmatching top-levels [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Hi all, I don't see any clear reason why org-occur should hide unmatching entries except at the top level, where it merely folds them. For files containing lots of top-level entries this requires tree demoting in order to hide irrelevant information, but this imposes constraints on the tree structure that are not related to its author's goals. It has been asked in the past: - https://stackoverflow.com/questions/7602787 - https://emacs-orgmode.gnu.narkive.com/ogvwJnHD I've been playing with org-show-context-detail and it doesn't seem to be any option which actually hides top levels, though the description of some options seem to imply that they should, I believe. This is why I'm reporting this as a bug and not a feature request. Best regards, Carlos --- Emacs : GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin20.6.0, NS appkit-2022.60 Version 11.6 (Build 20G165)) of 2021-11-14 Package: Org mode version 9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/) current state: == (setq org-link-elisp-confirm-function 'yes-or-no-p org-directory "~/Documents" org-bibtex-headline-format-function '(closure (org-id-locations org-agenda-search-view-always-boolean org-agenda-overriding-header t) (entry) (cdr (assq :title entry))) org-persist-after-read-hook '(org-element--cache-persist-after-read) org-export-before-parsing-hook '(org-attach-expand-links) org-default-notes-file "~/Documents/Capturas.org" org-archive-hook '(org-attach-archive-delete-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-persist-before-read-hook '(org-element--cache-persist-before-read) org-mode-hook '((closure (org-agenda-skip-regexp org-table1-hline-regexp org-table-tab-recognizes-table\.el org-table-dataline-regexp org-table-any-border-regexp org-agenda-restriction-lock-overlay org-agenda-overriding-restriction org-agenda-diary-file org-complex-heading-regexp t) nil (setq imenu-create-index-function 'org-imenu-get-tree)) (closure (org--rds reftex-docstruct-symbol org-element-greater-elements visual-fill-column-width org-clock-history org-agenda-current-date org-with-time org-defdecode org-def org-read-date-inactive org-ans2 org-ans1 org-columns-current-fmt-compiled org-clock-current-task org-clock-effort org-agenda-skip-function org-agenda-skip-comment-trees org-agenda-archives-mode org-end-time-was-given org-time-was-given org-log-note-extra org-log-note-purpose org-log-post-message org-last-inserted-timestamp org-last-changed-timestamp org-entry-property-inherited-from org-blocked-by-checkboxes org-state org-agenda-headline-snapshot-before-repeat org-agenda-buffer-name org-agenda-start-on-weekday org-agenda-buffer-tmp-name org-priority-regexp org-mode-abbrev-table org-mode-syntax-table org-element-use-cache org-element-cache-persistent buffer-face-mode-face org-tbl-menu org-org-menu org-struct-menu org-entities org-last-state org-id-track-globally org-clock-start-time texmathp-why remember-data-file org-agenda-tags-todo-honor-ignore-options iswitchb-temp-buflist calc-embedded-open-mode calc-embedded-open-formula calc-embedded-close-formula align-mode-rules-list org-emphasis-alist org-emphasis-regexp-components org-export-registered-backends org-modules crm-separator org-babel-load-languages org-id-overriding-file-name org-indent-indentation-per-level org-element-paragraph-separate org-agenda-buffer-name org-inlinetask-min-level t) nil (add-hook 'change-major-mode-hook 'org-show-all 'append 'local)) (closure (org-src-window-setup *this* org-babel-confirm-evaluate-answer-no org-babel-tangle-uncomment-comments org-src-preserve-indentation org-src-lang-modes org-edit-src-content-indentation org-babel-library-of-babel t) nil (add-hook 'change-major-mode-hook #'org-babel-show-result-all 'append 'local)) org-babel-result-hide-spec org-babel-hide-all-hashes) org-confirm-shell-link-function 'yes-or-no-p org-reveal-start-hook '(org-decrypt-entry) outline-isearch-open-invisible-function 'outline-isearch-open-invisible org-agenda-before-write-hook '(org-agenda-add-entry-text) org-show-context-detail '((agenda . local) (bookmark-jump . lineage) (isearch . lineage) (occur-tree . minimal) (default .
Re: Weird gap in agenda mode-line
Hi Ihor (sorry I have been calling you Igor for a while now :p), > (list "Org-Agenda" > (if (get 'org-agenda-files 'org-restrict) " []" "") > " " ;; <- this is the extra space > [...] > This part of code has not been changed from 2010. Ok then, nevermind the highlight issue which is probably related to my setup, what is reproducible is the "space issue" and the reason is obvious now. That said, what is the point of the list? What is the reason not to concatenate the parts into one single string? It looks and feels weird as if each section had its own menu while it's all the same thing. Best regards, Carlos
org-metashiftleft/right should honor org-support-shift-select
Hi all, on macOS option-shift-left / right extend the selection by one word. Emacs by default binds meta-shift-left / right in a way that is compatible with the system shortcuts. But org-mode interferes with these bindings even when org-support-shift-select is t. OTOH, an effort has been done to support shift selection in org-shiftcontrolleft / right. The problem is that macOS uses option instead of control to achieve selection by word. Best regards, Carlos
Re: Weird gap in agenda mode-line
Hi Igor, Have you checked that there is no extra space (I mean with the default bg face) as in the attached image? I've checked this now again with org main branch and emacs master branch and the gap is still there. Best regards, Carlos
Re: Unable to install from elpa
This might be because the builtin version is the same as the one in elpa (although if that's the case the UI is somewhat confusing) but I'm not sure about that because I don't quite understand the relationship between builtin versions and stable external releases. I mean, is builtin org only updated to match external releases or does it follow a different cadence? Does a strict number version match between builtin and external implies exactly the same org revision? And in this case, is it expected that package.el doesn't offer org as a valid installation target nor prepends org's local path to the builtin one? Best regards, Carlos
Unable to install from elpa
Hi all,
in a clean emacs-28 install I do:
M-x package-install org
I get:
Possible completions are:
org-contrib org-edna org-real org-translate orgalist
package-archives has:
(("gnu" . "https://elpa.gnu.org/packages/;)
("nongnu" . "https://elpa.nongnu.org/nongnu/;))
I do list-packages, org is now listed as available in gnu archive, I
install it from there, relaunch emacs (again with -Q), do
(package-initialize) and:
- check org-version: it's still the builtin one.
- check load-path: doesn't include my ~/.emacs.d/elpa/org-9.5
directory (although it exists and installing other packages works as
expected)
So many things are not working properly:
1. I'm unable to install org using package-install.
2. I can install it from the package list but then it's not added to load-path.
3. Of course the builtin version gets loaded instead of the elpa one.
All this is in a recent build from emacs-28 with default configure
options (including native compilation).
Best regards,
Carlos
Weird gap in agenda mode-line
Hi all, in the *Org Agenda* buffer mode-line I'm seeing a weird gap that I can't remember whether it was before or not. In the attached screenshot the gap shows a different face than the rest. I don't know under which circumstances this change of face happens but, in any case, the extra space is always there (emacs -q) and there is some combination in my setup that sometimes more obviously reveals it. I don't know if that's a lighter with just a space on it or what. Best regards, Carlos --- org-mode version: 9.5, release_9.5-68-g77e2ec (emacs-28 branch)
Re: org-goto shows full-size help window
> > .See https://list.orgmode.org/orgmode/87mtnovv7f@alphapapa.net/ > It should be already fixed on bugfix branch. > Thanks for the prompt response! I'm going to install it from gnu elpa then. What is the exact relationship between bugfix and the version of org shipped with emacs? When emacs is released does it always include the latest org bugfix release available at the time? I'm not asking about my particular situation, after all I'm running an emacs prerelease, but in general. Best regards, Carlos >
Re: Inconsistent usage of "overview"
I believe my confusion was due to the fact that the docstring of org-startup-folded is not particularly precise regarding to its possible values. On the one hand it seems to be a toggle, but its initial value is nevertheless showeverything and not t. On the other hand it states that "This can also be configured on a per-file basis by adding one of the following lines anywhere in your buffer..." but it's not clear whether these values may also be assigned directly to the variable. If you do that, then inconsistencies appear: when they are options in a buffer, showall and nofold are both mapped to nil, fold and overview are both mapped to t; but when they are directly set this mapping obviously doesn't take place. Following a suggestion I'd read elsewhere, I set org-startup-folded to fold (and, later, to overview), and this is not really calling org-overview but instead ends up in a catch-all clause that hides drawers. By the same token I could have set org-startup-folded to foobar. The point still stands that showall and contents fold drawers but overview (aka fold) doesn't fold drawers, which seems extremely odd to me. Best regards, Carlos
Inconsistent usage of "overview"
Hi all, Here is something I find very confusing. In [1]: #+STARTUP: overview #+STARTUP: content #+STARTUP: showall #+STARTUP: showlevels #+STARTUP: showeverything In org-startup-folded docstring it is said that it takes values equivalent to: #+STARTUP: fold (or ‘overview’, this is equivalent) #+STARTUP: nofold(or ‘showall’, this is equivalent) #+STARTUP: content #+STARTUP: showlevels ( = 2..5) #+STARTUP: showeverything The fact that "overview" is also called "fold" doesn't make what follows simpler, but so far so good. Then there is the function org-overview, which: Switch to overview mode, showing only top-level headlines. But org-overview shows drawers unfolded while "overview" mode folds drawers at startup. That is, if you start in "fold" or "overview" mode (as in #+STARTUP or org-startup-folder) and then cycle visibility all the way back to "overview" (now as in org-overview) you're not at the beginning again. I would say that this is not intentional but an inconsistency in what "overview" means that should be resolved some way or another. For me it makes sense that drawers begin folded in an overview and the docstring of org-overview seems to suggest that. Moreover, while cycling the rest of the "more expanded" visibility states fold drawers. And sometimes properties represent a disproportionate part of the document when compared to folded top-level headlines. For example, I'm thinking of brief org-roam notes showing an awful UUID at the top which is IMO not relevant to an overview. Best regards, Carlos --- [1] https://orgmode.org/manual/Initial-visibility.html
[BUG] "args out of range" on link heading completion [9.5 (9.5-gd361c7 @ /Users/carlos/.emacs.d/straight/build/org/)]
Hi,
when I try to autocomplete a heading inside a link I get:
completion--some: Args out of range: #("*hea" 0 1 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 1 2 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 2 3 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 3 4 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...)), 0, 5
To reproduce:
1. Create org file with a heading:
* heading
2. Start typing a link to that heading and press to autocomplete:
[[*head]]
Best regards,
Carlos
---
Emacs : GNU Emacs 28.0.60 (build 3, x86_64-apple-darwin20.6.0, NS
appkit-2022.60 Version 11.6 (Build 20G165))
of 2021-10-18
Package: Org mode version 9.5 (9.5-gd361c7 @
/Users/carlos/.emacs.d/straight/build/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-directory "~/Documents"
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-babel-after-execute-hook '(org-redisplay-inline-images)
org-agenda-files '("/tmp/test.org")
org-export-before-parsing-hook '(org-attach-expand-links)
org-default-notes-file "~/Documents/inbox.org"
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-font-lock-set-keywords-hook '(doom-themes-enable-org-fontification)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-confirm-shell-link-function 'yes-or-no-p
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer doom-modeline-set-org-src-modeline)
org-confirm-elisp-link-function 'yes-or-no-p
org-todo-keywords '((sequence "TODO" "NEXT" "|" "DONE"))
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-preview-latex-default-process 'dvisvgm
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-pre-tangle-hook '(save-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link) ("id" :follow org-id-open)
("eww" :follow org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("doi" :follow
org-link-doi-open :export org-link-doi-export) ("file+sys")
("file+emacs") ("shell" :follow org-link--open-shell)
("news" :follow #[514 "\301\300\302Q\"\207" ["news"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("mailto" :follow #[514 "\301\300\302Q\"\207" ["mailto"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("https" :follow #[514 "\301\300\302Q\"\207" ["https"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("http" :follow #[514 "\301\300\302Q\"\207" ["http"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("ftp" :follow #[514 "\301\300\302Q\"\207" ["ftp"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
Re: Keyword completion list: uppercase or lowercase?
Ihor Radchenko writes: Hi Igor, > I just tried with clean Emacs: > > #+beg #+begin_ -> list of completions, all in lower case > #+BEG #+BEGIN_ -> list of completions, all in upper case > > Seems to be all right. You're right, I was under the impression that completion-ignore-case = t was the default, but it's just an ancient customization of mine that I got used to and had forgotten about. My apologies for the noise. Best regards, Carlos
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi Igor, > The conversation was about keywords and similar constructs (i.e. > ^#+keyword). You are looking at property drawer and properties inside. > There is no preference here, though internally properties in property > drawer are all converted to upper case. Ok, thank you very much for the clarification. >> But then c-a-p is very lenient since it lists lower and upper case block >> variants even when I typed a lower case prefix, and upper case usually >> will go first in the list, hence promoting a seemingly bad practice. > > Could you clarify what is "c-a-p"? Yes, I just meant completion-at-point. At least some org functions, which I believe are implemented using pcomplete and then exposed through the completion-at-point interface, provide completions in both lower and uppercase variants and except when completion-ignore-case is nil (not the default) uppercase candidates will be sorted first in the list. It's often quite inconvenient to scroll down a completion menu to pick the lowercase completion for a short prefix, which either promotes using the uppercase variant at hand or offsets the benefits of autocompletion. Moreover, popular external collections of snippets have already adopted the lowercase convention of org-mode, hence introducing inconsistency in the document when one mixes both sources of completion (lowercase snippets and org-mode uppercase completions). So perhaps uppercase completions should be provided only when the user explicitly typed an uppercase prefix. What do you think? Best regards, Carlos
Re: [BUG] "args out of range" on link heading completion [9.5 (9.5-gd361c7 @ /Users/carlos/.emacs.d/straight/build/org/)]
> > !Changing the last line to (substring pcomplete-stub 1 -2) fixes it in my > example. I don't know if one is supposed to do [[*prefix]] or > [[*prefix as is implied by the code, but better to support both, > specially considering electric pairs, don't you think? > Indeed, the right limit should be the position of the point.
Re: [BUG] "args out of range" on link heading completion [9.5 (9.5-gd361c7 @ /Users/carlos/.emacs.d/straight/build/org/)]
Hi Igor, I believe the problem is in: (defun pcomplete/org-mode/searchhead () ... ;; When completing a bracketed link, i.e., "[[*", argument ;; starts at the star, so remove this character. (substring pcomplete-stub 1 <-- trailing ]] not removed! Changing the last line to (substring pcomplete-stub 1 -2) fixes it in my example. I don't know if one is supposed to do [[*prefix]] or [[*prefix as is implied by the code, but better to support both, specially considering electric pairs, don't you think? Best regards, Carlos
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi, in https://list.orgmode.org/87tuuw3n15@nicolasgoaziou.fr/#t it's stated: > Org is standardized on lower case. Uppercase is used in the manual as > a poor man's bold, and supported for historical reasons. But C-c C-x p still inserts stuff like: :PROPERTIES: :ARCHIVE: ... :END: Maybe it should be updated or maybe I don't fully understand the convention, perhaps it's just for blocks? But then c-a-p is very lenient since it lists lower and upper case block variants even when I typed a lower case prefix, and upper case usually will go first in the list, hence promoting a seemingly bad practice. Can you clarify? Thank you in advance, Carlos
Re: [BUG] "args out of range" on link heading completion [9.5 (9.5-gd361c7 @ /Users/carlos/.emacs.d/straight/build/org/)]
Hi Greg,
> fwiw, using
>
> : emacs -Q -L ~/.emacs.d/straight/build/org foo.org
It's exactly the same. To be more precise, this is what I did:
1. open -na emacs --args -Q -L ~/.emacs.d/straight/build/org foo.org
2. C-x C-f /tmp/test.org (a new file)
3. Type "* heading" in the first line
4. Type "[[]]" in the second line
5. Go into the brackets an type "*head"
6. Press or C-M-i.
This is the message I get:
completion--some: Args out of range: #("*hea" 0 1 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 1 2 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 2 3 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 3 4 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...)),
Interestingly enough the message includes the string "*hea" as well as
the string "*head".
If you can't still reproduce it let me know and I will debug the issue.
> ps -- the org-version was
> : Org mode version 9.5 (9.5-gdc154f @
> /home/minshall/.emacs.d/straight/build/org/)
What are these? Seemingly not git revisions. Can I checkout that version
somehow? If not, pass me your git revision and I will rerun my recipe
there.
Best regards,
Carlos
Clarify bug report requirements wrt mailing list subscription
Hi all, I find the instructions about bug reporting in [1] lacking a heads-up that subscription to the mailing list is a (soft?) prerequisite. It's true that it links to [2] which states: You can subscribe to the list from this web page. If you are not a member of the mailing list, your mail will be passed to the list after a moderator has approved but also it's true [3] states: The Org mailing list is a members only mailing list to prevent spam. Membership is freely available and only requires that you subscribe to the list and confirm your email address. Moreover, that it seemingly is a soft requirement implies that I'm not getting any feedback for some time about the status of my report. All this ended up in that, after some years, I reported a bug again but from an alternative address following the instructions in [1], but without reading [2], and since hours later I wasn't seeing my report in the list I checked [3], subscribe to the list and resent the report, which probably will arrive twice now, except that a moderator catches the dup. I reckon that I could have been more careful regarding [2] but still the instructions in [1] are somewhat misleading and I would say that [3] just contradicts [2], whatever is true. What do you think of: - Adding some brief mention to subscription in [1]. - Resolve the apparent contradiction about subscription being a prerequisite or not between [2] and [3]. Best regards, Carlos --- [1] https://orgmode.org/worg/org-issues.html [2] https://orgmode.org/org.html#Feedback [3] https://orgmode.org/worg/org-mailing-list.html
[BUG] "args out of range" on link heading completion [9.5 (9.5-gd361c7 @ /Users/carlos/.emacs.d/straight/build/org/)]
Hi,
when I try to autocomplete a heading inside a link I get:
completion--some: Args out of range: #("*hea" 0 1 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 1 2 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 2 3 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...) 3 4 (fontified t
help-echo "LINK: *head" htmlize-link (:uri "*head") rear-nonsticky
(mouse-face highlight keymap invisible intangible help-echo
org-linked-text htmlize-link) face org-link ...)), 0, 5
To reproduce:
1. Create org file with a heading:
* heading
2. Start typing a link to that heading and press to autocomplete:
[[*head]]
Best regards,
Carlos
---
Emacs : GNU Emacs 28.0.60 (build 3, x86_64-apple-darwin20.6.0, NS
appkit-2022.60 Version 11.6 (Build 20G165))
of 2021-10-18
Package: Org mode version 9.5 (9.5-gd361c7 @
/Users/carlos/.emacs.d/straight/build/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-directory "~/Documents"
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-after-execute-hook '(org-redisplay-inline-images)
org-agenda-files '("/tmp/test.org")
org-export-before-parsing-hook '(org-attach-expand-links)
org-default-notes-file "~/Documents/inbox.org"
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-font-lock-set-keywords-hook '(doom-themes-enable-org-fontification)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-confirm-shell-link-function 'yes-or-no-p
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer doom-modeline-set-org-src-modeline)
org-confirm-elisp-link-function 'yes-or-no-p
org-todo-keywords '((sequence "TODO" "NEXT" "|" "DONE"))
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-preview-latex-default-process 'dvisvgm
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-pre-tangle-hook '(save-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("attachment" :follow org-attach-follow
:complete org-attach-complete-link) ("id" :follow org-id-open)
("eww" :follow org-eww-open :store
org-eww-store-link) ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("doi"
:follow org-link-doi-open :export org-link-doi-export) ("file+sys")
("file+emacs") ("shell" :follow org-link--open-shell)
("news" :follow #[514 "\301\300\302Q\"\207"
["news" browse-url ":"] 6 "\n\n(fn URL ARG)"])
("mailto" :follow #[514 "\301\300\302Q\"\207"
["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"])
("https" :follow #[514 "\301\300\302Q\"\207"
["https" browse-url ":"] 6 "\n\n(fn URL ARG)"])
("http" :follow #[514 "\301\300\302Q\"\207"
["http" browse-url ":"] 6 "\n\n(fn URL ARG)"])
("ftp" :follow #[514 "\301\300\302Q\"\207"
["ftp" browse-url ":"] 6 "\n\n(fn URL ARG)"])
("help" :follow
Re: [O] Feature Request: allow export yes/no for blocks that are valid babel inputs
Hi Berry, sorry for the late reply, I was pretty busy lately. I didn't know about inline tasks, thanks for let me know. The idea is cool but I think that regarding the use case I'm suggesting, they are a more or less hackish workaround and not a proper solution. I'm saying this because: 1) They are kinda optional, they are not enabled by default. But this is not too important. 2) They are oriented towards tasks. Clearly, my use case is not about tasks but about more granularity in exporting. It's true that, as a side effect, you can wrap some additional syntactical constructions into selectively exportable chunks by considering them as tasks. Now, the concept of inline task could be generalized and, if the generalization is "general enough", maybe even enabled by default. But this is overkilling for my specific interest, specially if I had to implements something like that by myself. Instead, I could implement a more modest proposal (no Swift reference intended). Regards -- Carlos On Sun, Mar 24, 2019 at 1:31 PM Berry, Charles wrote: > AFAICS, the functionality you seek already exists, although it is not > heavily advertised. > > `C-c C-x t' will insert an inline task. Within such a `task' you can put > text, tables, src blocks and other objects. > > Setting option `inline:nil' will prevent export, but leave the content > visible to src blocks etc. > > Alternatively, you can tag inlinetasks as with headlines to control their > export. > > Browse the commentary in org-inlinetask.el for more details. > > HTH, > > Chuck > > > > On Mar 23, 2019, at 2:20 PM, Carlos Pita > wrote: > > > > Hi all, > > > > when using lists, tables and example blocks as inputs to babel src > > blocks sometimes the inputs are just... inputs. There is some > > inconsistency in the fact that src blocks can be selectively exported > > but not their inputs. Commenting these inputs out makes them invisible > > to the block referencing them (apparently this method worked a time > > ago but it's not working now). OTOH using the noexport tag introduces > > spurious sections that interrupt the flow of the document and might be > > hard to close afterwards (similar to the boilerplate introduced by > > beamer blocks). > > > > What do you think of adding an :export yes/no parameter to these > > blocks? Or to blocks in general. > > > > Best regards > > -- > > Carlos > > > > > > >
[O] Setting html special blocks id=name is problematic
Hi all, the html exporter produces a div with id = name when the #+name property is set for a special block. Since names are search targets they could be used in links of the form [[name]]. Now this link will fail in the browser because it will search for the internally generated id returned by org-export-get-reference and there is no html element with this id in the exported output. The problem I see here is that org searches for the link target using the name property but produces html that searches for this same target using a non-exported id instead. Given that there already is an #+attr_html keyword to set the id property if so desired, wouldn't it be a better idea to set the id property to the internally generated identifier so links are able to resolve both in emacs and in the browser the same way? I could write a simple patch but I would like to know your opinion on this first. Best regards -- Carlos
[O] Problems with yasnippet enabled in hidden font locking buffer
Hi all, I've been having problems with latex font locking the first time the internal font locking buffer is created (this with native latex fontification). It was hard to debug but at a point it became obvious that the culprit was yas minor mode, which I had globally enabled. I don't think this global minor mode should be enabled in hidden buffers and I requested this to be changed [1]. I'll keep you informed of any advance regarding this matter but, anyway, maybe org mode could also add a hook to yas-dont-activate-functions in order to disable activation when the buffer name matches an org mode specific pattern/prefix. Short of every concerned user taking action here, at least one of the interacting parties (org and snippet) would have to compromise: (i) yasnippet by disabling its global minor mode for all hidden buffers and/or those matching an org specific pattern and/or (ii) org by including a yasnippet specific filter. IMO the best solution is what I described above: yasnippet disabling its global minor mode for *all* hidden buffers. Best regards -- Carlos [1] https://github.com/joaotavora/yasnippet/issues/985
[O] Feature Request: allow export yes/no for blocks that are valid babel inputs
Hi all, when using lists, tables and example blocks as inputs to babel src blocks sometimes the inputs are just... inputs. There is some inconsistency in the fact that src blocks can be selectively exported but not their inputs. Commenting these inputs out makes them invisible to the block referencing them (apparently this method worked a time ago but it's not working now). OTOH using the noexport tag introduces spurious sections that interrupt the flow of the document and might be hard to close afterwards (similar to the boilerplate introduced by beamer blocks). What do you think of adding an :export yes/no parameter to these blocks? Or to blocks in general. Best regards -- Carlos
Re: [O] Feature Request: allow export yes/no for blocks that are valid babel inputs
Or maybe the other way around: #+noexport: mylist mytable ... Then there is the question of what to do with src blocks, which have their own, more complex, export control mechanism. What if both #+noexport and :exports were set with non consistent values? Should one forbid that possibility? Or simply make :exports win?
Re: [O] Feature Request: allow export yes/no for blocks that are valid babel inputs
Or maybe a keyword, similar to #+name. For instance: #+export: no #+name: mylist - item 1 - item 2
Re: [O] Use CHTML mathjax backend by default
Also, they said there: > I think you'll find that CommonHTML is faster at rendering the math So: 1. Recommended for newer mathjax versions. 2. Fixed my problem with web fonts. 3. Faster. It seems like a Pareto improvement to me.
Re: [O] Use CHTML mathjax backend by default
TL;DR about the specific problem I was having with HTML-CSS: > both HTML-CSS and CommonHTML use web fonts. But CommonHTML doesn't try to > detect their presence, while HTML-CSS does, and it is that detection that is > probably going wrong for some reason (I did say it was fragile). HTML-CSS > needed to wait for the fonts to arrive because (in the old days before > browsers were more consistent with each other), MathJax had to measure the > actual displayed subexpressions in order to determine their size, and that > meant the font had to be the right one. CommonHTML doesn't have to do that > because modern browsers are more consistent about their layout (thanks to > better standards and better adherence to them).
[O] Use CHTML mathjax backend by default
Hi all, I was having some problems with the mathjax HTML-CSS backend and I found out that the CHTML backend is currently the preferred one. See details at https://github.com/mathjax/MathJax/issues/2132 and http://docs.mathjax.org/en/latest/output.html. Changing the backend to CHTML fixed my issue. Wouldn't be time to update the default mathjax version to 2.7.1 (the current one) and setting the backend to CHTML? Best regards -- Carlos
Re: [O] Missing documentation for #+macro: xxx (eval ...)
> just what the subject says. It seems an important feature to me but > I'm unable to find any reference to it in > https://orgmode.org/manual/Macro-replacement.html. > Strangely I do find it here: https://orgmode.org/manual/Macro-Replacement.html#Macro-Replacement The only difference being that "replacement" is capitalized. I had been having this feeling of accessing to different versions of the documentation for some time now. Is there any double indexing of the docs? I reached both pages from Google. >
[O] #+RESULTS still upper case after executing babel block
Hi all, despite the new lower case convention the #+results directive auto generated after evaluation of babel blocks is still upper case. Best regards -- Carlos
[O] Missing documentation for #+macro: xxx (eval ...)
Hi all, just what the subject says. It seems an important feature to me but I'm unable to find any reference to it in https://orgmode.org/manual/Macro-replacement.html. Best regards -- Carlos
[O] [PATCH] Faulty logic in org-cmp-tag/alpha
Hi all, there is a problem in this kind of logic: (cond ((not ta) +1) ((not tb) -1) ((string-lessp ta tb) -1) ((string-lessp tb ta) +1 in that when both ta and tb are nil then they are arbitrarily sorted. Since the agenda sorting strategy is lexicographic this logic virtually invalidates any strategy that puts tag or alpha first, v.g. '(tag-up priority-down). I've attached a patch returning nil when both ta and tb are nil so as to fallback to the next sorting criterion without favoring lhs nor rhs. AFAICS this only affects tag and alpha comparators. Best regards -- Carlos From 35396182b465bd67c72d776709eee5e0041d96c7 Mon Sep 17 00:00:00 2001 From: memeplex Date: Sat, 9 Mar 2019 17:49:52 -0300 Subject: [PATCH] Compare nil-nil as nil so as not to change lexicographic order * lisp/org-agenda.el (org-cmp-alpha/tag): don't favor a particular ordering when both lhs and rhs are nil. --- lisp/org-agenda.el | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 13bbae966..c9bea4465 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7003,7 +7003,8 @@ The optional argument TYPE tells the agenda type." "\\([ \t]*\\[[a-zA-Z0-9]\\]\\)? *") tb) (setq tb (substring tb (match-end 0 (setq tb (downcase tb))) -(cond ((not ta) +1) +(cond ((not (or ta tb)) nil) + ((not ta) +1) ((not tb) -1) ((string-lessp ta tb) -1) ((string-lessp tb ta) +1 @@ -7012,7 +7013,8 @@ The optional argument TYPE tells the agenda type." "Compare the string values of the first tags of A and B." (let ((ta (car (last (get-text-property 1 'tags a (tb (car (last (get-text-property 1 'tags b) -(cond ((not ta) +1) +(cond ((not (or ta tb)) nil) + ((not ta) +1) ((not tb) -1) ((string-lessp ta tb) -1) ((string-lessp tb ta) +1 -- 2.21.0
[O] [PATCH] Avoid extra space when removing state
Hi all, here is a patch removing an extra space that is left when one selects an empty state from the completing read interface. I simply replaced a check for non-null with a check for org-string-nw-p in org-todo. Best regards -- Carlos From 9f137a50e1f18e067b4b9ca8836993b212d93093 Mon Sep 17 00:00:00 2001 From: memeplex Date: Fri, 8 Mar 2019 23:12:16 -0300 Subject: [PATCH] Avoid extra space when removing state * lisp/org.el (org-todo): check if org-string-nw-p instead of non nil. --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 668482932..655c5733b 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12082,7 +12082,7 @@ When called through ELisp, arg is also interpreted in the following way: (run-hook-with-args-until-success 'org-todo-get-default-hook org-state org-last-state) org-state)) - (next (if org-state (concat " " org-state " ") " ")) + (next (if (org-string-nw-p org-state) (concat " " org-state " ") " ")) (change-plist (list :type 'todo-state-change :from this :to org-state :position startpos)) dolog now-done-p) -- 2.21.0
Re: [O] Merge global/file and dynamic tags
I now notice that this is possible in case you have defined shortcut keys for the default tags and, thus, the fast selection menu opens. But it doesn't seem to be possible otherwise. Is this right?
[O] Merge global/file and dynamic tags
Hi all, is it possible to get a tag completion list that includes both: 1. Tags specified with org-tag-alist or #+tags 2. Tags dynamically parsed from the current buffer ? It seems that 1 always overrides 2, but there are legitimate cases to prefer the union of 1 and 2. Namely, you might want 1 to specify default tags, a core that must always be available, and 2 to be the rest of tags that come and go. Best regards -- Carlos
Re: [O] Lowercase keywords in 9.2?
Great, thanks!
Re: [O] Lowercase keywords in 9.2?
Today I noticed the export templates inserted by org are still uppercase: #+LATEX_CLASS: article #+LATEX_CLASS_OPTIONS: #+LATEX_HEADER: #+LATEX_HEADER_EXTRA: #+DESCRIPTION: #+KEYWORDS: #+SUBTITLE: #+LATEX_COMPILER: pdflatex #+DATE: \today Is this intentional, is the lowercase convention intended for blocks only? Best regards -- Carlos
Re: [O] [patch] Don't show trailing colon in agenda custom command desc
> Applied, with some refactoring. Please double check I didn't fumble it. I looked at the code and tested it a bit and seems to be ok. Thanks!
[O] [patch] Don't show trailing colon in agenda custom command desc
Hi all, here is a simple patch to avoid showing ugly trailing colons in custom agenda commands when no matcher was specified (for example, in the case of alltodo). Best regards -- Carlos From 4125d3ff9e4f26c3346b847288cad3e69a38da23 Mon Sep 17 00:00:00 2001 From: memeplex Date: Fri, 22 Feb 2019 00:32:58 -0300 Subject: [PATCH] org-agenda: don't show trailing color if no matcher * lisp/org-agenda.el (org-agenda-get-restriction-and-command): when no matcher was specified there is no point in showing a trailing colon (and space). --- lisp/org-agenda.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index ff98cd65d..ab50d4274 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3027,7 +3027,8 @@ s Search for keywords M Like m, but only TODO entries (symbol-name type) "Lambda expression")) (t "???" - (if org-agenda-menu-show-matcher + (if (and org-agenda-menu-show-matcher + match (not (string-empty-p match))) (setq line (concat line ": " (cond -- 2.20.1
Re: [O] Agenda todo states autocompletion: suggestion for improvement
Here is a patch inverting (1) and (2) above. From 9c97eebb6c26332415fb03c65e872d304576fe07 Mon Sep 17 00:00:00 2001 From: memeplex Date: Thu, 21 Feb 2019 16:09:58 -0300 Subject: [PATCH] org-agenda: improve todo states completion * lisp/org-agenda.el (org-todo-list): prepare agenda buffers before prompting for state. --- lisp/org-agenda.el | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 2765718ac..ff98cd65d 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4673,18 +4673,8 @@ for a keyword. A numeric prefix directly selects the Nth keyword in (when (and (stringp arg) (not (string-match "\\S-" arg))) (setq arg nil)) (let* ((today (org-today)) (date (calendar-gregorian-from-absolute today)) - (kwds org-todo-keywords-for-agenda) (completion-ignore-case t) - (org-select-this-todo-keyword - (if (stringp arg) arg - (and arg (integerp arg) (> arg 0) - (nth (1- arg) kwds - rtn rtnall files file pos) -(when (equal arg '(4)) - (setq org-select-this-todo-keyword - (completing-read "Keyword (or KWD1|K2D2|...): " - (mapcar #'list kwds) nil nil))) -(and (equal 0 arg) (setq org-select-this-todo-keyword nil)) + kwds org-select-this-todo-keyword rtn rtnall files file pos) (catch 'exit (when org-agenda-sticky (setq org-agenda-buffer-name @@ -4693,6 +4683,15 @@ for a keyword. A numeric prefix directly selects the Nth keyword in org-select-this-todo-keyword) (format "*Org Agenda(%s)*" (or org-keys "t") (org-agenda-prepare "TODO") + (setq kwds org-todo-keywords-for-agenda +org-select-this-todo-keyword (if (stringp arg) arg + (and arg (integerp arg) (> arg 0) +(nth (1- arg) kwds + (when (equal arg '(4)) +(setq org-select-this-todo-keyword + (completing-read "Keyword (or KWD1|K2D2|...): " + (mapcar #'list kwds) nil nil))) + (and (equal 0 arg) (setq org-select-this-todo-keyword nil)) (org-compile-prefix-format 'todo) (org-set-sorting-strategy 'todo) (setq org-agenda-redo-command -- 2.20.1
Re: [O] Agenda todo states autocompletion: suggestion for improvement
It doesn't seem to be any relevant computational penalty: (when (equal arg '(4)) (setq org-select-this-todo-keyword (completing-read "Keyword (or KWD1|K2D2|...): " (mapcar #'list kwds) nil nil))) < (1) (and (equal 0 arg) (setq org-select-this-todo-keyword nil)) (catch 'exit (when org-agenda-sticky (setq org-agenda-buffer-name (if (stringp org-select-this-todo-keyword) (format "*Org Agenda(%s:%s)*" (or org-keys "t") org-select-this-todo-keyword) (format "*Org Agenda(%s)*" (or org-keys "t") (org-agenda-prepare "TODO")< (2) It's true that the user might abort the prompt (1) without executing (2) but that's an exceptional use case.
[O] Agenda todo states autocompletion: suggestion for improvement
Hi all, M-x org-agenda T prompts for a todo keyword. But it builds the completion list while preparing the agenda buffers and this is done *after* prompting. So the first time no completion is presented, the second time completions from previous invocation of org-agenda-prepare-buffers are presented, etc. This has some drawbacks: 1. The first time one has to explicitly type the state. 2. I'm not sure about this but: aren't completions potentially outdated, since the last time the list was built was for a previous agenda? To prepare the buffers before showing the prompt will fix both issues but maybe at a high computational cost, I've not investigated the code in any depth yet. Otherwise, at least the default list of state keywords could be shown when org-todo-keywords-for-agenda is nil, couldn't it? Best regards -- Carlos
[O] [patch] Improve fast todo selection alignment
This avoids lines with just a closing "}", which look rather ugly.
Quite similar to my previous patch for fast tag selection.
Regards
--
Carlos
From 239e0d036da94b2a950db3ad1f7e82c5ca6d8daa Mon Sep 17 00:00:00 2001
From: memeplex
Date: Thu, 21 Feb 2019 01:09:29 -0300
Subject: [PATCH] Fix fast todo selection menu alignment
* lisp/org.el (org-fast-todo-selection): Avoid lines with just a
closing delimiter.
---
lisp/org.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index ef6e40ca9..a34211b65 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12573,7 +12573,8 @@ Returns the new TODO keyword, or nil if no state change should occur."
(when (and (= cnt 0) (not ingroup)) (insert " "))
(insert "[" c "] " tg (make-string
(- fwidth 4 (length tg)) ?\ ))
- (when (= (setq cnt (1+ cnt)) ncol)
+ (when (and (= (setq cnt (1+ cnt)) ncol)
+ (not (equal (car tbl) '(:endgroup
(insert "\n")
(when ingroup (insert " "))
(setq cnt 0)
--
2.20.1
[O] Rationale for org-directory (any?)
Hi all, I often wonder if the way org-directory is currently used has any sense or is just a historical artifact. I mean, when I list my refile targets and agenda files I have to specify full paths, which isn't very convenient. But if instead of a list I provide a file listing the paths, then the items in this list are taken to be relative to org-directory. Also, capture targets are relative to this variable. The result is a mix of relative and absolute paths in my init.el that makes me turn everything absolute in order to keep it sane. Why does it work that way? Is it because some paths are resolved relative to the current directory (unless they are configured as absolute paths) while others don't? Thanks! -- Carlos
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
> Please let me know if anything went wrong. I think your refactor improves the original code a lot and makes clear that toggling is just a special case. I've been testing the changes with a pretty complex beamer document and found no fault. Thanks!
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Nicolas, here is a patch implementing alternative B above with ORG-NEWS entry and everything. I have been playing with it and find the bindings quite handy. Code is indeed a bit simpler. If you like it, feel free to amend it before merging. Best regards -- Carlos From 799ecd332e81a31b06f69ba5546db74eb9583ba7 Mon Sep 17 00:00:00 2001 From: memeplex Date: Wed, 13 Feb 2019 16:26:46 -0300 Subject: [PATCH] org: Make latex preview toggle more useful and predictable * lisp/org.el (org-toggle-latex-fragment): - Avoid toggling behavior for subtree/buffer scope - Make common use cases simpler to type * Detailed discussion: http://lists.gnu.org/archive/html/emacs-orgmode/2019-02/msg00138.html --- lisp/org.el | 71 ++--- 1 file changed, 35 insertions(+), 36 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 003058434..afd3f8709 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18057,60 +18057,59 @@ overlays were removed, nil otherwise." overlays)) (defun org-toggle-latex-fragment ( arg) - "Preview the LaTeX fragment at point, or all locally or globally. - -If the cursor is on a LaTeX fragment, create the image and overlay -it over the source code, if there is none. Remove it otherwise. -If there is no fragment at point, display all fragments in the -current section. - -With prefix ARG, preview or clear image for all fragments in the -current subtree or in the whole buffer when used before the first -headline. With a prefix ARG `\\[universal-argument] \ -\\[universal-argument]' preview or clear images -for all fragments in the buffer." + "Toggle preview of the LaTeX fragment at point. + +If the cursor is on a LaTeX fragment, create the image and +overlay it over the source code, if there is none. Remove it +otherwise. + +If there is no fragment at point, display image for all fragments +in the current section. + +With prefix ARG, clear image for all fragments in the current +subtree. + +With double prefix ARG, display image for all fragments in the +buffer. + +With triple prefix ARG, clear image for all fragments in the +buffer." (interactive "P") (when (display-graphic-p) (catch 'exit (save-excursion (let (beg end msg) (cond - ((or (equal arg '(16)) - (and (equal arg '(4)) - (org-with-limited-levels (org-before-first-heading-p - (if (org-remove-latex-fragment-image-overlays) - (progn (message "LaTeX fragments images removed from buffer") - (throw 'exit nil)) - (setq msg "Creating images for buffer..."))) - ((equal arg '(4)) + ((member arg '((16) (64))) ; Double or triple prefix + (when (org-remove-latex-fragment-image-overlays) + (message "LaTeX fragments images removed from buffer")) + (when (equal arg '(64)) (throw 'exit nil)) + (setq msg "Creating images for buffer...")) + ((member arg '((4))) ; Single prefix (org-with-limited-levels (org-back-to-heading t)) (setq beg (point)) (setq end (progn (org-end-of-subtree t) (point))) - (if (org-remove-latex-fragment-image-overlays beg end) - (progn - (message "LaTeX fragment images removed from subtree") - (throw 'exit nil)) - (setq msg "Creating images for subtree..."))) + (when (org-remove-latex-fragment-image-overlays beg end) + (message "LaTeX fragment images removed from subtree")) + (throw 'exit nil)) ((let ((datum (org-element-context))) (when (memq (org-element-type datum) '(latex-environment latex-fragment)) (setq beg (org-element-property :begin datum)) (setq end (org-element-property :end datum)) - (if (org-remove-latex-fragment-image-overlays beg end) - (progn (message "LaTeX fragment image removed") - (throw 'exit nil)) - (setq msg "Creating image...") + (when (org-remove-latex-fragment-image-overlays beg end) + (message "LaTeX fragment image removed") + (throw 'exit nil)) + (setq msg "Creating image..." (t (org-with-limited-levels (setq beg (if (org-at-heading-p) (line-beginning-position) (outline-previous-heading) - (point))) - (setq end (progn (outline-next-heading) (point))) - (if (org-remove-latex-fragment-image-overlays beg end) - (progn - (message "LaTeX fragment images removed from section") - (throw 'exit nil)) - (setq msg "Creating images for section...") + (point)) + end (progn (outline-next-heading) (point))) + (when (org-remove-latex-fragment-image-overlays beg end) + (message "LaTeX fragment images removed from section")) + (setq msg "Creating images for section..." (let ((file (buffer-file-name (buffer-base-buffer (org-format-latex (concat org-preview-latex-image-directory "org-ltximg") -- 2.20.1
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Ok, let's make this more concrete so I can start working on it then. Alternative A: Provide three functions: org-toggle-latex-fragment: bound to C-c C-x C-l has an optional argument arg delegates to org-preview-latex-section if necessary (outside of fragment or C-u) org-preview-latex-section: unbound has an optional argument remove org-preview-latex-all: unbound has an optional argument remove Alternative B: Do some cosmetic changes to org-toggle-latex-fragment and provide the following bindings: C-c C-x C-l: toggle fragment or preview section C-u C-c C-x C-l: unpreview section C-u C-u C-c C-x C-l: preview document C-u C-u C-u C-c C-x C-l: unpreview document I favor alternative B since it's a simpler change and the only awful binding is the (by far) less useful one.
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
> C-c C-x C-l: as you defined it > C-u C-c C-x C-l: preview document scope. > C-- (or C-0) C-c C-x C-l: as you defined C-u C-c C-x C-l. > C-- (or C-0) C-u C-c C-x C-l: unpreview document scope. Btw, I don't think that "preview the entire document" is such a rare use case. Consider that you've taken some quick notes using embedded latex (I need to do that often because my notes are almost exclusively about mathematical stuff and unicode is far from enough). Now you open the notes and you can i. export to pdf and preview using docview/pdf-tools/external pdf reader or, alternatively, ii. preview all fragments. I agree it's more usual to go to some section of interest and then preview it, but nevertheless full preview has its place. This proposal makes more cumbersome to unpreview the entire document, which I do think is barely necessary. But the other use cases are just one modifier away from the base use case (toggle fragment). The downside is that C-0 is assigned to an arguably less frequent use case than C-u, because of the mnemonic argument. As I said, I dislike swapping them, but if you prefer it that way I'm fine with it; in that case what will result is your proposal plus two C-0 or something variations for full document.
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
> WDYT? I like it. Indeed, I was tempted to suggest removing document scope but, as an end user, I moderate my proposals to be more or less conservative. There are some complications though. If we remove the document scope bindings we have to refactor the current function quite a bit, because the interface it provides is purely interactive relying on numerical arguments. Maybe a split would be in order. I don't like this aspect that much. What do you think of this variation of your last proposal: C-c C-x C-l: as you defined it C-u C-c C-x C-l: preview document scope. C-- (or C-0) C-c C-x C-l: as you defined C-u C-c C-x C-l. C-- (or C-0) C-u C-c C-x C-l: unpreview document scope. Here I'm keeping both of your bindings although C-u is changed to C-- (or C-0, I think both are good mnemonics - = remove, 0 = leave zero). Then C-u is free to be used to signal document scope. I dislike the idea of swapping the roles of this modifiers because of the mnemonic advantage, even if "clearing previews" is to be used more often than "document scope". If you prefer to keep just your two bindings instead, we need to discuss how to offer the "document scope" interface to the end user. Best regards -- Carlos
Re: [O] Bug: latex blocks preview inline [9.2.1 (release_9.2.1-217-g232160 )]
Also, make sure imagemagick is installed. Btw, you might find this useful for previewing babel-generated images: (defun my-org-babel-redisplay-images () (when org-inline-image-overlays (org-redisplay-inline-images))) (add-hook 'org-babel-after-execute-hook #'my-org-babel-redisplay-images) This reloads the previewed images each time they potentially change.
Re: [O] Bug: latex blocks preview inline [9.2.1 (release_9.2.1-217-g232160 )]
Hi,
> #+HEADER: :file latex.svg
> #+HEADER: :results drawer
> #+BEGIN_SRC latex
I think you're missing some headers to get it working. For example, I
use the following defaults to preview/export images generated with
tikz to html/markdown documents:
org-babel-default-header-args:latex '((:results . "file raw")
(:exports . "results")
(:cache . "yes")
(:headers . ("\\usepackage{tikz}"))
(:imagemagick . "yes")
(:fit . "yes")))
Try adding them to you src block or to you config. :cache and :fit
aren't necessary for your goal but desirable anyway. The others I
think you will need them.
Of course, if you're embedding your tikz environment in a document
exported to latex, simply embed the fragment (that is, without the src
block) and preview it with C-c C-x C-l.
> When using the org-plus-contrib package from the org archive
> (9.2.1-8-g1b1797-elpaplus),
I don't know what is this, but could it be shipped with different
babel defaults?
Best regards
--
Carlos
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
> `C-c C-x C-S-l` is too ugly, even for me. It is a convention we don't > use in Org. Mmm ok :). I proposed it because it is easy to remember if you think you're modifying a base action by S and also because it's easier to keep C pressed (versus simply S-l or M-l). So lets play with minus as a modifier, I like that idea. (A) Here is a variation of my proposal: [C- -] [C-u] [C-u] C-c C-x C-l The modifier [C- -] means force preview. The modifier [C-u] means section scope. The modifier [C-u][C-u] means document scope. So - means force, C-u means section, C-u C-u means document. One advantage of this approach is backwards compatibility. (B) Here is a variation of your proposal. In it - means clear (I find this a good mnemonic since "minus removes stuff"): - C-c C-x C-l :: Toggle preview on the fragment at point, raise an error outside a fragment - C-u C-c C-x C-l :: *Preview* for current section - C-- C-u C-c C-x C-l :: *Clear preview* from the current section - C-u C-u C-c C-x C-l :: *Preview* the whole document - C-- C-u C-u C-c C-x C-l :: *Clear preview* for the whole document So - means clear, C-u means section, C-u C-u means document. > This doesn't solve the overlapping between `C-c C-x C-l' and `C-u C-x > C-l' either. I know I mentioned this overlapping but that was the result of a confusion of mine: at first I mistakenly thought the C-u modifiers were there to force preview clearing. But I don't think the section-scope overlapping between C-u C-c C-x C-l and C-c C-x C-l when used outside a fragment is a such bad thing. The C-u modifiers can be thought as setting "strict scopes" of operation while the vanilla operation tries to be smart. The problem with this smartness is not the overlapping per se but that the meaning of "toggle" is ill defined when you have a mixed set of un/previewed fragments. Therefore, although I'm ok with the section-scope overlapping, I agree that it could be convenient to ban the toggling behavior altogether except for single fragments, for which it's well defined. But backwards compatibility is a balancing consideration. I'm fine with both (A) and (B) above. (A) is backwards compatible and (B) removes the somewhat surprising toggle behavior when outside a fragment (which motivated this report). Best regards -- Carlos
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
What about leaving everything as it is now and adding C-c C-x C-S-l to mean "force preview", of course with the C-u and C-u C-u variants. This is a bit more orthogonal in the sense that the numerical argument controls scope and the S modifier controls "forcing". Also, it's backwards compatible with established muscle memory. What do you think? I could write a patch.
Re: [O] Bug: Bad alignment of grouped tags in fast selection dialog [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Not a big deal, but here is a slightly better fix that avoids adding some spaces before the closing }. The difference wrt to the previous one is just: - (unless (memq (caar tbl) '(:endgroup :endgrouptag)) (insert "\n")) - (when (or ingroup intaggroup) (insert " ")) + (unless (memq (caar tbl) '(:endgroup :endgrouptag)) + (insert "\n") + (when (or ingroup intaggroup) (insert " "))) That is, the when clause is inside the unless clause. From 49775847f6db729dfb726ac098cc8039fceb9346 Mon Sep 17 00:00:00 2001 From: memeplex Date: Tue, 12 Feb 2019 17:49:40 -0300 Subject: [PATCH] org: Fix fast tag selection menu alignment * lisp/org.el (org-fast-tag-selection): - Avoid lines with just a closing delimiter. - Correctly align grouped and ungrouped tags. --- lisp/org.el | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index e2258749b..003058434 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -14502,13 +14502,14 @@ Returns the new tags string, or nil to not change the current settings." ((member tg inherited) i-face (when (equal (caar tbl) :grouptags) (org-add-props tg nil 'face 'org-tag-group)) - (when (and (zerop cnt) (not ingroup) (not intaggroup)) (insert " ")) + (when (and (zerop cnt) (not ingroup) (not intaggroup)) (insert " ")) (insert "[" c "] " tg (make-string (- fwidth 4 (length tg)) ?\ )) (push (cons tg c) ntable) (when (= (cl-incf cnt) ncol) - (insert "\n") - (when (or ingroup intaggroup) (insert " ")) + (unless (memq (caar tbl) '(:endgroup :endgrouptag)) + (insert "\n") + (when (or ingroup intaggroup) (insert " "))) (setq cnt 0) (setq ntable (nreverse ntable)) (insert "\n") -- 2.20.1
Re: [O] Bug: Bad alignment of grouped tags in fast selection dialog [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
Ok, this was easier than I initially thought. Here is a patch. I've tested it with a number of configurations: a few grouped tags, many grouped tags, grouped tags that fill the last line entirely, grouped and ungrouped tags. Notice that even ungrouped tags are indented by two spaces. This is done because some tags may be grouped while other not. In case no tag is grouped this is adding an extra initial space but I think removing it is not worth the check "is everything ungrouped?". Best regards -- Carlos From 4a79d1355ec35c711bddd06be0d99b0af287c182 Mon Sep 17 00:00:00 2001 From: memeplex Date: Tue, 12 Feb 2019 17:49:40 -0300 Subject: [PATCH] org: Fix fast tag selection menu alignment * lisp/org.el (org-fast-tag-selection): - Avoid lines with just a closing delimiter. - Correctly align grouped and ungrouped tags. --- lisp/org.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index e2258749b..7f04cee18 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -14502,13 +14502,13 @@ Returns the new tags string, or nil to not change the current settings." ((member tg inherited) i-face (when (equal (caar tbl) :grouptags) (org-add-props tg nil 'face 'org-tag-group)) - (when (and (zerop cnt) (not ingroup) (not intaggroup)) (insert " ")) + (when (and (zerop cnt) (not ingroup) (not intaggroup)) (insert " ")) (insert "[" c "] " tg (make-string (- fwidth 4 (length tg)) ?\ )) (push (cons tg c) ntable) (when (= (cl-incf cnt) ncol) - (insert "\n") - (when (or ingroup intaggroup) (insert " ")) + (unless (memq (caar tbl) '(:endgroup :endgrouptag)) (insert "\n")) + (when (or ingroup intaggroup) (insert " ")) (setq cnt 0) (setq ntable (nreverse ntable)) (insert "\n") -- 2.20.1
Re: [O] Lowercase keywords in 9.2?
> What do you mean with the "uppercase legacy"? You mean all the current > documents we already have? Specifically what motivated this post: collections of snippets that have been written with the historical convention in mind. It's easy to convert them but it's not that easy to convert users :). Anyway I was just asking for opinions about what should be done, although I guess the answer is to not procrastinate conversion to the new convention.
[O] Bug: Bad alignment of grouped tags in fast selection dialog [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
For example, with:
#+tags: { @casa(c) @oficina(o) @viaje(v) @gimnasio(g) @xxx(x) }
I get:
{ [c] @casa [o] @oficina[v] @viaje [g] @gimnasio
[x] @xxx}
where [c] and [x] are clearly misaligned.
If I remove the last tag:
#+tags: { @casa(c) @oficina(o) @viaje(v) @gimnasio(g) }
I get:
{ [c] @casa [o] @oficina[v] @viaje [g] @gimnasio
}
where the closing brace should be in the line before.
org-last-tag-selection-key is a bit overwhelming in size but I might try
my luck and see what I can get.
Regards
--
Carlos
---
Emacs : GNU Emacs 26.1.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
of 2019-02-10
Package: Org mode version 9.2.1 (release_9.2.1-60-gb0379f @
/home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)
Re: [O] Lowercase keywords in 9.2?
> At first I didn't like the lowercase tags for the blocks, but I got used to > them after a couple of days. I prefer the lowercase convention hands down. The problem I pointed out is with the uppercase legacy. > Someone suggested adding a defcustom option to org-tempo to let the user > choose between lower and upper case tags. > It seems a simple enough feature for a first contribution. Maybe we could add > it? I have never done it before, but I am willing to try. I wouldn't mind (helping you) doing it as far as there is agreement whether this is a desired option or not. I guess it would be enough to patch the sites affected by https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0 and also the templates definition in org-tempo. Regards -- Carlos
Re: [O] Lowercase keywords in 9.2?
> Here are two previous threads about the subject: > > Last month: > http://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00349.html > A year ago: > http://lists.gnu.org/archive/html/emacs-orgmode/2018-01/msg00425.html Interesting, thanks! Although the issue of mostly uppercase external snippet collections was not raised there. For now I'm disabling yas in org mode and using org-tempo exclusively.
Re: [O] Lowercase keywords in 9.2?
> before, didn't they? Is this implying that now lowercase is preferred? I dug this up from the repo: org-element: Prefer lower case letters for blocks and keywords https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0 So the answer is yes. Also the begin/end pairs are lowercase hardcoded in org-tempo.el. This is a problem for available (ya)snippet databases. I've reported it in https://github.com/AndreaCrotti/yasnippet-snippets/issues/303, requesting an update. But I guess people will prefer uppercase for a time so I'm now sure how should they should cope with the transition. Best regards -- Carlos > > Regards > -- > Carlos
[O] Lowercase keywords in 9.2?
Hi all, I noticed that the default expansions for org-tempo in 9.2 are lowercase. I think they followed the uppercase informal convention before, didn't they? Is this implying that now lowercase is preferred? Regards -- Carlos
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
A last suggestion. Incidentally the toggle returns nil when at least a fragment is unpreviewed and non-nil otherwise (as a side effect of message). This can be documented and made part of the interface, so that something like the following can be put together by the end user: (defun my-org-preview-latex ( arg) (interactive "P") (unless (org-toggle-latex-fragment arg) (org-toggle-latex-fragment arg))) I insist on the importance of the use case "force preview" because it's very useful to quickly jot down a paragraph or part of a paragraph with many simple latex fragments like $x_i$, $f(x)$, etc. and then, afterwards, type C-c C-x C-l to preview the last entered part of the paragraph, instead of painfully entering C-c C-x C-l after any single $x$ or similar. Now, if the toggle prefers removing previews as it's the case, this won't work because, in general, you already have some preview in the same section or paragraph.
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
> I suggest to make C-c C-x C-l a toggle with preference for previewing, > that is: preview everything except when everything is already previewed. Mmmm I think this is not easy since it would imply changing org-remove-latex-fragment-image-overlay return value: (if (org-remove-latex-fragment-image-overlays beg end) (progn (message "LaTeX fragment images removed from section") (throw 'exit nil)) One workaround is calling the toggle twice in order to force full preview (in case the initial state contains at least one preview). Since everything is cached the overhead is negligible or at least tolerable. Another option could be to add an optional 'force argument to the toggle to simplify user bindings to a "force preview" key. What do you think?
Re: [O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
> the current section. Now, there is C-u C-u C-c C-x C-l for that. AFAICS, Sorry I meant just one C-u. C-u C-u is to clear the entire buffer of previews.
[O] Bug: org-toggle-latex-fragment doesn't work as documented [9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)]
According to the docstring: ``` (defun org-toggle-latex-fragment ( arg) "Preview the LaTeX fragment at point, or all locally or globally. If the cursor is on a LaTeX fragment, create the image and overlay it over the source code, if there is none. Remove it otherwise. **If there is no fragment at point, display all fragments in the current section**. ``` Notice the last sentence. Nevertheless C-c C-x C-l acts like a toggle that will remove all previews as far as there is at least one preview active, that is a toggle with a preference to UNdisplay all fragments in the current section. Now, there is C-u C-u C-c C-x C-l for that. AFAICS, the current situation is such that there is no way to get a full preview of an entire section when at least one formula is already previewed, except for unpreviewing and repreviewing everything. This is not only inconvenient but also contradicts the docstring and mostly overlaps the C-u C-u case. I suggest to make C-c C-x C-l a toggle with preference for previewing, that is: preview everything except when everything is already previewed. Regards -- Carlos --- Emacs : GNU Emacs 26.1.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5) of 2019-02-10 Package: Org mode version 9.2.1 (release_9.2.1-60-gb0379f @ /home/carlos/local/stow/emacs/share/emacs/site-lisp/org/)
Re: [O] [Patch] [Feature request] Add option to natively fontify latex snippets and environment
Hi Nicolas, I was thinking that maybe it would be nicer to make this depend on the value of org-src-fontify-natively. What do you think? Regards -- Carlos
Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
Hi Nicolas,
I've improved the commit message to better fit org mode conventions
and also added a note to ORG-NEWS about the new feature. Let me know
if there still is something I should change or feel free to amend it
to your liking.
One question for future patches: is it ok to add a link to the mailing
list thread where the issue was discussed in the commit message?
Regards
--
Carlos.
From bc210a028bb755aa8ca0eaef1605efaab735fde4 Mon Sep 17 00:00:00 2001
From: memeplex
Date: Wed, 2 Jan 2019 19:05:26 -0300
Subject: [PATCH] Use xcolor for all latex preview converters
* lisp/org.el: remove :use-xcolor option and make dvipng use xcolor
since usage of CLI fg and bg color args is incompatible with docs
that themselves use xcolor (e.g. through tikz).
* etc/ORG-NEWS: add incompatible change note.
---
etc/ORG-NEWS | 9
lisp/org.el | 63
2 files changed, 28 insertions(+), 44 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b988559..c1e426c 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -39,6 +39,15 @@ arguments no longer imply a "file" result is expected.
See [[git:3367ac9457]] for details.
+*** All LaTeX preview backends use now xcolor
+
+The dvipng backend was previously relying on fg and bg parameters to
+be passed to the CLI. This didn't work when xcolor was directly or
+indirectly used in the document (e.g. tkiz is a user of xcolor). Since
+every other backend was already using xcolor to set fg and bg, the CLI
+alternative was removed and there is no more a :use-xcolor options
+since now it's implicitly always true.
+
** New features
*** Add a dispatcher command to insert dynamic blocks
diff --git a/lisp/org.el b/lisp/org.el
index 0e541cd..2e63a65 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3813,12 +3813,11 @@ All available processes and theirs documents can be found in
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("latex -interaction nonstopmode -output-directory %o %f")
- :image-converter ("dvipng -fg %F -bg %B -D %D -T tight -o %O %f"))
+ :image-converter ("dvipng -D %D -T tight -o %O %f"))
(dvisvgm
:programs ("latex" "dvisvgm")
:description "dvi > svg"
:message "you need to install the programs: latex and dvisvgm."
- :use-xcolor t
:image-input-type "dvi"
:image-output-type "svg"
:image-size-adjust (1.7 . 1.5)
@@ -3828,7 +3827,6 @@ All available processes and theirs documents can be found in
:programs ("latex" "convert")
:description "pdf > png"
:message "you need to install the programs: latex and imagemagick."
- :use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
@@ -3848,11 +3846,6 @@ PROPERTIES accepts the following attributes:
:messagestring, message it when required programs cannot be found.
:image-input-type string, input file type of image converter (e.g., \"dvi\").
:image-output-type string, output file type of image converter (e.g., \"png\").
- :use-xcolor boolean, when non-nil, LaTeX \"xcolor\" macro is used to
- deal with background and foreground color of image.
- Otherwise, dvipng style background and foreground color
- format are generated. You may then refer to them in
- command options with \"%F\" and \"%B\".
:image-size-adjust cons of numbers, the car element is used to adjust LaTeX
image size showed in buffer and the cdr element is for
HTML file. This option is only useful for process
@@ -3884,8 +3877,6 @@ Place-holders used by `:image-converter' and `:latex-compiler':
Place-holders only used by `:image-converter':
- %Fforeground of image
- %Bbackground of image
%Ddpi, which is used to adjust image size by some processing commands.
%Sthe image size scale ratio, which is used to adjust image size by some
processing commands."
@@ -18339,7 +18330,6 @@ a HTML file."
(cdr (assq processing-type org-preview-latex-process-alist)))
(programs (plist-get processing-info :programs))
(error-message (or (plist-get processing-info :message) ""))
- (use-xcolor (plist-get processing-info :use-xcolor))
(image-input-type (plist-get processing-info :image-input-type))
(image-output-type (plist-get processing-info :image-output-type))
(post-clean (or (plist-get processing-info :post-clean)
@@ -18370,36 +18360,23 @@ a HTML file."
(resize-mini-windows nil)) ;Fix Emacs flicker when creating image.
(dolist (program programs)
(org-check-external-command program error-message))
-(if use-xcolor
- (progn (if (eq fg 'default)
- (setq fg (org-latex-color :foreground))
- (setq fg (org-latex-color-format fg)))
- (if (eq bg 'default)
- (setq bg (org-latex-color :background))
- (setq bg
Re: [O] [Patch] [Feature request] Add option to natively fontify latex snippets and environment
I've improved the commit message to better align org mode conventions and also added a note to ORG-NEWS about the new feature. From 19d1d83901d3cc959b0cef5d2832da307e01 Mon Sep 17 00:00:00 2001 From: memeplex Date: Wed, 2 Jan 2019 19:43:21 -0300 Subject: [PATCH] Add option to natively fontify LaTeX snippets and environments * lisp/org.el: add a 'native value to org-highlight-latex-and-related that allows to use tex native font locking by means of org-src-font-lock-fontify-block. * etc/ORG-NEWS: add note about new feature. --- etc/ORG-NEWS | 5 + lisp/org.el | 24 +++- 2 files changed, 20 insertions(+), 9 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index c1e426c..51d6a07 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -99,6 +99,11 @@ system than the main Org document. For example: *** New cell movement functions in tables ~S-~, ~S-~, ~S-~, and ~S-~ now move cells in the corresponding direction by swapping with the adjacent cell. +*** New option to natively fontify LaTeX snippets and environments +A 'native option was added to org-highlight-latex-and-related. It +matches the same structures than 'latex but it calls +org-src-font-lock-fontify-block instead, thus bringing about full +LaTeX font locking. ** New functions *** ~org-dynamic-block-insert-dblock~ diff --git a/lisp/org.el b/lisp/org.el index 2e63a65..3c9a5dc 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4138,6 +4138,7 @@ org-level-* faces." "Non-nil means highlight LaTeX related syntax in the buffer. When non nil, the value should be a list containing any of the following symbols: + `native' Highlight LaTeX snippets and environments natively. `latex'Highlight LaTeX snippets and environments. `script' Highlight subscript and superscript. `entities' Highlight entities." @@ -4147,6 +4148,7 @@ following symbols: :type '(choice (const :tag "No highlighting" nil) (set :greedy t :tag "Highlight" + (const :tag "LaTeX snippets and environments (native)" native) (const :tag "LaTeX snippets and environments" latex) (const :tag "Subscript and superscript" script) (const :tag "Entities" entities @@ -6093,7 +6095,8 @@ Result depends on variable `org-highlight-latex-and-related'." (list org-match-substring-with-braces-regexp)) (org-use-sub-superscripts (list org-match-substring-regexp (re-latex - (when (memq 'latex org-highlight-latex-and-related) + (when (or (memq 'latex org-highlight-latex-and-related) + (memq 'native org-highlight-latex-and-related)) (let ((matchers (plist-get org-format-latex-options :matchers))) (delq nil (mapcar (lambda (x) @@ -6117,17 +6120,20 @@ highlighting was done, nil otherwise." (while (re-search-forward org-latex-and-related-regexp nil t) ;; on purpose, we ignore LIMIT (unless (cl-some (lambda (f) (memq f '(org-code org-verbatim underline - org-special-keyword))) + org-special-keyword))) (save-excursion (goto-char (1+ (match-beginning 0))) (face-at-point nil t))) - (let ((offset (if (memq (char-after (1+ (match-beginning 0))) - '(?_ ?^)) - 1 - 0))) - (font-lock-prepend-text-property - (+ offset (match-beginning 0)) (match-end 0) - 'face 'org-latex-and-related) + (let* ((offset (if (memq (char-after (1+ (match-beginning 0))) + '(?_ ?^)) + 1 + 0)) + (start (+ offset (match-beginning 0))) + (end (match-end 0))) + (if (memq 'native org-highlight-latex-and-related) + (org-src-font-lock-fontify-block "latex" start end) + (font-lock-prepend-text-property start end + 'face 'org-latex-and-related)) (add-text-properties (+ offset (match-beginning 0)) (match-end 0) '(font-lock-multiline t))) (throw 'found t))) -- 2.20.1
[O] [Patch] [Feature request] Add option to natively fontify latex snippets and environment
This patch adds a fourth 'native value to org-highlight-latex-and-related. It matches the same structures than 'latex but it calls org-src-font-lock-fontify-block instead. It's a simple change that brings full latex fontification by building on top of org-src. I'm using it (implemented as an advice) since a few weeks ago and haven't noticed any problem. Hope you like the idea. Best regards -- Carlos From 3dbbf0f9c04003a5a0f0027c581a2ed6aa9fb892 Mon Sep 17 00:00:00 2001 From: memeplex Date: Wed, 2 Jan 2019 19:43:21 -0300 Subject: [PATCH] Add option to natively fontify latex snippets and environments --- lisp/org.el | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 2e63a65..3c9a5dc 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4138,6 +4138,7 @@ org-level-* faces." "Non-nil means highlight LaTeX related syntax in the buffer. When non nil, the value should be a list containing any of the following symbols: + `native' Highlight LaTeX snippets and environments natively. `latex'Highlight LaTeX snippets and environments. `script' Highlight subscript and superscript. `entities' Highlight entities." @@ -4147,6 +4148,7 @@ following symbols: :type '(choice (const :tag "No highlighting" nil) (set :greedy t :tag "Highlight" + (const :tag "LaTeX snippets and environments (native)" native) (const :tag "LaTeX snippets and environments" latex) (const :tag "Subscript and superscript" script) (const :tag "Entities" entities @@ -6093,7 +6095,8 @@ Result depends on variable `org-highlight-latex-and-related'." (list org-match-substring-with-braces-regexp)) (org-use-sub-superscripts (list org-match-substring-regexp (re-latex - (when (memq 'latex org-highlight-latex-and-related) + (when (or (memq 'latex org-highlight-latex-and-related) + (memq 'native org-highlight-latex-and-related)) (let ((matchers (plist-get org-format-latex-options :matchers))) (delq nil (mapcar (lambda (x) @@ -6117,17 +6120,20 @@ highlighting was done, nil otherwise." (while (re-search-forward org-latex-and-related-regexp nil t) ;; on purpose, we ignore LIMIT (unless (cl-some (lambda (f) (memq f '(org-code org-verbatim underline - org-special-keyword))) + org-special-keyword))) (save-excursion (goto-char (1+ (match-beginning 0))) (face-at-point nil t))) - (let ((offset (if (memq (char-after (1+ (match-beginning 0))) - '(?_ ?^)) - 1 - 0))) - (font-lock-prepend-text-property - (+ offset (match-beginning 0)) (match-end 0) - 'face 'org-latex-and-related) + (let* ((offset (if (memq (char-after (1+ (match-beginning 0))) + '(?_ ?^)) + 1 + 0)) + (start (+ offset (match-beginning 0))) + (end (match-end 0))) + (if (memq 'native org-highlight-latex-and-related) + (org-src-font-lock-fontify-block "latex" start end) + (font-lock-prepend-text-property start end + 'face 'org-latex-and-related)) (add-text-properties (+ offset (match-beginning 0)) (match-end 0) '(font-lock-multiline t))) (throw 'found t))) -- 2.19.2
Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
Here is a patch. It removes quite a few LOC.
> I think option 3 is better. Is there any use case left for :use-xcolor?
Every other previewer has :use-xcolor t. I assume it's safe to simply
ignore :use-xcolor if it's there except that some user has configured
a converter that for some reason requires the color command line args,
in which case he will get an error (because of the color placeholders
left untouched in the command line template).
> Thank you for taking care of this.
Well, thank you for taking care of everything else ;)
Best regards
--
Carlos
From 9beda785e60c791bc6524b996b60e9db00f858b7 Mon Sep 17 00:00:00 2001
From: memeplex
Date: Wed, 2 Jan 2019 19:05:26 -0300
Subject: [PATCH] Use xcolor for all latex preview converters
---
lisp/org.el | 63 -
1 file changed, 19 insertions(+), 44 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 0e541cd..2e63a65 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3813,12 +3813,11 @@ All available processes and theirs documents can be found in
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("latex -interaction nonstopmode -output-directory %o %f")
- :image-converter ("dvipng -fg %F -bg %B -D %D -T tight -o %O %f"))
+ :image-converter ("dvipng -D %D -T tight -o %O %f"))
(dvisvgm
:programs ("latex" "dvisvgm")
:description "dvi > svg"
:message "you need to install the programs: latex and dvisvgm."
- :use-xcolor t
:image-input-type "dvi"
:image-output-type "svg"
:image-size-adjust (1.7 . 1.5)
@@ -3828,7 +3827,6 @@ All available processes and theirs documents can be found in
:programs ("latex" "convert")
:description "pdf > png"
:message "you need to install the programs: latex and imagemagick."
- :use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
@@ -3848,11 +3846,6 @@ PROPERTIES accepts the following attributes:
:messagestring, message it when required programs cannot be found.
:image-input-type string, input file type of image converter (e.g., \"dvi\").
:image-output-type string, output file type of image converter (e.g., \"png\").
- :use-xcolor boolean, when non-nil, LaTeX \"xcolor\" macro is used to
- deal with background and foreground color of image.
- Otherwise, dvipng style background and foreground color
- format are generated. You may then refer to them in
- command options with \"%F\" and \"%B\".
:image-size-adjust cons of numbers, the car element is used to adjust LaTeX
image size showed in buffer and the cdr element is for
HTML file. This option is only useful for process
@@ -3884,8 +3877,6 @@ Place-holders used by `:image-converter' and `:latex-compiler':
Place-holders only used by `:image-converter':
- %Fforeground of image
- %Bbackground of image
%Ddpi, which is used to adjust image size by some processing commands.
%Sthe image size scale ratio, which is used to adjust image size by some
processing commands."
@@ -18339,7 +18330,6 @@ a HTML file."
(cdr (assq processing-type org-preview-latex-process-alist)))
(programs (plist-get processing-info :programs))
(error-message (or (plist-get processing-info :message) ""))
- (use-xcolor (plist-get processing-info :use-xcolor))
(image-input-type (plist-get processing-info :image-input-type))
(image-output-type (plist-get processing-info :image-output-type))
(post-clean (or (plist-get processing-info :post-clean)
@@ -18370,36 +18360,23 @@ a HTML file."
(resize-mini-windows nil)) ;Fix Emacs flicker when creating image.
(dolist (program programs)
(org-check-external-command program error-message))
-(if use-xcolor
- (progn (if (eq fg 'default)
- (setq fg (org-latex-color :foreground))
- (setq fg (org-latex-color-format fg)))
- (if (eq bg 'default)
- (setq bg (org-latex-color :background))
- (setq bg (org-latex-color-format
- (if (string= bg "Transparent") "white" bg
- (with-temp-file texfile
- (insert latex-header)
- (insert "\n\\begin{document}\n"
- "\\definecolor{fg}{rgb}{" fg "}\n"
- "\\definecolor{bg}{rgb}{" bg "}\n"
- "\n\\pagecolor{bg}\n"
- "\n{\\color{fg}\n"
- string
- "\n}\n"
- "\n\\end{document}\n")))
- (if (eq fg 'default)
- (setq fg (org-dvipng-color :foreground))
- (unless (string= fg "Transparent")
- (setq fg (org-dvipng-color-format fg
- (if (eq bg 'default)
- (setq bg (org-dvipng-color :background))
- (unless (string= bg "Transparent")
- (setq bg (org-dvipng-color-format bg
- (with-temp-file texfile
- (insert latex-header)
- (insert "\n\\begin{document}\n" string "\n\\end{document}\n")))
-
+(if (eq fg 'default)
+ (setq fg
Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
Considering the above, do you still want me to write a patch for this? Some options: 1. Add the above as a remark in the user guide or the wiki. 2. Add a variant of the dvipng backend, say dvipng-xcolor, as explained. 3. Remove the dvipng cli color code and (maybe just deprecate or ignore) the use-xcolor option altogether and make xcolor the default for every backend. 4. Do nothing. What do you think? Regards -- Carlos
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
3. Or maybe you mean a region extension function that uses the parser to find out the opposite delimiter of a block?
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
> > > I'd > rather see work to integrate fontification with the parser. > I could take a look at this sometime in the next few months but I'm not sure what do you mean. In particular: 1. Is the parser doing partial parsings of every inserted/removed character or line in a more or less complete syntactical environment around the insertion/removal? 2. If the parser identifies a block how is it in a better position to flag it as outdated regarding fontification? Do you mean completely circumventing the search based font lock mechanism with its multiline property and region extensions? That is, directly setting face related properties and forcing a refresh of the region? > Meanwhile, I applied your patch in master. I also added a commit > message. > Thanks, Nicolas! Best regards -- Carlos
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
Here is a patch on top of latest revision. It just adds an extension
function while initializing font locking, as documented in [1]. It
indeed reduces lines of code to some extent by moving the dirty stuff
out of the fontification function (but I tried to keep the code
formatting of your last commit, since it was rather different than the
one shipped with emacs). The approach is more robust AFAICS since the
font locking framework is correctly informed of which blocks should be
refontified before fontification itself happens. It covers all types
of blocks: #+BEGIN/#+END, \begin\end, \[\]. It's not a full parser but
at least it matches corresponding delimiters by type by using a simple
heuristic.
Of course, I cannot ensure that it's bug free but I was *really* using
and improving this for a couple of weeks now and I can say it does the
job. If you want me to change anything just let me know, I will have
some time for this for the next few days.
Best regards
--
Carlos
---
[1]
https://www.gnu.org/software/emacs/manual/html_node/elisp/Multiline-Font-Lock.html
diff --git a/lisp/org.el b/lisp/org.el
index 5dd5c02..115fa4d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6102,6 +6102,24 @@ by a #."
(add-text-properties closing-start end '(invisible t)))
t)
+(defun org-fontify-extend-region (beg end _old-len)
+ (let ((begin-re "\\(\\[\\|\\(#\\+begin_\\|begin{\\)\\S-+\\)")
+ (end-re "\\(\\]\\|\\(#\\+end_\\|end{\\)\\S-+\\)")
+ (extend (lambda (r1 r2 dir)
+ (let ((re (replace-regexp-in-string "\\(begin\\|end\\)" r1
+ (replace-regexp-in-string "[][]" r2
+ (match-string-no-properties 0)
+ (re-search-forward (regexp-quote re) nil t dir)
+(save-match-data
+ (save-excursion
+ (goto-char beg)
+ (back-to-indentation)
+ (cond ((looking-at end-re)
+ (cons (or (funcall extend "begin" "[" -1) beg) end))
+ ((looking-at begin-re)
+ (cons beg (or (funcall extend "end" "]" 1) end)))
+ (t (cons beg end)))
+
(defun org-activate-footnote-links (limit)
"Add text properties for footnotes."
(let ((fn (org-footnote-next-reference-or-definition limit)))
@@ -6233,16 +6251,11 @@ Result depends on variable `org-highlight-latex-and-related'."
(org-use-sub-superscripts (list org-match-substring-regexp
(re-latex
(when (memq 'latex org-highlight-latex-and-related)
- (let* ((matchers (plist-get org-format-latex-options :matchers))
- (regexps (and (member "begin" matchers)
-'("end{[a-zA-Z0-9\\*]+}[ \t]*$"
- (dolist (matcher matchers)
- (pcase (assoc matcher org-latex-regexps)
- (`("begin" . ,_) (push "^[ \t]*begin{[a-zA-Z0-9\\*]+}"
- regexps))
- (`(,_ ,regexp . ,_) (push regexp regexps))
- (_ nil)))
- (nreverse regexps
+ (let ((matchers (plist-get org-format-latex-options :matchers)))
+ (delq nil
+ (mapcar (lambda (x)
+ (and (member (car x) matchers) (nth 1 x)))
+ org-latex-regexps)
(re-entities
(when (memq 'entities org-highlight-latex-and-related)
(list "\\(there4\\|sup[123]\\|frac[13][24]\\|[a-zA-Z]+\\)\
@@ -6259,38 +6272,20 @@ highlighted object, if any. Return t if some highlighting was
done, nil otherwise."
(when (org-string-nw-p org-latex-and-related-regexp)
(catch 'found
- (while (re-search-forward org-latex-and-related-regexp limit t)
+ (while (re-search-forward org-latex-and-related-regexp
+nil t) ;; on purpose, we ignore LIMIT
(unless (cl-some (lambda (f) (memq f '(org-code org-verbatim underline
- org-special-keyword)))
+ org-special-keyword)))
(save-excursion
(goto-char (1+ (match-beginning 0)))
(face-at-point nil t)))
- (let* ((start (if (memq (char-after (1+ (match-beginning 0)))
+ (let ((offset (if (memq (char-after (1+ (match-beginning 0)))
'(?_ ?^))
- (1+ (match-beginning 0))
- (match-beginning 0)))
- (end
- (let* ((b (match-beginning 0))
- (e (match-end 0))
- (m (buffer-substring-no-properties b e)))
- (cond
- ((string-match "\\`[ \t]*begin{\\([a-zA-Z0-9\\*]+\\)}"
-m)
- (let ((re (format "end{%s}[ \t]*$"
- (regexp-quote (match-string 1 m)
- (or (re-search-forward re nil t) e)))
- ((string-match "end{\\([a-zA-Z0-9\\*]+\\)}[ \t]*\\'" m)
- (let ((re (format "^[ \t]*begin{%s}"
- (regexp-quote (match-string 1 m)
- (setq start
- (or (save-excursion (re-search-backward re nil t))
- b))
- (line-end-position)))
- ((string-match "\\`[a-zA-Z]+\\*?{\\'" m)
- (search-forward "}" nil t))
- (t e)
+ 1
+ 0)))
(font-lock-prepend-text-property
- start end 'face 'org-latex-and-related)
+ (+ offset (match-beginning 0)) (match-end 0)
+ 'face 'org-latex-and-related)
(add-text-properties start end '(font-lock-multiline t)))
(throw 'found t)))
nil)))
@@ -6480,6 +6475,8 @@
Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
Hi,
I found out that there is already code doing what I proposed but just
when the backend is not dvipng.
If you want to keep using dvipng you can set:
(let ((dvipng (alist-get 'dvipng org-preview-latex-process-alist)))
(plist-put dvipng :image-converter '("dvipng -D %D -T tight -o %O %f"))
(plist-put dvipng :use-xcolor t))
The first setting is necessary to remove -F and -B from the command
line since otherwise the mix of xcolor and color arguments makes
dvipng abort with segmentation fault.
Otherwise, use another backend like imagemagick.
Best regards
--
Carlos
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
> > > > Maybe you could rewrite my function in a better way using the > > precomputed latex regexps and augmenting them with #+BEGIN/END > > counterparts. > > Per above, I'm not really interested in writing yet another workaround > for something that is going to fail anyway. For the time being, I just > accept that fontification is not perfect. > Hi Nicolas, I understand this. It's just that I have been using an extension function for editing complex documents with lots of blocks (latex and org) and I've not yet seen any problem, while I quickly spot rough edges otherwise. It's not like writing yet another workaround in an accumulative fashion, since the fontification functions just work forward as always and the extension function is the one taking care of finding the opposite end, plus it's just one function for all types of blocks. I've no problem in contributing a patch if you're not inclined to work in this anymore. It will have to move the end searching logic out of org-do-latex-and-related though. All in all I don't think there would be more lines of code or complexity and all block types would be given the same treatment, moreover it would be a bit more by the book. Give it a chance :) Anyway, thank you for your work. Best regards -- Carlos
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
Nicolas, I have modified org-fontify-meta-lines-and-blocks-1 following your approach: @@ -5991,6 +5991,13 @@ by a #." (dc3 (downcase (match-string 3))) end end1 quoting block-type) (cond + ((and (match-end 4) (equal dc3 "+end")) + (save-match-data +(save-excursion + (when (re-search-backward + (concat "^[ \t]*#\\+begin" (match-string 4) "\\>.*") + nil t) ;; on purpose, we look further than LIMIT +(org-fontify-meta-lines-and-blocks-1 limit) ((and (match-end 4) (equal dc3 "+begin")) ;; Truly a block (setq block-type (downcase (match-string 5)) Nevertheless I'm not quite satisfied. If you play a bit with opening and ending delimiters and moving around the buffer you will quite easily find border cases in which the block is indeed recognized and properties adequately set but still font locking is only partially refreshed until you scroll, move to another buffer, etc. I tried any combination of save-match-data and save-excursion wrapping the recursive call, even without any of them, to no avail. What I think it's happening here is that ignoring the limit forwards could be a tolerable trick, but when you start jumping forward and backwards in you fontification function, font-lock routines lose track of what is meant to be refreshed; and if, instead, you save everything before jumping around it's like nothing or too little have been refontified from the point of view of the framework. I still believe that explicitly extending the region is a saner approach, it's the documented one at least. Maybe you could rewrite my function in a better way using the precomputed latex regexps and augmenting them with #+BEGIN/END counterparts. That still relies on ignoring limits in the font locking function but from a cursory inspection I understand the framework is quite robust when you move the point further than allowed. Also, as I've said before, some border cases remain when the block is too large (larger than the jit chunk) and you break the ending delimiter, but nothing to worry about. Best regards -- Carlos
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
Also, in the example above, when you change and restore the opening clause, refontification doesn't happen immediately, you have to somewhat move the point to retrigger fontification. > #+END_XXX python Just #+END_XXX, of course.
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
One problem I found after uninstalling my extension function is with #+BEGIN/END blocks. For example, enable fontification for python, elisp or whatever and write a long block like this: #+BEGIN_XXX python def xxx(x): pass def xxx(x): pass ... #+END_XXX python Now scroll down to the end and change python to pyton and back. Even when the delimiter is restored fontification isn't. I see that, for latex blocks, you have added a case for searching backwards for an opening delimiter. But org-fontify-meta-lines-and-blocks-1 lacks a similar logic.
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
Oh, I see there have been some changes in org-compute-latex-and-related-regexp in a previous commit. Now it seems to be working at least for some simple examples. I'm working in a long and complex beamer document so I will be able to more seriously test this during the next few days. Also, I'm interested in understanding your take on the problem. Thanks again.
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
Hi Nicolas, thank you for letting me know.
I've been giving it a try but it doesn't really fix the main problem
AFAICS (I've just redefined org-do-latex-and-related as in [1], maybe
I'm missing something). It's not surprising because I don't think you
can work around it without installing a region extension function.
For example, in order to reproduce one possible problem:
1) write \begin{xxx}
2) in the next line write xxx
3) now, in a third line, write \end{xxx}
This basic example already fails because you're not entering the start
and end delimiters at the same time (maybe you're using some snippet
facility for that?). Then you have an array of more complex cases:
blocks that are larger than jit-lock-chunk-size, changing one of the
ends of the block and restoring it, etc.
There is no perfect solution that I know of, but at the bare least you
have to let the font lock framework know that some entire syntactical
region has changed. Also you have to ignore search limits since one
chunk won't do it as a syntactical unit, but you are already doing
this. Even doing all this, some border cases remain, in particular if
you have a really large block and you go to the end of it and change
its delimiter and then restore it, the jit framework will proceed by
chunks upwards but only when you scroll up and progressively reveal
the block, so in general it won't be refontified until you get near
the top delimiter and the search finally identifies a syntactic unit
from the top to the bottom. I don't think this case is important in
practice, but it's a good illustration of how things are working under
the hood.
Also, there is the fact that this limitations are shared by the font
locking of #+BEGIN/END blocks. Even if search limits are ignored, the
region extension is still missing there too.
I've considerably improved my region extension function since my last
post, if you're interested in adding it I could write a proper patch,
but here it is anyway:
(defun my-org-extend-region (beg end _old-len)
(let ((begin-re "\\(\\[\\|\\(#\\+begin_\\|begin{\\)\\S-+\\)")
(end-re "\\(\\]\\|\\(#\\+end_\\|end{\\)\\S-+\\)")
(extend (lambda (r1 r2 dir)
(let ((re (replace-regexp-in-string "\\(begin\\|end\\)" r1
(replace-regexp-in-string "[][]" r2
(match-string-no-properties 0)
(re-search-forward (regexp-quote re) nil t dir)
(save-match-data
(save-excursion
(goto-char beg)
(back-to-indentation)
(cond ((looking-at end-re)
(cons (or (funcall extend "begin" "[" -1) beg) end))
((looking-at begin-re)
(cons beg (or (funcall extend "end" "]" 1) end)))
(t (cons beg end)))
Now it better supports nested blocks (of different types at least) and
also displaymath \[ \] delimiters.
Best regards
--
Carlos
[1]
https://code.orgmode.org/bzg/org-mode/commit/af3e2b1856be4088071bd01f386560cff1e292bc?style=unified
Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
> Would you want to provide a patch for that? Yes, sure, just give me a few days since I'm quite busy right know. Are you ok with depending on xcolor by default or do you prefer a customization option?
Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
The quick and dirty option, if anyone wants it now:
(setq org-format-latex-header
(concat org-format-latex-header
"\\usepackage{xcolor}\n"
"\\definecolor{__bg__}{HTML}{1d1f21}\n"
"\\definecolor{__fg__}{HTML}{c5c8c6}\n"
"\\color{__fg__}\n"
"\\pagecolor{__bg__}\n"))
HTML format is more convenient to edit by hand based in your current
default face.
[O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
Hi, I know this problem has been reported in the past ([1], [2]). The
second link provides a hint to a solution that I've developed
further. The underlying problem is (from dvipng man page):
-fg color_spec Choose foreground color for the images. This option will
be ignored if there is a foreground color \special in the DVI. The
color spec should be in TeX color \special syntax, e.g., 'rgb 1.0
0.0 0.0'.
So the current approach to latex fragment previewing is broken as far as
any latex package indirectly uses xcolor to set background or foreground
color, tikz being a prominent example.
As a more robust solution, I suggest to explicitly set the colors in the
tex fragment for the preview instead of passing them as arguments to
dvipng. This can be done easily:
...
\usepackage{xcolor}
...
\begin{document}
\definecolor{bg}{rgb}{0,0,0}
\definecolor{fg}{rgb}{1,1,1}
\color{fg}
\pagecolor{bg}
...
Where fg and bg might be replaced by randomly generated string or
whatever you see fit to prevent name clashes.
Notice that the syntax for rgb color is the same than the one for dvipng
so it shouldn't be much of a refactoring.
Best regards
--
Carlos
---
[1] https://lists.gnu.org/archive/html/emacs-orgmode/2010-01/msg00635.html
[2] https://lists.gnu.org/archive/html/emacs-orgmode/2012-05/msg00865.html
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
> the extension function becomes helpful again: this because the > #+BEGIN/#+END matcher is incremental and eventually the region to Well, on a closer inspection it's not that incremental, it's just ignoring the limit... (defun org-fontify-meta-lines-and-blocks-1 (limit) (when (re-search-forward (concat "^[ \t]*#\\+end" (match-string 4) "\\>.*") nil t) ;; on purpose, we look further than LIMIT This is against the rules! But if it's allowed here it should be allowed in org-do-latex-and-related by the same token, shouldn't it? So in order to get all this properly working: 1. Also ignore the limit in org-do-latex-and-related. 2. Install a region extension function so that multiline regions are properly identified at the start and after syntax breaking change (that is, at the beginning or at the end).
Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
Hi all,
I've been adding some improvements to the region extension function
(pasted below) in order to better support nesting, but anyway I'm
convinced that the current approach to org-highlight-latex-and-related
== '(latex) is hopeless except for small fragments and should be
reworked or dropped or kept with a caveat. This is because it quite
easily bumps into jit-lock-chunk-size (which is set at 500 by
default). Multiline matchers, specially medium to large ones, are
explicitly disadvised for a good reason. Once you have a larger chunk
of latex no region extension function will do it. But immediately
after you wrap the large latex environment inside a #+BEGIN/#+END pair
the extension function becomes helpful again: this because the
#+BEGIN/#+END matcher is incremental and eventually the region to
refontify spans the entire extended region and the latex matcher is
able to do its thing again.
Anyway, here is the extension function:
(defun my-org-extend-region (beg end old-len)
(let ((begin-re "[\t ]*\\(#\\+BEGIN_\\|begin{\\)%s[ \t}]?")
(end-re "[\t ]*\\(#\\+END_\\|end{\\)%s[ \t}]?")
(name-re "\\([a-zA-Z0-9_\\*]+\\)")
(extend (lambda (re pos dir)
(let ((re (format re (regexp-quote (match-string 2)
(or (re-search-forward re nil t dir) pos)
(save-match-data
(save-excursion
(goto-char beg)
(beginning-of-line)
(if (looking-at (format end-re name-re))
(setq beg (funcall extend begin-re beg -1))
(when (looking-at (format begin-re name-re))
(setq end (funcall extend end-re end 1)))
(message "%s--%s" beg end)
(cons beg end))
Best regards
--
Carlos
Re: [O] Feature request: simplify usage of special blocks (for beamer)
Hi Nicolas, fair enough if you feel it's not worth the hassle. I'm pasting here a simple filter implementing the rule I described above (use the special arg if present and if it doesn't conflict with any ATTR directive for the current backend) for anyone interested, if any at all: (defun my-org-special-block-filter (tree backend _symbol) (pcase-let ((`(,prop ,fmt) (cond ((org-export-derived-backend-p backend 'latex) '(:attr_latex ":options [%s]") (when prop (org-element-map tree 'special-block (lambda (element) (unless (org-element-property prop element) (save-excursion (goto-char (org-element-property :begin element)) (when (re-search-forward "#\\+BEGIN_\\S-+[ \t]+\\(.+\\)" nil t) (let ((attr (format fmt (match-string-no-properties 1 (org-element-put-property element prop (list attr)) nil) It can easily be extended to other backends by just adding a new clause to the cond at the beginning. This plus a little extra font locking allows me to edit my presentations like the attached screenshot shows. I think it's quite an improvement over subsectioning and ignoreheading cruft but it must be said that, although it looks nicer, it's only a marginal improvement over special blocks plus affiliated ATTRs. Best regards -- Carlos
Re: [O] Feature request: simplify usage of special blocks (for beamer)
I would also like to elaborate on another aspect of this. #+ATTR_xxx serves two purposes: a. As a syntactical means of attaching extra information to syntactically constrained elements (as tables or images). For this purpose the _xxx part is irrelevant, only the affiliation to an element matters. b. As a way of differentiating between different sets of attributes and thus dispatching the appropriate set to the appropriate backend. In the case of special blocks, which are syntactically capable of directly taking arguments, just as SRC blocks do, (a) doesn't apply. This brings about the possibility of a syntactic shortcut at the cost of (b). So, a general rule could be: i. A backend xxx interprets the argument to a special block as if it were the argument to an affiliated ATTR_xxx. ii. In case of conflict ATTR_xxx wins. iii. It's well understood (and documented!) that, by doing so, ability to export to other backends (point 2 above) may be compromised. Thus the user would take advantage of this shortcut only when he/she is already stuck with some particular output format. Also, for users implementing kinda DSLs, having this special blocks with special arguments is a handy feature. Let's add this to my list of suggestions as proposal (4), again related to but mostly independent of the other ones, although it's expected that something like (2) would have to be implemented in order to get (3) or (4). Best regards -- Carlos
Re: [O] Feature request: simplify usage of special blocks (for beamer)
Hi Eric, And this is where the challenge lies! The whole point of special blocks is > that org knows nothing of their semantics. They are a "black box" and it > would be difficult to identify export specific elements and general > elements on this basis. > I partially agree with this just because TIL that the html backend is already exporting special blocks as divs with an appropriate css class. But facilitating powerful backend specific mechanisms to the user that prefer to exploit the advantages of a particular backend, by somehow hindering his/her ability to later export to a different format, that's important too. And, besides backend-specific stuff, don't forget there are user-specific extensions, as mine above, that deliberately sacrifice generality. All this is in the best open-close spirit I would say and org already fully embraces it by its superb backend and filter interfaces. The same than the core parser is exposing a block "special type" it could also expose the block "special argument" as an uninterpreted string for the backend to interpret it. To emphasize this point: I'm not proposing that the core parser understands the arguments to the special block but that it passes opaque content for the backend and/or end user to process. I would have gladly avoided that save-excursion-goto-char-re-search-forwars cruft to focus in parsing a string cleanly passed down by the parser. Notice that, up to this point, I've not proposed any modification to the latex backend. But, to be honest, I see no harm in interpreting this special argument as :options if it's well understood that, by doing so, ability to export to another backends may be compromised. I understand this proposal could be more controversial, tough. So I think it's better to distinctly state the different but related suggestions I made: 1. Mention special blocks in the beamer export documentation as an alternative to subsectioning. 2. Make the core parser pass an :args or similar property as part of the element for the sake of backends providing specific extensions or end users filtering the tree to tailor the syntax to their needs, thus empowering special blocks as an extension mechanism. 3. Make the latex backend interpret this :args property as options for the underlying latex environment. Best regards -- Carlos
