Re: issue tracker?
On Wed, May 20, 2020 at 10:12:38PM -0500, James R Miller wrote: > > I think issue tracking could happen on a mailing list. If you tag an > > issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of > > the OPEN: issues to the list periodically (in theory). > > Something like that would be nice; the bot could even store such info in an > org file that could be exported the html occasionally too. I think recommended standardized formats for submissions is a great idea. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
[PATCH] ob-core: Display warning on failure to read results
Greg Minshall writes: > hi. i'm running R code from an org mode file. i was having a problem > where a code block that *was* returning a value result was not returning > the results into the buffer. > > (after long head-scratching) this appears to be because my code was > returning more lines of results than org-table-convert-region-max-lines. > > but, i was *not* seeing any error message, nothing to indicate to me why > i was getting no results. in the test program below, when trying to > return more than 1000 lines, one sees, in the echo area, "Code block > returned no value". if you go to *Messages*, there you can see an error > message. Thanks for the report and for providing a minimal example. > i think somehow org/babel should make sure the user sees what limitation > s/he is running into. I agree. Here's my suggestion. -- >8 -- Subject: [PATCH] ob-core: Display warning on failure to read results * lisp/ob-core.el (org-babel-import-elisp-from-file): Show handled errors with display-warning rather than a message because the latter is quickly overridden by subsequent messages, making it difficult if not impossible for the user to spot. The scope of the save-window-excursion call would need to be reduced for the display-warning buffer to be shown, but nothing appears to change the window configuration, so just drop the save-window-excursion call. Reported-by: Greg Minshall <2449663.1588516...@apollo2.minshall.org> --- lisp/ob-core.el | 39 +-- 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index ee0dc3d72..2a75ae734 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -2941,24 +2941,27 @@ (defun org-babel--string-to-number (string) (defun org-babel-import-elisp-from-file (file-name separator) "Read the results located at FILE-NAME into an elisp table. If the table is trivial, then return it as a scalar." - (save-window-excursion -(let ((result - (with-temp-buffer -(condition-case err -(progn - (org-table-import file-name separator) - (delete-file file-name) - (delq nil -(mapcar (lambda (row) - (and (not (eq row 'hline)) - (mapcar #'org-babel-string-read row))) -(org-table-to-lisp - (error (message "Error reading results: %s" err) nil) - (pcase result - (`((,scalar)) scalar) - (`((,_ ,_ . ,_)) result) - (`(,scalar) scalar) - (_ result) + (let ((result +(with-temp-buffer + (condition-case err + (progn +(org-table-import file-name separator) +(delete-file file-name) +(delq nil + (mapcar (lambda (row) +(and (not (eq row 'hline)) + (mapcar #'org-babel-string-read row))) + (org-table-to-lisp +(error + (display-warning 'org-babel + (format "Error reading results: %S" err) + :error) + nil) +(pcase result + (`((,scalar)) scalar) + (`((,_ ,_ . ,_)) result) + (`(,scalar) scalar) + (_ result (defun org-babel-string-read (cell) "Strip nested \"s from around strings." base-commit: 5e2490bdf29a1eeff91b631425c38309cf368690 -- 2.26.2
Re: issue tracker?
> I think issue tracking could happen on a mailing list. If you tag an > issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of > the OPEN: issues to the list periodically (in theory). Something like that would be nice; the bot could even store such info in an org file that could be exported the html occasionally too. -- James Miller james.ryland.mil...@gmail.com
Re: [PATCH] agenda: Consider FILETAGS for archive skipping
George Sokolsky writes: > Kyle, could you please apply the patch to the org repository? Applied (5e2490bdf).
Re: issue tracker?
On 5/18/20 5:24 PM, Anthony Carrico wrote: Does org-mode have an issue tracker, to keep track of which issues are active, or is it just this mailing list? I'm the OP here. My first post to this list generated a lot of feedback. I'm not sure I have an opinion, it was an honest question, but I'd like to summarize the replies: 1. The mailing list is a good way, perhaps the best way to manage discussion threads, including threads about issues (bugs). 2. There isn't an issue tracker. I think issue tracking could happen on a mailing list. If you tag an issue's subject line with OPEN: or CLOSE:, a bot could mail a summary of the OPEN: issues to the list periodically (in theory). Given that the mailing list holds the issues, it would be nice if you could import the mailing list into your client as a lump (maildir/mbox). Currently you can only download it chunk by chunk, so it isn't really practical for a newcomer to import the whole list to do research a new issue before reporting it. -- Anthony Carrico
Re: [Suggestion] add an API function for getting link description
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicolas Goaziou writes: > Hello, > > stardiviner writes: > >> I found org link can't get link description easily. >> >> I googled it how to get link description. Found this solution. But it's not >> intuitive. >> >> #+begin_src emacs-lisp >> (defun get-description-at-point () >> (interactive) >> (let ((link (org-element-context))) >> (message "%s" (buffer-substring (org-element-property :contents-begin >> link) >> (org-element-property :contents-end >> link) >> #+end_src >> >> Why now support this? >> >> #+begin_src emacs-lisp >> (org-element-property :desc (org-element-context)) >> #+end_src >> >> Maybe the key ~:desc~ could be more meaningful detailed. > > Links with description are not leaf elements in the AST. I.e., the > parser needs to go deeper. As any non-leaf object, as, e.g., bold, it > has :contents-begin and :contents-end properties. Adding :desc would > duplicate information for no good reason. Hmm, I get the reason. Thanks for explanation. > > I see no problem writing an helper function once, and use it often. > > Besides, there are other, slightly different implementations of this > function, e.g., > > (defun get-description-at-point-2 () > (and (org-at-regexp-p org-link-bracket-re) (match-string 2))) > > This one is fuzzier, it will get description in fake links too (e.g., in > comments, property drawers…), but will be faster. So there is no single > function that fits every need. > Good to know another faster implementation. Thankful. Regards, - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7FtAMUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsNQBQf/RiEZsKS5NXhcta1RGftiUYGPah4l GQX0hrc+x/1Edm8ZGDLDXFy81LQVo1Min2dNxmEFnGqNjp8stfX6LYC5oxbt1Ye5 2FpejBGNyxvjZ/LpPwsIRr4xt3wlp2aNhoKO6VrqbLxJtxf92/Y9rccLBxNmzH7z xBXSDqrf5xBv+NC8hPTKbvPbo2b9OcJrFkF8cyBWU3T64iMqs6+F5TdmBZwOscXB NSu8Qha5+1QCz8pukk2iTvilzi37rdxRweOBDWvjKRmVdAQk35IoPop2Ip37OmRo tVqOx6Cc/7n0zTyhsYN36N5CsacPlR9FagzaroZ/9Jsp5DJCwtVh4YXU8A== =t/oC -END PGP SIGNATURE-
Re: [Question] why my org-link-set-parameters :face function does not work?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John Kitchin writes: > On Tue, May 19, 2020 at 6:51 PM stardiviner wrote: > >> I actually borrowed code from your code example, Because I want to do the >> following: >> > > Where did you find code that uses org-element-property on a link like this? > This won’t work with org-link-set-parameters because the face function does > not get an org-element, it gets only the path part of it. > Aha, I see. Thanks for point this out. I have not realized Org only pass the path instead of whole link. I will take a note of this in my notebook. >> I guess the issue is on the let-binding which invoked >> ~org-element-property~. But >> I can't edebug this function. When I =C-u C-M-x= set edebug on the >> function, and >> toggle ~font-lock-mode~ on Org Mode buffer, this function is not entering >> edebug. >> Don't know how to make Emacs enter this function edebug status. >> > > I don’t think you can use edebug in font lock functions. I always use the > old fashioned (message “%s” thing-i-want-to-see) approach. > > Maybe there is some fancy way to do it, e.g. font-lock-studio, but I don’t > do it often enough to be fluent in fancy things! > Seems this is the way to debug it. Thanks again. :) - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7Fs28UHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsM9Uwf/UIxjUkz5aVau8SJEp0DgonNxyYab lEWns2iyz4F89rY3i0CMjt3T7HR7VMdgEHLZFtDwvQPda6vqD/4wLzQdWikirXjA F7hl+CWop0lQW2VPPswatFuHyJd/WOsqR541bnv6Mwlk0/rO/OrRV6FOzoDqCeEW 2IsjZufigeNpn7xxiuU0T8JmvGQF1TLl3aYdEzDaq/RZleFVwoy1lFwEir4aENj1 FTumDx39STgIQujtuQa8QdiBg6F88RS5m1yAoVZY0EXYWnGXl8OFAfRYb8gLvGV9 v5eCdELIeSPc2ADWEb4Snm2C4uuk7CBkBWJzpdtZ/5ylgTZL8O/pwbdRsg== =fzCV -END PGP SIGNATURE-
Re: issue tracker?
Aloha everyone, Sometimes a "lower tech" solution is best, or at least offers a lot of advantages. What I see as the advantages of resolving issues through a mailing list are: * Minimal barriers to entry. If you have an email client of ANY type, you're in. No need for anything more. I think this is a very big deal, the merits of which can easily be underestimated. * Distributed data. No one has to be responsible for maintaining a central database, keeping it secure and updated, etc. (except, of course, for the list server but that's a different matter). Changes in policy on the bug-tracker host don't matter because there is no host. * A permanent record maintained and replicated widely. Everyone who saves their mail from the list has a copy. I'm certainly not saying that a formal project-management style issue tracking system is a bad thing; in many use cases, it can be quite important. But this is an open-source, distributed effort, non-commercial endeavor, not beholden to a specific client (the clients are all of us) and clearly not for profit. The requirements are not the same. I can't cite statistics, but I wonder if more gets "lost" on the mailing list than in a formal bug tracking system, where things do get buried and may not surface for a long time if ever. Another big enabling factor is that (as others have mentioned) this list is very responsive, very open and welcoming, and almost always courteous and respectful (rather a big thing on today's internet). I've posted various things and gotten various replies and results. When I've reported problems, they've been addressed, generally quickly and effectively. When I talk about nice-to-haves, some get responses and some don't, which is exactly what I'd expect. I'm very pleased with the way things are working and would hate to add another layer of complexity without being sure the upsides were greater than the downsides. -- Bob Newell Honolulu, Hawai`i - Via GNU/Linux/Emacs/Gnus/BBDB
Setting org-todo-keywords through directory-local variables
Hello,
I'd like to set org-todo-keywords and org-todo-keyword-faces through
directory-local variables, to get rid of duplicate #+SEQ_TODO lines in
my Org files[1].
Right now I see two obstacles for this to work:
(1) org-set-regexps-and-options, which sets up a bunch of TODO-related
machinery, insists on using (default-value 'org-todo-keywords),
(2) this function is called in the major mode function, which IIUC means
that directory-local values have not been applied yet.
The first obstacle looks like it can be easily removed[2]; the second
obstacle looks more substantial. It is trivially side-stepped by
sticking (hack-local-variables) at the top of org-mode; to my untrained
eye, it looks like TRT would rather be for Org to add
org-set-regexps-and-options to hack-local-variables-hook.
This sounds like a risky change though: I imagine that a lot of what
happens in the major mode function depends on what
org-set-regexps-and-options sets up, and would therefore need to be
moved to this hook as well. Figuring which parts should be moved seems
like a non-trivial task that might introduce some regressions…
Can anyone confirm that this would (in principle) be the way forward, or
tell me if I am missing something[3]?
Thank you for your time.
[1] For example:
#+begin_src elisp
((org-mode
. ((org-todo-keywords
. ((sequence "REPORT" "REPORTED" "WAITING" "FIXED")
(sequence "CANCELED")))
(org-todo-keyword-faces
. (("REPORT" . org-todo)
("REPORTED" . warning)
("WAITING" . warning)
("FIXED" . org-done)
("CANCELED" . shadow))
#+end_src
I'd like that so much that I went through the trouble of writing
safe-local-variable predicates for these variables:
#+begin_src elisp
(put 'org-todo-keywords
'safe-local-variable
(lambda (x)
(cl-every
(lambda (seq)
(and (memq (car seq) '(sequence type))
(cl-every (lambda (i) (stringp i)) (cdr seq
x)))
(put 'org-todo-keyword-faces
'safe-local-variable
(lambda (x)
(cl-every
(lambda (pair)
(pcase pair
(`(,keyword . ,face)
(and (stringp keyword)
(or (facep face) (listp face))
x)))
#end_src
[2] I tried to go through org.el's history, but I could not find a
rationale for using default-value.
[3] Alternatively, maybe the answer is as simple as "Org documents
should be self-sufficient; keywords should be explicitly set in
#+SEQ_TODO lines"; that wouldn't sound right though, since
org-todo-keywords is customizable.
Re: ob-js uses deprecated Node APIs
Ivan Sokolov writes:
> I ran into problems with ob-js. When resolving them, I found that require
> ('sys') is deprecated, there is a patch.
>
> diff --git a/lisp/ob-js.el b/lisp/ob-js.el
> index 7592040ab..d459e8069 100644
> --- a/lisp/ob-js.el
> +++ b/lisp/ob-js.el
> @@ -65,7 +65,7 @@
>:safe #'stringp)
>
> (defvar org-babel-js-function-wrapper
> - "require('sys').print(require('sys').inspect(function(){\n%s\n}()));"
> +
> "require('process').stdout.write(require('util').inspect(function(){%s}()));"
>"Javascript code to print value of body.")
>
> (defun org-babel-execute:js (body params)
I can confirm that I just encountered this bug today and that Ivan's
patch resolves the issue.
See here for more information:
https://nodejs.org/api/deprecations.html#deprecations_dep0025_require_sys
Best,
Matt
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
Hello,
"Dauer, Michael" writes:
> This was different in earlier versions.
I couldn't find an earlier version where that was the case. This
doesn't mean there is none, of course.
> And what about date and time. Are these macros also expected to be defined
> manually before?
I cannot remember. But the behaviour currently matches the
documentation; and it looks very reasonable to me. Likewise, {{{date}}}
refers to the DATE keyword.
{{{time}}} case is different. This macro requires a mandatory FORMAT
argument that you didn't provide.
Regards,
--
Nicolas Goaziou
RE: issue tracker?
Hello everyone, I have been following the org-mode ML and I have seen the discussion about having a bug tracker. I wanted to offer my 2 cents as a non-developer; barely a power user. Org-mode works incredibly well and I use it on a daily basis. It is true that development is very active. However I might say that saying that no bugs fall through the cracks in the ML is a bit of a confirmation bias. My personal experience was different. I actually submitted some bug reports through emacs about some slightly less used parts of org-mode e.g. ob-eshell. The mailing list is moderated (or has anti-spam) so the result was that my mail did not appear AT ALL. I had that issue before, too, but here in IRC I was suggested to wait for several days. The previous time I think the e-mail eventually got through. When I submitted the bug report for ob-eshell it never did. I found a workaround by using shell instead of ob-shell so I never pursued the issue. Probably the bug is still there. I am glad that the ML works for the most active developers, and I suppose it works well for the linux kernel since it needs to be centralized and somewhat focused. However org-mode could benefit from more community involvement even of newbies, especially around the parts that are "part of" org-mode but are not that often used and don't receive enough love and attention from the main developers. A good bug tracker could also help identify parts that are not used or buggy and that should, maybe, be slated for removal or at least separated in a independent package. You see, for a beginner a bug is quite daunting because you never know if it is actually a bug or if it is your own fault for misunderstanding or misconfiguring something. And, honestly, in emacs, it is quite easy for a beginner to misconfigure something. All this to say that the ML works great and I picked up great ideas while reading through it in my mailbox (I am subscribed), however it still has a significant "gatekeeper" effect. Please, at least address the issue that some bug reports don't even make it to the list AT ALL. I do not want this email to be offensive in any way to anyone. I also realize that what I described may not be representative. I excuse myself in advance if my tone was inappropriate. More than anything I still wish to thank everyone for a piece of fantastic software that has helped me out crucially on multiple occasions! Sincerely, Gennady P.S. I wrote essentially the same e-mail on the IRC channel to be sure that it gets delivered somewhere. -Original Message- From: Emacs-orgmode On Behalf Of Jud Taylor Sent: Wednesday, 20 May, 2020 12:42 To: Stefan Nobis Cc: emacs-orgmode@gnu.org Subject: Re: issue tracker? I second that. Nicolas, thank you! Great product, better vision, high energy! ‐‐‐ Original Message ‐‐‐ On Wednesday, May 20, 2020 7:12 AM, Stefan Nobis wrote: > Detlef Steuer ste...@hsu-hh.de writes: > > > I would go as far as saying this list is one of the fastest reacting > > amd friendliest communities I have been part of. The job Nicolas > > does is just awesome. > > +1! > > -- > > Until the next mail..., > Stefan.
Re: issue tracker?
I second that. Nicolas, thank you! Great product, better vision, high energy! ‐‐‐ Original Message ‐‐‐ On Wednesday, May 20, 2020 7:12 AM, Stefan Nobis wrote: > Detlef Steuer ste...@hsu-hh.de writes: > > > I would go as far as saying this list is one of the fastest > > reacting amd friendliest communities I have been part of. The job > > Nicolas does is just awesome. > > +1! > > -- > > Until the next mail..., > Stefan.
Re: [Question] why my org-link-set-parameters :face function does not work?
On Tue, May 19, 2020 at 6:51 PM stardiviner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> John Kitchin writes:
>
> > The face function only takes the link path, which is a string. you cannot
> > use org-element-property on it.
> >
> > Maybe you want something like this:
> >
> > #+begin_src emacs-lisp
> > (defun org-link-beautify-face (path)
> > "Set link face colors."
> > (message "beautifying")
> > (if (and (not (file-remote-p path))
> > (file-exists-p (expand-file-name path)))
> > 'org-link
> > 'org-warning))
> >
> > ;;; DEBUG
> > (org-link-set-parameters
> > "file"
> > :face #'org-link-beautify-face)
> > #+end_src
>
> I actually borrowed code from your code example, Because I want to do the
> following:
>
Where did you find code that uses org-element-property on a link like this?
This won’t work with org-link-set-parameters because the face function does
not get an org-element, it gets only the path part of it.
> #+begin_src emacs-lisp
> (defun org-link-beautify-face (link)
> "Set link face colors."
> (let ((raw-link (org-element-property :raw-link link))
> (type (org-element-property :type link))
> (path (org-element-property :path link)))
> (pcase type
> ;; ("https" )
> ;; ("http" )
> ("file"
>(if (and (not (file-remote-p path))
> (file-exists-p (expand-file-name path)))
>'org-link 'org-warning)
>
> (dolist (link-type (mapcar 'car org-link-parameters))
> (org-link-set-parameters link-type
>:face #'org-link-beautify-face))
> #+end_src
>
> In this way, I can put my code in a union function.
>
> I guess the issue is on the let-binding which invoked
> ~org-element-property~. But
> I can't edebug this function. When I =C-u C-M-x= set edebug on the
> function, and
> toggle ~font-lock-mode~ on Org Mode buffer, this function is not entering
> edebug.
> Don't know how to make Emacs enter this function edebug status.
>
I don’t think you can use edebug in font lock functions. I always use the
old fashioned (message “%s” thing-i-want-to-see) approach.
Maybe there is some fancy way to do it, e.g. font-lock-studio, but I don’t
do it often enough to be fluent in fancy things!
> >
> > John
> >
> > ---
> > Professor John Kitchin
> > Doherty Hall A207F
> > Department of Chemical Engineering
> > Carnegie Mellon University
> > Pittsburgh, PA 15213
> > 412-268-7803
> > @johnkitchin
> > http://kitchingroup.cheme.cmu.edu
> >
> >
> >
> > On Tue, May 19, 2020 at 9:12 AM stardiviner wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >>
> >> Bellowing is my source code, it does not work. I'm wondering why?
> >>
> >> #+begin_src emacs-lisp
> >> (defun org-link-beautify-face (link)
> >> "Set link face colors."
> >> (let ((raw-link (org-element-property :raw-link link))
> >> (type (org-element-property :type link))
> >> (path (org-element-property :path link)))
> >> (pcase type
> >> ;; ("https" )
> >> ;; ("http" )
> >> ("file"
> >>(if (and (not (file-remote-p path))
> >> (file-exists-p (expand-file-name path)))
> >>'org-link 'org-warning)
> >>
> >> ;;; DEBUG
> >> (org-link-set-parameters
> >> "file"
> >> :face #'org-link-beautify-face)
> >> #+end_src
> >>
> >> - --
> >> [ stardiviner ]
> >>I try to make every word tell the meaning that I want to express.
> >>
> >>Blog: https://stardiviner.github.io/
> >>IRC(freenode): stardiviner, Matrix: stardiviner
> >>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
> >>
> >> -BEGIN PGP SIGNATURE-
> >>
> >> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7D2xkUHG51bWJjaGls
> >> ZEBnbWFpbC5jb20ACgkQG13xyVromsMfHAgAjnoQlzdHlcKL/rBVBLlkmMITh7f5
> >> 6SxRw9sS1BagIma+APiuy+A4O4fSDLyzUMDg+Sg/C+vNu3QC2BM7ipBYNXtWcX1M
> >> oPZj8loMrnISTIK51j2+9Pg0iOP1aZSvZqwA0p1mK2aZURBXWl7qDkVxD2oWji5P
> >> qCBVr9ZFUloGSl7PtZTlOtsCgTCGHvnfvnk7vqxY4beuavQgaRSWUCsVDDO0c/M6
> >> 5CSzxobElB3Y68fQ2awuQwRGCzfEvRkGShHp3Raug+EJ5Ew+MYEi6wILfPxYF2WR
> >> VJjuxAxseBuiIjYjF91xzbR7mSZQsvB1gNttLYb3uQ/jrgj0HOQDo5Jmtg==
> >> =4fE9
> >> -END PGP SIGNATURE-
> >>
> >>
>
>
> - --
> [ stardiviner ]
>I try to make every word tell the meaning that I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>
> -BEGIN PGP SIGNATURE-
>
> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7EYtkUHG51bWJjaGls
> ZEBnbWFpbC5jb20ACgkQG13xyVromsOnbwf/f5zAf2fh+vUg7ikwtXpzCL+cjeUt
> vyyHH9R32K5nb0FTqeyL/rjw6AhHRsTR7sFSUkb++Q8uWRJyxT2Kt7bgujRsL/cb
> bnmArq4HFWw7ysxYjhDSknwzhc4xFzUJpSmnZuNHEItIuV5Ghg/FnEJokcTurop2
> jN4dw28ladHMLel2hjhIRQni3ugQwfKOuyBZa8U3SCPENfnK8uPbMoxkONgdmDQu
> wG3qw8NvMFnD5Vr81qVb/ytGJyMv+34wD/unZ1TK7BaTGsOVvg/l8ssj5h3EsDeX
>
Re: `#+author:' stopped setting the author to empty string
On Tue, May 19, 2020 at 8:38 PM Kyle Meyer wrote: > Nicolas Goaziou writes: > > > At first glance, it looks harmless. If the test suite passes, we can > > apply it. > > The test suite does pass with the change. Pushed, along with a > regression test (962b8e765). > Thank you for the debug and quick fix! I confirm the fix.
Re: [Suggestion] add an API function for getting link description
Hello, stardiviner writes: > I found org link can't get link description easily. > > I googled it how to get link description. Found this solution. But it's not > intuitive. > > #+begin_src emacs-lisp > (defun get-description-at-point () > (interactive) > (let ((link (org-element-context))) > (message "%s" (buffer-substring (org-element-property :contents-begin > link) > (org-element-property :contents-end > link) > #+end_src > > Why now support this? > > #+begin_src emacs-lisp > (org-element-property :desc (org-element-context)) > #+end_src > > Maybe the key ~:desc~ could be more meaningful detailed. Links with description are not leaf elements in the AST. I.e., the parser needs to go deeper. As any non-leaf object, as, e.g., bold, it has :contents-begin and :contents-end properties. Adding :desc would duplicate information for no good reason. I see no problem writing an helper function once, and use it often. Besides, there are other, slightly different implementations of this function, e.g., (defun get-description-at-point-2 () (and (org-at-regexp-p org-link-bracket-re) (match-string 2))) This one is fuzzier, it will get description in fake links too (e.g., in comments, property drawers…), but will be faster. So there is no single function that fits every need. Regards, -- Nicolas Goaziou
Re: issue tracker?
Detlef Steuer writes: > I would go as far as saying *this list* is one of the fastest > reacting amd friendliest communities I have been part of. The job > Nicolas does is just awesome. +1! -- Until the next mail..., Stefan.
[Suggestion] add an API function for getting link description
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I found org link can't get link description easily. I googled it how to get link description. Found this solution. But it's not intuitive. #+begin_src emacs-lisp (defun get-description-at-point () (interactive) (let ((link (org-element-context))) (message "%s" (buffer-substring (org-element-property :contents-begin link) (org-element-property :contents-end link) #+end_src Why now support this? #+begin_src emacs-lisp (org-element-property :desc (org-element-context)) #+end_src Maybe the key ~:desc~ could be more meaningful detailed. WDYT? Nicolas - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7E++0UHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPYzAgAgpAgmgYJGvQME1T+cniWWAcfLDLh tHNrV9vmfPdmtKtMQsLBACkmHysGBt4jsxZXPB96nhpK7vc0Vo7WPSUum7jW4M4q GVC2bj9+gb/ZS4dYXnSHxzHTz62c5NRLHAj6jSuHow1cAtkuE/J5yT7M4ziECo4P NnSuOZaBpHdAfWLFfkQYM4PG0Nrawfe+fy5BTqthXLchExtvMAD2tdgOrI4fxaIV wfptEog/l6fzNfwpEW9XUUqaxqlFFPoN1GBVS3nPEuW/tInaOJgINL0giEN0ZSa6 P5czGgE9Zsdolw+v96rgqiInH3zRDFLDV8DiVrYxYig2wJ+xg0He2h6HNQ== =44DQ -END PGP SIGNATURE-
Re: issue tracker?
Am Wed, 20 May 2020 10:22:56 +0100 schrieb Eric S Fraga : > On Tuesday, 19 May 2020 at 18:57, Russell Adams wrote: > > My personal opinion is I'd always prefer to use my mail client over > > some website. > > +∞! How to add more now? Same here. Mail is functionally superior to a lot of modern solutions. A Bugtracker you do not use on a regular basis often is a horrible time sink. Plus, most of the time you need just another account for a site you never wanted an account on. Furthermore many of the discussions on this list wouldn't have happend, if the first post went into a bugtracker. I would go as far as saying *this list* is one of the fastest reacting amd friendliest communities I have been part of. The job Nicolas does is just awesome. That leads to the next point: If Nicolas decided *he* would love to work with a bugtracker, I would not complain and open an account. As it is now, anything that's not in the best interest of our benevolent developer, should not even be considered :-) Just my opinion, of course Detlef > > There are some communities that I would love to participate in but do > not because they use, for instance, discourse which has a horrible > email interface. And their web interface cannot be used via eww, for > instance. > > In any case, strictly speaking, some org issues could be submitted via > Emacs's own bug tracker, at least for the version of org that comes > with Emacs?
Re: issue tracker?
On Tuesday, 19 May 2020 at 18:57, Russell Adams wrote: > My personal opinion is I'd always prefer to use my mail client over some > website. +∞! There are some communities that I would love to participate in but do not because they use, for instance, discourse which has a horrible email interface. And their web interface cannot be used via eww, for instance. In any case, strictly speaking, some org issues could be submitted via Emacs's own bug tracker, at least for the version of org that comes with Emacs? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
This was different in earlier versions.
And what about date and time. Are these macros also expected to be defined
manually before?
Nicolas Goaziou schrieb am Mi., 20. Mai 2020,
00:53:
> Hello,
>
> "Dauer, Michael" writes:
>
> > mist.org>>>
> >
> > * test
> > foo {{{author}}} bar {{{keyword(AUTHOR)}}}
> > {{{title}}}
> > {{{date}}}
> > {{{time}}}
> > {{{input-file}}}
> > {{{n}}}
> > <<<
> >
> > ascii output buffer>>>
> > Michael Dauer
> >
> >
> > Table of Contents
> > _
> >
> > 1. test
> >
> >
> > 1 test
> > ==
> >
> > foo bar
> >
> >
> >
> > mist.org
> > 1
> > <<<
>
> This looks correct. AFACT, {{{author}}} never returned user-full-name.
> {{{author}}} is just a shortcut for {{{keyword(AUTHOR)}}}.
>
> See (info "(org) Macro Replacement") for more information.
>
> Regards,
>
> --
> Nicolas Goaziou
>
Aw: Re: Capture Template Diary Entry: file+datetree+prompt use the prompted timestamp including the time when time is specified
Hi Kyle,
thanks a lot for your workaround! I just tested it and it almost does what I am
looking for.
The only thing that does not work is to give a range of time, i.e. 10:00-12:00.
And looking at your code it is clear, that this cannot work because neither
"%t" nor "%T" can do this.
I guess in the long run, it would make sense to adapt the template expansion
"%t" to behave like the function "org-time-stamp".
Such an adaption would create more consistent behaviour for org users and does
not break any former usage.
I checked the the part in org-capture.el and it looks like this
((or "t" "T" "u" "U")
;; These are the date/time related ones.
(let* ((upcase? (equal (upcase key) key))
(org-end-time-was-given nil)
(time (org-read-date upcase? t nil prompt)))
(org-insert-time-stamp
time (or org-time-was-given upcase?)
(member key '("u" "U"))
nil nil (list org-end-time-was-given
But unfortunately, I am not an elisp programmer and I cannot do the adaption
myself.
I am sorry for that.
Once more, thanks.
Nils
Gesendet: Mittwoch, 20. Mai 2020 um 06:02 Uhr
Von: "Kyle Meyer"
An: "Nils Schween"
Cc: emacs-orgmode@gnu.org
Betreff: Re: Capture Template Diary Entry: file+datetree+prompt use the
prompted timestamp including the time when time is specified
Nils Schween writes:
> ("d" "Diary entry" entry (file+datetree+prompt
> "~/MPIK-Nextcloud/emacs/.org/kalender.org")
> "* %i%?\n %T")
>
> And it works as expected: When calling the capture template, I am prompted
> for a
> date and I can also type a time, and on saving everything is stored at the
> correct location in the datetree. Perfect. But in case I do not enter a time,
> 00:00 is inserted. This is unfortunate. Okay, I can replace "%T" in the
> template
> with "%t", but then any specification of time is ignored.
>
> Instead, I would love to mimic the behaviour of the function
> "org-time-stamp". Calling it
> prompts for a date, and if I do not specify a time, only the date is inserted.
> In case I specify a time or a range (i.e. 10:00-12:00) the timestamp is
> supplemented with this additional information.
>
> I tried a lot to get the desired behaviour by testing variants of the
> following
> combination of org-mode functions and variables.
> %(org-insert-time-stamp (org-read-date nil t org-read-date-final-answer) t)
>
> I was not able to produce what I wanted.
>
> Does anyone have a workaround or an idea how I could implement the described
> and
> wished behaviour? Thanks.
I'm not aware of any built-in way to do what you want. For either
implementing or working around, org-capture-set-target-location and
org-capture-fill-template are the two places you'd probably want to
look. As a start of a hacky workaround, with an entry like
("d" "Diary entry" entry (file+datetree "/tmp/scratch.org")
"* %i%?\n %T" :time-prompt t)
you should be able to get the time/no time behavior you're after with
(advice-add 'org-capture-fill-template :around
(lambda (fn template args)
(let ((template (and (not org-time-was-given)
(replace-regexp-in-string
"%T" "%t"
(org-capture-get :template) t
(apply fn template args)))
'((name . "org-capture-hack")))
