Re: [PATCH] Link handling for qutebrowser org-mac-link.el
Bonjour Bastien,
as per your wish and hint (thanx).
See attached.
Salut
Aimé
>From 5356ee77c368541113618a391b8480709c5eeb0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Aim=C3=A9=20Bertrand?=
Date: Tue, 18 May 2021 01:23:51 +0200
Subject: [PATCH] org-mac-link.el: Add support for qutebrowser
* lisp/org-mac-link.el (org-mac-grab-qutebrowser-app-p): Variable for menu option
(org-mac-grab-link): Menu option for qutebrowser
(org-as-mac-qutebrowser-get-frontmost-url): Retrieve url and title
---
lisp/org-mac-link.el | 55 +++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/lisp/org-mac-link.el b/lisp/org-mac-link.el
index f6d6da3..d887128 100644
--- a/lisp/org-mac-link.el
+++ b/lisp/org-mac-link.el
@@ -218,6 +218,12 @@
:group 'org-mac-link
:type 'string)
+(defcustom org-mac-grab-qutebrowser-app-p t
+ "Add menu option [q]utebrowser to grab links from qutebrowser.app."
+ :tag "Grab qutebrowser.app links"
+ :group 'org-mac-link
+ :type 'boolean)
+
;; In mac.c, removed in Emacs 23.
(declare-function do-applescript "org-mac-message" (script))
@@ -254,7 +260,8 @@ When done, go grab the link, and insert it at point."
("e" "evernote" org-mac-evernote-note-insert-selected ,org-mac-grab-Evernote-app-p)
("t" "ogether" org-mac-together-insert-selected ,org-mac-grab-Together-app-p)
("S" "kim" org-mac-skim-insert-page ,org-mac-grab-Skim-app-p)
- ("A" "crobat" org-mac-acrobat-insert-page ,org-mac-grab-Acrobat-app-p)))
+ ("A" "crobat" org-mac-acrobat-insert-page ,org-mac-grab-Acrobat-app-p)
+ ("q" "utebrowser" org-mac-qutebrowser-insert-frontmost-url ,org-mac-grab-qutebrowser-app-p)))
(menu-string (make-string 0 ?x))
input)
@@ -1013,6 +1020,52 @@ list of message:// links to flagged mail after heading."
(org-insert-heading nil t)
(insert org-heading "\n" (org-mac-message-get-links "f"))
+
+;; Handle links from qutebrowser.app
+
+(defun org-as-mac-qutebrowser-get-frontmost-url ()
+ (let ((result
+ (do-applescript
+ (concat
+ "set oldClipboard to the clipboard\n"
+ "set frontmostApplication to path to frontmost application\n"
+ "tell application \"qutebrowser\"\n"
+ " activate\n"
+ " delay 0.15\n"
+ " tell application \"System Events\"\n"
+ " keystroke \"y\"\n"
+ " keystroke \"y\"\n"
+ " end tell\n"
+ " delay 0.15\n"
+ " set theUrl to the clipboard\n"
+ " set the clipboard to oldClipboard\n"
+ " delay 0.15\n"
+ " tell application \"System Events\"\n"
+ " keystroke \"y\"\n"
+ " keystroke \"T\"\n"
+ " end tell\n"
+ " delay 0.15\n"
+ " set theTitle to the clipboard\n"
+ " set the clipboard to oldClipboard\n"
+ "set theResult to (get theUrl) & \"::split::\" & (get theTitle)\n"
+ "end tell\n"
+ "activate application (frontmostApplication as text)\n"
+ "set links to {}\n"
+ "copy theResult to the end of links\n"
+ "return links as string\n"
+ (car (split-string result "[\r\n]+" t
+
+;;;###autoload
+(defun org-mac-qutebrowser-get-frontmost-url ()
+ (interactive)
+ (message "Applescript: Getting qutebrowser url...")
+ (org-mac-paste-applescript-links (org-as-mac-qutebrowser-get-frontmost-url)))
+
+;;;###autoload
+(defun org-mac-qutebrowser-insert-frontmost-url ()
+ (interactive)
+ (insert (org-mac-qutebrowser-get-frontmost-url)))
+
(provide 'org-mac-link)
--
2.30.1 (Apple Git-130)
Bastien @ 2021-05-16 14:21 :
Hi Aimé,
hope to have done this right as a first time.
Thanks for the effort - but the patch is not in a readable
format for
me. I suggest you clone org-mode.git* and run C-x v = in the
modified
file to get a proper patch in the buffer, save this buffer as a
patch
and attach it (vs. include it) to your email.
If you want your patch to be perfect, you can check this page
too:
https://orgmode.org/worg/org-contribute.html#commit-messages
Thanks in advance,
Re: [PATCH] Possibility of using alternative separators in macros
Maxim Nikulin writes:
> On 17/05/2021 02:21, Christian Moe wrote:
>> Maxim Nikulin writes:
>>> On 03/05/2021 04:08, Christian Moe wrote:
>> [snip]
>>> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
>>> #'identity _ ",")))
>>>
>>> {{{allargshack(one, two, three)}}}
>>>
>>> I do not know if Eric can swap order of arguments of his credits
>>> macro. Extracting namely last argument requires a bit more lisp code.
>>
>> Yes, I didn't think that far. This would provide a comprehensive
>> backwards-compatible solution to the comma-escaping problem, though
>> perhaps not the most newbie-friendly one. It would also make macros more
>> flexible and powerful in the bargain (I'm sure people will think of
>> other uses for this than commas).
>
> I agree that it would abuse arguments syntax, but I expect that namely
> newbies would not bother since it would "just work":
>
> #+MACRO definition - $1 ::$_
>
> {{{definition(one, two, three}}}
>
> It is more experienced users who may be confused why it works.
That's not what I was trying to say. I don't think your suggestion
abuses the argument syntax - it would extend it, in a way that is likely
to prove helpful for multiple purposes.
When I said it was probably not the most newbie-friendly solution for
the comma-escaping problem, I thought that it required including a bit
of lisp in their macros to add the commas back in (the mapconcat
expression in your "allargshack" example above).
But if the "definition" macro above "just works", I suppose that in your
solution, the list of arguments $_ would by default expand to the same
string as the mapconcat expression would, i.e. the commas would be added
back in. That makes sense. The mapconcat expression would not even be
needed, then, unless one wants the macro to do anything else than
preserve commas. Or am I misunderstanding something?
Yours,
Christian
Re: Manual on web site is not the latest version
William Denton writes: > On 28 April 2021, Bastien wrote: > >> Do you still see differences between the doc/org-manual.org and the >> one published on https://orgmode.org/manual/ ? >> >> If so, please point at one or two differences. Thanks! > > Here's a late follow-up. Thanks for checking. > > On the web at https://orgmode.org/manual/Languages.html#Languages > > "Code blocks in the following languages are supported." > > "Additional documentation for some languages is at > https://orgmode.org/worg/org-contrib/babel/languages.html.; > > In org-manual.org, both sentence are different: > > $ grep -A2 "Code blocks" doc/org-manual.org > Code blocks in dozens of languages are supported. See Worg for > [[https://orgmode.org/worg/org-contrib/babel/languages/index.html][language > specific documentation]]. > > > Bill > > -- > William Denton > https://www.miskatonic.org/ > Librarian, artist and licensed private investigator. > > The online manual is for 9.4 (the released version). What you see in org-manual.org is for 9.5 (which AFAIK has not been released yet). -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: Multilingual support (proposals and state of the question)
Hi Denis, Denis Maier writes: > Why not add a :lang property to other blocks as well? > > #+begin_quote :lang en > this is english. > #+end_quote > > WDYT? > > Denis It's an interesting possibility. However, I think that the advantage of Org src blocks is that you can include anything you want, even quote blocks. And you also have org-edit-special... Best regards, Juan Manuel
Re: prettify-symbols-mode in org agenda?
Ihor Radchenko writes: > I can reproduce with ONGOING as well... In fact, I can reproduce the > issue with any TODO keyword of >4 chars length while using > prettify-symbols-mode (but not pretty-symbols-mode). Moreover, the > 'composition property is _not_ removed in agenda. Emacs... just does not > show the composed string. In this situation I suspect Emacs bug. > > I will try to report to emacs-devel and see what they say. Thanks. At least not something weird in my emacs config. :) I think your patch is ready to be merged into orgMode. Hopefully it can be merged soon. -- William
Re: [PATCH] Possibility of using alternative separators in macros
On 17/05/2021 02:21, Christian Moe wrote:
Maxim Nikulin writes:
On 03/05/2021 04:08, Christian Moe wrote:
[snip]
#+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
#'identity _ ",")))
{{{allargshack(one, two, three)}}}
I do not know if Eric can swap order of arguments of his credits
macro. Extracting namely last argument requires a bit more lisp code.
Yes, I didn't think that far. This would provide a comprehensive
backwards-compatible solution to the comma-escaping problem, though
perhaps not the most newbie-friendly one. It would also make macros more
flexible and powerful in the bargain (I'm sure people will think of
other uses for this than commas).
I agree that it would abuse arguments syntax, but I expect that namely
newbies would not bother since it would "just work":
#+MACRO definition - $1 ::$_
{{{definition(one, two, three}}}
It is more experienced users who may be confused why it works.
Re: Moving some lisp/ob-*.el files to org-contrib - your advice?
Bastien, > > lisp/ob-julia.el: Add a Homepage header > > that Homepage seems to point at > https://git.savannah.gnu.org/cgit/emacs/org-mode.git which appears to be > a (the?) full-on org-mode git repo, and which doesn't appear to have > ob-julia.el. apologies, i hadn't taken the time to look at the full git log message: commit 2e0375d20b3a411ddf32194229c7d93f69aa701c Author: Bastien Guerry Date: Wed May 12 06:20:33 2021 +0200 lisp/ob-julia.el: Add a Homepage header The Homepage header of ob-julia.el points to the new org-mode.git repository because we will include ob-julia.el in Org's core. cheers, Greg
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
On 2021-05-17, 07:29 +0200, Bastien wrote: > Hi Utkarsh, > > Utkarsh Singh writes: > >> For now can you review the patches I proposed earlier in this >> thread? > > Not until both you and Maxim are confident this is useful, complete > and predictable. Ok. > Also, if you resend the patch for review, please use a proper commit > message: https://orgmode.org/worg/org-contribute.html#commit-messages Thanks for the guidance. I was just trying to fit commit message in 50 words but next time I will keep this in mind. -- Utkarsh Singh http://utkarshsingh.xyz
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
On 2021-05-16, 23:24 +0700, Maxim Nikulin wrote: > On 14/05/2021 21:54, Utkarsh Singh wrote: >> On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote: >> >>> Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is >>> that order in which separator candidates are tried should depend on >>> active locale. >>> >> I am willing to work on this problem but before this can you identify >> any other locale with similar problem or a resource from where I can >> information's about locale. > > I do not think list of locales should be hard coded. I am not familiar > with elisp enough to tell you if locale properties such as decimal > separator are exposed through some function. I expect, it is quite > probable. As a last measure, some number, e.g. 0.5 or 1.5 could be > formatted using a locale-aware function and result string could be > checked if it contains ",". I will go through the Elisp manual to find solution for this problem. If you now any other better resource fell free to mail me. -- Utkarsh Singh http://utkarshsingh.xyz
Re: Multilingual support (proposals and state of the question)
Am 17.05.2021 um 17:41 schrieb Juan Manuel Macías: Hi all, I would like to start a thread on this question, leaving some basic ideas and sketches of my own, in case someone else wanted to join the discussion. I think it would be nice if Org Mode offered consistent support (out of the box) for multilingual documents. That is, those documents where there is a main language and it is possible to toggle between a list of others 'secondary' languages, in the LaTeX Babel way. Those documents could be consistently exported to other formats with multilingual support: LaTeX, of course, but also html, odt, etc. What is your opinion? I think Org documents should have three levels in multilingual management: - Short text segments, something like an 'inline block' for other languages - Blocks - Sections For short inline segments, IMHO and without the need to innovate, I think an excellent candidate are the links defined with org-link-set-parameters. For example: Lorem ipsum [[lang:de][some text in German]] dolor sit amet (For structures of this kind I found very interesting ideas here: https://github.com/alhassy/org-special-block-extras) As for blocks, I think of a hypothetical 'lang' block: #+begin_lang el :variant polytonic Some text in polytonic Greek... #+end_lang However, in a previous thread (https://orgmode.org/list/87k0og8fss@list.aleks.bg/) Aleksandar Dimitrov proposed an idea that seemed very suggestive, at least in concept: add a ':lang' argument to the Org code blocks: #+begin_src org :lang fr Some text in french #+end_src Why not add a :lang property to other blocks as well? #+begin_quote :lang en this is english. #+end_quote WDYT? Denis
Multilingual support (proposals and state of the question)
Hi all, I would like to start a thread on this question, leaving some basic ideas and sketches of my own, in case someone else wanted to join the discussion. I think it would be nice if Org Mode offered consistent support (out of the box) for multilingual documents. That is, those documents where there is a main language and it is possible to toggle between a list of others 'secondary' languages, in the LaTeX Babel way. Those documents could be consistently exported to other formats with multilingual support: LaTeX, of course, but also html, odt, etc. What is your opinion? I think Org documents should have three levels in multilingual management: - Short text segments, something like an 'inline block' for other languages - Blocks - Sections For short inline segments, IMHO and without the need to innovate, I think an excellent candidate are the links defined with org-link-set-parameters. For example: Lorem ipsum [[lang:de][some text in German]] dolor sit amet (For structures of this kind I found very interesting ideas here: https://github.com/alhassy/org-special-block-extras) As for blocks, I think of a hypothetical 'lang' block: #+begin_lang el :variant polytonic Some text in polytonic Greek... #+end_lang However, in a previous thread (https://orgmode.org/list/87k0og8fss@list.aleks.bg/) Aleksandar Dimitrov proposed an idea that seemed very suggestive, at least in concept: add a ':lang' argument to the Org code blocks: #+begin_src org :lang fr Some text in french #+end_src And finally, for sections, you could think of a new property ':lang:' * Header :PROPERTIES: :LANG: pt :END: ... Best regards, Juan Manuel
Re: Invalid duration format error with active timestamp
Hello, Garjola Dindi writes: > I am using the most recent elpa version of org > 9.4.5 (9.4.5-93-gbc857b-elpa @ > /home/garjola/.emacs.d/elpa/org-20210510/) with emacs master branch. > > Since updating org yesterday, when I use a timestamp like > > , > | <2021-05-17 Mon 10:00-11:00> > ` > > > building the agenda fails with this backtrace: > > , > | Debugger entered--Lisp error: (error "Invalid duration format: > | #(\"10:00-11:00\" 0 5 (font...") This was fixed a few days ago. Since Org in ELPA is updated every Monday, you need to update it again (later?) today to get the fix. Regards, -- Nicolas Goaziou
Re: prettify-symbols-mode in org agenda?
William Xu writes: > I can't reproduce it using your steps and config. I compared the org > config differences. I'm using a different org keyword ONGOING, instead of > NEXT. > > In fact, if I replace NEXT with ONGOING in 1.el, then I can reproduce > the issue. This is very strange.. I can reproduce with ONGOING as well... In fact, I can reproduce the issue with any TODO keyword of >4 chars length while using prettify-symbols-mode (but not pretty-symbols-mode). Moreover, the 'composition property is _not_ removed in agenda. Emacs... just does not show the composed string. In this situation I suspect Emacs bug. I will try to report to emacs-devel and see what they say. Best, Ihor
Re: [Question] Custom parse tree filter
Hi Nicolas,
Thank you very much for your excelent explanation, which has helped me
to learn new and valuable things.
I chose `headline' instead of `section' because in the scenario where I
want to apply those LaTeX groups I was looking for something like this:
{level 1 - group 1
{level 2 group 1 + group 2
{level 3 group 1 + group 2 + group 3
{etc.
I have tested your function and it works fine when all headers are at
the same level, but with different levels the filter understands both
properties as `font' (?). Anyway, and only for practical purposes, and
because I think that my initial idea of 2 properties was uneconomical, I
have slightly modified your function with a single property
`:fontspec:'. Now, with a couple of marks and some regexp both the
\fontspec group and the one with \addfontfeature are extracted:
| :fontspec: font ! optional: features | \fontspec{font}[features] |
|+---|
| :fontspec: > features | \addfontfeature{features} |
then the variable `fontspec':
(let* ((font )
(fontfeature )
(fontspec (cond (font font) (fontfeature fontfeature
is passed as an argument of `(funcall create-export-snippet ...)'
With a single property it works fine, although I have to test more...
Thak you very much!
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Juan Manuel Macías writes:
>
>> I am writing a custom parse tree filter that does the following (LaTeX
>> backend): if a heading has the ':font:' property, the content of that
>> heading is enclosed in a LaTeX group. If the property is ':fontfeature:',
>> then the content is enclosed in a different group. The filter works fine
>> when all the headings are at the same level. But with different levels,
>> it does not returns the expected result. It's evident that I'm doing
>> something catastrophically wrong :-). I wonder if anyone could put me on
>> the track of the origin of my error...
>>
>> Below, the offender function and a sample. Thanks in advance!
>
> I think you are operating at the wrong level. Higher level headlines
> contain lower level ones. I suggest to operate on sections instead.
>
> Also, using `org-element-interpret-data' is meh because you're operating
> at the parse tree level. You can insert export-snippet objects directly.
>
> Here's a proposal. This could be refactored, but you get the idea.
>
> (defun my-custom-filters/fontspec-headline (tree backend info)
> (when (org-export-derived-backend-p backend 'latex)
> (org-element-map tree 'section
> (lambda (section)
> (let ((font (org-export-get-node-property :FONT section t))
> (fontfeature (org-export-get-node-property :FONTFEATURE section
> t))
> (create-export-snippet
>;; Create "latex" export-snippet with value V.
>(lambda (v)
> (org-element-create 'export-snippet (list :back-end "latex"
> :value v)
> (cond
>(font
> (apply #'org-element-set-contents
>section
>(append (list (funcall create-export-snippet "%font
> start\n"))
>(org-element-contents section)
>(list (funcall create-export-snippet "%font
> end\n")
> (fontfeature
> (apply #'org-element-set-contents
>section
>(append (list (funcall create-export-snippet "%fontfeature
> start\n"))
>(org-element-contents section)
>(list (funcall create-export-snippet "%fontfeature
> end\n"
> info)
> tree))
>
> Also, when "org-cite-wip" is merged, you will be able to replace, e.g.,
>
> (funcall create-export-snippet "%fontfeature start\n")
>
> with
>
> (org-export-raw-string "%fontfeature start\n")
>
> Regards,
Invalid duration format error with active timestamp
Hi,
I am using the most recent elpa version of org
9.4.5 (9.4.5-93-gbc857b-elpa @
/home/garjola/.emacs.d/elpa/org-20210510/) with emacs master branch.
Since updating org yesterday, when I use a timestamp like
,
| <2021-05-17 Mon 10:00-11:00>
`
building the agenda fails with this backtrace:
,
| Debugger entered--Lisp error: (error "Invalid duration format:
| #(\"10:00-11:00\" 0 5 (font...")
|
| error("Invalid duration format: %S" #("10:00-11:00" 0 11 (face
| org-date keymap (keymap (follow-link . mouse-face) (mouse-3 .
| org-find-file-at-mouse) (mouse-2 . org-open-at-mouse)) mouse-face
| highlight wrap-prefix #(" " 0 2 (face org-indent)) line-prefix #(" "
| 0 2 (face org-indent)) org-category "work" fontified t)))
|
| org-duration-to-minutes(#("10:00-11:00" 0 11 (face org-date keymap
| (keymap (follow-link . mouse-face) (mouse-3 . org-find-file-at-mouse)
| (mouse-2 . org-open-at-mouse)) mouse-face highlight wrap-prefix #(" "
| 0 2 (face org-indent)) line-prefix #(" " 0 2 (face org-indent))
| org-category "work" fontified t)))
|
| org-agenda-format-item(nil #("Planning
| ..." 0 68 (face org-level-1 wrap-prefix #("* " 0 2 (face org-indent))
| line-prefix "" org-category "work" fontified t) 68 77 (keymap (keymap
| (follow-link . mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2
| . org-open-at-mouse)) mouse-face highlight face (org-tag org-level-1)
| wrap-prefix #("* " 0 2 (face org-indent)) line-prefix "" org-category
| "work" fontified t) 77 78 (rear-nonsticky (mouse-face highlight keymap
| invisible intangible help-echo org-linked-text htmlize-link) keymap
| (keymap (follow-link . mouse-face) (mouse-3 . org-find-file-at-mouse)
| (mouse-2 . org-open-at-mouse)) mouse-face highlight face (org-tag
| org-level-1) wrap-prefix #("* " 0 2 (face org-indent)) line-prefix ""
| org-category "work" fontified t)) " " "work" (#("work" 0 4 (inherited
| t)) "planning") #("<2021-05-17 Mon 10:00-11:00>" 0 1 (face
| (rainbow-delimiters-depth-1-face org-date) keymap (keymap (follow-link
| . mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2 .
| org-open-at-mouse)) mouse-face highlight wrap-prefix #(" " 0 2 (face
| org-indent)) line-prefix #(" " 0 2 (face org-indent)) org-category
| "work" fontified t) 1 27 (face org-date keymap (keymap (follow-link .
| mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2 .
| org-open-at-mouse)) mouse-face highlight wrap-prefix #(" " 0 2 (face
| org-indent)) line-prefix #(" " 0 2 (face org-indent)) org-category
| "work" fontified t) 27 28 (face (rainbow-delimiters-depth-1-face
| org-date) keymap (keymap (follow-link . mouse-face) (mouse-3 .
| org-find-file-at-mouse) (mouse-2 . org-open-at-mouse)) mouse-face
| highlight wrap-prefix #(" " 0 2 (face org-indent)) line-prefix #(" "
| 0 2 (face org-indent)) org-category "work" rear-nonsticky (mouse-face
| highlight keymap invisible intangible help-echo org-linked-text
| htmlize-link) fontified t))
| "<\\([[:digit:]]\\{4\\}-[[:digit:]]\\{2\\}-[[:digit:]]\\{..." nil)
|
| org-agenda-get-timestamps(nil)
`
Does this ring a bell to somebody? I have been using timestamps like
this for a while without problems. I have checked the manual and I still
see this kind of timestamps in the corresponding section.
Thank you.
G.
--
Re: begin_src Indentation in org 9.4.4, 9.4.5
Hi Bastien, The commit `bfda3cc7df31fa79222efb4c190618c3c85a3d04` breaks automatic (electric) indentation in src blocks for all configurations. Here's what happens with the original issue. When you press `RET` after the first ~hello hi~, the result is that the first line is indented by two spaces, and the second (where the point is) isn't. - since ~electric-indent-mode~ is on, ~org-return~ is called with `indent` set to `t`. - Since ~org-src-tab-acts-natively~ is `t`, indentation is done by calling `tab` in a src edit buffer, which by itself, does nothing. - The observed indentation comes from ~org-src--contents-for-write-back~. Since ~org-src--content-indentation~ is 2 and ~org-src--preserve-indentation~ is ~nil~, this functions further indents each *non blank* line by 2. At this point, the first line is indented, cursor is at bol. Note that you cannot indent your current empty line with `tab`. You can either indent it manually, or call ~org-edit-special~. When you write your second line, then press `RET`, ~org-src--contents-for-write-back~ will add an additional two spaces, producing the reported result. I think a reasonable fix is to have ~org-src--contents-for-write-back~ also indent blank lines. To do this, you need only remove following line from its definition. : (unless (eolp) ;ignore blank lines With this done and `bfda3cc7df31fa79222efb4c190618c3c85a3d04` reverted, the original issue is fixed, and the behaviour is better: when you press `RET` to enter a newline in a src block, it is automatically indented. The downside is that, unless ~org-src--preserve-indentation~ is `t`, when editing a src block, every empty line will be indented with spaces (according to ~org-edit-src-content-indentation~ + the indentation of the #+begin_src line). I think this is reasonable, but perhaps some might disagree. Regards, -- Sébastien Miquel
Re: [wip-cite-new] Adjust punctuation around citations
Am 17.05.2021 um 00:24 schrieb Bruce D'Arcus: On Sun, May 16, 2021 at 6:03 PM Denis Maier wrote: Am 16.05.2021 um 23:38 schrieb Bruce D'Arcus: Can you clarify the rule/situation that would use that approach? Chicago Manual of Style 15.26: "When the source of a block quotation is given in parentheses at the end of the quotation, the opening parenthesis appears after the final punctuation mark of the quoted material. No period either precedes or follows the closing parenthesis." Maybe me and a lot of scholars aren't very good at following these rules :-) Or maybe the stuff I read and write doesn't follow Chicago, etc for whatever reason. Seems to be the same in MLA and APA by the way: https://writingcenter.uagc.edu/block-quotations Very helpful! So what are you thinking; this punctuation-manipulation should not apply to blockquotes at all? I think there are a couple of options and combinations thereof: 1. Do nothing special, just treat block quotations like regular paragraphs. 2. Don't apply this punctuation-manipulation to blockquotes at all, i.e. let authors handle this manually. 3. Adjust RULE in the manipulation function: Let it accept two patterns: '((outside outside before) (outside outside after)) The first would apply to inline quotations, the second to blockquotes. 4. IIUC, it's possible to set certain properties at block elements. So, maybe you could actually add citation information there, e.g.: #+BEGIN_QUOTE :cite @doe p.45 This is a blockquote in its own paragraph. #+END_QUOTE Unsure about the syntax, but you get the idea. This should allow for complex manipulations: the citation can be added before or after the punctuation mark; if a journal requires quotation marks even around blockquotes => just add them during export; if the period is not part of the original quotation you could just do this: #+BEGIN_QUOTE :cite @doe p.45 :punct . This is a blockquote in its own paragraph #+END_QUOTE Then the period will be added during export, but if a journal wants an ellipsis in that case you can also just add that during export. This is a blockquote in its own paragraph [...].[1] Now, this is of course rather complex and might add a lot of overhead. I don't think users should be required to use this, but this could nevertheless be added as an additional and more powerful mechanism. 5. Don't apply punctuation-manipulation to individual blockquotes. #+BEGIN_QUOTE :punctuation-manipulation nil This is a blockquote in its own paragraph. [@doe p. 45] #+END_QUOTE (Maybe adding someting like this even for inline citations would be a good idea: "asdf." [cite: @doe p. 45 :punctuation-manipulation nil] I can imagine many users will be happy with the automatism 95% of the time, but there will always be egde cases.) Again, as I've said above, a combination of these options might be the way to go. E.g., the default could be to disable punctuation-manipulation for blockquotes. In addition to that there could also be a properties based mechanism that offers more options. (Thinking more about it, 3 and 4 would actually also play nicely together.) Denis
