Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Eric Abrahamsen]

Jens Schmidt  writes:

> Uh, I had technical issues and did not get all mails as I expected.
> Cobbling things together in one big reply now, with references and
> quotes hopelessly broken ... hope you can sort it out.
>
> Anyway, thanks to Eric for chiming in.
>
>> Ideally, it would be nice to have tests, though I have no clue how to
>> approach writing them.
>
> I have created a somewhat minimal Gnus setup to develop and test this
> patch on my development laptop, where I normally do not use Gnus.  It
> consists of a bunch of files and directories and a bit of configuration.
> I can follow up on this if you like, but preferably in a separate
> thread.

Someone mentioned gnus-mock in the other thread, which I made for
exactly these scenarios. It's a bit hairy making a Gnus installation
from nothing -- if you try it out and would like it to do something
different, I'd be interested in feedback.

>>> If we're currently in article-mode. The call to
>>> `gnus-article-show-summary' would protect against the case where the
>>> summary buffer has been killed in the meantime [...].
>
> Not really.  The following executed in an article buffer:
>
>   (progn
>(kill-buffer gnus-summary-buffer)
>(gnus-article-show-summary))
>
> results in
>
>   Debugger entered--Lisp error:
>   (error "There is no summary buffer for this article buffer")
> signal(error ("There is no summary buffer for this article buffer"))
> error("There is no summary buffer for this article buffer")
> gnus-article-show-summary()
> [...]
>
> Which, OTOH, shows that I was wrong in one aspect: Gnus at least in some
> cases *does* give a reasonable error message when the summary buffer for
> an article buffer is gone.
>
>>> Probably it would be enough to wrap the whole containing `let*' in a
>>> (with-current-buffer gnus-summary-buffer ...). If we're already in the
>>> summary buffer, no harm done.
>>
>> I am not sure if it is safe.
>> There is
>> (save-window-excursion (gnus-summary-select-article))
>> which calls (set-buffer gnus-summary-buffer)
>
> I agree with Ihor here and would rather go for individual wraps into
> `with-current-buffer'.  As I have done in my patch already,
> incidentially.

Somehow I missed that this whole thread started with an actual patch!
Sorry, that should have been the subject of discussion the whole time. I
can help with applying it, once all issues are resolved.

Thanks,
Eric

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Eric Abrahamsen]

Ihor Radchenko  writes:

> Eric Abrahamsen  writes:
>
>> We should definitely be using the paradigm above (using the
>> gnus-summary-buffer as the current buffer). The article number fetching
>> only works by accident in the article buffer, and other stuff (like
>> finding the original nnselect group name) won't work at all.
>
> I am convinced then.
> Ideally, it would be nice to have tests, though I have no clue how to
> approach writing them.
>
>> Later in the function we've got this:
>>
>> (save-window-excursion
>>   (save-excursion
>> (gnus-article-show-summary)
>> (gnus-summary-article-header)))
>>
>> If we're currently in article-mode. The call to
>> `gnus-article-show-summary' would protect against the case where the
>> summary buffer has been killed in the meantime, but I agree that's kind
>> of a pathological case.
>
> I'd say that the patch will be an improvement anyway.
>
>> Probably it would be enough to wrap the whole containing `let*' in a
>> (with-current-buffer gnus-summary-buffer ...). If we're already in the
>> summary buffer, no harm done.
>
> I am not sure if it is safe.
> There is
> (save-window-excursion (gnus-summary-select-article))
> which calls (set-buffer gnus-summary-buffer)
>
> `with-current-buffer' will certainly alter how things work (although,
> switching buffer when capturing link is already fishy).

Ugh, this whole thing is a mess. I think the first question is: should
this function "fix" the state of Gnus before it makes a link? Should it
attempt to re-open the Summary buffer if it's been closed? Should it
switch current articles if the open article buffer is not the one that
point is on in the Summary buffer?

If we make a decision about that, then it should be easier to decide how
to handle the code changes themselves.

Eric

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Eric Abrahamsen]

Jens Schmidt  writes:

> On 2023-07-22  15:48, Ihor Radchenko wrote:
>
>> I am not familiar with Gnus, but looking at the code, may it be that
>> a Gnus article is open when Gnus summary buffer is not?
>
> Theoretically yes, if you actively and malignantly kill the summary
> buffer, for example.  In practice and through Gnus key bindings, this
> should not happen.  IOW, Gnus stops behaving reasonably as well if you
> kill the summary buffer other than through Gnus key bindings
> ("Selecting deleted buffer", etc.).
>
> If you check function `gnus-summary-work-articles' from gnus-sum.el, the
> main work horse for article processing and also good for calling in
> article buffers, you will note (focusing on the default case) the same
> paradigm
>
>   (with-current-buffer gnus-summary-buffer
> (cond
>  [...]
>  (t
>   ;; Just return the current article.
>   (list (gnus-summary-article-number))
>
> As a last resort we could also try to drag in Andrew Cohen as a
> reviewer, he has been helpful already with one or two of my Gnus bugs.

We should definitely be using the paradigm above (using the
gnus-summary-buffer as the current buffer). The article number fetching
only works by accident in the article buffer, and other stuff (like
finding the original nnselect group name) won't work at all.

Later in the function we've got this:

(save-window-excursion
  (save-excursion
(gnus-article-show-summary)
(gnus-summary-article-header)))

If we're currently in article-mode. The call to
`gnus-article-show-summary' would protect against the case where the
summary buffer has been killed in the meantime, but I agree that's kind
of a pathological case.

