Re: [PATCH] Async session eval (2nd attempt)
Hi Timothy, > This is moving at a glacial pace, but I'd love to see this merged --- > there's clearly a lot of interest in this from the community if not > within this mailing list (ob-async which is more limited has 250 stars > on GitHub). Yes, this has taken far too long -- sorry about that. There have been a few things going on in my life recently, among them a job change. I am in the process of trying to get my FSF copyright forms approved at my new job. I think this will eventually happen, but the process is moving slowly. My last update on this thread was shortly before changing jobs, and I decided not to merge until I was sure I'd be able to stick around to maintain it. If someone is willing to apply the final tweaks and help with maintenance of this functionality, please go ahead and merge this in. Otherwise, I'll merge this as soon as I've got my paperwork approved and am back in action. Jack
Re: Contributor Steward role (was Re: Concerns about community contributor support)
Hi Timothy, thanks for your answer and your willingness to help here, much appreciated. Timothy writes: > I also think that regardless it would be good to put out a call asking > if anyone else is interested/willing to do this: I'm going to be busy > sometimes, a reduced workload is clearly preferable, and less should > slip through the cracks :) Sure. We can certainly have two or more contributor stewards. > I'm happy to document this, but I don't know what expectations should be > set. I think this is a matter that should be decided by consensus among > the current/active maintainers. I started something here: https://orgmode.org/worg/org-contribute.html#what-can-I-expect Please adapt along your own commitment and expectations. >> (4) is perhaps the most daunting task: I even think we could have >> someone only dedicated to this very important task. Just count the >> number of times Nicolas says "I cannot reproduce this." Each time, >> there is a real bug that is *not* fixed... > > Mmmm, even if I say I'm willing to do this, I suspect this is something > I'd by nature push off enough that I'd frequently forget about this 😅. Sure -- also, this is time consuming and probably requires someone to focus just on this. I will raise a call for help for this. > This is how I see this two. As I indicated at the start, I'm happy to do > this, but I think a second person would help ensure that nobody slips > through the cracks. Great! Thanks a lot.
Re: Concerns about community contributor support
Hi Tim, Tim Cross writes: > I agree and am willing to help if I can. Great! Would you agree to be "officially" appointed to this role, with Timothy? I put quotes on "officially": when moving toward the new maintainance team, I'd like to list maintainers and their roles, including the "contributor stewards". If you prefer not to publicly appear but still work on this, that's perfectly okay too, of course. > One thing I do think would be helpful, particularly for documentation on > maintenance of org mode, would be a clear outline of project goals and > philosophy. Some of this would be 'concrete' statements, such as the > minimum supported Emacs version, size of contribution and requirements > to sign FSF copyright assignment paperwork, inclusion of acceptance > tests, documentation, maintenance of backwards compatibility, API > stability etc. Other parts would be more 'fuzzy' guidelines, such as > avoiding complexity and 'blow out' in options/arguments, balancing > features and maintainability, what should become part of org core and > what should be in contributions or a completely separate add on package > and what guidelines are used in assessing extensions/enhancements for > inclusion etc. > > It will be challenging to define this as there are a wide diversity of > views and priorities amongst the community. However, I think it would be > an overall benefit for both the community and on-going development of > org mode. > > While I would be happy to help with this, I think the initial content at > least needs to come from current key maintainers and if possible, some > input from Carsten would be good. Fully agreed. Input from old timers will be precious, too. I will work on this as we are transitioning to the new maintainance team. Also, I commit to achieve this transition by August, 1st. This may seem a bit far away, but there is really no rush here, and I want to ensure we have a smooth transition.
Plea for reviews/action on my Patches
Hi Everyone, This is a very me-centric email, but I've got a collection patches that have received little attention (1 of the past 9 patches I've submitted has been reviewed by a core contributor, 6 have zero replies). I care about them, and I think it would be good if they were looked at. So, I'm going to list those patches here, organised by topic. * Rendering in/of Org buffers - [PATCH] Fontification for inline src blocks (Mar 31) https://orgmode.org/list/87pmzf4bd0@gmail.com/ - [PATCH] Add font-lock rule for inline export snippets (Mar 31) https://orgmode.org/list/87im57fh8j@gmail.com/ - [PATCH] Refresh inline plotted images, org-plot (Apr 24) https://orgmode.org/list/87r1j0mg56@gmail.com/ * Documentation - [PATCH] Improve documentation of #+startup keyword (Mar 19) https://orgmode.org/list/874kh72vrl@gmail.com/ * Exporting - [PATCH] tweaks to ox-html style (Jan 20) https://orgmode.org/list/87turbj2nu@gmail.com/ This is commented on a fair bit, but unresolved. If the CTAGS stuff is contentious I'd rather that's just ignored and the rest is merged. - [PATCH] Use tags for SVGs (Apr 7) https://orgmode.org/list/87k0pemj6d@gmail.com/ - [PATCH] avoid loading major modes when exporting to file (Mar 31) https://orgmode.org/list/87lfa3fips@gmail.com/ - [PATCH] Wrap LaTeX snippets in $$ with markdown export (Apr 1) https://orgmode.org/list/87ft0bff7q@gmail.com/ I also have some more patches lined up, and I'd rather my number of unresolved patches stayed out of the double digits. -- Timothy
[PATCH] Babel: remove LaTeX environment -type #+results
Hi All, I think there's potential for some really nice experiences leveraging Org's latex rendering in combination with some languages' symbolic maths ability. This is /very nearly/ already supported, `org-babel-result-end' just needs to be tweaked to also remove LaTeX environment -type #+results. This is what I'd like to make possible: -- Timothy >From e7e7eb698883348eeb404c0bc58ed7aed52344c4 Mon Sep 17 00:00:00 2001 From: TEC Date: Sun, 25 Apr 2021 16:51:15 +0800 Subject: [PATCH] ob-core: Remove LaTeX environment #+results type * lisp/ob-core.el (org-babel-result-end): By adding latex-enviroment to the possible results types, a much richer experience is possible for backends that can produce LaTeX-formatted maths as their results (for example: Calc, Julia with Latexify, Python with SymPy, Octave with symbolic). This is superior to a LaTeX export block as LaTeX environments can be (1) rendered inline, and (2) better used in non-LaTeX export formats (e.g. HTML with MathJax). Without this, backends can output a LaTeX environment, but new results will be added in front instead of replacing the environment. --- lisp/ob-core.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 2e78ac3e6..12f67a8e2 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -2559,8 +2559,9 @@ (defun org-babel-result-end () (let ((element (org-element-at-point))) (if (memq (org-element-type element) ;; Possible results types. - '(drawer example-block export-block fixed-width item - plain-list special-block src-block table)) + '(drawer example-block export-block fixed-width + special-block src-block item plain-list table + latex-environment)) (save-excursion (goto-char (min (point-max) ;for narrowed buffers (org-element-property :end element))) -- 2.31.1
Help with reproducing bugs reported on this list (was: Concerns about community contributor support)
Hi all, we are looking for someone to take charge of a very important task: reproducing bugs reported on this list. Bug reports generally starts with "Bug: " in the email subject, even if some emails directly sent to the list may omit this keyword. Once you confirm a bug, you would need to reply to it and to add a header to your email like this: X-Woof-Bug: confirmed And your job is done. This will make the bug appear on https://updates.orgmode.org which makes it easy for contributors to know that their time is correctly used when they want to contribute with fixes. This is a very important task: anyone can contribute to it with the same process, but having someone in charge would certain help. This human "bug validator" will join the contributor stewards, as discussed here: https://orgmode.org/list/87v98b0yvm@gnu.org/ Thanks! PS: Please don't use this thread to discuss bug reporting tools and processes: we need human power more than a change of tooling.
Re: [PATCH] ob-java: Allow import to end with asterisk
On Sat, Apr 24, 2021 at 11:44 PM Timothy wrote: > > This was not marked as applied on updates.orgmode.org. > Doing so with the X-Woof-Patch header. > > ian martins writes: > > > Thanks. And thanks for taking the time to fix issues that you find. It > > continues to improve because of your contributions. > > The patch looks good. Applied. > Thanks for fixing this. I re-read the woof documentation and realized I needed to put "Applied" at the beginning of the line. if anyone is curious, to save you a search, the doc is here: https://github.com/bzg/woof#basic-usage
Re: link syntax fixing bug?
On 21/03/2021 05:46, Samuel Wales wrote:
the issue is that when i click on google, the space before "hi" does
not show up in the earch box. ergo, different results.
*** should be orig
[[http://www.google.com/search?q=%7E%22retroactive%20whatever%22%20%22hi%22][retro
original]]
*** should be fixed, is not?
[[http://www.google.com/search?q=~"retroactive whatever" "hi"][retro
original]]
Reading Kyle's response, I have realized that you might have unsafe URL
handler. I hope, I am wrong. To factor out some excessively smart JS, I
tried
firefox 'http:/127.0.0.1/search?q=~"retroactive whatever" "hi"'
and I got expected result in the URL bar. With the following test script
"fake-browser"
#!/bin/sh
exec kdialog --title "Fake Browser" --msgbox "Args $#: '$*'"
and a some customization:
'(browse-url-browser-function (quote browse-url-generic))
'(browse-url-generic-program "fake-browser")
I did not get any white space problem for the following link
[[http:/127.0.0.1/search?q=~"retroactive whatever" "hi"][retro-original]]
So neither passing URL to handler nor handling URL by firefox cause a
problem.
However protecting spaces in URLs from `org-fill-paragraph' function was
mentioned in mail list archive as one of the reasons to introduce
second pass of percent encoding. Double percent encoding is clearly a
problem since there is no way to reliably guess whether second pass was
applied or not. My impression, it were not a problem if just "offensive"
for org symbols "][ \" would be replaced by percent-encoded equivalent
in URLs. Maybe I just missed cases when mixing percent-encoded and
unicode characters leads to some problem, so I believe it is safe. My
hypotesis is that replacing just "[", "]", and "\" to percent encoded
equivalent in any URL does not cause any issue, web-servers are able to
decode them (selective encoding, not second pass for whole URL). Maybe
file links on windows is an exception.
My opinion is that `org-lint' gives false positives for URLs with
percent encoded characters. They are rather wide spread e.g. in search
queries.
*** [[https://orgmode.org/Changes.html][Org mode for Emacs – Release notes]]
The following function will help switching your links to the new syntax:
(defun org-update-link-syntax (&optional no-query)
...
(while (re-search-forward "\\[\\[[^]]*?%\\(?:2[05]\\|5[BD]\\)" nil t)
I believe, the logic at least for space symbol (%20) should be more
sophisticated. Maybe decoding of URLs with "%20" should be performed
only if decoded URL still contains percent-encoded characters. Maybe
decoding should be prevented if any of characters mandatory for percent
encoding ("[]?/", etc) is present besides percent-encoded sequences.
Maybe the only way is interactive comparison of original and decoded URL.
I do not think that particular example you provided
http://www.google.com/search?q=%7E%22retroactive%20whatever%22%20%22hi%22
needs decoding. It is not human friendly but it is more safe and quite
wide spread. On the other hand, decoded variant should not lead to any
problem as well unless something is misconfigured
[[http://www.google.com/search?q=~"retroactive whatever" "hi"][retro
original]]
Re: Please help by becoming a maintainer for an Org Babel file
Hi Nick, sorry for the late reply. Nick Savage writes: > I'm willing to volunteer to maintain ob-sqlite.el. I think like Andy, > I have some work to do to get up to speed on my elisp but I'm > comfortable enough with sqlite itself. I added you as the ob-sqlite.el maintainer in 55ef8e858. I'll write to you private to set an account on code.orgmode.org. Thanks!
Re: Please help by becoming a maintainer for an Org Babel file
Hi Andy, Andy Klock writes: > Can I throw my hat in to help maintain ob-sql.el ? Are you still considering it? That would help, and it comes with no obligation, since everyone here is on best-effort mode.
Re: [PATCH] optimize org-refile-get-targets
Hi Maxim, Maxim Nikulin writes: > For a while, improvement is significant, so I am attaching the patch > that should make jumps using org-goto or org-refile faster. I hope, I > have not broken anything. Thanks a lot for the patch. Are you still using it? Did anyone tested it?
Re: PDF manual
Hi Frederic, Frederic Santos writes: > It looks like the PDF manual for Org mode is no longer available > (https://www.gnu.org/software/emacs/manual/org.html): only the html > version is online now. > Do you know why? And will the PDF version be back someday? The PDF manual is still here: https://orgmode.org/org.pdf It is linked at the bottom of this page: https://orgmode.org/quickstart.html Perhaps we could make this PDF version and the single HTML page version more visible on the website, let us know if you come up with a good idea. Thanks!
Re: [PATCH] Async session eval (2nd attempt)
I gave this a try and it works for me. One thing I noticed is that if you
run a call asynchronously, the final result ends up under the source block
instead of the call. In the example below both RESULTS were written after
I ran the call.
#+name: test-call
#+begin_src python :results output
import time
time.sleep(5)
print("done")
#+end_src
#+RESULTS: test-call
: done
#+call: test-call() :session :async
#+RESULTS:
: 70e844920752b3411170716dc450c50f
On Sun, Apr 25, 2021 at 3:06 AM Jack Kamm wrote:
> Hi Timothy,
>
> > This is moving at a glacial pace, but I'd love to see this merged ---
> > there's clearly a lot of interest in this from the community if not
> > within this mailing list (ob-async which is more limited has 250 stars
> > on GitHub).
>
> Yes, this has taken far too long -- sorry about that.
>
> There have been a few things going on in my life recently, among them a
> job change. I am in the process of trying to get my FSF copyright forms
> approved at my new job. I think this will eventually happen, but the
> process is moving slowly.
>
> My last update on this thread was shortly before changing jobs, and I
> decided not to merge until I was sure I'd be able to stick around to
> maintain it.
>
> If someone is willing to apply the final tweaks and help with maintenance
> of this functionality, please go ahead and merge this in. Otherwise, I'll
> merge this as soon as I've got my paperwork approved and am back in action.
>
> Jack
>
>
Re: org-cite: make 'suppress-author' a citation 'style'
On Sun, Apr 25, 2021 at 1:55 AM András Simonyi wrote: > > Dear All, > > my 2c on this issue: citeproc-el supports per cite author suppression > under the hood, but citeproc-org always maps "suppress author" mode > citations to suppressing only the first cite, because my impression > was also that this is a citation-level option. How would you deal with these? #+begin_example [cite/-:@doe20; @doe21] [cite/-:@doe20; see also @smith19] [cite/text:@doe20; see also @smith19] #+end_example My thought is you want to treat the author of the first listed cite as suppressed, or placed in-text in the last case, but that you wouldn't touch the other author? Bruce
Re: [tip] search this mailing list with helm-surfraw
Bastien, > I hope this is not confusing. no, that's perfectly clear. thanks. Greg
Re: [PATCH] Babel: remove LaTeX environment -type #+results
Timothy, interesting. would this show up in #+RESULTS blocks? in (heaven forbid!) #+BEGIN_SRC blocks? cheers, Greg
Re: bug#7506: Replacement for 'htmlize-region-for-past using htmlfontify?
Hi Stefan, Stefan Kangas writes: > The above feature request for `org-html-htmlize-region-for-paste' has > been sitting in the Emacs bug tracker for 10 years. It seems like no > one on our side has taken an interest in it. Yes, this is quite a long-standing issue, and I for one did not have enough interest in fixing this (I still think this needs fixing.) I'm adding a call for help through https://updates.orgmode.org, just in case. Thanks
Re: bug#7506: Replacement for 'htmlize-region-for-past using htmlfontify?
Bastien writes: > Hi Stefan, > > Stefan Kangas writes: > >> The above feature request for `org-html-htmlize-region-for-paste' has >> been sitting in the Emacs bug tracker for 10 years. It seems like no >> one on our side has taken an interest in it. > > Yes, this is quite a long-standing issue, and I for one did not have > enough interest in fixing this (I still think this needs fixing.) > > I'm adding a call for help through https://updates.orgmode.org, just > in case. > > Thanks It might be worth noting that I have a replacement for htmlize on the back-burner that I think would be worth using with Org anyway for LaTeX/PDF exports at some point: https://github.com/tecosaur/engrave-faces Perhaps it will have the same issue, but on the off-chance it's of some help, there it is :) -- Timothy
Re: [PATCH] Re: Any reason not to generate my own custom ID value (NOT CUSTOM_ID)?
Hi Ihor, Ihor Radchenko writes: >> Thanks, but you forgot the note to etc/ORG-NEWS announcing the new >> option la mission. > > Do I miss something or the need to add ORG-NEWS entry is not mentioned > in the contribution page? I updated https://orgmode.org/worg/org-contribute.html to mention etc/ORG-NEWS, thanks.
Re: Bug: org-agenda-undo does not work with repeated tasks [9.4]
Hi Warren, Warren Lynn writes: > With org-mode 9.4, if you have a repeated task like this: > > * TODO My weekly task > SCHEDULED: <2020-10-14 Wed +1w> > > In daily agenda, if you mark the task done, which will cause the > above to change into: > > * TODO My weekly task > SCHEDULED: <2020-10-21 Wed +1w> > :PROPERTIES: > :LAST_REPEAT: [2020-10-14 Wed 11:45] > :END: > :LOGBOOK: > - State "DONE" from "TODO" [2020-10-14 Wed 11:45] > :END: > > But then if you run "org-agenda-undo" immediately in the agenda > buffer, the task did not revert back to the original, instead, only > the "LOGBOOK" part is gone, so it becomes this: > > * TODO My weekly task > SCHEDULED: <2020-10-21 Wed +1w> > :PROPERTIES: > :LAST_REPEAT: [2020-10-14 Wed 11:45] > :END: > > I don't think that's what people would expect from "org-agenda-undo", > so it seems a bug to me. > > This bug is also in orgmode 6.3.7, so likely has been there for a > long time. > > Thanks for looking into this. I cannot look into this right now, but I confirm the bug still exists in master. Thanks for reporting it.
Re: [PATCH] Async session eval (2nd attempt)
Kyle Meyer writes: >> I also have an async implementation for ob-R that's ready after this is >> merged :) > > It's a bit disappointing that only one babel user has tested this out > and provided feedback, but please feel free to merge this whenever you > think it's ready. Strong +1 -- and thanks!
Re: [PATCH] optimize org-refile-get-targets
On 25/04/2021 19:25, Bastien wrote: Are you still using it? Did anyone tested it? I realized that I break cache a bit, so the patch should not be applied in the current form. I have an idea how to fix it but I have found more problems around (independent of my patch). I did not worried since the patch did not appeared on updates.orgmode.org (I guess, due to "git diff" instead of "git format patch".) Cache key is regexp. With my patch, level and max-level options share the same regexp. I think, cache for both options could be generated as for max-level and filtered in the case of "level". It may simplify the code. I would be grateful for other comments. I have not realized how to reduce number of regexps inside the loop without duplication of some regegexps. I have seen a statement that cache for compiled regular expressions in emacs is rather small so several patterns used on each cycle is enough to make it useless with significant performance penalty. Other issues: - Indirect buffer created with C-x 4 c does not reuse cache created for the main buffer, so first call in new buffer have to generate its own cache. - C-u C-c C-j promises to use headings from the buffer, but in the case of subtree indirect buffer, headings are not filtered to the narrowed part. - I have not solved the problem with default option for `org-refile' and `org-goto'. Maybe more detailed structure should be stored in history and formatted accordingly to current option at the moment of invocation.
Re: stability of toc links
On Wednesday, 21 April 2021 18:24:27 CEST Nicolas Goaziou wrote: > In particular, I'm not sure to understand how one system can generate an > ID based on the heading content and still limit itself to alphanumeric > characters. For example, what ID are generated with the following > document? > > --8<---cut here---start->8--- > * こんにちは > * ｺﾝﾆﾁﾊ > --8<---cut here---end--->8--- For what it's worth, DNS servers faces a similar problem where host names can contain any unicode character, but DNS servers support only ascii char. In DNS cases, this is worked around using punycode. (1) Using the example above, a host named "こんにちは.example" is converted to "xn--28j2a3ar1p.example". Punycode is available in Emacs through libidn (2) HTH (1) https://dnsquery.org/punycode (2) https://www.gnu.org/software/libidn/
Re: Bug: org-caputure fails, sometimes [9.3.7 (release_9.3.7-705-gea9463 @ /home/oub/emacs/site-lisp/packages/org/)]
> Uwe Brauer writes: > With this backtrace alone (which involves org-capture catching the > internal error), I think it's going to be hard for anyone to guess > what's going on here. It sounds like once you encounter this error, > subsequent calls reliably trigger it. Next time you run into it, I'd > suggest re-evaluating org-capture to something like below to hopefully > see a more informative backtrace. > diff --git a/lisp/org-capture.el b/lisp/org-capture.el > index 831c3e1f4..b20124ced 100644 > --- a/lisp/org-capture.el > +++ b/lisp/org-capture.el > @@ -693,9 +693,7 @@ (defun org-capture (&optional goto keys) > (string-prefix-p "CAPTURE-" (buffer-name))) > (kill-buffer (current-buffer))) > (set-window-configuration (org-capture-get :return-to-wconf)) > - (error "Capture template `%s': %s" > -(org-capture-get :key) > -(error-message-string error > + (signal (car error) (cdr error >(when (and (derived-mode-p 'org-mode) (org-capture-get :clock-in)) > (condition-case nil > (progn Even with your applied patch I don't obtain any more useful backtrace I will try to debug the function now. smime.p7s Description: S/MIME cryptographic signature
Re: Bug: org-caputure fails, sometimes [9.3.7 (release_9.3.7-705-gea9463 @ /home/oub/emacs/site-lisp/packages/org/)]
> Uwe Brauer writes:
> With this backtrace alone (which involves org-capture catching the
> internal error), I think it's going to be hard for anyone to guess
> what's going on here. It sounds like once you encounter this error,
> subsequent calls reliably trigger it. Next time you run into it, I'd
> suggest re-evaluating org-capture to something like below to hopefully
> see a more informative backtrace.
> diff --git a/lisp/org-capture.el b/lisp/org-capture.el
> index 831c3e1f4..b20124ced 100644
> --- a/lisp/org-capture.el
> +++ b/lisp/org-capture.el
> @@ -693,9 +693,7 @@ (defun org-capture (&optional goto keys)
> (string-prefix-p "CAPTURE-" (buffer-name)))
> (kill-buffer (current-buffer)))
> (set-window-configuration (org-capture-get :return-to-wconf))
> - (error "Capture template `%s': %s"
> -(org-capture-get :key)
> -(error-message-string error
> + (signal (car error) (cdr error
>(when (and (derived-mode-p 'org-mode) (org-capture-get :clock-in))
> (condition-case nil
> (progn
I debugged the function, the error appears in that line
(signal (car error) (cdr error
Which is not useful.
The funny thing is that the capture is saved correctly in the file
here is the template
("mu" "Stat+Num:Exercises English"
table-line (file+headline
"~/ALLES/HGs/tex/vorlesungen/HGQuim-Num-Estad/Lista-Alumnos/2021/GroupE/exercises-groupE-21.org"
"Exercise Group-E")
"| %:fromname|%:fromaddress |%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |
%a|%:date | " :prepend t
)
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] Babel: remove LaTeX environment -type #+results
Greg Minshall writes:
> Timothy,
>
> interesting. would this show up in #+RESULTS blocks? in (heaven
> forbid!) #+BEGIN_SRC blocks?
>
> cheers, Greg
The screenshot where it shows up is from the following Org buffer
(manually constructed for the example):
#+begin_src julia
[1 2; 3 4]
#+end_src
#+RESULTS:
\begin{equation}
\left[
\begin{array}{cc}
1 & 2 \\
3 & 4 \\
\end{array}
\right]
\end{equation}
#+begin_src julia
using Symbolics
@variables t
2^sin(t) + cos(t)/t
#+end_src
#+RESULTS:
\begin{equation}
\frac{\cos\left( t \right)}{t} + 2^{\sin\left( t \right)}
\end{equation}
The rendering is just done by `org-latex-preview'.
Hope that clears things up.
--
Timothy
Re: org-cite: make 'suppress-author' a citation 'style'
Dear All, On Sun, 25 Apr 2021 at 14:50, Bruce D'Arcus wrote: > How would you deal with these? > > #+begin_example > [cite/-:@doe20; @doe21] > [cite/-:@doe20; see also @smith19] > [cite/text:@doe20; see also @smith19] > #+end_example > > My thought is you want to treat the author of the first listed cite as > suppressed, or placed in-text in the last case, but that you wouldn't > touch the other author? yes, exactly -- since it's difficult to see (at least for me) how the context could supply the author information for the subsequent cites. best regards, András
Re: org-cite: make 'suppress-author' a citation 'style'
On Sun, Apr 25, 2021 at 3:48 PM András Simonyi wrote: > > Dear All, > > On Sun, 25 Apr 2021 at 14:50, Bruce D'Arcus wrote: > > How would you deal with these? > > > > #+begin_example > > [cite/-:@doe20; @doe21] > > [cite/-:@doe20; see also @smith19] > > [cite/text:@doe20; see also @smith19] > > #+end_example > > > > My thought is you want to treat the author of the first listed cite as > > suppressed, or placed in-text in the last case, but that you wouldn't > > touch the other author? > > yes, exactly -- since it's difficult to see (at least for me) how the > context could supply the author information for the subsequent cites. So the output for the first one would be: (2020, 2021) ..., and not: (2020, Doe 2021) As in, you would suppress the author not on the first cite (what you wrote in the original reply), but the author of the first cite? To me, that's the only wrinkle of having this a citation-level style; that a processor would need to be smart enough to handle cases like that, for output styles that require it. But otherwise it's easier and more efficient for the user. Bruce
Re: Backwards compatability
On org-drill, I think someone has already taken it up here a while ago: https://gitlab.com/phillord/org-drill On 4/25/21 12:39 AM, Bastien wrote: Hi Bithov, we *do* care a lot about backward compatibility*. We cannot make a strong commitment for contributed libraries and external ones, though, otherwise Org would not evolve. org-drill.el was removed from the contrib/ directory 1 year ago: https://code.orgmode.org/bzg/org-mode/commit/2c8e8b4a Perhaps you can try to find someone who wants to maintain it. * https://bzg.fr/en/the-software-maintainers-pledge/
Re: (Not so) Short note about citations in Org
Hi everyone, great to see that there's been so much progress since this issue has last been discussed! Looks really impressive so far. Two comments/questions: - I think it should be possible to use some markup in prefixes and suffixes. - Will this proposal allow multiple bibliographies? I think that's been discussed last year or so. Best, Denis Am 22.04.2021 um 01:34 schrieb Nicolas Goaziou: Hello, I just rebased "wip-cite-new" branch, which now includes citation syntax, and an interface between external citation processors and the rest of Org. I'll throw in a demo at the end of this message. TL;DR: search for "Demo time". As a reminder, the full citation syntax is [cite/style:common prefix ;prefix -@key suffix; ... ; common suffix] Everything is optional, except the brackets, "cite" and the colon. Also the citation must contain at least a key. So its minimal form is: [cite:@key] or its "suppress author" variant: [cite:-@key] A noteworthy difference with the last merge is that I removed the opportunity to add some Org syntax (emphasis, sub/superscript…) in prefixes or suffixes. It makes the code a bit simpler. Of course, I'm open to discussion about this change. The syntax also introduces three keywords (square brackets are for optional arguments): #+bibliography: filename #+print_bibliography: [style] #+cite_export: backend-name [bibliography-style] [citation-style] Now, the real novelty is the new "oc.el" library, which is an API to operate simply on citations. I paste here its commentary section. This library provides tooling to handle citations in Org, e.g, follow, fontify, and export them, respectively called "follow", "activate" and "export" capabilities. Libraries responsible for providing some, or all, of these capabilities are called "citation processors". Such processors are defined using `org-cite-register-processor'. Using this function, it is possible, in addition to giving it a name, to attach functions associated to capabilities. As such, a processor handling citation export must set the `:export-citation' property to an appropriate function. Likewise, "activate" capability require an appropriate `:activate' property, and, unsurprisingly, "follow" capability implies `:follow' property. As a user, the first thing to do is setting a bibliography, either globally with `org-cite-global-bibliography', or locally using one ore more "bibliography" keywords. Then one can select any registered processor for each capability by providing a processor name to the variables `org-cite-activate-processor' and `org-cite-follow-processor'. The "export" capability is slightly more involved as one need to select the processor providing it, but may also provide a default style for citations and bibliography. These three parameters, or triplet, can be set in `org-cite-export-processor' variable, or in a document, through the "cite_export" keyword. Eventually, this library provides some tools, mainly targeted at processor implementors. Most are export-specific and are located in the "Tools only available during export" section. The few others can be used directly from an Org buffer, or operate on processors. See "Generic tools" section. There are two points of view to consider here. As a user, as stated above, you first need to provide a bibliography, for all documents using the `org-cite-global-bibliography' variable, or for a single document (or a set of documents, using "setupfile" keyword) with #+bibliography: one-file.bib #+bibliography: another-file.ext #+bibliography: "some file with spaces" You can use both the variable and the keywords, in which case files are _accumulated_ in the list. Then when you (require 'org-cite-something) the "oc-something.el" library, in addition to possibly many other tools, registers a "citation processor", for example `something'. That processor may operate on any of the three entry points "activate", "follow", or "export". If you are not sure about which one it supports, you may inspect the processor with, e.g., (org-cite-processor-has-capability-p 'something 'follow) If this is non-nil, you can set `org-cite-follow-processor' to `something'. Once done, calling `org-open-at-point' on a citation starts whatever action the processor defined. If the variable is nil, nothing happens. If you need to use a different processor for a given document, consider using file local variables. Likewise, you can fontify citations according to a given processor using `org-cite-activate-processor'. This time, however, Org provides some fontification even when the variable is nil. The default set-up merely applies new `org-cite' and `org-cite-key' faces on citations. The "export" capability introduces the concept of "style", which is an _indi
Re: Concerns about community contributor support
As a new contributor, I wanted to add my two cents. I've submitted a minor amount of patches (somewhere between 1 and 3, I can't remember exactly), and I feel that the other problems you raise, primarily the first one, are obstacles towards that though. Patches like that are obviously minor, since they aren't fixing bugs, so they're low priority. That drags out the process though, and it's a little discouraging to submit patches that don't receive responses, and make me less eager to submit more.For example, I submitted a tiny refactoring patch last month that hasn't received an answer yet. I'm not looking for special treatment of course, and think that review of patches is super important (especially for a new contributor like me) I think that the solutions you raise are great starts. I feel like the documentation that I've used has been pretty accurate, but it could always be better, and someone who is the point person for dealing with people like me would be a good idea. I would not like to volunteer for that myself. I don't feel comfortable enough with my abilities, or my experience with the community, to able to help others or give reasonable answers for patches other than something like "yes, I've seen this". I will try to help out more with verifying bugs though. On a side note, I'd like some guidance though on whether or not the community is interested in a refactoring project (done in pieces of course). I'm wondering if I should be attempting to submit minor (or larger) patches moving things around to make it easier to maintain, if there is a way to go about this (since submitting a bunch at a time, breaking them up, etc), certain things I should focus on or ignore, etc. I haven't done much since that mostly because work has consumed my free time, but I'm going to have a significant amount more free time starting in the next week or so, so I'm looking for somewhere to direct my energies! On 4/25/21 12:30 AM, Bastien wrote: Dear Timothy, thanks for raising this points so carefully, they are important. I see three distinct problems: 1. The lack of response and/or follow-up when people contribute by sending bug reports or patches on the list. 2. The lack of maintainance on documenting the contribution process and the correct expectations for future contributors. 3. The inherent difficulty to move the Org codebase forward. I won't comment on (3). For (1) and (2), I suggest appointing a "contributor steward" with these responsibilities: 1. Maintain updates.orgmode.org (i.e. make sure it is accurate.) 2. Maintain the documentation for contributors. 3. Help contributors enhancing their patches. 4. Try to reproduce bugs (and confirm them for updates.orgmode.org) 5. Make sure patch contributors are not left with no answer. You started (1), which is really appreciated. Tim and others mentioned (2), and that's certainly needed too. (3) has historically been the role of the maintainer and of the core contributors, but helping with this is very welcome: knowing the doc at https://orgmode.org/worg/org-contribute.html by heart, educating contributors on the commit messages, etc. This all helps. (4) is perhaps the most daunting task: I even think we could have someone only dedicated to this very important task. Just count the number of times Nicolas says "I cannot reproduce this." Each time, there is a real bug that is *not* fixed... (5) is not about systematically welcome patch submitters with a message (that would be annoying) but to monitor updates.orgmode.org and decide what to do with a patch that didn't receive feedback: either say thanks and ping the list for why you think the patch deserves more attention, or thanks and dismiss the patch, or another answer. What do you think? Would you be willing to take this role? If not, that's perfectly okay, I'll send a call for help. Thanks,
Re: Concerns about community contributor support
Bastien writes: > Hi Tim, > > Tim Cross writes: > >> I agree and am willing to help if I can. > > Great! Would you agree to be "officially" appointed to this role, > with Timothy? I put quotes on "officially": when moving toward the > new maintainance team, I'd like to list maintainers and their roles, > including the "contributor stewards". If you prefer not to publicly > appear but still work on this, that's perfectly okay too, of course. > Yes, but with some caveats. As may have already been picked up by some, I'm extremely conservative regarding the addition of new features and enhancements to org mode. I have considerable concern regarding both the performance and maintainability of the mode and worry about the increasing complexity in options, performance impact from increasingly complex font locking just to have more 'eye candy' at the cost of sluggish behaviour for large files and striking the right balance between the 'richness' of org file functionality and consistency in exporters or source block handling. I really would hate to see org mode end up like MS word with 90% of users only using 10% of the functionality with 90% unused functionality just becoming a burden to maintainers. For these reasons, I'm probably not the best person to assist with the review and guidance for patches aimed at adding/extending functionality. However, I would be happy to - Assist in trying to reproduce and confirm bugs - Assist in extracting additional information and providing guidance/clarification for bug reports - Assist with documentation - Provide some guidance on patches, particularly bug fixes. My time availability can vary greatly depending on work. Also, as a blind user, my ability to reproduce bugs can sometimes be hampered by the necessity of running Emacspeak in conjunction with org mode (they can sometimes interfere with each other). However, apart from that, more than happy to help where I can, so if your happy, sign me up! >> One thing I do think would be helpful, particularly for documentation on >> maintenance of org mode, would be a clear outline of project goals and >> philosophy. Some of this would be 'concrete' statements, such as the >> minimum supported Emacs version, size of contribution and requirements >> to sign FSF copyright assignment paperwork, inclusion of acceptance >> tests, documentation, maintenance of backwards compatibility, API >> stability etc. Other parts would be more 'fuzzy' guidelines, such as >> avoiding complexity and 'blow out' in options/arguments, balancing >> features and maintainability, what should become part of org core and >> what should be in contributions or a completely separate add on package >> and what guidelines are used in assessing extensions/enhancements for >> inclusion etc. >> >> It will be challenging to define this as there are a wide diversity of >> views and priorities amongst the community. However, I think it would be >> an overall benefit for both the community and on-going development of >> org mode. >> >> While I would be happy to help with this, I think the initial content at >> least needs to come from current key maintainers and if possible, some >> input from Carsten would be good. > > Fully agreed. Input from old timers will be precious, too. I will > work on this as we are transitioning to the new maintainance team. > > Also, I commit to achieve this transition by August, 1st. This may > seem a bit far away, but there is really no rush here, and I want to > ensure we have a smooth transition. All your efforts greatly appreciated. It is a lot of effort and herding cats often takes a lot longer then anticipated! -- Tim Cross
Re: Concerns about community contributor support
Hi Tim, thank you very much for your detailed answer. Tim Cross writes: > Yes, but with some caveats. Thank you! > For these reasons, I'm probably not the best person to assist with the > review and guidance for patches aimed at adding/extending functionality. The role of a "contributor steward" is to address the issues Timothy originally raised about contributors not receiving answers when they take the time to send a patch or a bug report, it is not about making technical decisions. Of course, your advice as a long-time user on these decisions is always very welcome. > However, I would be happy to > > - Assist in trying to reproduce and confirm bugs > - Assist in extracting additional information and providing > guidance/clarification for bug reports > - Assist with documentation > - Provide some guidance on patches, particularly bug fixes. That's exactly what is badly needed to discharge core maintainers from routine tasks and to let them focus on technical stuff. This has basically been my role in my early years of maintainership: making sure to keep this list as welcoming as possible, to continue to attract new people with new ideas (and new bug report). This is a somewhat undervalued role, but a deeply necessary one -- so again, thanks for helping here. > My time availability can vary greatly depending on work. That's no problem. We have a team of Tim's :) > Also, as a > blind user, my ability to reproduce bugs can sometimes be hampered by > the necessity of running Emacspeak in conjunction with org mode (they > can sometimes interfere with each other). However, apart from that, more > than happy to help where I can, so if your happy, sign me up! If the task becomes too much for you, you can always say that you won't be available for a while. Thanks!
Re: Concerns about community contributor support
Bastien writes: > Hi Tim, > > thank you very much for your detailed answer. > > Tim Cross writes: > >> Yes, but with some caveats. > > Thank you! > >> For these reasons, I'm probably not the best person to assist with the >> review and guidance for patches aimed at adding/extending functionality. > > The role of a "contributor steward" is to address the issues Timothy > originally raised about contributors not receiving answers when they > take the time to send a patch or a bug report, it is not about making > technical decisions. Of course, your advice as a long-time user on > these decisions is always very welcome. > >> However, I would be happy to >> >> - Assist in trying to reproduce and confirm bugs >> - Assist in extracting additional information and providing >> guidance/clarification for bug reports >> - Assist with documentation >> - Provide some guidance on patches, particularly bug fixes. > > That's exactly what is badly needed to discharge core maintainers from > routine tasks and to let them focus on technical stuff. > > This has basically been my role in my early years of maintainership: > making sure to keep this list as welcoming as possible, to continue to > attract new people with new ideas (and new bug report). This is a > somewhat undervalued role, but a deeply necessary one -- so again, > thanks for helping here. > >> My time availability can vary greatly depending on work. > > That's no problem. We have a team of Tim's :) > >> Also, as a >> blind user, my ability to reproduce bugs can sometimes be hampered by >> the necessity of running Emacspeak in conjunction with org mode (they >> can sometimes interfere with each other). However, apart from that, more >> than happy to help where I can, so if your happy, sign me up! > > If the task becomes too much for you, you can always say that you > won't be available for a while. > > Thanks! OK, consider me 'singed up". Today I will see if I can re-jig my mail system to make it easier to track and respond. As Timothy seems to be doing a fine job 'catching up' with what is already on updates.orgmode, I'll leave that alone and will focus on responding to new bug reports, patches etc which come through the list. I'll also setup a 'clean' virtual image so that I have a vanilla, clean Emacs config I can use for evaluating/reproducing bugs (current emacs stable 27.2). . What is our position with bugs which can only be reproduced in the current development version of Emacs? I'd expect we track them, but focus more on Emacs stable given that dev is a moving target and any bugs may be resolved by later changes in Emacs? Finally, is it also necessary to monitor org bugs reported to the emacs bug tracker or are they sent on to the emacs-orgmode list via some other process? (I currently do monitor emacs-devel but not the bug tracker). -- Tim Cross
Re: [PATCH] ob-java: Allow import to end with asterisk
Hi Ian, ian martins writes: > Thanks for fixing this. I re-read the woof documentation and realized > I needed to put "Applied" at the beginning of the line. Yes - and also add a "X-Woof-Patch: applied" header in your reply.
Re: [PATCH] Refresh inline plotted images
Hi Timothy, Timothy writes: > +(defun org-plot/redisplay-img-in-buffer (img-file) > + "Find any overlays for IMG-FILE in the current Org buffer, and refresh > them." I guess M-x eldoc RET will choke because the first line of a docstring should shorter. Other than this nitpick, please feel free to commit, as you are org-plot.el maintainer. Thanks
