[PATCH] ol.el: add description format parameter to org-link-parameters
* ol.el (org-link-parameters): add parameter `:default-description', a string or a function. * (org-insert-link): if no description is provided (pre-existing or as an argument), next option is to use the `:default-description' (if non-nil) parameter to generate one. Default descriptions are predictable within a link type, but because link types are quite diverse, are NOT predictable across many types. A type-parameter is thus a good place to store information on the default description. --- lisp/ol.el | 49 +++-- 1 file changed, 35 insertions(+), 14 deletions(-) diff --git a/lisp/ol.el b/lisp/ol.el index 1b2bb9a9a..af0aaaf35 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -140,6 +140,13 @@ link. Function that inserts a link with completion. The function takes one optional prefix argument. +`:default-description' + + String or function used as a default when prompting users for a + link's description. A string is used as-is, a function is + called with the full link text as the sole argument, and should + return a single string. + `:display' Value for `invisible' text property on the hidden parts of the @@ -1761,11 +1768,14 @@ prefix negates `org-link-keep-stored-after-insertion'. If the LINK-LOCATION parameter is non-nil, this value will be used as the link location instead of reading one interactively. -If the DESCRIPTION parameter is non-nil, this value will be used as the -default description. Otherwise, if `org-link-make-description-function' -is non-nil, this function will be called with the link target, and the -result will be the default link description. When called non-interactively, -don't allow to edit the default description." +If the DESCRIPTION parameter is non-nil, this value will be used +as the default description. If not, and the chosen link type has +a non-nil `:default-description' parameter, that is used to +generate a description as described in `org-link-parameters' +docstring. Otherwise, if `org-link-make-description-function' is +non-nil, this function will be called with the link target, and +the result will be the default link description. When called +non-interactively, don't allow to edit the default description." (interactive "P") (let* ((wcf (current-window-configuration)) (origbuf (current-buffer)) @@ -1775,7 +1785,7 @@ don't allow to edit the default description." (desc region) (link link-location) (abbrevs org-link-abbrev-alist-local) -entry all-prefixes auto-desc) +entry all-prefixes auto-desc type) (cond (link-location) ; specified by arg, just use it. ((org-in-regexp org-link-bracket-re 1) @@ -1842,6 +1852,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support (and (equal ":" (substring link -1)) (member (substring link 0 -1) all-prefixes) (setq link (substring link 0 -1 + (setq type link) (setq link (with-current-buffer origbuf (org-link--try-special-completion link) (set-window-configuration wcf) @@ -1918,14 +1929,24 @@ Use TAB to complete link prefixes, then RET for type-specific completion support (let ((initial-input (cond (description) - ((not org-link-make-description-function) desc) - (t (condition-case nil -(funcall org-link-make-description-function link desc) - (error - (message "Can't get link description from %S" -(symbol-name org-link-make-description-function)) - (sit-for 2) - nil)) + (desc) + ((org-link-get-parameter +type +:default-description) + (let ((def (org-link-get-parameter + type + :default-description))) + (cond + ((stringp def) def) + ((functionp def) + (funcall def link) + (org-link-make-description-function + (funcall org-link-make-description-function link desc)) + (t (error + (message "Can't get link description from %S" + (symbol-name org-link-make-description-function)) + (sit-for 2) + nil) (setq desc (if (called-interactively-p 'any) (read-string "Description: " initial-input) initial-input -- 2.20.1
ol.el: add description format parameter to org-link-parameters
Suggested patch to add a new link parameter controlling how the default description is generated. As explained in the commit, this behaviour is often similar between links of the same type, but differs between those types, so a parameter seems like a good place to specify it. I've tried to make `org-insert-link' behave sensibly with regard to all the possible options -- hope it's alright. Blue skies, Hugo
Re: Faulty SVG width in default HTML export style
Yuchen Guo writes: > In my experiment removing this line fixed the issue. Thank you for reporting this! I now wonder if anyone knows how to fix the misaligned baselines of inline LaTeX fragments (as shown in the second screenshot). If we could somehow fix that, MathJax-less export could become usable in practice *and* it would also unlock full LaTeX power, including TikZ and beyond! (It would also put Emacs ahead of the pack in the world of LaTeX-capable editors because virtually every other modern editor, including the proprietary ones, can just use MathJax.) Rudy -- "Mathematics takes us still further from what is human into the region of absolute necessity, to which not only the actual world, but every possible world, must conform." -- Bertrand Russell, 1902 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: Custom TODO states for one item
Greetings, Bastien! On 28 March 2022 14:39, Bastien wrote: >> I have a file with custom TODO states: >> >> #+TODO: FOO(f@/@) | BAR(b@/@) >> >> I have one item (heading) within that file that I'd like to have >> different TODO states. Is this possible? > > No, and I don't think it's a good idea to support this. Could you elaborate on why not? I have been in situations where having the ability to define a heading-wise TODO keyword would be useful, but I managed to get around using different ways of achieving the same end-goal. Best regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
ox-latex table tabbing support.
Dear all,
I have implemented tabbing
(http://www.ctex.org/documents/latex/latex2e-html/ltx-58.html) support for
ox-latex. By setting #+ATTR_LATEX: :mode tabbingthe exporter will use the
tabbing environment.
The benefits of using tabbing over tabular:
- Can span multiple pages (also possible with long tables).
- Cell width is fixed and does not depend on the content.
- Cells can overflow.
Use cases of tabbing:
- Generate letter headings with fixed layout
- Generate tables on invoices
- Can replace multi-columns (my personal use case)
Example 1:
#+ATTR_LATEX: :mode tabbing
| A | B |
| | C |
is exported to
\begin{tabbing}
\hspace{0.49\textwidth} \= \hspace{0.49\textwidth} \= \kill
A \> B\\
\> C\\
\end{tabbing}
Example 2:
#+ATTR_LATEX: :mode tabbing
| *Address* | Some street 100, box 101 | | *GSM* | 00 000 00 00 00 |
| | Country | | *Email* | m...@example.com |
the exported pdf is attached to this mail.
Example 3:
#+ATTR_LATEX: :mode tabbing :align \hspace{2cm} \= \hspace{2cm} \= \kill
| name: | A very long product name in this cell | |
| options: | option 1 | 1 |
| | option 2 | 1 |
| | option 3 | 0 |
the exported pdf is attached to this mail.
Implementation details:
- The table environment must be set to tabbing
- The cell separators must be set to \>
- The alignment string must be updated.
Kind regards,
Bob Vergauwen
0001-ox-latex.el-Added-padding-support.patch
Description: Binary data
0002-org-manual.org-Added-padding-feature-to-the-manual.patch
Description: Binary data
0003-ORG-NEWS-Added-padding-feature-to-version-9.6.patch
Description: Binary data
padding-example.pdf
Description: Adobe PDF document
Re: citations: org-cite vs org-ref 3.0
On Mon, Mar 28, 2022 at 8:37 AM Max Nikulin wrote: > > On 28/03/2022 02:40, John Kitchin wrote: > > Max Nikulin writes: > >> On 21/03/2022 18:51, John Kitchin wrote: > > > > Rather than rehash a lot of experiences, I really encourage you to try > > writing a processor that can support this. Or even, try modifying > > org-ref-cite to support it. Not as some thought experiment about what > > should be possible, but an actual experiment that is worked out. > > I have some ideas for links, other inline objects and export attributes > that I should try before. > > >> In particular I am worrying concerning https://github.com/jkitchin/org-ref > >> README (and the same phrase from the earlier message): > >> > >>> org-cite does not meet my citation and technical document publishing > >>> needs, > >>> and it was not possible to integrate it into org-ref without compromising > >>> those. > > > > I have taken this out of the readme. I still agree with the sentiment, > > but my needs are not the same as others (for example, I include in my > > needs include ease of support and development, which is not a user > > need), and it is possible to meet some basic needs fully. > > John, in another message (Sun, 27 Mar 2022 13:00:40 -0400) > https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu you clearly > stated a technical limitation that is a real reason why org-cite is not > an option for you and for some other users: performance has not been > optimized for large BibTeX databases. It is deserved to be mentioned. FWIW, Ihor posted a patch related to this a week or so ago. > You even have managed to convince me that, besides adding missing style > names, some existing ones should be adjusted. noauthor/bare for citeyear > example makes for me much more sense ... This does need some attention, but there are wrinkles here. Citeyear is specific to author-date styles, while noauthor is intended to be more general. Hence, initially "noauthor". This indeed was influenced by CSL implementations like Zotero and pandoc, which have a notion of "suppress author". But the names are kind of awkward admittedly, and Andras Simonyi subsequently added a "year" style in oc-csl. You can see the conversation about it here. https://github.com/andras-simonyi/oc-csl-ns/issues/1#issuecomment-895440897 I think it's probably a good idea to add "year" to the latex processors too. I will reproduce Denis' explanation from that linked comment here: --- The reasoning behind "noauthor" vs "year" was that our priority was portability between different classes of citation styles. If we have this item "John, Doe. /A book/. 2020." the variant "noauthor" can be used to render this consistently. In-Text: a) author-year: "(2020)" b) author-title: "(/A book/)" Author-title in footnote: "/A book/. 2020." Here, it's not so much about what information should be rendered, but rather what should be ommitted. "Year" would be much less portable. That doesn't mean that "year" couldn't be legitimate, in the sense of "I really need the year here". But that raises another question: How will citeproc-el know where this year is coming from, and how the year has to be formatted? That will have to be hardcoded in the processor as styles contain no information about this. Bruce Bruce
Re: Custom TODO states for one item
Hi Ken, Ken Mankoff writes: > I have a file with custom TODO states: > > #+TODO: FOO(f@/@) | BAR(b@/@) > > I have one item (heading) within that file that I'd like to have > different TODO states. Is this possible? No, and I don't think it's a good idea to support this. Best, -- Bastien
Re: Faulty SVG width in default HTML export style
Hi,
Yuchen Guo writes:
> Currently the style specified for SVG images
> in `org-html-style-default' variable is the following:
>
> .org-svg { width: 90%; }
>
> This causes a single image (math formula) to occupy almost the width of
> the entire page, rendering the page unreadable.
>
> In my experiment removing this line fixed the issue.
Indeed, thanks for spotting and reporting this, fixed in the bugfix
branch.
--
Bastien
Re: citations: org-cite vs org-ref 3.0
On 28/03/2022 02:40, John Kitchin wrote: Max Nikulin writes: On 21/03/2022 18:51, John Kitchin wrote: Rather than rehash a lot of experiences, I really encourage you to try writing a processor that can support this. Or even, try modifying org-ref-cite to support it. Not as some thought experiment about what should be possible, but an actual experiment that is worked out. I have some ideas for links, other inline objects and export attributes that I should try before. In particular I am worrying concerning https://github.com/jkitchin/org-ref README (and the same phrase from the earlier message): org-cite does not meet my citation and technical document publishing needs, and it was not possible to integrate it into org-ref without compromising those. I have taken this out of the readme. I still agree with the sentiment, but my needs are not the same as others (for example, I include in my needs include ease of support and development, which is not a user need), and it is possible to meet some basic needs fully. John, in another message (Sun, 27 Mar 2022 13:00:40 -0400) https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu you clearly stated a technical limitation that is a real reason why org-cite is not an option for you and for some other users: performance has not been optimized for large BibTeX databases. It is deserved to be mentioned. You even have managed to convince me that, besides adding missing style names, some existing ones should be adjusted. noauthor/bare for citeyear example makes for me much more sense than general words that org-cite is too CSL-oriented. So the opinion that the set of styles has not really settled yet may be precious for users choosing between org-cite and org-ref. From my point of view such arguments are more clear than your earlier message (Sun, 20 Mar 2022 20:31:29 -0400) https://list.orgmode.org/m2sfrc149c@andrew.cmu.edu I had no intention to force to remove that phrase before the issues are fixed. I was trying to ask you about more details behind your opinion (and now we have them).
Re: Bug: Incorrect weekday in The Org Manual [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
Hi, Johnson writes: > But 2019/04/05 is in fact Friday: > > ``` > ** TODO Wash my hands > DEADLINE: <2019-04-05 Fri 08:00 .+1h> > Marking this DONE shifts the date to exactly one hour from now. > ``` Fixed, thanks! -- Bastien
Re: [PATCH] Fix typo in org-todo-list doc string
Nick Dokos writes: > Tiny typo fix attached. Applied, thanks! -- Bastien
Re: Is there a maintained calf-calendar fork?
Am Sat, 26 Mar 2022 23:03:07 +0100 schrieb Ypo : > Hi > > I use everyday emacs-calf, it is a superb package to see my tasks > within a calendar: https://github.com/kiwanami/emacs-calfw > > But it seems to be unmaintained. > > Is there some *recommended *fork on Github with corrected bugs or new > functions? > The best I have found during a similar search was https://github.com/MaximeWack/emacs-calfw/tree/fix_org-get-timerange Detlef > Offtopic if the answer to the above question is affirmative: could it > be on MELPA? Can MELPA change to new forks? > > Best regards, > > Ypo