Probably it would be enough to wrap the whole containing `let*' in a
(with-current-buffer gnus-summary-buffer ...). If we're already in the
summary buffer, no harm done.

Eric

Re: Bug in orgalist mode's advice on indent-according-to-mode

[Eric Abrahamsen]

Eric Abrahamsen  writes:

> Tim Cross  writes:
>
>> Eric Abrahamsen  writes:
>>
>>> In Emacs commit f596f0db82c0b1ff3fe8e8f1d8b07d2fe7504ab6, from Nov 2021,
>>> the function `indent-according-to-mode' was given an optional
>>> inhibit-widen argument. That argument being passed causes orgalist's
>>> advice to fail, as the lambda doesn't accept any additional arguments.
>>> One way to fix it would be like that:
>>>
>>>  (unless (advice-member-p 'orgalist-fix-bug:31361 'indent-according-to-mode)
>>>(advice-add 'indent-according-to-mode
>>>:around (lambda (old  inhibit-widen)
>>>  "Workaround bug#31361."
>>>  (or (orgalist--indent-line)
>>>  (let ((indent-line-function
>>> (advice--cd*r indent-line-function)))
>>>(funcall old inhibit-widen
>>>'((name . orgalist-fix-bug:31361)
>>>
>>> Or I suppose a more future-proof approach might be to use a  and
>>> then `apply' instead of `funcall'.
>>>
>>
>> A better solution would probably be to fix this without using
>> add-advice. While advice can be a useful escape hatch, it really is best
>> avoided, especially given that it doesn't always play nice with lexical
>> binding. I note this one is also calling an undocumented internal
>> function. 
>
> In principle I quite agree! But orgalist is basically built on top of
> add-function/advice-add, so I didn't think that was an option. And
> also assumed that, given what Orgalist is trying to do, there isn't a
> cleaner solution right now.

What do you think, Nicolas? Can I patch this to use  and `apply'?

Re: Bug in orgalist mode's advice on indent-according-to-mode

[Eric Abrahamsen]

Tim Cross  writes:

> Eric Abrahamsen  writes:
>
>> In Emacs commit f596f0db82c0b1ff3fe8e8f1d8b07d2fe7504ab6, from Nov 2021,
>> the function `indent-according-to-mode' was given an optional
>> inhibit-widen argument. That argument being passed causes orgalist's
>> advice to fail, as the lambda doesn't accept any additional arguments.
>> One way to fix it would be like that:
>>
>>  (unless (advice-member-p 'orgalist-fix-bug:31361 'indent-according-to-mode)
>>(advice-add 'indent-according-to-mode
>>:around (lambda (old  inhibit-widen)
>>  "Workaround bug#31361."
>>  (or (orgalist--indent-line)
>>  (let ((indent-line-function
>> (advice--cd*r indent-line-function)))
>>(funcall old inhibit-widen
>>'((name . orgalist-fix-bug:31361)
>>
>> Or I suppose a more future-proof approach might be to use a  and
>> then `apply' instead of `funcall'.
>>
>
> A better solution would probably be to fix this without using
> add-advice. While advice can be a useful escape hatch, it really is best
> avoided, especially given that it doesn't always play nice with lexical
> binding. I note this one is also calling an undocumented internal
> function. 

In principle I quite agree! But orgalist is basically built on top of
add-function/advice-add, so I didn't think that was an option. And
also assumed that, given what Orgalist is trying to do, there isn't a
cleaner solution right now.

Bug in orgalist mode's advice on indent-according-to-mode

[Eric Abrahamsen]

In Emacs commit f596f0db82c0b1ff3fe8e8f1d8b07d2fe7504ab6, from Nov 2021,
the function `indent-according-to-mode' was given an optional
inhibit-widen argument. That argument being passed causes orgalist's
advice to fail, as the lambda doesn't accept any additional arguments.
One way to fix it would be like that:

 (unless (advice-member-p 'orgalist-fix-bug:31361 'indent-according-to-mode)
   (advice-add 'indent-according-to-mode
   :around (lambda (old  inhibit-widen)
 "Workaround bug#31361."
 (or (orgalist--indent-line)
 (let ((indent-line-function
(advice--cd*r indent-line-function)))
   (funcall old inhibit-widen
   '((name . orgalist-fix-bug:31361)

Or I suppose a more future-proof approach might be to use a  and
then `apply' instead of `funcall'.

Eric

Re: How do you manage complex project with Org-mode

[Eric Abrahamsen]

Sébastien Gendre  writes:

> Hello Eric,
>
> Thanks for your reply and advice.
>
> I will look at custom agenda view and clocking. But I have bad memory of
> clocking tools because of the way previous jobs used it (It was not
> Emacs).

It's a much more positive experience when you're using it to improve
your own quality of life, rather than someone else's business metrics!

Re: How do you manage complex project with Org-mode

[Eric Abrahamsen]

Sébastien Gendre  writes:

> Hello,
>
> I don't know if it's the correct place to ask it. If not, sorry to ask in
> the wrong place.
>
> How do you manage complex project with Org-mode ?
>
> I used Org-mode for several periods of time in recent years. It worked
> very well for short and day to day tasks. When only a few of theme have
> deadlines and when you have plenty of time to do them.
>
> But, as a student, I regularly have big and important projects to do for
> the school. The kind of project who need several days to be done, with
> deadlines too soon, and if you fail one them the consequences can be
> disastrous. And generally, I have to many of these project in the same
> time and not enough time to do all the work. So, I also need to follow
> the progress of each project to choose which is sufficiently advanced to
> be stop for the benefit of another less advanced project.
>
> And I don't know how to manage this kind of projects with Org-mode. How
> to do it, without failing a 6 days project because I spent to much time
> on something else and I have only 3 days left with 3 half-day important
> appointment I cannot cancel. I can't risk failing a single one of these
> project by trying. So, when I am in a period with a lot of these
> projects, I stop using Org-mode and concentrate on doing these project
> as fast as I can. And because I often have this kind of project, I spend
> most of the year without being able to use Org-mode.
>
> So, if you have any suggestion on how to manage, in Org-mode, projects
> with:
> * Lot of work to do (many days)
> * Short deadline (not enough time)
> * High importance (disastrous consequences in my future in case of fail)
> * Many of them in the same time
> * Progression need to be followed to chose where to sacrifice time to
>   limit the damages

Interesting questions! I have the same general problem of, when things
heat up too much, I stop using the Org agenda. It's quite the opposite
of how it's supposed to work, but I guess it's something about human
psychology. I'll be interested to see what people say in this thread.

Some suggestions that come to mind:

- Create custom agenda views for each project, providing an overview of
  that project only, but use a single unified agenda view for each day's
  schedule. Look at the per-project agenda to decide if/how to complete
  it, but draw the action items into the unified schedule when deciding
  how to spend your day. It should become evident pretty quickly what
  you actually have time for. Projects are many, but there is only one
  of you.
- Maybe consider using `org-trigger-hook' and `org-blocker-hook' to cut
  down on TODO overwhelm.
- Use time estimates and then TODO clocking to more swiftly disabuse
  yourself of unrealistic expectations. This plus a schedule agenda can
  also help you make sure you stop work at a reasonable time and go do
  something else.
- Say no to more work :) Looking at your solid-packed agenda for the
  next day works wonders for saying no.

Good luck!

Re: org-table-blank-field key binding removal

[Eric Abrahamsen]

Kyle Meyer  writes:

> Michael Brand writes:
>
>> The change is not announced in ORG-NEWS. I think it should be in Version 9.4.
>
> Right, I agree this change should have come with a NEWS entry, though
> 0c4e844c8 (Remove default binding for org-table-blank-field, 2021-04-28)
> is from the 9.5 release not 9.4.
>
> However, 9.5 is out, and my understanding is that released NEWS sections
> should not be substantially modified in most cases
> ().  I'll leave it to
> the author of the original change and Bastien to decide if they want to
> make an exception in this case.

I also agree it should have had a NEWS entry (something I never
remember), but don't have much of an opinion on whether that entry gets
added after the fact or not!

Re: [PATCH] minor typo fix in org-tutorials/org-protocol-custom-handler.org

[Eric Abrahamsen]

Tim Cross  writes:

> this is a trivial fix and should be applied.
>
> Atlas Cove  writes:
>
>> From: Atlas48 
>>
>> As it says, this is a minor fix to worg.

Turns out I have push access; in it goes!

Re: Bug: ODT export of Chinese text inserts spaces for line breaks

[Eric Abrahamsen]

Maxim Nikulin  writes:

> On 29/06/2021 10:47, James Harkins wrote:
>> So, it would make sense to add a rule to the exporter: if one of the
>> characters before or after a source-text line break is a Chinese,
>> Japanese or Korean character, do not add a space.
>
> On 29/06/2021 11:43, tumashu wrote:
>> You can try the below config :-)
>>      (let ((regexp "[[:multibyte:]]")
>>    (string text))
>>    (setq string
>>      (replace-regexp-in-string
>>   (format "\\(%s\\) *\n *\\(%s\\)" regexp regexp)
>>   "\\1\\2" string))
>
> Notice that [[:multibyte:]] means almost any non-ASCII script, e.g.
> Cyrillic:
>
> (let ((sample "abc абв def"))
>   (and (string-match "[[:multibyte:]]\+" sample)
>(match-string 0 sample)))
> "абв"
>
> It seems, `org-fill-paragraph' M-q is smart enough to avoid a space
> before or after a CJK character, so it is possible to determine
> correct way to splice lines, despite e.g. "Script" Unicode property is
> not exposed to elisp:
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Character-Properties.html
> (Anyway maintaining explicit list of scripts is not a straightforward
> approach.)

There are a few ways to approach this:

(aref char-script-table ?中) -> 'han

(string-match-p "\\cc" "中") -> 0

(aref (char-category-set ?中) ?|) -> t

Re: Free up C-c SPC/org-table-blank-field?

[Eric Abrahamsen]

On 04/28/21 05:50 AM, Bastien wrote:
> Eric Abrahamsen  writes:
>
>> That took a while, for such a simple patch! Hope this is acceptable.
>
> ... and it took a while to install it, but finally done with commit
> 7a1c8cadf. 
>
> Thanks!

Awesome, thank you!

Re: Free up C-c SPC/org-table-blank-field?

[Eric Abrahamsen]

Carsten Dominik  writes:

> On Fri, Feb 5, 2021 at 7:33 PM Eric Abrahamsen 
> wrote:
>
>> Carsten Dominik  writes:
>>
>> > On Fri, Feb 5, 2021 at 11:13 AM Christian Moe 
>> wrote:
>> >
>> >>
>> >> Tim Cross writes:
>> >>
>> >> > Eric Abrahamsen  writes:
>> >> >
>> >> >>> Does it actually need a key binding? I've never used it and just use
>> >> >>>  to move to the next field, leaving the field blank.
>> >> >>
>> >> >> I assume it's meant for blanking a field you've already typed
>> something
>> >> >> into. But yes, I can't imagine it's a heavily-used command, and I
>> >> >> suspect the C-c  binding is mostly mnemonic: "make this field
>> >> >> contain only blanks".
>> >> >>
>> >> >
>> >> > I guess that makes sense, but not convinced the use of a valuable key
>> >> > binding is justified given the need. Then again, others probably have
>> >> > vastly different use cases to mine.
>> >>
>> >> One can also blank a field by pressing  immediately after tabbing
>> >> into it. So C-c  isn't strictly needed.
>> >>
>> >
>> > Hi,
>> >
>> > I think there would be minimal impact from releasing this key binding.
>> So
>> > I think we could remove it.
>>
>> Well that would be pretty nice, if you don't think it would be too
>> disruptive. Shall I prepare a patch?
>>
>
> I am not taking the decisions, but I would say: yes, please do.

That took a while, for such a simple patch! Hope this is acceptable.

Thanks,
Eric

>From c7d246b20f56bcc89a23d523ebf64a2f67c58bc6 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Thu, 4 Mar 2021 11:44:12 -0800
Subject: [PATCH] Remove default binding for org-table-blank-field

* lisp/org-keys.el: The command isn't useful enough to occupy such a
useful keybinding as "C-c SPC".
---
 lisp/org-keys.el | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index f0fdb79ea..07ff85349 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -174,7 +174,6 @@
 (declare-function org-show-subtree "org" ())
 (declare-function org-sort "org" ( with-case))
 (declare-function org-sparse-tree "org" ( arg type))
-(declare-function org-table-blank-field "org" ())
 (declare-function org-table-copy-down "org" (n))
 (declare-function org-table-create-or-convert-from-region "org" (arg))
 (declare-function org-table-create-with-table\.el "org-table" ())
@@ -620,7 +619,6 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names."
 (org-defkey org-mode-map (kbd "RET") #'org-return)
 (org-defkey org-mode-map (kbd "C-j") #'org-return-and-maybe-indent)
 (org-defkey org-mode-map (kbd "C-c ?") #'org-table-field-info)
-(org-defkey org-mode-map (kbd "C-c SPC") #'org-table-blank-field)
 (org-defkey org-mode-map (kbd "C-c +") #'org-table-sum)
 (org-defkey org-mode-map (kbd "C-c =") #'org-table-eval-formula)
 (org-defkey org-mode-map (kbd "C-c '") #'org-edit-special)
-- 
2.30.1

Re: Free up C-c SPC/org-table-blank-field?

[Eric Abrahamsen]

Carsten Dominik  writes:

> On Fri, Feb 5, 2021 at 11:13 AM Christian Moe  wrote:
>
>>
>> Tim Cross writes:
>>
>> > Eric Abrahamsen  writes:
>> >
>> >>> Does it actually need a key binding? I've never used it and just use
>> >>>  to move to the next field, leaving the field blank.
>> >>
>> >> I assume it's meant for blanking a field you've already typed something
>> >> into. But yes, I can't imagine it's a heavily-used command, and I
>> >> suspect the C-c  binding is mostly mnemonic: "make this field
>> >> contain only blanks".
>> >>
>> >
>> > I guess that makes sense, but not convinced the use of a valuable key
>> > binding is justified given the need. Then again, others probably have
>> > vastly different use cases to mine.
>>
>> One can also blank a field by pressing  immediately after tabbing
>> into it. So C-c  isn't strictly needed.
>>
>
> Hi,
>
> I think there would be minimal impact from releasing this key binding.  So
> I think we could remove it.

Well that would be pretty nice, if you don't think it would be too
disruptive. Shall I prepare a patch?

Thanks,
Eric

Re: Free up C-c SPC/org-table-blank-field?

[Eric Abrahamsen]

Kyle Meyer  writes:

> Eric Abrahamsen writes:
>
>> Hi all,
>>
>> The C-c SPC keybinding is pretty prime property (it's also, according to
>> Emacs conventions, meant to be reserved for the user, though I know
>> that's already out the window with Org),
>
> Based on my reading of (info "(elisp)Key Binding Conventions"), I think
> `C-c SPC` doesn't fall into the user's `C-c LETTER' territory but
> instead into the this group:
>
>   Sequences consisting of ‘C-c’ followed by any other ASCII
>   punctuation or symbol character are allocated for minor modes.
>   Using them in a major mode is not absolutely prohibited, but if you
>   do that, the major mode binding may be shadowed from time to time
>   by minor modes.

Oh, interesting, thanks -- I've always found that section impossible to
remember, and it seems to often be disregarded, anyway. In this case, I
guess we could consider the keybinding to be kind of "minor-mode-ish",
if you thought of commands that operate on Org tables to be like a minor
mode that's only active when point is inside a table.

[...]

>> But, either way, I don't disagree with what you say next.
>>
>>> and it's currently bound to `org-table-blank-field', which is useless
>>> unless you... happen to be in a table. I don't use tables often (or
>>> blank fields when I do), which means this binding is effectively just
>>> removed.
>
> Does it actually need a key binding? I've never used it and just use
>  to move to the next field, leaving the field blank.

I assume it's meant for blanking a field you've already typed something
into. But yes, I can't imagine it's a heavily-used command, and I
suspect the C-c  binding is mostly mnemonic: "make this field
contain only blanks".

>>>
>>> What do people think about making it a no-op when not on a table
>>> (letting it fall through to the global map), or putting it in a keymap
>>> text property on tables, or otherwise not hogging the binding?
>>
>> In my view, the first would be fine, and the second also unless someone
>> chimes in with a technical reason not to. For the last, perhaps `C-c
>> C-SPC' would be an okay replacement, though I'd assume that would break
>> some users' muscle memory in a surprising and unpleasant way.
>
> I'm not familiar with how this is all put together inside org mode.
> If it is possible to configure things so that it is only bound when
> inside a table and does not shadow other bindings for that sequence
> outside a table, I think that would be a positive change. However, I do
> also note that this is the type of change which tends to cause 'ripples'
> and may have unexpected impact in other areas, such as other packages,
> predefined or 'canned' emacs configurations etc.

The way Org handles these situations now is to have a command that is
named for its actual keybinding (eg `org-shiftmetaleft'), which then
examines its context and dispatches to various other functions. That's a
bit odd and not really how it's done in Emacs -- but I am not proposing
we change this as it is pretty fundamental to how Org is set up and
would wreck a bunch of stuff if it were changed.

I thought Emacs might have some easy way to let a key event "fall
through" to other keymaps, but I haven't been able to find anything
immediately obvious. Maybe I can ask on emacs.devel...

Eric

Free up C-c SPC/org-table-blank-field?

[Eric Abrahamsen]

Hi all,

The C-c SPC keybinding is pretty prime property (it's also, according to
Emacs conventions, meant to be reserved for the user, though I know
that's already out the window with Org), and it's currently bound to
`org-table-blank-field', which is useless unless you... happen to be in
a table. I don't use tables often (or blank fields when I do), which
means this binding is effectively just removed.

What do people think about making it a no-op when not on a table
(letting it fall through to the global map), or putting it in a keymap
text property on tables, or otherwise not hogging the binding?

Thanks,
Eric

Re: Reply-All noise

[Eric Abrahamsen]

Tim Cross  writes:

> Eric S Fraga  writes:
>
>> On Sunday, 11 Oct 2020 at 16:35, c.bu...@posteo.jp wrote:
>>> From my point of view mailinglists and web-forums are a step back in
>>> usability and efficiency.
>>
>> On this, we can definitely agree!  Newsgroups are still the best way to
>> have these types of conversations.
>>
>>> But there is just one exception (just IMO): StackExchange e.g.
>>> StackOverflow. ;)
>>
>> But here I disagree: I hate using the browser for anything other than
>> reading or banking.  But that's me.
>
> I am the same. One thing I do which has reduced the pain is to use the
> 'Edit with Emacs' Chrome extension. At least now, when I'm required to
> provide text input, I can do so from within Emacs.
>
> There is also an Emacs mode for stackOverflow/stackExchange sites. I've
> not used it for a while, but it wasn't too bad and would allow you to do
> your SO searching/browsing/replying from within Emacs. Main drawback was
> the auth2 stuff - you have to use the web browser to get a login token.
>
> I do miss the old newsgroups. I use to very much enjoy starting my day
> with a Gnus+NNTP session!

Some of us are stilling starting the day that way :)

Re: [feature request] A new cookie type [!] showing the last note taken

[Eric Abrahamsen]

  (and (string-match "State \\([^[:space:]]*\\) " head-par)
 (match-string 1 head-par)))
  (setq state-from
(and (string-match "from \\([^[:space:]]*\\) " head-par)
 (match-string 1 head-par)))
  
   log-list));;; org-log.el --- Quantitative logging for Org headings  -*- lexical-binding: 
t; -*-

;; Copyright (C) 2019  Free Software Foundation, Inc.

;; Author: Eric Abrahamsen 
;; Maintainer: Eric Abrahamsen 

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;; This library provides hooks and functions for quantitative logging
;; in Org: meaning that storing a log note may prompt for one or more
;; quantitative values, and store them as part of the note.  Those
;; values can later be viewed as tables.  Essentially this is a
;; generalization of org-clock, to allow logging of other values.
;; Like org-clock, it also includes a command to view logged data as
;; an Org table.

;; In terms of format, a logged value appears as an all-caps label,
;; followed by a colon, followed by the data itself, followed by a
;; semi-colon.  For instance:

;; BP: 120/60; PULSE: 45;

;; The `org-log-buffer-setup-hook' is used to prompt the user for log
;; values to store.  It does this by looking for a LOG_VALUES property
;; on the heading, which should be a space-separated list of all-caps
;; value labels.  These labels can also contain information about the
;; units used for the value.  Units are specified immediately after
;; the value label in square brackets, like so:

;; DISTANCE[mi]

;; This unit information will be automatically incorporated into
;; tables created to view logged data.  Call the
;; `calc-view-units-table' command to see all valid units; you can
;; define new units using `calc-define-unit', which see.

;;; Code:

(require 'org)
(require 'calc-units)

(defun org-log-prompt ()
  "Prompt the user for log values.
Insert values into the current log note."
  ;; This is called in the log buffer.  Only fire for state and note;
  ;; later add clock-out.
  (when (memq org-log-note-purpose '(state note))
(let ((values
   (with-current-buffer (marker-buffer org-log-note-marker)
 (save-excursion
   (goto-char org-log-note-marker)
   (org-entry-get (point) "LOG_VALUES" 'selective)
  (when (and (stringp values) (null (string-empty-p values)))
(unless (bolp)   ; This might follow a clock line.
  (insert "; "))
(dolist (val (split-string values))
  ;; Maybe strip off units.
  (setq val (substring val 0 (string-match-p "\\[" val)))
  (insert val ": ")
  (insert (read-string (format "%s: " val)) "; "))

(defun org-log--collect-data (id)
  "Collect log data from heading with id ID.
When valid data is found, it is returned as a list of lists.
Each sublist starts with the timestamp of the log entry, followed
by data keys and values, in the order they were found in the log
entry.

If no valid data is found, return nil."
  (save-excursion
(org-id-goto id)
(goto-char (org-log-beginning))
(let* ((struct (org-list-struct))
   (labels (org-entry-get (point) "LOG_VALUES" 'selective))
   (entries (when (and (stringp labels)
   (null (string-empty-p labels)))
  ;; First element is a list of value labels.
  (list (cons "TIMESTAMP"
  (mapcar (lambda (str)
(substring
 str 0 (string-match-p "\\[" str)))
  (split-string labels))
   elt data)
  (when (and entries struct)
;; Get onto the list item.
(forward-char)
(while (equal 'item (org-element-type
 (setq elt (org-element-at-point
  ;; Move past state/timestamp line.
  (forward-line)
  (while (re-search-forward "[[:upper:]]+: \\([^;]+\\)"
(point-at-eol) t)
(push (match-string-no-properties 1) data))
  (when da

Re: [PATCH] Re: Export to attach directory?

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> Subject: [PATCH] Add EXPORT_DIRECTORY property
>>
>> * lisp/ox.el (org-export-output-file-name): Check for this property
>> and place the exported output file there.
>> * doc/org-manual.org: Document.
>
> Doesn't it conflict with publishing, and with EXPORT_FILE_NAME
> property/keyword? In both, you can already specify an output directory.

I did look at making this work with the publishing framework. The
problem is that ox-publish looks like it will only do one or more files,
whereas I'm trying to publish a subtree.

More particularly, if there were a way to pass the PUB-DIR argument to
`org-export-output-file-name', that would take care of it. But I can
only export a subtree via the export dispatcher, and the export
dispatcher only calls `org-*-export-to-*' functions, and all of those
functions contain their own call to `org-export-output-file-name', so
there's no clean way to inject PUB-DIR anywhere.

You can't really wait until `org-export-as' does its general keyword
gathering, either, since EXPORT_FILE_NAME and EXPORT_DIRECTORY both need
to be available to `org-export-to-file'. So finding EXPORT_DIRECTORY in
`org-export-output-file-name' seemed like the only option.

I was imagining that EXPORT_FILE_NAME would take precedence, if it was
an absolute filepath. Otherwise, the two options could be complementary.

>> + (org-with-point-at (point-min)
>> + (catch :found
>> + (let ((case-fold-search t))
>> +(while (re-search-forward
>> +"^[ \t]*#\\+EXPORT_DIRECTORY:[ \t]+\\S-"
>> +nil t)
>> +  (let ((element (org-element-at-point)))
>> +(when (eq 'keyword (org-element-type element))
>> +  (throw :found
>> + (org-element-property
>> +  :value element))
>
> See `org-collect-keywords'.

I don't have this function! org-version -> "9.3.7"

Thanks,
Eric

Re: [feature request] A new cookie type [!] showing the last note taken

[Eric Abrahamsen]

Ihor Radchenko  writes:

>> Everyone has their own workflows, but I think the way you are approaching
>> this problem is "wrong". 
>
> I think I need to elaborate on the use-cases more then.
>
> I am well aware about the concept of NEXT actions, GTD, projects, and
> using categories to bring task context in agenda. However, the problem I
> am trying to solve is more subtle.
>
> Sometimes, subdividing a task into NEXT sub-tasks is simply overkill
> leading to redundancy. Consider the following example of reading a book,
> when the task of reading is also part of bigger project:

Chiming in briefly to say that I agree: many of my TODO use-cases simply
don't make any sense broken up into sub-tasks. So much of what I do is
email-based discussions -- about project proposals, textual edits,
contract negotiations -- and as the discussion evolves the TODO bounces
back and forth between NEXT and WAIT. This is also the fundamental
approach of Gnorb. There's no useful way to break that evolving
discussion into subtasks. All I want to know is, what am I WAITing on
and how long have I been WAITing, and if the ball's in my court, what am
I doing NEXT.

I looked into implementing something like what Ihor is suggesting
(except using a message-area echo), ran into some of the same
difficulties (the semi-real status of notes), and then noticed that
 on an Agenda item shows the item in another window with its
LOGBOOK expanded, meaning you can see the whole evolution of the TODO at
a glance. And "o" hides it away again. That took most of the steam out
of my plans, and I figured it was good enough.

Re the formatting issue, maybe the easiest thing would simply be to say
by fiat that only notes in a LOGBOOK drawer were eligible for special
parsing. If you're sticking notes in the subtree body, they're just a
list. Since no special note-handling facilities currently exist, no one
would lose out on anything if we said any future such facilities would
require the LOGBOOK.

Eric

Re: [PATCH] Re: Export to attach directory?

[Eric Abrahamsen]

Bastien  writes:

> Hi Eric,
>
> sorry for the late reply -- I don't use attachments that much
> but I see how this could be useful once correctly advertized and
> documented.
>
> Eric Abrahamsen  writes:
>
>> Would something along these lines be considered for inclusion?
>
> Yes, sure, for after 9.4 -- please go ahead with a proper patch.

How does this look? It occurred to me that having a global
`org-export-directory' option would be a good thing -- it makes sense to
me that a user might want all their exported files put in one place --
but in the interest of one-thing-at-a-time I didn't do that.

This additional property doesn't actually have anything to do with
org-attach. I'd originally thought that, with this option, I could write
an export filter that would check for:

:EXPORT_DIRECTORY: 

and replace it to point at whatever the attach dir was/should be for
that heading.

If that's something that many users would like to have, we could look at
adding it in org-attach.el. But in the meantime, the attached patch
makes it possible to do it yourself.

Thanks,
Eric

>From 0e80a6ed7ad955259c4e11ea74ed249696ba9b46 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Sun, 6 Sep 2020 10:36:34 -0700
Subject: [PATCH] Add EXPORT_DIRECTORY property

* lisp/ox.el (org-export-output-file-name): Check for this property
and place the exported output file there.
* doc/org-manual.org: Document.
---
 doc/org-manual.org |  8 +++-
 lisp/ox.el | 14 ++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 46498bd22..6f256a569 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11479,7 +11479,7 @@ global variables, include:
 - =CREATOR= ::
 
   #+cindex: @samp{CREATOR}, keyword
-  #+vindex: org-expot-creator-string
+  #+vindex: org-export-creator-string
   Entity responsible for output generation
   (~org-export-creator-string~).
 
@@ -11539,6 +11539,12 @@ global variables, include:
   generates the file name based on the buffer name and the extension
   based on the back-end format.
 
+- =EXPORT_DIRECTORY= ::
+
+  #+cindex: @samp{EXPORT_DIRECTORY}, keyword
+  An alternate directory in which to place the output file.
+  Otherwise, output files are placed alongside the original Org file.
+
 The =OPTIONS= keyword is a compact form.  To configure multiple
 options, use several =OPTIONS= lines.  =OPTIONS= recognizes the
 following arguments.
diff --git a/lisp/ox.el b/lisp/ox.el
index 9852cfd21..2d2c1ddb0 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6428,6 +6428,20 @@ Return file name as a string."
 	  "Output file: " pub-dir nil nil nil
 	  (lambda (n) (string= extension (file-name-extension n t))
 	   extension))
+	 (pub-dir (or pub-dir
+		  (and subtreep (org-entry-get
+ nil "EXPORT_DIRECTORY" 'selective))
+		  (org-with-point-at (point-min)
+			(catch :found
+			  (let ((case-fold-search t))
+			(while (re-search-forward
+"^[ \t]*#\\+EXPORT_DIRECTORY:[ \t]+\\S-"
+nil t)
+			  (let ((element (org-element-at-point)))
+(when (eq 'keyword (org-element-type element))
+  (throw :found
+	 (org-element-property
+	  :value element))
 	 (output-file
 	  ;; Build file name.  Enforce EXTENSION over whatever user
 	  ;; may have come up with.  PUB-DIR, if defined, always has
-- 
2.28.0

Re: Putting the value of page-delimiter in some outline regexps?

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> I've been trying to find a way to cordon off the bottom of my Org files,
>> to create an area for file-local variables and "LocalWords" and what
>> have you that Org doesn't consider part of the file's final heading.
>>
>> The usual Emacs thing to do seems to be using the value of
>> page-delimiter to demarcate the end of content, and the beginning of
>> meta data. I stuck that into the value of `org-outline-regexp', and also
>> hard-coded it into the "true heading" branch of `org-end-of-subtree'.
>> Over the past day this has worked fine for interactive use, and some
>> automatic Org-based tools. But I'm not so naive as to think that
>> catastrophic breakage couldn't be right around the corner as a result of
>> this!
>>
>> Anyway, I wanted to see if anyone else had tried this, or had any ideas
>> about it.
>
> I think Org already puts some care into preserving file-local variables
> at the end of the buffer, e.g., when moving around headlines. Maybe the
> issues you're encountering can be fixed the same way.

Do you mean `org-preserve-local-variables'? I think it would make sense
to put `page-delimiter' in the re-search-backward regexp. We could also
consider putting in the value of some of the ispell-*-keyword constants,
but it might also be reasonable to just ask the user to hide all that
stuff under a page-delimiter.

This still doesn't stop `org-next-visible-heading' or
`org-end-of-subtree' from treating the end matter as part of the last
heading. This would only be a minor inconvenience if I weren't trying to
write some automatic tools on top of Org. But perhaps I should be making
my tools smarter, not insisting that Org get smarter.

> Adding page delimiter in `org-outline-regexp' is clearly not subtle
> enough in any case, as it would affect every headline, not only the last
> one in the buffer.

No, I guess I didn't really think that was going to be a practical
solution.

Thanks for considering this,
Eric

Putting the value of page-delimiter in some outline regexps?

[Eric Abrahamsen]

Hi all,

I've been trying to find a way to cordon off the bottom of my Org files,
to create an area for file-local variables and "LocalWords" and what
have you that Org doesn't consider part of the file's final heading.

The usual Emacs thing to do seems to be using the value of
page-delimiter to demarcate the end of content, and the beginning of
meta data. I stuck that into the value of `org-outline-regexp', and also
hard-coded it into the "true heading" branch of `org-end-of-subtree'.
Over the past day this has worked fine for interactive use, and some
automatic Org-based tools. But I'm not so naive as to think that
catastrophic breakage couldn't be right around the corner as a result of
this!

Anyway, I wanted to see if anyone else had tried this, or had any ideas
about it.

Eric

Re: [feature request] A new cookie type [!] showing the last note taken

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Ihor Radchenko  writes:
>
>> I feel that my understand of "note" in context of org is different from
>> yours. Is there a formal definition of "note" in org?
>
> As I stated in my first post a few hours ago:
>
>Notes are mostly free-form; there is no syntax describing them.
>
>> However, we can formalise the "last note taken" to "last note taken
>> using org-add-note".
>
> This is more realistic, but you are then binding the tool
> (`org-add-note') to the syntax ("[!]"), which is a step in the wrong
> direction. We must not assume Org mode is the only tool writing Org
> documents.
>
>> org-add-note is the only way I am aware about (except plain text,
>> indeed). That's why I wrote the function saving the last note taken
>> using org-add-note into SUMMARY. The property is only used here for
>> convenient retrieval, not because I implied showing a property value.
>
> I understand the property was used for convenience, but showing its
> value is the only problem your can really claim solving at the moment.
>
>> May I know what are the other ways to add note via interactive function
>> in Org?
>
> Capture is certainly one way. In fact, `org-add-note' could (should ?)
> be rewritten using Capture library.
>
> I wouldn't dismiss plain text insertion too easily, either. It also
> includes external tools. What happens if an external tool automatically
> insert notes?
>
> The feature you are requesting could make sense if notes had a clear
> syntax. This would bring some interesting features, too (e.g., being
> able to list all notes in an entry, accurately). But it would also raise
> new problems, as any syntax change (backward compatibility with old
> documents, external tools...). 

FWIW I'd be very happy to see a formalized note syntax. I make heavy use
of arbitrary notes and state-change notes -- what needs to be done NEXT,
how long has a todo been in WAIT state -- and would love to be able to
build more tools on top of that.

Re: File local setting for export directory?

[Eric Abrahamsen]

Loris Bennett  writes:

> Hi Eric,
>
> Eric Abrahamsen  writes:
>
>> "Loris Bennett"  writes:
>>
>>> Hi,
>>>
>>> I want to export an org file to a pdf and have the pdf created in
>>> subdirectory relative to the org file.
>>>
>>> What's the simplest way to set the export directory in a file local way?
>>
>> I suggested the attached diff a while ago, but no one seemed very
>> interested. I think it might already do what you want.
>>
>>
>> diff --git a/lisp/ox.el b/lisp/ox.el
>> index 9cf62078a..77cafb20d 100644
>> --- a/lisp/ox.el
>> +++ b/lisp/ox.el
>> @@ -6417,6 +6417,20 @@ Return file name as a string."
>>"Output file: " pub-dir nil nil nil
>>(lambda (n) (string= extension (file-name-extension n t))
>> extension))
>> + (pub-dir (or pub-dir
>> +  (and subtreep (org-entry-get
>> + nil "EXPORT_PUB_DIR" 'selective))
>> +  (org-with-point-at (point-min)
>> +(catch :found
>> +  (let ((case-fold-search t))
>> +(while (re-search-forward
>> +"^[ \t]*#\\+EXPORT_PUB_DIR:[ \t]+\\S-"
>> +nil t)
>> +  (let ((element (org-element-at-point)))
>> +(when (eq 'keyword (org-element-type element))
>> +  (throw :found
>> + (org-element-property
>> +  :value element))
>>   (output-file
>>;; Build file name.  Enforce EXTENSION over whatever user
>>;; may have come up with.  PUB-DIR, if defined, always has
>>
>
> Thanks for the patch - it is exactly what I needed.
>
> I'm surprised no-one was interested, although I suppose back then I was
> probably also one of the uninterested :-)

Oh I'm not blaming anyone! There are a lot of patches coming down here,
and a lot of ideas for Org, and it's hard to keep up. I don't think I
did a very good job of stating my case, either.

I actually hadn't thought of how the latex process might go haywire with
an absolute export file name. My motivation was simply that "next to my
*.org" files is pretty much never where I want exported files to end up.
I want to send them to ~/tmp, or to a directory that's shared with
colleagues via syncthing. In fact what I really want is to export to the
value of ATTACH_DIR, because then I can immediately use all the attach
tools on the exported files.

Latex compilation is a nice additional argument, though!

Eric

Re: File local setting for export directory?

[Eric Abrahamsen]

"Loris Bennett"  writes:

> Hi,
>
> I want to export an org file to a pdf and have the pdf created in
> subdirectory relative to the org file.
>
> What's the simplest way to set the export directory in a file local way?

I suggested the attached diff a while ago, but no one seemed very
interested. I think it might already do what you want.


diff --git a/lisp/ox.el b/lisp/ox.el
index 9cf62078a..77cafb20d 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6417,6 +6417,20 @@ Return file name as a string."
 	  "Output file: " pub-dir nil nil nil
 	  (lambda (n) (string= extension (file-name-extension n t))
 	   extension))
+	 (pub-dir (or pub-dir
+		  (and subtreep (org-entry-get
+ nil "EXPORT_PUB_DIR" 'selective))
+		  (org-with-point-at (point-min)
+			(catch :found
+			  (let ((case-fold-search t))
+			(while (re-search-forward
+"^[ \t]*#\\+EXPORT_PUB_DIR:[ \t]+\\S-"
+nil t)
+			  (let ((element (org-element-at-point)))
+(when (eq 'keyword (org-element-type element))
+  (throw :found
+	 (org-element-property
+	  :value element))
 	 (output-file
 	  ;; Build file name.  Enforce EXTENSION over whatever user
 	  ;; may have come up with.  PUB-DIR, if defined, always has

Re: [PATCH] org-eldoc: Fix compatibility with Emacs 28

[Eric Abrahamsen]

"Basil L. Contovounesios"  writes:

> Kyle Meyer  writes:
>
>> All right, thanks.  Here's that in patch form.  I briefly tested with
>> Emacs 26, 27, and 28, and things seemed to work fine (though I'm not an
>> org-eldoc user).
>
> I'm not either, but it seems to get pulled in automatically when
> org-plus-contrib is installed - that's how I noticed the errors in Org
> buffers.

I was also trying to figure out how to shut it off, and there were no
obvious knobs to do so. Given that this gets installed implicitly, I
think maybe it shouldn't be turned on by default. Isn't this what
`org-modules' is for?

Re: New mailing list archive at https://orgmode/list/

[Eric Abrahamsen]

Eric Wong  writes:

> Kyle Meyer  wrote:
>> Eric Abrahamsen writes:
>> 
>> > Hey, that works great! It's a bit weird that it still asks for a
>> > username and password, I wonder if there's any way to skip that. I've
>> > never dealt with anonymous IMAP before -- is there anything in the
>> > connection process that explicitly tells us "you don't need to log on"?
>> 
>> The server advertises AUTH=ANONYMOUS as a capability [*], so Gnus could
>> detect that and send "AUTHENTICATE ANONYMOUS", I _think_.
>
> Fwiw, mutt detects AUTH=ANONYMOUS and uses it automatically,
> so I think it's reasonable for Gnus and others do the same.

Looks like it would be as simple as the attached diff. I have very
little confidence in my understanding of the potential ramifications,
though, so I'll open an Emacs bug and see what other people think.

Eric

diff --git a/lisp/gnus/gnus-registry.el b/lisp/gnus/gnus-registry.el
index f306889a7f..ebb1236674 100644
--- a/lisp/gnus/gnus-registry.el
+++ b/lisp/gnus/gnus-registry.el
@@ -837,6 +837,7 @@ gnus-registry-find-keywords
 (completing-read "Keyword: " (gnus-registry-keywords) nil t)))
   (registry-lookup-secondary-value gnus-registry-db 'keyword keyword))
 
+
 (defun gnus-registry-register-message-ids ()
   "Register the Message-ID of every article in the group."
   (unless (gnus-parameter-registry-ignore gnus-newsgroup-name)
diff --git a/lisp/gnus/nnimap.el b/lisp/gnus/nnimap.el
index 3c4e75ede8..18d3cba173 100644
--- a/lisp/gnus/nnimap.el
+++ b/lisp/gnus/nnimap.el
@@ -509,7 +509,8 @@ nnimap-open-connection-1
 			  (split-string capabilities)))
 	(unless (string-match-p "[*.] PREAUTH" greeting)
 	  (if (not (setq credentials
-			 (if (eq nnimap-authenticator 'anonymous)
+			 (if (or (eq nnimap-authenticator 'anonymous)
+ (nnimap-capability "AUTH=ANONYMOUS"))
  (list "anonymous"
    (message-make-address))
;; Look for the credentials based on

Re: New mailing list archive at https://orgmode/list/

[Eric Abrahamsen]

Kyle Meyer  writes:

> Eric Abrahamsen writes:
>
>> Kyle Meyer  writes:
>>
>>> (setq gnus-select-method '(nnimap "news.yhetil.org"
>>>   ;; no certs yet
>>>   (nnimap-stream plain)))
>>
>> Hmm, I tried this (adding to `gnus-secondary-select-methods'), and got:
>>
>> Warning: Opening nnimap server on news.yhetil.org...failed: NO Mailbox
>> doesn't exist: DOES.NOT.EXIST (0.001 + 0.000 secs).; Unable to open
>> server nnimap+news.yhetil.org due to: make client process failed:
>> Network is unreachable, :name, *nnimap*, :buffer, *nnimap
>> news.yhetil.org nil *nntpd**, :host, news.yhetil.org, :service, imap,
>> :coding, nil
>>
>> The "mailbox doesn't exist" thing seems to be misleading: further
>> attempts to connect to the server just gave me "network is unreachable".
>> I wonder if this has something to do with my tls settings? I'll set
>> `gnutls-log-level' to 2 and try again... Nope, same error.
>>
>> This is on Emacs master, I'm not sure what else I can check (though I
>> still suspect it's something to do with connection security).
>
> Sorry, I switched it over to using a cert last night.  I should have
> sent a message here.  Hopefully just having
>
> (nnimap "news.yhetil.org")
>
> in gnus-secondary-select-methods will work for you.  I tried just now,
> and it worked on my end (Emacs 26.3).

Hey, that works great! It's a bit weird that it still asks for a
username and password, I wonder if there's any way to skip that. I've
never dealt with anonymous IMAP before -- is there anything in the
connection process that explicitly tells us "you don't need to log on"?
Otherwise, I guess it doesn't hurt just to save a bogus
username/password and forget about it.

The whole thing (connection, search, display) is also significantly
faster than gmane :)

Eric

Re: New mailing list archive at https://orgmode/list/

[Eric Abrahamsen]

Kyle Meyer  writes:

> [ adding Eric Wong back to the cc ]
>
> Eric Abrahamsen writes:
>
>> Eric Wong  writes:
>>> Fwiw, I've been trying to avoid exposing NNTP article numbers in
>>> the HTTP endpoint in favor of Message-IDs because serial numbers
>>> aren't decentralization-friendly.  Of course, sometimes
>>> Message-IDs get reused, so public-inbox will return all messages
>>> which match a particular Message-ID in those rare cases.
>>>
>>> Btw, POST with the "=m" query parameter already allows search
>>> to return a gzipped mboxrd.
>>>
>>> And also what I just wrote about about JMAP/GraphQL in the other
>>> message.
>>>
>>> A read-only IMAP server is also coming with search support,
>>> and IMAP UIDs will be equivalent to NNTP article numbers.
>>
>> Sounds like something in there is bound to work! IMAP might be best --
>> while it's certainly possible to do Message-ID<->article number lookups,
>> that will slow Gnus down further, and it's already fairly slow.
>>
>> Thanks again,
>> Eric
>
> Here are the recent patches that Eric sent out related to the read-only
> IMAP server:
>
>   https://public-inbox.org/meta/20200610070519.18252-...@yhbt.net
>
> It's already available at .  I've played
> around with that a bit in Mutt and Gnus, and it seems to work nicely.
> As I mentioned before, I don't really search much in Gnus, but I tried
> some basic queries via GG and the results looked reasonable.
>
> I set this up for news.yhetil.org tonight.  Here's what I used to test
> it out:
>
> ;; Set so that all groups/folders aren't subscribed and synced.  Think
> ;; I should be able to prevent that with `gnus-options-not-subscribe'
> ;; or `gnus-auto-subscribed-groups', but didn't have any luck.
> (setq gnus-check-new-newsgroups nil)
>
> (setq gnus-select-method '(nnimap "news.yhetil.org"
>   ;; no certs yet
>   (nnimap-stream plain)))

Hmm, I tried this (adding to `gnus-secondary-select-methods'), and got:

Warning: Opening nnimap server on news.yhetil.org...failed: NO Mailbox
doesn't exist: DOES.NOT.EXIST (0.001 + 0.000 secs).; Unable to open
server nnimap+news.yhetil.org due to: make client process failed:
Network is unreachable, :name, *nnimap*, :buffer, *nnimap
news.yhetil.org nil *nntpd**, :host, news.yhetil.org, :service, imap,
:coding, nil

The "mailbox doesn't exist" thing seems to be misleading: further
attempts to connect to the server just gave me "network is unreachable".
I wonder if this has something to do with my tls settings? I'll set
`gnutls-log-level' to 2 and try again... Nope, same error.

This is on Emacs master, I'm not sure what else I can check (though I
still suspect it's something to do with connection security).

Eric

[PATCH] Re: Export to attach directory?

[Eric Abrahamsen]

Eric Abrahamsen  writes:

> I think the last thing I'm missing before my Org set up is Absolutely
> Perfect and never needs to be tweaked again (ha!) is the ability to
> export Org files/subtrees to their relevant ATTACH directories, if any.
> It might be overkill to have a global setting for this, but I would
> love to be able to say:
>
> * Report #25 :ATTACH:
> :PROPERTIES:
> :ID:   3da327aa-b51e-444a-ae5c-95bb56d025a9
> :EXPORT_FILE_NAME: report_25
> :EXPORT_TO_ATTACH: t
> :END:

Nobody seems super excited about this but...

I went poking to see how difficult it would be to do this only using
hooks and whatnot. It seemed a bit awkward: I can munge the export file
name altogether, but there's no good way to say "use whatever file name
you would have come up with, but put the resulting file in such-and-such
directory".

Mostly it's not possible to sneak in and add/alter the PUB-DIR argument
to `org-export-output-file-name' -- that argument only seems to be used
in the publishing framework.

The attached patch to `org-export-output-file-name' has it also check
for a EXPORT_PUB_DIR property at the heading level or document level;
that would allow libraries like org-attach.el a way to get at exporting
via a hook. (Maybe EXPORT_DIRECTORY would be a better name.)

Would something along these lines be considered for inclusion?

Thanks,
Eric


diff --git a/lisp/ox.el b/lisp/ox.el
index 9cf62078a..77cafb20d 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6417,6 +6417,20 @@ Return file name as a string."
 	  "Output file: " pub-dir nil nil nil
 	  (lambda (n) (string= extension (file-name-extension n t))
 	   extension))
+	 (pub-dir (or pub-dir
+		  (and subtreep (org-entry-get
+ nil "EXPORT_PUB_DIR" 'selective))
+		  (org-with-point-at (point-min)
+			(catch :found
+			  (let ((case-fold-search t))
+			(while (re-search-forward
+"^[ \t]*#\\+EXPORT_PUB_DIR:[ \t]+\\S-"
+nil t)
+			  (let ((element (org-element-at-point)))
+(when (eq 'keyword (org-element-type element))
+  (throw :found
+	 (org-element-property
+	  :value element))
 	 (output-file
 	  ;; Build file name.  Enforce EXTENSION over whatever user
 	  ;; may have come up with.  PUB-DIR, if defined, always has

Re: New mailing list archive at https://orgmode/list/

[Eric Abrahamsen]

Eric Wong  writes:

> Eric Abrahamsen  wrote:
>> Kyle Meyer  writes:
>> 
>> > [ +cc Eric Wong, mostly to say thanks for all the work he puts into
>> >   public-inbox, which is the software behind these archives, but also so
>> >   that he can correct me if I misrepresent any capabilities of or plans
>> >   for public-inbox ]
>> 
>> Thanks for this response, Kyle (and thanks for public-inbox, Eric)!
>
> you're welcome, both :>
>
>> You wouldn't really use one backend (nnweb) to provide search support
>> for another (nntp). nnir can assign different search engines to
>> different backends -- what a "search engine" boils down to is a function
>> that accepts group search criteria, and returns groups and article
>> numbers (and optional relevance scoring) for matching messages. So if
>> public-inbox had some sort of an API that accepted a query and returned
>> the above information in some sort of easily-digestible format, it
>> wouldn't be hard to write a engine for it. Articles referenced in the
>> search results would then be retrieved via NNTP, so the article numbers
>> would need to correspond.
>
> Fwiw, I've been trying to avoid exposing NNTP article numbers in
> the HTTP endpoint in favor of Message-IDs because serial numbers
> aren't decentralization-friendly.  Of course, sometimes
> Message-IDs get reused, so public-inbox will return all messages
> which match a particular Message-ID in those rare cases.
>
> Btw, POST with the "=m" query parameter already allows search
> to return a gzipped mboxrd.
>
> And also what I just wrote about about JMAP/GraphQL in the other
> message.
>
> A read-only IMAP server is also coming with search support,
> and IMAP UIDs will be equivalent to NNTP article numbers.

Sounds like something in there is bound to work! IMAP might be best --
while it's certainly possible to do Message-ID<->article number lookups,
that will slow Gnus down further, and it's already fairly slow.

Thanks again,
Eric

Re: New mailing list archive at https://orgmode/list/

[Eric Abrahamsen]

Kyle Meyer  writes:

> [ +cc Eric Wong, mostly to say thanks for all the work he puts into
>   public-inbox, which is the software behind these archives, but also so
>   that he can correct me if I misrepresent any capabilities of or plans
>   for public-inbox ]

Thanks for this response, Kyle (and thanks for public-inbox, Eric)!

>> Bastien  writes:
>>
>>> with Kyle's help, I've set up a new mailing list archive:
>>>
>>> https://orgmode/list/
>>>
>>> References in https://orgmode.org and https://orgmode.org/list
>>> that pointed to gmane.org are now using this, so many links are
>>> functional again.
>>
>> Cool! I note that there's also NNTP access at news.yhetil.org, in
>> addition to gmane.io. Does yhetil have a search interface, or are there
>> other mechanisms for searching the archives (ideally in Gnus :))?
>
> The web interface ( or
> ) is the main mechanism for searching.  You
> don't necessarily have to leave Emacs for that, as public-inbox's pages
> render nicely in EWW.  But of course that's not the Gnus-based search
> you're hoping for.
>
> I use Gnus to follow some lists via NNTP, a mix of public-inbox archives
> and gmane.io, but I've never really done any fancy searching from it and
> don't use Gnus for my mail.  To try it out, I hit GG to search on a
> gmane.io list, but got an error [^1], so I suppose its search capability
> went away with Gmane's HTTP interface.

Yup, Gmane hasn't had in-Gnus search since then.

> Poking around a bit, I guess nnweb.el would be the main place that
> public-inbox's web search could be integrated into Gnus?  I've been
> (slowly) working on an Emacs package [^2] that adds public-inbox-related
> functionality to different "endpoints" (currently Notmuch, Gnus, EWW,
> Elfeed), and I'd be interested in any ideas for improving the Gnus
> support.

You wouldn't really use one backend (nnweb) to provide search support
for another (nntp). nnir can assign different search engines to
different backends -- what a "search engine" boils down to is a function
that accepts group search criteria, and returns groups and article
numbers (and optional relevance scoring) for matching messages. So if
public-inbox had some sort of an API that accepted a query and returned
the above information in some sort of easily-digestible format, it
wouldn't be hard to write a engine for it. Articles referenced in the
search results would then be retrieved via NNTP, so the article numbers
would need to correspond.

(Basically this is all the old Gmane search functionality did.)

> A couple of other notes:
>
>   * You can get the entire archive locally with a 'git clone', in which
> case you can transform it into a form that can be indexed/searched
> however you prefer (including with public-inbox, running a local
> public-inbox-httpd).  There are some pointers on extracting an
> archive to a Maildir at
> .

That would certainly be one approach! But not one that scales to many
users :)

>   * In the message above, Eric W. mentions that he is considering
> working on client tools with mairix-like search results.  That'd
> make the search capabilities available locally, and I'd imagine
> something like that could be nicely integrated with Gnus,
> considering it already has a mairix backend to use as a guide.

Yup, basically we'd just want a way to retrieve matching article numbers
that (ideally) didn't involve scraping a web page.

Thanks again,
Eric

Re: New mailing list archive at https://orgmode/list/

[Eric Abrahamsen]

Bastien  writes:

> Dear all,
>
> with Kyle's help, I've set up a new mailing list archive:
>
> https://orgmode/list/
>
> References in https://orgmode.org and https://orgmode.org/list
> that pointed to gmane.org are now using this, so many links are
> functional again.

Cool! I note that there's also NNTP access at news.yhetil.org, in
addition to gmane.io. Does yhetil have a search interface, or are there
other mechanisms for searching the archives (ideally in Gnus :))?

Export to attach directory?

[Eric Abrahamsen]

I think the last thing I'm missing before my Org set up is Absolutely
Perfect and never needs to be tweaked again (ha!) is the ability to
export Org files/subtrees to their relevant ATTACH directories, if any.
It might be overkill to have a global setting for this, but I would
love to be able to say:

* Report #25 :ATTACH:
:PROPERTIES:
:ID:   3da327aa-b51e-444a-ae5c-95bb56d025a9
:EXPORT_FILE_NAME: report_25
:EXPORT_TO_ATTACH: t
:END:

Or maybe a property with an ATTACH prefix, I'm not sure. I find myself
having to use Google Docs more and more, for collaboration, and this
would let me use a package that mounts G-Docs on your filesystem, and
export directly there. (And it would keep my Org directory tidy!)

Has anyone cooked this up before? I wasn't able to find anything on the
web.

I'm imagining that org-attach.el could add something to
`org-export-before-processing-hook', to check for the presence of this
property, and set/rewrite the EXPORT_FILE_NAME property, if it's
present.

WDYT?

Eric

Re: Contact data and sync revisited

[Eric Abrahamsen]

Russell Adams  writes:

> I've been trying to find the best way to manage my contacts. I've dabbled with
> org-contact and using an Org file with property drawers, I've dabbled with
> BBDB. I've looked at standalone programs.
>
> My key problem is I need a way to access my contacts in Emacs and Mutt, and 
> send
> them to my Android phone. Single direction sync is fine.
>
> Using a Nextcloud host, org-caldav, and DAVx5 I have already successfully 
> pushed my
> calendar events to my Android phone. This makes it even more important for me 
> to
> solve this issue finally.
>
> I've considered the merit of a few options:
>
>  - Use Org-contacts
>- Pro: It's in org! So easy, lets me keep notes and appointment data 
> easily.
>- Cons: Doesn't export at all.
>
>  - BBDB
>- Pro: It's in Emacs natively, with Org integration.
>- Pro: Larger users base than Org-contacts, more software
>- Cons: Exports but requires additional tools to sync
>
> Unfortunately looking at the options keeps coming back to how poor general
> support for CardDAV and vcard files is. In particular, the popular vdirsyncer
> tool is now looking for a new maintainer, and I had the impression from his 
> list
> of grievances he might drop it entirely.

This is not yet a working solution, but I'm gradually getting there with
EBDB, a port/rewrite of BBDB. It does vCard export, though not very well
yet. I've also written a library called "vcard", which does parsing of
vcards into Elisp data, but have yet to get off my butt and wire
everything together. The end result will be an EBDB database that uses
the vCard format natively for storage.

Then I was planning on relying on vdirsyncer for CardDAV syncing, and
it's a bummer to hear that it might go unmaintained. I could write a
native CardDAV client using dav.el, but seeing how much fun David
Engster has maintaining org-caldav, I'm not eager to go that route.

If you're interested, you can follow this issue.

https://github.com/girzel/ebdb/issues/4

Yes, it's issue #4, opened in 2016. Don't let that discourage you!

Eric

Re: issue tracker?

[Eric Abrahamsen]

Russell Adams  writes:

> On Wed, May 27, 2020 at 12:59:24PM -0500, Mario Frasca wrote:
>> myself, I recently posted a patch, received zero reaction, and have the
>> impression it's now lost in the logs of this mailing list.  indeed
>> pretty inefficient!
>
> Or the devs haven't had a chance yet.
>
>> something which flashed to my mind while writing this email: we're
>> dealing with an emacs software, part of emacs, can we just use M-x
>> report-emacs-bug?
>
> Yes, I believe that goes to the emacs bug list.

And if you put:

Package: org

As the first line in the report, it will automatically be tagged as org,
making it easier for people to find. (At least, I'm pretty sure that
will work correctly.)

Re: issue tracker?

[Eric Abrahamsen]

Kévin Le Gouguec  writes:

> Nicolas Goaziou  writes:
>
>> - As pointed out, Org has a bug tracker : Emacs' Debbugs. See
>>   . Org users do not send bugs
>>   through it much.
>
> (In the event that they do, should whoever follows bug-gnu-emacs refer
> these users to emacs-orgmode?)

Maybe a first step would be changing `org-submit-bug-report' to submit
the bug to debbugs, not to this mailing list?

I know I'd be happy to help with bug triage, but I don't go wading
through this mailing list like I used to. I do use debbugs for other
stuff, though, and it would be easy to add an extra filter that I check
regularly.

2¢...

Re: issue tracker?

[Eric Abrahamsen]

Roland Everaert  writes:

> Sourcehut seams interesting. Did you know if importing github/gitlab
> projects, with issues and merge requests (opened and closed) is supported
> at the moment?

I did a bit of googling, and couldn't find anything, no. The developer
is very responsive, though, and might be worth contacting him directly.
Though I guess Org doesn't have any existing issues to import (unless
it's from Nicolas' development machine).

> I noticed it is in alpha, so I don't expect to see all the features of any
> of those forges yet.

Here are details on "alpha":

https://sourcehut.org/alpha-details/

One issue is that, while payment isn't currently required, it will be
eventually. Perhaps the developer would be willing to make an exception
for Org, or perhaps we should get what we pay for :)

I guess I wouldn't expect Org to migrate away from gnu.org as a mailing
list host, but the option is there.

> Before I forget, Does magit+forge works well with sourcehut, especially the
> latter, as the former shouldn't have any problem?

Forge notes Sourcehut:

https://magit.vc/manual/forge/Supported-Forges-and-Hosts.html#Supported-Semi_002dForges

The thing is that Sourcehut doesn't really do pull requests, which I
think is the tricky part of any "forge". It really is dead simple, and I
think would be most useful as a mirror of Org's code, and an issue
tracker.

Eric

Re: issue tracker?

[Eric Abrahamsen]

"James R Miller"  writes:

> So, I definitely agree that using Github / Gitlab does expose you to
> tracking messes and that is something to shun. I figured a self-hosted
> Gogs instance (which is already being hosted at
> https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue.
>
> I think an actual issue tracker has merit to large projects.

I've been going around doing proselytizing for sr.ht (sourcehut, aka
"Sir Hat"), which is a forge-like site that is very much in line with
Emacs' principles. No tracking (barely any javascript at all),
everything can be driven via email -- it's pretty nice. Could be a good
solution here.

(Not affiliated, though I do give them money.)

Eric

Re: get the body of a heading up to the next subheading

[Eric Abrahamsen]

John Kitchin  writes:

> Thanks! Here is what I am currently using:
>
> (defun canvas-org-get-heading-body ()
>   "Return the body of the current heading up to the next heading."
>   (interactive)
>   (save-excursion
> (unless (org-at-heading-p)
>   (org-previous-visible-heading 1))
> (org-end-of-meta-data)
> (buffer-substring (point)
> (progn (re-search-forward org-heading-regexp nil 'mv)
>(line-beginning-position)
>
> So far it gets what I want. I am pretty sure I have reinvented this,
> maybe even from code I wrote before... I couldn't find my answer on SO
> or my blog though.

I don't think there's anything built-in, no. I have needed this in
various places, and did something similar to the above, except with a
combination of `org-back-to-heading', `org-end-of-meta-data', then
`outline-next-heading'. 

Re: yhetil.org/orgmode now supports searching by Gmane ID

[Eric Abrahamsen]

Kyle Meyer  writes:

> Eric Abrahamsen  writes:
>
>> Kyle Meyer  writes:
>
> [...]
>
>>>   $ w3m -m nntp://news.gmane.io/gmane.emacs.orgmode/112052
>>>
>>> (Offhand I don't know how to do the same in Gnus, despite it being my
>>> primary method for following things over nntp.)
>>
>> I assume you can just use "j" in the summary buffer, and enter the
>> article number. Doing that for message 112052 got me message-id
>> "<87k28w7l6y@gmail.com>", is that correct?
>
> That's the one.  Thanks!
>
> If you happen to know off the top of your head: Is there an easy way for
> me to jump to that article if I'm not subscribed to the
> gmane.emacs.orgmode group but have the nntp:news.gmane.io server set up
> (for other lists)?

Hmm, this isn't something I do very often, but I think if you make an
ephemeral group with either "B" or "G M" (the interfaces are different,
but I believe the result is the same) you can enter the group name,
specify that it should use your nntp:news.gmane.io server, then the
group will open and you can do the "j" trick. The group should disappear
from your Gnus installation when you're done with it. You could also
write your own wrapper around gnus-group-read-ephemeral-group.

It might take some experimentation!

Eric

Re: yhetil.org/orgmode now supports searching by Gmane ID

[Eric Abrahamsen]

Kyle Meyer  writes:

> In the Git and mailing list history, we've got lots of references like
> .  Those Gmane
> http links aren't so useful now, though you can still use that
> information to access the message by doing things such as
>
>   $ w3m -m nntp://news.gmane.io/gmane.emacs.orgmode/112052
>
> (Offhand I don't know how to do the same in Gnus, despite it being my
> primary method for following things over nntp.)

I assume you can just use "j" in the summary buffer, and enter the
article number. Doing that for message 112052 got me message-id
"<87k28w7l6y@gmail.com>", is that correct?

Re: removal of org-maybe-keyword-time-regexp

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> I would have liked to know what the "something else" was! Or even "Org
>> link regexps have been rewritten", something like that.
>
> I added an obsolescence warning about it in "org-compat.el". It will
> still break upstream, since there is no replacement for the variable.

I suppose I should have been watching the compiler more closely...

>> Looks like commit "Move link-related core functions out of \"org.el\"".
>> Nearly a year ago -- I wasn't paying attention! But defining link
>> regexps as aliases of other link regexps meant that the regexps matched,
>> but the match groups were off: that led to silent failure, and took
>> quite a while to debug. I guess I would have preferred a loud failure.
>
> Most variables were only renamed. It's possible that a few of them
> changed match groups, but that was probably not intentional (I cannot
> remember). The only intended change was `org-link-bracket-re', which is
> documented in ORG-NEWS.

It was `org-bracket-link-analytic-regexp', which was made an alias for
`org-link-bracket-re', but the groups were different. I just moved
straight to using `org-link-any-re'.

Anyway, it wasn't a huge problem, and I'm happy to keep up with Org
changes, but in this case the silent failure was a bit tricky.

Eric

Re: removal of org-maybe-keyword-time-regexp

[Eric Abrahamsen]

On 03/11/20 23:20 PM, Nicolas Goaziou wrote:
> Hello,
>
> Eric Abrahamsen  writes:
>
>> But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a
>> simply explanatory string.
>
> You're right. However, I'm not sure what the CURRENT-NAME should be,
> besides "don't use this, you probably want something else"

I would have liked to know what the "something else" was! Or even "Org
link regexps have been rewritten", something like that.

> Also, my suggestions still holds: it is useful to warn upstream about
> it.

Absolutely. I don't think Org has a responsibility to maintain backwards
compatibility for these variables, and upstream packages should be
tracking changes. But the more help we can provide, the better.

>> I was also recently bit by the removal of a bunch of regexps (in my
>> case, link regexps), and it would have been useful to have some sort of
>> a pointer, either in the obsolescence message or in the docs, about what
>> we're supposed to do instead.
>
> I'm not sure about what "bunch of regexps" you are talking about.

Looks like commit "Move link-related core functions out of \"org.el\"".
Nearly a year ago -- I wasn't paying attention! But defining link
regexps as aliases of other link regexps meant that the regexps matched,
but the match groups were off: that led to silent failure, and took
quite a while to debug. I guess I would have preferred a loud failure.

Anyway, it's not a big deal, I only bring it up because someone else
did!

Eric

Re: removal of org-maybe-keyword-time-regexp

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Julien Cubizolles  writes:
>
>> I'm using org-caldav (https://github.com/dengste/org-caldav/) to
>> synchronize the calendar on my Android phone and Org. Recently this
>> synchronization stopped working because org-caldav relies on
>> org-maybe-keyword-time-regexp that has been dropped from Org. As a
>> workaround, could this variable be reintroduced in org so as not to
>> break this very useful package ?
>
> Could you contact upstream instead?
>
> AFAICT, they use this variable only twice. The first occurrence doesn't
> seem useful (they check for a planning info keyword in a headline, which
> cannot happen), it is probably enough to look for `org-ts-regexp-both'.
>
> I'm not sure about the second one. I guess it would be better for them
> to use something like:
>
> (and (re-search-forward "org-planning-line-re" nil t)
>  (org-at-planning-p)
>  (progn
>(org-skip-whitespace)
>(looking-at org-ts-regexp-both)))
>
> The (small) issue here is that we cannot properly deprecate a variable
> that is not replaced with something else (i.e., we're not using
> `define-obsolete-variable-alias' here).

But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a
simply explanatory string.

I was also recently bit by the removal of a bunch of regexps (in my
case, link regexps), and it would have been useful to have some sort of
a pointer, either in the obsolescence message or in the docs, about what
we're supposed to do instead.

Re: get subtree contents as string

[Eric Abrahamsen]

Matt Price  writes:

> I have the following convenience function that scans contents of a subtree
> and then sets a property, adds an overlay, and changes the TODO status:
> (defun org-lms-set-grade ()
>   "set grade property for all headings on basis of \"- Grade :: \" line
>   Use with caution."
>   (interactive)
>   (save-restriction
> (org-narrow-to-subtree)
>   (save-excursion
>   (org-back-to-heading)
>   (while (re-search-forward ol-grade-regex nil t )
> (org-set-property "GRADE" (or (match-string 2) 0))
> (org-todo "READY"
>   (org-lms-overlay-headings)  )
>
> It works, but there's a short (<1sec) non-responsive period when it runs.
> I'm wondering if it has to do with ~org-narrow-to-subtree~, so I thought
> I'd just copy the contents of the subtree as a string and replace
> re-search-forward with string-match. However, I'm not finding a
> super-obvious way to copy the subtree as a string. Am I missing something?
> And am I likely to be right that that's the source of the delay (as I write
> this, I'mwondering if hte overlay drawing might be the real problem? The
> whole project this is part of (https://github.com/titaniumbones/org-lms)
> suffers from delays while the buffer redraws, so I'm keen to figure out
> Better Ways To Do Things.

If it's just a matter of getting the subtree text, you could use
buffer-substring with org-end-of-subtree to find the end of the string.
Does that do it?

Re: Possible to exclude/include tags for agenda custom commands?

[Eric Abrahamsen]

Bastien  writes:

> Hi Eric,
>
> Eric Abrahamsen  writes:
>
>> The key is having `org-agenda-sticky' set to t -- this means that we'll
>> let-bind buffer-local variables in a buffer where they're already
>> set.
>
> thanks for the reproducible example, I was able to get the warning.
>
> You can safely ignore it: when redoing sticky agenda, we need to
> let-bind the values as explicitely set in the agenda custom command
> (here the org-agenda-tag-filter value) while preparing the agenda
> requires the variables to be made local.  I don't see what can be
> done and I don't think there hidden bugs lingering around here.

Okay! I also didn't think anything terrible was going on here. I note
there's the variable `org-agenda-doing-sticky-redo' that we could
presumably check, and avoid re-setting the tag filter when it's t, but
again I don't think the warning is a big deal.

Thanks,
Eric

Re: Possible to exclude/include tags for agenda custom commands?

[Eric Abrahamsen]

Bastien  writes:

> Hi Eric,
>
> Eric Abrahamsen  writes:
>
>> I hope that helps!
>
> thanks for the detailed example.  What verison of Org and Emacs?
>
> With your example and Org mode version 9.3.6 and GNU Emacs 28.0.50
> I don't get the warning.  If you have a ECM I'm willing to test more.

The key is having `org-agenda-sticky' set to t -- this means that we'll
let-bind buffer-local variables in a buffer where they're already set.
Steps to reproduce:

1. emacs -Q
2. Add Org of your choice to load-path
3. Load the attached startup.el
4. Make sure the attached test.org is someplace where the previous file
   can find it.
5. org-agenda, then the "b" key
6. Hit "g" or "r", either will trigger the warning

Hope that works,

Eric

(setq org-agenda-custom-commands
  '(("b" "Bugs?"
 ((agenda ""
  ((org-agenda-start-day "2020-02-22")
   (org-agenda-span 10
 ((org-agenda-tag-filter '("+buggy"))

(setq org-agenda-files '("~/test.org")
  org-agenda-sticky t)


test.org
Description: Lotus Organizer

Re: Possible to exclude/include tags for agenda custom commands?

[Eric Abrahamsen]

Bastien  writes:

> Hi Eric,
>
> Eric Abrahamsen  writes:
>
>> I'll also note that, while this works perfectly well, every time I
>> refresh my custom agenda I see:
>>
>> Making org-agenda-tag-filter buffer-local while locally let-bound!
>
> Can you send enough information so that we can reproduce the problem?

Yes, that wasn't a very helpful report, was it?

First of all, here's the custom command I'm using, to organize an
upcoming trip to New York:

("n" "New York Feb 2020"
 ((tags-todo "nyfeb2020")
  (agenda "is this string meaningless?"
  ((org-agenda-start-day "2020-02-25")
   (org-agenda-span 15
 ((org-agenda-tag-filter '("+nyfeb2020"

I edebug `org-agenda-redo', and hit "g". In this function,
`org-agenda-tag-filter' is nil. I don't know if it's supposed to be or
not, but it is.

The error arises out of `org-agenda-run-series', so we go there, and
find it comes from `org-let':

(let ((org-agenda-tag-filter '("+nyfeb2020")))
  (org-agenda-prepare name))

`org-agenda-run-series' gets called twice every time I update the
agenda; the error only arises from the first time. The
`org-agenda-tag-filter' variable is buffer-local to my custom agenda,
which is why Emacs complains that it's being let-bound. I don't see
where `org-agenda-tag-filter' is made buffer-local.

I hope that helps!

Eric

Re: Possible to exclude/include tags for agenda custom commands?

[Eric Abrahamsen]

Eric Abrahamsen  writes:

> Bastien  writes:
>
>> Hi Eric,
>>
>> Eric Abrahamsen  writes:
>>
>>> In my current Org, version 9.3.6-elpaplus, I need a "+" in front of a
>>> select tag, ie the "MAYBE" above needs to be "+MAYBE", otherwise nothing
>>> is selected at all.
>>
>> FWIW yes, this should be "+MAYBE".
>
> Thanks for confirming!

I'll also note that, while this works perfectly well, every time I
refresh my custom agenda I see:

Making org-agenda-tag-filter buffer-local while locally let-bound!

Maybe there's still some work to be done here?

Re: Possible to exclude/include tags for agenda custom commands?

[Eric Abrahamsen]

Bastien  writes:

> Hi Eric,
>
> Eric Abrahamsen  writes:
>
>> In my current Org, version 9.3.6-elpaplus, I need a "+" in front of a
>> select tag, ie the "MAYBE" above needs to be "+MAYBE", otherwise nothing
>> is selected at all.
>
> FWIW yes, this should be "+MAYBE".

Thanks for confirming!

Re: Possible to exclude/include tags for agenda custom commands?

[Eric Abrahamsen]

Stig Brautaset  writes:

> Hi Bastien,
>
> Bastien  writes:
>>> I can easily do this in the list of TODOs, with a tag search. However, I
>>> haven't figured out how to do this for the agenda. Is it possible? If
>>> so, how?
>>
>> From what I understand, check `org-agenda-tag-filter' to see how to
>> use it within an agenda custom command.
>
> Thank you! That did indeed do it. 

Coincidentally, I was just trying to figure this problem out, so this
snippet is helpful. It's weird, because I'm almost certain I've done
this before, but couldn't remember how.

> FWIW my stanza looks like this now:
>
> (setq org-agenda-custom-commands
>  '(("w" "Work Agenda"
> ((agenda "" ((org-agenda-span 'day)))
>  (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@home" "-MAYBE"
>("h" "Home Agenda"
> ((agenda "")
>  (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@work" "-MAYBE"
>("m" "Maybe"
> ((todo "PROJ")
>  (tags-todo "-PROJ/TODO"))
> ((org-agenda-tag-filter '("MAYBE"
>("P" "Projects" tags-todo "-MAYBE/PROJ"

In my current Org, version 9.3.6-elpaplus, I need a "+" in front of a
select tag, ie the "MAYBE" above needs to be "+MAYBE", otherwise nothing
is selected at all. If this is how it's meant to be, maybe we could
amend this example?

Thanks!

Eric

Re: [PATCH] Skip entries with no ID when updating ID locations

[Eric Abrahamsen]

Bastien  writes:

> Hi Eric,
>
> Eric Abrahamsen  writes:
>
>> Would the attached patch be acceptable? It's no big deal, just skips
>> entries with no ID property when updating all ID locations. I couldn't
>> figure out why I had several thousand "Duplicate ID "nil"" warnings in
>> the *Messages* buffer after updating ID locations.
>
> A welcome enhancement - applied, thanks!

Cool, thanks.

[PATCH] Skip entries with no ID when updating ID locations

[Eric Abrahamsen]

Hi all,

Would the attached patch be acceptable? It's no big deal, just skips
entries with no ID property when updating all ID locations. I couldn't
figure out why I had several thousand "Duplicate ID "nil"" warnings in
the *Messages* buffer after updating ID locations.

Thanks,
Eric

>From d3262aafe1afef3875de83ff46096d54c5c086fe Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Wed, 19 Feb 2020 13:23:40 -0800
Subject: [PATCH] Skip entries with no ID when updating ID locations

* lisp/org-id.el (org-id-update-id-locations): Saves a little chatter
about duplicate "nil" IDs.
---
 lisp/org-id.el | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lisp/org-id.el b/lisp/org-id.el
index 91142917a..369b494ab 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -503,10 +503,11 @@ When FILES is given, scan also these files."
i nfiles file))
 	(when (file-exists-p file)
 	  (insert-file-contents file nil nil nil 'replace)
-	  (setq ids (org-map-entries
-			 (lambda ()
-			   (org-entry-get (point) "ID"))
-			 "ID<>\"\""))
+	  (setq ids (delq nil
+			  (org-map-entries
+			   (lambda ()
+ (org-entry-get (point) "ID"))
+			   "ID<>\"\"")))
 	  (dolist (id ids)
 		(if (member id seen-ids)
 		(progn
-- 
2.25.1

Re: Faster version of org-find-olp

[Eric Abrahamsen]

Bastien  writes:

> Hi Eric,
>
> Eric Abrahamsen  writes:
>
>> I ended up writing a function on top of that that does find-or-create,
>> so you can go to a certain outline path, creating and inserting
>> (optionally in sorted order) the missing segments as you go. It was
>> fairly difficult to get right, so perhaps it will be of use to someone,
>> or appropriate for Worg or even Org proper:
>>
>> https://github.com/girzel/timesheet.el/blob/master/timesheet.el#L250
>
> thanks for this - don't hesitate to reference it somewhere on Worg if
> you think that's useful.
>
> If you think this should go to Org's core, please make a patch and
> tell what's the difference with your patch and how to test it to make
> sure we really understand the issue at stake.  I don't have any issue
> with the current implementation of `org-find-olp' so I cannot really
> know.

It isn't a replacement for `org-find-olp'! It's just built on top of it.
`org-find-olp' signals an error if the full path isn't found. My
function looks for that error and creates the missing segments of the
path. If `org-find-olp' is the equivalent of "cd" in the shell, this
function is like "mkdir -p", plus the "cd" afterwards. It's nice for
programmatically creating outline structures (ie can be used to create
date trees and the like).

I guess I think worg is sufficient -- it's a nice utility, but perhaps
not necessary for core.

Eric

Re: Faster version of org-find-olp

[Eric Abrahamsen]

Bastien  writes:

> Hi Adam,
>
> Adam Porter  writes:
>
>> While working on org-recent-headings, I thought I needed a version of
>> org-find-olp that behaved slightly differently, so I wrote a new
>> function.
>
> thanks for working on such improvements.  Is there something here we
> can integrate in Org (master)?  If possible, let's just optimize the
> current functions with no added constraints or features, then see if
> new options and features can be useful.

I ended up writing a function on top of that that does find-or-create,
so you can go to a certain outline path, creating and inserting
(optionally in sorted order) the missing segments as you go. It was
fairly difficult to get right, so perhaps it will be of use to someone,
or appropriate for Worg or even Org proper:

https://github.com/girzel/timesheet.el/blob/master/timesheet.el#L250

Yrs,
Eric

Re: orgmode.org is down for the next hour

[Eric Abrahamsen]

Bastien  writes:

> Bastien  writes:
>
>> the orgmode.org server has had hiccups again, I am right now upgrading
>> its capacity.  As I take a snapshot first it will be off the next hour
>> or so.
>
> The new server is working now, I doubled its capacity.

Thanks, Bastien!

Canonical way of getting all Org tags?

[Eric Abrahamsen]

Hi all,

I've got a "tags" field for contacts in EBDB (a contact management
package) where I'd like to offer completion on Org tags, so users can
tag any of their contacts using their Org tags.

Previously I was providing completion using the
`org-global-tags-completion-table' function, which Worked For Me™
because I define my tags via use in agenda files, not using
`org-tag-alist' or `org-tag-persistent-alist'. I didn't realize that
that function didn't consult those options.

What's the canonical way of getting a table of all the user's
tags, whether defined manually or used in the agenda files?

I guess I could do:

(org--tag-add-to-alist
 (org--tag-add-to-alist
  (org-global-tags-completion-table)
  org-tag-alist)
 org-tag-persistent-alist)

But that is ugly, and uses a double-dash interior function.

Any recommendations?

TIA,
Eric

Re: [Idea] Org Collections

[Eric Abrahamsen]

Tim Cross  writes:


[...]

> Its a +1 from me. 

And me -- I use Org across so many different contexts (in fact, I'd
propose the name org-contexts over org-collections \end{bikeshed}),
sometimes using the /same data in different contexts/, and while Org has
good tools for localizing config options, it's never felt "clean".

I agree with Tim's point about starting with a limited approach:
restrict it to namespaced collections of config options, and see if
that's sufficient.

Eric

Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.

[Eric Abrahamsen]

Karl Fogel  writes:

> This is the enhancement to `org-narrow-to-subtree' that I suggested back in 
> May [1].
>
> It allows you to choose what level subtree to narrow to. There are two
> ways to specify the subtree: use repeated C-u's to select "upward"
> from the current subtree, or use a direct numeric prefix arg to
> specify the subtree "downward" from level 1. (This is a somewhat
> unusual prefix argument usage, but it's useful to be able to choose
> from either direction, and the convenience of using C-u to select
> upward is quite enormous -- I expect it to be the common case, and
> it's pretty much the only way I use the feature.)

Just 2c: you're right that's a slightly odd use of the prefix argument.
I think a slightly more conventional approach might be to use positive
and negative numerical arguments, positive going one direction, negative
the other. Just a suggestion, though -- I like this addition a lot.

Re: Opening org Agenda whenever opening GNUs:

[Eric Abrahamsen]

Spenser Truex  writes:

> Email is something I check often (with Gnus), so attaching my agenda to
> it is a good way to stay on track.
>
> (defun my-instant-agenda ()
>   (org-agenda-list nil))
> (add-hook 'gnus-before-startup-hook 'my-instant-agenda)
>
> I'd like to be able to have it split vertically, since it otherwise
> obscures my view. How can I do that?
>
>
> =ACTUAL SETUP=
> +--+
> | Gnus |
> |org-mailing list  |
> +--|
> |  |
> |  |
> |  ORG AGENDA  |
> |TODO: everything  |
> |DONE: nothing |
> |  |
> |  |
> |  |
> +--+
> =GOAL EMACS ARANGEMENT=
> +--+
> | Gnus  |  ORG AGENDA  |
> |  org-mailing list |   DONE: everything   |
> |  Mom  |   TODO: other stuff  |
> |  alt.sex  |  |
> |   |  |
> |   |  |
> |   |  |
> |   |  |
> |   |  |
> |   |  |
> |   |  |
> |   |  |
> |   |  |
> |   |  |
> +---

What's your value of gnus-use-full-window? It defaults to t, and I
wouldn't have expected that even your "actual setup" above would work.
If you set that to nil, and then manually create the side-by-side layout
with "C-x 3", is it preserved?

I wrote a package called Gnorb that attempts to integrate Gnus and Org
(and BBDB) a little more closely together, so this is something that I'm
interested in. Gnorb can't currently do this sort of display, in part
because Gnus's window management is gnarly, but it does provide for
tagging Gnus messages with Org tags, and popping up agendas relevant to
messages. I'll be curious to see how you progress with this...

Re: Editting from the agenda view

[Eric Abrahamsen]

Shérab  writes:

> Hi Diego, many thanks for your prompt response!
>
> Diego Zamboni (2019/11/22 16:55 +0100):
>> Hi Shérab,
>> 
>> I usually press Enter on the entry, which takes you to the file from where
>> it came, and you can edit it there.
>
> I tried and it worked, thanks! Does this leave the agenda view and you
> then return to it as you enter it the fiirst time, e.g. C-c a a ?
>
> Is there a way to return to the agenda view exactly where one was when
> pressing enter?

If you use  instead of , the underlying org file will be
popped up next to the agenda, instead of replacing it. When you're done
editing use `other-window' to get back to the agenda, then "o" to close
other windows.

Hope that helps,
Eric

Re: DST and appointments in other timezones

[Eric Abrahamsen]

Leo Gaspard  writes:

> Hello world,
>
> I have appointments that are scheduled on timezones other than my
> computer's. Does org-mode support setting that? It looks like timestamps
> don't support adding a timezone, so I'm wondering whether there's a
> reasonable way to use s-expressions in timestamps for this?
>
> Well, ideally org-mode could be adapted to support timestamps in
> arbitrary timezones, but I guess there are reasons why that's not
> supported?

It's not what you're asking for, but timezones in calendar exports, at
least, are supported. I'm planning an upcoming trip to London, so I make
a "London trip" heading in my schedule.org file, and add a TIMEZONE
property with "Europe/London" as the value. It doesn't work in the
agenda (the agenda would require quite a bit more work to support it),
but when I export to my caldav server the TZ is set properly and it
shows up right on my phone, etc.

That's something, anyway...

Re: Finally figuring out some ob-sqlite stuff -- for worg?

[Eric Abrahamsen]

Stefan Nobis  writes:

> Eric Abrahamsen  writes:
>
>> I was confused in part because the "where exists (select *..." looks
>> like its main purpose is to return rows.
>
> Indeed that's the purpose: Restrict the set of rows upon which update
> acts on. Here I tried to reformat the statement a bit in order to
> emphasize its structure:

Right -- I should have phrased that as "looks like its main purpose is
to return data from rows", which as you clarify below, isn't its main
purpose.

> #+begin_src sql
>   UPDATE bookreview
>   SET rating = (select rating from updates
> where bookreview.id = updates.id)
>   WHERE EXISTS (select * from updates
> where updates.id = bookreview.id);
> #+end_src
>
> The subselect of the "SET rating" part is a correlated subquery. So if
> you imagine UPDATE as a kind of loop over the table, the subquery of
> the SET part is executed once for every row UPDATE acts on (maybe the
> SQL execution engine optimizes this in some kind, but the mental model
> here is: run the subquery for every row we visit on our journey
> throught the table).
>
> Only the WHERE EXISTS clause belonging directly to the UPDATE
> statement will reduce the set of rows to act on.
>
>> Will the select subquery actually restrict the values that are
>> available for updating/comparison in the update statement?
>
> No.
>
>> Or does the "exists" mean the subquery is treated as a plain yes/no
>> boolean, and the update still has access to anything it likes? We
>> could write "where exists (select " to the same effect?
>
> Yes. The SELECT clause of an EXISTS subquery (as in the above example)
> is rather meaningless. So somethimes you see constructs like "where
> exists (select 1 from ...)". Some SQL engines are not very clever and
> execute the subquery of such an EXISTS clause unchanged - meaning that
> way too much data is fetched for the intermediate result (unnecessary
> IO and maybe polluting caches). Thus the "select 1" as a workaround
> for those unclever engines. But current engines should have no
> problems with optimizing these EXISTS subqueries and in that case it
> does not matter how the select clause looks like - it will be ignored.
>
>> In essence, the "where exists" is acting as an "inner join"...
>
> Yes, effectively we are simulating an inner join at this point. Sadly,
> many SQL engines are not able to update rows of join constructs (or at
> least have quite severe constraints in these cases). Thus we need to
> build these kinds of workarounds to change data in more complex cases.
>
> SQL is quite a capable language, but it has also has some rough edges.
> :)

Really interesting! Thanks again for the in-depth explanation.

Re: Finally figuring out some ob-sqlite stuff -- for worg?

[Eric Abrahamsen]

Stefan Nobis  writes:

> Eric Abrahamsen  writes:
>
>> I was confused in part because the "where exists (select *..." looks
>> like its main purpose is to return rows.
>
> Indeed that's the purpose: Restrict the set of rows upon which update
> acts on. Here I tried to reformat the statement a bit in order to
> emphasize its structure:

Right -- I should have phrased that as "looks like its main purpose is
to return data from rows", which as you clarify below, isn't its main
purpose.

> #+begin_src sql
>   UPDATE bookreview
>   SET rating = (select rating from updates
> where bookreview.id = updates.id)
>   WHERE EXISTS (select * from updates
> where updates.id = bookreview.id);
> #+end_src
>
> The subselect of the "SET rating" part is a correlated subquery. So if
> you imagine UPDATE as a kind of loop over the table, the subquery of
> the SET part is executed once for every row UPDATE acts on (maybe the
> SQL execution engine optimizes this in some kind, but the mental model
> here is: run the subquery for every row we visit on our journey
> throught the table).
>
> Only the WHERE EXISTS clause belonging directly to the UPDATE
> statement will reduce the set of rows to act on.
>
>> Will the select subquery actually restrict the values that are
>> available for updating/comparison in the update statement?
>
> No.
>
>> Or does the "exists" mean the subquery is treated as a plain yes/no
>> boolean, and the update still has access to anything it likes? We
>> could write "where exists (select " to the same effect?
>
> Yes. The SELECT clause of an EXISTS subquery (as in the above example)
> is rather meaningless. So somethimes you see constructs like "where
> exists (select 1 from ...)". Some SQL engines are not very clever and
> execute the subquery of such an EXISTS clause unchanged - meaning that
> way too much data is fetched for the intermediate result (unnecessary
> IO and maybe polluting caches). Thus the "select 1" as a workaround
> for those unclever engines. But current engines should have no
> problems with optimizing these EXISTS subqueries and in that case it
> does not matter how the select clause looks like - it will be ignored.
>
>> In essence, the "where exists" is acting as an "inner join"...
>
> Yes, effectively we are simulating an inner join at this point. Sadly,
> many SQL engines are not able to update rows of join constructs (or at
> least have quite severe constraints in these cases). Thus we need to
> build these kinds of workarounds to change data in more complex cases.
>
> SQL is quite a capable language, but it has also has some rough edges.
> :)

Really interesting! Thanks again for the in-depth explanation

Re: Fwd: Re: Finally figuring out some ob-sqlite stuff -- for worg?

[Eric Abrahamsen]

"Thomas S. Dye"  writes:

> Cancel that, I was looking at a cached version of the page.

I guessed that was what happened :)

Re: Finally figuring out some ob-sqlite stuff -- for worg?

[Eric Abrahamsen]

Stefan Nobis  writes:

> Eric Abrahamsen  writes:
>
>> Okay, it's up. If anyone wants to explain to me the point of the
>> "where exists" clause in the SQL, I would be interested to hear. It
>> works as expected this way, but is that clause necessary?
>
> Yes, very necessary. Without it, all ratings would be changed - the
> two example rows without ratings (ids 5 and 12) would get the values
> from the intermediary org table, every other row in table bookreview
> would get its rating attribute set to null (because there is no
> matching entry in the temporary updates table).
>
> Remember: update without a where clause always touches every single
> row of the complete table.
>
> The "where exists" clause ensures that only those rows of bookreviews
> are touched that are present in the intermediary org table. If you do
> not like "where exists" you could say "where bookreview.id in (select
> id from udpates)".

Beautiful, this explains it perfectly. I had the sense that was the
purpose, but my very straightforward programming brain was insisting
that that job should be done with something like your final tip above:
update only if the id is in the updates table.

I was confused in part because the "where exists (select *..." looks
like its main purpose is to return rows. Will the select subquery
actually restrict the values that are available for updating/comparison
in the update statement? Or does the "exists" mean the subquery is
treated as a plain yes/no boolean, and the update still has access to
anything it likes? Ie, we could write "where exists (select " to
the same effect? Hope that's clear!

In essence, the "where exists" is acting as an "inner join"...

Sorry for the off-topic SQL detour! And thanks very much for this cogent
explanation.

Eric

Re: Finally figuring out some ob-sqlite stuff -- for worg?

[Eric Abrahamsen]

"Fraga, Eric"  writes:

> This looks quite useful and would be nice to have on Worg.  Thanks.

Okay, it's up. If anyone wants to explain to me the point of the "where
exists" clause in the SQL, I would be interested to hear. It works as
expected this way, but is that clause necessary?

Re: Finally figuring out some ob-sqlite stuff -- for worg?

[Eric Abrahamsen]

"Thomas S. Dye"  writes:

> Aloha Eric,
>
> Good news.  Yes, please feel free to update the Worg SQLite page.
>
> IIRC, you can get permission from Bastien to push changes and then you
> can edit Worg at will.

Cool! Bastien, can you help me get write access to Worg?

Thanks,
Eric

Finally figuring out some ob-sqlite stuff -- for worg?

[Eric Abrahamsen]

Hi all,

This is about putting some more example stuff on Worg about using Org
and SQLite...

Years ago I realized that Org tables weren't really practical as
"proper" databases, storing large quantities of information. As tempting
as it was to keep everything in-Org, the tables get pretty unusable
after a hundred rows or so.

The obvious solution seemed to be using Org in conjunction with SQLite,
but the stuff on Worg was pretty basic and just didn't quite do what I
wanted it to do.

Years later... I finally went and figured out how to do what I wanted,
namely 1) using an Org table to insert new values into an existing
SQLite table, and 2) using a SQLite block to pull some rows out of a SQL
table into an Org table, then editing the values in the Org table and
inserting the rows back into the SQL table. In other words, using an
intermediary Org table as an editable view on the SQL table.

Those two things together have made Org+SQLite enormously useful to me,
and I'd like to add this information to Worg, with the attached patch
(or something like it).

Does anyone have any comments on it? Would someone help me apply it?

Thanks,
Eric

>From 50fe1a6319dc13b41326702f6ea566f2241e7e52 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Thu, 7 Nov 2019 16:08:54 -0800
Subject: [PATCH] Add more examples to the ob-sqlite section

* org-contrib/babel/languages/ob-doc-sqlite.org: Add tips on inserting
new values into existing tables, and using an intermediary Org table
to edit SQL tables.
---
 org-contrib/babel/languages/ob-doc-sqlite.org | 40 +++
 1 file changed, 40 insertions(+)

diff --git a/org-contrib/babel/languages/ob-doc-sqlite.org b/org-contrib/babel/languages/ob-doc-sqlite.org
index 2dafa1ab..0512c9a4 100644
--- a/org-contrib/babel/languages/ob-doc-sqlite.org
+++ b/org-contrib/babel/languages/ob-doc-sqlite.org
@@ -212,4 +212,44 @@ select n, count(*) from testtable group by n;
 | 10 |2 |
 #+END_EXAMPLE
 
+If dropping/overwriting a table is undesirable, a temporary SQL table
+can be used to insert new values into an existing table:
 
+#+BEGIN_EXAMPLE
+,#+begin_src sqlite :db /tmp/rip.db :var orgtable=tableexample :colnames yes
+create temporary table temp_table(id int, n int);
+.mode csv testtable
+.import $orgtable temp_table
+insert into existing_table (id, n) select id,n from temp_table;
+,#+end_src
+#+END_EXAMPLE
+** Using Org tables as an updatable "view" on SQLite tables
+Org tables can be used to conveniently display some data from a SQLite
+table, allow the user to edit it in Org, and the re-insert the updated
+data into the underlying SQLite table. Do this by naming the results
+table, then using it as input to another SQLite block that updates
+rows. If your table has a primary key, you'll definitely want to use
+it to make sure the correct rows are edited.
+
+#+BEGIN_EXAMPLE
+,#+begin_src sqlite :db /tmp/reviews.db
+select id,title,rating from bookreview where rating is null;
+,#+end_src
+
+,#+name: ratings
+,#+RESULTS:
+|  5 | To Kill a Mockingbird | null |
+| 12 | Three Body Problem| null |
+
+,#+begin_src sqlite :db /tmp/reviews.db :var ratings=ratings
+create temporary table updates (id, title, rating);
+.mode csv updates
+.import $ratings updates
+update bookreview set rating = (select rating from updates
+where bookreview.id = updates.id)
+where exists (select * from updates where updates.id = bookreview.id);
+#+END_EXAMPLE
+
+By editing the intermediary table to replace "null" values with a
+numerical rating, and then running the second source block, the SQLite
+table will be updated correctly.
-- 
2.24.0

Re: Anyone use 3rd party search tools w/org-mode?

[Eric Abrahamsen]

John Kitchin  writes:

> The way I got Swish to index org files was to create a script that
> generated an xml file
> (https://kitchingroup.cheme.cmu.edu/blog/2015/07/06/Indexing-headlines-in-org-files-with-swish-e-with-laser-sharp-results/)
> or html
> (http://kitchingroup.cheme.cmu.edu/blog/2015/07/03/Using-swish-e-to-index-org-files-as-html/)
> that it could index. This is probably a general strategy for these tools.

That seems unfortunately roundabout, but I don't know enough about the
various FTS engines to know if they could be taught to read Org files 
directly...

Re: Anyone use 3rd party search tools w/org-mode?

[Eric Abrahamsen]

Roland Everaert  writes:

> Hello all,
>
> I am interested in a search/indexing engine targeting the org format,
> too.
>
> My interest comes from the fact that I have a growing number of org
> files and as org-mode has no file archiving feature, AFAIK, searching
> needs more and more time to complete.
>
> Moving files, that are no more necessary, outside of my org-directories,
> can be tedious and prone to moving the wrong file to the wrong location.
>
> Hence, an indexer could comes in handy, especially if it is optimised
> for the Org format (i.e.: it knows what are categories, tags,
> properties, etc in an Org file).

I think this last point is key. Most full-text search engines provide
config options for defining fields, or "facets", which in theory we
could set up to parse tags/properties/timestamps. My guess is that any
of the major contenders (solr, xapian, lucene) would work pretty much as
well as any of the others -- for our purposes, they probably only differ
in the details. Xapian might be considered "in the family" from a
license standpoint, but I don't know that that matters too much.

It would be fun to provide an Org indexing config for one of these
engines, and then build the Agenda on top of it.

Re: [O] Org-contacts and extra spaces

[Eric Abrahamsen]

Norman Walsh  writes:

> Hi,
>
> If I complete an email address with org-contacts, I get extra spaces
> after the email address:
>
>   To: Jane Doe _ _ _ _[cursor]
>
> Is this just me? Before I go digging for a solution, has anyone else
> encountered and fixed this?

The only time I ever saw something like this was in message-mode, using
C-M-i/completion-at-point to complete mail addresses. If I recall
correctly, it was caused by message-mode's idiosyncratic partial support
for the built-in completion mechanisms. In EBDB I had to add a cleanup
function to `choose-completion-string-functions' to remove the
whitespace.

Could that be what you're seeing?

Re: [O] exported contacts problem

[Eric Abrahamsen]

David Masterson  writes:

> Eric Abrahamsen  writes:
>
>> But Org can be an excellent *interface* to those tools, mostly through
>> dynamic blocks. I've started using small sqlite databases to keep track
>> of things, and dynamic blocks as sql composers/views, and it works
>> great. It's very easy to play with the queries, and this is the first
>> time I'm actually starting to feel comfortable with sql.
>>
>> I think in general Org is best used as a compositional tool for data
>> drawn from elsewhere.
>
> What do you think of RDB? It seems to be an old set of Perl scripts
> derived from /rdb (an older set of Unix shell scripts) that can be used
> to do basic relational database commands on textual database tables.  If
> it could be translated into an Elisp package, it would fit the Emacs
> model of open source and easily understandable data storage.  It can be
> gotten via ftp here:
>
> cdb.netbsd.org/pub/pkgsrc/distfiles/RDB-2.6d.tar.gz

I've never heard of it! But from your description it kind of sounds like
another attempt to use relational databases without actually using
relational databases :) I guess I think databases are one of those
things you should delegate to an external program. Org is already pretty
good at interfacing with them.

Re: [O] exported contacts problem

[Eric Abrahamsen]

Neil Jerram  writes:

> I've tried to work on contact conversion and synchronization in the past,
> aiming to merge and unify contacts that I've built up in BBDB, Google
> Contacts, email systems, pre-Android phones, etc.  The problematic aspect
> was different systems using different field names and structures, e.g. one
> with separate First Name and Last Name, and another with a combined Name
> field; different approaches to breaking up addresses; additional arbitrary
> notes fields; etc.
>
> With that in mind, I'm curious if the writers on this thread could comment
> on:
> 1. is this situation any better now?

If by "this situation" you mean fragmentation of data formats and
approaches, I don't think it's getting any better!

> 2. if you favour using org-contacts or org-vcard, what do you see as the
> benefit of Org as your master contact format, as opposed to say BBDB or
> .vcf?

I think something similar happens with Org as with happens with Emacs in
general: it's such a nice environment to be working in that people want
to move all their stuff into it. But there are some areas (contact
management, email, large datasets) where Org just isn't going to work as
well as a specialized tool.

But Org can be an excellent *interface* to those tools, mostly through
dynamic blocks. I've started using small sqlite databases to keep track
of things, and dynamic blocks as sql composers/views, and it works
great. It's very easy to play with the queries, and this is the first
time I'm actually starting to feel comfortable with sql.

I think in general Org is best used as a compositional tool for data
drawn from elsewhere.

Eric

Re: [O] exported contacts problem

[Eric Abrahamsen]

Jean Louis  writes:

> * Eric Abrahamsen  [2019-08-03 02:27]:
>> Okay, thanks for that run-down, pretty interesting. I've written a
>> package called EBDB[1] that's meant to be sort of an update to BBDB, and
>> while I think someone's using it with tens of thousands of contacts,
>> 192k records would probably exhaust it. It has pluggable data stores,
>> however, one of which will (eventually) be a proper external database,
>> so I'm always interested in how people are using this stuff.
>> 
>> Eric
>> 
>> [1] https://github.com/girzel/ebdb
>
> I have tried it. It has good concepts and integration. But I cannot
> switch to it.

No, and I think it would fall apart under your workload. But I would
like to make it better, and gradually get it closer to supporting the
sort of thing you're doing.

> Please, if you intend to make vcard import, don't make vcard stuff
> bundled with the ebdb, you will make repeated mistake.
>
> Make one vcard import package that give elisp structure, something
> like hash or alist, plist, whatever is better.

Yes, that's on my (mid-length) list of to do: a vcard parsing library
that just turns vcards into a couple pre-defined formats, or lets you
register your own consumption functions.

> Then such package is best to contribute to GNU Emacs.
>
> Then all other packages can use vcard import.
>
> This makes much sense rather than making it single-package oriented.
>
> I don't think that vCard complexity is necessary for contacts,
> standard is invented, but is too complex. But if you are doing it,
> than such feature can contribute to overall usage.

I'm also not fond of vcard, but I *am* fond of carddav, and having my
contacts synced to my phone, and shared with co-workers, etc. Otherwise
I probably wouldn't bother.

Jean Louis  writes:

> * Eric Abrahamsen  [2019-08-03 02:27]:
>> Okay, thanks for that run-down, pretty interesting. I've written a
>> package called EBDB[1] that's meant to be sort of an update to BBDB, and
>> while I think someone's using it with tens of thousands of contacts,
>> 192k records would probably exhaust it. It has pluggable data stores,
>> however, one of which will (eventually) be a proper external database,
>> so I'm always interested in how people are using this stuff.
>> 
>> Eric
>> 
>> [1] https://github.com/girzel/ebdb
>
> Not sure if you rely on vCard as some kind of "standard". It is
> attempt to globalize the contact keeping, but I don't find it good,
> not at all.
>
> It is way too complicated. It tries to encompass everything possible
> in one file, file which is probably not related to other files at all.
>
> Only relational database makes sense for complex contact management.

EBDB now provides for a sort of poor-man's relational database, with
multiple "roles" and relations, linking people to people and people to
organizations. But it's still limited and kind of awkward.

Eric

Re: [O] exported contacts problem

[Eric Abrahamsen]

Jean Louis  writes:

> * Eric Abrahamsen  [2019-08-02 23:11]:
>> > Neither bbdb nor Org is suitable for any serious collection of
>> > contacts. I have 192,000+ contacts, and when they are in database and
>> > I am using PostgreSQL, it gives me most of benefits, I can sort people
>> > into lists, groups, I can contact them, count interactions, open up
>> > their files, emails with a fast command, edit their data, add notes,
>> > send them faxes and SMS, maintain relations.
>> 
>> That sounds pretty intense. Have you written a separate package for
>> interacting with the database?
>
> I wrote few generic functions and use it with helm, it works for
> me. It is not ready for public. Web interface works based on Gedafe[1]
> and then I wrote access to it through console Common Lisp and then
> also through Emacs Lisp.
>
> I am using Emacs module `emacs-libpq'[2] to interact with PostgreSQL.
>
> Let's say I am looking for somebody, Hyper-C asks me for query, I
> enter something, then I can choose to open Org file relating to the
> person. When dealing with various companies, things related to a
> company shall be in the directory related to company. Things related
> to person, for example assignments related to one person shall be in
> the file belonging to that person.
>
> That way full file can be sent to the person for review, it becomes
> clear what has been done, and what is yet to be done.
>
> Mixing assignments, TODO, agendas from all subjects, groups and
> persons into one file would give me terrible confusion.

Okay, thanks for that run-down, pretty interesting. I've written a
package called EBDB[1] that's meant to be sort of an update to BBDB, and
while I think someone's using it with tens of thousands of contacts,
192k records would probably exhaust it. It has pluggable data stores,
however, one of which will (eventually) be a proper external database,
so I'm always interested in how people are using this stuff.

Eric

[1] https://github.com/girzel/ebdb

Re: [O] exported contacts problem

[Eric Abrahamsen]

Jean Louis  writes:

> * Jude DaShiell  [2019-08-02 17:48]:
>> I have one email message with several .vcf file attachments.  Has orgmode
>> got any tool or tools I can use to import contacts from such a message
>> into an orgmode table?
>
> And by all means, I would never keep contact in Org file, that is for
> short list fine, but for any future planning, contacts shall be in a
> real database sorted by its lists.
>
> A list could be group of people, or account name, or company name, or
> organization, or interest lists.
>
> Neither bbdb nor Org is suitable for any serious collection of
> contacts. I have 192,000+ contacts, and when they are in database and
> I am using PostgreSQL, it gives me most of benefits, I can sort people
> into lists, groups, I can contact them, count interactions, open up
> their files, emails with a fast command, edit their data, add notes,
> send them faxes and SMS, maintain relations.

That sounds pretty intense. Have you written a separate package for
interacting with the database?

Re: [O] Show breadcrumbs of nodes in agenda

[Eric Abrahamsen]

Florian Lindner  writes:

> Hello,
>
> the agenda only shows the title of nodes, like:
>
> capture:TODO Task 1
>
> Often, I have a structure like
>
> * Project A
> ** Task 1
>
> * Project B
> ** Task 1
>
> then, I get no idea, from what project the task actually is.
>
> Is there a way to also show the title of the parent in agenda buffer or even 
> full breadcrumbs?

You can use %b in the value of `org-agenda-prefix-format'.

Re: [O] org-links for Gnus in imap with Gmail (for a convenient todo.org list)

[Eric Abrahamsen]

Joseph Vidal-Rosset  writes:

> Le   jeu.   07/25/19   juil.   2019   à   05:33:57   ,   "Fraga,   Eric"
>  a envoyé ce message:
>
>> Okay, yes, if you move it, the link needs to be updated.  I wonder if
>> the gnus registery could help with this?  But that's well beyond my
>> gnus-fu.
>
> The only mention of gnus registry in my setup is the following one:
>
> (setq gnus-registry-max-entries 5)
>
> and, by the way, it is maybe inconsistent with
>
> (setq gnus-newsgroup-maximum-articles 7)

You'd have to put (gnus-registry-initialize) in your gnus.el init file
to make use of the registry. And no, I don't think the above settings
have anything to do with one another.

Eric

Re: [O] Help with dblocks and table formulas (and an RFC on quantitative logging)

[Eric Abrahamsen]

"Fraga, Eric"  writes:

> On Tuesday, 18 Jun 2019 at 20:18, Eric Abrahamsen wrote:
>> I'm finally trying to scratch a very old itch of mine: quantitative
>> logging in Org. 
> [...]
>
>> 1. I can't reliably trigger the note prompting using TODO keyword setup.
>
> What about using org-after-todo-stage-change-hook?

Hmm, that's a possibility, thanks. There are so many fiddly bits with
getting the right information out of the right dynamic variables, it
might take a while to pin this down...

>> Anyway, this is a total work in progress, but I would be curious if
>> anyone would find this useful, and for what.
>
> It's interesting and I can see at least one use: logging expenses.  I
> normally use ledger but this is overkill for some simple tasks.

Cool, well, I'll report back when I have something a little more
mature...

eric

[O] Help with dblocks and table formulas (and an RFC on quantitative logging)

[Eric Abrahamsen]

Hi all,

I'm finally trying to scratch a very old itch of mine: quantitative
logging in Org. Basically it's the same idea as org-clock, except
generalized to log random values. Rather than explain at length, below is
what a sample todo would look like, plus the created dblock. You specify
a LOG_VALUES property (multiple labels are possible), and then anytime
you take a note, you're prompted to enter values for those labels. Then
there's a command for making the dblock.

*** CHECK Test blood glucose
SCHEDULED: <2019-06-19 Wed +1d>
:PROPERTIES:
:ID:   dummy
:LOG_VALUES: MG
:LAST_REPEAT: [2019-06-18 Tue 19:55]
:END:
:LOGBOOK:
- State "DONE"  from "CHECK"  [2019-06-18 Tue 19:56] \\
  MG: 98;
- State "DONE"  from "CHECK"  [2019-06-17 Mon 19:55] \\
  MG: 110;
- State "DONE"  from "CHECK"  [2019-06-16 Sun 19:55] \\
  MG: 103;
:END:

#+BEGIN: log :id "dummy"
| Timestamp  |  Mg |
|+-|
| [2019-06-18 Tue 19:56] |  98 |
| [2019-06-17 Mon 19:55] | 110 |
| [2019-06-16 Sun 19:55] | 103 |
#+END:

The code for this is below, I'm sure it's a mess and doesn't take into
account hardly any of the variety of Org configs.

But it sort of works! I have a few questions:

1. I can't reliably trigger the note prompting using TODO keyword setup.
   The above example is actually manually adjusted because I couldn't
   get it to prompt for a note when going into DONE state, even with
   DONE(@). But presumably that's my own confusion.
2. I don't know how to handle defining table formulas. Are users meant
   to insert them manually into the dblock? As a property on the
   heading? What's the usual thing to do?
3. What I'd really like is to have this integrated with clocking, so
   that clocking out also prompts for log values, and then you can make
   tables that show not only how many hours you worked today, but also
   how many... widgets you frobbed in that time. I guess this isn't
   really a question, just an indication of where I hope it might go.
   
Anyway, this is a total work in progress, but I would be curious if
anyone would find this useful, and for what.

Eric

#+src elisp
;;; Code:

(require 'org)

(defun org-log-prompt ()
  "Prompt the user for log values.
Insert values into the current log note."
  ;; This is called in the log buffer.  Only fire for state and note;
  ;; later add clock-out.
  (when (memq org-log-note-purpose '(state note))
(let ((values
   (with-current-buffer (marker-buffer org-log-note-marker)
 (save-excursion
   (goto-char org-log-note-marker)
   (org-entry-get (point) "LOG_VALUES" 'selective)
  (when (and (stringp values) (null (string-empty-p values)))
(unless (bolp)   ; This might follow a clock line.
  (insert "; "))
(dolist (val (split-string values))
  ;; Maybe strip off units.
  (setq val (substring val 0 (string-match-p "\\[" val)))
  (insert val ": ")
  (insert (read-string (format "%s: " val)) "; "))

(defun org-log--collect-data (id)
  "Collect log data from heading with id ID.
When valid data is found, it is returned as a list of lists.
Each sublist starts with the timestamp of the log entry, followed
by data keys and values, in the order they were found in the log
entry.

If no valid data is found, return nil."
  (save-excursion
(org-id-goto id)
(goto-char (org-log-beginning))
(let* ((struct (org-list-struct))
   (labels (org-entry-get (point) "LOG_VALUES" 'selective))
   (entries (when (and (stringp labels)
   (null (string-empty-p labels)))
  ;; First element is a list of value labels.
  (list (cons "TIMESTAMP"
  (mapcar (lambda (str)
(substring
 str 0 (string-match-p "\\[" str)))
  (split-string labels))
   elt data)
  (when (and entries struct)
;; Get onto the list item.
(forward-char)
(while (equal 'item (org-element-type
 (setq elt (org-element-at-point
  ;; Move past state/timestamp line.
  (forward-line)
  (while (re-search-forward "[[:upper:]]+: \\([^;]+\\)"
(point-at-eol) t)
(push (match-string-no-properties 1) data))
  (when data
(save-excursion
  (forward-line -1)
  ;; Get the log entry timestamp.
  (setq data
(cons (if (re-search-forward org-ts-regexp-inactive
 (point-at-eol) t)
  (match-string-no-properties 0)
"none")
  (nreverse data
(push data entries)
(setq 

Re: [O] Advance notice of birthdays in org-mode via org-contacts

[Eric Abrahamsen]

Alan Schmitt  writes:

> Hi Eric,
>
> On 2019-05-28 04:34, Eric Abrahamsen  writes:
>
>> And (shameless plug) if you're using EBDB, you can set both
>> `ebdb-use-diary' and `org-agenda-include-diary' to t, and
>> anniversaries
>> will show in the agenda.
>
> Thank you for the plug, I've been wanting to look at EBDB for a while.
> I
> have a few questions: is it easy to migrate data from BBDB? Can you
> have
> org links to EBDB records? Does it work with mu4e for address
> completion?

Glad you're considering it! EBDB will migrate automatically from
versions 2 or 3 of BBDB (it is slow, but you only have to do it once),
you just have to have the `bbdb-file' variable pointing to a valid BBDB
file, then call `ebdb-open'.

It supports org links, either to single records, or to record searches:
following a link like "ebdb:mail/@gnu.org" will search for all records
with Gnu email addresses. You can also tag your records with org tags,
and pop up an EBDB window alongside a tag agenda search, for instance.

In theory it supports mu4e, but I think you would be the first user, if
you tried it, so beware! :)

Eric

Re: [O] Advance notice of birthdays in org-mode via org-contacts

[Eric Abrahamsen]

Nick Dokos  writes:

> Daryl Manning  writes:
>
>> I'm trying to come up with a better way to give myself advanced
>> notice on some peoples' birthdays coming up. 

And (shameless plug) if you're using EBDB, you can set both
`ebdb-use-diary' and `org-agenda-include-diary' to t, and anniversaries
will show in the agenda.

Re: [O] Macro that calls external program

[Eric Abrahamsen]

Josh  writes:

> Thanks! This is very helpful.
>
> I have a related question. How can I run an external program right
> before Export that takes as input the current buffer and prints out to
> stdout an updated version of the org file that then is exported?
> Basically I want to pipe the org file through a filter that is an
> external program before it is exported.

Probably one of `org-export-before-parsing-hook' or
`org-export-before-processing-hook' is where you'd hang a custom
function that does this.

Re: [O] bug#34684: 26.1; Strange characters when inserting date

[Eric Abrahamsen]

Robert Pluim  writes:

> Eli Zaretskii  writes:
>
>>> From: "Wong, Philip" 
>>> Date: Thu, 28 Feb 2019 14:16:25 +
>>> 
>>> When I insert a date by pressing CTRL+C then period then enter I get 
>>> “<2019-02-28 ¶g¥|>”.
>>> 
>>> I’m not sure what the strange character is (¶g¥|), can someone help?
>>
>> Please show a complete recipe, starting from "emacs -Q", to reproduce
>> the issue.  When I type "Ctrl-C ." in "emacs -Q", Emacs says that
>> sequence is not bound to any command, so I wonder what is needed to
>> "insert a date" in your scenario.
>
> From the output, this is 'org-time-stamp', which produces
> <2019-02-28 Thu> here. Based on this in the report:
>
> Important settings:
>   value of $LANG: ZHH
>   locale-coding-system: cp1252
>
> Iʼm assuming thereʼs an issue with buffer-file-coding-system or
> similar. If I do
>
> LANG=zh_HK src/emacs -Q
> (require 'org)
> (org-time-stamp) => <2019-02-28 四>

That means "four", aka "Thursday" :)

Re: [O] [PATCH] Let radio target works well with Chinese

[Eric Abrahamsen]

Emilio Francesquini  writes:

> Hello,
>
>> <<<天空>>>
>> >
>> > 我爱天空和大地
>> > 
>>
>> Org doesn't support mid-word radio targets. Is there any strong reason
>> to make a case for Chinese? What about other languages?
>>
>
> My knowledge in Chinese is rather limited, but if it is a little like
> Japanese the problem is that those languages do not use spaces to separate
> words.
>
> I found myself in the same situation writing radio targets in Japanese...
> My workaroud was to insert artificial spaces as needed... :/

I've gotten this information (does-space-separate-words) for specific
characters before using either of these two methods:

(aref (char-category-set ?b) ?|) => nil
(aref (char-category-set ?中) ?|) => t

(aref fill-nospace-between-words-table?b) => nil
(aref fill-nospace-between-words-table ?中) => t

| is the category character for "line breakable". Perhaps adding "\c|"
to the regexp would DTRT?

Eric

[O] Change default value of org-refile-use-outline-path?

[Eric Abrahamsen]

Hello,

I wonder if there'd be any interest in changing the default value of
`org-refile-use-outline-path' to something other than nil? I can't
imagine the nil default would be anyone's preference (at least not
anyone with more than a handful of headings in a single file). How about
'file as a more user-friendly default?

Eric

Re: [O] Org brings people together!

[Eric Abrahamsen]

John Hendy  writes:

[...]

> So far, Org-ers have been 100% awesome in person, and I look forward
> to running into more down the road. Anyway, just felt like a fun bit
> of news to share, and hopefully you all can nerd out about Org in
> person at some point too!

Somebody tell me if there's a Seattle meetup!

Eric

Re: [O] orgalist list item spacing

[Eric Abrahamsen]

Eric S Fraga  writes:

> On Saturday, 15 Sep 2018 at 11:03, Eric Abrahamsen wrote:
>> Eric S Fraga  writes:
>>> Long standing "feature" of org.  Unless you do require a blank line
>>> between items, it is impossible to differentiate between the start of a
>>> numbered item and the continuation of the previous item in this case.
>>
>> Huh, I've never seen this in org-mode proper. 
>
> Silly me.  I was comparing apples and oranges.  In org mode, I use
> visual-line-mode and no filling; in message mode, I use
> auto-fill.  Sorry for my intervention!

No worries, I still ended up learning something :)

Re: [O] orgalist list item spacing

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric S Fraga  writes:
>
>> On Friday, 14 Sep 2018 at 14:47, Eric Abrahamsen wrote:
>>> One thing I noticed is that if a paragraph line wraps so that the last
>>> line has a number followed by a full stop, orgalist treats that as a
>>> list item. It seems to me that text should not be considered a list item
>>> unless there's a blank line above it. Ie, this is currently considered a
>>> list item:
>>
>> [...]
>>
>>> Is this a bug, or a configurable option, or just the way it's supposed
>>> to work?
>>
>> Long standing "feature" of org.  Unless you do require a blank line
>> between items, it is impossible to differentiate between the start of a
>> numbered item and the continuation of the previous item in this case.
>
> Correct.
>
> I released Orgalist 1.9, which should hopefully mitigate this issue. In
> particular, it is now impossible for auto fill to create these wrong
> items.

Thanks! Maybe I was misinterpreting what I was seeing in Org mode buffers.

Re: [O] orgalist list item spacing

[Eric Abrahamsen]

Eric S Fraga  writes:

> On Friday, 14 Sep 2018 at 14:47, Eric Abrahamsen wrote:
>> One thing I noticed is that if a paragraph line wraps so that the last
>> line has a number followed by a full stop, orgalist treats that as a
>> list item. It seems to me that text should not be considered a list item
>> unless there's a blank line above it. Ie, this is currently considered a
>> list item:
>
> [...]
>
>> Is this a bug, or a configurable option, or just the way it's supposed
>> to work?
>
> Long standing "feature" of org.  Unless you do require a blank line
> between items, it is impossible to differentiate between the start of a
> numbered item and the continuation of the previous item in this case.
>
> It's an annoyance sometimes but usually minor.

Huh, I've never seen this in org-mode proper. I just went and did a bit
of testing, and it looks like wrapping in org-mode involves some
cleverness where it "over-wraps" lines that would otherwise start with a
number, making sure the previous word always comes down to start the
next line. Orgalist isn't that clever, which I guess is by design, and
probably a good thing.

Eric

[O] orgalist list item spacing

[Eric Abrahamsen]

I'm a happy user of orgalist, it's very nice to be able to have basic
Org structures in email.

One thing I noticed is that if a paragraph line wraps so that the last
line has a number followed by a full stop, orgalist treats that as a
list item. It seems to me that text should not be considered a list item
unless there's a blank line above it. Ie, this is currently considered a
list item:

This is an email talking about some future plans that will take place in
2020. This line with the 2020 is considered a list item.

  As evidenced by the indent automatically applied to this line.
  
C-j fixes it, as usual.

Is this a bug, or a configurable option, or just the way it's supposed
to work?

Thanks,
Eric

Re: [O] [PATCH] Add org-attach-download command

[Eric Abrahamsen]

Adam Porter  writes:

> Hi,
>
> This patch adds a new org-attach-download command, which downloads
> remote files with url.el and attaches them with org-attach.  When called
> without a prefix, it first looks at point for a link, and prompts the
> user for a URL if none is found.  When called with prefix, it prompts
> for the URL.  Before downloading, it asks for confirmation.

Don't we already have org-attach-url? I thought that did this...

Re: [O] Documentation in ePub Format

[Eric Abrahamsen]

Colin Baxter  writes:

> There must be something here I don't understand. If you want epub why not
> just go from org-manual.org directly to epub using
> https://github.com/ofosos/ox-epub? Why do we need to go via texi?

Good point!

Re: [O] Documentation in ePub Format

[Eric Abrahamsen]

Dilyan Palauzov  writes:

> Hello Eric,
>
> with https://github.com/jlhg/texinfo2epub I did
>
>  PATH/texinfo2epub/texinfo2epub.sh org-9.114/doc/org.texi org-9.1.14.epub
>
> The result – https://mail.aegee.org/dpa/org-9.1.14.epub – seems good.

Looks like this is something pandoc can handle as well -- it would be
interesting to compare the two outputs.

[O] customizable org-attach commands?

[Eric Abrahamsen]

I'd like to provide a patch making the org-attach dispatcher
customizable. ie a new custom option `org-attach-commands' that maps
characters to functions, and then the dispatch function builds its menu
from that option. Would that be acceptable?

What I'm trying to do is add my own org-attach function that prompts for
a file and then attaches it to an outgoing Gnus message buffer.

Another org-attach thing I'd like to do is add a way to export a subtree
as a file into the subtree's attach directory, but I haven't come up
with a good way of doing that yet. One way would be to add an option to
the export dispatcher, which seems awkward. Another way would be to
allow a property like ":EXPORT_FILE_NAME: :ATTACH_DIR", and look for
that in `org-export-output-file-name'. But that will require a little
more thought.

Eric

Re: [O] Orgalist notes

[Eric Abrahamsen]

On 05/06/18 10:34 AM, Bernt Hansen wrote:
> Eric Abrahamsen <e...@ericabrahamsen.net> writes:
>
>> And, as always, thank you! This is fairly heroic work -- I say that
>> after having made an attempt at orgstruct-mode, and run away screaming.
>> And look, no funny indentation!
>>
>> - Yet a list item with a ridiculous amount of text in it does not wrap
>>   into a second list item.
>> - Neither does the second list item, despite having an equivalent amount
>>   of spurious typing in it.
>>
>> - And before I get tired of the experiment, here's the same thing with
>>  a numbered list.
>> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>>   list.
>>
>> No good deed goes unpunished :)
>
> I think you need 2 blank lines between the lists to separate them by
> default - otherwise they are treated as one list and the first bullet
> defines the type of list (and therefore changes your 1. back to -

You're quite right! That did the trick. All seems to be behaving
perfectly now.

Thanks,
Eric

Re: [O] Orgalist notes

[Eric Abrahamsen]

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Hello,
>
> Gregor Zattler <telegr...@gmx.net> writes:
>
>> Hi Eric, orgalist users,
>> * Eric Abrahamsen <e...@ericabrahamsen.net> [2018-05-03; 23:45]:
>>> Huh! I tried the exact same typing as you've done above, and the third
>>>  item wraps into a fourth item. I expect it will be some interaction
>>>  with other minor modes. I've got:
>>
>> I have the very same problems with unstoppable indentation in
>>   orgalist and I don't think it is an interaction with other
>>   minor modes, because it hits even with no configuration.  Do:
>>
>> emacs25 -Q  --debug-init  -l 
>> /home/grfz/.emacs.d/elpa-27.0/orgalist-1.3/orgalist.el   -f compose-mail 
>> --eval "(progn (orgalist-mode t) (end-of-buffer) (newline) (newline))"
>>
>> (you'll have to adjust the path to your orglist.el)
>>
>> and hit RETURN in the newly created emacs frame and this last new
>> line will be indented.
>>
>>
>> I also tested with a freshly build emacs from the master branch
>>   and it showed the same behaviour.
>
> Indeed. When I tried make Orgalist mode fair with other minor modes and
> switched to using advices, I encountered a few unexpected hiccups, most
> notably bug#31361, which is responsible for some erratic indentation.
>
> I eventually worked around it, and just updated Orgalist. It should be
> available on ELPA toworrow. Hopefully, thing will become a bit smoother.
>
> Thank you for the reports.
>
> Regards,

And, as always, thank you! This is fairly heroic work -- I say that
after having made an attempt at orgstruct-mode, and run away screaming.
And look, no funny indentation!

- Yet a list item with a ridiculous amount of text in it does not wrap
  into a second list item.
- Neither does the second list item, despite having an equivalent amount
  of spurious typing in it.

- And before I get tired of the experiment, here's the same thing with
 a numbered list.
- Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
  list.

No good deed goes unpunished :)