Re: `with` as a list.

[Kyle Meyer]

Mario Frasca writes:

> now and then I use emacs to make graphs.  now recently I was plotting 
> point data, and a running average "fit", so I wanted to have points, and 
> lines, which I know it's possible in `gnuplot` but now how do I do that 
> from org-plot …
>
> I wrote a small patch for org-plot.el, I'm not a Lisp programmer so I'm 
> sure the patch looks terrible, but it does allow me to do this:
>
> #+PLOT: ind:1 deps:(3 6 4 7) with:(points lines points lines)
>
> it's two additions: [...]

Thanks for the patch and for clearly describing the motivation.  I'm not
an org-plot user, but the change sounds useful.  (It'd be great if
org-plot users could chime in.)

Two meta-comments:

  * Please provide a patch with a commit message.  See
 for more information.

  * The link above also explains the copyright assignment requirement
for contributions.  Please consider assigning copyright to the FSF.

> diff --git a/lisp/org-plot.el b/lisp/org-plot.el
> index a23195d2a..87a415137 100644
> --- a/lisp/org-plot.el
> +++ b/lisp/org-plot.el
> @@ -179,6 +179,28 @@ and dependent variables."
> (setf back-edge "") (setf front-edge ""
>  row-vals))
>  
> +(defun org-plot/zip-deps-with (num-cols ind deps with)
> +  "describe each column to be plotted as (col . with)"

This doesn't match the convention used in this code base for docstrings.
Taking a look around should give you a good sense, but (1) the first
word should be capitalized, (2) sentences should end with a period, and
(3) ideally all parameters should be described in the docstring.

> +  ;; make 'deps explicit

I think this and the other comments in this function could safely be
dropped.

> +  (unless deps
> +(setf deps (let (r)
> +  (dotimes (i num-cols r)
> +(unless (eq num-cols (+ ind i))
> +  (setq r (cons (- num-cols i) r)))

Hmm, org-plot does seem to use setf a lot (more than any other .el file
in the repo), though using setq unless setf is needed would be more
consistent with this code base.

The code above looks fine to me.  Another option would be to use
number-sequence and then filter out the ind value.

> +  ;; make sure 'with matches 'deps
> +  (unless with
> +(setf with "lines"))
> +  (unless (listp with)
> +(setf with (mapcar (lambda (x) with) deps)))

This is make-list in the more recent diff you sent, which I agree is
better.

> +  ;; invoke zipping function on converted data
> +  (org-plot/zip deps with))
> +
> +(defun org-plot/zip (xs ys)
> +  (unless
> +  (null xs)
> +(cons (cons (car xs) (or (car ys) "lines"))

Is the "lines" fall back ever reached?  It looks like you're extending
`with' above to be the same length as `deps`.

> +   (org-plot/zip (cdr xs) (cdr ys)

In Elisp, it's not very common to use recursive functions (and there's
no TCO).  In the case of zipping two lists, I think it'd probably be
easiest to just use cl-loop.  And in my view having a separate function
here is probably an overkill.

>  (defun org-plot/gnuplot-script (data-file num-cols params &optional preface)
>"Write a gnuplot script to DATA-FILE respecting the options set in PARAMS.
>  NUM-COLS controls the number of columns plotted in a 2-d plot.
> @@ -240,22 +262,22 @@ manner suitable for prepending to a user-specified 
> script."
>  "%Y-%m-%d-%H:%M:%S") "\"")))
>  (unless preface
>(pcase type; plot command
> - (`2d (dotimes (col num-cols)
> -(unless (and (eq type '2d)
> - (or (and ind (equal (1+ col) ind))
> - (and deps (not (member (1+ col) deps)
> -  (setf plot-lines
> -(cons
> - (format plot-str data-file
> - (or (and ind (> ind 0)
> -  (not text-ind)
> -  (format "%d:" ind)) "")
> - (1+ col)
> - (if text-ind (format ":xticlabel(%d)" ind) "")
> - with
> - (or (nth col col-labels)
> - (format "%d" (1+ col
> - plot-lines)
> + (`2d (dolist
> +  (col-with
> +   (org-plot/zip-deps-with num-cols ind deps with))
> +(setf plot-lines
> +  (cons
> +   (format plot-str data-file
> +   (or (and ind (> ind 0)
> +(not text-ind)
> +(format "%d:" ind)) "")
> +   (car col-with)
> +   (if text-ind (format ":xticlabel(%d)" ind) "")
> +   (cdr col-with)
> +   (or (nth (1- (car col-with))
> + 

Re: [Feature] add a new org-attach dispatcher command to offline save web page

[Ihor Radchenko]

> AFAICT, org-board uses the following options, which limit the archiving
> to a single page and all its resources:
>
> wget -e robots=off --page-requisites --adjust-extension --convert-links [...]

This is certainly better. I believe that wget would be a better default
(with right flags). It is much more likely to be installed for average
user.

> You can also create a warc (web archive) file with wget, but then you
> need a web archive replayer to view it, which is not exactly convenient.

Interesting. I did not know about warc.

Matthew Lundin  writes:

> Ihor Radchenko  writes:
>
>>> As I said, PATCH welcome, I admired many times I don't have ability to 
>>> build a
>>> complex archive functionality on url.el or wget or curl.
>>
>> I have found the following solution [1] using wget:
>>
>> wget --mirror -p --convert-links -P ./LOCAL-DIR WEBSITE-URL
>>
>
> I don't think --mirror is what we want this context, since that will
> initiate a recursive download of the entire site. (Ironically, my IP is
> now banned from a personal blog that provides a how-to for using wget
> after I tried to run the above command on it.) From the wget manual:
>
> -m
> --mirror
> Turn on options suitable for mirroring.  This option turns on 
> recursion and
> time-stamping, sets infinite recursion depth and keeps FTP directory 
> listings.
> It is currently equivalent to -r -N -l inf --no-remove-listing.
>
> AFAICT, org-board uses the following options, which limit the archiving
> to a single page and all its resources:
>
> wget -e robots=off --page-requisites --adjust-extension --convert-links [...]
>
>> This will not bundle the page into a single file, but it is better than
>> nothing. org-attach does not have to attach exactly one file.
>
> You can also create a warc (web archive) file with wget, but then you
> need a web archive replayer to view it, which is not exactly convenient.
>
> Best,
>
> Matt
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

[Eli Zaretskii]

> From: Kévin Le Gouguec 
> Cc: 41584-d...@debbugs.gnu.org,  dgu...@yandex.ru
> Date: Fri, 29 May 2020 22:32:11 +0200
> 
> (I guess xdisp.c is something we won't to touch with a 10-foot pole on
> the release branch, especially for a bug that users have lived with for
> so long?)

Exactly.

Re: org-read-date-minibuffer-local-map should use C-n/p/f/b

[Matthew Lundin]

Alex Branham  writes:

> I find it unintuitive that the usual calendar keys C-n/p/f/b don't work
> when scheduling tasks in org mode (yes, I know about S-right, etc). I've
> something like this to my init file for those four keys (based on their
> setup in org-keys.el) for some time with no negative repercussions (that
> I know about anyway), perhaps the same should be done for org itself?
>
> #+begin_src emacs-lisp
> (define-key org-read-date-minibuffer-local-map (kbd "C-n") (lambda () 
> (interactive) (org-eval-in-calendar '(calendar-forward-week 1
> #+end_src

While I can't think of any obvious conflicts for C-n and C-p in the
context of the read date minibuffer (please correct me if I'm wrong),
C-f and C-b are bound to forward-char and backward-char, which I
frequently use when entering and editing dates.

Best,

Matt

[BUG] recently commits on master branch breaks command 'org-babel-demarcate-block'

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


When I have a source block (The "|" represents the point):

#+begin_src sh :eval no
chrome --remote-debugging-port
|

#+end_src

Then press =[C-c C-v d]=, it becomes like this:

#+begin_src sh :eval no
chrome --remote-debugging-port
#+end_src

#+begin_src
sh :eval no

#+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-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7RvwkUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsPWigf+NOP4j0/9U3YvhHhdAmNbrLiNa+My
NsN7msj1uSwwgtyKccaDOmB4mRMoKxhdK3TMn55LmKj+xsJY54EQ35Oq2G4HsJYX
kbypfoj09NNjE4R7Qw7IyAbr7cLkITPbp+9UCDX+lupyNGsKDmkDtrl84JG/Lnxs
jp5FuKBzeG2P7dR8Zs8TFPZOzzPP4jQKnUgfghRcgLNxxJXX2CPge5+cAKiDQFoh
yQCXdd9cFbldnethRjQb6GrlylBcCaHe41AuKrXAdn2gmv1gPLNb1perJ/TCyw3x
ZQy554ZI8dOL1jH4lL5JmGxwWcgMq4qahdhUlfSCEzZKgjKqTtVTdBJYwg==
=qwc/
-END PGP SIGNATURE-

Re: [PATCH] Fix org-capture-place-entry narrow bounds

[Kevin Liu]

Sorry, corrected patch format:

>From 8e7b28054492424170f14f11297b416ef7575540 Mon Sep 17 00:00:00 2001
From: nivekuil 
Date: Fri, 29 May 2020 16:48:31 -0700
Subject: [PATCH] capture: Fix org-capture-place-entry narrow bounds

* lisp/org-capture.el
(org-capture-place-entry):
Prevent breaking the following headline inside the capture buffer.
This should match the behavior from 9.3.
(org-capture-finalize):
Reverts cb2774d1a, which solves a similar problem but only in the
finalize stage, so the subtree structure would still be broken in the
middle of editing the capture.
---
 lisp/org-capture.el | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 9136d331b..4d2c3e8d4 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -728,16 +728,6 @@ captured item after finalizing."
 
   (run-hooks 'org-capture-prepare-finalize-hook)
 
-  ;; Fix missing final newline, as it may have been deleted by accident
-  (when (eq (org-capture-get :type 'local) 'entry)
-(save-excursion
-  (goto-char (point-max))
-  (and (not (looking-at-p "^"))
-	   (org-with-wide-buffer
-	(and (not (looking-at-p org-heading-regexp))
-		 (not (eobp
-	   (insert "\n"
-
   ;; Did we start the clock in this capture buffer?
   (when (and org-capture-clock-was-started
 	 org-clock-marker
@@ -1166,7 +1156,7 @@ may have been stored before."
 	(org-capture-empty-lines-after)
 	(unless (org-at-heading-p) (outline-next-heading))
 	(org-capture-mark-kill-region origin (point))
-	(org-capture-narrow beg (point))
+	(org-capture-narrow beg (if (eobp) (point) (1- (point
 	(org-capture--position-cursor beg (point))
 
 (defun org-capture-place-item ()
-- 
2.26.2



On 29 May 2020 17:25, Kevin Liu  wrote:

> This is a patch to fix my previous report of a regression in capture
> behavior between 9.3 and 9.3.6:
>
>> Basically, the last position in the narrowed org-capture is actually
>> the first position on the next line, so when you go to (end-of-buffer)
>> and start typing you start clobbering the next headline.
>
> The fix already landed in cb2774d1a is inadequate for me as the subtree
> structure can still be broken during the capture process.  I think this
> is the more correct approach, though I haven't done much testing outside
> of my own workflow and `make test`.  It seems to be the same behavior as
> 9.3.
>
> From e6f4faacd2db9ea3f5dc6d6582e0e58ee11c8bef Mon Sep 17 00:00:00 2001
> From: nivekuil 
> Date: Fri, 29 May 2020 16:48:31 -0700
> Subject: [PATCH] Fix org-capture-narrow
>
> ---
>  lisp/org-capture.el | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/lisp/org-capture.el b/lisp/org-capture.el
> index 9136d331b..4d2c3e8d4 100644
> --- a/lisp/org-capture.el
> +++ b/lisp/org-capture.el
> @@ -728,16 +728,6 @@ captured item after finalizing."
>
>(run-hooks 'org-capture-prepare-finalize-hook)
>
> -  ;; Fix missing final newline, as it may have been deleted by accident
> -  (when (eq (org-capture-get :type 'local) 'entry)
> -(save-excursion
> -  (goto-char (point-max))
> -  (and (not (looking-at-p "^"))
> -(org-with-wide-buffer
> - (and (not (looking-at-p org-heading-regexp))
> -  (not (eobp
> -(insert "\n"
> -
>;; Did we start the clock in this capture buffer?
>(when (and org-capture-clock-was-started
>org-clock-marker
> @@ -1166,7 +1156,7 @@ may have been stored before."
>   (org-capture-empty-lines-after)
>   (unless (org-at-heading-p) (outline-next-heading))
>   (org-capture-mark-kill-region origin (point))
> - (org-capture-narrow beg (point))
> + (org-capture-narrow beg (if (eobp) (point) (1- (point
>   (org-capture--position-cursor beg (point))
>
>  (defun org-capture-place-item ()

[PATCH] Fix org-capture-place-entry narrow bounds

[Kevin Liu]

This is a patch to fix my previous report of a regression in capture
behavior between 9.3 and 9.3.6:

> Basically, the last position in the narrowed org-capture is actually
> the first position on the next line, so when you go to (end-of-buffer)
> and start typing you start clobbering the next headline.

The fix already landed in cb2774d1a is inadequate for me as the subtree
structure can still be broken during the capture process.  I think this
is the more correct approach, though I haven't done much testing outside
of my own workflow and `make test`.  It seems to be the same behavior as
9.3.

>From e6f4faacd2db9ea3f5dc6d6582e0e58ee11c8bef Mon Sep 17 00:00:00 2001
From: nivekuil 
Date: Fri, 29 May 2020 16:48:31 -0700
Subject: [PATCH] Fix org-capture-narrow

---
 lisp/org-capture.el | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 9136d331b..4d2c3e8d4 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -728,16 +728,6 @@ captured item after finalizing."
 
   (run-hooks 'org-capture-prepare-finalize-hook)
 
-  ;; Fix missing final newline, as it may have been deleted by accident
-  (when (eq (org-capture-get :type 'local) 'entry)
-(save-excursion
-  (goto-char (point-max))
-  (and (not (looking-at-p "^"))
-	   (org-with-wide-buffer
-	(and (not (looking-at-p org-heading-regexp))
-		 (not (eobp
-	   (insert "\n"
-
   ;; Did we start the clock in this capture buffer?
   (when (and org-capture-clock-was-started
 	 org-clock-marker
@@ -1166,7 +1156,7 @@ may have been stored before."
 	(org-capture-empty-lines-after)
 	(unless (org-at-heading-p) (outline-next-heading))
 	(org-capture-mark-kill-region origin (point))
-	(org-capture-narrow beg (point))
+	(org-capture-narrow beg (if (eobp) (point) (1- (point
 	(org-capture--position-cursor beg (point))
 
 (defun org-capture-place-item ()
-- 
2.26.2

Re: wip-cite status question and feedback

[Bruce D'Arcus]

One thing on a detail:

On Fri, May 29, 2020 at 6:00 PM András Simonyi  wrote:

...

> From the citeproc-el (and CSL) perspective, the list of bibliography database
> files, the place where the bibliography should be placed (if it's specified) 
> ...

Particularly if citeproc.el gets incorporated into emacs, keep in mind
the possibility
(at least at some point) of more than one bibliography in a document.

I'm not super familiar with biblatex, but I do know it supports this
functionality.

Here's one example I found; LaTeX of course:

\printbibliography[title=Primary Sources, keyword=primary]
\printbibliography[title=Secondary Sources, keyword=secondary]

And there's the use case of per/chapter endnote bibliographies and such.

Bruce

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Fri, May 29, 2020 at 6:00 PM András Simonyi  wrote:
>
> Hi,
>
> apologies for reacting that late (it seems that I messed up my email filtering
> royally) ...

I wondered what happened to you; glad you sorted it out though!

...

> (i) Default ("built in") citation processor in Org
>
> I think citeproc-el could be a reasonable solution for this. The core is
> well-tested (thanks to the CSL test suite), implements a fairly large subset 
> of
> the CSL 1.01 standard, and can output citations in a number of formats 
> including
> in Org syntax. If I understood correctly, this would require citeproc-el to be
> part of Emacs, and not even an ELPA package would suffice. In principle I'm 
> open
> to this, but I'm not familiar with the process and there are potential 
> pitfalls,
> e.g. citeproc-el currently depends on some "modern" libraries, e.g., "s" or
> "dash" which AFAIK are not in Emacs.

It would very cool if you all could figure out how to make this happen.

It would ensure pretty awesome out-of-box functionality.

Bruce

Re: wip-cite status question and feedback

[András Simonyi]

Hi,

apologies for reacting that late (it seems that I messed up my email filtering
royally) -- it is very nice to see progress in this area. Thanks to all of you
for trying to bring this forward, and, of course, to Bruce for initiating the
thread.

I think that the syntax that has crystallized is a good starting point
for having
dedicated citation support in Org, so in the following I'll concentrate on some
of the infrastructure issues raised.

(i) Default ("built in") citation processor in Org

I think citeproc-el could be a reasonable solution for this. The core is
well-tested (thanks to the CSL test suite), implements a fairly large subset of
the CSL 1.01 standard, and can output citations in a number of formats including
in Org syntax. If I understood correctly, this would require citeproc-el to be
part of Emacs, and not even an ELPA package would suffice. In principle I'm open
to this, but I'm not familiar with the process and there are potential pitfalls,
e.g. citeproc-el currently depends on some "modern" libraries, e.g., "s" or
"dash" which AFAIK are not in Emacs.

(ii) Citation API

NG == Nicolas Goaziou wrote on 8 Apr 2020

  NG> 2. [ ] Decide about API Org should provide for it to be useful. Here are
  NG> some low hanging fruits:
  NG>- [ ] List all ".bib" files associated to the document,
  NG>- [ ] List all citations,
  NG>- [ ] Return citation key at point, if any.
  NG>- Anything else?

>From the citeproc-el (and CSL) perspective, the list of bibliography database
files, the place where the bibliography should be placed (if it's specified) and
the list of citations would be enough, I think. For the proper handling of
footnote-based styles it would be important to provide footnote information
about each citation: is a citation in a footnote and what is its footnote number
(index in the list of footnotes)? (citeproc-org contains a function to collect
this info.)

  NG> Moreover, we need to decide about how external processors could plug into
  NG> the export framework.
  NG>- [ ] For example, it could be a simple variable bound to a list of
  NG> functions. Each function accepts three arguments: the export back-end, as
  NG> a symbol, the full citation, as a list of triplets (key, prefix, suffix)
  NG> along with global prefix/suffix, and the usual INFO communication channel.
  NG> Does it need more?

Unfortunately I'm unfamiliar with the Org exporter, so this might not be a
problem at all, but there is a seemingly tricky point during export, related,
again, to footnotes in footnote-based citation styles: If a footnote style is
used and a citation is not already in a footnote then a footnote has to be
dynamically generated around the citation during export. The simplest way of
doing this is to wrap the rendered citation (which can contain backend-specific
font-properties, e.g. smallcaps) into an inline Org footnote block. E.g.,
citeproc-org, which basically acts as an Org->Org preprocessor, generates
dynamical footnote citations for html export along the lines of

[fn:: @@html:Gödel 1931@@]

If this scenario can be handled by the proposed mechanism then I don't expect
any other problems.

  NG>- [ ] Also, the prefix/suffix may contain some Org markup, so this
  NG> needs to be also processed. Should it happen before, or after the external
  NG> processor does its job? I.e., should the function translate into Org or
  NG> target format?

This is a very good (and a bit tricky...) question! Since the proposed Org
citation syntax does not contain locator-related slots, the citation processor
has to locate this information in the affixes (in citeproc-org, in the suffix),
parse and remove it. This part should definitely be done in Org format, so I'd
say the Org markup rendering should be after the citation rendering. (With the
proviso that part of the citation processor's output can already be rendered in
the target format as in the previous example.)

  NG> 3. [ ] Specify the kind of basic translation that be done out of the box?
  NG> Ideally, every non-derived back-end should do something, even basic.
  NG> Therefore, we need to propose some translation pattern for each of the
  NG> following:
  NG>- [ ] ASCII
  NG>- [ ] HTML
  NG>- [ ] LaTeX
  NG>- [ ] ODT
  NG>- [ ] Texinfo

As an Org->Org preprocessor, citeproc-org supports all these back-ends in the
sense that for HTML and LaTeX it outputs target specific rendering using the
@@latex and @@html syntax and generic Org for the rest.

(iii) Citation visualization

JK == John Kitchin wrote on 8 Apr 2020

  JK> org-ref relies very heavily on the link functionality to provide actions
  JK> on a cite, e.g. to open the pdf, or url, allow sorting, to change the cite
  JK> color when it is a bad key, etc If the new syntax also has that
  JK> capability

I'd add to this that it would be very useful if citations -- similarly to links
-- had a "descriptive" (as opposed to "literal") rendering mode in the buffer

bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

[Kévin Le Gouguec]

Eli Zaretskii  writes:

> Fixed.

AFAICT you've scared the moles away, so I'll boldly close this report.
Thanks a lot for the efficient whacking!

(I guess xdisp.c is something we won't to touch with a 10-foot pole on
the release branch, especially for a bug that users have lived with for
so long?)

bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

[Eli Zaretskii]

> From: Kévin Le Gouguec 
> Cc: 41...@debbugs.gnu.org,  dgu...@yandex.ru
> Date: Fri, 29 May 2020 20:11:40 +0200
> 
> This time, instead of hitting RET, insert a pair of parentheses, and
> wait blink-matching-delay seconds until the opening parenthesis stops
> being highlighted.  Before and after your fix, the line-prefix
> disappears until I enter another command.

Fixed.

bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

[Kévin Le Gouguec]

Eli Zaretskii  writes:

> Should be fixed now on the master branch.

Thanks a lot!

I'm sorry I didn't notice it earlier, but I may have found another mole
for you to whack; starting with the same recipe:

> - emacs -Q
> - C-x C-f repro.org
> - M-x org-indent-mode
> - M-: (insert "* heading\ntext")
> - M-:
> (let ((ov (make-overlay (point-at-bol) (point-at-bol)))
>   (val (propertize " " 'display '((left-fringe right-triangle)
>   (overlay-put ov 'before-string val))

This time, instead of hitting RET, insert a pair of parentheses, and
wait blink-matching-delay seconds until the opening parenthesis stops
being highlighted.  Before and after your fix, the line-prefix
disappears until I enter another command.

org-read-date-minibuffer-local-map should use C-n/p/f/b

[Alex Branham]

Hello -

I find it unintuitive that the usual calendar keys C-n/p/f/b don't work
when scheduling tasks in org mode (yes, I know about S-right, etc). I've
something like this to my init file for those four keys (based on their
setup in org-keys.el) for some time with no negative repercussions (that
I know about anyway), perhaps the same should be done for org itself?

#+begin_src emacs-lisp
(define-key org-read-date-minibuffer-local-map (kbd "C-n") (lambda () 
(interactive) (org-eval-in-calendar '(calendar-forward-week 1
#+end_src

Thanks,
Alex

Re: [random sorting] (was: org table: one column of random numbers (but natural ones))

[Stig Brautaset]

Uwe Brauer  writes:

 "SB" == Stig Brautaset  writes:
>
>>> > In row 67 you would have a random integer in the range [0..67)
>>> > f0 format removes any fractional part leaving only an integer number
>>> 
>>> Aha thanks, a minor thing, which I thank, cannot be really done:
>>> 
>>> Is it possible to avoid number repetition?
>>> 
>>> So I want a random sequence of the column 67 but I don't want numbers to
>>> be repeated.
>
>> To avoid duplicates you could generate a sequence from [0..67), shuffle
>> it[1], then use the row number as an index into that list. (Or pop off 
> the
>> front.) How to do that from an org table function I have no idea,
>> however.
>
> Thanks I tried in a row of 33
> $5=random([0..34]);f0
> $5=random([0..34));f0
> $5=random([0..33));f0
>
> But random repeats, however org-table-sort-lines sorts anyway
> And what I truly needed is a random sorting of sorts.

Right, I think I failed to make myself understood so here's an example
of what I had in mind. It's not convenient to use (need to execute
a source code block) but hopefully what I mean is a bit clearer, and
someone can clean it up a little :-)

First we need to generate a randomised sequence of unique integer in a
range, using the Knuth shuffle I pointed to earlier. Every time you run
tihs you get a new sequence. I've kept the output more to verify that
the results have unique output, as the table formula later will read
from the lisp variable, IIUC.

#+name: random-seq
#+begin_src emacs-lisp :var length=10 :results list
(defun nshuffle (sequence)
  (loop for i from (length sequence) downto 2
do (rotatef (elt sequence (random i))
(elt sequence (1- i
  sequence)

(setq random-seq (nshuffle (number-sequence 0 (1- length
#+end_src

#+RESULTS: random-seq
- 5
- 9
- 6
- 0
- 7
- 8
- 3
- 2
- 1
- 4

And now for the table that uses the variable. As we compute the
randomised sequence ahead of time for each invocation of the column
formula, and we can use each row number as an index into the sequence to
assign a unique, randomised integer from a range to each column.

| 0 | 5 |
| 1 | 9 |
| 2 | 6 |
| 3 | 0 |
| 4 | 7 |
| 5 | 8 |
| 6 | 3 |
| 7 | 2 |
| 8 | 1 |
| 9 | 4 |
#+TBLFM: $2='(nth (string-to-number $1) random-seq)


Possible improvements (that I don't think I'm up to making):

1. Don't require the column of indices to use as index into the sequence
2. Show how to do this without having the separate pre-compute step of
   the index (possibly with memoizing a sequence on first use?)

Hope this helps!

Regards,

Stig

Re: [Feature] add a new org-attach dispatcher command to offline save web page

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Matthew Lundin  writes:

> Ihor Radchenko  writes:
>
>>> As I said, PATCH welcome, I admired many times I don't have ability to 
>>> build a
>>> complex archive functionality on url.el or wget or curl.
>>
>> I have found the following solution [1] using wget:
>>
>> wget --mirror -p --convert-links -P ./LOCAL-DIR WEBSITE-URL
>>
>
> I don't think --mirror is what we want this context, since that will
> initiate a recursive download of the entire site. (Ironically, my IP is
> now banned from a personal blog that provides a how-to for using wget
> after I tried to run the above command on it.) From the wget manual:
>
> -m
> --mirror
> Turn on options suitable for mirroring.  This option turns on 
> recursion and
> time-stamping, sets infinite recursion depth and keeps FTP directory 
> listings.
> It is currently equivalent to -r -N -l inf --no-remove-listing.
>
> AFAICT, org-board uses the following options, which limit the archiving
> to a single page and all its resources:
>
> wget -e robots=off --page-requisites --adjust-extension --convert-links [...]

Interesting, Learned a new skill.

>
>> This will not bundle the page into a single file, but it is better than
>> nothing. org-attach does not have to attach exactly one file.
>
> You can also create a warc (web archive) file with wget, but then you
> need a web archive replayer to view it, which is not exactly convenient.
>

Looks like you already parsed most technologies in awesome-web-archive list.
Does that mean most technologies not suitable for Org Mode for now?

> Best,
>
> Matt


- -- 
[ 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-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7RORIUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsPyxwf5ATSzoz/vxLnlWGJ4jKxH/HtKlleE
LJP3BhLDuRl6nrjJTBYfwCM/SrFbcWQjpzLtoXFRvL6Ro60yhNWxCgYSu74WPF6B
Or3oEQrnQGvQ8SKNcyEOimXbKCUDImNetCAyLpxtbPJ0pHtf6py49p9i/M7ZTZK/
jIF2g0E1AezDwGPG00jpdO1cDOiGYczvRfaaMr2OQ1EBtDrZOn5z+Cb6YiaHqfF5
x5HT5Z8fCqxAFOj9ixzOdqZ9C2hRncxATyiSFH0vAzwDYpYw9A20ZqoevThTVZRI
IUmirJM7pUQ4MM2SXidkLaT5T/Zuy4PjCrM8yfXybbnrSkWrVgjeEpXhYg==
=gsT0
-END PGP SIGNATURE-

Re: [Feature] add a new org-attach dispatcher command to offline save web page

[Matthew Lundin]

Ihor Radchenko  writes:

>> As I said, PATCH welcome, I admired many times I don't have ability to build 
>> a
>> complex archive functionality on url.el or wget or curl.
>
> I have found the following solution [1] using wget:
>
> wget --mirror -p --convert-links -P ./LOCAL-DIR WEBSITE-URL
>

I don't think --mirror is what we want this context, since that will
initiate a recursive download of the entire site. (Ironically, my IP is
now banned from a personal blog that provides a how-to for using wget
after I tried to run the above command on it.) From the wget manual:

-m
--mirror
Turn on options suitable for mirroring.  This option turns on recursion 
and
time-stamping, sets infinite recursion depth and keeps FTP directory 
listings.
It is currently equivalent to -r -N -l inf --no-remove-listing.

AFAICT, org-board uses the following options, which limit the archiving
to a single page and all its resources:

wget -e robots=off --page-requisites --adjust-extension --convert-links [...]

> This will not bundle the page into a single file, but it is better than
> nothing. org-attach does not have to attach exactly one file.

You can also create a warc (web archive) file with wget, but then you
need a web archive replayer to view it, which is not exactly convenient.

Best,

Matt

bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

[Eli Zaretskii]

> Date: Fri, 29 May 2020 10:12:27 +0300
> From: Eli Zaretskii 
> Cc: 41...@debbugs.gnu.org, dgu...@yandex.ru
> 
> In fact, it's enough to type "M-x".  Which is a clear sign that some
> redisplay optimization kicks in where it shouldn't.  And indeed,
> setting inhibit-try-window-id non-nil solves the problem.
> 
> I will look into this when I have time, thanks for an easy reproducer.

Should be fixed now on the master branch.

Failing tests (was: Possible fix for :includes header argument in org-babel C source blocks)

[Kévin Le Gouguec]

Kyle Meyer  writes:

> The source for that page is in the worg repo:
> https://code.orgmode.org/bzg/worg/src/master/org-contrib/babel/languages/ob-doc-C.org

Thanks for the pointer, and for applying the patches!

>>>   FAILED  ob-tangle/jump-to-org
>>>   FAILED  test-org-attach/dir
>
> :(
>
> After your first patch, all tests now pass on my end.  Would you mind
> posting the details of those failures in a new thread?

Mmm, on further inspection, those tests fail on one of my setups but
pass on another.

I think I've narrowed this down to org-open-file running "less
examples/att1/fileA" instead of visiting this file.

The following snippet returns "less '%s'" on the failing setup, and nil
on the passing one:

#+begin_src elisp
(mailcap-mime-info (mailcap-extension-to-mime ""))
#+end_src

IIUC this comes from /etc/mailcap; the failing setup (Xubuntu 18.04) has
an entry saying "less '%s'" for "text/plain"; the passing setup
(OpenSUSE Tumbleweed) simply has no /etc/mailcap.  mailcap-mime-info
falls back to "text/plain" when mailcap-extension-to-mime returns nil.

Let-binding org-file-apps to '(("." . emacs)) makes the tests pass, but
I don't know if that's the way we want to solve this.

Re: [random sorting]

[Eric S Fraga]

On Friday, 29 May 2020 at 13:19, Uwe Brauer wrote:
> But random repeats, however org-table-sort-lines sorts anyway
> And what I truly needed is a random sorting of sorts.

(now that I am awake... ;-))

What you want is a "permutation" vector.  Calc does appear to have some
support for permutation vectors but I'm not sure it has what you need to
create a random permutation.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc

[random sorting] (was: org table: one column of random numbers (but natural ones))

[Uwe Brauer]

>>> "SB" == Stig Brautaset  writes:

   >> > In row 67 you would have a random integer in the range [0..67)
   >> > f0 format removes any fractional part leaving only an integer number
   >> 
   >> Aha thanks, a minor thing, which I thank, cannot be really done:
   >> 
   >> Is it possible to avoid number repetition?
   >> 
   >> So I want a random sequence of the column 67 but I don't want numbers to
   >> be repeated.

   > To avoid duplicates you could generate a sequence from [0..67), shuffle
   > it[1], then use the row number as an index into that list. (Or pop off the
   > front.) How to do that from an org table function I have no idea,
   > however.

Thanks I tried in a row of 33
$5=random([0..34]);f0
$5=random([0..34));f0
$5=random([0..33));f0

But random repeats, however org-table-sort-lines sorts anyway
And what I truly needed is a random sorting of sorts.


smime.p7s
Description: S/MIME cryptographic signature

Re: Possible fix for :includes header argument in org-babel C source blocks

[Kévin Le Gouguec]

Brandon Guttersohn  writes:

> Apologies for the regression, and thank you for fixing it. I neglected
> to run the tests before suggesting that fix -- I'll try not to do that
> again..

No biggie, that got me to finally try out Babel ;)


I don't know if it's been mentioned in the "issue tracker?" thread, but
if I could pick just *one* feature off web-based forges, it'd be
automated testing with CI…

I find the "make-test-before-commit" discipline easy enough to adhere to
at $DAYJOB; it's not as straightforward when contributing to free
software, when I'm frequently pressed for time, running on battery on a
low-end laptop…

Running a few unit tests is not a big deal, but it's not trivial to
anticipate which ones to run; test-foo.el is rarely enough to catch
regressions introduced by tweaking foo.el.  

Having something (e.g. emba.gnu.org) pick up patches sent to the mailing
list and report new test failures would be very helpful, for
contributors if not for maintainers.
 

> I can at least confirm that the patch wasn't intended to change how
> C-header-files are specified in the org-babel-block-header. The goal
> was only to change how the headers are formatted in the generated
> C-language file during execution, and only for headers which were not
> wrapped in <>'s.

OK; IIUC, before the patch it was not possible to generate double-quoted
includes short of backslash-escaping the double quotes; that's why I
assumed that the goal of the patch was to make it easier to use
double-quoted includes, which I thought worth advertising in ORG-NEWS.

Emacs brings itself to the foreground when preparing agenda with org-agenda-include-diary t

[Friedrich Delgado]

Hi!

I've set up my emacs to prepare the org-agenda whenever I start it up.

While emacs starts up, I'm doing other things and it's frequently annoying
me that emacs brings itself to the foreground (with qtile, if that's
relevant).

I've come up with the following minimal configuration that reproduces the
issue for me (via emacs -Q -l ~/minimal-org.el):


,[ minimal-org.el ]
(require 'package)
(add-to-list 'package-archives '("org" . "https://orgmode.org/elpa/";) t)
(package-initialize)
(add-to-list 'load-path "~/lib/emacs/use-package/")
(require 'use-package)

(use-package org
:ensure org-plus-contrib)

(define-key global-map "\C-ca" 'org-agenda)
(custom-set-variables
'(org-agenda-files (quote ("~/Org/Collect.org" "~/Org/Common.org"
"~/Org/Rechner.org" "~/Org/home/Familie.org" "~/Org/home/Haus.org"
"~/Org/home/Gesundheit.org" "~/Org/home/Musik.org" "~/Org/home/Rechner.org"
"~/Org/home/Sonstiges.org" "~/Org/home/Weiterentwicklung.org"
"~/Org/work/Cert.org")))
'(org-agenda-include-diary t))
`

When I comment out org-agenda-include-diary or set it to nil, the behaviour
disappears.

When I comment out my extensive set of large org-mode files, the behaviour
disappears as well, but maybe just because I'm not fast enough to switch
away from emacs before it happens.

I'd like to be able to use org-agenda-include-diary but disable the
behaviour that emacs raises itself.

Please CC me in replies, as I'm not subscribed to this list.

For completeness, I've been asked to file an issue against qtile, because
they want to be able to prevent such behaviour from clients on the window
manager side, and they're also dealing with focus problems recently.
https://github.com/qtile/qtile/issues/1756

Best regards
Friedel

Re: bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

[Eli Zaretskii]

> From: Kévin Le Gouguec 
> Date: Thu, 28 May 2020 21:54:09 +0200
> Cc: emacs-orgmode@gnu.org, Dmitry Gutov 
> 
> - emacs -Q
> - C-x C-f repro.org
> - M-x org-indent-mode
> - M-: (insert "* heading\ntext")
> - M-:
> (let ((ov (make-overlay (point-at-bol) (point-at-bol)))
>   (val (propertize " " 'display '((left-fringe right-triangle)
>   (overlay-put ov 'before-string val))
> - RET
> - a
> 
> When "a" is inserted, org-indent-mode's line-prefix disappears on the
> *previous* line ("text").  It remains gone as long as I type
> self-inserting characters, until
> 
> - I type certain commands, e.g. RET or C-j, or
> 
> - I insert a closing delimiter that makes
>   blink-paren-post-self-insert-function blink the corresponding opening
>   delimiter, e.g. ')' or ']'.
> 
> Then the line-prefix shows up again.

In fact, it's enough to type "M-x".  Which is a clear sign that some
redisplay optimization kicks in where it shouldn't.  And indeed,
setting inhibit-try-window-id non-nil solves the problem.

I will look into this when I have time, thanks for an easy reproducer.